Subject: Re: [core] Martin Stiemerling's No Objection on draft-ietf-core-observe-14: (with COMMENT)

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

Hi Martin,

thank you for your review and suggestions.

Martin Stiemerling wrote:
> - I wondered what happens in the case when a server is sending too
> frequently notifications to the client and had to read to Section 4.5.1.
> Do you mind adding a reference at the end of Section 1.4 to Section
> 4.5.1? Just to get an early heads-up to the interested reader.

I hoped this was clarified by Section 1.3:

OLD:
      "It follows a best-effort approach for sending the current
      representation to the client after a state change: Clients should
      see the new state after a state change as soon as possible, and
      they should see as many states as possible.  However, a client
      cannot rely on observing every single state that a resource might
      go through."

I've rephrased the last sentence as follows:

NEW:
      It follows a best-effort approach for sending the current
      representation to the client after a state change: Clients should
      see the new state after a state change as soon as possible, and
      they should see as many states as possible.  This is limited by
      congestion control, however, so a client cannot rely on observing
      every single state that a resource might go through.

Is this what you had in mind?

> - I have a headache with the model used in Section 3.6, i.e., that the
> client just forgets its wish to receive notifications and solely relies
> on the transport, i.e., sending the Reset message. The second part, i.e.,
> describing how to explicitly removing notifications looks the much more
> straight forward way of removing the notifications form the server. Your
> first approach looks much more like a last resort handling. Especially,
> since the Reset messages can get lost and it will take a very long time
> in this case until the server stops sending notifications.

The first part is needed for the case where a client loses all its
communication state (e.g., due to a power outage) and therefore cannot
remove itself from the list of observers. The server must check from
time to time if the original client is still there, and, if not,
remove it from the list.

This check aligns nicely with the retransmission mechanism we have in
CoAP, so the implementation overhead is really small. And there is not
really a big difference timewise between a server transmitting
notifications until it receives a Reset message, and a client
transmitting cancellation requests until it receives an
Acknowledgement message.

So, since this part has to be implemented in any case and we aim for a
small code size, we tried for a long time to have only this as the
only cancellation mechanism. It works really well for mostly static,
long-term observations.

When the observations are more dynamic, short-term, then your concerns
are justified. But that's why we have the second part.

Does this relieve you of your headache?

Klaus