Résumé

  • draft-ietf-ivy-entitlement-inventory-05 décrit un modèle YANG en lecture seule pour les droits logiciels, les capacités et leurs restrictions. Il s’agit d’un Internet-Draft, non d’un RFC ni d’une preuve de déploiement.
  • Dans ce modèle, « installé » peut désigner une activation locale ou une attribution logique dans un système central. La provenance ne peut donc pas être séparée de la valeur.
  • allowed, in-use et le fonctionnement réel d’un service constituent trois affirmations distinctes. Les réunir dans un inventaire ne les rend pas interchangeables.

Une équipe d’actifs voit une licence rattachée au routeur r9. Pour elle, la situation est réglée : le contrat existe et la base centrale a enregistré l’attribution. L’équipe réseau interroge pourtant l’équipement et n’y trouve aucune activation locale. Les deux équipes peuvent afficher un état installed sans parler du même événement.

La révision 05 rend possible cette scène. Dans la section consacrée au périmètre, un droit installé est un droit attribué à un actif ; l’installation peut être un provisionnement direct sur l’équipement ou une attribution logique dans un système central. Plus loin, la définition d’Installed Entitlement insiste sur l’activation locale et la disponibilité pour les capacités de l’élément. Le terme n’est donc pas un reçu unique. Il est une catégorie commune posée au-dessus de plusieurs chemins opérationnels.

Les trois modèles de déploiement donnent la clé de lecture. Dans le premier, l’équipement conserve le droit et applique localement les restrictions. Dans le deuxième, un serveur de licences externe répond aux vérifications. Dans le troisième, le droit existe dans un accord commercial et le contrôle se déroule hors de l’équipement, qui peut ne rien savoir de cet accord. Le même arbre YANG peut être exposé par un élément réseau ou par un service de licences. Un collecteur peut ensuite agréger les vues, mais l’agrégation ne transforme pas leurs sources en un témoin unique.

Le modèle assume également des implémentations partielles. Le niveau 1 recense les droits détenus ou administrés par l’organisation. Le niveau 2 les associe à des actifs. Le niveau 3 ajoute les capacités. Le niveau 4 relie chaque capacité à ses droits de support et fournit allowed et in-use. Le niveau 5 ajoute les limites globales et celles propres à une capacité.

Cette progression évite de confondre les questions. Un catalogue d’entreprise ne dit pas ce que contient un châssis. Une attribution à un actif ne prouve pas que l’actif a accepté le droit. Une liste de capacités ne dit pas quel droit les autorise. Même le niveau 4 ne décrit pas nécessairement tous les quotas. Afficher un niveau 2 comme s’il s’agissait d’un niveau 5 revient à compléter le rapport avec des certitudes que la source n’a jamais émises.

Les presence containers servent précisément à signaler ce qu’un système sait rapporter. Leur absence signifie « cette implémentation ne peut pas fournir cette information ». Elle ne signifie pas automatiquement « cette capacité ou ce droit n’existe pas ». Pour une chaîne d’automatisation, inconnu doit rester une valeur de premier ordre. Le remplacer par false peut retirer une capacité valide ; le remplacer par true peut engager un service sans preuve suffisante.

À partir du niveau 4, allowed exprime l’effet combiné des droits requis. Si l’un d’eux manque, expire ou est révoqué, le projet prévoit que la valeur devienne fausse. in-use indique qu’une capacité est actuellement opérationnelle. Ces champs sont utiles, mais ils appartiennent toujours à un modèle en lecture seule. Ils ne sont ni l’ordre ayant activé la fonction, ni une transaction de configuration, ni une mesure indépendante de bout en bout, ni l’attestation qu’un service client a réussi.

Le texte exige d’ailleurs que les implémentations détectent les incohérences entre les enregistrements centraux, les droits installés localement et l’usage effectif des capacités. Cette obligation de rapprochement est révélatrice. Les trois couches peuvent se contredire ; le modèle permet de localiser le désaccord, pas de le faire disparaître.

La granularité des capacités reste une décision du fournisseur. Un produit peut annoncer une classe très large, par exemple Advanced Services, tandis qu’un autre expose MPLS, BGP ou QoS séparément. La valeur allowed: true n’a donc de sens qu’avec la définition de la capacité, la version du catalogue fournisseur et le périmètre de l’actif. Le standard porte la relation ; il ne rend pas identiques les frontières commerciales des produits.

La découverte automatique n’est pas couverte. Les associations peuvent être provisionnées dans une base, remontées par une interface de gestion ou saisies pendant l’inventaire. Les notifications d’expiration ne sont pas définies non plus : le modèle donne les dates, une autre application doit déclencher et remettre l’alerte. Une date d’échéance n’est pas la preuve qu’un avertissement a été reçu.

La protection de la lecture ne résout pas la vérité de la source. NETCONF, RESTCONF, l’authentification mutuelle et NACM peuvent sécuriser l’accès à des données particulièrement sensibles : références commerciales, durées de contrat, fonctions actives et profil de l’équipement. Ils ne certifient pas que le serveur de licences amont était exact ou synchronisé. Le projet avertit qu’une injection de faux états dans les canaux externes pourrait faire apparaître une capacité comme autorisée ou restreinte à tort.

La prudence vaut enfin pour le statut normatif. Datée du 29 septembre 2026, la révision 05 vise la Standards Track mais reste un document de travail. Un module valide et une éventuelle inscription IANA ne prouveraient ni adoption, ni support complet, ni fraîcheur des observations sur un réseau donné.

Le bon résultat n’est donc pas une coche verte supplémentaire. C’est une chaîne dans laquelle catalogue, attribution, activation locale, permission, usage déclaré, restriction et résultat du service conservent chacun leur auteur et leur date. L’inventaire devient alors un outil de rapprochement. Sans cette discipline, il devient une machine à transformer une représentation en réalité.

Sources