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.
## 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.
## 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.
## 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.).
## 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.
# 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.
Cheers,
Med
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
