Zusammenfassung

  • draft-ietf-ivy-entitlement-inventory-05 schlägt ein schreibgeschütztes YANG-Modell für Berechtigungen, Fähigkeiten und Beschränkungen vor. Es ist ein aktiver Internet-Draft, weder RFC noch Einsatznachweis.
  • „Installed entitlement“ kann lokale Aktivierung oder nur eine logische Zuordnung im zentralen System bedeuten. Die Datenquelle gehört deshalb zur Aussage.
  • allowed, in-use und die tatsächlich erbrachte Dienstleistung sind getrennte Behauptungen. Ein gemeinsamer Datenbaum macht sie vergleichbar, aber nicht austauschbar.

Ein Asset-System meldet für Router r9 die Berechtigung ent-47 als installiert. Das kann bedeuten, dass das Gerät einen Lizenznachweis erhalten und geprüft hat. Es kann ebenso bedeuten, dass ein zentraler Datensatz dem Router einen Vertrag zugeordnet hat, während der Router selbst nichts davon weiß. Beide Meldungen können im Kontext ihrer Quelle korrekt sein. Falsch wird es erst, wenn eine Anwendung daraus denselben Laufzeitstatus ableitet.

Revision 05 umfasst diese Breite ausdrücklich. Im Geltungsbereich gilt eine installierte Berechtigung als einem Netzwerk-Asset zugeordnet; die „Installation“ kann direkte Provisionierung oder logische Zuordnung in einem zentralen System sein. Die Begriffsdefinition beschreibt Installed Entitlement zugleich als lokal aktiviert und für Gerätefunktionen verfügbar. Ein portabler Begriff liegt damit über mehreren Beweisketten.

Die drei Bereitstellungsmodelle zeigen, warum. Erstens kann die Berechtigung lokal auf dem Asset liegen und dort erzwungen werden. Zweitens kann ein externer Lizenzserver den Status liefern. Drittens kann ein Handelsvertrag außerhalb des Assets verwaltet werden, ohne dass das Netzwerkelement die Berechtigung kennt. Gerät, Lizenzdienst und Monitoring können jeweils Teile desselben Modells darstellen. Eine Zusammenführung muss die Zeugen erhalten, nicht verwischen.

Das Modell unterstützt deshalb fünf Ausbaustufen. Stufe 1 ist der zentrale Katalog. Stufe 2 ordnet Berechtigungen Assets zu. Stufe 3 beschreibt Fähigkeiten. Stufe 4 verbindet Fähigkeiten mit unterstützenden Berechtigungen und meldet allowed sowie in-use. Stufe 5 ergänzt globale und funktionsbezogene Grenzen, etwa Installationszahl, Durchsatz oder Verbindungen.

Diese Stufen begrenzen, was behauptet werden darf. Ein Unternehmenskatalog beweist nicht, was auf einem Gerät ankam. Eine Zuordnung beweist keine Aktivierung. Eine Fähigkeitenliste nennt nicht zwingend die erforderliche Lizenz. Erst die Verbindung in Stufe 4 beantwortet die Autorisierungsfrage, und erst Stufe 5 liefert Beschränkungen. Wer eine Teilimplementierung wie eine vollständige behandelt, erzeugt Gewissheit, die der Produzent nie gemeldet hat.

Presence Container tragen eine besonders wichtige Semantik. Ihr Fehlen bedeutet, dass das System diese Information nicht berichten kann. Es bedeutet nicht automatisch, dass die Berechtigung, Fähigkeit oder Beschränkung nicht existiert. Automatisierung muss unbekannt von falsch trennen. Andernfalls kann sie funktionierende Kapazität abschalten oder unbewiesene Kapazität freigeben.

Auch allowed und in-use haben klare Grenzen. Benötigt eine Fähigkeit mehrere Berechtigungen, soll allowed deren gemeinsame Wirkung abbilden; fehlt eine, ist sie abgelaufen oder widerrufen, soll der Wert falsch sein. in-use meldet eine aktuell operative Fähigkeit. Beide Werte bleiben jedoch Beobachtungen in einem reinen Lesemodell. Sie sind kein Aktivierungsbefehl, keine Konfigurationstransaktion, keine unabhängige Telemetrie und kein unveränderlicher Beleg für den Kundendienst.

Der Entwurf verlangt sogar Mechanismen zur Erkennung von Abweichungen zwischen zentralen Datensätzen, lokal installierten Berechtigungen und tatsächlicher Fähigkeitsnutzung. Diese Anforderung ist die wichtigste Lesehilfe: Die Ebenen können auseinanderlaufen. Das Inventar soll die Differenz sichtbar machen, nicht durch ein letztes Schreibereignis verdecken.

Hinzu kommt die vom Anbieter bestimmte Granularität. Ein Hersteller darf eine grobe Fähigkeit wie Advanced Services melden; ein anderer listet MPLS, BGP und QoS einzeln. allowed: true ist nur zusammen mit Definition, Version und Asset-Kontext verständlich. Das gemeinsame Schema normiert die Beziehung, nicht jede Produktgrenze.

Automatische Erkennung gehört nicht zum aktuellen Umfang. Beziehungen können im Lizenzserver provisioniert, vom Gerät berichtet oder manuell gepflegt werden. Ebenso definiert das Modell keine Ablaufbenachrichtigung. Es liefert Daten, aus denen eine externe Anwendung Warnungen erzeugen kann. Ein Datum ist aber noch kein zugestellter Alarm.

Sichere Übertragung löst ein anderes Problem. NETCONF und RESTCONF können mit gegenseitiger Authentisierung arbeiten, NACM kann den Lesezugriff auf sensible Produkt-, Vertrags- und Fähigkeitsdaten begrenzen. Das schützt den Bericht, bestätigt aber nicht die Richtigkeit des vorgelagerten Systems. Der Entwurf warnt ausdrücklich, dass eingeschleuster falscher Status Fähigkeiten fälschlich als erlaubt oder beschränkt erscheinen lassen kann.

Auch der Dokumentstatus ist begrenzt. Revision 05 trägt das Datum 29. September 2026 und zielt auf den Standards Track, bleibt aber ein Internet-Draft. Ein validiertes Modul oder späterer IANA-Eintrag beweist weder endgültige Annahme noch Herstellerunterstützung, Vollständigkeit, Aktualität oder den Zustand eines bestimmten Netzes.

Der eigentliche Fortschritt liegt daher in der Trennung: kommerzielles Recht, Katalogeintrag, Asset-Zuordnung, lokale Aktivierung, Fähigkeitserlaubnis, gemeldete Nutzung und Serviceergebnis können einzeln adressiert werden. Gefährlich wird das Inventar erst, wenn eine Oberfläche daraus einen einzigen grünen Haken macht.

Quellen