Résumé

  • draft-ietf-netconf-error-registries-00 propose deux registres IANA pour les balises et identités d’erreur YANG ; cette révision initiale reste incomplète et ne transforme pas un nom en diagnostic causal.
  • Une automatisation responsable doit garder la session, l’opération, le demandeur, la décision d’accès, le chemin visé, l’identité qualifiée par son module, les indications structurées, le résultat de transaction et la vérification du service.

La machine lit invalid-value et croit tenir une cause.

Elle tient en réalité une catégorie d’échange. Avec RESTCONF, cette même balise peut accompagner les codes HTTP 400, 404 ou 406. Dans certaines situations d’accès, le serveur peut répondre 404 avec invalid-value afin de ne pas révéler l’existence d’une ressource protégée. Le message est conforme précisément parce qu’il ne livre pas toute la réalité.

C’est la frontière que rend visible draft-ietf-netconf-error-registries-00, publié le 30 septembre 2026. Ce document actif du groupe NETCONF propose une « YANG Protocol Error List » et un registre des identités d’erreur. L’objectif est utile : éviter que chaque implémentation reconstitue une nomenclature à partir d’une collection croissante de RFC.

La révision 00 vise le Standards Track et expire le 3 avril 2027. Ce n’est ni une RFC, ni un registre IANA approuvé, ni une preuve de déploiement. Ses cinq pages ouvrent un chantier de gouvernance ; elles ne le clôturent pas.

Le premier registre doit contenir la balise, le type, la gravité, les informations auxiliaires, une description et la référence qui enregistre la valeur. Le second doit consigner le nom d’identité, son identité de base, des informations complémentaires et la référence. La politique annoncée est l’IETF Review.

Centraliser ces éléments réduit les variantes orthographiques, rend les ajouts découvrables et permet de voir qui possède la définition. Un registre peut aussi donner un cycle de vie : entrée active, remplacement, dépréciation, référence courante. C’est un progrès de coordination réel.

La première version montre cependant les conditions de ce progrès. Les descriptions d’error-tag, error-type et error-severity sont encore TBD. Le texte affirme reprendre le contenu initial de l’annexe A de la RFC 6241, mais n’insère que cinq balises : in-use, invalid-value, too-big, missing-attribute et bad-attribute. L’annexe en contient bien d’autres, notamment access-denied, resource-denied, rollback-failed, data-missing, operation-not-supported, operation-failed et malformed-message.

La liste des identités porte elle aussi la marque d’un premier jet. filter-unsupported, insufficient-resources et no-such-subscription y apparaissent plusieurs fois. Des identités des RFC citées n’y figurent pas : stream-unavailable, suspension-timeout et unsupportable-volume dans la RFC 8639 ; cant-exclude, no-such-subscription-resync, on-change-unsupported, on-change-sync-unsupported et sync-too-big dans la RFC 8641. La référence de procédure est la RFC 5226, alors que la RFC 8126 l’a remplacée.

Il serait excessif d’en déduire un défaut définitif. La conclusion exacte est plus modeste : la révision 00 doit encore rendre son inventaire unique, complet et actuel. Tant que ce travail n’est pas fait, une application ne doit pas combler les trous par un tableau privé qui recréerait la dispersion que le projet veut éliminer.

Même un registre parfait ne raconterait toutefois pas l’incident.

La RFC 6241 prévoit qu’une réponse NETCONF puisse porter plusieurs éléments <rpc-error>. Chacun peut préciser la couche conceptuelle, la balise de protocole, la gravité, une balise applicative définie par le modèle, le chemin XPath concerné, un message et des informations structurées. Ces dimensions ne sont pas des ornements. Elles séparent la classe générale, le modèle qui l’affine et l’objet exact auquel elle s’applique.

La RFC 8640 le montre pour les abonnements. filter-unsupported devient la balise générale invalid-value. insufficient-resources devient resource-denied. on-change-unsupported devient operation-not-supported. sync-too-big devient too-big. unchanging-selection devient operation-failed. L’identité précise est transportée dans error-app-tag avec son module, par exemple ietf-subscribed-notifications:no-such-subscription.

Le module ne suffit pas non plus. L’identité de base admissible dépend de la RPC qui a échoué : établir, modifier, supprimer, tuer ou resynchroniser un abonnement. Lors d’un établissement ou d’une modification, error-info peut fournir des paramètres susceptibles de rendre un nouvel essai acceptable. Retirer l’opération et ces indications transforme une réponse structurée en étiquette pauvre.

Prenons unchanging-selection. La RFC 8641 autorise ce motif lorsqu’une sélection vise des données inexistantes ou des données que le destinataire ne peut pas lire. Le même motif peut suivre un changement d’autorisation qui rend les mises à jour invisibles. Corriger un chemin, demander un droit et reconstruire un filtrage sont trois gestes différents. Le protocole les regroupe pour préserver l’abstraction et éviter les fuites. Déduire une seule cause cachée serait une faute, pas une sophistication.

no-such-subscription protège la même frontière. Selon la RFC 8639, l’identifiant peut ne pas exister, appartenir à un autre abonné ou viser un abonnement configuré auquel la RPC ne s’applique pas. Le serveur dit ce que le demandeur a besoin de savoir — l’action n’est pas possible — sans lui offrir une vue du registre interne.

insufficient-resources est une autre compression légitime. Le serveur ne peut pas produire l’abonnement demandé. Le mot ne révèle ni la mémoire, ni le débit, ni la file, ni le processeur, ni le quota en cause. Il ne dit pas quand la capacité reviendra, quelle charge doit céder ou quel responsable peut arbitrer.

Le registre fait donc autorité sur le nom ; il ne fait pas autorité sur l’événement.

Un reçu exploitable commence avant l’erreur. Il conserve le protocole et la session, la RPC, l’identifiant de requête, le principal authentifié et la décision d’autorisation. Il ajoute le datastore et le chemin, la balise générale, l’identité qualifiée, sa base, les données d’error-info, la version du serveur et des modules, puis le résultat de transaction. Après correction, il consigne le changement autorisé, la relecture de l’état et le résultat réellement observé par le service.

Cette chaîne évite quatre raccourcis. Un 404 ne prouve pas l’absence. Une identité d’application ne prouve pas la cause physique. Un nouvel appel accepté ne prouve pas une mutation. Une mutation confirmée ne prouve pas que le service attendu fonctionne.

Le principe de spécification initiale minimale de Heng Lu éclaire la répartition. L’IETF peut définir le vocabulaire interopérable le plus petit et la procédure d’extension. L’acteur qui dispose plus tard des faits locaux — serveur, équipe réseau, propriétaire du service — garde la décision de correction. Le registre coordonne les mots ; il ne confisque pas le jugement futur.

La distinction entre couches de réalité est tout aussi décisive. operation-failed est un symbole valide. Le nœud absent, le droit révoqué, la capacité épuisée ou le paramètre impossible sont des réalités distinctes. Le symbole peut intentionnellement les couvrir ensemble. La clarté consiste à préserver cette incertitude, non à la remplir d’une certitude inventée.

Enfin, la primauté du code en fonctionnement impose un reçu après l’action. Modifier une valeur ou relancer une RPC ne suffit pas. Il faut relire l’état et observer le service. Sans ce dernier passage, l’organisation ne sait que nommer l’erreur et le geste ; elle ne sait pas si le monde a changé.

Sources