This WG LC closed on the 16th. Working group last calls serve a useful forcing function even for drafts that may end up looking unready as a result due to the attention. If I am making a judgement call here based on the feedback received during this period and the prior one.
I will try and summarize the major concerns that see expressed with this draft. Jurgen had a significant list of comments and edits https://mailarchive.ietf.org/arch/msg/netmod/qUGyGIxHJKsEXZsG6r3P7R0nirg <https://mailarchive.ietf.org/arch/msg/netmod/qUGyGIxHJKsEXZsG6r3P7R0nirg> Followed up by Christian One detail teased out there and in other comments bears revisting Juergen > I do not like this. YANG has extension statements and having to > parse stuff out of free text description statements seems to be a > movement backwards. Christian This is used by the human implementer of the module (i.e., they need to write code to implement the module). As such it was not intended for machine parsing. Juergon I am personally not convinced. The whole reason why we have YANG is automation and I believe people will go and write tools to extract tags and having to extract them out of free form text looks like a step backwards. Andy It is more than a step backwards. There is an unexplained procedure for declaring the module-tag conformance, in addition to the module-tag mappings. Alex I have no issue with systems using tags to classify or organize modules, however this seems to me like something that would be specific to the system doing the classifying. It would not be something that needs to be specified in the module itself (except perhaps as freeform description text), and it certainly would not need to involve the NETCONF server. What would a server do with module classification data? (unless it is also implementing some kind of module browsing interface, in which case it might be used to supply the browser with data) Wether or not this is intended for or will be parsed by machines remains a significant unresolved concern. The actual mechanics of restricting what goes into them however seems fairly straight forward. Absent consensus on the above concern this document cannot probably advance, we do have the opportunity for significant face to face discussion in the near future so using that to arrive at a conclusion would probably allow this work to progress or stop. Thanks Joel > On Oct 2, 2018, at 13:21, joel jaeggli <joe...@bogus.jcom> wrote: > > This is start of a two week working group last-call for > draft-ietf-netmod-module-tags-02 a current netmod working group > document. > > You may review at: > https://tools.ietf.org/html/draft-ietf-netmod-module-tags-02 > > Please send email to the list indicating "yes/support" or "no/do not > support". If indicating no, please state your reservations with the > document. If yes, please also feel free to provide comments you'd like > to see addressed once the document is a WG document. > > The prior discussion of my mistaken WG adoption call is here > > commences here: > > https://www.ietf.org/mail-archive/web/netmod/current/msg21290.html > > In particular Andy's concerns expressed in that thread here: > > https://www.ietf.org/mail-archive/web/netmod/current/msg21348.html > > are probably important to tease out in considering this for last call. > > so that we are clear on dates. This last call timing resets and runs > from 10/2/18 - 10/16/18 > > 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
