Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2015-09-30
16 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2015-09-09
16 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2015-08-20
16 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2015-07-06
16 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2015-07-06
16 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2015-07-03
16 (System) IANA Action state changed to Waiting on Authors from In Progress
2015-07-01
16 (System) IANA Action state changed to In Progress from On Hold
2015-06-30
16 Amy Vezza IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-06-29
16 (System) RFC Editor state changed to EDIT
2015-06-29
16 (System) Announcement was received by RFC Editor
2015-06-29
16 (System) IANA Action state changed to On Hold from In Progress
2015-06-29
16 (System) IANA Action state changed to In Progress
2015-06-29
16 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2015-06-29
16 Amy Vezza IESG has approved the document
2015-06-29
16 Amy Vezza Closed "Approve" ballot
2015-06-29
16 Amy Vezza Ballot approval text was generated
2015-06-27
16 Barry Leiba IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2015-06-27
16 Barry Leiba Ballot writeup was changed
2014-12-30
16 Klaus Hartke New version available: draft-ietf-core-observe-16.txt
2014-11-05
15 Richard Barnes
[Ballot comment]
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 …
[Ballot comment]
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.
2014-11-05
15 Richard Barnes [Ballot Position Update] Position for Richard Barnes has been changed to No Objection from Discuss
2014-10-27
15 Klaus Hartke IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2014-10-27
15 Klaus Hartke New version available: draft-ietf-core-observe-15.txt
2014-08-29
14 Meral Shirazipour Request for Telechat review by GENART Completed: Ready. Reviewer: Meral Shirazipour.
2014-08-28
14 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Dorothy Gellert.
2014-08-25
14 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2014-08-21
14 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2014-08-21
14 Ted Lemon
[Ballot comment]
In section 3.2:

  In the event that the resource changes in a way that would cause a
  normal GET request at …
