Subject: [core] draft-ietf-core-coap-09 review

From: Ari Keranen <[email-masked]>
Date: Fri, 20 Apr 2012 17:44:44 +0300

Hi,

Here's a set of review comments on the coap-09 draft.

Cheers,
Ari

1.2.  Terminology

     Elective Option
        An option that is intended be ignored by an end-point that does
        not understand it, which nonetheless still can correctly process
        the message (Section 5.4.1).

This was a bit confusing. Perhaps rephrase into something like:

   An option that is intended to be ignored by an end-point that does 
not understand it. Even without understanding the option the end-point 
can still correctly process the message (Section 5.4.1).

2.  Constrained Application Protocol

     The basic exchanges of the four types of
     messages are transparent to the request/response interactions.

What this means is not clear. I'd rephrase or remove this sentence.

2.2.  Request/Response Model

          Figure 4: Two GET requests with piggy-backed responses, one
                           successful, one not found

s/one not found/one resulting in a "not found" error/  (right?)

     (Note
     that the detailed semantics of CoAP methods are "almost, but not
     entirely unlike" those of HTTP methods:

Should this be "like" instead of "unlike"?

3.1.  Message Format

        If set to 15, then the number of options is unlimited, and an
        end-of-options marker is used to indicate no more options.

"unlimited" sounds quite strange here, how about:
s/number of options is unlimited, and an end-of-options marker is used 
to indicate no more options/number of options is not indicated in the 
header but instead with an end-of-options marker (Section 3.2)/

Also in section 3.2. "unlimited" is used in this context.

     Message ID:  16-bit unsigned integer.  Used for the detection of

Even if the Message ID is in practice an opaque bit string (right?), you 
could end up with byte-order problems (say, two different 
implementations print the value differently and then someone compares 
the printed values); better to say explicitly that the ID is "in network 
byte order".

3.2.  Option Format

        The Option Numbers 14, 28, 42,
        ... are reserved for no-op options when they are sent with an
        empty value (they are ignored) and can be used as "fenceposts"

Maybe this would be better as "The Option Numbers that are multiples of 
14 (i.e., 14, 28, 42, ...) are reserved [...]"
Also, how about those options with non-empty value? How should one react 
(ignore option, drop message, error response)?

4.1.  Reliable Messages

     The Message ID is a 16-bit unsigned integer that is
     generated by the sender of a confirmable message and included in the
     CoAP header.

The rules being same for CON and NON messages, saying here explicitly 
that the sender of *CON* messages generates the ID is a bit odd. Perhaps 
the whole ID generation discussion should be earlier in the doc, e.g., 
in section 4 or 3.1. since it applies to both types.

4.2.  Unreliable Messages

    A sender MAY choose to transmit a non-
    confirmable message multiple times which, for this purpose, specifies
    a Message ID as well.

Hard to parse this. The sender specifies the Message ID, or the fact 
that one chooses to transmit confirmable message multiple times does? 
Also, see the previous comment (is it necessary to talk about the ID here?).

4.4.1.  Confirmable (CON)

    A confirmable message always carries either a request or response and
    MUST NOT be empty.

How to react to empty CON and NON messages?

5.2.2.  Separate

    For a separate exchange, both the acknowledgement to the confirmable
    request and the acknowledgement to the confirmable response MUST be
    an empty message, i.e. one that carries neither a request nor a
    response.

Should the receiver still consider non empty (but otherwise OK) ACK as a 
valid ACK or keep retransmitting?

5.5.  Payload

    Its format is specified by the Internet media type
    given by the Content-Type Option.  No default value is assumed in the
    absence of this option.

..but the content type must be inferred from the context by the application?

5.7.  Proxying

    All options present in a proxy request MUST be processed at the
    proxy.

But not be forwarded?

    If the request to the
    destination returns an response that cannot be processed by the
    proxy [...]

What would qualify as "cannot be processed"? Unrecognized options? 
Malformed response?

6.2.  coaps URI Scheme

    Resources made available via the "coaps" scheme have no shared
    identity with the "coap" scheme even if their resource identifiers
    indicate the same authority (the same host listening to the same UDP
    port).

Is it OK to have coap and coaps URIs pointing to the same UDP port on 
the same host (i.e., run DTLS and plain CoAP in the same port)? The text 
seems to imply so.

10.  Security Considerations

I'd consider moving sections 10-10.2. out of the "Security 
Considerations" and into a section of their own (called something like 
"Securing CoAP") and make just the section 10.3. the Security 
Considerations. The text in 10-10.2. looks like "regular specification 
text" whereas 10.3. is what I'd expect to see in Security Considerations.

10.1.3.  Certificate Mode

    Implementations in Certificate Mode MUST support the mandatory to
    implement cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as
    specified in [RFC5246].

RFC5246 doesn't contain string "TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8". Add 
at least reference to the right section(s) in RFC5246 and preferably 
split the cipher suite name in relevant parts to make it clear what 
actually should be implemented.

11.  IANA Considerations

I'd suggest "IETF Review or IESG Approval" as the policy for the 
registries. This way also also non-standards-track RFCs and documents 
from other SDOs could get values, if IESG thinks it makes sense.

11.3.  Media Type Registry

Why are the current IDs allocated so sparsely? Is the idea to group 
similar types with adjacent IDs? Should the reason/policy be mentioned here?