Re: [yang-doctors] YANG dialects?

[Jan Lindblad <[e-mail]>]

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.

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