Versions Compared

Old Version 13

changes.mady.by.user Diego González Martínez

Saved on

compared with

New Version Current

changes.mady.by.user Tanja de Groot

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

RepresentativeOrganizationRole 

Herbert Damker 

Deutsche Telekom AG

TSC Chair, Active Maintainerx

Shilpa Padgaonkar

Deutsche Telekom AG

Active Maintainerx

Jan Friman 

Ericsson

Active Maintainer 

Toshiyasu Wakayama

KDDI

Active Maintainerx

Ludovic Robert 

Orange

TSC Deputy Chair, Active Maintainerx

Adnan Saleem 

Radisys

EUC Representative 

Doug Makishima 

Summit Tech

EUC Representative 

Diego González Martínez

Telefonica

Active Maintainerx

Jose Luis Urien

Telefónica

Active Maintainerx

Mahesh Chapalamadugu

Verizon

EUC Representative 

Eric Murray 

Vodafone

TSC Deputy Chairx

Kevin Smith 

Vodafone

Active Maintainerx

Chris Howell 

Vonage

Active Maintainer 
George Glass

TM Forum

TM Forum Representative 

Olta Vangjeli 

TM Forum

TM Forum Representativex

Henry Calvert 

GSMA

GSMA Representativex

Mark Cornall 

GSMA

GSMA Representativex

...

  • 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

...

  • 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 (Link to the , potentially based on the existing file-header).txt template. Target to close on this topic for next TSC crossed fingers 

...

 


...

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.
    Alignment with Release Management and
    • ICM
    for Release Candidate

Identity & Consent Management (Axel Nennker )

...

  • 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:
    • Presented Present in all-hands call newt next week (June 13th), featuring an example for the release tracking pages
    • Send a communication to "all" mailing list to informe 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 Cancelled and replaced by action on combined M0/M1 announcement email.