DRAFT
...
MINUTES
Attendees & Representation
...
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
...
- 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://wikilf-camaraproject.camaraprojectatlassian.orgnet/wiki/x/16N3ah7e), 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
...
- PR #273 feat: add the
statusInfoas parameter to theSessionInfo- 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
statusInfoinSessionInfo)- PR got merged
- As of last meeting:
- Action Point: Herbert Damker to prepare the patch release
- Proposal: before patch release also Patch release to be done after #272 (see below) should 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 the 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
- Discussion so far in the issue (summarised by Herbert):
Existing Issues (without backlog, reverse order)
- #271 X-Correlator required within OAS definition of QualityOnDemand API
- As of last meetingDiscussion: 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
- Related to this is clarification being discussed at camaraproject/Commonalities#164
- Decision: We will wait for the clarification in Commonalities
- 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
Action Point: the
- 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
- One new comment from Kevin Smith within the issue
- ...
- 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)
- As of last meetings:
- Jose will prepare a PR, just the split without any further changes (incl. copying schemas, decision about common file later)
- Will be continued 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
- As of last meeting: PR will be created by Jose.
- no No update, waiting for #265
- #265 to be done first
- As of last meeting:
- Jose has opened a new issue in Commonalities with request for some additional guidelines (#158)
- no No update (no Commonalities meeting in between)
- No update; #265 to be done first (split of APIs)
- ...
- see PR #255 above; closed
- 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
- 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
- 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?
- 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
- 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.
...