Résumé

  • La RFC 9911 est une norme proposée par l’IETF, publiée en décembre 2025, et elle rend obsolète la RFC 6991.
  • Elle révise ietf-yang-types et ietf-inet-types sans modifier leurs espaces de noms ni leurs noms de modules.
  • La révision peut néanmoins modifier l’espace des valeurs, les représentations canoniques, les motifs et les descriptions.
  • Le déploiement réel et le comportement des implémentations restent inconnus : il ne faut conclure ni à une adoption universelle ni à une incompatibilité générale.

Le mécanisme est le point essentiel. Un module peut rester immédiatement reconnaissable par les outils et les équipes, alors que sa déclaration de révision renvoie à un contrat différent. La RFC 9911 ajoute des types de date et d’heure et de durée, des types pour les étiquettes de langue et les numéros de protocole, des types d’adresses locales au lien, d’adresse et préfixe, ainsi que host-name et email-address. Elle aligne aussi yang-identifier sur YANG 1.1 et corrige ou améliore plusieurs déclarations de motifs et de descriptions.

Le détail temporel est particulièrement concret. Selon la sémantique issue de la RFC 9557, Z et +00:00 expriment tous deux UTC, mais ils ne l’affirment pas de la même façon : +00:00 indique qu’UTC est le point de référence local, tandis que Z indique UTC sans cette affirmation. Un analyseur, un canonicaliseur ou un sérialiseur qui fusionnerait systématiquement les deux formes pourrait donc effacer une information utile au consommateur.

Les nouveaux motifs appellent la même prudence. Une valeur admise par la RFC 6991 n’est pas automatiquement invalide selon la RFC 9911, et le dossier factuel ne permet pas de déterminer quelles valeurs stockées échoueront dans une installation donnée. Il faut examiner si la révision importée change l’espace des valeurs ou la forme canonique du champ réellement utilisé par le modèle. Les descriptions comptent également : elles peuvent modifier une hypothèse d’ingénierie même lorsque la validation machine ne change pas.

La RFC 9911 précise aussi l’équivalence, ou la non-équivalence, avec plusieurs conventions textuelles SMIv2 ; cela constitue un élément de preuve, pas une garantie de comportement identique dans chaque produit.

Registre de preuves sensible aux révisions

Question Preuve et limite
Qu’est-ce qui change ? La RFC 9911 révise les deux modules communs, ajoute des typedefs, aligne yang-identifier sur YANG 1.1 et met à jour motifs et descriptions.
Qu’est-ce qui reste familier ? Les espaces de noms et les noms de modules demeurent ; une nouvelle date de révision est publiée. Cela ne garantit pas la compatibilité sémantique.
Quel est le statut ? Norme proposée par l’IETF, décembre 2025 ; la RFC 9911 rend la RFC 6991 obsolète.
Que ne sait-on pas ? L’adoption déployée, le verrouillage des révisions par les clients et les valeurs de datastores qui échoueront.
Que ne faut-il pas déduire ? Ni adoption universelle, ni incompatibilité globale, ni comportement propre à un fournisseur sans preuve.

Sources