Clarification on Unavailable status

[Masa8106]

Problem description
In QoD API, Unavailable status is documentd as UNAVAILABLE - The requested QoS cannot be provided by the network due to some reason.
However, the cause of UNAVAILABLE is not only by the network but also by API consumer, e.g. deletion request by API consumer.
So it is expected to be clarified.

Expected action
To update the description to UNAVAILABLE - The requested QoS cannot be provided by the network due to some reason or by deletion request from API consumer for clarification.

Additional context
None

[hdamker]

@Masa8106

Thanks for raising this.

After looking at the session lifecycle, I think the current description of QosStatus is actually correct as-is, because the UNAVAILABLE state is only observable on a session object that still exists — which only happens when the network terminates the session (the session lingers for at least 360 seconds to allow polling consumers to discover it).

When the API consumer calls deleteSession, the response is 204 and the session resource is removed. There is no session object left that could have a qosStatus of UNAVAILABLE. The UNAVAILABLE + DELETE_REQUESTED combination only appears in the notification event (QOS_STATUS_CHANGED), which uses the separate EventQosStatus enum — and that one already has broader wording: "A requested or previously available QoS session is now unavailable."

So adding "or by deletion request from API consumer" to the QosStatus description could be misleading, because it would suggest that a deleted session can still be retrieved in UNAVAILABLE state — which it cannot.

If anything, the EventQosStatus description could be made more explicit about the DELETE_REQUESTED case, but I think it already covers it sufficiently.