Résumé

  • La révision 10 du projet IETF sur la candidate privée attribue à chaque session NETCONF un espace de préparation distinct. Le commit déclenche toujours une mise à jour implicite en mode revert-on-conflict : le moindre conflit arrête l’opération au lieu de désigner silencieusement un vainqueur.
  • Une décision explicite reste pourtant destructive. prefer-candidate conserve la valeur privée qui pourra écraser la valeur courante ; prefer-running efface la modification privée conflictuelle. Les droits NACM, l’authentification et l’annonce d’un mode ne disent pas pourquoi ce choix était légitime pour ce service.
  • Il faut donc un mandat de commit : base de la branche, ensemble des conflits, mode retenu, valeurs perdues, responsable, périmètre autorisé, contrôles, conditions du commit confirmé et cible de repli. Il s’agit d’une proposition de Daniel Kade, non d’une exigence de l’IETF.

La branche privée ferme une porte et en ouvre une autre

La candidate partagée de la RFC 6241 permet de construire une configuration complète avant de la rendre active. Ce confort s’accompagne d’un risque connu : plusieurs sessions peuvent modifier le même espace. Un client peut ainsi valider, avec ses propres changements, une modification laissée par un autre client. Le verrouillage évite certains accidents, mais transforme vite la prudence en file d’attente. Même le verrouillage partiel de la RFC 5717 ne garantit pas qu’un commit ne contiendra que le travail d’un seul client et suppose de comprendre toutes les dépendances du modèle.

Le projet draft-ietf-netconf-privcand-10 propose une réponse nette. Publié le 24 août 2026, en dernier appel du groupe NETCONF et destiné à la voie Proposed Standard, il reste un Internet-Draft actif, non une RFC. Sa candidate est propre à la session. Elle naît d’une copie de la configuration courante au premier appel pertinent, puis conserve les modifications hors de portée des autres sessions de configuration NETCONF. Si la session disparaît, la candidate et les changements non validés disparaissent avec elle.

Ce mécanisme protège l’auteur d’une branche contre le commit involontaire du travail d’autrui. Il rend également possible une préparation concurrente sans immobiliser tout le datastore. C’est un progrès substantiel. Il ne faudrait pas lui demander une autre promesse : déterminer quel projet de configuration possède la meilleure autorité lorsque la production évolue entre-temps.

Une branche privée répond à la question « qui a préparé ces changements ? ». La question « lesquels doivent prévaloir ? » commence seulement lorsqu’elle rejoint un monde qui n’est plus celui de sa création.

Le conflit porte sur le point de départ autant que sur la valeur

L’opération update remplace la base ancienne de la candidate privée par la configuration courante, puis rejoue les changements du client. L’ensemble est atomique. Cette propriété évite un état intermédiaire où seule une partie du rapprochement aurait réussi.

Le projet définit le conflit par rapport à l’intention possible du client. Il ne suffit pas que deux textes diffèrent. La configuration courante et la candidate doivent avoir modifié le même nœud pendant l’intervalle de préparation, dans une situation où un nouveau point de départ aurait pu conduire le client à agir autrement. Valeur, existence, ordre choisi par l’utilisateur, conteneur de présence, leaf-list, leaf ou métadonnée YANG peuvent être concernés. Le serveur peut ajouter des contrôles, notamment à l’aide d’un identifiant de transaction.

Chaque nœud concerné est marqué intérieurement in conflict. Le projet laisse le mécanisme de marquage hors de son périmètre ; le marqueur d’un enfant ne remonte pas automatiquement vers tous ses ancêtres. Les emplacements conflictuels devraient être communiqués sous forme de chemins XPath et de valeurs afin que le client puisse revoir son intention.

