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

[Izumi Okutani]

Hi Andrei and all,


Thanks for your feedback - they are helpful.

 > Izumi, is there a deadline for our response to these questions?
>

Not clear deadline is set by the ICG.

Alan has suggested to target to respond in two weeks, so perhaps target 
to reponse before Tue 10th March.


>> 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.
>>
>
> I agree with Richard Hill's suggestion and would add (as per II.B.3.i.
> you cited):
>
> - The contract under which ICANN carries out operation of the IANA
> functions. The NTIA has the ability to terminate the contract and award
> it to an entity other than ICANN.
>
>>   - 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).
>> ---

I agree Richard's suggestion is good.
I'll reflect it in the response.

> [...]
>>>>    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.
>>
>
> I agree, Izumi, that such coordination should include the names
> communities. I think your propopsal makes a lot of sense, but I'd be
> reluctant to suggest something concrete in our response to the ICG. I
> think we should closely follow the development of the names proposal and
> see if some of the coordination approaches discussed there can work for
> us, too.
>
> As for our response I agree with Seun Ojedeji's suggestion that it
> "should be looked at beyond the transition so that should not necessary
> make the proposal seem incomplete". We may also note that there have

Good point. It is not a must to set this up before the transition.

I agree with you Andrei that we don't want to make it like a complete 
part of our proposal which must be agreed before the transition - at the 
same time, I'd like to give certain level of assurance that we already 
have existing practices.

This may be addressed by stating an example as you have mentioned below.

> been many examples when such cooperation between the communities worked
> whenever the need arose. FWIW, the IETF's response provides one of such
> cases:
>
>> Changes to IETF standards may have impact on operations of RIRs
>>        and service providers.  A recent example is the extensions to BGP
>>        to carry the Autonomous System numbers as four-octet entities
>>        [RFC6793].  It is important to note that this change occurred out
>>        of operational necessity, and it demonstrated strong alignment
>>        between the RIRs and the IETF.
>

Sure and certainly helpful to have examples.
The example you quoted looks relevant for addressing overlaps.

If you look at III.A. referenced in the question (see below for the 
quote), it talks about the need for coordination in case each of the 
operational communities decided to have different IANA operator.

I feel it helps, at least to give an example on how this coordination 
can be achived, as this is the question from the ICG.

On this, Seun also says:
"Well maybe we could include some suggestions on communication between
existing entities which includes the SO/ACs within ICANN."

Which is a short explaination of an idea I had shared, i.e, it's an 
existing mechanism.

I like the ICANN SO/ACs example because this includes names and and an 
existing practice where numbers community is represented as well.

Any thoughts about this?
I'll follow up later in a seperate e-mail with draft response.
This may be after tomorrow my time as I still have other things to work 
with shorter deadlines.

---
III.A. The elements of this proposal
(snip>
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.
---

Izumi