The Constrained Application Protocol (CoAP)
draft-ietf-core-coap-18

I want to thank the authors and WG for producing this specification. I
think it may be one of the more important pieces of work in recent
years. As might be expected with a document of over 100 pages reviewed
by a pedant, I have a list of nits and worries. These are all enetered
as Comments: I hope you will find time to address them and make the
resulting RFC more polished, but none of them comes even close to a
requirement that you change the text, and I am ballotting Yes.

---

How quickly we forget!

I looked up the spec of a typical home computer around the time of HTTP
v1.0 and discovered that it was not so very different from what you are
scoping your environment to today.

That is not to say that your work is not valid. Far from it! But I do
believe it might be helpful to explore in more detail why you don't
simply run an early, low-function version of HTTP.

FWIW, I believe the answer is that you want some of the advanced
functions that have been added to HTTP over the years, but do not want
the full family of rich features that may chew memory and bandwidth.

---

What about the use of CoAP on the wider Internet?

---

A very minor terminology point from Section 1.2

   Confirmable Message
      Some messages require an acknowledgement.  These messages are
      called "Confirmable".  When no packets are lost, each Confirmable
      message elicits exactly one return message of type Acknowledgement
      or type Reset.

   Non-confirmable Message
      Some other messages do not require an acknowledgement.  This is
      particularly true for messages that are repeated regularly for
      application requirements, such as repeated readings from a sensor.

You have picked a form "confirmable" and "non-confirmable" tha expresses
the ability to do something: this message can be confirmed.

But you have mapped the form to a description that requires action: an
acknowledgement must be sent.

"Can be confirmed" != "A confirmation must be sent"
"Cannot be confirmed" != "A conformation does not need to be sent"

I don't believe this is too important because you are defining the tems,
but I do think that the casual reader will not embed your redefinitions
of normal English words, and so will be confused by these terms in the
text.

---

Section 1.2. Also a very minor point.

   Acknowledgement Message
      An Acknowledgement message acknowledges that a specific
      Confirmable Message arrived.  It does not indicate success or
      failure of any encapsulated request.

The fact that and Acknowledgement Message can carry a response is lost
in this definition. Maybe you need (including fixes to your typos)...

   Acknowledgement Message
      An Acknowledgement Message acknowledges that a specific
      Confirmable Message arrived.  Of itself, an Acknoweledgement
      Message does not indicate success or failure of any request
      encapsulated in the Confirmable Message, but the Acknoweledgement
      Message may also carry a Piggy-backed response (q.v.).

---

My feeling was that the Message IDs shown in figures 2 through 6 were
confusing in their randomness. For example, you could spend a lot of
time staring at figures 2 and 3 trying to work out how CON is encodeded
as 0x7d34 while NON is encoded as 0x01a0.

Since you want to show Message IDs to show how they correspond on
different parts of the flow, you could have written, e.g.,

                         Client              Server
                            |                  |
                            |   CON [MsgID1]   |
                            +----------------->|
                            |                  |
                            |   ACK [MsgID1]   |
                            |<-----------------+
                            |                  |

---

Section 2.1

   As CoAP is based on UDP, it also supports the use of multicast IP

I don't think it is based on UDP. I think it runs over UDP.

---

Section 2.3

   As CoAP was designed according to the REST architecture and thus

Maybe insert another pointer to [REST].

---

Section 4.2

   A Confirmable message
   always carries either a request or response and MUST NOT be empty,
   unless it is used only to elicit a Reset message.

That is a bit of an over-use of "MUST NOT". I think 

   A Confirmable message 
   always carries either a request or response, unless it is used only
   to elicit a Reset message in which case it is empty.

---

Section 4.2

   A CoAP endpoint that sent a Confirmable message MAY give up in
   attempting to obtain an ACK even before the MAX_RETRANSMIT counter
   value is reached: E.g., the application has canceled the request as
   it no longer needs a response, or there is some other indication that
   the CON message did arrive.  In particular, a CoAP request message
   may have elicited a separate response, in which case it is clear to
   the requester that only the ACK was lost and a retransmission of the
   request would serve no purpose.  However, a responder MUST NOT in
   turn rely on this cross-layer behavior from a requester, i.e. it
   SHOULD retain the state to create the ACK for the request, if needed,
   even if a Confirmable response was already acknowledged by the
   requester.

This paragraph is giving me some worries.

