Draft: draft-ietf-taps-interface

Commentary: should address this 
 To we need multiple local and remote candidates . Should this be represented as either : 1 ) taking two lists of objects ; or 2 ) as two objects each with multiple addresses , ports , etc . I suggest option 1 , since this makes it easier to resolve a to multiple preconnections , for NAT binding discovery . Relates to but with also different types of endpoint . 
 I like option 1 because it contains complexity . 
 See this email thread : Copy + pasting a relevant part from an email from To me at least , it was n't clear from the text that rendezvous ( ) would kick off ICE - style probing . It 's kind of obvious ( when else would it happen ? ) , but I think it would be good for the draft to spell this out . 
 modulo the do - we - want - to - bind - tightly - to - ICE question ...
Mailing list commentary: Dear all , I know way too little about rendezvous mechanisms , so I may get this completely wrong - please bear with me ! It may be that I describe an issue that ’s a non - issue . But , if I do understand this right , maybe that ’s something which needs fixing ? Ok , here it goes … Our current text in the API draft says the following : " The Rendezvous ( ) Action causes the Preconnection to listen on the Local Endpoint for an incoming Connection from the Remote Endpoint , while simultaneously trying to establish a Connection from the Local Endpoint to the Remote Endpoint . This corresponds to a TCP simultaneous open , for example . ” Now , if an application chooses unreliable data transmission , it may get SCTP with partial reliability , or it may ( in the future ) get QUIC with datagrams , or whatever … and then , the protocol may be able to do what ’s needed ( something similar to a simultaneous open ) . However , in case of UDP : Listening is quite okay , “ simultaneously trying to establish a Connection ” really means nothing - no packet will be sent . I believe that applications doing this over UDP will implement their own “ SYN”-type signal for this - but then it ’s up to the application , which , over TAPS , would need to : create a passive connection , send a Message from that same connection , i.e. using the same local address and port ( I believe ? ) - which is a matter of configuring the local endpoint , and doable if the underlying transport system can pull it off . I think there ’s nothing in our API preventing an application from doing this . If all of the above is correct , the problem that I see is that an application may ask for unreliable transmission , and then have one case in which calling “ Rendezvous ” is the right thing to do , and another case in which it is not - so it would need to be able to distinguish between these two cases : is it a protocol with Rendezvous - capability , or do I have to do it myself . Maybe , in case of UDP , the call to Rendezvous should just fail , and our text should say that Rendezvous failing would inform the application that it would have to implement it by itself , by issuing Listen and then sending a Message to the peer . Thoughts ? Am I completely off track , or is this something that needs a text fix ? Cheers ,
Paragraph (version A):
The Rendezvous() Action causes the Preconnection to listen on the
Local Endpoint for an incoming Connection from the Remote Endpoint,
while simultaneously trying to establish a Connection from the Local
Endpoint to the Remote Endpoint.  This corresponds to a TCP
simultaneous open, for example.
Paragraph (version B):
The Rendezvous() Action causes the Preconnection to listen on the
Local Endpoint for an incoming Connection from the Remote Endpoint,
while also simultaneously trying to establish a Connection from the
Local Endpoint to the Remote Endpoint.
Paragraph (version B):
If there are multiple Local Endpoints or Remote Endpoints configured,
then initiating a rendezvous action will systematically probe the
reachability of those endpoints following an approach such as that
used in Interactive Connectivity Establishment (ICE) RFC5245.
Paragraph (version B):
The Resolve() call returns a list of Preconnection Objects, that
represent the concrete addresses, local and server reflexive, on
which a Rendezvous() for the Preconnection will listen for incoming
Connections.  These resolved Preconnections will share all other
Properties with the Preconnection from which they are derived, though
some Properties may be made more-specific by the resolution process.
Paragraph (version B):
An application that uses Rendezvous() to establish a peer-to-peer
connection in the presence of NATs will configure the Preconnection
object with a Local Endpoint that supports NAT binding discovery.  It
will then Resolve() on that endpoint, and pass the resulting list of
candidate local addresses to the peer via a signalling protocol, for
example as part of an ICE RFC5245 exchange within SIP RFC3261 or
WebRTC RFC7478.  The peer will, via the same signalling channel,
return the remote endpoint candidates.  These remote endpoint
candidates are then configured on the Preconnection, allowing the
Rendezvous() Action to be initiated.