Zusammenfassung

  • Das Final Review eines RFC, früher AUTH48 genannt, beginnt nach der Publikationsgenehmigung eines Internet-Drafts durch einen Stream. Autoren prüfen Inhalt, Markup und Ausgabeformate, beantworten Fragen und erteilen die Endfreigabe; das ist eine echte Integritätskontrolle, aber keine erneute IETF-Abstimmung.
  • Nach der Übergabe an die Warteschlange kontrolliert das RFC Production Center die Produktionsfassung. Redaktionelle Korrekturen können innerhalb dieser Obhut erfolgen; Ergänzungen, Streichungen und technische oder sonst über das Redaktionelle hinausgehende Änderungen brauchen die Genehmigung des Ursprungsstreams.
  • Der kramdown-rfc- und GitHub-Pilot von 2025–2026 macht die Zuständigkeitsgrenze sichtbar. Am 27. August 2026 besaß RFC-to-be 10025 eine aktive Final-Review-Seite und ein öffentliches Repository, während die Informationsseite für RFC 10025 noch keinen veröffentlichten Eintrag lieferte.
  • Ein belastbarer Abschlussbeleg erhält die genehmigte Draft-Fassung, Streamentscheidung, RPC-Änderungsmenge, Klassifikation der Prüfpunkte, Autoren- und Streamfreigaben, Hashes der Endformate sowie Publikationsmeldung. Implementierung und Betrieb sind eine gesonderte Beweisebene.

Als ein Pull Request wie eine Neuabstimmung aussah

Das Bildschirmfoto zeigte tatsächlich einen Branch RPC-edits, offene Issues, eine Review-Anfrage und Namen ohne abschließende Bestätigung. Der Fehler entstand erst bei der Zusammenfassung. Aus „Publikationsfassung noch in Prüfung“ wurde „inhaltlich nicht genehmigt“, danach „Autoren legen ein Veto ein“ oder „der Konsens wird auf GitHub neu ausgehandelt“.

Final Review liegt zwischen zwei unterschiedlichen institutionellen Akten. Vorher genehmigt einer der RFC-Streams einen Internet-Draft zur Veröffentlichung. Nachher veröffentlicht das RPC bestimmte Dateien und kündigt den RFC an. Dazwischen prüfen Redaktion, Autoren und Streamkontakte, ob die Produktionsfassung den genehmigten Inhalt treu wiedergibt und als dauerhaftes Referenzobjekt taugt.

Diese Prüfung ist substanziell. Eine verlorene Algorithmuszeile, fehlerhaft dargestelltes ABNF, eine falsche IANA-Anweisung oder ein verschobenes normatives Wort kann nach Veröffentlichung lange wirken. Doch die Bedeutung eines Fehlers erweitert nicht automatisch die Zuständigkeit seines Finders. Das RPC bearbeitet und fragt; Autoren bestätigen die Integrität; der Stream entscheidet über inhaltliche Grenzüberschreitungen.

Darum ist die öffentliche Arbeitsfläche governance-relevant. Sie zeigt den genehmigten Ausgangspunkt, vorgeschlagene RPC-Änderungen, Fragen, Antworten und erforderliche Sonderfreigaben. Transparenz ist dann nützlich, wenn sie Rollen unterscheidbar hält, nicht wenn sie jeden sichtbaren Mitwirkenden zum Entscheider erklärt.

Die Genehmigung liegt vor der Warteschlange

Die aktuelle IETF-Anleitung zum RFC-Publikationsprozess setzt vor der redaktionellen Bearbeitung an. IETF, IAB, IRTF, Independent und Editorial Stream verfügen jeweils über einen eigenen Genehmigungsweg. Erst nachdem der zuständige Stream einen Internet-Draft zur Publikation freigegeben hat, erhält ihn das RFC Production Center.

Dieser vorherige Akt bestimmt Referenzinhalt und verantwortliche Autorität. Mit dem Eingang in die Queue übernimmt das RPC die Änderungskontrolle über die Produktionskopie. Autoren können die genehmigte Datei nicht still austauschen. Eine gewünschte Änderung läuft über das RPC und, sofern sie technisch oder sonst nicht bloß redaktionell ist, zurück zum zuständigen Stream.

RFC 9920, das aktuelle RFC-Editor-Modell, beschreibt die Arbeitsteilung. Die Genehmigungsorgane verantworten die Inhalte ihrer Streams. Die RFC-Editor-Funktion verantwortet Produktion und Verteilung. Das RPC redigiert, erhält Aufzeichnungen über Änderungen und Dialoge, erkennt mögliche technische Auswirkungen, verlangt Klärung, stellt Publikationsreife fest und veröffentlicht.

