



IVY WG                                                       N. R. Davis
Internet-Draft                                                     Ciena
Intended status: Informational                                C. Cardona
Expires: 23 April 2026                                               NTT
                                                                D. Lopez
                                                              Telefonica
                                                              M. Palmero
                                                             Independent
                                                         20 October 2025


                    Equipment Capability Application
          draft-davis-ivy-equipment-capability-application-00

Abstract

   This document applies the generalized capability principles to the
   description of equipment (a physical thing) with applied data
   (configuration state and code (software, firmware etc.)) and shows
   how such capability specifications integrate with base inventory and
   entitlement models as defined in Network Inventory, Software
   Extension and Entitlement YANG models.

   The approach is examined by example, focusing on how the potential
   capabilities of each equipment type-version with applied data are
   described, how these map to entitlements (licensed or policy-
   controlled subsets of capabilities), and how they are instantiated as
   inventory items.  The explanation covers both the capabilities of
   equipment in terms of physical properties and the capabilities of
   equipment with applied data in terms of resultant emergent
   functionality.

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://github.com/marisolpalmero/draft-ietf-davis-generalized-
   capability-principles/blob/main/draft-davis-ivy-equipment-capability-
   application-latest.md.  Status information for this document may be
   found at https://datatracker.ietf.org/doc/draft-davis-ivy-equipment-
   capability-application/.

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



Davis, et al.             Expires 23 April 2026                 [Page 1]

Internet-Draft                 EquCapAppl                   October 2025


   Source for this draft and an issue tracker can be found at
   https://github.com/marisolpalmero/draft-ietf-davis-generalized-
   capability-principles.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Specification in terms of the Model . . . . . . . . . . . . .   7
   5.  Some specification examples . . . . . . . . . . . . . . . . .   8
   6.  Recursive narrowing . . . . . . . . . . . . . . . . . . . . .   9
   7.  Specification of an assembly  . . . . . . . . . . . . . . . .   9
   8.  Generalization of the specification . . . . . . . . . . . . .   9
   9.  Using the language of specification . . . . . . . . . . . . .   9
   10. Building the equipment specification structure  . . . . . . .   9
   11. Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  10



Davis, et al.             Expires 23 April 2026                 [Page 2]

Internet-Draft                 EquCapAppl                   October 2025


   12. Security Considerations . . . . . . . . . . . . . . . . . . .  10
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     14.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  11
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT"
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the
   document are to be interpreted as described in RFC2119}}.

   The following terms abbreviations are used in this document:

   *  equipment: A physical item necessary for a particular purpose.

   *  physical: Has spatial dimensions (i.e., can be measured with a
      "ruler") and in some cases has mass (i.e., can be weighed with
      scales)

   *  SFP: Small Form-factor Pluggable

   *  equipment with applied data: A physical item with compatible
      software, firmware, configuration etc.

   *  equipment type-version: A reference to a definition of the
      capabilities of an equipment such that all instances of equipment
      of that type-version have the same capabilities.

2.  Introduction

   Physical things have various fundamental properties such as length,
   temperature, weight.  In an assembly of physical things each thing
   plays various roles in the structure and has to be compatible with
   the other things in that structure so that it can participate in
   those roles.












Davis, et al.             Expires 23 April 2026                 [Page 3]

Internet-Draft                 EquCapAppl                   October 2025


   In a telecoms environment, there are many physical things that
   support the provision of service.  For simplicity, in this document a
   physical thing that is useful for the provision of telecommunication
   service will be referred to as an equipment.  The focus of this
   document is limited to telecommunications networks and hence
   equipments for related purposes, but there is no specific limitation
   to the method that prevent it from being applied more broadly.  This
   restriction is simply to reduce the volume and complexity of the
   descriptions.

   The equipments to be represented include boards (circuit packs) and
   shelves (subracks).  In this description an SFP will be considered as
   a board.  The essential structural model is that a shelf can be
   placed in a rack, a board in a slot in a shelf and a board (SFP) in a
   slot in a board.

   Whilst this general model says a board can be placed in a slot,
   clearly not all boards can be placed in all slots.  This document
   describes the opportunities in terms of physical capabilities of an
   equipment type-version where all relevant characteristics are the
   same for each instance of that type-version such that the instances
   can be interchangeable.

   Many equipments can accommodate applied data.  The desired
   functionality is emergent from the combination of that equipment with
   applied data.  The statement of capability covers the equipment with
   applied data.

   This document is part of a suite that includes:

   *  [GenCapPrin] defines the generalized capability and refinement
      principles.

   *  [BaseInventory] defines how equipment occurrences are represented
      in a network inventory.

   *  [EntitlementInventory] defines how capability entitlements and
      licensed functionality are tracked.

   Together, these drafts describe a continuous trace:

   Capability -> Entitlement -> Inventory -> Realization

   {::include art/capabilities.txt}

   Figure 1: Relationship between Capability, Entitlement, and Inventory

   where:



