Joe Clarke <jcla...@cisco.com> writes: > On 11/15/17 00:30, Juergen Schoenwaelder wrote: >> 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. > > I'm not convinced this a bad thing. If a server supports multiple > versions of a given module, which should a client use? Did the server > vendor test each one? > > I suppose my gut reaction to Lou's question as to whether a server > should support multiple versions was, "no." A client may have multiple > versions loaded to support servers that support different versions. I > may be convinced otherwise, but I feel that this will become untenable > over time (even if module names change).
There are use cases for modules that are imported (i.e. not implemented): it could be that a module author wants to use some definitions from an old version of an imported module while, at the same time, other definitions from a new version. The semver-aware "import" statement should be able to deal with this. Lada > > Joe > >> >> /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/> >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod