Zusammenfassung

  • Datatracker führt charter-ietf-radext-07-08, zuletzt am 6. August 2026 aktualisiert, als vorgeschlagenen Neucharter im External Review. Als genehmigter Charter gilt weiterhin Version 07.
  • Die Vorlage enthält zwei Meilensteine für Mai, fünf für August und einen für Dezember 2026. In allen acht Zeilen ist Associated documents leer.
  • Die plausibelsten Dokumente für Mai sind aktive RADEXT-WG-Drafts, stehen beim IESG aber jeweils auf I-D Exists. Der Security Review nennt sich Informational, der Meilenstein dagegen Proposed Standard.
  • Die fünf August-Zeilen scheinen drei abgelaufene Individual Drafts, einen abgelaufenen Kandidaten zur WG-Annahme und einen aktiven Kandidaten zu betreffen. Beim aktiven Connect-Info weichen die Publikationspfade ebenfalls ab.
  • Expired bedeutet nicht aufgegeben, Candidate for WG Adoption nicht angenommen und I-D Exists nicht beim IESG eingereicht. Sieben Monatsangaben sind deshalb keine sieben Versäumnisnachweise.
  • Ein versionierter Ausgangsstand sollte Charter-Status, Dokumentidentität, Publikationspfad, Annahme- und IESG-Status, gemessenen Übergang, Ist-Datum und Begründung jeder Neuplanung verbinden.

Ein Vorschlag mit zwei Zeitachsen

RADEXT pflegt und erweitert RADIUS, das Authentifizierungs-, Autorisierungs- und Abrechnungsinformationen in Netzzugangssystemen transportiert. Die aktuelle Datatracker-Seite zeigt den Entwurf 07-08, unterscheidet ihn aber ausdrücklich vom genehmigten Charter 07. Damit ist nicht nur ein redaktioneller Versionshinweis gemeint. Der Unterschied entscheidet, welches Arbeitsprogramm institutionell in Kraft ist.

Der vollständige Zustand lautet External Review (Message to Community, Selected by Secretariat). Die Datatracker-Hilfe definiert External Review, IESG Review und Approved getrennt. Eine neue Textfassung, ein aufgelöster Ballot-Einwand oder ein geändertes Votum dokumentiert Fortschritt, ersetzt aber nicht den formalen Übergang zu Approved.

Die Historie zeigt intensive Bearbeitung. Am 12. Mai wurden acht Meilensteine ergänzt. Am 22. Juli wechselte der Entwurf aus der internen Charterprüfung in External Review, und ein Approve-Ballot wurde angelegt. Ende Juli und Anfang August gab es Blocks zu Abstimmung bei Congestion Control, zur Einordnung von Arbeitsgegenständen und zu Publikationsstatus. Die Fassungen liefen bis 07-08; am 6. August waren alle verzeichneten Blocks zu No Objection geworden.

Offene Blocks zu behaupten wäre deshalb falsch. Ihre Auflösung mit Genehmigung gleichzusetzen wäre ebenso falsch. Am Stichtag meldete die jüngste Seite weiterhin External Review, ohne die ausbleibende nächste Statusänderung zu erklären.

Die zweite Achse ist die Meilensteinliste. Zwei Proposed Standards sollten im Mai zum IESG, vier Proposed Standards und ein Informational-Dokument im August, ein weiterer Proposed Standard im Dezember. Keine Zeile enthält einen Link im Feld Associated documents. Die Bezeichnung des Vorhabens und der Monat sind sichtbar, nicht aber das prüfbare Objekt.

Die Mai-Drafts leben, der benannte Übergang fehlt

Die erste Zeile verlangt eine Sicherheits- und Datenschutzprüfung von RADIUS als Proposed Standard beim IESG. Am stärksten passt draft-ietf-radext-review-radius-02, ein aktives WG-Dokument, das am 10. August aktualisiert wurde. Sein IESG-Status lautet I-D Exists; der eigene Kopf weist Informational aus.

Die August-Revision belegt laufende Arbeit. Sie belegt nicht den im Meilenstein genannten Schritt „to IESG“. Gleichzeitig bleibt offen, warum der Charter Proposed Standard und das Dokument Informational nennt. Weder Stillstand noch Abschluss lässt sich daraus ableiten.

Der zweite Mai-Punkt betrifft die Abkehr von unsicheren RADIUS-Praktiken. draft-ietf-radext-deprecating-radius-10 ist ein aktiver WG-Draft, am 3. Juli aktualisiert, mit Document Shepherd und Standards-Track-Kopf. Auch er steht auf I-D Exists. Seine Dokumentseite zeigt weiterhin einen Januar-2024-Meilenstein des genehmigten Charters, während der Vorschlag Mai 2026 vorsieht. Eine öffentlich nachvollziehbare Überleitung fehlt.

Das Protokoll von IETF 126 ordnet den Prozess ein. Am 22. Juli erklärte der Vorsitz, beide Drafts hätten den Working Group Last Call noch nicht durchlaufen und sollten zügig dorthin gebracht werden. Aktive Arbeit und ein noch nicht erreichter IESG-Übergang sind damit keine Gegensätze.

Die August-Zeilen verteilen sich auf vier Reifegrade

Für Congestion Control ist draft-janfred-radext-radius-congestion-control-01 die plausibelste Zuordnung. Der Individual Draft hat keinen definierten Stream, wurde zuletzt im Oktober 2025 überarbeitet und lief im April 2026 ab. Aus der Charter-Historie geht hervor, dass die Koordination des Themas geprüft wurde. Ohne Link bleibt die Dokumentzuordnung jedoch redaktionell und nicht offiziell.

