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

[Tom Pusateri <[e-mail]>]

Thanks for the quick response.

> On Jul 15, 2018, at 10:18 PM, Ted Lemon <[e-mail]> wrote:
>  
>         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?
> 
> We specify that you should discover the default registration domain and use that.   It sounds like this wasn't sufficiently clear, though.  :)

To discover the default registration domain, you need a domain in the query: dr._dns-sd._udp.<domain>

domain could be .local or it could be something else. You don’t specify what to use here.
 
> 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.
> 
> Yes, TTL and leases are completely different things.
>  
> 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.
> 
> TTLs are used by caches.   The server always sends the same TTL.

Ok. Should there be any checking on the server to make sure the TTL is valid from the client. The only advice is make sure the TTL is the same for every record in the RRset. Should the server make sure it is <= to the lease lifetime or any other checks instead of just blindly accepting the value from the client? If the TTL value is greater than the lease lifetime, what error should the server return for the registration?
 
>  
> 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,
> 
> I don't see the point in this.   If we want to make it possible to register services from outside of the administrative domain, we can add an extension to do that, but it doesn't really make sense to have a service registration protocol that takes the place of an administrator, but that spans administrative domains.   If we had an authenticated service registration protocol, it would just be this protocol plus some additional stuff to allow enrolled devices to register when not local.   So I think making the base spec have a name that is limiting in this way would send exactly the wrong message.

I disagree. By admitting you need an extension, you are proving my point.

Thanks,
Tom