Subject: [core] Spencer Dawkins' Discuss on draft-ietf-core-coap-16: (with DISCUSS and COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 15 May 2013 10:47:18 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-core-coap-16: Discuss

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.

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Note that I plan to ballot Yes, after we resolve these questions. 

I have three points - the first one is the one I'm most curious about. 

In 4.8.1.  Changing The Parameters

   It is recommended that an
   application environment use consistent values for these parameters.

I'm thinking about this in an IOT/M2M context where it's somewhere
between inconvenient and impossible to change parameters on all the
deployed devices at once. I understand that configuring these parameters
is out of scope for the doc, so assume changing the parameters is out of
scope as well.

If you start deploying new devices into that environment with
significantly different parameters, is it more likely that performance
would suffer, or that something would break? (I don't care what the
answer is, I'd just like for the reader to have one - do you HAVE to get
the parameters right the first time, or do you WANT to get them right,
but you can deploy new devices with different parameters and let the old
devices be removed/replaced over time?)

This one is on the edge of being a Comment: 

In 5.10.5.  Max-Age

   The value is intended to be current at the time of transmission.
   Servers that provide resources with strict tolerances on the value of
   Max-Age SHOULD update the value before each retransmission.

Will servers know that resources they serve have strict tolerances? The
answer may be "yes", I'm just asking. If not, I'm wondering if this
should be a MUST.

This one is on the edge of being a comment: 

In 7.2.  Resource Discovery

   The discovery of resources offered by a CoAP endpoint is extremely
   important in machine-to-machine applications where there are no
   humans in the loop and static interfaces result in fragility.  A CoAP
   endpoint SHOULD support the CoRE Link Format of discoverable
   resources as described in [RFC6690].

Is it obvious that this is a SHOULD? Is CoRE Link Format necessary for
resource discovery, or can you also accomplish this with humans if
they're in the loop? I'm just trying to wrap my head around "it's
extremely important but implementations might not do it".

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

I think this specification is well-written, it's important, and a lot of
people will need to read it - that's why I'm being picky on comments.

Martin already has a DISCUSS about some of the more transport-ish topics
(support for UDP-lite, etc.). I'm sympathetic, but didn't restate them.
If Martin is happy, I'll be happy. 

In this text:
   Constrained networks like
   6LoWPAN support the expensive fragmentation of IPv6 packets into
   small link-layer frames.

Is "support" the right word here? I'm not understanding "support the
expensive fragmentation".

In this text:
   Although CoAP could be used for
   compressing simple HTTP interfaces

Is "compressing ... interfaces" the right way to say this?

I've seen other reviewers mention "short messages" in "CoAP is based on
the exchange of short messages", but it may also be worth clearly
distinguishing "short message" from "SMS" ("short message service") - as
I understand it, the two phrases have nothing in common, but they are
both used in the document (at the beginning of Section 3, and even in the
same paragraph) without qualification.

   Response codes
   correspond to a small subset of HTTP response codes with a few CoAP
   specific codes added, as defined in Section 5.9.

I get this, but I'm wondering if it's worth thinking about whether these
similar but unrelated namespaces can semi-collide (if HTTP is extended to
include a 328 response code, is it OK for CoAP to define a 3.28 response
code that means nothing like what HTTP 328 means?) Given that 404 and
4.04 are similar, for example, I'd expect some implementers to guess what
less common CoAP response codes are, based on HTTP response codes, rather
than check carefully. That's an obscure comment, but I thought I should
ask.

In 6.4.  Decomposing URIs into Options, is "fail this algorithm" clear?
It might be a term of art for HTTP folk, but I'm not familiar with it.

   4.  If |url| has a <fragment> component, then fail this algorithm.

In 8.1.  Messaging Layer

   When a server is aware that a request arrived via multicast, it MUST
   NOT return a RST in reply to NON.  If it is not aware, it MAY return
   a RST in reply to NON as usual.

Doesn't this tell me that the MUST NOT is not required for
interoperability? I'm only quibbling about the use of 2119 language. On a
related point, if there was a sentence that started out "to keep Bad
Thing X from happening, ..." that would be helpful.

