Subject: [Netmod-ver-dt] YANG Ver DT meeting 20th Sept

From: Robert Wilton <[email-masked]>
Date: Thu, 20 Sep 2018 14:28:19 +0100

We are meeting today.

Apologies, I should have sent out meetings minutes from last week.

Some of the key points that were discussed, or have been raised over 
email (I may have missed some), that I think that we should continue 
discussing are:

(1) Do the requirements need to accommodate Jason's stream proposal, in 
particular should it be allowed to version each stream entirely 
independently?

(2) Should we allow updates/bugfixes to module versions before the 
latest?  Although it is somewhat questionable whether this would be done 
in IETF with the RFC process, it seems much more likely that a vendor 
would want to do this?

(3) Is the draft comparing solutions, that I put forward last week the 
right way forward?  Should I be committing this so that we can work 
towards updating this (perhaps with other solution proposals)?

(4) Juergen is raising a question about what type of clients we are 
aiming to support?
- Really basic scripts
- More sophisticated scripts (inc basic version checking)
- Advanced management clients

(5) What level of sophistication should a server support clients in a 
backwards compatible way?  E.g. can a client choose any versions and ask 
the server to parley using those, or can the server decide sets of 
compatible versions?

(6) Does module level versioning actually help solve the key problems, 
or is some level of per data node backwards compatibility checking 
required to solve the real problems?

Meeting details:

JOIN WEBEX MEETING
https://cisco.webex.com/ciscosales/j.php?MTID=m196086ddc16716f4da6338e481c01246
Meeting number (access code): 200 574 017
Meeting password: UdTbwvpT (83829878 from phones)

JOIN FROM A VIDEO SYSTEM OR APPLICATION
Dial sip:[email-masked]
You can also dial 173.243.2.68 and enter your meeting number.
 From the Cisco internal network, dial *267* and the 9-digit meeting 
number.  If you are the host, enter your PIN when prompted.

JOIN BY PHONE
+1-866-432-9903 Call-in toll-free number (US/Canada)
+1-408-525-6800 Call-in toll number (US/Canada)

Global call-in numbers:
https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MC&ED=435913767&tollFree=1

Toll-free dialing restrictions:
https://www.webex.com/pdf/tollfree_restrictions.pdf

Can't join the meeting?
https://collaborationhelp.cisco.com/article/WBX000029055

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Thu, 20 Sep 2018 17:35:52 +0100

Attendees: Balazs, Jason, Joe, Mahesh, Reshad, Sue, & Rob

Meeting notes:
- We made progress with several of the issues, tracked here 
(http://etherpad.tools.ietf.org:9000/p/netmod-ver-dt), and reproduced below.

If I have missed anything then feel free to add/query it.  It would be 
useful to try and spin some of these issues out to separate threads to 
try and progress them before the next meeting.

I think that those attending the meetings reached two useful conclusions:
(1) There is a requirement to support branching the YANG module 
history.  In particular, vendors have a requirement to add new 
functionality and bug fixes to older YANG modules that may have been 
released on older software release trains.
- we discussed, but did not conclude on whether to restrict new 
functionality to be backwards compatible.  Putting bugfixes aside, 
adding non backwards compatible new functionality to an older release 
seemed like something that would only be done very rarely.
- we did not properly discuss whether bugfixes have to be backwards 
compatible (if not being fixed in the latest).

(2) Having a solution that does not align with how vendors realistically 
manage software releases is not useful because vendors will not adopt 
the solution.
- but must also find a compromise so that the solution is not too 
complex for clients.

Here is the copy of the Etherpad from this meeting:

(1)Do the requirements need to accommodate Jason's stream proposal, in 
particular should it be allowed to version each stream entirely 
independently?
- Not directly discussed, but partially covered by discussion of some of 
the other questions.

(2) Should we allow updates/bugfixes to module versions before the 
latest?  Although it is somewhat questionable whether this would be done 
in IETF with the RFC process, it seems much more likely that a vendor 
would want to do this?
- The conclusion of the folks on the call was that this is a vendor 
requirement.  In particular, if this was not supported then vendors 
would come up with their own solutions to achieve this.

- Not discussed today.

(4) Juergen is raising a question about what type of clients we are 
aiming to support?
(i)Really basic scripts
(ii)More sophisticated scripts (inc basic version checking)
(iii) Advanced management clients
- Not discussed today.

- Not discussed today.

(6) Does module level versioning actually help solve the key problems, 
or is some level of per data node backwards compatibility checking 
required to solve the real problems?
- Perhaps aim to solve module level versioning first (which could also 
stillcover features)
- Solving at the datanode level could be additional functionality beyond 
the basic module level versioning, which would have the advantage that 
it would also be able to cover features and deviations (but still 
doesn't prevent the device from rejecting the configuration, e.g. due to 
an incompatible linecard).

(7) What semantics do we keep with revision-date? Is it required to be 
unique?  Does it need to be tied to one stream?
- Agree: At least within a stream the revision-date must always be 
increasing.
- Discussed, but did not conclude on whether it must be unique.
   - If not unique, concern of what the impact/confusion to clients 
would be (e.g. how many assume that <module, revision> uniquely 
identifies an instance of a YANG module).
   - If not unique, then YANG library would need to be bis'ed again.

(8) Are we allowed to have a tree of YANG modules (or multiple 
streams)?  Or must it only be a list of YANG modules?
- Here a stream can be defined as any point that the tree is branched.  
I.e. any point that you branch a historical (i.e. non latest) version of 
a module would effectively defines a new stream from that point.
- DT view is that vendors will branch older versionmodules, at least for 
bugfixes (do we need to consider backward compatible vs nbc bugfix), 
probably for features, perhaps for nbc features.
- Can we disallownbc changes to older versions?
- Or if not disallow nbc changes to older version, then can we have 
major.minor.patch, with some way of indicating that minor has broken the 
rules.  Although this makes the scheme more complicated.

- IDR/BGP wasgiven by Sueas an example of where this might be useful for 
Standards based YANG models:
     -Workingon the basic model at the moment.
     -Also working on many features/extensions.
     - Flowspec augments base BGP model.  Is it allowed to fix past 
errors in the BGP model?
     - <I missed the rest of this because I had to step outof the meeting>

(9) Can a server implement more than one revision/version of a module, 
in particular considering schema mount (LNE)?
- The assumption is that it can (in the sense of an LNE).

(10) if-feature usage, can a feature be disabled in a future release of 
software?
- Not discussed.

(11) Does the solution need to cover vendors, or just standards, or both?
- The conclusion was that the solution must at least cover vendors.  On 
the presumption that vendor requirements are a subset of the standards 
YANG modules requirements this probably means that both must be addressed.

Thanks,
Rob

On 20/09/2018 14:28, Robert Wilton wrote:
> (1) Do the requirements need to accommodate Jason's stream proposal, 
> in particular should it be allowed to version each stream entirely 
> independently?
>
> latest?  Although it is somewhat questionable whether this would be 
> done in IETF with the RFC process, it seems much more likely that a 
> vendor would want to do this?
>
> backwards compatible way?  E.g. can a client choose any versions and 
> ask the server to parley using those, or can the server decide sets of 
> compatible versions?
>