Résumé

  • RIPE NCC a marqué sa fiche de maintenance du RPKI Dashboard comme terminée le 3 novembre 2026 à 21 h 06 min 58 s CET, après un début à 21 h 00 min 08 s. La fiche parallèle d’accès, du portail LIR et de la base de données était encore en cours après 21 h 08 et incluait désormais le même Dashboard.
  • Le flux public des composants indiquait toujours under_maintenance pour le Dashboard alors que sa fiche dédiée disait completed. Aucun essai publié de connexion, d’ouverture du Dashboard et de soumission d’une ROA ne départage ces deux états pour l’usage du membre.

Un registre peut fermer une fiche de maintenance sans avoir fermé toutes les questions qu’elle pose. À 21 h 06 min 58 s CET, RIPE NCC a apposé « terminé » sur sa fiche RPKI System Maintenance. Le travail avait commencé à 21 h 00 min 08 s. Le composant nommé est le RPKI Dashboard. La chronologie paraît nette jusqu’à ce que l’on ouvre l’autre fiche officielle du même soir.

La maintenance d’accès, du portail et de la base énumère RIPE NCC Access, le portail des membres LIR et la base RIPE. Pendant l’intervention, elle énumère aussi le RPKI Dashboard. Sa mise à jour de 21 h 08 min 58 s indique que le travail se poursuit; une capture faite après 21 h 41 la montre toujours in_progress. Son heure de fin prévue est passée d’abord à 21 h 40, puis à 21 h 59. Le flux des composants date l’étiquette under_maintenance du Dashboard de 21 h 08 min 58 s, environ deux minutes après la clôture de sa fiche dédiée. Access revient à operational à 21 h 41 min 21 s, tandis que Dashboard, portail et base restent marqués en maintenance. RIPE signe ces deux réponses sur le même Dashboard.

Un exemplaire sauvegardé avant l’intervention rend le changement visible. La fiche Access ne nommait alors que trois composants — base, portail et accès — et prévoyait une fin à 21 h 10. Les versions capturées pendant les travaux en comptent quatre avec le Dashboard, et affichent successivement 21 h 40 puis 21 h 59. L’API conserve des messages de début et de poursuite des travaux. Elle ne donne pas de note datée expliquant l’ajout du Dashboard ou les quarante-neuf minutes ajoutées au créneau initial. Pour refaire l’histoire, il faut conserver les versions successives de la fiche; l’état présent ne suffit pas.

Le dernier délai prévu n’a pas été atteint. Le composant Dashboard est repassé à operational à 21 h 46 min 51 s, et la fiche Access a été close à 21 h 47 min 19 s. Entre la clôture de la fiche RPKI à 21 h 06 min 58 s et le retour du composant, les étiquettes publiques ont divergé pendant 39 min 52 s. Les deux avis de fin sont séparés de 40 min 21 s. Le 21 h 59 était une prévision modifiée, pas l’heure réelle de fin.

Un statut de composant n’est pas un relevé d’essais effectués par un membre. completed atteste la clôture publiée d’une fiche. under_maintenance est l’étiquette publique du composant à un moment donné. Aucun de ces champs ne prouve si une personne pouvait se connecter à 21 h 07, ouvrir le Dashboard à 21 h 22 ou soumettre une ROA à 21 h 31. Le guide RPKI hébergé explique que le membre utilise un compte RIPE NCC lié à un LIR pour accéder au Dashboard et gérer ses Route Origin Authorizations. Le guide Access place lui aussi le Dashboard derrière cette entrée. Une opération ordinaire traverse les deux fiches.

Voilà pourquoi le problème dépasse une simple course d’horloges. Quand la fiche propre au Dashboard a été clôturée, la seconde fiche pilotait-elle encore son état ? Ou l’étiquette du composant suivait-elle le service avec retard ? Les données publiques ne donnent pas le résultat d’un test complet du parcours membre. Même si le service était utilisable, la publication ne permettait pas de le savoir. Une page de statut qui demande au lecteur de choisir entre deux descriptions du même composant n’a pas fini son travail.

RIPE NCC peut rendre la prochaine opération intelligible sans publier son journal interne entier. Associer chaque composant à un état faisant autorité et à la fiche active qui le tient; dater l’ajout d’un composant et le changement d’une heure prévue; indiquer si quelqu’un a testé connexion, ouverture du Dashboard et soumission d’une ROA. Le tampon vert cessera alors d’être la récompense administrative d’une seule fiche pour devenir une information exploitable.

Documents originaux RIPE NCC