Módulo 1 El recorrido del solicitante

Este módulo proporciona una reseña integral de toda la experiencia de un solicitante de nuevos gTLD, desde la presentación inicial de la solicitud hasta la posible delegación. El proceso es intrincado e incluye múltiples etapas, que abarcan evaluaciones técnicas, financieras y operativas.

Este recorrido del solicitante está diseñado para proporcionar a los posibles solicitantes información esencial sobre cada etapa, incluida la presentación, preevaluación, aportes de la comunidad, evaluación, controversia por cadenas de caracteres, resolución de disputas y contratación.

Al ofrecer una hoja de ruta clara, este módulo guía a los solicitantes a través de las complejidades del proceso de solicitud, para asegurarse de que estén preparados para cada paso hacia la obtención de un nuevo gTLD.

1.1 Información previa a la presentación

1.1.1 Elegibilidad

Solo las personas jurídicas como corporaciones, organizaciones e instituciones, así como entidades gubernamentales, no gubernamentales e intergubernamentales pueden solicitar un nuevo gTLD. No se tendrán en cuenta las solicitudes de personas físicas o empresas unipersonales. Además, no se aceptarán solicitudes presentadas por personas jurídicas aún por constituirse o en su nombre, ni solicitudes que presupongan la futura constitución de una entidad jurídica (por ejemplo, una empresa conjunta pendiente).

1.1.2 Tarifas

Se requiere que los solicitantes paguen la tarifa completa de evaluación de gTLD de USD 227 000 por cada solicitud, con excepciones para aquellos que reúnan los requisitos para el Programa de Apoyo para Solicitantes (ASP) y quienes presenten solicitudes de variantes que cumplan con los criterios descritos en la Sección 3.3 Tarifas y pagos. La tarifa deberá abonarse en el momento de la recepción de la factura, y la ICANN deberá recibir el pago completo a más tardar siete días después del cierre del período para la presentación de solicitudes. Si el solicitante no ha abonado la tarifa de evaluación del gTLD en este período de siete días, por lo general, la solicitud no seguirá procesándose y será cancelada.

Es posible que todos los solicitantes, incluidos aquellos que reúnan los requisitos para el ASP,¹ deban pagar tarifas adicionales en concepto de evaluaciones condicionales. Por ejemplo, esto se aplica si un solicitante procura que su solicitud sea designada como un TLD que representa a una marca o desea que se agregue un Compromiso voluntario de los operadores de registro a su Acuerdo de Registro. Si un solicitante no paga por una evaluación condicional, según el tipo de evaluación condicional, se le puede solicitar que presente un Pedido de cambios en una solicitud para eliminar esa sección de su solicitud para poder continuar. De lo contrario, las evaluaciones condicionales requeridas deben pagarse a tiempo para evitar la descalificación. Se puede encontrar más información en la Sección 3.3 Tarifas y pagos.

1.1.3 Términos y condiciones

Todos los solicitantes deben aceptar los Términos y condiciones de solicitud de TLD del Programa de Nuevos gTLD: Ronda de 2026 para poder presentar sus solicitudes (Consultar el Apéndice 10 Términos y condiciones, que se recomienda a los solicitantes leer en su totalidad).

1.1.4 Sistema de gestión de solicitudes de TLD

Las solicitudes deben presentarse en formato electrónico mediante el Sistema de gestión de solicitudes de TLD (TAMS). No se admitirán solicitudes en papel. Se recomienda a los solicitantes que consulten la Guía del Usuario del TAMS en el sitio web del Programa de Nuevos gTLD² para saber cómo utilizar el sistema y asegurarse de que lo entienden correctamente antes de presentar la solicitud.

1.1.5 Intención de buena fe

Las solicitudes deben presentarse con una intención bona fide (“de buena fe”) de operar el gTLD. Los solicitantes deben afirmar una intención de buena fe de operar el gTLD para todas las solicitudes presentadas en el TAMS (Consultar Conjunto de preguntas 21 en el Apéndice 1 Preguntas incluidas en la solicitud). La ICANN se reserva el derecho de impedir que una solicitud avance si determina que la solicitud no fue presentada de buena fe.

1.1.6 Aceptación Universal

El objetivo de la Aceptación Universal (UA) es garantizar que todas las aplicaciones, dispositivos y sistemas habilitados para Internet acepten todos los nombres de dominio y direcciones de correo electrónico, independientemente del código de escritura, el idioma o la longitud del TLD. Para obtener más información sobre la Aceptación Universal y el Programa de Nuevos gTLD, consultar la Sección 2.3 Aceptación Universal de nombres de dominio y direcciones de correo electrónico.

1.1.7 Programa de Apoyo para Solicitantes

Los solicitantes que deseen presentar una solicitud para un nuevo gTLD y operar un registro pueden postularse al Programa de Apoyo para Solicitantes (ASP). Si son elegibles, los solicitantes seleccionados podrán recibir apoyo financiero y no financiero. Consultar la sección ASP en el sitio web del Programa de Nuevos gTLD³ para obtener más información y actualizaciones.

1.2 Etapas de la solicitud

Esta sección describe las etapas por las que pasa una solicitud durante el período de presentación de solicitudes y una vez presentada. Mientras que algunas etapas se aplican a todas las solicitudes presentadas, otras ocurren solo en circunstancias específicas. Esta sección ofrece una reseña general y no exhaustiva de los diversos procesos. Para obtener información completa, los solicitantes y otras partes interesadas deben consultar las secciones pertinentes de la Guía para el Solicitante.

1.2.1 Presentación de solicitudes

Duración prevista: 105 días

1.2.1.1 Creación de una cuenta de la ICANN

Antes de acceder al TAMS para presentar su solicitud, los solicitantes deben registrarse para obtener una cuenta de usuario de la ICANN en el sitio web de Cuenta de la ICANN⁴ y habilitar la autenticación de factor múltiple.

1.2.1.2 Período para la presentación de solicitudes

