Skip to main content
Resources

Actas | Reunión Ordinaria de la Junta Directiva de la ICANN

Esta página está disponible en:

Este documento ha sido traducido a varios idiomas como información únicamente. El texto original y válido (en inglés) se puede obtener en: https://www.icann.org/resources/board-material/minutes-2015-09-28-en

El 28 de septiembre de 2015, a las 16:45 hora local, se realizó una reunión ordinaria de la Junta Directiva de la Corporación para la Asignación de Nombres y Números en Internet (ICANN) en Marina del Rey, California.

Steve Crocker, Presidente de la Junta Directiva, declaró abierta la sesión con puntualidad.

En forma adicional al Presidente de la Junta, los siguientes Directores participaron como parte de la reunión: Rinalia Abdul Rahim, Cherine Chalaby, Fadi Chehadé (Presidente y Director Ejecutivo), Chris Disspain, Asha Hemrajani, Wolfgang Kleinwächter, Markus Kummer, Bruno Lanvin, Gonzalo Navarro, Ray Plzak, George Sadowsky, Mike Silber, Bruce Tonkin (Vicepresidente) y Kuo-Wei Wu.

Los siguientes Directores se disculparon por su ausencia: Erika Mann

Los siguientes Coordinadores de enlace con la Junta Directiva participaron en toda o parte de la reunión: Ram Mohan, Coordinador de enlace del Comité Asesor de Seguridad y Estabilidad (SSAC), Jonne Soininen, Coordinador de enlace del Grupo de Trabajo en Ingeniería de Internet (IETF), y Suzanne Woolf, Coordinadora de enlace del Comité Asesor del Sistema de Servidores Raíz (RSSAC).

Secretario: John Jeffrey (Asesor Letrado General y Secretario).

