Subject: [yang-doctors] YANG dialects?

From: Andy Bierman <[email-masked]>
Date: Wed, 18 Dec 2019 11:27:37 -0800

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.
I suspect it is more than that.

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?

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

Andy

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 18 Dec 2019 12:10:30 -0800

> On Dec 18, 2019, at 11:27 AM, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 
> I guess --openconfig is missing (since they have their own rules for YANG as well)
> 
> I suspect it is more than that..

—mef and —ieee were added because those two use namespaces whose syntax is different from ietf. I suspect the same is true for —bbf. There are no other changes/redefinitions of YANG for those models.

Cheers.

>    - 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
> For starters, can somebody explain the different rules pyang is checking here?
> 
> 
> Andy
> 
> 
> 
> 
> _______________________________________________
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors

Mahesh Jethanandani
[email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 18 Dec 2019 22:01:30 +0100 (CET)

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

> the inconsistencies? Are there any issues the IETF (or YANG doctors)

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

---

From: Andy Bierman <[email-masked]>
Date: Wed, 18 Dec 2019 14:58:41 -0800

> No, not for these validators.
OK

> high on OpenConfig's priority list.

Not so easy for all of them.
(1)
The pattern-stmt disaster cannot be addressed.

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

(3)
Users want to specify identities without the prefixes.
Should tools allow it or follow YANG rules?
>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

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 19 Dec 2019 09:07:08 +0100 (CET)

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

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

> 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: Ladislav Lhotka <[email-masked]>
Date: Thu, 19 Dec 2019 17:44:56 +0100

> 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

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Thu, 19 Dec 2019 17:02:21 +0000

> that some instance data is valid, but tool B says it isn't, then the standard is

Right now, things are even worse. If they were defining an extension
and they would update their modules and tools to use it and they would
fix the pattern in the pattern statements to comply to RFCs, things
would be much better. But somehow I doubt any of this will happen
since they could have done all this already years ago.

/js
 
-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 19 Dec 2019 17:18:43 +0000

> -----Original Message-----
> From: yang-doctors <[email-masked]> On Behalf Of Martin
> Bjorklund
> Sent: 19 December 2019 08:07
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [yang-doctors] YANG dialects?
> 
> > > > 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?
> > >
> > > (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.
> > >
> > >
> > >
> >
> 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.

But, as I understand it, the regex implementations are not POSIX either.  E.g. I think that they are using RE2 for Go, which is somewhat derived from PCRE which is derived from POSIX regex, but not exactly compatible either.

So, it would end up replacing one regex language that can't be 100% directly implemented with another regex language that can't be 100% directly implemented.  This seems to make the life more complex not less.

I still believe that the only solution is to define as subset of XML regex that can easily be translated into common regex engines.  Although, as Juergen has stated previously, this effectively defines a new regex language ...

> > ietf-routing-policy, related to this dot1q-vlan container.
> 
> should give a warning that the must expression always evaluates to true.

This is obviously just a bug that needs to be fixed!

Thanks,
Rob

> 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: Ebben Aries <[email-masked]>
Date: Thu, 19 Dec 2019 17:32:20 +0000

> since they could have done all this already years ago.

Unfortunately when the extension was introduced in OC, the current
intention is that it is only a top-level module extension used to
"signal" to the module consumer on how to interpret the existing pattern
statement.  This obviously does not suffice unless all tools understand
this extension to then diverge the spec.

This has been talked abt many times and still an issue.  In my
conversations, the intention here is however to revert all current
pattern statements to XSD compliant w/ a possible parallel statement for
the posix-pattern

https://github.com/openconfig/public/issues/271

---

From: Jan Lindblad <[email-masked]>
Date: Thu, 19 Dec 2019 18:36:25 +0100

>> that some instance data is valid, but tool B says it isn't, then the standard is

Of course it would be legal. It's always legal for a NETCONF server to reject an edit-config for no apparent reason (from a YANG perspective), so all device YANG models would still be legal if all pattern statements were removed, but the same string pattern constraints still enforced by the devices. The OC group could therefore remove their pattern statements and introduce a YANG extension oc:posix-pattern (or oc:go-pattern, or whatever) that gives a hint to some clients what is expected. The clients that don't understand this extension would just se a rejection for no apparent reason (from a YANG perspective).

> I still believe that the only solution is to define as subset of XML regex that can easily be translated into common regex engines. Although, as Juergen has stated previously, this effectively defi…

I don't think a subset is possible here. The subset would be the null set, since basically all the posix expressions have caret+dollar ^(...)$ surrounding the actual expression, which are interpreted very differently than intended in the W3C world. So two separate pattern statements will be needed.

/jan

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 19 Dec 2019 17:52:49 +0000

From: Jan Lindblad <[email-masked]>
Sent: 19 December 2019 17:36
To: Rob Wilton (rwilton) <[email-masked]>
Cc: Martin Bjorklund <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [yang-doctors] YANG dialects?

Lada

I don't think a subset is possible here. The subset would be the null set, since basically all the posix expressions have caret+dollar ^(...)$ surrounding the actual expression, which are interpreted very differently than intended in the W3C world. So two separate pattern statements will be needed.
[RW]
Adding beginning/end anchors before processing a regex is trivial.  I.e. if the pattern is defined in XML regex, where the anchors are missing, implementations that want to put them into a POSIX regex need to add the anchors before processing the regex.

Thanks,
Rob

/jan

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Thu, 19 Dec 2019 17:58:27 +0000

> https://github.com/openconfig/public/issues/271

I only believe into this when it has happened. This issue is out for
years now and progress has been very slow. And given that libyang uses
pcre behind the scenes, I wonder why something like that won't work
for others. Part of the issue here really "religion" about different
regex languages, which escapes regular sound engineering.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 19 Dec 2019 20:17:17 +0100

On Thu, 2019-12-19 at 18:36 +0100, Jan Lindblad wrote:
> > > > > OpenConfig -
> > > > > mechanisms
> Of course it would be legal. It's always legal for a NETCONF server to reject
> an edit-config for no apparent reason (from a YANG perspective), so all device
> YANG models would still be legal if all pattern statements were removed, but
> the same string pattern constraints still enforced by the devices. The OC
> group could therefore remove their pattern statements and introduce a YANG
> extension oc:posix-pattern (or oc:go-pattern, or whatever) that gives a hint
> to some clients what is expected. The clients that don't understand this
> extension would just se a rejection for no apparent reason (from a YANG
> perspective).

I strongly disagree. Why then do we have so much text about constraints,
validity etc. in RFC 7950? The benefit of schema validation is that an
implementation can rely on an external validator and needn't clutter the code
with all kinds of input data checks. But if the validation result depends on
whether I choose library A or B, this concept simply falls apart.

Lada
> 
> > But, as I understand it, the regex implementations are not POSIX either.
> >  E.g. I think that they are using RE2 for Go, which is somewhat derived from
> > PCRE which is derived from POSIX regex, but not exactly compatible either.
> > 
> > So, it would end up replacing one regex language that can't be 100% directly
> > implemented with another regex language that can't be 100% directly
> > implemented.  This seems to make the life more complex not less.
> > 
> > I still believe that the only solution is to define as subset of XML regex
> > that can easily be translated into common regex engines. Although, as
> > Juergen has stated previously, this effectively defines a new regex language
> > ...
> 
> I don't think a subset is possible here. The subset would be the null set,
> since basically all the posix expressions have caret+dollar ^(...)$
> surrounding the actual expression, which are interpreted very differently than
> intended in the W3C world. So two separate pattern statements will be needed.
> 
> /jan
>

---

From: Jan Lindblad <[email-masked]>
Date: Fri, 20 Dec 2019 11:07:02 +0100

Lada,

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

I completely agree that the device interface behavior should be exposed with much detail in the corresponding YANG.

Practically, however, I don't think it is reasonable to expect that every little rule of the implementation is exposed. YANG isn't expressive enough to cover everything. And actually, there are sometimes cases where I advise not to add as many constraints into the model as technically possible by the YANG language. Half-a-page long XPath expressions may detract sharply from readability, performance and universality. Implementation details may start to leak into the interface.

There are also operational aspects to consider, such as a device running out of memory at some point. A client therefore has to be prepared that an edit-config may be refused for no apparent reason. There is no text in the RFC stating that the YANG constraints in a module must be complete, even if I regard that as a goal. One reason UML models tend to be useless as interface descriptions in practice is that they lack these constraints.

YANG extensions are a practical way to introduce validation concepts not feasible to express with YANG and XPath. Here are some examples:
+ Constraints on compatible colors in an optical YANG model (Not expressive enough)
+ Constraints on configured paths being disjunct (Not computationally efficient)
+ Constraints on an interface being unused by all other services (Not universally reusable [layer violation] if service YANG depends on device YANG)

In these cases it may not be possible or desirable to express the constraints in YANG/XPath. It may be possible express the constraint using domain specific extension keywords, which should be better than not expressing it at all. Clients that do not understand the added keywords would still work as long as the configurations generated are valid. Clients with domain understanding, possibly including understanding of the extension keywords, have a better chance at generating valid configurations.

/jan

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 20 Dec 2019 15:44:42 +0100

On Fri, 2019-12-20 at 11:07 +0100, Jan Lindblad wrote:
> Practically, however, I don't think it is reasonable to expect that every
> little rule of the implementation is exposed. YANG isn't expressive enough to
> cover everything. And actually, there are sometimes cases where I advise not
> to add as many constraints into the model as technically possible by the YANG
> language. Half-a-page long XPath expressions may detract sharply from
> readability, performance and universality. Implementation details may start to
> leak into the interface.

I understand this but I guess the problem is opposite: A server developer uses a
YANG library for validating config before applying it. If an implemented module
contained say

    oc:pattern '^x[123]$';

the developer might think that this constraint is checked by the library and
take it for granted. But if the library in fact silently ignores the oc:
extension, then arbitrary strings will be accepted and can do all kinds of nasty
things.

> 
> There are also operational aspects to consider, such as a device running out
> of memory at some point. A client therefore has to be prepared that an edit-
> config may be refused for no apparent reason. There is no text in the RFC
> stating that the YANG constraints in a module must be complete, even if I
> regard that as a goal. One reason UML models tend to be useless as interface
> descriptions in practice is that they lack these constraints.
> 
> YANG extensions are a practical way to introduce validation concepts not
> feasible to express with YANG and XPath. Here are some examples:
> + Constraints on an interface being unused by all other services (Not
> universally reusable [layer violation] if service YANG depends on device YANG)

All these constraints are related to a particular use case but oc:pattern would
really affect YANG semantics. For example:

- if oc:pattern is used in a type definition, does it also apply to a derived
type?

- according to sec. 8.1 in RFC 7950, this must be true in all data trees: 'All
leaf data values MUST match the type constraints for the leaf, including those
defined in the ... "pattern" properties.' But does this also apply to
oc:pattern?

In short: I believe that the notion of validity with respect to a YANG schema
should not depend on extensions as they are defined in RFC 7950. That's why I
proposed the critical/core extensions, because then YANG implementations can
learn that a modified YANG is assumed, and refuse to validate instances or at
least warn the user that things may unexpectedly break.

Lada

> 
> In these cases it may not be possible or desirable to express the constraints
> in YANG/XPath. It may be possible express the constraint using domain specific
> extension keywords, which should be better than not expressing it at all.
> Clients that do not understand the added keywords would still work as long as
> the configurations generated are valid. Clients with domain understanding,
> possibly including understanding of the extension keywords, have a better
> chance at generating valid configurations.
> 
> /jan
>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 20 Dec 2019 10:27:00 -0800

On Fri, Dec 20, 2019 at 6:44 AM Ladislav Lhotka <[email-masked]> wrote:

> > > > > > 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
> > > >
> > > > Of course it would be legal. It's always legal for a NETCONF server
> to
> > > > reject
> > > > an edit-config for no apparent reason (from a YANG perspective), so
> all
> > > > device
> > > > YANG models would still be legal if all pattern statements were
> removed,
> > > > but
> > > > extension oc:posix-pattern (or oc:go-pattern, or whatever) that
> gives a
> > > > hint
> > > implementation can rely on an external validator and needn't clutter
> the
> > > code
> > I completely agree that the device interface behavior should be exposed
> with
> > much detail in the corresponding YANG.
> >

But this is not the openconfig solution.
The oc-ext:regext-posix extension is much worse that this oc:pattern (does
it exist?)
It can be ignored by the compiler, which of course is unaware that
pattern-stmt
is not the YANG-defined pattern syntax.  They have already added this
module-level extension to all modules, so problem solved (they think).

I do not agree that the pattern-stmt is somehow "close to the
implementation"
and therefore one cannot expect it to work on all servers the same way.
All YANG constraints are supposed to produce the same client results, even
if they are not implemented the same way on each server.

There is a proper way to use YANG extensions to annotate the model
with implementation details.   Writing YANG modules so they only
work for 1 organization or only work if the server is written in a
particular language
is not the proper way.

There is no way to fix this correctly in YANG 1.1.
A new language version with new statements is needed to force all tools
to support any new pattern syntax.

Andy

> > + Constraints on compatible colors in an optical YANG model (Not
> expressive
> > enough)

---

From: Jan Lindblad <[email-masked]>
Date: Sat, 21 Dec 2019 09:49:01 +0100

Andy,
Completely agree. oc:pattern does not exist in code anywhere, AFAIK.
/jan

> On Fri, Dec 20, 2019 at 6:44 AM Ladislav Lhotka <[email-masked] <mailto:[email-masked]>> wrote:
> The oc-ext:regext-posix extension is much worse that this oc:pattern (does it exist?)
> It can be ignored by the compiler, which of course is unaware that pattern-stmt
> I do not agree that the pattern-stmt is somehow "close to the implementation"
> work for 1 organization or only work if the server is written in a particular language
> is not the proper way.
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/yang-doctors <https://www.ietf.org/mailman/listinfo/yang-doctors>

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 21 Dec 2019 12:46:01 +0100

On Fri, 2019-12-20 at 10:27 -0800, Andy Bierman wrote:
> > > > > extension oc:posix-pattern (or oc:go-pattern, or whatever) that gives
> > a
> > > > > hint

I know, but if you look back in this thread, Martin stated (and Jan later
supported) that the above "oc:pattern" extension would be legal, and I have been
arguing with that. Of course, I do agree that it would still be much better than
the existing situation.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Sat, 21 Dec 2019 08:32:42 -0800

On Sat, Dec 21, 2019 at 3:46 AM Ladislav Lhotka <[email-masked]> wrote:

> > > > > > > > This is not the case here, it is only syntactically
> compatible. If
> > > > > > > > tool A
> > > > > > Of course it would be legal. It's always legal for a NETCONF
> server to
> > > > > > reject
> > > > > > the same string pattern constraints still enforced by the
> devices. The
> > > OC
> > > > > > group could therefore remove their pattern statements and
> introduce a
> > > YANG
> gives
> > > > > > to some clients what is expected. The clients that don't
> understand
> > > this
> > > > > > extension would just se a rejection for no apparent reason (from
> a
> > > YANG
> > > > > > perspective).
> > > > >
> > > > > implementation can rely on an external validator and needn't
> clutter the
> > > > > code
> > > > little rule of the implementation is exposed. YANG isn't expressive
> enough
> > > to
> > > > cover everything. And actually, there are sometimes cases where I
> advise
> > > not
> > > > to add as many constraints into the model as technically possible by
> the
> > > YANG
> > > I understand this but I guess the problem is opposite: A server
> developer
> > > uses a
> > > YANG library for validating config before applying it. If an
> implemented
> > > module
> > > contained say
> > >
> > >     oc:pattern '^x[123]$';
> > >
> > > extension, then arbitrary strings will be accepted and can do all
> kinds of
> > > nasty
> > > things.
> > >
> >
> >

This solution would have meant standard YANG handled the node as a plain
string
with no pattern at all.

Since my company has to support all YANG modules, that includes openconfig.
It is easier to implement the regexp-posix hack, rather than get them to
fix anything.
I see the results of YANG complexity and mistakes due to churn in the form
of Freshdesk tickets.

Churn! Stuff keeps moving around from module to module and the refactoring
leaves bugs
in other modules. E.g., ietf-if-l3-vlan@2019-11-04,
openconfig-aaa@2018-11-21
(Plenty of broken XPath out there that needs to be fixed)

Lada
Andy

> > The oc-ext:regext-posix extension is much worse that this oc:pattern
> (does it
> > exist?)
> pattern-
> > stmt
> particular
> > language
> > > > There are also operational aspects to consider, such as a device
> running
> > > out
> > > > of memory at some point. A client therefore has to be prepared that
> an
> > > edit-
> > > > universally reusable [layer violation] if service YANG depends on
> device
> > > YANG)
> > >
> > > All these constraints are related to a particular use case but
> oc:pattern
> > > would
> > > - according to sec. 8.1 in RFC 7950, this must be true in all data
> trees:
> > > 'All
> > > leaf data values MUST match the type constraints for the leaf,
> including
> > > those
> > > should not depend on extensions as they are defined in RFC 7950.
> That's why
> > > I
> > > learn that a modified YANG is assumed, and refuse to validate
> instances or
> > > at
> > > > Clients that do not understand the added keywords would still work
> as long
> > > as