Problem description
The quality-on-demand API allows devicePorts and applicationServerPorts to be specified to narrow the flow description. Both of these properties use the DevicePorts schema, which currently allows unlimited single ports or port ranges to be specified.
This is unnecessarily generous, and complicates implementation if all options are to be supported. This is a particular issue for NEF based implementations, as source port ranges or lists are not supported, potentially leading to a large number of flow descriptions needing to be created.
Limiting the number of possible input parameters is also good API security practice.
Possible evolution
The number of ports should be limited.
It is proposed that these be significantly limited as follow:
applicationServerPorts: One single port OR one port range
devicePorts: One single port ONLY
Both parameters would remain optional. If NOT specified, then "all ports" is assumed, and this should be explicitly documented.
If a service requires a more complex specification of ports than is supported by the above restrictions, then multiple QoS sessions must be created.
Note that such a significant reduction in port specification capabilities would be considered a breaking change.
Alternative solution
Specify much higher limits that would effectively encompass the current specification and would hence not be a breaking change.
PortsSpec:
description: Specification of several TCP or UDP ports
type: object
minProperties: 1
properties:
ranges:
description: Range of TCP or UDP ports
type: array
minItems: 1
maxItems: 21845
items:
type: object
required:
- from
- to
properties:
from:
$ref: "#/components/schemas/Port"
to:
$ref: "#/components/schemas/Port"
ports:
description: Array of TCP or UDP ports
type: array
minItems: 1
maxItems: 32768
items:
$ref: "#/components/schemas/Port"
These limits may be breaking for some API consumers who have not properly combined their port specification into the minimum number of port ranges, but does not stop them specifying an arbitrary list of ports.
Additional context
None
Problem description
The quality-on-demand API allows
devicePortsandapplicationServerPortsto be specified to narrow the flow description. Both of these properties use theDevicePortsschema, which currently allows unlimited single ports or port ranges to be specified.This is unnecessarily generous, and complicates implementation if all options are to be supported. This is a particular issue for NEF based implementations, as source port ranges or lists are not supported, potentially leading to a large number of flow descriptions needing to be created.
Limiting the number of possible input parameters is also good API security practice.
Possible evolution
The number of ports should be limited.
It is proposed that these be significantly limited as follow:
applicationServerPorts: One single port OR one port rangedevicePorts: One single port ONLYBoth parameters would remain optional. If NOT specified, then "all ports" is assumed, and this should be explicitly documented.
If a service requires a more complex specification of ports than is supported by the above restrictions, then multiple QoS sessions must be created.
Note that such a significant reduction in port specification capabilities would be considered a breaking change.
Alternative solution
Specify much higher limits that would effectively encompass the current specification and would hence not be a breaking change.
These limits may be breaking for some API consumers who have not properly combined their port specification into the minimum number of port ranges, but does not stop them specifying an arbitrary list of ports.
Additional context
None