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. # 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? ## 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? ## BTW, does this cover published modules or any flavor? # 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? # 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? ## 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. # 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? ## 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". # 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. ## The normative language in the IANA section can be avoided per the IESG statement on the matter. ---------------------------------------------------------------------- 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] To unsubscribe send an email to [email protected]
