Early Review of draft-ietf-opsawg-rfc5706bis-01
review-ietf-opsawg-rfc5706bis-01-tsvart-early-eggert-2026-01-22-00
| Request | Review of | draft-ietf-opsawg-rfc5706bis |
|---|---|---|
| Requested revision | No specific revision (document currently at 01) | |
| Type | Early Review | |
| Team | Transport Area Review Team (tsvart) | |
| Deadline | 2026-01-23 | |
| Requested | 2026-01-07 | |
| Requested by | Alvaro Retana | |
| Authors | Benoît Claise , Joe Clarke , Adrian Farrel , Samier Barguil , Carlos Pignataro , Ran Chen | |
| I-D last updated | 2026-01-21 (Latest revision 2025-12-17) | |
| Completed reviews |
Iotdir Early review of -01
by Dave Thaler
Dnsdir Early review of -01 by Johan Stenstam Yangdoctors Early review of -01 by Martin Björklund Artart Early review of -01 by Harald T. Alvestrand Genart Early review of -01 by Joel M. Halpern Tsvart Early review of -01 by Lars Eggert Perfmetrdir Early review of -01 by Greg Mirsky Rtgdir Early review of -01 by Dhruv Dhody Opsdir Early review of -01 by Tina Tsou (Ting ZOU) |
|
| Comments |
Hi! I'm requesting an early review of this document from all directorates, given the requirement that all future RFCs include an Operational Considerations section (see Section 3 for details). Focus on how the contents of the draft (including the concise checklist of key questions in Appendix A) apply to your specific area of expertise. Thanks! |
|
| Assignment | Reviewer | Lars Eggert |
| State | Completed | |
| Request | Early review on draft-ietf-opsawg-rfc5706bis by Transport Area Review Team Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/tsv-art/9wSF8GQ8aacc5hrR5K8Sm_YTShw | |
| Reviewed revision | 01 | |
| Result | Not ready | |
| Completed | 2026-01-22 |
review-ietf-opsawg-rfc5706bis-01-tsvart-early-eggert-2026-01-22-00
# tsvart-early review of draft-ietf-opsawg-rfc5706bis-01 CC @larseggert This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. Thanks to Joel M. Halpern for the General Area Review Team (Gen-ART) review (https://mailarchive.ietf.org/arch/msg/gen-art/Zk5kYBtp7lz7li3BYYQZfnrCBVM). ## Comments ### "Abstract", paragraph 2 ``` creation and introduces a requirement to include an "Operational Considerations" section in new RFCs in the IETF Stream. ``` Oh please no. We have been down this road several times in the last decades. Not all IETF RFCs need this section, no matter how much the originating area may claim otherwise. If an spec needs one, there is ample opportunity during IETF and then IESG review to flag missing operations coverage and have it be added. OPS isn't SEC (and even for SEC there are quite a few specs for which that section isn't needed.) This document provides **no** evidence that would motivate why this additional work is something that needs to be put on all IETF WGs **now**. The IETF is already famously slow. Making all work go slower by putting an onus on all WGs to do busy-work for the OPS area is not moving us forward, no matter how good and important it would make the OPS area feel. ### Section 3, paragraph 0 ``` 3. Documentation Requirements for IETF Specifications ``` Remove this section. Rephrase the rest of the document to make recommendations to authors who **choose to** discuss operations and manageability aspects in their documents **because it makes sense for them**. ### Rest The rest of the document seems reasonable for a the stage in the process it is in. ### Too many authors The document has six authors, which exceeds the recommended author limit. Has the sponsoring AD agreed that this is appropriate? ### Inclusive language Found terminology that should be reviewed for inclusivity; see https://www.rfc-editor.org/part2/#inclusive_language for background and more guidance: * Term `master`; alternatives might be `active`, `central`, `initiator`, `leader`, `main`, `orchestrator`, `parent`, `primary`, `server` (matched `master` rule, pattern ((\bmaster\w*\b)\w*)) ## Nits All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. ### Typos #### Section 5, paragraph 9 ``` - Protocol Exension. Often an individual network element is not aware + Protocol Extension. Often an individual network element is not aware + + ``` ### Uncited references Uncited references: `[IESG-STATEMENT]` and `[NEMOPS-WORKSHOP]`. ### Outdated references Document references `draft-ietf-lamps-dilithium-certificates`, but that has been published as `RFC9881{quote}. Document references `draft-ietf-nmop-network-incident-yang-06`, but `-07` is the latest available revision. Document references `draft-ietf-tcpm-prr-RFC6937bis`, but that has been published as `RFC9937{quote}. Document references `draft-ietf-opsawg-oam-characterization-14`, but `-15` is the latest available revision. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF]. You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT]. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments [IRT]: https://github.com/larseggert/ietf-reviewtool