Se prevé que el plazo para la presentación de solicitudes se abra a más tardar a las 23:59 UTC del 30 de abril de 2026 y permanezca abierto durante 105 días, concluyendo el 12 de agosto de 2026 a las 23:59 UTC. Para ser consideradas, todas las solicitudes deberán presentarse antes del cierre del período para la presentación de solicitudes, ya que el sistema no admitirá solicitudes presentadas fuera de plazo. Se recomienda a los solicitantes que presenten sus solicitudes completas lo antes posible una vez abierto el período para la presentación de solicitudes. Esperar hasta el final de este período para iniciar el proceso no proporcionará tiempo suficiente para completar todos los pasos necesarios y presentar una solicitud completa a tiempo.

Los solicitantes deben abonar su tarifa de evaluación de gTLD al recibir la factura, y a más tardar siete días después del cierre del período para la presentación de solicitudes para que su solicitud sea considerada, tal como se describe en la Sección 3.3 Tarifas y pagos.

Después de presentar su solicitud, los solicitantes no podrán realizar ningún cambio fuera de los procesos que se describen en la Sección 3.8 Pedidos de cambios en una solicitud. Los Pedidos de cambios en una solicitud solo pueden presentarse después del Día de confirmación de las cadenas de caracteres.

1.2.1.3 Preguntas incluidas en la solicitud

La solicitud constará de las siguientes secciones que deberán completarse al momento de registrarse el usuario:

1. Información de la organización

2. Información financiera

3. Información de la solicitud de gTLD

Para completar la solicitud, los usuarios deben responder a una serie de preguntas y presentar la documentación de respaldo que se les solicite. El sistema validará que todos los campos obligatorios incluyan una respuesta antes de que los solicitantes puedan presentar su solicitud. Consultar más información en la Sección 3.1.3 Preguntas incluidas en la solicitud así como en el Apéndice 1 Preguntas incluidas en la solicitud.

1.2.1.4 Cadenas de caracteres en una solicitud

Cada solicitud es para un gTLD y puede incluir una o más de sus cadenas de caracteres variantes asignables, según corresponda. Una solicitud también puede referirse a una o varias cadenas de caracteres variantes asignables de un gTLD existente.⁵

1.2.1.5 Selección de cadena de caracteres de reemplazo

Para reducir potencialmente los casos de controversias por cadenas de caracteres, como parte de su solicitud, los solicitantes también pueden optar por presentar cadenas de caracteres de reemplazo, como se describe en la Sección 5.1 Cadenas de caracteres de reemplazo.

1.2.1.6 Tipos de cadenas de caracteres y solicitudes

Como se describe en la Sección 3.1.6 Tipos de solicitudes y cadenas de caracteres , ciertos tipos de solicitudes pueden requerir tratamiento diferencial según la naturaleza de la solicitud, la cadena de caracteres o el solicitante.

Entre los diferentes tipos de solicitudes se incluyen los siguientes: General, Comunidad, Nombre geográfico, Nombre reservado, TLD que representa a una marca, Nombre de Dominio Internacionalizado (IDN), Variante de gTLD existente, TLD IDN principal que incluye una o más variantes, Medidas de protección de Categoría 1, y solicitudes de gobiernos, OIG y solicitantes que reciben apoyo (tipos de solicitudes de Solicitante Gubernamental/OIG y Apoyo para solicitantes).

Además, ciertas cadenas de caracteres iniciarán procedimientos específicos de procesamiento y evaluación: Nombres geográficos, TLD IDN, Nombres reservados y cadenas de caracteres sujetas a Medidas de protección de Categoría 1.

1.2.1.7 Genéricos cerrados

La Junta Directiva de la ICANN ha resuelto que no se aprobarán las cadenas de caracteres de uso exclusivo (genéricos cerrados⁶) a menos que se establezcan una metodología y unos criterios aprobados para evaluar si un dominio genérico cerrado propuesto serviría al interés público. Consultar la Sección 3.1.7 Cadenas de caracteres de uso exclusivo (Genéricos cerrados).

1.2.1.8 Validaciones de cadenas de caracteres previas a la presentación

Ciertas validaciones (consultar la Sección 3.1.8 Validaciones de cadenas de caracteres previas a la presentación) de las cadenas de caracteres principales y variantes, incluidas las cadenas de reemplazo, se incorporan e implementan automáticamente a través del TAMS. Si una cadena de caracteres no supera una de las validaciones o se encuentra una coincidencia, el solicitante recibirá un mensaje de error o advertencia en el TAMS que explica los problemas detectados y no se le permitirá continuar y presentar su solicitud o tendrá que proporcionar documentación adicional. Los solicitantes podrán ingresar su cadena de caracteres en el TAMS para verificar si existe una coincidencia.

1.2.1.8.1 Identificación de nombres bloqueados

Ciertas cadenas de caracteres, denominadas "Nombres bloqueados", no están disponibles para su delegación. Durante el proceso de confección de la solicitud, el sistema verificará automáticamente si la cadena de caracteres que introdujo el solicitante y cualquier cadena de caracteres variante aplicable aparecen en la lista de Nombres bloqueados. De ser así, el solicitante no podrá seguir adelante con esa cadena de caracteres y debe seleccionar una diferente para poder continuar con la solicitud. Para obtener más información, consultar la Sección 3.1.8.1 Identificación de nombres bloqueados.

1.2.1.8.2 Identificación de nombres reservados

Determinadas cadenas de caracteres, conocidas como "Nombres reservados", están disponibles como gTLD únicamente a través de un proceso de verificación. Estos nombres están designados para entidades específicas, denominadas "OIG-OING internacionales limitadas", que son las únicas partes que pueden solicitarlos. La ICANN mantiene la lista de Nombres reservados, compilada de diversas fuentes, y requiere que las entidades pertinentes proporcionen documentación apropiada. Durante el proceso de confección de la solicitud, el sistema verificará automáticamente si la cadena de caracteres que introdujo el solicitante y cualquier cadena de caracteres variante aplicable aparecen en la lista de Nombres reservados. Si la cadena de caracteres se encuentra en esta lista, se iniciará el proceso de excepción, durante el cual se pedirá al solicitante que cargue documentación de respaldo que demuestre que es la entidad para la que se reserva el nombre. Para obtener más información, consultar la Sección 3.1.8.2 Nombres reservados.

1.2.1.8.3 Revisión de estabilidad del DNS

