Résumé

  • Publiée le 1er juillet 2026, la révision -11 de draft-ietf-procon-2026bis demeure en Working Group Last Call au 27 août. Elle propose une consolidation de la procédure, mais n’a pas encore remplacé la BCP 9.
  • RFC 2026 autorise déjà une variance pour une spécification déterminée lorsqu’une impasse survient ou que la procédure ne donne pas de réponse. Le groupe responsable — ou un comité ad hoc en l’absence de groupe — recommande ; l’IESG décide après une analyse motivée.
  • La demande doit identifier la disposition en cause, être publiée sous forme d’Internet-Draft, subir un Last Call prolongé d’au moins quatre semaines, puis faire l’objet d’une annonce. Une variance approuvée est publiée comme BCP et reste susceptible d’appel.
  • Les délais expressément fixés, l’ouverture, l’équité, le consensus, la conservation des traces et plusieurs rouages centraux ne peuvent être écartés. La bonne unité de preuve est donc un reçu d’exception attaché à un seul texte, jamais une permission générale transmise par habitude.

Le dossier particulier et la règle commune

Une institution peut avoir besoin d’une soupape sans vouloir abandonner sa procédure. C’est même le test décisif d’une bonne soupape : elle traite le cas qui ne rentre pas dans la règle, tout en laissant la règle lisible pour les cas suivants.

Supposons qu’un groupe travaille sur une spécification dont l’intérêt technique est réel, mais qu’une exigence procédurale ne puisse être satisfaite. Si le registre se contente de remplacer cette exigence par la mention « facultative », il commet une erreur de catégorie. Le fait observé n’est pas que l’exigence a disparu. Le fait est qu’une autorité identifiée a admis, pour une version identifiée d’une spécification, un écart identifié, pour des raisons consignées et sous des limites données.

Cette nuance résiste mal aux résumés. Une décision ancienne devient une « pratique ». La pratique devient un « précédent ». Le précédent est cité sans ses restrictions, puis intégré à une liste de contrôle. Au bout de la chaîne, personne n’a formellement révisé la procédure, mais l’outil et la mémoire collective se comportent comme si la révision avait eu lieu.

Il faut donc maintenir deux objets. La règle commune porte sa propre version et sa propre autorité. Le dossier de variance porte la spécification concernée, la disposition écartée, la recommandation, le raisonnement, le calendrier de consultation, les restrictions, la décision et les recours. Le second peut éclairer l’analyse du premier ; il ne peut pas le modifier par simple proximité.

Le terme de « précédent » demande la même prudence. RFC 2026 oblige l’IESG à examiner les effets de précédent d’une variance. Cela signifie qu’une décision peut influencer les attentes, les coûts ou les arguments ultérieurs. Cela ne signifie pas qu’elle produit une autorisation auto-exécutoire pour le dossier suivant. L’effet de précédent est un risque à analyser, non une règle à recopier.

Ce que le projet 2026bis établit — et ce qu’il n’établit pas encore

La fiche Datatracker décrit draft-ietf-procon-2026bis-11 comme une Internet-Draft active du groupe PROCON. Son champ Intended RFC status affiche None, tandis que l’en-tête du projet indique Best Current Practice comme statut visé. Ces mentions ne constituent pas une décision de statut déjà acquise. Cette révision a été publiée le 1er juillet 2026 et doit expirer le 2 janvier 2027 si elle n’est ni mise à jour ni avancée. L’historique public montre le passage en Working Group Last Call le 21 mai, alors que le texte était à la révision -08.

Au 27 août, l’état du groupe était toujours In WG Last Call. L’état IESG indiquait I-D Exists, sans date de téléconférence. Ces éléments attestent un travail mûr soumis à l’examen du groupe. Ils n’attestent ni une approbation IESG, ni une publication RFC, ni l’entrée en vigueur d’une nouvelle BCP.

