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

Joel Jaeggli <joelja@bogus.com> Thu, 25 October 2018 22:57 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89AC128D0C for <netmod@ietfa.amsl.com>; Thu, 25 Oct 2018 15:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPXayMZ8tLuy for <netmod@ietfa.amsl.com>; Thu, 25 Oct 2018 15:57:33 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F8D1127B92 for <netmod@ietf.org>; Thu, 25 Oct 2018 15:57:33 -0700 (PDT)
Received: from [IPv6:2601:647:4201:4561:9d71:513b:3d3d:8dbc] ([IPv6:2601:647:4201:4561:9d71:513b:3d3d:8dbc]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w9PMvUNL039005; Thu, 25 Oct 2018 22:57:31 GMT (envelope-from joelja@bogus.com)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Joel Jaeggli <joelja@bogus.com>
In-Reply-To: <BE6CFAA6-AE2A-4533-969F-FBF631CFD3BF@chopps.org>
Date: Thu, 25 Oct 2018 15:57:30 -0700
Cc: NETMOD Working Group <netmod@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E5893DF-2CA4-4E2A-9CF5-ABCF78620707@bogus.com>
References: <b45d1c39-c2f0-bcaf-61a4-9822ac04725a@bogus.com> <69F1E71B-CD7C-453A-AB78-C4F74AD0CC5E@bogus.com> <BE6CFAA6-AE2A-4533-969F-FBF631CFD3BF@chopps.org>
To: Christian Hopps <chopps@chopps.org>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Escnn8umkVUob0knBs60Fy9MD5s>
Subject: Re: [netmod] WG LC draft-ietf-netmod-module-tags-02 - 10/2/18 - 10/16/18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Oct 2018 22:57:36 -0000


> On Oct 25, 2018, at 06:12, Christian Hopps <chopps@chopps.org> wrote:
> 
> 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.

Yes, I don’t think we need to belabor the edits since I think that discussion tailed of to a reasonable conclusion.

> 
> 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.

I’m trying not to inject my own opinion into prejudging an outcome here. 

I do see it as significant point of contention in the working group last call. If I were asking for consensus on the point specifically I do not believe that we have arrived at a point of rough consensus yet.

> Thanks,

Thanks for getting us to this point.

Joel

> Chris.
> 
>> On Oct 25, 2018, at 3:05 AM, Joel Jaeggli <joelja@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 <joelja@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
> 
>