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

[Andy Bierman <[e-mail]>]

On Sun, Mar 24, 2019 at 11:39 AM Joel Jaeggli <[e-mail]> wrote:

>
>
> On Mar 22, 2019, at 12:07, Lou Berger <[e-mail]> 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";

         }


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.


Andy





>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>