[Top] [All Lists]

Re: [dnssd] Last Call: <draft-ietf-dnssd-mdns-dns-interop-04.txt> (On Interoperation of Labels Among Conventional DNS and Other Resolution Systems) to Informational RFC

2017-04-13 00:53:42
On 30 Mar 2017, at 14:10, The IESG <iesg-secretary(_at_)ietf(_dot_)org> wrote:

The IESG has received a request from the Extensions for Scalable DNS
Service Discovery  WG (dnssd) to consider the following document:
- 'On Interoperation of Labels Among Conventional DNS and Other
  Resolution Systems'
 <draft-ietf-dnssd-mdns-dns-interop-04.txt> as Informational RFC

Overall I think this document is very good.

Re-reading draft-04 today, I have a few minor comments.

Page 3:

Users and developers of applications are, of course, frequently
unconcerned with (not to say oblivious to) the name-resolution
system(s) in service at any given moment

Does “not to say” mean “not oblivious” or “oblivious”?

It would be clearer to say:

Users ... are, of course, frequently unconcerned with (but not oblivious to) 


Users ... are, of course, frequently unconcerned with (or even oblivious to) 

Page 3:

As a result, the same domain name might be tried using different name 
resolution technologies.

Any given name may only be looked up using the single name resolution 
technology appropriate for that name.

It might be clearer to say:

As a result, names entered into the same domain name slot might be resolved 
using different name resolution technologies.

Page 3:

the global DNS is eventually likely to be implicated

The global DNS is already used for service discovery. Every time someone prints 
at an IETF meeting using AirPrint to the Terminal Room printer, the global DNS 
is being used. This is now, not the future.

How about just removing the word “eventually”?

Page 5:

In any case, if a given portion is implicated, the
profile will need to apply to all labels in that portion.

This is overly strict. It’s not necessarily all-or-nothing. The <Domain> 
portion of the Service Instance Name may require mixed handling. Consider the 
Service Instance Name:

Public Printer._ipp._tcp.3rd Floor.café.com.

The <Instance> portion, “Public Printer”, is UTF-8.

The <Service> portion, “_ipp._tcp”, is plain ASCII, and uncomplicated.

The <Domain> portion is mixed.
“3rd Floor” has a space, and has to be UTF-8.
But “café.com” is actually registered as “” and has to be 
converted as such.

Fortunately the iterative algorithm described in RFC 6763, and implemented and 
shipping in Apple products and the Open Source mDNSResponder code, handles 
this. So, while this may appear to be a problem, it is in fact a solved problem.

Page 6:

some recommendations from [RFC6763] will not really be possible to implement

Can you elaborate on what recommendations are not possible to implement?

many labels in the <Domain> part of a Service Instance Name are
unlikely to be found in the UTF-8 form in the public DNS tree

Saying “unlikely” is too strong. An administrator who wants spaces or similar 
exotic Unicode characters in a service discovery domain name will have to use 
UTF-8 for that name, even if host names in the same zone use Punycode. And this 
is not hard to do. You simply edit the zone file using a UTF-8-capable text 
editor, and type in the desired UTF-8 text. Name servers such as ‘named’ will 
happily serve that zone. The name server itself doesn’t need to be 
UTF-8-capable in any way. It just acts on the bytes in the zone file, without 
attempting to interpret how humans will perceive those bytes.

Page 6:

mDNS normally uses UTF-8.

should say:

mDNS exclusively uses UTF-8.

Page 7:

As a practical matter, this
likely means special-purpose name resolution software for DNS-SD.

This reads as if it’s talking about some hypothetical future. This 
special-purpose name resolution software is already used for service discovery, 
and has been since Mac OS X 10.2 in 2002. This special-purpose name resolution 
software, and its APIs, is on Apple products, Microsoft Windows, Linux, and 
Android. So, again, this text is describing a non-problem. It’s like text 
warning against using JPEG as an image format in 2017, because JPEG images 
require “special-purpose JPEG image decoding software”, at a time when all 
major platforms have had JPEG image decoding software for many years.

Page 8:

DNS-SD 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.  In the event that the
<Domain> portion of the Service Instance Name fails to resolve, it is
acceptable to substitute labels with plain UTF-8, starting at the
lowest label in the DNS tree and working toward the root.  This
approach differs from the rule for resolution published in [RFC6763],
because it privileges IDNA2008-compatible labels over UTF-8 labels.

If we want to recommend this change in behavior, I think this document is the 
wrong place to do it.

RFC 6763 is a published Standards-Track specification. For good or bad, it went 
though thorough lengthy review, and is a result of the IETF consensus process. 
I think it’s confusing to have an Informational RFC that appears to update a 
Standards-Track RFC. Should an implementer follow RFC 6763 because it’s a 
Standards-Track specification and this document is merely Informational, and 
doesn’t say, “Updates: RFC 6763”? Or should an implementer follow this document 
because it’s newer and therefore is assumed to supersede any text found in 
older Standards-Track RFCs?

RFC 6763 specifies an iterative algorithm that is implemented, and in use, and 
appears to work. Overturning that specification should require careful scrutiny 
and Standards-Track action. In 2017, does the IETF want to be encouraging 
movement towards UTF-8 as the universal encoding for everything, or encouraging 
continued diversification into “every protocol invents its own different 
incompatible encoding for international text”?

Page 8:

The first of these is rejected because it represents a potentially
significant increase in DNS lookup traffic for no value.

I request removing the value judgement “for no value”.

The value of using UTF-8 is that it is both more compact and more expressive 
than Punycode.

How about:

An issue with the first of these is that it represents a potentially
significant increase in DNS lookup traffic.

Page 8:

it is unlikely that the UTF-8 version of the zone will be delegated from 

This is circular logic. An administrator using a UTF-8 zone *will* make sure 
that UTF-8 zone is accessible, or there’s no point having it. This could be 
done by delegation, but need not be. Subdomains don’t have to be delegated -- 
subdomains can exist in a single zone. Not all subdomain boundaries need to be 
zone cuts, and many are not.

Stuart Cheshire

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [dnssd] Last Call: <draft-ietf-dnssd-mdns-dns-interop-04.txt> (On Interoperation of Labels Among Conventional DNS and Other Resolution Systems) to Informational RFC, Stuart Cheshire <=