-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible inconsistency in specification of Service Data Flow Description #74
Comments
@tlohmar: please confirm that the suggested remedy was your original intent when specifying the Dynamic Policy instantiation API. |
hmm, the data type can be used for different purposes, thus, contains a 'at least one' of the properties. For Dynamic Policies, there is an additional constraint, i.e. 'at most one' / 'one of'. What is the inconsistency? |
Ah... I see where you are coming from now, @tlohmar. You are saying that the data type is loosely defined on purpose at clause 6.4.3.2 to allow for future flexibility, but the additional constraint for Dynamic Policies is additionally specified on top of that in clause 11.5.4. And this explains why the constraint is not enforced by the OpenAPI specification of the This is rather unfortunate, in my opinion. It would be quite nice to enforce this in the OpenAPI syntax if possible. Otherwise, the implementer has to join the dots to enforce the constraint in custom code for each usage of the data type where the constraint applies. The only other usage of the If we ever have a need to describe service data flows with both an IP Packet Filter Set and a domain name, I would suggest we define a different data type with different constraints. That makes things nice and explicit in the OpenAPI with no ambiguity. And these constraints can be enforced by the code automatically generated by compiling the OpenAPI YAML. Hence, unless there is a good reason not to, I would advocate amending clause 6.4.3.2 and the OpenAPI syntax to make the "exactly one of" constraint explicit. |
Any additional thoughts, @ibouazizi? |
Yes, I agree. Would be better to have more in the OpenAPI syntax. My earlier comment was more on the reason for change |
Initial prototyping suggests that it's difficult to enforce I might just make the simple clarification in clause 6.4.3.2, so that at least the cardinality of the members is clearly specified in a common location. |
Proposed clarification in clause 6.4.3.2 endorsed at post-SA4#124 ad hoc meeting:
|
Context
Clause 11.5.4 of TS 26.512 states:
This implies that
flowDescription
anddomainName
are mutually exclusive properties.(A
ServiceDataFlowDescription
is also supplied by the Media Session Handler when creating a new Network Assistance session, per clause 11.6.3.1.)Clause 6.4.3.2 specified the
ServiceDataFlowDescription
data type as having the above two properties, which are both specified as being optional. The following sentence appears at the end of this clause:Problem description
The two normative statements highlighted above appear to be contradictory.
Suggested solution
ServiceDataFlowDescription
.flowDescription
anddomainName
are mutually exclusive using theoneOf
YAML keyword.The text was updated successfully, but these errors were encountered: