Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
Joe Clarke <jclarke@cisco.com> Wed, 15 November 2017 08:44 UTC
Return-Path: <jclarke@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27401279EB for <netmod@ietfa.amsl.com>; Wed, 15 Nov 2017 00:44:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level:
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0kWxWev5bNRK for <netmod@ietfa.amsl.com>; Wed, 15 Nov 2017 00:44:44 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4451200C1 for <netmod@ietf.org>; Wed, 15 Nov 2017 00:44:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7940; q=dns/txt; s=iport; t=1510735484; x=1511945084; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=W+Y39ru0UtR5iy/T0FHDuVoZAyM2HkLgJN0sRx8Rllo=; b=BdGUjRyLt/LrcQH4061m0RKGoZ2yWRzvcIrpyqpDJncFCe75J9idI0Ky KZjSb+SU0OP3txGIL0QGUWyOaf/oZbCPibtnf0umaO3rmh7mbRjYXIE// Ucy7IgET5dMDAXKGLmCtS6wnEVgvTnrX++CXM6zkHjxgy2/GEs18BT3dF 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CoAAD1/Qta/49dJa1RCQMZAQEBAQEBAQEBAQEBBwEBAQEBgzZkboQmih+PIoF9llqCEQofhRwChQU/GAEBAQEBAQEBAWsohR8BBR0GDwFUAgsQCAICJgICGzwQAwgBAReKCapZgieLGAEBAQEGAQEBASQFgQqCJYIHgVWCEoMBhFgBKQkuJoJOgmMFkXABgRSPMpUGghWJaodFijKLe4E5HziBdFUlFYMuCIJTHIIFI4ZVgkIBAQE
X-IronPort-AV: E=Sophos;i="5.44,398,1505779200"; d="scan'208";a="318972414"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Nov 2017 08:44:29 +0000
Received: from [10.24.101.203] ([10.24.101.203]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id vAF8iRrx022603 for <netmod@ietf.org>; Wed, 15 Nov 2017 08:44:27 GMT
To: netmod@ietf.org
References: <19a4129f-84b4-2d6b-8405-37b85952f53a@ericsson.com> <20171114212210.7b2g3t3nqzrhcgrs@elstar.local> <20171115053046.nr33ypoibdn4jufv@elstar.local>
From: Joe Clarke <jclarke@cisco.com>
Organization: Cisco
Message-ID: <9094b945-366f-145d-fbc1-5cf116f4a3bc@cisco.com>
Date: Wed, 15 Nov 2017 03:44:26 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <20171115053046.nr33ypoibdn4jufv@elstar.local>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/PUv8mSkKU5Nrql0SGF_mBfsWmy0>
Subject: Re: [netmod] Comment on draft-clacla-netmod-yang-model-update-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Nov 2017 08:44:45 -0000
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] Comment on draft-clacla-netmod-yang-mode… Balazs Lengyel
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Juergen Schoenwaelder
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Andy Bierman
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Balazs Lengyel
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Juergen Schoenwaelder
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Juergen Schoenwaelder
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Martin Bjorklund
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Ladislav Lhotka
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Martin Bjorklund
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Ladislav Lhotka
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Joe Clarke
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Martin Bjorklund
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Balazs Lengyel
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Balazs Lengyel
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Ladislav Lhotka
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Joe Clarke
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Balazs Lengyel
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Joe Clarke
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Juergen Schoenwaelder
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Joe Clarke
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Ladislav Lhotka
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Ladislav Lhotka
- [netmod] Obsolete and deprecated in RFC 7950 Balazs Lengyel
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Martin Bjorklund
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Ladislav Lhotka
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Martin Bjorklund
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Balazs Lengyel
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Randy Presuhn
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Ladislav Lhotka
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Ladislav Lhotka
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Balazs Lengyel
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Ladislav Lhotka
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Joe Clarke
- Re: [netmod] Comment on draft-clacla-netmod-yang-… Ladislav Lhotka