Re: [netmod] WGLC on draft-ietf-netmod-node-tags-06

[Jürgen Schönwälder <[e-mail]>]

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 <[e-mail]>; Qin Wu <[e-mail]>
> 抄送: [e-mail]
> 主题: 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:[e-mail]] On Behalf Of Jürgen Sch?nw?lder
> Sent: Wednesday, April 13, 2022 2:37 PM
> To: Qin Wu <[e-mail]>
> Cc: [e-mail]
> 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:[e-mail]]
> > 发送时间: 2022年4月11日 21:32
> > 收件人: Qin Wu <[e-mail]>
> > 抄送: Kent Watsen <[e-mail]>; [e-mail]
> > 主题: 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:[e-mail]] 代表 Jürgen Sch?nw?lder
> > > 发送时间: 2022年4月11日 15:55
> > > 收件人: Kent Watsen <[e-mail]>
> > > 抄送: [e-mail]
> > > 主题: 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
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > > 
> > > 
> > > -- 
> > > Jürgen Schönwälder              Jacobs University Bremen gGmbH
> > > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   [phone]         <https://www.jacobs-university.de/>
> > > 
> > > _______________________________________________
> > > netmod mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netmod
> > 
> > -- 
> > Jürgen Schönwälder              Jacobs University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <https://www.jacobs-university.de/>
> 
> -- 
> Jürgen Schönwälder              Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Jürgen Schönwälder              Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>