Reflecting device limitations through scheduled activation 'requested_time'

[andrewbonney]

I had a query raised earlier in the year regarding use of the requested_time attribute for scheduled activations.

The current text in https://amwa-tv.github.io/nmos-device-connection-management/tags/v1.1/APIs/schemas/resolved/activation-response-schema.html, as reflected in the testing tool is that requested_time in the activation response should match what was included in the activation request. If however a device cannot achieve nanosecond granularity in its activations (for example if it can only manage to the nearest millisecond), what would be best to reflect back in this attribute? Should it reflect the request, or should it attempt to inform the control system via the response that it is incapable of meeting the requirement and will only activate at the time specified in the returned requested_time.

This would of course open questions such as 'how far away from the original requested time is acceptable to return?' and 'should I activate earlier or later than originally requested in this case?'.

[garethsb]

We already have that the activation_time should reflect the time the sender or receiver "did actually activate" for both scheduled and immediate activations.

Without any means in the current spec for the client to indicate the variance it is prepared to accept or the sender/receiver to indicate the precision it can offer, I think we should stick to the returned requested_time reflecting exactly what was requested.

[garethsb]

Any change in this should be made consistently in IS-08, see Behaviour - Activation Responses.