Zusammenfassung

  • Bei der IETF 126 beschloss PROCON, einen Charter-Satz zur zutreffenden Dokumentation geltender Politik vorzuschlagen. Zum Rechercheabschluss zeigte Datatracker weiterhin nur die 2025 genehmigte Charter; der neue Satz war noch keine operative Ermächtigung.
  • Die geltende Charter erlaubt bereits begrenzte nichtredaktionelle Änderungen an Meilensteinen und der Annahme von Internet-Drafts. Daneben darf ein BCP Delegation und vorübergehende Nachfolge des IETF-Vorsitzes regeln. Weitere Gegenstände erfordern eine neue Charter.
  • 2418bis entfernt die 51-/99-Prozent-Beispiele, ordnet Hilfsrollen ein, erfasst mehrere öffentliche Foren und macht Annahme rückgängig. 2026bis zeigt zusätzlich Grenzfälle bei nichtöffentlichen Berufungsdiskussionen, Beispielen und Statusbegriffen.
  • Beobachtete Praxis ist nicht allein deshalb schon Norm. Umgekehrt ist neuer Text nicht automatisch kompetenzwidrig, weil die Charter materielle Änderungen in benannten Bereichen ausdrücklich zulässt.
  • Ein schlankes öffentliches Änderungsregister sollte jeden folgenreichen Diff mit Ausgangstext, Praxisnachweis, Klassifikation, Chartergrundlage, Einwänden, WG-Beschluss sowie späterem IETF- und IESG-Status verbinden.
  • Das Register schafft weder Vetorecht noch neue Freigabe. Es trennt zudem die Veröffentlichung eines BCP von seiner späteren Übernahme in Werkzeugen und täglicher Gruppenarbeit.

Der Satz über die Gegenwart ist selbst noch Zukunftsmusik

PROCON bearbeitet ein echtes Lesbarkeitsproblem. RFC 2026 und RFC 2418 sind weiterhin Grundlagen des IETF-Verfahrens. Spätere RFCs, Errata und Werkzeuge haben die anwendbaren Regeln jedoch über viele Fundstellen verteilt.

Die genehmigte PROCON-Charter verlangt, aktualisierende RFCs und verifizierte oder für spätere Aktualisierung vorgesehene Errata zusammenzuführen. Sie erlaubt zugleich nichtredaktionelle Änderungen zu WG-Meilensteinen und Entwurfsannahme. Ein eigener BCP zu Delegation und zeitweiliger Nachfolge des IETF Chair gehört ebenfalls zum Auftrag. Zusätzliche Aufgaben verlangen Rechartering.

Schon das geltende Mandat kennt damit mehrere Arten legitimer Bewegung. Konsolidierung sammelt bestehende Autorität. Eine Mechanikkorrektur überträgt eine unveränderte Pflicht auf aktuelle Infrastruktur. Praxiskodifizierung macht aus beobachtetem Verhalten eine normative Aussage. Bewusste Revision nutzt eine ausdrücklich erteilte Kompetenz. Dass ein Satz in RFC 2418 nicht stand, beantwortet keine dieser Fragen.

Die Chair-Folien von IETF 126 benannten die Spannung offen. Das Vorhaben sei als genaue und klare Dokumentation des laufenden Prozesses verstanden worden; Erweiterungen und Politikänderungen sollten warten. Eine strikte Charterlesart könne aber redaktionelle Reparaturen und Anpassung an veränderte Betriebswirklichkeit ausschließen. Zunächst stand deshalb ein längerer Zusatz mit RFCs, IESG-Erklärungen und Werkzeugänderungen im Raum.

Das Sitzungsprotokoll hält die kürzere Einigung fest: Die Ergebnisdokumente sollen geltende Politik korrekt wiedergeben. Das Protokoll bezeichnet sich als KI-entworfen und anschließend von Chairs und Teilnehmenden geprüft und aktualisiert. Es dokumentiert Entscheidungen, ist aber kein Wortprotokoll.

Am 2. September 2026 war öffentlich weiterhin charter-ietf-procon-01 vom 9. Juli 2025 genehmigt. Der neue Satz ist also Text, dessen Vorschlag an die IESG die WG beschlossen hat. Er ist noch keine Nachfolgecharter und kann ältere Änderungen nicht rückwirkend legitimieren.

