/
2025-10-02 TSC Minutes

2025-10-02 TSC Minutes

Attendees & Representation

TSC Members may indicate their attendance with an X in the far column

Representatives

Organization

Role

 

@Herbert Damker

Deutsche Telekom AG

Maintainer

x

@Shilpa Padgaonkar

T-Mobile US

Maintainer

 

@Jan Friman

Ericsson

Maintainer

x

@Toshi Wakayama

KDDI

Maintainer

x

@Ludovic Robert

Orange

Maintainer

x

@Tanja de Groot

Nokia

Maintainer, Release Manager

x

@diego.gonzalezmartinez

Telefonica

Maintainer

x

@Jose Luis Urien Pinedo

Telefónica

Maintainer

x

@Eric Murray

Vodafone

Maintainer

 

@Mahesh Chapalamadugu

Verizon

Maintainer

 

@Nick Venezia

Centillion.ai

EUC Representative

 

@massimiliano.troiani

Verizon

EUC Representative

 

@Doug Makishima

Summit Tech

EUC Representative

x

George Glass

alt: @Olta Vangjeli

TM Forum

TM Form Representative

 

@Henry Calvert

alt: @Mark Cornall

GSMA

GSMA Representative 

x

Community members may use @name tag to mark their attendance

Community: @Pierre Close @Alberto Ramos Monaga @ALI IQBAL @Guang-Han Ma @Surajj Jaggernath @Rafal Artych @Artur Krukowski

 

 

 

 

 

 

 

Action Item Review

LF Staff:

Agenda

The project's Antitrust Policy is linked from the LF and project websites. The policy is important when multiple companies, including potential industry competitors, are participating in meetings. Please review it, and if you have any questions, please contact your company's legal counsel. Members of the LF may contact Andrew Updegrove at the firm Gesmer Updegrove LLP, which provides legal counsel to the LF.

  • 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

Review and approval of previous meeting minutes

Action Item Review

Governance & Project Management issues

  • None, focus on discussion below

API Backlog (@Alberto Ramos Monaga)

API proposed for review Fraud Hotzone Alert - This API enables fraud-prevention systems to assess recent call and SMS activity associated with a phone number over a defined period, returning a risk outcome (e.g., anomaly detected, anomaly date). It helps financial institutions and service providers identify potential fraud scenarios quickly, while ensuring data confidentiality through a controlled GSMA private framework.

  • Proposed by Chunghwa Telecom, original issue #241 and API proposal (link)

  • If approved by TSC, check with GSMA → New private repository under GSMA confidential framework (same as Scam Signal)

    • Decision: Confirmed that the API can not be onboarded within CAMARA for the above reasons (same as ScamSignal), should be under the license conditions of GSMA

      • @Mark Cornall : no problem to onboard it on the GSMA git hub

        • @Tanja de Groot Need refactoring for the API folder/repo in GSMA GitHub in particular to ease release management [Editor note: for access to the repository please contact GSMA]

Proposal “Dual-Phase Meta-Release Strategy: #194

  • Last updates: Following the TSC action item (2025-09-18 TSC Minutes) to analyze the impact of the dual-phase proposal on Governance and Release Management documents, a draft review was carried out. The analysis also extended to Commonalities and Identity & Consent Management. The wiki page compiles the proposed modifications across groups and documents, but is clearly marked as a draft proposal, pending validation by each working group.

    • Decision: Overall concept was already accepted, details are currently under discussion, e.g. the new meta-release time plan (under discussion in Release Management working group)

    • Action Point: offline review of the wiki page with proposals for changes in CAMARA documents, creating issues for document changes out of it.

Clean-up process: #199 - Early draft proposal under discussion, aiming to introduce a lightweight, transparent and reversible cleanup process for inactive contributions in the CAMARA catalog — specifically onboarding trackers and repositories that show no meaningful progress after initial approval.

  • Feedback received:

    • Clear distinction needed between failed onboarding and archiving an existing repository with content.

    • Four phases identified, each requiring different criteria and timelines (failed onboarding, empty repo, repo with initial content, repo with reviewed/released version).

    • TSC involvement required in all cases, since archiving reverts a previous approval.

    • Reaction time in proposal seen as too short — should allow for vacations/holidays.

    • Failed onboarding or inactive repos should allow handover to other interested parties.

    • For repos with a released version, case-by-case review needed to ensure no one is already implementing it.

  • Next step: Wiki page to discuss this proposal, eventually it will be reflected in the lifecycle document (done with a PR).

"Connectivity Quality Management" as new name for the Sub Project "Quality On Demand: #258 - The Sub Project “Quality On Demand” will be renamed “Connectivity Quality Management”, following the integration of the DedicatedNetworks repository alongside QualityOnDemand and QoSBooking. The new name was proposed to better reflect the broader scope, discussed at the TSC on September 18th, and formally agreed by the Sub Project team on September 19th with strong support and no objections.

  • Decision: No objection from TSC - go for it. Name change will be executed to close #258.

