Résumé

  • La RFC 6020 exigeait que tous les noms de modules et sous-modules YANG, ainsi que tous les espaces de noms XML du registre, soient uniques. La pratique de l’IANA conservait pourtant le même nom et le même espace de noms pour les révisions successives.
  • La RFC 9890, dont Qin Wu fait partie des trois auteurs, limite l’unicité à la version initiale et impose aux révisions de garder le nom d’origine ainsi que, pour les modules, l’espace de noms XML d’origine.
  • Une identité stable n’efface pas les différences de contenu. Date de révision, octets du fichier, choix d’importation, validation logicielle et observation en production restent des preuves distinctes.

Le registre YANG de l’IANA livre un exemple presque trop net. Au 1er septembre 2026, ietf-yang-types y figurait pour trois dates : 24 septembre 2010, 15 juillet 2013 et 22 décembre 2025. Les fichiers et les RFC de référence différaient. Le nom du module et l’espace de noms XML, eux, restaient identiques.

Ce tableau était incompatible avec une lecture littérale de la RFC 6020. Sa section 14 demandait l’unicité de tous les noms présents dans le registre et de tous les espaces de noms. Or l’IANA ne traitait pas chaque révision comme la naissance d’un nouveau module. Elle maintenait l’histoire éditoriale d’une même identité.

Publiée en octobre 2025, la RFC 9890 a nommé le problème au lieu de le masquer. Andy Bierman, Mohamed Boucadair et Qin Wu ont remplacé la règle trop générale par une frontière plus juste : l’attribution initiale est unique ; la révision prolonge cette attribution.

L’unicité ne vaut qu’après avoir nommé l’événement

Une chaîne identique n’est pas toujours un doublon. Lors d’une première attribution, elle peut signaler une collision. Lors d’une révision, elle peut au contraire prouver que la continuité a été préservée. Un contrôle automatique qui ignore le type d’événement ne protège pas le registre ; il confond sa propreté visuelle avec sa fonction.

La nouvelle formulation distingue quatre obligations. Les noms initiaux des modules et sous-modules doivent être uniques. Les espaces de noms XML des modules initiaux doivent l’être également. Toute révision de module ou de sous-module conserve le nom initial. Toute révision de module conserve l’espace de noms XML initial.

Les deux premières obligations empêchent deux lignées indépendantes de revendiquer le même identifiant public. Les deux suivantes empêchent une même lignée d’être rebaptisée à chaque changement. La coordination minimale a besoin de ces deux protections, pas d’un seul compteur de chaînes.

Le dossier de preuve doit donc inclure le statut « initial » ou « révision », la date, le document d’autorité, le nom et l’espace de noms. Sans ces éléments, une opération de déduplication peut supprimer une révision valable ou tolérer une véritable collision en la prenant pour une continuité.

Garder le nom ne veut pas dire garder la définition

L’erreur inverse serait de croire que deux révisions portant le même nom sont substituables. La RFC 7950 organise précisément la différence entre identité et contenu.

Dans YANG 1.1, les déclarations revision forment l’histoire éditoriale du module. Leur argument est une date. Chaque modification éditoriale publiée devrait ajouter une nouvelle déclaration en tête d’une séquence chronologique inversée. Le format de fichier recommandé associe le nom stable à un suffixe facultatif @date-de-révision.

Le nom répond à la question « de quelle lignée s’agit-il ? ». La date répond à la question « quel état de cette lignée ? ». Supprimer l’un ou l’autre produit une ambiguïté différente.

Cette différence atteint directement les importations. Avec revision-date, le module importateur demande la révision indiquée ; une date inexistante constitue une erreur. Sans cette précision, la RFC 7950 dit qu’on ne sait pas quelle révision est utilisée. Plusieurs révisions d’un même module peuvent même être importées si des préfixes différents les distinguent.

L’espace de noms commun n’est donc ni un certificat de compatibilité ni une consigne de mise à jour. Il maintient la référence publique ; les outils, les paquets et les opérateurs doivent encore établir quel contenu a été choisi et ce qu’il produit.

La date ouvre la piste, le condensat identifie les octets

Les trois lignes ietf-yang-types illustrent une chaîne correcte. La révision de 2010 renvoie à la RFC 6021, celle de 2013 à la RFC 6991, celle de 2025 à la RFC 9911. La continuité se lit dans le nom et l’espace de noms ; la variation se lit dans la date, le fichier et la référence.

Un inventaire qui ne conserve que le nom écrase trois états éditoriaux. Un inventaire qui fabrique des noms v1, v2 ou v3 rompt avec les identités effectivement enregistrées. Il faut conserver les deux axes sans les fusionner.

Pour la production, la date ne suffit pas. Il faut joindre le condensat du fichier, sa source, la version du paquet ou du micrologiciel, le parseur, le résultat de validation, l’environnement de test et l’instance déployée. Une date sélectionne une intention ; un condensat fixe les octets ; un manifeste dit ce qui a été livré ; un essai décrit ce qui a été accepté ; l’observation décrit ce qui a réellement fonctionné.

