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

Andy Bierman <andy@yumaworks.com> Tue, 24 July 2018 16:07 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 7874E131162 for <netmod@ietfa.amsl.com>; Tue, 24 Jul 2018 09:07:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 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, URIBL_BLOCKED=0.001] 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 rzUiwONpiz2H for <netmod@ietfa.amsl.com>; Tue, 24 Jul 2018 09:07:15 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 2B7A5131156 for <netmod@ietf.org>; Tue, 24 Jul 2018 09:07:14 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id l16-v6so3347112lfc.13 for <netmod@ietf.org>; Tue, 24 Jul 2018 09:07:14 -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=catevl4XRe6ZQx5GlTAL/EMDpu1kfBnz/bUINOfmXCw=; b=rNfbmw4mm88jXEOrIajw7CwjD5OwS8q4qkvdW6Fn/6vewPPTpBYiBgjxXEdO5r/Cs9 EXLfXRozTL2q5ZQLwXOEHcQaw4l5/SaBL9h2aVBr8ZR/0WGKDxVXU6NsEdgHV7PvOTGw E4fRGob17lAoJ2hdoQHiF1p+RzwiSzSpcNyf2hfknm3jWyVxQWFqVCF0A+9rdYwHxkF8 2aNCmjzTyCxz/fOwJi2ujmiOc9RI4DrxoUIz6r4oRumBBwg6lXwBtSOPNSEWOrEsmcsA kLrHx2v3WZvIdvoZdh/RFsHH7hLTfODMNsrFEJNAPWCyhln3nwRtU9l5EWCTLhCzXMz2 giJA==
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=catevl4XRe6ZQx5GlTAL/EMDpu1kfBnz/bUINOfmXCw=; b=qDO6iuj+yp3yctOzg9JZnrvhum40nrnCNuPBhsA9EkaoxrqMsOk4ZpjDYxZAOR/Rrk JhuCTbBg0vbhPL2gjng2hWXOrQioZRJiMSw7js5KQcRrdNH7HphB9OM+xsyf9xHsVNwf PeDxBepRdgEoSeuXwlQfh9jSv00mkrwwEtzvF2E0n9fAesXVyVbIaU7nkMUWI1lN66kG Glpuag6PKUDOYUo2byf4Rgv+jv7UueHCc08wE4ai50n0bg+QRpP1xKF7NuLLJzK9fTwd REdPTjWuQ6sHpbZdhPBQRAtXGReGY7TYa/8bzZGMqn2QW4geFTUvwdaoPRToQdGhnD5J 2iqQ==
X-Gm-Message-State: AOUpUlE4A/9ukRWRD3Ztsz9co/iUSdqKIaDEEfcGVSItsHqAn85txFEl 28F/r1ymEc9JQw2PCcJdCs782ULDyqbeoY5OYSYs4A==
X-Google-Smtp-Source: AAOMgpdYjvx+IteEiFeN7I3eXS+D2qzQZEERokLn+/JOZJuV4W5lAENE+SQFxbKaYX7dFFnQwj17FmmK4lWv02tmzCQ=
X-Received: by 2002:a19:1460:: with SMTP id k93-v6mr10149425lfi.15.1532448432365; Tue, 24 Jul 2018 09:07:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Tue, 24 Jul 2018 09:07:11 -0700 (PDT)
In-Reply-To: <e386b70a-f99e-d631-32c2-e1092012ddff@cisco.com>
References: <CABCOCHQ47ztJTPaZMZK7FWHsRPk1jN6SuuAWtg08rmtVgUPEWw@mail.gmail.com> <87va981svk.fsf@chopps.org> <CABCOCHSkpn_=04qJP9m6TUA+doCjk0=BFG6jX9T4awj+CO-QdA@mail.gmail.com> <87tvos1cse.fsf@chopps.org> <20180724092908.ed36loiv3zrivs5d@anna.jacobs.jacobs-university.de> <CABCOCHQdwqB78JgNdB_UvhDTz5W-RM3XHajrhCQAgogj4T2VHQ@mail.gmail.com> <e386b70a-f99e-d631-32c2-e1092012ddff@cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 24 Jul 2018 09:07:11 -0700
Message-ID: <CABCOCHT4kw8nfNM+=25-RaK6hy6km1oCdMiaJABjSG_jtwEHvA@mail.gmail.com>
To: Robert Wilton <rwilton@cisco.com>
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Christian Hopps <chopps@chopps.org>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000072b72b0571c0f4ee"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/nQjJ6eCkz9i8QFpghJVt4q5g5Sk>
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: Tue, 24 Jul 2018 16:07:19 -0000

