On Thu, Jan 29, 2026 at 4:03 PM Toerless Eckert <[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]> 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] > > > > > > > > > > > > > > > _______________________________________________ > > OPSAWG mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > > -- > --- > [email protected] >
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
