Resumen

  • RIPE NCC marcó como completado el aviso dedicado al RPKI Dashboard el 3 de noviembre de 2026 a las 21:06:58 CET; había comenzado a las 21:00:08. El aviso paralelo de Access, portal LIR y base de datos seguía en curso después de las 21:08 y ya incluía el mismo Dashboard entre sus componentes.
  • El canal de estado de componentes continuaba etiquetando el Dashboard como under_maintenance mientras su aviso propio decía completed. RIPE no publicó una prueba completa de acceso, apertura del panel y envío de una ROA que permitiera decidir qué podía hacer el socio.

El botón de cerrar una tarea funciona mejor cuando nadie necesita saber qué significó. A las 21:06:58 CET, RIPE NCC cerró su aviso de mantenimiento RPKI, iniciado a las 21:00:08. El componente señalado era el RPKI Dashboard. Si ese fuera el único registro, el lector tendría una historia limpia: empezó, terminó, siguiente asunto. Había otro registro del mismo servicio y de la misma noche.

El aviso de mantenimiento de Access, portal y base de datos también acabó enumerando el RPKI Dashboard entre sus componentes. Su actualización de las 21:08:58 mantenía los trabajos en marcha; una copia posterior a las 21:41 aún mostraba in_progress. El final previsto pasó primero a 21:40 y luego a 21:59. El canal oficial de componentes registra la etiqueta under_maintenance del Dashboard actualizada a las 21:08:58, unos dos minutos después del cierre de su ficha específica. Access volvió a operational a las 21:41:21; Dashboard, portal y base seguían marcados en mantenimiento. No hay que elegir una fuente externa para hallar la discrepancia: todas las marcas son de RIPE.

La segunda ficha había cambiado de forma durante el proceso. Una copia anterior al comienzo contenía tres componentes —base, portal y Access— y una finalización prevista para las 21:10. Las copias tomadas durante los trabajos contienen un cuarto componente, el Dashboard, y finales previstos de 21:40 y 21:59. El API guarda mensajes de inicio y de continuación. No guarda una explicación fechada de cuándo y por qué se añadió el Dashboard, ni de los cuarenta y nueve minutos añadidos al plazo inicial. Un lector que llega después ve la versión más reciente, no el camino que llevó hasta ella.

La conclusión llegó antes de las 21:59 previstas en la última versión. El componente Dashboard volvió a operational a las 21:46:51 y la segunda tarea terminó a las 21:47:19. Desde el cierre de la tarea RPKI a las 21:06:58 hasta el regreso de la etiqueta operativa pasaron 39 minutos y 52 segundos. Entre los dos cierres de tareas pasaron 40 minutos y 21 segundos. El plazo de las 21:59 era un plan revisado, no el resultado. RIPE tardó casi cuarenta minutos en dar al componente el mismo sentido de «terminado» que ya había dado a su ficha.

Conviene llamar a cada dato por su nombre. completed es la publicación de un cierre para una tarea; under_maintenance es la etiqueta pública de un componente. Ninguna de las dos cosas mide por sí sola si una persona pudo iniciar sesión a las 21:07, abrir el panel a las 21:22 o enviar una ROA a las 21:31. La guía de RPKI alojado dice que el miembro entra al Dashboard con una cuenta RIPE NCC vinculada a su LIR para gestionar autorizaciones de origen de ruta. La guía de Access sitúa el panel detrás de esa puerta de entrada. La operación del miembro atraviesa las dos fichas, por mucho que la página de estado las separe.

La pregunta no es quién ganó una carrera de cronómetros. Es qué ficha mandaba sobre el estado de un componente compartido después de que la tarea específica se cerrara. ¿La segunda tarea mantenía el panel en mantenimiento? ¿La etiqueta iba por detrás de un servicio ya utilizable? El registro público no muestra una prueba satisfactoria del recorrido completo. Aunque todo hubiera funcionado, el lector carecía del dato para saberlo. Esa carencia pertenece al diseño de la rendición de cuentas del servicio.

La solución es bastante menos larga que esta crónica. Un estado autorizado por componente, la ficha activa responsable de ese estado y un historial con la hora de cada cambio de lista o de plazo. Al cierre, una nota que diga si se probó el acceso, la apertura del Dashboard y el envío de una ROA. Entonces la palabra «completado» servirá al operador, y no solo al sistema que archiva tareas.

Registros originales de RIPE NCC