Skip to main content
Resources

Cambio al acuerdo de subcontratación parcial de funciones críticas (MSA)

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.

Reseña

Esta página web brinda pautas para los operadores de registro sobre cómo solicitar la aprobación de la organización de la ICANN para realizar cambios al acuerdo de subcontratación parcial de funciones críticas (MSA).

Todo acuerdo de subcontratación relacionado con cualquier función crítica como se define en la sección 6 de la especificación 10 del Acuerdo de Registro se considera un acuerdo de subcontratación parcial de funciones críticas (MSA). Los subcontratistas que operan una o varias funciones críticas se denominan operador de registro back-end o proveedor de servicios de registro (RSP).

Entre las funciones críticas sujetas al proceso de cambio al MSA se incluyen:

  • Resolución del DNS
  • Zona de DNSSEC debidamente firmada (si el registro ofrece DNSSEC)
  • Sistema de Registro Compartido (SRS), generalmente mediante el Protocolo de Aprovisionamiento Extensible (EEP)
  • Servicio de Directorio de Datos de Registración de Nombres de Dominio (RDDS), por ejemplo, Protocolo de Acceso a los Datos de Registración de Nombres de Dominio (RDAP) y WHOIS proporcionados a través del puerto 43 y mediante un servicio basado en la Web.

Mediante el proceso de cambio al MSA, la organización de la ICANN prueba y evalúa a un RSP a fin de asegurarse de que tenga la capacidad de operar un dominio de alto nivel (TLD) de modo estable y seguro. La organización de la ICANN también exige que los operadores de registro presenten un plan de transición para demostrar la forma en que una transición de servicios de un RSP a otro se coordinará y llevará a cabo de manera segura y estable.

A continuación, se muestra un cronograma general del proceso de MSA. Haga clic aquí para obtener un flujo de trabajo más detallado del proceso.

Cambio al acuerdo de subcontratación parcial de funciones críticas (MSA)

Antes de presentar la solicitud: Consideraciones y preparativos

Los pasos que se indican a continuación destacan las consideraciones y preparativos clave que los registros deberían realizar antes de presentar una solicitud de cambio al MSA en el portal de Servicios de Nombres (NSp).

Paso 1: Tenga en cuenta las transacciones relacionadas El hecho de cambiar su RSP podría generar otros cambios asociados. Considere, por ejemplo:

  • ¿Realizará modificaciones a los servicios de registro en el Anexo A del Acuerdo de Registro (RA) como resultado del cambio de su RSP?
  • ¿Cederá el TLD a una entidad diferente, además de este cambio al MSA?

Modificaciones a los servicios de registro: Si su RSP propuesto ofrece servicios de registro diferentes a los que ofrece su RSP actual (por ejemplo, bloqueo de registro, idiomas/códigos de escritura de IDN), necesitará actualizar el idioma del Anexo A mediante la presentación de una solicitud de Política de Evaluación de Servicios de Registro (RSEP) antes de presentar la solicitud de cambio al MSA. Recomendamos que solicite una llamada de consulta para analizar los pasos adecuados.

Cesión del TLD: Si planea ceder el RA del TLD a una entidad diferente además del cambio al MSA, deberá completar una transacción antes de iniciar la otra. Recomendamos encarecidamente que solicite una llamada de consulta para analizar las opciones disponibles y ayudarlo a comprender mejor las implicancias transaccionales. Consulte la página Cesiones para obtener más información sobre cómo ceder un TLD.

Paso 2: Comprenda su cronograma. Tómese al menos de 7 a 12 semanas para realizar la solicitud de cambio al MSA ante la organización de la ICANN. Calcule en su cronograma los requisitos de la organización de la ICANN para procesar el cambio al MSA, incluidas las pruebas, en relación con sus requisitos y necesidades empresariales. Por ejemplo, considere:

  • ¿Su acuerdo con su RSP actual finaliza pronto?
  • ¿Cuánto tiempo demorará realizar la transición de su RSP actual al RSP nuevo?

Paso 3: Organice una llamada de consulta con su a administrador de cuentas para asegurarse de que entiende el proceso. Su administrador de cuentas puede brindarle una visión general de lo que implica el proceso, informarle la documentación y pruebas requeridas, y ayudarle a asegurarse de que comprende lo que es necesario para iniciar una solicitud de cambio al MSA. Esto hará que el proceso sea más eficiente una vez que esté preparado para presentar su solicitud.

Paso 4: Revise y prepare la documentación exigida. Planee con anticipación; para ello, revise los recursos proporcionados y prepare la documentación que deberá incluir en su presentación y tome nota de lo siguiente:

Recursos

Sinopsis de requisitos (por tipo de cambio al MSA)

Requisito RSP conocido RSP desconocido

Presentación informal

Evaluación técnica

(Costo de evaluación estimado USD14.300)

Aprobación del plan de transición

Pruebas de Sistemas de Registro

Ejercicio de simulación

Presentación formal/Revisión de la ICANN

Determinación de la ICANN

Transición del RSP

*Actualmente no brinda apoyo a nuevos gTLD

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