Re: [dnssd] Setting device friendly names

Ted Lemon <mellon@fugue.com> Thu, 21 July 2016 13:52 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB58012D533 for <dnssd@ietfa.amsl.com>; Thu, 21 Jul 2016 06:52:05 -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 igZWiFlnTuyI for <dnssd@ietfa.amsl.com>; Thu, 21 Jul 2016 06:52:03 -0700 (PDT)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 84C3612D516 for <dnssd@ietf.org>; Thu, 21 Jul 2016 06:52:02 -0700 (PDT)
Received: by mail-lf0-x233.google.com with SMTP id g62so62542427lfe.3 for <dnssd@ietf.org>; Thu, 21 Jul 2016 06:52:02 -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=jKa9LL5NABvSoPoF+jcRNCE8inG9UjUxGbZs0SxWyjM=; b=s0Ti9livRmY8dEcOv+nUCGUjZuflktSuPS8mL5mbQlQvBEsXsxk912z6N2X9A9dAy8 fZs+LJey1YyPwd9uOpTBCsNpyf5dmDqFwxsYmbceTUb03B8wtV7rhVK1Eq85vStCUcu8 3bGqmHI5i+7EQHhb1PqublYgBIEEiaZ5OOdkw9/csOG3hgYtDER3aQEczFu9u5XvuOBa JZ0C9ikOK80CC63fy/wRsMnc9OVf3KiskZ/xx4nQav7byg9Mr2WEg6Nn8nGqZpviu79q ZTU412PEl0h4rpyPrxV23ESnP8PXdppgcijl7LL+nWRUzbvutuLRrVCXqRWsyc/mx7TM Shuw==
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=jKa9LL5NABvSoPoF+jcRNCE8inG9UjUxGbZs0SxWyjM=; b=Qcejw2EC3shGtWrbQEHitHIH1YhR5rcrgM+szO/fH1rD3FZgP7BblW+yA2gXNXV8ZU 0CVAnL8c1noybEh0UBhKHWVi5YNKAPCsgvBX0RB7OhVNfTmuj+qnER3hLC1ubdCkY1SR M592wlUQfRmnkpVHYnF+7hev+/q7rttkxT+EFbH1pvgSrwrO3UjzTV96C8O/0k+CCI8n D0gkyquXwzNKcH7ACcEiFJkgbczrMkeAKD88hxAajoY3MpSgEineTh3aeE/JoQPDKkfU qvIWnlR/DwwtiQvR9bqxdT9WYJAc7LOEPiq1B1oFUWwzjka7jXoVoVT//FLSxlUwdErf BoYg==
X-Gm-Message-State: ALyK8tIdbNbRMPUaShbZAJ7Yr2t8eV4f1MgmfXNcoVcCOEPlq+0cns2shMcTocXLX+W9qp6Na7VQK4+ODlJlBQ==
X-Received: by 10.25.42.207 with SMTP id q198mr21462866lfq.181.1469109120636; Thu, 21 Jul 2016 06:52:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.217.93 with HTTP; Thu, 21 Jul 2016 06:51:20 -0700 (PDT)
In-Reply-To: <CAPt1N1nb_s6wQDj=vHd-0z4Po_SmGvmxaRrM_NsaqCt-XOcO2A@mail.gmail.com>
References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> <CAPt1N1mxx=gPY_RtXaDVBXiT750Aq=YiyiOD4mj+CEh0MCT5qw@mail.gmail.com> <AD1ED147-37F0-4276-BC3B-E70072F97EBD@att.com> <B18D9771-8828-42D6-8F89-AC000531C85F@apple.com> <CAPt1N1nPkM2XBi5EapzP7RQmOYNwTWmRuSuD1Y3=JWXmTQcu7w@mail.gmail.com> <E31A479B-02C8-46E0-B507-527C365EB2C1@istumbler.net> <CAPt1N1n99ZmFQuB7X0h3v0eKiaUdDdkHgy--BhvvhfzXQiNVdg@mail.gmail.com> <E6726CEC-D09C-4574-B004-D090C610C735@istumbler.net> <CAPt1N1nb_s6wQDj=vHd-0z4Po_SmGvmxaRrM_NsaqCt-XOcO2A@mail.gmail.com>
From: Ted Lemon <mellon@fugue.com>
Date: Thu, 21 Jul 2016 15:51:20 +0200
Message-ID: <CAPt1N1m=C5hjmB9Wn3ExzsUmr1SgsujO8NhFjv46uf==GqoPNw@mail.gmail.com>
To: Alf Watt <alf@istumbler.net>
Content-Type: multipart/alternative; boundary="001a11411dba45afdd0538259f2c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/-ITF0U3X_a_4XHhWmQa5xtpx-I4>
Cc: Stuart Cheshire <cheshire@apple.com>, dnssd@ietf.org, "STARK, BARBARA H" <bs7652@att.com>
Subject: Re: [dnssd] Setting device friendly names
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jul 2016 13:52:06 -0000

