[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
Izumi Okutani
izumi at nic.ad.jp
Thu Jun 4 01:24:15 CEST 2015
Thank you Janvier for your feedback. Helpful to know explicitly that you support it.
The announcement is sent out to the global ianaxfer list.
https://www.nro.net/pipermail/ianaxfer/2015-June/000574.html
Izumi
On 2015/06/03 4:59, Janvier Noulaye wrote:
> 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
>>
>>
>
More information about the CRISP
mailing list