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

Ted Lemon <mellon@fugue.com> Fri, 01 April 2016 13:10 UTC

Return-Path: <mellon@fugue.com>
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 C2E4612D5DD for <homenet@ietfa.amsl.com>; Fri, 1 Apr 2016 06:10:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 TCN6WDSUo6yd for <homenet@ietfa.amsl.com>; Fri, 1 Apr 2016 06:10:42 -0700 (PDT)
Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1B7C12D5D6 for <homenet@ietf.org>; Fri, 1 Apr 2016 06:10:39 -0700 (PDT)
Received: by mail-lf0-x22a.google.com with SMTP id p188so54205728lfd.0 for <homenet@ietf.org>; Fri, 01 Apr 2016 06:10:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0YF3dCV9Xu3H9nyw9VOvXZnm7earkJWdFIOfdKrGerU=; b=F1b1+xOloE3Oqme88iJvwAZQDotCKLNObzs3Okdqim9fYolvpqjRRg9sjpHzUd8iAv xzptACOruXC12ylsbOMLEcQFoZ0qiT2TnBIGwWUflCshJWRZnLllx/c6OIi9wXRJGqaT MZqjFGz1kbM2KBefLm24Hfrt3mY8jUcGC+D3l1Zk/QYQBZkBVCdjbRhEHThxsOYPtprt qEkKrMYTdXU0eV4F5fGsj/F2Ra1YTVE7bEqN1D/1SEIe9JlFtc9dCWCu6tAvkqfLfZX2 OjvUZ6oGhsZo5ZG6EtuPpjUuDOlAUl7pSfA/B3E16CMDLKXLTv5x/7VPB76Qpb1Mr85P rvmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0YF3dCV9Xu3H9nyw9VOvXZnm7earkJWdFIOfdKrGerU=; b=ASb970KJz7r+zNxydBfWOvfgKjWptjMTmdB3HzHsZGZtOIoUj05I54UL/Xs/NFLGyg aCjtquYF5zRZIZIZJYyJpceuQDtZe569nNj+jMxtwARqKi9oPVIvE7jop0icwn7hNiem kew9ycr75py59iW70nVQ3+UEwNkKJGgrdfMGpAdL+FCqcnZOJhrLOihIE7OaQOm3SArj kBeZPeCVUUrGQgl/Pk7eEOAVtgJeTvv0Kb9wYY7vk/OCk5afjoLeFveY36FJEMI/Hxf6 Ljts0ax0gl1HFD177JxMdt5l9X29mmlnDR7jC/UzGdwBt2MNowa6TOmw0heC5EKxcuzc hMyQ==
X-Gm-Message-State: AD7BkJLCQCBujzJrYM2fq+oTRRZHb+dI7NIpDwJ/2US1Erxuyu6CXy86+C4nWLbvswRcRRWRaoE9LOMLqlTaHQ==
X-Received: by 10.25.85.210 with SMTP id j201mr135723lfb.132.1459516237099; Fri, 01 Apr 2016 06:10:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.40.136 with HTTP; Fri, 1 Apr 2016 06:09:57 -0700 (PDT)
X-Originating-IP: [107.77.215.32]
In-Reply-To: <BE7CA248-2B6A-49DF-86A6-142A8A3AE218@iki.fi>
References: <20160323164509.2510.24152.idtracker@ietfa.amsl.com> <CAPt1N1ni-01feyMSaa0-7GhFCXPSS0gPSL8fAzVnhWehih2Pug@mail.gmail.com> <BE7CA248-2B6A-49DF-86A6-142A8A3AE218@iki.fi>
From: Ted Lemon <mellon@fugue.com>
Date: Fri, 1 Apr 2016 09:09:57 -0400
Message-ID: <CAPt1N1k42dw0PN0JFxMcCfi0xc=F4-0QVruB=sHFtkMtvyyvcg@mail.gmail.com>
To: Markus Stenberg <markus.stenberg@iki.fi>
Content-Type: multipart/alternative; boundary=001a1141d826db4b57052f6c1ac3
Archived-At: <http://mailarchive.ietf.org/arch/msg/homenet/n-iSs961ICYUvUONtdxkT3KuxrM>
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 13:10:45 -0000

Thanks for the review Marcus!

On Fri, Apr 1, 2016 at 3:32 AM, Markus Stenberg <markus.stenberg@iki.fi>
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! :)


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


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


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

I tend to agree, but I put it in there for completeness.   Like you, I'm
not sure how it would work on a GP client.  On something like a printer I
think it would be fine, since the set of services to be advertised is known
in advance; that's why I even included it.


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


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

I agree.   However, it is as good as we have with mDNS, so I think it's
okay as a stopgap.   Molto preferito los llaves.


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

Yup.   I think TOFU is a good start.   Anything more than that is going to
require some kind of user interaction.


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

Yes, exactly.


> The draft seems like good start at least.
>

Thanks!   That's all it's meant to be!


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

I am happy to take what I can get. :)

If you have time, I don't think Ralph has called consensus yet.   I
reviewed the hybrid document pretty closely, but my review of the other one
was sketchy.   Mostly because it seems correct and I don't think I disagree
with the overall thrust of it.  But I want to do a closer review on the
flight.


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

Yes.   We are stuck with legacy, but let's not dig ourselves in deeper!