Résumé

  • Le RFC 10016 ajoute à NMDA le datastore <system>, en lecture seule, pour la configuration fournie par le système et non supprimable par un client. Celui-ci peut néanmoins référencer ces nœuds, remplacer certaines valeurs dans <running> ou ajouter des descendants configurables à une entrée créée par le système.
  • L’origine system décrit le fournisseur de la valeur, non son approbation, sa permanence ou son application. Supprimer un remplacement peut faire réapparaître la valeur système dans <intended> ; un changement de matériel, de licence, de fonction ou de logiciel peut aussi modifier le contenu de <system>.

L’ordre de changement ne contenait qu’une suppression. Une équipe retirait d’un équipement une valeur explicitement configurée, pensant revenir à l’absence de politique. Après la fusion, une autre valeur est pourtant apparue dans <intended> : celle que le système fournissait depuis le début et que le réglage supprimé avait masquée.

La transaction n’avait rien créé, mais elle avait changé le vainqueur. C’est précisément le type de réalité que le RFC 10016 permet de voir en introduisant le datastore conventionnel <system> dans la Network Management Datastore Architecture. L’accès est en lecture seule pour les clients NETCONF et RESTCONF ; les données demeurent un ingrédient du réglage effectif.

L’erreur de gouvernance consiste à faire du mode d’accès une propriété temporelle. « Lecture seule » répond à la question : qui peut écrire directement ici ? Il ne répond ni à « cette valeur changera-t-elle ? », ni à « qui l’a approuvée ? », ni à « a-t-elle atteint l’état opérationnel ? ». Trois attestations différentes se cachent derrière un seul badge dans trop d’outils de configuration.

Nommer une source auparavant diffuse

Le modèle NMDA du RFC 8342 sépare déjà la configuration destinée à être appliquée de l’état effectivement utilisé. Il reconnaît plusieurs origines, dont les sources conventionnelle, dynamique, apprise, système et par défaut. Le RFC 10016 donne à la source système un datastore explicite et une définition stricte : tout élément présent dans <system> est une configuration système, qu’il soit référencé ou appliqué ou non.

Cette configuration ne peut pas être supprimée par les clients. Des données fournies par un serveur mais effaçables par le client ne répondent donc pas à la définition. Un serveur compatible implémente l’identité ietf-system-datastore, dans un modèle fondé sur YANG tel que défini par le RFC 7950. Sa capacité peut être découverte grâce aux informations de YANG Library du RFC 8525.

La standardisation ne rend toutefois pas tous les nœuds permanents. Une configuration toujours présente est produite au démarrage sans dépendre d’une ressource physique particulière ; l’interface de bouclage sert d’exemple dans le RFC. Une configuration conditionnellement présente naît d’une carte, d’une ressource, d’une licence ou d’une fonction. Lorsque la condition cesse, le nœud système peut disparaître.

Le datastore <system> n’est pas persistant à travers un redémarrage. Le serveur le reconstruit selon les conditions du moment. Une capture d’hier n’atteste donc pas les intrants de demain, même si les chemins paraissent identiques. Une sauvegarde de <running> seule ne suffit pas davantage à reconstituer le prochain <intended>.

Un contenu protégé, une priorité modifiable

Un client ne peut pas éditer directement <system>, mais il peut créer dans <running> une configuration qui référence un nœud système. Lorsque le serveur l’autorise, une feuille correspondante de <running> remplace la valeur de <system>. Des descendants configurables peuvent aussi être ajoutés sous une entrée de liste créée par le système.

La règle de fusion a une conséquence nette : sur un même nœud, <running> l’emporte lors de la constitution de <intended>. Si les sources exigent des transformations — expansion d’un modèle ou retrait d’une configuration inactive, par exemple — elles doivent être transformées séparément avant la fusion. Comparer deux exports bruts ne permet donc pas de déterminer le résultat.

Prenons une valeur A fournie par le système. L’opérateur inscrit B dans <running> ; B devient effectif dans l’intention. Lorsqu’il supprime B, il ne supprime pas A, opération qui lui est interdite. A réintègre <intended> et peut ensuite être appliquée. Une interface qui décrit cela comme « effacer le réglage » escamote le choix réellement effectué.

Le mouvement inverse existe. Un nœud système conditionnel disparaît à la suite du retrait d’un composant ou d’une licence. Sa configuration liée peut subsister dans <running> et <intended>, mais ne plus apparaître dans <operational> faute de ressource. L’intention survit ; le monde auquel elle se rapportait a changé.

Une origine n’est pas une signature d’acceptation

Le mécanisme de métadonnées du RFC 7952 porte notamment les annotations d’origine. Le RFC 10016 précise qu’une configuration issue de <system> reçoit l’origine system, sauf si elle a été explicitement configurée ou remplacée dans <running>. Les éléments provenant de <running> suivent les règles d’origine de NMDA.

