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

Andy Bierman <andy@yumaworks.com> Mon, 23 July 2018 11:54 UTC

Return-Path: <andy@yumaworks.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 659B1130E06 for <netmod@ietfa.amsl.com>; Mon, 23 Jul 2018 04:54:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 jnogvOcIO6-L for <netmod@ietfa.amsl.com>; Mon, 23 Jul 2018 04:54:44 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19C6F130DD4 for <netmod@ietf.org>; Mon, 23 Jul 2018 04:54:44 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id y200-v6so254271lfd.7 for <netmod@ietf.org>; Mon, 23 Jul 2018 04:54:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bqvGc9kcnh1Yexbkj3+lufi+gmhi/+xFzVrTUo4708M=; b=z0O118ozCnfJas3njWhI6bvKVa4qW/S5ZuR8HZDW6htI3Mi0wankFmVqwvcBPwJxAd IvTLdq9OO44ZpqmvjgG0tRXdAfM2dLsouyp6KC7QcWscDBnC7fxsgK+/ROwgjM3N4swR fzir/1xHsKhRUSrVqvBmzYZIMpCYeHeJdjnhaYjcbeK12erN1hrETJABWGmmuGUjoarz DFIv3n8zGAf1rk6OquBf6rRQRGcl1KXMIyfpHXqRm4MolQ84hAoJEy/zJLlSINa+aWCZ e0GQOClgNRTHLvw6MUQzqAeergSKIQy8c51SMvbAV/HdsFW6hqoI1e4FdWDebZC8V30g N33g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bqvGc9kcnh1Yexbkj3+lufi+gmhi/+xFzVrTUo4708M=; b=n5UOmfS/t/l2LOWw42XpoIUgXld/kQJzxum1xuzahsnljQQ/jT32WnKV19/CgxuBRR iOtIVTjkKKgb3/0nHOAc/YPLpnF4IyhSDP4EDsEBE+aSY5dhwBnrRd7jOO2NptWxqewU TSVEjf08qe5Jr5Bmc8uvuJY+QAZBVXxmMgRuzatrOaIK1C9JB5uS8mg3HswLwdTgyqxw owfjfYFH93WUEPMxxlRKhb7jkQxEnBmJAImH/D6hHtVW9c0Vts67NL5VoE/slzte4Pvq Q2AU018uVAMxL5Pxh0DYupdHHpaGKiPqszrrb/PRZTgmyA3ooRE31Xt7/UsjuklDqZSs ccIg==
X-Gm-Message-State: AOUpUlEV/LCbt1+qWFquf9diTxZ417Oi61SvGm6tNbRS+UGDn8ROt9g8 F9VsgozuSpAd6Cr7cPuG4+q1pVB9L5PCMjfmOPyoyg==
X-Google-Smtp-Source: AAOMgpdVZNbw3NZ2+rmMkB0k8CH+rFHUcr3zfx4EzblygMih72WQyKZ5BYBQorQuy2O6ooU9y3JsmsR6H6HZqZleygA=
X-Received: by 2002:a19:2043:: with SMTP id g64-v6mr4631386lfg.66.1532346882238; Mon, 23 Jul 2018 04:54:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Mon, 23 Jul 2018 04:54:41 -0700 (PDT)
In-Reply-To: <a4ea8559-1f1f-8e7f-3dc5-29cb45fd4c7b@cisco.com>
References: <CABCOCHQ47ztJTPaZMZK7FWHsRPk1jN6SuuAWtg08rmtVgUPEWw@mail.gmail.com> <87va981svk.fsf@chopps.org> <a4ea8559-1f1f-8e7f-3dc5-29cb45fd4c7b@cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 23 Jul 2018 04:54:41 -0700
Message-ID: <CABCOCHT-NukBjvr6O02Meuz7fzD=8g5HvWNwkkEazQiLAsGM7A@mail.gmail.com>
To: Robert Wilton <rwilton@cisco.com>
Cc: Christian Hopps <chopps@chopps.org>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000096c0540571a94f96"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/gUWcruFL4Y4zVFU3quN2gyIkSpg>
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 11:54:48 -0000

On Mon, Jul 23, 2018 at 2:50 AM, Robert Wilton <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.
You can write the word MUST in all caps as many times as you want,
but that will not change anything.



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