Módulo 2 Información general

La ICANN reconoce la complejidad del Programa de Nuevos gTLD: Ronda de 2026 y ha compilado pautas para abordar posibles preguntas de los solicitantes. Este módulo proporciona acceso directo a información esencial y enlaces a recursos adicionales, lo que permite a los solicitantes y a las partes interesadas conocer mejor el Programa.

El Módulo 2 ofrece una descripción general de los temas clave, entre los que se incluyen:

• Información sobre idiomas y documentación de respaldo.

• Aceptación Universal.

• Seguridad y estabilidad.

• Cumplimiento legal.

Este módulo debería servir como principal punto de referencia para los solicitantes con preguntas generales.

2.1 Recursos y ayuda

Existen varios recursos disponibles para responder a preguntas sobre el Programa de Nuevos gTLD: Ronda de 2026 y el proceso de presentación de solicitudes, tal como se describe más adelante.

2.1.1 Preguntas frecuentes

La ICANN ha compilado una base de datos con preguntas frecuentes (FAQ) para que los solicitantes dispongan de un valioso recurso. Estas preguntas frecuentes se pueden consultar en la página de preguntas frecuentes del sitio web del Programa de Nuevos gTLD. ¹

2.1.2 Asistencia a consultas generales

Para consultas generales sobre el Programa de Nuevos gTLD: Ronda de 2026, contactar el equipo de Apoyo Global de la ICANN² o enviar un correo electrónico a globalsupport@icann.org.

Apoyo Global de la ICANN también ha puesto a disposición un Asesor de solicitantes dedicado a resolver preguntas sobre el proceso de presentación de solicitudes y proporcionar orientación sobre dónde encontrar los recursos disponibles.

2.1.3 Preguntas específicas sobre el sistema y las solicitudes

Para proteger la seguridad y la privacidad de los datos de los solicitantes, aquellos que tengan preguntas específicas sobre sus solicitudes deben enviar una consulta a través del TAMS. Para enviar una consulta a través del TAMS, hacer clic en el enlace “Ver mi Organización” (View My Organization) ubicado en el lado izquierdo de la página de inicio. Esto lo llevará a la página “Resumen de la Organización” (Organization Summary) en la que puede hacer clic en el botón “Crear Consulta” (Create Inquiry) en la parte superior derecha.

Para aprender a crear una consulta y obtener más información de utilidad acerca del sistema, consultar la Guía del Usuario del TAMS en el sitio web del Programa de Nuevos gTLD.³

Tal como se indica en la Sección 2.1.2, las consultas generales acerca del Programa de Nuevos gTLD deben enviarse mediante el servicio de Apoyo Global de la ICANN (globalsupport@icann.org).

2.2 Idiomas y documentación de respaldo

2.2.1 Guía para el Solicitante de Nuevos gTLD y materiales

La Guía para el Solicitante está disponible en los idiomas de la ICANN: árabe, chino, inglés, francés, ruso y español,⁴ Las versiones en los distintos idiomas pueden consultarse en la Página de inicio de la Guía para el Solicitante.⁵ La versión en inglés se considera oficial para la Guía para el Solicitante y demás documentación.

2.2.2 Idioma de las solicitudes de nuevos gTLD

El inglés es el idioma principal en el que se desarrollan todas las actividades de la ICANN. Todos los materiales relacionados con las solicitudes deben presentarse en inglés, salvo cuando se indique expresamente lo contrario en una pregunta incluida en la solicitud.

2.2.3 Idioma de la documentación de respaldo requerida para las solicitudes de nuevos gTLD

En cuanto a la documentación de respaldo, los solicitantes deben presentar la documentación original. Cuando presenten la documentación original en un idioma distinto del inglés, los solicitantes deberán proporcionar:

1. Documentos originales.

2. Traducciones al inglés de cada documento.

3. Un certificado de exactitud de la traducción de cada documento.

El certificado de traducción debe estar redactado en inglés e incluir:

1. Cualificaciones del traductor.

2. Una declaración en la que se afirme la integridad y exactitud de la traducción.

3. Identificación del documento traducido y de su idioma original.

4. Fecha, nombre y firma del traductor.

La mayoría de los traductores profesionales y agencias de traducción pueden proporcionar un certificado de traducción, que no necesita autenticación notarial. En el sitio web de la Asociación Estadounidense de Traductores (American Translators Association) se puede encontrar un modelo de certificado de exactitud de la traducción.⁶

Las traducciones certificadas debidamente presentadas pueden agilizar la revisión y el procesamiento de los materiales.

2.3 Aceptación Universal de nombres de dominio y direcciones de correo electrónico

