Résumé

  • PROCON a décidé à IETF 126 de proposer une disposition imposant à ses documents de décrire fidèlement la politique en vigueur. À la date d’arrêt de la recherche, Datatracker ne présentait encore que la charte approuvée en 2025 : la nouvelle phrase restait une proposition du groupe à l’IESG.
  • La charte actuelle autorise déjà certaines modifications non éditoriales, notamment sur les jalons d’un groupe de travail et l’adoption d’un Internet-Draft. Elle prévoit aussi un BCP sur la délégation et la succession temporaire du président de l’IETF ; les autres sujets nécessitent une nouvelle charte.
  • Les projets en cours retirent une formule chiffrée sur le consensus, définissent des fonctions d’appui, adaptent la modération aux forums publics modernes et décrivent l’adoption comme un état réversible. Ces changements n’ont pas nécessairement la même source d’autorité.
  • Une pratique observée n’est pas encore, par ce seul fait, une politique normative. À l’inverse, une nouveauté textuelle n’est pas automatiquement hors périmètre : la charte permet expressément certains choix de fond.
  • Un registre public et léger devrait relier chaque différence ayant des effets de gouvernance à son texte de référence, aux preuves de pratique invoquées, à sa qualification, au fondement dans la charte, aux objections et à son parcours ultérieur.
  • Ce registre n’ajouterait ni veto ni étape d’approbation. Il distinguerait aussi la publication d’un BCP de son adoption ultérieure par les outils, les présidents et les groupes.

La règle destinée à définir le présent appartient encore au futur

Le mandat de PROCON répond à une difficulté documentaire ancienne. RFC 2026 et RFC 2418 restent des piliers de la procédure IETF, mais des RFC ultérieurs les ont modifiés, des errata se sont accumulés et l’environnement de travail s’est transformé. Reconstituer la règle applicable demande aujourd’hui de naviguer entre plusieurs couches.

La charte PROCON approuvée charge le groupe de rassembler les RFC qui mettent à jour ces deux textes, ainsi que les errata vérifiés ou marqués pour une mise à jour. Elle ne réduit pourtant pas le projet à un travail de compilation. Elle permet des modifications non éditoriales ciblées concernant les jalons des groupes de travail et l’adoption des projets. Elle autorise séparément un BCP sur la délégation par le président de l’IETF et sur sa succession temporaire. Tout autre élément appelle une nouvelle charte.

Le périmètre comporte donc déjà plusieurs modes d’action légitimes. Consolider consiste à réunir une autorité existante. Corriger un mécanisme périmé consiste à préserver une obligation tout en actualisant son support. Codifier une pratique consiste à décider qu’un comportement observé mérite désormais une expression normative. Réviser délibérément consiste à modifier le dispositif en vertu d’une clause qui l’autorise. Une différence par rapport à l’ancien RFC ne suffit pas à distinguer ces cas.

Les diapositives des présidents à IETF 126 ont bien formulé le malaise. Le programme avait été compris comme une restitution exacte et claire de la procédure en vigueur, les extensions et changements de politique étant remis à plus tard. Mais une lecture très stricte exclurait aussi des corrections éditoriales et l’adaptation à une réalité opérationnelle qui a changé. Une première formulation longue citait les RFC, déclarations de l’IESG et changements d’outillage susceptibles d’étayer l’état présent.

Le compte rendu de la réunion retient finalement une phrase plus courte : le groupe a accepté de proposer que les documents produits décrivent fidèlement la politique en vigueur. Le compte rendu précise qu’il a été préparé avec l’aide de l’IA, puis revu et mis à jour par les présidents et des participants. Il rapporte des décisions vérifiées ; il ne constitue pas une transcription mot à mot.

Au 2 septembre 2026, seule la version charter-ietf-procon-01, mise à jour le 9 juillet 2025, apparaissait comme approuvée. Il faut donc résister à un raccourci : la phrase d’IETF 126 exprime le choix du groupe de proposer un nouveau texte à l’IESG. Elle n’est pas encore l’autorité en vigueur et ne tranche pas rétroactivement le statut de chaque modification antérieure.

Un pourcentage supprimé n’explique pas tout seul ce qui reste

