Subject: [core] Pete Resnick's Discuss on draft-ietf-core-coap-17: (with DISCUSS and COMMENT)

From: "Pete Resnick" <[email-masked]>
Date: Mon, 27 May 2013 17:05:50 -0700

Pete Resnick has entered the following ballot position for
draft-ietf-core-coap-17: 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:
----------------------------------------------------------------------

I'm still worried about 5.10.4:

                                                      The server SHOULD
   return the preferred Content-Format if available.  If the preferred
   Content-Format cannot be returned, then a 4.06 "Not Acceptable"
   SHOULD be sent as a response.

The possibility that a server could potentially not send back a 4.06
seems really problematic from a client perspective. I have no way as a
client to say, "I really can only accept format X, and if you can't make
format X, I don't want something else", and I have no way to distinguish
that from "I would prefer format X, but am willing to take whatever you
can give me." For the former, I have to be prepared to throw things away.
For the latter, I have to be willing to send two requests, the first with
Accept (potentially getting back 4.06), and then a re-request without
Accept. Which one of the above are current clients doing? If it's the
former, then I suggest making this into an implementation note, and I
would even consider getting rid of the 4.06 response code  for this use
case, since it is nearly useless, and probably harmful. If it's the
latter, then these SHOULDs ought to be MUSTs and the option should be
critical so that clients can stop doing that.

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

By section number:

3.

   Code:  8-bit unsigned integer, split into a 3-bit class (most
      significant bits) and a 5-bit detail (least significant bits),
      documented as c.dd where c is a digit from 0 to 7 for the 3-bit
      subfield and dd are two digits from 00 to 31 for the 5-bit
      subfield.  Indicates if the message carries a request (0.01-0.31)
      or a response (2.00-5.31), or is empty (0.00).  (All other code
      values are reserved.)

I suggest changing the last two sentences above to: "The class can
indicate a request (0), a success response (2), a client error response
(4), or a server error response (5). (All other class values are
reserved.)" 

4.1: Personally, I find the word "empty" confusing here. "Null" or "Noop"
probably would have been better. If this use is already well understood,
it's probably best to define it clearly. Capitalizing "Empty" might
help.

4.2/4.3: "Reject" in the sense it is talked about in these sections is an
internal state change. That's confusing to me, as the normal sense of the
English word implies a party that "hears about" the rejection. (It's hard
to me to think of a circumstance where someone or something was
"rejected" and only the rejector ever knew about it.) In your use,
"silently ignore" is one possible form of rejection. That's just weird.

If you're going to do this, I'd define the term up front. Maybe even
capitalize "Reject" wherever you use it.

Either way, in both 4.2 and 4.3, "MUST reject" is probably wrong (since
that's an internal state and nothing a protocol requirement is useful
for) and "MAY involve sending" is a strange construction.

4.5: I think the MAYs confuse things and might encourage implementers to
take that path. Instead of:

   This rule MAY be relaxed in case
   the Confirmable message transports a request that is idempotent (see
   Section 5.1) or can be handled in an idempotent fashion.  Examples
   for relaxed message deduplication:
   
I suggest: "Exceptions to this are when the Confirmable message
transports a request that is idempotent (see Section 5.1) or can be
handled in an idempotent fashion.  Examples of these exceptions:". Also:

   As a general rule that MAY be
   relaxed based on the specific semantics of a message, the recipient
   SHOULD silently ignore any duplicated Non-confirmable message, and
   SHOULD process any request or response in the message only once.
   
I suggest: "The recipient SHOULD silently ignore any duplicated
Non-confirmable message, and SHOULD process any request or response in
the message only once, though the specific semantics of the message might
dictate an exception."

4.6: I feel like this section is really one big implementation note:
Because it is a layer violation, it's not clear to me that any
implementer has the ability to figure out much of this. (For example, the
idea that an implementer would be willing to -- or even know how to --
set the Do Not Fragment bit or figure out the Path MTU is a bit hopeful.)
I have no objection to this section, but it might be better as an
implementation note rather than a set of protocol instructions.

5.3.2: Change "the client will likely send a Reset message so it does not
receive any more retransmissions" to "the client will send". A client
that has lost state that receives what it will see as a random CON
message will always send back a Reset.

5.4.6: If it were me, I would have put the NoCacheKey bits in the high
four bits of the most significant byte so that you could simply do a <224
test for cache-matching options. I suppose this ship has sailed.

5.5.1: The implementation note notwithstanding, I don't understand why
Content-Format is not a SHOULD.

5.7.1:

   a proxy SHOULD be conservative

s/SHOULD/should. There's nothing to implement here.

5.10.5 s/MUST/is. The MUST is not meaningful.

8.1:

   A server SHOULD be aware that a request arrived via multicast, e.g.
   by making use of modern APIs such as IPV6_RECVPKTINFO [RFC3542], if
   available.

That SHOULD is not meaningful. It is useful, not required with exceptions
(as SHOULD indicates), for the server to know that it is using
multicast.

This also gives a reason not to allow RST on *any* NON messages.

12.1: As mentioned regarding section 3 and 5.2 above, I think it would be
much easier to figure these out if you separated out the bit fields of
code type and code, and then had sub-registries for request codes,
success codes, client error codes, and server error codes.