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

Ladislav Lhotka <> Wed, 15 November 2017 10:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 67C2C12706D for <>; Wed, 15 Nov 2017 02:05:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZJBeP7V4dTin for <>; Wed, 15 Nov 2017 02:05:43 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 56F9112008A for <>; Wed, 15 Nov 2017 02:05:43 -0800 (PST)
Received: by (Postfix, from userid 109) id B2B8018215DD; Wed, 15 Nov 2017 11:04:23 +0100 (CET)
Received: from localhost ( []) by (Postfix) with ESMTPSA id F2DD91820F76; Wed, 15 Nov 2017 11:04:19 +0100 (CET)
From: Ladislav Lhotka <>
To: Joe Clarke <>,
In-Reply-To: <>
References: <> <20171114212210.7b2g3t3nqzrhcgrs@elstar.local> <20171115053046.nr33ypoibdn4jufv@elstar.local> <>
Mail-Followup-To: Joe Clarke <>,
Date: Wed, 15 Nov 2017 18:06:43 +0800
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Nov 2017 10:05:47 -0000

Joe Clarke <> 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.


> 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         <>
> _______________________________________________
> netmod mailing list

Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67