A YANG Module for Entitlement Inventory

Modeling Capabilities and Entitlements The model describes how to represent capabilities and the entitlements that enable them across inventoried network assets. Capabilities describe what an asset can do. Entitlements indicate whether those capabilities are allowed and under what conditions.

Relationship Between Entitlements and Capabilities The following subsections describe how the model progressively builds upon the base network inventory to incorporate capabilities, entitlements, and their relationships. The model uses identity-based classes in multiple parts to enable extensibility, allowing implementations to derive custom types that reference external definitions when needed.

Foundational model: NetworkElement-Entitlements-Capabilities and Restrictions To represent the complex relationships between network elements, capabilities, and entitlements, a foundational Network Inventory model should be built through a series of extensions. The following diagrams illustrate the progressive complexity of the approach, starting with simple network inventory extensions and culminating in a comprehensive model incorporating capabilities, entitlements, and restrictions.

Progressive Model Complexity depicts the initial step, highlighting the base network inventory and the areas to be extended: hardware, software, and entitlements. These extensions are necessary to properly model the relationships.

Base Network Inventory Entitlement extension illustrates the initial relationship between network elements and entitlements, which is two-way: entitlements SHOULD be attached to NEs, and NEs SHOULD have entitlements installed.

Relationship between entitlements and Base Inventory ───────┘ │ └───────────────────<──>──────────────────┘ ]]> depicts NE support capabilities by means of entitlements that authorize their use.

Capabilities integration with the Base Inventory │ Capabilities │<──────────┘ └────────────────┘ ]]> Finally, NE support capabilities thanks to entitlements that entitle them of their use under certain constraints as shown in .

Complete model with restrictions │ Capabilities │<──────────┘ └──────┬─────────┘ │ │constrained by ┌──────V─────────┐ │ Restrictions │ └────────────────┘ ]]>

Capabilities Capabilities are modeled by augmenting "network-element" in the "ietf-network-inventory" module in according to the following tree: ../../../../../../installed-entitlements/entitlement/entitlement-id +--ro capability-restrictions! +--ro capability-restriction* [restriction-id] +--ro restriction-id string +--ro description? string +--ro resource-name? string +--ro units? string +--ro max-value? int32 +--ro current-value? int32 ]]> For any given network asset, the capabilities list MAY include all potential capabilities advertised by the vendor, and MUST include those for which the network operator holds a valid entitlement—whether active or not. This document does not define a complete theory of capabilities or their internal relationships; such work may be addressed elsewhere. Instead, the model provides a flexible framework through the use of identity-based capability classes:

Basic capability class: The module defines basic-capability-description as a simple capability class using only identifiers and descriptions. This supports implementations that present capabilities as straightforward lists.
Extended capability classes: For structured capability definitions, implementations derive new identities from capability-class. These reference external YANG modules where capabilities have formal structure and semantics. (TBU - See Section X for extension examples.)

This separation ensures that capability definitions can evolve independently of the entitlement inventory model, and that implementations can adopt capability models appropriate to their domain without modifications to this base module. The granularity at which capabilities are defined is at the discretion of the vendor. A vendor MAY choose to advertise capabilities at a high level of abstraction, such as "Advanced Services", and consumers of this information should refer to vendor documentation to understand what specific functions are included. Alternatively, an implementation MAY enumerate capabilities at a finer granularity, listing individual protocols or features such as MPLS, BGP, or QoS. The model accommodates both approaches. The capabilities of an inventoried network asset may be restricted based on the availability of proper entitlements. An entitlement manager should be interested in the capabilities available to be used on the network assets, and the capabilities that are currently available. The model includes this information by means of the "supporting entitlements" list, which references installed entitlements and includes potential restrictions related to the status of the entitlement. This allows organizations to monitor entitlement usage and avoid misconfigurations or exceeding permitted capability limits.

