Skip to main content

Last Call Review of draft-ietf-core-coap-tcp-tls-07
review-ietf-core-coap-tcp-tls-07-artart-lc-nottingham-2017-04-09-00

Request Review of draft-ietf-core-coap-tcp-tls
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team ART Area Review Team (artart)
Deadline 2017-04-09
Requested 2017-03-26
Authors Carsten Bormann , Simon Lemay , Hannes Tschofenig , Klaus Hartke , Bill Silverajan , Brian Raymor
I-D last updated 2017-04-09
Completed reviews Genart Last Call review of -07 by Meral Shirazipour (diff)
Artart Last Call review of -07 by Mark Nottingham (diff)
Tsvart Last Call review of -07 by Yoshifumi Nishida (diff)
Tsvart Telechat review of -07 by Yoshifumi Nishida (diff)
Assignment Reviewer Mark Nottingham
State Completed
Request Last Call review on draft-ietf-core-coap-tcp-tls by ART Area Review Team Assigned
Reviewed revision 07 (document currently at 11)
Result Not ready
Completed 2017-04-09
review-ietf-core-coap-tcp-tls-07-artart-lc-nottingham-2017-04-09-00
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.