Zusammenfassung

  • draft-ietf-procon-2026bis-11 wurde am 1. Juli 2026 veröffentlicht und befand sich am 27. August weiterhin im Working Group Last Call. Der Entwurf übernimmt das Varianzverfahren aus RFC 2026, ist aber noch kein verabschiedeter Ersatz für BCP 9.
  • Eine zuständige Arbeitsgruppe oder, falls es keine gibt, ein Ad-hoc-Ausschuss kann für eine bestimmte Spezifikation eine Ausnahme empfehlen, wenn ein Stillstand eingetreten ist oder das Verfahren keine Anleitung bietet. Die Empfehlung ist kein Beschluss.
  • Der IESG muss technische Güte, den normalen Weg, Alternativen, Kosten, Neben- und Präzedenzwirkungen sowie den engstmöglichen Umfang prüfen. Der Vorschlag wird ein eigenes Internet-Draft, erhält einen verlängerten Last Call von mindestens vier Wochen und wird nach Genehmigung als BCP veröffentlicht. Die Beschwerdemöglichkeit bleibt bestehen.
  • Festgelegte Fristen, Offenheit, Fairness, Konsens, Aktenführung und zentrale Verfahrensschritte dürfen nicht entfallen. Eine belastbare Varianz ist deshalb ein versionierter Ausnahmebeleg für genau einen Fall, keine dauerhafte Neufassung, kein selbstvollziehender Präzedenzfall und keine Vorgabe für den Betrieb.

Wo die Bindungswirkung endet

Eine Ausnahme beantwortet nicht die abstrakte Frage, ob eine Anforderung noch gilt. Sie beantwortet eine engere Frage: Darf diese identifizierte Spezifikation trotz dieser nicht erfüllten Anforderung in den Standards Track eintreten oder dort fortschreiten, nachdem die zuständigen Stellen diesen Antrag geprüft haben?

Wird die Antwort ohne die Frage gespeichert, entsteht eine falsche Allgemeinverbindlichkeit. Das Register zeigt nur noch „nicht erforderlich“. Ein späteres Dokument übernimmt den Wert, obwohl weder seine technische Lage noch seine Alternativen oder Nebenwirkungen untersucht wurden. Das förmliche BCP blieb unverändert; die operative Verwaltung hat es dennoch umgeschrieben.

Auch institutionelle Sprache kann die Grenze verschieben. Aus „für Spezifikation A genehmigt“ wird „bereits praktiziert“, daraus „IETF-Präzedenz“ und schließlich „zulässiges Verfahren“. Mit jeder Verkürzung verschwinden Bedingungen, während die behauptete Reichweite wächst.

Deshalb braucht ein verlässliches Register zwei getrennte Objekte. Die allgemeine Prozessregel besitzt Fassung, Geltung und Änderungsverfahren. Die Varianz besitzt Ziel, Fassung, betroffene Vorschrift, Empfehlung, Abwägung, öffentliche Prüfung, Auflagen, Entscheidung und Rechtsbehelf. Ein früherer Fall darf die spätere Analyse informieren. RFC 2026 verlangt sogar, Präzedenzwirkungen zu bedenken. Er erledigt die neue Prüfung aber nicht.

Diese Begrenzung ist kein Misstrauen gegenüber jeder Ermessensentscheidung. Ein Verfahren ohne Ausnahme kann an einem unvorhergesehenen Fall scheitern. Ein Verfahren, dessen Ausnahmen automatisch den Standard ändern, hat dagegen keine stabile Grundregel. Die fallbezogene Bindungswirkung hält beides zusammen: Beweglichkeit und Verantwortlichkeit.

Der aktuelle Status ist selbst Teil der Aussage

Der Datatracker-Eintrag führt draft-ietf-procon-2026bis-11 als aktives Internet-Draft der PROCON-Arbeitsgruppe. Sein Feld Intended RFC status zeigt None; der Kopf des Entwurfstextes nennt dagegen Best Current Practice als beabsichtigten Status. Diese beiden Angaben dürfen nicht zu einer bereits erteilten Statusentscheidung verschmolzen werden. Die Fassung -11 erschien am 1. Juli 2026 und läuft am 2. Januar 2027 aus, sofern sie nicht aktualisiert oder weitergeführt wird. Die Historie verzeichnet den Wechsel in den Working Group Last Call am 21. Mai, damals bei Fassung -08.

Am 27. August lautete der WG-Status weiterhin In WG Last Call; beim IESG stand I-D Exists, ohne Telechat-Termin. Das belegt einen ernsthaft geprüften Arbeitsgruppenentwurf. Es belegt weder IESG-Zustimmung noch RFC-Veröffentlichung noch ein wirksames Nachfolge-BCP.

