Change:
URL - WGLC review by Esko Dijk • Page 22: "contain a multiple of 1024 bytes (non-final BERT block) or more than 1024 bytes (final BERT block)" -> Why can't the final block be 1024 bytes? I assume a final BERT block of 1024 bytes is allowed; it would be strange to switch back to SZX=6 for that purpose. What about below text -> "contain a multiple of 1024 bytes (non-final BERT block) or more than 1023 bytes (final BERT block)"
NAME - would you review and validate?
The text explains what is allowed with SZX=7 that is not allowed with SZX=6. As correctly noted, 1024 final is already allowed for SZX=6 (as is 1023, 1022, ...), so this is not explicitly listed in the list of additionally allowed cases. Maybe make clearer that this extends what has been allowed before instead of just saying that this is now allowed: s/is allowed/is also allowed/ or s//is additionally allowed/.
That seems like a simpler (if more subtle) edit.

Discussion:
A sender can also include an elective Custody Option in a Ping message to explicitly request the inclusion of an elective Custody <del> Option in the corresponding Pong message.  The receiver SHOULD delay its Pong message until it finishes processing all the request/ response messages received prior to the Ping message on the current connection. </del> <ins> Option in the corresponding Pong message.  In that case, the receiver SHOULD delay its Pong message until it finishes processing all the request/response messages received prior to the Ping message on the current connection. </ins> 5.5.

BERT block instead. In descriptive usage, a BERT Option is interpreted in the same way as <del> the equivalent Option with SZX == 6, except that the payload is </del> <ins> the equivalent Option with SZX == 6, except that the payload is also </ins> allowed to contain a multiple of 1024 bytes (non-final BERT block) or more than 1024 bytes (final BERT block).

In all these examples, a Block Option is decomposed to indicate the kind of Block Option (1 or 2) followed by a colon, the block number <del> (NUM), more bit (M), and block size exponent (2**(SZX+4)) separated by slashes.  E.g., a Block2 Option value of 33 would be shown as </del> <ins> (NUM), more bit (M), and block size (2**(SZX+4)) separated by slashes.  E.g., a Block2 Option value of 33 would be shown as </ins> 2:2/0/32), or a Block1 Option value of 59 would be shown as 1:3/1/128.

Resources made available via these schemes have no shared identity even if their resource identifiers indicate the same authority (the <del> same host listening to the same TCP port).  They are distinct namespaces and are considered to be distinct origin servers. </del> <ins> same host listening to the same TCP port).  They are hosted in distinct namespaces because each URI scheme implies a distinct origin server. </ins> The syntax for the URI schemes in this section are specified using Augmented Backus-Naur Form (ABNF) RFC5234.  The definitions of

7.6. The steps are the same as specified in Section 6.4 of RFC7252 with <del> the following changes: </del> <ins> minor changes. This step from RFC7252: is updated to: </ins> <del> If |url| does not have a <scheme> component whose value, when converted to ASCII lowercase, is "coap+tcp", "coaps+tcp", "coap+ws", or "coaps+ws" then fail this algorithm. </del> <ins> This step from RFC7252: </ins> <del> If |port| does not equal the request's destination TCP port, include a Uri-Port Option and let that option's value be |port|. </del> <ins> is updated to: </ins> 7.7. The steps are the same as specified in Section 6.5 of RFC7252 with <del> the following changes: </del> <ins> minor changes. </ins> <del> For CoAP over TCP, if the request is secured using TLS, let |url| be the string "coaps+tcp://".  Otherwise, let |url| be the string "coap+tcp://".  For CoAP over WebSockets, if the request is secured using TLS, let |url| be the string "coaps+ws://".  Otherwise, let |url| be the string "coap+ws://". </del> <ins> This step from RFC7252: </ins> <del> If the request includes a Uri-Port Option, let |port| be that option's value.  Otherwise, let |port| be the request's destination TCP port. </del> <ins> is updated to: This step from RFC7252: is updated to: </ins> 8.