29 clarifications on generation of data collection manifest

[JeanQuilbeufHuawei]

Tried to clarify the role of the data manifest and who generates it, see https://github.com/JeanQuilbeufHuawei/draft-collected-data-manifest/commit/08fca2515b83c8b09686d80d1f0e677a0d7417c8#diff-dd2927df57facdf2e03a3f7b78c34014e4d753e5b0e799c5e5280305746eea50L157 for the relevant diff in the intro.

[JeanQuilbeufHuawei]

Yes, the goal of the data manifest is to provide a normalized way of representing the information for interpreting a time series after the collection is over. Quoting the draft:

The goal of the current document is to define what needs to be kept as metadata (the data manifest) to ensure that the collected data can still be interpreted correctly. The proposed YANG modules in the data manifest do not expose many new information but rather define what should be exposed by a device streaming telemetry. It is expected that the data manifest is streamed directly from the the network equipment, along with the telemetry feature. If a device streaming telemetry does not support yet the YANG modules from the data manifest specified in this document, the collector could populate the data manifest from available information from the device. However this option requires efforts on the collector side, as the information gathered in the data manifest proposed in this document could be scattered among various standard and vendor- specific YANG modules [RFC8199], that depend on the device.

Let me know what part should be fixed to clarify the role of the proposed YANG modules. (Note that includes much more than telemetry statistics as they contain the platform-manifest as well.) I don’t think that a IETF module corresponding to the platform-manifest exist at the moment.

Now, regarding the data-manifest, we plan to cover all MDT systems, not only YANG-push. Notably Cisco, Huawei and Juniper have a system of subscription based on YANG paths (which is aligned with the data-manifest). There is also GNMI, which is an abstraction of these YANG-path based subscriptions. As you suggested, we need to support at least both YANG-push and YANG path based subscription. I believe that discussion on how to achieve this should be done in #9 as it already started.

Note that openconfig is mostly a repository of standard YANG modules. The protocol for streaming telemetry would be GNMI.

[idomingu]

Thanks for this clarification Jean. I'm afraid I'm not familiar with the different implementations of MDT subscription made by vendors such as Huawei or Cisco. In this sense, given such a variety of implementations, the data collection manifest makes total sense for normalizing the context information related to MDT subscriptions.

Perhaps this point should be reflected somewhere in the document. Thus far, the draft only mentions YANG-Push at the beginning in the introduction.

When streaming YANG-structured data with YANG-Push [RFC8641], there is a semantic definition in the corresponding YANG module definition. On top of that definition, it is also important to maintain contextual information about the collection environment.

Instead of just citing YANG-Push, we could provide multiple examples, i.e., YANG Push, openconfig-telemetry, vendor implementations, etc. Please, note that by Openconfig I was referring to openconfig-telemetry.

This said, I think we can finally merge this PR :) As you noted, let's follow-up the YANG-Push conversation in #9.