TS26.512: M1 Policy Template Provisioning - Return codes for error handling of put operation

[dsilhavy]

Description

As part of the PolicyTemplate object defined in TS26512_M1_PolicyTemplatesProvisioning.yaml a chargingSpecification.sponStatus of type TS29514_Npcf_PolicyAuthorization.SponsoringStatus may be defined. The SponsoringStatus string is defined as follow:

SponsoringStatus:
      description: Indicates whether sponsored data connectivity is enabled or disabled/not enabled.
      anyOf:
      - type: string
        enum:
          - SPONSOR_DISABLED
          - SPONSOR_ENABLED
      - type: string

Although any value of type string is a valid value for this parameter, implementations might only support one of the two possible enum values, namely SPONSOR_DISABLED and SPONSOR_ENABLED. In cases in which a value is used that does not correspond to one of the aforementioned enum values, it is desirable to send an error code to the sending entity to signal that the request contained unsupported or invalid payload.

The put operation to update an existing policy template defined in TS26512_M1_PolicyTemplatesProvisioning.yaml only allows two response codes, namely 204 and 404. Both are not well suited for the described use case in which an unssuported payload is provided.

Suggested solution

To handle use cases in which an invalid or unsupported payload is sent as part of the put operation, additional response codes should be supported. For instance, a 422 response code allows signaling unprocessable content and might be a good option to signal unsupported parameters in the payload: https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/422

Related issues

• Policy Templates - chargingSpecification.sponStatus - Invalid values are ignored rt-5gms-application-function#123

[rjb1000]

My reading of 422 Unprocessable Content is that is applies in cases where the syntax is valid but the semantic is not.

This case falls in the crack between a syntax error and a semantic error. While the invalid enumerated value is technically valid in the the OpenAPI YAML syntax, our particular implementation doesn't support it because it is not a valid value in the current version of the specification. To my mind that feels more on the side of a syntax error, but one that isn't policed automatically by the OpenAPI YAML definition.

I would therefore lean slightly more towards a 400 Bad Request client error response code in this case.

[rjb1000]

This issue is actually part of a wider lack in the TS 26.512 YAML specifications. Many API operations do not have a comprehensive list of HTTP error responses. This has been addressed in TS 26.510 Rel-18. The question is whether it's worthwhile going back and fixing in Rel-16 and Rel-17.

In practice, implementations are free to return whichever HTTP response codes they like, and recent improvements in the handling of enumerated types in the 5GMS AF implementation mean that we can now automatically send an error if an unrecognised enumerated value is encountered.

[rjb1000]

We probably need to broaden out the scope of this issue to improve all HTTP responses across all M1 and M5 APIs.

But we may only address Rel-17.