Re: [yang-doctors] YANG dialects?

Martin Bjorklund <mbj@tail-f.com> Thu, 19 December 2019 08:07 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 CF574120096 for <yang-doctors@ietfa.amsl.com>; Thu, 19 Dec 2019 00:07:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 sq0zAtNuTZIt for <yang-doctors@ietfa.amsl.com>; Thu, 19 Dec 2019 00:07:46 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 40235120046 for <yang-doctors@ietf.org>; Thu, 19 Dec 2019 00:07:46 -0800 (PST)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id 717791AE02AA; Thu, 19 Dec 2019 09:07:44 +0100 (CET)
Date: Thu, 19 Dec 2019 09:07:08 +0100
Message-Id: <20191219.090708.1031388562992503497.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: yang-doctors@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHRfNrz+cNMA8ciRYGEM-7aR=S2NYJzU-t8JQ620Zs=hvQ@mail.gmail.com>
References: <CABCOCHTB+V6sV8hRcAC+OfseBBN=jUQnHQxzEVB_1drWhaEVXg@mail.gmail.com> <20191218.220130.545256750871048075.mbj@tail-f.com> <CABCOCHRfNrz+cNMA8ciRYGEM-7aR=S2NYJzU-t8JQ620Zs=hvQ@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/7vkldv_3voQR5oyF2Oi5D7fDpQY>
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: Thu, 19 Dec 2019 08:07:49 -0000

Andy Bierman <andy@yumaworks.com> wrote:
> On Wed, Dec 18, 2019 at 1:01 PM Martin Bjorklund <mbj@tail-f.com> wrote:
> 
> > 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.
> >
> >
> OK
> 
> 
> 
> > > 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.
> >
> >
> >
> 
> Not so easy for all of them.
> (1)
> The pattern-stmt disaster cannot be addressed.

I think the solution is trivial, and it has been proposed to
OpenConfig - introduce a new extension statement oc:posix-pattern.
This will make the modules *legal*, and tools can use existing
mechanisms to deal (or not) with this new statement.

> (2)
> I see the config=false access issue in ietf-if-extensions@2019-11-04 and
> ietf-if-l3-vlan@2019-11-04
> 
> 
>       container dot1q-vlan {
>         must
>           'count(../../if-ext:forwarding-mode) = 0 or ' +
>           'derived-from-or-self(../../if-ext:forwarding-mode,' +
>                                 '"if-ext:layer-3-forwarding")' {
> 
> 
> forwarding-mode is config=false
> 
> I am trying to compile ietf-routing-policy and eventually ietf-bgp.
> 3 different compilers are giving 3 different answers for
> ietf-routing-policy,
> related to this dot1q-vlan container.

Hmm, I need to look at why neither pyang nor yanger detects this.  It
should give a warning that the must expression always evaluates to
true.

> (3)
> Users want to specify identities without the prefixes.
> Should tools allow it or follow YANG rules?

Up to you.  But if the expression is on the form:

   "id-node = 'foo'"

and it should have been:

   "id-node = 'f:foo'"


then it is probably not that easy to "just accept it", since the XPath
evaluator will evaluate the LHS and get a string which is the string
value of the "id-node" leaf.  Either this string value contains a
prefix or it doesn't (7950 says it does).  Then it will evaluate the
RHS and get the string 'foo', and then compare these two strings.

So if you change the string value of "id-node" to not contain the
prefix, you may run into problems in other must expressions.  Or you
do some other clever trick to handle this, but again, up to the tool
imo.



/martin


> From XPath POV it is just a string literal.
> I know they are supposed to use derived-from (or-self) but they don't
> follow that rule either.
> 
> 
> /martin
> >
> >
> Andy
> 
> 
> >
> >
> > >
> > > For starters, can somebody explain the different rules pyang is checking
> > > here?
> > >
> > >
> > > Andy
> >