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

[Nurani Nimpuno]

Hi all, 

Some comments from me. 

On 26 feb 2015, at 14:11, Izumi Okutani <izumi at nic.ad.jp> wrote:

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

Agreed.

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

Yes agreed. I think we need to acknowledge that coordination is necessary, that it should include the names community, but the proposal is not incomplete without such details. This was not an oversight from our part, but a pragmatic decision. 

Also, it all depends on the state of affairs once all the proposals are in. We cannot coordinate things, before we know what needs to be coordinated. We know what the IETF wants, but we still don't have a proposal from the names community. So while I agree in principle that it often makes sense to use existing structures, I think it's premature to define structures and bodies before we know these things. 

(One such question is whether the three IANA functions should always be kept together. Both Numbers and IETF don't think that's a requirement, while parts of the CWG seem to be arguing for this.) 

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

Yes, I agree on something brief of this nature, but if so, it needs to be "could include" or something or rather. Nothing more specific than that.  
I realise the ICG want to proceed with as much as they can even before the CWG has submitted their proposal, so as to meet the deadline. But we cannot define these things before we know how much the CWG differs from the other two, and in what way. (It's like choosing your tools before you know what you're making.:) )

Nurani

> 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
> 
> 
> _______________________________________________
> CRISP mailing list
> CRISP at nro.net
> https://www.nro.net/mailman/listinfo/crisp