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 -- [email protected] To unsubscribe send an email to [email protected]
