[CRISP-TEAM] [NRO-IANAXFER] ianaxfer Digest, Vol 12, Issue 2
Izumi Okutani
izumi at nic.ad.jp
Mon Sep 7 20:25:56 CEST 2015
CRISP Team,
This comment appears to be based on some misundertanding that Review Committee will not cover the performance of the IANA Numbering Services operated by PTI.
If you take a look at the draft review committee charter, it states its main function is to provide period advice to assist the NRO EC in its periodic review of the service level of the IANA Numebering Services.
(Can't do the exact quote due to bad format of copying from PDF)
https://www.nro.net/wp-content/uploads/Review-Committee-Charter-draft-Public-v1.pdf
It does not affect whether IFO is ICANN or PTI, as the review on the IANA Numbering Services by the Review Committee can be covered either way.
I would like to suggest clarifying this misunderstanding on the global ianaxfer list, as the comment is based on incorrect fact which may be misleading to others.
I would like to post this explanation in 12 hours time from now, if there are no concerns expresesd by the CRISP Team memers but let me know if you have other thoughts.
Izumi
On 2015/09/07 18:28, Shiva Upadhyay wrote:
> Dear CRISP Team,
> Please see the comment below :
>
>
>
> WhenCRISP team was developing the numbering community proposal to be submitted tothe ICG, there was no such proposed body called Post Transition IANA (PTI) and numberingcommunity was satisfied with ICANN as IANA function operator (IFO) post transition. It proposed that reviewcommittee will advise the NRO EC regarding ICANN’s performance and meeting of identifiedservice levels (as per the new service level agreement).
>
> However,as per the above graphic, a new body PTIwill act as a IFO and there is no point ofreviewing the work/performance as per the new SLA of ICANN alone. Reviewingcommittee should also review the work/performance of PTI also in addition toICANN, since in future there will be a new body called PTI which will be servingas the IANA function operator.
>
>
> Regards,
> Shiva Upadhyay
>
>
> On Tuesday, 1 September 2015 3:30 PM, "ianaxfer-request at nro.net" <ianaxfer-request at nro.net> wrote:
>
>
> Send ianaxfer mailing list submissions to
> ianaxfer at nro.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.nro.net/mailman/listinfo/ianaxfer
> or, via email, send a message with subject or body 'help' to
> ianaxfer-request at nro.net
>
> You can reach the person managing the list at
> ianaxfer-owner at nro.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ianaxfer digest..."
>
>
> Today's Topics:
>
> 1. Re: Call for submission of comment to the combined ICG
> proposal and the CRISP Team draft response (Izumi Okutani)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 01 Sep 2015 08:57:33 +0900
> From: Izumi Okutani <izumi at nic.ad.jp>
> To: Pranesh Prakash <pranesh at cis-india.org>, "ianaxfer at nro.net"
> <ianaxfer at nro.net>
> Subject: Re: [NRO-IANAXFER] Call for submission of comment to the
> combined ICG proposal and the CRISP Team draft response
> Message-ID: <55E4E9ED.6010907 at nic.ad.jp>
> Content-Type: text/plain; charset=utf-8
>
> 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.
> The number community has not proposed to split the IANA Functions by different operators at the time of the transition.
>
> * Since the number community has 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.
>
> * The CRISP Team does 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.
>
> * The CRISP Team believes 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 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
>>>
>>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> ianaxfer mailing list
> ianaxfer at nro.net
> https://www.nro.net/mailman/listinfo/ianaxfer
>
>
> End of ianaxfer Digest, Vol 12, Issue 2
> ***************************************
>
>
>
>
>
>
> _______________________________________________
> ianaxfer mailing list
> ianaxfer at nro.net
> https://www.nro.net/mailman/listinfo/ianaxfer
>
More information about the CRISP
mailing list