Résumé

  • Le projet draft-ietf-ivy-entitlement-inventory-05 distingue le droit détenu, son rattachement, son installation déclarée, les licences qui soutiennent une capacité, l’autorisation, l’usage et les plafonds.
  • Son module YANG est entièrement en lecture seule. Les systèmes qui attribuent ou imposent réellement les licences, la synchronisation et les alertes d’expiration restent hors de son périmètre.
  • Une décision exploitable doit conserver la source, l’heure, la règle et la preuve de chaque passage, jusqu’à l’état opérationnel et au service observé.

L’inventaire de clôture ne clôt pas la preuve

À la fin d’un trimestre, une équipe achats rapproche les licences acquises des équipements recensés. Le total est juste. Une licence de capacité apparaît active, rattachée à un châssis, présente dans installed-entitlements, et la fonction correspondante affiche allowed=true. Le rapprochement comptable peut être parfaitement réussi.

Le lendemain, une carte de ligne refuse la fonction. Le serveur de licences n’a pas propagé l’attribution, la carte dépend d’un module complémentaire arrivé à expiration, ou le cache local ne connaît pas encore la décision centrale. Le catalogue n’était pas nécessairement faux : il répondait à la question qu’il savait traiter. L’équipement en traitait une autre.

L’inverse est tout aussi révélateur. Une fonction peut continuer à tourner pendant une période de grâce alors que le catalogue central la classe expirée. Si le tableau de bord transforme ce désaccord en une seule couleur, il efface la seule information qui permette d’agir : qui affirme quoi, à quel instant et avec quel pouvoir d’exécution ?

La révision 05 de A YANG Module for Entitlement Inventory est datée du 29 septembre 2026. Son statut visé est Standards Track et son expiration est annoncée au 2 avril 2027. Il s’agit d’un Internet-Draft actif du groupe Network Inventory YANG de l’IETF, et non d’un RFC, d’une mise en œuvre certifiée ou d’une règle commerciale déjà appliquée.

Le droit se décompose

Le modèle complète l’inventaire IVY de base. Au sommet, l’organisation peut publier un droit avec identifiant, fournisseur, produit, état, dates et restrictions. Ce droit peut être rattaché à un détenteur, à un élément réseau ou à un composant. L’actif peut ensuite exposer une référence dite installée. Une capacité technique peut être décrite séparément, puis reliée à une ou plusieurs licences de soutien. Enfin viennent allowed, in-use, les maxima et la consommation courante.

Cette séquence répond à des questions différentes : le droit existe-t-il ? À qui est-il destiné ? Le système local le reconnaît-il ? De quelles licences la capacité dépend-elle ? Son utilisation est-elle permise ? Est-elle utilisée ? Dans quelles limites ? Le service attendu est-il observé ?

Une ligne de catalogue ne répond pas à toute la série. Une licence non attribuée peut être disponible pour demain. Une licence rattachée peut ne jamais avoir atteint l’actif. Une licence active peut ne couvrir qu’une dépendance parmi trois. Une capacité autorisée peut rester inutilisée. Une capacité utilisée peut ne transporter aucun trafic utile. Le modèle devient fiable lorsqu’il préserve ces écarts au lieu de les lisser.

Le mot « installé » change de point de vue

Le texte en chantier révèle lui-même une ambiguïté utile. La section de portée explique qu’une licence « installée » est attribuée à un actif et que cette installation peut être une activation directe ou une simple affectation logique dans un système central. La définition formelle parle d’une licence activée localement et disponible pour l’équipement. Une section ultérieure décrit encore ces références comme actives et conférant le droit.

Une version future pourra harmoniser le vocabulaire. Pour la révision analysée, un consommateur prudent ne doit pas choisir silencieusement l’interprétation la plus favorable. Il doit conserver le producteur.

La base d’actifs observe l’affectation. Le serveur de licences observe un bail. L’équipement observe un jeton chargé. Le contrôleur observe une réponse à sa dernière interrogation. Un identifiant commun permet de les rapprocher ; il ne leur donne pas le même champ de vision.

La donnée minimale n’est donc pas seulement installed=true. C’est un triplet : producteur, signification et heure d’observation. S’y ajoutent le chemin de validation et l’âge du cache. Sans eux, un nom de feuille précis masque une preuve imprécise.

Absent ne veut pas dire faux

Les conteneurs de présence du modèle indiquent aussi ce que le système sait publier. Un conteneur présent et vide peut signifier qu’aucune licence n’est installée. Un conteneur absent peut signifier que le producteur ne sait pas répondre. Une liste vide de licences de soutien peut signifier qu’une fonction n’exige pas de droit spécial ; l’absence du conteneur peut signifier que cette dépendance n’est pas disponible.

La même prudence vaut pour in-use. Si la feuille manque, le système peut être incapable d’exprimer l’usage. Il ne dit pas forcément « non ». Transformer toutes les absences en false facilite une jointure mais détruit la sémantique de l’incertitude.

Une automatisation sûre garde au moins quatre états : vrai déclaré, faux déclaré, vide déclaré et non déclaré. Elle garde également l’auteur et la date. Sinon elle peut refuser une opération sur la base d’une ignorance ou, pire, autoriser sans voir qu’une information indispensable n’existe pas.

