Módulo 7 Procedimientos de evaluación de la cadena de caracteres y solicitudes

El Programa de Nuevos gTLD: Ronda 2026 representa una evolución fundamental de la infraestructura de Internet. Si bien el entusiasmo por las potenciales nuevas extensiones de nombres de dominio es elevado, el proceso de evaluación de cadenas de caracteres y solicitudes está diseñado para proteger la estabilidad del DNS mientras se abordan las preocupaciones de las partes interesadas. Cada cadena de caracteres debe ser meticulosamente analizada en cuanto a singularidad, claridad y potencial confusión con marcas comerciales o cadenas de caracteres existentes para garantizar que no comprometa la integridad general del DNS.

Para tipos específicos de solicitudes, la evaluación de la participación con la comunidad del solicitante y su compromiso con la transparencia y responsabilidad es especialmente crítica.

El Módulo 7 describe el proceso de evaluación, que incluye:

Descripción general de los tipos de solicitud y métodos de tratamiento.
Examen de tipos de TLD, como nombres geográficos y nombres de dominio internacionalizados.
Estrategias para mitigar colisiones de nombres.
Evaluación de la similitud entre cadenas de caracteres.

Este módulo proporciona una mirada detallada a este proceso esencial y cuidadosamente diseñado para garantizar la estabilidad y seguridad del DNS.

7.1 Tipos de cadenas de caracteres y solicitudes

Los solicitantes pueden encontrar diferentes requisitos y pasos de procesamiento dependiendo del tipo de solicitud o cadena de caracteres que soliciten. Estas variaciones pueden afectar los siguientes aspectos:

Preguntas incluidas en la solicitud: Algunos tipos de solicitud requerirán que el solicitante responda preguntas especializadas como parte de su solicitud (por ejemplo, preguntas relacionadas con los objetivos comunitarios de un solicitante).
Priorización: Ciertos tipos de solicitud podrían recibir prioridad en el sorteo de priorización (por ejemplo, un IDN).¹
Evaluación: La naturaleza, enfoque u objetivo de una solicitud puede requerir una evaluación especializada (por ejemplo, para un nombre geográfico).
Controversia: Los procedimientos de resolución de controversias pueden ser específicos en función del tipo de solicitud (por ejemplo, Evaluación con prioridad de la comunidad).
Acuerdo de Registro: Algunos tipos de solicitud pueden considerarse exentos de ciertas disposiciones mientras que otros pueden estar obligados a incluir disposiciones especializadas en sus Acuerdos de Registro Base (por ejemplo, Exención al código de conducta).
Tarifas: Pueden requerirse tarifas adicionales de evaluación o solicitud (por ejemplo, para evaluaciones condicionales, como la Evaluación con prioridad de la comunidad).

Los solicitantes deben revisar la información en esta sección para comprender las posibles diferencias en los requisitos para distintos tipos de solicitud.²

7.1.1 Solicitudes generales

Una solicitud general es aquella que no se corresponde con uno de los tipos de solicitud definidos en la Sección 7.1.2 Solicitudes especializadas y está sujeta al conjunto estándar de requisitos definidos a lo largo de esta Guía para el Solicitante.

7.1.2 Solicitudes especializadas

Las solicitudes especializadas son aquellas que pueden tener diferentes requisitos según la solicitud (por ejemplo, una solicitud para un gTLD de la comunidad), cadena de caracteres (por ejemplo, un IDN) o tipo de solicitante (por ejemplo, una OIG o un solicitante de Apoyo para Solicitantes). Esta sección proporciona una descripción general de estos tipos de solicitudes especializadas. Una solicitud puede calificar para múltiples designaciones simultáneamente; por ejemplo, una solicitud podría clasificarse tanto como un IDN o como una Solicitud de una comunidad.

7.1.2.1 Solicitudes de gTLD de la comunidad

Al momento de la presentación de la solicitud, un solicitante puede designar una cadena de caracteres de gTLD solicitada como gTLD de la comunidad.³ Dicho solicitante debe gestionar la cadena de caracteres en beneficio de una comunidad claramente delimitada (consultar la Sección 5.4 Evaluación con prioridad de la comunidad). Los solicitantes que presenten una Solicitud de la comunidad estarán sujetos a requisitos adicionales a lo largo de varias etapas del ciclo de vida de la solicitud, incluidas las siguientes áreas:

Preguntas incluidas en la solicitud: Los solicitantes que designen su solicitud como solicitud comunitaria deberán responder a una serie de preguntas específicas para las solicitudes comunitarias.⁴ Las respuestas a estas preguntas se evaluarán si el solicitante decide participar en la CPE. Consultar el Apéndice 1 Preguntas incluidas en la solicitud (Conjunto de preguntas 7 gTLD de la comunidad).
Evaluación: La evaluación de las Políticas de registración para la comunidad del Acuerdo de Registro ("Políticas de registración para la comunidad") —a través de la Evaluación de compromisos de los operadores de registro (RCE)— propuestas para su inclusión en el Acuerdo de Registro con respecto a la operación de un gTLD de una comunidad solicitado ocurrirá durante la evaluación de la solicitud, a menos que el Solicitante de la comunidad opte por participar en la CPE, que es una opción disponible solo para Solicitudes de una comunidad para resolver la disputa. Si el solicitante opta por participar en la CPE, la RCE se llevará a cabo antes, previo a la evaluación de la solicitud, porque esta evaluación debe realizarse antes de que la solicitud sea elegible para participar en la CPE. Consultar la Sección 7.8 Compromisos en pos del interés público, Compromisos voluntarios de los operadores de registro y Políticas de registración para la comunidad.
Controversia: Si se encuentra en disputa con otras solicitudes para la misma cadena de caracteres, el solicitante puede optar por participar en la Evaluación con prioridad de la comunidad (Consultar la Sección 5.4) y potencialmente en una Subasta de la ICANN. Consultar la Sección 5.2 Controversia por cadenas de caracteres y procedimientos de resolución de controversias.
Contratación: El solicitante debe enumerar las Políticas de registración para la comunidad que son evaluadas y aprobadas por la ICANN y, cuando sea pertinente, evaluadas durante la CPE, en la Especificación 12 de su Acuerdo de Registro Base. Consultar la Sección 1.2.15 Contratación. Consultar también la Sección 7.8.4 Políticas de registración para la comunidad a continuación referente a la evaluación de las Políticas de registración para la comunidad.
Tarifas: Si un solicitante opta por participar en la CPE, el solicitante debe pagar una tarifa de evaluación adicional. Consultar la Sección 3.3 Tarifas y pagos.

La ICANN evaluará todas las Políticas de registración para la comunidad propuestas por los solicitantes para los gTLD de comunidades para su inclusión en el Acuerdo de Registro aplicable durante la evaluación de la solicitud. Como mínimo, estas políticas deben cubrir la elegibilidad de los registratarios y la selección de nombres. La evaluación de las Políticas de registración para la comunidad se alinea con el enfoque de la ICANN para evaluar todos los compromisos complementarios propuestos por los solicitantes mediante un marco uniforme. Se puede consultar más información disponible sobre este marco en la Sección 7.8 Compromisos en pos del interés público, Compromisos voluntarios de los operadores de registro y Políticas de registración para la comunidad.

Para ser consideradas durante la CPE, las Políticas de registración para la comunidad propuestas para su inclusión en el Acuerdo de Registro deben ser evaluadas en la Evaluación de compromisos de los operadores de registro (RCE) (antes de la CPE). Esto garantiza que los compromisos puedan ser acordados mutuamente entre el solicitante y la ICANN para su inclusión en el Acuerdo de Registro correspondiente. Si dichos compromisos no pueden acordarse, no serán considerados durante la CPE.

Cualquier solicitante que designe su solicitud como Solicitud de la comunidad estará obligado, si la solicitud es aprobada, a incluir las Políticas de registración para la comunidad acordadas con la ICANN durante la evaluación de la solicitud en la Especificación 12 del Acuerdo de Registro Base aplicable. Este requisito se aplica incluso si no hay solicitantes en disputa o si un solicitante con una Solicitud de la comunidad opta por no participar en la CPE para resolver la disputa. En resumen, se requiere la aprobación de las Políticas de registración para la comunidad no solo para que una Solicitud de la comunidad participe en la CPE, sino también para avanzar en el proceso de solicitud después de la RCE. Si no hay Políticas de registración para la comunidad que puedan ser aprobadas por la ICANN para su inclusión en el Acuerdo de Registro, la Solicitud de la comunidad no puede avanzar, independientemente de si está en disputa o si el solicitante opta por participar en la CPE.⁵

Consultar la Sección 5.4 Evaluación con prioridad de la comunidad para obtener más información sobre la Evaluación con prioridad de la comunidad y la Sección 7.8 Compromisos en pos del interés público, Compromisos voluntarios de los operadores de registro y Políticas de registración para la comunidad.⁶

También habrá una tarifa para el proceso de Evaluación de compromisos de los operadores de registro (RCE) para la Especificación 12 (consultar la Sección 3.3 Tarifas y Pagos).

7.1.2.2 Solicitudes para nombres geográficos

Un solicitante puede designar su solicitud como un nombre geográfico.⁷ Es responsabilidad del solicitante identificar si la cadena de caracteres de gTLD solicitada se enmarca en alguna de las categorías de nombres geográficos definidas (consultar Sección 7.5 Nombres geográficos), consultar con los gobiernos o autoridades públicas pertinentes y determinar el nivel de apoyo gubernamental necesario.

Además, como parte de la evaluación inicial de cadenas de caracteres, la ICANN revisará todas las solicitudes para determinar si una cadena de caracteres solicitada cumple los requisitos para ser considerada un nombre geográfico, como se describe más adelante en esta sección. Si un solicitante no designa su solicitud como nombre geográfico, pero posteriormente la ICANN la identifica como tal, la solicitud aún estará sujeta a los requisitos adicionales para un nombre geográfico. Los solicitantes pueden prever requisitos diferentes en las siguientes áreas del ciclo de vida de la solicitud:

Preguntas incluidas en la solicitud: El solicitante recibirá preguntas adicionales con respecto al nombre geográfico para el cual está presentando la solicitud. Consultar el Apéndice 1 Preguntas incluidas en la solicitud.
Evaluación: El solicitante de un nombre geográfico debe presentar documentación de respaldo o no objeción de la entidad gubernamental pertinente. Un Panel de Nombres Geográficos (GNP) determinará si la cadena de caracteres solicitada representa un nombre geográfico, y verificará la pertinencia y autenticidad de la documentación justificativa cuando sea necesario. Consultar la Sección 7.5.3.2 Revisión de nombres geográficos.
Tarifas: Habrá una tarifa condicional para la Revisión de nombres geográficos (Sección 7.5.3.2). Consultar la Sección 3.3 Tarifas y pagos.

7.1.2.3 Solicitudes para nombres reservados

Todas las cadenas de caracteres de gTLD solicitadas se comparan con las listas de Nombres Reservados y Bloqueados. Si bien no se pueden solicitar nombres bloqueados, las entidades elegibles pueden solicitar un nombre reservado como se define en la Sección 7.2 Nombres bloqueados y reservados.⁸ Para solicitar dichos nombres, el solicitante debe seguir el proceso definido en la Sección 7.2.2.2.1 Proceso de excepción para solicitar un nombre reservado. Los solicitantes de un nombre reservado pueden prever requisitos diferentes en las siguientes áreas del ciclo de vida de la solicitud:

Preguntas incluidas en la solicitud: Se le exigirá al solicitante que responda preguntas adicionales con respecto al nombre reservado para el cual está presentando la solicitud. Consultar el Apéndice 1 Preguntas incluidas en la solicitud.
Evaluación: Un solicitante de un nombre reservado debe presentar documentación, incluido un certificado de constitución y una carta de la organización matriz, junto con documentación de respaldo o no objeción, que puede incluir una carta firmada, según corresponda. Consultar la Sección 7.2.2 Nombres reservados.

7.1.2.4 Solicitudes para TLD que representan a una marca

Un solicitante tiene la capacidad de designar su solicitud como un TLD que representa a una marca. Este tipo de solicitud permite al solicitante utilizar su empresa o marca como un TLD.⁹ Un TLD que representa a una marca es una cadena de caracteres que es idéntica a los elementos textuales (por ejemplo, un nombre, palabra o frase) de una marca comercial registrada válida en virtud de la ley aplicable,¹⁰ y que el solicitante opera como un TLD que representa a una marca.¹¹ Los solicitantes de un TLD que representa a una marca deben prever requisitos diferentes en las siguientes áreas del ciclo de vida de la solicitud:

Preguntas incluidas en la solicitud: El solicitante recibirá preguntas adicionales con respecto al TLD que representa a una marca para el cual está presentando la solicitud (por ejemplo, su marca comercial o marca registrada). Consultar el Apéndice 1 Preguntas incluidas en la solicitud.
Evaluación: La solicitud para un TLD que representa a una marca será revisará a fin de determinar su elegibilidad para obtener la designación de TLD que representa a una marca.¹² Consultar la Sección 7.3 Evaluación de elegibilidad como TLD que representa a una marca.
Controversia: Si una solicitud está en disputa con otras solicitudes para la misma cadena de caracteres solicitada, el solicitante de un TLD que representa a una marca puede tener la oportunidad de pedir una modificación a su cadena de caracteres solicitada para resolver la disputa. Consultar la Sección 5.2 Controversia por cadenas de caracteres y procedimientos de resolución de controversias.¹³
Contratación: Si es elegible, la Especificación 13 se incluiría en su Acuerdo de Registro Base para su ejecución.¹⁴ Consultar la Sección 1.2.15 Contratación.
Tarifas: Habrá una tarifa condicional para la Evaluación de elegibilidad como TLD que representa a una marca. Consultar la Sección 3.3 Tarifas y pagos.

Si un solicitante de un TLD que representa a una marca cumple los requisitos de un TLD que representa a una marca, se incluirá la Especificación 13 en su Acuerdo de Registro correspondiente y el solicitante también obtendrá una Exención al código de conducta (CoC). Sin embargo, en algunos casos, un solicitante de un TLD que representa a una marca puede obtener una Exención al código de conducta, pero no ser elegible para la Especificación 13.

7.1.2.5 Solicitudes para Nombres de Dominio Internacionalizados

Los solicitantes tendrán la capacidad de solicitar IDN. Las solicitudes para los IDN deben cumplir con los requisitos definidos en la Sección 3.1.9 Nombres de Dominio Internacionalizados, y los solicitantes pueden prever requisitos diferentes en las siguientes áreas del ciclo de vida de la solicitud:

Priorización: Con sujeción a los límites y requisitos identificados en la Sección 3.7 Orden de procesamiento de solicitudes y sorteo de priorización, las solicitudes para IDN podrían recibir prioridad en su tramitación frente a las solicitudes que no sean de IDN.

7.1.2.6 Solicitudes para variantes de gTLD existentes

Los operadores de registro existentes tendrán la oportunidad de solicitar cadenas de caracteres variantes asignables de gTLD existentes.¹⁵ Las solicitudes para los IDN deben cumplir con los requisitos definidos en la Sección 3.1.9 Nombres de Dominio Internacionalizados, y los solicitantes pueden prever requisitos diferentes en las siguientes áreas del ciclo de vida de la solicitud:

Preguntas incluidas en la solicitud: El solicitante recibirá preguntas adicionales con respecto a la cadena de caracteres variante para la cual está presentando la solicitud. Consultar el Apéndice 1 Preguntas incluidas en la solicitud.
Priorización: Con sujeción a los límites y requisitos identificados en la Sección 3.7 Orden de procesamiento de solicitudes y sorteo de priorización, las solicitudes para cadena de caracteres variantes asignables podrían priorizarse frente a las solicitudes que no sean de IDN.
Evaluación: Un solicitante de una variante asignable de un gTLD existente estará sujeto a revisión por parte de un panel y deberá justificar la necesidad de la variante (por ejemplo, deberá explicar cómo las cadenas de caracteres principal y variante se consideran iguales).¹⁶ Los requisitos adicionales pueden incluir el uso del mismo RSP para el registro de variantes que para el registro principal. Consultar el Apéndice 1 Preguntas incluidas en la solicitud y la Sección 7.10 Evaluación de la similitud entre cadenas de caracteres.
Contratación: La Especificación 14 se agregará al Acuerdo de Registro Base para su ejecución. Consultar la Sección 1.2.15 Contratación.
Tarifas: Los operadores de registro existentes que soliciten cadenas de caracteres variantes asignables de gTLD existentes tendrán la tarifa de solicitud base eximida para hasta cuatro cadenas de caracteres de variantes;¹⁷ las solicitudes para más de cuatro cadenas de caracteres variantes incurrirán en tarifas adicionales. Consultar la Sección 3.3 Tarifas y pagos.¹⁸

7.1.2.7 Solicitudes para nuevos IDN que incluyen una o más variantes

Los solicitantes tendrán la oportunidad de solicitar un nuevo IDN TLD, además de sus cadenas de caracteres variantes asignables. Las solicitudes para un nuevo IDN TLD y sus cadenas de caracteres variantes asignables deben cumplir con los requisitos definidos en la Sección 3.1.9 Nombres de Dominio Internacionalizados, y los solicitantes pueden prever requisitos diferentes en las siguientes áreas del ciclo de vida de la solicitud:

Preguntas incluidas en la solicitud: El solicitante recibirá preguntas adicionales con respecto al IDN TLD y sus cadenas de caracteres variantes asignables para las cuales está presentando la solicitud. Consultar el Apéndice 1 Preguntas incluidas en la solicitud.
Priorización: Con sujeción a los límites y requisitos identificados en la Sección 3.7 Orden de procesamiento de solicitudes y sorteo de priorización, las solicitudes para IDN TLD, incluidas las cadenas de caracteres variantes asignables podrían recibir prioridad en su tramitación frente a las solicitudes que no sean de IDN.
Evaluación: Un solicitante de un nuevo IDN TLD y sus cadenas de caracteres variantes asignables estará sujeto a revisión por parte de un panel y se esperará que proporcione justificación en su solicitud para la necesidad de la variante (por ejemplo, explicación de cómo las cadenas de caracteres principal y variante se consideran iguales).¹⁹ Pueden aplicarse requisitos adicionales, como usar el mismo RSP para el registro de variantes que para el registro principal, así como garantizar que los tipos de TLD sean consistentes en la cadena de caracteres principal y las cadenas de caracteres variantes. Consultar la Sección 7.10 Evaluación de la similitud entre cadenas de caracteres.
Contratación: La Especificación 14 se agregará al Acuerdo de Registro Base para su ejecución. Consultar la Sección 1.2.15 Contratación.
Tarifas: Los nuevos solicitantes que presenten una solicitud para una cadena de caracteres principal más sus cadenas de caracteres variantes no incurrirán en tarifas de solicitud adicionales más allá de la tarifa base que incluye hasta cuatro cadenas de caracteres variantes. Sin embargo, las solicitudes de una cadena de caracteres principal más una cantidad de cadenas de caracteres variantes superior a cuatro incurrirán en tarifas adicionales. Consultar la Sección 3.3 Tarifas y pagos.²⁰

7.1.2.8 Solicitudes de organizaciones intergubernamentales o entidades gubernamentales

Se aceptarán solicitudes de organizaciones intergubernamentales (OIG)²¹ o entidades gubernamentales²². Los solicitantes en esta categoría deben considerar los requisitos para nombres geográficos definidos en la Sección 7.5 Nombres geográficos, así como los requisitos para nombres reservados que se especifican en la Sección 7.2 Nombres bloqueados y reservados. Estos solicitantes pueden prever requisitos diferentes en las siguientes áreas del ciclo de vida de la solicitud:

Preguntas incluidas en la solicitud: A estas entidades se les pueden hacer preguntas adicionales con respecto a sus organizaciones particulares. Consultar el Apéndice 1 Preguntas incluidas en la solicitud.
Evaluación: Cualquier entidad de este tipo estará obligada a proporcionar documentación para verificar su designación como organización intergubernamental o gubernamental, según corresponda. Consultar la Sección 7.5.3.2 Revisión de nombres geográficos y la Sección 7.2.2.2 Revisión de nombres reservados.

7.1.2.9 Solicitudes de candidatos elegibles para Apoyo para Solicitantes

Antes de que se abriera la ronda actual, los posibles solicitantes tuvieron la oportunidad de solicitar participar en el Programa de Apoyo para Solicitantes. Los candidatos que presentaron su solicitud para participar fueron evaluados sobre la base de los criterios establecidos en el Manual de Apoyo para Solicitantes. Una solicitud de Apoyo para Solicitantes es distinta de una solicitud para un nuevo gTLD. Los solicitantes que reciban Apoyo para Solicitantes también deben cumplir con los requisitos y criterios de elegibilidad para una solicitud de nuevo gTLD, como se define en esta Guía para el Solicitante.

Los solicitantes elegibles para el Apoyo para Solicitantes pueden prever requisitos diferentes en las siguientes áreas del ciclo de vida de la solicitud:

Controversia: Los solicitantes de Apoyo para Solicitantes que participen en una Subasta de la ICANN recibirán un crédito de oferta. Consultar la Sección 5.6.5 Créditos de oferta para solicitantes del Programa de Apoyo para Solicitantes en las subastas.
Contratación: Si un solicitante obtiene exitosamente Apoyo para Solicitantes y su solicitud prevalece en una subasta, el solicitante tendrá restricción para ceder el Acuerdo de Registro o la realización de cualquier Cambio de control durante un mínimo de tres años. Consultar la Sección 1.2.15 Contratación.
Tarifas: Un solicitante que reúna los requisitos para el Apoyo para Solicitantes será elegible para pagar una tarifa de solicitud reducida, así como tarifas de evaluación condicionales reducidas. Consultar la Sección 3.3 Tarifas y pagos así como el Manual del Programa de Apoyo para Solicitantes para obtener más información.²³

7.1.3 Cambios de tipos de solicitud

En algunos casos, un solicitante puede desear cambiar su tipo de solicitud. Esto puede o no ser permitido en función del tipo de solicitud. Por ejemplo, no se permitirá a un solicitante cambiar la designación de gTLD de la comunidad. Consultar la Sección 3.8 Pedidos de cambios en una solicitud para obtener más información sobre qué cambios a un tipo de solicitud o cadena de caracteres pueden estar permitidos.

7.2 Generalidades sobre nombres bloqueados y reservados

Ciertos nombres están bloqueados y, por lo tanto, no están disponibles para su uso como cadenas de caracteres de gTLD. La lista de Nombres bloqueados se basa en una variedad de fuentes y aportes, como se describe a continuación. Otros nombres están reservados a nivel superior sobre la base de la política de consenso y se mantienen en una lista elaborada por la ICANN.²⁴

Nota: En la Guía para el Solicitante de 2012, la lista llamada “Cadenas de caracteres no elegibles para delegación" ahora se denomina Lista de nombres reservados, y la lista previamente llamada "Lista de nombres reservados de nivel superior" ahora se conoce como Lista de nombres bloqueados.

Como parte de la Sección 3.1.8 Validaciones de cadenas de caracteres previas a la presentación, todas las cadenas de gTLD solicitadas y sus variantes se comparan con las listas de nombres reservados y bloqueados. Esta comparación garantiza que la cadena de caracteres de gTLD solicitada no figura en ninguna de las dos listas. Los solicitantes tendrán la posibilidad de introducir una cadena de caracteres propuesta en TAMS para verificar si aparece en las listas de Nombres bloqueados o reservados.

Además, los Nombres bloqueados o reservados que no se ajustan al marco de caracteres permitidos del DNS se convertirán en etiquetas del DNS que contienen únicamente letras, dígitos y guiones de acuerdo con la política de consenso.²⁵

7.2.1 Nombres bloqueados

Las cadenas de caracteres de gTLD y sus variantes asignables en la lista de Nombres bloqueados no son elegibles para solicitud en la ronda actual o en cualquier ronda de solicitudes futura, según la política de consenso. Sin embargo, la lista no se aplica a gTLD que ya han sido delegados en la zona raíz.

Las siguientes cadenas de caracteres de gTLD y sus cadenas de caracteres variantes asignables se encuentran en la lista de Nombres bloqueados (ver notas al pie para consultar las listas correspondientes) y no se pueden solicitar:

Nombres de dominio de uso especial: Estas son cadenas de caracteres específicas reservadas por normas técnicas para fines incompatibles con la delegación, que se señalan explícitamente en el Registro de Nombres de Dominio de Uso Especial de la IANA.²⁶^,²⁷^,²⁸
Normas técnicas: Consultar la Sección 3.8.3 Revisión de estabilidad del DNS para obtener más información.
Nombres de países o territorios en relación con nombres geográficos: Consultar la Sección 7.5 Nombres geográficos.

Organismos relacionados con la ICANN, la IANA y el IETF e infraestructura de Internet: Entre ellas figuran, por ejemplo: Organizaciones de apoyo (SO) y comités asesores (AC) de la ICANN,²⁹ Registros Regionales de Internet,³⁰ organismos del IETF³¹ e identificadores del sistema incluidos a través de la política de consenso.³² ³³

