Zusammenfassung

  • RFC 9945 ist seit Februar 2026 als BCP 245 veröffentlicht und schafft einen IETF-weiten Rahmen für die Moderation öffentlicher Online-Foren. Die Änderungen werden nach dem eigenen Übergangssatz aber erst wirksam, wenn die IESG die Verfahren aus Abschnitt 4 genehmigt hat; bis dahin bleiben frühere Prozesse in Kraft.
  • „Obsoleted“-Metadaten, ein ernanntes Team, ein öffentliches SOP und eine tatsächlich ausgeführte Maßnahme belegen verschiedene Zustände. Ein knapper Aktivierungsbeleg sollte genehmigte Fassung, Entscheidungsakt, Wirksamkeitszeit, abgelöste Regeln, Geltungsbereich, Rollen und Übergang offener Fälle verbinden, ohne Beschwerden offenzulegen.

Der Rechtsstand liegt nicht im neuesten Link

Wer eine heutige Webseite öffnet, sieht den heutigen Inhalt. Für einen Vorgang von gestern reicht das nicht. Ein Administrator kann eine Nachricht nach einer bestimmten Regel zurückhalten. Wochen später kann das Verfahren präzisiert worden sein. Im Rechtsmittel darf die neue Fassung nicht unbemerkt an die Stelle der alten treten.

Gerade für dieses Problem verwendet RFC 9945 eine zweistufige Konstruktion. Das Dokument wurde als Best Current Practice veröffentlicht. Es hat den öffentlichen IETF-Prozess durchlaufen, repräsentiert den Konsens der Community und trägt die Nummer BCP 245. Es bezeichnet RFC 3683 und RFC 3934 als obsolet, ersetzt Teile von RFC 9245 und aktualisiert RFC 2418.

Dann setzt es eine weitere Bedingung. Die Änderungen treten in Kraft, sobald die IESG die in Abschnitt 4 beschriebenen Verfahren genehmigt. Das Moderationsteam entwickelt Verfahren und Kriterien unter Beteiligung der Community. Vor Wirksamkeit ist die IESG-Genehmigung nötig; der Text muss öffentlich sein, aber nicht in der RFC-Reihe erscheinen. Bis zur Etablierung bleiben die in Abschnitt 1 genannten früheren Prozesse in Kraft.

Das ist kein bedeutungsloses Zögern. Dauerhafte Grundsätze gehören in den BCP. Praktische Anweisungen sollen sich an neue Foren und Erfahrungen anpassen können. Die Architektur schafft Flexibilität. Zugleich verlegt sie den tatsächlichen Umschaltpunkt aus dem RFC in einen späteren Entscheidungsakt.

Bibliografische Ablösung und operative Ablösung

Auf der RFC-Editor-Seite von RFC 3934 steht, dass RFC 9945 ihn abgelöst hat. Als Wegweiser durch die Dokumentenreihe ist das richtig. Wer einen alten Text findet, soll den Nachfolger sehen.

Ein bibliografischer Pfeil enthält jedoch weder den Hash eines Verfahrens noch ein Genehmigungsprotokoll oder eine Uhrzeit. Er beantwortet: Welches Dokument ist im Korpus der Nachfolger? Er beantwortet nicht vollständig: Welche Handlungsanweisung galt in einem bestimmten Forum an einem bestimmten Tag?

Darum können die scheinbar widersprüchlichen Aussagen gleichzeitig zutreffen. RFC 3934 ist formal obsolet. Sein Prozess kann aufgrund der Übergangsregel des Nachfolgers vorübergehend weiter in Kraft sein. Wer nur die erste Aussage liest, beendet die alte Ordnung möglicherweise zu früh. Wer nur die zweite liest, erklärt den veröffentlichten BCP zu Unrecht für nicht existent.

Die richtige Darstellung braucht zwei Zustandsfelder und eine datierte Verbindung. Dokumentstatus und Durchführungsbefugnis werden nicht gegeneinander ausgespielt.

Die IESG musste die Übergangsregel anwenden