Für Proxy Load Balancing liegt draft-dekok-radext-proxy-load-00 nahe, ebenfalls ein abgelaufener Individual Draft ohne Stream. Sein Abstract sagt, dass die Betriebserfahrung in dieser Fassung nicht für Standards Track oder BCP ausreichte. Der Meilenstein nennt trotzdem einen Proposed Standard im August. Gemeint sein könnte eine spätere Neufassung, ein anderes Dokument oder eine neue Pfadentscheidung. Die öffentliche Zeile entscheidet das nicht.

draft-grayson-5580uncertainty-00 entspricht genau dem Titel zur Ortsunsicherheit. Auch dieser Individual Draft ist abgelaufen. Informational im Meilenstein erscheint plausibel, liefert aber weder eine offizielle Verknüpfung noch einen IESG-Übergang.

Das Notfallvorsorge-Dokument draft-gundavelli-radepcs-02 wird als Candidate for WG Adoption geführt und lief im Juli ab. Ein Kandidat ist nicht angenommen; ein Ablauf ist keine Aufgabeerklärung. Beide Eigenschaften liegen vor einem Versand an das IESG.

Connect-Info ist unter den fünf wahrscheinlichen Zuordnungen das einzige aktive Dokument. draft-grayson-connectinfo-10 trägt Candidate for WG Adoption und I-D Exists. Im Kopf steht Informational, im vorgeschlagenen Meilenstein Proposed Standard. Das Protokoll von IETF 126 hält fest, dass ein Voraufruf Konsens ergab und die Annahme nach Abschluss des Neucharters erfolgen sollte.

Genau diese Abhängigkeit gehört in die Zeile. Ein aktiver Text und ein Konsenssignal sind vorhanden, doch der formale Schritt wartet auf einen noch geprüften Charter. Ein bloßer August-Termin verschmilzt Unterstützung, Mandat, Annahme und IESG-Einreichung.

Dezember ist noch kein verfehlter Termin

Der letzte Punkt plant Status-Realm und Loop Prevention für Dezember. Die wahrscheinlichste Zuordnung draft-ietf-radext-status-realm-01 ist ein RADEXT-WG-Draft, zuletzt im März 2025 überarbeitet und inzwischen abgelaufen.

Am Stichtag lag Dezember noch in der Zukunft. Ein Versäumnis lässt sich nicht feststellen. Der Ablauf ist aber ein Frühindikator: Für den geplanten Übergang braucht es eine neue Fassung, ein Ersatzdokument, eine Umfangsänderung oder eine Neuplanung. Ein Indikator ist kein Urteil.

Aus der Liste muss ein Zustandsregister werden

RFC 2418 beschreibt den Zweck von Meilensteinen. Ziele und Zeitrahmen helfen dem Area Director, Fortschritt zu verfolgen, und potenziellen Teilnehmenden, kritische Zeitpunkte für Beiträge zu erkennen. Die Liste soll regelmäßig aktualisiert werden. Termine lenken somit institutionelle Aufmerksamkeit.

Jede Zeile braucht dafür eine stabile Kennung, Charter-Version und -Status, die genaue Dokumentfamilie, den Zustand als Individual Draft, Kandidat, WG-Dokument oder IESG-Vorlage und den Publikationspfad sowohl im Charter als auch im aktuellen Kopf. Ebenso wichtig ist der gemessene Vorgang: Annahme, Working Group Last Call und IESG-Einreichung sind verschiedene Ereignisse.

Danach kann ein Ist-Datum oder ein begrenzter Zustand folgen: geplant, aktiv, erreicht, neu terminiert, ersetzt oder blockiert. Eine Neuplanung bewahrt das alte Ziel und nennt Grund, Akteur und Abhängigkeit. War Mai bereits rückblickend, als die Zeilen am 12. Mai hinzukamen, sollte das dort stehen. War August von der Genehmigung abhängig, gehört die Bedingung ins Register. Ein Wechsel des Publikationspfads braucht einen Beschlussnachweis.

Heng Lus Ledger-Prinzip ist hier in einem engen Sinn nützlich: Eine institutionelle Aufzeichnung sollte den Zustand beschreiben, den sie koordiniert. Das macht einen IETF-Charter nicht zu einem souveränen Instrument und bestreitet nicht die Legitimität von RADEXT. Es verlangt lediglich, dass ein öffentlicher Zeitplan seine Bedeutung nicht aus Lücken zwischen Seiten bezieht. Der Charter setzt die Richtung; das Register bewahrt den tatsächlichen Weg.

Quellen

  1. Heng Lu, The Policy Mirror
  2. Vorgeschlagener RADEXT-Neucharter
  3. RADEXT-Charter-Historie
  4. Datatracker-Definitionen der Charter-Zustände
  5. RADEXT-Gruppenseite
  6. RADEXT-Gruppendokumente
  7. RADEXT-Protokoll von IETF 126
  8. RFC 2418
  9. RADIUS Security and Privacy Review
  10. Draft zur Abkehr von unsicheren RADIUS-Praktiken
  11. RADIUS-Congestion-Control-Draft
  12. RADIUS-Proxy-Load-Draft
  13. Draft zur Ortsunsicherheit
  14. Draft zu Notfallvorsorge-Attributen
  15. Connect-Info-Draft
  16. Status-Realm-Draft