A successful attach should clear any errorReason set on a channel from a previous failure

[paddybyers]

As we discussed the other day, I think this is a spec omission.

[paddybyers]

Proposed spec text changes

This can be addressed by amending RTL4c and simplifying RTL4g, rather than adding a new spec point.

RTL4c (amend)

Current:

Otherwise an ATTACH ProtocolMessage is sent to the server, the state transitions to ATTACHING and the channel becomes ATTACHED when the confirmation ATTACHED ProtocolMessage is received

Proposed:

Otherwise an ATTACH ProtocolMessage is sent to the server, the state transitions to ATTACHING and the channel becomes ATTACHED when the confirmation ATTACHED ProtocolMessage is received. When the confirmation ATTACHED ProtocolMessage is received, the channel's errorReason is set to null.

RTL4g (simplify)

Current:

If the channel is in the FAILED state, the attach request sets its errorReason to null, and proceeds with a channel attach described in RTL4b, RTL4i and RTL4c

Proposed:

If the channel is in the FAILED state, the attach request proceeds with a channel attach described in RTL4b, RTL4i and RTL4c

The errorReason clearing previously specific to RTL4g is subsumed by the new RTL4c behaviour — it now applies to all successful attaches regardless of prior state (FAILED, SUSPENDED, re-attach after disconnect, etc.).

RTL24 (no change needed)

RTL24 lists the spec points that set/clear errorReason. RTL4g is already in that list and RTL4c will now also clear it, so RTL4g's reference covers the intent. Optionally, the RTL24 text could be updated to reference RTL4c explicitly.