June 2015 - lac-discuss-es

Sugerencias para el Showcase
by Alberto Soto June 9, 2015

June 9, 2015

Estimados, en la reunión de hoy se determinaron varias cosas. Para quienes no pudieron estar en la misma, me gustaría hacer el siguiente resumen: 1. Para quienes participen presencialmente: no olviden los vestidos tradicionales de cada país. Por ejemplo, yo vestiré de gaucho de las pampas y Carlos Aguirre de un típico hombre de tango. 2. La última fecha de envío de videos de cada ALS es el 12 de junio a las 23:00UTC. Aún no recibí ninguno La compilación no tendrá costos, obtuve sponsor gratuito. 3. Aún no está determinado si podremos pasar música sin pagar derechos de autor. Esperamos respuesta de Sergio Salinas Porto. Pero por las dudas, sugiero que me envíen a mi correo varias canciones de vuestro país. En realidad, debería ser música tradicional, la que ya no está protegida por los derechos de autor. En el caso de Argentina por ejemplo, está el denominado Pericón Nacional. Por favor, en formato MP3. Esto también hasta el 12 de junio a las 23:00 UTC 4. Entregaremos un obsequio al actual CEO de ICANN por ser la última reunión de ICANN de la cual participe en nuestra Región. Para ello necesitamos que envíen a mi correo (no a la lista), varias canciones que consideren típicas de vuestros respectivos países. Será armado un álbum de música de Latinoamérica y Caribe, y entregada en un pendrive, junto a algo más. Por favor, en formato MP3. Esto no será reproducido con fines de lucro, por lo cual no tendremos en cuenta los derechos de autor. Con este motivo, hubo sugerencias de entregar al actual CEO de ICANN un presente de cada país que esté en Buenos Aires, pequeño, solo indicatorio de la respectiva nacionalidad. Esto último es absolutamente voluntario. 5. Como obtuvimos dos sponsors adicionales (LACNIC y Google Inc.), estaremos en condiciones de mejorar un poco el catering y entregar otros regalos. Todo lo que se entregue en la recepción o como regalo, serán artesanías de los indígenas WICHIS, habitantes de Argentina, Bolivia y Brasil. Se entregará junto con el souvenir, un resumen sobre los Wichis y sobre la madera con la cual están construidos, esto en Inglés y Español. Les ruego encarecidamente el envío de los videos y la música solicitadas. Se han realizado esfuerzos muy grandes para que todas nuestras organizaciones estén representadas, y sería muy malo que por que no recibamos la colaboración de las mismas, no estén representadas. Es un derecho de cada ALS estar representada, pero también una obligación. Saludos cordiales Alberto Soto --- El software de antivirus Avast ha analizado este correo electrónico en busca de virus. https://www.avast.com/antivirus

1 0

Traducciones al español y portugués
by León Felipe Sánchez Ambía June 9, 2015

June 9, 2015

Queridos amigos, En seguimiento a mi correo en el que anunciaba la extensión del plazo para la recepción de comentarios en idiomas diferentes al inglés, adjunto las versiones en español, portugués y francés de la propuesta inicial para la mejora de la rendición de cuentas de ICANN preparada por el CCWG. La fecha límite para la recepción de comentarios es el día 12 de junio. Como lo han mencionado algunos compañeros, hay puntos sobre los que vale mucho la pena comentar. Dejo algunos puntos que espero detonen la discusión y puedan conducir a la elaboración de un documento con la posición de LACRALO. 1.- Modelo de membresía para ICANN 2.- Panel de revisión independiente (IRP) 3.- Poderes de la comunidad En espera de que esta información sea útil para la elaboración de comentarios, quedo pendiente de cualquier duda o comentario que puedan tener sobre el tema. Saludos, León

1 0

Re: [lac-discuss-es] Reunión Showcase- hoy a las 23 UTC
by Silvia Vivanco June 8, 2015

June 8, 2015

