Skip to main content

Telechat Review of draft-ietf-dnssd-mdns-dns-interop-04

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

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.