Subject: [Netmod-ver-dt] Versioning and features

From: Robert Wilton <[email-masked]>
Date: Mon, 23 Jul 2018 16:52:54 +0100

In some of the versioning discussions at IETF, there is the idea of 
using features to allow backwards compatible changes to a module that 
might not be supported in an older software release.

However, it occurred to me that feature statements can be used to break 
the backwards compatible versioning contract.

E.g. consider a module that has some configuration enabled under an 
if-feature "featurette1" statement.

If in release X the YANG feature "featurette1" is enabled, but in 
release X + 1, the YANG feature "featurette1" is not enabled.  For all 
intents and purposes, a client that is using "featurette1" and moving 
from release X to release X + 1 would see this an non-backwards 
compatible change to the configuration model.

Similar considerations apply to deviations as well.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 23 Jul 2018 18:06:36 +0200

On Mon, Jul 23, 2018 at 04:52:54PM +0100, Robert Wilton wrote:
> In some of the versioning discussions at IETF, there is the idea of using
> features to allow backwards compatible changes to a module that might not be
> supported in an older software release.
> 
> However, it occurred to me that feature statements can be used to break the
> backwards compatible versioning contract.
> 
> If in release X the YANG feature "featurette1" is enabled, but in release X
> + 1, the YANG feature "featurette1" is not enabled.  For all intents and
> purposes, a client that is using "featurette1" and moving from release X to
> release X + 1 would see this an non-backwards compatible change to the
> configuration model.
> 

I do not know what "feature enabled in YANG" means.

A feature is supported by an _implementation_ or it is not. A client
requiring a certain feature to be supported in order to function
requires this feature to be supported to function. If an
implementation removes support for a feature, well the application
will detect this and stop working.

Or do you talk about removing a feature from a YANG module? Well this
makes conditionally mandatory definitions mandatory, this can't break
interoperability (except that a client checking for the presence of a
feature would not see this announced anymore).

I think section 11 of RFC 7950 is fine wrt features. If your intention
was to say that if we allow uncontrolled changes to features we can
mess things up, then yes this is likely true.

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