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 > > >
- [netmod] backward compatibility requirements in d… Andy Bierman
- Re: [netmod] backward compatibility requirements … Juergen Schoenwaelder
- Re: [netmod] backward compatibility requirements … Juergen Schoenwaelder
- Re: [netmod] backward compatibility requirements … Andy Bierman
- Re: [netmod] backward compatibility requirements … Juergen Schoenwaelder
- Re: [netmod] backward compatibility requirements … Andy Bierman
- Re: [netmod] backward compatibility requirements … Christian Hopps
- Re: [netmod] backward compatibility requirements … Andy Bierman
- Re: [netmod] backward compatibility requirements … Christian Hopps
- Re: [netmod] backward compatibility requirements … Robert Wilton
- Re: [netmod] backward compatibility requirements … Andy Bierman
- Re: [netmod] backward compatibility requirements … Robert Wilton
- Re: [netmod] backward compatibility requirements … Andy Bierman
- Re: [netmod] backward compatibility requirements … Robert Wilton
- Re: [netmod] backward compatibility requirements … Andy Bierman
- Re: [netmod] backward compatibility requirements … Kent Watsen
- Re: [netmod] backward compatibility requirements … Juergen Schoenwaelder
- Re: [netmod] backward compatibility requirements … Andy Bierman
- Re: [netmod] backward compatibility requirements … Robert Wilton
- Re: [netmod] backward compatibility requirements … Andy Bierman
- Re: [netmod] backward compatibility requirements … Juergen Schoenwaelder
- Re: [netmod] backward compatibility requirements … Robert Wilton
- Re: [netmod] backward compatibility requirements … Juergen Schoenwaelder
- Re: [netmod] backward compatibility requirements … Robert Wilton
- Re: [netmod] backward compatibility requirements … Juergen Schoenwaelder
- Re: [netmod] backward compatibility requirements … Robert Wilton
- Re: [netmod] backward compatibility requirements … Christian Hopps
- Re: [netmod] backward compatibility requirements … Kent Watsen