DRAFT AGENDA
Date
Attendees & Representation
Type @ and your name to indicate your attendance
Community:
Agenda
- Approve previous meeting minutes → Remove DRAFT if no objections
- NEW: Release Management
- Open issues and PRs
Minutes
Release Management
- Meta-release Fall-24 - timeplan
- Meta-release Fall24
- Expected Deliverables from Device Location
- M1 - 30/04
- (Scope of Commonalities & ICM defined)
- Initiation of release cycle for API Sub Projects - definition of target version
- M2 - 15/06
- (Release candidate of Commonalities + ICM)
- M3 - 15/06
- First release candidate of Device Location, starting of test implementations
- M4 - 31/08
- Last (stable) release candidate of target release from Device Location
- Release Criteria fulfilled (incl validation of the release candidate by two independent implementation of the API)
- M5 - 15/09
- public release done
- M1 - 30/04
- As this subproject develops several APIs, we are impacted by API Release Planning, section "API family"
- We may have to consider having several Github repos, one per API, in APIs have to evolve independently, with its own versioning
New
- New PR to test new linting rules: Bad OAS spec
- Failed as expected
- Can be closed
Ongoing
- Issue: Semantics of the absence of 'maxAge'
- 2 options presented by Vodafone discussed in thread
- TEF and Orange comment in favour of option 1
- PR: Geofencing feature file
- Discuss licensing header
- To be aligned in Commonalities as not sure we have ruling for this.
- Akos will check internally → Feedback?
- Some new comments
- Discuss licensing header
- Issue: Cyclic reference in location-verification
- No new comments
- Can be closed
Add Test Definition for location Retrieval #119
- Issue in Commonalities to discuss Enhancement of the Testing Guidelines by TEF
- Jose from TEF will upload an example of Location Verification ATP once the commonalities guidelines are approved → Final internal review in TEF, will be shared this week
- Toyeeb to check with GSMA conformance → Update?
- Orange is working on the testing too and will provide feedback soon. → Update?
- Issue in Commonalities to discuss Enhancement of the Testing Guidelines by TEF
Waiting for Commonalities outcome, still open there
- Are we happy with security scope for geofencing
- Scope name should reflect the date provided by the notification (not
geofencing:subscriptions:write
but more precise likegeofencing:subscriptions:read-location
) - Discussion on this topic in progress in Commonalities (camaraproject/Commonalities#163)
- Any update?
- Scope name should reflect the date provided by the notification (not
Geofencing - Adding a value in Termination Reason value enum
- Discussion in progress in Commnonalities: camaraproject/Commonalities#153
- Related issues in DeviceStatus and QoD
- Any update?
- Subscription related issues → Proposal in TSC to setup a dedicated workshop
Geofencing API - Add "format: uri" to notificationUrl
- Issue in commonalities
- Any update?
On hold discussions
Administrative Code Area
- Issue #83, with formal requirements from GSMA Product track
- Document uploaded by TEF with a proposal.
- Review priority and next steps → Clarify this:
- More generally probably we need to have feedback loop with GSMA team about API work (and review the priority as focus could change)
- Done during last TSC - see here: https://wiki.camaraproject.org/display/CAM/2024-03-21+TSC+Minutes
- More generally probably we need to have feedback loop with GSMA team about API work (and review the priority as focus could change)
Implementation
Define guidelines for geofencing implementation
- We need more comments from the team
- Connected with Issue #85. A document with implementation guideline should cover this also.
- As requested by Joachim, issue #85 will remain open until TEF uploads the document with more detail or the information is added to an API_documentation file to keep in the repo for future references.
- Joachim: Should be also aligned/synchronized with Geofencing
- As requested by Joachim, issue #85 will remain open until TEF uploads the document with more detail or the information is added to an API_documentation file to keep in the repo for future references.