Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-00.txt

Ted Lemon <ted.lemon@nominum.com> Sun, 02 February 2014 14:42 UTC

Return-Path: <Ted.Lemon@nominum.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 4FBA61A00D9 for <dnsop@ietfa.amsl.com>; Sun, 2 Feb 2014 06:42:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 v6ipdlDnELSg for <dnsop@ietfa.amsl.com>; Sun, 2 Feb 2014 06:42:48 -0800 (PST)
Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 895C01A00DC for <dnsop@ietf.org>; Sun, 2 Feb 2014 06:42:48 -0800 (PST)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUu5ZZPKJpbnXCOzAodjzLvDdBsj2RvYc@postini.com; Sun, 02 Feb 2014 06:42:44 PST
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 2486B1B8318 for <dnsop@ietf.org>; Sun, 2 Feb 2014 06:42:44 -0800 (PST)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id D7A0E190052; Sun, 2 Feb 2014 06:42:43 -0800 (PST)
Received: from [10.0.10.40] (192.168.1.10) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 2 Feb 2014 06:42:43 -0800
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Ted Lemon <ted.lemon@nominum.com>
In-Reply-To: <20140130004530.C660CE086E0@rock.dv.isc.org>
Date: Sun, 2 Feb 2014 09:42:40 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <92B69F15-5DF0-46BC-8D77-02FE15AC24F8@nominum.com>
References: <20140129055438.2402.qmail@joyce.lan> <97E20887-2B9C-4EAD-826B-043306605F88@fl1ger.de> <72A3E4AE-F116-4496-BADB-5973DEC46598@vpnc.org> <C2A6625B-BEF7-41D6-B8BB-B870694CAFD9@fl1ger.de> <555B2F7B-7D29-43BC-AADC-1EA65A17DEF0@hopcount.ca> <EE6063EE-A69E-4460-91B4-862096A00F0F@fl1ger.de> <20140130004530.C660CE086E0@rock.dv.isc.org>
To: Mark Andrews <marka@isc.org>
X-Mailer: Apple Mail (2.1827)
X-Originating-IP: [192.168.1.10]
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>, Joe Abley <jabley@hopcount.ca>, Ralf Weber <dns@fl1ger.de>, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [DNSOP] additional special names Fwd: I-D Action: draft-chapin-additional-reserved-tlds-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: <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: Sun, 02 Feb 2014 14:42:50 -0000

On Jan 29, 2014, at 7:45 PM, Mark Andrews <marka@isc.org>; wrote:
> The squatted tld's used by software .onion, .bit etc could be
> migrated to a new namespaces.  Just issue new software that looks
> / recognises in the new namespace first then in the old one for X
> years.  After X years stop looking in / recognising the old namespace.
> Set X to about 10 years and there will be very little old code left
> when you turn off support for the namespace.  Set and compile in
> the drop dead date.

Ten years is a long time, and even if the schedule you recommend is practical, the conflict will still cause problems in the short term, which is what actually matters.   The IETF could choose to simply punt on this and let ICANN deal with it however they want, but there's some degree of consensus that we ought to document these issues, and that's why this draft is up for consideration.

The point is not to say "squatting on TLDs is ok" or "special-use TLDs for these uses is the right architecture," but rather to say "special-use TLDs for these uses exist; here is what they are; here is where to go to learn more about them."

In my mind, the criteria for deciding whether to document them are (a) whether there is some serious effort out there somewhere to use them _on the internet_, (b) that someone proposes to document the use in the IETF under RFC 6761, and (c) that we think there is sufficient interest in the usage being documented that it's reasonable to think that, were the TLD in question to be assigned in the DNS, significant problems would ensue.

(c) is a judgment call, (b) is a prerequisite for RFC 6761 to apply (the IETF does not have change control for the namespace, but is an appropriate venue for documenting uses of it), and (a) is a requirement because if (a) doesn't apply, it's simply not the IETF's problem.

It's certainly reasonable to say that we ought to make architectural recommendations to proponents of these special-use TLDs, but we can't actually stop them from using them.   It's somewhat analogous to the situation with TXT records.

So if we punt on this and refuse to document these special use TLDs under 6761, it doesn't actually solve the problem, or make anything better.

And although several heavy hitters in the DNS working groups do apparently feel strongly that special use TLDs are a bad architectural choice, there is no consensus in the IETF for this position (yes, I am saying that with my AD hat on).

The IESG would prefer to see these proposals worked on by DNSOP, because that will likely improve the documents.   Part of that improvement might be some recommendation for sunsetting, although I am skeptical that that will gain consensus.

But we've been down the "this is a bad idea, let's not document it" path before, and it leads to worse outcomes than documenting it.   So I'd really love it if we could see some discussion of how to make the document better, rather than simple rejection of the proposal.