[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.



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