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

Suzanne Woolf <suzworldwide@gmail.com> Thu, 27 February 2014 14:47 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 []) by ietfa.amsl.com (Postfix) with ESMTP id D1F881A02DD for <dnsop@ietfa.amsl.com>; Thu, 27 Feb 2014 06:47:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id fpoPjoleLqvE for <dnsop@ietfa.amsl.com>; Thu, 27 Feb 2014 06:47:04 -0800 (PST)
Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3701A02CF for <dnsop@ietf.org>; Thu, 27 Feb 2014 06:47:04 -0800 (PST)
Received: by mail-qa0-f41.google.com with SMTP id j5so2944919qaq.28 for <dnsop@ietf.org>; Thu, 27 Feb 2014 06:47:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=LraZVA8xrL7bIfBRoGm3KnEisL9+q/XwxW9IF7lrsXA=; b=XH4VbEGE9DCiFSM+xqR21knye6B7Atak14ZiTIdRAcPLrB04OM3A7Yofo0P9055FLu qLY1A9cYKzrna2tm7g/Ez7ytdm68SVrGaAr45eoAcyECSbyg9UgGMpv8DQDRHhLWhidf EAXD3V44TTgXw5nffkLDLMfuKZn5nruZz9eEHIiqQ8U3/AuNKM71qdwVKhh4RSKyN/0Q Ks54AeLnqaCmKJAkyjO+FAPwhoQ0shC/menlEslK4cfQ67ilzeUrEN043eM6hfjgzoZv NdZ9lK1mpok0so62UJpesGru24xFL/nNLvTl03gJvh2uKB7vC2pgo4yjINAQAIbR7h2A glHw==
X-Received: by with SMTP id a11mr17100515qay.1.1393512422920; Thu, 27 Feb 2014 06:47:02 -0800 (PST)
Received: from [] (c-24-63-89-87.hsd1.ma.comcast.net. []) by mx.google.com with ESMTPSA id b14sm14237397qac.17.2014. for <dnsop@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Feb 2014 06:47:02 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Suzanne Woolf <suzworldwide@gmail.com>
In-Reply-To: <20140227025617.0101A107642C@rock.dv.isc.org>
Date: Thu, 27 Feb 2014 09:47:02 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <A016D7ED-BB45-490E-B188-0326B2B89A5E@gmail.com>
References: <20140226233907.6214.qmail@joyce.lan> <20140227025617.0101A107642C@rock.dv.isc.org>
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/QUY-V5c777TS32jDq4KQfmuS7ps
Subject: [DNSOP] admin note Re: 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: Thu, 27 Feb 2014 14:47:07 -0000

(chair bit enabled)

On Feb 26, 2014, at 9:56 PM, Mark Andrews <marka@isc.org> wrote:

> In message <20140226233907.6214.qmail@joyce.lan>an>, "John Levine" writes:
>>> Perhaps all that is missing is some guidance that says "you shouldn't hijack
>>> namespaces that you don't control, even for non-DNS applications; register a
>>> domain instead".
>> That's a relatively high bar for all the residential broadband users
>> who buy a router at Best Buy (Future Shop to you), plug it in, and set
>> up the router via the configuration page at http://router.home.
> And why wasn't that "http://router.netgear.com" or
> "http://router.linksys.com". The router could easily serve the zone
> locally and the vendor could have a insecure delegation to it so
> it works if there are validating browsers being used.
> http://router.home does not work with validating browsers.
> If the CPE vendors want to use .home let them pony up the 100K for
> it rather than hijack the namespace.

There are operational reasons to care whether a name is in the special names registry, the production root zone, both, or neither-- regardless of who has authority over either or on what terms. We should probably focus on those. The DNSSEC issue is one useful set to explore, and further focus on it would be helpful. Another set of suggestions for our work is beginning to appear around refinements of standards treatment for DNS search path processing, on the grounds that much of the unpredictability of mixing namespaces and DNS scopes is based on unpredictable precedence of search path processes.

We've attempted to suggest now more than once that the special names discussions will be more useful if:

*We leave speculation on the economics and other non-technical attributes of other entities' decisions about the namespace out of it. Speculation on other mechanisms besides the one we in the IETF have (roughly, RFC 6761) for getting names into the top level namespace isn't productive, as we don't control them. We don't know when or whether ICANN will ever conduct another new TLD opening, or what will be eligible to be included, or at what price. The root zone change we have to consider is only that the old assumptions about its size stopped applying, not what the new ones might be beyond the specific commitments made by ICANN in its current root zone expansion. This is not an endorsement of anyone's actions in this space, or a condemnation either; it's an attempt to describe the situation we're actually in. 

* We separate issues of "what should be done, if anything, in the future to enable/support/protect non-DNS-protocol-specific, possibly non-global uses of the DNS namespace" from "what should be done, if anything, to improve/normalize the situation we're currently in". We have several drafts for discussion in London on options for the future, and a possible course of action for them that we work on them as refinements or replacements to RFC 6761. We also have two drafts requesting more or less that we grandfather pseudo-TLDs deployed in the absence of clear guidelines and consistent system behavior, in order to mitigate current issues caused by "hijacking" names under traditional expectations about how the root zone is managed. 

Regarding the guidance Joe proposed, our question is whether it's good guidance for the future, not so much whether it would have been in the past. We may also decide there's nothing we can do in the way of such guidance, the relevant horses have left the relevant barns, and the combination of DNS on-the-wire protocol, system behavior for scoping of names, and the policy characteristics of the namespace mean ambiguity, collision, or other sub-optimal characteristics of trying to use DNS namespace for non-DNS protocols or non-global scopes are a fact of life we can't usefully act to prevent in the future. That doesn't tell the IESG what to do with the current requests for grandfathering.

Ultimately, these issues do have to be integrated. But at this point we will get nowhere in, for example, trying to decide whether to grandfather existing names into the special names registry managed under the process in RFC 6761 based on an opinion about what a vendor might or should do in the future under an ICANN process we don't control.