Davis, et al.             Expires 23 April 2026                 [Page 4]

Internet-Draft                 EquCapAppl                   October 2025


   *  *Capability* defines what an equipment with applied data _can_ do
      (its potential);

   *  *Entitlement* defines what an operator _is allowed_ or _enabled_
      to use; and

   *  *Inventory* records what _actually exists_ and is deployed.

   The goal of this draft is to show, by concrete examples, how the
   generalized capability framework is specialized for equipment with
   applied data and how that structure integrates with inventory and
   entitlement data.

   From a purely physical perspective, whilst the general model says a
   board can be placed in a slot, clearly not all boards can be placed
   in all slots.  This document describes the opportunities in terms of
   physical capabilities of types of equipment.

   A majority of equipment can be configured and can have its behaviour
   define by software etc.  The capability, in these cases, is emergent
   from the combination of the physical structure activated by power and
   shaped by data.  Hence the overall capability specification may be
   defined by a complex combination of capability specifications.

   An equipment supports some specific functionality.  Some functions
   emerge from a combination of equipment.  The specification method
   described here allows the functions that emerge from assemblies of
   equipment to be described in detail.

   The specification of potential emergent functions can be used at
   various stages of the network lifecycle.  The specification of
   emergent functions allows a purchasing application to determine which
   particular types of equipment can be acquired and a planning tool to
   determine how to arrange occurrences of types of equipment in systems
   and what data to apply to support particular functions prior to the
   purchase of any equipment.

3.  Problem Statement

   A telecoms network is realized through an assembly of equipments
   (such as circuit packs, boards, racks, cables etc.), some passive
   (not directly powered), some active (directly powered) and some
   running complex software etc.  Each assembly provides some capability
   that supports the provision of service.  Understanding these
   capabilities in detail and precisely is vital throughout the life of
   the network.





Davis, et al.             Expires 23 April 2026                 [Page 5]

Internet-Draft                 EquCapAppl                   October 2025


   Whilst an active equipment with applied data may provide an interface
   that exposes what is available currently, it rarely indicates what is
   potentially available and when it does this is usually through an ad-
   hoc mechanism which only conveys a limited view of capability.
   Clearly, when the equipment is not powered, it is not possible to
   interrogate it even for this sparse and basic information.  Passive
   equipments cannot be interrogated.

   Manufactures of equipment produce instances of types of equipment
   where each instance of a type is essentially identical with respect
   to capabilities within an acceptable and understood tolerance.  Any
   instance of a type of equipment is interchangeable with another
   instance of the same type.  There may also be other compatibilities
   where different types have the same or a superset capability and
   hence can be used as alternatives.

   In practice, managing equipment capabilities in isolation is
   insufficient.  Each capability must be tied to:

   *  an _entitlement_ indicating whether it is licensed or permitted
      for use, and

   *  an _inventory record_ that anchors the capability to a deployed
      occurrence.

   This tri-layer relationship enables operators to reason about what
   equipment types exist, what functions they can theoretically perform,
   what data needs to be applied to cause these functions to be
   performed, what has been purchased or activated, and what is
   currently deployed or configured.

   Without such linkage, automation frameworks cannot determine whether
   a planned configuration is feasible, legally licensed, or available
   in the installed base.

   It is necessary to understand some aspects of capability of a type of
   equipment with applied data at all stages of the lifecycle: - whilst
   speculation about services to be provided prior to network design and
   researching potential network capabilities - when planning network
   structure - prior to purchasing, when choosing particular equipment
   types, software etc. for a specific purpose where there are
   alternatives - when planning future deployment of equipments,
   software etc. - when the equipment is installed and services are
   being designed - even when the equipment is fully configured and
   operational with no errors etc., there may be heartbeat and status
   capabilities





