Skip to main content

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

Request Review of draft-ietf-dnssd-mdns-dns-interop-04
Requested revision 04 (document currently at 04)
Type Early Review
Team Ops Directorate (opsdir)
Deadline 2017-03-15
Requested 2017-02-28
Requested by Terry Manderson
Authors Andrew Sullivan
I-D last updated 2017-03-08
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
I would like this document reviewed for;

Internet area: focus on impacts related to internet technologies

IoT Directorate: Look for and highlight any issues that might be raised for IoT devices in this interop,

Ops: Are there any DNS operational implications to Label interop that should be raised.
Assignment Reviewer Jürgen Schönwälder
State Partially completed
Request Early review on draft-ietf-dnssd-mdns-dns-interop by Ops Directorate Assigned
Reviewed revision 04
Result Not ready
Completed 2017-03-08
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

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.