Subject: [netmod] adoption poll for yang-versioning-reqs-02

From: Kent Watsen <[email-masked]>
Date: Wed, 13 Mar 2019 20:22:02 +0000

Seeing as how we all need to read this draft anyways, in preparation for our meeting in Prague, it seems like a good time for this poll.  Thusly, this email begins a 1-week adoption poll for:

    https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02 <https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02>

Please voice your support or objections before March 20.

Note that this draft defines *requirements* and its intended status is "Informational."   I believe that it is good for WGs to formalize requirements, even taking such drafts thru Last Call, in order to ensure consensus on the requirements.  This is the "adoption" call, to ascertain if the WG agrees with that statement; if adopted, a separate "last call" will be issued to ensure to correctness of the draft's content.

Kent (and Lou and Joel)

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 14 Mar 2019 15:17:50 +0000

I support the draft. (Contributor)

regards Balazs

On 2019. 03. 13. 21:22, Kent Watsen
wrote:

Seeing as how we all need to read this draft anyways, in
preparation for our meeting in Prague, it seems like a good time
for this poll.  Thusly, this email begins a 1-week adoption poll
for:

https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02

Please voice your support or objections before
March 20.

Note that this draft defines *requirements* and
its intended status is "Informational."   I believe that it is
good for WGs to formalize requirements, even taking such
drafts thru Last Call, in order to ensure consensus on the
requirements.  This is the "adoption" call, to ascertain if
the WG agrees with that statement; if adopted, a separate
"last call" will be issued to ensure to correctness of the
draft's content.

Kent (and Lou and Joel)

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]

---

From: Joe Clarke <[email-masked]>
Date: Thu, 14 Mar 2019 12:57:22 -0400

On 3/13/19 16:22, Kent Watsen wrote:
> Seeing as how we all need to read this draft anyways, in preparation for
> our meeting in Prague, it seems like a good time for this poll.  Thusly,
> this email begins a 1-week adoption poll for:
> 

As a contributor to the document, I support adoption of this draft.

Joe

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 14 Mar 2019 17:19:05 +0000

As a contributor, I support WG adoption of this draft.

Thanks,
Rob

From: netmod <[email-masked]> On Behalf Of Kent Watsen
Sent: 13 March 2019 20:22
To: [email-masked]
Subject: [netmod] adoption poll for yang-versioning-reqs-02

Kent (and Lou and Joel)

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Sun, 17 Mar 2019 21:23:22 +0000

As contributor, I support adoption of this document by the WG.

Regards,
Reshad.

From: netmod <[email-masked]> on behalf of Kent Watsen <[email-masked]>
Date: Wednesday, March 13, 2019 at 4:22 PM
To: "[email-masked]" <[email-masked]>
Subject: [netmod] adoption poll for yang-versioning-reqs-02

Kent (and Lou and Joel)

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 19 Mar 2019 16:12:29 +0100 (CET)

Hi,

I have read this document, and I do not think it should be adopted.

I object to the idea that we should allow non-backwards-compatible
changes to published YANG modules.

The draft motivates this idea with:

   we must recognize that many YANG
   modules are actually generated YANG modules (for example, from
   internal databases)

I do not agree that we should change what we allow in published
modules b/c of this.

It also motivates this idea with:

   The points made above lead to the logical conclusion that the
   standardized YANG modules have to be perfect on day one (at least the
   structure and meaning), which in turn might explain why IETF YANG
   modules take so long to standardize.

I disagree with this.  First of all, we have already published
revision two of several YANG modules (ietf-inet-types, ietf-yang-type,
ietf-interfaces, ietf-ip, ietf-routing, ...), so the statement that
"standardized YANG modules have to be perfect on day one" is simply
not true.

Second, I don't think the upgrade rules are the reason it takes a long
time to standardize IETF models (I think it has to do with the process
itself, including the fact that models get reviews from many different
people with different background.)  [BTW, is it true that drafts with
YANG models take longer time from wg -00 to published RFC than other
drafts?]

This said, I think there are some important points that the draft
raises, and that I think we should continue to work on; specifically
2.3, 2.5, 2.6, 2.7.  But I don't think that these areas require
changes to the versioning scheme, and I think it is a mistake to
include these areas in this draft.

Some comments on section 4, The Problem Statement:

   o  Any non-backwards-compatible change of a definition requires
      either a new module name or a new path.  This has been found
      costly to support in implementations, in particular on the client
      side.

Yes I agree there is a cost associated with this.  But I have come
across vendor modules that make NBC changes w/o introducing a new
path, and this is also costly to handle.

   o  Since non-backwards-compatible changes require either a new module
      name or a new path, such changes will impact other modules that
      import definitions.  In fact, with the current module versioning
      scheme other modules have to opt-in in order to use the new
      version.  This essentially leads to a ripple effect where a non-
      backwards-compatible change of a core module causes updates on a
      potentially large number of dependent modules.

This is by design.  We cannot have a situation where a legal
modification to a module leads to other modules becoming invalid.

   o  YANG has a mechanism to mark definitions deprecated but it leaves
      it open whether implementations are expected to implement
      deprecated definitions and there is no way (other than trial and
      error) for a client to find out whether deprecated definitions are
      supported by a given implementation.

As I wrote above, I agree that this is a problem that should be
solved.  But this is not a motivation for changing YANG versioning.

   o  YANG does not have a robust mechanism to document which data
      definitions have changed and to provide guidance how
      implementations should deal with the change.  While it is possible
      to have this described in general description statements, having
      these details embedded in general description statements does not
      make this information accessible to tools.

This might also be worth exploring, but this is not a motivation for
changing YANG versioning.

/martin

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 19 Mar 2019 16:37:46 +0000

Hi Martin,

Thanks for the review and comments.

A couple of points:
 
1) Lots of models outside those published in SDOs are already not following the RFC 7950 revision rules.  I think that it is better to have a versioning scheme that reflects how YANG models are actually evolving rather than have all vendor and OC YANG modules either just ignoring the rules, or using clever tricks that strictly conform with the rules but go against the spirit of them (e.g. just publish an entirely new set of YANG modules for each release).  Also noting that having a scheme that allows non-backwards-compatible changes does not require that everyone uses them - IETF could continue to always publish backwards compatible modules.  The obvious alternative here is that each vendor comes up with their own versioning extension and ignores the RFC 7950 section 11 rules anyway, but I'm not sure how that really helps client<->server interop.

2) I don't understand how the RFC 7950 approach of "deprecate a buggy node, and replace with a working node" really works in practice, particularly for configuration data nodes where you have two clients interacting with a server, one interacting with the old path, and another using the new path.  Perhaps there is a robust scheme that works in all cases, but it isn't obvious to me.  Historically, for CLI we just translate the CLI from old to new format and then return the new format when the running config is requested.  But that will still break an old client that doesn't understand how to read the new CLI, even if the server supports them writing via the old CLI.

Even if there is a workable solution for this simple case, I suspect that there are many slightly more complicated cases that don't work (e.g. rekeying a list, changing defaults, incompatible types).

In short, I don't agree with the premise that the current YANG versioning schema using revision dates is working just fine, and no changes are needed.

Thanks,
Rob

-----Original Message-----
From: netmod <[email-masked]> On Behalf Of Martin Bjorklund
Sent: 19 March 2019 15:12
To: [email-masked]
Cc: [email-masked]
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02

Hi,

I object to the idea that we should allow non-backwards-compatible changes to published YANG modules.

I do not agree that we should change what we allow in published modules b/c of this.

I disagree with this.  First of all, we have already published revision two of several YANG modules (ietf-inet-types, ietf-yang-type, ietf-interfaces, ietf-ip, ietf-routing, ...), so the statement that "standardized YANG modules have to be perfect on day one" is simply not true.

Second, I don't think the upgrade rules are the reason it takes a long time to standardize IETF models (I think it has to do with the process itself, including the fact that models get reviews from many different people with different background.)  [BTW, is it true that drafts with YANG models take longer time from wg -00 to published RFC than other drafts?]

This said, I think there are some important points that the draft raises, and that I think we should continue to work on; specifically 2.3, 2.5, 2.6, 2.7.  But I don't think that these areas require changes to the versioning scheme, and I think it is a mistake to include these areas in this draft.

Yes I agree there is a cost associated with this.  But I have come across vendor modules that make NBC changes w/o introducing a new path, and this is also costly to handle.

This is by design.  We cannot have a situation where a legal modification to a module leads to other modules becoming invalid.

As I wrote above, I agree that this is a problem that should be solved.  But this is not a motivation for changing YANG versioning.

This might also be worth exploring, but this is not a motivation for changing YANG versioning.

/martin

Kent Watsen <[email-masked]> wrote:
> <https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-0
> 2>
>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 19 Mar 2019 11:35:21 -0700

On Tue, Mar 19, 2019 at 9:38 AM Rob Wilton (rwilton) <[email-masked]>
wrote:

> 1) Lots of models outside those published in SDOs are already not
> following the RFC 7950 revision rules.  I think that it is better to have a
> versioning scheme that reflects how YANG models are actually evolving
> rather than have all vendor and OC YANG modules either just ignoring the
> rules, or using clever tricks that strictly conform with the rules but go
> against the spirit of them (e.g. just publish an entirely new set of YANG
> modules for each release).  Also noting that having a scheme that allows
> non-backwards-compatible changes does not require that everyone uses them -
> IETF could continue to always publish backwards compatible modules.  The
> obvious alternative here is that each vendor comes up with their own
> versioning extension and ignores the RFC 7950 section 11 rules anyway, but
> I'm not sure how that really helps client<->server interop.
>
>

I do not support branching for YANG models so I do not supported modified
SEMVER.
Adding a special character to the version string doesn't help the deployed
client code
that stops working when the server code is upgraded.  This is a quality
issue that
each organization has to deal with the best they can.

I do not object to the addition of a SEMVER field to a YANG module because
these version
strings are familiar to users.  It is possible to express import ranges
such as 1.2.* (any 1.2.x release)
which are not possible with date strings.

2) I don't understand how the RFC 7950 approach of "deprecate a buggy node,
> and replace with a working node" really works in practice, particularly for
> configuration data nodes where you have two clients interacting with a
> server, one interacting with the old path, and another using the new path.
> Perhaps there is a robust scheme that works in all cases, but it isn't
> obvious to me.  Historically, for CLI we just translate the CLI from old to
> new format and then return the new format when the running config is
> requested.  But that will still break an old client that doesn't understand
> how to read the new CLI, even if the server supports them writing via the
> old CLI.
>
>
SEMVER does not reduce the number of paths to the underlying configuration
object.
That problem does not change whether a new XPath absolute-path-expr is used
or whether the same path is overloaded with semantics derived from
additional protocol parameters
(e.g., versioning of each data node). I prefer the existing XPath solution
because it is explicit
so the YANG reader can easily see the multiple paths, and no new protocol
work needed to support it.
If there is an NBC change to an object then all XPath and leafref
references to it will probably break.
That seems like a harder problem to solve than the original path
duplication problem.

Even if there is a workable solution for this simple case, I suspect that
> there are many slightly more complicated cases that don't work (e.g.
> rekeying a list, changing defaults, incompatible types).
>
> In short, I don't agree with the premise that the current YANG versioning
> schema using revision dates is working just fine, and no changes are needed.
>
> Thanks,
> Rob
>
>
Andy

> I disagree with this.  First of all, we have already published revision
> two of several YANG modules (ietf-inet-types, ietf-yang-type,
> "standardized YANG modules have to be perfect on day one" is simply not
> true.
>
> people with different background.)  [BTW, is it true that drafts with YANG
> models take longer time from wg -00 to published RFC than other drafts?]
>
>
> This said, I think there are some important points that the draft raises,
> and that I think we should continue to work on; specifically 2.3, 2.5, 2.6,
> 2.7.  But I don't think that these areas require changes to the versioning
> scheme, and I think it is a mistake to include these areas in this draft.
>
> Yes I agree there is a cost associated with this.  But I have come across
> vendor modules that make NBC changes w/o introducing a new path, and this
> is also costly to handle.
>
> This is by design.  We cannot have a situation where a legal modification
> to a module leads to other modules becoming invalid.
>
> As I wrote above, I agree that this is a problem that should be solved.
> But this is not a motivation for changing YANG versioning.
>
> > Note that this draft defines *requirements* and its intended status is
> "Informational."   I believe that it is good for WGs to formalize
> requirements, even taking such drafts thru Last Call, in order to ensure
> consensus on the requirements.  This is the "adoption" call, to ascertain
> if the WG agrees with that statement; if adopted, a separate "last call"
> will be issued to ensure to correctness of the draft's content.
> >
> > Kent (and Lou and Joel)
> >
> >
>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 20 Mar 2019 08:30:22 +0100 (CET)

Hi,

"Rob Wilton (rwilton)" <[email-masked]> wrote:
> following the RFC 7950 revision rules.

Right, and I think that is ok.  If vendors want to break backwards
compatibility it is up to them.  With the current rules you can have
tool that detect this and flags it.  You can then fix the problem or
release the new NBC module anyway, but you have been warned.
Customers will accept this or not.

