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

[Ted Lemon <[e-mail]>]

On Sun, Jul 15, 2018 at 9:55 PM, Tom Pusateri <[e-mail]> wrote:

> Some quick feedback on the latest version:
>
Thanks! :)


> 1. You reference mDNS but don’t define it as multicast DNS or reference
> RFC 6762.
>

We do reference RFC6762 in the introduction, but you're right that we don't
introduce the term properly.


> 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.
>

Good point, thanks.


>         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.  :)


>         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?
>

This is an automatic protocol, so that would have to be configured.   Once
it has to be configured, then it doesn't matter whether it uses the list of
registration domains or not, although certainly one way to make this work
would be to have a UI that presents that list and allows the user to choose
one entry.


> 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.


> 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.