Andy: Sorry for late followup, please see my reply inline below. 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Andy Bierman 发送时间: 2023年4月20日 2:39 收件人: Kent Watsen <kent+i...@watsen.net> 抄送: netmod@ietf.org 主题: Re: [netmod] WGLC on node-tags-09
On Tue, Apr 18, 2023 at 6:59 PM Kent Watsen <kent+i...@watsen.net<mailto:kent%2bi...@watsen.net>> wrote: This email begins a two-week WGLC on: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-09 Please take time to review this draft and post comments by May 2nd. Favorable comments are especially welcomed. I have read the latest draft and IMO it needs more work. 1) metrics The identities to represent system tags are quite vague. There are no specific guidelines for selecting the correct tag. There are no references to other RFCs for the metric definitions. I would expect IPPM WG to define the classification system, not NETMOD WG. [Qin Wu] Good comment, the idea of introducing system tags is to classify the data nodes or data node instances and identify the characteristics data or metric data. The identity is associated with ‘type’ leaf for specific data node or instance of data node and provides a second level classification, e.g., we add a system tag for ‘in-octets’ leaf under interface list in ietf-interface.yang module, in addition, we can add a type leaf with the value as ‘summary’ for the same leaf to indicate the leaf value is average value. For packet loss, jitter, delay, similar to what ALTO performance metrics RFC (draft-ietf-alto-performance-metrics) is doing, we don’t define any new metrics and we just reuse the same metrics defined in IPPM, we can add similar RFCs to packet loss, jitter, delay described in this draft. Regarding summary, counter definition, I believe we should reference to openmetric draft described in (https://datatracker.ietf.org/doc/html/draft-richih-opsawg-openmetrics-00) which has already been open sourced and well specified and validated. Regarding guidelines for selecting the correct tag, we did provide guideline for model writer to define system tags at the design time, but similar to what module tag is doing, we will leave freedom to the client to decide whether the correct tag is selected. One more thing I want to clarify is I think identity used to describe the type of data node should be limited to summary, counter, unknown, gauge, etc, the packet loss, delay identities can be removed. 2) System tag procedures There are no procedures defined for YANG model developers. [Qin Wu] See section 8 for guidelines for YANG model developers. Are they supposed to add a node-tag extension to almost every leaf in the module? [Qin Wu] The answer is no, we only add node tag extension to characteristics data Related leaf, e.g., leaf used to describe the metric data, e.g., the number of inbound packets that contained errors. The administration and maintenance of node-tags will be a huge burden. That was one reason they were not added to the module-tags module in the first place. The YANG extension itself is under-specified since it offers no guidance on which YANG statements are allowed to have this extension as a sub-statement. [Qin Wu] See last paragraph of section 9.2 “ A data node can contain one or multiple node tags.Data node to be tagged with the initial value in Table 2 can be one of 'container', 'leaf-list', 'list', or 'leaf' data node. All tag values described in Table 2 can be inherited down the containment hierarchy if Data nodes tagged with those tag values is one of 'container', 'leaf- list', 'list'. ” Note that we don’t allow add system tag to notification or action statement. We can make this clear in the updated text. IMO all the metrics (tag type identities) should be removed from this document and moved to separate work that is properly defined using IPPM metrics. 3) YANG module issues - what module entry is used if the node is from a module that augments another one? I would assume the augmented module not the base module. Specify which one [Qin Wu] As you can see, ietf-node-tags module augments from module list within ietf-module-tag module, the module entry will be decided by the name key leaf under module list module: ietf-module-tags +--rw module-tags +--rw module* [name] +--rw name yang:yang-identifier - nacm:node-instance-identifier as a list key is complex to implement [Qin Wu] The reason to select nacm:node-instance-identifier as a list key is to represent both data node and instance of data node, any other choice we can make? - not sure a canonical representation is possible or required - syntax allows notification and action nodes to be tagged. Are these allowed in thislist? [Qin Wu]: See above, the answer is no. - it is possible for multiple 'tags' entries to represent the same data node instances. Figuring out precedence and enforcing masked-tag rules seems complicated. NACM has ordered by-user semantics. This module has "all entries at once" semantics. Not that easy to implement or deploy. [Qin Wu] Same issue is applied to module tag RFC8819 which allow one module to be tagged with multiple tags. - What if a tag value appears in the masked-tag leaf-list that has the same value as the 'tag' key leaf? [Qin Wu] Similar to what module tag is doing, we can use masked-tag with the same tag value to remove this tag. - the indentation in the YANG module is wrong for masked-tag [Qin Wu] Fixed, thanks - the list and key naming (tags/tag) is not consistent with other IETF modules . Maybe should be list tag and key leaf id. [Qin Wu] Will fix this, thanks Andy This draft went through a WGLC a year ago. The authors addressed the comments received and have been were waiting for feedback. In essence, this draft is presumed to reflect WG consensus and thusly, if no objection is received, the draft will move to the next step in the publication process. Ref: https://mailarchive.ietf.org/arch/msg/netmod/n2P9yohA-X-xSIt6FlMr4wOqmuI/ Kent // co-chair _______________________________________________ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
