Re: [yang-doctors] YANG dialects?

[Jan Lindblad <[e-mail]>]

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

> On Fri, Dec 20, 2019 at 6:44 AM Ladislav Lhotka <[e-mail] <mailto:[e-mail]>> wrote:
> 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.
> 
> 
> 
> 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
> 
> > 
> > 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
> 
> _______________________________________________
> yang-doctors mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/yang-doctors <https://www.ietf.org/mailman/listinfo/yang-doctors>