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

Donald Eastlake <> Sat, 02 January 2016 03:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 843231B2A3A for <>; Fri, 1 Jan 2016 19:04:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 3.105
X-Spam-Level: ***
X-Spam-Status: No, score=3.105 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c3hVqie3sNLJ for <>; Fri, 1 Jan 2016 19:04:51 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 54AC61A9154 for <>; Fri, 1 Jan 2016 19:04:51 -0800 (PST)
Received: by with SMTP id o124so230981121oia.1 for <>; Fri, 01 Jan 2016 19:04:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vxVhuErmvOmtfxNGdceK75wNysltRnbpf8CwrWcEg70=; b=yKlZggjNRxkt1q/v476JaNvKIZ6D2E/mYjjE+rvMHNdt8rwaASY+uuL41Fdo7nRnqW slF1UsvI5KYb6jBKG/bXWDpLs5z3r19L0/fif3bhvkxP+EgJR1dsllRJ92dJaq/3g+uk mX4xTgweXrrfXy2JFln9fPwu3yzYYtjFSnzSXPgJxAvK5wPQxL6qgEZ+M3ULjrJXqb1X moBODLx591hbid6RIPE4OrDhSV4CfOBGjPdUXpxUrnswwPccwPZaWEHpWqAVbbZ/Ynyn m+BF42wFWN3fm30hh9om03lsxsaAIByxYf/eNMDNGucfcXSwkKINEt6F6SPEW5w9aokG LdyQ==
X-Received: by with SMTP id y123mr45428483oia.110.1451703890638; Fri, 01 Jan 2016 19:04:50 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 1 Jan 2016 19:04:36 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: Donald Eastlake <>
Date: Fri, 01 Jan 2016 22:04:36 -0500
Message-ID: <>
To: dnsop WG <>
Content-Type: multipart/alternative; boundary="001a11c177c4b87f2e05285126f1"
Archived-At: <>
Cc: Stuart Cheshire <>, Peter Koch <>, Ralph Droms <>, Joe Abley <>, Alain Durand <>
Subject: Re: [DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 02 Jan 2016 03:04:54 -0000

I endorse and support Stuart Cheshire's remarks below.

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA

On Tue, Dec 29, 2015 at 4:32 PM, Stuart Cheshire <> wrote:

> 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:
> >    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
> _______________________________________________
> DNSOP mailing list