Résumé

  • Datatracker présente charter-ietf-radext-07-08, mis à jour le 6 août 2026, comme un projet de nouvelle charte en « External Review ». La charte approuvée demeure la version 07.
  • Le projet contient deux jalons datés de mai, cinq d’août et un de décembre 2026. Les huit cellules « Associated documents » sont vides.
  • Les deux textes correspondant le plus vraisemblablement aux jalons de mai sont des documents actifs du groupe RADEXT, mais leur état IESG reste I-D Exists. Le texte sur la sécurité se dit Informational alors que le jalon annonce Proposed Standard.
  • Parmi les cinq travaux vraisemblablement visés en août, trois sont des Internet-Drafts individuels expirés, un est un candidat à l’adoption expiré et Connect-Info est un candidat actif. Son en-tête annonce lui aussi Informational là où le jalon dit Proposed Standard.
  • Une expiration ne signifie pas un abandon, un statut de candidat ne vaut pas adoption et I-D Exists ne vaut pas dépôt auprès de l’IESG. Les sept dates antérieures ou contemporaines ne sont donc pas, à elles seules, sept livrables manqués.
  • Une base de référence versionnée devrait joindre l’état de la charte, l’identité du texte, la filière de publication, l’adoption, l’état IESG, la transition attendue, la date réelle et tout motif de recalage.

Une charte proposée, deux chronologies

RADEXT entretient et prolonge RADIUS, protocole utilisé pour transporter des informations d’authentification, d’autorisation et de comptabilité dans les systèmes d’accès aux réseaux. Sa page Datatracker actuelle porte le numéro 07-08, mais précise qu’il s’agit d’une proposition de nouvelle charte. Le texte approuvé reste la version 07. La nuance n’est pas éditoriale : elle détermine ce que le groupe est formellement autorisé à prendre en charge.

Le même écran classe la proposition dans l’état complet External Review (Message to Community, Selected by Secretariat). Le glossaire de Datatracker sépare External Review, IESG Review et Approved. Un nouveau texte, un commentaire de ballot résolu ou une objection levée peuvent faire progresser le dossier sans lui conférer le dernier de ces états.

L’historique atteste d’un examen réel. Huit jalons ont été ajoutés le 12 mai. Le 22 juillet, la charte est passée de l’examen interne à l’External Review et un ballot Approve a été créé. À la fin juillet et au début août, des positions ont interrogé la coordination sur le contrôle de congestion, l’emplacement de certains travaux et leur statut de publication. Plusieurs versions se sont succédé ; au 6 août, les Blocks consignés avaient tous évolué vers No Objection.

Il serait donc inexact d’écrire que des objections demeurent bloquantes. Il serait tout aussi inexact de traiter la proposition comme approuvée : au point d’observation, Datatracker affiche toujours External Review. Le dossier public ne dit pas pourquoi la transition suivante n’a pas été inscrite.

La seconde chronologie est celle des jalons. Deux lignes demandent un envoi à l’IESG en mai, cinq en août — quatre Proposed Standards et un texte Informational — puis une dernière en décembre. Aucune des cellules de documents associés ne fournit de lien. Le calendrier nomme une production, mais ne donne pas l’objet stable dont il faudrait vérifier l’état.

Les deux lignes de mai montrent du travail actif, pas la transition annoncée

La première ligne vise une revue de la sécurité et de la vie privée de RADIUS, à envoyer à l’IESG comme Proposed Standard. La correspondance de titre la plus nette est draft-ietf-radext-review-radius-02. C’est un document actif du groupe RADEXT, révisé le 10 août. Son état auprès de l’IESG est I-D Exists et son en-tête vise Informational.

Ces données évitent deux raccourcis opposés. Le travail ne sommeille pas : une nouvelle révision est arrivée en août. Mais l’état public n’enregistre pas l’envoi à l’IESG que le jalon devait mesurer. La différence de filière, Informational dans le texte et Proposed Standard dans la charte proposée, reste elle aussi visible.

La deuxième ligne de mai concerne la dépréciation des pratiques RADIUS non sûres. draft-ietf-radext-deprecating-radius-10 est également un texte actif du groupe, actualisé le 3 juillet, assorti d’un document shepherd et destiné au Standards Track. Il reste néanmoins à I-D Exists. Sa propre page conserve un jalon de janvier 2024 rattaché à la charte approuvée, alors que la proposition donne mai 2026.

Le compte rendu de l’IETF 126 apporte une indication utile. Le 22 juillet, la présidence a expliqué que les deux textes n’avaient pas encore passé le Working Group Last Call et qu’ils devaient y entrer rapidement. Un Internet-Draft peut donc progresser sérieusement sans avoir atteint la transition « draft to IESG ». Le registre devrait pouvoir rendre ces deux vérités simultanément.

Les lignes d’août recouvrent quatre situations institutionnelles

Pour le contrôle de congestion, la correspondance plausible est draft-janfred-radext-radius-congestion-control-01. Il s’agit d’un texte individuel, sans stream défini, expiré en avril 2026 après une révision d’octobre 2025. L’historique de la charte montre que la coordination sur ce sujet a bien été débattue. Faute de lien dans le jalon, l’association reste toutefois une identification éditoriale et non une désignation officielle.

