Zusammenfassung

  • RIPE NCC stellte nicht an einem Tag alles um: Die neue Datenbank ging am 23. April 2001 in Betrieb, auto-dbm wurde am 14. Mai RPSL-only, und die Umwandlung von RIPE-181 endete am 15. Oktober.
  • Die Quellen verbinden Andrei Robachevsky mit der Arbeit als Database Group Manager: 2000 erläuterte er neue Abfragefunktionen, 2001 unterzeichnete er die Mitteilung über den Abschluss der ersten Migrationsphase.
  • Ein umgewandeltes Datenbankobjekt belegt, wie ein Register einen Eintrag führt. Es beweist weder das Eigentum an einer Ressource noch eine gegenwärtige BGP-Ankündigung oder den tatsächlichen Paketweg.

Ein Umzug mit mehreren Schnittstellen

Die Mitteilung vom 14. Mai war keine abstrakte Erfolgsmeldung. Sie legte fest, dass auto-dbm nur noch RPSL-Updates akzeptierte. Für RIPE-181 gab es den Umweg über auto-181, der das alte Format bis zum angekündigten Stichtag 15. Oktober umwandelte. auto-rpsl nahm ebenfalls RPSL entgegen. Für die Testdatenbank galten dieselben Einteilungen.

Ein Betreiber musste deshalb mehr wissen als den Stand der Datenbankmigration. Entscheidend war, welches Format ein bestimmter Client erzeugte, wohin sein Skript die Änderung schickte, welche Autorisierung dort galt und wie lange die Übergangslösung bestehen blieb. Die öffentlichen Mitteilungen sagen nicht, wie viele Programme geändert werden mussten oder ob alle Nutzer Ausfälle erlebten. Sie machten jedoch die maßgeblichen Adressen, Formate und Fristen überprüfbar.

Schon am 23. April hatte Robachevsky eine erste Phase als abgeschlossen gemeldet: Die neue Version laufe, die Objekte seien automatisch nach RPSL überführt und geladen worden. Damit war aber nicht jede Ein- und Ausgabe sofort auf das neue Format beschränkt. In dieser ersten Phase nahm auto-dbm RIPE-181 noch mit Einschränkungen an: leere oder falsch geschriebene Attribute waren unzulässig, PGP-Authentifizierung wurde über diesen Weg nicht unterstützt, und die RPSL-Autorisierungsregeln galten bereits. auto-rpsl akzeptierte RPSL direkt. Die Migration veränderte damit zugleich Datenrepräsentation und erlaubte Schreibpfade.

Eine Abfrage beantwortet eine bestimmte Frage

In einer Nachricht vom August 2000 beschrieb Robachevsky als Database Group Manager die neue v3-Abfrageschnittstelle und bat um Rückmeldungen. Exakte und weniger spezifische Suche hatten unterschiedliche Semantik: Der exakte Treffer entsprach genau dem eingegebenen Bereich; die weniger spezifische Suche gab den kleinsten größeren Bereich zurück, der ihn vollständig enthielt. -K reduzierte die Antwort auf Primärschlüssel. Eine Source-Abfrage lieferte Datenbank- und Spiegelinformationen, darunter verfügbare Seriennummernbereiche; inverse Abfragen suchten nach Kontaktattributen.

Das macht einen Datensatz nicht wahrer. Es legt fest, welchen Ausschnitt ein Programm anfordert und erhält. Eine Schlüsselantwort kann die Verarbeitung erleichtern und gleichzeitig Kontext weglassen. Ein enthaltender Bereich ist kein exakter Treffer. Spiegelinformationen beschreiben eine Replikationsschnittstelle, keine vollständige Messung der globalen Routingtabelle. Wenn sich eine Schnittstelle ändert, kann daher Überwachungssoftware anders reagieren, obwohl ein Datensatz selbst unverändert aussieht.

Der als Entwurf gekennzeichnete Protokollentwurf der RIPE-38-Datenbankgruppe verzeichnet Robachevskys zwanzigminütige Präsentation zur Migration. Er nennt Abfrage- und Update-Nutzer, Skripte und nahezu in Echtzeit arbeitende Spiegel als betroffene Gruppen und führt RPSL, Zugriffskontrolle, Datenbankformat und Spiegelprotokoll an. Als Entwurf belegt das Dokument, was in dieser Fassung über Sitzung und Präsentation festgehalten wurde; es beweist nicht allein, dass später jede Frist eingehalten wurde. Dafür sind die danach veröffentlichten Betriebsmitteilungen und der Jahresbericht wichtiger.

