Draft: draft-ietf-taps-interface

Commentary: This changes the use of the term " entanglement " as discussed in , and moves some text around in this section for better clarity and less repetition . Also , addressing , it introduces a framer as an optional parameter to the Clone call . 
 I incorporated all of your suggestions , thanks ! 
 This is not fully clear from section 5.4 . , however , if connections in a group are each QUIC streams , I think it should be possible to use different framers on each stream . So it might be okay that a framers is copied when clone is called but changing a framer on one connection should not change the framer on the other connection in a group ... ? 
 Also an related editorial comment ( that could be addressed in the same PR eventually ): this section on groups only at the very end has a paragraph starting with " Note that calling Clone ( ) can result in on - the - wire signaling ... " which kind of explains that groups are supposed to be used for multistream protocol but can also be mapped to separate connection if the protocol does n't not support multiplexing of stream on one connection . I think this information should be at the very beginning of this section . 
 Actually , now looking at the framer section , I guess you would rather like to already set the new framer before you clone a connection ... ? 
 I agree with everything you say here ; about your last suggestion , maybe a framer should be an optional argument of the clone call ? 
 I do n’t actually understand the difference between a connection in a Connection Group and an “ entangled connection ” ? Both terms are used in API , but in different ways ( possibly by different authors ) - do we really really need the word “ entangled ” ? ? if we do we need , can we define and explain this . 
 I think that having the word is good as it indicates a deeper relationship than mere " grouping " . Just based on terms , I 'd ( correctly ) imagine that I can define priorities between members of a group , and that they somehow belong together ... as in : Close with a common call , etc . ... but I do n't think that I would expect , just from this term , that changing a property on one of them affects all the others . Hence the phrasing : " The connections within a group are ' entangled ' with each other " . However , I agree that in most other places , we should talk about " groups " instead . I can try to fix this . 
 Sounds good - we should add that explanation upfront in the definitions then also ? 
 [ Yes , I think so . ] EDIT : no , now I do n't think so anymore . ( see ) 
 I have addressed this in PR . Note that the text interchangeably talked about both Connections and Connection Properties as being " entangled " . I have now written this such that the term " entanglement " applies to Connection Properties only , whereas Connections in a group are , well , members of the same Connection Group . 
 Looks good to me .
