I-D list for Network Configuration RSS Feed

Adaptive Subscription to YANG Notifications

2026-04-16T16:56:45.221676+00:00

Closed request for IETF Last Call review by GENART with state 'Overtaken by Events': Gen AD has already balloted

Adaptive Subscription to YANG Notifications

2026-04-16T16:56:21.972757+00:00

Assignment of request for IETF Last Call review by GENART to Matt Joras was marked no-response

Adaptive Subscription to YANG Notifications

2026-04-16T14:34:31.027296+00:00

IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation

Adaptive Subscription to YANG Notifications

2026-04-16T14:33:55.662558+00:00

Changed consensus to Yes from Unknown

Adaptive Subscription to YANG Notifications

2026-04-16T05:28:46.050211+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Tommy Jensen

Adaptive Subscription to YANG Notifications

2026-04-16T02:09:03.803399+00:00

[Ballot comment]
Thank you for a very clearly written draft with a clearly defined experiment including the data that you hope to collect. Nice work.

Adaptive Subscription to YANG Notifications

2026-04-16T02:09:03.803310+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Christopher Inacio

Adaptive Subscription to YANG Notifications

2026-04-15T23:53:08.801007+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Charles Eckel

Adaptive Subscription to YANG Notifications

2026-04-15T21:04:21.763902+00:00

IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed

YANG Datastore Telemetry (YANG Push version 2)

2026-04-15T20:31:52.868767+00:00

This document now replaces draft-wilton-netconf-yang-push-lite instead of None

Adaptive Subscription to YANG Notifications

2026-04-15T16:52:30.323514+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Andy Newton

Extensible YANG Model for YANG-Push Notifications

2026-04-15T15:46:37.623375+00:00

Notification list changed to leonardo.rodoni@swisscom.com because the document shepherd was set

Extensible YANG Model for YANG-Push Notifications

2026-04-15T15:46:37.623375+00:00

Document shepherd changed to Leonardo Rodoni

Adaptive Subscription to YANG Notifications

2026-04-15T08:12:40.778536+00:00

IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed

Adaptive Subscription to YANG Notifications

2026-04-15T08:12:40.292489+00:00

New version available: draft-ietf-netconf-adaptive-subscription-17.txt

Adaptive Subscription to YANG Notifications

2026-04-15T08:12:40.290394+00:00

New version accepted (logged-in submitter: Qiufang Ma)

Adaptive Subscription to YANG Notifications

2026-04-15T08:12:40.203557+00:00

Uploaded new revision

Adaptive Subscription to YANG Notifications

2026-04-15T04:31:45+00:00

IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed

Adaptive Subscription to YANG Notifications

2026-04-14T14:53:49.950791+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Gunter Van de Velde

UDP-based Transport for Configured Subscriptions

2026-04-14T14:22:34.321630+00:00

# Document Shepherd Write-Up for Group Documents

*This version is dated 12 September 2025.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
few individuals, with others being silent, or did it reach broad agreement?

Yes, this work has benefited from the discussion of UDP transport notification over years
and is a replacement draft for both draft-zheng-netconf-udp-pub-channel and draft-unyte-netconf-udp-notif
and represents a broad agreement.

2. Was there controversy about particular points, or were there decisions where
the consensus was particularly rough?

No controversy. The need of congestion control
was brought up during TSVART review and discussed in IETF 119 NETCONF session and rough
consensus had been reached on detailed level of congestion control.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarize the areas of conflict in separate email messages to the
responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No.

4. For protocol documents, are there existing implementations of the contents of
the document? Have a significant number of potential implementers indicated
plans to implement? Are any existing implementations reported somewhere,
either in the document itself (as [RFC 7942][3] recommends) or elsewhere
(where)?

There are 4 known open source implementations and 3 implementations from network vendors, which have been
documented in section 9 of rev-22 of this document.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
IETF working groups or external organizations, and would it therefore benefit
from their review? Have those reviews occurred? If yes, describe which
reviews took place.

This document uses transport technology in WIT area and has been reviewed by TSVART
https://mailarchive.ietf.org/arch/msg/netconf/J8YeAHqnqIiyj-QqXdBx4nToXUw/
The comments from TSVART have been addressed in v-24 and confirmed on the NETCONF
ML https://mailarchive.ietf.org/arch/msg/netconf/0FwQWSxxi64r-i5AyqjskRvXC0M/.
Additional comments from WIT Area AD Gorry have been addressed in v-25 and confirmed on the NETCONF ML:
https://mailarchive.ietf.org/arch/msg/netconf/KbOfowwjF3kgQPMtPwQAZiQYukY/.

