I agree with a lot of what Warren has written, which is not surprising given that it is all pretty pragmatic.
I'm not really a big fan of mandatory sections in specification documents. We had a phase where our functional specifications ended up with an ever-increasing number of mandatory sections that you were expected to write text in, which in many cases were irrelevant to the functionality being specified in a particular domain. They just end up taking time to write some blurb in and then detract from the core content in the document by making it more bloated than it should be. Thankfully, we have moved away from this approach. Even for the security considerations section in an RFC, it sometimes feels that some of the text is just providing lip service or ticking a box on a checklist and that it won't necessarily make the protocol or the Internet more secure. But at least in the security case, getting it wrong can probably have more catastrophic consequences than the protocol failing at its task or not being easy to manage/operate. I do agree that for many protocols, it is a good idea to consider the operational considerations of deploying and managing the protocols. Personally, I think that it would be great, where applicable, to define the YANG module at the same time as the protocol since they would encourage consistency in the management API. Where there are particular operational considerations, i.e., beyond those that we would expect a competent engineer should automatically consider, then adding an Operational Considerations section makes sense, and we should do that. In addition, some protocols, or protocol families, may benefit from a general Operational/Management/Deployment considerations RFC that covers the protocol and protocol extensions, and then including a reference to that RFC could make sense. In summary, I think that we should continue to try and encourage authors to consider operational considerations early on in protocol design, and we should encourage them to write up appropriate prose if they have something useful to say, but let's not mandate a section, because this path likely leads to having many extra, probably not that helpful, sections in RFCs. Kind regards, Rob From: Warren Kumari <[email protected]> Date: Monday, 2 February 2026 at 06:56 To: Toerless Eckert <[email protected]> Cc: Eric Rescorla <[email protected]>, Mahesh Jethanandani <[email protected]>, Richard Barnes <[email protected]>, Operations and Management Area Working Group Discussion List <[email protected]> Subject: [OPSAWG]Re: Response: Appealing the adoption of draft-ietf-opsawg-rfc5706bis On Fri, Jan 30, 2026 at 9:35 AM, Toerless Eckert <[email protected]<mailto:[email protected]>> wrote: Thanks, Eric, but: https://datatracker.ietf.org/doc/rfc7322/ Informational, IAB Stream: This RFC was published on the Internet Architecture Board (IAB) stream. This RFC is not endorsed by the IETF and has no formal standing in the IETF standards process. So, still don't understand (process wide) how that RFC could be mandatory or BCP for IETF track RFC by itself. Having participated in a bunch of different SDOs, I still believe that one of the greatest strengths of the IETF is that we follow Spencer's "Do the Right Thing" mantra over a strict adherence to rules and regulations. I had always understood the "You must have a Security Considerations section" as an enforced norm: "We expect you to have this, and don't even bother trying to submit a draft without it because the IESG won't progress it". The exact rule lawyering of how this came to be isn't, to me, important - it's just how things work now, and that's more than fine. I'll also note that when I was Ops AD I pushed back on recommendations that all drafts must have an Ops and Mgmt section - it felt like a slippery slope and that we would end up with twenty seven required sections, with each one explaining why it wasn't relevant for the document. When I did see a document which would benefit from more operational considerations I'd generally just ask the authors to add some, and they were generally happy to do so. These were almost never in an Operational Considerations section, because, IMO, having the ops bits embedded in the text makes more sense… W Cheers Toerless On Thu, Jan 29, 2026 at 04:08:15PM -0800, Eric Rescorla wrote: On Thu, Jan 29, 2026 at 4:03 PM Toerless Eckert <[email protected]<mailto:[email protected]>> wrote: Thanks Mahesh No contention with your decision or reasoning, just curious about the refences given. rfc3552 says that the requirement for security sections in RFC is actually raised by rfc2223. Rfc3552 just says how to write them, not that you MUST write them. But rfc2223 is legacy (Jon Postel) and explicitly highlighted in datatracker as having no standing in the IETF process. So: Where actually does the MUST have security considerations reqirement come from that we follow today ? https://www.rfc-editor.org/rfc/rfc7322.html#section-4.8.5 -Ekr In the absence of another RFC i am overlooking it looks to me more like common law: Every IESG wanted to see it, so our current IESG does so too... ?? The IANA considerations are IMHO not a good second example for a MUST have, because its conditioned on wanting something from IANA. Thats not even an IETF thing. Thats just an expectation from IANA. "You wanna order something from us - here is the order sheet format". Do we have any other (better) IESG track document examples that state MUST against some parts of IETF track RFCs ? Doesn't have to be sections.. Cheers Toerless On Thu, Jan 29, 2026 at 02:14:17PM -0800, Mahesh Jethanandani wrote: [Adding OPSAWG in compliance with Section 8 of RFC 2026] To: [Richard Barnes/OPSAWG] From: Mahesh Jethanandani, Operations and Management Area Director Date: January 29, 2026 Subject: Response to the appeal regarding the adoption of draft-ietf-opsawg-rfc5706bis This memorandum serves as a formal response to the appeal submitted on January 22, 2026, regarding the OPSAWG’s adoption of draft-ietf-opsawg-rfc5706bis ("Guidelines for Considering Operations and Management of New Protocols and Extensions”) [1]. The appeal requests either the removal of Section 3 (which proposes mandatory "Operational Considerations" sections for all IETF specifications) or the revocation of the document's adoption, citing that such a cross-IETF process mandate is outside the OPSAWG charter and should be handled in a venue like GENDISPATCH. For the full text of the appeal, see below. I will note that it is not Section 3, but the Abstract itself that mandates the requirement for the “Operational Considerations” section, but for the purposes of this appeal, I will continue to refer to it as being in Section 3. After a thorough review of the OPSAWG charter [2], the history of the document, the adoption call proceedings[3], and IETF procedural norms (RFC 2026 and RFC 2418), I am denying the appeal. My reasoning is outlined below. 1. Charter Scope and Historical Context The appellant argues that OPSAWG’s charter does not permit the creation of cross-IETF process mandates. While the OPSAWG charter focuses on "operational and management RFC proposals," it also functions as the primary venue for operational best practices. The document in question is a "bis" version of RFC 5706. RFC 5706 itself was an Informational document providing guidelines for IETF specifications and a product of OPSAWG. It is standard practice for a Working Group (WG) to maintain and update documents within its specific area of expertise. As the primary repository for IETF operational expertise, OPSAWG is the most technically competent venue to refine what "operational considerations" should entail. 2. Adoption is a Starting Point, Not a Final Decision A common misunderstanding in IETF process appeals is the weight given to "adoption." The adoption of a draft as a WG item signifies that the WG believes the document is a useful starting point for work and that the topic is within the scope of interest. Adoption does not imply that every sentence in the draft—including the "mandatory" language in Section 3—has reached consensus, nor does it mean the current text is the final form. The WG process is specifically designed to refine these requirements. Denying adoption at this stage would prematurely halt a discussion that the OPSAWG community has expressed a clear interest in pursuing. 3. Cross-Area Consensus and Procedural Safeguards The appellant correctly notes that a single Working Group cannot unilaterally impose mandates on the entire IETF Stream without IETF-wide consensus. However, the IETF process has built-in safeguards for this: • IETF Last Call: If the document eventually progresses toward publication as a BCP, it must undergo an IETF-wide Last Call. This is the stage where other Areas and the broader community evaluate the "mandatory" nature of the requirements. • IESG Review: The IESG (including Directors from all Areas) must approve the document. If the document imposes unreasonable burdens on other Areas, the IESG is responsible for ensuring those concerns are addressed. The use of GENDISPATCH is a path to determine where work could be done, but the work cannot be done in GENDISPATCH. As stated above, since this document is a “bis” version of an existing WG document, it would make sense to continue the work there. Many guidelines that affect the whole IETF—such as Security Considerations (RFC 3552) or IANA Considerations (RFC 8126)—were developed in specialized venues or by experts in those specific domains before seeking IETF-wide approval. 4. Addressing the Remedy Sought The appellant’s request to remove Section 3 as a condition of adoption would essentially be the AD dictating the technical content of a draft before the WG has had the opportunity to deliberate on it. This would undermine the WG process. The proper venue for the appellant’s concerns is the OPSAWG mailing list. If there is no consensus within the IETF to make these sections mandatory, the text will necessarily be softened to "recommendations" or "guidelines" during the document's lifecycle or during the IESG review. Conclusion The OPSAWG delegate, acting on behalf of the chairs, since the chairs are co-authors on the document, acted within his discretion to adopt a document that updates an existing operational guideline. The concerns regarding the document's scope and its "mandatory" language are substantive technical and procedural points, but they are points that should be resolved through the development of the document and the subsequent IETF-wide review process, rather than by blocking the work at the adoption stage. I encourage the appellant and other interested parties to engage actively in the OPSAWG discussions to ensure the final language reflects a broad community consensus. The appeal is denied. Respectfully, Mahesh Jethanandani, Operations and Management Area Director [1] https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/ [2] https://datatracker.ietf.org/wg/opsawg/about/ [3] https://mailarchive.ietf.org/arch/msg/opsawg/wZ5aa34iWZfFZUDSTkcq_ixdiDM/ On Jan 22, 2026, at 11:31 AM, Richard Barnes <[email protected]<mailto:[email protected]>> wrote: Hi Mahesh, That content was already provided, in that format, in our initial email to the chairs and our email to you. I have pasted it below for your convenient reference. We do not have any problem with this disagreement being public. Our initial emails were private to allow the chairs discretion in what to make public. Best, --Richard Action Being Challenged: OPSAWG's adoption of draft-ietf-opsawg-rfc5706bis as a working group document. Grounds for Appeal: Section 3 of draft-ietf-opsawg-rfc5706bis ("Documentation Requirements for IETF Specifications") establishes mandatory documentation requirements for all IETF specifications, stating that "All Internet-Drafts documenting technical specifications advanced for publication as IETF RFCs must include an 'Operational Considerations' section." This IETF-wide scope appears to be a primary goal of the document. The adoption call stated that the document "introduces a requirement to include an 'Operational Considerations' section in new RFCs in the IETF Stream" [1]. Benoit’s announcement of the new draft described "the ideal end goal to have 'Manageability Considerations' section all IETF drafts" and included "Generalize the approach in RFC6123/Manageability Considerations Section in all IETF Specs" [2]. This scope is clearly outside OPSAWG's charter. The OPSAWG charter defines the group as a venue for "operational and management RFC proposals" that are "not in the scope of an existing OPS WG and do not justify the formation of a new WG." The charter's example deliverables—YANG modules, IPFIX extensions, maintenance of concluded WG documents—are operational specifications, not cross-IETF process mandates. Despite an explicit goal of a cross-IETF process requirement, the document was adopted by OPSAWG alone without apparent discussion of whether the working group has authority to impose requirements on all other IETF areas and working groups. Defining mandatory documentation requirements for all IETF specifications is a process matter that affects every working group. Such requirements have historically been established through IESG statements or BCPs developed with explicit cross-area consensus. In today’s IETF, that would mean going through something like GENDISPATCH to get cross-area visibility and consensus. Remedy Sought: Either: 1. Remove Section 3 from the document, limiting the draft to guidance for OPS area work rather than mandatory IETF-wide requirements; or 2. Revoke the adoption of the draft, and potentially pursue the work in a more appropriate venue (e.g., GENDISPATCH). [1] https://mailarchive.ietf.org/arch/msg/opsawg/wZ5aa34iWZfFZUDSTkcq_ixdiDM/ <https://mailarchive.ietf.org/arch/msg/opsawg/wZ5aa34iWZfFZUDSTkcq_ixdiDM/ [2] https://mailarchive.ietf.org/arch/msg/opsawg/lo47d71oPF-XRuBOxXuiggmuW_s/ <https://mailarchive.ietf.org/arch/msg/opsawg/lo47d71oPF-XRuBOxXuiggmuW_s/ [snip] Mahesh Jethanandani [email protected]<mailto:[email protected]> _______________________________________________ OPSAWG mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> -- --- [email protected]<mailto:[email protected]> -- --- [email protected]<mailto:[email protected]> _______________________________________________ OPSAWG mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
