[CRISP-TEAM] [Reminder: Comment on SLA close today 2nd June ] Re: Call for comments from the CRISP Team Re: first draft review of the SLA v1.0
Janvier Noulaye
jnoulaye at gmail.com
Tue Jun 2 21:59:50 CEST 2015
Hi Andrei, Izumi
I've read the last version of the Review. I have no additional comments.
Thanks for the work you did in short time.
Regards,
/Janvier Ngnoulaye
2015-06-02 17:19 GMT+01:00 Andrei Robachevsky <robachevsky at isoc.org>:
> Hi Izumi, all,
>
> I haven't seen comments and suggestions to the draft SLA that was sent
> to the list (file "Review of the SLA-201505262.doc|pdf"), so I am not
> sure what changes need to be done, including the clarification points
> that you mentioned below.
>
> For clarity sake, I include a clean version of the response. I made a
> few minor editorial changes:
> - removed all my own clarifying comments
> - changed "a compliance report to be produced every 90 days." to "a
> compliance report to be produced periodically"
> - deleted "escrow of these data to the RIRs" as being too prescriptive
> from "including regular backups of the registry data and escrow of these
> data to the RIRs, in case the Operator ceases to exist."
>
> Please let me know if anyone has concerns with these edits, or any other
> suggestions to the text.
>
> Regards,
>
> Andrei
>
>
> Izumi Okutani wrote on 02/06/15 12:35:
> > CRISP Team,
> >
> >
> > I would like to once again make the last call for comments to Andrei's
> review of the SLA.
> > Please express your comments by 2nd June UTC23:59.
> >
> >
> >
> > As for myself -
> >
> > I raised two points for clarification of interpretation of the SLA text,
> which I'll copy them here.
> > Would either Craig or Michael, as the RIR legal team be able to help on
> clarifying this?
> >
> >
> >> 1.1
> >> The Operator shall prepare a plan for this purpose and submit this plan
> to the RIRs (18) months after the date of this Agreement.
> >>
> >> Question:
> >> May I assume it is set after 18 months to give some time for the
> Operator for the preparation? If yes, do we not need to set a limit of
> period in preparation, in case it does not get completed unless specified?
> >>
> >> 12.1.1
> >> To the extent that the Operator possesses rights in and to any
> intellectual property, including but not limited to copyrights, trademarks
> and service marks,
> >> related to the performance of its obligations under this Agreement,
> Operator does hereby assign and transfer any and all right, title and
> interest in and to such intellectual property rights to the RIRs, their
> successors, assigns and designee.
> >>
> >> Question:
> >> Am I reading this right that the intellectual property rights transfer
> to RIRs, including trademarks and service marks?
> >
> >
> > Thanks,
> > Izumi
> >
> > On 2015/05/30 1:19, Izumi Okutani wrote:
> >> CRISP Team,
> >>
> >>
> >> I'd like to remind once again that we need to agree on the position as
> the CRISP team on Article 10, targetting 2nd June.
> >>
> >>
> >> Bill,
> >>
> >> I'd like to see if you have further comments, especially on "Points in
> support of the position that Article 10.1 is consistent with the numbers
> proposal" and/or if there is anything else to add from your perspective.
> >> If you do, it would be good for our discussions to share them here on
> the mailing list.
> >>
> >>
> >> Izumi
> >>
> >>
> >> On 2015/05/29 8:18, Izumi Okutani wrote:
> >>> CRISP Team,
> >>>
> >>>
> >>>
> >>> As a reference for our discussions on the mailing list, please see
> below the points shared and dicussed at the 20th CRISP Team call on 27th
> May regarding Section 10 (10.1 and 10.2) of the SLA.
> >>>
> >>> I attempted to add the point of views I observed but I may have
> unintentionally missed some points or not accurately captured some points.
> >>>
> >>> Please feel free to add/make changes as appropriate, and let's
> continue the discussions on this mailing list.
> >>>
> >>> At this stage, most CRISP Team members at the call supported the that
> Article 10.1 is consistent with the numbers proposal, but we still need to
> continue discussions on this mailing list to :
> >>>
> >>> - Confirm if there are further points to be made on the position that
> it is not consistent with the proposal
> >>> - Seek if there are points that the CRISP Team members from both
> position consider as agreeable
> >>>
> >>> We are going to share the review of the SLA by the CRISP Team on 3rd
> June to the global mailing list, so let's continue the discussions on the
> CRISP Team mailing list and seek for a position we can come up as the CRISP
> Team.
> >>>
> >>>
> >>> Izumi
> >>>
> >>>
> >>> ------
> >>> * Points in support of the position that Article 10.1 is not
> consistent with the numbers proposal (view expressed by Bill Woodcock)
> >>>
> >>> - The current description allows automatic renewal of the contract,
> unless either party provides makes 6 months advance notice not to renew.
> >>> - The current NTIA contract contains a term that ends on September
> 30, 2015 with no mention of automatic renewal. The US Government has
> historically rebids the IANA operator at every end of the contract term
> through standard US Government procurement procedure. Inclusion of an
> automatic renewal is a major change from this current situation, where the
> US Government of rebidding at the end of a every contract term.
> >>>
> >>> - This proposed provision It is not consistent with an effort to
> keep any changes to the current structure at a minimum. This is a major
> change from hat has been discussed with the numbers community nor the
> numbers proposal.
> >>> The numbers proposal has expressed clearly the need for minimum
> changes. This leads to major changes from the current way of contracting
> with the IANA operator.
> >>>
> >>> - This change would appears to serve the interests for the ICANN as
> it allows them to be the IANA operator as the default, but the question has
> been posed as to what interests of the Numbers community are served by this
> automatic renewal provision. It is not clear what interests serves for the
> numbers community.
> >>> - One advantage of bidding at every the end of the renewal each
> term gives RIRs an opportunity to know explore whether there is an
> alternate more preferable operator that can provide better service to
> provide its services. The cost of a rebidding process is not expected
> perceived to be a large amount big.
> >>>
> >>> - Calling for a rebidding when the SLA provides for defined
> automatic renewal, may be perceived as an would send a more explicit
> message that RIRs are not satisfied with the ICANN
> >>> - Despite having the mechanism to rebid without cause, it is
> perceived that the RIRs and Numbers community would never exercise this
> option
> >>>
> >>>
> >>>
> >>> * Points in support of the position that Article 10.1 is consistent
> with the numbers proposal
> >>>
> >>>
> >>> It would be a strong concern if as suggested, the SLA is serving the
> interests of the ICANN and not the numbers community, and/or inconsistent
> with the numbers proposal. However, it is not clear how the current SLA
> solely advantages ICANN or is inconsistent with the numbers proposal.
> >>>
> >>> The numbers proposal has described the need for;
> >>> - In case of failure in service, the RIRs can terminate the agreement
> >>> - The RIRs can periodically review the agreement and evaluate whether
> they want to renew the agreement
> >>>
> >>> Both of the points are covered in the by Section 10 of the draft SLA;
> the RIRs are able to terminate the agreement SLA in case of the a service
> level failure and additionally, the RIRs will be able to choose whether or
> not to renew the contract SLA with 6 months advance notice, even without
> cause.
> >>> Whether the contract is automatically renewed, or needs a rebidding is
> a matter of procedure on how we the RIRs/numbers community handle the
> contract at the end of the term.
> >>> The effect would be the same, Consistent with the CRISP proposal SLA
> principle on term and termination, the RIRs are still able to terminate in
> case of service level failure and as well as call for bidding without cause
> in the event they choose not to renew the SLA.
> >>>
> >>> It is not clear what issues it will cause, and if the RIRs will be
> perceived as sending a message that they are not satisfied with the ICANN
> by opening rebidding of the SLA. , or any other issues with automatic
> renewal, given we have the choice to rebid if needed.
> >>>
> >>> Further Additional points for consideration:
> >>> - The RIR legal team has drafted the SLA based on the Numbers
> community proposal with a focus on remaining consistent with the Numbers
> community proposal. No considerations were made to reflect ICANN's
> interests or desires.
> >>>
> >>> - Discussion on whether the contract should be automatically renewed
> had been discussed on the ianaxfer list.
> >>> It was agreed by the community to leave this decision to the RIRs
> on what would legally serve the interests of the RIRs and the community
> while remaining consistent and faithful to best legally, in line with the
> Numbers community proposal.
> >>>
> >>> - It is not true that providing for an automatic renewal and not
> requiring a rebid at the end of each term as US Government procedure
> requires, makes it inconsistent with the numbers proposal's desire for the
> minimum changes. The Numbers community proposal has expressed its the
> desire for the minimum "operational" changes, not minimal changes in the
> manner of contracting the contract to be exchanged with the NTIA today.
> >>> A.III.1. "Taking this into account, and considering the Internet
> Number Community's strong desire for stability and *a minimum of
> operational change*,.."
> >>>
> >>> - Having automatic renewal with a choice of not to renew without
> cause has benefits for the Numbers community as below;
> >>> 1) Gives stability of the services, while maintaining the ability
> to terminate and to not renew without cause based on the Numbers community
> proposal
> >>> 2) Pragmatic and reasonable from a business perspective way of
> handling renewal while achieving the effect needed
> >>> Rebidding has cost implications not just in terms of the fees
> paid but time needed for preparation and selection, consuming RIRs' human
> resources. The current draft provision allows RIRs to enter into a rebid
> process if desired, but does not require the expenditure of resources and
> funds to do so if deemed unnecessary. Given the order of magnitude of the
> service to be provided along with the minimal fees to be paid, it is
> unclear what benefit is sought to be realized by a mandatory rebid at the
> end of each term.
> >>> 3) It is still possible for RIRs to rebid after every each
> contract term if so desired. Rather than mandatory rebidding, it gives more
> flexibilities for the RIRs on desired choices.
> >>> 4) There is no material negative effect perceived by having this
> mechanism as opposed to requiring a mandatory rebid at the end of each term.
> >>>
> >>> ------
> >>>
> >>>
> >>> On 2015/05/28 0:55, Izumi Okutani wrote:
> >>>> CRISP Team,
> >>>>
> >>>>
> >>>> If you have any comments on the draft review of the SLAv1.0 shared by
> Andrei, please express on the CRISP Team ML by: Tue 2nd June UTC13:00
> >>>>
> >>>> Just for the record, we initially called for a volunteer from the RIR
> legal team who are also the CRISP Team members, to support provide legal
> clarity to review the SLA.
> >>>> We had no volunteer from the CRISP Team members who are in the RIR
> legal team. Nurani and I made the decision to leave it as it is, since this
> would be better from the accountability point of view.
> >>>>
> >>>> Below are the suggested next steps, with the core steps agreed at the
> 20th CRISP call, which took place a few hours ago.
> >>>>
> >>>> Tue 2nd June Close comments from the CRISP Team on the SLA1.0
> review
> >>>> Wed 3rd June Share the CRISP review on the ianaxfer list and see
> for comments
> >>>> Tue 9th June Close comments on the global list
> >>>> Thu 11th June Discuss handling of comments at the 21st CRISP call
> (in addition to ML discussions)
> >>>> Fri 12th June Finalize the CRISP comment by UTC13:00, submission
> by UTC15:00
> >>>> Sun 14th June Deadline of the submission (UTC23:59)
> >>>>
> >>>> Please also share if you have any comments on the steps described
> above before: UTC16:00, Thu 28th May.
> >>>>
> >>>>
> >>>> Regards,
> >>>> Izumi
> >>>>
> >>>> On 2015/05/27 3:27, Andrei Robachevsky wrote:
> >>>>> Colleagues,
> >>>>>
> >>>>> I attach a first draft of the analysis of the SLA for your review and
> >>>>> comments. I tried to include some of the comments from the community,
> >>>>>
> >>>>> although I wasn't able to fit them all in. Partly, because I felt
> some
> >>>>> of them were outside the scope of this analysis limited to checking
> the
> >>>>> conformance of the SLA provisions with each of the CRISP SLA
> Principles.
> >>>>>
> >>>>> Regards,
> >>>>>
> >>>>> Andrei
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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
> >>>
> >>
> >
> >
> > _______________________________________________
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.nro.net/pipermail/crisp/attachments/20150602/8754d326/attachment.html>
More information about the CRISP
mailing list