Cette granularité rend les écarts attribuables. Même date et condensats différents : problème d’approvisionnement ou d’emballage. Même révision, résultats de parseurs différents : problème d’implémentation. Validation réussie mais absence en production : la preuve de laboratoire ne devient pas un fait de déploiement.

Le registre gagne en légitimité lorsqu’il reste étroit

La RFC 9890 devient une référence d’autorité pour l’attribution des noms dans le registre. Elle précise pourtant qu’elle ne crée aucune nouvelle exigence opérationnelle ou de gestion, ni aucun risque de sécurité nouveau ou accru.

Cette modestie définit la bonne surface de contrôle. L’IANA peut empêcher une collision initiale et rattacher une révision datée à une lignée. Elle ne certifie ni la qualité du modèle YANG, ni le comportement d’un parseur, ni la compatibilité de deux versions, ni l’opportunité d’un déploiement.

La doctrine de spécification initiale minimale de Heng Lu s’applique sans forcer l’analogie. Les participants ont besoin d’une réponse commune sur le nom et l’espace de noms, car deux attributions initiales concurrentes casseraient les références. Ils n’ont pas besoin que le registre décide du calendrier de mise à niveau, de l’assemblage logiciel ou du risque acceptable pour chaque réseau.

Une révision enregistrée reste une possibilité publique, non un ordre universel. Les décisions futures demeurent locales : l’auteur modifie le texte, le fournisseur l’intègre, l’outil le sélectionne, l’opérateur le teste puis l’adopte ou le refuse.

Le nom de Qin Wu atteste une source, pas une autorité d’exploitation

La RFC 9890 inscrit Qin Wu, de Huawei, dans son équipe d’auteurs avec Andy Bierman et Mohamed Boucadair. Le profil officiel de l’IETF Datatracker rattache de nombreux autres RFC à la même identité. Ces éléments donnent un contexte solide au travail de normalisation.

Ils ne font pas de Qin Wu le propriétaire de la règle. La RFC relève du processus de l’IETF ; l’IANA tient le registre ; les équipes de spécification produisent les révisions ; les éditeurs de logiciels les implémentent ; les opérateurs décident du passage en production.

Conserver cette répartition évite d’attribuer une panne au mauvais acteur. Une erreur de registre appartient au processus d’enregistrement. Une divergence de parseur appartient à l’implémentation. Une migration insuffisamment testée appartient à la décision de déploiement. Le crédit d’auteur renseigne la provenance du document ; il ne transporte pas la responsabilité de tous les systèmes qui le citent.

La contribution est d’autant plus importante qu’elle est limitée : le texte cesse de contredire une pratique stable, tout en laissant les choix techniques et opérationnels à ceux qui les contrôlent.

Quand la pratique corrige le texte, elle doit encore prouver sa fonction

La primauté du code en fonctionnement n’absout pas toutes les pratiques. Un comportement largement déployé peut être dangereux. Une convention commode peut nuire à l’interopérabilité. La question n’est pas « cela existe-t-il ? », mais « cela protège-t-il la propriété pour laquelle la règle commune a été créée ? ».

Ici, la réponse est positive. Réutiliser le nom et l’espace de noms pour une révision ne compromet pas l’unicité de l’attribution initiale. Cela évite au contraire de créer de fausses identités à chaque changement et préserve les références des outils et des utilisateurs.

La manière de corriger compte également. La RFC 9890 reproduit l’ancien texte, décrit l’écart avec la pratique, publie le nouveau texte et identifie le registre concerné. La modification est auditable. Elle ne se cache pas derrière une interprétation rétroactive.

Une norme reste crédible lorsqu’elle sait reconnaître qu’un usage durable a révélé la mauvaise abstraction. Elle perdrait cette crédibilité si elle obligeait le système réel à se briser pour sauver une phrase trop large.

Construire un reçu de révision utilisable après la prochaine mise à jour

Le premier bloc décrit l’attribution initiale : nom, espace de noms, document d’autorité, date d’enregistrement et statut explicite de version initiale. C’est sur ce bloc que s’applique le contrôle d’unicité.

Chaque révision reprend ces champs d’identité et ajoute sa date, l’URL exacte, le condensat, la RFC source et le prédécesseur. Le reçu indique aussi si l’outil a choisi la révision explicitement ou s’il a laissé le choix indéfini.

Le bloc logiciel contient le parseur, sa version, le graphe d’importation, les fonctions activées, les déviations, le paquet livré et la validation. Le bloc opérationnel ajoute l’approbation, le périmètre du déploiement, les erreurs observées et la capacité de retour arrière.

Les verbes du tableau de bord doivent rester séparés : l’IANA enregistre, la RFC spécifie, le paquet contient, le parseur accepte, le fournisseur prend en charge, l’opérateur déploie, le service continue ou échoue. Une étape verte ne parle jamais au nom de la suivante.

Sources