**Session Date/Time:** 09 Sep 2025 18:00

# [TOOLS](../wg/tools.html)

## Summary

This TOOLS Working Group session covered significant progress and future plans across various IETF tooling initiatives. Key topics included the impact of upcoming Yang Semantic Versioning on existing tools and DataTracker, a discussion on the appropriate use of paid (proprietary) libraries in IETF tools, updates on the Red and Purple RPC tooling deployments, and a proposal for a regular maintenance window. The meeting also provided updates on the Azure transition, IDs 3 development, and several mail system improvements including welcome/challenge messages and static IP block removal.

## Key Discussion Points

*   **RFC 10K & RPC Tooling Update:**
    *   The goal remains to deploy Red and Purple into production before the spring IETF to support the RFC 10K event.
    *   The team is exploring deploying Red earlier, even before full Purple deployment, which would require temporary infrastructure.
    *   Red has been demonstrated at an RPC community call and will be available at a workstation at the RPC desk during the upcoming IETF. Plans are underway to make the staging site more broadly accessible.

*   **Yang Semantic Versioning's Effect on Tooling:**
    *   Joe Clark provided an update on three drafts nearing IESG approval related to Yang module versioning, Yang semantic versioning, and a new filename convention.
    *   The responsible AD, Mahesh, has flagged these drafts as requiring tooling support.
    *   The plan is to progress these drafts to RFCs and push upstream tooling updates:
        *   **ZIM:** Code for extracting Yang modules with semantic versioning is already merged (work in progress PR by Joe Clark was merged by Inar). It includes flags for `at revision date` and `pound sim` (semantic version).
        *   **Pyang:** Validation code for Yang semantic versioning is written but not yet pushed northbound. It will automatically check for `yang simver` if `d-itf` is present and validate it.
        *   **Libyang & Yang Lint:** Updates are also desired. Libyang is more challenging as it's a compiled C suite, and DataTracker uses an older `2.x` version while `3.x` is current; building from source might be necessary. Pyang validation might be sufficient initially.
    *   **DataTracker Integration:**
        *   The TOOLS team expressed a desire for DataTracker to incorporate new versions of tools (Pyang, potentially libyang/yang lint) to enable automated Yang validation.
        *   Robert pointed out custom DataTracker checks for file naming conventions might also need updates for the new semantic file name.
        *   Backward compatibility: Existing Yang modules will still be accepted, but new revisions of drafts will be flagged if they don't include a `Yang simver` on their latest revision, per new guidelines (if adopted). This would appear as an error in DataTracker's Yang validation.
    *   **IANA Publication:**
        *   The IANA process for publishing modules would need to adjust to handle both revision date and Yang semantic versioning (potentially as symlinks) and update their version of ZIM with new flags.
        *   Gene mentioned that RPC production uses `RFC strip` and `Pyang`, not ZIM directly. `RFC strip` would also need updates, which Joe Clark intends to investigate.
    *   **Collaboration:** Joe Clark plans to reach out to the NETMOD WG for assistance with tools development. Mahesh recommended reaching out to IANA separately and directly. Hackathon discussion for RPC production tools was suggested.

*   **Use of Paid Libraries in IETF Tools:**
    *   Jay initiated a discussion on open source libraries that also offer paid, proprietary components (e.g., builders, enhanced feature sets).
    *   **Paid Builder Tools:** Generally not a concern, treated as developer productivity tools. However, complex hand-coding might disadvantage community contributors.
    *   **Proprietary Components:** These are problematic as community members cannot be expected to purchase them, making contribution difficult.
    *   **Proposed Distinction:** Consider allowing proprietary components for tools exclusively built and run by the IETF (e.g., rsceditor.org website), but not for tools expected to be built/run by the community (e.g., DataTracker).
    *   **Community Input:** Robert emphasized the need for practical examples to assess trade-offs rather than setting a philosophical principle.

*   **Tools Roadmap:**
    *   The current GitHub project board for the roadmap was deprecated as it failed to provide transparency and was not maintained.
    *   New visualizations are planned to separate "what we're working on now" from "when this feature is expected to be in production."

