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

Ted Lemon <> Fri, 01 June 2018 00:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41134124205 for <>; Thu, 31 May 2018 17:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 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_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yZwZyriA-E9c for <>; Thu, 31 May 2018 17:39:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c0f::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EDE441241F5 for <>; Thu, 31 May 2018 17:39:55 -0700 (PDT)
Received: by with SMTP id i5-v6so27438893otf.1 for <>; Thu, 31 May 2018 17:39:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4K27RvMDm1/RTD8ztl/C6X8BdyvsDMT7WDRfx6ryVr4=; b=s7PNT0X2oOcGubSJY0jjEY5nst+/DfsuT2L81JAj+cWtD3VvawSL5bWHvGfCM+31xU fs86CbmP4skhBT070AbG2hjOi+fYXE6xDzBYvLV0qSz1C/SuaFjLlnJmn6uYbOrg8bKj UypoG/7g6WAJEmLi2BiW+b+KaeYvPHYuO4dYuOR+TLjrG91LIPX/yXlg0pdTf+x37oEg T9YhGtQgFd7xso5SvuVuVfK1EMMSE2IbnFnnIiAOuXD1Ou+w4IEfe4h8ZorexBinbRCn 3dMGzACVYrgFz6VGJKJBrifxZJVPZgd2Z6wGsDk+QLkk+hNpLyrTmKqtojhAFOWUiP4x Crhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4K27RvMDm1/RTD8ztl/C6X8BdyvsDMT7WDRfx6ryVr4=; b=Y/r+wuErpCOiVq+RtRlfRZEKUGMukGMkH/fLE1J8tEakYgE6EwUMlWW8VU40ifYKOs VPhc6bqJD1NK99Uqn7L1vmvgr85Pr9+qDeK1K6zK+QDJvSt+juMAexW1dCliGp0R6SHq 0TxAe8LeeseQvfCI9+yP7WwFnSvYgbdHLOzViRz5TaKmOsuyU9/Ax0doJSVdXIylTVBT jMkAhZ6+EdrST/PtGUxSeyhlX/TmOiEaaThGgCLLOzV+NcEdCn1l/IZfW6zzIg8X+N5A osZ8Ch0OEjGrlknFGTrO1VTubTLuMPnruxkH80L+NNPlRLsVAPAww0UmCdNODspe+wbh KsdQ==
X-Gm-Message-State: ALKqPwd83Cu8sLrvVUTSp+ovowE2VxDjJiU1edtixdGyHedvmRlSdk0F wr14dyH2gBBi1vcYb+SBlOfP6YnStjs=
X-Google-Smtp-Source: ADUXVKIrsA1gLY6NGMUGiM4Rq/qJu3PqOlKtukL3+fPcN34Ds2bJAxRFeGeSsaTJWXKIlTZkCsFUoA==
X-Received: by 2002:a9d:3df4:: with SMTP id l107-v6mr5717684otc.73.1527813595115; Thu, 31 May 2018 17:39:55 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id e132-v6sm20431972oia.58.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 May 2018 17:39:54 -0700 (PDT)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_809B557B-15DA-4E1C-B76A-D2A7193545CA"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Thu, 31 May 2018 17:39:51 -0700
In-Reply-To: <>
To: Michael Thomas <>
References: <> <> <> <> <10568.1527686230@localhost> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <>
Subject: Re: [homenet] Introduction to draft-ietf-homenet-simple-naming
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Homenet WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Jun 2018 00:39:58 -0000

On May 31, 2018, at 4:27 PM, Michael Thomas <> 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.

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.

When I talk about UI, I'm really talking about the API behind the UI.   Having a management API for homenet would be a good thing.   Possibly it could just be done with HNCP.