Extending Capability Classes The capability-class identity provides an extension point for integrating external capability models. This module does not define domain-specific capability classes. Instead, extensions derive new capability classes that reference separate models where capabilities are formally defined. The extension pattern involves two modules:

Capability definition module: An independent module defining capability concepts with its own structure (lists, containers, attributes). This module has no dependency on the entitlement inventory.
Integration module: An extension module that derives a new capability-class identity and augments the entitlement inventory to reference the capability definitions from the first module.

This pattern ensures that:

Capability models evolve independently of entitlement tracking.
Multiple capability domains can coexist (e.g., routing capabilities, security capabilities, QoS capabilities) each with their own defining module.
The entitlement inventory remains a thin integration layer rather than a repository of capability definitions.

The following example module defines capability concepts for a specific domain: The following extension module extends the capability-class identity and augments the entitlement inventory to reference the capability definitions from the module above: This pattern allows capability definitions to evolve independently while maintaining a clean integration with the entitlement inventory through the capability-class identity mechanism.

Entitlements The entitlement modeling augments "network-inventory" in the ietf-network-inventory module in with a top-level entitlements container according to the following tree: ../../entitlement/entitlement-id +--ro entitlement-attachment +--ro universal-access? boolean +--ro holders | +--ro organizations_names | | +--ro organizations* string | +--ro users_names | +--ro users* string +--ro assets +--ro elements | +--ro network-elements* -> /inv:network-inventory/network-elements/network-element/ne-id +--ro components +--ro component* [network-element component-id] +--ro network-element -> /inv:network-inventory/network-elements/network-element/ne-id +--ro component-id -> /inv:network-inventory/network-elements/network-element[inv:ne-id=current()/../network-element]/components/component/component-id ]]> depicts the relationship between the Entitlement Inventory model and other models. The Entitlement Inventory model enhances the model defined in the base network inventory model with entitlement-specific attributes and centralized entitlement management capabilities.

Relationship of Entitlement Inventory Model to Other Inventory Models Entitlements MUST be listed at the top level, directly under the network-inventory container. This is required because organizations may own entitlements that are not yet assigned to any network asset. Such entitlements exist in a pending state, available for future assignment or installation when the organization decides to allocate them to specific assets. Entitlements may be listed without explicitly identifying the assets (network elements or components) they apply to. Entitlements are linked to network assets in multiple ways: (1) When entitlements are created for specific assets (i.e., they should only be installed on those), then those assets are specified under the entitlement's attachment section. (2) When an entitlement is installed on a network asset, it appears in the asset's installed-entitlements list. (3) When an installed entitlement enables capabilities, the asset's capabilities will reference the installed entitlement via the supporting-entitlements list. The base network inventory model includes both network elements and components within them. A network element is an abstraction that typically represents a complete device such as a router or switch. For single-chassis devices, entitlements are typically associated with the network element itself rather than with individual chassis components. However, certain deployment scenarios involve multi-chassis systems, such as stacked switches or optical network elements—where multiple physical units operate as a single logical network element. In these cases, each component may have its own commercial identity (such as a serial number) while the collection behaves as one network element. Entitlements are typically assigned based on commercial identifiers, often targeting serial numbers. The model supports linking entitlements to both network elements and individual components. However, component-level entitlement tracking is RECOMMENDED only when necessary—specifically when each component has its own set of capability limitations that must be managed independently. Examples include:

Individual switches in a stack, where each unit has separate entitlements;
Individual chassis in a multi-chassis network element, such as optical equipment; or
Pay-as-you-grow routers where line cards have independent entitlement requirements.

