Skip to content

Add edgeCloudFootprint to EdgeCloudZone response schema#27

Open
clundie-CL wants to merge 1 commit intocamaraproject:mainfrom
cablelabs:task/25-add-edgeCloudFootprint-to-EdgeCloudZone-schema
Open

Add edgeCloudFootprint to EdgeCloudZone response schema#27
clundie-CL wants to merge 1 commit intocamaraproject:mainfrom
cablelabs:task/25-add-edgeCloudFootprint-to-EdgeCloudZone-schema

Conversation

@clundie-CL
Copy link

What type of PR is this?

  • enhancement/feature

What this PR does / why we need it:

This PR introduces an optional edgeCloudFootprint field to the EdgeCloudZone schema, enabling API consumers to understand the geographic coverage area that an edge cloud zone is intended to serve.

Key points:

  • Not physical proximity: The footprint represents a logical service region where devices are likely routed based on network topology and operator policies—not the physical location of underlying infrastructure. As discussed in the API working group, "what the API gives you is not just based on location proximity to a UE. It's actually based on how the data is getting routed."

  • Use cases:

    1. Visualization: Display edge zones on maps in orchestration/management portals
    2. Data governance: Identify territorial boundaries for data residency requirements (e.g., EU regulations requiring data to remain within specific regions or even counties)
    3. Coarse zone selection: Programmatically filter zones based on coverage overlap with target service areas
  • Privacy-preserving: The footprint describes the service area, not the physical infrastructure location

Schema additions:

  • edgeCloudFootprint field on EdgeCloudZone (optional)
  • Area, AreaType, Circle, Polygon, PointList, Point, Latitude, Longitude schemas copied from CAMARA_common.yaml patterns

Which issue(s) this PR fixes:

Fixes #25

Special notes for reviewers:

  1. The Area/Circle/Polygon schemas are copied directly into this spec rather than using $ref to CAMARA_common.yaml. A separate issue will be filed to address consolidating these common types via external reference once approved.

  2. The edgeCloudFootprint description emphasizes that this represents the network-optimized service area, not physical proximity. This distinction was highlighted in working group discussions—a device entering a zone's geographic footprint does not guarantee that zone is optimal for that device, as routing depends on network topology.

  3. The field is optional to maintain backward compatibility.

Changelog input

release-note
Add optional edgeCloudFootprint field to EdgeCloudZone response schema, enabling geographic coverage visualization and data residency use cases

Additional documentation

docs
Updated API description with edgeCloudFootprint field documentation and example response showing Circle footprint usage

@DLondonoD
Copy link
Contributor

Hi @clundie-CL,
I believe the proposal is generally fine. I would simply suggest adding edgeCloudFootprint field as schema component. This would make it reusable and ensure it is properly reflected in the schema section.

EdgeCloudZones is already used by other Edge APIs. Therefore, to maintain consistency across the data model, we should also consider introducing edgeCloudFootprint into those APIs.

In this context, I also noticed that the status property exists in other APIs, although under different naming conventions. For example, in EAM API it is referred to as edgeCloudZoneStatus. We should also consider aligning these fields.

@clundie-CL
Copy link
Author

@DLondonoD

I believe the proposal is generally fine. I would simply suggest adding edgeCloudFootprint field as schema component. This would make it reusable and ensure it is properly reflected in the schema section.
EdgeCloudZones is already used by other Edge APIs. Therefore, to maintain consistency across the data model, we should also consider introducing edgeCloudFootprint into those APIs.

Agreed

In this context, I also noticed that the status property exists in other APIs, although under different naming conventions. For example, in EAM API it is referred to as edgeCloudZoneStatus. We should also consider aligning these fields.

If the codeowners wish to pursue that as part of this PR, I am happy to accommodate reconciling this field in this (and possibly other) APIs in the family.

@maheshc01
Copy link
Contributor

My review of this PR is still in progress.. will target to complete it by end of this week.

@maheshc01
Copy link
Contributor

maheshc01 commented Jan 27, 2026

I have left my detailed response in the issues #25 .
I am making a proposal that this enhancement is a better for edge-application-management.yaml. Please review my comments in the issue and let me know your thoughts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Proposal: Introduce optional edgeCloudFootprint field in EdgeCloudZone to represent zone coverage regions (OptimalEdgeDiscovery)

3 participants