Esta revisión evalúa si una cadena de caracteres solicitada afectará negativamente la seguridad o estabilidad del Sistema de Nombres de Dominio (DNS) y cumplirá con el DNS y otros estándares relevantes, como se describe en la Sección 3.1.8.3 Revisión de estabilidad del DNS. La Revisión de estabilidad del DNS incluye una verificación del cumplimiento de las Reglas para la Generación de Etiquetas para la Zona Raíz aplicables. Si la cadena de caracteres no supera alguna de las pruebas, el solicitante no podrá presentar su solicitud.

1.2.1.9 Selección del proveedor de servicios de registro

Se requiere que todos los solicitantes identifiquen uno o más Proveedores de servicios de registro (RSP) evaluados mediante el Programa de Evaluación de RSP⁷, a los cuales el solicitante tiene intención de recurrir si la cadena o cadenas de caracteres solicitadas pasan a la fase de delegación. La lista de RSP evaluados puede consultarse en la Página de solicitudes de proveedores de servicios de registro (RSP).⁸

Como parte de la presentación de su solicitud, se recomienda al solicitante que identifique los RSP que pretende utilizar y los servicios de registro que pretende ofrecer en los gTLD propuestos, pero el solicitante puede optar por especificar los RSP justo antes de la evaluación de la solicitud.

Los solicitantes también pueden contratar RSP externos o solicitar la aprobación de la ICANN para prestar ellos mismos servicios de registro críticos como RSP a través del Programa de Evaluación de los RSP. Consultar la Sección 3.1.10 Selección del proveedor de servicios de registro.

1.2.2 Procesos de preevaluación

1.2.2.1 Comprobación administrativa y preparación para el Día de revelación

Duración prevista: Ocho semanas

Una vez cerrado el período para la presentación de solicitudes, la ICANN llevará a cabo las diligencias administrativas necesarias y comprobará si se han recibido las tarifas de evaluación. La ICANN revisará la lista de solicitudes presentadas y colocará las solicitudes de cadenas de caracteres idénticas en conjuntos de solicitudes controvertidas como preparación para el día de revelación.

Se prevé que la comprobación administrativa de todas las solicitudes se complete en un plazo aproximado de ocho semanas, en función del volumen total de solicitudes. En caso de que haya un gran volumen de solicitudes que impida a la ICANN procesar todas las solicitudes dentro del plazo establecido, la ICANN publicará un calendario actualizado tan pronto como sea posible.

1.2.2.2 Día de revelación

Salvo circunstancias extraordinarias, la ICANN prevé publicar la lista de todas las solicitudes que hayan superado la Comprobación administrativa el Día de revelación, a más tardar nueve semanas después del cierre del período para la presentación de solicitudes. Esta lista, que se publicará en el sitio web del Programa de Nuevos gTLD,⁹ incluirá las cadenas de caracteres solicitadas relevantes y cualquier cadena de caracteres variante y de reemplazo, según corresponda. Las partes públicas de cada solicitud también estarán disponibles. También se publicará en el sitio web una lista de conjuntos de solicitudes controvertidas que contienen solicitudes para cadenas de caracteres idénticas. Consultar la Sección 5.2.4.1 Controversia como resultado de solicitudes de cadenas de caracteres de gTLD idénticas para obtener más información. Ciertas comunicaciones y actividades estarán prohibidas a partir del Día de revelación; para más información, consultar la Sección 5.2.3.1 Comunicaciones y actividades prohibidas.

1.2.2.3 Período de reemplazo

Duración prevista: Dos semanas

Una vez que los solicitantes tengan acceso a la lista completa de cadenas de caracteres solicitadas, al igual que cualquier cadena variante y cadenas de reemplazo, tendrán la oportunidad de reemplazar su cadena de caracteres solicitada por su cadena de reemplazo. Los solicitantes que hayan seleccionado una cadena de caracteres de reemplazo elegible dispondrán de un período de reemplazo de 14 días para notificar a la ICANN a través del TAMS su intención de reemplazar la cadena original solicitada por la cadena de reemplazo identificada en su solicitud. Consultar la Sección 5.1 Cadena de caracteres de reemplazo para obtener más información.

1.2.2.4 Día de confirmación de las cadenas de caracteres

En el Día de confirmación de las cadenas de caracteres, la ICANN publicará una lista actualizada de las solicitudes y las cadenas de caracteres elegidas (ya sean originales o de reemplazo, como se indicó anteriormente). También se publicará una lista de conjuntos de solicitudes controvertidas actualizados.

1.2.2.5 Sorteo de priorización

Se prevé que se celebre un sorteo de priorización a más tardar 30 días después del Día de confirmación de las cadenas de caracteres. El Sorteo determinará el Número de prioridad de una solicitud y el orden general en el que será procesada por la ICANN, como se describe en la Sección 3.7 Orden de procesamiento de solicitudes y sorteo de priorización.

1.2.3 Aportes de la comunidad, objeciones y apelaciones

A partir del Día de confirmación de las cadenas de caracteres, la comunidad tendrá la oportunidad de proporcionar sus aportes como se describe a continuación.

1.2.3.1 Comentarios sobre solicitudes

Duración prevista: 104 días posteriores al Día de confirmación de las cadenas de caracteres; 30 días posteriores a los Pedidos de cambios en una solicitud

El público en general podrá publicar comentarios sobre solicitudes en el Foro de comentarios sobre solicitudes, como se describe en la Sección 4.1 Comentarios sobre solicitudes. La ICANN compartirá estos comentarios y cualquier respuesta con los evaluadores asignados a las solicitudes pertinentes. Solo los comentarios y respuestas recibidos durante los períodos de presentación de comentarios (104 días posteriores al Día de confirmación de las cadenas de caracteres y 30 días posteriores a los Pedidos de cambios en una solicitud aplicables¹⁰) serán considerados por los paneles de evaluación.

1.2.3.2 Alertas tempranas de miembros del GAC

Duración prevista: 104 días posteriores al Día de confirmación de las cadenas de caracteres

Los miembros y observadores del Comité Asesor Gubernamental (GAC) de la ICANN pueden emitir Alertas tempranas de miembros del GAC dentro del plazo de 104 días posteriores al Día de confirmación de las cadenas de caracteres, como se describe en la Sección 4.2 Alertas tempranas de miembros del GAC.

