Draft: draft-ietf-taps-interface

Commentary: quickly adding this to fix nits before -01 submission 
 Text : Internally , the transport system will first exclude all protocols and paths that match a Prohibit , then only keep candidates that match a Require , then sort candidates according to Preferred properties , and then use Avoided properties as a tiebreaker . does not read correct for me ... I understand excluding prohibit , but the action on require seems wrong . I expected to remove candidates with prohibit and remove candidates that do NOT have require . What is written is different . — - I would prefer a para break before : The Rendezvous ( ) Action causes the to show the change of topic . — Refs needed : SIP or WebRTC — maximum Message size should this be capitalised ? What is maxlen ? The same value ? Of different ? — - I could not finally understand what is intended by this text ; The exact disposition of the Message when the Sent Event occurs is specific to the implementation and the constraints on the Protocol Stacks implied by the Connection 's Transport Properties .
Paragraph (version A):
Internally, the transport system will first exclude all protocols and
paths that match a Prohibit, then only keep candidates that match a
Require, then sort candidates according to Preferred properties, and
then use Avoided properties as a tiebreaker.  In case of conflicts
between Protocol and Path Selection Properties, Path Selection
Properties take precedence.  For example, if an application indicates
a preference for a specific path, but also a preference for a
protocol not available on this path, the transport system will try
the path first, so the Protocol Selection Property might not have an
effect.
Paragraph (version B):
Internally, the transport system will first exclude all protocols and
paths that match a Prohibit, then exclude all protocols and paths
that do not match a Require, then sort candidates according to
Preferred properties, and then use Avoided properties as a
tiebreaker.  In case of conflicts between Protocol and Path Selection
Properties, Path Selection Properties take precedence.  For example,
if an application indicates a preference for a specific path, but
also a preference for a protocol not available on this path, the
transport system will try the path first, so the Protocol Selection
Property might not have an effect.
Paragraph (version A):
The Preconnection Object must be specified with both a Local Endpoint
and a Remote Endpoint, and also the transport properties and security
parameters needed for Protocol Stack selection.  The Rendezvous()
Action causes the Preconnection to listen on the Local Endpoint for
an incoming Connection from the Remote Endpoint, while simultaneously
trying to establish a Connection from the Local Endpoint to the
Remote Endpoint.  This corresponds to a TCP simultaneous open, for
example.
Paragraph (version B):
The Preconnection Object must be specified with both a Local Endpoint
and a Remote Endpoint, and also the transport properties and security
parameters needed for Protocol Stack selection.
Paragraph (version B):
The Rendezvous() Action causes the Preconnection to listen on the
Local Endpoint for an incoming Connection from the Remote Endpoint,
while simultaneously trying to establish a Connection from the Local
Endpoint to the Remote Endpoint.  This corresponds to a TCP
simultaneous open, for example.
Paragraph (version A):
The Resolve() call returns a list of Preconnection Objects, that
represent the concrete addresses, local and server reflexive, on
which a Rendezvous() for the Preconnection will listen for incoming
Connections.  This list can be passed to a peer via a signalling
protocol, such as SIP or WebRTC, to configure the remote.
Paragraph (version B):
The Resolve() call returns a list of Preconnection Objects, that
represent the concrete addresses, local and server reflexive, on
which a Rendezvous() for the Preconnection will listen for incoming
Connections.  This list can be passed to a peer via a signalling
protocol, such as SIP RFC3261 or WebRTC RFC7478, to configure the
remote.
Paragraph (version A):
The Sent Event occurs when a previous Send Action has completed,
i.e., when the data derived from the Message has been passed down or
through the underlying Protocol Stack and is no longer the
responsibility of the implementation of this interface.  The exact
disposition of the Message when the Sent Event occurs is specific to
the implementation and the constraints on the Protocol Stacks implied
by the Connection's Transport Properties.  The Sent Event contains an
implementation-specific reference to the Message to which it applies.
Paragraph (version B):
The Sent Event occurs when a previous Send Action has completed,
i.e., when the data derived from the Message has been passed down or
through the underlying Protocol Stack and is no longer the
responsibility of the implementation of this interface.  The exact
disposition of the Message (i.e., whether it has actually been
transmitted, moved into a buffer on the network interface, moved into
a kernel buffer, and so on) when the Sent Event occurs is
implementation-specific.  The Sent Event contains an implementation-
specific reference to the Message to which it applies.