Robert Wilton <[email protected]> writes: > 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. Well they are called "tags" after all. Normally one applies a tag to something (i.e., tags it. :) > 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. We in fact plan to do this with the device meta model. I believe this was in the presentation too, but it might not have been very obvious. > 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. I want to be sure I understand you here. We've defined 3 places that a tag could be defined (comes into existence), the module designer, the vendor and the local user. When you say "module defines" are you talking about the first case, or are you talking about where a tag resides after it is created? For the latter that was our intention with the yang library augmentation. For the former case consider e.g., IS-IS, I think the authors of that module know and are the appropriate folks to add categorization tags such as "ietf:routing", "ietf:protocol", "ietf:routing:igp" or whatever. Nothing would keep the user or vendor from removing these or adding their own tags for the same purpose as well if they found these inappropriate or incorrect. > 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. Well one goal I had with tags was to allow for them to be used in the future in ways we may not have anticipated. Therefore we specifically did not lock down how they are used or what they are used for. That said, examples of how one might use could be helpful. Thanks, Chris. > Thanks, > Rob > >> >> Lou >> >> >>> Thanks, >>> Chris. >> >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod >> . >>
signature.asc
Description: PGP signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
