Thanks, Thomas. This helps (at least me). I’m not thrilled with the lack of the specific device metadata, but I agree this is a problem that is being worked.
I think this revision would satisfy my shepherd review and procedural review. Joe From: thomas.g...@swisscom.com <thomas.g...@swisscom.com> Date: Wednesday, July 2, 2025 at 06:42 To: Joe Clarke (jclarke) <jcla...@cisco.com>, draft-ietf-opsawg-collected-data-manif...@ietf.org <draft-ietf-opsawg-collected-data-manif...@ietf.org> Cc: opsawg@ietf.org <opsawg@ietf.org> Subject: RE: Shepherd review of draft-ietf-opsawg-collected-data-manifest Dear Joe, I haven't gone through all the points yet with the authors but the following point catches my eyes: JC> With respect to the platform-id, its description states, “The 'id' has to be unique within the network scope at every point in time. The same id can point to different platform if they are not simultaneously part of the network, e.g., when a device associated to a particular id is replaced.” While this reflects common operational practices (e.g., re-using hostnames), it introduces challenges for long-term data analytics. If the same ID can refer to different physical devices over time, historical data for that ID becomes ambiguous regarding the underlying hardware. Data scientists might want to track the performance or behavior of a specific physical device over its entire lifecycle, not just its role at a given time. I am co-authoring draft-ietf-opsawg-collected-data-manifest and draft-boucadair-nmop-rfc3535-20years-later. What you are raising is a very valid point and has been for the very reason you described as a holistic requirement for Network Telemetry protocols in https://datatracker.ietf.org/doc/html/draft-boucadair-nmop-rfc3535-20years-later-08#section-4.10. It is not something which can be resolved within the two documents JC> To address both the normative/non-normative and the ID issues, it might be good to add an initial paragraph to Section 7.3 to summarize and address these points. That makes perfectly sense. Here I asking myself on top of that description wherever an informative reference to https://datatracker.ietf.org/doc/html/draft-boucadair-nmop-rfc3535-20years-later-08#section-4.10, the problem statement, would make sense or not? Here a proposal on operational considerations section: https://htmlpreview.github.io/?https://raw.githubusercontent.com/JeanQuilbeufHuawei/draft-collected-data-manifest/refs/heads/comments_08/docs/latest-diff.html Would that address above points? Best wishes Thomas From: Joe Clarke (jclarke) <jcla...@cisco.com> Sent: Sunday, June 29, 2025 10:07 AM To: draft-ietf-opsawg-collected-data-manif...@ietf.org Cc: opsawg@ietf.org Subject: Shepherd review of draft-ietf-opsawg-collected-data-manifest Be aware: This is an external email. In preparing for IESG publication, I am reviewing rev -08 of this draft as its document shepherd. Overall, the document is well-structured, and the examples in the appendices are excellent for helping one understand the use and implementation of the work. I do find some issues, some of which might need more discussion. First, the notion of normative vs. non-normative in the document may result in operational difficulty. Because one of the modules is normative (the platform manifest), and the other is non-normative (the data collection manifest) due to schema mount, it may be confusing as to what is being standardized as the “data manifest” (especially given the title of the document). Is the entire concept of the data manifest only partially normative? Moreover, relying on a mechanism (YANG Schema Mount) that doesn't fully support "design-time schema mount" for a core component of the "data manifest" creates an implementation challenge. Implementers cannot simply load and validate the full schema of the data collection manifest from a single YANG module. They would need to manually understand and combine the various mounted modules, which could lead to inconsistencies across implementations. Concretely, your example in Section 6.2 uses pseudo-normative language in the description of the yangmnt:mount-point leaf, but this wouldn’t be machine-consumable for easy design time validation. I know you’ve tried other things with respect to solving the normative nature of this, so rather than try to make this normative, I think you need to be more explicit as to the implications for interoperability and implementation. With respect to the platform-id, its description states, “The 'id' has to be unique within the network scope at every point in time. The same id can point to different platform if they are not simultaneously part of the network, e.g., when a device associated to a particular id is replaced.” While this reflects common operational practices (e.g., re-using hostnames), it introduces challenges for long-term data analytics. If the same ID can refer to different physical devices over time, historical data for that ID becomes ambiguous regarding the underlying hardware. Data scientists might want to track the performance or behavior of a specific physical device over its entire lifecycle, not just its role at a given time. Perhaps it would be good to explicitly highlight this as an operational consideration for data consumers and analysts. You might also consider adding a persistent identifier (e.g., a UUID) that wouldn’t be the key, but at least one way to uniquely identify an underlying device. To address both the normative/non-normative and the ID issues, it might be good to add an initial paragraph to Section 7.3 to summarize and address these points. I also found some nits in the document: Section 2: “a telemetry information” is odd. Maybe, “telemetry information”? Section 3.3: you have a few instances of “fancy” quotes. Make sure these are ASCII straight quotes. Joe
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
