Re: [Ianaplan] Transition proposal for naming-related functions

Alissa Cooper <> Mon, 04 May 2015 20:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 374151A8A97 for <>; Mon, 4 May 2015 13:42:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7b_pykxM6dUV for <>; Mon, 4 May 2015 13:42:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6EC2D1A8869 for <>; Mon, 4 May 2015 13:42:49 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id C4E53208D5 for <>; Mon, 4 May 2015 16:42:48 -0400 (EDT)
Received: from frontend2 ([]) by compute2.internal (MEProxy); Mon, 04 May 2015 16:42:48 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=YRab1 +P50btaft2W4ehTlY7oYLk=; b=r0WH6Gf3HlB74K0Ft523+ueiq/4ssN5JitviB jnCrYaKQVKPD/Q+0eSDidcyEZJJpP1QFobc7H3yg4WeNaFVxcktLWrfUeStp1mBb YVlR4m5Xg2K7Ud+G1sD1/TYR35yTtPbH5MTjoeFc8eyaYXrZnyFvoid5wEUMc3+g ROjMCo=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=YRab1+P50btaft2W4ehTlY7oYLk=; b=gFXIU 15M4GfEv8qC2T/klgmKqecp8z8WHTl81uaovzGi/gHnb6ybJxHTFIZmzHB7s64WU dbEwceTREslhXss1MRoisU7A/dY7PIT3YggOcQXIb6pptbeBOu+F+G/Tu8CfuZnk hxZlKc+0ltdqSkFV+zFKr1ZQUMhbWBHySYwEuA=
X-Sasl-enc: fGO/CLRABoajRni2mEFJze95E/5l5HVNx+Rl/8TsEW1/ 1430772168
Received: from (unknown []) by (Postfix) with ESMTPA id C857B680117; Mon, 4 May 2015 16:42:47 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7FF44AC7-4DED-4973-B4B3-BA9B7B1786CE"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Alissa Cooper <>
In-Reply-To: <>
Date: Mon, 04 May 2015 13:42:42 -0700
Message-Id: <>
References: <> <>
To: Tobias Gondrom <>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <>
Subject: Re: [Ianaplan] Transition proposal for naming-related functions
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: Mon, 04 May 2015 20:42:52 -0000

Hi Tobias,

On May 3, 2015, at 7:59 AM, Tobias Gondrom <> wrote:

> Dear Alissa, 
> just a small question for my understanding: 
> as the proposal speaks about ownership and transferring data to PTI for naming functions, but also mentions possible implications for non-naming functions. Is there any implicit assumption that such a PTI entity would aspire ownership or copyright for the data in the IANA registries? 
> Would it make sense that we make it more clear in the context of this proposal that PTI is not assuming ownership of that data? 

With my individual participant hat on, I would say that yes it would make sense. I haven’t looked into these provisions of the draft proposal in detail but in my brief reading it seemed like it wasn’t entirely clear what the expectation is as far as ownership/copyright of the data in the registries.


> Just a thought. 
> Best, Tobias
> On 29/04/15 15:25, Alissa Cooper wrote:
>> Dear IETF community,
>> You may be aware that the Cross Community Working Group developing the IANA stewardship transition proposal for naming-related functions has recently put its proposal out for public comment <>. We wanted to highlight a few aspects of the proposal that we believe would benefit from review and perhaps comment by your community:
>> 1) Overlaps and interdependencies (Section I.D and Annex A)
>> As in your community’s proposal, the CWG proposal contains information concerning overlaps and interdependencies with the other communities.
>> 2) Post-Transition IANA (Section III)
>> The CWG is proposing that a new separate legal entity, Post-Transition IANA (PTI), would be formed as an affiliate of ICANN. The existing IANA naming functions, administrative staff and related resources, processes, data and know-how would be legally transferred into PTI. Your community may want to consider a number of associated implications:
>> * The likelihood that personnel and resources dedicated to the non-naming IANA functions would be moved to PTI. Your community may also want to consider its view on having all IANA functions provided by the same entity or allowing them to be separated.
>> * Contracting. For existing or new contracts your community may have related to the IANA functions, there may be multiple options available, including maintaining existing contracts with ICANN and letting them subcontract their execution to PTI, assigning an existing contract to PTI, or re-contracting with PTI.
>> * PTI Board. The composition of the PTI Board is not highly specified in the CWG proposal. There has been some discussion within the CWG about including representation for the RIRs and IETF on the PTI Board.
>> * PTI ownership. If the PTI is formed as an affiliate of ICANN as the CWG proposes, as a legal entity it would be wholly owned by ICANN. Your community may want to consider its view of this whole ownership versus joint ownership involving all or multiple communities.
>> 3) Liaisons to IANA Functions Review Team (Section III.A.i.d and Annex F)
>> The CWG proposes that the performance of IANA be periodically reviewed post-transition and that the numbering and protocol parameter communities be offered the opportunity to appoint liaisons to the team performing reviews.
>> 4) Customer Service Complaint Resolution Process (Annex I)
>> The CWG proposes a complain resolution process for naming-related services, but which is open to the protocol parameters and numbering resources communities.
>> 5) Composition of the Customer Standing Committee (Section II.A.ii.a and Annex G)
>> The CWG proposes the creation of a Customer Standing Committee (CSC) to monitor the performance of the IANA naming function. The proposal mentions the possibility of IAB representation on the CSC. 
>> If the ICG can be of further assistance in coordinating your review or understanding of the CWG proposal, please let us know.
>> Thanks,
>> Alissa Cooper on behalf of the ICG
>> _______________________________________________
>> Ianaplan mailing list