Résumé

  • La révision 00 de NAIM Operation IR peut embarquer des objets de compensation destinés à inverser ou atténuer des changements déjà exécutés ; le texte prévoit pourtant explicitement l’échec de la compensation, l’expiration d’un groupe et la perte de connectivité pendant le retour arrière.
  • Un identifiant commun relie des opérations. Il ne crée pas, à lui seul, l’atomicité, l’isolation, le verrouillage, l’ordre d’exécution ou un point de restauration partagé entre équipements et protocoles.
  • Dire « restauré » exige davantage qu’un inverse envoyé : il faut l’état de référence, les décisions d’autorisation, les préconditions lues, l’ordre exact des actions, les accusés de réception, les écritures concurrentes, l’observation finale et une preuve de service indépendante.

L’inverse est calculé après que le monde a déjà changé

Supposons qu’un agent doive déplacer plusieurs interfaces vers une nouvelle politique de routage. Le Handler valide l’intention, vérifie les préconditions et lance dix changements. Le contrôle de service échoue après la troisième cible. Une compensation est prête : rétablir l’ancienne référence de politique.

Entre-temps, un autre contrôleur a corrigé une interface, un pair a reçu une annonce puis un retrait, une alarme a déclenché une procédure externe et le chemin de gestion d’un équipement a disparu. Réécrire l’ancienne valeur peut être juste sur une cible, destructeur sur une autre et impossible sur la troisième. Même une configuration redevenue identique ne peut pas rappeler les paquets déjà acheminés ni annuler une décision prise ailleurs.

C’est précisément pourquoi le choix des mots du brouillon compte. Une Compensation Operation est une opération « destinée à inverser ou atténuer » l’effet d’une opération antérieure. « Destinée à » décrit une finalité ; « atténuer » admet qu’un retour exact n’existe pas toujours. La présence d’un champ ne transforme donc pas l’intention en résultat.

Un objet intermédiaire utile, mais pas une preuve d’exécution

Operation IR propose une représentation neutre vis-à-vis du protocole entre une demande en langage naturel et NETCONF, RESTCONF ou un autre mécanisme d’administration. L’objet peut porter des écritures, lectures, RPC ou actions, filtres, choix de datastore, préconditions, expressions, métadonnées de transaction et compensations. L’IA reste l’encodeur de l’intention ; un Handler déterministe valide, traduit puis exécute.

Il faut néanmoins conserver le statut exact du texte. Datatracker classe draft-feng-netconf-naim-op-00, daté du 18 juillet 2026, comme Internet-Draft individuel actif, sans filière RFC ni statut RFC prévu formel. La page rappelle qu’un I-D peut être soumis par quiconque, n’est pas approuvé par l’IETF et n’a pas de valeur formelle. L’en-tête soumis mentionne « NETCONF Working Group » et « Intended status: Standards Track » ; ce sont des mentions de l’auteur, pas une adoption par le groupe ni un consensus IETF.

Le document exclut explicitement de son périmètre les algorithmes automatiques qui dérivent la compensation, les détails d’ordonnancement et la logique privée du moteur. Deux Handlers peuvent donc recevoir une même intention initiale et produire des suites de reprise différentes. Le journal doit conserver les objets exacts réellement générés, pas seulement l’étiquette « compensation automatique ».

Corrélation ne signifie pas transaction atomique

La section 12 permet d’associer plusieurs objets Operation IR au moyen d’un identifiant de transaction partagé. Cette association est indispensable pour reconstituer une histoire. Elle ne définit cependant ni commit tout-ou-rien, ni isolation sérialisable, ni verrou global, ni journal durable, ni ordre obligatoire.

La différence devient visible dès que le groupe traverse des systèmes hétérogènes. Un équipement peut prendre en charge un datastore candidat et un commit confirmé ; un autre écrit directement dans running ; une action applicative peut produire un effet dans un système tiers. Le même identifiant relie ces faits mais ne leur donne pas une horloge, une capacité ou une frontière de retour commune.

L’ordre inverse n’est pas davantage mécanique. Si la première opération crée une politique et la deuxième l’attache à une interface, la reprise doit probablement détacher avant de supprimer. Mais si un autre acteur a depuis attaché cette politique à un service légitime, la suppression devient une nouvelle faute. Un inverse syntaxtiquement exact peut être faux face à l’état vivant.

La compensation réclame une nouvelle autorité

Le brouillon recommande de soumettre les compensations aux mêmes attentes d’autorisation, de validation et de journalisation que les opérations ordinaires. Sa section sécurité cite séparément l’autorisation des compensations et l’audit de l’exécution et du retour arrière.

