Resoluciones aprobadas por la Junta Directiva | Sesión abierta del Taller de la Junta Directiva, Los Ángeles | Reunión ordinaria de la Junta Directiva de la ICANN 26 de enero de 2020

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

Orden del día convenido:
1. Aprobación de las actas de la reunión
  
  Resuélvase (2020.01.26.01): La Junta Directiva aprueba las actas de la Reunión Ordinaria de la Junta Directiva de la ICANN celebrada el 3 de noviembre de 2019, la Reunión Extraordinaria de la Junta Directiva de la ICANN celebrada el 21 de noviembre de 2019 y la Reunión Extraordinaria de la Junta Directiva de la ICANN celebrada el 12 de diciembre de 2019.
2. Aplazamiento de la imposición del cumplimiento del Formulario de autorización del Registrador receptor
  
  Visto y considerando: Que la Política de transferencia requiere que una transferencia entre registradores "solo puede proceder si el Registrador receptor recibe la confirmación de la transferencia del Contacto de transferencia" y que dicha autorización "debe hacerse mediante un Formulario de Autorización (FOA) Estándar válido".
  
  Visto y considerando: Que el 9 de octubre de 2019, el Grupo de Partes Interesadas de Registradores (RrSG) escribió al Consejo de la GNSO para informar que el RrSG había identificado un problema en la implementación del Requisito del FOA del Registrador receptor y solicitar al Consejo que solicite a la Junta Directiva de la ICANN que remita este problema a la inminente revisión de la Política de transferencia y que instruya al departamento de Cumplimiento Contractual de la ICANN a no exigir el cumplimiento del requisito de FOA del Registrador receptor mientras dicha revisión esté en curso.
  
  Visto y considerando: Que el 31 de octubre de 2019, el Consejo de la GNSO solicitó que la Junta Directiva de la ICANN instruyera a la organización de la ICANN a aplazar la imposición del cumplimiento del requisito del FOA del Registrador receptor hasta que este asunto se resuelva en la revisión de la Política de transferencia prevista por la GNSO.
  
  Resuélvase (2020.01.26.02): La Junta Directiva acepta la solicitud del Consejo de la GNSO e instruye al Presidente y Director Ejecutivo de la ICANN, o a quien este designe, que aplace la imposición del cumplimiento del requisito de la Política de transferencia del FOA del Registrador receptor hasta que el asunto se resuelva en la revisión de la Política de transferencia prevista por el Consejo de la GNSO.
  
  Fundamento de la resolución 2020.01.26.02
  
  ¿Por qué la Junta Directiva aborda el tema?
  
  La Junta Directiva aborda esta cuestión a solicitud del Consejo de la GNSO. El 31 de octubre de 2019, el Consejo de la GNSO envió una carta a la Junta Directiva de la ICANN en la que solicitó a la Junta Directiva que instruyera a la organización de la ICANN a aplazar la imposición de Cumplimiento Contractual del requisito del FOA del Registrador receptor de la Política de transferencia hasta que este asunto se resuelva en la revisión de la Política de transferencia prevista por la GNSO.
  
  ¿Cuál es la propuesta que se está considerando?
  
  La propuesta que se está considerando es una solicitud del Consejo de la GNSO para que la Junta Directiva de la ICANN instruya a la organización de la ICANN a aplazar la imposición de Cumplimiento Contractual del requisito de la Política de transferencia relativo al FOA del Registrador receptor.
  
  La Política de transferencia exige que una transferencia entre registradores "solo proceda si el Registrador receptor recibe la confirmación de la transferencia del Contacto de transferencia". Dicha autorización "debe realizarse a través de un Formulario de Autorización (FOA) Estandarizado válido". La Especificación Temporaria, en vigencia a partir del 25 de mayo de 2018, sustituyó este requisito del FOA del Registrador receptor en determinadas circunstancias y estableció que: "hasta el momento en que la ICANN exija que se ofrezca el servicio de RDAP (u otros métodos seguros de transferencia de datos), si el Registrador receptor no puede acceder a los datos de registración actuales en ese momento para un nombre de dominio objeto de transferencia, los requisitos correspondientes de la Política de transferencia serán sustituidos [...]". En la sección 1.1 del Anexo G de la Especificación Temporaria, se establece que cuando el Registrador receptor no pueda acceder a los datos de registración actuales en ese momento para el nombre de dominio objeto de una transferencia, el "Registrador receptor no está OBLIGADO a obtener un Formulario de autorización del Contacto de la transferencia".
  
  Sin embargo, esta disposición sustitutiva del Anexo G de la Especificación Temporaria solo se aplica si los datos de registración actuales en ese momento no son accesibles en el Servicio de Directorio de Datos de Registración (RDDS)/WHOIS público en el momento de la solicitud de transferencia. Cuando los datos de registración se muestran en el RDDS/WHOIS público, sigue aplicándose el requisito del FOA del Registro receptor.
  
  Como se expone con mayor detalle a continuación, el Grupo de Partes Interesadas de Registradores (RrSG) ha identificado problemas en la implementación de este requisito. El Consejo de la GNSO citó estos problemas al presentar esta solicitud a la Junta Directiva.
  
  La Política provisional de datos de registración para los gTLD (Política provisional), en vigencia desde el 20 de mayo de 2019, exige la implementación continua de medidas acordes con la Especificación Temporaria. Además, el Informe Final de la Fase 1 del Proceso Expeditivo de Desarrollo de Políticas sobre la Especificación Temporaria para los Datos de Registración de los gTLD, en la Recomendación 24, es coherente con la Especificación Temporaria y no altera las obligaciones contractuales actuales. Por lo tanto, los problemas de implementación identificados por el RrSG continuarán persistiendo cuando entre en vigencia la Política de datos de registración.
  
  Ante estos problemas de implementación, el Consejo de la GNSO solicitó a la Junta Directiva de la ICANN que remita la cuestión del FOA del Registrador receptor a la revisión anticipada de la Política de transferencia y que instruya a la organización de la ICANN que aplace la imposición del cumplimiento del requisito del FOA del Registrador receptor hasta que esta cuestión se resuelva en la revisión de la Política de transferencia.
  
  ¿Qué inquietudes o cuestiones fueron planteadas por la comunidad?
  
  El RrSG planteó sus preocupaciones sobre el requisito del FOA del Registrador receptor en una carta del 9 de octubre de 2019 al Consejo de la GNSO. Al plantear estas cuestiones, el RrSG expresó que le preocupaba que la Política de transferencia se deba implementar conforme al Reglamento General de Protección de Datos (GDPR), la Ley de Privacidad del Consumidor de California (CCPA) y otras leyes de privacidad aplicables.
  
  El RrSG señaló en su carta que, incluso cuando los datos están presentes en el campo de correo electrónico del registratario en el resultado público del RDDS, un correo electrónico enviado a esa dirección puede no ir directamente al registratario debido a que el correo electrónico está oculto, omitido, sustituido por un URL de formulario web, o utiliza direcciones de correo electrónico seudonimizadas. Consideran que si un registrador implementó un sistema para enviar el FOA del Registrador receptor a cualquier dirección que figure en el RDDS público, no existe garantía alguna de que el correo electrónico llegue al registratario. En consecuencia, los registradores sostienen que no pueden establecer un proceso automatizado confiable para continuar procesando el gran volumen de transferencias entre los registradores. Según los registradores, esto acabaría frustrando el propósito de la Política de transferencia, que es permitir a los registratarios tener la posibilidad de transferir nombres de dominio a otros registradores. Además, el RrSG afirma que muchos registradores creen que, en virtud del Reglamento General de Protección de Datos (GDPR) de la Unión Europea, el registrador receptor no tiene consentimiento para procesar esta información porque eso requeriría que los registradores envíen un correo electrónico a una persona que no es su cliente.
  
  Antes de la adopción de la Especificación Temporaria, el 1 de mayo de 2018, el comité de operaciones técnicas de la Cámara de Partes Contratadas (CPH) propuso a la organización de la ICANN eliminar el requisito del FOA del Registrador receptor, y declaró en una carta que: "Después del 25 de mayo de 2018, los registradores receptores no tendrán la capacidad de obtener el correo electrónico del registratario o un proxy del resultado público de WHOIS; los datos del registro o registrador emisor no estarán disponibles de forma consistente". Afirmó también que el actual proceso de transferencia, que requiere ambos FOA, se desarrolló antes de que los códigos de autorización se utilizaran de manera consistente en todos los registros. Además, el comité expresó que el FOA del Registrador receptor proporciona una protección insignificante en el contexto de una transferencia de dominio y que los registradores casi nunca confían en el FOA del Registrador receptor en el contexto de una disputa por transferencia.
  
  ¿Existen impactos positivos o negativos para la comunidad?
  
  En la carta del 9 de octubre de 2019, el RrSG declaró que han "observado que la gran mayoría de los registradores acreditados por la ICANN ya no envían el FOA del Registrador receptor después de la Especificación Temporal, y parece que no hay pruebas de un aumento de las transferencias no autorizadas desde mayo de 2018". Además, el departamento de Cumplimiento Contractual de la ICANN no ha visto un aumento sustancial de los reclamos sobre transferencias no autorizadas. Los datos que ha reunido Cumplimiento Contractual de la ICANN indican que 143 casos de transferencias no autorizadas se cerraron 13 meses antes de la adopción de la Especificación Temporaria (mayo de 2017 - mayo de 2018); y 138 casos se cerraron 13 meses directamente después de la adopción de la Especificación Temporaria (junio de 2018 - junio de 2019).
  
  Según lo que señaló el comité de operaciones técnicas de la CPH, durante las transferencias de gTLD cuando la dirección de correo electrónico no está presente en el RDDS público, el código AuthInfo es suficiente para confirmar la intención del registratario para realizar la transferencia. El FOA del Registrador emisor también confirma esta intención.
  
  El requisito del FOA del Registro receptor sigue causando dificultades de implementación y problemas de cumplimiento para muchos registradores. Este período de cumplimiento diferido dará tiempo a la comunidad de la ICANN para considerar el requisito del FOA del Registrador receptor a través de la revisión de la Política de transferencia. Asimismo, el tiempo adicional permitirá que las partes contratadas afectadas evalúen cualquier posible impacto en la Política de transferencia y permitirá que la función de Cumplimiento Contractual de la ICANN centre sus recursos en las solicitudes con mayor urgencia o impacto.
  
  ¿Se observan impactos fiscales o ramificaciones en la ICANN (plan estratégico, plan operativo, presupuesto), la comunidad o el público?
  
  No se prevé ningún impacto fiscal sobre los recursos de la ICANN, la comunidad y/o el público como resultado de esta acción.
  
  ¿Se observan cuestiones sobre seguridad, estabilidad o flexibilidad relacionadas con el DNS?
  
  No se prevé ningún impacto sobre la seguridad, la estabilidad ni la flexibilidad del DNS.
  
  ¿Hay un proceso de políticas definido dentro de las organizaciones de apoyo de la ICANN o de la decisión de función organizativa y administrativa de la ICANN que requiera comentario público, o que no lo requiera?
  
  Esta resolución forma parte de las funciones administrativas y organizativas que no requieren comentario público.
  
  ¿Esta acción se encuentra dentro de la misión de la ICANN? ¿Cómo se relaciona con el interés público global?
  
  Esta acción está en consonancia con la misión de la ICANN y es en beneficio del interés público, dado que ayuda a garantizar una implementación coherente y coordinada de las políticas en los gTLD.
