Re: [yang-doctors] YANG dialects?

Martin Bjorklund <mbj@tail-f.com> Wed, 18 December 2019 21:01 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 8A62E120B1D for <yang-doctors@ietfa.amsl.com>; Wed, 18 Dec 2019 13:01:33 -0800 (PST)
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_HELO_NONE=0.001, 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 Vg_u9l9fPhUK for <yang-doctors@ietfa.amsl.com>; Wed, 18 Dec 2019 13:01:31 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A748D1208AA for <yang-doctors@ietf.org>; Wed, 18 Dec 2019 13:01:31 -0800 (PST)
Received: from localhost (h-4-44.A165.priv.bahnhof.se [158.174.4.44]) by mail.tail-f.com (Postfix) with ESMTPSA id 7EB771AE02A7; Wed, 18 Dec 2019 22:01:30 +0100 (CET)
Date: Wed, 18 Dec 2019 22:01:30 +0100
Message-Id: <20191218.220130.545256750871048075.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: yang-doctors@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHTB+V6sV8hRcAC+OfseBBN=jUQnHQxzEVB_1drWhaEVXg@mail.gmail.com>
References: <CABCOCHTB+V6sV8hRcAC+OfseBBN=jUQnHQxzEVB_1drWhaEVXg@mail.gmail.com>
X-Mailer: Mew version 6.8 on Emacs 25.2
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/F1ePg9MJBaEraS6nC6JUqo3iouU>
Subject: Re: [yang-doctors] YANG dialects?
X-BeenThere: yang-doctors@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 18 Dec 2019 21:01:34 -0000

Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
> 
> I noticed in the help output for pyang 2.1:
> 
>   --mef                 Validate the module(s) according to MEF rules.
>   --ieee                Validate the module(s) according to IEEE rules.
>   --ietf                Validate the module(s) according to IETF rules.
>   --bbf                 Validate the module(s) according to BBF rules.
>   --lint                Validate the module(s) according to RFC 8407rules.
> 
> 
> I guess --openconfig is missing (since they have their own rules for YANG
> as well)
> 
> I hope these different rules are for style only, and not redefining YANG.

Right, these are style rules.  Note the help text for "--lint" - it
verifies the rules defined in RFC 8407.

All the others invokes --lint, and in addtion validates module names
and namespaces (e.g. --ietf checks that the module is called "ietf-*"
ot "iana-*").

> I suspect it is more than that.

No, not for these validators.

> I am aware of at least 3 openconfig issues that do not follow YANG rules:
>    - repurposing pattern-stmt to use a different syntax
>    - referencing config=false nodes from config=true context node for
> when-stmts
>    - use of identity strings without prefixes in XPath, where the default
> module does
>      not contain the identity (it is in an imported module instead)
> 
> Should we just continue hacking the tools in proprietary ways to deal with
> the inconsistencies? Are there any issues the IETF (or YANG doctors)
> could or should address?

These module are published and are being used.  Vendors that want to
use them will have to work around the problems.  There's nothing we
(the IETF) can do about them.  However, it is trivial to fix all these
issues so that the modules are valid YANG, but it doesn't seem this is
high on OpenConfig's priority list.


/martin



> 
> For starters, can somebody explain the different rules pyang is checking
> here?
> 
> 
> Andy