Hi Working Group, I quite agree with the idea of Italo, and would like to support adopting option1 draft-ietf-ccamp-network-inventory-yang-02 and evolve it to be the base model.
The requirements for hardware management are more clear and common, and has been discussed with more experts from different technologies for a long time. Therefore, the hardware inventory management draft is more mature and has a better condition to release in a short time. We also have discussed to introduce software inventory management into our data model in the last two weekly calls, but it seems that there are still a lot of debate. Personally, I think it is hard to get aligned in a short time. I don’t deny the necessary of software inventory management. What I concern is, do we need to combine software inventory management and hardware inventory management modeling in one draft? I don’t think it is a good standardization practice to define a big and comprehensive data model. Just like when we are doing coding works, we don’t like to write all the codes in one file. It is hard to read and maintenance. If some of the requirements have not been fully discussed, this big and comprehensive data model would be revised repeatedly. A big and comprehensive data model also takes more time to discuss. If this base model cannot be published in a short time, developers will lost interest to adopt it. A modular approach can also help for the developers to recognize which part of parameters they need to focus, since we have already noted some operators only required to manage hardware inventory in some technologies. And I also suggest that the base model can have a broader meaning. We can have two base models, one for hardware inventory and the other one for software inventory management. But software cannot be existing independently without hardware, so the software inventory management model should not have a separated root. It should augment to hardware inventory model in a proper approach. For the hardware inventory draft, probably we also need to reserve some placeholders for further extensions, including but not limit to software management. B.R. Chaode 发件人: Inventory-yang [mailto:[email protected]] 代表 Italo Busi 发送时间: 2023年9月14日 5:48 收件人: maqiufang (A) <[email protected]>; [email protected] 抄送: [email protected]; opsawg <[email protected]>; [email protected] 主题: Re: [Inventory-yang] [inventory-yang] poll for network inventory base model My preference is option 1 to adopt draft-ietf-ccamp-network-inventory-yang-02 in IVY and evolve it to become the network inventory base model I understand this draft does not cover all the items in the WG charter but IMHO there is no need to cover all the IVY WG charter items into a single draft nor into a single YANG model. Experience usually shows that modular and incremental (step-by-step) approaches work better with complex scenarios as those we are trying to address in the IVY WG In this case, considering only HW and SW inventory requirements, I have noted that two different set of UCs have been discussed: - UCs where only HW inventory is required; - UCs where both HW and SW inventory is required A modular approach defining a base model that covers the common requirements (i.e., HW inventory) and one or more augmentation models that covers optional additional requirements (e.g., SW inventory) would better address these different set of UCs Moreover, requirements and solutions for HW inventory are more mature (based on existing standards, like RFC8348 and TMF, and proven by many years of real network deployments) than emerging requirements and solutions for virtualization, SW and licenses inventory The proposed model split would allow both HW and SW inventory to progress in parallel and to reach RFC publication as quickly as possible IMHO, evolving draft-ietf-ccamp-network-inventory-yang-02 to become the network inventory base model would imply also providing the required technical changes to support other model augmentations that cover additional requirements (e.g., SW inventory). The technical details for these changes can be discussed in the interim WG meeting or even offline before/after the interim meeting Italo From: Inventory-yang <[email protected]<mailto:[email protected]>> On Behalf Of maqiufang (A) Sent: lunedì 28 agosto 2023 08:22 To: [email protected]<mailto:[email protected]> Cc: [email protected]<mailto:[email protected]>; opsawg <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: [Inventory-yang] [inventory-yang] poll for network inventory base model Hi Working Group, It’s now time to start considering how to move forward with the inventory base model. We have two different documents that could be used as a starting point for our work or, in case the working group believes none of them is “good enough”, we can start a brand new ID. In case the latter option is chosen, Daniele and I will write a -00 version including just the table of content and what we’d like to be covered in each section. The document will then be handed over to a pool of authors which will bring it till the WG adoption. Hence, we will have a 3 weeks polling starting today. We decided to make it a bit longer than usual because this time the working group is requested to review two drafts instead of one. This mail starts a 3 weeks polling, terminating on September 15th, where we would like the working group to express your preference among: 1. Adopt draft-ietf-ccamp-network-inventory-yang-02 in IVY and evolve it to become the network inventory base model 2. Adopt draft-wzwb-opsawg-network-inventory-management-03 in IVY and evolve it to become the network inventory base model 3. Start a brand new document from scratch as described above In the week after the closure of the polling (between September 18 and 25) we will have an IVY interim meeting to discuss the issues/concerns raised during the polling ( A separate mail will be sent). Thank you, Qiufang and Daniele
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
