DRAFT AGENDA
Attendees & Representation
TSC Members may indicate their attendance with an X in the far column | |||
---|---|---|---|
Representatives | Organization | Role | |
Deutsche Telekom AG | Maintainer | x | |
Deutsche Telekom AG | Maintainer | x | |
Ericsson | Maintainer | x | |
KDDI | Maintainer | x | |
Orange | Maintainer | ||
Nokia | Maintainer, Release Manager | x | |
Telefonica | Maintainer | x | |
Telefónica | Maintainer | x | |
Vodafone | Maintainer | x | |
Verizon | Maintainer | ||
EUC Representative | |||
Massimiliano Troiani | Verizon | EUC Representative | |
Summit Tech | EUC Representative | x | |
George Glass | TM Forum | TM Form Representative | |
GSMA | GSMA Representative |
Community members may use @name tag to mark their attendance
Community: Axel Nennker Rafal Artych Pierre Close Markus Kümmerle Ravi Shekhar Jorge Garcia Hospital
LF Staff:
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-11-21 TSC Minutes
No comments - minutes approved
Action Item Review
See home page Technical Steering Committee for current list of open action items
…
Governance & Project Management issues
Agreed concept between CAMARA and GSMA for API Descriptions
Presentation by Markus Kümmerle
Proposal for consistent presentation of API descriptions
Updated API categories
API names defined in API Backlog table
Each API will have an associated API description, based on TM Forum template
Tanja de Groot raised point of keeping information up to date. Automation and reuse of information in GitHub preferred.
Sandbox / Incubated / Graduated Approach for API Repositories
ProjectCharter and ProjectStructureAndRoles updated (PR #161 merged)
Next Steps:
Work on API-Onboarding-and-Lifecycle.md (aka API-Onboarding)
not yet started, will be based on Proposal for the lifecycle of API Repositories with Sandbox/Incubated/Graduated/Archived
Restructuring/sorting of CAMARA Wiki pages (Independent Sandboxes vs Sub Projects with Incubated API Repositories)
see proposal below
Define first round of Incubated API Repositories
Candidates are all API repositories from Fall24 meta-release which have
Question to CAMARA Board: best opportunities to communicate / announce the first round of incubated APIs
Proposal for Wiki structure:
Requirements
Structure will fit for Sub Project with one API Repository and Sub Projects with multiple API Repositories (current structure works only for 1:1)
API Repository are first-class citizens beside Sub Projects, not be hidden underneath Sub Projects
Graduated and Incubated API Repositories are prominently placed and can be viewed on one glance
Sandbox API Repositories are separated into an own section
Proposed structure
Every API Repository has an own wiki page (similar to current Sub Project pages, with content of README in GitHub)
Parent page for the release trackers
If part of Sub Project (default for Incubated/Graduated): Link to the Sub Project wiki page for organizational information
If an Independent Sandbox: contains all needed information to get involved and contribute
Sub Projects Wiki pages
have a list of their API repositories
all information relevant across the API Repositories (meeting information & minutes, scope of the sub project, list of Maintainers, main contacts, …).
there could be an overview of released API versions (based on the release trackers within the API Repositories, so automatically updated)
The API Repository wiki pages will be sorted into the three top level sections, following today's “Sub Project” top level. The top level section will be then:
Getting Started with CAMARA
CAMARA Working Groups
CAMARA Sub Projects
(Graduated CAMARA API Repositories - to be added later)
Incubated CAMARA API Repositories
Sandbox API Repositories
(Archived API Repositories - to be added later)
API Backlog (Jorge Garcia Hospital)
No new API proposals forwarded to TSC for todays meeting
Consent URL API is pending as discussed within last TSC. From ICM 04/12:
Identified gap in current CAMARA standard for consent management when captured in a different device than targeted device.
TEF proposal focused on creating an ad-hoc mechanism separated from API access token generation.
DT proposing a OIDC adapted option (to be reviewed).
Proposal (TBC): To create a working group to discuss the most optimal solution ¿?
Reminder that backlog table is available and updated (weekly):
Commonalities (Rafal Artych )
Status r2.1 (with 0.5.0-alpha.1):
Release PR ready for final review, main CHANGELOG points:
Added
Common 'area' data-type added to CAMARA_common.yaml by @tlohmar in #315
Security and Privacy Considerations for Filtering in API Design Guidelines by @rartych in #331
Security scheme added to CAMARA_common.yaml by @rartych in #335
VERSION.yaml file added to indicate Commonalities version by @rartych in #339
Filtering for boolean guideline and examples in API Design Guidelines by @rartych in #336
Guidelines on the coverage of error codes in API-Testing-Guidelines by @jlurien in #343
Changed
Normalization of error status and code allowed values using
enum
by @PedroDiez in #316Guidelines for subscription and event notification in API Design Guideliness by @bigludo7 in #313 main changes:
updated
terminationReason
in event notification type "subscription-ends"updated description of
sink
andsinkCredential
attributes for subscriptionadded rules for subscriptions with device identifier attribute
added section 11.7 Resource access restriction relevant to subscriptions
added clarification on
expiresAt
attribute for subscription
Updated error codes and changed
info.description
template for device / phone number identifiers in Appendix A in API Design Guideliness by @eric-murray in #324Guidelines regarding mandatory error
status
and alignment of error codes related to identifiers in API Design Guideliness by @PedroDiez in #329
Fixed
To be added before RC:
Remaining PRs:
Cleanup and slim down design guidelines document
Linting rules update
Corrections to alpha version
Volunteers needed to migrate linting rules to reusable workflows:https://docs.github.com/en/actions/sharing-automations/reusing-workflows
Review and test the workflows
Should we use https://github.com/camaraproject/.github or dedicated repository as workflows repository?
Identity & Consent Management (Axel Nennker Jesús Peña García-Oliva )
r2.1 created (with 0.3.0-alpha.1)
https://github.com/camaraproject/IdentityAndConsentManagement/issues/224
https://github.com/camaraproject/IdentityAndConsentManagement/issues/215
Sender-Constrained Access Tokens with DPoP
Release Management (Tanja de Groot)
r2.1 PR for RM repository approved and released.
Spring25 meta-release
Commonalities: 0.5.0-alpha.1 PR ready. M2 rc expected by Dec 9th
ICM: 0.3.0-alpha.1 now available
M2: Risk of delay due to delayed M1- need more time to cover all changes.
M3: Risk of being delayed into 2025.
Fall24 meta-release
M6 was announced on RM mailing list & codeowners list following the release of the RM repo
Fall24 meta-release is now closed.
Patch updates of APIs can be done as needed. Discussion is if it should be a new API release tracker or not (issue #125).
Any Other Business
...
Next Meeting
Next TSC Meeting will be on December 19th, 15:00 UTC (16:00 CET, 07:00 PT)
Specific agenda topics backlog:
...
...