Change:
Connection objects.  It is created from a Preconnection object that specifies the type of incoming connections it will accept. <ins> Transport Properties: Transport Properties allow the application to configure the Transport System and express their requirements, prohibitions, and preferences.  There are three kinds of Transport Properties: Selection Properties are used influence connection establishment. Connection Properties are used to configure the protocol instance and control per-connection behavior of the Transport System. Message Properties are used to configure per-message control per-connection behavior of the Transport System. Connection and Message Properties can also be specified prior establishment.  If done so, they are used as a default and MAY be used as an input to path selection and protocol selection.  Some Transport Properties only apply to a single protocol (transport protocol, IP, or security protocol).  The presence of such Transport 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. </ins> 4.1.2. Endpoint: An Endpoint represents an identifier for one side of a

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