**Session Date/Time:** 05 Nov 2025 18:15 # EODIR ## Summary This EODIR session provided updates and facilitated discussions on several key IETF operational areas. The primary topics included proposed revisions to the IETF Notewell and associated guidance for chairs, significant Datatracker tooling changes for working group adoption calls (which generated considerable community feedback and IESG apologies for process missteps), ongoing initiatives by the RFC Production Center (RPC) to streamline document processing and tools, and a major evolution in YANG module versioning rules to formally allow and track non-backwards compatible changes. Finally, a brief update was given on the revision of RFC 2418 concerning working group procedures. ## Key Discussion Points * **IETF Notewell Updates and Guidance** * The goals for the new Notewell text were presented: emphasize behavior, use direct quotes, simplify language, merge lists, and replace BCP references with individual RFC references. * ISG guidance instructs chairs to display the Notewell at the start of every session, preserve its text, and avoid creating additional policy slides. * A short example script (30-60 seconds) was created for chairs to use, based on existing Notewell text, to ensure consistent messaging. * Feedback included concerns about the Notewell's length and readability, particularly for non-native English speakers. Issues were raised regarding the practice of asking for affiliations at the microphone, potentially conflicting with the IETF's individual participation model, and perceived inconsistencies with RFC 8179 regarding IPR statements. * As an interim measure, a large placard of the Notewell with a QR code linking to RFCs has been placed at registration. * A sense of those present indicated a strong preference for a much shorter, reminder-focused Notewell presentation in meetings, as participants generally agree to IETF policies upon registration. However, it was noted that for interim meetings without a formal registration checkbox, the Notewell slide serves as the primary agreement reminder. * **Datatracker Tooling for Working Group Adoption Emails** * Eric (IESG liaison) initiated this segment by apologizing for the lack of communication and explanation surrounding recent changes to the Datatracker's functionality for working group adoption calls. The intent behind the changes was to improve transparency and record these calls in the document history for IESG process review. * Robert (tools team) acknowledged community feedback and identified problems with the initial implementation. A development branch has been deployed, featuring capabilities to preview and edit the adoption call message. * Known issues include the need to edit content in three separate places and a bug where backing off an adoption call incorrectly leaves the document in a "candidate for adoption" state. * **Significant concerns were raised by working group chairs**: * The changes were perceived as imposing a mandatory formal call for adoption process, potentially altering established working group practices where documents might become WG documents by charter or chair judgment without such a formal call. Eric clarified the *intent was not to change the underlying process*, but to provide better tracking *if* a formal call is made. * The IESG was strongly criticized for implementing tooling changes that impact working group chairs without prior consultation. Pete Resnick emphasized that the IESG does not *require* adoption calls to be tracked in the Datatracker and that such significant changes to chair workflows should involve community input *before* implementation. * The IESG acknowledged the process misstep and apologized for not consulting the community ahead of time. * **RFC Production Center (RPC) Updates** * Jean Mahoney (RPC Director) provided updates on several initiatives: * **Author Intake Form**: A questionnaire for authors upon document submission has proven highly effective, with authors responding promptly (average 3 days, half within 1 day). * **Cramdown RFC**: The RPC began accepting Cramdown RFC as an input format on September 1st, piloting with five documents per month. * **Internal Tools and Q Management**: The RPC is updating its queue management system, incorporating internal version control using GitHub. * **Optional GitHub for Auth48**: A pilot program is starting this month to allow authors to conduct the Author 48-hour review phase using GitHub. A single pull request with all RPC edits will be created in a new repository, although final approval will still be via email. * **Publication Statistics**: The RPC has experienced a high volume, having published more documents this year than in all of 2023, with a significant influx in Q1 2024 (3200 pages, 74 documents). The RPC has 12 employees. * **New Website Beta**: A beta version of the revamped RFC Editor website is available for review (requires Datatracker login), and feedback is encouraged. * A question was raised regarding the archiving of GitHub discussions from the Auth48 process to ensure a resilient historical record, which the RPC will consider. * **YANG Module Versioning Evolution** * Joe presented on behalf of the YANG community regarding significant evolutions to YANG module update rules, aiming to align with current practices and industry needs. * **Key changes include**: * Formally allowing non-backwards compatible (NBC) changes in YANG modules, while still encouraging their minimization. * Designating changes in a YANG node's `status` to `obsolete` as an NBC change. * Introducing new extension statements for YANG. * Adding a new `rev-non-backwards-compatible` tag to the revision statement to explicitly mark NBC changes. * Adopting a SemVer-like versioning scheme (e.g., 3.2.0) for YANG modules. * Providing new guidance for selecting revisions for module imports. * Introducing a new filename format incorporating the SemVer revision. * These changes address the reality that NBC changes are already occurring in IETF and vendor modules, improving transparency for module users and facilitating more rapid YANG authoring. * **Tooling Updates**: Plans are underway to update `pyang`, `rfcstrip`, and `libyang` to support these new rules. Much of this work is already complete. The updated tooling will be integrated into the Datatracker's existing YANG linting process. * Three related Internet-Drafts are being held at the Auth48 phase pending the completion and deployment of these tooling updates. * **RFC 2418 Revision** * Dave Thaler provided a brief update on the ongoing revision of RFC 2418, which details working group procedures. Dave Skunazi is leading this effort. * Discussions are taking place on the `procon` mailing list and via GitHub. A recent meeting established guiding principles for differentiating between documented policy and common practices. ## Decisions and Action Items * **Notewell**: * Feedback on the Notewell's length, readability, guidance on affiliations, and IPR consistency will be taken under advisement for future revisions. * The use of physical Notewell placards with QR codes at registration will continue. * **Datatracker Tooling for WG Adoption Emails**: * Robert and the tools team will address the identified issues (editing in multiple locations, "candidate for adoption" state bug) within the next 1-1.5 weeks. * A community-wide review of the fixed development deployment will occur before general production rollout. * The IESG will update the working group chair wiki with instructions and encourage the appropriate use of the new tooling. * **RFC Production Center**: * The use of the author intake form and the Cramdown RFC pilot (5 documents/month) will continue. * The pilot for optional GitHub for Auth48 will proceed as planned. * The RPC will investigate mechanisms for archiving GitHub comments from the Auth48 process to ensure a robust historical record. * **YANG Module Versioning Evolution**: * Non-backwards compatible changes in YANG modules are now formally permitted and will be explicitly marked using a new `rev-non-backwards-compatible` tag. * YANG modules will adopt a SemVer-like versioning scheme. * Tooling (`pyang`, `rfcstrip`, `libyang`) will be updated and integrated into the Datatracker's YANG linting process. * Three related Internet-Drafts will be held at the Auth48 phase pending the completion and deployment of the necessary tooling updates. ## Next Steps * **Notewell**: Ongoing internal discussion within IESG and IAB to refine the Notewell's in-meeting presentation and content based on community feedback. * **Datatracker Tooling**: Fix identified bugs, conduct a community review of the fixes, and deploy to production. The IESG will update guidance and promote tool usage. * **RFC Production Center**: Continue with pilot programs, develop new editing software, and complete the RFC Editor website revamp. Further work on archiving GitHub interactions is planned. * **YANG Module Versioning**: Complete tooling updates and integration into Datatracker. Advise YANG doctors on the new rules. Advance the three associated drafts once tooling is ready. * **RFC 2418 Revision**: Community members are encouraged to review ongoing draft revisions on the `procon` mailing list or via GitHub and provide feedback. --- **Session Date/Time:** 07 Nov 2025 13:15 # EODIR Session ## Summary The EODIR (External Outreach and Communications) session opened with an administrative note clarifying its status as an official IETF activity, rather than a side meeting, and the name change from EMODIR. The session provided updates on the Sisters in Engineering (SISTERS) program, new participant initiatives, IETF outreach activities, the Working Group Chairs (WGC) Forum, and the Guides program. A significant portion of the discussion centered on challenges and potential improvements related to GitHub usage within the IETF, specifically concerning documentation, training, and the diverse workflows employed by different working groups. ## Key Discussion Points * **EODIR Administration:** * EODIR (formerly EMODIR) is now an official IETF open meeting, not a side meeting, reflecting its status as an official IETF activity. * Outreach beyond the IETF is within the purview of the IAB, with EODIR coordinating independent activities. * The session emphasized that participants drive activities; "Who's going to do it? It might be you." * **SISTERS Update:** * Feedback from the IETF 123 "bridging perspective event" (workshop for SISTERS members and IETF leadership) was mixed on content but positive overall for fostering interaction. It was deemed a successful experiment. * At IETF 124, two low-key networking events (breakfast and lunch) were well-attended (approx. 30-40 people each). * Discussion confirmed SISTERS' core mission to focus on retention and improving the IETF experience for attendees. The mailing list will be used to discuss clearer actions and measurement methods. * **New Participant Program Update:** * 43% of IETF 124 attendees were new participants (first-time or attended 1-4 meetings), indicating high engagement and return rates. * A thorough review of the revised all-day new participant program will be conducted after a full year of operation. Initial assessment suggests it's "right on par." * The Thursday social hour saw exceptional leadership attendance and strong networking among new participants and leadership. Attendance was 35 (compared to 52 in Madrid). * Suggestion to gather new participants' areas of interest (e.g., SEC, ART, Routing) to facilitate more efficient connections, potentially via the guides program or quick connection sessions. * The post-lunch "Advanced Topics" presentation on Sunday was revised to "Power of the Community," focusing on community creation and handling disputes/appeals. Early indications suggest better retention and engagement. * Feedback on program length was mixed; some found it too long, suggesting breakpoints for choice. The program already advises it's a long agenda and can be completed over multiple meetings. * Challenges in providing "easy to understand" session pitches without conflicting with participants' desire to read drafts. * Rotating presenters for the new participant program is planned for future meetings (e.g., Vienna). * **Outreach Activities:** * Recent outreach activities included: Ripe and CAPF events (European region), an IAB panel, Eric Vyncke's cooperation working group panel, ICANN (leadership focus, future community engagement), Lacknick, Trinidad ISOC regions, and events in India (school of governance, youth IGF). * EODIR provides resources on its wiki, including a standard IETF overview presentation template customizable for different audiences (IG, general, students, researchers). * Emphasis that outreach is for anyone in the community, not just leadership, with EODIR offering support. * A comment highlighted that people struggle to find these resources; a broader email to the community about their availability was suggested. Resources were recently moved to the top of the outreach page for visibility. * Discussion about specific outreach to students, particularly for Hackathons, noting existing presentations and the value of Hackathons as an entry point. IRTF also does some academic outreach. * Visible IETF presence at other events (e.g., Ripe) sends a positive message, even if immediate effects aren't seen. * **Working Group Chairs Forum Update:** * The WGC Forum had a full agenda with no specific actions or training mandated. * Continuing conversations revolved around the "Note Well" and the distinction between required processes and available tools. * A helpful email with pointers to resources was sent to the WGC list by the Secretariat (Greg and Cindy), which was well-received as a timely reminder. This is part of a plan to send such emails periodically and to new WGCs. * **Guides Program Update:** * 23 matches were made for IETF 124 (3 remote), which is slightly higher than average. * Efforts are ongoing to make matches earlier, though participants often sign up late. * Michelle and Jay plan to follow up with guides and new participants (via mini-surveys) to gather feedback and express thanks. * Suggestions for guides included: meeting at the end of the week for wrap-up questions, and advising on preferred asynchronous communication methods (e.g., Slack, WhatsApp). WhatsApp was specifically noted for not being on the current list of suggested methods. * The newcomer social hour typically focuses on leadership interaction, but potential for guide attendance was discussed. * 72 new participants attended Quick Connections, with 37 experienced IETFers. * A separate Slack channel for new participants (e.g., "new participants 124") was proposed. * An observation was made about a cohort of 16 participants from Brazil who received multi-year funding, highlighting the positive impact of such initiatives. * **Tutorials / GitHub Discussion:** * A virtual interim meeting on September 17th discussed GitHub usage, identifying two primary user groups (experienced vs. IETF-specific users) and different roles (contributors, reviewers, chairs). * Three potential near-term outcomes were identified for GitHub documentation: 1. "Organize your workspace" for WGCs (Rich had initial content, but progress is slow). 2. Better pointers to Martin Thompson's tooling/authoring resources and pull request review guides. 3. Greg and Deb are working on general GitHub documentation. * A concern was raised that the problem isn't a lack of information, but difficulty in finding clear and concise documentation. * The "Welcome to the Chair Role" initiative (the secretariat email) was recognized as helpful but doesn't fully address all GitHub needs. * A participant is working on documentation for Martin Thompson's repo template and plans a pull request. * A key unanswered question remains the relationship between mailing lists and GitHub for IETF consensus and discussion, given that many participants don't track GitHub issues regularly. * Concern was expressed that the current approach to GitHub documentation and workflows might be too narrow, gathered from a small group. A broader conversation with working group chairs and authors is needed to identify actual requirements for tutorials/documentation. * Reluctance to generate "tons more content" given existing volume; a "Cliff Notes" version and a communication strategy are needed. * GitHub training needs to be practical and hands-on, acknowledging that expert trainers can sometimes move too fast. Different user types (authors, chairs, issue filers) have different needs. * A significant concern was raised that GitHub (a commercial product) is becoming a "big barrier to entry" due to its complexity and inconsistent workflows across working groups. Authors are reportedly hesitant to use it. * The idea of a "GitHub help desk," possibly at Hackathons, was suggested, similar to how Datatracker help is provided. * Roman Gen identified a challenge with a help desk for GitHub given the lack of normative workflows; working groups often have bespoke processes for tagging, triaging, etc. This makes generic advice difficult and risks confusing participants about the "right" way to do things. * A suggestion was made to add pointers on each working group's GitHub page to relevant wiki documentation. * There is no general "participant" wiki equivalent to the "authors" or "chairs" wikis, which might need consideration. * Emphasis on encouraging chairs to assist participants with their specific working group's GitHub process and to communicate that there is no single normative process for GitHub usage. ## Decisions and Action Items * **SISTERS:** The core mission to concentrate on retention and improving the IETF experience was reaffirmed. The group will discuss clearer actions and measurement methods on the SISTERS mailing list. * **New Participant Program:** The "Advanced Topics" presentation on Sunday was changed to "Power of the Community." A thorough review of the revised all-day program will be conducted. * **Outreach:** The Secretariat (Greg and Cindy) will draft and send a broader distribution message about the availability of IETF outreach resources. * **Working Group Chairs Forum:** The plan to periodically send helpful resource pointers to the WGC list and new WGCs was affirmed. * **Guides Program:** * Michelle will conduct mini-surveys with guides and new participants after the meeting to gather feedback. * The list of suggested communication methods for guides will be updated to include WhatsApp. * The Guides program will explore ways to thank guides more formally and regularly. * **GitHub Documentation/Tutorials:** * Greg and Deb will continue their work on GitHub documentation. * Rich will do a pull request on Martin Thompson's repo template to attach relevant documentation. * The EODIR group will encourage volunteers to step forward to work on GitHub documentation and tutorials. * A GitHub "help desk" at future Hackathons was supported by some participants. ## Next Steps * **SISTERS:** Continue discussions on the mailing list for clearer actions and measurements related to their core mission. * **New Participant Program:** * Conduct the thorough review of the all-day program, including follow-up discussions with ADs. * Brainstorm ideas for better identifying and connecting new participants with areas of interest. * Consider rotation of presenters for the new participant program at upcoming IETF meetings. * **Outreach:** Distribute the broader email communication regarding the availability of outreach resources. * **Guides Program:** * Conduct follow-up surveys with guides and new participants. * Consider sending a reminder email to guides mid-week to encourage end-of-week check-ins with mentees. * Explore the feasibility of inviting guides to the newcomer social, balancing it with leadership interaction. * Further discussion on a dedicated Slack channel for new participants. * **GitHub Documentation/Tutorials:** * Solicit more volunteers for specific GitHub documentation and tutorial development. * Organize a broader conversation (e.g., with WGCs, authors, RFC Interest Group) to gather comprehensive requirements for GitHub tutorials and documentation, moving beyond the EODIR group's initial brainstorming. * Explore strategies for communicating existing content in a more concise and discoverable "Cliff Notes" format. * Continue to discuss the GitHub help desk concept, particularly its implementation at Hackathons, while acknowledging the challenge of inconsistent working group workflows. * Encourage working group chairs to clearly communicate their specific GitHub workflows and offer direct assistance to participants. * Further ponder the relationship between mailing lists and GitHub for IETF discussions and consensus.