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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 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, . [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, . [GenCapPrin] "Generalized Capability Principles", n.d., . [ITU-T_G.7711] "Generic….", 31 August 2022, . [ivy] "ivy", 31 August 2022, . [LF_TAPI] "Transport API", n.d., . [mobo] "draft-davis-netmod-modelling-boundaries", 31 August 2022, . [ONF_TR-512] "TR-512 Core Information Model (CoreModel) v1.5", n.d., . [ONF_TR-512.7] "TR-512.7 Specification", n.d., . [ONF_TR-512.8] "TR-512.8 Control", n.d., . [ONF_TR-512.A.2] "TR-512.A.2 Appendix: Model Structure, Patterns and Architecture", n.d., . [plug] "plug", 31 August 2022, . 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]