Módulo 3 Presentación de solicitudes

En este módulo se describen los principales pasos y las expectativas para presentar una solicitud de un nuevo gTLD, y se destacan aspectos clave como el plazo y los límites para la presentación, el proceso de solicitud de reserva, y la colocación de solicitudes en fila de espera y priorización.

El Módulo 3 también abarca otros temas esenciales, incluyendo:

• Estabilidad del DNS y Reglas para la Generación de Etiquetas para la Zona Raíz.

• Tipos de solicitudes y cadenas de caracteres.

• Tarifas y pagos.

• Pedidos de cambios.

Esta información está diseñada para brindar claridad sobre el proceso de presentación de solicitudes, lo que permite a los solicitantes prepararse de manera adecuada y transitar dicho proceso con confianza.

3.1 Presentación de una solicitud

3.1.1. 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 descritos en la Sección 3.8 Pedidos de cambios en una solicitud, que sólo pueden presentarse después del Día de confirmación de las cadenas de caracteres.

3.1.2 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 consultar 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.

3.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 enumeradas en el Apéndice 1 Preguntas incluidas en la solicitud y se les pedirá que presenten los documentos de respaldo que se les soliciten. El sistema validará que todos los campos obligatorios incluyan una respuesta antes de que los solicitantes puedan presentar una solicitud.

Si un solicitante tiene la intención de presentar más de una solicitud, el TAMS aceptará la información de la organización y financiera solo una vez al momento de crearse el registro de la organización en el TAMS. Para cualquier solicitud adicional que el solicitante desee presentar, el TAMS solo le pedirá que introduzca la información de la solicitud de gTLD.

Esto significa que la información financiera y de la organización correspondiente a la entidad solicitante se bloqueará una vez presentada la primera solicitud. Los solicitantes deben asegurarse de que la información de la organización sea correcta y de que la información financiera refleje todas las solicitudes que el solicitante tiene intención de presentar antes de enviar la primera solicitud.

Una vez enviada, la solicitud no podrá modificarse durante el periodo para la presentación de solicitudes. Una vez transcurrido el período para la presentación de solicitudes, el solicitante tendrá la oportunidad de introducir cambios en las solicitudes según los procedimientos que se describen en la Sección 3.8 Pedidos de cambio en una solicitud.

3.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.²

3.1.5 Selección de cadenas de caracteres de reemplazo

Para reducir potencialmente los casos de controversias por cadenas de caracteres, 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.

3.1.6 Tipos de solicitudes y cadenas de caracteres

En esta sección se describen los distintos tipos de solicitudes de nuevos gTLD: general, de la comunidad, nombre geográfico, nombre reservado, marca, IDN, variante de un gTLD existente, variante de un IDN principal de un nuevo gTLD, solicitudes de gobiernos, OIG y solicitantes que reciben apoyo (tipos de solicitudes de solicitantes de gobierno/OIG y solicitante que recibe Apoyo para solicitantes). Cada tipo puede tener requisitos y pasos de procesamiento únicos que el solicitante debe consultar a la hora de presentar una solicitud para estos diferentes tipos en la Sección 7.1 Tipos de cadena de caracteres y solicitudes.

La tabla siguiente ofrece un resumen general de los distintos tipos de solicitudes, así como de los ámbitos específicos en los que pueden aplicarse requisitos diferentes. Para obtener información detallada, consultar las secciones cuyos enlaces aparecen en la Tabla 3-1.

Tabla 3-1: Reseña general de los tipos de solicitudes y principales diferencias de su gestión

3.1.7 Cadenas de caracteres de uso exclusivo (Genéricos cerrados)

En el Apéndice 4 Acuerdo de Registro Base, se define como “genérica a “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 de bienes, servicios, grupos, organizaciones o cosas específicas y distintas de los demás”. En el Acuerdo de Registro Base, los gTLD "de uso exclusivo" se definen como aquellos que imponen criterios de elegibilidad que limitan las registraciones exclusivamente a una sola persona o entidad y/o a las "afiliadas" de dicha persona o entidad. Los operadores de registro tienen prohibido operar gTLD genéricos de forma exclusiva. Eso se suele conocer como prohibición respecto de los TLD “genéricos cerrados”. Algunos ejemplos de cadenas de caracteres que podrían considerarse genéricas son .árbol y .banana, pero cabe señalar que estos ejemplos también podrían considerarse TLD que representan a una marca.

La Junta Directiva de la ICANN ha resuelto que no se permitirán las solicitudes de cadenas de caracteres genéricas cerradas, 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. Durante el proceso de presentación de solicitudes, cada solicitante deberá declarar que no solicita ni pretende operar una cadena de caracteres genérica cerrada.

Los TLD que representan una marca no describen una clase general de bienes, servicios, grupos, organizaciones o cosas y, por lo tanto, no están sujetos a la prohibición respecto de los genéricos cerrados. En la Sección 9.3 de la Especificación 13 del Acuerdo de Registro Base, ⁹ se indica que “los TLD que representan a una marca son aquellos en los que: (ii) sólo el Operador de Registro, sus afiliadas o los licenciatarios de marcas comerciales son registratarios de los nombres de dominio en el TLD y controlan los registros del DNS asociados a los nombres de dominio en cualquier nivel en el TLD”. Consultar la Sección 7.3 Evaluación de elegibilidad como TLD que representa a una marca para obtener más información.

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

3.1.8.1 Identificación de nombres bloqueados

El sistema cuenta con controles integrados que se activan antes de permitir que un solicitante continúe con su solicitud. Cuando un solicitante ingresa el nombre de la cadena solicitada, el sistema comprueba automáticamente si la cadena elegida por el solicitante, incluidas sus variantes, aparece en la lista de nombres bloqueados, tal como se describe en la Sección 7.2.1 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.

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

3.1.8.3 Revisión de estabilidad del DNS

Las cadenas de caracteres de nuevos gTLD no deben afectar negativamente a la seguridad o estabilidad del DNS. La Revisión de estabilidad del DNS determina si una cadena de caracteres de un gTLD solicitada cumple los estándares del DNS y otras normas pertinentes. Esta evaluación incluye la comprobación de la conformidad de la cadena de caracteres con los requisitos técnicos especificados para las cadenas de caracteres de gTLD. No se dará curso a las solicitudes a menos que se hayan completado con éxito estas comprobaciones.

La cadena de caracteres de gTLD solicitada debe cumplir los siguientes requisitos:

1. La etiqueta ASCII debe ser una NR-LDH¹⁰ o una etiqueta-A válida como se describe en la sección 2.3 de la RFC 5890¹¹.

2. La etiqueta NR-LDH debe constar íntegramente de letras (caracteres alfabéticos a-z) de conformidad con la sección 2.1 de la RFC 1123.¹²

3. Las cadenas de caracteres de IDN gTLD deben cumplir con IDNA2008¹³ (RFC 5890-5893) y todas las RFC sobre el seguimiento de normas que actualicen IDNA2008.

4. Las cadenas de caracteres de IDN gTLD deben cumplir con las Reglas para la Generación de Etiquetas para la Zona Raíz aplicables.¹⁴ Consultar la Sección 3.1.8.3.1 Reglas para la Generación de Etiquetas para la Zona Raíz para más información sobre las RZ-LGR y el procesamiento de solicitudes.

5. Si una cadena de caracteres de gTLD se clasifica como cadena variante de un gTLD existente en la zona raíz o de un gTLD principal solicitado, debe ser una cadena variante asignable de ese gTLD principal (consultar la Sección 3.1.9 Nombres de dominio internacionalizados). Las RZ-LGR son la única fuente para calcular las cadenas de caracteres variantes del gTLD principal y sus valores de disposición, ya sean asignables o bloqueados.

Las verificaciones descritas anteriormente se incorporan y aplican a través del TAMS. Esto significa que estas comprobaciones se producirán automáticamente cuando el solicitante introduzca la cadena de caracteres en su solicitud.

Si una cadena de caracteres no supera una de las comprobaciones descritas anteriormente, el solicitante recibirá un mensaje de error en el que se explicarán los problemas detectados y no se permitirá proceder con la solicitud.

Se debe tener en cuenta que, en la Sección 7.7 Colisión de nombres y la Sección 2.5 Seguridad y estabilidad, se describen otras cuestiones y requisitos con relación a las revisiones de estabilidad y seguridad.

