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