[CRISP-TEAM] [NRO-IANAXFER] Call for submission of comment to the combined ICG proposal and the CRISP Team draft response

Izumi Okutani izumi at nic.ad.jp
Mon Aug 31 17:09:51 CEST 2015 

CRISP Team,


Thanks Paul and John for your feedback.
I'd like to respond to Pranesh as below before UTC23:30 today 31 Aug.


------
Dear Pranesh,


Thank you for your question about the CRISP Team comment and I note your concern about impact on the ability to chose a new IANA Numbersing Services Operator in the future.

> Could the CRISP Team please elaborate on its reasoning behind believing that a singular PTI for all three functions will not hamper its stated need to be able to sever the contract with the INSO and choose a new INSO?
> 

The only change in the combined proposal by the ICG from the number community proposal, is PTI serving as the operator for all three IANA functions, instead of ICANN.
We have not proposed to split the IANA Functions by different operators at the time of the transition.

 * Since we have not proposed to splitting of the operator per function at the time of the transition,
   splitting the IANA Function Operator at the time of the transition will cause inconsistencies with the number community proposal. 
   - The number community proposal says:
     "considering the Internet Number Community’s strong desire for stability and a minimum of operational change, the Internet Number Community believes that ICANN should remain in the role of the IANA Numbering Services Operator for at least the initial term of the new contract"
   - Today, the IANA functions are operated by a single IANA Functions Operator (ICANN), and not by different Operators per IANA Function.
   - It is stated in the number community proposal to have priority to maintain stability and continuity in operations of the IANA Numbering Services, very minimal changes to the arrangements.
  
 * We do not observe any material changes for PTI to serve as IANA Functions Operators instead of ICANN, as we understand this as merely changes in organizational hat of the IFO, without any changes in its staff, system nor operations.
   - In terms of the conctractual arrangement, RIRs will continue to exchange the SLA with ICANN
   - Requirements for the SLA based on the number community proposal are reflected in the 2nd SLA draft.

 * We believe the ability to chose a new IANA Numbering Services Operator if needed in the future is ensured by description in the SLA.
   We observe the second draft SLA gives the RIRs the ability to do so by a single IFO, operated under PTI.
   - The second draft SLA addresses this point by additional clause in under Section 15.11 Sub-Contracting.  
     (See the bottom of the e-mail for the exact lanauge in the SLA). 
   - The condition to Termination remains unchanged and consistent with the number community proposal under Article 10: Term and termination.

Thanks for raising this point and I hope this clarifies your question -  Please let me know if there is any thing which remains unclear about our observation.


Izumi


------
Service Level Agreement for the IANA Numbering Services
[Public Draft v2.0 – 5 August 2015]
https://www.nro.net/wp-content/uploads/Numbers-SLA-2.0-Redline.pdf
------

"15.11.1 Operator shall not sub-contract or delegate to a third party entity for its provision
of the IANA Numbering Services under this Agreement without the prior written
consent of the RIRs, such consent not to be unreasonably withheld.

15.11.2 Notwithstanding the foregoing, any sub-contracting approved by the RIRs shall
not release Operator from, or diminish, its contractual obligations under this
Agreement and Operator shall remain fully liable to the RIRs under this
Agreement.

15.11.3 In the event that Operator sub-contracts or delegates the provision of the IANA
Numbering Services under Article 15.11.1 of this Agreement to a sub-contractor,
then Operator must, at the written request of the RIRs at their sole discretion,
enter into an agreement with the RIRs and sub-contractor to transfer or novate all
Operator’s rights and obligations under this Agreement to the sub-contractor."
------



