Original text:
a clear handshake, like TCP, then the obvious choice is to declare that node "connected" when the last packet of the three-way handshake has been received.  If the only protocol being used is an <del> "unconnected" protocol, like UDP, the implementation may consider the node fully "connected" the moment it determines a route is present, before sending any packets on the network, see further unconnected- racing. </del>  For protocol stacks with multiple handshakes, the decision becomes more nuanced.  If the protocol stack involves both TLS and TCP, an While protocols that use an explicit handshake to validate a Connection to a peer can be used for racing multiple establishment <del> attempts in parallel, "unconnected" protocols such as raw UDP do not </del>  offer a way to validate the presence of a peer or the usability of a Connection without application feedback.  An implementation should consider such a protocol stack to be established as soon as the Transport Services system has selected a path on which to send data. However, if a peer is not reachable over the network using the <del> unconnected protocol, or data cannot be exchanged for any other </del>  reason, the application may want to attempt using another candidate Protocol Stack.  The implementation should maintain the list of other candidate Protocol Stacks that were eligible to use. 4.6.2. <del> Unconnected protocols such as UDP and UDP-lite generally do not </del>  provide the same mechanisms that connected protocols do to offer Connection objects.  Implementations should wait for incoming packets <del> for unconnected protocols on a listening port and should perform </del>  four-tuple matching of packets to either existing Connection objects or the creation of new Connection objects.  On platforms with <del> facilities to create a "virtual connection" for unconnected protocols implementations should use these mechanisms to minimise the handling of datagrams intended for already created Connection objects. </del>  4.6.3. Each protocol has a notion of Connectedness.  Possible values for Connectedness are: <del> Unconnected.  Unconnected protocols do not establish explicit state between endpoints, and do not perform a handshake during Connection establishment. </del>  Connected.  Connected protocols establish state between endpoints, and perform a handshake during Connection establishment.  The 10.3. <del> Connectedness: Unconnected </del>  Data Unit: Datagram 10.4. <del> Connectedness: Unconnected </del>  Data Unit: Datagram 10.5. <del> Connectedness: Unconnected </del>  Data Unit: Datagram

Reviewer comments:
Just check "connected" - in case we mean connection-oriented; and that usage of "connect" is sane, we need care.
UDP is best described as connectionless, not unconnected: it has no notion of a connection, where "unconnected" might imply a particular usage pattern for a protocol that also supports connections.
YES! UDP is "connectionless"; confusing APIs do support a "connected mode". Please remove unconnected.

Revised text:
a clear handshake, like TCP, then the obvious choice is to declare that node "connected" when the last packet of the three-way handshake has been received.  If the only protocol being used is an  <ins> connectionless protocol, like UDP, the implementation may consider the node fully "connected" the moment it determines a route is present, before sending any packets on the network, see further connectionless-racing. </ins> For protocol stacks with multiple handshakes, the decision becomes more nuanced.  If the protocol stack involves both TLS and TCP, an While protocols that use an explicit handshake to validate a Connection to a peer can be used for racing multiple establishment  <ins> attempts in parallel, connectionless protocols such as raw UDP do not </ins> offer a way to validate the presence of a peer or the usability of a Connection without application feedback.  An implementation should consider such a protocol stack to be established as soon as the Transport Services system has selected a path on which to send data. However, if a peer is not reachable over the network using the  <ins> connectionless protocol, or data cannot be exchanged for any other </ins> reason, the application may want to attempt using another candidate Protocol Stack.  The implementation should maintain the list of other candidate Protocol Stacks that were eligible to use. 4.6.2.  <ins> Connectionless protocols such as UDP and UDP-lite generally do not </ins> provide the same mechanisms that connected protocols do to offer Connection objects.  Implementations should wait for incoming packets  <ins> for connectionless protocols on a listening port and should perform </ins> four-tuple matching of packets to either existing Connection objects or the creation of new Connection objects.  On platforms with  <ins> facilities to create a "virtual connection" for connectionless protocols implementations should use these mechanisms to minimise the handling of datagrams intended for already created Connection objects. </ins> 4.6.3. Each protocol has a notion of Connectedness.  Possible values for Connectedness are:  <ins> Connectionless.  Connectionless protocols do not establish explicit state between endpoints, and do not perform a handshake during Connection establishment. </ins> Connected.  Connected protocols establish state between endpoints, and perform a handshake during Connection establishment.  The 10.3.  <ins> Connectedness: Connectionless </ins> Data Unit: Datagram 10.4.  <ins> Connectedness: Connectionless </ins> Data Unit: Datagram 10.5.  <ins> Connectedness: Connectionless </ins> Data Unit: Datagram