Estimado Alberto, Corrección, en 42 minutos a las 23 UTC. Muchas gracias! Silvia From: lac-discuss-es-bounces(a)atlarge-lists.icann.org [mailto:lac-discuss-es-bounces@atlarge-lists.icann.org] On Behalf Of Alberto Soto Sent: Monday, June 08, 2015 5:18 PM To: 'LACRALO Español' Subject: [lac-discuss-es] Reunión Showcase Importance: High Estimados, a las 2300 UTC, (en 4 minutos) comenzaremos la última reunión antes de nuestro Showcase en Buenos Aires, es pido por favor si tienen tiempo disponible, que participen. Muchas gracias y cordiales saludos Alberto Soto For other times: http://tinyurl.com/ovnrakn The draft agenda (to be updated) and call details are available at: https://community.icann.org/x/xpU0Aw Adobe Connect: http://icann.adobeconnect.com/lacralo Conference ID: EN 1638 ES 1738 Wiki workspace: https://community.icann.org/x/xgonAw ________________________________ [Avast logo]<https://www.avast.com/antivirus> El software de antivirus Avast ha analizado este correo electrónico en busca de virus. www.avast.com<https://www.avast.com/antivirus>

1 0

Reunión Showcase
by Alberto Soto June 8, 2015

June 8, 2015

Estimados, a las 2300 UTC, (en 4 minutos) comenzaremos la última reunión antes de nuestro Showcase en Buenos Aires, es pido por favor si tienen tiempo disponible, que participen. Muchas gracias y cordiales saludos Alberto Soto For other times: <http://tinyurl.com/ovnrakn> http://tinyurl.com/ovnrakn The draft agenda (to be updated) and call details are available at: <https://community.icann.org/x/xpU0Aw> https://community.icann.org/x/xpU0Aw Adobe Connect: <http://icann.adobeconnect.com/lacralo> http://icann.adobeconnect.com/lacralo Conference ID: EN 1638 ES 1738 Wiki workspace: <https://community.icann.org/x/xgonAw> https://community.icann.org/x/xgonAw --- El software de antivirus Avast ha analizado este correo electrónico en busca de virus. https://www.avast.com/antivirus

1 0

RV: [NRO-IANAXFER] Numbering Services Draft SLA, still open for comment until 14 June
by Alberto Soto June 8, 2015

June 8, 2015

Estimados, aquí la respuesta de John Curran, CEO de ARIN, a David Conrard. Saludos cordiales Alberto Soto -----Mensaje original----- De: ianaxfer-bounces(a)nro.net [mailto:ianaxfer-bounces@nro.net] En nombre de John Curran Enviado el: lunes, 08 de junio de 2015 08:04 a.m. Para: David Conrad CC: ianaxfer(a)nro.net 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(a)virtualized.org> 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(a)nro.net 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

4 4

Fwd: Pensamientos solicitadas sobre Criterios CEO de ICANN
by carlton.samuels＠gmail.com June 8, 2015

June 8, 2015

