Change:
replace DG by CL. Changed one oddity: /as to/ to /about/
"Connection establishment is only a local operation for a Datagram transport (e.g., UDP(-Lite))": I think the criterion is not Datagram transports but "transports without a handshake" or "connectionless protocols" as it is used later in the document.
I wrote, and I suggest we use "connectionless protocols" explicitly mentioning examples of UDP and UDP-Lite when used as a transport without a handshake.
To whoever plans to address this: I checked occurrences of the word "datagram" in the architecture and API drafts, and I found (only) one sentence that needs fixing on similar grounds, I think, in the API draft: in Section 8.1.4 "Timeout for keep alive packets". Surely the guidance regarding this matter in the UDP usage RFC is related to the fact that UDP(-Lite) is connectionless, not that it's datagram based.
Starting to fix this.
This LGTM

Discussion:
independent of other connections that are not part of the same Connection Group. <del> Connection establishment is only a local operation for a Datagram transport (e.g., UDP(-Lite)), which serves to simplify the local send/receive functions and to filter the traffic for the specified addresses and ports RFC8085. </del> <ins> Connection establishment is only a local operation for a connectionless protocols, which serves to simplify the local send/ receive functions and to filter the traffic for the specified addresses and ports RFC8085 (for example using UDP or UDP-Lite transport without a connection handshake procedure). </ins> Once Initiate has been called, the Selection Properties and Endpoint information are immutable (i.e, an application is not able to later

arch), in which the necessary protocol handshakes are conducted so that the transport system can select which set to use. <del> This document structures the candidates for racing as a tree as terminological convention.  While a a tree structure is not the only way in which racing can be implemented, it does ease the illustration of how racing works. </del> <ins> As a terminological convention, this document structures the candidates for racing as a tree.  While a tree structure is not the only way in which racing can be implemented, it does ease the illustration of how racing works. </ins> The most simple example of this process might involve identifying the single IP address to which the implementation wishes to connect,

original request.  New connection attempts that involve transmitting data on the network ought not to be started after another leaf node has already successfully completed, because the connection as a whole <del> has now been established.  An implementation may choose to let certain handshakes and negotiations complete in order to gather metrics to influence future connections.  Keeping additional connections is generally not recommended since those attempts were slower to connect and may exhibit less desirable properties. </del> <ins> has now been established.  An implementation could choose to let certain handshakes and negotiations complete to gather metrics that influence future connections.  Keeping additional connections is generally not recommended, because those attempts were slower to connect and may exhibit less desirable properties. </ins> 4.4.1.

5.2. <del> Similar to sending, Receiving a Message is determined by the top- </del> <ins> Similar to sending, receiving a Message is determined by the top- </ins> level protocol in the established Protocol Stack.  The main <del> difference with Receiving is that the size and boundaries of the </del> <ins> difference with receiving is that the size and boundaries of the </ins> Message are not known beforehand.  The application can communicate in its Receive action the parameters for the Message, which can help the Transport Services implementation know how much data to deliver and

complete Message, the implementation should wait until an entire Message (datagram, stream, or frame) is read before delivering any Message content to the application.  This requires the implementation <del> to understand where messages end, either via a supplied deframer or because the top-level protocol in the established Protocol Stack preserves message boundaries.  If the top-level protocol only supports a byte-stream and no framers were supported, the application can control the flow of received data by specifying the minimum number of bytes of Message content it wants to receive at one time. </del> <ins> to understand where messages end, either via a supplied or because the top-level protocol in the established Protocol Stack preserves message boundaries.  If the top-level protocol only supports a byte- stream and no framers were supported, the application can control the flow of received data by specifying the minimum number of bytes of Message content it wants to receive at one time. </ins> If a Connection finishes before a requested Receive action can be satisfied, the Transport Services API should deliver any partial

purposes of the Transport Services API, these are ways for applications or application frameworks to define their own Message parsing to be included within a Connection's Protocol Stack.  As an <del> example, TLS is exposed as a protocol natively supported by the Transport Services API, even though it could also serve the purpose of framing data over TCP. </del> <ins> example, TLS is exposed as a protocol that is natively supported by the Transport Services API, even though it could also serve the purpose of framing data over TCP. </ins> Most Message Framers fall into one of two categories:

Upon receiving this event, a framer implementation is responsible for performing any necessary transformations and sending the resulting data back to the Message Framer, which will in turn send it to the <del> next protocol.  Implementations SHOULD ensure that there is a way to pass the original data through without copying to improve performance. </del> <ins> next protocol.  To improve performance, implementations SHOULD ensure that there is a way to pass the original data through without copying. </ins> To provide an example, a simple protocol that adds a length as a header would receive the "NewSentMessage" event, create a data

If the Protocol Stack includes a transport protocol that supports multipath connectivity, the Transport Services implementation should <del> also inform the Protocol Instance of potentially new paths that </del> <ins> also inform the Protocol Instance about potentially new paths that </ins> become permissible based on the "multipath" Selection Property and the "multipath-policy" Connection Property choices made by the application.  A protocol can then establish new subflows over new

between paths, the update to the set of available paths can trigger the connection to be migrated. <del> In case of Pooled Connections pooled-connections, the Transport </del> <ins> In the case of a Pooled Connection pooled-connections, the Transport </ins> Services implementation may add connections over new paths to the pool if permissible based on the multipath policy and Selection <del> Properties.  In case a previously used path becomes unavailable, the transport system may disconnect all connections that require this path, but should not disconnect the pooled connection object exposed to the application.  The strategy to do so is implementation- specific, but should be consistent with the behavior of multipath transports. </del> <ins> Properties.  In the case that a previously used path becomes unavailable, the transport system may disconnect all connections that require this path, but should not disconnect the pooled connection object exposed to the application.  The strategy to do so is implementation-specific, but should be consistent with the behavior of multipath transports. </ins> 8.