Subject: [Netmod-ver-dt] YANG versioning status

From: Robert Wilton <[email-masked]>
Date: Thu, 15 Nov 2018 10:19:39 +0000

Hi,

This is my summary (from memory) of where I think that we are at:

Broadly the WG seemed to be happy that the DT is making progress and 
should keep working.  However, I don't think that we are at the stage 
where we are ready for a given solution.

Anees is unhappy that the OpenConfig prior art isn't being acknowledged 
in the either the requirements or versioning solution comparison 
drafts.  We should rectify this to keep them happy.

1) Requirements:

I think that open issues relating to requirements are:

A) Req 1.4:
- Remove the first sentence about versioning by software release. In 
fact, I sent some proposed updated text to the alias yesterday that Andy 
at least seems to be happy with.

The current text that I sent for 1.4 was:

        1.4  The solution MUST allow for backwards-compatible
             enhancements, and backward-compatible or non-backwards compatible
             bug fixes to be allowed in non-latest releases.

Issues that we don't yet have WG consensus on:
i) Do we need to support bug fixes in older releases?  And if so, what 
constitutes a bug fix.
ii) Do we support bc enhancements in older releases?
iii) Do we support nbc changes in an older release? (E.g. for a broader 
definition of bug fix, or perhaps we can avoid defining bug fix altogether).

B) Req 3.2:
  - Martin doesn't like the wording since it implies supporting 2 module 
revisions at the same time.
  - I think that Andy doesn't want us to solve this at all, although I 
don't quite know whether he accepts translating between different 
versions of schema or not.

C) There is a desire that we also try and solve versioning at the 
package level (e.g. sets of related modules), which would be expanding 
the remit of this work.  Again should there be a requirement stating this?

We also want to get WG adoption for the requirements draft, which we 
should push to resolve over the next few weeks.  Iin the meeting, I 
don't think that anyone is opposed to doing an adoption call on the 
requirements draft, but they have issues with some of the requirements.

2) Solutions:

i) Lou would like to see viable solutions to all requirements (i.e. all 
pieces) before he thinks that we can state whether or not we are heading 
in the right direction.  Specifically, I think that his particular 
concern is being able to see a solution proposed for Req 3.2.

ii) Lou is still keen on the idea of doing minor versioning within a 
module, using revision dates as we do today, but use new module names 
(e.g. "module-foo-2") to indicate major version changes. Some folk think 
there is a solution to have two separate nodes controlling the same 
underlying config, but I can't really see how such a solution works in 
the general case, or at least there is a set of constraints under which 
such a solution could work.  As a design team, I think that we need to 
explore this and write this down.

iii) I think that there is a partial consensus that some sort of module 
level version number is a good thing:
  - Quite a lot of people seem to prefer using vanilla semver because it 
is simpler/more familiar.
  - Rob Shakir thinks semver is fine, and deviations/augmentations can 
be used where it doesn't work (e.g. bug fixes to older releases), but I 
think that this is misusing revision statements.
  - Going with semver probably means that the solution doesn't work for 
vendors.
  - In the design team discussions prior to the meeting we preferred

  - Perhaps another alternative is a custom 3 digit versioning scheme 
that doesn't have the semver guarantees, and relies on module comparison.

iv) Per release semver is not liked, and can be regarded as being dead. 
I think that the design team had probably already reached this point anyway.

3) Phasing of work, and next steps:

In the slides I proposed phasing the work as separate drafts, although I 
don't think that the chairs would accept us deferring solutions for 
particular requirements.

There is still an open question as to whether some/all of this work 
needs to be done as part of YANG next, or if some/all of it can be done 
as extensions.  I know that Kent is more keen on a YANG.next, but Lou 
prefers of defining extensions and then folding extensions into a new 
version of YANG in future.

In addition to resolving the issues above, I think that the discrete 
areas of work are probably:

1) Closing out on requirements and getting WG adoption of the reqs draft.
2) Investigating an describing whether two nodes writing the same config 
item can work in the general case, and if so, what are the 
constraints/impact.
3) Agreeing of module level version number scheme
4) Describe/refine the work for status handling, import handling, 
revision date semantics
5) Specifying the extensions required for a schema comparison tool to 
work effectively
6) Investigating what packages/module sets would look like.  It would be 
nice if these could reuse the same module level versioning scheme.
7) Defining how version selection could work (which should tie in the 
packages/modules work).

Perhaps we can split up some of this work and work on it in parallel.

Thanks,
Rob

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 15 Nov 2018 12:26:20 +0000

Won’t make it today (visitors).

3.2, as a requirement, should be reworded or removed IMO. It can be part of solution draft.

From: Netmod-ver-dt <[email-masked]> on behalf of "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]>
Date: Thursday, November 15, 2018 at 5:20 AM
To: "[email-masked]" <[email-masked]>
Subject: [Netmod-ver-dt] YANG versioning status

Hi,

Broadly the WG seemed to be happy that the DT is making progress and should keep working.  However, I don't think that we are at the stage where we are ready for a given solution.

Anees is unhappy that the OpenConfig prior art isn't being acknowledged in the either the requirements or versioning solution comparison drafts.  We should rectify this to keep them happy.

1) Requirements:

A) Req 1.4:
- Remove the first sentence about versioning by software release.  In fact, I sent some proposed updated text to the alias yesterday that Andy at least seems to be happy with.

Issues that we don't yet have WG consensus on:
i) Do we need to support bug fixes in older releases?  And if so, what constitutes a bug fix.
ii) Do we support bc enhancements in older releases?
iii) Do we support nbc changes in an older release? (E.g. for a broader definition of bug fix, or perhaps we can avoid defining bug fix altogether).

B) Req 3.2:
 - Martin doesn't like the wording since it implies supporting 2 module revisions at the same time.
 - I think that Andy doesn't want us to solve this at all, although I don't quite know whether he accepts translating between different versions of schema or not.

C) There is a desire that we also try and solve versioning at the package level (e.g. sets of related modules), which would be expanding the remit of this work.  Again should there be a requirement stating this?

We also want to get WG adoption for the requirements draft, which we should push to resolve over the next few weeks.  Iin the meeting, I don't think that anyone is opposed to doing an adoption call on the requirements draft, but they have issues with some of the requirements.

2) Solutions:

i) Lou would like to see viable solutions to all requirements (i.e. all pieces) before he thinks that we can state whether or not we are heading in the right direction.  Specifically, I think that his particular concern is being able to see a solution proposed for Req 3.2.

ii) Lou is still keen on the idea of doing minor versioning within a module, using revision dates as we do today, but use new module names (e.g. "module-foo-2") to indicate major version changes. Some folk think there is a solution to have two separate nodes controlling the same underlying config, but I can't really see how such a solution works in the general case, or at least there is a set of constraints under which such a solution could work.  As a design team, I think that we need to explore this and write this down.

iii) I think that there is a partial consensus that some sort of module level version number is a good thing:
 - Quite a lot of people seem to prefer using vanilla semver because it is simpler/more familiar.
 - Rob Shakir thinks semver is fine, and deviations/augmentations can be used where it doesn't work (e.g. bug fixes to older releases), but I think that this is misusing revision statements.
 - Going with semver probably means that the solution doesn't work for vendors.
 - In the design team discussions prior to the meeting we preferred

 - Perhaps another alternative is a custom 3 digit versioning scheme that doesn't have the semver guarantees, and relies on module comparison.

iv) Per release semver is not liked, and can be regarded as being dead. I think that the design team had probably already reached this point anyway.

In the slides I proposed phasing the work as separate drafts, although I don't think that the chairs would accept us deferring solutions for particular requirements.

There is still an open question as to whether some/all of this work needs to be done as part of YANG next, or if some/all of it can be done as extensions.  I know that Kent is more keen on a YANG.next, but Lou prefers of defining extensions and then folding extensions into a new version of YANG in future.

In addition to resolving the issues above, I think that the discrete areas of work are probably:

1) Closing out on requirements and getting WG adoption of the reqs draft.
2) Investigating an describing whether two nodes writing the same config item can work in the general case, and if so, what are the constraints/impact.
3) Agreeing of module level version number scheme
4) Describe/refine the work for status handling, import handling, revision date semantics
5) Specifying the extensions required for a schema comparison tool to work effectively
6) Investigating what packages/module sets would look like.  It would be nice if these could reuse the same module level versioning scheme.
7) Defining how version selection could work (which should tie in the packages/modules work).

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Thu, 15 Nov 2018 12:52:11 +0000

> 3.2, as a requirement, should be reworded or removed IMO. It can be 
I'm not sure that we can remove it because various WG members explicitly 
want this requirement.

So I think that we should reword it in the hope that we can get text 
that the WG agrees with.  I think that writing up a more details 
solution draft describing how this version selection can work would be 
helpful.  At least the WG can then see a concrete proposal and decide 
whether or not they like it.

Thanks,
Rob

> *From: *Netmod-ver-dt <[email-masked]> on behalf of 
> "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]>
> *Date: *Thursday, November 15, 2018 at 5:20 AM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[Netmod-ver-dt] YANG versioning status
>
> Hi,
>
> Anees is unhappy that the OpenConfig prior art isn't being 
> acknowledged in the either the requirements or versioning solution 
> comparison drafts.  We should rectify this to keep them happy.
>
> 1) Requirements:
>
> fact, I sent some proposed updated text to the alias yesterday that 
> Andy at least seems to be happy with.
>
> iii) Do we support nbc changes in an older release? (E.g. for a 
> broader definition of bug fix, or perhaps we can avoid defining bug 
> fix altogether).
>
> B) Req 3.2:
> i) Lou would like to see viable solutions to all requirements (i.e. 
> all pieces) before he thinks that we can state whether or not we are 
> heading in the right direction.  Specifically, I think that his 
> particular concern is being able to see a solution proposed for Req 3.2.
>
> (e.g. "module-foo-2") to indicate major version changes. Some folk 
> think there is a solution to have two separate nodes controlling the 
> same underlying config, but I can't really see how such a solution 
> works in the general case, or at least there is a set of constraints 
> under which such a solution could work.  As a design team, I think 
> that we need to explore this and write this down.
>
> iii) I think that there is a partial consensus that some sort of 
> module level version number is a good thing:
> be used where it doesn't work (e.g. bug fixes to older releases), but 
> I think that this is misusing revision statements.
> iv) Per release semver is not liked, and can be regarded as being 
> dead. I think that the design team had probably already reached this 
> point anyway.
>
> In the slides I proposed phasing the work as separate drafts, although 
> I don't think that the chairs would accept us deferring solutions for 
> particular requirements.
>
> needs to be done as part of YANG next, or if some/all of it can be 
> done as extensions.  I know that Kent is more keen on a YANG.next, but 
> Lou prefers of defining extensions and then folding extensions into a 
> new version of YANG in future.
>
> 2) Investigating an describing whether two nodes writing the same 
> config item can work in the general case, and if so, what are the 
> constraints/impact.
> 6) Investigating what packages/module sets would look like. It would 
> be nice if these could reuse the same module level versioning scheme.

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 15 Nov 2018 13:41:18 +0000