Am 30. Juni 2026 legte Andrew Lee einen Einspruch gegen eine Moderationsmaßnahme während des Last Call der TLS-Arbeitsgruppe ein. Unter anderem bestritt er die fortbestehende Autorität von RFC 3934, weil dessen RFC-Editor-Seite RFC 9945 als Nachfolger ausweist.

Die IESG wies den Einspruch am 9. Juli nach Prüfung zurück. Zur Verfahrensgrundlage erklärte sie ausdrücklich, RFC 3934 bleibe in Kraft. Abschnitt 4 von RFC 9945 erhalte die früheren Prozesse, solange die neuen Verfahren und Kriterien noch nicht etabliert seien. Außerdem hielt die IESG fest, dass BCP 9 selbst keine Moderationsbefugnis verleihe, die zusätzliche Referenz die konkrete Maßnahme aber nicht unwirksam mache.

Diese Recherche entscheidet den Fall nicht neu. Aus den öffentlichen Unterlagen folgt kein Nachweis von Zensur, Voreingenommenheit, Rechtswidrigkeit oder Fehlverhalten. Die IESG behandelte weitere Fragen zu technischen Positionen, Befangenheit und selektiver Anwendung. Die Ablehnung ist auch kein Freibrief für jede andere Moderationsentscheidung.

Der begrenzte Befund ist wichtiger als eine Parteinahme: Der Zeitpunkt der Aktivierung entschied mit darüber, welche Norm als Grundlage diente. Ein Metadatenfeld genügte nicht. Die IESG musste den Übergangssatz auf das datierte Ereignis anwenden.

Damit ist der Stand vom 9. Juli belegt. Über spätere Zeitpunkte sagt die Antwort nichts Sicheres. In den bis 11. September geprüften offiziellen Quellen ließ sich kein späterer IESG-Akt finden, der eine konkrete neue Verfahrensfassung genehmigt. Suchergebnislosigkeit beweist keine Nichtexistenz. Wenn die Genehmigung öffentlich sein muss, zeigt sie aber ein Auffindbarkeitsdefizit: Der autoritative Umschaltpunkt sollte ohne Archivrekonstruktion erreichbar sein.

Sechs Namen auf Datatracker, drei Namen im SOP

Datatracker führt ein aktives IETF Moderator Team mit sechs Mitgliedern. Die Beschreibung entspricht dem weiten Rahmen von RFC 9945: Verfahren für öffentliche IETF-Foren entwickeln, als Anlaufstelle dienen, Plenarforen und sonst unbetreute Räume administrieren, von der IESG ernannt werden und ihr verantwortlich sein.

Der öffentliche GitHub-Bestand ietf/Moderators zeigt im fixierten Commit b907805e15… eine andere, engere Oberfläche. Das README bezieht sich auf die allgemeine Diskussionsliste der IETF und RFC 9245. Das SOP nennt drei Mitglieder, verlangt für Maßnahmen mindestens zwei übereinstimmende Stimmen und beschreibt eine Eskalationsleiter mit den Stufen 0, 1 und 2. Eine Statistik zählt Maßnahmen nach diesen Stufen.

Die Abweichung beweist keine schlechte Verwaltung. Das Repository kann die bisherige Arbeit für die allgemeine Liste dokumentieren. Das neue Team kann seine Verfahren an anderer Stelle entwickeln. Eine gestufte Migration oder bloß veraltete Namenspflege ist möglich.

Gerade weil mehrere harmlose Erklärungen möglich sind, darf keine davon stillschweigend zur geltenden Regel erklärt werden. Die Datatracker-Seite beweist ein Team und seine öffentliche Rollenzuordnung. Der Commit beweist einen Textzustand. Die Statistik beweist eine Zählweise. Für den Aktivierungssatz fehlt die ausdrückliche Verbindung: IESG-Genehmigung dieser Fassung, für diesen Bereich, wirksam ab diesem Zeitpunkt.

Die Zuständigkeiten bleiben absichtlich verteilt