Si le texte aboutit, il consolidera et rendra obsolètes plusieurs RFC de procédure, dont RFC 2026, et mettra à jour RFC 7475. La charte PROCON explique la logique : les textes fondamentaux RFC 2026 et RFC 2418 ont accumulé une longue chaîne de mises à jour. Le mandat consiste à les réunir avec les errata vérifiés et à rendre l’ensemble plus cohérent. Les modifications non éditoriales supplémentaires sont limitées aux sujets nommés par la charte, faute de quoi un nouveau mandat serait nécessaire.

La section 11 de la révision -11 conserve l’architecture de la variance. Elle modernise et renumérote la présentation, mais ne crée pas cette possibilité en 2026. La source publiée reste la section 9 de RFC 2026, qui formulait déjà en 1996 la distinction entre une dérogation ponctuelle et une modification permanente de la BCP.

Une base de gouvernance sérieuse doit donc afficher les états côte à côte. RFC 2026 constitue la référence publiée actuelle. 2026bis-11 est la proposition consolidée en cours d’examen. Un futur RFC, s’il est approuvé, deviendra la nouvelle référence à la date de sa publication attribuable. Aucune de ces lignes ne doit écraser prématurément les autres.

Une recommandation n’est pas une autorisation

La procédure commence au plus près de la spécification. Le groupe de travail responsable recommande la variance ; s’il n’existe pas de groupe, un comité ad hoc peut le faire. Cette origine compte : une difficulté personnelle, une échéance commerciale ou une demande d’éditeur ne devient pas une question de procédure par le seul choix des mots.

La recommandation ouvre l’examen de l’IESG. Elle ne fait pas entrer le document sur la voie des normes et ne le fait pas progresser automatiquement. L’IESG doit déterminer si le bénéfice probable pour la communauté Internet l’emporte sur le coût du non-respect. Son examen doit porter sur le mérite technique, la possibilité d’atteindre les objectifs de la procédure sans variance, les solutions de remplacement, les conséquences collatérales, les effets de précédent et la possibilité de réduire l’exception à sa portée minimale.

Cette grille interdit plusieurs raccourcis. Un texte techniquement séduisant ne démontre pas que la voie normale est impraticable. L’urgence ne prouve pas qu’une consultation raccourcie produira une meilleure décision. Le soutien d’un groupe ne dispense pas d’examiner les tiers affectés. Et l’existence d’un dossier antérieur ne répond pas à la question de savoir si la nouvelle affaire partage réellement les mêmes contraintes.

La variance peut être limitée à certaines dispositions et assortie de restrictions supplémentaires. Sa logique n’est donc pas « la procédure s’arrête ici », mais « une exigence précisément nommée ne s’applique pas de la manière ordinaire dans ce cas, tandis que le reste continue de s’imposer ». Plus la décision avance, plus la frontière devrait devenir explicite.

La publicité comme chaîne de garde

Une décision exceptionnelle est facile à résumer et difficile à auditer. La procédure réduit cet écart en distribuant la preuve entre plusieurs étapes.

La proposition doit exposer le problème perçu, la disposition exacte qui pose difficulté et l’examen réalisé par l’IESG. Elle doit prendre la forme d’une Internet-Draft, donc d’un objet versionné et publiquement identifiable. L’IESG lance ensuite un Last Call prolongé d’au moins quatre semaines. Après cette période, il prend sa décision finale et l’annonce à l’IETF. Si la variance est approuvée, elle est transmise pour publication en tant que BCP. La voie d’appel reste ouverte.

Chaque étape a un auteur distinct. Le groupe porte la recommandation. L’IESG porte l’analyse et la décision. Les participants portent leurs objections et contributions. Le registre public porte les versions et les dates. L’instance d’appel, lorsqu’elle est saisie, porte un autre dossier. La légitimité ne repose donc pas sur une unique formule « exception accordée », mais sur une chaîne dont les pièces peuvent être rapprochées.

Le Last Call de quatre semaines n’est pas un délai décoratif. Il donne le temps de lire l’écart concret, de tester le raisonnement et de signaler les effets indirects. Dans la logique de RFC 7282, le rough consensus ne se réduit pas à compter des messages favorables. La substance des objections et leur traitement importent. Un reçu de variance doit conserver cette disposition, y compris lorsqu’une objection ne bloque pas le résultat final.