In the YANG model, both network elements and components are supported by providing augmentations to each. Entitlements and network assets are linked in the model in multiple ways. Entitlements at the network-inventory level should be attached to network assets through their attachment mechanism, representing organizational entitlements. Network assets have their own installed-entitlements that may be derived from the centralized entitlements or assigned directly. The capabilities of network assets reference these installed entitlements through their supporting-entitlements lists. The former addresses the case of a centralized license server or inventory system, while the latter represents entitlements that are actively entitling the asset's capabilities. An installed entitlement that is not referenced by any capability means that it is active on the asset but not currently in use. Entitlements are managed both centrally at the network-inventory level and at the asset level through installed-entitlements. Network assets reference their installed entitlements through their capabilities' supporting-entitlements lists. For instance, a license server or inventory system should list an entitlement at the top level, which then gets installed on specific network assets where the capabilities reference the active entitlement. Each installed entitlement references its centralized entitlement directly via the entitlement-id leafref. For hierarchical or pooled entitlements (e.g., a base license with add-on upgrades), the "parent-entitlement-uid" field in the centralized entitlement catalog links child entitlements to their parent. Proper identification of entitlements is imperative to ensure consistency across systems, enabling monitoring systems to recognize when multiple locations reference related entitlements.

Reverse Mapping from Entitlements to Capabilities While the model includes links from capabilities to supporting entitlements, some inventory operators may need to evaluate entitlements independently and identify the capabilities they enable. To support this, implementers may use the "product-id" or "capability-class" metadata along with external references or catalogs. Implementations requiring reverse mapping (identifying capabilities enabled by a specific entitlement) may leverage vendor-specific augmentations or external entitlement catalogs. Standardization of such reverse mappings is outside the scope of this document.

Entitlement Attachment The "entitlement" container holds a container called "entitlement-attachment" which relates how the entitlement is operationally linked to holders or network assets. Note that there is a difference between an entitlement being attached to a network asset and an entitlement being installed on the asset. In the former, the license was explicitly associated with one or more assets. Some licenses actually can be open but have a limited number of installations. Other licenses should be openly constrained to a geographic location. We are not dealing with these complex cases now, but the container can be expanded for this in the future. The model accommodates listing entitlements acquired by the organization but not yet applied or utilized by any actor/asset at the network-inventory level. For these pending entitlements, they can be managed centrally without requiring individual network assets to be aware of their existence. Some entitlements are inherently associated with a holder, such as organization or a user. For example, a software license may be directly attached to a user. Also, the use of a network device may come with a basic license provided solely to an organization. Some entitlements could be assigned to a more abstract description of holders, such as people under a jurisdiction or a geographical area. The model contains basic information about this, but it can be extended in the future to be more descriptive. While attachment is optional, the model should be capable of expressing attachment in various scenarios. The model can be expanded to list to which network assets an entitlement is aimed for, when this link is more vague, such as a site license (e.g., network assets located in a specific site), or more open licenses (e.g., free software for all users subscribed to a streaming platform). The current model does not provide information on whether an entitlement can be reassigned to other network assets. Such scenarios fall under the "what if" category, which is not covered by this model.

Installed Entitlements Since capabilities are optional in network assets, the model also provides an augmentation to track entitlements that are installed directly on network assets. This augmentation of "network-element" and "component" in the "ietf-network-inventory" module provides local entitlement storage according to the following tree: /inv:network-inventory/ei:entitlements/entitlement/entitlement-id +--ro in-use? boolean ]]> The installed entitlements represent references to entitlements that are currently active and entitling the network asset. The "entitlement-id" field provides a direct reference to the centralized entitlement at the network-inventory level. This structure allows network assets to track which entitlements are actively granting them rights, while maintaining the ability to trace relationships to organization-wide entitlement policies. When entitlements are installed at the component level (e.g., line cards), implementations MAY also list them at the parent network-element level to provide a consolidated view of all entitlements active on the device. Management systems should recognize when an entitlement-id appears at both levels and treat them as the same license instance to avoid double-counting. This point requires further exploration in future instances of this document.

Implementation Considerations The model is designed to support partial implementations. Not all systems need to implement every container or feature. The use of presence containers throughout the model allows implementations to signal which parts of the model they support. An implementation that does not populate a presence container indicates that it cannot report that information. The following progression describes how implementations can adopt the model incrementally, from basic entitlement tracking to full capability and restriction reporting:

