Re: [Ianaplan] CWG draft and its impact on the IETF

Jari Arkko <> Fri, 22 May 2015 20:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 008261A87E9 for <>; Fri, 22 May 2015 13:32:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Gpa_atkVzpgv for <>; Fri, 22 May 2015 13:32:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A612F1A87E2 for <>; Fri, 22 May 2015 13:32:45 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C3142CC5F; Fri, 22 May 2015 23:32:43 +0300 (EEST) (envelope-from
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mgCT8VHy6cBP; Fri, 22 May 2015 23:32:43 +0300 (EEST)
Received: from [] ( [IPv6:2a00:1d50:2::130]) by (Postfix) with ESMTP id C30D92CC5A; Fri, 22 May 2015 23:32:42 +0300 (EEST) (envelope-from
Content-Type: multipart/signed; boundary="Apple-Mail=_56C72D68-2A04-4419-9822-2992D5661D23"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Jari Arkko <>
In-Reply-To: <>
Date: Fri, 22 May 2015 23:32:41 +0300
Message-Id: <>
References: <> <> <> < > <> <> <> <> <> <> <> <> <> <> <> <000001d091f7$266de3f0$7349abd0$@ch> <> <> <> <> <> <DM2PR0301MB065543B4DCBCB> <> <>
To: "Lynn St.Amour" <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
Cc: "" <>
Subject: Re: [Ianaplan] CWG draft and its impact on the IETF
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 May 2015 20:32:48 -0000


> Many of the postings on this thread seem to assume unfavorable conditions for the PTI/PTI Board, etc.   That is because the Names community has not had time to complete all their work..  I think we can help them advance their work, which frankly is our work as well, and is in the interest of a global public Internet.
> Here are my working assumptions, please correct them if they are off the mark.  They are obviously missing lots of detail.
> 1 - We support (as good practice) separation between policy, oversight, and implementation for the 3 components of the IANA function (in each of the 3 areas - the so-called 3x3)
> 2 - Protocol Parameters has this (and btw, this PTI proposal was modeled heavily on the IETF)
> 3 - Numbers also largely has this.
> 4 - The Names community is trying to get to this.
> 5 - There is a preference for the 3 IANA functions to stay together at the IMPLEMENTATION role (only), but it is not seen as necessary from any of the operating communities (OC's).
> More specific to the CWG proposal:
> A - The PTI would be a narrow purposed organization built to house only the IANA IMPLEMENTATION functions (preferably for all three operating communities?, and I believe the IETF and RIR's assume the work would be done within the PTI *if* that structure goes forward (that is the IANA staff would be housed within the PTI even while their contracts may remain with ICANN).    This should be clarified as soon as their processes allow, as this seems to be one of the points of confusion.  
> B - The PTI would have its own board and would be responsible for the PTI  (many models to accomplish this - even with the funding considerations)
> C - The PTI Board need not have a majority of ICANN Board members - this is the current discussion within Names about ‘inside’ and ‘outside'.   The options would allow, I believe, for a full spectrum of:  no special role for ICANN to a strong central role for ICANN.   
> I believe the Names community would appreciate input/specific questions from the IETF - and I believe it would be useful to all of us if we could look at the proposal and see what we might be able to live with (or not be able to live with).  Either way we advance the discussion if we can share some concrete questions/preferences.   If we identify too many hurdles, well at least we can be specific on why it won't work for us, and again that will help the OC's and the ICG to advance the transition proposal.  For example, could the IETF identify some preferences re Board composition/by-laws/policies, etc.  Frankly, I can see some benefits to working with a purpose built PTI vs. the full-bodied ICANN :-) . 
> If the 3 operating communities could come to agreement on how the proposals fit together, it would help advance the Transition proposal work significantly - for the OC's as well as the ICG.  

Thank you for this. I agree.