Subject: Re: [core] AD review of draft-ietf-core-observe-14

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

Hi Barry,

thank you for your review. I've applied most of your suggestions to
the document in SVN (with a few tweaks here and there). Please see my
comments on the remaining items below.

Klaus

Barry Leiba wrote:
> -- Section 3.1 --
>    The target resource SHALL be identified
>    for this purpose by all options in the request that are part of the
>    cache-key, such as the full request URI and the Accept Option.
>
> I think the SHALL is unncessary here, and that the sentence is a bit
> confusingly worded.  This addresses that:
>
> NEW
>    For this purpose, all requests in which all options that are part
>    of the cache-key match are considered requests for the same
>    target resource.  Options that are part of the cache-key include,
>    for example, the full request URI and the Accept Option.
> END

I've removed the 'SHALL' from the draft ("The target resource is
identified..."), but to my eyes your 'NEW' is much harder to read than
the current text.

> -- Section 3.4 --
>
>    Messages with notifications can arrive in a different order than they
>    were sent.  Since the goal is to keep the observed state as closely
>    in sync with the actual state as possible, a client MUST NOT consider
>    a notification fresh that arrives later than a newer notification.
>
> That's a bit convoluted.  I suggest wording it positively, rather than
> negatively, like this:
>
> NEW
>    Messages with notifications can arrive in a different order than they
>    were sent.  Since the goal is to keep the observed state as closely
>    in sync with the actual state as possible, a client MUST consider the
>    notification that was sent most recently as the freshest, regardless
>    of the order of arrival.
> END

I've changed the entire section based on your suggestion as follows:

   Messages with notifications can arrive in a different order than they
   were sent.  Since the goal is to keep the observed state as closely
   in sync with the actual state as possible, a client MUST consider the
   notification that was sent most recently as the freshest, regardless
   of the order of arrival.

   To provide an order among notifications for the client, the server
   sets the value of the Observe Option in each notification to the 24
   least-significant bits of a strictly increasing sequence number.  An
   incoming notification was sent more recently than the freshest
   notification so far when one of the following conditions is met:

                      (V1 < V2 and V2 - V1 < 2^23) or
                      (V1 > V2 and V1 - V2 > 2^23) or
                      (T2 > T1 + 128 seconds)

   where V1 is the value of the Observe Option in the freshest
   notification so far, V2 the value of the Observe Option in the
   incoming notification, T1 a client-local timestamp for the freshest
   notification so far, and T2 a client-local timestamp for the incoming
   notification.

   Design Note:  The first two conditions verify that V1 is less than V2
      in 24-bit serial number arithmetic [RFC1982].  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; in other words, after 128 seconds have
      elapsed without any notification, a client does not need to check
      the sequence numbers to assume that an incoming notification was
      sent more recently than the freshest notification it has received
      so far.

Does that look good to you?

> -- Section 4.1 --
>    Upon success, the server returns a current representation
>    of the resource and MUST notify the client of subsequent changes to
>    the state as long as the client is on the list of observers.
>
> But we've already said it's OK for the server not to send *every*
> state change, so the MUST isn't quite right.  I actually think you
> don't need MUST here, and that this will explain the situation just
> fine, allowing for what was said earlier:
>
>    Upon success, the server returns a current representation
>    of the resource, and notifies the client of subsequent changes to
>    the state as long as the client is on the list of observers.

As Carsten said, there is a promise of eventual consistency. So the
server can't just sit back and relax; it MUST actively work towards
eventual consistency. Maybe the text could be rephrased as follows?

    Upon success, the server returns a current representation
    of the resource and MUST keep this representation updated
    (as described in Section 1.3) as long as the client is on the
    list of observers.

> -- Section 6 --
>    The "obs" attribute MUST NOT appear more
>    than once in a given link-value; occurrences after the first MUST be
>    ignored by parsers.
>
> I see where you're going with this, but as "obs" has no value, if
> there are multiple occurrences they're all the same.  In this case,
> I'd say it this way (putting the second part in active voice while I'm
> at it):
>
> NEW
>    The "obs" attribute MUST NOT appear more
>    than once in a given link-value, and parsers MUST ignore any extra
>    occurrences.
> END

I'm just following the wording of RFC 5988:

   "The 'rel' parameter MUST NOT appear more than once in a given
   link-value; occurrences after the first MUST be ignored by parsers." [1]
   "The 'title' parameter MUST NOT appear
   more than once in a given link-value; occurrences after the first
   MUST be ignored by parsers." [2]
   "The 'title*' parameter MUST NOT appear more than once in
   a given link-value; occurrences after the first MUST be ignored by
   parsers." [2]

Should I change the text as you suggest, or leave it as it is for
consistency with RFC 5988?

[1] http://tools.ietf.org/html/rfc5988#section-5.3
[2] http://tools.ietf.org/html/rfc5988#section-5.4