1. draft-clacla-netmod-yang-model-update-02
New YANG Module Update Procedure
draft-clacla-netmod-yang-model-update-02
Benoît Claise, Cisco
Joe Clarke, Cisco
Kevin D'Souza, AT&T
Netmod WG
November 15, 2017

2. Problem Illustrated

3. Problem Illustrated

4. Problem Illustrated
Area of confusion. E.g., ietf-rip shows a dependency to both ietf-routing and ietf-routing-2 since there is no explicit linkage between the two.

5. Problem Explication Background:
ietf-routing-2 has been renamed to ietf-routing, so not really an issue
Not a new problem, but the first occurrence in the IETF (openconfig mentioned this)
Have to warn all ietf-routing dependent YANG module authors that they have to import a different YANG module now
Btw, had to create a script from the yangcatalog to get those addresses
Industry-wide issue: cross SDO, cross opensource, cross vendors
From a tooling point of view, no way to know that YANG module-B updates/obsoletes YANG module-A
Without going the RFC header tag

6. Sources of the Problem Let’s re-think our YANG module update strategy
YANG “updating a module” rules are strict in term of backward compatibility
The YANG module (structure) have to be perfect
Slow Standardization
As a consequence of the YANG update rules
Some YANG modules are not backward compatible. It’s a fact
Ex: L3VPN
Ex: some “native” models
Let’s re-think our YANG module update strategy 

7. The Bigger Problem/End Goal: Service Composition
Operators want to automate services
Services YANG modules maps to multiple device YANG modules
Potentially from multiple sources
Service creation: which YANG module work together?
Which YANG modules work together (“release bundle”, “package”)
Testing and/or metadata (tree-type/dependency)
Service maintenance/upgrade
Mapping to all YANG paths
Impact to my service if I upgrade a device? Path change?
In case of non backward compatible YANG modules, is my service impacted?
Let’s re-think our YANG module update strategy 

8. Proposed Solution We relax the YANG update rules:
"As experience is gained with a module, it may be desirable to revise that module. Changes to published modules are allowed, even if they have some potential to cause interoperability problems, at the condition that the semantic versioning change are clearly indicated based on the SEMVER YANG extension.”
Keep the same YANG module name
SEMVER extension in YANG module
MAJOR is incremented when the new version of the specification is incompatible with previous versions.
MINOR is incremented when new functionality is added in a manner that is backward-compatible with previous versions.
PATCH is incremented when bug fixes are made in a backward- compatible manner
Note: based on an openconfig previous proposal

9. Tracking Module Changes
Derived-semantic-version is determined using:
Order all modules of the same name by revision from oldest to newest.
If module A, revision N+1 has failed compilation, bump its derived semantic MAJOR version.
Else, run "pyang --check-update-from" on module A, revision N and revision N+1 to see if backward-incompatible changes exist.
If backward-incompatible changes exist, bump module A, revision N+1's derived MAJOR semantic version.
If no backward-incompatible changes exist, compare the pyang trees of module A, revision N and revision N+1.
If there are structural differences (e.g., new nodes), bump module A, revision N+1's derived MINOR semantic version.
If no structural differences exist, bump module A, revision N+1's derived PATCH semantic version.

10. Which problem does it solve?
YANG modules backward compatibility
Automation oolchain works
Experiment in yangcatalog.org
Fit well in the service composition concept
No YANG path update with new YANG modules
SEMVER composition of any new YANG modules

11. Open Issues
Next to “import by revision” (though this is seldom used), do we need import by semantic version: "version==X", "version>=X", "major version==X", "major version>=X", etc.
A new naming convention for modules?
Today, modules are named in notation.  Re-using the for version is not ideal.  Perhaps a new character such as '%' is needed (i.e., module%version.yang).  In this manner, both version and revision could be used.
module bundle/package?
modules that are part of a bundle and are known to interoperate. 
A new kind of import is required.  Today, we have import by revision (though this is seldom used).  There should also be an import by module-version (i.e., the semantic version).  This import will not simply be a copy of import by revision.  Consideration needs to be given to expressions such as "version==X", "version>=X", "major version==X", "major version>=X", etc.
Similarly to import-by-version, we may also require a new naming convention for modules.  Today, modules are named in notation.  Re-using the for version is not ideal.  Perhaps a new character such as '%' is needed (i.e., module%version.yang).  In this manner, both version and revision could be used.
Taking another page from Openconfig, the notion of a module bundle should be considered.  That is, there may need to be a way to enumerate modules that are part of a bundle and are known to interoperate.  This may not be as critical if a rich import-by-version is defined.
Similarly, the concept of a feature bundle should be considered.  Typically, operators combine and test YANG modules to build value-add services.  These bundles form releases for specific features or services, and it is critical to ensure as the modules evolve, the bundles can coherently evolve with them.