Das ist keine Rangordnung zwischen „Technik“ und „Redaktion“. Ein Stream schützt die Reihe nicht, indem er nur eine Idee genehmigt und fehlerhafte Ausgaben hinnimmt. Das RPC darf umgekehrt aus der Kontrolle über die Datei keine Kompetenz zur Protokollgestaltung ableiten. Und Autoren gewinnen am Schluss nicht das ausschließliche Eigentum an einem kollektiv genehmigten Text zurück.

Ein belastbares Register braucht daher von Beginn an die exakt genehmigte Quelle mit Revision und Hash sowie den genehmigenden Stream. Ohne diesen Fixpunkt schweben spätere Diffs ohne Maßstab.

Was Autoren wirklich freigeben

Die Autorenfreigabe ist keine Formalie. Autoren beantworten RPC-Fragen, prüfen Änderungen ihrer Mitautoren, lesen den vollständigen Text, kontrollieren Copyright und semantisches Markup und prüfen HTML-, PDF- und Textausgabe. Mehrere Schleifen können nötig sein.

Die Anleitung für den kramdown-rfc-Pilot trennt zwei Bestätigungen. Zunächst erklären Autoren den Markdown-Inhalt für stabil genug zur RFCXML-Konvertierung. Später genehmigen sie Inhalt und sämtliche Endformate. Eine korrekte Quelle kann schließlich immer noch falsch gerenderten Code, Grafiken, Referenzen oder Umbrüche erzeugen.

Autorenfreigabe ist deshalb eine Integritätserklärung: Die Endprodukte geben die Arbeit, für die der Name steht, korrekt wieder. Sie sagt nicht, dass der Wunsch eines einzelnen Autors nun den Beschluss der Arbeitsgruppe, der IESG oder eines anderen Streamorgans verdrängt.

Die Regel für unerreichbare Autoren belegt die beabsichtigte Grenze. Nach aktueller Anleitung kann eine Person in Acknowledgements oder Contributors verschoben werden; alternativ kann ein Streammanager an ihrer Stelle genehmigen. Anerkennung bleibt möglich, ohne einem nicht erreichbaren Postfach ein ewiges Veto einzuräumen.

Eine fehlende Rückmeldung darf dennoch nicht unsichtbar werden. Vielleicht erkennt nur diese Person eine feine Bedeutungsverschiebung. Der Vorgang sollte Kontaktversuche, gewählten Ersatzweg, Autorisierung und Begründung festhalten. Entscheidend ist, die offene Frage nach einer veröffentlichten Regel zu behandeln und nicht als undefinierte Macht zu deuten.

Die Grenze, die ein Merge nicht überschreiten kann

Am 1. September 2025 startete das RPC seinen kramdown-rfc-Pilot. Dokumente sollten in einem vielen Autoren vertrauten Format bearbeitet und Änderungen klarer auf ihren Inhalt begrenzt dargestellt werden. Zunächst waren mindestens fünf Anfragen pro Monat vorgesehen; Erfahrungen sollten die weitere Ausgestaltung bestimmen.

2026 verwendeten die öffentlichen Anleitungen bereits Final Review statt AUTH48. Der neue Name passt besser, weil 48 nie eine zugesicherte Frist bezeichnete. GitHub macht die Obhut greifbar: RPC-Bearbeitungen liegen auf einem eigenen Branch, Issues erhalten Fragen, Pull Requests zeigen Vorschläge und das Archiv konserviert den Dialog.

Das Repository für RFC-to-be 10025, die Überarbeitung der HTTP-Cookie-Spezifikation, liefert ein aktuelles Beispiel. Laut README ist das anfängliche Markdown eine Kopie des zur Veröffentlichung genehmigten Internet-Drafts. RPC-Änderungen werden getrennt geführt. Autoren genehmigen Inhalt und Formate; Area Directors genehmigen Änderungen jenseits des Redaktionellen. Chairs und Document Shepherd werden einbezogen, und bei Bedarf kann die Bearbeitung per E-Mail erfolgen.

Am 27. August 2026 waren die Final-Review-Statusseite und das Repository erreichbar, während die RFC-Informationsadresse für Nummer 10025 noch 404 meldete. Die Oberfläche zeigte fünfzehn Issues und einen Pull Request. Daraus folgen weder fünfzehn technische Mängel noch fünfzehn Einwände oder blockierende Entscheidungen. Die Zahlen belegen nur sichtbare Arbeitspunkte.

Dieser Zustand ist veränderlich. Ein Register muss Beobachtungszeit und maßgebliche URLs speichern. Im Final Review beschreibt den Moment. Als RFC 10025 veröffentlicht wird erst durch den endgültigen Datensatz und die Publikationsmeldung belegt.