3.1.8.3.1 Reglas para la Generación de Etiquetas para la Zona Raíz

3.1.8.3.1.1 Versión aplicable de las RZ-LGR y códigos de escritura e idiomas compatibles

Los IDN son importantes para hacer posible una Internet multilingüe. A fin de garantizar un DNS seguro y estable, se desarrollaron Reglas para la Generación de Etiquetas para la Zona Raíz (RZ-LGR)¹⁵ con el propósito de determinar la validez de las cadenas de caracteres principales solicitadas en diferentes códigos de escritura, así como sus cadenas variantes asignables.

El DNS es para los identificadores, no para escribir un idioma o su literatura, por lo tanto, no se espera que las RZ-LGR admitan toda la gama de expresión de un lenguaje natural en el DNS, ni que cualquier cadena de caracteres generada por las RZ-LGR deba constituir una palabra en un idioma.

Se utilizará la versión 6 de las RZ-LGR, que integra los códigos de escritura y sistemas de escritura que se indican a continuación¹⁶ a partir de las propuestas elaboradas por los paneles de generación de códigos de escritura basados en la comunidad (Paneles de generación) e integradas por una lista de revisores expertos (Panel de integración).

árabe, armenio, bengalí, chino (han), cirílico, devanagari, etíope, georgiano, griego, gujarati, gurmukhi, hebreo, japonés (hiragana, katakana y kanji [Han]), kannada, jemer, coreano (hangul y hanja [Han]), lao, latino, malayalam, birmano, oriya, sinhala, tamil, télugu y tailandés.

Las RZ-LGR contienen LGR distintas para cada código o sistema de escritura. Un sistema de escritura puede contener más de un código de escritura, por ejemplo, el sistema de escritura japonés consta de los códigos de escritura hiragana, katakana y kanji (han).

3.1.8.3.1.2 Solicitudes de códigos de escritura no compatibles

Las RZ-LGR sólo validarán cadenas de caracteres en códigos de escritura o sistemas de escritura integrados en ellas. Los solicitantes no podrán presentar una solicitud para una cadena de caracteres en un código de escritura no integrado en la versión aplicable de las RZ-LGR.

En dicho caso, el solicitante potencial deberá trabajar primero con la comunidad que utiliza el código de escritura para integrar el código de escritura pertinente en las RZ-LGR, siguiendo el Procedimiento de las RZ-LGR¹⁷. La ICANN apoyará activamente este proceso. El solicitante potencial puede iniciar este proceso con la ICANN enviando un correo electrónico a globalsupport@icann.org cuando lo desee. El solicitante podrá presentar su solicitud en un período de presentación de solicitudes posterior, si el código de escritura correspondiente ha sido integrado y puesto a disposición en la versión aplicable de las RZ-LGR.

3.1.8.3.1.3 Elección de cadenas de caracteres principales o variantes mediante las RZ-LGR

La cadena de caracteres principal es la cadena de caracteres principal presentada por el solicitante, que debe ser válida según el cálculo de las RZ-LGR. Las cadenas variantes de la cadena de caracteres principal también se calculan mediante las RZ-LGR, marcadas como cadenas variantes asignables y bloqueadas. En conjunto, las cadenas de caracteres variantes asignables y bloqueadas de las principales se denominan conjunto de cadenas variantes. En el caso de un gTLD existente, se considera la cadena de caracteres principal con respecto a la cual se calculará y presentará su conjunto de cadenas variantes.

Si el solicitante solicita una cadena de caracteres principal, también podrá solicitar cadenas variantes asignables adicionales de la cadena principal como parte de una única solicitud, pero no podrá solicitar cadenas variantes bloqueadas de la cadena principal. Un operador de registro de un gTLD existente también puede solicitar cadenas variantes asignables del gTLD en una única solicitud, pero no puede solicitar cadenas variantes bloqueadas del gTLD.

La elección de la cadena de caracteres principal (cuando la principal no sea un gTLD existente) dentro de un conjunto de cadenas variantes no cambiará el total de cadenas de caracteres del conjunto de cadenas variantes, pero puede cambiar los subconjuntos de cadenas variantes asignables y bloqueadas dentro de este conjunto. Por lo tanto, al seleccionar la cadena de caracteres principal, los solicitantes deben tener en cuenta las cadenas variantes asignables y bloqueadas correspondientes que se crearán. La herramienta de LGR puesta a disposición por la ICANN en https://lgrtool.icann.org/ se puede utilizar para determinar las cadenas variantes asignables para una cadena de caracteres principal.

3.1.8.3.1.4 Resultados del uso de los cálculos de las RZ-LGR

Las RZ-LGR se aplicarán a una cadena de caracteres principal para determinar si dicha cadena es válida como TLD según las RZ-LGR.

Las RZ-LGR se aplicarán a una cadena variante de una cadena de caracteres principal o gTLD existente para:

1. Determinar si la cadena variante es válida como TLD según las RZ-LGR.

2. Determinar si se trata de una cadena variante de la cadena de caracteres principal o del gTLD existente identificado por el solicitante.

3. Determinar si se trata de una cadena variante asignable de la cadena de caracteres principal o del gTLD existente.

Las cadenas de caracteres que combinan puntos de código en LGR para diferentes códigos de escritura pueden ser marcadas como no válidas.

3.1.8.4 Impugnaciones a las validaciones de cadenas de caracteres previas a la presentación

Cuando un solicitante considere que se le está impidiendo presentar su solicitud o que debe aportar documentación adicional porque las validaciones de cadenas de caracteres previas a la presentación se han aplicado incorrectamente o se han codificado de manera errónea, tendrá la oportunidad de presentar una impugnación a más tardar 14 días antes del cierre del período para la presentación de solicitudes¹⁸, como se describe detalladamente a continuación:

• Identificación de nombres bloqueados: Un error del sistema en el proceso automatizado de identificación de nombres bloqueados dio lugar a que la cadena de caracteres de un solicitante se clasificara incorrectamente como Nombre bloqueado. Debido a ello, el solicitante no pudo proceder con su presentación. Consultar la Sección 3.1.8.1.

• Identificación de nombres reservados: 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. En consecuencia, el solicitante solo pudo continuar con la presentación aportando la documentación de respaldo requerida, tal como se especifica para las excepciones de nombres reservados. Consultar la Sección 3.1.8.2.

• Revisión de estabilidad del DNS: Un error del sistema en el cálculo de la herramienta automatizada de Revisión de estabilidad del DNS y el error del sistema identificado hicieron que el solicitante no superara la Revisión de estabilidad del DNS. Debido a ello, el solicitante no pudo proceder con su presentación. Este mecanismo de impugnación no se aplica a los códigos de escritura no compatibles con las RZ-LGR. Consultar la Sección 3.1.8.3 y la Sección 3.1.8.3.1.2 Solicitudes de códigos de escritura no compatibles.

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.

3.1.9. Nombres de dominio internacionalizados

Los Nombres de dominio internacionalizados (IDN) son nombres de dominio representados por caracteres distintos de los caracteres ASCII (letras a-z, para los dominios de alto nivel). Tales nombres de dominio se forman utilizando caracteres de un código de escritura distinto de ASCII (por ejemplo, árabe o chino).

La ICANN prevé un conjunto diverso de solicitudes para los nuevos gTLD, incluidos los IDN, lo que creará un importante potencial de nuevos usos y beneficios para los usuarios de Internet de todo el mundo, además de fomentar la elección y la inclusión digital.

3.1.9.1 Reglas para los IDN y sus variantes

Un IDN solicitado debe cumplir con IDNA2008¹⁹ (RFC 5890-5893²⁰) y todos sus sucesores. El IDN también debe cumplir con la versión aplicable de las RZ-LGR. Consultar la Sección 3.1.8.3.1 Reglas para la Generación de Etiquetas para la Zona Raíz.