6. Describe how the document meets any required formal expert review criteria,
such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This document has been reviewed by YANG Doctor, the review result is available at:
https://datatracker.ietf.org/doc/review-ietf-netconf-udp-notif-20-yangdoctors-early-schoenwaelder-2025-04-16/
No message states that the YANG Doctors review is cleared.

7. If the document contains a YANG module, has the final version of the module
been checked with any of the [recommended validation tools][4] for syntax and
formatting validation? If there are any resulting errors or warnings, what is
the justification for not fixing them at this time?

3 pyang command tools "pyang --ietf ","pyang --lint" and "yanglint" have been used to validate
v-25 of YANG module included in this document, there are no errors or warnings to be found.

Does the YANG module
comply with the Network Management Datastore Architecture (NMDA) as specified
in [RFC 8342][5]?

Yes

8. Describe reviews and automated checks performed to validate sections of the
final version of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, CBOR's CDDL, etc.

Manual review of the XML examples in Appendix A. There are no errors or warnings to be found.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
document is needed, clearly written, complete, correctly designed, and ready
to be handed off to the responsible Area Director?

Yes.

10. Several IETF Areas have assembled [lists of common issues that their
reviewers encounter][6]. For which areas have such issues been identified
and addressed? For which does this still need to happen in subsequent
reviews?

N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
Current Practice][12], [Proposed Standard, Internet Standard][13],
[Informational, Experimental or Historic][14])? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this intent?

Proposed Standard. Because Capabilities for high frequency UDP based Data Collection are needed by
both NETCONF clients and RESTCONF client. The "Intended RFC Status" in Datatracker has to be set to
reflect this intent.

12. Have reasonable efforts been made to remind all authors of the intellectual
property rights (IPR) disclosure obligations described in [BCP 79][7]? To
the best of your knowledge, have all required disclosures been filed? If
not, explain why. If yes, summarize any relevant discussion, including links
to publicly-available messages when applicable.

All authors have responded not being aware of any IPR:
https://mailarchive.ietf.org/arch/msg/netconf/VQUz-x7mEWVmdxwG_ZZAbN-mlUk/

13. Has each author, editor, and contributor shown their willingness to be
listed as such? If the total number of authors and editors on the front page
is greater than five, please provide a justification.

Yes. The document has 5 authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
tool][8] is not enough; please review the ["Content Guidelines" on
authors.ietf.org][15]. (Also note that the current idnits tool generates
some incorrect warnings; a rewrite is underway.)

Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------

Miscellaneous warnings:
----------------------------------------------------------------------------

-- The document date (3 July 2025) is 70 days in the past. Is this
intentional?

Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------

(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)

-- Possible downref: Non-RFC (?) normative reference: ref. 'BCP195'

-- Possible downref: Non-RFC (?) normative reference: ref. 'BCP230'

== Outdated reference: A later version (-15) exists of
draft-ietf-netconf-distributed-notif-14

** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147)

Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--).

Run idnits with the --verbose option for more detailed information about
the items above.

I think Outdated reference draft-ietf-netconf-distributed-notif needs to be changed
into v-15. For Obsolete normative reference RFC6347， I believe it is intentional
to reference both TLS1.2 and TLS1.3 therefore this error is innocuous and can be ignored.

15. Should any informative references be normative or vice-versa? See the [IESG
Statement on Normative and Informative References][16].

References are cited properly.

16. List any normative references that are not freely available to anyone. Did
the community have sufficient access to review any such normative
references?

None.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
list them.

None.

18. Are there normative references to documents that are not ready to be
submitted to the IESG for publication or are otherwise in an unclear state?
If so, what is the plan for their completion?

None. This document adds dependency to two other documents: [I-D.ietf-netconf-distributed-notif] and [I-D.ietf-netconf-udp-client-server].
Both documents will be submitted to the IESG in parallel for publication.

19. Will publication of this document change the status of any existing RFCs? If
so, does the Datatracker metadata correctly reflect this and are those RFCs
listed on the title page, in the abstract, and discussed in the
introduction? If not, explain why and point to the part of the document
where the relationship of this document to these other RFCs is discussed.

No change.

20. Describe the document shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.
Confirm that all aspects of the document requiring IANA assignments are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that each newly created IANA registry specifies its initial contents,
allocations procedures, and a reasonable name (see [RFC 8126][11]).

The document shepherd has reviewed IANA considerations section and confirm
three new registries are correctly defined and consistent with the body of this document.

21. List any new IANA registries that require Designated Expert Review for
future allocations. Are the instructions to the Designated Expert clear?
Please include suggestions of designated experts, if appropriate.

N/A

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]:
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

Adaptive Subscription to YANG Notifications

2026-04-14T12:40:11.293060+00:00

[Ballot comment]
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.

The changes made in [1] adequately addresses comments in my previous ballot [2].

