Draft: draft-ietf-taps-arch

Commentary: In the architecture document , I think Section 4.2.3 Protocol Stack Equivalence could be misinterpreted to mean connection migration , i.e. , changing network paths or protocol stacks during the lifetime of a single Connection . " The Transport Services architecture defines a mechanism that allows applications to easily use different network paths and Protocol Stacks . In some cases , changing which Protocol Stacks or network paths are used will require updating the preferences expressed by the application that uses the Transport Services system . " It says " use different network paths and Protocol Stacks " and talks about changing these , but it does not say in what context or over what timeframe . Maybe here it would help to say something like " The Transport Services architecture defines a mechanism that allows applications to easily use different network paths and Protocol Stacks for their Connections or start using new protocols as they get implemented , without requiring major changes to the applications " . 
 Agreed , sounds good 
 I do n't think there 's any particular reason a future transport should n't renegotiate paths and stack components on the fly ( but then again I think the future of the Internet will see endpoints using TLS / TCP / IPv4 only to establish cryptographic and routing state , then dynamically negotiating connectivity beyond that , i.e. " legacy Internet as a bootstrap protocol alone " so my opinion should probably be regarded as a minority one and best ignored . :) ) 
 +1 to  but I guess I was sharing an office with him for too long ;-) 
 So ... This is a case where I would n't wish to speculate . It was controversial in the lead - up to TAPS for various reasons , and I 'd really encourage we do not start thinking in this RFC about how that may turn in future . I do like Theresa 's new para above . I would argue not to add more . 
 Thanks for fixing !
Paragraph (version A):
The Transport Services architecture defines a mechanism that allows
applications to easily use different network paths and Protocol
Stacks.  In some cases, changing which Protocol Stacks or network
paths are used will require updating the preferences expressed by the
application that uses the Transport Services system.  For example, an
application can 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 by racing multiple candidate Protocol Stacks during connection
establishment.  This functionality in the API can be a powerful
driver of new protocol adoption, but needs to be constrained
carefully to avoid unexpected behavior that can lead to functional or
security problems.
Paragraph (version B):
The Transport Services architecture defines a mechanism that allows
applications to easily make use of various network paths and Protocol
Stacks without requiring major changes in application logic.  In some
cases, changing which Protocol Stacks or network paths are used will
require updating the preferences expressed by the application that
uses the Transport Services system.  For example, an application can
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 by racing
multiple candidate Protocol Stacks during connection establishment.
This functionality in the API can be a powerful driver of new
protocol adoption, but needs to be constrained carefully to avoid
unexpected behavior that can lead to functional or security problems.