Sasha Romijns NRTMv4-Entwurf sagte nicht, was sie meinte

Zusammenfassung

Sasha Romijn, ursprüngliche Entwicklerin und Maintainerin von IRRD, schrieb an NRTMv4 mit, dem Protokoll für die Synchronisierung von Internet-Registry-Spiegeln.
Als IRRD und RIPE NCC getrennte Implementierungen bauten, wich das Verhalten voneinander ab. Romijn las den Entwurf erneut: Der Text beschrieb eine andere Regel als die beabsichtigte.
Ein IESG-Reviewer bemerkte später, dass ein IPv6-Beispiel route statt route6 verwendete. Am 2. November 2026 wartete das IETF-Dokument noch auf die endgültige Freigabe des RFC Editors.

Sasha Romijn hielt zunächst die RIPE-NCC-Implementierung für falsch. Dann las sie ihren Entwurf erneut. Der Text sagte tatsächlich etwas anderes als das, was sie gemeint hatte.

Romijn arbeitet unabhängig. Sie entwickelte IRRD Version 4 ursprünglich und betreut die Software bis heute; außerdem ist sie Mitautorin von NRTMv4. Das Protokoll verteilt Einträge aus Internet Routing Registries von einer maßgeblichen Datenbank an Spiegel. Netzbetreiber verwenden IRR-Daten für Routenfilter und Netzkonfiguration. Ein Spiegel muss erkennen lassen, ob er auf dem aktuellen Stand ist.

NRTMv3 trennte den Datenbank-Dump von späteren Änderungsabfragen. Die Bedeutung einer Seriennummer hing von der jeweiligen Serverinstanz ab, und der Protokollablauf lieferte nur schwache Hinweise darauf, ob ein Spiegel aufgeholt hatte. NRTMv4 veröffentlicht Snapshots und kleinere Delta-Dateien über HTTPS. Eine signierte Update Notification File verweist auf diese Dateien und ihre Hashes. Clients können Signatur und Hashes prüfen.

Der Text wurde erst dann hart geprüft, als mehr als ein Codebestand daraus entstand. Romijn und RIPE NCC entwickelten ihre Implementierungen parallel, aber getrennt. Als sie verschieden reagierten, vermutete Romijn zunächst einen Fehler bei RIPE NCC. IRRD setzte ihre Absicht um; der Entwurf formulierte eine andere Regel. Der Abgleich legte Mängel in frühen Fassungen offen, bevor sich eine lokale Auslegung still zur Norm entwickeln konnte.

Ein Review fand denselben Typ Fehler in einem kleinen Beispiel. Für eine IPv6-Route musste das RPSL-Objekt route6 heißen; im Entwurf stand route. Ein IESG-Reviewer bemerkte das. Es war ein falsches Beispiel, das während der Prüfung korrigiert werden konnte, kein Produktionsausfall.

Auf der RIPE 92 berichtete Romijn im Mai 2026 von fünf interoperablen Implementierungen. RIPE NCC betrieb NRTMv4 bereits produktiv; IRRD unterstützte Client- und Serverbetrieb. Die aktuelle RIPE-Dokumentation nennt den Produktiv-Endpunkt der Update Notification File und den öffentlichen Schlüssel. Das IETF-Datentracker führt Entwurf -11 in der RFC-Editor-Warteschlange; die endgültige Freigabe stand am 2. November noch aus.

Dass ein Programm bei seiner Autorin läuft, beweist wenig über den Text, der es beschreiben soll. Eine zweite Implementierung liest dieselben Wörter ohne den Vorteil der Absicht. Genau dort zeigt sich, ob eine technische Regel trägt.