Cinq niveaux, cinq promesses

Le projet propose une adoption progressive. Le niveau 1 couvre le catalogue central. Le niveau 2 ajoute les licences installées sur les actifs. Le niveau 3 décrit les capacités. Le niveau 4 relie capacités et licences, avec allowed et in-use. Le niveau 5 expose les restrictions globales et locales.

Les implémentations devraient documenter leur niveau et leurs écarts. Cette déclaration est plus importante qu’un logo de conformité. Un outil de niveau 1 ne peut pas prouver une permission locale. Un outil de niveau 3 peut connaître une capacité sans connaître son droit. Un outil de niveau 4 peut dire « permis » sans décrire le pool commun qui décide si une nouvelle utilisation reste licite.

Il faudrait donc acheter des garanties observables, non une case « inventaire des licences ». Quelle couche est réellement fournie ? Quel système alimente chaque feuille ? Quelle fraîcheur ? Que devient la réponse pendant une partition ? Voilà les questions comparables.

allowed résume une règle

Une capacité peut dépendre de plusieurs licences. Le modèle exige que allowed reflète leur effet combiné et recommande une valeur fausse si une dépendance requise manque, est expirée ou révoquée. Ce booléen est donc le résultat d’un calcul de politique.

Pour l’interpréter, il faut connaître la liste complète, l’état frais de chaque droit, la règle de combinaison et l’identité du décideur. Une période de grâce peut être connue du serveur et ignorée du contrôleur. Une extension obligatoire peut manquer dans un catalogue incomplet. Deux réponses différentes peuvent être cohérentes avec deux vues différentes.

Même exact, allowed=true ne donne pas à un administrateur le droit de configurer. Le NACM défini par le RFC 8341 traite les autorisations des utilisateurs NETCONF ou RESTCONF. L’entitlement traite le droit de l’organisation à activer une fonction. La licence ne crée pas le rôle de l’utilisateur ; le rôle ne crée pas la licence.

Et la permission commerciale ou technique ne remplace pas les prérequis de fonctionnement : version logicielle, ressources, carte compatible, topologie, politique et état du plan de transfert restent à vérifier.

Usage, quota et concurrence

Le champ in-use peut exister au niveau de la licence et de la capacité. Le projet demande leur cohérence lorsqu’ils sont tous deux disponibles. C’est un contrôle utile, mais la méthode d’observation reste déterminante. « Utilisé » peut vouloir dire configuré, processus démarré, siège réservé, compteur non nul ou trafic effectivement traité.

Les restrictions comportent un nom de ressource, une unité, un maximum et une valeur courante. Quatre-vingts unités sur cent ne garantissent pas que vingt unités sont encore réservables. La mesure peut être ancienne ; deux orchestrateurs peuvent consommer simultanément le même reliquat ; un pool parent peut couvrir plusieurs enfants.

Les hiérarchies de licences ajoutent un autre risque. YANG peut empêcher une auto-référence directe, mais pas toutes les boucles profondes. Le système de gestion doit détecter A→B→A. Un document conforme au schéma peut donc porter un graphe impossible, et un graphe correct peut encore subir une course de réservation.

Chaque compteur devrait voyager avec son périmètre, son unité, sa fenêtre, sa source, son heure et son état de réservation. Il devient alors une preuve exploitable plutôt qu’un nombre décoratif.

Lecture seule ne signifie pas vérité automatique

Tous les nœuds du module sont config false. Le modèle rend compte d’un état ; il ne le modifie pas. Les serveurs de licences et les plateformes de gestion d’actifs écrivent la réalité sous-jacente par des canaux extérieurs au projet.

Un accès NETCONF ou RESTCONF peut être chiffré et mutuellement authentifié tout en livrant une information périmée. La section de sécurité avertit qu’un canal externe compromis peut injecter un faux état et faire paraître une fonction autorisée ou interdite à tort. Le caractère en lecture seule protège contre certaines écritures par cette interface ; il ne garantit pas l’origine de ce qui est lu.

La réconciliation est donc une fonction à part entière. Le projet recommande de détecter les incohérences entre catalogue central, installations locales et usage réel, mais n'impose ni arbitre universel, ni délai de fraîcheur, ni ordre de priorité. L’expiration suit la même logique : les dates sont exposées, mais les alertes et l’escalade appartiennent aux applications de gestion.

Neuf reçus pour une décision

Une chaîne défendable conserve :

  1. le reçu d’octroi, avec émetteur, détenteur, dates et limites ;
  2. le reçu d’affectation à un actif ou composant ;
  3. le reçu d’activation du système capable d’accepter ou refuser ;
  4. le reçu de dépendances, complet et sans cycle ;
  5. le reçu de permission, avec règle, producteur et fraîcheur ;
  6. le reçu d’accès de l’utilisateur ou de l’automate ;
  7. le reçu d’usage, avec sa méthode d’observation ;
  8. le reçu de restriction, avec pool, réservation et contrôle ;
  9. le reçu de résultat, depuis la configuration jusqu’au service vu.

Ces reçus peuvent rester distribués. L’important est que l’inventaire ne les transforme pas en une seule affirmation impossible à auditer.

Sources