Hi Reshad, The changes in -17 adequately address my comments. Much appreciated.
Cheers, Med De : Reshad Rahman <[email protected]> Envoyé : mardi 30 juin 2026 05:06 À : The IESG <[email protected]>; BOUCADAIR Mohamed INNOV/NET <[email protected]> Cc : [email protected]; [email protected]; [email protected] Objet : Re: [netmod] Re: Mohamed Boucadair's Discuss on draft-ietf-netmod-yang-module-versioning-16: (with DISCUSS and COMMENT) Hi Med, I believe we have addressed your DISCUSS and COMMENTS as per offline discussions, please see new revision below. Regards, Reshad (on behalf of the authors). A new version of Internet-Draft draft-ietf-netmod-yang-module-versioning-17.txt has been successfully submitted by Reshad Rahman and posted to the IETF repository. Name: draft-ietf-netmod-yang-module-versioning Revision: 17 Title: Updated YANG Module Revision Handling Date: 2026-06-29 Group: netmod Pages: 40 URL: https://www.ietf.org/archive/id/draft-ietf-netmod-yang-module-versioning-17.txt Status: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/ HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-netmod-yang-module-versioning-17 On Tuesday, June 2, 2026 at 11:07:54 PM EDT, Reshad Rahman <[email protected]<mailto:[email protected]>> wrote: Hi Med, Thanks for the review. Below are responses to the DISCUSS points. On Thursday, May 28, 2026 at 08:32:12 AM EDT, Mohamed Boucadair via Datatracker <[email protected]<mailto:[email protected]>> wrote: Mohamed Boucadair 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: ---------------------------------------------------------------------- Hi Rob, Reshad, Balázs, Joe, and Jason, Thank you for the effort put into this important piece. I will be definitely balloting YES. I have some few points to discuss. Comments are listed following the order in the document, not their importance. # Augmentation and Update CURRENT: This document updates [RFC8525] with augmentations to include two boolean leafs to indicate whether status deprecated and status obsolete schema nodes are implemented by the server. We don't usually update specs with augmented module. Please consider adding some text to explain what is special here. <RR> Understood, but what is different in this case is that we're clarifying RFC8525 behaviour. Proposed text: Note, an updates tag is being used to highlight to readers of RFC8525 of the relationship between these documents because RFC 8525 is a core manageability specification and this document sets the future direction of YANG versioning. # Authors Guidelines vs Specification Section 3 is more about refinement of rules in [RFC7950] and [RFC6020], however there are parts that are move guidance to authors, which fall under 9907 updates. An example of such text is the following: CURENT: Removing revision statements is allowed, but can cause issues and SHOULD NOT be done without careful analysis of the potential impact to users of the module or submodule since it may cause loss of visibility of when non-backwards-compatible changes were introduced. ## Wouldn't be cleaner to move such parts to be under the section with 9907 updates? <RR> Could we instead, add a sentence referencing RFC 9907 section 4.8 to the list of things being referenced/updated at the beginning of section 3? We feel that it might be helpful to keep this text together rather than splitting into two sections, particularly because section 6 focuses on different aspects. Thoughts? ## The text is more about what can be considered, but there is no guidance/reco on how/whether the outcome of that analysis is recorded in the module/document itself. Can we add some guidance? <RR> The guidance in this section is that the revision histories can be removed, if they don't impact the tracking of NBC changes. The expectation is that there shouldn't be any need for any extra documentation of removing old revision statements that are no longer required, e.g., perhaps they are in versions that are 5+ years old and are no longer in any shipping release. I guess the authors could add a comment describing the removal to the latest revision change, but we think that probably isn't needed (or the authors don't have consensus on this point), and this should be out of scope for this document. ## BTW, does this cover published modules or any flavor? <RR> Published modules. # Multiple versions of the same module CURRENT: If a "recommended-min-date" extension statement is ignored by a YANG parser, the import statement is processed according to the rules documented in Section 7.1.5 of [RFC7950]. Per 7950, "Multiple revisions of the same module can be imported, provided that different prefixes are used". This would allow in theory authors to pick from revisions of the same modules but with distinct deprecation status. Do we need to say anything about mixing versions that deprecate vs. not deprecate a given data node? <RR> The issue above is orthogonal to this document. The actual behaviour would depend on how the imported data nodes are used (e.g., is it pulling a particular version of a grouping or type) and would pick up the deprecated status of whichever version is imported. Also, it is worth noting that you can only "implement" a single version of a module even if you can import definitions from multiple versions. # Missing Rationale CURRENT: Servers SHOULD set both the "deprecated-nodes-implemented" and "obsolete-nodes-absent" leafs to "true", which allows clients to determine the exact schema used by the server. ## I don't understand what is the reasoning of this reco? Why are we asking an implem to still support data nodes? <RR> The core reason is that the schema is well defined, i.e., so that the clients can know with certainty which nodes are actually implemented by the server. For any nodes (current or deprecated) that are not implemented then deviation "not-supported" are a better and precise mechanism to remove nodes that are not supported. Note that in programming languages deprecated APIs often also means that the API is supported but not recommended, similarly in YANG, deprecated does not in itself mean that the node is not supported. ## How setting these Boolean helps know "the exact schema used by the server". A server may have partial support of those. These nodes are not helpful for that. <RR> See above. # Incomplete Guidance CURRENT: A module that includes submodules SHOULD use the "revision-date" statement to include specific submodule revisions. The revision of the including module MUST be updated when any included submodule has changed. ## Who is the target of the last part of this guidance? <RR> The key goal/requirement here is that a particular module version/revision is well defined to a particular schema so the guidance is for authors, and users of the YANG modules. But as per the section headline, it is really aimed at ensuring module authors follow this rule. ## How that update is supposed to work? # I would strengthen the guidance to MUST for this part: CURRENT: If there is a replacement data node, rpc, action or notification for the deprecated node, this SHOULD be stated in the "description". <RR> We had some discussions and our suggestion is to remove the normative language: If there is a replacement data node, rpc, action or notification for the deprecated node, then updating the description of the deprecated node to highlight the replacement may be helpful. FYI, note that this document<https://datatracker.ietf.org/doc/draft-rtv-netmod-yang-subtree-replacement/> aimes to tackle the replacement "issue". # IANA-maintained modules CURRENT: In all cases, IANA MUST follow the versioning guidance specified in Section 3.1, and MUST include a "rev:non-backwards-compatible" substatement to the latest revision statement whenever an IANA maintained module is updated in a non-backwards-compatible way, as described in Section 3.2. ## I don't see how these MUSTs can be done by IANA without expert assistance. This guidance smells like adding Expert Review to all registries that are represented with a YANG module. ## I guess some of the answers are in: CURRENT: See [I-D.ietf-netmod-iana-yang-guidance] for complete guidance on how to handle versioning for IANA maintained YANG modules. However, I-D.ietf-netmod-iana-yang-guidance is only listed as Informative. If the full guidance is what is recorded in that draft, then I-D.ietf-netmod-iana-yang-guidance has to be normative. <RR> This document defines the strict rules (normative) and I-D.ietf-netmod-iana-yang-guidance is the current guidance of how those rules can be achieved. ## The normative language in the IANA section can be avoided per the IESG statement on the matter. <RR> Could you clarify which IESG statement you are referring to? We looked for it... Regards, Reshad. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Applicability I suggest to add a statement early in the document about the target modules (is it published, unpublished, IETF modules, IANA-maintained, etc.). # The lifecycle model in 4.7 of 9907 (also updated here) can also be relaxed when there are no known implem/deploymnents. Can we include a I have seen bis doc fixing those. Relax rule is needed. # RFC 8407 CURRENT: Network Working Group R. Wilton, Ed. Internet-Draft Cisco Systems, Inc. Updates: 6020, 7950, 8407, 8525 (if approved) R. Rahman, Ed. Intended status: Standards Track Equinix Expires: 23 October 2026 B. Lengyel, Ed. ... This document updates RFC 7950, RFC 6020, RFC 8407 and RFC 8525. Please update to RFC9907. # Ambiguous "suggestion" CURRENT: It extends the YANG import statement with a minimum revision suggestion to help document inter-module dependencies. ^^^^^^^^^^^^^^^^^^^^ I don't know how to interpret the highlighted text. # Won't age well OLD: The current YANG [RFC7950] module update rules require that updates of YANG modules preserve strict backwards compatibility. NEW: The YANG module update rules per [RFC7950] require that updates of YANG modules preserve strict backwards compatibility. # (nit) YANG 1.0 OLD: Refinements to the YANG 1 and YANG 1.1 module revision update NEW: Refinements to the YANG 1.0 and YANG 1.1 module revision update # Stale text: CURRENT: 1.2. Editorial Note (To be removed by RFC Editor) Note to the RFC Editor: This section is to be removed prior to publication. This document updates [I-D.ietf-netmod-rfc8407bis]. The header metadata for this document should be updated to the new RFC number when [I-D.ietf-netmod-rfc8407bis] is published. Please delete. # Terminology Consider add to the list RFC 9907 as we are using terms "IANA-maintained YANG module", "published", etc. that are defined there. # Helps readers CURRENT: or if revision A would have been listed had it not been removed (see Section 3.3). Can you please consider rewording as I had difficulty to parse this. Thanks. # nit OLD: A module's name and revision date identifies a specific NEW: A module's name and revision date identify a specific # Section 3.1.1 CURRENT: * A "status" "deprecated" statement MAY be added, or changed from "current" to "deprecated", but adding or changing "status" to "obsolete" is a non-backwards-compatible change. As there other rules in 9907 for such status transition, especially this part: "The status SHOULD NOT be changed from "current" directly to "obsolete". An object SHOULD be available for at least one year after the publication date with a "deprecated" status before it is changed to "obsolete"." I suggest to update the above bullet to emphasis that such status changes should also be done per the guidance in 9907 and update behavior in Section 6. # Section 4 CURRENT: Instead, for conformance purposes (section 5.6 of [RFC7950]), the recommended approach for defining the relationship between specific YANG module revisions is to specify the relationships outside of the YANG modules, Should s/recommended/RECOMMENDED to better highlight the guidance? # Section 4.1 CURRENT: This module introduces, primarily for modules with a linear revision history that are versioned using revision dates, Not sure what we meant by "This module" here. Please reword to make that explicit. # RFC 9907 Guidance and template ## Example prefix CURRENT: prefix "prefix-name"; GUIDANCE: For convenience, prefix values of example modules SHOULD be prefixed with "ex" or similar patterns. ## Update TLP to 2026 for all modules ## Module template OLD: This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices. NEW: All revisions of IETF and IANA published modules can be found at the YANG Parameters registry group (https://www.iana.org/assignments/yang-parameters). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; ## Sec cons OLD: This section uses the template described in Section 3.7 of [I-D.ietf-netmod-rfc8407bis]. NEW: This section uses the template described in Section 3.7.1 of [RFC9907]. ## IANA Registrations Please add for both registrations: Maintained by IANA? N # RFC 9911 CURRENT: The argument to the "recommended-min-date" extension statement is a revision date which uses the "date-no-zone" type defined in [I-D.ietf-netmod-rfc6991-bis]. And "RFC YYYY-draft-ietf-netmod-rfc6991-bis: Common YANG Data Types"; } # Default values Shouldn't a default false statement be better here rather than having this in the description or by normative text? CURRENT: deprecated-nodes-implemented: If set to "true", this leaf indicates that all schema nodes with a status "deprecated" are implemented equivalently as if they had status "current"; otherwise deviations MUST be used by the server to explicitly remove "deprecated" nodes from the schema. If this leaf is set to "false" or absent, then the behavior is unspecified. obsolete-nodes-absent: If set to "true", this leaf indicates that the server does not implement any status "obsolete" schema nodes. If this leaf is set to "false" or absent, then the behaviour is unspecified. ... type boolean; description "If set to true, this leaf indicates that all schema nodes with a status 'deprecated' are implemented equivalently as if they had status 'current'; otherwise deviations MUST be used to explicitly remove deprecated nodes from the schema. If this leaf is absent or set to false, then the behavior is unspecified."; .. leaf obsolete-nodes-absent { type boolean; description "If set to true, this leaf indicates that the server does not implement any status 'obsolete' schema nodes. If this leaf is absent or set to false, then the behaviour is unspecified."; # Please add an Operational Considerations Section I suggest to add at least some text to basically encourage authors to details the OPS impacts of changes. # References Please move the following entries from Normative to Informative [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>. [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>. [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>. # nits * s/and hence section Section 6.1/and hence Section 6.1 * s/consumers of YANG models/ consumers of YANG data models * s/The author/Authors * s/an author/Authors * s/New ietf-yang-library-status YANG module/The "ietf-yang-library-status" YANG module Cheers, Med _______________________________________________ netmod mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> _______________________________________________ netmod mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
