Logo
ICANN
ICANN
Filtered Search

Are you sure you want to sign out from http://www.icann.org?

If you want to sign out from both http://www.icann.org and ICANN Account, click here.

Actividades y reuniones de la Junta Directiva

Consulte las acciones y decisiones de la Junta Directiva de la ICANN en los registros de sus actividades y reuniones recientes.

Resoluciones Aprobadas por la Junta Directiva | Reunión Ordinaria de la Junta Directiva de la ICANN 28 de septiembre de 2015

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/resolutions-2015-09-28-en

  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 Traducción y Transliteración de Información de Contacto
    3. Renovación del Acuerdo de Registro .CAT
    4. Renovación del Acuerdo de Registro .TRAVEL
    5. Renovación del Acuerdo de Registro .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 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: Camino hacia las Rondas Futuras
    5. Requisitos de Seguro para el Acuerdo de Acreditación de Registradores
    6. Recomendaciones sobre Políticas 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:

    1. Aprobación de las Actas de las Reuniones de la Junta Directiva

      Resuélvase (2015.09.28.01): la Junta Directiva aprueba las actas de los días 16 y 28 de julio de 2015 de las reuniones de la Junta Directiva de la ICANN.

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

      Visto y considerando que el 13 de junio de 2013, el Consejo de la GNSO lanzó un Proceso de Desarrollo de Políticas (PDP) sobre la Traducción y Transliteración, abordando dos preguntas de la carta orgánica establecidas en http://gnso.icann.org/en/issues/gtlds/transliteration-contact-charter-20nov13-en.pdf [PDF, 185 KB].

      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 Traducción y Transliteración de Información de Contacto obtuvo el consenso sobre su primera recomendación y el consenso total sobre sus seis recomendaciones restantes1

      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, mayoría calificada) 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 (véase 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 sobre Políticas del Consejo de la GNSO sobre la traducción y transliteración de información de contacto tal como se presenta en el Informe Final.

      Resuélvase (2015.09.28.03), se instruye al Director Ejecutivo, o quien este 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.

      Fundamento 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 conocen) el ASCII de Estados Unidos, el término técnico para los códigos de escritura basados en el alfabeto latino utilizados en Inglés y otros idiomas de Europa occidental.

      La precisión y la coherencia de los datos de información de contacto son cruciales para que sea una fuente útil para los que busquen información sobre registratarios de nombres de dominio. Este WG sobre PDP ha considerado la importante cuestión de si los datos o datos traducidos y/o transliterados o los datos presentados en el código de escritura más conocido para el registratario es más probable que entregue 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 exhaustiva.

      El Informe Final del PDP sobre Traducción y Transliteración recibió el apoyo del consenso sobre su primera recomendación y el consenso total en las otras seis 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 solicitan la transformación es libre de hacerlo de manera ad hoc fuera del WHOIS o de cualquier sistema de reemplazo, 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 del 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 garantiza 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 se valida, 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 del WHOIS, por ejemplo, RDAP, permanezca flexible de manera que la información de contacto en nuevos scripts/idiomas pueda agregarse y expandir su capacidad lingüística/de script 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 del WHOIS donde sea necesario y se implementen o apliquen tan pronto como un sistema de reemplazo del WHOIS que pueda recibir, almacenar y mostrar caracteres que no son ASCII, se ponga en funcionamiento.

      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 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 1 fue acompañada por una Declaración Minoritaria, con el texto del siguiente tenor: 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 que hay situaciones en las que la información de contacto en el idioma local del registratario es la versión principal, como para identificar al registratario en la preparación para una acción judicial local, hay diversas situaciones en las que una búsqueda global del WHOIS, proporcionando acceso a los datos de la manera más uniforme posible, es necesario que el servicio de registración de datos alcance sus objetivos de proporcionar transparencia y responsabilidad en el DNS. Véase también 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?

      La consulta habitual con las partes interesadas se llevó a cabo durante la vigencia de este PDP, específicamente durante tres reuniones de la ICANN (ICANN 49, 50 y 51), al igual que los períodos de comentario público para el Informe de Cuestiones Preliminar, el Informe inicial y previo a la consideración de la Junta Directiva.

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

      La principal preocupación que planteó la Comunidad era que una base de datos con múltiples códigos de escritura/múltiples idiomas generaría una menor transparencia porque 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 los registratarios fraudulentos podían ocultar su identidad detrás de diferentes códigos de escritura/idiomas.

      ¿Qué materiales significativos analizó la Junta Directiva?

      La Junta directiva revisó 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 mayoría calificada 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 por el voto de más de dos tercios, la Junta Directiva determine que tal política no responde a los mejores intereses de la ICANN o de su comunidad. Además, continuar con la internacionalización del sistema de nombres de dominio es un área importante de trabajo para la ICANN. Las recomendaciones tienen el potencial de mejorar la facilidad de uso y la precisión de los datos de información de contacto en todo un DNS verdaderamente globalizado.

      ¿Existen impactos positivos o negativos para la comunidad?

      Algunos de los impactos positivos identificados en el Informe Final incluyen (entre otros):

      • Los registratarios que no estén familiarizados con el US-ASCII podrán registrar nombres de dominio utilizando el código de escritura con el que estén más familiarizados.
      • Los registradores no están obligados a traducir o transcribir los datos, pero tienen que validar los datos, independientemente del código de escritura que apoyen... la decisión sobre cuáles son los que se regirán por la oferta y la demanda.
      • Los costos de registración no van a aumentar porque requerir que los registradores traduzcan o transliteren todos los datos de información de contacto en un código de escritura3 generará inevitablemente costos que se podrían trasladar a los registratarios;
      • Permitir que los registratarios utilicen el idioma/código de escritura con el que estén más familiarizados cuando registren dominios tendrá un impacto positivo sobre la precisión de los datos.

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

      • Aquellos que procuren buscar datos de información de contacto y operen en US-ASCII podrían tener que traducir o transcribir los datos para poder contactar a los registratarios (aunque eso se aplica para aquellos que procuren información, pero no estén familiarizados con US-ASCII, incluso si la traducción o transliteración eran obligatorias).

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

      No existen impactos fiscales 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 la información de contacto. Sin embargo, estos costos se encuentran en marcado contraste con los costos potenciales que se generarían si en virtud de un requisito exhaustivo cada contacto que se proporcione en un código de escritura que no sea US-ASCII tuviera que traducirse o transliterarse.

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

      El protocolo de WHOIS actual no está diseñado para códigos de escritura que no sean US-ASCII. Sin embargo, el Protocolo de Acceso a los Datos de Registración de Nombres de Dominio (RDAP) se está implementando actualmente como el reemplazo de WHOIS y [el RDAP] es totalmente compatible con diferentes códigos de escritura. Una vez que el RDAP esté implementado, o cualquier otro reemplazo que sea capaz de hacer frente a los códigos de escritura distintos de 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 .CAT

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

      Visto y considerando que la renovación propuesta del Acuerdo de Registro de .CAT incluye disposiciones modificadas para lograr que el Acuerdo de Registro de .CAT esté en consonancia con el formato del Acuerdo de Registro de Nuevos gTLD.

      Visto y considerando que el foro de comentarios públicos sobre la renovación propuesta del Acuerdo de Registro que cerró el 7 de julio de 2015, con la ICANN que recibió quince (15) comentarios de personas y organizaciones/grupos. La Junta Directiva proporcionó un resumen y análisis de los comentarios.

      Visto y considerando que la renovación del acuerdo de registro se ha actualizado para incluir disposiciones ya existentes concernientes a Whois.

      Resuélvase (2015.09.28.04), la renovación propuesta del Acuerdo de Registro de .CAT [PDF, 621 KB] se aprueba, y el Presidente y Director Ejecutivo, o a quien éste designe, está autorizado a tomar dichas medidas según corresponda para finalizar y ejecutar el 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") celebraron un Acuerdo de Registro el 23 de septiembre de 2005 para la operación del dominio de alto nivel .CAT. El Acuerdo de Registro actual de .CAT vence el 19 de diciembre de 2015. La renovación propuesta del Acuerdo de Registro (la "Renovación del Acuerdo de Registro" o "Acuerdo") fue publicada para el comentario público entre el 28 de mayo de 2015 y el 7 de julio de 2015. En este momento, la Junta está aprobando la Renovación del Acuerdo de Registro para la operación continua del TLD .CAT por parte del Operador de Registro.

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

      La Renovación del Acuerdo de Registro aprobado por el Consejo incluye disposiciones modificado para hacer que el Acuerdo en consonancia con la forma del Nuevo Acuerdo de Registro de gTLD. Las modificaciones incluyen: actualizar las especificaciones técnicas; requerir la inclusión de ciertas garantías GAC como compromisos de interés público (que son objeto de ejecución por el Interés Público Compromiso de Controversias Procedimiento de resolución); requerir el uso de registradores en virtud del Acuerdo de Acreditación de Registradores 2013 después de que se alcance un determinado umbral; y actualizar las tarifas de registro.

      Para explicar la naturaleza específica del TLD .CAT, un TLD Patrocinado, disposiciones relevantes en el Acuerdo de Registro de TLD Patrocinado del 23 de septiembre de 2005 se han incluido en la Renovación del Acuerdo de Registro. En concreto, las disposiciones de la Carta Orgánica que delinean la Comunidad Lingüística y Cultural Catalana en Internet que se encuentran dentro del significado de la comunidad y que son elegibles para el registro se identifican en la Especificación 12. La Renovación del Acuerdo de Registro también refleja aprobaciones anteriores relativas a nombres reservados.

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

      La ICANN llevó a cabo un período de comentario público sobre la Renovación del Acuerdo de Registro .CAT propuesta del 28 de mayo de 2015 hasta el 7 de julio de 2015, tras el cual se resumieron y analizaron los comentarios. Además, la ICANN ha participado en negociaciones bilaterales con el Operador de Registro para aceptar el paquete de términos que se incluirán en la Renovación del Acuerdo de Registro publicada para comentario público.

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

      Quince (15) miembros de la comunidad participaron en el período de comentario público. Los miembros de la comunidad plantearon tres inquietudes clave en sus comentarios:

      • La transición de los TLD legados al formato del Acuerdo de Registro de Nuevos gTLD: Algunos comentarios públicos expresaron 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 legados. Estos comentaristas sugieren que la adopción de una posición de este tipo tiene el efecto de transformar los Procedimientos para la Resolución de Disputas con Posterioridad a la Delegación de Nuevos gTLD (por ejemplo, el Procedimiento para la Resolución de Disputas por Marcas Comerciales con Posterioridad a la Delegación y el Procedimiento para la Resolución de Disputas en Materia de Compromisos de Interés Público) y el 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 la búsqueda de coherencia de la ICANN entre los acuerdos de registro y señalaron que la transición hacia el nuevo formato de acuerdo es parte de las negociaciones bilaterales permisibles.
      • Inclusión del Sistema Uniforme de Suspensión Rápida (URS) y el Procedimiento para la Resolución de Disputas por Marcas Comerciales (PDDRP) en las renovaciones de TLD legados sin seguir el Proceso de Desarrollo de Políticas (PDP): la mayoría de los comentarios recibidos expresaban la objeción a la inclusión del URS a la renovación propuesta del Acuerdo de Registro .CAT, alegando que el URS se puede convertir en una política de consenso únicamente después de un proceso de desarrollo de políticas (PDP) completo en el cual participe toda la comunidad de partes interesadas de la ICANN. Estos comentaristas también sugirieron que la imposición del URS en un gTLD legado a través del proceso de contratación es una intervención del personal inaceptable en el proceso de desarrollo 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, que establece que los registros son libres de ir más allá de las protecciones de los derechos mínimos y no requieren 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 ha considerado significativos?

      La Junta Directiva examinó cuidadosamente los comentarios públicos recibidos para la Renovación del Acuerdo de Registro, junto con el resumen y el análisis de dichos 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 Directiva señala que la inclusión del URS en el Renovación del Acuerdo de Registro se basa en las negociaciones bilaterales entre la ICANN y el Operador de Registro, donde el Operador de Registro expresó su interés de 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 el Equipo de Recomendaciones para la Implementación (IRT) como un mecanismo de protección de derechos (RPM) obligatorio para todos los nuevos gTLD. Se le solicitó a la GNSO que exprese su opinión sobre si ciertos mecanismos de protección de derechos propuestos (que incluían el URS) eran consistentes con la política propuesta de la GNSO sobre la introducción de Nuevos gTLD y si era la opción adecuada y eficaz para lograr los principios y objetivos declarados de la GNSO. Las STI consideraron este asunto y concluyeron que "El uso del URS debería ser un RPM requerido para todos los Nuevos gTLD". Es decir, la GNSO señaló que el URS no era incompatible con ninguna de sus recomendaciones de políticas existentes.

      Aunque el URS se desarrolló y perfeccionó a través del proceso descrito aquí, incluido el debate y la revisión pública en la GNSO, no ha sido adoptado como una política de consenso y la ICANN no tiene capacidad para hacerlo obligatorio para ningún TLD que no sean los solicitantes de nuevos gTLD que presentaron la solicitud 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 es un movimiento para hacer que el URS sea obligatorio para cualquier TLD legado, y sería inapropiado hacerlo. En el caso de .CAT, la inclusión del URS se desarrolló como parte de la propuesta en las negociaciones bilaterales entre el Operador de Registro y la ICANN.

      Además, la Junta Directiva consideró los comentarios respecto a la transición de los gTLD legados al nuevo formato del acuerdo de registro. La Junta Directiva observa que el acuerdo de registro existente exige la renovación de presunción del acuerdo a su vencimiento, siempre que se cumplan ciertos requisitos. El acuerdo de renovación está sujeto a la negociación de los términos de renovación razonablemente aceptables para la ICANN y el Operador de Registro. Los términos de renovación aprobados por la Junta Directiva son el resultado de las negociaciones bilaterales previstas en el acuerdo de registro actual y la transición al nuevo formato del acuerdo de registro no violaría la política establecida de la GNSO. Como se describe a continuación, el nuevo formato del acuerdo de registro ofrece algunas ventajas operativas, además de los beneficios a los registratarios y a la comunidad de Internet incluidos los compromisos de interés público, que requieren el uso de registradores en virtud del RAA de 2013, y la capacidad de la ICANN para designar un operador de registro provisional de emergencia en caso de que se alcancen los umbrales de emergencia para los servicios de registros críticos.

      ¿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 en virtud del Acuerdo de Registro de .CAT actual. Se encontró que el Operador de Registro había cumplido sustancialmente sus requisitos contractuales.

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

      También habrá efectos positivos en los registradores y registratarios. La transición al Acuerdo de Registro de nuevos gTLD aportará coherencia en todos los registros y generará un entorno más predecible para los usuarios finales y también el hecho de que la Renovación del Acuerdo de Registro propuesta requiere que el Operador de Registro utilice registradores acreditados por la ICANN que sean parte en 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 los derechos: El acuerdo de nuevos gTLD permitirá que el Operador de Registro adopte mecanismos adicionales de protección de los derechos para proteger 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 prevé un impacto fiscal significativo si la ICANN aprueba la renovación propuesta del Acuerdo de Registro .CAT. Cabe señalar sin embargo, que como consecuencia de la aprobación de la Renovación del Acuerdo de Registro, las tarifas de registro anuales proyectadas disminuyen de USD 112.000 a USD 56.000. El impacto fiscal nominal se compensa con los beneficios adicionales para los registratarios y para la comunidad de Internet incluidos los compromisos de interés público, que requieren el uso de registradores en virtud del RAA de 2013, y la capacidad de la ICANN para designar un operador de registro provisional de emergencia en caso de que se alcancen los umbrales de emergencia para los servicios de registros críticos.

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

      No se prevén problemas de seguridad, estabilidad o flexibilidad relacionados con el DNS si la ICANN aprueba la renovación propuesta del Acuerdo de Registro de .CAT. La renovación propuesta del Acuerdo de Registro, de hecho, incluye términos destinados a permitir una acción más rápida en el caso de ciertas amenazas a la seguridad o estabilidad del DNS. Como parte de sus funciones administrativas y organizativas, la ICANN publicó la versión preliminar de la renovación del Acuerdo de Registro para el comentario público el 28 de mayo de 2015.

    4. Renovación del Acuerdo de Registro .TRAVEL

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

      Visto y considerando que la renovación propuesta del Acuerdo de Registro de .TRAVEL incluye disposiciones modificadas para lograr que el Acuerdo de Registro de .TRAVEL esté en consonancia con el formato del Acuerdo de Registro de Nuevos gTLD.

      Visto y considerando que el foro de comentarios públicos sobre la renovación propuesta del Acuerdo de Registro que cerró el 5 de julio de 2015, con la ICANN que recibió quince (15) comentarios de personas y organizaciones/grupos. La Junta Directiva proporcionó un resumen y análisis de los comentarios.

      Visto y considerando que la Junta Directiva ha determinado que, tras considerar los comentarios, no se necesitan revisiones de la renovación propuesta del Acuerdo de Registro .TRAVEL.

      Resuélvase (2015.09.28.05), la renovación propuesta del Acuerdo de Registro de .TRAVEL [PDF, 621 KB] se aprueba, y el Presidente y Director Ejecutivo, o a quien éste designe, está autorizado a tomar dichas medidas según corresponda para finalizar y ejecutar el Acuerdo.

      Fundamentos de la Resolución 2015.09.28.05

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

      La ICANN y Tralliance Registry Management Company, LLC (el "Operador de Registro") celebraron un Acuerdo de Registro el 5 de mayo de 2005 para la operación del dominio de alto nivel .TRAVEL. El Acuerdo de Registro actual de .TRAVEL vence el 19 de octubre de 2015. La renovación propuesta del Acuerdo de Registro (la "Renovación del Acuerdo de Registro" o "Acuerdo") fue publicada para el comentario público entre el 12 de mayo de 2015 y el 5 de julio de 2015. En este momento, la Junta está aprobando la Renovación del Acuerdo de Registro para la operación continua del TLD .TRAVEL por parte del Operador de Registro.

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

      La Renovación del Acuerdo de Registro aprobado por el Consejo incluye disposiciones modificado para hacer que el Acuerdo en consonancia con la forma del Nuevo Acuerdo de Registro de gTLD. Las modificaciones incluyen: actualizar las especificaciones técnicas; requerir la inclusión de ciertas garantías GAC como compromisos de interés público (que son objeto de ejecución por el Interés Público Compromiso de Controversias Procedimiento de resolución); requerir el uso de registradores en virtud del Acuerdo de Acreditación de Registradores 2013 después de que se alcance un determinado umbral; y actualizar las tarifas de registro.

      Para explicar la naturaleza específica del TLD .TRAVEL, un TLD Patrocinado, disposiciones relevantes en el Acuerdo de Registro de TLD Patrocinado del 5 de mayo de 2005 se han incluido en la Renovación del Acuerdo de Registro. En concreto, las disposiciones de la Carta Orgánica que delinean los sectores de la industria de los viajes que se encuentran dentro del significado de la comunidad y que son elegibles para el registro se identifican en la Especificación 12. La Renovación del Acuerdo de Registro también refleja aprobaciones anteriores relativas a nombres reservados.

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

      La ICANN llevó a cabo un período de comentario público sobre la Renovación del Acuerdo de Registro .TRAVEL propuesta del 12 de mayo de 2015 al 5 de julio de 2015, tras el cual se resumieron y analizaron los comentarios. Además, la ICANN ha participado en negociaciones bilaterales con el Operador de Registro para aceptar el paquete de términos que se incluirán en la Renovación del Acuerdo de Registro publicada para comentario público.

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

      Quince (15) miembros de la comunidad participaron en el período de comentario público. Los miembros de la comunidad plantearon dos inquietudes clave en sus comentarios:

      • La transición de los TLD legados al formato del Acuerdo de Registro de Nuevos gTLD: Algunos comentarios públicos expresaron 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 legados. Estos comentaristas sugieren que la adopción de una posición de este tipo tiene el efecto de transformar los Procedimientos para la Resolución de Disputas con Posterioridad a la Delegación de Nuevos gTLD (por ejemplo, el Procedimiento para la Resolución de Disputas por Marcas Comerciales con Posterioridad a la Delegación y el Procedimiento para la Resolución de Disputas en Materia de Compromisos de Interés Público) y el 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 la búsqueda de coherencia de la ICANN entre los acuerdos de registro y señalaron que la transición hacia el nuevo formato de acuerdo es parte de las negociaciones bilaterales permisibles.
      • Inclusión del Sistema Uniforme de Suspensión Rápida (URS) y el Procedimiento para la Resolución de Disputas por Marcas Comerciales (PDDRP) en las renovaciones de TLD legados sin seguir el Proceso de Desarrollo de Políticas (PDP): la mayoría de los comentarios recibidos expresaban la objeción a la inclusión del URS a la renovación propuesta del Acuerdo de Registro .TRAVEL, alegando que el URS se puede convertir en una política de consenso únicamente después de un proceso de desarrollo de políticas (PDP) completo en el cual participe toda la comunidad de partes interesadas de la ICANN.Estos comentaristas también sugirieron que la imposición del URS en un gTLD legado a través del proceso de contratación es una intervención del personal inaceptable en el proceso de desarrollo 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, que establece que los registros son libres de ir más allá de las protecciones de los derechos mínimos y no requieren 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 ha considerado significativos?

      La Junta Directiva examinó cuidadosamente los comentarios públicos recibidos para la Renovación del Acuerdo de Registro, junto con el resumen y el análisis de dichos 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 Directiva señala que la inclusión del URS en el Renovación del Acuerdo de Registro se basa en las negociaciones bilaterales entre la ICANN y el Operador de Registro, donde el Operador de Registro expresó su interés de 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 el Equipo de Recomendaciones para la Implementación (IRT) como un mecanismo de protección de derechos (RPM) obligatorio para todos los nuevos gTLD. Se le solicitó a la GNSO que exprese su opinión sobre si ciertos mecanismos de protección de derechos propuestos (que incluían el URS) eran consistentes con la política propuesta de la GNSO sobre la introducción de Nuevos gTLD y si era la opción adecuada y eficaz para lograr los principios y objetivos declarados de la GNSO. Las STI consideraron este asunto y concluyeron que "El uso del URS debería ser un RPM requerido para todos los Nuevos gTLD". Es decir, la GNSO señaló que el URS no era incompatible con ninguna de sus recomendaciones de políticas existentes.

      Aunque el URS se desarrolló y perfeccionó a través del proceso descrito aquí, incluido el debate y la revisión pública en la GNSO, no ha sido adoptado como una política de consenso y la ICANN no tiene capacidad para hacerlo obligatorio para ningún TLD que no sean los solicitantes de nuevos gTLD que presentaron la solicitud 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 es un movimiento para hacer que el URS sea obligatorio para cualquier TLD legado, y sería inapropiado hacerlo. En el caso de .TRAVEL, la inclusión del URS se desarrolló como parte de la propuesta en las negociaciones bilaterales entre el Operador de Registro y la ICANN.

      Además, la Junta Directiva consideró los comentarios respecto a la transición de los gTLD legados al nuevo formato del acuerdo de registro. La Junta Directiva observa que el acuerdo de registro existente exige la renovación de presunción del acuerdo a su vencimiento, siempre que se cumplan ciertos requisitos. El acuerdo de renovación está sujeto a la negociación de los términos de renovación razonablemente aceptables para la ICANN y el Operador de Registro. Los términos de renovación aprobados por la Junta Directiva son el resultado de las negociaciones bilaterales previstas en el acuerdo de registro actual y la transición al nuevo formato del acuerdo de registro no violaría la política establecida de la GNSO. Como se describe a continuación, el nuevo formato del acuerdo de registro ofrece algunas ventajas operativas, además de los beneficios a los registratarios y a la comunidad de Internet incluidos los compromisos de interés público, que requieren el uso de registradores en virtud del RAA de 2013, y la capacidad de la ICANN para designar un operador de registro provisional de emergencia en caso de que se alcancen los umbrales de emergencia para los servicios de registros críticos.

      ¿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 en virtud del Acuerdo de Registro de .TRAVEL actual. Se encontró que el Operador de Registro había cumplido sustancialmente sus requisitos contractuales.

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

      También habrá efectos positivos en los registradores y registratarios. La transición al Acuerdo de Registro de nuevos gTLD aportará coherencia en todos los registros y generará un entorno más predecible para los usuarios finales y también el hecho de que la Renovación del Acuerdo de Registro propuesta requiere que el Operador de Registro utilice registradores acreditados por la ICANN que sean parte en 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 los derechos: El acuerdo de nuevos gTLD permitirá que el Operador de Registro adopte mecanismos adicionales de protección de los derechos para proteger 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 prevé un impacto fiscal significativo si la ICANN aprueba la renovación propuesta del Acuerdo de Registro .TRAVEL. Cabe señalar sin embargo, que como consecuencia de la aprobación de la Renovación del Acuerdo de Registro, las tarifas de registro anuales proyectadas disminuyen de USD 46.000 a USD 25.000. El impacto fiscal nominal se compensa con los beneficios adicionales para los registratarios y para la comunidad de Internet incluidos los compromisos de interés público, que requieren el uso de registradores en virtud del RAA de 2013, y la capacidad de la ICANN para designar un operador de registro provisional de emergencia en caso de que se alcancen los umbrales de emergencia para los servicios de registros críticos.

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

      No se prevén problemas de seguridad, estabilidad o flexibilidad relacionados con el DNS si la ICANN aprueba la renovación propuesta del Acuerdo de Registro de .TRAVEL. La renovación propuesta del Acuerdo de Registro, de hecho, incluye términos destinados a permitir una acción más rápida en el caso de ciertas amenazas a la seguridad o estabilidad del DNS. Como parte de sus funciones administrativas y organizativas, la ICANN publicó la versión preliminar de la renovación del Acuerdo de Registro para el comentario público el 12 de mayo de 2015.

    5. Renovación del Acuerdo de Registro .PRO

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

      Visto y considerando que la renovación propuesta del Acuerdo de Registro de .PRO incluye disposiciones modificadas para lograr que el Acuerdo de Registro de .PRO esté en consonancia con el formato del Acuerdo de Registro de Nuevos gTLD.

      Visto y considerando que el foro de comentarios públicos sobre la renovación propuesta del Acuerdo de Registro que cerró el 7 de julio de 2015, con la ICANN que recibió catorce (14) comentarios de personas y organizaciones/grupos. La Junta Directiva proporcionó un resumen y análisis de los comentarios.

      Visto y considerando que la renovación del acuerdo de registro se ha actualizado para incluir disposiciones ya existentes concernientes a registros de dominio de tercer nivel.

      Resuélvase (2015.09.28.06), la renovación propuesta del Acuerdo de Registro de .PRO [PDF, 586 KB] se aprueba, y el Presidente y Director Ejecutivo, o a quien éste designe, está autorizado a tomar dichas medidas según corresponda para finalizar y ejecutar el Acuerdo.

      Fundamentos de la Resolución 2015.09.28.06

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

      La ICANN y Registry Services Corporation (el "Operador de Registro") celebraron un Acuerdo de Registro el 22 de abril de 2010 para la operación del dominio de alto nivel .PRO. El Acuerdo de Registro actual de .PRO vence el 20 de octubre de 2015. La renovación propuesta del Acuerdo de Registro (la "Renovación del Acuerdo de Registro" o "Acuerdo") fue publicada para el comentario público entre el 28 de mayo de 2015 y el 7 de julio de 2015. En este momento, la Junta está aprobando la Renovación del Acuerdo de Registro para la operación continua del TLD .PRO por parte del Operador de Registro.

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

      La Renovación del Acuerdo de Registro aprobado por el Consejo incluye disposiciones modificado para hacer que el Acuerdo en consonancia con la forma del Nuevo Acuerdo de Registro de gTLD. Las modificaciones incluyen: actualizar las especificaciones técnicas; requerir la inclusión de ciertas garantías GAC como compromisos de interés público (que son objeto de ejecución por el Interés Público Compromiso de Controversias Procedimiento de resolución); requerir el uso de registradores en virtud del Acuerdo de Acreditación de Registradores 2013 después de que se alcance un determinado umbral; y eliminar el tope máximo de precio en las tarifas que el registro puede cobrar a los registratarios.

      En concreto, se propone que las Restricciones de Registro existentes en el Apéndice 11 del Acuerdo de .PRO sean sustituidas por el conjunto de compromisos de interés público estándar aplicables a todos los nuevos gTLD. Sin embargo, la renovación propuesta del acuerdo de registro ha sido actualizada para incluir disposiciones relativas al registro de nombres de dominio de tercer nivel. Además, las Medidas de protección 1 a la 3 de Categoría 1 del GAC se agregan a la Especificación 11. La Renovación del Acuerdo de Registro también elimina el límite en las tarifas de servicios que el registro sea capaz de registrar para nombres de dominio, y refleja las aprobaciones anteriores relativas a nombres reservados.

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

      La ICANN llevó a cabo un período de comentario público sobre la Renovación del Acuerdo de Registro .PRO propuesta del 28 de mayo de 2015 hasta el 7 de julio de 2015, tras el cual se resumieron y analizaron los comentarios. Además, la ICANN ha participado en negociaciones bilaterales con el Operador de Registro para aceptar el paquete de términos que se incluirán en la Renovación del Acuerdo de Registro publicada para comentario público.

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

      Catorce (14) miembros de la comunidad participaron en el período de comentario público. Los miembros de la comunidad plantearon dos inquietudes clave en sus comentarios:

      • La transición de los TLD legados al formato del Acuerdo de Registro de Nuevos gTLD: Algunos comentarios públicos expresaron 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 legados. Estos comentaristas sugieren que la adopción de una posición de este tipo tiene el efecto de transformar los Procedimientos para la Resolución de Disputas con Posterioridad a la Delegación de Nuevos gTLD (por ejemplo, el Procedimiento para la Resolución de Disputas por Marcas Comerciales con Posterioridad a la Delegación y el Procedimiento para la Resolución de Disputas en Materia de Compromisos de Interés Público) y el 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 la búsqueda de coherencia de la ICANN entre los acuerdos de registro y señalaron que la transición hacia el nuevo formato de acuerdo es parte de las negociaciones bilaterales permisibles.
      • Inclusión del Sistema Uniforme de Suspensión Rápida (URS) y el Procedimiento para la Resolución de Disputas por Marcas Comerciales (PDDRP) en las renovaciones de TLD legados sin seguir el Proceso de Desarrollo de Políticas (PDP): la mayoría de los comentarios recibidos expresaban la objeción a la inclusión del URS a la renovación propuesta del Acuerdo de Registro .PRO, alegando que el URS se puede convertir en una política de consenso únicamente después de un proceso de desarrollo de políticas (PDP) completo en el cual participe toda la comunidad de partes interesadas de la ICANN. Estos comentaristas también sugirieron que la imposición del URS en un gTLD legado a través del proceso de contratación es una intervención del personal inaceptable en el proceso de desarrollo 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, que establece que los registros son libres de ir más allá de las protecciones de los derechos mínimos y no requieren 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 ha considerado significativos?

      La Junta Directiva examinó cuidadosamente los comentarios públicos recibidos para la Renovación del Acuerdo de Registro, junto con el resumen y el análisis de dichos 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 Directiva señala que la inclusión del URS en el Renovación del Acuerdo de Registro se basa en las negociaciones bilaterales entre la ICANN y el Operador de Registro, donde el Operador de Registro expresó su interés de 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 el Equipo de Recomendaciones para la Implementación (IRT) como un mecanismo de protección de derechos (RPM) obligatorio para todos los nuevos gTLD. Se le solicitó a la GNSO que exprese su opinión sobre si ciertos mecanismos de protección de derechos propuestos (que incluían el URS) eran consistentes con la política propuesta de la GNSO sobre la introducción de Nuevos gTLD y si era la opción adecuada y eficaz para lograr los principios y objetivos declarados de la GNSO. Las STI consideraron este asunto y concluyeron que "El uso del URS debería ser un RPM requerido para todos los Nuevos gTLD". Es decir, la GNSO señaló que el URS no era incompatible con ninguna de sus recomendaciones de políticas existentes.

      Aunque el URS se desarrolló y perfeccionó a través del proceso descrito aquí, incluido el debate y la revisión pública en la GNSO, no ha sido adoptado como una política de consenso y la ICANN no tiene capacidad para hacerlo obligatorio para ningún TLD que no sean los solicitantes de nuevos gTLD que presentaron la solicitud 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 es un movimiento para hacer que el URS sea obligatorio para cualquier TLD legado, y sería inapropiado hacerlo. En el caso de .PRO, la inclusión del URS se desarrolló como parte de la propuesta en las negociaciones bilaterales entre el Operador de Registro y la ICANN.

      Además, la Junta Directiva consideró los comentarios respecto a la transición de los gTLD legados al nuevo formato del acuerdo de registro. La Junta Directiva observa que el acuerdo de registro existente exige la renovación de presunción del acuerdo a su vencimiento, siempre que se cumplan ciertos requisitos. El acuerdo de renovación está sujeto a la negociación de los términos de renovación razonablemente aceptables para la ICANN y el Operador de Registro. Los términos de renovación aprobados por la Junta Directiva son el resultado de las negociaciones bilaterales previstas en el acuerdo de registro actual y la transición al nuevo formato del acuerdo de registro no violaría la política establecida de la GNSO. Como se describe a continuación, el nuevo formato del acuerdo de registro ofrece algunas ventajas operativas, además de los beneficios a los registratarios y a la comunidad de Internet incluidos los compromisos de interés público, que requieren el uso de registradores en virtud del RAA de 2013, y la capacidad de la ICANN para designar un operador de registro provisional de emergencia en caso de que se alcancen los umbrales de emergencia para los servicios de registros críticos.

      ¿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 en virtud del Acuerdo de Registro de .PRO actual. Se encontró que el Operador de Registro había cumplido sustancialmente sus requisitos contractuales.

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

      También habrá efectos positivos en los registradores y registratarios. La transición al Acuerdo de Registro de nuevos gTLD aportará coherencia en todos los registros y generará un entorno más predecible para los usuarios finales y también el hecho de que la Renovación del Acuerdo de Registro propuesta requiere que el Operador de Registro utilice registradores acreditados por la ICANN que sean parte en 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 los derechos: El acuerdo de nuevos gTLD permitirá que el Operador de Registro adopte mecanismos adicionales de protección de los derechos para proteger 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 prevé un impacto fiscal significativo si la ICANN aprueba la renovación propuesta del Acuerdo de Registro .PRO.

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

      No se prevén problemas de seguridad, estabilidad o flexibilidad relacionados con el DNS si la ICANN aprueba la renovación propuesta del Acuerdo de Registro de .PRO. La renovación propuesta del Acuerdo de Registro, de hecho, incluye términos destinados a permitir una acción más rápida en el caso de ciertas amenazas a la seguridad o estabilidad del DNS. Como parte de sus funciones administrativas y organizativas, la ICANN publicó la versión preliminar de la renovación del Acuerdo de Registro para el comentario público el 28 de mayo de 2015.

  2. Orden del Día Principal:

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

      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 hotel/centro de convenciones anfitrión para la Reunión Pública de la ICANN de junio de 2016 en Ciudad de Panamá, Panamá, hasta un monto máximo de USD 1,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.

      Fundamentos de 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 ICANN 56, 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 23 de marzo de 2015, se publicó una convocatoria para recomendar ciudades donde realizar la reunión de 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 ICANN 56.

      La Junta Directiva revisó la información presentada por el personal para celebrar la reunión en Ciudad de Panamá, Panamá y la determinación que indica 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, para la Reunión Pública de la ICANN de junio de 2016.

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

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

    2. Contratación y Desembolso para Nueva Iniciativa de ERP

      Visto y considerando que la ICANN ha establecido la 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 setiembre de 2015, el Comité de Finanzas de la Junta Directiva revisó 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 Directiva han examinado la solución de ERP propuesta y han proporcionado orientación al personal sobre los riesgos y las medidas de mitigación útiles.

      Visto y considerando que el personal y el Comité de Finanzas de la Junta Directiva han recomendado que la Junta Directiva autorice al Presidente y Director Ejecutivo, o quien é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 del presente documento, y realizar todos los desembolsos necesarios de conformidad con los contratos.

      Resuélvase (2015.09.28.09), la Junta Directiva autoriza al Presidente y Director Ejecutivo, o quien é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 del presente documento y realizar todos los desembolsos necesarios de conformidad con 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.

      Fundamento de las resoluciones 2015.09.28.09 – 2015.09.28.10

      La ICANN ha crecido en tamaño y complejidad en los últimos cinco años en muchos aspectos, a modo de ejemplo: (i) el personal se ha multiplicado por tres; (ii) la presencia global se ha expandido a tres centros nodales y varios centros de participación; y (iii) los procesos se han vuelto más globales y complejos. Por otra parte, la infraestructura de sistemas de gestión operacional de Finanzas, Recursos Humanos y Adquisición independientes que soportan a la organización actual se diseñó e implementó hace cinco años por lo menos. Asegurar e implementar una solución de planificación de recursos empresariales integrada bajo un único sistema de registro mejorará la capacidad de los sistemas, la presentación de informes global, la capacidad de análisis y las eficiencias multidisciplinarias y de productividad, y mejorará los controles internos, acelerando de este modo el avance de la ICANN hacia la excelencia operativa.

      El personal realizó un análisis exhaustivo de las dos opciones disponibles: (i) adaptar los conjuntos existentes de sistemas para mejorar levemente sus capacidades y desarrollar interfaces donde sea posible; y (ii) implementar una solución de ERP integrada. Aunque el costo de la opción de adaptación sería menor en el primer año, el costo total en cinco años superaría ampliamente a la opción de ERP, ya que la adaptación aún requeriría una actualización importante durante los cinco años. Además, la adaptación mejoraría solo un poco las capacidades y eficiencias de gestión operacional y requeriría desarrollar interfaces costosas, complejas y que requerirían mucho mantenimiento con el resultado de un conjunto de capacidades mucho menor al de la solución integrada.

      Por lo tanto, la solución de ERP integrada se considera viable y más rentable.

      El proyecto de la solución de ERP integrada se diseñó de la siguiente manera:

      Recursos internos: El proyecto se evaluó con anticipación pero se demoró hasta que se dispuso de recursos sénior con amplia experiencia dentro del personal y hasta que cada unidad de negocios involucrada hubiera alcanzado el nivel adecuado de madurez (TI, Finanzas, Recursos Humanos, Adquisiciones). Se cumplió con todas las condiciones con la contratación de un Director Sénior de TI en 2014 y una Vicepresidente de Finanzas en marzo de 2015, ambos con amplia experiencia en grandes proyectos de implementación de sistemas. Los recursos internos comprenden:

      1. Tres equipos expertos en el tema: cada uno con dos niveles de expertos (un líder y expertos para cada función).
      2. Cuatro recursos de reposición que cubren el período de diseño e implementación para asegurar que las operaciones diarias se lleven a cabo mientras se dedica el enfoque experto adecuado al proyecto de ERP.
      3. Un gerente de proyectos dedicado (contratado) con amplia experiencia en implementación de ERP.
      4. Tres recursos de TI: un Director Sénior de TI (supervisión y gestión), un Analista de Negocios en Tecnologías de la Información y un administrador de TI (uno para Recursos Humanos y uno para Finanzas/Adquisiciones).
      5. Un comité directivo que comprende: Un Director de Tecnologías de la Información e Innovación (CIIO), un Director de Operaciones (COO) y el Director Sénior de TI
      6. Un recurso de gestión de cambios de Recursos Humanos (a contratar)
      7. Revisiones de Gestión de riesgos empresariales incorporadas desde el comienzo del proyecto.

      Recursos externos:

      1. Los proveedores de ERP más grandes tienen una vasta red de socios comerciales certificados y de recursos de consulta internos a los que podrá recurrir la ICANN.
      2. La ICANN seleccionará a los consultores técnicos más calificados por medio de un proceso de entrevistas individuales.

      Solución técnica: Un modelo de software como servicio (SaaS):

      1. Una plataforma basada en la web y pronta para configurar utilizada por todos los clientes del proveedor de soluciones.
      2. Cada cliente configura una amplia gama de capacidades de acuerdo a las necesidades de su unidad de negocios (sin desarrollo de software ni adaptación).
      3. Para cada función, la gama de procesos estándares y opcionales se diseña basándose en las mejores prácticas de procesos y controles prontos para la configuración.
      4. La plataforma se actualiza con regularidad y tiene un plan de trabajo con diversas capacidades nuevas que se ponen a disposición de todos los clientes en la plataforma sin costo adicional.
      5. El proveedor de SaaS monitorea y gestiona el desempeño del sistema de acuerdo con los Acuerdos de Nivel de Servicio (SLA).

      Seguridad del sistema:

      1. Transferencia de datos: se ha diseñado una estrategia de conversión de datos de múltiples pasos que comprende procesos de evaluación, conciliación y validación.
        1. La ICANN convertirá datos transaccionales históricos y todos los datos de archivos maestros.
        2. Se realizarán pruebas exhaustivas a todos los programas de conversión relativas a la precisión e integridad.
        3. La ICANN llevará a cabo pruebas de unidades, dos Pilotos de Sala de Conferencias (CRP), las cuales prueban la configuración de sistema y la conversión de archivos de datos de nuestros procesos empresariales.
        4. La ICANN realizará un Piloto Empresarial, el cual simulará procesos empresariales reales de principio a fin (por ejemplo, Order to Cash y Procure to Pay) además de pruebas de conversión completas de datos históricos y datos de archivos maestros.
      2. Seguridad de datos: El proceso de Solicitud de Propuesta (RFP) incluye demostraciones sobre recuperación ante desastres, gestión de operaciones de centro de datos, cifrado de datos, registros de datos, entorno de ERP exclusivo a la ICANN:
        1. La ICANN realizará la configuración según estándares de talla mundial para la seguridad de los datos, que incluyen cifrado de datos, gestión de controles de acceso, acceso y revisión de registros de sistema y configuración de seguridad de acceso basada en buenos controles internos.

      Además, la Junta revisó las recomendaciones del personal y del Comité Financiero de la Junta Directiva sobre autoridad para contrataciones y desembolsos para una nueva solución de ERP.

      Habrá un impacto financiero en la ICANN para implementar una nueva solución de ERP. El impacto está incluido actualmente en el Plan Operativo y Presupuesto del año fiscal 2016 aprobado por la Junta Directiva el 25 de junio de 2015. Esta medida no tendrá un 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

      Visto y considerando que el 26 de abril de 2015 la Junta Directiva autorizó 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 parte del Gobierno de los Estados Unidos por un monto no mayor a 7 millones de dólares estadounidenses.

      Visto y considerando que la ICANN ha incurrido en costos reales durante el Año Fiscal 2015 de USD 8,7 millones, incluidos los costos imprevistos de asesoramiento jurídico independiente de aproximadamente USD 3,1 millones.

      Visto y considerando que la Junta Directiva reitera su declaración realizada el 25 de junio de 2015 en la que estableció que "mantiene 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 nota 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". (Véase https://www.icann.org/resources/board-material/resolutions-2015-06-25-en#2.c).

      Visto y considerando que el Comité de Finanzas de la Junta Directiva ha recomendado que la Junta Directiva autoriza 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 8,7 millones de dólares estadounidenses (USD), 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 monto de 8,7 millones de dólares estadounidenses.

      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 (USD 7.000.000) a través de un retiro correspondiente del Fondo de Reserva.

      Conforme se ha incurrido en costos durante el Año Fiscal 2015 (FY15) para este proyecto, la Junta Directiva aprobó el retiro de fondos previstos 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.

      Dado que el costo total real en el que se incurrió durante el Año Fiscal 2015 (FY15) para este proyecto fue de USD 8,7 millones, lo que excedió la suma total de USD 7 millones de retiro del Fondo de Reserva que había autorizado la Junta en la decisión 2015.04.26.17, la ICANN intentará obtener la aprobación de la Junta para retirar fondos del Fondo de Reserva por la suma total del costo real de USD 8,7 millones en el que se incurrió. Esta medida no tendrá un 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: Camino hacia las Rondas Futuras

      Visto y considerando que la resolución 2012.02.07.05 de la Junta Directiva reafirmó el compromiso de la ICANN de abrir una ronda adicional del Programa de Nuevos gTLD lo más pronto posible.

      Visto y considerando que las revisiones de la ronda de 2012 del Programa de Nuevos gTLD están actualmente en curso.

      Visto y considerando que la Junta Directiva fomenta la participación de las partes interesadas en el proceso ascendente para revisar y desarrollar rondas futuras del Programa de Nuevos gTLD.

      Resuélvase (2015.09.28.12), la Junta Directiva ordena al personal de la ICANN continuar con las revisiones del Programa de Nuevos gTLD tal como se planificó y alienta a la comunidad de partes interesadas a apoyar y participar en un proceso de revisión sólido y con sentido.

      Resuélvase (2015.09.28.13), la Junta Directiva hará un seguimiento con interés del trabajo de la comunidad y evaluará la posibilidad de una guía en rondas futuras una vez que el proceso de revisión y el potencial proceso de desarrollo de políticas de la GNSO hayan alcanzado una etapa más avanzada.

      Fundamento de las resoluciones 2015.09.28.12 – 2015.09.28.13

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

      Numerosas actividades de revisión y de la comunidad están actualmente en curso que probablemente informarán cuando se realizará la siguiente ronda y cómo se llevará a cabo. Se solicitó a la Junta Directiva que evalúe un proceso y un plazo para una ronda adicional del Programa de Nuevos gTLD para ayudar a la ICANN en la planificación, análisis y presupuestación a largo plazo necesarios para lograr que la próxima ronda sea efectiva.

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

      La Junta Directiva está evaluando en qué medida los numerosos procesos de revisión y las actividades de la comunidad que se encuentran en progreso informarán sobre cuándo y cómo se emprenderá la próxima ronda del Programa de Nuevos gTLD. Se han considerado tres opciones: La primera establece una fecha objetivo para los aportes de la comunidad a las rondas futuras y aporta un plazo aproximado para completar el proceso de revisión y un posible PDP. No compromete a ninguna parte a una fecha límite estricta para completar actividades de revisión o de desarrollo de políticas, sino que aporta un plazo aproximado para facilitar la planificación de todas las partes. La segunda opción establece un proceso anticipado mediante el cual la Junta Directiva evaluaría en primer lugar los resultados de las revisiones antes de asignar al personal tareas relativas a planes de implementación de desarrollo y plazos. La tercera pospone el establecimiento de un plazo o de un conjunto de requisitos previos para la próxima ronda hasta que el proceso de revisión o el PDP alcancen una etapa más avanzada.

      La Junta Directiva está tomando medidas en el presente para fomentar la ejecución y la participación continuas en los procesos de revisión actuales y para posponer la evaluación de la planificación de la próxima ronda hasta que las revisiones se encuentren en una etapa más avanzada.

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

      A partir de setiembre de 2014, el personal de la ICANN publicó y recibió comentarios y sugerencias sobre las revisiones de la versión preliminar del Plan de Trabajo para el Programa de Nuevos gTLD.4 El Grupo de Discusión de la GNSO sobre Procedimientos subsiguientes de nuevos gTLD ha tenido un papel importante en la discusión de implicaciones y desarrollo de políticas para el programa de nuevos gTLD. Si bien no se han realizado consultas formales a la GNSO, ha sido recurrente en las discusiones del grupo el tema de qué procesos futuros deberían ser considerados en la determinación del desarrollo de la próxima ronda. Además, partes interesadas de la comunidad, como las partes contratadas, los nuevos operadores de registro, los operadores de proveedores de servicios de Internet (ISP) y de IP y los miembros de la comunidad de usuarios finales, han aportado sus perspectivas sobre el plazo de la próxima ronda.

      ¿Qué materiales significativos analizó la Junta Directiva?

      La Junta revisó el borrador del Plan de Trabajo, Afirmación de Compromisos (AoC), el cronograma estimado para completar la revisión basado en estimaciones iniciales de actividades descritas en el Plan de Trabajo, el Informe Preliminar de Cuestiones de la GNSO del 31 de agosto de 2015 y las discusiones de la GNSO en las que se basó el Informe, las resoluciones 2012.02.07.05 y 2014.11.17.10 – 2014.11.17.12 relativas a compromisos de abrir una segunda ronda lo más pronto posible y consultando con los grupos de partes interesadas pertinentes, y la Revisión de Mecanismos de Protección de Derechos sobre las medidas de protección empleadas para mitigar problemas potenciales con el Programa de Nuevos gTLD.

      ¿Qué factores consideró importantes la Junta Directiva?

      Dado que se desconocen los resultados del proceso de revisión y que se podría iniciar un PDP, sería poco realista en esta etapa temprana establecer un plazo para abrir una ronda adicional del Programa de Nuevos gTLD. La Junta Directiva entiende que gran parte de la comunidad de partes interesadas desea mayor certeza, sin embargo considera prioritario en esta etapa llevar a cabo revisiones significativas de la ronda actual. La Junta Directiva volverá a analizar discusiones sobre cronogramas y procesos para rondas futuras más adelante.

      ¿Existen impactos positivos o negativos para la comunidad?

      Probablemente algunos miembros de la comunidad se sientan frustrados por la falta de compromiso con un plazo o un procedimiento definitivos. Sin embargo, las acciones de la Junta Directiva intentan asegurar que se dé la importancia adecuada al proceso de revisión para evaluar exhaustivamente los resultados de la primera ronda del Programa de nuevos gTLD. Algunas unidades constitutivas podrán considerar que esto no responde a las preguntas relativas a cómo se espera que los varios procesos y revisiones actualmente en progreso conduzcan 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 se deben abordar en la creación de este conjunto de pasos. Avanzar muy rápido hacia una segunda ronda sin el tiempo adecuado para la revisión podría impedir a la comunidad evaluar de forma adecuada las lecciones aprendidas en la primera ronda como parte del desarrollo de la próxima ronda. Asimismo, comprometerse con un plazo o un proceso esperado podría generar expectativas poco realistas en las comunidades de partes interesadas en relación con el momento en que se podría llevar a cabo una segunda ronda.

      ¿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. Sin embargo, no hay implicaciones de presupuesto adicionales anticipadas fruto de esta resolución que no hayan sido planeadas o asignadas.

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

      Esta resolución no tendrá impacto inmediato sobre la seguridad, estabilidad y flexibilidad del DNS, pero cabe señalar que la seguridad, estabilidad y flexibilidad del DNS es una de las áreas de estudio propuestas.

      ¿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 todavía se deben evaluar los resultados de la primera ronda del Programa de Nuevos gTLD y todavía se debe establecer un proceso de políticas definido. Sin embargo, es probable que las revisiones y el PDP se sometan a comentarios públicos una vez completadas.

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

      Visto y considerando que la Política de Declaración de Acreditación de Registradores (la "Política de Acreditación") de la ICANN, adoptada en 1999, establece que los registradores deben tener pólizas de seguro de responsabilidad comercial general (CGL) con límites de por lo menos USD 500.000, o una suma menor si el registrador puede probar que un límite más bajo fuera razonable como compensación en caso una pérdida cubierta por el seguro.

      Visto y considerando que los Acuerdos de Acreditación de Registradores exigen que los registradores tengan cobertura de hasta USD 500.000 (sin referencia a los límites potencialmente más bajos de la Política de Acreditación).

      Visto y considerando que la ICANN recibió comentarios que indicaban que los requisitos de seguros de CGL del Acuerdo de Acreditación de Registradores no promueven la intención de la Política de Declaración de Acreditación de Registradores sobre el requisito de seguro de CGL de indemnizar a los registratarios en caso de acciones perjuiciosas por parte del registrador cubiertas por el seguro, lo que supone un obstáculo para el desarrollo del mercado de registradores en 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 exime el requisito de seguro de CGL establecido en los RAA de 2009 y 2013 y se ordena al Presidente y Director Ejecutivo, o sus representantes, tomar las medidas necesarias para implementar la presente resolución.

      Resuélvase (2015.09.28.15), se solicita a la GNSO evaluar si se debe trabajar sobre políticas relativas al reemplazo de requisitos de seguro a la luz de la Política de Declaración de Acreditación de Registradores.

      Fundamento de las resoluciones 2015.09.28.14 – 2015.09.28.15

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

      Los Acuerdos de Acreditación de Registradores de 2009 y 2013 exigen a los registradores contratar un seguro de Responsabilidad Comercial General (CGL) con un límite de póliza de por lo menos USD 500.000. Este requisito se basa en el texto de la Política de Declaración de Acreditación de Registradores de la ICANN, que establece que los registradores deben tener pólizas de seguro de responsabilidad comercial general (CGL) con límites de por lo menos USD 500.000, o una suma menor si el registrador puede probar que un límite inferior fuera razonable como compensación en caso una pérdida cubierta por el seguro. El requisito del RAA no incorpora la flexibilidad de la Política de Declaración de Acreditación para límites de póliza inferiores.

      Las pólizas de seguro de CGL en general protegen a las empresas contra demandas por responsabilidad por lesiones corporales y daños a la propiedad que ocurran dentro de sus instalaciones, y también por responsabilidad por publicidad o daños personales, en algunos casos. Sin embargo, la mayoría de las pólizas de CGL no brindan cobertura sobre los errores y omisiones del registrador. Es decir, en general los titulares de nombres de dominio no podrían recibir compensación de parte de una compañía de seguros (bajo una póliza de CGL) por los actos de negligencia de un registrador, como eliminar por accidente o no renovar un registro o permitir que se apropien nombres de dominio.

      Este requisito de seguro plantea desafíos financieros y prácticos para algunas entidades que buscan convertirse en registradores acreditados por la ICANN. Los comentarios de la comunidad sugieren que este requisito pone en una desventaja desproporcionada a los registradores y a los potenciales registradores de lugares donde este tipo de seguro es excesivamente costoso o no existe.

      Por lo tanto, la Junta Directiva está tomando medidas para aprobar una exención del requisito de seguro de CGL existente en los RAA de 2009 y 2013 porque los requisitos de seguro de Responsabilidad Comercial General parecen no promover los objetivos previstos de la política y plantean una carga excesiva para los potenciales registradores. A pesar de una importante consulta pública, no hay prueba de que el requisito de CGL haya brindado beneficios a los registratarios.

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

      La ICANN ha recibido comentarios de potenciales registradores sobre el hecho de que el seguro exigido es difícil o imposible de contratar en su región. La ICANN llevó a cabo un taller en el que se discutió este y otros temas relacionados con regiones insuficientemente atendidas en la reunión de la ICANN en Singapur en 2014. La ICANN consultó con una consultora de seguros externa, y también con varios registradores y registradores potenciales. La ICANN solicitó dos rondas de comentarios públicos sobre este tema en mayo de 2014 y enero de 2015. Como parte de sus medidas, la Junta Directiva está animando a la GNSO a examinar esta cuestión.

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

      Miembros de la comunidad han informado a la ICANN que el requisito de seguro existente puede ser difícil o imposible de cumplir en muchas jurisdicciones, especialmente en jurisdicciones fuera de América del Norte y Europa. Algunas personas comentaron que el seguro de CGL no está disponible en algunos países y, si bien está disponible en otros países, el límite de USD 500.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 comerciales en las regiones correspondientes. Además, algunos comentaristas cuestionaron si el requisito sigue siendo necesario dadas las mejoras institucionales de la ICANN en otras áreas, como la aplicación del cumplimiento y la custodia de datos. Algunos miembros de la comunidad sugirieron que la ICANN podría facilitar a los registradores nuevos y a los existentes una lista de aseguradoras que trabajen para empresas de registradores existentes para que los registradores puedan asegurarse el seguro exigido para obtener la acreditación de la ICANN.

      Sin embargo, otros miembros de la comunidad advirtieron que se podría dejar sin protección a los registratarios si se exime el requisito de CGL.

      ¿Qué datos consideró importantes la Junta Directiva al tomar esta decisión?

      Para llegar a esta decisión, la Junta Directiva evaluó dos informes de comentarios públicos sobre la cuestión publicados el 2 de septiembre de 2014 [PDF, 405 KB] y el 3 de abril de 2015 [PDF, 516 KB] y materiales de referencia de la Junta Directiva. La Junta también evaluó la Política de Declaración de Acreditación de Registradores y también los Acuerdos de Acreditación de Registradores de 2009 y 2013.

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

      El requisito de seguro existente no cumple con el propósito que se buscó originalmente de proteger a los registratarios de los actos perjuiciosos de los registradores. Además, el requisito está impidiendo la competencia en regiones insuficientemente atendidas del mundo. Dado que el requisito de seguro original era un asunto de la política de la ICANN, la GNSO es el organismo adecuado para decidir si un reemplazo del requisito sería adecuado.

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

      Esta decisión no tiene impacto fiscal sobre la ICANN. Eliminar el requisito podría reducir costos para los registradores y potenciales registradores que elijan no tener seguro de responsabilidad comercial general.

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

      Con base en toda la información recibida hasta la fecha, surge a la vista que no habrá impacto negativo sobre los registratarios, otras partes interesadas o el interés público global si la Junta Directiva aprobara la exención del requisito de seguro.

      La decisión tendrá un impacto positivo sobre los registradores existentes y los potenciales, especialmente sobre aquellos que se encuentran en regiones donde el seguro de CGL es excesivamente costoso o imposible de obtener. Es probable que el impacto sea financiero en primer lugar, pero también puede estimular más solicitudes para la acreditación de registrador desde países desarrollados y en vías de desarrollo.

      La aprobación por parte de la Junta Directiva de la exención del requisito de seguro impulsará los esfuerzos de la ICANN de promover la competencia de registradores en un entorno global y dará la oportunidad a la GNSO de evaluar si sería adecuado un reemplazo del requisito de seguro.

      ¿Cuáles son las repercusiones en 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 sobre Políticas e Implementación de la GNSO

      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íticas e implementación de la GNSO no perteneciente a los PDP (http://gnso.icann.org/en/council/resolutions#201307) al cual se le encargó presentar 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, tal como se define en el Manual de PDP, funcionen y se manejen.

      Visto y considerando que el Grupo de Trabajo sobre políticas e implementación de la GNSO publicó su Informe Inicial de Recomendaciones para la recepción de comentarios públicos el 19 de enero de 2015 (véase https://www.icann.org/public-comments/policy-implementation-2015-01-19-en).

      Visto y considerando que el Grupo de Trabajo en materia de Implementación y Política de la GNSO revisó los aportes recibidos (véase herramienta de revisión de comentario público [DOC, 267 KB]) y actualizó el informe en consecuencia, obteniendo así un Informe Final de Recomendaciones, que se presentó ante el Consejo de la GNSO el 2 de junio de 2015.

      Visto y considerando que el Consejo de la GNSO adoptó de forma unánime el Informe Final de Recomendaciones (véase http://gnso.icann.org/en/drafts/policy-implementation-recommendations-01jun15-en.pdf [PDF, 1.53 MB]) el 24 de junio de 2015.

      Visto y considerando que el 28 de julio de 2015, la Junta Directiva de la ICANN ordenó al personal de la ICANN publicar las modificaciones propuestas a los Estatutos de la ICANN como consecuencia de las recomendaciones propuestas en el Informe Final de Recomendaciones para comentario público (véase https://www.icann.org/public-comments/bylaws-amendments-2015-07-31-en).

      Visto y considerando que se recibieron dos comentarios a favor de las recomendaciones propuestas, entre ellos una Declaración de Asesoramiento del ALAC.

      Visto y considerando que el ATRT2 recomendó que "la Junta Directiva debería seguir apoyando la participación intercomunitaria con el fin de desarrollar una comprensión de la distinción entre el desarrollo 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 con la Junta Directiva sobre asuntos como políticas, implementación y asuntos administrativos, sobre los que la Junta Directiva toma decisiones" (Recomendación N.° 4).

      Resuélvase (2015.09.28.16), la Junta Directiva aprueba las modificaciones a la sección 3-9 del Artículo X de los Estatutos de la ICANN, tal como se publicaron para el comentario público para abordar los nuevos umbrales de votación de la GNSO como consecuencia del Proceso de Orientación de la GNSO (GGP) y el Proceso Expeditivo de Desarrollo de Políticas de la GNSO (EPDP).

      Resuélvase (2105.09.28.17), la Junta Directiva aprueba las modificaciones del Anexo A de los Estatutos de la ICANN tal como se publicó para el comentario público (véase https://www.icann.org/en/system/files/files/bylaws-proposed-amendments-gnso-policy-implementation-31jul15-en.pdf [PDF, 656 KB]), creando así un nuevo Anexo A-1 que describe el EPDP de la GNSO.

      Resuélvase (2015.09.28.18), la Junta Directiva aprueba las modificaciones del Anexo A de los Estatutos de la ICANN tal como se publicó para el comentario público (véase https://www.icann.org/en/system/files/files/bylaws-proposed-amendments-gnso-policy-implementation-31jul15-en.pdf [PDF, 656 KB]), creando así un Anexo A-2 que describe el GGP de la GNSO.

      Resuélvase (2015.09.28.19), la Junta Directiva respalda el conjunto de principios / requisitos de la GNSO en la medida que se relacionan con política e implementación según la descripción de la sección 4 del Informe Final de Recomendaciones y ordena al Presidente y Director Ejecutivo, o sus representantes, y también a la comunidad de ICANN, tomar en cuenta estos principios y requisitos en la medida en que se involucra en asuntos relacionados con la política e implementación de la GNSO.

      Resuélvase (2015.09.28.20), la Junta Directiva respalda los Principios y Directrices del Equipo para la Revisión de la Implementación según la descripción en el Anexo L del Informe Final de Recomendaciones y ordena al personal de la ICANN y a la comunidad de la ICANN tomar en cuenta estos Principios y Directrices en la medida que se involucren en asuntos relacionados con la implementación.

      Resuélvase (2015.09.28.21), la Junta Directiva acusa recibo del Asesoramiento proporcionado por el ALAC y se compromete a supervisar minuciosamente las actividades de desarrollo de políticas de la GNSO a fin de garantizar que los intereses de los usuarios y el interés público se consideren adecuadamente y que la implementación de políticas complejas pueda realizarse dentro de plazos razonables.

      Resuélvase (2015.09.28.22), la Junta Directiva ordena al Presidente y Director Ejecutivo, o sus representantes, publicar los documentos pertinentes en páginas relacionadas con la política e implementación de la GNSO del sitio web de la GNSO y la ICANN y buscar e incorporar comentarios sobre mejoras y otros materiales de apoyo según corresponda.

      Resuélvase (2015.09.28.23), por la presente la Junta Directiva considera completa la Recomendación N.° 4 del ATRT2 e invita al ATRT3 a revisar las recomendaciones adoptadas a la luz de los hallazgos y recomendaciones del ATRT2.

      Resuélvase (2015.09.28.24) que la Junta Directiva agradece a la comunidad de la GNSO y a los demás involucrados por su arduo trabajo en este esfuerzo.

      Fundamentos de 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, que incluyen: 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 bajo el marco de la reunión ICANN46, el Consejo de la Organización de Apoyo para Nombres Genéricos (GNSO) decidió, en julio de 2013, conformar un Grupo de Trabajo (WG) al cual se le encargó desarrollar una serie de recomendaciones sobre:

      • Un conjunto de principios para apuntalar cualquier 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 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; y
      • Mayor orientación sobre cómo se espera que los Equipos para la Revisión de la Implementación de la GNSO, tal como se define en el Manual de PDP, funcionen y se manejen.

      El Consejo de la GNSO adoptó las recomendaciones del Grupo de Trabajo de forma unánime el 24 de junio de 2015 y estas fueron presentadas ante la Junta Directiva de la ICANN para su evaluación.

      Además, el Segundo Equipo de Revisión sobre Responsabilidad y Transparencia (ATRT2) también identificó esta cuestión como prioridad: "la Junta Directiva debería seguir apoyando la participación intercomunitaria con el fin de desarrollar una comprensión de la distinción entre el desarrollo 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 con la Junta Directiva sobre asuntos como políticas, implementación y asuntos administrativos, sobre los que la Junta Directiva toma decisiones" (Recomendación N.° 4).

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

      La medida actual de la Junta Directiva es adoptar recomendaciones de la GNSO en cuanto a políticas e implementación. Las recomendaciones adoptadas incluyen tres procesos nuevos 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 las modificaciones solicitadas a los Estatutos para implementar el Proceso de Orientación de la GNSO y el Proceso Expeditivo de Desarrollo de Políticas de la GNSO. Estos procesos nuevos pretenden brindar al Consejo de la GNSO más flexibilidad para abordar cuestiones de políticas a través de procesos formales que se utilizarán cuando se cumpla con criterios específicos. Además, la Junta Directiva está tomando medidas para respaldar los principios y directrices de políticas e implementación de la GNSO propuestos para orientar más el trabajo del personal y de la comunidad relacionado con la política e implementación de la GNSO.

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

      Tras varios debates, incluyendo la publicación de un documento de discusión por parte del personal (véase https://gnso.icann.org/en/correspondence/policy-implementation-framework-08jan13-en.pdf[PDF, 195 KB] y http://forum.icann.org/lists/comments-policy-implementation-31jan13/) y una sesión de la comunidad realizada bajo el marco de la reunión ICANN46 (véase http://beijing46.icann.org/node/37133) el Consejo de la Organización de Apoyo para Nombres Genéricos (GNSO) decidió en julio de 2013 en consulta con otros SO/AC (véase http://gnso.icann.org/en/correspondence/robinson-to-so-ac-leadership-23apr13-en.pdf [PDF, 236 KB]) formar un Grupo de Trabajo de la GNSO para abordar varias cuestiones específicas en la medida en que se relacionan con la Política e Implementación de la GNSO. El Grupo de Trabajo de la GNSO solicitó aportes iniciales de todos los SO/AC de la ICANN y los grupos de partes interesadas y unidades constitutivas de la GNSO en una etapa temprana (véase https://community.icann.org/x/iSmfAg). La publicación del Informe Inicial fue acompañada de un foro de comentarios públicos (véase https://www.icann.org/public-comments/policy-implementation-2015-01-19-en) y también una sesión comunitaria durante la reunión ICANN52 (véase https://singapore52.icann.org/en/schedule/wed-policy-implementation). El Grupo de Trabajo revisó y abordó todos los aportes recibidos tal como se demostró en la herramienta de revisión de comentarios públicos (véase https://community.icann.org/x/iSmfAg). Tras la adopción unánime del Informe Final de Recomendaciones por parte del Consejo de la GNSO, la Junta Directiva de la ICANN ordenó al personal de la ICANN publicar las modificaciones propuestas a los Estatutos de la ICANN para el comentario público (véase https://www.icann.org/public-comments/bylaws-amendments-2015-07-31-en). Se recibieron dos comentarios, entre ellos una Declaración de Asesoramiento del ALAC, a favor de las recomendaciones (véase http://forum.icann.org/lists/comments-bylaws-amendments-31jul15/).

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

      El Grupo de Trabajo revisó y abordó todos los aportes recibidos tal como se demostró en la herramienta de revisión de comentarios públicos (véase https://community.icann.org/x/iSmfAg). El ALAC, en la Declaración de Asesoramiento que respondió al foro de comentarios públicos lanzado por la Junta Directiva de la ICANN, apoyó las recomendaciones pero también recomendó que la Junta Directiva de la ICANN supervise minuciosamente las actividades de desarrollo de políticas de la GNSO a fin de garantizar que los intereses de los usuarios y el interés público se consideren adecuadamente y que la implementación de políticas complejas pueda realizarse dentro de plazos razonables.

      ¿Qué materiales significativos analizó la Junta Directiva?

      La Junta Directiva revisó el Informe Final de Recomendaciones de Política e Implementación de la GNSO (véase http://gnso.icann.org/en/drafts/policy-implementation-recommendations-01jun15-en.pdf [PDF, 1.53 MB]) y materiales relacionados.

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

      La Junta Directiva considera sumamente importante que estas recomendaciones fueron desarrolladas por la comunidad en consulta con el personal de la ICANN y que estas recomendaciones recibieron el apoyo unánime del Consejo de la GNSO. Además, la Junta Directiva reconoce la importancia de abordar esta cuestión, tal como lo señaló el ATRT2, y opina que estas recomendaciones brindarán al Consejo de la GNSO más flexibilidad para abordar cuestiones de políticas a través de procesos formales y también brindarán la claridad y previsibilidad necesarias en relación con cuestiones relacionadas a la 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 prevén impactos fiscales o ramificaciones como consecuencia de la implementación de estas recomendaciones.

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

      No se han identificado cuestiones de seguridad, estabilidad o flexibilidad relativas al DNS en relación con estas recomendaciones.

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

      Visto y considerando que, el BCG 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 llevó a cabo entrevistas con los candidatos.

      Visto y considerando que el Comité de Gobernanza de la Junta Directiva recomendó que Stéphane Van Gelder sea designado Presidente del NomCom de 2016 y Hans Petter Holen sea designado Presidente Electo del NomCom de 2016.

      Resuélvase (2015.09.28.25), por la presente, la Junta Directiva designa a Stéphane Van Gelder Presidente del Comité de Nominaciones de 2016 y a Hans Petter Holen 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 Comité de Nominaciones (NomCom). Véase el Artículo VII, secciones 2.1 y 2.2 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 BGC publicó una convocatoria para manifestaciones de interés (EOI) el 4 de junio de 2015 procurando las EOI para el 30 de junio de 2015 (véase https://www.icann.org/news/announcement-2-2015-06-04-en). La convocatoria de manifestaciones de interés se extendió luego hasta el 20 de julio de 2015 (véase https://www.icann.org/news/announcement-2015-07-01-en). El Comité de Gobernanza de la Junta Directiva recibió y revisó varias manifestaciones de interés, supervisó una evaluación de 360 grados del liderazgo del NomCom en 2015 y llevó a cabo entrevistas con los candidatos antes de realizar sus recomendaciones. La Junta Directiva ha sometido a consideración la recomendación del BGC respecto del Presidente y el Presidente Electo para el NomCom 2016 y está de acuerdo con ella. Asimismo, la Junta Directiva desea agradecer a todos los que 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 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 tendrá ningún impacto económico en la ICANN que no haya sido ya previsto, y no se observarán impactos negativos en la seguridad, estabilidad o flexibilidad del sistema de nombres de dominio.

1 Para obtener una definición de los niveles de consenso, http://gnso.icann.org/en/council/annex-1-gnso-wg-guidelines-07apr11-en.pdf [PDF, 344 KB] (p.8).

2 Véase también 5.1.1 y la Herramienta de revisión de comentario público (Anexo B). [del Informe Final]).

3 Muchos asumen que eso sería US-ASCII inglés aunque los argumentos para otros códigos de escritura podrían ser convincentes.

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