Let me also comment on the technologial goals and how to achieve them,
I am changing the Subject to make sure it is clear that i would NOT like
to see the discussion about better RFCs to be shortcut by the formal appeal
process, but that as far as process is concerned, we are going by what
Mahesh wrote: Let the actual IETG WG and following IETF consensus process
work determine what happens.
I don't think that security is such an outstanding topic that it
would deserve an exclusive formal mandatory slot in RFCs and others do
not. I think management and operations are equally important. It's
already bad enough that i have been (at work, not IETF) through enough
technology
development efforts that ended up cutting off management and ops
aspect of a new technology below the line resulting in products
to be delivered to customers that where not useable. We should do
better than that in IETF whereever we can.
Sec:
I do agree that security considerations are often? not as good as
they should be. Maybe SEC AD should more often ask "have co-authors
read rfc3552 and applied it to the security considerations section".
But i am also not sure if rfc3552 is the best it could be after now
being 22 years old. But i need some more time (independent of this
rfc5706bis effort) to have more well founded technical opinion about
that. I just wrote a fairly long sec section on a draft and wanted to
go back to rfc3552 and see how well it matches all the categories of it.
Mandatory Ops/Mgmt section:
I also don't think that a simple "all IETF proocol specification
MUST have an Ops/Mgmt section" to be the best possible outcome of
the WG process we are starting now. I think the starting point
really is "all IETF protocol specification MUST have Ops/Mgmt
documentation".
- I think there are cases where the document is better put into
other sections of the same document than their own "Mgmt Section".
- I think in some other cases, it may be more appropriate to have
one (or more) separate management docs. And we could for example
force the protocol RFC to be experimental until those dependent
docs are finished as RFC.
- In some (good) cases we even have IETF OPS WGs that take on the
operational aspects. That of course makes it even more important
to consider how to deal with such cross-document work-split.
Example: PIM/MBONED. Or SPRING/SRv6OPS. Funny how Multicast
had this model for decades and unicast not ;-))
I had more detailed thoughts re how/where to put the desired documentation
and will bring to the WG lisst if/where i haven't done so far.
The fact that security sections turn out to be less good than they
could be in cases is, i think also a good reference for attempting to improve
on our Ops/Mgmt documentation:
IETF RFCs are not a formal requirements hell.
We're all hopefully well meaning humans trying to do the best we can, and
the job is complex, and we may often fall short. So you shouldn't be
too worried of creating some "Ops/Mgmt formal requirement hell"
(which i think was what was beyond the appeal).
Instead, like in Sec, we're trying to improve but handle it
in execution pragmatically to the best of our capabilities. Yes,
we would like to have more Sec and Ops resources to help with these
important aspects but we may not have them always. Doesn't mean we should
not document the best we can at any point in time.
Cheers
Toerless
On Fri, Feb 06, 2026 at 04:14:56PM +0000, Rob Wilton (rwilton) wrote:
> 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]>
>
--
---
[email protected]
_______________________________________________
OPSAWG mailing list -- [email protected]
To unsubscribe send an email to [email protected]
