Skip to main content
Resources

Este documento ha sido traducido a varios idiomas como información únicamente. El texto original y válido (en inglés) se puede obtener en:

Esta página está disponible en:

12 – 14 October 2014

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

 

  1. Orden del Día Convenido:
    1. Aprobación de actas
  2. Orden del Día Principal:
    1. Asesoramiento del GAC en el Comunicado pronunciado en Pekín en relación a las Protecciones de Categoría 2 -Acceso al Registro Exclusivo
    2. No se adoptó ninguna resolución. Determinaciones de Expertos sobre Procesos de Objeción por Confusión de Cadenas de Caracteres, percibidas como incongruentes
    3. Solicitud de Reconsideración 14-37, I-Registry Ltd.
    4. Asesoramiento del GAC en materia de Protecciones para la Cruz Roja y la Media Luna roja-Comunicado pronunciado en Singapur
    5. Otros asuntos

 

La reunión del Comité para el Programa de Nuevos gTLD de la Junta Directiva de la ICANN del 12 de octubre de 2014 continuó el 14 de octubre de 2014. Se adoptaron las siguientes resoluciones durante la reunión:

  1. Orden del Día Convenido:

    1. Aprobación de actas

      Resuélvase (2014.10.12.NG01): El Comité para el Programa de Nuevos gTLD (NGPC) de la Junta Directiva de la ICANN aprueba las actas de la reunión celebrada el 8 de septiembre de 2014.

  2. Orden del Día Principal:

    1. Asesoramiento del GAC en el Comunicado pronunciado en Pekín en relación a las Protecciones de Categoría 2 -Acceso al Registro Exclusivo

      No se adoptó ninguna resolución.

    2. Determinaciones de Expertos sobre Procesos de Objeción por Confusión de Cadenas de Caracteres, percibidas como incongruentes

      Visto y considerando que, el 10 de octubre de 2013 el Comité de Gobernanza de la Junta Directiva (BGC) solicitó al personal que redactara un informe para el NGPC sobre las Objeciones por Confusión de Cadenas de Caracteres (SCO), en el que se "establezcan opciones para dar tratamiento a la situación planteada en esta Solicitud [de Reconsideración], en específico, con los diferentes resultados obtenidos del proceso de Resolución de Disputas sobre Objeciones por Confusión de Cadenas de Caracteres en disputas similares que involucran a la cadena de caracteres solicitada por Amazon y la cadena de caracteres solicitada por TLDH".

      Visto y considerando que, el NGPC analizó los posibles caminos a seguir para abordar las Determinaciones de los Expertos en las que se percibieron incongruencias con respecto al proceso de objeción por confusión de cadenas de caracteres del Programa de Nuevos gTLD, incluida la posible implementación de un mecanismo de revisión.

      Visto y considerando que el 5 de febrero de 2014 el Comité para el Programa de Nuevos gTLD de la Junta Directiva (NGPC) instruyó al Presidente y Director Ejecutivo de la ICANN, o a quien éste designe, iniciar a un período de comentarios públicos sobre los principios del marco de un posible mecanismo de revisión para abordar las Determinaciones de los Expertos que se percibieron como incongruentes con respecto al proceso de objeción por confusión de cadenas de caracteres (el "mecanismo de revisión propuesto"). Si se adoptase, el mecanismo de revisión propuesto habría estado limitado a las Determinaciones de los Expertos sobre las Objeciones por Confusión de Cadenas de Caracteres para .CAR/.CARS y .CAM/.COM y habría constituido un cambio al proceso de Objeciones establecido en la Guía para el Solicitante de Nuevos gTLD.

      Visto y considerando que, el NGPC ha analizado cuidadosamente el informe que el BGC solicitó al personal redactar en respuesta a la Solicitud de Reconsideración 13-9, los comentarios públicos recibidos sobre el mecanismo de revisión propuesto, otros comentarios brindados al NGPC para su consideración y los procesos establecidos en la Guía para el Solicitante.

      Visto y considerando que, tal como está establecido en la Guía para el Solicitante, la ICANN se reserva el derecho de considerar de manera individual una solicitud de un nuevo gTLD para determinar si su aprobación responde al mejor interés de la comunidad de Internet.

      Visto y considerando que, el NGPC está tomando esta medida de conformidad con la autoridad que le otorgase la Junta Directiva el 10 de abril de 2012, para ejercer la autoridad de la Junta Directiva de la ICANN ante cualquier y todas las cuestiones que pudiesen surgir en relación al Programa de Nuevos gTLD.

      Resuélvase (2014.10.12.NG02), el NGPC ha identificado las siguientes Determinaciones de los Expertos sobre Objeciones por Confusión de Cadena de Caracteres, las cuales no están en pos de los intereses del Programa de Nuevos gTLD y de la comunidad de Internet:

      Determinaciones de los Expertos sobre SCO Cadena de caracteres Determinaciones de los Expertos sobre SCO Relacionadas
      VeriSign Inc. (Objetor) v. United TLD Holdco Ltd. (Solicitante) .CAM [PDF, 5.96 MB]
      Commercial Connect LLC (Objetor) v. Amazon EU S.à r.l. (Solicitante) .通販 [PDF, 73 KB]1 Top Level Domain Holdings Limited [PDF, 721 KB](.购物)

      Resuélvase (2014.10.12.NG03), el NGPC instruye al Presidente y Director Ejecutivo, o quien éste designe, tomar todas las acciones necesarias a fin de establecer los procesos y procedimientos, en consonancia con esta resolución y el fundamento relacionado, según lo cual el Centro Internacional para la Resolución de Disputas (ICDR) deberá establecer un panel compuesto por tres miembros para re-evaluar las Determinaciones de los Expertos, en dos procedimientos de objeción establecidos en el cuadro anterior en la columna "Determinaciones de los Expertos sobre SCO para revisión" y emitir una Determinación Final de los Expertos sobre estos dos procedimientos. Al hacer esto, el NGPC recomienda que el panel de tres miembros también analice, a modo de referencia, las "Determinaciones de los Expertos sobre SCO relacionadas" a las que se hace referencia en el cuadro anterior.

      Fundamentos de las resoluciones 2014.10.12.NG02 y 2014.10.12.NG03

      Hoy el NGPC está tomando medidas para abordar las Determinaciones de los Expertos percibidas como incongruentes y no razonables resultantes del proceso de objeción por confusión de cadenas de caracteres del Programa de Nuevos gTLD. La acción tomada hoy por el NGPC es parte de su rol para brindar una supervisión general del Programa de Nuevos gTLD. Uno de los componentes de las responsabilidades del NGPC es "resolver las cuestiones relativas a la aprobación de solicitudes y la delegación de gTLD, de conformidad con el Programa de Nuevos gTLD para la ronda actual de dicho programa". (Véase Carta Orgánica del NGPC, Sección II.D).

      La Nueva Guía para el Solicitante de Nuevos gTLD (AGB o Guía) identifica cuatro causales por las cuales se puede presentar una objeción formal en contra de una cadena de caracteres solicitada. Dicha objeción es una Objeción por Confusión de Cadena de Caracteres o SCO, la cual puede ser presentada por un objetor (que cumpla con los requisitos establecidos) si cree que la cadena de caracteres de gTLD solicitada resulta confusamente similar a un TLD existente o a otra cadena de caracteres de gTLD solicitada en la misma ronda de solicitudes. Si tiene éxito, una SCO podría cambiar la configuración de los conjuntos controvertidos preliminares dado que las dos cadenas de gTLD solicitadas en cuestión serán consideradas en controversia directa entre sí (véase el Módulo 4, Procedimientos de Controversia por Cadenas de Caracteres de la Guía para el Solicitante). Todos los procedimientos de SCO fueron administrados por el Centro Internacional de Resolución de Disputas (ICDR) y en todos estos procedimientos se emitieron Determinaciones de los Expertos.

      Algunas partes interesadas han planteado inquietudes respecto de las incongruencias percibidas con ciertas Determinaciones de los Expertos sobre SCO o la irracionalidad de las mismas. El NGPC ha seguido de cerca estas inquietudes durante el último año y discutió el tema en varias de sus reuniones. El 10 de octubre de 2013 el Comité de Gobernanza de la Junta Directiva (BGC) solicitó al personal que redactara un informe para el NGPC sobre las Objeciones por Confusión de Cadenas de Caracteres, en el que se "establezcan opciones para dar tratamiento a la situación planteada en esta Solicitud, en específico, con los diferentes resultados obtenidos del proceso de Resolución de Disputas sobre Objeciones por Confusión de Cadenas de caracteres en disputas similares que involucran a la cadena de caracteres solicitada por Amazon y la cadena de caracteres solicitada por TLDH". (Véase http://www.icann.org/en/groups/board/governance/reconsideration/recommendation-amazon-10oct13-en.pdf [PDF, 131 KB]).

      A la luz de la solicitud del BGC luego de tomar en cuenta las Solicitudes de Reconsideración 13-9 y 13-10 y las inquietudes planteadas por la comunidad en relación a las incongruencias percibidas en las Determinaciones de los Expertos sobre SCO, el NGPC analizó las opciones, incluida la posible implementación de un mecanismo de revisión no contemplado en la Guía para el Solicitante, el cual estaría disponible en limitadas circunstancias.

      El 5 de febrero de 2014, el NGPC instruyó al Presidente y Director Ejecutivo de la ICANN, o a quien éste designe, dar inicio a un período de comentarios públicos sobre los principios del marco de un posible mecanismo de revisión para abordar las Determinaciones de los Expertos que se percibieron como incongruentes con respecto al proceso de objeción por confusión de cadenas de caracteres. El mecanismo de revisión propuesto, tal como fue redactado y publicado para comentario público, se limitaría a las Determinaciones de los Expertos sobre SCO para .CAR/.CARS y .CAM/.COM. El período de comentarios públicos para el mecanismo de revisión propuesto cerró el 3 de abril de 2014 y se ha publicado un resumen de los comentarios [PDF, 165 KB]

      En este momento, el NGPC está tomando medidas para abordar ciertas Determinaciones de los Expertos sobre SCO percibidas como incongruentes o, bien, no razonables, al enviarlas nuevamente al ICDR para una re-evaluación por parte del panel de tres miembros. El NGPC ha identificado estas Determinaciones de los Expertos, las cuales no van en pos de los intereses del Programa de Nuevos gTLD y la comunidad de Internet. El ICDR brindará reglas complementarias para guiar la revisión de las Determinaciones de los Expertos identificadas, que incluye lo siguiente:

      • El panel de revisión se compondrá de tres miembros designados por el ICDR (el "Panel de Revisión").

      • La única cuestión sujeta a análisis por parte del Panel de Revisión deberán ser las Determinaciones de los Expertos sobre SCO identificadas en estas resoluciones.

      • El registro de revisión se deberá limitar a la transcripción de los procedimientos que dieron lugar a la Determinación del Experto original, si existen, los informes de los expertos, la prueba documental admitida como evidencia durante el procedimiento original u otra prueba relevante a la revisión que fuese presentada en el procedimiento. No es posible presentar para consideración documentos adicionales, resúmenes u otra prueba, a menos que se recomiende que el Panel de Revisión tome en cuenta las "Determinaciones de los Expertos sobre SCO relacionadas" identificadas en el cuadro anterior como parte de su revisión.

      • El criterio de revisión a ser aplicado por el Panel de Revisión es: si el Panel de Expertos original podría haber llegado razonablemente a la decisión adoptada en la SCO subyacente mediante una adecuada aplicación del criterio de revisión, según lo establecido en la Guía para el Solicitante y los Procedimientos Complementarios del ICDR para el Programa de Nuevos gTLD de la ICANN.

      • La ICANN abonará las tarifas aplicables para llevar a cabo la revisión por parte del Panel de Revisión.

      • Los posibles resultados de la revisión son: (1) la Determinación del Experto original es avalada por el criterio de revisión y la referencia a las Determinaciones de los Expertos relacionadas identificadas y permanecerá como está; o (2) la Determinación del Experto original no puede ser razonablemente avalada según los criterios de revisión y referencia a las Determinaciones de los Expertos relacionadas identificadas, y será revisada. El Panel de Revisión enviará una decisión por escrito que incluirá una explicación y los fundamentos de dicha determinación.

      Como parte de las extensas deliberaciones durante meses sobre esta cuestión, a continuación, se expresan algunos de los factores que el NGPC consideró como significativos:

      1. El NGPC advierte que la Guía para el Solicitante fue desarrollada por la comunidad mediante un proceso multisectorial durante varios años. El NGPC analizó si era adecuado cambiar la Guía en este momento para implementar un mecanismo de revisión que abordara ciertas Determinaciones de los Expertos percibidas como incongruentes. El 18 de abril de 2013, la ICANN publicó un mecanismo de revisión propuesto para comentarios públicos. El NGPC analizó cuidadosamente los comentarios públicos recibidos. El NGPC señala que los comentarios enviados durante el período de comentarios públicos, en general, estuvieron dentro de las siguientes categorías, cada una de las cuales se discute más en detalle en el resumen de los comentarios públicos:

        1. No adoptar el mecanismo de revisión propuesto.

        2. Adoptar el mecanismo de revisión propuesto.

        3. Adoptar un mecanismo de revisión con un alcance ampliado.

        4. No adoptar el mecanismo de revisión propuesto o expandir su alcance.

        5. Adoptar alguna forma de revisión, pero no necesariamente la publicada para comentarios públicos.

        6. Modificaciones recomendadas a los principios del marco de trabajo del mecanismo de revisión propuesto en caso de que se adopte algún mecanismo de revisión.

        Los comentarios presentados por varias partes interesadas resaltan la dificultad de esta cuestión y la tensión que existe entre las inquietudes sobre el equilibrio en relación a las Determinaciones de Expertos con incongruencias percibidas y los procesos establecidos en la Guía que estuvieron sujetos a múltiples rondas de comentarios públicos durante varios años.

        Tal como se destacó en muchos de los comentarios públicos, la adopción de un mecanismo de revisión en este punto del proceso podría ser potencialmente injusto porque los solicitantes estuvieron de acuerdo con los procesos incluidos en la Guía, los cuales no incluyen este mecanismo de revisión y los Solicitantes confiaron en estos procesos. El NGPC reconoce que, si bien en general, un mecanismo de revisión no es apropiado para la actual ronda del Programa de Nuevos gTLD, se recomienda que el desarrollo de reglas y procedimientos para rondas futuras del Programa de Nuevos gTLD (a ser desarrollados mediante un proceso de múltiples partes interesadas) explore si existe una necesidad de implementar un proceso de revisión formal con respecto a las Determinaciones de los Expertos.

      2. El NGPC consideró su rol y propósito para brindar una supervisión general del Programa de Nuevos gTLD. Uno de los componentes de las responsabilidades del NGPC al brindar una supervisión general del Programa de Nuevos gTLD es "resolver las cuestiones relativas a la aprobación de solicitudes y la delegación de gTLD, de conformidad con el Programa de Nuevos gTLD para la ronda actual de dicho Programa". (Véase Carta Orgánica del NGPC, Sección II.D). Además, la Guía para el Solicitante (sección 5.1) establece que:

        La Junta directiva de ICANN tiene la responsabilidad final por el Programa de gTLD nuevos. La Junta Directiva se reserva el derecho de considerar de manera individual una solicitud de un nuevo gTLD para determinar si su aprobación responde al mejor interés de la comunidad de Internet. En circunstancias excepcionales, la Junta Directiva puede considerar de manera individual una solicitud de gTLD. Por ejemplo, la Junta Directiva podría considerar de manera individual una solicitud como resultado del Asesoramiento del GAC sobre los Nuevos gTLD, o de la utilización de un mecanismo de responsabilidad de la ICANN.

        Abordar las Determinaciones de los Expertos sobre Objeciones por Confusión de Cadenas de Caracteres que se perciben como incongruentes o no razonables es parte de la autoridad discrecional otorgada al NGPC en su carta orgánica en relación a la " aprobación de solicitudes" y "la delegación de gTLD", además de la autoridad reservada a la Junta Directiva en la Guía para considerar solicitudes de gTLD individuales en circunstancias excepcionales. El NGPC considera que las Determinaciones de los Expertos sobre SCO identificadas presentan circunstancias excepcionales que justifican la acción por parte del NGPC porque cada una de las Determinaciones de los Expertos recae fuera de los estándares normales de lo que se percibe como razonable y justo. Si bien algunos miembros de la comunidad pueden identificar otras Determinaciones de los Expertos cómo no congruentes o no razonables, las Determinaciones de los Expertos sobre SCO identificadas son las únicas que el NGPC ha considerado apropiadas para someterlas a revisión. El NGPC señala, no obstante, que también identificó las Determinaciones de los Expertos sobre Objeción por Confusión de Cadenas de Caracteres para .CAR/.CARS las cuales no irían en pos de los intereses del Programa de Nuevos gTLD y de la comunidad de Internet. Sin embargo, dado que las partes en el conjunto controvertido .CAR/.CARS recientemente han resuelto sus solicitudes en controversia, el NGPC no está tomando medidas para enviar estas Determinaciones de los Expertos sobre SCO nuevamente al ICDR para que sean evaluadas nuevamente a fin de emitir una Determinación del Experto Final.

      3. El NGPC también analizó si existía un fundamento razonable para la existencia de ciertas Determinaciones de los Expertos percibidas como incongruentes y, particularmente, porqué aquellas identificadas debían enviarse nuevamente al ICDR mientras que otras no. El NGPC señala que, si bien, desde su punto de vista, algunas de las Determinaciones de los Expertos pueden parecer incongruentes, incluidas otras Determinaciones de los Expertos sobre SCO y las Determinaciones de los Expertos sobre los Procesos de Objeción de la Comunidad y de Interés Público Limitado, existen explicaciones razonables para esta aparente discrepancia tanto procesal y sustancialmente.

        En primer lugar, a nivel procedimental, cada panel de expertos, generalmente, fundamenta su Determinación de los Expertos en los materiales presentados por las partes de esa objeción en particular y el objetor es el que tiene la carga de la prueba. Dos paneles en los que se confrontan cuestiones idénticas podría- y si fuese apropiado debería-llegar a diferentes determinaciones sobre la base de la contundencia de los materiales presentados.

        En segundo lugar, en el plano sustantivo, ciertas Determinaciones de los Expertos destacadas por la comunidad y que supuestamente arrojaron resultados "incoherentes" o "irracionales" presentaron distinciones matizadas pertinentes a la objeción particular. Estos matices no se deberían ignorar simplemente porque una de las partes en la disputa no está de acuerdo con el resultado final. Además, el criterio que guía a los paneles de expertos implica cierto grado de subjetividad y, por lo tanto, no se esperaría que los paneles de expertos independientes lleguen a las mismas conclusiones en cada ocasión. Sin embargo, en el caso de las Determinaciones de los Expertos identificadas, una explicación razonable para estas aparentes discrepancias no es tan evidente, incluso teniendo en cuenta todas las explicaciones previas respecto de porqué razonablemente pueden existir "discrepancias". No considerar estas Determinaciones de los Expertos no iría en pos de los intereses de la comunidad de Internet.

      4. El NGPC consideró inapropiado, tal como lo sugirieron algunos comentaristas, ampliar el alcance del mecanismo de revisión propuesto para incluir otras Determinaciones de los Expertos, por ejemplo, algunas resultantes de las Objeciones de la Comunidad o del Interés Público Limitado al igual que otras Determinaciones de los Expertos sobre Objeción por Confusión de Cadenas de Caracteres y posibles versiones en singular y plural de la misma cadena. El NGPC decidió que promover los objetivos de previsibilidad e igualdad al establecer un mecanismo de revisión más amplio puede ser más apropiado como parte de los debates futuros de la comunidad en relación a las siguientes rondas del Programa de Nuevos gTLD. Los solicitantes ya han tomado medidas en virtud de las muchas Determinaciones de los Expertos que incluyen la firma de Acuerdos de Registros, transición a la delegación, retiro de sus solicitudes y pedidos de reembolso. Retroceder en estas acciones ahora, no sólo retrasaría la consideración de todas las solicitudes, sino que también plantearía cuestiones de falta de equidad para aquellos que ya han actuado en virtud de la Guía para el Solicitante.

        Se debe también notar que en respuesta al asesoramiento del Comité Asesor Gubernamental (GAC), el NGPC previamente consideró la cuestión de si la confusión por parte de los usuarios puede ser el resultado de permitir versiones en plural y singular de las mismas cadenas de caracteres. El 25 de junio de 2013, el NGPC adoptó una resolución que establecía que "no hacía falta introducir cambios en los mecanismos establecidos en la Guía para el Solicitante para evitar posibles confusiones por parte de los usuarios como resultado de que se permitan versiones en singular y plural de una misma cadena de caracteres. http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-25jun13-en.htm#2.d. El NGPC nuevamente señala que el tema de las versiones en plural y singular de una misma cadena de caracteres también puede ser objeto de otros debates dentro de la comunidad, ya que se relacionan con las rondas futuras del Programa de Nuevos gTLD

      5. El NGPC consideró la correspondencia proveniente de la comunidad sobre la cuestión, además de los comentarios de la comunidad expresados en las reuniones de la ICANN. Las inquietudes planteadas en las reuniones de la ICANN y en la correspondencia fueron objeto de debate sobre esta cuestión.

      El NGPC previamente retrasó el análisis de las recomendaciones del BGC sobre las Solicitudes de Reconsideración 13-9 y 13-10 a la espera de finalizar su revisión de las cuestiones discutidas anteriormente. Ahora que el NGPC ha tomado medidas, tal como se señaló anteriormente, reanudará el análisis de las recomendaciones del BGC sobre las Solicitudes de Reconsideración 13-9 y 13-10 tan pronto como sea factible.

      Habrá un impacto fiscal directo en la ICANN asociado con la adopción de la resolución, ya que ciertos procedimientos se enviarán nuevamente al ICDR para que sean re- evaluados por el panel de expertos compuesto de tres miembros. La aprobación de la resolución no ocasionará impacto alguno en las cuestiones de seguridad, estabilidad o flexibilidad relacionadas con el Sistema de Nombres de Dominio.

      Esta decisión forma parte de las funciones administrativas y organizacionales que requieren comentario público. El resumen de los comentarios públicos se encuentra disponible en: https://www.icann.org/en/system/files/files/report-comments-sco-framework-principles-24apr14-en.pdf [PDF, 165 KB]).

    3. Solicitud de Reconsideración 14-37, I-Registry Ltd.

      Visto y considerando que iRegistry Ltd. ("Solicitante") presentó la Solicitud de Reconsideración 14-37 en la que solicitaba al Comité para el Programa de Nuevos gTLD ("NGPC") revertir las Resoluciones 2014.07.30.NG01 – 2014.07.30.NG04 (la "Resolución") "o, al menos, enmendar" la Resolución y dejar "en suspenso" la decisión sobre cómo abordar las colisiones de nombres hasta que las cuestiones que plantea el Solicitante se hayan "resuelto".

      Visto y considerando que el BGC evaluó las cuestiones planteadas en la Solicitud de Reconsideración 14-37.

      Visto y considerando que, el BGC recomendó que la Solicitud fuese denegada debido a que el Solicitante no ha presentado fundamentos que justificaran la Reconsideración y que el Comité para el Programa de Nuevos gTLD está de acuerdo con dicha recomendación.

      Resuélvase (2014.10.12.NG04), el NGPC adopta la recomendación del BGC sobre la Solicitud de Reconsideración 14-37, la cual puede consultarse en https://www.icann.org/en/system/files/files/recommendation-i-registry-04sep14-en.pdf [PDF, 150 KB].

      Fundamentos de la Resolución 2014.10.12.NG04

      1. Resumen

        iRegistry Ltd. ("Solicitante") es un registro de nombres de dominio que cuestiona la adopción por parte del NGPC del Marco de Gestión de Incidentes de Colisiones de Nombres (el "Marco").

        Luego de llevar a cabo varios estudios independientes en relación a la cuestión de la colisión de nombres, la ICANN implementó un período de comentarios públicos desde el 26 de febrero de 2014 hasta el 21 de abril de 2014, en el cual la comunidad brindó aportes sobre posibles soluciones a la cuestión de las colisiones de nombres, incluida la cuestión de la implementación de un marco para administrar y mitigar dichas colisiones. La ICANN recibió 28 comentarios, ninguno de los cuales provinieron del Solicitante.2

        Tras tomar en cuenta los comentarios públicos recibidos, los estudios detallados que analizaban la cuestión y el asesoramiento por parte del Comité Asesor pertinente de la ICANN, el NGPC aprobó las Resoluciones 2014.07.30.NG01 – 2014.07.30.NG04 (la "Resolución")3 el 30 de julio de 2014 y adoptó el Marco. Dicho Marco establece los procedimientos que los registros deben seguir para evitar que las colisiones de nombres comprometan la seguridad o estabilidad de Internet.

        El Solicitante presentó una Solicitud instantánea (Solicitud 14-37), en la que argumentaba que el NGPC no había hecho participar al público lo suficiente en su decisión de adoptar el Marco y plantea que dicho Marco producirá una confusión entre los varios registratarios, un menor volumen de registraciones y, por lo tanto, afectará de forma adversa al Solicitante desde el punto de vista financiero. El Comité de Gobernanza de la Junta Directiva (BGC) analizó la Solicitud 14-37 y concluyó que: (i) no existe evidencia de que las acciones del NGPC al adoptar la Resolución admiten reconsideración; (ii) el Solicitante no ha demostrado que el NGPC no analizó la información relevante al aprobar la Resolución o que tomó en cuenta información relevante falsa o inexacta al aprobar la misma; (iii) el Solicitante no ha demostrado que haya sido afectado de forma adversa y significativa por la Resolución. Por lo tanto, el BGC recomendó que se denegara la Solicitud de Reconsideración 14-37 (y la totalidad de la recomendación del BGC se incorpora por referencia como si se expusiera en este fundamento). El NGPC está de acuerdo.

      2. Resumen de la Información de contexto relevante

        En cumplimiento de los valores centrales de la ICANN que apuntan a "preservar y mejorar la estabilidad operativa, confianza, seguridad e interoperabilidad mundial de Internet" (Estatutos, Artículo 1, Sección 2.1), el Comité Asesor de Seguridad y Estabilidad de la ICANN ("SSAC") público el documento SAC057: Asesoramiento del SSAC sobre Certificados de Nombre Internos del 15 de marzo de 2013.4 El informe identificó una práctica de la Autoridad de Certificación ("CA") que, si se explotase en forma general, podría presentar riesgos para la privacidad e integridad de las comunicaciones seguras mediante Internet (colisiones de nombres). El SSAC aconsejó a la ICANN que tomara medidas inmediatas para mitigar los riesgos. Las cuestiones identificadas en el documento SAC057 forman parte de la categoría más general de cuestiones de colisiones de nombres. En consecuencia, el 18 de mayo de 2013, la Junta Directiva de la ICANN aprobó una resolución en la que se encomendaba un estudio en respuesta al asesoramiento de SSAC en el documento SAC057.5

        El 5 de agosto de 2013, la ICANN publicó el estudio, preparado por Interisle Consulting Group, sobre la probabilidad y posibles consecuencias de una colisión entre las nuevas etiquetas públicas de gTLD y los usos privados existentes de las mismas cadenas de caracteres.6

        El 7 de octubre de 2013, la ICANN introdujo el Plan de Gestión de Incidentes de Colisiones de Nuevos gTLD (el "Plan"), el cual permitía el uso de una vía de delegación alternativa.7 Como parte de la Resolución que adopta el Plan, el NGPC recomendó a la Junta Directiva de la ICANN que solicite al Presidente y Director Ejecutivo de esta corporación, por un lado, que elabore un plan a largo plazo para gestionar los riesgos de colisión de nombres relacionados con la delegación de nuevos TLD y, por el otro, que trabaje con la comunidad en la elaboración de un plan a largo plazo para retener y cuantificar los datos de los servidores raíz".8

        En noviembre de 2013, la ICANN solicitó a JAS Global Advisors LLC ("JAS") que lidere el desarrollo del Marco en cooperación con la comunidad.9

        Desde el 26 de febrero de 2014 hasta el 21 de abril de 2014, la ICANN implementó un período de comentarios públicos durante el cual la comunidad brindó aportes sobre las posibles soluciones a la cuestión de la colisión de nombres, incluida la cuestión de la implementación de un marco para administrar y mitigar dichas colisiones; la ICANN recibió 28 comentarios, ninguno de los cuales provino del Solicitante.10 El Solicitante no participó en el foro de comentarios públicos. Luego de recabar los comentarios públicos, JAS publicó la versión final de su Informe Fase Uno en la Mitigación de Riesgos de Colisiones en el Espacio de Nombres del DNS.11

        El 6 de junio de 2014, el SSAC publicó el documento SAC066: Comentario del SSAC en relación al Informe sobre la Etapa Uno en la Mitigación de Riesgos de Colisiones en el Espacio de Nombres del DNS, el cual brindó asesoramiento y recomendaciones a la Junta Directiva sobre el marco presentado en el Estudio y el Marco de Colisiones de Nombres realizados por JAS.12

        El 27 de julio de 2014, el Solicitante envió una carta a la ICANN: (i) en la que le solicitaba "evaluar concienzudamente" una propuesta para abordar el problema de las colisiones de nombres; y (ii) brindar cinco propuestas específicas respecto de cómo se podría abordar la cuestión. (Solicitud, Ex. D.) La ICANN acusó recibo de la carta del Solicitante el 29 de julio de 2014. (Solicitud, Ex. E.)

        El 30 de julio de 2014, el NGPC aprobó las Resoluciones 2014.07.30.NG01 – 2014.07.30.NG04 (la "Resolución") que adoptaban el Marco. El Marco establece los procedimientos que los registros deben seguir para evitar que las colisiones de nombres comprometan la seguridad o estabilidad Internet e instruyó al Presidente y Director Ejecutivo, o quien éste designe, tomar las medidas necesarias para implementar el Marco.13

        El 4 de agosto de 2014, la División Global de Dominios de la ICANN emitió para cada operador de registro de nuevos gTLD una Evaluación de Incidentes de Colisiones de Nombres ("Evaluación"), la cual identificaba qué medida debían tomar los registros a fin de evitar cuestiones de colisiones de nombres de acuerdo con el Marco. En esa misma fecha, el Solicitante recibió la Evaluación vía correo electrónico. (Solicitud, Ex. A.)

        El 12 de agosto de 2014, la ICANN presentó un seminario web en el que explicaba las generalidades del Marco orientado específicamente a los operadores de registro.15

        El 13 de agosto de 2014, el Solicitante presentó una Solicitud instantánea en la que buscaba la reconsideración de la Resolución del NGPC.

        Si bien el tratamiento de una categoría de nombres afectada por la cuestión de la colisión de nombres no es aún parte del Marco, la ICANN se encuentra en el proceso de recabar aportes del público sobre este tema. Específicamente, la ICANN ha abierto un foro de comentarios públicos sobre esta cuestión en particular, el cual se extenderá desde el 5 de agosto de 2014 hasta el 7 de octubre de 2014.16

        El 4 de septiembre de 2014, el Comité de Gobernanza de la Junta Directiva ("BGC") emitió su recomendación en relación a la Solicitud de Reconsideración 14-37.17 El 11 de septiembre de 14, el Solicitante presentó una Aclaración de la Solicitud de Reconsideración 14-37,18 que contenía más detalles alegados en relación a cómo el Solicitante ha sido significativamente afectado por la Resolución y la adopción del Marco.

      3. Cuestiones

        Las cuestiones presentadas para reconsideración son si el NGPC:

        1. No consideró los aportes significativos de la comunidad al aprobar la Resolución (Solicitud § 8, Pág. 11); y
        2. Subestimó incorrectamente las posibles consecuencias negativas de la Resolución. (Ídem, § 8, Págs. 7-8.).
      4. Normas pertinentes a la evaluación de solicitudes de reconsideración

        De acuerdo con los Estatutos de la ICANN, el BGC debe evaluar y, en el caso de que exista una acción de la Junta Directiva (o NGPC) que sea cuestionada, plantear recomendaciones a la Junta Directiva con relación a las Solicitudes de Reconsideración. Véase la Sección 2 del Artículo IV de los Estatutos. El NGPC, a quien se delegaron las facultades de la Junta Directiva en este asunto, ha examinado y debatido en profundidad la recomendación del BGC relacionada con la Solicitud 14-37 y opina que el análisis ha sido sólido.19

      5. Análisis y fundamentos

        El Solicitante no ha demostrado que la Junta Directiva no consideró la información relevante o tomó en cuenta información relevante falsa o inexacta al aprobar las Resoluciones; por lo tanto, la reconsideración no es procedente.

        1. La Solicitud Justifica la Desestimación Sumaria.

          El BGC concluyó, y el NGPC concuerda, que el Solicitante no tiene fundamentos porque el mismo "estaba notificado y tuvo la oportunidad, pero no lo hizo, de participar en el período de comentarios públicos en relación a la acción cuestionada". (Estatutos, Artículo IV, § 2.9.) Específicamente, los Estatutos de la ICANN permiten al BGC desestimar de manera sumaria una Solicitud de Reconsideración si "el Solicitante estaba notificado y tuvo la oportunidad, pero no lo hizo, de participar en el período de comentarios públicos en relación a la acción cuestionada". (Estatutos, Artículo IV, § 2.9.)

          Desde el 26 de febrero de 2014 hasta el 21 de abril de 2014, la ICANN implementó un período de comentarios públicos, que fue anunciado el sitio web de la corporación, en el cual la comunidad brindó aportes sobre la solución posible, que incluía un marco para las cuestiones de colisión de nombres.20 El foro generó 28 comentarios, pero el Solicitante no participó en el foro de comentarios públicos y no ofreció justificación, excusa o explicación para su decisión de no participar. La única comunicación que asegura haber tenido con la ICANN en relación a la colisión de nombres es una carta con fecha del 27 de julio de 2014 que fue muy posterior al cierre del período de comentarios públicos.21 Dado que el período de comentarios públicos en cuestión está indefectiblemente relacionado con la Resolución, se justifica una desestimación sumaria sobre la base de la no participación del Solicitante. No obstante, en aras de la exhaustividad, el NGPC abordará, los fundamentos de la Solicitud.

        2. El NGPC consideró toda la información relevante.

          El BGC concluyó, y el NGPC concuerda, que el Solicitante no ha demostrado que el NGPC no consideró la información relevante.

          A fin de expresar una base para la reconsideración de una acción de la Junta Directiva, el Solicitante debe demostrar que la Junta (o, en este caso, el NGPC), no tomó en cuenta la información relevante o consideró información relevante falsa o inexacta al adoptar la Resolución. (Estatutos, Artículo IV, § 2.2.) El Solicitante no argumenta que el NGPC consideró información relevante falsa o inexacta, pero señala que el Comité no tomó en cuenta información relevante de dos maneras. Primero, el Solicitante alega que el NGPC no consultó con el público lo suficiente antes de adoptar la Resolución. En segundo lugar, señala que el NGPC no tomó en cuenta de qué forma la Resolución tendrá efectos significativamente adversos para los registros y usuarios de Internet. Ninguno de estos argumentos resiste el escrutinio y tampoco es motivo para la reconsideración.

          1. El NGPC consideró los Comentarios Públicos solicitados durante un extenso Periodo de Comentarios Públicos.

            El Solicitante alega que el NGPC "no tomó en cuenta los aportes significativos de la comunidad". (Solicitud, § 8, página 11). Contrario a lo que alega el Solicitante, el NGPC sí consideró el aporte recibido en "el foro de comentarios públicos"22 que estuvo abierto desde el 26 de febrero de 2014 hasta el 21 de abril de 2014. El Solicitante no explica por qué no participó en dicho foro. Si hubiese participado, sus puntos de vista habrían sido incluidos junto con los 28 comentarios detallados tomados en cuenta que fueron presentados por varias partes interesadas y miembros del público, incluidos otros registros.23 Cabe destacar que el período de comentarios públicos para esta cuestión fue, en realidad, más extenso de lo requerido. Por lo general, los período de comentarios públicos permanecen abiertos durante 21 días y, si se reciben comentarios durante dicho período, hay un período de respuesta de 21 días.24 Aquí el período de comentarios públicos permaneció abierto durante 33 días, seguido de un período de respuesta de 21 días. Además, la ICANN facilitó una sesión pública dedicada a la cuestión de las colisiones de nombres en la reunión de la ICANN celebrada en Londres, el 23 de junio de 2014 que brindó también otra oportunidad para los comentarios públicos y la participación; una vez más, el Solicitante eligió no participar25 Consecuentemente, el Solicitante no puede reclamar de forma razonable que el NGPC no tomó en cuenta el aporte del público antes de adoptar la Resolución.

            En resumen, el Solicitante no argumenta de forma persuasiva el hecho de que NGPC no haya tomado en cuenta la información relevante en forma de comentarios públicos al adoptar la Resolución y, por lo tanto, no ha presentado los fundamentos adecuados para la reconsideración sobre esa base. (Estatutos, Artículo IV, § 2.2.)

          2. El NGPC consideró toda la información relevante pertinente a la Resolución.

            El Solicitante busca que se reconsidere la Solicitud porque alega que el NGPC "no evaluó correctamente las consecuencias de la decisión". (Solicitud, § 8, página 12). El principal fundamento del Solicitante para realizar esta afirmación es que las cuestiones planteadas en su propia carta con fecha del 27 de julio de 2014 no fueron expresamente abordadas en la sección de los "Fundamentos" de la Resolución. Este argumento no proporciona una base para la reconsideración por dos motivos.

            En primer lugar, en la Resolución se toma en cuenta la sustancia de la información brindada en la carta del Solicitante con fecha del 27 de julio de 2014. En dicha carta se realizaron cinco pedidos, todos relacionados con las "Reglas de RPM" o el punto de vista del Solicitante de que se debería aplicar un conjunto común de reglas a todos los gTLD. (Solicitud, § 8, página 10 y Ex. D.) A pesar de las afirmaciones del Solicitante en sentido contrario, las mismas cuestiones planteadas en la carta de 27 de julio de 2014 fueron presentadas al NGPC durante el período de comentarios públicos por otras partes interesadas y fueron abordadas por dicho Comité. La Resolución reconoce que el NGPC consideró los comentarios públicos que: (i) expresaban inquietud respecto de la "interacción entre las listas de bloqueo de colisión de nombres y los mecanismos de protección de derechos de propiedad intelectual" 26; (ii) hacían referencia a cómo la "cuestión de la colisión de nombres está creando un escenario competitivo desigual" y (iii) debatían los pros y los contras de tratar a los operadores de nuevos gTLD de forma diferente en relación a los operadores legados.27 Además, la ICANN ha determinado que la cuestión de los RPM requiere más comentarios públicos antes de que sea posible tomar una decisión sobre cómo manejar la cuestión. En realidad, la ICANN, en este momento, está solicitando comentarios, entre el 25 de agosto de 2014 y 17 de octubre de 2014, sobre el enfoque que se debería tomar "en relación a los Mecanismos de Protección de Derechos adecuados para liberar nombres en las Listas de Bloqueo de SLD".28 En otras palabras, el NGPC no carecía de ninguna información relevante sobre las cuestiones aplicables, independientemente de si consideró específicamente la carta del Solicitante con fecha del 27 de julio de 2014.

            En segundo lugar, el desacuerdo del Solicitante con la sustancia del Marco no conforma una base adecuada para la Reconsideración. El NGPC tomó en cuenta los estudios independientes detallados que debatían la cuestión de la colisión de nombres, incluido uno preparado por JAS y otro realizado por Interisle Consulting Group.29 Además, el NGPC tomó en consideración del asesoramiento de SSAC antes de adoptar la Resolución. El rol del SSAC es asesorar a la comunidad y a la Junta Directiva de la ICANN sobre asuntos relativos a la seguridad y la integridad de los sistemas de asignación de nombres y direcciones en Internet. (Estatutos, Artículo XI, § 2.a) En síntesis, el NGPC consideró los comentarios públicos, los informes analíticos independientes y el asesoramiento del Comité asesor de la ICANN pertinente. Si bien el Solicitante reclama que el NGPC "no mencionó la carta" (que el Solicitante envió meses posteriores al cierre del período de comentarios públicos) y por lo tanto, "no abordó de manera adecuada las consecuencias de la decisión" para aprobar el marco, dichos alegatos no fundamentan el reclamo de que el NGPC no consideró toda información relevante. En consecuencia, no se justifica la reconsideración.

            Como nota final, el Solicitante también reclama que la de reconsideración está justificada porque "no hay indicación de que el GAC30 haya tenido la oportunidad de brindar comentarios" a los informes de JAS o al asesoramiento del SSAC. (Solicitud, § 7, Pág. 7) El GAC brinda "asesoramiento sobre las actividades de la ICANN en la medida en que se relacionen con las cuestiones de gobierno, en especial, los asuntos donde las políticas de la ICANN y diversas leyes o acuerdos internacionales podrían afectarse recíprocamente o donde podrían afectar cuestiones sobre normativa pública". (Estatutos, Artículo XI, § 2.1.) El hecho de que GAC no emitiera ningún asesoramiento formal en relación a cómo la ICANN debería abordar las colisiones de nombres no significa que el NGPC no haya tomado en cuenta toda la información relevante. Si el GAC hubiese emitido dicho asesoramiento, la Junta Directiva de la ICANN lo habría considerado tal como lo requieren los Estatutos de la ICANN. (Estatutos, Artículo XI, §§ 2.1.i, 2.1.j.) Además, en julio de 2013, en el Comunicado del GAC pronunciado en Durban se recomendó que la Junta Directiva "de forma urgente considerara las recomendaciones contenidas en el informe del SSAC sobre los Dominios Sin Punto (SAC053) y los Certificados de Nombres Internos (SAC 057)" y este último tenía relación con las cuestiones de colisiones de nombres.31 La Junta Directiva sí consideró el asesoramiento del SSAC, y a su vez, adoptó el Marco.

            Nuevamente, dado que el Solicitante no demuestra que el NGPC no consideró la información relevante al adoptar la Resolución, la reconsideración no es procedente. (Estatutos, Artículo IV, § 2.2.)

        3. La confusión alegada no constituye un fundamento para la reconsideración.

          El BGC concluye, y el NGPC concuerda, que el Solicitante no ha demostrado que el NGPC no consideró la información relevante en relación a la importancia de educar al público sobre el Marco.

          El Solicitante reclama que el NGPC no consideró el supuesto hecho de que la "mayoría absoluta" de los registratarios no están al tanto del problema de la colisión de nombres y, por lo tanto, estarán confundidos respecto de la disponibilidad de los nombres de dominio en general". (Solicitud, § 7, página 6). Sin embargo, es evidente que el NGPC sí consideró la información en relación a la importancia de educar al público sobre el Marco. La Resolución dedica una cláusula entera (Sección B.6) a los "Materiales Informativos" y solicita a la ICANN que "cree material informativo según sea necesario . . . y que trabaje para que esta información esté disponible para las partes posiblemente afectadas por las colisiones de nombres".32 Aunque el Marco acaba de ser adoptado, la ICANN ya ha publicado y dispuesto una amplia variedad de materiales informativos que incluyen seminarios web destinados a los operadores de registros, manuales y videos para profesionales de Tecnología de la Información y una página de "Preguntas Frecuentes" en relación al Marco.33 Además, la ICANN ha dedicado recursos para garantizar que las preguntas en relación a la Evaluación o el Marco se respondan en tiempo y forma. En otras palabras, lejos de no considerar la posibilidad de confusión en relación a la Resolución, la ICANN ha tomado medidas significativas de protección para garantizar que las partes afectadas comprendan el Marco y los pasos que requiere.34 No se justifica la reconsideración con el argumento de que el NGPC no consideró la información sobre la difusión pública, ya que resulta claro que el NGPC tomó en cuenta dicha información y tomó medidas al respecto de la forma que se explica anteriormente.

        4. El Solicitante no ha demostrado que haya sido significativamente afectado por la Resolución.

          El BGC concluyó, y el NGPC acuerda, que el Solicitante no ha demostrado que haya sido afectado de forma adversa y significativa por la Resolución.

          Ante la falta de evidencia de que el Solicitante haya sido afectado de forma significativa y adversa por la Resolución, la reconsideración no resulta procedente. (Estatutos, Artículo IV, §§ 2.1-2.2.) Aquí, el Solicitante alega que se ve afectado de forma significativa por la Resolución por dos razones. (Solicitud § 6, Págs. 4-5.) En primer lugar, reclama que el Marco no brinda pautas claras respecto de cómo prevenir los daños relacionados con las colisiones de nombres. (Ídem, Página. 5.) En segundo lugar, señala que sufrirá "una reducción de las tasas de registración" debido a la confusión que supuestamente causará el Marco, dado que el Solicitante predice que los registradores no "ofrecerán registraciones de nombres de dominio de las listas de colisiones de nombres". (Ídem). No obstante, ninguna de estas inquietudes se ha concretado y ambas son meramente especulativas en este punto. 35 Una vez más, únicamente aquellas personas que "han sido afectadas de forma adversa por" una acción de la ICANN puede presentar una Solicitud de Reconsideración. (Estatutos, Artículo IV, Sección 2.2) (énfasis agregado). Dado que el único daño que el Solicitante identifica es, en este punto, meramente especulativo e hipotético, la Solicitud de Reconsideración resulta prematura.36

          En tal sentido, el Solicitante no ha demostrado que resultó afectado de forma significativa por la Resolución y, sobre esta base independiente, la reconsideración de la adopción de la Resolución no se justifica.

      6. Decisión

        El NGPC tuvo la oportunidad de analizar todos los materiales presentados por el Solicitante, o en su representación, o que de otro modo estén relacionados con la Solicitud 14-37. Tras analizar toda la información pertinente en su poder, el NGPC evaluó y adoptó la recomendación del BGC sobre la Solicitud 14-37, cuyo texto completo está disponible en https://www.icann.org/en/system/files/files/recommendation-i-registry-04sep14-en.pdf [PDF, 150 KB], la cual debe ser considerada como parte de los fundamentos y que se incluye en los Materiales de Referencia presentados ante el NGPC en el marco del tratamiento de esta cuestión.

        La adopción de la recomendación del BGC no tiene un impacto económico directo en la ICANN y no se observará un impacto negativo en la seguridad, la estabilidad ni en la flexibilidad estructurales del sistema de nombres de dominio.

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

    4. Asesoramiento del GAC en materia de Protecciones para la Cruz Roja y la Media Luna roja-Comunicado pronunciado en Singapur

      Visto y considerando que, el GAC se reunió durante la reunión 49 de la ICANN en Singapur y emitió un Comunicado [PDF., 449 KB] el día 27 de marzo del 2014 ("Comunicado Pronunciado en Singapur").

      Visto y considerando que, en el Comunicado pronunciado en Singapur, el GAC aclaró su asesoramiento previo a la Junta Directiva de la ICANN para proteger de forma permanente del uso no autorizado los términos asociados con la Cruz Roja Internacional y el Movimiento de la Media Luna Roja y recomendó que estas protecciones incluyeran también a las "189 Sociedades Nacionales de la Cruz Roja y la Media Luna Roja, en inglés y en los idiomas oficiales de los respectivos estados de origen" y los "nombres completos del Comité Internacional de la Cruz Roja y la Federación Internacional de la Cruz Roja y las Sociedades de la Media Luna Roja en los seis (6) idiomas de Naciones Unidas". El Asesoramiento del GAC se encuentra identificado en el Registro de Asesoramiento del GAC como 2014-03-27-RCRC.

      Visto y considerando que, la GNSO ha desarrollado recomendaciones de política para la Junta Directiva en relación a los nombres de la Cruz Roja y la Media Luna Roja que son objeto del comunicado del GAC pronunciado en Singapur. El alcance de las protecciones en las recomendaciones de política de la GNSO difieren del asesoramiento del GAC, y el GAC, la GNSO, la Junta Directiva y la comunidad de la ICANN continúan trabajando activamente para resolver estas diferencias.

      Visto y considerando que el NGPC es responsable de considerar el Asesoramiento del GAC conforme a la autoridad que le fue concedida por la Junta Directiva el 10 de abril de 2012, que lo habilita a ejercer la autoridad de la Junta Directiva de la ICANN respecto de todas y cada una de las cuestiones que puedan surgir con relación al Programa de Nuevos gTLD.

      Resuélvase (2014.10.12.NG05), se instruye al Presidente y Director Ejecutivo, o a quien éste designe, brindar las protecciones temporarias para los nombres del Comité Internacional de la Cruz Roja y la Federación Internacional de la Cruz Roja y las Sociedades de la Media Luna Roja y las 189 Sociedades Nacionales de la Cruz Roja y la Media Luna Roja, identificadas en el registro de asesoramiento del GAC como 2014-03-27-RCRC , mientras que el GAC, la GNSO, la Junta Directiva y la comunidad de la ICANN continúan trabajando activamente para resolver las diferencias en el asesoramiento del GAC y las recomendaciones de políticas de la GNSO sobre el alcance de las protecciones para los nombres RCRC.

      Fundamento de la Resolución 2014.10.12.NG05

      El NGPC está tomando medidas para brindar protección temporal a los nombres de la Cruz Roja/Media Luna Roja (RCRC) identificados en el asesoramiento del GAC en su Comunicado pronunciado en Singapur y, al mismo tiempo, toma muy en cuenta los debates pendientes entre el GAC, la GNSO, la Junta Directiva y la comunidad de la ICANN para trabajar activamente en la Resolución de las diferencias entre el asesoramiento del GAC y las recomendaciones de política la GNSO en relación al alcance de las protecciones para los nombres RCRC.

      La Sección 2.1 del Artículo XI de los Estatutos de la ICANN permite al GAC "presentar asuntos a la Junta Directiva directamente, ya sea por medio de un comentario o asesoramiento previo, o por medio de acciones de recomendación específica, el desarrollo de nuevas políticas o la revisión de las políticas existentes." El GAC emitió asesoramiento a la Junta Directiva sobre el Programa de Nuevos gTLDs a través de su Comunicado pronunciado en Singapur con fecha del 27 de marzo del 2014 ("Comunicado pronunciado en Singapur"). Los Estatutos de la ICANN requieren que la Junta Directiva tome en cuenta el asesoramiento del GAC respecto de las cuestiones de política pública 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. La Junta Directiva y el GAC intentarán, entonces, de buena fe, hallar una solución que sea aceptable para ambos. En caso de que no fuese posible llegar a una solución, la Junta Directiva informará, en su decisión final, los motivos por los cuales no siguió el asesoramiento del GAC.

      En el Comunicado pronunciado en Singapur el GAC aclaró su asesoramiento previo a la Junta Directiva de la ICANN para proteger de forma permanente del uso no autorizado los términos asociados con la Cruz Roja Internacional y el Movimiento de la Media Luna Roja y recomendó que estas protecciones incluyeran también a las "189 Sociedades Nacionales de la Cruz Roja y la Media Luna Roja, en inglés y en los idiomas oficiales de los respectivos estados de origen" y los "nombres completos del Comité Internacional de la Cruz Roja y la Federación Internacional de la Cruz Roja y las Sociedades de la Media Luna Roja en los seis (6) idiomas de Naciones Unidas".

      La GNSO también brindó recomendaciones de política a la Junta Directiva de la ICANN sobre los mismos nombres RCRC que son objeto del asesoramiento del GAC en el Comunicado pronunciado en Singapur. A diferencia del asesoramiento del GAC, las recomendaciones de política de la GNSO no solicitan protecciones permanentes para el conjunto de nombres de RCRC. En cambio, la política de la GNSO recomienda que estos nombres sean protegidos mediante su ingreso en el TMCH para una notificación de reclamos de 90 días.

      El 30 de abril de 2014, la Junta Directiva de la ICANN adoptó las recomendaciones de política del Consejo de la GNSO en materia de protecciones a las OIG- OING que no eran incompatibles con el asesoramiento del GAC y solicitó más tiempo para considerar las recomendaciones de política restantes que son incompatibles con el asesoramiento del GAC sobre el mismo tema. La Junta Directiva se comprometió a facilitar las discusiones entre las partes pertinentes para reconciliar las diferencias aún existentes entre las recomendaciones de políticas y el asesoramiento del GAC sobre el tema y, previamente, encomendó al NGPC la tarea de colaborar con este proceso. El NGPC está tomando medidas para brindar protección temporal a los nombres RCRC identificados en el asesoramiento del GAC en su Comunicado pronunciado en Singapur y, al mismo tiempo, toma muy en cuenta los debates pendientes entre el GAC, la GNSO, la Junta Directiva y la comunidad de la ICANN para trabajar activamente en la resolución de las diferencias entre el asesoramiento del GAC y las recomendaciones de política la GNSO en relación al alcance de las protecciones para los nombres RCRC.

      La acción del NGPC tendrá un impacto positivo en la comunidad, ya que dispondrá protecciones temporales para los nombres RCRC y permitirá, al mismo tiempo, continuar con los debates. Como parte de sus deliberaciones, el NGPC analizó los siguientes materiales y documentos significativos:

      No se observan impactos fiscales previstos asociados con la adopción de esta Resolución. La aprobación de la resolución propuesta no impactará en las cuestiones de seguridad, estabilidad o flexibilidad relacionadas con el DNS. Esta acción no es proceso de políticas definido dentro de las organizaciones de apoyo de la ICANN o de la decisión de función organizacional y administrativa de la ICANN que requiera o no comentario público. Las acciones posteriores relacionadas con las protecciones para RCRC pueden estar sujetas a comentarios públicos.

    5. Otros asuntos

      No se adoptó ninguna resolución.

Published on 14 October 2014


1 Traducción en idioma japonés de "compra en línea"

2 Véase Informe de Comentarios Públicos disponible en https://www.icann.org/en/system/files/files/report-comments-name-collision-10jun14-en.pdf [PDF, 229 KB].

3 Véase Resolución en disponible en https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-07-30-en.

4 Véase https://www.icann.org/en/system/files/files/sac-057-en.pdf [PDF,1.13 MB].

5 Véase https://features.icann.org/ssac-advisory-internal-name-certificates.

6 Véase Cómo abordar las Consecuencias de las Colisiones de Nombres, disponible en https://www.icann.org/news/announcement-3-2013-08-05-en.

7 Véase Preguntas Frecuentes sobre el Plan de Gestión de Incidentes de Colisiones de Nuevos gTLD, disponible en https://www.icann.org/news/announcement-2013-12-03-en.

8 Véase https://www.icann.org/resources/board-material/resolutions-new-gtld-2013-10-07-en#1.a.

9 Véase https://www.icann.org/resources/pages/name-collision-2013-12-06-en.

10 Véase Informe de Comentarios Públicos disponible en https://www.icann.org/en/system/files/files/report-comments-name-collision-10jun14-en.pdf [PDF, 229 KB].

11 Véase Informe de JAS, disponible en https://www.icann.org/en/system/files/files/name-collision-mitigation-study-06jun14-en.pdf [PDF, 391 KB].

12 Véase https://www.icann.org/en/system/files/files/sac-066-en.pdf [PDF, 305 KB].

13 Véase Resolución en disponible en https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-07-30-en.

14 Véase Evaluación de Incidentes de Colisiones de Nombres, disponible en http://newgtlds.icann.org/sites/default/files/agreements/name-collision-assessment-04aug14-en.pdf [PDF, 91 KB].

15 Véase https://www.icann.org/resources/pages/name-collision-2013-12-06-en.

16 Véase Implementación de los Mecanismos de Protección de Derechos en el Marco de Mitigación de Colisiones de Nombres, disponible en https://www.icann.org/public-comments/name-collision-rpm-2014-08-25-en.

17 https://www.icann.org/en/system/files/files/recommendation-i-registry-04sep14-en.pdf [PDF, 150 KB]

18 https://www.icann.org/en/system/files/files/clarification-i-registry-11sep14-en.pdf [PDF, 59 KB]

19 La existencia de un proceso de reconsideración mediante el cual el BGC examina y, si lo desea, plantea recomendaciones a la Junta Directiva o al NGPC para su aprobación tiene un impacto positivo en la responsabilidad y la transparencia de la ICANN. Este proceso ofrece una alternativa para garantizar a la comunidad que el personal y la Junta Directiva están actuando de conformidad con las políticas, los Estatutos y el Acta Constitutiva de la ICANN.

20 Véase Informe de Comentarios Públicos disponible en https://www.icann.org/en/system/files/files/report-comments-name-collision-10jun14-en.pdf [PDF, 229 KB].

21 El Solicitante señala que envió una carta al NGPC "con mucha antelación" a la reunión del NGPC, pero dicha declaración es incorrecta dado los escasos tres días entre la fecha de la carta y la reunión del NGPC del 30 de julio de 2014. (Véase Solicitud, § 8, página 9).

22 Véase Resolución en disponible en https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf [PDF, 634 KB].

23 Véase Informe de Comentarios Públicos disponible en https://www.icann.org/en/system/files/files/report-comments-name-collision-10jun14-en.pdf [PDF, 229 KB].

24 Véase https://www.icann.org/resources/pages/how-2014-03-17-en

25 Véase Presentación sobre Colisión de Nombres, Londres: ICANN 50, disponible en https://london50.icann.org/en/schedule/mon-name-collision/presentation-name-collision-23jun14-en.

26 Véase Resolución en disponible en https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf [PDF, 634 KB].

27 Véase Informe de Comentarios Públicos, en Pág. 11 disponible en https://www.icann.org/en/system/files/files/report-comments-name-collision-10jun14-en.pdf [PDF, 229 KB].

28 Véase Implementación de los Mecanismos de Protección de Derechos en el Marco de Mitigación de Colisiones de Nombres, disponible en disponible en https://www.icann.org/public-comments/name-collision-rpm-2014-08-25-en

29 Véase Resolución en disponible en https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-07-30-en.

30 Comité Asesor Gubernamental.

31 Véase Comunicado del GAC emitido en la reunión ICANN 47, disponible en https://www.icann.org/news/announcement-2013-07-18-en; SAC057, disponible en https://www.icann.org/en/system/files/files/sac-057-en.pdf [PDF, 1.13 KB].

32 Véase Resolución en disponible en https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf [PDF, 634 KB].

33 Véase Recursos e Información sobre Colisiones de Nombres, disponible en https://www.icann.org/resources/pages/name-collision-2013-12-06-en.

34 La ICANN ha también participado en actividades de difusión externa significativas en LinkedIn y mediante varios canales de las redes sociales, así como el lanzamiento de una promoción mediante Google Adwords.

35 En realidad, el Marco ahora permitirá que se activen los nombres en el DNS que previamente no estaba permitido activar. Por lo tanto, el Marco bien puede llevar a un incremento de las registraciones.

36 El 11 de septiembre de 2014, luego de que el BGC emitiera su recomendación, el Solicitante presentó una aclaración a la Solicitud de Reconsideración 14-37, en la que supuestamente brindaba detalles adicionales en relación a las formas en las cuales el Solicitante había sido afectado de forma significativa y adversa por la Resolución. A pesar de sus reclamos en contrario, los alegatos continuados del Solicitante sobre posibles daños son aún especulativos e hipotéticos.

resolutions-new-gtld-12oct14-es.pdf  [429 KB]

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."