2024-10-17 TSC Minutes

Attendees & Representation

LF Staff: @Casey Cain @Evan Harrison

Agenda

• 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

  • None

• Any Other Topics

Minutes

Review and approval of previous meeting minutes

• Minutes of previous TSC meeting: 2024-10-03 TSC Minutes

  • No comment → Approved

Action Item Review

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

  • @Rafal Artych provided update on linting extension to version breaking change. Action closed.

Governance & Project Management issues

• TSC Election (@Casey Cain)

  • TSC Election process documentation is available at: https://lf-camaraproject.atlassian.net/wiki/x/Snje

    • Question for @Casey Cain does current TSC member are eligible to be re-elect?

      • @Herbert Damker Yes, there are no restrictions within the ProjectCharter regarding multiple terms

    • Nomination phase is open until October 18th

      • After a 3-days verification period

      • The voting should open Oct 23, 2024 and open for one week.

      • Result should be communicated Oct 31, 2024

    • List of eligible nominees and voters is here:

      • Maintainers

      • End User Council

• Proposal to schedule all meeting within CAMARA anchored on UTC

  • See https://github.com/camaraproject/Governance/issues/164

  • Proposed change - to be discussed and decided by the TSC:

    • All CAMARA Community meetings get anchored in UTC

    • Each community decides on which UTC time they want to anchor their meeting

      • Default proposal is the time during the CET period e.g. for this TSC meeting UTC 15:00 (CEST 17:00, CET 16:00)

  • Decisions:

    • No opposition to switch to UTC → All meetings will be anchored in UTC

    • TSC 1st Thursday: 09:00 UTC (10:00 CET / 01:00 PT) [Note: during next DST, 11:00 CEST / 02:00 PST]

    • TSC 3rd Thursday: 15:00 UTC (16:00 CET / 07:00 PT) [Note: during next DST, 17:00 CEST / 08:00 PST]

    • AHC: 15:00 UTC (16:00 CET / 07:00 PT) [Note: ditto]

• Sandbox/Incubated/Graduated approach (@Herbert Damker - on vacation)

  • PR Governance/pull/161 with changes to ProjectCharter.md and ProjectStructureAndRoles.md opened for review (initial review comments addressed) - please review

    • Review in progress - please read & comment soon to speed up the merging.

    • No question from TSC

  • TBD: creation of API-Onboarding-and-Lifecycle document (update of current API-Onboarding.md with the new approach) in a separate PR

  • Comment: See discussion on “Capability and Runtime Restrictions” API below in API Backlog section below for issues that might arise from sandboxed APIs.

API Backlog (@Jorge Garcia Hospital @patricia.serranogonzalez@telefonica.com )

• Repository for CustomerInsights created (was approved as “TelcoIndex” in TSC 2024-09-19)

