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 ?
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]
