Hello draft-claise-opsawg-collected-data-manifest coauthors, I just wanted to follow up on my comment at the microphone in London regarding draft-claise-opsawg-collected-data-manifest.
Clearly, there is a need to preserve context to be able to correctly interpret data after it has been collected. That being said, as currently stated, the draft appears to overspecify some of those things, defining some YANG data that IMHO is not actually needed as the same can already be accomplished. This concerns the specifics about the subscription itself. RFC 8641 includes a YANG model that reflects for each subscription how it is configured (whether configured directly or established by RPC), including the selection filter, the update trigger, the period and anchor time (in case of periodic subscription), dampening periods and excluded changes (in case of on-change subscription), etc. The corresponding YANG data can be itself be subscribed to, or retrieved on demand, just like any other kind of YANG data. I am therefore not quite sure what the proposed manifest would provide that couldn't be accomplished already. The suggestion to retain the subscription data along with the subscribed data makes a lot of sense but would appear to be a practice that will be up to the management application to implement, with the mechanism already provided. (This could of course be included as a description of a recommended practice in the draft.) Or is there something else that is missing? If there is indeed a delta that cannot be otherwise accomplished, my suggestion would be to add text to the draft that clearly describes the possibility of subscribing to subscription configuration data, then explaining the functional delta that your draft covers in addition to that. Thanks --- Alex
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
