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

[Izumi Okutani]

Thanks Alan for this - I like the approach of quoting from the proposal.
Quick comments before I fly for APRICOT.

Please see my reponse inline.

On 2015/02/27 20:59, Alan Barrett wrote:
> Here are some of my thoughts on the additional queastions.
>
>
>> II.B.2. If the policy sources identified in Section II.A are affected,
>> identify which ones are affected and explain in what way.
>>
>> 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":
>
>    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).

Add below to asnwer the second question.

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
>> 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.

Add below: (I assume this is the part which is not clear to the ICG)

Based on this requirements, RIRs will initiate the process of setting up 
the Review Committee. RIR communities already have precedence and well 
estabilished processes in selecting community representatives, such as 
for ASO AC and the CRISP Team.

> 2b: How will the Review Committee operate?
>
> The Review Committee will review the level of service provided by the
> IANA Numbering Services Operator (which will initially be ICANN), 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 ny other ICANN-related
> review committees?
>
> It is not related to any other committees.

Add below: (should explain why they are not related)


As the Review Committee's role is to provide advice to RIRs in 
conducting reviews on the service level of IANA Numbering Services, its 
scope is limited to the number resources component of the IANA function 
and has no overlaps with other ICANN-related review committees.

>> 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 significant
> coordination may be required to ensure stability.

Reflect Andrei's feedback:

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 CRISP proposal does not specify how such coordination might take
> place, it merely records that coordination may be necessary.
>

My observation:
I'm not sure if this answers the question and concern from the ICG.
I think they are looking for a little more specific idea and a certain 
level of certainty that coordination can take place when needed.

Also, we may want to at least set direction on what is desirable so if 
some idea such as creating a new coordination body or commmittee comes 
up, we can say this is not the direction we intended.

I agree with Andrei and Nurani we shouldn't make our proposal sound 
incomplete without agreeing on a particular solution. Without doing so, 
perhaps can we say we already have existing practices in ICANN therefore 
confident we can work out a way?

Suggested response:


The numbers proposal on this paragraph describes the principles for a 
future possibilty:

- 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.

It recognizes and records such coordination would be needed and details 
are to be discusssed by all operational communities, including names and 
protocol parameters, in the event which needs such coordination.

There are already exising mechanisms which allows such coordination to 
happen, SOs and ACs representing the three operational communities as an 
example. We expect to make use of such existing mechanisms which works 
today for effective coordination.



Izumi