Attendees & Representation
...
| 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 (Toshiyasu) 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 | X |
| Diego González Martínez | Telefonica | Active Maintainer | X |
| Jose Luis Urien | Telefónica | Active Maintainer | X |
| Mahesh Chapalamadugu | Verizon | EUC Representative | X |
| Eric Murray | Vodafone | TSC Deputy Chair | x |
| Kevin Smith | Vodafone | Active Maintainer | x |
| Chris Howell | Vonage | Active Maintainer | |
| George Glass | TM Forum | TM Form Representative | |
Mark Cornall (representing Proxy for Henry Calvert) | GSMA | GSMA Representative | x |
LF Staff: Casey Cain Evan Harrison
Community: Shuting Quing ; Jin Xu (Huawei), Kai Zhang (Huawei), Evan Harrison, Ming Hui, Kai Zhang, Mark Cornall, Shuting Qing Pierre Close, Ramesh Sh, ShanmugasundaramTanja de Groot,
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. |
...
- 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
- 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 ( - It is possible to have several APIs but must be very close and released together.
- Discussion about use of "on-demand" label - rationale for this?
- Application proposal: APIproposal_NetworkSlicing_ChinaUnicom.md
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.
...
- Initial input info by Diego
- Agreements regarding releases:
- V0.1 to be generated. All issues marked as required for the release are solved
- 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. TEF has offered to provide initial draft covering CAMARA scope and needs; MobileConnect existing profile to be used as valid reference. DT also offered to be active here and provide a contribution.
- 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
...