[Gen-art] Re: [Ivy] draft-ietf-ivy-network-inventory-yang-18 ietf last call Genart review

[Mahesh Jethanandani <[e-mail]>]

Hi Italo (and Authors),

Thanks for trying to address the GENART review comments from Elwyn 
and posting the -19 version of the draft. Here is my assessment of the document 
after that review and the update posted.

I believe you have managed to address most of the comments. There is but one 
MINOR and several NITS that were not addressed from his review, and some 
that got carried over. 

BTW, I have also requested an RTGDIR review as the shepherd flagged the 
relationship between TEAS and ACTN work.

----------------------------------------------------------------------
MINOR
----------------------------------------------------------------------

Section 6, component integration/de-integration (GENART major issue #2)

> Section 6, current text:
1531   Since this YANG data model reports what it is actually installed in
1532   the network, if a component (e.g., a board) is physically removed
1533   from the network, also its descendant components (e.g., daughter
1534   boards and ports) are also physically removed from the network and,
1535   as a consequence, from the inventory data being reported through this
1536   YANG data model.

This addresses removal cleanly, but Davies's question about the other
direction -- how a newly added/discovered component's inventory data gets
integrated, and whether that's expected to arrive atomically or
incrementally -- isn't addressed in the document, even though the authors'
list response says protocol-level change notifications handle it. A short
sentence saying so  would let a future reader find the rationale without having 
to dig up the list thread.

----------------------------------------------------------------------
NIT
----------------------------------------------------------------------

Several of these are new in -19 -- introduced by the same edits that fixed
the -18 reviewers' comments -- so they haven't been caught by anyone yet.

Section 5, `leaf name` description:
1101   "The name of the  entity (e.g., component), as specified by
1102    a network operator, that provides a non-volatile 'handle'
1103    for the entity. The The network operator can specify a
1104    different value anytime during the entity lifetime.
s/for the entity. The The network operator/for the entity. The network operator/
s/name of the  entity/name of the entity/ (double space)

Section 5, `leaf is-main` description:
1449                    It is therefore omitted in scenarios where the
1450                    network element does not contain chassis components
1451                    which can can take or not the 'main' role
s/which can can take/which can take/
(Pre-existing, not introduced in -19 -- carried forward from at least -18
unnoticed by prior reviewers.)

Appendix B, Terminology of Container:
2083   Within this document , term "container" represents an hardware
2084   component class capable of containing one or more removable physical
2085   entities, e.g., a slot in a chassis which is capabable to contain a
2086   board.
s/represents an hardware/represents a hardware/
s/which is capabable to contain a board/capable of containing a board/
(This paragraph was rewritten from -18 to remove first-person "we/our"
phrasing per Davies's comment, but the rewrite introduced the article
error and the "capabable" typo.)

Appendix C, Efficiency Issue:
2150   The main scope of this documento is to define the generic data model,
s/documento/document/

Acknowledgments:
3378   The authors would like to thank Reshad Rahman for his YANG Doctor
3379   eview.
s/YANG Doctor\n   eview./YANG Doctors review./
(Missing "r")

3381   The authors would like to thank Valery Smyslov, Samier Barguil, and
3382   for their Security Directorate, Operational Directorate (ops-dir),
3383   and General Area Review Team (Gen-ART) reviews.
This sentence is missing the GENART reviewer's name -- reads "...Samier
Barguil, and for their..." with a name-sized gap before "for their." Should
presumably be "...Valery Smyslov, Samier Barguil, and Elwyn Davies for
their Security Directorate, Operational Directorate (ops-dir), and General
Area Review Team (Gen-ART) reviews.”

Thanks.


> On Sep 17, 2026, at 5:48 AM, Italo Busi <[e-mail]> wrote:
> 
> Hi Elwyn,
> 
> Thanks a lot for your review and comments
> 
> We have just uploaded the -19 version of the draft addressing your comments as per our feedbacks below with the only exception that instead of using the term "intended to be running" for the software modules reported in the base inventory, which seems quite confusing, we have improved the description of the software information in the scope of this draft and use the term "running" consistently through the document
> 
> Thanks, Italo (on behalf of co-authors/contributors)
> 
>> -----Original Message-----
>> From: Italo Busi <Italo.Busi=[e-mail]>
>> Sent: giovedì 16 luglio 2026 12:18
>> To: Elwyn Davies <[e-mail]>; [e-mail]
>> Cc: [e-mail]; [e-mail]; last-
>> [e-mail]
>> Subject: [Ivy] Re: draft-ietf-ivy-network-inventory-yang-18 ietf last call Genart
>> review
>> 
>> Hi Elwyn,
>> 
>> Thanks a lot for your review and comments
>> 
>> See our feedbacks in line
>> 
>> We are still work on the detailed text changes and we will let you know when
>> we have uploaded the I-D update addressing your comments.
>> 
>> In the meanwhile, you can follow-up the on-going editorial work on github:
>> 
>> https://github.com/ietf-ivy-wg/network-inventory-yang/pull/166
>> 
>> Thanks, Italo (on behalf of co-authors/contributors)
>> 
>>> -----Original Message-----
>>> From: Elwyn Davies via Datatracker <[e-mail]>
>>> Sent: giovedì 11 giugno 2026 01:20
>>> To: [e-mail]
>>> Cc: [e-mail]; [e-mail];
>>> last- [e-mail]
>>> Subject: [Ivy] draft-ietf-ivy-network-inventory-yang-18 ietf last call
>>> Genart review
>>> 
>>> Document: draft-ietf-ivy-network-inventory-yang
>>> Title: A Base YANG Data Model for Network Inventory
>>> Reviewer: Elwyn Davies
>>> Review result: Ready with Issues
>>> 
>>> I am the assigned Gen-ART reviewer for this draft. The General Area
>>> Review Team (Gen-ART) reviews all IETF documents being processed by
>>> the IESG for the IETF Chair.  Please treat these comments just like any other
>> last call comments.
>>> 
>>> For more information, please see the FAQ at
>>> 
>>> <https://wiki.ietf.org/en/group/gen/GenArtFAQ>.
>>> 
>>> Document: draft-ietf-ivy-network-inventory-yang-18
>>> Reviewer: Elwyn Davies
>>> Review Date: 2026-06-10
>>> IETF LC End Date: 2026-06-10
>>> IESG Telechat date: Not scheduled for a telechat
>>> 
>>> Summary:  There is one potential issue that the document itself brings
>>> out and a couple of operational ssues that could make the
>>> specification difficult to use especially on larger systems.
>>> Otherwise, the document has a fair number of nits and editorial issues
>>> outside the YANG specification.  I have not looked at the form of the
>>> YANG in great detail.  Please note that some parts of the appendices are
>> (partly) written in academic paper style and need to be depersonalized.
>>> 
>>> Judging from the example in Appendix E, the comments in the Security
>>> section about the risks of very high volumes of YANG data needed to
>>> complete the inventory of a network seem rather too well justified. I
>>> don't know if this could be a show stopper but feel that consideration
>>> should be given to this matter by peole with more hands-on knowledge
>>> of inventory handling.  I wonder if the inventory could be segmented
>>> in some way to limit the size of chunks being handled.  I am unsure
>>> whether there is going to be much call for complete inventories to be
>>> interchanged.  It  strikes me that one aspect that has not been
>>> discussed here is the dynamic cnstruction of complete inventories.  I
>>> could see an example where a new component is added to a network:
>>> Would the expansion of the inventory be conveniently carried out by
>>> the new component carrying its own inventory and passing it over to
>>> the inventory server (with appropriate security checks) for
>>> integration into the overall inventory - as opposed to the central
>>> inventory being updated by manual/semi-automatic interaction at the
>>> inventory server.  There are also potential risks of the consistency of the
>> model being damaged by incomplete or faulty removal of the inventory
>> associated with a componet tht has been removed.
>>> 
>> 
>> [Authors] The volume of inventory data in large scale networks is huge, even if
>> does not change quite often during the time. Addressing the scalability issue is
>> outside the scope of the YANG data model but mainly a protocol issue (e.g.,
>> through pagination/segmentations, filtering, targeted notifications), outside
>> the scope of this document. Some considerations have been already provided
>> in Appendix C.
>> 
>>> Major issues:
>>> 1. Potential problem:  Size of complete YANG inventory specifications
>>> if needed to be interchanged between devices.
>> 
>> [Authors] See our reply to the summary above.
>> 
>>> 2. Possble problem:  Ease or difficulty of integrating/de-integrating
>>> YANG inventory specifications for added or subtracted components.
>> 
>> [Author]
>> 
>> Is the question related to adding or removing component types to the model or
>> adding or removing components from the network?
>> 
>> The inventory needs to be updated every time components are added or
>> removed from the network. Protocol-specific mechanisms can be used to notify
>> the client about these changes.
>> 
>> [\Author]
>> 
>>> 3. Handling inter-component connections and disconnections. Ensuring
>>> that changes to interconnections can be handled in a way that limits
>>> the scope for dangling connections to be left in place after changes
>>> to components.  This is not discussed in the document.
>>> 
>> 
>> [Author] Since this data model reports what it is actually installed in the
>> network, it is somewhat implicit that if a component is actually removed from
>> the network, also its descendant components are removed. We will add some
>> text to clarify this behavior.
>> 
>>> Minor issues:
>>> None
>>> 
>>> Nits/editorial comments:
>>> 
>>> S1, paras1 and 2:  The definition of Network Inventory really needs to
>>> appear right at the beginning of the text.  As this document is the
>>> primary output of the IVY WG, I would suggest copying all or at least
>>> the beginning of the first paragraph of the charter of the IVY WG to
>>> supply the definition of Network
>>> Inventory:- thus some of all of:
>>> 
>>>     Network inventory is a foundation for network management in all
>>> types
>>>     of: Network operators need to keep a record of what equipment
>>>     is planned and installed in their networks (including a variety of
>>>     information such as product name, vendor, product series, embedded
>>>     software, and hardware/software versions). Network inventories may
>>>     be constructed from management system data to represent the
>>> expected
>>>     devices present in the network, and also be used to audit and
>>> catalog
>>>    what devices are discovered in the network, and to expose that
>>>    information in a consistent way.
>>> 
>>> and delete para 2
>>> 
>> 
>> [Author] Ok in principle. However, this text is the scope of the IVY WG while the
>> scope of this document is a sub-set of it. We think we need to add some text to
>> indicate that the scope of this document is a subset of the whole network
>> inventory as defined in the IVY charter (e.g., installed and active components
>> and not planned or passive components)
>> 
>>> s1, para 3:  s/overall network management/scheme of network
>>> management/
>>> 
>>> s1, para 3: "which was specified many years ago"  If so, can we have a
>>> reference please.  I could not identify where this specification is
>>> located although maybe RFC 8969 may be relevant.  If there isn't one,
>>> just omit this phrase - I am quite prepared to accept that it is a useful
>> fundamental block.
>>> 
>> 
>> [Authors] The first sentence of this paragraph is now duplicated with the
>> Network Inventory definition added as proposed above. Therefore, we would
>> remove it.
>> 
>>> s1, para 3: s/well-planned/well-managed/ (One hopes that the planning
>>> precedes definition of the inventory;  the inventory essentially
>>> documents the plan).
>>> 
>> 
>> [Authors]
>> 
>> We share the concern because inventory data does not provide information
>> about whether the network is well-planned or not. However, the intention of
>> the sentence is to use inventory data to check whether the network is working
>> as planned or some re-planning is needed.
>> 
>> We would rephrase as:
>> 
>> Network inventory management is a critical component for ensuring the
>> infrastructure remains up-to-date (e.g., identifying assets that need to be
>> upgraded or decommissioned), stays healthy (e.g., auditing to identify faulty
>> elements), and is maintained to meet strict performance objectives.
>> [/Authors]
>> 
>>> s1, para 4: s/to retrieve network element/to retrieve information
>>> relating to network element/
>>> 
>> 
>> [Authors] Ok, we will update as proposed
>> 
>>> s1, para 4: s/are key enablers/provides key enablers/
>>> 
>> 
>> [Authors] Ok, we will update as proposed
>> 
>>> s1, para 4: s/a gap about/a gap relating to/
>>> 
>> 
>> [Authors] Ok, we will update as proposed
>> 
>>> s1, para 5:  Please delete this paragraph.  This is a standards
>>> document and not a poltical positioning paper.
>>> 
>> 
>> [Authors] Ok, we will remove as proposed
>> 
>>> s1, para 8:  This paragraph does not read well.  Suggest:
>>> OLD:
>>> As outlined in Section 6, the network inventory provides a read-only
>>> perspective of the actual inventory data that a network controller
>>> knows of what it is actually installed within the network. NEW: As
>>> outlined in Section 6, the network inventory provides a read-only
>>> perspective of the actual inventory data of which a network controller
>>> is aware covering the components that are actually installed and
>>> active within the network. END
>> 
>> [Authors]
>> 
>> Based on previous discussion, instead of the term "active" we have decided to
>> say "intended to be running"
>> 
>> See also this mail thread:
>> https://mailarchive.ietf.org/arch/msg/ivy/WFd4SE5E6PQDdapUkuMHbHHeXh
>> 8/
>> 
>> Therefore, we would update the text as you proposed but with
>> c/active/intended to be running/
>> 
>> Note: it seems the terminology is not yet fully consistent in the document. The
>> YANG module still uses "configured to be active" and the Security
>> Considerations still uses the term "active". We would align these terms as well
>> for consistency.
>> 
>> [/Authors]
>> 
>>> The term 'spare'
>>> in the second sentence of this paragraph may be misleading. Networks
>>> may contain backup components which are there as spares that can be
>>> switched in automatically in the event of the primary component
>>> failing. I would expect the inventory to account for these. This is
>>> clearly different from having offline spares that might require human
>>> intervention to insert them into the active inventory.
>>> 
>> 
>> [Authors] We would align this text with the terminology used in section 6:
>> c/spare or inactive assets/inactive assets or warehouse spares/
>> 
>>> s2, definition of Hardware Component:  s/The generalisation of/A
>>> portmanteau [or alternatively 'An umbrella'] term for any of/  It
>>> might be worth referencing RFC 8348 here which sets out terms for adding
>> items to the lists.
>>> 
>> 
>> [Authors]
>> 
>> We would rephrase as:
>> 
>> "A general definition of category of components as defined in [RFC8348] and
>> [IANA_HW_YANG] (e.g., backplane, battery, container, central processing unit
>> (CPU), chassis, fan, module, port, power supply, sensor, stack, and storage
>> device components)."
>> 
>> [/Authors]
>> 
>>> s2, definition of Component:
>>> OLD:
>>> Component: The generalization of the hardware component definition to
>>> include other inventory objects which can be managed, from an
>>> inventory perspective, like hardware components. NEW: Component: A
>>> furher extension of the portmanteau hardware component definition to
>>> include other inventory objects which can be managed, from an
>>> inventory perspective, in the same way as hardware components.
>>> END
>>> 
>> 
>> [Authors]
>> 
>> We would rephrase as:
>> 
>> "A further extension of the hardware component definition to include other
>> inventory objects which can be managed, from an inventory perspective, in the
>> same way as hardware components."
>> 
>> [/Authors]
>> 
>>> s3.1 and s3.1.1: The use of 'such as' in the first paragraphs of these
>>> sections implies that there are other common attributes. etc.  I
>>> suspect that the lists givn are complete and different phraseology should be
>> used:
>>> 
>>> In s3,1;
>>> OLD:
>>> For all the inventory objects, there are some common attributes, such as:
>>> NEW:
>>> All inventory objects have the following common attributes:
>>> END
>>> 
>> 
>> [Authors]
>> 
>> We agree that "such as" can be misleading since the list contains all the
>> attributes currently defined in the grouping basic-common-entity-attributes.
>> 
>> However, we would prefer to rephrase this text to be also future proof and
>> remain valid even if a new attribute is added in the future.
>> 
>> We would rephrase as: "For all the inventory objects, there are some common
>> attributes, including:"
>> 
>> [/Authors]
>> 
>>> In s3.1.1:
>>> OLD:
>>> To be consistent with the component definition, some of the attributes
>>> defined in [RFC8348] for components are reused for network elements, such
>> as: NEW:
>>> To be consistent with the component definition, the following
>>> attributes defined in [RFC8348] for components are reused for network
>>> elements: END
>>> 
>> 
>> [Authors] Ok, we will update as proposed (no need to a future proof sentence
>> since it refers to RFC8348)
>> 
>>> s3.1, definition of ne_id: 'assigned by the server' -  Which server would that
>> be?
>>> 
>> 
>> [Authors] It is the server exposing the YANG data model, as defined in RFC7950
>> 
>>> s3.3, para 1: s/same approach of/same approach as/
>>> 
>> 
>> [Authors] Ok, we will update as proposed
>> 
>>> s3.3, definitions of hardware_rev and mfg-date:  Should the
>>> specification offer a standard form for use in case these items are not known?
>>> 
>> 
>> [Authors] These attributes, likewise other attributes, are optional and can be
>> omitted if not known, as outlined in section 6.
>> 
>>> s3.3.1, para 1:s./classifies/classify/, s/and manage all/and manages
>>> all/
>>> 
>> 
>> [Authors] Ok, we will update as proposed
>> 
>>> s3.3.2, para 3: s/an Application software modules/an Application
>>> module [or Application software modules]/ Which is intended?
>>> 
>> 
>> [Authors]
>> 
>> Both changes should be fine. We would rephrase as:
>> 
>> "For example, one Operating System and one or more Application software
>> modules can be intended to be running in a network element, and, in the same
>> way, one boot-loader, one firmware and one or more FPGA software modules
>> can be intended to be running on a component like a circuit pack."
>> 
>> [/Authors]
>> 
>>> s3.3.2, para 3: Expand FPGA - it isn't defined currently.
>>> 
>> 
>> [Authors] Ok, we will update as proposed
>> 
>>> s3.3.2, para5: s/under definition/defined/ (By the time this draft is
>>> published, the model will have been defined)
>>> 
>> 
>> [Authors] Ok, we will update as proposed
>> 
>>> s3.3.2, para 6:  'have similar replaceable requrements':  Does this
>>> mean that the components have similar requirements or characteristics
>>> as to replaceability?  I don't understand what is meant here.
>>> 
>> 
>> [Authors]
>> 
>> Your understanding is correct.
>> 
>> We would rephrase as: c/have similar replaceable requirements/have similar
>> replaceability requirements/
>> 
>> [/Authors]
>> 
>>> s3.3.2, para 6: s/one or more software patch information/one or more
>>> records of software patches that have been applied./
>>> 
>> 
>> [Authors] Ok, we will update as proposed
>> 
>>> s3,3.2, last para: s/like/such as/
>>> 
>> 
>> [Authors] Ok, we will update as proposed
>> 
>>> s5, module description item:  Suggest adding reference to RFC 8342 for
>>> Datastore Architecture
>>> 
>> 
>> [Authors] The document is following the updated guidelines in RFC9907 which
>> now requires to highlight only when the module is not-NMDA compliant
>> 
>>> s6, para 7: s/ and outside the scope/and is outside the scope/
>>> 
>> 
>> [Authors] Ok, we will update as proposed
>> 
>>> s6, para 8: s/dooes not constraint/does not constrain/
>>> 
>> 
>> [Authors] Ok, we will update as proposed
>> 
>>> s6, para 10:  The term 'brownfield' is jargon that needs to be
>>> explained or replaced.
>>> 
>>>  I suggest somethings along the lines of:
>>> 
>>>       If the inventory system defined by this document is to be deployed
>>>      into a nework which has a  preexistng inventory system....
>>> 
>> 
>> [Authors] Ok, we will update as proposed
>> 
>>> s9,2:  Arguably RFC7951 and RFC 8340 are normative references.  If RFC
>>> 6241
>>> (NETCONF) is nomative then I would suggest RFC  8040 (RESTCONF) is
>>> normative as well... but they could also both  be considered informative.
>>> 
>> 
>> [Authors]
>> 
>> We think that RFC7951 should remain informative since the draft does not
>> dictate any encoding but it is just using RFC7951 encoding in the JSON
>> examples. This approach is aligned with other RFCs defining YANG data models
>> with JSON examples.
>> 
>> We think that RFC8340 can remain informative to align with other RFCs
>> defining YANG data models with JSON examples.
>> 
>> According to section 3.7.1 of RFC9907, within the Security Consideration
>> section, RFC6241 and RFC8040 are by default referenced as informative unless
>> normatively cited in other sections.
>> 
>> In this draft, RFC6241 is also normatively referenced in section 2.2 and
>> therefore the reference to RFC6241 should remain Normative.
>> 
>> In this draft, RFC8040 in also informatively referenced in Appendix C, and
>> therefore the reference to RFC8040 should remain informative.
>> 
>> [/Authors]
>> 
>>> Appendix A:  The firstt two and last paragraphs and table of this
>>> section section is written in academic paper style  with 'we' do things and
>> 'our'
>>> rather than impersonal standards form  and need to be rewritten.
>>> There are also two missing deifinte articles in the first sentence of the second
>> paragraph.
>>> before Openconfig and "ietf-hardware".and another one missing in each
>>> of the third and fourth paragraphs.
>>> 
>> 
>> [Authors] Ok, we will update the appendix as suggested
>> 
>>> Appendices B and C; Also have the academic paper style issue.
>>> 
>> 
>> [Authors] Ok, we will update the appendices as suggested
>> 
>>> Appendix C, para 3: s/large scale of networks/large scale networks/
>>> 
>> 
>> [Authors] Ok, we will update as proposed
>> 
>>> Appendix C, para 4: s/ so to cover/so as to cover/, s/in YANG model/in
>>> the YANG model/, s/it is only needed/it is only necessary/
>>> 
>> 
>> [Authors] Ok, we will update as proposed
>> 
>>> Appendix D, para 2: s/three type of ports/three types of port/
>>> 
>> 
>> [Authors] Ok, we will update as proposed
>> 
>>> Appendix E:, para 2: ss/composed by/comprised of/
>>> 
>> 
>> [Authors] Ok, we will update as proposed
>> 
>>> Appendix E para 3 and para 8: :s/Stacked switch/Stacked switches/
>>> 
>> 
>> [Authors] Ok, we will update as proposed
>> 
>>> Appendix E, para 6: s/synchronzed/require synchronized/
>>> 
>> 
>> [Authors] Ok, we will update as proposed
>> 
>>> Appendix E, titles of Figures 5 and 6: s/a stacked switch/stacked
>>> switches/
>>> 
>> 
>> [Authors] Ok, we will update as proposed. For consistency, we will update also
>> the title of Figure 7.
>> 
>>> Appendix E, para 9:
>>> OLD:
>>> Using the base network inventory YANG data model each interconnected
>>> switch can be modelled as a chassis within the same network element,
>>> which models the cascaded switch. The ports used to interconnect the
>>> different chassis are normal (traffic) ports and modelled like other
>>> ports. NEW: Using the base network inventory, the YANG data model for
>>> each interconnected switch can be set up as a chassis within the same
>>> network element, which models the cascaded switch. The ports used to
>>> interconnect the different chassis are normal
>>> (traffic) ports and modelled in the same way as other ports. END
>>> 
>> 
>> [Authors] We would rephrase as:
>> 
>> Using the base network inventory YANG data model, each interconnected
>> switch is modelled as a chassis component of the same network element. The
>> ports used to interconnect these switches are normal (traffic) ports and
>> modelled like other ports.
>> 
>> [/Authors]
>> 
>>> Appendix E: [Aside: Yes, that's quite a lot of YANG!! ]
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Ivy mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>> _______________________________________________
>> Ivy mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]


Mahesh Jethanandani
[e-mail]