Last Call Review of draft-ietf-core-coap-14

Request Review of draft-ietf-core-coap
Requested rev. no specific revision (document currently at 18)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-03-27
Requested 2013-03-14
Authors Zach Shelby, Klaus Hartke, Carsten Bormann
Draft last updated 2013-03-27
Completed reviews Genart Last Call review of -14 by Dan Romascanu (diff)
Genart Last Call review of -15 by Dan Romascanu (diff)
Genart Telechat review of -16 by Dan Romascanu (diff)
Secdir Last Call review of -14 by Alexey Melnikov (diff)
Assignment Reviewer Dan Romascanu 
State Completed
Review review-ietf-core-coap-14-genart-lc-romascanu-2013-03-27
Reviewed rev. 14 (document currently at 18)
Review result Almost Ready
Review completed: 2013-03-27


I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at


Please resolve these comments along with any other Last Call comments you may receive.

Document: draft-ietf-core-coap-14
Reviewer: Dan Romascanu
Review Date: 3/27/2013
IETF LC End Date: 3/27/2013
IESG Telechat date: 

Summary: This document is almost ready. Clarification of the issues raised below is recommended. 

Major issues:

1. I could not find at any place in this document a dull mention of the transport mapping on UDP and of the fact that a node supporting CoAP MUST support UDP. On the contrary, in several places a language used mentions a 'datagram-oriented transport such as UDP'. This is somehow intriguing, I am missing a more specific definition of the mandatory transport. 

2 . The WG charter says: 

> 7) Consider operational and manageability aspects of the protocol and at
> a minimum provide a way to tell if a Device is powered on or not.

There is no mention in the protocol document (or other documents in core) about manageability and operational considerations. Maybe some work is being prepared, although I saw no core documents dealing with it. I believe that it would be good for the document to include either an Operational and Manageability Considerations section as recommended by RFC 5706 or, a short informational 'Future Work' section or appendix that mentions the need to deal with the operational and manageability aspects, and possibly point to work already done in the IETF for example on the coman mail list concerning management of constrained networks.

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. 
Minor issues:

1. The WG charter says: 

> The WG will coordinate on requirements from many organizations including
> OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI,
> ASHRAE/BACnet; other SDOs and organizations.

I am wondering whether the listed organizations were informed about the IETF conducting the Last Call on the protocol document. Maybe I missed some messages, but I see no feedback in the archives of the WG or IETF lists, or in the liaison statements page reflecting such interaction. 

2. The terms of 'constrained node' and 'constrained network' are widely used but never defined in this document (but by example in the introduction). I would suggest to include a definition in section 1.2 (Terminology) or a reference if proper definitions can be found some place else.  

3. It would be good to define in section 1.2 (Terminology) or provide a reference for the term of 'resource' as this specification used it (again, defined only by example when talking about 'resource discovery')

4. Section 3 - is there any special reason for the Version (Ver) field to start with the value 1 for this version? For a two-bit field this seems a waste we would rather avoid. Nothing prevents calling this version of CoAP 'version 1' and code it 00 on the wire. 

5. Section 12.6 

> IANA has assigned the port number 5683 and the service name "coap",
> in accordance with [RFC6335].

It is unclear to me when was this assignment made and were it is recorded (if not in this document). RFC 6335, section 8.1 says: 

> Reserved numbers and names are generally only assigned by a
> "Standards Action" or "IESG Approval", and MUST be accompanied by
> a statement explaining the reason a Reserved number or name is
> appropriate for this action.

Nits/editorial comments: