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 <[e-mail]>]

On 30 Mar 2017, at 14:10, The IESG <[e-mail]> 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) ...

or

> 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 “xn--caf-dma.com” 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 anywhere

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