Subject: [netmod] 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: 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.
>

---

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: Robert Wilton <[email-masked]>
Date: Fri, 26 Oct 2018 10:17:48 +0100

Hi Chris,

On 25/10/2018 18:42, Christian Hopps wrote:
>
> 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.
I think that everyone on design team agrees that 
non-backwards-compatible changes should be minimized and should really 
only to used for bug fixes where it is anticipated that clients should 
not be affected.

We want to allow non-backwards-compatible changes at the head of the 
development tree, but again, I think that everyone agrees that keeping 
it backwards compatible where possible is a good goal.

However, I think that there will be cases where a vendor decides that it 
is right for an enhancement or non backwards compatible change to be 
made to an already released module.  I agree that this is highly 
undesirable and an abuse of the rules, but I don't believe that whatever 
versioning scheme we come up with will prevent vendors from doing this.  
So then the question becomes: Is it better to pretend that this scenario 
will never happen, design the versioning scheme so that it cannot be 
expressed, which probably just means that clients will not be able to 
detect when vendors do this by cheating the rules!  Or is it better to 
accept that this will sometimes occur, provide strong guidance as to why 
this is bad practice and should be avoided, but have a versioning scheme 
that still allows this to be expressed (in a bounded way)?  I.e. even if 
the vendors are doing something that is less than ideal, at least the 
clients can spot where they have done this.

---

A separate concern that we had about ties this strictly to bug fixes is 
that some one will ask for a definition of a bug fix.  The design team 
tried this but we couldn't even agree what a bug fix is, let alone agree 
with a single definition of a bug fix as it related to a YANG module.  
So our conclusion was that perhaps it is better not to tie the 
requirements themselves to bug fix vs enhancement, because the boundary 
between the two is too vague, and module writers will bend the rules.

So I see that the rules should be:
  - backwards compatible bug fix  - this is fine.
  - non backwards compatible bug fix - this is fine if it is 
pragmatically expected to not impact any clients, but careful 
consideration is required if it might break clients.
  - backwards compatible enhancement - not ideal, but pragmatically OK.
  - non backwards compatible enhancement - this is bad and should be 
avoided.

But if we don't want to define the difference between a bug fix vs 
enhancement then I think that you end up with the most general 
requirement being that we do want to allow for non-backwards-compatible 
changes in released modules to accommodate the bug fix scenario, but the 
expectation (and guidance) will be that they should only be used for bug 
fixes.

>
> For example:
>
>> 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.
>
> 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.
I agree.  It was a backwards compatible enhancement that I was considering.

Thanks,
Rob

