Zusammenfassung

  • Ein am 17. August zirkulierter RIPE NCC-Entwurf stellt die einschlägigen Teile von SG2-C-0196 klar und ersetzt sie. RIPE NCC befürwortet den Fortbetrieb von Public ENUM und schlägt keine Schließung vor.
  • Bei 46 geprüften Delegierungen zeigten 23 auf oberster Delegierungsebene kein DNS-Problem, 17 wirkten nicht betriebsfähig, sechs hatten Teilprobleme. Die letzten 23 werden als Registerpflege- und Datenqualitätsfälle behandelt, nicht als Urteil über das System.
  • RIPE NCC bittet SG2, im September die überarbeiteten Verfahren für einzelne nicht betriebsfähige oder abgelaufene temporäre Delegierungen zu bestätigen. Bis 25. August läuft die Kommentierung; weder endgültige Erklärung noch Inkrafttreten oder Entfernung sind erfolgt.

Aus einer Schnittstellenfrage wurde eine Architekturfrage

Public ENUM verbindet E.164-Telefonnummern mit dem DNS. Die ITU-Seite beschreibt ENUM als Methode, E.164-Ländercodes in das Namenssystem einzutragen. RFC 6116 legt fest, wie eine Rufnummer in einen DNS-Namen umgewandelt und mit Kommunikationszielen verknüpft wird.

Mehrere Stellen tragen unterschiedliche Verantwortung. Das IAB verantwortet die arpa-Infrastruktur und hat RIPE NCC mit dem Betrieb von e164.arpa beauftragt. ITU-T koordiniert die E.164-Seite. Nationale Stellen und benannte Betreiber pflegen einzelne Delegierungen. RFC 3245 dokumentiert dieses Kooperationsmodell, keinen Alleinentscheider.

SG2-C-0196 ging im Februar von einer engeren Betriebsfrage aus: Sollten ENUM-Domainobjekte über RDAP erreichbar sein? Der Beitrag stellte zugleich weitergehende Fragen zur Zukunft von ENUM und e164.arpa. Nach Gesprächen mit IAB, Delegierungsbetreibern und RIPE-Community räumt der neue Entwurf ein, dass diese Erweiterung die etablierte Aufgabenteilung nicht genau wiedergab.

Die Korrektur ist eindeutig. RIPE NCC unterstützt den Fortbetrieb und schlägt keine Schließung vor. SG2-C-0196 ist keine Aufforderung mehr, SG2 solle die technische oder architektonische Zukunft bestimmen. Der Auftrag lautet nun, ein Verfahren für einzelne mangelhafte Delegierungen nutzbar zu machen.

Eine Hälfte mit Befund spricht nicht für das ganze Verzeichnis

Die Zahlen verlangen Arbeit. Von 46 Delegierungen waren 23 im oberen DNS-Test unauffällig. 17 schienen nicht zu funktionieren, sechs nur teilweise. Ein glaubwürdiges Register darf aufgegebene oder falsch beschriebene Einträge nicht unbegrenzt mitschleppen.

Der Test erklärt jedoch nicht automatisch die Ursache. Hinter einer fehlenden Antwort können Aufgabe, Migration, eine vorübergehende Störung, ein Konfigurationsfehler oder veraltete Kontakte stehen. Eine wenig genutzte Delegierung kann weiterhin gewollt sein. Der Test misst auch weder betroffene Nutzer noch abhängige Anwendungen oder die Kosten einer übereilten Entfernung.

Der August-Entwurf begrenzt die Aussagekraft sauber. Er bezeichnet die Befunde als Problem von Registerpflege und Datengenauigkeit. Für eine systemweite Schlussfolgerung zu Public ENUM reichen sie nicht. Jeder der 23 problematischen Zweige erhält potenziell einen eigenen Sachverhalt; die 23 unauffälligen Zweige werden nicht mehr in eine Schließungsfrage hineingezogen.

Das ist keine Nachsicht. Im Gegenteil: Einzelfälle verlangen erneute Messung, Kontakt, begründete Klassifizierung, Frist und einen nachvollziehbaren Weg zur Wiederherstellung.

Im September soll ein Fallverfahren wirksam werden

Der Bericht der SG2-Sitzung im Februar hält fest, dass die revidierten ENUM-Übergangsverfahren in TD423 Rev.1/PLEN zum nächsten Treffen vom 9. bis 18. September in Kraft treten sollen, abhängig von den Schlussfolgerungen aus der TSB-Konsultation.

TSB-Rundschreiben 123 fragte Mitgliedstaaten nach einer möglichen Schließung von E.164-Ländercode-Delegierungen in e164.arpa. Die beim IAB eingegangene Liaison nannte den 15. August als Frist. Nach dem neuen Entwurf können diese Antworten Status und Absicht eines nationalen Einzelfalls erhellen. Sie sollen nicht zu einem technischen Gesamtvotum addiert werden.