Cette dernière expression fixe la limite institutionnelle du mécanisme. Le serveur connaît l’arbre et les opérations. Il ne connaît pas le ticket d’urgence, la fenêtre de maintenance, la hiérarchie des services ni le responsable qui a autorisé une exception. Un nœud peut paraître local tout en commandant une dépendance plus large. Deux identités dûment authentifiées peuvent poursuivre des objectifs également valides mais incompatibles dans le temps.

Détecter le conflit conserve le désaccord. Cela ne tranche pas le droit de le résoudre.

Trois modes, trois responsabilités

revert-on-conflict est le mode obligatoire et le mode par défaut. S’il subsiste un seul conflit, la mise à jour échoue sans fusion. Tout commit effectue d’abord cette mise à jour implicite, quel que soit le défaut système éventuellement choisi pour d’autres mises à jour. Après l’échec, le client doit modifier ou abandonner son travail, ou lancer consciemment une mise à jour avec un mode de résolution. Le refus est précieux : il crée un moment où une décision peut encore être examinée.

Avec prefer-candidate, les valeurs privées conflictuelles restent dans la branche, tandis que les changements courants non conflictuels sont intégrés. Le commit suivant écrasera donc les valeurs correspondantes de la configuration courante. Ce qui est perdu est l’intention apparue en production après la création de la branche.

Avec prefer-running, les valeurs courantes remplacent les modifications privées en conflit. Le reste du travail privé demeure, mais la branche n’exprime plus entièrement le projet de son auteur. Ce qui est perdu est une partie de l’intention préparée.

Ni l’emplacement ni la chronologie ne suffisent à choisir. « Candidate » ne signifie pas « plus récente au sens métier ». « Running » ne signifie pas « approuvée pour l’avenir ». Une valeur courante peut être une mesure d’urgence temporaire ; une branche privée peut correspondre à une migration depuis longtemps approuvée, ou l’inverse. Les mots du datastore décrivent un état technique, pas un rang de légitimité.

Le serveur peut aussi utiliser un mode différent pour les mises à jour automatiques après une modification de running. Un choix non standard doit être annoncé, tout comme l’éventail des modes lorsqu’ils ne sont pas tous disponibles. L’annonce rend le comportement observable. Elle ne donne ni la raison de la politique, ni sa période de validité, ni le service qui en assume la perte éventuelle.

Le vrai risque est alors décalé dans le temps. Le commit final peut être propre et réussi, alors que la décision destructive a été prise plus tôt par une mise à jour automatique. Un journal limité au commit attribuera l’activation au bon client mais laissera sans auteur la règle qui a fabriqué le résultat.

NETCONF conserve une histoire que RESTCONF comprime

Dans NETCONF, le client et le serveur négocient la capacité pour toute la session. Si le client la demande à un serveur qui ne la prend pas en charge, celui-ci peut ignorer la demande pour compatibilité ascendante ou fermer la session ; le projet recommande plutôt la fermeture aux nouvelles implémentations. Une préférence du client n’est donc pas une preuve que la session est réellement privée.

RESTCONF ne dispose pas de la même annonce côté client. Lorsqu’un serveur publie la capacité private-candidate, chaque écriture sur la ressource de données passe par une candidate propre à la requête et se valide automatiquement. Cette solution préserve la sémantique immédiate attendue par les clients qui ne connaissent pas l’extension. Elle ne crée pas une branche longue couvrant plusieurs opérations comme une session NETCONF.

La différence commande le contrôle. NETCONF laisse une durée entre création, mise à jour, comparaison et commit ; le mandat peut expirer pendant cette durée. RESTCONF resserre ces étapes dans une requête ; une approbation placée entre modification et activation n’y tient pas de la même manière. Une organisation doit donc gouverner la frontière réelle, et non une analogie de vocabulaire.

Le droit d’exécuter n’est pas le mandat de départager

La RFC 8341 permet à NACM de limiter la lecture, l’écriture et l’exécution selon l’utilisateur et le contenu. Le projet qualifie update d’opération sensible et avertit contre les effets d’un accès non autorisé. Authentification mutuelle, transport sûr et politique d’accès sont indispensables.

