Change:
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.

Discussion:
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> <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 <del> attempts in parallel, "unconnected" protocols such as raw UDP do not </del> <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 <del> unconnected protocol, or data cannot be exchanged for any other </del> <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. <del> Unconnected protocols such as UDP and UDP-lite generally do not </del> <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 <del> for unconnected protocols on a listening port and should perform </del> <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 <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> <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: <del> Unconnected.  Unconnected protocols do not establish explicit state between endpoints, and do not perform a handshake during Connection establishment. </del> <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. <del> Connectedness: Unconnected </del> <ins> Connectedness: Connectionless </ins> Data Unit: Datagram

10.4. <del> Connectedness: Unconnected </del> <ins> Connectedness: Connectionless </ins> Data Unit: Datagram

10.5. <del> Connectedness: Unconnected </del> <ins> Connectedness: Connectionless </ins> Data Unit: Datagram