Re: Split the IANA functions?

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 06 January 2014 19:12 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5465A1AE1C0 for <ietf@ietfa.amsl.com>; Mon, 6 Jan 2014 11:12:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqStZ0YNcWzJ for <ietf@ietfa.amsl.com>; Mon, 6 Jan 2014 11:12:24 -0800 (PST)
Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2031AE1BB for <ietf@ietf.org>; Mon, 6 Jan 2014 11:12:24 -0800 (PST)
Received: by mail-pa0-f44.google.com with SMTP id fa1so19051516pad.3 for <ietf@ietf.org>; Mon, 06 Jan 2014 11:12:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=fu1AoybLWpJOc+rbn1jM7ipvmt+jO/je6HxAvz9RG+c=; b=HuLAwzTFgIsEyL/f7cIHRQrS/efLVMs3K/HDUuW932cZVf4nZY/7lwJ4ZK+U4un+5Z 6x6M2wDdZAqjn+TX1hezAVW0YoUqsulUAEvwjXCpMPhhCnOho8G9hLuePuUit9cmMyTt 5Z/qZGas6YPP1J1RdYNkmJmjHVNyTk5suuf/y4VbKfi3NeTBn0H7spOpPq2nrcVginXj t/N+kUHTNIMeI2uwAHgCaqampcmsjwZFFxhJvCEu7rnck/c3fd9+eLX/wy9oZuDkG3BF b1fdtKTh3J5MkKOj3y2ke5owBHwf+nXibb6U8hN1pDzDd8++6iZFYXhpi7f8eEVmiC+t pgvA==
X-Received: by 10.66.25.36 with SMTP id z4mr53187paf.101.1389035535900; Mon, 06 Jan 2014 11:12:15 -0800 (PST)
Received: from [192.168.178.21] (122.195.69.111.dynamic.snap.net.nz. [111.69.195.122]) by mx.google.com with ESMTPSA id wp8sm130617249pbc.26.2014.01.06.11.12.13 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 06 Jan 2014 11:12:15 -0800 (PST)
Message-ID: <52CB0010.5010407@gmail.com>
Date: Tue, 07 Jan 2014 08:12:16 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Phillip Hallam-Baker <hallam@gmail.com>
Subject: Re: Split the IANA functions?
References: <CAMm+LwinAb6+7BoMzwBWyu63vofndxK9VY6DSNN0Ykza4SxuMQ@mail.gmail.com>
In-Reply-To: <CAMm+LwinAb6+7BoMzwBWyu63vofndxK9VY6DSNN0Ykza4SxuMQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: IETF Discussion Mailing List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jan 2014 19:12:26 -0000

On 07/01/2014 05:20, Phillip Hallam-Baker wrote:
> Following up on Jari's post, I think it would be a prudent political move
> to split the IANA functions so that assignment of IP addresses is separate
> from the protocol registry functions. The motivation behind this is to
> protect the IETF.

Actually the reason we included explosive bolts in the IETF-ICANN MoU was
to protect the IETF in this way. (By "explosive bolts" I mean the unilateral
6 months notice.) I'm not sure why would need to blow the bolts in adavance
of an emergency.

> Like the DNS, the allocation of IP address space and BGP parameters is a
> potential control point. 

The MoU contains no exception to IETF control for BGP parameters.
And to be clear, the IETF retains control of "assignments of domain
names for technical uses", so DNS asignments and IP address assignments
are on exactly the same footing: IANA functions where the IETF has
agreed that "policy issues are outside the scope of this MOU." That
is not the case for BGP parameters. Since AS numbers are not in short
supply, and are allocated by IANA upon "RIR request to the IANA or IETF
Review" I can't see why we would want to change anything.

    Brian

> It is thus an activity that is at the eye of the
> storm as far as Internet governance goes. That can't be helped and isn't
> our problem. Governments can and should argue over the governance of a
> control point that could potentially cripple their economies if abused in a
> trade war.
> 
> The allocation of protocol parameters is not a control point since there is
> no enforcement mechanism. Nobody is going to take notice if IANA were to
> ever refuse to register a content type or an algorithm under political
> pressure.
> 
> So if Iceland develops its own word processor and wants to register the
> content type, the US government cannot protect Microsoft from competition
> by passing a law that tells IANA not to issue a content-type.
> Alternatively, if the NSA was to instruct IANA to refuse to register code
> points required by Brazil's new email security scheme the effort would be
> an obvious waste of time.
> 
> Abusing control of allocations in the IP, DNS and BGP spaces would also be
> difficult to maintain but the switching costs are much higher and the
> outcome is not so obvious. That dispute is certain to continue.
> 
> 
> The problem the current situation creates is that because half of the IANA
> function intersects with IETF activities and half with ICANN type
> activities, the combination brings IETF into the line of fire in disputes
> where it can better serve all sides by being neutral.
> 
> There is already a defacto split since the IANA operates the protocol
> registry under contract with IETF and the IP/BGP registries under contract
> with the DoC. The IETF might propose protocol changes that would impact the
> numbers registry but the same is equally true of ICANN. Similarly, the IETF
> could de facto reserve chunks of IPv6 space (and in fact does still
> controls 7/8th of the total space) just as it can de facto attempt to grab
> TLDs if it chooses. But this is a consequence of the fact that it is much
> easier to fork a chunk of namespaces than is generally admitted.
> 
> So splitting IANA in two would have little operational impact but ensures
> that there is a clear boundary between the governance of Internet control
> points which is clearly in ICANN space and the governance of Internet
> standards which is clearly separate from it.
> 
> The only practical impact would be changing the name of the protocol
> registry. It would still be maintained by the same people, etc. Since the
> protocol registries are not only numbers, the name Internet Assigned
> Registry Authority (IARA) would be more appropriate in any case.
> 
> 
> Logically, the thing to do would be for ICANN to rename the IP/BGP side of
> IANA but that would not have the same protective effect politically.
> 
>