Skip to main content
Resources

Notas de implementación de la RSEP

Tenga presente que la versión oficial de todos los contenidos y documentos traducidos es la versión en idioma inglés; las traducciones a otros idiomas son solo a título informativo.

A partir del 17 de junio de 2019

Tras varios meses de debate, el Grupo de Discusión de mejoras de la RSEP del RySG y la organización de la ICANN acordaron un conjunto de mejoras operativas para lograr eficiencias y previsibilidad dentro del proceso y a la vez respetar a la política. Esta versión 2019 de las Notas de implementación de la RSEP refleja los cambios acordados con vigencia a partir del 17 de junio de 2019.

Haga clic aquí para volver a la página web del Proceso de la RSEP.

Introducción

El 8 de noviembre de 2005, la Junta Directiva de la ICANN dirigió la implementación del procedimiento recomendado por la GNSO para considerar las solicitudes de nuevos Servicios de registro que se guiarán por las disposiciones del Acuerdo de Registro de .NET relativas a las definiciones de los Servicios de Registro. Estas Notas de Implementación son una sinopsis del proceso de la Política de Evaluación de Servicios de Registro (RSEP) y tienen la intención de proporcionar información de alto nivel sobre la implementación de la Política por parte de la organización de la ICANN. La organización de la ICANN puede revisar la eficacia de esta implementación de forma periódica con los aportes de los operadores de registro y las unidades constitutivas pertinentes.

En 2019, un grupo de discusión del Grupo de Partes Interesadas de Registros (RySG) colaboró con la organización de la ICANN para actualizar las Notas de Implementación sin alterar la propia política. Estas Notas de Implementación revisadas están diseñadas para hacer que el proceso de la RSEP sea más fácil de entender, establecer una mayor previsibilidad y asegurar una alineación continua con la Política subyacente.

Un operador de registro de gTLD puede presentar una solicitud RSEP a la organización de la ICANN para agregar un Servicio de Registro propuesto, modificar un Servicio de Registro existente o eliminar un Servicio de Registro. Si la organización de la ICANN determina que un servicio propuesto en una solicitud RSEP no cumple los requisitos de un Servicio de Registro según lo que se define en el Acuerdo de Registro, la organización de la ICANN notificará al operador de registro y cerrará la solicitud. El operador de registro podrá retirar su solicitud en cualquier momento.

En respuesta a las diferencias entre la Política de Consenso de RSEP y los términos contractuales de ciertos Acuerdos de Registro de gTLD heredados, la organización de la ICANN creó una conciliación entre la Política de Consenso y los términos contractuales de los Acuerdos de gTLD que contienen el proceso de evaluación. La conciliación tiene por objeto demostrar que la implementación de la política de consenso resulta en un proceso que no es incompatible ni con la política de consenso ni con los términos de cualquier Acuerdo de gTLD vigente. La organización de la ICANN tendrá en cuenta la conciliación para cualquier solicitud RSEP para Acuerdos de Registro con estas diferencias.

Todas las referencias a los días se definen como días naturales, a menos que se indique lo contrario.

Paso 1 - Presentación

Los operadores de registro pueden presentar solicitudes RSEP a la organización de la ICANN mediante el formulario de solicitud apropiado en base a los criterios que se indican a continuación:

  1. Formulario estándar de solicitud RSEP: para las solicitudes RSEP para agregar un Servicio de Registro propuesto, eliminar un Servicio de Registro existente o modificar sustancialmente un Servicio de Registro existente, los operadores de registro deben responder a una serie de preguntas estándar destinadas a proporcionar a la organización de la ICANN la información suficiente para evaluar la solicitud. Los operadores de registro pueden designar como "CONFIDENCIAL" la información presentada en la solicitud RSEP, con la excepción de la información necesaria para describir la finalidad del Servicio de Registro propuesto y el efecto en los usuarios del DNS.

    Con el fin de cumplir con los plazos de la Política y ofrecer más previsibilidad a los operadores de registro, la Política y la organización de la ICANN recomiendan a los operadores de registro que consulten a la organización de la ICANN antes de presentar un formulario de solicitud RSEP estándar. Este paso no tiene por objeto crear una carga adicional para el operador de registro, sino más bien ayudar a garantizar que la información necesaria se reúna con antelación para la consideración de la solicitud RSEP. Esta también es una oportunidad para analizar si la solicitud cumple con los requisitos en virtud de la Política, anotar y aclarar cualquier preocupación que pueda surgir en la revisión formal de la solicitud, y acordar el texto apropiado de autorización tan pronto como sea posible.

  2. Formulario de solicitud RSEP simplificado: para determinados servicios conocidos(servicios que han sido revisados repetidamente por la organización de la ICANN por temas de seguridad y estabilidad, que no han planteado problemas significativos de seguridad o estabilidad, que han sido aprobados anteriormente y que disponen de una plantilla de enmiendas publicada), el operador de registro completa un formulario de solicitud simplificado y confirma el uso de una plantilla estándar de enmiendas sin necesidad de modificación. Este paso puede reducir la duración de una solicitud RSEP de servicios conocidos desde su presentación hasta su autorización.

