Subject: [netmod] Meeting Notes from open YANG versioning Design Team meeting

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 28 Mar 2019 08:43:48 +0000

Hi all,

These are the meeting notes that I captured from the open YANG versioning design team meeting yesterday.

Attendees: Juergen, Joe, Rob, Martin, Balazs, Kent, Reshad, Qin, Michael, Jason, Mahesh

Recording:

https://cisco.webex.com/cisco/lsr.php?RCID=c4d757b2c15e4f3cb20eff11a155203c

Password: iPpxJQA4

1) The first half of the meeting was based on discussing the requirements:

In summary, my interpretation is that there is consensus on the underlying spirit or the requirements, although in some cases the requirements text needs further polishing, and there was not complete consensus on all parts of all requirements.

-        The requirements discussion was only focussed on the requirements section 5 of draft-verdt-netmod-yang-versioning-reqs-02, we didn't discuss the background text.

-        The assumption as to whether this document should take the full path to publication has been deferred, but with the understanding that more discussion would be required on the background text to reach consensus.  There was a desire to reach agreement on the list of requirements itself.

-        These was agreement that IETF models should be limited to a linear revision history, with changes only in the most recent revision.  It was agreed that in some cases it is necessary to make NBC changes (in a new most recent revision) in IETF YANG modules to fix bugs.

-        There was discussion that an applicability statement could be added, or some of the requirements could be split between SDO vs Vendor requirements, but there did not seem to be strong consensus either for or against this change.  In anything, there seemed to be a slight preference to trying not to make this split.

-        It was agreed that YANG should have a single versioning scheme that is capable of covering both SDO requirements and vendor requirements.  There was agreement that guidelines text could be used to provide guidance on how IETF models should be versioned.

-        It was agreed that it would be better to change the requirement text so that instead of saying "NBC changes are allowed" the text to be more along that the requirement is to have a way "to communicate when NBC changes have occurred".  I.e. the key is how NBC changes are documented, rather than saying whether or not they are allowed/encouraged/etc.

-        We also discussed and agreed that it is better not to refer to "bug fixes" because we don't want to have to try and define what a bug fix is.  Instead, we agreed that requirement 1.4 should be stated something along the lines of:  "The solution MUST be able to describe backwards-compatible changes, as well as non-backwards-compatible changes in non-latest-release modules."

-        We discussed the import requirement (1.3), and there was strong consensus that there is a need to import version "X or later" (e.g. to fufill a leafref/augmentation/etc dependency).  There was no consensus on the second sentence ("Once non-backwards-compatible changes to modules are allowed, the refined import statement is used to express the correct dependency between modules"); specifically, whether there needs to be an "upper bound" on what version can be imported.

-        There was no consensus on whether "linear module development of YANG models is ideal" is correct.  In particular, it was noted that what might be ideal for clients may not be ideal for vendors.

2) Discussion on solutions:

No consensus was reached on a direction for the solution.

Most of the time was spent discussing a scheme suggested by Kent of keeping a ledger in the top of the YANG file that documents its history.  My interpretation is that this is very similar as the existing revision history in a YANG module, but with the following points:

-        Revisions are identified by a revision-date (as they are today), but the revision-date only identifies uniqueness, and the most recent version of a particular YANG module file.  E.g. it represents the head tip of a branch (or DAG leaf node), rather than the head tip of only a single linear history (as it does today).

-        For each revision, addition metadata is added to indicate whether the change is bc or nbc.

-        Extra metadata could be added (in the form of xpaths) to document which parts of the schema have changed (if a tree was added/removed then it would only reference the tree, not every element in it).

-        A "version tag" could be added to label a particular revision in a more human readable way.

-        YANG files would be identified by their revision-date, but the tag could also be optionally included in the filename.

-        Importing revision "X or later" would not mean any revision with a later date, but any revision that is contained in the history (i.e. ledger) of the file that is being imported.

-        The revision for an import could also be identified by the tag name.

-        This scheme allows for unlimited "branching" (since each new revision only has to point to the revision that it is derived from).

-        Possibly semver or similar annotations could still be done using the version tags.

-        There were concerns expressed about how easily clients will be able to relate to YANG modules that are only identified by revision date, but the tag may mitigate this problem.

-        We discussed the biggest benefit of this solution being that it allows arbitrary unlimited branching at any point, rather than being arbitrarily constrained.  The biggest downside to the solution is perhaps additional complexity for users managing multiple versions, i.e. it is less intuitive as to the relationship between revisions.

We ran out of time at 6.30 and no clear next steps were identified in the meeting.  The expectation is that this solution should be investigated further, either by the design team, or as a separate individual draft.  It would be good to try and reach agreement on the next steps so that the WG/DT can continue to make progress in this area.

Thanks,
Rob

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 29 Mar 2019 10:50:52 -0700

Hi Robert,

Thanks for putting the minutes together. 

> On Mar 28, 2019, at 1:43 AM, Rob Wilton (rwilton) <[email-masked]> wrote:
> 

The combination of these bullet items, and maybe other bullet items does not make clear if there was any consensus in allowing (or maybe even preventing) vendors from using a versioning system to keep track of NBC changes on other (non-latest) branches of the model. I think I heard from multiple vendors (outside of this meeting) that making NBC changes was needed on the non-latest branches, whatever IETF or other SDOs decide. Has that sentiment changed?

If it is the case, the split between the requirements of SDO and the vendors is inevitable.

Thanks.

Mahesh Jethanandani
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 29 Mar 2019 19:31:32 +0100

> If it is the case, the split between the requirements of SDO and the vendors is inevitable.

If there is a solution that can handle multiple branches, then the
same solution should work for SDOs that choose to use only a single
branch. I do not see why a split is inevitable.

/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: Mahesh Jethanandani <[email-masked]>
Date: Fri, 29 Mar 2019 14:16:49 -0700

> On Mar 29, 2019, at 11:31 AM, Juergen Schoenwaelder <[email-masked]> wrote:
> 

If a single solution works for both SDO and the vendor, that is great. And I think that was the point of the third bullet in the list I send.

But that does mean the requirements of SDO and the vendor community cannot be different. There is a strong requirement that SDOs make NBC changes only on the most recent version of the YANG models. In the vendor community, NBC changes are going to be made on non-latest branches also.

Mahesh Jethanandani
[email-masked]