]> Huawei

lana.wubo@huawei.com

Nokia

sergio.belotti@nokia.com

Vodafone

jeff.bouquier@vodafone.com

FiberCop

fabio.peruzzini@fibercop.com

Cisco

phbedard@cisco.com

Operations and Management Network Inventory YANG Automation Network Inventory Network Operation Topology This document defines a YANG data model for Network Inventory location (e.g., site, room, rack, geo-location data), which provides location information with different granularity levels for inventoried network elements. Accurate location information is useful for network planning, deployment, and maintenance. However, such information cannot be obtained or verified from the Network Elements themselves. This document defines a location model for network inventory that extends the base inventory with comprehensive location data. Discussion Venues Discussion of this document takes place on the Network Inventory YANG Working Group mailing list (inventory-yang@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction NEs can be grouped by location to provide more information for network planning, deployment, and maintenance (e.g., easily locate problematic NEs, optimize network resources, or help planning forecasts). The location can reflect outdoor or indoor information. An indoor location may be represented as a building, room, or other similar organizational structures. Outdoor locations can be walls, poles, or other mount places. The information about sites, equipment rooms, and other more precise locations is critical, but it cannot be automatically populated and retrieved from network elements (NEs). Instead, it is usually configured manually. The Network Inventory location model is to record physical locations, such as sites, building, equipment rooms, racks, and so on. Additionally, it includes provisions for physical addresses or geo- location data (geographic coordinates). The location model augments the base network inventory to enrich NEs with location information. The Network Inventory location model is classified as a network model (Section 3.5.1 of ). The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in . Note: The NMDA design needs to be revisited once the module is stable per (Section 4.23.2 of ).

Editorial Note (To be removed by RFC Editor) Note to the RFC Editor: This section is to be removed prior to publication. This document contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. Please apply the following replacements:

• XXXX --> the assigned RFC number for this document
• AAAA --> the assigned RFC number for

Terminology and Notations The following terms are defined in and are not redefined here:

• client
• server
• augment
• data model
• data node The following terms are defined in and are not redefined here:
• configuration data
• state data The tree diagram used in this document follows the notation defined in .

Also, this document uses terms defined in .

Hierarchical Locations of Network Inventory The "location" list is generalized to support a variety of geographic location, such as sites, rooms, buildings. A site represents a general geographic location to group a set of NEs and corresponding inventory components. NEs, racks, equipment rooms, and buildings can be grouped within a site. A room is a facility, a space for network elements and other equipment (such as servers, storage) with power supply systems, air conditioning system, etc. Locations can be nested to form a hierarchy. For example, buildings may be within a site, and a room may be within a building. The "location-type" is defined as a YANG identity to identify the type of an inventory location, which may be site, equipment room, building, etc.

YANG Subtree of Location ../../location/id | +--ro timestamp? yang:date-and-time | +--ro valid-until? yang:date-and-time | +--ro physical-address | | ... | +--ro geo-location | | ... | +--ro contained-chassis* [chassis-id] | ... ]]>

Rack "racks" represent physical equipment racks in which NEs can be installed, which facilitate device maintenance. Through "rack- location", each rack can be assigned to a site or a specific location within a site, such as an equipment room. Each rack is assigned a unique ID and a name in the context of a facility, e.g. a site. A rack may have some specific attributes, such as appearance-related attributes and electricity-related attributes. The height, depth and width are described by Figure 2 (please consider that the door of the rack is facing the user). Note: Further discussion is needed to decide whether to separate "racks" from the list of "location".

Height, Width and Depth of Rack

The rack attributes include:

YANG Subtree of Rack

Max-voltage: the maximum voltage supported by the rack.

Network Inventory Location Tree provides an overview of the data model for "ietf-ni-location" module.

Network Inventory Location Tree Structure ../../location/id | +--ro timestamp? yang:date-and-time | +--ro valid-until? yang:date-and-time | +--ro physical-address | | +--ro address? string | | +--ro postal-code? string | | +--ro state? string | | +--ro city? string | | +--ro country-code? string | +--ro geo-location | | +--ro reference-frame | | | +--ro alternate-system? string | | | | {alternate-systems}? | | | +--ro astronomical-body? string | | | +--ro geodetic-system | | | +--ro geodetic-datum? string | | | +--ro coord-accuracy? decimal64 | | | +--ro height-accuracy? decimal64 | | +--ro (location)? | | | +--:(ellipsoid) | | | | +--ro latitude? decimal64 | | | | +--ro longitude? decimal64 | | | | +--ro height? decimal64 | | | +--:(cartesian) | | | +--ro x? decimal64 | | | +--ro y? decimal64 | | | +--ro z? decimal64 | | +--ro velocity | | | +--ro v-north? decimal64 | | | +--ro v-east? decimal64 | | | +--ro v-up? decimal64 | | +--ro timestamp? yang:date-and-time | | +--ro valid-until? yang:date-and-time | +--ro contained-chassis* [chassis-id] | +--ro chassis-id uint32 | +--ro ne-ref? leafref | +--ro component-ref? leafref +--ro racks +--ro rack* [id] +--ro id string +--ro uuid? yang:uuid +--ro name? string +--ro alias? string +--ro description? string +--ro rack-location | +--ro location-ref? ni-location-ref | +--ro row-number? uint32 | +--ro column-number? uint32 +--ro height? uint16 +--ro width? uint16 +--ro depth? uint16 +--ro max-voltage? uint16 +--ro max-allocated-power? uint16 +--ro contained-chassis* [relative-position] | +--ro relative-position uint8 | +--ro ne-ref? leafref | +--ro component-ref? leafref +--ro timestamp? yang:date-and-time +--ro valid-until? yang:date-and-time ]]>

