Draft: draft-ietf-taps-impl

Commentary: This provides more detail on how to implement Clone with TCP , and clarifies that SCTP 's " Initiate " should not yield a stream of an already existing SCTP Association in case " activeReadBeforeSend " is Preferred or Required . 
 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 . 
 Added a question for
Paragraph (version A):
Calling "Clone" on a TCP Connection creates a new Connection with
equivalent parameters.  The two Connections are otherwise
independent.
Paragraph (version B):
Calling "Clone" on a TCP Connection creates a new Connection with
equivalent parameters.  These Connections, and Connections
generated via later calls to "Clone" on one of them, form a
Connection Group.  To realize "entanglement" for these
Connections, with the exception of "Connection Priority", changing
a Connection Property on one of them must affect the Connection
Properties of the others too.  No guarantees of honoring the
Connection Property "Connection Priority" are given, and thus it
is safe for an implementation of a transport system to ignore this
property.  When it is reasonable to assume that Connections
traverse the same path (e.g., when they share the same
encapsulation), support for it can also experimentally be
implemented using a congestion control coupling mechanism (see for
example TCP-COUPLING or RFC3124).
Paragraph (version A):
If this is the only Connection object that is assigned to the SCTP
association or stream mapping has not been negotiated,
CONNECT.SCTP is called.  Else, a new stream is used: if there are
enough streams available, "Initiate" is just a local operation
that assigns a new stream number to the Connection object.  The
number of streams is negotiated as a parameter of the prior
CONNECT.SCTP call, and it represents a trade-off between local
resource usage and the number of Connection objects that can be
mapped without requiring a reconfiguration signal.  When running
out of streams, ADD_STREAM.SCTP must be called.
Paragraph (version B):
If this is the only Connection object that is assigned to the SCTP
association or stream mapping has not been negotiated,
CONNECT.SCTP is called.  Else, unless the Selection Property
"activeReadBeforeSend" is Preferred or Required, a new stream is
used: if there are enough streams available, "Initiate" is just a
local operation that assigns a new stream number to the Connection
object.  The number of streams is negotiated as a parameter of the
prior CONNECT.SCTP call, and it represents a trade-off between
local resource usage and the number of Connection objects that can
be mapped without requiring a reconfiguration signal.  When
running out of streams, ADD_STREAM.SCTP must be called.