Draft: draft-ietf-taps-interface

Commentary: The call needs multiple local and remote candidate endpoints . This means should take lists of and objects ( section 5 ) and there should be ways of adding / removing and objects from a Relates to 
 Pairs of ? Local and remote endpoints probably need to be linked . 
 updates the description of to say : That 's fine , but it prevents a single being used in when there are multiple candidates . For to work , we need to relax this restriction and allow multiple addresses of the same type to be to an endpoint . what 's the rationale for the change in ? 
 I remember having multiple addresses on an endpoint would also benefit multicast . 
 the explanation for how multicast is handled did n't change at all here , btw . 
 I think it would make most sense to either : Use the alias approach , where one endpoint can have a list of aliases that are equivalent options , or Let the preconnection have multiple endpoint objects for rendezvous The definition of a single endpoint object is a lot easier to keep track of and understand if it is a single address or equivalent identifier .
Paragraph (version A):
The Local Endpoint MUST be specified if the Preconnection is used to
Listen() for incoming Connections, but is OPTIONAL if it is used to
Initiate() connections.  If no Local Endpoint is specified, the
Transport System will assign an ephemeral local port to the
Connection on the appropriate interface(s).  The Remote Endpoint MUST
be specified if the Preconnection is used to Initiate() Connections,
but is OPTIONAL if it is used to Listen() for incoming Connections.
The Local Endpoint and the Remote Endpoint MUST both be specified if
a peer-to-peer Rendezvous is to occur based on the Preconnection.
Paragraph (version B):
At least one Local Endpoint MUST be specified if the Preconnection is
used to Listen() for incoming Connections, but the list of Local
Endpoints MAY be empty if the Preconnection is used to Initiate()
connections.  If no Local Endpoint is specified, the Transport System
will assign an ephemeral local port to the Connection on the
appropriate interface(s).  At least one Remote Endpoint MUST be
specified if the Preconnection is used to Initiate() Connections, but
the list of Remote Endpoints MAY be empty if the Preconnection is
used to Listen() for incoming Connections.  At least one Local
Endpoint and one Remote Endpoint MUST be specified if a peer-to-peer
Rendezvous is to occur based on the Preconnection.
Paragraph (version B):
If more than one Local Endpoint is specified on a Preconnection, then
all the Local Endpoints on the Preconnection MUST represent the same
host.  For example, they might correspond to different interfaces on
a multi-homed host, of they might correspond to local interfaces and
a STUN server that can be resolved to a server reflexive address for
a Preconnection used to make a peer-to-peer Rendezvous().
Paragraph (version B):
If more than one Remote Endpoint is specified on the Preconnection,
then all the Remote Endpoints on the Preconnection SHOULD represent
the same host.  For example, the Remote Endpoints might represent
various network interfaces of a host, or a server reflexive address
that can be used to reach a host, or a set of hosts that provide
equivalent local balanced service.
Paragraph (version B):
In most cases, it is expected that a single Remote Endpoint will be
specified by name, and a later call to Initiate() on the
Preconnection (see initiate) will internally resolve that name to a
list of concrete endpoints.  Specifying multiple Remote Endpoints on
a Preconnection allows applications to override this for more
detailed control.