Résumé

  • L’IESG a annoncé le 18 août 2026 l’approbation de draft-ietf-netmod-yang-semver-28 comme Proposed Standard. Le texte ajoute aux modules YANG un identifiant de version sémantique et permet à YANG Library d’en publier une partie.
  • Cette information classe l’évolution d’un artefact selon son auteur. Elle ne démontre ni la cohérence de l’ensemble de modules du serveur, ni l’activation d’une fonctionnalité, ni l’absence d’une déviation, ni le comportement réel de la cible. Ces preuves doivent précéder toute autorisation de changement.

Un contrôle exact peut répondre à la mauvaise question

La scène d’ouverture est hypothétique. Elle ne décrit aucun incident connu. Elle illustre un glissement fréquent : transformer un renseignement sur la dépendance en verdict d’exploitation.

recommended-min-version indique la plus ancienne version compatible que le consommateur préférerait trouver. La comparaison porte sur les trois nombres. Elle ignore le suffixe de compatibilité ainsi que les métadonnées de préversion et de construction. Une version majeure supérieure satisfait donc le seuil ; une variante marquée _non_compatible peut également le franchir.

Le texte assume ce couplage lâche. Si aucun choix viable n’est trouvé, le compilateur devrait avertir puis poursuivre la résolution normale des imports YANG. Le champ guide la sélection ; il n’impose pas un verrou. Le danger naît lorsqu’une chaîne d’automatisation efface cette nuance et traite l’avertissement comme une approbation.

Une grammaire pour raconter la vie du module

Le document approuvé est encore un Internet-Draft dans la file du RFC Editor. Il provient du groupe NETMOD. Le message d’approbation fait état d’un consensus général, avec quelques réserves, et d’outils encore en développement.

L’extension ysv:version adopte la forme X.Y.Z_COMPAT, à laquelle peuvent s’ajouter des indications de préversion et de construction. En principe, une hausse majeure signale une rupture de compatibilité ascendante, une hausse mineure une addition compatible, et un correctif une modification éditoriale compatible.

Cette convention apporte deux gains. Elle rend explicite le jugement du mainteneur sur l’évolution et, avec le nom du module, permet d’identifier un contenu précis. Les dépendances deviennent plus lisibles qu’avec une simple date de révision. YANG Library peut en outre annoncer la version revendiquée par le serveur.

Ce sont des propriétés de provenance. Elles répondent à « quel artefact et quelle lignée ? », non à « que fera cet équipement avec cette configuration ? ».

La compatibilité reste une déclaration du mainteneur

Le mainteneur attribue le numéro. Les règles encadrent son choix, mais l’autorisent à effectuer un saut plus important que nécessaire ou à omettre des versions. Ce n’est donc ni un résultat de test produit par l’équipement, ni une mesure indépendante du changement.

Le projet le dit sans détour : le numéro ne garantit pas que la modification annoncée a effectivement eu lieu, ni qu’un consommateur donné en subira les effets. La comparaison de schémas doit établir les différences concrètes. Les tests d’instance et d’implémentation doivent établir l’impact concret.

Un module peut rester compatible pris isolément alors que l’ensemble effectif change. Un autre module peut l’augmenter ; une fonctionnalité optionnelle peut être désactivée ; une déviation peut supprimer ou resserrer un nœud. La version du premier module conserve son sens, mais le chemin attendu par le contrôleur disparaît.

Parler de compatibilité sans nommer son périmètre crée une fausse promesse. Ici, le périmètre est la relation entre deux états d’une lignée maintenue.

Le suffixe conserve la mémoire d’une rupture

Les modificateurs _compatible et _non_compatible servent à exprimer des branches intermédiaires limitées. Une fois _non_compatible introduit dans une même branche majeure et mineure, une version ultérieure de cette branche ne peut pas effacer cette marque ni redevenir simplement compatible.

Cette persistance empêche qu’une succession éditoriale fasse oublier une rupture antérieure. Elle impose aussi de conserver l’identifiant complet dans les journaux et les décisions. Réduire la valeur à trois entiers détruit une partie de l’information.

Or la recommandation minimale ne compare que ces entiers. C’est cohérent avec sa fonction de préférence, mais insuffisant pour décider l’admission. Si une organisation veut refuser certaines branches, elle doit formuler cette politique, vérifier l’artefact résolu et enregistrer le motif. Le champ ne prend pas cette décision à sa place.

Le serveur expose un assemblage, pas un module isolé

YANG Library décrit un ensemble : modules et révisions, modules importés seulement, sous-modules, fonctionnalités activées, déviations et emplacements. La version sémantique ajoute une pièce utile à cet inventaire. Elle ne le remplace pas.

Le projet précise d’ailleurs que la constitution d’un ensemble cohérent se trouve hors du périmètre de l’extension et renvoie notamment aux travaux sur les paquets YANG. Deux serveurs annonçant la même version d’un module peuvent donc présenter des schémas effectifs différents.

RFC 7950 explique comment imports, augmentations, fonctionnalités et déviations composent le modèle utilisable. RFC 8525 permet au client de découvrir l’inventaire de la cible. RFC 9907 encadre les étiquettes de révision. Chaque couche réduit l’ambiguïté, mais aucune n’exécute le changement sur l’équipement visé.

L’unité de contrôle pertinente est le schéma compilé pour cette cible, avec son logiciel et sa classe de configuration, pas le seul numéro affiché à côté d’un module.

L’admission doit relier quatre preuves

Avant d’autoriser une modification, la chaîne doit conserver l’artefact exact et son empreinte, l’instantané YANG Library complet, l’empreinte du schéma effectif après résolution, puis les résultats de comparaison, de validation des données et d’essais d’implémentation.

Les échecs ne sont pas interchangeables. Un minimum non satisfait relève de la sélection de dépendance. Un suffixe incompatible relève de la politique de lignée. Une fonctionnalité manquante ou une déviation contradictoire relève du schéma cible. Une régression observable relève de l’implémentation. Une autorisation absente relève de la gouvernance.

Les confondre sous « mauvaise version » rend les dérogations plus dangereuses. Les distinguer permet une réponse proportionnée : choisir un autre artefact, corriger l’assemblage, élargir les essais, limiter un canari ou demander au responsable du service.

Le numéro doit intervenir tôt pour réduire l’espace de recherche. Le dernier mot revient à la preuve obtenue sur la cible et à l’acteur responsable des conséquences.

Sources