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

[Qin Wu <[e-mail]>]

Hi, Balazs:
Thanks for your valuable comments, I have incorporated your comments into https://github.com/billwuqin/draft-ietf-netmod-node-tags/blob/main/draft-ietf-netmod-node-tags-07.txt
please see reply inline below.
-----邮件原件-----
>发件人: Balázs Lengyel [mailto:balazs.lengyel=[e-mail]] 
>发送时间: 2022年4月12日 0:38
>收件人: Qin Wu <[e-mail]>; Jürgen Schönwälder <[e-mail]>
>抄送: [e-mail]
>主题: RE: [netmod] WGLC on draft-ietf-netmod-node-tags-06

>Hello,
>Sorry for the late comments as I am not very familiar with the topic, but some questions:
>- What makes a tag "self-describing" ? Unless this "self-describing" has a specific meaning, it would be easier not use it. I personally would prefer instead of "self-describing  data object tags" some simpler name like "data properties".
[Qin Wu] I have been discussing with Jurgen about the naming, we have reached agreement to change the title. Thanks for your proposal, data properties is a good naming, but have a little bit naming conflict with opm tag, since opm tag can be assigned with the 'property' value. 
>- In the YANG module I found the sentence: " The argument 'tag' is of type 'tag' "  Where is the "type tag" defined ?  If you mean from RFC 8819 indicate that e.g. by using the yang prefix: tags:tag.
[Qin Wu] Your understanding is correct, I will use prefix tags: tag as you suggested. Good catch, thanks.
>- Reserved Tags: As I understand other SDOs may register their own prefix with IANA in which case the list of :reserved for future use" is not the correct characterization.
[Qin Wu] How about change into the following:
"
Any tag not starting with the prefix "ietf:", "vendor:", "user:" or being reserved by other SDOs is reserved by IETF for future use ...
"
>- tags can be associated with "data-objects" - RFC7950 does not use the terminology "data object". Please call this "data nodes" or "data node instances" and define in the terminology section if you use it. 
[Qin Wu] Good suggestion, thanks.
>- is the tag (property) inherited down the containment hierarchy? If a container is marked with a tag, do all its contained leaves inherit the tag ? 
[Qin Wu] Very good comments. We define 3 data node tags in this draft, for metric-type and multi-source-tag tags, will be inherited down the containment hierarchy. For OPM tag, object tag value can not be inherited down but property tag and metric tag can be inherited down the containment hierarchy. I have add text to clarify this in section 5.1.
>- for each extension statement the following should be described
>   +  It can be a substatement of which parent statement, with what cardinality?
[Qin Wu] Again good comment, object tag value will be associated with 'container', 'leaf-list', and 'list'. Property tag value will be associated only with the leaf node. Metric tag value can be associated with 'container', 'leaf-list', and 'list', leaf node.
For metric-type tag, it will be associated with 'container', 'leaf-list', and 'list', leaf node tagged with 'metric' tag. For multi-source tag, similarly, it will be associated with 'container', 'leaf-list', and 'list', leaf node tagged with 'metric' tag.

For cardinality, I think opm tag have 3 fixed values and multi-source-tag tag have 2 fixed values. For metric-type value, it can be extensible and we list 7 possible values, but not limited to those values.
>    + Can it have substatements    
[Qin Wu] As described in section 7, each tag can only take one argument. No other substatments.
>   + Changing this extension statement is a backwards-compatible change yes/no/editorial-only
[Qin Wu] Can you provide an example for this issue or reference document, I can not find any guideline in RFC7950.
>   + Define the type as yang type. Is the list of possible values closed or can any string be used that fulfills the type-tag
[Qin Wu] See above, only opm tag and multi-source tag has possible value closed.
>- Security considerations calls these tags met-data. While from a broader perspective that may be true, these tags are not metadata according to RFC 7952. Avoid using this terminology or clarify this.
[Qin Wu] I agree to remove meta-data based on RFC7952 metadata definition. It is not metadata.
>- "name" is not a very good name for a leaf containing an node-instance-identifier.
[Qin Wu] How about change into 'ni-id'?
 
>-IMHO module ietf-data-object-tags-state should augment ietf-module-tags-state not ietf-module-tags
[Qin Wu] Good catch, have fixed this.
>- Why does ietf-data-object-tags-state redefine the extensions? Duplication is bad.
[Qin Wu] Good catch, have fixed this.
>- Shoudn't there be an editor's note about replacing XXXX with the RFC number?
[Qin Wu] Good suggestion, thanks.
>Regards Balazs

-----Original Message-----
>From: netmod <[e-mail]> On Behalf Of Qin Wu
>Sent: Monday, 11 April, 2022 15:43
>To: Jürgen Schönwälder <[e-mail]>
>Cc: [e-mail]
>Subject: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

>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://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-20f0e1ba59d49168&q=1&e=8fa311c3-7dfc-4595-b6d4-f418a62338cb&u=https%3A%2F%2Fwww.jacobs-university.de%2F>
_______________________________________________
>netmod mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/netmod