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

To: "'LACRALO EspaÃol'" <lac-discuss-es@xxxxxxxxxxxxxxxxxxxxxxx>
Subject: [lac-discuss-es] RV: [NRO-IANAXFER] Numbering Services Draft SLA, still open for comment until 14 June
From: "Alberto Soto" <asoto@xxxxxxxxxxxxxxxxxxx>
Date: Mon, 8 Jun 2015 11:16:34 -0300
Estimados, aquÃ la respuesta de John Curran, CEO de ARIN, a David Conrard.
Saludos cordiales

Alberto Soto

-----Mensaje original-----
De: ianaxfer-bounces@xxxxxxx [mailto:ianaxfer-bounces@xxxxxxx] En nombre de 
John Curran
Enviado el: lunes, 08 de junio de 2015 08:04 a.m.
Para: David Conrad
CC: ianaxfer@xxxxxxx
Asunto: Re: [NRO-IANAXFER] Numbering Services Draft SLA, still open for comment 
until 14 June

On Jun 7, 2015, at 11:51 PM, David Conrad <drc@xxxxxxxxxxxxxxx> wrote:
> 
> 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.

David - 
 
   Thanks for these comments - I have no doubt that they will lead to an
   improved SLA as a result.   

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

   Along that spirit, I am going to refrain from responding to the vast majority
   of the comments (as the community is likely to have ample comments), but
   but will comment on three areas which relate to the overall assumptions for 
   the IANA Stewardship transition process at a high-level.

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

   Agreed.

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

   I believe that the roles and responsibilities of the parties must be 
defined, but that
   doesnât necessarily have to be (or even should be) in a single document.   
The rather
   colorful structure and evolution of ICANN has resulted in it having multiple 
roles, and
   yet these roles are not strictly dependent on each other.   For example, if 
the ICANN
   IANA team were to experience extremely and chronic performance issues in the 
   administration of the IANA number registries (the opposite of the excellent 
performance
   provided to date), then there could be a circumstances where the numbers 
community
   would need (via the RIRs as their representative) to contract for an 
alternative IANA 
   numbers registry operator.   The SLA should be suitable for that arrangement 
(even 
   though ICANN would not longer be performing the IANA numbers registry 
function.)

   However, in my personal opinion, such a change should not in any way change 
the 
   RIRs collectively operating under ICANNâs overall Internet identifier 
coordination role;
   i.e. the community should still submit global policies to ICANN for 
ratification,  the ASO
   MOU should remain in effect, the RIR community should participate in 
accountability
   and transparency reviews (ATRT) as part of the ICANN system, etc.   ICANN 
serves
   as an important role external to the Internet numbers community that 
improves overall
   accountability and transparency, and helps in broad outreach to the global 
Internet 
   community.

   So, I think weâre in agreement that role and responsibilities should be 
clearly defined,
   but it is not clear that it should be done in a single document since there 
are multiple
   relationships: 1) RIRs/NRO serving as the global Address Supporting 
Organization 
   within ICANN, with its incumbent obligations, and 2) ICANN serving as the 
IANA 
   numbers service operator for numbering community as represented by the RIRs.

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

   Actually, I believe it is $100 _in total_ under the present languageâ Is 
there a value
   that makes more sense - i.e. what do you believe the full costs of providing 
âthe 
   extremely limited activityâ of the IANA numbering function?  I personally 
believe that
   it is in the community's interest for this value be an accurate estimate of 
such costs,
   and the present ICANN ASO contribution should be reduced by the same amount 
   once established.   In this manner, if the worst-cast were to happen and 
another
   party had to perform IANA services, then the RIRs would have budgeted at 
least a
   meaningful amount for this purpose, and while ICANN would lose this amount, 
it 
   would correspond with a similar reduction in the level of effort in their 
IANA team.

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

   It would be nice if we could all come to agreement that the rights to the 
community's
   intellectual property related to these activities (including any data 
rights, trademark,
   domain names, etc.) should be held by an entity which was actually set up 
for such 
   a purpose, had no operational role, would make appropriate licenses 
available to all
   parties that had a role in IANA operations, etc.   Last I checked, the IETF 
Trust met
   all of these criteria (whereas neither ICANN nor the RIRs do)  One can 
imagine 
   some rather extreme worse-case scenarios involving transitions where it 
would be
   very helpful it we could all rely on the intellectual property being made 
available to
   whomever needed it to perform the functions, and not otherwise caught in 
transition.

Thanks again for the comments!
/John

Disclaimer:  The remarks above are my own as CEO of ARIN.  While I believe them 
to 
                    be fully compatible with the organization's positions on 
these matters to 
                    date, neither the ARIN Board nor ARIN community has 
discussed Davidâs
                    comments and developed specific positions on these topics 
at this time.



_______________________________________________
ianaxfer mailing list
ianaxfer@xxxxxxx
https://www.nro.net/mailman/listinfo/ianaxfer


---
El software de antivirus Avast ha analizado este correo electrÃnico en busca de 
virus.
https://www.avast.com/antivirus

_______________________________________________
lac-discuss-es mailing list
lac-discuss-es@xxxxxxxxxxxxxxxxxxxxxxx
https://atlarge-lists.icann.org/mailman/listinfo/lac-discuss-es

http://www.lacralo.org