Re: [netmod] Review comments for module-tags-02

I think we need to define a subtree for non-NMDA clients to get the operational tags.

Reference:  https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
"   2.  Models that require immediate support for "in use" and "system
       created" information SHOULD be structured for NMDA.  A non-NMDA
       version of these models SHOULD also be published, using either an
       existing model or a model created either by hand or with suitable
       tools that support current modeling strategies.  Both the NMDA
       and the non-NMDA modules SHOULD be published in the same
       document, with NMDA modules in the document main body and the
       non-NMDA modules in a non-normative appendix.  The use of the
       non-NMDA model will allow temporary bridging of the time period
       until NMDA implementations are available."  

-----Original Message-----
From: Christian Hopps [mailto:chopps@chopps.org] 
Sent: 17 October 2018 14:08
To: Rohit R Ranade <rohitrranade@huawei.com>
Cc: Christian Hopps <chopps@chopps.org>; netmod@ietf.org
Subject: Re: [netmod] Review comments for module-tags-02

> On Oct 17, 2018, at 12:09 AM, Rohit R Ranade <rohitrranade@huawei.com> wrote:
> 
> 1. In the desrciption of leaf-list tag
>   "
>   The operational view of this list will contain all
>              user-configured tags as well as any predefined tags that
>              have not been masked by the user using the masked-tag leaf
>              list below.
>   "
>   ==> So the predefined tags, should be output as <default> origin  in <operational> ?
>   If so, I would suggest renaming them to "default" tags.

default has this in it's definition:

    "The default origin is only used when the configuration has not been
     provided by any other source."

The predefined tags are being added due to the module definition or by the vendor implementing the module, and the user would be adding to this set (not replacing) when they configure tags (and thus the reason for the mask). So I think predefined tags should have "system" origin. We can add text to the document to clarify this if others agree.

> 2. For "masked-tag", if the purpose is to only mask "predefined" tags, 
> why not rename as masked-default-tag or masked-predefined-tag ?
> Also if a tag say tag-1 (not predefined) is added to this list, and 
> tag-1 added to "tag", the tag-1 will still be output in <operational>, 
> which may look confusing to the user as the tag-1 will exist in both "tag" and "masked-tag". Changing the "masked-tag" may help in this case.

What's the compelling reason to make this more complex? Right now, the predefined tags are added, the configured tags are added, and then the masks are applied. KISS is the goal.

> 3.  It is still not clear, what is the use-case where user wants to "mask" a predefined tag..

The user is the ultimate arbiter over their network is the point. On example is a vendor adds a tag indicating the module belongs to a certain category of modules which would enable it's use in that users network, but for whatever reason the user does not agree.

> 4. What about already existing modules which donot define the tags, should they be output in the
>   "module-tags" list ? Or better to use "min-elements" for leaf-list "tags" ?

If they have no tags, there's no reason for them to be in the list, whether they come before or after the publication of this document (or after a device implements it). However, any client software is going to need to deal with no module entry, and also with an entry with no tags. I think it's better to stay away from adding restrictions that don't add real value, but do allow for software to "get it wrong".

> 5. I also agree with other reviewer's comment that this document must standardize what a module-tag must look like.
>   Currently it only standardizes a prefix, if the rest of the tag is not standardized a client has no way to parse
>   this tag.
>   Maybe we can say that a tag will contain 3 parts, 1st part is about organization, 2nd part is about the whether it is service / element, 3rd part
>   can be a sub-category of part-2.

There's a lot of prior art here in leaving this open to however people want to use the meta-data (see routing admin-tags, media tags, social media tags, etc).. The reservation of prefix space allows for future definition if that ends up being needed. Users are free to define whatever structure they want if any. This discussion in particular was carried out over routing admin tags in the IETF and not pre-defining structure/meaning was the end result and has worked out well.

Thanks,
Chris.

>  
> With Regards,
> Rohit R
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod