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

[Qin Wu <[e-mail]>]

Hi

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

Hi,

Adding a couple missed comments inline...

On Wed, Apr 19, 2023 at 11:38 AM Andy Bierman <[e-mail]<mailto:[e-mail]>> wrote:


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.

2) System tag procedures

There are no procedures defined for YANG model developers.
Are they supposed to add a node-tag extension to almost every leaf in the module?
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.


There is no way to specify the 'type' property using this extension.
There is no way to report this value in <operational> for system entries.
The "standard" tags (e.g. "ietf:loss" have no formal linkage to the identity 'loss' in the module.
It is not clear what value the 'type' identityref leaf provides at all.

[Qin Wu] One of reason to introduce ‘type’identityref leaf is to based on Jurgen’s comment and make the node tag
generic enough to apply all possible scenarios. As I clarified earlier, I think 'type' identityref leaf provide a second
level classification and further can indicate what metric type we are using, the metric type is well specified in
section 3.2 of draft-richih-opsawg-openmetrics-00.

In addition, ‘type’ identityref leaf is an optional leaf, it can be ignored if it doesn’t need.

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

-  nacm:node-instance-identifier as a list key is complex to implement
   - not sure a canonical representation is possible or required
   - syntax allows notification and action nodes to be tagged. Are these allowed in thislist?


There is no canonical form possible for an instance-identifier.
Yet this module MUST define the procedures for storing and comparing 2 instances of this key leaf.
[Qin Wu] I am wondering whether adding one more leaf as a new key leaf is a better choice.
The new leaf is string type and need to be global unique.

The draft says RESTCONF is supported.  It should also say that JSON is not supported
since the instance-identifier data type is used in a configuration data node.

IMO the instance-identifier encoding in RFC 7951 is a much better choice.
E.g., make a NACM schema-node-identifier typedef based on 7951, not 7950.

BTW, the same problem also exists if a list key is type identityref.
The encoding in 7951 is a better choice here as well.

[Qin Wu] Do you suggest we should use instance-identifier instead of nacm:node-instance-identifier
For list key? How instance-identifier can represent both data node and instance of data node?

Sec 4.3:

    Any tag with the prefix "user:" is a user tag. Furthermore, any tag that does not contain a colon
    (":", i.e., has no prefix) is also a user tag. Users are not required to use the "user:" prefix; however,
    doing so is RECOMMENDED.

How does this text impact the key leaf 'tag' in the YANG module?
Do the key leaf values "user:foo" and "foo" match or not?
If yes, there needs to be a canonical format . If no, then not a good design.

[Qin Wu] I think it is the former, whether you enter “user:foo” or “foo”, they are equivalent,
I think both should be stored as “user:foo”, in other words, if we enter “foo”, it will be automatically
add “user:” before “foo” and store consistently, is this what you are looking for?


Andy

-  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.

- What if a tag value appears in the masked-tag leaf-list that has the same value as the 'tag' key leaf?

- the indentation in the YANG module is wrong for masked-tag

- the list and key naming (tags/tag) is not consistent with other IETF modules .
  Maybe should be list tag and key leaf id.



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