Hi Tianran,
On 2/9/2022 2:04 PM, Tianran Zhou wrote:
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.
I'm not sure whether this is a generic question or whether your question
relates to the message below.
Let me answer the generic question. We don't always want to read the
devices information from the closed-loop automation systems or the
database. Once known ...
"This data manifest instance file MUST be streamed all with the data
and stored along with the collected data. In case the data are moved
to different place (typically a database), the data manifest MUST
follow the collected data. This can render the data unusable if that
context is lost, for instance when the data is stored without the
relevent information."
Also the context might be lost, so not available any longer from the
device Ex: how was it metered?
This is what we were trying to say with this generic sentence in the
charter: "This can render the data unusable if that context is lost, for
instance when the data is stored without the relevent information."
There is some more justifications in the introduction (section 2).
Regards, Benoit
Best,
Tianran
------------------------------------------------------------------------
Sent from WeLink
*发件人： *Jean Quilbeuf<[email protected]>
*收件人： *opsawg<[email protected]>
*主题： *[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
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