> I think that it is better to
> have a versioning scheme that reflects how YANG models are actually
> evolving rather than have all vendor and OC YANG modules either just
> ignoring the rules, or using clever tricks that strictly conform with
> the rules but go against the spirit of them (e.g. just publish an
> entirely new set of YANG modules for each release).  Also noting that
> having a scheme that allows non-backwards-compatible changes does not
> require that everyone uses them - IETF could continue to always
> publish backwards compatible modules.  The obvious alternative here is
> that each vendor comes up with their own versioning extension and
> ignores the RFC 7950 section 11 rules anyway, but I'm not sure how
> that really helps client<->server interop.

The client<->server interop will not magically work better if we allow
NBC changes.

> 2) I don't understand how the RFC 7950 approach of "deprecate a buggy
> node, and replace with a working node" really works in practice,
> particularly for configuration data nodes where you have two clients
> interacting with a server, one interacting with the old path, and
> another using the new path.  Perhaps there is a robust scheme that
> works in all cases, but it isn't obvious to me.  Historically, for CLI
> we just translate the CLI from old to new format and then return the
> new format when the running config is requested.  But that will still
> break an old client that doesn't understand how to read the new CLI,
> even if the server supports them writing via the old CLI.
> 
> Even if there is a workable solution for this simple case, I suspect
> that there are many slightly more complicated cases that don't work
> (e.g. rekeying a list, changing defaults, incompatible types).

I fully agree.  This is difficult in the general case.  In the worst
case you'll have to give up on backwards compatibility and only
implement the new version of the module (I believe this is possible
both with the current versioning rules, and with the proposed rules).

> In short, I don't agree with the premise that the current YANG
> versioning schema using revision dates is working just fine, and no
> changes are needed.

But this is not what the draft is about!  There is nothing in the
draft that talks about problems introduced by using the revision
dates.

/martin

> > Seeing as how we all need to read this draft anyways, in preparation
> > for our meeting in Prague, it seems like a good time for this poll.
> > Thusly, this email begins a 1-week adoption poll for:
> > 
> >     
> > requirements, even taking such drafts thru Last Call, in order to
> > ensure consensus on the requirements.  This is the "adoption" call, to
> > ascertain if the WG agrees with that statement; if adopted, a separate
> > "last call" will be issued to ensure to correctness of the draft's
> > content.
> > 
> > Kent (and Lou and Joel)
> > 
> > 
>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 20 Mar 2019 11:54:18 +0000

Hi Andy,

Thanks for the comments.

1. Regular Semver 2.0.0 (as per semver.org) allows some branching.  I.e. you can create version 2.0.0 based of version 1.1.0, and then subsequently create version 1.2.0 based of 1.1.0.  So structure wise this would logically look like:

   1.0.0
      | \
      |   1.1.0 – 1.2.0 - …
      |
   2.0.0
      |

I also raised https://github.com/semver/semver/issues/504  on the semver 2.0.0 github to confirm that my interpretation is correct, and no one has disputed it yet.

2. Vendor software releases can have a very long support time (e.g. easily 5+ years), with an expectation that bugs get fixed.  Requiring that customers upgrade their software (or perhaps hardware) to the very latest software version to pick up a small bug fix is not realistic.  This is primarily why I think that the ‘m’ and ‘M’ are so important.  They allow for bug fixes in a way that Semver 2.0.0 simply does not.

Semver 2.0.0 only allows for bugfixes in the implementation (by updating the patch version number), but has the expectation that there are *never* any non-backwards-compatible changes in the API, not even to fix a bug, except at the tip of the development tree.

In short, I think that vanilla Semver 2.0.0 is a good fit for open source projects where you can just tell the client to update to the latest version to pick up the fix.  I don’t think that Semver 2.0.0 is so well aligned to APIs that are required to be maintained for long periods of time.

The alternative that Rob Shakir mentioned at IETF 103 in the context of OpenConfig, which uses strict Semver 2.0.0, is to handle these bug fixes using deviations.  But it seems to be significantly more complex to manage bug fixes using extra deviation modules rather than allowing the ‘m’ | ‘M’ modifiers.  Versioning would no longer limited to a module version number, but require knowledge of the module version and set of deviations that are applied to it.  I would rather deviations are reserved to indicate whether an implementation doesn’t match the module specification rather than use them as a way of fixing bugs in the specification itself.

3. I agree that the use of Semver + packages + version selection does not reduce the overall number of paths to a configurable property, but it does ensure that there is only a single path to a configurable property within a YANG datastore schema.   So whichever version each client is using, they only use a single path.  I.e. mirroring the way that a classic programming API might be versioned.

Servers that wish to support this would have to map the data between different YANG datastore schema versions.  Not all mappings are possible, but at least any cases where it is not possible can be detected and reported to the client via an out of band mechanism.

If the module content changes significantly between module versions that mapping will be much harder than if the changes are minimal or backwards compatible.  So there is still a strong incentive for model writers to minimize churn to the YANG models.

Thanks,
Rob

From: Andy Bierman <[email-masked]>
Sent: 19 March 2019 18:35
To: Rob Wilton (rwilton) <[email-masked]>
Cc: Martin Bjorklund <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02

On Tue, Mar 19, 2019 at 9:38 AM Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Martin,

A couple of points:

I do not support branching for YANG models so I do not supported modified SEMVER.
Adding a special character to the version string doesn't help the deployed client code
that stops working when the server code is upgraded.  This is a quality issue that
each organization has to deal with the best they can.

I do not object to the addition of a SEMVER field to a YANG module because these version
strings are familiar to users.  It is possible to express import ranges such as 1.2.* (any 1.2.x release)
which are not possible with date strings.

SEMVER does not reduce the number of paths to the underlying configuration object.
That problem does not change whether a new XPath absolute-path-expr is used
or whether the same path is overloaded with semantics derived from additional protocol parameters
(e.g., versioning of each data node). I prefer the existing XPath solution because it is explicit
so the YANG reader can easily see the multiple paths, and no new protocol work needed to support it.
If there is an NBC change to an object then all XPath and leafref references to it will probably break.
That seems like a harder problem to solve than the original path duplication problem.

Thanks,
Rob

Andy

-----Original Message-----
From: netmod <[email-masked]<mailto:[email-masked]>> On Behalf Of Martin Bjorklund
Sent: 19 March 2019 15:12
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02

Hi,

/martin

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 20 Mar 2019 12:21:51 +0000

Hi Martin,

> From: Martin Bjorklund <[email-masked]>
> Sent: 20 March 2019 07:30
> Cc: [email-masked]; [email-masked]
> Right, and I think that is ok.  If vendors want to break backwards compatibility it
> is up to them.  With the current rules you can have tool that detect this and flags
> it.  You can then fix the problem or release the new NBC module anyway, but
> you have been warned.

[RW] 
Revision-dates don't help here, and are not sufficient to indicate the true version history of a module when it is not chronologically ordered.

Vendors want a way to accurately communicate to clients how the module is actually being changed, in a way that is easier for them to understand.

