Résumé

  • draft-fedyk-netmod-yang-normal-form-00 propose de garder la représentation lexicale d’origine tout en dérivant une forme déterministe pour l’égalité, les clés de liste et l’unicité des leaf-lists de configuration.
  • Dans l’exemple MAC, les séparateurs « : » ou « - » et les chiffres hexadécimaux en majuscules ou minuscules aboutissent à la même valeur de comparaison sur douze chiffres. Un pattern valide la syntaxe ; il ne définit pas l’égalité.
  • Datatracker classe le texte comme Internet-Draft individuel actif, sans statut RFC visé et à l’état IESG I-D Exists. L’en-tête du document dit pourtant Intended status: Standards Track. Ni adoption par NETMOD ni aval de l’IETF n’en découle.

L’écriture reste, la règle de comparaison change

L’IETF et l’IEEE peuvent exprimer la même adresse de 48 bits de deux façons. Le type YANG commun de l’IETF dans le RFC 6991, puis sa révision actuelle RFC 9911, emploie des octets séparés par des deux-points et décrit les minuscules comme forme canonique. Le type IEEE présenté dans les travaux IETF emploie des tirets et décrit les majuscules. Pour un lecteur, l’adresse est la même ; pour une clé de type string, les caractères restent différents.

La révision 00 sépare ces responsabilités. La valeur lexicale reçue reste disponible pour l’encodage et la restitution. Une extension optionnelle normalized-form désigne un algorithme déterministe dont le résultat sert à = et !=, à l’unicité des clés de liste et à celle des leaf-lists de configuration.

L’identité mac-48 commence par valider chaque entrée selon son type. Elle retire ensuite les séparateurs, met les chiffres hexadécimaux en majuscules et garde douze chiffres. aa:bb:cc:dd:ee:ff, AA:BB:CC:DD:EE:FF, aa-bb-cc-dd-ee-ff et AA-BB-CC-DD-EE-FF donnent ainsi AABBCCDDEEFF. Le projet affiche le résultat avec le préfixe 0x, mais l’identité à douze chiffres est la partie qui suit.

Élargir une expression régulière ne produit pas ce résultat. Dans le RFC 7950, pattern restreint les chaînes admises. La forme canonique du type string intégré est sa représentation lexicale, sans normalisation Unicode. Autoriser deux casses ou deux séparateurs ne dit donc rien au moteur de comparaison sur leur équivalence.

Deux moteurs peuvent compter deux nombres de doublons

Le mécanisme est explicitement optionnel. Une implémentation qui annonce le prendre en charge applique la forme normalisée. Une implémentation qui ne le prend pas en charge continue à traiter le type lexical. Le RFC 7950 autorise en effet l’ignorance complète d’une extension inconnue et impose le traitement conforme d’une extension prise en charge.

Imaginons que aa:bb:cc:dd:ee:ff existe déjà et que AA-BB-CC-DD-EE-FF arrive dans un autre nœud dont le type admet cette écriture. Le premier moteur peut refuser l’ajout comme duplication de la même clé normalisée. Le second peut encore voir deux chaînes. Cette divergence touche les comparaisons XPath, les listes indexées et les leaf-lists de configuration.

Un reçu de refus crédible doit donc conserver la révision du module, le nœud de schéma, le type de base, l’identité de normalisation, l’implémentation et sa version, la preuve de prise en charge ainsi que la valeur normalisée calculée. Deux chaînes et le mot « doublon » ne suffisent pas à reconstruire la décision.

Trois indications de statut doivent rester ensemble

La fiche Datatracker indique « Active Internet-Draft (individual) », aucun flux RFC, aucun statut RFC visé et I-D Exists. Elle rappelle aussi que n’importe qui peut soumettre un I-D et que celui-ci n’a ni aval de l’IETF ni position formelle dans le processus. Le corps immuable, lui, porte Intended status: Standards Track et une expiration au 2 janvier 2027.

L’en-tête exprime l’intention inscrite par les auteurs ; Datatracker décrit l’étape procédurale réelle. Même la mention « IETF NETMOD Working Group » dans le champ organization du module inclus ne prouve pas que le groupe de travail a adopté le document.

Les auteurs sont Don Fedyk, de LabN Consulting, et Scott Mansfield, d’Ericsson. Le profil de Fedyk recense 24 RFC ; celui de Mansfield en recense cinq et plusieurs fonctions de liaison IETF–UIT-T. Cette expérience justifie l’attention, pas une approbation institutionnelle.

Les diapositives NETMOD de l’IETF 124 montrent l’origine du choix. Elles comparaient les syntaxes IETF et IEEE et envisageaient une représentation unique, des patterns plus larges, une mécanique d’équivalence, un autre stockage ou l’inaction. La nouvelle révision retient une identité de comparaison distincte sans forcer la réécriture des valeurs.

Ce que prouve une égalité — et rien de plus

Une forme normalisée identique prouve que deux entrées admises ont passé la même transformation déclarée. Une égalité XPath documente la décision d’une implémentation dans un contexte de schéma donné. Un refus de doublon documente le déclenchement d’une contrainte locale.

Il ne prouve pas qu’il s’agit du même équipement réel, ni qu’un futur algorithme est sans collision, ni que deux produits l’implémentent pareil. Il ne prouve pas la prise en charge des deux côtés, l’identité du schéma ou de l’arbre XPath, la migration des données existantes, l’intention, l’autorisation, la déduplication du plan de transfert ou un résultat réseau.

La distinction avec une canonicalisation classique est essentielle. XDR impose une représentation externe unique. Ici, plusieurs écritures sont conservées et seule une identité parallèle gouverne certaines comparaisons. Le chargement du bon module et un diff de schéma restent nécessaires, mais ne prouvent pas que cet algorithme a été exécuté.

La question de contrôle est donc limitée : quelle trace établit que l’implémentation a comparé la valeur déclarée, et non la typographie de la chaîne ?