Re: [homenet] I-D ACTION:draft-lemon-homenet-naming-architecture-00.txt

[Markus Stenberg <[e-mail]>]

On 1.4.2016, at 16.09, Ted Lemon <[e-mail]> wrote:
> On Fri, Apr 1, 2016 at 3:32 AM, Markus Stenberg <[e-mail]> wrote:
> Section 2.1: It looks interesting. I like having separate naming and connectivity provider, if we can pry the reverse delegation off the connection providers’ dead hands at any rate.
> If you mean “get the ISP to do the delegation,” I think having it as part of the architecture will at least get them thinking about it, which is a start! :)

Yes. Not optimistic though :)

> Section 2.2: I am not sure I like ‘flat’ namespace, as it prevents e.g. DNS-SD records from being associated with the particular namespace (or is this ‘flat’ in some logical sense and not really talking about label sequences?).
> It's intended to be flat in the sense of a single label.   What would you see as the use for a non-flat namespace?   You mention DNS-SD records "being associated with a particular namespace," but this is more of a campus-wide DNS-SD solution than a homenet solution.   If you are trying to address the campus use case, I think that could be accomplished in a follow-on document, since it's not the primary goal.   But say on—is there more to it than that?

Well, my reading at the time was that it was strictly <label>.<zone>; therefore, even DNS-SD <service>.<transport>.<zone> would be out of scope. I hoped it was just an error on reader’s part :) 

> Section 2.3: I think public should be separate DNS-SD (+DNS-update) zone with manual opt-in, and not created out of local entries.
> Okay, but how would that work?   Do you mean just a different name externally than internally?   I agree with that to some extent, but it makes the UI harder because now the user has two different names for the same resource, depending on whether they are internal or external to the homenet.

Yes. Public should be opt-in, not default, because I for one at least don’t want to advertise every service in my home for various reasons; e.g. if there’s vulnerable product X, if trawling for the DNS-SD records in the well-defined home <domain> brings up data about it, someone can drive over and do bad things over wifi to e.g. broken Belkin wifi home automation stuff. Completely fictional example with nothing to do with the fact that the ones I used to use sometimes booted to default wifi, no password mode..

> Section 2.4.3: I would like some sort of ‘claim ownership of record X, allow updating it only if you are owner’ schemed DNS-Update to be the main method. It would also address conflict resolution _given_ single server (hard to do in distributed fashion though; the rest of draft seems to argue for loosely synchronized state while I would assert single master + read-only slaves would work better for this model as the ownership claim would be atomic / race-free)
> I thought I'd talked about that.   My idea was to put a key on each record that is used to sign subsequent updates or deletions.   You would lose control of the record if you went offline, however, since the whole name would expire.   I didn’t address that issue in the document.

Ah, perhaps I read through it too rapidly (as the disclaimer said, it was beer-powered sudden review, not really very thorough one).

Cheers,

-Markus