Un IDN puede representarse en caracteres Unicode (denominados etiqueta-U) y su asignación ASCII equivalente prefijada por "xn--" (denominada etiqueta-A) según IDNA2008. Los IDN solicitados (en formato de etiqueta-U) deben tener más de un carácter. Esto significa que la etiqueta-U debe tener al menos dos puntos de código con el valor de Categoría general²¹ “L” tal como se define en el estándar Unicode. Los puntos de código con el valor de Categoría general “M” no se tendrán en cuenta a efectos de determinar si un IDN solicitado es de un solo carácter. Para conocer los otros requisitos de las cadenas de caracteres, también se puede consultar la Sección 3.1.8.3 Revisión de estabilidad del DNS.

Las RZ-LGR son la única fuente para calcular las cadenas de caracteres variantes y sus valores de disposición (asignables o bloqueados) para todos los gTLD existentes y todas las cadenas de caracteres principales solicitadas.

La herramienta de LGR puesta a disposición por la ICANN puede utilizarse para determinar las cadenas de caracteres variantes asignables para un gTLD principal o una cadena de caracteres solicitada.²²

3.1.9.2 Presentación de solicitudes de IDN

Un IDN solicitado que cumpla con los requisitos obligatorios para cadenas de caracteres, incluidos el IDNA 2008 y las RZ-LGR, puede presentarse a través del TAMS. Cuando el cálculo de las RZ-LGR durante la comprobación algorítmica considere un gTLD solicitado como "no válido" o "bloqueado" (por ejemplo, en caso de que la cadena de caracteres solicitada sea una cadena variante), dicha solicitud de cadena de caracteres que no cumple con los requisitos no será aceptada por el sistema de presentación de solicitudes. Consultar la Sección 3.1.8.3 Revisión de estabilidad del DNS para una lista más exhaustiva de las comprobaciones que se realizan. El solicitante puede objetar el cálculo de las RZ-LGR mediante el sistema de presentación de solicitudes. Consultar la Sección 3.1.8.3.1Reglas para la Generación de Etiquetas para la Zona Raíz.

3.1.9.2.1 Presentación de solicitudes de un nuevo IDN principal y sus cadenas de caracteres variantes

Un solicitante puede solicitar un nuevo IDN principal junto con una o más de sus cadenas de caracteres variantes asignables. Estas cadenas variantes sólo se asignarán al mismo solicitante que el IDN gTLD principal y deberán compartir el mismo proveedor de servicios de registro de back-end mientras estén delegadas.

Se pueden solicitar cadenas de caracteres variantes asignables a partir del conjunto generado mediante las RZ-LGR. Una solicitud de una cadena de caracteres variante asignable no puede preceder a una solicitud de su IDN gTLD principal. Un IDN gTLD principal y cualquiera de sus cadenas de caracteres variantes asignables que se soliciten en la misma ronda deben presentarse a través de una única solicitud. Tras una evaluación satisfactoria, el gTLD principal y sus cadenas de caracteres variantes asignables solicitadas se asignarán al mismo operador de registro a través de un Acuerdo de Registro. Un solicitante no puede solicitar una cadena de caracteres variante bloqueada del nuevo IDN principal, según lo calculado por las RZ-LGR. Consultar la Sección 3.3 Tarifas y pagos para obtener información detallada sobre las tarifas de solicitud de cadenas de caracteres variantes asignables.

Una vez solicitado el IDN gTLD principal, no puede cambiarse, excepto en el caso de que la cadena de caracteres principal solicitada de una solicitud de IDN gTLD que representa a una marca que se haya puesto en controversia (consultar la Sección 5.3 Solicitud de cambio de una cadena de caracteres de TLD que representa a una marca).²³

Tras la presentación de una solicitud, el solicitante puede retirar cualquiera de las cadenas de caracteres variantes solicitadas de esa solicitud presentando un Pedido de cambios en una solicitud (Sección 3.8), pero no puede agregar ninguna otra cadena de caracteres variante asignable no solicitada originalmente en esa solicitud. Si un solicitante retira su solicitud de un IDN gTLD principal, también se retirarán todas las cadenas de caracteres variantes solicitadas.

3.1.9.2.2 Presentación de solicitudes de cadenas de caracteres variantes de gTLD existentes

Un solicitante sólo puede solicitar cadenas de caracteres variantes de un gTLD existente si es la misma persona jurídica que el operador de registro del gTLD existente. Todas las cadenas de caracteres variantes deben compartir el mismo proveedor de servicios de registro de back-end que el gTLD existente mientras estén delegadas. El proveedor de servicios de registro de back-end debe ser aprobado a través del Programa de Evaluación de RSP.²⁴

Las cadenas de caracteres variantes asignables de un gTLD existente pueden solicitarse a partir del conjunto generado mediante las RZ-LGR y deben presentarse en una única solicitud. Tras una evaluación satisfactoria, las cadenas de caracteres variantes asignables solicitadas se asignarán al operador de registro del gTLD existente. El operador de registro deberá realizar la transición al Acuerdo de Registro Base de la Ronda de 2026, y el gTLD existente y todas las cadenas variantes se asignarán a través de un Acuerdo de Registro. Un solicitante no puede solicitar una cadena de caracteres variante bloqueada de un gTLD existente, según lo calculado por las RZ-LGR. Consultar la Sección 3.3 Tarifas y pagos para obtener información detallada sobre las tarifas de solicitud de cadenas de caracteres variantes asignables.

Tras presentar una solicitud, los solicitantes pueden retirar cualquier cadena de caracteres variante solicitada, pero no pueden agregar ninguna otra cadena variante asignable no solicitada originalmente en esa solicitud.

3.1.9.3 Requisitos y procesamiento

3.1.9.3.1 Priorización en el procesamiento de cadenas de caracteres variantes de gTLD existentes

Como excepción única, las solicitudes de cadenas de caracteres variantes asignables de gTLD existentes de la Ronda de 2012 recibirán prioridad de procesamiento sobre todos los demás solicitantes de nuevos gTLD, incluidos los solicitantes de IDN que decidan participar en el sorteo de priorización. Consultar la Sección 3.7 Orden de procesamiento de solicitudes y sorteo de priorización.

3.1.9.3.2 Varios solicitantes de la misma cadena de caracteres principal o sus cadenas variantes

Si diferentes solicitantes solicitan cadenas de caracteres del mismo conjunto de cadenas de caracteres variantes, dichas solicitudes se colocarán en controversia y sólo se seleccionará a un solicitante mediante el proceso de resolución de controversias. Esto significa que las cadenas de caracteres principales solicitadas y sus cadenas variantes asignables solicitadas participarán como un conjunto en cualquier mecanismo de resolución de controversias, es decir, Evaluación con prioridad de la comunidad (Sección 5.4) o Subasta de nuevos gTLD de la ICANN (Sección 5.6) (consultar el Módulo 5 Resolución de conjuntos de solicitudes controvertidas).

Cualquier solicitud de una cadena de caracteres variante asignable de un gTLD existente será rechazada si la presenta un solicitante que no sea el operador de registro de ese gTLD existente.

3.1.10 Selección del proveedor de servicios de registro

Los solicitantes deben especificar los proveedores de servicios de registro (RSP) que prestarán los servicios de registro críticos si su solicitud pasa a la delegación. La lista de RSP evaluados puede consultarse en la página de Solicitudes de proveedores de servicios de registro (RSP).²⁵

Los solicitantes 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 RSP.

Cada RSP sólo debe evaluarse una única vez, independientemente del número de gTLD a los que preste servicio y para los que reciba la cualificación para prestar servicios de registro específicos.

3.1.10.1 Expectativas para la selección del RSP al presentar una solicitud

Se recomienda a los solicitantes que identifiquen sus RSP y los servicios de registro pretendidos al presentar su solicitud para evitar posibles demoras en el procesamiento. No obstante, un solicitante también puede presentar la solicitud sin especificar los RSP, y optar por hacerlo justo antes de la evaluación de solicitantes y solicitudes.

Se recomienda una selección temprana de RSP y servicios de registro, idealmente durante la preparación, ya que para los solicitantes puede ser importante colaborar estrechamente con los RSP seleccionados durante el período para la presentación de solicitudes a fin de completar correctamente estas partes de la solicitud.

Si un solicitante no ha identificado un RSP que cubra las funciones de registro críticas mínimas requeridas en el momento de los Procedimientos de evaluación de solicitantes (Módulo 6) y los Procedimientos de evaluación de cadenas de caracteres y solicitudes (Módulo 7), se podrá seleccionar la Evaluación extendida para que el solicitante disponga de más tiempo para proporcionar la información solicitada de sus RSP elegidos.

