Original text:
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>  The goal of the Transport Services architecture is to provide a common, flexible, and reusable interface for transport protocols.  As and functional characteristics, and it can communicate with different Remote Endpoints to optimize performance.  Beyond these, if the API for the system remains the same over time, new protocols and features <del> may be added to the system's implementation without requiring significant changes in applications for adoption. </del>  The following considerations were used in the design of this architecture. interface.  Each provided interface mimics an existing protocol- specific interface provided by supported security protocols.  For example, trust verification callbacks are common parts of TLS APIs. <del> Transport Services APIs will expose similar functionality.  Clients must take care to use security APIs appropriately.  In cases where clients use said interface to provide sensitive keying material, e.g., access to private keys or copies of pre-shared keys (PSKs), key use must be validated.  For example, clients should not use PSK material created for ESP with IETF-QUIC, and clients must not use private keys intended for server authentication as a key for client </del>  authentication.  Moreover, unlike certain transport features such as <del> TFO or ECN which can fall back to standard configurations, Transport </del>  Services systems must not permit fallback for security protocols. For example, if a client requests TLS, yet TLS or the desired version are not available, its connection must fail.  Clients are responsible

Reviewer comments:
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

Revised text:
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  <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 and functional characteristics, and it can communicate with different Remote Endpoints to optimize performance.  Beyond these, if the API for the system remains the same over time, new protocols and features  <ins> may be added to the system's implementation without requiring changes in applications for adoption. </ins> The following considerations were used in the design of this architecture. interface.  Each provided interface mimics an existing protocol- specific interface provided by supported security protocols.  For example, trust verification callbacks are common parts of TLS APIs.  <ins> Transport Services APIs will expose similar functionality. Clients must take care to use security APIs appropriately.  In cases where clients use said interface to provide sensitive keying material, e.g., access to private keys or copies of pre-shared keys (PSKs), key use must be validated.  For example, clients should not use PSK material created for the Encapsulating Security Protocol (ESP, part of IPsec) RFC4303 with QUIC, and clients must not use private keys intended for server authentication as a keys for client </ins> authentication.  Moreover, unlike certain transport features such as  <ins> TCP Fast Open (TFO) RFC7413 or Explicit Congestion Notification (ECN) RFC3168 which can fall back to standard configurations, Transport </ins> Services systems must not permit fallback for security protocols. For example, if a client requests TLS, yet TLS or the desired version are not available, its connection must fail.  Clients are responsible