Another thing to consider is that foo and foo2 allows an
implementation to support both during transition, with foo {semver
1.x.y} and foo {semver 2.x.y} this may be harder.
/js
On Tue, Nov 14, 2017 at 10:22:10PM +0100, Juergen Schoenwaelder wrote:
> On Wed, Nov 15, 2017 at 12:51:22AM +0800, Balazs Lengyel wrote:
> > 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.
>
> The current rules aim at guaranteeing that definitions (with status
> current) remain backwards compatible. Do you have an example what the
> current rules fail to achieve this? Definitions with status deprecated
> or obsolete may not be present. But if they are present, they have the
> same semantics. This is the promise made to a client. (Note also that
> objects may be absent for reasons document in deviations or simply not
> accessible due to access control.)
>
> > 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.
>
> The problem is to decide whether a change can break client
> expectations or not. Even 'bug fixes' can cause a client written to
> expect the old 'buggy' behaviour to fail. Also tricky are situations
> where behaviour was not clearly enough described and this is 'fixed'
> in a module update.
>
> Semantic versioning assumes that one always can clearly distinguish
> between incompatible updates and compatible updates. This may not be
> so clearly cut in practice, see above. (But then, we have the same
> judgement call at the end with today's update rules.)
>
> > 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.
>
> > 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.
>
> > 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).
>
> > 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.
>
> > 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.
>
> > 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).
>
> > 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.
>
> /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/>
--
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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
