2026-02-05 TSC Minutes

LF Staff:

• Review and approval of previous meeting minutes

• Action Items Review

• General Topics

  • Governance & project management issues

  • API Backlog

  • Commonalities

  • Identity & Consent Management

  • Release Management

• Specific Topics

  • ...

• Any Other Topics

• Minutes of previous TSC meeting: 2026-01-15 TSC MinutesPreview

  • approved

• See home page Technical Steering Committee for current list of open action items

  • none (see issues in Governance instead)

• Zulip migration

  • Slack workspace will be deactivated soon. Join Zulip here: https://linuxfoundation.zulipchat.com/join/t4rkxuxcviaac6igbonx6v4h/ with your Linux Foundation SSO ID.

  • Any feedback? Good experience

  • Channel for Number Insights sub project to be created

• MCP Whitepaper: several articles, e.g. here and here, worth to read: a longer review by Dean Bubley

• https://github.com/camaraproject/Governance/issues/210

  • Further comments?

  • @Jan Friman Commonalities probably will run it as a break-out, including also people outside Commonalities in the work

  • Decision: Programm in principle approved, work has to start after ICM and Commonalities are done with Spring26 M2

• Automated Release Process introduction: progressing, see below.

• (Information): Define standard README warning and topics for archived API repositories #297: we have a documented and repeatable Archived Repository Communication Requirements pattern (standard README banner + mandatory GitHub topics, including archived-api-repository) captured in Governance /API-Onboarding-and-Lifecycle.md under the archived-repository section—so we’re now operationally ready to proceed with upcoming repository archivals using the same template across all cases (for #283 HomeDevicesQoD, #284 SiteToCloudVPN and #285 ShortMessageService)

• (TSC for Approval): Following the agreement reached in the Device Status regular cadence call, we will take the repository renaming (from DeviceQualityIndicator to DeviceMediaStreamingRate) to the CAMARA TSC for formal approval (low-risk change given there is no release yet), clarifying that this is only a repository/name alignment and everything else remains unchanged—the work stays within the Device Status subproject (no subproject move implied).

  • https://github.com/camaraproject/APIBacklog/issues/296

  • Decision: approved

• Meta-release preparation

  • Draft PR for Release 4.1 and draft https://lf-camaraproject.atlassian.net/wiki/x/BIDjHg documenting changes impacting APIs

• Still open PRs:

  • Guidelines and linting rules for OWASP API Security Top 10 #582

    • New requirements for property definitions and linting rules:

      • owasp:api4:2023-array-limit - Schema of type array must specify maxItems.

      • owasp:api4:2023-integer-limit-legacy - Schema of type integer must specify minimum and maximum.

      • owasp:api4:2023-integer-format - Schema of type integer must specify format (int32 or int64).

      • owasp:api4:2023-string-limit - Schema of type string must specify maxLength or enum.

    • It is proposed that these requirements should be exempt from verification in current meta-release and the rules have the severity temporarily set to warning with the target value error (in future CAMARA meta-release after 2026).

    • The issue indicating impact of these rules can be created with automations

    • Improve authentication mechanism for subscription events #580

    • Add business-level outcome guidance to API Design Guide #578 (replacing PR #567)

    • Clarifications for asynchronous responses #575

    • Array description guideline #559

• Establish guidance for consuming schemas from CAMARA_common.yaml · Issue #577

  • initial analysis provided and discussion on-going

• Tooling

  • Release v0.2.0 - Dependabot for Github Actions, updates of linting rules and action workflows

  • Update of linting workflows to include OWASP rules - expected after Commonalities Release Candidate

• ICM Spring26 meta-release status.

  • The Spring26 Release Candidate (r4.1) PR is available for review https://github.com/camaraproject/IdentityAndConsentManagement/pull/344

  • The following issues were dropped from the scope of the meta-release (more details on the reasoning behind these decisions can be found here):

    • https://github.com/camaraproject/IdentityAndConsentManagement/issues/288 The WG has decided to remove the OAuth 2.1 adaptations from the scope of Spring26 and move them to a future release, with a tentative target of Spring27.

    • https://github.com/camaraproject/IdentityAndConsentManagement/issues/312 The WG noted insufficient business justification and no participant ownership for continuing RAR support.

• https://github.com/camaraproject/IdentityAndConsentManagement/issues/340 After analysis, the WG believes the attack does not affect CAMARA, given current recommendations (audience = full endpoint URL). Current ICM recommendations are likely already sufficient.

  • WG will consider adding an editorial clarification stating that CAMARA’s approach is not affected by the vulnerability.

• Consent Info API

  • The repository is preparing for the v0.2.0 release candidate.

    • https://github.com/camaraproject/ConsentInfo/pull/46 The v0.2.0‑rc.1 pre‑release PR has passed all checks and received approvals including Release Management

• Consent Management API - Controlled Consent Capture Delegation.

  • Initial API draft is under review; Open questions from previous sessions have been addressed; Further review to continue as needed; No open blocking issues.

• Further details of the above items can be found at 2026-01-28 ICM MinutesPreview

• Spring26 meta-release (Spring26 meta-releasePreview)

  • M2 (Feb 15)

    • Date shifted by 2 weeks to Feb 15 in order to finish some outstanding issues

    • Commonalities and ICM are preparing their Release PR

  • M3 (Feb 15+): 4 of 6 Spring26 APIs under review, but final Release PR only once M2 is reached.

    • Spring 26 participation: SessionInsights #350 

    • Spring26 participation: HighThroughputElasticNetworks #349

    • Spring26 participation: IoTSIMFraudPrevention #348 

    • Spring26 participation: NetworkInsights #344

    • Spring26 participation: ClickToDial #343 

    • Spring26 participation: Network Slice Booking #341

• Fall26 meta-release (Sync26 meta-release (ex-Fall26)Preview )

  • M0 (Jan 15). Start of API work dependent on:

    • M2 Commonalities and ICM release-candidate

    • Release automation rollout

• Release automation

  • Process implementation in work, two further steps added to MVP scope: /publish-release and post-release PR to main

  • Process to be tested with a few APIs before final rollout to all repositories for usage in Fall26

    • Codeowners should volunteer to be part of the testing phase if they have a pre-release planned in the next weeks (alpha for Fall26 or an independent release)

  • New release process documentation available accordingly for pre-read (work in progress!)

  • New release process in a nutshell:

    • Plan new release by updating the repository’s release-plan.yaml file (replacing the API release tracker on wiki)

      • Roll-out prepared, will come soon to all repositories. Can be used to declare intent for Fall26 or independent releases even before the process will be used.

    • Develop the API definitions, test definitions and documentation as usual on main branch (using “wip”)

      • Each PR will be linted and validated for release compatibility

      • Base check for release-plan.yaml in place, further validation checks will be added step-by-step

    • Use the generated “Release Issue” to give the commands to manage the API release.

      • The Release Issue also automatically tracks the state of release process (through a managed label).

      • User activities:

        • /create-snapshot (codeowner)

        • review, approve, and merge Release Review PR with CHANGELOG entry (codeowner + release management)

        • final check of GitHub draft release and /publish-release (codeowner)

      • States are: PLANNED → SNAPSHOT ACTIVE (branch from main with replacements + review PR branch) → DRAFT READY (GitHub draft release) → PUBLISHED (release tag created, post release updates to main branch done)

      • Several release attempts can be made before final release (commands /discard-snapshot and /delete-draft)

    • Use of the process requires deployment of new caller workflow “Release Automation” in API repository (under development)

• ...

• Next TSC Meeting will be on Thursday, February 19th, 15:00 UTC

• Specific agenda topics backlog:

  • ...

  • ...