Network Inventory YANG WG M. Palmero
Internet-Draft Cisco Systems
Intended status: Informational C. Cardona
Expires: 4 September 2025 NTT
D. Lopez
Telefonica
3 March 2025

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

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 feature(s) 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 4 September 2025 [Page 1]

Internet-Draft almo-entitlement-inventory March 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 4 September 2025.

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 . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
3. Modeling Capabilities and Entitlements . . . . . . . . . . . 5
3.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Entitlements . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Entitlement Attachment . . . . . . . . . . . . . . . . . 8
3.4. Model Definition . . . . . . . . . . . . . . . . . . . . 9
4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10

Palmero, et al. Expires 4 September 2025 [Page 2]

Internet-Draft almo-entitlement-inventory March 2025

1. Introduction

The goal of any network elements included as assets in the inventory
of any network service provider is to be used to build such services,
taking advantage of the features provided by the inventoried assets.
The use of many of these features are not necessarily associated with
the acquisition of an inventoried network element, as their use
requires specific permissions, usually in terms of licenses issued by
the network element provider explicitly authorizing the use of a
(number of) feature(s). As the technology evolves, making network
elements more modular and software-intensive, and even fully
virtualized, the management of these permissions, their agreggation
and application to enable a concrete network service becomes more
relevant. These trends also imply the combination of a greater
number of these permissions, within a given network element or in a
number of them, implying an increasing complexity when trying to
assess the feasibility of providing a specific service by integrating
the necessary assets. This draft proposes a YANG model for
incorporating the management of these permissions, based on two
essential concepts: capability and entitlement.

Capability refers to the ability or power to do something, often
indicating a skill, talent, or potential to achieve a specific
outcome, and is commonly used to describe the features or functions
of a system or device that enable it to perform tasks. On the other
hand, an entitlement corresponds to the right that someone has to do
or have something. Following this general definitions, the model
considers entitlements as the means that grant specific holders the
right to access particular capabilities of one or more of the assets
in the network inventory. The use of these capabilities may be
restricted in various ways, such as by duration, usage limits, or
predefined conditions. Being able to exchange information on the
state of the entitlements applicable to network elements can save
time and facilitate decision making. This document proposes a YANG
model that, complementing the network inventory module, can provide
the information an asset/entitlement administrator needs for this
purpose.

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?

Palmero, et al. Expires 4 September 2025 [Page 3]

Internet-Draft almo-entitlement-inventory March 2025

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

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

Palmero, et al. Expires 4 September 2025 [Page 4]

Internet-Draft almo-entitlement-inventory March 2025

It is important to note that the model primarily addresses the
utilization of capabilities, rather than access control. For
instance, if a network device cannot be configured to use an
arbitrary network protocol (e.g. MPLS) due to licensing restrictions,
this implies that the organization owning the router (the holder in
this scenario) is not permitted to utilize the MPLS feature. This
distinction is separate from, for instance, the ability of a specific
user to configure MPLS due to access control limitations.

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.

(Glossary TBP. We need at least formal definitions of "capability"
and "entitlement")

3. Modeling Capabilities and Entitlements

The model is intended to facilitate information on all capabilities
and entitlements associated with a set of inventoried assets under
the same inventory management. In scenarios where entitlements are
tied to network elements, the element itself can provide this
information. Alternatively, providers may support something similar
to a license server, which could house comprehensive information
regarding an organization's entitlements. Just by listing
capabilities and entitlements, and reading their basic information, a
NETCONF/RESTCONF client will be able to retrieve basic inventory
information of available capabilities and existing entitlements.

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 and features can be made available by means of do not
specifying which the assets (network elements or components) are
actually assigned the entitlements, either through an installation or
a similar operation. For this, we augment the network elements from
the network-inventory [I-D.draft-ietf-ivy-network-inventory-yang-03]
model with a new container called entitlement-information. This
container holds information of the state of entitlements in the
asset.

Palmero, et al. Expires 4 September 2025 [Page 5]

Internet-Draft almo-entitlement-inventory March 2025

3.1. Capabilities

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

+--rw capabilities
+--rw capability-class* [capability-class]
+--rw capability-class identityref
+--rw capability* [capability-id]
+--rw capability-id string
+--rw extended-feature-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

The list of capabilities for a given element MAY contain all the
associated capabilities provided by the element vendor for such an
element, and MUST contain all the capabilities the network service
provider operating the network element has acquired an entitlement
for, independently of it being 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 can help organizations stay informed about their
entitlement usage and take necessary actions to prevent potential
violations or overuse of capabilities.

Palmero, et al. Expires 4 September 2025 [Page 6]

Internet-Draft almo-entitlement-inventory March 2025

3.2. Entitlements

As in the case of capabilities, entitlement modeling augments
"newtwork-element" in the ietf-network-inventory module in
[BaseInventory] according to the following tree:

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

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

Palmero, et al. Expires 4 September 2025 [Page 7]

Internet-Draft almo-entitlement-inventory March 2025

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.3. Entitlement Attachment

The "entitlement" container holds a container called "entitlement-
attachement" which relates how the entitlement is operationally
linked to holders or assets. Note that there is a difference between
an entilement being attached to an asset and an entilement being
installed in the asset. In the former, we mean that the license was
issued only for one (or more) assets. Some licenses actually can be
open but have a limited number of installation. Other licenses might
be openly constraint to geography 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 an 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 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.

Palmero, et al. Expires 4 September 2025 [Page 8]

Internet-Draft almo-entitlement-inventory March 2025

3.4. Model Definition

TBP

4. Use cases

This section will describe 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.

(TBP in next versions)

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-05, 28 February 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-ivy-
network-inventory-yang-05>.

Palmero, et al. Expires 4 September 2025 [Page 9]

Internet-Draft almo-entitlement-inventory March 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
Cisco Systems
Email: mpalmero@cisco.com

Camilo Cardona
NTT
Email: camilo@gin.ntt.net

Diego Lopez
Telefonica
Email: diego.r.lopez@telefonica.com

Palmero, et al. Expires 4 September 2025 [Page 10]