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 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 from and , when the previous paragraphs seem to make it clear that one can clearly identify . Is this because one might envision naked octets that begin with underscore in either the or 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