Early Review of draft-ietf-dnssd-mdns-dns-interop-04
review-ietf-dnssd-mdns-dns-interop-04-opsdir-early-schoenwaelder-2017-03-08-00

Disclaimer: I regret that DNS does not use UTF-8 in its labels, to me
, as an outside observer, it seems IDNA was a big mistake. But given
the IETF standards we have, it seems one has to properly IDNA encode
UTF-8 in DNS labels. (As an outsider, I am puzzled by documents that
say that for some portions of the DNS name hierarchy this is not true
and it is left vague how to precisely determine where in the namespace
IDNA has to be used and where not.)  So now that you understand my
ignorance, I hope you understand what follows below may just be plain
wrong...

In section 2, I do not understand this statement:

   The greater problem is that the "infrastructure" types of DNS service
   -- the root zone, the top-level domains, and so on -- have embraced
   IDNA and refuse registration of raw UTF-8 into their zones. As of
   this writing there is (perhaps unfortunately) no reliable way to
   discover where these sorts of DNS services end.

Not sure what this is trying to convey. Are you saying that using
plain UTF in DNS labels is OK if it is far enough from the root?  Why
would that be? I looked up RFC 6055 and I am surprised to read text
about 'intelligent (stub) resolver' there as this seems to be asking
for trouble. To me, it sounds like you are saying 'some portions of
the name hierarchy may use raw UTF-8 labels while other portions may
not and we do not tell you how to set them appart in a reliable
way'. If this is the approach, then the approach is in my personal
view broken. (And please recall the disclaimer above.)

In section 3, what does the term 'implicated' mean?

What I do not understand: Why is it desirable to treat DNS labels that
carry DNS-SD Service Instance Names different than any other labels
that may contain UTF-8 characters? If the IETF believes IDNA is the
solution for the DNS, why do we then not also use IDNA for UTF-8
DNS-SD Service Instance Names? Yes, there will be some names that will
be impossible to use but then services in the DNS (as opposed to mDNS)
are likely more infrastructure services and less so end use provided
services. And at the end, the limitation is the result of the DNS /
IDNA approach, so you get what you asked for. (Again, please recall
the disclaimer).

Back to my role as ops-dir reviewer: This document is more a kind of a
problem statement document, I do not see direct operational impact.
The trouble with DNS labels is more likely a user facing issues than
it is a network operational issue (except perhaps for helpdesk
functions, in particular in enterprise networks).

Bottom line: I am the wrong reviewer for this document. I think the
authors should specifically seek reviews and comments from people
active in the DNSOP working group.