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.com@xxxxxxxxxxxxxx> > Envoyé : lundi 3 mars 2025 15:55 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx>; ops- > dir@xxxxxxxx > Cc : draft-ietf-opsawg-collected-data-manifest.all@xxxxxxxx; last- > call@xxxxxxxx; opsawg@xxxxxxxx > 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%7C7e7e030ba89041652cf > a08dd5a6364e2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63876610514 > 1195027%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMD > 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 <noreply@xxxxxxxx> > > Sent: Wednesday, January 8, 2025 10:43 AM > > To: ops-dir@xxxxxxxx > > Cc: draft-ietf-opsawg-collected-data-manifest.all@xxxxxxxx; > > last-call@xxxxxxxx; opsawg@xxxxxxxx > > 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%7C7e7e030ba89041652cfa08dd5a > 6364e2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638766105141213751 > %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsI > lAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=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%7C7e7e030ba89041652cf > > > a08dd5a6364e2%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63876610514 > > > 1222899%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMD > > > AwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sd > > ata=CqduH%2Faq7zScL9EaxF9WoQ6ggHqKCrFSG1L%2B%2BHoj4fo%3D&reserved=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%7C90c7a20af34b40bfbc48b92 > > > 53b6f5d20%7C0%7C0%7C638766105141232917%7CUnknown%7CTWFpbGZsb3d8eyJFbXB > > > 0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsI > > > ldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CVV8MmLI4Fv4cDDahu%2By0W1ohWuvtDiAO > > 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. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
