Re: [OPSAWG] Specifying protocols in draft-claise-opsawg-collected-data-manifest

Benoit Claise <benoit.claise@huawei.com> Sat, 19 March 2022 15:23 UTC

Return-Path: <benoit.claise@huawei.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540953A0A2E for <opsawg@ietfa.amsl.com>; Sat, 19 Mar 2022 08:23:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjmghbxOHwZq for <opsawg@ietfa.amsl.com>; Sat, 19 Mar 2022 08:22:55 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DA243A079C for <opsawg@ietf.org>; Sat, 19 Mar 2022 08:22:55 -0700 (PDT)
Received: from fraeml736-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KLPhy1msFz67Hjq; Sat, 19 Mar 2022 23:20:50 +0800 (CST)
Received: from [10.126.173.159] (10.126.173.159) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Sat, 19 Mar 2022 16:22:49 +0100
Content-Type: multipart/alternative; boundary="------------eNJ9TF2F8ZC20akkjVVvYqa0"
Message-ID: <ac4ed536-ce61-2182-db1c-51ba5433e6c6@huawei.com>
Date: Sat, 19 Mar 2022 16:22:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
Content-Language: en-GB
To: mohamed.boucadair@orange.com, Jean Quilbeuf <jean.quilbeuf@huawei.com>, opsawg <opsawg@ietf.org>
References: <667b1aceabf94b04ba0af396426531a7@huawei.com> <b55c2572e84b48caa7dfcd6147bb6018@huawei.com> <259a4a8f-533d-cf35-b8a9-2cbf81e13eef@huawei.com> <22792_1644847941_620A6345_22792_44_1_787AE7BB302AE849A7480A190F8B933035493808@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Benoit Claise <benoit.claise@huawei.com>
In-Reply-To: <22792_1644847941_620A6345_22792_44_1_787AE7BB302AE849A7480A190F8B933035493808@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
X-Originating-IP: [10.126.173.159]
X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To fraeml736-chm.china.huawei.com (10.206.15.217)
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/PlOceNPjWM0ChE7m-MCchgP7idA>
Subject: Re: [OPSAWG] Specifying protocols in draft-claise-opsawg-collected-data-manifest
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Mar 2022 15:23:01 -0000

Hi Med,

Many thanks for your review.
All your feedback has been inserted.

For the data source PEN, we added the "vendor" object (in the github 
temp version). The YANG model is now aligned with the fields in the 
yangcatalog.org API 
(https://datatracker.ietf.org/doc/html/draft-clacla-netmod-model-catalog).

https://github.com/JeanQuilbeufHuawei/draft-collected-data-manifest

Regards, Benoit

On 2/14/2022 3:12 PM, mohamed.boucadair@orange.com wrote:
>
> Hi Benoît, Jean,
>
> FWIW, you may find some comments/suggestions at:
>
>   * pdf:
>     https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-claise-opsawg-collected-data-manifest-00-rev%20Med.pdf
>
>   * doc:
>     https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-claise-opsawg-collected-data-manifest-00-rev%20Med.doc
>     <https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-claise-opsawg-collected-data-manifest-00-rev%20Med.doc>
>
> Some of the context information is not specific to telemetry, but can 
> be applied in other contexts to assess the reliability of collected 
> data. Generalizing the concept would make sense.
>
> Cheers,
>
> Med
>
> *De :* OPSAWG <opsawg-bounces@ietf.org> *De la part de* Benoit Claise
> *Envoyé :* mercredi 9 février 2022 15:42
> *À :* Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org>; Jean 
> Quilbeuf <jean.quilbeuf=40huawei.com@dmarc.ietf.org>; opsawg 
> <opsawg@ietf.org>
> *Objet :* Re: [OPSAWG] Specifying protocols in 
> draft-claise-opsawg-collected-data-manifest
>
> 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<jean.quilbeuf=40huawei.com@dmarc.ietf.org>
>
>     *收件人:*** opsawg<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
>     https://www.ietf.org/mailman/listinfo/opsawg
>
>
>
>     _______________________________________________
>
>     OPSAWG mailing list
>
>     OPSAWG@ietf.org
>
>     https://www.ietf.org/mailman/listinfo/opsawg
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.