Early Review of draft-ietf-ivy-network-inventory-location-06
review-ietf-ivy-network-inventory-location-06-yangdoctors-early-lindblad-2026-07-21-00

This is my YANG Doctor review of draft-ietf-ivy-network-inventory-location-06.
I find the document easy to read, and the module to be essentially ready. I
have one question, though. If answered one way, there are just a few appendix
example updates to be done. Or else, a deeper remodeling for certain parts of
this is still required.

#1) Appendix A shows a few examples of how this location module could be used.
While the data there matches the model exactly and fulfills all constraints
perfectly, I think these small examples are misleading by not showing that all
IDs would have to be globally unique. For example, the A.1 is using location
names like "Foo-Enterprise-Campus", "Building A", "Floor-2", "Corridor-East".
And rack names like "Rack-101-A", "Rack-201-B", "Rack-301-C".

While these names are very nice and user friendly, they do not reflect the
global uniqueness requirement at scale. Since there can be only a single
"Floor-2" in the entire list of locations, more realistic example names would
be: "Foo-Enterprise-Campus", Foo-Enterprise-Campus--Building A", 
"Foo-Enterprise-Campus--Building A--Floor-2", "Foo-Enterprise-Campus--Building
A--Floor-2--Corridor-East". The racks would have to have globally unique names
in a similar fashion.

If this is the intended location naming structure, I'd suggest the examples are
updated to reflect this, as not to mislead readers.

If more compact names, only locally unique in the context of the parent
location are desired, that is possible to achieve -- but would bring its own
set of limitations and a few quite deep changes to the model.

#2) Prefix nil

The modelers have chosen "nil" as the prefix for this module. I guess it's an
abbreviation of network inventory location, or something like that. While "nil"
is a legal prefix in YANG, I would suggest that a different name is picked
since nil is a very loaded term (meaning none, nothing, null) among computer
folks. Many readers might be confused seeing "nil:" or "prefix nil". They might
start debugging something that is working perfectly. In the spirit of least
surprise, how about using "nilo" as prefix instead?

#3) String for open ended enumerations

There is a leaf type under location that is meant to describe the type of the
location. Since different operators may organize their equipment in different
ways, perhaps depending also on what markets they are operating in, the
modelers have chosen to leave the actual values open ended. Modeling the leaf
as a string rather than some sort of enumeration with fixed values. This
flexibility is laudable, and can obviously be made to work fine. There is a
risk however, that such an open ended model becomes non optimal in actual
operation scenarios because the lack of definitions of names used and possible
variations in spellings.

An alternative could be to define a small set of commonly used identities, and
model the type as an identityref. This allows proper definitions and catches
any spelling mistakes early. Any operator could easily define their own YANG
module with additional, or alternate location identities. It would simply be a
matter of including that module with the additional identities in the server,
to allow them to be used.

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

#4) Chassis number

Any chassis that is mounted outside a rack in a given location is modeled as
having a single integer as their chassis-id. This appears somewhat limiting,
and as far as I can tell, for no particular reason. If modeled as a string, the
chassis ID could be anything, including a number or combination of numbers. As
modeled here, the chassis-id does not need to be globally unique -- the
chassis-id is unique local to a specific location.
             leaf chassis-id {
               type uint32;
               description
                 "Unique identifier for this chassis instance in the
                  location.";

#5) Max rack power 65kW

As modeled, the max-allocated-power to any rack, now and in the future, cannot
exceed 65kW. In this age of AI loads, I believe this limit is already passed. I
would suggest using an uint32 instead. That should hopefully last at least
until November/December or so :-)
           leaf max-allocated-power {
             type uint16;
             units "watts";

#6) Typos

I noticed the -06 version of the draft had some formatting errors in sec 1.2
and there is some word missing in the YANG description field of list
contained-chassis.

Best Regards,
/Jan