...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
DRAFT AGENDA
Attendees & Representation
...
Community: Herbert Damker Jose Luis Urien Pinedo Randy Levensalor Akos Hunyadi Ramesh Shanmugasundaram Thorsten Lohmar Jorge Garcia Hospital
Agenda
- Antitrust Policy
- Review of previous meeting minutes
- Agreed
- General Topics
- Overall project
- New Issues
- Open PRs
- Existing Issues
- Any Other Topics
...
- 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 #272 (see below) should be addressed
- PR #255 Updating the project scope in the ReadMe
- Ready to be merged (two approvals, no new comments)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 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
- In addition the limit of duration has to be eliminated in SessionInfo
- PR to be created - @Emil
- 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 meeting
- 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
- 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?
- Related to this is clarification being discussed at camaraproject/Commonalities#164
- ...Decision: We will wait for the clarification in Commonalities
- As of last meeting
- #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?
- ArgumentsArgsuments: 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
- One new comment from Kevin Smith within the issue
- ...
- As of last meeting:
- #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)
- Will be continued after the patch release v0.10.1
- Discussion of basepath
- qos-profiles agreed for the profiles. v0.11.0 (as the same functionality was already in v0.10.0)
- qod or qod-sessions or quality-on-demand? ... please raise your opinions within the issue
- As of last meetings:
- #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)
- As of last meeting:
- #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
- As of last meetings:
- #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
- As of previous meetings:
- #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?
- 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
- As of previous meetings:
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 CEST / 12:00 UTC.