Résumé

  • La révision 14 définit l’annotation YANG immutable, fournie par le serveur, et le paramètre facultatif with-immutability. Elle décrit un comportement existant au lieu de l’imposer.
  • La valeur true concerne une instance et peut être héritée, supprimée de la réponse ou réinitialisée par un descendant. Une photographie aplatie de l’arbre peut donc fausser la portée de la restriction.
  • Un refus invalid-value documente une requête donnée. La permanence, l’égalité entre protocoles et utilisateurs, l’alignement des datastores, l’état réellement appliqué et la reprise exigent d’autres observations.

Une console de gestion peut présenter une histoire très convaincante en deux lignes : le serveur renvoie immutable=true, puis refuse une modification avec invalid-value. La première ligne semble annoncer une règle ; la seconde paraît l’avoir testée. L’ensemble mérite d’être conservé. Il ne mérite pas encore le mot « toujours ».

Le titre du projet révision 14 est YANG Metadata Annotation for Immutable Flag. Son choix décisif est de qualifier le drapeau de descriptif. Le serveur rend visible un traitement qu’il applique déjà à certaines configurations fournies par le système. L’annotation n’est ni un ordre adressé à l’implémentation ni un verrou ajouté par le client.

Le Datatracker identifie le document du 2 juillet 2026 comme Internet-Draft NETMOD actif, destiné au Standards Track. La file éditoriale, les revues et une validation YANG appartiennent au parcours du texte. Elles n’attestent aucun équipement, aucun déploiement et aucun résultat d’exploitation.

Une réponse ne vaut que par sa requête

Le serveur ne joint pas spontanément ces métadonnées. En NETCONF, le client ajoute with-immutability à <get-data> ; en RESTCONF, il utilise un paramètre de requête sans valeur. Le mécanisme ne s’applique qu’aux datastores en lecture seule <system>, <intended> et <operational>. Sur une autre cible, le projet prévoit unknown-element. Une valeur inattendue dans le paramètre RESTCONF doit produire HTTP 400 avec invalid-value.

La découverte de capacité est encore un autre reçu. NETCONF s’appuie sur YANG Library pour annoncer le module ietf-immutable-annotation. RESTCONF publie une URI de capacité. Ces annonces rendent une interrogation bien formée possible ; elles ne démontrent pas que le serveur marque toutes les instances pertinentes, applique correctement l’héritage ou refuse chaque chemin d’écriture.

Avec un serveur ancien, le paramètre inconnu peut être rejeté ou ignoré. Une réponse sans annotation reste donc ambiguë si l’on a perdu l’annonce de capacité, le datastore choisi ou les octets de la requête. L’absence visible n’est pas une preuve générale de mutabilité.

L’arbre compte davantage que le badge

L’annotation appartient à une instance de nœud. Deux entrées d’une même liste peuvent avoir des valeurs différentes. Un enfant sans annotation hérite de son parent ; un nœud supérieur non annoté vaut false par défaut. Un descendant peut réinitialiser l’état, puis un autre descendant le changer de nouveau. Le projet ne limite pas le nombre de transitions dans l’arbre.

Cette règle rend les extraits dangereux. Une feuille marquée comme immuable peut l’être par héritage, et le parent fait partie de la preuve. À l’inverse, un parent immuable ne suffit pas si l’enfant porte explicitement false. RFC 7952 limite aussi les annotations aux entrées d’une liste ou d’une leaf-list ; l’immutabilité d’une collection entière vient de son parent.

Les conséquences varient. Une liste entièrement immuable n’accepte ni ajout, ni suppression, ni réordonnancement par l’utilisateur. Une seule entrée immuable protège cette entrée et, par défaut, ses descendants, sans condamner ses voisines. Un client peut recopier dans running la même valeur fournie par le serveur puis retirer cette copie ; l’intention fusionnée ne change pas pour autant.

Enfin, le serveur doit ignorer toute annotation immutable envoyée par un client. La métadonnée est une déclaration du serveur. Une signature du message client garantit au mieux l’origine des octets ; elle n’autorise pas le client à fabriquer une propriété immuable.

