2026-02-18 Population Density Data - Meeting Minutes
CAMARA Population Density Data API - Follow-up meeting #28 - 2026-02-18
Attendees
Name | Company |
|---|---|
@Ludovic Robert | Orange |
@Alberto Ramos Monaga | Telefónica |
@Istvan Andras Horvath | Ericsson |
|
|
|
|
Approval of previous meeting minutes & documentation (1)
Meeting minutes: OK
Agenda
Approval of previous meeting minutes and meeting agenda
Open issues and PRs
Agenda: Fall26 meta-release scope
Timeline and next steps
AoB
Open Issues & PRs
# | Company | Summary | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
TEF | Draft until next meta-release: Delete additional text for RFC date time format | |||||||||||||||||||
TEF | Issue (Release Management) - Align asynchronous response with CloudEvents format to ensure compliance with Commonalities r3.3 The asynchronous response in PredictiveConnectivityData and Population Density Data does not comply with Commonalities r3.3 (uses application/json instead of CloudEvents). Status: An issue (#533) has been created in the commonalities group to address this issue. Once a decision has been made, it will be applied to this issue Feb 17, 2026: The fix has been uploaded to commonalities: #575. It explains that an asynchronous response is not really an event. And that although it is recommended to use `sink` and `sinkCredential`, the cloudevents model should not be used. Pending action: Telefónica will propose a PR with the new changes. | |||||||||||||||||||
Orange | Some model names use SNAKE_CASE in place of CamelCase: NO_DATA, LOW_DENSITY, and DENSITY_ESTIMATION models do not respect naming conventions defined in Commonalities - Pending action: Ready to include in new version. | |||||||||||||||||||
Population Density Data Group | Scope for Fall26 release (in preparation): Please add your proposals in the comments and open issues if needed. Review or propose a deadline for finalizing the scope:
Deadline: around March until we’ve the draft PR with the latest changes. | |||||||||||||||||||
TEF | Add new PopoulationDensityData User Story: Add the Population Density Data user story based on the latest API changes and to follow the stable requirements phasing. Pending action: Review | |||||||||||||||||||
Orange | Provide a list of GeoHashes in the API request: Add support for Goal: Improve request precision and predict response volume. Note: This would complement, not replace, the current area definition method. Pending action: TEF will implement the changes in the next PR agreed with the discussion | |||||||||||||||||||
Governance | Reset API and test code version information in main branch to wip The main branch of this repository contains API definitions and/or test files with version references that are not yet reset to Can be close after merge PR#108 |
API proposal review (2)
Agenda 1: Fall26 meta-release scope - Issue created: #109
Note: APIs are recommended to target the Fall26 Meta-release, but some exceptions can be discussed.
For these exception, the concerned APIs should be aware that the Spring26 schedule is very tight.
Recommended to skip Spring26, but exception may exist e.g. for APIs that dropped from the Fall25 meta-release.
AoB (3)
N/A
Discussion Summary
# | Summary | Status/conclusion |
|---|---|---|
Stable readiness prerequisites — test coverage sufficiency and evidence (tests ↔ behaviours mapping + test result statement) | Proposed outcomes
Context |
Next steps
N/A
Action Points
TEF review implications with commonalities “Authentication mechanism based on pre-shared information for event notification by @m-nahum in #580”
Hi @Ludovic Robert, I made the review with the tech team regarding to the commonalities issue:
The PR introduces a new
sinkCredentialType,PRIVATE_KEY_JWT, for event notifications, based on pre-shared information between the API Consumer and the API Provider (e.g., token endpoint, client ID, JWKS URI). The goal is for the provider to mint new access tokens when the current one expires, without effectively “killing” the subscription due to token expiry.In Population Density Data, we already have an asynchronous callback pattern using
sink+sinkCredential. However, I would generally sayPRIVATE_KEY_JWTis not a priority for this API, because it is essentially request/response with a one-shot callback. If the async response is typically delivered quickly, introducingPRIVATE_KEY_JWTis overengineering (onboarding overhead, key/JWKS management, token endpoint integration, failure handling, etc.) for a single notification.It would only make sense if we genuinely expect long processing times and/or prolonged retries where the token could expire and we need subscription-like robustness—which is not the typical behavior described for this API.