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

[Balázs Lengyel <[e-mail]>]

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".
- 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.
- 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.
- 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. 
- 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 ? 
- for each extension statement the following should be described
   +  It can be a substatement of which parent statement, with what cardinality?
    + Can it have substatements    
   + Changing this extension statement is a backwards-compatible change yes/no/editorial-only
   + Define the type as yang type. Is the list of possible values closed or can any string be used that fulfills the type-tag
- 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.
- "name" is not a very good name for a leaf containing an node-instance-identifier. 
-IMHO module ietf-data-object-tags-state should augment ietf-module-tags-state not ietf-module-tags
- Why does ietf-data-object-tags-state redefine the extensions? Duplication is bad.
- Shoudn't there be an editor's note about replacing XXXX with the RFC number?
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