Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt

Tom Pusateri <> Mon, 16 July 2018 01:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91219130F2A for <>; Sun, 15 Jul 2018 18:55:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SiV4RwYjs_qY for <>; Sun, 15 Jul 2018 18:55:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5CCCE1292AD for <>; Sun, 15 Jul 2018 18:55:21 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 404096DF; Sun, 15 Jul 2018 21:53:40 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Tom Pusateri <>
In-Reply-To: <>
Date: Sun, 15 Jul 2018 21:55:18 -0400
Cc: dnssd <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Ted Lemon <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [dnssd] New Version Notification for draft-sctl-service-registration-02.txt
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Jul 2018 01:55:24 -0000

> On Jul 15, 2018, at 4:42 PM, Ted Lemon <> wrote:
> I just submitted an updated version of the service registration document.   If you were planning to read this prior to the meeting and haven't read it yet, you should definitely read the new version.   I think it's more understandable than the old version, but more importantly, it's also more correct.
> This version contains significant updates from the version that Toke reviewed last week.   Things move fast at the IETF...

Some quick feedback on the latest version:

1. You reference mDNS but don’t define it as multicast DNS or reference RFC 6762.
2. Section 2, second paragraph, you mention registering with the default registration domain ("dr._dns-sd._udp”).

	a. You could add Section 11 to the RFC 6763 reference.
	b. You don’t specify if you should use the .local domain or another domain. If it’s another domain, how do you find that domain?
	c. Why do you recommend always using the default registration domain? Couldn’t you get the list of registration domains ("r._dns-sd._udp”) and pick one of those?

3. It’s not clear to me from the document about the TTL values. The life of the registration is handled by the Update Lease Time and the Instance Lease Time. Therefore, I think the document is saying (after talking to Stuart) that the TTL in the registration is the one the client wants the server to use in responses. But the server is keeping the registration for longer than the TTL based on the EDNS(0) Update Lease Option values.

So does the server start the TTL countdown on the first response and then subsequent responses use the decrementing TTL until it times out and then the server resets it to the TTL it received in the register on the next response? This is confusing to me even after talking to Stuart so I”m probably just missing something.

4. Section 3 (security considerations)

You limit the scope of this to within an administrative domain limiting it’s applicability but nowhere else in the document do you convey this. For most of the document, the reader may assume that registrations can be done from anywhere, may wonder why they aren’t encrypted, and then only see in the security section that this is really made for IoT devices and in the home.
I think the name of the protocol should reflect this limited scope instead of using a generic name like Service Registration Protocol since it isn’t designed to be used as a generic unicast service registration protocol. Maybe something like Local Service Registration Protocol or Site Service Registration Protocol or Constrained Service Registration Protocol or something better than I can’t think of right now,