ietf
[Top] [All Lists]

Re: Artart last call review of draft-ietf-core-coap-tcp-tls-07

2017-04-10 19:40:07
Hi Carsten,

Couple of quic responses below.

On 10 Apr 2017, at 7:46 pm, Carsten Bormann <cabo(_at_)tzi(_dot_)org> wrote:

I agree that the introduction should focus on the Browser use case and keep 
out of the firewall traversal jungle.

OK. Just curious -- is there a strong motivation here? It seems very odd to 
tunnel HTTP-like semantics over a custom UDP protocol (COAP) over WebSockets 
over HTTP again, rather than just using HTTP (which AIUI you already have a 
mapping to).


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? 

There is no such expectation.

We did have the discussion about reserved URI scheme prefixes in the IETF, 
and as I recall, the result was that there are none.  While it would be a bit 
weird to register a URI scheme starting with coap+ or coaps+ that is 
unrelated to CoAP, only the slightly boggled response from an expert review 
is in the way of that happening.

Would the scheme names be more palatable with a dash instead of a plus?
Careful choice of the scheme name mostly benefits the implementer, so it can 
be changed in the spec (at the cost of changing existing implementations).

OK. I'm mostly noting this in case other folks feel that this is a bad 
precedent for URI schemes; I think the bigger concern is the one below.


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.

The “siloing” of URIs along schemes is indeed a problem, which started for 
CoAP with the separation of the coap:/coaps: name spaces.  The CoRE WG did 
not see it as its task to address this shortcoming.  So, for now, we’ll have 
to live with it; approaches such as 
draft-silverajan-core-coap-protocol-negotiation are trying to address its 
practicalities.

By defining multiple URI schemes for different transports of the same protocol, 
the WG has taken a position as to what the solution is. I'm finding it 
difficult to square this with the continuing characterisation of CORE as 
"RESTful".


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.

I’m not sure that a proliferation will happen — WebSockets is mostly used for 
tightly bound proprietary protocols between a JavaScript mobile code client 
and a server that provides this mobile code client.  On the other hand, 
deciding to never use URIs to refer to resources available over a WebSockets 
protocol strikes me as an unnecessary restriction.

Will COAP take the same approach for HTTP?

Not sure what this question is leading into.
(We do have a defined relationship with HTTP, in RFC 7252 and RFC 8075.
But maybe this is about something different.)

I mean to ask whether there will be a need for a "coap+http" URI scheme; it 
seems like a logical conclusion of the approach taken here. 


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

Indeed, a wider discussion of these longstanding issues would be useful.
I’m not sure that waiting for their resolution is blocking this spec.

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. 

This incorrect use of RFC 5785 is indeed embarrassing.  More about that later.

OK. The other obvious path is to opt wss:// (and ws://?) into RFC5785, but I 
think that would take a separate RFC that updates their scheme registrations. 
Not sure whether there would be any pushback in that community (but I can't see 
any immediate reason why there would be).


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.

Since it is the implementers who will decide whether they implement this, 
this co-author could live with making implementing NoSec completely optional. 
 (It will be anyway, in practice, at the level of what is actually 
configured.)  The important point(*) from the WG perspective here is that TLS 
is mandatory to implement, with the specifics depending on the security mode 
needed (cf. RFC 7925).  (Note also that there are other ways to provide 
security with CoAP.)

Ack. Again, this was mostly a note to bring it to others' attention; the use of 
the phrase "Mandatory to Implement" when applied to "no security" just seems 
odd.

Cheers,


Grüße, Carsten

(*) 
https://github.com/core-wg/coap-tcp-tls/commit/fe348f543fc45e981e38e9354242012afb28dc60


--
Mark Nottingham   https://www.mnot.net/