I think the initial MAY confuses the CoAP implementation with the 
endpoint containing the CoAP implementation.  The endpoint may give up,
and may instruct the CoAP implementation to stop retransmitting.  But I
think a CoAP implementaiton must not give up unless it is told to.


The drop from MUST NOT to SHOULD in the final sentence seems odd. My
understanding was that a CoAP implementation MUST always retain the 
state to create the ACK for the request.  Is this use of SHOULD a
relaxation, and how does it square with the MUST NOT?

---

Section 4.6

   Messages
   larger than an IP fragment result in undesired packet fragmentation.

s/undesired/undesirable/  ?

---

Section 4.6

   A CoAP message, appropriately encapsulated, SHOULD fit within a
   single IP packet (i.e., avoid IP fragmentation) and (by fitting into
   one UDP payload) obviously MUST fit within a single IP datagram.

s/MUST/will/

---

Section 12

I am surprised that IANA was relaxed about the use of "reserved" in 
Section 12. 

For example, in 12.1 you have two ranges marked "Reserved" without any
clue to what this means. For example, does it mean that allocations can
be made, that an RFC can dedicate them to a new use, or that they must
never be allocated?

In 12.1.2 you have 
   The Response Codes 96-127 are Reserved for future use.  All other
   Response Codes are Unassigned.
I take "Unassigned" to mean available for assignment according to the 
policy for the registry. But "Reserved or future use" means what?

In 12.2 you have 
                  |      0 | (Reserved)     |           |
This is the meaning of "reserved" I think we are used to, and means will
not be made available for allocation. (Although I am puzzled that you 
don't include the pointer to this RFC.)

Thank you for this important work and well written specification. While there are aspects that I would personally have done differently and some fine-tuning of the spec could continue, I believe the document is ready to move to an RFC. I also believe it that is a much-awaited spec and very useful to the Internet community in its current state.

I do agree with some of the points raised in other reviews, and those need to be addressed.

I did have one specific additional suggestion worth bringing up here. Dan Romascanu did a Gen-ART review and raised the issue that the parameter changes discussed in S4.8.1 are security sensitive, i.e., changes in the parameters may cause security/denial-of-service issues. This should be noted somewhere in the S11. I'd make a brief observation that it is security sensitive and should be addressed in any system that allows configuration of these parameters. 

Here's what Dan wrote:

3. Section 4.8 defines a number of CoAP protocol parameters and derived parameters that according to 4.8.1 may be changed. Some of these parameters have limitations and their changes may affect the basic functionality of the nodes, the interaction between nodes or between nodes and servers, as well as the functioning in constrained environments. However there is no risk analysis in Section 11 (Security Considerations) about the threats related to mis-configuration of the modes and un-appropriate or malevolent changes in these parameters, and recommendations of security counter-measures on this respect.

Thanks for addressing my more serious concerns. Nothing blocking, but for your consideration:

By section number:

4.2/4.3: "Reject" in the sense it is talked about in these sections is an internal state change. That's confusing to me, as the normal sense of the English word implies a party that "hears about" the rejection. (It's hard to me to think of a circumstance where someone or something was "rejected" and only the rejector ever knew about it.) In your use, "silently ignore" is one possible form of rejection. That's just weird.

If you're going to do this, I'd define the term up front. Maybe even capitalize "Reject" wherever you use it.

