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

From: Carsten Bormann <[email-masked]>
Date: Wed, 5 Nov 2014 12:40:30 +0100

Richard,

A -15 has been submitted a while ago. Does this cover your DISCUSS and comments?

Grüße, Carsten 

> On 24.10.2014, at 01:29, Carsten Bormann <[email-masked]> wrote:
> 
> 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
> 
> 
>

---

From: Richard Barnes <[email-masked]>
Date: Wed, 5 Nov 2014 11:10:41 -0500

Hi Klaus,

Sorry for the radio silence on this.  Thanks for the responses; they do
help clear things up.  I've got a couple of suggestions inline below (in
RFC-Editor ready format), but I'll move these to COMMENTs.

Thanks,
--Richard

> aware of is the MONITOR verb in Roy Fielding's Waka.

Thanks for this explanation.  I agree that there's a clear difference here.

> 'register' or 'unregister'. The two spaces do not overlap.

Looking at the text, this is not entirely clear.  I would suggest something
like the following at the top of Section 2:

NEW: "The Observe Option carries an integer value whose meaning depends on
whether it is in a request or a response.  In a request, the Observe Option
signals registration (0) or deregistration (non-zero).  In a response, the
Observe Option carries a sequence number."

> sends; the server MUST be liberal in what it accepts."

It depends on whether you think there might be future situations where you
want might want to attach additional semantics to other non-zero values in
the future.  If so, you should really constrain the space to be 0/1
("Server MUST reject messages with an Observe Option has a value other than
0/1.")  If not, I would suggest something like the following:

"Clients MUST NOT send values other than 0 and 1.  Servers MUST interpret
any positive value as a deregistration request."

> implementations have been verified multiple times and validated in

Overall, this section is fine.  I would just suggest clarifying that
sentence, in terms of how it assumes time maps to serial numbers.

OLD:
"""
The third condition ensures that 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
"""

NEW:
"""
The third condition ensures that if the client is generating serial numbers
based on a local clock with roughly millisecond granularity, 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
"""