Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this Internet-Draft. 

The Operational Directorate reviews all operational and management-related Internet-Drafts to ensure alignment with operational best practices and that adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in IETF Specifications"_ can be found at https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/.

While these comments are primarily for the Operations and Management Area Directors (Ops ADs), the authors should consider them alongside other feedback received.

- Document: A YANG Network Data Model for Inventory Topology Mapping
- Reviewer: Samier Barguil
- Review Date: 05-04-2026
- Intended Status: Standards Track 

---

## Summary 

- Has Nits: This document is basically ready for publication but has nits that should be considered prior to publication.

## General Operational Comments Alignment with RFC 5706bis 

The draft "Inventory Topology Mapping" provides a YANG data model designed to correlate layer-specific topology information with underlay network inventory data, with the goal of improving service provisioning and maintenance.The draft demonstrates strong operational feasibility by balancing automation with manual flexibility. It supports both autodiscovery — the model is primarily intended for network controllers to report automatically discovered data, reducing the need for manual data entry — and manual addition of attributes. To handle "blind spots" where discovery is not possible, such as customer-premises equipment (CPE), leased lines, or third-party resources, the mapping attributes are defined as read-write (config true), allowing operators to populate them directly.

The draft aligns with the Operations and Management guidelines (often referred to as RFC 5706-bis) through its comprehensive management and security sections.

## Nits 

Optional editorial suggestions:

 > Abstract: "service provisioning, network maintenance operations" — consider adding a comma to read "service provisioning, network maintenance, operations" if these are intended as three distinct items rather than two.

 > Section 3.1 — Potential improvements for clarity: While the logical mapping is clear, the explanation is relatively brief. The text refers to Figure 1 to illustrate the usage, but the figure itself is not self-explanatory: it includes model names and boxes, but does not show directions or interactions between them. Additionally, providing a brief walkthrough of a "failed" check (e.g., what happens if the capacity is insufficient) would further reinforce the "what-if" utility mentioned in the following section.

 > Network-type: For other topology models, consider including a type attribute to differentiate controller capabilities, e.g.: augment /nw:networks/nw:network/nw:network-types:

 > Acronym expansions: Several acronyms are used in the text without being expanded on first use or in the terminology section:
	EOL — used in Section 3.2 ("impact prediction of hardware EOL"); should be expanded as "End-of-Life".
	MPO — used in the title and description of Appendix B ("MPO breakout-channel port"); should be expanded as "Multi-fiber Push On".