2024-06-06 TSC Minutes

Owned by Casey Cain
Last updated: Jul 04, 2024 by Tanja de Groot
6 min read

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. 

Representative

Organization

Role

 

Representative

Organization

Role

 

@Herbert Damker 

Deutsche Telekom AG

TSC Chair, Active Maintainer

x

@Shilpa Padgaonkar

Deutsche Telekom AG

Active Maintainer

x

@Jan Friman 

Ericsson

Active Maintainer

 

@Toshi Wakayama

KDDI

Active Maintainer

x

@Ludovic Robert 

Orange

TSC Deputy Chair, Active Maintainer

x

@Adnan Saleem 

Radisys

EUC Representative

 

@Doug Makishima 

Summit Tech

EUC Representative

 

@diego.gonzalezmartinez

Telefonica

Active Maintainer

x

@Jose Luis Urien Pinedo

Telefónica

Active Maintainer

x

@Mahesh Chapalamadugu

Verizon

EUC Representative

 

@Eric Murray 

Vodafone

TSC Deputy Chair

x

@Kevin Smith 

Vodafone

Active Maintainer

x

@Chris Howell 

Vonage

Active Maintainer

 

George Glass

TM Forum

TM Forum Representative

 

@Olta Vangjeli 

TM Forum

TM Forum Representative

x

@Henry Calvert 

GSMA

GSMA Representative

x

@Mark Cornall 

GSMA

GSMA Representative

x

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  

  • "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.

  • New proposal how to manage "API Families" as Sub Projects with one lead repository and multiple API "family member" repositories (#142) (@Herbert Damker )

    • See issues about problem statement and proposed solution. It is a replacement for the previous proposal in #135 (working groups across Sub Projects).

    • Proposed next steps: close #135 and create a PR for the new proposal to enhance ProjectStructureAndRoles.md accordingly (@Herbert Damker )

    • Discussion

      • Comments to the issue should be provided before June 11th.

      • EdgeCloud provides an example with SimpleEdgeDiscovery

      • Question related to the Wiki pages for NV, SIM SWap & OTP - if it becomes a family we will need to have one wiki page. Anyway we need to be consistent between the wiki structure & the GitHub organization.

 

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.  

    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.gonzalezmartinez 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 Jun 13, 2024 
Release Management: Send a communication to "all" mailing list to inform about the release management and associated action requested from Sub Project @Samuel Adeyemo Jun 13, 2024 Cancelled and replaced by action on combined M0/M1 announcement email.