Code change:
6.1. <del> Appendix A.1 of I-D.ietf-taps-minset explains, using primitives that are described in RFC8303 and RFC8304, how to implement changing the following protocol properties of an established connection with TCP and UDP.  Below, we amend this description for other protocols (if applicable): </del> <ins> Appendix A.1 of I-D.ietf-taps-minset explains, using primitives from RFC8303 and RFC8304, how to implement changing some of the following protocol properties of an established connection with TCP and UDP. Below, we amend this description for other protocols (if applicable) and extend it with Connection Properties that are not contained in I- D.ietf-taps-minset. </ins> <del> Relative niceness: for SCTP, this can be done using the primitive CONFIGURE_STREAM_SCHEDULER.SCTP described in section 4 of RFC8303. Timeout for aborting Connection: for SCTP, this can be done using the primitive CHANGE_TIMEOUT.SCTP described in section 4 of RFC8303. Abort timeout to suggest to the Remote Endpoint: for TCP, this can be done using the primitive CHANGE_TIMEOUT.TCP described in section 4 of RFC8303. </del> <ins> Notification of excessive retransmissions: TODO </ins> Retransmission threshold before excessive retransmission <del> notification: for TCP, this can be done using ERROR.TCP described in section 4 of RFC8303. </del> <ins> notification: TODO; for TCP, this can be done using ERROR.TCP described in section 4 of RFC8303. Notification of ICMP soft error message arrival: TODO </ins> Required minimum coverage of the checksum for receiving: for UDP- Lite, this can be done using the primitive SET_MIN_CHECKSUM_COVERAGE.UDP-Lite described in section 4 of RFC8303. <ins> Priority (Connection): TODO; for SCTP, this can be done using the primitive CONFIGURE_STREAM_SCHEDULER.SCTP described in section 4 of RFC8303. Timeout for aborting Connection: for SCTP, this can be done using the primitive CHANGE_TIMEOUT.SCTP described in section 4 of RFC8303. </ins> Connection group transmission scheduler: for SCTP, this can be done using the primitive SET_STREAM_SCHEDULER.SCTP described in section 4 of RFC8303. <ins> Maximum message size concurrent with Connection establishment: TODO Maximum Message size before fragmentation or segmentation: TODO Maximum Message size on send: TODO Maximum Message size on receive: TODO Capacity Profile: TODO Bounds on Send or Receive Rate: TODO TCP-specific Property: User Timeout: for TCP, this can be configured using the primitive CHANGE_TIMEOUT.TCP described in section 4 of RFC8303. </ins> It may happen that the application attempts to set a Protocol Property which does not apply to the actually chosen protocol.  In this case, the implementation should fail gracefully, i.e., it may

Related discussion:
text: Connection properties really are about configuring something, but I still say that being able to use them as early input is good. I agree that the implementation isn't super clear as they don't come with a require/prefer/... etc. qualifier, but then we just offer some freedom to implementers.
NAME I just pushed a commit that updates the selection and connection properties text, removing "connection" almost everywhere, but adding a disclaimer in the beginning that says that connection properties should be configured as early as possible because they can influence decisions made by the implementation, and "In the remainder of this document, we only refer to Selection Properties because they are the more typical case." Frankly I'm not sure this is better... but it does remove most of the "selection and connection" double mentions that you pointed out.
Fixed up branch building and resolved merge conflicts. I'll merge this in later today before the posting deadline.
Cool thanks! Sorry if I messed something up
As discussed in
Thank you for updating this – looks good! just needs s/send-params/msg-properties/ and merging