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