3. Recomendaciones para la utilización técnica del Conjunto de Reglas para la Generación de Etiquetas para la Zona Raíz
  
  Visto y considerando: Que la Junta Directiva de la ICANN aprobó el Procedimiento para desarrollar y mantener las reglas para la generación de etiquetas para la zona raíz con respecto a las etiquetas de IDNA el 4 de noviembre de 2013, que se ha implementado para desarrollar gradualmente las Reglas para la Generación de Etiquetas de la Zona Raíz para determinar los dominios de alto nivel (TLD) válidos y sus etiquetas de variantes.
  
  Visto y considerando: Que varias comunidades que utilizan un código de escritura han completado sus propuestas para el RZ-LGR, de las cuales dieciséis códigos de escritura han sido integrados en la tercera versión del RZ-LGR, mientras que muchos de los códigos de escritura restantes se encuentran en proceso de finalizar sus propuestas para RZ-LGR.
  
  Visto y considerando: Que la Junta Directiva de la ICANN aprobó las Recomendaciones para la gestión de TLD con variantes de IDN el 14 de marzo de 2019 que requieren el uso del RZ-LGR para determinar los IDN TLD válidos y sus etiquetas de variantes, y solicitó que la ccNSO y la GNSO tengan en cuenta estas recomendaciones para desarrollar sus respectivas políticas pertinentes para los TLD con variantes de IDN y a la vez asegurar una solución consistente.
  
  Visto y considerando: Que la Junta Directiva de la ICANN solicitó además a la comunidad de la ICANN que formara un grupo de estudio para investigar cualquier problema en el empleo técnico del RZ-LGR para determinar los IDN TLD válidos y sus etiquetas de variantes.
  
  Visto y considerando: Que la comunidad de la ICANN formó el grupo de estudio que finalizó las Recomendaciones para la utilización técnica del RZ-LGR tras recibir los aportes de la comunidad, y publicó estas recomendaciones el 7 de octubre de 2019. Estas recomendaciones han sido revisadas por la organización de la ICANN y consideradas por la Junta Directiva de la ICANN.
  
  Resuélvase (2020.01.26.03): La Junta Directiva solicita que los Consejos de la ccNSO y la GNSO tengan en cuenta las Recomendaciones para la utilización técnica del RZ-LGR cuando desarrollen sus respectivas políticas para definir y gestionar los TLD con variantes de IDN para los TLD actuales, así como para las futuras solicitudes de TLD.
  
  Fundamento de la resolución 2020.01.26.03
  
  En el trabajo inicial realizado por la comunidad en 2012 sobre las cuestiones relacionadas con los TLD con variantes de IDN, como parte del Informe de Cuestiones Integradas (IIR)¹, se determinó que no existe una definición aceptada de lo que puede constituir una relación de variante entre las etiquetas de alto nivel. Para abordar esta cuestión, 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 de LGR)². Este procedimiento permite definir reglas para la generación de etiquetas para que diferentes códigos de escritura determinen las etiquetas de TLD válidas y sus variantes. En 2013, la Junta Directiva de la ICANN aprobó este procedimiento y solicitó a la organización y a la comunidad de la ICANN que lo implementara. En base al proceso estipulado en el Procedimiento de LGR, hasta la fecha, varios Paneles de Generación (GP) han completado sus propuestas de RZ-LGR, de las cuales dieciséis códigos de escritura ya han sido integrados en la tercera versión del RZ-LGR (RZ-LGR-3). Muchas de las comunidades de códigos de escritura restantes también se encuentran en proceso de finalizar sus propuestas para el RZ-LGR. Además, la Junta Directiva de la ICANN aprobó las recomendaciones³ para la gestión de los TLD con variantes de IDN, que requieren el uso del RZ-LGR para determinar los IDN TLD válidos y sus etiquetas de variantes, y solicitó a la ccNSO y a la GNSO que las tengan en cuenta en sus procesos de desarrollo de políticas.
  
  Con la disponibilidad del RZ-LGR y su función central prevista en la determinación de los TLD válidos y sus etiquetas de variantes, la Junta Directiva de la ICANN solicitó a la comunidad de la ICANN (incluidas las Organizaciones de Apoyo (SO), los Comités Asesores (AC) y la Junta de Arquitectura de Internet (IAB)) que estudie las cuestiones relacionadas con el uso técnico del RZ-LGR de manera coherente en todos los IDN TLD, incluidos los IDN gTLD y los IDN ccTLD. En consecuencia, el Grupo de Estudio (SG) sobre el RZ-LGR se formó a partir de los nominados de las SO, los AC, la IAB y voluntarios adicionales de la comunidad de la ICANN para atender la solicitud de la Junta Directiva de la ICANN. Tras su formación, la primera tarea del Grupo de Estudio sobre el RZ-LGR se centró en el alcance de su trabajo y la finalizó después de recibir los comentarios de la comunidad a través de la primera convocatoria a comentario público en agosto de 2018. El Grupo de Estudio deliberó sobre los detalles técnicos pertinentes en base a este alcance y elaboró un conjunto de recomendaciones. Estas recomendaciones se publicaron en el segundo comentario público del Grupo de Estudio en mayo de 2019. En base a los aportes de la comunidad, el Grupo de Estudio finalizó estas recomendaciones y las publicó el 7 de octubre de 2019 para que la Junta Directiva de la ICANN las examinara más a fondo.
  
  Habrá un impacto fiscal de estas recomendaciones debido al mantenimiento del RZ-LGR basado en el Procedimiento de LGR y el despliegue y mantenimiento de una Herramienta de LGR para procesar etiquetas de TLD basadas en el RZ-LGR. Se prevé que el impacto fiscal continuado para mantener el RZ-LGR será menos significativo que el apoyo financiero existente que se está destinando a su desarrollo. Además, la organización de la ICANN ya ha desarrollado e implementado una Herramienta de LGR para apoyar a los Paneles de Generación basados en códigos de escritura en el desarrollo de sus propuestas de RZ-LGR que pueden utilizarse para procesar etiquetas de TLD en el futuro. El impacto fiscal real también depende de las recomendaciones que finalmente desarrollen los Consejos de la ccNSO y la GNSO a través de sus respectivos procesos de políticas relacionados con los IDN TLD y sus etiquetas de variantes, y que adopte la Junta Directiva de la ICANN.
  
  Las recomendaciones apoyan la misión de la ICANN y contribuyen a un funcionamiento seguro y estable del sistema de identificadores únicos de múltiples maneras, dado que: apoyan una definición uniforme de los TLD con variantes de IDN en los gTLD y ccTLD y tanto para los TLD existentes como para las futuras solicitudes de TLD; apoyan un mecanismo impulsado por la comunidad para mantener el RZ-LGR en línea con el Procedimiento de LGR que mantiene su estabilidad; y destacan y abordan cualquier discrepancia entre lo que se permite a través del RZ-LGR y lo que se delega en la zona raíz. Esto se logra respetando la función de desarrollo de políticas de la comunidad. El trabajo, que respalda la utilización del RZ-LGR para determinar de manera coherente y posiblemente delegar los TLD con variantes de IDN, también contribuye al interés público mediante la mejora del acceso al Sistema de Nombres de Dominio (DNS) de Internet en diferentes códigos de escritura.
