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

[Ted Lemon <[e-mail]>]

OIC, you mean which domain should be used to discover the default
registration domain?

Is this better?
https://github.com/StuartCheshire/draft-sctl-service-registration/commit/327f3fef292731951c8cc8746b6880f3e13f2e43

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

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