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

From: "Richard Barnes" <[email-masked]>
Date: Wed, 20 Aug 2014 12:58:39 -0700

Richard Barnes has entered the following ballot position for
draft-ietf-core-observe-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-core-observe/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

As usual, I'm impressed by the high quality of documents from the CORE
WG.  Thanks!  There are just a few points that need clarification.

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? 

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.  

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.

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

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

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

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

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