Telechat Review of draft-ietf-dnssd-mdns-dns-interop-04
review-ietf-dnssd-mdns-dns-interop-04-artart-telechat-lear-2017-05-01-00
Request | Review of | draft-ietf-dnssd-mdns-dns-interop |
---|---|---|
Requested revision | No specific revision (document currently at 04) | |
Type | Telechat Review | |
Team | ART Area Review Team (artart) | |
Deadline | 2017-05-23 | |
Requested | 2017-04-23 | |
Authors | Andrew Sullivan | |
I-D last updated | 2017-05-01 | |
Completed reviews |
Intdir Early review of -04
by Bernie Volz
Iotdir Early review of -04 by Ines Robles Opsdir Early review of -04 by Jürgen Schönwälder Genart Last Call review of -04 by Robert Sparks Secdir Last Call review of -04 by Sean Turner Artart Telechat review of -04 by Eliot Lear |
|
Assignment | Reviewer | Eliot Lear |
State | Completed | |
Request | Telechat review on draft-ietf-dnssd-mdns-dns-interop by ART Area Review Team Assigned | |
Reviewed revision | 04 | |
Result | Ready w/issues | |
Completed | 2017-05-01 |
review-ietf-dnssd-mdns-dns-interop-04-artart-telechat-lear-2017-05-01-00
Well written and comprehensive. Just a few comments. First, the use of "rejected" several times in the document leads one to conclude that the WG is making design decisions at this time for input into the next document. Combined with when the profile is applicable, and its rough outline, one gets the impression of a first step towards its writing. Stating the audience and next steps would help the reader. Second, in Section 4.3, ppg 7-8, the following sentence: ... DNS-SD implementations ought somehow to identify the <Domain> portion of the Service Instance Name and treat it subject to IDNA2008 in case the domain is to be queried from the global DNS. The sentence implies that it will not be easy to separate <Domain> from <Instance> and <Service>, when the previous paragraphs seem to make it clear that one can clearly identify <Service>. Is this because one might envision naked octets that begin with underscore in either the <Domain> or <Instance> sections? If so, it might be worth reiterating that. Third, while one might say that the fundamental issue has to do with processing of labels in some form versus not doing so, most of the document is spent on the case of IDNA2008 v. LDH v. naked UTF8. The abstract really should probably state that up front. Similarly, the impact to both deployments and implementations should be tersely summarized. The key callouts to me are suggestions as to when to perform IDNA2008 processing and when to not do so, potential restriction of character sets, etc. Fourth: the following sentence leads to a question: A practical consequence of this is that zone operators need to be prepared not to apply the LDH rule to all labels. The implication here is that zone operators make this decision. I *think* what we are talking about here are user interfaces, no? BIND handles this just fine, right?[1] Finally one nit: expand LDH on first use. Eliot [1] http://www.dns-sd.org/servertestsetup.html