Was mit 51 und 99 Prozent verschwindet

draft-ietf-procon-2418bis-04 streicht den Absatz aus RFC 2418, wonach 51 Prozent Unterstützung nicht zwingend Rough Consensus bedeuten und selbst bei 99 Prozent ein wesentlicher Einwand bestehen kann. Die 2418bis-Präsentation nennt diese Zahlen verwirrende Faustregeln. Die Sitzung beließ es bei der Streichung und übernahm einen vorgeschlagenen Verweis auf RFC 7282 nicht.

Das lässt sich als Schutz des nichtnumerischen Konsensbegriffs erklären: Einprägsame Prozente können wie Abstimmungsschwellen wirken. Doch die Begründung muss mit der Änderung erhalten bleiben. Ausgangsabsatz, behauptetes Problem, fortgeltendes Prinzip und Gruppenbeschluss bilden zusammen erst die nachvollziehbare Korrektur.

Unterstützungsrollen folgen einem anderen Muster. Revision 04 erlaubt Chairs und Area Directors, Teilnehmende in Hilfsfunktionen einzusetzen oder abzuberufen. Diese Rollen verändern weder die Konsensentscheidung noch mindern sie die Verantwortung von Chairs und Area Directors. Das Treffen verlangte eine Überarbeitung des Textes bei Erhalt dieser Verantwortungsgrenze.

Eine öffentliche WG-Nachricht berichtet aus persönlicher Erfahrung, viele Gruppen ernannten keinen Document Editor förmlich, und fragt nach einer entsprechenden Darstellung. Das ist eine zurechenbare Praxisbehauptung, keine Vollerhebung und kein bereits ergangener Normbeschluss. Erst die WG entscheidet, ob und in welcher Form Beobachtung zur Regel wird.

Öffentliche Foren nach der Mailingliste

RFC 2418 dachte öffentliche Arbeit vor allem über E-Mail-Listen. Revision 04 nennt E-Mail, Chatgruppen und andere kollaborative Werkzeuge und verlangt, Ergebnisse dortiger Gespräche zusammenzufassen und gut zu dokumentieren.

Bleiben Öffentlichkeit und Nachweis unverändert, handelt es sich plausibel um eine Korrektur veralteter Mechanik. Doch die Formulierung wirft neue Kompetenzfragen auf: Welche Chats zählen, welche Moderation greift, wann wird ein flüchtiges Gespräch Teil der Konsensakte? Das Register muss nicht vorentscheiden; es muss zeigen, ob Kontinuität oder Reichweitenerweiterung behauptet wird.

Bei der Entwurfsannahme ist die Ermächtigung klarer. 2418bis erklärt, dass Annahme einen Text zur Arbeitsgrundlage macht, keinen Inhaltskonsens feststellt und rückgängig gemacht werden kann. Weil die geltende Charter gerade hier nichtredaktionelle Änderungen erlaubt, darf dieses Modell als bewusste, autorisierte Revision bezeichnet werden. Neuheit allein macht es nicht illegitim.

Ein zurückgezogener Satz und ein fortbestehendes Grenzproblem

Die 2026bis-Folien unterscheiden redaktionell genannte Änderungen, vertagte Fragen und Arbeit vor einem weiteren Working Group Last Call. Bei IETF 126 wurde beschlossen, Revision-09-Text zu nichtöffentlichen Berufungsdiskussionen zurückzunehmen und Unicode als Beispiel für einen externen Standard durch IEEE 802 Ethernet zu ersetzen.

Die öffentliche Scope-Debatte bewahrt zwei zugerechnete Positionen: neue Diskretion als charterwidrige Politikänderung einerseits, Klarstellung aus RFC 2026 und Praxis andererseits. Sie beweist den Streit, nicht ein institutionelles Urteil. Der Rückzug entscheidet die nächste Fassung, nicht die allgemeine Klassifikationsfrage.

Auch der Austausch von „expired“ durch „inactive“ blieb offen. In der öffentlichen Diskussion heißt es, der neue Begriff passe womöglich besser zu Datatracker, sei aber nicht eindeutig redaktionell. Ein aktualisiertes UI-Etikett wäre Mechanikkorrektur; ein anderer verfahrensrechtlicher Status wäre Politik. Diff-Länge und Tragweite sind unabhängig.