> The client<->server interop will not magically work better if we allow NBC
> changes.
[RW] 
It helps clients understand the nature of the changes.

I don't believe that vendors are making NBC changes to make client lives harder, they are trying to fix bugs and make their software better.  I obviously agree that it would be better to put more effort into producing higher quality models in the first place, but there will always be mistakes, particularly for vendor models that have much less peer review than YANG modules produced by SDOs.

> I fully agree.  This is difficult in the general case.  In the worst case you'll have to
> give up on backwards compatibility and only implement the new version of the
> module (I believe this is possible both with the current versioning rules, and with
> the proposed rules).
[RW] 
Implementing a new module and not supporting the old to fix one leaf has a massive impact:
 - it breaks all clients using that module (regardless of whether they were using the leaf)
 - it forces updates to all modules that augment or depend on the old module.

Say we hypothetically decide that "link-up-down-trap-enable" in RFC 8343 is wrong should be mandatory true.  Is the right solution here really to define a new "ietf-interfaces-2" YANG module and require all 50 or so YANG modules that augment IETF interfaces to be updated?

It seems that this would be a much more impactful change than allowing an NBC change to that module, and documenting that as version 2.0.0.

I am sure that if YANG allows NBC changes then some folks will use them for purposes that they should not.  But I also believe that those same folk will make those same changes regardless of what an RFC states.  But I also think that many vendors will try and use NBC changes as a way to make their models better, improve the quality of YANG data models.

> But this is not what the draft is about!  There is nothing in the draft that talks
> about problems introduced by using the revision dates.
[RW] 

I think that "revision-date" and RFC 7950 section 11 module update rules go hand in hand.

If your objection is that we don't quite describe the problem clearly enough then that can be fixed.

 My interpretation is that your objection is more fundamental than that.  I.e. you don't think that we should be using semantic versioning at all, and we should keep RFC 7950 section 11 rules and revision dates for versioning YANG models.  But I think that the overwhelming evidence is that the current scheme does not work for everyone, even if it might be sufficient for YANG modules produced in the IETF.

Thanks,
Rob

> > > Note that this draft defines *requirements* and its intended status
> > > is "Informational."  I believe that it is good for WGs to formalize
> > > ensure consensus on the requirements.  This is the "adoption" call,
> > > to ascertain if the WG agrees with that statement; if adopted, a
> > > separate "last call" will be issued to ensure to correctness of the
> > > draft's content.
> > >
> > > Kent (and Lou and Joel)
> > >
> > >
> >

---

From: Andy Bierman <[email-masked]>
Date: Wed, 20 Mar 2019 06:48:20 -0700

On Wed, Mar 20, 2019 at 4:54 AM Rob Wilton (rwilton) <[email-masked]>
wrote:

> Hi Andy,
>
>
>
> Thanks for the comments.
>
>
>
> 1. Regular Semver 2.0.0 (as per semver.org) allows some branching.  I.e.
> you can create version 2.0.0 based of version 1.1.0, and then subsequently
> create version 1.2.0 based of 1.1.0.  So structure wise this would
> logically look like:
>
>
>
>    1.0.0
>
>       | \
>
>       |   1.1.0 – 1.2.0 - …
>
>       |
>
>    2.0.0
>
>       |
>
>
>
> I also raised https://github.com/semver/semver/issues/504  on the semver
> 2.0.0 github to confirm that my interpretation is correct, and no one has
> disputed it yet.
>
>
>

The numbering may allow it, but it is not really being used that way.
I don't think the YANG standard needs to support branching in this way.

>
>
> 2. Vendor software releases can have a very long support time (e.g. easily
> 5+ years), with an expectation that bugs get fixed.  Requiring that
> customers upgrade their software (or perhaps hardware) to the very latest
> software version to pick up a small bug fix is not realistic.  This is
> primarily why I think that the ‘m’ and ‘M’ are so important.  They allow
> for bug fixes in a way that Semver 2.0.0 simply does not.
>
>
>
> Semver 2.0.0 only allows for bugfixes in the implementation (by updating
> the patch version number), but has the expectation that there are **never**
> any non-backwards-compatible changes in the API, not even to fix a bug,
> except at the tip of the development tree.
>
>
>
> In short, I think that vanilla Semver 2.0.0 is a good fit for open source
> projects where you can just tell the client to update to the latest version
> to pick up the fix.  I don’t think that Semver 2.0.0 is so well aligned to
> APIs that are required to be maintained for long periods of time.
>
>
>
> The alternative that Rob Shakir mentioned at IETF 103 in the context of
> OpenConfig, which uses strict Semver 2.0.0, is to handle these bug fixes
> using deviations.  But it seems to be significantly more complex to manage
> bug fixes using extra deviation modules rather than allowing the ‘m’ | ‘M’
> modifiers.  Versioning would no longer limited to a module version number,
> but require knowledge of the module version and set of deviations that are
> applied to it.  I would rather deviations are reserved to indicate whether
> an implementation doesn’t match the module specification rather than use
> them as a way of fixing bugs in the specification itself.
>
>
>

I agree that deviations should be used instead of branching.
You can cherry-pick features from the latest very easily with deviations.
IMO it is more accurate to say the implementation supports version X minus
some features,
rather than assigning some version string to mean the same thing.  This
approach can get
out of control very quickly if multiple independent release trains exist. I
prefer a linear
development progression, and each implementation will identity its
functionality the same way.

>
> 3. I agree that the use of Semver + packages + version selection does not
> reduce the overall number of paths to a configurable property, but it does
> ensure that there is only a single path to a configurable property within a
> YANG datastore schema.   So whichever version each client is using, they
> only use a single path.  I.e. mirroring the way that a classic programming
> API might be versioned.
>
>
>
> Servers that wish to support this would have to map the data between
> different YANG datastore schema versions.  Not all mappings are possible,
> but at least any cases where it is not possible can be detected and
> reported to the client via an out of band mechanism.
>
>
>
> If the module content changes significantly between module versions that
> mapping will be much harder than if the changes are minimal or backwards
> compatible.  So there is still a strong incentive for model writers to
> minimize churn to the YANG models.
>
>
>

I don't think the versioning data nodes is a good idea.
I have seen entire REST APIs be versioned, but not individual parameters
within the API.
How do you version the must/when/path references from other objects that
point at the data node?
Sounds way too complex to manage.

Andy

>
>
> *From:* Andy Bierman <[email-masked]>
> *Sent:* 19 March 2019 18:35
> *To:* Rob Wilton (rwilton) <[email-masked]>
> *Cc:* Martin Bjorklund <[email-masked]>; [email-masked];
> [email-masked]
> *Subject:* Re: [netmod] adoption poll for yang-versioning-reqs-02
>
>
>
>
>
>
>
> interacting with a server, one interacting with the old path, and another
> using the new path.  Perhaps there is a robust scheme that works in all
> cases, but it isn't obvious to me.  Historically, for CLI we just translate
> the CLI from old to new format and then return the new format when the
> running config is requested.  But that will still break an old client that
> doesn't understand how to read the new CLI, even if the server supports
> them writing via the old CLI.
>
>
>

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 20 Mar 2019 14:54:39 +0100 (CET)

