Draft: draft-ietf-taps-impl

Commentary: I 'm having difficult parsing " At this point , any constraints or requirements the application may have on the connection are available from pre - establishment . " I 'm not even sure what meaning is intended . Available ? To what and for what ? Is this really a forest ? I.e. , is a possible when , for instance , you have a choice of two hostnames ? If so , there should be an example illustrating that . The last example in the section should be augmented to show multiple hostnames as described by the preceding paragraph . Additionally , I think stating that there is a clear / natural dependency relationship between branching operations such that later operations depend on earlier decisions could simplify and clarify the justification for the suggested order of operations . " Scavenger " implies LEDBAT to me : it will take whatever is currently not being used but will defer to everything else . I 'm not sure that notion aligns with the preference described . Is the intent of : that a protocol higher in the stack ( or a framer ? ) could use 0 - RTT even if the application does n't want 0 - RTT ? Are there any security or privacy implications to this ? Should there be a mechanism to disable this entirely ? I do not understand the syntax employed here . Is in : a global object or something ? It appears to be generating a Start event with the Connection object to the system , but is n't the framer the receiver of such an event ? ( Nit : is n't Event < with angle brackets the syntax here ? ) does n't seem quite right . Protocols possess a property of application - layer data unit , usually as an intrinsic property that is a direct consequence of the protocol design . They do n't really define it so much as end up with it . Maybe this is too much of a nit , but it reads weirdly . The use of " unconnected " ( or " connectionless " ) directly adjacent to the phrase " UDP connections " is driving me batty . I understand that the TAPS interface provides only a Connection object , but we should not ever use lowercase - c " connection " to refer to UDP , and be clear when we mean the uppercase - C " Connection " object in relation to an underlying UDP transport . 
 I rust just read this as " The Implementation now has all constrains it needs to know for attempting to establish a connection in the form of Preconnection parameters ( endpoints , security parameters and transport properties ) and can now continue . " I would imagine that if 0 - RTT is set to prohibit that applies to the entire stack ( including framers ) . This is a bit confusing , but basically , as far as I understand , there is the  which is part of the TAPS Implementation ( this creates the events and has the methods MakeConnectionReady , MakeConnectionClosed etc . ) and there is the framer implementation ( which is the part the users of the TAPS implementation write themselves , this receives the events and then calls the methods on the  ) . It might be good to find another term for  to make that difference more clear . 
 WFM
Paragraph (version A):
The process of establishing a network connection begins when an
application expresses intent to communicate with a Remote Endpoint by
calling Initiate.  (At this point, any constraints or requirements
the application may have on the connection are available from pre-
establishment.)  The process can be considered complete once there is
at least one Protocol Stack that has completed any required setup to
the point that it can transmit and receive the application's data.
Paragraph (version B):
The process of establishing a network connection begins when an
application expresses intent to communicate with a Remote Endpoint by
calling Initiate, at which point the Preconnection object contains
all constraints or requirements the application has configured for
the connection.  The establishment process can be considered complete
once there is at least one Protocol Stack that has completed any
required setup to the point that it can transmit and receive the
application's data.
Paragraph (version A):
It is also possible that Protocol Stacks within a particular leaf
node use 0-RTT handshakes without any safely replayable application
data.  For example, TCP Fast Open could use a Client Hello from TLS
as its 0-RTT data, shortening the cumulative handshake time.
Paragraph (version B):
It is also possible for Protocol Stacks within a particular leaf node
to use 0-RTT handshakes without any safely replayable application
data if a protocol in the stack has idempotent handshake data to
send.  For example, TCP Fast Open could use a Client Hello from TLS
as its 0-RTT data, shortening the cumulative handshake time.