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

Andy Bierman <andy@yumaworks.com> Tue, 24 July 2018 15:12 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 9ED95131125 for <netmod@ietfa.amsl.com>; Tue, 24 Jul 2018 08:12:01 -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 EzVxwhQ-gnH9 for <netmod@ietfa.amsl.com>; Tue, 24 Jul 2018 08:11:58 -0700 (PDT)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 E60E5131117 for <netmod@ietf.org>; Tue, 24 Jul 2018 08:11:57 -0700 (PDT)
Received: by mail-lj1-x22d.google.com with SMTP id q5-v6so3896672ljh.12 for <netmod@ietf.org>; Tue, 24 Jul 2018 08:11:57 -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; bh=KMy+N9o/jcFO4a8JLGtpDNts/A6obcleAyOHXUyPbLw=; b=o//ztf5QIkkq3jPRd/nGwOgoWgrj0TZd9iQPgBfCg6GwvYD6yM/YV9eBBHpUMOGOSK GDiiWyezhVV3Vpw67XVNbfOLUzAG+hMPDynsjZHj3Tuf/OACBq0LQ84ugMn3L+jtv2nT SJiVwOzKQIpmwZZc6aotRW44y+zvR7Ncgi3PGYOVij3olnx0u3dR9L3miQlYwcIkejls w0TV47u9eO9QEiuUqajl27c/vk2O2JyoEtXl3UJfuO5T+NDnLoEYR+kQeDCXmn4Hk+M9 sZ2A0NaPBn5xFhjUqJ/jCm44XQ/cHCv+/za6iyhilkzDy4C8lhmLp/y9CYMsiqFShqFS JcyA==
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; bh=KMy+N9o/jcFO4a8JLGtpDNts/A6obcleAyOHXUyPbLw=; b=Ygk1ghKsbfwYYhMAgNBaGLieH50vDUXpkdIY8SIAEJrNLs2zzqZ/WC+LOPNX0+kDJk TiGRPva30D7FRj+eOL/41mxruhbxSKEkoL2Z2TZbjvnc+O1AHj4+EZeAn9naiMVs4LKh unuyFdZ7bJG/IrMDFt7Nk1olWD/gUPkPFH+XPh+lcFK7YD4Z0X+6M5xPHmBzSbKAPzKA 7xeXn3jUv5lD19K6tXjHAimIpwWXIik5f1WEG37m3LAG5OY51bDU8RmTKIBKR9dEZrWu cy9N2uuBDWh+p2rcvL+/9mJXqbxZ/cB+YqzLkOa0gKScFyHE5RQVAyRu5+ymqDe7be6d P5YA==
X-Gm-Message-State: AOUpUlFqt0JrBASWFlWXOlceqHmzPqv9LdQe6HzTCVM52CfXe+PpCgjT GAyQYK0gawz+8CpTukLCWfIp/hOhtGPVsNIUkg9eZuKo
X-Google-Smtp-Source: AAOMgpdiiCvKEwAe8zQcKFupBNZdLhLKq52s3Au9RIsz5/z41dHQrKFp6OPNhwq7uFh7/LgJnWMYmlP9gUgf2yRymF0=
X-Received: by 2002:a2e:97c8:: with SMTP id m8-v6mr13427231ljj.52.1532445116111; Tue, 24 Jul 2018 08:11:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:aa46:0:0:0:0:0 with HTTP; Tue, 24 Jul 2018 08:11:54 -0700 (PDT)
In-Reply-To: <20180724092908.ed36loiv3zrivs5d@anna.jacobs.jacobs-university.de>
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>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 24 Jul 2018 08:11:54 -0700
Message-ID: <CABCOCHQdwqB78JgNdB_UvhDTz5W-RM3XHajrhCQAgogj4T2VHQ@mail.gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Christian Hopps <chopps@chopps.org>, Andy Bierman <andy@yumaworks.com>, NetMod WG <netmod@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c8a9650571c02e10"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ONz9QrSfy0qJ2ygUpugnCClY0LQ>
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 15:12:02 -0000

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


/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/>
>