Zusammenfassung

  • Revision 04 von draft-ietf-green-power-and-energy-yang wurde am 9. September 2026 verfügbar. Sie ist weiterhin ein Internet-Draft der GREEN-Arbeitsgruppe im Zustand I-D Exists, kein RFC und kein verabschiedeter Standard.
  • Ein neuer Abschnitt erklärt, source-component-id sei an die uuid aus RFC 8348 gebunden und könne ein Energy Object über Geräte, Managementsysteme und administrative Domänen korrelieren.
  • Im YANG-Modul derselben Fassung zeigt der Leafref weiterhin auf /hw:hardware/hw:component/hw:name. Nach YANG 1.1 bestimmt der Pfad den referenzierten Knoten und dessen Werteraum; der ausführbare Vertrag wählt damit den lokalen Namen, nicht den separaten UUID-Leaf.
  • Text und Schema müssen zuerst dieselbe Identität wählen. Daniel Kade schlägt zusätzlich einen geschützten Identitätsbindungsbeleg für spätere Austausch- und Neubindungsentscheidungen vor. Er ist keine Vorgabe des Entwurfs.

Die neue Aussage und der alte Pfad

Die Liste aktueller IETF-Dokumente führt Revision 04 am 9. September. Der Datatracker-Eintrag weist sie als aktives GREEN-Dokument aus; die Historie protokolliert die Verfügbarkeit um 05:30:49 in der angezeigten Zeitzone -0700. Der Zustand bleibt I-D Exists. Eine fehlerfreie YANG-Validierung bestätigt Syntax, nicht die semantische Übereinstimmung zwischen Erläuterung und Leafref-Ziel.

Der neue Abschnitt zur Hardware-Identifikation sortiert drei Attribute aus RFC 8348. name hat nur im jeweiligen Gerät Bedeutung, physical-index hängt von einer optionalen MIB-Funktion ab, und allein uuid wird als global eindeutig bezeichnet. Daraus leitet der Text ab, source-component-id verwende die UUID und ermögliche eine geräte- und domänenübergreifende Korrelation.

Die Modulsprache bleibt bei type leafref, Pfad /hw:hardware/hw:component/hw:name und einer Beschreibung, die ausdrücklich den Bauteilnamen nennt. Schon Revision 03 verwendete diese Definition. Der offizielle Vergleich zeigt die neue UUID-Begründung, ohne den Zielpfad umzustellen.

Leafref-Semantik lässt sich nicht durch Prosa überschreiben

RFC 7950 legt fest, dass der path eines Leafrefs den referenzierten Leaf oder die Leaf-Liste bezeichnet. Der verweisende Knoten übernimmt den Werteraum des Ziels. Das Ziel in Revision 04 ist name.

RFC 8348 verwendet name als String-Schlüssel der Hardware-Komponentenliste. uuid ist ein anderer, optionaler und schreibgeschützter Leaf vom Typ yang:uuid. Zudem gilt das dortige Modell der Hardwareverwaltung auf einem einzelnen Server. Ein lokal eindeutiger Name ist deshalb kein Nachweis für dieselbe physische Komponente in zwei Verwaltungssystemen.

Aus diesem Widerspruch folgt keine Behauptung über reale Produkte. Implementierungen könnten eine private Zuordnung pflegen, der Prosa folgen oder eine Korrektur abwarten. Auch eine UUID beweist weder Eigentum noch fortdauernden Einbau noch Schaltbefugnis. Belegt ist allein, dass die unveränderliche Fassung für denselben Leaf zwei verschiedene Identitätsverträge beschreibt.

Messkette und Steuerkette treffen sich am Subjekt

Der GREEN-Rahmenentwurf beschreibt hierarchische Aggregation und Plausibilisierung. Die Anwendungsfälle umfassen Lebenszyklusberichte, indirekte Messung und Energiesteuerung. Werden zwei psu-1 aus verschiedenen Geräten verbunden, kann ein exakter Messwert trotzdem in der falschen Historie landen.

Der Entwurf trennt den administrativ gewünschten Energiezustand vom beobachteten Betriebszustand. Ein anderer Control-Leafref mit require-instance false lässt Konfiguration bestehen, bevor ein Energy Object erscheint oder nachdem es verschwunden ist; bei Abwesenheit wirkt sie nicht. Die Sicherheitsanalyse warnt, dass unbefugtes Schreiben den Betrieb kritischer Infrastruktur abschalten, Hardware schädigen oder Überwachung stören könnte. NACM soll die Berechtigungen für NETCONF und RESTCONF begrenzen.

NACM entscheidet, wer schreiben darf. Ob eine gespeicherte Absicht nach einem Austausch wieder dasselbe Bauteil trifft, ist eine andere Governance-Entscheidung.

Erst das Schema richten, dann die Bindung dokumentieren

Die Spezifikation braucht eine klare Wahl. Für domänenübergreifende Identität muss der Leaf die UUID führen oder eindeutig referenzieren. Soll es beim lokalen Namen bleiben, muss die Reichweite des Textes enger werden und eine eigene Zuordnung definiert sein.

Ein geschützter Identitätsbindungsbeleg könnte danach festhalten:

  1. genaue Modulrevision und Digest;
  2. Energy-Object-ID, Gerät und administrative Domäne;
  3. lokalen Namen und beobachtete UUID, einschließlich expliziter Abwesenheit;
  4. Quelle, Autorität und Zeitpunkt der Zuordnung;
  5. vorhandene Serien-, Anlagen- oder Austauschbelege;
  6. Verschwinden, Ersatz, Neuzuweisung oder Zusammenführung;
  7. weiterhin gebundene administrative Energieabsicht;
  8. Genehmiger und Zeitpunkt einer Neubindung;
  9. Prüfergebnis vor erneuter Aggregation oder Steuerung.

Der Beleg muss keine Stromtopologie offenlegen. Revision 04 weist selbst darauf hin, dass feingranulare Energiedaten und Beziehungen Auslastung, Kapazität, Kundenaktivität und wertvolle Infrastruktur sichtbar machen können. Die Identitätsbelege gehören in den berechtigten Verwaltungsbereich.

Die Minimum-Initial-Specification-Disziplin von Heng Lu begrenzt die gemeinsame Struktur auf die notwendige Interoperabilitätsgrenze. The Policy Mirror ergänzt: Nach automatischer Ausführung müssen Regel und Ziel der Entscheidung erkennbar bleiben.

Der Bindungsbeleg ist mein redaktioneller Vorschlag. Er steht nicht in Revision 04 und ist kein Beschluss der GREEN-Arbeitsgruppe.

Beweisgrenze

Die Quellen belegen die Abweichung von Prosa und Leafref, nicht einen Vorfall. Sie zeigen keine fehlerhafte Zuordnung, keinen ausgeführten Altbefehl und keine tatsächliche Implementierung. RFC 8348 macht die UUID optional; sie allein begründet weder Eigentum noch Autorität. Eine spätere Revision kann den Widerspruch beseitigen.

Die belastbare Aussage lautet: Der neue Text verspricht UUID-Korrelation, während das aktuelle Modul component/name auswählt.

Quellen