RFC 9991 und das normierende Wort

Eine reale Grenzüberschreitung zeigt die Zuständigkeit besonders deutlich. Beim Final Review des späteren RFC 9991 schlugen die Autoren ein zusätzliches BCP-14-Schlüsselwort vor. Großgeschriebene Anforderungsbegriffe können die technische Bedeutung ändern; sie sind keine gewöhnliche Zeichensetzung.

Im öffentlichen Archiv bat das RPC den verantwortlichen Area Director um Prüfung und Genehmigung. Der AD dokumentierte seine Zustimmung. Später publizierte das RPC den RFC.

Die Verben sind der Beleg: Autoren schlugen vor. Das RPC erkannte eine zuständigkeitsrelevante Änderung und ersuchte um Prüfung. Der AD genehmigte. Das RPC veröffentlichte. Kein Merge ersetzte die Genehmigung; keine Genehmigung galt vorzeitig als Publikation.

Wer nur den Endtext speichert, verliert die Autorität hinter der späten Änderung. Wer nur die AD-Antwort speichert, kann nicht zeigen, welche Enddateien das genehmigte Wort enthielten. Wer nur die RFC-Nummer führt, verliert die gesamte Obhutskette. Die Eskalation belegt hier gerade, dass die Redaktion ihre Grenze erkannte.

Warum 48 nie eine Frist war

AUTH48 klang nach 48 Stunden. RFC 8963 untersuchte eine Stichprobe von 2018 produzierten RFCs und unterschied Bearbeitungszeit, AUTH48 sowie den Zeitraum von der letzten Einigung bis zur Publikation. AUTH48 dauerte in dieser Stichprobe im Durchschnitt länger als einen Monat und schwankte stark.

RFC 8700 überliefert den alten Scherz von 48 Tagen oder 48 Wochen. Wichtiger ist die institutionelle Lehre: Technische Änderungen in dieser Phase brauchen die Genehmigung des zuständigen Area Directors oder Streammanagers.

Aus historischen Dauern folgt kein heutiger Sollwert. Komplexität, Zeitzonen, Unerreichbarkeit, IANA-Aktionen, normative Referenzen, Stream Holds und Werkzeugprobleme haben verschiedene Ursachen. Zeit ist ein Signal, das eine Frage auslöst, nicht die Antwort auf die Schuldfrage.

Die Umbenennung entfernte eine falsche Uhr. Sie sollte nicht durch die ebenso falsche Metapher einer zweiten Wahl ersetzt werden. Es geht um kontrollierte Finalisierung.

Der Abschlussbeleg

Feld Zu erhaltender Nachweis Zweck
Genehmigte Quelle Draftname, Revision, Bytes und Hash Fixiert den vom Stream akzeptierten Inhalt
Streamentscheidung Stream, Organ, Datum und URL Benennt die Publikationsautorität
Queue-Übergabe Eingangszeit und Status Trennt Entscheidung von Produktionsobliegenheit
Änderungssatz Branch, Diff oder Hash Zeigt Bearbeitungen nach Genehmigung
Prüfpunkte Frage, Akteur, Antwort und Archivlink Ordnet Unsicherheit und Lösung zu
Änderungsklasse Redaktionell, Format, technisch oder darüber hinaus Bestimmt die erforderliche Genehmigung
Autorenfreigabe Identität, Umfang und Zeit Verbindet Personen mit Endartefakten
Streamfreigabe AD- oder Streammanager-Beleg Schützt die Inhaltszuständigkeit
Externe Holds IANA, Referenz, Stream oder Werkzeuge Zeigt den tatsächlichen Engpass
Endartefakte Hashes für HTML, PDF, TXT und XML Bindet Genehmigung an konkrete Ausgaben
Publikation Ankündigung, URL und Zeitpunkt Belegt den Übergang zum RFC
Übernahme Implementierung, Tests und Deployment Trennt Dokumentautorität von Betrieb

Der Beleg automatisiert keine redaktionelle Entscheidung. Er erhält den zuständigen Akteur. Dann lässt sich präzise sagen: Ein Autor muss noch die Ausgaben genehmigen; eine technische Ergänzung wartet auf den AD; eine IANA-Aktion fehlt; oder der Publikationsdatensatz existiert noch nicht. Solche Sätze helfen bei Einkauf und Implementierung mehr als „Veto“ oder „zweite Abstimmung“.

Quellen

Die Beobachtungen zu RFC-to-be 10025 sind auf den 27. August 2026 datiert. Issuezahlen werden nicht als Fehlerzahlen ausgelegt; Publikationstermin und Ergebnis werden nicht vorhergesagt.