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

[Izumi Okutani]

Hi Andrei and all,


Thanks for starting this. Very helpful.

My comments in line with draft response except Q3.

I welcome feedback from the team.


On 2015/02/24 19:40, Andrei Robachevsky wrote:
> Hi,
>
> Some initial thoughts, I am interested to hear others opinion,
> especially on the last question.
>
> Izumi Okutani wrote on 24/02/15 11:10:
> [...]
>
>> ----
>> 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?
>>
>
> Looking through the SoW, the element is oversight of performance
> standards (see sections C.2.8, C.4.2., C.4.4.) and inspection and
> acceptance (C4.7. and Section E). I think in our proposal oversight is
> rested with the RIRs, facilitated by the SLA and the Review Committee.
> Failure to meet these requirements may result in termination of the
> agreement.

Thanks for going through the agreement.


Draft response:

The IANA stewardship transition by the NTIA would remove a significant 
element of oversight role NTIA plays, as decribed in Section II.B.3.i.

  - The role that NTIA is playing in obliging ICANN as the IANA function
    operator, to to manage the IANA Number Registries according to
    policies developed by the Internet Number Community.
  - NTIA reviews service level o the IANA function operator, including
    that of the IANA Numbering Services, based on what is defined in the
    IANA contract between ICANN and NTIA
     (sections C.2.8, C.4.2., C.4.4.,C4.7. and Section E)

This will be replace wiht the contract between ICANN and RIRs, and RIRs 
will conduct review of the Service Level, with advice from the Review 
Committee.

---
II.B.3.i. NTIA

ICANN, as the current IANA Numbering Services Operator, is obligated by 
the NTIA agreement to manage the IANA Number Registries according to 
policies de veloped 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).
---

>
>>
>> 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.
>>>
>>> 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.
>>
>>
>>   III.A.
>>   Question2:
>>   How will the Review Committee be established, how will it
>>   operate, and how is it related to any other ICANN-related review
>>   committees?
>
> Consistent with our overall approach we only provided essential
> requirements, like the objective of the committee, equal representation
> from each RIR region, and open, transparent, and bottom-up process of
> the selection of its representatives. Since the Review Committee only
> facilitates the oversight function, performed by the RIRs, we left the
> details of it to the RIRs and their respective communities.
>
> The Review Committee does not relate to any of the ICANN-related review
> committees.

I agree.

Draft response:

The CRISP Team proposal has described the essential requirements of the 
Review Committee such as the objective of the committee, equal 
representation from each RIR region, and open, transparent, and 
bottom-up process of the selection of its representatives.

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.

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 have 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 is a very good question. As I mentioned in my previous e-mail there
> might be a need for a more formal documentation of such coordination.
> For instance, early in the process of the development of the CRISP
> proposal there was an idea of affirmation of commitment between the RIRs
> and the IETF.
>

Yes indeed. I think this was the part we intentionally left it withouth 
defining too much as it requires coordination with other operational 
communities.

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

Would the AoC between RIRs and IETF is to cover the overlaps in number 
resources to distinct about specfication(IETF) and management and 
distribution (RIRs)?

I personally think it may be useful to have such AoC regardless, but for 
this question, it seems to me that we still need to cover a mechanism on 
how we coordinate including the names.

In my opinions, it would be preferable to make use of existing channels 
for coordination, rather than creating new ones, one for the prove that 
it works and second for miminizing the work required.

Based on this thinking, one idea which comes to my mind is to make use 
of existing ICANN stakeholder groups as a POC for coordination.

  i.e. Number - ASO, Names - GNSO, ccNSO, Protocols - IETF

They will each select representatives of their group for coordination, 
like they would for any Cross Community Working Group within ICANN.

What are people's thoughts on this?
I'm just putting an idea of on the table and interested to hear other 
ideas as well.


Izumi