Résumé

  • draft-ietf-netmod-yang-packages-09 compose récursivement des paquets, modules implémentés ou importés, fonctions, déviations, exclusions et montages pour obtenir un schéma résolu.
  • Une définition valide, marquée complète et liée à YANG Library établit une déclaration structurée. Elle n’atteste ni les octets récupérés, ni le chargement par un processus, ni l’identité des schémas aux deux extrémités, ni la sécurité d’un déploiement mixte.

Le cas trompeur n’est pas celui d’un paquet manifestement cassé. C’est celui qui passe tous les contrôles faciles. Son nom et sa version sont uniques, le JSON est valide, le graphe d’inclusion est sans boucle, chaque URI répond et le résolveur fournit un ensemble cohérent. Rien, dans cette réussite, ne dit encore si le contrôleur a utilisé une copie ancienne en cache ou si le serveur a réellement chargé les mêmes octets.

La révision 09, datée du 6 juillet 2026, est un Internet-Draft actif du groupe NETMOD, destiné à la voie Standards Track et expirant le 7 janvier 2027. Elle reste un travail en cours. Son apport est néanmoins précis : remplacer une collection implicite de fichiers par une structure hiérarchique, versionnée et calculable.

La résolution transforme la hiérarchie

Le conteneur includes ajoute des paquets, des modules implémentés, des modules réservés à l’import et des fonctions obligatoires. excludes retire ce qui a été hérité. depends-on indique un contexte utile à un paquet incomplet sans incorporer ce contexte dans son propre schéma. Un montage peut accumuler les paquets hérités ou, avec inherit-packages=false, les écarter et redéfinir entièrement le schéma monté.

L’algorithme commence par résoudre chaque paquet inclus, puis fusionne les résultats avec les entrées locales. Les modules implémentés entrent en conflit jusqu’à ce qu’une seule version subsiste. Une entrée locale peut remplacer le choix hérité ; les exclusions interviennent ensuite. Les fonctions sont réunies puis ajoutées ou retirées. Exclure un module retire aussi ses fonctions. Les listes d’emplacements conservent la première occurrence et ajoutent les nouvelles URI dans l’ordre d’inclusion.

Cette mécanique est déterministe, mais chaque étape possède un effet que le mot « paquet » masque. Un seul booléen de montage peut remplacer un sous-schéma. Une exclusion locale peut enlever une capacité héritée. Une URI placée en tête peut orienter toutes les récupérations suivantes.

Le gagnant automatique n’est pas nécessairement le gagnant attendu

En cas de versions concurrentes d’un module implémenté, deux labels YANG Semver sont comparés selon les seuls nombres majeur, mineur et correctif ; les modificateurs de compatibilité, les préversions et les métadonnées de construction ne départagent pas les candidats. Un label Semver est préféré à un label qui ne l’est pas ; sinon la date de révision la plus récente l’emporte. Une entrée locale permet un remplacement explicite.

Le calcul peut donc être conforme à la spécification tout en contredisant l’hypothèse d’un client ou l’intention d’un changement. La trace utile doit conserver tous les candidats, la règle appliquée, le gagnant, les remplacements, les exclusions et les avertissements. « Résolu » n’est pas une explication.

La comparaison de schémas traitée dans un autre article peut qualifier l’écart. Elle ne prouve pas que les fichiers comparés sont ceux que le processus a chargés, et elle n’exécute aucun client.

Le drapeau complete ferme les imports, pas la chaîne de confiance

Un paquet est référentiellement complet lorsque tous les imports de tous les modules, y compris ceux hérités, se résolvent vers des versions présentes dans la définition. Les paquets incomplets, par exemple un correctif, peuvent utiliser depends-on pour indiquer le contexte attendu.

Cette propriété ne garantit pas l’authenticité d’un miroir, l’absence de dérive sous un même nom/version, ni la présence effective de chaque sous-module. Les sous-modules sont listés surtout pour leurs emplacements ; la résolution décide au niveau du module et peut supposer l’équivalence lorsque les versions sont à égalité. Il faut donc conserver les octets et les empreintes du contenu réellement obtenu.

La règle d’unicité mondiale du couple nom/version relève elle aussi de la gouvernance. Elle ne remplace pas une empreinte cryptographique. Lorsque deux URI divergent, une attente d’équivalence ne permet pas de désigner la copie correcte.

Connu du serveur n’est pas actif dans un datastore

La liste supérieure des paquets d’un serveur est un catalogue. Elle peut contenir plusieurs versions non implémentées et inactives. Le lien opérationnel se trouve dans l’extension de YANG Library : des couples nom/version et des fonctions supplémentaires sont associés au schéma d’un datastore donné.

S’ils sont fournis, ces paquets doivent produire un schéma complet qui correspond exactement au module-set de YANG Library. C’est une obligation de cohérence forte, mais les deux représentations restent déclarées par le serveur. Le client doit les comparer et dater l’observation. Le content-id, généré par le serveur, signale une modification locale ; ce n’est pas une empreinte universelle.

Les fichiers .ypkg rendent la définition transportable sous forme de données d’instance JSON. Le client peut utiliser la copie du serveur, une URI annoncée ou un cache portant le même nom et la même version. La validation du fichier établit son format, pas son auteur, sa fraîcheur, le chemin récursif retenu ni son activation. RFC 9195 rappelle en outre que les données d’instance ne constituent pas un protocole de manipulation de la configuration ou de l’état en service.

Une conformité de schéma ne promet pas un résultat réseau

La conformité de paquet compare l’implémentation au schéma résolu. Un constructeur peut publier un paquet propre au serveur qui inclut puis affine un paquet standard : versions différentes, déviations, modules ou fonctions exclus. Cette transparence est utile. Elle ne garantit pas qu’un contrôleur accepte le résultat.

Il faut séparer les reçus : autorité du paquet ; URI et empreinte des octets ; validation structurelle ; trace récursive ; choix des conflits ; clôture des imports et sous-modules ; schéma final ; liaison YANG Library par datastore ; chargement du processus ; ensembles client et serveur ; tests de configuration, état, RPC, notifications et contrôle d’accès ; ordre de déploiement ; retour arrière ; état observé ; résultat de service.

Un reçu répond à une question. Il ne doit pas emprunter la conclusion du suivant.

Sources principales

Le dossier primaire réunit la révision 09 et son historique Datatracker, ainsi que RFC 7950, RFC 8525, RFC 9195, RFC 8528, RFC 8342, YANG Module Versioning révision 17, YANG Semantic Versioning révision 28 et le compte rendu NETMOD de l’IETF 122 : https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-packages-09 ; https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-packages/ ; https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-packages/history/ ; https://www.rfc-editor.org/rfc/rfc7950.html ; https://www.rfc-editor.org/rfc/rfc8525.html ; https://www.rfc-editor.org/rfc/rfc9195.html ; https://www.rfc-editor.org/rfc/rfc8528.html ; https://www.rfc-editor.org/rfc/rfc8342.html ; https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-17 ; https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-semver-28 ; https://datatracker.ietf.org/doc/minutes-122-netmod-202503190600/00/.