Paso 2 - Verificación de exhaustividad de la ICANN

Las solicitudes RSEP permanecen sin publicarse mientras están en la prueba de exhaustividad y toda la interacción entre la organización de la ICANN y el operador de registro con respecto a la solicitud RSEP permanece confidencial. Una vez que se presenta una solicitud, la organización de la ICANN lleva a cabo una revisión para asegurarse de que esté completa, lo cual debería demorar menos de 15 días. Una solicitud debe cumplir con los siguientes criterios para proceder con el Paso 3 - Revisión de la ICANN:

  1. Información suficiente: la solicitud debe incluir información suficiente para que la organización de la ICANN pueda tomar una determinación preliminar informada durante la Revisión de la ICANN. Las presentaciones completas de las solicitudes RSEP estándar incluyen respuestas sustantivas a todas las preguntas pertinentes, incluida una descripción completa del servicio propuesto, una evaluación del impacto en los usuarios externos, una lista y explicación de las disposiciones contractuales afectadas por el nuevo servicio (si las hubiera), el texto de la enmienda propuesta (cuando se requiera una enmienda), los comentarios de las partes externas y de la comunidad (si se obtiene) y cualquier otra documentación justificativa útil para la determinación preliminar.

  2. Documento de autorización: al final del Paso 2, la organización de la ICANN y el operador de registro deben estar de acuerdo con el tipo de documento de autorización y, en el caso de una enmienda al Acuerdo de Registro (RA), con el texto de la enmienda antes de que la solicitud se someta a la Revisión de la ICANN. Las razones por las cuales la organización de la ICANN no puede proceder a aceptar un documento de autorización incluyen cuando el servicio propuesto entra en conflicto con la Política de consenso de la ICANN o la dirección de la Junta Directiva de la ICANN.

    Tipo de documento de autorización y criterios:

    • Enmienda del RA:se utiliza cuando el servicio propuesto (i) contradice las disposiciones existentes en el RA o (ii) no está contemplado en el RA y, por lo tanto, debe agregarse al Anexo A del RA y/o como un apéndice/adenda apropiado.

    • Carta de habilitación para implementar:se utiliza cuando el servicio propuesto ya está contemplado en el RA y no contradice las disposiciones contractuales.ZZ

La organización de la ICANN puede identificar que se necesita información adicional en la solicitud RSEP para que la organización de la ICANN realice su evaluación y se incluya en la solicitud publicada. En esta situación, la organización de la ICANN puede consultar al operador de registro y/o pedirle que vuelva a presentar su solicitud con información adicional, lo que puede prolongar el Paso 2: Prueba de exhaustividad. La organización de la ICANN trabajará de buena fe con el operador de registro a lo largo de este proceso.

2A - Solicitud para proceder

Si las partes acuerdan que el criterio 1 del Paso 2 está completo, pero el operador de registro y la organización de la ICANN no han acordado el tipo de documento de autorización y/o el texto de la enmienda, el operador del registro puede presentar una solicitud para proceder con el Paso 3 - Revisión de la ICANN antes de que se finalice el documento de autorización. La organización de la ICANN considerará todas las Solicitudes para proceder de manera oportuna y evaluará el progreso de las negociaciones de buena fe.

