Change:
Setting options indicate a setting that will be applied by the sender. <del> A Capability and Settings message MUST be sent by both endpoints at the start of the connection and MAY be sent at any other time by either endpoint over the lifetime of the connection. </del> <ins> One CSM MUST be sent by both endpoints at the start of the connection.  Further CSM MAY be sent at any other time by either endpoint over the lifetime of the connection. </ins> <del> Both capability and settings options are cumulative.  A Capability and Settings message does not invalidate a previously sent capability indication or setting even if it is not repeated.  A capability message without any option is a no-operation (and can be used as such).  An option that is sent might override a previous value for the same option.  The option defines how to handle this case if needed. </del> <ins> Both capability and setting options are cumulative.  A CSM does not invalidate a previously sent capability indication or setting even if it is not repeated.  A capability message without any option is a no- operation (and can be used as such).  An option that is sent might override a previous value for the same option.  The option defines how to handle this case if needed. </ins> Base values are listed below for CSM Options.  These are the values <del> for the Capability and Setting before any Capability and Settings </del> <ins> for the capability and setting before any Capabilities and Settings </ins> messages send a modified value. These are not default values for the option as defined in Section 5.4.4 in RFC7252.  A default value would mean that an empty <del> Capability and Settings message would result in the option being set to its default value. </del> <ins> Capabilities and Settings message would result in the option being set to its default value. </ins> <del> Capability and Settings messages are indicated by the 7.01 code </del> <ins> Capabilities and Settings messages are indicated by the 7.01 code </ins> (CSM). 4.3.1.

Discussion:
One more 7.01 change to 7.00. Removed redundant requirement for references to abort: MAY immediately abort the connection (see Section 4.6) . since the Abort section already has the SHOULD.
URL Signaling s/Share/Relate/ (the nodes do not "share these characteristics") Shut down s/Ordered/Orderly/ Provide diagnostic information when terminating a connection in ... 4.3. Capability and Settings Messages (CSM) Hmm, should this be "Capabilities and Settings Messages"? (Need to change throughout.) s/A/One/ s/Capability and Settings message/CSM/ s/and/. Further CSM/ s/settings/setting/ 4.3.2. Max-Message-Size Capability Option (above 1152?)
URL Appendix B. Negotiating Protocol Versions s/Capability and Settings/Capabilities and Settings Messages (CSM)/
URL Cl.4.5/4.6: The text mentions a "diagnostic payload", is some standard envisaged for this or is it implementation dependent? This is implementation dependent, although it might be helpful to adapt or reference - URL
Reviewed in more detail. There is a reference to RFC7252 in an earlier section URL
Perhaps the RFC7252 references needs to be emphasized more. Options: Blockquote related RFC7252 Section 5.5.2 in section 4.1 to call more attention to it Include an xref with each related normative statement The simplest mitigation is the xref: A Release message indicates that the sender does not want to continue maintaining the connection and opts for an orderly shutdown. The details are in the options. A diagnostic payload (see Section 5.5.2 of [RFC7252]) MAY be included.