1.2.3.3 Asesoramiento consensuado del GAC

El GAC puede proporcionar Asesoramiento consensuado del GAC a la Junta Directiva de la ICANN sobre cualquier solicitud, como se describe en los Estatutos de la ICANN y como se describe en la Sección 4.3 Asesoramiento consensuado del GAC.

1.2.3.4 Notificaciones singular/plural

Duración prevista: 30 días posteriores al Día de confirmación de las cadenas de caracteres

Dentro de un plazo de 30 días posteriores al Día de confirmación de las cadenas de caracteres, el público puede notificar a la ICANN sobre:

• Cadenas de caracteres solicitadas que representan versiones en singular o plural de la misma palabra en el mismo idioma.

• Una cadena de caracteres solicitada que es una versión en singular o plural de:

  • Cadena de caracteres delegada

  • Cadena de caracteres que todavía está siendo procesada de una ronda anterior de nuevos gTLD

  • Nombre bloqueado

Para obtener más información, consultar la Sección 4.4 Notificaciones singular/plural.

1.2.3.5 Objeciones y apelaciones

Duración prevista del período para la presentación de objeciones: 104 días posteriores al Día de confirmación de las cadenas de caracteres

Duración prevista del período para la presentación de apelaciones: 15 días posteriores a la determinación de la objeción para presentar la notificación de apelación; 15 días para presentar la apelación

En los 104 días posteriores al Día de confirmación de las cadenas de caracteres, las partes con legitimación pueden presentar objeciones contra solicitudes específicas, que serán evaluadas por un panel de expertos. Las objeciones pueden basarse en cuatro fundamentos: confusión de cadenas de caracteres, derechos legales, interés público limitado y comunidad.

La parte que no prevalece en una objeción tiene una oportunidad limitada para apelar la decisión. La parte que no prevalece debe notificar al Proveedor de Servicios de Resolución de Disputas (DRSP) su intención de apelar dentro de los 15 días posteriores a la emisión de la resolución de la objeción. Posteriormente, la parte que no prevalece tiene 15 días adicionales desde la fecha de notificación para presentar la apelación y pagar las tarifas requeridas.

Las objeciones y apelaciones se presentan directamente ante los DRSP identificados por la ICANN. Tanto la presentación como la tramitación de estos procedimientos implican costos para las partes. Consultar la Sección 4.5 Objeciones y apelaciones para obtener más información sobre costos y procedimientos.

1.2.4 Evaluación de la cadena de caracteres

Duración prevista: 180 días¹¹

La Evaluación de la cadena de caracteres se centra únicamente en la evaluación de las cadenas de caracteres solicitadas y sus variantes asignables. Este proceso comienza después del Día de confirmación de las cadenas de caracteres y se prevé que tenga una duración de 180 días. La Evaluación de la cadena de caracteres se superpondrá parcialmente con el período durante el cual la comunidad puede proporcionar sus aportes sobre las solicitudes, como se describe en el Módulo 4 Aportes de la comunidad, objeciones y apelaciones. La Evaluación de la cadena de caracteres consta de los cinco elementos que se describen a continuación, cada uno de los cuales se evaluarán simultáneamente: La Evaluación de la cadena de caracteres, a diferencia de la Evaluación de solicitudes y solicitantes, no sigue el orden de prioridad.

1.2.4.1 Evaluación de la similitud entre cadenas de caracteres

La Evaluación de la similitud entre cadenas de caracteres será realizada por un panel de expertos con el objetivo de prevenir la confusión del usuario y la pérdida de confianza en el DNS que se genera ante la delegación de cadenas de caracteres visualmente similares¹², como se describe con mayor detalle en la Sección 7.10 Evaluación de la similitud entre cadenas de caracteres.

1.2.4.2 Evaluación inicial de colisiones de nombres

La evaluación inicial de colisiones de nombres tiene como objetivo identificar las cadenas de caracteres con un alto riesgo de colisión de nombres, tal como se describe en la Sección 7.7 Colisión de nombres. Si una cadena de caracteres se considera de alto riesgo, el solicitante tendrá la oportunidad de presentar un plan de mitigación para su evaluación, lo que permitirá que la solicitud siga adelante si se aprueba. De lo contrario, la cadena de caracteres se agregará a la Lista de cadenas de caracteres sujetas a colisiones y la solicitud no continuará. La sección también incluye información sobre la Delegación temporaria, que es un proceso adicional aplicable para cadenas de caracteres no identificadas inicialmente como de alto riesgo.

1.2.4.3 Evaluación de medidas de protección

La Evaluación de medidas de protección determinará si se exigirán medidas de protección específicas a una cadena de caracteres solicitada como requisitos contractuales en el Acuerdo de Registro aplicable en relación con la protección de los consumidores, las cadenas de caracteres sensibles y los mercados regulados. Más información en la Sección 7.8.2 Compromisos en pos del interés público sobre medidas de protección.

1.2.4.4 Identificación de nombres geográficos

Como parte de la identificación de nombres geográficos, un panel revisará todas las cadenas de caracteres solicitadas e identificará las que pueden considerarse un nombre geográfico, tal como se describe en la Sección 7.5 Nombres geográficos. Esto es independiente del proceso de verificación más sustancial denominado Revisión de nombres geográficos que tendría lugar como parte de la Evaluación de solicitudes.

1.2.4.5 Evaluación de notificaciones singular/plural

La ICANN revisará los materiales enviados como parte del proceso de Notificaciones singular/plural y determinará si ciertas cadenas de caracteres representan las formas singular y plural de la misma palabra en el mismo idioma. Consultar la Sección 4.4.3 Resultado de las notificaciones singular/plural.

1.2.5 Delegación temporaria

Las cadenas de caracteres que no fueron identificadas como potencialmente de alto riesgo como se describe en la Sección 7.7.2 Evaluación inicial de colisiones de nombres serán objeto de una delegación temporaria. La Delegación temporaria se iniciará una vez concluida la Evaluación inicial de colisiones de nombres, aunque se sigan realizando otras evaluaciones que formen parte de la Evaluación de la cadena de caracteres, y seguirá el orden de prioridad, según corresponda. 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.

