Change:
that an application can pass to describe its intent, requirements, prohibitions, and preferences for its networking operations.  For any system that provides generic Transport Services, these <del> properties SHOULD be defined to apply to multiple transport protocols.  Some properties are specific to a single transport protocol, and these are be exposed as non-generic interfaces (see Specific Protocol Properties preestablishment).  Properties can have a large impact on the rest of the aspects of the interface: they modify how establishment occurs, they influence the expectations around data transfer, and they determine the set of events that will be supported. </del> <ins> Selection Properties SHOULD be defined to apply to multiple transport protocols.  Selection Properties can have a large impact on the rest of the aspects of the interface: they modify how establishment occurs, they influence the expectations around data transfer, and they determine the set of events that will be supported. </ins> Establishment (establishment) focuses on the actions that an application takes on the basic objects to prepare for data

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