YANG Data model for Network Inventory Location The "ietf-ni-location" module uses types defined in , . WG List: Editor: Bo Wu Editor: Sergio Belotti Editor: Jean-Francois Bouquier Editor: Fabio Peruzzini Editor: Phil Bedard "; description "This YANG module defines a model for Network Inventory location. 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-02-28 { description "Initial version"; reference "RFC XXXX: A YANG Data Model for Network Inventory location."; //RFC Editor: Please replace XXXX with actual RFC number, //update date information and remove this note } /* Identities */ /* Typedef */ typedef ni-location-ref { type leafref { path "/nwi:network-inventory/nil:locations/nil:location" + "/nil:id"; } description "This type is used by data models that need to reference network inventory location."; } /* Grouping */ grouping physical-address { description "Grouping for physical address information."; container physical-address { description "Top-level container for the physical address."; leaf address { type string; description "Specifies an address (number and street)."; } leaf postal-code { type string; description "Specifies a postal code."; } leaf state { type string; description "Specifies a state. This leaf can also be used to describe a region for a country that does not have states."; } leaf city { type string; description "Specifies a city."; } leaf country-code { type string { pattern '[A-Z]{2}'; } description "Specifies a country. Expressed as ISO ALPHA-2 code."; } } } grouping locations { description "Grouping for locations."; container locations { config false; description "Container for the location information."; list location { key "id"; description "List of locations within the network."; leaf id { type string; description "An identifier of the location."; } uses nwi:basic-common-entity-attributes; leaf type { type string; description "The type of network inventory location, e.g. equipment room, building, or site. This allows operators to flexibly define custom location types (e.g., 'pole', 'roof', 'floor') based on their specific network scenarios without requiring model extensions. String-based types enable dynamic adaptation to heterogeneous organizational naming conventions."; } leaf parent { type leafref { path "../../location/id"; } description "The identifier of the location that physically contains this location."; } leaf timestamp { type yang:date-and-time; description "Timestamp when the location was recorded."; } leaf valid-until { type yang:date-and-time; description "The timestamp for which this location is valid until. If unspecified, the location has no specific expiration time."; } uses physical-address; uses geo:geo-location; list contained-chassis { key "chassis-id"; description "Chassis directly deployed in this location without rack. Also used for distributed chassis components that are logically part of a network element but physically located."; leaf chassis-id { type uint32; description "Unique identifier for this chassis instance in the location."; } leaf ne-ref { type leafref { path "/nwi:network-inventory/nwi:network-elements" + "/nwi:network-element/nwi:ne-id"; } description "Reference to the network element this chassis belongs to. Multiple chassis entries may reference the same ne-ref for distributed systems."; } 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"; } description "Reference to the specific chassis within the network element."; } } } uses racks; } } grouping racks { description "Grouping for rack attributes."; container racks { description "Top-level container for the list of racks."; list rack { key "id"; description "List of racks within the inventory (e.g., in an equipment room)."; leaf id { type string; description "An identifier that uniquely identifies the rack."; } uses nwi:basic-common-entity-attributes; container rack-location { description "The location information of the rack, which comprises the location reference, row number, and column number."; leaf location-ref { type ni-location-ref; description "Reference to the location where this rack is placed."; } leaf row-number { type uint32; description "Identifies the row within the location where the rack is located."; } leaf column-number { type uint32; description "Identifies the column within the location where the rack is located."; } } leaf height { type uint16; units "millimeter"; description "Rack height."; } leaf width { type uint16; units "millimeter"; description "Rack width."; } leaf depth { type uint16; units "millimeter"; description "Rack depth."; } leaf max-voltage { type uint16; units "volt"; description "The maximum voltage supported by the rack."; } leaf max-allocated-power { type uint16; units "watts"; description "The maximum allocated power for the rack."; } list contained-chassis { key "relative-position"; description "The list of chassis within a rack."; leaf relative-position { type uint8; description "Relative position (e.g., U-slot) of chassis within the rack."; } leaf ne-ref { type leafref { path "/nwi:network-inventory/nwi:network-elements" + "/nwi:network-element/nwi:ne-id"; } description "Reference to the network element containing the chassis component."; } 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"; } description "The reference to the chassis component within the network element and contained by the rack."; } } leaf timestamp { type yang:date-and-time; description "Timestamp when the rack information was recorded."; } leaf valid-until { type yang:date-and-time; description "The timestamp for which this rack is valid until. If unspecified, the rack has no specific expiration time."; } } } } augment "/nwi:network-inventory" { description "Provides location information for network inventory."; uses locations; } } ]]>

Operational Considerations This model serves as a complement to the base inventory, providing a read-only perspective of network inventory location information known to the controller. It reports the physical locations of network elements and components installed in the network, enabling queries for site, rack, and other location-related information associated with network elements and components. When used in brownfield scenarios, it is worth noting that existing deployments are based on proprietary inventory OSS solutions, and the migration path is highly dependent on the specific proprietary implementation. The model is designed based on the controller maintaining authoritative location data through automated tooling, while OSS systems consume this data as read-only operational state. Sources of controller location data may include RFID tooling, geolocation services, as well as manual entry via controller interfaces. As this data is read-only, the controller does not support OSS modification of controller location records. OSS systems and other management applications obtain location information via standard YANG retrieval operations (NETCONF, RESTCONF), such as querying network elements associated with a specific site or rack. In large-scale inventories containing numerous network elements and components, querying location associations can impose a load on the server. To optimize retrieval and avoid overwhelming the server, mechanisms such as RESTCONF or NETCONF pagination should be utilized for queries involving large result sets. Data quality is indicated through timestamps recording the last update time, as well as an optional expiration time for location validity. Before using a location for field dispatch or planning, verification is required to ensure at least one of physical-address or geo-location is present, and that the valid-until leaf is either not present or indicates a future time. Once the valid-until time has passed, the location MUST be considered stale and MUST NOT be used for operational purposes. A parallel "location-planning" container (read-write) may be introduced in future revisions to support intent-based configuration, where OSS provides planning-level location targets. This is outside the scope of the current document.

Security Considerations This section uses the template described in . The "ietf-ni-location" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF or RESTCONF . These protocols have to use a secure transport layer (e.g., SSH , TLS , and QUIC ) and have to use mutual authentication. The Network Configuration Access Control Model (NACM) 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). All writable data nodes are likely to be reasonably sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) and delete operations to these data nodes without proper protection or authentication can have a negative effect on network operations. The following subtrees and data nodes have particular sensitivities/vulnerabilities: 'locations': The list may be used to track the set of network elements. 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. Specifically, the following subtrees and data nodes have particular sensitivities/vulnerabilities: Since this module identifies locations, authors using this module SHOULD consider any privacy issues that may arise when the data is readable (e.g., customer device locations, etc).

