Subject: [core] Adrian Farrel's No Objection on draft-ietf-core-observe-14: (with COMMENT)

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 20 Aug 2014 08:09:56 -0700

Adrian Farrel has entered the following ballot position for
draft-ietf-core-observe-14: No Objection

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/

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

I have no objection to the publication of this document, but I note
a number of issues below that may be documentation concerns or may be
wrinkles in the protocol. I leave the authors, shepherd, and AD to
work out if any action is needed.

---

Section 1.1 needs to explain what is a "resource". There is a special
meaning in the context of this document (I think) that is not the same
as the "network resource" that other people working in constrained 
networks might consider. You should be able to slot this in to...

   The model of REST is that of a client exchanging representations of
   resources with a server, where a representation captures the current
   or intended state of a resource and the server is the authority for
   representations of the resources in its namespace.  A client
   interested in the state of a resource initiates a request to the
   server; the server then returns a response with a representation of
   the resource that is current at the time of the request.

---

I was doing well in understanding how this protocol was a trade-off in
optimization. A repeated Get/response exchange is heavy on network
resources. A register/push system (like hear) addresses that but trades
it for state on the server. You can't win, but you can choose, and this
document appears to make a choice.

And then, in Section 1.2...

   A client remains on the list of observers as long as the server can
   determine the client's continued interest in the resource.  The
   interest is determined from the client's acknowledgement of
   notifications sent in confirmable CoAP messages by the server.  When
   the client deregisters, rejects a notification, or the transmission
   of a notification times out after several transmission attempts, the
   client is considered no longer interested and is removed from the
   list of observers by the server.

So this has two problems:
1. It appears to say that the Get/response mode is replaced with
   register/push/ack which does not reduce the message flows and causes
   the server to retain even more state :-(
2. "client's acknowledgement of notifications sent in confirmable CoAP 
   messages by the server" is ambiguous. It could be read to say that 
   the aknowledgements are sent in confirmable messages by the server!

I think you need some more clarity in this paragraph. How about...

   A client remains on the list of observers as long as the server can
   determine the client's continued interest in the resource.  The may
   server send a notification in a confirmable CoAP messages to request
   an acknowledgement by the client.  When the client deregisters, 
   rejects a notification, fails to respond to a confirmable CoAP
   message, or when the transmission of a notification by the server 
   times out after several transmission attempts, the client is 
   considered to be no longer interested and is removed from the list of
   observers by the server.

See also comments on Section 3.5.

Maybe the document is also missing guidance about how often to seek 
confirmation.

   An acknowledgement message signals to the server that the client is
   alive and interested in receiving further notifications; if the
   server does not receive an acknowledgement in reply to a confirmable
   notification, it will assume that the client is no longer interested
   and will eventually remove the associated entry from the list of
   observers.

---

Section 2 jumps in a little with some assumptions of how much the reader
knows about CoAP.  Of course, it is reasonable to assume familiarity,
but maybe some references for what an Option is and how it is encoded?

---

Section 3.1

   A client ... MUST NOT register more than once for the same target
   resource.

So, suppose a client does register a second time for the same resource.
The server still has to handle it, notwithstanding the "MUST NOT".
It can handle it by saying:
- I see it is a duplicate, I'll ignore it
or
- I see it is a duplicate, I'll treat it as a protocol violation and
  reject it.

But in Section 4.1

   If an entry
   with a matching endpoint/token pair is already present in the list
   (which, for example, happens when the client wishes to reinforce its
   interest in a resource), the server MUST NOT add a new entry but MUST
   replace or update the existing one.

So, you have written text to describe how a server handles this case and
you have even described why a client might send a second registration.

Can you clarify?

---

Section 3.3.1

   A client MAY store a notification like a response in its cache and
   use a stored notification that is fresh without contacting the
   server.

This reads very much like an implementation detail rather than a 
protocol specification.

>From a protocol point of view the information in the notification is
fresh until it times out. What use the client makes of that is surely
up to the client.

---

Section 3.5

   An acknowledgement message signals to the server that the client is
   alive and interested in receiving further notifications; if the
   server does not receive an acknowledgement in reply to a confirmable
   notification, it will assume that the client is no longer interested
   and will eventually remove the associated entry from the list of
   observers.

Now. Suppose the notification or acknowledgement is lost (I think
message loss is possible in CoAP, right?). Or suppose there is 
reordering so that the confirmable notification is overtaken by a
subsequent non-confirmable notification? Shouldn't the server have a 
slightly more rigorous approach to determining that a client is no 
longer interested in notifications to avoid falsely removing an
interested client?

Perhaps that is what "eventually" is supposed to convey, but that is
not a suitable word for including in a protocol spec.