El solicitante puede especificar o cambiar sus RSP seleccionados después de presentar la solicitud de gTLD a través del proceso de Pedido de cambios en una solicitud (Sección 3.8).

Durante el Proceso de contratación, la ICANN buscará la confirmación del RSP identificado por un solicitante en relación a su reconocimiento de los planes para dar apoyo a ese solicitante y al gTLD o a los gTLD en particular.²⁶

3.1.10.2 Funciones de registro y tipos de RSP

El Acuerdo de Registro Base requiere que los operadores de registro proporcionen apoyo a las siguientes funciones críticas de registro: Sistema de Nombres de Dominio (DNS), Extensiones de Seguridad del Sistema de Nombres de Dominio (DNSSEC), Protocolo de Aprovisionamiento Extensible (EPP), Protocolo de Acceso a los Datos de Registración de Nombres de Dominio (RDAP) y Custodia de datos. Existen cuatro tipos de RSP, cada uno de los cuales ofrece un conjunto de funciones únicas necesarias para la operación de las funciones críticas del registro:

1. RSP principales, que operan la base de datos de registro de un gTLD, custodian los datos de registración de nombres de dominio y operan los servicios EPP y RDAP de un gTLD. Un gTLD sólo puede tener un RSP principal.

2. RSP del DNS, que operan uno o más servidores del DNS para un gTLD. Un gTLD puede utilizar varios RSP del DNS.

3. RSP de DNSSEC, que realizan las operaciones criptográficas necesarias para las DNSSEC. Un gTLD sólo puede tener un RSP de DNSSEC.

4. RSP de representación (proxy), que realiza la validación de registración para cumplir con la legislación local aplicable en una jurisdicción determinada. Se trata de un servicio de registro adicional opcional que debe ser aprobado por la ICANN en el Programa de Evaluación de los RSP.²⁷ Un gTLD puede utilizar varios RSP de representación (proxy), cada uno de los cuales proporciona acceso a una jurisdicción diferente.

Una organización puede ser evaluada para uno o varios tipos de RSP en el Programa de Evaluación de los RSP.²⁸

Durante el proceso de presentación de solicitudes, se pedirá al solicitante que proporcione los RSP que pretende utilizar y los servicios de registro adicionales, si los hubiera, que pretende ofrecer en los gTLD propuestos. Como mínimo, el solicitante debe proporcionar un RSP principal, un RSP de DNSSEC y un RSP del DNS.

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

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 un gran volumen de solicitudes impida a la ICANN procesar todas las solicitudes dentro del plazo establecido, la ICANN publicará un calendario actualizado tan pronto como sea posible.

3.3 Tarifas y pagos

Esta sección describe las tarifas que debe pagar el solicitante, incluidas las instrucciones de pago.

3.3.1 Tarifa de evaluación de gTLD

La tarifa de evaluación de gTLD se fija de modo que la ICANN pueda recuperar todos los costos aplicables asociados al Programa de Nuevos gTLD. Este enfoque garantiza que el Programa esté totalmente financiado y sea neutral en cuanto a ingresos, y no estará subvencionado por contribuciones de otras fuentes de financiación de la ICANN, incluidas las tarifas de operadores de registro y registradores de gTLD, y las contribuciones de ccTLD y los Registros Regionales de Internet. La ICANN ha estimado que los procesos de evaluación, contratación y delegación de la Ronda de 2026 continuarán aproximadamente hasta el 30 de junio de 2030, ²⁹ fecha en la que se prevé que todas las solicitudes presentadas hayan superado estas etapas del recorrido del solicitante (Módulo 1). La tarifa de evaluación de gTLD abarca todas las evaluaciones necesarias, incluida la evaluación extendida cuando corresponda, durante ese período.

La ICANN reconoce que pueden darse casos excepcionales que requieran la extensión de estos servicios para un número limitado de solicitudes más allá del plazo de junio de 2030.

La tarifa de evaluación de gTLD es de USD 227 000 por solicitud para todos los solicitantes, excepto las presentadas por solicitantes cualificados del Programa de Apoyo para Solicitantes (ASP) y las solicitudes de variantes que cumplan los criterios que se indican a continuación. 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. En el hipotético caso de que un solicitante de ASP aún esté esperando los resultados de la evaluación del ASP, es posible que el solicitante deba presentar una solicitud sin realizar el pago. La solicitud se colocaría en suspenso hasta que se haya determinado la tarifa de evaluación de gTLD correspondiente y se haya recibido el pago.

3.3.1.1 Tarifa de evaluación de gTLD para solicitudes con cadenas de caracteres variantes

3.3.1.1.1 Para solicitantes nuevos

La tarifa de evaluación de gTLD abarca una solicitud para un gTLD principal y hasta cuatro cadenas de caracteres variantes. Si un solicitante desea solicitar más de cuatro cadenas de caracteres variantes bajo una cadena principal, deberá abonar la tarifa de evaluación de USD 227 000 por cada variante asignable adicional más allá de la cuarta variante. Pueden aplicarse tarifas adicionales para Evaluaciones condicionales (consultar la Sección 3.3.2).

3.3.1.1.2 Para operadores de registro de gTLD existentes de la Ronda de 2012

En esta Ronda de 2026, un operador de registro de gTLD de la Ronda de 2012 podrá solicitar hasta cuatro cadenas de caracteres variantes de su gTLD existente con exención de su tarifa de solicitud como excepción única. Si solicita más de cuatro cadenas de caracteres variantes, pagará la tarifa de evaluación de gTLD completa por cada variante asignable adicional más allá de la cuarta variante. Pueden aplicarse tarifas adicionales para Evaluaciones condicionales (consultar la Sección 3.3.2).

3.3.1.2 Tarifa de evaluación de gTLD para solicitantes cualificados del Programa de Apoyo para Solicitantes

Los solicitantes cualificados del ASP recibirán una reducción del 75 al 85 % de la tarifa de evaluación de gTLD. Por lo tanto, la tarifa de evaluación de gTLD con descuento para un solicitante cualificado del ASP oscilará entre USD 34 500 y USD 56 750 (incluido el depósito de USD 2 500 presentado para confirmar la viabilidad financiera del ASP). El importe exacto dependerá del número final de solicitantes cualificados del ASP. La ICANN informará a los solicitantes cualificados del ASP que tienen derecho a un descuento mínimo del 75 %, y se espera que el importe final del descuento se comunique entre 12 y 16 semanas después de que finalice el plazo de presentación de solicitudes del ASP. Como se indica en la Sección 3.3.1.1 Tarifa de solicitud de gTLD para solicitudes con cadenas de caracteres variantes, el descuento en la tarifa de evaluación de gTLD incluye hasta cuatro cadenas variantes. Los solicitantes que reciben apoyo que soliciten más de cuatro cadenas de caracteres variantes deberán abonar la tarifa de evaluación de USD 227 000 por cada variante adicional a partir de la cuarta.

3.3.2 Evaluaciones condicionales

Además de las evaluaciones obligatorias cubiertas por la tarifa de evaluación de gTLD, existe una serie de evaluaciones condicionales que los solicitantes pueden elegir o a las que deben someterse para obtener un estado o exención específicos. Las tarifas de solicitantes para estas evaluaciones condicionales también se fijan para recuperar los costos asociados a la realización de estas evaluaciones, que pueden ser llevadas a cabo por proveedores externos o contar con el apoyo de los mismos. Esto garantizará que el Programa esté totalmente financiado y sea neutral en cuanto a ingresos, y no estará subvencionado por contribuciones de otras fuentes de financiación de la ICANN, incluidas las tarifas de operadores de registro y registradores de gTLD, y las contribuciones de ccTLD y los Registros Regionales de Internet. La selección de algunas de estas evaluaciones condicionales, como la revisión del Plan de mitigación de cadenas de caracteres de alto riesgo por colisión de nombres, sólo estará disponible más adelante en el proceso de evaluación. Para más detalles sobre lo que implica cada una de estas evaluaciones, consultar las secciones correspondientes que se indican en la Tabla 3-2:Evaluaciones condicionales y tarifas.

