Re: [netmod] WGLC on node-tags-09

[Qin Wu <[e-mail]>]

Andy:
Sorry for late followup, please see my reply inline below.

发件人: netmod [mailto:[e-mail]] 代表 Andy Bierman
发送时间: 2023年4月20日 2:39
收件人: Kent Watsen <[e-mail]>
抄送: [e-mail]
主题: Re: [netmod] WGLC on node-tags-09



On Tue, Apr 18, 2023 at 6:59 PM Kent Watsen <[e-mail]<mailto:[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netmod