La duración de la Delegación temporaria se definirá como parte del proceso y criterios relativos a la colisión de nombres. Si una cadena de caracteres se considera de alto riesgo, se eliminará de la zona raíz y el solicitante tendrá la oportunidad de presentar un Plan de mitigación para su evaluación, lo que permitirá que la solicitud siga adelante si se aprueba. De lo contrario, la cadena de caracteres se agregará a la Lista de cadenas de caracteres sujetas a colisiones. Consultar más información en la Sección 7.7 Colisión de nombres. La conclusión de la Delegación temporaria no es necesaria para que otros procesos, como la Evaluación de solicitudes y solicitantes o la resolución de conjuntos de solicitudes controvertidas, puedan comenzar.

Sin embargo, una solicitud podrá continuar su tramitación hacia la etapa de contratación solo cuando la Delegación temporaria haya concluido y el Plan de mitigación esté implementado, según corresponda.

1.2.6 Publicación de Informes de Evaluación de la cadena de caracteres y conjuntos de solicitudes controvertidas

Una vez que la Evaluación de la cadena de caracteres esté completada, se publicarán los Informes de Evaluación de la cadena de caracteres para todas las solicitudes, así como una lista actualizada de los conjuntos de solicitudes controvertidas, en el sitio web del Programa de Nuevos gTLD¹³.

1.2.7 Objeciones por confusión de cadenas de caracteres e identificación de posibles nuevos conjuntos de solicitudes controvertidas

Duración prevista: 30 días posteriores a la publicación de la lista inicial de conjuntos de solicitudes controvertidas

Como se describe en la Sección 4.5 Objeciones y apelaciones, una vez que la Evaluación de la cadena de caracteres se haya completado y se haya publicado una lista actualizada de los conjuntos de solicitudes controvertidas, habrá un segundo período de presentación de 30 días únicamente para Objeciones por confusión de cadenas de caracteres. Las solicitudes que recibieron una Objeción por confusión de cadenas de caracteres pueden crear conjuntos de solicitudes controvertidas adicionales en función de la decisión del DRSP. Si se crean nuevos conjuntos de solicitudes controvertidas, se publicarán en el sitio web del Programa de Nuevos gTLD.¹⁴

1.2.8 Evaluación con prioridad de la comunidad

• Condicional

Una vez que todos los conjuntos de solicitudes controvertidas hayan sido finalizados (es decir, ya no son posibles cambios en la composición del conjunto, excepto cuando un solicitante retira su solicitud) y todas las solicitudes en el conjunto de solicitudes controvertidas son elegibles para proceder a la resolución de controversias, los Solicitantes de la comunidad que estén en controversia pueden optar por someterse a la Evaluación con prioridad de la comunidad (CPE).¹⁵ La CPE es un análisis independiente que lleva a cabo un panel de expertos que determina si la solicitud de una comunidad cumple con los criterios de la CPE. Si una solicitud cumple con los criterios de la CPE, recibirá prioridad en el conjunto de solicitudes controvertidas. Se puede consultar más información sobre el proceso y los criterios en la Sección 5.4 Evaluación con prioridad de la comunidad.

1.2.9 Subastas de nuevos gTLD de la ICANN

La ICANN llevará a cabo subastas para resolver la controversia por cadenas de caracteres entre solicitantes de nuevos gTLD. Si el ganador de una subasta no es elegible para ejecutar o no ejecuta un Acuerdo de Registro con la ICANN, la ICANN puede, a su discreción, ofrecer al solicitante que realizó la segunda oferta más alta en la subasta, si lo hay, la oportunidad de continuar con su solicitud. Se puede consultar más información en la Sección 5.6 Subasta de nuevos gTLD de la ICANN. Para obtener información adicional sobre la elegibilidad para la contratación, consultar la Sección 1.2.15 Contratación. Consultar también 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 para conocer sobre otras evaluaciones aplicables que un solicitante ganador debe completar después de una Subasta de nuevos gTLD para poder proceder a la contratación.

1.2.10 Evaluación de solicitantes

La Evaluación de solicitantes se produce después de que la solicitud (a) haya superado con éxito la Evaluación de la cadena de caracteres y no forme parte de un conjunto de solicitudes controvertidas, o (b) haya superado con éxito la Evaluación de la cadena de caracteres y haya prevalecido en el conjunto de solicitudes controvertidas. Se lleva a cabo en paralelo con la Evaluación de solicitudes en función del número de prioridad de la solicitud, a menos que otros procesos impidan que la solicitud siga adelante. Consultar el Módulo 6 Procedimientos de evaluación de los solicitantes.

La evaluación de solicitantes consiste en dos evaluaciones obligatorias, detalladas a continuación:

1.2.10.1 Investigación de antecedentes

• Obligatoria

La investigación de antecedentes se lleva a cabo para proteger el interés público en la asignación de recursos críticos de Internet, lo que garantiza que solo las corporaciones, organizaciones o instituciones constituidas y que operen conforme a la ley puedan operar un nuevo gTLD. La ICANN se reserva el derecho a rechazar una solicitud que, por lo demás, cumpla con los requisitos, sobre la base de los resultados del proceso de investigación de antecedentes. Consultar la Sección 6.1 Investigación de antecedentes.

1.2.10.2 Evaluación financiera y operativa

• Obligatoria

La evaluación financiera y operativa evalúa si un solicitante tiene la capacidad financiera y operativa para mantener el registro a largo plazo y si ha implementado las medidas de protección razonables para garantizar la solidez de las operaciones comerciales y hacer frente a los problemas relativos al uso indebido.¹⁶ Consultar la Sección 6.2 Evaluación financiera y operativa.

1.2.11 Evaluación de solicitudes

Duración prevista: Consultar la Sección 1.5 Plazos del ciclo de vida

La evaluación de solicitudes está conformada por las evaluaciones que se describen a continuación. Entre ellas, solo es obligatoria la Revisión del proveedor de servicios de registro para todas las solicitudes. La Evaluación de compromisos de los operadores de registros (RCE) es obligatoria para todas las Solicitudes de la comunidad, pero es condicional para otras solicitudes.

1.2.11.1 Revisión de proveedores de servicios de registro

