# 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