Bei erfolgreichem Abschluss würde der Text mehrere Prozess-RFCs, darunter RFC 2026, zusammenführen und obsolet machen sowie RFC 7475 aktualisieren. Die PROCON-Charta begründet den Auftrag mit der zersplitterten Aktualisierungskette von RFC 2026 und RFC 2418 durch mehr als zwanzig RFCs. Die Gruppe soll diese Texte samt geprüften Errata in verständliche Nachfolger überführen. Nur zwei zusätzliche Bereiche nichtredaktioneller Änderungen sind benannt; weitere Themen erfordern eine neue Charta.

Abschnitt 11 der Fassung -11 erhält die Architektur der Varianz. Er schafft sie nicht erst 2026. Der veröffentlichte RFC 2026, Bestandteil von BCP 9, enthält sie seit 1996 in Abschnitt 9. Der neue Entwurf konsolidiert, aktualisiert Begriffe und nummeriert neu; seine Änderungshistorie bezeichnet die Varianz nicht als neues politisches Instrument.

Eine Governance-Datenbank muss daher drei Zustände nebeneinander führen. RFC 2026 ist die derzeit veröffentlichte Grundlage. 2026bis-11 ist der aktuelle Konsolidierungsvorschlag in der Arbeitsgruppenprüfung. Erst ein später tatsächlich veröffentlichter Nachfolge-RFC würde die wirksame Grundlage an einem zurechenbaren Ereignis ändern. Ein Entwurf kann die Richtung erklären, aber noch keine vollendete Regeländerung beweisen.

Empfehlung, Prüfung und Beschluss

Das Verfahren beginnt bei der für die Spezifikation verantwortlichen Arbeitsgruppe. Gibt es keine, kann ein Ad-hoc-Ausschuss empfehlen. Damit liegt die Darstellung des Problems bei einer Stelle, die den technischen und institutionellen Kontext kennt. Die gleiche Stelle kann sich die Ausnahme jedoch nicht abschließend selbst erteilen.

Der IESG muss entscheiden, ob der voraussichtliche Nutzen für die Internetgemeinschaft die Kosten der Nichteinhaltung überwiegt. Dabei prüft er die technische Güte der Spezifikation, ob sich die Ziele des normalen Standardsprozesses ohne Varianz erreichen lassen, welche Alternativen bestehen, welche Nebenwirkungen und Präzedenzfolgen drohen und wie eng sich die Ausnahme fassen lässt.

Technische Qualität allein genügt somit nicht. Auch ein guter Entwurf kann den normalen Weg nehmen. Zeitdruck allein genügt ebenfalls nicht, weil eine Verkürzung Prüfkosten auf andere Beteiligte verlagert. Die Unterstützung der Arbeitsgruppe beantwortet nicht automatisch Einwände außerhalb der Gruppe. Und ein ähnlicher AltfalI ersetzt keine Analyse der neuen Fassung und ihrer konkreten Vorschrift.

Der IESG kann die Varianz auf einzelne Bestimmungen begrenzen und zusätzliche Beschränkungen auferlegen. Der Erlass einer Anforderung setzt den übrigen Prozess nicht außer Kraft. Je weiter der Antrag kommt, desto genauer sollten Gegenstand, Grenze und Beendigungsbedingung werden.

Eine öffentliche Beweiskette statt einer Kurzformel

Der Vorschlag muss das wahrgenommene Problem, die genaue störende Bestimmung und die Erwägungen des IESG offenlegen. Er ist als Internet-Draft zu veröffentlichen und erhält dadurch eine öffentliche Identität und Versionsgeschichte.

Anschließend führt der IESG einen verlängerten Last Call von mindestens vier Wochen durch. Danach trifft er die endgültige Entscheidung und gibt sie gegenüber der IETF bekannt. Eine genehmigte Varianz wird zur Veröffentlichung als BCP weitergeleitet. Das Beschwerdeverfahren gilt weiterhin.

Jeder Schritt hat einen eigenen Beweiswert. Die WG-Empfehlung zeigt, wer die Prüfung beantragt. Das Internet-Draft fixiert den Gegenstand. Der Last Call belegt ein Mindestfenster öffentlicher Kontrolle, aber keine Zustimmung durch Schweigen. Die IESG-Mitteilung ordnet Entscheidung und Ergebnis zu. Die BCP-Veröffentlichung stabilisiert den genehmigten Fall. Eine Beschwerde erzeugt gegebenenfalls einen weiteren Vorgang mit eigenem Antrag, Prüfgegenstand und Ausgang.

RFC 7282 verdeutlicht, warum eine Stimmenzahl nicht ausreicht. Rough Consensus hängt vom Gehalt der Einwände und ihrem Umgang ab. Viele kurze Zustimmungen beantworten nicht automatisch einen tragenden strukturellen Einwand; ein Einwand ist umgekehrt kein automatisches Vetorecht. Im Register muss die sachliche Behandlung sichtbar bleiben.

Der Aufwand der Kette ist gewollt. Wäre die Ausnahme schneller und billiger als der Normalweg, würde sie zu einem zweiten Normalweg. Schriftliche Begründung, Veröffentlichung, Mindestdauer, Antwortpflicht und Beschwerde schaffen einen Anreiz, sie nur bei echtem Stillstand und mit kleinem Umfang einzusetzen.

