Change:
The names and functions between these APIs are not consistent, and vary depending on the protocol being used.  For example, sending and receiving on a stream of data is conceptually the same between <del> operating on an unencrypted TCP stream and operating on an encrypted TLS stream over TCP, but applications cannot use the same socket send() and recv() calls on top of both kinds of connections. Similarly, terminology for the implementation of protocols offering transport services vary based on the context of the protocols themselves.  This variety can lead to confusion when trying to understand the similarities and differences between protocols, and how applications can use them effectively. </del> <ins> operating on an unencrypted Transmission Control Protocol (TCP) stream and operating on an encrypted Transport Layer Security (TLS) I-D.ietf-tls-tls13 stream over TCP, but applications cannot use the same socket send() and recv() calls on top of both kinds of connections.  Similarly, terminology for the implementation of protocols offering transport services vary based on the context of the protocols themselves.  This variety can lead to confusion when trying to understand the similarities and differences between protocols, and how applications can use them effectively. </ins> The goal of the Transport Services architecture is to provide a common, flexible, and reusable interface for transport protocols.  As

Discussion:
seeing no comment... :)
Sorry, looks good =) Busy week over here!
See thread at URL Suggested resolution: implementation must have a deterministic tiebreaker, current recommendation is that path properties take precedence. API should note expected behavior. There should be additional text on candidate selection and ordering.
Give example for path candidate gathering and sorting (get selection properties, get available paths in system preferred order, walk through them cancelling out the prohibited ones, and ranking preferences; get ultimate list). Do the same for protocols likely.
Added text to API and Implementation drafts on branch "conflicting-policies". API has an example, implementation still needs one. Feel free to add, otherwise I'll come back to it later today or tomorrow.
I guess that works for -00 For -01, we might want to integrate the resolution a little bit more into the decision process.
Resolved by PR
The Sec Con section contains a large number of unexpanded abbreviations. Compared to the remainder of the document this requires much more knowledge of these terms, suggest we expand them here.
The sentence reads: Beyond these, if the API for the system remains the same over time, new protocols and features may be added to the system's implementation without requiring significant changes in applications for adoption. However, this kind of suggests that some small change is needed to apps. That's not necessarilly true, and I think the key point is the converse (i.e, 3.1 below). Can I suggest: Beyond these, if the API for the system remains the same over time, new protocols and features may be added to the system's implementation without requiring changes in applications for adoption. Hi, I made this comment in the past in QUIC when discussing migration. One policy may be prefer wifi over cellular network, Second policy prefers quic cove TCP Now I walk into my house and my cellphone has HTTP over QUIC. At home will switch to wifi but quic is not supported on the wifi so will fall back to TCP. This contradicts the second policy. So two options wifi TCP or cellular QUIC , how to decide? Roni Even