Code change:
This is the second step towards applying our new Properties Classification. It moves up the Connection Properties and annotates most places with stuff to do.
As discussed in
Thanks for moving this forward! I only found a few nits. Also, I have a question about whether two of these Properties should maybe be changed to be Selection Properties, but that's more of a discussion and not something that needs to be done in this URL modulo NAME commentsI carefully checked it, but I find it very hard to be sure that this is 100% ok (as is usually the case IMO with diff's about text blocks being moved around). My suggestion is to land it and see.

Related discussion:
text: domain RFC7556, measurements by the Protocol Stack, or other sources. <ins> 9.1.1. Boolean This property specifies whether an application considers it useful to be informed in case sent data was retransmitted more often than a certain threshold.  When set to true, the effect is twofold: The application may receive events in case excessive retransmissions.  In addition, the transport system considers this as a preference to use transports stacks that can provide this notification.  This is not a strict requirement.  If set to false, no notification of excessive retransmissions will be sent and this transport feature is ignored for protocol selection. The default is to have this option. 9.1.2. Integer This property specifies after how many retransmissions to inform the application about "Excessive Retransmissions". 9.1.3. Boolean This 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.  When set to true, 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.  Setting this option also implies a preference to prefer transports stacks that can provide this notification.  If not set, no events will be sent for ICMP soft error message and this transport feature is ignored for protocol selection. This property applies to Connections and Connection Groups.  The default is not to have this option. 9.1.4. Integer This property specifies the part of the received data that needs to be covered by a checksum.  It is given in Bytes.  A value of 0 means that no checksum is required, and a special value (e.g., -1) indicates full checksum coverage. 9.1.5. Integer This Property is a non-negative integer representing the relative inverse priority of this Connection relative to other Connections in the same Connection Group.  It has no effect on Connections not part of a Connection Group.  As noted in groups, this property is not entangled when Connections are cloned. 9.1.6. Integer This property specifies how long to wait before aborting a Connection during establishment, or before deciding that a Connection has failed after establishment.  It is given in seconds. 9.1.7. Enum This property specifies which scheduler should be used among Connections within a Connection Group, see groups.  The set of schedulers can be taken from I-D.ietf-tsvwg-sctp-ndata. 9.1.8. Integer (read only) This property represents the maximum Message size that can be sent before or during Connection establishment, see also msg-idempotent. It is given in Bytes. 9.1.9. Integer (read only) This property, if applicable, represents the maximum Message size that can be sent without incurring network-layer fragmentation or transport layer segmentation at the sender. 9.1.10. Integer (read only) This property represents the maximum Message size that can be sent. 9.1.11. Integer (read only) This numeric property represents the maximum Message size that can be received. 9.2. </ins> Slightly different from "querying", a SoftError Event can also occur, informing the application about the receipt of an ICMP error message related to the Connection.  This will only happen if the underlying