Original text:
6.5.  The steps are the same as specified in Section 6.4 of RFC7252 with the following changes: 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> 6.6. </del>  The steps are the same as specified in Section 6.5 of RFC7252 with the following changes:

Reviewer comments:
RFC 7252 section 5.10.1 says: The default value of the Uri-Host Option is the IP literal representing the destination IP address of the request message. Likewise, the default value of the Uri-Port Option is the destination UDP port. The default values for the Uri-Host and Uri-Port Options are sufficient for requests to most servers. Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers. Do we expect this default value to be applicable (and/or useful) for all the cases we are looking at? Maybe keeping Default-Uri-Host is not such a bad idea after all, or maybe we should clarify that this means for, say, a WebSocket server.
We should simply document appropriate defaults for TLS and WebSockets. There is already text for WS:
Regarding this scenario in RFC7252: Explicit Uri-Host and Uri-Port Options are typically used when an endpoint hosts multiple virtual servers. This is no longer relevant in CoAP over reliable transports. As Klaus noted in the earlier TRAC issue: In CoAP over WebSockets, the virtual server is specified during the WebSocket handshake in the Host header field. The Uri-Host Option is therefore not needed. A client wishing to talk to multiple virtual servers running on the same IP address has to open one WebSocket connection to each virtual server. (Please correct me if I'm wrong.) In CoAP over TLS we have the SNI extension, so I would expect that CoAP over TLS behaves like CoAP over WebSockets: no Uri-Host Option in requests, one connection to each virtual server. For the TLS+SNI case, the default value of the URI-Host is the underlying destination address that's shared across the virtual servers. Further note that the Hostname passed in the TLS SNI extension is not an "IP literal": URL - Literal IPv4 and IPv6 addresses are not permitted in "HostName". would still require our draft to support the URI-Host Option for this case: At the moment, this issue does not appear actionable.

Revised text:
6.5. <ins> CoAP over reliable transports maintains the property from Section 5.10.1 of RFC7252: The default values for the Uri-Host and Uri-Port Options are sufficient for requests to most servers. Unless otherwise noted, the default value of the Uri-Host Option is the IP literal representing the destination IP address of the request message.  The default value of the Uri-Port Option is the destination TCP port. For CoAP over TLS, these default values are the same unless Server Name Indication (SNI) RFC6066 is negotiated.  In this case, the default value of the Uri-Host Option in requests from the TLS client to the TLS server is the SNI host. For CoAP over WebSockets, the default value of the Uri-Host Option in requests from the WebSocket client to the WebSocket server is indicated by the Host header field from the WebSocket handshake. 6.6. </ins> The steps are the same as specified in Section 6.4 of RFC7252 with the following changes: If |port| does not equal the request's destination TCP port, include a Uri-Port Option and let that option's value be |port|.  <ins> 6.7. </ins> The steps are the same as specified in Section 6.5 of RFC7252 with the following changes: