Draft: draft-ietf-taps-impl

Commentary: 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 " ) . 
 we 've 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   is failing for some reason and that another option should be attempted , the Connection can be updated to point to the next candidate   . This can be viewed as an application - driven form of Protocol Stack racing . " How does the application indicate that ? I do n'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 should n't have a special API for marking the current connection failed . 
 Action is to propose initial text and follow up at next interim .
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
Message Framers are functions that define simple transformations
between application Message data and raw transport protocol data.  A
Framer can encapsulate or encode outbound Messages, and decapsulate
or decode inbound data into Messages.
Paragraph (version B):
Message Framers are functions that define simple transformations
between application Message data and raw transport protocol data.  A
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).