Skip to main content
Resources

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

Esta página está disponible en:

El 14 de marzo de 2019 a las 16:00 hora local se celebró en persona una reunión ordinaria de la Junta Directiva de la ICANN en Kobe, Japón.

Cherine Chalaby, Presidente, declaró abierta la sesión con puntualidad.

Junto al Presidente, los siguientes Directores participaron en forma total o parcial de la reunión: Becky Burr, Maarten Botterman, Ron da Silva, Sarah Deutsch, Chris Disspain (Vicepresidente), Avri Doria, Rafael Lito Ibarra, Danko Jevtovic, Khaled Koubaa, Akinori Maemura, Göran Marby (Presidente y Director Ejecutivo), Nigel Roberts, León Sanchez, Matthew Shears y Tripti Sinha.

Los siguientes coordinadores de enlace con la Junta participaron en forma total o parcial de la reunión: Harald Alverstrand (Coordinador de enlace entre la Junta Directiva y el IETF), Manal Ismail (Coordinadora de Enlace entre la Junta Directiva y el GAC), Merike Kaeo (Coordinadora de Enlace entre la Junta Directiva y el SSAC) y Kaveh Ranjbar (Coordinador de Enlace entre la Junta Directiva y el RSSAC).

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

 

  1. Orden del día convenido:
    1. Aprobación de las actas de la reunión
    2. Aprobación de la enmienda para implementar la solicitud de servicio de registro de Verisign a fin de autorizar la liberación para la registración del dominio de un solo caracter en el segundo nivel, O.COM
    3. Aplazamiento de la ejecución de la implementación de la Política sobre WHOIS Amplio
    4. Designación de los auditores independientes para el Año Fiscal 2019 (FY19)
    5. Aceptación de las revisiones de la Carta Orgánica del Comité de Efectividad Organizacional
    6. Designación del representante de la organización operadores de servidores raíz ante el Comité Asesor del Sistema de Servidores Raíz (RSSAC)
    7. Aprobación de la enmienda al contrato de funciones de nombres de la IANA
    8. Agradecimiento al anfitrión local de la Reunión N.º 64 de la ICANN
    9. Agradecimiento a los patrocinadores de la Reunión N.º 64 de la ICANN
    10. Agradecimiento a los intérpretes, el personal y los equipos del hotel y eventos de la Reunión N.º 64 de la ICANN
  2. Orden del día principal:
    1. Recomendaciones para la gestión de TLD con variantes de Nombres de Dominio Internacionalizados (IDN)
    2. Preparación para la implementación de los procedimientos posteriores a la Introducción de Nuevos gTLDs.
    3. Transferencia del dominio de alto nivel .VU (Vanuatu) al Regulador de Radiocomunicaciones y Radiodifusión de Telecomunicaciones (TRBR).
    4. Considerar la Solicitud de Reconsideración 16-5: DotMusic Limited
    5. Consideración de .AMAZON
    6. Aceptación de la Segunda Revisión Organizacional del NomCom – Informe Final y Recomendaciones
    7. Próximos pasos con respecto a la composición del Equipo de Revisión de la Función de Nombres de la IANA
    8. Otros temas a tratar
      1. Proyecto de Análisis de Colisión de Nombres - –Primer Estudio
  1. Orden del día convenido:

    El Presidente inauguró la reunión e introdujo los puntos a tratar en el orden del día convenido. El Presidente preguntó si alguno de los miembros de la Junta Directiva deseaba pasar algún punto del orden del día convenido al orden del día principal. Avri Doria solicitó que el punto sobre la Aceptación de la Segunda Revisión Organizacional del NomCom - Informe Final y Recomendaciones fuese transferido del orden del día convenido al orden del día principal. Chris Disspain solicitó que el punto de los Próximos pasos con respecto a la composición del Equipo de Revisión de la Función de Nombres de la IANA se transfiriese del orden del día convenido al orden del día principal.

    Ron da Silva presentó la moción y Lito Ibarra la secundó. Luego, el Presidente de la Junta Directiva llamó a votación y la Junta Directiva tomó las siguientes medidas:

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

      Resuélvase (2019.03.14.01): La Junta Directiva aprueba las actas de la Reunión Especial de la Junta Directiva de la ICANN celebrada el16 de enero de 2019 y la Reunión Ordinaria de la misma llevada a cabo el 27 de enero de 2019.

    2. Aprobación de la enmienda para implementar la solicitud de servicio de registro de Verisign a fin de autorizar la liberación para la registración del dominio de un solo caracter en el segundo nivel, O.COM

      Visto y considerando: Que la Organización de la ICANN ha evaluado la Enmienda propuesta al Acuerdo de Registro de .COM de Verisign para los servicios de registro de acuerdo con los requisitos de las Secciones 3.1 (d) (iii) y 3.1 (d) (iv) del Acuerdo de Registro de .COM y, en consonancia con la Política de Evaluación de Servicios de Registro, la Organización de ICANN no identificó problemas de seguridad o estabilidad significativos, y ha publicado la Enmienda propuesta para comentarios públicos.

      Visto y considerando: Que la Organización de la ICANN determinó que el Servicio de Registro propuesto podría plantear problemas de competencia importantes y remitió el asunto al Departamento de Justicia de los Estados Unidos, y que la División de Defensa de la Competencia del Departamento de Justicia de los Estados Unidos comunicó a la organización de la ICANN que no tenía la intención de iniciar una investigación sobre el asunto.

      Visto y considerando: Que la Organización de la ICANN inició un período de comentarios públicos desde el 10 de mayo de 2018 hasta el 20 de junio de 2018 sobre la Enmienda propuesta para implementar la solicitud de servicios de registro aprobada de Verisign para liberar el nombre de dominio un solo caracter, O.COM, para la registración, y que la Junta Directiva recibió un resumen y análisis de los comentarios.

      Visto y considerando: Que la liberación propuesta del dominio de un solo caracter, O.COM, estaría en consonancia con la recomendación efectuada por el Grupo de Trabajo sobre Nombres Reservados de la Organización de Apoyo para Nombres Genéricos (GNSO).

      Visto y considerando: Que la Junta Directiva de la ICANN

      examinó minuciosamente los comentarios públicos recibidos y el resumen y análisis de los mismos efectuado por la Organización de la ICANN.

      Visto y considerando: Que la Junta Directiva de la ICANN concluye que la Enmienda propuesta para autorizar la liberación del nombre de dominio de un solo caracter, O.COM, se encuentra limitada por las circunstancias específicas de este nombre de dominio en particular, y que la aprobación de la enmienda no sienta un precedente que se aplique en otras circunstancias.

      Resuélvase (2019.03.14.02): Se aprueba la Enmienda al Acuerdo de Registro .COM para liberar el nombre de dominio de un solo caracter, O.COM, en el espacio de nombres .COM, y el Presidente y Director Ejecutivo (CEO), o quien éste designe, están autorizados para tomar las medidas que sean apropiadas para implementar la Enmienda.

      Fundamento de la resolución 2019.03.14.02

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

      En noviembre de 2017, Verisign presentó una solicitud de servicio de registro para realizar una prueba para la liberación de un nombre de dominio .COM con una etiqueta de un solo caracter, O.COM, mediante una subasta y para destinar los fondos de la subasta a sectores de bien público para la comunidad de Internet, en consonancia con el Marco de Asignación de Nombres de Dominio de Segundo Nivel de un solo Caracter (SCSLD) de la organización de la ICANN.

      La organización de la ICANN llevó a cabo una revisión del Servicio de Registro propuesto y no identificó problemas significativos en materia de seguridad o estabilidad. Sin embargo, la organización de la ICANN determinó que el Servicio de Registro propuesto podría generar importantes problemas de competencia. El 7 de diciembre de 2017, la organización de la ICANN remitió el asunto al Departamento de Justicia de los Estados Unidos. El 14 de diciembre de 2017, la División Anti monopolio del Departamento de Justicia de los Estados Unidos comunicó a la organización de la ICANN que no tenía intención de dar lugar a una investigación al respecto.

      Tras una determinación preliminar de la aprobación del servicio de registro propuesto, la organización de la ICANN publicó para comentarios públicos, desde el 10 de mayo de 2018 al 20 de junio de 2018, la Enmienda propuesta al Acuerdo de Registro de .COM para dar lugar a la implementación del servicio.

      La Enmienda propuesta sigue el análisis y las recomendaciones sobre nombres de dominio de un solo caracter del Grupo de Trabajo sobre Nombres Reservados de la GNSO, el Consejo de la GNSO y la organización de la ICANN, así como los aportes de la comunidad, y está en consonancia con la aprobación por parte de la Junta Directiva de la ICANN de la liberación de nombres de un solo caracter en otros dominios genéricos heredados de alto nivel (gTLDs). Hasta la fecha, la Junta Directiva de la ICANN ha aprobado la liberación de nombres de un solo caracter en muchos gTLD heredados, incluidos .ORG, .BIZ, .INFO, .MOBI y .PRO. Además, no es necesario que los nombres de un solo caracter se reserven para los gTLD introducidos como parte del Programa de nuevos gTLD.

      La organización de la ICANN ha tomado medidas para evaluar y considerar la Enmienda propuesta y los comentarios de la comunidad, cada uno de los cuales se ha puesto a disposición de la Junta Directiva de la ICANN para que los revise y considere antes de tomar una decisión.

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

      Según la Enmienda propuesta, el nombre de dominio de un solo caracter, O.COM, se asignará mediante de un proceso de subasta y será administrado por un proveedor de servicios externo. Verisign no recibirá, directa o indirectamente, ningún rédito de la venta, distribución, transferencia o renovación de O.COM y sólo percibirá la tarifa de registro estándar para el registro de O.COM, o USD 7.85. Los ingresos derivados de la subasta de O.COM se proporcionarán a una o más organizaciones sin fines de lucro, o sus sucesores, dedicadas a sectores de bien público para la comunidad de Internet. Ninguno de los ingresos de la subasta se utilizará directa o indirectamente para beneficiar a Verisign, sus afiliados, sus directores, funcionarios o empleados. Todo posible registratario puede participar en el proceso de subasta y seleccionar cualquier registrador acreditado por la ICANN para la gestión de la registración de O.COM si se le otorga el nombre. No se impondrán restricciones sobre cómo el registratario puede seleccionar un registrador acreditado por ICANN de. COM.

      El registratario vencedor debe: (i) presentar el monto total de la oferta ganadora dentro de los catorce (14) días calendario a partir de la fecha en que se determinó que resultó la parte vencedora, y (ii) comprometerse a enviar al Fideicomiso el cinco por ciento (5 %) de la primera cuota de la oferta ganadora por cada año en que el nombre de dominio se renueve luego del vencimiento del período inicial de registro de cinco (5) años (cada uno,"cuotas subsiguientes") hasta el vigésimo quinto año (25°) en que el registratario renueve el nombre de dominio de un caracter. Las cuotas subsiguientes están destinadas a fomentar un flujo continuo de fondos para las organizaciones sin fines de lucro hasta el vencimiento de la cuota subsiguiente. A modo de ejemplo, si la subasta tuviese lugar en 2020 y la oferta ganadora fuese de $ 10.000, la primera cuota de la oferta ganadora para el nombre de dominio de un solo caracter sería de $ 10.000 y se pagaría en 2020, y la cuota subsiguiente para cada año posterior luego del plazo inicial de cinco (5) años sería de $ 500 y se pagaría entre 2026 y 2045 (es decir, el 5% de la primera cuota de la oferta ganadora).

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

      La organización de la ICANN inició un período de comentarios públicos sobre la enmienda propuesta desde el10 de mayo de 2018 al 20 de junio de 2018. La propuesta recibió veintinueve (29) comentarios de veinticuatro (24) entidades diferentes.

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

      Los comentarios que se enviaron generalmente se clasifican en las siguientes categorías, cada una de las cuales se explica con más detalle a continuación:

      1. Expresan apoyo a la enmienda propuesta para liberar O.COM.
      2. Temen que la liberación de O.COM pueda crear problemas en materia de seguridad y estabilidad.
      3. Temen que los requisitos de "prueba" propuestos para la liberación de O.COM puedan sentar un precedente para la liberación de futuros nombres de dominio de un solo caracter .COM o para todo el espacio de nombres .COM.
      4. Temen que las "cuotas subsiguientes" propuestas por Verisign, abonadas por el solicitante para renovar O.COM puedan ser un vehículo para que Verisign incremente las tasas de renovación para todo el espacio de nombres .COM.
      5. Presentan inquietudes con respecto a la restricción de transferencia propuesta para el nombre de dominio O.COM impuesta por Verisign una vez que se asigne el nombre.
      6. Temen por la falta de protección de ciertos derechos con la liberación de O.COM en la Enmienda propuesta.
      7. Presentan inquietudes con respecto al proceso de subasta y los requisitos de previos de calificación que impondrá el proveedor de la subasta, según lo propuesto por Verisign, para la liberación de O.COM y la falta de transparencia con respecto al proceso.
      8. Sugerencias con respecto a la distribución propuesta de fondos con posterioridad a la subasta de O.COM, según lo propuesto en la Enmienda

      Varios personas expresaron comentarios positivos con respecto a la liberación de nombres de .COM de un solo caracter y la dirección propuesta para la utilización de los ingresos de la subasta para apoyar el bien público de Internet y ofrecieron otras sugerencias sobre cómo se podrían utilizar los ingresos. Un tema que se repitió entre quienes realizaron comentarios fue la necesidad de transparencia en todo el proceso de subasta, desde la elección del proveedor de la subasta hasta el proceso propuesto para administrar la liberación del nombre de dominio.

      En dos comentarios se sugirió que O.COM puede dar lugar a problemas en materia de seguridad y estabilidad en el espacio de nombres .COM en caso de liberarse. Además, quienes efectuaron comentarios expresaron su preocupación con respecto al enfoque propuesto por Verisign para subastar y liberar el nombre de dominio O.COM, y que los requisitos propuestos para O.COM no están en consonancia con la forma en que los nombres de dominio .COM actuales se registran y renuevan, y la falta de protección de ciertos derechos con la liberación de O.COM.

      La inquietud sobre la seguridad y la estabilidad que se planteó durante el período de comentarios públicos se centró en la posible "confusibilidad de todo el código de escritura" con la liberación del nombre de dominio "O.COM" de un solo carácter en el código de escritura latino, dado el código griego y las versiones cirílicas de "O. COM “ ya existen en el espacio de nombres .COM. Tras una evaluación interna, se determinó que el riesgo no es mayor que el que representan otros nombres de dominio de un solo caracter ya liberados en otros TLD.

      Varios comentarios expresaron la preocupación de que los requisitos propuestos para la liberación de O.COM pueden sentar un precedente para la liberación de nombres de dominio .COM de un solo carácter en el futuro o en todo el espacio de nombres .COM. Específicamente, quienes realizaron comentarios sugirieron que la “Cuota Subsiguiente" propuesta por Verisign y abonada por el solicitante para renovar O.COM es una oportunidad para que Verisign introduzca tarifas premium o tarifas de renovación para otros nombres de dominio de un solo caracter liberados en el espacio de nombres .COM en el futuro o para todos los nombres de dominio .COM. La organización de la ICANN observa que la Política de Evaluación de Servicios de Registro (RSEP) propuesta por Verisign y la Enmienda propuesta al Acuerdo de Registro de .COM garantizan que Verisign solo percibirá la tarifa de registro estándar durante la registración inicial de O.COM y todas las renovaciones posteriores, que deberán cumplir con las disposiciones en materia de fijación de precios de tarifas del registro, según la Sección 7.3 (d) del Acuerdo de Registro .COM. A partir de la fecha de presentación de la propuesta, la tarifa de registro, definida como el Precio Máximo en el Acuerdo de Registro .COM, es de USD 7,85. La única tarifa de renovación que Verisign percibirá es la tarifa de renovación estándar al momento de la renovación. La "cuota subsiguiente" requerida por el registratario vencedor tiene la intención de "alentar un flujo continuo de fondos a las organizaciones sin fines de lucro hasta la fecha de vencimiento de la cuota subsiguiente".

      Quienes realizaron comentarios también expresaron inquietudes con respecto a una restricción de transferencia propuesta para el nombre de dominio O.COM propuesta por Verisign, una vez que se asigna el nombre, y sugirieron que esto agrega complicaciones innecesarias en el espacio de nombres .COM. Además, si se permite esta restricción, a quienes realizaron comentarios les preocupa que Verisign pueda hacer extensiva la restricción a los futuros nombres de dominio de .COM de un solo caracter que aún no se han liberado. En los comentarios públicos se señaló que, debido a la escasez de nombres de un solo caracter en el valioso espacio de nombres .COM, se debe permitir al registratario vencedor que utilice el o los nombre (s) a su criterio. Tras una revisión de los comentarios públicos, Verisign eliminó voluntariamente la restricción de transferencia del solicitante de registro al solicitante a partir de la Enmienda propuesta.

      Se plantearon otras preocupaciones con respecto a la ausencia de ciertos Mecanismos de Protección de Derechos (RPM) para acompañar la liberación de O.COM y posibles problemas de seguridad y estabilidad una vez que O.COM se agregue al espacio de nombres .COM. Sin embargo, no hay ningún requisito para ofrecer un período pre-registro (Sunrise) antes de la liberación de cualquier nombre reservado de acuerdo con el Acuerdo de Registro .COM. Además, las solicitudes en el marco de la RSEP enviadas y posteriormente aprobadas por la Junta Directiva para .BIZ (2008), .INFO (2010) y .ORG (2011) para liberar nombres reservados de uno y dos caracteres, no incluyeron un período pre-registro (Sunrise). La Política Uniforme de Resolución de Disputas por Nombres de Dominio está disponible para toda controversia relacionada con marcas comerciales que surja de la asignación de cualquier nombre en el espacio de nombres .COM, incluido O.COM.

      ¿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 consideró minuciosamente los comentarios públicos recibidos sobre la enmienda para implementar la Solicitud de Servicio de Registro de Verisign para liberar el nombre de un solo carácter, O.COM, para la registración, junto con el resumen y el análisis de dichos comentarios. La Junta Directiva también consideró los términos acordados por el Operador de Registro como parte de las negociaciones bilaterales con la organización de la ICANN.

      La Junta Directiva agradece el tiempo dedicado por la comunidad para revisar la Enmienda propuesta a fin de implementar la liberación de O.COM. Además, la Junta Directiva fundamentó sus consideraciones en el compromiso y los comentarios de la comunidad que brindaron sugerencias propicias para respaldar el enfoque propuesto por Verisign para utilizar los ingresos de la subasta de O.COM a favor del bien público de la comunidad de Internet.

      La Junta Directiva también reconoce las inquietudes expresadas por algunos miembros de la comunidad con respecto a la posible "confusabilidad de todo el código de escritura" con la liberación del dominio de un sólo caracter, "O.COM", y cómo la liberación del nombre de dominio de un solo carácter puede considerarse una preocupación sobre seguridad y estabilidad. No obstante, la Junta Directiva reconoce que otros nombres de dominio de un solo caracter, tanto en gTLD heredados como nuevos, están disponibles en la actualidad, y que el trabajo continúa en toda la comunidad a fin de mitigar las posibles inquietudes en relación con la seguridad y estabilidad para todos los códigos de escritura completos que prestan a confusión como nombres de dominio. Esto incluye la versión 4.0 de borrador propuesto final de las pautas para la implementación de nombres de dominio internacionalizados (Pautas para IDN versión 4) publicada por el Grupo de Trabajo sobre Pautas para IDN (IDNGWG), que recomienda prácticas diseñadas con el objetivo de minimizar el riesgo de ciberocupación y confusión del consumidor. La Junta Directiva observa que las pautas preliminares para IDN, versión 4, "alientan a los registros de TLD a aplicar otras restricciones a las registraciones que minimizan los conjuntos confusos de todo el código de escritura..." pero que no requieren una mitigación de carácter específico, y que estas Pautas para IDN versión 4 aún no han sido adoptadas por la Junta Directiva. Es una práctica de la organización de la ICANN adherirse a las políticas y procedimientos existentes y aplicar los requisitos de las recomendaciones de la comunidad pendientes sólo una vez que se hayan adoptado e implementado. La Junta Directiva debatió recientemente cómo la organización de la ICANN debe manejar las solicitudes nuevas de las partes contratadas, cuando el trabajo en curso de la comunidad podría resultar en un cambio de proceso que podría afectar la solicitud en el taller de Genval en septiembre de 2018.

      La Junta Directiva también reconoce las inquietudes planteadas por la comunidad al señalar que los aspectos de la liberación propuesta de O.COM mediante el proceso de subasta de prueba tienen requisitos diferentes a los de otros nombres de dominio en el espacio de nombres .COM y pueden afectar otros nombres de dominio en el espacio de nombres .COM ahora y en el futuro. La Junta Directiva reconoce las inquietudes planteadas por la comunidad y también reconoce el enfoque de Verisign para liberar O.COM a través de un proceso de prueba que ofrece a Verisign y a posibles registratarios la oportunidad de obtener información valiosa sobre el proceso. Tal como se indicó, el servicio propuesto no afectaría la funcionalidad, métodos, precios, procedimientos o especificaciones existentes para el registro de cualquier otro nombre de dominio en el espacio de nombres .COM. Además, Verisign está sujeto a los términos del Acuerdo de Registro de .COM y la liberación de O.COM no cambiará dichos compromisos. La Junta Directiva también reconoce la actualización de Verisign a la enmienda propuesta para eliminar las restricciones de transferencia en respuesta a las inquietudes planteadas por la comunidad.

      La Junta Directiva también reconoce las inquietudes planteadas con respecto a la subasta general y el proceso de subasta en la enmienda propuesta y observa que el proceso de subasta propuesto es similar a la forma en que la mayoría de los operadores de registro administran y han administrado las subastas de nombres de dominio. Además, los operadores de registro para TLD heredados como .BIZ, .INFO y .ORG utilizaron procesos similares para subastar sus TLD de uno o dos caracteres. Todos los operadores de registro, heredados o gTLD, pueden definir y realizar subastas sin supervisión ni restricciones para sus TLD y, rara vez, divulgan los detalles de la subasta con antelación o las tarifas que se abonarán al proveedor de la misma.

      La Junta Directiva reconoce, además, las inquietudes planteadas con respecto al plan propuesto por Verisign para liberar O.COM sin los RPM que los operadores de registro de nuevos gTLD deben avalar. En los comentarios se sugirió que con la liberación de O.COM, Verisign debería cumplir con las mismas obligaciones que los operadores de nuevos gTLD y llevar a cabo un período pre-registro (Sunrise) de 90 días. Si bien la Junta Directiva reconoce las inquietudes expresadas por algunos miembros de la comunidad con respecto al plan propuesto por Verisign para liberar O.COM sin RPM, no es obligatorio ofrecer un período pre-registro (Sunrise) antes de la liberación de los nombres reservados, según lo estipulado en el acuerdo de registro .COM. Además, las solicitudes de RSEP que se enviaron y que requirieron modificaciones al acuerdo de registro y que posteriormente fueron aprobadas por la Junta Directiva para .BIZ (2008), .INFO (2010) y .ORG (2011) para liberar nombres reservados de uno y dos caracteres, no incluía un período pre-registro (Sunrise). La Política Uniforme de Resolución de Disputas por Nombres de Dominio está disponible para toda controversia relacionada con marcas comerciales que surja de la asignación de cualquier nombre en el espacio de nombres .COM, incluido O.COM.

      ¿Existen impactos positivos o negativos para la comunidad?

      Se anticipa que la aprobación por parte de la Junta Directiva de la enmienda propuesta para liberar el nombre de dominio de un solo caracter, O.COM, para registración, será positiva. Como señalaron varios miembros de la comunidad durante el período de comentarios públicos, éste es un paso positivo para liberar más nombres de dominio de un solo caracter, específicamente en el espacio de nombres .COM. Además, quienes realizaron comentarios públicos apoyan el enfoque propuesto por Verisign para utilizar los ingresos de la subasta de O.COM a favor del bien público de la comunidad de Internet e instan a Verisign a mostrar transparencia en la forma en que se distribuyen los ingresos.

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

      No hay un impacto fiscal significativo para la organización de la ICANN que se prevea a partir de la liberación del dominio de un solo caracter, O.COM, para registración.

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

      Como se señaló anteriormente, la pregunta sobre si la liberación de O.COM puede causar un problema de seguridad o estabilidad se planteó durante el período de comentarios públicos. La inquietud planteada involucró la posible confusabilidad de la totalidad del código de escritura latino "O.COM" con los caracteres griegos y cirílicos que ya están en el espacio de nombres .COM y sostiene que la liberación de O.COM puede entrar en conflicto con la Pautas preliminares sobre IDN v4 . La organización de la ICANN ha confirmado a la Junta Directiva que las Pautas preliminares para IDN v4, "alientan a los registros de TLD a aplicar otras restricciones a las registraciones que minimizan los conjuntos confusos de todo el código de escritura…" pero no requieren una mitigación específica y esta liberación de O.COM no entraría en conflicto con las Pautas para IDN v4. Además, la Junta Directiva no ha adoptado aún las Pautas para IDN v4, ya que la organización de la ICANN continúa definiendo el plan de implementación a fin de garantizar una transición sin problemas a las nuevas pautas. Las Pautas para IDN v4 anticipan la necesidad de tratar los dominios existentes como excepciones, "Cuando un nombre de dominio preexistente requiera que un registro haga una excepción transitoria a alguna de estas Pautas, los términos de esa acción también deben estar disponibles en línea, incluidos los cronogramas para la resolución de tales asuntos transitorios” y se esperaría que Verisign cumpla con este requisito en el debido tiempo.

    3. Aplazamiento de la ejecución de la implementación de la Política sobre WHOIS Amplio

      Visto y considerando: Que la Política de Transición hacia WHOIS Amplio requiere que Verisign comience a aceptar los datos “amplios” de la registración de los registradores para los nombres .COM y .NET a partir del 30 de noviembre de 2019, que todos las registraciones de nuevos nombres de dominio se presentan como "Amplias" al 31 de mayo de 2020, y que todos los datos de registración relevantes para los nombres de dominio existentes se migran de "Acotado" a "Amplio" al 30 de noviembre de 2020.

      Visto y considerando: Que en preparación para completar la implementación para aceptar datos de WHOIS amplio, Verisign propuso modificaciones a los acuerdos entre registro y registrador para .COM y .NET.

      Visto y considerando: Que el Grupo de Partes Interesadas de Registradores expresó su preocupación por las enmiendas propuestas por Verisign sobre la base de las cuestiones relacionadas con el Reglamento General de Protección de Datos de la Unión Europea, el procesamiento de datos y los nuevos requisitos y obligaciones impuestas a los registradores.

      Visto y considerando: Que la organización de la ICANN ha continuado facilitando las discusiones entre Verisign y el Grupo de partes interesadas de registradores para llegar a un acuerdo sobre las enmiendas propuestas a los acuerdos entre registros y registradores para implementar la Política de Transición del WHOIS Amplio.

      Visto y considerando: Que Verisign y el Grupo de Partes Interesadas de Registradores necesitan más tiempo para llegar a un acuerdo sobre las enmiendas propuestas a los acuerdos entre Registro y Registrador aplicables para implementar la Política de transición hacia WHOIS amplio.

      Visto y considerando: Que el período de cumplimiento diferido permitirá a la comunidad de la ICANN y a la Junta Directiva considerar el Informe Final 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 tiempo adicional permitirá a las partes contratadas afectadas y a la organización de la ICANN evaluar todo posible impacto en la Política de Transición hacia WHOIS Amplio a partir de las recomendaciones del EPDP.

      Resuélvase (2019.3.14.03): El Presidente y Director Ejecutivo (CEO), o quien éste designe, está autorizado a diferir la ejecución de la Política de Transición hacia WHOIS amplio hasta el 30 de noviembre de 2019, el 31 de mayo de 2020 y el 30 de noviembre de 2020, respectivamente.

      Fundamento de la resolución 2019.03.14.03

      La Política de Transición hacia WHOIS Amplio especifica un enfoque por fases para la transición de los registros de .COM y .NET de WHOIS "Acotado" a "Amplio". Las tres fases son las siguientes:

      1. El Operador de registro (RO) comenzará a aceptar datos amplios de WHOIS de registradores,
      2. Se crearán nuevas registraciones de nombres de dominio de .COM y .NET como registraciones amplias.
      3. La migración completa de todos los datos de registración de dominios existentes de "Acotado" a "Amplio" un año después de la fecha en que el RO comience a aceptar los datos de WHOIS de los registradores.

      La Política de Transición hacia WHOIS Amplio requiere que Verisign comience a aceptar los datos de registración "Amplios" de los registradores a partir del 31 de mayo de 2019, los registradores deben enviar los datos amplios de registración a Verisign para todas las nuevas registraciones de nombres de dominio a partir del 30 de noviembre de 2019, y la migración de todos los datos de registración de dominio existentes de acotado a amplio, antes del 31 de mayo de 2020. En preparación para aceptar los datos de WHOIS amplio, Verisign, el operador de registro para .COM y .NET, propuso enmiendas a los acuerdos entre Registro y Registrador para .COM y .NET para que cuenten con el marco legal necesario para la aceptación de los datos. Si bien la Política de Consenso de WHOIS Amplio también se aplica a los TLD de .JOBS, el operador de registro para .JOBS, Employ Media, no exigió cambios en el Acuerdo entre Registro y Registrador para comenzar a aceptar los datos de registración amplia y los registradores ya han comenzado a presentar los datos de registración amplios para .JOBS conforme a la Política.

      Siguiendo el procedimiento de Enmienda del Acuerdo entre Registro y Registrador, la organización de la ICANN ha estado facilitando las discusiones entre Verisign y el Grupo de Partes Interesadas de Registradores para llegar a un acuerdo sobre las enmiendas propuestas a los acuerdos entre Registro y Registrador, pero las partes aún no han llegado a un acuerdo. Además, la comunidad a través del EPDP de la GNSO está trabajando para desarrollar una Política de consenso permanente para reemplazar o confirmar la Especificación Temporaria para los Datos de Registración de los gTLD.

      La Junta Directiva está tomando medidas en este momento para autorizar al Presidente y Director Ejecutivo de la ICANN para aplazar el cumplimiento de la Política de WHOIS amplio por un plazo de 180 días. Esto proporcionará más tiempo para que la comunidad y la Junta Directiva consideren las recomendaciones en el Informe Final del EPDP. El aplazamiento también proporcionará a las partes contratadas afectadas y a la organización de la ICANN tiempo para evaluar todo posible impacto en la Política de Transición hacia WHOIS Amplio a partir de las recomendaciones del EPDP.

      Existe el riesgo de que sea necesario seguir aplazando la implementación si el equipo del EPDP recomienda cambios significativos en la Especificación Temporaria para los Datos de Registración de los gTLD.

      Las deliberaciones de la Junta Directiva sobre este asunto hicieron referencia a varios materiales importantes entre los que se incluyen:

      No se prevé que la acción de la Junta Directiva tenga un impacto fiscal en la ICANN que ya no está previsto en el presupuesto actual. Esta acción es de interés público y está en consonancia con la misión de la ICANN, ya que contribuye a garantizar una implementación coherente y coordinada de las políticas en los gTLD.

      Esta resolución es una función organizacional y administrativa respecto de la cual no se requiere comentario público.

    4. Designación de los auditores independientes para el Año Fiscal 2019 (FY19)

      Visto y considerando: Que el Artículo 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 2019 y ha recomendado que la Junta autorice al Presidente y Director Ejecutivo, o quien éste designe, a tomar todas las medidas necesarias para la participación de BDO LLP y las empresas miembro de BDO.

      Resuélvase (2019.03.14.04): La Junta Directiva autoriza al Presidente y Director Ejecutivo, o a quien éste designe, a contratar a BDO LLP y a las empresas miembro de BDO como auditores de los estados contables del año fiscal que finaliza el día 30 de junio de 2019.

      Fundamento de la resolución 2019.03.14.04

      La firma de auditoria BDO LLP y las firmas miembro de BDO han sido auditores independientes de la ICANN desde la auditoria del año fiscal 2014. 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ó que la Junta Directiva autorice al Presidente y Director Ejecutivo (CEO), o quien éste designe, a instrumentar los pasos necesarios para contratar a BDO LLP y a las empresas miembro de BDO como auditores independientes anuales de la ICANN para el año fiscal 2019 para todo requisito de auditoria 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. Se espera que esta decisión sea congruente con la Misión de la ICANN y que sirva al interés público porque la contratación de un auditor independiente está en consonancia con las obligaciones de la ICANN de auditar los libros contables de la corporación y prestar un servicios de más responsabilidad a las partes interesadas de la ICANN.

      Esta decisión tendrá un impacto fiscal en la ICANN tal como se pretende. Esto no debería tener ningún impacto directo en la seguridad, estabilidad y flexibilidad del sistema de nombres de dominio.

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

    5. Aceptación de las revisiones de la Carta Orgánica del Comité de Efectividad Organizacional

      Visto y considerando: Que el Comité de Efectividad Organizacional de la Junta Directiva de la ICANN actualmente tiene la responsabilidad de supervisar las Revisiones Organizacionales y Específicas estipuladas por los Estatutos de la ICANN. En virtud del Artículo 18 de los Estatutos posteriores a la transición de la custodia de la IANA, la ICANN también es responsable de generar revisiones periódicas y especiales de la función de nombres de la IANA, que tienen como objetivo revisar el desempeño de la entidad de la PTI según el Contrato de la Función de Nombres de la IANA y la Declaración de Trabajo de la Función de Nombres de la IANA. Hasta la fecha, ningún comité de la Junta Directiva ha sido designado con responsabilidad de supervisión en lo referido a las revisiones de la función de nombres de la IANA (IFR).

      Visto y considerando: Que el Comité de Efectividad Organizacional ha propuesto revisiones a su carta orgánica actual para reflejar la responsabilidad de supervisión de las IFR.

      Visto y considerando: Que el Comité de Gobernanza de la Junta Directiva, encargado de considerar las cartas orgánicas del Comité, está de acuerdo con la propuesta del Comité de Efectividad Organizacional de la Junta Directiva (OEC) y recomienda que la Junta Directiva adopte esta Carta revisada del OEC.

      Resuélvase (2019.03.14.05): La Junta Directiva adopta las revisiones propuestas a la carta orgánica del Comité de Efectividad Organizacional.

      Fundamento de la resolución 2019.03.14.05

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

      La Junta Directiva aborda esta cuestión debido a la exigencia de que la Junta Directiva apruebe las revisiones de la carta orgánica de los Comités de la Junta Directiva.

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

      El Comité de Efectividad Organizacional (OEC) está proponiendo un cambio en la responsabilidad de supervisión del Comité para incluir las revisiones de la función de nombres de la IANA (IFR). El OEC propone asumir la responsabilidad de supervisión de las IFR, dado el rol de supervisión existente del OEC en relación con las revisiones específicas y organizativas.

      ¿Qué materiales significativos analizó la Junta Directiva?

      La Junta Directiva revisó las revisiones propuestas a la carta orgánica del OEC de 2017. Véase Materiales de referencia, Anexo A (borrador) y Anexo B (definitivo).

      ¿Existen impactos positivos o negativos para la comunidad?

      Las revisiones propuestas tienen la intención de proporcionar claridad y alinear las revisiones exigidas por los Estatutos a fin de aplicar de manera coherente la supervisión de la Junta Directiva. Se prevé que estos desarrollos tengan un impacto positivo en la comunidad. Las IFR son una forma clave para que la ICANN confirme que su afiliada y contratista, la entidad de los Identificadores Técnicos Públicos, se está desempeñando adecuadamente en relación con sus contratos, y corresponde contar con una supervisión definida a nivel de la Junta Directiva para dicha revisión.

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

      Los cambios propuestos no generarán ningún impacto fiscal ni ramificaciones adversas sobre los planes estratégicos y operativos de la ICANN.

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

      No existen problemas de seguridad, estabilidad o flexibilidad relacionados con el DNS como resultado de esta acción.

      ¿Está dicha 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 está en consonancia con el compromiso de la ICANN de conformidad con el Artículo 18 de los Estatutos para garantizar que la entidad de la PTI lleve a cabo la función de nombres de la IANA de acuerdo con los requisitos contractuales establecidos en el Contrato de la Función de Nombres de la IANA y la SOW de la Función de Nombres de la IANA. Esta acción servirá al interés público porque garantiza a la Junta Directiva de la ICANN la supervisión de cómo la ICANN y la entidad de la PTI cumplen con el compromiso de la ICANN de prestar los servicios de la función de nombres de la IANA acorde a las expectativas de los clientes y la comunidad de la ICANN en general.

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

      No se requiere ningún comentario público.

    6. Designación del representante de la organización operadores de servidores raíz ante el Comité Asesor del Sistema de Servidores Raíz (RSSAC)

      Visto y considerando: Que los Estatutos de la ICANN establecen la creación de un Comité Asesor del Sistema de Servidores Raíz (RSSAC), cuyo rol es asesorar a la comunidad y a la Junta Directiva de la ICANN respecto de cuestiones relativas a la operación, administración, seguridad e integridad del sistema de servidores raíz de Internet.

      Visto y considerando: Que los Estatutos de la ICANN requieren que la Junta Directiva de la ICANN designe a un miembro del RSSAC de cada Organización de Operadores de Servidores Raíz, sobre la base de las recomendaciones realizadas por los co-presidentes del RSSAC.

      Visto y considerando: Que, en febrero de 2019, el Centro de Coordinación de la Red Réseaux IP Européens (RIPE NCC) solicitó cambiar su representante por el resto del período actual, que finaliza el 31 de diciembre de 2020.

      Visto y considerando: Que los co-presidentes del RSSAC han recomendado a la Junta Directiva de la ICANN designar un representante de RIPE NCC ante el RSSAC.

      Resuélvase (2019.03.14.06): La Junta Directiva de la ICANN designa a Kaveh Ranjbar para el RSSAC hasta el 31 de diciembre de 2020.

      Fundamento de la resolución 2019.03.14.06

      En mayo de 2013, las organizaciones de operadores de servidores raíz acordaron la composición inicial de su membresía ante el RSSAC, y cada una nominó un candidato. La Junta Directiva de la ICANN aprobó la composición inicial del RSSAC en julio de 2013, con mandatos escalonados.

      En febrero de 2019, RIPE NCC solicitó cambiar su representante por el resto del período actual, que expira el 31 de diciembre de 2020.

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

      Esta resolución es una función organizacional y administrativa respecto de la cual no se requiere comentario público. La designación de los miembros del RSSAC honra el compromiso asumido por la ICANN de fortalecer la seguridad, estabilidad y flexibilidad del DNS.

    7. Aprobación de la enmienda al contrato de funciones de nombres de la IANA

      Visto y considerando: Que los Estatutos de la ICANN, en la Sección 16.3, requieren que la ICANN y la entidad de la PTI mantengan un Contrato de Funciones de Nombres de la IANA para el desempeño de la PTI de la función de nombres de la IANA. El contrato inicial de la función de nombres de la IANA fue aprobado por las juntas de la ICANN y PTI en 2016 como parte de la transición de la custodia de la IANA.

      Visto y considerando: Que el Contrato de la función de nombres de la IANA actualmente incluye una tabla que especifica los Acuerdos de nivel de servicio operacional (tabla de SLA) según lo acordado con la comunidad de múltiples partes interesadas durante el proceso de transición de la custodia de la IANA.

      Visto y considerando: Que la organización de la ICANN, la entidad de la PTI y el Comité Permanente de Clientes (CSC) han identificado que solicitar una modificación al Contrato de la Función de Nombres de la IANA cada vez que se debe modificar, eliminar o agregar un SLA individual no resulta sostenible y no satisface las necesidades de la ICANN, la entidad de la PTI o los clientes de la función de nombres de la IANA. Por lo tanto, se elaboró una propuesta para enmendar el Contrato de la función de nombres de la IANA en una oportunidad para sacar la Tabla de SLA del Contrato, y para exigir que todo cambio en dichos SLA sigan un "Proceso aprobado y publicado para enmendar los Acuerdos de Nivel de Servicio de la Función de Nombres de la IANA".

      Visto y considerando: Que la organización de la ICANN, la entidad de la PTI y el CSC participaron en el desarrollo del Proceso para enmendar los Acuerdos de Nivel de Servicio de la Función de Nombres de la IANA, y el CSC compartió ese proceso con los clientes de la Función de Nombres de la IANA.

      Visto y considerando: Que la ICANN solicitó comentarios públicos sobre la enmienda propuesta al Contrato de la función de nombres de la IANA del 7 de enero de 2019 al 18 de febrero de 2019.

      Visto y considerando: Que el foro de comentarios públicos sobre la enmienda propuesta al Contrato de la función de nombres de la IANA se cerró el 18 de febrero de 2018, y que la ICANN recibió un comentario del Grupo de Partes Interesadas de Registros que respalda la enmienda propuesta. Se publicó y proporcionó a la Junta Directiva un resumen y análisis de los comentarios el 25 de febrero de 2019.

      Resuélvase (2019.03.14.07): Se aprueba la Enmienda propuesta No. 1 al Contrato de Funciones de Nombres de la IANA y se autoriza al Presidente y Director Ejecutivo, o a quien éste designe, a tomar las medidas apropiadas para finalizar e implementar dicho Acuerdo.

      Fundamento de la resolución 2019.03.14.07

      El Comité Permanente de Clientes (CSC), que trabaja con la organización de la ICANN y la entidad de la PTI, ha recomendado cambios sobre la base de la evidencia de los datos operativos acumulados. Al proponer que los SLA se trasladen del contrato a una tabla de SLA en una página web de la entidad de la PTI, se reconoció que se requería un proceso de cambio de los SLA integral para garantizar que se realicen las consultas adecuadas con los clientes de la función de la IANA y con la comunidad de la ICANN en general.

      En su reunión celebrada el 17 de diciembre de 2018, el CSC aprobó los dos procesos de cambio de SLA: un 'Proceso para enmendar los acuerdos de nivel de servicio de la función de nombres de la IANA' y un 'Procedimiento para modificar el proceso de enmienda de los acuerdos de nivel de servicio de la función de nombres de la IANA'. La gerencia de la organización de la ICANN y la entidad de la PTI participaron en las conversaciones y también acordaron los procesos. Los procesos no estarán vigentes hasta que se modifique el contrato de la función de nombres.

      La Junta Directiva se encuentra aprobando la modificación del Contrato de la función de nombres de la IANA en este momento porque pasar los SLA de la función de nombres de la IANA del contrato a una tabla de SLA en una página web permite que los cambios a los SLA satisfagan de manera más eficiente las necesidades de los clientes de nombres, en tanto que la adhesión al nuevo " Proceso para enmendar los acuerdos de nivel de servicio de nombres de la IANA "garantiza que todos estos cambios sigan un proceso estricto para asegurar los niveles adecuados de consulta y acuerdo de la comunidad entre el CSC y la ICANN / PTI.

      La acción de la Junta Directiva toma en consideración los aportes de la comunidad, que avalaron la enmienda a través de la aprobación del CSC, y el comentario público del RySG que declaró que "Esta enmienda al Contrato de Funciones de Nombres de la IANA adopta un proceso de cambio de los SLA que se desarrolló y acordó de manera cooperativa entre el CSC, la entidad de la PTI y la organización de la ICANN. El proceso de cambio de los SLA permitirá al CSC y a la entidad de la PTI a) modificar los SLA cuando corresponda b) agregar nuevos SLA a medida que los nuevos servicios estén en línea y, c) eliminar los SLA que ya no se justifiquen. El RySG respalda la Enmienda y solicita a la Junta Directiva de la ICANN que la apruebe para que aquellos SLA que actualmente deban ser modificados, agregados o eliminados, se logren a la brevedad posible”.

      La acción impartida en esta resolución no tendrá ningún otro impacto en los recursos de la ICANN ni en la seguridad y estabilidad del Sistema de Nombres de Dominio (DNS). Esta acción está dentro de la misión de la ICANN, y avala que la ICANN lleve a cabo las funciones de nombres de la IANA.

    8. Agradecimiento al anfitrión local de la Reunión N.º 64 de la ICANN

      La Junta desea expresar su agradecimiento a la Sra. Yukari Sato, Ministro de Estado de Asuntos Internos y Comunicaciones, al Sr. Kizō Hisamoto, Alcalde de la ciudad de Kobe, al Profesor Jun Murai, Presidente del Comité Local de ICANN64 y al los miembros del Comité local de ICANN64, GMO Internet Inc., Japan Registry Services Co. Ltd., Internet Initiative Japan Inc., Internet Association Japan, Internet Multifeed Co., Interlink Co. Ltd., NTT Docomo Inc., Telecom Services Association, Centro de Información de Redes de Japón, BusinessRalliart Inc., Colegio de Estudios de Posgrado en Informática de Kyoto, Com Laude (Japan) Corporation, Taka Enterprise Ltd., Asociación de Proveedores de Japón, WIDE Project, NTT Communications Corporation, KDDI Corporation, Nippon Telegraph y Telephone West Corporation. También, agradece al Ministerio de Asuntos Internos y Comunicaciones, Kobe Convention Bureau y la Fundación Tsutomu Nakauchi por su gran apoyo.

    9. Agradecimiento a los patrocinadores de la Reunión N.º 64 de la ICANN

      La Junta Directiva desea agradecer a los siguientes patrocinadores: Verisign, Public Interest Registry, Afilias plc y CentralNic.

    10. Agradecimiento a los intérpretes, el personal y los equipos del hotel y eventos de la Reunión N.º 64 de la ICANN

      La Junta Directiva expresa su agradecimiento a los escribas (transcriptores), intérpretes, equipo audiovisual, equipos técnicos y todo el personal de la ICANN por los esfuerzos realizados para que la reunión se llevara a cabo en forma correcta y agradable. La Junta Directiva también desea agradecer a la administración y al personal de Kobe Portopia Hotel y al Centro Internacional de Conferencias de Kobe por brindar una sede maravillosa para celebrar este evento. Hacemos extensivo el agradecimiento especial al equipo del Centro Internacional de Conferencias de Kobe, Omura Masatoshi, Rikako Nakanishi, Aya Fukuda, Eiji Makatsuj i, Yuko Zikumaru, Tetsuya Shori y Lance Ferguson y al personal de TI y eventos del Kobe Portopia Hotel, Hitoshi Nakauchi, Kenji Kino, Shingo Murakami, Takumi Nishihara, Tomoko Nishio, Tomoya Takeda, Makoto Sakai, Shohei Inoue, Yosuke Taniguchi, Rose Tanasugarn y Gilbert Yeo, Gerente de Pryde Productions.

    Todos los miembros de la Junta presentes votaron a favor de las Resoluciones 2019.03.14.01, 2019.03.14.02, 2019.03.14.03, 2019.03.14.04, 2019.03.14.05, 2019.03.14.06 y 2019.03.14.07. Las resoluciones fueron aprobadas.

  2. Orden del día principal:

    El Presidente de la Junta Directiva presentó el Orden del día principal.

    1. Recomendaciones para la gestión de TLD con variantes de Nombres de Dominio Internacionalizados (IDN)

      Akinori Maemura presentó el tema del orden del día. Luego de leer la resolución propuesta para que conste en actas, Akinori señaló que la resolución propuesta es el resultado de mucho trabajo y aportes de la Comunidad. Ahora se solicita a la Junta Directiva que apruebe las recomendaciones resultantes de ese trabajo y que la ccNSO y la GNSO tengan en cuenta las recomendaciones al desarrollar sus políticas respectivas para definir y administrar los TLD con variantes de IDN actuales y para las futuras solicitudes de TLD.

      Akinori presentó la moción y Danko Jevtovic la secundó. El Presidente de la Junta llamó a votación y la Junta Directiva tomó la siguiente medida:

      Visto y considerando: Que los nombres de dominio internacionalizados (IDN) permiten a los usuarios de Internet acceder a los nombres de dominio en sus propios idiomas y siguen siendo un componente clave del trabajo de la ICANN.

      Visto y considerando: Que la Junta Directiva reconoce que las variantes de IDN son un componente importante para algunas cadenas de dominios de alto superior (TLD) con variantes de IDN y que la implementación de etiquetas de variantes en la zona raíz debe realizarse de manera tal que se mantenga la seguridad y la estabilidad del DNS.

      Visto y considerando: Que la Junta Directiva resolvió en 2010 que los TLD con variantes de IDN no se delegarían hasta que se completase el trabajo relevante y se ordenó a la organización de la ICANN elaborar un informe que identifique qué debe hacerse con la evaluación, posible delegación, asignación y operación de dominios genéricos de alto nivel (gTLD) que contienen caracteres variantes de IDN a fin de facilitar el desarrollo de enfoques viables para la implementación de gTLD con caracteres variantes de IDN.

      Visto y considerando: Que sobre la base de seis estudios de caso, integrados en un estudio de problemas relacionados con la gestión de TLD con variantes de IDN en 2012, la organización de la ICANN y la comunidad identificaron dos brechas que abordar: primero, que no existe una definición de TLD con variante de IDN, y segundo que no existe un mecanismo de gestión de TLD con variantes IDN.

      Visto y considerando: Que el Procedimiento para Desarrollar y Mantener las Reglas de Generación de Etiquetas para la Zona Raíz con respecto a las Etiquetas de los Nombres de Dominio Internacionalizados en Aplicaciones (IDNA)(Procedimiento RZ-LGR) ha sido desarrollado por la comunidad para definir los TLD con variantes de IDN y, siguiendo la resolución de la Junta Directiva en 2013 que aprobó el Procedimiento RZ-LGR, ha sido implementado para desarrollar de manera incremental las Reglas de Generación de Etiquetas de la Zona Raíz para abordar la primera brecha.

      Visto y considerando: Que la organización de la ICANN ha desarrollado las Recomendaciones para la Gestión de TLD con Variantes de IDN (las Recomendaciones sobre TLD variantes), se finalizó una recopilación de seis documentos luego de incorporar los comentarios públicos y se publicaron como mecanismos para abordar la segunda brecha identificada por la comunidad en la implementación de TLD con variante de IDN.

      Resuélvase (2019.03.14.08): La Junta Directiva aprueba las Recomendaciones sobre los TLD Variantes y solicita que la ccNSO y la GNSO tengan en cuenta las Recomendaciones sobre los TLD variantes al desarrollar sus políticas respectivas para definir y administrar los TLD con variantes de IDN para las solicitudes presentes y futuras de TLD.

      Resuélvase (2019.03.14.09): La Junta Directiva solicita que la ccNSO y la GNSO se mantengan mutuamente informadas sobre el avance en el desarrollo de los detalles relevantes de sus políticas y procedimientos para garantizar una solución uniforme, basada en las Recomendaciones de ccTLD y gTLD con variantes de IDN.

      Resuélvase (2019.03.14.10): La Junta Directiva también reconoce el importante esfuerzo y contribución de la comunidad, desde el inicio del Proyecto de Variantes de IDN en 2011, que ha llevado al desarrollo de las Recomendaciones sobre TLD variantes.

      Todos los miembros presentes de la Junta votaron a favor de las Resoluciones 2019.03.14.08, 2019.03.14.09 y 2019.03.14.10. Las resoluciones fueron aprobadas.

      Fundamentos de las resoluciones 2019.03.14.08 – 2019.03.14.10

      Los nombres de dominio internacionalizados (IDN) permiten a las personas de todo el mundo usar nombres de dominio en idiomas y códigos de escritura locales. Algunas comunidades de códigos de escritura han identificado que las etiquetas de dominio técnicamente distintas pueden considerarse indistinguibles en relación con otras etiquetas de dominio y, por lo tanto, etiquetas "iguales", denominadas etiquetas variantes. El estándar de IDN en Aplicaciones (IDNA) de 2008, al tiempo que estipula cómo usar nombres de dominio en múltiples códigos de escritura, también solicita en el RFC 58941 que "los registros deban desarrollar y aplicar otras restricciones, según sea necesario para reducir la confusión y otros problemas.… Para muchos códigos de escritura, el uso de técnicas variantes … puede ser útil para disminuir los problemas que los usuarios pueden percibir. …En general, los usuarios se beneficiarán si los registros solo permiten caracteres de códigos de escritura que son bien entendidos por el registro o sus asesores".

      Sobre la base del estándar IDNA2008, las etiquetas de variantes deben, al menos, identificarse y gestionarse para garantizar que los usuarios finales no sufran amenazas de seguridad. Algunas de las etiquetas de variante identificadas podrían incluso activarse para promover la usabilidad de los IDN, ya que diferentes comunidades de idiomas que usan un código de escritura pueden usar una etiqueta variante diferente. En algunos casos, las solicitudes para ccTLD con variantes de IDN y los nuevos gTLD han identificado otras etiquetas consideradas como etiquetas de variante, lo que indica que la comunidad puede considerar estas etiquetas diferentes como variantes entre sí. Sin embargo, debido a la falta de una definición clara y una solución para implementarlas, la Junta Directiva de la ICANN resolvió el 25 de septiembre de 2010 que "no se delegarán variantes de los gTLD a través del Programa de nuevos gTLD hasta que se desarrollen las soluciones de gestión de variantes adecuadas". La resolución además ordenó al personal de la ICANN desarrollar "un informe de cuestiones que identifique lo que debe hacerse con la evaluación, posible delegación, asignación y operación de gTLD que contengan caracteres variantes de IDN como parte del proceso de nuevos gTLD para facilitar el desarrollo de enfoques viables para la implementación de gTLD que contengan caracteres variantes de IDN”.

      Lograr estos objetivos de seguridad y usabilidad de manera estable es el desafío clave que debe abordarse. Para abordar estos complejos problemas lingüísticos y técnicos, la organización de la ICANN emprendió el Proyecto de cuestiones sobre variantes de IDN bajo la dirección de la Junta Directiva de la ICANN. Como primer paso, se comprometió con expertos de seis comunidades de códigos de escritura, que analizaron las cuestiones para identificar etiquetas de variantes para cada uno de estos códigos de escritura. Este análisis de cuestiones para los códigos de escritura en árabe , chino, cirílico , devanagari , griego y latino en 2011, integrado en el Informe de cuestiones integrado (IIR) (2012) identificó dos desafíos:

      1. "en el entorno del DNS actual, no existe una definición aceptada de lo que puede constituir una relación variable entre las etiquetas de alto nivel
      2. "Tampoco existe un mecanismo de 'gestión de variantes' para el alto nivel, aunque tal se ha propuesto a menudo como una manera de brindar soluciones a un problema particular".

      1. Definición de los TLD Variantes

      El IIR describió el trabajo de seguimiento que podría llevarse a cabo. Con posterioridad a este informe, la organización de la ICANN y la comunidad desarrollaron el Procedimiento para desarrollar y mantener reglas para la generación de etiquetas para la zona raíz con respecto a las etiquetas de IDNA (Procedimiento RZ-LGR) . Sobre la base de la directiva de la Junta Directiva de la ICANN el 11 de abril de 2013, la ICANN llevó a cabo el Procedimiento RZ-LGR que sigue un proceso de dos pasos, que requiere que cada comunidad desarrolle una propuesta de Reglas de generación de etiquetas (LGR) individuales basadas en códigos de escritura y un panel de expertos para revisar y integrar cada propuesta en el conjunto de Reglas para la Generación de Etiquetas para la Zona Raíz (RZ-LGR). Múltiples comunidades de códigos de escritura han finalizado sus propuestas, de las cuales se han incorporado las propuestas sobre códigos de escritura en árabe, etíope, georgiano, jemer, lao y tailandés, a la segunda versión, RZ-LGR-2. Muchas otras comunidades de códigos de escritura también se encuentran trabajando de forma activa en la definición de sus reglas. Además, se ha desarrollado una especificación para codificar estos detalles lingüísticos en un formato formal legible por computadores y ha sido publicado mediante el IETF como norma de seguimiento RFC 7940: Representación de conjuntos de reglas para la generación de etiquetas mediante XML. También se ha desarrollado una herramienta de LGR para crear, usar y administrar las LGR, y está disponible en línea para la comunidad y para descargar con una licencia de código abierto.

      2. Análisis de los Mecanismos de Gestión de TLD variantes

      Las reglas de generación de etiquetas para la zona raíz derivadas del proceso descrito anteriormente producen etiquetas de TLD variantes que son candidatas para la distribución. Para abordar la segunda parte de la necesidad declarada en el Informe Integrado de Cuestiones con respecto a un mecanismo de gestión de variantes para el alto nivel, es necesario que la comunidad de la ICANN desarrolle las políticas y procedimientos que rigen dicha distribución de nombres variantes. El conjunto de documentos, finalizado después de un comentario públicopublicado , ofrece recomendaciones para consideración por parte de la ccNSO y la GNSO durante el desarrollo de políticas y procedimientos relevantes de acuerdo con sus respectivos Procesos de Desarrollo de Políticas (PDP). Estos documentos también analizan las recomendaciones y su impacto en el proceso de solicitud de gTLD, tal como se describe en la Guía para el solicitante de nuevos gTLD, y en el proceso de solicitud de ccTLD con variantes de IDN, en función del Plan de implementación final para el Proceso de Avance Acelerado de Dominios de Alto Nivel con Código de País dentro de Nombres de Dominio Internacionalizados (IDN ccTLD). Las premisas fundamentales para las recomendaciones y el análisis presentado surgen principalmente de las observaciones de la comunidad en el Informe Integrado de Cuestiones y el asesoramiento presentado por el Comité Asesor de Seguridad y Estabilidad (SSAC) en su informe SAC 60.

      Al desarrollar el análisis, el equipo de la organización de la ICANN ha tenido múltiples interacciones con el Grupo de Trabajo sobre IDN de la Junta Directiva de la ICANN (BIWG) desde 2014, y el BIWG ha guiado el desarrollo de este trabajo. Las recomendaciones han sido diseñadas para ser conservadoras, en vistas de que los TLD con variantes de IDN se están implementando por primera vez, y que la solución podría adaptarse a la experiencia de implementación a lo largo del tiempo.

      La Junta Directiva de la ICANN observa que el trabajo de RZ-LGR está en marcha. La Junta Directiva de la ICANN también observa que el conjunto inicial de recomendaciones para implementar TLD con variantes de IDN de forma conservadora y uniforme está disponible para su posterior consideración por parte de la ccNSO y la GNSO en su trabajo para desarrollar políticas y procedimientos relevantes. Con los requisitos previos identificados por la comunidad en el Informe Integrado de Cuestiones, las organizaciones de apoyo (SO) pueden avanzar en los próximos pasos.

      Esto tendrá un impacto positivo para la comunidad, aunque hay algunos riesgos asociados. Al menos, los TLD con variantes de IDN identificados son retenidos al momento de la solicitud, lo que contribuirá a la seguridad de los usuarios finales, hasta que las organizaciones de apoyo hayan desarrollado un mecanismo de gestión posiblemente viable. Además, si la ccNSO y la GNSO pueden acordar mecanismos de administración uniformes para delegar algunas de estas etiquetas de variante, pueden contribuir a promover la usabilidad de los nombres de dominio en las comunidades que requieren estos TLD con variantes de IDN. Existe un riesgo asociado con la realización de este trabajo, especialmente si la comunidad no está de acuerdo con un enfoque uniforme para los TLD, ya que esto puede confundir a los usuarios finales, o en otros casos, puede causarles problemas relacionados con la seguridad. Los TLD con variantes de IDN también pueden provocar agobio en la gestión para los registratarios, según lo identifica el SSAC en su informe SAC060. Tras la resolución, la ccNSO y la GNSO deberán desarrollar sus propias políticas y procedimientos para implementar los TLD con variantes de IDN, teniendo en cuenta las recomendaciones proporcionadas. Sin embargo, esta resolución no instruye a la ccNSO o a la GNSO realizar un trabajo de políticas sobre este tema. Cuando los respectivos informes finales que contienen recomendaciones de políticas, desarrollados a través de los PDP apropiados, se envíen a la Junta Directiva de la ICANN para su aprobación, la Junta considerará la eficacia con la que estas políticas y procedimientos abordan las recomendaciones de los TLD variantes, su impacto y los riesgos asociados. En ese momento, la Junta Directiva decidirá si adopta las recomendaciones de políticas y si avanza en la implementación de los TLD con variantes de IDN.

      Finalmente habrá un impacto fiscal. El alcance del impacto fiscal dependerá del eventual proceso de evaluación de la solicitud del TLD con variante de IDN y del plazo de este proceso de solicitud sugerido por la comunidad. Por lo tanto, el impacto deberá evaluarse cuando la ccNSO y la GNSO finalicen sus políticas y procedimientos para implementar los TLD con variantes de IDN y los presenten para su consideración ante la Junta Directiva de la ICANN.

      Las recomendaciones contribuyen a una operación segura y estable del sistema de identificadores únicos, al tiempo que abordan la necesidad de TLD con variantes de IDN identificada por la comunidad y respetan el rol de desarrollo de políticas de la comunidad. El trabajo sobre los TLD con variantes de IDN también contribuye al interés público al mejorar el acceso al Sistema de Nombres de Dominio (DNS) de Internet en diferentes códigos de escritura e idiomas.

    2. Preparación para la implementación de los procedimientos posteriores a la Introducción de Nuevos gTLDs.

      Ron da Silva, el presidente del Comité de Finanzas de la Junta Directiva (BFC) presentó el punto del orden del día. Ron explicó que el BFC ha solicitado que el punto se elimine del orden del día porque, si bien la organización de la ICANN ha completado la planificación preliminar, el BFC desea realizar otra evaluación de los costos generales y el modelo de financiamiento. Si bien la organización de la ICANN ha logrado un progreso significativo en el desarrollo de un plan de implementación del proyecto, el BFC ha solicitado a la organización que proporcione un plan más completo y las proyecciones asociadas para que el BFC lo considere más a fondo y luego lo haga la Junta Directiva en un futuro próximo.

      Luego del debate, el Presidente indicó que el punto quedaba removido del orden del día.

    3. Transferencia del dominio de alto nivel .VU (Vanuatu) al Regulador de Radiocomunicaciones y Radiodifusión de Telecomunicaciones (TRBR).

      Chris Disspain presentó el tema del orden del día. Chris explicó que se requiere que la ccNSO ocupe tres puestos en el Equipo para la Revisión de la Función de Nombres de la IANA, uno de los cuales no debe ser miembro de la ccNSO. La ccNSO tiene dificultades para ocupar estas posiciones. Hay una serie de posibles soluciones para resolver este problema, sin embargo, hasta que se identifique la mejor solución para avanzar, este punto del orden del día no está listo para ser sometido a consideración de la Junta Directiva. Cuando sea apropiado, el punto será sometido a consideración de la Junta Directiva en la próxima oportunidad posible.

      Nigel Roberts presentó la moción y Chris la secundó. El Presidente de la Junta llamó a votación y la Junta Directiva tomó la siguiente medida:

      Resuélvase (2019.03.14.11): Como parte del ejercicio de sus responsabilidades conforme al Contrato de Funciones de Nombres de la IANA con la ICANN, la PTI ha revisado y evaluado la solicitud de transferencia del dominio de alto nivel con código de país .VU al Regulador de Radiocomunicaciones y Radiodifusión de Telecomunicaciones ( TRBR). La documentación demuestra que se siguieron los procedimientos adecuados durante la evaluación de la solicitud.

      Todos los miembros de la Junta Directiva presentes votaron a favor de la resolución 2019.03.14.11. La resolución fue aprobada.

      Fundamento de la resolución 2019.03.14.11

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

      De acuerdo con el Contrato de Funciones de Nombres de la IANA, la entidad PTI ha evaluado una solicitud de transferencia de un dominio de alto nivel con código de país (ccTLD) y presenta su informe ante la Junta Directiva para revisión. La revisión por parte de la Junta Directiva tiene por objetivo verificar que se hayan seguido los procedimientos adecuados.

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

      La propuesta es aprobar una solicitud para transferir el dominio de alto nivel con código de país .VU y asignar el rol de administrador al Regulador de Radiocomunicaciones y Radiodifusión de Telecomunicaciones (TRBR).

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

      Durante la evaluación de una solicitud de transferencia, la entidad PTI consultó al solicitante y a otras partes interesadas relevantes. Como parte del proceso de solicitud, es necesario que el solicitante describa las consultas realizadas en el país en relación con el ccTLD y su aplicabilidad a la comunidad local de Internet.

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

      La ICANN no tiene conocimiento de ninguna inquietud o cuestión significativa planteada por la comunidad en relación con esta solicitud.

      ¿Qué materiales significativos analizó la Junta Directiva?

      [OMITIDO – Información confidencial sobre la Delegación]

      ¿Qué factores la Junta Directiva consideró significativos?

      La Junta Directiva no identificó ningún factor específico importante respecto de esta solicitud.

      ¿Existen impactos positivos o negativos para la comunidad?

      La aprobación oportuna de administradores de nombres de dominio con código de país que cumplen con los diversos criterios de interés público no sólo tiene un impacto positivo para la misión de la ICANN a nivel general y para las comunidades locales a las que están destinados dichos dominios, sino que además responde a las obligaciones previstas en el Contrato de Funciones de Nombres de la IANA.

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

      La administración de las delegaciones de dominios con código de país en la zona raíz del DNS forma parte de las funciones de la IANA y, por ello, la acción de delegación no debería causar variaciones de importancia en los gastos ya planificados. No corresponde a la ICANN evaluar el impacto financiero de las operaciones internas de los nombres de dominio con código de país dentro de un país.

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

      La ICANN considera que esta solicitud no implica riesgos significativos para la seguridad, estabilidad o flexibilidad. Esta decisión forma parte de las funciones administrativas y organizativas que no requieren comentario público.

    4. Considerar la Solicitud de Reconsideración 16-5: DotMusic Limited

      León Sánchez, presidente del Comité de Mecanismos de Responsabilidad de la Junta Directiva (BAMC), presentó el tema del orden del día. León señaló que el BAMC ha considerado minuciosamente los méritos de la Solicitud 16-5 y todos los materiales relevantes y recomendó que se rechace la Solicitud 16-5 porque el Proveedor de Evaluación con Prioridad de la Comunidad (CPE) no infringió ninguna política o procedimiento establecido al realizar la CPE y la organización de la ICANN cumplió con las políticas establecidas, los Estatutos y las Actas Constitutivas cuando aceptó el Informe de CPE. El BAMC también recomendó que la Junta Directiva rechace la Solicitud 16-5 porque los Solicitantes no identificaron ninguna aplicación incorrecta de la política o el procedimiento por parte del Proveedor de CPE que haya afectado de manera significativa o adversa a los Solicitantes. Por lo tanto, la resolución es que la Junta adopte la recomendación del BAMC con respecto a la Solicitud 16-5. Como parte de su consideración de este asunto, la Junta Directiva ha recibido todos los materiales relevantes en relación a la Solicitud 16-5.

      Becky Burr señaló que se abstenía de emitir su opinión sobre el asunto, e indicó un posible conflicto de intereses.

      León presentó la resolución propuesta y Sarah Deutsch la secundó. El Presidente de la Junta llamó a votación y la Junta Directiva tomó la siguiente medida:

      Visto y considerando: Que DotMusic Limited (DotMusic) presentó una solicitud presentada por una comunidad para .MUSIC (la Solicitud), que se colocó dentro de un conjunto de solicitudes controvertidas junto con otras solicitudes para .MUSIC.

      Visto y considerando: Que, DotMusic participó en la Evaluación con Prioridad de la Comunidad (CPE) y no prevaleció.

      Visto y considerando: Que, DotMusic, la Federación Internacional de Músicos, la Federación Internacional de Consejos de las Artes y Agencias de Cultura, la Red Mundial Independiente, la Red Merlin, la Asociación de Compañías de Música Independientes, la Asociación Americana de Música Independiente, la Asociación de Música Independiente, la Coalición de Creadores de Contenido, la Asociación Internacional de Compositores de Nashville y ReverbNation (colectivamente, los Solicitantes) presentaron la Solicitud de reconsideración 16-5, en la que buscaban que se reconsiderara informe de CPE de la Solicitud y la aceptación por parte de la ICANN de dicho informe.

      Visto y considerando: Que, si bien la Solicitud 16-5 estaba pendiente, la Junta Directiva ordenó a la organización de la ICANN que realizara una revisión del proceso de CPE (la Revisión del Proceso de CPE). El Comité de Gobernanza de la Junta Directiva (BGC) determinó que las Solicitudes de reconsideración pendientes en relación al proceso de CPE, incluida la Solicitud 16-5, quedarían en suspenso hasta que finalice la revisión del proceso de CPE. 2

      Visto y considerando: Que el día 13 de diciembre de 2017, la organización de la ICANN publicó los tres informes sobre la revisión del proceso de CPE (los Informes sobre la revisión del proceso de CPE).

      Visto y considerando: Que el día 15 de marzo de 2018, la Junta Directiva presentó las Resoluciones 2018.03.15.08 a 2018.03.15.11, en las que reconoció y aceptó las conclusiones presentadas en los Informes sobre la revisión del proceso de CPE; declaró que se completó la revisión del proceso de CPE; concluyó que, como resultado de las conclusiones que se incluyen en los Informes sobre la revisión del proceso de CPE, no es necesario realizar ninguna revisión ni cambio en el proceso de CPE para la ronda actual del Programa de Nuevos gTLD; y ordenó al Comité de Mecanismos de Responsabilidad de la Junta Directiva (BAMC) que avance con la consideración de las Solicitudes de reconsideración restantes y relacionadas con el proceso de CPE, que se habían suspendido hasta la finalización de la revisión del proceso de CPE.

      Visto y considerando: Que, de conformidad con las Resoluciones 2018.03.15.08 a 2018.03.15.11, el BAMC invitó a los Solicitantes a presentar materiales adicionales y a efectuar hacer una presentación ante el BAMC en apoyo de la Solicitud 16-5; Los Solicitantes rechazaron ambas invitaciones del BAMC.

      Visto y considerando: Que, el BAMC ha considerado cuidadosamente los méritos de la Solicitud 16-5 y todos los materiales relevantes y ha recomendado que se rechace la Solicitud 16-5 porque el Proveedor de CPE no infringió ninguna política o procedimiento establecido al realizar la CPE y la organización de la ICANN cumplió con las políticas establecidas, los Estatutos y las Actas Constitutivas cuando aceptó el Informe de CPE. El BAMC también recomendó que la Junta Directiva rechace la Solicitud 16-5 porque los Solicitantes no identificaron ninguna aplicación incorrecta de la política o el procedimiento por parte del Proveedor de CPE que haya afectado de manera significativa o adversa a los Solicitantes.

      Visto y considerando: Que la Junta Directiva ha considerado exhaustivamente la Recomendación del BAMC sobre la Solicitud 16-5 y todos los documentos pertinentes relacionados, incluida la refutación del Solicitante, y que la Junta Directiva expresa su acuerdo con la Recomendación del BAMC, a lo que concluye que la refutación no proporciona nuevos argumentos ni evidencia que fundamenten la reconsideración.

      Resuélvase (2019.03.14.12): La Junta Directiva adopta la Recomendación del BAMC sobre la Solicitud 16-5.

      Quince directores votaron a favor de la resolución 2019.03.14.12. Becky Burr se abstuvo. La resolución fue aprobada.

      Fundamento de la resolución 2019.03.14.12

      1. Resumen breve y recomendación

        Todos los antecedentes de hechos se describen en la Recomendación del BAMC sobre la Solicitud 16-5 (Recomendación del BAMC), que fue revisada y considerada por la Junta y se ha incorporado al presente documento.

        El 25 de enero de 2018, el BAMC evaluó la Solicitud 16-5 y todos los materiales relevantes y recomendó a la Junta que rechazara la Solicitud 16-5 porque el Proveedor de CPE no infringió ninguna política o procedimiento establecido al realizar la CPE y la organización de la ICANN cumplió con las políticas establecidas, los Estatutos y las Actas Constitutivas cuando aceptó el Informe de CPE. El BAMC también recomendó que la Junta Directiva rechace la Solicitud 16-5 porque los Solicitantes no identificaron ninguna aplicación incorrecta de la política o el procedimiento por parte del Proveedor de CPE que haya afectado de manera significativa o adversa a los Solicitantes.

        La Junta Directiva ha considerado cuidadosamente la Recomendación del BAMC y todos los materiales relevantes relacionados con la Solicitud 16-5, y la Junta está de acuerdo con la Recomendación del BAMC.

        El 12 de febrero de 2019, los Solicitantes presentaron una refutación a la Recomendación del BAMC (Refutación). La Junta Directiva observa que la Refutación no está contemplada en los Estatutos que se aplican a la Solicitud 16-5 3. Sin embargo, la Junta Directiva ha considerado los argumentos expuestos en la refutación de los Solicitantes y considera que no avalan la reconsideración por los motivos que se exponen a continuación.

      2. Cuestión

        Las cuestiones son las siguientes:

        • Si la Declaración del Panel del Proceso de Revisión Independiente (IRP) en Little Birch LLC et al. vs. ICANN y Despegar Online SRL et al. vs. ICANN (IRP de Despegar ) requiere que la Junta Directiva reconsidere el Informe de CPE;
        • Si la aceptación por parte de la Junta Directiva del Asesoramiento de Categoría 1 y 2 del Comité Asesor Gubernamental (GAC) de la ICANN, requirió que el Proveedor de CPE otorgue prioridad a la comunidad en la solicitud;
        • Si el proveedor de CPE tuvo un conflicto de intereses con respecto a la Solicitud;
        • Si la organización de la ICANN realizó alguna revisión al Informe de CPE y, de ser así, si esas revisiones se adhirieron a las políticas o procedimientos establecidos;
        • Si el proveedor de CPE se adhirió a las políticas y procedimientos aplicables en su aplicación del criterio 1 de la CPE. Establecimiento de la comunidad;
        • Si el proveedor de CPE adhirió a las políticas y procedimientos aplicables en su aplicación del sub criterio 2-A-Nexus de la CPE.
        • Si el proveedor de CPE adhirió a las políticas y procedimientos aplicables en su aplicación del sub criterio 4-A-Aval de la CPE.

        Estas cuestiones se consideran de conformidad con los estándares relevantes para solicitudes de reconsideración vigentes en el momento en que se presentó la Solicitud 16-5. Estos estándares se discuten en detalle en la Recomendación del BAMC y se incorporan aquí .

      3. Análisis y fundamentos

        1. Los criterios y procedimientos de la CPE

          La CPE es un mecanismo de resolución de conflictos a disposición de los solicitantes que auto-designaron sus solicitudes como solicitudes de la comunidad. 4 . Los estándares de la CPE y el proceso de la CPE se definen en el Módulo 4, Sección 4.2 de la Guía para el Solicitante (Guía). Las solicitudes presentadas por una comunidad que se someten a CPE se evalúan según los siguientes criterios: Criterio 1: Establecimiento de la comunidad; Criterio 2: Nexo entre la cadena de caracteres propuesta y la comunidad; Criterio 3: Políticas de registración; y Criterio 3: Aval de la comunidad. 5 De acuerdo con la Guía, la secuencia de los criterios refleja el orden en que esos criterios serán evaluados por el proveedor del CPE. Para prevalecer en la CPE, una solicitud debe recibir al menos 14 de los 16 puntos en la puntuación de los cuatro criterios, cada uno de los cuales vale un máximo de cuatro puntos. Una solicitud que prevalece en una CPE "elimina todas las solicitudes estándares en conflicto directamente, sin importar qué tan bien calificada estén estas últimas". 6 La CPE es llevada a cabo por un panel independiente compuesto por dos evaluadores que son designados por el proveedor de CPE. 7. El rol de un proveedor de CPE es determinar si la solicitud con prioridad de la comunidad cumple con los cuatro criterios de prioridad de la comunidad establecidos en el Módulo 4.2.3 de la Guía.8

          El proceso de CPE no determina la existencia, adecuación o validez de una comunidad. Simplemente evalúa si una solicitud presentada por una comunidad satisface los criterios de la CPE para la prioridad de la comunidad. Como se señala en la Guía, "un resultado del [proveedor de la CPE] de que una solicitud no cumple con el umbral de puntuación para prevalecer en una evaluación con prioridad de la comunidad no necesariamente indica que la comunidad en sí sea, de manera alguna, inadecuada o no válida". 9

        2. La Declaración del IRP de Despegar no avala la reconsideración.

          Los Solicitantes afirman que la reconsideración es apropiada porque el proceso de la CPE es supuesta y fundamentalmente defectuoso. En apoyo, los Solicitantes hacen referencia a la Declaración del IRP de Despegar que, según argumentan, señala los problemas y las inquietudes que el Panel de IRP tuvo en relación con el proceso de la CPE.10 Los Solicitantes sostienen que las preocupaciones expresadas por el Panel de IRP de Despegar demuestran que el Proveedor de la CPE y la Organización de la ICANN infringieron las políticas y procedimientos establecidos relacionados con la evaluación de la Solicitud. 11 El Panel de IRP de Despegar recomendó, entre otras cosas, que se establezca un sistema para futuras rondas de nuevos gTLD a fin de asegurar que las evaluaciones de CPE sean llevadas a cabo "de manera uniforme y previsible por diferentes evaluadores individuales” y que los valores fundamentales de la organización de la ICANN” fluyan a través de ... . entidades como el [proveedor de CPE]” 12. Los Solicitantes parecen afirmar que la Declaración de IRP de Despegar requiere que la Junta Directiva lleve a cabo una revisión del Proceso de CPE en su conjunto,— lo cual fue realizado por la Junta en la Revisión del Proceso de CPE,— o que rechace el Informe de la CPE sobre la base de las supuestas fallas. 13

          Sin embargo, como concluyó el BAMC, y la Junta Directiva concuerda, nada en la Declaración del IRP de Despegar ni la aceptación por parte de la organización de la ICANN exige ese resultado. Al aceptar la Declaración de IRP de Despegar (Resolución 2016), 14 la Junta Directiva "tomó nota de las sugerencias del Panel [IRP]" y ordenó a la organización de la ICANN que "se asegure de que las Revisiones del Programa de Nuevos gTLD tengan en cuenta las cuestiones planteadas por el Panel conforme se relacionen con la uniformidad y la previsibilidad del proceso de CPE y las evaluaciones de proveedores externos". 15 Por otro lado, la Revisión del proceso de la CPE brindó otra revisión minuciosa del proceso de la CPE, con una consideración especial de la relación de la organización de la ICANN con el Proveedor de CPE.16

          Nada sobre la Declaración del IRP de Despegar o su aceptación por parte de la Junta exige que se modifique el proceso de CPE para la Aplicación, 17  o que el BAMC modifique su estándar de revisión para las solicitudes de reconsideración que cuestionan los informes de CPE. En consecuencia, nada sobre la Declaración del IRP de Despegar o la Resolución de 2016 requiere que la Junta Directiva tome medidas con respecto al Informe de la CPE, más allá de determinar si la organización de la ICANN y el Proveedor de CPE siguieron la política y el procedimiento establecidos con respecto a ese informe. Como se explica más adelante, los Solicitantes no identifican violaciones a la política o al procedimiento establecidos con respecto al Informe de CPE.

          Además, en la medida en que los Solicitantes argumentan que la Declaración del IRP de Despegar exige que la Junta realice una revisión del Proceso de la CPE en su conjunto, como se describió anteriormente, la Junta Directiva realizó dicha revisión: la Revisión del Proceso de la CPE. DotMusic impugnó el resultado de la Revisión del proceso de la CPE en la Solicitud 18-5,18 que la Junta Directiva denegó.19 Los Solicitantes no han identificado ninguna información importante que la Junta Directiva no haya considerado, o cualquier información falsa o engañosa en la que se haya basado la Junta para negarse a anular el informe de la CPE a la luz de la Declaración del IRP de Despegar o bien al responder al mismo.

        3. La aceptación por parte de la Junta Directiva del asesoramiento de Categorías 1 y 2 del GAC no tiene relación con el reclamo de DotMusic por la prioridad de la comunidad.

          Los Solicitantes afirman que la organización de la ICANN debería haber dado "tratamiento preferencial" a la Solicitud en respuesta al Asesoramiento de Categoría 1 y 2 del GAC.20 El asesoramiento de Categoría 1 del GAC sugirió que ciertos tipos de cadenas de caracteres deben estar sujetas a otras salvaguardas. Estos tipos de cadenas de caracteres incluían: (A) cadenas de caracteres que abarcan sectores regulados; (b) cadenas de caracteres que plantean problemas de protección al consumidor; y (c) otras cadenas de caracteres sensibles. .MUSIC fue uno de los nuevos gTLD sujetos al asesoramiento de Categoría 1 del GAC como una cadena que plantea inquietudes referidas a la protección al consumidor,– a saber, cuestiones de propiedad intelectual.21 El asesoramiento de Categoría 2 del GAC sugirió, entre otras cosas, que las cadenas que representan términos genéricos (Cadenas de términos genéricos) no deben operarse como registros de acceso exclusivo a menos que hacerlo "sirva a un objetivo de interés público". 22 .MUSIC también fue una de las cadenas genéricas de términos sujeta al asesoramiento de Categoría 2 del GAC.

          El BAMC determinó, y la Junta Directiva concuerda, que nada en la aceptación y la respuesta de la Junta al asesoramiento de Categoría 1 y 2 del GAC exigía a la organización de la ICANN otorgar "tratamiento preferencial" a las solicitudes de la comunidad para .MUSIC.23El asesoramiento de Categoría 1 y 2 del GAC ni siquiera abordó las solicitudes presentadas por la comunidad en comparación con las solicitudes estándares. Además, al contrario de lo que afirman los Solicitantes, la cadena de caracteres .MUSIC estaba sujeta al asesoramiento de Categoría 1 porque planteaba problemas de propiedad intelectual, no porque involucrara a un sector regulado.24 Como tal, nada en relación al asesoramiento de Categoría 1 del GAC implicaba que .MUSIC involucraba a una comunidad con "cohesión" como lo sugieren los Solicitantes. 25 Con respecto al asesoramiento de Categoría 2, el GAC declaró que las Cadenas de Términos Genéricos, como .MUSIC, representaban términos genéricos para los cuales el acceso exclusivo al registro no era adecuado. El asesoramiento del GAC y la aceptación por parte de la organización de la ICANN del asesoramiento de categoría 2 no tienen efecto o relación con la prioridad de la comunidad. Por lo tanto, la Junta Directiva está de acuerdo con la conclusión del BAMC de que el argumento de los Solicitantes no respalda la reconsideración.

        4. Ninguna parte de las recomendaciones de la Organización de Apoyo para Nombres Genéricos (GNSO) exigía que los reclamos en relación a la prioridad de la comunidad fueran "tomados en custodia”.

          Los Solicitantes afirman que no se debería haber solicitado una CPE en absoluto porque la GNSO de la organización de la ICANN recomendó que las afirmaciones de representación de una comunidad de una solicitud se debían "tomar en custodia". 26 Los Solicitantes interpretaron erróneamente el texto de las pautas de implementación de la GNSO, que no son las recomendaciones de políticas de la GNSO, y que requieren algún tipo de CPE. Específicamente, la GNSO observó que:

          Cuando un solicitante presenta un reclamo en relación a que el TLD está destinado a respaldar a una comunidad en particular, como un TLD patrocinado, o cualquier otro TLD destinado a una comunidad específica, dicho reclamo se tomaría en custodia con las siguientes excepciones:

          (i) el reclamo se relaciona con una cadena de caracteres que también es objeto de otra solicitud y el reclamo para dar apoyo a una comunidad se está utilizando para ganar prioridad en relación a esa solicitud; y

          (ii) se inicia un proceso formal de objeción. 27

          En consecuencia, la Guía establece que " la evaluación de la designación de una solicitud como presentada por una comunidad tendrá lugar solo en el caso de una situación de conflicto que resulte en una evaluación con prioridad de la comunidad". 28 Un solicitante de una solicitud presentada por una comunidad debe elegir someterse a una CPE, aunque esto no sea de carácter obligatorio. Dichos solicitantes eligen hacerlo porque solo a mediante una CPE pueden obtener prioridad sobre otras solicitudes presentadas para la misma cadena. 29 Por lo tanto, no existe una política o procedimiento establecido que requiera que la organización de la ICANN tome el reclamos de DotMusic de prioridad comunitaria "en custodia". Como tal, la ICANN no infringió ninguna política o procedimiento al negarse a tomar el reclamo de DotMusic de prioridad comunitaria “en custodia".

        5. Los solicitantes no han demostrado ningún conflicto de intereses por parte del proveedor de la CPE.

          Los Solicitantes sostienen que el Proveedor de la CPE tuvo un conflicto de intereses con respecto a la Solicitud porque Eric Schmidt, Presidente Ejecutivo de Google de 2001 a 2017, fue miembro de la Junta Directiva del Grupo Economist, la empresa matriz del Proveedor de la CPE, desde noviembre de 2013 hasta diciembre de 2015, ,30 y Vint Cerf, vicepresidente de Google desde 2003, "presidió un Panel de estrategia de la ICANN en 2013 (cuando se estaban evaluando las solicitudes)", y Google también presentó una solicitud para .MUSIC.31 La Junta concuerda con el BAMC en que este argumento no admite la reconsideración por los siguientes motivos.

          Primero, los Solicitantes no presentan evidencia de que el Proveedor de la CPE no haya confirmado que algunos de los miembros del panel de evaluación o los miembros del equipo principal tuviera algún conflicto con respecto a las solicitudes presentadas por una comunidad como lo establece la Guía, el Documento del Proceso del Panel de la CPE y las Pautas de CPE .32 Los Solicitantes no aducen que —el ejecutivo de alto nivel,— Eric Schmidta, haya sido miembro del panel de evaluación o miembro del equipo principal (no lo era), o que tuvo alguna influencia o conocimiento sobre el Informe de CPE (o incluso si tuvo alguna participación de alguna índole con el proveedor de la CPE, que es una división única dentro del Grupo Economist). De hecho, el Informe de la CPE se emitió dos meses después de que el Sr. Schmidt dejara de ser miembro de la junta directiva del Grupo Economist. 33 Del mismo modo, DotMusic no ha explicado cómo la posición de Vint Cerf en un Panel de estrategia de la ICANN sobre el Ecosistema de gobernanza de Internet 34en 2013, tres años antes de la emisión del Informe de la CPE, afectó la Solicitud.

          En segundo lugar, el único fundamento para el argumento sesgado de los Solicitantes es su controversia (sobre la base de un conjunto de muestra de 22 informes de la CPE) de que las solicitudes presentadas por la comunidad, que estaban en conflicto con Google, tenían más probabilidades de no aprobar la CPE.35El hecho de que muchas solicitudes no prevalecieran en la CPE no indica ninguna infracción del procedimiento en absoluto. Toda solicitud que prevalezca en la CPE tiene prioridad sobre todas las demás solicitudes, por lo tanto, el proceso de la CPE establece intencionalmente un estándar alto para la prevalencia de una solicitud.36 Como tal, el hecho de que numerosas solicitudes no prevalecieran en la CPE no demuestra de manera alguna que el Proveedor de la CPE no se ciñera al procedimiento y la política establecidos para garantizar que los miembros del proveedor de la CPE no tuvieran conflictos con respecto a la Solicitud.37 Además, el Informe de CoE en el que se funda DotMusic para estos argumentos concluyó que "no hay pruebas de que Google haya influido en las decisiones tomadas sobre las CPE."38

        6. La organización de la ICANN no tiene relación con la la puntuación de los criterios de la CPE.

          Los Solicitantes argumentan que ciertas comunicaciones entre la organización de la ICANN y el proveedor de la CPE que se identificaron en el IRP Dot Registry vs. ICANN (Comunicaciones de la EPC) demuestran que la organización de la ICANN modificó “significativamente” el Informe de la CPE, infringiendo la política y el procedimiento establecidos.39 El BAMC concluyó, y la Junta Directiva concuerda, que no hay nada en las Comunicaciones de la CPE que avale la opinión de los Solicitantes de que la organización de la ICANN modificó la calificación del Proveedor de CPE en la Solicitud de DotMusic. El Informe de Alcance 1 de la Revisión del Proceso de la CPE confirma que "no hay evidencia de que la organización de la ICANN haya tenido influencia indebida en el Proveedor de la CPE con respecto a los informes de la CPE emitidos por el Proveedor de la CPE o que haya participado en alguna irregularidad en el proceso de la CPE", incluso con respeto a la Solicitud.40 Cuando la organización de la ICANN proporcionó información al Proveedor de la CPE, esa información no implicó cuestionar las conclusiones del Proveedor de la CPE (incluidas las determinaciones de calificación), sino más bien garantizar que los Informes de la CPE fueran claros y "que el Proveedor de la CPE hubiera participado en un debate serio sobre cada criterio de la CPE en su informe.41 El FTI observó que "la organización de la ICANN no sugirió que el Proveedor de la CPE realizara cambios en la calificación final ni adapte el fundamento establecidos en los informes de la CPE". 42

          Los Solicitantes no identifican una política o procedimiento establecidos (porque no existen) que impida que la organización de la ICANN se comunique con el Proveedor de la CPE en relación al texto contenido en los informes de la CPE. Tampoco existe nada en las comunicaciones de la CPE que demuestren, como argumentan los Solicitantes, que el Proveedor de la CPE careciera de la experiencia necesaria para llevar a cabo la evaluación. Como tal, los Solicitantes no han planteado un fundamento para la reconsideración a este respecto.

        7. El informe de la CPE no implicó derechos del debido proceso legal.

          La Junta Directiva está de acuerdo con la determinación del BAMC de que la afirmación de los Solicitantes de que el Proveedor de la CPE y la organización de la ICANN no siguieron el "debido proceso" no justifica la reconsideración 43 Los Solicitantes no han demostrado ninguna falla por parte del Proveedor de la CPE en cuanto al seguimiento de la política y los procedimientos establecidos para la CPE como se establece en la Guía.

          El BAMC señaló que los Estatutos pertinentes no hacen referencia al debido proceso.44. En última instancia, los Solicitantes están sugiriendo que debería haber un proceso formal de apelación para las decisiones de los proveedores de servicios externos de la organización de la ICANN, incluidos el Proveedor de la CPE, el Panel de Objeción por Derechos Legales y los Paneles por Confusión de Cadenas de Caracteres. Los métodos para impugnar las decisiones en el curso del proceso de resolución de disputas de gTLD se establecen en la Guía, que se desarrolló después de años de extensas discusiones con una amplia variedad de grupos de partes interesadas, incluidos gobiernos, individuos, unidades constitutivas de la sociedad civil, empresas y propiedad intelectual, y la comunidad tecnológica.45 Se publicaron numerosos borradores de la Guía para comentarios públicos, y se revisaron a la luz de los aportes significativos de la comunidad.46 El momento para cuestionar la Guía pasó hace mucho tiempo. 47

          Además, la Guía proporciona un mecanismo para impugnar los resultados del proceso de la CPE: El Módulo 6 de la Guía establece que los solicitantes, incluido DotMusic, "pueden utilizar todo mecanismo de responsabilidad establecido en los Estatutos de la ICANN para impugnar cualquier decisión final de la ICANN con respecto a la solicitud". 48 Los Solicitantes han ejercido este derecho al invocar el Proceso de reconsideración repetidamente, 49 incluido con la Solicitud 16-5.

          Debido a que la aplicación de los criterios de la CPE por parte del Proveedor de la CPE está en consonancia con la Guía, la aceptación por parte de la ICANN del Informe de la CPE también se encontraba en consonancia con las políticas y procedimientos aplicables, y no implicó ninguna infracción de "debido proceso". Tampoco el hecho de que no haya una opción para apelar el fundamento de los resultados de la evaluación implica una violación del debido proceso.

        8. El reclamo de los Solicitantes con respecto a los ingresos de las subastas no justifica la reconsideración.

          La Junta Directiva concuerda con la conclusión del BAMC de que los Solicitantes no han proporcionado ninguna evidencia (porque no existe) que avale la aseveración de los Solicitantes de que la aceptación por parte de la ICANN del Informe de la CPE fue motivada por algún tipo de incentivo financiero para obtener ingresos a través del proceso de subasta. Además, los Solicitantes no han demostrado que se haya infringido ninguna política o procedimiento aplicable de la ICANN. Por lo tanto, este argumento no justifica la reconsideración.

        9. El Proveedor de la CPE adhirió a las políticas y procedimientos vigentes en su aplicación de los criterios de la CPE.

          Los Solicitantes se oponen a la decisión del proveedor de la CPE de otorgar solo 10 de los 16 puntos posibles a la Solicitud. Por las razones expuestas en la Sección VI.I del Anexo 1 a la Recomendación del BAMC, que se incorporan aquí como referencia, la Junta Directiva concuerda con las conclusiones del BAMC de que la reconsideración no está justificada porque los Solicitantes no demostraron que el Proveedor de la CPE haya incumplido alguna norma, política o procedimiento establecidos para calificar la Solicitud. Además, la Junta Directiva concuerda con el BAMC en que el argumento de los Solicitantes representa un desacuerdo sustancial con las conclusiones del Proveedor de la CPE, y que esto no es fundamento suficiente para la reconsideración.

        10. Los reclamos de los solicitantes con respecto a la revisión del proceso de la CPE no admiten la reconsideración.

          El BAMC determinó, y la Junta Directiva concuerda, que los reclamos de los Solicitantes con respecto a la Revisión del Proceso de la CPE no justifican la reconsideración por todos los motivos detallados en la Sección VI.K del Adjunto 1 a la Recomendación del BAMC  que se adjunta aquí como referencia. Específicamente, la Junta Directiva considera que las críticas de los Solicitantes con respecto a la conclusión de la Revisión del Proceso de la CPE no justifican la reconsideración. La Junta Directiva observa además que abordó muchas de las inquietudes planteadas por los Solicitantes en su Acción sobre la Solicitud de Reconsideración 18-5, que se incorporan aquí como referencia.

          La Junta Directiva también está de acuerdo con la conclusión del BAMC de que la demanda del Solicitante DotMusic 50 de exigir que la organización de la ICANN divulgue todos los documentos relacionados con la Revisión del Proceso de la CPE no es requerido por ninguna política o procedimiento establecidos. Además, la Junta Directiva abordó previamente la demanda de DotMusic de los mismos documentos en su Acción en la Solicitud de reconsideración 18-1, que se incorpora aquí como referencia. La Junta Directiva también está de acuerdo con la conclusión del BAMC de que no existe una política o procedimiento establecido que requiera que la organización de la ICANN asuma las costas y gastos de DotMusic por la revisión de algún documento emitido por la organización de la ICANN y por la preparación de las presentaciones complementarias ante el BAMC con respecto a esos documentos. La Junta concuerda además con el BAMC en que no existe una política o procedimiento establecido que requiera que la organización de la ICANN proporcione a DotMusic una lista de inquietudes específicas sobre la Solicitud 16-5 después de la presentación complementaria de DotMusic y que programe una sesión en persona para abordarlas (una vez que se cumplan las condiciones descritas anteriormente). 51

        11. La Refutación no presenta argumentos ni hechos que respaldan la reconsideración.

          Como primer paso, la Solicitud 16-5 se presentó de conformidad con los Estatutos del 11 de febrero de 2016, Véase Discusión supra, que no requiere refutación de la recomendación del BAMC.52 No obstante, la Junta Directiva ha considerado la Refutación de los Solicitantes y cree que los solicitantes no han proporcionado otros argumentos o hechos que respaldasen la reconsideración.

          1. Los argumentos de los solicitantes con respecto a la definición de la comunidad no justifican la reconsideración.

            Los Solicitantes afirman que el Proveedor de la CPE aplicó incorrectamente los criterios de evaluación sobre el establecimiento de la comunidad (Criterio 1) porque se basó en la comunidad definida en respuesta a la Pregunta 20D de la Solicitud de DotMusic. Los Solicitantes sostienen que la Guía requería que el Proveedor de la CPE dependiera únicamente de la definición de comunidad establecida en la respuesta de DotMusic a la Pregunta 20AA.53 Como aval, los Solicitantes citan una tabla en el Anexo 2 al Módulo 2 de la Guía, que explica la preguntas de evaluación, criterios, puntuación y metodología de evaluación de las solicitudes de nuevos gTLD.54 La explicación de la columna "Pregunta" de la tabla para la pregunta 20A señala:

            Indicar el nombre y la descripción completa de la comunidad a la que el solicitante se compromete a servir. En el caso de que esta solicitud se incluya en una evaluación con prioridad de la comunidad, se calificará según la comunidad identificada en respuesta a esta pregunta. El nombre de la comunidad no tiene que ser adoptado formalmente para que la solicitud sea designada como con prioridad de la comunidad. 55

            Los Solicitantes argumentan que esta explicación requería que el Proveedor de la CPE aplique la definición de comunidad establecida en la respuesta de DotMusic a la Pregunta 20A. La Junta Directiva considera que este argumento ignora la explicación expuesta en la columna "Criterios" para la Pregunta 20A que establece:

            Las respuestas a la pregunta 20 se considerarán compromisos firmes con la comunidad específica y se reflejarán en el Acuerdo de Registro, siempre que la solicitud prosiga con éxito. Las respuestas no se califican en la evaluación inicial. Las respuestas pueden calificarse en una evaluación con prioridad de la comunidad, si corresponde. Los criterios y la metodología de calificación para la evaluación con prioridad de la comunidad se describen en el Módulo 4 de la Guía para el Solicitante.

            Ninguna parte del Módulo 4 de la Guía requiere que el Proveedor de la CPE considere solo la respuesta de DotMusic a la Pregunta 20A, sin atender el resto de la Solicitud al evaluar el Criterio 1.57 Como tal, la Junta Directiva considera que este argumento no justifica la reconsideración porque los Solicitantes no han demostrado que la evaluación del Criterio 1 por parte del proveedor de la CPE no estuviese en consonancia con la Guía o con cualquier otra política y procedimiento establecidos.

            Segundo, DotMusic argumenta que el proveedor de la CPE utilizó la definición incorrecta de comunidad porque el proveedor de la CPE "no mencionó explícitamente la definición de comunidad del Solicitante en su CPE" y en su lugar "creó su propia" definición general "de comunidad que se derivó de la Pregunta 20D. "58 En respuesta a la Pregunta 20A (el" nombre y la descripción completa de la comunidad a la que el solicitante se compromete a servir "), DotMusic señaló que el nombre de la comunidad era "Comunidad de Música", luego describió a la comunidad. En el curso de la descripción de la comunidad, DotMusic declaró que "la Comunidad de la Música está estrictamente delimitada usando los códigos NAICS establecidos. . . organizada con la siguiente delimitación, "luego enumeró los códigos NAICS que el proveedor de la CPE incluyó en el Informe de CPE.59 En consecuencia, incluso si el Proveedor de la CPE hubiera tenido que considerar solo la respuesta de DotMusic a la Pregunta 20,— lo cual no fue así —la consideración de los códigos NAICS por parte del Proveedor de la CPE hubiera sido apropiada.

            Tercero, los Solicitantes afirman que el texto incluido en la respuesta de DotMusic a la Pregunta 20, se refería al "criterio de elegibilidad []", no a la definición de comunidad, y por lo tanto, el proveedor de la CPE no debería haberlo considerado cuando evaluó el Criterio 1.60 Como se explicó anteriormente, la Guía no requiere este nivel de distinción. Además, la Junta Directiva observa que la Pregunta 20D no hace referencia a la elegibilidad; en la Pregunta 20D se solicitó a DotMusic que "explique la relación entre la cadena de gTLD solicitada y la comunidad identificada en la [pregunta 20A]".61

            En respuesta a la pregunta 20D, DotMusic indicó, entre otras cosas, ".MUSIC se relaciona con la comunidad al representar a todos los elementos constitutivos involucrados en la creación, producción y distribución de música, incluidas las agencias gubernamentales de cultura y los consejos de arte y otras organizaciones complementarias [sic] que participan en actividades de apoyo en consonancia con la misión de .MUSIC ".62 DotMusic no identifica ningún criterio de la Guía ni de la política o procedimiento aplicable que prohíba al proveedor de la CPE considerar a los "elementos constitutivos” representados por la comunidad definida en la Solicitud cuando evaluó el Establecimiento de la Comunidad. Por este otro motivo, dicho argumento no admite la reconsideración.

            Cuarto, DotMusic argumenta que, debido a que definió la Comunidad de Música como una "comunidad organizada de individuos, organizaciones y negocios, una 'alianza lógica de comunidades de naturaleza similar ("COMUNIDAD")", que se relaciona con la música ", el Proveedor de la CPE debía "reconocer [] que [DotMusic] cumplió con la definición precisa de una 'alianza lógica' que posee 'conciencia y reconocimiento' entre sus miembros". 63 El BAMC abordó este argumento en su Recomendación 64 y la Junta Directiva incorpora el razonamiento del BAMC tal como se señala aquí. El BAMC determinó que la Guía señala que "una alianza lógica de comunidades" es "viable" como comunidad, “siempre y cuando la conciencia y el reconocimiento de la comunidad estén presentes entre los miembros". 65 Debido a que el proveedor de la CPE no encontró el requisito de consciencia y reconocimiento entre los miembros de la comunidad en general, el proveedor de la CPE siguió la pauta de la Guía y otorgó a la Solicitud cero puntos en el Criterio 1.66

          2. Los argumentos restantes de los solicitantes se han tratado anteriormente y no justifican la reconsideración.

            Los Solicitantes repiten las críticas a los Informes de Revisión del Proceso de la CPE que ya han presentado varias veces, incluso en la Solicitud 18-5.67 La Junta Directiva abordó estos argumentos el 18 de julio de 2018, que se incorporan aquí para referencia.68 Los argumentos restantes de los Solicitantes en su Refutación reiteran los argumentos presentados en la Solicitud 16-5 y los materiales presentados como aval, todos los cuales el BAMC consideró al emitir su Recomendación.

          3. La respuesta de los solicitantes a la invitación de brindar información adicional

            Finalmente, la Junta Directiva debe abordar el reclamo de los Solicitantes de que nunca "rechazaron" la invitación del BAMC para realizar presentaciones adicionales en apoyo de la Solicitud 16-5. En la Refutación, los Solicitantes afirman que es "inexacto" caracterizar su respuesta a la invitación del BAMC como un rechazo.69 Sin embargo, esa fue precisamente la caracterización de de los Solicitantes a la respuesta a la invitación. El 5 de abril de 2018, en respuesta a la invitación del BAMC para realizar otras presentaciones, los Solicitantes indicaron que "DotMusic rechaza el intento de la ICANN de imponer restricciones artificiales a toda otra presentación con respecto a la Solicitud de reconsideración 16-5" y, posteriormente, no presentó información adicional.70 Es incorrecto ahora sugerir que la respuesta de DotMusic al BAMC fue, en cambio, un pedido "para efectuar presentaciones escritas sin restricciones y una presentación en persona". 71

            Por las razones anteriormente expuestas, la Junta Directiva concluye que la reconsideración no está justificada.

            Esta acción es parte de la Misión de la ICANN y se realiza en pos del interés público, ya que es importante garantizar que, en el ejercicio de su Misión, la ICANN sea responsable ante la comunidad por su funcionamiento conforme a las Actas Constitutivas, los Estatutos y otros procedimientos establecidos. Para ello, es menester contar con un proceso mediante el cual toda persona o entidad afectada materialmente por una acción de la Junta Directiva o el Personal de la ICANN pueda solicitar la reconsideración de la acción o inacción ante la Junta Directiva. La adopción de la Recomendación del BAMC no ha tenido un impacto económico en la ICANN y no provocará un impacto negativo en la seguridad, la estabilidad ni en la flexibilidad del sistema de nombres de dominio.

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

    5. Consideración de .AMAZON

      Chris Disspain presentó el tema de la agenda y explicó que la Junta Directiva consideró este asunto en su reunión del 10 de marzo de 2019 y que se han publicado las resoluciones aprobadas de esa reunión.

      No se adoptó ninguna resolución.

    6. Aceptación de la Segunda Revisión Organizacional del NomCom – Informe Final y Recomendaciones

      Avri Doria presentó el punto del orden del día. Avri explicó que ella solicitó que el tema se transfiriera al orden del día principal a la luz de los debates relacionados con la aceptación de las recomendaciones de las revisiones específicas y organizacionales y la necesidad de que la organización de la ICANN y la comunidad identifiquen colectivamente las prioridades y desarrollen una cadencia sostenible para implementar las recomendaciones derivadas de las revisiones.

      Avri presentó la moción y Tripti Sinha la secundó. El Presidente de la Junta llamó a votación y la Junta Directiva tomó la siguiente medida:

      Visto y considerando: Que, la segunda Revisión organizativa del Comité de Nominaciones (NomCom) comenzó en junio de 2017, de conformidad con los Estatutos de la ICANN,Artículo 4, Sección 4.4 .

      Visto y considerando: Que, el examinador independiente que realizó la segunda Revisión del NomCom produjo un informe de evaluación que se publicó para consulta pública el 10 de enero de 2018, un borrador de informe final que se publicó para comentarios públicos el 27 de marzo de 2018 y uninforme final con veintisiete (27) recomendaciones, que fueron publicadas el 5 de junio de 2018.

      Visto y considerando: Que, el Equipo de Planificación de la Implementación de la Revisión del NomCom analizó las recomendaciones del examinador independiente sobre la viabilidad y utilidad, consideró las implicaciones presupuestarias provisionales y anticipó los recursos para proponer un calendario de implementación con prioridades.

      Visto y considerando: Que, el Equipo de Planificación de la Implementación de la Revisión del NomCom preparó un borrador del Estudio de factibilidad y plan de implementación inicial (FAIIP), y lo presentó a los grupos de la comunidad interesados ​​durante la reunión ICANN63, y recibió un amplio apoyo de los mismos.

      Visto y considerando: Que, luego de haber consultado de forma regular con la comunidad, así como con los NomCom de 2018 y 2019, el Equipo de Planificación de la Implementación, aprobó el FAIIP final con consenso pleno el 14 de diciembre de 2018.

      Visto y considerando: Que, la Junta Directiva observa que el proceso de aprobación del FAIIP no reflejó en su totalidad el procedimiento detallado en el diagrama de flujo organizacional, donde se indica que la Organización de Apoyo o el Comité Asesor (SO / AC) que está bajo revisión aprueba el FAIIP. Esta desviación se debe al rol y estructura de membresía del NomCom que difiere significativamente de la de los consejos y liderazgos de las SO y los AC que están sujetos a revisiones organizacionales.72 El apoyo unánime del Equipo de Planificación de la Implementación para el FAIIP, la representatividad de su membresía, la transparencia de su trabajo y la responsabilidad de sus esfuerzos de difusión a lo largo de su trabajo, incluso durante la reunión ICANN63, compensan la falta de la aprobación formal por parte de un comité o consejo asesor que se produce durante la revisión organizacional de una SO o un AC.

      Visto y considerando: Que, el Equipo de Planificación de la Implementación de la Revisión del NomCom avaló las 27 recomendaciones del examinador independiente, en tanto que proporcionó modificaciones menores a cuatro de las 27 mismas, como se detalla en el FAIIP.

      Visto y considerando: Que, el Comité de Efectividad Organizacional (OEC) de la Junta Directiva de la ICANN recibió informes del examinador independiente sobre su informe final y el Equipo de Planificación de la Implementación de la Revisión del NomCom sobre su FAIIP durante la reunión del OEC el 8 de enero de 2019.

      Visto y considerando: Que, el OEC consideró el informe final, el FAIIP y los comentarios públicos  para llegar a una recomendación a la Junta Directiva sobre cómo proceder con la segunda Revisión del NomCom. El OEC recomendó que la Junta Directiva acepte el informe final del examinador independiente de la revisión del NomCom y el FAIIP del Equipo de Planificación de la Implementación. El OEC también recomendó que la Junta Directiva ordene al Equipo de Planificación de la Implementación de la Revisión del NomCom convocar a un grupo de trabajo de implementación para desarrollar un plan de implementación detallado para las recomendaciones, tal como se detalla en el FAIIP, dentro de los seis meses posteriores a la adopción de esta resolución, y para que ese grupo de trabajo sobre la implementación supervise la implementación de estas recomendaciones, una vez que la Junta Directiva haya aprobado dicho plan detallado de implementación.73

      Resuélvase (2019.03.14.13): La Junta Directiva reconoce el trabajo diligente del examinador independiente y le agradece por la elaboración de un informe final completo destinado a mejorar la efectividad, la transparencia y la responsabilidad del NomCom.

      Resuélvase (2019.03.14.14): La Junta Directiva reconoce el trabajo y el apoyo del Grupo de trabajo para la Revisión de NomCom y el Equipo de planificación de la implementación de la revisión de NomCom durante el proceso de revisión. La Junta agradece al Equipo de Planificación de la Implementación de la Revisión del NomCom por su trabajo diligente y perspicaz en la elaboración del estudio de factibilidad y plan de implementación inicial que fue aprobado con total consenso por el Equipo de Planificación de la Implementación de la Revisión de la NomCom el 14 de diciembre de 2018.

      Resuélvase (2019.03.14.15): La Junta Directiva acepta el Informe Final del examinador independiente.

      Resuélvase (2019.03.14.16): La Junta Directiva acepta el Estudio de Factibilidad y Plan de Implementación Inicial del Equipo de Planificación de Implementación de la Revisión del NomCom, sujeto a los costos de implementación adecuados. La Junta Directiva ordena al Presidente y Director Ejecutivo (CEO) de la ICANN, o a quien éste designe, dar apoyo al Equipo de Planificación de la Implementación de la Revisión del NomCom en el desarrollo y la presentación a la Junta Directiva, a través del OEC, de un plan para la implementación de las recomendaciones aceptadas. El Presidente y Director Ejecutivo (CEO) de la ICANN, o quien éste designe, deberá informar a la Junta Directiva sobre el plan y todo aporte efectuado por la comunidad.

      Resuélvase (2019.03.14.17): Con el fin de respaldar esta acción, la Junta Directiva solicita que el Equipo de Planificación de laImplementación de la Revisión del NomCom  reúna a un grupo de trabajo que elabore un plan detallado de implementación de las recomendaciones, tal como se detalla en el FAIIP. El plan de implementación detallado se presentará a la Junta Directiva a la brevedad posible, pero a más tardar seis (6) meses luego de la adopción de esta resolución. El plan de implementación debe contener un cronograma realista para la implementación, una definición de los resultados deseados, una explicación de cómo la implementación aborda los problemas subyacentes identificados en el informe final y una manera de medir el estado actual y el progreso hacia el resultado deseado. El grupo de trabajo también trabajará con la organización de la ICANN para incluir las consecuencias presupuestarias esperadas para cada uno de los pasos de implementación en su plan de implementación detallado. El plan de implementación debe incorporar un enfoque por etapas que permita implementar primero las mejoras fáciles y menos costosas, y los elementos con consecuencias presupuestarias más importantes se abordarán más adelante en el proceso de implementación.

      Resuélvase (2019.03.14.18): La Junta Directiva instruye al grupo de trabajo para la implementación de la revisión del NomCom supervisar el proceso de implementación, una vez que la Junta Directiva haya aceptado el plan de implementación detallado. Toda solicitud presupuestaria que resulte de la implementación se realizará en consonancia con los procesos de presupuesto anual de la organización de la ICANN.

      Resuélvase (2019.03.14.19): La Junta Directiva ordena al Grupo de trabajo para la implementación de la Revisión del NomCom que proporcione al OEC informes de implementación semestrales por escrito sobre el progreso en relación con el plan de implementación, lo que incluye, entre otras cosas, el avance hacia las métricas detalladas en el plan y la utilización del presupuesto asignado.

      Todos los miembros de la Junta presentes votaron a favor de las Resoluciones 2019.03.14.13, 2019.03.14.14, 2019.03.14.15, 2019.03.14.16, 2019.03.14.17, 2019.03.14.18 y 2019.03.14.19. Las resoluciones fueron aprobadas.

      Fundamento de las resoluciones 2019.03.14.13 y 2019.03.14.19

      ¿Por qué la Junta Directiva aborda el tema?

      Para garantizar que el modelo de múltiples partes interesadas de la ICANN sea transparente y responsable, y para mejorar su desempeño, la ICANN lleva a cabo revisiones organizacionales de sus organizaciones de apoyo (SO), comités asesores (AC) (además del Comité asesor gubernamental) y el Comité de Nominaciones (NomCom), como se dispone en el Artículo 4, Apartado 4.4de sus Estatutos. La segunda revisión de NomCom comenzó en junio de 2017. El examinador independiente que realizó la revisión emitió un informe final que se publicó en junio de 2018. Sobre la base de su revisión detallada del informe final del examinador independiente, el Equipo de Planificación de la Implementación del NomCom preparó una Evaluación de Factibilidad y Plan de Implementación Inicial  (FAIIP), adoptado con pleno consentimiento el 14 de diciembre de 2018.

      Esta acción también reconoce que el enfoque que la ICANN ha adoptado históricamente para evaluar e implementar las recomendaciones de los procesos de revisión no es sostenible, y que antes de actuar en las recomendaciones del Informe final, la ICANN debe discutir con la comunidad procesos mediante los cuales la ICANN y la comunidad puedan identificar colectivamente las prioridades y desarrollar una cadencia sostenible para implementar recomendaciones fuera de las revisiones.

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

      La propuesta que se está considerando es que la Junta Directiva acepte el informe final, acepte la Evaluación de Factibilidad y el Plan de Implementación Inicial (FAIIP), y ordene al Equipo de Planificación de la Implementación de la Revisión del NomCom convocar a un grupo de trabajo de Implementación de la Revisión del NomCom que supervise la implementación de las recomendaciones, como se detalla en el FAIIP.

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

      Durante su trabajo en la Revisión del NomCom, el examinador independiente realizó más de 60 entrevistas con miembros actuales y anteriores del NomCom, la comunidad de la ICANN en general, la Junta Directiva de la ICANN y la organización de la ICANN, y reunió 85 respuestas individuales a su encuesta en línea. El examinador independiente celebró reuniones periódicas con el Grupo de Trabajo para la Revisión del NomCom durante la revisión, incluidas reuniones públicas ICANN61 e ICANN62 y reuniones con grupos comunitarios en la reunión ICANN63, consultas públicas sobre el informe de evaluación y un seminario web sobre el informe final preliminar .

      El examinador independiente publicó su informe de evaluación para consulta pública y su informe final preliminar para comentarios públicos. Se enviaron diez comentarios al foro de comentarios públicos– uno de un individuo y nueve en nombre de organizaciones. (Véase Resumen del Informe del procedimiento de comentarios públicos). ElGrupo de Trabajo para la Revisión de NomCom  también proporcionó comentarios directos al examinador independiente sobre los borradores iniciales del informe de evaluación, el informe final preliminar y el informe final.

      El OEC recibió resúmenes informativos por parte del examinador independiente sobre su informe final y del Equipo de Planificación de la Implementación de la Revisión del NomCom sobre su FAIIP durante la reunión del OEC el 8 de enero de 2019. El OEC también consideró los comentarios de la comunidad sobre el informe de evaluación del examinador independiente y el informe final preliminar.

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

      Si bien el Equipo de Planificación de la Implementación de la Revisión del NomCom estuvo de acuerdo con el espíritu de todas las recomendaciones del examinador independiente, realizó observaciones a la redacción en cuatro de ellas. El Equipo de planificación de la implementación del NomCom resolvió las inquietudes haciendo modificaciones semánticas a estas cuatro recomendaciones.

      En general, quienes realizaron aportes a los procedimientos de comentarios públicos sobre el informe final preliminar del examinador independiente expresaron su apoyo general a las conclusiones y recomendaciones incluidas en el informe.

      Además, la comunidad también avaló el borrador del estudio de factibilidad y plan de implementación inicial que el Equipo de Planificación de la Implementación presentó a los grupos de la comunidad interesados ​​durante la reunión ICANN 63.

      ¿Qué materiales significativos analizó la Junta Directiva?

      La Junta Directiva ha tomado en consideración las disposiciones pertinentes de los Estatutos, el informe final del examinador independiente, el FAIIP del Equipo de Planificación de la Implementación de la Revisión del NomCom, y los comentarios de la comunidad sobre el informe de evaluación del examinador independiente y el informe final preliminar, y tomó en cuenta las consideraciones del OEC al hacer esta recomendación.

      ¿Qué factores consideró importantes la Junta Directiva?

      La Junta toma nota del apoyo general del Equipo de Planificación de la Implementación de la Revisión del NomCom y de la comunidad al informe final preliminar y al informe final del examinador independiente, y los ha considerado junto con todos los aportes restantes de la comunidad recibidos a lo largo del proceso de Revisión del NomCom.

      En los cuatro casos en que el Equipo de Planificación de la Implementación de la Revisión del NomCom estuvo de acuerdo con el espíritu de la recomendación pero hizo modificaciones en la redacción, la Junta Directiva considera que las modificaciones propuestas y la justificación proporcionada en el FAIIP son adecuadas para abordar los problemas identificados por el examinador independiente en el informe final. Por lo tanto, la Junta Directiva acepta el informe final y el FAIIP.

      La implementación de las mejoras propuestas es un paso importante para garantizar que el NomCom posterior a la revisión sea capaz y pueda cumplir con su función y responsabilidades estipuladas en los Estatutos.

      ¿Existen impactos positivos o negativos para la comunidad?

      Se espera que esta acción de la Junta Directiva tenga un impacto positivo en la comunidad, ya que respalda el proceso continuo de facilitar la revisión periódica de las SO y los AC de la ICANN, según lo estipulado en los Estatutos. Además, la implementación de las recomendaciones conducirá a mejoras en la transparencia, responsabilidad y efectividad del NomCom.

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

      Esta acción de la Junta Directiva tendrá consecuencias fiscales, que se catalogarán en el próximo plan de implementación detallado, que en sí estará sujeto a una futura consideración por parte de la Junta Directiva. El plan de implementación detallado debe describir cómo se incorporarán los requisitos presupuestarios en los futuros ciclos de presupuesto de la ICANN.

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

      ¿Está dicha 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 se encuentra en consonancia con la Misión de la ICANN y su compromiso de conformidad con la Sección 4de los  Estatutos para garantizar que el modelo de múltiples partes interesadas de la ICANN continúe siendo transparente y responsable, y para mejorar el desempeño de sus organizaciones de apoyo y comités asesores.

      Esta acción servirá al interés público al contribuir al cumplimiento del compromiso de ICANN de mantener y mejorar su responsabilidad y transparencia.

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

      El informe final preliminar del examinador independiente fue publicado para comentario público. El borrador del estudio de factibilidad y plan de implementación inicial final fue presentado a los grupos de la comunidad interesados durante la reunión ICANN63. No se requieren comentarios públicos adicionales con anterioridad a la acción de la Junta Directiva.

    7. Próximos pasos con respecto a la composición del Equipo de Revisión de la Función de Nombres de la IANA

      Chris Disspain presentó el tema del orden del día. Chris explicó que se requiere que la ccNSO ocupe tres puestos en el Equipo para la Revisión de la Función de Nombres de la IANA, uno de los cuales no debe ser miembro de la ccNSO. La ccNSO tiene dificultades para ocupar estas posiciones. Hay una serie de posibles soluciones para resolver este problema, sin embargo, hasta que se identifique la mejor solución para avanzar, este punto del orden del día no está listo para ser sometido a consideración de la Junta Directiva. Cuando sea apropiado, el punto será sometido a consideración de la Junta Directiva en la próxima oportunidad posible.

      Avri Doria reiteró que el asunto se debe presentar a la consideración de la Junta Directiva lo antes posible, en cumplimiento con los requisitos de los Estatutos de la ICANN relacionados con la Revisión de la función de nombres de la IANA.

      Luego del debate, el Presidente señaló que el tema se trasladó del Orden del día convenido al orden del día principal y ahora se solicita que se elimine por completo del mismo. Luego el Presidente indicó que el punto quedaba removido del orden del día.

      No se adoptó ninguna resolución.

    8. Otros temas a tratar

      1. Proyecto de Análisis de Colisión de Nombres - –Primer Estudio

        Akinori Maemura presentó el tema del orden del día. Akinori proporcionó información de contexto sobre los eventos que condujeron a la resolución propuesta, los cuales se detallan en las cláusulas de los considerando. Akinori luego leyó la resolución propuesta para que conste en actas.

        Avri Doria expresó su agradecimiento al SSAC por su persistencia en la resolución de los problemas y a los miembros de la Oficina del Director de Tecnologías de la ICANN por su arduo trabajo.

        Akinori presentó la moción y Lito Ibarra la secundó. El Presidente de la Junta llamó a votación y la Junta Directiva tomó la siguiente medida:

        Visto y considerando: Que, el 2 de noviembre de 2017, la Junta Directiva solicitó al Comité Asesor de Seguridad y Estabilidad (SSAC) de la ICANN que desarrolle un plan para ser aprobado por la Junta Directiva que establezca estudios sobre el tema de la colisión de nombres, con muchos elementos detallados. Véase https://www.icann.org/resources/board-material/resolutions-2017-11-02-en#2.a.

        Visto y considerando: Que, el SSAC entregó, en septiembre de 2018, una propuesta sugerida del Proyecto de Análisis de Colisiones de Nombres (NCAP), que detallaba tres estudios previstos para cumplir con el llamado de la resolución de 2017 de la Junta Directiva.

        Visto y considerando: Que, en octubre de 2018, el Comité Técnico de la Junta (BTC) solicitó a la organización de la ICANN, a través de la Oficina del Director de Tecnologías (OCTO), una evaluación de la propuesta del NCAP. Posteriormente, la OCTO y el SSAC sostuvieron discusiones que proporcionaron más información y aclaraciones a la OCTO sobre los detalles de la propuesta.

        Visto y considerando: Que, la evaluación realizada por la OCTO indicó que una encuesta y un resumen de investigaciones previas sobre colisiones de nombres serían de valor, sin embargo, un repositorio de datos y las políticas asociadas para el uso de ese repositorio pueden no ser necesarios si se toma una decisión futura para no continuar con el Estudio 2 y el Estudio 3. Como resultado, la OCTO precisó el alcance del Estudio 1 propuesto por el SSAC sobre la comprensión del estado actual de las colisiones de nombres para aplazar la implementación de un repositorio de datos y el desarrollo de políticas relacionadas.

        Visto y considerando: Que, la OCTO detalló para el BTC un estudio propuesto sobre la comprensión del estado actual de las colisiones de nombres con tres objetivos: 1) examinar todo el trabajo previo sobre el tema de las colisiones de nombres y crear un informe resumido que aporte importantes conocimientos de trabajos anteriores a este estudio, y que pueda servir como un manual para quienes son nuevos en la materia; 2) crear una lista de resultados de los datos utilizados en estudios anteriores, identificar brechas, si las hay, y enumerar datos adicionales que se necesitarían para llevar a cabo con éxito los dos estudios adicionales identificados; y 3) proporcionar información que facilitará una decisión sobre si el NCAP debe proceder con los estudios 2 y 3 sobre la base de los resultados de la encuesta de trabajos anteriores y la disponibilidad de datos.

        Visto y considerando: Que, el BTC consideró la propuesta de la OCTO para un estudio sobre la comprensión del estado actual de las colisiones de nombres, incluido su impacto financiero y los 3 estudios y, el 4 de marzo de 2019, recomendó a la Junta Directiva que ordene a la organización de la ICANN continuar con el Estudio 1.

        Resuélvase (2019.03.14.20): La Junta Directiva de la ICANN agradece 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 (2019.03.14.21): La Junta Directiva instruye al Presidente y Director Ejecutivo (CEO) de la ICANN, o quien éste designe, a proceder con el Estudio 1 sobre la comprensión del estado actual de las colisiones de nombres, según lo indicado por la organización de la ICANN.

        Resuélvase (2019.03.14.22): La Junta Directiva instruye al Presidente y Director Ejecutivo (CEO) de la ICANN, o a quien éste designe, identificar y poner a disposición los fondos dentro de los límites adecuados de presupuesto y adquisiciones, y que los gastos incurridos para el estudio propuesto no excedan la suma de [OMITIDO A LOS FINES DE NEGOCIACIÓN].

        Resuélvase (2019.03.14.23): Algunos puntos específicos de esta resolución tendrán carácter confidencial por motivos de negociación, conforme al Artículo 3, Sección 3.5(b) y (d) de los Estatutos de la ICANN, hasta que el Presidente y Director Ejecutivo determine que la información confidencial puede publicarse.

        Todos los miembros presentes de la Junta Directiva votaron a favor de las resoluciones 2019.03.14.20, 2019.03.14.21, 2019.03.14.22 y 2019.03.14.23. Las resoluciones fueron aprobadas.

        Fundamentos de las resoluciones 2019.03.14.20 – 2019.03.14.23

        Una colisión de nombres ocurre cuando un intento de resolver un nombre utilizado en un espacio de nombres privado (por ejemplo, mediante un Dominio de Alto Nivel no delegado, o un nombre breve e incompleto) da como resultado una consulta al Sistema de Nombres de Dominio (DNS) público. Cuando se superponen los límites administrativos de los espacios de nombres públicos y privados, la resolución del nombre puede generar resultados no deseados o perjudiciales. Esta clase de cadenas de caracteres hasta ahora no delegadas se conoce como “Cadenas de Caracteres de Colisión”. En algunos casos, los resultados no deseados o perjudiciales de la delegación de Cadenas de Caracteres de Colisión pueden ser considerados “de alto riesgo”. Entre los parámetros de ejemplo para clasificar una Cadena de Caracteres de Colisión como de alto riesgo se incluyen; alta frecuencia de aparición en consultas a los servidores raíz, la gravedad del impacto de las Cadenas de Caracteres de Colisión, el tipo de solicitudes del DNS, el tipo de usuario que ocasiona la colisión (por ejemplo, servicios de emergencia, controladores del tráfico aéreo, etc.), diversidad de fuente de consultas y aparición en certificados de nombres internos.

        La Junta Directiva ha tomado medidas previamente con respecto a los problemas de colisiones de nombres y, en particular, solicitó al Comité Asesor de Seguridad y Estabilidad (SSAC) que identifique los estudios para abordar una serie de preguntas que la Junta Directiva identificó para ayudar a informar mejor cómo la ICANN abordará la cuestión de las colisiones de nombres en un futura expansión del espacio del nombres de dominio. En respuesta a la resolución del 2 de noviembre de 2017 de la Junta Directiva, el SSAC entregó, en septiembre de 2018, una propuesta sugerida del Proyecto de Análisis de Colisiones de Nombres (NCAP). Esa propuesta detalla tres estudios secuenciales previstos para cumplir con los establecido en esa resolución.

        El Comité Técnico de la Junta (BTC) luego solicitó a la Oficina del Director de Tecnologías de la ICANN (OCTO) una evaluación de la propuesta del NCAP. Como resultado de esa solicitud, la OCTO y el SSAC llevaron a cabo debates para proporcionar más información y aclaraciones a la OCTO sobre los detalles de la propuesta.

        Finalmente, la OCTO indicó al BTC que una encuesta y un resumen de investigaciones previas sobre colisiones de nombres serían de valor, sin embargo, un repositorio de datos y las políticas asociadas para el uso de ese repositorio pueden no ser necesarios si se toma una decisión futura para no continuar con el Estudio 2 y el Estudio 3. Como resultado, la OCTO precisó el alcance del Estudio 1 propuesto por el SSAC sobre la comprensión del estado actual de las colisiones de nombres para aplazar la implementación de un repositorio de datos y el desarrollo de políticas relacionadas para estudios posteriores. El Estudio 1 revisado tiene tres objetivos: 1) examinar todo el trabajo previo sobre el tema de las colisiones de nombres y crear un informe resumido que aporte importantes conocimientos de trabajos anteriores a este estudio, y que pueda servir como un manual para quienes son nuevos en la materia; 2) crear una lista de resultados de los datos utilizados en estudios anteriores, identificar brechas, si las hay, y enumerar datos adicionales que se necesitarían para llevar a cabo con éxito dos estudios adicionales identificados; y 3) proporcionar información necesaria para decidir si el NCAP debe proceder con los estudios 2 y 3 sobre la base de los resultados de la encuesta de trabajos anteriores y la disponibilidad de datos.

        La Junta Directiva está tomando esta acción hoy por dos razones. En primer lugar, el trabajo de la OCTO con respecto al NCAP ha llegado a un punto en el cual es posible llevar a cabo un estudio porque el alcance ha sido suficientemente definido. En segundo lugar, existe una posible interdependencia entre los resultados de los estudios de colisiones de nombres en la próxima ronda de Nuevos gTLD, en particular para obtener más información sobre la capacidad de delegar cadenas de caracteres que se superponen en los espacios de nombres públicos y privados.

        Se espera que esta resolución tenga un impacto positivo en la seguridad, estabilidad y flexibilidad del DNS de Internet, ya que está diseñado para recopilar más información sobre este importante desafío técnico. Esto 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.

        Esta resolución tendrá un impacto financiero, ya que hay costos esperados asociados con la realización de los estudios. Ordena a la organización de la ICANN sólo realizar el Estudio 1 sobre la comprensión del estado actual de las colisiones, según lo precisado por la organización de la ICANN, y los estudios adicionales se considerarán e instruirán de manera independiente sobre la base del resultado del Estudio 1. Se espera que el Presidente y Director Ejecutivo (CEO) de la ICANN realice este trabajo dentro de las prácticas presupuestarias apropiadas.

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

      Después de esto, el Presidente dio por concluida la reunión.