4. Adopción del Plan Operativo y Presupuesto de la IANA para el Año Fiscal 2021
  
  Visto y considerando: Que la versión preliminar del Plan Operativo y Presupuesto (OP&B) de la IANA para el año fiscal 2021 se publicó para comentario público conforme a los Estatutos el 14 de octubre de 2019.
  
  Visto y considerando: Que los comentarios recibidos a través del proceso de comentarios públicos fueron revisados, respondidos y entregados al Comité de Finanzas de la Junta Directiva (BFC) para que los revisen y realicen sus comentarios.
  
  Visto y considerando: Que todos los comentarios públicos se han tenido en cuenta y, en los casos factibles y apropiados, se han incorporado y se elaboró una versión final del OP&B de la IANA para el año fiscal 2021. Conforme a los Estatutos, la Junta Directiva adoptará el OP&B de la IANA y luego se publicará en el sitio web de la ICANN.
  
  Visto y considerando: Que los comentarios públicos recibidos, así como otros aportes solicitados de la comunidad, se tuvieron en cuenta para determinar las revisiones requeridas a la versión preliminar del Plan Operativo y Presupuesto de PTI para el Año Fiscal 2021.
  
  Resuélvase (2020.01.26.04): La Junta Directiva aprueba el Plan Operativo y Presupuesto de la IANA para el año fiscal 2021.
  
  Fundamento de la resolución 2020.01.26.04
  
  De conformidad con la Sección 22.4 de los Estatutos de la ICANN, la Junta Directiva deberá aprobar un presupuesto anual de la IANA y publicarlo en el sitio web de la ICANN. El 14 de octubre de 2019, las versiones preliminares del Plan Operativo y Presupuesto (OP&B) de PTI para el año fiscal 2021 y el OP&B de la IANA para el año fiscal 2021 se publicaron para comentario público. La Junta Directiva de PTI aprobó el OP&B de PTI para el año fiscal 2021 el 9 de enero de 2020 y dicho presupuesto se recibió como aporte al OP&B de la IANA para el año fiscal 2021.
  
  El OP&B de la entidad PTI para el año fiscal 2021 y la versión preliminar del OP&B de la IANA para el año fiscal 2021 se basaron en diversos debates con los miembros de la organización de la ICANN y de la comunidad de la ICANN, incluidas extensas consultas con las organizaciones de apoyo y comités asesores de la ICANN y otros grupos de partes interesadas durante los meses previos.
  
  Todos los comentarios recibidos de todas las maneras fueron considerados en el desarrollo del OP&B de la IANA para el año fiscal 2021. En los casos factibles y pertinentes, estos aportes se han incorporado en la versión final del OP&B de la IANA para el año fiscal 2021 propuesta para su adopción.
  
  El OP&B de la IANA para el año fiscal 2021 tendrá un impacto positivo en la ICANN, dado que proporciona un marco adecuado mediante el cual se prestarán los servicios de la IANA, además de los fundamentos para que la organización sea responsable de manera transparente.
  
  Esta decisión es en beneficio del interés público y se enmarca dentro de la misión de la ICANN, dado que es plenamente compatible con los planes estratégicos y operativos de la ICANN, y cuyos resultados permiten a la ICANN cumplir con su misión.
  
  Esta decisión tendrá un impacto fiscal en la ICANN y la comunidad de la forma prevista. El impacto sobre la seguridad, la estabilidad y la flexibilidad del sistema de nombres de dominio (DNS) respecto de cualquier otra financiación dedicada a dichos aspectos del DNS debería ser positivo.
  
  Esta medida constituye una función organizativa y administrativa que ya se ha sometido a comentario público, según se indicó anteriormente.
5. Revisión de Competencia, Confianza y Elección de los Consumidores (CCT): Plan de implementación sobre las seis recomendaciones aceptadas
  
  Visto y considerando: Que la ICANN tiene la obligación, en virtud de la Afirmación de Compromisos, de "organizar una revisión que analizará hasta qué punto la introducción o expansión de los gTLD ha promovido la competencia, confianza y elección de los consumidores, como también la efectividad de (a) el proceso de presentación y evaluación de solicitudes, y (b) las medidas de protección implementadas para mitigar cuestiones derivadas de dicha introducción o expansión". Se anunció un equipo de revisión dirigido por la comunidad, el Equipo de Revisión de Competencia, Confianza y Elección de los Consumidores (CCT-RT), el 23 de diciembre de 2015 para cumplir con ese mandato.
  
  Visto y considerando: Que el CCT-RT presentó un Informe Final que contiene 35 recomendaciones de consenso total a la Junta Directiva de la ICANN para su consideración el 8 de septiembre de 2018 ("Informe Final").
  
  Visto y considerando: Que la Junta Directiva de la ICANN tomó medidas sobre cada una de las 35 recomendaciones emitidas en el Informe Final como se especifica en la tabla de calificación titulada "Recomendaciones finales de CCT: Acción de la Junta Directiva (1 de marzo de 2019)" ("Tabla de calificación").
  
  Visto y considerando: Que la Junta Directiva resolvió aceptar las recomendaciones 1, 17, 21, 22, 30, 31 de CCT, con sujeción a las consideraciones de costo e implementación, según se especifica en la Tabla de calificación, y ordenó al Presidente y Director Ejecutivo de la ICANN, o a quien este designe, que elabore y presente a la Junta Directiva un plan para la implementación, con el objetivo de completar y proporcionar el plan a la comunidad para su consideración a más tardar seis meses después de dicha acción de la Junta Directiva.
  
  Visto y considerando: Que se presentó un Plan de implementación para comentario público el 11 de septiembre de 2019. También se solicitaron comentarios de la comunidad sobre la propuesta para incluir la implementación de las recomendaciones de CCT en el proceso de elaboración del plan operativo y presupuesto de la ICANN, según corresponda, que permitan la priorización adecuada en el contexto de todo el trabajo de la ICANN. La convocatoria para presentar comentarios aportó un total de cinco comentarios; el análisis y las respuestas de la organización de la ICANN a los aportes recibidos pueden consultarse en el resumen que elaboró la organización de la ICANN.
  
  Resuélvase (2020.01.26.05): la Junta Directiva ordena al Presidente y Director Ejecutivo de la ICANN, o a quien este designe, que comience la implementación de las recomendaciones del CCT-RT aceptadas como se propone en el Plan de implementación. El trabajo de implementación, para el cual no se necesitan costos ni recursos adicionales significativos, debe comenzar lo antes posible. Todas las recomendaciones de CCT que se aborden en el Plan de implementación y que requieran un presupuesto y recursos significativos, deben incluirse en los procesos de elaboración del plan operativo y presupuesto, para permitir que la comunidad las examine debidamente y establezca prioridades, según corresponda, en el trabajo planificado.
  
  Fundamento de la resolución 2020.01.26.05
  
  ¿Por qué la Junta Directiva aborda esta cuestión?
  
  Como se detalla en el Artículo 1 de los Estatutos de la ICANN, las revisiones son medidas de responsabilidad importantes que son fundamentales para mantener un modelo de múltiples partes interesadas saludable y para ayudar a la ICANN a cumplir su misión. Las revisiones también contribuyen a asegurar que la ICANN sirve al interés público. La primera Revisión de Competencia, Confianza y Elección de los Consumidores (CCT), iniciada en virtud de la Afirmación de Compromisos (AoC), es un aspecto importante del compromiso de la ICANN con la revisión y evaluación continua de áreas clave.
  
  El Equipo de Revisión de Competencia, Confianza y Elección de los Consumidores (CCT-RT) presentó su Informe Final y Recomendaciones a la Junta Directiva de la ICANN el 8 de septiembre de 2018.
  
  El 1 de marzo de 2019, la Junta Directiva de la ICANN tomó medidas sobre las Recomendaciones Finales que elaboró el CCT-RT. De acuerdo con los Estatutos de la ICANN, la Junta Directiva de la ICANN examinó detenidamente la mejor manera de abordar cada una de las recomendaciones y decidió tres categorías de acción: aceptada, pendiente y transmitiéndose a diferentes partes de la comunidad, como se documenta en una tabla de calificación detallada que acompaña a la resolución de la Junta Directiva.
  
  En la actualidad, la Junta Directiva está adoptando medidas para dirigir la implementación de las recomendaciones aceptadas que se describen en el Plan de implementación.
  
  ¿Cuál es la propuesta que se está considerando?
  
  La organización de la ICANN elaboró un Plan de implementación en cumplimiento de la resolución 2019.03.01.03 de la Junta Directiva para: 1) aceptar las recomendaciones 1, 17, 21, 22, 30, 31 de CCT, con sujeción a consideraciones de costo e implementación; y 2) ordenar a la ICANN que "elabore y presente a la Junta Directiva un plan para la implementación de las recomendaciones aceptadas".
  
  El Plan de implementación establece el enfoque para la implementación de las recomendaciones aceptadas. Contiene información como una descripción de las actividades, la duración estimada, los recursos necesarios (incluida la fuente de financiación), las dependencias y otros elementos, siempre que sea posible y estén disponibles.
  
  Además de articular los hitos y los pasos a seguir para la implementación, el Plan de implementación informa, en la mayor medida posible, sobre los costos previstos y los recursos necesarios para completar la implementación. Aborda la forma en que los recursos asignados a las recomendaciones específicas apoyan a la ICANN en el cumplimiento de su misión y ayuda a comprender el equilibrio de recursos y la priorización necesarios para financiar el trabajo identificado para cumplir con las recomendaciones del CCT-RT.
  
  El Plan de implementación fue desarrollado por expertos en la materia de la organización de la ICANN que lideran los temas de las seis recomendaciones aceptadas.
  
  ¿Cuáles son las partes interesadas u otros participantes consultados?
  
  El Plan de implementación se publicó para comentario público el 11 de septiembre de 2019. También se solicitaron comentarios de la comunidad sobre la propuesta para incluir la implementación de las recomendaciones de CCT en el proceso de elaboración del plan operativo y presupuesto de la ICANN, que permitan la priorización adecuada en el contexto más amplio de todo el trabajo de la ICANN. La convocatoria para presentar comentarios se cerró el 31 de octubre y aportó un total de cinco contribuciones. Según el caso, los comentarios se abordaron en la sección "Análisis" del Informe resumido del comentario público.
  
  Antes de publicar el Plan de implementación, se invitó a los Guías de la implementación del CCT-RT⁴ a participar en el Grupo de Expertos de la Junta Directiva dedicado a la iniciativa de CCT para obtener un panorama general del camino a seguir propuesto y los planes para abordar la acción de la Junta Directiva del 1 de marzo sobre las Recomendaciones Finales de CCT.
  
  ¿Se observan impactos fiscales o ramificaciones en la ICANN (plan estratégico, plan operativo, presupuesto), la comunidad o el público?
  
  Como se establece en el Plan de implementación, la implementación de estas recomendaciones puede requerir, en algunos casos, recursos superiores a los asignados en el presupuesto actual. Por consiguiente, la resolución de la Junta Directiva solicita que las recomendaciones abordadas en el Plan de implementación que requieren recursos y presupuestos significativos se incluyan en los ciclos de elaboración del plan operativo y presupuesto.
  
  ¿Existen impactos positivos o negativos para la comunidad?
  
  La adopción del Plan de implementación permitirá a la organización de la ICANN comenzar a implementar algunas de las recomendaciones desarrolladas por el equipo de revisión liderado por la comunidad tan pronto como sea posible. Se prevé que la implementación de recomendaciones específicas requerirá que la comunidad participe en algunas consultas, como se indica en el Plan de implementación. Esto podría afectar la carga de trabajo y los recursos de la comunidad.
  
  ¿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.
  
  ¿Esta acción se encuentra dentro de la misión de la ICANN? ¿Cómo se relaciona con el interés público global?
  
  Esta acción se enmarca dentro de la misión y el mandato de la ICANN. Se considera de interés público porque es el resultado de un compromiso clave asumido en 2009 en el marco de la Afirmación de Compromisos, ahora incorporada en los Estatutos de la ICANN. Las revisiones son una parte importante y esencial de la forma en que la ICANN cumple sus compromisos. El alcance de esta revisión está inherentemente ligado a los valores fundamentales de la ICANN de introducción y promoción de la competencia en el registro de nombres de dominio.
  
  ¿Hay un proceso de políticas definido dentro de las organizaciones de apoyo de la ICANN o de la decisión de función organizativa y administrativa de la ICANN que requiera comentario público, o que no lo requiera?
  
  Se recibió el comentario público antes de la consideración de la Junta Directiva.