I was always a bit ambivalent about 3.2. While it would make life for clients much easier, it is also imposing a solution on servers.  There may be other solutions which are as good for clients and simpler for servers. But I won’t fight it since the DT seems to want to keep it, but others will.

Regards,
Reshad.

From: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]>
Date: Thursday, November 15, 2018 at 7:52 AM
To: "Reshad Rahman (rrahman)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Netmod-ver-dt] YANG versioning status

I'm not sure that we can remove it because various WG members explicitly want this requirement.

So I think that we should reword it in the hope that we can get text that the WG agrees with.  I think that writing up a more details solution draft describing how this version selection can work would be helpful.  At least the WG can then see a concrete proposal and decide whether or not they like it.

Thanks,
Rob

From: Netmod-ver-dt <[email-masked]><mailto:[email-masked]> on behalf of "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]><mailto:[email-masked]>
Date: Thursday, November 15, 2018 at 5:20 AM
To: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: [Netmod-ver-dt] YANG versioning status

Hi,

1) Requirements:

A) Req 1.4:

B) Req 3.2:

2) Solutions:

Thanks,
Rob

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 15 Nov 2018 16:49:44 +0000

Hello Rob,

First of all thanks to all of you for driving this, I really
appreciate all your work.  Some personal thoughts:

We are not progressing that much. I see a risk of getting stuck.
Another Yangpush project running 4-5 years or more. We did not
agree on any of the crucial issues. IMHO we should try to
establish "rough" consensus on some issues and  go forward.
Couldn't we try to be more assertive? Issues to settle:

Generally I see a risk to this effort. The chairs should be
convinced to help us towards a limited solution, not include
everything someone thought as a good idea.

3.2 is not fully agreed,  (only one proponent, Lou) should be
pushed into a separate draft. Whoever is interested should work
on it. I will not implement 3.2, so either remove it or do
whatever is the fastest optional solution. It is not a
requirement its an obstacle to be navigated.

Agree we/vendors/our operator-customers need bugfixes in older
releases, but are willing to accept that in that case all
compatibility info is lost (m/M). So I would push for the
modified semver, and try to leave everything else in a dead
appendix.

Don't define bugfix, there are too many opinions. Define 3
kinds of changes NBC/BC/Cosmetic. Allow changes like the wrong
regexp for Ipv4 address to be classified as cosmetic, if it is
TRIVIAL to ALL parties what should have been the correct
pattern.

In the clacla draft we decided to exclude packaging. Unless we
can reuse OpenConfig as-is it will seriously delay the work.

Personally I would also like a list of things that are decided to
be out of scope for the main solution draft, including:

The versioning number scheme does not consider supported
features, deviations or implementation of deprecated nodes as
that would leed to a more complicated solution. Just make a
simple assumption: No removed features, all deprecated stuff
still works, deviations are all BC.

3.2 - multiple versions on the interface

packaging

regards Balazs

P.S. In some cases it might be easier to work without
requirements, and just present a workable solution.

On 2018. 11. 15. 11:19, Robert Wilton
wrote:

Hi,

This is my summary (from memory) of where I think that we are
at:

Broadly the WG seemed to be happy that the DT is making
progress and should keep working.  However, I don't think that
we are at the stage where we are ready for a given solution.

Anees is unhappy that the OpenConfig prior art isn't being
acknowledged in the either the requirements or versioning
solution comparison drafts.  We should rectify this to keep them
happy.

1) Requirements:

A) Req 1.4:

- Remove the first sentence about versioning by software
release.  In fact, I sent some proposed updated text to the
alias yesterday that Andy at least seems to be happy with.

i) Do we need to support bug fixes in older releases?  And if
so, what constitutes a bug fix.

iii) Do we support nbc changes in an older release? (E.g. for a
broader definition of bug fix, or perhaps we can avoid defining
bug fix altogether).

B) Req 3.2:

- Martin doesn't like the wording since it implies supporting 2
module revisions at the same time.

- I think that Andy doesn't want us to solve this at all,
although I don't quite know whether he accepts translating
between different versions of schema or not.

C) There is a desire that we also try and solve versioning at
the package level (e.g. sets of related modules), which would be
expanding the remit of this work.  Again should there be a
requirement stating this?

We also want to get WG adoption for the requirements draft,
which we should push to resolve over the next few weeks.  Iin
the meeting, I don't think that anyone is opposed to doing an
adoption call on the requirements draft, but they have issues
with some of the requirements.

2) Solutions:

i) Lou would like to see viable solutions to all requirements
(i.e. all pieces) before he thinks that we can state whether or
not we are heading in the right direction.  Specifically, I
think that his particular concern is being able to see a
solution proposed for Req 3.2.

ii) Lou is still keen on the idea of doing minor versioning
within a module, using revision dates as we do today, but use
new module names (e.g. "module-foo-2") to indicate major version
changes. Some folk think there is a solution to have two
separate nodes controlling the same underlying config, but I
can't really see how such a solution works in the general case,
or at least there is a set of constraints under which such a
solution could work.  As a design team, I think that we need to
explore this and write this down.

iii) I think that there is a partial consensus that some sort
of module level version number is a good thing:

- Quite a lot of people seem to prefer using vanilla semver
because it is simpler/more familiar.

- Rob Shakir thinks semver is fine, and
deviations/augmentations can be used where it doesn't work (e.g.
bug fixes to older releases), but I think that this is misusing
revision statements.

- Going with semver probably means that the solution doesn't
work for vendors.

- In the design team discussions prior to the meeting we
preferred

- Perhaps another alternative is a custom 3 digit versioning
scheme that doesn't have the semver guarantees, and relies on
module comparison.

iv) Per release semver is not liked, and can be regarded as
being dead. I think that the design team had probably already
reached this point anyway.

In the slides I proposed phasing the work as separate drafts,
although I don't think that the chairs would accept us deferring
solutions for particular requirements.

There is still an open question as to whether some/all of this
work needs to be done as part of YANG next, or if some/all of it
can be done as extensions.  I know that Kent is more keen on a
YANG.next, but Lou prefers of defining extensions and then
folding extensions into a new version of YANG in future.

In addition to resolving the issues above, I think that the
discrete areas of work are probably:

1) Closing out on requirements and getting WG adoption of the
reqs draft.

2) Investigating an describing whether two nodes writing the
same config item can work in the general case, and if so, what
are the constraints/impact.

4) Describe/refine the work for status handling, import
handling, revision date semantics

5) Specifying the extensions required for a schema comparison
tool to work effectively

6) Investigating what packages/module sets would look like.  It
would be nice if these could reuse the same module level
versioning scheme.

7) Defining how version selection could work (which should tie
in the packages/modules work).

Perhaps we can split up some of this work and work on it in
parallel.

Thanks,

Rob

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

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

---

From: Robert Wilton <[email-masked]>
Date: Thu, 15 Nov 2018 17:13:17 +0000

Before commenting I would be interested to see what the views/thoughts 
of other DT members are.

Thanks,
Rob

On 15/11/2018 16:49, Balázs Lengyel wrote:
> Another Yangpush project running 4-5 years or more. We did not agree 
> on any of the crucial issues. IMHO we should try to establish "rough" 
> consensus on some issues and  go forward. Couldn't we try to be more 
> assertive? Issues to settle:
>
>   * Generally I see a risk to this effort. The chairs should be
>   * 3.2 is not fully agreed,  (only one proponent, Lou) should be
>     pushed into a separate draft. Whoever is interested should work on
>     it. I will not implement 3.2, so either remove it or do whatever
>     is the fastest optional solution. It is not a requirement its an
>     obstacle to be navigated.
>   * Agree we/vendors/our operator-customers need bugfixes in older
>     compatibility info is lost (m/M). So I would push for the modified
>     semver, and try to leave everything else in a dead appendix.
>   * Don't define bugfix, there are too many opinions. Define 3 kinds
>     of changes NBC/BC/Cosmetic. Allow changes like the wrong regexp
>     for Ipv4 address to be classified as cosmetic, if it is TRIVIAL to
>     ALL parties what should have been the correct pattern.
>   * In the clacla draft we decided to exclude packaging. Unless we can
>     reuse OpenConfig as-is it will seriously delay the work.
>
> Personally I would also like a list of things that are decided to be 
> out of scope for the main solution draft, including:
>
>   * The versioning number scheme does not consider supported features,
>     deviations or implementation of deprecated nodes as that would
>     leed to a more complicated solution. Just make a simple
>     assumption: No removed features, all deprecated stuff still works,
>     deviations are all BC.
>   * 3.2 - multiple versions on the interface
>   * packaging
>
> regards Balazs
>
> P.S. In some cases it might be easier to work without requirements, 
> and just present a workable solution.
>
> On 2018. 11. 15. 11:19, Robert Wilton wrote:
>>
>> Hi,
>>
>> package level (e.g. sets of related modules), which would be 
>> done as extensions.  I know that Kent is more keen on a YANG.next, 
>> but Lou prefers of defining extensions and then folding extensions 
>> into a new version of YANG in future.
>>
> Mobile: +36-70-330-7909              email:[email-masked]  
>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 16 Nov 2018 18:45:37 +0700

Hi Rob,

Will echo comments on trying to keeping this group and the WG moving forward. Sorry, I am still on vacation, so could not attend the meeting. And as Joe mentioned, next week is Thanksgiving. The following week looks better (ahh!, I see next week is cancelled)

More comments inline.

> On Nov 15, 2018, at 5:19 PM, Robert Wilton <[email-masked]> wrote:
> 
> Hi,
> 
Agree. Trying to close on the requirement text should help.
>             bug fixes to be allowed in non-latest releases.

This text seems to satisfy most people and should allow us to close on it.
> i) Do we need to support bug fixes in older releases?  And if so, what constitutes a bug fix.

Can we split this into two questions to see if we can reach some consensus. If we can agree that changes should be supported on older releases, it might help to define what kind of changes are permissible. Broadly, changes that fix the model that is broken or improve it, bc or nbc, should be allowed. 
>  - I think that Andy doesn't want us to solve this at all, although I don't quite know whether he accepts translating between different versions of schema or not.

Is there any way to state this without implying a solution? Sorry, I am in flight, and do have the 3.2 text in front of me to propose wording for it.
> C) There is a desire that we also try and solve versioning at the package level (e.g. sets of related modules), which would be expanding the remit of this work.  Again should there be a requirement…