[[--Translated text (en -> es)--]] Asunto: Fwd: Pensamientos solicitadas sobre Criterios CEO de ICANN Desde: carlton.samuels(a)gmail.com Parece que nos íbamos para la mujer / hombre super! Pero el atributos / habilidades que destacaron llegar tapas de importancia, en mi humilde opinión. Y hasta podemos hacer otra triage para encontrar los muy, muy importantes. -Carlton ============================== Carlton Un Samuels Móvil: 876-818-1799 * Estrategia, Planeación, Gobierno, Evaluación y plazos de entrega * ============================= ---------- Mensaje reenviado ---------- Desde: Rinalia Abdul Rahim <rinalia.abdulrahim(a)gmail.com> Fecha: dom, 07 de junio 2015 a 21:29 Subject: [ALAC] Pensamientos solicitadas sobre Criterios CEO de ICANN Para: Lista de Trabajo ALAC <alac(a)atlarge-lists.icann.org> Estimados Presidentes ALAC y RALO, Estoy muy ansiosa por verle y otra comunidad de alcance miembros de nuevo en la próxima reunión de la ICANN en Buenos Aires. * Alerta Tema Importante * La Junta está interesada en su opinión para ayudar a refinar la selección criterios para el próximo CEO de ICANN. - El domingo 21 de junio, habrá un ALAC / At-Large sesión conmigo, que se centrará en el CEO de Búsqueda y Criterios. - El jueves 25 de junio, habrá una sesión de Consejo en el CEO Proceso de Sucesión justo antes del Foro Público donde su entrada sería inestimable. * Preguntas clave: * ¿Qué características y habilidades te gustaría ver en el futuro de ICANN CEO? Como ninguna persona va a cumplir con todos los criterios deseados, que son criterios lo más importante? ¿Qué distribución de las características y habilidades te gustaría ver? Solicito que los miembros de la ALAC y el poco de tiempo At-Large repuesto pensar y discutir este tema tan importante. Si Presidentes RALO podía facilitar los debates a nivel regional que conduce a Buenos Aires, que sería muy útil para alimentar los debates en Buenos Aires. Como referencia y detonante de sus pensamientos y discusión, a continuación es el CEO de Perfil de los 2011 CEO de búsqueda de materiales. Espero sus comentarios. Atentamente, Rinalia * CEO Perfil [CEO de búsqueda en 2011 *] Se espera que los candidatos para demostrar al más alto grado posible la siguiente experiencia y habilidades. Estos se han agrupado en 4 partidas que encarnan la naturaleza multifacética de la función: * Profesional * § sólido historial de either / or, servicio público, empresarial académica, en un alto nivel internacional § Exposición global: experiencia de trabajo en diferentes países o con culturas diferentes Experiencia en el manejo § flujos de trabajo de procesos y capacidad de anticipar los problemas § Cerrar la familiaridad con las formas en que la sociedad civil, el sector empresarial los intereses y las autoridades reguladoras interactúan § El éxito en la gestión de la evolución de la ICANN como organización, cuestiones complejas y programas y contratos clave § historial de lograr resultados, no sólo "estar allí" § asociación previa con las organizaciones altamente respetadas § Liderazgo de equipos internacionales dispersos y múltiples partes interesadas activas que proporcionan una condición política * Personal * § Consenso constructor y catalizador, un motivador y persuasor § Intelectualmente atractivo, contribuye al "liderazgo pensado 'en ayudar definir la visión y la estrategia, y aprovecha las competencias de la organización § Combina peso de la personalidad con empatía hacia los demás de muchos diferentes orígenes § Practicado en ejercer una influencia en las relaciones no jerárquicas § gana respeto y genera confianza en él / ella y la organización § Multicultural con conocimientos de idiomas, practicado comunicador y pública altavoz § Alinea con los valores de la ICANN: la integridad, la confianza, la humildad, la técnica la excelencia y el servicio público § negociador capaz, sin hacer enemigos, puede representar la ICANN y puede presentarlo así § afinidad fuerte con Internet (pero no sólo una "cheerleader"), consciente de su papel y la complejidad, abraza plenamente la misión de ICANN y su proceso de abajo hacia arriba § encarna y practica el enfoque de múltiples partes interesadas y se felicita participación voluntaria significativa * Técnica * § conocimiento arquitectura de Internet: la comprensión de la de Internet global sistemas de identificadores únicos, incluidos los nombres de dominio, los parámetros del protocolo y direcciones § conocimiento institucional: la familiaridad con el funcionamiento de los registros y los registradores, los procedimientos de desarrollo de políticas de ICANN y categorías de usuarios § Comprensión de la estructura del mercado de nombres de dominio y la dinámica, incluidas las cuestiones de competencia * El Ecosistema de la Gobernanza de Internet * § Instituciones: comprender el entorno de los implicados en el Sus sistemas de gobierno administrativos, en particular IETF, ISOC, Internet y W3C, y otros organismos de normalización (ETSI, ITU, ISO, Unicode) § La conciencia internacional: conocer los grupos de interés del gobierno en internet la gobernanza y la forma de interactuar con ellos § Conocimiento del sistema de las Naciones Unidas y otras organizaciones internacionales y procesos § Capacidad para funcionar y generar confianza con todos los actores a través de excelencia operativa y el respeto a la entrada de la base de múltiples partes interesadas FIN _______________________________________________ [[--Original text (en) http://mm.icann.org/transbot_archive/a2afa47b54.html --]]

1 0

RV: [NRO-IANAXFER] Numbering Services Draft SLA, still open for comment until 14 June
by Alberto Soto June 8, 2015

June 8, 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(a)nro.net [mailto:ianaxfer-bounces@nro.net] En nombre de David Conrad Enviado el: lunes, 08 de junio de 2015 12:52 a.m. Para: Axel Pawlik CC: ianaxfer(a)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

1 0

Re: [lac-discuss-es] Bienvenidos a-At Large!
by dacostabastidas＠dtech.ec June 7, 2015

June 7, 2015

