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

"Rob Wilton (rwilton)" <> Mon, 01 April 2019 10:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 84A931200E3 for <>; Mon, 1 Apr 2019 03:08:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FlIh55-2oHKu for <>; Mon, 1 Apr 2019 03:08:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7A044120075 for <>; Mon, 1 Apr 2019 03:08:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=10437; q=dns/txt; s=iport; t=1554113328; x=1555322928; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DmWnLfAeV92qeqN/X3/RazJ8jYVPKH9wTLnjVNjXwkk=; b=WYeFZ5GhCVoNwvpvDPw86F802yOgjljnYZJzPEqEJntgEWxc+jthmKLy 3NUWdjKretPiOkemqFTjINNgKJrweZBxOsRVvFcJWiXYHxMwTPCdQUA9g 1xYS1XNIjJDngGFBKWZ9P/PFRe/zuSwsaReh2ykbmi6cYFlMslf3V1urM g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAB14qFc/5RdJa1gAxkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYEOgQJogQMnCowgjTeJOIkOhXeBew4?= =?us-ascii?q?BAR+ETQKFQyI0CQ0BAQMBAQkBAwJtHAyFSgEBAQQtTA4CAgEIDgIBBAEBKAc?= =?us-ascii?q?bBhEUCQgBAQQBDQUIDAeDCIERTAMVqiuHeQ2CGgUFgSoBizIXgUA/g3UuPoI?= =?us-ascii?q?agksVEYUaA4pHMAWGJ5NxNgkCkB6DOCKULIs/h02MAQIRFYEuHziBVnAVO4J?= =?us-ascii?q?shiuKIEExjzyBHwEB?=
X-IronPort-AV: E=Sophos;i="5.60,296,1549929600"; d="scan'208,217";a="253712638"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Apr 2019 10:08:47 +0000
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id x31A8lq4020861 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 Apr 2019 10:08:47 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 1 Apr 2019 05:08:46 -0500
Received: from ([]) by ([]) with mapi id 15.00.1473.003; Mon, 1 Apr 2019 05:08:46 -0500
From: "Rob Wilton (rwilton)" <>
To: Mahesh Jethanandani <>, Juergen Schoenwaelder <>
CC: "" <>
Thread-Topic: [netmod] Meeting Notes from open YANG versioning Design Team meeting
Thread-Index: AdTkoRj6svo9SZKZQ5Ggg56oL5hxCAB4MM0AAAFrlwAABcXAgAAPTsjg
Date: Mon, 1 Apr 2019 10:08:46 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_bbcfe0a60ff742c1814229118903585fXCHRCD007ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [netmod] Meeting Notes from open YANG versioning Design Team meeting
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Apr 2019 10:08:50 -0000

I agree that the requirements for SDO models are slightly different from vendors models.  Really, I think that the SDO requirements are a subset of the vendor model requirements.

I think that a single solution should be possible here.


From: Mahesh Jethanandani <>
Sent: 29 March 2019 21:17
To: Juergen Schoenwaelder <>
Cc: Rob Wilton (rwilton) <>om>;
Subject: Re: [netmod] Meeting Notes from open YANG versioning Design Team meeting

On Mar 29, 2019, at 11:31 AM, Juergen Schoenwaelder <<>> wrote:

On Fri, Mar 29, 2019 at 10:50:52AM -0700, Mahesh Jethanandani 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.

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.

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.


Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <>

Mahesh Jethanandani<>