Draft: draft-ietf-taps-impl

Commentary: 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
Paragraph (version A):
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.
Paragraph (version B):
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).
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
If a leaf node has successfully completed its connection, all other
attempts should be made ineligible for use by the application for the
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
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.
Paragraph (version B):
If a leaf node has successfully completed its connection, all other
attempts should be made ineligible for use by the application for the
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
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.
Paragraph (version A):
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.
Paragraph (version B):
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.
Paragraph (version A):
While many protocols can be represented as Message Framers, for the
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
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.
Paragraph (version B):
While many protocols can be represented as Message Framers, for the
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
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.
Paragraph (version A):
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
next protocol.  Implementations SHOULD ensure that there is a way to
pass the original data through without copying to improve
performance.
Paragraph (version B):
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
next protocol.  To improve performance, implementations SHOULD ensure
that there is a way to pass the original data through without
copying.
Paragraph (version A):
In case of Pooled Connections pooled-connections, the Transport
Services implementation may add connections over new paths to the
pool if permissible based on the multipath policy and Selection
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.
Paragraph (version B):
In the case of a Pooled Connection pooled-connections, the Transport
Services implementation may add connections over new paths to the
pool if permissible based on the multipath policy and Selection
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.