[CRISP-TEAM] [NRO-IANAXFER] ianaxfer Digest, Vol 12, Issue 2
Janvier Noulaye
jnoulaye at gmail.com
Tue Sep 8 14:15:48 CEST 2015
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
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.nro.net/pipermail/crisp/attachments/20150908/08107433/attachment-0001.html>
More information about the CRISP
mailing list