...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Attendees & Representation
...
Community: Rafal Artych Herbert Damker Jose Luis Urien Pinedo
Andrew Wajs Jorge Garcia Hospital Akos Hunyadi Eric Murray , Emil Zhang, Joshua Peng, Maximilian Laue, Patrice Conil
Agenda
- Antitrust Policy
- General Topics
- New and existing Issues
- Open Pull Requests for v0.10.0
- Plan for release v0.10.0
- Any Other Topics
...
- Summary of the open pull requests presented within issue #260 Proposal to create RC2 of v0.10.0
- The following PR were merged during the call:
- PR #258 Added clarification of notifications to be sent and added StatusInfo "DELETE_REQUESTED" to address #241 was discussed but not merged:
- The PR addressed two issues
- Open point is the period of time in
"NOTE: in case of a `QOS_STATUS_CHANGED` event with `qosStatus` as `UNAVAILABLE` and `statusInfo` as `NETWORK_TERMINATED` the resources of the QoS session are not directly released, but will get deleted automatically only 360 seconds after the event" - With this formulation it is too restrictive for implementations.
- Herbert stated that API consumers need a defined time period in case they want to poll to QoS session status instead of using notifications
- Agreement: the statement should only define the time minimum period in which the QoS session resource is still available, but leave it up to implementations when the resources will be released after this period
- Herbert will update the PR and then ask for final reviews
- PR #255 Updating the project scope in the ReadMe
- Not ready for merge, as there are different opinions
- Herbert argues that the scope of CAMARA includes mobile and fixed networks, the API should be technically agnostic regarding the underlying technology, and that the qosProfiles functionality allows to define different profiles and therefore products for different networks based on the offered products
- Jorge García sees that the extension to fixed access networks will raise question on the product side, as the API should be offered completely, not partially raise error messages. He would prefer to see atomic APIs for the different scopes to be able to offer them as separate products
- Agreement: the explicit change of scope will not done for the release v0.10.0, but targeted for the next release (where it will be addressed together with issue #166).
- Jorge García: It is important to communicate the scope change also back to GSMA OGW to ensure a consistent communication.
- The PR will kept open for discussion of the wording (changed to draft until the release of v0.10.0)
...