La ICANN notificará a los solicitantes el vencimiento de las tarifas de las evaluaciones condicionales. Puede ser poco después del cierre del período para la presentación de solicitudes o en el momento en que se realicen las evaluaciones. Si un solicitante no paga la evaluación condicional, dependiendo del tipo de evaluación condicional, se le puede pedir que presente un Pedido de cambio en una solicitud para eliminar esa sección de su solicitud y poder continuar. De lo contrario, las evaluaciones condicionales requeridas deben pagarse a tiempo para evitar la descalificación.³⁰

Para las evaluaciones marcadas con un asterisco (*), un solicitante cualificado del ASP recibirá el mismo porcentaje de reducción que recibió en la tarifa de evaluación de gTLD. Antes de conceder esta reducción, la ICANN solicitará que el solicitante del ASP verifique que sigue cumpliendo los requisitos para recibir más ayuda financiera (consultar también Términos y condiciones del ASP).³¹

La evaluación del Plan de mitigación de cadenas de caracteres de alto riesgo por colisión de nombres se ha marcado con dos asteriscos (**) y debe realizarse para cada cadena de caracteres que se haya identificado como cadena de alto riesgo. En consecuencia, deberá abonarse la tarifa condicional por cada cadena de caracteres del conjunto que haya sido identificada como cadena de alto riesgo.

Tabla 3-2: Evaluaciones condicionales y tarifas

3.3.3 Reembolsos

3.3.3.1 Reembolsos de tarifas de evaluación de gTLD

En determinadas circunstancias, los solicitantes pueden solicitar un reembolso parcial ³² de la tarifa de evaluación de gTLD originalmente abonada a la ICANN como parte del proceso de solicitud, tal como se indica a continuación. El importe del reembolso variará en función de la etapa del proceso en la que se solicite el retiro o en la que el estado de la solicitud cambie a Finalizado (consultar la Sección 3.9 Estados de las solicitudes).

El proceso de solicitud incluirá tres plazos de reembolso distintos, como se indica a continuación:

1. El primer plazo abarca desde la recepción de la tarifa de evaluación de gTLD del solicitante hasta diez días después del Día de confirmación de las cadenas de caracteres, durante el cual puede reembolsarse el 65 % de la tarifa de evaluación de gTLD abonada.

2. El segundo plazo abarca el período comprendido entre 11 días después del Día de confirmación de las cadenas de caracteres y el inicio de la Evaluación de solicitudes y del solicitante, durante el cual puede reembolsarse el 35 % de la tarifa de evaluación de gTLD abonada. Se notificará al solicitante cuándo se prevé que se inicie la Evaluación de solicitudes y del solicitante. Esta notificación se realizará tras la conclusión de la etapa de Evaluación de cadenas de caracteres o la resolución de conjuntos de solicitudes controvertidas, si corresponde.

3. El tercer plazo se extiende desde el inicio de la Evaluación de solicitudes o del solicitante hasta el momento en que el solicitante celebra un Acuerdo de registro con la ICANN, lo que permite un reembolso del 20 % de la tarifa de evaluación de gTLD abonada.

Para más detalles sobre estos plazos y qué evaluaciones y procesos se realizan durante los mismos, consultar el Módulo 1 Recorrido del solicitante.

Las tarifas correspondientes a las evaluaciones condicionales que se hayan abonado pero cuya evaluación aún no haya comenzado también podrán reembolsarse si el estado de la solicitud se clasifica como Retirada, No procederá o Finalizada.

3.3.3.1.1 Retiro del solicitante

Un solicitante puede retirar una solicitud en cualquier momento antes de la celebración del Acuerdo de Registro con la ICANN. El solicitante que opte por retirar su solicitud podrá solicitar el reembolso parcial de las tarifas abonadas a la ICANN, según se indica a continuación. La solicitud de reembolso debe realizarse como parte de la solicitud de retiro. Si el solicitante no solicita la devolución en ese momento, perderá el derecho a hacerlo más adelante.

3.3.3.1.2 Solicitudes finalizadas

La ICANN notificará a un solicitante si su solicitud no sigue adelante y se le ha asignado el estado Finalizada (consultar la Sección 3.9 Estados de las solicitudes). Una vez recibida esta notificación de la ICANN, el solicitante podrá solicitar un reembolso de acuerdo con el plazo de reembolso y el porcentaje de la tarifa de evaluación de gTLD susceptible de reembolso, tal como se indica a continuación. Para tener derecho al reembolso, el solicitante debe solicitarlo en un plazo de 90 días a partir de la fecha en que se le notifique el estado de Finalizada. Para aquellos solicitantes que no soliciten el reembolso en este plazo de 90 días se considerará que renuncian a la posibilidad de solicitarlo.

3.3.3.1.3 Reembolso como resultado de cambios materiales

Las solicitudes que se retiren debido a cambios con repercusiones materiales en la Guía para el Solicitante o en los procesos del Programa, tal como se definen en el Apéndice 6 Marco de previsibilidad, podrán optar por un reembolso. Como parte de su decisión sobre cualquier cambio que tenga una repercusión material en la Guía o en los procesos del Programa, la Junta Directiva de la ICANN confirmará la elegibilidad del solicitante para un reembolso, así como el porcentaje de la tarifa de evaluación de gTLD pagada que puede reembolsarse. El solicitante que retire su solicitud como consecuencia de tales cambios deberá presentar una declaración formal acompañada de documentación de respaldo que demuestre que el cambio: (1) alteró el estado de su solicitud, o (2) afectó al resultado de la evaluación de la solicitud, o (3) tuvo un impacto financiero u operativo no trivial en el solicitante, o (4) tuvo un impacto no trivial en el plazo de procesamiento y evaluación de su solicitud.³³ De conformidad con la Sección 3.3.3.1.1 Retiro del solicitante, cualquier solicitud de reembolso como consecuencia de dicho cambio deberá realizarse como parte de la solicitud de retiro.

3.3.3.1.4 Reembolsos para cadenas de caracteres identificadas como de alto riesgo por colisión de nombres

Un solicitante que decida retirar su solicitud en un plazo de 90 días desde que se determine que su cadena solicitada presenta un alto riesgo de colisión de nombres, y que no presente un Plan de mitigación de cadenas de caracteres de alto riesgo por colisión de nombres para su evaluación, podrá recibir un reembolso del 100 % de la tarifa de evaluación de gTLD abonada. Las solicitudes de cadenas de caracteres que se haya determinado que presentan un alto riesgo por colisión de nombres en una ronda anterior o que no hayan sido aprobadas como resultado de dicha determinación no podrán optar por este reembolso (.HOME, .CORP y .MAIL).

3.3.3.1.5 Reembolso cuando se elimina una cadena de caracteres debido al proceso de solicitud de IDN ccTLD

En los casos en los que un solicitante de gTLD haya obtenido el apoyo o la no objeción del gobierno o autoridad pública pertinente, pero la solicitud de gTLD no siga adelante debido a la similitud visual de la cadena de caracteres con una cadena solicitada en el proceso de solicitud de IDN ccTLD, se reembolsará íntegramente al solicitante de gTLD la tarifa de evaluación de gTLD. Este reembolso es aplicable siempre que la solicitud de gTLD se haya presentado antes de la publicación del ccTLD evaluado con éxito.

3.3.3.2 Reembolso por volumen de solicitudes

La ICANN aplicó un enfoque conservador al calcular la recuperación de los costos de implementación antes de recibir una única solicitud. Para garantizar la recuperación de los esfuerzos de implementación, la parte de la tarifa de evaluación de gTLD correspondiente a los gastos estimados de implementación se basó en la hipótesis de 1 000 solicitudes abonadas en su totalidad. Como resultado, un reembolso por volumen puede ser aplicable si se cumplen las dos condiciones que se indican a continuación: 1) Se reciben más de 1 000 solicitudes; y, 2) se han recuperado los costos de implementación de la Ronda de 2026.

