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
Herbert Damker

Deutsche Telekom AG

TSC Chair, Active Maintainerx
Shilpa Padgaonkar

Deutsche Telekom AG

Active MaintainerX
Jan Friman

Ericsson

Active MaintainerX
Toshi (Toshiyasu) Wakayama

KDDI

Active MaintainerX
Ludovic Robert

Orange

TSC Deputy Chair, Active MaintainerX
Adnan Saleem

Radisys

EUC Representativex

Doug Makishima

Summit Tech

EUC RepresentativeX
Diego González Martínez

Telefonica

Active MaintainerX
Jose Luis Urien

Telefónica

Active MaintainerX
Mahesh Chapalamadugu

Verizon

EUC RepresentativeX
Eric Murray

Vodafone

TSC Deputy Chairx
Kevin Smith

Vodafone

Active Maintainerx
Chris Howell

Vonage

Active Maintainer
George Glass

TM Forum

TM Form Representative

Henry Calvert

GSMA

GSMA Representative x

LF Staff: Casey Cain Evan Harrison 

Community: Jin Xu (Huawei), Kai Zhang (Huawei),  Ming Hui Foo, Kai Zhang, Shuting Qing Pierre Close Ramesh Shanmugasundaram Tanja de Groot Henry Calvert Mark Cornall 

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.

  • Roll Call
  • Action Items Review
  • Agenda Bashing
  • General Topics
    • API Backlog
    • Commonalities
    • Identity & Consent Management
    • Release Management
  • Any Other Topics
    • Topics for Governing Board of CAMARA Fund?

Minutes

API Backlog

  • API proposal "Device Location Retrieval" - see message https://lists.camaraproject.org/g/tsc/message/105
    • Initial version of the YAML already available within the sub project "Device Location"
    • Hence just a formal approval required
    • #Approved
  • API proposal "Network Slicing" - see message https://lists.camaraproject.org/g/tsc/message/104
    • Application proposal: APIproposal_NetworkSlicing_ChinaUnicom.md
      • Discussion within related issue: https://github.com/camaraproject/WorkingGroups/issues/317
      • Supporting presentation in PPT
      • Endorsed by API Backlog WG Jan 11th, see meeting minutes
      • Jan raised a question about the name of the API as it more about ordering/reservation than Network Slicing itself.
        • Discussion about use of "on-demand" label - rationale for this? 
            • Kai Zhang: on-Demand because the customer will dynamically reserve the slice
        • The API could have the reservation name (and it will be decided by the project later)  but what's about the project name?  Herbert: what about Network Slicing ... on-Demand ? Booking ? Reservation?
        • Discussion about project granularity: Reservation but then does device attachment should be managed in same project? Herbert explained that we targeted 'small' project in term of APIs managed (to be flexible for CAMARA meta release management) - It is possible to have several APIs but must be very close and released together.
          • Ms. De Groot From a developer perspective, what do they want to call the sub-project? On Demand, or Network Slicing - The API needs to be explicit in the name
          • Mr. Damker gave the final answer to end the discussion for now, the option for the team to come back at a later time to decide upon a name, or they can make the decision during the meeting (TSC 1/18) -
      • Approved

Commonalities

  • Initial input info by Shilpa
  • Target date for release 0.3.0 is to be ready for approval on 05.02.2024
  • Linting ruleset and guidelines PRs are currently under review. We need to close this review soon.
  • API Testing guideline doc has 1 open point left. After this discussion is resolved, PR can be merged.
  • Security-scheme and scope update in design guidelines document and reference to document in ICM are also currently in review. 
  • Other release 0.3.0 specific PRs are minor documentation changes.
    • Mr. Damker asked when the team is planning on a certain release?

Identity & Consent Management

  • Initial input info by Diego
  • Agreements regarding releases:
    • V0.1 to be generated. All issues marked as required for the release are solved (Intended date for release will be next Jan 22 - Jan 26.)
    • V0.2 to be progressed as fast as possible. Scope: clarifications on existing scope requested by existing issues
    • V0.3 will include enhancements
  • OIDC profile:
    • To be created in CAMARA. Not to rely on starting it in OIDF working group to avoid risk of delay.
  • Duplicity of information GSMA-CAMARA
    • AuthN/AuthZ flows will be in CAMARA. Existing ones to be evolved as needed. 
    • Issue to be opened in GSMA so duplicated info there is replaced with a reference to CAMARA. GSMA to still have needed information regarding interconnection and routing, referencing to CAMARA when needed

Release Management

  • Initial input info by Herbert
  • There are two important streams regarding release management:
  • CAMARA wide "meta release"
    • The coordination of a snapshot across all CAMARA sub projects, including the coordination of dependencies (e.g. to Commonalities)
    • Requires at least two Release Managers for CAMARA
      • Tanja Groot that Nokia is willing to nominate Samuel Adeyemo to act as Release Manager
      • Request for further nominations will be addressed to the Governing Board
    • Release managers report to TSC about release progress
    • Next week (Jan 22- Jan 26), the team plans on sketching out a release roadmap plan.
  • The training material from LF about Release Management is available here: https://wiki.camaraproject.org/x/QAEG
  • Mr. Damker shared a question: Should we try to create these guidelines within the subject, or should we create the guidelines within a small task force from the Commonalities sub-project?
    • It makes sense to have this discussion within the Commonalities group. The task force will outline the guidelines.
      • Decision: The team believes that we should have the guideline discussion within the Release Management meetings as opposed to the Commonalities group.
        • ACTION: Raise this information in the next Commonalities meeting and make the team aware.
      • Volunteers for the Commonalities Task Force: Mark Cornall 

Any other topic

Action items

  •