*   **Monthly Maintenance Window:**
    *   Nick requested a regular maintenance window for Kubernetes and database updates, which will involve some downtime for critical applications like DataTracker.
    *   **Proposal:** Target North American Thursday afternoons.
    *   **Downtime:** Kubernetes major upgrades could cause 10+ minute outages for interdependent applications (DataTracker, www.ietf.org, mail archives due to shared file system). Shorter outages (seconds) for others.
    *   **Communication:** Pre-announcements for outages longer than a few minutes. Russ suggested warnings for WG chairs scheduling interims during planned windows.
    *   Roman emphasized the importance of announcing *possibility* of outages for all maintenance, even short ones, to increase community confidence in tooling availability. Discussion on appropriate announcement channels (IETF-announce, tools-discuss, status.ietf.org) for frequent small deploys vs. larger updates.

*   **Azure Transition Update:**
    *   The transition to Azure is complete, realizing anticipated benefits, including improved DataTracker speed.
    *   The security review by Doyian SEC for DataTracker and the new cloud infrastructure is nearing completion, with a final report expected soon. Some initial issues found (related to XML to RFC security) have already been addressed.
    *   **Security Report Sharing:** The general plan for security reviews is to share with a restricted group: IESG, tools liaison, SEC Area ADs, IETF Chair, and potentially a couple of tools team members. This approach received no objections.

*   **IDs 3 Tooling Update:**
    *   One critical issue remains, after which it will be integrated into the submission workflow.
    *   **Rollout Plan:** Initially, IDs 3 will run non-blocking checks in parallel with IDs 2, allowing users to report bugs. After the IETF 124 submission deadline, IDs 3 will become the authority, and IDs 2 checks will be removed.

*   **Mail System Updates:**
    *   **Static IP Block Removal:** Large IPv4/IPv6 static blocks (millions of IP addresses) that were causing user complaints about email interaction are being unblocked. No static blocks are desired long-term.
    *   **Ingress/Egress Separation:** Plans to separate ingress mail first, then egress, to improve scalability and prevent load spikes from affecting other mail system uses (e.g., list processing, password resets). A design will be shared soon.
    *   **Mailing List Welcome Message (Mailman 3):** New welcome messages for IETF and IRTF mailing lists have been implemented. They provide basic instructions and remind subscribers of applicable Note Well policies. The IRTF version is notably long due to its Note Well.
    *   **Post-Confirm Challenge Message:** The text for the first-time sender challenge has been rewritten to be clearer, more explicitly from the IETF, and encourage responses. It includes a "click-wrap" agreement: "By replying to this message you agree to follow IETF processes and policies."
    *   IESG oversight of these message texts will be incorporated into future processes.

*   **Tools Notes Page Schema:**
    *   The TOOLS team will switch to using the DataTracker-generated schema for meeting notes pages to resolve impedance issues. Redirects have been added for past meetings.

*   **Project Reports (FYIs):**
    *   **NPM Supply Chain Attack:** IETF tools were reviewed and found not to be affected by the recent large-scale attack.
    *   **DataTracker:** Python 3.12 upgrade completed smoothly. Person-less user cleanup done. Progress made on liaison work, with thanks to Eric and an anonymous community contributor for pull requests. Django upgrade planned for next April.
    *   **XML2RFC / SVGCHECK / RFC2HTML:** Security fixes implemented (by DSec), major backend upgrades for IAB/IETF websites. Upcoming new releases for SVGCHECK and RFC2HTML after publishing workflow setup.
    *   **Mail Archive:** Three releases since last call, focused on Python 3.12 and Django 5.2 upgrades. Investigation into replacing ElasticSearch with Typesense as a search engine is underway. Work has begun on blob storage for message back-end.
    *   **Purple (RPC Workflow Tool):** Close collaboration with RPC, feedback incorporated. Completed draft lifecycle flow (import, queuing, author matching), UI improvements, enhanced assignment concept (showing next steps), dependency status visualization. Upcoming: cluster visualization, recently published RFCs display, overall speed improvements (API, DB, frontend).
    *   **Red (RFC Viewer):** Progress on the new info route, now embedding RFC content. Support for PDFs/PostScript has been added (extracted as screenshots with alt text), addressing early RFCs lacking HTML content. Dark mode support fixes implemented across the app.

