Agenda

Antitrust Policy

• 1.Status of Traffic Influence API and related Issues

  2.Next Steps for Edge Discovery Services API

  3.Status of Edge Application Management API

  4.AOB

Minutes

1.Status of Traffic Influence API and related Issues

• PR TI API Rel 0.9.6: sourceTrafficFilters #278
• 3 LEGs Problems:

TI API currently uses 3Legs for all the methods in the API but as is defined in CAMARA IAC "Every time personal user data is processed by an API and the user can exercise their rights either via opt-in and/or opt-out, 3-legged access tokens must be used." Only when Device information is provided, 3Legs must be used so not all the methods in the API should use 3legs, instead it should use Client Credentials. This doubt will be asked by fabrizio moggio in commonalities.

2.Next Steps for Edge Discovery Services API

The API was analyzed by Telefónica team to provide some proposal for the API:

Analysis:

There are 3 Operations:

1. Discovery

2. Application Endpoints

3. Application Profile

- In my opinion an API named **Discovery** should contain only `GET` methods to discovery status/attributes for a given parameter but currently EDS API contains CRUD methods.

Impact Analyse

- 1. Discovery:
  - This operation has two methods `GET /application-endpoints` (at first glance and because of the name, it might overlap with AED API) and `GET /mecplatforms` (at first glance it might overlap with SED API or `GET /edge-cloud-zones` of EAM API).

   `GET /application-endpoints` ESD API vs `GET /app-endpoints` AED API:
    - `GET /application-endpoints` ESD API: Returns a list of optimal Application Endpoints that client devices can connect to. You can search based on Application Profile, Region, Suscriber Density or UEIdentity.
    
        This method is very interesting and covers part of intent 21, which is outside the scope of the MVP proposal, but was considered for the improvement phase.

    - `GET /app-endpoints` AED API: Returns the closest endpoint of the App Instance for an specific UE. Based on UEIdentity and AppID
    
    My conclusion is that each method has different functionality but can be merged to improve Application Endpoint Discovery capability, allowing endpoint discovery based on App Profile, Region, Subscriber Density, UEIdentity and AppId. 
    
  Note: There are some considerations to take into account if we agree on the merger.

   `GET /mecplatforms` ESD API vs `GET /edge-cloud-zones` EAM API:
    - `GET /mecplatforms` ESD API: Returns a list of optimal MEC Platforms where you can register your deployed application. You can choose to search without passing any of the inputs parameters or combination of Application Profile, Region, Subscriber or UEIdentity.

        This method is very interesting and covers part of intent 20, which is outside the scope of the MVP proposal, but was considered for the improvement phase.

    - `GET /edge-cloud-zones` EAM API: Returns a list of Edge Cloud Zones and their status, ordering the results by location (region) and filtering by status (active/inactive/unknown)
    
    My conclusion is that each method has different functionality but can be merged to improve Edge Cloud Platforms(?) discovery capability, allowing developers to discover them based on Application Profile, Region, Subscriber, UEIdentity and Status.
    
  Note: There are some considerations to take into account if we agree on the merger.

- 2. Application Endpoints:
  -  This Operation allows to: Register and manage the routable Application Endpoints of your deployed applications.
  - Currently the approach is that endpoints are fully managed by the Edge Platform and Developers can ask for this information through `GET /apps/{appId}/instances` EAM API method.
  - I don't found any intent related to this capability but I think is very interesting to have it because of two reasons:
    - If the developer deploys the application on a hyperscaler
    - If the developer wants to use their own domains, this relates to a comment in #271 to have a new API: `Bring Your Own DNS/Endpoint/Whatever` which allows the developer to use and manage third party domains (other than the Edge platform). So this contribution will serve as a basis for this.
    - A different approach I see here is to add it in the onboarding process within the EAM API, but I don't quite like it. 
    
- 3. Application Profiles:
  - This Operation allows to: Create and manage profiles that describe the application requirements of your MEC applications, such as the required connection bandwidth and maximum latency.
  - In my opinion this Operation is very interesting and covers part of intent 5, which is outside the scope of the MVP proposal but was considered for the enhancement phase. But it should be placed in the onboarding process within the Edge Application Management API.

Note: I have not added the impact to the SED API because, as far as I understand, the approaches are different, but feel free to add it to the analysis if needed.

 Mahesh Chapalamadugu proposed to:

• Create a pull request for combining EDS API and AED API yaml and take this discussion further to action.
• With respect to EDS having a combination of POST, PUT , GET and DELETE functions. In my opinion the ideal end state for the API is:

1. 1. Create separate yaml for Application profiles management- process started with discussions in connectivity insights and QoD as well as commonalities. becomes a reusable API across multiple CAMARA project
   2. Create separate yaml for Application end point registry. This is more edge cloud specific but still reusable across the sub projects.
   3. EDS will be more focussed on discovery of edge cloud sites and application end points

• More details are within the discussion 279

 3.Status of Edge Application Management API

• Add Missing AppProvider
  • Adds the missing AppProvider to the AppManifest model.
• UpdatingrequiredResources in Application Management API
  • Enables the definition of different infrastructure for the application, allowing selection from among Kubernetes, Virtual Machines, and Containers. Additionally, the developer can specify the sizing of Kubernetes cluster for the application, the characteristics of compute resources, and the base add-ons to enabling monitoring and ingress in Kubernetes clusters. Some comments by nicolacdnll@nearbycomputing to provide a different view on the K8s cluster provisioning, this is being discussed in the PR 280

4.AOB

Update from Kevin Smith for Simple Edge Discovery API:

0.11.0-alpha.1 is under development and expected to be available by 12th July. Progress so far:

- incorporated: Commonalities 203,214,233, EdgeCloud 119 (adding public port)

- checked (no change needed): Commonalities 152,170,177,189

- underway: update the errors to align with Commonalities 0.4rc.1 common.yaml

Action items