Il ne faut donc pas copier la permission de l’aller vers le retour. Créer un objet provisoire et le supprimer peuvent relever de privilèges différents. L’acteur peut avoir perdu son rôle. Une référence dynamique peut désigner une autre cible. Une règle d’accès peut avoir changé pendant l’incident. RFC 8341 montre que NETCONF et RESTCONF autorisent séparément opérations et nœuds de données ; l’urgence n’abolit pas ce contrôle.

Une précondition réduit le risque de course en exigeant qu’une valeur soit encore vraie avant l’exécution. Elle reste une lecture datée. Elle ne prouve ni que l’écriture suivante a été appliquée, ni qu’elle a persisté, ni que le service a repris. Chaque compensation doit conserver son principal, sa cible résolue, sa décision d’accès, son observation de précondition et son résultat.

Le texte reconnaît l’échec du chemin de secours

Le passage le plus lucide du brouillon demande aux implémentations transactionnelles de définir leur comportement en cas d’échec de précondition, de panne au milieu du groupe, d’échec de compensation, de délai dépassé ou de perte de connectivité pendant le retour arrière.

Ces états interdisent un simple booléen rolled_back. Après un silence réseau, le Handler peut ignorer si l’équipement n’a rien reçu, a appliqué sans répondre ou a répondu sur un chemin perdu. Une répétition aveugle peut dupliquer un effet ; l’abandon peut laisser une moitié de changement. Le rapport devrait distinguer au moins planifié, autorisé, précondition vérifiée, envoyé, acquitté, observé indépendamment et validé au niveau du service.

La comparaison NETCONF resserre la portée

RFC 6241 définit une sémantique plus étroite pour rollback-on-error : si le serveur annonce cette capacité, un edit-config peut s’arrêter sur erreur et restaurer la configuration visée à son état complet du début de l’opération. Cette promesse appartient à une opération et à une capacité précises.

Le même RFC avertit qu’en configuration partagée, le retour arrière peut supprimer par inadvertance les changements d’autres sessions si aucun verrou n’a été pris. Il prévoit également l’erreur rollback-failed. Le commit confirmé dépend de sa propre capacité et du datastore candidat.

Operation IR, parce qu’il est neutre vis-à-vis des protocoles, peut combiner ce mécanisme avec une écriture RESTCONF compensatrice ou un RPC applicatif. Il ne peut pas emprunter automatiquement la garantie la plus forte de l’un pour couvrir les autres. Le mot « rollback » désigne plusieurs mécanismes ; il n’est pas un reçu universel.

Revenir à une valeur n’efface pas les effets

RFC 8342 sépare configuration voulue et état opérationnel. Une égalité de datastore ne démontre donc pas déjà une égalité du système appliqué. Au-delà du modèle YANG, des effets ne possèdent aucun inverse fidèle : paquets transmis, notifications consommées, secrets révélés, délais expirés, facturation, alarmes client, choix humains.

Une compensation réussie peut ainsi être une bonne atténuation. Le mensonge commence lorsqu’un tableau de bord traduit « compensation terminée » par « aucun impact » ou « état antérieur restauré ». La preuve honnête doit dire quelle portée a retrouvé sa valeur, quelle portée reste inconnue et quels effets persistent.

Le dry-run doit montrer ses inconnues

Le mode dry-run proposé n’applique aucun changement et devrait présenter les cibles résolues, valeurs, datastore, contrôles, résumé protocolaire, plan de compensation, effets connus et limites. Le texte reconnaît qu’une prévisualisation peut rester incomplète lorsque l’état vivant, l’autorisation ou les conditions externes ne sont vérifiables qu’à l’exécution.

Une prévisualisation verte n’est donc sérieuse que si elle expose les contrôles différés, les cibles liées à un instantané et les effets sans inverse. Sa fonction est d’éclairer la décision, non de certifier le futur.

Le reçu de restauration

Pour chaque groupe, conservons séparément l’intention immuable et la version du contexte ; le modèle canonique du Handler ; les décisions d’accès ; les lectures de précondition ; les messages protocolaires exacts ; l’ordre des accusés, erreurs et délais ; les objets de compensation exacts ; leurs propres contrôles ; les verrous et écritures concurrentes ; l’état de configuration et l’état opérationnel observés après coup ; les effets résiduels ; enfin un test de service provenant d’un point de vue indépendant.

Le statut final doit répondre à trois questions distinctes : la compensation a-t-elle été tentée ? l’état modélisé dans une portée déclarée correspond-il à la référence ? le service attendu fonctionne-t-il ? Aucun « oui » ne doit remplir automatiquement la case suivante.

Sources