If there is a desire to solve this problem, I would like to understand what is the requirement. So yes, we should have a requirement stating it.

Separately, from a solution perspective, I am not sure what would be entailed in defining a "sets of related modules". What is required to make a set of modules wholesome, if I could call it so? Who is testing the set?
> We also want to get WG adoption for the requirements draft, which we should push to resolve over the next few weeks.  Iin the meeting, I don't think that anyone is opposed to doing an adoption call…
Agree. But pushing for WG adoption might be one way to force a discussion of what those issues are. Adoption should not be gated on all problems having been solved.
> ii) Lou is still keen on the idea of doing minor versioning within a module, using revision dates as we do today, but use new module names (e.g. "module-foo-2") to indicate major version changes. S…
I would agree that I do not see how a new module name helps to solve the problem of a major version change. If the nodes that are changed are not something that impacts my solution, why do I care?
>  - Quite a lot of people seem to prefer using vanilla semver because it is simpler/more familiar.
Agree.
>  - Rob Shakir thinks semver is fine, and deviations/augmentations can be used where it doesn't work (e.g. bug fixes to older releases), but I think that this is misusing revision statements.
Also agree.
>  - In the design team discussions prior to the meeting we preferred 
Did you mean to complete this thought?
> iv) Per release semver is not liked, and can be regarded as being dead. I think that the design team had probably already reached this point anyway.
Yes, we can close on this.
> 1) Closing out on requirements and getting WG adoption of the reqs draft.
I would rather that we get adoption call made now, and follow that with closing out the requirements. Let us not conflate the two steps.
> 2) Investigating an describing whether two nodes writing the same config item can work in the general case, and if so, what are the constraints/impact.
I have never understood how this was going to work. We have a problem in Cisco with getting CLI and NETCONF to be in sync. Add in two different nodes, and we are looking at compounding the problem.
> 6) Investigating what packages/module sets would look like.  It would be nice if these could reuse the same module level versioning scheme.
Because I do not understand this myself, I can probably take this one. I believe it was Martin who brought it up.  This would have to include 7) as you state below.

Cheers.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 16 Nov 2018 18:59:28 +0100

On Fri, Nov 16, 2018 at 06:45:37PM +0700, Mahesh Jethanandani wrote:
> Hi Rob,
> 
> Will echo comments on trying to keeping this group and the WG moving forward.. Sorry, I am still on vacation, so could not attend the meeting. And as Joe mentioned, next week is Thanksgiving. The following week looks better (ahh!, I see next week is cancelled)
>

Always wondering what would happen if we were to celebrate all
national holidays...

/js

-- 
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: Lou Berger <[email-masked]>
Date: Fri, 16 Nov 2018 14:24:52 -0500

Hi,

     Catching up on mail.  See below.

> requirements draft, but they have issues with some of the requirements.
It's time to move to WG adoption ASAP.  How long to you have a version 
that will be ready for adoption?

> particular concern is being able to see a solution proposed for Req 3.2.
My view (all hats) is that if the WG has a set of requirements, that 
these (any MUSTs) need to be fully addressed before we can say we (The 
DT and the WG) have a solution.  Certainly, individuals are free to 
pursue whatever solutions they are interested in, but my view is that 
the DT should be working from the full set of the WG requirements.

> that we need to explore this and write this down.
I think this is an overstatement of my view.  I think we need to meet 
the backward compatibility functionality  implicit in 
https://tools.ietf.org/html/rfc7950#section-11  . I was suggesting (as 
others have suggested, I think) that if major version was encoded in the 
name via tooling, meeting the (backward) compatibility requirement might 
be fairly straightforward.

>  - In the design team discussions prior to the meeting we preferred
For those not present in the meeting, I think it's very worthwhile to 
hear the input from both Rob and Chris on the discussion, see 
https://www.youtube.com/watch?v=2rW3JwnB2nw

...

Thank you all for your hard work!

Lou

---

From: Joe Clarke <[email-masked]>
Date: Fri, 16 Nov 2018 22:21:33 -0500

On 11/15/18 11:49, Balázs Lengyel wrote:
> Hello Rob,
> 
> First of all thanks to all of you for driving this, I really appreciate
> all your work.  Some personal thoughts:
> 
> We are not progressing that much. I see a risk of getting stuck. Another
> Yangpush project running 4-5 years or more. We did not agree on any of
> the crucial issues. IMHO we should try to establish "rough" consensus on
> some issues and  go forward.  Couldn't we try to be more assertive?
> Issues to settle:

I agree.  I very much want to see this progress, and I think a big step
in that is quickly turning around the reqs draft for adoption.  I plan
to have that done next week.

>   * 3.2 is not fully agreed,  (only one proponent, Lou) should be pushed
>     into a separate draft. Whoever is interested should work on it. I
>     will not implement 3.2, so either remove it or do whatever is the
>     fastest optional solution. It is not a requirement its an obstacle
>     to be navigated.

I think it should stay, but the language should be softened.  That is,
this is something that SHOULD be done, but even today a sever vendor
could simply create a new module to replace and old one and drop support
for the old one at the same time.  If we get too wrapped up on how we
support those older clients, I think we won't make any forward progress.

Vendors that feel strongly about supporting older clients can do the
mapping exercise they do today with different modules touching the same
underlying data in order to support things like module bundles (IMHO).
That said, any kind of bundle selection thing would need protocol
changes to work without convention hacks (like ignoring a "-2" in a
namespace).

>     semver, and try to leave everything else in a dead appendix.

I'm okay with this.  But I think the WG might want to have a more
serious look at augments and deviations to address 1.4 without branching
per se.

>   * Don't define bugfix, there are too many opinions. Define 3 kinds of
>     changes NBC/BC/Cosmetic. Allow changes like the wrong regexp for
>     Ipv4 address to be classified as cosmetic, if it is TRIVIAL to ALL
>     parties what should have been the correct pattern.

There was a strong desire from the WG to define a bug fix.  And maybe we
do without providing specific examples?  Something like, a change to a
module that is needed to resolve a software or hardware defect.

>     reuse OpenConfig as-is it will seriously delay the work.

To me, packaging or bundling is something left to server vendors.  I
don't think you need to solve this to provide a solution to the NBC
issue in modules.  Once you have the NBC thing addressed, you could
build a bundling solution on top of it like OC does.

For me, I'd like to make the changes that were discussed to the reqs
draft and turn that around quickly.  Unless the DT likes the idea of a
simple bugfix definition, I'd say we leave that out of the draft for now.

Joe

---

From: Lou Berger <[email-masked]>
Date: Mon, 19 Nov 2018 09:38:25 -0500

Balázs

On 11/15/2018 11:49 AM, Balázs Lengyel wrote:
>#
>
> # 3.2 is not fully agreed,  (only one proponent, Lou) should be pushed 
> into a separate draft.

I'm sorry - that's not how I read the WG.  To be clear, I'm talking 
about the first part of 3.2 (the rest is about implementation 
compromises which to me is not a core requirement.)

             The solution MUST provide a mechanism to allow servers to
             simultaneously support clients using different revisions of
             modules.

This part of 3.2 is what we have by today's rules.  It is support today 
either through backward compatible changes or via new modules for NBCs.  
I think we heard loud and clear in this past meeting from users, 
specifically Chris and Rob S, that making it so a software update means 
that clients break -- i.e., mirroring the issues we have with CLI -- is 
unacceptable.  FWIW it is true that I agree with them both as a 
contributor and as WG co-chair.

Note, nothing in this requirement says you as a vendor need to support 
this requirement.  (Your customers and the market will judge if your 
implementation approach is acceptable.) This is a requirement on the 
solution.

If you disagree, please raise this again on the WG list or as a separate 
adoption call issue.

Lou

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 19 Nov 2018 15:02:36 +0000

I’m with Balasz for 3.2. My concern with 3.2 is that it requires a solution, which violates 7950, without going into how viable the solution is. I am fine if that solution is considered for the solutions draft, but putting it as a MUST in the requirements draft seems biased.

From: Netmod-ver-dt <[email-masked]> on behalf of Lou Berger <[email-masked]>
Date: Monday, November 19, 2018 at 9:38 AM
To: Balázs Lengyel <[email-masked]>, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Netmod-ver-dt] YANG versioning status

Balázs
On 11/15/2018 11:49 AM, Balázs Lengyel wrote:
•
•  3.2 is not fully agreed,  (only one proponent, Lou) should be pushed into a separate draft.

I'm sorry - that's not how I read the WG.  To be clear, I'm talking about the first part of 3.2 (the rest is about implementation compromises which to me is not a core requirement.)

This part of 3.2 is what we have by today's rules.  It is support today either through backward compatible changes or via new modules for NBCs.  I think we heard loud and clear in this past meeting from users, specifically Chris and Rob S, that making it so a software update means that clients break -- i.e., mirroring the issues we have with CLI -- is unacceptable.  FWIW it is true that I agree with them both as a contributor and as WG co-chair.

Note, nothing in this requirement says you as a vendor need to support this requirement.  (Your customers and the market will judge if your implementation approach is acceptable.) This is a requirement on the solution.

If you disagree, please raise this again on the WG list or as a separate adoption call issue.

Lou

---

From: Robert Wilton <[email-masked]>
Date: Mon, 19 Nov 2018 15:15:27 +0000

Hi Lou,

On 19/11/2018 14:38, Lou Berger wrote:
> This part of 3.2 is what we have by today's rules.  It is support 
> today either through backward compatible changes or via new modules 
> for NBCs.  I think we heard loud and clear in this past meeting from 
> users, specifically Chris and Rob S, that making it so a software 
> update means that clients break -- i.e., mirroring the issues we have 
> with CLI -- is unacceptable.  FWIW it is true that I agree with them 
> both as a contributor and as WG co-chair.
>
I didn't get the backwards compatibility vibe from Rob S, only from 
Chris.  Certainly, the Open Config models/solution doesn't seem to 
support that backwards compatibility requirement in any way (and using 
semver they allow and make use of non backwards compatible changes).

In terms of 7950, I believe that the spirit of chapter 11 is that 
servers are meant to always be backwards compatible.  But strictly 
speaking it does not require this for several reasons:
  - a node can me marked obsolete, and then the server can stop 
supporting it.
  - any definition can be deviated away.
  - features can be turned off, breaking clients.
  - an older version of a module can be not implemented by the server.

I'm also not convinced that the existing RFC 7950 solution works (at 
least when backwards incompatible changes are introduced in a new 
module), I'm still stuck on the two different nodes/paths modifying the 
same underlying config.  I'm just not convinced that this works in a 
robust way.  The bit about all changes being backwards compatible works OK.

However, having said all that, I still agree with the requirement.  I 
think that this is an important problem, and a complete solution should 
address this.

