Hi Med, Many thanks for you comments, really appreciate it. I agree about getting the discussion with the WG about facilitating the use of the module (i.e. aligning with the YANG catalog to retrieve models a posteriori) vs facilitating the implementation of the module (and aligning with one or more existing specs to get the details of the platform). Any feedback from the list?
Here is a diff of the changes on our working version (not published yet). https://htmlpreview.github.io/?https://raw.githubusercontent.com/JeanQuilbeufHuawei/draft-collected-data-manifest/refs/heads/med_comments_06/docs/latest-diff.html Best, Jean > -----Original Message----- > From: mohamed.boucad...@orange.com <mohamed.boucad...@orange.com> > Sent: Thursday, March 6, 2025 2:16 PM > To: Jean Quilbeuf <jean.quilbeuf=40huawei....@dmarc.ietf.org>; ops- > d...@ietf.org > Cc: draft-ietf-opsawg-collected-data-manifest....@ietf.org; > last-c...@ietf.org; > opsawg@ietf.org > Subject: RE: Opsdir last call review of > draft-ietf-opsawg-collected-data-manifest- > 05 > > Hi Jean, > > Thank you for the follow-up. > > The changes made so far are clear enhancements to the spec. > > I think most of my comments were addressed. The main remaining point is this > one: > > # Avoid misalignment with existing models to report system characteristics & > ease integration. > > I noted your reply about being aligned with the YANG catalog. Not sure how > that > can be better for real deployments. I noted your point about usability of the > module vs. ease of implementation, but I'm afraid this is worth being checked > with the WG. I checked OPSAWG archives if this point was discussed, but I > failed > to find anything useful. > > FWIW, here is a full review of the new version: > > * pdf: https://github.com/boucadair/IETF-Drafts- > Reviews/blob/master/2025/draft-ietf-opsawg-collected-data-manifest-06- > rev%20Med.pdf > * doc: https://github.com/boucadair/IETF-Drafts- > Reviews/raw/refs/heads/master/2025/draft-ietf-opsawg-collected-data- > manifest-06-rev%20Med.doc > > Hope this helps. > > Cheers, > Med > > > -----Message d'origine----- > > De : Jean Quilbeuf <jean.quilbeuf=40huawei....@dmarc.ietf.org> > > Envoyé : lundi 3 mars 2025 15:55 > > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; > ops- > > d...@ietf.org Cc : > > draft-ietf-opsawg-collected-data-manifest....@ietf.org; last- > > c...@ietf.org; opsawg@ietf.org Objet : RE: Opsdir last call review of > > draft-ietf-opsawg-collected- > > data-manifest-05 > > > > > > Hi Med, > > Thank you very much for your detailed comments, they should have been > > addressed. > > > > The diff is here: > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth > > or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-opsawg-collected-data- > > manifest- > > > 06&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C7e7e030ba89 > 041652cf > > > a08dd5a6364e2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63 > 876610514 > > > 1195027%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi > IwLjAuMD > > > AwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C% > 7C&sd > > ata=LE0rw3AdSpl6GmrZxu5ow5NWRyJzfstoGNpvmeMnsLU%3D&reserved=0 > > > > I provide some answers to your comments inline. > > > > Best, > > Jean > > > > > -----Original Message----- > > > From: Mohamed Boucadair via Datatracker <nore...@ietf.org> > > > Sent: Wednesday, January 8, 2025 10:43 AM > > > To: ops-...@ietf.org > > > Cc: draft-ietf-opsawg-collected-data-manifest....@ietf.org; > > > last-c...@ietf.org; opsawg@ietf.org > > > Subject: Opsdir last call review of > > > draft-ietf-opsawg-collected-data-manifest-05 > > > > > > Reviewer: Mohamed Boucadair > > > Review result: Has Issues > > > > > > Thank you for the effort put into this document. > > > > > > This specification proposes an approach to supply (and store) > > required > > > context information to help interpreting telemetry data. It does so > > by > > > leveraging existing tools (e.g., yang mount). This is useful > > > especially when such context information cannot be easily grabbed > > from > > > the collected data or when not enriched locally by collecting > > systems. > > > With that in mind, the proposed approach is sound and reasonable. > > > > > > There are, however, some OPS/YANG issues that need to be further > > > discussed > > > > > > # Avoid misalignment with existing models to report system > > > characteristics & ease integration > > > > > > ## I was expecting that the main manifest information to be a > > > mix/subset of hw/system information, mainly from RFC7317 and > > RFC8348. > > > > > > RFC7317 > > > > > > +--ro platform > > > > > > +--ro os-name? string > > > > > > +--ro os-release? string > > > > > > +--ro os-version? string > > > > > > +--ro machine? String > > > > > > RFC8348 > > > > > > +--ro hardware-rev? string > > > > > > +--ro firmware-rev? string > > > > > > +--ro software-rev? string > > > > > > You may explain why reusing these modules or parts of these modules > > is > > > not an option? > > > > > > Grabbing data nodes from system/hw models has the merit to ease > > > capturing required context info. > > > > > > ## Similarly, relationship with > > > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata > > > tracker.ietf.org%2Fdoc%2Fdraft-ietf-ivy-network-inventory- > > yang%2F&data > > > > > > =05%7C02%7Cmohamed.boucadair%40orange.com%7C7e7e030ba89041652 > cfa08dd5a > > > 6364e2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638766105 > 141213751 > > > %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuM > DAwMCIsI > > > lAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdat > a=Pfs > > vibrFnfEvf8%2FG081WADSki3WUOX%2Bl%2FoZPHF8XfO8%3D&reserved=0 > should be > > better discussed (other than the discussion about the node-id (at > > least reuse of the same data nodes naming): > > > > > > +--rw network-element* [ne-id] > > > ................................... > > > +--rw hardware-rev? string > > > +--rw software-rev? string > > > +--rw mfg-name? string > > > +--rw mfg-date? yang:date-and-time > > > +--rw part-number? string > > > +--rw serial-number? string > > > +--rw product-name? string > > > > > > ## Are there cases where metering and reporting are executed by > > > distinct components of a network elements? If so, the > > characterization > > > of the source that produced data (e.g., a service card) should be > > > supplied, not only system- wide information. > > > > I understand the goal of facilitating the implementation of the module. > > However the rationale is to be aligned with the YANG catalog, as > > stated in the draft, to retrieve modules from there after the device > > is gone. We put the balance more towards usability of the module > > rather than ease of implementation. > > > > > ## Section 5.1 includes the following: > > > > > > In case of Data Manifest change, the > > > system should keep the mapping between the data collected so far > > and > > > the old Data Manifest, and not assume that the latest Data > > Manifest > > > is valid for the entire time series. > > > > > > This is an important aspect IMO that needs further elaboration about > > > how this will be implemented. > > > > Section 7 (previously 5) has been updated to make this link more > > explicit. > > > > > ## The document includes a fair discussion on collecting manifest > > > data, but no discussion about when it is safe to flush out such > > > information. I wonder whether some discussion can be added to > > optimize > > > required data storage (when there is no record that bind to a given > > > manifest version, decommissioning of a network element, etc.). > > > > > > # YANG > > > > > > ## Mount can't be used at design time. RFC 8528 has the following: > > > > > > "Design-time mounts are outside the > > > scope of this document and could be possibly dealt with in a > > future > > > revision of the YANG data modeling language." > > > > > > I don't think we can define the two modules with mount use as > > > "ietf-..". I think these should be defined as examples. Idem for the > > > companion xml files (which will be stale as they include also > > specific module revision dates, etc.). > > > > > > ## However, in order to ensure the key information is used, I > > suggest > > > that the core manifest/collection part be defined as separate > > > groupings in the same/separate IETF modules. These modules can then > > be > > > imported in your mount examples to illustrate the use. > > > > Added a grouping in the platform-manifest and dropped support for > > semver, which removes the need for schema mount. > > For the data collection, I renamed it to example. > > > > > ## The description of a platform may change over time. The "id" is > > not > > > sufficient in its own to map to a specific manifest (same platform). > > > It is not clear how versions are tracked over time (upon change, > > etc.). > > > > Clarified in Section 7, the timestamp allows to find the manifest (and > > mentioned in the introduction) > > > > > ## Unlike the other modules, ietf-data-collection-manifest- > > statistics > > > was not introduced early in the document. > > > ## ietf-data-collection-manifest-statistics is actually a generic > > > augmentation that can be used in other contexts than the manifest. I > > > suggest that you use a more generic name for it + update the IANA > > > considerations to register it + follow the security template in > > 8407bis. > > > > > > > Justification for new module in intro and new section dedicated to it. > > > > > # Detailed review > > > > > > 45 comments, proposed edits, nits, broken example, etc. can be found > > at: > > > > > > * pdf: > > > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > > > ub.com%2Fboucadair%2FIETF-Drafts- > > Reviews%2Fblob%2Fmaster%2F2025%2Fdraf > > > t- > > > &data=05%7C02%7Cmohamed.boucadair%40orange.com%7C7e7e030ba8904 > 1652cf > > > > > > a08dd5a6364e2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63 > 876610514 > > > > > > 1222899%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOi > IwLjAuMD > > > > > > AwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C% > 7C&sd > > > > ata=CqduH%2Faq7zScL9EaxF9WoQ6ggHqKCrFSG1L%2B%2BHoj4fo%3D&reser > ved=0 > > > ietf-opsawg-collected-data-manifest-05-rev%20Med.pdf > > > > > > * doc: > > > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > > > ub.com%2Fboucadair%2FIETF-Drafts- > > &data=05%7C02%7Cmohamed.boucadair%40o > > > > > > range.com%7C7e7e030ba89041652cfa08dd5a6364e2%7C90c7a20af34b40bf > bc48b92 > > > > > > 53b6f5d20%7C0%7C0%7C638766105141232917%7CUnknown%7CTWFpbGZ > sb3d8eyJFbXB > > > > > > 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpb > CIsI > > > > > > ldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CVV8MmLI4Fv4cDDahu%2By0W > 1ohWuvtDiAO > > > x%2F%2BpqCB11g%3D&reserved=0 > > > Reviews/raw/refs/heads/master/2025/draft-ietf-opsawg-collected-data- > > > manifest-05-rev%20Med.doc > > > > > > Hope this helps. > > > > Much appreciated, thanks. > > > > > > > > Cheers, > > > Med > > > > > _____________________________________________________________ > _______________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou > copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le > signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages > electroniques etant susceptibles d'alteration, Orange decline toute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, used > or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this > message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
