For TLC SXL < 1.1, we should not repond to wrong security with NotAck

[emiltin]

For core version earlier than 1.1, the corrrect behaviour when receiving a command with an incorrect security code is to send a command response with values set to the current states.

We currently respond with a NotAck regardless of the core version.

[emiltin]

Spec 1.1: https://rsmp-nordic.github.io/rsmp_specifications/rsmp_sxl_traffic_lights/1.1/security_codes.html?highlight=security%20code

If an incorrect security code is used then the TLC replies with MessageNotAck where rea is set to Incorrect security code.

Spec 1.0.15 has no no explanation on security codes, as far as I can tell. So where is the expected behaviour defined? Do we fall back on the core spec description of what to do when a command cannot be handled? @otterdahl

[emiltin]

core 3.2: https://rsmp-nordic.github.io/rsmp_specifications/core/3.2/applicability/basic_structure.html?highlight=commandrequest#structure-of-command-response-message

If the object is not known then the site must not disconnect but instead answer with this type of message where age is set to undefined.

Is that the relevant section?

This section in core 3.2 described how to write using a command, but it does not mention what to do if the command is rejected:
https://rsmp-nordic.github.io/rsmp_specifications/core/3.2/applicability/sxl.html#write-operation

@otterdahl can you provide input on where in the spec it's defined what to do if a security code is incorrect for the TLC SXL < 1.1?

[otterdahl]

Do we fall back on the core spec description of what to do when a command cannot be handled? @otterdahl

Correct

core 3.2: https://rsmp-nordic.github.io/rsmp_specifications/core/3.2/applicability/basic_structure.html?highlight=commandrequest#structure-of-command-response-message

If the object is not known then the site must not disconnect but instead answer with this type of message where age is set to undefined.

Is that the relevant section?

Not really. That section deals with parts of the SXL that might be unimplemented by the vendors.

This section in core 3.2 described how to write using a command, but it does not mention what to do if the command is rejected: https://rsmp-nordic.github.io/rsmp_specifications/core/3.2/applicability/sxl.html#write-operation

@otterdahl can you provide input on where in the spec it's defined what to do if a security code is incorrect for the TLC SXL < 1.1?

That section is the only section that describes how to handle commands. If the command is rejected, the values in CommandRequest and CommandResponse does not match. CommandReponse contains the values of what is currently set in the controller. In the case of security code, CommandReponse would contain the correct values, which is not a very good idea. A believe that the vendors replies with an empty value instead.

We have included some clarifications how to handle CommandRequest and CommandReponse in the faq, but it hasn't made it into the spec yet. I'm afraid that this section needs a bit of an overhaul.

[emiltin]

Alright, that will be important to clearly specifity in the next update of core. I think this should also (maybe 4.0) be part of a general streamlining of error handling, see rsmp-nordic/rsmp_core#114.

But for now, we need to choose what behaviour the validator should expect for when receiving a tlc command with incorrect security codes, for sxl version < 1.1.

also, is this expected behaviour independent of core version?

[otterdahl]

But for now, we need to choose what behaviour the validator should expect for when receiving a tlc command with incorrect security codes, for sxl version < 1.1.

If we follow the spec, that we should expect CommandReponse rather then a MessageNotAck. But I think we could consider simply not testing security codes with sxl versions prior to 1.1, rather than enforcing a behaviour that we think is bad anyway.

also, is this expected behaviour independent of core version?

Yes. I don't think the core version has changed much in this regard.

[emiltin]

ok we can skip testing security codes for sxl < 1.1. but we still need to choose how to implement the tlc emulator

[emiltin]

How should our TLC emulator respond when receiving a CommandRequest with invalid security codes?
For SXL >= 1.1 it's clear: send a NotAck
But for SXL < 1.1?

A believe that the vendors replies with an empty value instead.
This is one option. Do you mean a CommandResponse, with all values set to empty strings?

We could also responds with a NotAck. The benefit would be that we do the same same regardless of SXL version. I think I would prefer this.

[emiltin]

To pick up on this, the tlc sxl 1.1 states "If an incorrect security code is used then the TLC replies with MessageNotAck where rea is set to Incorrect security code."

1 .Is that in contradiction to the core spec, which states that the current values must be returned?
2. Should our TLC emulator responds with NotAck for SXL < 1.1?