DRAFT AGENDA
Date
Attendees & Representation
Type @ and your name to indicate your attendance
Community: Ludovic Robert Fernando Prado Cabrillo Akos Hunyadi
Agenda
- Approve previous meeting minutes
- Approved?
- Open issues and PRs
Minutes
New
- Scopes for meta-release Fall24, to be linked in DeviceLocation API Release Tracking
- 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?
- Should networkAccessIdentifier be deprected?
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:
- 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?
- 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?
- 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]
- New dedicated issue in Commonalities: Adding
Define guidelines for geofencing implementation
- No new comments
- Last meetinng:
- 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?
- 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
- PR: Geofencing feature file
- Discuss licensing header: (Meeting Action) Akos will check internally → Feedback?
AOB