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

Martin Bjorklund <mbj@tail-f.com> Sun, 24 March 2019 20:56 UTC

Return-Path: <mbj@tail-f.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 F21D31200F5; Sun, 24 Mar 2019 13:56:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 PbRL3r8F-Ykv; Sun, 24 Mar 2019 13:56:38 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 95CA41200F1; Sun, 24 Mar 2019 13:56:38 -0700 (PDT)
Received: from localhost (dhcp-9104.meeting.ietf.org [31.133.145.4]) by mail.tail-f.com (Postfix) with ESMTPSA id 81E411AE034E; Sun, 24 Mar 2019 21:56:37 +0100 (CET)
Date: Sun, 24 Mar 2019 21:56:35 +0100
Message-Id: <20190324.215635.272162695612319338.mbj@tail-f.com>
To: andy@yumaworks.com
Cc: joelja@bogus.com, netmod@ietf.org, netmod-ver-dt@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <CABCOCHSdakF3vACfwPMi4sq60+ndDxTrOyeqTjRpTYSQrUdzoA@mail.gmail.com>
References: <491b2abc-90ee-90d0-6672-ffff796e14d9@labn.net> <E4480DFE-2051-4C7F-A092-5B31AA15DA80@bogus.com> <CABCOCHSdakF3vACfwPMi4sq60+ndDxTrOyeqTjRpTYSQrUdzoA@mail.gmail.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/7NH-fVlH6spZOlTRmGcIoFELhqg>
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02
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: Sun, 24 Mar 2019 20:56:41 -0000

Andy Bierman <andy@yumaworks.com> wrote:
> On Sun, Mar 24, 2019 at 11:39 AM Joel Jaeggli <joelja@bogus.com> wrote:
> 
> >
> >
> > On Mar 22, 2019, at 12:07, Lou Berger <lberger@labn.net> 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";
>            semver:nbc-change;
> 
>          }
> 
> then later, a legal change
> 
>         revision 2019-03-10 {
>            description "Added leaf baz-64";
>            semver:module-version "1.3.3";
> 
>          }

+1  I have suggested something similar.

> This is a form of an inline deviation-stmt.
> The YANG update rules are not changing. They are just not being followed.

Right!

> The NBC info belongs in the revision-stmt, not overloading the version string.

Agreed.


> Not every major revision will mean NBC changes anyway.





/martin



> 
> 
> Andy
> 
> 
> 
> 
> 
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >