[netmod] Re: Mohamed Boucadair's Discuss on draft-ietf-netmod-yang-module-versioning-16: (with DISCUSS and COMMENT)

[Reshad Rahman <[e-mail]>]

 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 <[e-mail]> 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 -- [e-mail]
To unsubscribe send an email to [e-mail]