Hi Joe, Thanks for the quick reply - the NETCONF/RESTCONF polling example makes it much easier to picture the flood risk.
Cheers, Bo From: Joe Clarke (jclarke) <[email protected]> Sent: Saturday, October 25, 2025 11:57 PM To: Wubo (lana) <[email protected]>; Alvaro Retana <[email protected]>; [email protected]; [email protected]; [email protected] Subject: Re: [OPSAWG]Call for adoption: draft-opsarea-rfc5706bis-06 (Ends 2025-11-11) 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. [JMC] If you have examples of protocols being developed where the data "hungriness" of things like generative AI training or heavy inference would be relevant, please suggest some text. I was thinking of polling-centric protocols such as NETCONF and RESTCONF if they were to be provided to things like MCP servers could result in management plane saturation. Techniques such as list pagination or rate-limiting with backoff can help to alleviate some of the load. Joe Thanks, Bo -----Original Message----- From: Alvaro Retana via Datatracker <[email protected]<mailto:[email protected]>> Sent: Wednesday, October 22, 2025 4:52 AM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
