Change:
5.2.2. <del> Protocol Properties represent the configuration of a transport protocol once it has been selected.  A transport protocol may not support all Protocol Properties, depending on the available transport features.  As with Transport Preferences (transport-prefs), Protocol Properties are specified on the Preconnection object, and are using during initiation of a Connection to help the system choose an appropriate transport.  The system will only actually set those protocol properties that are actually supported by the chosen transport protocol.  These properties all apply to Connections and Connection groups.  The default settings of these properties depends on the chosen protocol and on the system configuration. Set timeout for aborting Connection: This numeric property specifies how long to wait before aborting a Connection attempt. It is given in seconds. </del> <ins> Protocol Properties represent the configuration that protocols should use once they have been selected.  Some properties apply generically across multiple transport protocols, in which case they may be used by the system to help select candidate protocols.  Other properties only apply to specific protocols.  As with Transport Preferences (transport-prefs), Protocol Properties are specified on the Preconnection object.  The default settings of these properties will vary based on the specific protocols being used and the system's configuration. Generic Protocol Properties include: Set timeout for aborting Connection establishment: This numeric property specifies how long to wait before aborting a Connection attempt.  It is given in seconds. </ins> Set timeout to suggest to the peer: This numeric property specifies the timeout to propose to the peer.  It is given in

Discussion:
This addresses
Section 5.2.2. of the API should include the concept from the architecture of Specific Protocol Properties. I think expecting that all of these timeout/etc values should be the same no matter what protocol is selected is limiting, and a bit naive. I know as an application, for example, that I may need to do more keep alive activity to make NATs happy for UDP-based protocols than for TCP-based protocols (where are you, PLUS?!). Just a quick paragraph to indicate that the API can allow protocol-specific options to tune based on what is ultimately selected would be good.
let's race candidate authors for this paragraph ;) those who do not charter working groups for good ideas are doomed to forever reinvent them poorly.
Is 5.2.2 supposed to be the Specific Protocol Properties section? This section also seems to be a mix of things right now. I think this needs to be fixed as part of a bigger rework of section 5.2.
Agreed. Check out my pull request—I switch the text to talking about the architecture concepts of Generic Protocol Properties and Specific Protocol Properties.
That is better, but just a partial fix. I think we should get rid of the term Transport Preferences and the content of 5.2.1 and 5.2.2 needs to be reshuffled. Most of what is in 5.2.1 reads as protocol properties to me so I do not understand the current split.
That's fine with me. We could merge this PR in, and then as Brian does a pass, we can clean the rest up.
lgtm