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:

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-2021-03-25-en

  1. Agenda convenida:
    1. RSSAC028: Análisis técnico del esquema de nombres usado para servidores raíz individuales
    2. RSSAC047: Asesoramiento del RSSAC sobre métricas para los servidores raíz del DNS y el Sistema de Servidores Raíz
    3. Designación de los auditores independientes para el año fiscal 2021
  2. Orden del día principal:
    1. Aceptación del Informe Final de Implementación de la Segunda Revisión Organizacional del Comité Asesor de Seguridad y Estabilidad (SSAC2)
    2. Aceptación del Estudio 1 del Proyecto de Análisis de Colisión de Nombres (NCAP) y continuación del Estudio 2
    3. Fase de diseño operativo para el Sistema Estandarizado para el Acceso y la Divulgación (SSAD) a datos de registración sin carácter público
    4. Otros temas a tratar

  1. Agenda convenida:

    1. RSSAC028: Análisis técnico del esquema de nombres usado para servidores raíz individuales

      Visto y considerando: Que, el 3 de agosto de 2017, el Comité Asesor del Sistema de Servidores Raíz (RSSAC) publicó el documento RSSAC028: Asesoramiento sobre el Análisis técnico del esquema de nombres usado para servidores raíz individuales.

      Visto y considerando: Que el trabajo solicitado en el documento RSSAC028 se enmarca dentro de las competencias de la ICANN para garantizar el funcionamiento estable y seguro del sistema de identificadores únicos de Internet como parte de la misión de la ICANN.

      Visto y considerando: Que la organización de la ICANN ha evaluado la viabilidad del asesoramiento del RSSAC en el documento RSSAC028 y elaboró recomendaciones de implementación para cada punto del asesoramiento.

      Visto y considerando: Que la Junta Directiva ha considerado las recomendaciones de implementación de la organización de la ICANN relacionadas con las recomendaciones del documento RSSAC028.

      Resuélvase (2021.03.25.01): La Junta Directiva acepta la Recomendación 1, en la que se solicita que no se modifique el actual esquema de nombres utilizado en el sistema de servidores raíz hasta que se realicen más estudios.

      Resuélvase (2021.03.25.02): La Junta Directiva acepta la Recomendación 2, relativa a la realización de un estudio para comprender el comportamiento actual de los resolutores del DNS y cómo afectaría a estos comportamientos cada uno de los esquemas de nombres analizados en este documento, e instruye al Presidente y Director Ejecutivo de la ICANN, o a quien este designe, que inicie dicho estudio.

      Resuélvase (2021.03.25.03): La Junta Directiva acepta la Recomendación 3, relativa a la realización de un estudio para comprender la viabilidad y el impacto de los ataques de redelegación de nodos, e instruye al Presidente y Director Ejecutivo de la ICANN, o a quien este designe, que comience dicho estudio.

      Fundamento de las Resoluciones 2021.03.25.01 – 2021.03.25.03

      ¿Por qué la Junta Directiva aborda el tema?

      La Junta Directiva toma esta medida por recomendación del RSSAC.

      La competencia del RSSAC es asesorar a la comunidad y a la Junta Directiva de la ICANN sobre asuntos relativos a la operativa, la administración, la seguridad y la integridad del sistema de servidores raíz de Internet." Esto incluye la comunicación de los asuntos relacionados con el funcionamiento de los servidores raíz y sus múltiples instancias con la comunidad técnica y de la ICANN; la recopilación y articulación de los requisitos para ofrecerlos a quienes participan en las revisiones técnicas de los protocolos y las mejores prácticas comunes relacionadas con el funcionamiento de los servidores DNS; la participación en la evaluación continua de las amenazas y el análisis de riesgos del sistema de servidores raíz; y la recomendación de cualquier actividad de auditoría necesaria para evaluar el estado actual de los servidores raíz y la zona raíz.

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

      El Grupo de trabajo sobre de la asignación de nombres de servidores raíz del Grupo de Expertos del RSSAC investigó posibles cambios en el actual esquema de nombres de servidores raíz. Este esquema de nombres ha funcionado bien para los servidores raíz y la comunidad de Internet en general durante más de dos décadas. Sin embargo, dado el entorno actual de Internet, el RSSAC ha estudiado el esquema de nombres utilizado para los servidores raíz individuales y ha considerado las consecuencias de realizar cambios.

      El Grupo de Trabajo concluyó que podría ser beneficioso adoptar uno de los otros esquemas descritos en el documento RSSAC028 tras una investigación más profunda, pero también se recomendó que no se hicieran cambios inmediatos en los nombres de los servidores raíz en el momento de la publicación del documento de asesoramiento (Recomendación 1).

      El documento recomienda que los investigadores del DNS investiguen cuatro temas: el tamaño de respuesta aceptable para las consultas iniciales; cómo responden los resolutores cuando se les da respuestas con un conjunto acortado de registros de pegado; cómo se comportan los resolutores que validan las respuestas iniciales cuando se enfrentan a respuestas interrumpidas; y si las listas de búsqueda afectan al comportamiento inicial (Recomendación 2).

      Además, el RSSAC recomendó que se llevara a cabo un estudio para comprender la viabilidad y el impacto de los ataques de redelegación de nodos, dado que se reconoció que se requiere una investigación más profunda para comprender los ataques de redelegación de nodos, los costos y beneficios de firmar los registros A y AAAA para los servidores raíz, y los efectos de aumentar el tamaño de las respuestas de consultas iniciales (Recomendación 3).

      La recomendación 4 solicita al RSSAC que estudie las respuestas iniciales enviadas en circunstancias específicas. No hay ninguna acción para la Junta Directiva de la ICANN asociada a esta recomendación.

      La recomendación 5 se califica de "especulativa" y contiene acciones sugeridas que solo se aplican si los ataques de redelegación de nodos suponen un riesgo grave que debe mitigarse. El 28 de septiembre de 2020, el RSSAC confirmó que no hay ninguna acción para la Junta Directiva de la ICANN relacionada con esta recomendación en este momento.

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

      En el marco de las competencias del RSSAC mencionadas anteriormente, el RSSAC formó un Grupo de Trabajo de Expertos que se encargó de publicar material hasta e incluido el documento RSSAC028.

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

      Por el momento, ninguna.

      ¿Qué materiales significativos analizó la Junta Directiva?

      El Grupo de Trabajo de Expertos publicó su Declaración de Trabajo y Alcance para el Historial y el Análisis técnico del esquema de nombres usado para servidores raíz individuales el 9 de julio de 2015. La orientación que proporcionó este documento se presentó en forma de cinco puntos clave. El primer punto era "documentar el historial técnico de los nombres asignados a los servidores raíz individuales desde la creación del sistema de servidores raíz", lo que condujo a que el RSSAC emitiera el documento RSSAC023: Historia del Sistema de Servidores Raíz. Los cuatro puntos de alcance restantes proporcionaron la base para este documento de asesoramiento, RSSAC028.

      ¿Qué factores consideró importantes la Junta Directiva?

      Esta investigación facilita la evolución continua del sistema de servidores raíz.

      ¿Existen impactos positivos o negativos para la comunidad?

      La organización de la ICANN podría realizar la investigación requerida por el documento RSSAC028 para ayudar a la comunidad a decidir si recomienda o no cambiar el esquema de nombres del servidor raíz.

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

      Los recursos necesarios para los estudios de las Recomendaciones 2 y 3 (es más eficiente realizar los estudios juntos) requerirán personal y presupuesto no asignados actualmente.

      La organización de la ICANN estima que completar el estudio de la Recomendación 2 requerirá aproximadamente seis meses de tiempo de un investigador con un costo aproximado de USD 150 000, junto con un mínimo apoyo administrativo y de gestión del proyecto. Este estudio no se ha presupuestado para el año fiscal 2021.

      La organización de la ICANN estima que completar este estudio contemplado en la Recomendación 3 requeriría aproximadamente dos meses de tiempo de un investigador con un costo aproximado de USD 50 000, junto con un mínimo apoyo administrativo y de gestión del proyecto. Este estudio no se ha presupuestado para el año fiscal 2021.

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

      La investigación recomendada por el documento RSSAC028 está directamente relacionada con la garantía de la estabilidad futura del sistema de servidores raíz.

      ¿Esta decisión es de interés público y está dentro de la misión de la ICANN?

      Esto se enmarca directamente en la Declaración de la misión de la ICANN, de la Sección 1.1 de los Estatutos. MISIÓN:

      "a) La misión de la ICANN es garantizar el funcionamiento estable y seguro de los identificadores únicos de Internet

      (ii) Facilitar la coordinación del funcionamiento y la evolución del sistema del servidor de nombres raíz del DNS".

      Además, la implementación de este asesoramiento se alinea con el punto "1.2 Fortalecer la gobernanza de las operaciones del servidor raíz del DNS en coordinación con los operadores del servidor raíz del DNS" del Plan Estratégico de la ICANN para los años fiscales 2021-2025.

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

      La acción recomendada por el documento RSSAC028 no requiere un proceso de comentario público, dado que es solo una investigación. Sin embargo, una vez que se publique la investigación, habrá decisiones futuras que requerirán los aportes de la comunidad.

    2. RSSAC047: Asesoramiento del RSSAC sobre métricas para los servidores raíz del DNS y el Sistema de Servidores Raíz

      Visto y considerando: Que el documento RSSAC047, Asesoramiento del RSSAC sobre métricas para los servidores raíz del DNS y el Sistema de Servidores Raíz, publicado el 12 de marzo de 2020, recomienda un conjunto de métricas para los servidores raíz del Sistema de Nombres de Dominio (DNS), así como para el sistema de servidores raíz (RSS), y recomienda el desarrollo de sistemas para recopilar dichas métricas.

      Visto y considerando: Que, la organización de la ICANN ha desarrollado un prototipo de sistema de medición para proporcionar datos al Grupo de Expertos del RSSAC para permitir una recomendación informada sobre los umbrales de las métricas, y el RSSAC y el Grupo de Expertos del RSSAC acordaron cuatro tipos de métricas para medir con mayor precisión el rendimiento de los operadores del servidor raíz (RSO).

      Visto y considerando: Que las recomendaciones del documento RSSAC047 se enmarcan dentro de las competencias de la organización de la ICANN para garantizar el funcionamiento estable y seguro de los sistemas de identificadores únicos de Internet; y que la implementación de las recomendaciones preservaría y mejoraría aún más la estabilidad operativa, la confiabilidad, la seguridad y la interoperabilidad global de Internet y garantizaría que los nuevos gTLD se introduzcan de forma segura y estable.

      Resuélvase (2021.03.25.04): La Junta Directiva acepta la Recomendación 1, que solicita la implementación de un prototipo de sistema de medición para los RSO, y agradece a la organización de la ICANN que ya esté desarrollando dicho sistema para ayudar a definir las métricas indicadas en el documento RSSAC047.

      Resuélvase (2021.03.25.05): La Junta Directiva acepta la Recomendación 2 de implementar un sistema de medición más permanente después de establecer y utilizar el prototipo de sistema de medición de la Recomendación 1, e instruye al Presidente y Director Ejecutivo de la ICANN, o a quien este designe, que implemente dicho sistema.

      Resuélvase (2021.03.25.06): la Junta Directiva solicita al Presidente y Director Ejecutivo, o a quienes éste designe, que implemente y opere el sistema de medición descrito en la Recomendación 2.

      Fundamento de las Resoluciones 2021.03.25.04 – 2021.03.25.06

      ¿Por qué la Junta Directiva aborda el tema?

      La Junta Directiva toma esta medida por recomendación del RSSAC.

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

      El documento RSSAC047 define las mediciones, las métricas y los umbrales que los operadores de servidores raíz (RSO) deben cumplir para proporcionar un nivel mínimo de rendimiento. Los umbrales se basan en métricas técnicas diseñadas para evaluar el rendimiento, la disponibilidad y la calidad del servicio que proporciona cada identificador de servidor raíz (RSI). Los umbrales y las métricas en las que se basan se incluyen como aportes del RSSAC a un proceso de evaluación aún por definir para los RSO actuales y futuros. Las métricas definidas en el documento RSSAC047 proporcionan una forma de demostrar cuándo los RSO están, o no, cumpliendo los niveles mínimos de rendimiento. También proporcionan una forma de mostrar que el RSS en su conjunto está, o no, cumpliendo los niveles de rendimiento.

      El documento RSSAC047 contiene tres (3) recomendaciones:

      La Recomendación 1 del RSSAC047 sugiere la implementación inicial de los sistemas de medición y análisis descritos en el documento de asesoramiento. Este trabajo ya se ha completado.

      Las métricas se basan en una estrategia que consiste en realizar mediciones externas de cada identificador de servidor raíz, recopilar dichas mediciones y luego cotejarlas en informes mensuales. Los informes se presentan como aprobados/reprobados para cada métrica con respecto a un conjunto de umbrales enumerados en el documento.

      La Recomendación 2 del RSSAC047 describe un servicio a largo plazo posterior. Los detalles operativos del servicio a largo plazo pueden determinarse una vez que se tenga suficiente experiencia con la implementación inicial del prototipo descrito en la Recomendación 1. En base a esta experiencia operativa con el sistema prototipo, la organización de la ICANN puede determinar cómo y cuándo se pondrá en marcha la implementación oficial. Es posible que la organización de la ICANN determine que el sistema prototipo cumple con todos los requisitos descritos en el documento RSSAC047 y es adecuado para su uso a largo plazo.

      La Recomendación 3 del RSSAC047 requiere trabajo adicional en el futuro y, por lo tanto, no implica ninguna acción para la Junta Directiva en este momento. El trabajo futuro lo iniciaría el RSSAC (o una organización sucesora como resultado de la implementación de las recomendaciones del documento RSSAC038), y se realizaría en colaboración con la organización de la ICANN y la comunidad de Internet.

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

      El documento RSSAC047 fue creado y editado por el Grupo de Expertos del RSSAC, que está formado por docenas de expertos de la comunidad en general. El RSSAC presentó este documento de asesoramiento en su calidad de asesor de la comunidad y la Junta Directiva de la ICANN en asuntos relacionados con el funcionamiento, la administración, la seguridad y la integridad del sistema de servidores raíz de Internet.

      Hubo un fuerte acuerdo en el Grupo de Expertos del RSSAC en cuanto a que los cuatro tipos de métricas identificadas en el documento conforman el conjunto correcto para las mediciones externas de los RSO.

      La organización de la ICANN ya ha trabajado con el RSSAC en un prototipo de sistema de medición del rendimiento de los RSO para proporcionar datos que se consideren para ayudar al desarrollo de las métricas descritas en el documento RSSAC047.

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

      Ninguna inquietud.

      ¿Qué materiales significativos analizó la Junta Directiva? ¿Qué factores consideró importantes la Junta Directiva?

      Este trabajo es iniciativa del documento RSSAC037: Modelo de Gobernanza Propuesto para el Sistema de Servidores Raíz del DNS. Aunque no depende de la implementación del documento RSSAC037, este trabajo puede informar el trabajo de implementación del RSSAC037 de las siguientes maneras:

      • Una futura manifestación de la Función de Seguimiento y Medición del Rendimiento (PMMF) podría utilizar las métricas y los umbrales técnicos definidos en este informe como punto de partida para definir sus reglas para evaluar el rendimiento, la disponibilidad y la calidad del servicio que proporciona cada RSO, aportando así responsabilidad técnica a los RSO.
      • El documento RSSAC037 establece que deben existir Expectativas de Nivel de Servicio (SLE) entre las partes interesadas que aportan financiación y los RSO que la reciben. Las métricas y los umbrales para los RSO que se definen en este informe pueden utilizarse como punto de partida para posteriores debates sobre los requisitos técnicos y de rendimiento en las SLE.

      En segundo lugar, aunque este informe se centra solo en las expectativas mínimas de rendimiento, el RSSAC reconoce que, con la evolución del modelo de gobernanza, los RSO pueden celebrar futuros contratos de servicio que podrían incluir acuerdos de nivel de servicio (SLA). El RSSAC espera que las métricas aquí definidas sean útiles en el contexto de un SLA. En base a los debates llevados a cabo durante la elaboración de este informe, el RSSAC prevé además que los umbrales de los SLA sean más estrictos (si fuera posible) que los que se proporcionan aquí.

      En tercer lugar, las métricas y los umbrales definidos en este informe también pueden ser utilizados por los RSO, entre otros, para identificar situaciones en las que el RSS en su conjunto se esté degradando en cuanto a su rendimiento, y sea necesario tomar medidas colectivamente.

      ¿Qué factores consideró importantes la Junta Directiva?

      La organización de la ICANN ya ha trabajado con el RSSAC en un prototipo de sistema de medición del rendimiento de los RSO para proporcionar datos que se consideren para ayudar al desarrollo de las métricas descritas en el documento RSSAC047.

      ¿Existen impactos positivos o negativos para la comunidad?

      Las métricas aquí definidas permiten a la comunidad determinar si hay RSO que no cumplen con los niveles mínimos de rendimiento. La comunidad puede entonces trabajar con el RSSAC, o a través de otros mecanismos de la comunidad, para abordar esta cuestión.

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

      La implementación de la Recomendación 1 y, eventualmente, de la Recomendación 2, requiere el tiempo de la organización de la ICANN y una pequeña cantidad de gastos operativos continuos. Estos costos se incorporan al presupuesto de la OCTO como parte de sus actividades normales.

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

      Las métricas aquí definidas proporcionan una forma de mostrar que el RSS en su conjunto está, o no, cumpliendo los niveles de rendimiento. La implementación de este asesoramiento se enmarca dentro de las competencias de la ICANN, dado que implica la creación de sistemas que la comunidad puede utilizar para realizar evaluaciones del RSS.

      ¿Esta decisión es de interés público y está dentro de la misión de la ICANN?

      Sí. El documento RSSAC047 define las mediciones, las métricas y los umbrales que los operadores de servidores raíz (RSO) deben cumplir para proporcionar un nivel mínimo de rendimiento. Esto se enmarca directamente en la Declaración de la misión de la ICANN, de la Sección 1.1 de los Estatutos. MISIÓN:

      "a) La misión de la ICANN es garantizar el funcionamiento estable y seguro de los identificadores únicos de Internet

      (ii) Facilitar la coordinación del funcionamiento y la evolución del sistema del servidor de nombres raíz del DNS".

      Además, la implementación de este asesoramiento se alinea con el punto "1.2 Fortalecer la gobernanza de las operaciones del servidor raíz del DNS en coordinación con los operadores del servidor raíz del DNS" del Plan Estratégico de la ICANN para los años fiscales 2021-2025.

    3. Designación de los auditores independientes para el año fiscal 2021

      Visto y considerando: Que el Artículo 22, Sección 22.2 de los Estatutos de la ICANN (http://www.icann.org/general/bylaws.htm) exige que, después de finalizar el año fiscal, los libros contables de la ICANN sean auditados por contadores públicos certificados a ser designados por la Junta Directiva.

      Visto y considerando: Que el Comité de Auditoria de la Junta Directiva ha analizado la participación del auditor independiente para el año fiscal que termina el día 30 de junio de 2021 y ha recomendado que la Junta Directiva autorice al Presidente y Director Ejecutivo, o a quien este designe, tome todas las medidas necesarias para la participación de BDO USA, LLP y las empresas miembros de BDO.

      Resuélvase (2021.03.25.07): La Junta Directiva autoriza al Presidente y Director Ejecutivo, o a quien este designe, a contratar a BDO USA, LLP y a las empresas miembros de BDO como empresas auditoras de los estados contables del año fiscal que finaliza el día 30 de junio de 2021.

      Fundamento de la resolución 2021.03.25.07

      La firma de auditoria BDO USA LLP y las firmas miembros de BDO han sido las empresas de auditoría independientes de la ICANN desde la auditoria del año fiscal 2014. En el año 2019, se realizó una rotación de socios y se asignó un nuevo socio auditor para su participación en la ICANN. Sobre la base del informe de la organización y la evaluación realizada por el Comité de Auditoria del trabajo realizado, el comité recomendó a la Junta Directiva autorice al Presidente y Director Ejecutivo (CEO), o a quien este designe, instrumentar los pasos necesarios para contratar a BDO USA, LLP y a las empresas miembros de BDO como empresas auditoras independientes de la ICANN para el año fiscal 2021 para todo requisito de auditoría independiente en cualquier jurisdicción.

      Esto promueve la responsabilidad de la ICANN en relación con sus estatutos y procesos, y los resultados del trabajo de los auditores independientes estarán públicamente disponibles. Esta decisión está en consonancia con la misión de la ICANN y es en pos del interés público porque la contratación de un auditor independiente se realiza en cumplimiento de las obligaciones de la ICANN de auditar los libros contables de la corporación y ayuda a que las partes interesadas de la ICANN se desempeñen de manera más responsable.

      Esta decisión tendrá un impacto fiscal en la ICANN, que se contabiliza en el Plan Operativo y Presupuesto de la ICANN. Esta decisión no debería tener ningún impacto directo en la seguridad, estabilidad o flexibilidad del sistema de nombres de dominio.

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

  2. Orden del día principal:

    1. Aceptación del Informe Final de Implementación de la Segunda Revisión Organizacional del Comité Asesor de Seguridad y Estabilidad (SSAC2)

      Visto y considerando: Que, el 12 de marzo de 2020, la Junta Directiva aceptó el Plan detallado de implementación de la Revisión SSAC2 e instruyó al Grupo de Trabajo de la Revisión SSAC2 para que presentara a la Junta Directiva informes periódicos sobre las actividades de implementación.

      Visto y considerando: Que el Grupo de Trabajo para la Revisión del Comité Asesor de Seguridad y Estabilidad (SSAC2 RWP), con la aprobación y supervisión del SSAC, suministró a la Junta Directiva a través del Comité de Efectividad Organizacional de la Junta Directiva (OEC) actualizaciones semestrales sobre el progreso de las iniciativas de implementación hasta el momento en que dichos esfuerzos concluyeron.

      Visto y considerando: Que el SSAC2 RWP, presentó un Informe Final de Implementación, el 3 de diciembre de 2020, en el que se detalla la finalización de la implementación de las recomendaciones derivadas de la segunda Revisión del SSAC y se documenta que tres recomendaciones1 tienen componentes limitados que aún no se han implementado completamente. El OEC reconoció que los pasos restantes del trabajo de implementación de la Revisión SSAC2 tienen dependencias que escapan al control del SSAC.

      Visto y considerando: Que el OEC recomienda que la Junta Directiva acepte el Informe Final de Implementación de la Revisión SSAC2 presentado por el SSAC2 RWP y aprobado por el SSAC el 3 de diciembre de 2020, completando así la segunda Revisión del SSAC; y solicita que el SSAC proporcione una actualización escrita u oral al OEC antes del 30 de junio de 2021 sobre las tres recomendaciones con componentes limitados cuya implementación aún no se ha completado totalmente y, si no se ha completado para entonces, cada seis meses a partir de entonces hasta que se complete la implementación en su totalidad.

      Resuélvase (2021.03.25.08): La Junta Directiva acepta el Informe final de implementación de la segunda Revisión del SSAC presentado por el SSAC RWP aprobado por el SSAC, que marca la finalización de esta revisión organizacional de acuerdo con el Artículo 4, Sección 4.4 de los Estatutos. La Junta Directiva alienta al SSAC a seguir supervisando el impacto de la implementación de las recomendaciones de la segunda Revisión del SSAC como parte de su proceso continuo de mejora.

      Resuélvase (2021.03.25.09): La Junta Directiva reconoce el arduo trabajo de implementación del SSAC RWP con el objetivo de mejorar la eficacia, transparencia y responsabilidad del SSAC, en concordancia con el plazo propuesto que se estipuló en el Plan Detallado de Implementación de la Revisión SSAC2.

      Resuélvase (2021.03.25.10): La Junta Directiva solicita al SSAC que proporcione al OEC una actualización escrita u oral de los avances en los componentes restantes de las tres recomendaciones cuya aplicación no se ha completado totalmente. En caso de que la implementación no se haya completado para el 30 de junio de 2021, el SSAC continuará proporcionando dichas actualizaciones al OEC cada seis meses hasta que concluyan los esfuerzos de implementación.

      Fundamento de las Resoluciones 2021.03.25.08 – 2021.03.25.10

      ¿Por qué la Junta Directiva aborda el tema?

      La ICANN organiza revisiones independientes de sus organizaciones de apoyo y comités asesores tal como se estipula en el Artículo 4, sección 4.4 de los Estatutos de la ICANN, a fin de garantizar que el modelo de múltiples partes interesadas de la ICANN siga siendo transparencia y responsable, y para mejorar su desempeño.

      Esta acción completa la segunda revisión del SSAC y se basa en el Informe Final de Implementación, aprobado por el SSAC.

      Después de la evaluación de todos los documentos pertinentes por parte del Comité de Efectividad Organizacional (OEC), la Junta Directiva ahora se encuentra en la posición de considerar y aceptar el Informe Final de Implementación.

      Información de referencia: La entidad examinadora independiente comenzó su trabajo en marzo de 2018 y publicó su Informe Final en diciembre de 2018, en el cual incluyó 30 recomendaciones. El SSAC publicó su Estudio de factibilidad y plan de implementación inicial en mayo de 2019, y la Junta Directiva aceptó ambos e indicó que la planificación de la implementación comenzara en junio de 2019. La Junta Directiva aceptó el Plan de Implementación Detallado en marzo de 2020. Se debe tener en cuenta que seis recomendaciones y/o cuestiones subyacentes proporcionadas por la entidad examinadora independiente no fueron respaldadas por el SSAC y, en consecuencia, estas recomendaciones no se incluyeron en el Plan de Implementación Detallado ni en el Informe de Implementación Final (Recomendaciones 7, 13, 17, 21, 22 y 23).

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

      El SSAC RWP presentó su Informe Final de Implementación al OEC el 3 de diciembre de 2020. El Informe Final de Implementación indica que las 24 recomendaciones aceptadas por la Junta Directiva han sido completadas o integradas en los procesos en curso del SSAC, como se documenta en los Procedimientos Operativos del SSAC.

      En particular, la labor de implementación de doce recomendaciones dio lugar a la modificación de varias secciones de los Procedimientos Operativos del SSAC publicados el 12 de febrero de 2020: Secciones 2.1.2 (Retiros y disentimientos)2, 2.3 (Selección de nuevos miembros)3, 2.5 (Proceso de revisión anual)4, 2.6.1 (Afirmación de confidencialidad y no divulgación)5, 2.8.1 (Funciones del SSAC - Presidente)6, 2.8.3 (Funciones del SSAC - Enlaces externos del SSAC)7, 3.1 (Procedimientos de publicación del SSAC - Proponer, seleccionar y planificar un producto de trabajo)8, 3.2.4 (Procedimientos de publicación del SSAC - Estudio y trabajo primario - Revisión preliminar)9, 3.4 (Publicación, promulgación y publicidad)10, 3.5 (Trazabilidad, revisión y seguimiento)11, Apéndices B y F12.

      Estas doce recomendaciones abarcan diversos aspectos de la operativa del SSAC:

      • documentar las revisiones y comentarios del Coordinador de enlace con la Junta Directiva (recomendación 3),
      • capturar información en el Registro de Solicitudes de Acción (ARR) de la Junta Directiva (recomendación 4),
      • revisar el estado de implementación del asesoramiento pasado y futuro proporcionado a la Junta Directiva de la ICANN (recomendación 5),
      • formalizar un proceso anual para establecer las prioridades de investigación e identificar las amenazas de SSR (recomendación 8),
      • actualizar las aptitudes en los procesos de incorporación de miembros y reclutamiento del SSAC (recomendación 9),
      • comunicar las decisiones (recomendación 10),
      • analizar explícitamente quiénes pueden ser las partes afectadas en el documento de la serie SAC (recomendación 16),
      • identificar las carencias en materia de aptitudes de los miembros actuales (recomendación 24),
      • desarrollar un proceso formalizado para estimar su diversidad actual y deseada (recomendación 25),
      • garantizar que se revise periódicamente la eficacia de un coordinador de enlace externo y de la persona que desempeña la función (recomendación 26),
      • y limitar los cargos de los líderes del SSAC a dos mandatos de tres años, y no imponer límites de mandato a los miembros que no son líderes (recomendación 27).

      Además, la implementación de la recomendación 28 dio lugar a una enmienda de los Estatutos para limitar el mandato del Presidente del SSAC. Esto sugiere que el impacto de la implementación de estas recomendaciones continuará como parte de los procesos en curso, apoyando la orientación de mejora continua del SSAC a medida que se pongan en funcionamiento y se continúen siguiendo los procedimientos modificados en el futuro.

      El SSAC RWP informó que ocho recomendaciones (1, 2, 11, 14, 15, 19, 20 y 30) no requerían trabajo de implementación porque los pasos recomendados ya forman parte de los procesos y operaciones del SSAC.

      Además, los componentes limitados del trabajo de implementación de las recomendaciones 18, 24 y 25 dependen de factores que escapan al control del SSAC. Las recomendaciones se refieren a la consolidación de la información en línea y el aumento de la transparencia (recomendación 18), la identificación de la brecha de aptitudes en los miembros actuales (recomendación 24), el desarrollo de un proceso formalizado para estimar su diversidad actual y deseada (recomendación 25) y, si bien se implementó un trabajo significativo, los componentes de estas recomendaciones no pueden considerarse completamente implementados debido a la falta de publicación de fotografías de los miembros del SSAC en la página web pública del SSAC (recomendación 18), y la falta de oportunidades presenciales debido a las cancelaciones por COVID-19 de las reuniones de la ICANN (recomendaciones 24, 25). Sin embargo, el SSAC tiene planificado abordar el último componente de la recomendación 18 una vez que se publique la nueva página web pública del SSAC, y también se contactará con el personal regional de la ICANN para ayudar en la difusión relacionada con la implementación de las recomendaciones 24 y 25.

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

      La Junta Directiva, a través del OEC, consultó al SSAC RWP, que estaba a cargo de la implementación, y supervisó el progreso de la revisión así como el progreso de la implementación de las recomendaciones de la revisión.

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

      El trabajo de implementación que realizó el SSAC cumplió con sus mejores prácticas estándar para garantizar la transparencia y la responsabilidad. La comunidad no planteó ninguna inquietud.

      ¿Qué materiales significativos analizó la Junta Directiva?

      La Junta Directiva revisó las secciones de los Estatutos pertinentes, la documentación del Proceso de Revisión Organizacional, el Plan de Implementación de la Revisión SSAC2, su primer informe de progreso semestral de la implementación y el informe final de implementación.

      ¿Qué factores consideró importantes la Junta Directiva?

      La Junta consideró que varios factores eran importantes, los que contribuyen a la finalización eficaz del trabajo de implementación:

      • Compromiso del SSAC con su mejora continua.
      • Formación de un grupo dedicado que supervise la implementación de las recomendaciones aceptadas por la Junta Directiva.
      • Cumplimiento del plan de implementación que incluía un plazo para la implementación, definición de los resultados deseados y formas de medir el estado actual y el progreso hacia el resultado deseado.
      • Informes oportunos y exhaustivos sobre el progreso de la implementación

      ¿Existen impactos positivos o negativos para la comunidad?

      Se prevé que esta acción de la Junta Directiva tendrá un impacto positivo sobre la comunidad al reconocer y destacar una finalización eficaz de la implementación de las recomendaciones de la Revisión SSAC2. La implementación completada de la revisión organizacional SSAC2 demuestra el compromiso del SSAC con la mejora continua.

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

      Se prevé que esta acción de la Junta Directiva no tenga ningún impacto fiscal adicional. La Junta Directiva observa que la mayoría de las recomendaciones requieren la ayuda del personal de apoyo del SSAC de la organización de la ICANN para su ejecución, lo cual se haría como parte de las tareas habituales del personal de apoyo. Se prevé que las ramificaciones de esta resolución en la organización de la ICANN, la comunidad y el público serán positivas, dado que esta acción de la Junta Directiva significa un importante hito para las revisiones organizacionales.

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

      No se prevé que esta acción de la Junta Directiva tenga algún efecto en las cuestiones de seguridad, estabilidad y flexibilidad relacionadas con el DNS.

      ¿Cómo se ajusta esta acción dentro de la misión de la ICANN y cuál es el interés público que se beneficia con esta acción?

      La acción de la Junta Directiva es coherente con el compromiso de la ICANN conforme al Artículo 4, Sección 4.1 de los Estatutos para garantizar que el modelo de múltiples partes interesadas de la ICANN siga siendo transparente y responsable, y para mejorar el desempeño de sus organizaciones de apoyo y comités asesores. Esta acción será en beneficio del interés público porque cumple con el compromiso de la ICANN de mantener y mejorar su responsabilidad y transparencia.

      ¿Se requieren comentarios públicos antes de que la Junta Directiva adopte la acción?

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

    2. Aceptación del Estudio 1 del Proyecto de Análisis de Colisión de Nombres (NCAP) y continuación del Estudio 2

      Visto y considerando: Que, en 2017, la Junta Directiva aprobó las resoluciones 2017.11.02.29 - 2017.11.02.31 en las que se formulaban una serie de preguntas sobre las colisiones de nombres.

      Visto y considerando: Que el Comité Asesor de Seguridad y Estabilidad (SSAC) de la ICANN respondió con una propuesta de tres estudios destinados a abordar las preguntas de la Junta Directiva.

      Visto y considerando: Que el SSAC y la Oficina del Director de Tecnologías (OCTO) dentro de la organización de la ICANN trabajaron juntos para producir una propuesta revisada de mutuo acuerdo para el Estudio 1 del NCAP.

      Visto y considerando: Que, en abril de 2019, la Junta Directiva instruyó a la organización de la ICANN para que procediera con el Estudio 1 del NCAP y autorizó los gastos asociados para dicho fin.

      Visto y considerando: Que la organización de la ICANN contrató a Scarfone Cybersecurity, un contratista independiente, para investigar y redactar el Estudio 1 del NCAP.

      Visto y considerando: Que, el 30 de junio de 2020, la organización de la ICANN envió la versión final del Estudio 1 del NCAP al Comité Técnico de la Junta Directiva (BTC) después de dos períodos de comentarios públicos sobre la versión preliminar y las versiones finales del informe.

      Visto y considerando: Que el Estudio 1 del NCAP recomendó que los Estudios 2 y 3 del NCAP no siguieran adelante tal y como están diseñados actualmente.

      Visto y considerando: Que el Grupo de Discusión (DG) del NCAP revisó el diseño del Estudio 2 del NCAP para tener en cuenta las cuestiones que se plantearon en el Estudio 1 del NCAP.

      Visto y considerando: Que, el 5 de febrero de 2021, los líderes del Grupo de Discusión del NCAP presentaron el diseño revisado del Estudio 2 del NCAP al BTC para su aprobación.

      Resuélvase (2021.03.25.11): La Junta Directiva reitera su agradecimiento al SSAC por su trabajo para responder a la resolución de noviembre de 2017 y por desarrollar una propuesta inicial para el Proyecto de Análisis Colisiones de nombres (NCAP) y las revisiones posteriores a esa propuesta.

      Resuélvase (2021.03.25.12): La Junta Directiva agradece al Grupo de Discusión del NCAP sus contribuciones al Estudio 1 del NCAP.

      Resuélvase (2021.03.25.13): La Junta Directiva afirma que siguen siendo pertinentes las nueve preguntas relacionadas con las colisiones de nombres presentadas en las resoluciones de la Junta Directiva 2017.11.02.29 - 2017.11.02.31, especialmente las preguntas (7) y (8) relativas a los criterios para identificar las cadenas de caracteres de colisión y determinar si las cadenas de caracteres de colisión son seguras para ser delegadas.

      Resuélvase (2021.03.25.14): La Junta Directiva instruye al Grupo de Discusión del NCAP que proceda con el Estudio 2 tal y como ha sido rediseñado, e instruye al Presidente y Director Ejecutivo, o a quien este designe, que participe en el Estudio 2 de la manera indicada en la propuesta rediseñada.

      Fundamento de las Resoluciones 2021.03.25.11 – 2021.03.25.14

      La colisión de nombres se refiere a la situación en la que un nombre definido y utilizado en un espacio de nombres puede aparecer también en otro. En este contexto, un "espacio de nombres" se refiere a todos los nombres posibles que pueden resolverse, por ejemplo, el espacio de nombres del DNS público administrado por la ICANN a través de las funciones de la IANA o un espacio de nombres "privado" limitado a una red empresarial. Los usuarios y las aplicaciones que pretenden utilizar un nombre en un espacio de nombres pueden intentar utilizarlo en otro diferente (normalmente de forma accidental debido a errores de configuración), y puede producirse un comportamiento inesperado cuando el uso previsto del nombre no es el mismo en ambos espacios de nombres. Un ejemplo de colisión de nombres fuera del DNS sería la comparación de gritar el nombre de una persona común en un entorno cerrado, como el comedor de una empresa, frente a gritar ese nombre en un espacio público lleno de gente: en el primer caso, es probable que la persona prevista responda, mientras que en el segundo caso, pueden responder varias personas.

      El 2 de noviembre de 2017, la Junta Directiva de la ICANN aprobó las resoluciones 2017.11.02.29 - 2017.11.02.31 en las que se solicitaba al SSAC que realizara estudios para presentar datos, análisis y puntos de vista, y que proporcionara asesoramiento a la Junta Directiva en relación con los riesgos que suponían para los usuarios y los sistemas finales si las cadenas de caracteres .CORP, .HOME, .MAIL se delegaban en la raíz, así como posibles líneas de actuación que pudieran mitigar los riesgos identificados. La Junta Directiva también formuló nueve preguntas relacionadas con la definición de colisión de nombres, la experiencia del usuario y posibles perjuicios, las causas de las colisiones, los riesgos potenciales y las posibles mitigaciones, entre otros temas relacionados con las colisiones de nombres.

      Tras la resolución de la Junta Directiva, el SSAC comenzó la planificación del proyecto en diciembre de 2017 para el trabajo necesario para abordar las solicitudes de la Junta Directiva. En enero de 2018, se formó el Grupo de Trabajo para el NCAP del SSAC ("NCAP WP"), que elaboró un plan en el que se solicitaban tres estudios. También se creó la Administración del NCAP ("NCAP Admin"), un grupo más pequeño compuesto por los líderes del NCAP WP y los líderes del SSAC, que dirige las iniciativas del NCAP tanto dentro del SSAC como en la comunidad más amplia de la ICANN.

      En junio de 2018, el Director Ejecutivo de la organización de la ICANN, tras los aportes de la Junta Directiva, asignó a la OCTO la responsabilidad de completar los estudios del NCAP, dado que el SSAC no tenía la infraestructura administrativa ni los recursos para emprender y gestionar un proyecto tan grande.

      En septiembre de 2018, el SSAC publicó la "Propuesta del SSAC para el Proyecto de Análisis de Colisiones de Nombres", que proponía tres estudios consecutivos para atender la solicitud de la Junta Directiva. La OCTO propuso cambios menores a la propuesta y, tras el debate entre el SSAC y la OCTO, se publicó una versión actualizada de la propuesta en febrero de 2019.

      En abril de 2019, se formó el Grupo de Discusión del NCAP para permitir que los miembros interesados de la comunidad más amplia de la ICANN también participaran en la iniciativa del NCAP. El Grupo de Discusión del NCAP está formado tanto por el NCAP WP del SSAC como por cualquier miembro interesado de la comunidad.

      Debido a las limitaciones de recursos, la OCTO decidió subcontratar a un proveedor para la realización del Estudio 1. El 9 de julio de 2019, se publicó una RFP para el trabajo y, en septiembre de 2019, se seleccionó a Scarfone Cybersecurity de acuerdo con los procesos de adquisición estándar de la organización de la ICANN. El Estudio 1 fue el resultado de un esfuerzo de colaboración entre Scarfone Security, el Grupo de Discusión del NCAP y la organización de la ICANN. Cada versión preliminar del estudio durante cada procedimiento de comentario público recibió varios comentarios y puntos de debate antes de la publicación del informe final. El informe final del Estudio 1 se publicó el 19 de junio de 2020.

      Las principales conclusiones del Estudio 1 pueden resumirse a continuación:

      1. Las colisiones de nombres son un problema conocido desde hace décadas, pero los trabajos publicados no empezaron a aparecer hasta 2012. El único trabajo conocido sobre colisiones de nombres en los últimos años ha sido realizado dentro de la comunidad de la ICANN por el Grupo de Discusión del NCAP y el Grupo de Trabajo para el PDP sobre Procedimientos Posteriores a la Introducción de los Nuevos gTLD ("SubPro WG").
      2. Se informaron pocos casos de colisiones de nombres a la ICANN o públicamente desde que se instituyó la interrupción controlada. Solo uno de los informes enviados a la ICANN requirió la intervención de un registro, y ninguno de los informes públicos analizados mencionó perjuicios significativos a personas u organizaciones.
      3. Existen varias causas principales de las colisiones de nombres, pero normalmente se han encontrado mediante la investigación de un TLD específico filtrado, no examinando conjuntos de datos.
      4. No se identificaron deficiencias ni otros problemas para acceder a los conjuntos de datos que se necesitarían para los Estudios 2 y 3.

      El Estudio 1 además establece lo siguiente:

      Frente a estos resultados, la recomendación es que los Estudios 2 y 3 no se realicen tal y como están diseñados actualmente. En lo que respecta al Estudio 2, es poco probable que el análisis de los conjuntos de datos identifique causas fundamentales significativas de las colisiones de nombres que no hayan sido ya identificadas. Es mucho más probable que se encuentren nuevas causas de colisiones de nombres investigando los candidatos a TLD para una potencial delegación caso por caso. Con respecto al Estudio 3, la interrupción controlada ya ha demostrado ser una estrategia de mitigación efectiva, y no parece ser necesario identificar, analizar y probar alternativas para la gran mayoría de los candidatos a TLD. (Resumen ejecutivo, p. V)

      En respuesta a los resultados del Estudio 1, el Grupo de Discusión del NCAP rediseñó el Estudio 2 e introdujo varios cambios importantes: (1) la eliminación de dos objetivos originales del estudio, (2) la ampliación y adición de detalles de otros objetivos del estudio, y (3) la realización por parte del Grupo de Discusión del NCAP de la mayor parte del trabajo que en la versión original de la propuesta del Estudio 2 estaba destinado a contratistas remunerados. Estas modificaciones reducen drásticamente el alcance, el nivel de esfuerzo, los costos totales y los recursos necesarios para ejecutar el Estudio 2.

      El Grupo de Discusión del NCAP se encargará de una parte importante del trabajo del Estudio 2 rediseñado, mientras que la ICANN proporcionará apoyo a la gestión del proyecto y contratará a un redactor técnico y a un investigador técnico para que ayuden en la elaboración del Estudio. Los costos estimados para la organización de la ICANN para el Estudio 2 rediseñado están por debajo del umbral requerido para la aprobación de la Junta Directiva y, por tanto, no se describen aquí.

      El BTC afirma que las cuestiones relacionadas con las colisiones de nombres planteadas en las resoluciones de la Junta Directiva 2017.11.02.29 - 2017.11.02.31 siguen siendo pertinentes. El BTC subraya la especial importancia de las preguntas (7) y (8) relativas a los criterios para identificar las cadenas de colisión y determinar si las cadenas de colisión son seguras para ser delegadas.

      Se prevé que la acción de la Junta Directiva tenga un impacto positivo en la seguridad, la estabilidad y la resiliencia del DNS de Internet, dado que ha sido diseñada para continuar estudiando las colisiones de nombres. Esta acción también cumple la misión de la ICANN de garantizar un funcionamiento seguro y estable de los sistemas de identificadores únicos de Internet. Esta resolución es de interés público ya que cumple con el valor fundamental de la ICANN de preservar y mejorar la administración del DNS y la estabilidad operativa, confiabilidad, seguridad, interoperabilidad global, flexibilidad y apertura del DNS e Internet.

      La acción de la Junta Directiva forma parte de las funciones administrativas y organizacionales que no requieren comentario público.

    3. Fase de diseño operativo para el Sistema Estandarizado para el Acceso y la Divulgación (SSAD) a datos de registración sin carácter público

      Visto y considerando: Que, el 24 de septiembre de 2020, el Consejo de la GNSO votó para aprobar todas las recomendaciones de su Informe final sobre la Fase 2 del Proceso Expeditivo de Desarrollo de Políticas (EPDP) sobre la Especificación Temporaria para los Datos de Registración de los gTLD.

      Visto y considerando: Que la Junta Directiva ha comenzado sus deliberaciones para considerar si las recomendaciones del Informe Final de la Fase 2 del EPDP sean en beneficio de los intereses de la ICANN o de la comunidad de la ICANN.

      Visto y considerando: Que la Junta Directiva desea utilizar el proceso de la Fase de Diseño Operativo recientemente desarrollado para evaluar las recomendaciones y reunir más información como parte de sus deliberaciones.

      Visto y considerando: Que la Junta Directiva observa que el 5 de mayo de 2020 se publicó un documento para debate: Estimación de costos de la organización de la ICANN para el Sistema Estandarizado para el Acceso/Divulgación propuesto por el equipo de la Fase 2 del EPDP que la organización de la ICANN proporcionó al Grupo de Trabajo para la Fase 2 del Proceso Expeditivo de Desarrollo de Políticas (EPDP) sobre la Especificación Temporaria para los Datos de Registración de los gTLD en el cual se incluía una estimación de los costos asociados con la puesta en marcha y las operaciones continuas relacionadas con los requisitos del sistema propuesto por el equipo durante el Proceso de Desarrollo de Políticas.

      Resuélvase (2021.03.25.15): La Junta Directiva instruye al Presidente y Director Ejecutivo, o a quien este designe, que proceda con la Fase de Diseño Operativo para las recomendaciones aprobadas por el Consejo de la GNSO (1-18) del Informe Final de la Fase 2 del EPDP sobre el Sistema Estandarizado de Acceso y Divulgación.

      Resuélvase (2021.03.25.16): La Junta Directiva instruye al Presidente y Director Ejecutivo, o a quien este designe, que lleve a cabo la Fase de Diseño Operativo abordando las cuestiones que se describen en el Documento de análisis inicial de la Fase de Diseño Operativo del Sistema Estandarizado de Acceso/Divulgación a los Datos de registración sin carácter público y que la Evaluación del diseño operativo final se entregue a la Junta Directiva seis meses después de la fecha de la solicitud de la Junta Directiva, siempre que no existan asuntos legales o de otro tipo imprevistos que puedan afectar el plazo. En caso de que surjan circunstancias imprevistas, la Junta Directiva instruye al Presidente y Director Ejecutivo, o a quien este designe, que lo notifique y lo analice con la Junta Directiva y que proporcione un calendario actualizado de los próximos pasos apropiados con respecto a la Evaluación del diseño operativo.

      Resuélvase (2021.03.25.17): La Junta Directiva instruye al Presidente y Director Ejecutivo, o a quien este designe, que considere el Documento para debate sobre la estimación de costos de la organización de la ICANN del 5 de mayo de 2020 para las recomendaciones aprobadas por el Consejo de la GNSO (1-18) del Informe de la Fase 2 del EPDP sobre el Sistema Estandarizado de Acceso y Divulgación.

      Fundamento de las Resoluciones 2021.03.25.15 – 2021.03.25.17

      ¿Por qué la Junta Directiva aborda el tema?

      Debido a la inversión de recursos y a la complejidad que probablemente se requiera para implementar las recomendaciones de políticas relacionadas con el SSAD de manera oportuna y predecible, el inicio de una ODP es esencial para informar las deliberaciones de la Junta Directiva, incluida la cuestión de si las recomendaciones resultan en beneficio de los intereses de la ICANN o la comunidad de la ICANN. El trabajo de la ODP evaluará los riesgos potenciales, los costos previstos, los requisitos de recursos, los plazos y otros asuntos relacionados con la implementación de las recomendaciones relacionadas con el SSAD. También proporcionará de forma transparente a la Junta Directiva la información pertinente relativa a las recomendaciones en apoyo de la obligación de la Junta Directiva de actuar sobre las recomendaciones de la GNSO conforme a los Estatutos. Además, el Consejo de la GNSO, en su carta del 22 de enero de 2021, recomendó a la Junta Directiva que revisara el "documento de debate sobre la estimación de costos" original publicado por la organización de la ICANN el 20 de mayo de 2020, y posteriormente solicitó una consulta con la Junta Directiva de la ICANN para debatir "si debe realizarse un nuevo análisis de costos y beneficios antes de que la Junta Directiva de la ICANN considere todas las recomendaciones relacionadas con el SSAD para su adopción". El inicio de la Fase de diseño operativo contribuirá a la consulta de la Junta Directiva con el Consejo de la GNSO.

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

      La Junta Directiva está tomando medidas en este momento para iniciar la OPD e instruye a la organización de la ICANN que elabore una evaluación de los requisitos operativos y el impacto de las recomendaciones relacionadas con el SSAD según el alcance especificado por la Junta Directiva con el fin de informar la deliberación de la Junta Directiva sobre las recomendaciones.

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

      El equipo de la Fase 2 del EPDP publicó su Informe inicial sobre las recomendaciones de prioridad 1 el 7 de febrero de 2020 y el Anexo del informe inicial, que abarca las recomendaciones de prioridad 2, el 26 de marzo de 2020. Tanto el Informe inicial como el Anexo del informe inicial fueron sometidos a procedimientos de comentario público. El Informe final se entregó al Consejo de la GNSO el 31 de julio de 2020. Se aceptaron las declaraciones minoritarias de los grupos de partes interesadas hasta el 24 de agosto de 2020, y todas las declaraciones recibidas antes de la fecha límite se incorporaron al Informe final.

      En su carta del 29 de octubre de 2020, en la que se transmiten las recomendaciones del equipo de la Fase 2 del EPDP a la Junta Directiva, el Consejo de la GNSO solicitó una consulta con la Junta Directiva de la ICANN en relación con las recomendaciones 1 a 18, en las que se describe la política para el SSAD. En su carta del 1 de diciembre de 2020, la Junta Directiva "reconoció la solicitud del Consejo de la GNSO de una consulta sobre las recomendaciones relacionadas con el SSAD" y señaló su plan de "iniciar una Fase de diseño operativo para evaluar el impacto operativo de las recomendaciones consensuadas aprobadas por el Consejo de la GNSO". El 8 de febrero de 2021, la Junta Directiva inició el foro de comentario público sobre las recomendaciones relacionadas con el SSAD. Se prevé que el foro de comentario público finalice el 30 de marzo de 2021.

      Además, la ODP es un proceso nuevo que se desarrolló con los aportes de la comunidad. La primera iteración del concepto de ODP se publicó el 1 de octubre de 2020. La comunidad y la organización de la ICANN debatieron sobre el contenido del documento conceptual durante la reunión ICANN69. La segunda versión de la ODP se publicó el 17 de diciembre de 2020. La organización de la ICANN llevó a cabo un seminario web de la comunidad el 13 de enero de 2021 para facilitar un debate sobre las actualizaciones proporcionadas en la siguiente versión preliminar del ODP y para recibir comentarios adicionales de la comunidad.

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

      La comunidad proporcionó amplios comentarios en relación con el SSAD, incluidas sus implicaciones financieras. Las siguientes preocupaciones se encuentran entre las compartidas en los comentarios públicos y en las declaraciones minoritarias sobre el Informe Final de la Fase 2 del EPDP, así como en la correspondencia recibida por la organización de la ICANN, entre otros ámbitos:

      • El SSAD no satisface las necesidades de la comunidad proporcionando acceso a datos específicos y precisos sin carácter público de manera oportuna y predecible.
      • El SSAD afronta importantes costos operativos y carece de flexibilidad para garantizar su idoneidad.
      • El SSAD no se ocupa de la seguridad, la estabilidad y la confiabilidad del DNS.
      • El SSAD incluye mecanismos insuficientes para la evolución.
      • El SSAD puede interrumpir un mecanismo de acceso estable, predecible y viable para la información sin carácter público de WHOIS.

      La comunidad también proporcionó comentarios durante el desarrollo de la ODP en los cuales se plantearon las siguientes preocupaciones:

      • La ODP podría dar la oportunidad a los grupos interesados de reabrir o revisar cuestiones de política que ya fueron resueltas durante el proceso de desarrollo de políticas.
      • La ODP modificaría las funciones y responsabilidades de la organización de la ICANN y del equipo de revisión de la implementación que se forma después de que la Junta Directiva haya adoptado las recomendaciones del Consejo de la GNSO.
      • La ODP modificaría la función del Consejo de la GNSO como administrador del proceso de desarrollo de políticas.

      ¿Qué materiales significativos analizó la Junta Directiva?

      La Junta Directiva analizó los siguientes materiales:

      • El documento de debate sobre el análisis de costos del 5 de mayo de 2020, elaborado por la organización de la ICANN para el equipo de la Fase 2 del EPDP, que proporciona una estimación de los costos asociados a la puesta en marcha y a las operaciones en curso relacionadas con los requisitos del sistema propuesto.
      • La resolución del Consejo de la GNSO del 24 de septiembre de 2020 sobre las recomendaciones del Informe final de la Fase 2 del EPDP.
      • El Informe final de la Fase 2 del EPDP, recibido del Consejo de la GNSO, que incluye las recomendaciones 1-18 que abordan el Sistema Estandarizado de Acceso y Divulgación (SSAD).
      • La correspondencia del Consejo de la GNSO del 29 de octubre de 2020 en la que se solicita una consulta de la Junta Directiva y el Consejo de la GNSO antes de las deliberaciones de la Junta Directiva sobre las recomendaciones de políticas.
      • La carta del Consejo de la GNSO del 22 de enero de 2021 en la que se recomendaba a la Junta Directiva que revisara y actualizara el documento de debate sobre la estimación original de costos junto con los temas sugeridos para la evaluación del impacto operativo.

      ¿Qué factores consideró importantes la Junta Directiva?

      La Junta Directiva consideró los factores señalados en el análisis de estimación de costos y la complejidad de las recomendaciones relacionadas con el SSAD al proponer un nuevo sistema para la ICANN. La Junta Directiva comprende que la comunidad está preocupada por las implicaciones financieras y la relación costo-beneficio del SSAD. La Junta Directiva también entiende que los usuarios potenciales del SSAD en la comunidad están preocupados por que dicho sistema sea eficaz para su propósito declarado y sea ampliamente utilizado. El esfuerzo de recopilación de información incluirá la consideración de la eficacia del SSAD y las medidas para garantizar su amplia adopción y uso. Si la Junta Directiva aprueba las recomendaciones, el SSAD es un nuevo sistema que la organización de la ICANN construirá y potencialmente operará. La implementación y el funcionamiento del SSAD requerirán un nivel significativo de inversiones y recursos. Además, las leyes de protección de datos, como el Reglamento General de Protección de Datos (RGPD), han afectado significativamente a la organización de la ICANN y a los datos de registración de WHOIS. Es posible que surjan otras leyes e incertidumbres legales durante el período de la ODP que también podrían afectar significativamente los datos de registro de la organización de la ICANN y WHOIS. Por lo tanto, la organización de la ICANN debe garantizar que el SSAD se diseñe de manera que cumpla con todas las leyes y respalde el DNS a nivel mundial.

      ¿Existen impactos positivos o negativos para la comunidad?

      La organización de la ICANN incorporará mecanismos de interacción, como seminarios web, para comunicarse con la comunidad sobre el progreso de la ODP, y mejorar así la transparencia de la consideración por parte de la Junta Directiva de las recomendaciones en materia de políticas aprobadas por el Consejo de la GNSO. La ODA también aportará más claridad sobre las recomendaciones de políticas, por lo que probablemente reducirá el tiempo que la organización de la ICANN y el Equipo para la Revisión de la Implementación dedican al diseño de procesos durante la fase de implementación.

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

      Esta resolución implicará la dedicación de importantes recursos organizativos para completar la ODP durante el período de tiempo indicado en el documento de análisis inicial. Se solicitará a la comunidad que aporte sus comentarios durante este periodo de tiempo.

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

      La ODP considerará el impacto que el SSAD pueda tener en la seguridad, estabilidad o resiliencia del DNS.

      ¿Esta decisión es de interés público y está dentro de la misión de la ICANN?

      En su evaluación, la Junta Directiva explorará cuáles son las consideraciones de interés público, si las hay, dentro de las recomendaciones de la Fase 2 del EPDP. El mecanismo para determinar el interés público relevante en una recomendación determinada será el marco de procedimiento de interés público global que la Junta Directiva está probando como piloto en el año fiscal 2021. El marco se utilizará como herramienta de evaluación solo para las recomendaciones con consideraciones de interés público.

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

      Esta es una función administrativa organizativa que no requiere comentario público, pero cabe señalar que el Informe final de recomendaciones políticas y el marco de la ODP fueron objeto de comentario público, como se ha comentado anteriormente. Además, la propia ODP es un proceso abierto y transparente y está previsto que el público pueda aportar comentarios y opiniones a lo largo de la fase de diseño.

    4. Otros temas a tratar

      No se adoptó ninguna resolución.


1 Recomendaciones 18, 24 y 25

2 Recomendación 29

3 Recomendaciones 24, 25, 29

4 Recomendación 29

5 Recomendación 29

6 Recomendación 27

7 Recomendación 26

8 Recomendaciones 8, 9, 10

9 Recomendación 16

10 Recomendación 3

11 Recomendaciones 4, 5

12 Recomendación 29

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