One option, by the way, would be to simply pop up some kind of warning if a
two devices come on the network with the same name, and leave it to the
user to fix it (or not).

On Thu, Jul 21, 2016 at 3:50 PM, Ted Lemon <mellon@fugue.com> wrote:

> Right, the security model for having "the network" change the device's
> name is wrong.   That doesn't mean it's not a problem that needs to be
> solved.   It may indeed be that there is no point in trying to address it
> in homenet; I would certainly agree that it's not a high priority.   The
> main reason it's of interest at all is for resolving name collisions.
>
> In that sense, we _do_ have a way of making the device change its name--we
> just don't get the opportunity to suggest a new name for it.
>
> On Thu, Jul 21, 2016 at 3:48 PM, Alf Watt <alf@istumbler.net> wrote:
>
>> Not have I, which seems suggestive: the feature has at least two proposed
>> methods (UPnP and DHCPv4) and neither has been widely implemented in
>> clients.
>>
>> It appears that clients which the IT staff doesn't already control do not
>> want the network to be able to choose their name. I expect for the
>> usability reasons already discussed: if the name is changed the user will
>> have to learn the new name somehow.
>>
>> One other common method of host name configuration which hasn't come up
>> is configuration profiles, which can automate away having (or allowing) the
>> user to set the host name (or have one generated for them in setup).
>>
>> Best,
>> Alf
>>
>> On Jul 21, 2016, at 6:13 AM, Ted Lemon <mellon@fugue.com> wrote:
>>
>> I have never seen a host that would accept an unauthenticated hostname
>> update from a DHCP server.
>>
>> On Thu, Jul 21, 2016 at 3:10 PM, Alf Watt <alf@istumbler.net> wrote:
>>
>>> Don't forget, good ol DHCPv4 provides option 12 for setting host names
>>> by the server:
>>>
>>> https://tools.ietf.org/html/rfc2132
>>>
>>> Support will depend on the client respecting the option, which at least
>>> some Linux distributions don't seem to out of the box.
>>>
>>> The option wasn't included (even for the more common case of the client
>>> requesting a name from the server) in DHCPv6, which suggests using DDNS for
>>> allowing the host to update the name after auto-configuration.
>>>
>>> http://www.ietf.org/rfc/rfc3315.txt
>>>
>>> Best,
>>> Alf
>>>
>>> On Jul 21, 2016, at 3:51 AM, Ted Lemon <mellon@fugue.com> wrote:
>>>
>>> I think the point Barbara is making about consistency is right, and that
>>> we may be in violent agreement. :)
>>>
>>> In general there are devices that you'd like to be able to configure
>>> using the network, and devices that you definitely do not want configured
>>> by the network.
>>>
>>> On Jul 21, 2016 12:31, "Stuart Cheshire" <cheshire@apple.com> wrote:
>>>
>>>> On 21 Jul 2016, at 02:54, STARK, BARBARA H <bs7652@att.com> wrote:
>>>>
>>>> > UPnP SSDP announcements include a friendly name in the SSDP header.
>>>> To me, this is comparable to the instance name in DNS-SD / mDNS. And
>>>> comparable to a NetBIOS name.
>>>>
>>>> Yes. I don’t know any service discovery protocol that *doesn’t* have
>>>> “friendly names”.
>>>>
>>>> The question was about a ubiquitous protocol for *setting* the
>>>> “friendly name” that’s universally supported on (virtually) all devices.
>>>>
>>>> > When I ask my router for a list of hosts on the network, and when I
>>>> ask my BluRay player to show me a list of content sources (UPnP), the lists
>>>> use the same names for devices (because these devices use the same name
>>>> across protocols).
>>>>
>>>> If one computer shares two USB printers on the network, do both shared
>>>> printers have to appear with the same name (the same as the name of the
>>>> computer that’s sharing them)? Restricting services to
>>>> one-instance-per-host is quite limiting.
>>>>
>>>> <https://tools.ietf.org/html/rfc6760#section-3.3> Address Services,
>>>> Not Hardware
>>>>
>>>> > Yes, there is also a UPnP Service defined that allows for remotely
>>>> changing the friendly name.
>>>> https://openconnectivity.org/upnp/specifications/friendlyinfoupdate1.
>>>> But this service was only published in 2014 (long, long after the UPnP
>>>> Device Architecture required "friendly name" in SSDP advertisements), it is
>>>> not widely implemented (not mandatory to implement)
>>>>
>>>> Do you personally own *any* device that supports this? I know the
>>>> “standard” exists. My question was how many products actually implement it.
>>>> The world is full of so-called “official standards” that no real-world
>>>> products implement.
>>>>
>>>> > FWIW, UPnP is an ISO/IEC standard.
>>>>
>>>>
>>>> Yes, a great example: OSI networking.
>>>>
>>>> Stuart Cheshire
>>>>
>>>> _______________________________________________
>>> dnssd mailing list
>>> dnssd@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>
>>>
>>
>