Résumé

  • Publiée le 17 août 2026, la révision -04 de draft-ietf-procon-2418bis indique pour la première fois dans ce projet qu’un groupe de travail peut ramener une Internet-Draft à un état non adopté, par exemple faute d’intérêt suffisant.
  • Ce texte demeure une WG Document dont l’état IESG est I-D Exists. Il ne remplace pas encore la BCP 25. Sa portée actuelle est celle d’une proposition de gouvernance, non d’une règle approuvée.
  • L’adoption confie un support de travail et son contrôle des modifications au groupe ; elle n’approuve pas chaque phrase et ne promet pas la publication d’un RFC. La réversion doit donc être lue comme une fin de garde collective, pas comme une condamnation automatique de la solution.
  • Un reçu de sortie doit conserver l’appel à adoption, la dernière révision détenue par le groupe, les motifs, l’appréciation du consensus, l’état obtenu, le transfert de contrôle et les éventuels successeurs. Expiration, abandon, mise en attente, non-adoption et retrait opérationnel ne sont pas des synonymes.

La phrase qui ouvre la porte de sortie

Le passage décisif tient dans le paragraphe 8.2 de la révision -04. Le groupe peut adopter formellement une Internet-Draft pour en faire la base d’un de ses chantiers. Cette adoption ne signifie pas que le contenu fait déjà consensus. Les éditeurs consignent ensuite le résultat des délibérations. Puis vient la nouveauté : le groupe peut aussi replacer la draft dans un état non adopté, notamment lorsque l’intérêt s’amenuise.

La révision -03 séparait déjà adoption et accord sur l’intégralité du texte. Elle ne formulait toutefois pas cette possibilité de retour. Le journal de -04 mentionne explicitement une nouvelle modification du texte relatif à l’adoption. La différence est donc vérifiable entre deux versions successives ; elle ne dépend pas d’une interprétation d’un compte rendu.

La formule reste volontairement peu prescriptive. Elle ne fixe ni délai de notification, ni quorum, ni critère quantifié de « baisse d’intérêt ». Elle ne dit pas non plus quel libellé exact le Datatracker devrait afficher dans tous les cas. C’est une limite réelle du texte actuel. Mais elle corrige déjà une asymétrie : une institution qui sait prendre un document sous sa garde doit aussi savoir constater publiquement qu’elle ne le porte plus.

Cette information intéresse davantage que les seuls secrétaires de séance. Une équipe produit peut choisir ses prototypes en fonction d’un statut de groupe de travail. Un autre document peut citer la draft. Un fournisseur peut utiliser le préfixe draft-ietf comme signal de trajectoire. Lorsque la garde cesse, chacun doit pouvoir distinguer la fin de l’investissement collectif, le jugement technique porté sur les idées et la situation des implémentations existantes.

Un projet en cours, pas une nouvelle règle

Le registre du groupe PROCON date draft-ietf-procon-2418bis-04 du 17 août 2026 et le classe comme WG Document. Sa fiche Datatracker vise le statut Best Current Practice et annonce que le futur texte, s’il est approuvé, rendrait obsolètes RFC 2418 et RFC 3934 tout en mettant à jour plusieurs RFC ultérieurs.

Au 27 août, la situation était plus précoce : état IESG I-D Exists, aucun document shepherd, aucun Area Director responsable et aucune date de téléconférence. La draft devait expirer le 18 février 2027 en l’absence de mise à jour ou d’avancement. Le projet voisin 2026bis était en Working Group Last Call ; 2418bis ne l’était pas. La proximité visuelle des deux lignes ne crée aucune décision commune.

La charte PROCON autorise bien le groupe à consolider les textes de procédure et à envisager des changements non éditoriaux aux lignes directrices d’adoption. Elle établit la compétence du groupe à discuter cette phrase, pas l’acceptation de celle-ci.

La référence publiée reste donc RFC 2418, au sein de la BCP 25, tant que la procédure applicable n’a pas produit un successeur. Un inventaire sérieux affichera simultanément la règle en vigueur et le texte de remplacement proposé. Il évitera aussi bien de présenter -04 comme une note sans contexte que de l’annoncer comme une politique acquise.

Adopter, c’est confier la garde, pas certifier la vérité

RFC 7221 décrit les pratiques courantes de traitement des Internet-Drafts. Au moment de l’adoption, les détenteurs initiaux sont avertis que le contrôle des modifications passe à l’IETF. Les présidents vérifient les déclarations de droits, recherchent un rough consensus, choisissent les éditeurs, font publier la version draft-ietf et préservent le lien avec le document remplacé.

Le choix porte sur une base de travail acceptable. RFC 7221 insiste sur deux formules : l’adoption est initiale, non finale ; c’est une adoption, non une approbation. Le texte n’a pas à proposer déjà une solution complète et sa prise en charge ne garantit aucun RFC. Une fois adopté, il appartient au groupe, qui peut le modifier dans les limites de sa charte et des procédures IETF. Sauf accord explicite, le groupe n’endosse pas automatiquement chaque élément du contenu reçu.

Le transfert a donc un double sens. Les auteurs initiaux perdent le droit de présenter leurs choix futurs comme ceux du groupe. En contrepartie, le groupe assume un devoir de tenue du dossier : décisions, révisions et objections doivent rester attribuables. Les éditeurs écrivent au service du consensus ; ils ne produisent pas seuls ce consensus.

Parler d’« homologation » fausse ce mécanisme. Le mot suggère une note technique définitive. L’adoption ressemble plutôt à l’inscription d’une affaire à l’ordre du jour collectif, avec des ressources, une identité documentaire et un contrôle de version. La réversion agit sur cette relation de garde. Elle ne remonte pas le temps pour transformer toute l’histoire technique en échec.

L’ancien modèle d’états connaissait déjà les chemins latéraux

