IETF Last Call Review of draft-ietf-ivy-network-inventory-yang-11
review-ietf-ivy-network-inventory-yang-11-yangdoctors-lc-rahman-2025-11-29-00

Please bear in mind that I haven't followed discussions on this document...

Issues (maybe)
==============

- The model is read-only and the reasoning is explained in section 6. Did the
authors consider having a read-write model and using access control, i.e NACM.
Section 6 states: "The information in the model is populated by controller by
reading it
   from the devices using the device model supported by the devices.". That is
   one way of doing it, but another implementation may want to populate the
   data via a read-write model?

- For the inventory I was expecting something which would tell me the "state"
of a network element e.g. is it in production, in a lab or a spare device? I
realize that the current expected implementation (section 6) is to read data
from the devices so it assumes that the devices are deployed, but an inventory
is also useful for the devices from which we can't (yet) read. Or is this use
case deemed outside the scope of this document?

Comments/questions
==================

- Introduction:
   Network
   inventory management is a critical part for ensuring that the network
   remains healthy (e.g., auditing to identify faulty elements)
Do we really need inventory mgmt for ensuring that the network remains healthy?

- Terminology. The terms borrowed (MDSC, MPI etc) from RFC8453 should be
mentioned here?

- YANG model

In grouping basic-common-entity-attributes, for "leaf name" the description
says "If no configured value exists...". The tree is read-only so that
description doesn't currently make sense?

parent-rel-pos,  RFC6933 has entPhysicalParentRelPos as -1 .. 2147483647 but
parent-rel-pos starts at 0. Also the description says "only when this component
is contained in the network-element or in only 1 parent", is the 1st part
accurate?

Ne-type why is only ne-physical defined? Couldn't the network inventory also
have virtual appliances/devices? In the description of ne-type, spell out
Network Element.

In grouping component-attributes, when using
ne-component-common-entity-attributes, the refined description states "physical
component", why is physical specified here I.e. does it have a special meaning?

base non-hardware-component-class => add the prefix of this module

- Thank you for the many examples. Have they been validated?

Regards,
Reshad.