Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create MOM-2023-11-17.md #234

Merged
merged 3 commits into from
Nov 20, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
100 changes: 100 additions & 0 deletions documentation/MeetingMinutes/MOM-2023-11-17.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,100 @@
# Camara QoD meeting - MOM-2023-11-17

*Friday, November 17th, 2023*

## Attendees (probably incomplete)

* Andrew Wajs (Scenera)
* Cetin Alpaycetin (Vodafone)
* Emil Zhang (Ericsson)
* Herbert Damker (Deutsche Telekom, Moderator)
* Jorge Garcia Hospital (Telefonica)
* Jose Luis Urien Pinedo (Telefonica)
* Patrice Conil (Orange)
* Rafal Artych (Deutsche Telekom)
* Ramesh Shanmugasundaram (Spry Fox Networks)
* Randy Levensalor (CableLabs)
* Toshi Wakayama (KDDI)


QoD minutes: [https://github.com/camaraproject/QualityOnDemand/tree/main/documentation/MeetingMinutes](https://github.com/camaraproject/QualityOnDemand/tree/main/documentation/MeetingMinutes)

## Agenda

* Open PRs
* Discussed Issues
* Release v0.10.0
* AOB

## Discussion of Open PRs

* [#216 Extend session duration](https://github.com/camaraproject/QualityOnDemand/pull/216) (Associated Issue [#220 Change duration of an active session](https://github.com/camaraproject/QualityOnDemand/issues/220))
* Tag of operation updated (belongs to `QoS Sessions`)
* Description updated
* ACTION ITEM - final review by code owners for approval until Wed Nov 22nd

* [#217 issue_194_PR](https://github.com/camaraproject/QualityOnDemand/pull/217) (Associated Issue [#194 Add Application Function Id (afId) or Sponsor Id](https://github.com/camaraproject/QualityOnDemand/issues/194)
* PR in draft status, not discussed

[#224 Align event notification with CloudEvents spec](https://github.com/camaraproject/QualityOnDemand/pull/224) - Issue 221
* Data object optional within Event base class (in line with other APIs using CloudEvents). Can be adapted if there is a global change within guidelines
* ACTION ITEM - final review by code owners for approval until Wed Nov 22nd

[#227 Adding global tags element](https://github.com/camaraproject/QualityOnDemand/pull/227)
* PR is merged and issue closed

[#228 Add GET /sessions endpoint for retrieving all active sessions of authenticated user](https://github.com/camaraproject/QualityOnDemand/pull/228) - Issue #101
* PR still in draft, and it is unclear if the open points can be resolved in time for v0.10.0 (see below ... release candidate should be created end of next week which require to have the PR ready for review start of the week)
* Still optional for v0.10.0.
* Discussions:
1. Can the endpoint deliver (A) all sessions created by the requesting API consumer or (B) only the ones for the user resource within the (3-legged) token? (in other word: does the endpoint later require 2-legged or 3-legged token, in case 3-legged token will (later) be required to create a QoD session resource)
* For now the assumption is that the operation delivers all sessions which are authorized by the token (all sessions created for 2-legged, only user sessions for 3-legged). Decision about needed token is postponed.
2. Should the operation deliver the full session information or just the session ids?
* Result of the discussion: return the full session information
* Rational: this is the more developer friendly option, as otherwise the API consumer would need to call getSession one by one to find the information they are looking for. From privacy perspective has the API consumer provided and seen all personal information already during the respective session creations. It should be enough that the API consumer was authorized to create the sessionId(s) to assume consent for the get operation.
3. Is paging needed or not?
* That depends on the answer to point 1. If only the sessions for one user device are delivered is no paging necessary. If all sessions for an API consumer are delivered then paging might be needed to avoid excessive data within the response
4. Filtering by `device` or `phoneNumber` (Added after the call, comment from Randy https://github.com/camaraproject/QualityOnDemand/pull/228#discussion_r1397522143)
* Potentially the discussions can be not be closed for v0.10.0, in this case the feature will be postponed to the next release.

[#233 Alignment with changes in https://github.com/camaraproject/Template_Lead_Repository on test definitions](https://github.com/camaraproject/QualityOnDemand/pull/233)
* PR creates the directory `Test_definitions` and copies the existing .feature file into this directory.
* The question what should happen with the JAVA code within the /cucumber folder can not be answered within the context of the PR
* It is about the general questions if such code (to execute the test definitions) could be provided centrally for all APIs, and if yes, where (e.g. in Commonalities or Release Management)
* ACTION ITEM: Rafal to create an issue in Commonalities for an initial clarification
* The PR itself is ready for final review by code owners (and does not change the API definition). Will go into v0.10.0



## Discussed Issues

* [#230 Single IPv6 addresses within device](https://github.com/camaraproject/QualityOnDemand/issues/230)
* Agreed to follow the proposal within Jose's comment https://github.com/camaraproject/QualityOnDemand/issues/230#issuecomment-1812335931 - only formats allowed in device would be those considered in [JSON-schema](https://json-schema.org/understanding-json-schema/reference/string#ip-addresses) (`ipv4` and `ipv6`).
* `devicePorts` might need be (re)defined later.
* ACTION ITEM: Jose to create a PR asap, so that it can potentially go into v0.10.0

[#231 Error behaviour when session cannot be created due to "time cap" limitation](https://github.com/camaraproject/QualityOnDemand/discussions/231)
* Opened as discussion, not as an issue - hasn't received any attention as a discussion
* The question is actually not QoD specific, but relevant for all APIs (as there could be a cap of agreed number of API calls or a lack of prepaid money)
* ACTION ITEM: Jose to create issue in commonalities


All other open issues either in work (see above) or not considered for v0.10.0 and therefore not discussed due of time.

## Release plan for 0.10.0

* **The release candidate for v0.10.0 should be created at end of next week (Friday Nov 23rd) to have enough time to validate the release candidate by implementing operators and do the actual release of v0.10.0 at latest before year end break.**
* The following PRs MUST be included in the release candidate v0.10.0
* [#216 Extend session duration](https://github.com/camaraproject/QualityOnDemand/pull/216)
* [#224 Align event notification with CloudEvents spec](https://github.com/camaraproject/QualityOnDemand/pull/224)
* [#233 Alignment with changes in https://github.com/camaraproject/Template_Lead_Repository on test definitions](https://github.com/camaraproject/QualityOnDemand/pull/233)
* The following PRs COULD be included within the release candidate if finalized in time
* [#228 Add GET /sessions endpoint for retrieving all active sessions of authenticated user](https://github.com/camaraproject/QualityOnDemand/pull/228)
* Yet to be done PR for issue [#230 Single IPv6 addresses within device](https://github.com/camaraproject/QualityOnDemand/issues/230)
* Release candidate will be the starting point for implementations. Release to be expected about 2 or 4 weeks later.
* Between release candidate and release only bug fixes and updates of documentation will be done on the API spec.
* ACTION ITEM: Herbert will create the issue with this release plan and prepare the changes to CHANGELOG.md

## AOB

* The next call will be on Friday December 1st, 14:00 CET / 13:00 BT / 13:00 UTC