Original text:
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>  Set timeout to suggest to the peer: This numeric property specifies the timeout to propose to the peer.  It is given in before or during Connection establishment, see also send- idempotent.  It is given in Bytes.  5.2.3. Application Intents are a group of properties expressing what an

Reviewer comments:
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

Revised text:
5.2.2.  <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 before or during Connection establishment, see also send- idempotent.  It is given in Bytes. <ins> In order to specify Specific Protocol Properties, the application can attach a set of options to the Preconnection object, associated with a specific protocol.  For example, the application could specify a set of TCP Options to use if and only if TCP is selected by the system, including options such as the Maximum Segment Size (MSS), and options around Acknowledgement Stretching.  Such properties should not be assumed to apply across different protocols, but must be possible to specify if required by the application. </ins> 5.2.3. Application Intents are a group of properties expressing what an