Subject: [Gen-art] Gen-ART review for draft-ietf-core-coap-14

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 27 Mar 2013 13:33:09 +0000

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 28 Mar 2013 16:26:41 +0100

Hi Dan,

thanks for the review.
We will be looking into these points in more detail in the next few days.

One of your comments can be addressed immediately:

>> appropriate for this action.

The UDP port number for CoAP was assigned a couple of months before RFC 6335 was published.  The assignment is recorded in http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml as follows:

  <record date="2011-06-13">
    <name>coap</name>
    <protocol>udp</protocol>
    <xref type="draft" data="draft-ietf-core-coap"/>
    <description>Constrained Application Protocol</description>
    <number>5683</number>
  </record>

The assignment was initiated by one of the authors, Klaus Hartke, on Jan 25, 2011.
We were in need of a stable port for the significant interop testing going on and didn't want to continue squatting on a port.
The allocation maybe took a bit longer at the time due to the uncertainty created by the transition to RFC 6335, and was shepherded along by the responsible AD at the time, Peter Saint-Andre.

The port number we were assigned wasn't a reserved one (such as 0, 1023, or 49151 would have been), but a previously unassigned one.
When we received the assignment, we were also advised:

> Your request has been processed.  We have assigned the following
> UDP port to coap as per the I-D.ietf-core-coap:
> 
> coap            5683/udp   Constrained Application Protocol
> #                          [I-D.ietf-core-coap] 13 June 2011
> 
> See: http://www.iana.org/assignments/port-numbers
> 
> When the internet draft is approved for publication as an RFC, IANA will
> be notified to change the draft string to RFC number.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 28 Mar 2013 16:46:28 +0100

A couple more comments (this time with an author hat on):

> 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 l…

3.  Message Format

   CoAP is based on the exchange of short messages which, by default,
   are transported over UDP (i.e. each CoAP message occupies the data
   section of one UDP datagram).  CoAP may also be used over Datagram
   Transport Layer Security (DTLS) (see Section 9.1).  It could also be
   used over other transports such as SMS, TCP or SCTP, the
   specification of which is out of this document's scope.

In the end, what transport is used is implied by the URI, so I wouldn't even go so far as considering UDP to be a "mandatory" transport (although in practice completely getting rid of the default UDP mapping may require DTLS to gain multicast capability).

> 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 sect…

A draft is nearing completion in LWIG that is defining these and other terms relevant to this field.

  "Terminology for Constrained Node Networks", Carsten Bormann, Mehmet
  Ersue, 25-Feb-13, <draft-ietf-lwig-terminology-01.txt>

We should reference this as an informative reference.

> 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 'resour…

Indeed.  For this central term, we could simply make more explicit the reference to RFC 2616.

(Section 1.2 says:
   This specification requires readers to be familiar with all the terms
   and concepts that are discussed in [RFC2616].  [...]

We could expand this into:
   This specification requires readers to be familiar with all the terms
   and concepts that are discussed in [RFC2616], including "resource", "representation", 
   "cache", and "fresh".  [...]
)

> 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 cal…

We were trying to avoid on-the-wire values that could be confused with the UDP payloads of STUN or DTLS.
This is generally a good strategy for diagnostic and debugging purposes.
(If need be, we can always wrap around the version number and represent 4 as 0b00.
We could even allocate more bits for the version number in version 2 upwards.
However, the protocol has a number of well-defined extension points apart from the version number, so I would consider it unlikely that we will arrive at this need.)

Grüße, Carsten