Network Inventory YANG A. Guo Internet-Draft Futurewei Intended status: Standards Track T. V. Caenegem Expires: 20 September 2026 Nokia N. Davis Ciena M. Tilocca FiberCop B. Peters NBN 19 March 2026 A YANG Data Model for Passive Network Inventory draft-ygb-ivy-passive-network-inventory-latest Abstract This document presents a YANG data model for tracking and managing passive network inventory. The model augments the base network inventory model. 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://aguoietf.github.io/draft-ygb-ivy-passive-network-inventory/ draft-ygb-ivy-passive-network-inventory.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- ygb-ivy-passive-network-inventory/. Discussion of this document takes place on the Network Inventory YANG Working Group mailing list (mailto:ivy@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ivy. Subscribe at https://www.ietf.org/mailman/listinfo/ivy/. Source for this draft and an issue tracker can be found at https://github.com/aguoietf/draft-ygb-ivy-passive-network-inventory. 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 20 September 2026. Copyright Notice Copyright (c) 2026 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 2. Examples of Passive Network Inventory 2.1. Passive Infrastructure in Optical Transport Networks 2.2. Passive Infrastructure in Optical Access Networks 2.3. Passive Infrastructure in Microwave Networks 2.4. Editorial Note (To be removed by RFC Editor) 3. Terminology and Notations 3.1. Terminology 3.2. Tree Diagram 3.3. Prefixes in Data Node Names 4. Modeling Considerations 4.1. Relationship with Network Inventory 4.2. Relationship with Topology 5. YANG Model Overview 6. YANG Modules 6.1. YANG Data Model for Passive Device Inventory 7. Operational Considerations 8. Security Considerations 9. IANA Considerations 10. References 10.1. Normative References 10.2. Informative References Appendix A. The Complete Schema Trees Acknowledgments Contributors Authors' Addresses 1. Introduction Passive infrastructure refers to the underlying infrastructure of a telecommunication network that is not actively detectable or manageable. It typically includes non-powered, non-communicating devices and components, such as cabinets, cables, connectors, splitters, antennas, distribution frames, etc., that are either hosted within an actively managed device or deployed along the physical pathway between active devices. Passive infrastructure serves as physical connections between active network devices, forming the backbone for network topology. As a crucial part of communication networks,the inventory information for these devices is also essential for inventory management. [I-D.ietf-ivy-network-inventory-yang] incorporates the component concept from [RFC8348] to detail the equipment and holder information of a NE. This encompasses chassis, slot/sub-slot, board/sub-board, port, and transceiver. As these items are recognized by the NE through internal protocols, the passive devices that cannot be discovered by the NE are thus not included in the modeling and needs to be addressed. [I-D.ietf-ivy-network-inventory-location] emphasizes the relative and geographic location, e.g. equipment room, geo-loation for NE. A passive device is deployed in a certain location visible by the operator, and thus can reference the location defined by [I-D.ietf-ivy-network-inventory-location]. This document focuses on modeling passive device inventory. The scope of this model is intended to be applicable to a varity types of networks, including but not limited to, IP/MPLS, optical access, optical transport and microwave networks. The methods for learning about these devices are implementation-specific and fall outside the scope of this document. 2. Examples of Passive Network Inventory Network segments built on different technologies share many common passive infrastructure components across the system. To explore the practical applications of these components, we can examine example scenarios for optical access networks, optical transport systems, and microwave networks. 2.1. Passive Infrastructure in Optical Transport Networks Passive infrastructure in optical transport networks serves as the backbone for high-capacity data transmission. Key components include fiber optic cables, which act as the primary medium of long distance transmission. Optical connectors, patch panels, and splice enclosures are crucial for joining and managing fiber links. Couplers and splitters are used for signal distribution and combining. Within a phyical network element (NE) there are also presence of passive components. For example, fiber optic cables are used to connect the ports of different modules within the same or between different chassises. Attenuators, on the other hand, are placed at places through connectors or built-in modules for reducing optical power. Figure 1 illustrates a typical passive infrastructure for a point-to- point optical transport network. Port +--------------+ +-+ +--------------+ | +---+ | +-----+ +----+ | +---+ | | | +++ |<--Cable--->| +-+ |<--Cable--->| +++ | | | | ++* +---+ | | / \ | | +---+ *++ | | | |NE |\+++ | |Cable- Cable| / \ |Cable- Cable| | +++/| NE| | | +---+ *++ +++|<-->| |<-->+++/ \+++<->| |<--->|+++ ++* +---+ | | | + +|----| |----+ |----------| +---| |-----|+ + | | | +++ +++|----| |----+++\ /+++---| |-----|+++ +++ | | +---+/*++ | | - | \ / | - | | ++*\+---+ | | | +*+ |ODF| | Joint | \ / | Joint | |ODF| +*+ | | | | +++ +---+ | Box | \ / | Box | +---+ +++ | | | |NE | | | *-+ | | | NE| | | +---+ | +-----+ +----+ | +---+ | |Central Office| +-+ |Central Office| +--------------+ Fiber +--------------+ Distribution Terminal Figure 1: Passive Infrastructure for Optical Transport Networks 2.2. Passive Infrastructure in Optical Access Networks Passive Optical Networks (PONs) are a typical type of optical access network with significant passive infrastructure. The passive infrastructure in PON, often referred to as Optical Distribution Network (ODN), is the physical optical fiber-based network that connects the Optical Line Terminal (OLT) typically hosted in a central office to the Optical Network Unit/Terminal (ONU/ONT) typically deployed at the user's location. The ODN is equipped with one or multiple cascaded passive optical splitter thus creating a physical point-to-multipoint fiber network between an OLT port and the multiple connected ONU/ONTs. The feeder segment of an ODN refers to the cabling between the OLT and the first splitter, whereas the distribution segment of the ODN comprises the fiber cabling between the first and second splitter stage. The drop segment comprises the drop fibers between the ONT/ ONU and the second splitter stage. The PON ODN hence comprises optical fiber cables and splitters but also many auxiliary components, such as connectors, fiber distribution terminals (FDT), fiber access terminals (FAT), wavelength co-existence elements, etc. The passive components where the optical signals entering or leaving the optical fibers are split/ combined or cross-connected are typically hosted in mini cabinets e.g. at street corners, manholes, attached to utility poles, etc. Figure 2 illustrates a typical passive infrastructure for optical access networks. +--------------+ <--Drop--> | +---+ | Cable | | +++ |<-Feeder Cable-> <--Distr.--> /|----------+-+ONU | | ++* +---+ | Cable / | +-+ | |NE |\+++ | | Cable - Cable /|------------x |FDT | +---+ *++ +++|<---->/ \<----> / | \ | | (OLT) | + +|------| |------x/ | \|----------+-+ONU | +++ +++|------| |------x | cccccccc +-+ | +---+/*++ | | \ / \ | c /| c | | +*+ |ODF| | - \ | c / | c | | +++ +---+ | Joint \|-c-x | c | |NE | | Box FDT c \ | c<---Drop Cable-->+-+ONU | +---+ | c \|-c-----------------+-+ | (OLT) | c FDT the assigned RFC number for this I-D * YYYY --> the assigned RFC number for [I-D.ietf-ivy-network-inventory-yang] * ZZZZ --> the assigned RFC number for [I-D.ietf-ivy-network-inventory-location] Please replace the revision date of the latest revision of the 'ietf- nwi-passive-inventory' module with the publication date of this I-D, using the the format (year-month-day). Please manually fix the YANG trees in Appendix A which have been generated by pyang and have some bugs. 3. Terminology and Notations 3.1. Terminology The following terms are defined in [RFC7950] and are not redefined here: * client * server * augment * data model * data node The following terms are defined in [RFC6241] and are not redefined here: * configuration data * state data The following terms are defined and used in this document. * Passive device: refers to a physical device within a network that does not require external power to function, and simply manipulates signals through processes like transmission, reflection, splitting, filtering, or attenuation without actively amplifying or generating the signal. Examples include optical fibers, splitters, couplers, and optical filters, all of which are used to direct signals within a system without needing power. A passive device typically does not have management interfaces and is typically deployed in a location tracked by the network operator. * Active device: refers to a physical device that contains hardware and software and is managable through communication interfaces. Network elements defined by [I-D.ietf-ivy-network-inventory-yang] are examples of active device. * Guiding media: refers to physical transmission pathways - such as optical fiber cables, electrical cables, and coaxial cables - that direct and confine electromagnetic signals along a specific route. These media provide a bounded channel for data transmission, ensuring signal integrity, minimizing interference, and enabling high-speed communication over varying distances. This category is also commonly known as guided media or wired transmission media. Guiding media can be concatenated to form longer guiding media. * Optical Cable: refers to a type of guiding media that uses optical fiber as media to transmit optical signals. An optical cable can contain one or multiple fiber cores, also known as fiber strands, each serving as an independent guiding media for data transmission. Optical cables can be spliced or fused through joint boxes, optical distribution frames (ODF), or fiber jumpers. * Electrical Cable: refers to a type of guiding media that uses metal conductors (such as copper or aluminum wires) as a medium to carry electrical signals for communication or power distribution. Common examples include twisted-pair cables (such as CAT-5/6 and DSL cables), and coaxial cables, which feature a single-core conductor commonly used in DOCSIS and MoCA-based broadband access networks. Electrical cables can be connected through splicing, connectors, or junction boxes. 3.2. Tree Diagram Tree diagrams used in this document follow the notation defined in [RFC8340]. 3.3. Prefixes in Data Node Names In this document, names of data nodes and other data model objects are prefixed using the standard prefix associated with the corresponding YANG imported modules, as shown in Table 1. +==========+========================+===========+ | Prefix | YANG module | Reference | +==========+========================+===========+ | nwi | ietf-network-inventory | [RFCYYYY] | +----------+------------------------+-----------+ | nil | ietf-ni-location | [RFCZZZZ] | +----------+------------------------+-----------+ | l0-types | ietf-layer0-types | RFC XXXX | +----------+------------------------+-----------+ Table 1: Prefixes and corresponding YANG module 4. Modeling Considerations 4.1. Relationship with Network Inventory TBD 4.2. Relationship with Topology TBD 5. YANG Model Overview The YANG data model in this draft augments the model defined in [I-D.ietf-ivy-network-inventory-yang] with the following information: * Passive devices: a list of passive devices with extended attributed reported by the domain controller. * Cables: a list of cables with each containing an optional list of child cables. 6. YANG Modules 6.1. YANG Data Model for Passive Device Inventory file "ietf-nwi-passive-inventory@2026-03-19.yang" module ietf-nwi-passive-inventory { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-nwi-passive-inventory"; prefix nwi-passive; import ietf-network-inventory { prefix nwi; reference "RFC YYYY: A YANG Data Model for Network Inventory"; } import ietf-ni-location { prefix nil; reference "RFC ZZZZ: A YANG Data Model for Network Inventory Location"; } organization "IETF Network Inventory YANG (IVY) Working Group"; contact "WG Web: WG List: Editor: Chaode Yu Editor: Aihua Guo Editor: Italo Busi "; description "This YANG module specifies a data model for passive devices, such as fibers, cables, and passive sites, deployed within and between network elements. Copyright (c) 2026 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2026-03-19 { description "Initial version"; reference "RFC XXXX: A YANG Data Model for Passive Device Info in Network Inventory."; } /* Identities */ identity fiber-type { description "Base identity for fiber types."; } identity G652A { base fiber-type; description "ITU-T G.652A fiber."; } identity G652B { base fiber-type; description "ITU-T G.652B fiber."; } identity G652C { base fiber-type; description "ITU-T G.652C fiber."; } identity G652D { base fiber-type; description "ITU-T G.652D fiber."; } identity G653 { base fiber-type; description "ITU-T G.653 fiber."; } identity G654 { base fiber-type; description "ITU-T G.654 fiber."; } identity G655 { base fiber-type; description "ITU-T G.655 fiber."; } identity G656 { base fiber-type; description "ITU-T G.656 fiber."; } identity G657A1 { base fiber-type; description "ITU-T G.657A1 fiber."; } identity G657A2 { base fiber-type; description "ITU-T G.657A2 fiber."; } identity G657B { base fiber-type; description "ITU-T G.657B fiber."; } identity other { base fiber-type; description "Other type of fiber."; } identity cable-type { description "Base identity for cable types."; } identity optical-fiber { base cable-type; description "Fiber optic cable."; } identity electrical-cable { base cable-type; description "Electrical cable."; } identity coaxial-cable { base electrical-cable; description "Coaxial cable."; } identity cable-role { description "Base identity for cable roles."; } identity backbone { base cable-role; description "Backbone cable."; } identity aggregation { base cable-role; description "Aggregation cable."; } identity access { base cable-role; description "Access cable."; } identity trunk { base cable-role; description "Trunk cable."; } identity distribution { base cable-role; description "Distribution cable."; } identity branch { base cable-role; description "Branch cable."; } identity passive-port-type { description "Base identity for passive port types."; } identity service-port { base passive-port-type; description "Service port."; } identity input-port { base passive-port-type; description "Input port."; } identity output-port { base passive-port-type; description "Output port."; } identity p2mp-port { base passive-port-type; description "Input port."; } identity connected-device-type { description "Base identity for connected device types."; } identity passive-device { base connected-device-type; description "Passive/unmanaged device."; } identity active-device { base connected-device-type; description "Active device, e.g. network element."; } identity passive-device-type { description "Base identity for passive device types."; } identity ODF { base passive-device-type; description "Optical Distribution Frame."; } identity WDM { base passive-device-type; description "Wavelength Division Multiplexer."; } identity FAT { base passive-device-type; description "Fiber Access Terminal."; } identity FDT { base passive-device-type; description "Fiber Distribution Terminal."; } identity ATB { base passive-device-type; description "Access Terminal Box."; } /* Groupings */ grouping connected-device-end { description "Attributes applicable to connected device end."; leaf device-type { type identityref { base connected-device-type; } description "Type of connected device."; } choice connected-device-type { description "Device end based on the type of connected device."; case passive { leaf device-id { type string; must "derived-from-or-self(../device-type, 'nwi-passive:passive-device')"; description "Connected passive device identifier."; } } case active { leaf ne-ref { type leafref { path "/nwi:network-inventory/nwi:network-elements" + "/nwi:network-element/nwi:ne-id"; } must "derived-from-or-self(../device-type, 'nwi-passive:active-device')"; description "Referenced Network Element (NE)."; } leaf component-ref { type leafref { path "/nwi:network-inventory/nwi:network-elements" + "/nwi:network-element[nwi:ne-id=current()/.." + "/ne-ref]/nwi:components/nwi:component" + "/nwi:component-id"; } must "derived-from-or-self(../device-type, 'nwi-passive:active-device')"; description "Referenced connected active device's component, e.g. port component."; } } } } grouping connected-device-ref { description "Attributes applicable to connected devices."; container a-end { description "A-end device reference"; uses connected-device-end; } container z-end { description "Z-end device reference"; uses connected-device-end; } } grouping common-cable-attributes { description "Common attributes of cables applicable to the cable and its child cables."; leaf id { type string; description "Cable identifier."; } leaf length { type uint32; units "meter"; description "Length of the cable in meter."; } uses connected-device-ref; } grouping optical-cable-attributes { description "Attributes applicable to fiber optic cables."; container optical-cable { when "derived-from-or-self(../cable-type, 'optical-fiber')"; description "Container for attributes associated with fiber optic cables."; leaf fiber-core-num { type uint32; description "Number of fiber cores within the cable."; } leaf fiber-type { type identityref { base fiber-type; } description "Type of fiber contained in the cable."; } leaf attenuation { type decimal64 { fraction-digits 2; } units "dB"; description "The fiber attenuation in dB."; } } } grouping cable-attributes { description "Attributes of cables."; uses common-cable-attributes; uses nwi:basic-common-entity-attributes; leaf cable-type { type identityref { base cable-type; } description "Type of cable."; } leaf cable-role { type identityref { base cable-role; } description "Role of cable."; } uses optical-cable-attributes; } grouping child-cables { description "Attributes applicable to child cables that are concatnated to form the cable."; list child-cable { key "index"; min-elements 2; description "Ordered list of concatenated child cables."; leaf index { type uint8; description "An index number used to identify the concatenation order of the child cables."; } uses common-cable-attributes; } } grouping cables { description "Attributes applicable to cables."; list cable { key "id"; description "List of cables."; uses cable-attributes; uses child-cables; } } grouping passive-device-ports { description "Attributes applicable to passive device ports."; list passive-port { key "id"; description "List of ports on a passive device."; leaf id { type string; description "Port identifier."; } uses nwi:basic-common-entity-attributes; leaf port-type { type identityref { base passive-port-type; } description "Type of passive port."; } leaf fiber-core-num { type uint32; description "Number of fiber cores within the port."; } } } grouping passive-devices { description "Attributes applicable to passive devices."; list passive-device { key "id"; description "List of passive devices."; leaf id { type string; description "Cable identifier."; } uses nwi:basic-common-entity-attributes; leaf device-type { type identityref { base passive-device-type; } description "Type of passive device."; } leaf-list custom-tags { type string; description "Customized tags, e.g. RFID, QR code that are attached to the device."; } leaf location-ref { type nil:ni-location-ref; description "Referenced location for the passive device."; } uses passive-device-ports; } } /* Augmentation */ augment "/nwi:network-inventory" { description "Augment network inventory with information for optical cables and passive devices."; uses cables; uses passive-devices; } } Figure 3: YANG model for passive network inventory 7. Operational Considerations TBC per [I-D.opsarea-rfc5706bis]. 8. Security Considerations The YANG module specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. The NETCONF access control model [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. Considerations in Section 8 of [RFC8795] are also applicable to their subtrees in the module defined in this document. Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. Considerations in Section 8 of [RFC8795] are also applicable to their subtrees in the module defined in this document. 9. IANA Considerations IANA is requested to register the following URI in the "ns" registry within the "IETF XML Registry" group [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-nwi-passive-inventory Registrant Contact: The IESG XML: N/A; the requested URI is an XML namespace. IANA is requested to register the following YANG module in the "YANG Module Names" registry [RFC6020] within the "YANG Parameters" registry group. name: ietf-nwi-passive-inventory Maintained by IANA? N namespace: urn:ietf:params:xml:ns:yang:ietf-nwi-passive-inventory prefix: nwi-passive reference: RFC XXXX 10. References 10.1. Normative References [I-D.ietf-ivy-network-inventory-location] Wu, B., Belotti, S., Bouquier, J., Peruzzini, F., and P. Bedard, "A YANG Data Model for Network Inventory Location", Work in Progress, Internet-Draft, draft-ietf- ivy-network-inventory-location-05, 28 February 2026, . [I-D.ietf-ivy-network-inventory-yang] 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-14, 5 February 2026, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A YANG Data Model for Hardware Management", RFC 8348, DOI 10.17487/RFC8348, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8795] Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and O. Gonzalez de Dios, "YANG Data Model for Traffic Engineering (TE) Topologies", RFC 8795, DOI 10.17487/RFC8795, August 2020, . 10.2. Informative References [I-D.opsarea-rfc5706bis] Claise, B., Clarke, J., Farrel, A., Barguil, S., Pignataro, C., and R. Chen, "Guidelines for Considering Operations and Management in IETF Specifications", Work in Progress, Internet-Draft, draft-opsarea-rfc5706bis-06, 20 October 2025, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . Appendix A. The Complete Schema Trees This appendix presents the complete tree of the Passive Network Inventory data model. See [RFC8340] for an explanation of the symbols used. The data type of every leaf node is shown near the right end of the corresponding line. module: ietf-nwi-passive-inventory augment /nwi:network-inventory: +--rw cable* [id] | +--rw id string | +--rw length? uint32 | +--rw a-end | | +--rw device-type? identityref | | +--rw (connected-device-type)? | | +--:(passive) | | | +--rw device-id? string | | +--:(active) | | +--rw ne-ref? leafref | | +--rw component-ref? leafref | +--rw z-end | | +--rw device-type? identityref | | +--rw (connected-device-type)? | | +--:(passive) | | | +--rw device-id? string | | +--:(active) | | +--rw ne-ref? leafref | | +--rw component-ref? leafref | +--ro uuid? yang:uuid | +--rw name? string | +--rw description? string | +--rw alias? string | +--rw cable-type? identityref | +--rw cable-role? identityref | +--rw optical-cable | | +--rw fiber-core-num? uint32 | | +--rw fiber-type? identityref | | +--rw attenuation? decimal64 | +--rw child-cable* [index] | +--rw index uint8 | +--rw id? string | +--rw length? uint32 | +--rw a-end | | +--rw device-type? identityref | | +--rw (connected-device-type)? | | +--:(passive) | | | +--rw device-id? string | | +--:(active) | | +--rw ne-ref? leafref | | +--rw component-ref? leafref | +--rw z-end | +--rw device-type? identityref | +--rw (connected-device-type)? | +--:(passive) | | +--rw device-id? string | +--:(active) | +--rw ne-ref? leafref | +--rw component-ref? leafref +--rw passive-device* [id] +--rw id string +--ro uuid? yang:uuid +--rw name? string +--rw description? string +--rw alias? string +--rw device-type? identityref +--rw custom-tags* string +--rw location-ref? nil:ni-location-ref +--rw passive-port* [id] +--rw id string +--ro uuid? yang:uuid +--rw name? string +--rw description? string +--rw alias? string +--rw port-type? identityref +--rw fiber-core-num? uint32 grouping connected-device-end: +-- device-type? identityref +-- (connected-device-type)? +--:(passive) | +-- device-id? string +--:(active) +-- ne-ref? leafref +-- component-ref? leafref grouping connected-device-ref: +-- a-end | +-- device-type? identityref | +-- (connected-device-type)? | +--:(passive) | | +-- device-id? string | +--:(active) | +-- ne-ref? leafref | +-- component-ref? leafref +-- z-end +-- device-type? identityref +-- (connected-device-type)? +--:(passive) | +-- device-id? string +--:(active) +-- ne-ref? leafref +-- component-ref? leafref grouping common-cable-attributes: +-- id? string +-- length? uint32 +-- a-end | +-- device-type? identityref | +-- (connected-device-type)? | +--:(passive) | | +-- device-id? string | +--:(active) | +-- ne-ref? leafref | +-- component-ref? leafref +-- z-end +-- device-type? identityref +-- (connected-device-type)? +--:(passive) | +-- device-id? string +--:(active) +-- ne-ref? leafref +-- component-ref? leafref grouping optical-cable-attributes: +-- optical-cable +-- fiber-core-num? uint32 +-- fiber-type? identityref +-- attenuation? decimal64 grouping cable-attributes: +-- id? string +-- length? uint32 +-- a-end | +-- device-type? identityref | +-- (connected-device-type)? | +--:(passive) | | +-- device-id? string | +--:(active) | +-- ne-ref? leafref | +-- component-ref? leafref +-- z-end | +-- device-type? identityref | +-- (connected-device-type)? | +--:(passive) | | +-- device-id? string | +--:(active) | +-- ne-ref? leafref | +-- component-ref? leafref +--ro uuid? yang:uuid +-- name? string +-- description? string +-- alias? string +-- cable-type? identityref +-- cable-role? identityref +-- optical-cable +-- fiber-core-num? uint32 +-- fiber-type? identityref +-- attenuation? decimal64 grouping child-cables: +-- child-cable* [index] +-- index uint8 +-- id? string +-- length? uint32 +-- a-end | +-- device-type? identityref | +-- (connected-device-type)? | +--:(passive) | | +-- device-id? string | +--:(active) | +-- ne-ref? leafref | +-- component-ref? leafref +-- z-end +-- device-type? identityref +-- (connected-device-type)? +--:(passive) | +-- device-id? string +--:(active) +-- ne-ref? leafref +-- component-ref? leafref grouping cables: +-- cable* [id] +-- id? string +-- length? uint32 +-- a-end | +-- device-type? identityref | +-- (connected-device-type)? | +--:(passive) | | +-- device-id? string | +--:(active) | +-- ne-ref? leafref | +-- component-ref? leafref +-- z-end | +-- device-type? identityref | +-- (connected-device-type)? | +--:(passive) | | +-- device-id? string | +--:(active) | +-- ne-ref? leafref | +-- component-ref? leafref +--ro uuid? yang:uuid +-- name? string +-- description? string +-- alias? string +-- cable-type? identityref +-- cable-role? identityref +-- optical-cable | +-- fiber-core-num? uint32 | +-- fiber-type? identityref | +-- attenuation? decimal64 +-- child-cable* [index] +-- index uint8 +-- id? string +-- length? uint32 +-- a-end | +-- device-type? identityref | +-- (connected-device-type)? | +--:(passive) | | +-- device-id? string | +--:(active) | +-- ne-ref? leafref | +-- component-ref? leafref +-- z-end +-- device-type? identityref +-- (connected-device-type)? +--:(passive) | +-- device-id? string +--:(active) +-- ne-ref? leafref +-- component-ref? leafref grouping passive-device-ports: +-- passive-port* [id] +-- id string +--ro uuid? yang:uuid +-- name? string +-- description? string +-- alias? string +-- port-type? identityref +-- fiber-core-num? uint32 grouping passive-devices: +-- passive-device* [id] +-- id string +--ro uuid? yang:uuid +-- name? string +-- description? string +-- alias? string +-- device-type? identityref +-- custom-tags* string +-- location-ref? nil:ni-location-ref +-- passive-port* [id] +-- id string +--ro uuid? yang:uuid +-- name? string +-- description? string +-- alias? string +-- port-type? identityref +-- fiber-core-num? uint32 Figure 4: Tree diagram for passive network inventory Acknowledgments TODO acknowledge. Contributors Chaode Yu Huawei Email: yuchaode@huawei.com Mohammad Boroon Highstreet Email: mohammad.boroon@highstreet-technologies.com Italo Busi Huawei Email: italo.busi@huawei.com Sergio Belotti Nokia Email: sergio.belotti@nokia.com Swaminathan 1. S. Nokia Email: swaminathan.1.s@nokia.com Swaminathan B. Nokia Email: swaminathan.b@nokia.com Bin Yu Yun ETRI Email: byyun@etri.re.kr Yucong Liu China Mobile Email: liuyucongyjy@chinamobile.com Yang Zhao China Mobile Email: zhaoyangyjy@chinamobile.com Avinash Sakalabhaktula Radisys Email: Avinash.Sakalabhaktula@radisys.com Authors' Addresses Aihua Guo Futurewei Email: aihuaguo.ietf@gmail.com Tom Van Caenegem Nokia Email: tom.van_caenegem@nokia.com Nigel Davis Ciena Email: ndavis@ciena.com Mauro Tilocca FiberCop Email: mauro.tilocca@fibercop.it Brad Peters NBN Email: bradpeters@nbnco.com.au