Zusammenfassung

  • Die am 13. September 2026 veröffentlichte Revision 03 bleibt ein individueller Internet-Draft, kein von REGEXT übernommenes Dokument und kein RFC.
  • Der Registrierungsantrag verweist nun auf eine separat veröffentlichte feste Spezifikation. Datenmodell und Übertragungsformat bleiben unverändert.
  • Im geprüften IANA-Verzeichnis fehlt reliabilityAssessment. Ein im Dokument formulierter Antrag belegt weder Eingang noch Prüfung oder Genehmigung.
  • Die Festlegung eines Namens ersetzt weder Standardisierungskonsens noch lokale Entscheidungen über Implementierung und Maßnahmen.

Geändert wird, worauf der Name verweist

Wer eine Erweiterung implementiert, muss wissen, welche Spezifikation hinter ihrem Namen steht. Ob eine Standardisierungsgemeinschaft das gesamte Design unterstützt, ist eine andere Frage. Revision 03 von RDAP Extension for Structured Reliability Assessment Metadata trennt beides durch eine neue Publikationsordnung.

Der Vorschlag übermittelt Bewertungen von Registraren und Domainnamen in RDAP-Antworten. Die Fassung vom 13. September ändert nach eigener Aussage weder Datenmodell noch Erweiterungskennung, JSON-Mitgliedsnamen oder Übertragungsformat. Abschnitt 13 ändert die Spezifikation, auf die sich die beantragte Registrierung von reliabilityAssessment stützen soll.

Revision 02 wollte einen RFC abwarten. Nun erklären die Autoren, es habe eine stabile Referenz gefehlt, nicht eine ausnahmslose RFC-Voraussetzung. Sie haben bcsec-RDAP-RA Version 1 unabhängig veröffentlicht und führen diesen Text als Grundlage an. Die Stabilitätsanforderung wird nicht aufgehoben; laut Vorschlag ist die fehlende Referenz jetzt vorhanden.

Eine abgeschlossene Registrierung folgt daraus nicht. Der für diesen Bericht gesicherte Stand des IANA-Verzeichnisses RDAP Extensions enthält die Kennung nicht. Der Datatracker führt weiterhin aktive individuelle Arbeit mit Status I-D Exists. Auch der Eingang eines formellen Antrags lässt sich aus seiner Beschreibung in einer Spezifikation nicht ableiten.

Ohne RFC heißt nicht ohne fachliche Prüfung

Das geltende Verfahren lautet Specification Required. RFC 8126 verlangt die Prüfung und Zustimmung eines benannten Experten sowie eine dauerhafte, öffentlich abrufbare Spezifikation, die unabhängige interoperable Implementierungen ermöglicht. Ein RFC ist ein idealer Publikationsweg; außerhalb dieses Weges veröffentlichte Dokumente sind ausdrücklich zulässig.

RFC 7480 begründet das RDAP-Verzeichnis und die Registrierungsvorlage. Der parallele Arbeitsgruppenentwurf RDAP Extensions schlägt konkretere Leitlinien für unveränderliche Referenzen und Reviews vor. Er bleibt ein Entwurf und darf nicht als bereits abschließende Ersatzregel behandelt werden.

Die Expertenprüfung ist also mehr als eine bloße Namensreservierung. Umgekehrt erzeugt die Erfüllung von Registrierungskriterien keinen IETF-Konsens. Die unabhängige Spezifikation lässt REGEXT ausdrücklich frei, das Vorhaben nicht zu übernehmen. Bertoldi Cybersecurity veröffentlicht sie allein und würdigt dabei das gemeinsame technische Design mit Simon Pietro Romano über den individuellen Entwurf.

Ein fester Text braucht einen eigenen Korrekturpfad

Die unabhängige Spezifikation verspricht, ihre kanonischen Bytes nicht zu ändern, auch nicht für redaktionelle Korrekturen. Fehler sollen in einem separaten, nicht normativen Errata-Dokument stehen. Eine interoperabilitätsrelevante Korrektur verlangt eine neue Spezifikation unter einer anderen URL; die alte bleibt erhalten. Ein Spiegel wird benannt, bei Abweichungen soll die kanonische URL maßgeblich sein.

Das sind Wartungszusagen des Herausgebers, keine von diesem Bericht bewiesene künftige Unveränderlichkeit. Ein erfolgreicher Abruf belegt nur die gegenwärtige Verfügbarkeit. Die Regelung unterscheidet dennoch klar zwischen dem Erkennen eines Fehlers und dem stillen Umschreiben der Regeln, denen bestehende Implementierungen folgen.

Anhang C erklärt das Datenmodell für identisch und nennt zugleich Unterschiede der Dokumente. Verweise auf unfertige Arbeiten werden informativ oder die nötigen Interoperabilitätsregeln werden erneut formuliert. Review-Einladungen und offene Fragen entfallen oder ändern ihre Form. Der feste Text beantragt keine eigenständige Registrierung in RDAP JSON Values; der individuelle Entwurf verfolgt diesen Teil separat. Technische Übereinstimmung bedeutet daher nicht Austauschbarkeit in jedem Verfahren.

Sollte ein RFC erscheinen, will der Registrant eine Aktualisierung der Referenz beantragen. Weder Veröffentlichung noch Aktualisierung sind bislang belegt. Eine solche Änderung würde bestehende Systeme auch nicht automatisch migrieren. Das gemeinsame Format transportiert Bewertungen, bestimmt aber keine Berechnungsmethode, Schwellenwerte oder Durchsetzungsmaßnahmen.

Quellen