3) Is needed because we need to be able to warn the consumers of
a YANG module (YAM) that some part will be going away, while at
the same time we need to promise them that it is still usable. We
need a firm contract not a maybe about this.
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: +36-70-330-7909 email: [email protected]
