[lac-discuss-es] RV: [NRO-IANAXFER] Numbering Services Draft SLA, still open for comment until 14 June

Lun Jun 8 04:23:12 UTC 2015

Estimados, reenvío este mail por considerarlo muy interesante por las críticas realizadas al trabajo realizado hasta este momento sobre la transición IANA, y nos compete.
Si bien es  largo, su lectura es importante.
Cuando haya respuesta, se las enviaré.
Saludos cordiales

Alberto Soto

-----Mensaje original-----
De: ianaxfer-bounces en nro.net [mailto:ianaxfer-bounces en nro.net] En nombre de David Conrad
Enviado el: lunes, 08 de junio de 2015 12:52 a.m.
Para: Axel Pawlik
CC: ianaxfer en nro.net
Asunto: Re: [NRO-IANAXFER] Numbering Services Draft SLA, still open for comment until 14 June

Hi,

I have been hesitant to provide comments on the draft SLA due to my current role within ICANN: for those that do not know, I am ICANN's CTO and am responsible for the technical implementation of the transition of the stewardship of the IANA Functions to the global multistakeholder community.  However, a number of people (not directly associated with ICANN) have asked me to provide my input WITHOUT my ICANN hat on, and instead as someone who helped set up APNIC, was an ARIN Board member for 5 years, had a very small role in helping to set up AfriNIC, who ran IANA from 2005 to 2010, and who has been doing registry stuff in one way or another for way longer than I care to admit.

Perhaps this can be a lesson in being careful what you ask for...

While I can assert the following input is, in fact, (a) purely my own, (b) is in no way representing ICANN's view, and (c) has not been coordinated with ICANN staff or board (I did mention I was planning on posting something in my own name), I am aware some will believe my input is subject to conflict of interest. My apologies in advance if you are among these people.

I will also apologize in advance if some of the comments below appear a bit harsh. This is not intended, however I believe due to time constraints, it is better to be clear and direct.