But I also want to split the solution drafts up into different parts so 
that as a design team, and as a WG, we can start to reach consensus on 
parts of the solution as we still develop the other parts.  I appreciate 
that it is necessary to see the path to a solution for all requirements 
before we can be sure that the solution is on the right track.

> implementation approach is acceptable.) This is a requirement on the 
I also agree with this.  I think that it is sufficient to have a 
specification for a reasonable solution.

But, I don't think that there is any cheaper solution this particular 
problem.  I think that it will fundamentally be expensive to implement 
whether or not it is implemented in the client, server, or intermediate 
NMS.  This is just one of those complex problems to solve.

Thanks,
Rob

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 19 Nov 2018 15:18:06 +0000

Hi,

On 2018-11-19, 10:10 AM, "Lou Berger" <[email-masked]> wrote:

    Hi,
    
    On 11/19/2018 10:02 AM, Reshad Rahman (rrahman) wrote:
    >
    > I’m with Balasz for 3.2. My concern with 3.2 is that it requires a 
    > solution, which violates 7950,
    >
    Humm - we must be talking past each other.  I'm reading the requirement 
    as that the spirit of 7950 must be preserved.  What am I missing?

We're talking about this right?            
           The solution MUST provide a mechanism to allow servers to
            simultaneously support clients using different revisions of
            modules.

From RFC7050:
5.6.5.  Implementing a Module

<snip>

   A server MUST NOT implement more than one revision of a module.

I'm reading the requirement 3.2 as violating the line above from 7950. But maybe my brain is still jet-lagged.

Regards,
Reshad.
    
    Thanks,
    
    Lou

    > without going into how viable the solution is. I am fine if that 
    > solution is considered for the solutions draft, but putting it as a 
    > MUST in the requirements draft seems biased.
    >
    > Lou Berger <[email-masked]>
    > *Date: *Monday, November 19, 2018 at 9:38 AM
    > *To: *Balázs Lengyel <[email-masked]>, "Robert Wilton -X 
    > (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]>, 
    > "[email-masked]" <[email-masked]>
    > *Subject: *Re: [Netmod-ver-dt] YANG versioning status
    >
    > Balázs
    >
    >     ·
    >     · 3.2 is not fully agreed,  (only one proponent, Lou) should be
    >     pushed into a separate draft.
    >

---

From: Lou Berger <[email-masked]>
Date: Mon, 19 Nov 2018 10:10:51 -0500

Hi,

Thanks,

Lou

---

From: Robert Wilton <[email-masked]>
Date: Mon, 19 Nov 2018 15:26:59 +0000

Hi Reshad,

> I'm reading the requirement 3.2 as violating the line above from 7950. But maybe my brain is still jet-lagged.

I don't think its the intention to really violate this, but maybe 
massage it's interpretation.

The server would probably always only ever "implement" the latest module 
versions.

If the server supports schema version selection then:
  - the server would advise (perhaps via YANG library) different 
versions of the schema that the client could connect with for a given 
session.
  - if the client connects using an older schema version then the server 
would translate to/from the latest schema version (used internally) on 
the fly.
  - this translation could be done on the box or off the box.

Does this mean that the server is implementing more than one revision? I 
would say no, not really.  But others may argue otherwise.

Thanks,
Rob

---

From: Lou Berger <[email-masked]>
Date: Mon, 19 Nov 2018 11:04:27 -0500

Rob,

     It sounds like we're basically in agreement on this.  I have some 
specific response below, if interested.

On 11/19/2018 10:15 AM, Robert Wilton wrote:
> Chris.
I'll have to go review the youtube to see what rob said, that lead me to 
this -- I, of course, can simply be wrong.

> Certainly, the Open Config models/solution doesn't seem to support 
> that backwards compatibility requirement in any way (and using semver 
> they allow and make use of non backwards compatible changes).
>
sure -- but these are *implementation* choices.  The requirement is on 
the solution not on the implementation.  In the real world, I'd expect 
backward compatibility for a fixed time period, or release stream.

> module), I'm still stuck on the two different nodes/paths modifying 
> the same underlying config.  I'm just not convinced that this works in 
> a robust way.
>
I hear you, but it is my understanding that multiple implementations are 
grappling with the challenge now and either have support now or are 
planning for it.  Either way, it *is* what is codified in 7950.

> The bit about all changes being backwards compatible works OK.
>
> think that this is an important problem, and a complete solution 
> should address this.
>
> But I also want to split the solution drafts up into different parts 
> so that as a design team, and as a WG, we can start to reach consensus 
> on parts of the solution as we still develop the other parts.  I 
> appreciate that it is necessary to see the path to a solution for all 
> requirements before we can be sure that the solution is on the right 
> track.
>
This is the part the cause me lots of concern, specifically that we'll 
come up a solution that works great except that it *precludes* a server 
from providing support for old clients.

>> Note, nothing in this requirement says you as a vendor need to 
>> support this requirement.  (Your customers and the market will judge 
>> if your implementation approach is acceptable.) This is a requirement 
>> on the solution.
>>
> whether or not it is implemented in the client, server, or 
> intermediate NMS.  This is just one of those complex problems to solve.
>
I do agree that this requirement has a real cost.  CLI had the cost 
largely paid by the client.  YANG has been "sold" as fixing this.  
Without this requirement, we're risking loosing this benefit and 
value/market attraction of YANG.

Lou

---

From: Robert Wilton <[email-masked]>
Date: Mon, 19 Nov 2018 16:20:50 +0000

Just one comment inline below.

On 19/11/2018 16:04, Lou Berger wrote:
>>>> # 3.2 is not fully agreed,  (only one proponent, Lou) should be 
>>> update means that clients break -- i.e., mirroring the issues we 
>>> have with CLI -- is unacceptable.  FWIW it is true that I agree with 
>>> them both as a contributor and as WG co-chair.
>>>
> I'll have to go review the youtube to see what rob said, that lead me 
> to this -- I, of course, can simply be wrong.
>
>
> I hear you, but it is my understanding that multiple implementations 
> are grappling with the challenge now and either have support now or 
> are planning for it.  Either way, it *is* what is codified in 7950.
>
>> so that as a design team, and as a WG, we can start to reach 
>> consensus on parts of the solution as we still develop the other 
>> parts.  I appreciate that it is necessary to see the path to a 
>> solution for all requirements before we can be sure that the solution 
>> is on the right track.
>>
> come up a solution that works great except that it *precludes* a 
> server from providing support for old clients.

So, I just see this as trying to do the work more efficiently. If we can 
divide the work up then we can have different individuals of the design 
team helping drive different parts of the overall solution, hopefully 
getting to an end solution more quickly.  If some parts of the solution 
are able to also move faster than other parts, then I think that this 
would also be a benefit.

I already think that there is a viable solution that uses schema version 
selection, e.g. as a I described in one of my previous responses.

Thanks,
Rob

>>> if your implementation approach is acceptable.) This is a 
>>> requirement on the solution.
>>>
>> problem.  I think that it will fundamentally be expensive to 
>> implement whether or not it is implemented in the client, server, or

---

From: Lou Berger <[email-masked]>
Date: Mon, 19 Nov 2018 11:07:04 -0500

> I'm reading the requirement 3.2 as violating the line above from 7950. But maybe my brain is still jet-lagged.

This is related to the date-based version of a model.  Today, to support 
a NBC basically a new module gets defined - think mib-2. So we could 
have ietf-interface and ietf-interface-2 (which has NBC changes to 
ietf-interface) supported by the same server using 7950 rules.

Lou

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 19 Nov 2018 16:38:33 +0000

On 2018-11-19, 11:23 AM, "Lou Berger" <[email-masked]> wrote:

    
It may just be a matter of rewording 3.2 as Rob mentioned.  I read 3.2 "different revisions of modules" as being date-based version of a model, and I believe Martin interpreted it the same way.

Regards,
Reshad.

    Lou

---

From: Lou Berger <[email-masked]>
Date: Mon, 19 Nov 2018 11:24:56 -0500

On 11/19/2018 11:20 AM, Robert Wilton wrote:
>> come up a solution that works great except that it*precludes*  a

This is sensible, but I think that we'll need to periodically sync the 
efforts to ensure that the overall solution is sound.

> selection, e.g. as a I described in one of my previous responses.

Great to hear! I either missed that one or have forgotten it, can you 
resend (unitcast to just me)?

Thanks,

Lou

---

From: Robert Wilton <[email-masked]>
Date: Mon, 19 Nov 2018 16:52:43 +0000

Hi,

So my principal thought is that we should split the work up so that we 
try and achieve rough DT and then WG consensus on the parts that we have 
most developed solutions for whilst we work on solutions to other parts 
of the requirements.

To that end, I agree with you that we should be progressing a "module 
level versioning" draft that covers: module level version number, fixes 
imports, fixes status handling, module level file naming).

Would the authors and design team be willing to adopt the clacla draft 
(with it updated to use modified semver) as a starting point for this work?

If the design team agrees then would one of the existing authors be 
happy to act as editor and drive updates to this draft?

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Tue, 20 Nov 2018 11:57:39 +0000

Hi Mahesh,

On 16/11/2018 11:45, Mahesh Jethanandani wrote:
> Hi Rob,
>
> Will echo comments on trying to keeping this group and the WG moving 
> forward. Sorry, I am still on vacation, so could not attend the 
> meeting. And as Joe mentioned, next week is Thanksgiving. The 
> following week looks better (ahh!, I see next week is cancelled)
>
> More comments inline.
>
> On Nov 15, 2018, at 5:19 PM, Robert Wilton <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Hi,
>>

Yes.

> Can we split this into two questions to see if we can reach some 
> consensus. If we can agree that changes should be supported on older 
> releases, it might help to define what kind of changes are 
> permissible. Broadly, changes that fix the model that is broken or 
> improve it, bc or nbc, should be allowed.
>>
> Is there any way to state this without implying a solution? Sorry, I 
> am in flight, and do have the 3.2 text in front of me to propose 
> wording for it.
>>
> If there is a desire to solve this problem, I would like to understand 
> what is the requirement. So yes, we should have a requirement stating it.
>
> Separately, from a solution perspective, I am not sure what would be 
> entailed in defining a "sets of related modules". What is required to 
> make a set of modules wholesome, if I could call it so? Who is testing 
> the set?
>>
> Agree. But pushing for WG adoption might be one way to force a 
> discussion of what those issues are. Adoption should not be gated on 
> all problems having been solved.
>>
>>
>> 2) Solutions:
>>
> I would agree that I do not see how a new module name helps to solve 
> the problem of a major version change. If the nodes that are changed 
> are not something that impacts my solution, why do I care?
>>

I had meant to say the design team discussions appears to prefer the 
"modified semver" as a solution, but it specifically addresses the 
requirement of allowing bug fixes.

