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 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 > 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