Either way, in both 4.2 and 4.3, "MUST reject" is probably wrong (since that's an internal state and nothing a protocol requirement is useful for) and "MAY involve sending" is a strange construction.

4.5: I think the MAYs confuse things and might encourage implementers to take that path. Instead of:

   This rule MAY be relaxed in case
   the Confirmable message transports a request that is idempotent (see
   Section 5.1) or can be handled in an idempotent fashion.  Examples
   for relaxed message deduplication:
   
I suggest: "Exceptions to this are when the Confirmable message transports a request that is idempotent (see Section 5.1) or can be handled in an idempotent fashion.  Examples of these exceptions:". Also:

   As a general rule that MAY be
   relaxed based on the specific semantics of a message, the recipient
   SHOULD silently ignore any duplicated Non-confirmable message, and
   SHOULD process any request or response in the message only once.
   
I suggest: "The recipient SHOULD silently ignore any duplicated Non-confirmable message, and SHOULD process any request or response in the message only once, though the specific semantics of the message might dictate an exception."

4.6: I feel like this section is really one big implementation note: Because it is a layer violation, it's not clear to me that any implementer has the ability to figure out much of this. (For example, the idea that an implementer would be willing to -- or even know how to -- set the Do Not Fragment bit or figure out the Path MTU is a bit hopeful.) I have no objection to this section, but it might be better as an implementation note rather than a set of protocol instructions.

5.3.2: Change "the client will likely send a Reset message so it does not receive any more retransmissions" to "the client will send". A client that has lost state that receives what it will see as a random CON message will always send back a Reset.

5.4.6: If it were me, I would have put the NoCacheKey bits in the high four bits of the most significant byte so that you could simply do a <224 test for cache-matching options. I suppose this ship has sailed.

5.5.1: The implementation note notwithstanding, I don't understand why Content-Format is not a SHOULD.

8.1:

   A server SHOULD be aware that a request arrived via multicast, e.g.
   by making use of modern APIs such as IPV6_RECVPKTINFO [RFC3542], if
   available.

That SHOULD is not meaningful. It is useful, not required with exceptions (as SHOULD indicates), for the server to know that it is using multicast.

This also gives a reason not to allow RST on *any* NON messages.

12.1: I think it would be much easier to figure these out if you separated out the bit fields of code type and code, and then had sub-registries for request codes, success codes, client error codes, and server error codes.

Overall, this is a very nicely written specification.  Thanks!  

In Section 2.2., are requests and responses in 1-1 correspondence?  Or can a single request receive more than one response?

In Section 3, why is version number 1 and not 0?  What's the plan here, do we get 3 or 4 versions out of this?

In Section 4.3, would it make sense to have something stronger than MAY for cases where future messages are likely to be screwed up, e.g., where CoAP syntax is malformed?  (A "STFU RST"?)

From Section 4.2 and 4.3, I generated a table mapping message types to request/response/empty:
            CON NON ACK RST
Request     X   X   ?   !
Response    X   X   X   !
Empty       !   !   X   X    
Might be helpful to include something like that as a summary.  This might be a bad idea, but: Did the WG consider allowing an ACK to contain a request?  In the case where a CON contains a response and the client wants to send another request, it would save a message to put the request in the ACK to the response.

Hey thanks for doing an excellent job addressing my comments.  Looking forward to progressing this one down the standards track ;)

