IETF Logo Mail Archive

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

Robert Wilton <rwilton@cisco.com> Mon, 23 July 2018 09:50 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 5BF04130DEB for <netmod@ietfa.amsl.com>; Mon, 23 Jul 2018 02:50:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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, 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 CgX_2vGaJy5r for <netmod@ietfa.amsl.com>; Mon, 23 Jul 2018 02:50:29 -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 1E39C130DE8 for <netmod@ietf.org>; Mon, 23 Jul 2018 02:50:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2691; q=dns/txt; s=iport; t=1532339429; x=1533549029; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=iPKwsXD49xhUGsmcUkyfboiy6fv5a+zBrb9e0WlmY6I=; b=ZlLawL+UBsE1gBFIn0jJs8yKdehhB1CuulVAQcZ3W35KZD+pwMhvh/MY eODblrMA56Sj1rC6d4fJzUyVXS3pxsrOKxmr89GQK6k/G0iq/0trofibu GXf7HEsc62NUHwNeJ4XlEFihGhHxYvda1KSRPaXVmxI1ThEyNpCHyhjyO 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DtAQDxo1Vb/xbLJq1cGgEBAQEBAgEBAQEIAQEBAYMfgRFtEiiDfohjjV+VUYFmCxgLhANGAoM8OBQBAgEBAgEBAm0cDIU2AQEBAQIBAQEhDwEFNhsJAg4KAgImAgInMAYBDAYCAQEXgwUBgXcID5JZm0eBLoRdhWoFgQuJTj+BESeCaoMbAQGBSAKDF4JVAogRhEuNEAmPKgaIIIVSjEyFVYFYIYFSMxoIGxU7gmmCTYhIhT8+MI8CAQE
X-IronPort-AV: E=Sophos;i="5.51,393,1526342400"; d="scan'208";a="5346238"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Jul 2018 09:50:27 +0000
Received: from [10.63.23.106] (dhcp-ensft1-uk-vla370-10-63-23-106.cisco.com [10.63.23.106]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id w6N9oQc9022106; Mon, 23 Jul 2018 09:50:27 GMT
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>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <a4ea8559-1f1f-8e7f-3dc5-29cb45fd4c7b@cisco.com>
Date: Mon, 23 Jul 2018 10:50:26 +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: <87va981svk.fsf@chopps.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
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-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/SQt4IFwcTkNXLyHTNp20s_kV4Ms>
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 09:50:32 -0000

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".

Thanks,
Rob


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

v2.23.0 | Report a Bug | By Email