Christian Hopps <cho...@chopps.org> wrote: > > > > On Oct 17, 2018, at 12:09 AM, Rohit R Ranade <rohitrran...@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.
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 > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
