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

Tobias Gondrom <tobias.gondrom@gondrom.org> Sun, 03 May 2015 14:59 UTC

Return-Path: <tobias.gondrom@gondrom.org>
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 1C7051A3B9C for <ianaplan@ietfa.amsl.com>; Sun, 3 May 2015 07:59:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.664
X-Spam-Level:
X-Spam-Status: No, score=-96.664 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=1.951, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no
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 C5LfDuFMYnoO for <ianaplan@ietfa.amsl.com>; Sun, 3 May 2015 07:59:20 -0700 (PDT)
Received: from lvps5-35-241-16.dedicated.hosteurope.de (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 415A71A3B9B for <ianaplan@ietf.org>; Sun, 3 May 2015 07:59:19 -0700 (PDT)
Received: from [192.168.178.28] (x590f0478.dyn.telefonica.de [89.15.4.120]) by lvps5-35-241-16.dedicated.hosteurope.de (Postfix) with ESMTPSA id 3B09663496; Sun, 3 May 2015 16:59:17 +0200 (CEST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=a3yYlRtnxNJtQBS7bFJOZ4a2q08MWD6/H9R8S66FwBTOS8M/7DahZ/6y3l2hdCcKjKe88Kh6dr7fn4zhM9+FAtrno+wuByoSWphIGVmr6mXb33CosT3cWZHqmWfh124I3V1dcIl1Ds7Gmh/jlkIv/rG1UHKrLHidTNI042hJEUE=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type;
Message-ID: <554637C4.2010400@gondrom.org>
Date: Sun, 03 May 2015 16:59:16 +0200
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: alissa@cooperw.in, ianaplan@ietf.org
References: <6FADE19B-E3BD-48F8-9A2D-91FA6F88E6DC@cooperw.in>
In-Reply-To: <6FADE19B-E3BD-48F8-9A2D-91FA6F88E6DC@cooperw.in>
Content-Type: multipart/alternative; boundary="------------010006060005070801060300"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/QE1doCwk_A-EstWNLZkmKSGuNqM>
Subject: Re: [Ianaplan] Transition proposal for naming-related functions
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: Sun, 03 May 2015 14:59:23 -0000

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?

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 
> <https://www.icann.org/public-comments/cwg-stewardship-draft-proposal-2015-04-22-en>;. 
> 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
> Ianaplan@ietf.org
> https://www.ietf.org/mailman/listinfo/ianaplan