**Session Date/Time:** 06 Nov 2025 13:15

# TOOLS

## Summary

This session provided an overview of recent activities and future directions for the IETF Tools Team. Key highlights included the formal administrative move of the team to the IETF LLC, significant progress on the RFC Editor modernization project with a target deployment before IETF 125, and substantial infrastructure improvements focusing on scalability and security. Discussions centered on increasing project visibility and community engagement, the team's planned increased reliance on client-side JavaScript for web tools and associated telemetry, and the ongoing work to enhance the security of authoring tools, particularly concerning arbitrary input.

## Key Discussion Points

*   **Introductions and Logistics**
    *   Team members (Robert Sparks, Jennifer Richards, Rudy Matz, Kessel Ratnäyke, Matt Holloway) introduced themselves.
    *   Reminded participants of the IETF "note well" policy.
    *   Mentioned communication channels: `toolsdiscuss@ietf.org` (publicly archived) and `toolshelp@ietf.org` (non-public for operational issues).
    *   Noted the availability of a beta version of the upcoming RFC Editor website for feedback. Feedback on any aspect (styling, functionality, design decisions) is welcome. The RFC Editor website is designed for "consumers of RFCs," potentially leading to different design choices than IETF participants might expect for other applications.

*   **Last Year's Activities and Accomplishments**
    *   **Administrative Change**: The Tools Team formally moved its administrative connections to the IETF LLC.
    *   **Infrastructure Improvements**:
        *   Completed a second cloud provider transition to Azure, gaining more control and faster hardware.
        *   Maintained a Digital Ocean environment for rapid failover.
        *   Conducted security audits of the Data Tracker and new cloud infrastructure, with identified issues addressed.
        *   Diversified session recording availability (YouTube, Cloudflare Stream) and implemented immediate offline archiving.
    *   **RFC Editor Modernization (Primary Focus)**:
        *   For the last four months, efforts have been heavily focused on this project, including the RFC Editor website, replacement of RPC workflow tooling, and building a new toolchain for editors.
        *   The ultimate goal is to move from a centralized Unix system to a distributed editing environment with source control and a transparent workflow system.
        *   First version of these systems is expected to be in production before IETF 125.
    *   **Other Projects**: Continued work on Data Tracker, IETF website, and xml2rfc, but at a significantly reduced velocity due to the RPC modernization focus. Expect a return to higher velocity once the RFC Editor Modernization Suite goes online.

*   **Current Focus and Roadmap**
    *   **RFC Editor Modernization**: Ensuring RFC 10K support by March, with XML editing well in hand. Remaining work includes editing support tools, workflow scripts, and core database/public-facing application replacement.
    *   **Scalability Refactoring**: Moving artifacts to blob storage (e.g., Cloudflare R2), using edge processes and workers to serve content directly, significantly reducing load on the origin server.
    *   **Community Issues & Requests**: Ongoing response to issues and feature requests, progress on ISG dashboards (limited by missing data in Data Tracker), specification for new liaison tooling, and updates to email control for balloting/last calls.
    *   **Future Projects**: Identified a large backlog of projects, including replacing entire applications (e.g., Mailman 3 integration with Data Tracker). These are waiting for the RPC modernization to wind down.

*   **Discussion Topic 1: Providing Visibility into Project Roadmap**
    *   **Community Questions**: How can the community track feature development (start/deploy dates, alignment with priorities), and where is the overall project plan?
    *   **Community Priorities**: Currently derived from GitHub issues, Tools calls, and Tools Discuss list. A new process could provide a clearer indication of community urgency/satisfaction.
    *   **Proposed Solutions**: Evaluating additional resources, moving towards a more formal prioritization and estimation process, and exploring project management tools like Zenhub (a GitHub overlay).
    *   **GitHub Voting**: A question was raised about upvoting/downvoting GitHub issues; currently not supported, with text comments being the existing mechanism.

