[Last-Call] Re: Last Call: <draft-ietf-opsawg-rfc5706bis-09.txt> (Guidelines for Considering Operations and Management in IETF Specifications) to Best Current Practice

[Jeffrey Haas <[e-mail]>]

This e-mail documents my objections to the publication of this document 
as an RFC.  It repeats points raised during earlier discussions of the 
document's contents.

While I find that the document contains a significant amount of 
accumulated wisdom, it will result in another bit of bloat-ware being 
attached to the IETF RFC process.

The authors did move much of the "checklist" discussion into a less 
normative bit of work. However, I still find it likely that future 
directorates and IESGs will take the presence of such a list and turn it 
into part of the mandatory process.

On the somewhat charitable thought that the future IESG doesn't put us 
into checklist purgatory, many of the underlying considerations are 
still problematic for document streams regularly produced by many 
working groups.  Such considerations manifest typically when a set of 
reviewers are participating in that technology perhaps for the first 
time as part of last call processes.  A perennial example are security 
reviewers who, not finding the entire landscape of a particular security 
space addressed in a small "patch" document, nor prior considerations 
they find satisfactory in prior RFCs, request the entire landscape be 
addressed in the patch document.

Similar considerations may apply for elements such as YANG models that 
may not have sufficient base coverage in the working group to request 
the related extension in the patch document.

These issues are often summarized as "please stop asking us to boil the 
ocean to make this one cup of tea".

A secondary consideration, especially for patch documents, is in the 
service of document paucity.  Simple and otherwise clear proposals often 
find themselves lost in a sea of boilerplate. As noted in other last 
call comments from TSV, when a feature may serve multiple operational 
scenarios, the simple ideas may find themselves suffocated by trying to 
address every reviewer's idea of what is an appropriate operational 
scenario.

I will make particular note of the long-standing pattern when drafts 
accumulate use case scenarios during initial working group discussion - 
only to have later reviewers, directorates, and the IESG ask for the use 
cases to be stripped.  I find this pattern likely to be repeated for the 
plethora of operational scenarios many of our features are likely to 
address. (I would offer the work leading to RFCs 9871 and 9832 in IDR as 
examples.)

I'm supportive of this document being progressed if the mandatory and 
prescriptive nature of the contents is moved to be advisory procedure.

-- Jeff

On 10/8/26 22:35, The IESG wrote:
> The IESG has received a request from the Operations and Management Area
> Working Group WG (opsawg) to consider the following document:
>    'Guidelines for Considering Operations and Management in IETF
>     Specifications'
>    <draft-ietf-opsawg-rfc5706bis-09.txt> as Best Current Practice
>
> The IESG plans to make a decision on this document in the coming weeks, and
> solicits last-call comments. Please send substantive comments to the
> [e-mail] mailing list, with [e-mail] copied, no later than
> 2026-10-22.  Please retain the beginning of the Subject line to facilitate
> automated sorting.
>
> Abstract
>
>     New Protocols and Protocol Extensions are best designed with due
>     consideration of the functionality needed to operate and manage them.
>     Retrofitting operations and management considerations is suboptimal.
>     The purpose of this document is to provide guidance to authors and
>     reviewers on what operational and management aspects should be
>     addressed when writing documents in the IETF Stream that document a
>     specification for New Protocols or Protocol Extensions or describe
>     their use.
>
>     This document obsoletes RFC 5706, replacing it completely and
>     updating it with new operational and management techniques and
>     mechanisms.  It also updates RFC 2360 to obsolete mandatory MIB
>     creation.  Finally, it introduces a requirement to include an
>     "Operational Considerations" section in new RFCs in the IETF Stream
>     that define New Protocols or Protocol Extensions or describe their
>     use (including relevant YANG Models), while providing an escape
>     clause if no new considerations are identified.
>
>
>
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5706bis/
>
>
> No IPR declarations have been submitted directly on this I-D.
>
>
> The document contains these normative downward references.
> See RFC 3967 for additional information:
>      rfc9940: Some Key Terms for Network Fault and Problem Management (Informational - Internet Engineering Task Force (IETF) stream)
>
>
>
>
> _______________________________________________
> IETF-Announce mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]