Specification around timeout for FinalizeRequest

[ssachinbharadwaj]

All the sub-projects under gNSI have a similar flow in the Rotate() which expects FinalizeRequest after the test/validation stage.
The client performs the test/validation parallel to the existing Rotate() stream.
All good if the client sends FinalizeRequest.

How long should the server wait if the client does not send FinalizeRequest?

Having a vendor-specific wait defeats the purpose of vendor neutrality with respect to timeout.
At the same time, having infinite wait on the server side is impractical because if a buggy client forgets to send 'FinalizeRequest' and keeps the stream open, it stays in the same state forever and no new Rotate() can be performed since the first Rotate() is still alive.
This also depends on the time it takes for the client to perform a test/validation.

Either of the below should be fine but this needs to be part of the spec:

1. Have timeout defined to handle buggy clients.
2. (OR) Assume that the client always sends FinalizeRequest and have an infinite wait on the server side.

Any specification/guideline in this regard will be helpful for both the server and client implementors.

[tomek-US]

I would lean towards adding explicit statement that there is no timeout.

Assuming that a timeout is added, what value and rules for restarting it do you have in mind?

[ssachinbharadwaj]

Assuming that a timeout is added, what value and rules for restarting it do you have in mind?

Yes this is subjective and the value differs across different services because the test/validation is performed outside of the scope of these services. So, having one single timeout may not make sense.

I would lean towards adding explicit statement that there is no timeout.

I am fine with specifying that there is no timeout and servers MUST wait indefinitely for either:

1. FinalizeRequest (Test/validation success case)
2. (OR) Stream cancellation (Test/validation failure case)