Change:
The transport system should have a list of supported protocols available, which each have transport features reflecting the capabilities of the protocol.  Once an application specifies its <del> Transport Parameters, the transport system should match the required and prohibited properties against the transport features of the available protocols. </del> <ins> Transport Properties, the transport system matches the required and prohibited properties against the transport features of the available protocols. </ins> In the following cases, failure should be detected during pre- establishment: <del> The application requested Protocol Properties that include </del> <ins> A request by an application for Protocol Properties that include </ins> requirements or prohibitions that cannot be satisfied by any of the available protocols.  For example, if an application requires "Configure Reliability per Message", but no such protocol is <del> available on the host running the transport system, e.g., because SCTP is not supported by the operating system, this should result in an error. The application requested Protocol Properties that are in conflict with each other, i.e., the required and prohibited properties cannot be satisfied by the same protocol.  For example, if an application prohibits "Reliable Data Transfer" but then requires "Configure Reliability per Message", this mismatch should result in an error. It is important to fail as early as possible in such cases in order to avoid allocating resources, e.g., to endpoint resolution, only to find out later that there is no protocol that satisfies the requirements. </del> <ins> available on the host running the transport system this should result in an error, e.g., when SCTP is not supported by the operating system. A request by an application for Protocol Properties that are in conflict with each other, i.e., the required and prohibited properties cannot be satisfied by the same protocol.  For example, if an application prohibits "Reliable Data Transfer" but then requires "Configure Reliability per Message", this mismatch should result in an error. To avoid allocating resources, it is important that such cases fail as early as possible, e.g., to endpoint resolution, only to find out later that there is no protocol that satisfies the requirements. </ins> 3.2. The properties specified during pre-establishment have a close <del> connection to system policy.  The implementation is responsible for </del> <ins> relationship to system policy.  The implementation is responsible for </ins> combining and reconciling several different sources of preferences when establishing Connections.  These include, but are not limited to:

Discussion:
Implementation draft sec 3: "In the remainder of this document, we only refer to Selection Properties because they are the more typical case and have to be handled by all implementations. The implementation stores these objects and properties as part of the Preconnection object for use during connection establishment." I don't understand these two sentences. In the API doc it seems we use the term Transport Properties for both selection and configuration properties. Why do we only talk about selection properties in this doc? Also in the next sentence what's meant by "objects and properties"? I guess the object(s) that hold the properties? But then this is saying twice the same and we should only use one term to avoid confusion.
Also in the next section 3.1: "Once an application specifies its Transport Parameters" I guess that should be Transport Properties instead? Maybe it would also be good to say here "Once an application specifies its Transport Properties and Preference (required, prefer, ignore, avoid, prohibit - see section 5.2. of [draft-taps-arch])".
I agree; I suspect that this is ancient leftover text that should be cleaned up.
Some small changes suggested