A YANG Module for Entitlement Inventory
draft-ietf-ivy-entitlement-inventory-01
| Document | Type | Active Internet-Draft (ivy WG) | |
|---|---|---|---|
| Authors | Marisol Palmero , Camilo Cardona , Diego Lopez | ||
| Last updated | 2025-10-22 (Latest revision 2025-10-20) | ||
| Replaces | draft-mcd-ivy-entitlement-inventory | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-ivy-entitlement-inventory-01
Network Inventory YANG WG M. Palmero
Internet-Draft Independent
Intended status: Standards Track C. Cardona
Expires: 23 April 2026 NTT
D. Lopez
Telefonica
20 October 2025
A YANG Module for Entitlement Inventory
draft-ietf-ivy-entitlement-inventory-01
Abstract
This document proposes a YANG module for incorporating entitlements
in a network inventory, encompassing both virtual and physical
network elements. 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-ietf-ivy-
entitlement-inventory.html. Status information for this document may
be found at https://datatracker.ietf.org/doc/draft-ietf-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 23 April 2026 [Page 1]
Internet-Draft entitlement-inventory October 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 23 April 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. Foundational model:
NetworkElement-Entitlements-Capabilities and
Restrictions . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Progressive Model Complexity . . . . . . . . . . . . 7
3.2. Capabilities . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Entitlements . . . . . . . . . . . . . . . . . . . . . . 10
3.3.1. Reverse Mapping from Entitlements to Capabilities . . 13
3.4. Entitlement Attachment . . . . . . . . . . . . . . . . . 13
3.5. Installed Entitlements . . . . . . . . . . . . . . . . . 14
3.6. Model Definition . . . . . . . . . . . . . . . . . . . . 15
4. Use cases and Examples . . . . . . . . . . . . . . . . . . . 15
4.1. MPLS Capability License on a Network OS . . . . . . . . . 15
4.2. Bandwidth Upgrade via License . . . . . . . . . . . . . . 16
4.3. Floating License Managed by License Server . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
Palmero, et al. Expires 23 April 2026 [Page 2]
Internet-Draft entitlement-inventory October 2025
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
The purpose of any network elements included as assets in the
inventory of any network operator 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
operator organization, their holders, and applicable scope.
* Modeling the capabilities that entitlements permit or enable,
representing what a network element may 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
may do; an entitlement grants permission to use one or more of those
capabilities, possibly under constraints such as time, scope, or
Palmero, et al. Expires 23 April 2026 [Page 3]
Internet-Draft entitlement-inventory October 2025
usage limits. Being able to represent and exchange this information
across systems helps automate entitlement administration and simplify
operational decisions.
This draft provides a foundational YANG structure for representing
these relationships as standards, 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 installed on each network element?
* What constraints do the current installed entitlements impose on
the network elements' functionality?
* Does the entitlement impose any kind of global restrictions? What
are they?
* What are the restrictions that each network element has due to the
entitlements it holds locally?
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.
Palmero, et al. Expires 23 April 2026 [Page 4]
Internet-Draft entitlement-inventory October 2025
With the aim of clarifying the model scope, here are some questions
that our model does not attempt to answer:
* What are the implications of purchasing a specific entitlement?
* Which entitlement is needed to obtain a specific capability?
* Is license migration feasible?
* What capabilities are permitted when an entitlement is installed
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.
Palmero, et al. Expires 23 April 2026 [Page 5]
Internet-Draft entitlement-inventory October 2025
* ToBeUpdated(TBU) Open Issue for the IVY WG, to include:
<<Update Glossary under Network Inventory draft, [BaseInventory]. 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 network elements.
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)
Entitlements may be listed without explicitly identifying the assets
(network elements or components) they apply to. Entitlements are
defined directly under the network-inventory container for
organizational management. Entitlements are linked to network-
elements in multiple ways: (1) When entitlements are created for
specific network-elements (i.e. they should only be installed on
those), then those network elements are specified under the
entitlement element's attachment section. (2) When an entitlement is
installed in a network-element, it appears in the network-element's
installed-entitlements list. (3) When an installed entitlement
enables capabilities, the network-element's capabilities will
reference the installed entitlement via the supporting-entitlements
list.
Palmero, et al. Expires 23 April 2026 [Page 6]
Internet-Draft entitlement-inventory October 2025
Capabilities, restrictions and the entitlements supporting them
within a network element are defined under the network-element under
the container "capabilities".
3.1. 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.
3.1.1. Progressive Model Complexity
Figure 1 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 │
└─────────┬───────┘
┌─────────────────────┼─────────────────────┐
▼ ▼ ▼
┌─────────────┐ ┌─────────────────┐ ┌─────────────┐
│ Hardware │ │ Software │ │Entitlements │
└─────────────┘ └─────────────────┘ └─────────────┘
Figure 1: Base Network Inventory Entitlement extension
Figure 2 illustrates the initial relationship between Network
Elements and entitlements is two ways: entitlements MIGHT be attached
to NE, and NE might have entitlements installed.
Palmero, et al. Expires 23 April 2026 [Page 7]
Internet-Draft entitlement-inventory October 2025
┌─────────────────────────┐
│Base Network Inventory │
└─────────┬───────────────┘
┌─────────────────────┼─────────────────────┐
▼ ▼ ▼
┌────┴────────┐ ┌───────┴─────────┐ ┌──────┴──────┐
│ Hardware │ │ Software │ │Entitlements │
└──────┬──────┘ └───────┬─────────┘ └───┬──┬──────┘
│ │ │ │
│ └───────<──>───────┘ │
└───────────────────<──>──────────────────┘
Figure 2: Relationship between entitlements and Base Inventory
Figure 3 depicts NE support capabilities thanks to entilements that
entitle them of their use
┌─────────────────────────┐
│Base Network Inventory │
└──────────┬──────────────┘
┌────────────────────┼────────────────────┐
▼ ▼ ▼
┌────┴───────┐ ┌───────┴───────┐ ┌──────┴─────┐
│ Hardware │ │ Entitlements │ │ Software │
└────┬───────┘ └─────┬─────────┘ └─────┬──────┘
│ │ │
│ │enables │
│supports ┌──────V─────────┐ supports│
└──────────>│ Capabilities │<──────────┘
└────────────────┘
Figure 3: Capabilities integration with the Base Inventory
Finally, NE support capabilities thanks to entilements that entitle
them of their use under certain constraints as shown in Figure 4.
Palmero, et al. Expires 23 April 2026 [Page 8]
Internet-Draft entitlement-inventory October 2025
┌────────────────────────────┐
│ Base Network Inventory │
└────────────┬───────────────┘
│
┌───────────────────┼─────────────────────┐
▼ ▼ ▼
┌──────┴─────┐ ┌───────┴───────┐ ┌──────┴─────┐
│ Hardware │ │ Entitlements │ │ Software │
└──────┬─────┘ └───────┬───────┘ └──────┬─────┘
│ │ │
│ │enables │
│supports ┌──────V─────────┐ supports│
└───────────>│ Capabilities │<──────────┘
└──────┬─────────┘
│
│constrained by
┌──────V─────────┐
│ Restrictions │
└────────────────┘
Figure 4: Complete model with restrictions
3.2. 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 23 April 2026 [Page 9]
Internet-Draft entitlement-inventory October 2025
+--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 resource-description? string
+--ro resource-units? string
+--ro resource-amount? int32
+--ro supporting-entitlements
+--ro entitlement* [entitlement-id]
+--ro entitlement-id -> ../../../../../entitlements/entitlement/entitlement-id
+--ro allowed? boolean
+--ro in-use? boolean
+--ro capability-restriction* [capability-restriction-id]
+--ro capability-restriction-id string
+--ro component-id? -> ../../../../../components/component/component-id
+--ro description? string
+--ro resource-name? string
+--ro units? string
+--ro max-value? int32
+--ro current-value? int32
For any given network 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 network element may be restricted
based on the availability of proper entitlements. An entitlement
manager might be interested in the capabilities available to be used
on the network elements, and the capabilities that are currently
available. The model includes this information by means of the
"supporting entitlements" list, which references locally 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.
3.3. Entitlements
The entitlement modeling augments "network-inventory" in the ietf-
network-inventory module in [BaseInventory] with a top-level
entitlements container according to the following tree:
Palmero, et al. Expires 23 April 2026 [Page 10]
Internet-Draft entitlement-inventory October 2025
Figure 5 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.
+----------------------+
| |
|Base Network Inventory|
| |
+----------+-----------+
^
|
+----------+-----------+
| |
| Entitlement Inventory|
| e.g., licenses, |
| capabilities, |
| restrictions |
+----------------------+
Figure 5: Relationship of Entitlement Inventory Model to Other
Inventory Models
Palmero, et al. Expires 23 April 2026 [Page 11]
Internet-Draft entitlement-inventory October 2025
+--ro entitlements
+--ro entitlement* [eid]
+--ro eid string
+--ro product-id? 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 units? string
| +--ro max-value? int32
| +--ro current-value? int32
+--ro parent-entitlement-uid? -> ../entitlement/eid
+--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* -> /network-inventory/network-elements/network-element/ne-id
+--ro components
+--ro component* [network-element component-id]
+--ro network-element -> /network-inventory/network-elements/network-element/ne-id
+--ro component-id -> /network-inventory/network-elements/network-element/components/component/component-id
Entitlements and network elements are linked in the model in multiple
ways. Entitlements at the network-inventory level might be attached
to network elements through their attachment mechanism, representing
organizational entitlements. Network elements have their own
installed-entitlements that may be derived from the centralized
entitlements or installed directly. The capabilities of network
elements reference these locally 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 locally available and actively used
by the network element's capabilities. An installed entitlement that
is not referenced by any network element capability means that it is
available locally but not currently in use.
Palmero, et al. Expires 23 April 2026 [Page 12]
Internet-Draft entitlement-inventory October 2025
Entitlements are managed both centrally at the network-inventory
level and locally within network elements through installed-
entitlements. Network elements utilize locally installed
entitlements and reference them through their capabilities'
supporting-entitlements lists. For instance, a license server or
inventory system might list an entitlement at the top level, which
then gets installed on specific network elements where the
capabilities reference the local copy. The "parent-entitlement-uid"
field in installed entitlements provides traceability back to
centralized entitlements when applicable. Proper identification of
entitlements is imperative to ensure consistency across systems,
enabling monitoring systems to recognize when multiple locations
reference related entitlements. Furthermore, there are cases where
an authorized network element might have locally installed
entitlements without explicit knowledge of the covering
organizational license. Consider the scenario of a site license,
wherein any device under the site may utilize a feature through
locally installed entitlements derived from the site-wide license.
In such cases, the parent-entitlement-uid maintains the connection to
the organizational entitlement policy.
3.3.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.4. Entitlement Attachment
The "entitlement" container holds a container called "entitlement-
attachment" which relates how the entitlement is operationally linked
to holders or network elements. Note that there is a difference
between an entitlement being attached to a network element and an
entitlement being installed in the network element. In the former,
the license was explicitly associated with one or more network
elements. 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.
Palmero, et al. Expires 23 April 2026 [Page 13]
Internet-Draft entitlement-inventory October 2025
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
elements 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 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
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 elements an entitlement is aimed
for, when this link is more vague, such as a site license (e.g.,
network elements 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
network elements. Such scenarios fall under the "what if" category,
which is not covered by this model.
3.5. Installed Entitlements
Since capabilities are optional in network elements, the model also
provides an augmentation to track entitlements that are installed
directly on network elements. This augmentation of "network-element"
in the "ietf-network-inventory" module provides local entitlement
storage according to the following tree:
+--ro installed-entitlements
+--ro entitlement* [eid]
+--ro eid -> /network-inventory/entitlements/entitlement/eid
The installed entitlements represent references to entitlements that
are locally present on the network element. The "eid" field provides
a direct reference to the centralized entitlement at the network-
inventory level.
This structure allows network elements to operate independently of
centralized entitlement management while maintaining the ability to
track relationships to organization-wide entitlement policies.
Palmero, et al. Expires 23 April 2026 [Page 14]
Internet-Draft entitlement-inventory October 2025
3.6. Model Definition
TBP
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.
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 network
element and activates the "mpls-routing" capability class.
Complete example showing network inventory augmented with
entitlements:
json
{
"ietf-network-inventory:network-inventory": {
"entitlements": {
"entitlement": [
{
"eid": "mpls-license-001",
"product-id": "mpls-software-lic-v2",
"state": "active",
"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"]
}
}
}
}
]
},
"network-elements": {
Palmero, et al. Expires 23 April 2026 [Page 15]
Internet-Draft entitlement-inventory October 2025
"network-element": [
{
"ne-id": "router-5",
"ne-type": "ietf-network-inventory:router",
"installed-entitlements": {
"entitlement": [
{
"eid": "mpls-license-001"
}
]
},
"capabilities": {
"capability-class": [
{
"capability-class": "ietf-entitlement-inventory:routing",
"capability": [
{
"capability-id": "mpls-routing",
"extended-capability-description": "MPLS Label Switching Protocol",
"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.
Complete example showing network inventory augmented with bandwidth
entitlements:
Palmero, et al. Expires 23 April 2026 [Page 16]
Internet-Draft entitlement-inventory October 2025
json
{
"ietf-network-inventory:network-inventory": {
"entitlements": {
"entitlement": [
{
"eid": "vendorN-bw-10g",
"product-id": "vendorN-bw-upgrade",
"state": "active",
"restrictions": {
"restriction": [
{
"restriction-id": "global-cap",
"description": "Organization bandwidth cap",
"units": "Gbps",
"max-value": 100,
"current-value": 25
}
]
}
}
]
},
"network-elements": {
"network-element": [
{
"ne-id": "switch-10g-01",
"ne-type": "ietf-network-inventory:switch",
"installed-entitlements": {
"entitlement": [
{
"eid": "vendorN-bw-10g"
}
]
},
"capabilities": {
"capability-class": [
{
"capability-class": "ietf-entitlement-inventory:bandwidth",
"capability": [
{
"capability-id": "bw-capability",
"resource-description": "Licensed bandwidth",
"resource-units": "Gbps",
"resource-amount": 10,
"supporting-entitlements": {
"entitlement": [
{
Palmero, et al. Expires 23 April 2026 [Page 17]
Internet-Draft entitlement-inventory October 2025
"entitlement-id": "vendorN-bw-10g",
"allowed": true,
"in-use": true,
"capability-restriction": [
{
"capability-restriction-id": "bw-limit",
"description": "Current bandwidth usage",
"resource-name": "active-bandwidth",
"units": "Gbps",
"max-value": 10,
"current-value": 6
}
]
}
]
}
}
]
}
]
}
}
]
}
}
}
4.3. Floating License Managed by License Server
A shared entitlement is held by a license server and consumed
dynamically by multiple switches.
Complete example showing floating license across multiple network
elements:
json
{
"ietf-network-inventory:network-inventory": {
"entitlements": {
"entitlement": [
{
"eid": "shared-switch-license-1",
"product-id": "advanced-switching-features",
"state": "active",
"entitlement-attachment": {
"universal-access": true,
"holders": {
"organizations_names": {
Palmero, et al. Expires 23 April 2026 [Page 18]
Internet-Draft entitlement-inventory October 2025
"organizations": ["NTT"]
}
},
},
"restrictions": {
"restriction": [
{
"restriction-id": "concurrent-users",
"description": "Maximum concurrent feature usage",
"units": "sessions",
"max-value": 50,
"current-value": 12
}
]
}
}
]
},
"network-elements": {
"network-element": [
{
"ne-id": "switch-1",
"ne-type": "ietf-network-inventory:switch",
"installed-entitlements": {
"entitlement": [
{
"eid": "shared-switch-license-1"
}
]
},
"capabilities": {
"capability-class": [
{
"capability-class": "ietf-entitlement-inventory:switching",
"capability": [
{
"capability-id": "advanced-vlan-features",
"extended-capability-description": "Advanced VLAN management features",
"supporting-entitlements": {
"entitlement": [
{
"entitlement-id": "shared-switch-license-1",
"allowed": true,
"in-use": false
}
]
}
},
Palmero, et al. Expires 23 April 2026 [Page 19]
Internet-Draft entitlement-inventory October 2025
{
"capability-id": "qos-policies",
"extended-capability-description": "Quality of Service policies",
"supporting-entitlements": {
"entitlement": [
{
"entitlement-id": "shared-switch-license-1",
"allowed": true,
"in-use": true
}
]
}
}
]
}
]
}
},
{
"ne-id": "switch-2",
"ne-type": "ietf-network-inventory:switch",
"installed-entitlements": {
"entitlement": [
{
"eid": "shared-switch-license-1"
}
]
},
"capabilities": {
"capability-class": [
{
"capability-class": "ietf-entitlement-inventory:switching",
"capability": [
{
"capability-id": "advanced-vlan-features",
"extended-capability-description": "Advanced VLAN management features",
"supporting-entitlements": {
"entitlement": [
{
"entitlement-id": "shared-switch-license-1",
"allowed": true,
"in-use": true
}
]
}
}
]
}
Palmero, et al. Expires 23 April 2026 [Page 20]
Internet-Draft entitlement-inventory October 2025
]
}
}
]
}
}
}
This example demonstrates how a floating license can be managed
centrally while being installed locally on multiple network elements.
Each switch has its own local copy of the entitlement that traces
back to the centralized policy. The centralized entitlement shows
global restrictions (concurrent users), while individual switches
show their local usage. 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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
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-
inventory-yang-11, 14 October 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-ivy-
network-inventory-yang-11>.
Palmero, et al. Expires 23 April 2026 [Page 21]
Internet-Draft entitlement-inventory October 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 23 April 2026 [Page 22]