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).
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
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
