In devices with limited resources processing of OpenSecureChannel request takes considerable time (few seconds). Blocking of other requests from the same client while OpenSecureChannel is being processed would mean interruption of data flow for that client. Server could block only incoming requests and still send responses to the Publish requests which were already queued on the server side. But if receiving of Publish messages stops, then Publishing queue on the server side could became empty, sampling queues become full, and data loss would start.
In multithreaded servers other requests from the same client ( as well as from other clients) could be processed in parallel, using existing security token. But in this case there is an opinion that it would be violation of the clause "The contents of the MessageChunk shall not be interpreted until the Message is decrypted and the signature and sequence number verified" of the specification Part 6, section 6.7.6. Therefore its proposed to clarify how verification of sequence numbers should be done. If it is understood as “every chunk must have sequence number equal to sequence number of the previous one + 1”, then it means the server cannot process further requests until OpenSecureChannel request is decrypted and its sequence number becomes known.

Lets assume that sequence number for the request which was received right before the OpenSecureChannel request is N. It is verified that one before it had N-1, so it is strictly verified. When the server receives OpenSecureChannel after it, its sequence number is expected to be N+1, but it is not known until decryption is complete. Note that it is known this message is of type OPN, because that part is not encrypted.

The proposal is: for this particular case only, i.e. when we have message of type OPN being processed, when next requests have sequence numbers as N+2, N+3, N+4 and so on, then they should be considered as valid and verified, even we don’t know what is actually sequence number for the OpenSecureChannel request. As soon processing of the OpenSecureChannel request is complete, then the server should close the connection if its sequence number is not N+1.

This would allow un-interrupted data flow without large queue sizes.

Example: during 3 seconds, for monitored items sampled with 50 ms interval, 60 data changes can occur. Number of Publish queue size on the server side is often limited to 2, so in order to deliver those data changes, each publish response should be able to store 25 values. If number of items is large enough, then it can exceed max message size, or max number of notifications, etc.
So it is better to allow communication flow while secure channel renewal. All communication is still encrypted with valid token, therefore I don’t see security risk here which such exemption on sequence number verification could cause.