On 5/20/2013 3:35 PM, Carsten Bormann wrote:
> Spencer,
> 
> thank you for this attentive review.
> I have done some of the changes as simple editorial fixes, these are
> marked like [1373] below and can be reviewed in
> http://trac.tools.ietf.org/wg/core/trac/changeset/1373
> (Overview in http://trac.tools.ietf.org/wg/core/trac/timeline).

Hi, Carsten,

Thank you for the quick and careful response. 

We've discussed my DISCUSS, so I'm changing my ballot position to YES (but please make Martin happy on his transport-ish DISCUSS :-). 

I have a couple of places where I've suggested text that seems clearer to me, but I moved these to COMMENTs on my ballot.

> Grüße, Carsten
> 
>          ----------------------------------------------------------------------
>          DISCUSS:
>          ----------------------------------------------------------------------
> 
>          Note that I plan to ballot Yes, after we resolve these questions.
> 
>          I have three points - the first one is the one I'm most curious about.
> 
>          In 4.8.1.  Changing The Parameters
> 
>            It is recommended that an
>            application environment use consistent values for these parameters.
> 
>          I'm thinking about this in an IOT/M2M context where it's somewhere
>          between inconvenient and impossible to change parameters on all the
>          deployed devices at once. I understand that configuring these parameters
>          is out of scope for the doc, so assume changing the parameters is out of
>          scope as well.
> 
> Yes.  The assumption is that implementations better don't start
> changing the parameters until there is a good way to do so.
> 
>          If you start deploying new devices into that environment with
>          significantly different parameters, is it more likely that performance
>          would suffer, or that something would break? (I don't care what the
>          answer is, I'd just like for the reader to have one - do you HAVE to get
>          the parameters right the first time, or do you WANT to get them right,
>          but you can deploy new devices with different parameters and let the old
>          devices be removed/replaced over time?)
> 
> The answer is different for each parameter and for the direction in
> which you change it.  I don't think we can provide all the definitive
> answers in this document.

For "changing the parameters" above ... I think what you're saying in your response to me is more helpful than the way I read the text in -16. If I'm understanding correctly, the situation is 

- the specification doesn't include a way to change parameters without a "flag day", and 

- if an application environment uses consistent parameters, everything will work, but 

- if an application environment doesn't use consistent parameters, what happens next is out of scope for this specification (and, for extra credit, is unpredictable)

As a COMMENT, I'd be more comfortable if 

     It is recommended that an
     application environment use consistent values for these parameters.

continued to say "Operation with inconsistent values in an application environment is outside the scope of this specification", or something like that. 

As an aside, also as a COMMENT ... I am now noticing that the specification has "recommended" in lower case. If you were telling me it's "RECOMMENDED = SHOULD = do it this way unless you're sure what you're doing, and if you think you know what you're doing, but you break it, you own it", I'd be more comfortable. That's consistent with the way I read this text in 2119:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course. 

>          This one is on the edge of being a Comment:
> 
>          In 5.10.5.  Max-Age
> 
>            The value is intended to be current at the time of transmission.
>            Servers that provide resources with strict tolerances on the value of
>            Max-Age SHOULD update the value before each retransmission.
> 
>          Will servers know that resources they serve have strict
>          tolerances?
> 
> Yes.  It is typically in the nature of a resource to be replaced
> periodically (e.g., the ECB exchange rate -- this has a very specific
> Max-Age) or be on a more unpredictable basis.  In the CoRE model,
> servers generally should be aware about the nature of the resources
> they are serving.
> 
>          The
>          answer may be "yes", I'm just asking. If not, I'm wondering if this
>          should be a MUST.
> 
> Because both the condition on the SHOULD and the desired behavior are
> very much local matter, a MUST won't have a much different outcome
> here.  Maybe the SHOULD should be turned into a non-RFC 2119
> implementation guidance recommendation.

Your explanation was very helpful to me. I'm fine with SHOULD as 2119 language here - that matches what I'm hearing you say.

>          This one is on the edge of being a comment:
> 
>          In 7.2.  Resource Discovery
> 
>            The discovery of resources offered by a CoAP endpoint is extremely
>            important in machine-to-machine applications where there are no
>            humans in the loop and static interfaces result in fragility.  A CoAP
>            endpoint SHOULD support the CoRE Link Format of discoverable
>            resources as described in [RFC6690].
> 
>          Is it obvious that this is a SHOULD? Is CoRE Link Format necessary for
>          resource discovery, or can you also accomplish this with humans if
>          they're in the loop? I'm just trying to wrap my head around "it's
>          extremely important but implementations might not do it".
> 
> This is more of a policy statement, a statement of expectation: If you
> want to be part of the CoRE ecosystem, do CoAP and do RFC 6690,
> because that will maximize interoperability.  So this may be another
> SHOULD abuse.  (But it does impact interoperability!)

This is very helpful. What I wasn't getting was whether there was any way other than CoRE Link Format to discover resources when there are no humans in the loop.

Again, as a COMMENT, I'm reading this response as "SHOULD support the CoRE Link Format of discoverable resources as described in [RFC6690] if there are no humans in the loop, to maximize interoperability". Am I getting that right? 

And if this is a statement of expectation, I'm OK with SHOULD, if the working group thinks that's appropriate.

>          ----------------------------------------------------------------------
>          COMMENT:
>          ----------------------------------------------------------------------
> 
>          I think this specification is well-written, it's important, and a lot of
>          people will need to read it - that's why I'm being picky on comments.
> 
>          Martin already has a DISCUSS about some of the more transport-ish topics
>          (support for UDP-lite, etc.). I'm sympathetic, but didn't restate them.
>          If Martin is happy, I'll be happy.
> 
>          In this text:
>            Constrained networks like
>            6LoWPAN support the expensive fragmentation of IPv6 packets into
>            small link-layer frames.
> 
>          Is "support" the right word here? I'm not understanding "support the
>          expensive fragmentation".
> 
> 6LoWPAN has a mechanism for ("supports") sending IPv6 packets that are
> larger than the link layer packet size.  This mechanism is expensive
> in the sense that it reduces performance similar to the way
> fragmentation often does.

So I should be reading this as something like "Constrained networks like 6LoWPAN support the fragmentation of IPv6 packets into small link-layer frames, but this mechanism is expensive in that it reduces performance"?

> 
>          In this text:
>            Although CoAP could be used for
>            compressing simple HTTP interfaces
> 
>          Is "compressing ... interfaces" the right way to say this?
> 
> No.  [1385]

Ack.

>          I've seen other reviewers mention "short messages" in "CoAP is based on
>          the exchange of short messages", but it may also be worth clearly
>          distinguishing "short message" from "SMS" ("short message service") - as
>          I understand it, the two phrases have nothing in common, but they are
>          both used in the document (at the beginning of Section 3, and even in the
>          same paragraph) without qualification.
> 
> Oh.  Good catch.  [1373]

Ack.

>            Response codes
>            correspond to a small subset of HTTP response codes with a few CoAP
>            specific codes added, as defined in Section 5.9.
> 
>          I get this, but I'm wondering if it's worth thinking about whether these
>          similar but unrelated namespaces can semi-collide (if HTTP is extended to
>          include a 328 response code, is it OK for CoAP to define a 3.28 response
>          code that means nothing like what HTTP 328 means?) Given that 404 and
>          4.04 are similar, for example, I'd expect some implementers to guess what
>          less common CoAP response codes are, based on HTTP response codes, rather
>          than check carefully. That's an obscure comment, but I thought I should
>          ask.
> 
> We already deviate from a strict one-to-one correspondence with HTTP
> (e.g., we have a 2.05 where HTTP uses 200).  So "correspond" may
> indeed be too strong.  [1386]

Ack.

>          In 6.4.  Decomposing URIs into Options, is "fail this algorithm" clear?
>          It might be a term of art for HTTP folk, but I'm not familiar with it.
> 
>            4.  If |url| has a <fragment> component, then fail this algorithm.
> 
> Indeed, this is hixiefied speak (right out of text in the versions of
> the websockets spec that were current when we wrote this, and still in
> HTML5).  It might be shorter to just say "fail", but the intent is not
> for the node to blow up in smoke, but to specifically fail the
> algorithm defined in this section (as explained in the introduction to
> 6.4).

No, I think you're doing this right (thanks for the clue!).

>          In 8.1.  Messaging Layer
> 
>            When a server is aware that a request arrived via multicast, it MUST
>            NOT return a RST in reply to NON.  If it is not aware, it MAY return
>            a RST in reply to NON as usual.
> 
>          Doesn't this tell me that the MUST NOT is not required for
>          interoperability? I'm only quibbling about the use of 2119
>          language.
> 
> This hand-waving is a reaction on a specific restriction of the POSIX API
> that I don't wish on anyone.  "Please avoid using RFC3542-challenged
> environments.  But if you have to (.NET?)..."
> 
>          On a
>          related point, if there was a sentence that started out "to keep Bad
>          Thing X from happening, ..." that would be helpful.
> 
> Good point.  [1387]

Ack. 

>          There's similar language in 8.2.  Request/Response Layer
> 
>            When a server is aware that a request arrived via multicast, the
>            server MAY always ignore the request, in particular if it doesn't
>            have anything useful to respond (e.g., if it only has an empty
>            payload or an error response).
> 
>          but MAY is pretty weak anyway (maybe "can always ignore the request", to
>          avoid the 2119 question?).
> 
> This is trying to say that the peer has to be able to cope with the
> "MAY"-type behaviour described, so it does affect interoperability and
> I think 2119 language is appropriate here.

I understand why you're using 2119 language now. I'm not sure I understand how the requirement for the peer is different from either the request or response getting lost.

I'm reading the spec as saying that multicast requests are sent as non-confirmable at the messaging layer, so if there's no confirmation at the messaging layer and no response from the server at the request/response layer, does the peer see any difference between hearing nothing back because something was lost, and hearing nothing back because the server had nothing to say?

>          In 11.3.  Risk of amplification
> 
>            This is particularly a problem in nodes that enable NoSec access,
>            that are accessible from an attacker and can access potential victims
>            (e.g. on the general Internet), as the UDP protocol provides no way
>            to verify the source address given in the request packet.  An
>            attacker need only place the IP address of the victim in the source
>            address of a suitable request packet to generate a larger packet
>            directed at the victim.  Such large amplification factors SHOULD NOT
>            be done in the response if the request is not authenticated.
> 
>          I don't understand what the SHOULD NOT means in practice. Is this saying
>          the server shouldn't return large resources for NoSec requests (whatever
>          "large" means), or ? If this is saying the same thing as the text on
>          using "slicing/blocking mode" two paragraphs, down, it would be clearer
>          to combine these points in a single paragraph.
> 
> Well, it is leading into it, and you just have to read one more
> paragraph before it comes...  (I'm still optimistic that at least some
> implementers read a whole section before writing code.)
> [ceterum censeo deploy BCP38...]

