Change:
identifier for itself that it uses for transport connections.  For example, a local IP address and port. <del> Path Selection Properties: The Path Selection Properties consist of the options that an application can set to influence the selection of paths between the local and remote systems.  These options can take the form of requirements, prohibitions, or preferences.  Examples of options that influence path selection include the interface type (such as a Wi-Fi Ethernet connection, or a Cellular LTE connection), characteristics of the path that are locally known like the Maximum Transmission Unit (MTU) or discovered like the Path MTU (PMTU), or predicted based on cached information like expected throughput or latency. Protocol Selection Properties: The Protocol Selection Properties consist of the options that an application can set to influence the selection of transport protocol, or to configure the behavior of generic transport protocol features.  These options can take the form of requirements, prohibitions, and preferences.  Examples include reliability, service class, multipath support, and fast open support. Specific Protocol Properties: The Specific Protocol Properties refer to the subset of Protocol Properties options that apply to a single protocol (transport protocol, IP, or security protocol). The presence of such Properties does not require that a specific protocol will be used when a Connection is established, but that if this protocol is employed, a particular set of options is to be used. </del> <ins> Selection Properties: The Selection Properties consist of the options that an application can set to influence the selection of paths between the local and remote systems, to influence the selection of transport protocol, or to configure the behavior of generic transport protocol features.  These options can take the form of requirements, prohibitions, or preferences.  Examples of options that influence path selection include the interface type (such as a Wi-Fi Ethernet connection, or a Cellular LTE connection), characteristics of the path that are locally known like the Maximum Transmission Unit (MTU) or discovered like the Path MTU (PMTU), or predicted based on cached information like expected throughput or latency.  Examples of options that influence protocol selection and configuration of transport protocol features include reliability, service class, multipath support, and fast open support. </ins> 4.1.3.

Discussion:
fixes Properties Terminology and aligns them to the API adds Properties as "Basic Object" updates Figure 2
NAME comments should be addressed now. Thanks for the reviews
Reviewing the arch doc right now which talkes about path and protocol selection properties, however, the API doc now has transport properties, connection properties, and message properties... I think we need to realign the terms here....
I admit to being slightly lost now with the naming and re-organization process... so maybe this is a left-over thing that should no longer exist... but: the API draft says "Collectively, Selection, Connection, and Message Properties can be referred to as Transport Properties." Unless I'm mistaken, this is what's needed: API draft: it seems strange how the list of selection properties (from 5.2.1 onward) appears out of nowhere. There should be a new heading, 5.3, just before what is now 5.2.1, called "Selection properties"Arch draft: with some exceptions that should perhaps be removed, the API draft doesn't really distinguish between "path" and "protocol" selection properties. Can we remove this distinction from the arch draft? Because of the availability of a protocol with certain abilities, a transport system might also make a decision about a certain path, and a path selection property might lead to a decision for a path that rules out a certain protocol... so this distinction seems to me to be a bit artificial anyway.
We converged on classifying properties into Selection, Connection, and Message Properties. If that is still true, then the architecture draft should refer to these classes of properties as well. I agree that there isn't necessarily a clear distinction between Path and Protocol Selection Properties, so we can merge them into a single class in the architecture document and just state that these properties can influence both path and protocol selection. About Transport Properties as a generic term to refer to all properties, I don't recall an extensive discussion on this, but I think it's alright (and makes more sense than what is in the API doc now, which basically uses Transport Properties as a synonym for Selection Properties).
I completely agree with NAME – don't re-iterate the whole discussion, please. We definitely need to make sure properties are consistent across all drafts. That primarily requires changes to Section 4.1.2.

What I definitely would like to see is a short Section in the Architecture explaining what Properties are and that they are our tool to expose "knobs" of the transport. I am willing to volunteer for this, but It may take until next week.
closed by 5b173e2
Thanks for doing this - and thanks NAME for the close look you're taking