[Ianaplan] CWG draft and its impact on the IETF

Eliot Lear <lear@cisco.com> Mon, 11 May 2015 18:42 UTC

Return-Path: <lear@cisco.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 20DBC1ACEAF for <ianaplan@ietfa.amsl.com>; Mon, 11 May 2015 11:42:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 xdihsstQsTQD for <ianaplan@ietfa.amsl.com>; Mon, 11 May 2015 11:42:21 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD7001ACEAE for <ianaplan@ietf.org>; Mon, 11 May 2015 11:42:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10975; q=dns/txt; s=iport; t=1431369741; x=1432579341; h=message-id:date:from:mime-version:to:subject; bh=c/PwtXs9s9rU4M5a9T/TcIQos9sBpGr9P4cdNnD3GK4=; b=Uej95kXlibutD117Om4Ywu/SCP+w9a+NFIndsdEsUHBxnL6o2/E1wQGG iz5s/dV6c+gqDbIFKfKyIhWhGLyBFbwSCXF0RtqnukzZTsQ2s8pWJ7/aJ p1THkD953nCyYyEi0OsbwAe8bCHAjkIMYS5NpnI/pERJKjjweN1b87JDk s=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AoBAAA91BV/xbLJq1cg2McAUGDHsFaCYFahheBXhQBAQEBAQEBgQqEJSVPICMhAhECTAoDBgIBARCIGA2XV40wj1eTWgEBCAEBAQEBGQSTLYFFBZRCgTyHIoEkhjUhjl0jYYEoHIFUPDEBgkUBAQE
X-IronPort-AV: E=Sophos;i="5.13,409,1427760000"; d="asc'?scan'208,217";a="491785559"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 11 May 2015 18:42:19 +0000
Received: from [10.61.211.148] ([10.61.211.148]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t4BIgI2H009711 for <ianaplan@ietf.org>; Mon, 11 May 2015 18:42:18 GMT
Message-ID: <5550F809.80200@cisco.com>
Date: Mon, 11 May 2015 20:42:17 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "ianaplan@ietf.org" <ianaplan@ietf.org>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="ErNjhvl8QQFva3rhR25lkpSalJvtwtiB0"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/mFZhcb5TUtpapZdJDZnDZ5QMYKs>
Subject: [Ianaplan] CWG draft and its impact on the IETF
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: Mon, 11 May 2015 18:42:24 -0000

Hi everyone,

I'm writing this with an eye toward a conversation that perhaps the IAB
and IAOC might find useful, as they consider various activities relating
to the IANA transition.

Over the last week or so, I read through the CWG proposal for the naming
component of the IANA functions transition proposal.  That proposal can
be found at [1].  I'm posting some comments here strictly as relates to
the IETF relationship with ICANN, and not the rest of it, since that
discussion should occur elsewhere.

The basis of the naming community's proposal is to create a new entity
to take on the IANA functions, known as Post-Transition IANA (PTI)[2]. 
That entity would be a wholly owned subsidiary of ICANN, but have its
own management structure, including a customer service component, known
as the Customer Standing Committee.  All current IANA functions would be
transferred to the PTI under this proposal.  A multistakeholder IANA
Function Review  (IFR) process is created as well.  In a sense, the
proposal is vaguely reminiscent of our own arrangements.  In particular
it seems that the names community also wants to a customer relationship
with the IANA Functions Operator (IFO) and to have the choice to change
providers, should that ever become necessary.  There's a bunch of
mechanism proposed to reduce the likelihood of a change, including
escalation, a separation review, etc., but at the end of the day the
choice would be the naming community's, just as the IAB has had the
choice to continue the protocol parameters arrangement.

How does this affect the IETF? 

First, if all functions are meant to be transferred to the PTI, it seems
that the IAB would have to agree to an assignment, per the terms of
RFC-2860.[2]  Second, since for the first time the naming community
would have a choice in whether they wish to change IFO, we have to ask
the question, “What if they did?”  What would happen to the PTI?  What,
in particular, are the funding implications?  It has always been
possible for ICANN or the IAB to terminate the arrangement.  If that
happened, however, the IAB and IAOC would have to work with ISOC to
determine a funding source for a new IFO for protocol parameters. 

It's worth noting that NRO Executive Council has stated that they wish
to retain a direct relationship with ICANN, and NOT the PTI[4].  The IAB
could do the same, but then it seems to me that the value of the PTI
itself is diminished.  And so that brings us back to the cardinal
question: what's right for the Internet?  Here I understand that
different people will have varying views.

Having the burden of funding shift to another source can itself be a
source of instability.  The CWG proposal contains the FY15 budget costs
for the IANA function.  That total is $6.3 million[6], but includes
indirect and shared costs as well.  What isn't in those costs is an
allocation across functions.  At the very least we should have that
information.  Preferably we should have those costs separately funded,
to the extent possible.  This would provide the naming community all the
freedom they want, and us all the freedom we want, without budgetary risk.

Having written that last line, I feel the need to once again point out
what we said in our response, that we are satisfied with the performance
of ICANN as IFO, and have been for quite some time, and that all of this
is still contingency planning.[5]

And so questions:

  * Under this new arrangement, does it make sense to continue the
    relationship with ICANN as it stood before or does it make sense to
    go directly to PTI?
  * If the arrangement is with PTI, should we seek a budgetary
    separation, and what would be the complexities of that?

I think there may be other questions for the CWG proposal, but to me
these are the big questions.

Eliot
[1]
https://www.icann.org/en/system/files/files/cwg-stewardship-draft-proposal-with-annexes-22apr15-en.pdf
[2] See III.A bullet 1.
[3] RFC 2860
[4] Message from Axel Pawlik to icg-forum@icanncg.org on 10 May 2015,
"Numbers community proposal contact points with CWG’s Draft IANA".
[5] draft-ietf-ianaplan-icg-response.
[6] See Annex P of the CWG draft.