Attendees & Representation

TSC Members may indicate their attendance by marking an X in the column to the right.

Community members may use @name tag to mark their attendance below the table. 

RepresentativeOrganizationRole

Deutsche Telekom AG

TSC Chair, Active Maintainerx

Deutsche Telekom AG

Active Maintainerx

Ericsson

Active Maintainerx

KDDI

Active Maintainerx

Orange

TSC Deputy Chair, Active Maintainerx

Radisys

EUC Representativex

Summit Tech

EUC Representativex

Telefonica

Active Maintainerx

Telefónica

Active Maintainerx

Verizon

EUC Representative

Vodafone

TSC Deputy Chairx

Vodafone

Active Maintainer

Vonage

Active Maintainerx
George Glass

TM Forum

TM Forum Representative

TM Forum

TM Forum Representative

GSMA

GSMA Representativex

GSMA

GSMA Representativex

LF Staff: Casey Cain Evan Harrison 

Community: Rafal Artych Tanja de Groot Ming Hui Foo Yacine Kheddache Pierre Close Samuel Adeyemo Ricardo Serrano Gutierrez Axel Nennker 

Agenda

The project's Antitrust Policy, which you can find linked from the LF and project websites. The policy is important where multiple companies, including potential industry competitors, are participating in meetings. Please review and if you have any questions, please contact your company 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

  • Easy CLA Introduction
    • Discussion with GSMA ongoing (Casey Cain)
    • Proposal for decision: Activate EasyCLA without further delay, as already previously decided for several past dates
      • Rational: 
        • Contributor License Agreements (CLA) or DCO (Developer Certificate of Origin) has to be introduced and enforced - mandatory for LF projects 
        • Linux Foundation recommended the use of EasyCLA for CAMARA, accordingly the activation of EasyCLA have been prepared
        • CLAs (or DCO) are necessary to protect contributors and project maintainers, it ensure that all contributions are done in accordance with the license of the project (ingoing = outgoing)
        • GSMA has their OPAG "Sandbox" as agreed, to be able to contribute work which was created within OPAG to CAMARA
      • Discussion & Decision:
        • GSMA will come to a proposal to Casey Cain and asks for one additional session with LF team.
          • Herbert Damker did see other option to move forward.
            • Decision is at CAMARA board level with TSC recommendation.
          • Casey Cain provided the options - We need to have one enforced anyway to act accordingly to our project charter.
            1. Have a decision at governing board
            2. Move to easyCLA right now (which is not really an option as we need governing board validation)
            3. Forgo the EasyCLA agreement and turn on DCO (Developer Certificate of Origin) enforcement.
          • Mark Cornall will meet GSMA lawyers and get back to LF team with proposal.
          • Casey Cain  will reach out to LF legal team in regard to CLA agreements, afterwards we can schedule a meeting with GSMA.
    • Note: The ProjectCharter is requiring currently both, CLA and DCO, that is according to Open Source experts unnecessary. Has to be resolved and updated together with LF.
  • Update of README.md structure in all sub projects
  • New working flow - API Approval (Ricardo Serrano Gutierrez )
  • Move Working Groups into own Sub Project repositories
    • See https://github.com/camaraproject/Governance/issues/84
    • API Backlog - initial list of maintainers (see previous TSC Minutes) (as of https://lists.camaraproject.org/g/tsc/message/165):

      Ricardo Serrano

      Telefonica

      MAINTAINER/CODEOWNER

      @TEF-RicardoSerr

      Ludovic Robert

      Orange

      MAINTAINER

      @bigludo7

      Jorge Garcia

      Telefonica

      MAINTAINER

      @jgarciahospital

      Mark Cornall

      GSMA

      MAINTAINER

      @MarkCornall

      Eric Murray

      Vodafone

      MAINTAINER

      @eric-murray

      Noel Wirzius

      DT

      MAINTAINER

      @NoelWirzius

      Christopher Aubut

      Charter Comunications

      MAINTAINER

      @caubut-charter

      (additional Codeowners to be agreed within the Maintainer Group, 3 recommended)

API Backlog (Ricardo Serrano Gutierrez )

  • Approval request for new repositories (see https://lists.camaraproject.org/g/tsc/message/160)
    • "Most Frequent Location" (see https://lists.camaraproject.org/g/tsc/message/164)
      • Proposed Initial maintainer/codeowner: 
        • Fernando Prado (Telefonica)
        • Fabrizio Moggio (TIM)
      • Will be potentially managed within "Location Insights" family together with "Device Visit Location"
      • Decision: Approved
    • "Best Interconnection" and "Device Visit Location" waiting for Maintainer/Codeowner lists
    • Also ready for creation: "Home Devices - Network Access Management":

      Name

      Company

      Role

      GitHub User

      Christopher Aubut

      Charter Communications

      CODEOWNER

      @caubut-charter

      Randy Levensalor

      CableLabs

      CODEOWNER

      @RandyLevensalor

      Mayur Channegowda

      Vodafone

      CODEOWNER

      @mayur007

      Justin Pace

      Charter Communications

      MAINTAINER

      @justin-pace-charter

      • Decision: Approved

Commonalities (Rafal Artych )

  • Draft scope for v0.4 release (relevant for Fall-24 meta-release) for discussion:
  • Proposal to tackle open subscription issues Common proposal to tackle subscription-based open issues. · Issue #185 · camaraproject/Commonalities (github.com) - mains points:
    • Align our subscription model with CloudsEvents subscriptions one
    • Introduce a status attribute in the template as we have fair UCs that can leverage this (Retrieve expired subscriptions for monitoring, deactivate a subscription if an user revoked her/his consent, etc...). API subproject could decide to use it or not.
    • Improve the model to allow consumers to subscribe to more than one event types with a single subscription but at least for the first meta-release we enforce to have only event type per subscription. After this first meta release decision to handle several event types in one subscription request should be discussed at API sub projet level
    • Add filters and it's up to API Project to use it. We recommend to be very cautious as it add complexity so it should be keep for very relevant UC.
    • Add initialEvent in config as well to manage request to get event when current situation of a device corresponds to the subscriptions type. .

Identity & Consent Management (Axel Nennker )

  • Working on getting https://github.com/camaraproject/IdentityAndConsentManagement/pull/121 merged.
    • Still some discussion on how to specify purpose
  • Hoping to convince participants that the current version is a working compromise on what we can  agree on
  • Some new issues for after the merge e.g.: ICM examples
  • Some old issues for after the merge e.g.: DPoP
  • First discussions/issues on operator token and how to support them in ICM and Camara APIs
  • Request to working group: define scope of release which will follow the milestones below for the Fall-24 release.


Release Management (Tanja de Groot Samuel Adeyemo )

  • Current time plan (from https://wiki.camaraproject.org/x/3qN3):
  • Meta Release Fall24
    • M0 approved and will be communicated
    • M1 initiated.- main deliverable will be the release scope of Commonalities and ICM
  • Approach for API families - latest proposals - two options
    • Multiple APIs within one sub project:
      • Have to always do their releases together
      • The APIs can have different versions, but every API has to have a defined version within the release
      • Repository release tag names are decoupled from the API versions contained within the repository
    • If APIs won't be able to release together (e.g. having different teams/codeowner working on it) they have to be in different repositories
      • In this case API should be carved out into own sub project repositories
      • A set of sub project repositories can be managed as a "family", with one wiki page, meeting etc.
        • Today this is the case already with NumberVerify, OTP Validation and SimSwap. They are managed together in one meeting but in three repositories.
        • EdgeCloud is an example recommended to carve out in multiple repositories for API development
  • Sandbox "release" within Meta-release: will have x.y.z with x=0, "incubated" APIs will have x >= 1
    • Sandbox and Incubated APIs can be together within one repository
  • Tanja de Groot presented the current draft of the Release Checklist (note: link to work in progress document, content will change)
  • Request to working group: elaborate Release Checklist and present within next TSC meeting with more details.

No life sign projects - how to handle these? (Ludovic Robert Eric Murray )

  • From past TSC Minutes:
    • We have currently two project without (visible) work within the repositories
      • Device Swap (repository created but no activity over the last 6 months)
      • IMEI Fraud (Attached to device identifier repository but no activity there on this API)
    • Are these APIs still relevant?
      • If, yes, how to find volunteers who will work on them?
      • If no volunteers: Postpone these APIs to a later time?
  • Device Swap seems to be solved: according to messages on the mailing lists there is a contribution in preparation, based on off-line work between MTN and Airtel. Ludovic Robert  will contact Wassem Amra. 
  • IMEI Fraud: Eric was in contact with MTN (proposal owner of IMEI Fraud). API will not be part of target release for Fall-24. If interest to develop will come up, setting up a separate Sub Project recommended. 
    • Action: Eric Murray to inform API Backlog and Helene from GSMA Product Team.

Any Other Business

  • Casey Cain presented the options to get current meeting invites <add details>. 
  • Herbert Damker proposed to open a discussion to anchor (all) meetings in CAMARA on UTC time (not urgent, but should be concluded before end of EU daylight saving time in October)

Next Meeting

  • Next TSC Meeting will be on May, 2nd, 2024 at 10:00 CEST / 08:00 UTC / 01:00 PST (see https://wiki.camaraproject.org/x/KAAG for meeting links)
  • Specific agenda topics backlog:
    • Update from TMForum collaboration and how members are working in Catalysts and Operate APIs (Olta Vangjeli )
      • Catalyst and Operate APIs update
      • Can we have more usecases proposed how TMForum APIs and Camara communicate in e2e journeys

Action items

2 Comments

  1. For the "Next Meeting" section, Could I please get feedback on this request?
    "
    Camara TSC: Microcks demo agenda proposals

    Yacine Kheddache <yacine@microcks.io>
    Apr 4, 2024, 2:30 AM
    to tsc

    Hi,

    We will be happy to introduce Microcks (100% open source project within the CNCF) for API mocking & testing and our ideas for helping Camara: https://hub.microcks.io/package/camaraproject.org

    Can we have a slot (around 15mins) for the next CAMARA TSC meeting? 

    Thank you
    Regards,
    Yacine Kheddache
    Microcks team
    "

    Depending on your preference, It could be shorter or discussed in a dedicated meeting.

  2. Yacine Kheddache As discussed: I'm personally interested in a dedicated demo call, but don't see that it fits into the TSC meeting agenda for now. Looking forward to learn more about Microcks.