L’annotation répond utilement à « quelle source a fourni ce nœud ? ». Elle ne nomme pas la personne qui en a accepté l’effet. Le fournisseur peut être une image de plateforme, un mécanisme de licence, un gestionnaire de ressources ou un processus local. Aucun ne prouve qu’un humain a examiné la valeur dans son contexte actuel. Symétriquement, un contrôleur automatique peut être l’auteur matériel d’une valeur dans <running>.

Confondre origine et approbation produit deux raccourcis. Le premier qualifie de sûre une valeur parce qu’elle vient du système ; le second qualifie de délibéré tout remplacement parce qu’il vient de <running>. La provenance doit plutôt être reliée à l’autorité de changement, à l’examen de politique et au propriétaire du risque.

L’intention validée n’est toujours pas l’état appliqué

À chaque modification de <system>, le RFC 10016 impose au serveur de mettre à jour et de valider immédiatement <intended>. Il indique aussi que <running> devrait rester un arbre de configuration valide après un changement système, tout en laissant hors périmètre les mécanismes employés. Ces garanties concernent le traitement des données ; elles n’attestent pas une programmation réussie du matériel.

Le document ne modifie volontairement pas <operational>. Dans le cadre du RFC 8342, une ressource absente, un délai de propagation, un échec ou un état rémanent peuvent séparer l’intention de l’exploitation. La chaîne réelle est donc : transformation indépendante de <system> et <running>, fusion dans <intended>, puis application conditionnelle dans <operational>. Chaque transition mérite sa propre preuve.

Les changements peuvent être signalés au moyen des abonnements YANG et des notifications de mise à jour décrits par le RFC 8639 et le RFC 8641. Un événement émis dans le périmètre d’un abonnement est une observation utile. Il ne garantit pas que tous les consommateurs l’ont traité, ont recalculé leur politique et ont contrôlé le nouvel arbre opérationnel.

Enfin, <system> n’est pas <factory-default>. Le RFC 8808 définit un datastore de paramètres d’usine et une opération de réinitialisation. <system> décrit ce que le système fournit dans les conditions présentes. Une ressemblance entre certaines valeurs ne confond pas leurs rôles ni leur temporalité.

Le reçu d’origine et de priorité

Un reçu d’origine et de priorité rendrait chaque valeur importante justifiable. Il consignerait d’abord le chemin du nœud, l’empreinte de la valeur, son origine et sa condition de présence. La condition nommerait l’époque matérielle, logicielle, de licence, de fonction ou de démarrage afin qu’une valeur système ne soit jamais traitée comme intemporelle.

La partie suivante décrirait la mutabilité : remplacement autorisé ou non, nœud de <running> qui référence ou masque la source, descendants ajoutés, transformations appliquées séparément et vainqueur de la fusion vers <intended>. Avant d’autoriser la suppression d’un remplacement, le reçu montrerait la valeur de repli qui prendra sa place.

La partie activation comparerait <intended> à <operational>. Elle noterait l’heure, la présence de la ressource, les délais, les échecs, les états rémanents et l’observation exacte utilisée pour dire « en vigueur ». Une référence valide peut viser une ressource inactive ; un arbre d’intention valide peut encore décrire un composant absent.

La partie autorité distinguerait le fournisseur système, le client de configuration, l’approbateur opérationnel et le propriétaire du risque. Mise à niveau, changement de licence, insertion de matériel ou commit de politique seraient reliés à la décision qui accepte le résultat. Les secrets peuvent rester protégés ; des empreintes et références restreintes peuvent préserver l’audit.

Ce reçu est une proposition éditoriale de gouvernance de Daniel Kade, non une exigence ajoutée au RFC 10016. Il sert à ne plus confondre une source visible, une valeur gagnante, une décision acceptée et un résultat appliqué.

La sécurité commence par le droit de lire

La lecture seule n’est pas sans danger. Le RFC 10016 avertit que <system> peut révéler des identifiants matériels, des politiques de sécurité et des ressources critiques. L’accès aux nœuds sensibles doit être limité et les tentatives de lecture consignées. Le RFC 8341 fournit le modèle NACM pour encadrer les utilisateurs NETCONF et RESTCONF.

La voie de remplacement crée un risque distinct. Un attaquant ou un client défaillant peut écrire dans <running> une feuille qui masque une valeur système sensible, provoquant contournement de politique ou indisponibilité sans modifier <system>. Une surveillance limitée aux écritures sur ce dernier observerait précisément le chemin que le client ne peut pas emprunter.

La conclusion doit rester proportionnée. Le RFC 10016 rend la configuration système inspectable et exploitable de façon standard. Il ne transforme pas le choix du système en intention de l’opérateur, ne le fige pas pour toujours et ne prouve pas son application. La visibilité ouvre le contrôle ; la priorité et l’exploitation le terminent.

Sources