[lac-discuss-en] Draft Numbering Services SLA, still open for comment Until 14 June

[asoto at ibero-americano.org]

[[--Translated text (es -> en)--]]

 Subject: Re: Draft Numbering Services SLA, still open for comment Until 14 June 
 From: asoto at ibero-americano.org

 Dear, I forward this mail as too interesting for the criticisms of the work done so far on transition IANA, and concerns us. 
 While it's long, reading is important. 
 When you have answer, I will send them. 
 Best regards 


 Alberto Soto 


 ----- Original Message ----- 
 From: ianaxfer-bounces at nro.net [mailto: ianaxfer-bounces at nro.net] On behalf of David Conrad 
 Posted on: Monday, June 8, 2015 12:52 am 
 To: Axel Pawlik 
 CC: ianaxfer at nro.net 
 Subject: Re: [NRO-IANAXFER] Draft Numbering Services 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 overall multistakeholder community. However, a number of people (not Directly Associated With ICANN) Have Asked to Provide me my input WITHOUT ICANN my hat on, and as someone WHO Instead Helped set-up APNIC, was an ARIN Board member for 5 years, had a very small role in helping to set-up AfriNIC, WHO IANA ran from 2005 to 2010, and WHO has-been doing stuff registry in one way or another for way longer than I care to admit. 


 Perhaps esta 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) you have 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.


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


 Finally, I apologize for the length of esta message. I partially blame the length on the length of the SLA Which is quite stunning what the IANA Given the whos function does and numbering (as Indicated by the blog by Alain Durand at  https://www.icann.org/news/blog/iana-functions-usage-analysis) 


 So, With the above caveats: 


 At a high level, I will admit to very high degree of confusion about the draft document as written SLA. It does not 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 an agreement Which is Being defined. You then figure out acceptable levels of services, preferably by the folks whos Who are Involved in making use of the services in question, and Once You Have An Idea of \u200b\u200bthe services and the services Those levels at Which Should be provided, you then Clearly defined 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. Should SLAs 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 contract is IANA Functions Primarily interested in Ensuring DNS root zone management is Done with minimal hiccups (with contractual language put in place to root zone management Ensure past hiccups did not reoccur) - the IANA Functions Contract management's treatment of numbers (like management protocol parameter) is Largely Mentioned only (IMHO) to Ensure oversight of Those functions are bound by NTIA to ICANN. 


 That is, I believe the drafting team Largely Took an existing but non-applicable _contract_, applied cosmetic Largely Changes, and then a Declared That a "Service Level Agreement". Esta I believe 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 operator numbering IANA function, the RIRs, LIRs, and end users, for the benefit of the Internet community as a whole. As such, I believe to useful SLA must _mutual_ Clearly define the 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 agreement _level_. Perhaps the issue here is just my interpretation of what an SLA is and what "the RIR legal team" whos was 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 can not 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" In This context mean? Also, as written, it can be read as this is defined in RIR overall policies, Which of course it is not. 


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


 So what? Do not see the point of esta sentence in an SLA. 


 2.1: "The Operator is required to coordinate IANA With operators of other 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 state Explicitly That, since reading is another potential That there are multiple providers of the numbering function. 


 Article 3: 


 Not being a lawyer, I do not understand the usage of "severally" in 3.1 and 3.2. Also I'm a bit surprised That a liability Assumed by (say) ARIN, presumably Including legal liabilities since it is not 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." 


 IPv4 unallocated 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 downstream through Internet providers to 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 specified applications globally. " 


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


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


 I do not think it is a good idea to permanently embed to using email to handle requests. It precludes the Operator pointlessly 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 to 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: Should probably send the simultaneous announcement to "the other RIRs" to avoid the redundant announcement to the Requesting RIR. 


 4.2.1.c.iii: "Appropriate make Modifications to the pages of the Operator's website ..." 


 This should probably say "make Modifications to the Appropriate Registry Number IANA or Registries" 


 4.2.1.c.iii: "Such announcements Which 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 do not see the reason for esta limitation. What is this trying to stop? 


 4.2.1.c.iv "ITS Upon receipt of the allocation, the RIR Requesting That Shall notify administrator of the name servers to be inserted into the name server resource records of That domain." 


 And what happens if the RIR does not? 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 altogether? 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 RIR Global Policy esta Which 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 STI website. 


 6.2: "... Shall Be Obliged to issue yearly reports illustrating ITS compliance With the Obligations Described in Articles 4 and 6.1"


 Probably need a bit of detail in What They expect to Contain este informe, eg, the Operator simply writing a report That 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 system for secure 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 Function Numbering function on the IANA contract. That sentence Makes Sense for the Root Zone Management System and Dealing with Hundreds of TLD That Administrators connect via HTTPS, it does not make sense here. Above, the SLA has required requests to be Submitted By email: There is no "system for secure authenticated communications" for the Currently numbering function. We authenticate above the communications system.


 7.1.5: "The Operator Shall notify and consult in advance the RIRs When there are million other Changes in personnel." 


 Notification is fine, however it Should be clear esta That 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 is not a contract. 


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


 Cut-and-paste error: this is not a contract and it is not Awarded. 


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


 Should it be made public, so This should probably say "... CSS submit the Report to the RIRs and publish Appropriately Operator on the 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 was not 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 a.m. 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 information Requested 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 is the third party must be constrained somehow. "Mutual agreement" should suffice. 


 Article 9:


 I believe would be an escalation process Appropriate here. 


 Article 10: 


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


 I do not 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 first need to 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 plan for th purpose esta plan and submit to the RIRs (18) months after the date of esta Agreement." 


 What happens if the RIRs choose to terminate six 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 does not? Are the RIRs going to doubly terminate them? 


 11.2: "Transition to Successor Operator" 


 Same question as above. 


 11.2.3: "The Operator Shall disclose Also Necessary personnel records and allow the successor to conduct on-site interviews With These employees." 


 Would not 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 do not 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: "May be the Operator provided the use of intellectual property rights over data or through a license from the RIRs or the IETF Trust (the" IP Assets ")." 


 This is backwards. Currently ICANN That owns the rights to intellectual property. 


 Articles 13-15: 


 Did not read. Do not have the background to determine if legal incantations Those are reasonable. 


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


 Regards, 
 -drc 
 (SPEAKING ONLY FOR MYSELF) 










 --- 
 Avast antivirus software scanned this email for viruses. 
 https://www.avast.com/antivirus 



[[--Original text (es)
http://mm.icann.org/transbot_archive/99e41ce1b2.html
--]]