Zusammenfassung

  • Der am 10. September ergänzte Test erwartet für AS64495-AS131071 ebenso wie für AS131070-AS131072 den Reserved-Status, obwohl beide den Testbereich 64496-131071 an jeweils einer Seite um eine Nummer überschreiten.
  • Die Implementierung prüft irgendeine Überlappung; der RDAP-Mapper macht daraus einen einzigen Objektstatus. Ohne die Grenzen darf dieser Status nicht auf jede enthaltene ASN übertragen werden.

Die beiden Testfälle verlassen denselben Korridor in entgegengesetzter Richtung. Der erste beginnt eine Nummer zu früh, der zweite endet eine Nummer zu spät. Beide gelten als reserviert. Ein vollständig außerhalb liegender Block dagegen nicht. Entscheidend ist also nicht, ob alle Elemente im reservierten Bereich liegen, sondern ob sich die Intervalle überhaupt schneiden.

Im aktuellen IANA-Register hat diese eine Nummer Gewicht. AS64495 beendet einen RIPE NCC zugewiesenen Bereich; mit AS64496 beginnt Dokumentationsraum. Am oberen Rand ist AS131071 reserviert, während AS131072 bereits einen APNIC zugewiesenen Bereich eröffnet. Die Testblöcke enthalten an ihrer jeweiligen Kante folglich unterschiedliche globale Dispositionen.

Der Code entspricht diesem Befund. ReservedResources.isReservedAsBlock zerlegt den Schlüssel in ein numerisches Intervall und fragt, ob irgendein konfigurierter reservierter Bereich damit überlappt. Vollständige Enthaltenheit ist keine Bedingung. RdapObjectMapper verwendet das Ergebnis anschließend, um für den AS-BLOCK zwischen RESERVED und ACTIVE zu wählen.

Diese konservative Richtung ist als Sperre nachvollziehbar. Würde nur vollständige Enthaltenheit zählen, könnte ein großer aktiver Block einen reservierten Kern umfassen und dennoch undifferenziert aktiv erscheinen. Die Überlappungsprüfung übersieht den Kern nicht. Sie liefert jedoch kein Maß und keinen Ort der Überschneidung. Verlässt das Wort den ursprünglichen Entscheidungskontext, reist seine Begründung nicht automatisch mit.

Ein sorgfältiger RDAP-Nutzer speichert Schlüssel, Anfang, Ende und Status und kann sie später erneut mit IANA abgleichen. Ein anderes System könnte den Block in einzelne ASN-Zeilen auflösen und reserved überall eintragen. Dann bekämen AS64495 oder AS131072 den Status ihres Nachbarn, obwohl IANA sie zugewiesenen Bereichen zurechnet. Die Quellen belegen keinen solchen Fehler bei einem benannten Dienst. Sie zeigen einen konkreten Informationsverlust, gegen den sich ein Datenmodell prüfen lässt.

AS-BLOCK-Objekte haben laut RIPE-Database-Dokumentation eine administrative Funktion. Sie delegieren einen AS-Nummernbereich an ein RIR oder markieren ihn als reserviert; nur Datenbankadministratoren dürfen sie anlegen. Die Maintainer des übergeordneten Blocks wirken außerdem an der Berechtigung für neue aut-num-Objekte mit. Dieser Kontext erklärt vorsichtige Behandlung, macht den Mapperstatus aber weder zur IANA-Zuweisung noch zur BGP-Ursprungsprüfung oder Erreichbarkeitsaussage.

Auch der Neuigkeitswert hat eine klare Grenze. Edward Shryanes Commit vom 10. September fügt eine 53 Zeilen lange Testdatei hinzu, ändert aber weder die Methode noch den Mapper. Das jüngste erfasste Tag, WHOIS 1.124.1, wurde am 31. August veröffentlicht. Der Test ist somit neuer als dieses Tag. Daraus folgt nicht, wann die vorhandene Logik produktiv wurde, ob der Testcommit ausgerollt ist oder ob in der öffentlichen Datenbank tatsächlich ein gemischter Grenzblock vorkommt.

Die belastbare Nachricht lautet deshalb: Die Überlappungssemantik ist jetzt als ausführbarer Test sichtbar. Statt die vorsichtige Regel vorschnell abzuschwächen, kann RIPE NCC ihre Entscheidungsgrundlage mitgeben: Kandidatenbereich, geschnittenes Reservierungsintervall, Registerstand und Mapperversion. Dann bleibt „dieses Objekt berührt reservierten Raum“ von „jede ASN dieses Objekts ist reserviert“ trennbar.

Quellen