**Session Date/Time:** 03 Nov 2025 17:00 # RTGAREA ## Summary The RTGAREA open meeting addressed two primary topics: the ongoing revision of RFC 5706 to integrate "operational considerations" as a mandatory section in new IETF RFCs, and an open discussion regarding the Routing Open Source Initiative (ROSI). An experimental BGP Directorate was also briefly introduced. The discussion on ROSI revealed overwhelming community support for its continuation, emphasizing its role in fostering implementations and bridging the gap between specifications and running code. ## Key Discussion Points * **BGP Directorate Experiment**: An experimental initiative to establish a team of experienced BGP implementers and operators. This team would proactively review BGP-related drafts early in their development cycle to improve specification quality and provide timely feedback, aiming to address issues typically identified much later. Feedback was solicited on whether this directorate should be proactive in chasing drafts or respond to requests. * **Operational Considerations (RFC 5706 Revision)**: * **Objective**: To update RFC 5706, providing comprehensive guidance for authors on how to effectively incorporate operational and management considerations into IETF specifications from the initial design phase. * **Core Proposal**: Introduce a new requirement for all RFCs in the IETF stream to include an explicit "Operational Considerations" section, akin to the existing "Security Considerations" section. * **Scope & Target Audience**: The revised draft serves as guidance primarily for *authors*, not for reviewers or Area Directors. Specific reviewer guidance is being moved to an Ops Directorate wiki to prevent rigid "checkbox" reviews. * **Routing Area Specific Concerns**: * **Avoiding Checkbox Documentation**: The intent is to encourage authors to *think about* operational aspects, not to enforce a rigid documentation template or allow reviews to fail based on not ticking specific boxes. * **Small Protocol Extensions**: ADs should not block new work on protocol extensions simply because the base protocol is deficient in operational considerations. Extensions should be as manageable as possible within existing constraints, and any base protocol deficiencies should be acknowledged without halting new development. * **Community Feedback**: * Concerns were raised about potentially overstepping the scope of existing Operations Working Groups or compartmentalizing operational aspects that are normative and should be integrated into the core protocol specification (e.g., configuration parameters, timers, diagnostics). * Suggestions included providing concrete examples within the guidance and clarifying its relevance for implementers. * The utility of a "cheat sheet" or checklist (similar to RFC 8126 for IANA considerations) was discussed, balancing clarity with the avoidance of overly prescriptive, rigid requirements. * A proposal was made to make the "Operational Considerations" section a mandatory placeholder in draft Markdown templates to encourage author engagement. The AD acknowledged this but expressed a preference for user-friendly, non-mandatory tools (e.g., an IETF website "vending machine" for guidance and boilerplate) to enhance document quality and readability. * **Routing Open Source Initiative (ROSI)**: * **Background**: Initiated approximately 10 years ago (after IETF 97), ROSI is an informal, community-driven effort to facilitate the implementation of IETF standards and bridge the gap between protocol specifications and running code. It traditionally met in dedicated lunch slots during IETF meetings. * **Recent Issue**: The recent withdrawal of the ROSI meeting room raised questions about IESG's support for open source engagement within the IETF. * **Community-Articulated Value**: * **Implementation Focus**: Directly supports the IETF's core mission of "running code" by providing a venue for quick implementations and collaborative development. * **Direct Implementer-Author Interaction**: Offers a crucial forum for implementers to highlight operational challenges, discuss implementation details, and provide direct feedback on drafts to authors. * **Low Barrier to Entry**: Its unstructured, low-prep format (no formal slides or presentations) fosters organic discussions, connections, and problem-solving among participants. * **Cross-Project Collaboration**: Facilitates networking and mutual issue resolution among various open source projects, even those with overlapping functionalities. * **Educational Outreach**: Serves as an accessible entry point for universities and students to engage with IETF work and open source development. * **Mailing List Utilization**: The `rtg-open-source` mailing list was highlighted as an important channel for broader open-source related Q&A and announcements to prevent information fragmentation. * **Best Practice Sharing**: Provides a forum for discussing and disseminating best practices, such as using open source reference implementations for protocol validation. * **Consensus**: There was overwhelming community interest and support for the continuation of ROSI, emphasizing the need for a dedicated, recurring meeting slot (preferably a consistent time like a lunch break) and an assigned room, with minimal formal structure beyond that. ## Decisions and Action Items * **BGP Directorate**: The Routing Area Directors will continue to explore the BGP Directorate experiment, taking into account feedback regarding proactive engagement versus on-demand review. * **Operational Considerations Draft**: The draft is currently undergoing an adoption poll within the Ops Area Working Group. * **Routing Open Source Initiative (ROSI)**: The Routing Area Directorate acknowledges the strong community interest and support for ROSI. They commit to processing the feedback received and working towards re-establishing a dedicated, periodic meeting slot for ROSI. ## Next Steps * **Operational Considerations**: * IETF community members are strongly encouraged to participate in the adoption poll on the Ops Area Working Group mailing list and provide detailed feedback or suggested text for the RFC 5706 revision. * Volunteers are requested to "alpha test" the document by attempting to incorporate an operational considerations section into their ongoing drafts, providing feedback on the clarity and effectiveness of the guidance. * **Routing Open Source Initiative (ROSI)**: * The Routing ADs will analyze the collected feedback to determine the optimal approach for supporting and reinstating the ROSI meeting, prioritizing the securing of a consistent meeting room and time slot. * The `rtg-open-source` mailing list should be actively used by the community for all relevant open-source discussions and announcements within the IETF.