[[--Translated text (en -> es)--]] Asunto: Re: Bienvenidos a-At Large! Desde: dacostabastidas(a)dtech.ec Bienvenidos!, ESPERAMOS Aportes y gestión activa en favor de de los ususarios del Internet de Nicaragua y de la región. Atte Diego Acosta Bastidas 06.03.2015 16:30 GMT-05: 00 <hcarrascob(a)gmail.com> : > > [[--Translated text (en -> es)--]] > > Asunto: Re: Bienvenidos a-At Large! > Desde: hcarrascob(a)gmail.com > > Bienvenidos a Lacralo !!! > > > > > Saludos > > > Enviado desde mi iPhone > > > > El 03-06-2015, a las 20:31, "staff(a)atlarge.icann.org" < > staff(a)atlarge.icann.org> escribiÃ³: > > > > Dear Mario and Carlos, > > > > ICANN's At-Large Advisory Committee (ALAC) is pleased to inform you that > > (224) IEEE Nicaragua has been certified as an At-Large Structure (ALS). > The > > ALAC greatly appreciates your group's interest in involving individual > users > > in ICANN and looks forward to working with you and your colleagues. > > > > The purpose of ALS certification is to recognize that your organization > > meets the necessary criteria to involve individual Internet users at the > > local or issue level in ICANN activities, and that your organization will > > support its individual members' informed participation in ICANN efforts > that > > affect end-users. > > > > The ALAC is eager to promote a productive working relationship between > your > > organization, other ALS, and the ALAC (and ICANN in general), and your > input > > on how we can make this a success would be greatly appreciated. > > > > We would like to offer some initial tools to help your organization keep > its > > members informed (about significant news from ICANN and information on > ICANN > > policy-development efforts) and engaged in activities of interest: > > > > > > - Point of Contact for your Organisation: Please send an email to > > mailto:staff@atlarge.icann.org identifying the names and email > addresses of > > one or two individuals who will be the point of contact for information > and > > correspondence regarding ICANN At-Large. If this changes, please let us > > know. > > > > > > - At Large Mailing Lists. There are many At Large email lists, for each > > region; you can sign up for them and manage your subscriptions at: > > http://atlarge-lists.icann.org/mailman/listinfo . The points of contact > you > > identify will automatically be added to your region's list just for > > accredited ALSes to discuss regional issues and to the mailing list for > > Staff announcements (only Staff can post messages to that list); you are > > invited to join others as you wish. > > > > - ALS information. Information about your organization will be shared > with > > the At-Large community to enable individuals interested in your group's > > activities to contact you, and to encourage cooperation with other groups > > interested in ICANN activities in your geographic region. Please complete > > and email the form at the bottom of this note to staff(a)atlarge.icann.org > . > > > > - ALAC website. The ALAC website (http://www.atlarge.icann.org > > <http://www.atlarge.icann.org/> ) is a good source for ICANN news and > > information of interest to individual Internet users. We encourage you > to > > provide your members with a link. The ALAC relies on volunteers to > > translate information into multiple languages. Translations of documents > on > > the website are welcome and should be sent to > > <mailto:staff@atlarge.icann.org> > > > > - At-Large Regional Websites. Regional wiki webpages also have been > created > > to distribute information (including in local languages) on activities, > > events and issues of particular interest to people in each region. These > are > > maintained by the community. They are: > > > > African Region: http://www.afralo.org > > > > Asia/Australia/Pacific Region: http://www.apralo.org > > <http://www.apralo.org/> > > > > European Region: http://www.euralo.org <http://www.euralo.org/> > > > > Latin America/Caribbean Region: http://www.lacralo.org > > <http://www.lacralo.org/> > > > > North American Region: http://www.naralo.org <http://www.naralo.org/> > > > > > > We have included an Starter Kit that includes key information on ALAC and > > At-Large communication tools. We have also included the ALS Beginners > Guide > > which explains how best to engage within At-Large. > > > > We look forward to working with you and your organization's members to > > advance individual Internet users' interests within ICANN. If you have > any > > questions, or need additional information, please contact us at > > staff(a)atlarge.icann.org. > > > > Sincerely, > > > > The At-Large Advisory Committee > > > > http://www.atlarge.icann.org <http://www.atlarge.icann.org/> > > staff(a)atlarge.icann.org > > > > --------------------------- > > > > > > Name: > > > > > > Location (city/country/region; whatever is relevant to your membership): > > > > > > Mission: > > > > > > Member benefits: > > > > > > Contacts (name/s and email address/es -- title/s optional): > > > > > > Website: > > > > > > Other (additional informational you would like included): > > > > > > > > > > > > > > <Starter Kit for ALS Representatives - EN.pdf> > > <Starter Kit for ALS Representatives - ES.pdf> > > <alses-beginners-guide-02jun14-en(1).pdf> > > <alses-beginners-guide-02jun14-es.pdf> > > _______________________________________________ > > ALAC-Internal mailing list > > ALAC-Internal(a)atlarge-lists.icann.org > > https://atlarge-lists.icann.org/mailman/listinfo/alac-internal > > > > ALAC Wiki: > https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(AL… > > > > At-Large Website: http://atlarge.icann.org > lac-discuss-en lista de correo > lac-discuss-en(a)atlarge-lists.icann.org > https://atlarge-lists.icann.org/mailman/listinfo/lac-discuss-en > > > [[--Original text (en) http://mm.icann.org/transbot_archive/74df4fce6a.html --]]

