APNIC ergänzt 92 WHOIS/RDAP-Berichte, lässt den Reparaturstatus offen

Zusammenfassung

Im Oktober-Archiv von APNIC sind nun alle 92 WHOIS/RDAP-Berichte für den Zeitraum vom 23. Oktober, 04:00 UTC, bis zum 27. Oktober, 00:00 UTC, aufgeführt. Berichte und MD5-Dateien tragen dieselbe Änderungszeit: 29. Oktober, 10:16 Uhr in der UTC+10-Anzeige des Verzeichnisses.
In der Meldung vom 16. Oktober fehlen weiterhin Endzeit und Dauer. Eine Prüfsumme bestätigt die heruntergeladenen Bytes; das veröffentlichte APNIC-Schema sagt nicht, ob die zugrunde liegenden Protokolle für jede Stunde vollständig waren.

92 Dateien, ein gemeinsamer Zeitstempel

Am 27. Oktober fehlten im Archiv 92 aufeinanderfolgende Stundenberichte. Zwei Tage später standen alle Berichte samt MD5-Dateien unter einer gemeinsamen Änderungszeit: 29. Oktober, 10:16 Uhr in der UTC+10-Anzeige. Das Fenster reicht vom 23. Oktober, 04:00 UTC, bis zum 27. Oktober, 00:00 UTC. Wer heute alle Oktoberdateien einliest, erhält 92 Stundenwerte mehr als mit dem früheren Archivstand.

Die Verzeichnisliste zeichnet die Rückkehr mit einem einzigen Zeitstempel nach. Jeder erwartete Bericht und jede zugehörige .md5-Datei ist als geändert am 29. Oktober um 10:16 Uhr aufgeführt, der UTC+10-Zeit des Verzeichnisses. Für den ersten und letzten Bericht nennen die HTTP-Kopfzeilen 00:16:28 UTC. Ich habe beide gzip-Dateien geladen, ihre ausgewiesenen Intervalle geprüft und den MD5-Wert der Dateien mit APNICs veröffentlichten MD5-Prüfdateien verglichen. Der erste Bericht umfasst den 23. Oktober von 04:00 bis 05:00 UTC; der letzte den 26. Oktober von 23:00 bis zum 27. Oktober, 00:00 UTC.

Auch der aktuelle Datenstrom ist weitergelaufen. Das jüngste WHOIS/RDAP-JSON deckt den Zeitraum vom 30. Oktober, 23:00 UTC, bis zum 31. Oktober, 00:00 UTC, ab. Sein MD5-Wert stimmt mit den heruntergeladenen Bytes überein. Auf Dateiebene sind die fehlenden Stunden zurück und die stündliche Veröffentlichung ist aktuell.

Der Störungsbericht hat diese Bewegung nicht mitgemacht. APNIC schrieb am 16. Oktober, dass Probleme bei der Log-Verarbeitung die Statistiken ab 10:00 Uhr UTC+10 unvollständig machten. Die Generierung sei vorerst abgeschaltet; betroffene Dateien würden nach Behebung des Problems erneut veröffentlicht. Die Felder für Ende und Dauer sind noch leer. Im Service-Update-Verzeichnis steht die Meldung weiterhin, ein eigener Abschluss für diese WHOIS/RDAP-Störung fehlt.

Alle 92 Berichte stehen wieder im Archiv. Die APNIC-README listet die Felder eines Stundenberichts: Intervall, Abfragezahl, Verteilung nach Abfragetyp, Zahl der ASNs und Kennzahlen je ASN. Die öffentlichen Unterlagen enthalten keine Revisionskennung, keinen Vollständigkeitsstatus je Stunde und kein Wiederherstellungsmanifest. Die zwei geprüften MD5-Dateien stimmen mit den heruntergeladenen Berichten überein. Für die Herkunft der verarbeiteten Protokolle und den Status jeder betroffenen Stunde fehlt ein Verarbeitungsprotokoll.

Wer den Stand vom 27. Oktober mit einem aktuellen Download vergleicht, hat zwei verschiedene Zeitreihen: Die erste lässt 92 Stunden aus, die zweite enthält sie. Dieselbe Auswertung verarbeitet dadurch unterschiedliche Intervalle. Für einen nachvollziehbaren Vergleich braucht es den archivierten Stand und den Status jeder nachgelieferten Stunde. APNICs Meldung nennt weiterhin keine Endzeit für den seit dem 16. Oktober betroffenen Zeitraum.

Der fehlende Status für jede zurückgekehrte Stunde

APNIC könnte die Sache mit einem Manifest je Intervall schließen: betroffene UTC-Stunde, Wiederherstellungsstatus, Kennung des Verarbeitungslaufs, aktuelle Prüfsumme und Endzeit der Störung. Ist eine Statistik noch unvollständig, gehört das in genau diese Zeile. Nutzer könnten dann wieder eingestellte Dateien von bestätigten Statistiken unterscheiden und dieselbe Zeitreihe später erneut berechnen.

Der Zeitstempel im Verzeichnis dokumentiert die Rückkehr der Dateien. Ein Reparaturprotokoll sollte Verarbeitungslauf und Status jedes Intervalls nennen. APNIC hat die fehlenden Stunden ins Archiv gestellt; die öffentliche Beschreibung ihrer Verarbeitung fehlt noch.