On 2015/08/28 22:40, Sweeting, John wrote:
> +1
> 
> Sent from my iPhone
> 
>> On Aug 28, 2015, at 5:31 AM, Paul Rendek <rendek at ripe.net> wrote:
>>
>> Hello Izumi,
>>
>> I support this approach.
>>
>> Cheers,
>> Paul
>>
>>> On 8/28/15 10:27 AM, Izumi Okutani wrote:
>>> CRISP Team,
>>>
>>>
>>> We have received a question and clarification.
>>>
>>> While we encourage anyone in the community with a different view from
>>> the CRISP Team to submit their own comment to the ICG, I think we need
>>> to respond to the question about our response.
>>>
>>> If no objection to this approach, I will draft a response which I hope
>>> to share on the global list on Monday.
>>>
>>>
>>> Izumi
>>>
>>>> On 2015/08/28 16:15, Pranesh Prakash wrote:
>>>> Dear Izumi and all,
>>>> Thank you for this.
>>>>
>>>> I must admit I am a bit surprised by this part of the response:
>>>>
>>>>> The names community proposes the creation of a new organization to
>>>>> manage all IANA functions, namely the PTI. Such a structure was not
>>>>> proposed by the other communities. However, we do not believe this
>>>>> creates an incompatibility for the other communities. The Number
>>>>> Community proposal for the RIRs to sign an SLA with ICANN is still
>>>>> possible to implement, and therefore still workable.
>>>>>
>>>>> Further, as a part of the composition of the PTI, the names community
>>>>> proposes creation of additional committees aimed at reviewing service
>>>>> levels and providing operational oversight (namely, the IFRT, special
>>>>> IFRT and the CSC).
>>>>>
>>>>> The Number Community requires no additional reviews or organizational
>>>>> structures beyond the Review Committee that is specified in the Number
>>>>> Community proposal. However, because the scope of the activity of
>>>>> these new structures is limited to the IANA naming function, we see no
>>>>> overlap nor do we see any incompatibility.
>>>>
>>>> When there is no overlap between the PTI proposal of the names community
>>>> (a single new organization for all functions) and that of the Number
>>>> Community, I don't see why this is a suggestion that should be accepted.
>>>>  I do in fact see it being a problem that the policy body for the names
>>>> community (ICANN) will be the entity the Number Community would have to
>>>> contract with, instead of the actual body which will be performing the
>>>> IANA Numbering Services Operator (the "PTI" in the names community's
>>>> lingo).
>>>>
>>>> Indeed, I see difficulty that arises from keeping the three operators
>>>> together, since that limits severability of the contract.  It would
>>>> limit the ability of the Number Community to choose a new Operator if,
>>>> by design, all three functions have the same Operator.  It is far better
>>>> for the operator of each of these functions being separate so that
>>>> impediments don't exist between the ability of the Number Community to
>>>> choose a different IANA Numbering Services Operator without affecting
>>>> the operation of the IANA Names Services Operator or the IANA Protocol
>>>> Services Operator.
>>>>
>>>> Could the CRISP Team please elaborate on its reasoning behind believing
>>>> that a singular PTI for all three functions will not hamper its stated
>>>> need to be able to sever the contract with the INSO and choose a new
>>>> INSO?
>>>>
>>>> Regards,
>>>> Pranesh
>>>>
>>>> Izumi Okutani <izumi at nic.ad.jp> [2015-08-27 08:30:06 +0900]:
>>>>> Dear Colleagues,
>>>>>
>>>>>
>>>>>
>>>>> We would like to share the attached CRISP Team response to the draft
>>>>> IANA Stewardship Transition Proposal for public comment.
>>>>>
>>>>>  IANA Stewardship Transition Proposal: Call for Public Comment
>>>>>
>>>>> https://www.ianacg.org/calls-for-input/combined-proposal-public-comment-period/
>>>>>
>>>>>
>>>>>
>>>>> As described in the call for Public Comment by the ICG:
>>>>>
>>>>> "It is critical that the ICG build a public record that reflects broad
>>>>> community support for the proposal and justifies the proposal’s
>>>>> conformance with the NTIA criteria before the proposal can be
>>>>> submitted to NTIA.
>>>>> Thus, commenters are encouraged to file comments in support of the
>>>>> proposal even if they have no concerns to express about the proposal."
>>>>>
>>>>> You can contribute to the process in three ways as described below.
>>>>>
>>>>> 1. Submit your own comment to the ICG
>>>>>   We strongly encourage you to submit your comment to the ICG.
>>>>>   This helps the ICG to build public record that the combined
>>>>> proposal has support of the broad community.
>>>>>
>>>>>   - It is not a requirement to respond to all questions from the ICG.
>>>>>     Submission of comments expressing a general support for the
>>>>> proposal itself would be helpful enough, without responding to
>>>>> specific aspects of the proposal.
>>>>>   - Please feel free to use the CRISP Team response as a reference,
>>>>> in considering contents for your own submission.
>>>>>     Words in bold letters cover a general observation which could be
>>>>> applicable to anyone in the Number Community.
>>>>>     Details specific to the CRISP Team are in italics.
>>>>>
>>>>>     Deadline of the submission: 8 September 2015 at 23:59 UTC
>>>>>      - You can submit your comment using the online form or by e-mail
>>>>> to <public-comments at ianacg.org>.
>>>>>        For details see:
>>>>> https://www.ianacg.org/calls-for-input/combined-proposal-public-comment-period/#instructionssubmitcomment
>>>>>
>>>>>
>>>>>
>>>>> 2. Help spread the word
>>>>>   Encourage others to submit comments to the ICG.
>>>>>
>>>>> 3. Express support to the CRISP Team response to the ICG
>>>>>   Support expressed by e-mail to <ianaxfer at nro.net> before 7
>>>>> September 2015 23:59 UTC will be recorded as the level of support from
>>>>> the Number Community to the CRISP Team response.
>>>>>   We will share this in our response to the ICG, but will not share
>>>>> the names of individuals who expressed support. We therefore encourage
>>>>> you to submit your own comment to the ICG in addition, as described
>>>>> in 1.
>>>>>
>>>>>
>>>>> We are looking forward to your contributions in this important phase
>>>>> of the process, as an opportunity to express support towards the
>>>>> transition which will be lead to bottom-up, community based oversight
>>>>> mechanism for the IANA functions.
>>>>>
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Izumi Okutani and Nurani Nimpuno
>>>>> on behalf of the CRISP Team
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> ianaxfer mailing list
>>>>> ianaxfer at nro.net
>>>>> https://www.nro.net/mailman/listinfo/ianaxfer
>>>
>>> _______________________________________________
>>> CRISP mailing list
>>> CRISP at nro.net
>>> https://www.nro.net/mailman/listinfo/crisp
>>
>>
>> _______________________________________________
>> CRISP mailing list
>> CRISP at nro.net
>> https://www.nro.net/mailman/listinfo/crisp
> 
> This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
> _______________________________________________
> CRISP mailing list
> CRISP at nro.net
> https://www.nro.net/mailman/listinfo/crisp
>

More information about the CRISP mailing list