I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on appsdir, please see ​ 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.

Please note, that as this is an early AppsDir review, I only cc'ed the 
two Apps ADs, but not the IESG to this email.

Document: draft-ietf-core-coap-13
Title: Constrained Application Protocol (CoAP)
Reviewer: Tobias Gondrom
Review Date: 27.12.2012
State: in WGLC

Summary:
This draft will have major impact on the underlying infrastructure of 
lossy networks using coap. The draft is nearly ready for IETF LC, there 
are a few suggestions I would make.


Some thoughts:
section 1.2

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
where eventual success is sufficient.

The assumption that eventual success will happen is not necessarily 
correct.
It is rather: success is not critical for the sender node (nor could it 
change it's behaviour) based on that information. In the end even 
eventual success can not be guaranteed.


Comments/Questions:
- section 3.0 and section 4.3: "The payload data extends from after the 
marker to the end of the UDP datagram"
Is there a need for CoAP payloads across multiple UDP packets?
(see also rfc540 section 3.2 Message Size Guidelines and for IPv4 UDP 
max packet size of 65,507 bytes)
I fully understand the fact we want to avoid fragmentation.
The question would be, is there an application need for asynchronous 
larger message sizes assembled over time across different UDP packets in 
the form of CON packets.
Especially considering that maybe one packet is limited to <576bytes as 
outlined in section 4.3?


- considering that we assume a lossy network and repeated sending and 
don't really have a "session", is an 8byte token enough?
Even though I appreciate that it is not for security purposes as you 
MUST use a secure channel binding for that instead, I wonder, whether 
the fact that we don't have a a session ID and potentially infinite 
lifetimes of the CON message (as being resend), is it important that we 
increase the space beyond 8bytes?
(to avoid (or make it harder) spoofing and flooding attacks to spoof a 
confirm or a reset/? E.g. an attacker sending an 8-byte burst to cover 
every token over time.)

section 5.5:
"In the absence of this option, no default value is assumed and the 
format will need to be inferred by the application (e.g., from the 
application context or by "sniffing" the payload)."
As we have seen quite a bit of trouble with "sniffing" in http content 
types, you may want to be more strict and make it clear that sniffing 
SHOULD (or MUST) only apply if no content type is given. Also consider 
that unlike most web scenarios this is M2M and there is no human 
interaction that could make any deviating judgement calls.

section 5.9 Response Code Definitions:
I notice the absence of code 30x responses.
Why is that? Especially a redirect (e.g. to allow to switch to DTLS) 
seems important in this case?

section 9 Securing CoAP:
does Coap need to be able to determine which type of DTLS is in use?
(in which case mapping all three secure cases to coaps may not be 
sufficient for that distinction on the coap application layer?

Considering the weak security properties and large number of attack 
vectors (ncluding section 11.3, etc.) of non-secure coap,
the I-D should consider to write a "SHOULD use coaps whenever possible" 
in that section.

Why do you "hard-code" MUST support of 
"TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8"?
If it (the algs or AES128 or...) is ever not sufficiently secure anymore 
that would constitute a security weakness in the protocol.


section 11.3
"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."

Although the following paragraph already put a "SHOULD" on 
authentication, it might be worth mentioning here as well, that any 
large amplification factors should only be done in the reponse if the 
the request is authenticated (i.e. using coaps).

Section 11.4.
this section is in fact very important (as we don't have some of the 
stabilising factors of a TCP/HTTP session here), and you may want to 
consider to also the "SHOULD use authentication" here?


Nits:
 From a naming perspective:
Safe/Unsafe Option might be better called "safe-forward option" or 
"unsafe-forward option"?

References:
you may want to add a reference to UDP (and DTLS)?

section 6.3
in case you wish, you could use informative reference to the Web Origin 
Concept rfc6454

Best regards, Tobias