Re: [Internetgovtech] Cross community

Andrew Sullivan <ajs@anvilwalrusden.com> Wed, 23 July 2014 22:47 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: internetgovtech@ietfa.amsl.com
Delivered-To: internetgovtech@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40DD1B28BA for <internetgovtech@ietfa.amsl.com>; Wed, 23 Jul 2014 15:47:07 -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 KaS7WMNKK7f5 for <internetgovtech@ietfa.amsl.com>; Wed, 23 Jul 2014 15:47:06 -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 4E5151B2810 for <internetgovtech@iab.org>; Wed, 23 Jul 2014 15:47:06 -0700 (PDT)
Received: from mx1.yitter.info (dhcp-bcbc.meeting.ietf.org [31.133.188.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 1977D8A031 for <internetgovtech@iab.org>; Wed, 23 Jul 2014 22:47:05 +0000 (UTC)
Date: Wed, 23 Jul 2014 18:47:03 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: internetgovtech@iab.org
Message-ID: <20140723224703.GC21760@mx1.yitter.info>
References: <B7163126-31B6-4CC6-A711-F225051C294A@istaff.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.2020000@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02828.1030805@gmail.com> <53D02D53.6070501@acm.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <53D02D53.6070501@acm.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/xjib9VEU0I_2AYAOXbQaennnDtE
Subject: Re: [Internetgovtech] Cross community
X-BeenThere: internetgovtech@iab.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Governance and IETF technical work <internetgovtech.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/internetgovtech>, <mailto:internetgovtech-request@iab.org?subject=unsubscribe>
List-Archive: <http://www.iab.org/mail-archive/web/internetgovtech/>
List-Post: <mailto:internetgovtech@iab.org>
List-Help: <mailto:internetgovtech-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/internetgovtech>, <mailto:internetgovtech-request@iab.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Jul 2014 22:47:07 -0000

On Wed, Jul 23, 2014 at 05:46:59PM -0400, Avri Doria wrote:
> But ICANN is responsible for policy regarding TLDs.  It gets to tell
> IANA what to do with TLDs.

I think, actually, that's not precisely correct.  ICANN has
responsibility for the root zone.  The things we put in the root zone
are often called "TLDs", but not every domain name is in fact a name
eligible to be in the DNS.  

The IETF has responsibility for the technical definition and
consequences of protocols, and what RFC 6761 establishes is a way to
reserve certain kinds of names for technical purposes when that is
necessary.  This is not new: RFC 2606, published in 1999, establishes
some similar reservations.

So, ICANN gets to tell IANA when to add an entry to the root zone,
provided that is technically acceptable.  ICANN cannot, for instance,
create a new delegation for com. that is distinct from COM., at least
not without violating STD13.  That's a consequence of the way the
protocols are defined.  ICANN cannot, either, create a new delegation
for zx--foo. without violating IDNA2008.  Note that somewhere around
2000, that latter restriction wasn't the case.  But new protocols come
along, and they have new rules.

RFC 6761 is intended to be used to identify names that need to be
handled specially.  In the case of such names that might be understood
as "top-level domains" (i.e. that are one label plus the null label
long), those are names that by definition should _not_ appear in the
root.  If they should, then part of the standards action or IESG
approval needed to approve the entry in the special-purposes registry
would detect that and likely reject the registration.  RFC 6761
clearly says as much:

   The specification also MUST state, in each of the seven "Domain Name
   Reservation Considerations" categories below, what special treatment,
   if any, is to be applied.  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.

There's no question that the special-use registry for names is a place
of overlap, where a slow and careful job of co-ordination will be
needed.  But we actually have those relationships between the
organizations, and this registry requires a fairly heavyweight
registration procedure precisely _because_ of the potential for conflict.

It just isn't true that RFC 6761 is a unilateral encroaching by IETF
on ICANN's area of responsibility.  ICANN is responsible for the root
zone.  It certainly should have policies itself for things that are
not permitted to be registered.  But I do not buy that ICANN's policy
responsibility extends to all labels that could logically-possibly be
in the root zone, just because of those cases where a protocol
requires a special-use name for technical reasons.  The IETF doesn't
tread on ICANN's responsibilities when it reserves local. any more
than it treads on Verisign's when it reserves example.com.

At the same time, the RFC 6761 example militates in favour of leaving
the different IANA functions together in a single IANA.  It is
logically possible, of course, to separate these functions, but it
would be a bad idea because IANA is about technical co-ordination that
turns out to be useful.  It's not Internet Police, and neither are any
of the policy bodies that feed it.  It's a utility, and making
arrangements that maximise that utility is the right thing to do.

Quite apart from that, it's not like the adoption of RFC 6761 or the
adoption of any future entry (were one to happen) in the special-use
registry is going to happen under a barrel.  One of the things I've
been finding mystifying about this entire discussion is the apparent
assumption that if someone is "in" one community that person can't
also be "in" another one.  We're not arranged with carefully-balanced
powers, or spheres of influence, or things like that.  I thought one
of the supposed advantages of open, bottom-up, transparent, and even
multi-stakeholder processes was supposed to be that cross-participation
is easy.  What have I missed?

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com