Re: [homenet] (no subject)

Sure, it *could*, but it's probably easier to implement it as a split-horizon DNS server that only talks to the homenet. On Tue, Jul 24, 2018 at 12:31 AM, Tim Wicinski wrote: > Instead of calling it a "DNS Server" perhaps call it the "declarative data > store"? it could be a git repo, > > tim >

Re: [homenet] (no subject)

Instead of calling it a "DNS Server" perhaps call it the "declarative data store"? it could be a git repo, tim On Mon, Jul 23, 2018 at 10:43 PM, Ted Lemon wrote: > The DNS server in the cloud doesn't have to answer queries. Indeed, it > probably shouldn't. It's really just a backing store.

Re: [homenet] (no subject)

The DNS server in the cloud doesn't have to answer queries. Indeed, it probably shouldn't. It's really just a backing store. The public/private primary with selective publication is just a functional block—you can put it where it makes the most sense. Juliusz is saying that he wants a nearl

Re: [homenet] (no subject)

On 07/23/2018 05:45 PM, STARK, BARBARA H wrote: You're concerned with the homenet losing state when the master is unplugged.   By having the master in the cloud, this problem is eliminated. I can't speak for Juliusz, but my first question was "what if i don't want it in the cloud"? For one thi

Re: [homenet] (no subject)

> > You're concerned with the homenet losing state when the master is > > unplugged.   By having the master in the cloud, this problem is eliminated. > I can't speak for Juliusz, but my first question was "what if i don't want it > in the cloud"? For one thing, what if it's a cloudless day? I w

Re: [homenet] (no subject)

On 07/23/2018 03:36 PM, Ted Lemon wrote: On Jul 23, 2018, at 6:10 PM, Juliusz Chroboczek > wrote: What? You're concerned with the homenet losing state when the master is unplugged.   By having the master in the cloud, this problem is eliminated. I can't speak for Julius

Re: [homenet] (no subject)

On Jul 23, 2018, at 6:10 PM, Juliusz Chroboczek wrote: > What? You're concerned with the homenet losing state when the master is unplugged. By having the master in the cloud, this problem is eliminated. ___ homenet mailing list homenet@ietf.org http

Re: [homenet] (no subject)

> if the homenet loses its memory, it can simply refresh it from the cloud. What? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet

[homenet] virtual interims to progress simple naming draft

Hiya, As mentioned in Montreal, we're thinking of organising a set of virtual interims to try help progress this [1] draft. The goal is to try more quickly move it along to the point where (we think) it's editorially complete, at which point it ought be easier for implementers to use, and to give

Re: [homenet] (no subject)

On Mon, Jul 23, 2018 at 4:08 PM, Juliusz Chroboczek wrote: > whereas Daniel's draft only allows me to publish my address > if I'm in my Homenet. > One of the reasons I was hassling Daniel at the mic about updating his draft based on implementation experience is that I think it's hard to read th

[homenet] (no subject)

>> neither SIP, nor Skype, nor BitTorrent, nor syncthing, nor anything >> else that normal people run in their home relies on the DNS for >> locating remote peers. > If publishing things into global DNS worked reliably and automatically, > and we had IPv6 everywhere, such designs would not be need

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

Juliusz Chroboczek writes: >> Why? What is wrong with the owner of the network selecting which devices >> / services he/she wants globally reachable > > I don't think this is about global reachability (which is hopefully > managed by PCP), it's about exporting names into the global DNS. We > ough

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

Hi, On Mon, Jul 23, 2018 at 08:50:50PM +0200, Toke Høiland-Jørgensen wrote: > Juliusz Chroboczek writes: > > > Exporting names from the Homenet into the global namespace, on the > > other hand, should be done by the hosts, with no involvement of any > > third party (neither the ISP nor the Homen

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

> Why? What is wrong with the owner of the network selecting which devices > / services he/she wants globally reachable I don't think this is about global reachability (which is hopefully managed by PCP), it's about exporting names into the global DNS. We ought to distinguish the two -- you can b

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

> Apparently my comment was clear as mud. I meant this: > https://tools.ietf.org/html/draft-ietf-opsawg-mud-25 Quote, "YANG-based JSON that describes a Thing", unquote. 61 pages. Revision 25, and still a draft. I wish you a lot of fun implementing that. > Having a public/private zone pair where

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

Juliusz Chroboczek writes: > Exporting names from the Homenet into the global namespace, on the > other hand, should be done by the hosts, with no involvement of any > third party (neither the ISP nor the Homenet itself). This is where I > argue for some form of end-to-end, secured, dynamic DNS u

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

> By using DynDns are you proposing to remove the requirement of having > a naming resolution mechanism internally in the homenet ? No. Naming *internal* to the Homenet needs another mechanism, perhaps what Ted is designing (and implementing), perhaps something else. Exporting names from the Hom

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

Hi Juliusz, I'm just catching up in the mailing list here and I'd like to clarify if my understanding is correct. By using DynDns are you proposing to remove the requirement of having a naming resolution mechanism internally in the homenet ? DynDns does work nicely to update a single record

Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

Apparently my comment was clear as mud. I meant this: https://tools.ietf.org/html/draft-ietf-opsawg-mud-25 Having a public/private zone pair where the public zone is an image of the private zone that is constructed following rules, the default rule being "don't copy," seems very straightforward