6. Gerente de sucursal y representante legal de la oficina de Bruselas
  
  Visto y considerando: Que la Corporación para la Asignación de Nombres y Números en Internet, una corporación de beneficio público sin ánimo de lucro, debidamente incorporada y regida por las leyes del estado de California y de los Estados Unidos de América, con sede comercial principal en 12025 E. Waterfront Drive, Suite 300, Los Ángeles, California, EE. UU. 90094 ("ICANN"), ha establecido la oficina sucursal una entidad extranjera sin ánimo de lucro en Bélgica, con domicilio actual en 6 Rond Point Schuman, B-1040, Bruselas, bajo el nombre de Corporación para la Asignación de Nombres y Números en Internet.
  
  Visto y considerando: Que por resolución 2017.06.24.13 de la Junta Directiva de la ICANN, Jean-Jacques Sahel, fue designado como el gerente de sucursal y el representante legal en Bélgica, para desempeñarse en este rol hasta que se retire su designación por resolución de esta Junta Directiva.
  
  Visto y considerando: Que el rol de Jean-Jacques Sahel como gerente de sucursal y representante legal en Bélgica finalizó en octubre de 2019, tras su renuncia de la ICANN.
  
  Visto y considerando: Que a partir del 26 de enero de 2020, Christopher Mondini, [INFORMACIÓN DE CONTACTO IDENTIFICABLE OMITIDA] asumirá las responsabilidades de gerente de sucursal y representante legal para la oficina de la ICANN en Bruselas, Bélgica.
  
  Resuélvase (2020.01.26.06): Con vigencia inmediata, cesa la autoridad de Jean-Jacques Sahel para desempeñarse como gerente de sucursal o representante legal de la oficina sucursal de la ICANN en Bruselas, Bélgica.
  
  Resuélvase (2020.01.26.07): A partir del 26 de enero de 2020, Christopher Mondini será el nuevo gerente de sucursal y representante legal de la oficina sucursal de la ICANN en Bruselas, Bélgica.
  
  Resuélvase (2020.01.26.08): Christopher Mondini tendrá plenas facultades para llevar a cabo la gestión diaria de la sucursal de la ICANN en Bruselas, Bélgica, que incluye, a modo meramente ilustrativo, las siguientes facultades específicas con respecto a las operaciones de dicha sucursal:
  1. Representar a la corporación frente a todas las autoridades públicas, ya sean gubernamentales, regionales, provinciales, municipales u otras, los Tribunales de Comercio, el banco Crossroads Bank for Enterprises, los contadores corporativos, las autoridades impositivas, incluida la administración de IVA, el servicio de cheques postales, aduanas, servicios postales, telefónicos y telegráficos, y todos los demás servicios y organismos públicos.
  2. Firmar la correspondencia a diario, recibir y firmar la entrega de cartas o paquetes registrados que se envíen a la corporación mediante los servicios o las compañías de correo postal, aduana o transporte aéreo, ferroviario u otro.
  3. Suscribir, firmar, transferir o cancelar todas las políticas de seguros y todos los contratos de suministro de servicios de agua, gas, energía, teléfono u otros de la sucursal, así como también pagar las facturas o los gastos relacionados.
  4. Firmar y aceptar todas las cotizaciones, los contratos y los pedidos para la compra o venta de equipo para la oficina y otros bienes de inversión, servicios o suministros necesarios para el funcionamiento de la sucursal, siempre que esto no obligue a la corporación a gastar más de EUR 500.
  5. Contratar o conceder arrendamientos, incluidos los arrendamientos a largo plazo, sobre bienes inmuebles, equipos u otros activos fijos y celebrar contratos de arrendamiento con respecto a los mismos, previa aprobación del Presidente y Director Ejecutivo de la ICANN o la Junta Directiva de la ICANN.
  6. Reclamar, recaudar y recibir sumas de dinero, documentos o propiedad de cualquier tipo y firmar su respectiva recepción.
  7. Afiliar la sucursal a todos los profesionales u organizaciones comerciales.
  8. Representar a la sucursal en los procedimientos legales o de arbitraje, como demandante o demandado; tomar todas las medidas necesarias respecto de los procedimientos antes mencionados, obtener todas las sentencias y observar su ejecución.
  9. Elaborar versiones preliminares de todos los documentos y firmarlos a fin de poder ejecutar las facultades antes descriptas.
  10. Adoptar todas las medidas necesarias para implementar las resoluciones y recomendaciones de la Junta Directiva.
  11. Mudar la sucursal a otra ubicación en Bélgica tras la aprobación del Presidente y Director Ejecutivo de la ICANN o de la Junta Directiva de la ICANN.
  Fundamento de las resoluciones 2020.01.26.06 – 2020.01.26.08
  
  La ICANN está comprometida a continuar su alcance global y presencia en todas las zonas horarias del mundo. Para este fin, la Junta Directiva de la ICANN aprobó las resoluciones para establecer una oficina sucursal en Bélgica y, en 2017, designó a Jean-Jacques Sahel como gerente de sucursal y representante legal con facultades delegadas asociadas para desempeñar estas funciones. El Sr. Sahel renunció a su cargo en la ICANN en octubre de 2019. Por ello, la Junta Directiva debe designar a un nuevo gerente y representante legal de sucursal. La resolución por la cual se designó al Sr. Mondini como gerente y representante legal de sucursal con delegación de facultades específicas para administrar la sucursal, continúa con la administración efectiva de la sucursal de la ICANN tras la renuncia del actual gerente y representante legal de sucursal.
  
  El compromiso de la ICANN para lograr un alcance global es coherente con el interés público y con la misión de la ICANN en cuanto a que ayuda a respaldar el enfoque multisectorial global de la ICANN.
  
  Habrá un impacto fiscal en la ICANN solo en la medida de los gastos por la designación del nuevo gerente de sucursal, pero este impacto puede contemplarse en el presupuesto para el año fiscal 2020.
  
  Se prevé que esta resolución no tenga ningún impacto en la seguridad, estabilidad y flexibilidad del Sistema de Nombres de Dominio.
  
  Esta decisión forma parte de las funciones administrativas y organizacionales que no requieren comentario público.

