Original text:
consider such a Protocol Stack to be established as soon as the Transport Services system has selected a path on which to send data. <del> However, if a peer is not reachable over the network using the connectionless protocol, or data cannot be exchanged for any other 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. </del>  4.7. Message Framers are functions that define simple transformations between application Message data and raw transport protocol data.  A <del> Framer can encapsulate or encode outbound Messages, and decapsulate or decode inbound data into Messages. </del>  While many protocols can be represented as Message Framers, for the purposes of the Transport Services API, these are ways for

Reviewer comments:
That change would have helped me understand what framers can do. It seems a bit out of sync with " A Framer can encapsulate or encode outbound Messages, and decapsulate or decode inbound data into Messages." which sounds like it'd preclude operations like processing received data (or whole messages) into connection object state without emitting a message again -- maybe that sentence could be extended along with it (if even just to include "for example" or "or modify the connection object").
NAME we've added some clarifying text in the message framer definition
Impl draft Section 4.5: Handling racing with "unconnected" protocols "In the case that the application signals that the initial Protocol Stack is failing for some reason and that another option should be attempted, the Connection can be updated to point to the next candidate Protocol Stack. This can be viewed as an application-driven form of Protocol Stack racing." How does the application indicate that? I don't think this is covered by the API draft? Also I would recommend to move this section as a subsection within 4.5. (Completing Establishment) or at least switch the order with the previous section (Establishing multiplexed connections) to get a better reading flow.
This may affect the API draft so we should conclude if the API draft needs to be updated. We do have the functionality in NEAT for racing with unconnected protocols so i think the text is based on that.
Change this to text about how a framer can be used to drive racing over UDP. We shouldn't have a special API for marking the current connection failed.
Action is to propose initial text and follow up at next interim.

Revised text:
consider such a Protocol Stack to be established as soon as the Transport Services system has selected a path on which to send data.  <ins> However, this can cause a problem if a specific peer is not reachable over the network using the connectionless protocol, or data cannot be exchanged with the peer for any other reason.  To mitigate this, an application can use a Message Framer message-framers on top of a connectionless protocol to only mark a specific connection attempt as ready when some data has been received, or after some application- level handshake has been performed. </ins> 4.7. Message Framers are functions that define simple transformations between application Message data and raw transport protocol data.  A  <ins> Framer can encapsulate or encode outbound Messages, decapsulate or decode inbound data into Messages, and implement parts of protocols that do not directly map to application Messages (such as protocol handshakes or preludes before Message exchange). </ins> While many protocols can be represented as Message Framers, for the purposes of the Transport Services API, these are ways for