Re: [netmod] Module tags

[Robert Wilton <[e-mail]>]

On 13/02/2017 18:19, Kent Watsen wrote:
> As for a concrete use-case, would something like this be helpful
> for a server to indicate which datastores a module is supported in?
I'm not sure.  I would probably prefer to see the two kept separate, but 
it may depend on what the scope of modules tags ends up being.

Rob

>
> I'm thinking specifically about the revised-datastores draft where
> we've discussed that a module might exist in just oper-state,
> oper-state + ephemeral, oper-state + ephemeral + running, etc.
>
>
> Kent // as a contributor
>
>
>
>
> Hi tags draft authors,
>
> On 09/02/2017 12:28, Lou Berger wrote:
>> I'm personally more excited by the use of tags as additional module
>> meta-data accessible via yang library. But also see no reason to
>> preclude this possible  (even if unlikely) usage.
> When the idea of tags was presented as IETF, I had assumed that tags
> would be versioned/managed entirely independently from the YANG modules
> that the tags apply to.
>
> For a while, there was a desire to organize YANG modules by their
> hierarchical path location in the schema tree.  My concern with this
> approach, is that there needs to be sufficient foresight to get that
> structure right now, because it will be very painful to change it in
> future.  Unfortunately things have a habit of evolving over time, and
> hence choosing the right structure now such that is still the right
> structure in 25 years seems somewhat unlikely.
>
> I was thinking that tags offers a better solution to this problem, that
> allows the structure to be a bit more dynamic, evolving over time.  I.e.
> YANG modules for features can sit at (or near to) the top level of the
> schema tree, and tags can then be used to group those modules into
> sensible organizations that can evolve, so that when clients are trying
> to sort through all the different YANG models that are available, they
> have more hope than looking at a flat list.
>
> In this scenario, I think that it is better if the YANG module
> definitions themselves don't specify the tags because then
> adding/removing/changing them is going to be a pain.  If this tag
> information was managed separately (e.g. in something like YANG catalog)
> then it seems easier for the tags to evolve over time.
>
> But I also had not really realized that the tags information would
> necessarily reach down to the devices.  I.e. I hadn't envisaged Chris's
> example of querying the hello-time via an IGP package tag. Instead, I
> had thought of tags making a YANG catalog website more useful.  E.g.
> when browsing for YANG modules, be able to restrict the query to just
> the modules that are tagged as "standard" + "IGP", etc.
>
> So, I think that this draft may benefit with a bit more description of
> the envisaged use cases, and also about how tags are envisaged to evolve
> once they have been defined.
>
> Thanks,
> Rob
>
>> Lou
>>
>>
>>> Thanks,
>>> Chris.
>>
>> _______________________________________________
>> netmod mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>
>