Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00

Christian Hopps <chopps@chopps.org> Sat, 21 July 2018 16:00 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 7174D130E6B for <netmod@ietfa.amsl.com>; Sat, 21 Jul 2018 09:00:19 -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 6gCx-dR-nw50 for <netmod@ietfa.amsl.com>; Sat, 21 Jul 2018 09:00:17 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7D8130DD3 for <netmod@ietf.org>; Sat, 21 Jul 2018 09:00:17 -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 BCA18633EB; Sat, 21 Jul 2018 16:00:16 +0000 (UTC)
References: <CABCOCHQ47ztJTPaZMZK7FWHsRPk1jN6SuuAWtg08rmtVgUPEWw@mail.gmail.com>
User-agent: mu4e 1.0; emacs 26.1
From: Christian Hopps <chopps@chopps.org>
To: Andy Bierman <andy@yumaworks.com>
Cc: NetMod WG <netmod@ietf.org>
In-reply-to: <CABCOCHQ47ztJTPaZMZK7FWHsRPk1jN6SuuAWtg08rmtVgUPEWw@mail.gmail.com>
Date: Sat, 21 Jul 2018 12:00:15 -0400
Message-ID: <87va981svk.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/XcWlktrB9pJAcTXUUlfL7IZxR9g>
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 16:00:20 -0000

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.

Thanks,
Chris.

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