Tabla 7-1: Organismos relacionados con la ICANN, la IANA y el IETF e infraestructura de Internet

Organismos relacionados con la ICANN, la IANA y el IETF e infraestructura de Internet
AFRINIC	GNSO	INTERNIC	NRO	TLD
ALAC	GTLDSERVERS	INTERNAL	PTI	WHOIS
APNIC	IAB	IETF	RFCEDITOR	WWW
ARIN	IANA	IRTF	RIPE
ASO	IANASERVERS	ISTF	ROOTSERVERS
CCNSO	ICANN	LACNIC	RSSAC
GAC	IESG	NIC	SSAC
Nota: Las cadenas de caracteres en la lista están bloqueadas solo en la forma incluida anteriormente.

Otras cadenas de caracteres no permitidas:
- TLD delegados.³⁴
- Cadenas de caracteres de gTLD que se solicitaron en rondas de gTLD anteriores y que siguen en proceso.³⁵
- ccTLD existentes que superaron con éxito la evaluación.
- Cadenas de caracteres solicitadas actualmente como IDN ccTLD.
- Todas las demás cadenas de caracteres ASCII de una o dos letras.

7.2.1.1 Identificación de nombres bloqueados

Cuando un solicitante completa el nombre de la cadena de caracteres solicitada, el sistema comprueba automáticamente si la cadena de caracteres elegida por el solicitante, incluidas las variantes, aparece en la lista de Nombres bloqueados. Si la cadena de caracteres se encuentra en esta lista, el sistema impedirá que el solicitante continúe con esa cadena. Para continuar con la solicitud, el solicitante debe revisar la entrada y seleccionar una cadena de caracteres diferente que no esté bloqueada.

7.2.1.1.1 Impugnación en materia de identificación de nombres bloqueados

En los casos en que un solicitante considere que se le está impidiendo presentar su solicitud o que deba proporcionar documentación adicional debido a que un error del sistema en el proceso automatizado de identificación de nombres bloqueados ha dado lugar a que la cadena de caracteres del solicitante se haya clasificado incorrectamente como Nombre bloqueado y, en consecuencia, el solicitante no haya podido proceder a la presentación, dicho solicitante tendrá la oportunidad de presentar una impugnación a más tardar 14 días antes de que finalice el período para la presentación de solicitudes³⁶ (consultar las secciones 1.2.14.2 Impugnación de la evaluación y 3.1.8.4 Impugnación de las validaciones de cadenas de caracteres previas a la presentación).

7.2.2 Nombres reservados

El proceso de evaluación de Nombres reservados se divide en dos partes: Identificación de nombres reservados, una verificación automatizada que identifica si una cadena de caracteres solicitada aparece en la lista de Nombres reservados, y Revisión de nombres reservados, que incluye tanto el proceso de excepción para que un candidato solicite un nombre de OIG-OING internacionales limitadas y la verificación de la documentación requerida.³⁷

Las siguientes cadenas de caracteres de OIG-OING internacionales limitadas se encuentran en la lista de Nombres reservados y pueden ser solicitadas a través de un proceso de excepción únicamente por la entidad relevante, siempre que presente la documentación apropiada como se detalla en la sección 7.2.2.2 Identificación de nombres reservados a continuación:

Los nombres agregados por las recomendaciones del Grupo de Trabajo para el PDP de OIG-OING ³⁸ sobre las protecciones de los identificadores de las OIG-OING en todos los gTLD,³⁹^,⁴⁰ incluidas sus cadenas de caracteres variantes asignables, son elegibles para delegación previa verificación. Estas iniciativas incluyen: Cruz Roja/Media Luna Roja (RCRC),⁴¹ Comité Olímpico Internacional (IOC) ⁴² y nombres de organizaciones internacionales gubernamentales (OIG) ⁴³ – organizaciones internacionales no gubernamentales (OING).^,⁴⁴

7.2.2.2 Identificación de nombres reservados

Cuando un solicitante introduce la cadena de caracteres solicitada, el sistema verificará automáticamente si esa cadena, incluida cualquier cadena de caracteres variante asignable, aparece en la Lista de nombres reservados. En ese caso, se iniciará el proceso de excepción, en el que se pedirá al solicitante que cargue documentación de respaldo que demuestre que es la entidad para la que se reserva el nombre.

Además de esta verificación, el sistema también verificará si la cadena de caracteres es una variante de un Nombre reservado. En dichos casos, el solicitante solo podrá continuar si el nombre reservado en sí está siendo solicitado como la cadena de caracteres principal, o si el solicitante proporciona confirmación de que es el operador de registro para el TLD que coincide con el nombre reservado.

7.2.2.2.1 Impugnación en materia de identificación de nombres reservados

Si un solicitante cree que un error del sistema en el proceso automatizado de identificación de nombres reservados dio lugar a que la cadena de caracteres de un solicitante se clasificara incorrectamente como nombre reservado, puede iniciar una Impugnación de la evaluación. La impugnación debe presentarse a más tardar siete días antes del cierre del período para la presentación de solicitudes.

La ICANN revisará la Impugnación de la evaluación. Si la ICANN determina que un error del sistema provocó la clasificación incorrecta de la cadena de caracteres como un nombre reservado, el error del sistema será corregido, y se permitirá que la solicitud proceda a la siguiente etapa apropiada en el proceso. Si no se encuentra ningún error, la solicitud continuará, pero debe cumplir con los criterios de Nombre reservado durante la fase de Revisión de nombres reservados. No hay tarifas condicionales asociadas a un procedimiento de Impugnación de la evaluación relacionado con nombres reservados. Los solicitantes son responsables de garantizar el cumplimiento de todos los requisitos de Nombres reservados, incluso en casos de error del sistema.

7.2.2.3 Revisión de nombres reservados

7.2.2.3.1 Proceso de excepción para solicitar nombres reservados

Los solicitantes pueden presentar una solicitud para una cadena de caracteres en la lista de Nombres reservados a través del proceso de excepción. Durante la Revisión de nombres reservados, el panel evalúa la excepción y verifica la documentación de respaldo del solicitante para confirmar que es la entidad elegible para operar el nombre reservado. Consultar la Sección 7.2.2 Nombres reservados para las cadenas de caracteres específicas incluidas en la lista de Nombres reservados.

Para solicitar un nombre reservado a través del proceso de excepción, los solicitantes deben presentar los siguientes tipos de documentación al momento de la solicitud:

Acta constitutiva y, si corresponde, carta de la organización matriz.
Documentación de respaldo o no objeción, incluida una carta firmada por la autoridad pública competente (si corresponde).

7.2.2.3.1.1 Verificación de la documentación presentada

Si un solicitante de una de las OIG-OING internacionales limitadas enumeradas anteriormente utiliza el proceso de excepción para solicitar un nombre de la lista de Nombres reservados, incluidas sus cadenas de caracteres variantes asignables, se iniciará un proceso de verificación. Este proceso confirmará que el solicitante ha presentado documentación satisfactoria que establece su elegibilidad para solicitar ese TLD en particular. El proceso de verificación para la organización/entidad solicitante ocurrirá como parte de la fase de evaluación de la solicitud.

La ICANN puede consultar a las autoridades pertinentes para una verificación adicional.

Si procede, para obtener más asistencia a la hora de determinar cuál es la autoridad gubernamental o pública competente para una solicitud, el solicitante puede consultar con el representante pertinente del GAC.⁴⁵

7.2.2.3.2 Evaluación extendida para la revisión de nombres reservados

Los solicitantes que no presenten documentación adecuada que demuestre su elegibilidad para solicitar un TLD incluido en la lista de nombres reservados no superarán la Revisión de nombres reservados.

Sin embargo, si se determina que una solicitud no cumple con los criterios identificados para la Revisión de nombres reservados, el solicitante puede solicitar una Evaluación extendida. Durante la Evaluación extendida, se pueden emitir Preguntas aclaratorias para obtener información adicional. Para garantizar el procesamiento oportuno, se recomendará a los solicitantes que respondan a la mayor brevedad posible, pero como máximo 21 días después de recibir las preguntas aclaratorias. Si la información adicional proporcionada no cumple los criterios de Nombres reservados, la solicitud no superará con éxito la revisión y no continuará.

7.3 Evaluación de elegibilidad como TLD que representa a una marca

El solicitante tendrá la posibilidad de designar por sí mismo una solicitud como un TLD que representa a una marca. Este tipo de solicitud permite a una empresa o corporación utilizar su nombre empresarial o marca como un TLD. Consultar la Sección 3.1.6 Tipos de solicitudes y cadenas de caracteres.

7.3.1 Requisitos para la Evaluación de elegibilidad como TLD que representa a una marca

El solicitante que desee designar su cadena de caracteres solicitada como un TLD que representa a una marca debe someterse a la Evaluación de elegibilidad como TLD que representa a una marca. El propósito de esta evaluación es confirmar que el solicitante cumple los criterios para la designación como un TLD que representa a una marca. Las solicitudes que superen la Evaluación de elegibilidad como TLD que representa a una marca incluirán la Especificación al Acuerdo de Registro Base correspondiente si la solicitud procede a la delegación. Consultar el Apéndice 4 Acuerdo de Registro Base para ver los términos de la Especificación 13.⁴⁶

El solicitante puede pedir la Evaluación de elegibilidad como TLD que representa a una marca en su solicitud o mediante un Pedido de cambios en una solicitud. Consultar la Sección 3.8 Pedidos de cambios en una solicitud.

7.3.2 Tarifa condicional para la Evaluación de elegibilidad como TLD que representa a una marca

Un solicitante que solicita la Evaluación de elegibilidad como TLD que representa a una marca debe pagar una tarifa de evaluación adicional como se especifica en la Sección 3.3 Tarifas y pagos. La Evaluación de elegibilidad como TLD que representa a una marca no se realizará hasta que la ICANN reciba el pago de la tarifa pertinente.

7.3.3 Evaluación y resultados de la Evaluación de elegibilidad como TLD que representa a una marca

Para poder obtener una designación de TLD que representa a una marca, un solicitante debe proporcionar uno o más archivos de datos de marca firmados (SMD) del Centro de Información y Protección de Marcas Comerciales (TMCH). Consultar las pautas del TMCH para los requisitos de elegibilidad.⁴⁷

7.3.3.1 Interacción con el Centro de Información y Protección de Marcas Comerciales antes de presentar una solicitud de TLD que representa a una marca

Un solicitante que tiene planificado designar su cadena de caracteres solicitada como TLD que representa a una marca debe adoptar medidas preparatorias con suficiente anticipación antes de iniciar la solicitud para garantizar que pueda demostrar la elegibilidad al momento de la presentación.

Las solicitudes de TLD que representan a una marca deben incluir uno o más archivos de datos de marca firmados (SMD) del Centro de Información y Protección de Marcas Comerciales (TMCH) en apoyo de la designación de marca. Debido a que agregar o ajustar las presentaciones del TMCH puede requerir varios meses y puede implicar el pago de tarifas directamente al TMCH, los solicitantes de TLD que representan a una marca deben revisar cuidadosamente sus archivos SMD del TMCH existentes o adquirir nuevos archivos SMD tan pronto como sea posible. Los solicitantes de TLD que representan a una marca deben adoptar los siguientes pasos en relación con el TMCH (según corresponda) antes de solicitar un TLD que representa a una marca:

Un solicitante de TLD que representa a una marca sin una relación con el TMCH o sin archivos SMD que cubran las cadenas de caracteres para las cuales desea solicitar debe iniciar la verificación del TMCH.⁴⁸
Garantizar que cualquier etiqueta de TLD deseada esté incluida en la lista en los elementos <mark:label> en archivos SMD. Toda cadena de caracteres que un solicitante de TLD que representa a una marca desee solicitar debe coincidir exactamente con un elemento <mark:label> en un SMD válido con fecha anterior a la presentación de la solicitud.
Garantizar que cualquier etiqueta variante deseada de la cadena de caracteres principal que representa a una marca esté incluida en la lista en los elementos <mark:label> en archivos SMD. Todas las cadenas de caracteres variantes solicitadas de un TLD que representa a una marca deben coincidir exactamente con un elemento <mark:label> en un SMD válido con fecha anterior a la presentación de la solicitud.
Garantizar que los elementos <mark:goodsAndServices> estén correctos, completos e incluyan una palabra que el solicitante pueda querer usar en un Cambio de cadena de caracteres que representa a una marca conforme a la Solicitud de cambio de cadena de caracteres que representa a una marca (consultar la Sección 5.3). Las palabras adicionales usadas para ampliar la cadena de caracteres que representa a una marca solicitada deben aparecer en un elemento <mark:goodsAndServices> de un archivo SMD válido con fecha anterior a la presentación de una Solicitud de cambio de cadena de caracteres que representa a una marca.

Si las palabras usadas para ampliar la cadena de caracteres solicitada no aparecen en un archivo SMD, aún puede ser posible presentar una Solicitud de cambio de cadena de caracteres que representa a una marca usando documentación alternativa. Consultar la Sección 5.3.2 Requisitos para solicitudes de cambio de una cadena de caracteres que representa a una marca.

7.3.3.2 Criterios para la Evaluación de elegibilidad como TLD que presenta a una marca

Un Panel de evaluación para determinar la elegibilidad como TLD que representa a una marca llevará a cabo la Evaluación de elegibilidad como TLD que representa a una marca. Un solicitante que procura la designación de TLD que representa a una marca debe demostrar que la solicitud cumple con los siguientes criterios:

1a. La cadena de caracteres de gTLD solicitada debe coincidir exactamente con los elementos textuales de una marca comercial registrada verificada por el TMCH en los archivos SMD proporcionados; o bien,

1b. Si el solicitante cambió su cadena de caracteres solicitada mediante una Solicitud de cambio de cadena de caracteres que representa a una marca (Sección 5.3), la cadena de caracteres final debe cumplir con todos los requisitos establecidos en la misma.

2. El solicitante y la cadena de caracteres final (incluidas todas las cadenas de caracteres variantes asignables) deben cumplir con todos los requisitos establecidos en la Especificación 13 del Acuerdo de Registro Base. Consultar el Apéndice 4 Acuerdo de Registro Base.

El solicitante deberá autocertificar en su solicitud el cumplimiento de los criterios establecidos anteriormente y en la Especificación 13 del Acuerdo de Registro Base (consultar el Apéndice 4 Acuerdo de Registro Base). Además, el solicitante debe confirmar el uso no genérico en su solicitud. Consultar el Conjunto de preguntas 13 TLD que representa a una marca y exenciones al código de conducta en el Apéndice 1 Preguntas incluidas en la solicitud.

7.3.3.3 Preguntas aclaratorias sobre la Evaluación de elegibilidad como TLD que representa a una marca

La ICANN podrá efectuar Preguntas aclaratorias durante la Evaluación de elegibilidad como TLD que representa a una marca. Los solicitantes tendrán siete días para responder a preguntas aclaratorias de carácter administrativo y 21 días para responder a preguntas aclaratorias sustantivas. Si el solicitante no responde dentro del plazo establecido, podrá perder la oportunidad de abordar cualquier cuestión detectada por el panel de evaluación.

7.3.3.4 Resultados de la Evaluación de elegibilidad como TLD que representa a una marca

Los resultados de la Evaluación de elegibilidad como TLD que representa a una marca se incluirán en los Informes de evaluación de solicitudes y solicitantes, como se describe en la Sección 1.2.13 Publicación de informes de evaluación de solicitudes y solicitantes.

Si una solicitud supera con éxito la Evaluación de elegibilidad como TLD que representa a una marca, la Especificación 13 se agregará al Acuerdo de Registro Base correspondiente si la solicitud procede a la delegación.

Si no se supera con éxito una Evaluación de elegibilidad como TLD que representa a una marca, el solicitante puede optar por continuar con su solicitud sin la designación de TLD que representa a una marca, es decir, sin la adición de la Especificación 13.

Si la solicitud de TLD que representa a una marca se realiza fuera del período para la presentación de solicitudes mediante un Pedido de cambios en una solicitud, o un solicitante desea retirar su solicitud de designación de TLD que representa a una marca, se iniciará un período de comentarios durante 30 días.

7.3.4 Impugnaciones y Evaluación extendida para la Evaluación de elegibilidad como TLD que representa a una marca

Los solicitantes tendrán la posibilidad de volver a presentar la documentación requerida si la presentación inicial de dicha documentación no cumple con los requisitos. Por este motivo, la evaluación extendida o el mecanismo de impugnación no son pertinentes para esta evaluación.

7.3.5 Controversia por cadenas de caracteres y cambio de cadenas de caracteres

Un solicitante que complete exitosamente la Evaluación de elegibilidad como TLD que representa a una marca puede tener permitido cambiar su cadena de caracteres principal para evitar la controversia por cadena de caracteres. Consultar la Sección 5.3 Solicitud de cambio de una cadena de caracteres que representa a una marca para obtener más información sobre los procedimientos para una Solicitud de cambio de cadena de caracteres de TLD que representa a una marca.

7.4 Evaluación de exención al código de conducta para operadores de registro

La Especificación 9 del Acuerdo de Registro Base contiene el Código de conducta del operador de registro. El objetivo del código de conducta es proteger a los registratarios de un gTLD. En algunos casos, se puede solicitar una exención al código de conducta.

7.4.1 Elegibilidad para la Evaluación de exención al código de conducta

Si un operador de registro registra todos los nombres de dominio en el gTLD exclusivamente para su uso propio o el de sus afiliadas, (como se define en el Apéndice 4 Acuerdo de Registro Base) y el operador de registro desea renunciar a la protección para sí mismo y sus afiliadas, la ICANN puede otorgar al operador de registro una exención al código de conducta, siempre que el gTLD no sea una cadena de caracteres genérica (consultar la Sección 3.1.7 Genéricos cerrados) y el operador de registro pueda cumplir todos los criterios de exención. Consultar el Apéndice 4 Acuerdo de Registro Base para ver el texto de la Especificación 9.

Se permite a un solicitante presentar la solicitud para una exención al código de conducta en su solicitud o, tras la presentación de la solicitud, mediante la utilización de un Pedido de cambios en una solicitud. La solicitud de exención al código de conducta está abierta al público para su revisión y aportes mediante el período de comentarios sobre solicitudes (consultar la Sección 4.1.3 Comentarios sobre solicitudes en el proceso de evaluación).

7.4.2 Evaluación de exención al código de conducta para cadenas de caracteres variantes

Si un solicitante solicita cadenas de caracteres variantes asignables de una cadena de caracteres de gTLD principal solicitada y procura la Exención al código de conducta, la Evaluación de la exención al código de conducta cubrirá las cadenas de caracteres principales y variantes solicitadas.

7.4.3 Tarifas condicionales para la Evaluación de exención al código de conducta

Los solicitantes que presenten una solicitud de Evaluación de exención al código de conducta deben pagar una tarifa adicional, como se especifica en la Sección 3.3 Tarifas y pagos. La Evaluación de exención al código de conducta no se realizará hasta que la ICANN reciba el pago de las tarifas pertinentes.

7.4.4 Criterios para la evaluación de exención al código de conducta

El Panel de Evaluación de exención al código de conducta llevará a cabo la Evaluación de Exención al código de conducta. La decisión sobre si la ICANN concederá una exención al código de conducta consistirá en una revisión de las afirmaciones contenidas en la solicitud de exención para verificar que, si el solicitante se convierte en un operador de registro, cumplirá los tres criterios de exención:

El operador de registro será responsable de registrar y mantener todas las registraciones de nombres de dominio en el gTLD y cadenas de caracteres variantes, según corresponda, para el uso exclusivo del operador de registro o sus afiliadas (como se define en el Acuerdo de Registro Base);
El operador de registro no venderá, distribuirá ni transferirá el control o el uso de ninguna registración en el TLD y cadena de caracteres variantes, según corresponda, a ningún tercero que no sea una afiliada del operador de registro; y
La aplicación del Código de conducta al gTLD y cadena(s) de variante(s), según corresponda, no es necesaria para proteger el interés público.

Los solicitantes que presenten una solicitud de exención al código de conducta deberán autocertificar en su solicitud que cumplen los criterios establecidos anteriormente. Además, las declaraciones de misión y propósito deben demostrar un uso no genérico. Es decir, para garantizar que la aprobación de una exención al código de conducta no entrará en conflicto con la Especificación 11 del Acuerdo de Registro Base, que prohíbe que los gTLD genéricos y cadenas de caracteres de variantes sean operados sobre una base exclusiva, la cadena de caracteres no debe ser un genérico cerrado como se define en la Sección 3.1.7 Genéricos cerrados.

7.4.5 Preguntas aclaratorias sobre la Evaluación de exención al código de conducta

La ICANN podrá efectuar Preguntas aclaratorias como parte de la Evaluación de exención al código de conducta. Un solicitante tendrá siete días para responder a preguntas aclaratorias de carácter administrativo y 21 días para responder a preguntas aclaratorias sustantivas. Si el solicitante no responde dentro del plazo establecido, podrá perder la oportunidad de abordar cualquier cuestión detectada por el panel de evaluación.

7.4.6 Resultados de la Evaluación de exención al código de conducta

Los resultados de la Evaluación de exención al código de conducta se incluirán en los Informes de evaluación de solicitudes y solicitantes, como se describe en la Sección 1.2.13 Publicación de informes de evaluación de solicitudes y solicitantes.

Si una solicitud supera con éxito la Evaluación de elegibilidad del código de conducta, se otorgará una exención al código de conducta.

Si una solicitud no supera con éxito la evaluación de exención del código de conducta, la solicitud podrá continuar con la Especificación 9 vigente.

7.4.6 Impugnaciones y Evaluación extendida para la Evaluación de exención al código de conducta

7.5 Nombres geográficos

Los solicitantes deben considerar cuidadosamente los intereses de los gobiernos o autoridades públicas concernientes a los nombres geográficos. Las siguientes secciones describen los requisitos y procedimientos que la ICANN seguirá durante el proceso de evaluación. Un solicitante debe revisar estos requisitos, incluso aunque no considere que su cadena de caracteres de gTLD solicitada constituye un nombre geográfico. Todas las cadenas de caracteres de gTLD solicitadas y sus variantes asignables se revisarán de conformidad con los requisitos incluidos en esta sección, independientemente de si la solicitud indica que es para un nombre geográfico.

El procesamiento de nombres geográficos comprende:

Identificación de nombres geográficos: una verificación a nivel de cadena de caracteres que es parte de la Evaluación de la cadena de caracteres.
Revisión de nombres geográficos: verificación y revisión sustancial de las respuestas a las solicitudes de las cadenas de caracteres determinadas como geográficas. Esta revisión se lleva a cabo durante la fase de evaluación de la solicitud.

Además, un solicitante de una cadena de caracteres de Nombre geográfico puede solicitar sus cadenas de caracteres variantes asignables. En dichos casos, todas las cadenas de caracteres variantes asignables deben cumplir los mismos requisitos de solicitud y criterios de evaluación que la cadena de caracteres de nombre geográfico principal asociada. En concreto, se aplican los mismos requisitos de documentación. Consultar la Sección 3.1.9 Nombres de dominio internacionalizados.

7.5.1 Tratamiento de nombres de países o territorios

No se aprobarán las solicitudes de cadenas de caracteres que sean nombres de países o territorios.⁴⁹ Una cadena de caracteres se considera un nombre de país o territorio si cumple alguno de los siguientes criterios:

Es un código alfa-3 contenido en la lista de la norma ISO 3166-1.⁵⁰
Es un nombre de forma larga contenido en la norma ISO 3166-1, o una traducción del nombre de forma larga en cualquier idioma.
Es un nombre abreviado contenido en la norma ISO 3166-1, o una traducción del nombre abreviado en cualquier idioma.
Es un nombre largo o abreviado asociado a un código que ha sido designado como “excepcionalmente reservado” por la Agencia de Mantenimiento ISO 3166.
Es un componente separable de un nombre de país o territorio designado en la "Lista de Nombres de Países y Territorios Separables", o es una traducción de un nombre contenido en la lista, en cualquier idioma. Consultar el Apéndice 2 Materiales relacionados con nombres geográficos.
Las permutaciones y transposiciones de las siguientes cadenas de caracteres están reservadas y no están disponibles para delegación:

Nombres de formato largo enumerados en la norma ISO 3166-1
Nombres de formato corto enumerados en la norma ISO 3166-1
Nombres de formato abreviado o largo asociados con un código que ha sido designado como “excepcionalmente reservado” por la Agencia de Mantenimiento de ISO 3166.
Componente separable de un nombre de país designado en la “Lista de Nombres de Países Separables, o es una traducción de un nombre contenido en la lista, en cualquier idioma”.

Las cadenas de caracteres resultantes de permutaciones y transposiciones de códigos alfa-3 contenidos en la lista de la norma ISO 3166-1 pueden delegarse, a menos que las propias cadenas de caracteres resultantes de permutaciones y transposiciones figuren en dicha lista.⁵¹

Es un nombre por el cual un país es comúnmente conocido, conforme lo demuestre la evidencia de que ese país es reconocido con ese nombre por parte de una organización intergubernamental o por un tratado.

7.5.2 Nombres geográficos que requieren documentación de gobiernos o autoridades públicas

Ciertos tipos de cadenas de caracteres solicitadas, incluidas sus variantes asignables, se consideran nombres geográficos y deben ir acompañados de documentación de respaldo o no objeción de los gobiernos o autoridades públicas pertinentes. Estos tipos son los siguientes:

Cadenas de caracteres que representen, en cualquier idioma, el nombre de la ciudad capital de cualquier país o territorio enumerado en la norma ISO 3166-1.
Nombres de ciudades en los que el solicitante declara que pretende utilizar el gTLD para fines asociados al nombre de la ciudad.

Los nombres de ciudades pueden presentar desafíos porque también pueden ser términos genéricos o nombres de marcas y, a menudo, no son únicos. A diferencia de otros tipos de nombres geográficos, los nombres de ciudades no tienen listas establecidas para referencias objetivas durante la evaluación. Por ende, los nombres de las ciudades no están protegidos universalmente. Sin embargo, el proceso proporciona un medio para que las ciudades y los solicitantes trabajen juntos cuando lo deseen.

Una solicitud para el nombre de una ciudad estará sujeta a los requisitos de nombres geográficos (es decir, requerirá documentación de respaldo o no objeción de los gobiernos o autoridades públicas pertinentes) si:

Resulta evidente de las declaraciones del solicitante en la solicitud que el solicitante utilizará el TLD principalmente para fines relacionados con el nombre de la ciudad; y
La cadena de caracteres solicitada es el nombre de una ciudad tal como figura en los documentos oficiales de la ciudad.⁵²

Cadenas de caracteres que coincidan exactamente con nombres de lugares secundarios dentro de la nación, tal como un condado, provincia o estado, enumerados en la norma ISO 3166-2.
Cadenas de caracteres que figuren como regiones⁵³ de la UNESCO o que aparezcan en la sección Regiones geográficas de los "Códigos estándar de país o área para uso estadístico (M49)".⁵⁴

Las traducciones de las regiones incluidas en la lista mencionada anteriormente se limitarán a los idiomas especificados en dicha lista. Los nombres de regiones que no se ajusten al marco de caracteres del DNS permitidos se convertirán en etiquetas del DNS que solo contengan letras, dígitos y guiones, tal como se indica en las Reglas para la Generación de Etiquetas para la Zona Raíz (RZ-LGR).⁵⁵

En el caso de las cadenas de caracteres que figuran en estas listas, se requerirá documentación de respaldo o no objeción de al menos el 60 % de los respectivos gobiernos nacionales de la región, y no más de una objeción por escrito a la solicitud por parte de gobiernos relevantes de la región o autoridades públicas asociadas con el continente o la región.

Cuando se aplica la regla del 60 % y las regiones son comunes a ambas listas, prevalece la composición regional contenida en los "Códigos estándar de país o área para uso estadístico (M49)".

Se considera que una cadena de caracteres de gTLD solicitada que se corresponda con cualquiera de los tipos 1 a 4 enumerados anteriormente representa un nombre geográfico. En casos de incertidumbre, es aconsejable que el solicitante consulte con gobiernos y autoridades públicas relevantes para obtener su respaldo o no objeción antes de la presentación de la solicitud. Este enfoque proactivo puede ayudar a prevenir posibles objeciones y aclarar cualquier ambigüedad concerniente a la cadena de caracteres y los requisitos aplicables.

Las cadenas de caracteres que incluyen pero no coinciden exactamente con un nombre geográfico como se define en esta sección no serán consideradas Nombres geográficos. Por lo tanto, no requerirán documentación de respaldo o no objeción del gobierno durante el proceso de evaluación.

Para cada solicitud, el Panel de Nombres Geográficos determinará qué gobiernos o autoridades públicas son relevantes sobre la base de los aportes del solicitante, los gobiernos y su propia investigación y análisis. Si hay más de un gobierno o autoridad pública pertinente para la cadena de caracteres de gTLD solicitada, el solicitante deberá aportar documentación de respaldo o no objeción de todos los gobiernos o autoridades públicas pertinentes. Se prevé que esto pueda aplicarse al caso de un topónimo dentro de una nación.

Es responsabilidad del solicitante:

Identificar si su cadena de caracteres de gTLD solicitada pertenece a cualquiera de las categorías anteriores.
Identificar y consultar a los gobiernos o autoridades públicas pertinentes.
Identificar qué nivel de apoyo gubernamental se requiere.

Nota: El nivel de gobierno y organismo administrativo necesarios para la presentación de cartas de apoyo o no objeción es una cuestión que debe determinar cada administración nacional. Los solicitantes deben consultar en la jurisdicción pertinente para determinar el nivel adecuado de apoyo.

El requisito de incluir documentación de respaldo o no objeción para ciertas solicitudes no excluye ni exime a las solicitudes de ser objeto de objeciones por fundamentos de la comunidad (consultar la Sección 4.5.1.4 Fundamento de la objeción: Comunidad). Las solicitudes aún pueden ser rechazadas si las objeciones que afirman oposición sustancial de la comunidad objetivo tienen éxito.

7.5.2.1 Documentación requerida

La documentación de respaldo o no objeción debe incluir una carta firmada del gobierno o autoridades públicas pertinentes. Dado que esto variará según la jurisdicción, la carta podrá contar con la firma del ministro responsable de la administración de nombres de dominio, TIC, asuntos exteriores o la Oficina del Primer Ministro o Presidente de la jurisdicción pertinente o, en su defecto, un representante de alto rango de la agencia o departamento responsable de la administración de nombres de dominio, TIC, asuntos exteriores, o la Oficina del Primer Ministro. Para determinar qué gobierno o autoridad pública es competente en relación con un posible nombre geográfico, el solicitante puede consultar al representante del Comité Asesor Gubernamental (GAC) correspondiente.⁵⁶

La carta debe expresar claramente el respaldo o la no objeción del gobierno o la autoridad pública a la solicitud y demostrar que el gobierno o la autoridad pública comprenden la cadena de caracteres solicitada y el uso previsto.

La carta también debe demostrar que el gobierno o la autoridad pública comprenden que la cadena se solicita a través del proceso de solicitud de gTLD y que el solicitante está dispuesto a aceptar las condiciones en las que la cadena de caracteres estará disponible, es decir, la celebración de un Acuerdo de Registro con la ICANN que exija el cumplimiento de las políticas de consenso y el pago de tarifas. En la Sección 1.2.16 Después de la contratación y la Sección 2.10 Obligaciones fundamentales de los operadores de registro frente a los registradores se puede consultar más información sobre las obligaciones de un operador de registro de gTLD.

En el Apéndice 2 Materiales relacionados con nombres geográficos, se puede consultar un ejemplo de carta de apoyo o no objeción de una entidad gubernamental o autoridad pública.

Los solicitantes y los gobiernos pueden mantener debates sobre el apoyo o la no objeción de los gobiernos a una solicitud en cualquier momento. Se recomienda a los solicitantes que inicien estas conversaciones lo antes posible, a fin de que los gobiernos puedan seguir los procesos necesarios para considerar, aprobar y generar una carta de apoyo o de no objeción. Si la carta de apoyo o no objeción tiene una antigüedad superior a cuatro meses desde la apertura del período de presentación de solicitudes del Programa de Nuevos gTLD, se requerirá una nueva carta de apoyo o no objeción. No obstante, los solicitantes deberán facilitar los datos de contacto de una persona designada en caso de que el Panel de Nombres Geográficos (GNP) necesite aclaraciones o tenga preguntas.

Un gobierno o autoridad pública no tiene obligación de proporcionar documentación de respaldo o de no objeción en respuesta a la petición de un solicitante. Si se retira el respaldo o no objeción durante el proceso de solicitud, la solicitud no superará la Revisión de nombres geográficos.

Los solicitantes deben saber que la ICANN se ha comprometido con los gobiernos⁵⁷ a que, en caso de litigio entre un gobierno (o autoridad pública) y un solicitante o, tras la delegación, un operador de registro que haya presentado documentación de apoyo de dicho gobierno o autoridad pública, la ICANN cumplirá la orden jurídicamente vinculante del tribunal de la jurisdicción del gobierno o autoridad pública que haya dado apoyo a una solicitud. Si el respaldo se retira mediante una orden judicial legalmente vinculante, el solicitante u operador de registro ya no tendrá la documentación necesaria, y el solicitante no continuará en los siguientes pasos respectivos en el proceso de solicitud, o bien, si esto ocurre después de la delegación, se seguirán los Procesos de transición del registro⁵⁸ referidos en el Acuerdo de Registro.

7.5.3 Procesamiento de nombres geográficos

7.5.3.1 Identificación de nombres geográficos

Como parte de la identificación de nombres geográficos, el Panel de Nombres Geográficos revisará todas las cadenas de caracteres solicitadas para identificar cuáles pueden considerarse nombres geográficos. Este proceso ocurre antes y es distinto del proceso de verificación más sustantivo realizado durante la Revisión de nombres geográficos, que se lleva a cabo como parte de la Evaluación de la solicitud (consultar el Módulo 7) y la Evaluación del solicitante (consultar el Módulo 6).

Los nombres de ciudades que no se enmarcan dentro de las categorías definidas en las secciones 1, 3 y 4 de Nombres geográficos que requieren documentación de gobiernos o autoridades públicas (consultar la Sección 7.5.2) no se clasificarán como Nombres geográficos durante la Identificación de nombres geográficos. Sin embargo, si el solicitante indica una intención de usar la cadena de caracteres solicitada como un nombre de ciudad, como se describe en la sección 2 de Nombres geográficos que requieren documentación de gobiernos o autoridades públicas (consultar la Sección 7.5.2), la solicitud será evaluada por el Panel de Nombres Geográficos durante la fase de Evaluación de solicitudes y solicitantes. Esta evaluación incluirá una evaluación del propósito previsto y cualquier documentación requerida.

7.5.3.2 Revisión de nombres geográficos

Un Panel de Nombres Geográficos (GNP) determinará si cada cadena de caracteres de gTLD solicitada representa un nombre geográfico, y verificará la pertinencia y autenticidad de la documentación justificativa cuando sea necesario.

El GNP revisará todas las solicitudes recibidas, no solo aquellas en las que el solicitante haya anotado su cadena de caracteres de gTLD solicitada como nombre geográfico. Para toda solicitud en la que el GNP determine que la cadena de caracteres de gTLD solicitada es un nombre de país o territorio (tal como se define en este módulo), la solicitud no superará con éxito la Revisión de nombres geográficos y será denegada. No habrá revisiones adicionales.

Para toda solicitud en la que el GNP determine que la cadena de caracteres de gTLD solicitada no es un nombre geográfico que requiera apoyo o no objeción gubernamental (como se describe en este módulo), la solicitud superará con éxito la Revisión de nombres geográficos sin que se requieran pasos ni tarifas adicionales.

Para toda solicitud en la que el GNP determine que la cadena de caracteres de gTLD solicitada es un nombre geográfico que requiere el apoyo o la no objeción gubernamental, el GNP confirmará que el solicitante ha proporcionado la documentación requerida de los gobiernos o autoridades públicas pertinentes, y que la comunicación del gobierno o autoridad pública es legítima y contiene el contenido requerido. La ICANN podrá confirmar la autenticidad de la comunicación consultando a las autoridades diplomáticas pertinentes o a los miembros del Comité Asesor Gubernamental de la ICANN para el gobierno o autoridad pública de que se trate sobre la autoridad competente y el punto de contacto pertinente dentro de su administración para las comunicaciones.

El GNP podrá comunicarse con la entidad firmante de la carta para confirmar su intención y su comprensión de los términos en los que se concede el apoyo o la no objeción a una solicitud.

7.5.3.2.1 Evaluación extendida para la revisión de nombres geográficos

Una Revisión de nombres geográficos será sometida a una Evaluación extendida en las siguientes instancias:

Problemas con la documentación proporcionada: En los casos en que un solicitante no haya proporcionado la documentación requerida, se procederá a contactarlo y se le notificará sobre el requisito y se le dará un plazo limitado para brindar la documentación. Si el solicitante puede presentar la documentación antes del cierre del período de evaluación y se considera que la documentación cumple los requisitos, el solicitante superará con éxito la Revisión de nombres geográficos. Si no es así, el solicitante puede optar por una Evaluación extendida donde tendrá tiempo adicional para obtener la documentación requerida; sin embargo, si el solicitante no ha presentado la documentación solicitada para la fecha indicada (al menos 90 días desde la fecha de notificación), el solicitante no tendrá tiempo ni otras oportunidades en la ronda de solicitud actual para hacerlo. El solicitante puede volver a presentar la solicitud en rondas posteriores, si lo desea, con sujeción a las tarifas y requisitos de las rondas de solicitudes específicas. Consultar el Módulo 6 Procedimientos de evaluación de los solicitantes y el Módulo 7 Procedimientos de evaluación de la cadena de caracteres y solicitudes en Impugnación de la evaluación para obtener más información.
Apoyo o no objeción en conflicto para el mismo nombre geográfico: Como se señala en la Sección 5.5 Resolución de controversias para solicitudes de nombres geográficos, en el caso de que haya más de una solicitud para una cadena de caracteres que representa el mismo Nombre geográfico y haya recibido documentación de respaldo o no objeción de diferentes gobiernos o autoridades públicas, según lo establecido por el Panel de Nombres Geográficos, estas solicitudes también se someterán a una Evaluación extendida. Si, durante la Evaluación extendida, el Panel de Nombres Geográficos considera que las autoridades que respaldan todas las solicitudes pertinentes cumplen los criterios exigidos y acuerda que dichas solicitudes pueden pasar a la fase de resolución de controversias, se procederá a la subasta o a la CPE, si una de las solicitudes es una Solicitud de una comunidad y se opta por someterse a la CPE.

7.6 Evaluación de cadenas de caracteres variantes

Una cadena de caracteres variante se considera "igual" a la cadena de caracteres de gTLD principal solicitada o un gTLD existente ("cadena de caracteres principal") por parte de la comunidad que utiliza un código de escritura, según se define en las Reglas para la Generación de Etiquetas para la Zona Raíz (RZ-LGR).⁵⁹ Las RZ-LGR determinan los dominios de alto nivel válidos y sus cadenas de caracteres variantes.⁶⁰ Un solicitante que busque una o más cadenas de caracteres variantes asignables de un IDN principal solicitada o gTLD existente deberá justificar la necesidad de cada cadena de caracteres variante. Esta justificación será evaluada por un panel mediante un estándar general de razonabilidad sobre la base de los siguientes criterios, en el contexto del IDN gTLD principal solicitado o gTLD existente:

El significado o el significado previsto (para palabras que no pertenezcan al diccionario) de cada una de las cadenas de caracteres variantes solicitadas es coherente, según lo demuestren las fuentes proporcionadas por el solicitante.
La cadena de caracteres variante es reconocida como equivalente por la comunidad de usuarios a la que va dirigida.
Las ventajas y las comunidades de usuarios que se beneficiarán de la introducción de la cadena de caracteres variante solicitada.
Medidas que adoptará el solicitante para minimizar las complejidades operativas y administrativas de los gTLD variantes y los nombres de dominio variantes resultantes que afectan a los registradores, revendedores o registratarios.

Los compromisos adquiridos por el solicitante para minimizar las complejidades operativas y de gestión señaladas constituirán la base de los requisitos contractuales que se incluirán en el Acuerdo de Registro aplicable.

El solicitante debe cumplir con cada criterio para cada cadena de caracteres variante solicitada para continuar en el Programa. El resultado de la evaluación de cualquier cadena de caracteres variante solicitada no afectará el resultado de la evaluación de un IDN principal solicitado o cualquier otra cadena de caracteres variante solicitada que se incluya en la solicitud.

La capacidad de gestionar las cadenas de caracteres variantes solicitadas junto con el IDN principal solicitado o el gTLD existente será evaluada desde una perspectiva tanto técnica como operativa, como se describe en el Manual para RSP.⁶¹

7.6.1 Otros requisitos para las solicitudes de cadenas de caracteres variantes

Una cadena de caracteres variante solicitada estará sujeta a los mismos requisitos de solicitud y criterios de evaluación que el IDN principal solicitado asociado o gTLD existente. En concreto, los mismos requisitos de documentación se aplican tanto al IDN principal solicitado como a sus cadenas de caracteres variantes solicitadas. A efectos de aportar mayor claridad, una cadena de caracteres principal solicitada y sus cadenas de caracteres variantes solicitadas serán evaluadas juntas como un conjunto, pero se requerirá documentación pertinente para cada cadena de caracteres variante, según sea necesario.

Con respecto a los siguientes tres tipos de solicitudes especializadas:

Los solicitantes de IDN de una comunidad y sus cadenas de caracteres variantes deben presentar el mismo respaldo para las cadenas de caracteres variantes solicitadas según sea necesario para el IDN principal. Si un IDN de una comunidad se encuentra en controversia (consultar la Sección 5.2 Controversia por cadenas de caracteres y procedimientos de resolución de controversias) y opta por participar en la Evaluación con prioridad de la comunidad (CPE), entonces el IDN de la comunidad y sus cadenas de caracteres variantes solicitadas serán evaluados juntos como un conjunto (consultar la Sección 5.4 Evaluación con prioridad de la comunidad).
Un solicitante de un IDN de nombre geográfico y sus cadenas de caracteres variantes debe presentar documentación de respaldo o no objeción a su cadena de caracteres principal solicitada y cadenas de caracteres variantes solicitadas de gobiernos o autoridades públicas relevantes. Es decir, la documentación requerida de respaldo o no objeción debe hacer referencia tanto al IDN solicitado como a sus cadenas de caracteres variantes solicitadas. Consultar la Sección 7.5 Nombres geográficos.
Un solicitante de un IDN que presenta la solicitud como marca y sus cadenas de caracteres variantes está obligado a presentar prueba de que su cadena de caracteres primaria solicitada y cadenas de caracteres variantes solicitadas son idénticas a marcas comerciales registradas que posee y usa el solicitante. Es decir, cualquier cadena de caracteres variante solicitada también debe mostrar prueba de que es idéntica a marcas comerciales registradas que posee y utiliza el solicitante. Consultar la Sección 7.3 Evaluación de elegibilidad como TLD que representa a una marca.

7.6.2 Solicitud de cadenas de caracteres variantes de la lista de nombres reservados

Cuando un Nombre reservado es la cadena de caracteres principal, solo la organización asociada con ese Nombre reservado (consultar la Sección 7.2.2 Nombres reservados) tiene permitido solicitar sus cadenas de caracteres variantes a nivel superior. Aunque la cadena de caracteres variante no necesita ser un Nombre reservado, se genera como una cadena de caracteres variante del Nombre reservado mediante el uso de las RZ-LGR. Una solicitud de cadenas de caracteres variantes de un Nombre reservado no puede anteceder a una solicitud del Nombre reservado, que sirve como la cadena de caracteres principal para generar las cadenas de caracteres variantes.

7.6.3 Dependencia complementaria de cadenas de caracteres variantes

Todas las cadenas de caracteres variantes dependen de su IDN principal para la evaluación de la solicitud. Si un IDN principal solicitado es descalificado por cualquier motivo, como se describe en esta sección u otras secciones pertinentes de la Guía, entonces todas las cadenas de caracteres variantes asociadas también serán descalificadas. En dichos casos, no se admitirá el procesamiento de toda la solicitud.

Sin embargo, si alguna cadena de caracteres variante solicitada es descalificada y no puede continuar, entonces el solicitante deberá presentar un Pedido de cambios en una solicitud (ACR) para eliminar la cadena de caracteres variante solicitada descalificada y la solicitud pueda continuar. Si el ACR tiene éxito, el IDN principal solicitado correspondiente y cualquier cadena de caracteres variante solicitada restante que no sea descalificada podrán continuar.

7.7 Colisión de Nombres

La delegación de casi todo nuevo gTLD conlleva algún riesgo de colisión de nombres. La Colisión de nombres se refiere a la situación en la que el nombre de un recurso que está destinado a ser resuelto en un sistema de nombres⁶² es inadvertidamente resuelto en un sistema de nombres diferente, lo que podría provocar un comportamiento inesperado, como la interrupción o el desvío de la comunicación de su destinatario previsto.⁶³

Para evaluar y mitigar el riesgo de colisiones de nombres entre el DNS global y otros sistemas de nombres, la ICANN ha implementado el Marco para la gestión de riesgos de colisión de nombres, según las recomendaciones del Informe del Segundo Estudio del Proyecto de Análisis de Colisiones de Nombres,⁶⁴ según lo instruido por la Junta Directiva de la ICANN el 7 de septiembre de 2024.⁶⁵

Todas las cadenas de caracteres de gTLD solicitadas deben ser evaluadas en este marco antes de ser aprobadas para contratación y delegación. En esta sección se describe este marco y los procedimientos que se utilizarán para evaluar y, si es necesario, mitigar cualquier riesgo de colisión de nombres asociado con dichas cadenas de caracteres.

7.7.1 Acceso de los solicitantes a datos de riesgo longitudinales

Antes del inicio del período para la presentación de solicitudes, la ICANN publicará conjuntos de datos relacionados con todas las cadenas de caracteres por encima de cierto umbral de volumen de consultas que pueden ayudar a los solicitantes a evaluar el riesgo de colisión de nombres.

Las métricas para una cadena de caracteres solicitada constituyen solo uno de diversos factores, tanto cuantitativos como cualitativos por naturaleza, que se considerarán al evaluar el riesgo asociado con esa cadena.

De las aproximadamente 1400 cadenas de caracteres únicas que fueron solicitadas durante la última ronda, solo tres (.CORP, .HOME y .MAIL) fueron evaluadas como de alto riesgo.⁶⁶ No obstante, los solicitantes no deben dar por sentado que, si los conjuntos de datos indican un bajo volumen de colisiones de nombres, la cadena se considerará segura para su delegación.

7.7.2 Evaluación inicial de colisiones de nombres

Cada cadena de caracteres solicitada y toda cadena de caracteres variante asignable se someterá a la Evaluación inicial de colisiones de nombres mediante el uso de conjuntos de datos pertinentes que puedan obtenerse de, por ejemplo, registros de servidores raíz y registros de servidores recursivos del DNS, utilizando tanto el volumen como la diversidad de consultas, orígenes, nombres de consulta (etiquetas) y tipos de consulta; conjuntos de datos de Indicadores de Sanidad de Tecnologías de Identificadores (ITHI)⁶⁷; y evidencia cualitativa que pueda ayudar a deducir la gravedad del daño. El propósito de esta evaluación, que se llevará a cabo según el Procedimiento operativo para la evaluación inicial de colisiones de nombres,⁶⁸ es identificar preliminarmente cadenas de caracteres de alto riesgo.

La Evaluación inicial se llevará a cabo después del Día de confirmación de las cadenas de caracteres (Sección 3.6), y será supervisada por el Equipo de Revisión Técnica (TRT). La ICANN publicará un informe de Evaluación inicial en el cual se describe la evaluación, su metodología y hallazgos, una vez que finalice. Se llevará a cabo un período de Comentario público para el informe para permitir que la comunidad proporcione aportes sobre la metodología y los hallazgos.

7.7.3 Delegación temporaria y evaluación final

Las cadenas de caracteres (incluidas las cadenas de caracteres variantes) que no se identifiquen como de alto riesgo durante la Evaluación inicial de colisiones de nombres (Sección 7.7.2) se pondrán en cola para Delegación temporaria. La Delegación temporaria se iniciará una vez concluida la evaluación inicial, aunque se sigan realizando otras evaluaciones que formen parte de la Evaluación de la cadena de caracteres. La prioridad de la Delegación temporaria se determinará en función del número de prioridad asignado a la solicitud.⁶⁹ La duración de la Delegación temporaria se describirá en el Procedimiento operativo sobre la delegación temporaria en caso de colisión de nombres.⁷⁰ La conclusión de la Delegación temporaria no es condición necesaria para llevar adelante otras evaluaciones o resoluciones de controversias. Sin embargo, una solicitud podrá proceder a la etapa de contratación solo cuando la Delegación temporaria haya concluido y el Plan de mitigación se haya implementado, (según corresponda).

La proporción de delegaciones temporarias de las cadenas de caracteres se limitará para garantizar que el número de TLD delegados en la zona raíz del DNS no aumente en más de aproximadamente un cinco por ciento por mes. Se prevé que este límite corresponda a aproximadamente 75 delegaciones temporarias por mes inicialmente y aumentará a medida que se deleguen más nuevos gTLD temporalmente. Sin embargo, como las delegaciones permanentes tienen precedencia sobre las Delegaciones temporarias, este número puede variar de un mes a otro.

Durante la Delegación temporaria, la cadena de caracteres de gTLD solicitada se delegará a servidores de nombres del DNS gestionados por la ICANN con el fin de recopilar datos sobre el volumen y la naturaleza del tráfico del DNS para esa cadena de caracteres. Se utilizarán cuatro métodos de evaluación diferentes para notificación y generación de datos durante la Delegación temporaria. Dichos métodos se describen en el Apéndice 2 del Informe del Segundo Estudio del Proyecto de Análisis de Colisiones de Nombres y se denominan: Sin interrupción (NI); Interrupción controlada (CI); Interrupción visible (VI); e Interrupción visible y notificación (VIN). La evaluación será supervisada por el Equipo de revisión técnica (TRT), que consiste en expertos internos de departamentos relevantes de la ICANN. El TRT determinará caso por caso qué método o métodos se utilizarán para cada evaluación.

