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/>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