1 Nombres de Dominio Internacionalizados en Aplicaciones (IDNA): antecedentes, explicación y fundamento

2 https://www.icann.org/en/system/files/correspondence/disspain-letter-review-new-gtld-cpe-process-26apr17-en.pdf.

3 Véase Estatutos de la ICANN, 11 de febrero de 2016, Art. 4, § 2 (https://www.icann.org/resources/pages/bylaws-2016-02-16-en#IV).

4 Véase Guía, Módulo 4, § 4.2 en Pág. 4-7 (https://newgtlds.icann.org/en/applicants/agb/string-contention-procedures-04jun12-en.pdf). Véase también https://newgtlds.icann.org/en/applicants/cpe.

5 Id. En Módulo 4, § 4.2 en Pág. 4-7 (https://newgtlds.icann.org/en/applicants/agb/string-contention-procedures-04jun12-en.pdf).

6 Id. En Módulo 4, § 4.2.3, Pág. 4-9.

7 Id. Módulo 4, § 4.2.2.

8 Id. En Módulo 4, §§ 4.2.2 y 4.2.3. En Págs. 4-8 y 4-9 (https://newgtlds.icann.org/en/applicants/agb/string-contention-procedures-04jun12-en.pdf).

9 Guía, Módulo 4, § 4.2.3, en Pág. 4-9.

10 Solicitud 16-5, § 6, Pág. 19; Declaración de IRPDespegar ¶¶ 66-67 (https://www.icann.org/en/system/files/files/irp-despegar-online-et-al-final-declaration-12feb16-en.pdf).

11 Solicitud 16-5, § 6, página 19.

12 Id. ¶¶ 147, 150 (énfasis agregado).

13 Solicitud 16-5, § 6, página 19.

14 Resoluciones de la Junta Directiva 2016.03.10.10-11 (https://www.icann.org/resources/board-material/resolutions-2016-03-10-en#2.a).

15 Id.

16 Véase https://newgtlds.icann.org/en/applicants/cpe#process-review.

17 Solicitud 16-5, § 8, Pág. 17, 18.

18 Solicitud18-5, https://www.icann.org/en/system/files/files/reconsideration-18-5-dotmusic-request-redacted-14apr18-en.pdf.

19 Acción de la Junta Directiva con respecto a la Solicitud 18-5, https://www.icann.org/resources/board-material/resolutions-2018-07-18-en#2.f.

20 Solicitud 16-5, § 8, página 5.

21 Véase Comunicado pronunciado en Pekín, Anexo I, Pág. 9 https://www.icann.org/en/system/files/correspondence/gac-to-board-18apr13-en.pdf; véase también https://newgtlds.icann.org/en/applicants/gac-advice/cat2-safeguards.

22 véase id., Pág. 11.

23 Véase https://www.icann.org/en/system/files/files/resolutions-new-gtld-annex-2-05feb14-en.pdf. Véase también http://www.icann.org/en/groups/board/documents/resolutions-new-gtld- 25jun13-en.htm; véase también Documento No. 2013-06-25-2B de la NGPC de la ICANN: Asesoramiento del GAC contenido en el Comunicado pronunciado en Pekín con respecto al asesoramiento sobre las protecciones que se aplican a cadenas de caracteres de Categoría 2, material informativo 1, pág. 25-31 (http://www.icann.org/en/groups/board/documents/briefing-materials-1- 25jun13-en.pdf); http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-02jul13-en.htm#1.d; véase también http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-annex-1-item-1d- 02jul13-en.pdf, Anexo I, Acuerdo de Nuevos gTLD).

24 Solicitud 16-5, § 8, página 5.

25 Id.; véase también opinión de Blomqvist, ¶ 52, en pág. 41.

26 Id., § 6, Pág. 3, 6.

27 Informe final de la GNSO sobre la introducción de nuevos dominios genéricos de alto niver, pauta de implementación IG H (énfasis añadido) (http://gnso.icann.org/en/issues/new-gtlds/pdp-dec05-fr-parta-08aug07.htm).

28 Guía Módulo § 1.2.3.2, en Pág. 1-27.

29 Id.

30 Solicitud 16-5, § 6, página 20. Véase también la Carta de Revisión del Proceso de CPE de DotMusic, en 26 (c), 67b, en la pág. 28, 47 (que también argumenta que Sir Robin Jacob, un miembro del Panel seleccionado por el ICC en los procedimientos de objeción de la Comunidad para .MUSIC y .BAND, representó a Samsung, "uno de los socios multimillonarios de Google", en una causa legal (para más detalle, consultar la Solicitud de reconsideración 16-7, 8, en la página 18 (marcado 17) n.68, https://www.icann.org/en/system/files/files/reconsideration-16-7-dotmusic-request-redacted-30may16-en.pdf).

31 Carta de revisión del proceso de de la CPE de DotMusic, en 26 (c), en la pág. 28.

32 Guía § 2.4.3.1, en Pág. 2-33; Documento del Proceso del Panel de la CPE en Pág. 2, https://newgtlds.icann.org/en/applicants/cpe; Pautas de la CPE en Pág. 22, https://newgtlds.icann.org/en/applicants/cpe.

33 El señor Schmidt renunció en diciembre de 2015.(https://www.theguardian.com/media/2015/dec/10/economist-appoints-tessa-jowell-to-board-as-googles-eric-schmidt-departs). El Informe Final de la CPE fue emitido el 10 de febrero de 2016; (https://newgtlds.icann.org/sites/default/files/tlds/music/music-cpe-1-1115-14110-en.pdf.)

34 Véase Panel de Estrategia: El Rol de la ICANN en el ecosistema de gobernanza de Internet (https://www.icann.org/en/system/files/files/report-23feb14-en.pdf).

35 Solicitud 16-5, § 6, página 20.

36 Véase Guía, Módulo 4, § 4.2.3, en Pág. 4-9 ("una solicitud de la comunidad calificada elimina todas las solicitudes estándar que están en competencia directa, independientemente de cuán bien calificada pueda estar estas últimas Esta es una razón fundamental para la existencia de requisitos estrictos para la calificación de una solicitud presentadas por una comunidad".

37Los Solicitantes se refieren a un intercambio con Fadi Chehadé en el foro público. Véase https://singapore52.icann.org/en/schedule/thu-public-forum/transcript-public-forum-12feb15-en.pdf, Págs. 61-62. Durante ese intercambio, el Sr. Chehadé agradeció a DotMusic por sus comentarios y pidió a DotMusic que enviara una carta a la ICANN explicando las inquietudes de DotMusic. DotMusic nunca lo hizo. Nada sobre este intercambio comprende un "reconocimiento" de algún conflicto de intereses, como señalan los Solicitantes. (Véase Solicitud 16-5, § 6, pág. 20).

38 Informe CoE, en pág. 47, citada en la Carta de Revisión del Proceso de CPE de DotMusic, 26 (c), en la pág. 28.

39 Solicitud 16-5, § 6, página 18.

40 Informe 1 sobre el Alcance de FTI en pág. 3 https://www.icann.org/en/system/files/files/cpe-process-review-scope-1-communications-between-icann-cpe-provider-13dec17-en.pdf.

41 Id. En Pág. 12.

42 Id.

43 Solicitud 16-5, § 8, en pág. 16 (indicado como pág. 15).

44 Véase Estatutos de la ICANN, 11 de febrero de 2016.

45 Guía para el Solicitante, Preámbulo.

46 Id.

47 Véase https://newgtlds.icann.org/en/applicants/agb, que indica que la versión actual de la guía con fecha del 4 de junio de 2012. Según los Estatutos vigentes en junio de 2012, las Solicitudes de Reconsideración debían presentarse dentro de los treinta días posteriores a la publicación de las acciones de la Junta Directiva o dentro de los treinta días posteriores a que el Solicitante se hubiera enterado o debiera haber tenido conocimiento razonable de las acciones del personal impugnadas. Estatutos de la ICANN, 16 de marzo 2012, Art. IV, § 2.5 (https://www.icann.org/resources/pages/bylaws-2012-12-21-en#IV).

48 Guía, Módulo 6, § 6, en pág. 6-4.

49 Véase Solicitud 14-28, https://www.icann.org/en/system/files/files/request-dotmusic-07jun14-en.pdf; Solicitud 16-7, https://www.icann.org/en/system/files/files/reconsideration-16-7-dotmusic-request-redacted-30may16-en.pdf; Solicitud 17-2, https://www.icann.org/en/system/files/files/reconsideration-17-2-dotmusic-request-redacted-18jun17-en.pdf; Solicitud 17-4, https://www.icann.org/en/system/files/files/reconsideration-17-4-dotmusic-dotgay-request-redacted-25jul17-en.pdf; Solicitud 18-1, https://www.icann.org/en/system/files/files/reconsideration-18-1-dotmusic-request-redacted-10mar18-en.pdf; Solicitud 18-5, https://www.icann.org/en/system/files/files/reconsideration-18-5-dotmusic-request-redacted-14apr18-en.pdf.

50 La Junta Directiva observa que este reclamo fue presentado solo por el Solicitante DotMusic, no por los otros Solicitantes, en una presentación complementaria en apoyo de la Solicitud 16-5. Véase https://www.icann.org/en/system/files/files/reconsideration-16-3-et-al-dotgay-dechert-to-icann-board-bamc-redacted-23mar18-en.pdf.

51 https://www.icann.org/en/system/files/files/reconsideration-18-5-dotmusic-bamc-recommendation-attachment-2-14jun18-en.pdf.

52 Véase Estatutos de la ICANN, 11 de febrero de 2016, Art. 4, § 2 (https://www.icann.org/resources/pages/bylaws-2016-02-16-en#IV).

53 (Refutación, páginas 3-5 (https://www.icann.org/en/system/files/files/reconsideration-16-5-dotmusic-requestors-rebuttal-to-bamc-recommendation-request-12feb19-en.pdf).

54 Id.; véase también Guía, Módulo 2, Anexo 2 (https://newgtlds.icann.org/en/applicants/agb/evaluation-questions-criteria-04jun12-en.pdf).

55 Guía, Módulo 2, Anexo 2, Pág. A-14 (https://newgtlds.icann.org/en/applicants/agb/evaluation-questions-criteria-04jun12-en.pdf) (énfasis agregado).

56 Id. (énfasis agregado).

57 Véase Guía, Módulo 4, § 4.2.3, en Págs. 4-10 – 4-12.

58 Refutación, página 6.

59 Solicitud, Pregunta 20A (https://gtldresult.icann.org/applicationstatus/applicationdetails/1392).

60 Refutación, en pág. 4 (se omiten las comillas internas).

61 Guía, Anexo 2 al Módulo 2, en la pág. A-14.

62 Solicitud, Pregunta 20D, (https://gtldresult.icann.org/applicationstatus/applicationdetails/1392).

63 Refutación en Pág. 4-5.

64 Véase Anexo 1 a la recomendación del BAMC en Pág. 29 (https://www.icann.org/en/system/files/files/reconsideration-16-5-dotmusic-bamc-recommendation-attachment-1-25jan19-en.pdf).

65 Guía, Módulo 4, § 4.2.3, en Pág 4-12 (énfasis agregado).

66 Id.

67 Véase https://www.icann.org/en/system/files/files/reconsideration-18-5-dotmusic-request-redacted-14apr18-en.pdf.

68 Véase https://www.icann.org/resources/board-material/resolutions-2018-07-18-en#2.f.

69 Refutación, página 1.

70 https://www.icann.org/en/system/files/files/reconsideration-18-5-dotmusic-bamc-recommendation-attachment-2-14jun18-en.pdf (énfasis agregado).

71 Refutación, página 1.

72 Se realizará una actualización del diagrama de flujo para aclarar este punto en el estándar de revisión y una actualización de la documentación del proceso de la ICANN.

73 La aceptación por parte de la Junta Directiva del plan de implementación detallado es una desviación del diagrama de flujo del proceso de revisión organizacional, pero este paso está de acuerdo con la práctica estándar para las revisiones organizacionales porque la Junta Directiva está ejerciendo su responsabilidad fiduciaria al revisar y aceptar dicho plan de implementación detallado. Se realizará una actualización del diagrama de flujo en el proceso estándar de revisión y una actualización de la documentación del proceso de la ICANN.

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