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

[Tom Pusateri <[e-mail]>]

> On Jul 16, 2018, at 8:59 AM, Tom Pusateri <[e-mail]> wrote:
> 
> The TTL addition still leaves ambiguity for the server implementation:
> 
> "Service Registration servers SHOULD ensure that TTLs are reasonable: neither too long nor too short.  The TTL should never be longer than the lease time.”
> 
> Can you give guidance for “too short”? “too long” seems to be > lease time. If this isn’t what you mean by “too long”, guidance on that would be appreciated too.
> 
> And finally, if the TTL is “too long” or “too short”, how does the server respond? Does the server accept the registration and modify the TTL? Does the server reject the registration and return an error? What error code?

May I suggest that the server adjusts the TTL to a reasonable value (guidance) and returns the new value in the response.

Then the client can know for the future what is a more acceptable value and adjust future registrations 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?

Section 2.3.3:

'To do so, it must discover default registration zone’   ——> insert ‘the’

Section 2.4.2 Page 9:

change “rejectration” to “registration”.

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

Thanks,
Tom