...
...
...
...
DRAFT
...
MINUTES
Date
Attendees & Representation
Type @ and your name to indicate your attendance
Community: Ludovic Robert Fernando Prado Cabrillo Akos Hunyadi Jose Luis Urien Pinedo Surajj Jaggernath Javier Carro Joachim Dahlgren Rafal Artych
Agenda
- Approve previous meeting minutes
- Approved? Yes - no objection.
- Open issues and PRs
Minutes
...
- Scopes for meta-release Fall24, to be linked in DeviceLocation API Release Tracking
- Scope of Location Verification API for Fall24 CAMARA Meta Release
- Scope of Location-Retrieval for Fall24 CAMARA Release
- Scope of Geofencing Subscriptions API for Fall24 CAMARA Meta Release
- Discussion during meeting:
- About initial vs stable maturity level. Our understanding (José/Ludovic) is that for the first meta-release we use the initial maturity level. But this could be confirmed as the release process management set in.
- Regarding milestone we can target M3 around mi-July & M4 for end of August.
- About Test Definition we should provide at least scenario for basic UCs (for M4).
- Geofencing - Align with new model
- PR: Update the geofencing subscription models to align on CAMARA commonalities
- Decision in Commonalities to include all options for protocol and credentialType, even if in this version only HTTP and ACCESSTOKEN are supported
- Limits for array types (number of events per subscription) will be set to minItems = 1 (permanently), and maxItems = 1 (for this version)
- Updated as well in Commonalities: camaraproject/Commonalities#235
- Fixes as well past issues:
- Ready for final review
- PR: Update the geofencing subscription models to align on CAMARA commonalities
- Simplification of Device object - short term solution
- Should device be made optional?
- Team decision: It's quite safe - OK for the team.
- Akos raised the point about requirement to enhance documentation in the API - should be global for all CAMARA API
- Rafal indicated that it would be handled & finalized in Commonalities
- Team decision: It's quite safe - OK for the team.
- Should networkAccessIdentifier be deprected?deprecated?
- Joachim Dahlgren asked to keep it.
- For Telefonica & Orange it could be removed.
- Rafal explained that in commonalities we propose to keep it but not use it
- Team Decision: We keep it but not use it. We will add a test scenario for that.
- Discussion during meeting
- Discussion about the CIBA flow.
- Should device be made optional?
Ongoing
- Issue: [Geofencing] Support for polygon area type
- PR: Polygon area type added
- Decision about adding support or not, making this support mandatory or not ?
- Does the following statement could be acceptable for first meta release: "We add the polygon. Circle management is mandatory while polygon is nice to have. " ?
- We have still some time to discuss this.
- Does the following statement could be acceptable for first meta release: "We add the polygon. Circle management is mandatory while polygon is nice to have. " ?
- How to managed not supported polygon:
- Team Decision: This one could be backlog-ed. Not for first meta release.
- New issue: Geofencing - Manage when telco is not able to manage geofencing on the requested area
- Proposal
- Sync response: Add a 422 error when the area is not 'manage-able'
- Async: Add a terminationReason to indicate that the the area is not 'manage-able'
- Proposal
- Can we propose PR?
- Team Decision: Sounds good to create the PR
- /!\This one need to be managed for the first meta release
- Team Decision: Sounds good to create the PR
- New issue: Geofencing - Manage when telco is not able to manage geofencing on the requested area
- Issue: [Location-Retrieval]: add
POINT
as possible Location response- Some comments on the issue. Minimum right now is a CIRCLE with radius=1m, Is it not enough?
- Discard point and rely on Circle?
- Agreement (previous meeting) from Jose Luis Urien Pinedo Joachim Dahlgren and Ludovic Robert to consider that 1m radius will be good enough (and no need for Point)
- No further comments, can we close issue?
- Action: Akos will check with Max if we can close it.
- Related topic raised in last meeting, no new issue:
- Should we lower minimum radius for location-verification?
- Javier Carro has still some discussion with legal team about privacy issue
- Any update?
- Should we lower minimum radius for location-verification?
Geofencing - Adding a value in Termination Reason value enum
- New dedicated issue in Commonalities: Adding
SUBSCRIPTION_DELETED
as aterminationReason
[event-subscription-template.yaml] - Action: Approved by usual suspects in Commonalities so we wan apply it
- New dedicated issue in Commonalities: Adding
Define guidelines for geofencing implementation
- No new comments
- Last meetinngmeeting:
- Akos & José proposed some suggestion - in particular to improve the subscription to allow consumer to indicate the 'reliability' expected.
- Ludovic also raised the point above UC where we are not able to send any notification.... and we need to inform the consumer.
- Discussion/Action: DT team can move forward with a PR with the proposal about adding triggerSensibility
- New thoughts, can we create PR?
- Not discussed with the team - Probably to be shift to the backlog.
- Location Verification Implementation Guidelines
- No new comments but should be addressed for next meta-release
...
- PR: Add Test Definition for location Retrieval #119
- Aligned with initial version of location-verification. It may be needed to be aligned with the latest version
- Action: Ludovic will do
- Aligned with initial version of location-verification. It may be needed to be aligned with the latest version
- PR: Geofencing feature file
- Discuss licensing header: (Meeting Action) Akos will check internally → Feedback?
- Check if Max is willing to do it.
- Discuss licensing header: (Meeting Action) Akos will check internally → Feedback?
AOB