Edits 01072026/typos correction#14
Open
jordijoangimenez wants to merge 2 commits into
Open
Conversation
In particular "allow to get" is incorrect... allows (object) to get. I simplified it.
jordijoangimenez
requested review from
Masa8106,
albertoramosmonagas,
hdamker and
tlohmar
as code owners
| | Need addressed | The API consumer needs defined connectivity quality for a specific time window — which can start immediately or at a future point — and a defined service area. | | ||
| | What it controls | A connectivity booking for one QoS profile, one time window, one service area and one device. | | ||
| | API consumer takeaway | The essential difference from `quality-on-demand` is that the booking allows to get confidence that the QoS Profile is usable by the requesting API consumer, which obtains CSP confirmation before the QoS session is established. The essential difference from `qos-provisioning` is that the booking is bounded by a time window and service area. | | ||
| | API consumer takeaway | The essential difference from `quality-on-demand` is that the booking provides confidence that the QoS Profile is usable by the requesting API consumer, which obtains CSP confirmation before the QoS session is established. The essential difference from `qos-provisioning` is that the booking is bounded by a time window and service area. | |
Contributor
There was a problem hiding this comment.
Two-step model survives in qos-booking takeaway. "which obtains CSP confirmation before the QoS session is established" implies mandatory QoD call after booking. Masa confirmed the ACTIVATED state puts QoS in effect directly for qos-booking. Lines 234/260 were fixed but this one was not.
Suggested change
| | API consumer takeaway | The essential difference from `quality-on-demand` is that the booking provides confidence that the QoS Profile is usable by the requesting API consumer, which obtains CSP confirmation before the QoS session is established. The essential difference from `qos-provisioning` is that the booking is bounded by a time window and service area. | | |
| | API consumer takeaway | The essential difference from `quality-on-demand` is that the booking provides confidence that the QoS Profile is usable by the requesting API consumer, which obtains CSP confirmation. The essential difference from `qos-provisioning` is that the booking is bounded by a time window and service area. | |
| | Need addressed | The API consumer needs to book connectivity quality — for immediate or future use — without binding devices at the time of the booking. This can be done for a scenario that may require one or multiple QoS profiles. | | ||
| | What it controls | A connectivity booking based on a network profile, within which one or more QoS profiles can be made available. Device assignment is managed separately via the `dedicated-network-accesses` API. | | ||
| | API consumer takeaway | Like other booking APIs, `dedicated-network` allows to get confidence that the QoS Profile is usable by the requesting API consumer before the QoS session is established. It is relevant when the scenario requires not to bind devices at booking time — allowing separation between the connectivity booking and the devices that will use it — and when the scenario may require one or multiple QoS profiles within a single booking. | | ||
| | API consumer takeaway | Like other booking APIs, `dedicated-network` provides confidence that the QoS Profile is usable by the requesting API consumer before the QoS session is established. It is relevant when the scenario requires not to bind devices at booking time — allowing separation between the connectivity booking and the devices that will use it — and when the scenario may require one or multiple QoS profiles within a single booking. | |
Contributor
There was a problem hiding this comment.
Same two-step phrasing in dedicated-network takeaway. "provides confidence that the QoS Profile is usable by the requesting API consumer before the QoS session is established." Same fix needed.
Suggested change
| | API consumer takeaway | Like other booking APIs, `dedicated-network` provides confidence that the QoS Profile is usable by the requesting API consumer before the QoS session is established. It is relevant when the scenario requires not to bind devices at booking time — allowing separation between the connectivity booking and the devices that will use it — and when the scenario may require one or multiple QoS profiles within a single booking. | | |
| | API consumer takeaway | Like other booking APIs, `dedicated-network` provides confidence that the QoS Profile is usable by the requesting API consumer. It is relevant when the scenario requires not to bind devices at booking time — allowing separation between the connectivity booking and the devices that will use it — and when the scenario may require one or multiple QoS profiles within a single booking. | |
| | `dedicated-network` | Reservation-based | Time window (immediate or future) | Defined service area | Devices managed separately via `dedicated-network-accesses` | One or multiple QoS profiles per booking | | ||
| | `dedicated-network-accesses` | Device-access management | Follows the dedicated network booking lifecycle | Inherited from the dedicated network | Device-access management | Inherited from the dedicated network | | ||
|
|
||
| For reservation-based APIs (qos-booking, qos-booking-and-assignment, dedicated-network), the booking allows the API consumer to get confidence that the QoS Profile is usable, and to obtain confirmation from the CSP. |
Contributor
There was a problem hiding this comment.
Missing backticks. API names appear without code formatting: "qos-booking, qos-booking-and-assignment, dedicated-network". Every other reference in the document uses backticks.
Suggested change
| For reservation-based APIs (`qos-booking`, `qos-booking-and-assignment`, `dedicated-network`), the booking allows the API consumer to get confidence that the QoS Profile is usable, and to obtain confirmation from the CSP. |
|
|
||
| 3. **Do not turn the portfolio into a strict decision tree.** The same scenario may be addressed differently depending on the API consumer need, CSP offering and market context. | ||
|
|
||
| 4. Match the API tool to the actual need. Some needs require a QoS session; others require a long-lived assignment, a planned booking, device assignment or a reserved multi-profile environment. |
Contributor
There was a problem hiding this comment.
Missing bold on Guardrail 4. All other guardrails use bold for the imperative phrase. This one reads "4. Match the API tool..." without bold.
Suggested change
| 4. **Match the API tool to the actual need**. Some needs require a QoS session; others require a long-lived assignment, a planned booking, device assignment or a reserved multi-profile environment. |
tlohmar
reviewed
Jul 6, 2026
| | Discovery of capabilities | The ability to retrieve information about the offered QoS profiles, network profiles or eligible service areas before requesting or reserving them. | It allows the CSP to make its available capabilities visible to API consumers, who can then use them without needing to know internal network topology. | | ||
| | QoS session | A time-bounded instantiation of a QoS profile to one or more application flows associated with a device. | It explains temporary QoS treatment, either requested On-Demand (using the `quality-on-demand` API) or in-future (using one of the reservation APIs). | | ||
| | Provisioned QoS assignment | A QoS profile associated with a device and applied to all its traffic whenever the device connects to the access network, until the assignment is revoked. | It explains `qos-provisioning`: persistent device-level configuration (like a _premium subscription_) rather than a time-bounded session requested at the moment of use. | | ||
| | Connectivity quality booking | A request to get confidence that the QoS Profile is usable by the requesting API consumer for a given time window — which can start immediately or at a future point — and, where the API allows, a defined service area. | It explains `qos-booking`, `qos-booking-and-assignment` and `dedicated-network`. Through the booking, the API consumer gets confidence that the QoS Profile is usable. The CSP decides whether it can be confirmed. The minimum time between a reservation request and its confirmation/activation is defined by the CSP. Device assignment may be included in the booking or managed separately, depending on the API. | |
Contributor
There was a problem hiding this comment.
Suggested change
| | Connectivity quality booking | Provides confidence that the QoS Profile is usable by the requesting API consumer for a given time window — which can start immediately or at a future point — and, where the API allows, a defined service area. | It explains `qos-booking`, `qos-booking-and-assignment` and `dedicated-network`. Through the booking, the API consumer gets confidence that the QoS Profile is usable. The CSP decides whether it can be confirmed. The minimum time between a reservation request and its confirmation/activation is defined by the CSP. Device assignment may be included in the booking or managed separately, depending on the API. | |
Contributor
There was a problem hiding this comment.
ugh, too many comments already.
Author
|
Thank you for the comments. There are some inconsistencies between what we discussed and agreed (for instance the fact that qos-booking sets the QoS session in the API call or that qod and qos-provisioning get such QoS session either when triggering (qod) or when the provisioned device camps in the network. However, we need to resolve another fundamental issue. How can a QoS session be set on already reserved resources? Understanding that a QoS session is actually the link between device IP:port and AS IP:port for which a QoS Profile is applicable, how can this be set for those APIs which do not establish such link when reserving resources (basically because at time of reservation such devices may not even be known or decided yet). Anybody knows? |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
Add one of the following kinds:
What this PR does / why we need it: