From CMP review: this set of tests are very valid, but they need to be more generic, in that this test and the two previous test err-22 and err-23 should be moved to be under the session general service behavior. The tests should be expanded to include all service not just the translatebrowsepaths service. This topic is discussed in Part 2 and the related spec is described in part 6 so the topic is covered in the specifications.

As part of this mantis issue the test case definition should also be move to the appropriate location

Script (View Services -> View TranslateBrowsePath -> Err-024.js) is now suppressing the warning for the big time delay of the messages.

These type of tests make no sense.

We added a sentence in Part 4 to make clear that a service request is NOT rejected because of a time difference and not synchronized clocks.
In part 4, table 170, the spec states that the timestamp in the RequestHeader " is only used for diagnostic
and logging purposes in the server".

We added this sentence since such test was in earlier versions of the CTT and the UA WG decided that such tests make no sense.

The text in OPC UA Part 6 - 6.3 is not very concrete. The only shall talks about a configuration parameter. There is no definition what an application (client or server) should do if it detects that the times are not synchronized.

As long as we do not have a general concept for time synchronization, we are not able to enforce such harsh behaviour like rejecting service requests. There should be a better way to indicate suceh a problem that "you are not longer able to talk to me".

part 2 describes that message that are way out are rejected - for security (replay) attacks - The test is not checking is time is close it is checking if time is rejected if it is way out . This is also what part 6 says - again way out - I know we do not have something for time syncing, but the test is not checking close time.

replay attacks can happen when counters roll over so the time stamp have to be check that they are not different by more then the roll over period.

we should discuss this at the F2F

This requires clarification and fix. The test makes no sense at it is today.
A server behaviour hack to pass the CTT creates problems with clients.

Needs discussion in CMP call to define the actual expectation. Spec clearly states that the timestamp is only to be used for diagnostic purposes and therefore it cannot expect to return a bad status for it. BUT the test script first only allowed a Bad_InvalidTimestamp ServiceResult then starting with 2019 also allowed Good. The question now is whether we continue to accept a Bad_InvalidTimestamp or if we should enforce that the server ignores the timestamp.

Updated test case:

Server uses the timestamp only for diagnostic purposes and returns a valid response.
Service Result: 'Good'.

After discussion in the CMP Group it was decided that some servers may still return a Bad_InvalidTimestamp because they need the timestamp for diagnostics.

Updated test case to reflect latest discussion:

Server uses the timestamp only for diagnostic purposes and returns a valid response. Because the server may need it for those purposes it may alternatively return Bad_InvalidTimestamp.

Service Result: 'Good' or 'Bad_InvalidTimestamp '

reviewed test case in call, agreed and closed issue