Résumé

  • La révision 04 de draft-ietf-green-power-and-energy-yang est disponible depuis le 9 septembre 2026. Elle reste un Internet-Draft du groupe GREEN, à l’état I-D Exists, et non un RFC approuvé.
  • Un nouveau passage indique que source-component-id s’appuie sur l’uuid de RFC 8348 afin de corréler un Energy Object entre équipements, systèmes de gestion et domaines administratifs.
  • Dans le module de cette même révision, le leafref vise encore /hw:hardware/hw:component/hw:name. Les règles YANG donnent au chemin le pouvoir de désigner le nœud et son espace de valeurs : le contrat exécutable transporte donc le nom local, pas la feuille UUID séparée.
  • Le texte et le schéma doivent d’abord être alignés. Daniel Kade propose ensuite un reçu protégé de liaison d’identité pour encadrer les remplacements et rattachements ultérieurs ; ce n’est pas une exigence du projet.

La validation syntaxique ne tranche pas le choix d’identité

La liste des documents récents date la révision 04 du 9 septembre. Sa fiche Datatracker la classe comme document actif de GREEN et son historique enregistre la mise à disposition à 05:30:49 dans le fuseau -0700 affiché. Elle n’a pas dépassé l’état I-D Exists. Le contrôle YANG signalé sans erreur est utile, mais il ne vérifie pas que le commentaire humain et la cible d’un leafref choisissent la même notion.

La nouvelle section sur l’identification matérielle distingue trois attributs de RFC 8348. Le name vaut dans le contexte d’un équipement, physical-index dépend d’une fonction MIB, et seul uuid est présenté comme globalement unique. Le texte en déduit que source-component-id est lié à l’UUID, ce qui doit permettre la corrélation entre appareils, outils de gestion et domaines administratifs.

Or le module fixe toujours le type de cette feuille à leafref, avec le chemin /hw:hardware/hw:component/hw:name. Sa description parle elle aussi du nom du composant. La révision 03 utilisait déjà cette cible. La comparaison officielle montre que l’ambition UUID s’est précisée sans modification correspondante de la feuille.

Le chemin est la règle que les outils peuvent exécuter

RFC 7950 définit le leafref de YANG 1.1 : le path identifie la feuille référencée et le nœud qui la cite hérite de son espace de valeurs. Le chemin actuel mène à name.

RFC 8348 place ce nom comme clé de la liste des composants matériels. C’est une chaîne attribuée au composant. L’UUID est une autre feuille, facultative, en lecture seule et typée yang:uuid. De plus, ce RFC présente un modèle de gestion du matériel d’un serveur unique. La validité locale du nom ne garantit donc pas une identité persistante à l’échelle de plusieurs systèmes.

Le constat ne permet pas d’accuser une mise en œuvre. Un fournisseur peut maintenir une table privée, préférer l’intention narrative ou ne rien déployer avant correction. Même l’UUID ne prouve ni la propriété du matériel, ni sa présence actuelle, ni le droit de lui imposer un état électrique. Le problème documenté est celui d’une révision qui propose deux réponses pour le contenu d’une même feuille.

Une erreur de sujet précède toute erreur de mesure

Le cadre GREEN prévoit des agrégations et validations hiérarchiques. Les cas d’usage couvrent le suivi du cycle de vie, la mesure indirecte et la commande énergétique. Dans chacun, la qualité du chiffre vient après l’identité de son sujet. Une mesure exacte attribuée à la mauvaise alimentation ne devient pas fiable grâce à un label d’exactitude.

Le modèle sépare aussi l’état électrique administratif demandé de l’état opérationnel constaté. Pour une autre référence du sous-arbre de contrôle, require-instance false permet de conserver une configuration avant l’apparition d’un Energy Object ou après sa disparition ; elle reste sans effet en son absence. La partie sécurité précise qu’une écriture non autorisée sur l’état administratif pourrait éteindre une infrastructure critique, endommager du matériel ou perturber la surveillance. Elle renvoie à NACM pour limiter les droits dans NETCONF ou RESTCONF.

NACM vérifie l’auteur de l’écriture. Il ne certifie pas que l’objet revenu sous un identifiant ressemble encore, physiquement et administrativement, à celui qui avait reçu l’intention. Cette continuité exige une décision distincte.

Un petit correctif de norme, puis un reçu de rattachement

Le projet doit choisir. Si l’UUID est l’identité intersystème, le module doit le transporter ou le référencer sans ambiguïté. Si le nom local est conservé, la promesse de corrélation doit être limitée et une association explicite définie ailleurs.

Pour l’exploitation, un reçu protégé pourrait conserver :

  1. la révision exacte du module et son empreinte ;
  2. l’identifiant de l’Energy Object, l’équipement et le domaine administratif ;
  3. le nom local et l’UUID observé, ou une absence explicite ;
  4. la source, l’autorité et l’heure de l’association ;
  5. les éléments locaux de série, d’actif ou de remplacement disponibles ;
  6. toute disparition, substitution, réaffectation ou fusion ;
  7. l’intention d’alimentation encore attachée à l’objet ;
  8. l’autorité et l’heure d’une décision de rattachement ;
  9. le résultat de la vérification avant reprise de l’agrégation ou de la commande.

Il ne s’agit pas de publier la topologie électrique. Le projet rappelle que les séries fines et les relations entre objets peuvent révéler charge, capacité, activité de clients et cibles critiques. Les références et empreintes peuvent rester dans le domaine autorisé.

L’approche suit la discipline de spécification initiale minimale décrite par Heng Lu : partager le raccord indispensable, pas tout le dossier interne. The Policy Mirror rappelle que l’automatisation ne doit pas faire disparaître la règle ni le sujet de la décision.

Ce reçu est ma proposition éditoriale. Il ne figure pas dans la révision 04 et n’exprime pas une décision du groupe GREEN.

Limite des preuves

Les sources prouvent la divergence entre le paragraphe UUID et le leafref vers name. Elles ne prouvent aucune confusion réelle, aucun ordre appliqué au mauvais composant et aucune adoption du modèle. L’UUID de RFC 8348 est facultatif et ne suffit pas à lui seul pour établir autorité ou continuité physique. Une prochaine révision peut corriger le texte.

La conclusion reste bornée : la corrélation entre domaines est promise par l’UUID, alors que le schéma publié le 9 septembre sélectionne toujours le nom local.

Sources