Change:
configured via a Preconnection, or by inheriting them from an antecedent via cloning; see groups for more. <ins> In addition to protocol and path selection properties, the transport parameters may also contain Generic and/or Specific Protocol Properties (see protocol-props).  These properties will be passed to the selected candidate Protocol Stack(s) to configure them before candidate Connection establishment. The following properties can be used during Protocol and Path selection: 5.2.1. This boolean property specifies whether the application wishes to use a transport protocol that that provides mechanisms to help ensure that all data is received and without corruption on the other side. This also entails being notified when a Connection is closed or aborted.  This property applies to Connections and Connection Groups. This is a strict requirement.  The default is to enable Reliable Data Transfer. 5.2.2. This boolean property specifies whether the application wishes to use a transport protocol that provides mechanisms to ensure that data is received by the application on the other end in the same order as it was sent.  This property applies to Connections and Connection Groups.  This is a strict requirement.  The default is to preserve data ordering. 5.2.3. This boolean property specifies whether an application considers it useful to indicate its reliability requirements on a per-Message basis.  This property applies to Connections and Connection Groups. This is not a strict requirement.  The default is to not have this option. 5.2.4. This boolean property specifies whether an application would like to supply a Message to the transport protocol before Connection establishment, which will then be reliably transferred to the other side before or during Connection establishment, potentially multiple times.  See also send-idempotent.  This is a strict requirement.  The default is to not have this option. 5.2.5. This boolean property specifies that the application would prefer multiple Connections within a Connection Group to be provided by streams of a single underlying transport connection where possible. This is not a strict requirement.  The default is to not have this option. 5.2.6. This boolean property specifies whether an application considers it useful to be informed in case sent data was retransmitted more often than a certain threshold.  This property applies to Connections and Connection Groups.  This is not a strict requirement.  The default is to have this option. 5.2.7. This boolean property specifies whether an application considers it useful to be informed when an ICMP error message arrives that does not force termination of a connection.  This property applies to Connections and Connection Groups.  Received ICMP errors will be available as SoftErrors.  Note that even if a protocol supporting this property is selected, not all ICMP errors will necessarily be delivered, so applications cannot rely on receiving them.  This is not a strict requirement.  The default is not to have this option. 5.2.8. This boolean property specifies whether the application considers it useful to enable / disable / configure a checksum when sending data, or decide whether to require a checksum or not when receiving data. This property applies to Connections and Connection Groups.  This is not a strict requirement, as it signifies a reduction in reliability. The default is full checksum coverage without being able to change it, and requiring a checksum when receiving. 5.2.9. This enumerated property specifies which kind of access network interface, e.g., WiFi, Ethernet, or LTE, to prefer over others for this Connection, in case they are available.  In general, Interface Types should be used only with the "Prefer" and "Prohibit" preference level.  Specifically, using the "Require" preference level for Interface Type may limit path selection in a way that is detrimental to connectivity.  The default is to use the default interface configured in the system policy. 5.2.10. This enumerated property specifies the application's expectation of the dominating traffic pattern for this Connection.  The Capacity Profile should only be used with the "Prefer" preference level; other preference levels make no sense for profiles.  The following values are valid for Capacity Profile: The application makes no representation about its expected capacity profile.  No special optimizations of the tradeoff between delay, delay variation, and bandwidth efficiency should be made when selecting and configuring stacks. The application is interactive.  Response time (latency) should be optimized at the expense of bandwidth efficiency and delay variation.  This can be used by the system to disable the coalescing of multiple small Messages into larger packets (Nagle's algorithm), to prefer lower-latency paths, signal a preference for lower-latency, higher-loss treatment, and so on. The application expects to send/receive data at a constant rate after Connection establishment.  Delay and delay variation should be optimized at the expense of bandwidth efficiency.  This implies that the Connection may fail if the desired rate cannot be maintained across the Path.  A transport may interpret this capacity profile as preferring a circuit breaker RFC8084 to a rate adaptive congestion controller. The application is not interactive.  It expects to send/receive a large amount of data, without any urgency.  This can be used to select protocol stacks with scavenger transmission control, to signal a preference for less-than-best-effort treatment, and so on. </ins> 5.3. Common parameters such as TLS ciphersuites are known to

Discussion:
Send parameters were subsections, transport selection properties were not. This fixes that by promiting transport selection properties to subsections, and reorganizing the sections slightly to make that fit. There are no changes to technical content in this PR.
Makes sense - had that one also on my list of ugliness to be fixed.