On Wed, Nov 15, 2017 at 11:33:18AM +0800, Balazs Lengyel wrote:
> BALAZS: Semantic versioning gives the editor the possibility to indicate
> that a change is non backward compatible(NBC). Even if the Yang Model
> type/restrictions/valuespace/etc. does not change, but I, the human model
> designer, know that the expected behavior of the SW implementing the model
> changes, I can still indicate that the model is changing in an NBC way.
> That's one reason I like, I need semantic versioning.
You have several possible cases:
a) The semver indicates an non-compatible change and the change does
affect your client.
b) The semver indicates an non-compatible change but the change does not
affect your client.
c) The semver indicates no non-compatible change and your client happily
continues to work.
d) The semver indicates no non-compatible change but there is a change
that does affect your client.
It seems semantic versioning focuses on a) and c) but b) and d) may
still happen in practice.
> > > 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.
> > In XML land, this is mostly a change of the namespace (not of the
> > prefix) if one keeps the same structure, no? In JSON land, the change
> > of the module name more directly becomes visible in instance data; but
> > this is all encoding details.
> BALAZS: Even in XMLland we store the prefix as part of any leaf with type
> instance-identifier or identityref and potentially CLI scripts.
Which is risky since in principle there is no guarantee that the prefix
always remains the same.
> > > If we update the module from ietf-routing to ietf-routing-2 ? Do we
> > > keep
> > > the prefix?
> > I guess you mean the namespace, not the prefix. You can use any prefix
> > you like.
> BALAZS: No, I mean the prefix. Prefix is part of the instance data (see
> above), potentially part of CLI scripts etc. It is also part of human
> communication. In email we never refer to
> urn:ietf:params:xml:ns:yang:ietf-yang-library:/modules-state instead we just
> write yanglib:/modules/state.
See above.
> > > 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.
> > If we move towards allowing incompabile updates, then we need to have
> > a mechanism to tell which versions of modules can work together and
> > which combinations are affected by an incompatible update. We probably
> > need to require strict import by revision or at least 'import by
> > compatible revision' (whatever this means at the end).
> BALAZS: We already have this problem today. We allow incompatible updates
> for deprecated/obsolete. When you import a module, the importing module will
> not check for status statements. For "augment" or "must" referencing a
> deprecated and thus removed part will already today cause problems.
There is in general a difference between the status of a definition
and which objects are implemented and which objects are accessible.
> > > 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.
> > Marking something deprecated / obsolete means you can not be sure this
> > is implemented. But then, even definitions with status current may not
> > be implemented (see deviations) or they may not be accessible to a
> > client due to access control. However, if implemented and accessible,
> > the guarantee today is that the semantics stay the same and don't
> > change unexpectedly.
> BALAZS: Access control can be set by the operator, deviations are at least
> viewable, checkable in design time. However something (possibly) removed due
> to status just disappears. In my view the current status deprecated is
> similar to deviation not-supported .
The status is known at compile time. Deviations are known at run-time,
not at design-time.
> > > 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.
> > I do not see why you need a line by line comparison. With semantic
> > versioning, you _hope_ the semantic version number is a good enough
> > indicator. It might also be that your client is only using a subset
> > that did not really change even though the semantic version number
> > changed. Or the semantic version number indicates only minor changes
> > that sill break your client.
> BALAZS: Line by line comparison is needed, because today anywhere in the
> model you might find a new status deprecated statement. You are forced to do
> the line by line comparison and even that is no guarantee of compatibility
> due to behavior changes.
> Yes you might set the semantic version incorrectly, but that's a bug. You
> might use other parts of YANG incorrectly too.
Semantic versioning gives you a hint, it does not tell for sure your
client fails not does it tell for sure your client will continue to
work.
> > > 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.
> > So it seems to boil down to the question whether foo and foo2 is
> > significantly more expensive than foo { semver 1.x.y } and foo {
> > semver 2.x.y }. The main argument seems to be that the later keeps
> > references that involve module names or namespaces unchanged (but
> > they may or may not mean different things).
> BALAZS: For SMALL NBC changes, I propose to keep the original module name.
> Now while agree it is possible to misuse this, and that SMALL is subjective,
> however we already have this situation. Removing stuff by deprecation is not
> much better then just deleting the same.
> In ericsson our internal definition of deprecation follows what e.g. JAVA
> does:
> "Deprecated schema nodes MUST still work as defined by the YAM. The
> deprecated status serves only as a a warning that the schema node will be
> removed or obsoleted in the future."
> This allows continued compatible usage while still warning the client, that
> the marked parts will go away soon.
The difference is that Java releases are published regularly but IETF
published modules likely won't be republished to go from deprecated to
obsolete. The deprecated status leaves it to implementors to decide
whether they remove something. And implementors usually have little
interest to break clients.
> > > 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 think it is necessary to think about how the semantic version
> > numbers are used. See my remark above about imports. If we allow
> > incompatible changes, than this has side effects and I think we are
> > not done by just adding a semantic version number without going
> > working throught the implications.
> BALAZS: I don't object, although I would prefer to handle them separately.
> I do object to the word "if". Due to YANG's current rules for status we
> already allow incompatible changes.
/js
--
Juergen Schoenwaelder Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax: +49 421 200 3103 <http://www.jacobs-university.de/>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
