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]> > Sent: giovedì 11 giugno 2026 01:20 > To: [email protected] > Cc: [email protected]; [email protected]; last- > [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/WFd4SE5E6PQDdapUkuMHbHHeXh8/ 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] > To unsubscribe send an email to [email protected] _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