Orden del día principal:
1. Asesoramiento del GAC: Comunicado de Montreal (noviembre de 2019)
  
  Visto y considerando: Que el Comité Asesor Gubernamental (GAC) se reunió durante la reunión ICANN66 en Montreal, Canadá, y emitió un comunicado el 6 de noviembre de 2019 ("Comunicado de Montreal"), que contiene cuatro puntos de asesoramiento consensuado y tres puntos de seguimiento del asesoramiento anterior. El asesoramiento consensuado refiere a la Revisión de CCT y las Rondas posteriores de nuevos gTLD, y al Servicio de Directorio de Registración de Nombres de Dominio y la Protección de Datos. El seguimiento sobre el asesoramiento anterior se refiere a la Protección de las designaciones e identificadores de la Cruz Roja y la Media Luna Roja, las protecciones de la OIG y los Servicios de Directorio de Registración de Nombres de Dominio y la Protección de Datos.
  
  Visto y considerando: Que, en una carta del 16 de diciembre de 2019, el Presidente y Director Ejecutivo de la ICANN proporcionó información sobre los esfuerzos de implementación relacionados con la Revisión de CCT y planteó preguntas aclaratorias con respecto al asesoramiento del GAC sobre el tema al Presidente del GAC.
  
  Visto y considerando: Que, en una llamada del 17 de diciembre de 2019, la Junta Directiva de la ICANN y el GAC debatieron sobre el Comunicado de Montreal y las preguntas aclaratorias de la Junta Directiva de la ICANN con respecto al asesoramiento del GAC.
  
  Visto y considerando: Que, en una carta del 19 de diciembre de 2019, el Consejo de la GNSO proporcionó sus comentarios a la Junta Directiva en relación con el seguimiento del asesoramiento anterior contenido en el Comunicado de Montreal.
  
  Visto y considerando: Que, en una carta del 6 de enero de 2020, la organización de la ICANN proporcionó una actualización del cronograma de implementación de la Fase 1 del EPDP, tal como lo solicitó el GAC en su Comunicado de Montreal.
  
  Visto y considerando: Que, en una carta del 22 de enero de 2020, el GAC proporcionó aclaraciones adicionales con respecto a su asesoramiento del Comunicado de Montreal.
  
  Visto y considerando: Que la Junta elaboró una tabla de calificación para responder al asesoramiento del GAC en el Comunicado de Montreal, teniendo en cuenta el diálogo previo entre la Junta Directiva y el GAC sobre los temas, así como la información proporcionada por el Consejo de la GNSO.
  
  Resuélvase (2020.01.26.09): La Junta adopta la tabla de calificación titulada "Asesoramiento del GAC – Comunicado de Montreal: Acciones y Actualizaciones (26 de enero de 2020)" en respuesta a los puntos del asesoramiento del GAC en el Comunicado de Montreal.
  
  Fundamento de la resolución 2020.01.26.09
  
  El Artículo 12, sección 12.2(a)(ix) de los Estatutos de la ICANN permite al GAC "exponer temas a la Junta Directiva directamente, ya sea por medio de un comentario o asesoramiento previo, o a través de recomendaciones específicas de acción, recomendaciones sobre el desarrollo de políticas nuevas o sobre la revisión de las políticas existentes”. En su Comunicado de Montreal (6 de noviembre de 2019), el GAC emitió un asesoramiento consensuado a la Junta Directiva sobre la Revisión de CCT y las Rondas posteriores de nuevos gTLD, y el Servicio de Directorio de Registración de Nombres de Dominio y la Protección de Datos. El GAC también emitió comentarios complementarios sobre el asesoramiento anterior sobre la Protección de las designaciones e identificadores de la Cruz Roja y la Media Luna Roja, las protecciones de la OIG y los Servicios de Directorio de Registración de Nombres de Dominio y la Protección de Datos. Los Estatutos de la ICANN requieren que la Junta Directiva tenga en cuenta el asesoramiento del GAC respecto de las cuestiones de políticas públicas en la formulación y adopción de políticas. Si la Junta Directiva decide llevar a cabo una acción que no se ajusta al asesoramiento del GAC, ésta deberá informarlo al GAC y explicar los motivos por los cuales ha decidido no seguir su asesoramiento. Todo asesoramiento del GAC aprobado por pleno consenso del GAC (tal como se define en los Estatutos) puede ser rechazado únicamente por una votación de no menos del 60 % de la Junta Directiva, y el GAC y la Junta Directiva entonces intentarán, de buena fe y de manera oportuna y eficaz, encontrar una solución mutuamente aceptable.
  
  La Junta Directiva está tomando medidas hoy sobre todos los puntos del Comunicado de Montreal.
  
  Las acciones de la Junta Directiva se describen en la tabla de calificación con fecha del 26 de enero de 2020.
  
  Al adoptar su respuesta al asesoramiento del GAC en el Comunicado en Montreal, la Junta Directiva analizó diversos materiales, incluidos, aunque no taxativamente, los siguientes materiales y documentos:
  - Resoluciones de la Junta Directiva del 15 de mayo de 2019 sobre el Comunicado de Kobe: https://www.icann.org/resources/board-material/resolutions-2019-05-15-en#1.a
  - Comunicado de Montreal (6 de noviembre de 2019): https://gac.icann.org/contentMigrated/icann66-montreal-communique
  - Carta del 16 de diciembre de 2019 del Presidente y Director Ejecutivo de la ICANN al Presidente del GAC respecto al asesoramiento del GAC sobre la Revisión de CCT y las Rondas posteriores de nuevos gTLD: https://www.icann.org/en/system/files/correspondence/marby-to-ismail-16dec19-en.pdf
  - Revisión del Consejo de la GNSO del seguimiento sobre el asesoramiento anterior contenido en el Comunicado de Montreal, según se presentó en la carta con fecha 19 de diciembre de 2019 a la Junta Directiva: https://gnso.icann.org/sites/default/files/file/field-file-attach/drazek-et-al-to-botterman-19dec19-en.pdf
  - Carta del 6 de enero de 2020 del Presidente y Director Ejecutivo de la ICANN al Presidente del GAC sobre el Cronograma de implementación de la Fase 1 del EPDP: https://www.icann.org/en/system/files/correspondence/marby-to-ismail-06jan20-en.pdf
  - Carta del 22 de enero de 2020 del Presidente del GAC al Presidente de la Junta Directiva de la ICANN respecto a las aclaraciones adicionales sobre el asesoramiento del Comunicado de Montreal: https://gac.icann.org/contentMigrated/gac-response-to-icann-board-clarification-questions-on-the-gac-montr-al-communiqu-advice
  La adopción del asesoramiento del GAC, tal como se proporciona en la tabla de puntaje, tendrá un impacto positivo en la comunidad porque ayudará a resolver el asesoramiento del GAC respecto de los gTLD y otras cuestiones. Actuar de acuerdo con el asesoramiento del GAC está en consonancia con la misión de la ICANN y la función del GAC en el modelo de múltiples partes interesadas de la ICANN, y apoya el interés público. No se observan impactos fiscales previstos asociados con la adopción de esta Resolución. La aprobación de la resolución no tendrá impacto alguno en las cuestiones de seguridad, estabilidad o flexibilidad relacionadas con el DNS. Esta decisión forma parte de las funciones administrativas y organizacionales que no requieren comentario público.
