Change:
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

Discussion:
During pre-establishment the application specifies the Endpoints to be used for communication as well as its preferences via Selection Properties and, if desired, also Connection Properties.  Generally, <del> Connection Properties should be configured as early as possible, as they may serve as input to decisions that are made by the implementation (the Capacity Profile may guide usage of a protocol offering scavenger-type congestion control, for example).  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 </del> <ins> Connection Properties should be configured as early as possible, because they can serve as input to decisions that are made by the implementation (e.g., the Capacity Profile can guide usage of a protocol offering scavenger-type congestion control). The implementation stores these properties as a part of the </ins> Preconnection object for use during connection establishment.  For Selection Properties that are not provided by the application, the implementation must use the default values specified in the Transport

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:

If all of the leaf nodes fail to connect during racing, i.e. none of the configurations that satisfy all requirements given in the <del> Transport Parameters actually work over the available paths, then the </del> <ins> Transport Properties actually work over the available paths, then the </ins> transport system should notify the application with an InitiateError event.  An InitiateError event should also be generated in case the transport system finds no usable candidates to race.