Zusammenfassung

  • AFRINICs signierte Delegationsstatistik vom 7. September führte AS36887, AS36911, AS36921 und 41.204.224.0/19 als reserved; am 8. September standen alle vier als allocated in Nigeria unter derselben undurchsichtigen Inhaberkennung.
  • Die wieder erschienenen Datumswerte liegen im Jahr 2006. Nach AFRINICs Format sind das Daten der ersten Zuteilung, nicht der jüngsten Statusänderung.
  • Das aktuelle RDAP zeigt alle vier Ressourcen als aktiv unter DIRECT ON PC LTD, mit vier Registrierungsvorgängen am 7. September 2026 und demselben Änderungszeitpunkt um 14:19 UTC.
  • Keine öffentliche Oberfläche klassifiziert den Vorgang als Korrektur, Wiedereinsetzung, Neuzuweisung, Prüfergebnis oder anderen autorisierten Übergang. Ein datensparsamer Ressourcen-Übergangsbeleg würde genau diese Lücke schließen.

Vier Zeilen wechselten gemeinsam die Seite

Die erweiterte Datei vom 7. September setzt einen klaren Ausgangspunkt. Die drei ASNs und der Block mit 8.192 Adressen ab 41.204.224.0 stehen auf reserved. Das Länderfeld lautet ZZ; Datum und undurchsichtige Inhaberkennung sind leer.

Der Snapshot vom 8. September gibt dem Bündel eine andere öffentliche Bedeutung. Das Land ist Nigeria, der Status allocated, und jede Zeile trägt F36DCCF2. Die ASN-Daten lauten 16. Januar, 4. August und 7. November 2006. Beim /19 steht der 1. August 2006.

Die Zeitachse lädt zu einer falschen Abkürzung ein. Wer nur die aktuelle Datei liest, sieht vier alte Zuteilungen. Wer die Dateien vergleicht, sieht einen gegenwärtigen Registervorgang. Daraus wird noch keine neue September-Zuteilung.

Altes Zuteilungsdatum und neues Registerereignis

AFRINICs README zur erweiterten Datei definiert das Datum als Tag der Zuteilung oder Zuweisung. Das RIR Statistics Exchange Format beschreibt die Datei als Momentaufnahme des aktuellen Zustands ohne Transaktions- oder Verlaufsdetails. Das ist eine vertretbare Architektur: Eine kompakte Statistik soll den heutigen Stand liefern, nicht die vollständige Akte hinter jeder Zeile.

RDAP stellt eine zweite Uhr daneben. AS36887, AS36911, AS36921 und 41.204.224.0/19 sind aktiv auf DIRECT ON PC LTD registriert. Ihre Registrierungsereignisse liegen am 7. September um 12:03, 12:06, 12:08 und 12:18 UTC; last changed ist jeweils 14:19.

Die zeitliche Nähe macht den Wechsel am Folgetag nachvollziehbar. Sie benennt weder die Klasse noch die Autorität des Vorgangs. Registration ist ein RDAP-Ereignistyp, keine Begründung.

Das Bündel hat die Grenze schon früher überquert

Die Stichprobe zeigt mehrere Umkehrungen. Am 1. Januar 2021 waren alle vier Ressourcen mit denselben 2006er Daten und derselben Kennung allocated. 2022 standen sie auf reserved, 2023 wieder auf allocated. Der Snapshot von 2025 führte sie erneut als reserved, ebenso die Datei vom 7. September 2026.

Damit sind wiederholte Änderungen des veröffentlichten Zustands belegt. Der genaue Tag und der Grund früherer Übergänge bleiben offen. Die undurchsichtige Kennung hilft beim Gruppieren innerhalb der Serie, doch AFRINIC garantiert ihre Beständigkeit zwischen Versionen ausdrücklich nicht.

Die stärkste Verteidigung steckt in der Formatspezifikation

Eine Momentaufnahme muss keine Fallakte sein. AFRINICs Dateien sind maschinenlesbar, signiert und verwenden definierte Zustände. RDAP nennt die aktuelle Organisation und aktuelle Ereignisse. Wenn der Vorgang historische Kontinuität erhält, kann es gerade richtig sein, die 2006er Daten nicht künstlich auf 2026 zu verjüngen.

Ebenso wenig sollte AFRINIC private Korrespondenz, personenbezogene Kontakte, Kontodaten oder geschütztes Rechtsmaterial veröffentlichen. Die angemessene Forderung ist kleiner: Wechselt ein Bündel knapper Ressourcen zwischen zwei öffentlichen Zuständen, sollte eine grobe Übergangsklasse samt Autoritätsgrund sichtbar sein.

Ein knapper Wechselbeleg genügt

Ein Ressourcen-Übergangsbeleg könnte die Hashwerte der signierten Vorher- und Nachher-Dateien mit einer datensparsamen Bündelreferenz, dem alten und neuen Status sowie Wirksamkeits- und Veröffentlichungszeit verbinden. Eine grobe Klasse — Datenkorrektur, Wiedereinsetzung, Neuzuweisung, Prüfergebnis oder anderer autorisierter Vorgang — reicht aus, ohne vertrauliche Nachweise offenzulegen.

Hinzu kommen die Art der Autorität, der Grund für die beibehaltenen 2006er Daten, ihr Verhältnis zu den RDAP-Ereignissen von 2026, die abgeglichenen öffentlichen Registerflächen und der Ort einer späteren Korrektur. So bleibt alte Chronologie korrekt, ohne die aktuelle Entscheidung unsichtbar zu machen.

Quellen