> I would rather that we get adoption call made now, and follow that 
> with closing out the requirements. Let us not conflate the two steps.
>>
> I have never understood how this was going to work. We have a problem 
> in Cisco with getting CLI and NETCONF to be in sync. Add in two 
> different nodes, and we are looking at compounding the problem.
>>
> Because I do not understand this myself, I can probably take this one. 
> I believe it was Martin who brought it up.  This would have to include 
> 7) as you state below.

OK.

Some brief thoughts on this:

Yang library-bis already defines module-sets, which might be a good 
starting point.
We might want to extend them in several ways:
  - Augment module-set with a version number.  Initially, I would 
propose that this is also uses a "modified semver" that would get 
updated based on how the modules contained within the module-set are 
changed.  Note, this is somewhat similar to how OpenConfig package 
versioning works, given that it is the obvious solution.
  - Perhaps allow a module-set to also contain a list of (module-sets, 
version) that it reuses, currently module-sets are only allowed to 
contain modules.  Or perhaps this will mean that they should be called 
packages instead of module sets.
  - Probably need to change how module-sets are combined.  The 
definition in YANG library-bis assumes that there will be no conflicts, 
but when this comes to packages I think that will be too restrictive.  
Instead, a think that a ordered resolution process is required, but this 
will require some careful thought.
  - Some form of static instance data document will probably be needed 
to define the module-sets/packages.
  - How are features handled?  Do mdoule-sets/packages need to be able 
to define their own module-set/package level features?

It would also be good to look at what Andy published previously on YANG 
packages (although IIRC he was considering language level constructs) 
and the OpenConfig approach.

>> 7) Defining how version selection could work (which should tie in the 
Some thoughts on how the version selection would work:
  - We would need to determine how the version selection could be done.  
E.g. does this need to be done as part of the hello message exchange, or 
could be define a YANG RPC for this?
  - In the case of RESTCONF, I think that the protocol would probably 
need to define new paths for accessing the data within a version set.  
E.g. so rather than accessing "{+restconf}/ds/<datastore>", once it had 
selected a version if would use the path something along the lines of: 
"{+restconf}/ms/<module-set-name>/ver/<version>/ds/<datastore>", or 
perhaps it might be better if the module-set-name and version are 
embedded as query parameters.

Thanks,
Rob

>> [email-masked] <mailto:[email-masked]>

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 20 Nov 2018 12:42:21 +0000

Hello,

First of all I am sorry, if I was to passionate in my last mail. I did 
not want to be rude, but I am worried about our progress. See the rest 
below.

regards Balazs

On 2018. 11. 19. 16:26, Robert Wilton wrote:
>>      >
>>      > I’m with Balasz for 3.2. My concern with 3.2 is that it 
>> requires a
>>      > solution, which violates 7950,
>>      >
>> I'm reading the requirement 3.2 as violating the line above from 
>> 7950. But maybe my brain is still jet-lagged.
>
> The server would probably always only ever "implement" the latest 
> module versions.
>
>  - if the client connects using an older schema version then the 
> server would translate to/from the latest schema version (used 
> internally) on the fly.
> Does this mean that the server is implementing more than one revision? 
> I would say no, not really.  But others may argue otherwise.
>
> Thanks,
> Rob 

BALAZS: IMHO if the server advertises in YANG library a module (version) 
as implemented, the client has no way to know (and should  not be 
interested in) whether internally some mapping is used or not. (Also the 
new version of yang-library only uses the name of the module as a key, 
so it is not possible to advertise multiple revisions of the same module.)

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 20 Nov 2018 13:01:43 +0000

> It may just be a matter of rewording 3.2 as Rob mentioned.  I read 3.2 "different revisions of modules" as being date-based version of a model, and I believe Martin interpreted it the same way.

BALAZS: Could you please specify what "date-based version of a model" means?

For me the only version/revision of a model was what ietf-yang-library 
advertised. Is that a "data-based version"? Would you propose that 
ietf-yang-library (in some form) advertises multiple versions of the 
same module as implemented?

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 20 Nov 2018 13:33:48 +0000

Hello Lou,

3.2 The solution MUST provide a mechanism to allow servers to
simultaneously support clients using different revisions of
modules. ...

For me this means one of 2 things:

as long as a model is changed in a BC manner (including
deprecated/obsolete issues) a server implementing the last
version of the model can support clients using previous versions
of the same model.  However when an NBC change is done(which is
allowed), only new clients will be supported. If you want to
support old  clients, keep your changes BC!

the server MUST support clients using different versions ((5
and 6) of the model even if there have been NBC changes between
ver5 and ver6.

Which is your interpretation 1) or 2) or something else?

I have problems with 2). It is expensive to implement (we will
not do it). It will take much time to define as IMHO it will need
updates to YANG 1.1 , ietf-yang-library, Netconf, Restconf,
YangPush, RFC6470, RFC6022, etc. IMO this is really the point when
Jurgen's model/path/revision addressing needs to be deployed
everywhere. If we keep to a single version for each module we can
and should avoid this change of addressing. Even with this I don't
object to it, but I really want to avoid delaying the versioning
solution while we settle this requirement. I don't want to
preclude this, if you want it, go ahead, but please lets follow
what Rob W. proposed: "If we can divide the work up then we can
have different individuals of the design team helping drive
different parts of the overall solution, hopefully getting to an
end solution more quickly."

As a private comment: IMHO it is easier to rename models either
completely or to interfaces-2  then to use versioning for this.

regards Balazs

P.S. As for keeping customers happy: we do our best to minimize
the number of NBC changes, but using a CLI or YANG does not change
the underlying fact that NBC changes are sometimes needed because
of bugs, killing off old functionality, or the need for new
incompatible functionality. Bugs, etc didn't disappear because we
use YANG instead of a CLI.as long

On 2018. 11. 19. 16:10, Lou Berger
wrote:

Hi,

I’m with Balasz for 3.2. My concern with 3.2 is that it requires
a solution, which violates 7950,

Humm - we must be talking past each other.  I'm reading the
requirement as that the spirit of 7950 must be preserved.  What am
I missing?

Thanks,

Lou

without going into how viable the solution
is. I am fine if that solution is considered for the solutions
draft, but putting it as a MUST in the requirements draft seems
biased.

*From: *Netmod-ver-dt <[email-masked]> on
behalf of Lou Berger <[email-masked]>

*To: *Balázs Lengyel <[email-masked]>,
"Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)"
<[email-masked]>, "[email-masked]"
<[email-masked]>

Balázs

·

· 3.2 is not fully agreed,  (only one proponent, Lou) should
be

I'm sorry - that's not how I read the WG.  To be clear, I'm
talking about the first part of 3.2 (the rest is about
implementation compromises which to me is not a core
requirement.)

The solution MUST provide a mechanism to allow
servers to

simultaneously support clients using different
revisions of

modules.

This part of 3.2 is what we have by today's rules.  It is
support today either through backward compatible changes or via
new modules for NBCs.  I think we heard loud and clear in this
past meeting from users, specifically Chris and Rob S, that
making it so a software update means that clients break -- i.e.,
mirroring the issues we have with CLI -- is unacceptable.  FWIW
it is true that I agree with them both as a contributor and as
WG co-chair.

Note, nothing in this requirement says you as a vendor need to
support this requirement.  (Your customers and the market will
judge if your implementation approach is acceptable.) This is a
requirement on the solution.

If you disagree, please raise this again on the WG list or as a
separate adoption call issue.

Lou

[email-masked]

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 20 Nov 2018 13:35:53 +0000

Yes, I would be happy  to work on this based on clalcla and
modified semver. I would prefer to be one of the lesser authors as
I am involved in 5 drafts at the moment.

regards Balazs

On 2018. 11. 19. 17:52, Robert Wilton
wrote:

Hi,

So my principal thought is that we should split the work up so
that we try and achieve rough DT and then WG consensus on the
parts that we have most developed solutions for whilst we work
on solutions to other parts of the requirements.

To that end, I agree with you that we should be progressing a
"module level versioning" draft that covers: module level
version number, fixes imports, fixes status handling, module
level file naming).

Would the authors and design team be willing to adopt the
clacla draft (with it updated to use modified semver) as a
starting point for this work?

If the design team agrees then would one of the existing
authors be happy to act as editor and drive updates to this
draft?

Thanks,

Rob

On 15/11/2018 16:49, Balázs Lengyel
wrote:

Hello Rob,

We are not progressing that much. I see a risk of getting
stuck. Another Yangpush project running 4-5 years or more. We
did not agree on any of the crucial issues. IMHO we should try
to establish "rough" consensus on some issues and  go
forward.  Couldn't we try to be more assertive? Issues to
settle:

Generally I see a risk to this effort. The chairs should
be convinced to help us towards a limited solution, not
include everything someone thought as a good idea.

3.2 is not fully agreed,  (only one proponent, Lou) should
be pushed into a separate draft. Whoever is interested
should work on it. I will not implement 3.2, so either
remove it or do whatever is the fastest optional solution.
It is not a requirement its an obstacle to be navigated.

Agree we/vendors/our operator-customers need bugfixes in
older releases, but are willing to accept that in that case
all compatibility info is lost (m/M). So I would push for
the modified semver, and try to leave everything else in a
dead appendix.

Don't define bugfix, there are too many opinions. Define 3
kinds of changes NBC/BC/Cosmetic. Allow changes like the
wrong regexp for Ipv4 address to be classified as cosmetic,
if it is TRIVIAL to ALL parties what should have been the
correct pattern.

In the clacla draft we decided to exclude packaging.
Unless we can reuse OpenConfig as-is it will seriously delay
the work.

Personally I would also like a list of things that are
decided to be out of scope for the main solution draft,
including:

The versioning number scheme does not consider supported
features, deviations or implementation of deprecated nodes
as that would leed to a more complicated solution. Just make
a simple assumption: No removed features, all deprecated
stuff still works, deviations are all BC.

packaging

regards Balazs

On 2018. 11. 15. 11:19, Robert
Wilton wrote:

Hi,

This is my summary (from memory) of where I think that we
are at:

Broadly the WG seemed to be happy that the DT is making
progress and should keep working.  However, I don't think
that we are at the stage where we are ready for a given
solution.

Anees is unhappy that the OpenConfig prior art isn't being
acknowledged in the either the requirements or versioning
solution comparison drafts.  We should rectify this to keep
them happy.

1) Requirements:

A) Req 1.4:

i) Do we need to support bug fixes in older releases?  And
if so, what constitutes a bug fix.

iii) Do we support nbc changes in an older release? (E.g.
for a broader definition of bug fix, or perhaps we can avoid
defining bug fix altogether).

B) Req 3.2:

