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

[Ted Lemon <[e-mail]>]

Here are some proposed fixes to the issues you've raised:
https://github.com/StuartCheshire/draft-sctl-service-registration/commit/f532e4aee9aaae8f1fccc104df8ea12c450bc0ab

On Sun, Jul 15, 2018 at 10:18 PM, Ted Lemon <[e-mail]> wrote:

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