There's similar language in 8.2.  Request/Response Layer

   When a server is aware that a request arrived via multicast, the
   server MAY always ignore the request, in particular if it doesn't
   have anything useful to respond (e.g., if it only has an empty
   payload or an error response).

but MAY is pretty weak anyway (maybe "can always ignore the request", to
avoid the 2119 question?).

In 11.3.  Risk of amplification

   This is particularly a problem in nodes that enable NoSec access,
   that are accessible from an attacker and can access potential victims
   (e.g. on the general Internet), as the UDP protocol provides no way
   to verify the source address given in the request packet.  An
   attacker need only place the IP address of the victim in the source
   address of a suitable request packet to generate a larger packet
   directed at the victim.  Such large amplification factors SHOULD NOT
   be done in the response if the request is not authenticated.

I don't understand what the SHOULD NOT means in practice. Is this saying
the server shouldn't return large resources for NoSec requests (whatever
"large" means), or ? If this is saying the same thing as the text on
using "slicing/blocking mode" two paragraphs, down, it would be clearer
to combine these points in a single paragraph.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 20 May 2013 22:35:44 +0200

Spencer,

thank you for this attentive review.
I have done some of the changes as simple editorial fixes, these are
marked like [1373] below and can be reviewed in
http://trac.tools.ietf.org/wg/core/trac/changeset/1373
(Overview in http://trac.tools.ietf.org/wg/core/trac/timeline).

Grüße, Carsten

Yes.  The assumption is that implementations better don't start
changing the parameters until there is a good way to do so.

The answer is different for each parameter and for the direction in
which you change it.  I don't think we can provide all the definitive
answers in this document.

        In 5.10.5.  Max-Age

        Will servers know that resources they serve have strict
        tolerances?

Yes.  It is typically in the nature of a resource to be replaced
periodically (e.g., the ECB exchange rate -- this has a very specific
Max-Age) or be on a more unpredictable basis.  In the CoRE model,
servers generally should be aware about the nature of the resources
they are serving.

        The

Because both the condition on the SHOULD and the desired behavior are
very much local matter, a MUST won't have a much different outcome
here.  Maybe the SHOULD should be turned into a non-RFC 2119
implementation guidance recommendation.

This is more of a policy statement, a statement of expectation: If you
want to be part of the CoRE ecosystem, do CoAP and do RFC 6690,
because that will maximize interoperability.  So this may be another
SHOULD abuse.  (But it does impact interoperability!)

        In this text:

6LoWPAN has a mechanism for ("supports") sending IPv6 packets that are
larger than the link layer packet size.  This mechanism is expensive
in the sense that it reduces performance similar to the way
fragmentation often does.

        In this text:

No.  [1385]

Oh.  Good catch.  [1373]

          Response codes

We already deviate from a strict one-to-one correspondence with HTTP
(e.g., we have a 2.05 where HTTP uses 200).  So "correspond" may
indeed be too strong.  [1386]

Indeed, this is hixiefied speak (right out of text in the versions of
the websockets spec that were current when we wrote this, and still in
HTML5).  It might be shorter to just say "fail", but the intent is not
for the node to blow up in smoke, but to specifically fail the
algorithm defined in this section (as explained in the introduction to
6.4).

        In 8.1.  Messaging Layer

        Doesn't this tell me that the MUST NOT is not required for
        interoperability? I'm only quibbling about the use of 2119
        language.

This hand-waving is a reaction on a specific restriction of the POSIX API
that I don't wish on anyone.  "Please avoid using RFC3542-challenged
environments.  But if you have to (.NET?)..."

        On a

Good point.  [1387]

This is trying to say that the peer has to be able to cope with the
"MAY"-type behaviour described, so it does affect interoperability and
I think 2119 language is appropriate here.

Well, it is leading into it, and you just have to read one more
paragraph before it comes...  (I'm still optimistic that at least some
implementers read a whole section before writing code.)
[ceterum censeo deploy BCP38...]