Skip to content
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

Default duration should be only an example #115

Closed
hdamker opened this issue Feb 15, 2023 · 3 comments
Closed

Default duration should be only an example #115

hdamker opened this issue Feb 15, 2023 · 3 comments
Labels
QoD wontfix This will not be worked on

Comments

@hdamker
Copy link
Collaborator

hdamker commented Feb 15, 2023

Issue

Within API documentation the default session duration of 24 hours is only given as an example:

  • "... or the default session expiration time has been reached (within an example provider implementation it is set to 24hrs)"
  • "When not specified, a default session duration (e.g. 24 hours) is applied"

but in the API YAML file it is fixed:

duration:
          type: integer
          example: 86400
          description: |
            Session duration in seconds. Maximal value of 24 hours is used if not set.
            After session has expired the client will receive QOS_STATUS_CHANGED event with 
             - qosStatus is 'UNAVAILABLE', and, 
             - statusInfo is 'DURATION_EXPIRED'. 
            See notification callback.
          format: int32
          minimum: 1
          maximum: 86400
          default: 86400

Proposal:

Omit "Maximal value of 24 hours is used if not set" and the default: 86400 line from the general YAML, 24 hours is then still the maximum and implicit default value, if there is not other default value defined by the network operator. A network operator can set a specific default for their network enviroment. A PR should also make the documentation more precise and encourage developers to set the duration if they expect a certain duration.

Background:

We would like to set a short default duration in certain networks (using environment variable), e.g. in case of test environments (as a mitigation to issue described in #101).
Also a default of 24 hrs might be too long from business perspective in production networks.

@hdamker hdamker added the QoD label Feb 15, 2023
@jlurien
Copy link
Collaborator

jlurien commented Feb 16, 2023

Sounds reasonable to me. As you say the maximum implies an upper limit, so no implementation should allow a higher value, but we may allow different policies regarding the default. In any case, the client can always request for a value explicitly, and it will be informed of the applied value in the response.

@hdamker hdamker added the wontfix This will not be worked on label Apr 20, 2023
@hdamker
Copy link
Collaborator Author

hdamker commented Apr 20, 2023

We propose to not fix the issue. For test/lab deployments we have internal (not schema conform) solution to configure the default value. Leaving out the default value in the API spec would make the description incomplete.

A an alternative (correct) solution would be to make the duration paramater mandatory, but that would be a different issue.

@hdamker
Copy link
Collaborator Author

hdamker commented Apr 24, 2023

Won't fix.

@hdamker hdamker closed this as not planned Won't fix, can't repro, duplicate, stale Apr 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
QoD wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants