Resumen

  • La versión 3 añade una vía para que el RIR afectado inicie un traspaso temporal de sus propios servicios; otra vía permite que ICANN y dos tercios de los demás RIR lo inicien o renueven.
  • El límite de 90 días y el derecho del registro afectado a recuperar los servicios cuando su capacidad esté restablecida y verificada son explícitos. La autoridad para renovar un traspaso que comenzó por iniciativa propia no lo es.

Cambió la autoridad antes que el operador

Cuando un registro no puede prestar adecuadamente todos o parte de sus servicios, el proyecto de RIR Governance Document permite que un Temporary Emergency Operator cualificado los asuma temporalmente. No plantea que ese operador sustituya institucionalmente al RIR. La transferencia se refiere a servicios concretos: delegar recursos numéricos, mantener registros y datos de directorio, u otras funciones técnicas que permiten a titulares y redes confiar en la información vigente. La cobertura puede ser parcial y modificarse.

El 1 de septiembre de 2026 AFRINIC compartió el borrador recomendado por el ASO AC, su versión comparada y un informe de justificación. El NRO etiqueta la versión 3 como borrador final; su cronograma indica que el ASO AC/NRO NC la entregó al NRO EC el 28 de julio. A 14 de octubre, la finalización y la aprobación/adopción del cuarto trimestre siguen pendientes. Es una regla propuesta para todo el sistema de RIR, no un procedimiento vigente. Ni el anuncio ni el borrador acreditan que AFRINIC u otro registro no pueda prestar sus servicios. AFRINIC difundió el paquete; el texto de la versión 3 del NRO contiene las cláusulas relevantes.

Dos vías para iniciar

El apartado 5.1(a) cambia de manera sustantiva la versión 2. Si no puede prestar todos o algunos de sus servicios, el RIR afectado puede iniciar un Temporary Emergency Continuity Arrangement para sus propias funciones. Antes, el inicio exigía unanimidad de los demás RIR y de ICANN. La versión 3 conserva una vía de coordinación externa en el apartado 5.1(b), pero reduce el umbral: ICANN y dos tercios de los demás RIR también pueden iniciar o renovar el acuerdo, después de dialogar con el RIR afectado y su comunidad cuando las circunstancias lo permitan razonablemente.

La justificación explica el motivo operativo. La autoactivación puede servir durante un desastre natural; reducir el umbral externo puede acelerar la respuesta. A la vez, se conserva el máximo de 90 días para que la solución temporal no se convierta en el modo habitual. La combinación tiene lógica: durante una perturbación, esperar una autorización más amplia antes de pedir apoyo puede dejar incierto quién puede ejecutar una tarea registral necesaria.

Sin embargo, iniciar y renovar no son la misma decisión. El apartado (a) identifica al RIR afectado como quien puede iniciar el traspaso de sus servicios. El apartado (b) es el único que señala expresamente que el acuerdo puede iniciarse o renovarse con ICANN y dos tercios de los demás RIR. El apartado (c) establece que no puede superar 90 días salvo renovación conforme a las condiciones de la sección. No dice de forma expresa si un RIR que inició bajo (a) puede renovar por sí mismo o si debe usar el acuerdo externo de (b).

Hay más de una lectura posible. La referencia explícita a la renovación en (b) puede entenderse como la única vía que el texto establece para renovar. Otra lectura sostiene que la autoridad de autoactivación también permite prolongar el acuerdo iniciado por el propio RIR. El apartado 5.1(f), que atribuye los cambios de alcance a la parte iniciadora pertinente —o a las partes— de las vías (a) o (b), enlaza ambas rutas, pero no resuelve quién puede renovar. Conviene tratarlo como una ambigüedad de redacción que debe aclararse, no como un dictamen jurídico ya cerrado ni como prueba de que un traspaso autoactivado no pueda continuar.

El alcance del servicio también distribuye autoridad

El alcance no queda congelado el primer día. El apartado 5.1(f) permite ampliarlo o reducirlo durante el acuerdo o cuando se renueva, según considere necesario la parte iniciadora pertinente. Si el RIR afectado activó el traspaso y más tarde el grupo externo autoriza su renovación, el texto debería explicar quién puede añadir una función, restringir el mandato del operador temporal o modificar la división del trabajo.

No es una cuestión de archivo. Cada servicio que recibe el operador temporal cambia lo que el RIR afectado sigue controlando directamente; cada servicio que se devuelve exige pasos y pruebas para mostrar que el registro puede asumirlo de nuevo. El criterio inicial —no poder prestar adecuadamente todo o parte de los servicios— también necesita evaluación operativa. El expediente debería indicar qué función no superaba ese criterio y qué evidencia demostraría su recuperación, sin divulgar credenciales ni detalles de seguridad.

El borrador incorpora salvaguardias importantes. El apartado 5.1(d) exige que ICANN publique pronto la decisión de iniciar o renovar, su justificación y su alcance. Después del inicio pide participación de todas las comunidades de los RIR; tras una renovación, los RIR pueden optar por abrir participación adicional. El RIR afectado debe colaborar con el traspaso y conserva el derecho a reanudar las funciones una vez restaurada y verificada su capacidad.

El artículo 5.2 exige luego una evaluación conjunta y un informe público sobre las circunstancias, los servicios, la duración y la vuelta, además de evaluar al operador, recibir comentarios comunitarios y recomendar mejoras.

Estas garantías hacen visible el trabajo del operador temporal y delimitan su mandato. No dicen, por sí solas, quién renueva un acuerdo que empezó localmente. La participación de la comunidad aporta testimonios, experiencia y alertas; no sustituye la autoridad institucional que el texto asigna a los actores designados.

Las reglas de aplicación deben mostrar el traspaso

El apartado 1.3 contempla procedimientos de aplicación conjuntos, pero establece que su ausencia no impide aplicar las disposiciones del documento. Cada RIR conserva margen para definir su forma de cumplimiento dentro de las obligaciones comunes. El apartado 1.4 remite las decisiones a los procedimientos de cada entidad, incluidos los mecanismos de impugnación o recurso que correspondan. Un manual común puede precisar las operaciones, pero la autoridad básica no debería tener que reconstruirse durante el incidente.

Un registro breve de la vía de autoridad permitiría comprobar el mecanismo. Debería identificar el apartado invocado y quién decidió; qué servicios se transfirieron y desde cuándo; la fecha límite de 90 días; quién puede renovar y quién debe aprobar; qué alcance cambió y quién lo autorizó; la consulta y publicación realizadas; la prueba de capacidad para el retorno; y quién llevará a cabo la revisión posterior y en qué fecha. No se trata de añadir una aprobación a cada paso, sino de distinguir entre una solicitud local de ayuda y una decisión colectiva de mantener o ampliar el traspaso.

Según el calendario del NRO, la finalización sigue en curso, con actualizaciones previstas en próximas reuniones de los RIR e ICANN y la aprobación/adopción proyectada para el cuarto trimestre. La prueba para la siguiente versión es concreta: ¿puede renovarlo el RIR que activa 5.1(a)? Si no, ¿qué acuerdo de 5.1(b) hace falta? ¿Quién controla el alcance si cambia la vía de inicio? Responder con precisión mantendría la velocidad buscada por la versión 3 y permitiría seguir la responsabilidad cuando vence el plazo de 90 días.

Fuentes