Draft: draft-ietf-taps-interface

Commentary: Proposal : replace this with a way to query for a connection what the other connections in a group are ( which will only happen passively for multi streamed protocols today ) . 
 Implemented ; does this work ? 
 I 'm merging this now so I can proceed with re - structuring . It reflects what we discussed at the interim , so I do n't think there should be more concerns . 
 See the discussion in PR . I think this is best dealt with by merging PR after a small fix , then doing a separate PR to address this . IMO the easiest way to do this is to allow to query a group number ( a simple integer ) . Without grouping , every new Connection simply gets a new number . Having the same group number as any previous Connection(s ) indicates group membership . This is how we did it in NEAT too . If people agree with this , I can take care of this . 
 I remember the discussion in NEAT , to me it seems a good way to resolve the issue . 
 PR now resolves this differently . It does n't matter much , IMO the method in this PR also works fine . 
 I merged PR , which closes this issue . 
 Should ListenClone ( ) fail for non - multiplexed transports How to specify if a top - level listener can accept cloned ( multiplexed ) streams Should ListenClone ( ) be called ListenForClone ( ) ... ? 
 Just a note to say that issue waits for this issue to be addressed . 
 Rename function Trying to do this without a multiplexing transport should fail 
 ping : issue is waiting for this ... 
 Currently the " Clone " part of , e.g. , TCP ( section 10.1 ) only says : " Calling Clone on a TCP Connection creates a new Connection with equivalent parameters . The two Connections are otherwise independent . " This text should reflect that equivalent behavior must be maintained upon later Connection configuration calls . And , there should be more text in general on cloning ( see issue ) . 
 This text must refer to a new " do I want a Connection that supports initiate followed by listen ? " property . This property will be to address - so I 'll address this issue when the PR addressing has landed . 
 I 'm ok with this modulo one suggested change
Paragraph (version A):
ListenClone() creates a Listener that listens on the same
LocalEndpoint as the one the cloned Connection is using.  Any new
Connection received by this Listener will be entangled with the
cloned Connection.  Changing one of the Connection Properties on one
Connection in the group changes it for all others.  Message
Properties, however, are not entangled.  For example, changing
"Timeout for aborting Connection" (see conn-timeout) on one
Connection in a group will automatically change this Connection
Property for all Connections in the group in the same way.  However,
changing "Lifetime" (see msg-lifetime) of a Message will only affect
a single Message on a single Connection, entangled or not.
Paragraph (version B):
It is also possible to check which Connections belong to the same
Connection Group.  Calling GroupedConnections() on a specific
Connection returns a set of all Connections in the same group.
Paragraph (version B):
Connections will be in the same group if the application previously
called Clone.  Passive Connections can also be added to the same
group - e.g., when a Listener receives a new Connection that is just
a new stream of an already active multi-streaming protocol instance.
Paragraph (version B):
Changing one of the Connection Properties on one Connection in the
group changes it for all others.  Message Properties, however, are
not entangled.  For example, changing "Timeout for aborting
Connection" (see conn-timeout) on one Connection in a group will
automatically change this Connection Property for all Connections in
the group in the same way.  However, changing "Lifetime" (see msg-
lifetime) of a Message will only affect a single Message on a single
Connection, entangled or not.