La Aceptación Universal (UA) es un concepto crítico que apunta a 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. Este enfoque permite a los usuarios de Internet navegar y comunicarse en línea utilizando nombres de dominio y direcciones de correo electrónico que reflejen sus preferencias culturales y lingüísticas.

2.3.1 Aviso sobre cuestiones relacionadas con la Aceptación Universal de nombres de dominio y direcciones de correo electrónico que usan nuevos gTLD

Todos los solicitantes deben entender que la obtención de la aprobación de la ICANN y la firma de un Acuerdo de Registro no garantizan la funcionalidad inmediata y completa de Internet. La experiencia indica que es posible que los operadores de redes no sean plenamente compatibles de inmediato con los nuevos dominios de alto nivel, incluso cuando estos dominios hayan sido delegados en la zona raíz del DNS, ya que la aplicación de los cambios puede requerir modificaciones de software de terceros. Del mismo modo, las aplicaciones de software a veces intentan validar los nombres de dominio y pueden no reconocer dominios de alto nivel nuevos o desconocidos.

La ICANN no puede imponer la aceptación del software de los nuevos dominios de alto nivel, pero proporciona recursos para facilitarla. La ICANN publica los dominios de alto nivel válidos y ha desarrollado una herramienta básica para ayudar a los proveedores de aplicaciones a utilizar los datos actuales de la zona raíz. La ICANN recomienda que los solicitantes se familiaricen con estas posibles cuestiones relativas a la integración y que las tengan en cuenta en sus planes de puesta en marcha y lanzamiento. Es posible que los solicitantes seleccionados tengan que realizar esfuerzos considerables para trabajar con los proveedores a fin de lograr la aceptación de sus dominios gTLD solicitados.

A los efectos de obtener información más detallada y antecedentes, se recomienda que los solicitantes consulten la página web dedicada a la Aceptación Universal ⁷ . Se recomienda a los solicitantes de nombres de dominio internacionalizados que revisen el material relativo a las experiencias con cadenas de caracteres de prueba de IDN en la zona raíz.⁸

2.3.2 Información más detallada sobre la Aceptación Universal

La ICANN y la comunidad siguen avanzando en la preparación para la UA en todo el ecosistema de Internet. La ICANN publica información detallada reciente sobre la Aceptación Universal en la página web dedicada a la Aceptación Universal, incluido el último Informe Anual sobre la Preparación para la UA. Este informe abarca el estado de compatibilidad para la UA en tecnología, incluidos lenguajes de programación, herramientas y servicios de correo electrónico, utilidades de red, aplicaciones de redes sociales, sistemas de gestión de contenidos y herramientas de autenticación, entre otros. Asimismo, el informe incluye información sobre los esfuerzos de notificación y corrección de errores que se están llevando a cabo actualmente. Los informes sobre la UA, así como el material de capacitación técnica y las pautas para que los sistemas estén listos para la UA, pueden consultarse en la página web dedicada a la Aceptación Universal. En la Sección 1.2 del Acuerdo de Registro Base (Apéndice 4) se incluye una disposición sobre la viabilidad técnica de las cadenas de caracteres.

2.4 Libertad de expresión de los solicitantes

La ICANN respeta los derechos de libertad de expresión de los solicitantes, protegidos por principios jurídicos reconocidos internacionalmente, incluidos los definidos en el Convenio de París para la Protección de la Propiedad Industrial, la Declaración Universal de los Derechos Humanos y el Pacto Internacional de Derechos Civiles y Políticos.

Si bien los solicitantes pueden solicitar cadenas de caracteres disponibles, esto debe sopesarse con ciertas restricciones basadas en normas técnicas, listas de nombres reservados y otras prohibiciones detalladas en la Guía, sin olvidar las limitaciones a la libertad de expresión. A la hora de evaluar la conveniencia o no de presentar una objeción de interés público limitado (Sección 4.5.1.3), el Objetor independiente considerará la libertad de expresión junto con otros factores pertinentes. Las solicitudes pueden no prosperar si la cadena de caracteres propuesta infringe la legislación aplicable u otros derechos, requisitos o prohibiciones.

2.5 Seguridad y estabilidad

El número de TLD delegados en la zona raíz del DNS no debe aumentar más de aproximadamente un cinco por ciento al mes.⁹

Las solicitudes se procesarán por orden de prioridad. El proceso de delegación de un nuevo gTLD en la zona raíz comienza cuando el operador de registro presenta una solicitud de delegación una vez que el nuevo gTLD está listo.¹⁰ Salvo circunstancias extraordinarias, las solicitudes de delegación se procesarán por orden de llegada hasta que se alcancen los límites de cambio de la zona raíz. No obstante, las solicitudes de delegación de otros tipos de TLD¹¹ tendrán prioridad sobre las solicitudes de delegación de nuevos gTLD.

