Draft: draft-ietf-taps-interface

Commentary: 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 do n'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 ca n'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 . 
 requested that I adapt the " error " text in the implementation draft too . In doing so , I noticed : I do n't understand 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 does n'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 . "
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.  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):
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.  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 A):
When an implementation is asked to Listen, it registers with the
system to wait for incoming traffic to the Local Endpoint.  If no
Local Endpoint is specified, the implementation should either use an
ephemeral port or generate an error.
Paragraph (version B):
When an implementation is asked to Listen, it registers with the
system to wait for incoming traffic to the Local Endpoint.  If no
Local Endpoint is specified, the implementation should use an
ephemeral port.