Hi Tiaran, The value of this draft is not to expose new information via YANG but rather to define what needs to be kept as metadata (or data manifest) to ensure that the data can still be interpreted correctly even if the device is not present anymore, has been updated or has a new configuration.
The proposed model does not necessarily have to be implemented on the device, it could be generated by the collector by collecting in parallel all the information already present, although having it available directly on the device would simplify the collector operation. Best, Jean From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Tianran Zhou Sent: Wednesday 9 February 2022 13:04 To: Jean Quilbeuf <jean.quilbeuf=40huawei....@dmarc.ietf.org>; opsawg <opsawg@ietf.org> Subject: Re: [OPSAWG] Specifying protocols in draft-claise-opsawg-collected-data-manifest Hi Jean, I am a little confused about this manifest? Can we just read from the device about the configuration? We can get all the running information. Best, Tianran ________________________________ Sent from WeLink 发件人： Jean Quilbeuf<jean.quilbeuf=40huawei....@dmarc.ietf.org<mailto:jean.quilbeuf=40huawei....@dmarc.ietf.org>> 收件人： opsawg<opsawg@ietf.org<mailto:opsawg@ietf.org>> 主题： [OPSAWG] Specifying protocols in draft-claise-opsawg-collected-data-manifest 时间： 2022-02-09 20:33:06 Dear All, We are wondering whether to add information about protocols in the data manifest draft https://datatracker.ietf.org/doc/draft-claise-opsawg-collected-data-manifest/ Details are here https://github.com/JeanQuilbeufHuawei/draft-collected-data-manifest/issues/9 (that git repo contains a pre-01 version of the draft). The data manifest should contain the information that a device able to stream telemetry can gather to allow a posteriori understanding of values stored in a time series database for instance. In that context, knowing the protocol would enable to understand whether some metrics can be missed (for instance if UDP push is used) and explain some gaps in the time serie. 1 - In the model, do we want to encode that fact as a Boolean (such as unreliable_subscription) that would be attached to a particular MDT subscription or do we want to specify the protocol used for subscription and let the consumer of the model draw the conclusion themselves? 2 - Another point is about the encoding used, do we need to specify it in the data-manifest or do we leave this as a responsibility of the collector/database system? For the second question, not that he collector/database system still has the responsibility to modify the data manifest if that encoding is changed. Any suggestions? Best, Jean _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org<mailto:OPSAWG@ietf.org> https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
