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

[Andy Bierman <[e-mail]>]

Hi,

Adding a couple missed comments inline...

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

>
>
> On Tue, Apr 18, 2023 at 6:59 PM Kent Watsen <[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.

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

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.


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]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>