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 <cheshire@apple.com> Thu, 13 April 2017 05:53 UTC

Return-Path: <cheshire@apple.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80620127201 for <dnssd@ietfa.amsl.com>; Wed, 12 Apr 2017 22:53:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KpUQeYAoaWtZ for <dnssd@ietfa.amsl.com>; Wed, 12 Apr 2017 22:53:11 -0700 (PDT)
Received: from mail-in21.apple.com (mail-out21.apple.com [17.171.2.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3759127449 for <dnssd@ietf.org>; Wed, 12 Apr 2017 22:53:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1492062788; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ynhZtJ+zD8DkXmpIZacyrL01VH5Ia97z0k1h8lV6j7k=; b=E935uCSKFKRNgv3BV6HaVBNS6uLgTb5B74rr94a5hLFetenyh53hm7d5EJkZFrJo 5ykoAAL+u/dYnuBSKmHwlmBbAe5hDT5bwAgE2WfsKA4uS+FMFtCKyyZie3NDdr// J5SO7BFxzKcLLW4LYLbSCsqmP5DmBRAiJr2vsijq4yixjVu0adbtq+7YYSSImWt3 dBGPVQduf5zOq4bofTBaovwdTOHuGIpdQz/vKAl6z21DHDmZAc5fAwygB65/0L7n 09nJ7DB2pqg5EOQplioOtqCctGsR8YIvp+C9SmwcF/dv1VMg+6CCfvIZ58dH8sX4 G7+Qna5MXH4OnV7vM0Zv9Q==;
Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) by mail-in21.apple.com (Apple Secure Mail Relay) with SMTP id CC.2C.13165.3421FE85; Wed, 12 Apr 2017 22:53:08 -0700 (PDT)
X-AuditID: 11ab0215-dc5879a00000336d-9f-58ef12435967
Received: from kencur (kencur.apple.com [17.151.62.38]) by relay7.apple.com (Apple SCV relay) with SMTP id 34.87.26825.3421FE85; Wed, 12 Apr 2017 22:53:07 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Received: from [10.0.1.35] (50-197-138-101-static.hfc.comcastbusiness.net [50.197.138.101]) by kencur.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OOC00MTF30HRX60@kencur.apple.com>; Wed, 12 Apr 2017 22:53:07 -0700 (PDT)
Sender: cheshire@apple.com
From: Stuart Cheshire <cheshire@apple.com>
In-reply-to: <149090820270.9007.2835487042847566330.idtracker@ietfa.amsl.com>
Date: Wed, 12 Apr 2017 22:53:07 -0700
Cc: IETF-Announce <ietf-announce@ietf.org>, draft-ietf-dnssd-mdns-dns-interop@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, Suzanne Woolf <suzworldwide@gmail.com>, terry.manderson@icann.org
Content-transfer-encoding: quoted-printable
Message-id: <099780BE-C3BC-4EF7-8C0F-93522195E6AE@apple.com>
References: <149090820270.9007.2835487042847566330.idtracker@ietfa.amsl.com>
To: ietf@ietf.org
X-Mailer: Apple Mail (2.3124)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUi2FCYqusi9D7CoOOOicWVd33MFu+XzmK0 +Pb7HZvFvTPT2SyebZzPYtE0ZRqrRevRm6wO7B47Z91l9zh84T6Lx5IlP5kCmKO4bFJSczLL Uov07RK4MpZ9+cxasNCy4uaNe+wNjEv1uhg5OSQETCRuT7/F0sXIxSEksJ9R4sLVWUwwictv jrBCJFYwSrx+v4INJMErICjxY/I9oA4ODmYBdYkpU3Khapgkutd2g9UIC0hJvFr5mRkkISyw lVFi8fnFLCAJNgEtiRefr4AVcQr4Skzp2QW2jUVAVWLroYlg25gFjjFKPH12F6yIWUBb4sm7 C6wg23gFbCQ2vaoECQsJ+EhMn32BCSQsAnTQwceWEEfLSjw5uQjsGwmBHWwSj+beZ53AKDwL yd2zEO6ehWTBAkbmVYzCuYmZObqZeUaGeokFBTmpesn5uZsYQZGxmkl0B+P8V4aHGAU4GJV4 eDsE30cIsSaWFVfmHmKU5mBREuedPvVdhJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbG6owp 1i7RFXqb7Or7pixhP3e67vV0NaVlQj8+TP8n8VE1KLosImiOw1Efhq85DoJNjltyNPhbF7sr zWNh+5PaYH3OZx6jpn2jl5/pmndcD1wkt6d9+Sz9ZgrHy4VyX7ImL86eknzl65SrYk3q92bu fqFS76Cc7K+1Q+5/7N51/qkCxY0KKTuUWIozEg21mIuKEwHhXzGvbQIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUiON1OTddZ6H2Ewf13OhZX3vUxW7xfOovR 4tvvd2wW985MZ7N4tnE+i0XTlGmsFq1Hb7I6sHvsnHWX3ePwhfssHkuW/GQKYI7isklJzcks Sy3St0vgylj25TNrwULLips37rE3MC7V62Lk5JAQMJG4/OYIaxcjF4eQwApGidfvV7CBJHgF BCV+TL7H0sXIwcEsoC4xZUouVA2TRPfabrAaYQEpiVcrPzODJIQFtjJKLD6/mAUkwSagJfHi 8xWwIk4BX4kpPbuYQGwWAVWJrYcmgm1jFjjGKPH02V2wImYBbYkn7y6wgmzjFbCR2PSqEiQs JOAjMX32BSaQsAjQQQcfW0IcLSvx5OQilgmMArOQnDoL4dRZSGYuYGRexShQlJqTWGmul1hQ kJOql5yfu4kRFMYNhak7GBuXWx1iFOBgVOLhPSH7LkKINbGsuDL3EKMEB7OSCO/sn0Ah3pTE yqrUovz4otKc1OJDjNIcLErivJdF3kQICaQnlqRmp6YWpBbBZJk4OKUaGO2nuCo0fErgl9vA r7mnScfs3pyJFz/uTdptv+zSgaRZO8+ZTdE7dfjwJu0jm899K1y87vabXjGp0GPczUckt/3d 7KMdeE0mcPukF10RDmslU527lZakK8T6ml4QUF+8Z1H9vGR3q51ST48yTn6exZ0au+SuKYep /axeuW0J8ifv3S6sOBx+20+JpTgj0VCLuag4EQB1gAN3XwIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/PJ5ACyvbJE41yD7FS9_Hso5AqI0>
Subject: 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
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Apr 2017 05:53:12 -0000

On 30 Mar 2017, at 14:10, The IESG <iesg-secretary@ietf.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) ...

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