Original text:
The Local Endpoint MUST be specified if the Preconnection is used to Listen() for incoming Connections, but is OPTIONAL if it is used to <del> Initiate() connections.  The Remote Endpoint MUST be specified if the </del>  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 When an implementation is asked to Listen, it registers with the system to wait for incoming traffic to the Local Endpoint.  If no <del> Local Endpoint is specified, the implementation should either use an ephemeral port or generate an error. </del>  If the Selection Properties do not require a single network interface or path, but allow the use of multiple paths, the Listener object

Reviewer comments:
Done.
Impl draft section 4.6 (Implementing listeners): "If no Local Endpoint is specified, the implementation should either use an ephemeral port or generate an error." Do we need an interface for the application to indicate that an ephemeral port should be used?
It's implicit in the old socket API - accept just gives me a new socket, which I can use to continue communication, but I don't see the port numbers associated with this socket and never have to say that they are ephermal. I believe it's similarly implicit in ours. So ... what's missing?
The text above says "use an ephemeral port or generate an error". So when would you throw an error? If the assumption is that always an ephemeral port should be used (no matter actually how the underlying interfaces works) that should be stated (in the API doc).
If you do not use an "ephemeral port", and choose to specify the port - then you may get the error if it can't be completed.
... or if the system is out of resources for some reasons. Just like "accept" can fail in the normal socket API.
That too.
NAME requested that I adapt the "error" text in the implementation draft too. In doing so, I noticed: I don't understand NAME comment above, about choosing the specify the port. I think this kind of error was possible with sockets somehow, but this text talks about not specifying a Local Endpoint. Technically, I think not specifying a Local Endpoint yet specifying a port is not possible.Regarding my own comment, any call may fail for reasons such as the system being out of resources; I think mentioning this in the text here doesn't add any value though. As a result, I'll remove the part about the error from the text in my update to PR .
This seems like what was agreed.This change is fine. You also need to adapt the implementation doc to remove the "or" part: "either use an ephemeral port or generate an error."

Revised text:
The Local Endpoint MUST be specified if the Preconnection is used to Listen() for incoming Connections, but is OPTIONAL if it is used to  <ins> Initiate() connections.  If no Local Endpoint is specified, the Transport System will assign an ephemeral local port to the Connection.  The Remote Endpoint MUST be specified if the </ins> 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 When an implementation is asked to Listen, it registers with the system to wait for incoming traffic to the Local Endpoint.  If no  <ins> Local Endpoint is specified, the implementation should use an ephemeral port. </ins> If the Selection Properties do not require a single network interface or path, but allow the use of multiple paths, the Listener object