"Rob Wilton (rwilton)" <[email-masked]> wrote:
> > compatibility it
> Revision-dates don't help here, and are not sufficient to indicate the
> true version history of a module when it is not chronologically
> ordered.
> 
> Vendors want a way to accurately communicate to clients how the module
> is actually being changed, in a way that is easier for them to
> understand.

If I'm at 1.0.1M and see 1.0.2M it doesn't help me much.

> > NBC

The draft we talk about does not mention anything about helping
clients understand the diffs, BC or not.

> I don't believe that vendors are making NBC changes to make client
> lives harder, they are trying to fix bugs and make their software
> better.  I obviously agree that it would be better to put more effort
> into producing higher quality models in the first place, but there
> will always be mistakes, particularly for vendor models that have much
> less peer review than YANG modules produced by SDOs.
> 
> 
> > 
> > case you'll have to
> Implementing a new module and not supporting the old to fix one leaf

This is a strawman; I never recommended changing an entire module to
fix one leaf.

> has a massive impact:
> Say we hypothetically decide that "link-up-down-trap-enable" in RFC
> 8343 is wrong should be mandatory true.  Is the right solution here
> really to define a new "ietf-interfaces-2" YANG module and require all
> 50 or so YANG modules that augment IETF interfaces to be updated?
> 
> It seems that this would be a much more impactful change than allowing
> an NBC change to that module, and documenting that as version 2.0.0.
> 
> I am sure that if YANG allows NBC changes then some folks will use
> them for purposes that they should not.  But I also believe that those
> same folk will make those same changes regardless of what an RFC
> states.  But I also think that many vendors will try and use NBC
> changes as a way to make their models better, improve the quality of
> YANG data models.
> 
> 
> > 
> > draft that talks
>  My interpretation is that your objection is more fundamental than
>  that.

Yes.

>  I.e. you don't think that we should be using semantic
>  versioning at all

My objection is that I don't agree with the problem statement and I
don't think that we should allow NBC in published modules.

/martin

> , and we should keep RFC 7950 section 11 rules and
>  revision dates for versioning YANG models.  But I think that the
>  overwhelming evidence is that the current scheme does not work for
>  everyone, even if it might be sufficient for YANG modules produced in
>  the IETF.
> 
> Thanks,
> Rob
> 
> 
> > 
> > 
> > /martin
> > 
> > 
> > 
> > >
> > > Thanks,
> > > Rob
> > >
> > >

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 20 Mar 2019 16:44:22 +0000

Hi Andy,

Regarding:
> I have seen entire REST APIs be versioned, but not individual parameters within the API.
> How do you version the must/when/path references from other objects that point at the data node?

The YANG packages and version selection drafts both propose that the entire API is versioned.  In fact it regards IETF models, vs OpenConfig models, vs Native vendor models as separate APIs.

Thanks,
Rob

Sent: 20 March 2019 13:48

On Wed, Mar 20, 2019 at 4:54 AM Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Andy,

Thanks for the comments.

1. Regular Semver 2.0.0 (as per semver.org<http://semver.org>) allows some branching.  I.e. you can create version 2.0.0 based of version 1.1.0, and then subsequently create version 1.2.0 based of 1.1.0.  So structure wise this would logically look like:

   1.0.0
      | \
      |   1.1.0 – 1.2.0 - …
      |
   2.0.0
      |

I agree that deviations should be used instead of branching.
You can cherry-pick features from the latest very easily with deviations.
IMO it is more accurate to say the implementation supports version X minus some features,
rather than assigning some version string to mean the same thing.  This approach can get
out of control very quickly if multiple independent release trains exist. I prefer a linear
development progression, and each implementation will identity its functionality the same way.

I don't think the versioning data nodes is a good idea.
I have seen entire REST APIs be versioned, but not individual parameters within the API.
How do you version the must/when/path references from other objects that point at the data node?
Sounds way too complex to manage.

Thanks,
Rob

Andy

From: Andy Bierman <[email-masked]<mailto:[email-masked]>>
Sent: 19 March 2019 18:35
To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>
Cc: Martin Bjorklund <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02

A couple of points:

Thanks,
Rob

Andy

-----Original Message-----
From: netmod <[email-masked]<mailto:[email-masked]>> On Behalf Of Martin Bjorklund
Sent: 19 March 2019 15:12
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02

Hi,

/martin

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 20 Mar 2019 18:10:02 +0000

Hi Martin,

> Sent: 20 March 2019 13:55

[RW] 
In this case the client has to diff the YANG modules.  This is the same as going from 1.0.0 to 2.0.0.

The aim of the 'm'|'M' is to *allow* models to be fixed with NBC changes if required, it is not intended to encourage models to have lots of NBC changes.  I.e. the scheme is deliberately restricted in the information that it conveys as a means to prevent model authors from having carte blanche when updating models.  It is meant to be used as a last resort, and that is what draft-verdt-netmod-yang-semver-00 tries to express.

I argue that it is better to indicate an NBC bug fix to a client than to either (i) make the NBC bug fix but be unable to indicate it, or (ii) not be able to fix an obvious bug in the model in case it might break a client.  At least with semantic versioning a client is able to check whether they might get broken.

> > > > have a versioning scheme that reflects how YANG models are
> > > > actually evolving rather than have all vendor and OC YANG modules
> > > > either just ignoring the rules, or using clever tricks that
> > > > strictly conform with the rules but go against the spirit of them
> > > > (e.g. just publish an entirely new set of YANG modules for each
> > > > release).  Also noting that having a scheme that allows
> > > > non-backwards-compatible changes does not require that everyone
> > > > uses them - IETF could continue to always publish backwards
> > > > compatible modules.  The obvious alternative here is that each
> > > > vendor comes up with their own versioning extension and ignores
> > > > the RFC 7950 section 11 rules anyway, but I'm not sure how that really
> helps client<->server interop.
> > >
> > > The client<->server interop will not magically work better if we
> > > allow NBC changes.
> > [RW]
> The draft we talk about does not mention anything about helping clients
> understand the diffs, BC or not.

That part of the work is still TBD.  Section 1.2 of draft draft-verdt-netmod-yang-semver-00 talks about this.

I still think that a tooling based module and schema comparison tool is important, but it probably will require additional module annotations to be properly useful.

But I also still believe that having a semantic version number can greatly help a module reader, in conjunction with the revision history, understand the nature of the changes.

> > > > 2) I don't understand how the RFC 7950 approach of "deprecate a
> > > > buggy node, and replace with a working node" really works in
> > > > practice, particularly for configuration data nodes where you have
> > > > two clients interacting with a server, one interacting with the
> > > > old path, and another using the new path.  Perhaps there is a
> > > > robust scheme that works in all cases, but it isn't obvious to me.
> > > > Historically, for CLI we just translate the CLI from old to new
> > > > format and then return the new format when the running config is
> > > > requested.  But that will still break an old client that doesn't
> > > > understand how to read the new CLI, even if the server supports them
> writing via the old CLI.
> > > >
> > > > Even if there is a workable solution for this simple case, I
> > > > suspect that there are many slightly more complicated cases that
> > > > don't work (e.g. rekeying a list, changing defaults, incompatible types).
> > >
> This is a strawman; I never recommended changing an entire module to fix one
> leaf.

