Re: [yang-doctors] YANG dialects?

[Ladislav Lhotka <[e-mail]>]

On Fri, 2019-12-20 at 11:07 +0100, Jan Lindblad wrote:
> Lada,
> 
> > > > > 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
> > > 
> > > 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
> 
> 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.

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

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
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67