El TRT evaluará los datos recopilados durante la Delegación temporaria, que incluyen consultas del DNS a servidores de TLD, diversidad de consultas, orígenes, nombres de consulta (etiquetas), tipos de consulta, etc., así como datos recopilados mediante el uso de los métodos de evaluación, para determinar si la cadena de caracteres será:

Designada como de alto riesgo, en cuyo caso la cadena será eliminada inmediatamente de la zona raíz.
Elegible para continuar con el resto del procesamiento de la solicitud.

Independientemente del resultado de la Delegación temporaria, el TRT elaborará un informe de Delegación temporaria que describe los hallazgos, el cual será publicado para que los solicitantes y otras partes interesadas lo revisen.

7.7.4 Lista de cadenas de caracteres sujetas a colisiones

La ICANN mantendrá una Lista de cadenas de caracteres sujetas a colisiones, que es una lista de cadenas de caracteres que la ICANN ha determinado que presentan un alto riesgo de Colisión de nombres.

Una cadena de caracteres solicitada se agregará a la Lista de cadenas de caracteres sujetas a colisiones si (1) no se presenta un Plan de mitigación para esa cadena, (2) el Plan de mitigación no supera la Evaluación del plan de mitigación, o (3) el Plan de mitigación no es efectivo.

7.7.5 Evaluación del plan de mitigación de alto riesgo por colisión de nombres

El solicitante de una cadena de caracteres en la Lista de cadenas de caracteres sujetas a colisiones que haya resuelto la controversia puede enmendar su solicitud para agregar un Plan de mitigación de cadenas de caracteres de alto riesgo, que luego se evaluará. Esta evaluación se llevará a cabo según el Procedimiento operativo para la evaluación del plan de mitigación de alto riesgo por colisión de nombres⁷¹ y está sujeta a una tarifa adicional. Consultar la Sección 3.3 Tarifas y pagos.

Los solicitantes deben presentar un Pedido de cambios en una solicitud para agregar un Plan de mitigación en un plazo de 90 días (prorrogable hasta 180 días previa solicitud razonable) a partir de (a) la designación de la cadena de caracteres como de alto riesgo o, en caso de controversia, (b) la resolución de la controversia. Si el Pedido de cambios en una solicitud no se presenta dentro de este plazo, el estado de la solicitud pasará a Finalizada. Consultar la Sección 3.9 Estados de las solicitudes.

Se proporcionarán al solicitante los datos pertinentes generados durante la Evaluación inicial o la Delegación temporaria de la cadena de caracteres para que sirva de ayuda en el desarrollo del Plan de mitigación, con sujeción a los requisitos aplicables de protección de datos. En casos donde los datos incluyan datos personales y donde las medidas de protección técnicas, como la anonimización o la agregación, no puedan aplicarse efectivamente, la ICANN puede solicitar celebrar un Acuerdo de Procesamiento de Datos (DPA) con el solicitante.

El Plan de mitigación presentado por el solicitante debe contener como mínimo lo siguiente:

Un resumen de los hallazgos de la Evaluación inicial, y, si corresponde, de los hallazgos del Equipo de revisión técnica durante la Delegación temporaria.
Un Análisis de causas raíz y cualquier otra evidencia relevante, que identifique las razones subyacentes por las que pueden ocurrir colisiones de nombres para la cadena de caracteres.
Un Plan de mitigación que describa las medidas preventivas y correctivas específicas que tomará el solicitante para mitigar el riesgo de colisión de nombres, incluidas las actividades de comunicación con los usuarios finales afectados. Cada acción de mitigación debe tener un plazo específico para su implementación. El plazo total no debe superar los dos años.

El Plan de mitigación será evaluado por un panel de expertos técnicos, que puede asesorar al solicitante sobre posibles mejoras al mismo. En caso de que se requieran enmiendas, se permitirán 90 días adicionales para dichas enmiendas. La evaluación determinará si el plan (a) identifica correctamente la causa raíz de las colisiones y (b) tiene una alta probabilidad de ser efectivo.

La ICANN publicará el Plan de mitigación y los resultados de la Evaluación del plan de mitigación para comentarios. El panel revisará todos los comentarios recibidos, y los considerará, antes de tomar su decisión definitiva. Dentro del Plan de mitigación, los solicitantes podrán identificar secciones que contengan información que, de hacerse pública, podría socavar la efectividad del plan, como por ejemplo cuando podría posibilitar a un actor malicioso interferir con las mitigaciones, y marcar estas secciones para que sean omitidas. Si el panel está de acuerdo, las secciones marcadas serán omitidas antes de la publicación.

Si el Plan de mitigación contempla actividades de mitigación que se llevan a cabo antes de la delegación de la cadena de caracteres, la solicitud no seguirá adelante hasta que dichas actividades se hayan llevado a cabo y el Panel de evaluación haya confirmado su eficacia utilizando los mismos criterios aplicados durante la Evaluación inicial.

En los casos en que el Panel de evaluación determine que, por razones técnicas, una medida de mitigación debe implementarse después de que el operador de registro haya delegado la cadena de caracteres para su operación (una vez finalizada la evaluación), por ejemplo, si los problemas de Colisión de nombres se limitan a un nombre de segundo nivel que el registro acuerda nunca delegar, se podrá permitir que la solicitud continúe con el resto del proceso de tramitación siempre y cuando el solicitante acepte agregar los requisitos aplicables del Plan de mitigación a su Acuerdo de Registro.

Si el Panel de evaluación establece que el Plan de mitigación (a) no identifica correctamente la causa raíz de las colisiones o (b) no tiene una alta probabilidad de ser efectivo, no se permitirá que la solicitud proceda, y el estado de la solicitud se cambiará a Finalizada.

7.7.5.1 Impugnación de la Evaluación del plan de mitigación

El solicitante tendrá la oportunidad de impugnar el resultado de una Evaluación del plan de mitigación con respecto a su propia solicitud si cree que el panel ha cometido un error de hecho o de procedimiento cuando decidió que el Plan de mitigación (a) no identifica correctamente la causa raíz de las colisiones o (b) no tiene una alta probabilidad de ser efectivo. Para iniciar un procedimiento de Impugnación de la evaluación, el solicitante debe presentar una impugnación dentro del plazo de 21 días a partir de la fecha en que se transmitió la decisión de la evaluación. Un Panel de impugnación, que consiste en las mismas personas responsables de la evaluación inicial del plan, llevará a cabo la revisión de impugnación.

La Impugnación de la evaluación se evaluará en virtud de un estándar de revisión "de error manifiesto". En concreto, el Panel de impugnación deberá aceptar la resolución del Panel de evaluación, a menos que el Panel de evaluación: (1) no haya seguido los procedimientos apropiados, o (2) no haya considerado/solicitado evidencias o información material necesaria.

El plazo para presentar una impugnación será dentro de los 21 días desde la fecha en que el solicitante recibe la notificación de la decisión de la evaluación que procura impugnar. El Panel de impugnación comunicará el resultado del procedimiento de impugnación en un plazo de 30 días a partir de la presentación de dicha impugnación por parte del solicitante.

Si el Panel de impugnación encuentra un error de hecho o de procedimiento, se volverá a evaluar el Plan de mitigación. El Panel de evaluación llevará a cabo la reevaluación y proporcionará el resultado a la ICANN. La ICANN publicará los resultados y proporcionará un período de comentarios de 30 días. Una vez finalizado el período de comentarios, la ICANN considerará toda la información disponible y tomará una decisión final sobre si aceptar o rechazar el Plan de mitigación. Si se rechaza el plan, el estado de la solicitud pasará a Finalizada.

Si el Panel de impugnación no encuentra un error de hecho o de procedimiento con la evaluación inicial del Plan de mitigación, no se permitirá que la solicitud proceda y el estado de la solicitud se cambiará a Finalizada.

7.7.6 Interacción con cadenas de caracteres variantes

Todas las cadenas de caracteres principales solicitadas, incluidas las cadenas de caracteres variantes asignables solicitadas, serán evaluadas con relación al riesgo de Colisión de nombres a través de los procesos de Evaluación inicial y Delegación temporaria descritos anteriormente.

Si se establece que una cadena de caracteres principal o cadena de caracteres variante asignable es de alto riesgo, entonces la solicitud no puede continuar hasta que se haya llevado a cabo el proceso de Evaluación del plan de mitigación. Sin embargo, en el caso de una cadena de caracteres variante asignable, la solicitud puede ser enmendada para eliminar esa cadena de caracteres, lo cual permitiría que la solicitud enmendada pueda continuar. La eliminación de una cadena de caracteres variante asignable puede ocurrir en cualquier momento siempre y cuando el estado de la solicitud no se haya cambiado a Finalizada.

7.8 Compromisos en pos del interés público, Compromisos voluntarios de los operadores de registro y Políticas de registración para la comunidad

La misión de la ICANN es garantizar la operación estable y segura de los sistemas de identificadores únicos de Internet.⁷² El Programa de Nuevos gTLD respalda esto con diversas medidas de protección integradas, entre las que se incluyen una evaluación rigurosa de las cadenas de caracteres de gTLD solicitadas, las solicitudes y los operadores, así como exigir el cumplimiento del Acuerdo de Registro.

Los Compromisos en pos del interés público (PIC), específicamente los PIC obligatorios (consultar la Sección 7.8.1) y los PIC sobre medidas de protección (consultar la Sección 7.8.2), son una protección importante que se incorpora en el Programa de Nuevos gTLD. Esos PIC son compromisos vinculantes del Acuerdo de Registro en la Especificación 11, y la ICANN los utiliza para exigir el cumplimiento. Los PIC obligatorios y los PIC sobre medidas de protección son uniformes en todos los Acuerdos de Registro pertinentes y se implementaron en respuesta a las preocupaciones del Comité Asesor Gubernamental (GAC) sobre las solicitudes en la ronda de solicitudes de 2012. Los temas principales abordados incluyen protección al consumidor, derechos de propiedad intelectual y sectores de mercado regulados como el sector financiero, la salud y las organizaciones benéficas.⁷³

Además de los PIC, se permitirá a un solicitante proponer uno o más Compromisos voluntarios de los operadores de registro (RVC) (consultar la Sección 7.8.3) para proporcionar medidas de protección adicionales con respecto a la operación de una cadena de caracteres de gTLD solicitada. Un solicitante puede proponer un RVC para abordar preocupaciones que no estén ya abordadas por los PIC obligatorios o sobre medidas de protección o por otros medios. Como se establece con mayor detalle en la Sección 7.8.3 Compromisos voluntarios de los operadores de registro, los RVC propuestos están sujetos a un proceso de evaluación separado, es decir, la Evaluación de compromisos de los operadores de registro (RCE). La ICANN solo aprobará un RVC propuesto si: (1) el RVC cumple con los criterios de la RCE (consultar la Sección 7.8.3.3); y (2) el solicitante y la ICANN acuerdan cada uno que, si el RVC propuesto se incluye en el Acuerdo de Registro, su cumplimiento sería exigible en virtud de los Estatutos de la ICANN y en la práctica. Al igual que con los PIC, los RVC (una vez aprobados e incorporados en el Acuerdo de Registro) son compromisos vinculantes en la Especificación 11 del Acuerdo de Registro Base.⁷⁴

Tanto los PIC como los RVC están sujetos al Procedimiento para la Resolución de Disputas en Materia de Compromisos de Interés Público (PICDRP).⁷⁵

Como se detalla en la Sección 7.1 Tipos de cadenas de caracteres y solicitudes, un solicitante puede optar por designar una cadena de caracteres de gTLD solicitada como gTLD de la comunidad. Si el solicitante identifica una cadena de caracteres de gTLD solicitada como gTLD de la comunidad, debe proponer Políticas de registración para la comunidad en el Acuerdo de Registro (consultar la Sección 7.8.4) para su inclusión en el Acuerdo de Registro correspondiente que la ICANN evaluará aplicando los criterios de la RCE (consultar la Sección 7.8.3.3).

7.8.1 Compromisos obligatorios en pos del interés público

Los PIC obligatorios se incluyen en cada Acuerdo de Registro. Los PIC obligatorios requieren que cada operador de registro implemente medidas para proteger a los registratarios de gTLD y a los usuarios de Internet de manera más amplia, e incluyen obligaciones relacionadas con: mitigación de actividades abusivas; verificaciones de seguridad; y transparencia en la operación. Los PIC obligatorios se incluyen en la Especificación 11 sección 3(a)-(d) del Acuerdo de Registro Base (consultar el Apéndice 4), a saber:

El operador de registro incluirá una cláusula en su Acuerdo entre Registro y Registrador que exija a los registradores la inclusión, en sus Acuerdos de Registración, de una cláusula mediante la cual se prohíba a los titulares de nombres registrados distribuir software malicioso, redes de robots de operación abusiva, suplantación de identidad, infracción de marcas comerciales o violación de propiedad intelectual, prácticas fraudulentas o engañosas, falsificaciones u otra participación en actividades ilegales, y que explicite (de acuerdo con la legislación aplicable y todo procedimiento relacionado) las consecuencias resultantes de dichas actividades, incluida la suspensión del nombre de dominio.
El operador de registro llevará a cabo periódicamente un análisis técnico, a fin de evaluar si los dominios en su TLD están siendo utilizados para perpetrar Uso indebido del DNS. El operador de registro mantendrá informes estadísticos sobre los casos de Uso indebido del DNS y las acciones adoptadas como resultado de los controles periódicos relativos a la seguridad. El operador de registro mantendrá estos informes durante el plazo de vigencia del acuerdo, a menos que un período más corto sea requerido por ley o aprobado por la ICANN, y suministrará dichos informes a la ICANN cuando le sean solicitados.⁷⁶
El operador de registro operará el TLD de manera transparente en consonancia con los principios generales de transparencia y de no discriminación al establecer, publicar y adherirse a claras políticas de registro.
El operador de registro de un TLD de "cadena de caracteres genérica" no puede imponer criterios de elegibilidad para el registro de nombres en el TLD, que limiten los registros exclusivamente a una sola persona o entidad y/o "afiliados" de esa persona o entidad (conforme se define en la Sección 2.9 (c) de Acuerdo de Registro Base). El término "cadena de caracteres genérica" se define como una cadena de caracteres que consiste en una palabra o término que denomina o describe una clase general de bienes, servicios, grupos, organizaciones o cosas, en contraposición a distinguir una marca especifica de bienes, servicios, grupos, organizaciones o cosas de otras.

Para obtener más información sobre cadenas de caracteres genéricas, consultar la Sección 3.1.7 Genéricos cerrados/Cadenas de caracteres genéricas exclusivas.

7.8.2 Compromisos en pos del interés público sobre medidas de protección

Los PIC sobre medidas de protección son disposiciones que se exigen en determinados Acuerdos de Registro, además de los PIC obligatorios incluidos en todos los Acuerdos de Registro.

La ICANN clasifica los gTLD que necesitan PIC sobre medidas de protección en cuatro grupos basados en el riesgo:

Sectores regulados/Requisitos de libre ingreso: Cadenas de caracteres que invocan confianza del consumidor, pero con riesgos elevados.
Sectores altamente regulados/Requisitos de ingreso cerrado: Cadenas de caracteres asociadas con industrias que requieren licencias o acreditación.
Potencial de ciberacoso/hostigamiento: Cadenas de caracteres que podrían facilitar el acoso.
Funciones inherentemente gubernamentales: Cadenas de caracteres asociadas a dominios gubernamentales.

Consultar información más detallada y los ejemplos que se incluyen en la tabla de la Sección 7.8.2.2 PIC sobre medidas de protección aplicables por categoría de cadena de caracteres.

Si la ICANN establece durante la evaluación que una cadena de caracteres de gTLD solicitada se enmarca dentro de una o más de las categorías establecidas en la Sección 7.8.2.2 PIC sobre medidas de protección aplicables por categoría de cadena de caracteres, los PIC sobre medidas de protección aplicables (consultar la Sección 7.8.2.3) deben incluirse en la Especificación 11 del Acuerdo de Registro Base correspondiente sin modificaciones.⁷⁷

Los PIC sobre medidas de protección se desarrollaron e implementaron en respuesta al Asesoramiento consensuado del GAC en el Comunicado pronunciado en la reunión ICANN46 en Pekín⁷⁸ y la posterior Resolución de la Junta Directiva de la ICANN⁷⁹ durante la Ronda de 2012 del Programa de Nuevos gTLD.⁸⁰

7.8.2.1 Definición del grupo de cadenas de caracteres

En la solicitud, el solicitante debe responder preguntas para evaluar qué PIC sobre medidas de protección, si los hay, serían requeridos en el Acuerdo de Registro (consultar el Conjunto de Preguntas 10 Evaluación de medidas de protección/Misión y propósito en el Apéndice 1 Preguntas incluidas en la solicitud). Las respuestas del solicitante serán publicadas con la solicitud.

Al cierre de un período de comentarios de la solicitud, la ICANN determinará si cada cadena de caracteres de gTLD solicitada se enmarca o no en uno de los cuatro grupos de PIC sobre medidas de protección. Esta decisión concluye la evaluación y sirve como aporte para el procedimiento de contratación. No se puede impugnar en virtud de la Evaluación extendida e Impugnaciones de las evaluaciones (Sección 1.2.14), porque no afecta el avance de la solicitud.

Consultar la Sección 4.1 Comentarios de la solicitud para obtener más información sobre los períodos de comentarios sobre la solicitud.

7.8.2.2 PIC sobre medidas de protección aplicables por categoría de cadenas de caracteres

La ICANN utilizará el marco a continuación para determinar si una cadena de caracteres de gTLD solicitada requiere PIC sobre medidas de protección y, de ser así, cuáles son los PIC sobre medidas de protección que corresponden. El marco identifica los cuatro grupos de cadenas de caracteres establecidos en respuesta al Asesoramiento consensuado del GAC en el Comunicado pronunciado en la reunión ICANN46 en Pekín y proporciona descripciones y ejemplos relevantes.⁸¹ La ICANN aplicará los PIC sobre medidas de protección a las cadenas de caracteres de gTLD solicitadas que se identifiquen como pertenecientes a los grupos de cadenas de caracteres establecidos en el Comunicado del GAC pronunciado en la reunión ICANN46.

El marco identifica cuáles de los diez PIC sobre medidas de protección se aplican a cada una de las cuatro categorías de cadenas de caracteres.

Tabla 7-2: Marco de PIC sobre medidas de protección

Grupo de cadenas de caracteres n.°	Grupo de cadenas de caracteres	Descripción	Medidas de protección requeridas
1	Sectores regulados/Requisitos de entrada abierta en múltiples jurisdicciones	Es probable que la cadena de caracteres invoque un nivel de confianza implícita de los consumidores Es probable que la cadena de caracteres conlleve riesgos elevados de perjuicio a los consumidores La cadena de caracteres está asociada a un sector generalmente abierto, pero puede requerir registración limitada Consultar la lista no exhaustiva de cadenas de caracteres identificadas por el GAC como pertenecientes a este grupo en el Comunicado pronunciado en la reunión ICANN46 en Pekín.⁸² Ejemplos: .kid, .degree, .audio, .town	1-3
2	Sectores con alto nivel de regulación/Requisitos de entrada cerrada en múltiples jurisdicciones	La cadena de caracteres está asociada con una industria donde se requiere licencia o acreditación por parte de gobiernos locales, regionales o nacionales. Esto generalmente implica una evaluación de cualificaciones, inspecciones periódicas y supervisión gubernamental continua Consultar la lista no exhaustiva de cadenas de caracteres identificadas por el GAC como pertenecientes a este grupo en el Comunicado pronunciado en la reunión ICANN46 en Pekín.⁸³ Ejemplos: .cash, .bet, .abogado, .earth, .care	1-8
3	Potencial de ciberacoso/hostigamiento	El significado implícito o real de la cadena de caracteres podría resultar en que el gTLD sea utilizado para facilitar hostigamiento o ciberacoso Ejemplos de cadenas de caracteres identificadas por el GAC como pertenecientes a este grupo en el Comunicado pronunciado en la reunión ICANN46 en Pekín⁸⁴: .fail, .gripe, .sucks, .wtf	1-9
4	Funciones inherentemente gubernamentales	La cadena de caracteres está asociada con una función que es inherentemente del dominio del gobierno, como las fuerzas armadas Ejemplos de cadenas de caracteres identificadas por el GAC como pertenecientes a este grupo en el Comunicado pronunciado en la reunión ICANN46 en Pekín⁸⁵: .army, .navy, .airforce	1-8 y 10

7.8.2.3 PIC sobre medidas de protección

Los diez PIC sobre medidas de protección incluyen requisitos para que los registratarios cumplan con las leyes aplicables, implementen medidas de seguridad apropiadas, proporcionen información de contacto, posean credenciales necesarias e informen cambios sustanciales a las credenciales, entre otras obligaciones. Los PIC sobre medidas de protección se describen en la siguiente tabla:

Tabla 7-2: Tipos de PIC sobre medidas de protección

PIC sobre medidas de protección	Texto de los PIC sobre medidas de protección
1	El operador de registro incluirá una disposición en sus Acuerdos entre Registro y Registrador que solicite que los registradores incluyan en sus Acuerdos de Registración una disposición que exija a los registratarios cumplir con todas las leyes aplicables, incluidas aquellas relacionadas con la privacidad, la recopilación de datos, la protección de los consumidores (incluso en relación con conductas engañosas), los préstamos justos, el cobro de deudas, el pharming orgánico, la divulgación de los datos y las revelaciones financieras.
2	El operador de registro incluirá una disposición en sus Acuerdos entre Registro y Registrador que solicite que los registradores, al momento de la registración, notifiquen a los registratarios de la obligación de cumplir con todas las leyes aplicables.
3	El operador de registro incluirá una disposición en sus Acuerdos entre Registro y Registrador que solicite a los registradores incluir en sus Acuerdos de Registración una disposición que exija a los registratarios que recaban y mantienen datos financieros o en materia de salud sensibles implementar medidas de seguridad razonables y adecuadas para la prestación de dichos servicios, tal como se define en la regulación vigente.
4	El operador de registro creará de forma proactiva una vía clara para la creación de una relación de trabajo con los organismos regulatorios o de auto regulación de la industria que sean relevantes al publicar un punto de contacto y al invitar a dichos organismos a establecer un canal de comunicación, entre otras cosas, con el fin de facilitar el desarrollo de una estrategia para mitigar los riesgos de actividades fraudulentas o ilegales.
5	El operador de registro incluirá en sus Acuerdos entre Registro y Registrador una disposición que solicite a los registradores incluir en sus Acuerdos de Registración una disposición que exija a los registratarios proporcionar información de contacto administrativo, la cual debe estar actualizada, a fin de efectuar las notificaciones en caso de reclamos o informes por uso indebido de la registración y los datos de contacto de los órganos regulatorios o de la industria de autorregulación en su lugar principal de actividad comercial.
6	El operador de registro incluirá una disposición en sus Acuerdos entre Registro y Registrador que solicite a los registradores incluir en sus Acuerdos de Registración una disposición que exija una declaración de que el registratario posee todas las autorizaciones, cartas, licencias y/u otras credenciales relacionadas para la participación en el sector asociado con el TLD.
7	Si el operador de registro recibe un reclamo que expresa dudas con respecto a la autenticidad de las licencias o credenciales, el operador de registro debe consultar a las autoridades nacionales de supervisión o sus equivalentes.
8	El operador de registro incluirá una disposición en sus Acuerdos entre Registro y Registrador que solicite a los registradores incluir en sus Acuerdos de Registración una disposición que obligue a los registratarios a informar cualquier cambio importante en la validez de las autorizaciones, cartas, licencias y/u otras credenciales de los registratarios para la participación en el sector asociado con la cadena de caracteres del TLD a fin de garantizar que continúen cumpliendo con las regulaciones y requisitos de licencia adecuados y que, en general, lleven a cabo sus actividades en pos del interés de los consumidores para los que prestan el servicio.
9	El operador de registro desarrollará y publicará políticas de registración para minimizar el riesgo de ciberacoso y/u hostigamiento.
10	El operador de registro incluirá una disposición en sus Acuerdos entre Registro y Registrador que exige a los registradores que incluyan en sus Acuerdos de Registración una disposición que requiera una declaración que indique que el registratario adoptará medidas razonables para evitar tergiversar o implicar falsamente que el registratario o su empresa están afiliados, patrocinados o respaldados por una o más fuerzas militares de un país o gobierno si dicha afiliación, patrocinio o respaldo no existe.

7.8.3 Compromisos voluntarios de los operadores de registro

Puede haber circunstancias en las que la multitud de medidas de protección incorporadas en el proceso de solicitud y en el Acuerdo de Registro, incluidos los PIC obligatorios y sobre medidas de protección, no aborden completamente un problema específico con una solicitud o Acuerdo de Registro propuesto. En estas circunstancias, el solicitante puede considerar proponer un RVC para ayudar a resolver el problema potencial.

