Résumé

  • L’annotation concerne une configuration fournie par le système que le client ne peut pas modifier dans les datastores en lecture-écriture ; le serveur conserve la faculté de la faire évoluer.
  • Une valeur peut être explicite, héritée d’un ancêtre ou issue de la valeur par défaut, ce qui rend un booléen isolé insuffisant pour l’audit.
  • Une preuve temporelle locale doit enregistrer l’instantané, le chemin, l’héritage, l’autorité serveur et le résultat d’une tentative d’écriture.

L’immuabilité dépend du point de vue

Dans le langage courant, une donnée immuable évoque un objet figé : une archive scellée ou un condensat qui ne varie plus. draft-ietf-netmod-immutable-flag-14 emploie le terme selon un axe différent. Une instance annotée est une configuration système que le serveur refuse de voir remplacée par une autre valeur dans un datastore en lecture-écriture, ou retirée de la configuration intended par un client.

Cette précision répond à un vrai problème de modélisation. Une donnée peut devoir rester config true afin que ses descendants soient configurables, que des contraintes YANG la référencent ou qu’une entrée système indispensable cohabite avec des entrées créées par l’utilisateur. Une simple description en prose n’est guère exploitable par une automatisation. L’annotation rend le comportement existant découvrable par machine.

Le projet souligne pourtant qu’il est descriptif et non prescriptif. Il indique aussi que la configuration système immuable ne peut être créée, mise à jour et supprimée que par le serveur. Ainsi, « immuable » répond à la question de savoir si le client peut agir par cette interface. Il ne répond pas à la question de savoir si le serveur fournira la même valeur demain.

Une observation vraie à midi peut donc être suivie d’une autre valeur après un redémarrage, un remplacement matériel ou une nouvelle politique serveur. L’observation de midi n’était pas erronée ; elle n’était simplement pas un historique.

L’annotation n’est visible qu’à la demande

Le client doit demander with-immutability lorsqu’il lit le datastore system, intended ou operational. Le même paramètre visant un autre datastore doit produire une erreur. Avec NETCONF, la présence du module ietf-immutable-annotation dans la bibliothèque YANG permet de découvrir la capacité. Avec RESTCONF, un identifiant de capacité spécifique joue ce rôle.

Ces étapes composent une chaîne de preuve : le serveur annonçait-il la capacité, quel datastore et quel sous-arbre ont été demandés, à quel instant, et quelle réponse le principal autorisé a-t-il reçue ? Une capture ultérieure qui ne montre qu’une valeur vraie ne permet pas de reconstruire cette chaîne.

La coexistence avec les anciens équipements renforce l’ambiguïté. Un ancien client ne demande pas l’annotation et ne la voit pas. Un client récent face à un ancien serveur peut recevoir une erreur ou voir le paramètre ignoré. L’absence peut aussi venir de l’héritage, d’une valeur par défaut, de la suppression d’une annotation redondante ou des droits de lecture. Sans trace de capacité et de requête, toutes ces causes prennent la même apparence.

Une annotation absente peut se résoudre à vrai

Le mécanisme économise de la bande passante en propageant l’état dans l’arbre. Un enfant non annoté hérite de son parent ; au sommet, l’absence vaut faux. Un descendant peut réinitialiser l’état et modifier ce qui s’applique à son propre sous-arbre. Le nombre de changements d’état à travers l’arbre n’est pas limité.

Il ne suffit donc pas d’enregistrer un chemin et le résultat vrai ou faux. Il faut dire si le résultat était explicite, hérité ou calculé par défaut, et garder le chemin de l’ancêtre ou de la réinitialisation qui l’a déterminé. Sinon, deux valeurs vraies de provenance différente deviennent indiscernables et l’impact d’une modification du parent ne peut pas être simulé.

Les listes illustrent une seconde finesse. Les annotations portent sur des instances. Deux entrées de la même liste peuvent avoir des états différents. En raison des règles de RFC 7952, une liste entière ne reçoit pas directement l’annotation comme une seule entité ; son comportement global peut venir du parent, tandis qu’une entrée précise réinitialise l’héritage. Ajout, retrait, modification et réordonnancement ne sont pas toujours gouvernés de la même manière.

Un reçu d’observation devrait donc garder le type du nœud, le chemin d’instance, la révision du schéma, l’annotation explicite, le résultat résolu et sa source d’héritage. Cette résolution est un calcul ; ses entrées méritent d’être auditables.

