[CRISP-TEAM] Additional questions from the ICG on the numbers proposal

Alan Barrett apb at cequrux.com
Fri Mar 13 13:30:46 CET 2015


On Fri, 13 Mar 2015, Izumi Okutani wrote:
>I have re-formated my last e-mail I sent out on 28th Feb (JST), so Q & 
>A is more clear for review. There are no changes in terms of contents.

Thank you.  I identified a few typos or grammatical errors, but
otherwise I am hapy with this draft response.

>-----
>>II.B.2. If the policy sources identified in Section II.A are affected, identify which ones are affected and explain in what way.
>>
>>Response in the numbers proposal:
>>>A decision by the NTIA to discontinue its stewardship of the IANA Numbering Services, and therefore its contractual relationship with the IANA Functions Operator, would have no significant impact on the continuity of IANA Numbering Services currently provided by ICANN. However, it would remove a significant element of oversight from the current system
>>>
>>>ICANN has historically provided IANA Numbering Services via the IANA Number Registries under the terms of the NTIA IANA Functions contract, and therefore IANA Numbering Services for the RIRs are currently subject to change in accordance with that agreement.
>>
>> Question1:
>> What specifically is the “element of oversight” which is referred to
>> in this section, and how is it to be replaced under this proposal?
>
>
>The element of oversight that the NTIA provides for the IANA Numbering 
>Services is the ability to change the contract with ICANN.
>
>This is stated in the the very next paragraph of the CRISP proposal 
>(the last parwithgraph of section III.B.2), immediately after the 
>sentence that says "it would remove a significant element of 
>oversight":

s/parwithgraph/paragraph/

>
>  ICANN has historically provided IANA Numbering Services via
>  the IANA Number Registries under the terms of the NTIA IANA
>  Functions contract, and therefore IANA Numbering Services for
>  the RIRs are currently subject to change in accordance with
>  that agreement.
>
>Section II.B.3.i expands on this:
>
>  ICANN, as the current IANA Numbering Services Operator, is
>  obligated by the NTIA agreement to manage the IANA Number
>  Registries according to policies developed by the Internet
>  Number Community.
>
>  Although the IANA operator escalation and reporting mechanisms
>  are public in nature, the NTIA has an oversight role in the
>  provision of the services through its contract with ICANN. The
>  ultimate consequence of failing to meet the performance
>  standards or reporting requirements is understood to be a
>  decision by the contracting party (the NTIA) to terminate
>  or not renew the IANA Functions Agreement with the current
>  contractor (ICANN).
>
>The proposed new contract between the NRO/RIRs and ICANN replaces the 
>existing IANA Functions contract on the IANA Numbering Services. It 
>provides the same type of oversight, that is, the possibility of 
>delegating IANA Numbering Services to an entity other than ICANN and 
>provisions on how the IANA function should be performed.
>
>
>>III.A. The elements of this proposal
>>Response in the numbers proposal:
>>>1. ICANN to continue as the IANA Functions Operator for the IANA Numbering Services, hereinafter referred to as the IANA Numbering Services Operator, via a contract with the RIRs;
>>>2. IPR related to the provision of the IANA services remains with the community;
>>>3. Service Level Agreement with the IANA Numbering Services Operator; and
>>>4. Establishment of a Review Committee, with representatives from each RIR, to advise the NRO EC on the review of the IANA functions operator’s performance and meeting of identified service levels.
>>>
>> Question2:
>> How will the Review Committee be established, how will it
>> operate, and how is it related to any other ICANN-related review
>> committees?
>>
>
>2a: How will the Review Committee be established?
>
>The Review Committee will be established by the RIRs, there will be 
>equal representation from each RIR region, and members will be 
>selected in an open, transparent, and bottom-up manner appropriate for 
>each RIR region.
>
>This is explained in section III.A.4 of the CRISP proposal:
>
>  The RIRs shall establish a Review Committee [...].
>
>  The Review Committee should be a team composed of suitably
>  qualified Internet Number Community representatives from each
>  RIR region. The selection of the Review Committee members
>  should be conducted in an open, transparent, and bottom-up
>  manner appropriate for each RIR region. There should be
>  equal representation from each RIR region within the Review
>  Committee.
>
>Based on this requirements, RIRs will initiate the process of setting 
>up the Review Committee. the RIR community already has precedence and 
>well established processes in selecting community representatives from 
>each RIR region, such as selecting representatives for the ASO AC, and 
>the CRISP Team.

s/this requirements/these requirements/.

s/the RIR community already has precedence/The RIR community already has
precedents/.

>2b: How will the Review Committee operate?
>
>Based on the SLA, the Review Committee will review the level of 
>service provided by the IANA Numbering Services Operator (ICANN at the 
>time of the transition), and will report any concerns to the NRO EC.  
>The Review Committee will not do anything else.  The Review 
>Committee's activities will be conducted in an open and transparent 
>manner.
>
>This is explained in section III.A.4 of the CRISP proposal:
>
>  The RIRs shall establish a Review Committee that will advise
>  and assist the NRO EC in its periodic review. The Review
>  Committee will, as needed, undertake a review of the level of
>  service received from the IANA Numbering Services Operator and
>  report to the NRO EC any concerns regarding the performance
>  of the IANA Numbering Services Operator, including especially
>  any observed failure or near-failure by the IANA Numbering
>  Services Operator to meet its obligations under the proposed
>  agreement. Any such Review Committee will advise the NRO EC
>  in its capacity solely to oversee the performance of the
>  IANA Numbering Services, and the Review Committee's advice
>  and comment will be limited to the processes followed in the
>  IANA Numbering Services Operator's performance under the
>  proposed agreement. Activities of the Review Committee shall be
>  conducted in an open and transparent manner. Reports from the
>  Review Committee shall be published.
>
>2c: How is the Review Committee related to any other ICANN-related
>review committees?
>
>It is not related to any other committees.
>
>The Review Committee's role is to provide advice to RIRs in conducting 
>review on the service level of IANA Numbering Services. Its scope is 
>limited to the number resources component of the IANA function which 
>has no overlaps with other ICANN-related review committees.
>
>
>> III.A. The elements of this proposal
>>  Question3:
>>  Given the stated need for “communication and coordination” between
>>  the communities, how is this to be achieved under this proposal?
>
>This question seeme to refer to the last paragraph of section III.A of 
>the CRISP proposal:
>
>  This proposal assumes that specific IANA customers (i.e., the
>  number community, the protocol parameter community, and the
>  name community) will have independent arrangements with
>  the IANA Functions Operator related to maintenance of the
>  specific registries for which they are responsible. At the
>  same time, the Internet Number Community wishes to emphasize
>  the importance of communication and coordination between these
>  communities to ensure the stability of the IANA services. Such
>  communication and coordination would be especially vital
>  should the three communities reach different decisions
>  regarding the identity of the IANA Functions Operator after
>  the transition. Efforts to facilitate this communication and
>  coordination should be undertaken by the affected communities
>  via processes distinct from this stewardship transition
>  process.
>
>
>In the event that all three communities (numbers, protocol parameters, 
>and names) choose the same IANA operator, then we expect that minimal 
>coordination will be required. In the event that different IANA 
>operators are chosen by different communities, then coordination will 
>be required to ensure coherency of the IANA functions.
>
>The numbers proposal merely records that coordination may be necessary 
>for such future possibility.
>
>If such event occurs in the future which require coordination, there 
>is an exising mechanism which enables such coordination, as SOs and 
>ACs representing the three operational communities. We could make use 
>of such existing mechanism.
>
>-----

--apb (Alan Barrett)




More information about the CRISP mailing list