[Ballot comment]
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.
2014-08-21
14 Ted Lemon [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon
2014-08-20
14 Pete Resnick
[Ballot comment]
3.3.1:

  The server uses the Max-Age Option to indicate an age up to which it
  is acceptable that the observed state …
[Ballot comment]
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.
2014-08-20
14 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2014-08-20
14 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2014-08-20
14 Richard Barnes
[Ballot 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 …
[Ballot 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.
2014-08-20
14 Richard Barnes
[Ballot comment]
"And third, the server may erroneously come to the conclusion that the client is no longer interested"
To mitigate this, might it be …
[Ballot 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.
2014-08-20
14 Richard Barnes [Ballot Position Update] New position, Discuss, has been recorded for Richard Barnes
2014-08-20
14 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2014-08-20
14 Alia Atlas [Ballot comment]
I do agree with Adrian's comments and concerns though.
2014-08-20
14 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2014-08-20
14 Adrian Farrel
[Ballot comment]
I have no objection to the publication of this document, but I note
a number of issues below that may be documentation concerns …
[Ballot 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.
2014-08-20
14 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2014-08-20
14 Jari Arkko [Ballot comment]
Thank you for this excellent and much needed work. I'm happy to recommend the publication of this specification as an RFC:
2014-08-20
14 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko
2014-08-19
14 Stephen Farrell
[Ballot comment]


- You probably won't want to but I'll ask anyway, just in
case:-) The timing and sizes of notifications could expose
sensitive information …
[Ballot comment]


- 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?
2014-08-19
14 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2014-08-19
14 Kathleen Moriarty
[Ballot comment]
I think it is worth adding a mention of Section 9 applying in addition to section 11 as a reference for security considerations …
[Ballot comment]
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.
2014-08-19
14 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2014-08-18
14 Spencer Dawkins
[Ballot comment]
I liked this document more than the number of questions I have might make you guess ...

These aren't blocking, and "Spencer doesn't …
[Ballot comment]
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.
2014-08-18
14 Spencer Dawkins Ballot comment text updated for Spencer Dawkins
2014-08-18
14 Spencer Dawkins
[Ballot comment]
I liked this document more than the number of questions I have might make you guess ...

These aren't blocking, and "Spencer doesn't …
[Ballot comment]
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 can 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.
2014-08-18
14 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2014-08-18
14 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2014-08-15
14 Martin Stiemerling
[Ballot comment]

Two points/questions:
- I wondered what happens in the case when a server is sending too frequently notifications to the client and had …
[Ballot comment]

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!
2014-08-15
14 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2014-08-14
14 Jean Mahoney Request for Telechat review by GENART is assigned to Meral Shirazipour
2014-08-14
14 Jean Mahoney Request for Telechat review by GENART is assigned to Meral Shirazipour
2014-08-12
14 Barry Leiba Changed consensus to Yes from Unknown
2014-08-11
14 Meral Shirazipour Request for Last Call review by GENART Completed: Ready. Reviewer: Meral Shirazipour.
2014-08-08
14 Barry Leiba Ballot has been issued
2014-08-08
14 Barry Leiba [Ballot Position Update] New position, Yes, has been recorded for Barry Leiba
2014-08-08
14 Barry Leiba Created "Approve" ballot
2014-08-08
14 Barry Leiba IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2014-08-08
14 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2014-08-01
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Dorothy Gellert
2014-08-01
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Dorothy Gellert
2014-07-31
14 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2014-07-31
14 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-core-observe-14.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-core-observe-14.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the CoAP Option Numbers subregistry of the Constrained RESTful Environments (CoRE) Parameters registry located at:

http://www.iana.org/assignments/core-parameters/

a new option number will be registered as follows:

Number: 6
Name: Observe
Reference: [ RFC-to-be ]

Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has
been approved for publication as an RFC. This message is only to confirm what actions will
be performed.
2014-07-31
14 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2014-07-31
14 Jean Mahoney Request for Last Call review by GENART is assigned to Meral Shirazipour
2014-07-30
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Wicinski
2014-07-30
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Wicinski
2014-07-26
14 Barry Leiba Placed on agenda for telechat - 2014-08-21
2014-07-25
14 Cindy Morgan IANA Review state changed to IANA - Review Needed
2014-07-25
14 Cindy Morgan
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Observing Resources in CoAP) to …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Observing Resources in CoAP) to Proposed Standard


The IESG has received a request from the Constrained RESTful Environments
WG (core) to consider the following document:
- 'Observing Resources in CoAP'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-08-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  CoAP is a RESTful application protocol for constrained nodes and
  networks.  The state of a resource on a CoAP server can change over
  time.  This document specifies a simple protocol extension for CoAP
  that enables CoAP clients to "observe" resources, i.e., to retrieve
  a representation of a resource and keep this representation updated
  by the server over a period of time.  The protocol follows a best-
  effort approach for sending new representations to clients and
  provides eventual consistency between the state observed by each
  client and the actual resource state at the server.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-core-observe/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-core-observe/ballot/


No IPR declarations have been submitted directly on this I-D.


2014-07-25
14 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2014-07-25
14 Cindy Morgan Last call announcement was generated
2014-07-25
14 Barry Leiba Last call was requested
2014-07-25
14 Barry Leiba IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2014-07-21
14 Barry Leiba IESG state changed to AD Evaluation::AD Followup from AD Evaluation
2014-07-20
14 Barry Leiba Ballot writeup was changed
2014-07-20
14 Barry Leiba IESG state changed to AD Evaluation from Publication Requested
2014-07-20
14 Barry Leiba Notification list changed to : core-chairs@tools.ietf.org, draft-ietf-core-observe@tools.ietf.org, core@ietf.org
2014-07-20
14 Carsten Bormann
1. Summary

This specification extends the CoAP protocol (RFC 7252) to allow for
CoAP clients to "observe" changing server-side resources, using a
model …
1. Summary

This specification extends the CoAP protocol (RFC 7252) to allow for
CoAP clients to "observe" changing server-side resources, using a
model of eventual consistency (not every intermediate state is
necessarily delivered).  It is intended for standards-track as it is a
widely implemented extension of a standards-track protocol.

Carsten Bormann is the document shepherd.
Barry Leiba is the responsible Area Director.

2. Review and Consensus

The specification was developed along with the base CoAP specification
and received significant review by active WG members and implementers.
One remaining smaller issue without an obvious answer, how to actively
cancel an ongoing observation from the client side, remained under
discussion for quite some time before a solution was finally picked at
IETF89 in London.

Several implementations of this final (post-London) version have
completed an interoperability test event with a very good score.
Further implementer feedback also was positive.
Parts of the specification have already been picked up earlier in OMA
LWM2M and are an element of their 1.0 specification.

The specification benefited from the directorate reviews of the base
specification (in particular with respect to congestion control), but
no separate directorate review of this extension has been performed.

3. Intellectual Property

There is no IPR disclosure referencing this document.  The author has
indicated recently that he is not aware of patent claims relating to
this document.

4. Other Points

(The shepherd was an original co-author of early versions of this
draft and is now listed in the acknowledgements.)
2014-07-20
14 Carsten Bormann IETF WG state changed to Submitted to IESG for Publication from WG Document
2014-07-20
14 Carsten Bormann IESG state changed to Publication Requested from AD is watching
2014-07-20
14 Carsten Bormann
1. Summary

This specification extends the CoAP protocol (RFC 7252) to allow for
CoAP clients to "observe" changing server-side resources, using a
model …
1. Summary

This specification extends the CoAP protocol (RFC 7252) to allow for
CoAP clients to "observe" changing server-side resources, using a
model of eventual consistency (not every intermediate state is
necessarily delivered).  It is intended for standards-track as it is a
widely implemented extension of a standards-track protocol.

Carsten Bormann is the document shepherd.
Barry Leiba is the responsible Area Director.

2. Review and Consensus

The specification was developed along with the base CoAP specification
and received significant review by active WG members and implementers.
One remaining smaller issue without an obvious answer, how to actively
cancel an ongoing observation from the client side, remained under
discussion for quite some time before a solution was finally picked at
IETF89 in London.

Several implementations of this final (post-London) version have
completed an interoperability test event with a very good score.
Further implementer feedback also was positive.
Parts of the specification have already been picked up earlier in OMA
LWM2M and are an element of their 1.0 specification.

The specification benefited from the directorate reviews of the base
specification (in particular with respect to congestion control), but
no separate directorate review of this extension has been performed.

3. Intellectual Property

There is no IPR disclosure referencing this document.  The author has
indicated recently that he is not aware of patent claims relating to
this document.

4. Other Points

(The shepherd was an original co-author of early versions of this
draft and is now listed in the acknowledgements.)
2014-07-20
14 Carsten Bormann Document shepherd changed to Dr. Carsten Bormann
2014-06-30
14 Klaus Hartke New version available: draft-ietf-core-observe-14.txt
2014-04-10
13 Klaus Hartke New version available: draft-ietf-core-observe-13.txt
2014-02-14
12 Klaus Hartke New version available: draft-ietf-core-observe-12.txt
2013-10-15
11 Klaus Hartke New version available: draft-ietf-core-observe-11.txt
2013-09-23
10 Klaus Hartke New version available: draft-ietf-core-observe-10.txt
2013-07-15
09 Klaus Hartke New version available: draft-ietf-core-observe-09.txt
2013-02-25
08 Klaus Hartke New version available: draft-ietf-core-observe-08.txt
2012-10-22
07 Klaus Hartke New version available: draft-ietf-core-observe-07.txt
2012-09-06
06 Klaus Hartke New version available: draft-ietf-core-observe-06.txt
2012-07-05
05 Barry Leiba Responsible AD changed to Barry Leiba from Peter Saint-Andre
2012-07-05
05 Barry Leiba Intended Status changed to Proposed Standard from None
2012-03-12
05 Klaus Hartke New version available: draft-ietf-core-observe-05.txt
2012-02-14
04 (System) Ballot writeup text was added
2012-02-14
04 (System) Last call text was added
2012-02-14
04 (System) Ballot approval text was added
2012-02-14
04 (System) New version available: draft-ietf-core-observe-04.txt
2011-10-31
03 (System) New version available: draft-ietf-core-observe-03.txt
2011-09-15
04 (System) Document has expired
2011-09-15
04 (System) State changed to Dead from AD is watching.
2011-03-14
02 (System) New version available: draft-ietf-core-observe-02.txt
2011-02-07
01 (System) New version available: draft-ietf-core-observe-01.txt
2011-02-07
04 Cindy Morgan Approval announcement text regenerated
2010-11-02
04 Peter Saint-Andre Draft Added by Peter Saint-Andre in state AD is watching
2010-10-18
00 (System) New version available: draft-ietf-core-observe-00.txt