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