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

Andy Bierman <> Tue, 24 July 2018 16:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7874E131162 for <>; Tue, 24 Jul 2018 09:07:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rzUiwONpiz2H for <>; Tue, 24 Jul 2018 09:07:15 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B7A5131156 for <>; Tue, 24 Jul 2018 09:07:14 -0700 (PDT)
Received: by with SMTP id l16-v6so3347112lfc.13 for <>; Tue, 24 Jul 2018 09:07:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <>
References: <> <> <> <> <> <> <>
From: Andy Bierman <>
Date: Tue, 24 Jul 2018 09:07:11 -0700
Message-ID: <>
To: Robert Wilton <>
Cc: Juergen Schoenwaelder <>, Christian Hopps <>, NetMod WG <>
Content-Type: multipart/alternative; boundary="00000000000072b72b0571c0f4ee"
Archived-At: <>
Subject: Re: [netmod] backward compatibility requirements in draft-verdt-netmod-yang-versioning-reqs-00
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Jul 2018 16:07:19 -0000

On Tue, Jul 24, 2018 at 8:32 AM, Robert Wilton <>; wrote:

> On 24/07/2018 16:11, Andy Bierman wrote:
> On Tue, Jul 24, 2018 at 2:29 AM, Juergen Schoenwaelder <
>>; 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
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

> Rob

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