Thanks again, Bo. Some of the authors discussed this a bit more today, and we hope we can close this down with two separate things.
We plan to add a "check list" as an Appendix to the document. This will be a brief reminder of the topics that authors should think about, together with pointers into the main body of text. We also note that several IETF Areas have assembled lists of common issues that their reviewers encounter. We will suggest to ADs that, if they need to vary the advice given by our draft, they have a good place to document it. Hoping that closes this issue. Thanks, Adrian -----Original Message----- From: Wubo (lana) <[email protected]> Sent: 27 October 2025 13:26 To: [email protected] Cc: 'Alvaro Retana' <[email protected]>; [email protected]; [email protected]; [email protected] Subject: RE: [OPSAWG]Re: Call for adoption: draft-opsarea-rfc5706bis-06 (Ends 2025-11-11) Hi Adrian, Thanks for the quick reply and for the pointer to #66 — I can see the effort to broaden the scope. Re: "is there really a difference?" -my feeling is that although the base questions are the same, the focus may differ per domain. Giving each area a one-line template—"PCE-style" like RFC 6123 did for Routing area —makes life easier. Thanks, Bo -----Original Message----- From: Adrian Farrel <[email protected]> Sent: Saturday, October 25, 2025 8:30 PM To: Wubo (lana) <[email protected]> Cc: 'Alvaro Retana' <[email protected]>; [email protected]; [email protected]; [email protected] Subject: RE: [OPSAWG]Re: Call for adoption: draft-opsarea-rfc5706bis-06 (Ends 2025-11-11) Hi Bo, Thanks for the support and your thoughts. The authors have been concerned about exactly the point you make: too much focus on only OPS and RTG. For Security, we have section 4.6 (Impact on Security Operations), section 5.8 (Security Management), and section 9 (Security Considerations). With special thanks to Michael P for help with the SecOps work. For applicability at "other layers in the stack" we have been trying to collect input across the board, and you can see this anchored at https://github.com/IETF-OPSAWG-WG/draft-opsarea-rfc5706bis/issues/66 This has helped us bolster the "other layer" material, although it still seems that our examples are RTG-biased. The idea of having separate sections on the different layers (such as separate templates) is interesting, but... - Is there really such a difference (any difference) between the requirements for Operational Considerations across the layers? - Would someone like to suggest some text? Cheers, Adrian -----Original Message----- From: Wubo (lana) <[email protected]> Sent: 25 October 2025 09:48 To: Alvaro Retana <[email protected]>; [email protected]; [email protected]; [email protected] Subject: [OPSAWG]Re: Call for adoption: draft-opsarea-rfc5706bis-06 (Ends 2025-11-11) Hi all, I support adopting draft-opsarea-rfc5706bis. It is very useful. As an ops-dir reviewer I like seeing an "Operational Considerations" section in every new Standards-Track RFC. It shows the authors have thought through operational and management aspects in a systematic way. It seems to me the present draft is written mostly from the OPS and Routing Area points of view, with examples drawn mainly from those domains. If we could add a short "Area-Specific Operational Considerations" part with ready-made templates for Routing, Applications, Security, Transport, etc.? That way each area can quickly pick what fits. The document is presently quite long and the check-list is extensive, making it hard to spot the absolute must-dos. If it is possible, could you highlight the questions that cannot be ignored so readers see them at once. The draft is great useful for OPS-area work. The new chapters show current IETF best practice and the YANG parts are very clear. The new §6.1 on AI Tooling is helpful today. If we could add a few concrete examples of which new protocols or extensions will use that section, it would be even better. Thanks, Bo -----Original Message----- From: Alvaro Retana via Datatracker <[email protected]> Sent: Wednesday, October 22, 2025 4:52 AM To: [email protected]; [email protected]; [email protected]; [email protected] Subject: [OPSAWG]Call for adoption: draft-opsarea-rfc5706bis-06 (Ends 2025-11-11) 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] _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
