Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call

[joel jaeggli <[e-mail]>]

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 <[e-mail]> 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
> 
>