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

"Rob Wilton (rwilton)" <rwilton@cisco.com> Thu, 28 March 2019 08:43 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE258120074 for <netmod@ietfa.amsl.com>; Thu, 28 Mar 2019 01:43:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYYMgRZ0j37Z for <netmod@ietfa.amsl.com>; Thu, 28 Mar 2019 01:43:51 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F2B12026D for <netmod@ietf.org>; Thu, 28 Mar 2019 01:43:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27005; q=dns/txt; s=iport; t=1553762631; x=1554972231; h=from:to:subject:date:message-id:mime-version; bh=frANjkmGOm+oL2gRs1IbTnCArtZDItHZ2oFScnUOmy8=; b=Gz1UdeMuGMiJ538OHJFY3vmL9whHfdbfXSKrKu/uQDt8Fj8ASoIQp/0T T2BTB4AWMLQgB/ijnZHEcazknRd+/2oMElox2qJ9zqGLbH1c7ODcQlcJ9 TZb7d/OFQgesayAuUDiPs/skubOnNQbqYrqKHdtyXqUgZXd7g3CUJSRuQ E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAADoiJxc/4kNJK1JGhwBAQEEAQE?= =?us-ascii?q?HBAEBgVEHAQELAYEOgQJogQMnCowgiyKDC5c+FIFnDQEBJYl4IjQJDQEBAwE?= =?us-ascii?q?BCQEDAm0cAQuFfkUZATgIBDwmAQQbE4MIgRFkDzWqSoNChmwFgS8BizEXgUA?= =?us-ascii?q?/gRGBfWAHg00EGIEgD2eFEgOKcAIDhiYek3IJAodqi1MilAyLLIYJjTECERW?= =?us-ascii?q?BLh84gVZwFTuCbYIVF4NLilNBMQEJjR4kgQqBHwEB?=
X-IronPort-AV: E=Sophos;i="5.60,280,1549929600"; d="scan'208,217";a="251983024"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Mar 2019 08:43:49 +0000
Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x2S8hnVn018305 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <netmod@ietf.org>; Thu, 28 Mar 2019 08:43:49 GMT
Received: from xch-rcd-007.cisco.com (173.37.102.17) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 28 Mar 2019 03:43:48 -0500
Received: from xch-rcd-007.cisco.com ([173.37.102.17]) by XCH-RCD-007.cisco.com ([173.37.102.17]) with mapi id 15.00.1473.003; Thu, 28 Mar 2019 03:43:48 -0500
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: Meeting Notes from open YANG versioning Design Team meeting
Thread-Index: AdTkoRj6svo9SZKZQ5Ggg56oL5hxCA==
Date: Thu, 28 Mar 2019 08:43:48 +0000
Message-ID: <c22dd347c9ac42d68f74177c36bdea27@XCH-RCD-007.cisco.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.79.96]
Content-Type: multipart/alternative; boundary="_000_c22dd347c9ac42d68f74177c36bdea27XCHRCD007ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com
X-Outbound-Node: alln-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/97SJECqspmqPITkRtnGWcEesm5M>
Subject: [netmod] Meeting Notes from open YANG versioning Design Team meeting
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Mar 2019 08:44:01 -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