Skip to main content

IETF Last Call Review of draft-ietf-netconf-distributed-notif-19
review-ietf-netconf-distributed-notif-18-opsdir-lc-qu-2026-04-03-01

Request Review of draft-ietf-netconf-distributed-notif
Requested revision No specific revision (document currently at 19)
Type IETF Last Call Review
Team Ops Directorate (opsdir)
Deadline 2026-03-08
Requested 2026-02-22
Requested by Mahesh Jethanandani
Authors Tianran Zhou , Guangying Zheng , Eric Voit , Thomas Graf , Pierre Francois
I-D last updated 2026-04-21 (Latest revision 2026-04-13)
Completed reviews Yangdoctors Early review of -13 by Martin Björklund (diff)
Opsdir Early review of -14 by Jürgen Schönwälder (diff)
Opsdir IETF Last Call review of -19 by Yingzhen Qu
Yangdoctors IETF Last Call review of -17 by Martin Björklund (diff)
Genart IETF Last Call review of -18 by Joel M. Halpern (diff)
Secdir IETF Last Call review of -19 by Daniel Migault
Tsvart IETF Last Call review of -18 by Magnus Westerlund (diff)
Intdir IETF Last Call review of -18 by Florian Obser (diff)
Comments
The SEDDIR review should look for any security implications as far as sending traffic from the Component (a.k.a. line cards) to an entity outside the chassis. Similarly, the INTDIR review should examine the implications of establishing an IP network inside and outside the box. The transport experts should examine the use of UDP and any possible issues with sending data over it. Finally, the YANG doctors should (re)examine any changes to the YANG module and OPSDIR on any operational considerations that were not obvious before.
Assignment Reviewer Yingzhen Qu
State Completed
Request IETF Last Call review on draft-ietf-netconf-distributed-notif by Ops Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/rJr4VNmj8cN1i3mwpX8w81y7fxE
Reviewed revision 19
Result Ready
Completed 2026-05-04
review-ietf-netconf-distributed-notif-18-opsdir-lc-qu-2026-04-03-01
I have reviewed version -19, which addressed my comments, so I'm revising the
review to "Ready".

Hi,

I have been selected as the Operational Directorate (opsdir) reviewer for this
Internet-Draft.

The Operational Directorate reviews all operational and management-related
Internet-Drafts to ensure alignment with operational best practices and that
adequate operational considerations are covered.

A complete set of _"Guidelines for Considering Operations and Management in
IETF Specifications"_ can be found at
https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/.

While these comments are primarily for the Operations and Management Area
Directors (Ops ADs), the authors should consider them alongside other feedback
received.

- Document: [Internet-Draft Name and Revision]

- Reviewer: [Your Name]

- Review Date: [Date]

- Intended Status: [Proposed Status, e.g., Standards Track]

---

## Summary

Choose one:

- Ready: No issues found. This document is ready for publication.

- Has Nits: This document is basically ready for publication but has nits that
should be considered prior to publication.

- Has Issues: I have some minor concerns about this document that I think
should be resolved before publication.

- Has Major Issues: I have significant concerns about this document and
recommend that the OPS ADs discuss these issues further with the authors.

## General Operational Comments Alignment with RFC 5706bis

Provide an overview of the draft’s operational feasibility, readability, and
alignment with RFC5706bis guidelines. Example:

> This document defines a mechanism for [X]. While the technical approach is
sound, Section [X] lacks clarity on how the mechanism would deploy.

> The Operational Considerations section (Section X) should be expanded to
address [Z].

Explicitly evaluate compliance with operational guidelines (optional but
recommended):

For example the check list:

- Fault Management: Are failure detection/recovery mechanisms specified?

- Configuration Management: Are configuration changes to enable/disable the
feature clearly defined?

- Performance Monitoring: Are metrics (e.g., latency, resource usage) clearly
identified?

| Review Item                | RFC 5706 Considerations
|-------------------------------
|-------------------------------------------------------------------------------------------------------
| Deployment                     | Does the document include a description of
how this protocol or technology is going to be deployed and managed? |
Installation and Initial Setup | Are configuration parameters clearly
identified and do they have reasonable default values? | Migration Path        
        | Is a path to migrate existing configuration clearly articualted? Are
there any backward compatibility issues? | Requirements on Other Protocols|
What other protocol operations are expected to be performed relative to the new
protocol or technology? | Impact on Network Operation    | Will the new
protocol significantly increase traffic load on existing networks or affect the
control plane? | Verifying Correct Operation    | For example, how can one test
end-to-end connectivity and throughput?

For routing protocols, example as

[RFC 6123 – Inclusion of Manageability Sections in Path Computation Element
(PCE) Working Group Drafts](https://www.rfc-editor.org/rfc/rfc6123.html)

## Major Issues

List critical problems blocking publication (e.g., protocol flaws, missing
operational safeguards, or lack of manageability considerations). Include
section/paragraph references.

- Example:

 > Section 4.2 describes [feature] but does not specify how operators can
 monitor its performance (RFC 5706 Section 3.6). This omission could lead to
 undiagnosed failures in production networks.

- If none:

 > No major issues found.

---

## Minor Issues

List non-blocking but important clarifications (e.g., ambiguous terminology or
incomplete examples).

- Example:

 > Section 2.1 uses "node" without defining its scope (physical/virtual). Add a
 reference to RFC 8345 for consistency.

- If none:

 > No minor issues found.

---

## Nits

Optional editorial suggestions (e.g., acronym expansions or grammar fixes).

- Example:

 > Abstract: Expand "NFV" on first use.

 > Section 3.1: "it’s" -> "its".

---