Résumé

  • La RFC 9907 est la Best Current Practice 216, publiée en mars 2026. Elle rend obsolète la RFC 8407 et met à jour la RFC 8126. Elle guide les auteurs et réviseurs de spécifications contenant des modèles de données YANG, notamment les modules gérés par l’IANA.
  • Son mécanisme est éditorial mais ses effets visés sont opérationnels : délimiteurs de composants de code, noms uniques, en-têtes complets, traçabilité des révisions vers les RFC, sémantique explicite des datastores, exemples, analyse de sécurité et procédures de registre.
  • Il ne s’agit pas d’une modification du protocole filaire et la RFC ne garantit pas l’interopérabilité des implémentations. Il s’agit d’une discipline de processus destinée à accroître l’interopérabilité et l’utilisabilité de NETCONF et RESTCONF.

Un modèle de données YANG décrit conceptuellement les informations de gestion et leurs relations. Un module individuel est une réalisation de ce modèle dans le langage YANG ; ces deux notions ne doivent pas être confondues. Cette distinction devient importante lorsque le réviseur examine le code extrait, les importations, les révisions, les exemples et le texte qui les entoure.

La RFC 9907 considère les modules et sous-modules YANG normatifs comme des composants de code. Ils doivent être encadrés par les balises CODE BEGINS et CODE ENDS. Les noms publiés doivent être uniques : les modules IETF normatifs commencent par ietf-, tandis que les modules d’exemple devraient utiliser example-. Ces contrôles identifient le composant faisant autorité et limitent les confusions entre exigence normative et illustration.

L’en-tête du module n’est pas décoratif. Il doit contenir la déclaration actuelle de copyright de l’IETF Trust et identifier le registre YANG Parameters. Les références qui ne proviennent pas de modules importés doivent figurer dans des instructions reference. Chaque révision publiée doit comporter une déclaration dont la référence identifie le document contenant le module. Le code extrait devient ainsi un artefact vérifiable, et non un fragment orphelin.

La revue doit aussi dépasser la syntaxe. YANG 1.1 fournit les règles du langage ; l’architecture NMDA fournit la terminologie des datastores et le contexte de l’état opérationnel. Les auteurs doivent préciser ce qui relève de chaque datastore, le rapport entre configuration et état, ainsi que le sens opérationnel et le cycle de vie des nœuds. Une analyse syntaxique réussie ne tranche pas une frontière d’autorité absente.

Les exemples servent la revue mais ne sont pas des modules normatifs. Ils doivent éclairer la structure attendue sans être présentés comme des exigences d’implémentation. Le document doit également analyser les conséquences de sécurité, y compris l’exposition de gestion créée par les données et actions modélisées. Pour un module géré par l’IANA, une procédure explicite de registre est nécessaire : l’autorité appartient à cette procédure, pas à une modification ad hoc du texte de module généré.

Checklist de revue avant publication

  1. Chaque module et sous-module normatif est-il encadré par CODE BEGINS et CODE ENDS ?
  2. Les noms publiés sont-ils uniques, avec ietf- pour les modules IETF normatifs et example- pour les exemples ?
  3. L’en-tête contient-il la déclaration actuelle de l’IETF Trust et l’identification du registre YANG Parameters ?
  4. Les références externes aux modules importés figurent-elles dans des instructions reference ?
  5. Chaque révision identifie-t-elle la RFC ou le document qui contient le module ?
  6. Le texte distingue-t-il le modèle de données de chaque module qui le réalise ?
  7. Les datastores NMDA, la configuration, l’état opérationnel, le cycle de vie et l’autorité sont-ils explicites ?
  8. Les exemples sont-ils clairement non normatifs et les implications de sécurité analysées ?
  9. Pour un module géré par l’IANA, la procédure de registre est-elle explicite et prioritaire sur toute édition du texte généré ?
  10. Chaque composant de code peut-il être rattaché à son document conteneur ?

Chemin de décision pour l’acceptation opérateur

N’acceptez le modèle que si les dix questions ont une réponse dans le dossier de revue. Une lacune concernant un délimiteur, un nom, un en-tête, une révision, une sémantique, un exemple, la sécurité ou le registre impose un retour en correction. Si les réponses sont complètes, acceptez le document comme preuve de préparation de la revue, et non comme promesse que toutes les implémentations interopéreront. Toute question non résolue sur NMDA ou l’autorité du registre doit être escaladée avant la publication.

Sources