Change:
The transport services API uses the Local Endpoint and Remote Endpoint Objects to refer to the endpoints of a transport connection. <del> Actions on these Objects can be used to represent various different types of endpoint identifiers, such as IP addresses, DNS names, and interface names, as well as port numbers and service names. </del> <ins> Endpoints can be created as either Remote or Local: A single Endpoint Object represents the identity of a network host. That endpoint can be more or less specific depending on which identifiers are set.  For example, an Endpoint that only specifies a hostname may in fact end up corresponding to several different IP addresses on different hosts. An Endpoint Object can be configured with the following identifiers: Hostname (string) Port (a 16-bit integer) or a Service (string) that maps to a port IP address (IPv4 or IPv6 address) Interface (string name) An Endpoint cannot have multiple identifiers of a same type set. That is, an endpoint cannot have two IP addresses specified.  Two separate IP addresses are represented as two Endpoint Objects.  If a Preconnection specifies a Remote Endpoint with a specific IP address set, it will only establish Connections to that IP address.  If, on the other hand, the Remote Endpoint specifies a hostname but no addresses, the Connection can perform name resolution and attempt using any address derived from the original hostname of the Remote Endpoint. The Transport Services API resolves names internally, when the Initiate(), Listen(), or Rendezvous() method is called to establish a Connection.  Privacy considerations for the timing of this resolution are given in privacy-security. The Resolve() action on a Preconnection can be used by the application to force early binding when required, for example with some Network Address Translator (NAT) traversal protocols (see rendezvous). 5.1.1. Specifying a multicast group address on a Local Endpoint will indicate to the transport system that the resulting connection will be used to receive multicast messages.  The Remote Endpoint can be used to filter incoming multicast from specific senders.  Such a Preconnection will only support calling Listen(), not Initiate(). The accepted Connections are receive-only. Similarly, specifying a multicast group address on the Remote Endpoint will indicate that the resulting connection will be used to send multicast messages. 5.1.2. An Endpoint can have an alternative definition when using different protocols.  For example, a server that supports both TLS/TCP and QUIC may be accessible on two different port numbers depending on which protocol is used. To support this, Endpoint Objects can specify "aliases".  An Endpoint can have multiple aliases set. In order to scope an alias to a specific transport protocol, an Endpoint can specify a protocol identifier.  These identifiers MUST only be set for aliases. The following example shows a case where "example.com" has a server running on port 443, with an alternate port of 8443 for QUIC. 5.1.3. The following examples of Endpoints show common usage patterns. </ins> Specify a Remote Endpoint using a hostname and service name:

Discussion:
NAME does the update about transport aliasing help?
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.
sec 5.1 I found it odd that there didn't appear to be any sort of formal list of attributes of an endpoint, just some examples.
Should fix with
what happened if you add multiple addresses or interfaces to an endpoint: Does it overwrite the existing one or not?
I would say that it does not overwrite but simply add to a list of addresses. This is, among other things, because for a Listen() the remote endpoint can be used to filter incoming connections and I don't think it makes much sense to only be able to constrain it to a single address.
I agree with NAME – but we should really make this explicit
Discussion at interim: Clarification is needed. add() during preconnection will overwrite, and add() cannot be used in connection state. Also add a note in the text that e.g. specifying a specific IP address might restrict mobility or use of multiple paths and could cause the connection to fails when the IP address goes way rather than enabling some handover. Still open: Do we need a way to add of multiple addresses in the first place? This is used for filtering remote IP addresses for listener for multicast.

The current API text doesn't use "add", but rather "with...": It also implies that multiple is already allowed: How does that line up with the comment about , and having that replace?
As far as I can see, in the API draft we currently have add() for Properties and Security Parameters where each new add() overwrites the value for the old one. So if we change this to add(), probably IP addresses should work the same. But can't we just allow add() with a list of IP addresses instead of just with a single IP address?
Allow adding an alias endpoint to an endpoint Any one endpoint has at most one hostname Any one endpoint has at most one port/service (if you need more, add an alias) Any one endpoint has at most one address If you need multiple source-specific multicast filters, use multiple connection objects
From NAME 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. To Rendezvous() we need multiple local and remote candidates. Should this be represented as either: Rendezvous() taking two lists of Preconnection objects; or as two Preconnection objects each with multiple addresses, ports, etc. I suggest option 1, since this makes it easier to resolve a Preconnection to multiple preconnections, for NAT binding discovery. Relates to but with also different types of endpoint.
I'm adding a point from NAME here (and closing a separate issue that he opened, because this tackles the same problem space): In the past, when I've designed transport abstraction APIs, I've always kept address family abstract, just as BSD sockets do. In this case, you've got WithIPv4Address and With IPv6Address as separate methods on the Endpoint type instead of just a single WithAddress method that takes an object of a type appropriate to the address family. Similarly, you've got WithPort as a first-class method instead of making it part of the Endpoint, as BSD sockets does with sockaddr_in. What if you want to support both TCP and QUIC, but the QUIC endpoint is on a different port? The notion of "port" is similar between the two, making the use of the same name appropriate, but it is only by convention that they often match: they are completely different spaces implemented in entirely separate codepaths in every network stack.

ICMP doesn't even have a port: what if you wanted to use that (or some other port-less protocol that, for instance, multiplexes via IPv6 host ID) with this interface.