Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
49 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,49 @@ | ||
NETMOD WG LC of Module Versioning and YANG Semver | ||
|
||
Key issues to resolve in the WG before continuing the WG LC process: | ||
|
||
K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not? | ||
K2) tbd | ||
|
||
Other issues raised but not "key" are below | ||
|
||
Should N5 be a "key" issue? | ||
|
||
|
||
################################### | ||
K1) Allow NBC changes in YANG 1.0 & YANG 1.1 or not? | ||
|
||
Option 1 - allow | ||
----------------- | ||
- RFC modifies 7950 to allow NBC changes | ||
- guidance that NBC changes SHOULD NOT be done | ||
- rev:non-backwards-compatible is a YANG extension | ||
- introduction in published YANG does not impact current tooling (ignored until recognized) | ||
|
||
|
||
Option 2 - do not allow | ||
------------------------- | ||
- NBC changes only allowed in a future version of YANG | ||
- TBD: YANG 1.2 vs 2.0 | ||
- Content = Module Versioning + YANG Semver + very limited YANG NEXT items | ||
- rev:non-backwards-compatible tag is a language keyword | ||
- consequence: any use of it breaks all YANG 1.0/1.1 tooling that hasn't been updated | ||
- IESG will be unable to approve any RFCs that make any changes to IETF YANG modules that don’t strictly conform to those rules | ||
- RFC6991 bis would not be allowed to change the use/meaning of ip-address (or change datetime) | ||
- date string (SEDATE) and YANG date-and-time couldn't change | ||
|
||
|
||
|
||
######################################## | ||
other issues (non-key issues): | ||
N1) File nameing (Robert Varga) | ||
N2) Default values for deprecated-nodes-implemented & obsolete-nodes-absent (Fengchong) | ||
N3) recommended-min is insufficient (soft and we need a "max") (Jurgen) | ||
N4) really need multiple revision label schemes? Collapse to just one? | ||
N5) make this work a separate "versioning scheme" (where the current 7950 rules are another versioning scheme) (Jurgen) | ||
N6) maintain import constraints outside of the modules (e.g. semver for a package only) (Jurgen) | ||
N7) should changes to import recommended-min or revision-date be NBC? (Jurgen) | ||
N8) use per-node tags instead of top level? (Jurgen) | ||
N9) do we really need _COMPATIBLE in YANG Semver? (Jurgen) | ||
N10) byte-equivalent (semantic API vs byte content of .yang file). Questions about *why* we're tackling this (Jurgen ,Robert V, Andy, Carsten, Tom) | ||
N11) |