Résumé

  • Le RFC 9997 réserve deux très grandes plages privées et permet à certains titulaires de PEN d’en déduire directement un bloc de 100 000 SID, ainsi qu’un bloc de 10 000 SID pour les PEN les plus bas. Il supprime une démarche d’allocation, pas le contrôle de la source.
  • Le texte précise qu’un PEN reconnaissable dans un SID n’indique pas la provenance. Le RFC 9595 exige par ailleurs une source faisant autorité pour les fichiers .sid, car une mauvaise correspondance change la signification des nombres compacts.
  • Daniel Kade propose un reçu de rattachement de provenance en huit plans, sobre en données, pour relier registre, calcul de plage, dépôt autorisé, empreintes du module et du fichier SID, cycle de vie, intégrité, contexte YANG Library et décision d’acceptation.

Le nombre officiel qui raconte une histoire non vérifiée

Dans un atelier d’intégration, un fichier de correspondance arrive avec un nouveau modèle YANG. Les identifiants appartiennent tous à la plage calculée depuis le PEN de l’entreprise annoncée. L’outil n’observe aucune collision. Le décodage CBOR restitue des noms de feuilles crédibles. La tentation est forte de résumer le contrôle par une phrase : « la plage est la bonne, donc le fichier vient du bon acteur ».

Cette phrase ajoute une propriété que le mécanisme ne fournit pas. Un tiers peut calculer la même plage publique. Il peut écrire des entiers qui s’y trouvent, recopier un espace de noms et publier un fichier vraisemblable. La justesse du calcul ne lui confère aucun droit sur le dépôt, aucune maîtrise du module et aucune délégation du titulaire du PEN.

Publié en juillet 2026 comme Proposed Standard du flux IETF, le RFC 9997 organise l’emploi de Private Enterprise Numbers pour attribuer des plages privées de YANG Schema Item iDentifiers. Il répond à un problème réel : demander une allocation centrale pour chaque modèle expérimental, propriétaire ou interne ajouterait du délai sans toujours améliorer l’interopérabilité publique.

Un SID est un entier non signé globalement unique sur 63 bits. Il associe un élément de schéma YANG à un nombre compact. Dans YANG-CBOR, décrit par le RFC 9254, cette association évite de répéter des chemins ou des noms plus longs. L’économie de place est réelle, mais elle reporte la confiance sur la table de correspondance. Les deux extrémités doivent attribuer la même sémantique au même entier.

L’unicité globale évite qu’une autorité soigneuse empiète par mégarde sur le bloc d’une autre. Elle ne transforme pas le nombre en certificat. Une plaque d’immatriculation peut respecter le format d’un pays sans prouver l’identité de la personne qui conduit ; un SID peut respecter une plage déléguée sans authentifier le fichier qui lui donne un sens.

Deux réserves immenses, deux opérations simples

Le dispositif repose sur deux intervalles inscrits comme Private dans le registre IANA des SID YANG. Le premier s’étend de 3 000 000 000 à 3 999 999 999. Le second va de 300 000 000 000 à 399 999 999 999. Ici, « Private » désigne une politique d’allocation. Le mot ne rend ni les bornes ni les usages secrets.

Pour tout PEN inférieur à 1 000 000, une formule détermine un bloc de 100 000 SID dans la grande plage. Un PEN inférieur à 100 000 obtient aussi, par calcul, un bloc de 10 000 SID dans l’intervalle inférieur. Une fois le PEN enregistré, aucune interaction supplémentaire avec l’IANA n’est nécessaire pour obtenir ces blocs.

Le résultat est une séparation prévisible. Deux titulaires appliquant la règle à des PEN différents n’atterrissent pas sur le même bloc. Le registre central fixe les limites et l’espace des numéros d’entreprise ; la formule distribue la capacité ; le titulaire administre ensuite ses attributions privées.

Le traitement de PEN 32473 montre le soin accordé aux exemples. Le RFC 5612 réserve ce numéro à la documentation. Le RFC 9997 réserve donc également les deux blocs SID qui en découlent. Une spécification peut illustrer le calcul sans emprunter le numéro réel d’une entreprise ni créer une fausse apparence d’usage.

