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

Christian Hopps <chopps@chopps.org> Tue, 16 October 2018 19:42 UTC

Return-Path: <chopps@chopps.org>
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 A5DC8130E3B for <netmod@ietfa.amsl.com>; Tue, 16 Oct 2018 12:42:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 alHG6GNhzcj9 for <netmod@ietfa.amsl.com>; Tue, 16 Oct 2018 12:42:50 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 97163130E36 for <netmod@ietf.org>; Tue, 16 Oct 2018 12:42:50 -0700 (PDT)
Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 7B55F6005A; Tue, 16 Oct 2018 19:42:49 +0000 (UTC)
References: <b45d1c39-c2f0-bcaf-61a4-9822ac04725a@bogus.com> <20181002203031.pcdclhq7vb5tohrj@anna.jacobs.jacobs-university.de> <57BCB4D8-D82F-43C9-8D05-2F52A174F37C@chopps.org> <20181016130829.3jnbnxyb5vjlogih@anna.jacobs.jacobs-university.de> <CABCOCHTZ6Vj+5WxmAXQLVCEQ3AP95RbYtvCqh0PtsuUdaANM8A@mail.gmail.com>
User-agent: mu4e 1.0; emacs 26.1
From: Christian Hopps <chopps@chopps.org>
To: Andy Bierman <andy@yumaworks.com>
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Christian Hopps <chopps@chopps.org>, joel jaeggli <joelja@bogus.com>, NETMOD Working Group <netmod@ietf.org>
In-reply-to: <CABCOCHTZ6Vj+5WxmAXQLVCEQ3AP95RbYtvCqh0PtsuUdaANM8A@mail.gmail.com>
Date: Tue, 16 Oct 2018 15:42:48 -0400
Message-ID: <sa64ldl8ypz.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/wo2CEzzYSjYRB_iwY_L4GLCCMaw>
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: Tue, 16 Oct 2018 19:42:53 -0000

Andy Bierman <andy@yumaworks.com> writes:

> On Tue, Oct 16, 2018 at 6:08 AM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
>
>> On Tue, Oct 16, 2018 at 08:31:43AM -0400, Christian Hopps wrote:
>> >
>> > On Oct 2, 2018, at 4:30 PM, Juergen Schoenwaelder <
>> j.schoenwaelder@jacobs-university.de> wrote:
>>
>> > > - Standard tags defined in description statements
>> > >
>> > >  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.
>> >
>> > 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.
>> >
>>
>> 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.
>>
>
>
> 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.
>
> All YANG designers are supposed to learn the exact text to write (not
> free-form at all)
> and this draft updates 6087bis with procedures for declaring the module-tags
> in the description-stmt.
>
> Also, tool developers are supposed to parse the description-stmt looking
> for the
> module-tag definitions. But instead, tool developers are going to say "Use
> our
> proprietary YANG extension because we are never going to parse description
> statements"

I've added the extension statement.

>> > > - System management
>> > >
>> > >  What is 'system management' and a 'system management protocol'?
>> >
>> > These were derived from the work the RtgYangDT originally did where we
>> were organizing everything under a single device tree. This tree concept
>> was (rightly) abandoned to be replaced with use of tags. Examples of
>> protocols would be Syslog, TACAC+, SNMP, Netconf, ... I've added that to
>> the description.
>> >
>>
>> I am generally not a fan of definition by example. Is SSH a 'system
>> management protocol'?
>>
>
>
> An example is not a definition.
> The IETF is supposed to know the difference.

Do you have some suggestions for text that could replace the examples?

Some of these things seem painful obvious, like do we *really* need to define what we mean by a routing protocol?

Thanks,
Chris.