Hi Med,
Thanks for the review. Below are responses to the DISCUSS points.
On Thursday, May 28, 2026 at 08:32:12 AM EDT, Mohamed Boucadair via
Datatracker <[email protected]> wrote:
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.
<RR> Understood, but what is different in this case is that we're clarifying
RFC8525 behaviour. Proposed text: Note, an updates tag is being used to
highlight to readers of RFC8525 of the relationship between these documents
because RFC 8525 is a core manageability specification and this document sets
the future direction of YANG versioning.
# 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?
<RR> Could we instead, add a sentence referencing RFC 9907 section 4.8 to the
list of things being referenced/updated at the beginning of section 3? We feel
that it might be helpful to keep this text together rather than splitting into
two sections, particularly because section 6 focuses on different aspects.
Thoughts?
## 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?
<RR> The guidance in this section is that the revision histories can be
removed, if they don't impact the tracking of NBC changes. The expectation is
that there shouldn't be any need for any extra documentation of removing old
revision statements that are no longer required, e.g., perhaps they are in
versions that are 5+ years old and are no longer in any shipping release. I
guess the authors could add a comment describing the removal to the latest
revision change, but we think that probably isn't needed (or the authors don't
have consensus on this point), and this should be out of scope for this
document.
## BTW, does this cover published modules or any flavor?
<RR> Published modules.
# 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?
<RR> The issue above is orthogonal to this document. The actual behaviour
would depend on how the imported data nodes are used (e.g., is it pulling a
particular version of a grouping or type) and would pick up the deprecated
status of whichever version is imported. Also, it is worth noting that you can
only "implement" a single version of a module even if you can import
definitions from multiple versions.
# 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?
<RR> The core reason is that the schema is well defined, i.e., so that the
clients can know with certainty which nodes are actually implemented by the
server. For any nodes (current or deprecated) that are not implemented then
deviation "not-supported" are a better and precise mechanism to remove nodes
that are not supported. Note that in programming languages deprecated APIs
often also means that the API is supported but not recommended, similarly in
YANG, deprecated does not in itself mean that the node is not supported.
## 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.
<RR> See above.
# 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?
<RR> The key goal/requirement here is that a particular module version/revision
is well defined to a particular schema so the guidance is for authors, and
users of the YANG modules. But as per the section headline, it is really aimed
at ensuring module authors follow this rule.
## 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".
<RR> We had some discussions and our suggestion is to remove the normative
language:
If there is a replacement data node, rpc, action or notification for
the deprecated node, then updating the description of the deprecated node
to highlight the replacement may be helpful.
FYI, note that this document aimes to tackle the replacement "issue".
# 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.
<RR> This document defines the strict rules (normative) and
I-D.ietf-netmod-iana-yang-guidance is the current guidance of how those rules
can be achieved.
## The normative language in the IANA section can be avoided per the IESG
statement on the matter.
<RR> Could you clarify which IESG statement you are referring to? We looked for
it...
Regards,Reshad.
----------------------------------------------------------------------
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]
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
