Skip to main content

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 09)
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-10-08 (Latest revision 2026-10-06)
Completed reviews Iotdir Early review of -01 by Dave Thaler (diff)
Dnsdir Early review of -01 by Johan Stenstam (diff)
Yangdoctors Early review of -01 by Martin Björklund (diff)
Artart Early review of -01 by Harald T. Alvestrand (diff)
Genart Early review of -01 by Joel M. Halpern (diff)
Tsvart Early review of -01 by Lars Eggert (diff)
Secdir Early review of -03 by Jacqueline McCall (diff)
Perfmetrdir Early review of -01 by Greg Mirsky (diff)
Rtgdir Early review of -01 by Dhruv Dhody (diff)
Opsdir Early review of -01 by Tina Tsou (Ting ZOU) (diff)
Intdir Early review of -04 by Timothy Winters (diff)
Tsvart IETF Last Call review of -09 by Lars Eggert
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 (document currently at 09)
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