Level 1: Centralized Entitlement Inventory The minimal implementation populates the top-level entitlements container under network-inventory. This provides a centralized catalog of all entitlements owned or managed by the organization, including their identifiers, vendors, states, and validity periods. At this level, the system answers: What entitlements does the organization have?

Level 2: Installed Entitlements on Assets Building on Level 1, implementations can populate the installed-entitlements container on network elements and/or components. This tracks which entitlements are currently active and entitling each network asset, by referencing the centralized entitlement catalog. At this level, the system additionally answers: Which entitlements are actively entitling which assets?

Level 3: Capabilities Reporting Implementations that can report device capabilities populate the capabilities container on network elements and/or components. This lists what functions each asset can perform, organized by capability class. At this level, the system additionally answers: What can each asset do?

Level 4: Capability-Entitlement Linkage Advanced implementations populate the supporting-entitlements container within each capability. This links capabilities to the installed entitlements that enable them, along with the entitlement-state container indicating whether each capability is allowed and in use. When a capability lists multiple supporting entitlements, the entitlement-state/allowed field MUST reflect the combined effect of all required entitlements. If any required entitlement is missing, expired, or revoked, allowed should be false. The in-use field indicates whether the capability is currently operational. At this level, the system additionally answers: Which entitlements enable which capabilities? What is allowed and what is in use?

Level 5: Restrictions Reporting Full implementations populate restriction information at two levels:

The restrictions container under each entitlement for global restrictions (e.g., total allowed installations, aggregate usage limits)
The capability-restrictions container within each capability for capability-specific limits (e.g., maximum throughput, connection limits)

At this level, the system additionally answers: What constraints apply to entitlements and capabilities? What are the current usage levels? Implementations SHOULD document which levels they support and any deviations from this progression.

