Résumé

  • RFC 9968 consigne les conclusions d'un atelier IAB sur la prochaine ère des opérations de gestion réseau. C'est un rapport informationnel : ni protocole normatif, ni mandat donné à un contrôleur, à un modèle ou à un tableau de bord.
  • Un modèle décrit un état visé, une télémétrie décrit ce qu'elle a observé et un adaptateur convertit des représentations. Aucun de ces objets ne prouve seul l'exhaustivité, le consentement d'un client, ni le droit d'accepter les conséquences d'une panne.
  • Une automatisation responsable sépare l'intention de service, l'observation horodatée, la proposition bornée et l'autorisation locale. La séparation ne ralentit pas le réseau ; elle empêche qu'une représentation propre se fasse passer pour un pouvoir.

Un compte rendu n'est pas un ordre d'exploitation

Publié en mai 2026, RFC 9968 regarde ce qui a changé depuis l'atelier de 2002 décrit dans RFC 3535. Le constat est plus intéressant qu'une promesse de plateforme unique. Les participants demandent des outils utilisables, des modèles de service, des moyens de vérifier une configuration, de l'observabilité et un chemin plus praticable entre fournisseurs. Ils constatent aussi que SNMP et la ligne de commande restent présents, que NETCONF et YANG ne couvrent pas toutes les fonctions de nombreux équipements, et que plusieurs modèles coexistent réellement.

Cette description est précieuse parce qu'elle commence par l'exploitation au lieu de déclarer la victoire d'une abstraction. Mais le RFC énonce aussi sa limite : il relève du flux IAB et son statut est Informationnel, non Standards Track. Il rapporte des présentations et des notes de discussion sans les interpréter ni les valider ; sauf indication explicite, il ne prétend pas saisir un consensus, et les positions des participants ne sont pas forcément celles de l'IAB. Il faut prendre cette réserve au sérieux. Le document apporte une trace de problèmes et de pistes, pas une permission de modifier le réseau d'un tiers.

Le risque moderne naît lorsque cette limite disparaît dans l'interface. Une topologie bien dessinée, un graphe de connaissances cohérent ou une recommandation calculée avec confiance peuvent sembler plus réels que les contrats, les dépendances et les utilisateurs qui supporteront la conséquence. Or la lisibilité d'un objet n'est pas son autorité. Un système peut savoir formuler une modification sans savoir qui est habilité à en assumer le coût.

RFC 3535 avait déjà formulé la discipline essentielle : distinguer les données de configuration, l'état opérationnel et les statistiques ; minimiser les effets lors du passage d'une configuration A à une configuration B ; appliquer le moindre privilège ; distinguer la distribution d'une configuration de son activation. Ces exigences d'opérateurs sont elles-mêmes issues d'un atelier informationnel. Elles n'autorisent personne. Elles montrent pourquoi un fichier disponible, un client API valide et un modèle correctement analysé ne suffisent jamais à activer un changement sur un service actif.

Les quatre dossiers d'une action défendable

Le premier dossier est l'intention de service. Il nomme le résultat dû : disponibilité, enveloppe de latence, interconnexion client, classe de trafic protégée, limite de maintenance ou objectif de restauration. Il identifie aussi le responsable de l'engagement. Une configuration de routeur n'en est souvent qu'une traduction locale.

Le deuxième est l'observation : télémétrie, journaux, sondes, compteurs, vues de routage et signaux d'alarme. L'observation doit porter sa provenance, son âge, son champ, ses pertes et ses zones muettes. Un flux peut rapporter exactement une portion du monde tout en laissant une condition déterminante invisible. L'absence de notification peut traduire une santé réelle, mais aussi une collecte rompue, un filtre ou une donnée que le modèle ne sait pas exprimer.

Le troisième est la proposition de changement. Elle doit rendre visible le delta : services, équipements, clients, fenêtre, dépendances, effet attendu et voie de retour. Quand un adaptateur transforme un modèle de service en syntaxe propre à un fournisseur, il faut conserver les deux représentations et la version de l'adaptateur. Sinon, après un incident, l'organisation ne peut démontrer ni ce qu'elle avait demandé, ni ce que l'équipement avait réellement reçu.

