发件人: Andy Bierman [mailto:[email protected]] 发送时间: 2024年5月14日 1:28 收件人: Qin Wu <[email protected]> 抄送: Kent Watsen <[email protected]>; [email protected] 主题: Re: [netmod] RE I-D Action: draft-ietf-netmod-node-tags-11.txt
On Sat, May 11, 2024 at 11:01 PM Qin Wu <[email protected]<mailto:[email protected]>> wrote: 发件人: Andy Bierman [mailto:[email protected]<mailto:[email protected]>] 发送时间: 2024年5月11日 1:10 收件人: Qin Wu <[email protected]<mailto:[email protected]>> 抄送: Kent Watsen <[email protected]<mailto:kent%[email protected]>>; [email protected]<mailto:[email protected]> 主题: Re: [netmod] RE I-D Action: draft-ietf-netmod-node-tags-11.txt On Thu, May 9, 2024 at 7:19 AM Qin Wu <[email protected]<mailto:[email protected]>> wrote: Thank Andy for valuable comments, I have update introduction in the github to clarify the motivation and provide more guidance See diff: https://author-tools.ietf.org/diff?url_1=https://raw.githubusercontent.com/billwuqin/draft-ietf-netmod-node-tags/main/draft-ietf-netmod-node-tags-12.txt I cannot find any evidence that the IETF module-tags are being used anywhere. https://www.rfc-editor.org/rfc/rfc8819.html#name-ietf-yang-module-tags-regis Why do we need to go through every leaf in every YANG module and decide if it is a metric, log, trace, or info? Wouldn't every leaf be tagged as 'info'? [Qin]:I think you don’t need to go through all leafs and in most cases, you just pick the leaf you are interested or you might just pick parent leaf (e.g., list, container, etc). Take user configured tag as an example, You as user or operators can use edit-data to label all instances of data node and establish the mapping between the label and instance of data node using ietf-node-tags, Which can be get accessed to other users for data analytics, or decide to where to subscribe the data. These data can be seen as user intent in some sense. IMO it makes sense (in some cases) to improve the granularity of the module-tag with per-node tagging. That means using the same tag registry defined in RFC 8819, not inventing a new classification system. [Qin]:note that what we proposed in this document is to extend module tag module to establish the mapping between tag and leaf. Or you think we should add one parameter under module list of ietf-module-tags to distinguish module name from node name such as: module: ietf-module-tags +--rw module-tags +--rw module* [name] +--rw name yang:yang-identifier +--rw type //indicate whether it is module or node. +--rw tag* tag +--rw masked-tag* tag Or you just think we should not introduce yang extension for node-tag, just reuse YANG extension for module-tag, I am open to this. I cannot find any evidence that the module-tag extension is being used. There are no standard protocol operations that use module tags. YANG Doctors are not telling WGs to add module-tag extensions. The tag mechanism has some value, although variables (i.e. RFC 7952 annotations) would be much better than tags. The IETF classifications should not be expanded since they are not even being used now. There is still some value in the vendor and user tags. We have proprietary augments to get* operations and to NACM rules to use a module-tag as a filter. Node tags could be more useful. They could provide a simple way to use YANG Push. But maybe this makes more sense as a vendor or operator-configured feature. -Qin Andy Andy [Qin Wu]I think it can also be used as standard feature, Taking ONUG project and use cases as an example, many cloud providers suffer from increased expenditure of human and capital resources to assess Cloud Security Notification. They are looking for common definition and syntax for Cloud security notification. ONUG is working on Common Cloud Security Notification Framework or CSCF, CSCF introduces the similar concept as node tag called decorator which can provide rich context information without need to define new data node or new object, for downstream tools, they can use decorator to integrate these context data easily into data lake to drive new dashboards usages, I think node tag can be designed for the same purpose even though I haven't envision how module tag or module tag extension can be used. See the introduction of ONUG decorator: https://onug.net/blog/multi-cloud-security-gets-a-decorator/ " The “decorator” is to provide a common set of definitions and syntax to: 1. Ease ingestion of CSP security notifications into security data lakes and other security plus observability tools 2.Provide CSPs translational services to understand common security notifications between and across CSPs a. Mappings of NIST controls and MITRE ATT&CK into a decorator are high priority to deliver cross CSP translational service 3. Extended log information field attributes are to be accommodated to better understand context, e.g., each CSP to provide a log plus type set of meta field a.A method to tag or identify Cloud Consumer assets so as to prioritize response is high priority " 发件人: netmod [mailto:[email protected]<mailto:[email protected]>] 代表 Andy Bierman 发送时间: 2024年2月21日 8:18 收件人: Kent Watsen <[email protected]<mailto:kent%[email protected]>> 抄送: [email protected]<mailto:[email protected]> 主题: Re: [netmod] RE I-D Action: draft-ietf-netmod-node-tags-11.txt On Tue, Feb 20, 2024 at 8:03 AM Kent Watsen <[email protected]<mailto:kent%[email protected]>> wrote: Juergen, Tom, Andy, Gentle reminder. I read draft-11. It is an improvement. No objections. There are 4 IETF tags defined: metrics, logs, traces, info I do not see much value in these standard tags, but more guidance and explanation would help. Since the IETF does not define any protocol usage of tags, there is little impact caused by this draft, except for the additional administrative overhead. Kent // shepherd Andy > On Nov 14, 2023, at 4:49 PM, Kent Watsen > <[email protected]<mailto:kent%[email protected]>> wrote: > > Juergen, Tom, Andy, > > The previous WGLC for this draft didn’t succeed due to your comments. > Qin’s update (1) below removes all the (metric) specific node-tags. > All that is left now is the generic mechanism for tagging nodes. > Can you confirm that this update (-11) addresses your concerns? > > Thanks, > Kent > > >> On Oct 23, 2023, at 6:28 AM, Qin Wu >> <[email protected]<mailto:[email protected]>> >> wrote: >> >> v-11 addresses comments during WGLC, the main changes include: >> 1. Remove all specific metrics from both terminology section and section 9.2 >> on IETF YANG Data Node Tags Registry based on WGLC discussion. >> 2. Align with Open Telemetry and Open Metrics open source implementation >> specification, introduce traces, log for data nodes classification. >> 3.Fix normative reference issues in section 9.2. >> >> -Qin >> -----邮件原件----- >> 发件人: I-D-Announce >> [mailto:[email protected]<mailto:[email protected]>] >> 代表 [email protected]<mailto:[email protected]> >> 发送时间: 2023年10月21日 17:56 >> 收件人: [email protected]<mailto:[email protected]> >> 抄送: [email protected]<mailto:[email protected]> >> 主题: I-D Action: draft-ietf-netmod-node-tags-11.txt >> >> Internet-Draft draft-ietf-netmod-node-tags-11.txt is now available. It is a >> work item of the Network Modeling (NETMOD) WG of the IETF. >> >> Title: Node Tags in YANG Modules >> Authors: Qin Wu >> Benoit Claise >> Mohamed Boucadair >> Peng Liu >> Zongpeng Du >> Name: draft-ietf-netmod-node-tags-11.txt >> Pages: 30 >> Dates: 2023-10-21 >> >> Abstract: >> >> This document defines a method to tag nodes that are associated with >> the operation and management data in YANG modules. This method for >> tagging YANG nodes is meant to be used for classifying either data >> nodes or instances of data nodes from different YANG modules and >> identifying their characteristic data. Tags may be registered as >> well as assigned during the definition of the module, assigned by >> implementations, or dynamically defined and set by users. >> >> This document also provides guidance to future YANG data model >> writers; as such, this document updates RFC 8407. >> >> The IETF datatracker status page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-ietf-netmod-node-tags/ >> >> There is also an HTMLized version available at: >> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-11 >> >> A diff from the previous version is available at: >> https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-node-tags-11 >> >> Internet-Drafts are also available by rsync at: >> rsync.ietf.org::internet-drafts >> >> >> _______________________________________________ >> I-D-Announce mailing list >> [email protected]<mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/i-d-announce >> >> _______________________________________________ >> netmod mailing list >> [email protected]<mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
