Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

Qin Wu <bill.wu@huawei.com> Mon, 11 April 2022 11:52 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB71D3A191A for <netmod@ietfa.amsl.com>; Mon, 11 Apr 2022 04:52:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=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 o0j0pyGOAjWU for <netmod@ietfa.amsl.com>; Mon, 11 Apr 2022 04:52:17 -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 84EA63A1919 for <netmod@ietf.org>; Mon, 11 Apr 2022 04:52:17 -0700 (PDT)
Received: from fraeml712-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4KcRxH6Qq6z67Vhh; Mon, 11 Apr 2022 19:50:11 +0800 (CST)
Received: from canpemm500005.china.huawei.com (7.192.104.229) by fraeml712-chm.china.huawei.com (10.206.15.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 11 Apr 2022 13:52:12 +0200
Received: from canpemm500005.china.huawei.com (7.192.104.229) by canpemm500005.china.huawei.com (7.192.104.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Mon, 11 Apr 2022 19:52:10 +0800
Received: from canpemm500005.china.huawei.com ([7.192.104.229]) by canpemm500005.china.huawei.com ([7.192.104.229]) with mapi id 15.01.2375.024; Mon, 11 Apr 2022 19:52:10 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Jürgen Schönwälder <j.schoenwaelder@jacobs-university.de>, Kent Watsen <kent+ietf@watsen.net>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] WGLC on draft-ietf-netmod-node-tags-06
Thread-Index: AdhNhJha0arwSZZrTNadvmCMven9PQ==
Date: Mon, 11 Apr 2022 11:52:10 +0000
Message-ID: <9d2afd9f536d4db6b9fa54edb6d90d63@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.100.16]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/qHnKfPacmejoqdRhKnz2kg6FjKI>
Subject: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2022 11:52:23 -0000

Hi, Jürgen:
Thank for quick comments. Please see reply inline below.
-----邮件原件-----
>发件人: netmod [mailto:netmod-bounces@ietf.org] 代表 Jürgen Sch?nw?lder
>发送时间: 2022年4月11日 16:19
>收件人: Kent Watsen <kent+ietf@watsen.net>
>抄送: netmod@ietf.org
>主题: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

>I have a problem with the term "Self-Describing Data Object Tags". It is not clear what 'self-describing' means. RFC 8819 defines "YANG Module Tags", i.e., tags that apply to entire modules. Perhaps this document should be titled "YANG Data Node 
>Instance Tags".
[Qin Wu] Good comment, in my understanding, the essence of data object tags is to classification telemetry data or operation and management data into several categories and tag data node with category information (e.g., tag a data node to indicate whether it is KPI related data), therefore here "self-describing" is really referred to inline information included in the same data module. I am okay to change the title to reflect what it actually is. Maybe "YANG data node Tags" is more appropriate.

>There should be in general a check that terminology aligns with YANG terminology.  The document talks about 'YANG data object', which is not a well defined term. In fact, there are three levels of tagging, you can tag modules (RFC 8819), you can tag 
>data nodes, and you can tag data node instances. It seems a bit unclear to me what the WGs strategy is here with covering all three levels.

[Qin Wu] Good question, I am also discussing with Joe about the similar issue, we could have both data node level tag and instance level tag since we use node-instance-identifier type and need to reach agreement on this.

>I have not read the document in detail yet but I find the notion of data objects and subobjects confusing. I also do not know what "massive" data object collections are or why both objects and subobjects can be modeled as YANG data nodes, or what the 
>purpose of this statement is. 

[Qin Wu] massive data collection might consume large amount of network bandwidth resource and computation resource. the data node tag help us capture characteristics data (e.g., KPI data) and greatly reduce the data to exported to the collectors.
Take example-module-A as an example:
   module example-module-A {
     //...
     container top {
       list X {
         leaf foo {
         }
         leaf bar {
         }
       }
     }
     // ...
   }
The top level node will be seen as data object while leaf foo and leaf bar will be seen as subobject, the top level node will be tagged with Object tag, the child node will be tagged with other tag such as metric tag or metric type tags.
Note that the notion of data objects and subobjects is only used in the usage example in section 3. Do you think it is confusing to introduce new terminologies, if yes, I will see how to fix this.

>When I look at ietf-data-object-tags (likely also a misnomer), then what I see is a list associating tags to anything identifiable by a nacm:node-instance-identifier. It feels like this document has a lot of hot air around something that is at the end rather basic.

[Qin Wu] Please note that RFC9196 also defines node-selector as node-instance-identifier. See the definition of node-instance-identifier in RFC8341
"
     typedef node-instance-identifier {
       type yang:xpath1.0;
       description
         "Path expression used to represent a special
          data node, action, or notification instance-identifier
          string.

          A node-instance-identifier value is an
          unrestricted YANG instance-identifier expression.
          All the same rules as an instance-identifier apply,
          except that ***predicates**** for keys are optional.
          If a key
          predicate is missing, then the node-instance-identifier
          represents all possible server instances for that key. "
It can represent one specific node instance,e.g.,
     /* instance-identifier for a list entry */
     /ex:system/ex:user[ex:name='fred']
or all possible node instance if the predicates is not specified, e.g.,
     /* instance-identifier for all list entry/
        /ex:system/ex:user
For the latter case, it can also be seen as at node level or schema node level if my understanding is correct.

>/js

>On Fri, Apr 08, 2022 at 06:09:45PM +0000, Kent Watsen wrote:
>> This message begins a Working Group Last Call (WGLC) on draft-ietf-netmod-node-tags-06, per the chair-action from the 113 session (minutes <https://notes.ietf.org/#4-Title-Self-Describing-Data-Object-Tags-10-min>).  The WGLC will close in two->weeks (Apr 22).  Here is a direct link to the HTML version of the draft:
>> 
>> 	https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags 
>> <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags>
>> 
>> Positive comments, e.g., "I've reviewed this document and believe it is ready for publication", are welcome!  This is useful and important, even from authors. Objections, concerns, and suggestions are also welcomed at this time.
>> 
>> Please be aware that this draft has declared IPR <https://datatracker.ietf.org/ipr/4216> indicating that license may entail possible royalty/fee. Also, this exchange between Lou and Qin on 8/30/2020 (mailman 
><https://mailarchive.ietf.org/arch/msg/netmod/SC6zfdYVmvlkquWOzP1qZszxWgs/>):
>> 
>> [Lou] Since this work is derived from work that I contributed to, I'd be interested in hearing what new mechanism(s) is/are covered by the IPR disclosure prior to supporting WG adoption.  I'm not asking in order to debate this, as that is something for 
>other venues, I'm merely asking that you state for the record what new mechanism is covered.
>> 
>> [Qin] Thanks for asking, different from module level tag defined in draft-ietf-netmod-module-tags , this work provide data node level tag definition, use these data node level tag definition to provide hint or indication to selection filter in the YANG push 
>and tell the collector or subscriber which specific category data objects needs to fetched.
> 
> 
> Kent (as co-chair)
> 

> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


-- 
Jürgen Schönwälder              Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod