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

From: Qin Wu <[email-masked]>
Date: Tue, 12 Apr 2022 15:27:03 +0000

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:[email-masked]] 
发送时间: 2022年4月11日 21:32
收件人: Qin Wu <[email-masked]>
抄送: Kent Watsen <[email-masked]>; [email-masked]
主题: 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:[email-masked]] 代表 Jürgen Sch?nw?lder
> 发送时间: 2022年4月11日 15:55
> 收件人: Kent Watsen <[email-masked]>
> 抄送: [email-masked]
> 主题: 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
> > [email-masked]
> > 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
> [email-masked]
> 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/>

---

From: Jürgen Schönwälder <[email-masked]>
Date: Wed, 13 Apr 2022 08:37:20 +0200

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

---

From: "maqiufang (A)" <[email-masked]>
Date: Wed, 13 Apr 2022 11:19:17 +0000

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:[email-masked]] On Behalf Of Jürgen Sch?nw?lder
Sent: Wednesday, April 13, 2022 2:37 PM
To: Qin Wu <[email-masked]>
Cc: [email-masked]
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:
> 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.
> 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
> -----邮件原件-----
> > > <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags
> > > >
> > >