**Session Date/Time:** 06 Nov 2025 19:30

# OPSAREA

## Summary

The OPSAREA session featured updates from several working groups (IVY, MBONED, SIDEROPS, OPSDIR) covering their current status, recent achievements, and ongoing challenges. Key discussions included the growing need for multicast solutions in live streaming, the complex rechartering process for SIDEROPS, and initiatives to improve the quality and efficiency of operational reviews across the IETF. Significant time was dedicated to exploring a proposed merger of the IPPM and BMWG working groups, and a wide-ranging discussion on the potential reorganization of DNS-related working groups to address issues of workload, scope, and efficiency. The session concluded with a summary of a side meeting on cybersecurity risks and mitigations.

## Key Discussion Points

*   **IVY Working Group Update:**
    *   The IVY (Inventory YANG) working group focuses on network inventory, encompassing hardware, software, physical location, and entitlements/licenses.
    *   Work includes correlating inventory with topology models for troubleshooting and network knowledge.
    *   The core model is nearing Working Group Last Call, with augmentation drafts for software, location, and entitlement.
    *   Initially chartered for a single draft, the WG now has five drafts, with more anticipated.
    *   The WG recently decided to expand its charter to formally include passive inventory.

*   **MBONED Working Group Update:**
    *   The MBONED working group's primary focus is multicast operations and deployment, particularly for live streaming and "multicast to the browser."
    *   Recent progress includes adopting a multicast security draft, and progressing YANG models for multicast and AMT to Working Group Last Call.
    *   **Side Meeting on Multicast for Live Streaming:**
        *   A side meeting highlighted the exponential growth of live streaming events (tens of millions of concurrent viewers) which is straining CDNs and network operators.
        *   Live streaming has unique demands (low latency, step-function join rates) distinct from on-demand video.
        *   The meeting aimed to bridge awareness between network-layer multicast solutions (e.g., TreatyN, RFC 9706) and streaming-layer innovations (MABR, MAUD, UDP, Quick extensions).
        *   Concerns discussed included adaptive bitrate, encryption, access control, ad insertion, reliability, and multicast over Wi-Fi (with a real-world successful deployment by Aircast presented).
        *   A sense of those present indicated strong interest and a belief that multicast's time may have come again due to traffic scale.
        *   The discussion suggested enhanced coordination between MBONED and MOPS working groups might be beneficial given the streaming focus.

*   **SIDEROPS Working Group Update:**
    *   SIDEROPS is dedicated to securing inter-domain routing, primarily through the RPKI (Resource Public Key Infrastructure) framework.
    *   A recent example demonstrated how RPKI deployment could mitigate prefix hijack attacks affecting root DNS servers in minutes.
    *   Current work involves updating RPKI-related protocols, such as 8210bis (for validator-router communication) and the ASPA (AS Path Attestation) mechanism, which faced a temporary block at the IESG but is now progressing.
    *   Future work includes exploring the Eric Protocol for more efficient RPKI information sharing among relay points.
    *   **Rechartering Discussion:**
        *   A key challenge is the existing charter, which currently does not permit standard track documents, leading to an IESG block on a recent publication.
        *   The working group decided against a quick charter fix, opting for a full rechartering to formally incorporate an "implementation policy" (requiring at least two interoperable implementations for protocol specifications) and other previously wiki-tracked decisions.
        *   Discussion arose regarding the interpretation of "two interoperable implementations," particularly for client-side specifications.

*   **OPSDIR Working Group Update:**
    *   OPSDIR's mission is to enhance operational awareness across the IETF, provide early feedback on drafts, and assist ADs.
    *   The group has 48 members and processes numerous review requests (42 since last IETF).
    *   Challenges include a high number of incomplete reviews (10 out of 42), particularly for security-related documents that often lack sufficient operational consideration sections.
    *   The review cycle averages 17 days, exceeding the 14-day target, and a small number of reviewers carry a disproportionate workload.
    *   To address this, OPSDIR has introduced a new review template highlighting 8 core operational questions (3 management, 5 operational) that draft authors should consider, integrated into the Meetecho review process.
    *   A call was made for more reviewers with diverse operational expertise, particularly in security, routing, Internet, and transport areas.

*   **RFC 5706 Update: Guidelines for Operations and Management Considerations:**
    *   An effort is underway to update and obsolete RFC 5706 (published 2009), which provides guidelines for operational and management considerations in IETF specifications.
    *   The current RFC is considered outdated (e.g., references MIP), addressed too many audiences, and its core guidance was often lost.
    *   The new draft (`draft-ietf-opsawg-rfc5706-update`) refocuses the audience on protocol/extension designers (draft authors).
    *   It removes specific management technologies, addresses boilerplate concerns (allowing authors to state "no new operations and management requirements" if applicable), and incorporates new topics like SACOPs, OAMC impacts, information models, and AI tooling.
    *   The document, initially AD-sponsored, is now seeking adoption as an OPSAWG working group document. Alvaro (a Routing Area AD) is the document shepherd.
    *   Feedback from the Routing Area included concerns about potentially blocking protocol extensions if their base protocol lacks operational considerations, and a desire for tooling to automate section inclusion. It was clarified the document aims to guide authors, not impose process blocks.