2. Delegación del dominio البحرين. ("albahrain") que representa Baréin en código de escritura arábigo a la Autoridad Regulatoria de Telecomunicaciones (TRA)
  
  Resuélvase (2020.01.26.10): Como parte del ejercicio de sus responsabilidades conforme al Contrato de Funciones de Nombres de la IANA con la ICANN, la IANA ha examinado y evaluado la solicitud de delegación del dominio de alto nivel con código de país البحرين. a la Autoridad Regulatoria de Telecomunicaciones. La documentación demuestra que se siguieron los procedimientos adecuados durante la evaluación de la solicitud.
  
  Fundamento de la resolución 2020.01.26.10
  
  ¿Por qué la Junta Directiva aborda el tema ahora?
  
  De acuerdo con el Contrato de Funciones de Nombres de la IANA, la entidad PTI, en cumplimiento de la Función de Nombres de la IANA (IANA), ha evaluado una solicitud de delegación de un dominio de alto nivel con código de país (ccTLD) y presenta su informe ante la Junta Directiva para su 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 tiene por objeto aprobar la solicitud para crear el dominio de alto nivel con código de país البحرين. en el código de escritura arábigo y asignar la función de administrador a la Autoridad Regulatoria de Telecomunicaciones.
  
  ¿Cuáles son las partes interesadas u otros participantes consultados?
  
  Durante la evaluación de una solicitud de delegación, la IANA consultó al solicitante y a otras partes interesadas. 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 IANA 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?
  
  La Junta Directiva analizó los siguientes evaluaciones:
  
  [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.
3. Delegación del dominio .ລາວ ("Lao") que representa la República Democrática Popular Lao en código de escritura lao al Centro Nacional de Internet de Laos (LANIC)
  
  Resuélvase (2020.01.26.11): Como parte del ejercicio de sus responsabilidades conforme al Contrato de Funciones de Nombres de la IANA con la ICANN, la IANA ha examinado y evaluado la solicitud de delegación del dominio de alto nivel con código de país .ລາວ al Centro Nacional de Internet de Laos. La documentación demuestra que se siguieron los procedimientos adecuados durante la evaluación de la solicitud.
  
  Fundamento de la resolución 2020.01.26.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, en cumplimiento de la Función de Nombres de la IANA (IANA), ha evaluado una solicitud de delegación de un dominio de alto nivel con código de país (ccTLD) y presenta su informe ante la Junta Directiva para su 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 tiene por objeto aprobar la solicitud para crear el dominio de alto nivel con código de país .ລາວ en el código de escritura lao y asignar el papel de administrador al Centro Nacional de Internet de Laos.
  
  ¿Cuáles son las partes interesadas u otros participantes consultados?
  
  Durante la evaluación de una solicitud de delegación, la IANA consultó al solicitante y a otras partes interesadas. 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 IANA 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?
  
  La Junta Directiva analizó los siguientes evaluaciones:
  
  [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. Consideración de la recomendación del BGC sobre la Solicitud de Reconsideración 19-4
  
  Visto y considerando: Que Merck KGaA y Merck Registry Holdings, Inc. (Solicitantes) presentaron la Solicitud de Reconsideración 19-4 en la que solicitaban que se reconsiderara la denegación por parte de la organización de la ICANN de su solicitud mutua de un segundo aplazamiento de una subasta de controversia por cadena de caracteres para el dominio genérico de alto primer (gTLD) .MERCK (Segunda solicitud).
  
  Visto y considerando: Que los Solicitantes afirman que el personal de la ICANN no consideró información esencial e infringió las políticas establecidas de la ICANN que favorecen la resolución voluntaria de las controversias por cadena de caracteres y permiten la renuncia discrecional de los plazos cuando denegó la Segunda solicitud.
  
  Visto y considerando: Que los Solicitantes afirman además que la denegación de la Segunda solicitud infringió el Compromiso de la ICANN que se establece en sus Estatutos de "tomar decisiones mediante la aplicación de políticas documentadas de manera neutral y objetiva con integridad y equidad".
  
  Visto y considerando: Que el Comité de Mecanismos de Responsabilidad de la Junta Directiva (BAMC) había determinado con anterioridad que la Solicitud 19-4 se ha fundamentado suficientemente y que se la ha enviado al Defensor del Pueblo para su consideración conforme al Artículo 4, Sección 4.2(j) y (k) de los Estatutos de la ICANN.
  
  Visto y considerando: Que el Defensor del Pueblo se ha recusado de este asunto de acuerdo con el Artículo 4, Sección 4.2(l)(iii) de los Estatutos.
  
  Visto y considerando: Que el BAMC consideró cuidadosamente los fundamentos de la Solicitud 19-4 y todos los materiales relevantes y recomendó que la Solicitud 19-4 fuera denegada porque el Personal de la ICANN no dejó de considerar información esencial y no infringió los Compromisos, los Valores Fundamentales ni las políticas establecidas de la ICANN en su denegación de la Segunda solicitud de los Solicitantes.
  
  Visto y considerando: Que el BAMC recomendó que la Junta Directiva solicite a la organización de la ICANN que procure una actualización de los Solicitantes y, si los Solicitantes declaran conjuntamente que han logrado avances desde la presentación de la Solicitud 19-4 y que están muy cerca de una resolución privada, que considere la posibilidad de proporcionar alguna forma de medida discrecional para dar tiempo a los Solicitantes a finalizar una resolución privada.
  
  Visto y considerando: Que los Solicitantes presentaron una Impugnación a la Recomendación del BAMC, conforme al Artículo 4, Sección 4.2(q) de los Estatutos de la ICANN.
  
  Visto y considerando: Que la Impugnación proporcionó una actualización sobre los avances de los Solicitantes para alcanzar una resolución privada de la cuestión de la controversia por cadena de caracteres y estableció que no es probable que los Solicitantes resuelvan sus disputas sobre .MERCK en el próximo mes, y solicitó el aplazamiento de la subasta hasta fines de agosto de 2020.
  
  Resuélvase (2020.01.26.12): La Junta Directiva adopta la Recomendación del BAMC y, por lo tanto, deniega la Solicitud de Reconsideración 19-4.
  
  Resuélvase (2020.01.26.13): La Junta Directiva instruye al Presidente y Director Ejecutivo, o a quien éste designe, que procure obtener una actualización adicional de los Solicitantes sobre el avance del acuerdo. Si los Solicitantes declaran conjuntamente que han logrado avances desde la presentación de la Solicitud 19-4 y la organización de la ICANN considera que los Solicitantes están muy cerca de lograr una resolución privada, la Junta Directiva solicita al Presidente y al Director Ejecutivo, o a quien este designe, que considere la posibilidad de proporcionar a los Solicitantes alguna forma de medida discrecional que les permita disponer de un breve período de tiempo para finalizar una resolución privada.
  
  Resuélvase (2020.01.26.14): Si los Solicitantes no proporcionan una actualización adicional con respecto a los avances de su resolución y/o si la organización de la ICANN no considera que los Solicitantes estén muy cerca de una resolución privada, la Junta Directiva ordena al Presidente y Director Ejecutivo, o a quien este designe, a continuar procesando las solicitudes de .MERCK, incluida la programación de una subasta si la organización de la ICANN lo considera apropiado.
  
  Fundamento de las resoluciones 2020.01.26.12 – 2020.01.26.14
  1. Resumen breve y recomendación
    
    Toda la información contextual fáctica se describe en la Recomendación del BAMC sobre la Solicitud 19-4 (Recomendación del BAMC), que fue revisada y considerada por la Junta y se ha incorporado al presente documento.
    
    El 19 de diciembre de 2019, el BAMC evaluó la Solicitud 19-4 y todos los materiales relevantes y recomendó que la Junta Directiva denegara la Solicitud 19-4 porque el Personal de la ICANN no dejó de considerar información esencial y no infringió los Compromisos, los Valores Fundamentales ni las políticas establecidas de la ICANN en su denegación de la Segunda solicitud de los Solicitantes.
    
    El 3 de enero de 2020, los Solicitantes presentaron una Impugnación a la Recomendación del BAMC (Impugnación), conforme al Artículo 4, Sección 4.2(q) de los Estatutos de la ICANN. Los Solicitantes afirman que: 1) el BAMC hizo una caracterización errónea de la historia de las disputas de los Solicitantes sobre los derechos de marca comercial relacionados con la palabra "Merck"; 2) la regla de la Guía para el Solicitante que prohíbe las renovaciones múltiples no se aplica a los Solicitantes; 3) el BAMC penalizó indebidamente a los Solicitantes por no presentar evidencia de que el Personal de la ICANN no consideró información esencial; (4) al denegar la Segunda solicitud, el Personal de la ICANN ejerció discriminación contra los Solicitantes; y (5) aunque los Solicitantes inicialmente esperaban poder resolver la controversia por cadena de caracteres a principios de 2020, los Solicitantes ahora solicitan al Personal de la ICANN que posponga la subasta hasta fines de agosto de 2020 para que los Solicitantes dispongan del tiempo suficiente para resolver de forma privada la controversia por cadena de caracteres.
    
    La Junta Directiva ha considerado detenidamente la Recomendación del BAMC, así como todos los materiales pertinentes para la Solicitud 19-4, y concluye que la Solicitud 19-4 es denegada. De conformidad con la Recomendación del BAMC, la Junta Directiva solicitará a la organización de la ICANN que procure una actualización adicional de los Solicitantes sobre los avances de la resolución, aunque la Impugnación sugiere que la resolución privada, incluso si se logra, no se producirá hasta agosto de 2020. Si los Solicitantes declaran conjuntamente que han logrado avances desde la presentación de la Solicitud 19-4 y la organización de la ICANN considera que los Solicitantes están más cerca de lograr una resolución privada de lo que sugiere la Impugnación, la Junta Directiva solicita a la organización de la ICANN que considere la posibilidad de proporcionar a los Solicitantes alguna forma de medida discrecional que les permita disponer de un período de tiempo limitado para finalizar un acuerdo.
  2. Cuestión
    
    Las cuestiones son las siguientes:
    - Si el personal de la ICANN no consideró información esencial cuando denegó la solicitud mutua de los Solicitantes de un segundo aplazamiento de la subasta del conjunto de solicitudes controvertidas de .MERCK.
    - Si el Personal de la ICANN infringió las políticas establecidas por la ICANN que favorecen la solución voluntaria de las controversias por cadena de caracteres y permiten la renuncia discrecional de los plazos cuando denegó la solicitud mutua de los Solicitantes de un segundo aplazamiento de la subasta del conjunto de solicitudes controvertidas de .MERCK.
    - Si el personal de la ICANN infringió el Compromiso de la ICANN de "tomar decisiones mediante la aplicación de políticas documentadas de manera coherente, neutral, objetiva y justa" al denegar la solicitud mutua de los Solicitantes de un segundo aplazamiento de la subasta del conjunto de solicitudes controvertidas de .MERCK.
  3. Análisis y fundamentos
    1. El personal de la ICANN no dejó de considerar información esencial antes de denegar la Segunda solicitud
      
      El personal de la ICANN consideró toda la información esencial para denegar la Segunda solicitud. Los Solicitantes sostienen que el Personal de la ICANN hizo caso omiso del historial de litigios multijurisdiccionales entre ellos en relación con la marca "Merck", del hecho de que los Solicitantes esperaban recibir sentencias en varios casos pendientes "en los próximos meses", y del hecho de que los Solicitantes tenían la "esperanza" de poder resolver "pronto" su controversia sobre .MERCK mediante un acuerdo voluntario.⁵ Y los Solicitantes sugieren que estos hechos eran esenciales para su Segunda solicitud.⁶ El BAMC concluyó lo siguiente: 1) los Solicitantes no han presentado ninguna prueba que respalde su convicción de que el personal de la ICANN no consideró la historia de la disputa de los Solicitantes; 2) el personal de la ICANN conoce bien la larga historia de disputas de los Solicitantes; 3) el Personal de la ICANN estaba al tanto de los esfuerzos en curso de los Solicitantes para la resolución privada; y 4) en cualquier caso, la información relativa a la disputa de los Solicitantes o a los intentos de resolución privada no fue esencial para la decisión del Personal de la ICANN sobre la Segunda solicitud.⁷
      
      En su Impugnación, los solicitantes sostienen que no se les exigió presentar pruebas que respaldaran su convicción de que el Personal de la ICANN no consideró información esencial y que sería imposible probar dicha negativa.⁸ La Junta Directiva reconoce que el Personal de la ICANN no se refirió expresamente a los "antecedentes jurídicamente complejos y políticamente sensibles" de los Solicitantes⁹ en su decisión sobre la Segunda solicitud; sin embargo, el registro muestra exactamente lo contrario de lo que afirman los Solicitantes, a saber, que el Personal de la ICANN tenía pleno conocimiento de esos antecedentes. Los Solicitantes deben, pero no han podido, refutar esta evidencia. Por consiguiente, el BAMC concluyó y la Junta Directiva está de acuerdo en que el Personal de la ICANN tenía pleno conocimiento del largo y contencioso historial de los Solicitantes.¹⁰
      
      Los Solicitantes también impugnaron la sugerencia del Personal de la ICANN, en su denegación de la Segunda solicitud, que señala que dos semanas podrían ser suficiente "tiempo para procurar y completar la resolución propia del conjunto de solicitudes controvertidas". Los Solicitantes afirman que "el Personal de la ICANN no entendió el alcance total" de los esfuerzos en curso de los Solicitantes para llegar a un acuerdo voluntario; de lo contrario (según los solicitantes), el Personal de la ICANN se habría dado cuenta de que dos semanas no era tiempo suficiente para que estas partes, dados sus antecedentes jurídicamente complejos y delicados, resolvieran sus disputas.¹¹ Sin embargo, la denegación de la Segunda solicitud por parte del Personal de la ICANN simplemente expresó que la denegación no requería, en sí misma, que las partes dejaran de intentar resolver de forma privada la controversia por cadena de caracteres. La declaración simplemente deja claro que las partes tenían la libertad de continuar las negociaciones hasta la fecha límite para retirarse de la controversia por la cadena de caracteres. Ningún elemento de la denegación de la Segunda solicitud por parte del Personal de la ICANN demuestra que el Personal de la ICANN no apreció la complejidad de la disputa de los Solicitantes. La Junta Directiva está de acuerdo con el BAMC en que no existen pruebas de que el Personal de la ICANN no haya considerado esta información.
      
      En cualquier caso, el BAMC concluyó que la información relativa al historial de disputas e intentos de resolución de los Solicitantes no fue esencial ni relevante para la decisión del Personal de la ICANN sobre la Segunda solicitud.¹² La Junta Directiva está de acuerdo. El Personal de la ICANN denegó la Segunda solicitud conforme a la regla de la ICANN de no conceder más de una solicitud de aplazamiento de la subasta para cualquier conjunto de solicitudes controvertidas, independientemente de la razón de la solicitud.¹³
    2. El personal de la ICANN no infringió las políticas de la ICANN que favorecen los acuerdos voluntarios.
      
      Los Solicitantes afirman que la denegación de la Segunda solicitud por parte del Personal de la ICANN infringió las políticas de la organización que favorecen la resolución voluntaria de los conjuntos de solicitudes controvertidas y tratan las subastas de conjuntos de solicitudes controvertidas como un medio de último recurso únicamente.¹⁴ El BAMC concluyó, y la Junta Directiva está de acuerdo, que la denegación de la Segunda solicitud fue coherente y no infringió la política de la ICANN que favorece la resolución voluntaria de las controversias por cadenas de caracteres y trata a la subasta como un método de desempate únicamente.¹⁵
      
      En su Impugnación, los Solicitantes cuestionan la confianza del BAMC en la declaración de la Guía para el Solicitante que señala que el aplazamiento es "una opción por única vez; la ICANN no concederá más de una solicitud de este tipo por cada conjunto de solicitudes en disputa".¹⁶ Los Solicitantes afirman que este enunciado no se aplica a ellos porque se encuentra en la sección de la Guía para el Solicitante que trata sobre los procedimientos de Evaluación con Prioridad de la Comunidad cuando "se determina que más de una solicitud presentada por una comunidad cumple con el criterio" para la Prioridad de la Comunidad, y ninguna de las solicitudes presentadas por una comunidad para .MERCK cumplía con el criterio para la Prioridad de la Comunidad.¹⁷
      
      Sin embargo, aunque el análisis de la Guía para el Solicitante sobre la regla de un único aplazamiento aparece en la sección de Evaluaciones con Prioridad de la Comunidad, el texto de la Guía para el Solicitante especifica claramente que las solicitudes mutuas de aplazamiento de subastas se concederán una única vez. Además, y en particular, como señaló el BAMC y reconocen los Solicitantes, la Guía para el Solicitante no es el único documento que hace referencia a dicha regla de un único aplazamiento. El "Formulario para solicitar el adelantamiento/aplazamiento de la fecha de una subasta" de la ICANN explica que "la ICANN aceptará una solicitud de aplazamiento por cada conjunto de solicitudes controvertidas".¹⁸ Como señaló el BAMC, la versión actual de las Reglas para las subastas de los nuevos gTLD se refiere al Formulario de solicitud de aplazamiento.¹⁹ El Formulario de solicitud de aplazamiento "proporciona a los solicitantes que han recibido una notificación de intención de Subasta la capacidad de solicitar un adelantamiento o aplazamiento de la fecha de la subasta programada" si todos los miembros del conjunto de solicitudes controvertidas están de acuerdo en aplazar (o adelantar) la fecha de la subasta.²⁰ El formulario está disponible para solicitudes de aplazamiento de cualquier grupo de solicitantes en cualquier conjunto de solicitudes controvertidas (siempre y cuando todos los miembros del conjunto de solicitudes controvertidas estén de acuerdo con el aplazamiento). El Formulario de solicitud de aplazamiento no limita la regla del aplazamiento único a un determinado tipo de conjunto de solicitudes controvertidas, sino que es aplicable a todos.²¹
      
      La Junta Directiva concluye que el Formulario de solicitud de aplazamiento evidencia la regla de la organización de la ICANN de conceder un único aplazamiento de una subasta que se solicita mutuamente, y que las referencias al aplazamiento de subastas en la Guía para el Solicitante y en las Reglas para las subastas no evidencian la intención de limitar la aplicabilidad de esa regla a ciertos tipos de conjuntos de solicitudes controvertidas, ni de permitir múltiples aplazamientos para ciertos tipos de conjunto de solicitudes controvertidas.
      
      Los Solicitantes también sugieren en su Impugnación que, aunque han tratado de resolver el conjunto de solicitudes controvertidas de .MERCK de buena fe durante más de cinco meses (ahora más de ocho meses) desde que la subasta para el conjunto de solicitudes controvertidas se programó por primera vez el 2 de mayo de 2019, "el panorama es mucho más complejo", lo que presumiblemente sugiere que cinco meses no es tiempo suficiente.²² Sin embargo, cabe señalar que los Solicitantes han tenido mucho más que cinco meses para resolver sus disputas. Los Solicitantes han estado involucrados en disputas entre ellos durante décadas. Los Solicitantes tenían conocimiento de que sus solicitudes estaban destinadas a una subasta si no llegaban a una resolución privada desde que presentaron en 2012 de las solicitudes concurrentes de .MERCK; o bien, como mínimo, desde marzo de 2013 cuando Merck KGaA presentó Objeciones por derechos legales contra la solicitud de Merck Registry Holdings, Inc. relacionada específicamente con el uso del nombre "Merck".²³ Por lo tanto, este argumento de los Solicitantes no justifica la reconsideración.
      
      El BAMC concluyó y, por los motivos expuestos anteriormente y los que se establecen en la Recomendación del BAMC, la Junta Directiva está de acuerdo en que la denegación de la Segunda solicitud, y la regla de la ICANN contra segundos aplazamientos de conjuntos de solicitudes controvertidas de forma más amplia, es coherente con la política de la ICANN que favorece la resolución voluntaria de las controversias por cadenas de caracteres y aplica la subasta como un método de desempate únicamente. Además, cabe señalar que la regla contra los segundos aplazamientos no impide los acuerdos, sino que simplemente impide que las partes prolonguen indefinidamente las disputas sobre gTLD mediante el establecimiento de una fecha límite para la subasta. Este uso del proceso de subasta para proporcionar un tope en caso de que fracasen los esfuerzos de llegar a un acuerdo después de un tiempo razonable es coherente tanto con la política de la ICANN a favor de los acuerdos como con su designación de las subastas como método de último recurso para resolver la controversia por cadena de caracteres.
    3. El personal de la ICANN no infringió el compromiso de la ICANN de aplicar las políticas de forma neutral y objetiva.
      
      Los Solicitantes afirman que la negativa del Personal de la ICANN de la Segunda solicitud infringió el Compromiso de la ICANN de tomar "decisiones mediante la aplicación de políticas documentadas de manera neutral y objetiva con integridad y equidad". El BAMC concluyó, y la Junta Directiva está de acuerdo, que ni el Compromiso de la ICANN de aplicar las políticas de forma neutral ni ningún otro compromiso impiden el uso de la regla de la ICANN contra los segundos aplazamientos o requiere el uso de la discreción caso por caso en todas las instancias.
      
      En su Impugnación, los Solicitantes sugieren que, "dada la singularidad de las circunstancias en este caso", el Personal de la ICANN debía aplicar "flexibilidad y discreción" al considerar la Segunda solicitud, incluso si la organización de la ICANN prohibía de otro modo los segundos aplazamientos.²⁴ Las "circunstancias[] . . . únicas" aquí presentes, según los Solicitantes, son que los dos Solicitantes están "completamente alineados" en cuanto a que "están completamente alineados para aplazar la subasta"²⁵ Pero esas circunstancias no son únicas; el acuerdo entre los solicitantes es un requisito previo para solicitar cualquier aplazamiento de una subasta.²⁶ La Junta Directiva concluye que este argumento no justifica la reconsideración.
      
      Los Solicitantes no están de acuerdo con la conclusión del BAMC que señala que la aplicación de la regla de un solo aplazamiento "trata por igual a todas las solicitudes de un segundo aplazamiento, al disponer que todas esas solicitudes serán denegadas".²⁷ Los Solicitantes sugieren que la denegación de la Segunda solicitud por parte del Personal de la ICANN tiene el efecto de "discriminación contra [los Solicitantes]".²⁸ Como señalan los Solicitantes, el Compromiso de la ICANN de tomar "decisiones mediante la aplicación de políticas documentadas de manera neutral y objetiva con integridad y equidad"²⁹ "tiene como objetivo específico evitar la discriminación y no 'individualizar a ninguna parte'".³⁰ Sin embargo, los Solicitantes no han demostrado que el Personal de la ICANN haya individualizado a alguna parte en particular para un tratamiento desigual, porque no han identificado a ninguna parte que el Personal de la ICANN haya tratado de manera diferente ni tampoco han identificado ninguna instancia en la cual la ICANN haya sugerido que su política era otra que la de permitir un solo aplazamiento de la subasta mutuamente solicitado. La Junta Directiva está de acuerdo con la conclusión del BAMC que señala que la regla del aplazamiento único permite, de hecho, al Personal de la ICANN tratar por igual a todas las solicitudes de segundo aplazamiento. Por consiguiente, este argumento no justifica la reconsideración.
    4. El desacuerdo de los Solicitantes con la regla contra los segundos aplazamientos de las subastas no constituye un fundamento para la reconsideración.
      
      Los Solicitantes esencialmente están en desacuerdo con la regla de la organización de la ICANN que deniega los segundos aplazamientos en todos los casos.³¹ El BAMC concluyó que ninguno de los argumentos de los Solicitantes demostró que la regla contradijera la misión, los compromisos, los valores fundamentales y/o las políticas establecidas de la ICANN, ni que proporcionara una base para la reconsideración de la denegación de la Segunda solicitud.³²
      
      En cuanto a la Impugnación, los Solicitantes aclaran que no están impugnando la regla contra los segundos aplazamientos en sí, sino que están impugnando "la motivación del Personal de la ICANN para denegar el segundo aplazamiento de la subasta".³³ Por los motivos expuestos en la Recomendación del BAMC, la Junta Directiva concluye que la motivación del Personal de la ICANN para denegar la Segunda solicitud fue cumplir la regla de un único aplazamiento de la organización de la ICANN. La Junta Directiva concluye que los argumentos de los Solicitantes sobre la motivación del Personal de la ICANN no justifican la reconsideración.
    5. Actualización de los Solicitantes en relación con los debates sobre el acuerdo.
      
      En la Impugnación, los Solicitantes proporcionan una actualización sobre el estado del litigio en curso que afirma que está relacionado con sus negociaciones sobre .MERCK. Los Solicitantes afirman inicialmente que están "muy cerca de la resolución" de sus disputas, pero que sus nuevas fechas proyectadas para la conclusión de los litigios pendientes en Australia, China, India, Suiza, Estados Unidos y Reino Unido son aproximadamente junio de 2020; y que "una vez que tengamos las decisiones y audiencias mencionadas, estaremos en mejores condiciones de procurar la finalización de un acuerdo". Los Solicitantes solicitan actualmente hasta fines de agosto de 2020 para intentar resolver la controversia por cadena de caracteres.³⁴
      
      La Junta Directiva considera que instruir a la organización de la ICANN para que obtenga otra actualización en un futuro próximo es poco probable que produzca información nueva o diferente. No obstante, la Junta Directiva reconoce el ofrecimiento de los Solicitantes de "proporcionar a la Junta Directiva una actualización más detallada de las sentencias judiciales que se prevén en enero de 2020 y de los avances que han logrado para llegar a un acuerdo".³⁵ Por consiguiente, para asegurarse, la Junta Directiva ha instruido al Presidente y Director Ejecutivo, o a quien este designe, para que procure una actualización de los Solicitantes sobre: (i) si los Solicitantes han recibido alguna de las sentencias judiciales que los Solicitantes prevén para enero de 2020; y ii) qué avances, de haberlos, han logrado los Solicitantes para llegar a un acuerdo. Si los Solicitantes declaran conjuntamente que han logrado avances desde la presentación de la Solicitud 19-4 y la organización de la ICANN considera que los Solicitantes están muy cerca de lograr una resolución privada, la Junta Directiva solicitará a la organización de la ICANN que considere la posibilidad de proporcionar a los Solicitantes alguna forma de medida discrecional que les permita disponer de un período de tiempo limitado para finalizar un acuerdo. Si los Solicitantes no proporcionan una actualización adicional con respecto a los avances de su resolución y/o si la organización de la ICANN no considera que los Solicitantes estén muy cerca de una resolución privada, la Junta Directiva ordena al Presidente y Director Ejecutivo, o a quien este designe, a continuar procesando las solicitudes de .MERCK, incluida la programación de una subasta si la organización de la ICANN lo considera apropiado.
      
      Esta acción está dentro de la misión de la ICANN y es en pos del interés público ya que es importante garantizar que, al llevar a cabo su misión, la ICANN es responsable ante la comunidad de operar dentro de las actas constitutivas, los Estatutos y o procedimientos establecidos. Esta responsabilidad incluye contar con un proceso implementado mediante el cual cualquier persona o entidad significativamente afectada por una acción del personal o de la Junta Directiva de la ICANN pueda solicitar la reconsideración de dicha acción o inacción por parte de la Junta Directiva. Esta acción no debería tener un impacto financiero 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.