My apologies for not being clearer in my comment. 

I'm looking at this text:

   This is particularly a problem in nodes that enable NoSec access,
   that are accessible from an attacker and can access potential victims
   (e.g. on the general Internet), as the UDP protocol provides no way
   to verify the source address given in the request packet.  An
   attacker need only place the IP address of the victim in the source
   address of a suitable request packet to generate a larger packet
   directed at the victim.  Such large amplification factors SHOULD NOT
   be done in the response if the request is not authenticated.

[annoyingly distracting paragraph deleted here]

   A CoAP server can reduce the amount of amplification it provides to
   an attacker by using slicing/blocking modes of CoAP
   [I-D.ietf-core-block] and offering large resource representations
   only in relatively small slices.  E.g., for a 1000 byte resource, a
   10-byte request might result in an 80-byte response (with a 64-byte
   block) instead of a 1016-byte response, considerably reducing the
   amplification provided.

and I'm not seeing 

- the SHOULD NOT, which is conditional on whether the request is authenticated, and 

- the subsequent suggestion to use slicing/blocking, which is not conditional on authentication, seamlessly hooked together. 

Is the intention that the recommendation to use slicing/blocking be conditional on authentication, or should the server always use slicing/blocking whether the request is authenticated or not?

Is that clearer? ("writing text is hard" :-)

