Re: [netmod] adoption poll for yang-versioning-reqs-02

Balázs Lengyel <> Mon, 25 March 2019 11:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A12FD1203B9; Mon, 25 Mar 2019 04:22:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.299
X-Spam-Status: No, score=-0.299 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, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Cs7s_yWPAve7; Mon, 25 Mar 2019 04:22:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5F99B120390; Mon, 25 Mar 2019 04:22:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AHeNbEgbbUhkOgOvdgzF1k8hikHpEcEq2WLHsyEYeFk=; b=JD9fJyJBD9mgVXQuxSYdRUv14kfOctZNRvhH4WR6vixpmtnwlvfMazHmFpYDeCEGypk3TRtfJhbhFFbW55V70nTRfvm+YYZ2vAjOv5dSpTMcTXHCuLUCkRLhFt0uo2CtWR5OTFc1b+GXJr/XSU5OHpJ2O3ChMoVPNbeOmj4J9dc=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.13; Mon, 25 Mar 2019 11:22:28 +0000
Received: from ([fe80::39a5:6b6d:a86f:721c]) by ([fe80::39a5:6b6d:a86f:721c%2]) with mapi id 15.20.1730.013; Mon, 25 Mar 2019 11:22:28 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= <>
To: Andy Bierman <>, Joel Jaeggli <>
CC: NetMod WG <>, "" <>
Thread-Topic: [netmod] adoption poll for yang-versioning-reqs-02
Thread-Index: AQHU4v0HhsWz4a2SB0O3/IV6GxqqIA==
Date: Mon, 25 Mar 2019 11:22:28 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: [2001:67c:1232:144:90ab:af5c:5e62:e8f6]
user-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.0
x-clientproxiedby: (2603:10a6:20b:56::14) To (2603:10a6:209:31::16)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 15f772b2-db93-4bc6-c740-08d6b11429de
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(49563074)(7193020); SRVR:AM6PR07MB5431;
x-ms-traffictypediagnostic: AM6PR07MB5431:
authentication-results: spf=none (sender IP is );
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 0987ACA2E2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(366004)(136003)(376002)(346002)(199004)(189003)(8936002)(25786009)(58126008)(486006)(54906003)(86362001)(6512007)(110136005)(54896002)(8676002)(5070765005)(81156014)(6506007)(81166006)(64126003)(236005)(31696002)(316002)(11346002)(46003)(106356001)(446003)(478600001)(2616005)(85202003)(6246003)(99286004)(14454004)(105586002)(93886005)(7736002)(99936001)(476003)(53936002)(2906002)(186003)(85182001)(229853002)(6116002)(65956001)(65826007)(65806001)(52116002)(6486002)(14444005)(256004)(31686004)(68736007)(5660300002)(4326008)(36756003)(97736004)(71200400001)(71190400001)(6436002)(102836004)(76176011)(386003)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR07MB5431;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: hRKJbIe9tRSbc5u2P4Fs7drByJo/VO6WhOLSRFXCwCIoCiCgwIPy5UxyY8Z3D+xnQIQ4lvjdSbAu1Mk8eg/Oz/YFyC0B9npKwBZuxOBgBimEATckX9ZZ7QjRQmgiRw+tFkIATBLfEQEkBC/DFEan/NvC9hMIIuY/XXXFJKBAMAmXLnVCIfRj/1wcd1LIMzZAT68pLW5efcTGlhS7PGMLKTnbxxW+dYG+fiW8e2IlNINA8HA0p/lET4LcLY+khkiwr3YmEIVVYBtnSDHJk69vs2ar0fP7OfrZgrHcbUlJj0GfhjVMdWeMGZ3dg0a0wuFbCmYqgGdqFlHUvQZy12EpXMaPQAE/avp0t6CVFNvs6tazyZU3qcxpXmfjk8beN6OyBRvErPfhQKWvMnWd3Kj0uP9LqiNy7SpfF/pNw4jwTB0=
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060400030400000509090502"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 15f772b2-db93-4bc6-c740-08d6b11429de
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2019 11:22:28.2574 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5431
Archived-At: <>
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02
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, 25 Mar 2019 11:22:34 -0000

On 2019. 03. 24. 21:05, Andy Bierman wrote:

On Sun, Mar 24, 2019 at 11:39 AM Joel Jaeggli <> wrote:

On Mar 22, 2019, at 12:07, Lou Berger <> wrote:


Thank you all for the good input on this thread.

With the understanding that a 00 working group document is a starting point for the working group rather than a document that is ready for last call - we believe there is sufficient support to adopt this document as a starting point for the requirements we wish to address on this topic.

It is clear that there is still work to be done on this document before we can declare consensus on it and, not surprisingly, that there is more work to be done on the solution.


Please resubmit this document as draft-ietf-netmod-yang-revision-reqs-00 with the only change being the name and publication date.  The -01 version should focus on resolving issues raised during adoption.  Of course the document is subject to normal WG input and processing.

Please note the 'file' name change -this is to indicate that the requirements are not presupposing a specific solution. It is also consistent with how versioning is defined within the document currently.

Note: we would like to try to continue the list discussion in next week's session and ask the Authors/DT to summarize issues raised during the adoption call and lead a discussion to help resolve these issues.

I think this meeting is great opportunity to decide what steps need to be taken to advance the document within the working group.

Martin specifically objects to the presence of of Non-Backward-Compatible changes. 

Many modules outside the IETF are already incompatible with roc 7950 yang 1.1 revision rules. So that cat may be out of the bag at least with respect to the real world. the question remains what to do about that?

I do not look at the problem as allowing NBC so much as making it clear to toolmakers what is going on,
like a deviation to the versioning rules.

BTW, I do not support adoption of the requirements document at all.
I support the work on versioning as part of the charter, and I am happy to
accept the design team solution draft as the starting point, and just work on a solution.

But I think the solution is a bit flawed.

1) extensions are optional and problematic since they can be revisioned without changing
    the language version; the solution needs to use new YANG 1.2 statements instead of extensions

2) the version string does not have to contain all the NBC semantics.
The solution draft does not show modified semver.
It should be done differently than overloading the version string;

Let's say a fork is done on 1..3.0.
         revision 2017-07-30 {
           description "Added leaf foo-64";
           semver:module-version "1.3.0";
start with a legal change, just not at the HEAD
         revision 2019-01-10 {
           description "Added leaf bar-64";
           semver:module-version "1.3.1";

then later, an NBC change
        revision 2019-02-10 {
           description "Changed leaf bar-64 default-stmt";
           semver:module-version "1.3.2";
then later, a legal change
        revision 2019-03-10 {
           description "Added leaf baz-64";
           semver:module-version "1.3.3";
This is a form of an inline deviation-stmt.
The YANG update rules are not changing. They are just not being followed.
The NBC info belongs in the revision-stmt, not overloading the version string.
Not every major revision will mean NBC changes anyway.
BALAZS: This would not work. Lets say we have 3 versions of a model 1, 2 and 3.
Between 1->2 there is an NB C change (non-backward compatible.
Between 2->3 there is a BC change.

We have a server that only implements ver-3. As the last change was backward compatible ver-3 does not contain semver:nbc-change;
So if the client-A used ver-2 previously it will get the correct information: change is BC
However if the client-B used ver-1 previously it will get INCORRECT information.

If you say that the semver:nbc-change;is sticky and ver-3 contains semver:nbc-change; client-A gets wrong information, it believes the change is NBC while it was BC.

The problem is that the server does not know which is the "previous" model version for the client, and backwards compatibility info is needed between the two model-versions the client is using.

If we connect compatibility to the version number as we propose this problem is solved.

regards Balazs

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