2024-06-04 Device Location - Meeting Minutes

Owned by Jose Luis Urien Pinedo
Last updated: Jun 18, 2024
5 min read

Date

Jun 4, 2024

Attendees & Representation

Type @ and your name to indicate your attendance

Community: @Jose Luis Urien Pinedo @Ludovic Robert @Cetin Alpaycetin @Joachim Dahlgren @Rafal Artych @Fernando Prado Cabrillo @Javier Carro 

Agenda

Minutes

New

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: [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 from @Jose Luis Urien Pinedo @Joachim Dahlgren and @Ludovic Robert to consider that 1m radius will be good enough (and no need for Point)

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

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

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

    • 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

 

AOB

Action items