Résumé

  • RFC 10016 crée <system>, un datastore en lecture seule pour les clients de gestion, destiné à exposer la configuration fournie par l’équipement. Son contenu peut néanmoins changer avec le logiciel, les licences et les ressources physiques.
  • Une surcharge autorisée dans <running> prime sur la valeur système correspondante. Sa suppression peut faire réapparaître la valeur système dans <intended> ; à l’inverse, la disparition d’une ressource peut laisser une intention cliente sans effet dans <operational>.
  • La norme impose de transformer séparément les deux sources, de les fusionner puis de valider immédiatement la cible. Elle ne garantit ni l’application, ni une notification exhaustive, ni la méthode de sauvegarde de la validité de <running>.

Quatre états derrière un seul mot

Une carte d’interface est absente au démarrage. Le contrôleur possède encore l’adresse préparée pour cette carte. Son API de configuration renvoie un arbre cohérent. Pourtant, aucune interface correspondante ne fonctionne.

L’explication n’est pas un simple échec de synchronisation. Dans l’architecture mise à jour par RFC 10016, la configuration conditionnelle de la carte n’existe plus dans <system>. Les valeurs du contrôleur peuvent rester dans <running>, puis dans la cible fusionnée <intended>. Faute de ressource, elles ne sont pas appliquées et n’apparaissent pas dans <operational>.

Chaque datastore formule donc une affirmation distincte. <system> dit ce que l’équipement fournit. <running> dit ce qu’un client a explicitement demandé. <intended> dit ce que le serveur, après transformation, fusion et validation, cherche à appliquer. <operational> dit ce qui est réellement en usage. Une plate-forme qui n’en conserve qu’un seul ne décrit pas l’autorité ; elle ne garde qu’un point de vue.

La lecture seule ne fige pas la source

Les opérations NETCONF ou RESTCONF visant à modifier directement <system> doivent être refusées. Cette interdiction protège la provenance. Elle ne transforme pas le contenu en constante.

Le système peut créer des éléments toujours présents, comme une boucle locale, et des éléments conditionnels. L’insertion d’une carte, l’activation d’une licence ou d’une fonction peut ajouter des nœuds. Le retrait de la carte, l’expiration de la licence ou une mise à niveau logicielle peut les modifier ou les faire disparaître.

Le datastore <system> ne persiste pas au redémarrage. Il est reconstitué à partir du système qui démarre. Cela le distingue de <factory-default> défini par RFC 8808, dont le contenu doit survivre aux redémarrages et peut initialiser les datastores en lecture-écriture lors d’une remise à l’état d’usine. L’un expose une offre système courante ; l’autre fournit une origine persistante de réinitialisation.

Lecture seule ne signifie pas davantage « sans influence cliente ». Lorsqu’un serveur l’autorise, un client peut écrire dans <running> un nœud correspondant à une valeur de <system>. Il ne modifie pas la source système, mais sa valeur obtient la priorité au moment de la fusion.

Une suppression qui donne effet à une autre valeur

Cette priorité produit un geste opérationnel contre-intuitif. Tant qu’une surcharge existe dans <running>, elle masque la valeur de même niveau dans <system>, y compris lorsque le système change cette valeur. Si le client retire plus tard sa surcharge, la valeur système réapparaît dans <intended> et peut entrer en service si son application réussit.

La suppression n’est donc pas une absence. Elle transfère le résultat visible vers une autre source. Une demande de changement qui n’affiche que la ligne supprimée ne montre pas la valeur qu’elle va libérer. Avant de retirer une surcharge, il faut capturer le <system> courant et tester la valeur qui gagnera la fusion.

Le retrait d’une ressource inverse la difficulté. La source système s’efface, mais l’intention cliente peut rester. Une carte réinsérée ou une licence renouvelée rend cette intention dormante à nouveau applicable. La bonne discipline consiste à conserver le pré-provisionnement tout en le qualifiant d’inappliqué, puis à le relire avant le retour de la condition physique ou commerciale.

L’ordre de calcul est une règle commune

RFC 10016 exige que les transformations — expansion de modèles, retrait de nœuds inactifs ou mécanismes équivalents — soient exécutées séparément sur <system> et <running>. La fusion vient ensuite. Un nœud correspondant de <running> prime si la surcharge est permise. Toute modification de <system> doit entraîner immédiatement la mise à jour et la validation de <intended>.

La continuité adjacente est moins déterminée. La norme indique que <running> devrait rester un arbre valide lorsque la configuration système change, mais laisse les mécanismes hors de son périmètre. Lorsqu’une mise à niveau supprime une cible référencée, le texte ne choisit pas entre blocage, réparation, isolement ou retour logiciel. Ce choix appartient à l’implémentation et à l’opérateur qui en supporte le coût.

RFC 8342 rappelle aussi que <intended> représente une tentative d’application. Des ressources manquantes ou des délais locaux peuvent empêcher le passage vers <operational>. Un commit accepté et un arbre valide ne remplacent pas la preuve du comportement effectif.

Une meilleure visibilité, un accès plus sensible

RFC 10016 donne aux clients un moyen standard de lire une configuration système qui existait déjà. Les anciens clients NMDA peuvent continuer à utiliser les datastores historiques, mais ils doivent évoluer pour comprendre cette nouvelle provenance et ses règles de priorité.

Le contenu visible peut inclure des identifiants matériels, des politiques de sécurité et des ressources critiques. Le RFC impose de contrôler la lecture des sous-arbres sensibles et recommande fortement de journaliser les tentatives. Le modèle NACM de RFC 8341 fournit les instruments ; les identités et autorisations effectivement déployées restent une décision locale.

La surcharge elle-même est une surface de sécurité. Une valeur erronée ou hostile dans <running> peut masquer un nœud sensible et provoquer un contournement de politique ou une perte de disponibilité. Déclarer la source « en lecture seule » ne suffit pas lorsque le résultat fusionné est modifiable par priorité.

Les changements peuvent être transmis par les abonnements de RFC 8639 et YANG-Push de RFC 8641. Mais tous les objets ne prennent pas forcément en charge le mode on-change. Le récepteur doit connaître la couverture, détecter les pertes et effectuer une resynchronisation complète. Le silence d’un flux n’est pas une preuve d’immobilité.

La doctrine de primauté du code en exécution de Heng Lu s’applique ici de manière mesurable : le modèle exprime une règle, le contrôleur exprime une intention, et l’équipement exécuté détermine l’état opérationnel. Son cadre de spécification initiale minimale et de décision future localisée permet de fixer une fusion déterministe sans retirer aux exploitants la responsabilité des permissions, du séquencement et du retour arrière.