Draft: draft-ietf-taps-interface

Commentary: In § 6.3 we have : This does n't work , because takes only a single . The action on a should rather be on a or .
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.
Paragraph (version A):
The Rendezvous() Action causes the Preconnection to listen on the
Local Endpoint for an incoming Connection from the Remote Endpoint,
while also simultaneously trying to establish a Connection from the
Local Endpoint to the Remote Endpoint.
Paragraph (version A):
If there are multiple Local Endpoints or Remote Endpoints configured,
then initiating a rendezvous action will systematically probe the
reachability of those endpoints following an approach such as that
used in Interactive Connectivity Establishment (ICE) RFC5245.
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.  These resolved Preconnections will share all other
Properties with the Preconnection from which they are derived, though
some Properties may be made more-specific by the resolution process.
Paragraph (version A):
An application that uses Rendezvous() to establish a peer-to-peer
connection in the presence of NATs will configure the Preconnection
object with a Local Endpoint that supports NAT binding discovery.  It
will then Resolve() on that endpoint, and pass the resulting list of
candidate local addresses to the peer via a signalling protocol, for
example as part of an ICE RFC5245 exchange within SIP RFC3261 or
WebRTC RFC7478.  The peer will, via the same signalling channel,
return the remote endpoint candidates.  These remote endpoint
candidates are then configured on the Preconnection, allowing the
Rendezvous() Action to be initiated.
Paragraph (version A):
The Rendezvous() Action returns a Connection object.  Once
Rendezvous() has been called, any changes to the Preconnection MUST
NOT have any effect on the Connection.  However, the Preconnection
can be reused, e.g., for Rendezvous of another Connection.
Paragraph (version B):
A Preconnection Object used in a Rendezvous() MUST have both the
Local Endpoint candidates and the Remote Endpoint candidates
specified, along with the transport properties and security
parameters needed for Protocol Stack selection, before the
Rendezvous() Action is initiated.
Paragraph (version B):
The Rendezvous() Action listens on the Local Endpoint candidates for
an incoming Connection from the Remote Endpoint candidates, while
also simultaneously trying to establish a Connection from the Local
Endpoint candidates to the Remote Endpoint candidates.
Paragraph (version B):
If there are multiple Local Endpoints or Remote Endpoints configured,
then initiating a Rendezvous() action will systematically probe the
reachability of those endpoint candidates following an approach such
as that used in Interactive Connectivity Establishment (ICE) RFC5245.
Paragraph (version B):
The Resolve() call returns lists of Local Endpoints and Remote
Endpoints, that represent the concrete addresses, local and server
reflexive, on which a Rendezvous() for the Preconnection will listen
for incoming Connections, and to which it will attempt to establish
connections.
Paragraph (version B):
The Rendezvous() Action can be initiated once both the Local Endpoint
candidates and the Remote Endpoint candidates retrieved from the peer
via the signalling channel have been added to the Preconnection.
Paragraph (version A):
The RendezvousDone<> Event occurs when a Connection is established
with the Remote Endpoint.  For Connection-oriented transports, this
occurs when the transport-layer connection is established; for
Connectionless transports, it occurs when the first Message is
received from the Remote Endpoint.  The resulting Connection is
contained within the RendezvousDone<> Event, and is ready to use as
soon as it is passed to the application via the Event.
Paragraph (version A):
An EstablishmentError occurs either when the Properties and Security
Parameters of the Preconnection cannot be fulfilled for rendezvous or
cannot be reconciled with the Local and/or Remote Endpoints, when the
Local Endpoint or Remote Endpoint cannot be resolved, when no
transport-layer connection can be established to the Remote Endpoint,
or when the application is prohibited from rendezvous by policy.
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.  These resolved Preconnections will share all other
Properties with the Preconnection from which they are derived, though
some Properties may be made more-specific by the resolution process.
This list can be passed to a peer via a signalling protocol, such as
SIP RFC3261 or WebRTC RFC7478, to configure the remote endpoint.
Paragraph (version B):
The RendezvousDone<> Event occurs when a Connection is established
with the Remote Endpoint.  For Connection-oriented transports, this
occurs when the transport-layer connection is established; for
Connectionless transports, it occurs when the first Message is
received from the Remote Endpoint.  The resulting Connection is
contained within the RendezvousDone<> Event, and is ready to use as
soon as it is passed to the application via the Event.  Changes made
to a Preconnection after Rendezvous() has been called do not have any
effect on existing Connections.