La ICANN se reserva el derecho a modificar el índice de delegación en caso de inestabilidad real o potencial del servicio del DNS, según determine la ICANN a su entera y razonable discreción. En caso de que sea necesario modificar el índice de delegación, se notificará a los solicitantes afectados. Cualquier demora por parte de la ICANN en la delegación de una cadena de caracteres no se computará en la obligación del operador de registro de completar las pruebas y procedimientos previos a la delegación dentro del plazo establecido en el Artículo 2.20 del Acuerdo de Registro Base (Apéndice 4).

2.6 Cumplimiento legal

El solicitante reconoce que la ICANN debe cumplir todas las leyes aplicables, incluidos las leyes, normas y reglamentos de Estados Unidos. Una de estas normas es el programa de sanciones económicas y comerciales administrado por la Oficina de Control de Activos Extranjeros (OFAC) del Departamento del Tesoro de Estados Unidos.
¹² Estas sanciones se han impuesto a determinados países, así como a personas y entidades que figuran en la Lista de Ciudadanos Especialmente Designados y Personas Bloqueadas (Lista de SDN) de la OFAC. La ICANN tiene prohibido suministrar la mayoría de los bienes o servicios a residentes de países sancionados o a sus entidades gubernamentales o a SDN sin una autorización o exención aplicable del gobierno de Estados Unidos. Por lo general, la ICANN no solicitará una licencia para proporcionar bienes o servicios a una persona o entidad incluida en la lista de SDN. En el pasado, cuando se le solicitó a la ICANN que prestara servicios a personas o entidades que no sean SDN, pero que sean residentes de países sancionados, la ICANN solicitó y se le otorgaron licencias según fuese necesario. No obstante, el solicitante reconoce que la ICANN no está obligada a solicitar dichas licencias y que, en cualquier caso, la OFAC podría decidir no conceder la licencia solicitada.

2.7 Mecanismos de responsabilidad

La ICANN está comprometida con la responsabilidad y la transparencia en todas sus prácticas. La ICANN considera que estos principios son medidas de protección fundamentales para garantizar que el modelo de múltiples partes interesadas ascendente continúe siendo efectivo. Los mecanismos mediante los cuales la ICANN logra la responsabilidad y la transparencia están incorporados en todos los niveles de la organización y su mandato, comenzando con los Estatutos, ¹³ detallados en sus Principios y Marcos para la Responsabilidad y Transparencia ¹⁴ (adoptados por la Junta Directiva de la ICANN en 2008), y anualmente reforzados en su Plan Estratégico y Operativo.¹⁵ Con el fin de reforzar su transparencia y responsabilidad, la ICANN ha establecido mecanismos de responsabilidad para revisar sus acciones. Consultar los Mecanismos de Responsabilidad de la ICANN ¹⁶ para más información.

2.8 Futuras rondas de solicitudes

La ICANN prevé que las futuras rondas de nuevos gTLD tendrán lugar a intervalos regulares y predecibles, sin períodos de revisión indefinidos. Salvo en circunstancias extraordinarias, los procedimientos de solicitudes proseguirán sin interrupción, a menos que el Consejo de la GNSO recomiende una pausa y la Junta Directiva de la ICANN la apruebe.

La Junta Directiva puede iniciar una nueva ronda incluso si los pasos previos de procesamiento y delegación de solicitudes están incompletos. Las solicitudes de cadenas de caracteres variantes asignables de gTLD existentes también podrán presentarse en la Ronda de 2026 y en las posteriores.

La Junta Directiva determinará el calendario de la próxima ronda de solicitudes tan pronto como sea factible, idealmente antes de la segunda reunión de la Junta Directiva una vez que se cumplan las siguientes condiciones:

1. Confirmación de la lista de cadenas de caracteres solicitadas para la ronda en curso y cierre del plazo para las solicitudes de cambio de cadena de caracteres. De este modo, los solicitantes de una ronda posterior sabrán cuáles son las cadenas de caracteres que se pueden solicitar.

2. La ICANN no ha encontrado obstáculos significativos al recibir y procesar nuevas solicitudes.

Las revisiones y los procesos de desarrollo de políticas futuros, incluida la próxima Revisión de Competencia, Confianza y Elección de los Consumidores (CCT), deberían tener lugar independientemente de las posteriores rondas de solicitudes de gTLD. No deben detener ni retrasar estas rondas, salvo en circunstancias extraordinarias.