>> which I
>>> [ 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.
>>>
>>>
>>> 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: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 26 Oct 2018 11:33:47 +0200

Let me add that there was large disagreement what a bug fix is in the
design team. Hence, any text that talks about 'bug fixes' is ambiguous
and of limited value to achieve consensus. (Or we may find consensus
but then not agree on what we have found consensus on.)

To be more concrete, I learned that Rob's notion of a bug fix is very
different from my notion of a bug fix. I think it is important for
having a productive discussion to be aware of this.

For me, a bug fix is rather limited, i.e., fixing something where the
correct intention was clear but the model did not properly capture the
intention correctly, i.e., roughly what we can do with errata in the
IETF. I think Rob understands bug fixes in a much broader sense,
including fixes to what essentially are in my view module design
errors.

With my narrow definition of bug fixes, bug fixes are essentially
backwards compatible (even if they may violate RFC 7950 rules - but as
long as the original intention was clear, we can be flexible).

With Rob's notion of bug fixes, we have to handle them as part of the
versioning system since they may be non-backwards compatible.

/js

On Fri, Oct 26, 2018 at 10:17:48AM +0100, Robert Wilton wrote:
> > 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.
> I think that everyone on design team agrees that non-backwards-compatible
> changes should be minimized and should really only to used for bug fixes
> where it is anticipated that clients should not be affected.
> 
> development tree, but again, I think that everyone agrees that keeping it
> backwards compatible where possible is a good goal.
> 
> However, I think that there will be cases where a vendor decides that it is
> right for an enhancement or non backwards compatible change to be made to an
> already released module.  I agree that this is highly undesirable and an
> abuse of the rules, but I don't believe that whatever versioning scheme we
> come up with will prevent vendors from doing this.  So then the question
> becomes: Is it better to pretend that this scenario will never happen,
> design the versioning scheme so that it cannot be expressed, which probably
> just means that clients will not be able to detect when vendors do this by
> cheating the rules!  Or is it better to accept that this will sometimes
> occur, provide strong guidance as to why this is bad practice and should be
> avoided, but have a versioning scheme that still allows this to be expressed
> (in a bounded way)?  I.e. even if the vendors are doing something that is
> less than ideal, at least the clients can spot where they have done this.
> 
> ---
> 
> A separate concern that we had about ties this strictly to bug fixes is that
> some one will ask for a definition of a bug fix.  The design team tried this
> but we couldn't even agree what a bug fix is, let alone agree with a single
> definition of a bug fix as it related to a YANG module.  So our conclusion
> was that perhaps it is better not to tie the requirements themselves to bug
> fix vs enhancement, because the boundary between the two is too vague, and
> module writers will bend the rules.
> 
>  - non backwards compatible bug fix - this is fine if it is pragmatically
> expected to not impact any clients, but careful consideration is required if
> it might break clients.
>  - non backwards compatible enhancement - this is bad and should be avoided.
> 
> enhancement then I think that you end up with the most general requirement
> being that we do want to allow for non-backwards-compatible changes in
> released modules to accommodate the bug fix scenario, but the expectation
> (and guidance) will be that they should only be used for bug fixes.
> 
> 
> > 
> > For example:
> > 
> > > 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.
> > 
> > need/requirement to support non-backward compatible changes to existing
> > modules in order to support enhancements.
> > > > [ 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?
> > > > 
> > > > "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.
> > > > 
> > > > 
> > > > 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.
> > > > 

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 26 Oct 2018 09:35:39 -0700

> versioning system since they may be non-backwards compatible.

IMO requirements 3.1 and 3.2 are the most  important and have the most
impact
on the solution space. I do not agree with either of these requirements.

Implementing multiple non-compatible revisions of a module on a server
sounds hard,
not to mention that it breaks RFC 7950 rules. The current protocols do not
support the
ability to specify different versions of the same QName. This change makes
YANG validation
much to difficult to specify and implement (as that has to be rewritten as
well).

It is one thing to deploy rapidly changing, buggy YANG modules in order to
gain experience quickly.  It is quite another to complicate YANG and the
protocols
to preserve these interim mistakes, and bake into the standards the notion
that this
is good engineering.

/js

Andy

> is
> that
> requirement

---

From: Robert Wilton <[email-masked]>
Date: Fri, 26 Oct 2018 19:15:18 +0100

On 26/10/2018 17:35, Andy Bierman wrote:
>
>
> On Fri, Oct 26, 2018 at 2:33 AM, Juergen Schoenwaelder 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
OK.

For 3.1, I think that just means that the solution has to be backwards 
compatible with existing clients (e.g. don't change the protocols in a 
non backwards compatible way).

> not to mention that it breaks RFC 7950 rules.
Completely agree that it will be hard.  I envisage that it will optional 
for servers to implement this.

> The current protocols do not support the
> ability to specify different versions of the same QName. This change 
> makes YANG validation
> much to difficult to specify and implement (as that has to be 
> rewritten as well).
The way that I think of one solution for this problem is using datastore 
schema (as per the NMDA definition):

Say for release X, the server natively supports Module [email-masked] and 
[email-masked], call this schema X.
For release Y, the server natively supports Module [email-masked] and 
[email-masked], call this schema Y.

When a client connects it chooses which schema it wants to use, X, Y, or 
latest.  If it doesn't specify then perhaps it uses the earliest schema 
(to handle requirement 3.1).

If the client wants to use X, then the server has to translate the 
request into the equivalent request using schema Y instead.  Perhaps the 
server has to validate the config both in the context of X and Y.

If the clients wants to use Y then it just talks to the server normally, 
i.e. as it does today.

I think that this is logically the equivalent model mapping that clients 
would have to do to support multiple server revisions.  Yes, I think 
that it is complex.  No, I'm not sure how many vendors will decide to 
implement this, but I think that it is OK to require the solution to 
specify how this is done, so that servers that do want to support this, 
and clients that want to use this, can do so.

But all the QNames, validations, etc, I think would be constrained to a 
particular schema.

> gain experience quickly..  It is quite another to complicate YANG and 
> the protocols
> to preserve these interim mistakes, and bake into the standards the 
> notion that this
> is good engineering.
Thanks,
Rob

>     sympathetic
>     non-backwards-compatible
>     pragmatically
>     existing
>     > > Robert Wilton <[email-masked] <mailto:[email-masked]>>
>     writes:
>     > >
>     > > > Hi Chris,
>     > > >
>     > > > What I regard as the key one, is that we want to be able to
>     support
>     > > > the software
>     > > > 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
>     > > > (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
>     > > > The second thing driving this requirement is that vendors
>     sometimes
>     > > > get asked
>     > > > for enhancements to existing releases, perhaps because the
>     latest
>     > > > development
>     > > > 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
>     > > > is necessary to make changes that sometimes break these
>     rules, and
>     > > > having a
>     > > > operator doesn't get any useful indication of what type of
>     changes
>     > > > are being
>     > > > made.
>     > > >
>     > > > Thanks,
>     > > > Rob
>     > > >
>     > > >
>     > > > > > On Oct 20, 2018, at 1:55 PM, Joe Clarke
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     > > > > >
>     > > > > How many operators/users have asked for this or indicated
>     it's a
>     > > > > requirement for them?
>     > > > >
>     > > > > magnifying it greatly) to other people in the community..
>     > > > >
>     > > > > Thanks,
>     > > > > Chris.
>     > > > >
>     > > > > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/netmod>
>     > > > > .
>     > > > >
>     > >
>     > > .
>     > >
>     >
>     > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/netmod>
>
>     -- 
>     Fax:   +49 421 200 3103         <https://www.jacobs-university.de/
>     <https://www.jacobs-university.de/>>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/netmod>
>
>
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 27 Oct 2018 01:01:48 +0200

> to preserve these interim mistakes, and bake into the standards the notion

So how do you think this conflict between more agility and client
stability should be handled? It seems you can't easily have both at
the same time. Are you saying that backwards compatibility to support
existing clients is not important?

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 26 Oct 2018 16:36:26 -0700

On Fri, Oct 26, 2018 at 4:01 PM, Juergen Schoenwaelder <
[email-masked]> wrote:

> makes
> notion
It depends on the data model and how broken it is in the replaced version.
YANG validation is slow and complicated enough without pretending there
are 8 or 10 separate schema trees within a datastore. It might be impossible
for all constraints to be true in all schema trees at once.  It is a burden
on operators
and client developers to understand and properly manage multiple
incompatible revisions
of the same module

yang-library is a good example of a clean break.
The /yang-library tree completely replaces the /modules-state tree.
A server can easily support both subtrees.
No new YANG or protocol features are needed at all.
This was not a bugfix, just the normal instability in the IETF.

Even with this clean break, there could be external modules that have
leafref
or must/when that point at the /modules-state subtree.  They have to be
rewritten
to use /yang-library instead. But this can happen as needed since the old
tree is unchanged.

For truly broken changes (e.g. change a node from a container to a list;
change a leaf from type boolean to an enumerated type w/ 6 enums;
remove or rename lots of existing nodes) the cross-references from external
modules can easily be incorrect if used with the new version.

The NETMOD WG chose to add a new /yang-library tree instead of
mangling the existing nodes. One design choice makes req. 3.1 easy and 3.2
not needed.
Another - just the opposite.

Andy

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 27 Oct 2018 10:36:28 +0200

> mangling the existing nodes. One design choice makes req. 3.1 easy and 3.2

       3.1  The solution MUST provide a mechanism to allow servers to
            support existing clients in a backwards-compatible way.

I believe 3.1 is exactly what we have today. If it is necessary to
make incompatible changes, you create new definitions. This allows
servers to support existing clients in a backwards-compatible way (as
long as the old and new definitions are not conflicting.)

       3.2  The solution MUST provide a mechanism to allow servers to
            simultaneously support clients using different revisions of
            modules.  A client's choice of particular revision of one or
            more modules may restrict the particular revision of other
            modules that may be used in the same request or session.

Today, the version number is effectively an (implicit) part of the
module name (plus the revision date for backwards compatible changes).
Hence, my understanding is that today's model does satisfy 3.2 as
well.

If we want to increase 'agility' in an attempt to make it easier to
deliver early designs and to fix them on the go, the costs will go up
somewhere. The extreme cases are:

1) The server can make changes to YANG modules in arbitrary ways and
   the clients have to adapt, i.e., clients have to pay the bill.

2) The server has to provide strict backwards compatibility in order
   to not break clients, i.e., servers have to pay the bill.