Ils ne résolvent pourtant pas le cas d’un acteur autorisé au sens du protocole mais hors de son mandat ponctuel. Un compte d’automatisation peut écrire un sous-arbre d’interfaces sans être autorisé à annuler une mesure prise par l’équipe incident. Un administrateur peut posséder le droit d’exécution tout en ignorant que sa branche touche un service partagé. Le privilège durable répond à « peut-il appeler cette opération ? » ; le mandat de changement répond à « peut-il imposer cette valeur-là maintenant, contre cette autre intention ? ».

La comparaison étendue de la RFC 9144 apporte une pièce de preuve. Lorsque le serveur prend en charge les nouveaux points de référence, le client peut comparer sa candidate à running, à son point de création ou à son dernier update. On voit mieux l’écart et l’évolution du contexte. Mais un diff n’évalue ni l’importance métier d’un nœud, ni la complétude des dépendances, ni la validité du mandat.

Construire un mandat de commit

Le contrôle manquant peut rester extérieur au protocole. Le mandat de commit proposé ici est un dossier bref, lié à un seul rapprochement conflictuel et destiné à expirer.

Il identifie le dispositif, le datastore, la session ou la requête, le principal authentifié et le propriétaire de l’automatisation. Il fixe le point de création, le dernier point de mise à jour et une référence stable de running. Il joint le delta exact et tous les conflits signalés, enrichis lorsque la politique locale connaît un parent ou un service que le marqueur par nœud ne révèle pas.

Il consigne le défaut annoncé, les modes disponibles, le caractère automatique ou explicite de l’opération et le mode appliqué. Puis il nomme la perte : valeurs running promises à l’écrasement sous prefer-candidate, modifications privées supprimées sous prefer-running, ou conflits encore ouverts sous revert-on-conflict.

La version de la politique NACM figure au dossier, sans servir de substitut à l’approbation. Un responsable humain ou automatisé indique le motif, le périmètre, la fenêtre, la limite d’impact et l’expiration. Résultat des comparaisons, validation de configuration et contrôles représentatifs du service soutiennent la décision.

Enfin, le mandat précise le commit confirmé, son délai, ses identifiants persistants s’ils existent, les signaux de santé attendus et la cible exacte de retour. La clôture conserve le résultat et une empreinte de la nouvelle configuration courante. Toute modification d’une prémisse—running plus récent, politique changée, observateur absent, fenêtre expirée—annule le mandat.

Ce registre n’est ni une opération NETCONF ni une obligation de l’IETF. C’est une proposition de Daniel Kade pour préserver la partie que le protocole ne prétend pas transporter : la justification de la priorité accordée à une intention valable sur une autre.

Pouvoir revenir ne rend pas la première décision légitime

Le commit confirmé reste une excellente défense. Si la session cliente se rompt pendant un commit confirmé utilisant une candidate privée, le projet prévoit le rétablissement immédiat de running et l’abandon des changements proposés. La capacité à revenir borne une panne de connectivité ou une perte de contrôle.

Elle ne valide pas rétroactivement le choix initial. Une décision peut être réversible mais prise hors mandat. À l’inverse, une intervention d’urgence légitime peut manquer d’un repli fiable ; dans ce cas, l’absence de repli doit interrompre l’exécution, pas créer fictivement une autre autorité.

Même discard-changes exige une formulation exacte. La candidate revient à son point de création ou à son dernier point de mise à jour, selon le plus récent. Ce point ne correspond pas forcément au running actuel. Dire « revenu à la production » après un abandon peut donc masquer un nouvel écart.

L’isolation protège l’origine du travail. Le conflit protège la visibilité du désaccord. Le commit confirmé protège une voie de retour. Seul un mandat attaché à la décision peut expliquer, longtemps après la disparition de la session, pourquoi une intention a légitimement remporté la priorité.

Sources