Change:
(connection-props), and the security parameters (see security- parameters): <del> 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. </del> <ins> 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. 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(). 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. 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. </ins> Transport Properties MUST always be specified while security parameters are OPTIONAL.

Discussion:
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 added to an endpoint. NAME what's the rationale for the change in ?
I remember having multiple addresses on an endpoint would also benefit multicast.
NAME the explanation for how multicast is handled didn't change at all here, btw.
NAME 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.