Draft: draft-ietf-taps-interface

Commentary: How do framers behave in connection groups ? I.e. do all connections share one framer object or does the framer object get duplicated when a connection gets cloned ? If it does get duplicated , does it keep its current state ? This might mostly be an implementation detail but I think it should be mentioned in section 6.4 of API . 
 Interim : same type of framer is plausible default ( but new instances ) , but in general a framer should be per connection . State is not shared across connections . Bigger problem : framers are to preconnections , not connections , so how is this done with cloning ? ( perhaps : add list of framers as parameter to the clone call ) 
 I 've thought about it , and Idon't think we actually have a bigger problem here : On an initiated Connection / ConnectionGroup , the provenance of the Framers is Preconnection .  ( ) -Preconnection . Initiate ( ) . On a  , the provenance of the Framers is Preconnection .  ( ) -Preconnection . Listen ( ) -Listener . Clone ( ) . In a Rendezvous situation , there is ( unless I 'm missing something ) always a Preconnection from which a Framer can ultimately be inherited . 
 In § 8.1.2 ¶3 , the doc says : but this does n't seem to be conceptually compatible with the text at the top of § 8.1.2.1 , which says : I think the way most developers would think about this is as a pipeline : you feed data into the top - level framer with Send , which then percolates downward through the pipeline to the bottom - level framer , which then sends it to the transport . 
 I think this should be easy to address , by rephrasing : as : ... BUT " call each other " is surely a terrible way to put this , and there must be a way to say this cleanly and neatly , in line with how the code really goes . THIS , I suspect , is a very simple thing for to do , and hence I assigned it to him .
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 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 B):
Calling Clone on a Connection yields a group of Connections: the
parent Connection on which Clone was called, and a resulting cloned
Connection.  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 B):
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 A):
The Message Framer object can be added to one or more Preconnections
to run on top of transport protocols.  Multiple Framers may be added.
If multiple Framers are added, the last one added runs first when
framing outbound messages, and last when parsing inbound data.
Paragraph (version B):
The Message Framer object can be added to one or more Preconnections
to run on top of transport protocols.  Multiple Framers may be added
to a preconnection; in this case, the Framers operate as a framing
stack, i.e. the last one added runs first when framing outbound
messages, and last when parsing inbound data.
Paragraph (version B):
Since Message Framers pass from Preconnection to Listener or
Connection, addition of Framers must happen before any operation that
may result in the creation of a Connection.