Re: [homenet] Introduction to draft-ietf-homenet-simple-naming

Michael Thomas <mike@mtcc.com> Fri, 01 June 2018 00:59 UTC

Return-Path: <mike@mtcc.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 8E896124234 for <homenet@ietfa.amsl.com>; Thu, 31 May 2018 17:59:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.1
X-Spam-Level:
X-Spam-Status: No, score=-1.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 roePKFtQKXat for <homenet@ietfa.amsl.com>; Thu, 31 May 2018 17:59:22 -0700 (PDT)
Received: from mtcc.com (mtcc.com [50.0.18.224]) (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 38B14124205 for <homenet@ietf.org>; Thu, 31 May 2018 17:59:22 -0700 (PDT)
Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.15.2/8.14.7) with ESMTPSA id w510xLd9004683 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 31 May 2018 17:59:21 -0700
To: Ted Lemon <mellon@fugue.com>
References: <CAPt1N1kcuDBxK1=RN=_Q4YM7L_-YDNaEt4WS-sh2YDeJgvMgRw@mail.gmail.com> <20180528180538.GF12038@mx4.yitter.info> <CADZyTkmAc+CUdFxaur=qfFagtrUx64vv7QGFocgdHM1rXqJB7Q@mail.gmail.com> <762d4d6d-38d3-05ac-7cd6-fc87b2f1b042@gmail.com> <10568.1527686230@localhost> <29be80e3-bd65-bcd3-5db2-c2ef0a084f12@gmail.com> <37902D77-2528-4D9E-815A-DFF83905EB83@fugue.com> <8736y8hnll.wl-jch@irif.fr> <355c2773-efb5-20ce-f813-2fcd48470543@gmail.com> <1F6977CE-A176-432C-85EC-92CDACA71C02@orandom.net> <35df1f70-c900-501e-7014-eae265d8ebdf@gmail.com> <CAPt1N1nHMS42F9Qke8wWHhTSF_Szr9AGao+ZxftwDavZAkztCQ@mail.gmail.com> <69d6999b-af05-c38d-56e2-6f391f6bcf05@mtcc.com> <CAPt1N1=s+x26pPk2-kP7vgHMs6R=0zG6ZoXevKymbf1EwbqTMw@mail.gmail.com> <a75e515f-0d67-10c4-326a-0c4f70d8b888@mtcc.com> <CB6C0B26-CF8C-4713-94F0-86F06819FF3C@fugue.com>
Cc: HOMENET <homenet@ietf.org>
From: Michael Thomas <mike@mtcc.com>
Message-ID: <eeb322ba-b172-418c-d9df-0971519bc668@mtcc.com>
Date: Thu, 31 May 2018 17:59:21 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <CB6C0B26-CF8C-4713-94F0-86F06819FF3C@fugue.com>
Content-Type: multipart/alternative; boundary="------------D2CAC90E0568F97BDFBED675"
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/yLOySN8UGqQKwwXwf72nLxY-f1U>
Subject: Re: [homenet] Introduction to draft-ietf-homenet-simple-naming
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.22
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 Jun 2018 00:59:25 -0000

On 05/31/2018 05:39 PM, Ted Lemon wrote:
> On May 31, 2018, at 4:27 PM, Michael Thomas <mike@mtcc.com 
> <mailto:mike@mtcc.com>> wrote:
>> With a CNAME, you wouldn't need to deprecate the other... it's just 
>> an alias that you have control of.
>> From the UI perspective, whatever is presenting names to the user can 
>> prefer the human-given name over
>> the auto-generated name, right? We wouldn't need to standardize 
>> anything then.
>
> Michael, I don't think you've really understood the issue here.   Let 
> me try and explain it all at once, since the explanation was actually 
> scattered across several messages.
>
> There are two pieces to this.   First, there's the thing that 
> publishes the name.  That's DNSSD.   There's no problem with that end 
> of things.   If you change the name, the device just appears with its 
> new name, and everything is fine. That's our piece of the puzzle, and 
> it already works.
>
> The problem is that hosts tend to remember names. On MacOS, for 
> instance, if you configure a printer, the host remembers the printer 
> forevermore.   It's no problem to configure a new printer, but if you 
> change the name that the printer advertises, there will be a stale 
> configuration on the host pointing to the old name, and the user will 
> have to configure a new printer to get access to the old printer.
>
> So what we are talking about here actually /breaks/ DNSSD's good 
> behavior.   We don't want DNSSD to publish two names.   We don't want 
> DNSSD to publish a CNAME.   That would just be extra garbage that 
> would have to be maintained forever.

No, no, no. That's not what i meant. I'm saying that a authoritative 
server can create a CNAME based on the DNSSD name
which is the pretty name. So that when i type pretty-name.myhome.net 
it's really pointing to ugly-name.

>
> What we want is a way for the host to notice that the device's name 
> has changed.   We want the device to have some identity other than the 
> name that doesn't change when the name changes.   And we actually have 
> this in the registration protocol, which is another draft being 
> published in the DNSSD working group.   That protocol has the host 
> generating a public/private key pair, and using the public key as an 
> identity.   It uses this identity to claim the name, but it wouldn't 
> be that much work to also specify that hosts should use that 
> identifier to notice that a device has a new name and update the name 
> in the user interface.

What I'm thinking is that i plug something into my homenet, and i name 
it. I could do that by logging into the device itself,
but creating a CNAME gives me some flexibility in that i don't have to 
deal with its crappy interface, and survives when i throw
it in the trash. If it's normal DNS, it doesn't matter how/why the CNAME 
was created, it just works.

Mike