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.
This is not what I thought would hold this work up. Thanks, Chris. > On Nov 13, 2018, at 5:58 AM, Robert Wilton <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
