Original text:
The payload of a CoAP message that is affected by a BERT Option in <del> descriptive usage (Section 2.1 of I-D.ietf-core-block). </del>  2. WebSocket protocol does not provide means for multiplexing.  If it is not desirable for a large message to monopolize the connection, requests and responses can be transferred in a block-wise fashion as <del> defined in I-D.ietf-core-block. </del>  Empty messages (Code 0.00) MUST be ignored by the recipient (see also sec-ping). 4.3.3. A sender can use the Block-wise Transfer elective Option to indicate <del> that it supports the block-wise transfer protocol I-D.ietf-core- block. </del>  If the option is not given, the peer has no information about whether block-wise transfers are supported by the sender or not.  An The message size restrictions defined in Section 4.6 of CoAP RFC7252 to avoid IP fragmentation are not necessary when CoAP is used over a reliable byte stream transport.  While this suggests that the Block- <del> wise transfer protocol I-D.ietf-core-block is also no longer needed, it remains applicable for a number of cases: </del>  large messages, such as firmware downloads, may cause undesired head-of-line blocking when a single TCP connection is used The use of this new extension is signaled by sending Block1 or Block2 Options with SZX == 7 (a "BERT option").  SZX == 7 is a reserved <del> value in I-D.ietf-core-block. </del>  In control usage, a BERT option is interpreted in the same way as the equivalent Option with SZX == 6, except that it also indicates the

Reviewer comments:
There's no longer an informative reference to this expired draft. Originally, it was included in the Introduction of draft-savolainen-core-coap-websockets-07.

Revised text:
The payload of a CoAP message that is affected by a BERT Option in  <ins> descriptive usage (Section 2.1 of RFC7959). </ins> 2. WebSocket protocol does not provide means for multiplexing.  If it is not desirable for a large message to monopolize the connection, requests and responses can be transferred in a block-wise fashion as  <ins> defined in RFC7959. </ins> Empty messages (Code 0.00) MUST be ignored by the recipient (see also sec-ping). 4.3.3. A sender can use the Block-wise Transfer elective Option to indicate  <ins> that it supports the block-wise transfer protocol RFC7959. </ins> If the option is not given, the peer has no information about whether block-wise transfers are supported by the sender or not.  An The message size restrictions defined in Section 4.6 of CoAP RFC7252 to avoid IP fragmentation are not necessary when CoAP is used over a reliable byte stream transport.  While this suggests that the Block-  <ins> wise transfer protocol RFC7959 is also no longer needed, it remains applicable for a number of cases: </ins> large messages, such as firmware downloads, may cause undesired head-of-line blocking when a single TCP connection is used The use of this new extension is signaled by sending Block1 or Block2 Options with SZX == 7 (a "BERT option").  SZX == 7 is a reserved  <ins> value in RFC7959. </ins> In control usage, a BERT option is interpreted in the same way as the equivalent Option with SZX == 6, except that it also indicates the