Résumé

  • Le BBF a indiqué que WT-477i2 dépendait des modules du modèle BGP de l’IETF et a demandé une information sur une date cible. Cette demande décrit une dépendance externe ; elle ne crée pas un engagement de publication de l’IETF.
  • La réponse d’IDR du 1er août place le projet en Working Group Last Call et distingue encore l’examen par l’Area Director, l’IETF Last Call, l’examen de l’IESG et l’entrée dans la file du RFC Editor.
  • Le 21 août, le responsable de l’area Routing a écrit que la WGLC restait ouverte et que le silence ne valait pas indication de maturité pour publication.
  • Le Datatracker présente la version 21 comme Internet-Draft, avec l’état WG « Waiting for Implementation », l’état IESG « I-D Exists » et aucune date de téléconférence. Ce ne sont pas des champs de RFC publié.
  • Le contrôle utile est un reçu de dépendance reliant versions, examens et décisions sans convertir une demande de calendrier en résultat de norme.

Une liaison de dépendance ne choisit pas l’issue de la norme

La liaison de suivi du BBF du 17 décembre 2025 nomme ce qui est attendu. Elle explique que les modèles YANG de WT-477i2 dépendent du module ietf-bgp et des modules associés figurant alors dans draft-ietf-idr-bgp-model-18. Elle joint une version de travail du document BBF, indique que WT-477i2 approchait de sa finalisation et demande une indication de date de publication cible pour le modèle IETF.

Cette formulation fournit une preuve utile : un acteur externe identifie son propre document, une dépendance précise et la question qu’il pose. Elle ne fournit pas une date acceptée par IDR, un numéro de RFC réservé, une décision de l’IESG ni la preuve que WT-477i2 ou le modèle a été déployé. Une dépendance technique peut être réelle sans que le demandeur acquière le pouvoir de clore les examens du document dont il dépend.

Cette distinction protège les deux institutions. Le BBF peut rendre visible l’effet d’un état amont sur son calendrier. L’IETF peut recevoir des retours techniques là où son processus les prévoit. Aucun de ces faits ne transforme la coordination entre organismes en mandat d’un organisme sur l’autre. RFC 2418 traite d’ailleurs la prise en compte du travail pertinent effectué ailleurs et de l’adéquation d’une liaison ; il n’efface pas les tâches et décisions propres au groupe de travail.

IDR a décrit un parcours, pas une échéance

La réponse d’IDR au BBF est claire sur l’état alors connu. Le projet draft-ietf-idr-bgp-model était en Working Group Last Call. Après cette étape devaient encore venir un examen par l’Area Director, un IETF-wide Last Call et un examen complet de l’IESG avant l’entrée dans la file de publication du RFC Editor. Le texte recommande aussi aux personnes intéressées au BBF de participer à la liste IDR, de présenter des retours techniques et d’exprimer explicitement leur soutien.

Cette dernière invitation mérite une lecture exacte. Participer apporte un élément au dossier ; participer ne produit pas par lui-même le consensus, l’approbation de l’IESG ou une publication. Inversement, l’existence d’une dépendance BBF ne rend pas cette participation suspecte. Elle rend l’intérêt technique identifiable. Le test reste celui de l’examen attribuable du document.

Le message du 21 août ajoute l’élément qu’un calendrier ne peut pas fournir. L’Area Director responsable explique que la version 21 a été déposée, que la WGLC reste ouverte et qu’il recherchera des soutiens positifs ainsi que des examens achevés pour apprécier le consensus ; le silence ne signifie pas que le document est prêt. Le message note aussi que les trois présidents d’IDR sont coauteurs, raison pour laquelle l’Area Director appellera le consensus pour cette étape et qu’un shepherd identifié contribue à l’examen.

Le point n’est pas de dramatiser une procédure normale. C’est de préserver le sens des preuves. Une révision déposée, une discussion de liste, une absence de réponse et une décision sur le consensus ne sont pas des synonymes. Le dossier public dit quelle preuve est encore recherchée et quelle fonction l’évalue.

Le statut d’Internet-Draft n’est pas un raccourci vers le RFC

Le Datatracker de la version 21 la décrit comme Internet-Draft, daté du 14 août 2026. Il affiche « Waiting for Implementation » côté groupe de travail, « I-D Exists » côté IESG et aucune date de téléconférence. Le texte du projet rappelle que les Internet-Drafts sont des documents de travail, peuvent être remplacés ou rendus obsolètes et ne devraient être cités que comme tels.

Ces champs ne dévalorisent pas le modèle. Ils empêchent d’attribuer au document une maturité qu’il n’a pas encore enregistrée. La charte d’IDR donne au groupe la priorité de développer et maintenir BGP comme protocole d’interconnexion pour IPv4 et IPv6. Elle identifie un mandat de travail, non la date à laquelle tout projet individuel devient une norme. RFC 2026 définit les niveaux de maturité et exige une action spécifique de l’IESG pour atteindre le niveau Proposed Standard ; l’expérience ultérieure peut encore conduire à modifier ou retirer le document.

Le dossier doit donc conserver cinq pièces séparées : la dépendance déclarée par BBF ; l’état WGLC ; les examens et l’appréciation du consensus ; les états ultérieurs de l’IETF et de l’IESG ; enfin une éventuelle file du RFC Editor et un RFC final. Une pièce ne peut pas remplir les colonnes d’une autre. La liaison ne prouve pas un engagement de l’IETF. Une WGLC en cours ne prouve pas un refus ou une date. Un RFC final ne prouvera pas à lui seul le déploiement d’un profil BBF.

Le reçu nécessaire est bref et versionné

Un reçu public suffisant relierait : la version de WT-477i2 ; la version exacte du projet IETF citée ; la date et le contenu de la demande ; l’ouverture, la prolongation ou la clôture de la WGLC ; le résultat de consensus lorsqu’il existe ; les étapes de l’Area Director, de l’IETF et de l’IESG ; l’entrée éventuelle dans la file du RFC Editor ; et le RFC, s’il paraît. Chaque ligne devrait dire explicitement ce qu’elle ne démontre pas.

Le besoin de cette discipline est particulièrement net ici, car les sources ne montrent ni essai d’interopérabilité, ni adoption par un opérateur, ni soutien de fournisseur, ni date de sortie de WT-477i2. Elles décrivent un état documentaire. Leur faire dire davantage rendrait la dépendance moins lisible, non plus utile.

Sources