Andy Bierman <a...@yumaworks.com> wrote:
> On Sun, Mar 24, 2019 at 11:39 AM Joel Jaeggli <joe...@bogus.com> wrote:
>
> >
> >
> > On Mar 22, 2019, at 12:07, Lou Berger <lber...@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
> >
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