Model Definition WG List: Author: Marisol Palmero Author: Camilo Cardona Author: Diego Lopez Author: Italo Busi "; description "A YANG module for Entitlement Inventory, as per draft-ietf-ivy-entitlement-inventory-01. Copyright (c) 2025 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, they appear in all capitals, as shown here. "; revision 2025-10-20 { description "First full draft version for draft-ietf-ivy-entitlement-inventory"; reference "draft-ietf-ivy-entitlement-inventory-01"; } identity capability-class { description "Base identity for capability classes."; } identity basic-capability-description { base capability-class; description "Basic capability class for general capability descriptions."; } typedef entitlement-state-t { type enumeration { enum active { description "Entitlement is active."; } enum expired { description "Entitlement is expired."; } enum pending { description "Entitlement is pending activation."; } enum revoked { description "Entitlement is revoked."; } } description "State of the entitlement."; } grouping restriction-fields { description "Common fields for describing restrictions or limits. Used both for capability-level restrictions and entitlement-level global restrictions."; leaf description { type string; description "Human-readable description of the restriction."; } leaf resource-name { type string; description "Optional name of the physical or network resource being restricted (e.g., 'bandwidth', 'throughput', 'storage', 'memory')."; } leaf units { type string; description "Units for the restriction values (e.g., 'Mbps', 'connections', 'tunnels')."; } leaf max-value { type int32; description "Maximum permitted value for this restriction."; } leaf current-value { type int32; description "Current usage or consumption of this restricted resource at query time."; } } grouping installed-entitlements-group { description "Grouping for installed entitlements that can be applied to network elements or components (generally called asset over this document)."; container installed-entitlements { presence "The presence of this container means the information system that exposes this model knows of the installed entitlements of the asset that it populates. An empty list of entitlements would then mean that no entitlement is installed in this asset."; config false; description "Entitlements currently active and entitling this asset."; list entitlement { key "entitlement-id"; description "List of entitlements actively entitling this asset. Each entitlement references a global listed entitlement."; leaf entitlement-id { type leafref { path "/inv:network-inventory/ei:entitlements" + "/ei:entitlement/ei:entitlement-id"; } description "Reference to centralized entitlement."; } leaf in-use { type boolean; description "Informs whether the entitlement is actively used, besides being installed. If existing, and if the capabilities list exist and the information system supports setting their entitlement-state, this information MUST be consistent with it. Meaning, this should be in-use if any capability it supports is in-use, or false otherwise. The no presence of this leaf means that the information system cannot express this information"; } } } } grouping capabilities-group { description "Grouping for capabilities that can be applied to assets. Capabilities represent what the asset can do, potentially restricted by entitlements."; container capabilities { presence "The presence of this container means the information system that exposes this model is aware of and can report the capabilities of this asset (i.e. network element or component). An empty list of capability classes would mean that the element has no capabilities configured or available."; config false; description "Container for capabilities of this asset."; list capability-class { key "capability-class"; description "List of capability classes supported by this asset. Each class groups related capabilities."; leaf capability-class { type identityref { base capability-class; } description "Identifier for the capability class using an identity reference."; } list capability { key "capability-id"; description "Individual capability within this class. Represents a specific function or feature that the element may perform."; leaf capability-id { type string; description "Unique identifier for this capability."; } leaf extended-capability-description { type string; description "Extended capability description."; } container entitlement-state { presence "The presence of this container indicates the system can report whether this capability is allowed and/or in use based on entitlement status."; description "Reports whether this capability is permitted by entitlements and whether it is currently in active use."; leaf allowed { type boolean; description "Whether the capability is allowed by entitlements."; } leaf in-use { type boolean; description "Whether the capability is currently in use."; } } container supporting-entitlements { presence "The presence of this container indicates the system can report the entitlement(s) supporting the use of this capability by the asset to its current allowed state. this container should not exist if the system cannot report this. An empty list of supporting-entitlement means the capability requires no special entitlement to be provided."; description "List of installed entitlements that enable or support this capability."; list supporting-entitlement { key "entitlement-id"; description "List of installed entitlements that enable or support this capability. The capability may require one or more entitlements to be allowed and in use."; leaf entitlement-id { type leafref { path "../../../../../../installed-entitlements" + "/entitlement/entitlement-id"; } description "Reference to an installed entitlement supporting this capability."; } } } container capability-restrictions { presence "The presence of this container indicates that the system can report the current capability restrictions. If present, an empty list of capability-restriction means the capability has no restriction."; description "Restrictions or limits imposed on this capability by entitlements."; list capability-restriction { key "restriction-id"; description "Restrictions or limits imposed on this capability by entitlements."; leaf restriction-id { type string; description "Unique identifier for this capability restriction."; } uses restriction-fields; } } } } } } augment "/inv:network-inventory/inv:network-elements" + "/inv:network-element" { description "Augments network elements with installed entitlements tracking which entitlements are currently active and entitling the device."; uses installed-entitlements-group; } augment "/inv:network-inventory/inv:network-elements" + "/inv:network-element/inv:components/inv:component" { description "Augments network element components with installed entitlements for component-level tracking."; uses installed-entitlements-group; } augment "/inv:network-inventory/inv:network-elements" + "/inv:network-element" { description "Augments network elements with capabilities information, describing what functions the element can perform and their entitlement status."; uses capabilities-group; } augment "/inv:network-inventory/inv:network-elements" + "/inv:network-element/inv:components/inv:component" { description "Augments network element components with capabilities for component-level feature tracking and entitlement restrictions."; uses capabilities-group; } augment "/inv:network-inventory" { description "Augments the network inventory with a centralized entitlements catalog. This provides organization-wide visibility of all acquired entitlements, their holders, validity periods, and asset associations."; container entitlements { presence "The presence of this container indicates the system maintains and can report the organizational entitlement catalog. An empty list means the organization has no entitlements defined."; config false; description "Top-level container for organizational entitlements."; list entitlement { key "entitlement-id"; description "List of entitlements owned or managed by the organization. Each entitlement represents a license, right, or permission to use specific capabilities, potentially with restrictions on scope, time, or usage."; leaf entitlement-id { type string; description "Unique entitlement identifier."; } leaf product-id { type string; description "Product identifier for this entitlement."; } leaf sku { type string; description "Stock Keeping Unit - vendor's catalog/ordering number for this entitlement. Used for procurement and asset management integration."; } leaf vendor { type string; description "Vendor or issuer of this entitlement. Identifies the license provider."; } leaf part-number { type string; description "Manufacturer's part number. May differ from SKU in distribution channels."; } leaf state { type entitlement-state-t; description "Current state of the entitlement."; } container renewal-profile { description "Renewal and validity information for the entitlement."; leaf activation-date { type yang:date-and-time; description "Date when entitlement was activated."; } leaf start-date { type yang:date-and-time; description "Start date of entitlement validity."; } leaf expiration-date { type yang:date-and-time; description "Expiration date of the entitlement."; } } container restrictions { presence "The presence of this container means the system can provide information of global restrictions for this entitlement. An empty list will then mean that the entitlement has no global restriction."; description "Global restrictions imposed by this entitlement."; list restriction { key "restriction-id"; description "List of restrictions that apply globally to this entitlement across all assets and holders. These may include usage limits, quotas, or other constraints on how the entitlement can be utilized."; leaf restriction-id { type string; description "Unique restriction identifier."; } uses restriction-fields; } } leaf parent-entitlement-uid { type leafref { path "../../entitlement/entitlement-id"; } must '. != ../entitlement-id' { error-message "An entitlement cannot reference itself as its parent."; } description "Reference to parent entitlement if this is derived."; } container entitlement-attachment { description "Defines how the entitlement is attached to holders and assets."; leaf universal-access { type boolean; description "True if entitlement has universal access."; } container holders { description "Holders of this entitlement. This is for information purposes only, it does not apply any restrictions on who can use or not the asset where assigned to the entitlement."; container organizations_names { description "Organization holders."; leaf-list organizations { type string; description "List of organization names."; } } container users_names { description "User holders."; leaf-list users { type string; description "List of user names."; } } } container assets { description "Assets to which this entitlement is attached."; container elements { description "Network elements covered by this entitlement."; leaf-list network-elements { type leafref { path "/inv:network-inventory" + "/inv:network-elements/inv:network-element" + "/inv:ne-id"; } description "References to network elements covered by this entitlement. When specified, this entitlement applies to the listed network elements."; } } container components { description "Individual components covered by this entitlement."; list component { key "network-element component-id"; description "List of specific components to which this entitlement applies. Allows fine-grained entitlement assignment at the component level rather than entire network elements."; leaf network-element { type leafref { path "/inv:network-inventory" + "/inv:network-elements" + "/inv:network-element/inv:ne-id"; } description "Reference to network element."; } leaf component-id { type leafref { path "/inv:network-inventory" + "/inv:network-elements" + "/inv:network-element" + "[inv:ne-id=current()/../network-element]" + "/inv:components/" + "inv:component/inv:component-id"; } description "Reference to component within the specified network element."; } } } } } } } } } ]]>

