[netmod] Comment on draft-clacla-netmod-yang-model-update-02

[Balazs Lengyel <[e-mail]>]

Hello,

First of all Ericsson very strongly supports this draft. This is a problem we definitely have, and for which we had to create our own internal solution. So we would love to see an IETF solution!

General)

The document does not mention some other problems with the current versioning. These stem from

• we should allow non-backward compatible (NBC) changes in some limited cases
• it should be possible to determine two module versions' compatibility without a line-by-line comparison
  

Whenever a client OSS implements some higher level logic for a network function, something that can not be implemented in a purely model driven way, it is always dependent on a specific version of the Yang Module (YAM). If the client finds that the module has been updated on the network node, it has to decide if it tries to handle it as it did the previous version of the model or if it just stops to avoid problems. To make this decision the client needs to know if the module was updated in a backward compatible way or not. This is not addressed with the current versioning.

While having PYANG based checks for backward compatibility is a very good idea, a  comparison based check will never be a complete check. It is quite possible to change just the behavior of an rpc/action/etc.  without changing the YANG definition.  This will only show up as a change of the description statement that can not be analyzed by PYANG.

When upgrading a network node we might introduce non-backward compatible (NBC) changes. Today we need to introduce a new module for this. That means during the upgrade process the node must convert stored configuration instance data from ietf-routing to ietf-routing-2 format. Instead of solving this data transformation/transfer problem just for a few NBC data nodes, we will have to do it for the full model. This is complicated. In many cases the transformation of a few NBC leafs can be handled by good defaults or with a small script. Transferring the full data set is more complicated. If we allow NBC updates in some cases this problem is avoided.

If we update the module from ietf-routing to ietf-routing-2 ? Do we keep the prefix?  In one sense it should be kept as it is the same module "logically"; we also might have stored data including the prefix (identityrefs, instance-identifiers). On the other hand having multiple modules with the same prefix is a problem. The only good solution is to allow incompatible updates in some cases.

CH 1)

You write
"The YANG data modeling language [RFC7950] specifies strict rules for updating..."
and again
"When the same YANG module name is kept, the new YANG module  revision must always be updated in a backward-compatible way."

I strongly disagree. While we have strict rules about even small modifications to existing schema, but you are allowed to deprecate/obsolete big parts of the model, thereby possibly deleting complete subtrees from the schema. That is anything but strict backward compatibility.
I find this aspect of YANG inconsistent to the level that it would need an errata.

So practically the current rules allow backward incompatible changes that can only be detected by a line by line comparison of the yang modules. In a system with semantic versioning, you could determine backward compatibility just by reading the version numbers.

CH 2.3)
As we need to create a new Yang Module (YAM) even for the smallest incompatible modification, this increases the number of modules.

CH 2.5)  We already have vendor modules depending on ietf-routing

CH3.1)

I propose that the semantic version should be a mandatory substatement of the YANG revision statement. It should be updated every time, and it would be good to see the older semantic versions as well.

I would propose to have 3 separate statements for x,y,z. I don't like structured strings. It would be much easier to compare simple integers.

I can if needed provide some more detailed rules for x,y,z e.g. if x is stepped y and z MUST be set to 0.

IMHO YANG package definition should be a separate issue, left out of this document. Andy has already provided some very good ideas about this topic.

I also think the current definition of deprecated and obsolete in YANG 1.1 is near useless, as all it says that both deprecated and obsolete items may or may not be there. We need something better. 

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: [phone]              email: [e-mail]