Subject: [core] Spencer Dawkins' No Objection on draft-ietf-core-observe-14: (with COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 18 Aug 2014 18:38:58 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-core-observe-14: No Objection

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.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-core-observe/

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

I liked this document more than the number of questions I have might make
you guess ...

These aren't blocking, and "Spencer doesn't grok CoAP" could be a
reasonable response to most of them, but I'd ask that you consider them
along with any other comments you might collect during IESG evaluation.

In this text:

3.2.  Notifications

   Notifications typically have a 2.05 (Content) response code.  They
   include an Observe Option with a sequence number for reordering
   detection (see Section 3.4), and a payload in the same Content-Format
   as the initial response.  If the client included one or more ETag
   Options in the request (see Section 3.3), notifications can also have
                                                               ^^^^
   a 2.03 (Valid) response code.

I would read “also” as implying “simultaneously”, and I bet that’s not
true. If it’s not, would “notifications would have a 2.03 (Valid)
response code rather than 2.05” be clearer?

I mention this mostly because CoAP is the same as HTTP except when it
isn’t, so I don’t know that you don’t mean “simultaneously” without going
to look :-)

In this text:

3.3.1.  Freshness

   To make sure it has a current representation and/or to re-register
   its interest in a resource, a client MAY issue a new GET request with
   the same token as the original at any time.  All options MUST be
   identical to those in the original request, except for the set of
   ETag Options.  It is RECOMMENDED that the client does not issue the
   request while it still has a fresh notification/response for the
   resource in its cache.  Additionally, the client SHOULD at least wait
   for a random amount of time between 5 and 15 seconds after Max-Age
   expired to avoid synchronicity with other clients.

Am I reading this correctly as “wait between 5 and 15 seconds after
Max-Age expires to send a GET and re-register”? If so, you folk are the
experts, but is this making it more likely that the client will miss
state changes if the GET to re-register is dropped? 

Thanks for the shout-out to randomness, of course.

In this text:

4.3.1.  Freshness

   After returning the initial response, the server MUST try to keep the
                                             ^^^^^^^^^^^^^^^      
   returned representation current, i.e., it MUST keep the resource
   state observed by the client as closely in sync with the actual
   resource state as possible.

and in at least one other place in Section 4 that talk about trying to
keep the client in sync, it looks like you’re using RFC 2119 language to
describe what the protocol designers are thinking (“we MUST make sure
that happens”), in ways that can’t be tested and don't impact
interoperability. The second MUST seems more reasonable (squishy, but I
wouldn't complain about it).

In this text:

4.5.1.  Congestion Control

   The server SHOULD NOT send more than one non-confirmable notification
              ^^^^^^^^^^
   per round-trip time (RTT) to a client on average.  If the server
   cannot maintain an RTT estimate for a client, it SHOULD NOT send more
   than one non-confirmable notification every 3 seconds, and SHOULD use
   an even less aggressive rate when possible (see also Section 3.1.2 of
   RFC 5405 [RFC5405]).

could you give some guidance on violating the SHOULD, and when/why that
would be a great idea?

The rest of the congestion control section seemed very reasonable. Thank
you.

In this text:

5.  Intermediaries

   To perform this task, the intermediary SHOULD make use of the
                                          ^^^^^^
   protocol specified in this document, taking the role of the client
   and registering its own interest in the target resource with the next
   hop towards the server.

I find myself wondering why this isn’t a MUST.