Un socle que la soupape ne peut traverser

La limite la plus forte de la procédure se trouve dans la liste de ce qui demeure obligatoire. Une variance ne peut pas réduire un délai expressément spécifié. Elle ne peut écarter l’ouverture, l’équité ou le consensus. Elle ne peut supprimer la tenue de traces appropriées des réunions et des discussions sur liste. Elle ne peut davantage neutraliser les sections centrales relatives à la révision des BCP, au déclenchement d’une action, à l’examen IESG, à la publication, aux conflits, aux appels et à la variance elle-même. Le projet 2026bis reprend ce plancher avec sa nouvelle numérotation.

Ce socle répond à un problème classique : une procédure d’exception qui pourrait s’exempter de ses propres garanties détruirait la possibilité de vérifier sa légitimité. Si la publicité, les délais, les archives ou les recours disparaissaient au moment précis où la règle est assouplie, l’institution demanderait à ses participants de faire confiance à une décision dont elle aurait retiré les preuves.

Le plancher ne rend pas toute contestation impossible. Il ne garantit pas que chaque participant trouvera le résultat juste. Il garantit une chose plus modeste et plus utile : le désaccord peut porter sur une décision visible, attribuable et inscrite dans une procédure que l’exception n’a pas elle-même effacée.

Le reçu de variance

Le meilleur antidote à la réécriture silencieuse est un reçu suffisamment précis pour voyager sans perdre son périmètre. Il devrait réunir l’identifiant de la variance ; le nom, la révision et l’empreinte de la spécification ; le groupe ou comité responsable ; la recommandation datée ; la disposition exacte ; l’impasse ou le silence procédural observé ; et l’exigence non satisfaite.

Il devrait ensuite conserver l’évaluation du mérite technique, le rapport bénéfices-coûts, les solutions rejetées, les effets collatéraux et de précédent, la portée exacte et les restrictions ajoutées. La proposition d’Internet-Draft et son empreinte, les heures d’ouverture et de clôture du Last Call, les objections importantes et leur disposition forment la partie publique de la chaîne.

Enfin viennent la décision IESG, l’annonce, l’identité de la BCP publiée si l’issue est positive, l’état des appels et la condition de fin de l’exception. Deux non-affirmations doivent être lisibles : le reçu ne décide aucun dossier ultérieur et ne prouve aucune adoption opérationnelle externe.

Un tel schéma évite aussi une autre confusion. Une variance approuvée est une BCP, mais elle n’est pas pour autant la révision générale de la BCP de procédure. Le type de publication stabilise et rend la décision citable ; la portée du contenu demeure celle du cas nommé. Pour modifier durablement la règle réutilisable, RFC 2026 renvoie au processus BCP ordinaire.

La frontière avec l’adoption sur le réseau

La procédure de l’IETF détermine la trajectoire d’un document dans l’IETF. Elle ne transforme pas le résultat en ordre d’achat, en obligation de déploiement ou en modification automatique d’un service.

RFC 9281 répartit les rôles entre les groupes, l’IESG et les autres acteurs du processus. Cette architecture n’autorise pas un observateur externe à changer l’état du document. À l’inverse, RFC 3935 rappelle qu’une norme IETF explique comment faire lorsqu’on revendique la conformité ; l’IETF n’a pas pour fonction de contraindre universellement l’utilisation.

Il faut par conséquent enregistrer séparément l’effet interne et l’effet externe. La variance prouve qu’un obstacle procédural précis a été traité pour une spécification précise. Un déploiement demande ses propres preuves : décision d’opérateur, version implémentée, essais, calendrier, périmètre et possibilité de retour. Déduire le second du premier serait une forme de blanchiment de mandat.

Cette séparation rejoint le cadre de Heng Lu sur la spécification initiale minimale, la décision future localisée et l’adoption volontaire. Une décision commune doit rester bornée à l’autorité qui l’a prise ; les choix d’exploitation ultérieurs conservent leurs propres auteurs. Ce cadre éclaire ici le modèle de gouvernance sans remplacer les sources procédurales de l’IETF.

Sources