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

[Izumi Okutani]

CRISP Team,


As we will be discussing this at the call tomorrow, let me re-invite 
feedback for the draft response.

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.

-----
> 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":

   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.


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.

This paragraph describes the principles for a future possibilty that:

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.

-----

Izumi

On 2015/02/28 9:36, Izumi Okutani wrote:
> 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
>
>
>
> _______________________________________________
> CRISP mailing list
> CRISP at nro.net
> https://www.nro.net/mailman/listinfo/crisp