Observing Resources in the Constrained Application Protocol (CoAP)
draft-ietf-core-observe-16

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.

I do agree with Adrian's comments and concerns though.

I think it is worth adding a mention of Section 9 applying in addition to section 11 as a reference for security considerations in 7252.  This would only add a couple of words and make it clear that you've covered session encryption options with explanations of why each option exists and the risks.

Two points/questions:
- I wondered what happens in the case when a server is sending too frequently notifications to the client and had to read to Section 4.5.1. Do you mind adding a reference at the end of Section 1.4 to Section 4.5.1? Just to get an early heads-up to the interested reader. 

- I have a headache with the model used in Section 3.6, i.e., that the client just forgets its wish to receive notifications and solely relies on the transport, i.e., sending the Reset message. The second part, i.e., describing how to explicitly removing notifications looks the much more straight forward way of removing the notifications form the server. Your first approach looks much more like a last resort handling. Especially, since the Reset messages can get lost and it will take a very long time in this case until the server stops sending notifications. 

And by the way: thanks for the considerations about congestion control!

3.3.1:

   The server uses the Max-Age Option to indicate an age up to which it
   is acceptable that the observed state and the actual state are
   inconsistent.  If the age of the latest notification becomes greater
   than its indicated Max-Age, then the client MUST NOT assume that the
   enclosed representation reflects the actual resource state.

The first sentence never defines "acceptable" or "inconsistent" in this context. It sounds like there is no guarantee that if Max-Age hasn't expired, the observed state is identical to the actual state. If so, then does the server merely decide what is acceptable for itself? The semantics of Max-Age aren't clear. The second sentence just seems wrong: Unless you want to say that the client MUST/SHOULD ignore the value if it is beyond Max-Age (in which case say *that*), I'd change the sentence to "The client can use Max-Age to determine if the latest notification received by the client reflects the actual resource state."

3.4:

   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.
   
First, I think the MUST NOT is too strong. Also, "consider" is not an actionable implementation. How about:

   Since the goal is to keep the observed state as closely
   in sync with the actual state as possible, a client SHOULD discard
   an older notification that arrives later than a newer notification.

4.3.1:

   After returning the initial response, the server MUST try to keep the
   returned representation current, i.e., it MUST keep the resource
   state observed by the client as closely in sync with the actual
   resource state as possible.

Neither of those MUSTs are reasonable. Saying "the server MUST do its best" is silly.

   The server MAY wish to prevent
   that by sending a new notification with the unchanged representation
   and a new Max-Age just before the Max-Age indicated earlier expires.
   
If you actually want this to be an option, s/The server MAY wish to prevent that by sending/To prevent that, the server MAY send.

However, I don't understand why that isn't a SHOULD. If the server knows the client has stale data, SHOULDn't the server refresh client?

4.5:

   A server that transmits notifications mostly in non-confirmable
   messages MUST send a notification in a confirmable message instead of
   a non-confirmable message at least every 24 hours.  This prevents a
   client that went away or is no longer interested from remaining in
   the list of observers indefinitely.

That can't possibly be a protocol requirement. If I am a server that has plenty of space in my table and there are infrequent enough changes, I don't have to do this every 24 hours. I can choose to do it every minute, every day, or every week, as I see fit.

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.

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

I liked this document more than the number of questions I have might make you guess ...

These aren't blocking, and "Spencer doesn't grok CoAP" could be a reasonable response to most of them, but I'd ask that you consider them along with any other comments you might collect during IESG evaluation.

In this text:

3.2.  Notifications

   Notifications typically have a 2.05 (Content) response code.  They
   include an Observe Option with a sequence number for reordering
   detection (see Section 3.4), and a payload in the same Content-Format
   as the initial response.  If the client included one or more ETag
   Options in the request (see Section 3.3), notifications can also have
                                                               ^^^^
   a 2.03 (Valid) response code.

