-
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
TS 26.512 Policy Template state reasons #62
Comments
Adding a human-readable string in the Policy Template sounds sensible from an operational point of view. This could be called something as simple as |
General question on
TS 29.501 points to RFC 7807 (JSON ProblemDetails) for more detailed error information. What about inserting a object of type ProblemDetails (TS 29.571)? |
Good idea. I like this suggestion to reuse an existing type. |
Once we have a candidate solution more fleshed out, we should check whether this needs to be backported to Rel-17 and/or Rel-16. |
I checked the YAML specification for
Basically, there are a lot of fields that wouldn't be relevant in the context of a simple error response because it is intended to be used to convey errors in reponse to RESTful service operations, which is different from the use case we are trying to satisfy here. On the other hand, all the properties of the data type are optional, so this isn't such a worry. We could profile it down for use in this context. |
OK. I propose adding a new mandatory property in Rel-17 below
|
CR contributed to SA4#124 (Berlin):
|
CR Pack SP-230546 including TS 26.512 CR0033r5 (Rel-17) and CR0035 (Rel-16) approved at SA#100 (Taipei). |
📣 3GPP TS 26.512 V16.10.0 and V17.5.0 are now published: |
Updated APIs now published: |
Description
TS 26.512 Clause 4.3.7.1 shows a model where Policy Templates in a Provisioning Session transition through various states.
Some of these state changes will happen for a specific reason ("invalid" and "suspended" states). In order for the AP to address issues with a PolicyTemplate, it needs to know this reason. There is no way, in the v17.4.0 version of TS 26.512, of conveying this reason to the Application Provider with the PolicyTemplate resource (TS 26.512 Clause 7.9.3.1).
Suggested solution
Add a conditional
stateReason
field, of typeString
, to the PolicyTemplate resource in Table 7.9.3-1 which will hold a human readable reason for the latest state change. This new field must be present if thestate
field is "invalid" or "suspended". This can then be populated with a reason for the rejection of a PolicyTemplate when it is transitioned to the "invalid" state by a System operator, or can hold a description of the policy violation which led to the PolicyTemplate entering the "suspended" state (e.g. paid for data limits reached or too many clients using the policy).The text was updated successfully, but these errors were encountered: