Last Call Review of draft-ietf-core-coap-14
review-ietf-core-coap-14-genart-lc-romascanu-2013-03-27-00

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

<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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:

Regards,

Dan