Hi Lars,
Thanks for your TSV directorate review.
We have posted a draft version, which we believe address your points.
new version of Internet-Draft draft-ietf-opsawg-rfc5706bis-02.txt has been
successfully submitted by Benoît Claise and posted to the
IETF repository.
Name: draft-ietf-opsawg-rfc5706bis
Revision: 02
Title: Guidelines for Considering Operations and Management in IETF
Specifications
Date: 2026-02-19
Group: opsawg
Pages: 48
URL:https://www.ietf.org/archive/id/draft-ietf-opsawg-rfc5706bis-02.txt
Status:https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/
HTML:https://www.ietf.org/archive/id/draft-ietf-opsawg-rfc5706bis-02.html
HTMLized:https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-rfc5706bis
Diff:https://author-tools.ietf.org/iddiff?url2=draft-ietf-opsawg-rfc5706bis-02
See inline.
Document: draft-ietf-opsawg-rfc5706bis
Title: Guidelines for Considering Operations and Management in IETF
Specifications Reviewer: Lars Eggert Review result: Not Ready
# 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 [email protected]
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.)
We realized that we did not stress early on the fact the escape clause;
this is now done in the abstract.
This document provides **no** evidence that would motivate why this additional
work is something that needs to be put on all IETF WGs **now**.
We discussed and considered your point in our weekly calls.
We don't believe this is the document goal to document the evidence,
with good & bad examples.This might be a distraction, on top of
potential finger-pointing. Once/if this document is published, that
would become somehow irrelevant.
We addressed all the nits below.
Thanks again for your review.
Regards, Benoit (on behalf of the authors)
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 (viahttps://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
_______________________________________________
OPSAWG mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
