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