Early Review of draft-ietf-ivy-network-inventory-topology-06
review-ietf-ivy-network-inventory-topology-06-opsdir-early-barguil-2026-05-04-00

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