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

[Martin Bjorklund <[e-mail]>]

Christian Hopps <[e-mail]> wrote:
> 
> 
> > On Oct 17, 2018, at 12:09 AM, Rohit R Ranade <[e-mail]>
> > 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.

I agree that the origin should be "system" for these tags.

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

But this is not what the draft says.  The description of masked-tag
says that predefined tags are removed.

Keep it simple, but make sure the description is clear.  So maybe add
your 3 steps above to the draft, and remove the word "predefined" from
the description of masked-tag.


/martin


> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>