Administratoren tragen weiterhin die Erstverantwortung für ihre Foren. In einer Working Group sind die Chairs standardmäßig Administratoren. Sie dürfen delegieren, müssen Beschwerden aber annehmen, bestätigen und verfolgen. Nach Beratung mit dem Moderationsteam dürfen sie auch Maßnahmen von Moderatoren ändern oder aufheben.

Das Team entwickelt einheitliche Verfahren, unterstützt die Community und kann eingreifen, wenn Administratoren nicht rechtzeitig reagieren oder Störungen mehrere Foren erfassen. Grundsätzlich soll es die lokalen Verantwortlichen zuerst kontaktieren. Es verwaltet Plenarforen und öffentliche Räume ohne andere Administration.

Area Directors lösen frühe Konflikte. Die IESG genehmigt Verfahren, ernennt und entlässt Teammitglieder, beurteilt die Leistung und ist Teil der Rechtsmittelkette. Danach kann das IAB nach RFC 2026 angerufen werden. Das Ombudsteam behält seinen eigenen Anti-Harassment-Auftrag. Die IETF Administration LLC verfügt bei gravierendem Rechtsrisiko und entsprechender Beratung über einen gesonderten Notfallweg.

IRTF, IAB, RSWG, RSAB und Independent Submission Stream fallen ohne ausdrückliche Zustimmung nicht automatisch unter RFC 9945. Die saubere Trennung ist ein Schutz gegen unbemerkte Machtvergrößerung. Sie verlangt zugleich, dass jeder Prüfende Verfahrensfassung und Geltungsbereich kennt.

Auch das frühere System war kein Monolith

RFC 3934 betraf Maßnahmen von Chairs auf Mailinglisten ihrer Working Groups. RFC 3683 regelte einen von IESG und Community getragenen Entzug von Postingrechten. RFC 9245 beschrieb die allgemeine IETF-Diskussionsliste und ihre Moderatoren. RFC 2418 ordnete Chair-Verantwortung ein. RFC 2026 stellte weitere Rechtsmittel bereit.

RFC 9945 reagiert auf reale Lücken: unterschiedliche Kriterien, langsame Instrumente, forumübergreifende Muster und neue Arbeitsorte von Chat bis GitHub-Issue. Ein gemeinsames Team und gemeinsame Leitplanken können diese Brüche überwinden.

Die Übergangsregel macht alte Befugnisse nicht grenzenlos. Accountentzug, Ausschluss von Präsenz-, Hybrid- oder virtuellen Treffen, Löschung von Inhalten sowie private oder nicht zur IETF gehörende Kommunikation liegen außerhalb gewöhnlicher Moderationsmaßnahmen. Eine Listenregel wird nicht zur universalen Organisationsgewalt, nur weil sie vorübergehend fortgilt.

Zeit spielt auch innerhalb einzelner Fälle eine Rolle. Eine unbefristete Sperre, die vor dem neuen Prozess verhängt wurde, wird nach dem Verfahren der ursprünglichen Entscheidung neu betrachtet. RFC 9945 selbst schützt damit historische Verfahrensidentität vor rückwirkender Glättung.

Ein Aktivierungsbeleg braucht keine Falldaten

Der öffentliche Beleg beginnt mit einer unveränderlichen Verfahrensfassung: Commit oder anderes Versionsobjekt, SHA-256-Wert, dauerhafte Adresse und erfasste Forenklassen. Ein Verweis auf main bleibt nützlich zum Lesen, ist aber kein historischer Nachweis.

Es folgt der Autoritätsakt: Beteiligungszeitraum der Community, Verzeichnis der Stellungnahmen, IESG-Entscheidungsreferenz, Entscheidungszeit und Wirksamkeitszeit. Bei gestufter Einführung gehört der Plan hinein. Bei sofortiger Wirksamkeit genügt eine eindeutige Bestätigung.

