> On Oct 17, 2018, at 12:09 AM, Rohit R Ranade <[email protected]> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
