Open RandyLevensalor opened 1 year ago
MOM-2023-12-01:
Problem description Some QoS profiles may not be available to every customer. This can be due to their current plan, capabilities/capacity of the local network, device features or other attributes. So only a set of available profiles should be returned.
Possible evolution
Alternative solution
Additional context
The discovery endpoint filters QoS profiles based on target user's mobile subscription which makes some sense. However, filtering QoS profiles bases on network capacity is a bit tricky. As network capacity is so dynamic, usually the Policy node in a network shall consider.
I would suggest that we only scope the mobile subscription aspect at least at this stage.
Once we proceed with the agreed split (#265), we can discuss further enhancements. I see two approaches:
1) If we consume that endpoint with client credentials, we'd need a filter to be passed. If we have to pass personal information as phone numbers, we probably need to change to a POST method. 2) With a three-legged access token we can rely on the info linked to the access token, to let the implementation adapt the response to it.
This is looking similar to the query in issue #101 and I think that it could be follow a similar pattern using both the three-legged access token and the device schema in the request.
Yes, it's quite the same situation
Problem description Some QoS profiles may not be available to every customer. This can be due to their current plan, capabilities/capacity of the local network, device features or other attributes. So only a set of available profiles should be returned.
Possible evolution
Alternative solution
Additional context