I am supportive of adopting this work. I have significant concerns about the current form of this work. I articulated some of this during the IETF 123 rtgarea meeting.
At a high level, the document covers the exact sort of things one would want out of a new protocol. Thus, as considerations about your considerations, I think it's great. However, these sort of efforts eventually get distilled into onerous boilerplate checklists that - when satisfied - bloat the document that contains them without making the document better. "Did you? yeah, no, but..." I nod in the direction of the already tedious YANG considerations and their bit of useless boilerplate that should simply say "YANG considerations document RFC-blah, version foo apply - go read that". On a broader note, I find the current document likely to exacerbate issues for existing protocols we regularly see in security review - especially by the IESG. That pattern is "this thing I want covered by this considerations section doesn't exist... and there's no such thing in the base protocol specification. Please address this". The "this" all too often turns into a request to create broader considerations than the small bit of patch-work that the document in question may be doing. A trivialized form of this is "where's your YANG module?" Well, if your base document doesn't have one, requiring one in the patch document is unreasonable. My specific requests for the long term outcome from this document can be made in two points: 1. Avoid excess boilerplate and checklists. For operational considerations, especially on patch documents, the bloat overwhelms reader comprehension. 2. Discuss the considerations for "patch" documents better. Perhaps that conversation moves to "well, your document series should have these things" and work might be chartered to update the considerations for the series. -- Jeff > On Oct 21, 2025, at 4:52 PM, Alvaro Retana via Datatracker <[email protected]> > wrote: > > > Subject: Call for adoption: draft-opsarea-rfc5706bis-06 (Ends 2025-11-11) > > This message starts a 3-week Call for Adoption for this document. > > Abstract: > New Protocols or 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 defining New Protocols or Protocol Extensions. > > This document obsoletes RFC 5706, replacing it completely and > updating it with new operational and management techniques and > mechanisms. It also introduces a requirement to include an > "Operational Considerations" section in new RFCs in the IETF Stream. > > File can be retrieved from: > https://datatracker.ietf.org/doc/draft-opsarea-rfc5706bis/ > > Please reply to this message keeping [email protected] in copy by indicating > whether you support or not the adoption of this draft as a WG document. > Comments to motivate your preference are highly appreciated. > > Authors, and WG participants in general, are reminded of the Intellectual > Property Rights (IPR) disclosure obligations described in BCP 79 [2]. > Appropriate IPR disclosures required for full conformance with the provisions > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. > Sanctions available for application to violators of IETF IPR Policy can be > found at [3]. > > Thank you. > [1] https://datatracker.ietf.org/doc/bcp78/ > [2] https://datatracker.ietf.org/doc/bcp79/ > [3] https://datatracker.ietf.org/doc/rfc6701/ > > > > _______________________________________________ > OPSAWG mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
