Adaptive Subscription to YANG Notifications
draft-ietf-netconf-adaptive-subscription-18

RFC Editor Note was changed to

RFC Editor Note

There is a typo in Section 1.2, line 229 of the draft that was not caught in
-17:

"as well as the slection of 'eval-interval' parameter"

should be:

"as well as the selection of 'eval-interval' parameter"

There is a typo in Section 1.2, line 229 of the draft that was not caught in -17:

"as well as the slection of 'eval-interval' parameter"

should be:

"as well as the selection of 'eval-interval' parameter"

But I am sure it will be fixed by the RFC Editor.

[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/

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

[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

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

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

# 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

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

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

# 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

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-netconf-adaptive-subscription-15. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry in the IETF XML Registry group located at:

https://www.iana.org/assignments/xml-registry/

a single new namespace will be registered as follows:

ID: yang:ietf-adaptive-subscription
URI: urn:ietf:params:xml:ns:ietf-adaptive-subscription
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the YANG Module Names registry in the YANG Parameters registry group located at:

https://www.iana.org/assignments/yang-parameters/

a single new YANG module will be registered as follows:

Name: ietf-adaptive-subscription
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-adaptive-subscription
Prefix: adaps
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

In section 2.1, second bullet point: “If the leaf is encoded in XML, all namespace declarations in scope on the "eval-expression" leaf element are added to the set of namespace declarations. If a prefix found in the XML is already present in the set of namespace declarations, the namespace in the XML is used.”  I read that to say that a namespace declaration with associated prefix in the XML overrides one in the pre-existing namespace declarations with the same prefix. If that’s what it means, then no worries. 

I wonder about namespace declarations in the XML leaf that have no prefix, , is there possibility of a conflict with pre-existing namespace declarations?

The XML examples are complicated but I don’t see anything wrong with them.

The following Last Call announcement was sent out (ends 2026-03-23):

From: The IESG
To: IETF-Announce
CC: draft-ietf-netconf-adaptive-subscription@ietf.org, mjethanandani@gmail.com, netconf-chairs@ietf.org, netconf@ietf.org, thomas.graf@swisscom.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Adaptive Subscription to YANG Notification) to Experimental RFC


The IESG has received a request from the Network Configuration WG (netconf)
to consider the following document: - 'Adaptive Subscription to YANG
Notification'
  as Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2026-03-23. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines a YANG data model and associated mechanism to
  enable adaptive subscriptions to YANG notifications.  The publisher
  can dynamically adjust the periodic update interval based on the
  evaluation of pre-configured conditions (e.g., thresholds or
  expressions).  This allows for finer-grained telemetry by increasing
  update frequency when certain criteria are met, and reducing it
  otherwise.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-netconf-adaptive-subscription/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/5438/
  https://datatracker.ietf.org/ipr/5439/

Thanks to both Joe and Dhruv for completing their expert review. I will mark the state as Revised I-D needed to allow for the authors to address the comments from both the reviewers. If a revised I-D is not needed (which I doubt), let me know.

I have indicated Revised I-D needed after having provided some follow-up comments. Based on the feedback, authors can decide whether a new I-D is needed or not.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

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?

During the working group process, the document received fair feedback from the
working group and OPS directorate and YANG doctors reviews. There was no feedback
on the working group last call.


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

There was no controversy.


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)?

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-adaptive-subscription-09#section-6 describes 1 prototype implementation. Matches document intend to be Experimental.


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

The content relate to a YANG-Push push extension modeled in YANG. A YANG doctors
and OPS directorate review was performed.


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.

A YANG doctors review was performed. RFC 8407bis has been applied to
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-adaptive-subscription-09#section-7

UPDATE BY CHAIRS: YANG Doctor says all issues were addressed by recent updates.

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? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The YANG modules were validated with pyang and yanglint.

The YANG module is NMDA compliant. The document has a RFC 8342 normative downstream
reference.

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.

Not applicable.


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

The document is well written and the YANG-Push extension described makes sense.
The use cases described make from a network operation point of view sense.


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?

No issues has been identified.


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?

Experimental


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.

IPR calls and declarations have been performed according to BCP 79. See https://mailarchive.ietf.org/arch/msg/netconf/mpowVmtzEz1ZOYWcdQMgKJ3bolU/


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, there are 5 authors and 2 contributors.


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.)

idnits shows no issues and document complies to content guidelines. Contains YANG
schema tree and examples for dynamic and configured YANG-Push subscriptions.
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-netconf-adaptive-subscription-09.txt


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

RFC 3688 should be normative instead of informative.

UPDATE BY CHAIRS: RFC 3688 is now normative.


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


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, it doesn't.


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]).

IANA Consideration section reflects
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-28#section-3.8.3.1


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.

