Dear Qiufang, I did not ask for an extended-tag-type. I do not think you really understood my concerns. I do not understand the whole object, property, metric business nor has my question how this relates to the NETCONF I-D providing another meta-data retrieval mechanism been answered. There are authors who are on both documents so someone should have an answer hy we need multiple mechanisms.
We should focus on a generic mechanism to convey meta-information and not confuse that with the semantics of the different kinds of tags. I am looking for a generic mechanims that can be used for A, B, and C instead of a solution for A, a different solution for B, and yet another for C. /js On Fri, Apr 29, 2022 at 10:35:42AM +0000, Qin Wu wrote: > Hi, Qiufang: > First, the metric-tag defined in this draft allow you add more metric-tag > values in the metric-tag subregistry. See usage example in the Appendix B. > To make the data node tags module even more extensible, I think adding one > leaf in the type of enumeration is still limited, > a. the enumeration type is not extensible and doesn't allow you add new > enumeration values. > b. how do you introduce other auxiliary data associated with new introduced > tag type, therefore here is my proposal: > module: ietf-data-node-tags > augment /tags:module-tags/tags:module: > +--rw data-node-tags > +--rw data-node* [ni-id] > +--rw ni-id nacm:node-instance-identifier > +--rw tag* tags:tag > +--rw masked-tag* tags:tag > +--rw extended-tag-type? identityref > As you can see, we introduce extended-tag-type in the base module, > which allows you further add auxiliary data in the extension to the base > module, see Appendix A for example. > See more details in v-07 > https://datatracker.ietf.org/doc/draft-ietf-netmod-node-tags/ > > -Qin > -----邮件原件----- > 发件人: maqiufang (A) > 发送时间: 2022年4月13日 19:19 > 收件人: Jürgen Schönwälder <j.schoenwael...@jacobs-university.de>; Qin Wu > <bill...@huawei.com> > 抄送: netmod@ietf.org > 主题: RE: [netmod] WGLC on draft-ietf-netmod-node-tags-06 > > Hi, Juergen, Qin > How about defining a more general mechanism to cover your proposal: > module: ietf-data-node-tags > augment /tags:module-tags/tags:module: > +--rw data-object-tags > +--rw data-node* [ni-id] > +--rw ni-id nacm:node-instance-identifier > +--rw tag-list* [tag] > | +--rw tag tags:tag > | +--rw value? enumeration > +--rw masked-tag* tags:tag > So that the users can define any tag(e.g., corresponding-mib-oid, > related-node...) they’re interested in and the corresponding value(if any). > > Best Regards, > Qiufang > > -----Original Message----- > From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Jürgen Sch?nw?lder > Sent: Wednesday, April 13, 2022 2:37 PM > To: Qin Wu <bill...@huawei.com> > Cc: netmod@ietf.org > Subject: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06 > > Hi, > > I believe the NETMOD WG should work out a single mechanism to convey > metadata. I see no value in developing N use case specific mechanisms spread > over several WGs. If this document is not aiming to provide a generic > solution, then I believe it should not be published. > > /js > > On Tue, Apr 12, 2022 at 03:27:03PM +0000, Qin Wu wrote: > > Hi, Jurgen: > > I understand your comment, is to investigate more use cases and see how one > > mechanism can be generalized to cover more use cases. > > But the idea of this draft is to capture characteristics data (e.g., KPI > > data ) using data node tag. Data node tag module can only convey enumerated > > tag valued defined in section 9.2, that is why Balazs clarify the essence > > of data nod tag are not metadata based on RFC7950 but data properties. > > > > I did investigate meta-data-collection draft. I think meta-data > > collection draft extends from ietf-system-capabilities module defined in > > RFC9196 while draft-ietf-netmod-node-tags-06 extends from ietf-module-tags > > defined in RFC8819 I believe observable-period related parameter in > > metadata-collection module is not suited to be redefined in Data node tag > > module since they are really system capability related parameters. > > For three other parameters such as corresponding-mib-oid, related-node, > > optimized-measurement-point, not every data node has these three > > parameters, the value of corresponding-mib-oid, related-node can be any > > value it is hard to be listed as tag values, for > > optimized-measutement-point, it is empty type, it seem to fine, but add > > corresponding-mib-oid, related-node make data node tag module design very > > ugly, also the value of corresponding-mib-oid, related-node are read only > > value and can not be configured by the user. > > module: ietf-data-node-tags > > augment /tags:module-tags/tags:module: > > +--rw data-node-tags > > +--rw data-node* [ni-id] > > +--rw ni-id nacm:node-instance-identifier > > +--rw tag* tags:tag > > +--rw masked-tag* tags:tag > > +--rw corresponding-mib-oid? yang:object-identifier-128 > > +--rw related-node? yang:node-instance-identifier > > In addition, we may need to introduce new yang extension for these two > > parameters and consider to use when statement to decide when > > corresponding-mib-oid or related-node should not appear or otherwise, I > > feel designing this kind of model is not generic. Please correct me if I am > > wrong. > > > > -Qin > > -----邮件原件----- > > 发件人: Jürgen Schönwälder [mailto:j.schoenwael...@jacobs-university.de] > > 发送时间: 2022年4月11日 21:32 > > 收件人: Qin Wu <bill...@huawei.com> > > 抄送: Kent Watsen <kent+i...@watsen.net>; netmod@ietf.org > > 主题: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06 > > > > It seems like we confuse use cases with mechanisms. We should IMHO focus on > > defining one mechanism to convey metadata and ideally that mechanism than > > supports multiple use cases. > > > > /js > > > > On Mon, Apr 11, 2022 at 01:14:08PM +0000, Qin Wu wrote: > > > Hi, Jurgen: > > > Thank for bringing this issue up. > > > Generally, I feel two drafts are orthogonal to each other. > > > Draft-ietf-netmod-node-tags-06 focuses on YANG modelled data > > > classification while draft-claise-netconf-metadata-for-collection-03 > > > focuses on telemetry related server capability exposure, e.g., how > > > frequent you can use YANG push mechanism to send the telemetry data, from > > > where to collect the specific interested data, how to inform the client > > > or collector when the server compute a new observable period, in other > > > words, draft-claise-netconf-metadata-for-collection-03 more focuses on > > > data collection protocol (e.g., yang push) related metadata. > > > > > > In addition, draft-ietf-netmod-node-tags-06 doesn't need to depend on > > > notification capability defined in RFC9196 since ietf-data-object-tags in > > > draft-ietf-netmod-node-tags-06 defines data objects list under > > > /tags:module-tags/tags:module. Therefore the client can look for these > > > tags from the <operational>, <get-schema> also can be used since yang > > > extension is defined for these tags in the ietf-data-object-tags. > > > > > > Please correct me if I am wrong. > > > > > > -Qin > > > -----邮件原件----- > > > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Jürgen Sch?nw?lder > > > 发送时间: 2022年4月11日 15:55 > > > 收件人: Kent Watsen <kent+i...@watsen.net> > > > 抄送: netmod@ietf.org > > > 主题: Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06 > > > > > > During the NETCONF meeting at IETF 113, Benoit presented an I-D > > > titled > > > > > > Per-Node Capabilities for Optimum Operational Data Collection > > > draft-claise-netconf-metadata-for-collection-03 > > > > > > and I asked why we need another metadata export mechanism given that node > > > tags is been worked on in the NETMOD WG. The reaction during the meeting > > > was to followup on the mailing list, i.e., there was no conclusive answer > > > during the meeting. > > > > > > I suggest that this document does not proceed until we know that it > > > provides all mechanisms needed to support the use case described in the > > > above mentioned I-D. If any functionality is lacking, the WG may want to > > > investigate whether this can be addressed generically. > > > > > > /js > > > > > > On Fri, Apr 08, 2022 at 06:09:45PM +0000, Kent Watsen wrote: > > > > This message begins a Working Group Last Call (WGLC) on > > > > draft-ietf-netmod-node-tags-06, per the chair-action from the 113 > > > > session (minutes > > > > <https://notes.ietf.org/#4-Title-Self-Describing-Data-Object-Tags-10-min>). > > > > The WGLC will close in two-weeks (Apr 22). Here is a direct link to > > > > the HTML version of the draft: > > > > > > > > > > > > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags > > > > <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags > > > > > > > > > > > > > Positive comments, e.g., "I've reviewed this document and believe it is > > > > ready for publication", are welcome! This is useful and important, > > > > even from authors. Objections, concerns, and suggestions are also > > > > welcomed at this time. > > > > > > > > Please be aware that this draft has declared IPR > > > > <https://datatracker.ietf.org/ipr/4216> indicating that license may > > > > entail possible royalty/fee. Also, this exchange between Lou and Qin on > > > > 8/30/2020 (mailman > > > > <https://mailarchive.ietf.org/arch/msg/netmod/SC6zfdYVmvlkquWOzP1qZszxWgs/>): > > > > > > > > [Lou] Since this work is derived from work that I contributed to, I'd > > > > be interested in hearing what new mechanism(s) is/are covered by the > > > > IPR disclosure prior to supporting WG adoption. I'm not asking in > > > > order to debate this, as that is something for other venues, I'm merely > > > > asking that you state for the record what new mechanism is covered. > > > > > > > > [Qin] Thanks for asking, different from module level tag defined in > > > > draft-ietf-netmod-module-tags , this work provide data node level tag > > > > definition, use these data node level tag definition to provide hint or > > > > indication to selection filter in the YANG push and tell the collector > > > > or subscriber which specific category data objects needs to fetched. > > > > > > > > > > > > Kent (as co-chair) > > > > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > -- > > > 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 > > > > -- > > 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/> > > -- > 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 -- 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
