Résumé

  • La révision 10 propose un datastore candidat propre à une session, une opération update atomique, la détection des conflits sur les nœuds, trois modes de résolution et des comparaisons optionnelles avec le point de création ou de dernière mise à jour.
  • Ces mécanismes protègent la garde des modifications, sans prouver que la base est restée fraîche, que toute concurrence pertinente a été observée, que la résolution traduit l'intention humaine ou que le service a effectivement changé.

L'isolement protège une branche, pas le temps

Le problème traité par draft-ietf-netconf-privcand-10 est concret : avec un candidat partagé, un client peut valider les modifications inachevées d'un autre. Le projet crée donc, au premier accès pertinent, une copie de running réservée à la session NETCONF ou au client RESTCONF.

Pendant que cette copie est éditée, running continue de vivre. Le projet reconnaît qu'un candidat privé peut fortement se désynchroniser. Une opération update, une actualisation automatique annoncée ou l'actualisation implicite précédant le commit le rapproche à nouveau de la base courante. Rien ne remonte le temps.

Le Datatracker classe la révision 10 comme Internet-Draft actif du groupe NETCONF, en Working Group Last Call et destiné au statut Proposed Standard. Son historique date la version du 24 août 2026. Ce statut ne démontre ni produit ni déploiement.

Huit reçus, huit questions

1. Base. Il faut l'identité du serveur, le digest ou la révision exacte de running, la bibliothèque YANG, les valeurs par défaut, l'heure de création et la dernière mise à jour. creation-point, last-update et running actuel ne sont pas interchangeables. Même discard-changes peut restaurer un état déjà ancien.

2. Propriété des éditions. En NETCONF, client et serveur doivent annoncer la capacité. Un serveur non compatible peut ignorer la demande et poursuivre sans candidat privé. Le reçu lie donc utilisateur authentifié, session, capacités négociées, durée de vie et opérations à un même ensemble de changements. Le projet laisse en dehors de son périmètre les autres interfaces d'administration.

RESTCONF suit une autre voie. RFC 8040 ne prévoit pas l'annonce d'une capacité par le client ; le projet utilise un candidat privé puis le valide automatiquement afin de préserver l'attente d'une écriture immédiate. Une preuve NETCONF ne peut pas être recopiée telle quelle pour RESTCONF.

3. Sens de la différence. L'extension de RFC 9144 permet de comparer le candidat avec running, sa création ou sa dernière actualisation, mais le support du point de référence reste optionnel. Filtres XPath ou sous-arbre, option all, schéma, valeurs par défaut et droits de lecture déterminent le périmètre. « Aucun nœud correspondant » signifie que rien n'a été comparé, pas qu'aucune différence n'existe.

RFC 8341 autorise séparément opérations et contenu ; les données non lisibles peuvent être omises sans bruit. Une comparaison vide est donc un résultat borné par la vue autorisée.

4. Concurrence. La règle centrale détecte les modifications concurrentes du même nœud : valeur, existence, ordre choisi par l'utilisateur, conteneur de présence, feuille, liste de feuilles ou métadonnée YANG. Un serveur peut ajouter d'autres contrôles. Deux écritures sur des nœuds différents peuvent pourtant, ensemble, épuiser une capacité, supprimer une redondance ou violer une politique. Ces invariants inter-nœuds ont besoin d'un contrôle propre.

5. Autorité de résolution. revert-on-conflict annule l'actualisation entière ; prefer-candidate conserve les valeurs conflictuelles de la branche ; prefer-running les remplace. En actualisation automatique, le mode système peut modifier la branche sans que le client le remarque. Le reçu doit nommer déclencheur, mode, nœuds, valeurs avant/après, intention abandonnée et décideur responsable.

6. Commit. Le serveur exécute d'abord un update atomique implicite en revert-on-conflict, puis copie le candidat dans running. Un conflit doit faire échouer le commit. RFC 6241 fait de <ok> un accusé de réception sans erreur protocolaire, non une observation du réseau. Message ID, digest du candidat, rapport de conflit et nouvelle révision de running doivent rester liés.

7. Convergence. RFC 8342 distingue running, intended et operational. Transformations, ressources absentes et délais d'application peuvent les séparer. RFC 8526 permet d'y accéder par NETCONF sans les confondre. La vérification porte sur le bon appareil, au bon instant, pendant une fenêtre stable.

8. Résultat. Un observateur distinct vérifie l'interface, la route, la file, la politique ou le comportement de transfert, puis la population client, SLA ou métier réellement touchée. L'état du dispositif n'est pas automatiquement l'expérience du service.

Sources et limites de revue

La revue OPSDIR de la version 06 a soulevé des questions sur les points de référence, la définition du datastore et la sécurité ; la revue YANG Doctors de la même version l'a jugée « Almost ready ». Ce ne sont pas des verdicts nouveaux sur la version 10.

Le socle normatif consulté comprend RFC 6241, RFC 8040, RFC 8341, RFC 8342, RFC 8526 et RFC 9144. Aucun ne constitue le compte rendu d'un déploiement nommé.