There are no new IANA registries.


[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/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

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?

During the working group process, the document received fair feedback from the
working group and OPS directorate and YANG doctors reviews. There was no feedback
on the working group last call.


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

There was no controversy.


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)?

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-adaptive-subscription-09#section-6 describes 1 prototype implementation. Matches document intend to be Experimental.


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

The content relate to a YANG-Push push extension modeled in YANG. A YANG doctors
and OPS directorate review was performed.


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.

A YANG doctors review was performed. RFC 8407bis has been applied to
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-adaptive-subscription-09#section-7

UPDATE BY CHAIRS: YANG Doctor says all issues were addressed by recent updates.

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? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The YANG modules were validated with pyang and yanglint.

The YANG module is NMDA compliant. The document has a RFC 8342 normative downstream
reference.

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.

Not applicable.


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

The document is well written and the YANG-Push extension described makes sense.
The use cases described make from a network operation point of view sense.


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?

No issues has been identified.


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?

Experimental


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.

IPR calls and declarations have been performed according to BCP 79. See https://mailarchive.ietf.org/arch/msg/netconf/mpowVmtzEz1ZOYWcdQMgKJ3bolU/


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, there are 5 authors and 2 contributors.


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.)

idnits shows no issues and document complies to content guidelines. Contains YANG
schema tree and examples for dynamic and configured YANG-Push subscriptions.
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-netconf-adaptive-subscription-09.txt


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

RFC 3688 should be normative instead of informative.

UPDATE BY CHAIRS: RFC 3688 is now normative.


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


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, it doesn't.


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]).

IANA Consideration section reflects
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-28#section-3.8.3.1


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.

There are no new IANA registries.


[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/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

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?

During the working group process, the document received fair feedback from the
working group and OPS directorate and YANG doctors reviews. There was no feedback
on the working group last call.


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

There was no controversy.


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)?

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-adaptive-subscription-09#section-6 describes 1 prototype implementation. Matches document intend to be Experimental.


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

The content relate to a YANG-Push push extension modeled in YANG. A YANG doctors
and OPS directorate review was performed.


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.

A YANG doctors review was performed. RFC 8407bis has been applied to
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-adaptive-subscription-09#section-7


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? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The YANG modules were validated with pyang and yanglint.

The YANG module is NMDA compliant. The document has a RFC 8342 normative downstream
reference.

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.

Not applicable.


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

The document is well written and the YANG-Push extension described makes sense.
The use cases described make from a network operation point of view sense.


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?

No issues has been identified.


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?

Experimental


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.

IPR calls and declarations have been performed according to BCP 79. See https://mailarchive.ietf.org/arch/msg/netconf/mpowVmtzEz1ZOYWcdQMgKJ3bolU/


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, there are 5 authors and 2 contributors.


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.)

idnits shows no issues and document complies to content guidelines. Contains YANG
schema tree and examples for dynamic and configured YANG-Push subscriptions.
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-netconf-adaptive-subscription-09.txt


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

RFC 3688 should be normative instead of informative.


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


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, it doesn't.


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]).

IANA Consideration section reflects
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-28#section-3.8.3.1


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.

There are no new IANA registries.


[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/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

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?

During the working group process, the document received fair feedback from the
working group and OPS directorate and YANG doctors reviews. There was no feedback
on the working group last call.


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

There was no controversy.


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)?

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-adaptive-subscription-09#section-6 describes 1 prototype implementation. Matches document intend to be Experimental.


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

The content relate to a YANG-Push push extension modeled in YANG. A YANG doctors
and OPS directorate review was performed.


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.

A YANG doctors review was performed. RFC 8407bis has been applied to
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-adaptive-subscription-09#section-7


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? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

The YANG modules were validated with pyang and yanglint.

The YANG module is NMDA compliant. The document has a RFC 8342 normative downstream
reference. However it lacks the following paragraph:

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


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.

Not applicable.


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

The document is well written and the YANG-Push extension described makes sense.
The use cases described make from a network operation point of view sense.


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?

No issues has been identified.


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?

Experimental


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.

IPR calls and declarations have been performed according to BCP 79. See https://mailarchive.ietf.org/arch/msg/netconf/mpowVmtzEz1ZOYWcdQMgKJ3bolU/


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, there are 5 authors and 2 contributors.


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.)

idnits shows no issues and document complies to content guidelines. Contains YANG
schema tree and examples for dynamic and configured YANG-Push subscriptions.
https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-netconf-adaptive-subscription-09.txt


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

RFC 3688 should be normative instead of informative.


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


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, it doesn't.


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]).

IANA Consideration section should be updated according to
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-28#section-3.8.3.1


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.

There are no new IANA registries.


[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/