5 4

Opinión sobre futuro CEO de ICANN
by Alberto Soto June 7, 2015

June 7, 2015

Estimados, la Junta de ICANN está interesada en la opinión sobre cuáles son las características que a nuestra comunidad le gustaría ver en el futuro CEO de ICANN. También habrá una sesión pública con el Consejo sobre el tema de CEO , el jueves 25 de junio justo antes de que el foro público. Sería muy conveniente opinar sobre este tema, y fundamentar tal opinión. Creo que es una buena oportunidad de participar y que nuestra voz sea considerada. Estas opiniones deben ser enviadas antes del 20 de junio a las 2300 UTC por la reunión que tendremos los RALOs Chair con la Junta. Muchas gracias y saludos cordiales Alberto Soto --- El software de antivirus Avast ha analizado este correo electrónico en busca de virus. https://www.avast.com/antivirus

2 2

Fw: Ra�z de Estabilidad Estudio RFP
by carlton.samuels＠gmail.com June 6, 2015

June 6, 2015

[[--Translated text (en -> es)--]] Asunto: Fw: Raíz de Estabilidad Estudio RFP Desde: carlton.samuels(a)gmail.com Cualquier persona? -Carlton ============================== Carlton Un Samuels Móvil: 876-818-1799 * Estrategia, Planeación, Gobierno, Evaluación y plazos de entrega * ============================= [Imagen: la ICANN] <http://www.icann.org/> Alerta de Noticias https://www.icann.org/news/announcement-2-2015-06-05-en ------------------------------ Raíz de Estabilidad Estudio RFP 05 de junio 2015 La Corporación de Internet para Nombres y Números Asignados ("ICANN") es la búsqueda de uno o más proveedores para llevar a cabo un estudio técnico de examinar la impacto del Programa de nuevos gTLD (el Programa) en el sistema de la raíz DNS. En consonancia con su misión de apoyo a la seguridad y la estabilidad de la Sistema de identificadores únicos de Internet, ICANN llevará a cabo una el examen del impacto del programa en el sistema de raíz DNS. El seleccionado proveedor (s) será diseñar y ejecutar uno o más estudios que incorporan el recopilación y análisis de datos de los operadores de servidores raíz, histórico datos de rendimiento, los datos recogidos en los estudios anteriores, y otras herramientas y medidas. ICANN está buscando uno o más proveedores calificados para manejar este ejercicio complejo en forma oportuna y eficiente. Una revisión del Programa de impacto en la seguridad y la estabilidad es un anterior compromiso basado en el asesoramiento de Comité Asesor Gubernamental de ICANN < https://archive.icann.org/en/topics/new-gtlds/board-notes-gac-scorecard-cle…> y otras discusiones. Concretamente, la ICANN ha comprometido a revisar los efectos del Programa de nuevos gTLD en las operaciones del sistema de la raíz DNS, y para posponer las delegaciones en una futura ronda hasta que se determine que el delegaciones en la ronda de 2012 no han puesto en peligro el sistema de raíces la seguridad o la estabilidad. Los objetivos de este estudio incluyen, como mínimo: - Ejecución de una revisión a fondo del impacto del Programa en la la seguridad y la estabilidad del DNS. - Identificar qué medidas, en su caso, debe llevarse a cabo como un requisito previo para añadir más dominios de primer nivel a la zona de las raíces. - Identificar qué medidas, en su caso, debe ser llevado a cabo por la comunidad en el futuro para evaluar el estado de la zona de las raíces en forma permanente. Para obtener información adicional, línea de tiempo completo, y las instrucciones para la presentación de las respuestas por favor haga clic < https://www.icann.org/en/system/files/files/root-stability-study-rfp-05jun1…>. [ZIP, 983 KB] Las propuestas deben enviarse a RootStabilityStudy-RFP(a)icann.org las 23:59 UTC del 2 de julio de 2015. [[--Original text (en) http://mm.icann.org/transbot_archive/1f1956163b.html --]]

1 0