Mike Bishop has entered the following ballot position for draft-ietf-netmod-yang-semver-26: No Objection
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-semver/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # IESG review of draft-ietf-netmod-yang-semver-26 CC @MikeBishop ## Comments ### Previous DISCUSS Thank you for the discussion about the intended uses of this; my original DISCUSS was based on a few misunderstandings. Notably, I missed this restriction: > There MUST NOT be multiple versions of a YANG artifact that have the same > MAJOR, MINOR and PATCH version numbers, but different patch modifier strings. > E.g., artifact version "1.2.3_non_compatible" MUST NOT be defined if artifact > version "1.2.3" has already been defined. ...and its implication that all versions are minted by (or at least coordinated with) the same source. While I still think that the inability to identify which version is the parent of another version will cause confusion, my preference for a different approach is not DISCUSS-worthy. ### Section 4.3, paragraph 4 "MUST only" is potentially ambiguous. Does it mean "MUST be present if COMPAT is present and MUST NOT be present otherwise? If so, consider a single optional element that MUST begin with the character '_' as a cleaner way to express this. ### Section 4.4, paragraph 12 What does one do with "can indicate" here? Either it indicates this, or it indicates many things including this. If many things, what is the scope of things it indicates? ### Section 4.4.3, paragraph 4 ``` software development. It is recommended to avoid only incrementing the PATCH digit on the main branch of YANG modules. See Appendix B Scenario 2 for an illustration and explanation. ``` This says that changes on the main branch should alter more than the PATCH number, but your example seems to argue for the exact opposite. Should this instead say "It is recommended that only the main branch of YANG modules increment the PATCH number"? Or am I misunderstanding? ### Section 5.2, paragraph 15 For the reasons stated here, I'm slightly surprised there's not a corresponding max-version, in case there's a breaking change which the current module doesn't yet support. ### Section 6.1.2.1, paragraph 1 ``` For example, if a module or submodule started out in the pre-NMDA ([RFC8342] ) world, and then had NMDA support added without removing any legacy "state" branches -- and you are looking to add additional new features -- a sensible choice for the target YANG Semver would be 1.2.0 (since 1.0.0 would have been the initial, pre-NMDA release, and 1.1.0 would have been the NMDA revision). ``` This can probably be reworded to remove the "world" terminology and the use of the second-person. ### Too many authors The document has six authors, which exceeds the recommended author limit. Has the sponsoring AD agreed that this is appropriate? ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Typos #### Section 1, paragraph 1 ``` - [I-D.ietf-netmod-yang-module-versioning] puts forth new concepts - ------------- - relating to modified rules for updating YANG modules and submodules, - ------------ ``` #### Section 1, paragraph 2 ``` - The goal being to add a human readable version identifier that - --------- ^^^^^ ^ + This adds a human-readable version identifier that + ^ + ^ ``` ### Outdated references Document references `draft-clacla-netmod-yang-model-update-06`, but `-26` is the latest available revision. ### Grammar/style #### Section 4.4.1, paragraph 1 ``` the versions could look like, from oldest version to newest: 0.1.0 - first p ^^^^^^ ``` A determiner may be missing. #### Section 4.6.2, paragraph 2 ``` s section and the IETF-specific sub-section below provide YANG Semver-specif ^^^^^^^^^^^ ``` This word is normally spelled as one. _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
