Network Inventory YANG WG M. Palmero Internet-Draft Independent Intended status: Informational C. Cardona Expires: 8 January 2026 NTT D. Lopez Telefonica 7 July 2025 A YANG Module for Entitlement Inventory draft-mcd-ivy-entitlement-inventory-01 Abstract This document proposes a YANG module for incorporating entitlements in a network inventory of entitlements. Entitlements define the rights for their holder to use specific capabilities in a network element(s). The model is rooted by the concept of the capabilities offered by an element, enabled by the held entitlements, and considers entitlement scope, how they are assigned, and when they expire. The model introduces a descriptive definition of capabilities and the entitlement use restrictions, supporting entitlement administration and the understanding of the capabilities available through the network. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://dr2lopez.github.io/ivy-capability-entitlement/draft-mcd-ivy- entitlement-inventory.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-mcd-ivy- entitlement-inventory/. Discussion of this document takes place on the Network Inventory YANG WG Working Group mailing list (mailto:inventory-yang@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/inventory- yang/. Subscribe at https://www.ietf.org/mailman/listinfo/inventory- yang/. Source for this draft and an issue tracker can be found at https://github.com/dr2lopez/ivy-capability-entitlement. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Palmero, et al. Expires 8 January 2026 [Page 1] Internet-Draft almo-entitlement-inventory July 2025 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 8 January 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope of the Entitlement Model . . . . . . . . . . . . . 4 1.2. Pre-Provisioned vs. Discovered Entitlements . . . . . . . 5 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 3. Modeling Capabilities and Entitlements . . . . . . . . . . . 6 3.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Entitlements . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Reverse Mapping from Entitlements to Capabilities . . 9 3.3. Entitlement Attachment . . . . . . . . . . . . . . . . . 9 3.4. Model Definition . . . . . . . . . . . . . . . . . . . . 10 3.5. Read-Only vs. Read-Write Model Segmentation . . . . . . . 10 4. Use cases and Examples . . . . . . . . . . . . . . . . . . . 10 4.1. MPLS Capability License on a Network OS . . . . . . . . . 11 4.2. Bandwidth Upgrade via License . . . . . . . . . . . . . . 11 4.3. Floating License Managed by License Server . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . 13 Palmero, et al. Expires 8 January 2026 [Page 2] Internet-Draft almo-entitlement-inventory July 2025 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction The goal of any network elements included as assets in the inventory of any network service provider or enterprise is to leverage their capabilities to build network services. Many of these capabilities are not automatically enabled upon acquisition; their use may require specific rights—typically provided via entitlements or licenses from the vendor. The primary intent of this draft is to support three key operational use cases in managing software entitlements and network capabilities: * Listing entitlements (e.g., licenses) available across the organization, their holders, and applicable scope. * Modeling the capabilities that entitlements permit or enable, representing what a device can do when properly licensed. * Representing the actual use of capabilities, including any active restrictions or limits defined by the associated entitlements. Together, these use cases enable administrators to answer essential questions such as: What can this device do? What is it currently allowed to do? And what is it actively doing within the bounds of licensing or entitlement constraints? This approach supports not only entitlement tracking but also intent-aware control of device behavior and resource exposure. As network technology evolves toward modular, software-defined, and virtualized architectures, managing the rights to activate specific functions becomes increasingly complex. These rights granted via entitlements or licenses must be tracked, aggregated, and matched to assets to ensure that services can be delivered using available capabilities. This complexity calls for structured, machine-readable models that represent which capabilities are available, permitted, and in use. To address this, the model relies on two core concepts: capability and entitlement. A capability represents what a system or component can do; an entitlement grants permission to use one or more of those capabilities, possibly under constraints such as time, scope, or usage limits. Being able to represent and exchange this information across systems helps automate entitlement administration and simplify operational decisions. Palmero, et al. Expires 8 January 2026 [Page 3] Internet-Draft almo-entitlement-inventory July 2025 This draft provides a foundational YANG structure for representing these relationships in a standard, vendor neutral way, complementing the network inventory module. 1.1. Scope of the Entitlement Model The entitlement model aims to provide an inventory of entitlements. This includes the entitled holders and the capabilities to which they are entitled. Additionally, it offers information into the restrictions of the operation of the different assets (network entities and components). In general, this model seeks to address the following questions: * What entitlements are administered/owned by the organization? * How are entitlements restricted to some assets and holders? * What entitlements are assigned or installed on each asset(s)? * What constraints do the current entitlements impose on the assets' functionality? * Does the entitlement impose any kind of global restrictions? What are they? * What are the restrictions that each asset due to the entitlements it holds? The model is designed with flexibility in mind, allowing for expansion through the utilization of tools provided by YANG. The realm of entitlements and licensing is inherently complex, presenting challenges in creating a model that can comprehensively encompass all scenarios without ambiguity. While we attempt to address various situations through examples and use cases, we acknowledge that the model might not be able to cover all corner cases without ambiguity. In such cases, we recommend that implementations provide additional documentation to clarify those potential ambiguities. The current model does not aim to serve as a catalog of licenses. While it may accommodate basic scenarios, it does not aim to cover the full spectrum of license characteristics, which can vary significantly. Instead, our focus is on providing a general framework for describing relationships and answering the questions posed above. With the aim of clarifying the model scope, here are some questions that our model does not attempt to answer: Palmero, et al. Expires 8 January 2026 [Page 4] Internet-Draft almo-entitlement-inventory July 2025 * What are the implications of purchasing a specific entitlement? * Which entitlement should I acquire to get a specific capability? * Is license migration feasible? * What capabilities will be allowed if I install an entitlement in a specific device? * Features or restrictions that depend on each user. We are not covering this in the current version of this document, but it could be done if we expand the holders' identification. This model focuses on the ability to use capabilities, not on access control mechanisms. For example, if a router cannot enable MPLS due to entitlement restrictions, it means the organization lacks the rights to use that capability—even if access to the device itself is available. This distinction is separate from, for instance, the ability of a specific user to configure MPLS due to access control limitations. 1.2. Pre-Provisioned vs. Discovered Entitlements This model is not intended for automatic discovery of entitlements or capabilities through the network elements themselves. Instead, it assumes that entitlements and their associations are either: * Provisioned in a license server or asset database; * Installed on individual devices and reported through management interfaces; or * Manually configured as part of an inventory process. Future augmentations may explore capability discovery or telemetry driven models, but they are out of scope for the current version. 2. Conventions and Definitions 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. * TBU Open Issue for the IVY WG, to include: Palmero, et al. Expires 8 January 2026 [Page 5] Internet-Draft almo-entitlement-inventory July 2025 (Update Glossary for Network Inventory draft. We need at least formal definitions of "capability" and "entitlement") * Capability: A function or resource that a network element can support or execute. * Entitlement: A right granted to a holder (organization or user) to access or activate specific capabilities under defined conditions. 3. Modeling Capabilities and Entitlements The model describes how to represent capabilities and the entitlements that enable them across inventoried assets. Capabilities describe what a device can do. Entitlements indicate whether those capabilities are allowed and under what conditions. In deployments where entitlements are directly associated with specific network elements, the devices themselves may expose entitlement information. Alternatively, some environments may rely on a centralized license server that maintains the entitlements of an organization. By querying the list of capabilities and entitlements, along with their associated metadata, a NETCONF or RESTCONF client can retrieve essential inventory details about what capabilities are available and which entitlements are currently in place. Note that the model uses lists based on classes on multiple parts to be able to extend functionality. (TBD: Provide examples of how this can be done in future releases of this document) Capabilities and entitlements may be listed without explicitly identifying the assets (network elements or components) they apply to. To support assignment, the network inventory [BaseInventory] should be augmented with two new containers referred as capabilities and entitlements. These containers hold information of the state of capabilities and entitlements in the asset(s). 3.1. Capabilities Capabilities are modeled by augmenting "network-element" in the "ietf-network-inventory" module in [BaseInventory] according to the following tree: Palmero, et al. Expires 8 January 2026 [Page 6] Internet-Draft almo-entitlement-inventory July 2025 +--rw capabilities +--rw capability-class* [capability-class] +--rw capability-class identityref +--rw capability* [capability-id] +--rw capability-id string +--rw extended-capability-description? string +--rw resource-description? string +--rw resource-units? string +--rw resource-amount? int32 +--rw supporting-entitlements +--rw entitlement* [entitlement-id] +--rw entitlement-id -> ../../../../../entitlements/entitlment/entitlement-id +--rw allowed? boolean +--rw in-use? boolean +--rw capability-restriction* [capability-restriction-id] +--rw capability-restriction-id string +--rw component-id? -> ../../../../../components/component/component-id +--rw description? string +--rw resource-name? string +--rw units? string +--rw max-value? int32 +--rw current-value? int32 For any given element, 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. The capabilities of an inventoried asset may be restricted based on the availability of proper entitlements. An entitlement manager might be interested in the capabilities available to be use on the assets, and the capabilities that are available. The model includes this information by means of the "supporting entitlements" list, that 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. 3.2. Entitlements As in the case of capabilities, entitlement modeling augments "network-element" in the ietf-network-inventory module in [BaseInventory] according to the following tree: Palmero, et al. Expires 8 January 2026 [Page 7] Internet-Draft almo-entitlement-inventory July 2025 +--rw entitlements +--rw entitlement* [eid] +--rw eid string +--rw product-id? string +--rw state? entitlement-state-t +--rw renewal-profile | +--rw activation-date? yang:date-and-time | +--rw expiration-date? yang:date-and-time +--rw restrictions | +--rw restriction* [restriction-id] | +--rw restriction-id string | +--rw description? string | +--rw units? string | +--rw max-value? int32 | +--rw current-value? int32 +--rw parent-entitlement-uid? -> ../entitlement/eid +--rw entitlement-attachment +--rw universal-access? boolean +--rw holders! | +--rw organizations_names | | +--rw organizations* string | +--rw users_names | +--rw users* string +--rw assets +--rw elements +--rw network-elements* string +--rw components +--rw component* [network-element component-id] +--rw network-element string +--rw component-id string Entitlements and assets are linked in the model in two ways. Entitlements might be attached to assets, and assets include (or have installed) entitlements. The former way addresses the case of a license server, while the latter considers an entitlement directly associated with the network element. An entitlement that is not included by any asset means that it is not being used. Palmero, et al. Expires 8 January 2026 [Page 8] Internet-Draft almo-entitlement-inventory July 2025 Entitlements may be listed in multiple assets. For instance, a license server, functioning as an asset, might list an entitlement, while the network element entitled by that license might also list it. Proper identification of entitlements is imperative to ensure consistency across systems, enabling monitoring systems to recognize when multiple assets list the same entitlement. Furthermore, there are cases where an authorized asset might not be aware of the covering license. Consider the scenario of a site license, wherein any device under the site may utilize a feature without explicit knowledge of the covering license. In such cases, asset awareness relies on management controls or a service license capable of listing it. 3.2.1. 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. A reverse mapping structure may be introduced in a future version of the model, once a reliable binding syntax for entitlement to capability is standardized. 3.3. Entitlement Attachment The "entitlement" container holds a container called "entitlement- attachment" which relates how the entitlement is operationally linked to holders or assets. Note that there is a difference between an entitlement being attached to an asset and an entitlement being installed in 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 installation. Other licenses might 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. For these pending entitlements, logistical constraints may arise in informing their existence, as there must be at least one element exporting the model that is aware of their existence. Some entitlements are inherently associated with a holder, such as organization or a user. For example, a software license might be directly attached to a user. Also, the use of a network device might come with a basic license provided solely to an organization. Some Palmero, et al. Expires 8 January 2026 [Page 9] Internet-Draft almo-entitlement-inventory July 2025 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 assets an entitlement is aimed for, when this link is more vague, such as a site license (e.g., assets located in a specific site), or more open licenses (e.g., free software for all users subscribed to a streaming platform). It is important to note that the current model does not provide information on whether an entitlement can be reassigned to other devices (e.g., fixed or floating license). Such scenarios fall under the "what if" category, which is not covered by this model. 3.4. Model Definition TBP 3.5. Read-Only vs. Read-Write Model Segmentation Not all elements in the entitlement model are expected to be configurable. The current YANG tree uses rw extensively for structural convenience. However, in many real-world use cases, entitlement and capability data will be read-only from the device or management system perspective. Data can be classified as follows: * *Read-only (ro)*: Installed entitlements, current-value/max-value, expiration timestamps, holder details. * *Read-write (rw)*: Static description of capabilities and manually registered licenses. Future revisions may refactor the model to more accurately reflect configuration vs. operational state using config false statements. 4. Use cases and Examples This section describes use cases, provide an example of how they could be modeled by the model, and show how each of the questions that we have explored in this draft can be answered by the model. Palmero, et al. Expires 8 January 2026 [Page 10] Internet-Draft almo-entitlement-inventory July 2025 4.1. MPLS Capability License on a Network OS An operator installs a software license (entitlement) enabling MPLS routing on a NOS. The license is attached to a specific device and activates the "mpls-routing" capability class. json "entitlement": { "eid": "mpls-license-001", "product-id": "mpls-software-lic-v2", "renewal-profile": { "activation-date": "2025-01-01T00:00:00Z", "expiration-date": "2026-01-01T00:00:00Z" }, "entitlement-attachment": { "holders": { "organizations_names": { "organizations": ["ACME Corp"] }, "assets": { "elements": { "network-elements": ["router-5"] } } } } } "capability": { "capability-id": "mpls-routing", "capability-class": "routing", "supporting-entitlements": { "entitlement": [ { "entitlement-id": "mpls-license-001", "allowed": true, "in-use": true } ] } } 4.2. Bandwidth Upgrade via License A vendor-N device uses a capacity license to expand throughput. Palmero, et al. Expires 8 January 2026 [Page 11] Internet-Draft almo-entitlement-inventory July 2025 json "entitlement": { "eid": "vendorN-bw-10g", "product-id": "vendorN-bw-upgrade", "restrictions": { "restriction": [ { "restriction-id": "cap", "description": "Bandwidth cap", "units": "Gbps", "max-value": 10, "current-value": 6 } ] } } "capability": { "capability-id": "bw-capability", "resource-description": "Licensed bandwidth", "resource-units": "Gbps", "resource-amount": 10, "supporting-entitlements": { "entitlement": [ { "entitlement-id": "vendorN-bw-10g", "allowed": true, "in-use": true } ] } } 4.3. Floating License Managed by License Server A shared entitlement is held by a license server and consumed dynamically by multiple switches. Palmero, et al. Expires 8 January 2026 [Page 12] Internet-Draft almo-entitlement-inventory July 2025 json "entitlement": { "eid": "shared-switch-license-1", "entitlement-attachment": { "universal-access": true, "holders": { "organizations_names": { "organizations": ["NTT"] } }, "assets": { "elements": { "network-elements": ["switch-1", "switch-2", "switch-3"] } } } } This entitlement may be tracked across devices using a license server asset that records usage or seat count (future extension). 5. IANA Considerations (TBP) 6. Security Considerations (TBP) 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [BaseInventory] Yu, C., Belotti, S., Bouquier, J., Peruzzini, F., and P. Bedard, "A Base YANG Data Model for Network Inventory", Work in Progress, Internet-Draft, draft-ietf-ivy-network- Palmero, et al. Expires 8 January 2026 [Page 13] Internet-Draft almo-entitlement-inventory July 2025 inventory-yang-07, 7 July 2025, . Acknowledgments This document is based on work partially funded by the EU Horizon Europe projects ACROSS (grant 101097122), ROBUST-6G (grant 101139068), iTrust6G (grant 101139198), MARE (grant 101191436), and CYBERNEMO (grant 101168182). Authors' Addresses Marisol Palmero Independent Email: marisol.ietf@gmail.com Camilo Cardona NTT Email: camilo@gin.ntt.net Diego Lopez Telefonica Email: diego.r.lopez@telefonica.com Palmero, et al. Expires 8 January 2026 [Page 14]