Re: [yang-doctors] automating yang doctor reviews

Christian Hopps <> Tue, 15 May 2018 07:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 10980127023 for <>; Tue, 15 May 2018 00:29:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9ddzcAHSPPKn for <>; Tue, 15 May 2018 00:29:17 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 39F8E12D778 for <>; Tue, 15 May 2018 00:29:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 7EA9460B2F; Tue, 15 May 2018 07:29:16 +0000 (UTC)
References: <> <>
User-agent: mu4e 1.0; emacs 25.3.1
From: Christian Hopps <>
To: Martin Bjorklund <>
In-reply-to: <>
Date: Tue, 15 May 2018 03:29:15 -0400
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: <>
Subject: Re: [yang-doctors] automating yang doctor reviews
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Email list of the yang-doctors directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 May 2018 07:29:19 -0000

Martin Bjorklund <> writes:

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

Actually I'm guessing there are many people that would not think to automate any of this, or would not be comfortable enough with make to do so if hinted at. :)

The tree diagrams should be able to be automatically generated without specific commands though, given a module name and optional path to the root of the sub-tree to insert.

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

Well we could simply replace "\s*...\s*" with an empty string, and document that we will do so. :)

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

I think another person mentioned that the document can change after yang doctor review. In any case it can't hurt to have a set of tools that automatically test as much as possible for authors, submission, reviewers and prior to publication.


> 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 <> 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
> _______________________________________________
> yang-doctors mailing list