Can a session be extended if the QoS profile becomes inactive?

[maxl2287]

I have created Issue #419 to implement an HTTP-422 response when a requested QoS profile is unavailable.

However, I have a question regarding the following scenario:

1. A user requests a QoD session with an AVAILABLE QoS profile (e.g., "QOD_L") for one day.
2. The session is successfully created, returning HTTP-201.
3. During the day, the QoS profile status changes to INACTIVE.
4. The user attempts to extend their session.

What should happen in this case?

a) The user can successfully extend the session.
b) The request is rejected with HTTP-422, indicating that the QoS profile is currently unavailable or not applicable.

{
  "status": 422,
  "code": "QUALITY_ON_DEMAND.QOS_PROFILE_NOT_APPLICABLE",
  "message": "The requested QoS profile is no longer available for session extension."
}

c) <...>

I've started a discussion on this topic. Looking forward to your input!

[RandyLevensalor]

I assume b, would be the most likely action.

Does this behavior have to be determined by the API? Could the API provider or network provider on the backend determine if the profile can be extended?

• If the profile was deactivated in favor of a more resource intensive one, then continuing this profile would be a valid path for the operator to provide.
• If the profile was deactivated due to lack or resources or cost associated with continuing supporting the profile then returning a 422 and not granting the extension would be valid.
• This could even be seen as being grandfathered into a legacy plan until as long as the session is extended.

Are there any regulatory challenges or differences with this? I'm not aware of any.

[jlurien]

To me it depends on whether the UNAVAILABLE status is final or not. Really, the current definition of the API is a bit ambiguous on this:

We don't say explicitly that a session cannot transit from UNAVAILABLE to AVAILABLE, but the statusInfo values that inform of the reason are all final. However, statusInfo is optional, so there is some space there for doubt.

It we "close this door" and make clear that UNAVAILABLE is final, then it wouldn't be coherent to allow extending a terminated session.

@hdamker wdyt? should we clarify better the session life cycle?

[hdamker]

@hdamker wdyt? should we clarify better the session life cycle?

There is always room for improvement in documentation :-) My understanding so far is that UNAVAILABLE is a final state. And the extend operation is clear here: "Extend the overall session duration of an active QoS session (with qosStatus = AVAILABLE)", it can't used on an UNAVAILABLE session. I don't see an operation which can reactivate an UNAVAILABLE session (and the server can delete the resource after the grace period of 360 seconds).

But that is anyway not the topic of this discussion ... @maxl2287 asked what happens if the QoS profile status changes to INACTIVE during the session and then the API consumer tries to extend the session. The title of the discussion was misleading here, I have corrected it now.