Hi Mike, Thanks for your review. I've put some comments inline ...
Begin forwarded message: From: Mike Bishop via Datatracker <[email protected]> Subject: Mike Bishop's Discuss on draft-ietf-netmod-yang-module-versioning-16: (with DISCUSS and COMMENT) Date: 1 June 2026 at 20:00:11 BST To: "The IESG" <[email protected]> Cc: [email protected], [email protected], [email protected], [email protected] Resent-From: <[email protected]> Resent-To: [email protected], [email protected], [email protected], [email protected], [email protected] Reply-To: Mike Bishop <[email protected]> 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. RW: The key issue that we are trying address here is to ensure that the client can determine exactly what the schema is for the device. This is particularly important with YANG that has a strict conformance/validation across the configuration. I.e., there are cases where it is important to know whether or not a leaf is supported or not because it could change the meaning of some other constraint, e.g., a "must" or "when" YANG statement. Deviations are the right and best way to advertise conformance on a per leaf basis. Effectively this change is allowing server to move from a somewhat vague definition of their schema to a very explicit and precisely defined schema. ### 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? RW: If a server doesn't set these leaves these nothing changes, you are with the status quo of today's existing behaviour. I.e., the goal of these leaves is to make an improvement in a backwards-compatible opt-in way, although it seems plausible that the next version of YANG will enforce these rules more strictly. To answer your question, no, it is not guaranteed that all intermediate revisions of the modules are accessible, but you don't need them, you only need to compare the old and new versions of the schema to determine what has changed between the two. ### 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? RW: This really ties back to RFC 8342 section 5.3, paragraphs 6 to 8. The main issue is that operational data returned from real routers is often only eventually consistent. E.g., you may be returning large numbers of FIB entries across multiple line cards, which each have their own databases and at a given point of time are not guaranteed to be consistent with each other. So, if you receive operational data that is inconsistent then it is better to process that data in a best effort fashion rather than discarding the entire message because one inconsistency bit of data was detected. This is also a bit like the IETF robustness principal (whether you agree with it or not) about being strict in what you send, but forgiving in what you receive ... but the real crux here is that the operational data in running systems is best thought of being loosely coupled and eventually consistent unlike the configuration of the devices which adopts very strict consistency semantics. ---------------------------------------------------------------------- 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. RW: Really because this is a recommendation rather than strict compliance. Ultimately we think that declaring relationships between YANG module versions is best handled separately outside the modules themselves, e.g., via YANG packages, https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-packages/07/. RW: The main use case for this is if a new type has been introduced that you can label the dependency so that others using that module know which minimum version they likely need. ### 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. RW: By clients, we mean those consuming the YANG modules to send in configuration or consume operational data. Basically, someone needs to track that these things are changing and take appropriate action. ### 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. RW: I think that we will help them achieve this, perhaps by scripting it, but there are not that many IANA maintained YANG modules and they don't tend to change that much. There is also https://datatracker.ietf.org/doc/html/draft-ietf-netmod-iana-yang-guidance-01 that will help them going forwards. We'll also check/address your nits. Thanks again for your review. Kind regards, Rob ## 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]