Finally, I apologize for the length of this message. I partially blame the length on the length of the SLA which is quite stunning given the what the IANA numbering function actually does and (as indicated by the blog by Alain Durand at https://www.icann.org/news/blog/iana-functions-usage-analysis) the extremely limited activity of that function. However, it's still a long message. Sorry for that.

So, with the above caveats:

At a high level, I will admit a very high degree of confusion about the draft SLA document as written. It doesn't seem like an SLA to me.

In my experience, when one is writing up service level agreements, the first step is to clearly identify the services to which an agreement is being defined. You then figure out acceptable levels of services, preferably by the folks who are actually involved in making use of the services in question, and once you have an idea of the services and the levels at which those services should be provided, you then clearly define the roles and responsibilities of both parties. Only after all of this is done do you bring in the lawyers (if necessary) to write stuff down into a binding agreement.  SLAs should minimize the technical and legal jargon, instead, focus on clarity and simplicity.

This does not appear to have been the path taken in drawing up the draft SLA. Instead, it appears the drafting team, aka "the RIR legal team (a group of staff counsels and advisors from the five RIRs)" took the IANA Functions contract, and hacked it up. I feel this is VERY odd since I believe the IANA Functions contract is primarily interested in ensuring DNS root zone management is done with minimal hiccups (with contractual language put in place to ensure past root zone management hiccups didn't reoccur) -- the IANA Functions contract's treatment of numbers management (like protocol parameter management) is largely mentioned only (IMHO) to ensure oversight of those functions are bound by NTIA to ICANN.

That is, I believe the drafting team took an existing but largely non-applicable _contract_, applied largely cosmetic changes, and then declared that a "Service Level Agreement". I believe this to be a mistake.

In addition, the "SLA" appears to be entirely one-sided, ignoring the reality that management of numbers is a cooperative effort done by the IANA numbering function operator, the RIRs, LIRs, and end users, for the benefit of the Internet community as a whole. As such, I believe a useful SLA must clearly define the _mutual_ roles and responsibilities of both parties, along with a very clear escalation path should a party not live up to their responsibilities. The current document does not do this.

Finally, much of the document, perhaps as a result of its origin, feels much more like a contract for services or MoU as opposed to a service _level_ agreement.  Perhaps the issue here is just my interpretation of what an SLA is and what "the RIR legal team" was actually after was a service contract. If that's so, I'd suggest not terming it a "service level agreement".

Specific comments:

Article 1:

As I am not a lawyer, I cannot usefully comment on the one and a half pages of definitions and interpretations. I also do not feel comfortable trying to figure out all the implications of those definitions and interpretations as they apply to SLAs, so I'm just going to ignore them and try to focus on the rest of the document as a definition of acceptable service levels.

Article 2:

2.1: "The Operator is required to perform the IANA Numbering Services in a stable and secure manner and in accordance with the RIR Global Policies."

What does "stable and secure" mean in this context? Also, as written, it can be read as this is defined in RIR global policies, which of course it isn't.

2.1: "The IANA Numbering Services are administrative and technical in nature. "

So what?  Don't see the point of this sentence in an SLA.

2.1: "The Operator is required to coordinate with operators of other IANA services."

Who are these "operators" and what do they do? I assume this is intended to deal with the case where the numbering function is split off from the other IANA functions, but it might be useful to explicitly state that, since another potential reading is that there are multiple providers of the numbering function.

Article 3:

Not being a lawyer, I don't understand the usage of "severally" in 3.1 and 3.2.  I'm also a bit surprised that a liability assumed by (say) ARIN, presumably including legal liabilities since it isn't constrained, would apply to (say) RIPE, but I suspect due to lack of legal training, I'm simply misunderstanding what is meant.

Article 4:

4.1: "The Operator shall be responsible for allocated and unallocated IPv4 and IPv6 address space and Autonomous System Number (ASN) space based on established guidelines and RIR Global Policies."

Unallocated IPv4 address space?

What are "established guidelines"? In a service level agreement, I believe it is very important to have concise and concrete terms, not vague handwaves.

4.1: "The Operator shall distribute IP address blocks to RIRs for routine distribution typically through downstream providers to Internet end-users within the regions served by those registries. The Operator shall also reserve and direct allocation of space for special purposes, such as multicast addressing, addresses for private networks as described in RFC 1918-Address Allocation for Private Internets, and globally specified applications."

No mention of distributing AS numbers.  Should probably say "… shall distribute Internet numbering resources …".

4.2.1.a: "The RIR will submit an initial request for Internet Number Resources to the Operator by electronic mail (e-mail)."

I don't think it is a good idea to permanently embed using email to handle requests. It pointlessly precludes the Operator from innovation and deploying more user friendly technologies.

4.2.1.b: "The Operator shall acknowledge receipt of the initial request within two (2) Business Days by return e-mail."

Again, forcing the use of email seems a bad idea in this day and age.

4.2.1.c.ii: "send a detailed announcement to the requesting RIR as well as a simultaneous announcement to the RIRs, informing them of the provisioning of resources"

Nit: probably should send the simultaneous announcement to "the other RIRs" to avoid the redundant announcement to the requesting RIR.

4.2.1.c.iii: "make modifications to the appropriate pages of the Operator’s website …"

This should probably say "make modifications to the appropriate IANA Number Registry or Registries"

4.2.1.c.iii: "which such announcements shall be limited to which IP address or AS number ranges have been issued, the time of issuance and the Registry to which they have been issued"

I don't see the reason for this limitation.  What is this trying to stop?

4.2.1.c.iv: "Upon its receipt of the allocation, the requesting RIR shall notify that administrator of the name servers to be inserted into the name server resource records of that domain."

And what happens if the RIR doesn't? This is an example of why I believe SLAs need to define mutual roles and responsibilities.

Article 5:

5.2: "Notwithstanding the foregoing, the maximum amount the RIRs shall reimburse the Operator pursuant to Article 5.1 above shall be One Hundred Dollars ($100.00) unless otherwise agreed to in writing by all Parties."

Um, what?  So the RIRs are only obligated to pay a maximum of $500 total? This makes no sense to me, particularly given 5.1. I guess this is some sort of legal incantation that makes sense to lawyers.

Article 6:

6.1: "Additionally, within a month of the adoption …"

Probably should state 30 days or 4 weeks or something else non-ambiguous.

6.1: "the Operator, as guided by the RIRs, shall document the procedures according to which this Global RIR Policy would be implemented and publish it on the Operator’s website."

I do not think the RIRs should have the unilateral ability to define the process by which the Operator updates its website.

6.2: "… shall be obliged to yearly issue reports illustrating its compliance with the obligations described in Articles 4 and 6.1"

Probably need a bit of detail in what they expect this report to contain, e.g., the Operator writing a report that simply says "we did stuff" is probably insufficient.

Article 7:

As a preamble, I think the amount of work defined in this section makes the maximum $100/RIR absolutely ludicrous.  It strikes me as incredibly odd that the work performing the actual function is vastly outweighed by the work necessary to monitor the function.

7.1.1: "The Operator shall implement a secure system for authenticated communications between it and its customers when carrying out all IANA Numbering Services requirements."

This is why I feel it is inappropriate to have based the Service Level Agreement for the IANA Numbering Function on the IANA function contract. That sentence makes sense for the Root Zone Management System and dealing with hundreds of TLD administrators that connect via HTTPS, it doesn't make sense here.  Above, the SLA has required requests to be submitted by email: there is NO "secure system for authenticated communications" for the numbering function currently. We authenticate above the communications system.

7.1.5: "The Operator shall notify and consult in advance the RIRs when there are personnel changes in this position."

Notification is fine, however it should be clear that this does not imply approval.

7.1.5: "The Director of Security shall be one of the key personnel assigned to this contract."

Cut-and-paste error: this isn't a contract.

7.2.2: "… starting no later than six (6) months after date of contract award."

Cut-and-paste error: this isn't a contract and it isn't awarded.

7.2.3: "No later than 30 days after conducting the survey, the Operator shall submit the CSS Report to the RIRs."

It should be made public, so this should probably say "… submit the CSS Report to the RIRs and publish appropriately on the Operator website" or some such.

7.2.5: "Prior to publication/posting of reports, the Operator shall obtain approval from the RIRs."

This violates ICANN's (and the RIRs) requirements to be open and transparent.  If this wasn't a copy/paste from the IANA Functions contract, I'd be extremely worried about this clause.

7.3.3: "Prior to publication/posting of reports, the Operator shall obtain approval from the RIRs."

Same comment as 7.2.5.

Article 8:

8.2: "The RIRs may perform a review whenever they deem appropriate."

This needs to be constrained.  I do not think it reasonable to allow the RIRs to 'perform a review' at (say) 2 AM on January 1.  There should be some sort of notice and reasonable accommodation made for schedules, workload, etc.

8.3: "The Operator must comply with the request by providing the requested information within working days."

The number of working days might be helpful.

8.4: "The RIRs may perform reviews in consultation with third parties."

And what happens when the RIRs demand the use of (say) the Russian Business Network, the Yakuza, or worse, the US Congress, as a third party?  Who the third party is must be constrained somehow. "Mutual agreement" should suffice.

Article 9:

I believe an escalation process would be appropriate here.

Article 10:

10.1: "the term of this Agreement shall continue for five (5) years after the Commencement Date."

I don't see the point in having a term given the agreement can be terminated at any time by any party.

10.2, 10.3: Separability.

I believe these SLAs need to be mutual — if the RIRs choose not to renew or terminate, they need to first document how the replacement Operator can assure at least the same level of accountability, openness, transparency, security, stability, resilience, etc., as the existing Operator.

Article 11:

11.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."

What happens if the RIRs choose to terminate 6 months after the date of the agreement?

11.1: "The Operator shall provide sufficient experienced personnel during the phase-in, phase-out period to ensure that the IANA Numbering Services are maintained at the required level of proficiency."

This seems pointless. In the event of a termination, what if the Operator doesn't? Are the RIRs going to doubly terminate them?

11.2: "Transition to Successor Operator"

Same question as above.

11.2.3: "The Operator also shall disclose necessary personnel records and allow the successor to conduct on-site interviews with these employees."

Wouldn't this violate the privacy of those employees and privacy protection laws?

Article 12:

12.1.1: "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 designees."

I don't think it makes sense to assign (say) intellectual property held by the Operator on behalf of (say) the naming community exclusively to the RIRs.

12.1.2: "Operator does hereby assign and transfer any and all right, title, and interest in and to such data rights to the RIRs, their successors, assigns and designees."

Similar comment as above.

12.3: "the Operator may be provided the use of intellectual property or rights over data through a license from the RIRs or the IETF Trust (the “IP Assets”)."

This is backwards. ICANN currently owns the rights to that intellectual property.

Articles 13-15:

Didn't read. Don't have the background to determine if those legal incantations are reasonable.

If you've read this far, I'm impressed at your intestinal fortitude...

Regards,
-drc
(SPEAKING ONLY FOR MYSELF)

---
El software de antivirus Avast ha analizado este correo electrónico en busca de virus.
https://www.avast.com/antivirus
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: no disponible
URL: <http://atlarge-lists.icann.org/pipermail/lac-discuss-es/attachments/20150608/aab79037/signature.asc>
------------ próxima parte ------------
An embedded and charset-unspecified text was scrubbed...
Name: Datos adjuntos sin título 00610.txt
URL: <http://atlarge-lists.icann.org/pipermail/lac-discuss-es/attachments/20150608/aab79037/Datosadjuntossinttulo00610.txt>