Los siguientes ejecutivos e integrantes del personal de la ICANN participaron en forma total o parcial de la reunión: Akram Atallah (Presidente de la División Global de Dominios); Susana Bennett (Directora de Operaciones); Megan Bishop (Coordinadora de Apoyo a la Junta Directiva); Michelle Bright (Gerente de Contenidos de Apoyo a la Junta Directiva); Xavier Calvez (Director de Finanzas); David Conrad (Director de Tecnologías); Samantha Eisner (Asesora Letrada General Asociada); Allen Grogan (Director General de Cumplimiento Contractual); Dan Halloran (Asesor Letrado General Adjunto); Jamie Hedlund (Vicepresidente de Programas Estratégicos, División Global de Dominios); Tarek Kamel (Asesor Sénior del Presidente sobre Participación Gubernamental); Vinciane Koenigsfeld (Gerenta de Contenido de Apoyo para la Junta Directiva); Elizabeth Le (Asesora Sénior); Margie Milam (Directora Sénior de Iniciativas Estratégicas); David Olive (Vicepresidente de Apoyo para el Desarrollo de Políticas); Erika Randall (Asesora Sénior); Amy Stathos (Asesora Letrada General Adjunta); Theresa Swinehart (Asesora Sénior del Presidente sobre Estrategia); Shawn White (Asesora Letrada General Asociada) y Christine Willett (Vicepresidenta de Operaciones de gTLD).

  1. Orden del Día Convenido:
    1. Aprobación de las Actas de las Reuniones de la Junta Directiva
    2. Recomendaciones del Consejo de la GNSO sobre la traducción y transliteración de la información de contacto
    3. Renovación del Acuerdo de Registro del dominio .CAT
    4. Renovación del Acuerdo de Registro del dominio .TRAVEL
    5. Renovación del Acuerdo de Registro del dominio .PRO
  2. Orden del Día Principal:
    1. Contratación de la sede para la reunión de la ICANN de junio de 2016
    2. Contratación y desembolso para la nueva Iniciativa de ERP
    3. Liberación de Fondos de Reserva - Costos de la Transición de la Custodia de la IANA por parte del Gobierno de los Estados Unidos
    4. Programa de Nuevos gTLD: El camino hacia futuras rondas
    5. Requisitos de seguro para el Acuerdo de Acreditación de Registradores
    6. Recomendaciones de política e implementación de la GNSO
    7. Designación del Presidente y Presidente Electo del Comité de Nominaciones para 2016 - SESIÓN EJECUTIVA

 

  1. Orden del Día Convenido:

    El Presidente de la Junta presentó los elementos del orden del día convenido y llamó a votación. A continuación, la Junta Directiva tomó la siguiente medida:

    Resuélvase: se aprueban las siguientes resoluciones del orden del día convenido.

    1. Aprobación de las actas de la Junta Directiva

      Resuélvase (2015.09.28.01): la Junta Directiva de la Corporación para la Asignación de Nombres y Números en Internet (ICANN) aprueba las actas de sus reuniones de los días 16 y 28 de julio de 2015.

    2. Recomendaciones del Consejo de la GNSO sobre la Traducción y Transliteración de la Información de Contacto

      Visto y considerando que, 13 de junio de 2013, el Consejo de la GNSO (Organización de Apoyo para Nombres Genéricos) lanzó un Proceso de Desarrollo de Políticas (PDP) sobre Traducción y Transliteración, abordando dos preguntas estatutarias establecidas en: http://gnso.icann.org/en/issues/gtlds/transliteration-contact-charter-20nov13-en.pdf.

      Visto y considerando que el PDP siguió los pasos establecidos para dicho proceso, de acuerdo con lo estipulado en los Estatutos, y generó el Informe Final que fue presentado el 12 de junio de 2015.

      Visto y considerando que el Grupo de Trabajo (WG) sobre la Traducción y Transliteración de la Información de Contacto logró un consenso sobre su primera recomendación y un consenso total sobre sus seis recomendaciones restantes.1

      Visto y considerando que, el Consejo de la GNSO examinó y debatió las recomendaciones del Grupo de Trabajo sobre la Traducción y Transliteración de la Información de Contacto y adoptó las Recomendaciones el día 24 de junio de 2015 mediante votación unánime (véase: http://gnso.icann.org/en/council/resolutions#20150624-3).

      Visto y considerando que, la votación del Consejo de la GNSO alcanzó y superó el umbral de votación requerido (es decir, la supermayoría) para imponer nuevas obligaciones a las partes contratadas de la ICANN; y

      Visto y considerando que, luego de la votación del Consejo de la GNSO hubo un período para la recepción de comentarios públicos sobre las recomendaciones aprobadas, y que los comentarios han sido resumidos y considerados (https://www.icann.org/public-comments/transliteration-contact-recommendations-2015-06-29-en).

      Resuélvase (2015.09.28.02): la Junta Directiva adopta las Recomendaciones de Política del Consejo de la GNSO relativas a la traducción y transliteración de la información de contacto, tal como se presenta en el Informe Final.

      Resuélvase (2015.09.28.03): la Junta Directiva instruye al Director Ejecutivo, o quien éste designe, a desarrollar y completar un plan de implementación para estas recomendaciones y continuar la comunicación y cooperación con el Equipo para la Revisión de la Implementación de la GNSO y la comunidad en relación al trabajo de implementación.

      Fundamentos de las Resoluciones 2015.09.28.02 – 2015.09.28.03

      ¿Por qué la Junta Directiva aborda el tema ahora?

      La internacionalización continuada de los sistemas de nombres de dominio significa que una parte cada vez mayor de usuarios de Internet no utilizan (o ni siquiera están familiarizados con) el código US ASCII (Código Estadounidense Estándar para el Intercambio de Información), el término técnico utilizado para el script (código de escritura) latino utilizado en inglés y en otros idiomas de Europa occidental.

      La exactitud y la coherencia de los datos de la información de contacto resultan cruciales para que los mismos constituyan una fuente útil para aquellos que buscan información relativa a los registratarios de nombres de dominio. Este Grupo de Trabajo del PDP ha considerado la importante cuestión de si los datos traducidos y/o transliterados o los datos presentados en el script (código de escritura) más conocido para el registratario implican una mayor probabilidad de cumplimiento de estos requisitos, teniendo también en cuenta la cantidad de solicitudes de este tipo de datos y los costos asociados con la traducción o transliteración general.

      El Informe Final del PDP sobre Traducción y Transliteración recibió un apoyo consensuado sobre su primera recomendación y un consenso total sobre las otras seis recomendaciones restantes. También recibió el apoyo unánime del Consejo de la GNSO.

      Con posterioridad al cierre del período de comentarios públicos, la siguiente etapa, según lo establecido en el Anexo A de los Estatutos de la ICANN, es someter las recomendaciones a consideración de la Junta Directiva de la ICANN.

      ¿Cuál es la propuesta que se está considerando?

      Se han adoptado las siguientes recomendaciones:

      Recomendación n.° 1 - El Grupo de Trabajo recomienda que no es deseable hacer que la transformación de la información de contacto sea obligatoria. Cualquiera de las partes que solicite la transformación es libre de hacerlo de manera ad hoc fuera del WHOIS o de cualquier sistema de reemplazo, tal como el Protocolo de Acceso a los Datos de Registración de Nombres de Dominio (RDAP). Si no es realizada de manera voluntaria por el registrador/registro (véase Recomendación n.° 5), la carga de la transformación recae en la parte solicitante.

      Recomendación n.° 2 Si bien se destaca que un sistema de reemplazo de WHOIS debe ser capaz de recibir aportes en el formulario de información de contacto que no sea un script (código de escritura) ASCII, el Grupo de Trabajo recomienda que sus campos de datos se almacenen y muestren de manera que permitan la identificación sencilla de lo que representan las diversas entradas de datos y qué idiomas/scripts (códigos de escritura) han sido utilizados por el titular de nombre registrado.

      Recomendación n.° 3 - El Grupo de Trabajo recomienda que los idiomas y los scripts (códigos de escritura) admitidos para que los registratarios presenten sus datos de información de contacto puedan elegirse de conformidad con los modelos comerciales de proveedores de gTLD.

      Recomendación n.° 4 - El Grupo de Trabajo recomienda que, independientemente de los idiomas/scripts (códigos de escritura) utilizados, se garantice que los campos de datos cumplan con las normas del Acuerdo de Acreditación de Registradores (RAA), la política de consenso relevante, la Política de Información Adicional de WHOIS (AWIP) y toda otra política aplicable. La información de contacto ingresada ha de ser validada de conformidad con las políticas y acuerdos anteriormente mencionados y el idioma/script (código de escritura) utilizado debe poderse identificar fácilmente.

      Recomendación n.° 5 - El Grupo de Trabajo recomienda que si se realiza la transformación de la información de contacto y, si el sistema de reemplazo del WHOIS es capaz de mostrar más de un conjunto de datos por entrada de titular de nombre registrado, estos datos deben presentarse como campos adicionales (además de los campos de script (código de escritura) locales autoritativos proporcionados por el registratario) y que estos campos se marquen como transformados y se indique su origen.

      Recomendación n.° 6 El Grupo de Trabajo recomienda que cualquier sistema de reemplazo de WHOIS, por ejemplo, el Protocolo de Acceso a los Datos de Registración de Nombres de Dominio (RDAP), permanezca flexible de manera que la información de contacto en nuevos scripts (códigos de escritura)/idiomas pueda agregarse y expandir su capacidad lingüística/de script (código de escritura) para recibir, almacenar y mostrar datos de información de contacto.

      Recomendación n.° 7 - El Grupo de Trabajo recomienda que estas recomendaciones se coordinen con otras modificaciones de WHOIS donde sea necesario y se implementen o apliquen tan pronto como se ponga en funcionamiento un sistema de reemplazo del WHOIS que pueda recibir, almacenar y mostrar caracteres que no son ASCII.

      Conclusión en relación con la segunda pregunta de la carta orgánica: en virtud de las recomendaciones n.° 1 y n.° 7, la pregunta de quién debe decidir sobre quién debería afrontar la carga de traducir o transliterar la información de contacto a un único script (código de escritura) común es discutible.

      La Recomendación n.° 1 fue acompañada por una Declaración de las Minorías, que establece lo siguiente: El miembro del Grupo de Trabajo Petter Rindforth, en consonancia con la posición adoptada por su unidad constitutiva, la Unidad Constitutiva de Propiedad Intelectual (ICP),2 recomienda la traducción y/o transliteración (transformación) obligatoria de la información de contacto en todos los dominios genéricos de alto nivel (gTLD).

      Si bien está de acuerdo en que hay situaciones en las cuales la información de contacto en el idioma local del registratario es la versión principal, tal como identificar al registratario en la preparación para una acción judicial local, existen diversas situaciones en las cuales es necesario realizar una búsqueda global de WHOIS, proporcionando acceso a los datos de la manera más uniforme posible, para que el servicio de registración de datos alcance sus objetivos de proporcionar transparencia y responsabilidad en el DNS (Sistema de Nombres de Dominio). Véase también el punto 5.1.1 [del Informe Final] que explica los argumentos del Grupo de Trabajo en apoyo a la transformación obligatoria de la información de contacto en todos los dominios genéricos de alto nivel.

      ¿Cuáles son las partes interesadas u otros participantes consultados?

      Durante el curso de la vida de este PDP se realizaron consultas periódicas con las partes interesadas, específicamente durante tres reuniones de la ICANN (ICANN 49, ICANN50 e ICANN51), así como períodos de comentarios públicos para el Informe preliminar de Cuestiones, el Informe Inicial y antes de la consideración de la Junta Directiva.

      ¿Qué inquietudes o cuestiones fueron planteadas por la comunidad?

      La principal inquietud planteada por la Comunidad fue que una base de datos en múltiples scripts (códigos de escritura)/idiomas conducirá a una menor transparencia debido a que los códigos de escritura no latinos podrían ser menos comprensibles para la mayoría de los usuarios de Internet. También reduciría la capacidad de búsqueda de datos. También se temía que registratarios fraudulentos pudiesen ocultar su identidad detrás de diferentes scripts (códigos de escritura)/idiomas.

      ¿Qué materiales significativos analizó la Junta Directiva?

      La Junta Directiva examinó el Informe Final, el Informe de Recomendaciones para la Junta Directiva del Consejo de la GNSO, así como el resumen de los comentarios públicos recibidos y la respuesta del Personal a esos comentarios.

      ¿Qué factores consideró importantes la Junta Directiva?

      Las recomendaciones fueron formuladas según el proceso de desarrollo de políticas de la GNSO, de conformidad con lo estipulado en el Anexo A de los Estatutos de la ICANN y han recibido el apoyo unánime del Consejo de la GNSO. De conformidad con los Estatutos de la ICANN, el apoyo de la supermayoría del Consejo para aprobar la moción (el Consejo votó a favor de manera unánime) obliga a la Junta Directiva a adoptar esta recomendación, a menos que con más del 66% de los votos, la Junta Directiva establezca que la política no beneficia a la comunidad de la ICANN o a la ICANN propiamente dicha. Además, el continuar con la internacionalización del sistema de nombres de dominio constituye un área importante de trabajo para la ICANN. Las recomendaciones tienen el potencial de mejorar la facilidad de uso y la exactitud de los datos de la información de contacto a través de un DNS verdaderamente globalizado.

      ¿Existen impactos positivos o negativos para la comunidad?

      Algunos de los impactos positivos identificados en el Informe Final incluyen (pero no se limitan a):

      • Los registratarios que no están familiarizados con el código US-ASCII podrán registrar nombres de dominio utilizando el script (código de escritura) con el cual estén más familiarizados;
      • Los registradores no están obligados a traducir o transliterar los datos, aunque deben validar los datos independientemente del script (código de escritura) que respalden: la decisión sobre cuáles son esos datos estará regulada por la oferta y la demanda;
      • Los costos de registración no aumentarán debido al requisito de que los registradores traduzcan o transliteren todos los datos de la información de contacto a un script (código de escritura)3 e inevitablemente conllevará a que los costos puedan ser transmitidos a los registratarios;
      • El permitir que, al momento de registrar sus dominios, los registratarios utilicen el idioma/script (código de escritura) con el cual están más familiarizados, tendrá un impacto positivo sobre la exactitud de los datos.

      Algunos de los impactos negativos identificados en el Informe Final son que:

      • Aquellos que intenten buscar los datos de la información de contacto y lo hagan utilizando el código US-ASCII, podrían tener que traducir o transliterar los datos para poder ponerse en contacto con los registratarios (aunque eso es cierto para aquellos que buscan información, pero no están familiarizados con el código US-ASCII, incluso si la traducción o transliteración eran obligatorios).

      ¿Se observan impactos fiscales o ramificaciones en la ICANN (plan estratégico, plan operativo, presupuesto), la comunidad y/o el público?

      No existe impacto fiscal sobre la ICANN. Los miembros de la comunidad y el público en general podrían tener que pagar por la traducción o transliteración profesional de información de contacto. Sin embargo, estos costos contrastan marcadamente con los potenciales costos en que se incurriría ante un requisito general para que cada contacto que tenga un script (código de escritura) diferente al código US-ASCII tuviese que ser traducido o transliterado.

      ¿Se observan cuestiones sobre seguridad, estabilidad o flexibilidad relacionadas con el DNS?

      El actual protocolo de WHOIS no está diseñado para scripts (códigos de escritura) distintos al código US-ASCII. Sin embargo, el Protocolo de Acceso a los Datos de Registración de Nombres de Dominio (RDAP) está siendo actualmente desplegado como el reemplazo de WHOIS y [el RDAP] es totalmente compatible con diferentes scripts (códigos de escritura). Una vez que el RDAP esté implementado ―o cualquier otro reemplazo que sea capaz de tratar con scripts (códigos de escritura) distintos al código US-ASCII― no habrá problemas de seguridad, estabilidad o flexibilidad relacionados con el DNS, si la Junta Directiva aprueba las recomendaciones propuestas.

    3. Renovación del Acuerdo de Registro del dominio .CAT

      Visto y considerando que, desde el 28 de mayo al 7 de julio de 2015 la ICANN comenzó un período de comentarios públicos <https://www.icann.org/public-comments/cat-renewal-2015-05-28-en> sobre la propuesta de renovación al Acuerdo de Registro del dominio de alto nivel .CAT <https://www.icann.org/resources/unthemed-pages/cat-2012-02-25-en>.

      Visto y considerando que, la propuesta de renovación al Acuerdo de Registro del dominio .CAT incluye disposiciones modificadas para conciliar el Acuerdo de Registro del dominio .CAT con el Acuerdo de Registro de Nuevos gTLD.

      Visto y considerando que, el foro de comentarios públicos sobre la propuesta de renovación al Acuerdo de Registro de dominio .CAT cerró el día 7 de julio de 2015, y que la ICANN recibió quince (15) comentarios, tanto por parte de individuos como de organizaciones/grupos. Se proporcionó a la Junta Directiva un resumen y análisis de los comentarios.

      Visto y considerando que, la renovación del acuerdo de registro fue actualizada para incluir las disposiciones vigentes en materia de WHOIS.

      Resuélvase (2015.09.28.04): se aprueba la propuesta de renovación al Acuerdo de Registro .CAT y se autoriza al Presidente y Director Ejecutivo, o quien éste designe, a tomar las medidas apropiadas para finalizar e implementar dicho acuerdo.

      Fundamentos de la Resolución 2015.09.28.04

      ¿Por qué la Junta Directiva aborda el tema ahora?

      La ICANN y la Fundació puntCAT (el "Operador de Registro") firmaron un Acuerdo de Registro el 23 de septiembre de 2005 para el funcionamiento del dominio de alto nivel .CAT. El actual Acuerdo de Registro del dominio .CAT expira el 19 de diciembre de 2015. La propuesta de renovación al Acuerdo de Registro (la "Renovación del Acuerdo de Registro" o el "Acuerdo") fue publicado para la recepción de comentarios públicos entre el 28 de mayo y el 7 de julio de 2015. En este momento, la Junta Directiva está aprobando la Renovación del Acuerdo de Registro para la continuidad de gestión del dominio de alto nivel .CAT por parte del Operador de Registro.

      ¿Cuál es la propuesta que se está considerando?

      La Renovación del Acuerdo de Registro aprobada por la Junta Directiva incluye disposiciones modificadas para conciliar el Acuerdo con el Acuerdo de Registro de Nuevos gTLD. Las modificaciones incluyen: la actualización de las especificaciones técnicas; que requieren la inclusión de ciertas medidas de protección del GAC (Comité Asesor Gubernamental) como compromisos de interés público (las cuales son exigibles mediante el Procedimiento para la Resolución de Disputas en Materia de Compromisos de Interés Público); que requieren el uso de registradores regidos por el Acuerdo de Acreditación de Registradores de 2013 tras alcanzar un determinado umbral; y la actualización de las tarifas de registro.

      Con el fin de dar cuenta de la naturaleza específica del dominio de alto nivel .CAT, un TLD Patrocinado, se han incluido disposiciones relevantes del Acuerdo de Registro de TLD Patrocinados del 23 de septiembre de 2005 en la Renovación del Acuerdo de Registro. Específicamente, en la Especificación 12 se identifican disposiciones de la carta orgánica que describen la lingüística y comunidad cultural del catalán en Internet de conformidad con la comunidad y elegibilidad para la registración. La Renovación del Acuerdo de Registro también refleja las aprobaciones anteriores relativas a los nombres reservados.

      ¿Cuáles son las partes interesadas u otros participantes consultados?

      Desde el 28 de mayo al 7 de julio de 2015, la ICANN llevó a cabo un período de comentarios públicos sobre la propuesta de renovación al Acuerdo de Registro del dominio .CAT, finalizado dicho período, se resumieron y analizaron los comentarios recibidos. En forma adicional, la ICANN entabló negociaciones bilaterales con el Operador de Registro para acordar el paquete de términos a incluirse en la Renovación del Acuerdo de Registro, publicado para la recepción de comentarios públicos.

      ¿Qué inquietudes o cuestiones fueron planteadas por la comunidad?

      Quince (15) miembros de la comunidad participaron en el período de comentarios públicos. En sus comentarios, los miembros de la comunidad plantearon tres cuestiones fundamentales:

      • La transición de los TLD preexistentes a la forma del Acuerdo de Registro de Nuevos gTLD: Algunos comentarios públicos expresaron su preocupación por el proceso de la ICANN para utilizar el acuerdo de registro de nuevos gTLD como el punto de partida para la renovación de los acuerdos de registro de los gTLD preexistentes. Estos comentadores sugieren que la adopción de una posición de este tipo tiene el efecto de transformar los Procedimientos de Resolución de Disputas de los Nuevos gTLD posteriores a la delegación (por ejemplo, el Procedimiento de Resolución de Disputas por Marcas Comerciales Posterior a la Delegación y el Procedimiento de Resolución de Disputas por Compromisos de Interés Público) y del Sistema Uniforme de Suspensión Rápida (URS) en Políticas de Consenso de facto sin seguir los procedimientos establecidos en los Estatutos de la ICANN para su creación. Por otro lado, otros comentarios apoyaron que la ICANN busque coherencia entre los acuerdos de registro y señalaron que la transición a la nueva forma de acuerdo es parte de las negociaciones bilaterales permisibles.
      • La inclusión del Sistema Uniforme de Suspensión Rápida (URS) y del Procedimiento para la Resolución de Disputas con Posterioridad a la Delegación (PDDRP) en las renovaciones de los acuerdos de los TLD preexistentes, sin pasar a través de un Proceso de Desarrollo de Políticas (PDP): la mayoría de los comentarios recibidos expresaron su objeción a la inclusión del URS a la propuesta de renovación al Acuerdo de Registro .CAT, alegando que el URS puede convertirse en una política de consenso sólo después de que un proceso de desarrollo de políticas (PDP) completo tome lugar con la participación de toda la comunidad de las partes interesadas de la ICANN. Estos comentadores también sugirieron que la imposición del URS a un gTLD preexistente a través del proceso de contratación es una intervención inaceptable del personal en el proceso de formulación de políticas. Por otro lado, algunos comentarios expresaron su apoyo a la inclusión del URS en la Renovación del Acuerdo de Registro, afirmando que los registros tienen libertad para ir más allá de las protecciones mínimas de los derechos y que ello no requiere de un PDP.

      ¿Qué materiales significativos analizó la Junta Directiva?

      Como parte de sus deliberaciones, la Junta Directiva analizó diversos materiales, incluidos, entre otros, los siguientes materiales y documentos:

      ¿Qué factores la Junta Directiva consideró significativos?

      La Junta Directiva examinó cuidadosamente los comentarios públicos recibidos sobre la Renovación del Acuerdo de Registro, junto con el resumen y análisis de esos comentarios. La Junta Directiva también consideró los términos acordados por el Operador de Registro como parte de las negociaciones bilaterales con la ICANN. Si bien la Junta Directiva reconoce las preocupaciones expresadas por algunos miembros de la comunidad con respecto a la inclusión del URS en la Renovación del Acuerdo de Registro, la Junta señala que dicha inclusión del URS se basa en las negociaciones bilaterales entre la ICANN y el Operador de Registro, durante las cuales el Operador de Registro expresó su interés para renovar su acuerdo de registro en base al Acuerdo de Registro de Nuevos gTLD.

      La Junta Directiva señala que el URS fue recomendado por parte del Equipo para la Revisión de la Implementación (IRT) como un mecanismo de protección de los derechos obligatorio (RPM) para todos los nuevos gTLD. Se solicitó a la GNSO ofrecer su visión consensuada respecto de si ciertos mecanismos de protección de derechos propuestos (los cuales incluyen al URS) eran coherentes con la política propuesta por la GNSO para la introducción de los nuevos gTLD, y si eran una opción adecuada y eficaz para lograr los principios y objetivos establecidos por la GNSO. El equipo de Cuestiones Específicas de Marcas Comerciales (STI) consideró este asunto y concluyó que: "El uso del URS debe constituir un RPM requerido a todos los nuevos gTLD." Es decir, la GNSO indicó que el URS no era incompatible con ninguna de sus recomendaciones de política existentes.

      Si bien el URS fue desarrollado y perfeccionado a través del proceso aquí descripto, el cual incluyó la revisión pública y discusión en la GNSO, el mismo no ha sido adoptado como una política de consenso y la ICANN no tiene capacidad de exigirlo como obligatorio a ningún TLD que no sea un nuevo solicitante de gTLD presentado durante la ronda de nuevos gTLD de 2012.

      Por consiguiente, la aprobación de la Renovación del Acuerdo de Registro por parte de la Junta Directiva no constituye un movimiento hacia exigir la obligatoriedad del URS a ningún TLD preexistente, y el hacerlo no sería apropiado. En el caso de .CAT, la inclusión del URS se desarrolló como parte de la propuesta surgida en las negociaciones bilaterales entre el Operador de Registro y la ICANN.

      Además, la Junta Directiva consideró los comentarios relativos a la transición de los gTLD preexistentes a la nueva forma del acuerdo de registro. La Junta Directiva señala que acuerdo de registro existente exige la renovación de presunción del acuerdo a su vencimiento, siempre y cuando se cumplan ciertos requisitos. La renovación del acuerdo está sujeta a la negociación de los términos de renovación razonablemente aceptables para la ICANN y para el Operador de Registro. Los términos de la renovación aprobada por la Junta Directiva son el resultado de negociaciones bilaterales previstas en el acuerdo de registro actual y la transición a la nueva forma del acuerdo de registro no violaría la política de la GNSO establecida. Tal como se describe a continuación, la nueva forma del acuerdo de registro ofrece algunas ventajas operativas ―además de los beneficios a los registratarios y la comunidad de Internet, que incluyen los compromisos de interés público―, que requieren el uso de registradores regidos por el RAA del 2013 y la capacidad de la ICANN para designar a un operador de registro provisional de emergencia, en caso de alcanzarse los umbrales de emergencia para los servicios críticos del registro.

      ¿Existen impactos positivos o negativos para la comunidad?

      Como parte del proceso de renovación, la ICANN examinó el desempeño reciente del Operador de Registro, según el Acuerdo de Registro del dominio .CAT actualmente vigente. Se encontró que, fundamentalmente, el Operador de Registro ha cumplido con sus requisitos contractuales.

      La aprobación de la Renovación del Acuerdo de Registro por parte de la Junta Directiva también ofrece beneficios técnicos y operacionales positivos. De conformidad con la Renovación del Acuerdo de Registro, en caso de alcanzarse alguno de los umbrales de emergencia para las funciones de registro, el Operador de Registro está de acuerdo en que la ICANN puede designar a un operador de registro provisional de emergencia para el registro del TLD, lo cual mitigaría los riesgos de la estabilidad y la seguridad del Sistema de Nombres de Dominio. Además, la incorporación técnica del Operador de Registro para cumplir con lo dispuesto en el acuerdo de los nuevos gTLD permitirá que el Registro utilice procesos uniformes y automatizados, lo cual facilitará el funcionamiento del TLD. En la Especificación 11, la Renovación del Acuerdo de Registro también incluye medidas de protección en forma de compromisos de interés público.

      También habrá un impacto positivo en los registradores y registratarios. La transición al Acuerdo de Registro de Nuevos gTLD proporcionará consistencia a través de todos los registros, conllevando a un entorno más predecible para los usuarios finales y además, el hecho de que la propuesta de renovación al Acuerdo de Registro exija que el Operador de Registro utilice registradores acreditados por la ICANN regidos por el Acuerdo de Acreditación de Registradores (RAA) de 2013, sólo proporcionará más beneficios a los registradores y registratarios.

      Protección de los titulares de derechos: El acuerdo de los nuevos gTLD permitirá al Operador de Registro adoptar mecanismos adicionales de protección de derechos para brindar protección a los titulares de derechos.

      ¿Se observan impactos fiscales o ramificaciones en la ICANN (plan estratégico, plan operativo, presupuesto), la comunidad y/o el público?

      No se espera ningún impacto fiscal significativo como consecuencia de la aprobación por parte de la ICANN de la propuesta de renovación del Acuerdo de Registro .CAT. Sin embargo, cabe señalar que como consecuencia de la aprobación de la Renovación del Acuerdo de Registro, las tarifas de registro anuales proyectadas disminuyen desde USD112.000 a USD56.000. El impacto fiscal nominal se ve compensado por los beneficios a los registratarios y la comunidad de Internet, que incluyen los compromisos de interés público, que requieren el uso de registradores regidos por el RAA del 2013 y la capacidad de la ICANN para designar a un operador de registro provisional de emergencia, en caso de alcanzarse los umbrales de emergencia para los servicios críticos del registro.

      ¿Se observan cuestiones sobre seguridad, estabilidad o flexibilidad relacionadas con el DNS?

      No se esperan cuestiones sobre seguridad, estabilidad ni flexibilidad relacionadas con el DNS como consecuencia de la aprobación de la propuesta de renovación al Acuerdo de Registro del dominio .CAT por parte de la Junta Directiva. De hecho, la propuesta de renovación al Acuerdo de Registro contiene términos cuyo objetivo es agilizar las acciones ante ciertas amenazas a la seguridad o estabilidad del DNS. Como parte su función administrativa organizacional, el 28 de mayo de 2015 la ICANN publicó la versión preliminar de la renovación al Acuerdo de Registro para la recepción de comentarios públicos.

    4. Renovación del Acuerdo de Registro del dominio .TRAVEL

      Visto y considerando que, desde el 12 de mayo al 5 de julio de 2015 la ICANN comenzó un período de comentarios públicos <https://www.icann.org/public-comments/travel-renewal-2015-05-12-en> sobre la propuesta de renovación al Acuerdo de Registro del dominio de alto nivel .TRAVEL <https://www.icann.org/resources/unthemed-pages/travel-2012-02-25-en>.

      Visto y considerando que, la propuesta de renovación al Acuerdo de Registro del dominio .TRAVEL incluye disposiciones modificadas para conciliar el Acuerdo de Registro del dominio .TRAVEL con el Acuerdo de Registro de Nuevos gTLD.

      Visto y considerando que, el foro de comentarios públicos sobre la propuesta de renovación al Acuerdo de Registro cerró el día 5 de julio de 2015, y que la ICANN recibió quince (15) comentarios, tanto por parte de individuos como de organizaciones/grupos. Se proporcionó a la Junta Directiva un resumen y análisis de los comentarios.

      Visto y considerando que, la Junta Directiva ha determinado que, luego de considerar los comentarios, no es necesaria ninguna revisión de la Renovación del Acuerdo de Registro del dominio .TRAVEL propuesto.

      Resuélvase (2015.09.28.05): se aprueba la propuesta de renovación al Acuerdo de Registro .TRAVEL y se autoriza al Presidente y Director Ejecutivo, o quien éste designe, a tomar las medidas apropiadas para finalizar e implementar dicho acuerdo.

      Fundamentos de la Resolución 2015.09.28.05

      ¿Por qué la Junta Directiva aborda el tema ahora?

      La ICANN y la compañía Tralliance Registry Management Company, LLC (el "Operador de Registro") firmaron un Acuerdo de Registro el 5 de mayo de 2005 para el funcionamiento del dominio de alto nivel .TRAVEL. El actual Acuerdo de Registro del dominio .TRAVEL expira el 19 de diciembre de 2015. La propuesta de renovación al Acuerdo de Registro (la "Renovación del Acuerdo de Registro" o el "Acuerdo") fue publicada para la recepción de comentarios públicos entre el 12 de mayo y el 5 de julio de 2015. En este momento, la Junta Directiva está aprobando la Renovación del Acuerdo de Registro para la continuidad de gestión del dominio de alto nivel .TRAVEL por parte del Operador de Registro.

      ¿Cuál es la propuesta que se está considerando?

      La Renovación del Acuerdo de Registro aprobada por la Junta Directiva incluye disposiciones modificadas para conciliar el Acuerdo con el Acuerdo de Registro de Nuevos gTLD. Las modificaciones incluyen: la actualización de las especificaciones técnicas; que requieren la inclusión de ciertas medidas de protección del GAC (Comité Asesor Gubernamental) como compromisos de interés público (las cuales son exigibles mediante el Procedimiento para la Resolución de Disputas en Materia de Compromisos de Interés Público); que requieren el uso de registradores regidos por el Acuerdo de Acreditación de Registradores de 2013 tras alcanzar un determinado umbral; y la actualización de las tarifas de registro.

      Con el fin de dar cuenta de la naturaleza específica del dominio de alto nivel .TRAVEL, un TLD Patrocinado, se han incluido disposiciones relevantes del Acuerdo de Registro de TLD Patrocinados del 5 de mayo de 2005 en la Renovación del Acuerdo de Registro. Específicamente, en la Especificación 12 se identifican disposiciones de la carta orgánica que describen los sectores de la industria de viajes de conformidad con la comunidad y elegibilidad para la registración. La Renovación del Acuerdo de Registro también refleja las aprobaciones anteriores relativas a los nombres reservados.

      ¿Cuáles son las partes interesadas u otros participantes consultados?

      Desde el 12 de mayo al 5 de julio de 2015, la ICANN llevó a cabo un período de comentarios públicos sobre la propuesta de renovación al Acuerdo de Registro del dominio .TRAVEL, finalizado dicho período, se resumieron y analizaron los comentarios recibidos. En forma adicional, la ICANN entabló negociaciones bilaterales con el Operador de Registro para acordar el paquete de términos a incluirse en la Renovación del Acuerdo de Registro, publicado para la recepción de comentarios públicos.

      ¿Qué inquietudes o cuestiones fueron planteadas por la comunidad?

      Quince (15) miembros de la comunidad participaron en el período de comentarios públicos. En sus comentarios, los miembros de la comunidad plantearon dos cuestiones fundamentales:

      • La transición de los TLD preexistentes a la forma del Acuerdo de Registro de Nuevos gTLD: algunos comentarios públicos expresaron su preocupación por el proceso de la ICANN para utilizar el acuerdo de registro de nuevos gTLD como el punto de partida para la renovación de los acuerdos de registro de los gTLD preexistentes. Estos comentadores sugieren que la adopción de una posición de este tipo tiene el efecto de transformar los Procedimientos de Resolución de Disputas de los Nuevos gTLD posterior a la delegación (por ejemplo, el Procedimiento de Resolución de Disputas por Marcas Comerciales Posterior a la Delegación y el Procedimiento de Resolución de Disputas por Compromisos de Interés Público) y del Sistema Uniforme de Suspensión Rápida (URS) en Políticas de Consenso de facto sin seguir los procedimientos establecidos en los Estatutos de la ICANN para su creación. Por otro lado, otros comentarios apoyaron que la ICANN busque coherencia entre los acuerdos de registro y señalaron que la transición a la nueva forma de acuerdo es parte de las negociaciones bilaterales permisibles.
      • La inclusión del Sistema Uniforme de Suspensión Rápida (URS) y del Procedimiento para la Resolución de Disputas con Posterioridad a la Delegación (PDDRP) en las renovaciones de los acuerdos de los TLD preexistentes, sin pasar a través de un Proceso de Desarrollo de Políticas (PDP): la mayoría de los comentarios recibidos expresaron su objeción a la inclusión del URS a la propuesta de renovación al Acuerdo de Registro .TRAVEL, alegando que el URS puede convertirse en una política de consenso sólo después de que un proceso de desarrollo de políticas (PDP) completo tome lugar con la participación de toda la comunidad de las partes interesadas de la ICANN. Estos comentadores también sugirieron que la imposición del URS a un gTLD preexistente a través del proceso de contratación es una intervención inaceptable del personal en el proceso de formulación de políticas. Por otro lado, algunos comentarios expresaron su apoyo a la inclusión del URS en la Renovación del Acuerdo de Registro, afirmando que los registros tienen libertad para ir más allá de las protecciones mínimas de los derechos y que ello no requiere de un PDP.

      ¿Qué materiales significativos analizó la Junta Directiva?

      Como parte de sus deliberaciones, la Junta Directiva analizó diversos materiales, incluidos, entre otros, los siguientes materiales y documentos:

      ¿Qué factores la Junta Directiva consideró significativos?

      La Junta Directiva examinó cuidadosamente los comentarios públicos recibidos sobre la Renovación del Acuerdo de Registro, junto con el resumen y análisis de esos comentarios. La Junta Directiva también consideró los términos acordados por el Operador de Registro como parte de las negociaciones bilaterales con la ICANN. Si bien la Junta Directiva reconoce las preocupaciones expresadas por algunos miembros de la comunidad con respecto a la inclusión del URS en la Renovación del Acuerdo de Registro, la Junta señala que dicha inclusión del URS se basa en las negociaciones bilaterales entre la ICANN y el Operador de Registro, durante las cuales el Operador de Registro expresó su interés para renovar su acuerdo de registro en base al Acuerdo de Registro de Nuevos gTLD.

      La Junta Directiva señala que el URS fue recomendado por parte del Equipo para la Revisión de la Implementación (IRT) como un mecanismo de protección de los derechos obligatorio (RPM) para todos los nuevos gTLD. Se solicitó a la GNSO ofrecer su visión consensuada respecto de si ciertos mecanismos de protección de derechos propuestos (los cuales incluyen al URS) eran coherentes con la política propuesta por la GNSO para la introducción de los nuevos gTLD, y si eran una opción adecuada y eficaz para lograr los principios y objetivos establecidos por la GNSO. El equipo de STI consideró este asunto y concluyó que: "El uso del URS debe constituir un RPM requerido a todos los nuevos gTLD." Es decir, la GNSO indicó que el URS no era incompatible con ninguna de sus recomendaciones de política existentes.

      Si bien el URS fue desarrollado y perfeccionado a través del proceso aquí descripto, el cual incluyó la revisión pública y discusión en la GNSO, el mismo no ha sido adoptado como una política de consenso y la ICANN no tiene capacidad de exigirlo como obligatorio a ningún TLD que no sea un nuevo solicitante de gTLD presentado durante la ronda de nuevos gTLD de 2012.

      Por consiguiente, la aprobación de la Renovación del Acuerdo de Registro por parte de la Junta Directiva no constituye un movimiento hacia exigir la obligatoriedad del URS a ningún TLD preexistente, y el hacerlo no sería apropiado. En el caso de .TRAVEL, la inclusión del URS se desarrolló como parte de la propuesta surgida en las negociaciones bilaterales entre el Operador de Registro y la ICANN.

      Además, la Junta Directiva consideró los comentarios relativos a la transición de los gTLD preexistentes a la nueva forma del acuerdo de registro. La Junta Directiva señala que acuerdo de registro existente exige la renovación de presunción del acuerdo a su vencimiento, siempre y cuando se cumplan ciertos requisitos. La renovación del acuerdo está sujeta a la negociación de los términos de renovación razonablemente aceptables para la ICANN y para el Operador de Registro. Los términos de la renovación aprobada por la Junta Directiva son el resultado de negociaciones bilaterales previstas en el acuerdo de registro actual y la transición a la nueva forma del acuerdo de registro no violaría la política de la GNSO establecida. Tal como se describe a continuación, la nueva forma del acuerdo de registro ofrece algunas ventajas operativas ―además de los beneficios a los registratarios y la comunidad de Internet, que incluyen los compromisos de interés público―, que requieren el uso de registradores regidos por el RAA del 2013 y la capacidad de la ICANN para designar a un operador de registro provisional de emergencia, en caso de alcanzarse los umbrales de emergencia para los servicios críticos del registro.

      ¿Existen impactos positivos o negativos para la comunidad?

      Como parte del proceso de renovación, la ICANN llevó a cabo una revisión del desempeño reciente del Operador de Registro, según el Acuerdo de Registro del dominio .TRAVEL actualmente vigente. Se encontró que, fundamentalmente, el Operador de Registro ha cumplido con sus requisitos contractuales.

      La aprobación de la Renovación del Acuerdo de Registro por parte de la Junta Directiva también ofrece beneficios técnicos y operacionales positivos. De conformidad con la Renovación del Acuerdo de Registro, en caso de alcanzarse alguno de los umbrales de emergencia para las funciones de registro, el Operador de Registro está de acuerdo en que la ICANN puede designar a un operador de registro provisional de emergencia para el registro del TLD, lo cual mitigaría los riesgos de la estabilidad y la seguridad del Sistema de Nombres de Dominio. Además, la incorporación técnica del Operador de Registro para cumplir con lo dispuesto en el acuerdo de los nuevos gTLD permitirá que el Registro utilice procesos uniformes y automatizados, lo cual facilitará el funcionamiento del TLD. En la Especificación 11, la Renovación del Acuerdo de Registro también incluye medidas de protección en forma de compromisos de interés público.

      También habrá un impacto positivo en los registradores y registratarios. La transición al Acuerdo de Registro de Nuevos gTLD proporcionará consistencia a través de todos los registros, conllevando a un entorno más predecible para los usuarios finales y además, el hecho de que la propuesta de renovación al Acuerdo de Registro exija que el Operador de Registro utilice registradores acreditados por la ICANN regidos por el Acuerdo de Acreditación de Registradores (RAA) de 2013, sólo proporcionará más beneficios a los registradores y registratarios.

      Protección de los titulares de derechos: El acuerdo de los nuevos gTLD permitirá al Operador de Registro adoptar mecanismos adicionales de protección de derechos para brindar protección a los titulares de derechos.

      ¿Se observan impactos fiscales o ramificaciones en la ICANN (plan estratégico, plan operativo, presupuesto), la comunidad y/o el público?

      No se espera ningún impacto fiscal significativo como consecuencia de la aprobación por parte de la ICANN de la propuesta de renovación del Acuerdo de Registro .TRAVEL. Sin embargo, cabe señalar que como consecuencia de la aprobación de la Renovación del Acuerdo de Registro, las tarifas de registro anuales proyectadas disminuyen desde USD46.000 a USD25.000. El impacto fiscal nominal se ve compensado por los beneficios a los registratarios y la comunidad de Internet, que incluyen los compromisos de interés público, que requieren el uso de registradores regidos por el RAA del 2013 y la capacidad de la ICANN para designar a un operador de registro provisional de emergencia, en caso de alcanzarse los umbrales de emergencia para los servicios críticos del registro.

      ¿Se observan cuestiones sobre seguridad, estabilidad o flexibilidad relacionadas con el DNS?

      No se esperan cuestiones sobre seguridad, estabilidad ni flexibilidad relacionadas con el DNS como consecuencia de la aprobación de la propuesta de renovación al Acuerdo de Registro del dominio .TRAVEL por parte de la Junta Directiva. De hecho, la propuesta de renovación al Acuerdo de Registro contiene términos cuyo objetivo es agilizar las acciones ante ciertas amenazas a la seguridad o estabilidad del DNS. Como parte su función administrativa organizacional, el 12 de mayo de 2015 la ICANN publicó la versión preliminar de la renovación al Acuerdo de Registro para la recepción de comentarios públicos.

    5. Renovación del Acuerdo de Registro del dominio .PRO

      Visto y considerando que, desde el 28 de mayo al 7 de julio de 2015 la ICANN comenzó un período de comentarios públicos <https://www.icann.org/public-comments/pro-renewal-2015-05-28-en> sobre la propuesta de renovación al Acuerdo de Registro del dominio de alto nivel .PRO <https://www.icann.org/resources/unthemed-pages/pro-2012-02-25-en>.

      Visto y considerando que, la propuesta de renovación al Acuerdo de Registro del dominio .PRO incluye disposiciones modificadas para conciliar el Acuerdo de Registro del dominio .PRO con el Acuerdo de Registro de Nuevos gTLD.

      Visto y considerando que, el foro de comentarios públicos sobre la propuesta de renovación al Acuerdo de Registro cerró el día 7 de julio de 2015, y que la ICANN recibió catorce (14) comentarios, tanto por parte de individuos como de organizaciones/grupos. Se proporcionó a la Junta Directiva un resumen y análisis de los comentarios.

      Visto y considerando que, la renovación del acuerdo de registro fue actualizada para incluir las disposiciones vigentes en materia de registraciones de dominios en el tercer nivel.

      Resuélvase (2015.09.28.06): se aprueba la propuesta de renovación al Acuerdo de Registro .PRO y se autoriza al Presidente y Director Ejecutivo, o quien éste designe, a tomar las medidas apropiadas para finalizar e implementar dicho acuerdo.

      Fundamentos de la Resolución 2015.09.28.06

      ¿Por qué la Junta Directiva aborda el tema ahora?

      La ICANN y la corporación Registry Services Corporation (el "Operador de Registro") firmaron un Acuerdo de Registro el 22 de abril de 2010 para el funcionamiento del dominio de alto nivel .PRO. El actual Acuerdo de Registro del dominio .PRO expira el 20 de octubre de 2015. La propuesta de renovación al Acuerdo de Registro (la "Renovación del Acuerdo de Registro" o el "Acuerdo") fue publicado para la recepción de comentarios públicos entre el 28 de mayo y el 7 de julio de 2015. En este momento, la Junta Directiva está aprobando la Renovación del Acuerdo de Registro para la continuidad de gestión del dominio de alto nivel .PRO por parte del Operador de Registro.

      ¿Cuál es la propuesta que se está considerando?

      La Renovación del Acuerdo de Registro aprobada por la Junta Directiva incluye disposiciones modificadas para conciliar el Acuerdo con el Acuerdo de Registro de Nuevos gTLD. Las modificaciones incluyen: la actualización de las especificaciones técnicas; que requieren la inclusión de ciertas medidas de protección del GAC (Comité Asesor Gubernamental) como compromisos de interés público (las cuales son exigibles mediante el Procedimiento para la Resolución de Disputas en Materia de Compromisos de Interés Público); que requieren el uso de registradores regidos por el Acuerdo de Acreditación de Registradores de 2013 tras alcanzar un determinado umbral; y la eliminación del precio máximo en las tarifas que el registro puede cobrar a los registradores.

      Específicamente, se propone reemplazar a las restricciones de registración existentes en el Apéndice 11 del Acuerdo del dominio .PRO por el conjunto de los compromisos de interés público estándar aplicable a todos los nuevos gTLD. Sin embargo, la propuesta de renovación del acuerdo de registro fue actualizada para incluir las disposiciones vigentes en materia de registraciones de dominios en el tercer nivel. Además, se agregaron las Medidas de Protección 1 a 3 de la Categoría 1 del GAC a la Especificación 11. La Renovación del Acuerdo de Registro también elimina el precio máximo en las tarifas que el registro puede cobrar a los registradores por los nombres de dominio, y refleja las aprobaciones anteriores relativas a los nombres reservados.

      ¿Cuáles son las partes interesadas u otros participantes consultados?

      Desde el 28 de mayo al 7 de julio de 2015, la ICANN llevó a cabo un período de comentarios públicos sobre la propuesta de renovación al Acuerdo de Registro del dominio .PRO, finalizado dicho período, se resumieron y analizaron los comentarios recibidos. En forma adicional, la ICANN entabló negociaciones bilaterales con el Operador de Registro para acordar el paquete de términos a incluirse en la Renovación del Acuerdo de Registro, publicado para la recepción de comentarios públicos.

      ¿Qué inquietudes o cuestiones fueron planteadas por la comunidad?

      Catorce (14) miembros de la comunidad participaron en el período de comentarios públicos. En sus comentarios, los miembros de la comunidad plantearon dos cuestiones fundamentales:

      • La transición de los TLD preexistentes a la forma del Acuerdo de Registro de Nuevos gTLD: Algunos comentarios públicos expresaron su preocupación por el proceso de la ICANN para utilizar el acuerdo de registro de nuevos gTLD como el punto de partida para la renovación de los acuerdos de registro de los gTLD preexistentes. Estos comentadores sugieren que la adopción de una posición de este tipo tiene el efecto de transformar los Procedimientos de Resolución de Disputas de los Nuevos gTLD posterior a la delegación (por ejemplo, el Procedimiento de Resolución de Disputas por Marcas Comerciales Posterior a la Delegación y el Procedimiento de Resolución de Disputas por Compromisos de Interés Público) y del Sistema Uniforme de Suspensión Rápida (URS) en Políticas de Consenso de facto sin seguir los procedimientos establecidos en los Estatutos de la ICANN para su creación. Por otro lado, otros comentarios apoyaron que la ICANN busque coherencia entre los acuerdos de registro y señalaron que la transición a la nueva forma de acuerdo es parte de las negociaciones bilaterales permisibles.
      • La inclusión del Sistema Uniforme de Suspensión Rápida (URS) y del Procedimiento para la Resolución de Disputas con Posterioridad a la Delegación (PDDRP) en las renovaciones de los acuerdos de los TLD preexistentes, sin pasar a través de un Proceso de Desarrollo de Políticas (PDP): la mayoría de los comentarios recibidos expresaron su objeción a la inclusión del URS a la propuesta de renovación al Acuerdo de Registro .PRO, alegando que el URS puede convertirse en una política de consenso sólo después de que un proceso de desarrollo de políticas (PDP) completo tome lugar con la participación de toda la comunidad de las partes interesadas de la ICANN. Estos comentadores también sugirieron que la imposición del URS a un gTLD preexistente a través del proceso de contratación es una intervención inaceptable del personal en el proceso de formulación de políticas. Por otro lado, algunos comentarios expresaron su apoyo a la inclusión del URS en la Renovación del Acuerdo de Registro, afirmando que los registros tienen libertad para ir más allá de las protecciones mínimas de los derechos y que ello no requiere de un PDP.

      ¿Qué materiales significativos analizó la Junta Directiva?

      Como parte de sus deliberaciones, la Junta Directiva analizó diversos materiales, incluidos, entre otros, los siguientes materiales y documentos:

      ¿Qué factores la Junta Directiva consideró significativos?

      La Junta Directiva examinó cuidadosamente los comentarios públicos recibidos sobre la Renovación del Acuerdo de Registro, junto con el resumen y análisis de esos comentarios. La Junta Directiva también consideró los términos acordados por el Operador de Registro como parte de las negociaciones bilaterales con la ICANN. Si bien la Junta Directiva reconoce las preocupaciones expresadas por algunos miembros de la comunidad con respecto a la inclusión del URS en la Renovación del Acuerdo de Registro, la Junta señala que dicha inclusión del URS se basa en las negociaciones bilaterales entre la ICANN y el Operador de Registro, durante las cuales el Operador de Registro expresó su interés para renovar su acuerdo de registro en base al Acuerdo de Registro de Nuevos gTLD.

      La Junta Directiva señala que el URS fue recomendado por parte del Equipo para la Revisión de la Implementación (IRT) como un mecanismo de protección de los derechos obligatorio (RPM) para todos los nuevos gTLD. Se solicitó a la GNSO ofrecer su visión consensuada respecto de si ciertos mecanismos de protección de derechos propuestos (los cuales incluyen al URS) eran coherentes con la política propuesta por la GNSO para la introducción de los nuevos gTLD, y si eran una opción adecuada y eficaz para lograr los principios y objetivos establecidos por la GNSO. El equipo de STI consideró este asunto y concluyó que: "El uso del URS debe constituir un RPM requerido a todos los nuevos gTLD." Es decir, la GNSO indicó que el URS no era incompatible con ninguna de sus recomendaciones de política existentes.

      Si bien el URS fue desarrollado y perfeccionado a través del proceso aquí descripto, el cual incluyó la revisión pública y discusión en la GNSO, el mismo no ha sido adoptado como una política de consenso y la ICANN no tiene capacidad de exigirlo como obligatorio a ningún TLD que no sea un nuevo solicitante de gTLD presentado durante la ronda de nuevos gTLD de 2012.

      Por consiguiente, la aprobación de la Renovación del Acuerdo de Registro por parte de la Junta Directiva no constituye un movimiento hacia exigir la obligatoriedad del URS a ningún TLD preexistente, y el hacerlo no sería apropiado. En el caso de .PRO, la inclusión del URS se desarrolló como parte de la propuesta surgida en las negociaciones bilaterales entre el Operador de Registro y la ICANN.

      Además, la Junta Directiva consideró los comentarios relativos a la transición de los gTLD preexistentes a la nueva forma del acuerdo de registro. La Junta Directiva señala que acuerdo de registro existente exige la renovación de presunción del acuerdo a su vencimiento, siempre y cuando se cumplan ciertos requisitos. La renovación del acuerdo está sujeta a la negociación de los términos de renovación razonablemente aceptables para la ICANN y para el Operador de Registro. Los términos de la renovación aprobada por la Junta Directiva son el resultado de negociaciones bilaterales previstas en el acuerdo de registro actual y la transición a la nueva forma del acuerdo de registro no violaría la política de la GNSO establecida. Tal como se describe a continuación, la nueva forma del acuerdo de registro ofrece algunas ventajas operativas ―además de los beneficios a los registratarios y la comunidad de Internet, que incluyen los compromisos de interés público―, que requieren el uso de registradores regidos por el RAA del 2013 y la capacidad de la ICANN para designar a un operador de registro provisional de emergencia, en caso de alcanzarse los umbrales de emergencia para los servicios críticos del registro.

      ¿Existen impactos positivos o negativos para la comunidad?

      Como parte del proceso de renovación, la ICANN llevó a cabo una revisión del desempeño reciente del Operador de Registro, según el Acuerdo de Registro del dominio .PRO actualmente vigente. Se encontró que, fundamentalmente, el Operador de Registro ha cumplido con sus requisitos contractuales.

      La aprobación de la Renovación del Acuerdo de Registro por parte de la Junta Directiva también ofrece beneficios técnicos y operacionales positivos. De conformidad con la Renovación del Acuerdo de Registro, en caso de alcanzarse alguno de los umbrales de emergencia para las funciones de registro, el Operador de Registro está de acuerdo en que la ICANN puede designar a un operador de registro provisional de emergencia para el registro del TLD, lo cual mitigaría los riesgos de la estabilidad y la seguridad del Sistema de Nombres de Dominio. Además, la incorporación técnica del Operador de Registro para cumplir con lo dispuesto en el acuerdo de los nuevos gTLD permitirá que el Registro utilice procesos uniformes y automatizados, lo cual facilitará el funcionamiento del TLD. En la Especificación 11, la Renovación del Acuerdo de Registro también incluye medidas de protección en forma de compromisos de interés público, entre ellos las Medidas de Protección 1 a 3 de la Categoría 1 del GAC.

      También habrá un impacto positivo en los registradores y registratarios. La transición al Acuerdo de Registro de Nuevos gTLD proporcionará consistencia a través de todos los registros, conllevando a un entorno más predecible para los usuarios finales y además, el hecho de que la propuesta de renovación al Acuerdo de Registro exija que el Operador de Registro utilice registradores acreditados por la ICANN regidos por el Acuerdo de Acreditación de Registradores (RAA) de 2013, sólo proporcionará más beneficios a los registradores y registratarios.

      Protección de los titulares de derechos: El acuerdo de los nuevos gTLD permitirá al Operador de Registro adoptar mecanismos adicionales de protección de derechos para brindar protección a los titulares de derechos.

      ¿Se observan impactos fiscales o ramificaciones en la ICANN (plan estratégico, plan operativo, presupuesto), la comunidad y/o el público?

      No se espera ningún impacto fiscal significativo como consecuencia de la aprobación por parte de la ICANN de la propuesta de renovación del Acuerdo de Registro .PRO

      ¿Se observan cuestiones sobre seguridad, estabilidad o flexibilidad relacionadas con el DNS?

      No se esperan cuestiones sobre seguridad, estabilidad ni flexibilidad relacionadas con el DNS como consecuencia de la aprobación de la propuesta de renovación al Acuerdo de Registro del dominio .PRO por parte de la Junta Directiva. De hecho, la propuesta de renovación al Acuerdo de Registro contiene términos cuyo objetivo es agilizar las acciones ante ciertas amenazas a la seguridad o estabilidad del DNS. Como parte su función administrativa organizacional, el 28 de mayo de 2015 la ICANN publicó la versión preliminar de la renovación al Acuerdo de Registro para la recepción de comentarios públicos.

    Todos los miembros presentes de la Junta Directiva votaron a favor de las Resoluciones 2015.09.28.01, 2015.09.28.02, 2015.09.28.03, 2015.09.28.04, 2015.09.28.05 y 2015.09.28.06. Wolfgang Kleinwächter, Erika Mann y Bruce Tonkin no estaban disponibles para votar sobre la resolución. Las resoluciones fueron aprobadas.

  2. Orden del Día Principal:

    1. Contratación de la sede para la reunión de la ICANN de junio de 2016

      Cherine Chalaby, Presidente del Comité Financiero, presentó el tema del orden del día. El lugar propuesto para la reunión de la ICANN a realizarse en el mes de junio de 2016, es la Ciudad de Panamá, Panamá. Cherine señaló que el costo total de la sede tiene un precio competitivo y se compara favorablemente con otros lugares de reunión, a saber: Singapur, Buenos Aires y Dublín. La Junta Directiva debatió respecto a que la reunión a celebrarse en junio de 2016 será la primera reunión pública del tipo "B", que abarca menos días y menos eventos en comparación con las otras dos reuniones públicas estándar de la ICANN en el año.

      Cherine presentó la moción, George Sadowsky la secundó y la Junta Directiva tomó la siguiente medida:

      Visto y considerando que la ICANN planea celebrar su segunda reunión pública de 2016 en la región de América Latina y el Caribe.

      Visto y considerando que el personal ha finalizado una revisión exhaustiva de todas las sedes propuestas en América Latina y el Caribe, y considera que la de Ciudad de Panamá, Panamá, es la más adecuada.

      Resuélvase (2015.09.28.07): la Junta Directiva autoriza al Presidente y Director Ejecutivo, o a quienes éste designe, a realizar y facilitar todas las contrataciones y desembolsos que se requieran para el centro de convenciones/hotel, sede de la reunión pública de la ICANN de junio de 2016 a realizarse en la Ciudad de Panamá, Panamá, hasta un monto máximo de USD1,1 millones.

      Resuélvase (2015.09.28.08): algunos puntos específicos de esta resolución tendrán carácter confidencial por motivos de negociación, conforme al artículo III, sección 5.2 de los Estatutos de la ICANN, hasta que el Presidente y Director Ejecutivo determine que la información confidencial puede publicarse.

      Todos los miembros de la Junta Directiva votaron a favor de las resoluciones 2015.09.28.07 y 2015.09.28.08. Wolfgang Kleinwächter, Erika Mann y Bruce Tonkin no estaban disponibles para votar sobre la resolución. Las resoluciones fueron aprobadas.

      Fundamentos para las Resoluciones 2015.09.28.07 - 2015.09.28.08

      Como parte de su calendario de reuniones públicas, la ICANN actualmente celebra tres reuniones al año en regiones geográficas distintas (de conformidad con lo establecido en los Estatutos de la ICANN). La Reunión No. 56 de la ICANN, programada para el 27 al 30 de junio de 2016, se celebrará en la región geográfica de América Latina y el Caribe. El día 23 de marzo de 2015, se publicó una convocatoria para recomendar la ubicación de la reunión en América Latina y el Caribe. La ICANN recibió diversas propuestas.

      El personal realizó un análisis exhaustivo de todas las propuestas, así como también de otras sedes, y preparó un documento para identificar aquellas que cumplían con los criterios de selección para reuniones (consulte http://meetings.icann.org/location-selection-criteria). En función de las propuestas y el análisis, la ICANN ha identificado a la Ciudad de Panamá, Panamá, como sede para la Reunión N. º 56 de la ICANN.

      La Junta Directiva revisó la información presentada por el personal para celebrar la reunión pública de la ICANN de junio de 2016, en la Ciudad de Panamá, Panamá, y determinó que la propuesta cumple con los factores importantes de los criterios de selección para reuniones, así como con los costos relacionados para las instalaciones seleccionadas.

      Se prevé un impacto financiero sobre la ICANN como resultado de la celebración de la reunión y del suministro de asistencia para viajes, según sea necesario, así como también sobre la comunidad, cuyos miembros deberán costearse el traslado a la reunión. Sin embargo, dicho impacto hubiese existido independientemente de la sede seleccionada para la reunión. Esta acción no tendrá impacto alguno sobre la seguridad o la estabilidad del DNS.

      La Junta Directiva agradece a todos aquellos que recomendaron sedes para celebrar la reunión n. º 56 de la ICANN.

      Esta decisión forma parte de las funciones administrativas y organizacionales que no requieren comentario público.

    2. Contratación y desembolso para la nueva Iniciativa de ERP

      Cherine Chalaby, Presidente del Comité Financiero, presentó el tema del orden del día. El Comité de Finanzas recomienda que la Junta Directiva apruebe la contratación e implementación de una nueva solución integrada de planificación de recursos empresariales (ERP) para reemplazar la infraestructura actual del sistema de back-office (sistema administrativo de respaldo) de Finanzas, Recursos Humanos y Contratación, que apoya a toda la organización. El asegurar e implementar una solución de ERP integrada bajo un único sistema de registro, mejorará la capacidad de los sistemas, la presentación de informes global y la capacidad de análisis, la productividad y la eficiencia de funciones cruzadas, además de mejorar los controles internos. Cherine también señaló que la implementación de una nueva solución de ERP es más rentable que intentar adaptar el sistema existente.

      Cherine presentó la moción, Ray Plzak la secundó y la Junta Directiva tomó la siguiente medida:

      Visto y considerando que la ICANN ha establecido una necesidad de adquirir una solución integrada de planificación de recursos empresariales (ERP).

      Visto y considerando que, durante su reunión del 11 de septiembre de 2015, el Comité de Finanzas de la Junta examinó las consecuencias financieras de una nueva iniciativa de ERP, y ha considerado alternativas.

      Visto y considerando que ciertos miembros del Comité de Riesgos de la Junta han revisado la solución de ERP sugerida y han brindado pautas al personal en relación a los riesgos y las medidas de mitigación útiles.

      Visto y considerando que tanto el personal como el Comité de Finanzas de la Junta han recomendado que la Junta Directiva autorice al Presidente y Director Ejecutivo, o a quienes éste designe, a tomar todas las medidas necesarias para la ejecución de los contratos para una nueva iniciativa de ERP, tal como se refleja en los materiales de referencia para este documento y a realizar todos los desembolsos necesarios en virtud de dichos contratos.

      Resuélvase (2015.09.28.09): la Junta Directiva autoriza al Presidente y Director Ejecutivo, o a quienes éste designe, a tomar todas las medidas necesarias para la ejecución de los contratos para una nueva solución de ERP, tal como se refleja en los materiales de referencia para este documento y a realizar todos los desembolsos necesarios en virtud de esos contratos.

      Resuélvase (2015.09.28.10): algunos puntos específicos de esta resolución tendrán carácter confidencial por motivos de negociación, conforme al artículo III, sección 5.2 de los Estatutos de la ICANN, hasta que el Presidente y Director Ejecutivo determine que la información confidencial puede publicarse.

      Todos los miembros de la Junta Directiva votaron a favor de las resoluciones 2015.09.28.09 y 2015.09.28.10. Erika Mann no se encontraba disponible al momento de la votación de las resoluciones. Las resoluciones fueron aprobadas.

      Fundamentos de las Resoluciones 2015.09.28.09 - 2015.09.28.10

      Durante los últimos cinco años, la ICANN ha crecido en tamaño y complejidad en muchas maneras, incluyéndose pero no limitándose a lo siguiente: (i) el personal se ha multiplicado por tres; (ii) la presencia global se amplió a tres oficinas nodales y varios centros de participación; y (iii) los procesos se volvieron más globales y complejos. Mientras tanto, la infraestructura de los sistemas administrativos de respaldo separados de Finanzas, Recursos Humanos y Contratación que asisten a la organización actual fue diseñada e implementada hace al menos cinco años. El asegurar e implementar una solución integrada de planificación de recursos empresariales (ERP) bajo un único sistema de registro, mejorará la capacidad de los sistemas, la presentación de informes global y la capacidad de análisis, así como la productividad y la eficiencia de funciones cruzadas, además de mejorar los controles internos y por lo tanto acelerar el progreso de la ICANN hacia la excelencia operacional.

      El personal realizó un análisis exhaustivo de las dos opciones disponibles: (i) la adaptación de los conjuntos de sistemas existentes para mejorar apenas sus capacidades y desarrollar interfaces, cuando fuese posible; y (ii) la implementación de una solución de ERP integrada. Si bien el costo de la opción de adaptación sería menor en el primer año, los costos totales quinquenales superarían significativamente la opción del ERP integrado, dado que la adaptación continuaría requiriendo mejoras significativas durante los cinco años. Además, la modificación sólo mejoraría apenas las capacidades y eficiencias del sistema administrativo de respaldo, y se necesitarían desarrollos costosos, complejos y con interfaces de alto mantenimiento, resultando en un conjunto de capacidades muy por debajo de la solución integrada.

      Como resultado, la solución de ERP integrada se considera una solución viable y más rentable.

      El proyecto de la solución de ERP integrada ha sido diseñado de la siguiente manera:

      Recursos internos: El proyecto fue considerado en forma temprana pero se retrasó hasta contar con la disponibilidad de recursos de personal de alto nivel con amplia experiencia y hasta que cada unidad de negocio involucrada hubo alcanzado el nivel de madurez adecuado (Tecnologías de la Información, Finanzas, Recursos Humanos, Contratación). Con la contratación de un Director Sénior de Tecnologías de la Información en 2014 y un Vicepresidente de Finanzas en marzo de 2015, ambos con amplia experiencia en grandes proyectos de implementación de sistemas, se cumplieron las condiciones. Los recursos internos incluyen:

      1. Tres equipos de expertos en la materia: cada uno de ellos con dos niveles de expertos (un líder y expertos para cada función)
      2. Cuatro recursos de rellenado que cubren el período de diseño e implementación a fin de garantizar el funcionamiento diario mientras se brinda un enfoque experto adecuado al proyecto de ERP.
      3. Un gerente de proyecto dedicado (contratado) con amplia experiencia en la implementación de ERP.
      4. Tres recursos de Tecnologías de la Información (IT): un Director Sénior de IT (supervisión y gestión), un analista de negocios de IT y un gerente de IT (uno para Recursos Humanos, uno para Finanzas/Contratación)
      5. Un comité directivo que incluye: Al Director de Innovación y Tecnologías de Información (CIIO), al Director de Operaciones (COO), al Director de Finanzas (CFO) y al Director Sénior de Tecnologías de la Información.
      6. Un recurso para la gestión de cambios de Recursos Humanos (a ser contratado)
      7. Revisiones de ERM (Gestión de Riesgo Empresarial) internas desde el inicio del proyecto.

      Recursos externos:

      1. Los proveedores de ERP más grandes tienen una amplia red de asociados comerciales certificados, así como recursos de consultoría internos que la ICANN aprovechará.
      2. La ICANN seleccionará a los consultores técnicos más calificados a través de un proceso de entrevistas individuales.

      Solución técnica: Un modelo de Software como un Servicio (SaaS):

      1. Una plataforma basada en la web lista para configurar, utilizada por todos los clientes del proveedor de soluciones.
      2. Cada cliente configura una amplia gama de capacidades para las necesidades de su unidad de negocio (sin desarrollo de software, sin personalización)
      3. Para cada función, el rango de procesos estándar y opcionales está diseñado sobre la base del proceso y controla las mejores prácticas, listos para la configuración.
      4. La plataforma se actualiza con regularidad y tiene un rico plan de acción para nuevas capacidades a disposición de todos los clientes de la plataforma, sin costo adicional.
      5. El rendimiento del sistema es controlado y administrado por el proveedor del SaaS para Acuerdos de Nivel de Servicio (SLA).

      Sistema de seguridad:

      1. Transferencia de datos: se diseñó una estrategia de conversión de datos de varios pasos que incluye: prueba, reconciliación y proceso de validación.
        1. La ICANN convertirá los datos transaccionales históricos y todos los datos del archivo maestro.
        2. Todos los programas de conversión serán probados minuciosamente para corroborar exactitud e integridad.
        3. La ICANN realizará pruebas unitarias, dos Pruebas Piloto de Salas de Conferencia (CRP), las cuales comprobarán nuestros procesos comerciales para la configuración del sistema y la conversión de los archivos de datos.
        4. La ICANN realizará una prueba piloto comercial, la cual simulará el actual proceso comercial desde principio a fin (por ejemplo, orden de cobranza y procuración de pago), además de comprobar la conversión completa de los datos históricos y del archivo maestro.
      2. Seguridad de datos: El proceso de Solicitud de Propuesta (RFP) incluye demos en la recuperación de desastres, gestión de operaciones del centro de datos, cifrado de datos, registros de datos, entorno de ERP exclusivo de la ICANN:
        1. La ICANN configurará estándares de clase mundial para la seguridad de datos, que incluye: el cifrado de datos, la gestión de controles de acceso, el acceso y la revisión de los registros del sistema y la configuración de seguridad del acceso en base a buenos controles internos.

      Además, la Junta Directiva examinó las recomendaciones del personal y del Comité de Finanzas de la Junta en materia de contratación y autoridad de desembolso para una nueva solución de ERP.

      Habrá un impacto financiero en la ICANN para implementar una nueva solución de ERP. Este impacto está actualmente incluido en el Plan Operativo y Presupuesto para el Año Fiscal 2016 (FY16) aprobado por la Junta Directiva el 25 de junio de 2015. Esta medida no tendrá ningún impacto directo sobre la seguridad, estabilidad y flexibilidad del sistema de nombres de dominio.

      Esta decisión forma parte de las funciones administrativas y organizacionales que no requieren comentario público.

    3. Liberación de Fondos de Reserva - Costos de la Transición de la Custodia de la IANA por parte del Gobierno de los Estados Unidos

      Cherine Chalaby, Presidente del Comité Financiero, presentó el tema de la agenda. Visto y considerando que, la Junta Directiva ha autorizado la liberación de los fondos del Fondo de Reserva para cubrir los costos incurridos durante el Año Fiscal 2015 (FY15) relacionados con la iniciativa de la Transición de la Custodia de la IANA por un monto no mayor a USD7 millones. El importe total de los costos para el proyecto de transición del Gobierno de los Estados Unidos actualmente excede el importe originalmente presupuestado para el Año Fiscal 2015 (FY15) (los costos incurridos ahora ascienden a USD8,7 millones), debido a los costos adicionales de asesoría legal independiente externa que se puso en marcha a petición del CCWG (Grupo de Trabajo Intercomunitario sobre la Mejora de la Responsabilidad de la ICANN) y del CWG (Grupo de Trabajo Intercomunitario). De este modo, el Comité de Finanzas recomienda que la Junta Directiva autorice la liberación de fondos del Fondo de Reserva para cubrir los costos incurridos por un importe de USD1,7 millones.

      La Junta Directiva inició un debate sobre el monto significativo de los costos incurridos en relación con la iniciativa de la Transición de la Custodia de la IANA por parte del Gobierno de los Estados Unidos Varios miembros de la Junta Directiva expresaron su preocupación con respecto a los gastos responsables y eficientes y a las medidas de control de costos para el trabajo futuro, a fin de evitar que los costos se salgan de control. Además la Junta Directiva continuó debatiendo el establecimiento de parámetros y expectativas para los gastos de cualquier futura inversión similar. La Junta Directiva exploró la posibilidad de medidas de ahorro interno para compensar la cantidad que se ha retirado del Fondo de Reserva. La Junta Directiva también discutió la necesidad de revisar las trayectorias de costos y gastos, las expectativas para el Fondo de Reserva, las proyecciones para el Año Fiscal 2016 y el Año Fiscal 2017 y el Plan Operativo quinquenal, con el fin de elaborar recomendaciones sobre cómo mantener el Fondo de Reserva y reducir los gastos.

      Cherine presentó la moción, Gonzalo Navarro la secundó y la Junta Directiva tomó la siguiente medida:

      Visto y considerando que, el 26 de abril de 2015, la Junta Directiva ha autorizado el retiro de fondos del Fondo de Reserva para cubrir los costos incurridos durante el Año Fiscal 2015 (FY15) relacionados con la iniciativa de la Transición de la Custodia de la IANA por un monto no mayor a USD7 millones.

      Visto y considerando que, la ICANN ha incurrido en costos reales de USD8,7 millones durante su Año Fiscal 2015, que incluyeron costos imprevistos de asesoramiento jurídico independiente por un importe de aproximadamente USD3,1 millones.

      Visto y considerando que, la Junta Directiva reitera su declaración realizada el día 25 de junio de 2015 respecto a su "compromiso de apoyar a la comunidad a obtener el asesoramiento que necesite para el desarrollo de recomendaciones que apoyen el proceso de transición, y que también señala la importancia de asegurarse de que los fondos que la comunidad confió a la ICANN se utilicen de manera responsable y eficiente. Es importante que se garantice la continuación de las medidas de control de costos sobre el trabajo futuro del asesoramiento independiente." (Consulte https://www.icann.org/resources/board-material/resolutions-2015-06-25-en#2.c).

      Visto y considerando que, el Comité de Finanzas Junta Directiva ha recomendado que la Junta Directiva autorice la liberación de los fondos del Fondo de Reserva para cubrir los costos reales incurridos durante el Año Fiscal 2015 (FY15) relacionados con la iniciativa de la Transición de la Custodia de la IANA por un monto de USD8,7 millones, y que la Junta Directiva está de acuerdo.

      Resuélvase (2014.09.28.11): la Junta Directiva autoriza al Presidente y Director Ejecutivo, o a quien éste designe, a utilizar el Fondo de Reserva para cubrir los costos incurridos durante el Año Fiscal 2015 (FY15) en relación a la iniciativa de Transición de la Custodia de la IANA por parte del Gobierno de los Estados Unidos por un importe de USD8,7 millones.

      Doce miembros de la Junta Directiva presentes votaron a favor de la Resolución 2015.09.28.11. Ray Plzak y Kuo-Wei Wu votaron en contra de la Resolución 2015.09.28.11. Wolfgang Kleinwächter se abstuvo de votar. Erika Mann no se encontraba disponible al momento de la votación de la Resolución. La Resolución fue aprobada.

      Fundamentos de la Resolución 2015.09.28.11

      La iniciativa de Transición de la Custodia de la IANA por parte del Gobierno de los Estados Unidos es una importante iniciativa a la que la Comunidad de la ICANN en su conjunto está dedicando una cantidad significativa de tiempo y recursos. El apoyo de la ICANN a la Comunidad en su labor hacia una conclusión exitosa del proyecto (que incluye el desarrollo de una propuesta de transición de la custodia de la IANA y el trabajo sobre la responsabilidad) es fundamental para la ICANN.

      Teniendo en cuenta su naturaleza excepcional y la cantidad significativa de costos previstos, la financiación de este proyecto no podría proporcionarse a través de los ingresos anuales por operaciones de la ICANN. En consecuencia, cuando la Junta Directiva aprobó el Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15), incluyó la financiación anticipada de los costos del proyecto (USD7.000.000) a través de un retiro correspondiente del Fondo de Reserva.

      Conforme se incurrió en costos durante el Año Fiscal 2015 (FY15) para este proyecto, la Junta Directiva aprobó el retiro de fondos del Fondo de Reserva para cubrir los costos reales incurridos en el Año Fiscal 2015 (FY15) relacionados con la iniciativa de Transición de la Custodia de la IANA, por un monto de hasta USD7 millones, incluidos en el Plan Operativo y Presupuesto para el Año Fiscal 2015 (FY15) aprobado por la Junta Directiva.

      Como los costos reales totales incurridos durante el Año Fiscal 2015 (FY15) para este proyecto ascendieron a USD8,7 millones, lo cual excede el importe total de USD7 millones del retiro del Fondo de Reserva autorizado por la Junta Directiva mediante su decisión 2015.04.26.17, la ICANN está procediendo a obtener la aprobación de la Junta Directiva para retirar fondos del Fondo de Reserva por el importe total de los costos reales de USD8,7 millones. Esta medida no tendrá ningún impacto directo sobre la seguridad, estabilidad y flexibilidad del sistema de nombres de dominio.

      Esta decisión forma parte de las funciones administrativas y organizacionales que no requieren comentario público.

    4. Programa de Nuevos gTLD: El camino hacia futuras rondas

      Akram Atallah, Presidente de la División Global de Dominios, presentó el tema del orden del día. Se ha solicitado a la Junta Directiva considerar un proceso y un plazo para una nueva ronda del Programa de Nuevos gTLD. Las revisiones de la ronda de 2012 se encuentran actualmente en curso. La Junta Directiva discutió la importancia de que todas las revisiones y la evaluación de las revisiones estén completas antes de comenzar la siguiente ronda, dado que ellas informarán cuándo y cómo se llevará a cabo la siguiente ronda. Una vez que se hayan completado las revisiones y evaluaciones de la comunidad, la Junta Directiva podrá proponer un plazo para el inicio de la próxima ronda del Programa de Nuevos gTLD.

      Chris Disspain prosiguió, Cherine Chalaby secundó la resolución propuesta, y la Junta Directiva tomó la siguiente medida:

      Visto y considerando que, la resolución 2012.02.07.05 de la Junta Directiva reafirmó el compromiso de la ICANN para la apertura de una nueva ronda del Programa de Nuevos gTLD lo más rápidamente posible.

      Visto y considerando que, actualmente se están llevando a cabo las revisiones de la ronda de solicitudes de 2012 del Programa de Nuevos gTLD.

      Visto y considerando que, la Junta Directiva alienta a la participación de las partes interesadas en el proceso de abajo hacia arriba para revisar y desarrollar las futuras rondas del Programa de Nuevos gTLD.

      Resuélvase (2015.09.28.12): la Junta instruye el personal de la ICANN continuar con las revisiones del Programa de Nuevos gTLD conforme lo programado, y alienta a la comunidad de partes interesadas a participar y apoyar un proceso de revisión robusto y significativo.

      Resuélvase (2015.09.28.13): la Junta Directiva realizará un seguimiento del trabajo comunitario con interés y considerará pautas para las futuras rondas, una vez que el proceso de revisión y posible proceso de desarrollo de políticas (PDP) de la GNSO lleguen a una etapa más avanzada.

      Todos los miembros de la Junta Directiva votaron a favor de las resoluciones 2015.09.28.12 y 2015.09.28.13. Erika Mann no se encontraba disponible al momento de la votación de las resoluciones. Las resoluciones fueron aprobadas.

      Fundamentos de las Resoluciones 2015.09.28.12 – 2015.09.28.13

      ¿Por qué la Junta Directiva aborda este tema ahora?

      Actualmente se encuentran en curso numerosas actividades de revisión y de la comunidad, que probablemente informarán cuándo y cómo se llevará a cabo la próxima ronda de solicitudes. Se ha solicitado a la Junta Directiva considerar un proceso y un plazo para una nueva ronda del Programa de Nuevos gTLD, con el fin de ayudar a la ICANN en la planificación a largo plazo, el análisis y la elaboración de presupuestos necesarios para el logro de una próxima ronda eficaz.

      ¿Cuáles son las propuestas que se están considerando?

      La Junta Directiva está considerando el grado en que los numerosos procesos de revisión y actividades de la comunidad actualmente en curso brindarán información respecto a cuándo y cómo se llevará a cabo la próxima ronda del Programa de Nuevos gTLD. Se han considerado tres opciones. La primera establece una fecha prevista para los aportes de la comunidad en rondas futuras y proporciona un plazo aproximado para la realización del proceso de revisión y posible PDP. No compromete a ninguna de las partes a un plazo estricto para finalizar cualquier revisión o actividad de elaboración de políticas, sino que proporciona un plazo aproximado para todas las partes con el fin de ayudar a su planificación. La segunda opción establece un proceso previsto por el cual la Junta Directiva consideraría en primer lugar los resultados de la revisión, antes de encargar al personal la elaboración de planes de implementación y plazos. La tercera opción aplaza el establecimiento de un plazo o conjunto de requisitos previos para la próxima ronda, hasta que el proceso de revisión y/o el PDP se encuentren en una etapa más avanzada.

      En este momento, la Junta Directiva está tomando medidas para alentar la continua ejecución y participación en los actuales procesos de revisión y para aplazar el análisis de planificación de una futura ronda hasta que las revisiones se encuentren en una etapa más avanzada.

      ¿A qué partes interesadas u otros se consultó?

      A partir de septiembre de 2014, el personal de la ICANN publicó y recabó retroalimentación sobre el Plan de Trabajo preliminar para las revisiones del Programa de Nuevos gTLD.4 El Grupo de Deliberación de la GNSO sobre los Procedimientos Posteriores a los Nuevos gTLD ha jugado un rol importante en la discusión de las implicaciones y el desarrollo de políticas para el Programa de Nuevos gTLD. Mientras que la GNSO no ha sido consultada formalmente, un tema recurrente en las discusiones del grupo se ha centrado en qué procesos futuros deben ser considerados al determinar el desarrollo de la próxima ronda. Además, las partes interesadas de la comunidad, tal como: las partes contratadas, los nuevos operadores de registro, los proveedores de servicios de Internet y operadores de IP, y los miembros de la comunidad de usuarios finales, han contribuido con sus perspectivas sobre el plazo de la próxima ronda.

      ¿Qué materiales significativos analizó la Junta Directiva?

      La Junta Directiva examinó el Plan de Trabajo preliminar, la Afirmación de Compromisos (AoC), el cronograma estimado para la compleción de la revisión en base a las estimaciones iniciales de las actividades descriptas en el Plan de Trabajo, el Informe de Cuestiones preliminar de la GNSO del 31 de agosto de 2015, así como las deliberaciones dela GNSO sobre las cuales se basó, las Resoluciones 2012.02.07.05 y 2014.11.17.10 - 2014.11.17.12 en relación a los compromisos para abrir una segunda ronda de solicitudes tan pronto como fuese posible y en consulta con los grupos relevantes de partes interesadas, así como los Mecanismos de Protección de Derechos de las protecciones establecidas para mitigar los posibles problemas con el Programa de Nuevos gTLD.

      ¿Qué factores consideró importantes la Junta Directiva?

      Teniendo en cuenta que los resultados del proceso de revisión son desconocidos y que puede iniciarse un PDP, no es realista en esta etapa inicial establecer un plazo para la apertura de una nueva ronda del Programa de Nuevos gTLD. La Junta Directiva entiende que existe un deseo de mayor certidumbre en gran parte de la comunidad de partes interesadas, pero considera que en este momento es prioritario realizar revisiones significativas de la ronda actual. Las discusiones de los cronogramas para futuras rondas volverán a ser analizadas en un momento posterior.

      ¿Se observan impactos positivos o negativos en la comunidad?

      Es probable que algunos en la comunidad se sientan frustrados por la falta de compromiso con un plazo o procedimiento definitivo. Sin embargo, la acción de la Junta Directiva intenta garantizar que se le brinde el peso adecuado al proceso de revisión, con el fin de evaluar plenamente los resultados de la primera ronda del Programa de Nuevos gTLD. Esto puede ser visto por algunas unidades constitutivas como una falta de respuesta a las preguntas relativas a la manera en que se espera que las diversas revisiones y procesos actualmente en curso den lugar a la apertura de una segunda ronda. Sin embargo, este enfoque permite continuar el diálogo de la comunidad en relación con las áreas críticas que deben abordarse en la creación de este conjunto de medidas. El moverse demasiado rápido hacia una segunda vuelta, sin tiempo suficiente para la revisión puede inhibir a la comunidad de considerar adecuadamente las lecciones aprendidas a partir de la primera ronda de solicitudes, como parte del desarrollo de la próxima ronda. Además, el compromiso para con un plazo o proceso esperado puede crear expectativas poco realistas por parte de las comunidades de partes interesadas respecto a cuándo esperar que una segunda ronda tome lugar.

      ¿Se observan ramificaciones o impactos fiscales en la ICANN (plan estratégico, plan operativo, presupuesto), la comunidad o el público?

      Algunas de las revisiones del Programa requieren la contratación de especialistas y ya se han asignado fondos para estas actividades en el presupuesto del Año Fiscal 2016 (FY16). Sin embargo, no hay implicancias presupuestarias adicionales previstas como resultado de esta resolución que no hayan sido planificadas y/o asignadas.

      ¿Se observan cuestiones sobre seguridad, estabilidad o flexibilidad relacionadas con el DNS?

      No hay impacto inmediato para la seguridad, la estabilidad o la flexibilidad del DNS como resultado de tomar esta resolución, pero debe tenerse en cuenta que la seguridad, la estabilidad y la flexibilidad del DNS es una de las áreas propuestas de estudio.

      ¿Hay un proceso de políticas definido dentro de las organizaciones de apoyo de la ICANN o de la decisión de función organizativa y administrativa de la ICANN que requiera comentario público, o que no lo requiera?

      Este no es un proceso de políticas definido, ya que los resultados de la primera ronda del Programa de Nuevos gTLD aún no se han evaluado y aún se debe establecer un proceso de políticas definitivo. Sin embargo, es probable que una vez que finalicen, las revisiones y el PDP se publiquen para la recepción de comentarios públicos.

    5. Requisitos de seguro para el Acuerdo de Acreditación de Registradores

      Mike Silber, Copresidente del Comité de Riesgos, presentó el tema del orden del día. La Política de Acreditación de Registradores exige a los registradores mantener una póliza de seguro de Responsabilidad Comercial General ("CGL") dentro de los límites de al menos USD500.000 o un monto menor si el registrador puede demostrar que un límite menor aún cubriría una indemnización razonable en caso de una pérdida cubierta. Los Acuerdos de Acreditación de Registradores (RAAS) requieren que los registradores mantengan la cobertura a un nivel de USD500.000. La ICANN ha recibido retroalimentación respecto a que los requisitos de seguro de CGL del RAA no alientan la intención de la Declaración de la Política de Acreditación de Registradores para el requisito del seguro de CGL, el cual fue concebido para ofrecer a los registratarios un recurso en caso de actos cubiertos de negligencia por parte de un registrador. Además, hasta la fecha, dicha cobertura de seguro no ha sido activada. La Junta Directiva deliberó respecto a que este requisito de seguro representa un obstáculo para el desarrollo del mercado de registradores en los países en vías de desarrollo. En base a esta información, la Junta Directiva discutió la aplicación de una exención al requisito de seguro de CGL.

      Mike presentó la moción, Gonzalo Navarro la secundó y la Junta Directiva tomó la siguiente medida:

      Visto y considerando que, la Declaración de la Política de Acreditación de Registradores de la ICANN ("Política de Acreditación") adoptada en 1999, dispone que los registradores deben tener y mantener una póliza de seguro de Responsabilidad Comercial General (CGL) con límites de al menos USD500.000 o un monto menor si el registrador puede demostrar que un límite menor aún cubriría una indemnización razonable en caso de una pérdida cubierta.

      Visto y considerando que, los Acuerdos de Acreditación de Registradores exigen que los registradores mantengan la cobertura a un nivel de USD500.000 (sin referencia a límites potencialmente más bajos de la Política de Acreditación).

      Visto y considerando que, la ICANN ha recibido retroalimentación respecto a que los requisitos de seguro de CGL del RAA no alientan la intención de la Declaración de la Política de Acreditación de Registradores para el requisito del seguro de CGL, de ofrecer a los registratarios un recurso en caso de actos cubiertos de negligencia por parte de un registrador y que plantea un obstáculo para el desarrollo del mercado de registradores en los países en vías de desarrollo.

      Visto y considerando que, la ICANN solicitó dos rondas de comentarios públicos sobre este tema en mayo de 2014 y enero de 2015.

      Resuélvase (2015.09.28.14): se establece la exención al requisito del seguro de CGL en el RAA de 2009 y de 2013, y se instruye al Presidente y Director Ejecutivo, o a quienes éste designe, tomar las medidas necesarias para implementar la presente resolución.

      Resuélvase (2015.09.28.15): se solicita a la GNSO evaluar si realizar o no labor de políticas sobre un reemplazo para los requisitos de seguro, a la luz de la Declaración de la Política de Acreditación de Registradores.

      Todos los miembros de la Junta Directiva votaron a favor de las resoluciones 2015.09.28.14 y 2015.09.28.15. Erika Mann no se encontraba disponible al momento de la votación de las resoluciones. Las resoluciones fueron aprobadas.

      Fundamentos para las Resoluciones 2015.09.28.14 y 2015.09.28.15

      ¿Por qué la Junta Directiva aborda el tema ahora?

      Los Acuerdos de Acreditación de Registradores de 2009 y de 2013 exigen a los registradores obtener un seguro de Responsabilidad Comercial General (CGL) con un límite de póliza de al menos USD500.000. Este requisito se basa en el texto de la Declaración de la Política de Acreditación de Registradores de la ICANN, la cual dispone que los registradores deben tener y mantener una póliza de seguro de Responsabilidad Comercial General (CGL) con límites de al menos USD500.000 o un monto menor si el registrador puede demostrar que un límite menor aún cubriría una indemnización razonable en caso de una pérdida cubierta. El requisito del RAA no incorpora la flexibilidad de límites de póliza más bajos dispuesta en la Declaración de la Política de Acreditación de Registradores de la ICANN.

      Generalmente, las pólizas de seguro de CGL protegen a las empresas frente a los reclamos de responsabilidad por lesiones corporales y daños materiales producidos en sus instalaciones, en algunos casos incluso, frente a responsabilidad de publicidad y perjuicios personales. Sin embargo, la mayoría de las pólizas de CGL excluirían la cobertura de los errores u omisiones por parte del registrador. En otras palabras, en general, los titulares de nombres de dominio no podrían recibir indemnización de una compañía de seguros (en virtud de una póliza de CGL) por actos negligentes del registrador, tal como la eliminación accidental o la falta de renovación de un registro, o permitir que un nombre de dominio sea secuestrado.

      Este requisito de seguro plantea tanto retos financieros como prácticos para algunas entidades que buscan convertirse en un registrador acreditado por la ICANN. Los comentarios de la comunidad sugieren que este requisito perjudica de manera desproporcionada a los registradores y potenciales registradores en los lugares donde este tipo de seguro es excesivamente caro y/o inexistente.

      Por lo tanto, en este momento, la Junta Directiva está tomando la medida de aprobar una exención al requisito del seguro de CGL existente en el RAA de 2009 y de 2013, debido a que los requisitos del seguro de Responsabilidad Comercial General (CGL) no parecen alentar los objetivos de política previstos y suponen una carga excesiva para los potenciales registradores. A pesar de la considerable consulta pública, no existen pruebas de que el requisito de CGL haya proporcionado algún beneficio para los registratarios.

      ¿Cuáles son las partes interesadas u otros participantes consultados?

      La ICANN ha recibido retroalimentación por parte de potenciales registradores, indicando que el seguro obligatorio es difícil o imposible de obtener en su región. En la reunión de la ICANN celebrada en Singapur en 2014, se realizó un taller sobre este y otros temas relacionados con las regiones subatendidas. La ICANN ha realizado consultas con un asesor de seguros exterior, así como con muchos registradores actuales y potenciales. La ICANN solicitó dos rondas de comentarios públicos sobre este tema en mayo de 2014 y enero de 2015. Como parte de la medida de la Junta Directiva, ésta alienta a la GNSO para analizar este asunto.

      ¿Qué inquietudes o cuestiones fueron planteadas por la comunidad?

      Los miembros de la comunidad han informado a la ICANN que el requisito del seguro existente puede ser difícil o imposible de cumplirse en muchas jurisdicciones, particularmente en jurisdicciones fuera de América del Norte y Europa. Algunas personas comentaron que, en algunos países, el seguro de CGL ni siquiera está disponible y, aunque en otros países sí está disponible, el límite de USD500.000 podría ser excesivo (y por lo tanto comercialmente inviable), en relación con las condiciones del mercado, el costo de vida y los riesgos de hacer negocios en la región respectiva. Además, algunos comentadores cuestionaron si el requisito continúa siendo necesario a la luz de las mejoras institucionales de la ICANN en otras áreas, tales como la exigibilidad de cumplimiento y la custodia de datos. Algunos miembros de la comunidad han sugerido que la ICANN podría proporcionar a los registradores nuevos y existentes, una lista de compañías de seguros conocidas por brindar servicio a los negocios existentes de registradores, de modo que esos registradores puedan garantizar la obtención del seguro exigido para obtener la acreditación por parte de la ICANN.

      Sin embargo, otros miembros de la comunidad han advertido de que los registratarios podrían quedar sin protección en caso de aplicar una exención al requisito de CGL.

      ¿Qué materiales significativos analizó la Junta Directiva para tomar esta decisión?

      Para llegar a esta decisión, la Junta Directiva consideró dos informes de comentarios públicos recibidos sobre este tema, publicados el 2 de septiembre de 2014 y el 3 de abril de 2015 así como materiales de referencia de la Junta Directiva. La Junta Directiva también consideró la Declaración de la Política de Acreditación de Registradores, así como los Acuerdos de Acreditación de Registradores de 2009 y de 2013.

      ¿Qué factores consideró importantes la Junta Directiva para tomar esta decisión?

      El actual requisito de seguro no sirve a su propósito inicialmente previsto de proteger a los registratarios ante actos erróneos cometidos por parte de los registradores. Por otra parte, el requisito inhibe la competencia en las regiones subatendidas del mundo. Debido a que el requisito de seguro original era una cuestión de política de la ICANN, la GNSO es el órgano competente para decidir la idoneidad de un requisito de reemplazo.

      ¿Cuáles son los impactos fiscales de esta decisión?

      Esta decisión no tiene impacto fiscal sobre la ICANN. La eliminación del requisito podría reducir los costos para los registradores existentes y potenciales que opten por no mantener un seguro de responsabilidad comercial general.

      ¿Cuáles son los impactos de esta decisión sobre la comunidad?

      En base a toda la información recibida hasta la fecha, parece que la aprobación de exención del requisito de seguro por parte de la Junta Directiva no tendrá ningún impacto negativo sobre los registradores, otras partes interesadas o el interés público general.

      Esta decisión tendrá un impacto positivo sobre los registradores potenciales y existentes, en particular los de aquellas regiones donde el seguro de CGL es excesivamente caro o imposible de obtener. Es probable que el impacto sea principalmente financiero, aunque también puede alentar solicitudes adicionales para la acreditación de registradores, ambos de países desarrollados como en vías de desarrollo.

      La aprobación de una exención al requisito de seguro por parte de la Junta Directiva impulsará las iniciativas de la ICANN para promover la competencia entre registradores en un entorno mundial, y le dará a la GNSO la oportunidad de considerar si un requisito de seguro de reemplazo sería apropiado.

      ¿Cuáles son los impactos sobre la seguridad y la estabilidad de Internet?

      La aprobación de la resolución no ocasionará impacto alguno en las cuestiones de seguridad, estabilidad o flexibilidad relacionadas con el DNS.

    6. Recomendaciones de política e implementación de la GNSO

      Bruce Tonkin presentó el tema del orden del día. La Junta Directiva recibió un conjunto de recomendaciones a partir del Informe Final de Recomendaciones del Grupo de Trabajo sobre Política e Implementación no-PDP de la GNSO y del Grupo de Trabajo sobre Implementación que propuso enmiendas a los Estatutos que abordan nuevos umbrales de votación de la GNSO resultantes del Proceso de Pautas de la GNSO (GGP) y el Proceso de PDP Expedito de la GNSO (EPDP). Las enmiendas estatutarias propuestas fueron publicadas para la recepción de comentarios públicos, y se recibieron dos comentarios en respuesta. Ahora se solicita a la Junta Directiva adoptar las recomendaciones de la GNSO relativas a política e implementación, mediante la aprobación de las enmiendas estatutarias que se publicaron para la recepción de comentarios públicos. La Junta Directiva también respalda la propuesta de principios de política e implementación de la GNSO y las pautas para orientar al personal, así como el trabajo de la comunidad en materia de política e implementación de la GNSO. Además, la Junta Directiva reconoció el asesoramiento brindado por el ALAC (Comité Asesor At-Large), y se comprometió controlar las actividades de desarrollo de políticas de la GNSO para asegurar que los usuarios y los intereses públicos sean considerados en forma adecuada.

      Bruce presentó la moción, el Presidente de la Junta la secundó y la Junta Directiva tomó la siguiente medida:

      Visto y considerando que, el 17 de julio de 2013, el Consejo de la GNSO aprobó la carta orgánica para un Grupo de Trabajo sobre Política e Implementación no-PDP de la GNSO (http://gnso.icann.org/en/council/resolutions#201307) encargado de proporcionar al Consejo de la GNSO un conjunto de recomendaciones sobre:

      • Un conjunto de principios que pudiesen apuntalar cualquier discusión de la GNSO relativa a política e implementación, teniendo en cuenta los Procedimientos Operativos de la GNSO ya existentes.
      • Un proceso para el desarrollo de políticas de gTLD, tal vez en la forma de "Pautas sobre Políticas", que incluya los criterios para cuando sería apropiado utilizar un procedimiento de este tipo (para el desarrollo de políticas que no sean "políticas de consenso") en lugar de un Proceso de Desarrollo de Políticas de la GNSO;
      • Un marco para las discusiones relativas a la implementación asociadas a las recomendaciones de política de la GNSO.
      • Criterios a utilizarse para determinar cuándo una acción debe ser abordada mediante un proceso de política y cuando se debe considerar de implementación.
      • Mayor orientación sobre cómo se espera que los Equipos para la Revisión de la Implementación de la GNSO, conforme se definen en el Manual de PDP, funcionen y se manejen.

      Visto y considerando que, el 19 de enero de 2015, el Grupo de Trabajo sobre Política e Implementación de la GNSO publicó su Informe Inicial de Recomendaciones para la recepción de comentarios públicos (consultehttps://www.icann.org/public-comments/policy-implementation-2015-01-19-en).

      Visto y considerando que, el Grupo de Trabajo sobre Política e Implementación de la GNSO examinó los aportes recibidos (consulte herramienta de revisión de comentarios públicos) y actualizó el informe en consecuencia, lo cual resultó en un Informe Final de Recomendaciones presentado al Consejo de la GNSO el día 2 de junio de 2015.

      Visto y considerando que, el Informe Final de Recomendaciones (consulte http://gnso.icann.org/en/drafts/policy-implementation-recommendations-01jun15-en.pdf) fue adoptado por unanimidad del Consejo de la GNSO el día 24 de junio de 2015.

      Visto y considerando que, el 28 de julio de 2015, la Junta Directiva de la ICANN instruyó al Personal de la ICANN publicar los cambios propuestos a los Estatutos de la ICANN, como resultado de las recomendaciones propuestas en el Informe Final de Recomendaciones para la recepción de comentarios públicos (consulte https://www.icann.org/public-comments/bylaws-amendments-2015-07-31-en).

      Mientras que se recibieron dos comentarios en apoyo de las recomendaciones propuestas, entre ellas una Declaración de Asesoramiento del ALAC.

      Visto y considerando que, el ATRT2 (Segundo Equipo de Revisión sobre Responsabilidad y Transparencia) recomendó que "la Junta Directiva debería continuar apoyando la participación intercomunitaria orientada a desarrollar un entendimiento de la distinción entre el desarrollo de políticas y la implementación de políticas. Desarrollar mecanismos complementarios mediante los cuales las Organizaciones de Apoyo y Comités Asesores (SO/AC) puedan consultar los asuntos con la Junta Directiva, incluyendo ―pero no limitándose a― cuestiones de políticas, implementación y administración, sobre las cuales la Junta Directiva toma decisiones." (Recomendación n.° 4).

      Resuélvase (2015.09.28.16): la Junta Directiva aprueba las enmiendas a la sección 3-9 del Artículo X de los Estatutos de la ICANN, tal como se publicaron para la recepción de comentarios públicos, con el fin de abordar los nuevos umbrales de votación de la GNSO que resultaron a partir del Proceso de Pautas de la GNSO (GGP) y del Proceso de PDP expedito de la GNSO (EPDP).

      Resuélvase (2105.09.28.17): la Junta Directiva aprueba las enmiendas al Anexo A de los Estatutos de la ICANN, tal como se publicaron para la recepción de comentarios públicos (consulte https://www.icann.org/en/system/files/files/bylaws-proposed-amendments-gnso-policy-implementation-31jul15-en.pdf), con la creación de un nuevo Anexo A-1 que describa el Proceso de PDP expedito de la GNSO (EPDP) de la GNSO.

      Resuélvase (2015.09.28.18): la Junta Directiva aprueba las enmiendas al Anexo A de los Estatutos de la ICANN, tal como se publicaron para la recepción de comentarios públicos (consulte https://www.icann.org/en/system/files/files/bylaws-proposed-amendments-gnso-policy-implementation-31jul15-en.pdf), con la creación de un nuevo Anexo A-2 que describa el Proceso de Pautas de la GNSO (GGP) de la GNSO.

      Resuélvase (2015.09.28.19): la Junta Directiva respalda el conjunto de principios/requisitos de la GNSO en materia de política e implementación, conforme se indica en la sección 4 del Informe Final de Recomendaciones, e instruye al Presidente y Director Ejecutivo, o a quienes éste designe, así como a la comunidad de la ICANN, tomar estos principios y requisitos en cuenta a medida que participa en cuestiones relacionadas con política e implementación de la GNSO.

      Resuélvase (2015.09.28.20): la Junta Directiva respalda las Pautas y Principios del Equipo para la Revisión de la Implementación, conforme se establecen en el Anexo L del Informe Final de Recomendaciones, e instruye al Personal de la ICANN, así como a la comunidad de la ICANN, a tomar estas Pautas y Principios en cuenta a medida que participa en cuestiones relacionadas con la implementación.

      Resuélvase (2015.09.28.21): la Junta Directiva reconoce el Asesoramiento suministrado por el ALAC y se compromete a controlar las actividades de desarrollo de políticas de la GNSO para asegurar que los usuarios y los intereses públicos son considerados de manera adecuada y que la implementación de políticas complejas puedan lograrse en plazos razonables.

      Resuélvase (2015.09.28.22): la Junta Directiva instruye al Presidente y Director Ejecutivo, o a quienes éste designe, publicar los documentos pertinentes sobre política e implementación de la GNSO en las páginas relacionadas de los sitios web de la GNSO y de la ICANN, y buscar e incorporar retroalimentación sobre mejoras y materiales de apoyo adicionales, según corresponda.

      Resuélvase (2015.09.28.23): la Junta Directiva considera que por la presente se completa la Recomendación n.° 4 del ATRT2 e invita al ATRT3 (Tercer Equipo de Revisión sobre Responsabilidad y Transparencia) a examinar estas recomendaciones adoptadas a la luz de los hallazgos y recomendaciones del ATRT2.

      Resuélvase (2015.09.28.24): la Junta Directiva agradece a la comunidad de la GNSO y demás personas involucradas, por su ardua labor en este esfuerzo.

      Catorce miembros de la Junta Directiva presentes votaron a favor de las Resoluciones 2015.09.28.16, 2015.09.28.17, 2015.09.28.18, 2015.09.28.19, 2015.09.28.20, 2015.09.28.21, 2015.09.28.22, 2015.09.28.23 y 2015.09.28.24. Ray Plzak se abstuvo de votar. Erika Mann no se encontraba disponible al momento de la votación de las resoluciones. Las resoluciones fueron aprobadas.

      Fundamentos para las Resoluciones 2015.09.28.16 - 2015.09.28.24

      ¿Por qué la Junta Directiva está abordando ahora la cuestión?

      Principalmente como resultado de las discusiones derivadas de cuestiones relativas a la implementación del Programa de Nuevos gTLD (Dominios Genéricos de Alto Nivel) ha habido una mayor atención sobre los temas que requieren de políticas y labor de implementación, incluso cuáles procesos se deben utilizar, en qué momento y cómo se debe actuar respecto a las cuestiones sujetas a opiniones divergentes durante el proceso de implementación. Tras varios debates, que incluyeron la publicación de un documento de discusión por parte del personal y una sesión de la comunidad realizada dentro del marco de la reunión ICANN46, el Consejo de la GNSO decidió, en julio de 2013, conformar un grupo de trabajo para brindar una serie de recomendaciones sobre:

      • Un conjunto de principios para apuntalar la discusión futura de la GNSO relativa a política e implementación, teniendo en cuenta los Procedimientos Operativos de la GNSO ya existentes.
      • Un proceso para el desarrollo de políticas de gTLD, posiblemente en forma de "Pautas sobre Políticas", que incluya los criterios para cuando sería apropiado utilizar un procedimiento de este tipo (para el desarrollo de políticas que no sean "políticas de consenso") en lugar de un Proceso de Desarrollo de Políticas de la GNSO;
      • Un marco para las discusiones relativas a la implementación asociadas a las recomendaciones de política de la GNSO;
      • Criterios a utilizarse para determinar cuándo una acción debe ser abordada mediante un proceso de política y cuando se debe considerar de implementación, y;
      • Mayor orientación sobre cómo se espera que los Equipos para la Revisión de la Implementación de la GNSO, conforme se definen en el Manual de PDP, funcionen y se manejen.

      El día 24 de junio de 2015, el Consejo de la GNSO adoptó por unanimidad las recomendaciones del Grupo de Trabajo, y posteriormente las presentó a la Junta Directiva de la ICANN para su consideración.

      Además, esta cuestión también fue identificada por el Segundo Equipo de Revisión sobre Responsabilidad y Transparencia (ATRT2) como una prioridad: "la Junta Directiva debería continuar apoyando la participación intercomunitaria orientada a desarrollar un entendimiento de la distinción entre el desarrollo de políticas y la implementación de políticas. Desarrollar mecanismos complementarios mediante los cuales las Organizaciones de Apoyo y Comités Asesores (SO/AC) puedan consultar los asuntos con la Junta Directiva, incluyendo ―pero no limitándose a― cuestiones de políticas, implementación y administración, sobre las cuales la Junta Directiva toma decisiones." (Recomendación n.° 4).

      ¿Cuál es la propuesta que se está considerando?

      La medida que hoy está tomando la Junta Directiva es adoptar las recomendaciones de la GNSO en materia de política e implementación. Las recomendaciones adoptadas incluyen tres procesos propuestos para la GNSO. Dos de estos procesos, el Proceso de Orientación de la GNSO (GGP) y el Proceso Expeditivo de Desarrollo de Políticas de la GNSO (EPDP), requieren la modificación de los estatutos de la ICANN. La medida de la Junta Directiva aprueba los cambios estatutarios necesarios para implementar el Proceso de Pautas de la GNSO y el Proceso de PDP Expedito de la GNSO. Estos dos procesos nuevos están destinados a proporcionar al Consejo de la GNSO una mayor flexibilidad para abordar cuestiones de políticas a través de procesos formales a utilizarse ante el cumplimiento de ciertos criterios específicos. Además, la Junta Directiva está tomando la medida de respaldar la propuesta de principios de política e implementación de la GNSO y las pautas para orientar al personal, así como el trabajo de la comunidad en materia de política e implementación de la GNSO.

      ¿Cuáles son las partes interesadas u otros participantes consultados?

      Tras varias deliberaciones que incluyeron la publicación de un documento para debate del personal (consulte https://gnso.icann.org/en/correspondence/policy-implementation-framework-08jan13-en.pdf y http://forum.icann.org/lists/comments-policy-implementation-31jan13/) y una sesión de la comunidad realizada dentro del marco de la reunión ICANN46 (consulte http://beijing46.icann.org/node/37133) el Consejo de la Organización de Apoyo para Nombres Genéricos (GNSO) decidió, en julio de 2013 y en consulta con otras Organizaciones de Apoyo y Comités Asesores (SO/AC) (consulte http://gnso.icann.org/en/correspondence/robinson-to-so-ac-leadership-23apr13-en.pdf) conformar un Grupo de Trabajo de la GNSO para abordar una serie de cuestiones específicas relativas a política e Implementación de la GNSO. El Grupo de Trabajo de la GNSO solicitó tempranamente el aporte inicial de todas las SO/AC de la ICANN, así como de los Grupos de Partes Interesadas y Unidades Constitutivas (SG/C) (consulte https://community.icann.org/x/iSmfAg). La publicación del Informe Inicial fue acompañada por un foro de comentarios públicos (consulte https://www.icann.org/public-comments/policy-implementation-2015-01-19-en) así como por una sesión de la comunidad realizada dentro del marco de la reunión ICANN52 (consulte https://singapore52.icann.org/en/schedule/wed-policy-implementation). El Grupo de Trabajo examinó y consideró todos los aportes recibidos, conforme lo demostrado en la herramienta de revisión de comentarios públicos (consulte https://community.icann.org/x/iSmfAg). Tras la aprobación unánime del Informe Final de Recomendaciones por parte del Consejo de la GNSO, la Junta Directiva de la ICANN instruye al Personal de la ICANN publicar los cambios estatutarios propuestos para la recepción de comentarios públicos (consulte https://www.icann.org/public-comments/bylaws-amendments-2015-07-31-en). Se recibieron dos comentarios en apoyo a las recomendaciones, entre ellos una Declaración de Asesoramiento del ALAC (consulte http://forum.icann.org/lists/comments-bylaws-amendments-31jul15/).

      ¿Qué inquietudes o cuestiones fueron planteadas por la comunidad?

      El Grupo de Trabajo examinó y consideró todos los aportes recibidos, conforme lo demostrado en la herramienta de revisión de comentarios públicos (consulte https://community.icann.org/x/iSmfAg). En su Declaración de Asesoramiento en respuesta al foro de comentarios públicos lanzado por la Junta Directiva de la ICANN, el ALAC apoyó las recomendaciones, aunque también recomendó que la Junta Directiva de la ICANN controle cuidadosamente las actividades de desarrollo de políticas de la GNSO para asegurar que los usuarios y los intereses públicos son considerados de manera adecuada y que la implementación de políticas complejas puedan lograrse en plazos razonables.

      ¿Qué materiales significativos analizó la Junta Directiva?

      La Junta Directiva examinó el Informe Final de Recomendaciones sobre Política e Implementación de la GNSO (consulte http://gnso.icann.org/en/drafts/policy-implementation-recommendations-01jun15-en.pdf) y materiales relacionados.

      ¿Qué factores consideró importantes la Junta Directiva? ¿Existen impactos positivos o negativos para la comunidad?

      La Junta Directiva considera de gran importancia que estas recomendaciones fueron desarrolladas por la comunidad, en consulta con el personal de la ICANN, y que las mismas recibieron el apoyo unánime del Consejo de la GNSO. Por otra parte, la Junta Directiva reconoce la importancia de abordar esta cuestión, como también lo ha señalado el ATRT2, y opina que estas recomendaciones proporcionarán al Consejo de la GNSO una mayor flexibilidad para abordar cuestiones de política a través de procesos formales, así como la claridad y previsibilidad necesarias con respecto a las cuestiones relativas a política e implementación de la GNSO.

      ¿Se observan impactos fiscales o ramificaciones en la ICANN (plan estratégico, plan operativo, presupuesto), la comunidad y/o el público?

      No se esperan impactos fiscales o ramificaciones como resultado de la implementación de estas recomendaciones.

      ¿Se observan cuestiones sobre seguridad, estabilidad o flexibilidad relacionadas con el DNS?

      No se ha identificado ninguna cuestión de seguridad, estabilidad o flexibilidad del DNS en relación a estas recomendaciones.

    7. Designación del Presidente y Presidente Electo del Comité de Nominaciones para 2016 - SESIÓN EJECUTIVA

      La Junta Directiva celebró una sesión confidencial. Durante su sesión confidencial, la Junta Directiva tomó las siguientes medidas:

      Visto y considerando que, el BCG (Comité de Gobernanza de la Junta Directiva) analizó las Expresiones de Interés de los candidatos para presidente y presidente electo del Comité de Nominaciones 2016 ("NomCom"), consideró los resultados de la evaluación de 360 grados del liderazgo del NomCom 2015 y entrevistó a los candidatos.

      Visto y considerando que el BGC recomendó la designación de Stéphane Van Gelder como Presidente del NomCom para el año 2016, y la designación de Hans Petter Holen como Presidente Electo del NomCom para el año 2016.

      Resuélvase (2015.09.28.25): por la presente, la Junta Directiva designa a Stéphane Van Gelder como Presidente y a Hans Petter Holen como Presidente Electo del Comité de Nominaciones de 2016.

      Fundamentos de la Resolución 2015.09.28.25

      De acuerdo con los Estatutos de la ICANN, la Junta Directiva debe designar al presidente y al presidente electo del NomCom. Véanse las secciones 2.1 y 2.2 del Artículo VII en http://www.icann.org/en/general/bylaws.htm - VII. La Junta Directiva ha delegado en el BGC la responsabilidad de recomendar al presidente y al presidente electo del Comité de Nominaciones para la aprobación de la Junta Directiva. Véase la carta orgánica del BGC en http://www.icann.org/en/committees/board-governance/charter.htm. El día 4 de junio de 2015, el BGC publicó una convocatoria de Manifestaciones de Interés (EOI) a ser presentadas antes del 30 de junio de 2015 (consulte https://www.icann.org/news/announcement-2-2015-06-04-en). La convocatoria para EOI fue luego extendida hasta el día 20 de julio de 2015 (consulte https://www.icann.org/news/announcement-2015-07-01-en). Antes de hacer sus recomendaciones, el BGC recibió y examinó varias EOI, supervisó una evaluación de 360 grados del liderazgo del NomCom 2015 y entrevistó a los candidatos. La Junta Directiva ha sometido a consideración la recomendación del BGC respecto del presidente y presidente electo para el NomCom 2016 y está de acuerdo con ella. Asimismo, la Junta Directiva desea agradecer a todos quienes manifestaron su interés en formar parte del liderazgo de NomCom 2016.

      La designación del Presidente y el Presidente Electo del NomCom identificados a través de un proceso público de EOI (Manifestación de Interés) tiene un impacto positivo en la transparencia y la responsabilidad de la ICANN y avala el interés público. La adopción de la recomendación del BGC no tiene un impacto económico en la ICANN diferente del previsto y no observará un impacto negativo en la seguridad, estabilidad o flexibilidad del sistema de nombres de dominio.

    8. Después de esto, el Presidente declaró el cierre de la reunión.


1 Para una definición de los niveles de consenso consulte http://gnso.icann.org/en/council/annex-1-gnso-wg-guidelines-07apr11-en.pdf (p.8).

2 Consulte también el punto 5.1.1 y la Herramienta de Revisión de Comentarios Públicos (Anexo B [del Informe Final]).

3 Muchos asumen que eso sería código US-ASCII en inglés, aunque los argumentos de otros scripts (códigos de escritura) pueden ser convincentes.

4 Consulte https://www.icann.org/news/announcement-3-2014-09-22-en

minutes-28sep15-es.pdf  [281 KB]

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."