Original text:
CoAP usage for IoT can make the use of UDP brittle, resulting in lost or malformed packets. <del> To address such environments, this document defines how to transport </del>  CoAP over TCP, CoAP over TLS, and CoAP over WebSockets. layering illustrates the layering: This document assumes that readers are familiar with the terms and concepts that are used in RFC6455 and RFC7252.  A Block1 or Block2 option that includes an SZX value of 7. CoAP over TCP message format.  All messages are also untyped. fig-flow-comparison illustrates the difference between CoAP over UDP <del> and CoAP over reliable transport.  The removed Type (no type) and Message ID fields are indicated by dashes. </del>  2.2.

Reviewer comments:
Replacing "CoAP over TCP, TLS and Websockets" with "CoAP over reliable transports" is a good idea to reduce repetition. I feel it might be a good idea to clarify when we refer to reliable transports, that we actually refer to stream-based reliable transports. Datagram-based reliable transports (eg DCCP, QUIC, etc) exist, which render the Message Framing layer in Figure 1 unnecessary. I'm not advocating that we run CoAP over QUIC, DCCP etc but perhaps clarification would be wise.
See also
I would add a note to the terminology section that CoAP over reliable transports refers to stream-based transport protocols, such as TCP.
Sounds reasonable: The term "reliable transport" only refers to stream-based transport protocols such as TCP.
URL The term "reliable transport" only refers to stream-based transport protocols such as TCP. We could say more explicitly: sequenced/order-preserving, reliable... (Stream might be byte stream or message stream.) s/only refers/is used only to refer/
NAME - I would probably avoid "sequenced" which suggests sequence numbers and acknowledgements which are the mechanism to provide reliability. Perhaps too much detail? How about: The term "reliable transport" is used only to refer to transport protocols such as TCP which provide reliable and ordered delivery of a byte-stream.
NAME wrote: This concisely clarifies my initial concern, and I'm ok with this.

Revised text:
CoAP usage for IoT can make the use of UDP brittle, resulting in lost or malformed packets.  <ins> Emerging standards such as Lightweight Machine to Machine LWM2M currently use CoAP over UDP as a transport and require support for CoAP over TCP to address the issues above and to protect investments in existing CoAP implementations and deployments.  Although HTTP/2 could also potentially address these requirements, there would be additional costs and delays introduced by such a transition. Currently, there are also fewer HTTP/2 implementations available for constrained devices in comparison to CoAP. To address these requirements, this document defines how to transport </ins> CoAP over TCP, CoAP over TLS, and CoAP over WebSockets. layering illustrates the layering: This document assumes that readers are familiar with the terms and concepts that are used in RFC6455 and RFC7252. <ins> The term "reliable transport" only refers to stream-based transport protocols such as TCP. </ins> A Block1 or Block2 option that includes an SZX value of 7. CoAP over TCP message format.  All messages are also untyped. fig-flow-comparison illustrates the difference between CoAP over UDP  <ins> and CoAP over reliable transport.  The removed Type and Message ID fields are indicated by dashes. </ins> 2.2.