Der nicht abdingbare Verfahrenskern

RFC 2026 untersagt, eine ausdrücklich festgelegte Frist durch Varianz zu verkürzen. Offenheit, Fairness und Konsens dürfen nicht erlassen werden. Dasselbe gilt für ordnungsgemäße Aufzeichnungen von Sitzungen und Mailinglisten-Diskussionen. Außerdem schützt der RFC bezeichnete Kernabschnitte zu BCP-Prüfung, Einleitung einer Maßnahme, IESG-Prüfung, Veröffentlichung, Konfliktlösung, Beschwerden und dem Varianzverfahren selbst. 2026bis-11 übernimmt diesen Boden mit neuer Nummerierung.

Könnte eine Ausnahme die Instrumente ihrer eigenen Kontrolle beseitigen, würde sie genau im Moment größter Abweichung die Beweise vernichten. Der Name des Verfahrens bliebe, doch eine kontrollierte Ermessensentscheidung wäre von einer intransparenten Machtausübung nicht mehr zu unterscheiden.

Auch der vierwöchige Last Call ist keine leere Wartefrist. Er verschafft Beteiligten außerhalb der Arbeitsgruppe eine Mindestchance, Bestimmung, Gründe, Alternativen und Folgewirkungen zu prüfen. Dürfte die behauptete Dringlichkeit gerade die Frist verkürzen, in der diese Behauptung überprüft wird, würde die Begründung zur Befugnis, ihrer Kontrolle zu entgehen.

Der feste Kern garantiert keine Einstimmigkeit und beseitigt das Ermessen des IESG nicht. Er garantiert die vorgelagerte Voraussetzung: Die Entscheidung bleibt sichtbar, zurechenbar, dokumentiert und anfechtbar.

Ein prüffähiger Ausnahmebeleg

Der Beleg beginnt mit eindeutiger Identität: Kennung und Version der Varianz; Name, Revision und Inhalts-Hash der Zielspezifikation; zuständige WG oder Ad-hoc-Ausschuss; Empfehlung und Datum; genaue BCP-Bestimmung; festgestellter Stillstand oder fehlende Anleitung; nicht erfüllte Anforderung und das Versagen des Normalwegs.

Der analytische Teil hält technische Güte, Nutzen-Kosten-Abwägung, verworfene Alternativen, Neben- und Präzedenzwirkungen, exakten Umfang und zusätzliche Auflagen fest. Der öffentliche Teil verknüpft Varianz-Draft und Hash, Beginn und Ende des Last Calls sowie wesentliche Einwände und deren Behandlung.

Der abschließende Teil nennt IESG-Entscheidung und Bekanntgabe, bei Genehmigung die BCP-Identität, den Stand von Beschwerden, die Einmaligkeitsgrenze und eine mögliche Endbedingung. Zwei Nichtaussagen gehören ausdrücklich dazu: Der Beleg entscheidet keinen späteren Fall und weist keine externe Implementierung oder Einführung nach.

Dass eine genehmigte Varianz als BCP erscheint, ändert daran nichts. Die Publikationsform macht den Beschluss öffentlich, stabil und zitierbar. Der sachliche Umfang bleibt auf die genannte Spezifikation begrenzt. Eine dauerhafte Änderung der wiederverwendbaren Regel verlangt das normale offene BCP-Verfahren.

Interne Verfahrenswirkung und externer Einsatz

Eine Varianz betrifft den Eintritt oder das Fortkommen einer Spezifikation im IETF-Standardsprozess. Sie entscheidet nicht über Beschaffung, Implementierung oder Betrieb bei Unternehmen, Netzbetreibern, Behörden oder Softwareprojekten.

RFC 9281 beschreibt die Rollen von Arbeitsgruppe, IESG und weiteren Beteiligten. Diese Zuordnung verleiht einem externen Akteur keine Befugnis, aus einer Ausnahme neue Dokumentzustände abzuleiten. RFC 3935 hält zugleich fest, dass ein IETF-Standard beschreibt, wie etwas bei behaupteter Konformität zu tun ist; die IETF erzwingt oder überwacht die Nutzung nicht allgemein.

Eine Einsatzentscheidung braucht daher einen eigenen Nachweis: verantwortliche Stelle, implementierte Fassung, Tests, Reichweite, Zeitpunkt, Rückfallbedingung und beobachteter Betrieb. Die Varianz kann Kontext liefern, aber diese Entscheidung nicht ersetzen. Wer sie als externes Mandat darstellt, erweitert eine interne Prozessbefugnis ohne Quelle.

Heng Lus Rahmen zu minimaler Ausgangsspezifikation, lokalisierter späterer Entscheidung und freiwilliger Übernahme bietet dafür eine passende Governance-Perspektive: Jede Entscheidung bleibt an den Zuständigkeitsbereich ihres Urhebers gebunden, spätere Übernahmen behalten eigene Verantwortliche und Belege. Er ersetzt nicht die IETF-Quellen, sondern schärft die Grenze.

Quellen