I have one minor comment about -16:

# server/publisher

As you decided to maintain both server and publisher and that you define "client" such as in:

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

* ...

* Client
...

* Publisher

...

I think that you need an entry for server as well.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url2=draft-ietf-netconf-adaptive-subscription-16

[2] https://mailarchive.ietf.org/arch/msg/netconf/xOmD8LV6jXZQfkRFt6HSBS3lRH4/

Adaptive Subscription to YANG Notifications

2026-04-14T12:40:11.292991+00:00

[Ballot Position Update] Position for Mohamed Boucadair has been changed to Yes from Discuss

Adaptive Subscription to YANG Notifications

2026-04-14T11:35:10.348626+00:00

[Ballot comment]
Thank you to Yoav Nir for their secdir review.

Section 1.2: This experimental draft actually defines the experiment! Kudos.

Section 7, para 2: I recommend using draft-ietf-tls-8446bis vice RFC 8446. The draft is in Auth 48.

Adaptive Subscription to YANG Notifications

2026-04-14T11:35:10.348546+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Deb Cooley

Subscription to Notifications in a Distributed Architecture

2026-04-14T05:29:44.669283+00:00

Changed action holders to Mahesh Jethanandani (IESG state changed)

Subscription to Notifications in a Distributed Architecture

2026-04-14T05:29:44.645454+00:00

Sub state has been changed to AD Followup from Revised I-D Needed

Subscription to Notifications in a Distributed Architecture

2026-04-14T05:29:44.094008+00:00

New version available: draft-ietf-netconf-distributed-notif-19.txt

Subscription to Notifications in a Distributed Architecture

2026-04-14T05:29:44.091275+00:00

New version accepted (logged-in submitter: Thomas Graf)

Subscription to Notifications in a Distributed Architecture

2026-04-14T05:29:44.037419+00:00

Uploaded new revision

Adaptive Subscription to YANG Notifications

2026-04-13T21:22:04.714163+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw

Adaptive Subscription to YANG Notifications

2026-04-13T11:53:26.830011+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard

Adaptive Subscription to YANG Notifications

2026-04-13T10:18:02.606119+00:00

[Ballot comment]
Thank you to Joe Touch for his review. I concur with his conclusion when used over a congestion-controlled Internet transport that there are "no particular transport considerations of note".

NiT:
/setting a too high or low threshold may make adaptive subscription degenerated to periodic subscription./ - is this word /degenerate/ rather than /degenerated/?

- Regards, Gorry

Adaptive Subscription to YANG Notifications

2026-04-13T10:18:02.606000+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Gorry Fairhurst

Adaptive Subscription to YANG Notifications

2026-04-13T07:36:03.555669+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke

Adaptive Subscription to YANG Notifications

2026-04-10T08:59:01.853598+00:00

IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed

Adaptive Subscription to YANG Notifications

2026-04-10T08:59:01.297848+00:00

New version available: draft-ietf-netconf-adaptive-subscription-16.txt

Adaptive Subscription to YANG Notifications

2026-04-10T08:59:01.295708+00:00

New version accepted (logged-in submitter: Qiufang Ma)

Adaptive Subscription to YANG Notifications

2026-04-10T08:59:01.246449+00:00

Uploaded new revision

Transaction ID Mechanism for NETCONF

2026-04-10T07:09:00.467591+00:00

Document has expired

Subscription to Notifications in a Distributed Architecture

2026-04-09T16:07:17.792712+00:00

Request for IETF Last Call review by INTDIR Completed: Ready. Reviewer: Florian Obser. Sent review to list.

Adaptive Subscription to YANG Notifications

2026-04-09T10:52:45.514458+00:00

[Ballot 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,
.

And

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

Adaptive Subscription to YANG Notifications

2026-04-09T10:52:45.514422+00:00

[Ballot 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:

:

# 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:

NEW:
WG List: NETCONF

# 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,
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

Adaptive Subscription to YANG Notifications

2026-04-09T10:52:45.514308+00:00

Ballot comment and discuss text updated for Mohamed Boucadair

Adaptive Subscription to YANG Notifications

2026-04-09T10:43:34.779791+00:00

[Ballot 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 document defines an experimental YNAG 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,
.

And

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

Adaptive Subscription to YANG Notifications

2026-04-09T10:43:34.779746+00:00

[Ballot 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. Published

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:

:

# Muxing error cases is 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: NETCONF

NEW:
WG List:

# 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

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,
rfc8407bis-28>.

# Not sure I would keep this 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.

# 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

Adaptive Subscription to YANG Notifications

2026-04-09T10:43:34.779610+00:00

[Ballot Position Update] New position, Discuss, has been recorded for Mohamed Boucadair