Zusammenfassung

  • draft-ietf-ivy-entitlement-inventory-05 modelliert den zentralen Lizenzbestand, Zuordnung, installierte Referenzen, unterstützende Lizenzen, allowed, in-use und Beschränkungen als getrennte Aussagen.
  • Das vorgeschlagene YANG-Modul ist vollständig schreibgeschützt. Die Systeme, die Rechte tatsächlich ändern oder durchsetzen, sowie Synchronisierung und Ablaufwarnung liegen außerhalb.
  • Verlässliche Automatisierung benötigt Herkunft, Zeitpunkt und Regel jedes Wertes sowie Belege von lokaler Annahme bis zur beobachteten Dienstwirkung.

Was bedeutet aktiv, wenn der Server schweigt?

Ein Lizenzserver ist während einer Wartung nicht erreichbar. Drei Router zeigen dieselbe Funktion als allowed=true. Der erste arbeitet weiter, weil er ein noch gültiges lokales Token besitzt. Der zweite sperrt neue Aktivierungen, lässt bestehende Sitzungen aber bestehen. Der dritte verweigert die Funktion sofort. Im zentralen Inventar sehen alle drei gleich aus.

Keine dieser Strategien ist allein aufgrund des Beispiels falsch. Sie verkörpern unterschiedliche Entscheidungen über Verfügbarkeit, Widerruf und kommerzielles Risiko. Falsch wäre nur, die identische Inventarzeile als Beweis identischen Verhaltens zu behandeln.

Revision 05 von A YANG Module for Entitlement Inventory wurde am 29. September 2026 datiert, strebt Standards Track an und läuft am 2. April 2027 aus. Es handelt sich um einen aktiven Internet-Draft der IETF-Arbeitsgruppe Network Inventory YANG, nicht um einen RFC, eine abgeschlossene IANA-Zuweisung oder den Nachweis einer Produktimplementierung.

Der Entwurf schafft eine gemeinsame Sprache. Er schafft keinen zentralen Vollstrecker.

Vom Bestand bis zur Wirkung

Im obersten Katalog steht ein organisatorisches Entitlement mit ID, Produktdaten, Zustand, Gültigkeitsdaten und Beschränkungen. Eine Zuordnung verbindet es mit Inhabern, Netzelementen oder Komponenten. Am Asset kann eine Referenz unter installed-entitlements erscheinen. Die technische Fähigkeit wird getrennt aufgeführt und verweist auf die Lizenzen, die sie stützen. allowed beschreibt die lizenzbezogene Erlaubnis, in-use die gemeldete Nutzung. Maximal- und Istwerte beschreiben Grenzen.

Erst danach folgen Konfigurationsannahme, operativer Zustand, Forwarding und der beobachtete Dienst.

Dieser Ablauf enthält neun Beweisfragen: Erteilung, Zuordnung, lokale Aktivierung, Abhängigkeitsmenge, Erlaubnis, Benutzerzugriff, Nutzung, Begrenzung und Ergebnis. Eine aktive Katalogzeile kann keine der späteren Fragen automatisch beantworten.

Installiert ist kein ortsunabhängiger Begriff

Der Arbeitsstand verwendet „installed“ nicht überall deckungsgleich. Im Scope kann es eine Zuweisung zu einem Asset bedeuten, einschließlich einer rein logischen Zuordnung im zentralen System. Die Definition spricht von lokaler Aktivierung und Verfügbarkeit. Später werden installierte Referenzen als aktuell berechtigend beschrieben.

Das ist bei einem Internet-Draft eine zu klärende Semantik. Für Betreiber ist es bereits heute ein Hinweis: Die Herkunft muss mitgespeichert werden.

Das Asset-System sieht die Zuordnung. Der Lizenzserver sieht die Ausgabe eines Leases. Das Gerät sieht ein akzeptiertes Token. Der Controller sieht den letzten Poll. Gleiche IDs schaffen Korrelation, aber keine gemeinsame Beobachtung.

Eine belastbare Aussage lautet daher nicht nur „installiert“, sondern „von System X um Zeitpunkt Y unter Semantik Z und Validierungspfad V gemeldet“. Auch das Alter des Cache gehört dazu.

Abwesenheit, Leere und Nein

Presence Container beschreiben, ob ein System eine Informationsklasse kennt. Ein vorhandener, leerer Container kann „keine installierte Lizenz“ bedeuten. Ein fehlender Container kann „nicht berichtsfähig“ bedeuten. Ein fehlendes in-use ist nicht zwingend false.

Bei supporting entitlements kann eine ausdrücklich leere Liste aussagen, dass kein besonderes Recht nötig ist. Ein fehlender Container kann unbekannte Abhängigkeiten bedeuten. Wer beides in eine leere Liste normalisiert, verwandelt Unwissen in Freigabe.

Vier Zustände sollten erhalten bleiben: gemeldet wahr, gemeldet falsch, ausdrücklich leer und nicht gemeldet. Dazu kommen Produzent, Modellversion und Beobachtungszeit.

Fünf Ausbaustufen

