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

[Ted Lemon <[e-mail]>]

On Mon, Jul 16, 2018 at 2:47 PM, Tom Pusateri <[e-mail]> wrote:
>
> May I suggest that the server adjusts the TTL to a reasonable value
> (guidance) and returns the new value in the response.
>

I don't think this is important.   What behavior on the client would change
on the basis of this guidance?   The client doesn't necessarily know which
server it's talking to, so the advisory TTL value, if retained, might be
considered wrong next time it sends an update. strations with this server.

>
> New Feedback
> ——————————
>
> Section 2 says:
>
> 'In other network environments, updates for names ending in
> "services.arpa" may be rewritten internally to names with broader
> visibility.’
>
> And Section 2.2 says:
>
> ‘...and let the DNS-SD Service Registration server handle rewriting that
> to a different domain if necessary.’
>
> When the registration server rewrites the domain, does it send the new
> domain back in the response? I couldn’t find that anywhere in the document.
> Does it have to send back all of the records in the request? Can it send
> just a header if the Zone doesn’t change and the TTL doesn’t change? Can it
> only complete the Zone section if the zone name changes but the TTL stays
> the same with nothing changes in the Update section?
>

We concluded that it does not.   The only case where this happens now is
for constrained devices, and constrained devices shouldn't care.


> Section 2.3.3:
>
> 'To do so, it must discover default registration zone’   ——> insert ‘the’
>
thanks.


>
> Section 2.4.2 Page 9:
>
> change “rejectration” to “registration”.
>
Done.


>
> Throughout the document "DNS-SD Registration Protocol” is used
> synonymously with "DNS-SD Service Registration Protocol”. If the latter is
> too many words, you might substitute ‘this specification’. This becomes
> even more confusing with the discussion of service registration protocols
> in RFC 6763 such as:
>         "Service discovery requires a service registration protocol. DNS
> already has one: DNS Dynamic Update.” and
>         "This also requires some service discovery registration protocol
> to be implemented and deployed for clients to register with the central
> aggregation server.  Virtually every company with an IP network already
> runs a DNS server, and DNS already has a dynamic registration protocol.”
> This provides additional motivation for a new name.
>
> “Registrations” is capitalized lots of places where it probably shouldn’t
> be: "Ordinarily Registrations will fail…”
>

Yeah, I went through the document and noticed that there was a huge amount
of inconsistent use of terminology.   I updated the document to use SRP
instead of the various permutations of DNS-SD Service Registration
Protocol, SRP Server for the various permutations of Registration server,
and SRP update instead of Registration.