Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams

Vladimir Vassilev <vladimir@transpacket.com> Wed, 17 January 2018 09:08 UTC

Return-Path: <vladimir@transpacket.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 B0E1012FAA8 for <netmod@ietfa.amsl.com>; Wed, 17 Jan 2018 01:08:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 cPjNbrTAgLS0 for <netmod@ietfa.amsl.com>; Wed, 17 Jan 2018 01:08:09 -0800 (PST)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A63AD12EB6B for <netmod@ietf.org>; Wed, 17 Jan 2018 01:08:09 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id D4A4414620BF; Wed, 17 Jan 2018 10:08:03 +0100 (CET)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id vfioZH7y-bFN; Wed, 17 Jan 2018 10:08:03 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id AB67614620D4; Wed, 17 Jan 2018 10:08:03 +0100 (CET)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id axRBhy5QK7RB; Wed, 17 Jan 2018 10:08:03 +0100 (CET)
Received: from [192.168.43.32] (77.16.194.13.tmi.telenormobil.no [77.16.194.13]) by mail.transpacket.com (Postfix) with ESMTPSA id 65F9914620BF; Wed, 17 Jan 2018 10:08:03 +0100 (CET)
To: joel jaeggli <joelja@bogus.com>, Robert Wilton <rwilton@cisco.com>, Martin Bjorklund <mbj@tail-f.com>, netmod@ietf.org
References: <aa7a1449-fd6e-e4c6-7568-41061c09d9f2@transpacket.com> <20180116.115606.561861432247288407.mbj@tail-f.com> <e94d1ed3-e859-3167-501f-ce23e77804df@transpacket.com> <20180116.164053.2123534827829006518.mbj@tail-f.com> <e63efa9f-3114-d59d-e1d8-e62602a830c5@cisco.com> <a2c75af7-c5b9-f277-1d04-5891dc97c0d2@bogus.com> <2585727d-80df-a4bc-e1e5-64f4575aac9f@transpacket.com> <20180116200636.w437ttcwyqswnj2t@elstar.local>
From: Vladimir Vassilev <vladimir@transpacket.com>
Message-ID: <a7b39bd9-4e9a-e4b0-0e46-904645edf5f3@transpacket.com>
Date: Wed, 17 Jan 2018 10:08:02 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20180116200636.w437ttcwyqswnj2t@elstar.local>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: nb
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/PP8YeGE85lYOBO2oDm6NLPWfV-A>
Subject: Re: [netmod] WGLC - draft-ietf-netmod-yang-tree-diagrams
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 17 Jan 2018 09:08:11 -0000


On 01/16/2018 09:06 PM, Juergen Schoenwaelder wrote:
> On Tue, Jan 16, 2018 at 08:19:38PM +0100, Vladimir Vassilev wrote:
>> As for the automated validation of the tree diagrams as an added value to
>> the human readability I have the following thoughts. I would like to be able
>> to compare unlimited line length tree outputs generated by different YANG
>> compilers for equality. This is mainly a way to have some partial common
>> denominator output for validating YANG is correctly compiled which we did
>> not have until now. For example as soon as I have support for Schema mount I
>> would compare the tree output with another tool known to work and add some
>> testcases based on that. I do not see any automated alternative for doing
>> this except writing NETCONF chat scripts (also module specific), or writing
>> not only YANG module specific but also API specific test cases as 3rd
>> option. 1) does not compromise this automated validation option since space
>> sequences can be collapsed to single space. If the alignment algorithm was
>> creating a possibility for nontrivial output variation then I would have
>> supported strongly 3) but this is not the current case.
>>
> If you want to make sure a YANG compiler is correct, simply write a
> backend that generates a serialized YANG module in canonical
> form. They YANG modules should be the same. Determining YANG compiler
> correctness by comparing tree diagrams does not seem to be a
> convincing approach since tree diagrams by design leave many details
> out.
The advantage I see is that 'uses' and 'augments' are resolved in the 
tree output. For example one can not cach bug in the reolution of the 
configure flag in a uses expanded under case with "configure false;" by 
generating YANG with unresolved 'uses'.  Another example - one can not 
represent the result of multiple modules augmenting e.g. /interfaces 
with a YANG module. The only universal representation is the YANG tree.

Vladimir
> /js
>