Eine Ablösungstabelle nennt frühere RFC-Abschnitte und lokale Verfahren, die enden, weiterlaufen oder nur für Altfälle erhalten bleiben. Ernennungen werden separat mit Rollenintervallen verzeichnet. So kann die Teamliste nicht als Ersatz für die Verfahrensgenehmigung dienen.

Der Übergang offener Vorgänge braucht geschützte Zählung: laufende Beschwerden, aktive Einschränkungen, offene Einsprüche und Fristen für Wiederzulassung. Öffentlich reichen Anzahl, Regelklasse und Entscheidung über die Migration. Namen, Vorwürfe und interne Beratung bleiben geschützt.

Forenadministratoren und technische Betreiber können anschließend den Einsatz der Fassung bestätigen. Diese Bestätigung schafft keine Befugnis; sie zeigt, dass die zentrale Entscheidung den Ausführungsort erreicht hat. Korrekturen werden als neue, verknüpfte Zustände angelegt und überschreiben nicht die Vergangenheit.

Transparenz über Macht ist nicht Transparenz über Beschwerden

Moderationsberichte sind personenbezogen. Eine rohe Veröffentlichung kann Beschwerdeführer oder Betroffene identifizieren, schädliche Äußerungen wiederholen, privaten Kontext offenlegen und die ursprüngliche Störung verstärken. Rechtliche Beratung kann weitere Geheimhaltung verlangen.

Der Aktivierungsbeleg betrifft daher Norm, Zuständigkeit und Zeit. Der öffentliche Kern braucht keine Fallgeschichte. Individuelle Maßnahmen benötigen eigene geschützte Aufzeichnungen über Hinweis, Grundklasse, Bereich, Dauer, Entscheider, Überprüfung und Einspruch.

Auch gute Dokumentation darf keine falschen Schlüsse erzeugen. Ein korrekt genehmigtes Verfahren beweist nicht die Fairness jeder Anwendung. Eine Benachrichtigung beweist den Vorwurf nicht. Eine aggregierte Zahl ist kein Gleichbehandlungsurteil. Jede Evidenz bleibt auf ihre Behauptung begrenzt.

Die Texte von Heng Lu sind hier analytische Orientierung, keine Tatsachenquelle zur IETF. Symbolischer Dokumentstatus, ausführbare Entscheidung und beobachtetes Ergebnis liegen auf verschiedenen Ebenen. Eine minimale Spezifikation sollte nur die notwendige Verbindung stabilisieren und spätere Anpassungen bei der dafür autorisierten Stelle lassen.

RFC 9945 verbindet zu Recht forumübergreifende Reichweite, Ermessen, Grenzen, erneute Prüfung und Einspruch. Ein sichtbarer Aktivierungsbeleg macht diese Architektur nicht bürokratischer, sondern zeitlich ehrlich. Das Team beantwortet „wer“. Das Verfahren beantwortet „wie“. Die IESG-Genehmigung beantwortet „mit welcher Autorität“. Erst die Wirksamkeitszeit beantwortet „wann“.

Quellen

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://www.rfc-editor.org/info/rfc9945/
  5. https://www.rfc-editor.org/rfc/rfc9945.html
  6. https://www.rfc-editor.org/rfc/rfc3934.html
  7. https://www.rfc-editor.org/rfc/rfc3683.html
  8. https://www.rfc-editor.org/rfc/rfc9245.html
  9. https://www.rfc-editor.org/rfc/rfc2418.html
  10. https://www.rfc-editor.org/rfc/rfc2026.html
  11. https://datatracker.ietf.org/group/iesg/appeals/artifact/314
  12. https://datatracker.ietf.org/group/iesg/appeals/artifact/315
  13. https://datatracker.ietf.org/group/ietfmoderators/about/
  14. https://github.com/ietf/Moderators/blob/b907805e15f5b902d5d728a9c2c6601962ca625d/README.md
  15. https://github.com/ietf/Moderators/blob/b907805e15f5b902d5d728a9c2c6601962ca625d/sop.md
  16. https://github.com/ietf/Moderators/blob/b907805e15f5b902d5d728a9c2c6601962ca625d/stats.md