Resumen

  • El borrador recomendado de septiembre de 2026 exigiría a cada RIR mantener procedimientos de continuidad y redundancia, y compartir periódicamente los registros, datos, procedimientos y sistemas necesarios para que un operador temporal pudiera sostener los servicios.
  • El texto incorpora protección de datos, un alcance de servicios, renovaciones con límite de 90 días y una revisión pública posterior. Sigue siendo un borrador; aquí no se documenta ninguna transferencia real.

Un plan de continuidad que se prepara cuando el registro ya no puede operar llega tarde. La propuesta de la Organización de Recursos Numéricos (NRO) intenta adelantar parte del trabajo: cada Registro Regional de Internet (RIR) tendría que mantener procedimientos de continuidad y redundancia y compartir los materiales que permitan a un operador temporal sostener los servicios necesarios.

La cláusula central es la sección 4.1(m) del Documento de Gobernanza de los RIR, versión 3, recomendado por ASO AC. Exige compartir periódicamente registros, datos, procedimientos de aplicación de políticas regionales y sistemas suficientes para que un operador temporal pueda prestar servicios cuando sea necesario, sujetos a controles adecuados de depósito o protección de datos. No exige publicar los datos ni transferir todos los sistemas a un tercero.

La lista es más amplia que una copia de la base registral: incluye sistemas y procedimientos de política. La continuidad se convierte así en una relación preparada en tiempos normales, no en una exportación improvisada tras una interrupción. El propio documento define los servicios del RIR como la delegación de recursos y los servicios de asignación, registro, directorio y soporte técnico relacionados que permiten a los titulares usar esos recursos y a terceros consultar información correcta.

La preparación plantea un equilibrio delicado. Una copia desactualizada puede impedir que el operador temporal mantenga registros fiables. Un acceso excesivo puede exponer información sensible o conceder autoridad innecesaria. La cláusula menciona controles de depósito y protección, pero no fija por sí misma la frecuencia de actualización, el proceso de revocación ni la prueba de integridad. Esos detalles deben convertirse en controles comprobables durante la implementación.

El relevo tiene límites, pero puede renovarse

La sección 5.1 permite activar la continuidad cuando un RIR no pueda prestar todos o parte de sus servicios, por causas internas o externas. El propio RIR puede iniciar un arreglo para sus servicios. También pueden iniciarlo o renovarlo la ICANN y dos tercios de los demás RIR, después de dialogar con el RIR afectado y su comunidad cuando las circunstancias lo permitan.

Cada período no puede superar 90 días sin renovación conforme a la misma sección. El informe de cambios de la versión 3 explica que se añadió la vía de autoactivación, se rebajó el umbral externo desde la unanimidad y se mantuvo el límite de 90 días para evitar que la solución temporal se convirtiera en el modo habitual. Por tanto, 90 días es un punto para volver a decidir, no un máximo acumulado si se autorizan renovaciones.

El RIR afectado debe cooperar con el traspaso temporal y conserva el derecho a retomar los servicios cuando su capacidad operativa se haya restablecido y verificado. El alcance de los servicios puede ampliarse o reducirse durante el arreglo o al renovarlo. El retorno existe en el diseño; falta saber quién verifica la recuperación, qué pruebas utiliza, cómo reconcilia los cambios y cuándo revoca los accesos del operador temporal.

La propuesta exige transparencia. La ICANN publicaría pronto la justificación y el alcance; las conversaciones con las comunidades de todos los RIR comenzarían tan pronto como fuera razonable. Al terminar, los RIR y la ICANN deberían revisar conjuntamente el evento y publicar un informe con las circunstancias, los servicios, la duración, el proceso de retorno, el desempeño del operador, la opinión de la comunidad y las recomendaciones. Un registro público facilitaría la auditoría, siempre que existan medidas precisas con las que comparar lo previsto y lo ocurrido.

La continuidad de emergencia no equivale a retirar el reconocimiento a un RIR. La sección 6 reserva la retirada para un incumplimiento material que persiste después de una oportunidad razonable de corregirlo. Ese proceso termina la responsabilidad del RIR y requiere un plan de transición. La continuidad de emergencia sustituye temporalmente la prestación de algunos servicios y conserva una vía para que el RIR vuelva. La sección 6.9 exige preparación para ambos escenarios, sin convertirlos en la misma decisión.

La versión 3 aún es un borrador recomendado

La versión 3 no es una regla adoptada. El NRO EC comunicó el 28 de julio que el consejo ASO había entregado el texto y que el NRO EC coordinaría los pasos hacia una versión final. La publicación de AFRINIC del 1 de septiembre añadió el borrador, la comparación y el informe de motivos, y dejó en manos del NRO EC anunciar futuras oportunidades de participación. La sección 1.3 prevé procedimientos de implementación conjuntos con requisitos mínimos.

La evidencia útil que falta es práctica: inventario de servicios y sistemas cubiertos, antigüedad de la copia, pruebas de integridad, autorización y registro de accesos, criterios de recuperación, reconciliación y caducidad de credenciales. Un ejercicio de mesa permitiría ensayar el relevo sin insinuar que hubo una caída real. El informe posterior debería diferenciar qué información estuvo disponible de cuál se utilizó.

El cambio de diseño más claro es trasladar la preparación a las operaciones ordinarias. Su eficacia dependerá de que «periódicamente», «suficiente», «controles adecuados» y «verificado» se conviertan en pruebas observables.

Fuentes

Al 15 de octubre, el calendario del NRO aún muestra la redacción final en curso: prevé actualizaciones en ICANN 87 (17–22 de octubre), LACNIC 46 (19–22 de octubre), ARIN 58 y RIPE 93; la aprobación y adopción figuran para el cuarto trimestre de 2026.