Re: [yang-doctors] YANG dialects?

[Ladislav Lhotka <[e-mail]>]

On Thu, 2019-12-19 at 09:07 +0100, Martin Bjorklund wrote:
> Andy Bierman <[e-mail]> wrote:
> > On Wed, Dec 18, 2019 at 1:01 PM Martin Bjorklund <[e-mail]> wrote:
> > 
> > > Andy Bierman <[e-mail]> 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.

I don't think it is legal, because

o  extension: An extension attaches non-YANG semantics to statements.

This is not the case here, it is only syntactically compatible. If tool A says
that some instance data is valid, but tool B says it isn't, then the standard is
gone.

Lada

> 
> > (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
> 
> _______________________________________________
> yang-doctors mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/yang-doctors
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67