The question is whether there is a solution somewhere in the middle
that balances the costs and eases the process of adapting clients to
servers and vice versa. It might very well be that there is no sweet
point.

Unless we go for option 1) above, I believe 3.1 and 3.2 are valid and
important requirements.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 27 Oct 2018 06:50:58 -0700

On Sat, Oct 27, 2018 at 1:36 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > > > not to mention that it breaks RFC 7950 rules. The current protocols
> do
> > > not
> > > > support the
> > > as
> > > > It is one thing to deploy rapidly changing, buggy YANG modules in
> order
> > > to

This is what we have today only if modules are updated in legal ways.
The 3.1 requirement says this backward compatibility is maintained even
if the module is updated in violation of the module update rules.

How would 3.1 be met if the WG decided to just add a new 'datastore' key
leaf
to the /modules-state/module list?

IMO the current "deprecate and start over" is actually the easiest and most
robust
solution path, and it requires no changes to YANG or the protocols.

> Hence, my understanding is that today's model does satisfy 3.2 as

This is not what we have at all. RFC 7950 says a server can only implement
one revision of a module.

>    to not break clients, i.e., servers have to pay the bill.
This is not correct. Implementing multiple incompatible revisions of a
module
(e.g, "module" list keyed 2 different ways) is a huge bill to pay for the
server developer.