Si alguno de los resultados de las revisiones o de los procesos de desarrollo de políticas afectara sustancialmente los procedimientos de solicitudes, dichos cambios se aplicarán a la siguiente ronda de solicitudes tras la adopción de las recomendaciones pertinentes por parte de la Junta Directiva. La implementación de estas recomendaciones será un requisito previo para el calendario de la próxima ronda de solicitudes.

2.9 Días calendario y plazos

A menos que se especifique lo contrario, el período a partir del cual se realizará el conteo regresivo para todos los procesos mencionados en la Guía para el Solicitante será en días calendario y comenzará a la 00:01 UTC el día después del anuncio del inicio del proceso. A menos que se especifique lo contrario, todas las horas de finalización de los plazos estarán expresadas en Tiempo Universal Coordinado (UTC).

2.10 Obligaciones fundamentales de los operadores de registro en relación con los registradores

Esta sección describe las obligaciones de los operadores de registro relativas a sus interacciones con los registradores. Consultar el Apéndice 4 Acuerdo de Registro Base para ver todas las obligaciones de los operadores de registro.

Un nombre de dominio en un gTLD debe registrarse a través de un registrador acreditado por la ICANN, salvo en ciertas excepciones específicas, identificadas en el Acuerdo de Registro Base, que permiten al operador de registro registrar un nombre para sí mismo. Consultar la Sección 2.9 del Acuerdo de Registro Base.

Un operador de registro debe utilizar un acuerdo uniforme con todos los registradores autorizados a registrar nombres mediante la creación de un Acuerdo entre Registro y Registrador (RRA) para definir los requisitos para sus registradores. El RRA debe incluir ciertos términos que se especifican en el Acuerdo de Registro Base y puede incluir otros términos específicos del gTLD. Un operador de registro debe notificar con antelación los cambios de precios a todos los registradores, de conformidad con los plazos especificados en el acuerdo. Consultar las secciones 2.9 y 2.10 del Acuerdo de Registro Base.

Todos los operadores de registro están obligados a cumplir el Código de conducta del operador de registro, a menos que la ICANN conceda una exención a un operador de registro que cumpla con los requisitos y lo solicite.¹⁷ El Código de conducta del operador de registro exige que el operador de registro proporcione acceso no discriminatorio a sus servicios de registro a todos los registradores acreditados por la ICANN que celebren y cumplan el RRA para el TLD. Consultar la Especificación 9, Sección 1(a) del Acuerdo de Registro Base.

Además, el Código de conducta del operador de registro exige a los operadores de registro que también presten servicios de registrador o registrador revendedor que garanticen que dichos servicios se ofrecen a través de una entidad jurídica independiente del operador de registro, y que se mantienen libros contables separados. La ICANN se reserva el derecho de remitir cualquier solicitud a la autoridad de competencia pertinente en relación con cualquier problema de titularidad cruzada. Consultar la Especificación 9, Sección 2, del Acuerdo de Registro Base.

Un operador de registro debe saber que un registrador acreditado por la ICANN no tiene obligación de portar un gTLD ni de ofrecerlo a sus clientes en su oferta de productos. Si bien se recomienda a los registradores que sigan las actualizaciones relativas al Programa de Nuevos gTLD con el fin de estar al tanto de los gTLD delegados, queda a discreción de los registradores evaluar la conveniencia de suscribir un RRA con cada operador de registro.

La ICANN seguirá brindando apoyo a los operadores de registro de gTLD en el lanzamiento y mantenimiento de sus operaciones de registro. La ICANN ofrece un punto de contacto a los operadores de registro de gTLD para recibir asistencia de forma continua. Los operadores de registro también pueden consultar el sitio web dedicado a los operadores de registro¹⁸ y la sección “Después de la contratación” del sitio web del Programa de Nuevos gTLD¹⁹ para más información.

La función de cumplimiento contractual de la ICANN realiza auditorías periódicas para garantizar que los operadores de registro de gTLD cumplen las obligaciones de su acuerdo e investiga cualquier caso de incumplimiento. Consultar la página web del equipo de Cumplimiento Contractual²⁰ para más información sobre las actividades en curso en materia de cumplimiento contractual.

Los Estatutos de la ICANN exigen que la organización actúe de forma abierta y transparente, y que garantice un trato equitativo entre los operadores de registro. La ICANN es responsable de mantener la seguridad y estabilidad de Internet a nivel mundial, y espera mantener una relación constructiva y de cooperación con los futuros operadores de registro de gTLD para alcanzar este objetivo.