Commonalities (@Rafal Artych )

Identity & Consent Management (@diego.gonzalezmartinez on behalf @Jesús Peña García-Oliva )

Release Management (@Tanja de Groot)

  • Spring26 meta-release (https://lf-camaraproject.atlassian.net/wiki/x/AQB_Cg)

    • M0: kick-off in this TSC - for now keep current schedule for Spring26 APIs, adjust once new schedule is agreed.

      • Commonalities targetting to release stable version in Spring26 (v1.0.0) - no breaking changes foreseen (so far)

      • ICM targeting to release stable version in Spring26 (tbc v1.0.0)

      • Commonalities and ICM are preparing content for Spring26

      • Preparing the scope issues for M1 and investigating how to link the scope issue with the GitHub milestone feature

    • M1: target Oct 15, but delay expected. APIs can start working with the Fall25 r3.3 (or r3.4 patch update)

      • @Herbert Damker potentially that will be even the official base for APIs released in Spring26, in line with the proposed dual-phase approach.

    • Current Spring26 schedule

    • image-20251002-014006.png

       

  • Proposal to be discussed: Meta-release schedule update

    • New meta-release schedule proposal following the feedback in Dual Phase proposal: see Proposal to Adopt a Dual-Phase Meta-Release Cadence for CAMARA APIs · Issue #194 · camaraproject/Governance

      • Requirements

        • Comm & ICM milestone 6 months earlier than today - spreading over the year Spring to Spring

        • Comm & ICM public release (M4) to be done 3 months before Fall APIs M3 [in following meta-release cycle]

          • @Herbert Damker Comm & ICM M4 in Spring26 should be 3 months before the M3 for APIs in Fall26

        • propose to move the “Fall” release later in the year to allow for proper review (outside of august) - oct or november - this leaves still enough time for meeting MWC demos deadline → current proposal 31 October YY

          • @Herbert Damker End of October might be too late for implementations within the same year, would prefer to keep the public release at September. Vacation time can be compensated by a longer release candidate period.

        • Need to allow time for APIs to test the upcoming C/I release-candidate before its public release

        • request to change the names of the meta-release as not matching the southern hemisphere.

          • For now using MayXX and NovXX with XX the year, e.g. May26 and Nov26.

          • @Herbert Damker Proposed to separate this discussion from the time plan itself. Using months as names might be not flexible enough, especially if short-term changes are needed.

      • @Tanja to update the proposal for discussion with Commonalities / ICM and in next TSC on Oct 2nd

        • Needs a bit more time as not yet discussed with Commonalities and ICM

DRAFT proposal (still to be discussed with Commonalities and ICM)

Main Commonalities and ICM releases in Spring

  • Spring meta-release initial APIs build on Commonalities/ICM M1/M2 and test for M4.

  • Fall meta-release stable APIs build on Commonalities/ICM M4/M5 delivered in Spring

image-20251002-014421.png

 

API meta-releases in Spring and in Fall

  • NOTE: APIs can create release inside or outside a meta-release

  • new or updates of initial APIs in Spring (in green) and in Fall (in red) meta-release

  • stable APIs preferably in Fall (in red) meta-release

  • transition period: All APIs must align to Commonalities / ICM of Spring26 by Fall26 meta-release

  • the below schedules explicitly includes the release PR review periods for M3 and M4

  • the overall meta-release dates are pushed to May and November, and the duration is extended from 6 to 7 months (the next meta-release starts (M0) one month before the end of the previous one (M6)).

image-20251002-014629.png

 

Any Other Business

  • Proposal to write a CAMARA White Paper to clarify use of the SIM swap, Tenure, Number Recycling and Device Swap API

    • The objective is to have in one document explanation about the information provided by these 4 APIs which are close

      • Examples will be provided

    • This white paper should be “validated” by KYC & Number Insight WG.

    • Telefonica offered to provide a draft (@Jorge Garcia Hospital ) & Orange (@Ludovic Robert ) happy to help

  • Feedback from GSMA @Tanja de Groot : the follwing feedback was received during the CAMARA presentation to the OGWTG:

    • The idea was brought up by GSMA that CAMARA could be presented to other groups in GSMA (e.g. RCS) which might be interested in contributing APis to CAMAP. Tanja has informed that the way to bring API proposals to CAMARA is to go through the APIBacklog team and that the development is expected to be done by the proposing team.

    • Question on how to provide feedback to CAMARA - e.g. on error codes on auth flows ? I presented various options, but for technically-focussed feedback the option to creating an issue in the relevant working group / API repository (e.g. ICM in this case) and to join meetings to discuss it was recommended

    • Feedback on the meta-release naming: Spring and Fall are not the same in the southern hemisphere, so it would be good to introduce alternative names.

Next Meeting

  • Next TSC Meeting will be on October 16th, 15:00 CET

  • Specific agenda topics backlog:

    • ...

    • ... 

Action items