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
smime.p7s