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

[Andy Bierman <[e-mail]>]

On Tue, Jul 24, 2018 at 8:32 AM, Robert Wilton <[e-mail]> wrote:

>
>
> On 24/07/2018 16:11, Andy Bierman wrote:
>
>
>
> On Tue, Jul 24, 2018 at 2:29 AM, Juergen Schoenwaelder <
> [e-mail]> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   [phone]         <https://www.jacobs-university.de/>
>>
>
>
>
> _______________________________________________
> netmod mailing [e-mail]://www.ietf.org/mailman/listinfo/netmod
>
>
>