Source: https://www.icann.org/resources/board-material/resolutions-2017-10-29-es
Timestamp: 2020-06-01 06:32:31+00:00

Document:
Este documento ha sido traducido a varios idiomas a título informativo únicamente. El texto original y autoritativo (en inglés) se puede obtener en: https://www.icann.org/resources/board-material/resolutions-2017-10-29-en
Considerar la Solicitud de Reconsideración 17-4:
Fundamento de la resolución 2017.10.29.01
Solicitud de Información nueva o adicional del Comité Asesor Gubernamental a: Asesoramiento sobre las solicitudes de Amazon
Fundamento de las resoluciones 2017.10.29.02 – 2017.10.29.03
Solicitud para postergar la aplicación de cumplimiento de la Política de consenso del WHOIS amplio por 180 días
Fundamento de la resolución 2017.10.29.04
Ajuste de la revisión de similitud de cadena de caracteres en el Proceso de Avance Acelerado de Dominios de Alto Nivel con Código de País dentro de Nombres de Dominio Internacionalizados (IDN ccTLD)
Fundamento de las resoluciones 2017.10.29.05 – 2017.10.29.06
Visto y considerando: Que dotgay LLC y DotMusic Limited (los Solicitantes) presentaron la Solicitud de Reconsideración 17-4 (Solicitud 17-4) mediante la cual se impugna la respuesta de la organización de la ICANN a la solicitud de documentos sobre la revisión del proceso de la Evaluación con prioridad de la Comunidad (CPE) presentada por los Solicitantes, conforme a la Política de Divulgación de Información Documental de la ICANN.
Visto y considerando: Que el Comité de Mecanismos de Responsabilidad de la Junta Directiva (BAMC) había determinado con anterioridad que la Solicitud 17-4 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, Secciones 4.2(j) y (k) de los Estatutos de la ICANN.
Visto y considerando: Que el BAMC ha analizado los fundamentos de la Solicitud 17-4 y todos los materiales pertinentes y ha sugerido la denegación de la Solicitud 17-4 en virtud de que esta no expone una base de reconsideración adecuada. La Junta Directiva se manifestó de acuerdo.
Visto y considerando: Que la Junta Directiva también consideró la refutación de los Solicitantes a la Recomendación del BAMC sobre la Solicitud 17-4, a lo que concluye que la refutación no proporciona argumentos ni evidencia adicionales para fundamentar la reconsideración.
Resuélvase (2017.10.29.01): La Junta Directiva adopta la Recomendación del BAMC sobre la Solicitud 17-4 [PDF, 273 KB].
Los Solicitantes dotgay LLC (dotgay) y DotMusic Limited (DotMusic) enviaron solicitudes presentadas por una comunidad para .GAY y .MUSIC, respectivamente; las dos solicitudes participaron en la evaluación con prioridad de la comunidad (CPE) y ninguna prevaleció. En octubre de 2015, dotgay solicitó la reconsideración del resultado de la CPE (Solicitud 15-21),1 que el Comité de Gobernanza de la Junta Directiva (BGC)2 rechazó.3 En febrero de 2016, dotgay solicitó la reconsideración del rechazó del BGC a la Solicitud 15-21 (véase Solicitud 16-3).4 En febrero de 2016, DotMusic solicitó la reconsideración de la determinación de la CPE y la aprobación de la solicitud de DotMusic (Solicitud 16-5).5
Posteriormente, la Junta Directiva de la ICANN impartió instrucciones para que el Presidente y Director Ejecutivo, o la persona que él designe, lleve a cabo una revisión del proceso mediante el cual la organización de la ICANN ha interactuado con el proveedor de CPE (Revisión del proceso de CPE). El BGC luego decidió que la Revisión del proceso de CPE también debía incluir los materiales de referencia consultados por el proveedor de CPE para las evaluaciones, que son el tema de las Solicitudes de Reconsideración pendientes en relación con el CPE. El BGC colocó en espera ocho solicitudes de reconsideración pendientes en relación con el CPE, incluidas las Solicitudes 16-3 y 16-5, cuya finalización de la Revisión del proceso de CPE aún está pendiente.
El 10 de junio de 2017, los Solicitantes enviaron una Solicitud de Política de Divulgación de Información Documental Conjunta (DIDP) para pedir documentos e información relacionada con la Revisión del Proceso de CPE, algo que los Solicitantes ya habían pedido en solicitudes de DIDP anteriores. (Véase Solicitud de DIDP Conjunta, que se encuentra adjunta como Anexo E en el Material de referencia.) En su respuesta (Respuesta a la Solicitud de DIDP Conjunta, que se adjunta como Anexo E en el Material de referencia), la organización de la ICANN explicó que, a excepción de determinados documentos que estaban sujetos a las Condiciones de No Divulgación de la DIDP (Condiciones de no divulgación), todos los demás documentos en respuesta se han publicado e identificado en relación con las anteriores solicitudes de DIDP de los Solicitantes.6 (Véase Id.). La respuesta a la Solicitud de DIDP Conjunta incluyó los hipervínculos a las respuestas de las solicitudes de DIDP anteriores, que en su momento identificaron e incluyeron los hipervínculos a los documentos en respuesta disponibles al público. (Véase Id. en página 2). En la respuesta a la Solicitud de DIDP Conjunta también se expresó que en dos puntos (Puntos 2 y 4) no se solicitaba documentación existente en la ICANN. (Véase Id.) Asimismo, en la respuesta a la Solicitud de DIDP Conjunta se explicó que la organización de la ICANN evaluó los documentos en respuesta sujetos a las Condiciones de No Divulgación para determinar si el interés público en su divulgación tenía más peso que el daño que pudiera ocasionar la divulgación y determinó que no había motivos para creer que el interés público en la divulgación de la información superaría el daño que pudiera ocasionar la divulgación de los documentos. (Véase Id. en página 3).
Los Solicitantes presentaron la Solicitud de Reconsideración 17-4 (Solicitud 17-4) impugnado la respuesta a la Solicitud de DIDP Conjunta. (Véase Solicitud 17-4, que se encuentra adjunta como Anexo A en el Material de referencia). Los Solicitantes sugieren que la reconsideración de la respuesta a la Solicitud de DIDP Conjunta está garantizada porque la organización de la ICANN violó los Valores Fundamentales de la ICANN, las políticas establecidas del DIDP y los Estatutos referentes al trato no discriminatorio, la transparencia y la responsabilidad. (Véase Id. en §8, página 21).
El BAMC consideró la Solicitud 17-4 y todo el material pertinente y recomendó a la Junta Directiva que rechace la Solicitud 17-4 porque no expone una base de reconsideración adecuada para los motivos presentados en la Recomendación del BAMC sobre la Solicitud de Reconsideración 17-4 (la Recomendación del BAMC), que se consideró e incorporó en el presente documento. (Véase Recomendación del BAMC [PDF, 273 KB], que se encuentra adjunta como Anexo D en el Material de referencia).
El 26 de octubre de 2017, los Solicitantes presentaron una refutación a la Recomendación del BAMC (Refutación), conforme al Artículo 4, Sección 4.2(q) de los Estatutos de la ICANN. (Véase Refutación, que se encuentra adjunta como Anexo G en el Material de referencia). A continuación se describen las sugerencias de los Solicitantes: (1) La Solicitud 17-4 estaba dentro del alcance del proceso de reconsideración porque "[e]l proceso de reconsideración permite la revisión de una acción o inacción, no solo del proceso para adoptar acciones"; (2) "[e]l DIDP se relaciona con los compromisos y valores fundamentales de la [organización] de la ICANN, que requiere transparencia"; y (3) la organización de la ICANN violó su compromiso con la transparencia, la responsabilidad y la equidad en la respuesta a la Solicitud de DIDP Conjunta. (Véase Id.).
Todos los antecedentes de hechos se describen en la Recomendación del BAMC [PDF, 273 KB], que fue revisada y considerada por la Junta Directiva y se ha incorporado al presente documento.
El 11 de octubre de 2017, el BAMC sugirió el rechazo de la Solicitud 17-4 en virtud de que dicha solicitud no exponía fundamentos adecuados para la reconsideración de los motivos presentados en la Recomendación del BAMC [PDF, 273 KB]. La Junta Directiva consideró la Recomendación del BAMC y se la ha incorporado al presente documento.
El 26 de octubre de 2017, los Solicitantes presentaron una refutación a la Recomendación del BAMC, conforme al Artículo 4, Sección 4.2(q) de los Estatutos de la ICANN, que también estuvieron bajo consideración de la Junta Directiva.
Las cuestiones presentadas para reconsideración son7:
Si la organización de la ICANN cumplió con las políticas establecidas de la ICANN al responder a la Solicitud de DIDP Conjunta.
Si la organización de la ICANN cumplió con sus Valores Fundamentales, la Misión y los Compromisos al responder a la Solicitud de DIDP Conjunta.
El Artículo 4, Secciones 4.2(a) y (c) de los Estatutos de la ICANN expresa claramente que todas las entidades deben presentar una solicitud "para reconsideración o revisión de una acción o inacción de la ICANN siempre que se haya visto afectado negativamente por:
Una o más acciones o inacciones de la Junta Directiva o el Personal de la ICANN que se hubiesen tomado o denegado sin la consideración de información significativa, salvo cuando el Solicitante hubiese podido presentar la información para la consideración de la Junta Directiva o el Personal en el momento de la acción o denegación de actuar y no la hubiese presentado; o
(Estatutos de la ICANN, 22 de julio de 2017, Art. 4, §§ 4.2(a), (c)). Conforme al Artículo 4, Sección 4.2(k) de los Estatutos, si el BAMC determina que la Solicitud se ha fundamentado suficientemente, esta se enviará al Defensor del Pueblo para su revisión y consideración. (Véase Id. en § 4.2(l)). Si el Defensor del Pueblo se recusa de la cuestión, el BAMC revisará la Solicitud sin la participación del Defensor del Pueblo y presentará sus recomendaciones ante la Junta Directiva. (Véase Id. en § 4.2(l)(iii)). El Solicitante puede presentar una refutación a la recomendación del BAMC, siempre que la refutación: (i) "esté limitada a refutar o contradecir las cuestiones planteadas en la recomendación del BAMC; y (ii) no ofrezca nueva evidencia para respaldar un argumento realizado en la Solicitud de Reconsideración original del Solicitante que el Solicitante podría haber proporcionado cuando inicialmente presentó dicha solicitud". (Véase Id. en § 4.2(q)). La denegación de una solicitud de reconsideración de la acción o inacción de la ICANN es adecuada si el BAMC lo recomienda y la Junta Directiva determina que la parte solicitante no satisface los criterios de reconsideración que establecen los Estatutos. (Véase Id. en § 4.2(e)(vi), (q), (r)).
La Junta Directiva ha revisado y considerado detenidamente la Solicitud 17-4 y todo el material pertinente, incluida la Recomendación del BAMC. La Junta Directiva determina que el análisis presente en la Recomendación del BAMC [PDF, 273 KB], está bien fundado. La Junta Directiva también consideró la Refutación de los Solicitantes a la Recomendación del BAMC. La Junta Directiva determina que la Refutación no presenta argumentos ni hechos que respaldan la reconsideración.
La organización de la ICANN adhirió a las políticas y procedimientos establecidos al responder a la Solicitud de DIDP Conjunta.
El BAMC concluyó, y la Junta Directiva aceptó, que la respuesta a la Solicitud de DIDP Conjunta cumplió con las políticas y procedimientos aplicables. (Recomendación del BAMC [PDF, 273 KB], páginas 16-27). En respuesta a la solicitud de documentos presentados conforme a la DIDP, la organización de la ICANN adhiere al "Proceso para responder a las Solicitudes de Política de Divulgación de Información Documental (DIDP) de la ICANN" (Proceso de respuesta de DIDP). (Véase Proceso de respuesta de DIDP [PDF, 59 KB]). El Proceso de respuesta de DIDP establece que "[d]espués de recibir una Solicitud de DIDP, el personal de la ICANN realiza una revisión de la Solicitud e identifica la documentación solicitada. . .. entrevistas . . . los miembros del personal correspondiente y lleva a cabo una búsqueda detenida de los documentos que responden a la Solicitud de DIDP". (Id.) Una vez que se revisa la capacidad de respuesta de los documentos reunidos, se procede con la revisión para determinar si los documentos que responden a la Solicitud están sujetos a alguna de las Condiciones de No Divulgación detalladas en la página web de DIDP en https://www.icann.org/resources/pages/didp-2012-02-25-en. De ser así, se realiza otra revisión para determinar si, bajo determinadas circunstancias, el interés público en la divulgación de la documentación superaría el daño que la divulgación podría ocasionar. (Véase Proceso de respuesta de DIDP [PDF, 59 KB]).
De acuerdo con el Proceso de Respuesta de DIDP, en la respuesta a la Solicitud de DIDP Conjunta se explicó que, a excepción de determinados documentos que están sujetos a las Condiciones de No Divulgación, se han publicado e identificado todos los demás documentos con capacidad de respuesta en la respuesta a las anteriores solicitudes de DIDP de los Solicitantes. (Véase Respuesta a la Solicitud de DIDP Conjunta [PDF, 214 KB], página 2). Para los Puntos 1 y 3, la organización de la ICANN determinó que ya se habían publicado todos los documentos en respuesta en el sitio web de la ICANN y que ya se los había proporcionado a los Solicitantes en respuesta a las anteriores solicitudes de DIDP. (Véase Id. en 2). En los hipervínculos a los 21 documentos públicos disponibles y a los sitios web que compilan documentación en respuesta a los Puntos 1 y 3, se han identificado y proporcionado las respuestas de la DIDP a dichas solicitudes. (Véase Id.) En la respuesta a la Solicitud de DIDP Conjunta también se expresó que en dos puntos (Puntos 2 y 4) no se solicitaba documentación existente en la ICANN. (Véase Id.) A pesar de este requisito, la organización de la ICANN suministró información significativa en respuesta a los Puntos 2 y 4 en la Actualización de estado y en una actualización temprana de la Revisión del proceso de CPE, además de proporcionar los hipervínculos a esas actualizaciones. (Véase Id. en 2-3). Asimismo, en la respuesta a la Solicitud de DIDP Conjunta se explicó que algunos de los documentos en respuesta a los Puntos 2 y 4 estaban sujetos a ciertas Condiciones de No Divulgación identificadas. (Véase Id.) En la respuesta a la Solicitud de DIDP Conjunta también se explicó que la organización de la ICANN evaluó los documentos en respuesta sujetos a las Condiciones de No Divulgación, como se requería, y determinó que no había motivos para creer que el interés público en la divulgación de la información superaría el daño que pudiera ocasionar la divulgación de los documentos. (Véase Id. en 3).
Los Solicitantes sugieren que la reconsideración está garantizada porque la organización de la ICANN violó los Valores Fundamentales de la ICANN y las políticas establecidas en la DIDP y los Estatutos referentes al trato no discriminatorio, la transparencia y la responsabilidad en su respuesta a los Puntos 1 a 4. (Véase Solicitud 17-4, § 8, página 21). Además, los Solicitantes sugieren que la determinación de la organización de la ICANN acerca de la aplicabilidad de las Condiciones de No Divulgación especificadas en respuesta a los Puntos 2 y 4 garantiza la reconsideración ya que la divulgación de los documentos "es en pos del interés público". (Id. en § 8, página 22).
El BAMC determinó, y la Junta Directiva acepta, que la posición de los Solicitantes carece de fundamentos dado que la organización de la ICANN sí adhirió a las políticas y procedimientos establecidos al responder a la Solicitud de DIDP. (Véase Recomendación del BAMC [PDF, 273 KB], páginas 16-27). Los Solicitantes no reclaman que la respuesta a la Solicitud de DIDP Conjunta sea contraria al Proceso de Respuesta de DIDP, así como tampoco proporcionan evidencia que demuestre que la Respuesta a la Solicitud de DIDP Conjunta de la organización de la ICANN viola la Misión, los Compromisos y los Valores Fundamentales de la ICANN. (Véase Id.) El BAMC también concluyó, y la Junta Directiva acordó, que la organización de la ICANN cumplió con el Proceso de DIDP en la evaluación de los documentos en respuesta sujetos a las Condiciones de No Divulgación, como se requería, y determinó que no había motivos para creer que el interés público en la divulgación de la información superaría el daño que pudiera ocasionar la divulgación de los documentos. (Véase Id. en 21-26). Si bien los Solicitantes pueden creer que la organización de la ICANN debería haber aplicado su criterio de otra manera, esto no representa un motivo suficiente para la reconsideración.
Las Referencias infundadas de los Solicitantes a los Compromisos y Valores Fundamentales de la ICANN no sustentan la reconsideración de la respuesta a la Solicitud de DIDP Conjunta.
Los Solicitantes sugieren que la organización de la ICANN violó los siguientes Compromisos y Valores Fundamentales en su respuesta a la Solicitud de DIDP Conjunta: Artículo 1, Secciones 1.2(a), 1.2(a)(v), 1.2(a)(vi) y Artículo 3, Sección 3.1 de los Estatutos de la ICANN. (Véase Solicitud 17-4, § 6, páginas 5-7). No obstante, el BAMC concluyó, y la Junta Directiva acordó, que en la Solicitud 17-4 los Solicitantes no explicaron cómo se relacionan los Compromisos y Valores Fundamentales con la respuesta a la Solicitud de DIDP Conjunta en cuestión ni cómo la organización de la ICANN podría haber violado estos Compromisos y Valores Fundamentales. (Véase Recomendación del BAMC [PDF, 273 KB], páginas 26-27). Por lo tanto, los Solicitantes no han fundamentado la reconsideración en su lista de Compromisos y Valores Fundamentales.
La Junta Directiva ha considerado la Refutación de los Solicitantes y determina que los Solicitantes no han prestado argumentos ni hechos adicionales que respalden la reconsideración.
En la refutación se reclama lo siguiente: (1) La Solicitud 17-4 estaba dentro del alcance del proceso de reconsideración porque "[e]l proceso de reconsideración permite la revisión de una acción o inacción, no solo del proceso para adoptar acciones"; (2) "[e]l DIDP se relaciona con los compromisos y valores fundamentales de la [organización] de la ICANN, que requiere transparencia"; y (3) la organización de la ICANN violó su compromiso con la transparencia, la responsabilidad y la equidad en la respuesta a la Solicitud de DIDP Conjunta. (Véase Refutación).
Con respecto al primer reclamo, la Junta Directiva ha considerado la Solicitud 17-4 y toda la documentación pertinente, la Recomendación del BAMC y la Refutación y determina que la reconsideración no está garantizada. El proceso de Solicitud de Reconsideración es un medio para que los solicitantes busquen la reconsideración de "la acción o inacción de la organización de la ICANN siempre que el solicitante se haya visto afectado negativamente por … [u]na o varias acciones o inacciones de la Junta Directiva o del Personal que contradigan la Misión, los Compromisos, los Valores Fundamentales o las políticas establecidas de la ICANN". (Estatutos de la ICANN, Art. 4, Sección 4.2(c)(i)). La reconsideración es adecuada si el Solicitante demuestra que la acción o inacción contradice "la Misión, los Compromisos, los Valores Fundamentales o las políticas establecidas de la ICANN". (Id.; véase también, por ejemplo, Determinación de la Junta Directiva sobre la Solicitud 17-3, https://www.icann.org/resources/board-material/resolutions-2017-09-23-en#2.b; Determinación de la Junta Directiva sobre la Solicitud 17-1, https://www.icann.org/resources/board-material/resolutions-2017-06-24-en#2.d.)8 Una Solicitud de Reconsideración que impugna el resultado de la acción o inacción de la organización de la ICANN sin evidencia que la respalde aparte de la inconformidad del solicitante con el resultado no cumple con las normas de reconsideración. De forma similar, una Solicitud de Reconsideración que no explique la manera en que la acción o inacción impugnada contradice la Misión, los Compromisos, los Valores Fundamentales o las políticas establecidas de la ICANN, no puede justificar una reconsideración.
Los Solicitantes establecen que "las solicitudes de reconsideración proporcionan una oportunidad para volver a evaluar una acción o inacción". (Refutación, página 3). Esto es precisamente lo ocurrido. En efecto, e independientemente de la imposibilidad de los Solicitantes para demostrar que las acciones o inacciones de la organización de la ICANN violaron la Misión, los Compromisos, los Valores Fundamentales o las políticas establecidas de la ICANN, el BAMC evaluó la respuesta a la Solicitud de DIDP Conjunta para determinar si la mencionada violación tuvo lugar. El BAMC concluyó, y la Junta Directiva aceptó, que la acción de la organización de la ICANN en la respuesta fue coherente con la Misión, los Compromisos, los Valores Fundamentales y las políticas establecidas. (Recomendación del BAMC, páginas 16-27).
En segundo lugar, los Solicitantes argumentaron que "la ICANN debe cumplir con sus Compromisos y Valores Fundamentales durante la DIDP" ya que esta "se relaciona claramente con los Compromisos y Valores Fundamentales". (Refutación, páginas 4-5). Sin embargo, la respuesta a la Solicitud de DIDP Conjunta sí cumplió con los Compromisos y los Valores Fundamentales de la organización de la ICANN. La DIDP implementa los Compromisos y los Valores Fundamentales de la ICANN para respaldar la transparencia y la responsabilidad mediante un procedimiento por el cual los documentos relacionados con las operaciones de la organización de la ICANN y bajo posesión, custodia o control de dicha organización se ponen a disponibilidad del público, a menos que existan motivos de confidencialidad convincentes. (Véase DIDP, https://www.icann.org/resources/pages/didp-2012-02-25-en). Sin embargo, ni la DIDP ni los Compromisos y Valores Fundamentales de la organización de la ICANN que respaldan la transparencia y la responsabilidad obligan a la organización de la ICANN a hacer públicos todos los documentos que se encuentren en su posesión. Como señaló anteriormente este año el Panel en el Panel del Proceso de Revisión Independiente de Amazon EU S.A.R.L. contra la ICANN:
[I]ndependientemente del compromiso de la ICANN con la transparencia, tanto en los Estatutos como en las Prácticas de Publicación de la ICANN se reconoce que hay situaciones en las que la información no pública, por ejemplo, comunicaciones internas del personal relacionadas con los procesos deliberativos de la ICANN, . puede contener información que debe protegerse contra la divulgación.
(Amazon EU S.A.R.L. contra la ICANN, ICDR Caso N.° 01-16-000-7056, Orden Procedimental (7 de junio de 2017), en página 3.) Los Estatutos de la organización de la ICANN tratan la necesidad de que exista un equilibrio entre los intereses contrapuestos, como la transparencia y la privacidad, y destacan que "en toda situación en la que un Valor Fundamental deba equilibrarse con otro, posiblemente un Valor Fundamental que compita, el resultado del equilibrio debe cumplir con una política desarrollada mediante el proceso ascendente de múltiples partes interesadas o, de cualquier otro modo, debe cumplir de la mejor manera con la Misión de la ICANN". (Estatutos de la ICANN, Art. I, Sección 1.2(c)). La DIDP describe una prueba para equilibrar las inquietudes de privacidad, como el privilegio y la protección de los procesos deliberativos, que respalda los Valores Fundamentales de la organización de la ICANN para operar con eficiencia y excelencia y, a la vez, "esforzarse por lograr un equilibrio razonable entre los intereses de las distintas partes interesadas y evitar la captura" en contra del Valor Fundamental de transparencia. (Id. en las Secciones 1.2(b)(v) y 1.2(b)(vii).) De conformidad, la organización de la ICANN puede aplicar su criterio de forma adecuada, conforme a la DIDP, para establecer que ciertos documentos no son adecuados para divulgación, sin infringir su compromiso con la transparencia.
En tercer lugar, los Solicitantes reclaman que la respuesta a la Solicitud de DIDP Conjunta contradecía los Compromisos y los Valores Fundamentales de la ICANN que respaldan la transparencia, la equidad y la responsabilidad. (Refutación, páginas 9-10). La Junta Directiva determina que estos argumentos carecen de fundamento.
En lo que respecta al compromiso de la ICANN con la transparencia, los Solicitantes sugieren que la organización de la ICANN debería haber divulgado todos los documentos solicitados o, al menos haber "identific[ado] los documentos sujetos a las Condiciones de [No Divulgación] y explic[ado] cómo se aplican las Condiciones de No Divulgación". (Id. en página. 6). Como se analizó anteriormente, la organización de la ICANN adhirió a las políticas y procedimientos establecidos, incluido el compromiso de la ICANN con la transparencia, al determinar que algunos de los documentos solicitados estaban sujetos a las Condiciones de No Divulgación. Además, la Junta Directiva explica que la respuesta al Proceso de Solicitud de DIDP Conjunta no requiere que la organización de la ICANN identifique la Condición de No Divulgación aplicable a cada documento individual retenido. En efecto, un requerimiento de este tipo podría representar una carga indebida para la ICANN. Aquí, el BAMC dio una explicación más que suficiente acerca de cómo se aplican las Condiciones de No Divulgación a los documentos que la organización de la ICANN considera no adecuados para divulgación. En términos más específicos, de acuerdo con la respuesta al Proceso de Solicitud de DIDP Conjunta, el BAMC explicó que el material solicitado contenía versiones preliminares internas, que podían comprometer la integridad de los procesos deliberativos y de toma de decisiones en relación con la Revisión del Proceso de CPE, y que el material estaba sujeto a privilegios de abogado-cliente, entre otros. (Recomendación del BAMC, páginas 23-24). Por último, los Solicitantes no han demostrado que la organización de la ICANN no siguió la DIDP o que la respuesta a la Solicitud de DIDP Conjunta contradice los Compromisos y los Valores Fundamentales de la ICANN que respaldan la transparencia, la equidad y la responsabilidad.
Los Solicitantes también sugieren que los Compromisos y los Valores Fundamentales de la ICANN que respaldan la transparencia y la equidad exigen que la organización de la ICANN divulgue el material solicitado aunque se apliquen algunas Condiciones de No Divulgación porque el Proceso de Revisión de CPE es "importante para los Solicitantes" y otros, porque "[e]l público está claramente interesado" en los documentos solicitados y porque los Solicitantes sospechan "que no hay daño en la divulgación de [los] documentos". (Refutación, páginas 6-8). El "interés público" no está determinado porque una entidad esté "interesada" en una cuestión, sino porque una acción se realice en pos del "interés público" general. Por otro lado, la DIDP concede a la organización de la ICANN el criterio para decidir si "bajo determinadas circunstancias, . . . el interés público en la divulgación de la información supera el daño que podría ocasionar dicha divulgación". (Página web de la DIDP, https://www.icann.org/resources/pages/didp-2012-02-25-en.)
Como se explicó en la respuesta a la Solicitud de DIDP Conjunta, la organización de la ICANN evaluó los documentos que estaban sujetos a las Condiciones de No Divulgación para determinar si el interés público (incluidas las inquietudes de transparencia y equidad) en su divulgación superaría el daño que podría ocasionar dicha acción y concluyó que el interés público no garantizaba el daño que se ocasionaría con la divulgación, dadas estas circunstancias. (Véase Respuesta a la Solicitud de DIDP Conjunta, páginas 2-3). Como se mencionó antes, los Solicitantes creen que la organización de la ICANN debería haber aplicado su criterio de forma diferente, pero esto no es un fundamento válido para la reconsideración, ya que los Solicitantes no han podido demostrar que la organización de la ICANN infringió la DIDP.
Los Solicitantes también sugieren que la ICANN "ha cerrado la posibilidad de obtener información adicional [acerca de la Revisión del Proceso de CPE] en una clara contradicción con su propio Compromiso y Valor Fundamental con la transparencia". (Refutación, página 7). De forma similar, los Solicitantes sugieren que la organización de la ICANN "ha restringido . . el acceso a la información sobre la [Revisión del Proceso de CPE] en un decisión claramente injusta que aleja a las partes afectadas de la información y genera varias alertas sobre la integridad de la propia revisión independiente" y que "la ICANN ha prohibido la participación informada de la Comunidad de Internet en la [Revisión del Proceso de CPE]". (Id. en páginas 9-10). La Junta Directiva señala que el BGC y la organización de la ICANN proporcionaron varias actualizaciones sobre la Revisión del Proceso de CPE, incluida una el 1.° de septiembre de 2017. (https://www.icann.org/news/announcement-2017-09-01-en.) Además, como se indicó en la actualización del 1.° de septiembre de 2017, la Revisión del Proceso de CPE sigue en curso. Cuando la Revisión del Proceso de CPE finalice, se pondrá a disposición de la comunidad de la ICANN, incluidos los Solicitantes, más información adicional.
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.
Visto y considerando: Que la Declaración Final en el Proceso de Revisión Independiente (IRP) del caso Amazon EU S.A.R.L. (Amazon) contra la ICANN se emitió el 11 de julio de 2017.
Visto y considerando: Que en la Declaración Final, el Panel recomienda que la Junta Directiva "reevalúe con prontitud las solicitudes de Amazon" y "formule un juicio objetivo e independiente con respecto a si existen, de hecho, razones fundadas de políticas públicas basadas en méritos para denegar las solicitudes de Amazon". (Declaración Final, ¶ 125).
Visto y considerando: Que, conforme el Artículo IV, Sección 3.21 de la versión aplicable de los Estatutos, la Junta Directiva consideró la Declaración Final en su reunión del 23 de septiembre de 2017 y determinó la necesidad de seguir considerando la recomendación no vinculante del Panel que señala que la Junta Directiva "reevalúe con prontitud las solicitudes de Amazon" y "formule un juicio objetivo e independiente sobre si existen, de hecho, razones fundadas de políticas públicas basadas​en méritos para denegar las solicitudes de Amazon".
Visto y considerando: Que la Junta Directiva solicitó al Comité de Mecanismos de Responsabilidad de la Junta Directiva (BAMC) que revise y considere la recomendación del Panel que señala que la Junta Directiva "reevalúe con prontitud las solicitudes de Amazon" y "formule un juicio objetivo e independiente sobre si existen, de hecho, razones fundadas de políticas públicas basadas​en méritos para denegar las solicitudes de Amazon", y que proporcione opciones para que la Junta Directiva las considere al abordar la recomendación del Panel.
Visto y considerando: Que el BAMC ha recomendado que la Junta Directiva solicite al Comité Asesor Gubernamental (GAC): (i) si tiene información para proporcionar a la Junta Directiva sobre las "razones fundadas de políticas públicas basadas​en méritos", en relación con el asesoramiento del GAC para que las solicitudes de Amazon no sigan adelante; o (ii) si tiene información nueva o adicional para proporcionar a la Junta Directiva sobre el asesoramiento del GAC para que las solicitudes de Amazon no sigan adelante.
Resuélvase (2017.10.29.02): La Junta Directiva consulta al GAC si tiene: (i) si tiene información para proporcionar a la Junta Directiva sobre las "razones fundadas de políticas públicas basadas​en méritos", en relación con el asesoramiento del GAC para que las solicitudes de Amazon no sigan adelante; o (ii) si tiene información nueva o adicional para proporcionar a la Junta Directiva sobre el asesoramiento del GAC para que las solicitudes de Amazon no sigan adelante.
Resuélvase (2017.10.29.03): Que la Junta Directiva pregunta al GAC si tiene información nueva o adicional (como se solicitó anteriormente) para proporcionar a la Junta Directiva. Esto se llevará a cabo al cierre de la Reunión N.° 61 de la ICANN, programada para los días 10 a 15 de marzo de 2018, a fin de colaborar con la adecuada y pronta consideración de la Junta Directiva.
Amazon EU S.A.R.L. (Amazon) inició un Proceso de Revisión Independiente (IRP) por el cual se impugnaba la decisión tomada por el Comité para el Programa de Nuevos gTLD (NGPC) el 14 de mayo de 2014 para aceptar el asesoramiento consensuado del Comité Asesor Gubernamental (GAC) que negaba la continuación de las solicitudes de Amazon. (Resolución 2014.05.14.NG03, disponible en https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-05-14-en#2.b.)
Amazon solicitó el dominio .AMAZON y sus caracteres equivalentes en chino y japonés (Solicitudes de Amazon), que habían pasaron la evaluación inicial (véase https://newgtlds.icann.org/sites/default/files/ier/bqe3so7p3lu2ia8ouwp7eph9/ie-1-1315-58086-en.pdf [PDF, 46 KB]). En respuesta a las Solicitudes de Amazon, los gobiernos de Brasil y de Perú, con el aval de Bolivia, Ecuador y Guyana, presentaron una Advertencia Temprana por medio del GAC, de acuerdo con la Guía para el Solicitante, en la que declaraban que: "el [o]torgamiento de derechos exclusivos para este gTLD específico a una empresa privada, evitaría el uso de este dominio para fines de interés público relacionados con la protección, la promoción y la concientización sobre las cuestiones relacionadas con el bioma amazónico. También dificultaría la posibilidad de utilizar dicho dominio para congregar a páginas web relacionadas con la población que habita en esa región geográfica". (Advertencia Temprana, disponible en https://gacweb.icann.org/display/gacweb/GAC+Early+Warnings?preview=/27131927/27197938/Amazon-BR-PE-58086.pdf [PDF, 79 KB]).
Después de indicar en su Comunicado pronunciado en Pekín (abril de 2013) que las Solicitudes de Amazon requerían mayor consideración de su parte, el GAC proporcionó asesoramiento consensuado (Asesoramiento del GAC) a la Junta Directiva de la ICANN en el Comunicado pronunciado en Durban (18 de julio de 2013) en el que determinada que las Solicitudes de Amazon no debían seguir adelante (https://gacweb.icann.org/display/GACADV/2013-07-18-Obj-Amazon).
El 14 de mayo de 2014, la Junta Directiva (representada por el NGPC) aceptó el Asesoramiento del GAC e instruyó a la ICANN a no seguir adelante con las Solicitudes de Amazon. (Resolución 2014.05.14.NG03, disponible en https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-05-14-en#2.b.) La decisión del NGPC se tomó sin perjuicio de la continuidad de los esfuerzos por parte de Amazon y los miembros del GAC para proseguir el diálogo sobre las cuestiones pertinentes.
En marzo de 2016, Amazon inició una revisión independiente de la Resolución 2014.05.14.NG03 emitida por la Junta Directiva de la ICANN en la que se indicaba que las Solicitudes de Amazon no debían seguir adelante.
El 11 de julio de 2017, el Panel de Revisión Independiente (Panel) emitió su Declaración Final en el Proceso de Revisión Independiente de Amazon (https://www.icann.org/en/system/files/files/irp-amazon-final-declaration-11jul17-en.pdf [PDF, 294 KB]). La versión completa de las decisiones y recomendaciones del Panel que se resumen a continuación está disponible en https://www.icann.org/resources/pages/irp-amazon-v-icann-2016-03-04-en.
En una decisión 2 a 1, el Panel declaró que Amazon es la parte que prevalece y determinó que la "Junta Directiva, actuando a través el NGPC, actuó se manera inconsistente con sus Artículos, Estatutos y Guía para el Solicitante ya que, […] dando deferencia absoluta al asesoramiento consensuado del [GAC] acerca de la existencia de un interés de política pública válido y basado en méritos que respaldaran el asesoramiento, el NGPC incumplió en su deber de evaluar de forma independiente y determinar si existían intereses de política pública válidos y basados​en méritos que respaldaran el asesoramiento consensuado del GAC". (Declaración Final, ¶ 2). El Panel también declaró que "la ICANN asumirá los costos de esta IRP, así como el costo del proveedor de IRP" y "reembolsará a Amazon la suma de $ 163 045,51 dólares estadounidenses". (Declaración Final, ¶ 126).
Asimismo, el Panel recomienda que la Junta Directiva "reevalúe con prontitud las solicitudes de Amazon" y "formule un juicio objetivo e independiente con respecto a si existen, de hecho, razones fundadas de políticas públicas basadas en méritos para denegar las solicitudes de Amazon". Si la Junta Directiva determina que las Solicitudes de Amazon no deben seguir adelante, el Panel indica que "la Junta Directiva debe explicar los motivos que fundamentan esa decisión". El "asesoramiento consensuado del GAC, por sí mismo, no puede reemplazar la decisión independiente y objetiva de la Junta Directiva con un análisis detallado". (Declaración Final, ¶ 125). Ante la posibilidad de que la Junta Directiva determinara que las Solicitudes de Amazon deben seguir adelante, el Panel recomienda que la ICANN se "reúna y consulte con el GAC" "dentro de los sesenta (60) días posteriores a la emisión de esta Declaración Final". (Declaración Final, ¶ 125). En sus conclusiones, el Panel declaró que "de acuerdo con los hechos de este IRP, la mínima obligación de equidad procesal que se aplica al GAC exige que este permita la presentación de una declaración o comentario por escrito de una parte que se viera afectada negativamente, antes de decidir dar su asesoramiento consensuado para objetar una solicitud[; y que la] obligación de la Junta Directiva era observar que el GAC, como organismo constitutivo de la ICANN, tuviera un procedimiento de este tenor y que lo respetara". (Declaración Final, ¶ 94).
El Panel también concluyó que "si bien no deben darse motivos ni fundamentos, el asesoramiento consensuado del GAC debe basarse en una inquietud de interés público bien fundada y este fundamento de interés público debe estar determinado o ser determinable en la totalidad del registro ante el NGPC". (Declaración Final, ¶ 103). De acuerdo con el Panel, "el NGPC aplazó el asesoramiento consensuado del GAC acerca de la existencia de una inquietud de política pública válida y, al hacerlo, abandonó su obligación bajo los documentos de gobernanza de la ICANN para tomar una decisión objetiva, independiente y basada en méritos sobre la continuación o no de las solicitudes". El Panel también señaló que "[a]l no poder evaluar y articular en forma independiente la existencia de razones de política pública bien fundadas para el asesoramiento del GAC, el NGPC en efecto, generó una presunción concluyente o irrefutable para el asesoramiento consensuado del GAC". (Declaración Final, ¶ 116).
Conforme el Artículo IV, Sección 3.21 de la versión aplicable de los Estatutos, la Junta Directiva consideró la Declaración Final en su reunión del 23 de septiembre de 2017 y determinó, entre otras cuestiones, la necesidad de seguir considerando la recomendación no vinculante del Panel que señala que la Junta Directiva "reevalúe con prontitud las solicitudes de Amazon" y "formule un juicio objetivo e independiente sobre si existen, de hecho, razones fundadas de políticas públicas basadas​en méritos para denegar las solicitudes de Amazon". La Junta Directiva solicitó al BAMC que revise y considere la recomendación del Panel y que brinde opciones para que la Junta Directiva tenga en cuenta al tratar la recomendación del Panel.
Después de revisar y considerar la Declaración Final, la recomendación del Panel y todos los materiales relevantes, el Comité de Mecanismos de Responsabilidad de la Junta Directiva (BAMC) concluyó que sería beneficioso recibir toda la información nueva o adicional que el GAC decidiera proporcionar en relación con su asesoramiento sobre la detención de las Solicitudes de Amazon. La Junta Directiva considera que cualquier información nueva o adicional podría ser de utilidad para que la Junta Directiva realice una nueva evaluación integral de las Solicitudes de Amazon de acuerdo con la recomendación del Panel. Por lo tanto, el BAMC recomendó que la Junta Directiva solicitara al GAC toda información nueva o adicional relacionada con el asesoramiento del GAC sobre la detención de las Solicitudes de Amazon.
La Junta Directiva reconoce la importancia de esta decisión y quiere dejar en claro que toman muy seriamente los resultados de todos los mecanismos de responsabilidad de la ICANN, lo que queda demostrado con la creación de un nuevo BAMC y con el motivo por el cual la recomendación del Panel se derivó al BAMC.
La toma de esta decisión se encuentra dentro del alcance de la Misión de la ICANN y en la promoción del interés público como el resultado final de la consideración que la ICANN ha realizado sobre esta cuestión yace uno de los aspectos clave de coordinar la distribución y asignación de nombres en la zona raíz del sistema de nombres de dominio (DNS). Asimismo, la decisión de la Junta Directiva debe ser en pos del interés público, tener en cuenta y equilibrar los objetivos de la resolución de disputas de gTLD pendientes, respetar los mecanismos de responsabilidad y los comités asesores de la ICANN y observar las políticas y procedimientos que se detallan en la Guía para el Solicitante, desarrollados a través de un proceso ascendente de múltiples partes interesadas y basado en el consenso a lo largo de varios años de esfuerzos y aportes de la comunidad.
No se espera que esta decisión tenga ningún impacto financiero directo sobre la organización de la ICANN. Esta acción no tendrá ningún impacto directo sobre la seguridad, estabilidad o flexibilidad del sistema de nombres de dominio.
Visto y considerando: Que la Política de consenso del WHOIS amplio exige que todos los nuevos registros de nombres de dominio se presenten al registro como "amplios" a partir del 1.° de mayo de 2018 a más tardar, y que se migren todos los datos de registro relevantes de los nombres de dominio existentes de "acotados" a "amplios" antes del 1.° de febrero de 2019.
Visto y considerando: Que la migración del modelo de registro de acotado a amplio requerirá que los Registradores modifiquen los sistemas que usan para presentar los datos de registro a los registradores.
Visto y considerando: Que el Grupo de Partes Interesadas de Registradores manifestó sus inquietudes acerca de llevar a cabo tales modificaciones de resolución pendiente en relación con el Reglamento General sobre la Protección de Datos (GDPR), que podría exigir otras modificaciones al sistema.
Visto y considerando: Que en preparación para completar el despliegue para aceptar los datos del WHOIS amplio, Verisign, Inc. propuso enmiendas a los acuerdos entre registro y registrador para .COM y .NET con el fin de contar con el marco jurídico necesario para que Verisign comience a aceptar la transmisión de registradores de los datos amplios al registro.
Visto y considerando: Que la organización de la ICANN ha facilitado los debates entre Verisign y el Grupo de Partes Interesadas de Registradores para llegar a un acuerdo sobre las enmiendas propuestas a los acuerdos entre registro y registrados a fin de implementar la Política de consenso del WHOIS amplio.
Visto y considerando: Que Verisign y el Grupo de Partes Interesadas de Registradores necesitan más tiempo para llegar a un acuerdo sobre las enmiendas propuestas a los acuerdos entre registro y registrador aplicables a fin de implementar la Política de consenso del WHOIS amplio.
Visto y considerando: Que se requiere más tiempo para resolver las preguntas sobre la solicitud del GDPR a los datos del WHOIS.
Resuélvase (2017.10.29.04): El Presidente y Director Ejecutivo, o la persona que él designe, está autorizado para postergar la aplicación de cumplimiento de la Política de consenso del WHOIS amplio por 180 días a fin de proporcionar más tiempo para que los registradores y Verisign lleguen a un acuerdo sobre las enmiendas que deben hacerse a los acuerdos entre registro y registrador aplicables con el objetivo de implementar la Política y para que los Registradores puedan realizar las modificaciones requeridas al sistema que les permitan migrar de acotado a amplio, además de todas las modificaciones adicionales que deban hacerse para cumplir con el GDPR, si correspondiere.
La Política de consenso del WHOIS amplio determina que los registradores deben enviar los datos de registro amplio a los registros de .COM, .NET y .JOBS para todos los nuevos registros de nombre de dominio a partir del 1.° de mayo de 2018, a más tardar. La Política también exige la migración de todos los datos de registración de nombres de dominio existentes de acotado a amplio antes del 1.° de febrero de 2019. En preparación para completar el despliegue para aceptar los datos de WHOIS amplio, Verisign, el operado de registro para .COM y .NET y el proveedor de servicios de registro back-end para .JOBS, propuso enmiendas a los acuerdos entre registro y registrador para .COM y .NET con el fin de contar con el marco jurídico necesario para que Verisign comience a aceptar la transmisión de registradores de los datos amplios al registro.
La organización de la ICANN siguió su procedimiento de enmienda de Acuerdos entre Registro y Registrador y reenvió las enmiendas propuestas al Grupo de Partes Interesadas de Registradores para que las revisen. El Grupo de Partes Interesadas de Registradores expresó su preocupación sobre la aceptación de las enmiendas propuestas sobre la base de cuestiones relacionadas con el Reglamento General sobre la Protección de Datos (GDPR) de la Unión Europea, que entra en vigor el 25 de mayo de 2018. Como tal, el siguiente paso que se detalla en el procedimiento es que la organización de la ICANN consulte con el operador de registro y el Grupo de Partes Interesadas de Registradores para resolver estas inquietudes.
Durante los últimos meces, la organización de la ICANN ha facilitado los debates entre Verisign y el Grupo de Partes Interesadas de Registradores para que lleguen a un acuerdo sobre las enmiendas propuestas a los acuerdos entre registro y registrados, pero las partes aún no han llegado a un acuerdo. Además, la organización de la ICANN está investigando si existen posibles problemas de cumplimiento en sus acuerdos entre registros y registradores según el Reglamento General sobre la Protección de Datos. La organización de la ICANN está trabajando con registros, registradores y distintas partes interesadas para entender estos posibles problemas de cumplimiento. De acuerdo con las revisiones y comunicaciones iniciales, que incluyen a algunas agencias de protección de datos, la organización de la ICANN entiende que el cumplimiento del GDPR tendrá un impacto en el sistema de WHOIS.
El 29 de junio de 2017, la organización de la ICANN aprobó la solicitud de extensión de Verisign a una fecha hito opcional en la Política para que los registradores comenzaran a enviar datos amplios al registro de forma voluntaria. Esta extensión se concedió para que Verisign, la ICANN y el Grupo de Partes Interesadas de Registradores tuvieran más tiempo para continuar con los debates con la esperanza de lograr una resolución, mientras se siguen tomando las medidas razonables para cumplir con la política. La fecha de hito opcional del 1.° de agosto de 2017 se extendió hasta el 29 de noviembre de 2017.
La Junta Directiva toma esta medida en este momento para autorizar al Presidente y Director Ejecutivo de la ICANN a postergar la aplicación de cumplimiento de la Política del WHOIS amplio por 180 días a fin de permitir que los registradores y Verisign tengan más tiempo para llegar a un acuerdo sobre las enmiendas que deben hacerse a los acuerdos entre registro y registrador para implementar la Política. La postergación del período de aplicación también permitirá que la organización de la ICANN siga participando con la comunidad europea (incluido el Grupo de Trabajo sobre el ARTíCULO 29 acerca de protección de datos de la Unión Europea), las agencias de protección de datos, las partes contratadas y otras partes interesadas pertinentes a fin de llegar a un mejor entendimiento de los aspectos relevantes del GDPR y cómo se relaciona con el trabajo, las políticas y los contratos entre registradores y registros de la organización de la ICANN, entre otros, la Política del WHOIS amplio.
Como resultado de la acción de la Junta Directiva, la organización de la ICANN comenzará la aplicación de cumplimiento del requisito de la Política por el cual los registradores deben enviar todos los nuevos registros de nombres de dominio como amplios al registro a partir del 28 de octubre de 2018 a más tardar y deben migrar de acotado a amplio todos los datos de registro relevantes para los nombres de dominio existentes antes del 31 de julio de 2019. La fecha hito opcional para que los registradores comiencen a enviar los datos amplios al registro de forma voluntaria será el 28 de mayo de 2018.
Durante este período de aplicación de cumplimiento postergada, la organización de la ICANN seguirá trabajando con Verisign y con el Grupo de Partes Interesadas de Registradores con el objetivo de facilitar los debates sobre las enmiendas propuestas. La organización de la ICANN también brindará actualizaciones a la comunidad sobre el progreso a fin de cumplir con la Política del WHOIS amplio. Durante esta extensión del período, el Grupo de Partes Interesadas de Registradores indicó [PDF, 43 KB] que "seguirá participando con la ICANN y con Verisign en los cambios a los Acuerdo entre Registro y Registrador, en el rol de la ICANN en el Reglamento General sobre la Protección de Datos (GDPR) y en los pasos necesarios para implementar la transición al WHOIS amplio".
Informe Final del Grupo de Trabajo para el Proceso de Desarrollo de Políticas [PDF, 1,23 MB]
Carta de Patrick Kane a Akram Atallah sobre: WHOIS amplio para .COM y .NET – 20 de junio de 2017 (https://www.icann.org/en/system/files/correspondence/kane-to-atallah-20jun17-en.pdf [PDF, 3,7 MB])
Carta de Akram Atallah a Patrick Kane sobre: WHOIS amplio para .COM y .NET – 29 de junio de 2017 (https://www.icann.org/en/system/files/correspondence/atallah-to-kane-29jun17-en.pdf [PDF, 4,04 MB])
Carta de Graeme Bunton a Akram Atallah sobre: Extensión de la Solicitud para la migración de WHOIS amplio – 17 de agosto de 2017 (https://www.icann.org/en/system/files/correspondence/bunton-to-atallah-17aug17-en.pdf [PDF, 43 KB])
Esta acción se realiza en pos del interés público ya que permite garantizar la implementación coherente y coordinada de políticas en los gTLD. Es Misión de la ICANN coordinar el desarrollo y la implementación de las políticas.
No se espera que la acción de la Junta Directiva tenga un impacto fiscal en la ICANN que no se haya anticipado en el presupuesto actual, así como tampoco se espera que tenga un impacto negativo en la seguridad, la estabilidad y la flexibilidad del sistema de nombres de dominio.
Visto y considerando: Que la Junta Directiva de la ICANN aprobó el Plan Final de Implementación para el Proceso de Avance Acelerado de Dominios de Alto Nivel con Código de País dentro de Nombres de Dominio Internacionalizados (IDN ccTLD) el 30 de octubre de 2009 (http://www.icann.org/en/minutes/resolutions-30oct09-en.htm#2).
Visto y considerando: Que como parte de una revisión y actualización del Plan de Implementación y de acuerdo con el desarrollo de las recomendaciones para la política de selección de cadenas de caracteres de ccTLD de IDN, el Consejo de la ccNSO solicitó a la Junta Directiva que incluyera un proceso de dos paneles para la evaluación de similitudes entre cadenas de caracteres (http://ccnso.icann.org/node/38787).
Visto y considerando: Que la Junta Directiva de la ICANN aprobó la actualización de la implementación del Proceso de Avance Acelerado de Dominios de Alto Nivel con Código de País dentro de Nombres de Dominio Internacionalizados (IDN ccTLD) para llevar a cabo el proceso de dos paneles para la revisión de similitudes entre cadenas de caracteres. El 27 de junio de 2013 se aprobó la inclusión del Panel de Revisión Extendida de Similitudes entre Cadenas de Caracteres (EPSRP) en el Proceso de Avance Acelerado de Dominios de Alto Nivel con Código de País dentro de Nombres de Dominio Internacionalizados (IDN ccTLD) y se instruyó a la Junta Directiva a desarrollar las Pautas relevantes y a actualizar el Plan Final de Implementación en consecuencia (https://www.icann.org/resources/board-material/resolutions-2013-06-27-en#2.a).
Visto y considerando: Que, tras la actualización de 2013 y a pedido de los solicitante relevantes, las cadenas de caracteres de ccTLD de IDN pendientes bajo el Proceso de Avance Acelerado fueron evaluadas por el Panel de Revisión Extendida de Similitudes entre Cadenas de Caracteres (EPSRP) y que el 14 de octubre de 2014 se publicaron en el sitio web de la ICANN los informes del EPSRP para las tres solicitudes con los resultados de la evaluación (https://www.icann.org/resources/pages/epsrp-reports-2014-10-14-en). Una solicitud tuvo un resultado dividido a partir de las evaluaciones de posibles confusiones en las representaciones en mayúsculas y minúsculas de la cadena de caracteres solicitada.
Visto y considerando: Que se recibieron comentarios públicos durante la tercera revisión anual del Proceso de Avance Acelerado de Dominios de Alto Nivel con Código de País dentro de Nombres de Dominio Internacionalizados (IDN ccTLD) sobre cuestiones relacionadas con la metodología experimental y los resultados informados por las recomendaciones divididas del EPSRP sobre las similitudes confusas entre las formas en mayúsculas y minúsculas de la cadena de caracteres solicitada (https://www.icann.org/public-comments/idn-cctld-fast-track-2015-01-15-en).
Visto y considerando: Que luego de recibir el comentario público para la tercera revisión anual, el 25 de junio de 2015 la Junta Directiva de la ICANN resolvió solicitar a la ccNSO, en consulta con otras partes interesadas, incluidos el GAC y el SSAC, que proporcione más orientación y detalles con respecto a la metodología del proceso de segunda revisión de similitud entre cadenas de caracteres (https://www.icann.org/resources/board-material/resolutions-2015-06-25-en#2.a).
Visto y considerando: Que en respuesta a una carta enviada por la Junta Directiva para solicitar mayor claridad, la ccNSO y el SSAC brindaron una respuesta conjunta el 19 de septiembre de 2017 en la que proponían modificaciones al Plan Final de Implementación para el Proceso de Avance Acelerado de Dominios de Alto Nivel con Código de País de Nombres de Dominio Internacionalizados (IDN ccTLD).
Resuélvase (2017.10.29.05): La Junta Directiva agradece a la ccNSO, al GAC y al SSAC su colaboración en el tratamiento de la cuestión de la revisión de similitud entre las cadenas de caracteres y por elaborar la "Respuesta Conjunta de la ccNSO y el SSAC a la Junta Directiva de la ICANN sobre el EPSRP".
Resuélvase (2017.10.29.06): La Junta Directiva aprueba la enmienda al Plan Final de Implementación para el Proceso de Avance Acelerado de Dominios de Alto Nivel con Código de País dentro de Nombres de Dominio Internacionalizados (IDN ccTLD) tal como se sugiere en la Respuesta Conjunta de la ccNSO y el SSAC. Se instruye al Presidente y Director Ejecutivo, o a la persona que él designe, a incorporar la enmienda en el anterior Plan de Implementación adoptado por la Junta Directiva el 30 de octubre de 2009 (con su enmienda del 5 de noviembre de 2013) y a implementar la enmienda tan pronto como sea posible.
El 5 de noviembre de 2013, la organización de la ICANN publicó un Plan Final de Implementación para el Proceso de Avance Acelerado de Dominios de Alto Nivel con Código de País dentro de Nombres de Dominio Internacionalizados (IDN ccTLD) actualizado [PDF, 851 KB], que incluía las Pautas [PDF, 86 KB] para el Panel de Revisión Extendida de Similitudes entre Cadenas de Caracteres (EPSRP) e implementaba la revisión de similitudes entre cadenas de caracteres de dos paneles, según lo resuelto por la Junta Directiva el 27 de junio de 2013. Luego de la actualización, tres solicitantes elegibles del Proceso de Avance Acelerado de Dominios de Alto Nivel con Código de País dentro de Nombres de Dominio Internacionalizados (IDN ccTLD) para Bulgaria (en cirílico), la Unión Europea (en griego) y Grecia (en griego) ejercieron su opción para pasar a la segunda revisión de similitud. El EPSRP finalizó la revisión y la organización de la ICANN publicó los informes el 14 de octubre de 2014.
Para cada solicitud, el EPSRP documentó sus pronunciamientos sobre la cadena de caracteres solicitada. Cada informe incluyó una descripción detallada de la metodología y los resultados de los experimentos para analizar la similitud entre las cadenas de caracteres. El EPSRP no agregó sus pronunciamientos para una cadena de caracteres que se basara en experimentos realizados en las formas en mayúsculas y minúsculas de la cadena de caracteres. El EPSRP concluyó que desde una perspectiva de similitud visual, los caracteres en mayúsculas o minúsculas son entidades diferentes. Y dado que no existe un fundamento científico o en las políticas que indique cómo combinar los resultados de las similitudes entre mayúsculas y minúsculas encontradas para los IDN ccTLD, el EPSRP solo se limitó a brindar recomendaciones independientes para cada forma. Por lo tanto, como los pronunciamientos del EPSRP se dividen a partir de las distintas opiniones sobre las similitudes confusas entre las formas en mayúsculas y en minúsculas de una cadena de caracteres, no existe un mecanismo que permita identificar una única recomendación agregada de la segunda revisión de similitud entre cadenas de caracteres realizada por el EPSRP.
A partir de su experiencia con el análisis del EPSRP, durante la tercera revisión del Proceso de Avance Acelerado de Dominios de Alto Nivel con Código de País dentro de Nombres de Dominio Internacionalizados (IDN ccTLD), la comunidad realizó comentarios públicos que cuestionaban la metodología del EPSRP, incluida la evaluación de las recomendaciones divididas (p. ej., similitud confusa en mayúsculas pero no en minúsculas).
Para abordar estos comentarios, la Junta Directiva (mediante la Resolución 2015.06.25.16) solicita a la ccNSO, en consulta con otras partes interesadas, incluidos el GAC y el SSAC, que proporcione más orientación y detalles con respecto a la metodología del proceso de segunda revisión de similitud entre cadenas de caracteres, incluida la interpretación de las recomendaciones divididas, para su aplicación a los casos relevantes actuales y futuros en el Proceso de Avance Acelerado de ccTLD de IDN, así como para informar la política propuesta para la selección de las cadenas de caracteres de ccTLD de IDN.
El grupo de trabajo correspondiente de la ccNSO, en colaboración con los miembros del GAC, publicó su informe [PDF, 274 KB] para comentario público antes de la finalización. El SSAC presentó una revisión alternativa en el documento SAC 084 [PDF, 218 KB] y, luego, en los documentos SAC 088 [PDF, 72 KB] y SAC 089 [PDF, 128 KB]. A pedido de la Junta Directiva, la ccNSO y el SSAC trabajaron juntos para hallar una solución, que los presidentes correspondientes presentaron como una respuesta conjunta [PDF, 215 KB] a la Junta Directiva el 19 de septiembre de 2017.
Con esta resolución, la Junta Directiva da por finalizada la revisión 2015 del programa de Avance Acelerado y procede con la actualización del Plan Final de Implementación para el Proceso de Avance Acelerado de Dominios de Alto Nivel con Código de País dentro de Nombres de Dominio Internacionalizados (IDN ccTLD), como se sugiere en la respuesta conjunta de la ccNSO y el SSAC. El tratamiento de esta cuestión se corresponde con la Misión de la ICANN, como lo establece la Sección 1.1(a)(i) de los Estatutos de la ICANN: "Coordina la distribución y asignación de nombres en la zona raíz del Sistema de Nombres de Dominio". Una vez aclarada esta cuestión pendiente, puede comenzar el ciclo de revisión del Plan de Implementación.
El SSAC proporcionó aportes iniciales en el documento SAC 084 [PDF, 218 KB] y en los documentos SAC 088 [PDF, 72 KB] y SAC 089 [PDF, 128 KB] aclaró que si hubiera una recomendación dividida, "el pronunciamiento predeterminado será rechazar la etiqueta si existe confusión en cualquier forma", y señala que se deben aplicar los principios de conservadurismo, inclusión y estabilidad a procesos como el EPSRP, conforme al RFC 6912. Sin embargo, en el Informe Técnico de Unicode N.° 36, el Consejo de la ccNSO señaló lo siguiente: En las Consideraciones de seguridad de Unicode se establece que "a menudo se exagera sobre el uso de caracteres confusos visualmente en la falsificación informática (spoofing) … [lo que] da cuenta de una pequeña proporción de problemas de phishing", que se pueden mitigar gracias a las medidas que se sugieren en el informe de Unicode. En la respuesta conjunta, la ccNSO y el SSAC acuerdan llevar a cabo un proceso que trate las inquietudes presentadas por el SSAC acerca de permitir que el solicitante proponga medidas para que los expertos revisen y determinen si la mitigación de la confusión generada por la similitud fue efectiva.
Plan Final de Implementación para el Proceso de Avance Acelerado de Dominios de Alto Nivel con Código de País de Nombres de Dominio Internacionalizados (IDN ccTLD) [PDF, 851 KB], 5 de noviembre de 2013
Pautas para el Panel de Revisión Extendida de Similitudes entre Cadenas de Caracteres (EPSRP) para el Proceso de Avance Acelerado de Dominios de Alto Nivel con Código de País dentro de Nombres de Dominio Internacionalizados (IDN ccTLD) [PDF, 86 KB], 4 de diciembre de 2013
Informe Técnico Unicode N.° 36: Consideración de seguridad de Unicode – 19 de septiembre de 2014
Informes del Panel de Revisión Extendida de Similitudes entre Cadenas de Caracteres (EPSRP) para las Solicitudes de IDN ccTLD – 14 de octubre de 2014
Comentarios públicos sobre la revisión anual del Proceso de Avance Acelerado de Dominios de Alto Nivel con Código de País dentro de Nombres de Dominio Internacionalizados (IDN ccTLD), 17 de marzo de 2015
La resolución 2015.06.25.16 de la Junta Directiva de la ICANN – 25 de junio de 2015
La respuesta al comentario público sobre el informe preliminar [PDF, 274 KB] del Grupo de Trabajo sobre EPSRP – 20 de julio de 2016
SAC 084: Comentarios del SSAC sobre las Pautas para el Panel de Revisión Extendida de Similitudes entre Cadenas de Caracteres para el Proceso de Avance Acelerado de Dominios de Alto Nivel con Código de País dentro de Nombres de Dominio Internacionalizados (IDN ccTLD) [PDF, 218 KB], 31 de agosto de 2016
Comentario del GAC sobre el Grupo de Trabajo de EPSRP. Comentario público [PDF, 261 KB] – 28 de septiembre de 2016
SAC 088: Respuesta del SSAC a los comentarios de la ccNSO sobre el documento SAC084 [PDF, 72 KB] - 6 de noviembre de 2016
Asesoramiento del GAC a la Junta Directiva, Punto 7, en el Comunicado del GAC pronunciado en la Reunión N.° 57 de la ICANN [PDF, 638 KB] – 8 de noviembre de 2016
SAC 089: Respuesta del SSAC a los comentarios de la ccNSO sobre el documento SAC084 [PDF, 128 KB] - 12 de diciembre de 2016
Carta de la ccNSO a la Junta Directiva de la ICANN sobre: Informe Final del EPSRP – 30 de enero de 2017
Grupo de Trabajo de la ccNSO sobre el EPSRP. Informe Final [PDF, 894 KB] – 6 de enero de 2017
Respuesta conjunta del SSAC de la ccNSO a la Junta Directiva de la ICANN [PDF, 215 KB] - 19 de septiembre de 2017
La Junta Directiva señaló que los miembros de la ccNSO y del SSAC trabajaron en conjunto para llegar a un mecanismo efectivo que trate las inquietudes contrapuestas que surgieron durante el proceso. El solicitante de IDN ccTLD debe proponer medidas efectivas para la mitigación de riesgos a fin de tratar las inquietudes de seguridad presentadas anteriormente por el SSAC.
Esta decisión tiene un impacto positivo porque aclara la ambigüedad de las pautas de la segunda revisión de similitud ante la posibilidad de que exista una recomendación dividida. Asimismo, permite que las evaluaciones de cadenas de caracteres de IDN ccTLD sigan adelante siempre que sea posible determinar e implementar medidas de mitigación de riesgos efectivas. Esta decisión también respalda el interés público mediante la expansión de la posible disponibilidad de IDN ccTLD a países y territorios adicionales, lo que apoya a los usuarios locales de Internet.
Una vez que se lleva adelante la implementación, habrá impactos fiscales porque la organización de la ICANN deberá convocar a expertos relevantes para revisar las estrategias de mitigación propuestas por el solicitante.
¿Se observan cuestiones sobre seguridad, estabilidad o flexibilidad? ¿Qué inquietudes o cuestiones fueron planteadas por la comunidad?
En la respuesta conjunta del SSAC y la ccNSO se explica que hay cuatro maneras en que la similitud entre las formas en mayúsculas y minúsculas de las cadenas de caracteres solicitadas puede ser confusa. En el primer caso, ninguna cadena de caracteres presenta similitud confusa y pasa la evaluación. En el segundo y tercer caso, la confusión se presenta en la similitud de la forma en minúsculas, sin importar que exista o no confusión en la similitud de las mayúsculas. Los riesgos asociados son demasiado elevados y difíciles de mitigar, por lo tanto, la cadena de caracteres no debe pasar. En el cuarto caso, las minúsculas no son similares pero las mayúsculas sí y se presta a confusión. El SSAC señala que lo adecuado es tener un enfoque prudente. En la respuesta conjunta, se expresa que el SSAC considera que el riesgo es un proceso continuo y, en el cuarto caso, el enfoque prudente podría aplicarse para que el solicitante de IDN ccTLD proponga medidas de mitigación y que los expertos consideren suficientes para reducir los riesgos a un nivel aceptable. Solo entonces la cadena de caracteres puede pasar la evaluación de similitud entre cadena de caracteres.
La actualización sugerida por la ccNSO ya estaba sujeta al comentario público requerido tras la elaboración de la versión preliminar del informe inicial. Entre los comentarios se incluyó una respuesta del GAC en apoyo a los pronunciamientos y respuestas del SSAC en el documento SSAC 084, con posteriores respuestas en los documentos SAC 088 y SAC 089, donde se sugería un enfoque alternativo. Para resolver las opiniones divergentes que se manifestaron luego del comentario público, la ccNSO y el SSAC trabajaron en conjunto para aclarar sus posiciones y buscar un terreno común, lo que se presentó en su respuesta conjunta ante la Junta Directiva. No se requiere mayor cantidad de comentarios públicos para incorporar el ajuste sugerido por la respuesta conjunta de la ccNSO y el SSAC al Plan Final de Implementación para el Proceso de Avance Acelerado de Dominios de Alto Nivel con Código de País dentro de Nombres de Dominio Internacionalizados (IDN ccTLD). Esta decisión forma parte de las funciones administrativas y organizativas que no requieren comentario público.
1 Determinación del BGC sobre la Solicitud 15-21, en página 1, https://www.icann.org/en/system/files/files/reconsideration-15-21-dotgay-bgc-determination-01feb16-en.pdf [PDF, 272 KB].
2 El BGC tenía la tarea de revisar las solicitudes de reconsideración antes del 22 de julio de 2017. Véase Estatutos de la ICANN, 1.° de octubre de 2016, Art. 4, § 4.2(e), https://www.icann.org/resources/pages/bylaws-2016-09-30-en#article4. Luego del 22 de julio de 2017, el Comité de Mecanismos de Responsabilidad de la Junta Directiva (BAMC) tenía la tarea de revisar y hacer recomendaciones a la Junta Directiva sobre las solicitudes de reconsideración. Véase Estatutos de la ICANN, 22 de julio de 2017, Art. 4, § 4.2(e), https://www.icann.org/resources/pages/governance/bylaws-en/#article4.
3 Determinación del BGC sobre la Solicitud 15-21, en página 1.
4 Solicitud 16-3, https://www.icann.org/en/system/files/files/reconsideration-16-3-dotgay-request-17feb16-en.pdf [PDF, 728 KB].
5 Solicitud 16-5, https://www.icann.org/en/system/files/files/reconsideration-16-5-dotmusic-request-redacted-24feb16-en.pdf [PDF, 1,06 MB].
6 Respuestas de la ICANN a las Solicitudes de DIDP No. 20170505-1 (DotMusic Ltd.) y 20170518-1 (dotgay LLC), incorporadas por referencia en la Respuesta de la ICANN a la Solicitud de DIDP No. 20170610-1 en la página 2.
7 Como señaló el BAMC, los Solicitantes indicaron (al marcar la casilla de verificación correspondiente en el Formulario de Solicitud de Reconsideración) que la Solicitud 17-4 pretende la reconsideración de la acción o inacción por parte del personal y la Junta Directiva. No obstante, por una breve referencia al Artículo 4, Sección 4.2(o) de los Estatutos de la ICANN, que establece que el BAMC "deberá . . . proporcionar[] al Solicitante" toda la información "recopilada por la ICANN de terceros" que sea relevante a la Solicitud de Reconsideración", los Solicitantes no exponen más argumentos acerca de las acciones o inacciones del BAMC. Los Solicitantes también piden a la organización de la ICANN que tome acciones en esta cuestión. En cambio, los Solicitantes se centran en la respuesta de la organización de la ICANN a la Solicitud de DIDP Conjunta. De conformidad, el BAMC interpretó que la Solicitud 17-4 pretendía la reconsideración de la respuesta de la organización de la ICANN a la Solicitud de DIDP Conjunto y no la reconsideración de la acción o inacción del BAMC, y la Junta Directiva expresó su acuerdo. (Véase Recomendación del BAMC [PDF, 273 KB], páginas 12-13).
8 La reconsideración también es adecuada si el solicitante demuestra que se vio afectado negativamente por la acción o inacción por parte del personal o la Junta Directiva que se haya seguido sin considerar la información material o como resultado de confiar en información relevante falsa o inexacta. (Estatutos de la ICANN, Art. 4, Sección 4.2(c)(ii), (iii)).

References: resolución 
 resolución 
 Artículo 4
 Artículo 4
 Artículo 4
 Artículo 4
 Artículo 4
 Artículo 1
 Artículo 3
 Resolución 
 resolución 
 resolución 
 ARTíCULO 29
 Resolución 
 resolución 
 Artículo 4