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