Résumé

  • La révision 14 du projet NMOP distingue l’état réseau raisedupdatedcleared du parcours opérateur acknowledgeddiagnosedresolved, et une même RPC peut viser plusieurs incidents.
  • Le résultat positif est annoncé ensuite par une notification distincte. La revue YANG Doctors du 31 août relève qu’aucun mécanisme ne permet d’associer cette notification à la RPC qui l’a provoquée.
  • Un reçu commande-vers-clôture devrait conserver l’appel autorisé, les incidents visés, l’action, la notification corrélée, la traduction vers le ticket et la validation du service. Cette proposition est éditoriale, non normative.

Une traduction déterministe peut propager une incertitude

Le projet de modèle YANG veut réduire une difficulté réelle : les alarmes, métriques et anomalies arrivent de couches différentes, tandis que les équipes doivent comprendre leur impact sur un service commun. Son approche agrège ces signaux en incidents et propose trois opérations pour accuser réception, diagnostiquer et résoudre.

Le texte ne confond pas complètement la machine et l’opérateur. L’instance réseau suit les états raised, updated et cleared. Le travail de l’opérateur passe par acknowledged, diagnosed et resolved. Cette séparation permet qu’un défaut disparaisse avant la clôture humaine, ou qu’une équipe ait terminé son intervention alors qu’un symptôme reste visible.

Une troisième chronologie vit pourtant ailleurs : celle du ticket. La section opérationnelle recommande une traduction déterministe entre les états du modèle et Open, Assigned, In-Progress ou Resolved. Son objectif est d’éviter une visibilité « split-brain », avec un incident clos côté réseau mais ouvert dans l’OSS, ou l’inverse.

La détermination de la règle ne garantit pas la justesse de son entrée. Si cleared n’est pas relié à l’action qui l’a produit, la même règle peut convertir fidèlement une observation ambiguë en clôture administrative certaine.

Le numéro identifie l’incident, pas l’invocation

L’opération incident-resolve reçoit une liste de numéros d’incident. Elle peut donc demander en une fois la résolution de plusieurs instances. Après réussite, une notification séparée met à jour chaque incident vers cleared. Le détail de la résolution reste hors périmètre du projet.

Le numéro assure la continuité de l’instance : il dit quel incident a changé. Il ne nomme pas l’appel précis lorsque deux clients agissent presque simultanément, lorsqu’un nouveau diagnostic déclenche une autre action, ou lorsqu’un mécanisme autonome rétablit le service. Pour attribuer un résultat, il faut l’identité de la requête, et pas seulement celle de l’objet modifié.

La revue YANG Doctors classe le document « Almost Ready », tout en formulant cette objection concrète : les résultats de RPC arrivent par notification, sans moyen de savoir quelle notification résulte de quelle RPC. Elle demande également comment le client reconnaîtra la notification issue d’un diagnostic donné, et souligne des questions sur les identifiants, les listes vides, les erreurs et la direction des notifications.

Ce constat n’est ni un incident d’exploitation ni une condamnation du projet. La revue précise que la prochaine version, encore non publiée au moment de son examen, devrait être relue. La conclusion honnête porte donc sur la révision et l’interface visibles, pas sur un futur texte présumé.

Le contrôle d’accès ne remplace pas la causalité

NETCONF et RESTCONF fournissent le canal de gestion. Le projet exige un transport sécurisé et une authentification mutuelle; NACM peut limiter les opérations et les données accessibles à chaque utilisateur. Les erreurs de résolution peuvent signaler une cause probable non résolue, un refus d’autorisation, un délai dépassé ou une ressource indisponible.

Chaque pièce répond à une question utile. Qui s’est connecté ? Avait-il le droit d’appeler l’opération ? La demande a-t-elle échoué immédiatement ? Aucune ne répond seule à « quelle action autorisée explique cette notification tardive ? ». Même un acteur parfaitement authentifié peut lancer deux requêtes, abandonner la première, retenter la seconde et recevoir ensuite un état dont l’origine n’est plus évidente.

La sécurité du projet rappelle aussi que les incidents peuvent révéler l’état cassé du réseau et qu’un client défectueux ou hostile peut épuiser des ressources. Un reçu public ne doit donc pas exposer topologie, cause détaillée ou commande sensible. L’exigence porte sur une chaîne vérifiable dans le plan de contrôle, avec une projection publique minimale si nécessaire.

Le lot rend la réussite partielle politiquement importante

Une seule commande visant cinq incidents peut conduire à cinq histoires. Deux disparaissent après l’action prévue. Un troisième se résout par une protection locale. Un quatrième reste actif. Le dernier change d’identité après actualisation de la topologie. Une métrique « quatre sur cinq clôturés » peut être exacte et pourtant attribuer trop de mérite à la commande.

Le projet reconnaît que la résolution peut affecter les services en fonctionnement. Le client peut renoncer si l’impact n’est pas négligeable. La décision de ne pas agir, de choisir une solution alternative ou de diviser un lot doit alors rester attachée au résultat. Sans cela, le statut final récompense l’automate qui ferme vite et masque l’équipe qui a refusé un risque légitime.

Les sources de topologie ajoutent un autre piège. Le texte indique qu’un état périmé de la découverte multi-couche dégrade l’identification de la cause probable et l’analyse d’impact. Un incident peut donc être requalifié parce que la connaissance du réseau change, non parce qu’une réparation a réussi.

Le processus IETF fournit un état, pas un déploiement

La révision 14 date du 18 août. L’appel final du groupe s’est terminé le 3 septembre. Au gel des sources, Datatracker affichait toujours « In WG Last Call », sans responsable AD ni téléconférence IESG. La validation YANG du 7 septembre ne signalait ni erreur ni avertissement.

Ces faits montrent une proposition avancée et vérifiée comme schéma. Ils ne démontrent ni consensus final, ni RFC, ni déploiement, ni interopérabilité. Les minutes NMOP de l’IETF 126 montrent que la relation entre clé de liste, numéro et identifiant d’incident faisait encore l’objet de questions. La trace du débat est utile précisément parce qu’elle ne prétend pas le clore.

Un reçu qui accepte « origine inconnue »

Le reçu commande-vers-clôture commence avant l’appel. Il inscrit une identité d’invocation unique, les numéros et versions visés, le principal authentifié, son rôle, la règle d’autorisation, la politique de changement, l’impact anticipé et l’approbateur lorsque nécessaire.

Pendant l’exécution, il conserve l’acceptation ou l’erreur, le résultat par incident, le serveur et la version du modèle, les répétitions et la solution alternative. À l’arrivée d’une notification, il relie événement, révision et heure à l’invocation correspondante. S’il ne peut pas le faire, il écrit indépendant ou inconnu au lieu d’inventer un lien.

La clôture ajoute la règle de traduction utilisée par l’OSS, l’état et l’auteur du ticket, le test de service, le résidu ou contournement, le propriétaire du retour arrière et les corrections ultérieures. Les détails dangereux restent privés; un public légitime peut recevoir seulement la classe d’action, les heures, l’état et la qualité de corrélation.

The Policy Mirror oblige à localiser chaque pouvoir : NACM autorise, la RPC demande, le serveur observe, le ticket organise et le test de service confronte le résultat au réel. Running-Code Primacy demande leur réunion dans une exécution traçable. Reality, Not Advocacy interdit d’inventer une panne : le modèle est utile, mais l’état cleared ne doit pas devenir, seul, la preuve de sa propre cause.

Sources