Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Documentation: Clarify distinction between device/server usage of Simple Edge Discovery API #207

Closed
maxplumley opened this issue Feb 15, 2024 · 3 comments · Fixed by #194
Assignees

Comments

@maxplumley
Copy link

Hi folks,

We're in the process of implementing the Simple Edge Discovery API (v0.9.3) and attempting to reconcile some issues we see with the proposed usage:

The API returns the closest MEC platform to a given device, so that device needs to be identifiable by the network:
    * if you call the API from a server, you must explicitly pass one or more device identifiers in the HTTP request header:
      * `IP-Address`. This is the public IP address of the user device: this can be obtained by an application hosted on that device calling a public IP address API (e.g. GET https://api.ipify.org?format=json)
      * `Phone-Number` . The international E.164 format (starting with country code), e.g. +4407123123456
      * `Network-Access-Identifier` (where available from the API host operator)
      
    * if you call the API from a device attached to the operator network, you _may_ omit the explicit device identifier(s)from the request header. If such a request fails with a `404 Not Found` error then retry the request but this time include a device identifier.

How does the group suggest implementations identify that a request was generated by a server, as opposed to a device attached to the network? Our current approach is purely IP based, we look for the IP-Address header, and if not provided fall back to the remote client IP address (assuming parties in between are handling X-Forwarded-For etc headers appropriately). We don't really know if the original client is a server or device attached to the network. Because of this we don't really see how we can support both server requirements 'you must explicitly pass one or more device identifiers' and device requirements 'you may omit the explicit device identifier(s)'. Any ideas greatly welcomed :)!

@Kevsy
Copy link
Collaborator

Kevsy commented Feb 15, 2024

Hi @maxplumley sorry for slow reply -

Thanks for pointing this out, I'll make it clearer on 0.9.4.

If an IP-Address parameter is provided then the operator should assume the request is coming from a developer's server rather than a device attached to the network. In which case the developer server is expected to have been provided with the device public IP address (e.g. by the application client on that device signaling it back to the server)

If neither the IP-Address parameter nor any other device identifier is provided in the API request header, then the operator should assume the request is from a device attached to their network, and attempt to use the public IP source address to determine which packet gateway issued it (and hence the closest edge to that gateway).

If no IP-Address header is provided, but another device identifier(s) is provided, then the operator should assume the request is coming from a device attached to their network and should make use of one or both of the public IP source address (from the IP packet header) and the other device identifier(s).

@maxplumley
Copy link
Author

Hi Kevin, thanks for the clarification! I think our implementation is aligned.

@Kevsy
Copy link
Collaborator

Kevsy commented Feb 16, 2024

Thanks for raising it Max, I'll add to #194

@Kevsy Kevsy self-assigned this Feb 16, 2024
@Kevsy Kevsy changed the title Question: device/server distinction for Simple Edge Discovery API usage Documentation: Clarify distinction between device/server usage of Simple Edge Discovery API Feb 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants