[netconf] Re: WG Last Call: draft-ietf-netconf-yang-notifications-versioning-09 (Ends 2025-12-10)

[[e-mail]]

Dear Reshad,

On behalf of the authors. Thanks a lot for the detailed review and the comments. This is much appreciated.

We merged as following: https://author-tools.ietf.org/diff?doc_1=draft-ietf-netconf-yang-notifications-versioning-10&url_2=https://raw.githubusercontent.com/network-analytics/draft-ietf-netconf-yang-notifications-versioning/refs/heads/main/draft-ietf-netconf-yang-notifications-versioning-11.txt

Below some feedback in line. Please let us know wherever we addressed your comments.

Best wishes
Thomas

From: Reshad Rahman <[e-mail]<mailto:[e-mail]>>
Sent: Sunday, November 30, 2025 9:46 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Mithun Valaphil <[e-mail]<mailto:[e-mail]>>
Subject: Re: [netconf] WG Last Call: draft-ietf-netconf-yang-notifications-versioning-09 (Ends 2025-12-10)

Be aware: This is an external email.

I support progressing this document, the requirements are clear and the document is well-written. I do have some feedback/questions on the document though.

Comments/questions
==================

- Introduction

   This specification applies to the YANG-Push configured subscriptions
   defined in Section 2.5 of [RFC8639], where a publisher is configured
   to stream notification out of band, as opposed to dynamic
   subscriptions defined in Section 2.4 of [RFC8639], where the
   subscriber can initiate and modify the subscription dynamically in-
   band.  In the latter case, the subscriber knows already all the
   subscriber YANG-related information, which it has to know in order to
   configure the subscription.
Last sentence: since "in the latter case" is for dynamic subscriptions, "configure the subscription" can be misleading/confusing. Also this paragraph states that this specification isn't needed for dynamic subscriptions, but it's not clear to me why since there could be an NBC change in the modules after a dynamic subscription is established (e..g type change or leaf removed). Or did I misunderstand this paragraph?

TG> Fully agree. We rephrased the paragraph and described the difference in applicability and usefulness between dynamic and configured subscriptions.

   Changes in the yang-library-content-id that YANG module(s) on the
   network management server of the YANG-Push publisher has/have
   changed.
So if the yang-library-content-id changes, but the module(s) which changed does not impact a particular subscription, is that subscription expected to have a subscription-modified notification with the new content-id? Consider adding some explicit text for this.

TG> Correct. It is expected that the new yang-library-content-id is being advertised in subscription-modified notifications. There has been discussions among the authors wherever a subscription specific yang-library-content-id would be useful. We opted for simplicity with minor overhead for the YANG-Push receiver where in such cases a re-discover of the YANG schema tree for such a subscription would lead to no change. It is a later discussion item wherever a subscription specific yang-library-content-id is necessary from network operators operating large scale deployments.

- Section 2

   The YANG notifications subscription OPTIONALLY can be restricted to
   the following YANG module revision for future capabilities:

   module:  Restricts the subscription to one or more YANG module names
      with revision and version together for the related streamed
      content.

   revision:  Restricts the subscription to a specific YANG module
      revision.  Example: "2014-05-08".

   version:  Restricts the subscription to the latest compatible YANG
      module semantic version referenced to.  Example: "2.0.0".

   When the NETCONF client creates or modifies the subscription using
   the RPCs establish-subscription and modify-subscription and the
   NETCONF server does not support the revision, the version or the
   combination of revision and version specified in the RPC request, the
   NETCONF server MUST return an RPC reply including an <rpc-error>
   element as defined in Section 4.3 of [RFC6241] with the error
   information populated as follows:

I don't understand the need to specify both revision and version. IMO we should allow only one of the 2 to be specified. Or explain the use case for specifying both with an example. e.g. is it because we could have multiple module versions with the same date (I thought that is not allowed)?

As for the version field, say it is set to 2.0.0 by the client, does that mean that if the publisher does not have a version which is 2.x.y, the create/modify will be rejected? Can the client provide 2.1.3 and if yes, would the behaviour be identical to 2.0.0 being provided by the client? Finally, what does "latest compatible" mean, is it based on revision-date or minor and editorial versions?

And the text below from introduction mentions "or" (not "and").
   This document extends the current YANG notifications subscription
   mechanism to allow to subscribe to a specific revision or latest YANG
   module semantic version to which the YANG module version needs to be
   backward compatible to.

TG> Good point. I assume it should be a choice between version and revision. When version is select, the defined YANG module must be backward compatible to the version specified. The rules for backward compatibility is defined in https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-module-versioning-15#section-3.1.1

Before
---
  grouping yang-push-module-version-config {
    description
      "This grouping combines the module name, the revision and
      version leaves. This grouping is to be used for
      configuration and the leaves are not mandatory.";
    leaf name {
      type yang:yang-identifier;
      description
        "This references the YANG module name.";
    }
    leaf revision {
      type rev:revision-date;
      description
        "This references the YANG module revision to be sent in the
        subscription.";
    }
    leaf version {
      type ysver:version;
      description
        "This references the YANG module semantic version to be sent
        in the subscription.";
    }
  }

