Change:
NAME - can you review (don't see you in the Reviewers list)?
Referencing , I have these comments: I feel the text in Section 7 discussing security solutions pertains to both TCP as well as WebSockets, and therefore propose the following amendment: "A security solution MUST be implemented to protect CoAP over reliable transports and MUST be enabled by default. This document defines the TLS binding, but alternative solutions at different layers in the protocol stack MAY be used to protect CoAP over reliable transports when appropriate." In addition I have the following suggestion for a new subsection as follows: A CoAP client requesting a resource identified by a “coaps+ws” URI negotiates a secure WebSocket connection to a WebSocket server endpoint, with a “wss" URI. This is described and depicted in section 6.4. As provided by the guidance in Section 4.1 of [RFC6455], the client MUST perform a TLS handshake after opening the connection to the server. The guidance in Section 4.4 of [RFC7925] applies towards mandatory-to-implement TLS functionality for certificates, when a CoAP server exposes resources identified by a “coaps+ws” URI. For the server-side requirements in accepting incoming connections over port 443, guidance given in Section 4.2 of [RFC6455] applies.
Minor. Regarding for the server-side requirements in accepting incoming connections over port 443, guidance given in Section 4.2 of [RFC6455] applies .... RFC6455 actually refers to an HTTPS (HTTP-over-TLS) port in this section:
Thanks Brian, this is ok with me

Discussion:
environment).  ... even if those features stretch the capabilities of such devices. <del> A security solution MUST be implemented to protect CoAP over TCP and MUST be enabled by default.  This document defines the TLS binding, but alternative solutions at different layers in the protocol stack MAY be used to protect CoAP over TCP when appropriate.  Note that there is ongoing work to support a data object-based security model for CoAP that is independent of transport (see I-D.ietf-core-object- security). </del> <ins> A security solution MUST be implemented to protect CoAP over reliable transports and MUST be enabled by default.  This document defines the TLS binding, but alternative solutions at different layers in the protocol stack MAY be used to protect CoAP over reliable transports when appropriate.  Note that there is ongoing work to support a data object-based security model for CoAP that is independent of transport (see I-D.ietf-core-object-security). </ins> 7.1.

indicated by the "coaps+tcp" scheme and TLS-secured CoAP default port. <ins> 7.2. A CoAP client requesting a resource identified by a "coaps+ws" URI negotiates a secure WebSocket connection to a WebSocket server endpoint with a "wss" URI.  This is described in coaps-ws-scheme. The client MUST perform a TLS handshake after opening the connection to the server.  The guidance in Section 4.1 of RFC6455 applies.  When a CoAP server exposes resources identified by a "coaps+ws" URI, the guidance in Section 4.4 of RFC7925 applies towards mandatory-to- implement TLS functionality for certificates.  For the server-side requirements in accepting incoming connections over a HTTPS (HTTP- over-TLS) port, the guidance in Section 4.2 of RFC6455 applies. </ins> 8. The security considerations of RFC7252 apply.  For CoAP over