La decisión de un solicitante de proponer un RVC suele ser voluntaria, excepto en el caso de aquellos reconocidos por la ICANN para resolver una objeción o para abordar el Asesoramiento consensuado del GAC (consultar la explicación en la Sección 7.8.3.2.3.1 Situación 1: Compromisos adquiridos para resolver las objeciones o Asesoramiento consensuado del GAC). Estos compromisos serán contractualmente vinculantes si se aprueban e incluyen en el Acuerdo de Registro. Los RVC pueden variar, lo que podría aumentar los compromisos relacionados con el interés público o codificar los compromisos de las partes interesadas. Un RVC también podría instituir medidas de protección que pueden ayudar a resolver una inquietud de terceros con respecto a una solicitud o a una cadena de caracteres de gTLD solicitada. Por ejemplo, los solicitantes podrían proponer los RVC en respuesta a Objeciones, Alertas tempranas de miembros del GAC o Asesoramiento consensuado del GAC, comentarios sobre la solicitud u otras cuestiones que de otro modo podrían afectar de forma negativa el proceso de evaluación de la solicitud. Consultar la Sección 3.8 Pedidos de cambios en una solicitud y el Módulo 4 Aportes de la comunidad, objeciones y apelaciones para más detalles sobre estos temas.

Un solicitante puede incluir un RVC propuesto en su solicitud o solicitar agregar uno posteriormente a través del proceso de Pedido de cambios en una solicitud (consultar la sección 3.8), que incluye un período de comentarios sobre solicitudes y otras condiciones.

Todos los RVC propuestos presentados con la solicitud o como un Pedido de cambios en una solicitud aparecerán en la sección pública de la solicitud, accesible en el sitio web⁸⁶ del Programa de Nuevos gTLD, y estarán abiertos al público para revisión y comentarios durante el período de comentarios sobre solicitudes (consultar la Sección 4.1 Comentarios sobre solicitudes).

7.8.3.1 Factores a considerar antes de proponer un RVC

Antes de decidir proponer un RVC, se recomienda a los solicitantes revisar los Estatutos de la ICANN; los acuerdos pertinentes de la ICANN, incluido, entre otros, el Acuerdo de Registro y el Acuerdo de Acreditación de Registradores (RAA); y las Políticas de Consenso de la ICANN y las Políticas temporarias. Los solicitantes y cualquier tercero que plantee preocupaciones sobre cualquier solicitud deben considerar si las disposiciones estandarizadas preexistentes podrían proporcionar medidas de protección suficientes para la cadena de caracteres de gTLD solicitada, a fin de evitar la necesidad de la evaluación e implementación de un RVC personalizado.⁸⁷

La comunidad de la ICANN recomendó que la ICANN incluya los PIC obligatorios en cada Acuerdo de Registro y también incluya PIC sobre medidas de protección (cuando corresponda) en los Acuerdos de Registro para cadenas de caracteres identificadas durante el proceso de evaluación como pertenecientes a los cuatro grupos de cadenas de caracteres establecidos en la Sección 7.8.2 Compromisos en pos del interés público sobre medidas de protección. En algunos casos, puede ser posible para un solicitante que no esté obligado a implementar los PIC sobre medidas de protección proponer utilizar uno o más de los PIC sobre medidas de protección aprobados como un RVC para resolver problemas o preocupaciones planteadas respecto a una solicitud o una cadena de caracteres de gTLD solicitada.

Además, el solicitante debe considerar si el desempeño de un RVC propuesto requiere la operación de un Servicio de registro adicional.⁸⁸ En tal caso, el solicitante deberá ponerse en contacto con el Proveedor de servicios de registro (RSP) seleccionado para analizar la implementación de dicho servicio de registro adicional, que deberá ser evaluado a través del Programa del RSP y aprobado por la ICANN. Si la ICANN identifica un RVC propuesto que requiere la operación a través de un Servicio de registro adicional, y dicho Servicio de registro aún no ha sido aprobado para el RSP seleccionado del solicitante, entonces el RSP debe buscar la aprobación de la ICANN a través del Programa de RSP antes de que la ICANN considere aprobar el compromiso propuesto como un RVC.⁸⁹

Cualquier RVC propuesto que sea incompatible con los Estatutos, políticas y acuerdos de la ICANN no será aprobado, como se explica en la Sección 7.8.3.3 Criterios de Evaluación de compromisos de los operadores de registro.

Se recomienda al solicitante que considere si existen otros medios, además del Acuerdo de Registro, que podrían ayudar a resolver los problemas planteados respecto de la solicitud o la cadena de caracteres de gTLD solicitada. Por ejemplo, un solicitante puede considerar abordar las preocupaciones, posiblemente en consulta con el tercero que las planteó, incluidos los compromisos pertinentes en las propias políticas de registro del solicitante, términos de uso o a través de un acuerdo aparte entre el solicitante y el tercero. La ICANN no exigirá el cumplimiento de ningún acuerdo independiente de este tipo, y ningún tercero será "tercero beneficiario" del Acuerdo de Registro con la ICANN.⁹⁰

7.8.3.2 Evaluación de compromisos de los operadores de registro

Cada RVC propuesto para cada cadena de caracteres de gTLD solicitada (y sus cadenas de caracteres variantes asignables solicitadas, según corresponda) estará sujeto a evaluación y aprobación de la ICANN a través de la Evaluación de compromisos de los operadores de registro (RCE). El propósito de la RCE es determinar si un compromiso propuesto cumple con todos los criterios de evaluación establecidos en los Criterios de RCE (consultar la Sección 7.8.3.3) para su inclusión en el Acuerdo de Registro.

Cada Política de registración para la comunidad propuesta para su inclusión en el Acuerdo de Registro correspondiente también estará sujeta a la Evaluación de compromisos de los operadores de registro (consultar la Sección 7.8.4 Políticas de registración para la comunidad). Consultar la Sección 7.8.3.5 RVC propuesto para cadenas de caracteres variantes para obtener más información sobre esta evaluación para cadenas de caracteres variantes.

En la solicitud, los solicitantes que deseen presentar RVC propuestos y Políticas de registración para la comunidad para su inclusión en el Acuerdo de Registro deben responder una serie de preguntas que están diseñadas para facilitar la evaluación de la ICANN (consultar el Apéndice 1 Preguntas incluidas en la solicitud).

Un solicitante que presente los RVC o Políticas de registración para la comunidad está obligado a realizar un pago fijo por única vez que cubre el costo de la Evaluación de compromisos de los operadores de registro. Para obtener detalles sobre tarifas asociadas con la RCE, consultar la Sección 3.3.2 Evaluaciones condicionales.

7.8.3.2.1 Los solicitantes deben identificar los propósitos de los RVC propuestos

El solicitante debe proporcionar información de referencia para explicar por qué su RVC propuesto es relevante, importante y necesario para respaldar la solicitud. La ICANN llevará a cabo una prueba de exhaustividad para este requisito cuando el RVC sea propuesto por el solicitante, antes de la Evaluación de compromisos de los operadores de registro. Esta información ayudará a proporcionar contexto para el RVC propuesto y, en ciertos casos, podría ser útil si se necesitan ajustes a los términos del RVC para cumplir con los objetivos del compromiso propuesto mientras también se cumplen los criterios para que un RVC se incluya en el Acuerdo de Registro, como se explica en la Sección 7.8.3.3 Criterios de Evaluación de compromisos de los operadores de registro.

Por ejemplo, si un RVC propuesto responde a una objeción de un tercero, el solicitante debe identificar la objeción específica y el objetor, proporcionar las referencias o enlaces relevantes a la objeción, y ofrecer otros detalles pertinentes. Estos detalles podrían incluir, entre otros, cómo el solicitante construyó el RVC propuesto para abordar la preocupación, si el solicitante consultó con el objetor en el desarrollo del RVC propuesto y los medios y sistemas establecidos para garantizar el cumplimiento del RVC.

7.8.3.2.2 Regla general: La Evaluación de compromisos de los operadores de registro para RVC propuestos no afecta el avance de la solicitud

En circunstancias distintas a las que se identifican en la Sección 7.8.3.2.3 Excepción: La Evaluación de compromisos de los operadores de registro para RVC propuestos afecta el avance de la solicitud, la Evaluación de compromisos de los operadores de registro para RVC propuestos no afectará a la continuidad de la solicitud. Fuera de estas circunstancias excepcionales, la Evaluación de compromisos de los operadores de registro no tiene impacto en la evaluación de la capacidad de un solicitante o solicitud de proceder a la contratación, sino que simplemente determina si el RVC propuesto cumple con los criterios para su inclusión en el Acuerdo de Registro aplicable si la solicitud avanza.

La evaluación no determinará si el RVC propuesto aborda exitosamente las preocupaciones de terceros. Aunque la ICANN puede considerar los comentarios sobre la solicitud y otros aportes y puede consultar a terceros durante la evaluación, en general no involucrará a terceros en esta evaluación.

Se recomienda a los solicitantes que tengan la intención de proponer un RVC para resolver una objeción u otra inquietud de terceros que se comuniquen primero con la parte o partes interesadas. Si pueden acordar un RVC que aborde el problema antes de presentar un Pedido de cambios en una solicitud, es posible evitar que la ICANN evalúe un RVC propuesto que el tercero cree que no resuelve adecuadamente la preocupación respecto a la solicitud o al gTLD solicitado. Si un solicitante propone un RVC durante los procedimientos de objeción para resolver una objeción o preocupación de terceros, y dicho RVC es aprobado por la ICANN, el objetor u otro tercero debe decidir por separado si continuar con sus inquietudes y de qué manera hacerlo.

Por ejemplo, si una solicitud propone un RVC para abordar una objeción durante el período de "reflexión", una vez que la Evaluación de compromisos de los operadores de registro concluya, ya sea mediante la aprobación o rechazo del RVC, el objetor puede entonces decidir si desea continuar con la objeción. Por poner otro ejemplo, un solicitante podría proponer un RVC como un Pedido de cambios en una solicitud después de recibir una Alerta temprana de miembros del GAC para reducir el riesgo de recibir posteriormente un Asesoramiento consensuado del GAC que podría obstaculizar el progreso de la solicitud. En este caso, la evaluación no determinaría si el RVC propuesto probablemente atenuaría la preocupación planteada en la Alerta temprana de miembros del GAC, pero la aprobación del RVC podría aportar información para los debates del GAC sobre la emisión de Asesoramiento consensuado a la Junta Directiva respecto a la solicitud o cadena de caracteres de gTLD solicitada.

Si un solicitante tiene planificado proponer un RVC como un Pedido de cambios en una solicitud para abordar una preocupación de terceros, el solicitante debe tener en cuenta los plazos y procesos pertinentes para objeciones, Asesoramiento consensuado del GAC, Alertas tempranas de miembros del GAC, comentarios sobre la solicitud, etc., si desea que el RVC se tenga en cuenta en dichos procesos (consultar el Módulo 4 Aportes de la comunidad, objeciones y apelaciones). Como se señaló anteriormente, todos los RVC propuestos que se presentan como un Pedido de cambios en una solicitud (consultar la Sección 3.8) están sujetos a un período de comentarios sobre la solicitud.

7.8.3.2.3 Excepción: La Evaluación de compromisos de los operadores de registro para RVC propuestos afecta el avance de la solicitud

El resultado de la Evaluación de compromisos de los operadores de registro para un RVC propuesto solo puede afectar el avance de la solicitud en dos casos. Consultar la Sección 3.9 Estados de las solicitudes para saber qué esperar cuando se determina que una solicitud no puede continuar.

7.8.3.2.3.1 Situación 1: Compromisos adquiridos para resolver las objeciones o Asesoramiento consensuado del GAC

Si la ICANN reconoce un RVC para resolver una objeción o abordar el Asesoramiento consensuado del GAC, estará sujeto a restricciones más estrictas durante el proceso de solicitud y después de la ejecución del contrato.

Aunque los RVC propuestos en esta circunstancia están etiquetados como "voluntarios", la ICANN reconoce que no son únicamente propuestos a discreción del propio solicitante, sino que son condiciones necesarias para que la solicitud pueda continuar.

Un RVC debe ser aprobado por la ICANN a través de la Evaluación de compromisos de los operadores de registro para resolver una objeción o abordar Asesoramiento consensuado del GAC. Sin dicha aprobación, la solicitud no puede continuar.⁹¹ Consultar la Sección 4.5.8.13 Objeciones y Compromisos voluntarios de los operadores de registro y la Sección 4.3.3 Asesoramiento consensuado del GAC y Compromisos voluntarios de los operadores de registro.

Los RVC propuestos para resolver objeciones o Asesoramiento consensuado del GAC están abiertos al público para revisión y comentarios a través de un período de comentarios sobre la solicitud. Si las negociaciones con la ICANN dan lugar a cambios para su aprobación, tanto la propuesta original como las versiones aprobadas por la ICANN serán publicadas para comentarios. Consultar más información en la Sección 3.8 Pedidos de cambios en una solicitud.

Debido al propósito específico que cumplen estos RVC, los solicitantes y los operadores de registros, por lo general, no podrán, salvo en circunstancias extraordinarias, modificar sustancialmente o eliminar estos compromisos una vez que hayan sido aprobados por la ICANN. Se prevé que estos compromisos se incluyan en una subsección separada de la Especificación 11 para dejar en claro que están sujetos a restricciones más estrictas. Consultar la Sección 7.8.3.4 Adiciones, cambios y eliminaciones de RVC.

7.8.3.2.3.2 Situación 2: Pedido de cambios en una solicitud requerido después del rechazo de un RVC propuesto

Si un solicitante propone un RVC en su presentación inicial y no supera con éxito la Evaluación de compromisos de los operadores de registro, el solicitante deberá presentar un Pedido de cambios en una solicitud para modificar o eliminar el RVC propuesto para que la solicitud pueda avanzar. La ICANN revisará el Pedido de cambios en una solicitud según los criterios publicados (Consultar la Sección 3.8).

Salvo circunstancias extraordinarias, si el solicitante no presenta un Pedido de cambios en una solicitud en un plazo de 30 días a partir de la notificación de que el RVC propuesto no ha superado con éxito la evaluación, no se permitirá que la solicitud continúe.

7.8.3.2.4 Plazos de la Evaluación de compromisos de los operadores de registro y notificación del resultado

Con respecto a los plazos de la Evaluación de compromisos de los operadores de registro para RVC propuestos en la Situación 1: Compromisos adquiridos para resolver las objeciones o Asesoramiento consensuado del GAC (consultar la Sección 7.8.3.2.3.1) y Políticas de registración para la comunidad propuestas (consultar la Sección 7.8.4) presentados por los Solicitantes de una comunidad que participan en la Evaluación con prioridad de la comunidad (CPE), la Evaluación de compromisos de los operadores de registro se llevará a cabo tan pronto como sea posible después de que la ICANN haya recibido el pago de la tarifa correspondiente. La ICANN reconoce la importancia de llevar a cabo la RCE de manera oportuna para garantizar que los procesos dependientes puedan proceder sin demora.

En todos los demás casos, se prevé que la Evaluación de compromisos de los operadores de registro se lleve a cabo más adelante en el proceso de solicitud, antes de la contratación, después de que la ICANN reciba el pago de la tarifa de evaluación.

Salvo circunstancias extraordinarias, el plazo estimado para la RCE es de 60 a 90 días.

La ICANN publicará y actualizará de forma periódica los resultados de la RCE de todos los RVC y Políticas de registración para la comunidad que se presenten en el sitio web del Programa de Nuevos gTLD y notificará a los solicitantes respectivos sobre los resultados.⁹²

7.8.3.3 Criterios de Evaluación de compromisos de los operadores de registro

La ICANN rechazará cualquier RVC propuesto que no sea compatible con los Estatutos de la ICANN.⁹³ Consultar el criterio 5 de la tabla siguiente para obtener más detalles.

La ICANN evaluará cada RVC propuesto sobre la base de los siguientes criterios, y la aprobación dependerá del cumplimiento de todos ellos. Los solicitantes deben seguir las pautas asociadas y considerar la relevancia de cada criterio al elaborar su RVC.

Cada compromiso en la Política de registración para la comunidad (consultar la Sección 7.8.4) que se propone para su inclusión en el Acuerdo de Registro correspondiente también debe cumplir con todos los criterios de Evaluación de compromisos de los operadores de registro para ser aprobado.

Consultar las instrucciones para las Preguntas 150-155 en el Conjunto de preguntas 7 gTLD de la comunidad y el Conjunto de preguntas 11 Compromisos voluntarios de los operadores de registro (RVC) en el Apéndice 1 Preguntas incluidas en la solicitud para conocer los requisitos detallados que guían el enfoque de redacción de las Políticas de registración para la comunidad propuestas y los Compromisos voluntarios de los operadores de registro que serán evaluados a través de la RCE.

Como se señaló en la Sección 7.8.3.1 Factores a considerar antes de proponer un RVC, los solicitantes pueden considerar incluir ciertos compromisos fuera del Acuerdo de Registro, en instrumentos tales como las propias políticas de registro del solicitante, términos de uso, o a través de un acuerdo aparte entre el solicitante y un tercero. Cualquier compromiso de ese tipo que no se proponga para su inclusión en el Acuerdo de Registro no estará sujeto a la Evaluación de compromisos de los operadores de registro.⁹⁴

Tabla 7-3: Criterios de evaluación de RVC

Criterio	Descripción	Orientación
El RVC debe declarar con claridad qué compromisos “deben” implementarse.	Un RVC propuesto debe ser una obligación o un compromiso obligatorio y debe declarar con claridad qué compromisos el operador de registro “debe” implementar, no qué compromisos el operador de registro “puede” o “podría” implementar.	Utilizar lenguaje definitivo: Evitar calificadores y expresar certeza al describir el RVC propuesto. Declarar lo que el solicitante propone que el operador de registro “debe” hacer.
El RVC debe ser claro, detallado, mutuamente entendido entre el solicitante y la ICANN, objetivo y medible.	Cada RVC debe declarar con claridad lo que el RVC requiere que el operador de registro haga. Este nivel de detalle en el RVC es necesario para garantizar que se pueda exigir el cumplimiento del RVC en la práctica. El RVC debe ser claro, de modo que, en caso de un problema de cumplimiento contractual, las acciones del operador de registro puedan medirse en función del texto objetivo en el RVC para determinar si el operador de registro cumplió o no con el RVC.	Ser claro: Utilizar un lenguaje simple y directo que sea fácil de entender. Ser preciso y específico: Evitar declaraciones vagas o ambiguas que puedan generar malentendidos. Ser detallado: Especificar qué entidad será responsable de implementar el RVC; describir las acciones, pasos o tareas requeridas para implementar el RVC; describir las acciones específicas que el operador de registro debe adoptar para cumplir con el RVC. Considerar la supervisión de cumplimiento interno del operador de registro: Describir cómo el operador de registro supervisará y evaluará su implementación y cumplimiento del RVC.
El RVC debe especificar cualquier limitación aplicable.	El solicitante debe proporcionar detalles sobre si un RVC propuesto está limitado en el tiempo, la duración, el alcance o cualquier otro factor, y de ser así, cómo y por qué.	Definir toda limitación aplicable del RVC propuesto: Por ejemplo, si un RVC está limitado en tiempo, debe declarar si se aplicará durante la vida útil del gTLD, solo durante un período de lanzamiento especificado o durante algún otro período definido.

Criterio	Descripción	Orientación
El RVC no debería⁹⁵ duplicar o ser contrario a requisitos en virtud de la ley aplicable, acuerdos de la ICANN o políticas de consenso o políticas temporarias de la ICANN	Un RVC no debería duplicar obligaciones que se aplicarían al operador de registro según el Acuerdo de Registro, las Políticas de consenso y Políticas temporarias aplicables de la ICANN, o la legislación aplicable. No se aprobará un RVC si es contrario a los acuerdos y políticas aplicables de la ICANN. El operador de registro debe poder cumplir con el RVC mientras también cumple con los acuerdos y políticas aplicables de la ICANN. Un RVC tampoco debe impedir el cumplimiento de otras partes (por ejemplo, registradores) con los acuerdos y políticas aplicables de la ICANN.⁹⁶ Si el desempeño de un RVC propuesto requiere la operación de un Servicio de registro adicional, dicho Servicio de registro debe ser evaluado a través del Programa de RSP y aprobado por la ICANN antes de que la ICANN considere aprobar el compromiso propuesto como un RVC.	Evitar la duplicación: Antes de proponer un RVC, un solicitante debe revisar cuidadosamente las disposiciones en el Acuerdo de Registro, el Acuerdo de Acreditación de Registradores, así como las Políticas de consenso y las Políticas temporarias de la ICANN para ver si ya existe dicha obligación. Si es así, el solicitante no debe proponer el RVC. Mejoras a las obligaciones de contratos o políticas: Un RVC podría mejorar, complementar o ampliar los requisitos en el Acuerdo de Registro y otras obligaciones aplicables siempre y cuando el RVC no sea contrario a esas obligaciones aplicables. El RVC debe aplicarse junto con otros requisitos de contratos y políticas: Un RVC no puede comprometer a un operador de registro a adoptar acciones que contradigan requisitos en el Acuerdo de Registro o Políticas de consenso o Políticas temporarias aplicables de la ICANN. Un RVC no debe comprometer a un operador de registro a incluir términos en sus Acuerdos entre registro y registrador que requerirían que los registradores adopten acciones que puedan infringir el Acuerdo de Acreditación de Registradores, Políticas de consenso o Políticas temporarias aplicables de la ICANN, o la legislación aplicable.
El RVC debe ser compatible con los Estatutos de la ICANN.	La ICANN no puede aprobar un RVC que sea incompatible con los Estatutos de la ICANN.	Un aspecto que se tiene especialmente en cuenta en este criterio es si el RVC propuesto restringiría el contenido o el uso de una cadena de caracteres de gTLD solicitada.⁹⁷ Si un RVC propuesto situara a la ICANN en una posición en la que tuviera que exigir a un operador de registro el cumplimiento de una restricción sobre el contenido en el gTLD aplicable, dicho RVC propuesto será rechazado.⁹⁸ “Contenido” es la sustancia de un mensaje que se entrega, mientras que los factores no restrictivos de contenido podrían incluir, entre otros, cómo y cuándo se entrega el contenido y quién lo entrega. Diferenciar entre compromisos restrictivos de contenido y compromisos no restrictivos de contenido en el contexto de un RVC implica entender el alcance, enfoque e impacto de los compromisos: Alcance: Los compromisos no restrictivos de contenido podrían enfocarse en aspectos operativos, de procedimiento y técnicos del registro y gestión de nombres de dominio, en lugar de contenido específico dentro del gTLD. Enfoque: Los compromisos no restrictivos de contenido podrían involucrar el cumplimiento de estándares de la industria, requisitos de elegibilidad de registraciones y procedimientos que no son específicos al contenido en el gTLD. Impacto: Los compromisos no restrictivos de contenido podrían influir en cómo se gestionan los nombres de dominio y el entorno operacional en el que existen.

Criterio

Descripción

Orientación

El RVC no debería⁹⁵ duplicar o ser contrario a requisitos en virtud de la ley aplicable, acuerdos de la ICANN o políticas de consenso o políticas temporarias de la ICANN

Un RVC no debería duplicar obligaciones que se aplicarían al operador de registro según el Acuerdo de Registro, las Políticas de consenso y Políticas temporarias aplicables de la ICANN, o la legislación aplicable. No se aprobará un RVC si es contrario a los acuerdos y políticas aplicables de la ICANN. El operador de registro debe poder cumplir con el RVC mientras también cumple con los acuerdos y políticas aplicables de la ICANN. Un RVC tampoco debe impedir el cumplimiento de otras partes (por ejemplo, registradores) con los acuerdos y políticas aplicables de la ICANN.⁹⁶ Si el desempeño de un RVC propuesto requiere la operación de un Servicio de registro adicional, dicho Servicio de registro debe ser evaluado a través del Programa de RSP y aprobado por la ICANN antes de que la ICANN considere aprobar el compromiso propuesto como un RVC.

Evitar la duplicación: Antes de proponer un RVC, un solicitante debe revisar cuidadosamente las disposiciones en el Acuerdo de Registro, el Acuerdo de Acreditación de Registradores, así como las Políticas de consenso y las Políticas temporarias de la ICANN para ver si ya existe dicha obligación. Si es así, el solicitante no debe proponer el RVC.
Mejoras a las obligaciones de contratos o políticas: Un RVC podría mejorar, complementar o ampliar los requisitos en el Acuerdo de Registro y otras obligaciones aplicables siempre y cuando el RVC no sea contrario a esas obligaciones aplicables.
El RVC debe aplicarse junto con otros requisitos de contratos y políticas: Un RVC no puede comprometer a un operador de registro a adoptar acciones que contradigan requisitos en el Acuerdo de Registro o Políticas de consenso o Políticas temporarias aplicables de la ICANN. Un RVC no debe comprometer a un operador de registro a incluir términos en sus Acuerdos entre registro y registrador que requerirían que los registradores adopten acciones que puedan infringir el Acuerdo de Acreditación de Registradores, Políticas de consenso o Políticas temporarias aplicables de la ICANN, o la legislación aplicable.

El RVC debe ser compatible con los Estatutos de la ICANN.

La ICANN no puede aprobar un RVC que sea incompatible con los Estatutos de la ICANN.

Un aspecto que se tiene especialmente en cuenta en este criterio es si el RVC propuesto restringiría el contenido o el uso de una cadena de caracteres de gTLD solicitada.⁹⁷ Si un RVC propuesto situara a la ICANN en una posición en la que tuviera que exigir a un operador de registro el cumplimiento de una restricción sobre el contenido en el gTLD aplicable, dicho RVC propuesto será rechazado.⁹⁸

“Contenido” es la sustancia de un mensaje que se entrega, mientras que los factores no restrictivos de contenido podrían incluir, entre otros, cómo y cuándo se entrega el contenido y quién lo entrega. Diferenciar entre compromisos restrictivos de contenido y compromisos no restrictivos de contenido en el contexto de un RVC implica entender el alcance, enfoque e impacto de los compromisos:

Alcance: Los compromisos no restrictivos de contenido podrían enfocarse en aspectos operativos, de procedimiento y técnicos del registro y gestión de nombres de dominio, en lugar de contenido específico dentro del gTLD.

Enfoque: Los compromisos no restrictivos de contenido podrían involucrar el cumplimiento de estándares de la industria, requisitos de elegibilidad de registraciones y procedimientos que no son específicos al contenido en el gTLD.

Impacto: Los compromisos no restrictivos de contenido podrían influir en cómo se gestionan los nombres de dominio y el entorno operacional en el que existen.

7.8.3.4 Adiciones, cambios y eliminaciones de RVC

Si se agrega o modifica un RVC propuesto después de la fecha de presentación de la solicitud y antes de que se ejecute el Acuerdo de Registro correspondiente, estará sujeto al proceso de Pedido de cambios en una solicitud, que incluye un período de comentarios sobre la solicitud para cambios sustanciales, como se establece en la Sección 3.8 Pedidos de cambios en una solicitud. Para ver los diferentes tipos de períodos de comentarios de la solicitud para RVC propuestos, consultar la sección 3.8.3 Tipos de pedidos de cambios en una solicitud y procesos requeridos

Salvo circunstancias extraordinarias, los RVC según la Situación 1: Los compromisos adquiridos para resolver las objeciones o el Asesoramiento consensuado del GAC (consultar la Sección 7.8.3.2.3.1) no podrán, por lo general, modificarse sustancialmente ni eliminarse antes de la formalización del contrato.

Actualmente, la ICANN no cuenta con un proceso para que los operadores de registro soliciten modificaciones a los RVC en los Acuerdos de Registro que se han ejecutado. La ICANN puede proponer un proceso para que la comunidad proporcione sus aportes con respecto a los operadores de registro que solicitan modificaciones a los RVC después de la ejecución del contrato.

7.8.3.5 RVC propuesto para cadenas de caracteres variantes

Si un solicitante requiere cadenas de caracteres variantes asignables de una cadena de caracteres principal solicitada y tiene previsto proponer un RVC con su solicitud o como un Pedido de cambios en una solicitud, el RVC propuesto debe aplicarse tanto a la cadena principal como a las cadenas variantes y someterse a la misma Evaluación de compromisos de los operadores de registro. Este requisito también se aplica a la Política de registración para la comunidad propuesta para las cadenas de caracteres principales y variantes solicitadas de un gTLD de la comunidad, tal y como se explica en la Sección 7.8.4 Políticas de registración para la comunidad.

7.8.4 Políticas de registración para la comunidad

Las Políticas de registración para la comunidad del Acuerdo de Registro (Políticas de registración para la comunidad) son condiciones estipuladas en el Acuerdo de Registro que los operadores de registro de gTLD deben imponer a los registratarios dentro de los gTLD de la comunidad. Al presentar una solicitud para un gTLD de una comunidad (Solicitud de la comunidad), los solicitantes deben proponer Políticas de registración para la comunidad a fin de que sean incluidas en los Acuerdos de Registro aplicables. Como mínimo, estas políticas deben cubrir la elegibilidad de los registratarios y la selección de nombres.

Al igual que con los RVC propuestos para su inclusión en el Acuerdo de Registro, una Política de registración para la comunidad propuesta por un solicitante para su inclusión en el Acuerdo de Registro correspondiente se debe evaluar según los criterios de la RCE (consultar la Sección 7.8.3.3). El resultado de su evaluación influirá en la posibilidad de que una Solicitud de la comunidad pueda seguir adelante. Concretamente, un solicitante debe haber aprobado las Políticas de registración para la comunidad como requisito previo para que su solicitud pueda participar en la Evaluación con prioridad de la comunidad (CPE), una opción únicamente disponible para las Solicitudes de la comunidad con el fin de resolver conflictos.⁹⁹ No obstante, la aprobación es necesaria no solo para que una Solicitud de la comunidad participe en la CPE, sino también para avanzar en el proceso de solicitud después de la RCE. En otras palabras, si no hay Políticas de registración para la comunidad que puedan ser aprobadas por la ICANN para su inclusión en el Acuerdo de Registro, la Solicitud de la comunidad no puede avanzar, independientemente de si está en disputa o si el solicitante opta por participar en la CPE.¹⁰⁰

Una Política de registración para la comunidad que cumpla con los criterios de la RCE (consultar la Sección 7.8.3.3) será incluida en el Acuerdo de Registro correspondiente si la cadena de caracteres solicitada procede a la delegación. Consultar las instrucciones para las Preguntas 150-155 en el Conjunto de preguntas 7 gTLD de la comunidad y el en el Apéndice 1 Preguntas incluidas en la solicitud para ver los requisitos detallados que guían el enfoque de redacción de las Políticas de registración para la comunidad propuestas que serán evaluadas a través de la RCE. Al igual que con los PIC y RVC, una Política de registración para la comunidad aprobada estará sujeta a supervisión de cumplimiento contractual de la ICANN. Las Políticas de registración para la comunidad incluidas en el Acuerdo de Registro están sujetas al Procedimiento para la Resolución de Disputas por Restricciones de Registración (RRDRP) y al Procedimiento de solicitudes de cambio de gTLD de la comunidad.¹⁰¹

Además, los operadores de gTLD de la comunidad pueden implementar cualquier política de registración adicional fuera del Acuerdo de Registro que se desee, siempre y cuando las políticas no sean contrarias a requisitos en los acuerdos y políticas aplicables de la ICANN.¹⁰²

7.8.5 Exigibilidad por parte de la ICANN

La ICANN exigirá el cumplimiento de los PIC, los RVC y las Políticas de registración para la comunidad evaluados y aprobados según los criterios de la RCE (consultar la Sección 7.8.3.3) e incluidos en el Acuerdo de Registro como cualquier otra obligación contractual. El PICDRP puede utilizarse para abordar presuntas denuncias que señalen que un operador de registro puede no estar cumpliendo con uno o más de sus PIC o RVC. El RRDRP puede utilizarse para abordar circunstancias en las que el operador de un gTLD de la comunidad presuntamente se desvía de las Políticas de registración para la comunidad descritas en el Acuerdo de Registro. Consultar la Sección 1.2.17 Procedimientos de resolución de disputas después de la delegación para obtener más detalles sobre el PICDRP y el RRDRP.

7.9 Revisión del proveedor de servicios de registro

La ICANN verificará si el solicitante ha seleccionado uno o más RSP evaluados como parte de su solicitud. De no ser así, el solicitante podrá realizar una Evaluación extendida para proporcionar la información solicitada sobre los RSP elegidos. La ICANN también revisará la voluntad de los RSP para dar soporte al gTLD, incluida su capacidad para dar soporte al gTLD con cualquier servicio de registro adicional. Consultar la Sección 3.1.10 Selección del proveedor de servicios de registro.

7.10 Evaluación de la similitud entre cadenas de caracteres

El objetivo de la Evaluación de la similitud entre cadenas de caracteres es evitar la confusión por parte del usuario y la pérdida de confianza en el DNS que resulta de la delegación de cadenas de caracteres similares. Las cadenas de caracteres o sus cadenas variantes no deben ser visualmente similares (definición a continuación) a un dominio de nivel superior existente o sus cadenas de caracteres variantes, o a un Nombre bloqueado o sus cadenas de caracteres variantes según se establece con mayor detalle en la Sección 7.10.1 Alcance de la evaluación de la similitud entre cadenas de caracteres (consultar la Sección 7.2.1 Nombres bloqueados). Las cadenas de caracteres variantes se calculan utilizando la versión aplicable de las Reglas para la Generación de Etiquetas para la Zona Raíz (consultar la Sección 3.1.8.3.1.1 Versión aplicable de las RZ-LGR y códigos de escritura e idiomas compatibles). ¹⁰³

Una solicitud se basa en la cadena de caracteres principal solicitada o gTLD existente. Cada cadena de caracteres principal pertenece a un conjunto de cadenas de caracteres y variantes y lo crea.¹⁰⁴ Una solicitud puede contener una o más cadenas de caracteres del mismo conjunto de cadenas de caracteres y variantes (consultar la Sección 3.1.9 Nombres de dominio internacionalizados), en función de la elección del solicitante y con otras restricciones aplicables.¹⁰⁵ Para cualquier solicitud, la Evaluación de la similitud entre cadenas de caracteres se lleva a cabo utilizando todas las cadenas de caracteres en el conjunto de cadenas de caracteres y variantes incluso si muchas de éstas no son solicitadas por el solicitante, según los detalles a continuación.

El término “visualmente similar” en este contexto se refiere a las cadenas de caracteres visualmente confusas, específicamente “cadenas de caracteres tan visualmente similares que es probable que den lugar a que el usuario se confunda si se delega más de una de las cadenas de caracteres a la zona raíz”.¹⁰⁶ La Evaluación de la similitud entre cadenas de caracteres estará a cargo de un Panel de evaluación de la similitud entre cadenas de caracteres independiente. Si el panel considera que las cadenas de caracteres solicitadas o cadenas de caracteres variantes son visualmente similares, serán marcadas y excluidas del procedimiento o formarán conjuntos de solicitudes controvertidas. La Evaluación de la similitud entre cadenas de caracteres que ocurre durante la Evaluación de cadenas de caracteres complementa el proceso de objeción por confusión de cadenas de caracteres. Consultar la Sección 4.5 Objeciones y apelaciones.

7.10.1 Alcance de la Evaluación de la similitud entre cadenas de caracteres

La evaluación de la similitud entre cadenas de caracteres implica una comparación preliminar de cada cadena de caracteres solicitada y sus cadenas de caracteres variantes con las cadenas de caracteres correspondientes y cadenas de caracteres variantes en categorías relevantes. La evaluación se lleva a cabo utilizando todas las cadenas de caracteres en el conjunto de cadenas de caracteres y variantes, independientemente de si el solicitante las solicita, según se detalla a continuación. Las comparaciones se realizan para determinar si las cadenas de caracteres son visualmente similares en la medida en que genera una probabilidad de confusión¹⁰⁷ del usuario siguiendo las Pautas para la Evaluación de la similitud entre cadenas de caracteres (consultar la Sección 7.10.2.3).

Para cada solicitud, la cadena de caracteres principal (si aún no está delegada) y todas las cadenas de caracteres variantes asignables¹⁰⁸ en su conjunto de cadenas de caracteres y variantes se compararán con lo siguiente:¹⁰⁹

gTLD delegados existentes y todas sus cadenas de caracteres variantes asignables y bloqueadas.
Las cadenas de caracteres de gTLD que fueron solicitadas en las rondas de gTLD anteriores y que aún están en proceso,¹¹⁰ y todas sus cadenas de caracteres variantes asignables y bloqueadas.
ccTLD existentes que superaron con éxito la evaluación¹¹¹ o delegados¹¹² y todas sus cadenas de caracteres variantes asignables y bloqueadas.
Cadenas de caracteres actualmente solicitadas como IDN ccTLD¹¹³ (consultar la Sección 7.10.3.3 Cadenas de caracteres similares a ccTLD evaluados o delegados con éxito o sus cadenas de caracteres variantes) y todas sus cadenas de caracteres variantes asignables y bloqueadas.
Otras cadenas de caracteres de gTLD solicitadas en la ronda de solicitudes actual y todas sus cadenas de caracteres variantes asignables y bloqueadas.
Un subconjunto de Nombres bloqueados¹¹⁴ y todas sus cadenas de caracteres variantes asignables y bloqueadas.
Todas las demás cadenas de caracteres ASCII¹¹⁵ de dos letras y todas sus cadenas de caracteres variantes asignables y bloqueadas.

Además, para cada solicitud, todas sus cadenas de caracteres variantes bloqueadas en su conjunto de cadenas de caracteres y variantes se compararán con lo siguiente:

gTLD delegados existentes y todas sus cadenas de caracteres variantes asignables.
Las cadenas de caracteres que fueron solicitadas en rondas anteriores del Programa de Nuevos gTLD y que aún están en proceso,¹¹⁶ y todas sus cadenas de caracteres variantes asignables.
ccTLD existentes que superaron con éxito la evaluación o delegados y todas sus cadenas de caracteres variantes asignables.
Cadenas de caracteres actualmente solicitadas como IDN ccTLD (consultar la Sección 7.10.3.3 Cadenas de caracteres similares a ccTLD evaluados o delegados con éxito o sus cadenas de caracteres variantes) y todas sus cadenas de caracteres variantes asignables.
Otras cadenas de caracteres de solicitadas en la ronda de solicitudes actual y todas sus cadenas de caracteres variantes asignables.
Un subconjunto de Nombres bloqueados¹¹⁷ y todas sus cadenas de caracteres variantes asignables.
Todas las demás cadenas de caracteres ASCII de dos letras y todas sus cadenas de caracteres variantes asignables.

Como excepción a las comparaciones que se indican anteriormente, durante la Evaluación de la similitud entre cadenas de caracteres, el Panel de evaluación de la similitud entre cadenas de caracteres puede decidir omitir algunas comparaciones con las cadenas de caracteres variantes bloqueadas. Cualquier decisión de ese tipo debe basarse en las Pautas para la Evaluación de la similitud entre cadenas de caracteres que justifiquen dicha omisión citando un bajo nivel de capacidad de confusión entre los códigos de escritura que se comparan.

La tabla a continuación resume las comparaciones que el Panel de evaluación de la similitud entre cadenas de caracteres realizará, según las categorías marcadas con “Sí”. Como se señaló anteriormente, el Panel de evaluación de la similitud entre cadenas de caracteres puede omitir comparaciones para celdas sombreadas en gris marcadas con “Sí*” si concluye que es improbable que los códigos de escritura se confundan, siguiendo las Pautas para la Evaluación de similitud entre cadenas de caracteres (sección 7.10.2.3). Las comparaciones marcadas con “No” no se llevarán a cabo.

Tabla 7-4: Alcance de las comparaciones realizadas por el Panel de evaluación de la similitud entre cadenas de caracteres

Categorías para la comparación		La cadena de caracteres solicitada
Categorías para la comparación		Cadena de caracteres principal	Todas las cadenas de caracteres variantes asignables	Todas las cadenas de caracteres variantes bloqueadas
gTLD existente Cadena de caracteres solicitada de ronda(s) anterior(es) del Programa de Nuevos gTLD aún en proceso ccTLD existente IDN ccTLD solicitado Otra cadena de caracteres solicitada Nombre bloqueado Cualquier ASCII de dos caracteres	Cadena de caracteres principal	Sí	Sí	Sí*
	Todas las cadenas de caracteres variantes asignables	Sí	Sí	Sí*
	Todas las cadenas de caracteres variantes bloqueadas	Sí*	Sí*	No

*El Panel de evaluación de la similitud entre cadenas de caracteres puede omitir comparaciones para celdas sombreadas en gris marcadas con “Sí*” si concluye que es improbable que los códigos de escritura se confundan, siguiendo las Pautas para la Evaluación de la similitud entre cadenas de caracteres.

7.10.2 Metodología de Evaluación de la similitud entre cadenas de caracteres

7.10.2.1 Cadenas de caracteres principales o variantes iguales

Se consideran tanto las formas en mayúsculas como en minúsculas de letras ASCII, y cualquier combinación de mayúsculas y minúsculas en una cadena de caracteres puede utilizarse para la Evaluación de la similitud entre cadenas de caracteres, como: "EJEMPLO", "Ejemplo" o "ejemplo."

Las solicitudes de diferentes solicitantes con cadenas de caracteres del mismo conjunto de cadenas de caracteres y variantes serán marcadas como iguales por el Panel de evaluación de la similitud entre cadenas de caracteres.

7.10.2.2 Procesamiento en lotes de cadenas de caracteres

Si se requiere el procesamiento en lotes, la Evaluación de la similitud entre cadenas de caracteres se completará en todas las cadenas de caracteres solicitadas antes del establecimiento de lotes de prioridad para la evaluación. Para aquellas solicitudes identificadas como parte de un conjunto de solicitudes controvertidas, la ICANN pondrá todas las cadenas de caracteres de dicho conjunto en el mismo lote según la cadena de caracteres de mayor prioridad en ese conjunto de solicitudes controvertidas.

7.10.2.3 Pautas para la Evaluación de la similitud entre cadenas de caracteres

El Panel de evaluación de la similitud entre cadenas de caracteres llevará a cabo la evaluación según las Pautas para la Evaluación de la similitud entre cadenas de caracteres, que serán publicadas en el sitio web del Programa de Nuevos gTLD.

7.10.2.4 Proceso para el Panel de evaluación de la similitud entre cadenas de caracteres

La Evaluación de la similitud entre cadenas de caracteres estará a cargo de un Panel de evaluación de la similitud entre cadenas de caracteres independiente. Todas las cadenas de caracteres solicitadas y sus variantes se evaluarán en función de otras cadenas de caracteres solicitadas y sus variantes, gTLD existentes y Nombres bloqueados, según se detalla en la Sección 7.10.1 Alcance de la Evaluación de la similitud entre cadenas de caracteres.

El Panel de evaluación de la similitud entre cadenas de caracteres llevará a cabo la Evaluación de la similitud entre cadenas de caracteres en los siguientes pasos:

Compilar las listas de cadenas de caracteres para la comparación:
1. gTLD existentes
2. Cadenas de caracteres solicitadas en rondas anteriores del Programa de Nuevos gTLD y aún en proceso
3. ccTLD existentes
4. IDN ccTLD solicitados
5. Otras cadenas de caracteres solicitadas
6. Nombres bloqueados
7. Cadenas de dos caracteres en código ASCII
Considerar todas las cadenas de caracteres variantes asignables de las cadenas de caracteres anteriores utilizando las RZ-LGR.
Considerar todas las cadenas de caracteres variantes bloqueadas de las cadenas de caracteres anteriores utilizando las RZ-LGR que están en el mismo código de escritura (cadenas de caracteres de códigos de escritura mixtos para los códigos de escritura kana y han según lo permitido por las RZ-LGR).
Decidir qué cadenas de caracteres variantes bloqueadas se deben omitir de la evaluación, de corresponder, y documentar el fundamento para la decisión. Cualquier decisión de ese tipo que tome el panel debe basarse en las Pautas para la Evaluación de la similitud entre cadenas de caracteres (consultar la Sección 7.10.2.3) sobre la base de un bajo nivel de capacidad de confusión entre los códigos de escritura de las cadenas de caracteres que se comparan.
Identificar cadenas de caracteres en diferentes solicitudes pero en el mismo conjunto de cadenas de caracteres y variantes para determinar conjuntos de solicitudes controvertidas provocados por las mismas cadenas de caracteres o cadenas de caracteres variantes.
Llevar a cabo la comparación de las cadenas de caracteres para identificar cualquier conjunto de cadenas de caracteres visualmente similares según las Pautas para la Evaluación de la similitud entre cadenas de caracteres (consultar la Sección 7.10.2.3), y documentar el análisis. Las herramientas de similitud visual no se utilizan como aporte para este proceso, pero el Panel de evaluación de la similitud entre cadenas de caracteres puede utilizar la automatización y datos proporcionados por la comunidad de códigos de escritura respectiva para lograr que el proceso de comparación manual sea eficiente.
Determinar y documentar (junto con el fundamento) el resultado de la Evaluación de la similitud entre cadenas de caracteres.

7.10.3 Resultados de la Evaluación de la similitud entre cadenas de caracteres

Como se señaló anteriormente, el Panel de evaluación de la similitud entre cadenas de caracteres llevará a cabo el análisis y determinará los resultados de la Evaluación de la similitud entre cadenas de caracteres. Estos resultados, junto con su fundamento, se basarán en comparaciones de similitud que se llevan a cabo para todas las cadenas de caracteres de gTLD solicitadas (incluido su conjunto de cadenas de caracteres variantes), según los detalles en esta sección. Los resultados posibles son los siguientes:

Cadena de caracteres visualmente similar a un gTLD existente o a sus cadenas de caracteres variantes.
Cadena de caracteres visualmente similar a una cadena solicitada en rondas anteriores del Programa de Nuevos gTLD y aún en proceso, o sus cadenas de caracteres variantes.
Cadena de caracteres visualmente similar a un ccTLD existente o a sus cadenas de caracteres variantes.
Cadena de caracteres visualmente similar a un IDN ccTLD solicitado o sus cadenas de caracteres variantes.
Cadena de caracteres igual a otra cadena de caracteres solicitada o sus cadenas de caracteres variantes.
Cadena de caracteres visualmente similar a otra cadena de caracteres solicitada o sus cadenas de caracteres variantes.
Cadena de caracteres visualmente similar a un nombre bloqueado o sus cadenas de caracteres variantes.
Cadena de caracteres visualmente similar a una cadena de dos caracteres ASCII o sus cadenas de caracteres variantes.
Cadena de caracteres que no es visualmente similar a ninguna de las categorías enumeradas.

La ICANN publicará los resultados de la Evaluación de la similitud entre cadenas de caracteres en la Página de resultados de la evaluación del sitio web del Programa de Nuevos gTLD.

Todas las cadenas de caracteres de un conjunto de cadenas de caracteres y variantes, que comprenden la cadena de caracteres principal y todas sus cadenas de caracteres variantes asignables y bloqueadas, compartirán el mismo resultado de la Evaluación de la similitud entre cadenas de caracteres:

Si alguna cadena de caracteres solicitada o cualquiera de sus cadenas de caracteres variantes no puede continuar o se coloca en un conjunto de solicitudes controvertidas debido a una Similitud visual, entonces la cadena de caracteres solicitada y todas sus cadenas de caracteres variantes (es decir, el conjunto completo de cadenas de caracteres variantes) compartirán el mismo resultado.
Cuando una solicitud en un conjunto de solicitudes controvertidas prevalece, esto se aplica al conjunto completo de cadenas de caracteres variantes, y todas las cadenas de caracteres en la solicitud que prevalece pueden continuar a la siguiente etapa del proceso de solicitud. Consultar la Sección 5.2.2 Resolución de controversias por cadenas de caracteres.

7.10.3.1 Cadenas de caracteres visualmente similares a gTLD existentes o sus cadenas de caracteres variantes

Si se establece que alguna cadena de caracteres solicitada o cualquiera de sus cadenas de caracteres variantes es visualmente similar a alguno de los gTLD existentes o cualquiera de sus cadenas de caracteres variantes, la solicitud no podrá continuar, excepto en el caso que se indica a continuación.

La excepción ocurre cuando la cadena de caracteres solicitada es una variante asignable de un gTLD existente, forma parte del mismo conjunto de cadenas de caracteres y variantes que el gTLD existente, se considera que la cadena de caracteres solicitada es visualmente similar a ese gTLD existente o a cualquiera de sus cadenas de caracteres variantes, y el solicitante es el mismo operador de registro de ese gTLD existente. En este caso, la solicitud puede continuar con la evaluación como una cadena de caracteres variante.

7.10.3.2 Cadenas de caracteres visualmente similares a cadenas de caracteres y sus variantes de rondas anteriores del Programa de Nuevos gTLD que aún están en proceso

Si una cadena de caracteres principal solicitada o cualquiera de sus cadenas de caracteres variantes es visualmente similar a una cadena de caracteres principal solicitada o cualquiera de sus cadenas de caracteres variantes que se hayan retrasado de una ronda de solicitudes anterior y aún están en curso, la solicitud recién presentada se pondrá en espera hasta que se haya determinado el resultado de la solicitud de la ronda anterior.

Si la solicitud de una ronda anterior del Programa de Nuevos gTLD completa exitosamente la evaluación y es elegible para la celebración de un Acuerdo de Registro Base, el conjunto completo de cadenas de caracteres y variantes de la cadena de caracteres principal recién solicitada no es elegible para continuar en el proceso de solicitud.
Si la solicitud de la ronda anterior se retira o no supera con éxito la evaluación, la solicitud recién presentada es elegible para continuar a la siguiente etapa del proceso de solicitud.

