Skip to main content
Resources

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

Esta página está disponible en:

  1. Orden del día convenido:
    1. Aprobación de las actas de la reunión
    2. Nombramientos del Comité Asesor de Seguridad y Estabilidad
    3. Convocatoria de la primera Revisión de las funciones de nombres de la IANA
    4. Renovación del Acuerdo de Registro del TLD .coop
    5. Designación del Presidente y Presidente Electo del Comité de Nominaciones de 2019
  2. Orden del día principal:
    1. Asesoramiento del GAC: Comunicado pronunciado en Panamá (junio de 2018)
    2. Estrategia de Servidores Raíz
    3. Continuación con el traspaso de la KSK
    4. Mayor consideración de las solicitudes de .AMAZON
    5. Otros temas por tratar

 

  1. Orden del día convenido:

    1. Aprobación de las actas de la reunión

      Resuélvase (2018.09.16.01): La Junta Directiva aprueba las actas de los días 18 de julio y 21 de agosto de 2018 de las reuniones de la Junta Directiva de la ICANN.

    2. Nombramientos del Comité Asesor de Seguridad y Estabilidad

      Visto y considerando: Que, ocasionalmente, el Comité Asesor de Seguridad y Estabilidad (SSAC) realiza una revisión y cambio de sus miembros.

      Visto y considerando: Que el Comité de Membresía del SSAC solicita que la Junta Directiva nombre a David Piscitello ante el SSAC por un mandato que se inicia en forma inmediata tras la aprobación de la Junta Directiva y con fecha de finalización el 31 de diciembre de 2020.

      Resuélvase (2018.09.16.02): La Junta Directiva designa a David Piscitello para desempeñarse en el SSAC durante un mandato que comienza en forma inmediata tras la aprobación de la Junta Directiva y finaliza el 31 de diciembre de 2020.

      Fundamento de la Resolución 2018.09.16.02

      El SSAC es un grupo diverso de personas cuyos conocimientos sobre temas específicos permiten que dicho comité cumpla su estatuto y ejecute su misión. Desde su creación, el SSAC ha invitado a personas con amplios conocimientos y gran experiencia en áreas técnicas y de seguridad que son fundamentales para la seguridad y la estabilidad de los sistemas de asignación de direcciones y de nombres de dominio de Internet.

      Las operaciones continuas del SSAC como organismo competente dependen del aporte y el talento de expertos que han aceptado contribuir voluntariamente con su tiempo y energía para llevar a cabo la misión del comité.

      A lo largo de sus 40 años de carrera, David ha acumulado una amplia experiencia en redes, seguridad, protocolos y servicios de Internet. David ha prestado sus servicios como miembro del personal de la ICANN desde 2005 hasta 2018, más recientemente en el rol de Vicepresidente de Seguridad y Coordinación de las TIC, y apoyó el trabajo del SSAC durante muchos años. Llevó a cabo investigaciones y redactó informes técnicos y documentos de asesoramiento en nombre del Comité, y trabajó en colaboración con el entonces Presidente, Dr. Stephen Crocker. Ha contribuido de manera positiva a muchos debates del SSAC.

      Esta resolución forma parte de las funciones administrativas y organizativas que no requieren comentario público. La designación de los miembros del SSAC sirve al interés público, respalda la Misión de la ICANN y honra el compromiso asumido por la ICANN de fortalecer la seguridad, estabilidad y flexibilidad del DNS.

    3. Convocatoria de la primera Revisión de las funciones de nombres de la IANA

      Visto y considerando: Que los Estatutos de la ICANN exigen que "la Junta Directiva, o un comité apropiado de la misma, lleve a cabo revisiones periódicas y/o especiales (cada revisión denominada "IFR") del desempeño por parte de la PTI de las Funciones de la IANA con respecto a los requisitos contractuales establecidos en el Contrato de Funciones de Nombres de la IANA y la Declaración de Trabajo (SOW) de la Función de Nombres de la IANA que llevará a cabo un Equipo de Revisión de las Funciones de la IANA ("IFRT") establecido conforme al Artículo 18 de los Estatutos de la ICANN”.

      Visto y considerando: Que la sección 18.2.a de los Estatutos de la ICANN exige que la primera IFR periódica se convoque a más tardar el 1 de octubre de 2018.

      Visto y Considerando: Que la sección 18.7 de los Estatutos de la ICANN especifica la composición del IFRT y exige que los miembros y los coordinadores de enlace del Equipo de Revisión sean designados de acuerdo con las reglas y procedimientos de las organizaciones con facultades para designar miembros.

      Visto y considerando: Que algunas de las organizaciones con facultades para designar miembros ya han designado miembros y coordinadores de enlace para el IFRT.

      Visto y considerando: Que la Sección 18.8.c de los Estatutos de la ICANN exige que las organizaciones con facultades para designar miembros para los miembros y coordinadores de enlace del IFRT trabajen conjuntamente para lograr un Equipo de Revisión equilibrado en cuanto a la diversidad (incluida la diversidad funcional, geográfica y cultural) y las habilidades, y procuren ampliar la cantidad de personas que participan en las diferentes revisiones; siempre y cuando, el Equipo de Revisión incluya a miembros de cada Región Geográfica de la ICANN, y la ccNSO y el Grupo de Partes Interesadas de Registros no designe a varios miembros que sean ciudadanos de países de la misma Región Geográfica de la ICANN.

      Visto y considerando: Que la sección 18.8.e de los Estatutos de la ICANN exige que la Junta Directiva de la ICANN designe a un miembro del personal de la ICANN para que se desempeñe como punto de contacto para facilitar las líneas formales de comunicación entre el Equipo de Revisión y la ICANN.

      Visto y considerando: Que la sección 18.3 de los Estatutos de la ICANN especifica el alcance y las responsabilidades del Equipo de Revisión.

      Visto y considerando: Que la sección 18.3.j de los Estatutos de la ICANN exige que el Equipo de Revisión "identifique el proceso u otras áreas para mejorar el desempeño de la Función de Nombres de la IANA en virtud del Contrato de Funciones de Nombres de la IANA y la SOW de las Funciones de Nombres de la IANA y el desempeño del CSC y EC en lo que respecta a la supervisión de la PTI”.

      Visto y considerando: Que la sección 18.11 de los Estatutos de la ICANN exige que la organización de la ICANN proporcione el apoyo administrativo y operativo necesario para que el Equipo de Revisión cumpla con sus responsabilidades, lo cual incluye proporcionar y facilitar la participación remota en todas las reuniones.

      Resuélvase (2018.09.16.03): La Junta Directiva convoca la primera Revisión de las Funciones de Nombres de la IANA y ordena al Presidente y Director Ejecutivo de la ICANN, o a quien este designe, que proporcione el apoyo administrativo y operativo necesario para que el Equipo de Revisión cumpla con sus responsabilidades, lo cual incluye proporcionar y facilitar la participación remota en todas las reuniones.

      Resuélvase (2018.09.16.04): La Junta Directiva solicita que las restantes organizaciones con facultades para designar miembros completen sus procesos para designar miembros y coordinadores de enlace. Asimismo, las organizaciones con facultades para designar miembros deben coordinarse para garantizar que el Equipo de Revisión compuesto cumpla con los requisitos de diversidad que se especifican en la Sección 18.8.c de los Estatutos de la ICANN.

      Resuélvase (2018.09.16.05): La IFR se llevará a cabo de acuerdo con el alcance especificado en la Sección 18.3 de los Estatutos de la ICANN.

      Resuélvase (2018.09.16.06): En cumplimiento de la obligación de la Junta Directiva de designar a un miembro del personal de la organización de la ICANN que se desempeñe como punto de contacto para facilitar las líneas formales de comunicación entre el Equipo de Revisión y la organización de la ICANN, la Junta Directiva ordena al Presidente y Director Ejecutivo de la ICANN que designe al miembro del personal adecuado para desempeñar esa función.

      Fundamentos para las Resoluciones 2018.09.16.03 – 2018.09.16.06

      La Junta Directiva convoca a la primera Revisión de las Funciones de Nombres de la IANA ("IFR") periódica para cumplir con el requisito de la Sección 18.2 de los Estatutos de la ICANN que establecen que la primera IFR periódica se debe convocar a más tardar el 1 de octubre de 2018. El IFR es un nuevo mecanismo de responsabilidad creado como parte de la transición de la custodia de la IANA para garantizar que la PTI cumpla con las necesidades y expectativas de sus clientes de servicios de nombres mediante el cumplimiento de los requisitos contractuales estipulados en el Contrato de Funciones de Nombres de la IANA y la Declaración de Trabajo de Funciones de Nombres de la IANA [PDF, 626 KB].

      Las organizaciones con facultades para designar miembros ya han tomado medidas para designar a los miembros y los coordinadores de enlace del Equipo de Revisión. La Junta Directiva solicita que las restantes organizaciones con facultades para designar miembros completen sus procesos para designar miembros y coordinadores de enlace para que el Equipo de Revisión compuesto pueda comenzar su trabajo. Para asegurarse de que la composición final del Equipo de Revisión cumpla con los requisitos de los Estatutos de la ICANN, la Junta Directiva solicita que las organizaciones con facultades para designar miembros se coordinen para finalizar la composición del Equipo de Revisión conforme a la Sección 18.8.c de los Estatutos de la ICANN. La organización de la ICANN ha recibido la orden de proporcionar un punto de contacto de un miembro del personal para apoyar la comunicación entre el Equipo de Revisión y la organización de la ICANN.

      La Junta Directiva entiende que el alcance del IFR está bien definido en la Sección 18.3 de los Estatutos de la ICANN. Existe la posibilidad de superposición con la Revisión de Efectividad del CSC en curso, que se exige en la Sección 17.3 de los Estatutos, en la cual se establece: "La efectividad del CSC se revisará dos años después de la primera reunión del CSC…El método de revisión será determinado por la ccNSO y la GNSO." La Revisión de Efectividad del CSC debe comenzar antes del 6 de octubre de 2018, que es dos años después de que el Comité Permanente de Clientes celebró su primera reunión. La posible superposición es con el punto sobre el alcance del Equipo de Revisión de la IFR para "Identificar el proceso u otras áreas para mejorar el rendimiento…del CSC…en lo que respecta a la supervisión de la PTI". Para garantizar un uso eficaz y eficiente de los recursos de la comunidad, la Junta Directiva recomienda al Equipo de Revisión de la IFR que considere como aportes para su trabajo cualquier conclusión, recomendación o metodología y criterios futuros que la GNSO y la ccNSO adopten en relación con la revisión de la efectividad del Comité Permanente de Clientes.

      El plan operativo y presupuesto anual de la ICANN para el año fiscal 2019 aprobado por la Junta Directiva contiene recursos presupuestados para respaldar la IFR.

      Esta acción es parte de la misión de la ICANN porque apoya a que la ICANN lleve a cabo la parte de su misión relacionada con la coordinación de la distribución y asignación de nombres en la zona raíz, y apoya directamente el interés público. La Junta Directiva de la ICANN está tomando esta medida de acuerdo con los requisitos de los Estatutos de la ICANN. Por lo tanto, no se necesita un período de comentarios públicos para informar la acción de la Junta Directiva.

    4. Renovación del Acuerdo de Registro del TLD .coop

      Visto y considerando: Que el operador de registro para .coop, DotCooperation LLC, tiene un acuerdo existente con la organización de la ICANN y está establecido que vence el 22 de noviembre de 2018.

      Visto y considerando: Que la organización de la ICANN entabló negociaciones con el operador de registro para desarrollar un acuerdo de renovación propuesto y comenzó un período de comentario público desde el 11 de junio de 2018 hasta el 27 de julio de 2018 sobre la Renovación propuesta del Acuerdo de Registro para el TLD .coop, y recibió comentarios de dos organizaciones. Se proporcionó a la Junta Directiva un resumen y análisis de los comentarios.

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

      Visto y considerando: Que la renovación al Acuerdo de Registro de .coop incluye disposiciones nuevas que son coherentes con los términos comparables del Acuerdo de Registro de Nuevos gTLD.

      Resuélvase (2018.09.16.07): Se aprueba la propuesta de Renovación del Acuerdo de Registro .coop y se autoriza al Presidente y Director Ejecutivo, o a quién este designe, a tomar las medidas apropiadas para finalizar e implementar dicho acuerdo.

      Fundamento de la resolución 2018.09.16.07

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

      La ICANN y DotCooperation LLC firmaron un Acuerdo de Registro el 1.° de julio de 2007 para el funcionamiento del dominio de alto nivel .coop. El actual Acuerdo de Registro del TLD .coop vence el 22 de noviembre de 2018 y el operador de registro tiene derecho a una renovación presunta con el acuerdo existente. La propuesta de Renovación del Acuerdo de Registro se publicó para comentario público entre el 11 de junio de 2018 y el 27 de julio de 2018. En este momento, la Junta Directiva está aprobando la propuesta de Renovación del Acuerdo de Registro de .coop para la continuidad de gestión del dominio de alto nivel .coop por parte de DotCooperation LLC.

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

      La renovación propuesta del Acuerdo de Registro del TLD .coop se basa en el actual Acuerdo de Registro del TLD .coop con las modificaciones acordadas por la organización de la ICANN y DotCooperation LLC e incluye ciertas disposiciones de la base del Acuerdo de Registro de Nuevos gTLD.

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

      La organización de la ICANN llevó a cabo un período de comentario público sobre la propuesta de renovación del Acuerdo de Registro del dominio .coop desde el 11 de junio de 2018 hasta el 27 de julio de 2018. En forma adicional, la organización de la ICANN entabló negociaciones con el Operador de Registro para acordar los términos a incluirse en la propuesta de renovación del Acuerdo de Registro de .coop, que fue publicada para la recepción de comentarios públicos.

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

      El foro de comentario público sobre la propuesta de renovación del Acuerdo de Registro de .coop finalizó el 27 de julio de 2018 y la organización de la ICANN recibió dos (2) comentarios. Los comentarios pueden resumirse en las dos categorías enumeradas a continuación.

      1. La inclusión de Mecanismos de Protección de Derechos (RPM) de nuevos gTLD y medidas de protección como los Compromisos en pos del interés público en renovaciones de acuerdos de registro de gTLD legados: en un comentario se expresó el apoyo a la inclusión en el acuerdo de renovación propuesto de ciertos mecanismos de protección de derechos, como el Sistema Uniforme de Suspensión Rápida y el Procedimiento de Resolución de Disputas por Marcas Comerciales con Posterioridad a la Delegación, además de la inclusión de los Compromisos en pos del interés público (es decir, medidas de protección) que están presentes en el Acuerdo de Registro de gTLD base. Por el contrario en un comentario se expresó la preocupación respecto de la inclusión de mecanismos de protección de derechos de gTLD base en los acuerdos legados. La explicación dada es que estas disposiciones no deben incorporarse como un resultado de las negociaciones de contrato, sino que deben tratarse a través del proceso de desarrollo de políticas ("PDP") de la GNSO.
      2. Proceso de negociación para la renovación propuesta del Acuerdo de Registro del TLD .coop y negociaciones para los acuerdos de registro de gTLD legados en general: En uno de los comentarios se expresó que .coop está haciendo la transición a las especificaciones técnicas y operativas desde el Acuerdo de Registro de gTLD base, pero mostró su descontento porque .COM y .NET no han modernizado sus términos también. En otro comentario se reiteraron las objeciones al proceso de negociación, y se afirmó que el personal de la GDD "establece unilateralmente un nuevo statu quo para los acuerdos de registro" y sustituye "su juicio (GDD) en lugar del desarrollo de políticas de la GNSO" al exceder sus "facultades y anula las medidas de protección destinadas a preservar la transparencia y la inclusión con la comunidad de múltiples partes interesadas”.

      ¿Qué materiales significativos analizó la Junta Directiva?

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

      ¿Qué factores la Junta Directiva consideró significativos?

      La Junta Directiva examinó cuidadosamente los comentarios públicos recibidos sobre la Renovación del Acuerdo de Registro de .coop, junto con el resumen y análisis de esos comentarios. La Junta Directiva también consideró los términos acordados por el Operador de Registro como parte de las negociaciones bilaterales con la organización de 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 propuesta del Acuerdo de Registro, la Junta Directiva señala que la inclusión del URS en la Renovación del Acuerdo de Registro se basa en las negociaciones entre la organización de la ICANN y el Operador de Registro, donde el Operador de Registro expresó su interés de renovar su acuerdo 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. El Equipo de Revisión de Cuestiones Específicas de Marcas Comerciales (STI) consideró este asunto y concluyó que: "El uso del URS debe constituir un RPM requerido a todos los nuevos gTLD". Es decir, la GNSO 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 organización de 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 .coop, la inclusión del URS se desarrolló como parte de la propuesta en las negociaciones entre el Operador de Registro y la organización de la ICANN.

      ¿Existen impactos positivos o negativos para la comunidad?

      La aprobación de la Renovación del Acuerdo de Registro de .coop por parte de la Junta Directiva también ofrece beneficios técnicos y operativos positivos. Por ejemplo, la Renovación del Acuerdo de Registro de .coop incluye los mismos Servicios Aprobados que se incluyen en el Acuerdo de Registro de gTLD base más el Servicio del DNS - Contenido de zona de TLD y Directorio de Dominio Activo. Además, se exigirá que DotCooperation LLC siga los mismos compromisos en pos del interés público para .coop que se establecen en el Acuerdo de Registro de gTLD base. La realización de esta medida es en pos del interés público ya que contribuye al compromiso de la organización de la ICANN de fortalecer la seguridad, estabilidad y flexibilidad del DNS.

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

      No se prevé ningún impacto fiscal significativo como consecuencia de la renovación del Acuerdo de Registro del dominio .coop.

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

      No se prevé que la renovación del Acuerdo de Registro del dominio .coop genere problemas de seguridad, estabilidad o flexibilidad relacionados con el DNS. En efecto, la renovación del Acuerdo de Registro del dominio .coop incluye términos que permiten una acción más rápida ante la ocurrencia de determinadas amenazas a la seguridad o estabilidad del DNS, además de otros beneficios técnicos con los que se pretende brindar consistencia en todos los registros en pos de un ambiente más predecible para los usuarios finales.

    5. Designación del Presidente y Presidente Electo del Comité de Nominaciones de 2019

      Visto y considerando: Que el Comité de Gobernanza de la Junta Directiva (BGC) analizó la Manifestación de Interés de los candidatos para presidente y presidente electo del Comité de Nominaciones 2019 (“NomCom”), consideró los resultados de la revisión entre pares del liderazgo del NomCom 2018 y entrevistó a los candidatos.

      Visto y considerando: Que el BGC recomendó la designación de J. Damon Ashcraft como Presidente del NomCom para el año 2019, y la designación de Cheryl Ann Miller como Presidente Electo del NomCom para el año 2019.

      Resuélvase (2018.09.16.08): Por la presente, la Junta Directiva designa a J. Damon Ashcraft como el Presidente del Comité de Nominaciones de 2019 y a Cheryl Ann Miller como el Presidente Electo del Comité de Nominaciones de 2019.

      Fundamento de la resolución 2018.09.16.08

      De acuerdo con los Estatutos de la ICANN, la Junta Directiva debe designar al presidente y al presidente electo del Comité de Nominaciones (NomCom). Ver Estatutos de la ICANN, Artículo 8, Sección 8.1. 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 13 de junio de 2018 procurando las EOI para el 2 de julio de 2018 (véase (https://www.icann.org/news/announcement-2-2018-06-13-en). Antes de hacer sus recomendaciones, el BGC recibió y examinó varias EOI, revisó los resultados de una evaluación entre pares del liderazgo del NomCom 2018 y entrevistó a los candidatos. La Junta Directiva ha sometido a consideración la recomendación del BGC respecto del Presidente y Presidente Electo para el NomCom 2019, y está de acuerdo con ella. Asimismo, la Junta Directiva desea agradecer a todos quienes manifestaron su interés en formar parte del liderazgo de NomCom 2019.

      El nombramiento de un Presidente del NomCom y Presidente Electo identificado mediante un proceso público de EOI, incluidas las entrevistas de los candidatos, sirve al interés público, ya que afecta positivamente la transparencia y la responsabilidad de la ICANN. También es plenamente coherente con la misión de la ICANN.

      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.

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

  2. Orden del día principal:

    1. Asesoramiento del GAC: Comunicado pronunciado en Panamá (junio de 2018)

      Visto y considerando: Que, el Comité Asesor Gubernamental (GAC) se reunió durante la reunión ICANN62 celebrada en Cuidad de Panamá, Panamá, y emitió su asesoramiento a la Junta Directiva de la ICANN en un comunicado [PDF, 576 KB] el 28 de junio de 2018 ("Comunicado de Panamá").

      Visto y considerando: Que el Comunicado de Panamá fue el tema de un intercambio entre la Junta Directiva y el GAC el 31 de julio de 2018.

      Visto y considerando: Que en una carta [PDF, 160 KB], con fecha del 27 de julo de 2018, el Consejo de la GNSO brindó comentarios a la Junta Directiva respecto del asesoramiento contenido en el Comunicado pronunciado en Panamá en relación a los dominios genéricos de alto nivel para informar a la Junta Directiva y la comunidad de las actividades de políticas de gTLD que pueden relacionarse con el asesoramiento brindado por el GAC.

      Visto y considerando: Que la Junta Directiva desarrolló una iteración del sistema de puntaje para responder al asesoramiento del GAC en el Comunicado pronunciado en Panamá, teniendo en cuenta el diálogo entre la Junta Directiva y el GAC, y la información proporcionada por el Consejo de la GNSO.

      Resuélvase (2018.09.16.09): La Junta Directiva adopta la tabla de calificación titulada "Asesoramiento del GAC – Comunicado pronunciado en Panamá: Acciones y Actualizaciones (16 de septiembre de 2018)" [PDF, 294 KB] en respuesta a los puntos del asesoramiento del GAC en el comunicado pronunciado en Panamá.

      Fundamento de la Resolución 2018.09.16.09

      El Artículo 12, Sección 12.2(a)(ix) de los Estatutos de la ICANN permite al GAC "exponer temas a la Junta Directiva directamente, ya sea por medio de un comentario o asesoramiento previo, o a través de recomendaciones específicas de acción, recomendaciones sobre el desarrollo de políticas nuevas o sobre la revisión de las políticas existentes”. En su Comunicado pronunciado en Panamá (28 de junio de 2018), el GAC emitió su asesoramiento a la Junta Directiva sobre: el Reglamento General de Protección de Datos (GDPR) y WHOIS, protección de nombres y acrónimos de Organizaciones Intergubernamentales. (OIG) en gTLD y códigos de país de dos caracteres en el segundo nivel. El GAC también proporcionó un seguimiento del asesoramiento anterior sobre los elementos aplazados con respecto al GDPR y WHOIS desde el Comunicado pronunciado por el GAC en San Juan. Los Estatutos de la ICANN requieren que la Junta Directiva tenga en cuenta el asesoramiento del GAC respecto de las cuestiones de políticas públicas en la formulación y adopción de políticas. Si la Junta Directiva decide llevar a cabo una acción que no se ajusta al asesoramiento del GAC, ésta deberá informarlo al GAC y explicar los motivos por los cuales ha decidido no seguir su asesoramiento. Todo asesoramiento del GAC aprobado por pleno consenso del GAC (tal como se define en los Estatutos) puede ser rechazado únicamente por una votación de no menos del 60 % de la Junta Directiva, y el GAC y la Junta Directiva entonces intentarán, de buena fe y de manera oportuna y eficaz, encontrar una solución mutuamente aceptable.

      La Junta Directiva está tomando medidas hoy para aceptar todos los elementos relacionados con el GDPR y WHOIS, y las medidas de protección para las OIG, y aplazará la consideración de los dos (2) puntos del asesoramiento relacionados con los códigos de país de dos caracteres en el segundo nivel, en espera de un debate adicional con el GAC. La Junta Directiva considerará si se necesitan acciones adicionales tras estos debates. Las acciones de la Junta Directiva se describen en la tabla de calificación con fecha del 16 de septiembre de 2018 [PDF, 294 KB].

      Al adoptar su respuesta al asesoramiento del GAC en el Comunicado pronunciado en Panamá, la Junta Directiva examinó diversos materiales, incluidos, aunque no taxativamente, los siguientes materiales y documentos:

      La adopción del asesoramiento del GAC, tal como se proporciona en la tabla de puntaje, tendrá un impacto positivo en la comunidad porque ayudará a resolver el asesoramiento del GAC respecto de los gTLD y otras cuestiones. No se observan impactos fiscales previstos asociados con la adopción de esta Resolución. La aprobación de la resolución no ocasionará impacto alguno en las cuestiones de seguridad, estabilidad o flexibilidad relacionadas con el DNS. La consideración de la Junta Directiva del asesoramiento del GAC es de interés público, en reconocimiento del rol del GAC en el asesoramiento en materia de política pública, y también es coherente con la misión de la ICANN.

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

    2. Estrategia de Servidores Raíz

      Visto y considerando: Que el enfoque actual de la ICANN de implementar un gran número de servidores individuales ("L-Individuales") y una pequeña cantidad de instalaciones más grandes con múltiples servidores ("L-Grupos") ha sido, hasta la fecha, una defensa adecuada contra los ataques en el Sistema de Servidores Raíz.

      Visto y considerando: Que el Sistemas de Servidores Raíz que se implementa actualmente es visto por muchos dentro de la comunidad técnica como un riesgo de no poder seguir el ritmo del crecimiento en la capacidad de ataque y, por lo tanto, es cada vez más vulnerable al tráfico de ataques, ya sea lanzado por entidades maliciosas o como resultado de una mala configuración, mal uso o errores.

      Visto y considerando: Que un ataque exitoso contra el Sistema de Nombres de Dominio supondría un grave riesgo para la seguridad y la estabilidad del DNS y suponen un riesgo potencialmente existencial para la organización de la ICANN, como facilitadora de la coordinación del funcionamiento y la evolución del Sistemas de Servidores Raíz del DNS.

      Visto y considerando: Que una estrategia integral destinada a reducir los efectos de los ataques contra el Sistemas de Servidores Raíz debería tener en cuenta los múltiples enfoques que aprovechan y mejoran las prácticas existentes de operadores del servidor raíz, integran nuevos avances tecnológicos y metodologías, así como también aumentan la observación y el monitoreo del sistema en su conjunto.

      Resuélvase (2018.09.16.10): Que la Junta Directiva instruya a la organización de la ICANN, como operador del Servidor Raíz/Raíz L Gestionado por la ICANN (IMRS), para trabajar con la Comunidad para finalizar una estrategia para reducir los efectos de los ataques en el IMRS y, una vez finalizado, ordene al Presidente y el Director Ejecutivo que comience con la implementación de esa estrategia mediante el desarrollo de un plan de proyecto con plazos y gastos potenciales para una posterior revisión y aprobación por parte de la Junta Directiva.

      Fundamento de la Resolución 2018.09.16.10

      Arquitectónicamente, la raíz del espacio de nombres del DNS sirve como un punto único a través del cual la búsqueda de cualquier nombre dentro de ese espacio de nombres debe pasar al menos una vez. Esto plantea el riesgo de un "único punto de falla" para todo el DNS. Hasta la fecha, este riesgo se ha mitigado al "fortalecer" la infraestructura que proporciona el servicio de nombres para esa raíz. Este fortalecimiento tradicionalmente se ha implementado mediante la expansión de la capacidad, ya sea mediante un aumento del ancho de banda para los servidores de nombres o mediante el uso del enrutamiento "anycast", con la implementación de más servidores de nombres que responden preguntas para la raíz en todo el mundo.

      Sin embargo, como resultado de la continua evolución de las tecnologías e instalaciones de Internet, en particular, el despliegue de dispositivos de "Internet de las cosas" y una mayor capacidad de las redes en todo el mundo, junto con la desafortunada falta de seguridad suficiente en esos dispositivos y redes, los atacantes tienen un poder cada vez mayor para paralizar la infraestructura de Internet. Específicamente, el crecimiento en la capacidad de ataque pone en riesgo que se supere la capacidad de la comunidad de operadores de servidores raíz para expandir la capacidad defensiva. Si bien sigue siendo necesario continuar expandiendo la capacidad defensiva en el corto plazo, la perspectiva a largo plazo para el enfoque tradicional parece desoladora.

      Además, debido a la falta de un despliegue significativo de validación de DNSSEC, las respuestas del Sistemas de Servidores Raíz continúan en riesgo de sufrir ataques de integridad. Del mismo modo, como resultado de mensajes del DNS que se supone que se envían sin cifrar, los usuarios del Sistema de Servidores Raíz (es decir, los resolutores) están sujetos a los ataques de confidencialidad. Si bien estos ataques no son necesariamente nuevos, la dependencia cada vez mayor en el DNS y, por lo tanto, el Sistemas de Servidores Raíz, sugiere una nueva estrategia para reducir el efecto de estos ataques contra el Sistemas de Servidores Raíz.

      Para cumplir con este requisito la organización de la ICANN ha ideado una estrategia integral para los Servidores Raíz Gestionados por la ICANN que, además de expandir los mecanismos de protección tradicionales existentes, busca aprovechar potencialmente la infraestructura de nube comercial y descentralizar aún más el servicio raíz, fomentar la implementación de la validación de DNSSEC, facilitar el desarrollo de mejoras de privacidad para el DNS, promover un mayor compromiso tanto con la comunidad de operadores de servidores raíz como con los operadores de resolutores, y mejorar el monitoreo del sistema raíz.

      Esta estrategia debería finalizarse con la cooperación de la comunidad y, en particular, con el RSSAC. Una vez finalizada, la implementación de la estrategia debería comenzar con el desarrollo de un plan de proyecto detallado que incluya plazos, hitos y gastos anticipados. Una vez completado el plan de proyecto, se debería proporcionar a la Junta Directiva para su revisión y aprobación.

      Se anticipa que la resolución para finalizar la estrategia raíz y desarrollar el plan de proyecto detallado necesario requerirá recursos de personal que se encuentran dentro del presupuesto actual del año fiscal 2019, por lo que no se prevé un impacto presupuestario adicional.

      Esta decisión es de interés público y se enmarca dentro de la misión de la ICANN, dado que apoya el trabajo de la organización de la ICANN para garantizar el funcionamiento estable y seguro de los sistemas de identificadores únicos de Internet.

    3. Continuación con el traspaso de la KSK

      Visto y considerando: Que la organización de la ICANN se comprometió a realizar el traspaso de la KSK "después de 5 años de funcionamiento" como se documenta en la "Declaración de Prácticas de DNSSEC para el Operador de la KSK de la Zona Raíz”.

      Visto y considerando: Que la organización de la ICANN solicitó un equipo de diseño para preparar un conjunto completo de planes con el fin de implementar el traspaso de la KSK.

      Visto y considerando: Que como parte de la implementación de dicho plan, la organización de la ICANN recopiló ciertos datos que generaron preguntas relacionadas con el impacto del traspaso de la KSK en los usuarios finales.

      Visto y considerando: Que la organización de la ICANN suspendió el traspaso el 27 de septiembre de 2017 para comprender los datos que se recopilaron.

      Visto y considerando: Que la organización de la ICANN, en consulta con los miembros de la comunidad técnica del DNS, obtuvo una mayor comprensión de los datos que se habían recopilado.

      Visto y considerando: Que la organización de la ICANN extrapoló el impacto probable del traspaso de la KSK.

      Visto y considerando: Que la organización de la ICANN ha actualizado los documentos del plan completo y ha creado el "Plan actualizado para continuar con el traspaso de la KSK raíz".

      Visto y considerando: Que la Junta Directiva ha recibido aportes del RSSAC, el RZERC y el SSAC sobre los documentos del plan y esos aportes indican que esos organismos no encontraron ninguna razón para no continuar con el plan actualizado para el traspaso de la KSK y que partes de la comunidad, en particular, aquellos miembros de la comunidad técnica del DNS, han expresado su preocupación sobre el impacto de posponer más el traspaso de la KSK, específicamente que: no avanzar con el traspaso de la KSK no estaría de acuerdo con el consenso de las expectativas de la comunidad; no es compatible con los datos obtenidos hasta la fecha; podría resultar en confusión o pérdida de atención de la comunidad a la mensajería de DNSSEC de la organización de la ICANN; podría fomentar la creencia de que la KSK nunca se traspasaría, lo que conlleva el riesgo de que la KSK actual se incruste en un sistema difícil de cambiar; y/o reducir la confianza en las DNSSEC como un sistema confiable.

      Visto y considerando: Que la cantidad anticipada de usuarios finales afectados negativamente por el traspaso de la KSK es significativamente menor que el umbral especificado por la comunidad de 0,5 % de los usuarios finales, y la identificación y remediación de ese impacto negativo debería ser directa para los afectados.

      Visto y considerando: Que la ICANN cree que los beneficios para la comunidad de proceder con el traspaso de manera oportuna superan los riesgos difíciles de cuantificar.

      Resuélvase (2018.09.16.11): Que la Junta Directiva instruye la organización de la ICANN para continuar con el traspaso de la KSK como se describe en el "Plan actualizado para continuar con el traspaso de la KSK raíz".

      Fundamento de la Resolución 2018.09.16.11

      El plan para realizar el traspaso de la KSK raíz del DNS se puso en pausa el 27 de septiembre de 2017 debido a datos inesperados, específicamente datos recibidos como resultado de implementaciones tempranas de la RFC 8145, que generó preguntas relacionadas con qué tan listos estaban los resolutores de validación para el traspaso que estaba programado para implementarse el 11 de octubre de 2017. La organización de la ICANN, entre otros, analizó esos datos y determinó que había indicios de que un porcentaje relativamente pequeño de resolutores probablemente se verían afectados negativamente por el traspaso de la KSK, sin embargo, también se estableció que los datos no eran adecuados para determinar la cantidad de usuarios finales que se verían afectados.

      En base a esa investigación, la organización de la ICANN solicitó a la comunidad técnica que recomiende un plan de acción. Si bien hubo un disenso minoritario, la mayoría de los aportes de esa comunidad indicaban que la organización de la ICANN debe continuar con el procedimiento del traspaso de la KSK de manera ordenada.

      Con ese aporte, la organización de la ICANN creó un plan resumido, titulado "Plan para continuar con el traspaso de la KSK", para realizar el traspaso de la KSK el 11 de octubre de 2018. La organización de la ICANN publicó el resumen del plan para la revisión de la comunidad el 1 de febrero de 2018 (véase <https://www.icann.org/public-comments/ksk-rollover-restart-2018-02-01-en>). El tiempo previsto para comentarios se extendió más allá del período normal de 45 días para permitir presentaciones sobre el plan en la reunión ICANN61 de San Juan y en la reunión IETF 101 de Londres y para solicitar más aportes de la comunidad en esos foros.

      El consenso de la respuesta de la comunidad recibida antes del 2 de abril de 2018 estaba a favor del plan publicado, con algunas sugerencias de difusión adicional que la organización de la ICANN ya ha realizado. En base a la respuesta de la comunidad, la organización de la ICANN creó el "Plan actualizado para continuar con el traspaso de la KSK" y revisó los documentos del plan original del traspaso de la KSK para mostrar qué pasos ya se habían realizado y qué pasos aún debían llevarse a cabo con las fechas revisadas. Esta documentación del plan está disponible en <https://www.icann.org/resources/pages/ksk-rollover-operational-plans>.

      El aporte de la comunidad sobre el plan propuesto provino de una variedad de comités asesores, grupos de partes interesadas, organizaciones y personas. La Junta Directiva solicitó aportes explícitos del RSSAC, el RZERC y el SSAC sobre el plan propuesto. Las siguientes son respuestas a la solicitud de la Junta Directiva:

      La organización de la ICANN consideró todas las conclusiones en estas tres respuestas de Comités Asesores, particularmente cualquier conclusión que dudara acerca de continuar con el traspaso. En definitiva, la organización de la ICANN interpreta esas conclusiones para indicar los riesgos de interrupción para un número muy pequeño de usuarios de Internet que quizás nunca estén preparados para un traspaso, dado que son menos que los beneficios de traspasar la KSK ahora y de forma periódica en el futuro. El material de referencia adjunto también enumera las principales objeciones al procedimiento conocidas por la organización de la ICANN junto con las respuestas a esas objeciones.

      No se prevé que el traspaso de la KSK tenga impacto fiscal alguno sobre la organización de la ICANN fuera de los recursos ya presupuestados y necesarios para el apoyo continuo del traspaso de la KSK.

      Esta decisión es de interés público y se enmarca dentro de la misión de la ICANN, dado que apoya el trabajo de la organización de la ICANN para garantizar el funcionamiento estable y seguro de los sistemas de identificadores únicos de Internet.

      Esto constituye una Función Administrativa y Organizacional que no requiere comentario público más allá de los que ya se han solicitado.

    4. Mayor consideración de las solicitudes de .AMAZON

      Visto y considerando: Que en 2012, Amazon EU S.à r.l. La empresa Amazon solicitó .AMAZON y dos versiones del Nombre de Dominio Internacionalizado (IDN) de la palabra "Amazon" ("las solicitudes de .AMAZON"). Las solicitudes de .AMAZON fueron objeto de Alertas Tempranas del Comité Asesor Gubernamental (GAC) presentadas por los gobiernos de Brasil y Perú (con el respaldo de Bolivia, Ecuador y Guyana), que notificaron a la empresa Amazon que estos gobiernos tenían una preocupación de política pública sobre las cadenas de caracteres solicitadas.

      Visto y considerando: Que en julio de 2013, en el Comunicado de Durban, las solicitudes de .AMAZON fueron objeto de un Asesoramiento consensuado del GAC que indica que las solicitudes de .AMAZON no deberían proceder. El 14 de mayo de 2014, el Comité para el Programa de Nuevos gTLD aceptó ese asesoramiento y ordenó a la organización de la ICANN que no proceda con las solicitudes de .AMAZON.

      Visto y considerando: Que en octubre de 2015, la empresa Amazon presentó una propuesta a los estados miembros de la Organización del Tratado de Cooperación Amazónica (OTCA) en un intento por llegar a una solución que pudiera beneficiar a ambas partes. Esta propuesta fue rechazada.

      Visto y considerando: Que en julio de 2017, la empresa Amazon prevaleció en un Proceso de Revisión Independiente (IRP) presentado en 2016. La declaración del IRP recomendó que la Junta Directiva "vuelva a evaluar adecuadamente las solicitudes de Amazon" y "formule un juicio objetivo e independiente con respecto a si existen razones de política pública fundadas en los méritos para rechazar las solicitudes de Amazon".

      Visto y considerando: Que el 29 de octubre de 2017, la Junta Directiva solicitó al GAC información adicional sobre el asesoramiento del GAC sobre las solicitudes de .AMAZON. En su Comunicado pronunciado en Abu Dabi en noviembre de 2017, el GAC recomendó que la Junta Directiva "continúe facilitando negociaciones entre los estados miembros de la Organización del Tratado de Cooperación Amazónica (OTCA) y la empresa Amazon con el objetivo de alcanzar una solución aceptable para ambas partes para permitir el uso de .amazon como nombre de dominio de primer nivel".

      Visto y considerando: Que, el 4 de febrero de 2018, la Junta Directiva de la ICANN aceptó el asesoramiento del GAC y le ha indicado al Presidente y Director Ejecutivo de la organización de la ICANN que "facilite las negociaciones entre los estados miembros de la Organización del Tratado de Cooperación Amazónica (OTCA) y la empresa Amazon".

      Visto y considerando: Que la empresa Amazon presentó una nueva propuesta ante el GAC y la OTCA en octubre de 2017. Después de que la empresa Amazon presentó una nueva propuesta actualizada en febrero de 2018, los estados miembros de la OTCA emitieron una declaración el 5 de septiembre de 2018, en la cual manifestaron que "…[los] países de la Amazonia han llegado a la conclusión de que la propuesta no constituye una base adecuada para proteger sus derechos inmanentes relacionados con la delegación del TLD '.amazon'". Los estados miembros de la OTCA también declararon que la delegación de .AMAZON "requiere el consentimiento de los países de la Amazonia" y que "tienen el derecho de participar en la gobernanza del TLD '.amazon'”.

      Visto y considerando: Que los estados miembros de la OTCA afirmaron en octubre de 2017 "…que el nombre Amazon, en cualquier idioma, es parte del patrimonio cultural y la identidad de los países de la Amazonia, y que su uso como nombre de dominio de primer nivel, a menos que sea acordado de otra manera por los países de la Amazonia, se reservará para la promoción de los intereses y derechos de los pueblos de la Amazonia y su inclusión en la sociedad de la información".

      Visto y considerando: Que la Junta Directiva es sensible y aprecia el trabajo de los estados miembros de la OTCA para servir el interés público de la región de la Amazonia, incluida la promoción y protección del patrimonio natural y cultural de la región de la Amazonia.

      Resuélvase (2018.09.16.12): Se ordena al Presidente y Director Ejecutivo de la ICANN respaldar el desarrollo de una solución para la delegación de las cadenas de caracteres representadas en las solicitudes de .AMAZON que incluye compartir el uso de esos dominios de alto nivel con los estados miembros de la OTCA para apoyar el patrimonio cultural de los países de la región de la Amazonia.

      Resuélvase (2018.09.16.13): La Junta Directiva ordena al Presidente y Director Ejecutivo de la ICANN, o a quien este designe, si es posible, que proporcione una propuesta a la Junta Directiva, sobre las solicitudes de .AMAZON para permitir que la Junta Directiva tome una decisión sobre la delegación de las cadenas de caracteres representadas en las solicitudes de .AMAZON.

      Resuélvase (2018.09.16.14): Se le ordena al Presidente y Director Ejecutivo de la ICANN, o a quien este designe, que proporcione actualizaciones detalladas periódicas a la Junta Directiva sobre el estado de las solicitudes de .AMAZON.

      Fundamento de las resoluciones 2018.09.16.12 – 2018.09.16.14

      Esta acción apoya la consideración de la Junta Directiva de la ICANN sobre el resultado del Proceso de Revisión Independiente (IRP) presentado por la empresa Amazon, así como la consideración del asesoramiento del Comité Asesor Gubernamental en lo que se refiere a las solicitudes de .AMAZON. La Junta Directiva está tomando esta medida hoy para avanzar con la posibilidad de la delegación de las solicitudes de .AMAZON como se contempla en la declaración del Panel del IRP, y al mismo tiempo reconocer las cuestiones de política pública planteados a través del asesoramiento del GAC sobre estas solicitudes.

      La Junta Directiva toma esta medida hoy para apoyar la continuación del trabajo que pueda dar lugar a una solución que permita que las solicitudes de .AMAZON avancen de una manera que se ajuste al asesoramiento del GAC y los aportes sobre este tema.

      Información de referencia

      La empresa Amazon solicitó .AMAZON y dos versiones del Nombre de Dominio Internacionalizado (IDN) de la palabra "Amazon" ("las solicitudes de .AMAZON"). En respuesta a las solicitudes de .AMAZON, los gobiernos de Brasil y de Perú, con el aval de Bolivia, Ecuador y Guyana, presentaron una Alerta Temprana por medio del GAC, de acuerdo con la Guía para el Solicitante, en la que declararon que: "el [o]torgamiento de derechos exclusivos para este gTLD específico a una empresa privada, evitaría el uso de este dominio para fines de interés público relacionados con la protección, la promoción y la concientización sobre las cuestiones relacionadas con el bioma amazónico. También dificultaría la posibilidad de utilizar dicho dominio para congregar a páginas web relacionadas con la población que habita en esa región geográfica". (Alerta Temprana, disponible en https://gacweb.icann.org/display/gacweb/GAC+Early+Warnings?preview=/27131927/27197938/Amazon-BR-PE-58086.pdf [PDF, 79 KB].)

      Después de indicar en su Comunicado pronunciado en Pekín (abril de 2013) que las Solicitudes de .AMAZON requerían mayor consideración de su parte, el GAC proporcionó asesoramiento consensuado (Asesoramiento del GAC) a la Junta Directiva de la ICANN en el Comunicado pronunciado en Durban (18 de julio de 2013) en el que determinada que las Solicitudes de Amazon no debían seguir adelante (https://gacweb.icann.org/display/GACADV/2013-07-18-Obj-Amazon).

      El 14 de mayo de 2014, la Junta Directiva (representada por el NGPC) aceptó el Asesoramiento del GAC e instruyó a la ICANN a no seguir adelante con las Solicitudes de Amazon. (Resolución 2014.05.14.NG03, disponible en https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-05-14-en#2.b.)

      En octubre de 2015, la empresa Amazon presentó una propuesta a los estados miembros de la Organización del Tratado de Cooperación Amazónica (OTCA) en un intento por llegar a una solución que pudiera beneficiar a ambas partes. Sin embargo, esta propuesta fue rechazada por los estados miembros de la OTCA. Posteriormente, la empresa Amazon inició un Proceso de Revisión Independiente (IRP) en marzo de 2016. El IRP finalizó en julio de 2017 con la conclusión del Panel del IRP a favor de la empresa Amazon. Tras el resultado del IRP y siguiendo las recomendaciones del GAC, la Junta Directiva de la ICANN encargó a la organización de la ICANN que apoye a la empresa Amazon y a los estados miembros de la OTCA en la negociación de una solución.

      En octubre de 2017, en la reunión ICANN60 de Abu Dabi, la empresa Amazon presentó al GAC y a los estados miembros de la OTCA una nueva propuesta para un "compromiso práctico". En febrero de 2018, en base a las negociaciones adicionales facilitadas por la organización de la ICANN, la empresa Amazon presentó una propuesta actualizada. El 5 de septiembre de 2018, tras una revisión de la propuesta por parte del Grupo de Trabajo de la OTCA, en una reunión del Consejo de Cooperación Amazónica, los estados miembros de la OTCA emitieron una declaración en la que declararon que "…[los] países de la Amazonia han llegado a la conclusión de que la propuesta no constituye una base adecuada para proteger sus derechos inmanentes relacionados con la delegación del TLD '.amazon'".

      Las propuestas de la empresa Amazon

      Desde octubre de 2015, la empresa Amazon ha presentado varias propuestas a los estados miembros de la OTCA en un esfuerzo por alcanzar una solución de mutuo acuerdo. La propuesta inicial de octubre de 2015 fue rechazada por los estados miembros de la OTCA, lo que llevó al eventual IRP que presentó la empresa Amazon. Tras la resolución del IRP, en la cual el Panel del IRP falló a favor de la empresa Amazon, en la reunión ICANN60 en Abu Dabi, la empresa Amazon presentó al GAC una nueva propuesta para un "compromiso práctico". En febrero de 2018, tras las negociaciones facilitadas por la ICANN entre la empresa Amazon y los estados miembros de la OTCA, la empresa Amazon presentó una propuesta más actualizada. Conforme a esta propuesta, la empresa Amazon propuso cuatro líneas de acción principales:

      1. Ayudar con la visibilidad global de la región de la Amazonia y sus pueblos, así como proteger su patrimonio cultural, mediante:
        1. el establecimiento de un dominio de segundo nivel acordado mutuamente para permitir la visibilidad de la región de la Amazonia. La empresa Amazon asumiría el costo del sitio web hasta USD 1 000 000 y por la duración de cuatro años.
      2. Ayudar a prevenir el uso indebido de nombres de dominio asociados con la región de la Amazonia y sus pueblos, mediante:
        1. el acuerdo de reservar una cantidad sustancial de dominios de segundo nivel en inglés, español y portugués.
      3. Crear un Comité Directivo para supervisar la implementación del acuerdo.
      4. Participar en los esfuerzos de buena voluntad al proporcionar a los estados miembros de la OTCA créditos para el uso de los servicios y productos de la empresa Amazon hasta USD 5 000 000.

      Además, la empresa Amazon propuso ayudar a los estados miembros de la OTCA a crear un programa informativo para ayudar a divulgar los beneficios del acuerdo.

      Preocupaciones de la OTCA y respuesta a las propuestas de Amazon

      Las preocupaciones de los estados miembros de la OTCA con respecto al uso del TLD .AMAZON giran en torno a la capacidad de los países y las personas de la región de la Amazonia para utilizar los nombres de dominio con fines de interés público. En una Alerta Temprana emitida por los países de Brasil y Perú en noviembre de 2012, los dos países declararon que:

      "El otorgamiento de derechos exclusivos para este gTLD específico a una empresa privada, evitaría el uso de este dominio para fines de interés público relacionados con la protección, la promoción y la concientización sobre las cuestiones relacionadas con el bioma amazónico. También dificultaría la posibilidad de utilizar dicho dominio para congregar a páginas web relacionadas con la población que habita en esa región geográfica".

      En octubre de 2017, tras la Declaración Final del Panel del IRP sobre .AMAZON, los estados miembros de la OTCA emitieron una declaración en la cual reafirmaron:

      "…que el nombre Amazon, en cualquier idioma, es parte del patrimonio cultural y la identidad de los países de la Amazonia, y que su uso como nombre de dominio de primer nivel, a menos que sea acordado de otra manera por los países de la Amazonia, se reservará para la promoción de los intereses y derechos de los pueblos de la Amazonia y su inclusión en la sociedad de la información".

      Finalmente, el 5 de septiembre de 2018, tras la propuesta actualizada presentada por la empresa Amazon en febrero de 2018, incluso después de las aclaraciones solicitadas por los estados miembros de la OTCA para comprender la propuesta, los estados miembros de la OTCA enviaron una carta a la Junta Directiva en la que indicaron, con respecto a la delegación de .AMAZON, que esto "requiere el consentimiento de los países de la Amazonia" y que ellos "tienen el derecho de participar en la gobernanza del TLD '.amazon'. Asimismo, los estados miembros de la OTCA declaran que "la propuesta no constituye una base adecuada para proteger sus derechos inmanentes relacionados con la delegación del TLD '.amazon'”.

      Sin embargo, los estados miembros mencionan que están dispuestos a "comprometerse con la Junta Directiva de la ICANN …con el fin de proteger sus derechos como estados soberanos”.

      Temas considerados por la Junta Directiva

      A la hora de adoptar esta acción, la Junta Directiva consideró lo siguiente:

      • Las propuestas de la empresa Amazon del 6 de octubre de 2015 y del 7 de febrero de 2018.
      • La Declaración del Panel del IRP en el Proceso de Revisión Independiente de .AMAZON.
      • La propuesta de la empresa Amazon de octubre de 2017 al GAC y los estados miembros de la OTCA.
      • La acción del NGPC del 14 de mayo de 2014 sobre las solicitudes de .AMAZON y las acciones de la Junta Directiva del 29 de octubre de 2017 y del 4 de febrero de 2018 sobre las solicitudes de .AMAZON.
      • Carta del 5 de septiembre de 2018 de la OTCA y anexos relacionados.

      Impactos

      Se anticipa que esta acción tendrá un pequeño impacto de recursos en la organización de la ICANN en base a los recursos necesarios para cumplir con la orden de la Junta Directiva. Sin embargo, el empleo de recursos para encontrar una solución de mutuo acuerdo es preferible a hacer frente a los posibles impactos de un continuo estancamiento en relación con la delegación de las solicitudes de .AMAZON. Esta acción es en apoyo de la misión de la ICANN, porque promueve el Programa de Nuevos gTLD y la expansión prevista del DNS. También es de interés público porque equilibra los valores fundamentales del aumento de la competencia en el DNS, sin dejar de reconocer la prestación de asesoramiento en materia de políticas públicas por parte de los gobiernos.

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

    5. Otros temas a tratar

      No se adoptó ninguna resolución.

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