Se pedirá a los solicitantes que indiquen en el momento de la presentación si desean recibir un reembolso por volumen, en caso de que sea aplicable.³⁴ Si el solicitante no selecciona la opción de recibir un reembolso por volumen, se considerará que ha renunciado a la posibilidad de recibir un reembolso por volumen. Después del Día de la revelación, la ICANN notificará a los solicitantes que optaron por el reembolso por volumen, en caso de que sea aplicable. El importe del reembolso por volumen se calculará en función del número de solicitudes recibidas y del importe final de los costos incurridos para la implementación. Solo las solicitudes pagas para la Ronda de 2026 podrán optar por reembolso por volumen; asimismo, las solicitudes del ASP que cumplan los requisitos recibirán un reembolso por volumen proporcional al importe de la tarifa abonada.

3.3.4 Tarifas exigidas en algunos casos

Los solicitantes pueden incurrir en tarifas y costos adicionales cuando se requieran pasos especializados en el proceso. En las secciones correspondientes a estos procesos especializados, se podrá encontrar información más detallada. Esas posibles tarifas adicionales incluyen:

• Costos de objeciones y apelaciones. Consultar la Sección 4.5.6 Costos de objeciones y apelaciones.

• Subastas. Consultar la Sección 5.6 Subasta de nuevos gTLD de la ICANN.

• Verificación de la documentación de Pedido de cambios de cadena de caracteres de TLD que representa a una marca. Consultar la Sección 5.3 Pedido de cambios de cadena de caracteres de TLD que representa a una marca.

3.3.5 Tarifas durante operaciones de registro

Los solicitantes que superen todos los procesos de solicitud y se conviertan en operadores de registro deberán abonar otras tarifas en calidad de operadores de registro. Dichas tarifas se describen en el Apéndice 4 Acuerdo de Registro Base e incluyen la tarifa fija de registro y las tarifas de transacción a nivel de registro.

3.3.6 Métodos de pago

Los pagos a la ICANN deben realizarse mediante transferencia bancaria, Cámara de Compensación Automatizada (ACH), pago SWIFT internacional u otro método aprobado por la ICANN para este servicio. No se aceptan cheques, dinero en efectivo ni pagos con tarjeta de crédito. Las instrucciones para efectuar el pago estarán disponibles en el TAMS.

Los pagos a los Proveedores de Servicios de Resolución de Disputas deben efectuarse de conformidad con las reglas del proveedor. Consultar la Sección 4.5.6 Costos de objeciones y apelaciones.

3.4 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, incluidas las cadenas de caracteres solicitadas pertinentes y cualquier cadena de caracteres variante y cadena de caracteres de reemplazo (si corresponde), en el sitio web del Programa de Nuevos gTLD ³⁵ 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. Las partes públicas de cada solicitud también estarán disponibles, junto con una lista de conjuntos de solicitudes controvertidas que contendrá las solicitudes de cadenas de caracteres idénticas. Ciertas comunicaciones y actividades estarán prohibidas a partir del Día de revelación para las solicitudes en proceso de resolución de controversias. Consultar la Sección 5.2.3.1 Comunicaciones y actividades prohibidas.

3.5 Período de reemplazo

Una vez que los solicitantes tengan acceso a la lista completa de cadenas de caracteres solicitadas, junto con cualquier cadena variante y cadena de reemplazo, tendrán la oportunidad de reemplazar su cadena de caracteres originalmente 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 Cadenas de caracteres de reemplazo.

3.6 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 actualizada de conjuntos de solicitudes controvertidas compuestos por solicitudes de 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.

3.7 Orden de procesamiento de solicitudes y sorteo de priorización

El número de prioridad asignado a una solicitud determina el orden general en el que la ICANN procesa las sucesivas etapas del proceso de solicitudes. Los números de prioridad también se utilizarán para determinar el orden general de publicación de los resultados de la evaluación y la celebración de los Acuerdos de Registro.³⁶

Una vez asignado, el número de prioridad de una solicitud no cambiará ni podrá transferirse entre solicitantes o solicitudes.

Se aplican reglas específicas a la priorización de solicitudes de IDN. Consultar la Sección 3.7.3 Priorización de solicitudes de IDN.

3.7.1 El sorteo de priorización

La prioridad de procesamiento de las solicitudes se establecerá mediante un evento de sorteo de priorización ("Sorteo"), que será un evento en vivo. Durante este evento, cada solicitud inscrita en el Sorteo tendrá un ticket físico en papel extraído manualmente del grupo de solicitudes participantes y se le asignará un número de prioridad.

La participación en el Sorteo es opcional. Para conocer cómo se asigna la prioridad de procesamiento a las solicitudes no inscritas en el Sorteo, consultar la Sección 3.7.4 Solicitudes no incluidas en el sorteo de priorización.

3.7.2 Participación en el sorteo

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. Los tickets para el Sorteo costarán USD 100 y deberán adquirirse en persona; no es posible la compra en línea. Para participar en el Sorteo, el solicitante, a través de un representante o apoderado designado, deberá comprar en persona un ticket por cada solicitud que el solicitante desee que se priorice.

Los solicitantes no pueden asistir al sorteo en persona, pero pueden seguir el evento en vivo virtualmente.

La ICANN tiene previsto anunciar todos los detalles del sorteo con al menos 30 días de antelación.

Sólo puede adquirirse un ticket por solicitud. Si un solicitante presenta varias solicitudes, deberá comprar un ticket distinto para cada solicitud que desee incluir en el Sorteo.

3.7.3 Priorización de solicitudes de IDN

Las solicitudes inscritas en el Sorteo se seleccionarán al azar en grupos de 500 hasta que todas las solicitudes hayan recibido un número de prioridad. Las solicitudes de IDN tendrán prioridad en el Sorteo de acuerdo con el siguiente orden y las siguientes reglas:

1. Solicitudes de IDN para cadenas de caracteres variantes asignables de IDN gTLD de 2012.

   • Como excepción para esta ronda de solicitudes, las solicitudes de cadenas de caracteres variantes asignables de IDN gTLD de la Ronda de 2012 se procesarán antes que otras solicitudes de nuevos gTLD, incluidas todas las demás solicitudes de cadenas principales de IDN que se hayan presentado en el Sorteo. Estas solicitudes se incluirán automáticamente en el Sorteo sin necesidad de que los solicitantes compren un ticket. Estas solicitudes se separarán y sortearán en primer lugar.

2. Una vez que se hayan sorteado todas las solicitudes de cadenas de caracteres variantes de IDN gTLD de 2012, si quedan menos de 125 solicitudes de IDN que opten por participar en el Sorteo:

   • todas las solicitudes de IDN se sortearán en primer lugar y se les asignará un número de prioridad antes que a las solicitudes que no sean de IDN.

3. No obstante, si quedan 125 o más solicitudes de IDN que opten por participar en el Sorteo:

   • El 25 % (125) del primer grupo de 500 solicitudes serán solicitudes de IDN, seleccionadas al azar como parte del Sorteo. Estas solicitudes de IDN seleccionadas se sortearán en primer lugar y se les asignará un número de prioridad.

   • El 75 % restante (375) de las solicitudes del primer grupo en recibir números de prioridad comprenderá tanto solicitudes de IDN como aquellas que no sean de IDN. Éstas se seleccionarán al azar del grupo restante de solicitudes que participen en el Sorteo, y se sortearán y priorizarán de forma aleatoria.

4. Por cada grupo subsiguiente de 500 solicitudes que decidan participar en el Sorteo:

   • El primer 10 % de cada grupo serán solicitudes de IDN seleccionadas al azar, sorteadas en primer lugar y priorizadas, continuando hasta que no quede ninguna solicitud de IDN.

   • Las solicitudes restantes de cada grupo se seleccionarán al azar del conjunto de solicitudes de IDN y que no sean del grupo de IDN restantes, sorteadas y priorizadas al azar.

3.7.4 Solicitudes no incluidas en el sorteo de priorización

Las solicitudes no inscritas en el Sorteo también serán sorteadas y se les asignará un número de prioridad en grupos de 500 solicitudes, pero sólo después de que todas las solicitudes inscritas en el Sorteo hayan sido sorteadas y priorizadas. Por ejemplo, si el número de prioridad final asignado mediante el Sorteo es 1 000, el número de prioridad más bajo que puede recibir una solicitud no inscrita en el Sorteo es 1 001.

En cada grupo de 500 solicitudes, el primer 10 % debe estar formado por solicitudes de IDN hasta que no quede ninguna por sortear. Las solicitudes restantes de cada grupo se seleccionarán al azar y se les dará prioridad entre el grupo restante de solicitudes de IDN y que no sean de IDN.