Un nuevo solicitante no tiene permitido solicitar una cadena de caracteres que sea parte del mismo conjunto de cadenas de caracteres y variantes que la cadena de caracteres de la ronda anterior del Programa de Nuevos gTLD que aún está en proceso.

7.10.3.3 Cadenas de caracteres visualmente similares a ccTLD evaluados o delegados con éxito o sus cadenas de caracteres variantes

Si se establece que alguna cadena de caracteres solicitada o cualquiera de sus cadenas de caracteres variantes es visualmente similar a alguno de los ccTLD que superaron con éxito la evaluación o que fueron delegados o cualquiera de sus cadenas de caracteres variantes, la solicitud de gTLD no continuará.

7.10.3.4 Cadenas de caracteres visualmente similares a un IDN ccTLD solicitado

Una cadena de caracteres de IDN ccTLD puede ser solicitada a través del Proceso de Avance Acelerado de Dominios de Alto Nivel con Código de País dentro de Nombres de Dominio Internacionalizados (IDN ccTLD) o su sucesor de forma continua.¹¹⁸ El proceso de solicitud de cadenas de caracteres de IDN ccTLD es independiente y distinto del proceso de solicitud de gTLD. Si se establece que una cadena de caracteres de gTLD solicitada es visualmente similar a algún IDN ccTLD solicitado,¹¹⁹ el Panel de evaluación de la similitud entre cadenas de caracteres reportará este caso como un conflicto con un IDN ccTLD solicitado, sin formar un conjunto de solicitudes controvertidas, dado que dichos conjuntos corresponden únicamente para cadenas de caracteres de gTLD solicitadas. La ICANN adoptará el enfoque que se indica a continuación para resolver el conflicto.

Si se establece que una cadena de caracteres de gTLD solicitada es visualmente similar a un IDN ccTLD solicitado, la ICANN determinará el resultado sobre la base del estado de finalización de sus respectivos procesos de evaluación. Los escenarios son los siguientes:

Una solicitud de gTLD que haya completado con éxito todas las etapas de evaluación pertinentes, incluida la resolución de disputas y la controversia por cadenas de caracteres, según corresponda, y que sea elegible para la celebración de un Acuerdo de Registro Base, se considerará completa y, por lo tanto, dicha solicitud de gTLD (cadena de caracteres principal y cadenas variantes solicitadas, según corresponda) no quedará descalificada por una nueva solicitud de IDN ccTLD. Se informará al solicitante del IDN ccTLD en consecuencia.
Una cadena de caracteres principal de IDN ccTLD solicitada que sea validada¹²⁰ será considerada completa. Por lo tanto, esa cadena de caracteres de IDN ccTLD (cadena de caracteres principal de IDN ccTLD y cadenas de caracteres variantes solicitadas, según corresponda) no sería descalificada por una solicitud de gTLD recién presentada.

Cuando ninguna solicitud haya completado su respectivo proceso de evaluación, la solicitud de gTLD (incluidas las cadenas de caracteres variantes solicitadas, según corresponda) será puesta en espera mientras la solicitud de IDN ccTLD (incluidas las cadenas de caracteres variantes solicitadas, según corresponda) se somete a evaluación. La espera podría ser por un período de tiempo indeterminado, siempre que el solicitante de IDN ccTLD proporcione la documentación y la información suficiente para completar el proceso de evaluación, que se rige exclusivamente por el proceso de evaluación de solicitudes de IDN ccTLD. Se informará al solicitante de gTLD en consecuencia sobre uno de dos resultados:

Una vez completada exitosamente su evaluación, la solicitud de un IDN ccTLD prevalecerá y la solicitud de gTLD no será aprobada.
Si el IDN ccTLD solicitado no supera con éxito la evaluación, o es retirado por el solicitante del IDN ccTLD, entonces la cadena de caracteres de gTLD IDN puede continuar con la evaluación de la solicitud.

Si el solicitante de gTLD recibió respaldo relevante del gobierno o autoridad pública o no objeción, pero su solicitud finalmente se elimina debido a la similitud visual con una cadena de caracteres solicitada en el proceso de solicitud de IDN ccTLD, se emitirá un reembolso completo de la tarifa de evaluación si la solicitud de gTLD se presentó antes de la publicación del ccTLD.

Un solicitante no tiene permitido presentar una solicitud para una cadena de caracteres de gTLD que sea parte del mismo conjunto de cadenas de caracteres y variantes que una cadena de caracteres de ccTLD solicitada que esté validada.

7.10.3.5 Cadenas de caracteres idénticas o visualmente similares a cadenas de caracteres solicitadas y sus variantes

Si se establece que alguna cadena de caracteres principal solicitada y cualquiera de sus cadenas de caracteres variantes son visualmente similares entre sí, y estas cadenas de caracteres son solicitadas en la misma solicitud, no serán puestas en controversia entre sí y pueden proceder como cadenas de caracteres principales y variantes entre sí.

Si se establece que alguna cadena de caracteres solicitada o cualquiera de sus cadenas de caracteres variantes son idénticas o visualmente similares a cualquier otra cadena de caracteres solicitada o cualquiera de sus cadenas de caracteres variantes, el Panel de evaluación de la similitud entre cadenas de caracteres colocará los conjuntos de cadenas de caracteres y variantes para estas solicitudes¹²¹ en un conjunto de solicitudes controvertidas. Un conjunto de solicitudes controvertidas contiene al menos dos cadenas de caracteres solicitadas que son idénticas o visualmente similares entre sí o sus variantes. Consultar el Módulo 5 Resolución de conjuntos de solicitudes controvertidas para obtener más información sobre conjuntos de solicitudes controvertidas y resolución de controversias.

Estos conjuntos de solicitudes controvertidas también incluirán información sobre controversias directas (la cadena de caracteres A se confunde con la cadena de caracteres B) o controversias indirectas a través de transitividad de similitud visual de cadenas de caracteres (la cadena de caracteres A se confunde con la cadena de caracteres B y la cadena de caracteres B se confunde con la cadena de caracteres C pero la cadena de caracteres A y la cadena de caracteres C no se confunden) o transitividad de similitud visual de cadenas variantes (por ejemplo, la cadena de caracteres A se confunde con la cadena de caracteres B-variante-1 y la cadena de caracteres B-variante-2 se confunde con la cadena de caracteres C pero la cadena de caracteres A y la cadena de caracteres C no se confunden). La controversia indirecta puede resolverse para permitir que tanto la cadena de caracteres A como la cadena de caracteres C continúen en caso de que la cadena de caracteres B no pueda continuar, pero si la cadena de caracteres B continúa, ni la cadena de caracteres A ni la cadena de caracteres C pueden continuar.

7.10.3.6 Cadenas de caracteres visualmente similares a un nombre bloqueado

Si se establece que cualquier cadena de caracteres solicitada o cualquiera de sus cadenas de caracteres variantes es visualmente similar a cualquier Nombre bloqueado¹²² o cualquiera de sus cadenas de caracteres variantes, la solicitud no continuará.

7.10.3.7 Similitud visual de cadenas de caracteres con una cadena de caracteres ASCII de dos caracteres

Si se establece que alguna cadena de dos caracteres solicitada o cualquiera de sus cadenas de caracteres variantes es similar a cualquier cadena de dos caracteres ASCII o cualquiera de sus cadenas de caracteres variantes, la solicitud no continuará.

7.10.3.8 Resultados de la Evaluación de la similitud entre cadenas de caracteres

Los resultados mencionados anteriormente se resumen en la tabla siguiente. Si se considera que la cadena de caracteres no es visualmente similar a ninguna de las cadenas de caracteres de ninguna de las categorías, puede continuar a la siguiente etapa en el proceso de evaluación de la solicitud.

Tabla 7-5: Resultados para la solicitud de gTLD en virtud de la Evaluación de la similitud entre cadenas de caracteres realizada por el panel

	Si se establece que la cadena de caracteres solicitada o cualquier miembro de su conjunto de cadenas de caracteres y variantes es:
	Igual que	Variante de	Visualmente similar a (pero no una variante de)
gTLD existente	No se aceptará la solicitud.	La solicitud puede continuar si el operador de registro existente es también el solicitante.	La solicitud no puede continuar.
Cadena de caracteres solicitada de ronda(s) anterior(es) del Programa de Nuevos gTLD aún en proceso¹²³	No se aceptará la solicitud.	No se aceptará la solicitud.	La solicitud se pone en espera hasta que la cadena de caracteres anterior complete la evaluación. La solicitud puede continuar con la evaluación si la cadena de caracteres de gTLD de la ronda anterior es retirada o no supera con éxito la evaluación.
ccTLD existente	No se aceptará la solicitud.	No se aceptará la solicitud.	La solicitud no puede continuar.
IDN ccTLD solicitado	La solicitud no se aceptará si la cadena de caracteres de IDN ccTLD ha sido validada. La solicitud se pone en espera mientras se evalúa la cadena de caracteres de ccTLD.	La solicitud no se aceptará si la cadena de caracteres de IDN ccTLD ha sido validada. La solicitud se pone en espera mientras se evalúa la cadena de caracteres de ccTLD.	La solicitud puede continuar si ha completado con éxito todas las etapas de evaluación pertinentes, y es elegible para la celebración de un Acuerdo de Registro Base al momento de presentación de la solicitud de IDN ccTLD. De lo contrario, la solicitud se pone en espera hasta que la evaluación de ccTLD se complete y la solicitud puede continuar si el IDN ccTLD solicitado es retirado o no supera con éxito la evaluación.
Otra cadena de caracteres de gTLD solicitada	La solicitud se incluye en el conjunto de solicitudes controvertidas.	La solicitud no se incluye en el conjunto de solicitudes controvertidas si la otra cadena de caracteres solicitada es una cadena de caracteres variante del mismo solicitante. La solicitud se incluye en el conjunto de solicitudes controvertidas si la otra cadena de caracteres solicitada es de un solicitante diferente.	La solicitud se incluye en el conjunto de solicitudes controvertidas.
Nombre bloqueado	No se aceptará la solicitud.	No se aceptará la solicitud.	La solicitud no puede continuar.
Cadena de dos caracteres en código ASCII	No se aceptará la solicitud.	No se aceptará la solicitud.	La solicitud no puede continuar.

7.10.4 Impugnación de la Evaluación de la similitud entre cadenas de caracteres

Se puede impugnar la Evaluación de la similitud entre cadenas de caracteres. Si un solicitante cree que el Panel de evaluación de la similitud entre cadenas de caracteres cometió un error de hecho o de procedimiento, por ejemplo, cuando estableció que la cadena de caracteres solicitada del solicitante (o una cadena de caracteres variante) es visualmente similar y, por lo tanto, no puede continuar o debe ser colocada en un conjunto de solicitudes controvertidas sobre la base de los casos mencionados anteriormente, entonces el solicitante puede interponer una impugnación.

La impugnación de la evaluación se valorará en virtud de un estándar de revisión "de error manifiesto". En concreto, el Proveedor de servicios para la impugnación de evaluaciones debe aceptar la decisión de la evaluación del Panel de evaluación de la similitud entre cadenas de caracteres a menos que: (1) el panel no haya seguido los procedimientos de evaluación establecidos, o (2) no haya considerado o solicitado evidencias o información material necesaria.

La impugnación de la evaluación puede realizarse dentro de un plazo de 21 días desde la fecha en que el solicitante recibe notificación de la decisión de la Evaluación de la similitud entre cadenas de caracteres. El Panel de evaluación de la similitud entre cadenas de caracteres comunicará las conclusiones resultantes de la Impugnación de la evaluación en un plazo de 30 días a partir de la presentación de dicha impugnación por parte del solicitante.

Si el Panel de evaluación de la similitud entre cadenas de caracteres encuentra un error de hecho, de procedimiento o del sistema, entonces se volverá a realizar la Evaluación de la similitud entre cadenas de caracteres para la solicitud, y se tendrán en cuenta los hallazgos de la Impugnación de la evaluación.

Si el Panel de evaluación de la similitud entre cadenas de caracteres no encuentra ningún error de hecho, de procedimiento o del sistema, entonces:

Si la impugnación se funda en una decisión que establece que una cadena de caracteres solicitada es visualmente similar a un gTLD existente, cualquier cadena de caracteres ya solicitada de una ronda anterior del Programa de Nuevos gTLD, cualquier ccTLD existente, un IDN ccTLD solicitado que ha sido validado, cualquier otra cadena de caracteres ASCII de dos caracteres, o cualquier otro Nombre bloqueado, la solicitud no continuará más.
Si la impugnación se funda en una decisión que establece que una cadena de caracteres solicitada es visualmente similar a otra cadena de caracteres solicitada, la solicitud permanece en el conjunto de solicitudes controvertidas pertinente.

7.10.5 Excepción para los TLD que representan a una marca

Si una cadena de caracteres solicitada ha cumplido con los criterios para ser calificada como un TLD que representa a una marca (consultar la Sección 7.1.2.4 Solicitudes para TLD que representan a una marca), y se establece que este TLD que representa a una marca solicitado es similar según los detalles en la Tabla 7-5: Resultados para la solicitud de gTLD en virtud de la Evaluación de la similitud entre cadenas de caracteres realizada por el panel mencionados anteriormente, y por lo tanto no puede continuar o se coloca en un conjunto de solicitudes controvertidas, entonces ese solicitante del TLD que representa a una marca tendrá la oportunidad de cambiar su cadena. Las reglas para el cambio de cadena de caracteres para solicitudes de TLD que representan a una marca pueden consultarse en la Sección 5.3 Solicitud de cambio de cadena de caracteres que representa a una marca.¹²⁴

