Introduce critical extensions

[llhotka]

Critical extensions would be allowed to extend or modify YANG semantics and would be mandatory to implement. In fact, some existing extensions, such as yang-data, are already of this category, even though RFC 7950 only permits extensions to address non-YANG semantics.

It is important to keep critical extensions under strict control, so it might be opportune to establish an IANA registry for them. In this case, critical extension statements needn't carry any prefix, i.e. appear syntactically as built-in YANG statements.

[abierman]

What is the YANG Conformance for critical extensions? Right now, implementation of an extension is tied to the YANG module that defines it, but not that clear. YANG 1.2 should definitely clarify the conformance requirements for an extension. Critical extension sounds like it should be a real YANG statement and not an extension

[llhotka]

It may be useful to introduce new YANG features without immediately modifying YANG spec. In some cases "normal" extensions have already been used like this, which is IMO problematic (see yang-data).

The idea here is that the IETF will keep control of these critical extensions (perhaps core extensions may be a better term). Some of them may be later incorporated in the "main" language but it is also possible that some will be used only in specific areas.

Details regarding conformance have to be worked out. They could be defined in YANG modules using a new statement, with the requirement of IANA registration. Then a server can advertize their use in YANG library by

• implementing the corresponding modules
• including an extra declarationn (top-level leaf-list)
• or both (this would be similar to the current handling of deviations)

[immibis]

If they are mandatory to implement, why do they need to be extensions?

Core keywords already seem to function as mandatory-to-implement keywords.

[llhotka]

What I mean by mandatory to implement is this: If the server advertizes such an extension, then clients that don't support it may expect hiccups.

The use of such extensions would be twofold:

• New features affecting YANG semantics may be introduced (temporarily) without updating the core YANG spec. If they prove useful, they may later be integrated in core yang.
• Some extensions may be domain-specific. For example, floating point support can be such an extensions. Servers that don't use it won't advertize it. However, if a server advertizes it, clients who don't may break.

[rovarga]

I think that is fair, but it also needs some work in NETCONF to specify protocol negotiation.

[mbj4668]

I think this is an interesting idea that is worth exploring more. I also agree with Andy about the need to clarify that an extension is supposed to be supported if a module is implemented.

[llhotka]

@rovarga Such extensions can be signalled on the server side simply by implementing the module where the extension is defined. And the client just has to follow suit.

[abierman]

Extensions are very vague about which tool needs to understand the extension. Is it the compiler? The server? The client? One or more? Look at nacm:default-deny-all as an example. It is only server.

The basic concept of critical extension is OK. It means "if you do not implement this extension, then halt with an error" But it should be clear what tools are intended for this check

Conformance for extensions should be clarified and this issue is part of the general problem

[llhotka]

Extensions are very vague about which tool needs to understand the extension. Is it the compiler? The server? The client? One or more? Look at nacm:default-deny-all as an example. It is only server.

Yes, current extensions are often misused. For example, a server that supports schema mount and a client that doesn't cannot work together. Critical extensions would make such approaches legal but

• the conformance requirements will be strict, and
• standard critical extensions will be under tight control

The basic concept of critical extension is OK. It means "if you do not implement this extension, then halt with an error"

Or simply "if you do not implement this extension, then expect problems". It is the same as if the client doesn't fully support standard YANG.

But it should be clear what tools are intended for this check

Conformance for extensions should be clarified and this issue is part of the general problem

[rovarga]

Extensions are very vague about which tool needs to understand the extension. Is it the compiler? The server? The client? One or more?

Compiler at the very least, as it should be able to fail if it does not understand a critical extension while being asked to compile a model using it.

[mbj4668]

This is too vague. Suppose my compiler is used to generate documentation. Is it necessary that it fails if in encounters a critical extension? I agree with Andy; it is not clear at all in which situation an extension is critical.

Take Lada's example of schema mount. A client that sends an edit-config for some part of a model that happens to have a mount point will work perfectly fine. The extension is not critical in this situation. And a client that performs a get-config for archiving purposes also doesn't have to care about this extension.

[rovarga]

I did not mean to imply that the compiler MUST fail, just that a critical extensions have a different handling from RFC7950 extensions. In the documentation case, this really boils down to user preference: is it better to have incomplete documentation or fail compilation?

In both get-config and edit-config cases you are right, they can work, but the compiler needs to know that a critical extension (schema-mount in this case) has certain semantics and can be ignored in the use case.

As a (theoretical) counter-example, imagine the use of yang-data in config=true context: here ignoring the extension would break both edit-config and get-config use cases -- edit-config would potentially wipe data and get-config would result in an incomplete backup.

I think this illustrates that "critical extensions" is perhaps a general term encompassing multiple semantic classes of extensions. Can we perhaps enumerate the classes?

[llhotka]

I agree with Martin: unlike server functionality, it is not specified what a client, compiler or any YANG-related tool is expected to do.

Support for critical extensions should be indicated to YANG compilers and other software but it is then up to the authors or users to take this information into account. If they don't care, things may break. It is pretty much the same as with tools supporting only YANG 1.0: they may sometimes work for YANG 1.1.

For clients and some software, critical extensions will be listed as a part of YANG library data that defines the overall data model. This data is either advertised by a server or, for example, passed to tools as yang-instance-file.

[kwatsen]

MUST RFCs defining a critical extension "update" RFC 7950?

(came up in a discussion with Andy and Lou)

[llhotka]

IMO critical extensions must be defined in a new version of YANG because the existing extensions are (on purpose) weak and truly optional:

   o  extension: An extension attaches non-YANG semantics to statements.
      The "extension" statement defines new statements to express these
      semantics.

The fact that some extensions (schema mount, annotations) may be not-so-optional just indicates that the "plain" extensions are being misused.

[llhotka]

Hmm, I misunderstood the question, you probably asked about the case when a particular critical extension is defined. I think this has to be discussed, but perhaps it won't be necessary to update 7950bis provided that "vanilla" YANG can be used without the extension. That said, some critical extensions can later become an integral part of a new version of YANG.

[kwatsen]

A lot of concern for adding things that have to be understood by clients.