I think if a client does not need a connection, it would not listen for new connections and server tcp connects would fail. A server need to retry to see if the client needs a connection.

Needs in this context is that the client want to create a conection to the server or want to reconnect to the server or is doing discovery.
If a client has all "expected connections" working, there is no need to listen for tcp connects on the server side.

The client would start to listen as soon as a reconnect, new connect or discovery is needed.

A server would try tcp connects but would only succeed if the client is waiting for a connect.

Part 6 needs to state there needs to be a finite number of open unused sockets that get recycled. Also the option of a whitelist of ServerURIs can help with DOS,

May need to clone to Part 2 once the Part 6 update is made.

If the Reverse Connect scenario should support multiple connections & SecureChannels between the same Client and Server, AND if the initiative to opening them should come from the Server, then I think we are missing a flag in the "Reverse Hello" message to distinguish whether

1) The server wants to create a new SecureChannel at this moment,
2) The server is opening a "back-up" connection as implied by the sentence "When a SecureChannel is established, the Server shall immediately create a new socket and sends a new ReverseHello to ensure the Client is able to create another SecureChannel if it is needed.

Without the flag, the Client cannot tell what it should do at that moment.
In the first case, it needs to proceed with "Hello" and the full sequence till SecureChannel handshake (and CreateSession etc.)
In the second case, it just needs to check the "Reverse Hello" request, and then sit idle on that connection until "... it is needed".

I think there is still a basic missunderstanding.

The server has never the initiative to open a secure channel. And the server does not know the client side requirements.

The server only knows that there is a client with a hostname or IP and port that potentially want to create one or more SecureChannels with the server.
The server tries to offer TCP/IP connections to the client, nothing else.
The client decides if he want to create a SecureChannel and a Session. Never the server.

The only difference between normal connect and reverse connect is the step to create the TCP/IP connection

This is not misunderstanding. I know what the spec says, and I understand your explanation, which is one way the spec can be read. I have intentionally started my note with "If ..." so that we can clarify whether the condition of the "If..." is intended to be true or not. You have confirmed that the "If..." condition is, in fact, meant to be false, and that's fine with me.

It then confirms my concerns about Denial of Service attacks. And we agreed to clarify the handling of additional Reverse Hello requests and when and how "idle" connections will be dropped.

Clients shall monitor the number of unused sockets per peer IP address. The Client shall immediately close unused sockets if the count exceeds the needs of the Client. An administrator may configure the Client with list of IP addresses which are allowed to establish reverse connections. The Client may build its own list of trusted IP addresses from the IP addresses used by active SecureChannels which have been authenticated.

Updated text:

Clients shall monitor the number of unused sockets used to send a ReverseHello but do not have an active SecureChannel per peer IP address. The Client shall immediately close unused these extra sockets if the count exceeds the needs of the Client . An administrator may configure the Client with list of IP addresses which are allowed to establish reverse connections. The Client may build its own list of trusted IP addresses from the IP addresses used by active SecureChannels which have completed the authentication process.

Agreed to reopen in Web meeting to add addtional text.

Added table describing the handshake agreed to in the meeting.

Agreed to 1.05.03 Draft text, but needs 1.04 Errata to close.

DoS for Reverse connect needs to be updated in Part 2 to match.

What I would like to see clarified in Part 2 is this: "... the Client needs to validate that the connection is from an appropriate Server and not a denial of service attack. If the Server does not respond in a timely manner to the open SecureChannel request the Client should close the channel.".
What does "needs to validate.... is from an appropriate Server..."?

After the changes made to Part 6, technically, I think the client is either allowed to verify just the ApplicationUri in ReverseHello message (which can be easily spoofed), and pause ("save the socket") before it needs the SecureChannel. Or, the client can establish the SecureChannel immediately - only which truly verifies that "the connection is from an appropriate Server".

Does Part 2 allow the client both of these approaches, or does it mandate that the SecureChannel must be created? Can it be made clearer?

We need to make sure that reverse connect include tets cases for the following

open socket, but no reversehello message sent
Open Socket and send a different maessage then a reverse hello
ServerUri > 4096 in size
ServerUri - that does not match any server
EndpointUrl > 4096 in size
EndpointUrl that is unknow