Mike Bishop 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: ---------------------------------------------------------------------- # IESG review of draft-ietf-netmod-yang-module-versioning-16 CC @MikeBishop ## 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 does not seem sustainable. This leaves servers with a binary choice -- either support all deprecated nodes indefinitely or don't disclose the implementation state of any deprecated node. Similarly, remove all obsolete nodes or don't disclose the state of any obsolete nodes. The use of deviations gives an escape hatch, but it seems like this is really not a binary at all; a server would like to indicate that it supports/doesn't support individual nodes. ### Section 5.1, paragraph 4 ``` If a server does not set the "deprecated-nodes-implemented" leaf to "true", then clients MUST NOT rely solely on the "rev:non-backwards- compatible" statements to determine whether two module revisions are backwards-compatible, and MUST also consider whether the status of any nodes have changed to "deprecated" and whether those nodes are implemented by the server. An implementation may choose to add ``` This suggests that clients must inspect the contents of all versions, in addition to the revision history and its tags. Or minimally, the old and new versions. Are clients guaranteed to have access to all arbitrary revisions? ### 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. ``` This seems like a dangerous SHOULD. Clients SHOULD accept invalid data, because it might have been valid from the server's perspective? Arguably that's always true of any invalid input. How can the client treat anything as invalid in that world? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## 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]
