Hi Reshad, A couple of comments. See inline with [mj]. Once an updated draft is posted with the agreed changes, we can proceed towards IETF LC.
> On Sep 11, 2025, at 8:44 PM, Reshad Rahman <[email protected]> wrote: > > Hi Mahesh, > > Thanks for the review and apologies for the delay. > > On Tuesday, August 5, 2025 at 05:46:14 PM EDT, Mahesh Jethanandani > <[email protected]> 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? > > > <RR> The response was @ > https://mailarchive.ietf.org/arch/msg/netmod/iiHWLodAPVwW0Ztqdap_DSZYcOg/. Or > are you referring to another review email from Juergen? > [mj] Thanks for the pointer. I see it now. > "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? > > <RR> We are updating the doc to say that it updates 8407bis. Section 4.7 is > being called out (no change there i..e that's what we called out for 8407). > > 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? > > <RR> Yes versioning-reqs is kept as live doc and will not be published. As > per initial plan, other requirements are being worked on in the other docs > (packages, schema-comparison). > > 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? > > <RR> I thought we had text covering this already but couldn't find it. The > effect is that the module is imported without taking into account the > recommended-min-date, so an undesired revision could be imported. We'll add > some text for this 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? > > <RR> Yes :-) What about this below instead? > "[RFC7950] and [RFC6020] allow YANG module "import" statements to optionally > have a revision-statement which requires the imported module to have 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. > > <RR> I agree that "whenever" is incorrect/misleading, we'll modify the text. > What we are referring to is the case where the importing module wants to use > a new type or grouping which has been added to the imported module, in that > case the importing module has to be updated to use the new revision. > > 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. > > <RR> I'm not getting the part "But if implementations always import the > latest version", are you referring to text in this document? Let's say a type > we need in an importing module was added on 2025-09-11 in an imported module. > If we put "recommended-min-date 2025-09-11", there is no guarantee that the > type we need will be present in all revisions in the future since the type > could be removed eventually. OTOH if we don't put a recommended min date and > get an older version, for sure we will not have the needed type. But I'm not > sure I understood your question... Do the examples in 4.1.1 clarify how > recommended-min-date is used? [mj] I think you explained the problem statement better than me :-). Let us take your example above. First let us take the case where a recommended-min-date is present, but the imported module has been updated (by a version greater than recommended-min-date) to remove a type. The compile will fail and the user will get an error. If the recommended-min-date is removed, the user will still get the same error, by virtue of it importing the latest version of the module. The added statement therefore does not help. Now let us take the second case when a recommended-min-date is specified and the importing module has access only to an older version of the imported module. The compile will fail. If the recommended-min-date is removed, the compile will still fail.The only difference will be with the statement present you will know which (min) version of the imported module needs to be present for the compile to succeed. The difference between the recommended-min-date and an exact version that RFC 7950 specifies is that the first case is taken care of, meaning if a later version of the imported module removes a given type it does not affect the importing module. The impact to the second case is the same whether the statement is present or not. I am, therefore, questioning the usefullness of the statement. > > 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? > > <RR> Yes (as stated above). > > 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? > <RR> Yes (as stated above). > > > 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. > <RR> Ack, will do. > > Regards, > Reshad. > > P.S: I'll resopnd to the nits only if I disagree with your suggestions or > have something to discuss. > > 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 > 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. > > 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". (The > phrases "kind of" and "sort of" are informal if they mean "to some extent".) Mahesh Jethanandani [email protected]
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
