Résumé

  • Le serveur définissait les schema-sets sélectionnables, leur valeur par défaut et les combinaisons admises pendant des sessions concurrentes.
  • Une sélection réussie ne prouve ni l’équivalence des vues, ni le droit d’écrire, l’isolement transactionnel, la modification du datastore, l’état opérationnel ou le résultat métier.

Deux clients peuvent recevoir deux réponses correctes du même équipement sans poser la même question. Dans la révision 00 de YANG Schema Selection, le contexte d’interprétation était choisi au démarrage d’une session NETCONF ou dans le chemin d’une requête RESTCONF. Le schema-set associait des datastores à des unions de packages YANG compatibles, avec révisions, fonctionnalités et déviations.

Le serveur gardait la main. Il pouvait publier plusieurs vues, exiger leur configuration préalable, n’en autoriser qu’une globalement, ou déclarer les paires utilisables simultanément. Pour NETCONF, le premier élément commun entre les listes ordonnées du client et du serveur devenait immuable pendant la session. Pour RESTCONF, une racine /schema/<nom> portait la sélection. L’absence de choix explicite ramenait au défaut.

Ce reçu reste étroit. Une vue pouvait présenter running en lecture seule alors que ce datastore est normalement inscriptible. Quand l’écriture était visible, RFC 8341 devait encore autoriser l’identité et les nœuds. RFC 6241 devait traiter l’opération. Il fallait ensuite établir l’avant/après du datastore, l’isolement face aux concurrents et le rollback. RFC 8342 sépare encore l’état intended de l’état operational ; ni l’un ni l’autre ne prouve le transfert de paquets ou l’effet commercial.

RFC 8525 permet de conserver la bibliothèque YANG, les module-sets, révisions, features et deviations liés à la vue. Sans cet instantané, le nom choisi flotte. Même avec lui, deux clients peuvent appliquer des hypothèses différentes aux mêmes données. La chaîne probante doit donc nommer le serveur, l’heure, la vue, sa fermeture de packages, la bibliothèque, l’identité, la décision NACM, la transaction, les écritures concurrentes, les empreintes du datastore, l’état opérationnel et les mesures de service.

La qualification historique est essentielle. La révision 00 date du 17 mars 2020 et devait expirer le 18 septembre 2020. Datatracker l’affiche aujourd’hui comme Expired Internet-Draft, Expired & archived, WG Document et IESG Expired, avec un Intended RFC status vide. La mention Standards Track de l’en-tête n’est pas une approbation. Le relevé de validation, six erreurs et aucun avertissement, décrit un outil et une fermeture de dépendances de l’époque, non l’échec nécessaire du mécanisme.

Sources : projet, statut, historique, RFC 6241, RFC 8040, RFC 8341, RFC 8342, RFC 8525 et RFC 8526. Cadre analytique : spécification initiale minimale, couches de réalité et primauté du code exécuté. Archives des dépendances et suites : YANG 1.1, packages révision 03, versionnement des modules révision 01, exigences révision 02, versionnement sémantique révision 01, format d’instance révision 08, puis les fiches Datatracker actuelles des packages, du versionnement des modules, des exigences et du versionnement sémantique.