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

[Qin Wu <[e-mail]>]

Hi, Jurgen:
-----邮件原件-----
发件人: Jürgen Schönwälder [mailto:[e-mail]] 
发送时间: 2022年4月11日 20:18
收件人: Qin Wu <[e-mail]>
抄送: Kent Watsen <[e-mail]>; [e-mail]
主题: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

On Mon, Apr 11, 2022 at 11:52:10AM +0000, Qin Wu wrote:
> >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.

I strongly disagree with introducing new terminology. The notion of a data object or a subobject does not exist in YANG. All the YANG model does is to associate tags with yang-node-identifiers. That's it and I think the document should restrict itself to explain that.
[Qin Wu] Fair point, I will remove these new terms. Thanks!
My comment was actually more about words like "massive" being a purely subjective term. Marketing people may use them but in technical writing or even scientific writing, they have no real meaning. 
[Qin Wu] Thanks for pointing this out, I didn't realize this is an issue before you flag this, what I emphasize large amount of data you need to collect, maybe should choose the better term, thanks.
If you are worried about scalability (and I would), then the question to ask may be whether a single flat list is scalable to large numbers of tags, i.e., how many queries do I need to find all relevant tags and how do the queries scale.
[Qin Wu] Again those tags defined in this draft are used to classify the data, the number of standard tag defined in this draft is not too many. At the schema level, I think the scale is not a problem, since the tag at the schema level help find where to get these interested data. At the data node instance level, using tag will help filter and quickly identify specific category data, e.g., KPI data, the query scale and cost is not greater than
Retrieving all the operational data and figuring out later on which one are useful data itself.
> >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.

I can't tell right now whether RFC 9196 makes proper use of nacm:node-instance-identifier. Anyway, this is important material to explain, not the data objects massive kind of marketing text.
[Qin Wu] Okay, will clarify this in the next version. Thanks!
/js

-- 
Jürgen Schönwälder              Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>