Subject: Re: [core] Richard Barnes' Discuss on draft-ietf-core-observe-14: (with DISCUSS and COMMENT)

From: Carsten Bormann <[email-masked]>
Date: Fri, 24 Oct 2014 01:29:46 +0200

Richard,

I’m assuming the best way forward is for Klaus to write up the changes resulting from the discussion below (and the other COMMENTs), submit a -15, and take it from there?

Grüße, Carsten

> On 23 Sep 2014, at 15:50, Klaus Hartke <[email-masked]> wrote:
> 
> Hi Richard,
> 
> thank you for your review and questions.
> 
> 
> Richard Barnes wrote:
>> One very temporary point: Has anyone done a comparison between this work
>> and the server push aspects of HTTP/2?  Is there any value in trying to
>> align the two?
> 
> If I'm not mistaken, the server push in HTTP/2 is used when a server
> can predict which resources the client is going to request next. For
> example, when an HTML document contains an <img> element, it's highly
> likely that a web browser will request the linked image next. However,
> once the representation has been pushed to the browser, the server
> cannot update the displayed page by pushing updated representations.
> 
> The "CoAP observe" protocol is used when a client wants to have a
> fresh representation over a period of time. The server pushes updated
> representations, but it cannot push representations of resources that
> the client didn't request. In a web browser, a similar effect can be
> achieved using <meta http-equiv="refresh" content="1"> or some ad-hoc
> solution based on repeated AJAX calls, Long-Polling, Server-Sent
> Events or WebSockets, except that any of these mechanisms either cause
> a lot of unnecessary traffic, bypass the cache, or break REST in some
> other way.
> 
> The closest equivalent to "CoAP observe" in the HTTP world that I'm
> aware of is the MONITOR verb in Roy Fielding's Waka.
> 
> 
>> It's unclear to me from the text of Section 2 how the 0/1
>> register/deregister values are used.  Are these reserved values out of
>> the sequence number space?  Or are they carried somewhere else in the
>> option?  I infer from Section 3.6 that the answer is the former, but
>> Section 2 should be explicit about this.
> 
> The value of the Observe Option depends on where it's used: in
> requests or in notifications/responses. In notifications/responses,
> the value is a sequence number. In a request, the value is either
> 'register' or 'unregister'. The two spaces do not overlap.
> 
>> In fact, it seems like it's not necessary to reserve the value 1 at all,
>> since the server must interpret any positive value as deregistration.
>> Calling out 1 as special invites server implementations to screw this
>> up.
> 
> I could have written: "The client MUST be conservative in what it
> sends; the server MUST be liberal in what it accepts."
> 
> 
>> "the time elapsed between the two incoming messages is not so large that
>> the difference between V1 and V2 has become larger than the largest
>> integer that it is meaningful to add to a 24-bit serial number"
>> The text seems confused about whether the value of the Observe option is
>> a serial number or a time value.  The definition says that it's a serial
>> number, but this sentence implies that it's somehow related to time.  In
>> order to avoid clients making unwarranted assumptions about the value of
>> the Observe option, it seems important to clarify this.
> 
> We want implementations to be able to generate the sequence number
> from a client-local clock, so the client doesn't have to maintain any
> counters. That makes the sequence number a "temporal serial number".
> I'm aware that the draft doesn't fully explain how they work (temporal
> serial number arithmetic is hard), but the requirements for
> implementations have been verified multiple times and validated in
> interop events.
> 
> 
>> "And third, the server may erroneously come to the conclusion that the
>> client is no longer interested"
>> To mitigate this, might it be useful for a client to sometimes send
>> "gratuitous ACKs"? That is, to periodically re-ACK the last notification
>> to re-confirm its interest?
> 
> The server makes several attempts to contact the client before it
> removes an entry from the list of observers. So a client is really
> only removed when there is a network partition or heavy congestion. In
> that case, a periodic acknowledgement wouldn't help as well. At some
> point, an unresponsive client has to be declared dead and removed from
> the list of observers. If a client wants to make sure that it's still
> on the list (for example, if it hasn't heard from the server for some
> time), then it can easily re-register by sending another GET request
> with Observe Option and the previously used token.
> 
> 
>> "If the server returns a 2.xx response that includes an Observe Option as
>> well..."
>> Does the value of this option matter at all?  Could the server, for
>> example, simply mirror the client's option?
> 
> At this stage (send a request, get a response) it's only important
> that the Observe Option is present. However, when it comes to
> reordering detection, the value is important; it must be a sequence
> number. This is specified in section 4.4 of the document [1].
> 
> [1] https://tools.ietf.org/html/draft-ietf-core-observe-14#section-4.4
> 
> 
>> "Notifications are additional responses..."
>> Might be helpful to re-word to emphasize that the only difference between
>> a "notification" and a normal response is the presence of the Observe
>> option.
> 
> I've added this to the end of that paragraph:
> 
>   Notifications are additional responses sent by the server in reply to
>   the single extended GET request that created the registration.  Each
>   notification includes the token specified by the client in the
>   request.  The only difference between a notification and a normal
>   response is the presence of the Observe Option.
> 
> 
>> "Non-2.xx responses do not include an Observe Option..."
>> Should this be a MUST NOT?  It seems like an interop requirement, in the
>> sense of maintaining a consistent view of subscription state between
>> server and client.
> 
> This sentence is just a non-normative summary of the normative
> requirements for servers in section 4.2 [2]:
> 
>   "A 2.xx notification MUST include an Observe Option with a sequence
>   number as specified in Section 4.4 below; a non-2.xx notification
>   MUST NOT include an Observe Option."
> 
> [2] http://tools.ietf.org/html/draft-ietf-core-observe-14#section-4.2
> 
> 
> Klaus
>