Draft: draft-ietf-taps-arch

Commentary: Fixed some upper - case / lower - case issues where I think I know the right answer . Also , a few sentences seemed incomplete or like they could be clearer . Moreover , endpoint resolution occured " in response to the Initiate call " , but " during the Rendezvous call " - I think " in response to " is better , as " during " sounds like it 's a blocking call . Alternatively , this could be " after [ the call ] " .
Paragraph (version A):
There are key differences between the architecture of the Transport
Services system and the architecture of the sockets API: the
Transport Services API is asynchronous and event-driven; it uses
messages for representing data transfer to applications, and it
assumes an implementation that can use multiple IP addresses,
multiple protocols, multiple paths, and provide multiple application
streams.
Paragraph (version B):
There are key differences between the architecture of the Transport
Services system and the architecture of the Socket API: the Transport
Services API is asynchronous and event-driven; it uses messages for
representing data transfer to applications, and it assumes an
implementation that can use multiple IP addresses, multiple
protocols, multiple paths, and provide multiple application streams.
Paragraph (version A):
It is important to note that neither the Transport Services API I-
D.ietf-taps-interface nor the Implementation document I-D.ietf-taps-
impl define new protocols or protocol capabilities that affect what
is communicated across the network: this implies that a Transport
Services system MUST be deployable on only one side of a connection.
A Transport Services system acting as a connection initiator can
communicate with any existing system that implements the transport
protocol(s) selected by the Transport Services system.  Similarly, a
Transport Services system acting as a listener can receive
connections for any protocol that is supported by the system, from
existing initiators.
Paragraph (version B):
It is important to note that neither the Transport Services API I-
D.ietf-taps-interface nor the Implementation document I-D.ietf-taps-
impl define new protocols or protocol capabilities that affect what
is communicated across the network: this implies that a Transport
Services system MUST be deployable on only one side of a connection.
A Transport Services system acting as a connection initiator can
communicate with any existing system that implements the transport
protocol(s) selected by the Transport Services system.  Similarly, a
Transport Services system acting as a listener can receive
connections for any protocol that is supported by the system from
existing initiators that implement the protocol, independent of
whether the initiator uses Transport Services as well or not.
Paragraph (version A):
Rendezvous: The action of establishing a peer-to-peer connection
with a Remote Endpoint.  It simultaneously attempts to initiate a
connection to a Remote Endpoint while listening for an incoming
connection from that endpoint.  The process of identifying options
for the connection, such as resolution of the Remote Endpoint,
occurs during the Rendezvous call.  As with Listeners, the set of
local paths and endpoints is constrained by Selection Properties.
If successful, the Rendezvous call returns a Connection object to
represent the established peer-to-peer connection.  The processes
by which connections are initiated during a Rendezvous action will
depend on the set of Local and Remote Endpoints configured on the
Preconnection.  For example, if the Local and Remote Endpoints are
TCP host candidates, then a TCP simultaneous open RFC0793 will be
performed.  However, if the set of Local Endpoints includes server
reflexive candidates, such as those provided by STUN, a Rendezvous
action will race candidates in the style of the ICE algorithm
RFC8445 to perform NAT binding discovery and initiate a peer-to-
peer connection.
Paragraph (version B):
Rendezvous: The action of establishing a peer-to-peer connection
with a Remote Endpoint.  It simultaneously attempts to initiate a
connection to a Remote Endpoint while listening for an incoming
connection from that endpoint.  The process of identifying options
for the connection, such as resolution of the Remote Endpoint,
occurs in response to the Rendezvous call.  As with Listeners, the
set of local paths and endpoints is constrained by Selection
Properties.  If successful, the Rendezvous call returns a
Connection object to represent the established peer-to-peer
connection.  The processes by which connections are initiated
during a Rendezvous action will depend on the set of Local and
Remote Endpoints configured on the Preconnection.  For example, if
the Local and Remote Endpoints are TCP host candidates, then a TCP
simultaneous open RFC0793 will be performed.  However, if the set
of Local Endpoints includes server reflexive candidates, such as
those provided by STUN, a Rendezvous action will race candidates
in the style of the ICE algorithm RFC8445 to perform NAT binding
discovery and initiate a peer-to-peer connection.
Paragraph (version A):
Connection Finished: Signals to an application that a given
Connection is no longer usable for sending or receiving Messages.
The event SHOULD deliver a reason or error to the application that
describes the nature of the termination.
Paragraph (version B):
Connection Closed: Signals to an application that a given
Connection is no longer usable for sending or receiving Messages.
The event SHOULD deliver a reason or error to the application that
describes the nature of the termination.
Paragraph (version A):
Message Sent: Notifies the application of the status of its Send
action.  This might indicate a failure if the Message cannot be
sent, or an indication that Message has been processed by the
protocol stack.
Paragraph (version B):
Message Sent: Notifies the application of the status of its Send
action.  This might indicate a failure if the Message cannot be
sent, or an indication that the Message has been processed by the
protocol stack.
Paragraph (version A):
Cached State: The state and history that the implementation keeps
for each set of associated Endpoints that have been used
previously.  This can include DNS results, TLS session state,
previous success and quality of transport protocols over certain
paths.
Paragraph (version B):
Cached State: The state and history that the implementation keeps
for each set of associated Endpoints that have been used
previously.  This can include DNS results, TLS session state,
previous success and quality of transport protocols over certain
paths, as well as other information.