Zusammenfassung

  • Der IESG genehmigte charter-ietf-radext-08 am 21. September 2026, nachdem Formulierungen gestrichen worden waren, die Bedürfnissen externer Organisationen oder anderer IETF-Arbeitsgruppen einen automatischen Vorrang verleihen konnten.
  • Roaming, Interoperabilität mit historischen Implementierungen und Multi-Hop-RADIUS bleiben im Geltungsbereich. Kein bestimmter Antrag, Entwurf, Meilenstein, Protokollwechsel oder Einsatz wurde damit genehmigt.
  • Ein Nachweis „vom Geltungsbereich zum Konsens“ könnte Herkunft und Evidenz einer Anforderung mit Charta-Grundlage, Dokumentstatus, Kompatibilität und RADEXTs eigenem Konsens verbinden.

Genehmigt wurde ein Rahmen, nicht eine Vermutung

Die Fassung 07-01 vom April nannte die Wireless Broadband Alliance und eduroam als Gemeinschaften, mit denen RADEXT koordiniert. Zudem sollte die Gruppe nach Bedarf Erweiterungen oder Leitlinien zur Unterstützung solcher Organisationen veröffentlichen und Erweiterungen definieren, die externe Organisationen oder andere IETF-WGs benötigten.

Die Einwände bestritten keine realen Betriebsprobleme, sondern die Richtung der Autorität. Mahesh Jethanandani sah im „Unterstützen“ externer Organisationen eine Umkehr der Beziehung: Ein Antrag konnte IETF-Gewicht erhalten, bevor er IETF-Konsens gewonnen hatte. Roman Danyliw fragte nach einem Sonderstatus und betonte, dass selbst die Bitte einer anderen IETF-WG RADEXT-Konsens braucht. Seine Abhilfe war die Streichung beider Passagen.

Die genehmigte Fassung 08 folgt diesem Weg. WBA und eduroam werden nicht mehr genannt; externer Bedarf ist keine eigene Arbeitskategorie. Das entwertet Betriebserfahrung nicht, sondern zeigt den Entscheidungspunkt, an dem sie zu IETF-Arbeit werden kann.

Die Genehmigung ist eindeutig: Der Datatracker führt Version 08 als Approved. Eine Charta genehmigt jedoch Geltungsbereich, Ziele und Ergebnisarten, nicht vorab den Inhalt künftiger Beiträge. Weder eine WBA-Anforderung noch eine eduroam-Vorgabe, ein neues Attribut, ein bestimmter Entwurf oder ein Einsatzplan wurden dadurch gebilligt.

Drei Bahnen statt eines offenen Kundenauftrags

Kleine RADIUS-Erweiterungen sollen gewöhnlich als Proposed Standard laufen. Hinweise zu Roaming und zur Interoperabilität mit historischen Implementierungen können Informational oder Best Current Practice werden. Protokollklarstellungen gehören in Informational-Dokumente.

Die Einteilung verhindert, dass operative Dringlichkeit allein den Rang festlegt. Ein gut belegter Roaming-Fehler kann Implementierungshinweise statt einer normativen Erweiterung erfordern. Eine kleine Erweiterung kann zum Standards Track passen, ohne dass ihr externer Sponsor das Design bestimmt.

Zwei Schranken bleiben: Interoperabilität mit Altimplementierungen ist zu berücksichtigen, und nicht rückwärtskompatible Änderungen müssen begründet werden. Multi-Hop-RADIUS bleibt zur Klärung von Architektur und Anforderungen im Rahmen; das Ziel wählt aber keine Lösung aus.

Input ist keine delegierte Stimme

RFC 4053 verlangt angemessene Berücksichtigung einer Liaison-Mitteilung, erlaubt dem IETF aber, die Arbeit auszuführen, abzulehnen oder einen anderen Weg zu erklären. Der Absender muss weiterhin einen technischen Fall darlegen. RFC 4691 setzt die Gegenbegrenzung: Eine Liaison übermittelt bestehenden IETF-Konsens; sie erhält keine Vollmacht, ihn zu erzeugen.

Betreiber, Roaming-Verbünde, Hochschulen und Anbieter können Fehlerdaten, Größenordnungen und Kompatibilitätszwänge beitragen, die einer abstrakten Diskussion fehlen. Einfluss entsteht aus Teilnahme, reproduzierbaren Belegen und der Bearbeitung technischer Einwände, nicht aus einem bekannten Organisationsnamen.

RFC 2418 verortet die Entscheidung in der WG: Die Charta steckt Problem und Ziele ab, die Gruppe arbeitet mit rough consensus. RFC 7282 erklärt, dass dies keine Stimmenzählung ist, sondern die Prüfung, ob technische Einwände verstanden und behandelt wurden.

Der Nachweis vom Geltungsbereich zum Konsens

Jede extern angestoßene Arbeit könnte einen kurzen Nachweis führen. Er nennt Herkunft, persönliche oder organisatorische Rolle, konkrete Störung, betroffene Implementierungen und reproduzierbare Evidenz. Danach folgen die Stelle in Version 08, die vorgesehene Bahn Proposed Standard, Informational oder BCP sowie Folgen für Altbestand und Rückwärtskompatibilität.

Schließlich werden Entwurf, Redakteure, Meilenstein, wesentliche Einwände, ihre Behandlung und der WG-Konsens festgehalten. Anbieterzusage, ausgelieferter Code, beobachteter Einsatz und getestete Interoperabilität bleiben vier verschiedene Tatsachen.

Unbekanntes bleibt unbekannt. Die Bedeutung des Antragstellers ersetzt keinen Mitschnitt; „von der Charta gedeckt“ ersetzt keinen Konsens; eine IETF-Publikation beweist keinen Einsatz.

Was die Genehmigung entschied

Der IESG löste eine Governance-Frage, bevor sie zur technischen Abkürzung wurde. RADEXT darf weiter operative Gemeinschaften anhören und Dokumente für Roaming und Altsysteme erstellen. Die Gruppe ist aber nicht deren Normungsdienstleister, und externe Herkunft schiebt einen Vorschlag nicht nach vorn.

Die Tür bleibt offen, doch die Schwelle gilt für alle: Geltungsbereich, Belege, technisches Urteil und rough consensus.

Quellen