Résumé

  • Dans le fonctionnement actuel de l’IETF, un Internet-Draft expire normalement 185 jours après son dépôt, sauf lorsqu’un état formel de traitement suspend cette échéance. Le libellé décrit le cycle de vie d’une version active; il ne désigne aucun organe qui aurait rejeté le texte.
  • Le Repository actif et l’Archive ne jouent pas le même rôle. Mise à jour, remplacement, publication en RFC et expiration font sortir une version du Repository, tandis que ses différentes versions restent en principe conservées dans l’Archive.
  • Les historiques officiels interdisent l’assimilation. draft-iab-protocol-maintenance-05 a expiré avant de reprendre son parcours et de devenir le RFC 9413. draft-ietf-netvc-testing a expiré plusieurs fois, mais sa clôture significative est un état IESG Dead, distinct et motivé.
  • Une diligence sérieuse exige un reçu d’état: nom et révision exacts, dates, chaîne d’archives et de remplacement, état du groupe et du flux, preuves d’adoption et de Last Call, décision explicite, dépendances techniques et responsable de la conclusion.

Le registre qui a transformé une date en sentence

Supposons qu’un acheteur étudie une extension de protocole. Un analyste ouvre le Datatracker, constate que la dernière version du draft est Expired, puis écrit « l’IETF a rejeté la proposition ». L’équipe produit supprime la fonction de sa feuille de route. Le rapport de sécurité reprend la même formule. Lorsqu’une nouvelle révision apparaît quelques mois plus tard, le registre bascule vers « travaux de nouveau approuvés ».

Les deux conclusions sont fabriquées. La première convertit une échéance automatique en jugement institutionnel; la seconde prend un nouveau fichier pour un signe d’approbation. Les observations de départ — expiration puis révision — sont exactes. Ce sont les deux décisions attribuées à l’IETF qui manquent de preuve.

Un rejet doit avoir un sujet. Le groupe de travail a-t-il refusé d’adopter le texte ? Son président a-t-il conclu à l’absence de rough consensus ? Un Area Director a-t-il écarté le parrainage ? L’IESG a-t-il clos une demande de publication ? L’auteur a-t-il simplement cessé de déposer des versions ? Un autre draft a-t-il remplacé celui-ci ? Ou les échanges ont-ils continué pendant que la version active franchissait une échéance automatique ?

Expired ne tranche aucune de ces hypothèses. Le mot atteste un événement de cycle de vie. Pour décrire une décision de gouvernance, il faut retrouver l’acte distinct qui dit qui a décidé quoi, sur quelle version, selon quelle compétence et pour quels motifs.

Repository, Archive et échéance de 185 jours

La page actuelle des ressources IETF pour les auteurs distingue le Repository des Internet-Drafts et leur Archive. Le Repository ne contient que les versions actives. Une version en sort lorsqu’elle est mise à jour, remplacée par un autre draft, publiée sous forme de RFC ou arrivée à expiration. L’Archive conserve, hors retraits exceptionnels, toutes les versions et leurs autres rendus.

La règle opérationnelle fixe normalement l’expiration à 185 jours après le dépôt. Certains états de traitement formel empêchent toutefois cette échéance: c’est notamment le cas d’un texte traité par l’IESG en vue d’une publication dans le flux IETF, ou examiné par l’Independent Series Editor pour le flux des soumissions indépendantes. Même le mécanisme automatique s’articule donc avec le dossier de procédure.

La conservation en Archive ne transforme pas le draft en publication d’archives. La même page rappelle que les Internet-Drafts restent des travaux en cours et ne doivent être cités qu’en cette qualité. L’Archive répond à la question « quel texte existait ? », pas à la question « quel texte l’IETF a-t-il approuvé ? ».

Le contraste historique est instructif. La section 2.2 du RFC 2026 présentait en 1996 le répertoire des drafts comme un moyen d’exposer un document évolutif à la revue informelle. Après plus de six mois sans modification ni recommandation de publication par l’IESG, le document était retiré; une nouvelle version relançait le délai. Le RFC précisait également qu’un Internet-Draft n’avait aucun statut formel et pouvait être modifié ou retiré à tout moment.

L’outillage a changé: la durée est désormais exprimée en 185 jours et l’Archive préserve l’historique. La frontière institutionnelle demeure. Un draft n’est pas un RFC, et l’expiration du Repository n’est pas la décision motivée d’une autorité.

Quatre états qu’un seul badge ne peut contenir

Une fiche fiable sépare au moins quatre plans.

Le premier est l’identité documentaire. draft-example-foo-04 n’est pas une simple idée baptisée « Foo ». C’est une version datée, un contenu précis et un ensemble de références. La révision 05 peut réparer une condition de sécurité, modifier le mécanisme ou réduire le périmètre. Sans suffixe de version, une analyse ne prouve même pas le texte qu’elle a évalué.

Le deuxième est le cycle de vie du dépôt. Active, updated, replaced, published et expired disent pourquoi une version reste ou cesse d’être la copie active. Ces indications facilitent la navigation. Elles ne constituent pas, seules, une mesure de qualité technique ou de consensus.

Le troisième est l’état de procédure. Une soumission individuelle, une candidature à l’adoption par un groupe, un document adopté, un texte en Working Group Last Call ou une demande de publication examinée par l’IESG n’occupent pas la même position. La section 7.2 du RFC 2418 décrit les drafts comme des documents en cours; la section 7.4 traite le Last Call du groupe comme un acte distinct; la section 7.5 sépare encore le rough consensus nécessaire à l’avancement et la saisine de l’IESG.

Le quatrième est la disposition. Un acteur compétent peut consigner une adoption, un remplacement, un retrait, un refus de parrainage, une approbation, une publication ou une clôture, parfois avec motifs et recours. C’est à ce niveau qu’un constat défavorable peut être établi. Il ne doit pas être déduit du calendrier du dépôt.

Ces plans évoluent séparément. Un document de groupe peut expirer alors que sa révision reste prévue. Un draft individuel peut être actif sans sponsor. Un texte déjà implémenté peut voir sa publication abandonnée. Une révision expirée peut être suivie par une autre sous le même nom. Aucun voyant unique ne décrit honnêtement toutes ces combinaisons.

Le draft qui a expiré avant de devenir le RFC 9413

L’historique officiel de Maintaining Robust Protocols suffit à réfuter l’équivalence entre expiration et rejet. La révision 05 a été déposée le 12 juillet 2021, puis déclarée expirée par le système le 13 janvier 2022. La révision 06 a suivi le 10 mai. Les versions 07 à 12 ont prolongé le travail. L’IAB a engagé une Community Review, puis une IAB Review, enregistré son consensus et son approbation, avant d’envoyer le texte au RFC Editor en février 2023.

Le document final est devenu le RFC 9413 en juin 2023. L’expiration de la version 05 est un fait historique à conserver. La décrire comme un rejet par l’IAB ou l’IETF serait pourtant fausse: l’horloge n’a ni empêché les révisions suivantes, ni décidé de leur issue.

Ce cas ne permet pas d’affirmer que les drafts expirés reviennent généralement. Il établit une proposition plus étroite: expiration et rejet ne sont pas logiquement identiques. Un modèle qui doit remplacer ultérieurement la valeur « rejeté » par « approuvé » détruit le déroulement qu’il prétend documenter.

Le bon registre garde chaque événement: sortie automatique de la version 05 le 13 janvier, arrivée de la version 06 le 10 mai, étapes de revue assorties de leurs acteurs, puis publication d’archives sous le numéro 9413. Chaque donnée conserve sa date et son auteur institutionnel.

Le draft dont la vraie clôture avait un motif

L’historique de Video Codec Testing and Quality Measurement montre l’autre versant. La version 05 a expiré en septembre 2017 et la 06 est arrivée le mois suivant. La 06 a expiré en mai 2018; la 07 a été déposée en juillet et placée en Last Call du groupe. En janvier 2019, cette version a expiré alors que l’état du groupe indiquait un consensus en attente de write-up. La version 08 est ensuite entrée dans le processus de publication et dans un IETF Last Call.

Le dossier défavorable pertinent est postérieur. Le 25 mars 2020, l’état IESG est passé à Dead. La note de l’Area Director explique qu’après plusieurs tentatives pour obtenir une réponse aux commentaires d’évaluation, le groupe NETVC ne disposait plus d’un élan suffisant pour achever le document. Une expiration automatique supplémentaire n’a été enregistrée qu’en août.

Cette fois, l’analyste dispose d’une clôture attribuable: une date, une surface de décision et un motif. Celui-ci porte sur l’absence de dynamique et sur des commentaires non résolus; il ne démontre pas que les méthodes d’essai étaient sans valeur. Le write-up du shepherd signalait au contraire leur usage par des implémenteurs d’AV1. Dépendance technique, disposition de publication et échéance du Repository restent trois faits différents.

Nommer la dernière expiration « rejet » ferait disparaître la meilleure preuve, c’est-à-dire le changement d’état IESG et sa justification. Qualifier les expirations précédentes de rejets serait incompatible avec la poursuite documentée du travail.

Une reprise n’est pas davantage une approbation

