Subject: [Netmod-ver-dt] Fwd: New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

From: Joe Clarke <[email-masked]>
Date: Sat, 20 Oct 2018 13:55:12 -0400

The netmod YANG versioning design team has updated the requirements
draft based on comments received at IETF 102 as well as some individual
discussions.  Highlights include:

* Definition of "non-backwards-compatible"

* Clarification on what clients should do with backwards-compatibly
changed instance data

* Reworded requirement 1.2 to avoid needless client work for unchanged
nodes or nodes that were changed in backwards-compatible ways

* New requirement 1.4 for supporting over-arching software releases

Joe (on behalf of the DT)

-------- Forwarded Message --------
Subject: New Version Notification for
draft-verdt-netmod-yang-versioning-reqs-01.txt
Date: Sat, 20 Oct 2018 10:50:23 -0700
From: [email-masked]
To: Joe Clarke <[email-masked]>

A new version of I-D, draft-verdt-netmod-yang-versioning-reqs-01.txt
has been successfully submitted by Joe Clarke and posted to the
IETF repository.

Name:		draft-verdt-netmod-yang-versioning-reqs
Revision:	01
Title:		YANG Module Versioning Requirements
Document date:	2018-10-20
Group:		Individual Submission
Pages:		12
URL:
https://www.ietf.org/internet-drafts/draft-verdt-netmod-yang-versioning-reqs-01.txt
Status:
https://datatracker.ietf.org/doc/draft-verdt-netmod-yang-versioning-reqs/
Htmlized:
https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-01
Htmlized:
https://datatracker.ietf.org/doc/html/draft-verdt-netmod-yang-versioning-reqs
Diff:
https://www.ietf.org/rfcdiff?url2=draft-verdt-netmod-yang-versioning-reqs-01

Abstract:
   This document describes the problems that can arise because of the
   YANG language module update rules, that require all updates to YANG
   module preserve strict backwards compatibility.  It also defines the
   requirements on any solution designed to solve the stated problems.
   This document does not consider possible solutions, nor endorse any
   particular solution.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Christian Hopps <[email-masked]>
Date: Thu, 25 Oct 2018 11:26:25 -0400

> On Oct 20, 2018, at 1:55 PM, Joe Clarke <[email-masked]> wrote:
> 

[ I read this as supporting various different module versions based on a vendor's different software release trains. If this is wrong then the rest of this doesn't apply and I would just ask for the text to be update to clarify what it means. ]

How many operators/users have asked for this or indicated it's a requirement for them?

What problem is intractable without this requirement being met, and what is the cost of this requirement on the actual users?

I have pushed back multiple times on this b/c I believe this "requirement" is really being pushed to make it easier for vendors (a small affected group) to develop their software at the cost of their users (the much larger affected group) who would then have to deal with multiple trains of the same module.

Here is what I am afraid the vendors want here: A developer on release train X can easily change some data structure and then push the change into an automated system which generates a new YANG module definition and revs a version number -- all done! They don't have to deal with the inertia of making this change in their release train Y or Z and they don't have to treat modules as a stable API they are exporting, b/c they now have these new wonderful versions from this work. Meanwhile we the users now have to deal with N forks with all the various little incompatible changes random developers at the company wanted to make without having to coordinate with their coworkers/other internal teams. Now multiply this by M vendors. It's a nightmare. It shouldn't be what we are optimizing for, let alone making a requirement.

We already have features and deviations why are they not enough to deal with functionality that is present or not in various software release/devices?

FWIW I'm not against making it easier to develop software, but we have to be mindful if we are just pushing the cost (and magnifying it greatly) to other people in the community.

Thanks,
Chris.

---

From: Robert Wilton <[email-masked]>
Date: Thu, 25 Oct 2018 17:29:37 +0100

Hi Chris,

I think that there are two things driving this requirement:

What I regard as the key one, is that we want to be able to support the 
software that we have shipped.  In particular, we may need to fix bugs 
(perhaps at the operators request) to a YANG model that has already been 
released.  I.e. I think that there are some scenarios, where forking a 
YANG module, although undesirable is the right thing to do to include a 
fix.  I don't believe that features or deviations help solve this problem.

The two alternative solutions to being able to fix bugs, neither of 
which I think is pragmatic, that I can think of are:
(i) Vendors ensure that their YANG modules are perfect before they ship 
in a release.
(ii) If a bug is reported, operators are happy to wait until the bug has 
been fixed in the current development release, and will migrate to that 
latest release to pick up the fix.

The second thing driving this requirement is that vendors sometimes get 
asked for enhancements to existing releases, perhaps because the latest 
development release is too far out, or ask for an enhancement on the 
current train to be back ported to an older release.

So, aiming to have stable YANG modules, trying a lot harder to avoid 
non-backwards-compatible changes, and keeping new functionality to the 
head of the development I completely agree with you on.  But I still 
believe that there are some valid scenarios, that should be limited as 
much as possible, where it is necessary to make changes that sometimes 
break these rules, and having a limited scheme that clearly indicates 
where such breakages have occurred is probably better that the status 
quo of where the modules get changed, but the operator doesn't get any 
useful indication of what type of changes are being made.

