[Ballot comment]
On 5/20/2013 3:35 PM, Carsten Bormann wrote:
> 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).

Hi, Carsten,

Thank you for the quick and careful response.

We've discussed my DISCUSS, so I'm changing my ballot position to YES (but please make Martin happy on his transport-ish DISCUSS :-).

I have a couple of places where I've suggested text that seems clearer to me, but I moved these to COMMENTs on my ballot.

> Grüße, Carsten
>
> ----------------------------------------------------------------------
> 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.
>
> Yes. The assumption is that implementations better don't start
> changing the parameters until there is a good way to do so.
>
> 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?)
>
> 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.

For "changing the parameters" above ... I think what you're saying in your response to me is more helpful than the way I read the text in -16. If I'm understanding correctly, the situation is

- the specification doesn't include a way to change parameters without a "flag day", and

- if an application environment uses consistent parameters, everything will work, but

- if an application environment doesn't use consistent parameters, what happens next is out of scope for this specification (and, for extra credit, is unpredictable)

As a COMMENT, I'd be more comfortable if

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

continued to say "Operation with inconsistent values in an application environment is outside the scope of this specification", or something like that.

As an aside, also as a COMMENT ... I am now noticing that the specification has "recommended" in lower case. If you were telling me it's "RECOMMENDED = SHOULD = do it this way unless you're sure what you're doing, and if you think you know what you're doing, but you break it, you own it", I'd be more comfortable. That's consistent with the way I read this text in 2119:

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

> 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?
>
> 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
> answer may be "yes", I'm just asking. If not, I'm wondering if this
> should be a MUST.
>
> 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.

Your explanation was very helpful to me. I'm fine with SHOULD as 2119 language here - that matches what I'm hearing you say.

> 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".
>
> 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!)

This is very helpful. What I wasn't getting was whether there was any way other than CoRE Link Format to discover resources when there are no humans in the loop.

Again, as a COMMENT, I'm reading this response as "SHOULD support the CoRE Link Format of discoverable resources as described in [RFC6690] if there are no humans in the loop, to maximize interoperability". Am I getting that right?

And if this is a statement of expectation, I'm OK with SHOULD, if the working group thinks that's appropriate.

> ----------------------------------------------------------------------
> 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".
>
> 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.

So I should be reading this as something like "Constrained networks like 6LoWPAN support the fragmentation of IPv6 packets into small link-layer frames, but this mechanism is expensive in that it reduces performance"?

>
> In this text:
> Although CoAP could be used for
> compressing simple HTTP interfaces
>
> Is "compressing ... interfaces" the right way to say this?
>
> No. [1385]

Ack.

> 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.
>
> Oh. Good catch. [1373]

Ack.

> 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.
>
> 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]

Ack.

> 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 component, then fail this algorithm.
>
> 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).

No, I think you're doing this right (thanks for the clue!).

> 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.
>
> 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
> related point, if there was a sentence that started out "to keep Bad
> Thing X from happening, ..." that would be helpful.
>
> Good point. [1387]

Ack.

> 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?).
>
> 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.

I understand why you're using 2119 language now. I'm not sure I understand how the requirement for the peer is different from either the request or response getting lost.

I'm reading the spec as saying that multicast requests are sent as non-confirmable at the messaging layer, so if there's no confirmation at the messaging layer and no response from the server at the request/response layer, does the peer see any difference between hearing nothing back because something was lost, and hearing nothing back because the server had nothing to say?

> 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.
>
> 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...]

My apologies for not being clearer in my comment.

I'm looking at this text:

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.

[annoyingly distracting paragraph deleted here]

A CoAP server can reduce the amount of amplification it provides to
an attacker by using slicing/blocking modes of CoAP
[I-D.ietf-core-block] and offering large resource representations
only in relatively small slices. E.g., for a 1000 byte resource, a
10-byte request might result in an 80-byte response (with a 64-byte
block) instead of a 1016-byte response, considerably reducing the
amplification provided.

and I'm not seeing

- the SHOULD NOT, which is conditional on whether the request is authenticated, and

- the subsequent suggestion to use slicing/blocking, which is not conditional on authentication, seamlessly hooked together.

Is the intention that the recommendation to use slicing/blocking be conditional on authentication, or should the server always use slicing/blocking whether the request is authenticated or not?

Is that clearer? ("writing text is hard" :-)

Spencer