Model tree /inv:network-inventory/ei:entitlements/entitlement/entitlement-id +--ro in-use? boolean augment /inv:network-inventory/inv:network-elements/inv:network-element/inv:components/inv:component: +--ro installed-entitlements! +--ro entitlement* [entitlement-id] +--ro entitlement-id -> /inv:network-inventory/ei:entitlements/entitlement/entitlement-id +--ro in-use? boolean augment /inv:network-inventory/inv:network-elements/inv:network-element: +--ro capabilities! +--ro capability-class* [capability-class] +--ro capability-class identityref +--ro capability* [capability-id] +--ro capability-id string +--ro extended-capability-description? string +--ro entitlement-state! | +--ro allowed? boolean | +--ro in-use? boolean +--ro supporting-entitlements! | +--ro supporting-entitlement* [entitlement-id] | +--ro entitlement-id -> ../../../../../../installed-entitlements/entitlement/entitlement-id +--ro capability-restrictions! +--ro capability-restriction* [restriction-id] +--ro restriction-id string +--ro description? string +--ro resource-name? string +--ro units? string +--ro max-value? int32 +--ro current-value? int32 augment /inv:network-inventory/inv:network-elements/inv:network-element/inv:components/inv:component: +--ro capabilities! +--ro capability-class* [capability-class] +--ro capability-class identityref +--ro capability* [capability-id] +--ro capability-id string +--ro extended-capability-description? string +--ro entitlement-state! | +--ro allowed? boolean | +--ro in-use? boolean +--ro supporting-entitlements! | +--ro supporting-entitlement* [entitlement-id] | +--ro entitlement-id -> ../../../../../../installed-entitlements/entitlement/entitlement-id +--ro capability-restrictions! +--ro capability-restriction* [restriction-id] +--ro restriction-id string +--ro description? string +--ro resource-name? string +--ro units? string +--ro max-value? int32 +--ro current-value? int32 augment /inv:network-inventory: +--ro entitlements! +--ro entitlement* [entitlement-id] +--ro entitlement-id string +--ro product-id? string +--ro sku? string +--ro vendor? string +--ro part-number? string +--ro state? entitlement-state-t +--ro renewal-profile | +--ro activation-date? yang:date-and-time | +--ro start-date? yang:date-and-time | +--ro expiration-date? yang:date-and-time +--ro restrictions! | +--ro restriction* [restriction-id] | +--ro restriction-id string | +--ro description? string | +--ro resource-name? string | +--ro units? string | +--ro max-value? int32 | +--ro current-value? int32 +--ro parent-entitlement-uid? -> ../../entitlement/entitlement-id +--ro entitlement-attachment +--ro universal-access? boolean +--ro holders | +--ro organizations_names | | +--ro organizations* string | +--ro users_names | +--ro users* string +--ro assets +--ro elements | +--ro network-elements* -> /inv:network-inventory/network-elements/network-element/ne-id +--ro components +--ro component* [network-element component-id] +--ro network-element -> /inv:network-inventory/network-elements/network-element/ne-id +--ro component-id -> /inv:network-inventory/network-elements/network-element[inv:ne-id=current()/../network-element]/components/component/component-id ]]>

