Re: [DNSOP] Interim DNSOP WG meeting on Special Use Names: some reading material

Dan York <york@isoc.org> Tue, 12 May 2015 12:50 UTC

Return-Path: <york@isoc.org>
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 5FCB71B2C2B for <dnsop@ietfa.amsl.com>; Tue, 12 May 2015 05:50:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 LkQdS7S_QIeU for <dnsop@ietfa.amsl.com>; Tue, 12 May 2015 05:49:57 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0066.outbound.protection.outlook.com [65.55.169.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE88C1B2C2E for <dnsop@ietf.org>; Tue, 12 May 2015 05:49:53 -0700 (PDT)
Received: from CY1PR0601MB1657.namprd06.prod.outlook.com (25.163.232.19) by CY1PR0601MB1657.namprd06.prod.outlook.com (25.163.232.19) with Microsoft SMTP Server (TLS) id 15.1.160.19; Tue, 12 May 2015 12:49:50 +0000
Received: from CY1PR0601MB1657.namprd06.prod.outlook.com ([25.163.232.19]) by CY1PR0601MB1657.namprd06.prod.outlook.com ([25.163.232.19]) with mapi id 15.01.0160.009; Tue, 12 May 2015 12:49:50 +0000
From: Dan York <york@isoc.org>
To: Andrew Sullivan <ajs@anvilwalrusden.com>
Thread-Topic: [DNSOP] Interim DNSOP WG meeting on Special Use Names: some reading material
Thread-Index: AQHQiM15lqprJJM9GU2GchpioojQ151xS7amgAEAWgCAAC4yAIAAPGKAgAAuDoCAABUogIAElEeAgADEhgA=
Date: Tue, 12 May 2015 12:49:49 +0000
Message-ID: <62970575-A605-4B3E-9E98-D760B47E8532@isoc.org>
References: <20150508193400.55273.qmail@ary.lan> <FF464258-0C33-45CC-A684-BAB7BCE8A8FB@gmail.com> <alpine.OSX.2.11.1505082118060.31363@ary.lan> <0902600F-134B-4688-9CDD-1ACB23431DDE@vpnc.org> <20150512010624.GC74841@mx2.yitter.info>
In-Reply-To: <20150512010624.GC74841@mx2.yitter.info>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: anvilwalrusden.com; dkim=none (message not signed) header.d=none;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [74.69.229.215]
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0601MB1657;
x-microsoft-antispam-prvs: <CY1PR0601MB1657444168096E6AE07D9FCCB7DA0@CY1PR0601MB1657.namprd06.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR0601MB1657; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0601MB1657;
x-forefront-prvs: 0574D4712B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(51704005)(377454003)(33656002)(82746002)(76176999)(19580405001)(19580395003)(189998001)(54356999)(5001960100002)(83716003)(110136002)(106116001)(50986999)(86362001)(87936001)(2656002)(99286002)(46102003)(102836002)(92566002)(66066001)(93886004)(36756003)(62966003)(122556002)(77156002)(40100003)(2900100001)(2950100001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0601MB1657; H:CY1PR0601MB1657.namprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-ID: <9B8C5DF13DFB074B95635CE0F8C14AFF@namprd06.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: isoc.org
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2015 12:49:49.6273 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0601MB1657
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/6664xfMKFaLM-NiTR268-wxYgQE>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Subject: Re: [DNSOP] Interim DNSOP WG meeting on Special Use Names: some reading material
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, 12 May 2015 12:50:01 -0000

I’ve been reading this whole discussion with great interest over the past while and do intend on joining today’s call.  In the midst of all of this I think two points from Andrew and Ed have been helpful to my thinking:

> On May 11, 2015, at 9:06 PM, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
> 
> It seems to me that making new reservations solely on _policy_ grounds
> is overstepping our role, because we actually gave that management
> function away to someone else many years ago.  But if there are
> additional protocol-shift registrations, it would be appropriate to do
> that.

I’m not sure I’m 100% on board with Andrew’s use of the term “protocol-shift” to explain the difference, but I do agree with his statement that reservations should not be made based *solely* on policy grounds and that there needs to be some true protocol-based reason for the reservation.

Even better, I like Ed’s distinction:

> On May 9, 2015, at 7:29 AM, Edward Lewis <edward.lewis@icann.org> wrote:
> 
> The problem (the topic of discussion here) I see is that there are class
> of strings that are intended to not be active in the DNS and further more,
> the DNS isn't even meant to be consulted.  


This to me is the key point.  Reserving names like .ONION makes sense to me because there is existing Internet infrastructure that is widely deployed and uses that TLD-like-name in its operation…. but has no expectation that the name would be active in DNS.   Were such a TLD ever to be delegated in DNS, it could conceivably *break* these existing services and applications.   Those are the kind of names that make sense to be reserved.

I do realize that there is a challenge with determining when something is “widely deployed” enough to merit this consideration.  Just because I may have some service I created that uses a pseudo-TLD of “.YYY”[1] probably doesn’t really rise to the level if only I and 5 other friends use it.  What number makes sense?  I don’t know because as others have commented such numbers can be easy to game with automated scripts, bots, etc.

My 2 cents,
Dan  (as an individual, not as any statement from ISOC)

[1] I was going to use “.FOO” here but of course someone (Google, in this case, maybe at Warren’s request!) did actually register .FOO through the newgTLD process.