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

Ted Lemon <mellon@fugue.com> Fri, 15 April 2016 15:40 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 9BD6112DDDF for <homenet@ietfa.amsl.com>; Fri, 15 Apr 2016 08:40:46 -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 iYy_E327g9L2 for <homenet@ietfa.amsl.com>; Fri, 15 Apr 2016 08:40:44 -0700 (PDT)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 0D09212E21D for <homenet@ietf.org>; Fri, 15 Apr 2016 08:40:44 -0700 (PDT)
Received: by mail-lf0-x236.google.com with SMTP id e190so150177045lfe.0 for <homenet@ietf.org>; Fri, 15 Apr 2016 08:40:43 -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=w+uOqwqz1O+RChxJJpHdYWwyvg1cvRmbylNIdZvxE10=; b=T1i43TyDVnyz/MSOj1PuLNm4GJc5FFw3nU2w/T7tRf/2v0MsLuuOhz5yvown9ErKJQ P3NLGCZucTt0M4mxZyFXK/bGrA9MbNnWZsBreZ+Om33BjI6mqL1eXOHWSc+3N8vOJ47M f4nx1SfEw8pC03J6dNq1L/AlT1G/KPLiwZNSwwOf8NMWOypyyZj2lOR1H1FeYrzxkiGQ TOv5P/mvnRtkq79WWl5bidcYq1Job8M3NdJIHkG/MXB5CQuMWYQekTOqZCtfbppUGhVW IL+kBMLJ/a/0aStHTMZ2U2nF8Fm8qSsI1r4xBEBgFIRxbszG46lXkspX1cwyc7WutnEb e/Hg==
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=w+uOqwqz1O+RChxJJpHdYWwyvg1cvRmbylNIdZvxE10=; b=ANJOdAso13/X5kVgJd4knfB+BCI2ebXI/D0bs8wDEsqdAoRLfkg3AtwPBSnP0e1ldO N8bPCvQtxOsy6YBvpccvdeGSRF8CdtMnolQgeFsvpkr7RZjZjXMZhs5Fdb0abaBFgzMp nn6HB6vNiUmezBPBgPCpkqMpQ8DF1kdzsHx8eAPR+Kq4TOYw0sGxVJoN6DaNQwJ9L3PB VzIooGlL6Oow4sZdD9INQ67v8FzTvmXKYtU/QosNIujrZIP29beccqeIYCtS+gtbNQBF EG0rMIWQ4i+Id5RudC++l6A6izJQJFnfB+/3wqJWiRH6RHueQARJ3mEHVBIyBExXKHJp bkxg==
X-Gm-Message-State: AOPr4FU3n4Uo01kE8El5WAVaKa5evb1slCRLqmyyvu/1vboMRIV7DLStFTAbsULN7RXskVBBFhaNfFMp5EXfTQ==
X-Received: by 10.25.153.136 with SMTP id b130mr8947895lfe.53.1460734841259; Fri, 15 Apr 2016 08:40:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.213.19 with HTTP; Fri, 15 Apr 2016 08:40:00 -0700 (PDT)
X-Originating-IP: [71.233.41.235]
In-Reply-To: <8A8B70E7-DE26-4F94-9B15-E5E8BC94B930@iki.fi>
References: <20160323164509.2510.24152.idtracker@ietfa.amsl.com> <CAPt1N1ni-01feyMSaa0-7GhFCXPSS0gPSL8fAzVnhWehih2Pug@mail.gmail.com> <BE7CA248-2B6A-49DF-86A6-142A8A3AE218@iki.fi> <CAPt1N1k42dw0PN0JFxMcCfi0xc=F4-0QVruB=sHFtkMtvyyvcg@mail.gmail.com> <8A8B70E7-DE26-4F94-9B15-E5E8BC94B930@iki.fi>
From: Ted Lemon <mellon@fugue.com>
Date: Fri, 15 Apr 2016 11:40:00 -0400
Message-ID: <CAPt1N1mvEEeC8eeW5byUydgfr6c70DTQecYDOqmbQsw=FzE7Xw@mail.gmail.com>
To: Markus Stenberg <markus.stenberg@iki.fi>
Content-Type: multipart/alternative; boundary=001a114039266270ce053087d5b3
Archived-At: <http://mailarchive.ietf.org/arch/msg/homenet/Q0fJXkCLiPe-WszAnckukVEo5aE>
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, 15 Apr 2016 15:40:46 -0000

On Fri, Apr 15, 2016 at 3:04 AM, Markus Stenberg <markus.stenberg@iki.fi>
wrote:

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

Ah, thank you.   No, the error was on my part--I was aware that that had to
work, but wrote the document in a way that doesn't really allow it to
work.  I will come up with a better way to express this.   Thanks for
helping me to see this omission!


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

I agree in general, but there is a slight clarification: the question I'm
asking is not "should all devices registered locally appear globally by
default," but rather, "are there some devices for which the correct
behavior is that they appear globally by default."   My knee-jerk reaction
is the same as yours: no way.   However, I think it's worth exploring the
question.


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

No worries.   Perhaps I will be able to coax you to read the -01 with or
without beer goggles.   :)