Original text:
2.2. <del> Both the client and the server MUST send a Capability and Settings </del>  message (CSM see csm) as its first message on the connection.  This message establishes the initial settings and capabilities for the endpoint such as maximum message size or support for block-wise provided by CoAP over UDP.  The Type (T) and Message ID fields in the CoAP message header are elided. <del> The Version (Vers) field is elided as well.  In constrast to the UDP message layer for UDP and DTLS, the CoAP over TCP message layer does not send a version number in each message.  If required in the future, a new Capability and Settings Option (see negotiation) could be defined to support version negotiation. </del>  In a stream oriented transport protocol such as TCP, a form of message delimitation is needed.  For this purpose, CoAP over TCP Signaling messages are introduced to allow peers to: <del> Share characteristics such as maximum message size for the </del>  connection <del> Shutdown the connection in an ordered fashion </del>  <del> Terminate the connection in response to a serious error condition </del>  Signaling is a third basic kind of message in CoAP, after requests and responses.  Signaling messages share a common structure with the 4.1. <del> A code in the 7.01-7.31 range indicates a Signaling message.  Values </del>  in this range are assigned by the "CoAP Signaling Codes" sub-registry (see message-codes). For each message, there is a sender and a peer receiving the message. <del> Payloads in Signaling messages are diagnostic payloads (see </del>  Section 5.5.2 of RFC7252), unless otherwise defined by a Signaling message option. 4.3. <del> Capability and Settings messages (CSM) are used for two purposes: </del>  Each capability option advertises one capability of the sender to the recipient. 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>  <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>  Base values are listed below for CSM Options.  These are the values <del> for the Capability and Setting before any Capability and Settings </del>  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>  <del> Capability and Settings messages are indicated by the 7.01 code </del>  (CSM). 4.3.1. the maximum message size in bytes that it can receive. As per Section 4.6 of RFC7252, the base value (and the value used <del> when this option is not implemented) is 1152.  A peer that relies on this option being indicated with a certain minimum value will enjoy limited interoperability. </del>  4.3.3. A Release message indicates that the sender does not want to continue maintaining the connection and opts for an orderly shutdown.  The <del> details are in the options.  A diagnostic payload MAY be included.  A peer will normally respond to a Release message by closing the TCP/ TLS connection.  Messages may be in flight when the sender decides to send a Release message.  The general expectation is that these will still be processed. </del>  Release messages are indicated by the 7.04 code (Release). release.  The sender shuts down the connection immediately after the abort (and may or may not wait for a Release or Abort message or connection shutdown in the inverse direction).  A diagnostic payload <del> SHOULD be included in the Abort message.  Messages may be in flight when the sender decides to send an Abort message.  The general expectation is that these will NOT be processed. </del>  Abort messages are indicated by the 7.05 code (Abort). TLS version 1.2 or higher is mandatory-to-implement and MUST be enabled by default.  An endpoint MAY immediately abort a CoAP over <del> TLS connection that does not meet this requirement (see sec-abort) and SHOULD include a diagnostic payload. </del>  The TLS usage guidance in RFC7925 SHOULD be followed.

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

Revised text:
2.2.  <ins> Both the client and the server MUST send a Capabilities and Settings </ins> message (CSM see csm) as its first message on the connection.  This message establishes the initial settings and capabilities for the endpoint such as maximum message size or support for block-wise provided by CoAP over UDP.  The Type (T) and Message ID fields in the CoAP message header are elided.  <ins> The Version (Vers) field is elided as well.  In contrast to the message format of CoAP over UDP, the message format for CoAP over TCP does not include a version number.  CoAP is defined in RFC7252 with a version number of 1.  At this time, there is no known reason to support version numbers different from 1.  If version negotiation needs to be addressed in the future, then Capabilities and Settings Messages (CSM see csm) have been specifically designed to enable such a potential feature. </ins> In a stream oriented transport protocol such as TCP, a form of message delimitation is needed.  For this purpose, CoAP over TCP Signaling messages are introduced to allow peers to:  <ins> Related characteristics such as maximum message size for the </ins> connection  <ins> Shut down the connection in an orderly fashion </ins>  <ins> Provide diagnostic information when terminating a connection in response to a serious error condition </ins> Signaling is a third basic kind of message in CoAP, after requests and responses.  Signaling messages share a common structure with the 4.1.  <ins> A code in the 7.00-7.31 range indicates a Signaling message.  Values </ins> in this range are assigned by the "CoAP Signaling Codes" sub-registry (see message-codes). For each message, there is a sender and a peer receiving the message.  <ins> Payloads in Signaling messages are diagnostic payloads as defined in </ins> Section 5.5.2 of RFC7252), unless otherwise defined by a Signaling message option. 4.3.  <ins> Capabilities and Settings messages (CSM) are used for two purposes: </ins> Each capability option advertises one capability of the sender to the recipient. Setting options indicate a setting that will be applied by the sender.  <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>  <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  <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  <ins> Capabilities and Settings message would result in the option being set to its default value. </ins>  <ins> Capabilities and Settings messages are indicated by the 7.01 code </ins> (CSM). 4.3.1. the maximum message size in bytes that it can receive. As per Section 4.6 of RFC7252, the base value (and the value used  <ins> when this option is not implemented) is 1152. </ins> 4.3.3. A Release message indicates that the sender does not want to continue maintaining the connection and opts for an orderly shutdown.  The  <ins> details are in the options.  A diagnostic payload (see Section 5.5.2 of RFC7252) MAY be included.  A peer will normally respond to a Release message by closing the TCP/TLS connection.  Messages may be in flight when the sender decides to send a Release message.  The general expectation is that these will still be processed. </ins> Release messages are indicated by the 7.04 code (Release). release.  The sender shuts down the connection immediately after the abort (and may or may not wait for a Release or Abort message or connection shutdown in the inverse direction).  A diagnostic payload  <ins> (see Section 5.5.2 of RFC7252) SHOULD be included in the Abort message.  Messages may be in flight when the sender decides to send an Abort message.  The general expectation is that these will NOT be processed. </ins> Abort messages are indicated by the 7.05 code (Abort). TLS version 1.2 or higher is mandatory-to-implement and MUST be enabled by default.  An endpoint MAY immediately abort a CoAP over  <ins> TLS connection that does not meet this requirement (see sec-abort). </ins> The TLS usage guidance in RFC7925 SHOULD be followed.