Cette simplicité est volontaire. Le document décrit l’obtention d’un PEN comme une démarche peu contraignante et la dérivation du bloc comme une opération sans interaction. Il serait incohérent d’utiliser ensuite ce chemin léger comme contrôle d’identité de haute assurance. Le système a été conçu pour répartir un espace, pas pour examiner chaque publication.

Le titulaire de la plage n’est pas présent dans chaque fichier

L’autorité d’allocation répond à une question : qui peut gérer les nombres de ce bloc dans le cadre de la politique du registre ? La provenance en pose une autre : par quel canal vérifié ce module précis et ce fichier précis ont-ils été publiés ? Les réponses peuvent être cohérentes, mais elles ne se déduisent pas l’une de l’autre.

La section Sécurité du RFC 9997 énonce exactement cette limite. La présence d’un PEN donné dans un SID n’est pas un indicateur de provenance. Elle ne garantit pas que le SID ou le modèle YANG sous-jacent provient du titulaire de ce PEN. Cette réserve interdit de faire de la formule une identité implicite.

Il faut distinguer au moins quatre objets. Le registre IANA des PEN documente une attribution de numéro. Le registre SID documente des plages et leurs politiques. Un dépôt distribue des octets portant un nom, une révision et une correspondance. Un serveur en fonctionnement annonce le schéma qu’il utilise. La validité d’un objet ne répare pas automatiquement une erreur sur un autre.

Un PEN n’est ni une décision sur une marque, ni un certificat de signature logicielle, ni la preuve qu’un compte de forge demeure sous le contrôle de l’entité attendue. Une plage correcte ne dresse pas la liste des modèles. Un espace de noms familier ne prouve pas les octets. Une révision inscrite dans un nom ne garantit pas la correspondance entre le module et le fichier .sid reçu.

Le RFC 9595 insiste sur ce dernier risque. Un fichier SID relie des concepts sémantiques à des entiers. Une correspondance non fiable peut donc faire lire une valeur sous le mauvais concept. Les développeurs ne devraient importer ces fichiers qu’à partir de sources faisant autorité ; les systèmes de gestion ont besoin d’une source aussi autorisée que celle des modules YANG eux-mêmes.

Vérifier seulement l’intervalle ne satisfait pas cette obligation. L’intervalle montre que le nombre appartient à un espace que le titulaire est autorisé à gérer. La provenance montre que l’énoncé d’attribution particulier a effectivement suivi un canal autorisé. La différence est celle qui sépare la possibilité de parler du droit d’avoir parlé.

Trouver un modèle n’équivaut pas à authentifier sa publication

Le RFC 9997 ne définit pas de service universel de découverte reliant chaque SID dérivé d’un PEN à son module. Lorsque l’obscurité n’est pas recherchée, il encourage un dépôt public de modèles et de fichiers SID, ou l’exposition de YANG Library par les implémentations. Ces options améliorent la découvrabilité sans créer, à elles seules, une racine de confiance.

Un dépôt public exige encore une preuve de mandat : quelle adresse est officielle, qui contrôle le compte, quelle version a été approuvée, quelle empreinte a été téléchargée, et comment une migration ou une compromission est-elle signalée ? La disponibilité résout « où regarder ». Elle ne résout pas nécessairement « pourquoi croire ce que l’on a trouvé ».

Le RFC 8525 fait de YANG Library une excellente source de contexte opérationnel. Un serveur peut déclarer ses modules, révisions, espaces de noms, fonctions, déviations, schémas et datastores. Son content-id doit changer lorsque l’information de bibliothèque change. Il n’a toutefois pas à être identique pour une information identique à deux moments ou sur deux serveurs.

Ce content-id permet donc d’observer une transition dans le contexte d’un serveur. Ce n’est pas une empreinte universelle du contenu. Il peut aider à répondre : « quel ensemble ce serveur déclarait-il lorsque cette décision a été prise ? » Il ne répond pas, seul, à la question de savoir qui a publié les fichiers ni si leur acheminement a été intègre.