Le même problème se pose pour l’équilibrage de charge des proxys. draft-dekok-radext-proxy-load-00 est un texte individuel expiré, sans stream. Son résumé indique qu’à cette révision, l’expérience opérationnelle était insuffisante pour une publication Standards Track ou BCP. Le jalon d’août parle pourtant de Proposed Standard. Il peut viser une réécriture future, un autre texte ou une décision de filière postérieure ; la ligne publique ne tranche pas.

draft-grayson-5580uncertainty-00 correspond exactement au titre sur l’incertitude de localisation. Lui aussi est individuel et expiré. Le jalon lui attribue la filière Informational, combinaison cohérente en apparence, mais il manque toujours le lien officiel et le reçu de transition.

Le travail de priorité pour les services d’urgence est plus proche du périmètre du groupe. draft-gundavelli-radepcs-02 figure dans l’espace RADEXT avec le statut Candidate for WG Adoption, mais a expiré en juillet. Être candidat ne signifie pas être adopté ; être expiré ne signifie pas que le travail est abandonné. Aucun de ces deux états ne correspond à un envoi à l’IESG.

Connect-Info est le seul des cinq textes vraisemblables d’août qui soit actuellement actif. draft-grayson-connectinfo-10 reste Candidate for WG Adoption et I-D Exists. Son en-tête vise Informational, alors que le jalon proposé annonce Proposed Standard. Le compte rendu de l’IETF 126 indique qu’un appel préalable à l’adoption avait trouvé un consensus et que l’adoption devait intervenir une fois la nouvelle charte achevée.

Cette dépendance est au cœur du problème. Un texte actif et un signal de consensus existent, mais la transition formelle attend une charte encore en examen. Une date isolée fusionne le signal, l’autorisation et l’exécution dans une même case.

Décembre est un indicateur, pas un retard

Le dernier jalon prévoit pour décembre un dépôt sur Status-Realm et la prévention des boucles. La correspondance la plus probable, draft-ietf-radext-status-realm-01, est un texte RADEXT expiré dont la dernière révision remonte à mars 2025.

Décembre n’est pas encore arrivé au point d’observation. Il n’y a donc pas de jalon manqué à constater. L’expiration est un signal de suivi : une nouvelle version, un document de remplacement, une modification du périmètre ou un recalage sera nécessaire si cette famille de textes doit atteindre la transition promise. La transformer dès maintenant en verdict reproduirait précisément l’ambiguïté que le calendrier devrait lever.

Transformer le calendrier en registre d’états

RFC 2418 donne aux jalons une fonction concrète. Une charte fixe des objectifs et des horizons ; les dates aident l’Area Director à suivre l’avancement et les participants potentiels à repérer les moments où leur contribution compte. La liste doit être tenue à jour. Le calendrier dirige donc l’attention institutionnelle.

Mais une date n’est contrôlable que si elle pointe vers un objet. Chaque ligne RADEXT devrait disposer d’un identifiant stable, de la version et de l’état de la charte, du document exact, de son statut individuel, candidat, adopté ou IESG, ainsi que de la filière prévue par la charte et de celle affichée par le texte. La transition mesurée doit être explicite : adoption, Last Call et envoi à l’IESG ne sont pas interchangeables.

Le registre peut ensuite noter une date réelle ou une situation limitée : prévu, actif, atteint, recalé, remplacé ou bloqué. Un recalage doit conserver l’ancienne cible et préciser le motif, l’acteur et la dépendance. Si un jalon de mai était déjà rétrospectif le 12 mai, cela peut être dit. Si août dépendait de l’approbation, la dépendance doit apparaître. Si Proposed Standard devient Informational, la décision doit être enregistrée plutôt que laissée à la comparaison manuelle de deux pages.

Le principe de registre défendu par Heng Lu s’applique ici de façon ciblée : le dossier institutionnel doit refléter l’état qu’il coordonne. Cela ne transforme pas une charte IETF en instrument souverain et ne met pas en cause la légitimité de RADEXT. Il s’agit simplement d’empêcher qu’un calendrier public tire sa signification de zones muettes. La charte donne la direction ; le registre doit montrer le chemin réellement parcouru.

Sources

  1. Heng Lu, The Policy Mirror
  2. Projet de nouvelle charte RADEXT
  3. Historique de la charte RADEXT
  4. Définition des états de charte dans Datatracker
  5. Page du groupe RADEXT
  6. Documents du groupe RADEXT
  7. Compte rendu RADEXT de l’IETF 126
  8. RFC 2418
  9. Revue de la sécurité et de la vie privée de RADIUS
  10. Dépréciation des pratiques RADIUS non sûres
  11. Projet sur le contrôle de congestion RADIUS
  12. Projet sur la charge des proxys RADIUS
  13. Projet sur l’incertitude de localisation
  14. Projet sur les attributs de priorité d’urgence
  15. Projet Connect-Info
  16. Projet Status-Realm