Hi Med, Thank you very much for your detailed comments, they should have been addressed. The diff is here: https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-collected-data-manifest-06 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://datatracker.ietf.org/doc/draft-ietf-ivy-network-inventory-yang/ 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://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft- > ietf-opsawg-collected-data-manifest-05-rev%20Med.pdf > > * doc: > https://github.com/boucadair/IETF-Drafts- > Reviews/raw/refs/heads/master/2025/draft-ietf-opsawg-collected-data- > manifest-05-rev%20Med.doc > > Hope this helps. Much appreciated, thanks. > > Cheers, > Med > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