> Unless we go for option 1) above, I believe 3.1 and 3.2 are valid and

I do not agree with the premise that non-compatible data model updates are
required.
3.1 can be achieved without such changes. 3.2 violates RFC 7950, requiring
a new(much more complicated) version of YANG

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 27 Oct 2018 23:13:55 +0200

> if the module is updated in violation of the module update rules.

It is stating a requirement. How solutions meet the requirement is for
the solutions to figure out.

> How would 3.1 be met if the WG decided to just add a new 'datastore'
> key leaf to the /modules-state/module list?

Depends on the solution I guess.
 
> IMO the current "deprecate and start over" is actually the easiest
> and most robust solution path, and it requires no changes to YANG or
> the protocols.

Yep. But there are people who think that other solutions can do
better. The challenge is to find out whether they actually do better
or for whom they do better (and if someone has to pay a price for it).
For having this discussions, it is good to write down requirements.

> one revision of a module.

A new version today essentially means a new module name and I do not
see a conflict with what I wrote.

> (e.g, "module" list keyed 2 different ways) is a huge bill to pay for the

Depends on the details and the developer will decide based on the
impact on the clients and whether a transition period is possible. You
seem to read that the requirement says one has to implement backwards
compatibility. This is not what the text says. The text says it must
be possible.

> a new(much more complicated) version of YANG

I think you misread the requirements text.

/js