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

  1. Orden del día convenido:
    1. Aprobación de las actas de la reunión
    2. Aceptación del Informe Final de Implementación del Grupo de Trabajo para la segunda Revisión de la GNSO (GNSO2)
    3. Consideración del Plan de Implementación detallado del Comité Asesor At-Large
    4. Plan Operativo y Presupuesto de la IANA para el Año Fiscal 2020
    5. Contratación de la sede para la reunión de la ICANN de octubre de 2021
    6. Renovación del contrato y desembolso para la iniciativa de ERP (Oracle Cloud)
    7. Reafirmación de la Especificación Temporaria para los Datos de Registración de los gTLD
  2. Orden del día principal:
    1. Delegación del dominio de alto nivel con código de país موريتانيا. que representa a Mauritania en código de escritura arábigo a la Université de Nouakchott Al Aasriya
    2. Delegación del dominio de alto nivel de código de país .SS (Sudán del Sur) a la Autoridad Nacional de Comunicaciones (NCA)
    3. Asesoramiento del GAC: Comunicado del GAC pronunciado en Barcelona (octubre de 2018)
    4. Adopción de la política de consenso de la GNSO en relación con ciertos nombres de la Cruz Roja y Media Luna Roja en el segundo nivel del Sistema de Nombres de Dominio
    5. Cambios de líderes y miembros del Comité de la Junta Directiva
    6. Considerar la Solicitud de Reconsideración 16-11: Travel Reservations SRL, Famous Four Media Limited (y su subsidiaria solicitante, dot Hotel Limited), Fegistry LLC, Minds + Machines Group Limited, Spring McCook, LLC, y Radix FZC (y su subsidiaria solicitante, dot Hotel Inc.) (.HOTEL)
    7. Considerar la Solicitud de Reconsideración 18-9: DotKids Foundation (.KIDS)
    8. Considerar la Solicitud de Reconsideración 16-12: Merck KGaA (.MERCK)
    9. Otros temas a tratar

 

  1. Orden del día convenido:

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

      Resuélvase (2019.01.27.01): La Junta Directiva aprueba las actas de las reuniones ordinaria y organizacional del 25 de octubre de la Junta Directiva de la ICANN, y la reunión extraordinaria del 6 de noviembre de la Junta Directiva de la ICANN.

    2. Aceptación del Informe Final de Implementación del Grupo de Trabajo para la segunda Revisión de la GNSO (GNSO2)

      Visto y considerando: Que, como parte de la segunda revisión de la Organización de Apoyo para Nombres Genéricos (GNSO), el 3 de febrero de 2017, la Junta aceptó el Plan de Implementación de la Revisión de la GNSO y ordenó que el Consejo de la GNSO suministrara a la Junta informes periódicos sobre los esfuerzos de implementación.

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

      Visto y considerando: Que el OEC supervisó el progreso de los esfuerzos de implementación a través de informes semestrales sobre la implementación y recomienda que la Junta acepte el Informe Final de Implementación de la segunda Revisión de la GNSO que emitió el Grupo de Trabajo para la Revisión de la GNSO y que aprobó el Consejo de la GNSO el 16 de agosto de 2018.

      Resuélvase (2019.01.27.02): La Junta reconoce el arduo trabajo del Grupo de Trabajo para la Revisión de la GNSO y le agradece haber elaborado el informe de implementación de recomendaciones para mejorar la eficacia, transparencia y responsabilidad de la GNSO, en concordancia con el plazo propuesto tal como se estipuló en el Plan de Implementación de la Revisión de la GNSO adoptado.

      Resuélvase (2019.01.27.03): La Junta acepta el Informe Final de Implementación de Revisión GNSO2 de la segunda Revisión de la GNSO que emitió el Grupo de Trabajo para la Revisión de la GNSO, el cual marca la finalización de esta importante revisión. La Junta alienta a la GNSO a seguir supervisando el impacto de la implementación de las recomendaciones de la segunda Revisión de la GNSO como parte de su proceso continuo de mejora.

      Fundamentos de las resoluciones 2019.01.27.02 – 2019.01.27.03

      ¿Por qué la Junta Directiva aborda el tema?

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

      Esta acción completa la segunda revisión de la GNSO y se basa en el Informe Final de Implementación tal como lo adoptó el Consejo de la GNSO, el informe final del examinador independiente, Westlake Governance, así como en la evaluación de las recomendaciones por parte del Grupo de Trabajo para la Revisión de la GNSO tal como fueron adoptadas por el Consejo de la GNSO. Después de la evaluación de todos los documentos y comentarios de la comunidad pertinentes por parte del OEC, la Junta ahora se encuentra en la posición de considerar y aceptar el Informe Final de Implementación.

      La Junta Directiva, con la recomendación de su Comité de Efectividad Organizacional (OEC), consideró todos los documentos relevantes, incluido el informe final, la evaluación de factibilidad del Grupo de Trabajo para la Revisión de la GNSO y priorización de recomendaciones por parte del examinador independiente ("Evaluación de factibilidad"), y aceptó el informe final que emitió el examinador independiente el 25 de junio de 2016. La Junta adoptó la Evaluación de factibilidad, salvo las recomendaciones 23 y 32. Además, la Junta ordenó al Consejo de la GNSO que: elabore un plan de implementación para las recomendaciones adoptadas con un plazo realista que tomara en cuenta la carga de trabajo continuamente alta de la comunidad y la consideración de la priorización propuesta por el Grupo de Trabajo; publique el plan en un plazo que no supere los seis (6) meses con posterioridad a la adopción de la Evaluación de factibilidad por parte de la Junta; garantice que el plan de implementación incluya definiciones de los resultados deseados y un modo de medir el estado actual así como el progreso hacia el resultado deseado; e informe a la Junta de manera periódica sobre su progreso en la implementación.

      El 3 de febrero de 2017, la Junta aceptó el Plan de Implementación suministrado por el WG y aprobado por el Consejo de la GNSO el 15 de diciembre de 2016, y ordenó al WG que suministrara actualizaciones semestrales al OEC hasta el momento en que los esfuerzos de implementación hayan concluido.

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

      La propuesta que se está considerando es que la Junta acepte el Informe Final de Implementación del WG, adoptado por el Consejo de la GNSO y considerado por el OEC.

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

      La Junta, a través del OEC, consultó al Grupo de Trabajo para la Revisión de la GNSO, que estaba a cargo de la implementación, y recomendó mejores prácticas para realizar revisiones eficaces de manera oportuna y supervisó el progreso de la revisión así como el progreso de la implementación de las recomendaciones sobre la revisión.

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

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

      ¿Qué materiales significativos analizó la Junta Directiva?

      La Junta revisó las secciones relevantes de los Estatutos, la documentación de procesos de la revisión organizacional, el Plan de Implementación de las Recomendaciones sobre la Revisión de la GNSO y el Informe Final de Implementación del Grupo de Trabajo para la Revisión de la GNSO.

      ¿Qué factores consideró importantes la Junta Directiva?

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

      • Formación de un grupo dedicado que supervise la implementación de las recomendaciones aceptadas por la Junta
      • Un plan de implementación que contenga un plazo realista para la implementación, definición de los resultados deseados y un modo de medir el estado actual así como el progreso hacia el resultado deseado
      • Informes oportunos y detallados sobre el progreso de la implementación

      ¿Existen impactos positivos o negativos para la comunidad?

      Se prevé que esta acción de la Junta tendrá un impacto positivo sobre la comunidad al reconocer y destacar una finalización eficaz de la implementación de las recomendaciones de la revisión de la GNSO.

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

      Se prevé que esta acción de la Junta no tendrá ningún impacto fiscal ya que los esfuerzos de implementación concluyeron satisfactoriamente. Se prevé que las ramificaciones en la organización de la ICANN, la comunidad y el público serán positivas, ya que esta acción de la Junta significa un importante hito para las revisiones organizacionales y la autonomía 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 está en consonancia con el compromiso de la ICANN de conformidad con la sección 4.1 de los Estatutos de seguir revisando que las entidades dentro de la ICANN tengan un propósito continuo y de mejorar el desempeño de sus organizaciones de apoyo y comités asesores. Esta acción será en pos del interés público al cumplir con el compromiso de la ICANN hacia una revisión continua de sus componentes para confirmar que donde las personas participen con la comunidad de la ICANN respalden los propósitos y las expectativas de dicha participación.

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

      No se requiere ningún comentario público.

    3. Consideración del Plan de Implementación detallado del Comité Asesor At-Large

      Visto y considerando: Que el Artículo 4, sección 4.4 de los Estatutos de la ICANN requiere que la Junta Directiva de la ICANN "de lugar a una revisión periódica del desempeño y el funcionamiento de cada Organización de Apoyo, de cada Consejo de Organización de Apoyo de cada Comité Asesor (excepto el Comité Asesor Gubernamental) y del Comité de Nominaciones, a cargo de una o varias entidades independientes respecto de la organización bajo revisión. El objetivo de la revisión, que se efectuará conforme a los criterios y los estándares indicados por la Junta Directiva, será determinar (i) si el objetivo de la organización sigue teniendo vigencia en la estructura de la ICANN, y (ii) de ser así, si debe efectuarse algún cambio en la estructura o en las operaciones para mejorar su eficacia”.

      Visto y considerando: Que el examinador independiente de la Revisión de At-Large elaboró un Informe Final en febrero de 2017. La Junta recibió dicho informe en junio de 2018 y, al mismo tiempo, aceptó el Plan de Implementación y Evaluación de Factibilidad de las Recomendaciones de la Revisión de At-Large y la Propuesta de Aspectos Generales de la Revisión de At-Large tal como fueran aprobados por el ALAC.

      Visto y considerando: Que, en respuesta a dicha resolución de junio de 2018, se creó el Grupo de Trabajo para la Implementación de la Revisión de At-Large. Dicho Grupo de Trabajo elaboró y aprobó el Plan de Implementación de la Revisión de At-Large (el "Plan de Implementación") el 19 de noviembre de 2018, el cual fue respaldado por el aval del ALAC el 27 de noviembre de 2018.

      Resuélvase (2019.01.27.04): La Junta reconoce el trabajo del Grupo de Trabajo para la Implementación de la Revisión de At-Large y agradece a los miembros de ese Grupo de Trabajo por sus esfuerzos.

      Resuélvase (2019.01.27.05): La Junta Directiva acepta el Plan de Implementación de la Revisión de At-Large, incluido el enfoque en etapas contenido en dicho plan. La Junta admite que es posible que se requiera más información con respecto a los detalles de la implementación para la implementación de las actividades de prioridades 2 y 3.

      Resuélvase (2019.01.27.06): La Junta instruye al Grupo de Trabajo para la Implementación de la Revisión de At-Large que proporcione actualizaciones al OEC cada seis meses. Dichas actualizaciones semestrales deberán identificar los logros medidos en comparación con el plan de implementación existente, así como detalles sobre futuros planes de implementación. Es durante estas actualizaciones que el Grupo de Trabajo para la Implementación de la Revisión de At-Large deberá brindar más detalles sobre el avance de la implementación y su mensurabilidad. El OEC puede solicitar informes provisionales si lo considera necesario.

      Resuélvase (2019.01.27.07): Toda posible implicancia presupuestaria de la implementación de la revisión de At-Large se deberá considerar como parte de los procesos presupuestarios anuales aplicables.

      Fundamentos de las resoluciones 2019.01.27.04 – 2019.01.27.07

      Con el fin de garantizar que el modelo de múltiples partes interesadas de la ICANN siga siendo transparente y responsable, y para optimizar su desempeño, la ICANN organiza revisiones independientes de sus organizaciones de apoyo y comités asesores del modo estipulado en el Artículo 4, sección 4.4 de los Estatutos de la ICANN. La segunda Revisión de At-Large se inició en el año 2016 y el examinador independiente presentó su Informe Final en mayo de 2017.

      Las recomendaciones para la implementación de la Revisión de At-Large según están contenidas en la Propuesta de Aspectos Generales de la Revisión de At-Large tienen el potencial de avanzar con los objetivos de transparencia y responsabilidad de la ICANN y han sido cuidadosamente consideradas por el Comité de Efectividad Organizacional de la Junta Directiva así como por toda la Junta Directiva.

      La resolución de la Junta Directiva tendrá un impacto positivo en la ICANN y, en especial, en la comunidad At-Large y el ALAC, dado que refuerza el compromiso de la ICANN, y de la comunidad At-Large y del ALAC de mantener y mejorar su responsabilidad, transparencia y eficacia organizacional a través del proceso de implementación.

      Debido a la cantidad de recomendaciones que necesitan ser implementadas, la Junta avala el enfoque por prioridades establecido en el Plan de Implementación (Anexo A). Esto dará tiempo a la comunidad para perfeccionar los detalles conforme al avance del proceso de implementación – especialmente durante las actividades de prioridad 2 y 3 estipuladas en dicho Plan de Implementación.

      Algunas recomendaciones – especialmente aquellas previstas para ser implementadas en las actividades de prioridad 2 y 3 – pueden beneficiarse de más detalles respecto a su implementación exacta. Debido a la dificultad de predecir estas cuestiones con meses de antelación, la Junta está favor de la idea de que el Grupo de Trabajo para la Implementación de la Revisión de At-Large brinde actualizaciones semestrales al OEC. Es durante estas actualizaciones que el ALAC puede proporcionar más detalles de implementación con respecto a esas recomendaciones que se programarán para el próximo periodo de seis meses, luego de la respectiva actualización al OEC. En ese momento, el ALAC estaría en una mejor posición para señalar variaciones significativas con respecto al plan de implementación original y a los plazos. El Plan de Implementación para la Revisión de At-Large estipula la priorización, la distribución de recursos esperados en cuanto al tiempo del personal, los recursos web y wiki, las implicancias presupuestarias previstas tales como recursos adicionales de personal, y los pasos para la implementación. Si bien la mayoría de las actividades de implementación usarán recursos existentes de At-Large, a continuación se señalan todas las implicancias fiscales adicionales. El ALAC utilizará el proceso de comentario presupuestario anual normal para solicitar los recursos necesarios. Si no se proporcionan dichos recursos, el resultado probable sería una desaceleración significativa en la velocidad de la implementación de la revisión.

      ¿Por qué la Junta Directiva aborda el tema?

      Esta resolución lleva la segunda revisión de la comunidad At-Large a la etapa de implementación. Después de evaluar el Plan de Implementación y los aportes del Comité de Efectividad Organizacional de la Junta Directiva, la Junta Directiva ahora está en condiciones de considerar el Plan y de ordenar al ALAC que comience con el proceso de implementación tal como se estipula en el Plan. Este paso es una parte importante del proceso de controles y equilibrios de la revisión organizacional para garantizar que el espíritu de las recomendaciones aprobadas por la Junta Directiva se aborde a través de los planes de implementación, teniendo en cuenta las limitaciones presupuestarias y aquellas relativas a los plazos.

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

      La propuesta que la Junta está considerando es la recomendación del Comité de Efectividad Organizacional de la adopción del Plan de Implementación para la Revisión de At-Large, elaborado y adoptado por el Grupo de Trabajo para la Implementación de la Revisión de At-Large, avalado por el ALAC.

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

      Inmediatamente después de que la Junta Directiva aprobó la resolución sobre la Revisión de At-Large, el liderazgo del Grupo de Trabajo para la Revisión de At-Large suministró actualizaciones sobre la revisión y los próximos pasos en las teleconferencias mensuales de cada una de las cinco RALO. La creación del Grupo de Trabajo para la Implementación de la Revisión de At-Large implicó la consideración cuidadosa de los miembros para garantizar diversidad y equilibrio geográfico dentro de cada RALO entre las 232 estructuras de At-Large y más de 100 miembros individuales. Durante el desarrollo del Plan de Implementación de la Revisión de At-Large, los miembros del Grupo de Trabajo para la Implementación de la Revisión de At-Large brindaron información actualizada al ALAC y a cada RALO de manera periódica sobre el avance que se estaba realizando. Asimismo, se llevaron a cabo varias discusiones sobre la implementación de la Revisión de At-Large durante las sesiones presenciales de ICANN 63. En cada paso, el Grupo de Trabajo para la Implementación de la Revisión de At-Large analizó los aportes, los cuales se incorporaron en el plan final.

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

      Durante el desarrollo del Plan de Implementación de la Revisión de At-Large, la comunidad At-Large planteó la inquietud respecto de si la tercera Cumbre At-Large (ATLAS III) tendría lugar tal como se programó tentativamente durante ICANN 66 en Montreal en octubre de 2019 e identificó como actividad de Prioridad 1 y que requiere consideración presupuestaria con antelación al ciclo de presupuesto organizacional más amplio. En septiembre de 2018, la Junta Directiva confirmó que la organización de la ICANN aún tenía autoridad para continuar con la planificación y la contratación.

      ¿Qué materiales significativos analizó la Junta Directiva?

      La Junta Directiva analizó el Plan de Implementación de la Revisión de At-Large adoptado por el Grupo de Trabajo para la Implementación de la Revisión de At-Large y avalado por el ALAC.

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

      El trabajo para mejorar la eficacia de la organización de At-Large – mediante la implementación de las cuestiones resultantes de la Revisión y la Propuesta de Aspectos Generales de la Revisión de At-Large, puede requerir recursos financieros adicionales que están sujetos a los procesos presupuestarios normales de la ICANN. Esta resolución no autoriza ningún financiamiento específico para dichos esfuerzos de implementación. La Junta entiende que parte del trabajo de Prioridad 1, como desarrollo de aptitudes y esfuerzos de comunicaciones, requerirá solicitudes presupuestarias adicionales para el año fiscal 2020. Asimismo, la Junta entiende que se estima que las actividades continuas y de Prioridad 2 requerirán la adición de un equivalente de empleado de tiempo completo y que hay otras necesidades de recursos anticipadas para elementos tales como comunicaciones y recopilación de datos.

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

      Se prevé que esta acción no tendrá ningún impacto en la seguridad, estabilidad y flexibilidad del DNS. No obstante, una vez implementadas las mejoras, las actividades futuras del ALAC y la comunidad At-Large, incluidos asesoramientos o aportes en los procesos de desarrollo de políticas, se volverán más transparentes y responsables, lo que, a su vez, puede contribuir indirectamente en la seguridad, estabilidad o flexibilidad del DNS.

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

      El informe preliminar del examinador independiente se publicará para comentario público. No se requieren comentarios públicos antes de que la Junta Directiva adopte alguna acción. La voz del ALAC se ha reflejado a lo largo del proceso de revisión – a través del Grupo de Trabajo para la Revisión de At-Large que elaboró la Propuesta de Aspectos Generales de la Implementación del ALAC; el Grupo de Trabajo para la Revisión de At-Large que desarrolló el plan de implementación; y el ALAC que avaló el plan de implementació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?

      Dado que At-Large representa los mejores intereses de los usuarios finales individuales de Internet dentro del enfoque de gobernanza de múltiples partes interesadas de la ICANN, la aprobación del Plan de Implementación de la Revisión de At-Large, el cual generará una comunidad At-Large fortalecida, tendrá un impacto positivo directo en la misión de la ICANN en su proceso de desarrollo de políticas ascendente. También se beneficia al interés público mediante esta acción que fomenta el desarrollo y respaldo continuos de una comunidad de múltiples partes interesadas diversas e informadas.

    4. Plan Operativo y Presupuesto de la IANA para el Año Fiscal 2020

      Visto y considerando: Que la versión preliminar del Plan Operativo y Presupuesto de la IANA para el Año Fiscal 2020 (OP&B) se publicó para comentario público conforme a los Estatutos de la ICANN el 28 de septiembre de 2018.

      Visto y considerando: Que los comentarios recibidos a través del proceso de comentario público fueron revisados, respondidos y entregados a los miembros del 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 a la versión final del OP&B de la IANA para el año fiscal 2020.

      Visto y considerando: Que la Junta de Identificadores Técnicos Públicos adoptó el OP&B final de la entidad PTI para el año fiscal 2020 el 20 de diciembre de 2018, el cual es un aporte requerido para que la Junta de la ICANN considere el OP&B de la IANA más amplio. En virtud de los Estatutos de la ICANN, una vez que la Junta de la ICANN adopta el OP&B de la IANA, este es publicado en el sitio web de la ICANN y la comunidad empoderada tiene la oportunidad de considerarlo para su rechazo.

      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 la IANA para el Año Fiscal 2020.

      Resuélvase (2019.01.27.08): La Junta Directiva adopta el Plan Operativo y Presupuesto de la IANA para el Año Fiscal 2020, incluido el presupuesto provisorio de la IANA para el año fiscal 2020.

      Fundamento de la resolución 2019.01.27.08

      De conformidad con la sección 22.4 de los Estatutos de la ICANN, la Junta Directiva deberá adoptar un presupuesto anual para la operación de las funciones de la IANA y publicarlo en el sitio web de la ICANN. El 28 de septiembre de 2018, las versiones preliminares del O&B de la entidad PTI para el año fiscal 2020 y el OP&B de la IANA para el año fiscal 2020 se publicaron para comentario público. La Junta Directiva de la entidad PTI aprobó el presupuesto de dicha entidad el 20 de diciembre de 2018 y dicho presupuesto se recibió como aporte al Presupuesto de la IANA para el año fiscal 2020.

      La versión preliminar publicada del Plan Operativo y Presupuesto de la entidad PTI para el año fiscal 2020 y la versión preliminar del Plan Operativo y Presupuesto de la IANA para el año fiscal 2020 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 2020. 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 2020 propuesta para su adopción.

      El OP&B de la IANA para el año fiscal 2020 tendrá un impacto positivo en la ICANN ya que proporciona un marco adecuado mediante el cual se llevarán a cabo los servicios de la IANA y que además brinda los fundamentos para que la organización sea responsable con transparencia.

      Esta decisión es de 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, de hecho, 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. La comunidad empoderada de la ICANN ahora tiene la oportunidad de considerar si ejercerá su facultad de rechazo sobre este OB&P.

    5. Contratación de la sede para la reunión de la ICANN de octubre de 2021

      Visto y considerando: Que la ICANN tiene la intención de realizar su última reunión pública de 2021 en la región de América del Norte.

      Visto y considerando: Que la organización de la ICANN realizó un análisis exhaustivo de las sedes disponibles en la región de América del Norte y considera que la de Seattle, Washington, es la más adecuada.

      Resuélvase (2019.01.27.09): La Junta Directiva autoriza al Presidente y Director Ejecutivo, o a quien este designe, a realizar y facilitar todas las contrataciones y todos los desembolsos que se requieran para la sede de la reunión pública de la ICANN de octubre de 2021 en Seattle, Washington, hasta una cantidad máxima que no supere [MONTO OMITIDO POR MOTIVOS DE NEGOCIACIÓN].

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

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

      Fundamentos de las resoluciones 2019.01.27.09 – 2019.01.27.11

      Como parte de su estrategia para reuniones públicas, la ICANN desea celebrar las reuniones en regiones geográficas distintas (de conformidad con lo establecido en los Estatutos de la ICANN) tres veces al año. La reunión ICANN72 está programada para llevarse a cabo del 23 al 28 de octubre de 2021. Después de la búsqueda y evaluación de las sedes disponibles, la organización consideró que Seattle, Washington, era una ubicación adecuada para la reunión pública de la ICANN.

      La organización realizó un análisis exhaustivo de todas las sedes disponibles y preparó un documento para identificar aquellas que cumplían con los criterios de selección para sedes de reuniones (véase http://meetings.icann.org/location-selection-criteria). En función de las propuestas y el análisis, la ICANN ha seleccionado a Seattle, Washington, como sede de la reunión ICANN72. La selección de esta ubicación de América del Norte se ajusta a las pautas de rotación geográfica establecidas por el Grupo de Trabajo sobre la Estrategia de Reuniones.

      La Junta Directiva revisó la información presentada por la organización para celebrar la reunión de la ICANN de octubre de 2021 en Seattle, Washington, y la determinación de que la propuesta cumplía con los factores importantes de los criterios de selección de sedes de reuniones, así como con los costos relacionados con las instalaciones seleccionadas. La ICANN realiza reuniones públicas en respaldo de su misión para asegurar el funcionamiento estable y seguro de los sistemas de identificadores únicos de Internet y actúa en pos del interés público al brindar acceso libre y abierto a cualquiera que desee participar, ya sea en persona o en forma remota, en procesos de desarrollo de políticas de múltiples partes interesadas abiertos, transparentes y ascendentes.

      Habrá un impacto financiero sobre la ICANN basado en la celebración de la reunión y el suministro de apoyo para viajes, según sea necesario, así también sobre la comunidad, al incurrir en los gastos de viaje para asistir a la reunión. Sin embargo, dicho impacto hubiese existido independientemente de la sede seleccionada para la reunión. Esta acción no tendrá impacto alguno sobre la seguridad o la estabilidad del DNS.

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

    6. Renovación del contrato y desembolso para la iniciativa de ERP (Oracle Cloud)

      Visto y considerando: Que la ICANN ha establecido la necesidad de renovar contratos para la solución de Planificación de Recursos Empresariales (ERP), Oracle Cloud.

      Visto y considerando: Que el Comité de Finanzas de la Junta Directiva ha revisado las implicancias financieras de la renovación del contrato con Oracle Cloud para la solución de ERP de la ICANN y ha considerado alternativas.

      Visto y considerando: Que la organización y el Comité de Finanzas de la Junta Directiva han recomendado que la Junta Directiva autorice al Presidente y Director Ejecutivo, o quien éste designe, a tomar todas las medidas necesarias para la ejecución de los contratos con Oracle Cloud para la solución de ERP de la ICANN y a realizar todos los desembolsos necesarios en virtud de dichos contratos.

      Resuélvase (2019.01.27.12): La Junta Directiva autoriza al Presidente y Director Ejecutivo, o quien éste designe, a tomar todas las medidas necesarias para la renovación de los contratos con Oracle Cloud para la solución de ERP de la ICANN y a realizar todos los desembolsos necesarios en virtud de dichos contratos.

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

      Fundamentos de las resoluciones 2019.01.27.12 – 2019.01.27.13

      La ICANN utiliza satisfactoriamente ERP de Oracle Cloud desde que la implementación estuvo disponible en diciembre de 2016. Durante los últimos años, la organización de la ICANN ha aumentado gradualmente los sistemas de ERP y el conocimiento de procesamiento transaccional, y está en condiciones de realizar mejoras incrementales en la eficiencia a fin de maximizar la inversión original. La solución Oracle Cloud ERP reemplazó a los entonces obsoletos sistemas legados de finanzas, recursos humanos y compras. Esta solución brindó a la organización de la ICANN una solución de ERP integrada bajo un único sistema de registro, que mejoró la capacidad de los sistemas, la presentación de informes global y la capacidad de análisis, lo cual mejoró la productividad y la eficiencia multidisciplinaria, además de mejorar los controles internos.

      Contrato actual

      El contrato actual de la ICANN con Oracle Cloud ERP tenía una vigencia de tres años. Este contrato venció en diciembre de 2018. Oracle Cloud ha otorgado a la ICANN una extensión del contrato de un mes. El costo anual es [OMITIDO – POR MOTIVOS DE NEGOCIACIÓN].

      Contrato nuevo

      Después de exhaustivos análisis, negociaciones y un ajuste en el número de licencias con el proveedor, la organización tiene dos opciones disponibles: (i) contrato de tres años a [OMITIDO – POR MOTIVOS DE NEGOCIACIÓN] anualmente con un costo total por los tres años de [OMITIDO – POR MOTIVOS DE NEGOCIACIÓN], (ii) contrato de cinco años a [OMITIDO – POR MOTIVOS DE NEGOCIACIÓN] anualmente con un costo total por los cinco años de [OMITIDO – POR MOTIVOS DE NEGOCIACIÓN].

      Después de haber analizado cuidadosamente las opciones presentadas por la organización, se considera que la opción del contrato por cinco años es una solución viable y rentable. Esta solución tiene un costo total más bajo, tiene precio fijo, lo que brinda protección contra aumentos durante cinco años, y tiene flexibilidad para que la organización realice otro análisis general de los sistemas de ERP en tres años (2021-2022) para determinar si la solución establecida es la mejor opción para la ICANN.

      La Junta Directiva analizó las recomendaciones de la organización y del Comité de Finanzas de la Junta Directiva en materia de contratación y autoridad de desembolso para la renovación del contrato de Oracle Cloud ERP.

      La toma de esta medida de la Junta Directiva se ajusta perfectamente a la misión de la ICANN y el interés público porque garantiza que los pagos de grandes sumas de dinero en una factura para una entidad sean revisados​y evaluados por la Junta Directiva si superan una cierta cantidad de autoridad delegada a través de la Política de Contratación y Desembolso de la ICANN. Esto garantiza que la Junta Directiva supervise grandes desembolsos y actúe como administradores apropiados de los fondos que la ICANN recibe del público.

      Habrá un impacto financiero en la ICANN para renovar el contrato de Oracle Cloud ERP. Este impacto está incluido actualmente en el Plan Operativo y Presupuesto para el año fiscal 2020 que está pendiente de aprobación por parte de la Junta Directiva. Esta medida no tendrá ningún impacto directo sobre la seguridad, estabilidad y flexibilidad del sistema de nombres de dominio.

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

    7. Reafirmación de la Especificación Temporaria para los Datos de Registración de los gTLD

      Visto y considerando: Que el 17 de mayo de 2018, la Junta Directiva adoptó la Especificación Temporaria para los Datos de Registración de gTLD (la “Especificación Temporaria”) con vigencia a partir del 25 de mayo de 2018 durante un período de 90 días. La Especificación Temporaria establece los requisitos temporarios para permitir que la ICANN y los registradores y operadores de registro de gTLD sigan cumpliendo con los requisitos contractuales de la ICANN y las políticas desarrolladas por la comunidad en vigencia respecto de los datos de registración de gTLD (incluido el WHOIS) en virtud del Reglamento General de Protección de Datos de la Unión Europea (GDPR).

      Visto y considerando: Que, el 21 de agosto de 2018, la Junta reafirmó la adopción de la Especificación Temporaria que estará en vigencia por un período adicional de 90 días que comenzará el 23 de agosto de 2018.

      Visto y considerando: Que, el 6 de noviembre de 2018, la Junta reafirmó la adopción de la Especificación Temporaria que estará en vigencia por un período adicional de 90 días a partir del 21 de noviembre de 2018.

      Visto y considerando: Que la Junta adoptó la Especificación Temporaria de conformidad con los procedimientos del Acuerdo de Registro y del Acuerdo de Acreditación de Registradores para adoptar políticas temporarias. Este procedimiento requiere que “[s]i el período por el cual se adopta la Política Temporaria supera los noventa (90) días, la Junta Directiva ratificará su adopción temporaria cada noventa (90) días por un período total que no exceda un (1) año, con el propósito de mantener dicha Política Temporaria en vigencia durante el tiempo necesario para que se convierta en una Política de Consenso”.

      Resuélvase (2019.01.27.14): La Junta Directiva reafirma la Especificación Temporaria para los Datos de Registración de gTLD de conformidad con los procedimientos contenidos en el Acuerdo de Registro y el Acuerdo de Acreditación de Registradores respecto del establecimiento de políticas temporarias. Al reafirmar esta Especificación Temporaria, la Junta Directiva ha determinado que:

      1. Las modificaciones de la Especificación Temporaria a los requisitos existentes respecto del procesamiento de datos personales en los datos de registración siguen estando justificadas y el establecimiento temporario inmediato de la Especificación Temporaria sigue siendo necesario para mantener la estabilidad y seguridad de los Servicios para Registradores, Servicios para Registros, o el DNS o la Internet.
      2. La Especificación Temporaria está lo más estrechamente adaptada posible a fin de lograr el objetivo de mantener la estabilidad o la seguridad de los Servicios para Registradores, Servicios para Registros, o el DNS o la Internet.
      3. La Especificación Temporaria estará en vigencia durante un período adicional de 90 días, a partir del 19 de febrero de 2019.

      Resuélvase (2019.01.27.14): La Junta reafirma la Declaración de Asesoramiento respecto de la Adopción de la Especificación Temporaria para los Datos de Registración de los gTLD, la cual brinda explicación detallada de sus motivos por los cuales adoptar la Especificación Temporaria y por qué la Junta considera que dicha Especificación Temporaria debería recibir el apoyo consensuado de las partes interesadas de Internet.

      Fundamentos de las resoluciones 2019.01.27.14 – 2019.01.27.15

      El Reglamento General sobre la Protección de Datos de la Unión Europea (GDPR) entró en vigencia el 25 de mayo de 2018. El GDPR es un conjunto de reglas adoptadas por el Parlamento Europeo, el Consejo Europeo y la Comisión Europea que imponen obligaciones nuevas a todas las compañías y organizaciones que recopilan y mantienen cualquier “dato personal” de residentes de la Unión Europea, según se define en la ley de protección de datos de la UE. El GDPR impacta sobre la forma en que los datos se recopilan, muestran y procesan entre los participantes en el ecosistema de nombres de dominio gTLD (incluidos registros y registradores) de conformidad con los contratos y políticas de la ICANN.

      El 17 de mayo de 2018, la Junta Directiva adoptó la Especificación Temporaria para los Datos de Registración de los gTLD ("Especificación Temporaria") para establecer los requisitos temporarios para permitir que la ICANN, y los operadores de registro y registradores de gTLD continúen cumpliendo con los requisitos contractuales de la ICANN y las políticas desarrolladas por la comunidad en vigencia respecto de los datos de registración de gTLD (incluido el WHOIS) en relación con el GDPR. La Especificación Temporaria, la cual entró en vigencia el 25 de mayo de 2018, fue adoptada mediante el procedimiento para políticas temporarias establecido en el Acuerdo de Registro y el Acuerdo de Acreditación de Registradores.

      El 21 de agosto de 2018, la Junta reafirmó la Especificación Temporaria por un período adicional de 90 días que comenzará el 23 de agosto de 2018. El 6 de noviembre de 2018, la Junta reafirmó la adopción de la Especificación Temporaria que estará en vigencia por un período subsiguiente de 90 días a partir del 21 de noviembre de 2018.

      Tal como lo requiere el procedimiento contenido en el Acuerdo de Acreditación de Registradores y los Acuerdos de Registro para adoptar la especificación o política temporaria, “[s]i el período por el cual se adopta la Política Temporaria supera los noventa (90) días, la Junta Directiva ratificará su adopción temporaria cada noventa (90) días por un período total que no exceda un (1) año, con el propósito de mantener dicha Política Temporaria en vigencia durante el tiempo necesario para que se convierta en una Política de Consenso”.

      En el día de la fecha, la Junta está tomando las medidas para reconfirmar la Especificación Temporaria durante un período adicional de 90 días ya que los requisitos temporarios siguen estando justificados a fin de mantener la estabilidad o seguridad de los servicios de registro, servicios para registradores o el DNS. Al adoptar la Especificación Temporaria, la Junta brindó una Declaración de Asesoramiento para brindar una explicación detallada de sus motivos para la adopción de la Especificación Temporaria y por qué la Junta considera que dicha Especificación Temporaria debería recibir apoyo consensuado de las partes interesadas de Internet. La Junta reafirma la Declaración de Asesoramiento, la cual se incorpora como referencia al fundamento de las resoluciones de la Junta.

      Tal como se requiere al adoptar una especificación o política temporaria, la Junta tomó medidas para implementar el proceso de desarrollo de políticas de consenso y consultó con el Consejo de la GNSO sobre los posibles pasos a seguir para considerar el desarrollo de una política de consenso en relación a las cuestiones contenidas en la Especificación Temporaria. El proceso de desarrollo de políticas de consenso debe concluirse en un período de un año. La Junta tiene en cuenta que el Consejo de la GNSO inició un Proceso Expeditivo de Desarrollo de Políticas sobre la Especificación Temporaria y el Grupo de Trabajo sigue con sus deliberaciones para desarrollar recomendaciones propuestas en materia de política. El 21 de noviembre de 2018, el Grupo de Trabajo publicó para comentario público el Informe Inicial del Proceso Expeditivo de Desarrollo de Políticas (EPDP) sobre la Especificación Temporaria para los Datos de Registración de los gTLD. El Grupo de Trabajo definió un cronograma para elaborar un informe final en febrero de 2019 y para entregar el informe a la Junta para su consideración antes del vencimiento del período de 1 año suministrado para la Especificación Temporaria. La Junta seguirá participando con el Consejo de la GNSO en esta cuestión y reconfirma su compromiso de brindar el apoyo necesario al trabajo del Proceso Expeditivo de Desarrollo de Políticas para cumplir con el plazo (véase la carta de Cherine Chalaby al Presidente del Consejo de la GNSO con fecha 7 de agosto de 2018: https://www.icann.org/en/system/files/correspondence/chalaby-to-forrest-et-al-07aug18-en.pdf).

      La acción de la Junta de reafirmar la Especificación Temporaria está en consonancia con la misión de la ICANN de “[...] asegurar el funcionamiento estable y seguro de los sistemas de identificadores únicos de Internet [...]”. Dado que uno de los roles principales de la ICANN es ser responsable de la administración de los niveles más importantes de los identificadores de Internet, posibilitar la capacidad de identificar a los titulares de dichos identificadores es una función central de la ICANN. La acción de la Junta hoy ayudará a beneficiar el interés público y fomentar el requisito contenido en los Estatutos de la ICANN de “evaluar la eficacia del servicio de directorio de gTLD vigente en su momento y si su implementación satisface las necesidades legítimas del cumplimiento de la ley mediante la promoción de la confianza de los consumidores y la protección de los datos de los registratarios”. [Sección 4.6(e)(ii) de los Estatutos]

      Asimismo, se prevé que esta acción tendrá un impacto inmediato en la seguridad, estabilidad o flexibilidad continuas del DNS, ya que ayudará a seguir manteniendo el WHOIS en la mayor medida posible mientras la comunidad trabaja para desarrollar una política de consenso. No se prevé que la reafirmación de la Especificación Temporaria tenga un impacto fiscal en la organización de la ICANN más allá de lo anteriormente identificado en el fundamento de las resoluciones 2018.05.17.01 – 2018.05.17.09 de la Junta. Si las necesidades de recursos son mayores que los montos actualmente presupuestados para realizar el trabajo sobre las cuestiones relativas al WHOIS y al GDPR, el Presidente y Director Ejecutivo presentará toda necesidad adicional de recursos ante el Comité de Finanzas de la Junta Directiva para su consideración, en consonancia con las prácticas de solicitud de fondos existentes.

      Esta es una función administrativa y organizacional de la Junta para la cual no se requiere comentario público; sin embargo, el enfoque de la ICANN respecto de abordar el cumplimiento de las políticas y los acuerdos de la ICANN concernientes a los datos de registración de gTLD en relación con el GDPR ha sido objeto de comentarios de la comunidad durante el último año (https://www.icann.org/dataprotectionprivacy).

  2. Orden del día principal:

    1. Delegación del dominio de alto nivel con código de país موريتانيا. que representa a Mauritania en código de escritura arábigo a la Université de Nouakchott Al Aasriya

      Resuélvase (2019.01.27.16): Como parte del ejercicio de sus responsabilidades conforme al Contrato de Funciones de Nombres de la IANA con la ICANN, la entidad PTI ha examinado y evaluado la solicitud de delegación del dominio de alto nivel con código de país موريتانيا. a la Université de Nouakchott Al Aasriya. La documentación demuestra que se siguieron los procedimientos adecuados durante la evaluación de la solicitud.

      Fundamento de la resolución 2019.01.27.16

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

      De acuerdo con el Contrato de Funciones de Nombres de la IANA, la PTI 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 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 el rol de administrador a la Université de Nouakchott Al Aasriya.

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

      Durante la evaluación de una solicitud de delegación, la PTI consulta 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 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.

    2. Delegación del dominio de alto nivel de código de país .SS (Sudán del Sur) a la Autoridad Nacional de Comunicaciones (NCA)

      Resuélvase (2019.01.27.17): Como parte del ejercicio de sus responsabilidades conforme al Contrato de Funciones de Nombres de la IANA con la ICANN, la entidad PTI ha examinado y evaluado la solicitud de delegación del dominio de alto nivel con código de país .SS (Sudán del Sur) a la Autoridad Nacional de Comunicaciones (NCA). La documentación demuestra que se siguieron los procedimientos adecuados durante la evaluación de la solicitud.

      Fundamento de la resolución 2019.01.27.17

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

      De acuerdo con el Contrato de Funciones de Nombres de la IANA, la PTI 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 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 .SS y asignar el rol de administrador a la Autoridad Nacional de Comunicaciones (NCA).

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

      Durante la evaluación de una solicitud de delegación, la PTI consulta 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 las partes considerablemente interesadas.

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

    3. Asesoramiento del GAC: Comunicado del GAC pronunciado en Barcelona (octubre de 2018)

      Visto y considerando: Que el Comité Asesor Gubernamental (GAC) se reunió durante la Reunión N.° 63 de la ICANN celebrada en Barcelona, España, y emitió asesoramiento a la Junta Directiva de la ICANN en un comunicado el 25 de octubre de 2018 ("Comunicado pronunciado en Barcelona").

      Visto y considerando: Que el Comunicado pronunciado en Barcelona fue el tema de un intercambio entre la Junta Directiva y el GAC el 28 de noviembre de 2018.

      Visto y considerando: Que, en una carta del 20 de diciembre de 2018, el GAC brindó más aclaraciones sobre el lenguaje contenido en el anexo al Comunicado pronunciado en Barcelona denominado Seguimiento de la declaración conjunta del ALAC y el GAC (Abu Dabi, 2 de noviembre de 2017).

      Visto y considerando: Que en una carta con fecha del 21 de diciembre de 2018, el Consejo de la GNSO brindó comentarios a la Junta Directiva respecto del asesoramiento contenido en el Comunicado pronunciado en Barcelona en relación a los dominios genéricos de alto nivel para informar a la Junta Directiva y la comunidad sobre las actividades en materia de políticas de gTLD que pueden relacionarse con el asesoramiento brindado por el GAC.

      Visto y considerando: Que la organización de la ICANN publicó un memorando y un documento informativo histórico que brinda aclaraciones sobre el desarrollo y la evolución del procedimiento de la organización de la ICANN para la liberación de etiquetas de dos caracteres en el segundo nivel y el marco estándar de medidas para evitar confusiones con los códigos de países correspondientes.

      Visto y considerando: Que la Junta Directiva elaboró una tabla de calificación para responder al asesoramiento del GAC contenido en el Comunicado pronunciado en Barcelona, teniendo en cuenta el diálogo entre la Junta y el GAC, la carta aclaratoria brindada por el Presidente del GAC, la información suministrada por el Consejo de la GNSO, y el memorando y documento informativo que publicó la organización de la ICANN.

      Visto y considerando: Que la Junta Directiva ha considerado el asesoramiento del GAC anteriormente aplazado respecto de códigos de país de dos caracteres en el segundo nivel del Comunicado pronunciado en Panamá y ha incluido una respuesta en la actual tabla de calificación "Asesoramiento del GAC – Comunicado pronunciado en Barcelona: acciones y actualizaciones (25 de enero de 2019)”.

      Resuélvase (2019.01.27.18): La Junta Directiva adopta la tabla de calificación titulada "Asesoramiento del GAC – Comunicado pronunciado en Barcelona: acciones y actualizaciones (25 de enero de 2019)” que fue elaborada en respuesta a los temas del asesoramiento del GAC contenido en los comunicados pronunciados en Barcelona y Panamá.

      Fundamento de la resolución 2019.01.27.18

      El Artículo 12, Sección 12.2(a)(ix) de los Estatutos de la ICANN permite al GAC "exponer temas a la Junta Directiva directamente, ya sea por medio de un comentario o asesoramiento previo, o a través de recomendaciones específicas de acción, recomendaciones sobre el desarrollo de políticas nuevas o sobre la revisión de las políticas existentes”. En su Comunicado pronunciado en Barcelona (25 de octubre de 2018), el GAC proporcionó asesoramiento a la Junta Directiva sobre: códigos de país de dos caracteres en el segundo nivel y protección de nombres y acrónimos de Organizaciones Intergubernamentales (OIG) en los gTLD. El GAC también brindó un seguimiento al asesoramiento anterior sobre el GDPR y el WHOIS, las solicitudes de .Amazon, la protección de las designaciones y los identificadores de la Cruz Roja y la Media Luna Roja, y un seguimiento a la declaración conjunta del ALAC y el GAC (Abu Dabi, 2 de noviembre de 2018). 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 temas contenidos en el Comunicado pronunciado en Barcelona, incluidos los temas relacionados con los códigos de país de dos caracteres en el segundo nivel así como las protecciones de las OIG. La Junta también está tomando medidas sobre los temas respecto de los códigos de país de dos caracteres en el segundo nivel del Comunicado pronunciado en Panamá, cuya consideración había sido anteriormente aplazada.

      La Junta seguirá aplazando la consideración de cinco temas del Comunicado pronunciado en San Juan, entre los que se incluyen: cuatro temas de asesoramiento relativos al GDPR y al WHOIS y un tema de asesoramiento relativo a los acrónimos reservados de las OIG, a la espera de más discusión con el GAC. La Junta considerará si se requiere acción adicional después de estas discusiones.

      Las acciones de la Junta Directiva se describen en la tabla de calificación con fecha del 25 de enero de 2019.

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

      La adopción del asesoramiento del GAC, tal como se proporciona en la tabla de puntaje, tendrá un impacto positivo en la comunidad porque ayudará a resolver el asesoramiento del GAC respecto de los gTLD y otras cuestiones. No se observan impactos fiscales previstos asociados con la adopción de esta Resolución. La aprobación de la resolución no ocasionará impacto alguno en las cuestiones de seguridad, estabilidad o flexibilidad relacionadas con el DNS. Esta decisión forma parte de las funciones administrativas y organizacionales que no requieren comentario público.

    4. Adopción de la política de consenso de la GNSO en relación con ciertos nombres de la Cruz Roja y Media Luna Roja en el segundo nivel del Sistema de Nombres de Dominio

      Visto y considerando: Que, en marzo de 2017, la Organización de Apoyo para Nombres Genéricos (“GNSO”) y el Comité Asesor Gubernamental (“GAC”) participaron de un diálogo facilitado y de buena fe con el fin de resolver las diferencias pendientes entre las recomendaciones de consenso sobre el Proceso de Desarrollo de Políticas (“PDP”) original de la GNSO y el asesoramiento del GAC en relación con ciertos nombres de la Cruz Roja y la Media Luna Roja.

      Visto y considerando: Que, en el transcurso de dicho diálogo facilitado, el GAC y la GNSO señalaron ciertas cuestiones específicas, a saber:

      1. Las consideraciones en materia de política pública relacionadas con la protección de identificadores asociados con el movimiento internacional de la Cruz Roja (“Movimiento”) en el sistema de nombres de dominio;
      2. El fundamento del GAC para solicitar protección permanente para los términos más estrechamente asociados con el Movimiento y sus componentes respectivos se basa en las protecciones de las designaciones “Cruz Roja”, “Media Luna Roja”, “Sol y León Rojos” y “Cristal Rojo” en virtud del derecho internacional de tratados y de diversas leyes nacionales;
      3. La lista de nombres de las Sociedades Nacionales de la Cruz Roja y la Media Luna Roja es una lista finita y limitada de nombres específicos de las Sociedades Nacionales reconocidos dentro del Movimiento (http://www.ifrc.org/Docs/ExcelExport/NS_Directory.pdf );
      4. No existen otros usos legítimos para estos términos; y
      5. El GAC había suministrado aclaraciones con posterioridad a la finalización del PDP de la GNSO, a través de su Comunicado pronunciado en Singapur en marzo de 2014, sobre el alcance finito de la lista específica de nombres del Movimiento para los cuales se solicitaban protecciones permanentes (https://gacweb.icann.org/download/attachments/28278854/Final%20Communique%20 %20Singapore%202014.pdf?version=1&modificationDate=1397225538000&api=v2).

      Visto y considerando: Que, con posterioridad a la discusión entre el GAC y la GNSO, la Junta de la ICANN había solicitado que el Consejo de la GNSO considerara iniciar el proceso de la GNSO para enmendar las recomendaciones anteriores en materia de política de la GNSO respecto de los nombres completos de las Sociedades Nacionales de la Cruz Roja y el Comité Internacional de la Cruz Roja y la Federación Internacional de las Sociedades de la Cruz Roja y la Media Luna Roja, y un conjunto definido y limitado de variaciones de estos nombres, en los seis idiomas oficiales de las Naciones Unidas (https://www.icann.org/resources/board-material/resolutions-2017-03-16-en#2.e.i).

      Visto y considerando: Que, en mayo de 2017, el Consejo de la GNSO resolvió reunir al Grupo de Trabajo para PDP original para considerar la solicitud de la Junta (https://gnso.icann.org/en/council/resolutions#20170503-071).

      Visto y considerando: Que, en agosto de 2018, el Grupo de Trabajo para PDP que volvió a convocarse presentó seis recomendaciones que recibieron pleno consenso del Grupo de Trabajo al Consejo de la GNSO (https://gnso.icann.org/en/issues/igo-ingo/red-cross-protection-policy-amend-process-final-06aug18-en.pdf), incluido un conjunto definido y limitado de variaciones de los nombres de la Cruz Roja y la Media Luna Roja para ser reservados en virtud de la política de consenso propuesta (https://gnso.icann.org/en/issues/igo-ingo/red-cross-identifiers-proposed-reservation-06aug18-en.pdf).

      Visto y considerando: Que, en septiembre de 2018, el Consejo de la GNSO votó unánimemente para aprobar todas las recomendaciones de consenso del PDP (https://gnso.icann.org/en/council/resolutions#20180927-3) y, en octubre de 2018, aprobó la presentación de un Informe de recomendaciones a la Junta de la ICANN (https://gnso.icann.org/en/council/resolutions#20181024-1).

      Visto y considerando: Que, tal como lo exigen los Estatutos de la ICANN, se abrió un período de comentario público en noviembre de 2018 para que el público tuviera una oportunidad razonable de brindar aportes sobre la política de consenso propuesta antes de la acción de la Junta así como para que el GAC brindase asesoramiento oportuno sobre cualquier inquietud en materia de política pública.

      Visto y considerando: Que la Junta ha considerado las recomendaciones de la GNSO y otros materiales relevantes en relación a esta cuestión.

      Resuélvase (2019.01.27.19): La Junta por el presente adopta las recomendaciones finales del Grupo de Trabajo para PDP de las organizaciones internacionales y gubernamentales (OIG) y organizaciones internacionales no gubernamentales (OING) que volvió a convocarse, según se aprobaron por votación unánime del Consejo de la GNSO el 27 de septiembre de 2018.

      Resuélvase (2019.01.27.20): La Junta Directiva ordena al Presidente y Director Ejecutivo, o a quien éste designe, elaborar y ejecutar un plan de implementación, incluidos costos y plazos, para las recomendaciones adoptadas en consonancia con el Anexo A de los Estatutos de la ICANN y las Pautas y Principios del Equipo para la Revisión de la Implementación avalados por la Junta Directiva el 28 de septiembre de 2015 (véase https://www.icann.org/resources/board-material/resolutions-2015-09-28-en - 2.f), y seguir con las comunicaciones con la comunidad sobre dicho trabajo.

      Fundamentos de las resoluciones 2019.01.27.19 – 2019.01.27.20

      ¿Por qué la Junta Directiva aborda el tema?

      La GNSO llevó a cabo un PDP, el cual finalizó en noviembre de 2013, que consideró y elaboró ciertas recomendaciones de políticas para la protección de ciertos identificadores asociados con el movimiento de la Cruz Roja y Media Luna Roja. Aquellas recomendaciones de la GNSO que estaban en consonancia con el asesoramiento del GAC sobre el tema; a saber, las relacionadas con los términos específicos “Cruz Roja”, “Media Luna Roja”, “Cristal Rojo” y “Sol y León Rojos” fueron adoptadas por la Junta en abril de 2014 (http://www.icann.org/en/groups/board/documents/resolutions-30apr14-en.htm#2.a). Con posterioridad al trabajo de implementación de la organización de la ICANN y voluntarios de la comunidad, estos cuatro términos específicos ahora son reservados para impedir su delegación en el alto nivel y en el segundo nivel del DNS, en los seis idiomas oficiales de las Naciones Unidas, en virtud de una política de consenso que entró en vigencia en enero de 2018.

      La Junta no aprobó las recomendaciones restantes en materia de política de la GNSO de 2013 que se relacionaban con otros identificadores de la Cruz Roja y la Media Luna Roja, por ejemplo, los nombres completos de todas las Sociedades Nacionales del movimiento de la Cruz Roja y aquellos del Movimiento Internacional de la Cruz Roja y la Media Luna Roja, el Comité Internacional de la Cruz Roja y la Federación Internacional de las Sociedades de la Cruz Roja y la Media Luna Roja. La Junta no aprobó estas recomendaciones de políticas en ese momento para permitir más discusiones entre la Junta, la GNSO, el GAC y la comunidad sobre las inconsistencias entre las recomendaciones de políticas de la GNSO y el asesoramiento del GAC. Durante los próximos meses, la Junta facilitó el diálogo entre los grupos sobre un posible camino a seguir. Después de la conclusión de un diálogo facilitado entre el GAC y la GNSO en marzo de 2017, el Consejo de la GNSO volvió a convocar al Grupo de Trabajo para PDP original para considerar posibles modificaciones de sus recomendaciones anteriores respecto de estos identificadores específicos.

      En septiembre de 2018, el Consejo de la GNSO aprobó unánimemente las recomendaciones de políticas modificadas presentadas en el informe final del Grupo de Trabajo para PDP. Con la aprobación unánime de las recomendaciones de políticas modificadas por parte del Consejo de la GNSO, la Junta ahora está realizando acciones para adoptar las recomendaciones de política de consenso revisadas de conformidad con el proceso documentado en virtud de los Estatutos de la ICANN.

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

      Las recomendaciones sobre PDP son que ciertos nombres específicos de la Cruz Roja y la Media Luna Roja así como una lista de variantes acordadas y permitidas de dichos nombres sean reservados para impedir su delegación en el segundo nivel del DNS, en los seis idiomas oficiales de las Naciones Unidas. Las recomendaciones sobre PDP incluyen un proceso documentado específico y criterios para corregir errores encontrados en la lista de nombres y variantes acordados, así como para agregar o eliminar entradas de la lista. La política adoptada complementará la política de consenso existente sobre la protección en el alto nivel y en el segundo nivel de los términos “Cruz Roja”, “Media Luna Roja”, “Cristal Rojo” y “Sol y León Rojos” en los seis idiomas oficiales de las Naciones Unidas.

      A los efectos de aportar claridad, las recomendaciones sobre el PDP no incluyen propuestas para la protección de los acrónimos específicos asociados con el movimiento internacional de la Cruz Roja, las cuales siguen siendo una cuestión pendiente del PDP original de la GNSO del año 2013 que resultó en recomendaciones que son inconsistentes con el asesoramiento del GAC respecto de estos acrónimos.

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

      El Grupo de Trabajo para PDP que volvió a convocarse realizó su trabajo de conformidad con las Pautas para Grupos de Trabajo y el Manual para Procesos de Desarrollo de Políticas de la GNSO, los cuales incluyen disposiciones pertenecientes a la representación de la comunidad en general. El Grupo de Trabajo estaba conformado por representantes de varias partes de la GNSO y la comunidad de la ICANN, incluidos representantes de la Cruz Roja. El Informe Inicial del Grupo de Trabajo se publicó para comentario público en junio de 2018, después de lo cual el grupo consideró todos los aportes recibidos al desarrollar sus recomendaciones finales, todas las cuales recibieron pleno consenso del Grupo de Trabajo. Con anterioridad a la votación del Consejo de la GNSO sobre el Informe Final, el presidente del Grupo de Trabajo realizó una reunión con los miembros de la comunidad que habían manifestado algunas inquietudes sobre las recomendaciones propuestas. El Consejo de la GNSO votó unánimemente a favor de aprobar todas las recomendaciones en septiembre de 2018.

      Las recomendaciones de políticas tal como las aprobó el Consejo de la GNSO se publicaron para comentario público en noviembre de 2018 y el GAC notificó de la acción del Consejo.

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

      Se plantearon posibles inquietudes sobre la libertad de expresión respecto de la reservación de los nombres de la Cruz Roja y la Media Luna Roja en el segundo nivel del DNS, así como el desarrollo de criterios del Grupo de Trabajo y un proceso para agregar nuevos nombres y variantes a la lista en vez de recomendar una lista fija. Asimismo, la comunidad solicitó aclaración sobre el mecanismo para implementar la política propuesta (es decir, si deberán enmendarse los contratos de la organización de la ICANN con sus partes contratadas). La Junta entiende que el Grupo de Trabajo considera que abordó estas inquietudes al desarrollar sus recomendaciones finales de política de consenso.

      Otros comentarios de la comunidad respaldaron la política propuesta, citando que la política pública debe suministrar las protecciones adecuadas para la Cruz Roja contra el uso indebido de sus nombres y variantes reconocidas, así como el hecho de que las protecciones recomendadas se basan en el derecho internacional humanitario y varias leyes nacionales.

      ¿Qué materiales significativos analizó la Junta Directiva?

      La Junta revisó el Informe Final del Grupo de Trabajo y la lista protegida recomendada de nombres de la Cruz Roja (https://gnso.icann.org/sites/default/files/file/field-file-attach/red-cross-protection-policy-amend-process-final-06aug18-en.pdf y https://gnso.icann.org/sites/default/files/file/field-file-attach/red-cross-identifiers-proposed-reservation-06aug18-en.pdf), el informe de recomendaciones del Consejo de la GNSO (https://gnso.icann.org/en/drafts/reconvened-red-cross-recommendations-14oct18-en.pdf), un resumen de los comentarios públicos recibidos (https://www.icann.org/en/system/files/files/report-comments-red-cross-names-consensus-policy-04jan19-en.pdf) y el asesoramiento relevante del GAC sobre este tema (https://gac.icann.org/).

      ¿Qué factores consideró importantes la Junta Directiva?

      Las recomendaciones fueron formuladas según el Proceso de Desarrollo de Políticas de la GNSO, de conformidad con lo estipulado en el Anexo A de los Estatutos de la ICANN y han recibido pleno consenso del Grupo de Trabajo, así como el apoyo unánime del Consejo de la GNSO. Tal como se estipula en los Estatutos de la ICANN (Anexo A, sección 9.a.), "Cualquier recomendación del PDP aprobada por un voto de mayoría calificada de la GNSO será adoptada por la Junta Directiva a menos que por el voto de más de dos tercios (2/3) de la Junta Directiva, dicha Junta determine que tal política no responde a los mejores intereses de la ICANN o de su comunidad".

      Asimismo, los Estatutos permiten aportes del GAC en relación a las inquietudes de política pública que pueden plantearse si la Junta Directiva adopta una política propuesta. En este contexto, el Comunicado del GAC pronunciado en Barcelona en octubre de 2018 manifestó su esperanza de que la Junta adopte las recomendaciones de la GNSO.

      ¿Existen impactos positivos o negativos para la comunidad?

      La adopción de la Junta de estas recomendaciones resolverá la cuestión, pendiente desde el año 2013, de inconsistencias entre el asesoramiento del GAC y la política anterior de la GNSO sobre estos nombres específicos de la Cruz Roja y la Media Luna Roja. Esto implica que las protecciones provisionales implementadas anteriormente por la Junta respecto de estos nombres serán reemplazadas por la política de consenso cuando entre en vigencia, lo que conlleva más claridad en cuanto al alcance de las protecciones de estos nombres para las partes contratadas de la ICANN y la comunidad en general.

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

      Además de todo costo financiero u otro costo relacionado con los recursos que pueda surgir durante el trabajo en la implementación de la política adoptada, no se prevén impactos fiscales o ramificaciones en la ICANN, la comunidad o el público.

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

      No hay cuestiones sobre la seguridad, estabilidad ni flexibilidad relacionadas con el DNS que puedan atribuirse directamente a la implementación de las recomendaciones de PDP.

      ¿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 cuestión concierne al proceso de políticas de la GNSO, tal como se define y describe en los Estatutos de la ICANN y los procedimientos operativos de la GNSO. Se han cumplido todos los requisitos de comentarios públicos como parte de estos procesos.

    5. Cambios de líderes y miembros del Comité de la Junta Directiva

      Visto y considerando: Que Chris Disspain es miembro de la Junta Directiva y actual Presidente del Comité de Mecanismos de Responsabilidad de la Junta Directiva (BAMC).

      Visto y considerando: Que León Sánchez es miembro actual de la Junta Directiva y miembro del BAMC.

      Visto y considerando: Que, a fin de permitir el traslado sin inconvenientes en el liderazgo del BAMC, el Comité de Gobernanza de la Junta Directiva (BGC) recomendó que la Junta Directiva designe de inmediato a León Sánchez como Presidente del BAMC y retenga al Sr. Disspain como miembro de dicho Comité.

      Visto y considerando: Que Matthew Shears manifestó interés en convertirse en miembro del Comité de Efectividad Organizacional de la Junta Directiva (OEC) y el BGC recomendó que la Junta designe de inmediato al Sr. Shears como miembro de dicho Comité.

      Resuélvase (2019.01.27.21): La Junta designa a León Sánchez como Presidente del BAMC y retiene a Chris Disspain como miembro de dicho Comité, con vigencia inmediata.

      Resuélvase (2019.01.27.22): La Junta designa a Matthew Shears como miembro del OEC, con vigencia inmediata.

      Fundamentos de las resoluciones 2019.01.27.21 – 2019.01.27.22

      La Junta se compromete a permitir un traspaso sin inconvenientes en el liderazgo de sus comités como parte de las discusiones continuas de la Junta respecto de la planificación de la sucesión. A tal fin, el Comité de Mecanismos de Responsabilidad de la Junta Directiva (BAMC) ha sugerido que su actual Presidente, Chris Disspain, deje el cargo de Presidente (pero siga siendo miembro) y que la Junta Directiva designe a León Sánchez como Presidente de dicho Comité. Como miembro del BAMC, el Sr. Disspain trabajará junto con el Sr. Sánchez durante el período de traspaso.

      Dado que el Comité de Gobernanza de la Junta Directiva (BGC) está a cargo de recomendar las tareas del comité, el BGC discutió la propuesta del BAMC y ha recomendado que la Junta Directiva designe a León Sánchez como nuevo Presidente del BAMC y retenga al Sr. Disspain como miembro de dicho Comité, con vigencia inmediata. La Junta concuerda con la recomendación del BGC.

      La Junta también se compromete a facilitar la composición de sus Comités de conformidad con los Procedimientos para la selección de liderazgo y comités de la Junta Directiva. El BGC consideró el interés que manifestó Matthew Shears de unirse al Comité de Efectividad Organizacional y ha recomendado que la Junta apruebe su designación. La Junta concuerda con la recomendación del BGC.

      La acción es en pos del interés público y está en consonancia con la misión de la ICANN dado que resulta importante que los Comités de la Junta Directiva, al llevar a cabo las tareas asignadas por la Junta de conformidad con los Estatutos de la ICANN y las cartas orgánicas de los Comités, hayan implementado planes de sucesión adecuados para garantizar la continuidad en el liderazgo dentro de los Comités. Asimismo, resulta de igual importancia que la composición de los Comités de la Junta se establezca de conformidad con los Procedimientos para la selección de liderazgo y comités de la Junta Directiva. Esta acción no tendrá un impacto financiero en la organización ni 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.

    6. Considerar la Solicitud de Reconsideración 16-11: Travel Reservations SRL, Famous Four Media Limited (y su subsidiaria solicitante, dot Hotel Limited), Fegistry LLC, Minds + Machines Group Limited, Spring McCook, LLC, y Radix FZC (y su subsidiaria solicitante, dot Hotel Inc.) (.HOTEL)

      Visto y considerando: Que Travel Reservations SRL, Fegistry LLC, Minds + Machines Group Limited y Radix FZC (y su subsidiaria solicitante, dotHotel Inc.) (colectivamente, los Solicitantes) presentaron solicitudes para .HOTEL, que se colocó en el conjunto de solicitudes controvertidas con otras solicitudes para el dominio .HOTEL. Otro solicitante, HOTEL Top-Level-Domain S.a.r.l. (HTLD), realizó una solicitud presentada por una comunidad para .HOTEL.

      Visto y considerando: Que HTLD participó en la evaluación con prioridad de la comunidad (CPE) y resultó ser la parte vencedora.

      Visto y considerando: Que, el 9 de agosto de 2016, la Junta Directiva aprobó las resoluciones 2016.08.09.14 y 2016.08.09.15 (las Resoluciones de 2016), las cuales ordenaban a la organización de la Junta avanzar con el procesamiento de la solicitud de la comunidad vencedora para el gTLD .HOTEL (Solicitud de HTLD) presentada por HTLD.

      Visto y considerando: Que los solicitantes presentaron la Solicitud de Reconsideración 16-11 que solicitaba la reconsideración de las Resoluciones de 2016.

      Visto y considerando: Que, mientras la Solicitud 16-11 estaba pendiente, la Junta ordenó a la organización de la ICANN que realice una revisión del Proceso de CPE (Revisión del proceso de CPE). El Comité de Gobernanza de la Junta Directiva (BGC) determinó que las Solicitudes de Reconsideración pendientes acerca del proceso de CPE, incluida la Solicitud 16-11, se pondrán en espera hasta que finalice la Revisión del proceso de CPE.1

      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 aprobó 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 puesto en espera 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 realizar una presentación telefónica ante dicho Comité en respaldo de la Solicitud 16-11, lo que los Solicitantes hicieron el 19 de julio de 2018. El BAMC también invitó a los Solicitantes a presentar materiales escritos adicionales en respuesta a los Informes sobre la revisión del proceso de CPE.

      Visto y considerando: Que el BAMC consideró cuidadosamente los méritos de la Solicitud 16-11 y todos los materiales relevantes, y recomendó que dicha solicitud sea denegada porque la Junta adoptó las Resoluciones de 2016 basándose en información precisa y completa. Asimismo, el BAMC recomendó que la Junta deniegue la Solicitud 16-11 porque no hay evidencia que respalde el reclamo de los Solicitantes de que la Junta no consideró la supuesta “ventaja injusta” que HTLD obtuvo como resultado de la Configuración del Portal ni hay evidencia de que la Junta discriminó en contra de los Solicitantes.

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

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

      Fundamento de la resolución 2019.01.27.23

      1. Resumen breve y recomendación

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

        El 16 de noviembre de 2018, el BAMC evaluó la Solicitud 16-11 y todos los materiales relevantes, y recomendó que la Junta deniegue la Solicitud 16-11 porque la Junta adoptó las Resoluciones de 2016 basándose en información precisa y completa. Asimismo, el BAMC recomendó que la Junta deniegue la Solicitud 16-11 porque no hay evidencia que respalde el reclamo de los Solicitantes de que la Junta no consideró la supuesta “ventaja injusta” que HTLD obtuvo como resultado de la Configuración del Portal ni hay evidencia de que la Junta discriminó en contra de los Solicitantes.

        El 30 de noviembre de 2018, el Solicitante presentó una refutación a la Recomendación del BAMC (Refutación). La Junta señala que la Refutación no es solicitada en virtud de los Estatutos aplicables a la Solicitud 16-11, que se estipulan en los Estatutos de 2016 que estaban en vigencia cuando se presentó la Solicitud 16-11.2 No obstante, la Junta consideró los argumentos contenidos en la refutación de los Solicitantes y considera que no justifican la reconsideración por los motivos mencionados más adelante en el presente.

      2. Cuestión

        Las cuestiones son si la adopción de la Junta de las Resoluciones de 2016 ocurrió: (i) sin consideración de la información material; o (ii) fue tomada como resultado de haberse basado en información material falsa o inexacta.

        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-12. Estos estándares se analizan detalladamente en la Recomendación del BAMC.

      3. Análisis y fundamentos

        1. La Junta adoptó las Resoluciones de 2016 después de haber considerado toda la información material y sin basarse en información material falsa o inexacta.

          Los Solicitantes sugieren que se justifica la reconsideración de las Resoluciones de 2016 porque la organización de la ICANN no investigó adecuadamente la Configuración del Portal y no abordó las supuestas acciones relacionadas con dicha configuración. Específicamente, los Solicitantes sostuvieron que la organización de la ICANN no verificó la afirmación de Dirk Kirschenowski, la persona cuyas credenciales se utilizaron para acceder a información confidencial de otros usuarios autorizados del portal de Nuevos gTLD, de que no suministró ni suministraría la información a la que él accedió a HTLD o a su personal. El BAMC concluyó, y la Junta concuerda, que este argumento no respalda la reconsideración porque los Solicitantes no identificaron información falsa o engañosa en la que se basó la Junta, o información material que la Junta no haya considerado en relación con la Configuración del Portal al adoptar las Resoluciones de 2016.

          En primer lugar, el BAMC determinó, y la Junta concuerda, que la organización de la ICANN realizó un análisis cuidadoso y exhaustivo de la Configuración del Portal y las cuestiones planteadas por los Solicitantes respecto de la Configuración del Portal. Los resultados de la investigación fueron compartidos con la Junta de la ICANN y fueron considerados cuidadosamente por la Junta en su adopción de las Resoluciones de 2016. El BAMC señaló que, en su investigación, la organización de la ICANN no descubrió ninguna evidencia de que: (i) la información que pueda haber obtenido el Sr. Krischenowski como resultado de la publicación del portal fuera utilizada para respaldar la solicitud de HTLD; o (ii) cualquier información obtenida por el Sr. Krischenowski permitiera que la solicitud de HTLD prevaleciera en la CPE. Además, la investigación de la ICANN reveló que al momento en que el Sr. Krischenowski accedió a información confidencial, él no estaba directamente vinculado con la solicitud de HTLD como contacto autorizado o como accionista, funcionario o director. En cambio, el Sr. Krischenowski fue accionista con el 50 % y director ejecutivo de GmbH, Berlín del dominio de alto nivel HOTEL (GmbH Berlín), la cual era accionista minoritario (48,8 %) de HTLD. El Sr. Philipp Grabensee, el único director ejecutivo de HTLD, informó a la organización de la ICANN que el Sr. Krischenowski "no era empleado" de HTLD, pero actuaba como consultor para la solicitud de HTLD al momento en que fue presentada en el año 2012. El Sr. Grabenesee además verificó que HTLD "se enteró sobre [el acceso del Sr. Krischenowski a los datos] el 30 de abril de 2015 en el contexto de la investigación de la ICANN". El Sr. Grabensee manifestó que los servicios de consultoría empresarial entre HTLD y el Sr. Krischenowski habían terminado al 31 de diciembre de 2015.3

          En segundo lugar, contrariamente a las afirmaciones de los Solicitantes, el BAMC determinó que la organización de la ICANN sí verificó la afirmación del Sr Krischenowski de que él y sus asociados no compartieron ni compartirían la información confidencial a la que accedieron como resultado de la Configuración del Portal con HTLD. La organización de la ICANN también confirmó con HTLD que no recibió información confidencial del Sr. Krischenowski o sus asociados obtenida de la Configuración del Portal. Tal como se analizó en el fundamento de las Resoluciones de 2016, esta información fue considerada por la Junta al adoptar las resoluciones.4 Como la Junta manifestó en el fundamento de las Resoluciones de 2016, incluso si el Sr. Krischenowski (o sus asociados) hubieran obtenido documentos comerciales confidenciales pertenecientes a los Solicitantes, esto no habría afectado de modo alguno el proceso de CPE para la solicitud de HTLD. Los Solicitantes no explicaron de qué manera los documentos confidenciales pertenecientes a los otros solicitantes de .HOTEL podrían afectar los criterios de CPE, los cuales no consideran la información confidencial de otras entidades. Si bien el acceso del Sr. Krischenowski ocurrió antes de la publicación del Informe de CPE en junio de 2014, HTLD no buscó enmendar su solicitud durante la CPE ni presentó documentación que podría haber sido considerada por el panel de la CPE.5 No existe evidencia alguna de que el Panel de la CPE haya tenido interacción con el Sr. Krischenowski durante el proceso de CPE y, por lo tanto, no existe motivo alguno para creer que el Panel de la CPE haya recibido la información confidencial que el Sr. Krischenowski obtuvo.6

          Por estos motivos, los cuales se analizaron en mayor detalle en la Recomendación del BAMC y se incorporaron en el presente a modo de referencia, el BAMC determinó, y la Junta concuerda, que los Solicitantes no identificaron información falsa o engañosa en la que la Junta se basó, o información material que la Junta no consideró en relación con la Configuración del Portal al adoptar las Resoluciones de 2016. La decisión de la Junta de permitir que la solicitud de HTLD continuara fue tomada después de una investigación integral, y fue bien razonada y estaba en consonancia con las actas constitutivas y los Estatutos de la organización de la ICANN. En particular, al llegar a su decisión de que no debía excluirse la solicitud de HTLD, la Junta consideró cuidadosamente los resultados de la revisión e investigación forense de la Configuración del Portal y los reclamos de los Solicitantes en relación con el supuesto impacto de la Configuración del Portal sobre la CPE de la solicitud de HTLD.

        2. La Junta no se basó en información falsa o engañosa al aceptar la declaración del Panel de IRP de Despegar.

          Si bien la Solicitud 16-11 objeta la conducta de la Junta en cuanto a las Resoluciones de 2016, los Solicitantes también parecen objetar la aceptación de la Junta de la declaración del Panel de IRP de Despegar. En particular, los Solicitantes afirman que "el Panel IRP de Despegar y otros se basó en información material falsa e inexacta”, tal como “¨cuando la Junta de la IRP aceptó la declaración de IRP de Despegar y otros, se basó en la misma información material falsa e inexacta".7

          Como cuestión inicial, la Junta concuerda con la conclusión del BAMC de que el reclamo de los Solicitantes prescribió. La resolución de la Junta respecto de la declaración del Panel de IRP de Despegar se publicó el 10 de marzo de 2016.8 La Solicitud 16-11 se presentó el 25 de agosto de 2016, más de cinco meses después de la aceptación de la Junta de la declaración del Panel de IRP de Despegar y mucho tiempo después del entonces plazo existente de 15 días para solicitar la reconsideración de una acción de la Junta.9

          1. Los reclamos de los Solicitantes respecto de las declaraciones del Panel de IRP de Dot Registry y Corn Lake no respaldan sus reclamos de discriminación.

            Incluso si los Solicitantes hubieran objetado oportunamente la resolución de la Junta respecto de la declaración del Panel de IRP de Despegar, la Junta concuerda con el BAMC que los reclamos de los Solicitantes no justifican la reconsideración. Los Solicitantes hacen referencia a la declaración del Panel de IRP publicada en Dot Registry, LLC vs. ICANN (Declaración del Panel de IRP de Dot Registry) para justificar que su reclamo de que la declaración del Panel de IRP de Despegar se basó "en la premisa falsa de que las determinaciones [del proveedor de CPE] son presuntivamente finales y están hechas independientemente por el [proveedor de CPE], sin la participación activa de la ICANN".10 En particular, los Solicitantes reclaman que la declaración del Panel de IRP de Dot Registry demuestra que "la ICANN tuvo comunicaciones con los evaluadores que identifican la puntuación de las CPE individuales,"11 de manera que el Panel de IRP de Despegar se basó en información falsa (a saber, la interpretación de la organización de la ICANN en su respuesta a la Solicitud de DIDP de 2014 de que la organización de la ICANN no participa en comunicaciones con los evaluadores individuales que participan en la calificación de las CPE, que fue objeto de la Solicitud 14-39), cuando consideró que la organización de la ICANN era la parte vencedora. Como resultado, los Solicitantes sugieren que la Junta de la ICANN también se basó en información falsa cuando aceptó la Declaración del Panel de IRP de Despegar. Los Solicitantes también argumentan que hay una “similitud contextualizada” a las partes reclamantes de Dot Registry y, por lo tanto, si la Junta rechaza otorgar a los Solicitantes la reparación cuando la Junta otorgó a las partes reclamantes de Dot Registry la reparación, entonces la Junta está discriminando a los Solicitantes en contradicción con las Actas Constitutivas y los Estatutos de la ICANN. El BAMC concluyó, y la Junta concuerda, que la Declaración de IRP de Dot Registry y la respuesta correspondiente de la Junta, no obstante, no justifica la solicitud de los Solicitantes de la reconsideración por los motivos siguientes.

            En primer lugar, contrariamente a la afirmación de los Solicitantes, el Panel de IRP de Dot Registry no consideró que la organización de la ICANN haya tenido comunicaciones con los evaluadores de la CPE que participaron en la puntuación de las CPE. En segundo lugar, las declaraciones que realizó un Panel de IRP no puede aplicarse sucintamente en el contexto de otro IRP totalmente independiente y no relacionado. El IRP de Dot Registry se refería a .LLC, .INC y .LLP, mientras que el IRP de Despegar se refería a .HOTEL. Se consideraron diferentes cuestiones en cada IRP, en función de diferentes argumentos presentados por partes diferentes respecto de solicitudes distintas y situaciones fácticas no relacionadas. Por ende, no existe respaldo alguno para el intento de los Solicitantes de aplicar las conclusiones de la Declaración de IRP de Dot Registry al IRP de Despegar.

            De manera similar, el BAMC concluyó, y la Junta concuerda, que la mención de los Solicitantes a la aceptación de la Junta de la declaración final en Corn Lake, LLC vs. ICANN, (Declaración de IRP de Corn Lake) y la decisión "de extender su procedimiento de revisión final para incluir la revisión de la determinación de los expertos de .charity de Corn Lake"12 no justifica la reconsideración. Como sucedió con el IRP de Dot Registry, las circunstancias en la IRP de Corn Lake y la posterior decisión de la Junta respecto de .CHARITY implicaron hechos diferentes y consideraciones distintas específicas a las circunstancias en la solicitud de Corn Lake. Por lo tanto, la acción de la Junta en ese caso no representa un tratamiento incoherente o discriminatorio; en cambio, es un ejemplo del modo en que la Junta debe "realizar distinciones matizadas entre las diferentes solicitudes [de gTLD]",13 y está en consonancia con las Actas Constitutivas y los Estatutos de la ICANN.

          2. La Revisión del proceso de CPE confirma que la organización de la ICANN no tuvo ninguna influencia indebida sobre el proveedor de CPE con respecto a las CPE llevadas a cabo.

            El BAMC concluyó, y la Junta concuerda, que la sugerencia de los Solicitantes de que la organización de la ICANN ejerció indebida influencia sobre la ejecución de la CPE por parte del proveedor de CPE no justifica la reconsideración.14 De hecho, como señaló correctamente el BAMC, este argumento ya había sido abordado por la Junta en las Resoluciones de 2018.15

            En resumen, el Informe de Alcance 1 de la revisión del proceso de CPE confirma que "no existe evidencia de que la organización de la ICANN haya ejercido influencia indebida sobre el proveedor de CPE con respecto a los informes de CPE emitidos por el proveedor de CPE ni realizado ningún acto impropio en el proceso de CPE", incluso respecto de la solicitud de HTLD.16 Los Solicitantes creen que el Informe de Alcance 1 demuestra que "el proveedor de CPE no era independiente de la ICANN. Cualquier influencia de la ICANN en la CPE era contraria a la política y, por ende, indebida".17 Los Solicitantes no identifican a qué “política” hacen referencia, pero, no obstante, su desacuerdo con las conclusiones del Informe de Alcance 1 no justifica la reconsideración. Esto se debe a que los Solicitantes no debaten que, cuando la organización de la ICANN brindó aportes al proveedor de CPE, dichos aportes no implicaban objetar las conclusiones del proveedor de CPE, sino eran para garantizar que los Informes de CPE fueran claros y “que las conclusiones del proveedor de CPE—no las conclusiones de la organización de la ICANN—estuviesen "respaldados por razonamiento suficiente".18 Los Solicitantes también citan “llamadas telefónicas entre la ICANN y el proveedor de CPE para discutir 'varias cuestiones'", afirmando que dichas llamadas "demuestran que el proveedor de CPE no estaba libre de la influencia externa de la organización de la ICANN" y, por ende, no era independiente.19 Ninguno de estos hechos demuestra que el proveedor de CPE “no era independiente” o que la organización de la ICANN ejerció influencia indebida sobre el proveedor de CPE. Estos tipos de comunicaciones, en cambio, demuestran que la organización de la ICANN protegía la independencia del proveedor de CPE al centrarse en garantizar que sus conclusiones fueran claras y bien respaldadas, en vez de inducirlo a llegar a una conclusión en particular. Por lo tanto, este argumento no justifica la reconsideración. En consecuencia, el BAMC concluyó, y la Junta concuerda, que debido a que el Informe de Alcance 1 demuestra que la organización de la ICANN no ejerció indebida influencia sobre el proveedor de CPE y el proceso de CPE, desaprueba el reclamo de los Solicitantes respecto de que “el Panel de IRP de Despegar y otros recibió información incompleta y engañosa” que se basa únicamente en la premisa de la indebida influencia de la organización de la ICANN en el proceso de CPE.20

          3. Los Solicitantes no han demostrado que la organización de la ICANN fue obligada a mantener comunicaciones con el Panel de CPE.

            La Junta concuerda con la conclusión del BAMC de que no se justifica la reconsideración porque, tal como reclaman los Solicitantes, el Panel de IRP de Despegar no ordenó a la organización del IRP que presentara documentos entre la organización de la ICANN y el proveedor de CPE. El BAMC señaló que el Panel de IRP no ordenó a la organización de la ICANN que presentara ningún documento en el IRP de Despegar, mucho menos documentos que reflejaran comunicaciones entre la organización de la ICANN y el panel de CPE. Y ningún procedimiento o política exigió que la organización de la ICANN presentara voluntariamente documentos durante el IRP de Despegar o con posterioridad.21 En cambio, durante el IRP de Dot Registry, el Panel de IRP de Dot Registry ordenó a la organización de la ICANN que presentara documentos que reflejasen "[c]onsideración de la ICANN del trabajo que realizó el [proveedor de CPE] en relación a la solicitud de Dot Registry" y los "[a]ctos realizados y las decisiones tomadas por la ICANN con respecto al trabajo que realizó el [proveedor de CPE] en relación con las solicitudes de Dot Registry".22 Las comunicaciones de la organización de la ICANN con los paneles de CPE para .INC, .LLC y .LLP estaban incluidas dentro del alcance de dichas solicitudes y, por ello, fueron realizadas. Por último, la organización de la ICANN actuó de conformidad con los procedimientos y políticas aplicables, incluidos los Estatutos de la ICANN, en ambas instancias.23

          4. Los Solicitantes no han demostrado que es pertinente realizar una nueva CPE de la solicitud de HTLD.

            Sin identificar criterios específicos de CPE, los Solicitantes solicitan a la Junta “garantizar una revisión significativa de la CPE respecto de .hotel, asegurando la coherencia de enfoque con su manejo de la [Declaración del Panel de IRP] de Dot Registry".24 El BAMC determinó, y la Junta concuerda, que, en la medida que los Solicitantes están afirmando que el resultado del análisis de la CPE de la solicitud de HTLD no está en consonancia con otras solicitudes de CPE, este argumento se abordó en el Alcance 2 de la Revisión del proceso de CPE. Allí, "la firma FTI no encontró ninguna evidencia de que el proceso o los informes de evaluación del proveedor de CPE se desviasen de modo alguno de las pautas aplicables ni observó instancias en las que el proveedor de CPE aplicara los criterios de CPE de manera incoherente".25 Además, por los motivos analizados más arriba y en detalle en la Recomendación del BAMC, la Junta considera que ni la CPE de .HOTEL ni las Resoluciones de 2016 evidencian un tratamiento incoherente o discriminatorio hacia los Solicitantes. Por estos motivos, este argumento no justifica la reconsideración.

        3. Las Resoluciones de 2018 están en consonancia con la misión, los compromisos y los valores fundamentales de la ICANN, y con las políticas establecidas de la ICANN.

          Las críticas del Solicitante de las Resoluciones de 2018 se enfocan en la transparencia, la metodología y el alcance de la Revisión del proceso de CPE. Ninguna justifica la reconsideración. El BAMC concluyó, y la Junta concuerda, que el BAMC y la Junta abordaron las inquietudes de los Solicitantes respecto de las Resoluciones de 2018 en su Recomendación sobre la Solicitud 18-6,26 la cual fue adoptada por la Junta el 18 de julio de 2018.27 Los fundamentos formulados por el BAMC y la Junta en su determinación de la Solicitud 18-6 se incorporan en el presente a modo de referencia.

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

          Como primer paso, la Solicitud 16-11 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.28 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 Estatutos del 11 de febrero de 2016 rigen la Solicitud 16-11.

            Los Solicitantes afirman que la Junta debe considerar la Solicitud 16-11 según los estándares de reconsideración estipulados en los Estatutos del 18 de junio de 2018 de la organización de la ICANN, es decir, la versión de los Estatutos en vigencia al momento de la recomendación del BAMC, en vez de la versión del 11 de febrero de 2016 que estaba en vigencia cuando la Solicitud 16-11 se presentó el 25 de agosto de 2016. Sin embargo, los Estatutos del 18 de junio de 2018 no existían cuando los Solicitantes presentaron la Solicitud 16-11 y la Junta no estipuló tratamiento retroactivo cuando aprobó la versión de los Estatutos del 18 de junio de 2018; en consecuencia, los Estatutos del 18 de junio de 2018 no tienen efecto retroactivo. De hecho, el formulario de Solicitud de Reconsideración que los Solicitantes presentaron hace referencia al estándar de reconsideración en virtud de los Estatutos del 11 de febrero de 2016, el cual instruye a los solicitantes que, para objeciones a la acción de la Junta, “[d]ebe haber identificación de información material que existía [al] momento de la decisión y que no fue considerada por la Junta a fin de definir una solicitud de reconsideración”. (Véase Solicitud 16-11, § 8, en página 7). Por lo tanto, el BAMC consideró correctamente la Solicitud 16-11 en virtud de los Estatutos del 11 de febrero de 2016, los cuales estaban en vigencia cuando los Solicitantes presentaron dicha Solicitud.

          2. Las objeciones de los Solicitantes a los Estatutos son extemporáneas.

            Los Solicitantes afirman que “los requisitos formales del Artículo 4(2)(q) [de los Estatutos del 18 de junio de 2018] y las circunstancias de este caso crean un desequilibrio injustificado que impide que los Solicitantes participen en los procedimientos de reconsideración de manera significativa” porque el BAMC emitió una recomendación de 33 páginas “casi cuatro meses” después de la presentación telefónica de los Solicitantes concerniente a la Solicitud 16-11, cuando las refutaciones (en virtud de los Estatutos actuales) deben ser presentadas dentro de los 15 días posteriores a la publicación del BAMC de sus recomendaciones y no puede superar las 10 páginas. (Refutación, en página 1). Como se mencionó más arriba, la versión operativa de los Estatutos no brinda a los Solicitantes el derecho de presentar una refutación, por lo que la reconsideración no se justifica a causa del aparente desacuerdo de los Solicitantes con los plazos que rigen las refutaciones en virtud de la versión actual (aplicable) de los Estatutos.29 Además, los Solicitantes han participado significativamente en el proceso de la reconsideración: los Solicitantes realizaron una presentación en una audiencia telefónica respecto de la Solicitud 16-11 (Refutación, en página 1); y, como se manifestó en la Recomendación del BAMC, los Solicitantes presentaron—y el BAMC consideró—siete cartas en respaldo a la Solicitud 16-11.30 Los Solicitantes ahora también presentaron una refutación en respaldo a la Solicitud 16-11, la cual ha sido considerada por la Junta. En consecuencia, los Solicitantes no demostraron que no les permitieron participar “significativamente” en el proceso de la solicitud de reconsideración.

          3. La Junta consideró las acciones de la Sra. Ohlmer cuando adoptó las Resoluciones de 2016.

            Los Solicitantes afirman que la “Junta ignoró el rol de [Katrin] Ohlmer” (Refutación, en página 3) en la cuestión relativa a la Configuración del Portal. Los Solicitantes alegan que la Sra. Ohlmer era Directora Ejecutiva de HTLD cuando tuvo acceso a la información confidencial de otros solicitantes y que ella había sido Directora Ejecutiva desde el momento en que HTLD presentó la solicitud de HTLD hasta el 23 de marzo de 2016. (Solicitud 16-11, § 8, en página 19; véase también Refutación, en página 3). Los Solicitantes alegan que, debido a su rol en HTLD, la información a la que tuvo acceso la Sra. Ohlmer “fue automáticamente suministrada a HTLD”. (Refutación, en página 4). Asimismo, los Solicitantes afirman que “HTLD reconoció que [la Sra. Ohlmer] (i) era principalmente responsable de representar a HTLD, (ii) estaba muy implicada en el proceso de organizar y recabar apoyo para [la solicitud de HTLD], y (iii) estaba a cargo de las operaciones comerciales diarias de HTLD".31

            La Junta considera que este argumento no justifica la reconsideración ya que la Junta sí consideró la afiliación de la Sra. Olhmer con HTLD cuando adoptó las Resoluciones de 2016. De hecho, el fundamento de las resoluciones 2016.08.09.14 – 2016.08.09.15 manifiesta que: (1) La Sra. Ohlmer era asociada del Sr. Krischenowski; (2) la compañía de propiedad absoluta de la Sra. Ohlmer adquirió las acciones que la compañía de propiedad abosluta del Sr. Krischenowski’ había tenido en GmbH Berlín (en sí un accionista minoritario del 48,8 % de HTLD); y (3) la Sra. Ohlmer (al igual que el Sr. Krischenowski) "certificó a la [organización de la] ICANN que [ella] eliminaría o destruiría toda la información obtenida y afirmó que [ella] no había usado ni usaría la información obtenida, ni se la entregaría a terceros".32 Tal como el BAMC señaló en su Recomendación, el Sr. Grabensee afirmó que GmbH Berlín transferiría su interés de dominio en HTLD a otra compañía, Afilias plc. Una vez realizada esta transferencia, la compañía de la Sra. Ohlmer no tendría un interés de dominio en HTLD.33

          4. Los argumentos de los Solicitantes respecto de las aseveraciones de HTLD y del Sr. Krischenowski, y la relación de HTLD con el Sr. Krischenowski no justifican la reconsideración.

            La Junta concluye que los argumentos de los Solicitantes de que la Junta no debería haber aceptado las declaraciones de los Sres. Grabensee o Krischenowski de que HTLD no recibió la información confidencial de la Configuración del Portal no justifican la reconsideración porque los Solicitantes no han proporcionado argumentos o hechos que el BAMC no haya considerado en su Recomendación.

            De manera similar, la Junta concluye que los argumentos de los Solicitantes de que la Junta no consideró el momento de la separación de HTLD del Sr. Krischenowski al adoptar las Resoluciones de 2016 no justifican la reconsideración. Contrariamente al argumento de los Solicitantes, resulta evidente que la Junta consideró el momento de la separación de HTLD del Sr. Krischenowski cuando adoptó las resoluciones. En el fundamento de las Resoluciones de 2016, la Junta hizo referencia al mismo plazo del fundamento de las Resoluciones, señalando que “los servicios de consultoría empresarial entre HTLD y el Sr. Krischenowski habían terminado el 31 de diciembre de 2015" y "el Sr. Krischenowski renunció a su cargo de director ejecutivo de GmbH Berlín el 18 de mayo de 2016."34 Los Solicitantes no están de acuerdo con la conclusión de la Junta de que el plazo no respaldaba la cancelación de la solicitud de HTLD, pero su desacuerdo, así sin más, no es fundamento para la reconsideración.

          5. Los Solicitantes no objetan la aplicación de criterios específicos de CPE a la solicitud de HTLD.

            Los Solicitantes reclaman que el BAMC concluyó incorrectamente que los Solicitantes “no objetan la aplicación de los criterios de CPE a la solicitud de HTLD o una conclusión en particular del proveedor de CPE sobre cualquiera de los criterios de CPE”. (Refutación, en página 9, en la cual se cita a la Recomendación, en la página 1). No obstante, ni la Solicitud 16-11 ni la Refutación identifican alguno de los criterios de CPE ni discuten la aplicación de criterios específicos de CPE a la solicitud de HTLD. (Véase Solicitud 16-11; Refutación). Los Solicitantes simplemente reiteran sus argumentos de que el proveedor de CPE aplicó criterios (no específicos) de CPE incoherente[mente] y errónea[mente]”, y que el BAMC no debería haber considerado los Informes sobre la Revisión del proceso de CPE al formular su Recomendación. (Refutación, en págs. 9-10). El BAMC abordó estos argumentos en su Recomendación y la Junta adopta el razonamiento del BAMC tal como se encuentra totalmente estipulado en el presente.

            Por estos motivos, la Junta Directiva concluye que no se justifica la reconsideración.

            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.

    7. Considerar la Solicitud de Reconsideración 18-9: DotKids Foundation (.KIDS)

      Visto y considerando: Que, en la resolución 2010.03.12.47, como parte del Programa de Nuevos gTLD, la Junta Directiva de la ICANN "solicit[ó] a las partes interesadas que trabajen a través de sus SO [organizaciones de apoyo] y AC [comités asesores], y formen un Grupo de Trabajo para elaborar un enfoque sostenible para brindar apoyo a los solicitantes que requieren asistencia para solicitar y operar nuevos gTLD".

      Visto y considerando: Que, en respuesta a la resolución 2010.03.12.47, se formó el Grupo de Trabajo Conjunto de Apoyo al Solicitante de Nuevos gTLD de SO/AS.

      Visto y considerando: Que, el 13 de septiembre de 2011, el JAS WG publicó su Informe Final, en el cual describe varias recomendaciones respecto del apoyo financiero y no financiero que debe ofrecerse a los “candidatos aprobados para recibir apoyo” en conjunto con el Programa de Nuevos gTLD.

      Visto y considerando: Que, en la resolución 2011.10.28.21, la Junta se comprometió a tomar el Informe Final de JAS seriamente y convocó a un grupo de trabajo de miembros de la Junta “para supervisar el alcance y la implementación de las recomendaciones del Informe [Final de JAS], según sea factible".

      Visto y considerando: Que, en las resoluciones 2011.12.08.01 – 2011.12.08.03, la Junta aprobó el plan de implementación del Informe Final de JAS elaborado por el Grupo de Trabajo de la Junta Directiva, ordenó que la organización de la ICANN finalizara el plan de implementación de conformidad con el proceso y los criterios propuestos para el lanzamiento del Programa de Apoyo para Solicitantes (ASP) en enero d e2012, y aprobó una reducción de tarifas a los candidatos de Apoyo para los Solicitantes de USD47.000 que reúnan los criterios establecidos.

      Visto y considerando: Que el Solicitante DotKids Foundation presentó una solicitud presentada por una comunidad para .KIDS, que se colocó en un conjunto de solicitudes controvertidas con otra solicitud de .KIDS y una solicitud de .KID.

      Visto y considerando: Que el Solicitante presentó una solicitud de ayuda financiera y dicha ayuda fue otorgada en la forma de una tarifa de solicitud reducida de conformidad con el ASP.

      Visto y considerando: Que el Solicitante participó en la Evaluación con prioridad de la comunidad y no fue la parte vencedora, y se programó una subasta de la ICANN para el 10 de octubre de 2018.

      Visto y considerando: Que, en agosto de 2018, el Solicitante contactó a la organización de la ICANN para solicitar ayuda financiera para participar en el proceso de resolución de controversia por cadena de caracteres, la cual la organización de la ICANN denegó por estar fuera del alcance del ASP.

      Visto y considerando: Que, el 21 de septiembre de 2018, el Solicitante presentó la Solicitud de Reconsideración 18-9, en la cual solicitaba la reconsideración de la respuesta de la organización de la ICANN a su solicitud de ayuda financiera para participar en el proceso de resolución de controversia por cadena de caracteres.

      Visto y considerando: Que el Comité de Mecanismos de Responsabilidad de la Junta Directiva (BAMC) había determinado con anterioridad que la Solicitud 18-9 se ha fundamentado suficientemente y que se la ha enviado al Defensor del Pueblo para su revisión y consideración conforme al Artículo 4, sección 4.2(j), 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 méritos de la Solicitud 18-9 y todos los materiales relevantes, y recomendó que dicha Solicitud sea denegada debido a que la organización de la ICANN se adhirió a las políticas y los procedimientos establecidos al responder la solicitud del Solicitante de ayuda financiera para participar en el proceso de resolución de controversia por cadena de caracteres; y la organización de la ICANN no infringió sus valores fundamentales establecidos en los Estatutos concernientes al interés público global.

      Visto y considerando: Que el 3 de diciembre de 2018, el Solicitante presentó una refutación a la Recomendación del BAMC sobre la Solicitud 18-9.

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

      Resuélvase (2019.01.27.24): La Junta Directiva adopta la Recomendación del BAMC sobre la Solicitud 18-9.

      Fundamento de la resolución 2019.01.27.24

      1. Resumen breve y recomendación

        Toda la información fáctica se describe en la Recomendación del BAMC sobre la Solicitud 18-9 (Recomendación del BAMC), que fue revisada y considerada por la Junta y se ha incorporado al presente documento a modo de referencia.

        El 16 de noviembre de 2018, el BAMC evaluó la Solicitud 18-9 y todos los materiales relevantes, y recomendó que la Junta denegara dicha Solicitud debido a que la organización de la ICANN se adhirió a las políticas y los procedimientos establecidos al responder la solicitud del Solicitante de ayuda financiera para participar en el proceso de resolución de controversia por cadena de caracteres; y la organización de la ICANN no infringió sus valores fundamentales establecidos en los Estatutos concernientes al interés público global.

        El 3 de diciembre de 2018, el Solicitante presentó una refutación a la Recomendación del BAMC (Refutación). La Junta señala que la Refutación fue presentada después del período asignado en virtud del Artículo 4, sección 4.2(q) de los Estatutos de la ICANN. No obstante, la Junta ha considerado los argumentos contenidos en la Refutación del Solicitante y considera que no justifican la reconsideración por los motivos mencionados más adelante.

      2. Cuestión

        Las cuestiones son las siguientes:

        • Si la organización de la ICANN cumplió con las políticas establecidas al responder la solicitud del Solicitante para ayuda financiera para participar en el proceso de resolución de controversia por cadena de caracteres para el conjunto de solicitudes controvertidas de .KID/.KIDS en virtud del ASP; y
        • Si la organización de la ICANN cumplió con sus valores fundamentales establecidos en los Estatutos respecto de su compromiso hacia el interés público global.35

        Estas cuestiones se consideran en las normas correspondientes a las solicitudes de reconsideración, que se incluyen en la Recomendación del BAMC.

      3. Análisis y fundamentos

        1. La organización de la ICANN se adhirió a las políticas y los procedimientos al responder a la solicitud del Solicitante de ayuda financiera.

          Los Solicitantes sugieren que se justifica la reconsideración debido a que la denegación de la organización de la ICANN de su solicitud de ayuda financiera para participar en la resolución de controversia por cadena de caracteres se contradice con el Informe Final de JAS. Específicamente, el Solicitante reclama que la organización de la ICANN estaba “bajo presión de tiempo” cuando consideró el Informe Final de JAS, lo que hizo que la Junta de la ICANN solo aprobara la recomendación del JAS WG de una reducción en la tarifa de solicitud para los solicitantes calificados y, en consecuencia, la Junta de la ICANN “no consideró[]” otras partes de las recomendaciones en ese momento.36 El BAMC determinó, y la Junta concuerda, que el Solicitante no ha suministrado evidencia para respaldar su reclamo de que la Junta de la ICANN no consideró todo el Informe Final de JAS en el año 2011. Como se analizó en detalle en la Recomendación del BAMC y se incorporó en el presente a modo de referencia, la Junta de la ICANN consideró de manera exhaustiva y completa todas las recomendaciones contenidas en el Informe Final de JAS. El 28 de octubre de 2011, la Junta de la ICANN resolvió considerar “seriamente” el Informe Final y reunió a un grupo de trabajo de miembros de la Junta “para supervisar el alcance y la implementación de las recomendaciones que surgen del [Informe Final de JAS], según sea factible".37 El grupo de trabajo de la Junta posteriormente trabajó con un subgrupo de miembros de la comunidad designados por el JAS WG para elaborar los documentos Proceso y Criterios que establecen el alcance y los requisitos del ASP, los que la Junta luego aprobó en diciembre de 2011.38

          El hecho de que la Junta de la ICANN no adoptase todas las recomendaciones del Informe Final de JAS cuando aprobó el plan de implementación de conformidad con los documentos Proceso y Criterios no justifica el punto de vista del Solicitante de que la organización de la ICANN no consideró (y rechaza) las recomendaciones que no se implementaron. Como cuestión inicial, ningún procedimiento o política exigía que la ICANN adoptase todas las recomendaciones establecidas en el Informe Final de JAS. Por el contrario, como se señaló en el Informe Final de JAS, las recomendaciones solo se "presentaron para su consideración ante la GNSO, el ALAC, la Junta de la ICANN y la comunidad de la ICANN".39 Quedaba a discreción de la Junta de la ICANN determinar qué recomendaciones implementar, si las hubiese, y la Junta de la ICANN resolvió hacerlo solo “según sea factible".40

          La posición del Solicitante también se contradice con el lenguaje sencillo del fundamento de las resoluciones 2011.12.08.01 – 2011.12.08.03, las cuales especificaban que la Junta había considerado y determinado no adoptar todas las recomendaciones estipuladas en el Informe Final de JAS: "Nota: este proceso no sigue todas las recomendaciones de JAS".41 En cambio, la Junta, a su discreción, consideró factible y resolvió aprobar la ayuda financiera en la forma de una “reducción de tarifas a USD47.000” para los candidatos de apoyo para los solicitantes que reúnan las condiciones necesarias.42

          Como señaló el BAMC, las únicas recomendaciones de JAS que aprobó la Junta son aquellas establecidas en los documentos Proceso y Criterios, los cuales, a su vez, definían el alcance y los requisitos del ASP. Todas las demás recomendaciones del JAS WG fueron consideradas pero no adoptadas. Debido a que el ASP, tal como se implementó, no brinda ayuda financiera para el proceso de resolución de controversias por cadena de caracteres, la Junta concuerda con la conclusión del BAMC de que la organización de la ICANN no infringió ningún procedimiento o política establecida al denegar la solicitud de dicha ayuda presentada por el Solicitante.

          El Solicitante tampoco identificó ningún procedimiento o política (porque no hay ninguno) que obligara a la ICAN a reconsiderar, como parte de la ronda actual del Programa de Nuevos gTLD las recomendaciones del JAS WG que no fueron anteriormente adoptadas. Por el contrario, los requisitos del ASP estipulados en los documentos Proceso y Criterios tenían el objetivo de ser “requisitos muy claros que son los requisitos finales del programa de apoyo para solicitantes".43

          Asimismo, la Junta concuerda con la conclusión del BAMC de que incluso si la junta “abordara el resto del Informe Final de JAS”, como reclama el Solicitante,44 aún así la reconsideración no estaría justificada. El BAMC ha revisado el Informe Final de JAS y los materiales relevantes asociados, incluidos los comentarios realizados en respuesta a la solicitud de comentario público, y ha confirmado que la ayuda financiera en el formato solicitado por el Solicitante nunca fue recomendada por el JAS WG o de cualquier otro modo. Por ende, incluso si la organización de la ICANN “abordara el resto del Informe Final de JAS" como reclama el Solicitante,45 la organización de la ICANN no encontraría ninguna recomendación en el Informe Final de JAS respecto de poner a disposición ayuda financiera para participar en el proceso de resolución de controversias por cadena de caracteres.

        2. La organización de la ICANN se adhirió a sus valores fundamentales al responder a la solicitud del Solicitante de ayuda financiera.

          La Junta está de acuerdo con la conclusión del BAMC de que la organización de la ICANN no ha infringido su valor fundamental de actuar en pos del interés público global al denegar la solicitud de ayuda financiera presentada por el Solicitante. El valor fundamental citado por el Solicitante estipula lo siguiente:

          Buscar y apoyar la participación amplia e informada y reflexionar sobre la diversidad funcional, geográfica y cultural de Internet en todos los niveles del desarrollo de políticas y toma de decisiones a fin de garantizar que se utilice un proceso ascendente de desarrollo de políticas de múltiples partes interesadas para garantizar que el interés público global y dichos procesos sean responsables y transparentes.46

          La implementación de la organización de la ICANN del ASP es la representación de este valor fundamental, no, como el Solicitante reclama, una contravención al mismo. El valor fundamental de "buscar[] y apoyar la participación amplia e informada" mediante el modelo de múltiples partes interesadas se ilustró en la solicitud de la Junta Directiva de la ICANN, en marzo de 2010, de que las partes interesadas "trabajen a través de sus SO [organizaciones de apoyo] y AC [comités asesores], y formen un Grupo de Trabajo para elaborar un enfoque sostenible hacia suministrar apoyo a los solicitantes que requieren ayuda al solicitar y operar nuevos gTLD".47 El Informe Final de JAS, que la Junta de la ICANN consideró en su totalidad, fue elaborado en respuesta al compromiso de la ICANN hacia el modelo de múltiples partes interesadas y ejemplifica el compromiso de la ICANN de “garantizar el interés público global” en lo concerniente al Programa de Nuevos gTLD. Al resolver considerar el Informe Final de JAS, la Junta señaló que "se toma seriamente las afirmaciones de la comunidad de la ICANN de que el apoyo a los solicitantes fomentará la participación diversa en el Programa de Nuevos gTLD y promoverá el objetivo de la ICANN de ampliar el alcance del modelo de múltiples partes interesadas".48

          El BAMC determinó, y la Junta concuerda, que el Solicitante parece instar a la organización de la ICANN a evadir la política establecida estipulada en los requisitos que rigen el ASP de manera favorable para el Solicitante, que socava, en vez de estimular, el interés público global. La organización de la ICANN está comprometida a garantizar diversidad, estabilidad operativa y no discriminación, pero no es responsable de garantizar un gTLD para ningún solicitante específico. El Solicitante no ha demostrado ninguna infracción a los valores fundamentales de la ICANN.

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

          Como cuestión inicial, la Junta Directiva manifiesta que la Refutación es extemporánea. El Solicitante recibió la Recomendación el 17 de noviembre de 2018.49 La Refutación vencía a los 15 días posteriores, el 2 de diciembre de 2018.50 El Solicitante presentó la Refutación el 3 de diciembre de 2018, un día después del vencimiento del plazo.51 No obstante, la Junta ha considerado los argumentos contenidos en la refutación del Solicitante y considera que no justifican la reconsideración por los motivos siguientes.

          1. La Solicitud 18-9 solicita la reconsideración de la denegación de la solicitud de ayuda financiera del Solicitante por parte de la organización de la ICANN.

            El Solicitante argumenta en la Refutación que no está solicitando “directamente” “ayuda financiera”. (Refutación, en página 1. Véase también id. en página 3 (la Solicitud 18-9 "no solicitó ninguna forma particular de ayuda financiera”).) No obstante, como el BAMC manifestó en la Recomendación, el 27 de agosto de 2018, el Solicitante envió un mensaje por correo electrónico a la organización de la ICANN en el cual indicaba que “deseaba solicitar ayuda financiera para participar en el proceso de resolución de controversia por cadena de caracteres”. (Recomendación del BAMC en página 9, que cita al Anexo A a la Recomendación). El Solicitante identificó la respuesta de la organización de la ICANN a este mensaje de correo electrónico "rechaza[ndo] la solicitud" como la acción que busca ser reconsiderada.52 De conformidad, el BAMC razonablemente entendió que la Solicitud 18-9 buscaba la reconsideración de la denegación de la solicitud de ayuda financiera del Solicitante por parte de la organización de la ICANN.

            El Solicitante ahora afirma que la Solicitud 18-9 “simplemente” solicita que “la Junta de la ICANN inicie el proceso para considerar las partes restantes del Informe Final de JAS”. (Refutación en página 1). Sin embargo, el BAMC ya consideró este reclamo. El BAMC concluyó que "la organización de la ICANN consideró cuidadosa y completamente todas las recomendaciones formuladas en el Informe Final de JAS". (Recomendación del BAMC, en página 13). La Junta Directiva concuerda con el razonamiento contenido en la Recomendación del BAMC y adopta el mismo.

            La Junta considera que la Refutación del Solicitante no ha suministrado ningún argumento nuevo ni identificó ningún procedimiento o política (porque no hay ninguno) que obligue a la ICANN a reconsiderar las recomendaciones del JAS WG que no adoptó anteriormente.

            La Junta señala que la Refutación expresa desacuerdo con la conclusión del BAMC de que la Junta dejó en claro que había decidido no adoptar todas las recomendaciones contenidas en el Informe Final de JAS. El Solicitante reclama que esto “en el mejor de los casos deja la pregunta abierta” en cuanto a si la Junta brindaría posterior consideración a las recomendaciones que no siguió. (Refutación, en página 2) No obstante, nada en los materiales citaba que el Solicitante respalda su afirmación de que la Junta tenía la intención de "dejar[] . . . abierta" la posibilidad de una posterior consideración de las recomendaciones de JAC que no adoptó en el año 2011. (Refutación, en página 2). Tal como explicó el BAMC, las resoluciones 2011.12.08.01 – 2011.12.08.03 y los materiales respaldatorios dejan en claro que la Junta consideró y decidió no adoptar ninguna recomendación del JAS WG salvo aquellas estipuladas en los documentos Proceso y Criterios. Específicamente, la resolución 2011.12.08.01 ordenó a la organización de la ICANN a "finalizar el plan de implementación de conformidad con el proceso y los criterios propuestos para el lanzamiento del Programa de Apoyo para Solicitantes".53 Los documentos Proceso y Criterios no estipulan los fondos adicionales que el Solicitante desea ni estipula la posible reevaluación de las recomendaciones de JAS que la Junta no aceptó en 2011.54 La Junta no se ve persuadida por los argumentos del Solicitante en sentido contrario, los cuales se basan en opiniones. El Solicitante no ha suministrado pruebas o hechos nuevos para demostrar que se justifica la reconsideración.

          2. El JAS WG nunca recomendó ayuda financiera en la forma que solicitó el Solicitante.

            Por primera vez en la Refutación, el Solicitante argumenta que, sin “alguna ayuda posterior (por ejemplo, en términos de reducción de tarifas, ajustes, escalonamiento u otro modo), el Programa de Apoyo para Solicitantes simplemente no tiene sentido”. (Refutación, en página 1). Como cuestión preliminar, los Estatutos estipulan que las Refutaciones “deberán . . limitarse a refutar o contradecir las cuestiones planteadas en la” Recomendación y “no ofrecerán nueva evidencia” si el Solicitante “pudo haber suministrado” dicha evidencia cuando presentó originalmente la Solicitud.55 En consecuencia, este argumento no refuta una cuestión específica planteada en la Recomendación; debería haberse planteado en la Solicitud y, por ende, no está debidamente planteada en la Refutación. Además, cualquier objeción a las resoluciones 2011.12.08.01 – 2011.12.08.03 de la Junta o el ASP hace tiempo que ha prescripto. No obstante, la Junta ha considerado el argumento y concluye que no justifica la reconsideración por los motivos siguientes.

            El Solicitante argumenta que el BAMC concluyó incorrectamente que ninguna de las recomendaciones del JAS WG en las que se basó el Solicitante en la Solicitud 18-8 “sugiere un intento específico de brindar ayuda financiera para asistir en el proceso de resolución de controversia por cadena de caracteres”. (Refutación, en página 3). El Solicitante afirma que “[i]ncluso si no hay disponible apoyo directo para el proceso de resolución de controversia por cadena de caracteres, el ajuste de otras tarifas podría tener un impacto significativo en” los candidatos aprobados para apoyo y que el BAMC debería haber concluido que “solo porque la contribución directa puede no estar incluida[,] . . . otros ajustes de tarifas" podrían haber ser contemplados. (Id.) La conclusión del BAMC no fue tan limitada como el Solicitante sugiere; el BAMC concluyó que el Informe Final de JAS no respalda ayuda financiera de ningún tipo para una parte del proceso de resolución de controversia por cadena de caracteres. (Recomendación del BAMC, en páginas 15-16). Además, como el BAMC señaló, el Informe Final de JAS específicamente indicó que, en el caso de existir una controversia por cadena de caracteres, el Solicitante debería “financiar[] esta paso adicional” del proceso. (Recomendación del BAMC, en página 16, la cual cita al Informe Final de JAS en la página 28). El Solicitante no identifica ningún procedimiento o política (ni existe alguno) que exija a la organización de la ICANN a modificar o complementar las recomendaciones del JAS WG para brindar ayuda adicional al Solicitante o solicitantes en situaciones similares cuando la Junta no ha realizado dichas disposiciones y el informe a la Junta ni siquiera recomendaba dicha ayuda.

            La Junta también considera que la afirmación del Solicitante de que el BAMC concluyó que “cualquier otra ayuda financiera no ayudará” es errónea. (Refutación, en página 3). El BAMC concluyó que la organización de la ICANN cumplió con los procedimientos y políticas cuando llegó a la conclusión de que no había disponible una asistencia financiera adicional para el Solicitante en virtud del ASP. (Recomendación del BAMC, en páginas 12-16).

            Por los motivos expuestos, ninguno de los argumentos de la Refutación del Solicitante justifica la reconsideración.

            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.

    8. Considerar la Solicitud de Reconsideración 16-12: Merck KGaA (.MERCK)

      Visto y considerando: Que Merck KGaA (Solicitante) presentó una solicitud presentada por una comunidad para .MERCK (la Solicitud), la cual fue colocada en un conjunto de solicitudes controvertidas con otras solicitudes para .MERCK.

      Visto y considerando: Que el Solicitante participó en la evaluación con prioridad de la comunidad (CPE), pero no resultó ser la parte vencedora.

      Visto y considerando: Que el Solicitante presentó la Solicitud de Reconsideración 16-12 en la que solicitaba la reconsideración del informe de CPE de su Solicitud, y la aceptación de dicho informe por la organización de la ICANN.

      Visto y considerando: Que, mientras la Solicitud 16-12 estaba pendiente, la Junta ordenó a la organización de la ICANN que realice una revisión del Proceso de CPE (Revisión del proceso de CPE). El Comité de Gobernanza de la Junta Directiva determinó que las Solicitudes de Reconsideración pendientes acerca del proceso de CPE, incluida la Solicitud 16-12, se pondrán en espera hasta que finalice la Revisión del proceso de CPE.56

      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ó al Solicitante a presentar materiales adicionales y a realizar una presentación ante el BAMC en respaldo a la Solicitud 16-12.

      Visto y considerando: Que el Solicitante presentó materiales adicionales en forma respaldatoria y realizó una presentación telefónica ante el BAMC en respaldo a la Solicitud 16-12; el Solicitante también presentó un resumen escrito de su presentación telefónica ante el BAMC.

      Visto y considerando: Que el BAMC ha considerado cuidadosamente los méritos de la Solicitud 16-12 y todos los materiales relevantes, y ha recomendado que dicha solicitud sea denegada porque el proveedor de CPE no infringió ningún procedimiento o política en su evaluación del Criterio 2 y la aceptación del Informe del proveedor de CPE por parte de la organización de la ICANN cumplió con las políticas establecidas.

      Visto y considerando: Que la Junta ha considerado cuidadosamente la Recomendación del BAMC sobre la Solicitud 16-12 y todos los materiales relevantes relacionados con la misma, y la Junta está de acuerdo con la Recomendación del BAMC.

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

      Fundamento de la resolución 2019.01.27.25

      1. Resumen breve y recomendación

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

        El 14 de diciembre de 2018, el BAMC evaluó la Solicitud 16-12 y todos los materiales relevantes, y recomendó que la Junta deniegue dicha Solicitud porque el proveedor de CPE no infringió ningún procedimiento o política en su evaluación del Criterio 2 y la aceptación del Informe del proveedor de CPE por parte de la organización de la ICANN cumplió con las políticas establecidas.

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

      2. Cuestión

        Las cuestiones son las siguientes:

        • Si el proveedor de CPE cumplió con la Guía en su aplicación del Criterio 2, Nexo entre la cadena de caracteres propuesta y la comunidad, en el Informe de CPE.
        • Si la organización de la ICANN cumplió con los procedimientos y políticas aplicables cuando aceptó el Informe de CPE;
        • Si la organización de la ICANN debe divulgar información documental y comunicaciones entre la organización de la ICANN y el proveedor de CPE en relación a la Solicitud; y
        • Si la Junta cumplió con los compromisos, valores fundamentales y políticas aplicables cuando reconoció y aceptó las conclusiones manifestadas en los Informes de Revisión del proceso de 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-12. Estos estándares se analizan detalladamente en la Recomendación del BAMC.

      3. Análisis y fundamentos

        1. Los criterios y procedimientos de la CPE

          La CPE es un mecanismo de resolución de controversias por cadenas de caracteres disponible para los solicitantes que autodesignaron sus solicitudes como solicitudes de la comunidad.57 Los estándares de la CPE y el proceso de la CPE están definidos 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. 58 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". 59 La CPE es llevada a cabo por un panel independiente compuesto por dos evaluadores que son designados por el proveedor de CPE. 60. 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.61

        2. El proveedor de CPE cumplió con los procedimientos y políticas aplicables en su aplicación del Criterio 2.

          El Solicitante reclama que el proveedor de CPE se equivocó al otorgar a su solicitud cero de cuatro puntos para el Criterio 2. El Criterio 2 evalúa "la relevancia de la cadena de caracteres para la comunidad específica que pretende representar".62 Se mide por dos subcriterios: subcriterio 2-A-Nexo (vale un máximo de tres puntos); y subcriterio 2-B-Singularidad (vale un máximo de un punto).63

          1. El proveedor de CPE cumplió con los procedimientos y políticas aplicables en su aplicación del subcriterio 2-A-Nexo.

            La Solicitud del Solicitante recibió cero puntos para el subcriterio 2-A. Para obtener tres puntos para el subcriterio 2-A, la cadena de caracteres solicitada debe “coincidir con el nombre de la comunidad o ser un formato corto o una abreviatura reconocida de la comunidad".64 El proveedor de CPE determinó que la Solicitud del Solicitante no cumplía con la prueba de tres puntos porque la cadena de caracteres solicitada no “coincide con el nombre de la comunidad como se define en la solicitud, ni es un formato corto ni una abreviatura reconocida de la comunidad".65

            Para una puntuación de dos, la cadena de caracteres solicitada debe “estrechamente describir la comunidad o los miembros de ella, sin extralimitarse sustancialmente más allá de la comunidad".66 No es posible obtener una puntuación de uno para este subcriterio. Asimismo, el proveedor de CPE concluyó que la Solicitud del Solicitante no cumplía con la prueba de dos puntos porque la cadena de caracteres solicitada no “identifica... a la comunidad como se define en la solicitud".67

            El proveedor de CPE consideró que

            si bien la cadena de caracteres “Merck” coincide con el nombre de la comunidad definido en la Solicitud, también coincide con el nombre de otra entidad corporativa conocida como “Merck” de EE. UU. y Canadá. Esta compañía con base en EE. UU., Merck & Co., Inc., opera en el sector farmacéutico, de vacunas y de salud animal, tiene 68.000 empleados y tuvo ingresos de USD 39.500 millones en el año 2015. Por ende, es una entidad importante también conocida con el nombre "Merck".68

            El proveedor de CPE, por lo tanto, determinó que la cadena de caracteres "'se extralimita sustancialmente más allá de la comunidad'…que define porque la cadena de caracteres solicitada también identifica a una entidad importante—Merck en EE. UU. y Canadá—que no es parte de la comunidad definida por el solicitante".69

            El BAMC concluyó que, si bien el Solicitante está en desacuerdo con la conclusión del proveedor de CPE, el Solicitante no ha identificado ningún procedimiento o política que el proveedor de CPE haya infringido en su determinación.70 El Solicitante tampoco suministró pruebas de que el proveedor de CPE infringió un procedimiento o política establecida. El BAMC señaló que el Solicitante no niega que la entidad con base en EE. UU. esté conectada con la comunidad del Solicitante como se define en la Solicitud; al contrario, la mayor parte de la Solicitud 16-12 está dedicada a resumir la disputa legal contenciosa existente desde hace décadas entre el Solicitante y Merck & Co., Inc. con base en EE. UU. (una anterior subsidiaria del Solicitante) sobre qué empresa puede usar el nombre “MERCK” fuera de los Estados Unidos.71 En consecuencia, el BAMC concluyó, y la Junta concuerda, que el desacuerdo sustancial del Solicitante con la conclusión del proveedor de CPE no es fundamento para la reconsideración.

            Además, tal como se informó en el Informe de Alcance 2 de la Revisión del proceso de CPE, el proveedor de CPE actuó en consonancia con la Guía en su análisis en virtud del subcriterio 2-A para todas las CPE que se llevaron a cabo.72

            La consideración del tratamiento del proveedor de CPE de la solicitud de Merck & Co. confirma la coherencia del análisis del Proveedor de CPE del subcriterio 2-A en su totalidad para todas las CPE. En el informe de CPE sobre la solicitud de la comunidad presentada por Merck & Co., Inc. para el gTLD .MERCK (Informe de CPE sobre Merck & Co.), el proveedor de CPE aplicó el mismo razonamiento para la solicitud de Merck & Co. que el razonamiento incluido en el Informe de CPE del Solicitante: consideró que la cadena de caracteres solicitada (.MERCK) por Merck & Co., se extralimita sustancialmente más allá de la comunidad porque el Solicitante aquí es “una entidad importante también conocida con el nombre 'Merck'" y no está incluida en la definición de la comunidad de la Solciitud de Merck & Co. en su solicitud de .MERCK.73 Allí, el proveedor de CPE consideró si la existencia del Solicitante debería impedir que la solicitud de Merck & Co. reciba puntos sobre el elemento nexo.74 Por tal motivo, el proveedor de CPE otorgó a la solicitud de Merck & Co. cero puntos en el subcriterio 2-A, lo mismo que hizo el proveedor de CPE con respecto a la Solicitud del Solicitante.75

            Con respecto al reclamo del Solicitante de que el tamaño de su comunidad es mayor que la comunidad asociada a Merck & Co., Inc. y, por ende, "la cadena de caracteres claramente identifica al Solicitante"76, el BAMC concluyó, y la Junta concuerda, que esta afirmación no muestra que el proveedor de CPE no cumplió con alguna política o algún procedimiento establecido al concluir que la cadena de caracteres .MERCK se extralimita sustancialmente más allá de la definición de la comunidad en la Solicitud del Solicitante. El Solicitante tampoco ha demostrado que el proveedor de CPE no cumplió con algún procedimiento o alguna política al otorgar cero puntos en el elemento nexo. En cambio, como señaló el BAMC, la Guía específicamente instruye que se debe otorgar cero puntos si la cadena de caracteres se extralimita sustancialmente más allá de la comunidad en la solicitud.

            El BAMC determinó, y la Junta concuerda, que la sugerencia del Solicitante de que debería haber recibido más puntos para el subcriterio 2-A porque “tomará todas las medidas necesarias, incluso geofocalización, para evitar el acceso a Internet de usuarios en los pocos territorios en los que Merck & Co. tiene derechos de marca comercial” no justifica la reconsideración porque el Solicitante no señala ningún procedimiento ni ninguna política que indique que el proveedor de CPE debe (o incluso debería) tener en cuenta consideraciones de geofocalización al calificar el subcriterio 2-A. El BAMC manifiesta que no existe ninguna política de este tipo según la Guía.

            Con respecto a la sugerencia del Solicitante de que el proveedor de CPE no consideró evidencia de “intrusión ilegítima” en sus territorios y su “uso ilegal” de la palabra por parte de Merck por Merck & Co., Inc.,77 el BAMC concluyó, y la Junta concuerda, que el proveedor de CPE no estaba obligado a evaluar la disputa de marca comercial que existe hace décadas entre el Solicitante y Merck & Co., Inc.78,79 En consecuencia, el proveedor de CPE no infringió ningún procedimiento o política establecida al no tener en cuenta las disputas legales en curso y este argumento no justifica la reconsideración. Por el mismo motivo, la Junta también concuerda con la conclusión del BAMC de que la organización de la ICANN no estaba obligada a suministrar al proveedor de CPE información relacionada con las disputas legales entre el Solicitante y Merck & Co., Inc. El Solicitante no identifica, ni puede identificar, una política o un procedimiento que obligue a la organización de la ICANN a suministrar dicha información al proveedor de CPE.

          2. La aplicación del subcriterio 2-A es coherente con otros informes de CPE.

            El Solicitante afirma que el análisis del proveedor de CPE del subcriterio 2-A del Infome de CPE no es coherente con su análisis del mismo subcriterio para las solicitudes de .ECO, .RADIO, .SPA y .ART, y reclama que en cada uno de dichos casos, el “solicitante recibió tres puntos en el requisito de nexo si bien existían otras entidades que usaban el mismo nombre".80 El BAMC concluyó, y la Junta concuerda, que el Solicitante no brinda respaldo o argumento adicional respecto de esta afirmación y, por ende, el argumento está fuera de lugar. Como se analizó en detalle en la Recomendación del BAMC y se incorporó en el presente a modo de referencia, en cada uno de estos casos, el proveedor de CPE determinó que la cadena de caracteres solicitada no coincidía con el nombre de la comunidad, pero identificaba a la comunidad sin extralimitarse sustancialmente más allá de la comunidad.81 Por el contrario, el proveedor de CPE concluyó que .MERCK coincidía con el nombre de la comunidad, pero también coincidía con el nombre de otra comunidad, el de Merck & Co., Inc. con base en EE. UU.82 En consecuencia, la Junta concuerda con la conclusión del BAMC de que no se justifica la reconsideración sobre este fundamento porque el Solicitante no suministró ninguna evidencia de que el proveedor de CPE contradijo una política o un procedimiento establecido.

          3. El proveedor de CPE cumplió con los procedimientos y políticas aplicables al aplicar el subcriterio 2-B-Singularidad.

            El BAMC determinó, y la Junta concuerda, que el Solicitante no ha demostrado que el proveedor de CPE infringió alguna política o algún procedimiento al otorgar cero puntos a la Solicitud del Solicitante para el subcriterio 2-B-Singularidad. Para obtener un punto para el subcriterio 2-B, la cadena de caracteres solicitada no debe tener un significado significativo más allá de identificar a la comunidad descripta en la solicitud.83 Una solicitud que no califica para dos o tres puntos para el subcriterio 2-A no calificará para una puntuación de uno para el subcriterio 2-B.84 En este caso, el proveedor de CPE otorgó cero puntos en el subcriterio 2-B porque la cadena de caracteres solicitada no recibió una puntuación de dos o tres puntos en el subcriterio 2-A por los motivos ya expuestos.85

            El Solicitante sugiere que el proveedor de CPE debería haber otorgado a la Solicitud un punto en el elemento singularidad debido a la reputación del Solicitante y el uso exclusivo de su nombre de comunidad MERCK.86 De manera similar a los argumentos sobre el subcriterio 2-A, la Junta concuerda con el BAMC que la objeción del Solicitante de la puntuación del proveedor de CPE sobre el subcriterio se basa exclusivamente en un desacuerdo sustancial con las conclusiones del proveedor de CPE, lo cual no es fundamento para la reconsideración. El Solicitante no mostró ninguna infracción a una política o un procedimiento en relación a la conclusión del proveedor de CPE de que la Solicitud debe recibir una puntuación de cero puntos para el subcriterio 2-B.

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

          El Solicitante argumenta que el proveedor de CPE “no tomó el cuidado necesario” al elaborar el Informe de CPE “y aplicó erróneamente los estándares y políticas que elaboró la ICANN en la [Guía], lo que resultó en la denegación de debido proceso al Solicit[a]nte".87 La Junta concuerda con el BAMC que este argumento no justifica la reconsideración. Por los motivos expuestos anteriormente y en mayor detalle en la Recomendación del BAMC, el Solicitante no ha demostrado ninguna omisión del proveedor de CPE de seguir la política y los procedimientos establecidos para la CPE como se estipula en la Guía. En cambio, el Solicitante sugiere que debería haber habido un proceso de apelación formal para las decisiones tomadas por proveedores de servicios de terceros de la organización de la ICANN, incluidos el proveedor de CPE, los paneles de objeción por derechos legales y los paneles para confusión de cadenas de caracteres. Los métodos para objetar determinaciones en el curso del proceso de resolución de controversias por cadenas de caracteres de gTLD están estipulados en la Guía, la cual fue elaborada después de extensa consulta con la comunidad y adoptada por la Junta en junio de 2011.88 El plazo para objetar la Guía hace mucho que expiró.89

          Como el BAMC señaló, la Guía brinda una ruta para objetar los resultados del proceso de CPE a través de mecanismos de responsabilidad de la ICANN.90 De hecho, el Solicitante ha ejercido su derecho al invocar el proceso de reconsideración con la Solicitud 16-12.91 En consecuencia, la Junta considera que debido a que la aplicación del Criterio 2 a la Solicitud por parte del proveedor de CPE fue coherente con la Guía, la aceptación de la organización de la ICANN del Informe de CPE también fue coherente con los procedimientos y políticas aplicables y no implicó ninguna infracción al “debido proceso”. Además, la Junta considera que la ausencia de un mecanismo de apelación en virtud de la Guía para la esencia de los resultados de la evaluación no constituye una infracción al debido proceso.

        4. La Revisión del proceso de CPE respalda los resultados de la solicitud de Merck KGaA.

          El Informe de Alcance 2 de la Revisión del proceso de CPE muestra que el proveedor de CPE aplicó los criterios de CPE de manera coherente en todas las CPE y que no hay evidencia de que el proceso o los informes de evaluación del proveedor de CPE se hayan desviado de algún modo de las guías aplicables.92 Por este motivo adicional, el BAMC consideró, y la Junta concuerda, que el argumento del Solicitante de que el proveedor de CPE aplicó incorrectamente el Criterio 2 no justifica la reconsideración.

          El Solicitante argumenta que los Informes de Alcance 2 y 3 de la Revisión del proceso de CPE son excesivamente limitados y no reevaluaron la aplicación del proveedor de CPE de los criterios de Nexo ni evaluó la conveniencia ni la razonabilidad de la investigación realizada por el proveedor de CPE.93 Por los motivos estipulados en la Recomendación del BAMC, los cuales se incorporaron en el presente a modo de referencia, el BAMC concluyó, y la Junta concuerda, que los reclamos del Solicitante no justifican la reconsideración porque el Solicitante no demostró que se haya infringido un proceso o procedimiento. (Recomendación del BAMC, páginas 25-28).

        5. La Solicitud del Solicitante de la divulgación de información documental no es fundamento para la reconsideración.

          El BAMC determinó, y la Junta concuerda, que la solicitud del Solicitante de divulgación de información documental entre la organización de la ICANN y el proveedor de CPE en relación con la Solicitud y el Informe de CPE no está realizada correctamente en el contexto de una solicitud de reconsideración, ya que el Solicitante no solicita a la organización de la ICANN reconsiderar la acción o inacción de la Junta o del personal.94 En consecuencia, la Junta concuerda con el BAMC que esto no es fundamento para la reconsideración. En la medida que el Solicitante desee realizar una solicitud en virtud de la Política de Divulgación de Información Documental (DIDP), el Solicitante puede hacerlo de manera independiente, de conformidad con la DIDP.95 No obstante, debería tenerse en cuenta que la información documental que el Solicitante desea fue el tema de varias solicitudes de DIDP y posteriores solicitudes de reconsideración, que el Solicitante puede considerar consultar antes de presentar otra solicitud prácticamente idéntica.96

          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.

    9. Otros temas a tratar


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

2 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).

3 Carta del Sr. Philipp Grabensee a la ICANN (https://www.icann.org/en/system/files/correspondence/grabensee-to-willett-23mar16-en.pdf. Los Solicitantes afirman que la Sra. Ohlmer también ha estado asociada a HTLD. (Véase Solicitud 16-11 § 8, en página 15. La Junta consideró esta información al aprobar las Resoluciones de 2016. Véase Fundamento de las resoluciones 2016.08.09.14 – 2016.08.09.15 (https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.h. El BAMC concluyó que la asociación anterior de la Sra. Ohlmer con HTLD, que los Solicitantes reconocen que finalizó antes del 17 de junio de 2016 (Solicitud 16-11 § 8, en página 15) no justifica la reconsideración porque no existe evidencia de que parte de la información confidencial a la que la Sra. Ohlmer (o el Sr. Krischenowski) accedió de manera impropia haya sido suministrada a HTLD o resultado en una ventaja injusta para la solicitud de HTLD en la CPE. La Junta Directiva está de acuerdo.

4 https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.h.

5 Materiales informativos en respaldo a las resoluciones 2016.08.09.14 – 2016.08.09.15, páginas 95-96 (https://www.icann.org/en/system/files/bm/briefing-materials-2-2-redacted-09aug16-en.pdf).

6 Id. en páginas 95-96.

7 Id., § 8, pág. 9.

8 Resoluciones de 2016 (https://www.icann.org/resources/board-material/resolutions-2016-03-10-en#2.a).

9 Estatutos de la ICANN, 11 de febrero de 2016, Art. IV, § 2.5.

10 Solicitud 16-11, § 8, página 12.

11 Id. (énfasis en el original).

12 Carta de Crowell y Moring a la Junta de la ICANN, con fecha de 28 de diciembre de 2016, en páginas 4-5 (https://www.icann.org/en/system/files/files/reconsideration-16-11-trs-et-al-crowell-moring-to-board-redacted-28dec16-en.pdf.

13 Id.

14 Solicitud 16-11, § 8, páginas 12-13.

15 Resoluciones de 2018 (https://www.icann.org/resources/board-material/resolutions-2018-03-15-en#2.a).

16 Informe de Alcance 1 de la firma 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).

17 Carta de Petillion al BAMC enviada el 1 de febrero de 2018, en pág. 3 (https://www.icann.org/en/system/files/files/reconsideration-16-11-trs-et-al-petillion-to-icann-bamc-redacted-01feb18-en.pdf.

18 Carta de Petillion al BAMC enviada el 1 de febrero de 2018, en pág. 3, que cita el Informe de Alcance 1 de la firma FTI, en pág. 12 (énfasis agregado).

19 Id.

20 Id., en pág. 3.

21 Ninguna disposición en los Estatutos de la ICANN, la DIDP u otro procedimiento o política exige que la ICANN elabore, en el curso de un IRP, documentos que fueron adecuadamente conservados en respuesta a una solicitud de DIDP.

22 Orden procesal N°. 3, Dot Registry LLC vs. ICANN, Caso del ICDR N°. 01-14-0001-5004 (https://www.icann.org/resources/pages/dot-registry-v-icann-2014-09-25-en.

23 Los Solicitantes tenían pleno conocimiento de las comunicaciones establecidas entre la organización de la ICANN y el panel de CPE, dado que dichas comunicaciones están expresamente contempladas en el Documento Proceso del Panel de CPE y la ICANN divulgó la existencia de dichas comunicaciones en la respuesta de DIDP de 2014. Véase Documento Proceso del Panel de CPE (https://newgtlds.icann.org/en/applicants/cpe ("La Unidad de Inteligencia de The Economist trabaja con la ICANN cuando se plantean preguntas o cuando se puede requerir información procesal adicional para evaluar una solicitud”).

24 Solicitud 16-11, § 9, página 20.

25 Informe de Alcance 2, en pág. 2 (https://www.icann.org/en/system/files/files/cpe-process-review-scope-2-cpe-criteria-analysis-13dec17-en.pdf.

26 Recomendación del BAMC sobre la Solicitud 18-6 (https://www.icann.org/en/system/files/files/reconsideration-18-6-trs-et-al-bamc-recommendation-14jun18-en.pdf.

27 Resolución 2918.07.18.09 (https://www.icann.org/resources/board-material/resolutions-2018-07-18-en#2.g.

28 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).

29 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).

30 Véase https://www.icann.org/resources/pages/reconsideration-16-11-trs-et-al-request-2016-08-25-en (se brindan enlaces a las cartas).

31 Id., que cita la carta de Grabensee a la organización de la ICANN, 18 de mayo de 2016, (https://www.icann.org/en/system/files/correspondence/grabensee-to-willett-18may16-en.pdf).

32 Véase Fundamento de las resoluciones 2016.08.09.14 – 2016.08.09.15, https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.h.

33 Id.

34 Fundamento de las resoluciones 2016.08.09.14 – 2016.08.09.15, https://www.icann.org/resources/board-material/resolutions-2016-08-09-en#2.h.

35 Véase en general, Solicitud de Reconsideración 18-9.

36 Solicitud de Reconsideración 18-9, § 7 en pág. 4.

37 Resolución de la Junta del 28 de octubre de 2011 (https://www.icann.org/resources/board-material/resolutions-2011-10-28-en#2.

38 Resolución de la Junta del 8 de diciembre de 2011 (https://www.icann.org/resources/board-material/resolutions-2011-12-08-en#1.

39 Informe Final de JAS en I (énfasis agregado) (http://dakar42.icann.org/meetings/dakar2011/presentation-jas-final-report-13sep11-en.pdf).

40 Resolución de la Junta del 28 de octubre de 2011 (https://www.icann.org/resources/board-material/resolutions-2011-10-28-en#2.

41 Resolución de la Junta del 8 de diciembre de 2011 (https://www.icann.org/resources/board-material/resolutions-2011-12-08-en#1).

42 Resolución de la Junta del 8 de diciembre de 2011 (https://www.icann.org/resources/board-material/resolutions-2011-12-08-en#1.

43 Actas de la reunión de la Junta del 28 de octubre de 2011 (énfasis agregado) (https://www.icann.org/resources/board-material/minutes-2011-10-28-en#2.

44 Solicitud de Reconsideración 18-9, § 7 en pág. 4.

45 Solicitud de Reconsideración 18-9, § 7 en pág. 4.

46 Estatutos de la ICANN, 18 de junio de 2018, Art. 1, § 1.2(b)(ii).

47 Resolución de la Junta del 12 de marzo de 2010 (https://www.icann.org/resources/board-material/resolutions-2010-03-12-en.

48 https://www.icann.org/resources/board-material/minutes-2011-10-28-en#2.

49 Correo electrónico del Solicitante a la ICANN, con fecha de 3 de diciembre de 2018, adjuntado como Anexo __ a los materiales de referencia.

50 Véase Estatutos de la ICANN, 18 de junio de 2018, Art. 4, § 4.2(q) (que establece el plazo para la presentación de refutaciones).

51 Véase https://www.icann.org/resources/pages/reconsideration-18-9-dotkids-request-2018-09-21-en.

52 Solicitud 18-9, § 2, página 1.

53 Resolución 2018.12.08.01 (https://www.icann.org/resources/board-material/resolutions-2011-12-08-en#1 (énfasis agregado)).

54 Véase los documentos Proceso y Criterios, incluidos en los materiales informativos de la Junta para la reunión de la Junta del 8 de diciembre de 2011, en páginas 81 y 87 de 164 (https://www.icann.org/en/system/files/bm/briefing-materials-3-08dec11-en.pdf.

55 Estatutos de la ICANN, 18 de junio de 2018, Art. 4, § 4.2(q).

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

57 Véase Guía, Módulo 4, § 4.2 en páginas 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.

58 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).

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

60 Id. Módulo 4, § 4.2.2.

61 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).

62 Véase Guía, Módulo 4, § 4.2.3 en páginas 4-13 (https://newgtlds.icann.org/en/applicants/agb/string-contention-procedures-04jun12-en.pdf.

63 Id. en páginas 4-12-4-13.

64 Id.

65 Informe de CPE, en pág. 3.

66 Id. en páginas 4-12.

67 Id.

68 Id.

69 Id.

70 El Solicitante afirma que el BAMC debería reevaluar la Solicitud en el curso de la formulación de una recomendación sobre la Solicitud 16-12. Véase Presentación por escrito en respaldo a la presentación oral ante el BAMC del 4 de septiembre de 2018, en pág. 1 (https://www.icann.org/en/system/files/files/reconsideration-16-12-merck-kgaa-oral-presentation-bamc-20sep18-en.pdf). La versión aplicable de los Estatutos de la ICANN instruyen al BAMC a considerar solo si la acción objetada infringe políticas o procedimientos establecidos de la ICANN y no autoriza al BAMC a realizar una revisión de novo de la Solicitud. Véase Estatutos de la ICANN, 11 de febrero de 2016, Art. IV, §§ 2.1, 2.2.

71 Véase Solicitud 16-12, § 8, páginas 7-10.

72 Informe de Alcance 2 de la Revisión del proceso de CPE, en páginas 36-37 (https://www.icann.org/en/system/files/files/cpe-process-review-scope-2-cpe-criteria-analysis-13dec17-en.pdf).

73 Id.

74 Informe de CPE de Merck & Co., Inc., pág. 4.

75 Id.

76 Solicitud, § 8, página 9.

77 Id.

78 Véase Solicitud 16-12, § 8, en páginas 7-10.

79 Véase, Guía, Módulo 4, § 4.2.3.

80 Resumen de presentación de 2017 en pág. 3 (https://www.icann.org/en/system/files/files/reconsideration-16-12-merck-kgaa-summary-bgc-presentation-31mar17-en.pdf).

81 Informe de CPE sobre .ART en pág. 5 (https://newgtlds.icann.org/sites/default/files/tlds/art/art-cpe-1-1675-51302-en.pdf); .Informe de CPE para .SPA en pág. 4 (https://newgtlds.icann.org/sites/default/files/tlds/spa/spa-cpe-1-1309-81322-en.pdf); Informe de CPE para .ECO en págs. 5-6 (https://newgtlds.icann.org/sites/default/files/tlds/eco/eco-cpe-1-912-59314-en.pdf); Informe de CPE para .RADIO en págs. 4-5 (https://newgtlds.icann.org/sites/default/files/tlds/radio/radio-cpe-1-1083-39123-en.pdf).

82 Informe de CPE en páginas 3-4.

83 Id. en páginas 4-13.

84 Id. en páginas 4-14.

85 Informe de CPE en pág. 5; véase también Guía, Módulo 4, § 4.2.3, páginas 4-14 ("La frase '. . . más allá de identificar a la comunidad' en la puntuación de 1 para 'singularidad' implica un requisito respecto del cual la cadena de caracteres identifica a la comunidad, es decir, puntuación 2 ó 3 para 'Nexo', a fin de ser elegible para una puntuación de 1 para 'Singularidad'").

86 Solicitud, § 8, página 11.

87 Solicitud 16-12, § 8, página 6.

88 Id.

89 Véase https://www.icann.org/resources/board-material/resolutions-2011-06-20-en#1. En virtud de los Estatutos en vigencia en junio de 2012, las solicitudes de reconsideración debían presentarse antes de los treinta días después de que se haya publicado la información respecto de la acción objetada de la Junta o dentro de los treinta días después de que un Solicitante supiera o debería razonablemente saber de la acción objetada del personal. Estatutos de la ICANN, 16 de marzo 2012, Art. IV, § 2.5 (https://www.icann.org/resources/pages/bylaws-2012-12-21-en#IV).

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

91 El Solicitante también ejerció este derecho cuando presentó un procedimiento de IRP respecto de las objeciones que el Solicitante y Merck & Co., Inc. presentaron uno en contra del otro en el curso de sus solicitudes controversiales para el gTLD .MERCK. Véase https://www.icann.org/en/system/files/files/irp-merck-final-declaration-11dec15-en.pdf.

92 Informe de Alcance 2, en pág. 2 (https://www.icann.org/en/system/files/files/cpe-process-review-scope-2-cpe-criteria-analysis-13dec17-en.pdf. El Solicitante considera que el Informe de Alcance 2 “no tiene significancia respecto de la solicitud de reconsideración de Merck KGaA. (Carta de Bettinger a la ICANN enviada el 12 de abril de 2018, en pág. 8). No obstante, las conclusiones del Informe de Alcance 2 son directamente relevantes al reclamo del Solicitante de que la determinación del proveedor de CPE respecto del sub-criterio 2-A-Nexo no estaba en consonancia con las determinaciones del proveedor de CPE en virtud del mismo sub-criterio para SPA, .RADIO, .ART y .ECO.

93 Carta de Bettinger a la ICANN enviada el 12 de abril de 2018, en pág. 6 (https://www.icann.org/en/system/files/files/reconsideration-16-12-merck-kgaa-supp-submission-12apr18-en.pdf). Véase también Presentación por escrito en respaldo de la presentación oral ante el BAMC del 4 de septiembre de 2018, en pág. 7 (https://www.icann.org/en/system/files/files/reconsideration-16-12-merck-kgaa-oral-presentation-bamc-20sep18-en.pdf.

94 Carta de Bettinger a la ICANN enviada el 12 de abril de 2018, en pág. 10.

95 Véase https://www.icann.org/resources/pages/didp-2012-02-25-en.

96 Véase, por ejemplo, Solicitud de DIDP 20180115-1 y respuesta a la misma (https://www.icann.org/resources/pages/didp-20180115-1-ali-request-2018-02-15-en) (Solicitud de Reconsideración denegada el 18 de julio de 2018 (https://www.icann.org/resources/board-material/resolutions-2018-07-18-en#2.c)); Solicitud de DIDP 20180110-1 y respuesta a la misma (https://www.icann.org/resources/pages/didp-20180110-1-ali-request-2018-02-12-en) (Solicitud de reconsideración denegada el 18 de julio de 2018 (https://www.icann.org/resources/board-material/resolutions-2018-07-18-en#2.b)).