• Obligatoria

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. Consultar la Sección 7.9 Revisión de proveedores de servicios de registro.

1.2.11.2 Revisión de nombres geográficos

• Condicional

Un Panel de Nombres Geográficos verificará la relevancia y autenticidad de la documentación de respaldo para cualquier solicitud de una cadena de caracteres definida como Nombre Geográfico durante el proceso de Evaluación de la cadena de caracteres, como se describe en la Sección 7.5.3.2 Revisión de Nombres Geográficos.

1.2.11.3 Revisión de nombres reservados

• Condicional

El proceso de evaluación de nombres reservados determinará si la organización adecuada ha solicitado la cadena de caracteres reservada y verificará la documentación de respaldo, tal como se describe en la Sección 7.2.2 Nombres reservados.

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

• Condicional

El solicitante de una cadena de caracteres que la ICANN haya considerado que presenta un alto riesgo de colisión de nombres y haya resuelto la controversia puede presentar un plan de mitigación de cadenas de caracteres de alto riesgo para su revisión. Este plan será revisado por expertos técnicos (consultar la Sección 7.7.5 Evaluación del plan de mitigación de alto riesgo por colisión de nombres).

1.2.11.5 Evaluación de exención al código de conducta del operador de registro

• Condicional

El Código de conducta del operador de registro (incluido en la Especificación 9 del Acuerdo de Registro) es un conjunto de pautas para el operador de registro relacionadas con ciertas operaciones limitadas de un registro. Si un solicitante propone registrar todos los nombres de dominio en el gTLD exclusivamente para uso propio del operador de registro o para uso de sus afiliadas, y desea renunciar a la protección para sí mismo y sus afiliadas, la ICANN puede conceder 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 Cadena de caracteres de uso exclusivo (“Genéricos cerrados”) y el operador de registro cumpla con los criterios de exención (consultar la Sección 7.4 Evaluación de exención al código de conducta del operador de registro).

1.2.11.6 Evaluación de compromisos de los operadores de registro

• Condicional¹⁷

Como se describe en la Sección 7.8.3.2 Evaluación de compromisos de los operadores de registro, cada Compromiso voluntario de los registros propuesto por el solicitante y cada Política de registración para la comunidad del Acuerdo de Registro ("Política de registración para la comunidad") propuesta por el solicitante para un gTLD de la comunidad para su inclusión en el Acuerdo de Registro aplicable será evaluada por la ICANN y publicada durante un período de comentarios sobre solicitudes.

1.2.11.6.1 Evaluación de compromisos voluntarios de los operadores de registro

Cada Compromiso voluntario de los operadores de registro (RVC) propuesto se someterá a una evaluación de la ICANN. El objetivo de esta evaluación es determinar si el RVC propuesto cumple con todos los criterios de evaluación establecidos en la Sección 7.8.3.2 Evaluación de compromisos de los operadores de registro para la aprobación de la ICANN de incluir el compromiso en la Especificación 11 del Acuerdo de Registro Base.

1.2.11.6.2 Evaluación de políticas de registración para la comunidad

Las Políticas de registración para la comunidad, que todos los solicitantes de la comunidad deben proponer durante la presentación de la solicitud, están sujetas a la evaluación y aprobación de la ICANN antes de poder incluirse en la Especificación 12 del Acuerdo de Registro Base. Se puede consultar más información en la Sección 7.8.4 Políticas de registración para la comunidad.

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

• Condicional

El propósito de la Evaluación de elegibilidad como TLD que representa a una marca es confirmar que el solicitante cumple los criterios para la designación de un TLD que representa a una marca. Una designación satisfactoria dará lugar a que se agregue la Especificación 13 al Acuerdo de Registro del solicitante, siempre que el solicitante supere con éxito todas las etapas de la evaluación. Consultar la Sección 7.3 Evaluación de elegibilidad como TLD que representa a una marca.

Un solicitante de un TLD que representa a una marca que se encuentre en disputa tiene la opción de cambiar su cadena de caracteres y evitar procedimientos adicionales de resolución de controversias completando una Solicitud de cambio de una cadena de caracteres que representa a una marca, sujeto a los requisitos establecidos en la Sección 5.3 Solicitudes de cambio de una cadena de caracteres que representa a una marca.

1.2.11.8 Evaluación de cadenas de caracteres variantes

• Condicional

El solicitante que desee una o más cadenas de caracteres variantes asignables de un IDN principal solicitado o de un gTLD existente deberá justificar la necesidad de cada cadena de caracteres variante solicitada. Esta justificación será evaluada por un panel basándose en una norma general de razonabilidad. Consultar la Sección 7.6 Evaluación de cadenas de caracteres variantes para obtener más información. Las variantes se incluirán en la Especificación 14 del Acuerdo de Registro Base.

1.2.12 Preguntas aclaratorias

Duración prevista: Siete días para preguntas administrativas; 21 días para preguntas sustantivas

Durante cada Evaluación de solicitudes y solicitantes,¹⁸ el panel de evaluación respectivo podrá formular preguntas aclaratorias si requiere información adicional para completar su evaluación, si tiene la intención de reprobar a un solicitante, o si alguno de los comentarios sobre solicitudes que consideró puede tener un impacto en la evaluación de la solicitud. Los solicitantes tendrán siete días para responder a preguntas aclaratorias administrativas¹⁹ 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.²⁰

1.2.13 Publicación de informes de la Evaluación de solicitudes y solicitantes

Los informes de la Evaluación de solicitudes y solicitantes se compilarán después de que se completen todas las evaluaciones requeridas específicas de una solicitud y se publicarán de manera continua.²¹ Ciertos procesos, como los Pedidos de cambios en una solicitud, las controversias o las objeciones, pueden afectar los plazos de publicación de los informes.

1.2.14 Evaluación extendida e impugnación de la evaluación

Para determinadas evaluaciones, existe la posibilidad de solicitar una evaluación extendida o una impugnación de la evaluación, tal y como se describe a continuación. No hay tarifas condicionales asociadas a ninguno de los dos procesos.

1.2.14.1 Evaluación extendida

