Zusammenfassung

  • Das RIPE NCC setzte sein eigenes RPKI-Dashboard-Wartungsticket am 3. November 2026 um 21:06:58 Uhr MEZ auf completed, nachdem es um 21:00:08 Uhr begonnen hatte. Das parallele Ticket für Access, LIR-Portal und Datenbank lief nach 21:08 Uhr noch und enthielt inzwischen auch das Dashboard.
  • Der öffentliche Komponentenfeed bezeichnete das Dashboard weiter als under_maintenance, während sein eigenes Ticket bereits geschlossen war. Ein veröffentlichter Test von Anmeldung, Dashboard-Aufruf und ROA-Übermittlung fehlt; die Einträge beantworten daher nicht, was ein Mitglied in dieser Zeit erledigen konnte.

Ein abgeschlossenes Ticket ist kein benutzbares Werkzeug. Das RIPE NCC hat beide Begriffe am 3. November nebeneinander veröffentlicht. Der Eintrag „RPKI System Maintenance“ meldete um 21:06:58 Uhr MEZ completed; sein Start war um 21:00:08 Uhr eingetragen. Als betroffene Komponente nannte er das RPKI Dashboard. Wer nur diese Karte las, konnte eine kurze, ordentlich beendete Wartung vermuten. Die zweite Karte derselben Nacht erzählte eine andere operative Geschichte.

Das Ticket für RIPE NCC Access, LIR-Portal und Datenbank führte während des Eingriffs zusätzlich das RPKI Dashboard. Ein Update um 21:08:58 Uhr sagte, die Arbeiten liefen noch. Eine nach 21:41 Uhr gesicherte Antwort zeigte weiter in_progress; das geplante Ende wanderte erst auf 21:40 Uhr, dann auf 21:59 Uhr. Der Komponentenfeed datiert das under_maintenance-Label des Dashboards auf 21:08:58 Uhr, etwa zwei Minuten nach dem Schluss seines eigenen Tickets. Access kehrte um 21:41:21 Uhr zu operational zurück; Dashboard, Portal und Datenbank trugen weiter Wartungslabels. Ein Ticket sagte „Dashboard-Arbeit beendet“, der Status der Komponente sagte „unter Wartung“. Beide Anzeigen stammen vom Betreiber selbst.

Die zweite Karte hatte sich unterwegs verändert. Eine vor Beginn gesicherte Fassung nannte nur Datenbank, Portal und Zugang und setzte das geplante Ende auf 21:10 Uhr. Die laufenden Fassungen enthielten vier Komponenten, darunter das Dashboard, und zeigten nacheinander 21:40 und 21:59 Uhr. RIPE veröffentlichte Start- und Fortsetzungsupdates. Eine datierte Erläuterung, wann und warum das Dashboard hinzukam oder das geplante Ende insgesamt um 49 Minuten verschoben wurde, stand nicht dabei. Wer die frühere Fassung nicht gesichert hatte, sah nur die jeweils neue Uhrzeit.

Die tatsächlichen Abschlüsse kamen vor dem zuletzt geplanten Ende. Der Dashboard-Komponentenstatus wechselte um 21:46:51 Uhr zu operational, das zweite Ticket schloss um 21:47:19 Uhr. Vom Abschluss des RPKI-Tickets um 21:06:58 Uhr bis zum Betriebslabel der Komponente vergingen 39 Minuten und 52 Sekunden; zwischen den beiden Ticketabschlüssen lagen 40 Minuten und 21 Sekunden. 21:59 Uhr war ein revidierter Plan, kein tatsächlicher Schluss. Das sind Abstände zwischen veröffentlichten Statusangaben, keine gemessene Ausfalldauer.

Die Labels brauchen präzise Grenzen. completed ist ein Abschlussvermerk für ein Ereignis. under_maintenance ist der im Statussystem veröffentlichte Zustand einer Komponente. Keines misst, ob ein Mitglied um 21:07 Uhr einloggen, um 21:22 Uhr das Dashboard öffnen oder um 21:31 Uhr eine ROA absenden konnte. Laut RIPEs Anleitung für gehostetes RPKI greift ein Mitglied über ein mit dem LIR verbundenes RIPE-NCC-Konto auf das Dashboard zu, um Route Origin Authorizations zu verwalten. Die Access-Dokumentation nennt das Dashboard als Ziel hinter demselben Zugang. Eine einzige Mitgliedsaufgabe geht durch beide Wartungsbereiche.

Die offene Frage lautet daher nicht bloß, welche Uhr zuerst stehen blieb. Nach dem Abschluss des speziellen Dashboard-Tickets blieb das Dashboard in der zweiten Wartung und im Komponentenfeed markiert. War das zweite Ticket nun für seinen Zustand maßgeblich? Oder hinkte das öffentliche Label einem bereits funktionierenden Dienst hinterher? RIPEs Aufzeichnungen enthalten keinen erfolgreichen Test des kompletten Mitgliedswegs. Selbst eine problemlos erreichbare Anwendung wäre aus diesen Anzeigen allein nicht erkennbar. Die Statusseite verlangt vom Betreiber eine Antwort, statt dem Leser die Deutung zweier Karten zu überlassen.

Eine brauchbare Korrektur wäre klein: je Komponente ein maßgeblicher Zustand mit Verweis auf das offene Ereignis, das ihn setzt; ein Zeitstempel für jede Änderung an Komponentenliste oder geplanten Endzeiten; zum Abschluss ein Ergebnis für Anmeldung, Dashboard-Aufruf und ROA-Übermittlung. Dann ist „fertig“ eine Information für den Netzbetreiber und kein Pokal für die Ticketverwaltung.

Originale Aufzeichnungen des RIPE NCC