Résumé

  • draft-ietf-netconf-yp-transport-capabilities-07 rend découvrables les transports de notification YANG, leurs encodages et leurs protocoles de sécurité, à partir de données de conception ou du serveur en fonctionnement.
  • Ce relevé indique ce qui est pris en charge. Il ne prouve ni la validité de la combinaison choisie à cet instant, ni l’autorisation du destinataire, ni l’acceptation de establish-subscription, ni la livraison.
  • Une donnée fournie avant déploiement et une lecture à l’exécution n’ont pas la même origine ni la même fraîcheur. Les réduire à un booléen « supporté » détruit cette distinction.
  • Un reçu de décision entre capacité et abonnement devrait relier constat, combinaison, politique, destinataire, tentative, résultat et repli. C’est une proposition éditoriale, pas une exigence de l’IETF.

Une réponse exacte peut conduire à une conclusion fausse

La révision 07 de YANG Notification Transport Capabilities organise un problème concret. Un système de gestion doit savoir comment un serveur peut expédier des notifications avant de lui demander un abonnement. Le modèle ajoute donc au cadre de capacités système une liste par protocole de transport, complétée par des listes d’encodages et de mécanismes de sécurité.

L’exemple est parlant. Sous HTTPS figurent XML et JSON, puis TLS 1.2 et TLS 1.3. Sous UDP-notif figurent JSON et CBOR, puis DTLS 1.2 et DTLS 1.3. Un orchestrateur peut ainsi éliminer des propositions manifestement étrangères au serveur.

Il n’en découle pas qu’un abonnement existe. Un tableau de bord qui transforme toute cette structure en « notifications disponibles » mêle au moins cinq états : capacité observée, combinaison retenue, conformité à la politique locale, acceptation par le serveur et livraison au récepteur. Chaque état possède un responsable et une preuve propres.

Le texte de la révision 07 date du 17 août 2026. La fiche Datatracker a été actualisée le 8 septembre, jour d’échéance des commentaires de la dernière consultation IETF annoncée le 25 août. Au 9 septembre, le document restait un Internet-Draft actif, destiné à Proposed Standard, soumis à l’IESG et dans l’état « Waiting for AD Go-Ahead ». Une échéance écoulée n’est ni un RFC ni une approbation finale.

Deux sources, donc deux horloges

Le projet s’appuie sur le RFC 9196, dont l’un des choix les plus utiles est aussi le plus facile à perdre dans une interface. Les capacités peuvent être publiées au moment de la conception sous forme de données d’instance YANG, sans attendre un nœud actif. Elles peuvent aussi être lues sur un serveur en service au moyen de NETCONF ou RESTCONF.

La première voie sert au concepteur d’un système de gestion, à l’intégrateur et à l’acheteur. Elle décrit ce qu’un type de produit est censé savoir faire. La seconde sert aux applications pilotées par les modèles et permet de tenir compte d’une licence, d’une contrainte matérielle ou d’un changement intervenu en exploitation. Le RFC 9196 cite même la lecture à l’exécution comme moyen de vérifier ce qui a effectivement été mis en œuvre par rapport à l’information antérieure.

Les deux assertions peuvent être sincères tout en divergeant. Un fichier de produit ne connaît pas forcément la carte installée. Une réponse du serveur peut devenir ancienne avant l’action suivante. Le cadre recommande des notifications « on-change » lorsque ces capacités peuvent évoluer, mais un consommateur doit encore les écouter et relier le changement à ses propres décisions.

Le registre d’automatisation devrait donc conserver l’origine, la révision du module, le modèle d’équipement, la version logicielle, le mode de récupération, l’heure d’observation et la règle d’expiration. La mention « supporté » n’est pas mensongère sans ces éléments; elle est trop pauvre pour exercer un pouvoir.

Une liste de valeurs n’est pas la trace d’un choix

Chaque entrée transport-capability est indexée par le protocole de transport. À l’intérieur, security-protocol et encoding-format sont des listes distinctes. Cette forme est adaptée à la découverte. Elle n’est pas un procès-verbal de négociation.

Il serait excessif d’en conclure que le modèle affirme à tort toutes les combinaisons cartésiennes entre ses listes. Les sources ne permettent pas cette accusation. La conclusion opérationnelle est plus rigoureuse : la présence de trois valeurs ne suffit pas à prouver que le triplet précis voulu par l’orchestrateur fonctionne dans le contexte présent. Il faut choisir le triplet, le soumettre et garder le résultat.

