Draft: draft-ietf-taps-interface

Commentary: I realise I 'm late reviewing this , but this approach seems pretty cumbersome . Why do we need two connections , once send only and one receive only , rather than a single bidirectional connection ? It also seems cumbersome to implement : both objects will be bound to the same port , and so will receive the multicast packets once the group has been joined . The send - only must then filter out those received packets ? 
 In the multicast endpoint section , we should have explicit examples for patterns of ASM and SSM . Listen(multicast address , port , interface ) Get a connection from a specific remote endpoint Initiate a connection back to talk to that endpoint , etc 
 We should mention the IGMP joining in Implementation , etc too 
 If we have n't done so , should note than one process may receive from the same address with SO_REUSEADDR so that every incoming multicast or broadcast UDP datagram destined to the shared port is delivered to all . 
 I think the other bits about reuse address belong in implementation , filed 
 See my comment on – this approach seems cumbersome 
 For SSM , -send only , -receive only , makes sense . But for ASM , I 'm increasingly thinking that we also want -multicast peer that can both send and receive on a single local port : you want sender and receiver to be bound to the same local address / port pair . 
 I feel uncomfortable here . I have been persuaded we should add ASM Multicast . I suggest try a PR and see if this is simple and helpful ? 
 Interim : waiting on 
 CSP to propose a PR to see if this needs to be taken in a different direction .
Paragraph (version A):
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.
Paragraph (version A):
Similarly, specifying a multicast group address on the Remote
Endpoint will indicate that the resulting connection will be used to
send multicast messages, and that the Preconnection will support
Initiate() but not Listen().  The Connection created this way is
send-only.
Paragraph (version B):
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().
Calling Listen() will cause the Transport Services system to register
for receiving multicast, such as issuing an IGMP join RFC3376 or
using MLDv2 for IPV6 RFC4604.  Any Connections that are accepted from
this Listener are receive-only.
Paragraph (version B):
Similarly, specifying a multicast group address on the Remote
Endpoint will indicate that the resulting connection will be used to
send multicast messages, and that the Preconnection will support
Initiate() but not Listen().  Any Connections created this way are
send-only.
Paragraph (version B):
See multicast-examples for more examples.
Paragraph (version B):
One common pattern for multicast is to both send and receive
multicast.  For such cases, an application can set up both a Listener
and a Connection.  The Listener is only used to accept Connections
that receive inbound multicast.  The initiated Connection is only
used to send multicast.