Hi Alex, Thank you very much for your comments. I provided some answers inline.
The diff is here: https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-collected-data-manifest-05&url2=draft-ietf-opsawg-collected-data-manifest-06&difftype=--html<https://author-tools.ietf.org/iddiff?url1=draft-ietf-opsawg-collected-data-manifest-05&url2=draft-ietf-opsawg-collected-data-manifest-06&difftype=--html> Best, Jean From: Alex Huang Feng <alex.huang-f...@insa-lyon.fr> Sent: Sunday, January 5, 2025 5:38 PM To: draft-ietf-opsawg-collected-data-manif...@ietf.org Cc: opsawg@ietf.org; Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org> Subject: [OPSAWG]Re: WG LAST CALL: A Data Manifest for Contextualized Telemetry Data Dear authors and OPSAWG, I have a some comments on the ietf-platform-manifest YANG module. I would suggest to implement the following fields as a grouping within the YANG module so that YANG developers could use these fields without the need to implement the whole module. The idea is only moving these field to a “platform-grouping” and use this grouping in the list “platform". +--mp platform* [id] +--ro id string +--ro name? string +--ro vendor? string +--ro vendor-pen? uint32 +--ro software-version? string +--ro software-flavor? string +--ro os-version? string +--ro os-type? string I think this set of fields are very useful in plenty of cases and some of them might not want to include the full YANG-library. Done Major comments: - On the ietf-data-collection-manifest YANG module, wouldn’t we need a node-id somewhere? How can we distinguish the different subscriptions from different nodes that use the same platform? Clarified definition of platform and that each platform must have a unique id. I guess platform id in our case is the same as node id in your case. I understand this YANG model as the set of platforms (along with the subscriptions) that a data collection is collecting from a network. However, in a network, multiple nodes with the same platform-id could be deployed, and within these nodes, each could have different subscriptions. Or am I getting this model wrong? Same as previous - I don’t fully understand the presence of XML file after the YANG modules, are they examples (Sec 3.2 and Sec 4.2)? If so, I would suggest to move them to the appendix and add a comment “An example of usage is in Appendix XXX”. If not, maybe add some text to explicit why this XMLs are in these sections. Removed for platform manifest, Moved file to appendix for data collection. Minor comments: - the YANG module copyright is outdated. - Editorial: I would move Sec 4.3 before 4.2. Seems strange to arrive to ietf-data-collection-manifest-statistics after getting a view on the YANG tree from ietf-data-collection-manifest. Thanks, fixed. Regards, Alex On 27 Nov 2024, at 15:39, Joe Clarke (jclarke) <jclarke=40cisco....@dmarc.ietf.org<mailto:jclarke=40cisco....@dmarc.ietf.org>> wrote: Hello, WG (and a Happy Thanksgiving to those of you in the US). With the IPR poll concluded (no IPR has been reported), we’d like to kick off a two week WG LC on draft-ietf-opsawg-collected-data-manifest<https://datatracker.ietf.org/doc/draft-ietf-opsawg-collected-data-manifest/>. Please review this draft and provide comments on-list. If you feel this draft is ready for publication, please respond as such on-list. We will kick off DIR reviews with OPS and YANG docs to get a couple more eyes on it. We are also in need of a shepherd for this document. If you are interested, please let the chairs know. The WG LC will conclude on December 11. Joe _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org<mailto:opsawg@ietf.org> To unsubscribe send an email to opsawg-le...@ietf.org<mailto:opsawg-le...@ietf.org>
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