La organización de la ICANN puede tomar una de las siguientes medidas si se presenta una Solicitud para proceder:

  • Si las negociaciones están casi completas, la organización de la ICANN puede conceder la Solicitud para proceder y la solicitud RSEP continuará con el Paso 3 - Revisión de la ICANN, en cuyo momento se publicará la solicitud RSEP. Ambas partes continuarán las negociaciones durante el Paso 3 con el objetivo de llegar a un acuerdo al final de la Revisión de la ICANN.

  • Si las negociaciones no están cerca de completarse, la organización de la ICANN puede solicitar una negociación adicional con intervención progresiva dentro del liderazgo de la organización de la ICANN. Esta intervención progresiva tendrá lugar antes de que la solicitud RSEP se traslade al Paso 3. Si la organización de la ICANN concede la Solicitud para proceder después de la intervención progresiva, la organización de la ICANN puede publicar el documento de autorización propuesto para comentario público si el Servicio de Registro propuesto sienta un nuevo precedente o tiene un efecto sustancial sobre la ICANN, terceros o el Sistema de Nombres de Dominio. El comentario público se produciría después del Paso 3 - Revisión de la ICANN.

  • Si la organización de la ICANN determina que el operador de registro no ha negociado de buena fe, la organización de la ICANN puede rechazar la Solicitud para proceder.

Paso 3 - Revisión por parte de la ICANN

Una vez que la organización de la ICANN determine que una solicitud está completa o que otorga una Solicitud para proceder en el Paso 2, la organización de la ICANN comenzará el proceso de revisión de 15 días y publicará el Servicio de Registro propuesto.

Durante la revisión de la ICANN, se hará una determinación preliminar sobre si el Servicio de Registro propuesto plantea problemas significativos en materia de seguridad, estabilidad o competencia. La organización de la ICANN seguirá las directrices publicadas sobre la determinación preliminar de problemas de competencia y podrá procurar el asesoramiento de expertos de entidades o personas con sujeción a acuerdos de confidencialidad sobre las implicaciones del Servicio de Registro propuesto en materia de seguridad, estabilidad o competencia. Estos expertos pueden incluir a miembros del Panel de Evaluación Técnica de Servicios de Registro (RSTEP). Esta revisión no excederá los 15 días requeridos por la Política.

Al final del Paso 3 - Revisión por parte de la ICANN, la organización de la ICANN notificará la determinación preliminar sobre el servicio de registro propuesto al operador de registro que presenta la solicitud.

Paso 4 - Aprobación o remisión

La determinación preliminar del Paso 3 tendrá como consecuencia uno de los siguientes resultados:

  1. Aprobación de la solicitud RSEP

  2. Remisión al Panel de Evaluación Técnica de Servicios de Registro (RSTEP)

  3. Remisión a la autoridad gubernamental correspondiente en materia de competencia.

  4. Remisión tanto al RSTEP como a la autoridad gubernamental correspondiente en materia de competencia.

Si la determinación preliminar concluye con los resultados 2-4, se notificará al operador de registro y éste deberá confirmar que tiene la intención de seguir adelante con el proceso de revisión o retirar su solicitud RSEP. Si es necesario, el operador de registro puede consultar a la organización de la ICANN sobre el resultado.

Resultado

Determinación

Próximos pasos

(1) Aprobación

No hay problemas significativos aparentes en materia de seguridad, estabilidad o competencia.

La solicitud se considera completa y se procederá al Paso 6 - Autorización.

(2) Remisión al RSTEP

Podría plantear problemas importantes de seguridad o estabilidad.

Si el operador de registro confirma que desea seguir adelante, el servicio propuesto es evaluado por el RSTEP (la lista de miembros del RSTEP se publica aquí). Una vez que una solicitud es referida al RSTEP, el panel tendrá 45 días para revisar el servicio propuesto y crear un informe sobre cualquier problema en materia de seguridad o estabilidad. Se entregará al operador de registro una versión no redactada del informe final del RSTEP. Paso 5 - Se requiere el comentario público y la consideración de la ICANN.

(3) Remisión a la autoridad gubernamental correspondiente en materia de competencia.

Podría plantear problemas importantes en materia de competencia.

Si el operador de registro confirma que desea seguir adelante, la organización de la ICANN remitirá el asunto a la autoridad o autoridades gubernamentales correspondientes en materia de competencia con jurisdicción sobre el asunto dentro de los cinco días hábiles siguientes a la confirmación del operador de registro para proceder. Paso 5 - Se requiere el comentario público y la consideración de la ICANN.

(4) Remisión tanto al RSTEP como a la autoridad gubernamental correspondiente en materia de competencia.