Los solicitantes que no puedan resolver problemas a través de preguntas aclaratorias pueden ser elegibles para ingresar a una evaluación extendida, que proporciona tiempo e interacciones adicionales para abordar inquietudes pendientes sobre una evaluación específica. Los solicitantes pueden recurrir a una evaluación extendida dentro de un plazo de 15 días posteriores a la notificación de sus resultados de la Evaluación de solicitudes y solicitantes. La evaluación extendida es realizada por el mismo conjunto de evaluadores que inicialmente realizaron la evaluación pertinente. Cuando corresponda, un panel de evaluación puede emitir preguntas aclaratorias adicionales como parte de la evaluación extendida.

Las siguientes evaluaciones pueden estar sujetas a una evaluación extendida:

Tabla 1-1: Evaluaciones sujetas a una evaluación extendida

1.2.14.2 Impugnación de la evaluación

El mecanismo de impugnación de la evaluación permite a los solicitantes impugnar el resultado de una evaluación basándose en alegaciones de errores de hecho, de procedimiento o del sistema en las validaciones automáticas realizadas por el TAMS que puedan haber dado lugar a un resultado incorrecto de la evaluación. Si bien los solicitantes pueden proporcionar evidencia documental de un error de hecho o de procedimiento percibido, no se les permite presentar ninguna información nueva que constituya un cambio sustancial a la solicitud original. En general, el mecanismo de impugnación no prevé preguntas aclaratorias.

El mecanismo de impugnación está sujeto a una evaluación de "revisión preliminar". El panel puede desestimar la impugnación basándose en uno o varios de los criterios siguientes:

• La impugnación no se presenta sobre uno de los fundamentos aceptados.

• La parte que presenta la impugnación no es el solicitante.

• No se proporcionan pruebas suficientes o no se proporciona ninguna prueba para respaldar la impugnación.

• La impugnación es inverosímil, claramente inventada o contraria al sentido común.

• El solicitante presenta impugnaciones duplicadas o repetidas por el mismo motivo para la misma evaluación.

• Otros hechos que puedan demostrar claramente que la impugnación es manifiestamente infundada o constituye un abuso del derecho de impugnación.

Consultar la Tabla 1-2: Evaluaciones que pueden ser impugnadas para obtener una descripción general de las evaluaciones que pueden ser impugnadas, la fecha límite para solicitarla y los motivos.

Tabla 1-2: Evaluaciones que pueden ser impugnadas

El Panel de impugnación comunicará el resultado de las validaciones de cadenas de caracteres previas a la presentación en un plazo de 5 días a partir de la presentación de la impugnación por parte de un solicitante. Para el resto de las evaluaciones que se indican en la tabla anterior, el Panel de impugnación comunicará el resultado en un plazo de 30 días a partir de la presentación de dicha impugnación por parte del solicitante.

Para obtener información más detallada sobre cada tipo de evaluación e impugnación, consultar las secciones cuyo enlace se incluye en la tabla anterior. Cada sección de evaluación proporciona detalles adicionales sobre el proceso de impugnación y sus resultados.

1.2.15 Contratación

Duración prevista: El solicitante debe completar la contratación en un plazo máximo de 90 días a partir de la fecha de la invitación a la contratación.

Un solicitante que completa exitosamente todas las etapas pertinentes que se describen en esta sección debe ejecutar un Acuerdo de Registro con la ICANN para ser elegible para la delegación de su cadena de caracteres solicitada (y cualquier cadena de caracteres variante, según corresponda) en la zona raíz del DNS. Los solicitantes que superen con éxito la Evaluación de solicitudes y solicitantes serán invitados a proporcionar información adicional para la contratación, incluido el signatario autorizado. En ese momento, los solicitantes también deben confirmar que las declaraciones y manifestaciones contenidas en la solicitud y complementadas a lo largo del proceso de solicitud (incluido cualquier documento o material escrito presentado en relación con la solicitud) siguen siendo veraces, precisas y completas en todos los aspectos sustanciales, tal y como se exige en la Sección 3.8 Pedidos de cambios en una solicitud y los Términos y condiciones de esta Guía (Apéndice 10).

En paralelo, la ICANN buscará la confirmación del RSP identificado de un solicitante de que reconoce los planes para apoyar a ese solicitante y gTLD en particular.

El Acuerdo de Registro Base (Apéndice 4) es el resultado de una amplia consulta con la comunidad. La ICANN solo considerará modificaciones al acuerdo en circunstancias extraordinarias, tales 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á. Los solicitantes que requieran negociar enmiendas limitadas al Acuerdo de Registro Base deberán proporcionar una justificación que respalde la necesidad de dichos cambios, junto con una versión del documento con los cambios resaltados que indique las modificaciones solicitadas. Los solicitantes deben presentar un pedido de negociación a la ICANN lo antes posible en el proceso y a más tardar 15 días posteriores a la fecha de su invitación a la contratación.

Según corresponda, un Acuerdo de Registro incluirá lo siguiente basándose en la respuesta del solicitante a las preguntas incluidas en la solicitud y los resultados de la evaluación:

• Los Compromisos en pos del interés público, incluidos los Compromisos voluntarios de los operadores de registro y las Medidas de protección, se incluyen en la Especificación 11.

• Las Políticas de registración para la comunidad se incluyen en la Especificación 12.

• La información sobre solicitudes de marca se incluye en la Especificación 13.

• La información sobre cadenas de caracteres variantes se incluye en la Especificación 14.

• Disposición especial relativa a las organizaciones intergubernamentales o entidades gubernamentales, incluida en el Artículo 7.

Salvo circunstancias extraordinarias, se requiere que los solicitantes ejecuten el contrato dentro de un plazo de 90 días a partir del momento en que son invitados a iniciar el proceso de contratación.

1.2.16 Después de la contratación

Esta sección Después de la contratación proporciona a los nuevos operadores de registro recursos para comprender los requisitos del lanzamiento y operación de sus gTLD.

Tras superar con éxito la evaluación y firmar un Acuerdo de Registro con la ICANN, la operación del gTLD por parte del que fuera solicitante del nuevo gTLD se regirá por este Acuerdo de Registro, que describe las obligaciones entre el operador del registro y la ICANN. Los operadores de registro deben completar actividades de incorporación para varios sistemas y procesos de la ICANN de conformidad con el Acuerdo de Registro aplicable. Esta incorporación es fundamental para garantizar el cumplimiento de las obligaciones contractuales y responsabilidades operativas. Los nuevos operadores de registro deben delegar su TLD dentro del plazo de un año a partir de la fecha de ejecución del Acuerdo de Registro, con excepción de lo que se describe en la Sección 2.19 del Acuerdo de Registro Base.

