Re: [Ianaplan] A draft for your review

Andrew Sullivan <ajs@anvilwalrusden.com> Sat, 01 November 2014 16:52 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: ianaplan@ietfa.amsl.com
Delivered-To: ianaplan@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6EF1A89B9 for <ianaplan@ietfa.amsl.com>; Sat, 1 Nov 2014 09:52:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level:
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 wjPbAQMQsq0t for <ianaplan@ietfa.amsl.com>; Sat, 1 Nov 2014 09:52:42 -0700 (PDT)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9689E1A89AF for <ianaplan@ietf.org>; Sat, 1 Nov 2014 09:52:42 -0700 (PDT)
Received: from mx1.yitter.info (unknown [50.189.173.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 796668A035 for <ianaplan@ietf.org>; Sat, 1 Nov 2014 16:52:41 +0000 (UTC)
Date: Sat, 01 Nov 2014 12:52:36 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: ianaplan@ietf.org
Message-ID: <20141101165234.GA25533@mx1.yitter.info>
References: <54017E09.8060504@cisco.com> <6.2.5.6.2.20140830052032.0c96c880@resistor.net> <54047E4A.30503@cisco.com> <6.2.5.6.2.20140901094544.0b305698@resistor.net> <54059587.8070608@cisco.com> <6.2.5.6.2.20141024004255.0b5ef5d8@resistor.net> <4C1255B9-68C3-45D5-A618-2C7553386DF4@gmail.com> <54522E43.5020709@acm.org> <545428AC.3090802@gmail.com> <7471A339-3938-4D65-81ED-9E27A80EC32B@virtualized.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <7471A339-3938-4D65-81ED-9E27A80EC32B@virtualized.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/tnwTRDrgokQegn0o_aexPz544QU
Subject: Re: [Ianaplan] A draft for your review
X-BeenThere: ianaplan@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <ianaplan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ianaplan/>
List-Post: <mailto:ianaplan@ietf.org>
List-Help: <mailto:ianaplan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Nov 2014 16:52:44 -0000

On Fri, Oct 31, 2014 at 07:15:14PM -0700, David Conrad wrote:
> 
> RFC 6761 allows for the preemption of _any_ top-level domain name. This would appear to go beyond "technical uses" and get into policy issues regardless of how "technical uses" might be reasonably defined or who does the defining.
> 

Yes, of course that's what RFC 6761 allows for.  That's because IANA
is responsible for allocating names in the root zone.  RFC 6761 is in
effect a formalization of the procedures for delineating the
_boundary_ of the root zone.  The introduction of 6761 is pretty clear
that these are all for special use, and draws the analogy with IP
allocation policy.  As it says, " This document specifies under what
circumstances special treatment is appropriate, and in what ways."

More importantly, 6761 includes, in section 4, this observation:

	If in all seven categories the answer is
   "none", then possibly no special treatment is required and requesting
   reservation of a Special-Use Domain Name may not be appropriate.

Additions to the registry require either Standards Action or IESG
Approval, which is a high bar.  I would expect the IESG to ask some
pretty pointed questions about a proposed registration if it didn't
meet the seven-category test.

So, I do not agree that there is an actual conflict between the two
areas of action here, and what is necessary is for us to ensure that
everyone is in agreement about the limits on the size of the root
zone, given particular technical needs.

I _can_ imagine things that the IETF might have tried to do that in my
opinion would have been an attempt to legislate policy under the
rubric of technical need.  For example, I can imagine the IETF having
tried to nail down the number of TLDs on the grounds that resolvers or
other clients would configure that list as static data (much as many
clients did in fact do).  To me, that would certainly have been an
attempt to make policy under the guise of technical need.  But that
didn't happen, which suggests to me that the division of labour,
again, is working.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com