Level 1 umfasst den zentralen Katalog. Level 2 ergänzt installierte Lizenzen je Asset. Level 3 meldet Fähigkeiten. Level 4 verknüpft Fähigkeiten mit Lizenzen und liefert allowed sowie in-use. Level 5 ergänzt globale und funktionsbezogene Einschränkungen.

Implementierungen sollen ihren Umfang und Abweichungen dokumentieren. Ein Level-1-System beantwortet Einkaufsfragen, nicht den lokalen Zulassungszustand. Level 3 zeigt technisches Potenzial ohne Lizenzschluss. Level 4 kann eine Erlaubnis melden, ohne den gemeinsam genutzten Pool atomar zu verwalten.

In Ausschreibungen sollte deshalb nicht nach einem Feature-Namen, sondern nach Datenbeispielen, Ausfallsemantik, Aktualisierung und Provenienz pro Level gefragt werden.

allowed ist das Ergebnis einer Regel

Benötigt eine Fähigkeit mehrere Entitlements, muss allowed deren kombinierte Wirkung abbilden. Fehlt eine notwendige Lizenz oder ist sie expired beziehungsweise revoked, sollte der Wert false sein.

Zur Prüfung gehören die vollständige Abhängigkeitsmenge, frische Zustände, Kombinationsregel und Entscheider. Ein unbekannter Zusatz kann zu großzügig, eine unbekannte Kulanzperiode zu streng machen. Der Boolean erbt alle Grenzen seiner Eingaben.

Er ersetzt außerdem keine Benutzerberechtigung. RFC 8341 regelt mit NACM, welcher NETCONF- oder RESTCONF-Principal auf Operationen und Daten zugreifen darf. Das Entitlement betrifft das Recht der Organisation, eine Fähigkeit zu nutzen. Lizenz und Benutzerrolle können einander nicht erzeugen.

Selbst beide positiven Entscheidungen garantieren keine Ausführung. Hardware, Softwarestand, Ressourcen, Konfiguration und Topologie können die Funktion verhindern.

Nutzung ist beobachterabhängig

in-use kann an einer installierten Lizenz und an einer Fähigkeit erscheinen. Beide Werte sollen konsistent sein. Offen bleibt dennoch, was Nutzung misst.

Ein Server zählt ausgeliehene Seats, ein Gerät vorhandene Konfiguration, ein Controller den letzten Status, der Betrieb aktive Sessions oder Pakete. Diese Beobachtungen besitzen unterschiedliche Reichweite. Für Routing sind konfigurierte Instanz, laufender Prozess, Adjazenz, Route, FIB und Nutzverkehr getrennte Stufen.

Der Nutzungsbeleg braucht Auslöser, Sensor, Zeit, Ablaufbedingung und möglichst eine unabhängige Betriebsbeobachtung.

Grenzen ohne Reservierung

Das Modell stellt Ressource, Einheit, Maximum und Istwert bereit. Ein Istwert von 80 bei Maximum 100 ist kein Versprechen, weitere 20 atomar vergeben zu können. Der Wert kann alt sein, zwei Controller können gleichzeitig zugreifen, oder ein Parent-Pool kann mehrere Kinder speisen.

Hierarchische Entitlements können über parent IDs verknüpft werden. YANG verhindert direkte Selbstreferenz, aber nicht jeden tieferen Zyklus. Das Managementsystem muss A→B→A erkennen. Schema-Gültigkeit beweist weder einen gültigen Rechtegrapfen noch eine konfliktfreie Reservierung.

Zu jedem Limit gehören Scope, Einheit, Messfenster, Quelle, Zeitpunkt, Reset und Reservierungszustand.

Read-only ist keine Wahrheitsgarantie

Alle Datenknoten sind config false. Das Modul meldet Zustand, verändert ihn aber nicht. Lizenzserver und Asset-Plattformen schreiben die zugrunde liegende Realität über externe Kanäle, die außerhalb des Entwurfs liegen.

Ein sicher authentifizierter NETCONF- oder RESTCONF-Transport kann einen veralteten Wert korrekt übertragen. Die Security Considerations warnen, dass manipulierte externe Kanäle falsche Entitlement-Zustände einspeisen und Fähigkeiten fälschlich erlaubt oder beschränkt erscheinen lassen können.

Der Entwurf empfiehlt, Abweichungen zwischen zentralem Bestand, lokaler Installation und tatsächlicher Nutzung zu erkennen. Er definiert keinen universellen Vorrang. Ablaufdaten werden exponiert, nicht die Benachrichtigung. Wer warnt, eskaliert, verlängert und die Verlängerung bestätigt, bleibt eine Betriebsentscheidung.

Neun Belege statt eines grünen Feldes

Eine tragfähige Kette enthält Grant, Assignment, Activation, Dependency Closure, Permission, NACM Access, Usage, Restriction Enforcement und Service Outcome. Jeder Beleg nennt Akteur, Objekt und Zeitpunkt.

Die Daten dürfen verteilt bleiben. Entscheidend ist, dass Übergänge referenzierbar sind und Widersprüche nicht überschrieben werden. Das Inventar ist am glaubwürdigsten, wenn es die Grenze seiner eigenen Autorität offenlegt.

Quellen