Arch: 4.2.3 could be misinterpreted as connection migration

[theri]

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".

[tfpauly]

Agreed, sounds good

[britram]

I don't think there's any particular reason a future transport shouldn'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. :) )

[mirjak]

+1 to Brian but I guess I was sharing an office with him for too long ;-)

[gorryfair]

So... This is a case where I wouldn'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.

[theri]

Thanks for fixing!