Telechat Review of draft-ietf-dnssd-mdns-dns-interop-04
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:
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
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
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?
Finally one nit: expand LDH on first use.