Re: [DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt

Stuart Cheshire <cheshire@apple.com> Tue, 29 December 2015 21:32 UTC

Return-Path: <cheshire@apple.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42FC71A8A11 for <dnsop@ietfa.amsl.com>; Tue, 29 Dec 2015 13:32:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.457
X-Spam-Level:
X-Spam-Status: No, score=-99.457 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_BELOW2=2.154, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham
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 hDtCIAlNzdfn for <dnsop@ietfa.amsl.com>; Tue, 29 Dec 2015 13:32:35 -0800 (PST)
Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AB031A8A12 for <dnsop@ietf.org>; Tue, 29 Dec 2015 13:32:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1451424754; x=2315338354; 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=3OEue0r6t7FPsvk/1awFOzPSgiA6wXLcoHovWzC1HG0=; b=AWPzQTw32Pl8XlNNXwJ/eC6vBUTf5IEYghc+phnMOx7qkH7jWvknuY8xSkDOgIqQ GGGv6tb9F1WnVbpYy6cM1sfhbpKHADJydpFiNLbWjL55DoeEWNkRC+B9rEwyt493 BCEHmbjc+c3ipca8SaOer5cmtcQjxCjDe3H9kvXONaFIBaeWU2tAPSfeNXSVNYBg xxBFvhsL9eV0dzO3lVLfoQazisepG5tXZb+JjLD4CYBdlbKKA6SRmmows2mFA5mJ jHYTTuUXh4rivBVBWqH76dj11a794g4GjdfzQUztJnccy8fdu6XKc5ImF/aWo9bn p43J7mxPmVb0Q59ZxN1vGg==;
Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 55.9E.27232.2FBF2865; Tue, 29 Dec 2015 13:32:34 -0800 (PST)
X-AuditID: 11973e15-f79366d000006a60-89-5682fbf2d4f1
Received: from russet.apple.com (russet.apple.com [17.171.2.67]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 1E.5C.29028.2FBF2865; Tue, 29 Dec 2015 13:32:34 -0800 (PST)
Received: from [172.20.10.5] (mc75036d0.tmodns.net [208.54.80.199]) by russet.apple.com (Oracle Communications Messaging Server 7.0.5.37.0 64bit (built Nov 11 2015)) with ESMTPSA id <0O0500M2S2I54X40@russet.apple.com> for dnsop@ietf.org; Tue, 29 Dec 2015 13:32:32 -0800 (PST)
Sender: cheshire@apple.com
Content-type: text/plain; charset=utf-8
MIME-version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Stuart Cheshire <cheshire@apple.com>
In-reply-to: <68818B75-F6F6-44A1-BAF5-BB68B7BD86F6@hopcount.ca>
Date: Tue, 29 Dec 2015 13:32:28 -0800
Content-transfer-encoding: quoted-printable
Message-id: <9AE35A2C-69D1-4324-ACFC-F7AD9AC3C917@apple.com>
References: <20151019232608.9713.92337.idtracker@ietfa.amsl.com> <68818B75-F6F6-44A1-BAF5-BB68B7BD86F6@hopcount.ca>
To: Joe Abley <jabley@hopcount.ca>, Peter Koch <pk@denic.de>, Alain Durand <alain.durand@icann.org>
X-Mailer: Apple Mail (2.3096.5)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUi2FCYpvvpd1OYwYl32hZ331xmcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxuk/RxkLpjhUdK46zNTAONW4i5GTQ0LAROL4jlusELaYxIV7 69m6GLk4hAT2MUos3HiXGaboyrsbzBCJaUwSlxdvBesQEpjNJDH/jSGILSwgJfFq5WegIg4O ZgF1iSlTckHCvAIGEv+vNrJDlCRLNG9/BNbKJqAl8eLzFTYQm1PAXuJO6xswm0VAVWLR0lYw m1nAVuJz41VGCFtb4sm7C6wQM20kHm5azgJxQqnE2w0zmEBsEYFUiXUT77JB3Cwv8XNlAxPI zRICf1kltmz+xjaBUWQWwnmzkJw3C8mKBYzMqxiFchMzc3Qz88z0EgsKclL1kvNzNzGCgnu6 negOxjOrrA4xCnAwKvHwZkxqDBNiTSwrrsw9xCjNwaIkznvxeVOYkEB6YklqdmpqQWpRfFFp TmrxIUYmDk6pBsaz65e9VJqXPZNh5X2fj5uiluu+Yb57KK2nSHBBTGf5frEfrpG79r+IbsxY /qe8fvPbu+Zv69Ud1pgdW7Zk1/zcl3Vqc/smnOld/KPFbHdIikdiVPypycvmFP0+uGaR1YPG WmPN5/0ror24u7/uPX6Cea2g3dQb59czMe9K7Ls8+d7HFeGH9ka9UmIpzkg01GIuKk4EAHqK amVPAgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUiuJrJWffT76Ywg+nvNSzuvrnM4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujNN/jjIWTHGo6Fx1mKmBcapxFyMnh4SAicSVdzeYIWwxiQv3 1rN1MXJxCAlMY5K4vHgrK0hCSGA2k8T8N4YgtrCAlMSrlZ+BGjg4mAXUJaZMyQUJ8woYSPy/ 2sgOUZIs0bz9EVgrm4CWxIvPV9hAbE4Be4k7rW/AbBYBVYlFS1vBbGYBW4nPjVcZIWxtiSfv LrBCzLSReLhpOQvECaUSbzfMYAKxRQRSJdZNvMsGcbO8xM+VDUwTGAVnIVw0C8lFs5BMXcDI vIpRoCg1J7HSQi+xoCAnVS85P3cTIygYGwrTdjA2Lbc6xCjAwajEw5sxqTFMiDWxrLgy9xCj BAezkgiv4qSmMCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8EtYFYUIC6YklqdmpqQWpRTBZJg5O qQZGNtWz9z4HMt/9syUzMUyy1XJrxtmtNqK36i+ZynHue6kYvT2vpytlyYpr+cbO22cc4k+P uGOy9/xVn0cislJXw597H0sT9xOZJ658dk9rRFDm63MbnnXM/7mzYa38FsWyiS0my809WpkX ns/68vAUg9PdHTWp6deqp15hE8zhdr5lEJSxyyBfiaU4I9FQi7moOBEApoKQ7kICAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/hyjQV8k4yef_m-kZR0uO_lOwzp0>
Cc: dnsop WG <dnsop@ietf.org>, Ralph Droms <rdroms@cisco.com>
Subject: Re: [DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Dec 2015 21:32:37 -0000

Hi Joe, Peter, Alain,

I have some feedback on draft-adpkja-dnsop-special-names-problem-00.

There seems to have been lots of recent discussion regarding confusion surrounding RFC 6761. I’m a little surprised by this, since I didn’t think RFC 6761 was unclear. But then as co-author, that’s my failing. I thought it clearly stated our intention, and I thought the IETF Last Call scrutiny should have identified any ambiguity, but apparently not.

>    In recent years, using the last label of a domain name (aka TLD) as
>    switch to indicate how to treat name resolution has been experimented
>    using the framework of [RFC6761].

Not only the last label. The last _n_ labels are also commonly used as the algorithmic method for determining what names qualify as special. Some examples:

10.in-addr.arpa.
168.192.in-addr.arpa.
example.com.
example.net.
example.org.

>    This switch practice is not explicitly documented anywhere.

That was the intention of the seven-question list: to have protocol specifications explicitly document their “switch practice” -- i.e. how their special names are to be unambiguously recognized, and what software should do having recognized one of them.

>    Answers to these seven questions provide guidance to the
>    corresponding seven audiences on how to handle a special-use domain
>    name once it has been reserved by inclusion in the Registry.
>    However, they are inadequate for making the determination whether a
>    particular domain name qualifies as being special in the first place.

You have it backwards. The seven questions were not “what to expect *after* this special-use registration is done”; they were the justifications *why* the special-use registration should be granted, required in a document demonstrating that it (a) provides a result that the community judges to be good, and (b) the aforementioned good result cannot reasonably be achieved better another way.

>    The lack of a more elegant way to specify a name resolution protocol
>    in (for example) a URI amounts to an architectural oversight.

I’m not sure I agree that there *is* a more elegant way to achieve the desired effect. Unless you intend to actually describe some hypothetical “more elegant way” of doing this, I suggest simply removing this unsupported implication from the document.

>    It should also be noted that there are other choice than using the
>    most significant label for a protocol switch.  In particular, a
>    proposal to move those protocol switches under a specific top level
>    domain has been discussed (.ALT).  If that architecture choice is
>    made, some of the questions listed in the sections bellow (sic) would
>    become moot.

RFC 6761 is not, and has never been, about TLDs. It is about special behaviours, and how to trigger them. As such, whether the protocol switch is a TLD, or SLD, or 3LD, or whatever, has no bearing at all on “the questions listed in the sections below”. The same concerns would apply equally, regardless of how the algorithmic determination of “specialness” is to be performed. RFC 6761 states that the algorithmic determination is *typically* done by looking for a certain suffix (i.e., one or more labels). I deliberately did not want RFC 6761 to over-specify this, so as to leave the door open for someone smarter than me who might come along in the future and propose some new and valid algorithmic determinant that I had not anticipated. Clearly a document stating that any name containing any label starting with an “x” is now “special” ought to be thrown out by the IESG as unreasonable, but there could be other valid ideas beyond my current imagination.

>    Note: [RFC6761] mentions the reserved names could be any label in any
>    random string, not just the rightmost one (or ones).

Can you cite the actual text that says that? I couldn’t find what particular text you’re paraphrasing there.

>    What does it mean to have a "non-DNS" entry in the registry
>    described above?

The answers to the seven questions, and other text in the associated protocol specification, are supposed to tell you what it means.

>    Are applications supposed to check that registry to know what to do?

No.

>    Can/Should applications do this check dynamically?

No.

>    What if an application makes this dynamic check and realizes the
>    name contains a switch it does not know how to treat?

Not applicable. The closest equivalent to the run-time mechanism you’re hinting at is something that already exists: The global DNS. Putting in authoritative NXDOMAIN results for all appropriate special-use names is the best way to achieve the result you want.

>    it is not clear who is responsible for carrying out an
>    evaluation.  A document which requests additions to the Registry
>    might be performed by the IESG, by the IAB, by the DNSOP working
>    group, by an ad-hoc working group, by expert review or any
>    combination of those approaches.  [RFC6761] provides no direction.

RFC 6761 says:

   When IANA receives a request to record a new "Special-Use Domain
   Name", it should verify, in consultation with the IESG, that the IETF
   "Standards Action" or "IESG Approval" document [RFC5226] includes the
   required "Domain Name Reservation Considerations" section stating how
   the special meaning of this name affects the behavior of hardware,
   software, and humans in the seven categories.  If IANA and the IESG
   determine that special handling of this "Special-Use Domain Name" is
   appropriate, IANA should record the Special-Use Domain Name, and a
   reference to the specification that documents it, in the registry.

I confess I has assumed that IANA would designate some person with the expertise and experience to evaluate whether “... special handling of this "Special-Use Domain Name" is appropriate ...”, much as requests for TCP and UDP ports are evaluated. That was my mistake. I should have been explicit about the intended review process.

>    For example, is large scale prior deployment an acceptable criteria?

Large scale prior deployment should *not* be required -- that would just make squatting a necessary prerequisite for getting a special use name assigned. RFC 6761 was intended to provide a legitimate path for proposals to be evaluated on technical merit, rather than de facto squatting.

>    Going back to the previous point of prior usage of the protocol, in
>    the case of LOCALHOST, LOCAL and ONION, those particular domain names
>    were already in use by a substantial population of end-users at the
>    time they were requested to be added to the Registry.  Rightly or
>    not, the practical cost of a transition was argued as a justification
>    for their inclusion in the registry.

No. The justification for having an entry in the registry was to facilitate the desired special behaviour. The particular choice of what name went in the registry was influenced by existing usage, but the justification for having the entry itself was motivated by the desire for special behaviour. If the IETF process went a bit more smoothly, the IETF would have more participation in the choice of name *before* it becomes too late to easily change that.

As I read it, draft-adpkja-dnsop-special-names-problem seems to focus far too intently on the issue names. (But then, that is what ICANN is in the business of selling, so maybe it’s not surprising.) The substance of RFC 6761 is about enabling special behaviours, and using special names to trigger those special behaviours is merely a means to the end. What is interesting and important, and worthwhile for the IETF to support, is the special behaviours, not the names.

Stuart Cheshire