This is not intended as a strawman.

How would you propose handling this change whilst keeping within the RFC 7950 rules?  My understanding is that if this change was required then the only option within the RFC 7950 rules would be to create an entirely new module, with the massive impact that I describe.

I.e. I don't think that the existing rules have a viable solution for this sort of problem.  For config false nodes, adding duplicate nodes & deprecating is fine.  For config true nodes, I'm just not convinced that the current scheme works of adding a second configurable leaf works in a robust way.  

In particular, within a YANG schema I think that there should only be a single path for configuring a property (putting aside hierarchical config which is OK).

> > > > versioning schema using revision dates is working just fine, and
> > > > no changes are needed.
> > >
> >  I.e. you don't think that we should be using semantic  versioning at
> > all
> 
> My objection is that I don't agree with the problem statement and I don't think
> that we should allow NBC in published modules.

But on a practical level this seems to be the same as stating:

"Published YANG modules MUST never have any bugs in any config true nodes."

Thanks,
Rob

> 
> 
> /martin
> 
> 
> > , and we should keep RFC 7950 section 11 rules and  revision dates for
> > versioning YANG models.  But I think that the  overwhelming evidence
> > is that the current scheme does not work for  everyone, even if it
> > might be sufficient for YANG modules produced in  the IETF.
> >
> > Thanks,
> > Rob
> >
> >
> > >
> > >
> > > /martin
> > >
> > >
> > >
> > > >
> > > > Thanks,
> > > > Rob
> > > >
> > > >
> > > > revision two of several YANG modules (ietf-inet-types,
> > > > ietf-yang-type, ietf-interfaces, ietf-ip, ietf-routing, ...), so
> > > > the statement that "standardized YANG modules have to be perfect
> > > > on day one" is simply not true.
> > > >
> > > > Second, I don't think the upgrade rules are the reason it takes a
> > > > long time to standardize IETF models (I think it has to do with
> > > > the process itself, including the fact that models get reviews
> > > > from many different people with different background.)  [BTW, is
> > > > it true that drafts with YANG models take longer time from wg -00
> > > > to published RFC than other drafts?]
> > > >
> > > >
> > > > raises, and that I think we should continue to work on;
> > > > specifically 2.3, 2.5, 2.6, 2.7.  But I don't think that these
> > > > areas require changes to the versioning scheme, and I think it is
> > > > a mistake to include these areas in this draft.
> > > >
> > > > > preparation for our meeting in Prague, it seems like a good time for this
> poll.
> > > > > https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-r
> > > > > eqs-
> > > > > 02
> > > > > <https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-
> > > > > reqs
> > > > > -0
> > > > > 2>
> > > > >
> > > > > Note that this draft defines *requirements* and its intended
> > > > > status is "Informational."  I believe that it is good for WGs to
> > > > > formalize requirements, even taking such drafts thru Last Call,
> > > > > in order to ensure consensus on the requirements.  This is the
> > > > > "adoption" call, to ascertain if the WG agrees with that
> > > > > statement; if adopted, a separate "last call" will be issued to
> > > > > ensure to correctness of the draft's content.
> > > > >
> > > > > Kent (and Lou and Joel)
> > > > >
> > > > >
> > > >

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 20 Mar 2019 19:01:12 +0000

Hi,

On 2019-03-20, 2:12 PM, "netmod on behalf of Rob Wilton (rwilton)" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Martin,
    
<snip>

    
    Thanks,
    Rob

+1
My recollection/understanding of how this work started is that some members of the WG felt that there are and will be cases where published YANG modules (SDOs or native) have bugs and have to be updated in an NBC way.

Regards,
Reshad.

---

From: Kent Watsen <[email-masked]>
Date: Wed, 20 Mar 2019 19:24:43 +0000

> I have seen entire REST APIs be versioned, but not individual parameters within the API.

FWIW, I have seen individual resources versioned within a REST API, in lieu of a version number in the beginning of the URL.  The REST API presented resources for versioned "objects", each having a distinct media type for content negotiation (e.g., application/vnd.<company>.<object>+[xml/json];v=2).

