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