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

Markus Stenberg <markus.stenberg@iki.fi> Fri, 01 April 2016 07:32 UTC

Return-Path: <markus.stenberg@iki.fi>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8212112D183 for <homenet@ietfa.amsl.com>; Fri, 1 Apr 2016 00:32:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.821
X-Spam-Level:
X-Spam-Status: No, score=-1.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27WrN1H3HlEo for <homenet@ietfa.amsl.com>; Fri, 1 Apr 2016 00:32:42 -0700 (PDT)
Received: from johanna3.inet.fi (mta-out1.inet.fi [62.71.2.199]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8CD12D0E6 for <homenet@ietf.org>; Fri, 1 Apr 2016 00:32:41 -0700 (PDT)
RazorGate-KAS: Status: not_detected
RazorGate-KAS: Rate: 0
RazorGate-KAS: Envelope from:
RazorGate-KAS: Version: 5.5.3
RazorGate-KAS: LuaCore: 80 2014-11-10_18-01-23 260f8afb9361da3c7edfd3a8e3a4ca908191ad29
RazorGate-KAS: Lua profiles 69136 [Nov 12 2014]
RazorGate-KAS: Method: none
Received: from poro.lan (80.220.86.47) by johanna3.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as stenma-47) id 56F3C8C900981B9D; Fri, 1 Apr 2016 10:32:39 +0300
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Markus Stenberg <markus.stenberg@iki.fi>
In-Reply-To: <CAPt1N1ni-01feyMSaa0-7GhFCXPSS0gPSL8fAzVnhWehih2Pug@mail.gmail.com>
Date: Fri, 1 Apr 2016 10:32:38 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <BE7CA248-2B6A-49DF-86A6-142A8A3AE218@iki.fi>
References: <20160323164509.2510.24152.idtracker@ietfa.amsl.com> <CAPt1N1ni-01feyMSaa0-7GhFCXPSS0gPSL8fAzVnhWehih2Pug@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/homenet/k1_RRR67ZTHiC1_lxFx-jhh089k>
Cc: homenet@ietf.org
Subject: Re: [homenet] I-D ACTION:draft-lemon-homenet-naming-architecture-00.txt
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Apr 2016 07:32:44 -0000

I have partially browsed through the draft. For the record, I am not big fan of the hybrid solution either as I consider the whole mdns rather ‘loud’ on the link, and hybrid just makes the solution worse by causing the spam to occur across multiple links. It is working solution _given current stuff_ though, which I am not sure can be ignored[1].

So, to comments about some parts of the draft:

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.

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?).

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. 

Section 2.4.2: I think adding service registration to DHCP would be a mistake. (Wrong level in typical implementation stack, as it is not really tied to network configuration but instead property of applications; one _could_ do it but I find it non-desirable.)

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)

Section 2.5: Not fan of using just IP address for authentication, instead, see above.

Section 3.6: TOFU is usually better than nothing at least..

Section 4.6: We got some (user) feedback that ULA should be preferred over GUA as GUA can go away, disrupting in-home stuff unneccessarily. (Obviously not mosh user.)

The draft seems like good start at least. 

Disclaimer: I didn’t quite read all of it as I am mostly just browsing through everything going on at the moment (and wondering if I should react to the dnssd WGLCs that already expired while I was on vacation, grumble.)

Cheers,

-Markus

[1] The classic argument ‘for’ hybrid are e.g. historic printers. However, I am pretty sure e.g. first-hop router could proxy-DNSSD-register them to DNS and mDNS could be just let rot in practise. (Later addition: Oh.  Section 2.4.1 covers this to some degree already.)