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