## Decisions and Action Items

*   **Yang Semantic Versioning:**
    *   **Decision:** DataTracker tooling (Pyang, potentially Libyang) should be updated to incorporate Yang semantic version validation.
    *   **Action Item (Joe Clark):** Investigate updating `RFC strip` to support Yang semantic versioning.
    *   **Action Item (Joe Clark):** Reach out to NETMOD WG to explore interest in helping with tools development for Yang semantic versioning.
    *   **Action Item (Mahesh):** Reach out to IANA separately and directly to discuss their publication process adjustments for Yang semantic versioning.
    *   **Action Item (Gene):** Review current RPC production tools (specifically `RFC strip`) and plan for updates. Meet at the hackathon to discuss.
*   **Use of Paid Libraries:**
    *   **Decision:** The use of paid/proprietary libraries will be evaluated on a case-by-case basis, focusing on concrete examples and trade-offs, rather than establishing a generic rule at this time.
*   **Tools Roadmap:**
    *   **Decision:** The existing GitHub project board for the roadmap is deprecated.
    *   **Action Item (Tools Team):** Replace the deprecated roadmap with new visualizations that differentiate between current work and expected production dates.
*   **Monthly Maintenance Window:**
    *   **Decision:** Target North American Thursday afternoons for routine maintenance and major upgrades.
    *   **Decision:** Major outages (more than single-digit minutes) will be pre-announced.
    *   **Action Item (Tools Team):** Develop a strategy to manage potential conflicts with working group interims.
    *   **Action Item (Tools Team/Roman):** Further discussion is needed on the best approach for community-wide announcements regarding maintenance (both short blips and longer outages) to balance communication needs with mailing list volume.
*   **Azure Security Review Report:**
    *   **Decision:** The final security review report will be shared with a restricted list including IESG, tools liaison, SEC Area ADs, IETF Chair, and a few TOOLS team members.
*   **IDs 3 Tooling:**
    *   **Decision:** IDs 3 will be integrated into the submission workflow as a non-blocking check initially, running in parallel with IDs 2.
    *   **Decision:** After the IETF 124 submission deadline, IDs 3 will become the authoritative check, replacing IDs 2.
*   **Mail System Updates:**
    *   **Decision:** Remove large static IPv4/IPv6 blocks from the mail server to improve email interaction.
    *   **Decision:** Implement new welcome messages for mailing list subscriptions (IETF & IRTF).
    *   **Decision:** Implement the rewritten post-confirm challenge message, including the "click-wrap" agreement.
    *   **Decision:** Incorporate IESG oversight into the process for maintaining these critical message texts.
*   **Tools Notes Page Schema:**
    *   **Decision:** The TOOLS team will switch to using the DataTracker-generated schema for future meeting notes pages.
    *   **Action Item (Robert):** Ensure redirects are in place for past meetings' notes pages.

## Next Steps

*   Continue to work towards the deployment of Red and Purple RPC tooling, with a goal of being in production before the spring IETF.
*   Further development and integration of Yang semantic versioning tooling (Pyang, Libyang, RFC strip) into DataTracker and RPC production systems.
*   When a concrete need arises for a paid library, bring the practical example to a TOOLS team meeting for discussion.
*   Implement new visualizations for the TOOLS roadmap.
*   Finalize the communication strategy for maintenance windows and deploys, addressing Roman's concerns.
*   Iterate on and share the final security review report for DataTracker and the new cloud infrastructure.
*   Complete the remaining critical issue for IDs 3 and proceed with its phased rollout.
*   Complete the removal of remaining static IP blocks and develop the design for ingress/egress mail separation.
*   Continue with scheduled updates for XML2RFC, SVGCHECK, and RFC2HTML.
*   Proceed with the investigation into Typesense as an ElasticSearch replacement and blob storage implementation for the Mail Archive.
*   Continue Purple and Red development, focusing on UI/performance improvements and new features as outlined in the project reports.