Subject: [core] Adrian Farrel's Yes on draft-ietf-core-coap-15: (with COMMENT)

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 29 Apr 2013 07:34:51 -0700

Adrian Farrel has entered the following ballot position for
draft-ietf-core-coap-15: 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:
----------------------------------------------------------------------

I want to thank the authors and WG for producing this specification. I
think it may be one of the more important pieces of work in recent
years. As might be expected with a document of over 100 pages reviewed
by a pedant, I have a list of nits and worries. These are all enetered
as Comments: I hope you will find time to address them and make the
resulting RFC more polished, but none of them comes even close to a
requirement that you change the text, and I am ballotting Yes.

---

How quickly we forget!

I looked up the spec of a typical home computer around the time of HTTP
v1.0 and discovered that it was not so very different from what you are
scoping your environment to today.

That is not to say that your work is not valid. Far from it! But I do
believe it might be helpful to explore in more detail why you don't
simply run an early, low-function version of HTTP.

FWIW, I believe the answer is that you want some of the advanced
functions that have been added to HTTP over the years, but do not want
the full family of rich features that may chew memory and bandwidth.

---

What about the use of CoAP on the wider Internet?

---

A very minor terminology point from Section 1.2

   Confirmable Message
      Some messages require an acknowledgement.  These messages are
      called "Confirmable".  When no packets are lost, each Confirmable
      message elicits exactly one return message of type Acknowledgement
      or type Reset.

   Non-confirmable Message
      Some other messages do not require an acknowledgement.  This is
      particularly true for messages that are repeated regularly for
      application requirements, such as repeated readings from a sensor.

You have picked a form "confirmable" and "non-confirmable" tha expresses
the ability to do something: this message can be confirmed.

But you have mapped the form to a description that requires action: an
acknowledgement must be sent.

"Can be confirmed" != "A confirmation must be sent"
"Cannot be confirmed" != "A conformation does not need to be sent"

I don't believe this is too important because you are defining the tems,
but I do think that the casual reader will not embed your redefinitions
of normal English words, and so will be confused by these terms in the
text.

---

Section 1.2. Also a very minor point.

   Acknowledgement Message
      An Acknowledgement message acknowledges that a specific
      Confirmable Message arrived.  It does not indicate success or
      failure of any encapsulated request.

The fact that and Acknowledgement Message can carry a response is lost
in this definition. Maybe you need (including fixes to your typos)...

   Acknowledgement Message
      An Acknowledgement Message acknowledges that a specific
      Confirmable Message arrived.  Of itself, an Acknoweledgement
      Message does not indicate success or failure of any request
      encapsulated in the Confirmable Message, but the Acknoweledgement
      Message may also carry a Piggy-backed response (q.v.).

---

My feeling was that the Message IDs shown in figures 2 through 6 were
confusing in their randomness. For example, you could spend a lot of
time staring at figures 2 and 3 trying to work out how CON is encodeded
as 0x7d34 while NON is encoded as 0x01a0.

Since you want to show Message IDs to show how they correspond on
different parts of the flow, you could have written, e.g.,

                         Client              Server
                            |                  |
                            |   CON [MsgID1]   |
                            +----------------->|
                            |                  |
                            |   ACK [MsgID1]   |
                            |<-----------------+
                            |                  |

---

Section 2.1

   As CoAP is based on UDP, it also supports the use of multicast IP

I don't think it is based on UDP. I think it runs over UDP.

---

Section 2.3

   As CoAP was designed according to the REST architecture and thus

Maybe insert another pointer to [REST].

---

Section 4.2

   A Confirmable message
   always carries either a request or response and MUST NOT be empty,
   unless it is used only to elicit a Reset message.

That is a bit of an over-use of "MUST NOT". I think 

   A Confirmable message 
   always carries either a request or response, unless it is used only
   to elicit a Reset message in which case it is empty.

---

Section 4.2

   A CoAP endpoint that sent a Confirmable message MAY give up in
   attempting to obtain an ACK even before the MAX_RETRANSMIT counter
   value is reached: E.g., the application has canceled the request as
   it no longer needs a response, or there is some other indication that
   the CON message did arrive.  In particular, a CoAP request message
   may have elicited a separate response, in which case it is clear to
   the requester that only the ACK was lost and a retransmission of the
   request would serve no purpose.  However, a responder MUST NOT in
   turn rely on this cross-layer behavior from a requester, i.e. it
   SHOULD retain the state to create the ACK for the request, if needed,
   even if a Confirmable response was already acknowledged by the
   requester.

This paragraph is giving me some worries.

I think the initial MAY confuses the CoAP implementation with the 
endpoint containing the CoAP implementation.  The endpoint may give up,
and may instruct the CoAP implementation to stop retransmitting.  But I
think a CoAP implementaiton must not give up unless it is told to.

The drop from MUST NOT to SHOULD in the final sentence seems odd. My
understanding was that a CoAP implementation MUST always retain the 
state to create the ACK for the request.  Is this use of SHOULD a
relaxation, and how does it square with the MUST NOT?

---

Section 4.6

   Messages
   larger than an IP fragment result in undesired packet fragmentation.

s/undesired/undesirable/  ?

---

Section 4.6

   A CoAP message, appropriately encapsulated, SHOULD fit within a
   single IP packet (i.e., avoid IP fragmentation) and (by fitting into
   one UDP payload) obviously MUST fit within a single IP datagram.

s/MUST/will/

---

Section 12

I am surprised that IANA was relaxed about the use of "reserved" in 
Section 12. 

For example, in 12.1 you have two ranges marked "Reserved" without any
clue to what this means. For example, does it mean that allocations can
be made, that an RFC can dedicate them to a new use, or that they must
never be allocated?

In 12.1.2 you have 
   The Response Codes 96-127 are Reserved for future use.  All other
   Response Codes are Unassigned.
I take "Unassigned" to mean available for assignment according to the 
policy for the registry. But "Reserved or future use" means what?

In 12.2 you have 
                  |      0 | (Reserved)     |           |
This is the meaning of "reserved" I think we are used to, and means will
not be made available for allocation. (Although I am puzzled that you 
don't include the pointer to this RFC.)

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 30 Apr 2013 08:53:18 +0200

Adrian,

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

Grüße, Carsten

        ---

        How quickly we forget!

In the LWIG terminology document, we define our class 1 as ~ 10 KiB
RAM, ~ 100 KiB code.  This is more like a 1982 C64 than like a 1990
NeXT (the computer on which the Web started) and certainly not like
the mid-1990s home computer (486, Pentium!).

HTTP/TCP can be made to work on class 1 platforms with heroic efforts
and significant limitations.  Add security and some application
functionality, and it becomes difficult.  This is easier on a class 2
platform, as SEP 2.0 demonstrates.  Moore's law doesn't help as much
in the embedded space as it does in personal devices.

I'm sure there will be lots of articles describing the objectives in detail.
For a start, I can recommend http://dx.doi.org/10.1109/MIC.2012.29
and for some additional background, see our Paris IAB workshop paper
http://www.iab.org/wp-content/IAB-uploads/2011/04/Bormann.pdf
(I need to find time to complete this draft).

I think it is a bit difficult to try to obtain WG consensus on a piece
of text on why exactly HTTP/TCP doesn't cut it, so I hesitate to
expand the text in the spec.

        ---

CoAP has a number of problems in common with the DNS protocol that may
make both of them hard to use on the wider Internet.

More seriously speaking, we have tried to focus on the requirements of
the constrained node networks.  If CoAP works well for applications
that don't have those constraints, that makes us happy, but is not the
main objective.  Note that constrained node networks already want to
talk to the wider Internet, so enabling that is part of the objective.

The most important constraint of CoAP is the size of the Message ID,
which limits the goodput between two endpoints to about 250 messages
per second.  If that is not enough, alternative transport mappings
should be considered.  Those haven't been written up yet.

        ---

          Confirmable Message

          Non-confirmable Message

As a non-native speaker I'm well aware of this slight abuse.
It did seem expedient and it is not really wrong (you can ACK a
Confirmable, but not a Non-confirmable).  The other meaning is also
very much present in English: payable, taxable, ...
Most important, we never found a better word.

        ---

          Acknowledgement Message

          Acknowledgement Message

Yes!
I put it right in...  [1337]
(But I used "By itself", because that is easier to understand for me.)

        ---

                                Client              Server
                                   |                  |
                                   |   CON [MsgID1]   |
                                   +----------------->|
                                   |                  |
                                   |   ACK [MsgID1]   |
                                   |<-----------------+
                                   |                  |

I'm a big fan of concreteness.  We could then replace '/temperature'
with [URI] etc.  (There actually is a quick explanation of 0x7d34 as
an example in the reference to Figure 2, which I made slightly more
explicit.  I also added explanation in the reference to Figure 3.)
[1338]

        ---

        Section 2.1

[1338]

        ---

        Section 2.3

[1339]

        ---

        Section 4.2

          A Confirmable message

          A Confirmable message

[1340]

        ---

        Section 4.2

Well, we do talk about the endpoint giving up?
Specifically, we are also talking about the CoAP implementation
(message layer) giving up if it has another indication (from the
request/response layer) that the message did arrive.

The SHOULD is probably wrong.  This was meant as an implementation
method, allowing for others.  But the statement already is suitably
abstracted from the implementation method.
[1341]
Here we enter the area populated by FIN_WAIT_2 timeouts...
Maybe an RFC 6919 "MUST (BUT YOU KNOW YOU WON'T)" would be most appropriate.

        ---

        Section 4.6

          Messages

[1340]

        ---

        Section 4.6

        s/MUST/will/

did "s/MUST/needs to/" in [1305] based on Pete Resnick's similar comment.

        ---

        Section 12

No allocations can be made from reserved space.
But an RFC can update (or replace) this RFC, and unreserve the space.

There is no fundamental difference in effect between "reserved" and
"allocated by standards action".  However, the latter would mean we
have an idea how future standards might want to use the space.  We
don't, so the space is "reserved".  We don't even know what a policy
for allocation would be!

(Insert metacomment about cognitive dissonance caused by reserved
codepoints.  Space we can't use!  Actually, space that may turn out
useful in protocol evolution.)

        In 12.1.2 you have

No allocations can be made from reserved space.

        In 12.2 you have
                         |      0 | (Reserved)     |           |

The missing pointer is a bug.  [1342]

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 30 Apr 2013 14:42:59 +0100

Hello Carsten,

Just a few snips and responses, but nothing earth-shattering.

Adrian

> expand the text in the spec.

Hmmm, I might have thought that before starting out on CoAP there was some
consensus on why you were doing it :-)

> should be considered.  Those haven't been written up yet.

I think you might add some commentary. For example: 

While CoAP has been designed for use in constrained networks it may also be
applicable on the wider Internet although this is for future study.

> But an RFC can update (or replace) this RFC, and unreserve the space.

OK. I get it.
Might be clearer to have "Reserved: not to be allocated"

Cheers,
Adrian