Split the IANA functions?

Phillip Hallam-Baker <hallam@gmail.com> Mon, 06 January 2014 16:20 UTC

Return-Path: <hallam@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 8D6DA1AE097 for <ietf@ietfa.amsl.com>; Mon, 6 Jan 2014 08:20:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Level:
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 F2kqwXI7AYuB for <ietf@ietfa.amsl.com>; Mon, 6 Jan 2014 08:20:57 -0800 (PST)
Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2A31C1AE059 for <ietf@ietf.org>; Mon, 6 Jan 2014 08:20:56 -0800 (PST)
Received: by mail-lb0-f170.google.com with SMTP id c11so10101420lbj.1 for <ietf@ietf.org>; Mon, 06 Jan 2014 08:20:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=1CBKqABwUEv0PIDCCgtwW2xxXAZ2bbJmfFmscclLVeQ=; b=d3Yi6ZVWxSjKtgs/rE9RfB77BuTvl+CZn9f+1J5A/tdUAw9Q6tLui9mJzUsG0kivUA sWWZtfaj584Ssj8eYy9PWf7fsX5uJ1DPiVXdhW0uk632sOTHqIc7/VY6fselHgHbfCXm +R3+FC2xwZa09A5Wx1IZy4XYRht2CO1s71oq1eTi1pTOm10GOeZFx9biVku6X7txNGgW +rJyOUQFAl59IQl5Vq2BUx+3nPqhHgDOcJ3haF8VazzzfMN3diyek4IDQ3CyPF8xoxVc yJYdrBV90+PQ4aRLDaUpkrbsJUpxNZJLclgrlxPRIkcEE74NdzR9+BR5bHPz7K6hiHQS 4HlA==
MIME-Version: 1.0
X-Received: by 10.112.138.70 with SMTP id qo6mr1358477lbb.34.1389025248023; Mon, 06 Jan 2014 08:20:48 -0800 (PST)
Received: by 10.112.37.172 with HTTP; Mon, 6 Jan 2014 08:20:47 -0800 (PST)
Date: Mon, 06 Jan 2014 11:20:47 -0500
Message-ID: <CAMm+LwinAb6+7BoMzwBWyu63vofndxK9VY6DSNN0Ykza4SxuMQ@mail.gmail.com>
Subject: Split the IANA functions?
From: Phillip Hallam-Baker <hallam@gmail.com>
To: IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="089e0112c02c7e17bd04ef4fa47e"
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 16:20:59 -0000

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.

Like the DNS, the allocation of IP address space and BGP parameters is a
potential control point. 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.


-- 
Website: http://hallambaker.com/