idnits 2.17.1 draft-ma-core-stateful-observe-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 24, 2013) is 3959 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 190, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 577, but not defined == Unused Reference: 'I-D.li-core-conditional-observe' is defined on line 608, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-10 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-05 == Outdated reference: A later version (-05) exists of draft-li-core-conditional-observe-02 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group C. Ma 3 Internet-Draft P. Hong 4 Intended status: Standards Track K. Xue 5 Expires: December 26, 2013 USTC 6 June 24, 2013 8 Stateful Observation in CoAP 9 draft-ma-core-stateful-observe-02 11 Abstract 13 The Observe Option allows a CoAP client to observe changes in the 14 state of resources and obtain a current representation of the last 15 resource state. To be an observer of an origin server's resources, 16 the client is required to register its interest with the server. A 17 successful registration will make the client added into the server's 18 observation list, while a failed one MAY drive the client to re- 19 register. 21 However, repeated and frequent re-registrations cannot guarantee the 22 client to eventually become an observer of the target server. In the 23 case that the server is unable or unwilling to accept an observer, 24 the time-intensive re-registrations will just bring redundant 25 messages in the constrained network and considerable energy 26 consumption on both the client and the server. 28 This memo defines a new CoAP option, State, for providing stateful 29 observation on the resources of CoAP servers. By observing the state 30 of the server in terms of the Observe Option, a client can explicitly 31 learn when the server will not actively reject an observation 32 registration, and then can wisely performs the re-registration. This 33 avoids the potential registration flooding that causes considerable 34 network overhead and energy consumption on the constrained nodes. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on December 26, 2013. 53 Copyright Notice 55 Copyright (c) 2013 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 This document may contain material from IETF Documents or IETF 69 Contributions published or made publicly available before November 70 10, 2008. The person(s) controlling the copyright in some of this 71 material may not have granted the IETF Trust the right to allow 72 modifications of such material outside the IETF Standards Process. 73 Without obtaining an adequate license from the person(s) controlling 74 the copyright in such materials, this document may not be modified 75 outside the IETF Standards Process, and derivative works of it may 76 not be created outside the IETF Standards Process, except to format 77 it for publication as an RFC or to translate it into languages other 78 than English. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 83 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 84 1.2. Protocol overview . . . . . . . . . . . . . . . . . . . . 4 85 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 86 2. The State Option . . . . . . . . . . . . . . . . . . . . . . . 5 87 3. Using the State Option . . . . . . . . . . . . . . . . . . . . 6 88 3.1. State notifications . . . . . . . . . . . . . . . . . . . 7 89 3.2. State option in request . . . . . . . . . . . . . . . . . 7 90 3.3. State option in initial response . . . . . . . . . . . . . 7 91 3.4. State option in state notifications . . . . . . . . . . . 8 92 3.5. Cancellation . . . . . . . . . . . . . . . . . . . . . . . 8 93 4. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . . 8 94 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 95 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 96 6.1. Amplification attacks . . . . . . . . . . . . . . . . . . 14 97 6.2. IP address spoofing attacks . . . . . . . . . . . . . . . 14 98 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 99 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 100 9. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 15 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 102 10.1. Normative reference . . . . . . . . . . . . . . . . . . . 15 103 10.2. Informative reference . . . . . . . . . . . . . . . . . . 15 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 106 1. Introduction 108 1.1. Background 110 CoAP [I-D.ietf-core-coap] is an Application Protocol for Constrained 111 Nodes/Networks. The observe [I-D.ietf-core-observe] specification 112 describes a subject/observer pattern to establish an observation 113 relationship between a CoAP client and a CoAP server. In this way, 114 the CoAP client will be notified whenever the state of the observed 115 resource changes. Furthermore, to provide the CoAP client with 116 tailored resources, the conditional observe [ID.li-core-conditional- 117 observe] specification proposes to implement frequently occurring 118 conditional observations by virtue of a new CoAP Condition Option. 120 In both of the specifications, the client is required to register its 121 interest with the server. A successful registration will make the 122 client added into the server's observation list, while a failed one 123 may drive the client to re-register. If the registration is 124 frustrated by factors such as network congestion and transmission 125 error, the client still has chances to become an observer by re- 126 registering with the server. In the case that the registration 127 failure results from the target server's incapability or 128 unwillingness, however, time-intensive re-registrations will not work 129 but just cause redundant messages in the constrained network and 130 waste the constrained energy of both the client and the server. 132 1.2. Protocol overview 134 This memo provides a mechanism for CoAP clients to explicitly learn 135 when the server will not actively reject an observation registration, 136 and to wisely perform a re-registration. This is accomplished 137 through a new CoAP option "State", which defines three states of a 138 CoAP server in terms of the "Observe" option (observation states) as 139 follows. 141 STATE 0: The CoAP server can add a CoAP client in the observation 142 list; 144 STATE 1: The CoAP server cannot add a CoAP client in the observation 145 list, but into the candidate queue, which is maintained by the server 146 for notifying the members about the changed observation state; 148 STATE 2: The CoAP server is unwilling or unable to accept a CoAP 149 client as an observer or a candidate. 151 A CoAP client who wishes to observe the resources of a CoAP server 152 can add the State Option along with the Observe Option in the initial 153 registration request. If the server is in STATE 0, the client will 154 be successfully added into the observation list and will become an 155 observer of the resources of the server. If the server is in STATE 156 1, the client will become a candidate, and thus can re-register with 157 the server when it is notified that the server returns to STATE 0. 158 This case is a typical stateful observation pattern as shown in 159 Figure 1. If the server is in STATE 2, the client temporarily quits 160 registering with the server. 162 Observer Subject 163 | | 164 | Register | 165 +-------------------->| 166 | | 167 | State Notification | 168 |<--------------------+ 169 | | 170 | State Notification | 171 |<--------------------+ 172 | | 173 | Re-register | 174 +-------------------->| 175 | | 176 |Resource Notification| 177 |<--------------------+ 178 | | 179 |Resource Notification| 180 |<--------------------+ 181 | | 183 Figure 1: Stateful Observation Design Pattern 185 1.3. Terminology 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 189 document are to be interpreted as described in [RFC2119]. 191 2. The State Option 193 +------+-----+----------+-----------+--------+---------+ 194 | Type | C/E | Name | Data type | Length | Default | 195 +------+-----+----------+-----------+--------+---------+ 196 | 30 | E | State | uint | 1-2B | (none) | 197 +------+-----+----------+-----------+--------+---------+ 198 Table 1: State Option Format 200 The State Option can be presented in both request and response 201 messages. In this document, the State Option MUST be used together 202 with the "Observe" Option and MAY be used with the "Max-age" Option. 204 0 1 2 3 4 5 6 7 0 1 2 205 +-+-+-+-+-+-+-+-+-+-+ 206 | TYPE |R| VAL | 207 +-+-+-+-+-+-+-+-+-+-+ 209 Figure 2: State Option Value 211 TYPE: The type indicates which option is described by the State 212 Option. In this document, the option number of the described Observe 213 Option is 10, therefore, the type should be 001010. It is set to be 214 a 6-bit integer for option description extension use. 216 R: The reliability flag indicates whether a state notification needs 217 to be sent in non-confirmable (0) form or in confirmable (1) form. 219 VAL: The state value that is represented by the VAL flag is used to 220 indicate the state of a CoAP server in terms of an option. For 221 instance, the state values combined with the Observe Option are 0, 1, 222 and 10, referring to the three observation states of an observable 223 CoAP server that are summarized in TABLE 2. The maximal length of 224 VAL is set to be 3 bits for extension use. The VAL part of a State 225 Option in the request message MUST be vacant. 227 +----------+-----------+--------------------------------+ 228 |State Type|State Value| Indication | 229 +----------+-----------+--------------------------------+ 230 | 1010 | 0 | Observation list is available | 231 +----------+-----------+--------------------------------+ 232 | 1010 | 1 |Observation list is unavailable | 233 | | | Candidate queue is available | 234 +----------+-----------+--------------------------------+ 235 | 1010 | 10 | Both are unavailable | 236 +----------+-----------+--------------------------------+ 238 Table 2: State Indication 240 3. Using the State Option 241 3.1. State notifications 243 If a CoAP client is added in the observation list of a CoAP server, 244 it will receive resource notifications as described in [I-D.ietf- 245 core-observe]. If the client is added in the candidate queue, 246 however, it will receive state notifications describing the 247 observation state of the server. A state notification includes an 248 Observe Option, a State Option, a Token Option that matches the token 249 specified by the client in the GET request, and a Max-age Option that 250 indicates the state notification delivery interval, and MAY contains 251 the payload which is in reply to the GET request. 253 3.2. State option in request 255 If a CoAP client wants to establish an observation relationship with 256 a CoAP server, it sends a GET request with an Observe Option, a State 257 Option and a Token Option to the server. Specifically, the TYPE of 258 the State Option is 1010, indicating that the client wants to observe 259 the observation state of the server, and the VAL part of the State 260 Option in the request message MUST be vacant. 262 3.3. State option in initial response 264 A CoAP server keeps an observation list and a candidate queue. When 265 the CoAP server receives the request, it performs as follows. 267 It firstly checks the state of its observation list and the candidate 268 queue. 270 If the server is in STATE 0, it adds the client in the observation 271 list, and responds as the same way described in [I-D.ietf-core- 272 observe], which excludes the State Option. 274 If the server is in STATE 1, it adds the client in the candidate 275 queue and sends a response containing the payload in reply to the GET 276 request, the Observe Option, the Token Option, the Max-age Option, 277 and the State Option with the TYPE part of 1010 and the VAL part of 278 1. Note that the Max-age Option is set for indicating the life time 279 of a state notifications, rather than the payload, and its default 280 value is 60s. 282 If the server is in STATE 2, it sends a response containing the 283 payload in reply to the GET request, the Observe Option, the Token 284 Option, and the State Option with the TYPE part of 1010 and the VAL 285 part of 10. The client will not be added into the candidate queue 286 and will not receive subsequent state notifications. 288 3.4. State option in state notifications 290 The server MUST choose an appropriate max-age for the state 291 notification. The value of the max-age should be larger than that in 292 the resource notifications. 294 The server sends the state notification with the VAL part of 1 to the 295 observation candidates whenever the last state notification has been 296 sent over the max-age, and notifies the candidates when its 297 observation state changes to be State 0. 299 Upon receiving the state notification with the VAL part of 0, the 300 candidate re-registers with the server by sending a GET request with 301 the Observe Option, the State Option and a new token. 303 The number (n) of the responsive candidates MAY be larger than that 304 (N) of the observers the server can additionally add in the list. In 305 this case, the server just simply chooses the top N candidates whose 306 responses are firstly received by it. The rest n-N responders still 307 stay in the candidate queue. A former candidate learns whether the 308 former re-registration succeeds through the subsequent notification. 309 Namely, a subsequent rescoure notification indicates a successful re- 310 registration, while a subsequent state notification indicates a 311 failed re-registration. 313 3.5. Cancellation 315 When a CoAP client wants to leave the observation list, it follows 316 the operations in [I-D.ietf-core-observe]. If the client wants to 317 leave the candidate queue, it can reject a confirmable notification 318 with a RST message or perform a GET request without the State Option 319 and the Observe Option for a currently observed state. In both of 320 the two cases, the server will remove the client from the candidate 321 queue. 323 The dismission of an observer is the same as that in [I-D.ietf-core- 324 observe]. If the server wants to dismiss a candidate, it SHOULD set 325 the VAL part of the state notification to be 10 and choose a large 326 max-age for the state notification. Otherwise, the server SHOULD NOT 327 send the state notification with the VAL part of 10 to the 328 candidates. 330 4. Intermediaries 332 It is possible that there is an intermediary between an origin server 333 and the CoAP client that is interested in a resource in the namespace 334 of the server. In this case, the client registers its interest with 335 the intermediary towards the origin server, acting as if it was 336 communicating with the origin server itself as specified in Section 337 3. The intermediary provides the client with a current 338 representation of the target resource and sends (state) notifications 339 upon changes to the resource (or observation) state, as an origin 340 server as specified in Section 3. To accomplish this, the 341 intermediary SHOULD make use of the protocol specified in this 342 document, taking the role of the client and registering its own 343 interest in the target resource with the original server. 345 If there is more than one CoAP-to-CoAP intermediary between the CoAP 346 client and the origin server, the first intermediary towards the 347 origin server is in charge of providing the client with a current 348 representation of the target resource and sends (state) notifications 349 upon changes to the resource (or observation) state, as an origin 350 server as specified in Section 3. The intermediary transmits the GET 351 request from the client hop by hop. If the next hop does not return 352 a response with an Observe Option, the intermediary MAY resort to 353 polling the next hop, or MAY itself return a response without an 354 Observe Option. The last intermediary towards the server transmits 355 the request to the server as if it is the client, or responds to the 356 request with the storage in its cache. 358 Additionally, the intermediary can also register in several target 359 resources with the original servers that it can directly reach, and 360 keep its own cache up to date. Whenever there is a GET request with 361 an Observe Option and a State Option from the client (or other 362 intermediary), the intermediary responds to the client with the 363 storage in its cache. 365 5. Examples 367 This section gives a number of examples to illustrate the use of 368 State Option in a GET request. 370 The first example (Figure 3) shows that a registration that is 371 carried in the GET request with Observe Option and State Option makes 372 the client added in the observation list of the server. The client 373 receives resource notifications of the current state and upon a state 374 change. 376 Observed CLIENT SERVER Resource Observation 377 content State State 378 ________ | | ________ _____ 379 | | 380 unknown | | 20.6 C list 381 +--------->| Header: GET 0x43011633 382 | GET | Token: 0x4a 383 | | Uri-Path: temperature 384 | | Observe: 0 385 | | State: 386 | | 387 ________ |<---------+ Header: 2.05 0x63451633 388 | 2.05 | Token: 0x4a 389 20.6 C | | Observe: 8 390 | | Max-Age: 20 391 | | Payload: "20.6 C" 392 | | ________ _____ 393 | | 394 ________ |<---------+ 18.9 C list 395 | 2.05 | Header: 2.05 0x53457b50 396 18.9 C | | Token: 0x4a 397 | | Observe: 16 398 | | Max-Age: 20 399 | | Payload: "18.9 C" 400 | | 402 Figure 3: The client is added in the observation list after a 403 registration 405 The example in Figure 4 shows that a registration that is carried in 406 the GET request with Observe Option and State Option makes the client 407 added into the candidate queue of the server. The client receives a 408 state notification of the current observation state and upon a state 409 change. When the client learns the server is in STATE 0 through the 410 state notification, the client re-registers with the server and then 411 is added into the observation list. 413 Observed CLIENT SERVER Resource Observation 414 content State State 415 ________ | | ________ _____ 416 | | 417 unknown | | 20.6 C queue 418 +--------->| Header: GET 0x43011633 419 | GET | Token: 0x4a 420 | | Uri-Path: temperature 421 | | Observe: 0 422 | | State: 423 | | 424 ________ |<---------+ Header: 2.05 0x63451633 425 | 2.05 | Token: 0x4a 426 1 | | Observe: 8 427 20.6 C | | Max-Age: 40 428 | | State: 1 429 | | ________ _____ Payload: "20.6 C" 430 | | 431 | | 18.9 C list 432 ________ |<---------+ Header: 2.03 0x53457b50 433 | 2.03 | Token: 0x4a 434 0 | | Observe: 16 435 20.6 C | | Max-Age: 40 436 | | State: 0 437 | | 438 +--------->| Header: GET 0x43021634 439 | GET | Token: 0xa1 440 | | Uri-Path: temperature 441 | | Observe: 23 442 | | State: 443 | | 444 ________ |<---------+ Header: 2.05 0x64451733 445 | 2.05 | Token: 0xa1 446 18.9 C | | Observe: 31 447 | | Max-Age: 20 448 | | Payload: "18.9 C" 449 | | 451 Figure 4: The client is added into the candidate queue after the 452 initial registration and is added into the observation list after the 453 re-registration 455 This example (Figure 5) shows that the client that is in the 456 candidate queue hasn't received a state notification over a max-age 457 time of 40s, and thus re-registers with the server. 459 Observed CLIENT SERVER Resource Observation 460 content State State 461 ________ | | ________ _____ 462 | | 463 1 | | 20.6 C queue 464 19.7 C | | 465 | | ________ _____ 466 | | 467 | | 18.9 C list 468 | X-------+ Header: 2.03 0x53457b50 469 | 2.03 | Token: 0x4a 470 | | Observe: 16 471 | | Max-Age: 40 472 | | State: 0 473 ________ | | 474 +--------->| Header: GET 0x43011633 475 1 | GET | Token: 0xb4 476 19.7 C | | Uri-Path: temperature 477 | | Observe: 27 478 | | ________ _____ State: 479 | | 480 ________ |<---------+ 19.4 C list Header: 2.05 0x63451633 481 | 2.05 | Token: 0xb4 482 19.4 C | | Observe: 31 483 | | Max-Age: 40 484 | | Payload: "19.4 C" 485 | | 487 Figure 5: The client re-registers after Max-Age ends 489 The example in Figure 6 shows that a proxy registers its interest 490 with the server, and receives state notifications to keep its cache 491 up to date. The client gets state notification from the proxy and 492 registers with the server (via the proxy) when the server returns to 493 State 0. 495 CLIENT PROXY SERVER 496 | | | 497 | +------>| Header: GET 0x44015fb8 498 | | GET | Token: 0x1a 499 | | | Uri-Host: sensor.example 500 | | | Uri-Path: temperature 501 | | | Observe: 0 502 | | | State: 503 | | | 504 | |<------+ Header: 2.05 0x63455fb8 505 | | 2.05 | Token: 0x1a 506 | | | Observe: 32 507 | | | Max-Age: 60 508 | | | State: 1 509 | | | Payload: "19.4 C" 510 | | | 511 | |<------+ Header: 2.03 0x63455f56 512 | | 2.03 | Token: 0x1a 513 | | | Observe: 40 514 | | | Max-Age: 60 515 | | | State: 0 516 | | | 517 | +------>| Header: GET 0x42011663 518 | | GET | Token: 0x3b 519 | | | Uri-Host: sensor.example 520 | | | Uri-Path: temperature 521 | | | Observe: 45 522 | | | State: 523 | | | 524 | <-------+ Header: 2.05 0x64451733 525 | | 2.05 | Token: 0x3b 526 | | | Observe: 49 527 | | | Max-Age: 30 528 | | | Payload: "18.9 C" 529 | | | 530 +------>| | Header: GET 0x42011633 531 | GET | | Token: 0x9a 532 | | | Proxy-Uri: coap://sensor.example/temperature 533 | | | Observe: 52 534 | | | State: 535 | | | 536 |<-----+| | Header: 2.03 0x62451633 537 | 2.05 | | Token: 0x9a 538 | | | Observe: 56 539 | | | Max-Age: 25 540 | | | Payload: "18.9 C" 541 | | | 543 Figure 6: A proxy registers with the server and receives state 544 notification to keep its cache up to date 546 6. Security Considerations 548 6.1. Amplification attacks 550 The amplification attacks towards observing the observation state are 551 more mitigatory compared to observing resources, since the state 552 notification has smaller message size and lower frequency than a 553 resource notification due to the lack of resource representation 554 payload and a larger max-age. Nonetheless, to further reduce the 555 harmful effects caused by the amplification attacks, the state 556 notifications sent in non-confirmable messages are recommended to be 557 interspersed with confirmable messages. 559 6.2. IP address spoofing attacks 561 Spoofing (state) notifications or RST in the response to a (state) 562 notification in a CON message, MAY make a client "deaf". For 563 instance, if a state notification with "VAL=0" is tampered by the 564 spoofing attacker to be a state notification with "VAL=10" and a 565 large max-age, the client will be spoofed to be waiting for a long 566 time. This kind of attack can be prevented using security modes 567 other than NoSec. 569 7. IANA Considerations 571 The following entries are added to the CoAP Option Numbers registry 572 of [I-D.ietf-core-coap]: 574 +--------+---------+-----------+ 575 | Number | Name | Reference | 576 +--------+---------+-----------+ 577 | 30 | State | [RFCXXXX] | 578 +--------+---------+-----------+ 580 8. Acknowledgements 582 Thanks to the support from the National Science and Technology Major 583 Project of China under Grant No.2011ZX03005-006. 585 9. Changelog 587 Changed from draft-00 to draft-01: 589 Added the description of max-age. Section 3.4 591 Changed the description of cancellation. Section 3.5 593 10. References 595 10.1. Normative reference 597 [I-D.ietf-core-coap] 598 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 599 "Constrained Application Protocol (CoAP)", 600 draft-ietf-core-coap-10 (work in progress), June 2012. 602 [I-D.ietf-core-observe] 603 Hartke, K., "Observing Resources in CoAP", 604 draft-ietf-core-observe-05 (work in progress), March 2012. 606 10.2. Informative reference 608 [I-D.li-core-conditional-observe] 609 Li, S., Hoebeke, J., and A. Jara, "Conditional observe in 610 CoAP", draft-li-core-conditional-observe-02 (work in 611 progress), June 2012. 613 Authors' Addresses 615 Changsha Ma 616 USTC 617 Room 307, EEIS Department, USTC West Campus 618 Shushan District, Hefei, Anhui 230027 619 P. R. China 621 Phone: +86-551-3601334 622 Email: machangs@mail.ustc.edu.cn 623 Peilin Hong 624 USTC 625 Room 305, EEIS Department, USTC West Campus 626 Shushan District, Hefei, Anhui 230027 627 P. R. China 629 Phone: +86-551-3601334 630 Email: plhong@ustc.edu.cn 632 Kaiping Xue 633 USTC 634 Room 305, EEIS Department, USTC West Campus 635 Shushan District, Hefei, Anhui 230027 636 P. R. China 638 Phone: +86-551-3601334 639 Email: kpxue@ustc.edu.cn