Zusammenfassung

  • Der Designated Expert aus RFC 5226 beantwortet eine enge Zuteilungsfrage. Er besitzt den Namensraum nicht, IANA schreibt die Richtlinie nicht, und Teilnahme an einer Mailingliste erzeugt kein Mandat.
  • Der heutige Nachfolger RFC 8126 macht den Kontrollrahmen deutlicher: erforderliche Angaben, Kriterien, Ablehnungsgründe, Rückzug bei Konflikten, Ersatz, Änderungskontrolle, geprüfte Version und regulärer Beschwerdeweg.
  • Ein Registereintrag belegt nur, dass ein bestimmter Antrag zu einem bestimmten Zeitpunkt ein bestimmtes Verfahren bestand. Er zertifiziert weder Sicherheit noch Implementierung, Einsatz oder Betriebserfolg.

Die Ernennung beantwortete nur die halbe Frage

Man nehme einen konstruierten Fall. Eine Spezifikation eröffnet ein Register und nennt lediglich „Expert Review“. Der IESG beruft eine erfahrene Ingenieurin. Beim ersten Antrag verlangt sie ein Bedrohungsmodell, zwei unabhängige Implementierungen und eine Prognose zum Verbrauch des knappen Bereichs. Das sind vernünftige Fragen. Im gründenden Dokument stehen sie jedoch nicht, und der nächste Antragsteller erhält später andere Anforderungen.

Das Problem setzt keinen schlechten Willen voraus. Die Institution hat entschieden, wer prüft, aber nicht, woran geprüft wird. Der Sitz ist besetzt; Beweislast und Ablehnungsgrenze bleiben rückwirkend veränderbar.

RFC 5226 erschien im Mai 2008 als BCP 26. Seine entscheidende Trennung lautet: IANA erfindet keine Zuteilungsrichtlinie, sondern führt von anderen definierte und in RFCs veröffentlichte Regeln aus. Die Textfassung zeigt diese Delegationskette. Datatracker, Statusseite, Dokumentgeschichte und Errata sichern zugleich den zeitlichen Befund: RFC 5226 ist historisch und wurde 2017 von RFC 8126 abgelöst.

Die Prüfungsfrage lautet deshalb nicht, ob der Experte persönlich vertrauenswürdig ist. Sie lautet, ob Dritte feststellen können, welche Nachweise er verlangen durfte, welche Mängel eine Ablehnung trugen, welche Fassung vorlag, wie Konflikte behandelt wurden und wo eine Anfechtung möglich war.

Vier Rollen hinter einer Registerzeile

Das definierende RFC bestimmt Namensraum, Antragsfelder, Verfahren, Eintragsformat und anfängliche Reservierungen. IANA nimmt Anträge entgegen und protokolliert Ergebnisse. Für Register des IETF-Streams ernennt und ersetzt der IESG Experten. Der Experte koordiniert die Prüfung und empfiehlt die Entscheidung über die konkrete Zuteilung. Das reguläre Verfahren stellt Aufsicht und Beschwerde bereit.

Die IANA-Hinweise für Autoren verlangen das genaue Register, die maßgebliche Referenz und alle Pflichtfelder. Die Seite für Protokollregistrierungen verweist Antragsteller auf das jeweilige Verfahren. Die Datatracker-Hilfe zum Status IANA review zeigt einen operativen Verarbeitungsschritt. Diese Schnittstellen sind wichtig, aber kein stiller Ersatz für die veröffentlichte Richtlinie.

Wer die Rollen verschmilzt, macht das Formular zum Gesetzgeber, persönliche Präferenz zum Kriterium und offene Teilnahme zur Autorisierung. Eine belastbare Prüfung trennt daher Richtlinienautor, Vorgangsverwaltung und technische Empfehlung.

Eine Arbeitsgruppe ist kein Bereitschaftsdienst

Mailinglisten können viel Wissen sammeln, müssen aber nicht mit einer eindeutigen Antwort enden. IANA kann nicht jede Diskussion überwachen und soll nicht entscheiden, wann daraus Konsens wurde. Arbeitsgruppen enden; Register bleiben.

RFC 2418 beschreibt den Lebenszyklus der Arbeitsgruppe. RFC 7282 versteht rough consensus als Bearbeitung technischer Einwände, nicht als Auszählung. RFC 3935 stellt nützliche technische Arbeit für den Betrieb des Internets in den Mittelpunkt der IETF-Mission. Nichts davon macht eine geschlossene Gruppe oder eine laute Mehrheit zur Dauerkammer.

