Early Review of draft-ietf-dnssd-mdns-dns-interop-04
|Team||Ops Directorate (opsdir)|
|Requested by||Terry Manderson|
Intdir Early review of -04 by Bernie Volz
Iotdir Early review of -04 by Ines Robles
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.
|Review result||Not Ready|
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.