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

Andy Bierman <> Sun, 24 March 2019 20:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4EB161200A3 for <>; Sun, 24 Mar 2019 13:05:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yVTsEpMUBv4e for <>; Sun, 24 Mar 2019 13:05:35 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3058E12009E for <>; Sun, 24 Mar 2019 13:05:35 -0700 (PDT)
Received: by with SMTP id l7so5975619ljg.6 for <>; Sun, 24 Mar 2019 13:05:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sJAXk4gIQySt15zzZdbcGgVFY7ds2ogbzxt26H/nPuw=; b=nf2lewZhsvoHpVrIUKjOjYAqxEtXuI5wg0IMErDrMnzpzN60cNbYLLee0jh9ldZejd UDBJYGxcet3hLOi7W97UiKz0io6j4wLIv1oPl+hWq09p6YWV/+n+AxWGJ6qTTVrNQ0xV OH/8FAaCYyFePJSUo2J/2nyhDyKQGu1qkPHNsMQnxEd2pdxXwSMxoLzxNtVqJPb1+vI7 xSjGm9cozCom4eDJSHJItqFtvy7Q78wNnupFMEONjK6o3g6Svn3fblwttn9k2/O5TyYa 4pFYYvnfzOQFFVOBaPvXELdrBgp+01LlMR28J//zaFhcikRiq/njVqbXp1gOYFXcmLWq upFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sJAXk4gIQySt15zzZdbcGgVFY7ds2ogbzxt26H/nPuw=; b=ohCcsMfKmigmCN6zbhUdMhfAt9uLaEp28PAcjcl6hpjhl72K4c0odlGaQfG4649Ibs gQ6xfSJctZzuXEyo+LmEqVhABGByFOUE64plqsEbkAMMqyr+HCMXJYcRTCwGG2sOZ/TW Mh2iUC3tK4wa7UuiyIMX1Z4mrCFTzvL/YJraot+pYNV0LLIrleAnjExEiIKWcoG1CGa8 PuRIOhPieYv2X71XxFkHspa40BByGcXFryxT3FFbnlIcytLCECcopKthzNcl022kbNir Of29QeId+dIEy7j1ZYM48vUlfcyVxSwGRjp1jBOq6/+9gm5hwzPsdYFfrCOamD4XQd2E JRdg==
X-Gm-Message-State: APjAAAW3euawwNryps/csKa2C8Z36iJzbTYdaq+49WtztoKqmssoAzbP GYt5CCG/VAjKdjRxsL7e+kGnELXMyeoPDqsZKF+xDQ==
X-Google-Smtp-Source: APXvYqwa/4WXEwRHT5eRokjATU4/4yWHp966bLtErbtAo7+Y8XDu+ylr0EzfitsQLJbLXeprZyzny36kfnytahReLqc=
X-Received: by 2002:a2e:85d2:: with SMTP id h18mr10752586ljj.128.1553457933237; Sun, 24 Mar 2019 13:05:33 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Andy Bierman <>
Date: Sun, 24 Mar 2019 13:05:21 -0700
Message-ID: <>
To: Joel Jaeggli <>
Cc: Lou Berger <>, "" <>, NetMod WG <>
Content-Type: multipart/alternative; boundary="00000000000048d2020584dc9cb3"
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: Sun, 24 Mar 2019 20:05:38 -0000

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

> On Mar 22, 2019, at 12:07, Lou Berger <> wrote:
> Hi,
> 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.
> Authors,
> 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.


> _______________________________________________
> netmod mailing list