Spencer

Thanks for addressing my discuss points. I've left the comments
in below from last time, but didn't check 'em against -17.

--- former discuss points

(1) I think you made a change to 5.6 for this but I still
think (now at COMMENT level) that it'd be really good to say
that CoAP is currently well defined only for URI schemes like
coap(s) and http(s) but maybe not others. Basically, you need
a scheme://host:port syntax or else you have to do some more
specification work to get CoAP interop.

(3) You now say "SHOULD use 32 bits of randomness" which
is ok. I think it might be worth adding that CoAP nodes
that might be targetted with many guesses SHOULD also  
detect and react to that.

Text of discuss (3) was:
4.2, last para: this creates an attack that can work
from off-path - just send loads of faked ACKs with guessed
Tokens and some of 'em will be accepted with probability
depending on Token-length and perhaps the quality of the RNG
used by the sender of the CON. That could cause all sorts of
"interesting" application layer behaviour. Why is that ok?
(Or put another way - was this considered and with what
conclusion?) I suspect you need to have text trading off the
Token length versus use of DTLS or else CoAP may end up too
insecure for too many uses. (Note: the attack here is made
worse because the message ID comparison can be skipped.
Removing that "feature" would help a lot here.) 5.3.1's
client "may want to use a non-trivial, randomized token"
doesn't seem to cut it to me. How does this kind of
interaction map to DTLS sessions/epoch? Basically, I'd like
to see some RECOMMENDED handling of token length that would
result in it not being unsafe to connect a CoAP node to the
Internet. (And please note recent instances where 10's of
thousands of insecure devices have been found via probing
the IPv4 address space. These are real attacks.)
 
(4) 4.4, implementation note - this seems unwise since it
means that once Alice has interacted with Bob, then Bob can
easily guess the message IDs that Alice will use to talk to
Charlie. This is no longer a DISCUSS because you said that
the WG figure its ok and given you say to randomise at
the start (of what?) then its marginal. 

--- old comments below, sorta checked against -16 

intro, 2nd para: better to not talk about the WG name and
its work really, but about the resulting protocol

intro, last para: more sales pitch language

3: Message ID - with 16 bits that imposes a rate limit on
how often you can send. I don't think that's described and
I'm curious as to whether it'd set to max goodput for CoAP
that'd be way less than otherwise possible with e.g. HTTP.
- I think in a mail Carsten said its 250/second max or 
something, I still think this'd be great information to
say explicitly early on in the spec since it might prevent
someone spending a lot of effort before they find out that
CoAP doesn't work for their use-case.

7.1 - what if I want to only do discovery via DTLS? What
does "support" mean for port 5683 then? Carsten said that
you do need to still listen on 5683 even if you only
want to do work on <TBD>. I'm not so happy about that but
its not DISCUSS level.

12.7 - as it turns out I also don't see why this needs
two ports - the cost is two more bytes for security which
is significantly-enough less than the current cost (in
terms of message size) for security. Am I wrong? Carsten
responded: "yep, that's what we want" and I'm ok with that,
if not convinced.