- Martin doesn't like the wording since it implies
supporting 2 module revisions at the same time.

C) There is a desire that we also try and solve versioning
at the package level (e.g. sets of related modules), which
would be expanding the remit of this work.  Again should
there be a requirement stating this?

We also want to get WG adoption for the requirements draft,
which we should push to resolve over the next few weeks.
Iin the meeting, I don't think that anyone is opposed to
doing an adoption call on the requirements draft, but they
have issues with some of the requirements.

2) Solutions:

i) Lou would like to see viable solutions to all
requirements (i.e. all pieces) before he thinks that we can
state whether or not we are heading in the right direction.
Specifically, I think that his particular concern is being
able to see a solution proposed for Req 3.2.

ii) Lou is still keen on the idea of doing minor versioning
within a module, using revision dates as we do today, but
use new module names (e.g. "module-foo-2") to indicate major
version changes. Some folk think there is a solution to have
two separate nodes controlling the same underlying config,
but I can't really see how such a solution works in the
general case, or at least there is a set of constraints
under which such a solution could work.  As a design team, I
think that we need to explore this and write this down.

iii) I think that there is a partial consensus that some
sort of module level version number is a good thing:

- Rob Shakir thinks semver is fine, and
deviations/augmentations can be used where it doesn't work
(e.g. bug fixes to older releases), but I think that this is
misusing revision statements.

- Going with semver probably means that the solution
doesn't work for vendors.

- Perhaps another alternative is a custom 3 digit
versioning scheme that doesn't have the semver guarantees,
and relies on module comparison.

iv) Per release semver is not liked, and can be regarded as
being dead. I think that the design team had probably
already reached this point anyway.

In the slides I proposed phasing the work as separate
drafts, although I don't think that the chairs would accept
us deferring solutions for particular requirements.

There is still an open question as to whether some/all of
this work needs to be done as part of YANG next, or if
some/all of it can be done as extensions.  I know that Kent
is more keen on a YANG.next, but Lou prefers of defining
extensions and then folding extensions into a new version of
YANG in future.

1) Closing out on requirements and getting WG adoption of
the reqs draft.

2) Investigating an describing whether two nodes writing the
same config item can work in the general case, and if so,
what are the constraints/impact.

5) Specifying the extensions required for a schema
comparison tool to work effectively

6) Investigating what packages/module sets would look like.
It would be nice if these could reuse the same module level
versioning scheme.

7) Defining how version selection could work (which should
tie in the packages/modules work).

Thanks,

Rob

---

From: Joe Clarke <[email-masked]>
Date: Tue, 20 Nov 2018 09:08:12 -0500

On 11/20/18 08:33, Balázs Lengyel wrote:
>  1. as long as a model is changed in a BC manner (including
>     deprecated/obsolete issues) a server implementing the last version
>     of the model can support clients using previous versions of the same
>     model.  However when an NBC change is done(which is allowed), only
>     new clients will be supported. If you want to support old  clients,
>     keep your changes BC!
>  2. the server MUST support clients using different versions ((5 and 6)
>     of the model even if there have been NBC changes between ver5 and ver6.
> 

Interpretation is maybe the wrong word.  This is a requirement.  Treat
it as you will.

That said, my view of a solution has been 2.  I think 1 is a perfectly
valid solution to satisfy this requirement, though.  Meaning, we could
document these requirements.  Point 1 also doesn't preclude 2.  Meaning,
someone could compose a draft that describes solution 2, and that could
be implemented by some server vendors.

> 
> I have problems with 2). It is expensive to implement (we will not do
> it). It will take much time to define as IMHO it will need updates to
> YANG 1.1 , ietf-yang-library, Netconf, Restconf, YangPush, RFC6470,
> RFC6022, etc. IMO this is really the point when Jurgen's
> model/path/revision addressing needs to be deployed everywhere. If we
> keep to a single version for each module we can  and should avoid this
> change of addressing. Even with this I don't object to it, but I really
> want to avoid delaying the versioning solution while we settle this
> requirement. I don't want to preclude this, if you want it, go ahead,
> but please lets follow what Rob W. proposed: "/If we can divide the work
> up then we can have different individuals of the design team helping
> drive different parts of the overall solution, hopefully getting to an
> end solution more quickly./"

Again, I think we should include requirement 3.2.  I am thinking of
adding some additional wording around what Lou said about keeping the
spirit of 7950 update rules, but I don't think we should soften the
language after all.

Why?  Well, the solution MUST address this requirement, but the
addressing could be in line what your point 1 above IMHO.

Joe

> P.S. As for keeping customers happy: we do our best to minimize the
> number of NBC changes, but using a CLI or YANG does not change the
> underlying fact that NBC changes are sometimes needed because of bugs,
> killing off old functionality, or the need for new incompatible
> functionality. Bugs, etc didn't disappear because we use YANG instead of
> a CLI.as long
> 
> On 2018. 11. 19. 16:10, Lou Berger wrote:
>> Hi,
>>
>> requirement as that the spirit of 7950 must be preserved.  What am I
>> missing?
>>
>> Thanks,
>>
>> Lou
>>
>>

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 20 Nov 2018 14:12:37 +0000

If the team/WG is OK with this, if we are not forced to specify a 
solution based on 2), I am happy.

Balazs

---

From: Robert Wilton <[email-masked]>
Date: Tue, 20 Nov 2018 15:24:02 +0000

> solution based on 2), I am happy.

I don't think that I would regard 1 as a valid solution.

I have a different example:

I have a small C DLL API between some generic process code, and a 
platform/hardware specific DLL implementation (e.g. like a plugin API).

This API has versioning (at the entire DLL API level, rather than on a 
per API function basis), and has undergone various changes over the 
years, not all of them are backwards compatible in API semantics, but 
broadly all backwards compatible in the functionality that they support.

After 15 years, this generic process code still supports _all_ versions 
of this API.  There are still some implementations coded that implement 
the original API written 15 years ago, others are coded against the 
latest API and various versions in between.

The generic process code is always coded against the latest version of 
the API, which implements a shim layer that translates to older APIs if 
required.

In my experience, this approach has been very stable, and worked well.  
Not least because it allows a decoupling between the generic process 
code, and the platform/hardware implementations.

Personally, I would like to try and achieve something similar at the 
YANG Mgmt API, i.e. the ability to decouple server implement from client 
API version. Whether vendors choose to implement this is down to market 
pressures to decide whether or not this problem gets solved in the 
servers or in the clients.

So, I think that we should at least try and specify a solution for 
this.  If the DT and/or WG decides then decides that this is too complex 
then so be it.  But let's get at least get one proposal on the table first.

Thanks,
Rob

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 20 Nov 2018 16:21:01 +0000

Hello,

IMHO this is complicated and expensive. So please let us separate
this effort from the main part of the requirements.

You say "we should
at least try and specify a solution". This contains
the word SHOULD which I would like to see in the requirement text
as well instead of MUST. I guess some people like me thought we
are looking for option 1) only.

regards Balazs

E.g. I have some  nightmare scenarios before me: We need to
update YangPush to indicate which version of the YANG model we
want to subscribe to. This further delays (kills) yangpush. :-(

On 2018. 11. 20. 16:24, Robert Wilton
wrote:

On 20/11/2018 14:12, Balázs Lengyel
wrote:

If
the team/WG is OK with this, if we are not forced to specify a
solution based on 2), I am happy.

I have a small C DLL API between some generic process code, and
a platform/hardware specific DLL implementation (e.g. like a
plugin API).

This API has versioning (at the entire DLL API level, rather
than on a per API function basis), and has undergone various
changes over the years, not all of them are backwards compatible
in API semantics, but broadly all backwards compatible in the
functionality that they support.

After 15 years, this generic process code still supports _all_
versions of this API.  There are still some implementations
coded that implement the original API written 15 years ago,
others are coded against the latest API and various versions in
between.

The generic process code is always coded against the latest
version of the API, which implements a shim layer that
translates to older APIs if required.

In my experience, this approach has been very stable, and
worked well.  Not least because it allows a decoupling between
the generic process code, and the platform/hardware
implementations.

Personally, I would like to try and achieve something similar at
the YANG Mgmt API, i.e. the ability to decouple server implement
from client API version. Whether vendors choose to implement
this is down to market pressures to decide whether or not this
problem gets solved in the servers or in the clients.

So, I think that we should at least try and specify a solution
for this.  If the DT and/or WG decides then decides that this is
too complex then so be it.  But let's get at least get one
proposal on the table first.

Thanks,

Rob

Balazs

Hello Lou,

3.2  The solution MUST provide a mechanism to allow servers
to

modules.  ...

deprecated/obsolete issues) a server implementing the
last version

of the model can support clients using previous
versions of the same

model.  However when an NBC change is done(which is
allowed), only

new clients will be supported. If you want to support
old  clients,

keep your changes BC!

2. the server MUST support clients using different
versions ((5 and 6)

of the model even if there have been NBC changes
between ver5 and ver6.

Interpretation is maybe the wrong word.  This is a
requirement.  Treat

it as you will.

That said, my view of a solution has been 2.  I think 1 is a
perfectly

valid solution to satisfy this requirement, though.  Meaning,
we could

document these requirements.  Point 1 also doesn't preclude
2.  Meaning,

someone could compose a draft that describes solution 2, and
that could

I have problems with 2). It is
expensive to implement (we will not do

it). It will take much time to define as IMHO it will need
updates to

YANG 1.1 , ietf-yang-library, Netconf, Restconf, YangPush,
RFC6470,

model/path/revision addressing needs to be deployed
everywhere. If we

keep to a single version for each module we can  and should
avoid this

change of addressing. Even with this I don't object to it,
but I really

want to avoid delaying the versioning solution while we
settle this

requirement. I don't want to preclude this, if you want it,
go ahead,

but please lets follow what Rob W. proposed: "/If we can
divide the work

up then we can have different individuals of the design team
helping

drive different parts of the overall solution, hopefully
getting to an

Again, I think we should include requirement 3.2.  I am
thinking of

adding some additional wording around what Lou said about
keeping the

spirit of 7950 update rules, but I don't think we should
soften the

language after all.

Why?  Well, the solution MUST address this requirement, but
the

Joe

As a private comment: IMHO it is
easier to rename models either

completely or to interfaces-2  then to use versioning for
this.

regards Balazs

P.S. As for keeping customers happy: we do our best to
minimize the

number of NBC changes, but using a CLI or YANG does not
change the

underlying fact that NBC changes are sometimes needed
because of bugs,

killing off old functionality, or the need for new
incompatible

functionality. Bugs, etc didn't disappear because we use
YANG instead of

a CLI.as long

Hi,

I’m with Balasz for 3.2. My
concern with 3.2 is that it requires a

Humm - we must be talking past each other.  I'm reading
the