IANA Considerations IANA is requested to register the following URI in the "ns" subregistry within the "IETF XML Registry" : IANA is requested to register the following YANG module in the "YANG Module Names" subregistry within the "YANG Parameters" registry.

References Normative References Huawei Technologies Nokia Vodafone FiberCop Cisco This document defines a base YANG data model for reporting network inventory. The scope of this base model is set to be application- and technology-agnostic. The base data model can be augmented with application- and technology-specific details. Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950. YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document defines a generic geographical location YANG grouping. The geographical location grouping is intended to be used in YANG data models for specifying a location on or in reference to Earth or any other astronomical object. This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). This document describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] Informative References YumaWorks Orange Huawei This document provides guidelines for authors and reviewers of specifications containing YANG data models, including IANA-maintained modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF Protocol implementations that utilize YANG modules. This document obsoletes RFC 8407. Also, this document updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained modules. This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. Huawei Technologies Nokia Vodafone TIM Cisco This document defines a YANG data model for network hardware inventory data information. The YANG data model presented in this document is intended to be used as the basis toward a generic YANG data model for network hardware inventory data information which can be augmented, when required, with technology-specific (e.g., optical) inventory data, to be defined either in a future version of this document or in another document. The YANG data model defined in this document conforms to the Network Management Datastore Architecture (NMDA).

Examples This section provides example usages of the Network Inventory Location model for two common deployment scenarios: a non-rack-mounted Access Point and a distributed multi-chassis network element.

Non-Rack Deployment: Access Point This example illustrates a typical edge deployment scenario where a Wi-Fi Access Point (AP) is mounted directly to a ceiling without a rack enclosure. The location hierarchy is as follows: The following shows the location data instance:

Distributed Multi-Chassis Network Element This example illustrates a distributed deployment where a single logical network element (NE-1, a stack switch) spans multiple physical locations. The three chassis of the stack switch are located in separate telecommunications rooms on different floors, interconnected via stacking cables. The location hierarchy is as follows: The following shows the location data instance:

Acknowledgments The authors would like to thank the authors and contributors of to trigger this work. During the discussion of base Network Inventory (NI) model, it is agreed that the definition of the equipment room and rack can be a separate location model and support manual configuration, while the NI model aggregates the inventory data of the Network Elements (NEs) on the network. Usually the information about sites or equipment rooms is not detectable by network controller and configured manually. The authors wish to thank Mohamed Boucadair and many others for their helpful comments and suggestions.

Contributors Huawei Technologies

italo.busi@huawei.com

Huawei

yuchaode@huawei.com