Der benannte Experte schafft einen Abschluss: Er erhält einen erkennbaren Antrag, konsultiert bei Bedarf Fachleute oder die passende Gemeinschaft und gibt IANA eine klare Empfehlung. Er kann Kurator einer breiteren Prüfung sein, ohne allwissender Einzelrichter zu werden.

Das Mandat bleibt eng. Es betrifft die Zuteilung nach der Registerregel, nicht die Zertifizierung eines Produkts, die Genehmigung eines Einsatzes oder Eigentum am Namensraum.

Das Etikett enthält noch keine Entscheidungsregel

„Ein Experte prüft“ sagt weder, welche Belege nötig sind, noch, was zur Ablehnung reicht.

RFC 5226 verlangt, dass Experten ihre Entscheidungen gegenüber der IETF-Gemeinschaft vertreten können. Das Verfahren soll weder geheim sein noch unbefragte Macht verleihen. Idealerweise stehen konkrete Kriterien beim Protokoll. Fehlen sie, gilt eine wichtige Vermutung: Der Codepunkt soll vergeben werden, sofern kein zwingender Ablehnungsgrund besteht.

Der geltende Nachfolger RFC 8126 formuliert dies schärfer. Seine Textfassung fordert Angaben darüber, was Antragsteller liefern, was Experten bewerten und warum ein Antrag abgelehnt werden darf. Datatracker-Fassung, Status, Historie und Errata belegen seinen aktuellen Dokumentstand.

Zulässige Gründe sind begrenzt: Knappheit, eine für Interoperabilitätsbewertung zu unklare Dokumentation, schwerer Widerspruch zur Architektur oder zum Sicherheitsmodell des Basisprotokolls, Schaden an eingesetzten Systemen oder eine interoperabilitätsschädliche Kollision mit aktiver IETF-Arbeit. Geschmack gehört nicht dazu.

Vage Regeln ermächtigen nicht zu besonderer Strenge. Sie schwächen die Grundlage restriktiver Entscheidungen. Braucht ein Register zwei Implementierungen, eine öffentliche Sicherheitsanalyse oder Nutzungsnachweise, muss dies vor dem ersten Antrag geschrieben stehen.

Zustimmung braucht eine Versionsnummer

Für eine Warteschlange genügt Ja oder Nein. Für institutionelles Gedächtnis braucht es Antragsversion, eingereichte Belege, Kriterienversion, Konsultationen, offengelegte Konflikte und Begründung.

Die Freigabe von Version N gilt nicht automatisch für N+1, wenn sich Verhalten, Semantik oder Sicherheit wesentlich ändern. RFC 8126 weist darauf hin, dass Expert Review zu einem Zeitpunkt gegen ein bestimmtes Dokument erfolgt und substantielle Änderungen eine erneute Prüfung verlangen können. Die Logik ist aus Code Reviews vertraut: Ein genehmigter Commit autorisiert nicht seinen ungeprüften Nachfolger.

Gründe schützen auch den Experten. Ohne sie erscheint Annahme als Begünstigung und Ablehnung als Blockade. Mit ihnen lässt sich prüfen, ob Knappheit, unklare Dokumentation, Interoperabilitätsschaden, ein Sicherheitskonflikt oder bloße Vorliebe ausschlaggebend war.

Ein nützlicher Prüfbeleg verbindet fünf Teile: Antragsversion, Belege, Kriterienversion, begründete Empfehlung samt Konfliktstatus und Registeraktion mit späterem Änderungsverlauf. Das ist ein Analysemodell von Daniel Kade/BTW, kein in den RFCs vorgeschriebenes Schema. Es hält die Delegation nach Personalwechseln lesbar.

Befangenheit ist ein vorhersehbarer Betriebszustand

In kleinen Fachgebieten kann die bestgeeignete Person zugleich Autorin des Antrags, Vertreterin eines Konkurrenzentwurfs oder Beraterin eines Betroffenen sein. Schweigen beseitigt den Konflikt nicht; es macht ihn nur unsichtbar.

RFC 8126 fordert den Rückzug eines befangenen Experten. Sind alle betroffen, soll ein vorübergehender Experte angefordert werden; der zuständige Area Director kann ihn einsetzen oder die Prüfung übernehmen. Nicht verfügbare Experten können ersetzt, vom IESG berufene auch vom IESG abberufen werden.

