Subject: [core] comments on draft-ietf-core-coap-06

From: [email-masked]
Date: Wed, 11 May 2011 13:42:06 -0400

Detailed comments in document order:

Abstract: "...a specialized web transfer protocol..."  CoAP is a pair of
protocols, one of which is a transfer protocol; cf. Section 2 and see
below.

Section 3.1. :  16-bit message ID will be insufficient.  Here is a
hypothetical but realistic example.  The physical layer is a RF mesh
network with a single-hop timeout of five minutes, such that a round trip
might take as much as ten minutes + slop.  A central actor (think an AMI
head-end system) polls a group of >= 65537 meters, transmitting one request
message every nine milliseconds.

Section 3.2. :  The option-number delta scheme is reminiscent of ISO 8583.
It complicates parser design significantly, in exchange for a very small
savings of bandwidth.

Section 4.1., third graf :  Somewhere in here, the strategy for handling
duplicate and orphan ACKs or RSTs should be defined explicitly.

Section 4.2., second graf :  "A sender MAY choose to transmit a
non-confirmable message multiple times which, for this purpose, specifies a
Message ID as well.  The same rules for generating the Message ID apply."
These two sentences, taken together, are entirely unclear.  I think you
mean that the retransmissions MUST have the same Message ID, but it is easy
to read the passage in the opposite sense.

Section 4.3.4. :  The example implies -- correctly! -- that the sole
purpose of RST is to indicate a failure within the protocol-terminating
component, such that the message cannot even be passed on to an
application.  In other words, RST is not to be used to report application
errors.  A well-formed message that is received and processed by an
application, but which (for example) contains nonsense actuals and is
therefore rejected by the application logic, would NOT be replied to with
an RST, but with an ACK with a response code in the > 128 range .  This is
the correct strategy and should be stated explicitly and prescriptively
here.

passim, the Token option :  The token is a correlator and may as well be
named so; the word "token" is nonspecific, but this thing has only one
purpose.  It is not clear why a correlator should be allowed to be up to
four times wider than the message ID.  Perhaps it is intended to be
potentially human-readable?

Section 5.2.2, second graf :  Grammar.  "The server may either initiate
...or immediately send..."

Section 5.3., last graf :  I would have expected the guidance to be at
least "SHOULD silently discard", if not MUST, as the RST is a security
leak.

Section 5.4.1., page 24, second bullet :  (Quite generally, a "must
understand" semantic is bad magic.)  This is, again, a security leak.  All
an attacker has to do is define an option with a high odd number and
collect his "human-readable" error message, from which lots of things
(implementation platform/tool chain, etc.) might be deducible.  Better to
say "bad option" and nothing more.  (This reasoning also applies to all of
the unhappy response codes defined in 5.9.2 and 5.9.3.  A debug mode,
including informative error messages, could be defined for trusted
environments, including field service using physically isolated ports.)

Global comments:

What is the problem?  Is it constrainedness, or it is connectedness, or is
it bandwidth, or it is some pair of those three, or is it all three?  I
have been lurking on the ZigBee mailing lists and it appears to me that the
problem with TCP in the ZigBee context is primarily a connectedness
problem.  TCP made very few assumptions for a thing of its kind, but the
assumptions it did make (of course, silently and unawares) have to do with
connectedness and the ZigBee scenarios are a poor fit with those
assumptions.

So: ZigBee sems to need an alternative to TCP at layer 4.  CoAP is two
protocols; let us call them Constrained Transfer Protocol (CoTP) and
Constrained Session Protocol (CoSP), where CoTP is the TCP replacement and
CoSP is the featherweight quasi-HTTP .  When you say that HTTP could ride
over CoAP, you are really saying that it could ride over CoTP; when you say
that CoAP could ride on top of TCP, you are really talking about CoSP.
These distinctions deserve to be made.

BUT: if connectedness is the problem, then CoAP versus TCP may be a tossup,
because CoAP assumes a competent name service and a lot of the
connectedness issues that arise in the ZigBee context seem to have to do
with name service over a semi-connected network.

The version field and the message ID both need to be wider and widening
them isn't going to have any crippling effects.

The option-numbering scheme is ugly.  I haven't taken the time to prove
this, but I think it is going to make it impossible to generate a parser
from an abstract grammar.  I wasn't able to generate a parser for ISO 8583
and I think you are going to have the same kind of problem.  (ISO 8583 has
a bitmask of possible options, then *some* of the options are length-tagged
and others are fixed-length.  You're not quite that badly off, but it is a
similar kind of thing.)

This is tied in with the two-bit (in all senses) version number, because
that is why you have to have the option registry.  Adding options is
versioning the protocol, but there can only ever be three versions of the
protocol and there will obviously be more than three new options added over
time.  Because CoAP breaks new ground, versioning the protocol must be easy
and safe.  The must-understand semantic is another needless complication
here; it prevents a clear understanding of compatible change.  But in any
case, factoring the options out into a registry doesn't help; adding an
option is still a version, because the option set is an enumerated type and
adding a value to an enumerated type is not a compatible change.

Thanks,

Frank Wilhoit
Information Architect
Enterprise Architecture and Strategy
American Electric Power
Direct Dial 614.716.3878
Audinet 8.200.3878

Scraping the bottom of a different barrel, since 1958.

---

From: Paul Duffy <[email-masked]>
Date: Wed, 11 May 2011 13:48:25 -0400

On 5/11/2011 1:42 PM, [email-masked] wrote:
> head-end system) polls a group of>= 65537 meters, transmitting one request

I also found the option-number delta scheme to be overly clever ;)

> an RST, but with an ACK with a response code in the>  128 range .  This is
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>