Une écriture identique ne transfère pas l’autorité

Le client peut inscrire dans running la même valeur que celle fournie par le système, puis retirer cette inscription. La configuration intended ne change pas pour autant. L’opération déplace la visibilité dans le datastore en lecture-écriture, pas la maîtrise de la valeur système.

Un journal qui dit seulement « création par le client » risque alors de lui attribuer une origine qu’il n’a pas. Inversement, une configuration système immuable peut être absente de running tant qu’elle n’y a pas été répétée explicitement. Limiter un inventaire à running peut donc masquer la valeur qui contraint réellement l’appareil.

La provenance temporelle doit relier, sans les confondre, l’événement du client et celui du serveur. Le serveur peut parfois expliquer que la valeur vient d’une découverte matérielle, d’un profil de démarrage ou d’une règle fournisseur. L’annotation standard ne transporte pas ces détails. S’ils ne sont pas disponibles, la bonne réponse est « source serveur inconnue », non une provenance imaginée.

L’accès est jugé avant l’immuabilité

Lorsque NACM est actif, le serveur traite la décision de contrôle d’accès avant de tester l’immuabilité. Une personne non autorisée reçoit un refus d’accès, même si la cible aurait ensuite été jugée immuable. Cet ordre évite de divulguer inutilement une propriété de configuration.

Il empêche aussi une lecture naïve des statistiques. Toute écriture en échec n’est pas une confirmation de la politique d’immuabilité. Le reçu doit conserver le principal authentifié, l’opération, le chemin, la décision NACM, le résultat du contrôle d’immuabilité et l’étiquette d’erreur effectivement renvoyée.

Le projet reconnaît que la connaissance des parties fixes d’une configuration pourrait aider un attaquant. L’annotation n’est visible qu’à ceux qui peuvent déjà lire le nœud. Exporter ces données dans un entrepôt d’observabilité sans conserver la portée d’autorisation peut élargir leur diffusion au-delà de l’intention du serveur.

Ajouter un reçu temporel, pas des champs au standard

Le booléen standard doit rester étroit. Un reçu d’exploitation peut l’accompagner. Il identifie le serveur ou l’élément logique, la version logicielle, le datastore, le module YANG, la découverte de capacité et le protocole. Il contient le sous-arbre, le chemin, la valeur de configuration, l’état immuable résolu et son origine explicite ou héritée. Il date la réponse et ajoute, quand la plate-forme en fournit un, l’identifiant ou le condensat de l’instantané.

Viennent ensuite les faits locaux prouvables : source de la configuration système, autorité de décision, dernier changement serveur et motif. Les champs inconnus restent inconnus. Pour une écriture tentée, le reçu joint le rôle, l’intention, le résultat NACM, le résultat d’immuabilité et l’erreur.

Enfin, il fixe une date de revue. Cette échéance évite de transformer « observé immuable » en « garanti permanent ». Une nouvelle valeur serveur produit un nouveau reçu sans réécrire l’ancien. La succession montre le changement et préserve ce que le client savait alors.

Il ne s’agit pas de gonfler l’annotation YANG avec une histoire locale. Mélanger identités, workflow et historique dans un booléen nuirait à l’interopérabilité. La recommandation concerne l’architecture de preuve de l’exploitant : utiliser le standard pour la frontière commune, puis joindre les faits que son système sait réellement observer.

Mesurer le chemin complet d’adoption

À la date de recherche, la révision 14 avait été approuvée par l’IESG et se trouvait dans la file du RFC Editor, tout en restant un Internet-Draft actif. La validation YANG affichait zéro erreur et zéro avertissement. Ces étapes ne prouvent pas un déploiement généralisé.

Le parc restera nécessairement mixte. Certains serveurs annonceront la capacité ; certains clients la demanderont. D’autres continueront sans annotation. Un client récent peut rencontrer un serveur qui ignore ou rejette le paramètre. Compter toute annotation absente comme un nœud modifiable confond l’adoption, l’héritage et la politique.

La bonne unité de suivi est le parcours terminé : capacité découverte, requête valide, réponse reçue, état résolu et éventuelle écriture classée après le contrôle d’accès. Là où le parcours s’arrête se trouve la prochaine décision d’exploitation.

Sources