Hi Mahesh, Thanks for your careful review: I have just submitted a -20 version of the I-D fixing the minor comments and nits
See in line Italo From: Mahesh Jethanandani <[email protected]> Sent: venerdì 18 settembre 2026 21:05 To: Italo Busi <[email protected]> Cc: Italo Busi <[email protected]>; Elwyn Davies <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [Ivy] draft-ietf-ivy-network-inventory-yang-18 ietf last call Genart review 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. [Italo Busi] Added text in -20 copied from previous Authors' reply ---------------------------------------------------------------------- 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) [Italo Busi] Fixed in -20 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.) [Italo Busi] Fixed in -20 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.) [Italo Busi] Fixed in -20, with an additional improvement: c/Within this document , term "container" represents an hardware/Within this document, the term "container" represents a hardware component/ Appendix C, Efficiency Issue: 2150 The main scope of this documento is to define the generic data model, s/documento/document/ [Italo Busi] Fixed in -20 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.” [Italo Busi] Fixed in -20 Thanks. On Sep 17, 2026, at 5:48 AM, Italo Busi <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> Sent: giovedì 16 luglio 2026 12:18 To: Elwyn Davies <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; last- [email protected]<mailto:[email protected]> 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 <[email protected]<mailto:[email protected]>> Sent: giovedì 11 giugno 2026 01:20 To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; last- [email protected]<mailto:[email protected]> 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 -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> _______________________________________________ Ivy mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> Mahesh Jethanandani [email protected]<mailto:[email protected]>
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
