Résumé

  • RFC 10035 ajoute à YANG Library une liste augmented-by en lecture seule indiquant quels modules ajoutent directement des nœuds à un autre module du même module-set.
  • Cette visibilité ne constitue ni une fermeture transitive, ni une preuve de fraîcheur, ni un verdict de compatibilité, ni une autorisation de changer un schéma actif.

C dépend de l’arbre d’A sans modifier A directement

L’exemple à trois modules donne sa portée exacte. A définit un conteneur. B lui ajoute un second conteneur. C ajoute une feuille au conteneur appartenant à B. La réponse associe donc B à A et C à B.

Même si le XPath de C commence dans l’arbre enraciné chez A, le parent immédiat de sa cible appartient à B. C ne figure pas dans la liste directe d’A. Une application qui veut la chaîne A→B→C ou l’effet sur un chemin précis doit effectuer elle-même le parcours.

Cette précision empêche de fondre plusieurs relations sous un vague « dépend de ». YANG distingue import, include, augment et deviation. Réutiliser une définition, inclure un sous-module, insérer des nœuds ou modifier les propriétés prises en charge ne produit pas le même risque lors d’une mise à jour.

Le serveur rend une arête inverse observable. Il ne devient pas le propriétaire de toute analyse en aval.

La publication complète RFC 8525

RFC 10035 est un document Standards Track publié en août 2026. Le module ietf-yang-library-augmentedby porte la révision du 26 août 2026 ; l’IANA a enregistré son nom, son espace XML et le préfixe yanglib-aug.

RFC 8525 permet déjà de découvrir datastores, ensembles de modules, modules implémentés ou seulement importés, fonctions et deviations. Une deviation constitue une dépendance inverse parce qu’un module externe change le comportement pris en charge par un module de base.

L’augment manquait à cette représentation. Un connecteur devait télécharger puis analyser les modèles ensemble pour découvrir quel module ajoutait les nœuds. Cette opération est raisonnable pour certains clients de configuration, mais impose un moteur complet à un catalogue ou à un parseur de télémétrie.

Le nouveau modèle ajoute la liste dans l’arbre NMDA et dans l’ancien modules-state, conservé pour compatibilité avec RFC 7895. Il facilite la collecte sans prétendre que les deux architectures sont identiques.

Le module-set fixe la portée de l’affirmation

Chaque valeur est une leafref vers un nom de module du même module-set. Le module de base et celui qui l’augmente doivent appartenir à cet ensemble. Une entrée import-only ne peut pas être présentée comme modification active, et une référence ne doit pas revenir vers elle-même, directement ou indirectement.

Ces règles établissent une cohérence structurelle. Elles ne prouvent pas que le client a interrogé le bon ensemble. Un serveur peut décrire plusieurs datastores et schémas ; une activation logicielle ou l’arrivée d’un module change le contenu.

RFC 10035 précise que les dépendances inverses augmentent la taille de l’instance et que la bibliothèque devrait être mise à jour lors de l’intégration de nouveaux modules. L’évidence doit donc conserver l’équipement, l’identité authentifiée, le datastore, le schéma, le module-set, le content identity, les révisions et l’heure.

Une arête correcte sans ces coordonnées peut être ancienne ou appartenir à un autre périmètre.

L’inventaire ne décide pas de la compatibilité

L’entrée B sous A affirme que B ajoute des nœuds dans le schéma actuellement exposé. Elle ne dit pas qu’un client comprend ces nœuds, qu’une application peut les ignorer ou qu’une nouvelle révision gardera leur sens.

Un catalogue peut charger les modèles pertinents ; un parseur peut repérer les champs ajoutés ; un banc d’essai peut étendre sa couverture. Il faut encore examiner révisions, features, deviations, imports et target paths, puis savoir si les données sont présentes et utilisées par un processus métier.

La suppression révèle le piège. Le fait qu’A cite B avertit d’un impact ; il n’autorise pas à décharger B. C peut dépendre de B, des configurations peuvent contenir ses nœuds et des abonnements les consommer. La décision exige la fermeture construite à partir du schéma réellement exécuté.

Une donnée en lecture seule peut rester sensible

Le nouveau module ne définit aucun nœud configurable. La requête ne change donc pas directement l’appareil. Elle peut néanmoins révéler la composition de sa surface de gestion : extensions fournisseur, fonctions activées et emplacement probable de données supplémentaires.

Le RFC exige des protocoles de gestion sécurisés, une authentification mutuelle et un contrôle comme NACM. L’authentification désigne le serveur ; l’autorisation borne la vue du lecteur. Aucune des deux ne garantit qu’un autre utilisateur, datastore ou instant possède la même visibilité.

Une automatisation doit conserver le périmètre d’accès. La différence entre un collecteur privilégié et un collecteur restreint peut être une politique, pas la disparition réelle d’un module.

Les implémentations établissent la faisabilité

Le writeup de l’IESG mentionne quatre implémentations et une validation lors d’un hackathon IETF. C’est une preuve de réalisation, pas l’inventaire des versions présentes sur tous les équipements ni la garantie d’une mise à jour atomique.

Un essai opérationnel active un augment connu, vérifie la présence des deux modules dans le même ensemble, l’arête attendue et le changement de content identity. Un cas à deux sauts doit produire A←B et B←C sans aplatir C sous A.

Les essais négatifs couvrent import-only, cycle, différence d’accès et cache ancien. Ce n’est qu’après ces observations que la preuve d’implémentation peut soutenir une décision de changement.

Trois autorités, trois dossiers

Le propriétaire du serveur répond de la composition qu’il publie. Le client répond du graphe qu’il calcule. Le propriétaire du service répond de l’exécution, de l’interruption et du retour arrière.

RFC 10035 améliore le passage entre eux en évitant de reconstruire chaque arête élémentaire à partir des sources. Mais le serveur ne connaît pas tous les usages métier ; un graphe générique ne connaît pas la fenêtre autorisée ; le registre IANA ne sait pas si l’appareil a rafraîchi sa bibliothèque.

Conservez l’enchaînement : endpoint authentifié, datastore et schéma, content identity, révisions et rôles, arêtes directes, fermeture calculée, chemins et consommateurs, changement candidat, validation, retour arrière, configuration et résultat observés.

Sources