Early Review of draft-ietf-ivy-network-inventory-location-06
review-ietf-ivy-network-inventory-location-06-opsdir-early-schoenwaelder-2026-09-30-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.

This document does not define a protocol, it instead defines a data model
exposing physical location information to network management systems. I have a
few comments and questions, if they have been already beaten to death by the
WG, just tell me. I have not followed this work, I am reading this without
knowing the context.

* Introduction

  - Does the model assume that the location of a NE is static? If so,
    it might be worth to spell this out explicitly. Or would the model
    also work for NEs on mobile objects? Would it be possible for
    locations to move dynamically from one part of the hierarchy to
    another?

* Terminology

  - Editorial: The sentence following 'data node' does not start on a
    new line.

  - Can you spell out which terms are imported from
    [ID.ivy-network-inventory-yang]?

* Rack

  - The document says:

    Note: Further discussion is needed to decide whether to separate
    "racks" from the list of "location".

  - I was wondering what the rack classes are meant to be.

* YANG Data model for Network Inventory Location

  - I do not understand the distinction between baseline/medium/high
    security lockable racks. If the class type is just about the
    physical security of racks, would an enum attribute do the same?
    And thinking further, other locations may have physical security
    attributes (like rooms), not just racks. So is it desirable to
    associate physical security with racks or should physical security
    be associated with locations?

  - Chassis may belong to locations, then they have an id and two
    reference. The chassis of a rack, however, have no id but they are
    identified by a relative position (e.g. U-slot). Perhaps I am
    wondering why racks are not just a locations. One could give all
    locations a height/width/depth and find a generic way to express
    how something is situated inside some container. And attributes
    like voltage and power may also apply to other locations, not just
    racks (e.g., antenna arrays mounted on roofs).

  - Perhaps change "Timestamp when the rack information was recorded"
    to "Timestamp when the rack information was last updated" if that
    is the intention (see Operational Considerations).