Date

Oct 22, 2024

Attendees & Representation

Community: @Ludovic Robert @Jose Luis Urien Pinedo @Cetin Alpaycetin @Huub Appelboom @Akos Hunyadi @Joachim Dahlgren @Surajj Jaggernath @Rafal Artych

Agenda

Antitrust Policy

• Approve previous meeting minutes

  • Approved ? No comments - approved

• Open issues and PRs

Minutes

Release patch r1.3

• To be considered. Candidate fixes:

  • Issue:Update errormessage for unsupported device identifieres Small typo in GENERIC_422_UNSUPPORTED_DEVICE_IDENTIFIERS - example, PR: Update errormessage for unsupported device identifieres

    • New PR reviewed, it could be merged into main

  • Fix links for geofencing-subscriptions in README, add links also to Changelog

  • Decision: We can wait to have something more relevant to create a new patch as it is cosmetic.

  • New issue created to have a tracking: Scope for potential patch r1.3

  • Discussion about having a deadline for the project. We can wait more time before to close this release. This topic will be addressed during each calls.

New

• [geofencing-subscriptions]: MultieventSubscriptionNotSupported instead of PermissionDenied.

  • PR: Correct the example for sub - initialEvent and error MULTIEVENT_SUBSCRIPTION_NOT_SUPPORTED and some typos.

  • The name of the example does not correspond with the content

  • Many typos corrected

  • Makes sense to be corrected to main and be potentially added to future patch r1.3

  • Meeting outputs: No comment from the team - @Jose Luis Urien Pinedo will approve & merge

Old

• Issue [Retrieval] What is the expected behavior when maxAge value is above threshold supported by the operator?

  • Answered by @Cetin Alpaycetin

  • No further interaction, it could be closed - Closed

• Update location-retrieval with add maxSurface management

  • After issue How to understand the response parameter area in the device retrieval API

  • Review and comment

    • Add a note in the yaml for the minimum → Pending @Ludovic Robert ?

    • We will wait before to merge to avoid collision with Meta release patch

• Support of Multi-SIM lines in DeviceLocation APIs

  • Derived from camaraproject/Commonalities#302

    • Some new comments but no conclusions

  • Device Location APIs are specially problematic as location is linked to a physical device, not to a phone number 

  • Discussion during last meeting:

    • The issue has a technical aspect  but it is more important for Product Management.

    • For Location-verification probably we can consider that if any device is in 'the zone' then the result will be true. Perhaps same for geofencing.

    • For location-retrieval the issue is more critical as sending back an array of location is probably not a good solution

    • We need to think about UC in particular as location retrieval is probably used for non-personal device (for sensitive reason) so is there really a requirement for multi-sim for this API?

    • Action for each company to work with product team to refine the requirement

• The issue to improve Geofencing with LOOSE, MODERATE, STRICT 'flavor' is still open #133

  • From previous meeting: Should be part of the discussion for next version.

  • @Ludovic Robert is working on this topic within Orange.

  • Issue still relevant

Waiting for commonalities

• Add an “Area” data-type into CAMARA_common.yaml

  • No new comments

  • From previous meeting: 

    • related issue in Commonalities

    • New PR in Commonalities: https://github.com/camaraproject/Commonalities/pull/315

      • To be reviewed

• Evolution of subscription guidelines that may affect geofencing-subscriptions:

  • Resource-based subscription – GET /subscriptions using a 3-legged access token

  • Resource-based subscription – guidelines for expiration time set by API operator policy

  • @Ludovic Robert is working on a global PR for commonalities.

    • Any update?

      • Action: @Ludovic Robert will create an issue to discuss data minimization for the geofencing

      • Request to the team to track progress & comment here (WIP) Subscription & events for Commonalities 0.5.0 by bigludo7 · Pull Request #313 · camaraproject/Commonalities (github.com)

AOB

From latest TSC:

• Proposal to schedule all meeting within CAMARA anchored on UTC

  • See https://github.com/camaraproject/Governance/issues/164

  • Decisions:

    • No opposition to switch to UTC → All meetings will be anchored in UTC

    • Each community decides on which UTC time they want to anchor their meeting

For DeviceLocation current slots are:

• During CEST: 7:00 UTC → If we choose this one all year around, meetings would be at 9:00 during CEST and at 8:00 during CET

• During CET: 8:00 UTC→ If we choose this one all year around, meetings would be at 10:00 during CEST and at 9:00 during CET

Action: Take a decision during meeting or open a discussion in Github

From the team feedback we have preference for the second proposal from José, Joachim, Akos and Ludovic

Action items

Next meeting

@Jose Luis Urien Pinedo and @Ludovic Robert will be not available for Nov 5, 2024 meeting - Meeting will be skipped.