¹ https://www.icann.org/en/system/files/files/idn-vip-integrated-issues-final-clean-20feb12-en.pdf

² https://www.icann.org/en/system/files/files/draft-lgr-procedure-20mar13-en.pdf

³ https://www.icann.org/resources/pages/idn-variant-tld-implementation-2018-07-26-en

⁴ Los Guías de la implementación del CCT-RT son antiguos miembros del CCT-RT que se ofrecieron voluntariamente para proporcionar aclaraciones, según sea necesario, sobre la intención, el fundamento, los hechos que llevaron a conclusiones, el cronograma y las medidas de implementación de las recomendaciones. Consulte https://community.icann.org/display/CCT/Implementation+Shepherds para obtener más información.

⁵ Solicitud 19-4, § 8, en págs. 7-8.

⁶ Ver id.

⁷ Recomendación del BAMC, páginas 9-10.

⁸ Impugnación, páginas 3-4.

⁹ Solicitud 19-4, § 8, página 7.

¹⁰ Recomendación del BAMC, páginas 4 n.28, 9.

¹¹ Impugnación, página 4. Los Solicitantes también afirman que la declaración del BAMC, en su Recomendación, que señala que cada uno de los Solicitantes "tiene derechos de marcas comerciales que implican la palabra 'Merck', que han sido y siguen siendo objeto de litigio en múltiples jurisdicciones durante muchas décadas", indica que el Personal de la ICANN no consideró el historial de los Solicitantes cuando evaluó la Segunda solicitud, porque "todos los casos judiciales actuales" se iniciaron después de que los Solicitantes presentaran la solicitud del gTLD .MERCK en 2012. Impugnación, página 3. Si las contiendas judiciales de los Solicitantes comenzaron hace siete años o hace muchas décadas no es importante, el personal del BAMC y de la ICANN tenía pleno conocimiento del historial de disputas de los Solicitantes. Lo que resulta más importante es que la Junta Directiva está de acuerdo con el BAMC en cuanto a que el historial de los Solicitantes (por mucho que se extienda) no era significativo para la Segunda solicitud.

