[CRISP-TEAM] Review of SLA ver.2

[Nurani Nimpuno]

Dear Izumi,

Thank you so much for doing the work on this. 

> On 27 aug 2015, at 17:45, Izumi Okutani <izumi at nic.ad.jp> wrote:
> 
> CRISP Team,
> 
> 
> 
> It is now beyond the time (UTC14:00 26th Aug) set at the last call to provide feedback on SLA ver.2 but please see my observations below.
> Apologies it is not the most easy to read format. I would like to share the contents of my feedback in the interest of time.
> 
> I also call for feedback from the CRISP Team members on SLA ver.2.
> We need to have your feedback today, to compile the CRISP Team comment tomorrow, which will then be submitted on Monday next week.
> 
> 
> 
> I have reviewed whether:
> 
> - CRISP Team comment for SLA ver.1 are adequately addressed
> - No consistencies with the number community proposal over additional edits for SLA ver.2
> 
> 
> The only part I would like to have more clarity is on the itellectual property rights.
> It wasn't clear to me whether the clauses in 12.1.1 and 12.2 will allow an organization independent from IFO to hold the IANA trade mark and iana.org domain, not a a license from RIRs/ICANN.

The text says "the Operator may be provided the use of intellectual property or rights over data through a license from the RIRs or the IETF Trust” so it clearly states the RIRs or the IETF trust. 

Perhaps, as the proposal only suggests the IETF trust as one alternative, the SLA text could be softened to speak about the IETF Trust or the neutral trust holding the IPRs (or something or rather).

> But may be because it is already late here - I'll take another look tomorrow.
> 
> In the meantime, if Craig or Michael could help me understand the arrangement explained better, it would be really helpful.

Indeed.
Nurani

> 
> 
> Thanks,
> Izumi
> 
> 
> 
> ------------------------------------------------------------------------------------
> 1. Comment about how the CRISP Team comments are addressed
> ------------------------------------------------------------------------------------
> -  2.1, 4.3.1(c)(iv), do not seem to address CRISP Team comment but no substantial concerns and does not cause inconsistencies with the number community proposal.
> -  11.1, while preferable to be addressed, the current description may be a pragmatic way forward.
> -  12.1.1 , 12.2 does not seem to address CRISP Team comment.
>     Needs double checking that it is not the RIRs which own the IANA trademark
>     Also helps to have clarify on ownership and not the license	
> 
> ----
> 2.1 Operational Role of the Operator
> No further clarification on the definition of "other IANA services" and "coordination"
> 
> "if any" is added, so it is not a requirement. While it does not create inconsistencies, and does not require changes in the agreement, would be good to understand the purpose of this clause.
> 
> 
> 4.3.1(c)(iv)
> Request to reduce details have not been addressed, as being considered necessary.
> Would not create inconsistencies, even it remains as it is.
> 
> Article 11: Continuity of operations9
> 11.1 Submission of a plan
> CRISP Team request to submit a plan in case of change in the IFO prior to transition is not addressed. The reason being the period is shortened from 18 months to 6 months and requiring the plan prior to the transition may delay the impementation timelines. Acknowledge that this is the pragmatic way forward.
> 
> 12.1 Assignment of intellectual property rights and rights over data
> 12.1.1 It reads as though trademark and will be delegate to RIRs, not an entity independent of IFO. Is this a correct reading?
> 12.2 Rights created in performance of Agreement is also not clear whether the owndership will be delegated to an organization independing of IFO, and not just the license.
> ----
> 
> ------------------------------------------------------------------------------------
> 2. Feeback based on track changes.
> ------------------------------------------------------------------------------------
> 
> https://www.nro.net/wp-content/uploads/Numbers-SLA-2.0-Redline.pdf
> 
> Observation below is based on substantial addition/edits.
> None of the changes are observed to cause inconsistencies with the number community proppsal.
> 
> ----
> Explanatory Notes
> Support having clarity about the next step in the SLA itself.
> Agree with the expectation described in the SLA for the SLA to be agreed by ICANN, given ICANN has provided feedback
> 
> Further, the CRISP Team expects the final SLA to remain consistent with the number community proposal, given consultation process has taken place, including feedback from the ICANN Board.
> Would like to request for clarity in the process beyond negotiation with ICANN.
> 
> 1.1 Definitions
> No additional description which will cause inconsistencies with the number community proposal.
> Helps to have clarity on Commencement date and Condition Precedent, as added.
> 
> 2.2 Priority of IANA Numbering Service
> While it acknowledges the need for ICANN to support the other IANA Functions it gives assurance that the services level of the IANA Numbering Services will not be affected.
> Therefore no inconsistencies with the number community proposal.
> 
> 4.1 Provision of IANA Numbering Services
> No concerns as it is a general statement.
> 
> 4.4 Registry Data
> No inconsistencies with the number community proposal.
> Helpful addition for performance review and backup of the data relevant to the IANA Numbering Services.(Addressing CRISP Team feedback)
> 
> 5.2 Maximum Reimbursement
> No inconsistencies with the number community proposal.
> The specific amount of the fees is not specified in the number community proposal, as the decision by RIRs and ICANN,
> 
> 6.2 Obligation to Issue Reports
> No consistency with the proposal and positive change for more up to date report, as frequency of the report in increased from every year to every 6 months
> 
> 7.2 Performance Reporting
> No inconsistencies with the number community proposal.
> Good to have public accessible report , clarify about date of performance report.
> 
> 8.4 Third parties
> If this refers to the Review Committee it ensures smooth condition for the Review Committee to conduct the review.
> No inconsistencies with the number community proposal. Rather, it supports its smooth implementation.
> 
> 10.1 Condition Precedent
> This addition does not create inconsistencies with the number community proposal. It helps to have clarify on when the agreement becomes effective.
> 
> 11.1 Submission of a plan
> 18 month --> 6 months to submit a plan for change in the IANA Numbering Services Operator: Gives better assurance of stability.
> 
> 13.2 Arbitration of Disputes
> No inconsistencies with the number community proposal.
> Defining details of abitration are implementation to be worked out between the RIRs and ICAN .
> 
> Article 14: Governing law and jurisdiction
> Clarifying the current jurisdiction of ICANN,  the State of California, United States of America.
> This is not an area covered in the number community proposal. It is expected to be worked out between the RIRs and ICANN for most effective enforceability.
> 
> 15.11 Sub-Contracting
> No inconsistencies with the number community proposal.
> Good to have this addition to address PTI. 
> ----
> 
> 
> 
> 
> _______________________________________________
> CRISP mailing list
> CRISP at nro.net
> https://www.nro.net/mailman/listinfo/crisp