La réversibilité ne surgit pas de nulle part. RFC 6174 décrit une machine d’états pour les documents de groupe de travail. Un appel à adoption signifie qu’une draft est examinée mais pas encore choisie. Si elle ne l’est pas, elle revient à l’absence d’état propre à un flux, tandis que l’historique conserve la trace de l’appel. Adopted by a WG couvre l’intervalle avant la publication de la version draft-ietf, puis WG Document signale un texte adopté et activement développé.

Le modèle distingue aussi deux arrêts. Parked WG Document désigne un travail bloqué par l’absence d’un éditeur, l’attente d’une revue ou une autre dépendance. Une annotation peut indiquer la condition de reprise. Dead WG Document signifie que le travail a été abandonné, sans rendre toute résurrection impossible. Un document non expiré peut même changer de groupe avec les accords requis. RFC 6174 précise enfin que l’absence d’une flèche dessinée entre deux états n’interdit pas un mouvement approprié.

Ces mots répondent à des questions différentes. Un document « parked » reste sous garde mais en pause. Un document « dead » a été abandonné dans ce groupe. Un document « non adopté » n’est plus la base d’un chantier du groupe ; son nouveau détenteur et sa nouvelle trajectoire doivent être indiqués. Un document « expiré » a atteint une échéance de dépôt, ce qui ne constitue pas à lui seul une décision collective.

Le raccord exact entre la future phrase de 2418bis et tous les états du Datatracker n’est pas encore défini. Il faudra le surveiller au lieu de supposer une équivalence. RFC 7221 donne toutefois une conséquence importante : un groupe n’est pas obligé de conserver une draft adoptée. S’il l’abandonne, le travail peut être poursuivi comme soumission individuelle ou indépendante, sous réserve des droits applicables. La sortie du groupe n’est donc pas nécessairement la disparition du texte.

« Non adopté » n’est pas un verdict

Une baisse d’intérêt peut cacher plusieurs causes. Le problème a perdu son urgence ; aucun éditeur n’est disponible ; une proposition concurrente a absorbé la partie utile ; une dépendance manque ; les implémentations ont bifurqué ; des objections techniques demeurent ; ou les contributeurs ont simplement d’autres priorités. Toutes ces causes peuvent conduire à retirer un chantier, mais elles ne produisent pas le même jugement.

RFC 7282 rappelle que le rough consensus ne se réduit pas au nombre de voix. Les raisons, les objections et la réponse qui leur est apportée comptent. La sortie mérite la même qualité de dossier. Un décompte de messages n’établit pas à lui seul l’intérêt ; une annonce des présidents ne suffit pas si elle ne montre ni la question posée ni les considérations retenues.

Le statut documentaire ne commande pas davantage le réseau. Un logiciel peut encore mettre en œuvre une draft délaissée ; une expérience peut continuer ; un autre organisme peut reprendre une idée. À l’inverse, une WG Document active peut ne compter aucun déploiement de production. Le statut indique qui travaille sur le texte et au nom de quelle autorité. Les mesures d’usage indiquent ce que font réellement les opérateurs.

La grille de Heng Lu sur la spécification initiale minimale, la décision future localisée et l’adoption volontaire aide à garder cette séparation. Un artefact de coordination borne une décision commune ; il ne crée pas par sa seule existence une obligation universelle d’implémenter. Cette doctrine sert ici de cadre éditorial, non de preuve de procédure IETF.

La formulation publique la plus sûre reste donc factuelle : à telle date, le groupe a replacé telle révision dans un état non adopté, pour les motifs consignés. Le rejet technique, le retrait d’un RFC ou l’arrêt d’un service doivent chacun être démontrés séparément.

Ce qu’une sortie propre doit conserver

Le premier élément est l’identité. Il faut relier la soumission individuelle, sa version draft-ietf, les révisions pertinentes et leurs empreintes. L’appel à adoption et l’annonce du consensus forment le point de départ. Sans eux, deux familles de noms peuvent paraître étrangères ou, au contraire, être confondues.

Vient ensuite la décision de sortie : auteur de la proposition, période de discussion, arguments favorables et défavorables, objections non résolues, appréciation des présidents. « Intérêt en baisse » doit renvoyer à des observations adaptées au cas — recherche infructueuse d’éditeur, appels à revue sans réponse, travail de remplacement — et non fonctionner comme une formule autojustificative.

L’état d’arrivée doit être nommé sans ambiguïté : hors flux, en attente, abandonné, remplacé, transféré, expiré ou poursuivi individuellement. Il faut aussi dater la fin du contrôle des modifications par le groupe. Quelle est la dernière révision dont les éditeurs peuvent dire qu’elle reflète le groupe ? Qui contrôle les versions suivantes ?

Enfin, le dossier technique ne doit pas disparaître avec le chantier. Questions ouvertes, analyses utiles, rapports d’implémentation et objections peuvent servir à un successeur. Le groupe peut mettre fin à son investissement futur sans effacer ce qui a déjà été appris.

Le reçu de réversion

Un reçu compact réunira : les noms, révisions et empreintes de la chaîne ; l’appel et la décision d’adoption ; la dernière version sous contrôle du groupe ; la proposition de réversion et les échanges ; l’appréciation datée du consensus ; l’état final exact ; la fin de l’autorité éditoriale du groupe ; les liens de remplacement, transfert ou poursuite ; les questions techniques préservées ; les dépendances documentaires et implémentations connues ; les effets éventuels sur charte et jalons ; enfin, une phrase explicite sur ce qui n’est pas décidé.

Conserver l’entrée sans la sortie donne à un texte inactif une autorité périmée. Effacer l’entrée lors de la sortie réécrit l’histoire. Le reçu maintient la mémoire tout en rendant la garde réversible.

Sources