Podría plantear problemas importantes en materia de seguridad o estabilidad y problemas de competencia.

Si el operador de registro confirma que desea seguir adelante, la organización de la ICANN seguirá los pasos de los resultados 2 y 3.

Paso 5 - Comentario público y consideración de la ICANN (si corresponde)

Se requiere un período de comentario público sobre un documento de autorización propuesto como resultado de la solicitud RSEP si el Servicio de Registro propuesto fue remitido al RSTEP o a la autoridad de competencia en el Paso 4 o en virtud de las condiciones descritas en 2A - Solicitud para proceder.

  • Remisión al RSTEP: el Servicio de Registro propuesto y el documento preliminar de autorización se publicarán para que comentario público mientras el RSTEP lleva a cabo su revisión. Una vez que el informe de evaluación del RSTEP esté completo, se agregará al período de comentario público en curso. Una vez concluido el período de comentario público, el operador de registro puede responder a los comentarios y actualizar el documento preliminar de autorización.

  • Derivación a la autoridad en materia de competencia: El Servicio de Registro propuesto y el documento de autorización se publicarán para comentario público durante los 45 días de remisión a la autoridad gubernamental correspondiente en materia de competencia.

    • Si la autoridad en materia de competencia plantea problemas dentro del plazo de remisión de 45 días, el operador de registro puede trabajar con la organización de la ICANN para abordar los problemas y el documento preliminar de autorización puede actualizarse.

    • Si la autoridad en materia de competencia no plantea problemas dentro de los 45 días del plazo de remisión o si la solicitud se resuelve antes, la organización de la ICANN lo tendrá en cuenta en su análisis de los comentarios de públicos. 

    • Una vez concluido el período de comentario público, el operador de registro puede responder a los comentarios y actualizar la autorización preliminar.

Después del período de comentario público, la aprobación de la solicitud RSEP será considerada por la organización de la ICANN o será remitida a la Junta Directiva de la ICANN.

Si se remite a la Junta Directiva de la ICANN, la Junta Directiva de la ICANN tendrá como objetivo tomar una decisión en un plazo de 30 días a partir de la finalización del resumen de comentarios públicos y el informe del análisis. La Junta Directiva de la ICANN puede decidir: 1) aprobar la solicitud RSEP, 2) rechazar la solicitud RSEP, o 3) aplazar la solicitud RSEP para obtener más información.

Si la organización de la ICANN o la Junta Directiva de la ICANN aprueba la solicitud RSEP, el operador de registro y la organización de la ICANN procederán al Paso 6: Autorización. Si la Junta Directiva de la ICANN rechaza la solicitud, la misma no procederá.

Paso 6 - Autorización

Al igual que con la implementación previa de la Política por parte de la ICANN, una vez que se haya aprobado una solicitud RSEP y que la organización de la ICANN y el operador de registro estén de acuerdo con el documento de autorización, la organización de la ICANN iniciará el proceso de autorización. Dentro del plazo de 5 días posteriores al cumplimiento de estas condiciones, la organización de la ICANN realizará una de las siguientes acciones:

  1. Expedir la Carta de habilitación para implementar al operador de registro (según lo acordado en el paso 2), momento en el cual el operador de registro puede implementar el servicio.

  2. Iniciar el proceso de ejecución de Enmienda del RA mediante la enmienda del RA acordada en el Paso 2 o el Paso 5 si se realizan actualizaciones después del Comentario Público. El operador de registro podrá implementar el servicio solicitado tras la ejecución de la enmienda tanto por parte del operador de registro como por parte de la organización de la ICANN.

La organización de la ICANN publicará una notificación del Servicio de Registro aprobado, así como el documento de autorización, en la página web de la RSEP y en la página web del Acuerdo de Registro específico de los TLD.

Si el operador de registro lo implementa sin un documento de autorización, se puede considerar que el operador del registro está incumpliendo las normas.

Flujo de trabajo del proceso de RSEP

Consulte el Flujo de trabajo del proceso de RSEP para obtener una representación de alto nivel del proceso de la RSEP que contiene referencias a estas Notas de Implementación.

Archivo

Esta página web se actualizó en junio de 2019 como parte de las mejoras operativas para el proceso de la RSEP (consulte la publicación del blog de la organización de la ICANN). Las Notas de implementación archivadas están disponibles aquí.

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