¹² Recomendación del BAMC, páginas 9-10.

¹³ Id.

¹⁴ Solicitud 19-4, § 8, en págs. 8-11.

¹⁵ Véase Recomendación del BAMC, páginas 11-12.

¹⁶ Impugnación, página 4, que cita la Recomendación del BAMC, página 9.

¹⁷ Id., en pág. 5.

¹⁸ Formulario de solicitud de aplazamiento, https://newgtlds.icann.org/en/applicants/auctions/date-advancement-postponement-form-09nov17-en.pdf (énfasis en el original).

¹⁹ Recomendación del BAMC en 10 n.53, que cita las Reglas para las subastas de los nuevos gTLD (3 de noviembre de 2014), ¶ 10, https://newgtlds.icann.org/en/applicants/auctions/rules-03nov14-en.pdf

²⁰ Formulario de solicitud de aplazamiento.

²¹ La Junta Directiva reconoce que las Reglas para las subastas establecen que los solicitantes pueden presentar una solicitud de aplazamiento a través del Portal del Cliente de la ICANN sin utilizar el Formulario de Solicitud de Aplazamiento en determinadas circunstancias. Reglas para las subastas, ¶ 10. Sin embargo, el debate sobre el aplazamiento en las Reglas para las subastas no indica que la ICANN pueda conceder múltiples aplazamientos para el mismo conjunto de solicitudes controvertidas. Véase id. La Junta Directiva concluye que las Reglas para las subastas no reflejan una norma que favorezca ni permita múltiples aplazamientos de una subasta de conjuntos de solicitudes controvertidas.

²² Impugnación, página 10.

²³ Objeción por derechos legales de decisiones de expertos en marzo de 2013, https://www.wipo.int/export/sites/www/amc/en/domains/lro/docs/lro2013-0009.pdf; https://www.wipo.int/export/sites/www/amc/en/domains/lro/docs/lro2013-0010.pdf; https://www.wipo.int/export/sites/www/amc/en/domains/lro/docs/lro2013-0011.pdf. Y los Solicitantes fueron alertados de nuevo sobre la eventual necesidad de resolver el conjunto de solicitudes controvertidas ya sea a través de una resolución privada o mediante una subasta cuando Merck KGaA presentó la Solicitud de reconsideración 16-12 en agosto de 2016. Recomendación del BAMC, páginas 11-12.

²⁴ Impugnación, páginas 6-7.

²⁵ Id.

²⁶ Reglas para las subastas, ¶ 10; véase también Formulario de solicitud de aplazamiento.

²⁷ Impugnación, página 7, que cita la Recomendación del BAMC, página 14.

²⁸ Id.

²⁹ Estatutos de la ICANN, Art. 1, § 1.2(a).

³⁰ Impugnación, página 7.

³¹ Solicitud 19-4, § 8, en págs. 8, 10, 13, 14.

³² Recomendación del BAMC, página 15.

³³ Impugnación, página 8.

³⁴ Impugnación, página 10.

³⁵ Id.

ICANN

Get Started

News and Media

Policy

Public Comment

Resources

Community

Quicklinks

Resoluciones aprobadas por la Junta Directiva | Sesión abierta del Taller de la Junta Directiva, Los Ángeles | Reunión ordinaria de la Junta Directiva de la ICANN 26 de enero de 2020

Orden del día convenido:

Aprobación de las actas de la reunión

Aplazamiento de la imposición del cumplimiento del Formulario de autorización del Registrador receptor

Fundamento de la resolución 2020.01.26.02

Recomendaciones para la utilización técnica del Conjunto de Reglas para la Generación de Etiquetas para la Zona Raíz

Fundamento de la resolución 2020.01.26.03

Adopción del Plan Operativo y Presupuesto de la IANA para el Año Fiscal 2021

Fundamento de la resolución 2020.01.26.04

Revisión de Competencia, Confianza y Elección de los Consumidores (CCT): Plan de implementación sobre las seis recomendaciones aceptadas

Fundamento de la resolución 2020.01.26.05

Gerente de sucursal y representante legal de la oficina de Bruselas

Fundamento de las resoluciones 2020.01.26.06 – 2020.01.26.08

Orden del día principal:

Asesoramiento del GAC: Comunicado de Montreal (noviembre de 2019)

Fundamento de la resolución 2020.01.26.09

Delegación del dominio البحرين. ("albahrain") que representa Baréin en código de escritura arábigo a la Autoridad Regulatoria de Telecomunicaciones (TRA)

Fundamento de la resolución 2020.01.26.10

Delegación del dominio .ລາວ ("Lao") que representa la República Democrática Popular Lao en código de escritura lao al Centro Nacional de Internet de Laos (LANIC)

Fundamento de la resolución 2020.01.26.11

Consideración de la recomendación del BGC sobre la Solicitud de Reconsideración 19-4

Fundamento de las resoluciones 2020.01.26.12 – 2020.01.26.14