3.7.5 Excepciones al procesamiento según el número de prioridad

La ICANN intentará mantener el orden de prioridad entre las solicitudes que se procesen en cada etapa. Sin embargo, este orden puede verse afectado por la capacidad operativa y otros problemas relacionados con las solicitudes, como, por ejemplo, objeciones, asesoramiento consensuado del GAC, evaluaciones extendidas, conjuntos de solicitudes controvertidas, mecanismos de responsabilidad de la ICANN o suspensiones de procesamiento debidas a pedidos de cambios en una solicitud. Es probable que las actividades de procesamiento en curso se interrumpan hasta que finalicen estos procesos. Para evitar demoras y garantizar el progreso continuo de otras solicitudes, la ICANN procederá con la siguiente solicitud en el orden de prioridad. Una vez que la ICANN determine que se han resuelto los problemas que afectan a la solicitud en suspenso, reanudará el procesamiento de acuerdo con el número de prioridad asignado.

3.8 Pedidos de cambios en una solicitud

Esta sección describe el proceso para que los solicitantes actualicen la información inexacta o desactualizada de su solicitud y para realizar otros cambios, según sea necesario. Estos pedidos de cambios en una solicitud (ACR) son revisados por la ICANN sobre la base de los criterios de determinación de pedidos de cambios (consultar la Sección 3.8.2 Criterios para determinar pedidos de cambios) y están sujetos a la aprobación de la ICANN.

Los ACR sustanciales se publicarán durante un período de comentario de 30 días, como se describe en la Sección 3.8.3 Tipos de pedidos de cambios en una solicitud y procesos requeridos, lo que brindará al público en general la oportunidad de proporcionar sus aportes.

3.8.1 Descripción general de pedidos de cambios en una solicitud

Los solicitantes pueden pedir cambios o actualizaciones de la información de la organización, la información financiera o la información de la solicitud de gTLD durante todo el proceso de las solicitudes, desde el Día de confirmación de las cadenas de caracteres hasta la celebración del Acuerdo de Registro.

Si en cualquier momento durante el Programa la información presentada en respuesta a las Preguntas incluidas en la solicitud (Apéndice 1) o la información de la organización deja de ser verdadera, precisa o actualizada, por ejemplo, tras un acuerdo entre la ICANN y el solicitante como resultado de una evaluación, ³⁷ el solicitante deberá presentar un ACR sin demora (y, en cualquier caso, en un plazo de siete días a partir del momento en que tenga conocimiento de cualquier hecho o circunstancia que dé lugar a dicha obligación). La ICANN se reserva el derecho a exigir una reevaluación de la solicitud en caso de que se produzca un cambio material,³⁸ lo que podría dar lugar al cobro de tarifas adicionales. No notificar a la ICANN sobre cualquier cambio de circunstancias que pudiera hacer que la información proporcionada en la solicitud se vuelva falsa o engañosa puede dar lugar a que no se permita proceder con la solicitud.

Un solicitante puede pedir cambios en muchos aspectos de su solicitud, como se describe en la Sección 3.8.3 Tipos de pedidos de cambios en una solicitud y procesos requeridos. Sin embargo, un solicitante no podrá cambiar la cadena de caracteres solicitada, salvo en los casos en que el solicitante haya reunido los requisitos para ser un TLD que representa a una marca (consultar la Sección 7.3 Evaluación de elegibilidad como TLD que representa a una marca) y esté en controversia. Las solicitudes de cambio de una cadena de caracteres que representa a una marca siguen el proceso que se describe en la Sección 5.3 Solicitud de cambio de una cadena de caracteres que representa a una marca.³⁹

Algunos ACR pueden requerir reevaluaciones u otros procesos, tal como se describe en la Sección 3.8.3 Tipos de pedidos de cambios en una solicitud y procesos requeridos, que pueden implicar tarifas adicionales para el solicitante. Para más información sobre evaluaciones y tarifas, consultar el Módulo 6 Evaluación del solicitante, el Módulo 7 Evaluación de cadenas de caracteres y solicitudes y la Sección 3.3 Tarifas y pagos.

Los ACR de los solicitantes que reciban apoyo también se tendrán en cuenta en relación con la posibilidad de que el solicitante reciba más ayuda financiera a través del Programa de Apoyo para Solicitantes. Consultar Términos y condiciones del Programa de Apoyo para Solicitantes para más información.⁴⁰

3.8.2 Criterios para determinar pedidos de cambios

Al evaluar cada ACR, la ICANN tendrá en cuenta toda la información disponible en función de siete criterios, que se elaboraron para permitir las actualizaciones necesarias de la información o las solicitudes específicas de los solicitantes, y, a la vez, garantizar un proceso justo y equitativo para todos los solicitantes. La ponderación de cada criterio puede variar en función de las circunstancias específicas del pedido de cambio y de la solicitud, incluidos el solicitante y las cadenas de caracteres implicados. La aprobación de los cambios se determinará sopesando los siguientes factores:

1. Corrección de errores en la presentación: Este criterio se aplica cuando el solicitante pide un cambio para corregir un error. El solicitante debe proporcionar información adecuada para respaldar el pedido. Estos pedidos son poco frecuentes, pero cuando se presentan, este criterio tiene un peso significativo.

¿Existen pruebas que respalden la afirmación o el reclamo de que el cambio se solicita con el único propósito de corregir un error?

2. Explicación: Este criterio exige que el solicitante explique los cambios solicitados. Si no se proporciona una explicación, se brinda al solicitante la oportunidad de corregir la situación.

¿Se brinda una explicación razonable?

3. Causa del cambio:

¿Se solicita el cambio en respuesta a aportes de terceros, tales como comentarios sobre la solicitud, objeciones, asesoramiento consensuado del GAC o alertas tempranas de miembros del GAC? ¿Se solicita el cambio para reflejar un cambio organizativo (por ejemplo, un cambio en el nombre de la organización o en la dirección de correo)?

4. Precedentes: La ICANN evalúa si la aprobación del pedido de cambios sentaría un nuevo precedente o estaría en consonancia con solicitudes similares aprobadas con anterioridad. En esta etapa del Programa de Nuevos gTLD, es poco probable que se aprueben solicitudes que sienten un nuevo precedente.

¿El cambio es similar a otros ya aprobados? ¿El cambio podría llevar a otros a solicitar cambios similares que podrían afectar a terceros o tener efectos no deseables en el Programa?

5. Impacto a terceros, incluidos otros solicitantes: La ICANN evalúa si el pedido de cambios afecta sustancialmente a terceros, en particular, a otros solicitantes. Si un cambio puede afectar de manera sustancial al estado de otro solicitante, este criterio se pondera exhaustivamente.

¿Qué impacto, positivo o negativo, tendría el cambio sobre terceros, incluidos otros solicitantes? ¿Sería justo para la comunidad en general? ¿Crearía una ventaja o desventaja injusta?

6. Materialidad: La ICANN evalúa cómo el pedido de cambios afectará el estado de la solicitud y sus solicitudes competidoras, la cadena de caracteres, el conjunto de solicitudes controvertidas y cualquier otro proceso del Programa, como la evaluación con prioridad de la comunidad. Un cambio material no dará lugar automáticamente al rechazo, pero influirá en la ponderación de otros criterios.

¿El cambio afectaría los resultados de la evaluación, la controversia por cadena de caracteres o podría dar lugar a objeciones?

7. Momento: Este criterio determina si el momento en que se realiza el pedido de cambio afecta a los criterios 4 a 6 anteriores. Si se comprueba que dicho momento influye en estos criterios, se ponderará exhaustivamente.

¿Interfiere el momento de alguna manera en el procesamiento de las solicitudes?

Los cambios que supongan cambios materiales en partes públicas de la solicitud se someterán a un período de comentario de 30 días.⁴¹ Los cambios que requieran un período de comentario de 30 días se publicarán en el sitio web del Programa de Nuevos gTLD, donde se mostrará la información actualizada. ⁴²

3.8.3 Tipos de pedidos de cambios en una solicitud y procesos requeridos