requirement as that the spirit of 7950 must be preserved.
What am I

missing?

Thanks,

Lou

without going into how viable the
solution is. I am fine if that

solution is considered for the solutions draft, but
putting it as a

*From: *Netmod-ver-dt <[email-masked]>
on behalf of

"Robert Wilton -X

Balázs

·

· 3.2 is not fully agreed,  (only one proponent,
Lou) should be

I'm sorry - that's not how I read the WG.  To be clear,
I'm talking

about the first part of 3.2 (the rest is about
implementation

The solution MUST provide a mechanism to
allow servers to

simultaneously support clients using
different revisions of

modules.

This part of 3.2 is what we have by today's rules.  It
is support

today either through backward compatible changes or via
new modules

for NBCs.  I think we heard loud and clear in this past
meeting from

users, specifically Chris and Rob S, that making it so a
software

update means that clients break -- i.e., mirroring the
issues we have

with CLI -- is unacceptable.  FWIW it is true that I
agree with them

Note, nothing in this requirement says you as a vendor
need to

support this requirement.  (Your customers and the
market will judge

if your implementation approach is acceptable.) This is
a requirement

on the solution.

If you disagree, please raise this again on the WG list
or as a

Lou

[email-masked]

--

Senior Specialist

[email-masked]

---

From: Robert Wilton <[email-masked]>
Date: Tue, 20 Nov 2018 16:45:22 +0000

On 20/11/2018 16:21, Balázs Lengyel wrote:
>
> Hello,
>
> IMHO this is complicated and expensive.
>
Potentially, although I think that it is probably less complex/expensive 
than you do.

But why is it OK to force all clients to pick up this complexity and 
cost?  I don't believe that it is any easier for clients to handle a 
myriad of non backwards compatible versions.

If the cost of handling NBC changes is pushed to the client, then the 
server vendors have much less reason to avoid making them.

However, if the costs of handling NBC changes falls on the server, then 
I think that the server vendors will work that little bit harder to get 
more stable APIs in the first place that are less likely to be churned.

> So please let us separate this effort from the main part of the 
> requirements.
>
> You say "/we should at least try and specify a solution/". This 
> contains the word SHOULD which I would like to see in the requirement 
> text as well instead of MUST. I guess some people like me thought we 
I still think that it is a MUST.

A requirement that is a SHOULD really ends up meaning "it would be nice 
if you could do this"

If we can't find a solution, then we just declare that we haven't been 
able to meet that requirement, but as a design team, our stated goal 
should be that we are trying to meet this requirement.

> regards Balazs
>
> E.g. I have some  nightmare scenarios before me: We need to update 
> YangPush to indicate which version of the YANG model we want to 
> subscribe to. This further delays (kills) yangpush. :-(
>
No, we publish YANG push now, and then update it in future. There is no 
need for it to wait.

Thanks,
Rob

> On 2018. 11. 20. 16:24, Robert Wilton wrote:
>>
>>
>> This API has versioning (at the entire DLL API level, rather than on 
>> a per API function basis), and has undergone various changes over the 
>> versions of this API.  There are still some implementations coded 
>> that implement the original API written 15 years ago, others are 
>> coded against the latest API and various versions in between.
>>
>> The generic process code is always coded against the latest version 
>> of the API, which implements a shim layer that translates to older 
>> APIs if required.
>>
>> In my experience, this approach has been very stable, and worked 
>> well.  Not least because it allows a decoupling between the generic 
>> process code, and the platform/hardware implementations.
>>
>> YANG Mgmt API, i.e. the ability to decouple server implement from 
>> client API version. Whether vendors choose to implement this is down 
>> to market pressures to decide whether or not this problem gets solved 
>> in the servers or in the clients.
>>
>> this.  If the DT and/or WG decides then decides that this is too 
>> complex then so be it.  But let's get at least get one proposal on 
>> the table first.
>>
>> Thanks,
>> Rob
>>
>>
>>>
>>>
>>> Balazs
>>>
>>>>> version
>>>>>>> have
>>>>>>> judge

---

From: Lou Berger <[email-masked]>
Date: Tue, 20 Nov 2018 12:42:55 -0500

> BALAZS: Could you please specify what "date-based version of a model" means?

sorry, should have said revision based.

> advertised. Is that a "data-based version"?

yes.

> Would you propose that

I'm not advocating any solution.   Just stating what is possible using a 
7950-based solution.

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 20 Nov 2018 12:39:12 -0500

> so it is not possible to advertise multiple revisions of the same module.)

Just to ensure we're on the same page: In 7950 systems, a NBC module 
would be advertised with a different module name, and both old and new 
could be supported.

Lou

---

From: Robert Wilton <[email-masked]>
Date: Tue, 20 Nov 2018 18:06:54 +0000

> would be advertised with a different module name, and both old and new 

I know that this is what 7950 states, but I'm still not convinced that 
this is a viable solution for configuration, or at a minimum I think 
that it is more complex and more nuanced than just stating that the 
server can implement two versions of a module if they have different names.

Specifically when happens if one client is trying to configure the 
system using the old version of the module, and another client is trying 
to configure the system using the new version of the module.

And more specifically, I think that how servers handle this problem is 
likely to be different, and hence not interoperable.

Hence, I don't really buy into "we have a working solution today that we 
don't want YANG versioning to break", but I do buy into the "this is a 
real and important problem to solve and at the very least the YANG 
versioning team should be trying to solve it".

Thanks,
Rob

> .

---

From: Lou Berger <[email-masked]>
Date: Tue, 20 Nov 2018 13:23:13 -0500

On 11/20/2018 1:06 PM, Robert Wilton wrote:
> but I do buy into the "this is a

It sounds like we agree that addressing this is something that can't be 
dropped - independent of how we each got here!

Thanks,

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 20 Nov 2018 12:54:14 -0500

Hi,

On 11/20/2018 8:33 AM, Balázs Lengyel wrote:
>     of the model can support clients using previous versions of the
>     same model.
>
agreed.
>
>  1. However when an NBC change is done(which is allowed), only new
>     clients will be supported. If you want to support old clients,
>     keep your changes BC!
>
If we're talking what 7950 allows, a NBC change would require a new 
module.  No exceptions.  Certainly a vendor could alter it's support 
which would break an existing client, but this is what the 
implementation is doing, not what 7950 dictates.

>  1. 2. the server MUST support clients using different versions ((5
The requirement is revisions not versions.  I took revisions to mean one 
that includes a NBC change.  Today, this would be done with different 
module names.

> I have problems with 2). It is expensive to implement (we will not do it).
>
sure I respect this position and there's nothing that prevents you from 
following this path.  What I don't think is reasonable is for your 
position to limit what the market can do, i.e., what implementations are 
possible with a standard solution.

> It will take much time to define as IMHO it will need updates to YANG 
> 1.1 , ietf-yang-library, Netconf, Restconf, YangPush, RFC6470, 
> model/path/revision addressing needs to be deployed everywhere.
>
Your presupposing a solution.  If we follow an approach where NBC 
version numbers are encoded in the module name, tooling can address this 
without changing any of the mentioned RFCs. I'm not advocating a 
specific solution, but rather pointing out that there are different 
solutions possible with different tradeoffs.

> If we keep to a single version for each module we can  and should 
> avoid this change of addressing. Even with this I don't object to it, 
> but I really want to avoid delaying the versioning solution while we 
> settle this requirement. I don't want to preclude this, if you want 
> it, go ahead, but please lets follow what Rob W. proposed: "/If we can 
> divide the work up then we can have different individuals of the 
> design team helping drive different parts of the overall solution, 
> hopefully getting to an end solution more quickly./"
>
I think subdividing the problem is a a fine idea, but I don't think it 
works to solve one part while breaking/worsening the other.

Lou

> functionality. Bugs, etc didn't disappear because we use YANG instead 
> of a CLI.as long
>
>>> *To: *Balázs Lengyel <[email-masked]>, "Robert Wilton 
>>> -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]>,

---

From: Robert Wilton <[email-masked]>
Date: Wed, 21 Nov 2018 10:46:17 +0000

On 20/11/2018 12:42, Balázs Lengyel wrote:
>>> requirement
>> Does this mean that the server is implementing more than one 
>> revision? I would say no, not really.  But others may argue otherwise.
>>
>> Thanks,
>> Rob 
>
> BALAZS: IMHO if the server advertises in YANG library a module 
> (version) as implemented, the client has no way to know (and should  
> not be interested in) whether internally some mapping is used or not. 
> (Also the new version of yang-library only uses the name of the module 
> as a key, so it is not possible to advertise multiple revisions of the 
> same module.)

So, probably the schema advertised by YANG library would need to change 
to reflect the schema version that the client has chosen to interact with.

The schema that is reported in yang-library/schema would always still 
conform to the rule that only a single version of a particular module 
can be implemented.

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Fri, 23 Nov 2018 13:03:34 +0000

Hi,

Just to try and close on this, so that we can keep forward momentum.

I've seen no opposition to the DT adopting the clacla draft as the basis 
of a "module level versioning" solution that covers: module level 
version number, fixes imports, fixes status handling, module level file 
naming).

Hence, we should proceed on that basis:
  - Joe, I think that you have agreed to be editor this draft, so when 
you get the chance, please can you rename and upload to the verdt github 
project, and send out the details.
  - Please can folks review, and send comments to the DT on what things 
should be improved/changed.  I would suggest trying to keep these 
comments relatively high level at the moment to try and reach agreement 
on structure and content before getting into details.
  - Perhaps we can get this done before Thursdays meeting so that we can 
use this as a basis of discussion?

Thanks,
Rob

On 19/11/2018 16:52, Robert Wilton wrote:
> try and achieve rough DT and then WG consensus on the parts that we 
> have most developed solutions for whilst we work on solutions to other 
> parts of the requirements.
>
> level versioning" draft that covers: module level version number, 
> fixes imports, fixes status handling, module level file naming).
>
>>     for Ipv4 address to be classified as cosmetic, if it is TRIVIAL
>>     to ALL parties what should have been the correct pattern.
>>   * In the clacla draft we decided to exclude packaging. Unless we
>>   * The versioning number scheme does not consider supported
>>> should keep working.  However, I don't think that we are at the 
>>> stage where we are ready for a given solution.
>>>
>>> - Remove the first sentence about versioning by software release.  
>>> In fact, I sent some proposed updated text to the alias yesterday 
>>> that Andy at least seems to be happy with.
>>>
>>>  - I think that Andy doesn't want us to solve this at all, although 
>>> I don't quite know whether he accepts translating between different 
>>> module, using revision dates as we do today, but use new module 
>>> names (e.g. "module-foo-2") to indicate major version changes. Some 
>>> folk think there is a solution to have two separate nodes 
>>> controlling the same underlying config, but I can't really see how 
>>> such a solution works in the general case, or at least there is a 
>>> set of constraints under which such a solution could work.  As a 
>>> design team, I think that we need to explore this and write this down.
>>>
>>>  - Rob Shakir thinks semver is fine, and deviations/augmentations 
>>> can be used where it doesn't work (e.g. bug fixes to older 
>>> releases), but I think that this is misusing revision statements.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Nov 2018 17:03:59 +0100

