Mike Bishop has entered the following ballot position for draft-ietf-netmod-yang-module-versioning-16: 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-module-versioning/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## Previous DISCUSS Thank you for following up over e-mail. I'm summarizing what I understand the resolution to be here: ## Discuss ### Section 5.1, paragraph 1 ``` The ietf-yang-library-status YANG module augments YANG library with two boolean leafs to allow a server to report how it implements status "deprecated" and status "obsolete" schema nodes. The leafs are: ``` This text is intended to increase client certainty, rather than muddy the waters. If servers indicate that deprecated nodes are supported in general, they will also need to explicitly indicate (through deviations) nodes that it does not support. Servers that indicate they do not generally support obsolete schema nodes could still do so for certain nodes. ### Section 5.1, paragraph 4 Clients will need access to both module versions they're comparing, but don't need to know anything about intervening versions to make this comparison. ### Section 6.2, paragraph 2 ``` * Clients SHOULD be liberal when processing data received from a server. For example, the server may have increased the range of an operational node causing the client to receive a value which is outside the range of the YANG model revision it was coded against. ``` I'm still very cautious about this text. The argument given is "eventual consistency," which is to say that there may be disagreement between data indicated in various nodes or from various sources due to differences in perspective. However, that's a different beast from tolerating values which are invalid per the schema of the module. At a minimum, I'd like there to be some improved text focusing the scope of this. If a server is using a schema which is not backwards-compatible to the version the client is using, it might expect the possibility for changes in ranges, etc., etc. Clients need to exercise particular caution about buffer overruns, etc. ## Comments ### Section 4.1, paragraph 7 ``` Adding, modifying or removing a "recommended-min-date" extension statement is a BC change. ``` Is this because compliance is optional? Otherwise, I'd think changing a minimum version on a dependency would be a potentially-breaking change; a dependent module which matched the old version would no longer match, and you don't know whether there were breaking changes between those versions. ### Section 6.2, paragraph 3 ``` * Clients SHOULD monitor changes to published YANG modules through their revision history, and use appropriate tooling to understand the specific changes between module revision. In particular, clients SHOULD NOT migrate to NBC revisions of a module without understanding any potential impact of the specific NBC changes. * Clients SHOULD plan to make changes to match published status changes. When a node's status changes from "current" to "deprecated", clients SHOULD plan to stop using that node in a timely fashion. When a node's status changes to "obsolete", clients MUST stop using that node. ``` This seems less about client behavior and more about developer behavior. The required feature on clients is an update mechanism, because changes will be necessary over time. ### Section 9.2, paragraph 5 ``` For published IANA maintained YANG modules that contain non- backwards-compatible changes between revisions, a new revision should be published with the "rev:non-backwards-compatible" substatement retrospectively added to any revisions containing non-backwards- compatible changes. ``` Has IANA confirmed it's capable of generating that list? This seems like a potentially large order. Also, presumably this is suggesting a single new revision wherein the document's revision history is modified, not making retrospective changes to the older revisions themselves. ## 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 2 ``` - if they are impacted by changes between the revisions. The - ----- ``` #### Section 1, paragraph 2 ``` - [I-D.ietf-netmod-yang-semver] document defines a YANG extension that - --------- ``` #### Section 1, paragraph 2 ``` - versioning. YANG packages [I-D.ietf-netmod-yang-packages] provides a - - ``` #### Section 3, paragraph 6 ``` - packages [I-D.ietf-netmod-yang-packages], and YANG library [RFC8525], - - - ``` #### Section 6.1.1, paragraph 2 ``` - Section 4.7 of [I-D.ietf-netmod-rfc8407bis]), instead the status - ^ ^ + Section 4.7 of [I-D.ietf-netmod-rfc8407bis]). Instead, the status + ^ ^ + ``` #### Section 6.1.1, paragraph 7 ``` - See Appendix B for examples on how NBC changes can be made. - ^ + See Appendix B for examples of how NBC changes can be made. + ^ ``` ### Section 6.1, paragraph 9 Why introduce a bulleted list of one item? This could be "For example, if a..." ### Outdated references Document references `draft-ietf-netmod-RFC8407bis`, but that has been published as `RFC9907`. Reference `[I-D.ietf-netmod-rfc6991-bis]` to `RFC6991`, which was obsoleted by `RFC9911` (this may be on purpose). Document references `draft-ietf-netmod-RFC6991-bis`, but that has been published as `RFC9911`. Document references `draft-clacla-netmod-yang-model-update-06`, but `-26` is the latest available revision. ### Grammar/style #### "a/an" NBC Is NBC pronounced "non-breaking change" or "enn-bee-cee"? This affects whether a/an is the appropriate article. Pick one and check that you're consistent throughout. #### Section 3.4, paragraph 4 ``` he importing module, and hence section Section 6.1 suggests that authors do n ^^^^^^^^^^^^^^^ ``` Possible typo: you repeated a word. #### Section 10.1, paragraph 8 ``` nd the "description" updated. This is a NBC change. B.2. Changing the type o ^ ``` #### Section 10.1, paragraph 6 ``` remental approach described in section Section 6.1.1. The examples are all f ^^^^^^^^^^^^^^^ ``` Possible typo: you repeated a word. #### "Appendix A.", paragraph 1 ``` remental approach described in section Section 6.1.1 can not be followed. Th ^^^^^^^^^^^^^^^ ``` Possible typo: you repeated a word. _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
