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

From: Klaus Hartke <[email-masked]>
Date: Mon, 22 Sep 2014 15:43:15 +0200

Hi Spencer,

thank you for your review and suggestions.

Spencer Dawkins wrote:
> 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?

Yes, that's a good improvement. I've applied the change to the document in SVN.

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

"CoAP is the same as HTTP except when it isn’t" describes CoAP very well :-)

> 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”?

Yes.

> 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?

The server tries really hard to keep the client updated. So if the
client feels the need to re-register, it's likely that it's because
congestion, network partition or some other problem that lets the
client miss state changes. But this is fine and fully in line with the
'eventually consistent' approach of the protocol [1].

[1] http://tools.ietf.org/html/draft-ietf-core-observe-14#section-1.3

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

I agree the second 'MUST' is the more actionable one. I've eliminated
the first part:

   After returning the initial response, the server MUST keep the
   resource state observed by the client as closely in sync with the
   actual resource state as possible.

> 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?

That 'SHOULD' comes from RFC 5405 [2]:

   A second class of applications cannot maintain an RTT estimate for a
   destination, because the destination does not send return traffic.
   Such applications SHOULD NOT send more than one UDP datagram every 3
   seconds, and SHOULD use an even less aggressive rate when possible.

[2] http://tools.ietf.org/html/rfc5405#section-3.1.2

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

Strictly speaking the intermediary only has to satisfy the request of
the client. There is a strong expectation that it uses the 'observe'
protocol to do that, but it's not required as long as the intermediary
sends the correct notifications to the client. One possible reason not
to use the 'observe' protocol is directly mentioned in the following
text, namely polling the next hop if necessary. If there are other
means to satisfy the client's request (and the implementer understands
the implications, such as increased traffic in the case of polling),
then it's fine to do that.

Klaus