Résumé

  • La configuration explicite hors modèle l’emporte ; entre ancêtres, l’application la plus proche du nœud l’emporte ; au même emplacement, le premier modèle applicable de la liste fournie par le client est prioritaire.
  • Une reproduction sérieuse exige les instantanés complets de running et system, les définitions, les emplacements, l’ordre, les clés évaluées par I-Regexp et les dérogations explicites. Elle ne prouve ni l’auteur de l’entrée, ni l’absence de course, ni NACM, ni l’exécution ou le service.

Un conflit d’héritage paraît simple après coup : deux modèles proposent une valeur, l’un gagne. Mais, dans draft-tt-netmod-yang-config-templates-03, le vainqueur dépend de trois informations différentes. En perdre une seule revient à conserver le résultat tout en jetant la règle qui l’explique.

La première information est la nature de la valeur. Une configuration ordinaire, écrite explicitement dans running ou system, a la priorité la plus élevée. Le modèle peut fournir un contenu réutilisable ; l’opérateur garde le dernier mot par une valeur explicite. Il peut la remplacer, mais ne peut pas supprimer un nœud hérité comme si le modèle n’existait plus.

La deuxième information est la distance. Une application placée sur l’ancêtre interne, le plus proche de la cible, prévaut sur celle d’un ancêtre externe. Une archive qui retient seulement les noms des modèles, sans leur chemin exact dans l’arbre, ne permet donc pas de rejouer le calcul.

La troisième est l’ordre au même nœud. Le client transmet une liste ordonnée. Dans l’exemple Ethernet, ethernet-interface précède base-interface ; sa valeur MTU 1500 gagne sur 65536 pour les entrées correspondantes. Le sens est essentiel : le premier modèle applicable a la priorité. Une collection non ordonnée de noms falsifie l’intrant.

Cette liste est remplacée en bloc lorsqu’une valeur non vide est envoyée. Une valeur vide ou composée d’espaces retire l’application ; l’absence de la métadonnée conserve l’état précédent. Un journal qui ne note que « ajout » et « retrait » peut manquer la valeur complète soumise par le client.

La correspondance est aussi un état

Le projet autorise des expressions régulières sur les clés de liste dont le type intégré est string, ou en dérive. Il s’appuie sur I-Regexp de la RFC 9485, sous-ensemble volontairement limité des expressions XML Schema. Cette limitation réduit les surprises entre implémentations ; elle ne dispense pas de conserver la version de la règle, son interprétation et les clés concrètes disponibles au moment du calcul.

Le motif eth.* ne constitue pas, seul, la liste des interfaces ciblées. Une interface renommée, une entrée issue de system absente de la capture ou un instantané pris quelques secondes plus tard modifie l’ensemble correspondant. Il faut préserver le motif et son domaine d’évaluation.

Les modèles peuvent être partiels. Le serveur devrait les valider lorsque c’est possible, mais c’est le résultat fusionné qui doit satisfaire les contraintes YANG applicables. La page Datatracker affiche actuellement zéro erreur et zéro avertissement pour le contrôle de l’extrait ietf-config-template (revision 2026-07-03). C’est un reçu d’outil sur un module extrait, pas une adoption par NETMOD, une approbation de l’IETF ou un test de serveur.

« Intended » montre une sortie, pas toute son histoire

Dans l’architecture NMDA, running conserve la représentation compacte : définitions, métadonnées d’application et valeurs explicites. L’arbre transformé apparaît dans intended. Une modification d’un modèle appliqué dans running ou system doit y être répercutée.

La suppression impose une discipline particulière. Un modèle encore référencé doit être refusé avec data-missing ; il faut d’abord mettre à jour toutes les applications, puis supprimer la définition. Ce séquencement ne garantit toutefois pas une opération atomique. Entre l’inventaire et la suppression, un autre client peut modifier une référence. Le verrou, la transaction ou la procédure de maintenance appartient à l’implémentation et doit être observé séparément.

Une lecture de intended ne permet pas davantage de retrouver univoquement la commande initiale. Des définitions différentes masquées par une même valeur explicite peuvent aboutir au même arbre. Une inversion d’ordre sans conflit visible aussi. Le résultat prouve une observation ; il n’archive pas automatiquement les causes.

Le dossier minimal d’une reproduction

Pour comparer un développement hors équipement au serveur, il faut figer une expérience : version exacte du projet et des règles ; identités des deux implémentations ; instantanés complets et contemporains de running et system ; toutes les définitions ; chemins et profondeur d’application ; listes ordonnées ; sémantique I-Regexp et clés candidates ; valeurs explicites ; relation temporelle ou numéro de version qui lie les éléments.

Le hachage doit porter sur ce dossier complet. Une égalité entre l’expansion hors équipement et la lecture intended prouve que deux calculateurs ont produit le même résultat pour ces intrants. Elle ne démontre pas l’identité de tous les serveurs, la correction de l’autorisation ou l’application effective.

NETCONF et RESTCONF apportent leurs propres reçus de requête et de ressource. La RFC 8341 place NACM sur une surface indépendante : il faut tester chaque rôle, y compris les vues filtrées. La RFC 8342 distingue ensuite intended de operational ; une limite de ressources peut empêcher l’application. Et même operational ne prouve pas la programmation FIB, le passage des paquets ou l’effet sur le service.

Ne pas résumer le statut

Le texte est daté du 3 juillet 2026. Son en-tête porte « Intended status: Standards Track ». Le Datatracker le décrit séparément comme un Internet-Draft individuel actif, sans stream, sans intended RFC status, avec l’état I-D Exists. La formulation fidèle conserve les deux champs. Elle ne les transforme ni en adoption de groupe de travail, ni en statut RFC.

Sources

Sources primaires : révision 03 ; fiche Datatracker ; YANG 1.1, RFC 7950 ; métadonnées YANG, RFC 7952 ; NMDA, RFC 8342 ; NACM, RFC 8341 ; NETCONF, RFC 6241 ; RESTCONF, RFC 8040 ; I-Regexp, RFC 9485. Chronologie : historique Datatracker. Sources de cadrage : System Configuration révision 20 ; Lu Heng sur la primauté du code en exécution, la spécification initiale minimale et les couches de réalité.