La siguiente tabla presenta una lista no exhaustiva de posibles tipos de ACR, especifica si el ACR está permitido y detalla los procesos necesarios para cada tipo. La tabla también diferencia entre los dos flujos de trabajo distintos que activarán los diferentes tipos de ACR. En la Sección 3.8.4 Flujos de trabajo de los pedidos de cambios en una solicitud que figura más adelante se podrá obtener información más detallada.

Salvo lo incluido en la tabla, las evaluaciones pertinentes, como los Procedimientos de evaluación de la cadena de caracteres y solicitudes (Módulo 7) y los Procedimientos de evaluación de solicitantes (Módulo 6), se realizarán de nuevo en función de las áreas específicas afectadas por el ACR; esto se evaluará caso por caso.

La aprobación de cambios en una solicitud puede depender de los hechos y circunstancias específicos en torno al ACR y a la solicitud, incluidos el solicitante y las cadenas de caracteres implicados. Si la aprobación de un ACR requiere una reevaluación, puede cobrarse una tarifa adicional.

Tabla 3-3: Tipos de pedidos de cambios en una solicitud y procesos requeridos

3.8.4 Flujos de trabajo de los pedidos de cambios en una solicitud

Los distintos tipos de ACR activan flujos de trabajo diferentes, como se describe a continuación. En particular, salvo circunstancias extraordinarias, los ACR seguirán uno de los dos flujos de trabajo que se indican a continuación:

• Pedidos de cambios en una solicitud: Flujo de trabajo 1: Los ACR relativos a todas las áreas, excepto políticas de registración de la comunidad y Compromisos voluntarios de los operadores de registro, siguen el Flujo de trabajo 1. Consultar la Sección 3.8.4.1.

• Pedidos de cambios en una solicitud: Flujo de trabajo 2: Los ACR relativos a las políticas de registración de la comunidad y los Compromisos voluntarios de los operadores de registro siguen el Flujo de trabajo 2.

Cada flujo de trabajo se adapta para abordar los requisitos y consideraciones específicos asociados a los respectivos tipos de ACR. Consultar la Sección 3.8.4.2.

3.8.4.1 Pedidos de cambios en una solicitud: Flujo de trabajo 1

Todos los ACR, excepto los relativos a políticas de registración de la comunidad y Compromisos voluntarios de los operadores de registro, seguirán el flujo de trabajo que se describe a continuación:

1. Presentación: El solicitante presenta un ACR.

2. Revisión administrativa: La ICANN determina si el tipo de ACR está generalmente permitido, como se indica en la tabla en la Sección 3.8.3 Tipos de pedidos de cambios en una solicitud y procesos requeridos. Si no se permite el cambio, la ICANN informará al solicitante que el ACR no ha sido aprobado.

3. Revisión por parte de la ICANN: La ICANN revisa los materiales del pedido de cambios en función de los siete criterios para determinar los pedidos de cambios mencionados anteriormente. Si se requiere información adicional, la ICANN la pedirá al solicitante.

4. Determinación: Una vez finalizada la revisión, la ICANN informará al solicitante de su decisión de las siguientes maneras:

   1. Si no se aprueba el ACR, se informará al solicitante.

   2. Si se aprueba el ACR, los cambios propuestos se publicarán en el sitio web del Programa de Nuevos gTLD, se actualizará la solicitud y se informará al solicitante. Además, se informará al solicitante de uno de los siguientes resultados:

      1. No se requiere período de comentarios ni reevaluación (el proceso termina aquí).

      2. Se requiere un período de comentarios (consultar el paso 5).

      3. Se requiere un período de comentarios y reevaluaciones (consultar los pasos 5 y 6).

5. Período de comentarios: Si se requiere un período de comentarios, el ACR se publicará durante un período de comentarios de 30 días. Este período dará tiempo a la comunidad para revisar y presentar comentarios sobre la parte modificada de la solicitud.

6. Reevaluación: La ICANN emitirá una factura por la reevaluación, cuando corresponda. Tras el pago, la ICANN llevará a cabo la reevaluación de las áreas de evaluación afectadas de forma simultánea con el período de comentarios.

Figura 3-1: Pedidos de cambios en una solicitud: Flujo de trabajo 1

3.8.4.2 Pedidos de cambios en una solicitud: Flujo de trabajo 2

Los ACR relativos a las políticas de registración de la comunidad y a Compromisos voluntarios de los operadores de registro (RVC) seguirán el proceso descrito a continuación.

1. Presentación: El solicitante presenta un ACR.

2. Revisión administrativa: En primer lugar, la ICANN determina si el tipo de ACR está generalmente permitido, de acuerdo con la tabla que figura en la Sección 3.8.3 Tipos de pedidos de cambios en una solicitud y procesos requeridos. Si no se permite el cambio, la ICANN informará al solicitante que el ACR no ha sido aprobado.

3. Revisión por parte de la ICANN: La ICANN revisa los materiales del pedido de cambios en función de los siete criterios para determinar los pedidos de cambios mencionados anteriormente. Si se requiere información adicional, la ICANN la pedirá al solicitante.

4. Determinación: La ICANN determina si el cambio es material y toma las siguientes medidas:

   1. Si no es material, los cambios propuestos se publican en el sitio web del Programa de Nuevos gTLD, se actualiza la solicitud y se informa al solicitante (el proceso termina aquí).

   2. Si es material, consultar el paso 5.

5. Evaluación de compromisos de los operadores de registro (RCE): Los cambios materiales requieren una RCE.

6. Determinación: Una vez completada la RCE, la ICANN tomará una decisión sobre el cambio solicitado. La determinación tendrá como consecuencia uno de los siguientes resultados:

   1. Si el cambio solicitado supera la RCE, se continuará con el paso 7.

   2. Si el cambio solicitado no supera la RCE, la solicitud no se actualizará como se pidió a través del ACR y se procederá sin el cambio solicitado.

   3. Si el cambio solicitado no supera la RCE, o el cambio se pidió tras el asesoramiento consensuado del GAC o una Resolución del Panel en el contexto de una objeción, y se determinó que la solicitud no puede proceder sin el cambio, la solicitud no puede seguir avanzando. Consultar la Sección 7.8.3.4 Adiciones, cambios y eliminaciones de RVC para obtener más información sobre este tipo de RVC.

7. Publicación: Todos los RVC o políticas de registración de la comunidad presentados se publicarán junto con su respectiva determinación de la ICANN tras la RCE. Si los RVC o políticas de registración de la comunidad presentados sufren algún cambio como resultado de la negociación entre el solicitante y la ICANN para ser aprobados por la ICANN, los RVC o políticas de registración de la comunidad aprobados se publicarán junto a la versión original presentada por el solicitante.

8. Período de comentarios: Se abrirá un período de comentarios de 30 días. La ICANN se reserva el derecho de reiniciar las negociaciones o debatir con el solicitante los comentarios planteados durante este período.

Figura 3-2: Pedidos de cambios en una solicitud: Flujo de trabajo 2

3.9 Estados de las solicitudes

Una solicitud tendrá uno de los siguientes estados:

• Activa: La solicitud está avanzando en el Programa de Nuevos gTLD.

• En suspenso: La solicitud tiene actividades pendientes que pueden afectar su progreso, por ejemplo, mecanismos de responsabilidad u objeciones.

• Retirada: El solicitante renuncia voluntariamente a la solicitud. Este proceso es irreversible.

• Finalización pendiente: La solicitud no cumple los criterios establecidos en la Guía para el Solicitante de Nuevos gTLD y no puede seguir adelante en el Programa. Se espera que el solicitante retire su solicitud en un plazo de 60 días o la ICANN podrá cambiar el estado de su solicitud a Finalizada.

• Finalizada: La solicitud no continuará en el Programa y el solicitante ha agotado todas las apelaciones e impugnaciones disponibles.⁴⁸

• Desactivada: Este estado se asigna a cualquier solicitud que el solicitante decida no continuar procesando tras el periodo de reemplazo de cadenas de caracteres. Dichas solicitudes ya no se encuentran activas en el programa y no pasarán a la etapa de evaluación o delegación.

• Contratada: El estado de Contratada se asigna después de que el Acuerdo de Registro esté completamente firmado. El solicitante se convierte entonces en operador de registro de la/s cadena/s de caracteres solicitada/s.

• Delegada: El TLD se ha agregado a la zona raíz del DNS.