Los nuevos operadores de registro son remitidos al sitio web del Programa de Nuevos gTLD, que proporcionará recursos exhaustivos para ayudar a los operadores de registro emergentes a orientarse en las interacciones con la ICANN y comprender sus obligaciones contractuales. Para obtener información adicional sobre la delegación de gTLD y el cronograma para su finalización, consultar la Sección 1.2.15 Contratación y el Apéndice 4 Acuerdo de Registro Base.

1.2.17 Procedimientos de resolución de disputas después de la delegación

Los procedimientos para la resolución de disputas con posterioridad a la delegación proporcionan una vía para presentar reclamos contra la conducta de un operador de registro.

En ocasiones, se puede requerir que una parte reclamante adopte medidas específicas para resolver sus cuestiones antes de presentar un reclamo formal. La ICANN o proveedores externos cualificados administran estos procedimientos de resolución de disputas. Un panel de expertos, si se designa, determina si un operador de registro está en falta y, de ser así, recomienda soluciones a la ICANN.

Los operadores de registro deben cumplir con los mecanismos de resolución de disputas que se describen en el Acuerdo de Registro Base y aceptar someterse a cualquier decisión de la ICANN o del panel de expertos, así como implementar y cumplir cualquier medida correctiva impuesta posteriormente por la ICANN.

En la actualidad, existen tres procedimientos para la resolución de disputas con posterioridad a la delegación:

1. Procedimiento para la resolución de disputas en materia de compromisos de interés público (PICDRP): El PICDRP se utiliza para abordar reclamos relacionados con un operador de registro que podría no estar cumpliendo con uno o más de los Compromisos en pos del interés público (PIC) o Compromisos voluntarios de los operadores de registro (RVC) en su Acuerdo de Registro. 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 para obtener más detalles sobre los PIC y los RVC.

2. Procedimiento para la resolución de disputas por restricciones de registración (RRDRP): El RRDRP aborda circunstancias en las cuales un operador de registro de un nuevo gTLD de una comunidad no cumple presuntamente con las restricciones en materia de registraciones según lo establecido en el Acuerdo de Registro. Un gTLD de una comunidad se opera en beneficio de una comunidad claramente delimitada. Consultar la Sección 5.4 Evaluación con prioridad de la comunidad para obtener más detalles sobre Solicitudes de la comunidad.

3. Procedimiento para la resolución de disputas por marcas comerciales con posterioridad a la delegación (TM-PDDRP) El TM-PDDRP generalmente se ocupa de la presunta complicidad en el incumplimiento de normativas en materia de marcas comerciales en el primer o segundo nivel de un gTLD. Entre los tres procedimientos de resolución de disputas con posterioridad a la delegación, solo el TM-PDDRP está específicamente destinado a abordar cuestiones relacionadas con marcas comerciales concernientes a operadores de registro. Consultar la sección Mecanismos de protección de derechos²³ para obtener más detalles sobre los requisitos de mecanismos de protección de derechos para todos los gTLD.

Para obtener más información sobre el alcance de los procedimientos, los roles de todas las partes y el proceso de adjudicación con respecto a estos procedimientos para la resolución de disputas con posterioridad a la delegación, consultar las Preguntas frecuentes en el sitio web del Programa de Nuevos gTLD,²⁴ así como la página de información de Mecanismos de protección de derechos (RPM) y Procedimientos de resolución de disputas (DRP).

1.3 Generalidades del proceso

Figura 1-1: Generalidades del proceso

1.4 Materiales publicados

La ICANN publicará los siguientes materiales relacionados con las solicitudes presentadas en el sitio web del Programa de Nuevos gTLD:

• Partes públicas de las solicitudes

• Número de prioridad asignado

• Estado y etapa de la solicitud

• Solicitudes con Alertas tempranas de miembros del GAC y Asesoramiento consensuado del GAC

• Estados de objeciones y apelaciones

• Comentarios sobre solicitudes

• Cambios a la parte pública de la solicitud debido a Pedidos de cambios en una solicitud

• Informes de resultados de evaluación (Cadena, Solicitud y solicitante, y CPE)

• Informe de evaluación inicial de colisiones de nombres

• Informe de delegación temporaria

• Plan de mitigación de alto riesgo e informe

• Informes de Evaluación extendida e Impugnación de la evaluación

• Preguntas aclaratorias (CQ) y Respuestas a las CQ del solicitante para las partes públicas de las solicitudes

• Lista de conjuntos de solicitudes controvertidas

• Estado de elección de la CPE

• Estado y resultados de subastas

1.5 Plazos del ciclo de vida

La tabla a continuación proporciona una estimación general de la duración de cada proceso en meses, según la cantidad de solicitudes presentadas. Las duraciones indicadas se refieren a una solicitud simple y estándar parte del primer lote de prioridad, no sujeta a Asesoramiento consensuado del GAC, objeciones o evaluaciones condicionales, que no esté en disputa y que no tenga ningún otro problema. Las solicitudes en lotes de prioridad posteriores pueden ser retenidas hasta su tiempo de procesamiento designado. Los solicitantes con solicitudes que requieren evaluaciones condicionales o que están sujetas a Asesoramiento consensuado del GAC o tienen solicitudes más complejas pueden verse afectados por plazos de tramitación más largos.

Tabla 1-3: Duración estimada de cada proceso

*La duración estimada para completar la incorporación y delegación se proporcionará posteriormente.

La tabla a continuación proporciona una estimación de la duración de algunos de los procesos condicionales a los que puede estar sujeta una solicitud.

Tabla 1-4: Duración estimada de algunos procesos condicionales

Estas tablas no cubren todos los escenarios posibles, y varios factores pueden influir en la duración de cada proceso. Las métricas sobre los diversos procesos se publicarán en el sitio web del Programa de Nuevos gTLD²⁷ y se actualizarán de forma periódica.