On Thu, Jan 29, 2026 at 4:35 PM Toerless Eckert <[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. The IAB (prior to RFC 9280) and now the RSWG and RSAB (post RFC 9280) are responsible for determining what is in an RFC. So yes, I suppose the IETF could decide to create standards and publish them outside of the RFC series, in which case a Security Considerations section might not be needed. -Ekr > > 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]> 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] > > > > > -- > --- > [email protected] >
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