Le code d’erreur a un périmètre

Les exemples NETCONF et RESTCONF du projet renvoient invalid-value, un chemin précis et un message expliquant que la cible est marquée immutable. Ce dossier est bien plus utile qu’un voyant vert : il rattache le jugement à une identité, une opération, une valeur proposée, une cible et un instant.

Mais le serveur peut prendre une décision antérieure. Si NACM refuse l’accès, le contrôle d’immutabilité n’est effectué qu’après ; l’utilisateur reçoit access-denied. Ce refus ne confirme ni n’infirme la propriété de la cible. Les écarts entre utilisateurs doivent donc être expliqués par l’ordre des contrôles, pas automatiquement attribués à une politique contradictoire.

Un seul chemin de gestion ne représente pas davantage toutes les voies. Un échec NETCONF ne teste pas RESTCONF, la console locale, un outil constructeur, le démarrage, une mise à niveau ou un processus interne au serveur. La phrase du projet selon laquelle l’immutabilité est indépendante du protocole et de l’utilisateur constitue une exigence à vérifier dans une implémentation, non un résultat déjà observé.

Le serveur garde le droit de changer

Le terme peut tromper parce qu’il semble parler du temps. Le mécanisme parle surtout de l’autorité : le client ne peut pas substituer une valeur différente, tandis que le serveur crée, met à jour ou retire sa propre configuration. Un changement de logiciel, de matériel, de licence, de fonctionnalité ou de ressource peut modifier ce que le serveur fournit.

L’immutabilité peut exister sans datastore <system>, et toute configuration système n’est pas immuable. C’est pourquoi l’article ne confond pas le mécanisme avec le modèle général de fusion des configurations. Il suffit ici de constater que la visibilité dans running et l’autorité sur la valeur ne coïncident pas nécessairement.

RFC 8342 distingue l’intention et l’état opérationnel. Une lecture synchronisée montrant la même valeur dans system, intended et operational est une bonne photographie. Elle ne prouve pas la photographie suivante, la présence durable des ressources, l’application effective après mise à niveau, le passage des paquets ou la qualité du service.

Huit reçus au lieu d’une conclusion unique

Une assurance exploitable conserve séparément : la requête et le datastore ; la capacité et le schéma effectif ; le sous-arbre avec annotations explicites, héritées et réinitialisées ; l’écriture tentée et l’erreur complète ; les vues de datastore pertinentes ; l’événement logiciel, matériel ou commercial qui peut changer la valeur ; l’observation opérationnelle ; enfin l’exécution de la reprise et le résultat du service.

Le dossier primaire fermé réunit la révision 14 et son enregistrement/historique Datatracker, les RFC 7952, 7950, 8342, 8525, 8526, 8527, 6241, 8040, 8341 et 9907, ainsi que system-configuration 20 : https://datatracker.ietf.org/doc/html/draft-ietf-netmod-immutable-flag-14; https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag/; https://datatracker.ietf.org/doc/draft-ietf-netmod-immutable-flag/history/; https://www.rfc-editor.org/rfc/rfc7952.html; https://www.rfc-editor.org/rfc/rfc7950.html; https://www.rfc-editor.org/rfc/rfc8342.html; https://www.rfc-editor.org/rfc/rfc8525.html; https://www.rfc-editor.org/rfc/rfc8526.html; https://www.rfc-editor.org/rfc/rfc8527.html; https://www.rfc-editor.org/rfc/rfc6241.html; https://www.rfc-editor.org/rfc/rfc8040.html; https://www.rfc-editor.org/rfc/rfc8341.html; https://datatracker.ietf.org/doc/html/draft-ietf-netmod-system-config-20; https://www.rfc-editor.org/rfc/rfc9907.html.

Ces textes établissent le mécanisme proposé et les limites des protocoles. Ils ne démontrent ni la conformité d’un produit nommé, ni une adoption générale, ni un incident évité, ni une reprise réussie. La liste d’implémentations de l’annexe reste une déclaration du projet, pas un rapport d’interopérabilité indépendant.