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. Major issues: 1. Potential problem: Size of complete YANG inventory specifications if needed to be interchanged between devices. 2. Possble problem: Ease or difficulty of integrating/de-integrating YANG inventory specifications for added or subtracted components. 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. 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 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. s1, para 3: s/well-planned/well-managed/ (One hopes that the planning precedes definition of the inventory; the inventory essentially documents the plan). s1, para 4: s/to retrieve network element/to retrieve information relating to network element/ s1, para 4: s/are key enablers/provides key enablers/ s1, para 4: s/a gap about/a gap relating to/ s1, para 5: Please delete this paragraph. This is a standards document and not a poltical positioning paper. 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 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. 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. 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 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 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 s3.1, definition of ne_id: 'assigned by the server' - Which server would that be? s3.3, para 1: s/same approach of/same approach as/ 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? s3.3.1, para 1:s./classifies/classify/, s/and manage all/and manages all/ s3.3.2, para 3: s/an Application software modules/an Application module [or Application software modules]/ Which is intended? s3.3.2, para 3: Expand FPGA - it isn't defined currently. s3.3.2, para5: s/under definition/defined/ (By the time this draft is published, the model will have been defined) 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. s3.3.2, para 6: s/one or more software patch information/one or more records of software patches that have been applied./ s3,3.2, last para: s/like/such as/ s5, module description item: Suggest adding reference to RFC 8342 for Datastore Architecture s6, para 7: s/ and outside the scope/and is outside the scope/ s6, para 8: s/dooes not constraint/does not constrain/ 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.... 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. 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. Appendices B and C; Also have the academic paper style issue. Appendix C, para 3: s/large scale of networks/large scale networks/ 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/ Appendix D, para 2: s/three type of ports/three types of port/ Appendix E:, para 2: ss/composed by/comprised of/ Appendix E para 3 and para 8: :s/Stacked switch/Stacked switches/ Appendix E, para 6: s/synchronzed/require synchronized/ Appendix E, titles of Figures 5 and 6: s/a stacked switch/stacked switches/ 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 Appendix E: [Aside: Yes, that's quite a lot of YANG!! ] _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
