Procesos de transición del registro
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.
Definiciones
A los efectos de este documento, los siguientes términos se definen así:
Operador de registro back-end: una organización contratada por un registro para ejecutar una o más de las funciones críticas de un registro de gTLD.
Funciones críticas:funciones que son esenciales para el funcionamiento de un registro de gTLD:
- Resolución de DNS;
- Zona de DNSSEC debidamente firmada (si el registro ofrece DNSSEC);
- Sistema de registro compartido (SRS), generalmente mediante el protocolo de aprovisionamiento extensible (EEP);
- Servicios de directorio de datos de registración de nombres de dominio (RDDS), por ejemplo, WHOIS proporcionado mediante el puerto 43 y un servicio web;
- Custodia de datos del registro.
Transición del registro: un cambio en la parte contratada de un Acuerdo de Registro de gTLD con la ICANN. Estos son ejemplos de circunstancias que conducen a una transición del registro: cambio de nombre de la organización que ejecuta el gTLD, una venta o transferencia del registro, el registro actual no cumple con el Acuerdo de Registro, etcétera.
Registro sucesor: la nueva parte contratada de un Acuerdo de Registro de gTLD con la ICANN después de una transición del registro.
Procesos de transición del registro
Confirmación de compromisos, sección 9.2, se estipula como uno de los compromisos de la ICANN:
Preservar la seguridad, la estabilidad y la flexibilidad del DNS.1
Los estatutos de la ICANN identifican los valores fundamentales de la organización. El valor fundamental n.º 1 es:
Preservar y mejorar la estabilidad operativa, la confiabilidad, la seguridad y la interoperabilidad mundial de Internet.2
El Plan operativo de ICANN 2006-2007 (sección 1.1.2) establece que la ICANN:
Establecerá un plan global que se seguirá en caso de fracaso financiero, técnico o comercial de un operador de registro, incluido el total cumplimiento de los requisitos de custodia de datos y la prueba de recuperación.3
El proceso se creó en el año fiscal 2006-2007 y se ha actualizado de manera continua; se lo llama ahora marco de continuidad del registro.4 El proceso de administración de incidentes y eventos, descrito en el marco de continuidad del registro, identifica la necesidad de manejar situaciones en las que las funciones críticas del registro se ven afectadas de manera negativa.
En pos de cumplir con su valor fundamental n.º 1, y como resultado del desarrollo de un marco de continuidad del registro, la ICANN ha identificado la necesidad de definir los procesos para la transición de un gTLD de manera segura, estable y confiable, a la vez que se minimiza el impacto sobre los registratarios y los usuarios de gTLD, y se brinda transparencia a las partes implicadas en la transición.
Se han desarrollado los tres procesos siguientes y se describen en este documento:
- Proceso de transición del registro con sucesor propuesto
- Proceso de transición del registro con solicitud de propuestas (RFP)
- Proceso de transición temporal del operador de registro back-end de emergencia
-
Proceso de transición del registro con sucesor propuesto
Este proceso se utilizará cuando un registro solicite que la ICANN asigne su Acuerdo de Registro a un posible sucesor (por ejemplo, se adquiere el registro, hay un cambio de nombre en la organización, una transición al proveedor de continuidad de servicios de registro). Este proceso también se utilizará si al final de la vigencia del Acuerdo de Registro, o por medio de una orden judicial emitida por una autoridad legal con jurisdicción, el gobierno o la autoridad pública competente retira su respaldo al operador de registro de un gTLD que es un nombre geográfico y propone un registro sucesor. En el apéndice 2, hay un diagrama de flujo de este proceso.
Al evaluar al sucesor propuesto, se ejercerá en todo momento el nivel de análisis adecuado. Por ejemplo, en el caso de un cambio de nombre, la evaluación se centrará en asegurar que es legítimo garantizar que no haya oportunidad de secuestrar el TLD.
Al recibir la solicitud del registro actual o del gobierno o de la autoridad pública competente (en el caso de gTLD geográficos), la ICANN evaluará la situación a partir de datos recopilados, conversaciones con el registro actual y el gobierno o la autoridad pública (si corresponde), y un análisis del Acuerdo de Registro. La evaluación se centrará en las siguientes preguntas:
- ¿Habría un cambio en una entidad que proporcione alguna de las funciones de registro back-end?
- ¿Tiene el TDL alguna comunidad competente a la que se deba consultar?
- ¿Es este gTLD un nombre geográfico de acuerdo con la definición de la Guía para el Solicitante? (O, ¿se requirió respaldo del gobierno al momento de la solicitud?)
- ¿Hay alguna restricción en el Acuerdo de Registro que podría afectar una transición?
La ICANN también llevará a cabo una evaluación de riesgos del gTLD, el registro actual y el operador de registro back-end (si hay un cambio en cuanto a ello). La evaluación se centrará en las particularidades del triple como un todo y de los triples mismos. Por ejemplo, se controlará que el gTLD sea utilizado en gran medida por instituciones financieras o para el comercio electrónico, lo que puede conducir a medidas más estrictas sobre la seguridad de la transición.
Una vez finalizadas las evaluaciones, se controlará el registro sucesor propuesto para garantizar que cuente con el respaldo exterior requerido, si corresponde. Si el gTLD es un nombre geográfico, como se define en la Guía para el Solicitante de gTLD nuevos, la ICANN ordenará al sucesor propuesto que solicite respaldo al gobierno o a la autoridad pública competente para el posible sucesor y recolecte documentación de respaldo o no objeción. Si el Acuerdo de Registro define alguna comunidad a la que se debe consultar al momento de la transición, la ICANN la consultará en esta etapa. En estos casos, el sucesor propuesto debe contar con respaldo de la comunidad competente a fin de que el proceso pueda continuar con la transición.
Si el sucesor propuesto cuenta con el respaldo requerido o si no se requiere respaldo, la ICANN procederá a evaluar al solicitante, mediante los procesos que se definen en la Guía para el Solicitante de gTLD nuevos. De acuerdo con los criterios establecidos en la Matriz de evaluación del posible registro que se describen en el apéndice 1, la ICANN determinará qué evaluaciones son necesarias y recogerá la tarifa de información y evaluación. La tarifa cubrirá el costo de las evaluaciones que llevan a cabo los proveedores externos.
Las evaluaciones llevadas a cabo internamente por la ICANN no tendrán costo alguno para el solicitante.
El alcance de las evaluaciones variará para cada caso según el nivel de análisis requerido y adecuado. Los tres niveles de análisis se presentan en el apéndice 1. El nivel más amplio (es decir, Completo) será similar en alcance a la revisión de solicitantes de gTLD nuevos. La evaluación la llevará a cabo una de las firmas encargadas de evaluar las solicitudes de gTLD nuevos. El siguiente nivel (es decir, Limitado) representa un alcance de revisión más limitado. Por ejemplo, la evaluación técnica y de operaciones podría consistir en asegurar que la nueva organización tenga arreglos similares establecidos con el operador de registro back-end existente. El tercer nivel (es decir, Mínimo) representa un alcance de revisión muy limitado que podría ser llevado a cabo internamente por la ICANN.
El proveedor de evaluaciones llevará a cabo las evaluaciones requeridas y brindará un informe al solicitante y a la ICANN. Si el solicitante no aprueba la evaluación, es posible que pueda remediar las deficiencias dentro de las tres semanas de haber desaprobado la evaluación (una evaluación extendida). Si el solicitante no aprueba la evaluación en la segunda oportunidad, el proceso finalizará sin ninguna transición y se le dará al solicitante un reembolso igual a lo que se recolectó menos los costos reales de la evaluación.
Si el posible sucesor aprueba la evaluación, la ICANN buscará las aprobaciones necesarias y celebrará un Acuerdo de Registro con el sucesor si es aprobado. Si el posible sucesor no es aprobado, el proceso finalizará sin transición.
Una vez que el sucesor haya sido aprobado, se comunicará el resultado interna y externamente según sea necesario y corresponda. Si la transición no implica un cambio en el operador de registro back-end, el sucesor debe entonces solicitar el cambio en la organización patrocinadora con la IANA.
Si hay un cambio en la entidad que brinda los servicios de operador de registro back-end, el sucesor debe aprobar la prueba previa a la delegación, según se define en la Guía para el Solicitante de gTLD nuevos. Este es el caso si el proveedor back-end es el operador de registro o un contratista del operador de registro. Una vez que la prueba finalice satisfactoriamente, el operador de registro nuevo debe proceder a cambiar la organización patrocinadora con la IANA en la base de datos de la zona raíz de la IANA. Una vez que se haya completado el paso de la IANA, el operador de registro sucesor llevará a cabo la migración de datos y servicios, y solicitará cambios en los registros del DNS y de RDDS (WHOIS) con la IANA.
Los pasos finales en el proceso de transición serán comunicar interna y externamente según sea necesario y corresponda y para la ICANN actualizar su información pública e interna acerca del registro de gTLD.
-
Proceso de transición del registro con solicitud de propuestas
Este proceso se usará principalmente cuando un registro de gTLD incurra en incumplimiento de su Acuerdo de Registro (que genere la rescisión) y no identifique un registro sucesor. Este proceso también se utilizará si al final de la vigencia del Acuerdo de Registro, o por medio de una orden judicial emitida por una autoridad legal con jurisdicción, el gobierno o la autoridad pública competente retira su respaldo al registro de un gTLD geográfico y no ofrece un registro sucesor propuesto. En el apéndice 3, hay un diagrama de flujo de este proceso.
Este proceso es similar a un proceso de transición del registro con sucesor propuesto descrito anteriormente, excepto que incluye un subproceso de solicitud de propuestas (RFP). El propósito de la solicitud de propuestas es identificar y obtener solicitudes de registros sucesores posibles.
El proceso de solicitud de propuestas se iniciará de acuerdo con la evaluación de riesgos del gTLD, ya que puede producir conclusiones que podría ser importante divulgar en la solicitud de propuestas. La solicitud de propuestas describirá los servicios necesarios que el registro sucesor proveerá. Además, los costos previstos para los servicios de evaluación se incluirán en la solicitud de propuestas y servirán como propuesta económica mínima aceptable por parte de un solicitante.
Si el registro está operando un gTLD que es un nombre geográfico, según lo definido en la Guía para el Solicitante, la ICANN consultará con el gobierno o con la autoridad pública competente para conocer sus aportes en la solicitud de propuestas. Además, si el Acuerdo de Registro contiene una disposición que requiera que la ICANN consulte con una comunidad específica acerca de un posible sucesor antes de una transición, esto se hará en esta etapa del proceso.
Una vez que la solicitud de propuestas haya sido aprobada, se publicará durante 45 días y los solicitantes tendrán hasta el final del período de publicación para brindar una respuesta.
Luego se verificará si el solicitante que proponga el pago más elevado al registro original cuenta con el respaldo necesario y se lo evaluará de acuerdo a lo descrito en el proceso de transición del registro con sucesor propuesto. Este mecanismo de selección proporciona la máxima rentabilidad para el registro original y minimiza los gastos innecesarios para los solicitantes no ganadores, a la vez que garantiza que el ganador esté calificado.
Si el solicitante tiene el respaldo necesario (o si no se requiere respaldo) y aprueba la evaluación, el proceso continuará según lo descrito en el proceso mencionado. Si el solicitante no tiene el respaldo requerido o no aprueba la evaluación, se considerará al solicitante con la siguiente propuesta más elevada, y así sucesivamente, hasta que haya un solicitante evaluado y respaldado satisfactoriamente o no haya más propuestas.
Si no se reciben propuestas durante el proceso de solicitud de propuestas, o si no hay solicitantes calificados, debido a la falta de respaldo apropiado o a que no pueden aprobar la evaluación, se realizará el proceso de terminación de TLD para cerrar el gTLD. Si se identifica a un candidato viable después de cerrado el proceso de RFP en el cual no se identificó a ningún sucesor, se puede considerar al candidato según las circunstancias de ese momento y si la decisión satisface al interés público.
Si se identifica un registro sucesor calificado a lo largo del proceso, los fondos cobrados a este solicitante menos los costos de evaluación y las tarifas pendientes pagaderas irán al operador de registro que dispone del gTLD.
-
Proceso de transición temporal del operador de registro back-end de emergencia
Se utilizará este proceso para los gTLD nuevos principalmente cuando se cumplan dos condiciones: (1) el registro no cumple su Acuerdo de Registro y (2) se está desempeñando una función crítica por debajo del umbral de emergencia, lo que genera una situación de riesgo inaceptable según lo definido a continuación. En ese caso, las operaciones pueden transferirse a un proveedor de emergencia de servicios back-end hasta que el operador de registro pueda restaurar las operaciones normales. Esta transición temporal también podría iniciarse a pedido del operador de registro si tiene la certeza de un impedimento o lo anticipa para brindar las funciones críticas de manera adecuada.
Las mediciones para detectar el umbral de emergencia para las funciones críticas (excepto la custodia de datos) se prepararán en virtud del sistema de supervisión de SLA (contrato a nivel de servicio) de registro usado por la ICANN según lo descrito en el Acuerdo de Registro.
También cabe destacar que este proceso de transición procura ser una medida temporal para proteger a los registratarios y a los usuarios de gTLD. La transición temporal de las funciones críticas permanecerá en vigor hasta que se resuelvan los problemas subyacentes o hasta que se realice la transición del gTLD a otro operador usando uno de los procesos de transición del registro descritos anteriormente. Para permitir esta transición temporal, el Acuerdo de Registro para los gTLD nuevos incluirá la aceptación previa del operador del registro para los cambios en la base de datos de la IANA para DNS y RDDS (WHOIS), en el caso de una emergencia.
Una vez que el operador de registro esté listo para reanudar las operaciones y se hayan solucionado todos los problemas que puedan haber hecho que incurriera en incumplimiento, puede iniciar un proceso de transición del registro con sucesor propuesto para volver a tener el control de las operaciones del gTLD. Esta opción estará disponible para el operador de registro hasta que caduque el período de solución del incumplimiento. El operador de registro se identificará a sí mismo como el sucesor propuesto en ese proceso.
La ICANN mantendrá al menos dos operadores de registros back-end de emergencia (operadores de emergencia) preseleccionados contratados. Cada cinco años se publicará un proceso de solicitud de propuestas de operador de emergencia para renovar los contratos o identificar y seleccionar nuevos operadores de emergencia. Los operadores de emergencia que sean seleccionados serán de diversas regiones geográficas a fin de aumentar su confiabilidad de forma integral; si hubiera una catástrofe en una región que afectara la capacidad de funcionamiento de uno de ellos, el otro seguiría estando listo para operar. Los requisitos básicos de elegibilidad de los operadores de emergencia son al menos tres años de experiencia operando DNS y un año de experiencia operando servicios de RDSS (WHOIS) y EPP.
La ICANN seleccionará a los operadores de emergencia en virtud de su valor: la mejor combinación de servicio y precio. La financiación para el uso de servicios de los operadores de emergencia en cada caso se obtendrá de los instrumentos de continuidad operacional respectivos, requeridos para los operadores de registro de gTLD según define en la Especificación 8 del Acuerdo de Registro.
Los postulantes a operador de emergencia se evaluarán mediante procesos similares para gTLD nuevos, incluida la prueba previa a la delegación en la infraestructura que se utilizará en caso de emergencia. La infraestructura debe estar lista para operar durante la evaluación. La ICANN puede, cada cierta cantidad de tiempo, solicitar una prueba de la funcionalidad y la preparación del operador de emergencia para aceptar y actuar en caso de una transición de emergencia.
Apenas la ICANN seleccione los operadores de emergencia, se ofrecerá un acuerdo flexible entre registro y registrador a todos los registradores que permitirán a los operadores de emergencia llevar a cabo las funciones del SRS durante un proceso de transición temporal. Se fomentará que los registradores trabajen con los operadores de emergencia antes de que ocurra cualquier emergencia, de modo que estén listos para actuar (por ejemplo, cuando se celebre un acuerdo, cuando se distribuyeron las credenciales de acceso al SRS, en caso de prueba operativa de los operadores de emergencia, etcétera) en caso de emergencia de un gTLD en particular.
Cuando ocurra una emergencia y se requieran los servicios de operadores de emergencias, la ICANN solicitará los servicios de uno de los operadores de emergencia. Si el proveedor seleccionado no puede ocuparse de la operación o si hay un conflicto de interés, la ICANN solicitará los servicios de otro proveedor. Un operador de emergencia activo no podrá postularse para convertirse en el registro sucesor definitivo o el operador back-end del gTLD si hubiera una transición del registro, según las reglas de RFP. Para que el proceso de licitación sea equilibrado, un operador de emergencia activo brindará la información operativa a la ICANN, solicitada para incluirla en una RFP para la operación del gTLD.
Puede haber casos en los cuales el operador de registro back-end actual actúe como operador de emergencia, por ejemplo si:
- el operador de registro le solicita a la ICANN la transición de emergencia al operador de registro back-end como operador de emergencia;
- el operador actual de registro back-end interviene en las funciones críticas según las condiciones de los niveles de servicio definidas en el Acuerdo de Registro;
- la empresa operadora de registro back-end no está relacionada ni afiliada con el operador de registro; y
- el operador de registro back-end acepta operar el gTLD en las mismas o mejores condiciones que las acordadas por los operadores de emergencia.
Luego, la ICANN puede, a su sola discreción, ofrecer al operador de registro back-end llevar a cabo las funciones de registro del gTLD. En ese caso, el operador de registro back-end que actúa como operador de emergencia recibirá el pago de los procedimientos del instrumento de continuidad operacional.
Los operadores de emergencia tendrán los siguientes requisitos de nivel de servicio (SLR) para la activación de cada una de las funciones críticas.
Función crítica Requisito de nivel de servicio DNS/DNSSEC 4 horas a partir de la solicitud de la ICANN RDDS 24 horas después de recibir los datos SRS (EPP)* 72 horas después de recibir los datos Custodia de datos 24 horas del inicio de la operación del SRS * Servidores del SRS listos para aceptar solicitudes de los registradores.
Los operadores de emergencia mantendrán un archivo de al menos los archivos de zona diarios de todos los gTLD para permitir que el operador de emergencia seleccionado reanude rápidamente el servicio DNS en caso de emergencia. Para las otras funciones críticas, los datos se obtendrán del registro actual o de los depósitos de datos en custodia.
Los agentes de custodia de gTLD nuevos deberán aceptar un requisito de publicar los datos de los gTLD dentro de las 24 horas posteriores a la recepción, en caso de emergencia.
Durante el funcionamiento de emergencia de las funciones críticas de un gTLD, el operador de emergencia no aceptará operaciones facturables del SRS de parte de los registradores.
Por lo general, el operador de emergencia no aceptará la creación de dominios, renovaciones de dominios, transferencias de dominios ni eliminaciones de dominios de parte de los registradores. No obstante, en algunos casos excepcionales, se aceptarán las operaciones mencionadas, por ejemplo, en caso de solicitud acelerada de seguridad del registro 5, UDRP o cualquier otro proceso de resolución de disputas de nombres de dominio de la ICANN. La ICANN puede aprobar transferencias masivas de dominios patrocinados por registradores cuando estos ya no los mantienen (por ejemplo, porque fueron desacreditados). El operador de emergencia no los cancelará ni los renovará automáticamente; incluirá en el resultado de RDDS (por ejemplo, WHOIS) una explicación breve (aprobada por la ICANN) encima de la exención de responsabilidad (si la hubiere) como se describe en la sección 1.1 de la Especificación 4 del Acuerdo de Registro respecto del motivo por el cual la fecha de caducidad ocurrió en el pasado. El resto de las operaciones estándares de SRS (RFC 5730-34, 5910), host, contacto y nombre de dominio estarán permitidas. El operador de emergencia trabajará con todos los registradores acreditados que tengan dominios patrocinados en el gTLD.
Se permitirá que el registro sucesor cobre renovaciones o fracciones de renovaciones a partir de la fecha de inicio de las operaciones. El registro sucesor heredará las tarifas del registro fallido y deberá seguir el proceso definido en el Acuerdo de Registro para modificarlas.
En caso de emergencia, se seguirá el diagrama de flujo del proceso que se encuentra en el apéndice 4.
Al realizar la transición de un operador de emergencia al operador de registro anterior o a uno nuevo, el operador de emergencia colaborará y cooperará con el nuevo operador para llevar a cabo una transición ordenada que tenga un impacto mínimo en los registratarios y los usuarios de gTLD.
La ICANN supervisará y documentará los procesos de transición a medida que sucedan. Se elaborarán mediciones, incluso del desempeño de EBERO y del operador de registro, en las cinco funciones críticas.La ICANN tomará nota de aquello que funcionó bien y de aquello que se debe mejorar para proponer modificaciones al proceso.
- Appendix 1 | Prospective Registry Evaluation Matrix
- Appendix 2-1 | Registry Transition Process with Proposed Successor
- Appendix 2-2 | Registry Transition Process with Proposed Successor - Check Support
- Appendix 2-3 | Registry Transition Process with Proposed Successor - Evaluate
- Appendix 2-4 | Registry Transition Process with Proposed Successor - Communicate
- Appendix 3-1 | Registry Transition Process with Request for Proposals
- Appendix 3-2 | Registry Transition Process with Request for Proposals - Check Support
- Appendix 3-3 | Registry Transition Process with Request for Proposals - Evaluate
- Appendix 3-4 | Registry Transition Process with Request for Proposals - RFP
- Appendix 3-5 | Registry Transition Process with Request for Proposals - Communicate
- Appendix 4-1 | Emergency Back-End Registry Operator Temporary Transition Process
- Appendix 4-2 | Emergency Back-End Registry Operator Transition Process - DNS
- Appendix 4-3 | Emergency Back-End Registry Operator Transition Process - RDDS
- Appendix 4-4 | Emergency Back-End Registry Operator Transition Process - SRS
- Appendix 4-5 | Emergency Back-End Registry Operator Transition Process - Data Escrow
- Appendix 4-6 | Emergency Back-End Registry Operator Transition Process - Communicate
1 ICANN. (2009, September 30). Affirmation of Commitments. Retrieved from http://www.icann.org/en/documents/affirmation-of-commitments-30sep09-en.htm
2 ICANN. (2009, September 30). ICANN bylaws. Retrieved from http://www.icann.org/en/general/bylaws.htm#I
3 ICANN. (2006, June 22). 2006-2007 ICANN Operating Plan. Retrieved from http://www.icann.org/announcements/operating-plan-22jun06.htm
4 ICANN. (2009). gTLD Registry Continuity. Retrieved from http://www.icann.org/en/registries/continuity/