Le cas des nombres illustre la nécessité d’un classement. draft-ietf-procon-2418bis-04 retire le passage de RFC 2418 selon lequel un soutien de 51 % ne suffit pas nécessairement à un consensus approximatif, tandis qu’un soutien de 99 % peut encore masquer une objection substantielle. La présentation sur 2418bis qualifie ces chiffres de règles empiriques déroutantes. Le groupe a maintenu leur suppression, sans ajouter la référence à RFC 7282 qui avait été proposée.

On peut défendre la suppression comme une correction : des seuils frappants risquent de faire passer une appréciation argumentée du consensus pour un vote. Encore faut-il conserver cette justification, le paragraphe d’origine, le principe qui le remplace et la décision du groupe. Faute de quoi, le lecteur devra conclure que la suppression était fidèle simplement parce qu’elle a survécu.

Les fonctions d’appui posent une autre question. La révision 04 permet aux présidents et aux Area Directors de nommer ou de révoquer des participants chargés d’un appui. Elle ajoute que ces fonctions ne changent ni la manière de déterminer le consensus ni les responsabilités de fond des présidents et des Area Directors. Le compte rendu montre que le groupe a voulu retravailler la rédaction tout en gardant ce verrou de responsabilité.

Un message public du groupe observe que de nombreux groupes ne nomment pas formellement un Document Editor et demande si 2418bis doit refléter cette pratique. C’est une source attribuée utile pour tester une affirmation sur l’usage. Ce n’est ni une enquête exhaustive ni une décision normative déjà prise. Le registre devrait séparer l’observation, le choix de la codifier et les limites ajoutées à cette codification.

Les espaces changent, mais le devoir de publicité doit être démontré

RFC 2418 décrivait surtout la liste de diffusion. La révision 04 parle de forums publics comprenant le courriel, les groupes de discussion instantanée et d’autres outils collaboratifs ; elle impose aussi de résumer et de documenter correctement ce qui en ressort.

Cette mise à jour peut n’être que le transfert d’une même exigence de publicité vers des supports nouveaux. Elle peut aussi affecter la compétence du président : quels espaces comptent, quelles mesures de modération y sont possibles, à quel moment une conversation éphémère devient-elle un élément du dossier de consensus ? Pour l’évaluer, il faut savoir si le groupe affirme que l’obligation est inchangée ou qu’il choisit d’en élargir la portée.

Le modèle d’adoption est plus directement rattaché au mandat. Le projet précise que l’adoption désigne un texte comme base d’un élément de travail sans valider son contenu, puis autorise un retour à l’état non adopté. Puisque la charte approuvée nomme l’adoption des projets parmi les domaines ouverts à des changements non éditoriaux, cette nouveauté ne peut être déclarée irrégulière au seul motif que RFC 2418 ne la formulait pas ainsi. Elle peut être une révision volontaire et expressément autorisée.

2026bis a retiré un texte, pas la difficulté de le qualifier

Les diapositives de mise à jour de 2026bis séparent les ajustements qualifiés d’éditoriaux, les questions différées et le travail attendu avant un nouvel appel final du groupe. À IETF 126, le groupe a décidé de revenir sur le texte de la révision 09 concernant les discussions non publiques d’un recours, et de remplacer Unicode par IEEE 802 Ethernet comme exemple de norme externe.

L’échange public sur le périmètre expose deux thèses attribuées. Un participant y voit un pouvoir discrétionnaire nouveau, donc un changement de politique hors charte ; une réponse invoque RFC 2026 et la pratique actuelle pour parler de clarification. L’échange ne transforme aucune de ces positions en conclusion de l’IETF. La décision de retirer les mots règle la prochaine version, mais confirme l’intérêt d’une provenance claire.

Une modification apparemment minuscule, le passage de « expired » à « inactive », a été reportée. Dans la discussion publique correspondante, il est reconnu que le nouveau terme correspond peut-être mieux à Datatracker sans être manifestement éditorial. Si le mot ne fait qu’actualiser l’interface, il corrige un mécanisme périmé. S’il modifie le moment où une règle produit ses effets, il touche à la politique. La longueur du changement ne mesure pas sa portée.

