Résumé

  • La révision 11 associe une connexion QUIC à une session NETCONF, les flux bidirectionnels ouverts par le client aux RPC de configuration et un flux unidirectionnel ouvert par le serveur à chaque abonnement.
  • Cette topologie rend le transport vérifiable ; elle ne remplace pas les preuves distinctes d’identité, d’autorisation NACM, de transaction, de transition entre datastores, d’état opérationnel et d’effet réseau.

draft-ietf-netconf-over-quic-11 propose quelque chose de plus utile qu’un simple changement de transport : une géographie des responsabilités. Une connexion QUIC porte une seule session NETCONF. Le client ouvre des flux bidirectionnels pour les RPC de configuration. Le serveur ouvre des flux unidirectionnels pour les notifications, un par abonnement. Une panne peut ainsi être située dans la connexion, la session, le flux, le message ou l’opération, au lieu d’être noyée dans un unique journal de « succès ».

Cette clarté impose une discipline symétrique. L’ordre des octets n’est pas l’ordre de tous les événements. Un certificat accepté n’est pas une permission. Un message correctement délimité n’est pas une opération correcte. <ok/> n’est pas une observation du plan de données. La configuration intended n’est pas nécessairement l’état operational.

La révision 11 a été déposée le 25 août 2026. Le Datatracker la présente comme Internet-Draft actif du groupe NETCONF, destiné au Standards Track, au stade WG Document et I-D Exists. Son historique confirme la date. Le texte rappelle qu’il s’agit d’un travail en cours expirant le 26 février 2027. Ce statut n’atteste ni mise en œuvre, ni déploiement, ni interopérabilité, ni performance, ni adoption.

Commencer par ce qui a réellement été négocié

RFC 7301 définit ALPN. La révision 11 demande l’identifiant noq et le port UDP 831. Demander une attribution n’équivaut pas à l’obtenir : le registre ALPN de l’IANA figé pour cette enquête ne contient pas noq.

Le premier reçu doit donc conserver la valeur négociée lors de la poignée de main, les extrémités, le port, les paramètres QUIC, l’heure et l’identité logicielle. Une chaîne inscrite dans un fichier de configuration ne prouve même pas qu’elle a été négociée. Une négociation réussie prouve le choix d’application pour cette connexion, pas la conformité complète à la révision 11.

Distinguer le certificat, le nom NETCONF et le droit d’agir

RFC 8446 définit TLS 1.3 et RFC 9001 son emploi avec QUIC. Le modèle NETCONF sur TLS vient de RFC 7589, qui sépare la validation du certificat de la règle ordonnée transformant cette identité en nom d’utilisateur NETCONF ; RFC 9144 actualise le profil pour TLS 1.3.

Il faut conserver la chaîne, l’ancre de confiance, l’état de révocation, le résultat de validation, puis la règle exacte et sa version. Le droit arrive encore après. RFC 8341 charge NACM d’autoriser les opérations, les nœuds de données et les notifications. L’authentification dit qui contrôle une clé ; elle ne dit pas si ce principal pouvait modifier cette feuille à cet instant.

Traiter une nouvelle connexion comme une nouvelle session

Une connexion correspond à une session. Sa fermeture donne une limite propre à l’audit : identifiants, principal, négociation, début, fin et cause. Après une rupture, la connexion suivante crée toutefois une nouvelle session. Si le contrôleur n’a pas reçu la réponse précédente, il peut répéter une intention déjà exécutée.

La révision 11 interdit les données précoces. C’est important car RFC 9001 explique l’absence de protection intrinsèque contre le rejeu en 0-RTT. Mais cette interdiction ne rend pas les relances applicatives exactement une fois. Il faut une identité stable de l’intention, la filiation des tentatives, un journal transactionnel côté serveur et une politique d’idempotence.

Ne pas perdre l’association entre flux et abonnement

RFC 9000 fournit des flux d’octets ordonnés. Dans la proposition, un RPC circule sur un flux bidirectionnel lancé par le client. L’abonnement est d’abord demandé par RPC ; après acceptation, le serveur ouvre un flux unidirectionnel propre à cet abonnement.

Le tuple probant comprend connexion, session, identifiant de flux, initiateur, direction, message-id ou identifiant d’abonnement et temps de vie. Le projet exige que les deux extrémités suivent l’association abonnement-flux mais laisse sa réalisation hors périmètre. Un journal qui garde « flux 19 » tout en perdant « abonnement 604 » a conservé le transport et perdu la provenance.

Ne pas inventer d’ordre entre les flux

L’ordre QUIC est interne à chaque flux. Un RPC et une notification sur deux flux différents avancent indépendamment. Leur ordre d’arrivée ne constitue pas une causalité garantie. De même, les limites des trames QUIC STREAM ne sont pas préservées pour l’application. Un chunk NETCONF n’est donc pas « une trame QUIC ».

RFC 6241 définit NETCONF. Le hello utilise le marqueur de fin de message ; après négociation de base:1.1, la proposition applique le mécanisme de chunks de RFC 6242, qui évite l’injection de l’ancien délimiteur. La preuve doit porter séparément sur les octets réassemblés, les longueurs de chunks et le message complet. Un parseur satisfait ne certifie ni le sens, ni l’autorisation, ni l’effet.

Garder <ok/> dans son périmètre

Le message-id relie une requête à sa réponse. rpc-error décrit une erreur ; <ok/> indique que l’opération de protocole n’a pas de données ou d’erreur à renvoyer. Ce reçu évite de confondre des RPC concurrents. Il ne sonde pas l’équipement.

Pour une édition ou un commit, le dossier doit lier le datastore cible, les options, le hash avant/après, l’identifiant de transaction et les erreurs ou retours en arrière ultérieurs. Sans cette matière, le reçu dit seulement que le serveur a rendu une décision de protocole.

Séparer permission, datastore et monde réel

NACM doit être enregistré au niveau de l’opération : principal, chemins visés, ensemble de règles effectif, règle correspondante, décision et version. Pour une notification absente, il faut pouvoir différencier absence d’événement, filtre, interdiction et panne de livraison.

RFC 8342 établit la distinction décisive entre configuration conventionnelle, intended et operational. Une ressource référencée peut manquer : l’intention subsiste alors que l’application n’apparaît pas dans l’état opérationnel. La lecture horodatée de cet état est un nouveau reçu. Les tables de routage, adjacences, compteurs et sondes actives en sont encore un autre.

Les notifications ont elles aussi besoin de leur contrat. RFC 8639 définit identifiant, destinataire, filtre et cycle de vie ; RFC 8641 ajoute les modes périodique et on-change, la temporisation et la synchronisation YANG-Push. Un flux intact peut transporter une vue filtrée, temporisée ou partielle. Il faut joindre l’identifiant d’abonnement, le datastore, le filtre, le déclencheur, le destinataire, la politique et les événements de fin.

Dix reçus plutôt qu’une certitude empruntée

La chaîne complète relie : ALPN négocié ; identité TLS ; nom NETCONF ; session ; flux et abonnement ; octets et framing ; RPC et relance ; décision NACM ; évolution des datastores ; observation indépendante de l’effet. Chaque reçu autorise une phrase précise. Aucun ne reçoit par voisinage le pouvoir de prouver le suivant.

Cette lecture rejoint la primauté du code en fonctionnement défendue par Heng Lu : le symbole décrit, l’exécution observée établit. Son modèle de spécification initiale minimale permet au socle commun de fixer l’interopérabilité sans centraliser les choix locaux de confiance et de résultat. Les couches de réalité expliquent le danger institutionnel : un reçu propre finit par acquérir l’autorité de la réalité qu’il représente.

La révision 11 trace de meilleurs couloirs. Sa réussite opérationnelle dépendra de la capacité des organisations à ne pas les fusionner dans un seul voyant vert. L’archive officielle de la révision conserve la limite de version utilisée ici.