Clients asked for what they could support (including older versions, in case the server didn't support the latest).  Server's up/down-converted objects through a chain of converters.  Each release only had converters to/from the previous release, but only for the objects that changed.  

It worked well.  The API was stable. Clients did not have to support all the new object versions in one go.  Incremental transition was common.

Kent

---

From: Andy Bierman <[email-masked]>
Date: Wed, 20 Mar 2019 13:59:22 -0700

On Wed, Mar 20, 2019 at 12:24 PM Kent Watsen <[email-masked]> wrote:

> FWIW, I have seen individual resources versioned within a REST API, in
> lieu of a version number in the beginning of the URL.  The REST API
> presented resources for versioned "objects", each having a distinct media
> type for content negotiation
> (e.g., application/vnd.<company>.<object>+[xml/json];v=2).
>
> Clients asked for what they could support (including older versions, in
> case the server didn't support the latest).  Server's up/down-converted
> objects through a chain of converters.  Each release only had converters
> to/from the previous release, but only for the objects that changed.
>
> It worked well.  The API was stable. Clients did not have to support all
> the new object versions in one go.  Incremental transition was common.
>
>

This is much simpler because the REST APIs are like RPC operations in YANG
-- they do not interact with each other.
In fact, it is impossible in YANG to have the XPath/leafref
cross-references in 1 RPC access another RPC.

It is easy to support many revisions of an RPC operation.
Not so easy for the contents of a YANG datastore.

Changing the data type, config-stmt, or data definition type are drastic
changes that will affect cross-references.
These might be the only NBC changes that really matter. Anything else you
could call a bugfix
and it would be better to fix than replace (e.g., add/modify/delete
must/when/mandatory)

I agree with Martin that NBC changes cannot be allowed and a new definition
is required to replace the broken one.

Perhaps Lada is right that the YANG update rules are too strict.
There are many things that could be considered a bugfix that are not
allowed.
But I don't think a version string format fixes any of the hard problems.
More YANG statements, extensions, and annotations (in NETCONF) are needed
to really address the problem, (E.g., where is the 301 Redirect for
NETCONF/YANG?)

Kent

Andy

---

From: Kent Watsen <[email-masked]>
Date: Wed, 20 Mar 2019 23:24:57 +0000

> This is much simpler because the REST APIs are like RPC operations in YANG -- they do not interact with each other.
> In fact, it is impossible in YANG to have the XPath/leafref cross-references in 1 RPC access another RPC.
> 

The REST API was modeled using YANG, but each "object" was effectively yang-data.   This was for an NMS, so the objects were large.  For example, each NE device was an object, as was each application-level abstraction built on top of the device native models.

K.

---

From: Lou Berger <[email-masked]>
Date: Fri, 22 Mar 2019 15:07:39 -0400

Hi,

Thank you all for the good input on this thread.

With the understanding that a 00 working group document is a starting 
point for the working group rather than a document that is ready for 
last call - we believe there is sufficient support to adopt this 
document as a starting point for the requirements we wish to address on 
this topic.

It is clear that there is still work to be done on this document before 
we can declare consensus on it and, not surprisingly, that there is more 
work to be done on the solution.

Authors,

Please resubmit this document as draft-ietf-netmod-yang-revision-reqs-00 
with the only change being the name and publication date.  The -01 
version should focus on resolving issues raised during adoption.  Of 
course the document is subject to normal WG input and processing.

Please note the 'file' name change -this is to indicate that the 
requirements are not presupposing a specific solution. It is also 
consistent with how versioning is defined within the document currently.

Note: we would like to try to continue the list discussion in next 
week's session and ask the Authors/DT to summarize issues raised during 
the adoption call and lead a discussion to help resolve these issues.

Thank you,

Lou (and Kent and Joel)

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 24 Mar 2019 11:39:06 -0700

> On Mar 22, 2019, at 12:07, Lou Berger <[email-masked]> wrote:
> 
> Hi,
> 
> With the understanding that a 00 working group document is a starting point for the working group rather than a document that is ready for last call - we believe there is sufficient support to adopt this document as a starting point for the requirements we wish to address on this topic.
> 
> It is clear that there is still work to be done on this document before we can declare consensus on it and, not surprisingly, that there is more work to be done on the solution.
> 
> Authors, 
> 
> Please resubmit this document as draft-ietf-netmod-yang-revision-reqs-00 with the only change being the name and publication date.  The -01 version should focus on resolving issues raised during adoption.  Of course the document is subject to normal WG input and processing.
> 
> Please note the 'file' name change -this is to indicate that the requirements are not presupposing a specific solution. It is also consistent with how versioning is defined within the document currently.
> 
> Note: we would like to try to continue the list discussion in next week's session and ask the Authors/DT to summarize issues raised during the adoption call and lead a discussion to help resolve these issues.
> 
I think this meeting is great opportunity to decide what steps need to be taken to advance the document within the working group.

Martin specifically objects to the presence of of Non-Backward-Compatible changes. 

Many modules outside the IETF are already incompatible with roc 7950 yang 1.1 revision rules. So that cat may be out of the bag at least with respect to the real world. the question remains what to do about that?

---

From: Andy Bierman <[email-masked]>
Date: Sun, 24 Mar 2019 13:05:21 -0700

On Sun, Mar 24, 2019 at 11:39 AM Joel Jaeggli <[email-masked]> wrote:

> point for the working group rather than a document that is ready for last
> call - we believe there is sufficient support to adopt this document as a
> starting point for the requirements we wish to address on this topic.
>
> It is clear that there is still work to be done on this document before we
> can declare consensus on it and, not surprisingly, that there is more work
> to be done on the solution.
>
> Authors,
>
> with the only change being the name and publication date.  The -01 version
> should focus on resolving issues raised during adoption.  Of course the
> document is subject to normal WG input and processing.
>
> Note: we would like to try to continue the list discussion in next week's
> session and ask the Authors/DT to summarize issues raised during the
> adoption call and lead a discussion to help resolve these issues.
>
> I think this meeting is great opportunity to decide what steps need to be
> taken to advance the document within the working group.
>
> Many modules outside the IETF are already incompatible with roc 7950 yang
> 1.1 revision rules. So that cat may be out of the bag at least with respect
> to the real world. the question remains what to do about that?
>
>

I do not look at the problem as allowing NBC so much as making it clear to
toolmakers what is going on,
like a deviation to the versioning rules.

BTW, I do not support adoption of the requirements document at all.
I support the work on versioning as part of the charter, and I am happy to
accept the design team solution draft as the starting point, and just work
on a solution.

But I think the solution is a bit flawed.

1) extensions are optional and problematic since they can be revisioned
without changing
    the language version; the solution needs to use new YANG 1.2 statements
instead of extensions

2) the version string does not have to contain all the NBC semantics.
The solution draft does not show modified semver.
It should be done differently than overloading the version string;

Let's say a fork is done on 1.3.0.

         revision 2017-07-30 {
           description "Added leaf foo-64";
           semver:module-version "1.3.0";
         }

start with a legal change, just not at the HEAD

         revision 2019-01-10 {
           description "Added leaf bar-64";
           semver:module-version "1.3.1";
         }

then later, an NBC change

        revision 2019-02-10 {
           description "Changed leaf bar-64 default-stmt";
           semver:module-version "1.3.2";
           semver:nbc-change;

         }

then later, a legal change

        revision 2019-03-10 {
           description "Added leaf baz-64";
           semver:module-version "1.3.3";

         }

This is a form of an inline deviation-stmt.
The YANG update rules are not changing. They are just not being followed.

The NBC info belongs in the revision-stmt, not overloading the version string.
Not every major revision will mean NBC changes anyway.

Andy

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Sun, 24 Mar 2019 20:44:32 +0000

Please see inline, marked with [cue].

From: netmod <[email-masked]> on behalf of "Rob Wilton (rwilton)" <[email-masked]>
Date: Wednesday, March 20, 2019 at 12:55 PM
To: Andy Bierman <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02

Hi Andy,

Thanks for the comments.

   1.0.0
      | \
      |   1.1.0 – 1.2.0 - …
      |
   2.0.0
      |

In short, I think that vanilla Semver 2.0.0 is a good fit for open source projects where you can just tell the client to update to the latest version to pick up the fix.  I don’t think that Semver 2.0.0 is so well aligned to APIs that are required to be maintained for long periods of time.
[cue]
Let me start by admitting that I am a YANG neophyte, so take this as a question rather than a suggestion, but would it make any sense to apply the semantics of Semver 2.0.0 for standard models and allow the use of something more expressive, such as that proposed in https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02, for native models? My guess is that standard vs. native model is a distinction that we discuss and that is evident by YANG model name; however, a YANG compiler has no knowledge of this and makes no distinction. Nevertheless, I thought I’d throw it out there.

