Résumé

  • La RFC 9890 actualise la formulation de la RFC 6020 sur l’enregistrement des noms de modules et de sous-modules YANG.
  • Les noms et espaces de noms XML des versions initiales restent uniques, tandis que les révisions ultérieures réutilisent le nom et l’espace de noms initiaux.
  • La procédure du registre IANA des noms de modules YANG fait autorité pour l’attribution des noms ; l’identité du registre ne constitue pas un inventaire de déploiement tenant compte des révisions.

La RFC 6020 indiquait que tous les noms de modules et de sous-modules, ainsi que tous les espaces de noms XML du registre, devaient être uniques. La RFC 9890 précise que cette formulation ne correspondait pas à la pratique d’IANA pour les révisions. Avec la règle actualisée, l’unicité porte sur la version initiale : le nom initial d’un module ou d’un sous-module reste unique, et l’espace de noms XML initial d’un module reste unique. Chaque révision ultérieure conserve le nom initial et le même espace de noms XML.

Cette continuité est intentionnelle. Un consommateur peut reconnaître la famille du module sans considérer chaque révision comme une nouvelle identité enregistrée. La frontière devient toutefois opérationnelle : une recherche par nom ou par espace de noms indique l’identité enregistrée ; elle ne dit pas, sans métadonnées de révision et sans l’artefact approprié, quelle révision est installée, validée ou sûre à restaurer. Elle ne démontre pas non plus la compatibilité sémantique de révisions successives.

IANA cite la RFC 9890 comme référence supplémentaire, car sa procédure fait autorité pour attribuer les noms dans le registre des noms de modules YANG. L’instantané IANA gelé est une preuve de l’état du registre observé le 2026-09-05, non une preuve de la qualité d’une implémentation, de l’adoption par les opérateurs, de la compatibilité des outils ou de la correction d’une révision particulière.

Analyse de Theo March — et non exigence de la RFC 9890 : traiter un nom stable comme une clé complète de déploiement crée une ambiguïté d’identité. Dans l’automatisation, cette ambiguïté peut produire une dérive d’inventaire : la fiche désigne la bonne famille de modules, alors que la validation et le déploiement ont utilisé des révisions différentes. Le contrôle pratique consiste à conserver, avec le nom et l’espace de noms stables, l’identifiant de révision, l’artefact source ou son condensat, le résultat de validation et la cible de retour arrière.

Fixtures de vérification

Une fixture minimale doit contenir : le nom example-module, l’espace de noms XML urn:example:module, la révision initiale 2024-01-01, la révision ultérieure 2025-06-01, le résultat de recherche dans le registre, l’artefact exactement validé et l’artefact conservé pour le retour arrière. Vérifier que les deux révisions gardent le même nom et le même espace de noms, puis vérifier que l’inventaire distingue leurs dates ou métadonnées de révision équivalentes. Une seconde fixture doit omettre volontairement les métadonnées de révision. Le résultat attendu est un échec du contrôle, et non l’inférence d’une équivalence. Ces tests opérationnels sont proposés dans ce briefing, pas imposés par la RFC 9890.

Parcours de décision de l’opérateur

  1. Résoudre le nom et l’espace de noms enregistrés selon la procédure faisant autorité.
  2. Récupérer et consigner les métadonnées exactes de révision et l’artefact utilisé pour la validation.
  3. Comparer la révision déployée avec la révision validée avant l’activation.
  4. Conserver une cible de retour arrière propre à la révision et la preuve de sa conservation.
  5. Si l’identité de révision manque, suspendre la promotion ou le retour arrière ; ne pas déduire la compatibilité de la seule identité du registre.

L’ensemble de preuves ne mesure pas le nombre d’outils ayant supposé des noms globalement uniques pour toutes les révisions. Aucun incident opérateur, échec d’interopérabilité ou coût de migration n’est établi. La RFC 9890 ne valide pas la compatibilité sémantique des révisions successives. L’instantané IANA peut changer après l’observation. Le support des fournisseurs et la prévalence des déploiements sont hors du périmètre des sources.

Sources

La RFC 9890 indique que cette modification aligne la politique sur la pratique existante du registre et n’introduit ni nouvelles opérations ni nouvelles exigences de gestion. Elle indique aussi qu’aucun risque de sécurité nouveau ou accru ne nécessitant une discussion n’est introduit.