Example	Title	Complexity	Key Concepts	Operational Question Addressed
1	Basic Structure	Simple	Fundamental relationships, entitlement states	What are the core components of the model?
2	Expired License Handling	Simple	Lifecycle management, state transitions	How does the model handle expired entitlements?
3	Utilization Tracking	Moderate	Restrictions, usage monitoring	What constraints apply and how to track usage?
4	Hierarchical Entitlements	Moderate	Parent-child relationships, tiered licensing	How to model license upgrades and dependencies?
5	License Pooling	Advanced	Shared entitlements, multi-device allocation	How to manage pooled licenses across devices?
6	Multi-Vendor Environment	Advanced	Heterogeneous networks, vendor diversity	How to unify entitlements across vendors?
7	Component-Level Entitlements	Advanced	Modular devices, granular licensing	How to track entitlements for device components?
8	Capability Class Extension	Expert	Extensibility, external references	How to integrate custom capability models?

Aspect	Impact	Remediation
Security capabilities	Disabled, features stopped	Renew ent-sec-001 or purchase new license
Routing capabilities	Unaffected, continue operating	Monitor expiration date (2025-06-30)
Device operation	Continues with reduced functionality	Plan renewal before 2025-06-30
Compliance risk	Potential breach if security required	Immediate action if security is mandatory