Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Tue, 24 July 2018 09:29 UTC
Return-Path: <j.schoenwaelder@jacobs-university.de>
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 A6A11130E40 for <netmod@ietfa.amsl.com>; Tue, 24 Jul 2018 02:29:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FraxoeQcXuZ8 for <netmod@ietfa.amsl.com>; Tue, 24 Jul 2018 02:29:09 -0700 (PDT)
Received: from anna.localdomain (firewallix.jacobs-university.de [212.201.44.247]) by ietfa.amsl.com (Postfix) with ESMTP id 48B7912872C for <netmod@ietf.org>; Tue, 24 Jul 2018 02:29:09 -0700 (PDT)
Received: by anna.localdomain (Postfix, from userid 501) id 97BE4237D13C; Tue, 24 Jul 2018 11:29:08 +0200 (CEST)
Date: Tue, 24 Jul 2018 11:29:08 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Christian Hopps <chopps@chopps.org>
Cc: Andy Bierman <andy@yumaworks.com>, NetMod WG <netmod@ietf.org>
Message-ID: <20180724092908.ed36loiv3zrivs5d@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Christian Hopps <chopps@chopps.org>, Andy Bierman <andy@yumaworks.com>, NetMod WG <netmod@ietf.org>
References: <CABCOCHQ47ztJTPaZMZK7FWHsRPk1jN6SuuAWtg08rmtVgUPEWw@mail.gmail.com> <87va981svk.fsf@chopps.org> <CABCOCHSkpn_=04qJP9m6TUA+doCjk0=BFG6jX9T4awj+CO-QdA@mail.gmail.com> <87tvos1cse.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <87tvos1cse.fsf@chopps.org>
User-Agent: NeoMutt/20180716
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Hhq4AWL_B8Wgj0pyDqOdbAkRoCY>
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
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: Tue, 24 Jul 2018 09:29:12 -0000
On Sat, Jul 21, 2018 at 05:47:45PM -0400, Christian Hopps wrote: > There are actual instances where small perhaps non-disruptive but > incompatible changes are required. The example given to me for this > type of change was when the original specification had an obvious > bug (e.g., a range was incorrectly specified). I strongly believe that fixing bugs is not a reason to change the current versioning rules. Bugs come essentially in three flavors: - A definition is messed up (i.e., a range, a pattern, a must expression) but the original intention of the definition is clear from the context (description clauses, references, ...). In this case, implementors will likely have done the right thing (or when they observed the problem they will likely have done the right thing). - A definition is messed up but it is not clear from the context what the original intention of the definition was. In this case, there is a true ambiguity and implementors can rightfully have come to different conclusions how to deal with the conflict in the definition. In the first case, I believe there is no issue with simply fixing the messed up definition. I believe this kind of bug fixes is not constrained by the YANG update rules. In the second case, there is true ambiguity what implementations may do and hence the safest approach is to deprecate the messed up definition and to create a replacement. Of course, in reality, things are often not so clear cut and hence it takes some informed judgement what is the reasonable way to deal with things. (A type two bug caught very early may be different from a type two bug caught after several months of implementation and deployment.) Sometimes we also have situations where a definition that was originally OK turs out over time to be problematic as technology has evolved. So after some time, the original definition starts to look like a bug but it actually is not. The safe path forward is again to create new definitions and to deprecate the old ones. Now, for those in favour of moving from (module, path) to (module, path, version), you loose the deprecated definition. So if you wan't to allow for a transition period, there is a need to allow an old client to work with the old definition and a new client to work with the new definition. In the current naming scheme, this is not a problem, with a (module, path, version) naming scheme this requires some extra complexity. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
- [netmod] backward compatibility requirements in d… Andy Bierman
- Re: [netmod] backward compatibility requirements … Juergen Schoenwaelder
- Re: [netmod] backward compatibility requirements … Juergen Schoenwaelder
- Re: [netmod] backward compatibility requirements … Andy Bierman
- Re: [netmod] backward compatibility requirements … Juergen Schoenwaelder
- Re: [netmod] backward compatibility requirements … Andy Bierman
- Re: [netmod] backward compatibility requirements … Christian Hopps
- Re: [netmod] backward compatibility requirements … Andy Bierman
- Re: [netmod] backward compatibility requirements … Christian Hopps
- Re: [netmod] backward compatibility requirements … Robert Wilton
- Re: [netmod] backward compatibility requirements … Andy Bierman
- Re: [netmod] backward compatibility requirements … Robert Wilton
- Re: [netmod] backward compatibility requirements … Andy Bierman
- Re: [netmod] backward compatibility requirements … Robert Wilton
- Re: [netmod] backward compatibility requirements … Andy Bierman
- Re: [netmod] backward compatibility requirements … Kent Watsen
- Re: [netmod] backward compatibility requirements … Juergen Schoenwaelder
- Re: [netmod] backward compatibility requirements … Andy Bierman
- Re: [netmod] backward compatibility requirements … Robert Wilton
- Re: [netmod] backward compatibility requirements … Andy Bierman
- Re: [netmod] backward compatibility requirements … Juergen Schoenwaelder
- Re: [netmod] backward compatibility requirements … Robert Wilton
- Re: [netmod] backward compatibility requirements … Juergen Schoenwaelder
- Re: [netmod] backward compatibility requirements … Robert Wilton
- Re: [netmod] backward compatibility requirements … Juergen Schoenwaelder
- Re: [netmod] backward compatibility requirements … Robert Wilton
- Re: [netmod] backward compatibility requirements … Christian Hopps
- Re: [netmod] backward compatibility requirements … Kent Watsen