Davis, et al.             Expires 23 April 2026                 [Page 6]

Internet-Draft                 EquCapAppl                   October 2025


   Considering the above, it is necessary to have a complete description
   of capability that is available independent of the presence of
   equipment etc.  This description needs to be rigorous and readily
   interpretable allowing for comparisons with other equipment types
   etc.  On that basis the capabilities should be described in a
   normalized language where advantage is taken of recurring patterns
   etc.

   As automation progresses, machine interpretability of the capability
   information becomes increasingly important.  Whilst AI, especially
   LLMs, can deal with the variety of human interaction, a more coherent
   and compact language usage is preferable for efficiency and removal
   of potential ambiguity.

   This document sets out an approach for expression of capabilities of
   equipment in terms of physical structure, data structure (software
   etc.) and emergent functionality.

   Whilst knowing the YANG model for the equipment is beneficial, it is
   not sufficient.  The YANG model essentially provides a space within
   which actual state and configuration can be expresses.  The YANG
   model tends to not express equipment type based constraints.  Whilst
   specifying the combinatorial effects of interacting equipments and
   software in YANG is potentially possible, the mechanisms available
   are not designed for this purpose and the results would probably be a
   large set of special models with extremely cumbersome/complex
   definitions that would be distinct from the interface model that is
   necessarily open and broad.

4.  Specification in terms of the Model

   The specification of capability of equipment with applied data should
   be presented in terms of the _generalized capability model_ from
   [GenCapPrin] and explicitly mapped to the inventory and entitlement
   contexts.

   The relationships between these elements can be summarized as:














Davis, et al.             Expires 23 April 2026                 [Page 7]

Internet-Draft                 EquCapAppl                   October 2025


    +=============+========================+==========================+
    | Concept     | Defined In             | Represents               |
    +=============+========================+==========================+
    | Capability  | [GenCapPrin], this     | The potential functions  |
    | Spec        | draft                  | and limits of an         |
    |             |                        | equipment type           |
    +-------------+------------------------+--------------------------+
    | Entitlement | [EntitlementInventory] | The subset of            |
    |             |                        | capabilities permitted   |
    |             |                        | or licensed              |
    +-------------+------------------------+--------------------------+
    | Inventory   | [BaseInventory]        | The actual occurrence of |
    | Item        |                        | an entitled capability   |
    |             |                        | in the network           |
    +-------------+------------------------+--------------------------+

                                  Table 1

   This linkage ensures that refinement and occurrence formation have a
   tangible operational anchor in network management systems.

5.  Some specification examples

   This section illustrates how equipment capability specifications
   connect to entitlement and inventory concepts.

   Example covering an Optical Transponder:

   1.  *Generic capability*: an abstract optical transponder supporting
       multiple modulation formats up to 800 G.

   2.  *Equipment capability specification*: a vendor-specific model
       constrained to 400 G operation, defining port, thermal, and power
       envelopes.

   3.  *Entitlement*: a software license enabling the 400 G feature set;
       represented via the entitlement model.

   4.  *Inventory occurrence*: a deployed device instance that has the
       entitlement applied and exposes its active capabilities through
       inventory records.

   This recursive narrowing from generic capability to entitled
   occurrence demonstrates how specification refinement is operationally
   realized.






Davis, et al.             Expires 23 April 2026                 [Page 8]

Internet-Draft                 EquCapAppl                   October 2025


   Note that the use of the physical and functional considerations are
   recursively intertwined... a bit of physical, emergent function,
   function assembly, physical assembly thermals etc.

   Note: Start with a generalized equipment and a generalized function
   and sketch the narrowing.

   An equipment in a physical context considering how it fits and what
   fits in it... -type -size -thermals -power/thermal -physical
   compatibility -electrical compatibility -diagram or compatibilities
   from ONF work -physical assemblies and thermals

   Function emergent from a physical equipment with applied data -raw
   functions (use ProcessingConstruct recursion as per ONF) -emergent
   capabilities and needs -functional compatibility -power and thermals
   per functions

   A system of equipments in an assembly -functional assemblies -power
   and thermals per assembly

   A system arrangements for a protection scheme.

   A specification for a system arrangement for a service and associated
   realization pattern specifications.