Thanks,
Rob

On 25/10/2018 16:26, Christian Hopps wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
> .
>

---

From: Christian Hopps <[email-masked]>
Date: Thu, 25 Oct 2018 13:42:44 -0400

Hi Rob,

We've more privately discussed the bug-fix scenario and I'm sympathetic to it; however, the requirement as written does not restrict itself to fixing module definition bugs (e.g., a pattern or other value constraint) in some small but incompatible way -- instead it's wide open and it will be [ab]used that way.

> Here is what I am afraid the vendors want here: A developer on release train X can easily change some data structure and then push the change into an automated system which generates a new YANG mod…

Regarding enhancements, these are features, and are naturally augmentative. I find it hard to believe we have a pressing need/requirement to support non-backward compatible changes to existing modules in order to support enhancements.

Thanks,
Chris.

Robert Wilton <[email-masked]> writes:

> What I regard as the key one, is that we want to be able to support the software
> that we have shipped. In particular, we may need to fix bugs (perhaps at the
> operators request) to a YANG model that has already been released. I.e. I think
> that there are some scenarios, where forking a YANG module, although undesirable
> is the right thing to do to include a fix. I don't believe that features or
> deviations help solve this problem.
> The two alternative solutions to being able to fix bugs, neither of which I
> think is pragmatic, that I can think of are:
> (i) Vendors ensure that their YANG modules are perfect before they ship in a
> release.
> (ii) If a bug is reported, operators are happy to wait until the bug has been
> fixed in the current development release, and will migrate to that latest
> release to pick up the fix.
>
> The second thing driving this requirement is that vendors sometimes get asked
> for enhancements to existing releases, perhaps because the latest development
> release is too far out, or ask for an enhancement on the current train to be
> back ported to an older release.
>
> non-backwards-compatible changes, and keeping new functionality to the head of
> the development I completely agree with you on. But I still believe that there
> are some valid scenarios, that should be limited as much as possible, where it
> is necessary to make changes that sometimes break these rules, and having a
> limited scheme that clearly indicates where such breakages have occurred is
> probably better that the status quo of where the modules get changed, but the
> operator doesn't get any useful indication of what type of changes are being
> made.
>
> Thanks,
> Rob
>
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 25 Oct 2018 10:07:54 -0700

> > * New requirement 1.4 for supporting over-arching software releases
This text?

       1.4  The solution MUST allow for modules to be versioned by
            software release.  In particular, backwards-compatible
            enhancements and bug fixes MUST be allowed in any non-latest
            release.

IMO these requirements are mostly intended to legitimize bad practices be
server vendors,
entirely at the expense of client developers.

It is clear that SEMVER is required to support this requirement to
treat every platform as an isolated release of what are supposed to be
shared modules.
The revision date no longer identifies the latest (e.g, 1.6.1 could have a
newer date than 1.9.0)
However, SEMVER becomes less useful if 1.6.1 actually has more features
than 1.9.0.

YANG clients already have to deal with different variants (revision,
features, deviations) on every server,
so it would be easy to think that all these server variants are not a new
problem.
However, this only applies to parsing incoming data.  A client that is
designed to
formulate requests against specific data models is greatly harmed by a lack
of server
consistency.

If YANG is ever going to grow up, the 3rd party client development needs to
be taken more seriously.

Andy

[ I read this as supporting various different module versions based on a
> vendor's different software release trains. If this is wrong then the rest
> of this doesn't apply and I would just ask for the text to be update to
> clarify what it means. ]
>
> What problem is intractable without this requirement being met, and what
> is the cost of this requirement on the actual users?
>
> I have pushed back multiple times on this b/c I believe this "requirement"
> is really being pushed to make it easier for vendors (a small affected
> group) to develop their software at the cost of their users (the much
> larger affected group) who would then have to deal with multiple trains of
> the same module.
>
> Here is what I am afraid the vendors want here: A developer on release
> train X can easily change some data structure and then push the change into
> an automated system which generates a new YANG module definition and revs a
> version number -- all done! They don't have to deal with the inertia of
> making this change in their release train Y or Z and they don't have to
> treat modules as a stable API they are exporting, b/c they now have these
> new wonderful versions from this work. Meanwhile we the users now have to
> deal with N forks with all the various little incompatible changes random
> developers at the company wanted to make without having to coordinate with
> their coworkers/other internal teams. Now multiply this by M vendors. It's
> a nightmare. It shouldn't be what we are optimizing for, let alone making a
> requirement.
>
> We already have features and deviations why are they not enough to deal
> with functionality that is present or not in various software
> release/devices?
>
> FWIW I'm not against making it easier to develop software, but we have to
> be mindful if we are just pushing the cost (and magnifying it greatly) to
> other people in the community.
>
> Thanks,
> Chris.
>