Eine Übergangsfrist verteilt Arbeit

Im Jahresbericht 2001 beschrieb RIPE NCC den Wechsel als sechsmonatigen Prozess vom 23. April bis zum 15. Oktober. Die Organisation betrieb die Konvertierung und veröffentlichte Regeln. Objektverwalter mussten Update-Generatoren prüfen, Spiegelbetreiber Format und Synchronisierung kontrollieren, und Client-Autoren mussten die neue Abfragesemantik berücksichtigen. Die Quellen beziffern weder Arbeitsstunden noch Kosten und listen nicht jede betroffene Implementierung auf. Sie zeigen aber die Stellschrauben, die das Register kontrollierte: akzeptierte Syntax, Autorisierung, Eingangsadressen und Abschaltdatum der Brücke.

Verantwortung für ein gemeinsames Register endet nicht mit dem erfolgreichen Import der Daten. Nutzer brauchen klare Angaben zu Schreibformat, Berechtigung, Ergebnisumfang, Replikation und Auslaufen einer Übergangslösung. Das sind Pflichten des Dienstes. Sie machen den Betreiber weder zum Eigentümer der eingetragenen Nummernressourcen noch zum politischen Entscheider über jede Organisation, die auf den Dienst angewiesen ist.

RFC 2622 zieht eine weitere Grenze. Die Spezifikation definiert RPSL zur Beschreibung von Routing-Policies und erläutert die Rolle des Maintainer-Objekts bei der Autorisierung von Änderungen. Als Autoren führt sie Alaettinoglu, Villamizar, Gerich, Kessens, Meyer, Bates, Karrenberg und Terpstra auf, nicht Robachevsky. Aus seiner belegten Rolle in der Migration folgt nicht, dass er RPSL erfunden oder RFC 2622 verfasst hat.

Registereintrag und BGP-Beobachtung

Ein RIPE-Datenbankeintrag, ein RPSL-Policy-Objekt im Internet Routing Registry und eine BGP-Beobachtung beantworten verschiedene Fragen. Der konvertierte Eintrag zeigt, was die Datenbank zu diesem Zeitpunkt führte. Das Policy-Objekt beschreibt eine registrierte Absicht. Ein Route Collector kann zeigen, dass eine bestimmte Messstelle zu einer bestimmten Zeit eine BGP-Ankündigung sah. Keine dieser Quellen ersetzt die anderen. Der Eintrag beweist weder gegenwärtige Erreichbarkeit noch Paketlieferung, rechtliches Eigentum oder dass alle Router eine eingetragene Policy befolgen.

Ist ein Eintrag veraltet, muss man Datenqualität und Schreibberechtigung untersuchen. Verschwindet ein Präfix aus einer Routing-Sicht, braucht es Routing-Messdaten. Ist strittig, wer einen Eintrag ändern darf, löst ein Formatwechsel den Streit nicht. Die belegbare Bedeutung der Migration liegt enger: Sie machte Schnittstellen, Fristen und Verantwortlichkeiten eines öffentlichen Registers sichtbar, ohne das Register mit den registrierten Ressourcen oder dem tatsächlichen Netz gleichzusetzen.

Was sich über Robachevsky sagen lässt

Im August 2000 unterzeichnete Robachevsky als Database Group Manager eine Nachricht zu den v3-Abfragen. Im April 2001 zeichnete er für die Mitteilung über die erste Phase, automatische Konvertierung und vorübergehende RIPE-181-Beschränkungen. Der RIPE-38-Entwurf nennt ihn als vorgesehenen Präsentator. Das reicht für das Bild eines Managers, der den Wechsel erklärte und Rückmeldungen einholte. Es belegt nicht, dass er die Konvertierungssoftware schrieb, alle Regeln allein festlegte oder jeden Datensatz prüfte.

Wer ein öffentliches Register betreibt, übernimmt Verantwortung für verlässlichen Zugang und nachvollziehbare Änderungen. Dadurch wird er nicht Eigentümer der registrierten Ressourcen. Die Quellen tragen Aussagen über Zeitpunkte, Schnittstellen und Regeln. Sie belegen weder die individuellen Kosten der Teilnehmer noch eine lückenlose Umstellung aller Nutzer oder den heutigen Zustand irgendeiner Route.

Quellen