6.  Recursive narrowing

   This general principle is considered in the context of equipment
   specification.

7.  Specification of an assembly

   Highlighting this general principle in terms of assemblies of
   equipment with applied data and the emergent behaviour that results.

8.  Generalization of the specification

   Showing the reuse of specification fragments.

9.  Using the language of specification

   This requires work in the generalized capabilities draft.

10.  Building the equipment specification structure

   Take the language and general structure and build specific equipment.





Davis, et al.             Expires 23 April 2026                 [Page 9]

Internet-Draft                 EquCapAppl                   October 2025


11.  Conclusion

   This document applies the generalized capability principles to the
   specific case of equipment with applied data.  By linking equipment
   capability descriptions to entitlements and inventory items, it
   creates a complete semantic chain from potential -> permitted ->
   realized.

   This alignment ensures that planning, procurement, licensing, and
   operational systems can reason coherently about equipment functions
   and their lifecycle.  The approach enables automation, energy- and
   sustainability-aware network management, and AI-assisted reasoning
   grounded in formally defined capability structures.

12.  Security Considerations

   TBD

13.  IANA Considerations

   This document has no IANA actions.

14.  References

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

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

   [EntitlementInventory]
              Palmero, M. P., Cardona, C., and D. Lopez, "A YANG Module
              for Entitlement Inventory", Work in Progress, Internet-



Davis, et al.             Expires 23 April 2026                [Page 10]

Internet-Draft                 EquCapAppl                   October 2025


              Draft, draft-ietf-ivy-entitlement-inventory-01, 20 October
              2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
              ivy-entitlement-inventory-01>.

   [GenCapPrin]
              "Generalized Capability Principles", n.d.,
              <https://github.com/OpenNetworkingFoundation/TAPI/
              releases/tag/v2.4.0>.

   [ITU-T_G.7711]
              "Generic….", 31 August 2022, <https://www.itu.int/rec/T-
              REC-G.7711/recommendation.asp?lang=en&parent=T-REC-
              G.7711-202202-I)>.

   [ivy]      "ivy", 31 August 2022, <https:// 3.pdf>.

   [LF_TAPI]  "Transport API", n.d., <https://github.com/Open-Network-
              Models-and-Interfaces-ONMI/TAPI-Home>.

   [mobo]     "draft-davis-netmod-modelling-boundaries", 31 August 2022,
              <https:// 3.pdf>.

   [ONF_TR-512]
              "TR-512 Core Information Model (CoreModel) v1.5", n.d.,
              <https://opennetworking.org/wp-content/uploads/2021/11/TR-
              512_v1.5_OnfCoreIm-info.zip>.

   [ONF_TR-512.7]
              "TR-512.7 Specification", n.d.,
              <https://opennetworking.org/wp-content/uploads/2021/11/TR-
              512_v1.5_OnfCoreIm-info.zip>.

   [ONF_TR-512.8]
              "TR-512.8 Control", n.d., <https://opennetworking.org/wp-
              content/uploads/2021/11/TR-512_v1.5_OnfCoreIm-info.zip>.

   [ONF_TR-512.A.2]
              "TR-512.A.2 Appendix: Model Structure, Patterns and
              Architecture", n.d., <https://opennetworking.org/wp-
              content/uploads/2021/11/TR-512_v1.5_OnfCoreIm-info.zip>.

   [plug]     "plug", 31 August 2022, <https:// 3.pdf>.

Appendix A.  Acknowledgments

   This document has been made with consensus and contributions coming
   from multiple drafts with different visions.  We would like to thank
   all the participants in the IETF meeting discussions.



Davis, et al.             Expires 23 April 2026                [Page 11]

Internet-Draft                 EquCapAppl                   October 2025


Contributors

   Nigel Davis
   Ciena
   Email: ndavis@ciena.com


Authors' Addresses

   Nigel Robert Davis
   Ciena
   Email: ndavis@ciena.com


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


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


   Marisol Palmero
   Independent
   Email: marisol.ietf@gmail.com
























Davis, et al.             Expires 23 April 2026                [Page 12]
