Page Comparison

...

...

...

...

...

DRAFT MINUTES

Date

18 Jun 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

...

• 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:
      • Geofencing API - Add "format: uri" to notificationUrl 
      • Geofencing API - Defining a standard behavior for first event
    • 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 deprected?

Ongoing (copied from last minutes)

• Issue: Consistency problem in Location retrieval regarding lastLocationTime cardinality
  • Review comments
  • Decision: Fix the yaml → lastLocationTime is mandatory and documentation must be updated
    • Ludovic Robert will do the PR

• Issue: Provide Test Defintion for Device Retrieval API
  • We already had a PR for Add Test Definition for location Retrieval
  • Discussion: 
  • Done for admin purpose
  PR will be done soon by Ludovic Robert 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
  • PR: Polygon area type added
  • From previous meeting:
    • 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. 
  • Discussion:
  • Review latest comments
  Related to discussion in Define guidelines for geofencing implementation
  • 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?
    • Proposal discussed:
      • We can have a 422 for synchronous response for lack of support  for a given area + add a terminationEvent reason for lack of support when the area assessment is performed asynchronously.
      • Action: have a dedicated issue for this.

• 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.
  • Ready for merge?
    • Yes !

• • : 
  • 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?From previous meeting:
  • 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
  • Discussion: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 ?
      • Javier Carro has still some discussion with legal team about privacy issue
      • Keep this point open.

Test plans

• 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
  • We discussed about the use of this Test Definition by GSMA for certification which will be one of the main 'consumer' of this work.

• PR: Testing plan for location verification
  
  • Used as example for Commonalities Issue Enhancement of the Testing Guidelines, but has to be updated

• PR: Geofencing feature file
  
  • Discuss licensing header
    • To be aligned in Commonalities as not sure we have ruling for this.
    • (Meeting Action) Akos will check internally → Feedback?
• PR: Add Test Definition for location Retrieval #119 (see New issue above)

APIs error alignment

• Rafal Artych has prepared a confluence page with Http Errors in different APIs and a comparaison with the CAMARA_common.yaml to check differences and misalignments so we can adapt the guidelines: Error response guidelines
• New PR in Commonalities
• Action Point: Review errors in our APIs after Commonalities guidelines are approved ?

Issues pending on  Commonalities outcome, review status and cleanup

• Are we happy with security scope for geofencing
  • Is it covered by Align security scope with guideline  discussed 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 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.
    • Action: Ludovic Robert This issue could be closed

• • • Any update?

• 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
  • Action: Once PR merged Ludovic Robert will close this issue

• Subscription related issues → Dedicated workshop took place
  

  • 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)
  • Action: Once PR merged Ludovic Robert will close this issue

• Geofencing API - Add "format: uri" to notificationUrl

  • Issue in commonalities
  • No progress in commonalities

On hold discussions

Implementation

Define guidelines for geofencing implementation (mentioned above)

• New comments
• 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
  • 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

Administrative Code Area

• Relate also with discussion about polygons for Geofencing, as it has similar implications.
• 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+MinutesNew 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

• PR: Geofencing feature file
  
  • Discuss licensing header: (Meeting Action) Akos will check internally → Feedback?
    • Check if Max is willing to do it.

AOB

Action items