Mehrere Experten ersetzen keine Entscheidungsregel. Bei Uneinigkeit müssen sie IANA eine gemeinsame klare Empfehlung liefern. Der Registerbetreiber soll den technischen Streit nicht schlichten. Eine Blockade fällt an die ernennende Instanz zurück.

Der Beschwerdeweg schließt den Kreis. RFC 2026 führt zunächst zum IESG und nötigenfalls zum IAB. Eine Beschwerde beleidigt keine Expertise. Sie zeigt, dass die Empfehlung Teil einer größeren Delegation bleibt.

Nach der Zuteilung beginnt die Änderungskontrolle

Ein Registereintrag überlebt seinen ursprünglichen Antrag. Referenzen werden korrigiert, Kontakte ändern sich, Einträge werden deprecated oder obsolete. RFC 8126 empfiehlt deshalb bei First Come First Served, Expert Review und Specification Required ein Feld für den Change Controller.

Wer zunächst einen Wert erhielt, darf ihn nicht automatisch Jahre später inkompatibel umdeuten. Auch der erste Prüfer wird nicht Eigentümer jeder künftigen Änderung. Änderungsbefugnis muss sichtbar sein, und die Historie sollte selbst bei obsoleten Einträgen erhalten bleiben. Annotation bewahrt Koordinationswissen; Löschen täuscht Nichtbenutzung vor.

RFC 7120 ermöglicht frühe, vorläufige Zuteilungen für laufende Arbeiten. Implementierung wird möglich, ohne einen abgeschlossenen Standardisierungsweg vorzutäuschen. Vorläufig, dauerhaft, deprecated und obsolete sind Governance-Zustände, keine Schmuckwörter.

Ähnliche Richtliniennamen liefern verschiedene Nachweise

RFC 5226 übernahm und änderte die Begriffe aus RFC 2434. Sie bilden keine einfache Qualitätsleiter.

First Come First Served enthält keine substanzielle Technikprüfung über Form und Nichtduplizierung hinaus. Expert Review fügt einen Prüfer unter veröffentlichten Kriterien hinzu. Specification Required verlangt zusätzlich eine stabile, dauerhaft öffentliche und für unabhängige interoperable Implementierung ausreichende Spezifikation. RFC Required verlangt ein RFC, kann aber ohne Einschränkung unterschiedliche Streams und Status zulassen. IETF Review verlangt ein RFC des IETF-Streams auf dem IESG-Weg.

Eine Expert-Review-Zuteilung ist kein Produkt- oder Sicherheitszertifikat. RFC Required heißt nicht zwingend IETF Standard. IETF Review beweist weder zwei Implementierungen noch produktiven Betrieb. Jede Richtlinie belegt nur ihren eigenen Prozess.

Lu Hengs Analysen erklären, warum diese Bescheidenheit strukturell ist. The Multi-Stakeholder Mirage trennt Teilnahme von Mandat. Minimum Initial Specification begrenzt die gemeinsame Schicht und belässt spätere Entscheidungen bei lokalem Wissen. When the Bookkeeper Auditions for Olympus warnt davor, den Buchführer zur höheren Gewalt zu erheben. Running-Code Primacy trennt Spezifikation und Registersymbol von Implementierung und beobachtetem Einsatz.

Der Experte ist dort am stärksten, wo die Grenze sichtbar bleibt: Er verhindert Kollisionen und schädliche Erweiterungen, ohne die nachgelagerte Welt zu regieren.

Quellen

  1. RFC 5226
  2. RFC 5226 als Text
  3. RFC 5226 im Datatracker
  4. Status von RFC 5226
  5. Geschichte von RFC 5226
  6. Errata zu RFC 5226
  7. RFC 8126
  8. RFC 8126 als Text
  9. RFC 8126 im Datatracker
  10. Status von RFC 8126
  11. Geschichte von RFC 8126
  12. Errata zu RFC 8126
  13. IANA-Hinweise für Autoren
  14. IANA-Protokollregistrierungen
  15. IANA-Review-Status im Datatracker
  16. RFC 7120
  17. RFC 2026
  18. RFC 2418
  19. RFC 2434
  20. RFC 3935
  21. RFC 7282
  22. Lu Heng — The Multi-Stakeholder Mirage
  23. Lu Heng — Minimum Initial Specification
  24. Lu Heng — When the Bookkeeper Auditions for Olympus
  25. Lu Heng — Running-Code Primacy