2024-06-20 TSC Minutes
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 |
|
---|---|---|---|
@@Herbert Damker | Deutsche Telekom AG | TSC Chair, Active Maintainer | x |
@Shilpa Padgaonkar | Deutsche Telekom AG | Active Maintainer | x |
@Jan Friman | Ericsson | Active Maintainer | x |
@Toshi Wakayama | KDDI | Active Maintainer | x |
@Ludovic Robert | Orange | TSC Deputy Chair, Active Maintainer | x |
@Adnan Saleem | Radisys | EUC Representative | x |
@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 | x |
@Eric Murray | Vodafone | TSC Deputy Chair | x |
@Kevin Smith | Vodafone | Active Maintainer |
|
@Chris Howell | Vonage | Active Maintainer | x |
George Glass | TM Forum | TM Forum Representative |
|
@Olta Vangjeli | TM Forum | TM Forum Representative |
|
@Henry Calvert | GSMA | GSMA Representative |
|
@Mark Cornall | GSMA | GSMA Representative | x |
LF Staff: @Casey Cain @Evan Harrison
Community: @Jesús Peña García-Oliva @Tanja de Groot @Pierre Close @Mark Cornall @G. Murat Karabulut @Nick Venezia @Rafal Artych @Samuel Adeyemo
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
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
Minutes of previous TSC meeting: 2024-06-06 TSC Minutes
Approved
Action Item Review
See home page Technical Steering Committee and 2024-06-06 TSC Minutes
Governance & Project Management issues
EasyCLA Introduction (@Casey Cain )
Concerns of the EasyCLA deployment have been resolved.
Suggested that we deploy EasyCLA on Jun 24, 2024 or Jul 1, 2024
LF Staff will be on standby to resolve any last-minute issues
There were a few unforeseen issues on the LF side; can be deployed at any time now. Set the deployment date for
Suggestion by Herbert to have a "EasyCLA" playground (test repository) to help community to understand/test how it works. +1 on the idea from Casey.
@Herbert Damker Proposal changed based on the feedback within the comments: no "lead repository" for a Sub Project, but a Sub Project / API Family will be a set of 1 to n equal repositories to describe, develop, document and test the APIs (family members). The link between the repositories is the home page of the Sub Project within the wiki
Pull request to be reviewed: https://github.com/camaraproject/Governance/pull/146
Ask for formal vote from the TSC: No... but we keep it open for next week. Will be merged by end of next week if no objections arise.
Proposal for new API Project lifecycle approach (Sandbox + Incubated) (#129)
Herbert reminds us the advantages of this proposal to have some flexibility to onboard easily new project.
Next step: details out this.
Issues to resolve smaller issues within the governance (for information / request to contribute):
Ongoing project organization tasks (just in case there are questions)
Create CAMARA teams for Codeowners & Maintainers - apply to all sub projects (#134)
Almost done !
Update of README.md structure in all sub projects (#124)
Not all of them has been done (half) - Work in progress.
Change Working Groups into Sub Projects (#84)
Almost done.
API Backlog (@Ricardo Serrano Gutierrez )
@Herbert Damker Two new API Proposals are forwarded by the API Backlog working group to the TSC (see https://lists.camaraproject.org/g/tsc/message/195)
Device Connection Quality Indicator
Device data Volume
Both are intended to be part of the DeviceStatus Sub Project
@Eric Murray Raise an issue in Device Status project to formally ask the project to manage this 2 APIs
@Herbert Damker There are currently two approaches to define an API which delivers the network type a device is currently connected to
Within DeviceStatus: https://github.com/camaraproject/DeviceStatus/issues/143 with PR
Within ConnectivityInsights: https://github.com/camaraproject/ConnectivityInsights/pull/40 (see also https://github.com/camaraproject/ConnectivityInsights/issues/48)
How to avoid and resolve such situations?
@Mahesh Chapalamadugu explained that discussion occurred already in the connectivityInsight project and this team stated that probably it did not make sense to keep this network type attribute in this API.... so the point is resolved
Commonalities (@Rafal Artych )
Release 0.4.0-rc.1 - in preparation
All PRs missing in alpha merged, new fixes proposed (PR#229, PR#234, PR#236, PR#238)
Device object simplification https://github.com/camaraproject/Commonalities/pull/233:
Apply the mechanism to rely on the access_token (not providing the device object in the API request) for 3-legged access scenarios - Annex to API Design Guidelines
networkAccessIdentifier not removed from Device object, but not allowed in Commonalities 0.4.0 (Fall24 release)
Please review this PR
Target is to agree the RC.1 during Commonalities call on 24th of June and publish it during the week.
Question from @Jesús Peña García-Oliva where this information should be kept: in ICM or in Commonalities. In the PR this is in annex of the design guideline - people have already approved to have this in the guideline.
Identity & Consent Management (@Jesús Peña García-Oliva on behalf of @Axel Nennker )
Create ICM Release Plan - #146:
The team agreed to proceed with a release candidate directly, bypassing the alpha release, given the stability and closed scope of the current state.
Issue 128 will be excluded from the current release, and the scope is now fully defined, allowing the team to proceed with generating the release candidate.
There is a recognition of the need for validation of access tokens but differing views on the feasibility and scope of standardization. Some participants suggested documenting standard claims in access tokens, while others emphasized the need to leave implementation details to individual operators.
OIDC authorization code flow and/or CIBA - #176
GSMA highlighted the need for clarity on which authorization flow operators should implement when onboarded in Open Gateway.
ICM feedback: The decision on which authorization flow to implement is more of a business decision than a technical one. Operators should support the flows defined by CAMARA and be compliant with ICM Security & Interoperability profile, but specific implementation can be decided based on business needs and regulatory requirements. For instance, an operator using only one API that requires a specific flow can choose to implement just that flow if it's allowed by the business decision of Open Gateway. For specific APIs with unique requirements, the auth flow to implement may be dictated by the API's functionality (such as Number Verification API) and be documented by the API subproject.
No comments from the team - very good summary!
Release Management (@Tanja de Groot @Samuel Adeyemo )
Commonalities and ICM scope issues and alpha release PRs/releases are ready for TSC approval - Combined M0/M1 to be declared after that and notified to the all mailing list.
Question: How much time is needed for the TSC approval ?
Give one week for review of the release PRs and then assume lazy consensus if there are no open comments.
- @Tanja de Groot Send already in parallel information to all sub projects via "all" mailing list about the M2
Question: where do we post the "Request for scope and alpha/release candidate review" announcement? TSC mailing list or the RM mailing list ? If the latter, do we have sufficient TSC members on the RM mailing list?
Request for review should go to the TSC Mailing list. In addition the GitHub team @camaraproject/TSC_participants to be added as reviewer to the PRs
Delayed sending the message (per action previous TSC) to the all list due to an ongoing update of all the material (Update public release name - PR #35)
Proposal: combined M0/M1 message to be sent after TSC approval of Commonalities and ICM scope and alpha releases.
See above, information should be send already in parallel to the review of the release PRs of Commonalities and ICM.
15 APIs proposed for the Fall24 meta release so far. All are currently target initial versions (v0.x) as public release. Possibly 1 or 2 may be proposed as stable public releases (NumberVerification and SimSwap)
Third candidate for stable: OTPvalidationAPI
@Jose Luis Urien Pinedo : We will have a discussion also in device location for some API to promote for stable.
Herbert: We can decide moving forward during the release cycle.
Tanja: till Aug 15, 2024 we can decide to promote or not to stable
Promoted API to stable should have live implementation (of previous released version) as listed here, and only reasonable amount of changes since then
As a reminder checklist table is within GitHub (API-Readiness-Checklist.md) and more details here within wiki.
Updated CHANGELOG_TEMPLATE and example PR available for review: https://github.com/camaraproject/ReleaseManagement/pull/36
Question: How to proceed with the existing template in Commonaltities? Herbert's proposal: proceed as same way as we did it for the checklist
Release management issues closed. One pending PR review, one issue as backlog item remaining.
@Tanja de Groot added that we can create 'public release' outside of meta release → This possibility has been documented.
Upcoming tasks: start looking at the APIs proposed for the meta-release.
Any Other Business
Nope.
Next Meeting
Next TSC Meeting will be on July 4th at 10:00 CEST / 08:00 UTC / 01:00 PST
Specific agenda topics backlog:
None so far - please feel free to propose topics
Action items
embedded above.