Résumé

  • L’IESG a annoncé le 18 août 2026 l’approbation de draft-ietf-netmod-yang-module-versioning-17 comme Proposed Standard. Le texte autorise une évolution incompatible documentée, propose recommended-min-date pour les imports et expose le traitement des nœuds dépréciés ou obsolètes.
  • Son exemple de branches montre la limite : la révision du 1er mai satisfait un minimum fixé au 1er avril tout en pouvant ne pas contenir l’apport de la branche du 1er avril. La date ordonne les artefacts ; elle ne prouve pas leur ascendance ni leur adéquation à une cible.

Le seuil a laissé passer la branche sœur

L’ouverture est une construction analytique tirée de l’exemple du projet, non un incident réel. Après une révision commune du 1er février, une branche passe par le 1er mars vers le 1er mai ; l’autre passe par le 1er avril vers le 1er juin.

Une dépendance qui exige l’ajout du 1er avril peut recommander cette date minimale. Selon la règle, toutes les dates égales ou postérieures conviennent : le 1er mai franchit donc le seuil, alors qu’il n’est pas descendant du 1er avril.

Le document en tire lui-même la conclusion : recommended-min-date convient mal à un historique ramifié et sert surtout dans un développement chronologique linéaire. « Plus tard » est une relation d’ordre ; « issu de » est une relation de graphe.

L’approbation rend les ruptures visibles

La version 17 de “Updated YANG Module Revision Handling” est un produit NETMOD. Elle attend encore le RFC Editor et demeure un Internet-Draft. L’annonce précise que l’état des implémentations est inconnu.

Les règles de RFC 7950 imposaient une stricte compatibilité ascendante. Le nouveau texte reconnaît des exceptions utiles, par exemple pour corriger un modèle afin qu’il reflète le serveur, retirer un nœud obsolète après transition ou restructurer un contenu instable.

Ces changements restent découragés. Toute révision incompatible avec son parent doit porter rev:non-backwards-compatible. Le signal transforme une rupture silencieuse en élément examinable. Il qualifie cependant une arête entre parent et enfant, pas toutes les relations possibles dans l’arbre.

L’identité immuable ne suffit pas à reconstruire la famille

Le nom du module et sa date identifient une définition précise et immuable dans l’historique. Cette propriété est forte pour l’identité, mais pas pour la filiation. Le texte dit explicitement que date et identifiant de version ne suffisent pas à déterminer l’ascendance ; il faut consulter l’historique.

Deux branches peuvent même recevoir une modification identique et produire des contenus égaux dont seul l’historique diffère. La ressemblance du corps ne prouve donc pas davantage le chemin suivi.

Les sous-modules ajoutent une autre frontière. Sans revision-date exact dans include, le module principal ne détermine pas la révision du sous-module. YANG Library ou un inventaire de paquet doit alors compléter la preuve.

Le minimum évite volontairement un verrou strict

recommended-min-date est un sous-énoncé d’import. Zéro ou un peut apparaître par import. L’ajouter, le modifier ou le supprimer est classé compatible. Un analyseur qui l’ignore continue selon la résolution ordinaire de RFC 7950.

Le projet le préfère à une date d’import exacte lorsque seule une borne est utile, parce qu’un verrou exact empêche de profiter de révisions ultérieures compatibles. Le compromis est raisonnable : moins de blocage, mais une vérification d’adéquation séparée.

La borne ne demande pas si l’artefact descend de la révision voulue, conserve le nœud, a intégré une modification de branche sœur ou expose le même défaut. L’automatisation peut s’en servir pour trouver des candidats, puis prouver ascendance et schéma effectif.

L’historique est une preuve opérationnelle

Les mainteneurs peuvent retirer certaines entrées anciennes, notamment pour réduire un long historique. Ils ne peuvent pas retirer l’entrée la plus récente et doivent préserver l’exactitude des marqueurs incompatibles entre les entrées restantes.

Le texte déconseille cette réduction parce qu’elle peut masquer le moment où une rupture a été introduite. Son exemple interdit de supprimer une entrée si cela ferait croire qu’une révision ultérieure est compatible avec des ancêtres qu’une arête cachée avait séparés.

La politique de conservation n’est donc pas de la simple documentation. Si l’organisation autorise selon la filiation, elle doit conserver les arêtes qui prouvent cette filiation, avec empreintes d’artefacts, inventaires et journaux de changement lorsque l’historique publié est raccourci.

Les nœuds dépréciés restent propres à la cible

Le nouveau module ietf-yang-library-status ajoute deprecated-nodes-implemented et obsolete-nodes-absent. À vrai, le premier indique que les nœuds dépréciés sont implémentés comme les nœuds courants, sauf déviation explicite. À vrai, le second indique l’absence de tout nœud obsolète.

Les deux valeurs par défaut sont fausses, ce qui signifie que le comportement est indéterminé. Le projet recommande de publier vrai pour les deux. Sinon, le client ne doit pas s’appuyer uniquement sur les marqueurs de rupture.

Une bonne transition passe de courant à déprécié, puis à obsolète. Les clients doivent préparer la sortie d’un nœud déprécié et cesser d’utiliser un nœud obsolète. La date de la révision n’établit pas à elle seule le stade réellement exposé par le serveur.

L’admission associe graphe, schéma et code

Le contrôleur doit conserver la capacité demandée et la révision qui l’a introduite, l’artefact choisi et son empreinte, le chemin des parents, les ruptures, les sous-modules, l’instantané YANG Library, les fonctions, déviations et déclarations de statut.

Il compile ensuite le schéma effectif, compare avant et après, valide des données représentatives et teste le logiciel serveur avec le client réel. Une incompatibilité peut élargir une plage au-delà des hypothèses du client, modifier une valeur par défaut ou imposer une révision des règles NACM.

Une mauvaise branche est une erreur de filiation. Un nœud au statut ambigu est une lacune de découverte. Une différence d’arbre est une erreur de schéma. Une conséquence en exécution est une erreur d’implémentation. L’absence d’accord est une erreur de gouvernance.

La date reste utile pour ouvrir la liste des candidats. Elle ne doit pas fermer la décision de production.

Sources