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

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 20 May 2013 23:16:04 -0700

Spencer Dawkins 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:
----------------------------------------------------------------------

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 <fragment> 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

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 25 May 2013 23:34:29 +0200

Hi Spencer,

thank you for clearing your DISCUSS early.
The chart looks much more hope-inspiring with only four DISCUSSes :-)

I believe your remaining comments are covered by the changesets 1393 to 1396 (which will turn up in -17 soon); with maybe one exception:

> request or response getting lost.

The main difference is that retransmission/saturation is a good strategy against random packet loss, but not
against willful disregard.  So it is important to point out this expected behavior.

Grüße, Carsten

---

From: Spencer Dawkins <[email-masked]>
Date: Sat, 25 May 2013 18:19:13 -0500

On 5/25/2013 4:34 PM, Carsten Bormann wrote:

Notice: you're deep into AD Education Mode, and I've already balloted 
YES, and I'm not planning to be That Guy who ballots a second DISCUSS on 
a document from his first telechat as an AD :p

But let's assume that you're still reading ...

> against willful disregard.  So it is important to point out this expected behavior.

OK, that helps.

I may not be asking my question in a helpful way. Let me try again -

Is the peer expected to deal with random packet loss (whether lost 
requests or lost responses), and expected to deal with a server who 
(MAY) ignores a request?

What does the peer see, if the server decides to (MAY) ignore the 
request (because it came in as multicast, if I'm understanding 
correctly), that's different from random packet loss?

If the peer sees something different, what the document is saying makes 
sense. If the peer doesn't see something different, I'm not 
understanding what's going on.

Is that clearer?

Thanks,

Spencer

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 26 May 2013 20:48:21 +0200

On May 26, 2013, at 01:19, Spencer Dawkins <[email-masked]> wrote:

> Notice: you're deep into AD Education Mode, and I've already balloted YES, and I'm not planning to be That Guy who ballots a second DISCUSS on a document from his first telechat as an AD :p
> 
> Is the peer expected to deal with random packet loss (whether lost requests or lost responses), and expected to deal with a server who (MAY) ignores a request?

Yes, yes.
"deal with" is maybe a bit ambiguous.
The client is likely to factor in the random packet loss by repeating the request, either regularly (say, every 30 minutes) or, if filling in the gaps needs to be quicker, as a short saturation burst (at 1 byte/s).

The client needs to factor in the refusal to answer by asking questions that servers do want to answer.
Completely different strategy.

> What does the peer see, if the server decides to (MAY) ignore the request (because it came in as multicast, if I'm understanding correctly), that's different from random packet loss?

For random loss, the client may see 1 answer for 3 requests.  For refusal, it won't see anything.
For a new request, the client will likely not know about the servers that don't answer, so it can't see a difference.
Hence repetition/saturation.
(If it does know about a server, it is much better off to address it via unicast.)

> If the peer sees something different, what the document is saying makes sense. If the peer doesn't see something different, I'm not understanding what's going on.

The likelihood of seeing all servers that do answer goes to 1 asymptotically with continued repetition (unless there are systematic losses, which I hope is not a property of the multicast distribution system).  The likelihood of seeing a server that just doesn't answer stays at 0.

Grüße, Carsten

---

From: Spencer Dawkins <[email-masked]>
Date: Sun, 26 May 2013 17:12:50 -0500

> (If it does know about a server, it is much better off to address it via unicast.)

I finally managed to ask a question that resulted in this answer :-)

Makes perfect sense. No action required on this one.

Spencer