Something like the text below addresses the question of guidance. I think we get a better draft if we close off this discussion on the list.
I think the question about where the tags reside generally is settled. Thanks joel > On Nov 14, 2018, at 09:26, Robert Wilton <[email protected]> wrote: > > >> >> The answer is: >> >> 1) B/c there's literally no where else they could be stored (no way for a >> vendor to add tags) >> 2) There are other examples of servers storing things they don't use like >> comments, so "server not using what it stores" isn't a reason to not store >> them on the server in the first place. >> >> Regarding the rest. Maybe we should write a requirements draft and a use >> cases draft for the use of meta-data/tags for organizing things. > That is not what I was suggesting. > > I was suggesting text something like this: > > Introduction: > > OLD: > > The use of tags for classification and organization is fairly > ubiquitous not only within IETF protocols, but in the internet itself > (e.g., #hashtags). Tags can be usefully standardized, but they can > also serve as a non-standardized mechanism available for users to > define themselves. Our solution provides for both cases allowing for > the most flexibility. In particular, tags may be standardized as > well as assigned during module definition; assigned by > implementations; or dynamically defined and set by users. > > NEW: > > The use of tags for classification and organization is fairly > ubiquitous not only within IETF protocols, but in the internet itself > (e.g., #hashtags). One benefit of using tags for organization > over a rigid structure is that it is more flexible and can more easily > adapt over time as technologies evolve. Tags can be usefully > standardized, but they can also serve as a non-standardized mechanism > available for users to define themselves. This document provides a > mechanism to define tags and associate them with YANG modules in a > flexible manner. In particular, tags may be standardized as > well as assigned during module definition; assigned by > implementations; or dynamically defined and set by users. > > > NEW: > > 1.1 Some example use cases of YANG module tags > > Tags can be used to help filter different discrete categories of YANG > modules supported by a device. E.g., if modules are suitably tagged, > then an XPath query can be used to list all of the vendor modules > supported by a device. > > Tags can also be used to help coordination when multiple > semi-independent clients are interacting with the same devices. E.g., > one management client could mark that some modules should not be used > because they have not been verified to behave correctly, so that other > management clients avoid querying the data associated with those > modules. > > Tag classification is useful for users searching module repositories > (e.g. YANG catalog). A query restricted to the 'ietf:routing' module > tag could be used to return only the IETF YANG modules associated with > routing. Without tags, a user would need to know the name of all > the IETF routing protocol YANG modules. > > Future management protocol extensions could allow for filtering > queries of configuration or operational state on a server based on > tags. E.g., return all operational state related to system-management. > > > If you think that this text is helpful, and it allowed, then please add it, > refining as required. If you think that it detracts from the clarify of > document, and is superfluous then leave it out, that is also fine with me ... > > Thanks, > Rob > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
