Résumé

  • draft-feng-netmod-naim-01 donne l’autorité au JSON canonique. La vue Markdown sert à la revue humaine et au retour contrôlé, tandis que la vue de contexte LLM est une projection volontairement incomplète.
  • Une validation de schéma, un aller-retour sans perte, une nouvelle tentative réussie ou un module YANG accepté attestent des contrôles précis. Aucun ne prouve seul que le besoin a été correctement élucidé, que le serveur l’implémente ou que le réseau produit l’effet attendu.

Le risque apparaît souvent lors d’une modification apparemment anodine. Un ingénieur change dans la vue Markdown « chemin de secours autorisé après panne ». La reconstruction du JSON est valide et le diff paraît propre. Mais la vue n’exposait peut-être ni la définition de la panne, ni une déviation du serveur, ni l’autorité qui permet l’action. La phrase a été transportée sans corruption ; son sens n’a pas été complété.

C’est le problème que tente d’encadrer la révision 01 de NAIM. Natural AI Interface Modeling propose une représentation sémantique intermédiaire entre des exigences en langage naturel et YANG. Le texte constate que la conversion directe force souvent l’outil à deviner : configuration ou état, clés de liste, expressions de contrainte, préconditions opérationnelles et relations entre modules.

Le statut du document borne toute lecture. Le Datatracker le présente comme un Internet-Draft individuel actif de Chong Feng, mis à jour le 18 juillet 2026, sans stream, sans intended RFC status enregistré et à l’état I-D Exists. L’en-tête du brouillon indique séparément « Intended status: Standards Track ». C’est l’objectif déclaré par l’auteur, non une adoption par NETMOD, une approbation de l’IETF ou un RFC. L’historique prouve une chronologie éditoriale, pas un déploiement.

Le JSON commande, les vues rendent des services différents

Dans la proposition, le Canonical JSON est la seule source normative du contenu NAIM. Les outils interopérables doivent le traiter comme tel. La vue Markdown doit être dérivée de façon déterministe pour la lecture, la discussion et le contrôle de version. Si une implémentation accepte ce Markdown comme entrée, les champs représentés doivent conserver leur sens lors du retour. Un champ existant uniquement dans le JSON ne peut pas être effacé silencieusement, et un conflit doit recevoir une résolution explicite.

Cette discipline crée un journal vérifiable : octets du JSON, version du schéma, identité du convertisseur, empreintes des deux sorties, liste des champs non représentés et décision prise pour chaque conflit. Dire simplement « round trip OK » masque le périmètre du test. Il faut savoir quels champs ont réellement participé à l’aller-retour.

La LLM Context View assume une autre fonction. Elle doit conserver noms, types sémantiques, caractère obligatoire, contraintes, possibilité d’écriture, conditions de visibilité, opérations, préconditions et effets de bord. Pour réduire le contexte, elle doit omettre la construction des requêtes NETCONF/RESTCONF, les métadonnées internes, le JSON Schema brut, les déclarations de déviation et les définitions d’extension. Elle n’est pas autorisée à reconstruire le JSON canonique.

La perte est donc voulue et documentée, mais pas universellement sans conséquence. Une déviation omise peut changer le schéma effectif du serveur ; un augment extérieur peut donner un autre sens à un chemin ; une information de transport peut être décisive au moment de l’exécution. Avant de donner cette vue à un modèle, il faut relier chaque omission à la tâche précise. L’économie de jetons n’est pas une preuve de suffisance.

Spécification, Skill et Tool ne possèdent pas la même autorité

NAIM sépare une couche Specification, qui définit le format et les règles de vue ; une couche Skill, qui contient les processus pilotés par l’IA ; et une couche Tool, composée de logiciels déterministes pour valider, convertir, extraire et générer. Les Skills A à D couvrent la modélisation conversationnelle, la synthèse, la génération YANG et l’ingénierie inverse.

Cette séparation permet de garder un format stable tout en remplaçant un modèle, un prompt ou une stratégie. Elle empêche aussi de confondre trois affirmations : « le fichier respecte la structure », « le modèle a proposé une interprétation » et « cette interprétation est exacte ». La première relève du Tool ; la seconde du Skill ; la troisième exige un responsable du schéma, le contexte complet et des essais.

La boucle Validation-Reflection-Retry illustre la limite. Après une erreur, le Tool produit un rapport structuré avec le chemin et la condition attendue. Le système peut le réinjecter dans le contexte puis recommencer. Un plafond de tentatives doit arrêter la boucle ; les défauts restants deviennent des questions ciblées et l’historique devrait être conservé.

Une réussite après correction démontre seulement que la nouvelle sortie passe les contrôles qui ont rejeté l’ancienne. Le modèle peut avoir supprimé un champ facultatif complexe, choisi une clé plausible ou relégué une condition irrésolue dans une description. L’audit doit conserver la consigne initiale, les questions posées, les hypothèses, les valeurs par défaut, les suppressions et les versions du Skill, du Tool et du schéma.

Après génération, RFC 7950 donne à YANG 1.1 une sémantique riche : must, when, leafref, augment, features et contraintes d’instance. Avec la fermeture exacte des modules, les features, les déviations et un corpus positif et négatif, un validateur fournit une preuve forte mais locale. Il ne sait pas si une condition naturelle est devenue le bon XPath, si le serveur cible possède l’augment attendu ni si l’utilisateur est autorisé. RFC 8407 apporte des pratiques de conception, pas une certification automatique.

RFC 8525 permet au serveur de publier sa YANG Library, ses ensembles de modules, features et déviations. Cette déclaration doit être jointe aux sources exactes, aux traces de résolution du client et à l’empreinte du schéma effectif. Puis RFC 8342 distingue l’état intended de l’état operational : accepter une configuration n’établit pas son application ni son effet réseau. Même RFC 8259 rappelle, par son objet limité, qu’un JSON valide ne dit rien de la justesse du monde décrit.

Le brouillon NAIM précise qu’il n’est ni un encodage JSON de YANG ni un remplacement de YANG. L’usage pour les intentions d’opération est renvoyé au brouillon séparé NAIM-OP. Le modèle, les prompts, le score de confiance et l’exécution restent hors périmètre.

Une revendication de production doit donc conserver la demande et ses incertitudes ; le JSON canonique exact ; les vues, omissions et conflits ; le YANG, sa fermeture et ses tests ; la déclaration serveur, la résolution client et l’autorisation ; enfin les observations intended, operational, de télémétrie et de retour arrière.

La notion de couche commune déterministe minimale de Lu Heng offre ici une grille utile : rendre la validité locale et auditable sans transformer une spécification en adoption. Ses textes sur la primauté du code exécuté et les couches de réalité aident BTW à distinguer document et effet. Nous utilisons cette grille ; nous n’affirmons pas que Lu Heng a évalué NAIM.

Sources