Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02

[Martin Bjorklund <[e-mail]>]

Joe Clarke <[e-mail]> wrote:
> 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."

Exactly.  With the current solution, the sever can still implement the
deprecated or obsolete nodes in order to support old clients.

With a MAJOR update in a semver world, it means that the old nodes are
removed (or rather, possibly, that the old nodes have new syntax
and/or semantics).


> 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).

I think the proposed solution will make it even harder for clients,
since the same paths will mean very different things on different
servers.


/martin


> 
> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> >> Fax:   [phone]         <http://www.jacobs-university.de/>
> > 
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>