



Network Inventory YANG WG                                     M. Palmero
Internet-Draft                                               Independent
Intended status: Informational                                C. Cardona
Expires: 24 January 2026                                             NTT
                                                                D. Lopez
                                                              Telefonica
                                                            23 July 2025


                A YANG Module for Entitlement Inventory
                 draft-mcd-ivy-entitlement-inventory-02

Abstract

   This document proposes a YANG module for incorporating entitlements
   in a network inventory.  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 a
   network 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 24 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 24 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  . . . . . . . . . . . . . . . . . . . . . .   7
     3.2.  Entitlements  . . . . . . . . . . . . . . . . . . . . . .   8
       3.2.1.  Reverse Mapping from Entitlements to Capabilities . .  10
     3.3.  Entitlement Attachment  . . . . . . . . . . . . . . . . .  10
     3.4.  Installed Entitlements  . . . . . . . . . . . . . . . . .  11
     3.5.  Model Definition  . . . . . . . . . . . . . . . . . . . .  11
   4.  Use cases and Examples  . . . . . . . . . . . . . . . . . . .  12
     4.1.  MPLS Capability License on a Network OS . . . . . . . . .  12
     4.2.  Bandwidth Upgrade via License . . . . . . . . . . . . . .  13
     4.3.  Floating License Managed by License Server  . . . . . . .  15
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  18



Palmero, et al.          Expires 24 January 2026                [Page 2]

Internet-Draft         almo-entitlement-inventory              July 2025


   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

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 24 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 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.

   With the aim of clarifying the model scope, here are some questions
   that our model does not attempt to answer:




Palmero, et al.          Expires 24 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 24 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 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.

   Capabilities, restrictions and the entitlements supporting them
   within a network element are defined under the network-element under
   the container "capabilities".



Palmero, et al.          Expires 24 January 2026                [Page 6]

Internet-Draft         almo-entitlement-inventory              July 2025


3.1.  Capabilities

   Capabilities are modeled by augmenting "network-element" in the
   "ietf-network-inventory" module in [BaseInventory] according to the
   following tree:

+--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                 -> ../../../installed-entitlements/entitlement/eid
            +--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.







Palmero, et al.          Expires 24 January 2026                [Page 7]

Internet-Draft         almo-entitlement-inventory              July 2025


3.2.  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:

   Figure 1 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 1: Relationship of Entitlement Inventory Model to Other
                                 Inventory Models






















Palmero, et al.          Expires 24 January 2026                [Page 8]

Internet-Draft         almo-entitlement-inventory              July 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 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.

   Entitlements are managed both centrally at the network-inventory
   level and locally within network elements through installed-
   entitlements.  Network elements utilize locally installed



Palmero, et al.          Expires 24 January 2026                [Page 9]

Internet-Draft         almo-entitlement-inventory              July 2025


   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.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 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.

   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.



Palmero, et al.          Expires 24 January 2026               [Page 10]

Internet-Draft         almo-entitlement-inventory              July 2025


   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.4.  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.

3.5.  Model Definition

   TBP





Palmero, et al.          Expires 24 January 2026               [Page 11]

Internet-Draft         almo-entitlement-inventory              July 2025


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": {
      "network-element": [
        {
          "ne-id": "router-5",
          "ne-type": "ietf-network-inventory:router",



Palmero, et al.          Expires 24 January 2026               [Page 12]

Internet-Draft         almo-entitlement-inventory              July 2025


          "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:

json
{
  "ietf-network-inventory:network-inventory": {
    "entitlements": {
      "entitlement": [
        {



Palmero, et al.          Expires 24 January 2026               [Page 13]

Internet-Draft         almo-entitlement-inventory              July 2025


          "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": [
                        {
                          "entitlement-id": "vendorN-bw-10g",
                          "allowed": true,
                          "in-use": true,
                          "capability-restriction": [
                            {
                              "capability-restriction-id": "bw-limit",



Palmero, et al.          Expires 24 January 2026               [Page 14]

Internet-Draft         almo-entitlement-inventory              July 2025


                              "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": {
                "organizations": ["NTT"]
              }
            },
          },
          "restrictions": {
            "restriction": [



Palmero, et al.          Expires 24 January 2026               [Page 15]

Internet-Draft         almo-entitlement-inventory              July 2025


              {
                "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
                        }
                      ]
                    }
                  },
                  {
                    "capability-id": "qos-policies",
                    "extended-capability-description": "Quality of Service policies",
                    "supporting-entitlements": {
                      "entitlement": [
                        {



Palmero, et al.          Expires 24 January 2026               [Page 16]

Internet-Draft         almo-entitlement-inventory              July 2025


                          "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 24 January 2026               [Page 17]

Internet-Draft         almo-entitlement-inventory              July 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-08, 22 July 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-ivy-
              network-inventory-yang-08>.

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).



Palmero, et al.          Expires 24 January 2026               [Page 18]

Internet-Draft         almo-entitlement-inventory              July 2025


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 24 January 2026               [Page 19]
