Add PATCH operation

[emil-cheung]

What type of PR is this?

Add one of the following kinds:

• enhancement/feature

What this PR does / why we need it:

• Update an existing QoD session

Which issue(s) this PR fixes:

Fixes #47

Special notes for reviewers:

Changelog input

 release-note

Additional documentation

This section can be blank.

docs

[eric-murray]

@emil-cheung I didn't think the discussion on what parameters could be patched had been concluded, so my questions on your proposal are:

• Why allow applicationServer to be updated? Whilst this may be technically possible, the new server might not be compatible with the agreed QoS profile or business / legal considerations (e.g. prioritising traffic the new application server might not be compliant with net neutrality rules).

  And what happens if the PATCH request is refused because the new application server is not allowed? Does traffic continue to be prioritised to the previous application server, even though that may not be required.

  My preference would be to not allow applicationServer to be patched, and instead require a new session to be created if a change in application server is required.

• Why can qosProfile not be patched? I would have thought that a more likely scenario than changing application server. For example, the end user application might find that the QoS profile currently being used does not give the desired QoE, and wants to upgrade without changing other parameters.

• Does the patched duration still apply from the original session creation time? So sessions are still limited to one day, and this cannot be extended by patching?

• The notificationUrl and notificationAuthToken format does not match that being proposed in #155, which is following the updated CAMARA design guidelines. Also, updating notificationAuthToken is understandable, by why would notificationUrl be updated during a session?

[hdamker]

On duration we need to decide the semantics:

• does the duration values still counts from begin of the session? What happens then if PATCH sets a duration which is already exceeded by the session?
• or will the duration be counted from the (successful) PATCH operation onwards? (only that will allow to achieve sessions longer than the defined maximum of 86400 seconds)

[hdamker]

A general comment: I consider this PR as one for the release after v0.9.0. It will need intensive discussions before it can be merged and would therefore postpone the release otherwise.

[emil-cheung]

A general comment: I consider this PR as one for the release after v0.9.0. It will need intensive discussions before it can be merged and would therefore postpone the release otherwise.

@hdamker It is for v0.10.0 and no hurry. As the v0.9.0 comes to the end, I provide a draft proposal for the community to further discuss.

[jlurien]

Agree that we have to discuss which parameters it makes sense to allow to be updated. Requirement should come from what it is convenient and intuitive for the client, not just because it is technically feasible to do it in the network.

[emil-cheung]

Agree that we have to discuss which parameters it makes sense to allow to be updated. Requirement should come from what it is convenient and intuitive for the client, not just because it is technically feasible to do it in the network.

@jlurien @eric-murray @hdamker Sorry for moving too quickly. Let's park the PR at this moment and go back to the #47 to discuss the changeable attributes. I have created a table to scan the attributes in Session information.

[emil-cheung]

On duration we need to decide the semantics:

• does the duration values still counts from begin of the session? What happens then if PATCH sets a duration which is already exceeded by the session?
• or will the duration be counted from the (successful) PATCH operation onwards? (only that will allow to achieve sessions longer than the defined maximum of 86400 seconds)

@hdamker My thought is the timer will be reset since the successful PATCH operation, which is simple and clear.

[hdamker]

@emil-cheung: i changed the PR to "draft" status, until we have discussed the behavior behind patching duration withing in the issue #47 and PR is adapted based on the result.

(all people who have subscribed to the PR previously are still subscribed)