Résumé

  • Daté du 29 septembre, draft-gerke-publication-process-reform-09 est un Internet-Draft individuel, à l’état IESG I-D Exists. Il propose désormais de mettre à jour RFC 6359 en plus de RFC 7841, sous réserve d’approbation ; il ne modifie encore aucun de ces textes.
  • Le gel en deux temps figurait déjà dans la version 08. La nouveauté est que l’auteur rattache explicitement ses contrôles d’intégrité des états au suivi Datatracker décrit par RFC 6359, alors que ce dernier distingue la visibilité commune des sources d’état faisant autorité.

Entre les versions 08 et 09, une ligne de couverture change le périmètre du débat. La première visait RFC 7841, texte consacré aux flux de publication et aux mentions portées sur les RFC. La seconde ajoute RFC 6359. Ce texte plus ancien traite de la façon de suivre, dans Datatracker, les étapes prises en charge par l’IANA et le RFC Editor. La révision ne se borne donc plus à proposer des mentions et des jalons de publication : elle revendique aussi une place dans l’infrastructure qui rend ces jalons visibles.

Le changement se lit dans une nouvelle section 1.2. Son auteur présente les contraintes automatiques d’intégrité d’état et les limites de modification comme une extension du circuit de suivi décrit en 2011. Le résumé de la version 09 parle de jalons programmatiques communs aux flux de traitement centraux, actuels comme futurs. Ce sont des ambitions formulées dans un projet, pas des contrôles déjà exécutés par le service.

La comparaison exige de ne pas grossir la nouveauté. La version 08 contenait déjà le principe d’un gel technique puis éditorial, ainsi que les propositions de retrait des droits d’écriture après IESG OK et d’immuabilité progressive du côté de l’équipe de production des RFC. La version 09 élargit leur justification et leur portée alléguée. Elle transfère également le projet draft-ietf-procon-2026bis-11 des références informatives aux références normatives. Ce dernier reste lui-même un projet en dernière consultation de groupe de travail, pas une RFC publiée.

RFC 6359 offre un point de contrôle précis. Le texte recherchait une vue cohérente des étapes après approbation, mais précise qu’il ne définit pas les processus propres aux organisations concernées. Pour l’état de l’IANA après approbation, son système de suivi fait autorité ; pour l’état du RFC Editor, c’est toujours le système de ce dernier. Datatracker en reflète des informations. Un affichage fidèle et un droit transversal de refuser une modification ne sont pas la même responsabilité.

Cela ne condamne pas toute validation future dans Datatracker. Il faut cependant savoir qui décide qu’un verrou vaut pour un flux donné, qui distingue une correction technique d’un ajustement éditorial et quel registre tranche en cas d’exception. Une proposition individuelle ne constitue ni l’accord de chaque responsable de flux ni une preuve de déploiement. Le Datatracker indique toujours I-D Exists ; le statut Best Current Practice annoncé sur la couverture est une destination souhaitée, non un statut acquis.

Sources