[netmod] Re: AD review of draft-ietf-netmod-yang-module-versioning-13 (Document 1 of 3).

[Reshad Rahman <[e-mail]>]

 Hi Mahesh,
Thank you for the review. We (the authors) will get back to you soon on your comments.
Regards,Reshad.
    On Tuesday, August 5, 2025 at 05:46:29 PM EDT, Mahesh Jethanandani <[e-mail]> wrote:  
 
 Hi Authors,
Thanks for working on this document. It has taken a lot to get here. While this review is particularly for this draft, the two other related drafts, draft-ietf-netmod-yang-semver and draft-ietf-netmod-yang-module-filename, will be progressed along with this draft as a single cluster.
Please find enclosed some comments that hopefully go towards improving the document.
Overall Comment:
This is a comment more for Shepherd writers. The fact that a document contains a YANG module does not mean its intended status is Proposed Standard by default. Some recent documents are publishing YANG modules in other tracks, such as Experimental.
Separately, Juergen provided comments on all three related drafts. I saw responses to draft-ietf-netmod-semver (by Joe, thanks for that), and to draft-ietf-netmod-yang-module-filename (by Per, thanks for that). But I did not see anyone respond to comments for draft-ietf-netmod-yang-module-versioning. Can one of the authors respond to his comments?
"Abstract", paragraph 0>    This document refines the RFC 7950 module update rules.  It specifies>    a new YANG module update procedure that can document when non->    backwards-compatible changes have occurred during the evolution of a>    YANG module.  It extends the YANG import statement with a minimum>    revision suggestion to help document inter-module dependencies.  It>    provides guidelines for managing the lifecycle of YANG modules and>    individual schema nodes.  This document updates RFC 7950, RFC 6020,>    RFC 8407 and RFC 8525.
The document states it is updating RFC 8407. However, it also touches on the same set of updates that rfc8407bis touches upon in its Section 4.8. How do the changes described in this document jive with the changes in rfc8407bis? Can specific sections in rfc8407bis that are being updated be called out, or state what is being updated?
Section 1, paragraph 0>    The current YANG [RFC7950] module update rules require that updates>    of YANG modules preserve strict backwards compatibility.  This causes>    problems as described in [I-D.ietf-netmod-yang-versioning-reqs].>    This document recognizes the need to sometimes allow YANG modules to>    evolve with non-backwards-compatible changes, which can cause>    breakage to clients and when importing YANG modules.  Accepting that>    non-backwards-compatible changes do sometimes occur -- e.g., for>    bugfixes -- it is important to have mechanisms to report when these>    changes occur, and to manage their effect on clients and the broader>    YANG ecosystem.
I know this comment is not in particular for this document, but since the requirements document is mentioned here, what is the plan for draft-ietf-netmod-yang-versioning-reqs? Is the plan to keep it as a “live” document, with no plan to publish it? If this document is not able to address all the requirements documented there, can those unfulfilled requirements be identified?
Section 1.1, paragraph 0>    This document updates [RFC7950] section 11 and [RFC6020] section 10.>    Section 3 describes modifications to YANG revision handling and>    update rules, and Section 4.1 describes a YANG extension statement to>    describe potential YANG import revision dependencies.
RFC7950 states that extension statements can be ignored. If the YANG Semver statement were to be ignored, particularly the recommended-min-date, what would be the effect on the import of the module? Can we have some text that describes that scenario?
Section 4, paragraph 1>    [RFC7950] and [RFC6020] allow YANG module "import" statements to>    optionally require the imported module to have a specific revision>    date.  In practice, importing a module with an exact revision date>    can be too restrictive because it requires the importing module to be>    updated whenever any change to the imported module occurs, and hence>    section Section 6.1 suggests that authors do not restrict YANG module>    imports to exact revision dates.
I do not understand this paragraph.
First of all, isn't "optionally require" an oxymoron? Did you mean to say that YANG modules can optionally import modules with a specific revision date?
Secondly, isn't the whole idea of importing a module with a revision date to make sure the imported module is "frozen in time"? RFC 7950 is Section 5.1.1, says for imported modules using revision statements that "As future revisions of the imported module are published, the importing module is unaffected". Therefore, saying that "importing module to be updated whenever any changes to the imported module occurs" is not a true statement.
Section 4.1, paragraph 1>    Although the previous section indicates that the actual relationship>    constraints between different revisions of YANG modules should be>    specified outside of the modules, in some scenarios YANG modules are>    designed to be loosely coupled, and implementors may wish to select>    sets of YANG module revisions that are expected to work together.>    For these cases it can be helpful for a module author to provide>    guidance on a recommended minimum revision that is expected to>    satisfy a YANG import.  E.g., the module author may know of a>    dependency on a type or grouping that has been introduced in a>    particular imported YANG module revision.  Although there can be no>    guarantee that all derived future revisions from the particular>    imported module will necessarily also be compatible, older revisions>    of the particular imported module may not be compatible.
RFC 7950 in Section 5.1.1 says that when a module is imported without a specific version, it is undefined which revision is used. Given that, specifying an exact version helps. But if implementations always import the latest version, does specifying the minimum version help? I feel that we are not providing a complete context here.
Section 6, paragraph 0>    The following text updates section 4.7 of [RFC8407] to revise the>    guidelines for updating YANG modules.
Should the reference be updated to rfc8407bis?
Section 6.1.1, paragraph 1>    1.  The changes should be made gradually, e.g., a data node's status>        SHOULD NOT be changed directly from "current" to "obsolete" (see>        Section 4.7 of [RFC8407]), instead the status SHOULD first be>        marked "deprecated".  At some point in the future, when support>        is removed for the data node, there are two options.  The first,>        and preferred, option is to keep the data node definition in the>        model and change the status to “obsolete”. The second option is>        to simply remove the data node from the model, but this has the>        risk of breaking modules which import the modified module, and>        the removed identifier may be accidentally reused in a future>        revision.
Should the reference to RFC8407 be updated to point to rfc8407bis?
Section 8.2, paragraph 0>    The YANG module specified in this document defines a schema for data>    that is designed to be accessed via network management protocols such>    as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NETCONF layer>    is the secure transport layer, and the mandatory-to-implement secure>    transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF layer>    is HTTPS, and the mandatory-to-implement secure transport is TLS>    [RFC8446].
Please update to reflect the latest version of the template defined in rfc8407bis.
No reference entries found for these items, which were mentioned in the text:[draft-ietf-netmod-rfc6991-bis]. I think you meant [I-D.ietf-netmod-rfc6991-bis].
-------------------------------------------------------------------------------NIT-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose toaddress in some way - or ignore - as you see fit. Some were flagged byautomated tools (via https://github.com/larseggert/ietf-reviewtool) so therewill likely be some false positives. There is no need to let me know what youdid with these suggestions.
Section 3.1.1, paragraph 3>    *  YANG schema nodes with a "status" "obsolete" substatement MAY be>       removed from published modules, and the removal is classified as a>       backwards-compatible change.  In some circumstances it may be>       helpful to retain the obsolete definitions since their identifiers>       may still be referenced by other modules and to ensure that their>       identifiers are not reused with a different meaning.
s/may be helpful/MAY be helpful/?
Section 3.2, paragraph 0> 3.2.  non-backwards-compatible extension statement
s/non-backwards-compatible/Non-backwards-compatible/
Section 7, paragraph 8>         Copyright (c) 2024 IETF Trust and the persons identified as>         authors of the code.  All rights reserved.
s/2024/2025/
Section 7, paragraph 27>         Copyright (c) 2024 IETF Trust and the persons identified as>         authors of the code.  All rights reserved.
s/2024/2025/
Uncited references: [I-D.ietf-netmod-rfc6991-bis]. This will be fixed once you change the reference above.
"Table of Contents", paragraph 1>  . . . . . . 31 B.2. Changing the type of a leaf node . . . . . . . . . . . .>                                   ^^^^^^^^^If "type" is a classification term, "a" is not necessary. Use "type of". (Thephrases "kind of" and "sort of" are informal if they mean "to some extent".).
Section 3, paragraph 2> f revision B, or if revision A would have been listed had it not been removed>                                ^^^^^^^^^^^^^^^Did you mean "had been"?
Section 3, paragraph 12> introduces a method to indicate that an non-backwards-compatible (NBC) chang>                                      ^^Use "a" instead of "an" if the following word doesn't start with a vowel sound,e.g. "a sentence", "a university".
Section 3.1, paragraph 14> marking the "status" as "obsolete" is a NBC change, however removing the node>                                       ^Use "an" instead of "a" if the following word starts with a vowel sound, e.g."an article", "an hour".
Section 3.1.2, paragraph 1> ence of entries from the end (i.e., oldest entries) of the revision history. >                                     ^^^^^^A determiner may be missing.
Section 4.1.1.2, paragraph 1> n Handling February 2025 any nodes has changed to "deprecated" and whether th>                                    ^^^You should probably use "have".
Section 10.1, paragraph 20>  the old node is already set (and vice-versa). The new node could have a "whe>                                   ^^^^^^^^^^The expression "vice versa" is spelled without hyphens.
Section 10.2, paragraph 19> old list already has entries (and vice-versa). 4. When list "sessions" is no>                                   ^^^^^^^^^^The expression "vice versa" is spelled without hyphens.
Section 10.2, paragraph 25>  the old node is already set (and vice-versa). The new node could have a "whe>                                   ^^^^^^^^^^The expression "vice versa" is spelled without hyphens.
Thanks
Mahesh [e-mail]





_______________________________________________
netmod mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]