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

Donald Eastlake <d3e3e3@gmail.com> Sat, 02 January 2016 03:04 UTC

Return-Path: <d3e3e3@gmail.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 843231B2A3A for <dnsop@ietfa.amsl.com>; Fri, 1 Jan 2016 19:04:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3hVqie3sNLJ for <dnsop@ietfa.amsl.com>; Fri, 1 Jan 2016 19:04:51 -0800 (PST)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54AC61A9154 for <dnsop@ietf.org>; Fri, 1 Jan 2016 19:04:51 -0800 (PST)
Received: by mail-oi0-x230.google.com with SMTP id o124so230981121oia.1 for <dnsop@ietf.org>; Fri, 01 Jan 2016 19:04:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.202.75.129 with SMTP id y123mr45428483oia.110.1451703890638; Fri, 01 Jan 2016 19:04:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.76.157.161 with HTTP; Fri, 1 Jan 2016 19:04:36 -0800 (PST)
In-Reply-To: <9AE35A2C-69D1-4324-ACFC-F7AD9AC3C917@apple.com>
References: <20151019232608.9713.92337.idtracker@ietfa.amsl.com> <68818B75-F6F6-44A1-BAF5-BB68B7BD86F6@hopcount.ca> <9AE35A2C-69D1-4324-ACFC-F7AD9AC3C917@apple.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Fri, 1 Jan 2016 22:04:36 -0500
Message-ID: <CAF4+nEFnJCCHdaOHLFa5xc_iH8AC5p_bVAd+k1UbpgSXH-h4cw@mail.gmail.com>
To: dnsop WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary=001a11c177c4b87f2e05285126f1
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/yq_jKqlO74nNB343hC8qY737DF0>
Cc: Stuart Cheshire <cheshire@apple.com>, Peter Koch <pk@denic.de>, Ralph Droms <rdroms@cisco.com>, Joe Abley <jabley@hopcount.ca>, Alain Durand <alain.durand@icann.org>
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: Sat, 02 Jan 2016 03:04:54 -0000

I endorse and support Stuart Cheshire's remarks below.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

On Tue, Dec 29, 2015 at 4:32 PM, Stuart Cheshire <cheshire@apple.com> 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:
>
> 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
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>