Hi Joel, WG, I published a new draft some days ago covering the specific concerns and editorial changes requested during WGLC. This included the addition of an extension statement which covered machine parsing of pre-defined tags which was mentioned by multiple people, and is the only significant change made. I would think we'd have rough consensus (at least) at this point.
I do not agree that we should restrict the usefulness of this work by removing the ability of the module author or the vendor/implementer to add tags due to a single persons view of how they might use the technology. There's nothing gained, and there's obvious loss of functionality. Thanks, Chris. > On Oct 25, 2018, at 3:05 AM, Joel Jaeggli <joe...@bogus.com> wrote: > > 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 > > 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
