First, a general comment. I have been concerned about the duplication of effort that COAP represents for some time, and that concern grows significantly upon reading this draft. COAP is now specifying multiple "bindings" to underlying application and transport protocols, re-inventing message framing,  congestion control in UDP, etc. The introduction justifies this development over the reuse of HTTP/2 (and presumably QUIC, once available) based upon the relative availability of implementations for constrained devices. Whether that remains true will only be judged by the market -- unfortunately after all of the cost of development and standardisation is sunk.

The introduction motivates the layering of COAP over WebSockets to allow it to be used in a network that only allows external access through a HTTP proxy. In fact, it is not necessary to use WebSockets to do so; HTTP CONNECT provides a tunnel in this scenario. WebSockets is a specialised protocol that allows bidirectional, stream-based transport from a Web browser -- it is effectively TCP wrapped into the Web browser's security model, to make doing so safe. Using it for other purposes (i.e., non-browser use cases) isn't really appropriate. I'd suggest either removing the WebSockets binding, or changing its motivation in the Introduction.

Section 7 defines a number of new URI schemes for COAP protocols. Syntactically, they use "+" to separate "coap" from the underlying transport(-ish) protocol that they're bound to; e.g., "coap+tcp". This syntax is allowed by RFC3986, but is unprecedented, and implies a sub-syntax convention similar to those used in media types, etc. Is there an expectation that other URI schemes starting with "coap+" are reserved? 

Defining URI schemes that switch transport protocol based upon their name deserves wider review as well; this has been a contentious topic in the past, and it would be good to understand what tradeoffs are being made by doing so. Locking identifiers into a specific transport protocol sacrifices much of the power of URLs. Furthermore, creating "coap+ws" to denote a specific protocol over WebSockets (which has its own URI scheme) is questionable; taken to its natural conclusion, we'll have a proliferation of URI schemes for things over WebSockets. Will COAP take the same approach for HTTP?

I would suggest a wider discussion of these issues on art@ / uri@.

Section 7.4 shows how to convert a "coap+ws://" URI into a "wss://" URI, using a well-known URI in the "wss" scheme. However, "wss" is not defined to use well-known URIs, so this is an invalid use. I'm not sure how to address this, other than removing the WebSockets binding.

Section 8.1 makes it Mandatory to Implement the protocol without any security ("NoSec"). This seems counter to best practice in the IETF, but I'll defer to the Security Area review.