Zwölf Felder genügen

Das Register ist ein Index, kein Parallelverfahren. Für Änderungen an Rollen, Verantwortung, Konsens, öffentlicher Akte, Annahme oder Berufung enthält es:

  1. unveränderliche Revision und genaue Stelle;
  2. zugrunde liegenden RFC, Erratum oder IESG-Text;
  3. öffentliche Evidenz für Praxis oder Werkzeugzustand;
  4. Konsolidierung, Mechanikkorrektur, Praxiskodifizierung und/oder bewusste Revision;
  5. Charterklausel, Recharter-Vorschlag oder Begründung fehlenden Zusatzbedarfs;
  6. editorische Begründung;
  7. wesentliche, zugerechnete Einwände;
  8. WG-Entscheid und Datum;
  9. Änderungen aus dem Working Group Last Call;
  10. IETF-Last-Call- und IESG-Entscheid;
  11. veröffentlichten Endtext;
  12. betriebliche und werkzeugseitige Übernahme.

Mehrfachklassifikation ist erlaubt. Die Forenänderung kann technische Korrektur und Kodifizierung zugleich sein. Verboten ist nur die unbegründete Leerstelle. Praxis braucht Nachweis, Korrektur die erhaltene Pflicht, Revision ihren Kompetenzweg.

Einwände werden dadurch nicht zu Vetos. Eine E-Mail bleibt die Aussage ihrer Urheberin oder ihres Urhebers. Der Gruppenentscheid steht getrennt. Fällt der Diff weg, vermerkt das Register seinen Abschluss.

Heng Lus Note 64 bietet eine Entwurfsperspektive: stabiles Minimum, spätere Entscheidung beim zuständigen Akteur und gesonderte operative Übernahme. Sie ist keine Tatsachenquelle zu PROCON und ersetzt kein IETF-Verfahren. Hier hilft sie nur, Ausgangsbasis, spätere Wahl und Adoption nicht zu einem Ereignis zu verschmelzen.

Review entscheidet, aber archiviert nicht automatisch den Grund

Die IETF besitzt bereits gewichtige Kontrollen: WG-Konsens, Working Group Last Call, IETF Last Call, Area-Director-Prüfung und IESG. Der Area Director hielt 2026bis unter der vorgeschlagenen Aktualisierung für im Scope, wies aber darauf hin, die 2418bis-Diffs noch nicht tief geprüft zu haben.

Das PROCON-Dokumentenverzeichnis führte 2026bis-11 im Working Group Last Call und 2418bis-04 als WG-Dokument. Nichts davon ist IESG-Genehmigung oder BCP-Veröffentlichung. Spätere Prüfung kann Text und Begründung ändern.

Mehrere Freigaben ordnen jedoch nicht automatisch, warum ein Diff Konsolidierung, Korrektur, Kodifizierung oder Revision war. Grund, Gegenargument, Beschluss und Endfassung können in vier Archiven liegen. Der spätere Leser sieht den Erfolg, aber nicht zuverlässig dessen Autoritätsgeschichte.

Das Register konkurriert mit keiner Instanz. Ändert ein späterer Review die Klassifikation, wird das sichtbar. Wird der Text entfernt, ist der Vorgang beendet. Bricht ein Praxisnachweis weg, kann die WG einen anderen Grund wählen oder die Formulierung fallen lassen. Entscheidungsspielraum bleibt erhalten; Erinnerung kommt hinzu.

Quellen

  1. Genehmigte PROCON-Charter
  2. PROCON-Dokumentenverzeichnis
  3. PROCON-Protokoll von IETF 126
  4. PROCON-Chair-Folien
  5. 2026bis-Update
  6. 2418bis-Präsentation
  7. Heng Lu Note 64
  8. Öffentliche Scope-Diskussion
  9. Öffentliche Diskussion zur Document-Editor-Praxis
  10. Öffentliche Diskussion zu inactive und expired
  11. draft-ietf-procon-2026bis-11
  12. draft-ietf-procon-2418bis-04
  13. RFC 2026
  14. RFC 2418