**Session Date/Time:** 23 Jul 2026 14:30 # [OPSAREA](../wg/opsarea.html) ## Summary The OPSAREA session at IETF 126 focused on cross-area collaboration and improving operational standards through running code and stricter protocol boundaries. Key areas of discussion included: * Coordination with the Transport Area on operational considerations for deploying protocols over QUIC. * The creation of an Acceptable Use Policy (AUP) to handle the recent explosion of ICMP extension proposals. * Bridging the gap between IRTF research (NMRG) and IETF operations (NMOP) for emerging topics such as digital twins and AI. * A proposal to mandate multiple independent implementations prior to publishing specifications to reduce the need for subsequent "bis" documents. * An introduction to the newly transferred working groups, Domain Connect (DECON) and Registration Extensions (REGEXT). * An overview of the IAB IP Geolocation Workshop and the launch of Raven, an open-source BGP routing validation tool. ## Key Discussion Points ### Area Updates & Administrative Items * **Chairs' Introduction:** Med Boucadair and Mahesh Jethanandani opened the session. Med highlighted the focus on cross-area collaboration (Transport, Internet, IRTF). * **TDD Chairs:** New chairs have been appointed for the TDD working group. * **RPKI Directory:** The chairs are considering creating a new directory for RPKI to ensure consistency across multiple working groups. A scoping call has been initiated in SIDROPS. * **AIOPS:** Mahesh Jethanandani announced an AI-NETOPS side meeting. A community-driven repository and [AIOPS Wiki](https://wiki.ietf.org/en/group/ops/aiops) are available to guide IETF work on the topic. * **Guidelines for Operations and Management:** Joe Clarke requested comments on [draft-ietf-opsawg-rfc5706bis](https://datatracker.ietf.org/id/draft-ietf-opsawg-rfc5706bis-00.html) on the `opsawg` mailing list. The draft has already inspired several authors to add operational considerations sections. --- ### Working Group Introductions (DECON & REGEXT) * **Domain Connect (DECON):** Peter Thomason introduced the newly chartered working group. DECON is an application-level protocol allowing SaaS providers to request automatic DNS record configuration in customer zones via templates. The group focuses on transitioning change control from GoDaddy/the community to the IETF while maintaining backward compatibility. * **Registration Extensions (REGEXT):** James Galvin introduced the working group, which recently transitioned from the ART area to the OPS area. REGEXT covers extensions to Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP). Current hot topics include RDAP extensions, EPP over QUIC/HTTP, and domain variant support for Internationalized Domain Names (IDNs). --- ### IP Geolocation Workshop Report Tommy Pauly presented the report on the IAB IP Geolocation Workshop held in December 2023 ([3. IP Geo Workshop Report](https://datatracker.ietf.org/meeting/126/materials/slides-126-opsarea-ip-geo-workshop-report-00)). * **Current State:** Geolocation is highly prevalent (used for localization, CDNs, regulatory compliance, and age verification) even though IP addresses were not designed to carry geographic meaning. Current mechanisms include RFC 8805 (CSV Geofeeds) and RFC 9632. * **Key Issues:** Assumptions that an IP maps to a single user or static location fail in modern architectures like satellite networks (e.g., Starlink), cellular roaming, and privacy proxies. Database updates suffer from lag, taking weeks or months to propagate to content operators. * **Discussion & Chat:** * Ondřej Surý and Joe Clarke discussed mobile roaming challenges, where data is often tunneled to the home country, causing incorrect localizations. * John Scudder and Reshad Rahman noted the tension between implicit tracking and explicit, user-consented location signals (like browser Geolocation APIs). * Tommy Pauly noted that regulatory pressures are driving the need for more secure, explicit, and verifiable geolocation mechanisms. --- ### Foo over QUIC: Operational Considerations Per Andersson initiated a discussion on running application protocols over QUIC ([4. foo-over-QUIC: Operational Considerations for when using QUIC as transport protocol](https://datatracker.ietf.org/meeting/126/materials/slides-126-opsarea-4-foo-over-quic-operational-considerations-for-when-using-quic-as-transport-protocol-00)). * **Operational Challenges:** QUIC is not a simple drop-in replacement for TCP. Key issues include congestion control tuning (Cubic vs. BBR), zero-RTT security profiles, the lack of a standardized socket API, and difficulty with middlebox/firewall inspection due to packet encryption. * **Call Home:** Kent Watsen noted that reversing a QUIC connection for NETCONF/RESTCONF Call Home is technically difficult. He suggested that an update to RFC 8071 (Call Home) might solve it for specific management use cases rather than attempting to define a generic "reverse QUIC" mechanism. * **Collaboration:** Benoit Claise and Lucas Pardue (QUIC WG Co-Chair) noted that the Webtransport (WIT) area plans to publish a wiki checklist/guideline for implementing protocols over QUIC. The Ops community was encouraged to coordinate and add Ops-specific layers (e.g., telemetry vs. control plane needs) to this wiki. --- ### Proposals for ICMP Extensions: Operational Motivations & Rationale Ron Bonica discussed the proliferation of ICMP extension proposals ([5. Proposals for ICMP Extensions: Operational Motivations & Rationale](https://datatracker.ietf.org/meeting/126/materials/slides-126-opsarea-5-proposals-for-icmp-extensions-operational-motivations-rationale-00)). * **The Issue:** The ICMP extension structure has led to an explosion of drafts proposing to query node IDs, link power consumption, and more. Proposed drafts like "XPM" define generic queries that can request almost any layer-1 to layer-3 attribute over ICMP. * **Operational Concerns:** ICMP is unreliable, easily spoofed, rate-limited, and unauthenticated. It is not designed to serve as a generic management or telemetry transport. * **Proposed Solution:** Establish an Acceptable Use Policy (AUP) for ICMP to define a strict boundary on what information is appropriate for ICMP and what transport requirements (e.g., authentication, reliability) are needed. * **Discussion:** * Jen Linkova supported the AUP, noting that management and monitoring data should be out of scope for ICMP if the nodes are within the same administrative domain. * Andrey Chilikin volunteered to help coordinate the drafting of this AUP. * Éric Vyncke and Joe Clarke discussed whether simple UDP-based queries would be a safer alternative to ICMP for operational probes. --- ### IRTF/IETF OPS Transfer between NMRG/NMOPS Thomas Graf discussed bridging the gap between research in the Network Management Research Group (NMRG) and operations in Network Management Operations (NMOP) ([6. IRTF/IETF OPS Transfer between NMRG/NMOPS](https://datatracker.ietf.org/meeting/126/materials/slides-126-opsarea-irtfietf-ops-transfer-between-nmrgnmops-00)). * **Closing the Gap:** Technologies like Digital Twins, Intent-Based Networking, and AI agents have rapidly moved from pure research to practical deployment by operators. * **Collaboration:** Thomas proposed running a joint session between NMRG and NMOP to align documents and encourage research experiments at IETF hackathons. * **Discussion:** Joe Clarke and Jéferson Nobre supported trying a joint meeting. Joe Clarke commented on the Model Context Protocol (MCP), stating that while it is a useful interaction layer for AI agents, it does not replace protocols like NETCONF. --- ### Mandating Multiple Implementations Job Snijders presented on the value of requiring running code as a standard part of the IETF process ([7. Mandating multiple implementations as ingredient for success](https://datatracker.ietf.org/meeting/126/materials/slides-126-opsarea-mandating-multiple-implementations-as-ingredient-for-success-00)). * **The Proposal:** Working groups in the Ops area should consider adopting charter requirements mandating at least two independent, interoperable implementations before publishing an RFC (similar to IDR, SSHM, and SIDROPS). * **Benefits:** Mandating running code before Working Group Last Call saves years of overall standardization time by avoiding the need for "bis" documents to fix design oversights, catches protocol ambiguities early, and validates readability. * **Discussion:** * John Scudder noted that requiring implementations can sometimes cause a single large specification to be broken up into several smaller specs implemented at different rates, potentially increasing RFC editor overhead. * Thierry suggested that using the Experimental track could also help fast-track running code. * Andrey Chilikin, Stefan, and Peter van Dijk supported the push for independent implementations, sharing experiences where writing code uncovered missing details in drafts. --- ### Raven: An Open-source BGP Routing Validation Tool Ritesh Mukherjee presented Raven, a Go-based open-source tool designed to correlate live BGP routes from BMP with RPKI validation states (Origin Validation and ASPA) ([8. Raven, an Opensource BGP Routing Validation Tool](https://datatracker.ietf.org/meeting/126/materials/slides-126-opsarea-raven-an-opensource-bgp-routing-validation-tool-00)). * **Capabilities:** Raven bridges the tool gap between BGP monitoring (BMP) and RPKI validators. It processes live BMP streams and RTR data to evaluate origin and path validity in real time, classifying path anomalies like leaks (Path Suspect) or origin failures (Origin Invalid). * **Lessons Learned:** * AS Set handling in ASPA validation remains structurally underspecified. * RTR v2 ASPA PDU negotiation with validators (such as Routinator) is production-ready. * **Discussion:** John Scudder advised that developers should deprecate and ignore AS Set handling entirely, as AS Sets are being actively stamped out of the routing ecosystem. ## Decisions and Action Items * **Action Item:** Establish a small volunteer group (led by Andrey Chilikin and Ron Bonica) to draft an **Acceptable Use Policy (AUP) for ICMP** to regulate and scope future ICMP extension proposals. * **Action Item (Cross-Area Coordination):** The Ops community will coordinate with the Webtransport (WIT) area to utilize and populate their planned **QUIC implementation checklist/wiki** with Ops-specific transport and telemetry requirements. * **Decision:** The chairs and interested contributors agreed to pursue a **joint NMRG and NMOP session** at a future meeting to coordinate network digital twins and AI-driven management. ## Next Steps * **Review Call:** All participants are requested to review [draft-ietf-opsawg-rfc5706bis](https://datatracker.ietf.org/id/draft-ietf-opsawg-rfc5706bis-00.html) on the `opsawg` mailing list to help push it to Working Group Last Call. * **Raven Feedback:** Operators running ASPA-covered paths are encouraged to test Raven and provide feedback on GitHub regarding ASPA path validation and BMP logging extensions.