Thanks for your review, Jeff. I don’t exactly agree with your assessment that the document will cause more boilerplate. See below.
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. [JMC] I don’t recall the authors talking about the “patch” case in great detail, though it was discussed after you raised it at 123. However, my take on this is that it is not incumbent on a “patch” draft to define the entirety of management and operations details for a whole protocol if such definition doesn’t already exist. My (our?) hope is that this draft will cause areas and WGs to reflect on the need to fill such gaps if there is one in the base. 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. [JMC] What I would expect of the “patch” doc in the case where the base (or a related RFC) did do a good job of defining operational and management considerations for the protocol is to extend said YANG module. Regardless, the “patch” doc considerations could list interesting metrics to collect or logs to generate for what is defined in that document. Joe > 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]
