Résumé

  • Les deux projets déconseillent de rejeter une RPC pour la seule raison que son contexte de trace est invalide ; l’exemple RESTCONF crée même la ressource et répond 201 Created sous une nouvelle trace non échantillonnée.
  • Continuer l’opération protège le plan de gestion, mais coupe la filiation observable : l’ancienne trace ne prouve pas l’échec, la nouvelle ne reconstitue pas le passé.
  • Il faut un reçu de raccordement indépendant reliant requête authentifiée, décision de traitement de la trace, réponse protocolaire, état relu et effet observé.

Deux succès qui ne parlent pas de la même chose

Dans un système distribué, la phrase « l’opération a réussi » est incomplète. Le serveur RESTCONF peut avoir créé la ressource. Le collecteur peut avoir reçu une trace. Le contrôleur peut avoir relu la configuration. Le service peut fonctionner. Ces quatre résultats sont liés, mais aucun ne contient automatiquement les trois autres.

Le projet draft-ietf-netconf-restconf-trace-ctx-headers-11 rend cette séparation visible dans un exemple particulièrement utile. Une requête porte un traceparent d’une version que le serveur ne sait pas interpréter et un tracestate mal formé. Le serveur répond pourtant 201 Created. Il renvoie un nouveau traceparent de version 00, avec les indicateurs de trace à zéro, et supprime tracestate.

La configuration n’est donc pas sacrifiée à son instrument d’observation. Mais sa généalogie distribuée est interrompue. La ressource créée appartient à la réalité opérationnelle ; l’identifiant initial appartient à une histoire devenue incomplète.

Ce choix est cohérent avec les deux projets du groupe NETCONF. Tous deux indiquent qu’il n’est pas recommandé de refuser une RPC à cause des valeurs de Trace Context. Si un serveur choisit malgré tout le refus, il doit émettre une erreur protocolaire operation-failed. Le standard en préparation ne gomme pas la décision locale : il exige qu’elle devienne interprétable.

La trace n’est ni la commande ni la preuve finale

Le W3C a défini traceparent pour transporter l’identité et la filiation d’une trace, et tracestate pour un contexte opaque propre aux fournisseurs. Le projet NETCONF adapte ces informations à des attributs XML ; le projet RESTCONF les conserve dans les en-têtes HTTP.

Le texte NETCONF précise que ce contexte n’est pas lié aux données transportées par l’opération : ni configuration, ni identifiant de service, ni état. Cette limite interdit une confusion fréquente. Un identifiant de trace peut aider à retrouver des observations ; il ne décrit pas l’objet modifié et ne certifie pas l’autorité de celui qui l’a modifié.

L’authentification mutuelle protège le canal. NACM porte une décision d’accès. Le message-id NETCONF corrèle une réponse à une RPC sur la session. Le code HTTP et l’URI de ressource décrivent la réponse RESTCONF. Une relecture montre ce que le serveur expose à un instant donné. Une mesure du service observe un résultat. La trace peut relier ces éléments, mais ne doit pas emprunter leur portée.

Lorsqu’un traceparent valide manque, le modèle W3C permet de créer un nouvel identifiant. Un tracestate isolé doit être éliminé. Cette règle évite de propager un contexte opaque sans racine valable. Elle produit cependant deux univers : avant la frontière, l’ancienne trace ; après elle, une nouvelle trace localement cohérente. Rien dans le nouveau numéro ne démontre à lui seul que les deux univers correspondent à la même intention.

Le coût caché d’un traitement tolérant

Le traitement tolérant protège la disponibilité du plan de gestion. Il protège aussi contre un pouvoir excessif donné à un en-tête auxiliaire : un appelant ne devrait pas pouvoir bloquer toute configuration en envoyant volontairement un contexte de trace défectueux.

Cette tolérance doit néanmoins être comptabilisée. Sans reçu, trois erreurs de gouvernance deviennent probables.

Premièrement, l’équipe d’exploitation assimile l’absence de span à l’absence d’action. Elle relance une écriture qui a déjà créé la ressource. Deuxièmement, l’équipe d’audit rapproche la commande du mauvais événement, car l’identifiant a changé sans table de correspondance. Troisièmement, l’organisation transforme le collecteur de traces en registre principal, alors que l’échantillonnage, la protection de la vie privée ou une migration de fournisseur peuvent légitimement couper la continuité.

Trace Context est lui-même une entrée non fiable. Le W3C décrit les risques de fuite d’information, de collisions forgées et de coûts d’échantillonnage imposés. Le projet NETCONF rappelle que la corrélation peut aider à cartographier un réseau administré. Redémarrer ou nettoyer une trace à une frontière de confiance peut donc être une mesure de sécurité, et non une panne.

La bonne exigence n’est pas « ne jamais couper ». Elle est « ne jamais couper sans rendre la coupure explicite dans un registre qui ne dépend pas de la trace ».

Le reçu de raccordement

À l’entrée, le système conserve l’identité authentifiée, la politique d’autorisation appliquée et une empreinte de la requête de gestion. Il note ensuite le sort du contexte : accepté, absent, réinitialisé ou refusé. En cas de réinitialisation, il associe le nouvel identifiant à la requête locale, sans promouvoir le tracestate fourni par l’appelant au rang de vérité.

La chaîne continue avec la réponse NETCONF ou RESTCONF, l’URI de ressource, l’ETag éventuel, le reçu de transaction ou de datastore, puis une relecture à une époque nommée. Enfin vient l’observation du service depuis un point indépendant du chemin d’écriture.

Ce modèle permet une conclusion précise. Une trace interrompue signale une limite d’observation. Une erreur operation-failed signale un refus protocolaire. Un 201 signale ce que le serveur RESTCONF affirme avoir créé. Une relecture et une mesure apportent d’autres preuves. Aucune couche ne se substitue aux autres.

Des projets, pas un déploiement prouvé

Les révisions 09 et 11 datent du 17 septembre 2026. Ce sont des Internet-Drafts actifs destinés au niveau Proposed Standard, non des RFC finales. Leur présence dans YANG Library ne prouve ni l’export de chaque span, ni la réception par un collecteur, ni l’existence d’un mécanisme de raccordement chez un fournisseur.

Leur apport est plus sobre et plus important : ils normalisent la possibilité que l’observation échoue sans que l’opération échoue. À l’entreprise de construire la preuve qui survivra à cette divergence.

Sources