After
---
  grouping yang-push-module-version-config {
    description
      "This grouping combines the module name, the revision and
      version leaves. This grouping is to be used for
      configuration and the leaves are not mandatory.";
    leaf name {
      type yang:yang-identifier;
      description
        "This references the YANG module name.";
    }
    choice revision-version {
      case revision {
        leaf revision {
          type rev:revision-date;
          description
            "This references the YANG module revision to be sent in the
            subscription.";
        }
      }
      case version {
        leaf version {
          type ysver:version;
          description
            "This references the YANG module semantic version to be sent
            in the subscription.";
        }
      }
    }
  }


- Section 3

       <module-version
         xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push-revision">
         <name>ietf-interfaces</name>
         <revision>2018-02-20</revision>
         <version>2.0.0</version>
         <yang-library-content-id>1</yang-library-content-id>
       </module-version>

TG> Thanks, corrected.

I believe this example is incorrect since yang-library-content-id is not in "module-version list". Could the authors validate all examples if it hasn't been done?

- Section 5.2 YANG Module

     identity version-unsupported {
       base sn:establish-subscription-error;
       base sn:modify-subscription-error;
       description
         "Version not supported.  This failure can be due to
         subscribing to a specific version not supported by the
         publisher.";
     }
Is it "specific version not supported" or the "specific major version not supported"?

TG> "specific version not supported". Changed text accordingly.

     grouping yang-push-module-version-config
Why are the leaf nodes not mandatory? For each module name, shouldn't we have either a revision or a version? If not, does it mean that the version/revision doesn't matter? If that's the case why provide the module name? Anyway some extra explanations may be needed.

TG> See above. Changed to a choice.

     // Event capabilities
     augment "/sysc:system-capabilities/notc:subscription-capabilities" {
       description
         "Add system level capabilities";
       leaf yang-push-module-revision-supported {
         type boolean;
         description
           "Specifies whether the publisher supports exporting
           revision and version in YANG-Push subscription state change
           notifications.";
         reference
           "RFC XXXX: Support of Versioning in YANG Notifications
           Subscription";
       }
     }
What is the need for this boolean leaf node, isn't the feature "yang-push-revision-supported" enough? Or can this boolean be false even if the feature is supported? If we keep this leaf node, consider making it conditional on the feature and adding a default value.

TG> We added if-feature "yang-push-revision-supported" condition and set to default true.


- Section 9 Security Considerations

You need to fill in that section based on 8407bis guidelines.

TG> Thanks. Is now updated accordingly.

Nits/suggestions
================

- Introduction

"the metrics are expose from." -> "the metrics are exposed from."

   When a network
   node is upgraded, the subscribed YANG module revision MAY have
   updated and might, consequently, break the data processing pipeline
MAY have been updated and might

TG> Addressed

   This document extends the current YANG notifications subscription
   mechanism to allow to subscribe to a specific revision or latest YANG
   module semantic version to which the YANG module version needs to be
   backward compatible to.
to allow subscriptions to a specific revision or latest

TG> Addressed

   Changes in the yang-library-content-id that YANG module(s) on the
   network management server of the YANG-Push publisher has/have
   changed.
Changes in yang-library-content-id indicate that YANG module(s) on the

TG> Addressed

- Section 5.2 YANG Module

   grouping yang-push-module-version-config
   grouping yang-push-module-version-config-list
I struggle with the term config in these grouping names, since this is not just for configured subscriptions.

TG> Valid point. Changed the grouping names and include "notif" or "subs" depending wherever they are used in subscription or notification.


- Author info: update info for Benoit.

TG> Addressed


Regards,
Reshad.


On Wednesday, November 19, 2025 at 06:27:53 PM CST, Mithun Valaphil via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:



Subject: WG Last Call: draft-ietf-netconf-yang-notifications-versioning-09
(Ends 2025-12-10)

This message starts a 3-week WG Last Call for this document.

Abstract:
  This document extends the YANG notifications subscription mechanism
  to specify the YANG module semantic version at the subscription.
  Then, a new extension with the revision and the semantic version of
  the YANG-Push subscription state change notification is proposed.

File can be retrieved from:
https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-notifications-versioning/

Please review and indicate your support or objection to proceed with the
publication of this document by replying to this email keeping
[e-mail]<mailto:[e-mail]> in copy. Objections should be motivated and suggestions to
resolve them are highly appreciated.

Authors, and WG participants in general, are reminded again of the
Intellectual Property Rights (IPR) disclosure obligations described in BCP 79
[1]. Appropriate IPR disclosures required for full conformance with the
provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of
any. Sanctions available for application to violators of IETF IPR Policy can
be found at [3].

Thank you.

[1] https://datatracker.ietf.org/doc/bcp78/
[2] https://datatracker.ietf.org/doc/bcp79/
[3] https://datatracker.ietf.org/doc/rfc6701/



_______________________________________________
netconf mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>