Attendees & Representation

TAC Members and Project representatives should mark their attendance below 

Agenda

• Check Action Items & Topic Requests (Backlog)

• Community Technical Events

• Planning discussion

  • RAN

  • AI

  • Security

    • Glasswing

    • LFN Vulnerability Reporting

    • Security policy template

• Any Other Topics

Project Glasswing

Casey provided a brief overview of Project Glasswing. The project is currently invitation-only and is focused on specific critical infrastructure projects within the Linux Foundation, with the Linux kernel as the initial target. The Apache Foundation is also involved. Ranny confirmed that no broader availability timeline is known at this time, and that the community will be informed as more details become available.

Casey noted that names and POCs for interested LFN projects (including FD.io and ONAP) have been collected and shared with the Glasswing team via Mike Dolan. Muddasar suggested it would be useful to track how Glasswing might eventually integrate into the LFN toolset for future reference.

LFN Vulnerability Reporting Page

Casey shared an updated LFN Vulnerability Reporting wiki page, which replaces a significantly outdated version. The page provides general guidance on how to report security vulnerabilities within the LFN community, includes project-specific security contacts where available, and lists the LFN support channel as a fallback for routing reports to the appropriate project contact.

Casey asked all project representatives to review the page and ensure that both the central page and their own project documentation accurately reflect their current vulnerability reporting processes.

Olaf noted that direct per-project security contacts would be preferable to relying on the central mailing list for routing. Dave confirmed that FD.io/VPP agreed in their community meeting the previous day to move their security policy from the wiki into the VPP GitHub repository, while also retaining it on the wiki.

Security Policy Template

Olaf proposed developing a common security policy template that projects can use as a baseline, to be hosted in each project's GitHub repository. He noted that the Cyber Resilience Act (CRA) will introduce new vulnerability reporting obligations starting in September 2026, making it important to have baseline infrastructure in place ahead of that deadline.

Douglas emphasized the importance of deriving any such template from well-vetted, legally reviewed policies, such as those from the Linux Foundation, OpenSSF, or the Eclipse Foundation, rather than drafting something ad hoc. He also cautioned that any policy written down must reflect what projects can actually enforce and deliver, not aspirational commitments.

Muddasar suggested the ideal structure would be a high-level foundation-wide policy statement that delegates specifics to individual projects. He noted that the LFN board considered security goals in 2024 or 2025 but did not adopt a formal policy at that time, and recommended raising the topic again.

Dave clarified that LFN projects operate as series LLCs under LF Projects LLC, meaning each project is an independent legal entity responsible for its own security processes. Casey confirmed this structure, noting that older projects such as FD.io and OpenDaylight had their charters updated when LFN was formed as a directed fund. Robert requested that an overview of U.S. series LLC structures be made available for community members, particularly those based in the EU.

The group agreed to keep security policy and vulnerability reporting as a standing agenda item in upcoming TAC meetings, and to bring the question of a foundation-wide policy to the May 20 LFN Governing Board meeting.

Actions:

• Olaf, Casey, and community: Begin drafting a security policy template drawing on LF, OpenSSF, and Eclipse Foundation guidelines, with attention to CRA obligations.

• Muddasar and Casey: Raise the question of a high-level LFN security policy at the May 20 Governing Board meeting.

• All project representatives: Ensure their projects have up-to-date, legally reviewed security process documentation; those without should initiate creation as soon as possible.

Cross-Community Technical Events

Olaf raised the question of reintroducing cross-community developer and testing events. The previous Developer and Testing Forum (DTF) format had largely been replaced by individual project events, and the group discussed whether to bring back a cross-project forum format given the growing number of cross-cutting topics such as RAN, AI, and security.

Dave noted that FD.io has held informal developer meetups at FOSDEM with good results, and suggested KubeCon as a venue more likely to attract developer attendance than OneSummit. Ranny highlighted the Cloud Native Telco Day, held as a full-day co-located event at recent KubeCons, as a strong existing venue that already broadly represents LFN community work. Robert noted that KubeCon attendance is often easier to justify internally since companies are already sending delegates.

The group discussed targeting both the US and European KubeCon events to account for the different regional centers of gravity across projects. Travel cost and authorization were raised as practical challenges, with a suggestion to bring the topic of travel support to the May 20 Governing Board meeting.

OSC Transition Update

Tracy van Brakle provided an update on the Open Source Cellular (OSC) project's transition plans. The group has decided not to rebrand or restructure the project, but rather to move it forward as-is. SMO-related functionality will remain within OSC for the foreseeable future, while integration work may migrate to the Super Blueprint. OpenCUD-related work will go to Duranta and OCUDU.

Tracy noted that OSC community members may not be familiar with LFN development practices and requested guidance and support in aligning with those practices. OSC will continue weekly meetings on Thursdays at 9 a.m. Eastern.

Tracy also shared two active use cases: network energy savings (involving Duranta and OpenAirInterface) and positive train control (involving OCUDU). Slides and details will be prepared for a future TAC presentation. Casey noted that the LFN Zulip discussion channel is available for cross-community announcements and conversations, and pointed to OpenDaylight's active use of Zulip as a positive example.

Actions: