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. 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. 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. > >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. /js -- 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