Draft: draft-ietf-taps-arch

Commentary: Satisfies , including text for both generic protocol equivalence and security protocols . We may want to move the section around organizationally later , as per some of  's comments on structure . However , I reference terms from our concept definitions , so it is easier to write in the latter portion of the document . 
 And add a subsection specifically for security protocols . Determining what security protocols ( and configurations ) are equivalent is nontrivial and incredibly important if we are to race , e.g. , TLS and gQUIC . 
 I think the racing / gathering section needs a tiny little explanation text and this seems reasonable to add - if you add to this section , can you also make sure it mentions something of the terms " policy " and " cached state " as a part of this update ? 
 yes , will do ! 
 Addressed by . 
 tiny editorial nits on section refs otherwise this is good to goLGTM !
Paragraph (version B):
The Transport Services architecture defines a mechanism that allows
applications to easily use different network paths and Protocol
Stacks.  Transitioning between different Protocol Stacks may in some
cases be controlled by properties that only change when application
code is updated.  For example, an application may enable the use of a
multipath or multistreaming transport protocol by modifying the
properties in its Pre-Connection configuration.  In some cases,
however, the Transport Services system will be able to automatically
change Protocol Stacks without an update to the application, either
by selecting a new stack entirely, or racing multiple candidate
Protocol Stacks during connection establishment.  This functionality
can be a powerful driver of new protocol adoption, but must be
constrained carefully to avoid unexpected behavior that can lead to
functional or security problems.
Paragraph (version B):
Both stacks must offer the same interface to the application for
connection establishment and data transmission.  For example, if
one Protocol Stack has UDP as the top-level interface to the
application, then it is not equivalent to a Protocol Stack that
runs TCP as the top-level interface.  Among other differences, the
UDP stack would allow an application to read out message
boundaries based on datagrams sent from the Remote Endpoint,
whereas TCP does not preserve message boundaries on its own.
Paragraph (version B):
Both stacks must offer the same transport services, as required by
the application.  For example, if an application specifies that it
requires reliable transmission of data, then a Protocol Stack
using UDP without any reliability layer on top would not be
allowed to replace a Protocol Stack using TCP.  However, if the
application does not require reliability, then a Protocol Stack
that adds unnecessary reliability might be allowed as an
equivalent Protocol Stack as long as it does not conflict with any
other application-requested properties.
Paragraph (version B):
Both stacks must offer the same security properties.  See the
security protocol equivalence section below for futher discussion
(security-equivalence).
Paragraph (version B):
The inclusion of transport security protocols I-D.ietf-taps-
transport-security in a Protocol Stack adds extra restrictions to
Protocol Stack equivalence.  Security features and properties, such
as cryptographic algorithms, peer authentication, and identity
privacy vary across security protocols, and across versions of
security protocols.  Protocol equivalence should not be assumed for
different protocols or protocol versions, even if they offer similar
application configuration options.
Paragraph (version B):
To ensure that security protocols are not incorrectly swapped,
Transport Services systems should only automatically generate
equivalent Protocol Stacks when the transport security protocols
within the stacks are identical.  Specifically, a system should
consider protocols identical only if they are of the same type and
version.  For example, the same version of TLS running over two
different transport protocol stacks may be considered equivalent,
whereas TLS 1.2 and TLS 1.3 I-D.ietf-tls-tls13 should not be
considered equivalent.