Résumé

  • L’IESG a approuvé charter-ietf-radext-08 le 21 septembre 2026 après la suppression de formulations qui pouvaient accorder une priorité implicite aux besoins d’organisations extérieures, voire d’un autre groupe IETF.
  • La charte finale couvre encore l’itinérance, l’interopérabilité historique et le RADIUS multi-saut. Elle n’approuve aucune demande particulière, aucun brouillon, jalon, changement de protocole ou déploiement.
  • Un reçu « du périmètre au consensus » permettrait de relier l’origine et les preuves d’une demande à la charte, au statut documentaire, aux contraintes de compatibilité et au consensus propre de RADEXT.

Une approbation qui retire une présomption

La version 07-01 d’avril citait la Wireless Broadband Alliance et eduroam parmi les communautés avec lesquelles RADEXT se coordonnait. Elle ajoutait que le groupe publierait des extensions ou des recommandations selon les besoins de ces organisations et définirait les extensions demandées par des organismes extérieurs ou d’autres groupes IETF.

Le problème n’était pas la réalité de leurs déploiements, mais le sens de la relation. Dans son objection, Mahesh Jethanandani a estimé que « soutenir le travail » d’organisations extérieures inversait le rapport normal et pouvait donner à une demande la force de l’IETF avant tout consensus IETF. Roman Danyliw a demandé si ces organismes recevaient un statut privilégié. Même une demande issue d’un autre groupe IETF, a-t-il rappelé, doit encore convaincre RADEXT. Sa solution consistait à supprimer les deux formulations.

La version 08 approuvée suit cette direction. Elle ne cite plus WBA ou eduroam et ne transforme plus le besoin externe en catégorie de travail autonome. Cela ne rend pas leurs problèmes secondaires. Cela précise l’endroit où une expérience opérationnelle devient, ou ne devient pas, un travail de l’IETF.

L’approbation reste une décision réelle : le Datatracker marque la version 08 « Approved ». Mais une charte fixe un périmètre, des objectifs et des familles de résultats. Elle ne pré-approuve pas le contenu d’une future contribution. Le dossier ne permet donc pas d’affirmer qu’un besoin WBA, une exigence eduroam, un nouvel attribut, un brouillon nommé ou un plan de déploiement a reçu l’aval de l’IETF.

Trois filières plutôt qu’une relation de commande

Le texte final classe mieux les travaux possibles. Les petites extensions de RADIUS relèvent normalement de Proposed Standard. Les recommandations sur l’itinérance et l’interopérabilité avec les mises en œuvre historiques peuvent devenir Informational ou Best Current Practice. Les clarifications du protocole doivent être Informational.

Ces filières indiquent la portée future d’un document et empêchent l’urgence opérationnelle de choisir silencieusement son statut. Un problème d’itinérance peut être urgent et bien documenté sans exiger une extension normative. Une petite extension peut convenir à la filière des standards, mais son promoteur extérieur n’en décide pas la conception.

Deux contraintes subsistent : tenir compte des implémentations anciennes et justifier toute rupture de compatibilité. Le RADIUS multi-saut reste dans le périmètre, notamment pour préciser l’architecture et les exigences, sans qu’une solution particulière soit pour autant sélectionnée.

L’apport extérieur n’est pas un vote délégué

RFC 4053 exige qu’une liaison externe soit dûment considérée, mais autorise l’IETF à agir, à ne pas agir ou à expliquer une autre voie. L’émetteur doit encore présenter son cas technique comme le ferait l’auteur d’un Internet-Draft. RFC 4691 ferme la boucle : un agent de liaison transmet un consensus IETF déjà formé ; il ne reçoit pas le pouvoir d’en fabriquer un.

Cette frontière protège plutôt qu’elle ne réduit la participation. Opérateurs, consortiums d’itinérance, universités et fournisseurs possèdent souvent les journaux d’erreurs, l’échelle et les contraintes d’interopérabilité qui manquent à une discussion abstraite. Leur influence provient de leur participation, de preuves reproductibles et d’un bon argument technique, pas du nom de leur institution.

RFC 2418 situe ensuite la décision : la charte encadre le problème et les objectifs, tandis que le groupe travaille par rough consensus. RFC 7282 rappelle qu’il ne s’agit pas de compter les voix, mais de comprendre et de traiter les objections techniques.

Le reçu du périmètre au consensus

Pour chaque travail inspiré par une demande externe, RADEXT pourrait conserver un reçu court. Il identifierait l’origine de la demande, le rôle personnel ou organisationnel du porteur, le défaut opérationnel précis, les implémentations touchées et les éléments reproductibles.

Il indiquerait ensuite le passage exact de la version 08, la filière Proposed Standard, Informational ou BCP visée, et l’effet sur l’interopérabilité historique et la compatibilité ascendante. Enfin viendraient le brouillon, les éditeurs, le jalon responsable, les objections principales, leur traitement et le constat de consensus.

Les affirmations de déploiement resteraient séparées. Un engagement de fournisseur, du code livré, un déploiement observé et un test d’interopérabilité sont quatre faits. Une case inconnue reste inconnue : le prestige du demandeur ne remplace pas une trace réseau, et l’expression « dans la charte » ne remplace pas un consensus.

La portée exacte de la décision

L’IESG a réglé une question de gouvernance avant qu’elle ne devienne un raccourci technique. RADEXT peut continuer d’écouter les communautés opérationnelles et produire des documents utiles à l’itinérance et aux systèmes anciens. Il n’est pas leur sous-traitant normatif, et la provenance externe d’une proposition ne la place pas en tête de file.

La porte reste donc ouverte, mais le seuil est commun : périmètre, preuve, jugement technique et rough consensus.

Sources