Re: [dnssd] The DNSSD WG has placed draft-sctl-service-registration in state "Call For Adoption By WG Issued"

[Toke Høiland-Jørgensen <[e-mail]>]

Ted Lemon <[e-mail]> writes:

> I just did a somewhat larger-than-expected update to the document to
> capture Toke's comments thus far. I also got a surprise guest review
> from a friend of mine, Tamara Kemper, who revealed a few opportunities
> to make the document clearer and better scoped. In the process of
> doing these two things I noticed that I'd fairly significantly
> misstated how SRV records work and left out some important details.
> The new document fixes all of these things (I hope). Sorry for adding
> so much text during an adoption call, but I didn't want to leave it
> for later because it would have made reading the document kind of
> unpleasant for Stuart, who I hope will review it this weekend, and if
> I hadn't done it now it would have taken at least twice as long later.
> The good news is that I'm pretty chuffed about the quality of the
> document now.

Thanks for the update! I think this version addresses my concerns from
the previous round. :)

A few other comments based on a quick read-through:

- Since registrations are always done with .local, it is up to the
  registration server to decide which domain(s) the registration ends up
  in, right? How is it supposed to do that if servicing multiple zones?
  Just based on source IP?

- The document says that clients must generate their own reverse PTR
  records. Should the server be able to do that on the clients behalf?
  It may be a matter of policy which ranges have reverse domain
  delegations...

- Related to the above, is it permitted for the registration server to
  modify the records submitted by clients before putting them into
  DNS? For example, to add PTR records, or to remove a subset of the
  records etc? The alternative to modifying would be to reject the whole
  registration if a subset is not admissible. If the server *is* allowed
  to modify things, should it communicate back to the client what it
  really did?

- You mention in the text that a network may use a different domain than
  ip6.arpa for reverse PTRs. How does that work? Won't clients always
  do reverse lookups to ip6.arpa?

-Toke