Cheers,
Charles

Thanks,
Rob

A couple of points:

Thanks,
Rob

Andy

-----Original Message-----
From: netmod <[email-masked]<mailto:[email-masked]>> On Behalf Of Martin Bjorklund
Sent: 19 March 2019 15:12
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02

Hi,

/martin

---

From: Kent Watsen <[email-masked]>
Date: Sun, 24 Mar 2019 20:45:07 +0000

Hi Andy,

> Andy Bierman wrote:

Can you say why?   Is it a blanket statement about adopting requirements drafts in general, or something specific to this draft.

Kent

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 24 Mar 2019 21:56:35 +0100 (CET)

>            semver:module-version "1.3.3";

+1  I have suggested something similar.

> The YANG update rules are not changing. They are just not being followed.

Right!

> The NBC info belongs in the revision-stmt, not overloading the version string.

Agreed.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sun, 24 Mar 2019 13:58:54 -0700

On Sun, Mar 24, 2019 at 1:45 PM Kent Watsen <[email-masked]> wrote:

> Can you say why?   Is it a blanket statement about adopting requirements
> drafts in general, or something specific to this draft.
>
>
Because they just waste time.
They are mostly reverse engineered from the desired solution (by the
authors).
We end up having the same debates twice.

It is usually worse then that, since you end up debating the wording in the
requirements
instead of the merits of the solution-in-progress (considering all factors
and readjusted requirements).

Andy

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Sun, 24 Mar 2019 21:46:56 +0000

From: netmod <[email-masked]> on behalf of 'Andy Bierman' <[email-masked]>
Date: Sunday, March 24, 2019 at 9:59 PM
To: Kent Watsen <[email-masked]>
Cc: NetMod WG <[email-masked]>
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02

On Sun, Mar 24, 2019 at 1:45 PM Kent Watsen <[email-masked]<mailto:[email-masked]>> wrote:

Hi Andy,

Because they just waste time.
They are mostly reverse engineered from the desired solution (by the authors).

<RR> I don’t think we’re tied to the solution of semver or modified semver (speaking for myself at least). The main question on the requirements is whether NBC changes should be accepted. Many people seem to think so, if you don’t agree that’s fine, but I disagree with the claim that the requirements are reverse engineered from the solution, I believe the design team has strived to separate the 2.

Reshad.

It is usually worse then that, since you end up debating the wording in the requirements
instead of the merits of the solution-in-progress (considering all factors and readjusted requirements).

Kent

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 24 Mar 2019 15:54:00 -0700

Hi,

I don't know what it means to "accept" NBC changes.
I agree this is a deviation that could be documented somehow.

Andy

On Sun, Mar 24, 2019 at 2:47 PM Reshad Rahman (rrahman) <[email-masked]>
wrote:

>
>
> *From: *netmod <[email-masked]> on behalf of 'Andy Bierman' <
> [email-masked]>
> *Date: *Sunday, March 24, 2019 at 9:59 PM
> *To: *Kent Watsen <[email-masked]>
> *Cc: *NetMod WG <[email-masked]>
> *Subject: *Re: [netmod] adoption poll for yang-versioning-reqs-02
>
>
>
>
>
>
>
> <RR> I don’t think we’re tied to the solution of semver or modified semver
> (speaking for myself at least). The main question on the requirements is
> whether NBC changes should be accepted. Many people seem to think so, if
> you don’t agree that’s fine, but I disagree with the claim that the
> requirements are reverse engineered from the solution, I believe the design
> team has strived to separate the 2.
>
>
>
> Reshad.
>
>
>

---

From: Balázs Lengyel <[email-masked]>
Date: Mon, 25 Mar 2019 11:22:28 +0000

On 2019. 03. 24. 21:05, Andy Bierman
wrote:

On Sun, Mar 24, 2019 at
11:39 AM Joel Jaeggli <[email-masked]> wrote:

On Mar 22, 2019, at 12:07, Lou Berger <[email-masked]>
wrote:

Hi,

Thank you all for the good input on this
thread.

With the understanding that a 00 working group
document is a starting point for the working
group rather than a document that is ready for
last call - we believe there is sufficient
support to adopt this document as a starting
point for the requirements we wish to address on
this topic.

It is clear that there is still work to be done
on this document before we can declare consensus
on it and, not surprisingly, that there is more
work to be done on the solution.

Authors,

Please resubmit this document as
draft-ietf-netmod-yang-revision-reqs-00 with the
only change being the name and publication
date.  The -01 version should focus on resolving
issues raised during adoption.  Of course the
document is subject to normal WG input and
processing.

Please note the 'file' name change -this is to
indicate that the requirements are not
presupposing a specific solution. It is also
consistent with how versioning is defined within
the document currently.

Note: we would like to try to continue the list
discussion in next week's session and ask the
Authors/DT to summarize issues raised during the
adoption call and lead a discussion to help
resolve these issues.

I think this meeting is great opportunity to decide
what steps need to be taken to advance the document
within the working group.

Martin specifically objects to the presence of of
Non-Backward-Compatible changes.

Many modules outside the IETF are already
incompatible with roc 7950 yang 1.1 revision rules. So
that cat may be out of the bag at least with respect
to the real world. the question remains what to do
about that?

I do not look at the problem as allowing NBC so much as
making it clear to toolmakers what is going on,

BTW, I do not support adoption of the requirements
document at all.

I support the work on versioning as part of the charter,
and I am happy to

accept the design team solution draft as the starting
point, and just work on a solution.

1) extensions are optional and problematic since they can
be revisioned without changing

the language version; the solution needs to use new
YANG 1.2 statements instead of extensions

2) the version string does not have to contain all the
NBC semantics.

It should be done differently than overloading the
version string;

Let's say a fork is done on 1..3.0.

revision 2017-07-30 {

revision 2019-01-10 {

revision 2019-02-10 {

}

revision 2019-03-10 {

}

Andy

BALAZS: This would not work. Lets say we have 3 versions of a model
1, 2 and 3.

Between 1->2 there is an NB C change (non-backward compatible.

Between 2->3 there is a BC change.

We have a server that only implements ver-3. As the last change
was backward compatible ver-3 does not contain semver:nbc-change;

So if the client-A used ver-2 previously it will get the correct
information: change is BC

However if the client-B used ver-1 previously it will get
INCORRECT information.

If you say that the semver:nbc-change;is sticky and ver-3
contains semver:nbc-change; client-A gets wrong
information, it believes the change is NBC while it was BC.

The problem is that the server does not know which is the
"previous" model version for the client, and backwards
compatibility info is needed between the two model-versions the
client is using.

If we connect compatibility to the version number as we propose
this problem is solved.

regards Balazs