Douze champs, aucune nouvelle autorité

Le registre utile serait un index, non une procédure parallèle. Une entrée complète serait réservée aux différences qui modifient les rôles, la responsabilité, la description du consensus, le dossier public, l’adoption ou les recours. Elle contiendrait :

  1. la révision immuable et la section exacte ;
  2. le RFC, l’erratum ou la déclaration servant de référence ;
  3. la pratique ou l’état de l’outil invoqué, avec preuve publique ;
  4. la ou les qualifications : consolidation, correction d’un mécanisme périmé, codification de pratique, révision délibérée ;
  5. la clause de la charte, le projet de nouvelle charte ou la raison pour laquelle aucun pouvoir nouveau n’est nécessaire ;
  6. la justification éditoriale ;
  7. les objections substantielles, correctement attribuées ;
  8. la décision du groupe et sa date ;
  9. les changements issus du dernier appel du groupe ;
  10. les décisions de l’appel IETF et de l’IESG ;
  11. le texte publié ;
  12. l’adoption opérationnelle ou dans les outils.

Une entrée peut cumuler deux catégories. Adapter une liste de diffusion à plusieurs forums peut être à la fois une correction technique et une codification. L’important n’est pas de forcer une étiquette unique, mais d’empêcher qu’une différence substantielle n’ait aucune généalogie.

Le registre n’accorde pas davantage de poids institutionnel à un courriel individuel. Une objection y demeure attribuée à son auteur. La décision du groupe apparaît dans un autre champ. Si le texte est abandonné, l’entrée conserve ce résultat sans faire survivre la proposition dans la norme.

La Note 64 de Heng Lu propose une grille de conception : stabiliser un minimum initial, localiser la décision future auprès de l’acteur compétent, puis distinguer l’adoption opérationnelle. Elle ne fournit aucun fait sur PROCON et ne remplace pas la procédure IETF. Elle aide seulement à ne pas transformer le socle, la décision ultérieure et la mise en pratique en un instant fictivement unique.

Les appels successifs décident ; ils n’archivent pas forcément le raisonnement

La procédure existante offre une objection sérieuse au registre. Le consensus du groupe, le Working Group Last Call, l’IETF Last Call, l’examen de l’Area Director et l’IESG peuvent corriger le texte. À IETF 126, l’Area Director a estimé que 2026bis entrerait dans le périmètre avec la modification proposée, tout en signalant qu’il n’avait pas encore étudié en profondeur les différences de 2418bis. Ce sont des contrôles réels.

L’inventaire PROCON indiquait au point d’arrêt 2026bis-11 en Working Group Last Call et 2418bis-04 comme document du groupe. Aucun de ces états ne vaut approbation par l’IESG ou publication comme BCP. Le résultat et ses justifications peuvent encore changer.

Mais les étapes de décision n’organisent pas automatiquement la mémoire. Une justification peut se trouver dans un courriel, son contre-argument dans une réunion, la décision dans des minutes et sa conséquence dans un changelog. Un futur lecteur verra que le texte a été approuvé sans savoir si une pratique avait été vérifiée, simplement affirmée ou rendue inutile par un autre fondement.

Le registre ne remplace donc aucun appel. Il rend leur effet intelligible. Une nouvelle qualification par l’IESG peut être ajoutée ; une différence supprimée reçoit une clôture ; une affirmation de pratique fragile peut être retirée ou documentée. La chaîne de décision garde ainsi la capacité de changer d’avis sans perdre la trace de ce qu’elle a examiné.

Sources

  1. Charte PROCON approuvée
  2. Inventaire des documents PROCON
  3. Compte rendu PROCON à IETF 126
  4. Diapositives des présidents de PROCON
  5. Mise à jour de 2026bis
  6. Présentation de 2418bis
  7. Note 64 de Heng Lu
  8. Discussion publique sur le périmètre
  9. Discussion publique sur la pratique du Document Editor
  10. Discussion publique sur inactive et expired
  11. draft-ietf-procon-2026bis-11
  12. draft-ietf-procon-2418bis-04
  13. RFC 2026
  14. RFC 2418