Résumé

  • La révision 03 propose qu’un module YANG normatif reste en version préliminaire à l’approbation de l’IESG, puis soit édité sous contrôle, daté et versionné définitivement, validé de nouveau et publié presque simultanément dans le RFC et par l’IANA.
  • La suppression du suffixe préliminaire, un passage sans erreur dans pyang ou yanglint et l’égalité des octets sont des reçus distincts ; aucun ne certifie à lui seul le sens, le bon incrément Semver, le téléchargement, le chargement ou la compatibilité en exploitation.
  • Les modules publiés par l’IETF et les modules maintenus par l’IANA à partir de registres compagnons suivent deux procédures différentes qu’il ne faut pas confondre.

Le point de départ n’est pas un fichier défectueux, mais un fichier honnêtement provisoire. À l’étape hypothétique où l’IESG approuve un document, son module normatif peut encore porter une version majeure zéro ou un suffixe lié au numéro du draft. Ce marqueur réserve la possibilité que l’édition finale change les octets avant qu’une révision immuable soit publiée.

La fiche Datatracker vérifiée le 11 septembre 2026 ne dit pas que ce processus est déjà devenu norme. Elle décrit draft-ietf-netmod-iana-yang-guidance-03 comme Internet-Draft actif du groupe NETMOD, WG Document, I-D Exists, avec statut RFC visé Informational. Le texte de la révision 03 date du 6 juillet 2026 et expire le 7 janvier 2027. La mention « Last updated 2026-08-27 » correspond à des changements de métadonnées — AD responsable et statut visé — tandis que la dernière révision reste celle du 6 juillet. Ce n’est ni un RFC ni la preuve d’une mise en œuvre.

L’éditeur dispose d’une marge, pas d’une autorité sémantique illimitée

Le projet autorise le RFC Editor à clarifier une description sans en changer le sens, remplacer une référence de draft par le numéro RFC définitif, corriger une faute ou harmoniser la forme. Dès qu’une modification peut devenir substantielle, la responsabilité revient dans la boucle : coordination avec les auteurs, et consultation supplémentaire si la frontière entre changement éditorial, BC et NBC reste incertaine.

Avant publication, le module reçoit sa date de révision finale. Son indicateur de préversion disparaît et la version YANG Semver de sortie est fixée. Pour un module déjà publié, la comparaison avec la version précédente doit aussi déterminer si rev:non-backwards-compatible est nécessaire. Toute modification ultérieure impose de refaire ce contrôle. Le numéro final est donc une décision attribuable sur un jeu d’octets final, non une vérité produite automatiquement par le calendrier.

Un validateur ne voit pas l’intention de l’auteur

Après édition et formatage, la révision 03 recommande une nouvelle validation, normalement avec pyang et yanglint. Le répertoire de dépendances compte autant que le fichier examiné. Plusieurs modules destinés à paraître ensemble peuvent devoir être extraits et testés ensemble.

Le texte consacre aussi une section aux limites des outils. Une description réécrite peut conserver le sens ou le modifier ; le logiciel ne sait pas toujours trancher. Les comparateurs couvrent des violations connues sans garantir tous les cas possibles. Un bug peut produire un faux positif ou un faux négatif. Une ancienne version encore préliminaire peut empêcher la recommandation automatique d’une version de sortie. Un résultat surprenant appelle donc une revue, pas une confiance accrue dans l’automate.

Un rapport propre établit une proposition limitée : telle version de l’outil a accepté tels octets, avec telles options et telles dépendances. Il ne prouve ni que la sémantique est inchangée, ni que tous les consommateurs compileront le même schéma effectif.

L’attente de l’IANA ferme le risque de publication anticipée

Le mécanisme central consiste à retarder la publication IANA du module normatif jusqu’à la fin du travail éditorial. Une fois le module finalisé, le RFC et la copie de l’IANA paraîtraient à peu près en même temps, avec le même contenu et une référence correcte au RFC. L’opérateur peut alors comparer les objets et leurs empreintes au lieu de choisir entre deux éditions concurrentes.

Cette égalité ne franchit pas la frontière suivante. Elle ne dit pas quelle version se trouve dans un cache, ce qu’une URL « latest » a servi à un instant donné, quel paquet a résolu les dépendances, quel processus a chargé le module, quelles features et deviations ont formé le schéma effectif, ni si une instance ou une opération reste compatible.

Les articles BTW existants conservent leurs domaines : noms de fichiers et sélection du chargeur, classification des différences de schéma, branches de versions et résolution de packages. La singularité de ce draft réside dans la garde des octets entre l’édition finale et les deux surfaces de publication.

Le module dérivé d’un registre suit une autre causalité

La seconde partie traite des modules maintenus par l’IANA. Ils représentent souvent des énumérations ou identités issues d’un registre compagnon. Une nouvelle valeur est d’abord ajoutée au registre qui fait autorité ; l’IANA identifie ensuite le changement, le transpose dans le module, fixe une nouvelle révision et version, vérifie BC/NBC, valide puis publie des fichiers adressables par version et par date.

Ce reçu peut rattacher un changement de registre à une édition du module. Il ne prouve pas une fraîcheur continue, l’exhaustivité de la projection, la récupération par un client ou le chargement dans un équipement. La question de fraîcheur et d’autorité étudiée autour de RFC 9907 reste voisine, mais elle n’est pas la remise éditoriale de la section précédente.

Neuf reçus au lieu d’un voyant vert

Une clôture sérieuse sépare : le candidat préliminaire approuvé ; les changements du RFC Editor et les consultations ; le jugement final de version ; les entrées, dépendances et versions des validateurs ; les octets extraits du RFC ; les octets IANA et leur heure d’observation ; la récupération et le cache du client ; le chargement et le YANG Library de l’équipement ; enfin les effets sur datastore, protocole, trafic et service.

Running-Code Primacy de Heng Lu sert ici de méthode explicite, pas d’intention prêtée à l’IETF : la publication coordonne une cible, l’exécution décide de l’adoption. Minimum Initial Specification valorise justement un contrat commun étroit et vérifiable. Reality, Not Advocacy et Reality Layers interdisent de remplir les cases manquantes par une conclusion rassurante.

La réussite du projet serait donc modeste et importante : faire en sorte que deux éditeurs disent exactement la même chose, tout en laissant le réseau témoigner pour lui-même.

Sources

  1. Texte de la révision 03
  2. Fiche Datatracker
  3. Historique Datatracker
  4. RFC 9907
  5. RFC 9890
  6. RFC 7950
  7. YANG Module Versioning, révision 17
  8. YANG Semantic Versioning, révision 26
  9. YANG Schema Comparison, révision 09
  10. YANG module filename, révision 14
  11. Paramètres YANG de l’IANA
  12. Heng Lu — Running-Code Primacy
  13. Heng Lu — Minimum Initial Specification
  14. Heng Lu — Reality, Not Advocacy
  15. Heng Lu — Reality Layers