Draft: draft-ietf-taps-impl

Commentary: Throughout the document , the term " protocol " is used in lots of different ways . In some cases , it clearly refers to the underlying transport . In other places , it refers to the top - level protocol that the application directly interacts with . In yet other places , it seems to refer to the whole protocol stack , sometimes including the framers . I feel like the document would benefit from a scrub of these usages , and maybe even a glossary describing what exactly is meant by these terms . 
 Use Protocol Stack and Protocol Instance from section 4.2 of  ; I 'll do this on my review pass . 
 Taking Protocol Stack to mean a whole stack of Instances , Protocol Instance to be a single protocol with an instantiated Stack , and Protocol to mean the protocol without referring to a specific instance within a Connection , then the state of the document after is semantically correct , if a little ugly , in my estimation . I 'd suggest s / Protocol Stack / protocol stack/ everywhere , though . I do n't thing the Very Important Casing makes the document readable or clears up any terminological confusion about what a protocol stack is .
Paragraph (version A):
The Transport Services architecture I-D.ietf-taps-arch defines a
system that allows applications to flexibly use transport networking
protocols.  The API that such a system exposes to applications is
defined as the Transport Services API I-D.ietf-taps-interface.  This
API is designed to be generic across multiple transport protocols and
sets of protocols features.
Paragraph (version B):
The Transport Services architecture I-D.ietf-taps-arch defines a
system that allows applications to flexibly use transport networking
protocols.  The API that such a system exposes to applications is
defined as the Transport Services API I-D.ietf-taps-interface.  This
API is designed to be generic across multiple transport protocols and
sets of protocol features.
Paragraph (version A):
Once the Connection is established, Transport Services implementation
maps actions and events to the details of the chosen Protocol Stack.
For example, the same Connection object may ultimately represent a
single instance of one transport protocol (e.g., a TCP connection, a
TLS session over TCP, a UDP flow with fully-specified Local and
Remote Endpoints, a DTLS session, a SCTP stream, a QUIC stream, or an
HTTP/2 stream).  The properties held by a Connection or Listener is
independent of other connections that are not part of the same
Connection Group.
Paragraph (version B):
Once the Connection is established, Transport Services implementation
maps actions and events to the details of the chosen Protocol Stack.
For example, the same Connection object may ultimately represent a
single transport protocol instance (e.g., a TCP connection, a TLS
session over TCP, a UDP flow with fully-specified Local and Remote
Endpoints, a DTLS session, a SCTP stream, a QUIC stream, or an HTTP/2
stream).  The properties held by a Connection or Listener is
independent of other connections that are not part of the same
Connection Group.
Paragraph (version A):
A request by an application for Protocol Properties that cannot be
satisfied by any of the available protocols.  For example, if an
application requires "Configure Reliability per Message", but no
such feature is available in any protocol the host running the
transport system on the host running the transport system this
should result in an error, e.g., when SCTP is not supported by the
operating system.
Paragraph (version B):
A request by an application for Protocol Properties that cannot be
satisfied by any of the available protocols.  For example, if an
application requires "Configure Reliability per Message", but no
such feature is available in any protocol on the host running the
transport system this should result in an error, e.g., when SCTP
is not supported by the operating system.
Paragraph (version A):
Once the application has provided its 0-RTT data, a Transport
Services implementation should keep a copy of this data and provide
it to each new leaf node that is started and for which a 0-RTT
protocol is being used.
Paragraph (version B):
Once the application has provided its 0-RTT data, a Transport
Services implementation should keep a copy of this data and provide
it to each new leaf node that is started and for which a protocol
instance supporting 0-RTT is being used.