RIPE NCC stellt zwei Anträge. SG2 soll TD423 Rev.1/PLEN als Verfahren für nicht betriebsfähige oder abgelaufene temporäre Delegierungen bestätigen. Breitere technische oder langfristige Fragen sollen weiter mit IAB, RIPE NCC, einschlägigen IETF-Verfahren und Betroffenen koordiniert werden.

Nach Inkrafttreten will RIPE NCC die technische Bewertung erneuern, Betreiber soweit möglich ansprechen und begründete Fälle an das TSB übermitteln. Diese Reihenfolge verhindert Automatismus: erst neu beobachten, dann Erklärung oder Reparatur suchen, zuletzt den Fall vorlegen. Ein alter Messzeitpunkt darf keinen Löschbefehl erzeugen.

Das IAB trennte Informationswert und Entscheidungsmacht

Die IAB-Antwort vom Juni erkennt an, dass Mitgliedstaaten wichtige Betriebsinformationen beisteuern können. Zugleich dürfe deren Konsultation allein weder über e164.arpa noch über den Status von ENUM entscheiden. Eine Einstufung von RFC 6116 als Historic gehört in den offenen IETF-Standardprozess; eine Aufgabe des Namensraums erfordert Koordination der zuständigen technischen und betrieblichen Stellen.

Damit ist auch geklärt, wer welchen Beleg liefern kann. Die nationale Stelle kennt ihre Absicht. Der Betreiber kennt Reparatur und laufenden Dienst. RIPE NCC kann messen, die Zone betreiben und einen Zeitverlauf dokumentieren. SG2 und TSB verwalten das E.164-Verfahren. Die IETF entscheidet über den Protokollstatus. Die Belege dürfen einander informieren, aber nicht gegenseitig die Zuständigkeit ersetzen.

Der August-Entwurf folgt dieser Ordnung. RIPE NCC gibt die Pflegepflicht nicht auf, erweitert den Betreiberstatus aber nicht zu Eigentum an der Architektur. SG2 erhält einen klaren Auftrag für Länderfälle, ohne allein über die DNS-Struktur entscheiden zu sollen.

Eine unabhängige Darstellung von RIPE NCC zählt ENUM-Koordination zu seinen Diensten. Lu Hengs The Policy Mirror liefert den institutionellen Maßstab: Vertrauen entsteht durch eine genaue, begrenzte Registerfunktion, nicht dadurch, dass ein Wartungsbefund zur Zuständigkeit über das umgebende System vergrößert wird.

RDAP ist wieder eine Produkt- und Gemeinschaftsfrage

Der Entwurf trennt RDAP-Unterstützung ausdrücklich vom Fortbetrieb von Public ENUM. Eine moderne Abfrageoberfläche lässt sich nach Nachfrage, Sicherheit, Kosten und Prioritäten beurteilen. Die Zukunft des Namensraums benötigt Erkenntnisse über tatsächliche Abhängigkeiten, Standardstatus, Zuständigkeiten und Übergang. Eine fehlende Funktion ist kein Nachweis für architektonische Überflüssigkeit.

Geringe Nutzung bleibt ein Signal, aber ein begrenztes. Sie kann für einen kleinen Investitionsrahmen sprechen. Sie kann nicht ohne Weiteres erklären, ob wenige Nutzer besonders kritische Abhängigkeiten haben.

Jeder Delegierungsfall sollte Zeitpunkt und Ziel der neuen Prüfung, Fehlerklasse, Kontaktversuch, Antwortfrist, geplante Maßnahme und Wiederherstellungsweg ausweisen. Wiederherstellung ist wesentlich, weil technische Zustände und nationale Absichten veränderlich sind. Ein vorübergehender Fehler darf nicht ohne Korrekturmöglichkeit dauerhaft werden.

Die Richtung ist korrigiert, der Text noch nicht endgültig

Bis 25. August kann die Community Stellung nehmen. Danach folgt die endgültige Liaison, im September die Entscheidung von SG2. Dieser Beitrag berichtet weder eine bereits erfolgte Entfernung noch behauptet er, dass alle 23 Befunde dauerhaft sind.

Der Statusvorbehalt macht die Änderung nicht klein. Im Februar trugen RDAP-Frage und Betriebsinventar eine systemweite Zukunftsfrage. Im August trennt RIPE NCC beides. Für 23 Befunde braucht es 23 begründete Fälle; für die Zukunft von ENUM braucht es ein anderes Verfahren und breitere Belege.

Das beste September-Ergebnis wäre deshalb nüchtern: eine wiederholbare Methode zum Bestätigen, Reparieren, Zurückziehen und Wiederherstellen. Kehrt eine Gesamtvorlage zurück, muss sie Nutzung, Abhängigkeiten, Alternativen, Übergangskosten und Protokollstatus separat belegen. Eine DNS-Prüfung kann die Debatte eröffnen. Sie kann sie nicht im Namen aller beenden.

Quellen