Le RFC 8639 rend cette limite incontestable. Pour un abonnement dynamique, la demande seule ne fait pas naître l’abonnement chez le producteur. Celui-ci n’existe qu’après acceptation de l’appel establish-subscription. Le producteur peut refuser pour plusieurs raisons et fournir des indications structurées sur des paramètres qui auraient davantage de chances de réussir.

Même l’acceptation ne prouve pas la continuité de la livraison. Elle atteste une transition dans l’état du producteur. L’adresse du récepteur peut rester injoignable, le chemin peut se rompre et l’abonnement peut être suspendu. Le premier message reçu et la fin de service appartiennent eux aussi au dossier de preuve.

Le chemin de gestion n’est pas le chemin de notification

Le projet énonce une hypothèse d’architecture : un réseau de gestion relie l’orchestrateur à l’équipement, et la connectivité ainsi que le point d’accès de gestion sont déjà configurés. C’est ainsi que le catalogue devient lisible.

Cette hypothèse ne configure pas automatiquement le récepteur des notifications. Elle ne décide pas non plus qu’une identité authentifiée sur NETCONF ou RESTCONF a le droit de créer un flux vers une destination donnée. L’authentification identifie le demandeur; NACM et la politique locale limitent ce qu’il peut faire; une autre équipe peut encore gouverner le récepteur et sa joignabilité.

Dans une grande organisation, ces responsabilités se distribuent entre exploitation du réseau, sécurité, plateforme de télémétrie et fournisseur de l’orchestrateur. Le danger n’est pas un secret révélé. Le projet qualifie les nouveaux nœuds de lecture seule et non sensibles, et prévoit des sessions sûres et mutuellement authentifiées. Le danger est de convertir un fait non secret en permission implicite. Savoir que TLS 1.2 figure dans le catalogue n’équivaut pas à l’autoriser pour ce destinataire.

La distinction respecte le texte au lieu de lui attribuer une faiblesse imaginaire. La confidentialité du menu et les conséquences institutionnelles de son utilisation sont deux surfaces différentes.

Des preuves bornées doivent garder leurs bornes

Datatracker indique, au 8 septembre, zéro erreur et zéro avertissement de validation YANG. L’examen de sécurité courant est « Ready », celui consacré au transport « Almost ready »; l’IANA signale des actions nécessaires et les expertises associées sont terminées. Ce sont des informations de processus précises. Elles ne mesurent pas l’exploitation.

La section d’état des implémentations dit que Huawei a mis le document en œuvre dans un producteur YANG-Push de VRP et Cisco dans IOS XR. Elle demande également au RFC Editor de supprimer cette section avant publication. Ces mentions montrent que le modèle a dépassé le papier. Elles ne constituent ni une matrice publique d’interopérabilité pour la révision 07, ni un inventaire de triplets testés, ni une statistique de déploiement.

Le détail dtls12 illustre une autre exigence de précision. Sa description appelle DTLS 1.2 obsolète et déconseille d’activer cette fonction. Elle ne déclare pas TLS 1.2 interdit, alors que l’exemple le cite sous HTTPS. Une politique qui réagit seulement à la chaîne « 1.2 » perdrait le protocole, le contexte normatif et donc la décision réelle.

Le reçu qui manque à l’automatisation

Un reçu de décision entre capacité et abonnement peut relier les preuves sans modifier le protocole. Il identifie d’abord l’équipement, la famille de produit, la révision du module et le logiciel. Il précise si l’observation provient d’un fichier de conception ou d’une lecture en direct, son adresse, sa date et sa durée de validité.

Le reçu conserve ensuite l’entrée de transport observée et le triplet exactement choisi : transport, encodage, sécurité. Il nomme l’identité ayant agi, le destinataire, le point de terminaison, la version de politique et les paramètres soumis. Il distingue acceptation, refus, expiration du délai, arrêt ultérieur et acceptation sans première livraison.

Enfin, il attache les indications d’erreur, le repli éventuel et l’autorité qui a permis un choix plus faible. Sans cette dernière partie, une automatisation peut afficher un meilleur taux de réussite tout en dégradant silencieusement la politique.

The Policy Mirror invite à retrouver le champ qui commande réellement l’issue. Ici, le modèle écrit la possibilité; la politique écrit la permission; establish-subscription écrit l’existence; seul le récepteur prouve l’utilité. Running-Code Primacy demande que ces traces se rencontrent. Reality, Not Advocacy impose une conclusion mesurée : le projet promet un meilleur catalogue, pas une livraison automatique. C’est précisément pourquoi la décision doit laisser son propre reçu.

Sources