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

[Tom Pusateri <[e-mail]>]

> On Jul 15, 2018, at 4:42 PM, Ted Lemon <[e-mail]> 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,

Thanks,
Tom