[DNSOP] followup and proposed actions: RFC 6761 interim and next steps

Suzanne Woolf <suzworldwide@gmail.com> Tue, 19 May 2015 22:18 UTC

Return-Path: <suzworldwide@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 25E631B330E for <dnsop@ietfa.amsl.com>; Tue, 19 May 2015 15:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Level:
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 rfvEraZwo-el for <dnsop@ietfa.amsl.com>; Tue, 19 May 2015 15:18:22 -0700 (PDT)
Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (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 3C2A81A1EF2 for <dnsop@ietf.org>; Tue, 19 May 2015 15:18:22 -0700 (PDT)
Received: by qctt3 with SMTP id t3so15037830qct.1 for <dnsop@ietf.org>; Tue, 19 May 2015 15:18:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:message-id:cc:to:mime-version; bh=8pULh5jsYh1+FMH6tvJyxZxMP/5RI+SKh8d+VSD13eg=; b=UXExZZ8E99RzUkEQUgRNjsMEF9Axzx5OXrGJuZmScKtzoHh43amHPrNeZIb27Sa1J9 1RBAQEbzGjT6kGw1ZtO/2ptBu+Yv79Eh7DnD6+cQ+JxzN6fPCi4hpXazF+pp5N+XaPP/ b/SHsPrq/kNMOXDjTKiy2kjXtnjcqS3JISvFN0o2rh6l188VkLT1WMWvKTeO/T3GcOLV fIyv7Sjg5bAHBT1ltlMvQ1uROO4xDCfYFGMhVS6nKNyhOW0VMAnpaczuTDGEW+s8eK9D aiyp8roKhGElg3kqwYjIOu2WMFL2OziDE6KfnVDI9qXVNqgcGMOmC5xfihY9APBxt6Ok LvYA==
X-Received: by 10.229.126.130 with SMTP id c2mr6340536qcs.7.1432073901433; Tue, 19 May 2015 15:18:21 -0700 (PDT)
Received: from ?IPv6:2601:6:3a80:77e:717c:c837:5691:fab9? ([2601:6:3a80:77e:717c:c837:5691:fab9]) by mx.google.com with ESMTPSA id p73sm9877024qha.20.2015.05.19.15.18.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 May 2015 15:18:20 -0700 (PDT)
From: Suzanne Woolf <suzworldwide@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2182209C-BA4C-4C9C-8E93-0DF6A52B5E34"
Date: Tue, 19 May 2015 18:18:24 -0400
Message-Id: <0CB7A66E-B6C9-4FE7-8452-172A5CF48895@gmail.com>
To: dnsop@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2074.6\))
X-Mailer: Apple Mail (2.2074.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/0naJj_6yt3PkeGabV-XMBBEi8jc>
Cc: joel jaeggli <joelja@bogus.com>
Subject: [DNSOP] followup and proposed actions: RFC 6761 interim and next steps
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: <http://www.ietf.org/mail-archive/web/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, 19 May 2015 22:18:25 -0000

Dear Colleagues,

First, thanks for extensive and thoughtful discussion on the list and in our interim meeting last week on the way forward for the internet-drafts requesting special use names registry entries under RFC 6761.

This message is fairly long, and contains some impressions of where we are, a couple of actions we expect to take in the next few days, and some questions we’d like to pursue going forward. Please read all of it if you’re interested in the overall topic; we have significant challenges of both process and substance to navigate.

It's clear that applying RFC 6761 is challenging, and one of the outcomes we'd like to see from the current discussion is serious consideration of whether we need to update it with a new document suggesting additional guidelines or considerations.

First, some initial impressions:


.ONION (draft-appelbaum-dnsop-onion-tld-01):

* There’s significant support for the .onion request, in terms of the draft itself and what the TOR project is trying to accomplish by supporting the protocol and making the request.

* There are some reservations about .onion. We heard concerns that we might be setting a precedent for arbitrary appropriation of namespace; that the protocol may not be thoroughly documented, and that we’re not clear on how high the bar should be for a special use name.


.ALT (draft-wkumari-dnsop-alt-tld-06):

* There’s significant support for .alt as a possible alternative namespace for implementers who want namespace they’re certain won’t resolve in the global DNS, but are willing to be flexible on what namespace they use.

* There are operational questions about .alt that would have to be resolved in further development of the draft, such as whether to assume “leaked” queries would be sunk to AS112.

* There was some concern that implementers who want single-label or “TLD” namespaces would not accept .alt as a possible alternative

* There was some question as to what would be gained by .alt that we don’t already have in .invalid, which is also already reserved


HOME/CORP/MAIL (draft-chapin-additional-reserved-tlds-02):

* This is the most controversial of the RFC 6761 drafts and the one most driven by policy concerns

* The draft assumes that these names are commonly being used in local DNS contexts and often “leak” into the public internet. Specific uses are not documented.

* The most commonly used justification for this reservation was the risk of name collision if ICANN delegates these names in the production root zone.

* Since ICANN has said that they’re not currently planning to delegate these names, the justification further seems to assume that ICANN’s assurance of this is not a sound basis for believing that risk is contained

* There were questions about how to quantify name collision risk, or otherwise set a threshold for what operational characteristics of the appearance of a given name in the public internet would justify a conclusion that it should be “protected” by the IETF from delegation in the production root zone


ADDITIONAL NOTES:

There was some discussion of other drafts as well. In particular, there was some willingness to review the requests currently contained in draft-grothoff-iesg-special-use-p2p-names-04 if presented in separate drafts, as that would make it easier for the WG to properly consider those requests.


MOVING FORWARD:

We expect to take the following steps:

1. A call for adoption on the WG list of draft-appelbaum-dnsop-onion-tld-01. Given that there's clear support for it and a timeliness concern, we'd like to see if we can get to a consensus to move forward with it.

2. A call for adoption on the WG list of draft-wkumari-dnsop-alt-tld-06, and further discussion on the list to the operational questions mentioned above. We're all aware this isn't a complete solution to the perceived demand for special use names; can it be used to make the situation notably better?

3. Further discussion on the WG list of draft-chapin-additional-reserved-tlds-02. Given that we don't currently see consensus to move forward with it, and the support for it seems widely fragmented among technical and policy-based reasoning, we'd particularly like to see any NEW input on:

	* What is the specific operational impact being sought by adding these names to the special use names registry? Is the goal to have an impact on anyone besides ICANN?
	* Some of our discussion so far has suggested that there's a difference between basing a decision about a special use names delegation on intended use in a new protocol, such as .onion, and basing such a decision on unknown and unspecified use, perhaps particularly within the DNS. In the interests of evaluating future such requests that might also not be based on a specific protocol use, is there a bar we can set besides the discussion in the current draft of inferred name collision risk?

4. It's been pointed out that the maintenance of the special use names registry is complicated by the fact that people used to be able to assume the root zone was relatively stable, and this assumption has become less defensible. (ICANN is not currently accepting new applications for TLDs, and has no announced schedule for opening an application window again, but has said they plan a future application round.) Is there something that the IETF should be doing to help DNS implementers and operators handle this change in the environment?


thanks,
Suzanne and Tim