Re: [yang-doctors] automating yang doctor reviews

Martin Bjorklund <mbj@tail-f.com> Tue, 24 April 2018 20:57 UTC

Return-Path: <mbj@tail-f.com>
X-Original-To: yang-doctors@ietfa.amsl.com
Delivered-To: yang-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E55012DA08 for <yang-doctors@ietfa.amsl.com>; Tue, 24 Apr 2018 13:57:22 -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, SPF_PASS=-0.001, 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 yqiya-GFan5N for <yang-doctors@ietfa.amsl.com>; Tue, 24 Apr 2018 13:57:20 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8A93A12DA3D for <yang-doctors@ietf.org>; Tue, 24 Apr 2018 13:57:08 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id EF0751AE0471; Tue, 24 Apr 2018 22:57:06 +0200 (CEST)
Date: Tue, 24 Apr 2018 22:57:03 +0200 (CEST)
Message-Id: <20180424.225703.1856993049395921058.mbj@tail-f.com>
To: kwatsen@juniper.net
Cc: yang-doctors@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <FF0CC106-9C22-4E09-8940-E759753D0AC0@juniper.net>
References: <FF0CC106-9C22-4E09-8940-E759753D0AC0@juniper.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/yang-doctors/j_LcimSX3wHHu-b029Ei4YWCTHE>
Subject: Re: [yang-doctors] automating yang doctor reviews
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Email list of the yang-doctors directorate <yang-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/yang-doctors/>
List-Post: <mailto:yang-doctors@ietf.org>
List-Help: <mailto:yang-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/yang-doctors>, <mailto:yang-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Apr 2018 20:57:23 -0000

Hi Kent,

While I appreciate the effort, I'm not sure this will actually make
the YANG doctor's job any easier.  For example, re including the
command to generate the tree diagram - if people knew how to do this
properly, they could as easily write a Makefile (or similar) that
always generate the diagram so that the tree diagram is always up to
date.  But we know that this is not the case.  So why do we think that
the addition of the 'gen' attribute will make people produce good
drafts?

Also, I'm not sure it helps to include specific commands like this --
what it tells me as a YD is that the probability that the examples
validate is somewhat higher than w/o this attribute.  It does not tell
me that the examples are valid.

And sometimes examples and tree diagrams are manually edited for
formatting reason (e.g., replace chunks of noise with "...").   This
is difficult to capture formally, and people will still have to
validate examples.

As have been pointed out, there is often dependencies to other
modules; capturing all this seems a bit tricky.  And the question is
what problem is actually solves.

Another approach might be to encourage people to keep their draft work
on github, have separate files for examples, use 'make' to generate
tree diagrams and to validate examples.  This is less formal, but
achieves the same goal.


/martin



Kent Watsen <kwatsen@juniper.net>; wrote:
> 
> Doctors,
> 
> Here's a stab at how we might automate the basic parts of a YANG
> Doctor review, something I've mentioned wanting at the YD-lunch
> meeting at the last two IETF meetings.
> 
> I'll be the first to say that this proposal has issues, but hopefully
> it's in the ballpark, and we can finish it off together, assuming
> there is interest in bringing it forward at all...
> 
> Note, I assume that this document will be AD-sponsored, just like RFC
> 7991 was, hence why the draft name is what it is.
> 
> PS: I'm falling into a black hole, and may not reply to any responses
> until early next week.
> 
> Kent
>  
>