Versions Compared

Old Version 1

changes.mady.by.user Randy Levensalor

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.

...

Community: Randy LevensalorEric Murray Rafal Artych Ramesh Shanmugasundaram Akos Hunyadi Masaharu Hattori

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

...

...

New Issues

  • No new issues since last meeting.

...

  • #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?)

    • Discussed in Spring Release planning.

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

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

    • new comment with use case draft available: Masaharu Hattori updated user story based on feedback. https://github.com/camaraproject/QualityOnDemand/issues/337#issuecomment-2391997666

    • Masaharu Hattori Added a state diagram.

    • 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.2478610680

    • Jose Luis Urien Pinedo Suggested adding a location to the booking.

      • Note: The session would be terminated when the device leaves this location. Further discussion needed on how to address location.

    • Eric Murray suggested to create a new booking API endpoint and test scenarios as a part of this PR.

    • Masaharu Hattori Will create a PR for next meeting.

  • #147 Extend the query capabilities for Qos Profiles

    Suggestion 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 PRJose 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

      Reviewed slides

      • General support for adding these optional elements to the QoS Profile

      • DifferentiatedServicesCodepoint- Discussion for alternatives to the current proposals for how to best represent the value.

    • Randy Levensalor Will create a PR for next meeting.

  • 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.Not discussed

  • 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.

    • Not discussed

  • #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, #304, #317) to be checked (off-line) regarding closing / taking into scope

...