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