|
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
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 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. 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) 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: +36-70-330-7909 email: [email protected] |
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