On Tue, Jul 24, 2018 at 8:32 AM, Robert Wilton <rwilton@cisco.com>; wrote:

>
>
> On 24/07/2018 16:11, Andy Bierman wrote:
>
>
>
> On Tue, Jul 24, 2018 at 2:29 AM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de>; wrote:
>
>> On Sat, Jul 21, 2018 at 05:47:45PM -0400, Christian Hopps wrote:
>>
>> > 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 strongly believe that fixing bugs is not a reason to change the
>> current versioning rules. Bugs come essentially in three flavors:
>>
>> - A definition is messed up (i.e., a range, a pattern, a must
>>   expression) but the original intention of the definition is clear
>>   from the context (description clauses, references, ...). In this
>>   case, implementors will likely have done the right thing (or when
>>   they observed the problem they will likely have done the right
>>   thing).
>>
>> - A definition is messed up but it is not clear from the context what
>>   the original intention of the definition was. In this case, there is
>>   a true ambiguity and implementors can rightfully have come to
>>   different conclusions how to deal with the conflict in the
>>   definition.
>>
>> In the first case, I believe there is no issue with simply fixing the
>> messed up definition. I believe this kind of bug fixes is not
>> constrained by the YANG update rules.
>>
>> In the second case, there is true ambiguity what implementations may
>> do and hence the safest approach is to deprecate the messed up
>> definition and to create a replacement.
>>
>> Of course, in reality, things are often not so clear cut and hence it
>> takes some informed judgement what is the reasonable way to deal with
>> things. (A type two bug caught very early may be different from a type
>> two bug caught after several months of implementation and deployment.)
>>
>> Sometimes we also have situations where a definition that was
>> originally OK turs out over time to be problematic as technology has
>> evolved. So after some time, the original definition starts to look
>> like a bug but it actually is not. The safe path forward is again to
>> create new definitions and to deprecate the old ones.
>>
>> Now, for those in favour of moving from (module, path) to (module,
>> path, version), you loose the deprecated definition. So if you wan't
>> to allow for a transition period, there is a need to allow an old
>> client to work with the old definition and a new client to work with
>> the new definition. In the current naming scheme, this is not a
>> problem, with a (module, path, version) naming scheme this requires
>> some extra complexity.
>>
>>
>
> The problem with versioning the "YANG API" is that it is not possible to
> isolate
> individual modules and say "I pick version 1.0.3 of module foo and version
> 2.1.1
> of module bar". And every client can pick a different arbitrary subset of
> mix-and-match YANG modules.
>
> Well YANG does not work that way.  There is no concept of a YANG package.
> There is no concept of a group of modules/versions/features that are
> not divisible within a server implementation.
>
> The other problem is what you are pointing out..
> It would be far easier to just fix the clients and the servers, not just
> the servers.
> Why is it OK for the client developer to decide "we are sticking with the
> defective version of the module and not going to upgrade to
> the fixed version like the server developers have done."
>
>
> One of the aims of the YANG versioning work is to give more information to
> the client about whether they are likely to be impacted by upgrading to a
> new set of modules.  For me, I think that the most useful thing is if this
> is done by comparing the full schema between old and new releases
> (including module versions, enabled features, and deviations), and then
> identifying the data nodes that have been changed in a backwards compatible
> way, and those that have been changed in a non backwards compatible way (if
> that is allowed).
>
> E.g. even it is a change is an obvious bugfix, it still makes sense to
> flag that change so that client implementations can be checked to ensure
> that they don't break.
>
> But if fixing a definition requires a whole new module name then I think
> that causes lots of problems (e.g. consider needing to change
> ief-interfaces to ietf-interfaces-v2 because of changing one random leaf).
> The YANG 1.1 way is to define a new definition and then deprecate the
> broken one.  But this has negative consequences as well, e.g. does writing
> to the old leaf automatically also write to the new leaf at the same time?
> Are both returned in a get request?  What if a different client only writes
> to the new leaf?
>
>
I agree a new module is not required.
I like SEMVER. It is still better to follow the YANG update rules, but I am
OK
with using the major version to indicate a non-backward-compatible change.
IMO it should not be fine-grained (e.g., SEMVER per object).
The scope of the standard should just be to identify versions with SEMVER
and fix import-stmt.

I think a server could version the API (all modules, not client-picked).
Not convinced this is a high priority at all, or that it would be easy to
standardize.

Thanks,
> Rob
>
>
Andy


>
>
>
> /js
>>
>
> Andy
>
>
>>
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
>>
>
>
>
> _______________________________________________
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
>