2024-04-23 Device Location - Meeting Minutes

Date

23 Apr 2024

Attendees & Representation

Type @ and your name to indicate your attendance

Community: Fernando Prado Cabrillo Ludovic Robert Joachim Dahlgren Cetin Alpaycetin Rafal Artych 

Agenda

• Approve previous meeting minutes 
  • approved.
• 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
  • As this subproject develops several APIs, we are impacted by API Release Process, 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
    • 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
    • Both Ericsson and DT agree aswell. 
    • (Action) Ludovic Robert will raise PR to include the required documentation

• 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

• 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? 

Waiting for Commonalities outcome, still open there

• Are we happy with security scope for geofencing
  • Scope name should reflect the data provided by the notification (not geofencing:subscriptions:write but more precise like geofencing: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.

• 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

• Subscription related issues → Proposal in TSC to setup a dedicated workshop

  • Geofencing API - Add Subscription type 'area-left-or-entered' to subscribe to both event in one time

    • Issue in Commonalities Subscription-Issue2: Allow event consumers to subscribe to more than one event types with a single subscription
  • 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 in config 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

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

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

AOB

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

Action items

• Ludovic Robert will raise PR to include the required documentation regarding the use of "maxAge" parameter
•