Subject: [core] Jari Arkko's Yes on draft-ietf-core-coap-16: (with COMMENT)

From: "Jari Arkko" <[email-masked]>
Date: Thu, 16 May 2013 06:51:40 -0700

Jari Arkko has entered the following ballot position for
draft-ietf-core-coap-16: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for this important work and well written specification. While
there are aspects that I would personally have done differently and some
fine-tuning of the spec could continue, I believe the document is ready
to move to an RFC. I also believe it that is a much-awaited spec and very
useful to the Internet community in its current state.

I do agree with some of the points raised in other reviews, and those
need to be addressed.

I did have one specific additional suggestion worth bringing up here. Dan
Romascanu did a Gen-ART review and raised the issue that the parameter
changes discussed in S4.8.1 are security sensitive, i.e., changes in the
parameters may cause security/denial-of-service issues. This should be
noted somewhere in the S11. I'd make a brief observation that it is
security sensitive and should be addressed in any system that allows
configuration of these parameters. 

Here's what Dan wrote:

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.