Paragraph (version A):
Calling Clone on a Connection yields a group of 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.  The Connections within
a group are "entangled" with each other, and become part of a
Connection Group.  Calling Clone on any of these Connections adds
another Connection to the Connection Group, and so on.  "Entangled"
Connections share all Connection Properties except "Connection
Priority" (see conn-priority) .  Like all other Properties,
Connection Priority is copied to the new Connection when calling
Clone(), but it is not entangled: Changing Connection Priority on one
Connection does not change it on the other Connections in the same
Connection Group.
Paragraph (version A):
The stack of Message Framers associated with a Connection are also
copied to the cloned Connection when calling Clone.  In other words,
a cloned Connection has the same stack of Message Framers as the
Connection from which they are Cloned, but these Framers may
internally maintain per-Connection state.
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 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 "Connection Priority"
(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 "Timeout for aborting Connection"
(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, "Connection Priority" is copied to the new Connection
when calling Clone(), but in this case, a later change to the
"Connection Priority" on one Connection does not change it on the
other Connections in the same Connection Group.
Paragraph (version B):
Message Properties are also not entangled.  For example, changing
"Lifetime" (see msg-lifetime) of a Message will only affect a single
Message on a single Connection.
Paragraph (version B):
A new Connection created by Clone can have a Message Framer assigned
via the optional "framer" parameter of the Clone Action.  If this
parameter is not supplied, the stack of Message Framers associated
with a Connection is copied to the cloned Connection when calling
Clone.  Then, a cloned Connection has the same stack of Message
Framers as the Connection from which they are Cloned, but these
Framers may internally maintain per-Connection state.
Paragraph (version A):
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 A):
If the underlying protocol supports multi-streaming, it is natural to
use this functionality to implement Clone.  In that case, entangled
Connections are multiplexed together, giving them similar treatment
not only inside endpoints, but also across the end-to-end Internet
path.
Paragraph (version A):
Note that calling Clone() can result in on-the-wire signaling, e.g.,
to open a new connection, depending on the underlying Protocol Stack.
When Clone() leads to multiple connections being opened instead of
multi-streaming, the Transport Services system will ensure
consistency of Connection Properties by uniformly applying them to
all underlying connections in a group.  Even in such a case, there
are possibilities for a Transport Services system to implement
prioritization within a Connection Group TCP-COUPLING RFC8699.
Paragraph (version A):
The Connection Priority Connection Property operates on entangled
Connections using the same approach as in msg-priority: when
allocating available network capacity among Connections in a
Connection Group, sends on Connections with lower Priority values
will be prioritized over sends on Connections with higher Priority
values.  Capacity will be shared among these Connections according to
the Connection Group Transmission Scheduler property (conn-
scheduler).  See priority-in-taps for more.
Paragraph (version B):
If the underlying protocol supports multi-streaming, it is natural to
use this functionality to implement Clone.  In that case, Connections
in a Connection Group are multiplexed together, giving them similar
treatment not only inside endpoints, but also across the end-to-end
Internet path.
Paragraph (version B):
Note that calling Clone() can result in on-the-wire signaling, e.g.,
to open a new transport connection, depending on the underlying
Protocol Stack.  When Clone() leads to the opening of multiple such
connections, the Transport Services system will ensure consistency of
Connection Properties by uniformly applying them to all underlying
connections in a group.  Even in such a case, there are possibilities
for a Transport Services system to implement prioritization within a
Connection Group TCP-COUPLING RFC8699.
Paragraph (version B):
The "Connection Priority" Connection Property operates on Connections
in a Connection Group using the same approach as in msg-priority:
when allocating available network capacity among Connections in a
Connection Group, sends on Connections with lower Priority values
will be prioritized over sends on Connections with higher Priority
values.  Capacity will be shared among these Connections according to
the Connection Group Transmission Scheduler property (conn-
scheduler).  See priority-in-taps for more.
Paragraph (version A):
When set to true, this property will initiate new Connections using
as little cached information (such as session tickets or cookies) as
possible from previous connections that are not entangled with it.
Any state generated by this Connection will only be shared with
entangled connections.  Cloned Connections will use saved state from
within the Connection Group.  This is used for separating Connection
Contexts as specified in I-D.ietf-taps-arch.
Paragraph (version B):
When set to true, this property will initiate new Connections using
as little cached information (such as session tickets or cookies) as
possible from previous connections that are not in the same
Connection Group.  Any state generated by this Connection will only
be shared with Connections in the same Connection Group.  Cloned
Connections will use saved state from within the Connection Group.
This is used for separating Connection Contexts as specified in I-
D.ietf-taps-arch.
Paragraph (version A):
Close terminates a Connection after satisfying all the requirements
that were specified regarding the delivery of Messages that the
application has already given to the Transport Services system.  For
example, if reliable delivery was requested for a Message handed over
before calling Close, the Closed Event will signify that this Message
has indeed been delivered.  This action does not affect any other
Connection that is entangled with this one in a Connection Group.
Paragraph (version A):
Abort terminates a Connection without delivering any remaining
Messages.  This action does not affect any other Connection that is
entangled with this one in a Connection Group.
Paragraph (version A):
CloseGroup gracefully terminates a Connection and any other
Connections that are entangled with this one in a Connection Group.
For example, all of the Connections in a group might be streams of a
single session for a multistreaming protocol; closing the entire
group will close the underlying session.  See also groups.  As with
Close, any Messages remaining to be processed on a Connection will be
handled prior to closing.
Paragraph (version A):
AbortGroup terminates a Connection and any other Connections that are
entangled with this one in a Connection Group without delivering any
remaining Messages.
Paragraph (version B):
Close terminates a Connection after satisfying all the requirements
that were specified regarding the delivery of Messages that the
application has already given to the Transport Services system.  For
example, if reliable delivery was requested for a Message handed over
before calling Close, the Closed Event will signify that this Message
has indeed been delivered.  This action does not affect any other
Connection in the same Connection Group.
Paragraph (version B):
Abort terminates a Connection without delivering any remaining
Messages.  This action does not affect any other Connection that in
the same Connection Group.
Paragraph (version B):
CloseGroup gracefully terminates a Connection and any other
Connections in the same Connection Group.  For example, all of the
Connections in a group might be streams of a single session for a
multistreaming protocol; closing the entire group will close the
underlying session.  See also groups.  As with Close, any Messages
remaining to be processed on a Connection will be handled prior to
closing.
Paragraph (version B):
AbortGroup terminates a Connection and any other Connections in the
same Connection Group without delivering any remaining Messages.