Consultar la Sección 3.7.1 Sorteo de priorización para obtener información sobre el sorteo, que se llevará a cabo para determinar el número de prioridad de una solicitud y el orden general en el que será procesada por la ICANN.↩︎
También puede haber diferentes requisitos para pedidos de cambios en una solicitud, incluidos los tipos de designaciones de solicitud que pueden o no pueden cambiarse. Consultar la Sección 7.1.3 Cambios de tipos de solicitud a continuación para obtener más información, así como la Sección 3.8 Pedidos de cambios en una solicitud para obtener detalles completos sobre los pedidos de cambios en una solicitud.↩︎
Una vez presentada la solicitud, el solicitante no puede cambiarla a una Solicitud de la comunidad ni viceversa. Consultar la Sección 3.8 Pedidos de cambios en una solicitud.↩︎
No se permitirá un Pedido de cambios en una solicitud para modificar la designación de comunidad de una solicitud. Consultar la Sección 3.8 Pedidos de cambios en una solicitud para obtener información sobre los pedidos de cambios permitidos.↩︎
Se prevé que el solicitante y la ICANN puedan negociar el texto específico de una Política de registración para la comunidad durante la Evaluación de compromisos de los operadores de registro, con el fin de identificar el texto propuesto para el Acuerdo de Registro que cumpla con los criterios de la RCE (consultar la Sección 3.8.4.2 Pedidos de cambios en una solicitud: Flujo de trabajo 2). El solicitante deberá presentar un Pedido de cambios en una solicitud que refleje el texto negociado del Acuerdo de Registro para la Política de registración para la comunidad propuesta tras recibir la notificación de la ICANN. La ICANN no rechaza de forma inmediata ni automática una Política de registración para la comunidad propuesta sin comunicarse previamente con el solicitante. Sin embargo, si un solicitante no presenta el Pedido de cambios en una solicitud requerido dentro del plazo establecido en la Sección 3.8 Pedidos de cambios en una solicitud, el resultado de la RCE sería negativo.↩︎
Consultar las instrucciones pertinentes en el Conjunto de preguntas 7 gTLD de la comunidad en el Apéndice 1 Preguntas incluidas en la solicitud para conocer los requisitos detallados y el enfoque sugerido para redactar las Políticas de registración para la comunidad propuestas, que se evaluarán a través de la RCE.↩︎
Consultar la Sección 7.5 Nombres geográficos para obtener una lista completa de categorías de cadenas de caracteres que cumplirían los requisitos para ser consideradas como nombres geográficos.↩︎
La sección detalla un proceso de excepción, que permite a los solicitantes solicitar un nombre de la lista de Nombres reservados. Este proceso se aplica exclusivamente a la Cruz Roja/Media Luna Roja (RCRC), Comité Olímpico Internacional (IOC), y nombres de organizaciones internacionales gubernamentales (OIG) - organizaciones internacionales no gubernamentales (OING).↩︎
Como referencia, consultar la Especificación 13 9.3(i) del Acuerdo de Registro Base (Apéndice 4) para obtener más información sobre los TLD que representan a una marca y los requisitos.↩︎
En casos de disputa con otros solicitantes, el solicitante de TLD que representa a una marca puede tener la oportunidad de cambiar su cadena de caracteres para agregar un descriptor al nombre de dominio, en cuyo caso el nombre de dominio puede ya no ser una coincidencia exacta con los elementos textuales de una marca comercial registrada. Consultar la Sección 5.3 Solicitud de cambio de una cadena de caracteres que representa a una marca.↩︎
No siempre una cadena de caracteres que coincide con un nombre de marca se gestionará como una cadena de caracteres que representa a una marca. Es posible que un solicitante presente la solicitud para una cadena de caracteres, que coincide con un nombre de marca, sin la intención de operar como un TLD que representa a una marca.↩︎
En algunos casos, el solicitante de un TLD que representa a una marca puede obtener una Exención al código de conducta (Especificación 9), pero no ser elegible para la Especificación 13.↩︎
Consultar también la Sección 3.8 Pedidos de cambios en una solicitud para obtener información sobre los requisitos de elegibilidad y evaluación.↩︎
Como se señaló anteriormente, los solicitantes elegibles también pueden solicitar una Exención al código de conducta del operador de registro. Consultar la Sección 7.4 Evaluación de exención al código de conducta del operador de registro ↩︎
Los solicitantes también tendrán la oportunidad de solicitar variantes de "nuevos" IDN TLD. Consultar la Sección 7.1.2.7 Solicitudes para nuevos IDN TLD que incluyen una o más variantes.↩︎
Consultar la Recomendación 3.5 del Informe Final de la Etapa 1 sobre el Proceso Expeditivo de Desarrollo de Políticas de Nombres de Dominio Internacionalizados: https://gnso.icann.org/sites/default/files/policy/2023/correspondence/epdp-idns2-leadership-team-et-al-to-gnso-council-et-al-08nov23-en.pdf.↩︎
Ibídem Véanse las Recomendaciones 3.11 y 3.12. La cantidad total de variantes que se pueden solicitar se basa en el cálculo de las RZ-LGR.↩︎
Ibídem↩︎
Ibídem Consultar la Recomendación 3.5.↩︎
Consultar el Informe Final de la Etapa 1 sobre el Proceso Expeditivo de Desarrollo de Políticas de Nombres de Dominio Internacionalizados: https://gnso.icann.org/sites/default/files/policy/2023/correspondence/epdp-idns2-leadership-team-et-al-to-gnso-council-et-al-08nov23-en.pdf.↩︎
Una OIG es una organización compuesta principalmente por estados soberanos o por otras organizaciones intergubernamentales. Las OIG se constituyen mediante un tratado u otro acuerdo que actúa como carta orgánica de creación del grupo. Algunos ejemplos son las Naciones Unidas, el Banco Mundial o la Unión Europea. Fuente: Unión de Asociaciones Internacionales, https://uia.org/faq/yb3.↩︎
En general, se define como un gobierno nacional o cualquier departamento, agencia o subdivisión del mismo con la autoridad relevante.↩︎
Consultar el Manual del Programa de Apoyo para Solicitantes:https://newgtldprogram.icann.org/en/application-rounds/round2/asp/handbook.↩︎
Consultar el resultado del PDP sobre Protección de Identificadores de OIG y OING en Todos los gTLD para obtener más información: https://gnso.icann.org/en/group-activities/active/igo-ingo.↩︎
Consultar las Reglas de conversión de etiquetas del DNS en la sección “Notas de implementación” para obtener más información: https://www.icann.org/en/contracted-parties/consensus-policies/protection-of-intergovernmental-organization-and-international-non-governmental-organization-identifiers-policy/protection-of-igo-and-ingo-identifiers-in-all-gtlds-policy-21-02-2024-en.↩︎
Consultar Nombres de dominio de uso especial: https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml.↩︎
Consultar RFC 6761: https://tools.ietf.org/html/rfc6761.↩︎
Nota: La ICANN reservará traducciones de los términos "test" y "example" en múltiples idiomas.↩︎
Consultar Comunidad de la ICANN: https://www.icann.org/community.↩︎
Consultar Registros Regionales de Internet: https://aso.icann.org/about/aso-and-nro/rirs/.↩︎
Consultar Grupos del IETF: https://www.ietf.org/about/groups/.↩︎
Consultar el Informe Final del Grupo de Trabajo de Nombres Reservados: https://gnso.icann.org/en/issues/new-gtlds/final-report-rn-wg-23may07.htm.↩︎
Como resultado del documento SAC113 y del trabajo posterior dirigido por la Junta Directiva de la ICANN, .INTERNAL se agregó a la lista de Nombres bloqueados. Consultar https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-113-en.pdf.↩︎
Consultar Base de datos de la Zona Raíz: https://www.iana.org/domains/root/db.↩︎
Sitio web del Programa de Nuevos gTLD Ronda 2012: https://gtldresult.icann.org/applicationstatus/viewstatus.↩︎
Los solicitantes deben saber que no se aceptará ninguna impugnación presentada después de este período y, por lo tanto, se les recomienda que inicien su solicitud lo antes posible y presenten cualquier impugnación a más tardar 14 días antes del cierre del período para la presentación de solicitudes.↩︎
Tal como se indica en la Sección 7.10.1 Alcance de la Evaluación de la similitud entre cadenas de caracteres, conforme a la moción 20251113 del Consejo de la GNSO, “Los identificadores pertinentes [asociados al Movimiento Internacional de la Cruz Roja y de la Media Luna Roja y al Comité Olímpico Internacional, así como los nombres completos de determinadas organizaciones internacionales gubernamentales y organizaciones internacionales no gubernamentales] no se incluirán en la evaluación de la similitud entre cadenas de caracteres del Programa de Nuevos gTLD, y dichos identificadores pertinentes no constituirán un obstáculo para que otro solicitante presente una solicitud para una cadena de caracteres confusamente similar, durante la evaluación”. Consultar el texto completo de la moción del Consejo de la GNSO: https://gnso.icann.org/en/council/resolutions/2020-current#20251113.↩︎
Consultar el Proceso de Desarrollo de Políticas para la protección de los identificadores de OIG y OING en todos los gTLD para conocer el alcance de los nombres permitentes: https://gnso.icann.org/en/group-activities/active/igo-ingo.↩︎
Consultar la Resolución de la Junta Directiva 2014.04.30.03: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-of-directors-30-04-2014-en#2.a.↩︎
Consultar la Resolución de la Junta Directiva 2019.01.27.19: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-27-01-2019-en#2.d.↩︎
Consultar los nombres de la Cruz Roja: https://www.icann.org/sites/default/files/packages/reserved-names/ReservedNames.xml#red-cross1. Cabe señalar que esta lista, así como las correspondientes a los nombres del IOC y las OIG, se aplica a los nombres de dominio de segundo nivel, pero también se reutilizará para reservar esos mismos nombres en el nivel superior en el contexto del Programa de Nuevos gTLD: Ronda de 2026. Consultar la columna “Nombre” de cada lista vinculada para ver los nombres correspondientes.↩︎
Consultar los nombres del IOC: https://www.icann.org/sites/default/files/packages/reserved-names/ReservedNames.xml#IOC.↩︎
Consultar los nombres de las OIG: https://www.icann.org/sites/default/files/packages/reserved-names/ReservedNames.xml#IGOs.↩︎
Consultar la “Lista de organizaciones no gubernamentales reconocidas como entidades consultivas por el Consejo Económico y Social al 31 de diciembre de 2022”: https://docs.un.org/en/E/2023/INF/5: https://esango.un.org/civilsociety/displayConsultativeStatusSearch.do?method=search.↩︎
Consultar la lista de miembros del GAC: https://gac.icann.org/about/gac-members.↩︎
Los solicitantes elegibles también pueden solicitar una Exención al código de conducta (Especificación 9) así como la Sección 7.4 Evaluación de exención al código de conducta.↩︎
Consultar Centro de Información y Protección de Marcas Comerciales: https://trademark-clearinghouse.com/.↩︎
Consultar Centro de Información y Protección de Marcas Comerciales: https://trademark-clearinghouse.com/.↩︎
Los nombres de países y territorios están excluidos del proceso según el asesoramiento del Comité Asesor Gubernamental en comunicados pasados. Estos comunicados interpretan el Principio 2.2 del GAC relativo a los Nuevos gTLD que establece que las cadenas que constituyen una representación significativa o una abreviatura del nombre de un país o territorio deben manejarse a través de un ccPDP, y otras cadenas geográficas podrían permitirse en el espacio de gTLD si cuentan con el acuerdo del gobierno o autoridad pública pertinente.↩︎
Consultar la lista de la norma ISO 3166-1: https://www.iso.org/obp/ui.↩︎
Las permutaciones incluyen la eliminación de espacios, la inserción de signos de puntuación y la adición o eliminación de artículos gramaticales como "el/la". Una transposición se considera un cambio en la secuencia del nombre largo o abreviado, por ejemplo, "RepublicaCheca" o "IslasCayman".↩︎
Los gobiernos de las ciudades que tengan inquietudes sobre las cadenas que constituyan duplicados, apodos o representaciones similares del nombre de una ciudad no deben ampararse en el proceso de evaluación como medio principal para proteger sus intereses respecto de una cadena. En cambio, las partes interesadas pertinentes pueden optar por presentar una objeción formal a una solicitud a la que se oponga la comunidad pertinente o pueden presentar su propia solicitud para la cadena de caracteres.↩︎
Las cinco regiones reconocidas por la UNESCO (en los seis idiomas de la ONU) son: África, Estados Árabes, Asia y el Pacífico, Europa y América del Norte, América Latina y el Caribe (a mayo de 2025).↩︎
Consultar los códigos estándar de país o área para uso estadístico (M49): https://unstats.un.org/unsd/methodology/m49/ publicados a diciembre de 2025.↩︎
Consultar la versión 6 de las Reglas para la Generación de Etiquetas para la Zona Raíz: https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en.↩︎
Consultar los Miembros del GAC: https://gac.icann.org/about/gac-members.↩︎
Consultar las notas de la Junta Directiva de la ICANN del 4 de marzo de 2011 sobre la tabla de clasificación de nuevos gTLD del GAC: https://archive.icann.org/en/topics/new-gtlds/board-notes-gac-scorecard-04mar11-en.pdf.↩︎
Consultar los Procesos de transición del registro: https://www.icann.org/en/contracted-parties/registry-operators/services/registry-transition-processes.↩︎
Consultar las RZ-LGR: https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en.↩︎
Consultar las definiciones de conceptos relacionados con variantes en el Glosario.↩︎
Consultar el Manual del Programa de Evaluación de los Proveedores de Servicios de Registro: https://newgtldprogram.icann.org/sites/default/files/documents/rsp-handbook-03jun24-en.pdf.↩︎
Consultar RFC 9499, sección 2: https://www.rfc-editor.org/rfc/rfc9499.html#name-names.↩︎
Para conocer ejemplos de colisiones de nombres, consultar la sección 2.2 del Informe del Proyecto de Análisis de Colisiones de Nombres (NCAP): https://icann-community.atlassian.net/wiki/download/attachments/99319865/ncap-study-1-report-19jun20-en.pdf.↩︎
Consultar el Informe del Segundo Estudio del Proyecto de Análisis de Colisiones de Nombres: https://www.icann.org/en/system/files/files/ncap-study-2-report-05apr24-en.pdf.↩︎
Consultar la Resolución de la Junta Directiva 2024.09.07.01: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-07-09-2024-en.↩︎
Para obtener más información sobre cómo se gestionaron las colisiones de nombres durante la última ronda, consultar https://www.icann.org/resources/pages/name-collision-2013-12-06-en.↩︎
Consultar Indicadores de Sanidad de Tecnologías de Identificadores (ITHI): https://ithi.research.icann.org/.↩︎
Este procedimiento estará disponible en el sitio web del Programa de Nuevos gTLD.↩︎
Para obtener detalles sobre cómo se asigna prioridad a las cadenas de caracteres, consultar la Sección 3.7 Orden de procesamiento de solicitudes y sorteo de priorización.↩︎
Este procedimiento estará disponible en el sitio web del Programa de Nuevos gTLD: https://newgtldprogram.icann.org/en.↩︎
Este procedimiento estará disponible en el sitio web del Programa de Nuevos gTLD: https://newgtldprogram.icann.org/en.↩︎
Consultar Estatutos de la ICANN, Artículo 1, Sección 1.1(a): https://www.icann.org/resources/pages/governance/bylaws-en/#article1.↩︎
Consultar más detalles en el Comunicado del GAC pronunciado en la reunión ICANN45 en Toronto: https://gac.icann.org/contentMigrated/icann45-toronto-communique, el Comunicado del GAC pronunciado en la reunión ICANN46 en Pekín. https://gac.icann.org/contentMigrated/icann46-beijing-communique, y la posterior resolución 2014.02.05.NG01 de la Junta Directiva de la ICANN: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-meeting-of-the-new-gtld-program-committee-05-02-2014-en; consultar más información sobre el Asesoramiento consensuado del GAC y su impacto en la ronda de 2012 del Programa de Nuevos gTLD: https://newgtlds.icann.org/en/applicants/gac-advice#gac-1-applicant-advisories.↩︎
En los Acuerdos de Registro Base entre la ICANN y los operadores de registro existentes de la Ronda de 2012 del Programa de Nuevos gTLD, los términos "Compromisos voluntarios de los operadores de registro" y "RVC" no existían y en su lugar, se utilizó el término "compromisos específicos en pos del interés público " (los términos "PIC voluntarios" y "PIC privados" también se utilizaban informalmente en el pasado). El Acuerdo de Registro Base para la Ronda de 2026 del Programa de Nuevos gTLD utilizará el término "compromisos voluntarios específicos en pos del interés público" para referirse a lo que ahora denominamos "Compromisos voluntarios de los operadores de registro" o "RVC”. Este enfoque se ajusta a la estructura y redacción existentes de la Especificación 11 del Acuerdo de Registro Base, así como al Procedimiento para la Resolución de Disputas en Materia de Compromisos de Interés Público (PICDRP) de la ICANN, que continúa siendo el procedimiento de resolución de disputas para abordar presuntos reclamos que indiquen que un operador de registro puede no estar cumpliendo con uno o más PIC obligatorios y sobre medidas de protección, así como futuros RVC aprobados en su Acuerdo de Registro en adelante. Consultar la Especificación 11 en el Apéndice 4 Acuerdo de Registro Base y la Sección 1.2.17 Procedimientos de resolución de disputas después de la delegación.↩︎
Consultar el Procedimiento para la Resolución de Disputas en Materia de Compromisos de Interés Público (PICDRP): https://www.icann.org/picdrp-en.↩︎
Este punto refleja la Especificación 11 sección 3(b) del Acuerdo de Registro Base según enmiendas del 5 de abril de 2024. A los efectos del Acuerdo de Registro Base, “Uso indebido del DNS” se define como malware, botnets, phishing, pharming y spam (cuando el spam sirve como mecanismo de entrega para las otras formas de Uso indebido del DNS) tal y como se definen estos términos en la Sección 2.1 del documento SAC 115 - Informe del SSAC sobre un enfoque interoperable para abordar la gestión del uso indebido en el DNS: https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac-115-en.pdf. Consultar la Sección 4.1 en la p. 2 de la Enmienda Global de 2024 a los Acuerdos de Registro: https://itp.cdn.icann.org/en/files/registry-agreements/base-registry-agreement-global-amendment-05-04-2024-en.pdf.↩︎
El Acuerdo de Registro Base es el resultado de una amplia consulta con la comunidad. La ICANN solo considerará modificaciones al acuerdo en circunstancias extraordinarias, como problemas legales, jurisdiccionales o normativos únicos que impedirían en términos jurídicos a una entidad ejecutar el Acuerdo de Registro Base tal como está. Consultar la Sección 1.2.15 Contratación.↩︎
Consultar el Comunicado pronunciado en la reunión ICANN46 en Pekín: https://gac.icann.org/contentMigrated/icann46-beijing-communique.↩︎
Consultar la resolución de la Junta Directiva de la ICANN 2014.02.05.NG01: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-meeting-of-the-new-gtld-program-committee-05-02-2014-en.↩︎
Consultar el Anexo 2 de la resolución de la Junta Directiva de la ICANN 2014.02.05.NG01: https://www.icann.org/en/system/files/files/resolutions-new-gtld-annex-2-05feb14-en.pdf.↩︎
En el Comunicado pronunciando en la reunión ICANN46 de Pekín (consultar https://gac.icann.org/contentMigrated/icann46-beijing-communique) se identificó una lista no exhaustiva de cadenas de caracteres que fueron solicitadas en la Ronda de 2012 del Programa de Nuevos gTLD y se recomendó a la Junta Directiva que los PIC sobre medidas de protección deberían aplicarse a esas cadenas de caracteres solicitadas. El GAC organizó estas cadenas de caracteres identificadas en subgrupos correspondientes.↩︎
Consultar el Comunicado pronunciado en la reunión ICANN46 en Pekín: https://gac.icann.org/contentMigrated/icann46-beijing-communique ↩︎
Ibidem.↩︎
Ibidem.↩︎
Ibidem.↩︎
Consultar el sitio web del Programa de Nuevos gTLD: https://newgtldprogram.icann.org/.↩︎
Consultar las actuales Políticas de consenso de la ICANN: https://www.icann.org/consensus-policies-en.↩︎
Los Servicios de registro adicionales se refieren a los servicios que ofrece un Proveedor de servicios de registro fuera de las Funciones críticas (es decir, Servicio del DNS, resolución adecuada de las DNSSEC, EPP, RDDS y Custodia de datos). Consultar una explicación más detallada del Servicio de registro adicional en la sección 1.1A-D en la Política de Evaluación de Servicios de Registro (véase https://www.icann.org/rsep-en). Consultar detalles sobre las Funciones críticas en la Sección 6 de la Especificación 10 en el Acuerdo de Registro Base (Apéndice 4).↩︎
Si el desempeño de un RVC aprobado requiere la operación de un Servicio de registro aprobado, se prevé que el compromiso mismo se incluya en la Especificación 11 del Acuerdo de Registro Base aplicable, sin embargo, se prevé que el Servicio de registro aprobado se incluya en el Anexo A del Acuerdo de Registro Base.↩︎
Como respuesta al Conjunto de preguntas 20 Información adicional y materiales de respaldo en el Apéndice 1 Preguntas incluidas en la solicitud, un solicitante puede incluir información adicional y materiales de apoyo que puedan ser de interés para el público o relevantes para la solicitud. Por ejemplo, un solicitante puede incluir enlaces a sus acuerdos separados con un tercero y sus compromisos adicionales fuera del Acuerdo de Registro. Las respuestas del solicitante a esta pregunta serán meramente informativas, y no serán evaluadas ni vinculantes para el solicitante a través del Acuerdo de Registro. Sin embargo, estas respuestas estarán abiertas al público para su revisión y el aporte de comentarios. En consecuencia, los solicitantes deben considerar cuidadosamente si desean revelar información adicional, y qué tipo de información, en respuesta al Conjunto de preguntas 20. Por ejemplo, podría ser utilizado por un tercero para apoyar una objeción, pero también puede ayudar a abordar las preocupaciones de terceros y evitar una posible objeción.↩︎
Se prevé que el solicitante y la ICANN puedan negociar el texto específico de un RVC durante la Evaluación de compromisos de los operadores de registro, con el fin de identificar el texto propuesto para el Acuerdo de Registro que cumpla con los criterios de la RCE (consultar la Sección 3.8.4.2 Pedidos de cambios en una solicitud: Flujo de trabajo 2). La ICANN no rechaza de forma inmediata ni automática un RVC propuesto sin comunicarse previamente con el solicitante.↩︎
Consultar el sitio web del Programa de Nuevos gTLD: https://newgtldprogram.icann.org/.↩︎
Los cinco criterios de evaluación de RVC reflejan este principio fundamental, que fue reconocido por la Junta Directiva de la ICANN cuando instruyó a la organización de la ICANN implementar criterios y procesos de evaluación para la consideración de compromisos propuestos por los solicitantes para su inclusión en los Acuerdos de Registro correspondientes: “Para celebrar cualquier acuerdo, la ICANN debe considerar que los términos y condiciones propuestos (incluido todo compromiso en pos del interés público) se suscriban al servicio de la misión de la ICANN, que consiste en garantizar el funcionamiento estable y seguro de los sistemas de identificadores únicos de Internet.” (Consultar el fundamento en las resoluciones 2024.06.08.08 – 2024.06.08.10 de la Junta Directiva de la ICANN: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-08-06-2024-en#section2.b).↩︎
Si el solicitante considera que dichos compromisos no propuestos para su inclusión en el Acuerdo de Registro pueden ser de interés para el público o relevantes para la solicitud, el solicitante puede incluirlos como respuesta al Conjunto de preguntas 20 Información adicional y material de respaldo en el Apéndice 1 Preguntas incluidas en la solicitud para que el público los revise y comente. Las respuestas del solicitante a esta pregunta serán meramente informativas, y no serán evaluadas ni vinculantes para el solicitante a través del Acuerdo de Registro. En consecuencia, los solicitantes deben considerar cuidadosamente si desean revelar información adicional, y qué tipo de información, en respuesta al Conjunto de preguntas 18. Por ejemplo, podría ser utilizado por un tercero para apoyar una objeción, pero también puede ayudar a abordar las preocupaciones de terceros y evitar una posible objeción.↩︎
La palabra "debería" (en oposición a "debe") se utiliza intencionalmente en el criterio 4. Consultar el RFC2119 sobre Palabras claves a utilizar en los RFC para indicar niveles de requisitos: https://datatracker.ietf.org/doc/html/rfc2119 (“Esta palabra, o el adjetivo "RECOMENDADO", significa que pueden existir motivos válidos en ciertas circunstancias para ignorar un elemento en particular, pero se deben comprender y sopesar con cautela todas las implicancias antes de elegir un rumbo diferente”). Puede haber circunstancias en las que un RVC que duplique los requisitos de la política de consenso o la legislación aplicable pueda aprobarse a discreción de la ICANN, por ejemplo, si este tipo de RVC es necesario para abordar el Asesoramiento consensuado del GAC.↩︎
Consultar el Apéndice 4 Acuerdo de Registro Base, el Acuerdo de Acreditación de Registradores: https://www.icann.org/resources/pages/registrars/registrars-en, y las actuales Políticas de consenso de la ICANN: https://www.icann.org/consensus-policies-en ↩︎
Consultar información adicional de referencia en las Resoluciones 2024.06.08.08 - 2024.06.08.10 de la Junta Directiva de la ICANN: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-08-06-2024-en#section2.b.↩︎
Los Estatutos de la ICANN establecen que "La ICANN no regulará (es decir, no impondrá reglas o restricciones sobre) los servicios que usan los identificadores únicos de Internet o el contenido que dichos servicios transmiten o brindan, fuera del alcance expresamente establecido en la Sección 1.1(a)”. (Consultar Estatutos de la ICANN, Artículo 1, Sección 1.1(a): https://www.icann.org/resources/pages/governance/bylaws-en/#article1). Tras una extensa deliberación y consulta a la comunidad con respecto a cómo los Estatutos afectan la evaluación de RVC, la Junta Directiva de la ICANN estableció que la ICANN debe excluir de los Acuerdos de Registro de la Ronda de 2026 "cualquier RVC y otros compromisos de registros comparables que restrinjan contenido en los gTLD".↩︎
Si un solicitante de un gTLD de la comunidad desea que se puntúe una Política de registración para la comunidad en la Evaluación con prioridad de la comunidad (CPE), deberá proponer dicha política para su inclusión en la Especificación 12 del Acuerdo de Registro Base aplicable al presentar una solicitud de la comunidad. Dicha política sirve como requisito previo para la participación de la solicitud en la CPE (consultar la Sección 5.4 Evaluación con prioridad de la comunidad).↩︎
Se prevé que el solicitante y la ICANN puedan negociar el texto específico de una Política de registración para la comunidad durante la Evaluación de compromisos de los operadores de registro, con el fin de identificar el texto propuesto para el Acuerdo de Registro que cumpla con los criterios de la RCE (consultar la Sección 3.8.4.2 Pedidos de cambios en una solicitud: Flujo de trabajo 2). El solicitante deberá presentar un Pedido de cambios en una solicitud que refleje el texto negociado del Acuerdo de Registro para la Política de registración para la comunidad propuesta tras recibir la notificación de la ICANN. La ICANN no rechaza de forma inmediata ni automática una Política de registración para la comunidad propuesta sin comunicarse previamente con el solicitante. Sin embargo, si el solicitante no presenta el Pedido de cambios en una solicitud requerido dentro del plazo establecido en la Sección 3.8 Pedidos de cambios en una solicitud el resultado de la RCE sería negativo.↩︎
Consultar el Procedimiento para la Resolución de Disputas por Restricciones de Registración (RRDRP): https://www.icann.org/rrdrp-en, y Procedimiento de solicitudes de cambio de gTLD de una comunidad: https://www.icann.org/resources/pages/community-gtld-change-requests-en.↩︎
Si un solicitante de TLD de la comunidad considera que las políticas de registración para la comunidad adicionales que el solicitante planea implementar pero no propone incluir en el Acuerdo de Registro aplicable pueden ser de interés para el público o relevantes para la solicitud, el solicitante puede incluirlas como respuesta al Conjunto de preguntas 20 Información adicional y material de respaldo en el Apéndice 1 Preguntas incluidas en la solicitud para que el público las revise y comente. Las respuestas del solicitante a esta pregunta serán meramente informativas, y no serán evaluadas (por ejemplo, no se tendrán en cuenta en ninguna puntuación aplicable durante la Evaluación con prioridad de la comunidad (CPE)) ni vinculantes para el solicitante a través del Acuerdo de Registro. En consecuencia, los solicitantes deben considerar cuidadosamente si desean revelar información adicional, y qué tipo de información, en respuesta al Conjunto de preguntas 20. Por ejemplo, podría ser utilizado por un tercero para apoyar una objeción, pero también puede ayudar a abordar las preocupaciones de terceros y evitar una posible objeción.↩︎
Consultar las Reglas para la Generación de Etiquetas para la Zona Raíz: https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en.↩︎
Para cualquier cadena de caracteres variante, su cadena principal se utiliza para determinar su conjunto de cadenas de caracteres y variantes establecido por las Reglas para la Generación de Etiquetas para la Zona Raíz. El conjunto contiene la cadena de caracteres principal, toda cadena variante asignable y toda cadena variante bloqueada.↩︎
Por ejemplo, un solicitante solo puede solicitar cadenas de caracteres variantes asignables, pero no puede solicitar cadenas de caracteres variantes bloqueadas, según lo calculado por las Reglas para la Generación de Etiquetas para la Zona Raíz Consultar la Sección 3.1.9.1 Reglas para los IDN y sus variantes.↩︎
Consultar la Afirmación 24.2, Informe Final del PDP sobre Procedimientos Posteriores a la Introducción de los Nuevos gTLD, p. 108: https://gnso.icann.org/sites/default/files/file/field-file-attach/final-report-newgtld-subsequent-procedures-pdp-02feb21-en.pdf.↩︎
El término “visualmente similares” se utiliza para referirse a dichas cadena de caracteres.↩︎
En el futuro, después de la próxima ronda de nuevos gTLD, algunas de estas cadenas de caracteres variantes asignables serán asignadas (y están incluidas en esta categoría).↩︎
Tal como se indica en la moción 20251113 del Consejo de la GNSO, “Los identificadores pertinentes [asociados al Movimiento Internacional de la Cruz Roja y de la Media Luna Roja y al Comité Olímpico Internacional, así como los nombres completos de determinadas organizaciones internacionales gubernamentales y organizaciones internacionales no gubernamentales] no se incluirán en la evaluación de la similitud entre cadenas de caracteres del Programa de Nuevos gTLD, y dichos identificadores pertinentes no constituirán un obstáculo para que otro solicitante presente una solicitud para una cadena de caracteres confusamente similar, durante la evaluación”. Consultar el texto completo de la moción del Consejo de la GNSO: https://gnso.icann.org/en/council/resolutions/2020-current#20251113. Consultar también la Sección 7.2.2 Nombres reservados.↩︎
Estas son cadenas de caracteres que no se encuentran en ninguno de los siguientes estados: “Retirada”, “RA rescindido” o “Delegada”. Todas las cadenas de caracteres en proceso de la ronda de 2012 de nuevos gTLD se publican en: https://gtldresult.icann.org/. Consultar también las Resoluciones 2025.09.14.05 - 2025.09.14.06 de la Junta Directiva sobre el Procedimiento de finalización de las solicitudes restantes de la ronda de 2012 que no fueron aceptadas: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-14-09-2025-en#section1.c.rationale.↩︎
Para ver una lista de todos los IDN ccTLD que superaron con éxito la evaluación, consultar https://www.icann.org/resources/pages/string-evaluation-completion-2014-02-19-en.↩︎
Todos los dominios de alto nivel que actualmente se encuentran en la zona raíz se pueden consultar en https://data.iana.org/TLD/tlds-alpha-by-domain.txt (la lista se actualiza de forma periódica).↩︎
Cadenas de caracteres actualmente solicitadas en el Proceso de Avance Acelerado de IDN ccTLD (consultar https://www.icann.org/resources/pages/fast-track-2012-02-25-en) o una política de IDN ccTLD, que puede reemplazar el proceso de Avance acelerado de IDN ccTLD. Puede existir un período donde tanto el Proceso de Avance Acelerado de IDN ccTLD como una Política de IDN ccTLD puedan estar ejecutándose de manera simultánea. En tal caso, las cadenas de caracteres prospectivas de IDN ccTLD de estos dos procesos serán consideradas dentro del alcance.↩︎
La definición más amplia de Nombres bloqueados se proporciona en la Sección 7.2.1 Nombres bloqueados. A efectos de la Evaluación de la similitud entre cadenas de caracteres, solo son aplicables dos categorías: (i) Nombres de dominio de uso especial, y (ii) organismos relacionados con la ICANN, la IANA y el IETF e infraestructura de Internet. Otras categorías de nombres bloqueados enumeradas no se utilizarán en la Evaluación de la similitud entre cadenas de caracteres.↩︎
Todos los códigos ASCII de dos letras están reservados para la asignación de código de país por la Agencia de Mantenimiento de la ISO 3166 independiente.↩︎
Una cadena de caracteres de una ronda anterior del Programa de Nuevos gTLD estará en uno de los siguientes estados: "Activa", "En contratación", "En espera", o "En PDT." Consultar también la página correspondiente al estado de la solicitud: https://gtldresult.icann.org/application-result/applicationstatus.↩︎
La definición más amplia de Nombres bloqueados se proporciona en la Sección 7.2.1 Nombres bloqueados. A efectos de la Evaluación de la similitud entre cadenas de caracteres, solo son aplicables dos categorías: (i) Nombres de dominio de uso especial, y (ii) organismos relacionados con la ICANN, la IANA y el IETF e infraestructura de Internet. Otras categorías de nombres bloqueados enumeradas no se utilizarán en la Evaluación de la similitud entre cadenas de caracteres.↩︎
La ccNSO está trabajando actualmente en el Proceso de Desarrollo de Políticas de IDN ccTLD (ccNSO PDP4 sobre la (de)selección de IDN ccTLD), que tiene la intención de reemplazar el Proceso de Avance Acelerado de Dominios de Alto Nivel con Código de País dentro de Nombres de Dominio Internacionalizados (IDN ccTLD). Una vez que la política del ccPDP4 de IDN se apruebe y se implemente, proporcionará otro mecanismo para los solicitantes de IDN ccTLD y también será aplicable aquí.↩︎
Una cadena de caracteres de IDN ccTLD solicitada es una que ha sido presentada a la ICANN a través del sistema de solicitud de IDN ccTLD y está siendo sometida a una evaluación de cadena de caracteres.↩︎
El término "validada" esencialmente significa que superaron con éxito la evaluación. Este término se definió inicialmente en 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) y se reafirmó en el Informe Inicial de ccPDP4. Consultar la sección "Validación de cadenas de caracteres y variantes de IDN ccTLD" en el Informe Inicial del ccPDP4 para obtener más información.↩︎
Tal como se define en la Sección 3.1.8.3.1.3 Elección de cadenas de caracteres principales o variantes mediante las RZ-LGR.↩︎
La definición más amplia de Nombres bloqueados se proporciona en la Sección 7.2.1 Nombres bloqueados. A efectos de la Evaluación de la similitud entre cadenas de caracteres, solo son aplicables dos categorías: (i) Nombres de dominio de uso especial, y (ii) organismos relacionados con la ICANN, la IANA y el IETF e infraestructura de Internet. Otras categorías de nombres bloqueados enumeradas no se utilizarán en la Evaluación de la similitud entre cadenas de caracteres.↩︎
Estas son cadenas de caracteres que no se encuentran en ninguno de los siguientes estados: “Retirada”, “RA rescindido” o “Delegada”. Todas las cadenas de caracteres en proceso de la ronda de 2012 de nuevos gTLD se publican en: https://gtldresult.icann.org/. Consultar también las Resoluciones 2025.09.14.05 - 2025.09.14.06 de la Junta Directiva sobre el Procedimiento de finalización de las solicitudes restantes de la ronda de 2012 que no fueron aceptadas: https://www.icann.org/en/board-activities-and-meetings/materials/approved-resolutions-regular-meeting-of-the-icann-board-14-09-2025-en#section1.c.rationale.↩︎
La Solicitud de cambio de cadena de caracteres que representa a una marca es independiente del proceso de cadena de caracteres de reemplazo. Consultar la Sección 5.1 Cadenas de caracteres de reemplazo.↩︎