La discipline vaut dans les deux sens. Si l’expiration ne prouve pas le rejet, une nouvelle version ne prouve pas l’acceptation. Toute personne remplissant les conditions de dépôt peut soumettre un Internet-Draft. Une révision peut répondre à des remarques, rendre le texte de nouveau visible, rouvrir un débat ou simplement maintenir l’option de poursuivre.

Le nom du fichier ne remplace pas l’historique. Un préfixe draft-ietf-... reflète normalement une adoption par un groupe, mais ne démontre ni le rough consensus actuel sur chaque phrase, ni l’approbation de l’IESG. Le Last Call ouvre une revue déterminée; il n’est pas la publication finale.

Le code en fonctionnement n’attribue pas non plus un statut institutionnel. Il apporte une preuve essentielle sur l’interopérabilité, l’utilité et le coût de transition. La primauté du running code défendue par Lu Heng protège contre l’autorité purement documentaire. Mais un déploiement constate une réalité opérationnelle; il ne fabrique pas un procès-verbal de consensus. Les deux dossiers doivent être conservés séparément et se contrôler mutuellement.

Les adoptants externes doivent enfin assumer leur propre choix. Un acheteur peut raisonnablement fixer un contrat sur une révision de draft afin d’obtenir une capacité émergente avant publication d’un RFC. L’obligation provient alors du contrat. Elle doit nommer la version, le mécanisme d’acceptation des changements, les essais de compatibilité et la sortie possible.

Le projet de suppression de l’expiration reste un projet

Le draft individuel Removing Expiration Notices from Internet-Drafts soutient que l’expiration automatique a perdu sa fonction depuis que les versions sont archivées. Il observe que les drafts expirés continuent d’être cités et que certains systèmes changent seulement leur présentation. C’est un élément utile pour établir l’existence d’un débat parmi des entités expérimentés.

Sa propre dernière version a expiré. Cette ironie ne doit servir ni à ridiculiser l’argument, ni à lui conférer une autorité. Le texte n’a pas été adopté comme règle IETF. On peut discuter son raisonnement; sa présence ne suffit pas à écrire « l’IETF a décidé de supprimer l’expiration ».

Le principe général se retrouve ici à l’état pur: un draft peut contenir une analyse solide sans statut formel; un badge de procédure peut être exact sans juger le fond. Seul un acte traçable accompli par l’acteur compétent relie les deux.

Le reçu d’état du draft

Un inventaire de normes doit permettre à un lecteur absent de reconstruire la conclusion sans deviner la signification d’une couleur affichée un jour donné.

Champ Ce qu’il établit
Nom exact et révision Le texte évalué, plutôt qu’une idée mouvante
Empreinte du contenu La concordance entre les octets lus et la version conservée
Dates de dépôt et d’expiration L’événement d’horloge et la règle alors applicable
État du Repository Le caractère actif de la version et la cause de sa sortie
Adresse d’Archive Le lieu de conservation du texte et de ses rendus
Chaîne de révisions Les versions antérieures et postérieures sans les confondre
Relations de remplacement La succession éventuelle sous un autre nom de draft
Flux, sponsor et groupe L’institution qui, le cas échéant, porte l’étape suivante
État d’adoption L’acceptation comme travail du groupe et sa preuve
Consensus et Last Call La revue effectuée, sa version et les objections non résolues
Disposition IESG ou de flux La décision réelle, son acteur, sa date et ses motifs
Issue de publication Le numéro, le flux et la catégorie du RFC éventuel
Dépendance d’implémentation Le code, les tests et les déploiements encore concernés
Instrument externe Le contrat ou la politique ayant choisi une révision
Responsable et prochaine revue La personne chargée de corriger le registre

Ce reçu évite deux fautes symétriques. Transformer Active, adopted ou Last Call en « approuvé par l’IETF » gonfle l’autorité. Transformer Expired en « rejeté par l’IETF » invente une autorité négative. La première affirmation exige une preuve d’acte positif, la seconde une preuve de disposition défavorable. Une minuterie ne fournit ni l’une ni l’autre.

Sources

Conclusion

Expired est un avertissement utile. La version active a franchi une limite de fraîcheur et toute dépendance mérite un nouvel examen. Le mot ne dit pas pourquoi le travail s’est arrêté, si le fond a été jugé, ni même si l’institution compétente a pris une décision.

La règle pratique consiste à conserver deux reçus: celui de l’horloge pour l’expiration, celui de l’autorité pour la disposition. Si le travail a été clos, il faut nommer l’acteur, la procédure, la version, la date et les motifs. S’il reprend, il faut enregistrer la nouvelle révision sans inventer une approbation. Si un implémenteur ou un acheteur continue d’en dépendre, il doit assumer ce choix sous sa propre autorité. Le calendrier peut vieillir un document; il ne sait pas voter.