Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
Christian Hopps <chopps@chopps.org> Sat, 21 July 2018 21:47 UTC
Return-Path: <chopps@chopps.org>
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 F35FD12F1A5 for <netmod@ietfa.amsl.com>; Sat, 21 Jul 2018 14:47:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 WtLE_2YHSddL for <netmod@ietfa.amsl.com>; Sat, 21 Jul 2018 14:47:47 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id BEC9612426A for <netmod@ietf.org>; Sat, 21 Jul 2018 14:47:46 -0700 (PDT)
Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 1F0C7633FD; Sat, 21 Jul 2018 21:47:46 +0000 (UTC)
References: <CABCOCHQ47ztJTPaZMZK7FWHsRPk1jN6SuuAWtg08rmtVgUPEWw@mail.gmail.com> <87va981svk.fsf@chopps.org> <CABCOCHSkpn_=04qJP9m6TUA+doCjk0=BFG6jX9T4awj+CO-QdA@mail.gmail.com>
User-agent: mu4e 1.0; emacs 26.1
From: Christian Hopps <chopps@chopps.org>
To: Andy Bierman <andy@yumaworks.com>
Cc: Christian Hopps <chopps@chopps.org>, NetMod WG <netmod@ietf.org>
In-reply-to: <CABCOCHSkpn_=04qJP9m6TUA+doCjk0=BFG6jX9T4awj+CO-QdA@mail.gmail.com>
Date: Sat, 21 Jul 2018 17:47:45 -0400
Message-ID: <87tvos1cse.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/a49CtliA7zmpcA-lawVxkdBhacY>
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: Sat, 21 Jul 2018 21:47:50 -0000
Perhaps you are mistaking my intention here? I want a simple solution. I advocated for *not* introducing a new major version component. I don't want models changing all the time. I don't believe there is a large need for incompatible changes. 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 think for these there are non-standard solutions (e.g., a server could be configured to map a set (or all) clients to new module name/namespace if the operator/user decides its safe to do so). Naming conventions (e.g., a version suffix) can identify lineage to earlier "major" versions of a module as well. Joe Clark mentioned one thing to me that I do think is missing and needed in YANG and that is some form of a "import after" so that module designers/users have the ability to select a version of the module that includes additions that have shown up in later revisions. I believe this can utilize the current revision (date) semantics. It seems one place seeing a lot of "major" changes is with vendor models. I think internal development processes are driving these, and the vendors need to fix these processes, and not just make it easier to push these changes out to the operators/users. I expressed this multiple times to the design team this last week. Thanks, Chris. Andy Bierman <andy@yumaworks.com> writes: > On Sat, Jul 21, 2018 at 9:00 AM, Christian Hopps <chopps@chopps.org> wrote: > >> As I pointed out at the mic @102 this requirement derives directly from >> the 1.x requirement of not changing the name of the module/namespace. If >> you allow for changing the namespace/module name for "major" (i.e., >> incompatible) changes (i.e., like today) then this 3.1 requirement goes >> away. >> >> I think the plan is to reword some of these to get closer to the intention >> which I believe is to allow for smoother transition from one module to the >> next while making incompatible but mostly non-impacting changes. >> >> > You may find that reality interferes with your requirement. > The term "incompatible" should be a clue. If the change is genuinely > incompatible > then the underlying system change may be incompatible as well. > Passive operations like <get> are not a problem, but configuration > datastores > are a problem. There are good reasons that RFC 7950 says only 1 revision > of a module can be advertised by a server. > > There is already a practical solution that is available today. > A vendor can implement the server in a way that allows their customer to > select the appropriate revision for their use-cases and tools environment. > > So how does YANG validation work? > There is only 1 instance of <intended>. > E.g., i there are 3 versions of module A and 2 versions of module B, > then which versions does module C use for XPath validation that reference > modules A and B? Is a new version of XPath needed for YANG? > > It is possible to make a standard so complicated that nobody implements it. > > > Thanks, >> Chris. >> >> > Andy > > >> Andy Bierman <andy@yumaworks.com> writes: >> >> Hi, >>> >>> I strongly object to requirement 3.1: >>> >>> >>> 3.1 The solution MUST provide a mechanism to allow servers to >>> support existing clients in a backward compatible way. >>> >>> >>> >>> This is not what servers do today at all. >>> They provide only one version of an implemented module, as specified in >>> RFC >>> 7950. >>> >>> It is a vendor and operator decision when to upgrade a server such that >>> non-backward compatible changes are made. They must decide if/when it is >>> ok >>> based on the client applications in use. >>> >>> This requirement says you cannot make backward-incompatible changes >>> which completely contradicts requirements 1.1 and 1.2. >>> >>> IMO requirement 3.1 should be removed, or change MUST to MAY >>> >>> >>> Andy >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> >>
- [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