*   **Discussion Topic 2: Increased Use of JavaScript in Web Tooling**
    *   The new RFC Editor website leverages client-side JavaScript with tiered rendering (origin data, server-side rendering, browser tailoring).
    *   Future interactive features will increasingly require JavaScript to be enabled in browsers.
    *   The community's general sentiment is "begrudgingly okay" with this, but awareness needs to be raised for those who may have JavaScript disabled.
    *   **Telemetry**: Browser-side JavaScript will "phone home" with crash logs and errors. The intent is to use **entirely self-hosted services** (e.g., Grafana, Tempo, OpenTelemetry) for this telemetry, addressing privacy concerns about third-party analytics.
    *   **Browser Compatibility**: Analysis of old browser usage is ongoing, visible via Matomo and Cloudflare user agent data. The new RFC Editor website requires a "moderately modern browser"; content (RFCs themselves) remains accessible to very old browsers, but navigation and interactive features may not.

*   **Discussion Topic 3: Security of Author Tools**
    *   A security audit highlighted risks with applications processing arbitrary input from anonymous users (e.g., `xml2rfc`, IDnits).
    *   Specifically, `xml2rfc` was shown to potentially include content from internal API endpoints (this has been addressed by limiting visibility).
    *   **Need for Stronger Sandboxing**: Critical to implement stronger resource sandboxing for such applications (limiting threads, memory, file system access, and data store interactions) to prevent denial-of-service or information disclosure.
    *   **Services under Review**: The automatic PowerPoint to PDF converter at the Data Tracker is an example of a service being re-evaluated due to security risks from arbitrary input and community feedback on its necessity.
    *   **XML Submission**: When users submit XML, it needs to be fully self-contained. Tooling is required to help authors create this, which itself will need to be sandboxed. This will lead to safer XML processing on the Data Tracker side.
    *   **Dependency Security**: Dependabot is used on GitHub for dependency alerts, with weekly team review and action. Rich commended the team's swift response to audit findings.

*   **Open Mic / Community Engagement**
    *   A concern was raised by leadership about meeting community priorities and getting sufficient community involvement.
    *   **Suggestions for engagement**:
        *   Consistently point users to the overall project roadmap when they raise small issues.
        *   Provide regular (even brief) updates at Working Group Chairs lunches, with links to the current roadmap.
        *   Consider better onboarding for new participants and leadership (WG Chairs, ADs) on how to use the IETF tools.
        *   Distinguish between bug fixes for long-time users (who often have "pet peeves") and large architectural work. Emphasize prioritization and technical debt.
        *   Explore dedicated monthly calls or sessions focused on "how to use" specific tools/features for Q&A and feature introductions.
        *   Provide structured documentation/updates, perhaps like a "monthly dose of Data Tracker updates."
    *   **PDF Generation for Internet Drafts**: Karsten pointed out persistent problems with the `pdf-i` variant for Internet Drafts (PDFs generated from HTML versions). He suggested stopping `pdf-i` generation, especially for documents with RFC XML sources, or ideally, entirely.
    *   **PDF for Review**: The challenge is that printed browser PDFs are not suitable for review, as reviewers need a document that looks like an RFC. There was a discussion about pushing submitters for Markdown/XML instead of plain text, and whether PDFs of older RFCs (for BIS drafts) are necessary given that text diffs are common.

## Decisions and Action Items

*   The Tools Team has formally moved its administrative connections to the IETF LLC.
*   The RFC Editor Modernization Suite (website, workflow tooling, new toolchain) is targeted for production deployment before IETF 125.
*   The team will use entirely self-hosted services (e.g., Grafana, Tempo, OpenTelemetry) for browser-side telemetry to address privacy concerns.
*   The team will conduct more formal conversations with the community regarding the necessity and security implications of services like the PowerPoint to PDF converter and the requirements for self-contained XML submissions.
*   The team will explore more formal project prioritization and estimation processes, including evaluating tools like Zenhub, to improve project visibility and community communication.
*   Investigate strategies for improving community involvement and leadership onboarding in tools usage, possibly including dedicated "how-to" sessions or structured documentation.

## Next Steps

*   Complete the development and deployment of the RFC Editor Modernization Suite before IETF 125.
*   Implement stronger sandboxing mechanisms for authoring tools that process arbitrary user input.
*   Continue engagement with the community to make decisions on the future of services like the PowerPoint to PDF converter and to define tooling and requirements for fully self-contained XML submissions.
*   Develop and implement improved project management practices and reporting to enhance transparency and provide better estimates for future projects.
*   Actively pursue strategies for increased community engagement, including improved roadmap communication and structured onboarding for IETF leadership and participants.
*   Further discussions regarding PDF generation policies for Internet Drafts, particularly the `pdf-i` variant and the long-term acceptance of text-only submissions.