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 Maintainer

KDDI

Active Maintainerx

Orange

TSC Deputy Chair, Active Maintainerx

Radisys

EUC Representative

Summit Tech

EUC Representative

Telefonica

Active Maintainerx

Telefónica

Active Maintainerx

Verizon

EUC Representative

Vodafone

TSC Deputy Chairx

Vodafone

Active Maintainerx

Vonage

Active Maintainer
George Glass

TM Forum

TM Forum Representative

TM Forum

TM Forum Representativex

GSMA

GSMA Representativex

GSMA

GSMA Representativex

LF Staff:

Community: Axel Nennker Ming Hui Foo Pierre Close Bart van Kaathoven Guang-Han Ma Rafal Artych Ricardo Serrano Gutierrez Samuel Adeyemo Laszlo Suto

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

  • EasyCLA vs Developer Certificate of Origin (DCO) (Casey Cain )
    • Debrief from CAMARA Board Meeting and leadership call CAMARA / LF / GSMA
    • GSMA / LF Catch-up  (June 5th) - push to use EasyCLA but no decision at this stage. We need to solve the GSMA issue in cooperation with GSMA & LF, potentially based on the existing file-header.txt template. Target to close on this topic for next TSC crossed fingers 
  • "Codeowner" and "Maintainer" for the Governance repository (#138) (Herbert Damker)
    • Process to change content in https://github.com/camaraproject/Governance is currently not defined, especially for important changes of ProjectCharter and other Governance documents
      • Nevertheless it is clear that changes are in the responsibility of the TSC
    • Proposal:
      • Chair and Co-Chair of TSC as "Codeowners"
      • All TSC Participants as "Maintainers", following the same rules like in Sub Projects
      • Creating a GitHub team "TSC_participants" for this purpose (which can be used to request input on issues or reviews on relevant PRs)
    • Decision: Approved & to be executed like this.


API Backlog (Ricardo Serrano Gutierrez )

  • Ricardo: Assessment in progress for new APIs but no API to be  proposed at TSC level for today.
  • Template for scope enhancement (of existing APIs): https://github.com/camaraproject/APIBacklog/pull/52
  • Eric raised the question about the commitment of "becoming a supporter" for an api proposal. 
    • For Herbert it means at least nominates a maintainer. The question could also differ if the new API is part of an existing family (in this case it is related to #142).
    • Ricardo agreed and we can write something to establish this.

Commonalities (Rafal Artych )

The solution proposed to be covered in the scope of this meta release was:

    1. Apply the mechanism to rely on the access_token (not providing the device object in the API request) for 3-legged access scenarios.

    2. Remove the networkAccessIdentifier from Device object

Action: should be good to ask sub-project to assess impact on this discussion ( should be discussed in sub-project meeting) → Raise an issue in impacted projets like QoD

Identity & Consent Management (Axel Nennker )

  • Mark raised the point about diversity of using either authorization code flow and/or CIBA but we need to be careful. Straightforward question: Is it one of the either or both? do we mandate something?
    • Axel Nennker opened a discussion in ICM but with no real result of a global direction because it'is up to API implementation.
      • Sub-project can indicate if & how they are supported CIBA. I, Axel, do not know how they can indicate CIBA support in their YAML files. Also, openid discovery does not help because the metadata allows to express support for flows on a AZ global level through grant_types_supported not on an API level and not on an API endpoint level. Maybe subprojects can "indicate" support or requirement for CIBA somewhere - to be acted upon at onboarding time - but not on a technical level e.g. in the yaml file. So, telcos do not know which flow must be supported by an API and API consumers do not know which flow is supported or needed by an API by looking at the API's yaml file.
    • Diego González Martínez raised that we need to decouple the "how the developer get auth flow accepted" from "how we manage several possible auth flow for one API". Also said that from his point of view, discussion mentioned by Axel was about security schemas but not for the topic raised by Mark.
    • We can have a 'decision' at sub project level to 'device' which authorization flow will be supported. Need anyway to see how this 'information' will be communicated.
    • Move this discussion in ICM
  • ICM examples was created
  • Commonalities API Design Guidelines PR agreement was reached in ICM on June 5th. 
    Still being worked on but close to being finished
    • Axel & Diego discussed about the redundancy of information between ICM & Commonalities - minimum should be duplicated and links should be provided.
  • CAMARA APIs access and user consent management adaption to CAMARA Security and Interoperability Profile finished.
    Still some discussion on what network authentication "authenticates", user vs subscriber discussion.
  • Working on ICM release plan

Release Management (Tanja de Groot Samuel Adeyemo )

  • Progress of meta-release plan: Meta-release Fall24. 2 APIs were added.
  • Commonalities and ICM M1 shifting into June; M2 still kept on 15/06
  • Commonalities and ICM may have to prioritize the closing of main functional/technical issues or decide to move to next meta-release in order to reach an alpha release ASAP. 
  • Release Management issues status: see 2024-06-04 Release WG Minutes
  • The API release tracking page has been added to all API Sub Projects (thanks to Casey)
    • For new Sub Projects this page will be automatically created in the Confluence page structure. The RM documentation needs to be updated accordingly.
    • API Sub Projects can create their API tracker(s) by clicking on the button on the API Release Tracking page and following the guidelines. There should be one tracker for each API and its version they plan to publish in the meta-release
  • Updated API-Readiness-Checklist PR available for review: Add API-Readiness-Checklist.md to RM project
  • Actions:
    • Present in all-hands call next week (June 13th), featuring an example for the release tracking pages
    • Send a communication to "all" mailing list to inform about the release management and associated action requested from Sub Project

Any Other Business

Next Meeting

  • Next TSC Meeting will be on June 20th at 16:00 CEST / 14:00 UTC / 07:00 PST
  • Specific agenda topics backlog:
    • No specific request but feel free to propose till next meeting.

Action items

  • Raise an issue in Sub Projects impacted by device object definition changes - https://github.com/camaraproject/Commonalities/issues/171 to analyse the impact Rafal Artych 
  • Release Management: Present in all-hands call next week (June 13th), featuring an example for the release tracking pages Samuel Adeyemo  
  • Release Management: Send a communication to "all" mailing list to inform about the release management and associated action requested from Sub Project Samuel Adeyemo