Le quatrième est l'autorisation. Elle désigne qui peut approuver ce périmètre, sur quelles preuves, sous quelles conditions, avec quel droit de retour en arrière et jusqu'à quand. Ce n'est pas l'appel à une cérémonie humaine pour chaque commande. C'est l'exigence que la règle d'automatisation elle-même ait un propriétaire local, une portée limitée et un mécanisme de révocation.

RFC 8342, l'architecture NMDA, distingue configuration voulue, configuration appliquée et état opérationnel. C'est une distinction technique, non une constitution de l'entreprise. Elle ne décide ni qu'un état appliqué respecte une promesse client, ni qu'un contrôleur peut le changer. Elle installe pourtant une habitude salutaire : demander de quel type est l'enregistrement avant de lui attribuer une conclusion.

Les mécanismes de configuration restent à leur place. RFC 6241 décrit NETCONF, y compris des surfaces autour des configurations candidate et active ainsi que du confirmed commit ; RFC 8040 expose RESTCONF. Ces protocoles peuvent structurer, authentifier et restaurer une opération dans leur périmètre. Ils ne savent pas si un client de transit doit porter le risque, si une maintenance est proportionnée, ou quel responsable peut accepter une indisponibilité.

Une meilleure télémétrie ne tranche pas une décision

Le rapport NEMOPS a raison de placer vérification et observabilité au centre. Une configuration dont l'acceptation par les appareils n'est pas testable ne devrait pas alimenter une boucle automatique. Un modèle de service est plus utile qu'un inventaire de feuilles isolées lorsque le risque est celui d'un service. Des adaptateurs hors boîtier peuvent rendre des parcs hétérogènes exploitables. Tout cela améliore la preuve et l'exécution.

Cela n'établit pas l'omniscience. RFC 8639 décrit un cadre de souscription aux notifications YANG ; RFC 8641 traite les mises à jour de datastore ; RFC 9196 décrit des capacités de système et des notifications. Ces documents donnent à un récepteur des signaux structurés dans un schéma convenu. Ils ne prouvent pas que toutes les fonctions sont modélisées, qu'une traduction est sans perte, qu'un flux n'a jamais été interrompu ou qu'aucune réalité externe ne modifie la décision.

Le syllogisme dangereux est bref : le modèle dit que le changement est possible ; donc le modèle est autoritaire ; donc le changement est autorisé. Le premier énoncé peut être techniquement bien étayé. Le deuxième doit être démontré ailleurs. L'autorité provient des engagements de l'opérateur, de rôles délégués, des contrats, du droit applicable et de la personne qui assumera réellement la perte. Aucun chemin dans un arbre de données ne peut l'inventer.

Les notes de Heng Lu sur la primauté du code qui tourne, la spécification initiale minimale et la décision locale et les couches de réalité offrent ici un test éditorial. Une surface commune doit faciliter l'interopérabilité sans capturer les décisions ultérieures. L'effet constaté dans le service compte plus qu'une déclaration symbolique de contrôle. Un dossier ne reste utile que si ses limites demeurent visibles.

Éprouver le passage de la preuve à l'action

L'exercice opérationnel doit tester autre chose qu'une transaction réussie. Partir d'une intention de service mesurable indépendamment. Conserver l'inventaire du contrôleur, les versions de modèles, les capacités annoncées par les appareils, les horodatages, les lacunes de notification, le résultat de traduction et le delta proposé. Vérifier ensuite l'acceptation par chaque cible, le respect de l'enveloppe de service et un retour en arrière borné.

Les cas négatifs sont les plus révélateurs : une télémétrie absente alors que le service reste sain ; une notification retardée ; une feuille de modèle refusée par un appareil ; une fonction fournisseur non prise en charge par l'adaptateur ; une modification CLI hors bande ; un redémarrage entre distribution et activation ; une portée modifiée après approbation. Chacun sépare une défaillance d'observation, de modèle, de traduction, de dérive, d'autorité ou de retour en arrière.

Sources