• New API proposals brought to TSC (3):

  • Model As A Service Family:

    • Supported by China Mobile, ZTE, Huawei. Filled template(below). Original issue: 83. Additional material:

    • Family proposal: New CAMARA Family to manage Model As a Service features. Includes different APIs that enable a end-to-end management of an AI model that can be exposed to third parties, with following functionalities:

      • Link1. Knowledge Base - Management (configure a user-specific knowledge base to support the construction of Q&A assistant)

      • Link2. Q&A Assistant - Management (configure specific LLM assistant with particular models)

      • Link3. Q&A Assistant - Service (usage of LLM, prompts and responses)

    • Decision: no comment - Reminder: This API will go in the sandbox. Approved !

  • Capability and Runtime Restrictions:

    • Proposed by TMUS. Filled template: link. Original issue: 22. Additional material:

    • Not API proposal per-se, but a capability that could allow developers know which optional features are supported by the telco operator before an API is called (This is a complementary API). Proposal is to create a mechanism to report

    • Could be considered as a transversal feature for any API, as per original CAMARA Service Management API APIs.

    • Question from @diego.gonzalezmartinez is this an API? Response: yes to request subscription in order to get notification.

      • For @diego.gonzalezmartinez we should have small API and all the API implemented. Having same API with different level of implementation is an adoption issue. We can have exceptions.

      • Is it valuable for a developer to discover on the fly an API limitation? Diego is doubtful about the rationale.

      • @Ludovic Robert and @Mark Cornall echoed Diego perspective.

      • @G. Murat Karabulut provides an illustration where depending on the (US) States the API may request distinct attributes list. Another example is documented for KYC Match in which idDocument is mandatory in some regions.

    • @Shilpa Padgaonkar : let’s leverage the sandbox capabilities to let this API grow up. Sandbox gives a chance to develop API idea.

    • @Jose Luis Urien Pinedo raises the point about the synchronization with the TMF operate API - The restrictions should be also defined in this flow.

    • Comment: Concern was expressed that such an API, even if developed as a sandbox, might give the wrong impression to external viewers of CAMARA was proceeding - in this case the concern that API providers will only implement a subset of an API’s functionality and use this API to advertise that once the API consumer has access. Some thought should be given as to how sandboxed APIs are to be “isolated” from incubated APIs to avoid giving this impression.

    • Decision: Ask to @G. Murat Karabulut to provide some examples where this API will be useful. To be revisited during the after-next TSC meetingNov 14, 2024 .

  • Consent URL API:

    • Supported by Telefonica and KPN. Filled template: link. Original issue: 68. Additional material: link

    • Meant for providing an out-of-band consent gathering mechanism that can be triggered in a separated moment (apart from API authentication phase) and in an arbitrary device (not only the API-targeted device), enhancing current mechanisms tied to Authcode or CIBA token flows.

      • Discussed with ICM WG in particular to define the relationship between this API & ICM

      • Open discussion, as lack of consensus around AuthCode authentication mechanisms (https://github.com/camaraproject/IdentityAndConsentManagement/issues/215 )

        • @Axel Nennker strongly disagrees with this API rationale

        • @Shilpa Padgaonkar Probably the issue comes from the fact that initial assumption is we use only Network-based authentication.

    • Comment: The discussion within ICM #215 indicates there may be a lack of clarity as to which of CAMARA’s “guidelines” are normative and which are only informative and hence not mandatory. TSC may need to look at formalising rules on this regarding documentation language, layout and approval processes.

    • Decision: The discussion must continue in ICM first. No decision at this stage.

Commonalities (@Rafal Artych @Pedro Díez García )

• An issue for the scope version 0.5.0 : Commonalities/issues/273 - important PR opened:

  • https://github.com/camaraproject/Commonalities/pull/316

  • https://github.com/camaraproject/Commonalities/pull/315

  • https://github.com/camaraproject/Commonalities/pull/313

• Breaking changes indication in PR template:

  • https://github.com/camaraproject/Commonalities/pull/314 - can be considered by subprojects esp. with stable releases of API

• https://github.com/camaraproject/Commonalities/issues/294- possibly can be provided by Capability and Runtime Restrictions API/feature.

Identity & Consent Management (@Axel Nennker )

• Main topic is to allow use operator_token from TS43 to identify device on authentication request.

• @diego.gonzalezmartinez It was raised in ICM an opinion that the document https://github.com/camaraproject/IdentityAndConsentManagement/blob/r0.2.1/documentation/CAMARA-API-access-and-user-consent.md is informative.

  • Comment: See comment thread in ICM #215 and also discussion around “Consent URL API” proposal in API Backlog section above. TSC may need to look at formalising rules on normative documents regarding documentation language, layout and approval processes.

Release Management (@Tanja de Groot @Samuel Adeyemo )

• Content from last meeting notes

  • Spring25 M0: the meta-release kick-off can be done in last week’s TSC meeting. An email to all mailing list has been sent to inform the community. The meta-release plan is available here: Meta-release Spring25.

    • M0 is declared by the TSC Oct 3, 2024

  • Spring25 M1: Due to delays in the Fall24 meta-release, the M1 date is slightly impacted and shifted from Oct 15th to Oct 31st.

    • Exceptionally, the M1 will not yet have an alpha release available for Commonalities and ICM, but the relevant set of PRs covering the scope of the upcoming release shall be made available for Sub Project team review as follows:

      • PRs for critical issues must be created by Oct 15th (not necessarily merged)

      • PRs for other issues must be created by Oct 31st (not necessarily merged)

      • Alpha releases will be created as fast as possible after that and an M1 update announcement shall be sent at that point.

  • Info for Sub Projects: the API release tracker content & template for Spring25 is now ready to create new API release trackers for Spring25. NOTE: Fall24 API release trackers SHALL NOT be copied as the structure is different.

  • Fall24 M6: The date is slightly delayed. Feedback is being integrated in the process and artefacts. This has no impact on the Spring25 content progress and should be finished latest by Oct 31st.

Specific Topic

• None

Any Other Business

• None

Next Meeting

• Next TSC Meeting will be on November 7th, depending on above decision either

  • 09:00 UTC (10:00 CET / 01:00 PT)

• Specific agenda topics backlog:

  • GSMA OPAG “NBI realisation guidelines” (Christina Santana Casillas, OPAG Chair)

Action items