Skip to main content
Resources

Procedimiento de enmienda al Acuerdo entre Registro y Registrador (RRA)

Esta página está disponible en:

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.

Actualizado el 2 de julio de 2018

Para ver las Enmiendas al Acuerdo entre Registro y Registrador que incluyen la aprobada Especificación Temporaria para los Datos de Registración de los gTLD, consulte esta página.

Página principal de Enmienda del RRA

Propuestas publicadas y notas de presentación (agosto de 2021 – presente)

Propuesta publicada retirada y notas de presentación (julio de 2009 – julio de 2021) – retirada tras actualizar el nombre de esta lista de correo electrónico para alinearla con el procedimiento.

Procedimiento de la ICANN para la consideración de las enmiendas propuestas a los Acuerdos entre Registro y Registrador de gTLD

La ICANN ha desarrollado el siguiente proceso para la consideración de las enmiendas propuestas a los Acuerdos entre Registro y Registrador (RRA) de gTLD, cuya aprobación por parte de la ICANN es exigida al registro. Este proceso está diseñado para garantizar aportes del registrador (y aportes públicos según corresponda) antes de que la ICANN apruebe cambios para un RRA.

Procedimiento para la consideración de las enmiendas propuestas al RRA:

  1. El registro que solicite la enmienda para su RRA debe suministrar a la ICANN una copia de su RRA propuesto, indicando todos los cambios en forma resaltada y adjuntando una nota de presentación. La nota de presentación suministrada por el registro debe describir el propósito de los cambios propuestos. Aunque no es obligatorio, se recomienda una llamada de consulta con la ICANN antes de presentar los cambios propuestos al RRA.
  2. La ICANN enviará la versión propuesta del RRA con cambios resaltados y la nota de presentación al Grupo de Partes Interesadas de Registradores para su revisión, mientras que la ICANN realiza un análisis interno de los cambios propuestos. La duración del período de revisión por parte de los registradores puede variar, dependiendo de la complejidad de los cambios propuestos u otras circunstancias, pero normalmente no debería ser mayor a veintiún (21) días. Normalmente, la ICANN publicará la propuesta y la nota de presentación en su sitio web.
  3. Al finalizar el período de revisión por parte de los registradores, y en caso de existir alguna inquietud que hubiese sido expresada, la ICANN consultará al registro y al Grupo de Partes Interesadas de Registradores para intentar resolver cualquier tipo de inquietud.
  4. Si las consultas dan lugar a cambios en la propuesta, la ICANN presentará el documento revisado al Grupo de Partes Interesadas de Registros y abrirá un período de revisión adicional, el cual normalmente no excederá los quince (15) días. Al concluir dicho segundo período de revisión, la ICANN intentará resolver los problemas pendientes a través de consultas con los registradores y con el registro.
  5. Tras el proceso anterior de análisis y consulta, la ICANN aprobará o rechazará los cambios propuestos. Algunos cambios pueden requerir la aprobación de la Junta Directiva de la ICANN; por ejemplo, en los casos en los cuales puede haber un efecto sustancial sobre terceros o sobre la seguridad y la estabilidad del DNS.

Diagrama de flujo del proceso de aprobación de enmiendas al RRA

RRA Amendment Approval Process Flowchart

A note about our terms of service:

We have updated our electronic terms of service to provide greater transparency and align with laws applicable to us. Learn more.

This site uses cookies to deliver an efficient user experience and to help us see how the site is used. Learn more.OK

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