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?
"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?
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".)
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
