Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18

[Christian Hopps <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod