> On Nov 14, 2018, at 10:14 AM, Robert Wilton <rwil...@cisco.com> wrote: > > Hi Chris, > > On 14/11/2018 13:46, Christian Hopps wrote: >> Do you have similar objections over comments in CLI config files? > > No, not at all. > > But one difference here is that the tags are bound to modules, not to the > config, or config paths.
This has nothing to do with the point I am addressing that you and Alex raised regarding "Servers not using the tags so why should they store them". 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. And maybe let's put this work on hold until we can find someone that is willing to do all that busy work. I understand more and more why openconfig exists. Thanks, Chris. > >> Routers (the server) certainly don't use those and clients write them and >> read them -- yet they are stored on the server. Perhaps if you thought of >> there being more than just one client possible this might all make more >> sense? > > Yes, perhaps. > > >> >> Regarding the yang library you keep bringing up. This was in the work >> originally and the WG decided that we should remove it. > > Sorry, I had missed the WG discussion where this was removed. But OK. > > >> I do not think the tail end of a WGLC is an appropriate time or place to >> start wondering out loud about whether it would be a good to have. I admit >> to being confused by this since I believe you were actively participating >> WRT this work when it had the yang library augmentation as well as after we >> removed it. > > My apologies, but I had intended to review this more thoroughly during the WG > LC but ran out of time. If was when I read Alex's comments that I thought > that he was raising some valid points. The key one that struck a chord is > that this document describes a solution but doesn't seem to clearly describe > what problem it is solving (other than tags are good), or how it is intending > to be used. When I reviewed this document after reading Alex's comments, I > was asking myself how this was going to be used, and the answer I came up > with was that I didn't really know. Or the case that I had in mind (YANG > catalog filtering on module tag) doesn't seem to match the authors envisaged > use cases. Looking back at some of the previous comments on this work (not > just Alex), others have also questioned what problem it is solving and how it > will be used. > > >> I'm OK with taking the editorial suggestions. I'm not so OK with going back >> and redoing this document or it's fundamental design at the tail end of a >> WGLC. Unless the WG agrees that it's truly broken. This would be pretty odd >> given it seemed like we were done, including during the 103 meeting in which >> you were in attendance. >> >> You say your not trying to hold the work up; however, that is exactly what >> your last minute public pondering is doing. > > Yes, I admit that I should have reviewed it earlier. My aim is not to slow > it down but to ensure that the document is as clear as possible. As I've > said lots of times, I like the idea of tags for classifying YANG modules :-) > > Given all that, it is still my opinion that this document would benefit from > the introduction being slightly clearer on the specific problem being solved > - e.g. I think that the abstract is more clear than the introduction, and > also think that the document would benefit having some examples of how module > tags could be used. > > But I appreciate that my comments are after the WGLC and have no issues if > the authors/chairs decide that they are too late. After all, no one else, > other than Alex, has expressed any concern. > > Thanks, > Rob > > >> >> Thanks, >> Chris. >> >>> On Nov 14, 2018, at 5:04 AM, Robert Wilton <rwil...@cisco.com> wrote: >>> >>> Hi Chris, >>> >>> On 13/11/2018 21:05, Christian Hopps wrote: >>>> The servers implement the modules which can have predefined tags from the >>>> module designer as well as the implementer (vendor) which literally cannot >>>> come from anywhere *but* the server that implements the module. >>> Clients should also be able to know find out the predefined tags from the >>> module definition. I agree that the any tags added by the implementation >>> can only be known by querying the server, although its not obvious to me >>> what those tags would be. E.g. if Cisco had a YANG module for EIGRP and >>> wanted to give it the ietf:protocol and ietf:routing tag then it would >>> ideally use the extension and put it in the YANG file. >>> >>>> This is not what I thought would hold this work up. >>> Sorry, I'm not trying to hold anything up. >>> >>> It not obvious to me how the ietf-module-tags modules will actually be used >>> on a device: >>> 1) being able to ask a device: "What are all the YANG modules that are >>> implemented on this device that are routing protocols" seems a useful thing >>> to do. Although personally I would ideally want the answer in the context >>> of YANG library. I.e. to see the modules with the given tags, along with >>> module evision/version, features and any deviations. This can probably be >>> achieved today with an appropriate xpath query, if supported, or could >>> perhaps be achieved more easily if the operational list of tags also >>> augmented the module entries in the YANG library structure. But perhaps >>> for your envisaged use case just getting back the list of modules with that >>> tag is sufficient and is what you are after. >>> >>> Is this how you are envisaging YANG module tags would be used, and if so, >>> would it do any harm to add a short section near the intro explaining this >>> (and perhaps the YANG catalogue example as well)? Or do you think that >>> this would just be needless noise. >>> >>> 2) Being able to filter queried data based on tags may also be useful, but >>> this would require protocol extensions, perhaps something to be done in >>> future? >>> >>> Thanks, >>> Rob >>> >>> >>>> Thanks, >>>> Chris. >>>> >>>>> On Nov 13, 2018, at 5:58 AM, Robert Wilton <rwil...@cisco.com> wrote: >>>>> >>>>> Hi Joel, authors, >>>>> >>>>> I have to confess that I didn't have time to review this during the last >>>>> call (but have reviewed/provided comments on previous versions). >>>>> >>>>> These comments may be too late, but I will provide them anyway, so make >>>>> of them what you will :-) >>>>> >>>>> In summary, I like the idea of tags and I think that they are a good fit >>>>> for classifying YANG models. In particular, I think that a flexible >>>>> classification of YANG modules is better than a rigid structure that can >>>>> never be changed. >>>>> >>>>> For me the one of the great utilities of module tags could be in >>>>> applications like YANG catalog search >>>>> (https://yangcatalog.org/yang-search/). Being able to search for modules >>>>> by tag seems like it would be a particularly useful thing to be able to >>>>> do. >>>>> >>>>> However, I do have some sympathy with Alex's comment, in that it is a bit >>>>> unclear as to benefits of configuring the tag information on the devices. >>>>> At the moment, the configuration doesn't have any material affect on the >>>>> device, and the only thing that a client can do is read back the tag >>>>> configuration. Is the intention that the protocols may be extended in >>>>> future to allow filter queries to be based on module tags? >>>>> >>>>> So, I am supportive of Alex's comment that it would give the document >>>>> more clarity if some of the specific use cases could be described. >>>>> >>>>> >>>>> Some other random comments/nits: >>>>> >>>>> 1) 6087bis references can be updated to RFC 8407. Is a reference even >>>>> allowed in the abstract? >>>>> >>>>> 2) Abstract: "writing a modules tags" => "writing a module's tags" or >>>>> "writing module tags" >>>>> >>>>> 3) The module is YANG 1.1, so RFC 6020 reference can be changed to RFC >>>>> 7950. >>>>> >>>>> 4) Section 3.4: Should there be a tag prefix for "experimental"? Or >>>>> perhaps this would be "ietf:experimental:<tag-name>" anyway. >>>>> >>>>> 5) Section 5.1: It might be useful if the tags were also reported under >>>>> YANG library, e.g. as an augmentation to rfc7895bis. E.g. this would >>>>> report the same information as "modules-tags/module[name]/tag" leaf-list. >>>>> >>>>> 6) YANG module: Should you limit the maximum size of a tag? Perhaps to >>>>> 255, or 1000 characters. >>>>> >>>>> 7) Line length for "The operational view of this list is constructed ..." >>>>> looks like it may be too long. >>>>> >>>>> 8) Section 7, Guidelines to authors. I was wondering if this section >>>>> should state that YANG modules SHOULD define standard tags that are >>>>> associated with it. At the moment, it just states what can be done, >>>>> without providing guidance of what should be done. >>>>> >>>>> 9) Section 9.2. A few more possible categories: discovery protocol, vpn, >>>>> tunnel. I'm not sure that I particularly like "rfc8199-" as a module >>>>> name, and possibly "classification-" would be better. >>>>> >>>>> Apologies for the tardy review comments, >>>>> Rob >>>>> >>>>> >>>>> On 12/11/2018 16:46, joel jaeggli wrote: >>>>>> During the Thursday nov 8 session of netmod, we asked if there were any >>>>>> objections to the publication of the Draft-03 version of >>>>>> draft-ietf-netmod-module-tags which addresses comments and concerns >>>>>> raised during the WGLC. In the meeting there were none. This commences a >>>>>> comment period to confirm that call. As this follows closely on the >>>>>> heels of the IETF 103 meeting we’ll let the call run through Monday the >>>>>> 26th of November. >>>>>> >>>>>> https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-module-tags-03.txt >>>>>> >>>>>> >>>>>> Thanks >>>>>> Joel >>>>>> _______________________________________________ >>>>>> 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
