[CRISP-TEAM] [NRO-IANAXFER] ianaxfer Digest, Vol 12, Issue 2

Izumi Okutani izumi at nic.ad.jp
Tue Sep 8 14:36:36 CEST 2015


I have responded to the global ianaxfer list: https://www.nro.net/pipermail/ianaxfer/2015-September/000660.html

Izumi


On 2015/09/08 21:15, Janvier Noulaye wrote:
> That's great ! Izumi.
> 
> /Janvier
> 
> 2015-09-08 13:01 GMT+01:00 Izumi Okutani <izumi at nic.ad.jp>:
> 
>> Thanks Janvier. I have had a chance to chat with Shiva as he here in
>> Jakarta for APNIC40.
>>
>> I understanding his point better now after the dialogue. He is suggeesting
>> to give clarity that RIRs and the Review Committee will get the report on
>> the service level on the IANA Numbering Services directly from PTI, and not
>> via ICANN, to ensure neutrality and accountability of the report received.
>>
>> I made an observation that this would be implementation details, which
>> would be addressed by RIR legal team either by clarity on the SLA text or
>> Review Committee Charter.
>> The community process for feedback on this is over and I believe it would
>> be more appropriate to respond from RIRs.
>>
>> I will make this clarification on the ianaxfer list.
>>
>>
>> Izumi
>>
>>
>> On 2015/09/08 18:57, Janvier Noulaye wrote:
>>> Dear Izumi,
>>> Go ahead with the explanation on the global ianaxfer list.
>>> Warm regards,
>>> /Janvier
>>>
>>> 2015-09-07 19:25 GMT+01:00 Izumi Okutani <izumi at nic.ad.jp>:
>>>
>>>> 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
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> CRISP mailing list
>>>> CRISP at nro.net
>>>> https://www.nro.net/mailman/listinfo/crisp
>>>>
>>>
>>
>>
> 




More information about the CRISP mailing list