La chaîne complète traverse plusieurs autorités : le registre borne l’espace ; un canal reconnu établit la publication ; une empreinte fixe les octets ; une signature ou un contrôle d’intégrité rattache la livraison ; YANG Library décrit le déploiement ; l’exploitant décide d’accepter ou de refuser. Supprimer un maillon et demander au PEN de le remplacer produit une certitude de façade.

La sémantique compacte possède elle aussi une histoire

Le RFC 9595 distingue les états instable, stable et obsolète des correspondances SID. Un numéro instable peut évoluer pendant la conception. Un SID devenu stable bénéficie d’une attente de continuité. Lorsqu’il devient obsolète, il reste enregistré pour empêcher sa réaffectation à un autre élément de schéma.

Cette conservation empêche qu’un entier revienne avec un sens différent. Mais elle n’aide que si l’historique accompagne les objets. Remplacer silencieusement un ancien fichier par sa dernière version peut rendre indéchiffrable la provenance sémantique d’une archive. À l’inverse, un fichier ancien peut être authentique tout en étant inadapté au modèle actuellement déclaré.

Deux contrôles sont donc nécessaires : l’objet venait d’une source autorisée, et son état de cycle de vie convenait à la charge utile ou au déploiement concerné. « Authentique » ne veut pas dire « actuel ». « Actuel en apparence » ne veut pas dire « autorisé ».

La compression accentue l’enjeu. Un chemin YANG lisible offre encore quelques indices à un examinateur. Un entier compact ne porte pas son explication avec lui. Si la correspondance est fausse, le système peut rester techniquement cohérent tout en appliquant une politique au mauvais objet.

Un reçu en huit plans, plutôt qu’une copie générale des systèmes

Il ne faut pas transformer cette exigence en collecte de configurations, de modèles privés ou de trafic décodé. La preuve utile tient dans les liaisons minimales. Daniel Kade propose un reçu de rattachement de provenance en huit plans séparés.

Le premier conserve la version ou l’instantané du registre IANA utilisé. Le deuxième note le PEN, le seuil applicable et le calcul exact de la plage. Ensemble, ils prouvent l’appartenance numérique, sans prétendre authentifier un fichier.

Le troisième identifie le dépôt ou la racine de distribution reconnus, avec la raison documentée de cette reconnaissance. Le quatrième lie le nom, l’espace de noms, la révision et l’empreinte cryptographique du module YANG. Le cinquième fixe l’empreinte du fichier .sid, son état de cycle de vie et l’historique pertinent des attributions.

Le sixième enregistre le résultat du contrôle d’intégrité ou de signature : mécanisme, identité de confiance, instant et conclusion. Le septième conserve le contexte YANG Library observé sur le serveur, notamment modules, révisions, fonctions, déviations, datastore et content-id, sans transformer ce dernier en hash global. Le huitième décrit l’issue opérationnelle : accepté, refusé, remplacé ou retiré, avec motif, responsable et périmètre.

Chaque plan garde son auteur. L’IANA ne garantit pas un dépôt. Le dépôt ne décrit pas tous les serveurs. Le serveur ne certifie pas rétroactivement le canal d’origine. Un décodage réussi ne prouve pas que l’association sémantique était autorisée. Le reçu sert à montrer les jointures et les incertitudes, pas à les effacer.

Cette proposition est celle de Daniel Kade ; elle n’ajoute aucun champ au RFC 9997, au RFC 9595 ou au RFC 8525. Elle exclut les contenus de configuration, identifiants d’accès, modèles privés, secrets d’équipement et comportements sans rapport. Sa finalité est modeste : empêcher qu’une économie d’interaction se transforme en économie de vérification.

Pourquoi BTW Media existe fournit la règle éditoriale appropriée : ne pas remplacer les faits observables par un récit séduisant. Un système peut observer un registre, une empreinte, une validation et un inventaire déployé. Il ne peut pas fabriquer une origine à partir de chiffres familiers.

Sources