[netconf] Re: Mohamed Boucadair's Discuss on draft-ietf-netconf-adaptive-subscription-15: (with DISCUSS and COMMENT)

["maqiufang (A)" <[e-mail]>]

Hi, Med,

Thanks a lot for the thorough and careful review, much appreciated. The authors have posted -16, which addresses your comments below. Please review the diff at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-netconf-adaptive-subscription-16 and let us know if you have further comments/suggestions.

On one specific point, regarding the comment below:
# Prefix

CURRENT:
         where the prefix is the YANG module name and the namespace is
         as defined by the "namespace" statement in the YANG module.

The use of prefix is misleading here.

As an observation, the namespace is likely to include the name:

   A standard "namespace" statement value SHOULD have the following
   form:

       <URN prefix string>:<module-name>

The authors prefer to keep the current text, to be consistent with what has already been used in RFC 8639 (see the definition of leaf stream-xpath-filter)and RFC 8040 (see sec.4.8.4).
The use of "prefix" is also aligned with what we have in Xpath1.0 spec (https://www.w3.org/TR/1999/REC-xpath-19991116/) e.g., The namespace declarations consist of a mapping from prefixes to namespace URIs.


Best Regards,
Qiufang //co-author

-----Original Message-----
From: Mohamed Boucadair via Datatracker [mailto:[e-mail]] 
Sent: Thursday, April 9, 2026 6:53 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Mohamed Boucadair's Discuss on draft-ietf-netconf-adaptive-subscription-15: (with DISCUSS and COMMENT)

Mohamed Boucadair has entered the following ballot position for
draft-ietf-netconf-adaptive-subscription-15: 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-netconf-adaptive-subscription/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi Qin, Peng, Qiufang, Wei, and Zhixiong,

Thank you for the effort put into this well-written document. The Experimental
approach followed here makes sense. Thanks for the description of the
experimental goals.

Thanks to Dhruv Dhody for the two OPSDIR reviews and the authors for taking
care of the comments.

Please find below some points for DISCUSSion;

# YANG modules can be consumed out of the parent RFCs, the scope and goals may
be overlooked

I suggest we make that clear in the module itself.

OLD:
     description
       "This module extends the YANG data module defined in

NEW:
     description
       "This modules defines an experimental YANG module that extends

For the same reason, and given that abstracts are used outside of the RFC
metadata, I also suggest

OLD:
      This document defines a YANG data model and associated mechanism to

NEW:
      This document defines an experimental mechanism and its companion YANG
      data model to

As I’m there, you may consider the following in the Introduction;

OLD:
   This document defines a YANG data model and associated mechanism that

NEW:
   This document defines an experimental mechanism and its companion YANG data
   model to

# Client Considerations are missing

CURRENT:
   Adaptive Subscription:  A subscription that specifies subscription
      period update policy on the servers when the subscription is
      initialized and allows servers/publishers to automatically switch
      to different period intervals according to network condition
      changes without interacting with the client for update policy
      instructions.

What about the conditions at the client side itself? Whether it receives an
avalanche of updates, etc.? I think such considerations need to be also part of
the experimental work assessment. I suggest to update experiment goals with
such aspects.

# Server behavior and operational impact

CURRENT:
      If an "eval-interval" is not
      provided, then the "eval-interval" is set with the minimum time
      interval that the server is able to detect whenever changes to the
      targeted data node occur.

## This should be part of aspects to checked as part of assessment work: do you
expect this to be hardcoded or this depends on the resources at some point in
time (memory, cpu, etc.)?

## Given this is an important piece that would impact the behavior, the
description statement of the corresponding node in the module should include
this clarification.

# Normative References

The following should be listed as normative

   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
              the Network Configuration Protocol (NETCONF)", RFC 6020,
              DOI 10.17487/RFC6020, October 2010,
              <https://www.rfc-editor.org/info/rfc6020>.

And

   [XPATH1.0] W3C, "https://www.w3.org/TR/1999/REC-xpath-19991116/", 11
              November 1999.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Title: Match the use in existing RFCs

OLD: Adaptive Subscription to YANG Notification

NEW: Adaptive Subscription to YANG Notifications

# Introduction: update mechanism

OLD:
   It defines a mechanism (i.e., update trigger)

NEW:
   It defines a mechanism (called, update trigger)

# Please help readers find the exact section where to look at

For example, consider this change:

OLD: Two types of subscriptions are introduced in [RFC8641],

NEW: Two types of subscriptions are introduced in Section 3.1 of [RFC8641],

# Characterization

CURRENT:
   However, in some deployments involving an increased data collection
   rate or "on-change" subscription to push updates that change
   frequently,

I wonder whether we can provide some characterization here about what is seen
typically as frequently? Is that too deployment-specific?

# Prone to errors

CURRENT:
   In addition, when tens of thousands of network devices need to be
   managed, frequent follow-up modification requests are prone to
   errors.

That is not specific to this case, but more importantly, I don’t see how this
is nullified by the approach in the draft.

# Server vs. Publisher

There are several occurrences where servers/publishers constructs such in the
following are used:

CURRENT:
   Servers can be
   configured with multiple different period intervals and corresponding
   period update conditions which allow servers/publishers

Why not simply using “publisher” through the document?

# Missing terminology

CURRENT:
   The following terms are defined in [RFC5277], [RFC7950], [RFC8342],
   [RFC8639], [RFC8641] and are not redefined here:

I would add datastore node, Update trigger, and Update record to that list.

# Expected or Encouraged?

CURRENT:
   It is expected that parties participating
   in this experiment will publish experimental results within one year
   of the publication of this document.

## Given the one year period, should this be “encouraged” instead?

## What if nothing happens in one year? Is that a sign of lack of
interest/failure?

# Scales need to be shared as well to ease comparison and reproducibility

OLD:
   *  Scalability across diverse network scales.

NEW:
   *  Scalability across diverse network scales and a description of these
   network scales.

# I would also add an item to basically say that one outcome would be to also
tweak the operational consideraions based on the experiment findings.

# Is this really needed?

CURRENT:
   Feedback garnered from deployments will be crucial in determining
   whether this specification merits progression from Experimental to
   the IETF Standards Track.

I would delete.

# Prefix

CURRENT:
         where the prefix is the YANG module name and the namespace is
         as defined by the "namespace" statement in the YANG module.

The use of prefix is misleading here.

As an observation, the namespace is likely to include the name:

   A standard "namespace" statement value SHOULD have the following
   form:

       <URN prefix string>:<module-name>

# Muxing error cases is not great for operations

CURRENT:
   The "xpath-evaluation-unsupported" RPC error is used to indicate that
   a server failed to parse syntax defined in "eval-expression".  The
   failure can be caused by either a syntax error or some XPath 1.0

Muxing both would make troubleshooting more complex. Why not defining separate
errors?

# On Data models, module, data module

Please check the guidance in  RFC9907, specifically this part:

   Even if a YANG data model is structured as a single YANG module, the
   term "YANG data model" should be used in the title, abstract, and in
   the body of the document where the overall design is described.
   "YANG module" should be used when a specific "*.yang" file is
   referenced.  Likewise, "YANG module" should be used when using terms
   related to YANG module specifications (e.g., augmentation or
   deviation).  However, when extending the concepts embodied in a YANG
   module, authors should refer to those as an extension to the "YANG
   data model".

For example,

OLD:
   This document defines a YANG data model named "ietf-adaptive-
   subscription" which augments the "update-trigger" choice defined in

NEW:
   This document defines a YANG module named "ietf-adaptive-
   subscription" which augments the "update-trigger" choice defined in

OLD:
   it augments the "ietf-notification-capabilities" data
   model defined in [RFC9196]

NEW:
   it augments the "ietf-notification-capabilities" module
   defined in [RFC9196]

Idem, you also use:

CURRENT:
       "This module extends the YANG data module defined in
        YANG-push to enable the subscriber's adaptive

While RFC9907 says:
   Likewise, "YANG data module" has no meaning
   and must be avoided.

# Please delete the following:

CURRENT:
   The YANG module specified in this document is compliant with Network
   Management Datastore Architecture (NMDA) [RFC8342].

A mention is needed only where the are major deviations per RFC9907:

   If the document contains major Network Management Datastore
   Architecture (NMDA) exceptions or includes a temporary non-NMDA
   module [RFC8342], then the Introduction section SHOULD mention this
   fact with the reasoning that motivated that design.

# Make Kent happy :-)

OLD:
        WG List:  <[e-mail]>

NEW:
        WG List:  NETCONF <[e-mail]>

# Follow IETF Template

OLD:
        This version of this YANG module is part of RFC XXXX
        (https://www.rfc-editor.org/info/rfcXXXX) 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.";

# Notifications, again

OLD:
       reference
         "RFC XXXX: Adaptive Subscription to YANG Notification.";

NEW:
       reference
         "RFC XXXX: Adaptive Subscription to YANG Notifications.";

# Nit

OLD: A list of adaptive period

NEW: A list of adaptive periods

# Consider clarifying the uniqueness scope of the name

CURRENT:
           leaf name {
             type string;
             description
               "The unique name of adaptive period.";
           }

# Consistency

CURRENT:
           leaf eval-interval {
             type yp:centiseconds;
             description
               "How often the XPath condition expression represented
                by 'eval-expression' is evaluated to decide whether
                to switch to another period interval.";
           }
           leaf period {
             type yp:centiseconds;
             mandatory true;
             description
               "Duration of time that should occur between periodic
                push updates, in units of 0.01 seconds.";
           }

I guess the unit is inferred from the type here (yp:centiseconds). So, a
“units” statement may be ignored. However, some of description mention “in
units of 0.01 seconds”, while others don’t.

Please pick one form and be consistent in all similar nodes that have
yp:centiseconds as a type.

# Another server operation consideration to call out

CURRENT:
   If a server receives an XPath evaluation criterion with some XPath
   syntax unsupported against the specific targeted data node, an RPC
   error with "xpath-evaluation-unsupported" MUST be returned.

Servers should expose bounds that they support. Should that support be added to
the module so that it can be retrieved and used to adjust client setting of
filters?

# Nits

OLD:
   within a short time window is a primay indicator of oscillation or
   unstable evaludation expressions.

NEW:
   within a short time window is a primary indicator of oscillation or
   unstable evaluation expressions.

# RFC9907

Please update this entry

   [I-D.ietf-netmod-rfc8407bis]
              Bierman, A., Boucadair, M., and Q. Wu, "Guidelines for
              Authors and Reviewers of Documents Containing YANG Data
              Models", Work in Progress, Internet-Draft, draft-ietf-
              netmod-rfc8407bis-28, 5 June 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
              rfc8407bis-28>.

# Not sure I would keep the following in an Exp doc

CURRENT:
; they do not prescribe or imply any normative behavior for
   deployments.

The previous part of the text is clear this is only for illustration.

# Module prefix

CURRENT:
   module example-wifi-network-diagnostic {
     yang-version 1;
     namespace "http://example.com/yang/wifi-network-diagnostic";
     prefix wnd;

Please consider updating to follow this guidance in 9907:

   For convenience, prefix values of example modules SHOULD be prefixed
   with "ex" or similar patterns.  In doing so, readers of example
   modules or tree diagrams that mix both example and standard modules
   can easily identify example parts

# XML Examples

I didn’t check them, but I trust the authors did. Please confirm. Thanks.

Hope this helps.

Cheers,
Med