Draft: draft-ietf-taps-interface

Commentary: I text to ConnectionReceived about this . I did n't additionally explicitly state this in the text about clone to avoid complicating things - since similarly , the text describing Initiate ( ) does n't talk about ConnectionReceived . 
 If is called , is an unsolicited event generated at the peer ? I assume so , but ca n't find it documented . 
 Do you want this to happen specifically upon calling clone ( ) , or is it good enough if it happens upon the first arrival of data on the new Connection ? The latter could be specified ( and I 'd have to check if it is n't already ) . However , in the first case , we could specify that this should happen if possible , but I do n't think it 's a behaviour that can be promised . For a multi - streaming protocol , ( ) just means " from now on , we have a new Connection , for which we 're going to use a new stream " - so I do n't think that anything 's immediately going to happen on the wire just due to clone ( ) in this case . 
 I 'd expect a event to be delivered before an event indicating arrival of data on the new connection . That could be immediately before , if there 's no explicit on - the - wire signalling that the new connection has been created . 
 Ah , ok ! I agree it should happen as you describe it , and I 'll take care of this : I 'll check if this is already covered ( and if so , if the text should be more explicit about it ) . If it is n't covered , I 'll add text to state this .
Paragraph (version A):
The ConnectionReceived Event occurs when a Remote Endpoint has
established a transport-layer connection to this Listener (for
Connection-oriented transport protocols), or when the first Message
has been received from the Remote Endpoint (for Connectionless
protocols), causing a new Connection to be created.  The resulting
Connection is contained within the ConnectionReceived Event, and is
ready to use as soon as it is passed to the application via the
event.
Paragraph (version B):
The ConnectionReceived Event occurs when a Remote Endpoint has
established or cloned (e.g., by creating a new stream in a multi-
stream transport; see groups) a transport-layer connection to this
Listener (for Connection-oriented transport protocols), or when the
first Message has been received from the Remote Endpoint (for
Connectionless protocols or streams of a multi-streaming transport),
causing a new Connection to be created.  The resulting Connection is
contained within the ConnectionReceived Event, and is ready to use as
soon as it is passed to the application via the event.
Paragraph (version A):
Calling Clone on a Connection yields a Connection Group containing
two Connections: the parent Connection on which Clone was called, and
a resulting cloned Connection.  The new Connection is actively
openend, and it will send a Ready Event or an EstablishmentError
Event.  Calling Clone on any of these Connections adds another
Connection to the Connection Group.  Connections in a Connection
Group share all Connection Properties except "connPriority" (see
conn-priority), and these Connection Properties are entangled:
Changing one of the Connection Properties on one Connection in the
Connection Group automatically changes the Connection Property for
all others.  For example, changing "connTimeout" (see conn-timeout)
on one Connection in a Connection Group will automatically make the
same change to this Connection Property for all other Connections in
the Connection Group.  Like all other Properties, "connPriority" is
copied to the new Connection when calling Clone(), but in this case,
a later change to the "connPriority" on one Connection does not
change it on the other Connections in the same Connection Group.
Paragraph (version B):
Calling Clone on a Connection yields a Connection Group containing
two Connections: the parent Connection on which Clone was called, and
a resulting cloned Connection.  The new Connection is actively
openend, and it will locally send a Ready Event or an
EstablishmentError Event.  Calling Clone on any of these Connections
adds another Connection to the Connection Group.  Connections in a
Connection Group share all Connection Properties except
"connPriority" (see conn-priority), and these Connection Properties
are entangled: Changing one of the Connection Properties on one
Connection in the Connection Group automatically changes the
Connection Property for all others.  For example, changing
"connTimeout" (see conn-timeout) on one Connection in a Connection
Group will automatically make the same change to this Connection
Property for all other Connections in the Connection Group.  Like all
other Properties, "connPriority" is copied to the new Connection when
calling Clone(), but in this case, a later change to the
"connPriority" on one Connection does not change it on the other
Connections in the same Connection Group.