Christopher Inacio has entered the following ballot position for draft-ietf-netmod-yang-module-versioning-16: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thank you to the editors/authors for the very interesting versioning document. It exposes, yet again, how hard versioning is. (Just a quick note on the comments themselves, the `####` indicate the section of the document for the comment(s); it makes a lot more sense in my markdown tool that I use to write the notes during review.) #### 4.4 In section 4.4 that `_COMPAT` tag, once applied cannot be removed. But there is not clause refining that statement; I believe this is the pertinent line in the draft text: ``` The modifier can change from "_compatible" to "_non_compatible" in a subsequent version, but the modifier MUST NOT change from "_non_compatible" to "_compatible" and MUST NOT be removed. ``` Does this mean that if I have version `2.3.2_compatible` that I release 3.0, that it has to be `3.0.0_compatible`? Does that make sense? Or by virtue of understanding the major release number in SemVer (and YANG Semver) that 3.0 is incompatible, and therefore it must be `3.0.0_non_compatible`? I’m not sure if that is what is intended. (this could possibly be related to defining the different components of the version number as “Major Version”, for example, but talking about compatible/non-compatible in terms of “revision”. This text, which I believe isn’t sufficiently clear, doesn’t align with the example given in 4.4.2. #### 4.4.2 * why doesn’t version ‘0.2.0’ have a `_non_compatible` suffix attached? Does that not violate 4.4? * Also, I see no reason the rule as stated in 4.4 with regards to ‘_COMPAT’ would not compel ‘1.0.0’ to have ‘_non_compatible’ attached; even though I expect this is not what is intended. #### 4.5 * Rule 2: Can you clarify what the “backward-compatible” means and against what it should be measured for this rule? (Major revison? This means you have taken away a functionality present in X.0.0? (renamed, removed, etc.)) * Rule 4: This conflicts with the `MUST` in 4.4 - please resolve. * I don’t know what this statement means, but it includes a ‘MUST’: ``` If a revision entry in a module's revision history includes the "rev:non-backwards-compatible" statement then that MUST be reflected in any YANG semantic version associated with that revision. ``` reflected how? With a ‘_COMPAT’ statement? But only for changes that aren’t MAJOR Version? #### 6.1.2.1 Who is the target of the “MUST” to retroactively apply YANG Semver to existing modules? That’s not a process or protocol MUST, but an IANA MUST? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to Joel H. for the GENART review. Thanks to Lou B. for the shepherd write up, it was insightful for the WG discussions. #### 4.4.2 * I will note that in 4.4.2 you use `NBC` and `BC`. NBC *is* defined in the Introduction as “non-backwards-compatible (NBC)”; there is no such definition of BC, which I would presume is “backwards-compatible”. Might be good if the the reader didn’t have to presume. * This example produces a good example of a question that I’ve been having: what information does `_compatible` convey? It patch version is assumed to be compatible unless marked `_non_compatible` right? I don’t believe it conveys any additional information in the naming of a release. #### 4.4.3 * This section should get mentioned in the definition of ‘_COMPAT’ in 4.4. e.g. ``` The _COMPAT modifier applies to versions within a MAJOR Version and indicates that a release in X.Y.Z marked with ‘_non_compatible’ indicates that the release is incompatible with first release of X, notionaly X.0.0. At every MAJOR release, the '_COMPAT' modifier MUST be removed.``` * Is my understanding of what this section indicates as the following correct? ``` Because of branching and its limitations to express compatibility, fundamentally, any release in X.?.? will have all capabilities and interfaces from X.0.0; but incompatibilities may still exist between available compatibilities in X.a.? and X.b.? where 'a' and 'b' may have different functional *additions* to X.0.0. ``` #### 4.5 * What are the exceptions to the ‘SHOULD’ in rule 1? * Why are there *5* rules in a section desribing the *four* rules? Maybe rule 5 should be a statement before the 4 rules? #### 4.6 * I don’t entirely know how to read the example (also, not a YANG expert) but I will note that it appears to me to document the future. It is version 1.1, but knows that 1.2.2 will be incompatible. #### 5.2 Rules 1 & 2 aren’t needed are they? Also, specifying X.Y.Z with Z being anything other than ‘0’ is also pointless because of rule 3, right? Unless those rules rules, as listed, are in priority order. _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
