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

Robert Wilton <rwilton@cisco.com> Mon, 23 July 2018 13:25 UTC

Return-Path: <rwilton@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 2A90C130DF3 for <netmod@ietfa.amsl.com>; Mon, 23 Jul 2018 06:25:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, 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 RiCxMv82vyNE for <netmod@ietfa.amsl.com>; Mon, 23 Jul 2018 06:25:01 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C09B130DD0 for <netmod@ietf.org>; Mon, 23 Jul 2018 06:25:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13323; q=dns/txt; s=iport; t=1532352301; x=1533561901; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=6G3UnWlimXBI3GsTh0tGt1dJSSt+BsWeAQD2SSyV5bc=; b=OCOPZclePjsO2inAndwqxfr4IqhPDKxeiBkE8Usl+yv8e6CY5AghyFSo sgfkrX1RINTbIqfCE0gjuRKkWG/DEK071ahXv2iTJUrt8Gpk4Hbgn1fVE TZvmA7Sj/dMnhyAPbddA8n5hFTNEQNoulDOGAsYLaeY9zzq78+/yJzreP w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AfAgBx1lVb/xbLJq1bGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYMfgRFtEiiDfohjjTQskC2FJIFmCxgBCoQDRgKDPjgUAQIBAQI?= =?us-ascii?q?BAQJtHAyFNgEBAQECAQEBIUsLBQsJAhgnAwICJx8RBg0GAgEBF4MFAYF3CA+?= =?us-ascii?q?SbptHgS4fhD6FbAWKWT+BESeCaoMbAQGBSAKDF4JVAogRhEuFHId0CY8qBog?= =?us-ascii?q?ghVKMTIVVgVghJoEsMxoIGxU7gmmBdViISIU/PjCORwEB?=
X-IronPort-AV: E=Sophos;i="5.51,393,1526342400"; d="scan'208,217";a="5352791"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jul 2018 13:24:58 +0000
Received: from [10.63.23.106] (dhcp-ensft1-uk-vla370-10-63-23-106.cisco.com [10.63.23.106]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id w6NDOvET016168; Mon, 23 Jul 2018 13:24:57 GMT
To: Andy Bierman <andy@yumaworks.com>
Cc: Christian Hopps <chopps@chopps.org>, NetMod WG <netmod@ietf.org>
References: <CABCOCHQ47ztJTPaZMZK7FWHsRPk1jN6SuuAWtg08rmtVgUPEWw@mail.gmail.com> <87va981svk.fsf@chopps.org> <a4ea8559-1f1f-8e7f-3dc5-29cb45fd4c7b@cisco.com> <CABCOCHT-NukBjvr6O02Meuz7fzD=8g5HvWNwkkEazQiLAsGM7A@mail.gmail.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <fd9ff226-b0a1-53f4-1b98-b4f6ecf3ce01@cisco.com>
Date: Mon, 23 Jul 2018 14:24:57 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CABCOCHT-NukBjvr6O02Meuz7fzD=8g5HvWNwkkEazQiLAsGM7A@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------9FF4C864440748C42D689175"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.63.23.106, dhcp-ensft1-uk-vla370-10-63-23-106.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/JswKpQiMWgVR5HsORuxQDfgrwuA>
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: Mon, 23 Jul 2018 13:25:04 -0000


On 23/07/2018 12:54, Andy Bierman wrote:
>
>
> On Mon, Jul 23, 2018 at 2:50 AM, Robert Wilton <rwilton@cisco.com 
> <mailto:rwilton@cisco.com>> wrote:
>
>     Hi Chris, Andy,
>
>
>     On 21/07/2018 17:00, Christian Hopps 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.
>
>     Not sure that I agree.
>
>     I think that you have made an assumption here that the server will
>     continue to support both old and new major revision (with
>     different name) of the module at the same time.  However, these is
>     nothing in the existing YANG upgrade rules that requires that.
>
>     Ultimately, there is a choice whether supporting older module
>     versions is the servers problem or the clients problem, or perhaps
>     a combination of the two.
>
>     The aim of requirement 3.1 is to ensure that there is a standard
>     mechanism available so that server implementations that want the
>     flexibility of supporting older client versions have a standard
>     way of doing so.  My intention is that this part of the solution
>     would be optional to implement and hence decided by the market,
>     which is why the text in the requirement is "to allow servers"
>     rather than "to require servers".
>
>
>
> API versioning is usually done on the message exchanges.
> Trying to do the same for datastore contents is not going to work.
A YANG schema can be considered an API.  Particularly looking at say the 
OpenConfig YANG schema.  I doubt all implementations will store all 
their configuration and operational state in a central place.

> You can write the word MUST in all caps as many times as you want,
> but that will not change anything.

I disagree.  Marking a requirement as a MUST means that requirement has 
to be met for a solution to be considered viable.

I previously had some text in the draft explaining how RFC 2119 text 
translates to evaluating the requirements, but was asked to take it out 
because it is obvious.  Perhaps it should go back in ...

Thanks,
Rob

>     Thanks,
>     Rob
>
>
> Andy
>
>
>
>
>         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 <mailto: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 <mailto:netmod@ietf.org>
>             https://www.ietf.org/mailman/listinfo/netmod
>             <https://www.ietf.org/mailman/listinfo/netmod>
>
>
>         _______________________________________________
>         netmod mailing list
>         netmod@ietf.org <mailto:netmod@ietf.org>
>         https://www.ietf.org/mailman/listinfo/netmod
>         <https://www.ietf.org/mailman/listinfo/netmod>
>         .
>
>
>