DRAFT MINUTES

Attendees & Representation

Type @ and your name to indicate your attendance

LF Staff: na

Community: @Herbert Damker @Jose Luis Urien Pinedo @Akos Hunyadi @Eric Murray @Jorge Garcia Hospital @Rafal Artych @Ramesh Shanmugasundaram @Toshi Wakayama @Syed Rehman Thorsten Lohmar, Joachim Dahlgren, Randy Levensalor, Masaharu Hattori

Agenda

• Antitrust Policy

• Review of previous meeting minutes

  • Agreed

• General Topics

  • Overall project

  • New Issues

  • Open PRs

  • Existing Issues

• Any Other Topics

Minutes

Overall project

• GSMA (Toyeeb Rehman) presented in TSC a list of issues identified during certification of CAMARA API implementations. Worth to read and consider, available within the TSC Minutes, or via direct link to presentation.

• Release v0.3.0 of Commonalities and remaining action points from it:

  • New issue for X-Correlator to be created → issue #271 created, see below

  • Review of Linting rules implementation → PR #270 created, see below

• Release process and milestone plan for a CAMARA "meta" release in work. Will be relevant also for QualityOnDemand: new Commonalities & ICM releases, own scope definition within QoD needed for the release.

Open Pull Requests

• PR #270 Adding configuration for linting ruleset

  • Created by @Rafal Artych based on the agreed and tested configuration within Commonalities 0.3.0

  • Merge to be done before PR for issue #265 (split of APIs) will be started.

  • Action Point: Request for final review by code owners.

• PR #269 Patch of documentation to address #267 (lack of statusInfo in SessionInfo)

  • Created by @Herbert Damker as agreed for issue #267

  • To be discussed if we want to have this as a patch or rather add the missing statusInfo directly as patch towards 0.10.1

  • Action Point: @Randy will improve the wording

  • To be merged into main, creating a patch release 0.10.1 before merging further changes of the YAML.

  • Action Point: @Herbert Damker to prepare the patch release

• PR #255 Updating the project scope in the ReadMe

  • Reopened for review after MWC as agreed.

  • Action Point: Request for final reviews by QoD Maintainers

  • Herbert will take the communications towards API Backlog afterwards @Herbert Damker 

• PR #228 and #217 still in draft mode.

New Issues

• #271 X-Correlator required within OAS definition of QualityOnDemand API

  • Discussion: is there a common definition in Commonalities of the header parameter and how to document in the OAS or will it be copied from sub project to sub project?

    • Currently there is only the requirement with the Design Guidelines, no definition in common YAML nor an open issue for that

  • Action Point: Create a separate PR based on other sub projects integration of X-Correlator header (before PR for #265) @Jose Luis Urien Pinedo 

• #268 Provision mode for QoD

  • The proposal is about introducing a new API for permanent provisioning of a QosProfile. Session will not limited in duration and will be started when a device opens the defined flow.

  • Enhancement or even new API - would a discussion in API Backlog make sense?

    • Arguments: the API could be considered as a different product. The behaviour will be different and the API will most probably require a different charging model

  • Action Point: the API proposal template to be filled for this API (at least describing the differences to QoD Session API)

    • The template is available here: https://github.com/camaraproject/WorkingGroups/blob/main/APIBacklog/documentation/API-proposal-template.md

Existing Issues (without backlog, reverse order)

• #101 List endpoint for active sessions of authenticated user

  • As of last meeting:

    • At least two different use cases

      • As described originally within the issue: API consumer wants to get a list of open sessions across different subscribers

        • within result would be only session created by the API consumer itself

        • Herbert: in this case the API consumer will not get additional (personal) information from this endpoint which they haven't received already earlier (during session creation). Potentially possible with 2-legged token?

      • Use case added by Jose: API consumer wants to get a list of sessions which are (potentially) already opened for a specific device

        • Would require a 3-legged token and potentially consent from end-user?

    • Discussion to be continued within the issue

  • No updates

• #166 Extend QoS Profile queries to list profiles based on specific users or devices

  • As of last meeting:

    • #265 to be done first (split of APIs)

    • More clarifications on subscription will be added by Emil

    • Description of parameters/filters within the issue needed

  • No updates

• #194 Add Application Function Id (afId) or Sponsor Id
  
  

  • New comments were added within the issue camaraproject/IdentityAndConsentManagement#126 (opened by Syed), to be reviewed.

  • Syed will investigate into TMF 931.

  • Akos/Syed: backend service will not necessary get the client id via the access token. This might justify to add an application id within the payload.

• #238 Updating the project scope in the ReadMe

  • see PR #255 above

• #244 Align securitySchemes and security of QOD API spec with IdentityAndConsentManagement

  • No update; #265 to be done first (split of APIs)

• #245 Update and enhance test definition file for QOD API
  
  

  • Jose has opened a new issue in Commonalities with request for some additional guidelines (#158)

• #249 Duration in QosProfile and SessionInfo

  • See previous minutes

  • #265 to be done first

• #257 Error behaviour when session cannot be created due to "time cap" limitation

  • PR will be created by Jose.

• #265 Proposal to split QoS Sessions and QoS Profiles into two separate API definitions

  • Jose will prepare a PR, just the split without any further changes (incl. copying schemas, decision about common file later)

• #267 Polling for statusInfo in GET /sessions/{sessionId} not possible

  • Bug within v0.10.0

  • PR #269 created as short-term patch

  • Further resolution: Add the statusInfo to the GET /sessions/{sessionId} - response → will be done in v0.11.0

Any other topics

• Next QoD will be on March 22nd, at 14:00 CET / 13:00 UTC.

• Please be aware the US will change to summertime on March 10th, so this specific meeting will be there one hour later as usual (e.g. 06:00 PDT, 09:00 EDT)

• The first meeting in EU summertime will be on April 5th at 14:00 CET / 12:00 UTC

Action items