*   **IPPM and BMWG Merger Proposal:**
    *   A proposal was presented to merge the IPPM (IP Performance Metrics) and BMWG (Benchmarking Methodology) working groups.
    *   The rationale cited included long-standing WGs with outdated charters (since 2018), significant overlap in performance metrics and measurement methods, and declining participation/contribution in BMWG.
    *   Proposed benefits include a single point of contact for cross-SDO collaboration, development of common building blocks (e.g., security frameworks), and increased contributor/reviewer bases.
    *   A key distinction identified is IPPM's focus on production networks versus BMWG's on laboratory environments, though cross-over work exists.
    *   Open issues include defining a common framework, leveraging the performance metric directorate, dispatching roles, and the approach to reviewing metrics defined by other SDOs.
    *   During discussion, concerns were raised about whether the proposal reflects community input, the relevance of benchmarking to QoE work, and the IETF's role in reviewing other SDOs' work. It was also noted that merging might not resolve the underlying issue of insufficient review volume.

*   **DNS Working Group Reorganization Discussion:**
    *   An initiative by Wes Hardaker (at the request of Med, AD) is collecting feedback on how DNS-related work is organized within the IETF.
    *   Concerns include the varying structure and operation of DNS WGs, the heavy workload of DNSOP, protocol development occurring within an operations group, slow specification development, and challenges in drawing the right expertise to focused WGs.
    *   Potential solutions on the table include reorganizing/rechartering WGs, doing nothing, or entirely new approaches.
    *   Key questions for discussion:
        *   Where should work get done (e.g., clear split between operational and protocol aspects)?
        *   How should new work be dispatched (e.g., a dedicated DNS dispatch group)?
        *   How to manage the sheer quantity of DNS work and rate-limit it to available volunteers?
        *   How to improve efficiency and coordinate information sharing across DNS-related activities?
    *   Feedback from participants varied:
        *   Some suggested splitting DNSOP into distinct operational and protocol development groups, potentially aligning with the Ops and Internet Areas, believing a clear line could be drawn.
        *   Others expressed concern that splitting could lead to increased information silos and a continued need for individuals to follow multiple groups, suggesting the quantity of work itself is the primary problem.
        *   A suggestion was made to require running code for draft adoption to reduce the volume of un-implemented RFCs.
        *   One participant proposed a three-way split: operations, protocol development, and application-specific use of DNS.
        *   The discussion highlighted the challenge of defining "DNS" within the IETF, its operational reality, and the appropriate scope of IETF responsibility versus other organizations.
        *   Several participants agreed that the current state of DNS work, particularly the workload on DNSOP chairs and mailing list volume, is unsustainable and needs a "new start" or different approach.

*   **Cybersecurity Risks Side Meeting Summary:**
    *   A side meeting with about 50 participants discussed current cybersecurity risks (e.g., ransomware, supply chain, memory safety) and mitigations.
    *   There was an acknowledgement that network operations and security are intertwined disciplines.
    *   Effective mitigations (e.g., resilience, avoiding single points of failure, incentivizing network segmentation and secure backups) heavily rely on operational expertise.
    *   The meeting reinforced the motivation for a "security operations draft" to foster collaboration between network operations and security.

## Decisions and Action Items

*   **SIDEROPS Working Group:**
    *   **Decision:** The SIDEROPS working group will proceed with a full rechartering effort to formally allow standard track documents and to include an "implementation policy" (requiring at least two interoperable implementations for protocol specifications) and other previously wiki-tracked decisions.
    *   **Action Item:** The SIDEROPS chairs will refine the interpretation of the "two interoperable implementations" requirement.
*   **OPSDIR Working Group:**
    *   **Decision:** A new review template for operational considerations, including 8 core questions, has been integrated into the Meetecho review completion process.
*   **RFC 5706 Update Draft:**
    *   **Decision:** The draft `draft-ietf-opsawg-rfc5706-update` will be put forward for adoption as an OPSAWG working group document.
*   **IPPM/BMWG Merger Proposal:**
    *   **Action Item:** The chairs of IPPM and BMWG, along with the proposers, will schedule an interim meeting to discuss the draft charter and continue collecting feedback from the mailing lists.
*   **DNS Working Group Reorganization:**
    *   **Action Item:** Wes Hardaker will continue collecting feedback on DNS WG organization until the end of the month, then form a small, impartial group to analyze it and make recommendations to the IESG by February, with an IESG decision anticipated around IETF 125.
*   **Cybersecurity Risks Side Meeting:**
    *   **Action Item:** A mailing list will be set up for continued discussion on cybersecurity risks and mitigations.

## Next Steps

*   **IVY:** Continue working towards Working Group Last Call for the core model and progressing augmentation drafts.
*   **MBONED:** Explore increased coordination with the MOPS working group regarding streaming-related topics.
*   **SIDEROPS:** Engage in the rechartering process, address questions around the implementation policy, and continue work on RPKI protocol updates.
*   **OPSDIR:** Actively seek more reviewers with diverse operational expertise to distribute workload and improve review efficiency; encourage authors to utilize the new operational consideration template.
*   **RFC 5706 Update:** Encourage community review of the `draft-ietf-opsawg-rfc5706-update` document as it progresses towards adoption in OPSAWG.
*   **IPPM/BMWG Merger:** Participate in the interim meeting and mailing list discussions to provide feedback on the proposed joint charter and open issues.
*   **DNS Working Group Reorganization:** Provide feedback to Wes Hardaker via the mailing list (`dns@ietf.org`), anonymously, or in direct conversation. The discussion will continue to explore optimal structures for DNS-related work, including managing work quantity and coordination.
*   **Cybersecurity Operations:** Engage with the new mailing list and OPSAREA working group activities related to the security operations draft and broader cybersecurity discussions.
*   **General:** Authors are encouraged to start including operational consideration sections in their new documents, potentially referencing the ongoing work to update RFC 5706.