Versions Compared

Old Version 3

changes.mady.by.user Akos Hunyadi

Saved on

compared with

New Version Current

changes.mady.by.user Randy Levensalor

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

DRAFT MINUTES

Attendees & Representation

...

Community: Ben HepworthRandy LevensalorAkos Hunyadi Toshi Wakayama Rafal Artych Masaharu Hattori Joachim Dahlgren Thorsten Lohmar Eric Murray Jose Luis Urien Pinedo

Agenda

  • Antitrust Policy

  • Review of previous meeting minutes

  • Overall Topics

  • Regular Topics

    • Closed PRs and Issues

    • Open Pull Requests

    • New Issues

    • Open Issues

  • Any Other Topics

...

...

  • #362 Support of Multi-SIM lines in QoD APIs

    • Jose Luis Urien Pinedo Raised concerns regarding changes in functionality in patch release. Can discuss further when we have a PR with these changes.

    • Previous minutes:

      • Target: define a common behaviour across operators (which all operators can implement)

      • Secondary MSISDNs: not known to users/developers, can't be used in public

      • Just using the "main" device not sufficient (way to notify the application about the chosen device/SIM missing)

      • Enabling all devices with same MSISDN? 

        • Maybe an option, but only in combination with a selected application (IP) flow

      • Request to those who have implemented to share their current solution

        • Target: Derive some guideline/documentation update for the current version

      • Documentation of expected behaviour also relevant for a Fall24 patch release

    • Discussion to be continued within the issue (@all)

      • Differentiate between short-term clarification in API documentation

      • Long-term solution (within next release?)

  • #361 Authorization and Authentication section need to be aligned with ICM 0.2.0 text

  • #359 Add explanation on why there is a "POST /retrieve-sessions" instead of GET

    #341 Add user story for QoS Profiles

    • see PR #367

    • Merged

  • #337 Potential enhancement of booking feature for qod-provision

    • new comment with use case draft available: https://github.com/camaraproject/QualityOnDemand/issues/337#issuecomment-2391997666

    • Masaharu Hattori offered to propose Added a state diagram, as started to discussed in the issue.

    • Eric Murray propose to have also a user story which describes the value of the feature

    • An important question if the “booking” comes with reservation of resources (a commitment that the session will be available at the requested time) or only a scheduling of the session/provisioning creation

      • a reservation would require to also provide the geographic region, to allow the network operator to check/reserve resources

      • Masaharu Hattori noted that the booking would not be guaranteed and the booking acceptance only depends on a properly formatted request.

      • Eric Murray Noted that the backend could also reject a booking earlier, if the operator knows that the requested resources will not be available. And there needs to be a mechanism for the API provider to cancel the booking, for instance if a QoS profile is removed after it is booked and before it is activated.

      • Jose Luis Urien Pinedo noted that a booking without a guarantee could be confusing. Though Eric Murray noted this can be covered in the T&C.

    • Jose Luis Urien Pinedo added a note regarding the inclusion of location to the booking function.

    • Masaharu Hattori will update the user benefit to booking without a guarantee. Update diagram to include operator cancelation after booking is accepted.

  • #147 Extend the query capabilities for Qos Profiles

    • Not discussed, no updateSuggestion to not standardize QoS profiles in CAMARA. This could be done more quickly through an aggregator.

    • Could add as optional parameters in the body

    • Randy Levensalor to create a PR

    • Jose Luis Urien Pinedo concerned that this could over complicate the API, if we are only exposing a few profiles to API consumers.

    • Previous meeting minutes

      • Application-profile as potential input, returning fitting qos-profiles

        • Challenge: application-profile is a resource which need first to be created

      • Use of application-profile API is also discussed in other Sub Project (e.g. EdgeCloud)

      • Potentially related: Commonalities/issues/179

  • #173 Add support for DSCP markings for QoD sessions

    • Not discussed, no update

    • Previous meeting minutes:

      • Refining use case as next step

      • DSCP to matching an IP flow? 

      • Use of L4S in context of a QoS profile as one potential user story

  • https://github.com/camaraproject/QualityOnDemand/issues/286

    • Eric Murray suggests that we review the definitions of the parameters before a stable release. Dedicate a meeting in Jan/Feb 2025 timeframe.

  • https://github.com/camaraproject/QualityOnDemand/issues/243

    • Eric Murray At a minimum this should be a documentation review / update. Could also include renaming properties or switching a to new model, such as using an application URL.

    • Needs further discussion.

  • #302 Providing developers with alternate to QoS profile

    • Not discussed, no update

    • Previous meeting minutes:

      • potential via #147 instead as a direct parameter within the quality-on-demand API

      • evaluate relation to new QualityByDesign concept

  • Remaining issues (#45, #194, #243, #286, #304, #317) to be checked (off-line) regarding closing / taking into scope

Any other topics

Action items