Do you have similar objections over comments in CLI config files? 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?
Regarding the yang library you keep bringing up. This was in the work originally and the WG decided that we should remove it. 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. 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. 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
