2024-06-18 Device Location - Meeting Minutes
DRAFT MINUTES
Date
Jun 18, 2024
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
New
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 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
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
Should networkAccessIdentifier be 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.
Ongoing
Issue:ย [Geofencing] Support for polygon area type
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.
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'
Can we propose PR?
Team Decision: Sounds good to create the PR
/!\This one need to be managed for the first meta release
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?
Geofencing - Adding a value in Termination Reason value enum
New dedicated issue in Commonalities: Addingย SUBSCRIPTION_DELETEDย as aย terminationReasonย [event-subscription-template.yaml]ย
Action: Approved by usual suspects in Commonalities so we wan apply it
Define guidelines for geofencing implementationย
No new comments
Last meeting:
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
Test plans
Commonalities guidelines approved and merged.
All test plans should be updated to follow them.
PR: Testing plan for location verification
Example updated, ready for review
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
Discuss licensing header: (Meeting Action) Akos will check internally โย Feedback?
Check if Max is willing to do it.
ย
AOB