I would read “also” as implying “simultaneously”, and I bet that’s not true. If it’s not, would “notifications would have a 2.03 (Valid) response code rather than 2.05” be clearer?

I mention this mostly because CoAP is the same as HTTP except when it isn’t, so I don’t know that you don’t mean “simultaneously” without going to look :-)

In this text:

3.3.1.  Freshness

   To make sure it has a current representation and/or to re-register
   its interest in a resource, a client MAY issue a new GET request with
   the same token as the original at any time.  All options MUST be
   identical to those in the original request, except for the set of
   ETag Options.  It is RECOMMENDED that the client does not issue the
   request while it still has a fresh notification/response for the
   resource in its cache.  Additionally, the client SHOULD at least wait
   for a random amount of time between 5 and 15 seconds after Max-Age
   expired to avoid synchronicity with other clients.

Am I reading this correctly as “wait between 5 and 15 seconds after Max-Age expires to send a GET and re-register”? If so, you folk are the experts, but is this making it more likely that the client will miss state changes if the GET to re-register is dropped? 

Thanks for the shout-out to randomness, of course.

In this text:

4.3.1.  Freshness

   After returning the initial response, the server MUST try to keep the
                                             ^^^^^^^^^^^^^^^      
   returned representation current, i.e., it MUST keep the resource
   state observed by the client as closely in sync with the actual
   resource state as possible.

and in at least one other place in Section 4 that talk about trying to keep the client in sync, it looks like you’re using RFC 2119 language to describe what the protocol designers are thinking (“we MUST make sure that happens”), in ways that can’t be tested and don't impact interoperability. The second MUST seems more reasonable (squishy, but I wouldn't complain about it).

In this text:

4.5.1.  Congestion Control

   The server SHOULD NOT send more than one non-confirmable notification
              ^^^^^^^^^^
   per round-trip time (RTT) to a client on average.  If the server
   cannot maintain an RTT estimate for a client, it SHOULD NOT send more
   than one non-confirmable notification every 3 seconds, and SHOULD use
   an even less aggressive rate when possible (see also Section 3.1.2 of
   RFC 5405 [RFC5405]).

could you give some guidance on violating the SHOULD, and when/why that would be a great idea?

The rest of the congestion control section seemed very reasonable. Thank you.

In this text:

5.  Intermediaries

   To perform this task, the intermediary SHOULD make use of the
                                          ^^^^^^
   protocol specified in this document, taking the role of the client
   and registering its own interest in the target resource with the next
   hop towards the server.

I find myself wondering why this isn’t a MUST.

- You probably won't want to but I'll ask anyway, just in
case:-) The timing and sizes of notifications could expose
sensitive information to a network attacker even if encrypted.
TLS 1.3 is considering providing padding but TLS 1.2 and
earlier don't really. HTTP/2.0 is also considering allowing
padding. So should CoAP allow for padding in general, and if
so, should this extension also? Or, is there a way to get the
same result by sending out-of-date or other notifications that
won't be accepted by the observer? If so, might it be worth
documenting that? (However, it'd probably be better if both
sides knew what was going on.)

- I expected to see something about DTLS in section 7. Is
there really nothing to be said about session lifetimes or
expiry or keep-alives?  Has anyone tried this protocol over
DTLS in the interops?

In section 3.2:

   In the event that the resource changes in a way that would cause a
   normal GET request at that time to return a non-2.xx response (for
   example, when the resource is deleted), the server sends a
   notification with an appropriate response code (such as 4.04 Not
   Found) and removes all clients from the list of observers of the
   resource.

Would the 4.04 message be confirmable in cases where a 2.05 would be?   If so, does the removal happen when the confirmation is received, or immediately?   Also, this text implies that the server sends one message and then removes all the clients from the list of observers; wouldn't it make more sense to say that the server sends one message and removes the client to which it sent the message from the list of observers?   Otherwise it seems as if only one client would be notified.