Observing Resources in the Constrained Application Protocol (CoAP)
Note: This ballot was opened for revision 14 and is now closed.
Barry Leiba Former IESG member
Yes (for -14)
Jari Arkko Former IESG member
Yes (2014-08-20 for -14)
Thank you for this excellent and much needed work. I'm happy to recommend the publication of this specification as an RFC:
Adrian Farrel Former IESG member
No Objection (2014-08-20 for -14)
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.
Alia Atlas Former IESG member
No Objection (2014-08-20 for -14)
I do agree with Adrian's comments and concerns though.
Alissa Cooper Former IESG member
No Objection (for -14)
Brian Haberman Former IESG member
No Objection (for -14)
Joel Jaeggli Former IESG member
No Objection (for -14)
Kathleen Moriarty Former IESG member
No Objection (2014-08-19 for -14)
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.
Martin Stiemerling Former IESG member
No Objection (2014-08-15 for -14)
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!
Pete Resnick Former IESG member
No Objection (2014-08-20 for -14)
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.
Richard Barnes Former IESG member
(was Discuss) No Objection
No Objection (2014-11-05 for -15)
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.
Spencer Dawkins Former IESG member
No Objection (2014-08-18 for -14)
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.
Stephen Farrell Former IESG member
No Objection (2014-08-19 for -14)
- 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?
Ted Lemon Former IESG member
No Objection (2014-08-21 for -14)
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.