I object on the grounds that I believe you can't change how imports
work without having a new version of YANG. But then I do not know what
"DT adoption" means - could be it means nothing. Then I do not object.

/js

On Fri, Nov 23, 2018 at 01:03:34PM +0000, Robert Wilton wrote:
> I've seen no opposition to the DT adopting the clacla draft as the basis of
> a "module level versioning" solution that covers: module level version
> number, fixes imports, fixes status handling, module level file naming).
> 
>  - Joe, I think that you have agreed to be editor this draft, so when you
> get the chance, please can you rename and upload to the verdt github
> should be improved/changed.  I would suggest trying to keep these comments
> relatively high level at the moment to try and reach agreement on structure
> and content before getting into details.
>  - Perhaps we can get this done before Thursdays meeting so that we can use
> this as a basis of discussion?
> 
> Thanks,
> Rob
> 
> 
> > > on any of the crucial issues. IMHO we should try to establish
> > > "rough" consensus on some issues and  go forward.  Couldn't we try
> > > to be more assertive? Issues to settle:
> > > 
> > > > Broadly the WG seemed to be happy that the DT is making progress
> > > > and should keep working.  However, I don't think that we are at
> > > > the stage where we are ready for a given solution.
> > > > 
> > > > which we should push to resolve over the next few weeks. Iin the
> > > > meeting, I don't think that anyone is opposed to doing an
> > > > not we are heading in the right direction. Specifically, I think
> > > > that his particular concern is being able to see a solution
> > > > proposed for Req 3.2.
> > > >

---

From: Robert Wilton <[email-masked]>
Date: Fri, 23 Nov 2018 17:06:20 +0000

Hi Juergen,

On 23/11/2018 16:03, Juergen Schoenwaelder wrote:
> work without having a new version of YANG.

I think that it could be done as an extension.

E.g. a new "version" extension statement under import.  Compilers that 
understand it use the statement to choose the revision. Compilers that 
don't understand get the existing behaviour.  I.e. it is up to the 
compiler to choose whichever version that it wants to use.

But this is somewhat besides the point at this stage

>   But then I do not know what

It just means that we should be working on a concrete draft that starts 
to present solutions to some of these problems.  And rather than 
starting from a blank document, starting from the clacla draft as a base 
is hopefully less work.

For areas that we don't agree on, then we can either mark those 
documents as such, or leave them out.

OK?

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 23 Nov 2018 22:19:05 +0100

On Fri, Nov 23, 2018 at 05:06:20PM +0000, Robert Wilton wrote:
> understand it use the statement to choose the revision. Compilers that don't
> understand get the existing behaviour.  I.e. it is up to the compiler to
> choose whichever version that it wants to use.

Do you not see why having two compilers producing different results is
broken? Changing the import semantics is an NBC change. Folks on this
design team should understand that you can't hide this under covers.

> It just means that we should be working on a concrete draft that starts to
> present solutions to some of these problems.  And rather than starting from
> a blank document, starting from the clacla draft as a base is hopefully less
> work.
> 
> For areas that we don't agree on, then we can either mark those documents as
> such, or leave them out.
>

As I said, I do not know what DT adoption means. I am just pointing
out that NBC changes to YANG cannot be done with extensions. If people
want to propose something to incorporate in a future version of YANG,
so be it. But hiding NBC changes in extensions will not get my
support. I think it is good to clarify this point early on so that we
do not run into a big debate about this N months from now.

/js

---

From: Balázs Lengyel <[email-masked]>
Date: Mon, 26 Nov 2018 09:16:56 +0000

Hello,

I thought we could handle import by XXX in the following way,
that does not require a new YANG language version:

When the optional "revision-date" substatement is present, any
typedef, etc. are taken from the specified revision  of the
imported module. (from RFC 7950)

If no "revision-date" substatement is present, it is undefined
from which revision of the module they are taken. (from RFC
7950)

We should extend 2) with the usage of  the semver:import-versions
extension statement. (While maintaining that if revision date is
present 1) has to be followed.)

Is this NBC? Would this need a new YANG version? IMHO no.

I know this is not exactly what is contained in
https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-06#section-2.2

however I think this could be a solution. So if you want import by
semver-versions just don't use revision-date.

regards Balazs

On 2018. 11. 23. 17:03, Juergen
Schoenwaelder wrote:

/js

Hi,

Thanks,
Rob

Hi,

Would the authors and design team be willing to adopt the clacla draft
(with it updated to use modified semver) as a starting point for this
work?

Thanks,
Rob

Hello Rob,

regards Balazs

Hi,

1) Requirements:

A) Req 1.4:

B) Req 3.2:

2) Solutions:

Thanks,
Rob

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

---

From: Robert Wilton <[email-masked]>
Date: Mon, 26 Nov 2018 11:03:30 +0000

On 23/11/2018 21:19, Juergen Schoenwaelder wrote:
> broken?

I see that it is less broken than what we have today: Already today, the 
output that two YANG compilers will produce entirely depends on which 
module revisions they select during import.

E.g. module A might exist in two revisions 20180101 and 20190101.  The 
second revision might add a new container "foo".
module B also exists in two revisions 20180101 and 20190101 that both 
import (with revision) module A, but the second revision of module A 
augments container "module-a:foo"

When the YANG compiler compiles B, it has to choose which version of A 
to compile against, and obviously only one of them will work.  Normally 
the version of A will be chosen by: (i) input to the compiler, (ii) 
search path for the modules (e.g. only make one of them visible), (iii) 
some other selection scheme (perhaps the first found, or the latest 
revision).

I agree that for a given compiler that follows the same module 
resolution scheme, the behaviour could well differ whether or not it 
chooses to process the import-by-version extension.  But in both cases, 
these still seem to be valid implementations of the standard RFC 7950 
YANG import rules.

>   Changing the import semantics is an NBC change. Folks on this

So I don't agree that it is an NBC change,  but I can also see why you 
think that it is.

> do not run into a big debate about this N months from now.

So I do agree that the draft should make this point very explicitly 
early in the draft, and that we should ensure that we have the WG debate 
on this early on.

For me, to ensure that we make forward progress, I think that the key 
point here is that we want to get some of this stuff written down into a 
draft so that the WG can properly review and comment on it.  If there 
are parts that we can't get DT consensus on then I think that is also 
OK, we just need to point that out as well.

Specifically I hope that we can agree broadly on how the import by 
revision stuff should work.  Whether or not it needs to go into a new 
version of YANG is somewhat of a tangential question than can hopefully 
be worked out as the work progresses.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 26 Nov 2018 12:21:41 +0100

The behavior if no "revision-date" substatement is present is not
undefined in all situations. Section 5.6.5 of RFC 7950 details the
procedure servers that expose what has been implemented via yang
library.

   If a server lists a module C in the "/modules-state/module" list from
   "ietf-yang-library" and there are other modules Ms listed that import
   C without specifying the revision date of module C, the server MUST
   use the definitions from the most recent revision of C listed for
   modules Ms.

/js

On Mon, Nov 26, 2018 at 09:16:56AM +0000, Balázs Lengyel wrote:
>    Hello,
> 
>    I thought we could handle import by XXX in the following way, that does
>    not require a new YANG language version:
> 
>     1. When the optional "revision-date" substatement is present, any
>        typedef, etc. are taken from the specified revision� of the imported
>        module. (from RFC 7950)
>     2. If no "revision-date" substatement is present, it is undefined from
>        which revision of the module they are taken. (from RFC 7950)
> 
>    We should extend 2) with the usage of� the semver:import-versions
>    extension statement. (While maintaining that if revision date is present
>    1) has to be followed.)
> 
>    [1]https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-06#section-2.2
>    On 2018. 11. 23. 17:03, Juergen Schoenwaelder wrote:
> 
>  On 15/11/2018 16:49, Bal�zs Lengyel wrote:
> 
>  Hello Rob,
> 
>  [2][email-masked]
>  [3]https://www.ietf.org/mailman/listinfo/netmod-ver-dt
> 
>  --
>  [4]email:[email-masked]
> 
>  [5][email-masked]
>  [6]https://www.ietf.org/mailman/listinfo/netmod-ver-dt
> 
>  [7][email-masked]
>  [8]https://www.ietf.org/mailman/listinfo/netmod-ver-dt
> 
> 
>  [9][email-masked]
>  [10]https://www.ietf.org/mailman/listinfo/netmod-ver-dt
> 
> 
> 
>  --
>  Mobile: +36-70-330-7909              email: [11][email-masked]
> 
> References
> 
>    Visible links
>    1. https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-06#section-2.2
>    2. mailto:[email-masked]
>    3. https://www.ietf.org/mailman/listinfo/netmod-ver-dt
>    4. mailto:email:[email-masked]
>    5. mailto:[email-masked]
>    6. https://www.ietf.org/mailman/listinfo/netmod-ver-dt
>    7. mailto:[email-masked]
>    8. https://www.ietf.org/mailman/listinfo/netmod-ver-dt
>    9. mailto:[email-masked]
>   10. https://www.ietf.org/mailman/listinfo/netmod-ver-dt
>   11. mailto:[email-masked]

---

From: Balázs Lengyel <[email-masked]>
Date: Mon, 26 Nov 2018 11:41:20 +0000

Hello Jurgen,

So section 5.6.5 and 7.1.5 contradict each other. Problem. Errata ?

Section 5.6.5 refers to  the /module-state branch which might not even 
be implemented as it is deprecated in [email-masked], 
so its validity is shaky.

Section 7.1.5 is very explicit: "it is undefined from which revision" I 
see no 'room for misunderstanding there.

Even if I would agree with your argument for run-time, this still means 
that in implementation time, I am free to choose any revision. If I only 
put the chosen (potentially older version) on the server then that would 
be imported. So only in run-time can I really find out which version is 
imported. Not good.

regards Balazs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 26 Nov 2018 14:28:24 +0100

On Mon, Nov 26, 2018 at 11:41:20AM +0000, Balázs Lengyel wrote:
> 
> Even if I would agree with your argument for run-time, this still means that
> in implementation time, I am free to choose any revision. If I only put the
> chosen (potentially older version) on the server then that would be
> imported. So only in run-time can I really find out which version is
> imported. Not good.
> 

Once implemented, there are rules how yang-library is to be
interpreted.

/js