...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
DRAFT
...
MINUTES
Attendees & Representation
...
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
...
- GSMA (Toyeeb Rehman) presented in TSC a list of issues identified during certification of CAMARA API implementations. Worth to read and consider. (add), 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 → see
- issue #271 created, see below
- Review of Linting rules implementation → see 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 this
- 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 before doing to be done before PR for issue #265 (split of APIs) - yesReady will be started.
- Action Point: Request for final review by code owners.
- PR #269 Patch of documentation to address #267 (lack of
statusInfo
inSessionInfo
)- 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
- Randy will 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
- To be done 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 within an own PR ) Jose Luis Urien Pinedo
- To be done 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?
- #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?
- As described originally within the issue: API consumer wants to get a list of open sessions across different subscribers
- Discussion to be continued within the issue
- At least two different use cases
- No updates
- As of last meeting:
- #166 Extend QoS Profile queries to list profiles based on specific users or devices
- Discussion updated by Emil and Jose
- 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
- As of last meeting:
- #194 Add Application Function Id (afId) or Sponsor Id
- Syed opened
- New comments were added within the issue under identity and consent management project
- camaraproject/IdentityAndConsentManagement#126
- New comments within the issues (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
- PR will be reopened after MWC (see previous minutes)
- see above.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
- Work in Device Location ongoing. Probably next week some issue will be opened in Commonalities (and TSC about GSMA Certification)
- Jose has open 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 next week, 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,Two alternatives to resolve:Remove
statusInfo
from this note → would lead to v0.10.1 (change in documentation) - Herbert will prepare a PR against release-0.10.0 branch
- But we will wait with a patch release in case there will be further issues and/or clarifications of documentation for v0.10.x Add the
- Bug within v0.10.0,Two alternatives to resolve:Remove
- 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 - Document in issue Herbert Damker
- See PR discussion.
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
...