DRAFT MINUTES

Attendees & Representation

Type @ and your name to indicate your attendance

LF Staff: na

Community: @Herbert Damker @Jose Luis Urien Pinedo @Randy Levensalor @Akos Hunyadi @Ramesh Shanmugasundaram @Thorsten Lohmar @Jorge Garcia Hospital 

@Masaharu Hattori , Emil Zhang

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 (@Herbert Damker )

• EasyCLA activated for QoD project - worked as expected already within PR #273 and #269

• 2024-03-21 TSC Minutes - topics with request for feedback:

  • CAMARA release process were introduced (https://lf-camaraproject.atlassian.net/wiki/x/ah7e), with request for feedback. Target is to have a meta release ready for September.

  • Commonalities prepared a release 0.4.0 scope planning: Release 0.4.0 scope planning - CAMARA Project - Confluence

  • Discussion on Capability and Runtime Restriction Proposal - potentially a new sub project which will benefit all other sub projects

Open Pull Requests (all)

• PR #273 feat: add the statusInfo as parameter to the SessionInfo

  • PR to resolve issue #267 within v0.11.0

  • Not to be merged before v0.10.1 patch release is done

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

  • PR got merged

  • As of last meeting:

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

  • Patch release to be done after #272 (see below) is also be addressed

• PR #255 Updating the project scope in the ReadMe

  • Merged

  • Herbert will communicate towards API Backlog @Herbert Damker using an issue and pointing to our PR #255

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

New Issues

• #272 Maximum duration 86400 in SessionInfo cannot support 'Extend Session Duration'

  • Discussion so far in the issue (summarised by Herbert):

    • Current documentation about extension of duration is ambiguous

    • There is a need to decide between the two options:

      • (a) maxDuration (or the limit of 86400 seconds) is absolut. Also the extended session duration can't be beyond this limit.

      • (b) maxDuration is relative to the current time. The maxDuration will be "restarted" by extendDuration. The requirement would be in this option that "expiresAt" is not more than maxDuration into the future (seen from the time of extendDuration API call)

    • Option (b) was the intention of the previous documentation (at least as understood by DT)

    • In case we are following option (b) there is still a need to clarify the documentation

  • Proposal: include the clarification into the v0.10.1 patch release

  • Decision:

    • Option (b) will be followed, update of documentation as described in issue

    • In addition the limit of duration has to be eliminated in SessionInfo => reference to "CreateSession" has to be expanded to allow that

    • The PR for this issue will be included within the v0.10.1 patch

  • Action:

    • PR to be created - @ Emil Zhang

Existing Issues (without backlog, reverse order)

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

  • As of last meeting

  • Related to this is clarification being discussed at camaraproject/Commonalities#164

  • Decision: We will wait for the clarification in Commonalities

• #268 Provision mode for QoD

  • As of last meeting:

    • 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

  • One new comment from @Kevin Smith within the issue

  • Action: API proposal template to be filled for this API (at least describing the differences to QoD Session API) @Jorge Garcia Hospital @Jose Luis Urien Pinedo 

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

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

  • Bug within v0.10.0

  • PR #269 created as short-term patch and merged

  • PR #273 created as resolution within v0.11.0 (not to be merged before v0.10.1 patch release)

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

  • As of last meetings:

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

  • PR will be created (only) after the patch release v0.10.1

  • Discussion of basepath within the issue (comment from Jose): 

    • qos-profiles agreed for the profiles.

    • v0.11.0 as version for both APIs (as the same functionality was already available in v0.10.0)

    • qod or qod-sessions or qos-sessions or quality-on-demand?

  • Request for action: please raise your opinions within the issue

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

  • As of last meeting: PR will be created by Jose.

  • No update, waiting for #265

• #249 Duration in QosProfile and SessionInfo

  • #265 to be done first

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

  • As of last meeting:

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

  • No update (no Commonalities meeting in between)

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

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

• #238 Updating the project scope in the ReadMe

  • see PR #255 above; closed

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

  • As of last meetings:

    • 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.

  • No update

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

  • As of previous meetings:

    • #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 update

• #101 List endpoint for active sessions of authenticated user

  • As of previous meetings:

    • 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

  • Discussion to be continued based on the summary in https://github.com/camaraproject/QualityOnDemand/issues/101#issuecomment-2015041284

  • No update.

Any other topics

• Next QoD will be on April 5th, at 14:00 CEST / 12:00 UTC.

Action items