Subject: [core] Pete Resnick's Yes on draft-ietf-core-coap-18: (with COMMENT)

From: "Pete Resnick" <[email-masked]>
Date: Fri, 28 Jun 2013 11:56:07 -0700

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

Thanks for addressing my more serious concerns. Nothing blocking, but for
your consideration:

By section number:

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.

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