Open
Conversation
ALIIQBAL786
requested review from
Noel-Wirzius-DT,
caubut-charter,
eric-murray and
jgarciahospital
as code owners
Contributor
|
Hi @ALIIQBAL786 , Thanks for creating the Backlog issue and the API proposal PR, and for sharing the supporting material. It’s good to see a potential new API that could be incorporated into the CAMARA API family. I’ll include the proposal in next week’s Backlog agenda. Before the session, a few quick points that came up while reading the proposal (we can cover everything live in the Backlog call):
|
Contributor
Author
|
[like] Ali Iqbal reacted to your message:
…________________________________
From: Alberto Ramos Monagas ***@***.***>
Sent: Friday, March 6, 2026 1:19:05 PM
To: camaraproject/APIBacklog ***@***.***>
Cc: Ali Iqbal ***@***.***>; Mention ***@***.***>
Subject: Re: [camaraproject/APIBacklog] V2X Exposure API proposal (PR #303)
[https://avatars.githubusercontent.com/u/194822567?s=20&v=4]albertoramosmonagas left a comment (camaraproject/APIBacklog#303)<#303 (comment)>
Hi @ALIIQBAL786<https://github.com/ALIIQBAL786> ,
Thanks for creating the Backlog issue and the API proposal PR, and for sharing the supporting material. It’s good to see a potential new API that could be incorporated into the CAMARA API family. I’ll include the proposal in next week’s Backlog agenda.
Before the session, a few quick points that came up while reading the proposal (we can cover everything live in the Backlog call):
* CAMARA capability vs MEC wrapper: today it can read as “a CAMARA façade over ETSI MEC 030 via a Transformation Function”. It would help to explicitly define the northbound service semantics (key entities/resources and portability expectations) and keep the TF/MEC mapping as implementation guidance.
* Service API vs Operate/Platform boundary: terms like “provisioning” (especially anything that sounds like radio/network provisioning) may trigger out-of-scope concerns. Please make clear this is developer-facing service exposure (service-level configuration/info needed by apps/vehicles), not network management.
* Overlap positioning: since you reference QoS/QoD and other CAMARA APIs, please clearly state what is in-scope for V2X Exposure and what is out-of-scope (covered by existing CAMARA APIs). Otherwise the discussion risks getting stuck on “this API does too much”.
* Subscriptions alignment: if you propose a unified subscription entry point for multiple event types, make sure it follows CAMARA/Commonalities subscription patterns. Even before YAML, a short description of subscription semantics (filters/geo scoping, event types, error model) in the PR will make the review much more concrete.
—
Reply to this email directly, view it on GitHub<#303 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXJ7QGULJH26H2MVZMGMJYD4PLF4TAVCNFSM6AAAAACWJGIE2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAMJRG4YDAOBZG4>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Contributor
Author
|
Thank you Alberto,
Will discuss it with our ETSI team 👍.
Warm Regards,
Ali Iqbal
Engineer II
X Flow Software Technology LLC
+92-318-638-2001 (GMT +5)
***@***.******@***.***>
www.xflowresearch.com<http://www.xflowresearch.com/>
[cid:b1214871-e42d-4ee9-a1b8-04fd05008a46]
…________________________________
From: Alberto Ramos Monagas ***@***.***>
Sent: Friday, March 6, 2026 6:19 PM
To: camaraproject/APIBacklog ***@***.***>
Cc: Ali Iqbal ***@***.***>; Mention ***@***.***>
Subject: Re: [camaraproject/APIBacklog] V2X Exposure API proposal (PR #303)
[https://avatars.githubusercontent.com/u/194822567?s=20&v=4]albertoramosmonagas left a comment (camaraproject/APIBacklog#303)<#303 (comment)>
Hi @ALIIQBAL786<https://github.com/ALIIQBAL786> ,
Thanks for creating the Backlog issue and the API proposal PR, and for sharing the supporting material. It’s good to see a potential new API that could be incorporated into the CAMARA API family. I’ll include the proposal in next week’s Backlog agenda.
Before the session, a few quick points that came up while reading the proposal (we can cover everything live in the Backlog call):
* CAMARA capability vs MEC wrapper: today it can read as “a CAMARA façade over ETSI MEC 030 via a Transformation Function”. It would help to explicitly define the northbound service semantics (key entities/resources and portability expectations) and keep the TF/MEC mapping as implementation guidance.
* Service API vs Operate/Platform boundary: terms like “provisioning” (especially anything that sounds like radio/network provisioning) may trigger out-of-scope concerns. Please make clear this is developer-facing service exposure (service-level configuration/info needed by apps/vehicles), not network management.
* Overlap positioning: since you reference QoS/QoD and other CAMARA APIs, please clearly state what is in-scope for V2X Exposure and what is out-of-scope (covered by existing CAMARA APIs). Otherwise the discussion risks getting stuck on “this API does too much”.
* Subscriptions alignment: if you propose a unified subscription entry point for multiple event types, make sure it follows CAMARA/Commonalities subscription patterns. Even before YAML, a short description of subscription semantics (filters/geo scoping, event types, error model) in the PR will make the review much more concrete.
—
Reply to this email directly, view it on GitHub<#303 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXJ7QGULJH26H2MVZMGMJYD4PLF4TAVCNFSM6AAAAACWJGIE2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAMJRG4YDAOBZG4>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
Add one of the following kinds:
What this PR does / why we need it:
This PR introduces a new API proposal for a CAMARA V2X Exposure API in the API Backlog.
The proposal explores how ETSI MEC V2X Information Service capabilities can be exposed through CAMARA northbound APIs, enabling developers to access V2X services through a simplified and standardized interface.
The API is motivated by smart mobility and smart city use cases, including connected emergency vehicles, collision risk detection, and cooperative traffic services. The proposal is based on ongoing projects such as CASCAD-e and ToMOVE (City of Turin), which demonstrate edge-enabled mobility scenarios using MEC infrastructure.
The goal of this proposal is to gather feedback from the CAMARA community and evaluate the potential creation of a new V2X API family within the project.
Which issue(s) this PR fixes:
Fixes #302
Special notes for reviewers:
This PR provides the initial proposal for discussion in the API Backlog Working Group.
Feedback from the community is welcome regarding scope, alignment with existing CAMARA APIs, and potential collaboration with ETSI MEC V2X specifications.
Changelog input
Additional documentation
This section can be blank.