2024-05-21 Device Location - Meeting Minutes
Date
May 21, 2024
Attendees & Representation
Type @ and your name to indicate your attendance
Community: @Jose Luis Urien Pinedo @Joachim Dahlgren @Akos Hunyadi @Cetin Alpaycetin @Fernando Prado Cabrillo @Javier Carro @Rafal Artych
Agenda
Approve previous meeting minutes
Approved
Overall topics
Open issues and PRs
Minutes
Overall topics
TSC: Reactivated discussion Commonalities/issues/171: Revise the device object definition to simplify it
Discuss use of device model in our APIs
New
Issue: [Geofencing] Support for polygon area type
Discussion:
Makes sense from a dev perspective but makes implementation more complicated
Possibly we may need this as well for Location Verification, but not necessarily
Align schemas with Location retrieval and Population Density in case we accept PR. In the future it would make sense to move it to Common artifacts.
Decision: Keep issue open and discuss there
Issue: Align security scope with guideline
Along with previous issue: Based on the new explicit subscriptions guideline in commonalities, change name of geofencing API to include the keyword subscriptions
PR: update base-path & security-scope for geofencing-subscriptions → fix both PRs, the old one changing the API name and the new one adapting also event name.
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?
Discussion:
Having the radius as 1 does not seem like a practical problem since even GPS often have a few meters of error margin
From a documentation perspective clients might think that using a point the precision will be high, which is not the case
We don't have use cases for precision lower than 1 meter
Decision: Keep the discussion open. Using circle with 1m radius as points seems enough
Related with location-verification:
Javier asks if the WG is open to lower the 2km minumum of radius for CIRCLE location-verification
There were issues open regarding this topic in the past where several problems and discussions raised
Javier will open a new issue to continue the discussion
Ongoing
Test plans
Dedicated Commonalities workshop
New Commonalities PR: Enhance API-Testing-Guidelines.md
Once new guidelines and consensuated, all test plans will need to be updated
For this meta-release it is still not mandatory to have the completed test plans, but the more we have advanced, the better
PR: Testing plan for location verification
Used as example for Commonalities Issue Enhancement of the Testing Guidelines, but has to be updated
Discuss licensing header
To be aligned in Commonalities as not sure we have ruling for this.
(Meeting Action) Akos will check internally → Feedback?
Other
APIs error alignment
@Rafal Artych has prepared a confluence page with Http Errors in different APIs and a comparision with the CAMARA_common.yaml to check differences and misalignments so we can adapt the guidelines: Error response guidelines
Regarding this topic @Fernando Prado Cabrillo created a PR to fix some of this misalignments: https://github.com/camaraproject/Commonalities/pull/174
(Meeting Action) : Chapter 6 of the Commonalities design document need to be review. @Jose Luis Urien Pinedo will check with Pedro Diez Garcia for that.
Waiting for Commonalities outcome, still open there
Review status of the following issues, agenda copied from last meeting minutes (except text in italic)
Are we happy with security scope for geofencing
Is it covered by Align security scope with guideline disccussed above? → Probably, let's double check with @Ludovic Robert
Last meeting:
Scope name should reflect the data 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)
Open pull request in Commonalities update-design-doc-with-explicit-sub-scope-changes by shilpa-padgaonkar · Pull Request #177 · camaraproject/Commonalities (github.com)
Proposal is to add scope per even-type additionally to scope managing the right to create a subscription.
(Meeting Action): @Ludovic Robert will create an issue.
Geofencing - Adding a value in Termination Reason value enum
Discussion in progress in Commonalities: camaraproject/Commonalities#153
Related issues in DeviceStatus and QoD
Still open, PR ongoing
Subscription related issues → Dedicated workshop took place
Geofencing API - Add Subscription type 'area-left-or-entered' to subscribe to both event in one time
Geofencing API - Defining a standard behavior for first event
Issue in Commonalities Issue 140
Proposal to tackle open subscription issues Common proposal to tackle subscription-based open issues. · Issue #185 · camaraproject/Commonalities (github.com) - mains points:
Align our subscription model with CloudsEvents subscriptions one
Introduce a
status
attribute in the template as we have fair UCs that can leverage this (Retrieve expired subscriptions for monitoring, deactivate a subscription if an user revoked her/his consent, etc...). API subproject could decide to use it or not.Improve the model to allow consumers to subscribe to more than one event types with a single subscription but at least for the first meta-release we enforce to have only event type per subscription. After this first meta release decision to handle several event types in one subscription request should be discussed at API sub projet level
Add
filters
and it's up to API Project to use it. We recommend to be very cautious as it add complexity so it should be keep for very relevant UC.Add
initialEvent
inconfig
as well to manage request to get event when current situation of a device corresponds to the subscriptions type. .
A template yaml is available for review here: Create subscription-notification-template.yaml by bigludo7 · Pull Request #189 · camaraproject/Commonalities (github.com)
Geofencing API - Add "format: uri" to notificationUrl
Issue in commonalities
No progress in commonalities
On hold discussions
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
On issue #133 we probably need to have a base agreement for Geofencing guidelines
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.
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://lf-camaraproject.atlassian.net/wiki/display/CAM/2024-03-21+TSC+Minutes
AOB