idnits 2.17.1 draft-bormann-core-roadmap-05.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 22, 2013) is 3837 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) == Outdated reference: A later version (-21) exists of draft-ietf-core-block-13 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-11 == Outdated reference: A later version (-11) exists of draft-ietf-tls-oob-pubkey-10 == Outdated reference: A later version (-08) exists of draft-mcgrew-tls-aes-ccm-ecc-07 ** Downref: Normative reference to an Informational draft: draft-mcgrew-tls-aes-ccm-ecc (ref. 'I-D.mcgrew-tls-aes-ccm-ecc') ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-05) exists of draft-arkko-core-dev-urn-03 == Outdated reference: A later version (-06) exists of draft-becker-core-coap-sms-gprs-04 == Outdated reference: A later version (-27) exists of draft-bormann-coap-misc-25 == Outdated reference: A later version (-06) exists of draft-castellani-core-advanced-http-mapping-02 == Outdated reference: A later version (-06) exists of draft-dijk-core-groupcomm-misc-04 == Outdated reference: A later version (-05) exists of draft-fossati-core-multipart-ct-03 == Outdated reference: A later version (-03) exists of draft-fossati-core-publish-option-02 == Outdated reference: A later version (-02) exists of draft-gerdes-core-dcaf-authorize-00 == Outdated reference: A later version (-25) exists of draft-ietf-core-groupcomm-16 == Outdated reference: A later version (-14) exists of draft-ietf-core-interfaces-00 == Outdated reference: A later version (-10) exists of draft-ietf-core-links-json-00 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-00 == Outdated reference: A later version (-06) exists of draft-ietf-lwig-cellular-00 == Outdated reference: A later version (-05) exists of draft-ietf-lwig-ikev2-minimal-01 == Outdated reference: A later version (-07) exists of draft-ietf-lwig-terminology-05 == Outdated reference: A later version (-01) exists of draft-ietf-lwig-tls-minimal-00 == Outdated reference: A later version (-03) exists of draft-kovatsch-lwig-coap-01 == Outdated reference: A later version (-03) exists of draft-li-core-coap-payload-length-option-02 == Outdated reference: A later version (-01) exists of draft-pporamba-dtls-certkey-00 == Outdated reference: A later version (-05) exists of draft-rahman-core-sleepy-04 == Outdated reference: A later version (-02) exists of draft-schmitt-two-way-authentication-for-iot-01 == Outdated reference: A later version (-02) exists of draft-selander-core-access-control-01 == Outdated reference: A later version (-11) exists of draft-silverajan-core-coap-alternative-transports-03 == Outdated reference: A later version (-19) exists of draft-urien-core-racs-00 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5988 (Obsoleted by RFC 8288) Summary: 3 errors (**), 0 flaws (~~), 30 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track October 22, 2013 5 Expires: April 25, 2014 7 CoRE Roadmap and Implementation Guide 8 draft-bormann-core-roadmap-05 10 Abstract 12 The CoRE set of protocols, in particular the CoAP protocol, is 13 defined in draft-ietf-core-coap in conjunction with a number of 14 specifications that are currently nearing completion. There are also 15 several dozen more individual Internet-Drafts in various states of 16 development, with various levels of WG review and interest. 18 Today, this is simply a bewildering array of documents. Beyond the 19 main four documents, it is hard to find relevant information and 20 assess the status of proposals. At the level of Internet-Drafts, the 21 IETF has only adoption as a WG document to assign status - too crude 22 an instrument to assess the level of development and standing for 23 anyone who does not follow the daily proceedings of the WG. 25 With a more long-term perspective, as additional drafts mature and 26 existing specifications enter various levels of spec maintenance, the 27 entirety of these specifications may become harder to understand, 28 pose specific implementation problems, or be simply inconsistent. 30 The present guide aims to provide a roadmap to these documents as 31 well as provide specific advice how to use these specifications in 32 combination. In certain cases, it may provide clarifications or even 33 corrections to the specifications referenced. 35 This guide is intended as a continued work-in-progress, i.e. a long- 36 lived Internet-Draft, to be updated whenever new information becomes 37 available and new consensus on how to handle issues is formed. 38 Similar to the ROHC implementation guide, RFC 4815, it might be 39 published as an RFC at some future time later in the acceptance curve 40 of the specifications. 42 This document does not describe a new protocol or attempt to set a 43 new standard of any kind - it mostly describes good practice in using 44 the existing specifications, but it may also document emerging 45 consensus where a correction needs to be made. 47 (TODO: The present version does not completely cover the new 48 Internet-Drafts submitted concurrently with it; it is to be updated 49 by the start of IETF88.) 51 Status of This Memo 53 This Internet-Draft is submitted in full conformance with the 54 provisions of BCP 78 and BCP 79. 56 Internet-Drafts are working documents of the Internet Engineering 57 Task Force (IETF). Note that other groups may also distribute 58 working documents as Internet-Drafts. The list of current Internet- 59 Drafts is at http://datatracker.ietf.org/drafts/current/. 61 Internet-Drafts are draft documents valid for a maximum of six months 62 and may be updated, replaced, or obsoleted by other documents at any 63 time. It is inappropriate to use Internet-Drafts as reference 64 material or to cite them other than as "work in progress." 66 This Internet-Draft will expire on April 25, 2014. 68 Copyright Notice 70 Copyright (c) 2013 IETF Trust and the persons identified as the 71 document authors. All rights reserved. 73 This document is subject to BCP 78 and the IETF Trust's Legal 74 Provisions Relating to IETF Documents 75 (http://trustee.ietf.org/license-info) in effect on the date of 76 publication of this document. Please review these documents 77 carefully, as they describe your rights and restrictions with respect 78 to this document. Code Components extracted from this document must 79 include Simplified BSD License text as described in Section 4.e of 80 the Trust Legal Provisions and are provided without warranty as 81 described in the Simplified BSD License. 83 Table of Contents 85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 86 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 87 2. The Main Four . . . . . . . . . . . . . . . . . . . . . . . . 3 88 2.1. The CoAP protocol . . . . . . . . . . . . . . . . . . . . 4 89 2.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 5 90 2.3. Further reading . . . . . . . . . . . . . . . . . . . . . 6 91 3. Informational Drafts . . . . . . . . . . . . . . . . . . . . 6 92 3.1. Implementation . . . . . . . . . . . . . . . . . . . . . 6 93 3.2. Multicast and Group Communication . . . . . . . . . . . . 7 94 3.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 8 95 3.4. Intermediaries . . . . . . . . . . . . . . . . . . . . . 9 96 3.5. Congestion Control . . . . . . . . . . . . . . . . . . . 9 97 4. CoAP over X . . . . . . . . . . . . . . . . . . . . . . . . . 9 98 5. Optional components of CoRE . . . . . . . . . . . . . . . . . 10 99 5.1. CoAP-misc . . . . . . . . . . . . . . . . . . . . . . . . 10 100 5.2. Generalizing Media Types . . . . . . . . . . . . . . . . 11 101 5.3. Patience, Leisure, Pledge, or: Timing extensions . . . . 11 102 5.4. Extending Observe . . . . . . . . . . . . . . . . . . . . 11 103 5.5. Service discovery . . . . . . . . . . . . . . . . . . . . 11 104 5.6. Server discovery, Naming, etc. . . . . . . . . . . . . . 12 105 5.7. More support for sleepy nodes . . . . . . . . . . . . . . 12 106 6. Replaced drafts . . . . . . . . . . . . . . . . . . . . . . . 14 107 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 108 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 109 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 110 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 111 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 112 10.2. Informative References . . . . . . . . . . . . . . . . . 16 113 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 115 1. Introduction 117 (To be written - for now please see the Abstract.) 119 1.1. Terminology 121 This document is a guide. However, it might evolve to make specific 122 recommendations on how to use standards-track specifications. 123 Therefore: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 124 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in RFC 126 2119. They indicate requirement levels for compliant CoRE 127 implementations [RFC2119]. Note that these keywords are not only 128 used where a correction or clarification is intended; the latter are 129 explicitly identified as such. 131 The term "byte" is used in its now customary sense as a synonym for 132 "octet". 134 2. The Main Four 136 The main component of the CoRE architecture is the Constrained 137 Application Protocol (CoAP). It aims to provide a RESTful transfer 138 service, not unlike HTTP, but radically simplified for the use on 139 constrained devices on constrained networks. REST is the 140 architectural style that informed the design of HTTP [REST]. The 141 terms "constrained device" and "constrained network" refer to 142 limited-capability devices such as sensors operating on networks such 143 as the IEEE 802.15.4 based 6LoWPAN [RFC4919]. 144 [I-D.ietf-lwig-terminology] provides a more detailed discussion of 145 what we mean by these terms. 147 2.1. The CoAP protocol 149 The CoAP protocol is defined in three specifications: 151 o [I-D.ietf-core-coap] 153 o [I-D.ietf-core-block] 155 o [I-D.ietf-core-observe] 157 The first specification, [I-D.ietf-core-coap], provides the core 158 transfer protocol, including the means to provide communication 159 security using the DTLS protocol [RFC6347] (compare this to the way 160 [RFC2616] and [RFC2818] define HTTP and HTTPS). The protocol is 161 structured into a message layer, which provides duplicate detection 162 and optional message reliability on top of UDP, and a request/ 163 response layer, which provides the usual REST operations GET, PUT, 164 POST, and DELETE. A highly efficient protocol encoding carries the 165 4-byte base header, a sequence of _Options_, and the payload (body) 166 of a message. The main extension points of CoAP are its Options, 167 similar to the way new header fields are used to extend HTTP. 169 Since CoAP is a very simple protocol running on top of UDP, it is 170 limited in its transfer size by the datagram sizes provided by UDP. 171 As a further constraint, many constrained networks do not provide 172 good reliability of delivery once their small frame sizes are 173 exceeded and the adaptation layer is forced to fragment [WEI]. This 174 may lead to a practical limitation to payload sizes as small as 64 175 bytes. [I-D.ietf-core-block] extends the base CoAP protocol with 176 three options that enable _blockwise_ transfer, i.e., splitting up a 177 larger transfer into a sequence of smaller transactions, as well as 178 the early determination of the overall size of the resource 179 representation. 181 In HTTP, transactions are always client initiated, and it is the 182 responsibility of the client to perform GET operations again and 183 again (polling) if it wants to stay up to date about the status of a 184 resource. This "pull model" becomes expensive in an environment with 185 limited power, limited network resources, and nodes that sleep most 186 of the time. Some more or less savory workarounds have been 187 developed for HTTP [RFC6202], but, as a new protocol, CoAP can do 188 better. [I-D.ietf-core-observe] extends the base CoAP protocol with 189 an option that a client can use to indicate its interest in further 190 updates from a resource. If the server accepts this option, the 191 client becomes an _Observer_ of this resource and receives an 192 asynchronous notification message each time it changes. Each such 193 notification message is identical in structure to the response to the 194 initial GET request. 196 While the "Block" and "Observe" specifications are optional additions 197 to the CoAP protocol (just as the core specification already defines 198 14 options most of which will not need to be used in every message), 199 they together form what is now generally considered to be the CoAP 200 protocol. 202 The CoRE Working Group has completed its work on the base CoAP 203 protocol specification [I-D.ietf-core-coap] and it has been approved 204 by the IESG for publication as a Standards-Track RFC on 2013-07-15. 205 The completed document is currently waiting in the RFC editor queue 206 for two of its normative references in the security area, 207 [I-D.mcgrew-tls-aes-ccm-ecc] and [I-D.ietf-tls-oob-pubkey], to be 208 completed and approved. 210 The other two CoAP specifications are, at the time of this writing, 211 in the process of being updated based on the comments to the first 212 Working-Group Last-Call [RFC2418], and in the second Working-Group 213 Last-Call, respectively; these are prerequisites to submitting them 214 to the IESG for publication as a Standards-Track RFC. 216 The specifications, together with link-format (below), have been 217 widely implemented in highly interoperable implementations: an ETSI 218 "plugtest" event in March 2012 was attended by 15 organizations with 219 20 implementations; in over 3000 tests performed only about 6 % 220 failed; a second plugtest was conducted in November 2012 and led to 221 some final adjustments of some details in the specifications. 222 Another plugtest is planned for November 2013 [COAP3]. 224 2.2. Discovery 226 The fourth specification in the main set now nearing completion does 227 not extend the CoAP protocol but addresses a different problem. 229 In the Web, a number of methods for discovery of resources are 230 common. Initially, Web discovery was just performed by humans based 231 on an entry resource to a server (e.g., "/index.html"). This 232 resource then includes links that directly or indirectly allow a 233 human to reach the other Web resources that make up the Web site. 235 Web discovery can be performed by machines if standardized interfaces 236 and resource descriptions are available. Among the component 237 mechanisms for Web discovery that are standardized in the IETF are 238 the well-known resource path "/.well-known/..." [RFC5785] and the 239 HTTP link header [RFC5988]. Several related techniques are in common 240 use today. 242 Clearly, in the machine-to-machine environments that will be typical 243 of CoAP applications, it is important to enable devices to discover 244 each other and their resources. Autonomous devices and embedded 245 systems necessitate uniform, interoperable resource discovery. 247 A basic component for this is provided by a standardized description 248 format for the resources a server provides, the _link-format_. 249 Unless other methods of discovery are available, CoAP servers should 250 provide such a description via the well-known URI "/.well-known/ 251 core", available for access via a GET request on that URI. (More 252 advanced resource discovery schemes might make the same description 253 available by other means, e.g. by posting it to a resource 254 directory.) 256 The description format has been adapted from the format used in the 257 HTTP link header [RFC5988], which is simple and easy to parse. In 258 contrast to the HTTP specification, link-format is specified as an 259 Internet media type (what used to be called "MIME type") and intended 260 to be carried around in the payload [RFC6690]. 262 [RFC6690] was the first RFC of the CoRE working group. 264 2.3. Further reading 266 A recent article provides a more detailed overview over the CoRE 267 documents nearing completion [SB]. 269 While the specification documents themselves have to go into 270 meticulous details on every aspect of their protocols, they are the 271 ultimate reference source and are the recommended reading if this 272 basic overview is not sufficient. 274 3. Informational Drafts 276 3.1. Implementation 278 In the IETF, a separate working group is working on informational 279 documents concerning guidance in lightweight implementation of 280 protocols, the LWIG working group. LWIG has several drafts pertinent 281 here: 283 [I-D.ietf-lwig-terminology] provides some common terms that are 284 useful for discussing implementations and specification in the 285 constrained node network space. Section 2 and 3 of this document are 286 quite stable at this time; a new section 4 is in preparation that 287 will include discussion of power-related terminology. 288 [I-D.ietf-lwig-cellular] provides a well-founded discussion of 289 methods for power conservation in CoAP nodes connected via cellular 290 networks, from which some of the material will be used. 292 [I-D.ietf-lwig-guidance] was originally intended as the main working 293 document of the WG. It contains some discussion about CoAP 294 implementation in its section 3.4.2, including the efficient 295 representation of managing duplicate detection state. 296 [I-D.kovatsch-lwig-class1-coap] contains additional considerations 297 that, over time, might move into [I-D.ietf-lwig-guidance]. 298 [I-D.castellani-lwig-coap-separate-responses] contains some examples 299 for message exchanges, focusing on elaborating exchanges involving 300 separate responses. Since IETF86, work is under way to merge the 301 CoAP-related information from these three drafts into a new document, 302 [I-D.kovatsch-lwig-coap]. 304 A new working group has been established in the IETF Security Area to 305 address the use of DTLS In Constrained Environments (DICE); several 306 drafts are available for discussion at IETF88 in Vancouver. On the 307 implementation side, two drafts show how to build minimal 308 implementations of security protocols relevant for CoAP: 309 [I-D.ietf-lwig-tls-minimal] for TLS, which is relevant for CoAP's use 310 of DTLS; and [I-D.ietf-lwig-ikev2-minimal] for IKEv2, the protocol 311 for setting up IPsec security associations. Similarly, 312 [I-D.hartke-core-codtls] looks specifically into the use of DTLS in 313 constrained networks. It raises issues that pertain both to the LWIG 314 and CoRE working groups of the IETF. 316 Further drafts submitted to LWIG address energy efficient 317 implementation [I-D.hex-lwig-energy-efficient] and recent 318 developments in operating systems for constrained devices 319 [I-D.hahm-lwig-painless-constrained-programming]. 321 After a somewhat slow start, LWIG is now picking up considerable 322 energy. 324 3.2. Multicast and Group Communication 326 As it is based on UDP, CoAP easily supports the use of IP multicast 327 to confer messages. However, there are difficult issues around 328 making the desirable multicast applications actually work well. 330 This led to an additional milestone on the CoRE charter: 332 Nov 2012: Using CoAP for group communications to IESG as 333 Informational 335 The informational WG draft [I-D.ietf-core-groupcomm] discusses 336 fundamentals and use cases for group communication with CoAP. This 337 is now very close to Working Group last call. 339 [I-D.dijk-core-groupcomm-misc] gives some additional considerations, 340 listing requirements, providing some taxonomy, proposing deployment 341 guidelines, and discussing approaches that are not (yet?) in the 342 focus of the WG. Its section 5 can serve as an overview over the 343 status of multicast in constrained node/networks. 345 3.3. Security 347 Several individual drafts analyze the issues around the security of 348 constrained devices in constrained networks. 350 [I-D.garcia-core-security] in particular describes the "Thing 351 Lifecycle" and discusses resulting architectural considerations. 353 [I-D.sarikaya-core-secure-bootsolution] documents the approach taken 354 in the ZigBee IP specification (used in Smart Energy Profile 2.0); 355 the CoRE WG currently is not working on replicating this 356 specification as an IETF document. 357 [I-D.jennings-core-transitive-trust-enrollment] demonstrates a 358 specific approach to securing the Thing Lifecycle based on defined 359 roles of security players, including a Manufacturer, an Introducer, 360 and a Transfer Agent. There is considerable interest in the CoRE 361 working group to complete one or more specifications in this space. 363 Further work around Thing Lifecycles was expected to occur in the 364 SOLACE initiative (Smart Object Lifecycle Architecture for 365 Constrained Environments), with its early mailing list at 366 solace@ietf.org -- developed after the model of the COMAN 367 initiative (Management for Constrained Management Networks and 368 Devices, coman@ietf.org, [I-D.ersue-constrained-mgmt]). 370 Besides [I-D.garcia-core-security], recently, more work has been 371 focused on the Authentication and Authorization aspects of CoRE: 373 o [I-D.gerdes-core-dcaf-authorize] 375 o [I-D.greevenbosch-core-authreq] 377 o [I-D.pporamba-dtls-certkey] 379 o [I-D.urien-core-racs] 381 o [I-D.schmitt-two-way-authentication-for-iot] 382 o [I-D.seitz-core-sec-usecases] 384 o [I-D.selander-core-access-control] 386 o [I-D.zhu-core-groupauth] 388 3.4. Intermediaries 390 [I-D.castellani-core-http-mapping] discusses some ideas about what 391 HTTP/CoAP intermediaries could do beyond the basic mapping defined in 392 [I-D.ietf-core-coap]; in the IETF86 WG meeting, this document was 393 agreed as a future working group item (with validation of the 394 adoption on the mailing list still pending). An earlier version of 395 this draft was split into the current document describing best 396 practices for mapping between HTTP and CoAP (beyond what is already 397 described in [I-D.ietf-core-coap]), and one additional document that 398 describes usages that serve as additional useful examples for more 399 advanced forms of mapping, a first draft of the latter is available 400 in [I-D.castellani-core-advanced-http-mapping]. 402 3.5. Congestion Control 404 [I-D.ietf-core-coap] only defines a very basic congestion control 405 scheme that is focused on being safe in a wide variety of 406 applications. Additional documents will define more advanced 407 congestion control schemes that can provide more optimized 408 performance in exchange for more implementation complexity and/or a 409 narrower field of application. 411 Several drafts are contributing to this active subject of discussion 412 in the WG: 414 | draft-bormann-core-congestion-control | -02 | 2012-08-01 | 415 | draft-bormann-core-cocoa | -00 | 2012-08-13 | 417 [I-D.greevenbosch-core-minimum-request-interval] proposes adding an 418 option that allows a server to indicate its desire for some pacing of 419 the requests sent to it by one client; enabling a form of server load 420 control. 422 4. CoAP over X 424 [I-D.becker-core-coap-sms-gprs] shows how to run CoAP over cellular 425 SMS and in mixed SMS/GPRS environments. This draft optionally makes 426 use of an SMS-oriented encoding for CoAP that is described in 427 [I-D.bormann-coap-misc]. 428 [I-D.silverajan-core-coap-alternative-transports] discusses how to 429 indicate the alternative transport in a URI. 431 [I-D.li-core-coap-payload-length-option] defines a way to indicate 432 the length of the payload in case the underlying transport does not 433 provide a suitable definite length indication. 435 5. Optional components of CoRE 437 Additional sub-protocols are being discussed in the IETF that may 438 become optional protocols in CoREs. 440 The present document will track these sub-protocols and be amended 441 once the sub-protocols reach formal status in the IETF. 443 Since the WG is cautious in adopting additional work while the main 444 specifications near completion, none of the additional protocols 445 proposed have become WG documents yet. 447 5.1. CoAP-misc 449 One draft is a little different from the other drafts in this 450 category: [I-D.bormann-coap-misc] is a running document capturing 451 CoAP extensions that are in various states of being cooked. 453 Some of these extensions may finally be adopted for the WG documents 454 and then vanish from CoAP-misc. For other extensions, we may decide 455 that they are not very good ideas. Instead of deleting them from 456 CoAP-misc, they are moved to an appendix. This documents the 457 approach, the best implementation of that approach that was reached, 458 and the reasons why it was not adopted. This documentation should 459 spare the WG and its contributors from the continuous reinvention of 460 bad ideas. 462 As of the time of writing, the main body of CoAP-misc is almost 463 empty, as most urgent developments have found their way into the WG 464 documents, and many other ideas wait in the "nursery" section of the 465 document. 467 5.2. Generalizing Media Types 469 CoAP defines a registry for combinations of an Internet Media Type 470 ("MIME type") and a Content Encoding (e.g. some form of compression), 471 enabling its compact encoding of this information in one or two 472 bytes. Each entry in the registry defines a single, fixed set of 473 media type parameters (as in ";charset=utf-8"), if any. This does 474 not work well with media types that rely on more complex combinations 475 of parameter settings. [I-D.doi-core-parameter-option] proposes to 476 add an option to carry parameters for media types. 478 [I-D.fossati-core-multipart-ct] defines a new media type that can 479 carry multiple embedded representations employing different media 480 types using a binary type-length-value format. 482 5.3. Patience, Leisure, Pledge, or: Timing extensions 484 Several proposals intend to extend the amount of information 485 available during an exchange about the timing requirements of the 486 participants. 488 | draft-li-core-coap-patience-option | -01 | 2012-10-22 | 490 Another discussion is in Appendix B.4 of [I-D.bormann-coap-misc]. 492 The question of whether some of this functionality should be 493 introduced into the main WG documents now is currently also the 494 subject of an active issue tracker ticket [CoRE204]. 496 5.4. Extending Observe 498 5.5. Service discovery 500 Basic service discovery is defined in [RFC6690]. A JSON 501 representation of the same information is defined in 502 [I-D.ietf-core-links-json]. The intention is to make this 503 information available in an equivalent format that is more accessible 504 to classic Web servers, both as a file format (Internet media type) 505 and as a format that can be used in e.g. a JavaScript API. 507 [I-D.arkko-core-dev-urn] defines a new Uniform Resource Name (URN) 508 namespace that can be used to provide hardware device identifiers in 509 resource descriptions. 511 [I-D.ietf-core-interfaces] provides additional semantics that can be 512 used to make resource descriptions more directly machine- 513 interpretable. This ties in to a more general discussion about CoRE 514 profiles that has only just begun. 516 [I-D.greevenbosch-core-profile-description] ties into this and 517 defines a basic JSON format for indicating what CoAP Options and what 518 Content-Formats (still called media-types there) are available for a 519 resource. At IETF86 there was fairly good consensus in the CoRE WG 520 that we should be working on something addressing the underlying 521 problem statement, while there was not yet agreement on the specific 522 solution. 524 [I-D.fossati-core-fp-link-format-attribute] defines a link-format 525 attribute that indicates a certain resource is best reached via a 526 specific proxy. 528 5.6. Server discovery, Naming, etc. 530 On the boundary between service and server discovery, resource 531 directory servers provide a way to collect resource descriptions from 532 multiple servers into one accessible location. 534 [I-D.bormann-core-simple-server-discovery] provided a basic way to 535 discover such servers in a constrained node/network without 536 necessarily having to resort to multicast. It has been merged into 537 [I-D.ietf-core-resource-directory], which defines protocol elements 538 that can be used for setting up such a resource directory. 540 An attempt to merge mDNS/DNS-SD-based discovery (colloquially known 541 as zeroconf or Bonjour), including recent approaches to extend these 542 for constrained networks, into the picture is documented in 543 [I-D.vanderstok-core-dna]; at IETF86 the authors showed interest to 544 continue work on this. 546 5.7. More support for sleepy nodes 548 The basic communication model of CoAP was imported from the Web. 549 This applies well to some communication requirements in constrained 550 node/networks, but leaves some other requirements open. 552 The assumption underlying the current set of WG documents is that the 553 communication layers below the application provide support functions 554 for sleeping nodes. Adding support at the application layer might be 555 able to further reduce the power requirements of "sleepy nodes" that 556 can sleep most of the time. 558 [I-D.rahman-core-sleepy-problem-statement] summarizes the overall 559 problem statement for sleepy nodes without getting into any specific 560 solution. 562 A number of drafts aim to extend the CoAP communication model towards 563 more support for sleepy nodes. 565 The base CoAP spec [I-D.ietf-core-coap] already provides some 566 rudimentary support of sleepy nodes by supporting caching in 567 intermediaries: resources from a sleepy node may be available from a 568 caching proxy (if previously retrieved) even though the node is 569 asleep. [I-D.ietf-core-observe] enhances this support by enabling 570 sleepy nodes to update caching intermediaries on their own schedule. 572 A number of drafts more extensively extend the concept of an 573 intermediary by introducing an additional kind of server that is 574 hosting the resources of the sleepy node: 576 The approach of [I-D.vial-core-mirror-server] is to store the actual 577 resource representations in a special type of Resource Directory 578 called the Mirror Server. Communicating devices can then fetch the 579 resource from the Mirror Server regardless of the state of the sleepy 580 server. ([I-D.vial-core-mirror-proxy] simply appears to be a 581 previous version of this draft.) 583 Similar to the above, the approach of 584 [I-D.fossati-core-publish-option] is to temporarily delegate 585 authority of its resources (when it is sleeping) to a proxy server 586 that is always on. 588 Also, the approach of [I-D.giacomin-core-sleepy-option] is to define 589 a proxy that acts as a store-and-forward agent for a sleepy node. 591 Other drafts introduce a variety of signaling based approaches to 592 facilitate communicating with sleepy nodes: The approach of 593 [I-D.castellani-core-alive] is to define a new CoAP message type 594 (called "Alive") which the sleepy node multicasts to all interested 595 devices when it wakes up. The approach of [I-D.rahman-core-sleepy] 596 is to introduce storing of sleep characteristics in the Resource 597 Directory. Communicating devices can then query the RD to learn the 598 sleep status of the sleepy node before attempting communications. 600 Finally, some drafts build on the concept of the Observe mechanism to 601 help keep track of the sleepy node information. The approach of 602 [I-D.fossati-core-monitor-option] is to extend the Observe pattern to 603 handle the scenario when both server and clients are sleepy nodes. 604 Note that some of the other drafts (e.g., 605 [I-D.vial-core-mirror-server], [I-D.rahman-core-sleepy]) include 606 using/extending the Observe mechanism as part of their overall 607 approach. 609 Support for sleepy nodes is currently a very active subject of 610 discussion in the WG; it is clear that there is a high level of 611 interest in the WG in addressing application-level support for sleepy 612 nodes in future specifications. See also the discussion of 613 [I-D.ietf-lwig-cellular] in Section 3.1 above. 615 6. Replaced drafts 617 Internet-Drafts often get replaced by merged drafts or get promoted 618 to WG drafts. As the relationships between drafts are not always 619 accurately captured by the secretariat tools, this table provides a 620 mapping from current drafts to any previous drafts they are 621 replacing: 623 +------------------------------------+------------------------------+ 624 | current draft | replaced draft | 625 +------------------------------------+------------------------------+ 626 | [I-D.ietf-core-coap] | draft-shelby-core-coap | 627 | | | 628 | [I-D.ietf-core-block] | draft-bormann-core-coap- | 629 | | block | 630 | | | 631 | | draft-li-core-coap-size- | 632 | | option | 633 | | | 634 | [I-D.ietf-core-observe] | draft-hartke-coap-observe | 635 | | | 636 | [RFC6690] | draft-shelby-core-link- | 637 | | format | 638 | | | 639 | [I-D.ietf-core-groupcomm] | draft-rahman-core-groupcomm | 640 | | | 641 | [I-D.becker-core-coap-sms-gprs] | draft-li-core-coap-over-sms | 642 | | | 643 | [I-D.vanderstok-core-dna] | draft-vanderstok-core-bc | 644 | | | 645 | [I-D.ietf-core-resource-directory] | draft-bormann-core-simple- | 646 | | server-discovery | 647 | | | 648 | [I-D.greevenbosch-core-minimum- | draft-greevenbosch-core- | 649 | request-interval] | block-minimum-time | 650 +------------------------------------+------------------------------+ 651 Note that draft-scim-core-schema is just named against the naming 652 conventions and actually unrelated to the CoRE working group. 654 7. IANA Considerations 656 This document has no actions for IANA. 658 8. Security Considerations 660 (None so far; this section will certainly grow as additional security 661 considerations beyond those listed in the base specifications become 662 known.) 664 9. Acknowledgements 666 (The concept for this document is borrowed from [RFC4815], which was 667 invented by Lars-Erik Jonsson. Thanks!) 669 Akbar Rahman contributed text to this roadmap. 671 10. References 673 10.1. Normative References 675 [I-D.ietf-core-block] 676 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 677 draft-ietf-core-block-13 (work in progress), October 2013. 679 [I-D.ietf-core-coap] 680 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 681 Application Protocol (CoAP)", draft-ietf-core-coap-18 682 (work in progress), June 2013. 684 [I-D.ietf-core-observe] 685 Hartke, K., "Observing Resources in CoAP", draft-ietf- 686 core-observe-11 (work in progress), October 2013. 688 [I-D.ietf-tls-oob-pubkey] 689 Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and 690 T. Kivinen, "Using Raw Public Keys in Transport Layer 691 Security (TLS) and Datagram Transport Layer Security 692 (DTLS)", draft-ietf-tls-oob-pubkey-10 (work in progress), 693 October 2013. 695 [I-D.mcgrew-tls-aes-ccm-ecc] 696 McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 697 CCM ECC Cipher Suites for TLS", draft-mcgrew-tls-aes-ccm- 698 ecc-07 (work in progress), August 2013. 700 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 701 Requirement Levels", BCP 14, RFC 2119, March 1997. 703 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 704 Uniform Resource Identifiers (URIs)", RFC 5785, April 705 2010. 707 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 708 Security Version 1.2", RFC 6347, January 2012. 710 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 711 Format", RFC 6690, August 2012. 713 10.2. Informative References 715 [COAP3] ETSI plugtests, "CoAP 3 & OMA Lightweight M2M", 2013, 716 . 718 [CoRE204] Bormann, C., "Introduce a minimal version of Pledge", CoRE 719 ticket #204, 2012, 720 . 722 [I-D.arkko-core-dev-urn] 723 Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource 724 Names for Device Identifiers", draft-arkko-core-dev-urn-03 725 (work in progress), July 2012. 727 [I-D.becker-core-coap-sms-gprs] 728 Becker, M., Li, K., Poetsch, T., and K. Kuladinithi, 729 "Transport of CoAP over SMS", draft-becker-core-coap-sms- 730 gprs-04 (work in progress), August 2013. 732 [I-D.bormann-coap-misc] 733 Bormann, C. and K. Hartke, "Miscellaneous additions to 734 CoAP", draft-bormann-coap-misc-25 (work in progress), May 735 2013. 737 [I-D.bormann-core-simple-server-discovery] 738 Bormann, C., "CoRE Simple Server Discovery", draft- 739 bormann-core-simple-server-discovery-01 (work in 740 progress), March 2012. 742 [I-D.castellani-core-advanced-http-mapping] 743 Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 744 E. Dijk, "Best Practices for HTTP-CoAP Mapping 745 Implementation", draft-castellani-core-advanced-http- 746 mapping-02 (work in progress), July 2013. 748 [I-D.castellani-core-alive] 749 Castellani, A. and S. Loreto, "CoAP Alive Message", draft- 750 castellani-core-alive-00 (work in progress), March 2012. 752 [I-D.castellani-core-http-mapping] 753 Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 754 E. Dijk, "Best Practices for HTTP-CoAP Mapping 755 Implementation", draft-castellani-core-http-mapping-07 756 (work in progress), February 2013. 758 [I-D.castellani-lwig-coap-separate-responses] 759 Castellani, A., "Learning CoAP separate responses by 760 examples", draft-castellani-lwig-coap-separate- 761 responses-00 (work in progress), March 2012. 763 [I-D.dijk-core-groupcomm-misc] 764 Dijk, E. and A. Rahman, "Miscellaneous CoAP Group 765 Communication Topics", draft-dijk-core-groupcomm-misc-04 766 (work in progress), June 2013. 768 [I-D.doi-core-parameter-option] 769 Doi, Y. and K. Lynn, "CoAP Content-Type Parameter Option", 770 draft-doi-core-parameter-option-03 (work in progress), 771 August 2013. 773 [I-D.ersue-constrained-mgmt] 774 Ersue, M., Romascanu, D., and J. Schoenwaelder, 775 "Management of Networks with Constrained Devices: Problem 776 Statement, Use Cases and Requirements", draft-ersue- 777 constrained-mgmt-03 (work in progress), February 2013. 779 [I-D.fossati-core-fp-link-format-attribute] 780 Fossati, T. and S. Loreto, "Resource Discovery through 781 Proxies", draft-fossati-core-fp-link-format-attribute-00 782 (work in progress), July 2012. 784 [I-D.fossati-core-monitor-option] 785 Fossati, T., Giacomin, P., and S. Loreto, "Monitor Option 786 for CoAP", draft-fossati-core-monitor-option-00 (work in 787 progress), July 2012. 789 [I-D.fossati-core-multipart-ct] 790 Fossati, T., "Multipart Content-Format Encoding for CoAP", 791 draft-fossati-core-multipart-ct-03 (work in progress), 792 October 2013. 794 [I-D.fossati-core-publish-option] 795 Fossati, T., Giacomin, P., and S. Loreto, "Publish Option 796 for CoAP", draft-fossati-core-publish-option-02 (work in 797 progress), October 2013. 799 [I-D.garcia-core-security] 800 Garcia-Morchon, O., Kumar, S., Keoh, S., Hummen, R., and 801 R. Struik, "Security Considerations in the IP-based 802 Internet of Things", draft-garcia-core-security-06 (work 803 in progress), September 2013. 805 [I-D.gerdes-core-dcaf-authorize] 806 Gerdes, S., Bergmann, O., and C. Bormann, "Delegated CoAP 807 Authorization Function (DCAF)", draft-gerdes-core-dcaf- 808 authorize-00 (work in progress), July 2013. 810 [I-D.giacomin-core-sleepy-option] 811 Fossati, T., Giacomin, P., Loreto, S., and M. Rossini, 812 "Sleepy Option for CoAP", draft-giacomin-core-sleepy- 813 option-00 (work in progress), February 2012. 815 [I-D.greevenbosch-core-authreq] 816 Greevenbosch, B., "Use cases and requirements for 817 authentication and authorisation in CoAP", draft- 818 greevenbosch-core-authreq-00 (work in progress), September 819 2013. 821 [I-D.greevenbosch-core-minimum-request-interval] 822 Greevenbosch, B., "CoAP Minimum Request Interval", draft- 823 greevenbosch-core-minimum-request-interval-01 (work in 824 progress), April 2013. 826 [I-D.greevenbosch-core-profile-description] 827 Greevenbosch, B., Hoebeke, J., Ishaq, I., and F. Abeele, 828 "CoAP Profile Description Format", draft-greevenbosch- 829 core-profile-description-02 (work in progress), June 2013. 831 [I-D.hahm-lwig-painless-constrained-programming] 832 Hahm, O., Baccelli, E., and K. Schleiser, "Painless Class 833 1 Devices Programming", draft-hahm-lwig-painless- 834 constrained-programming-00 (work in progress), March 2013. 836 [I-D.hartke-core-codtls] 837 Hartke, K. and O. Bergmann, "Datagram Transport Layer 838 Security in Constrained Environments", draft-hartke-core- 839 codtls-02 (work in progress), July 2012. 841 [I-D.hex-lwig-energy-efficient] 842 Cao, Z., He, X., Kovatsch, M., Tian, H., and C. Gomez, 843 "Energy Efficient Implementation of IETF Constrained 844 Protocol Suite", draft-hex-lwig-energy-efficient-02 (work 845 in progress), October 2013. 847 [I-D.ietf-core-groupcomm] 848 Rahman, A. and E. Dijk, "Group Communication for CoAP", 849 draft-ietf-core-groupcomm-16 (work in progress), October 850 2013. 852 [I-D.ietf-core-interfaces] 853 Shelby, Z. and M. Vial, "CoRE Interfaces", draft-ietf- 854 core-interfaces-00 (work in progress), June 2013. 856 [I-D.ietf-core-links-json] 857 Bormann, C., "Representing CoRE Link Collections in JSON", 858 draft-ietf-core-links-json-00 (work in progress), June 859 2013. 861 [I-D.ietf-core-resource-directory] 862 Shelby, Z., Krco, S., and C. Bormann, "CoRE Resource 863 Directory", draft-ietf-core-resource-directory-00 (work in 864 progress), June 2013. 866 [I-D.ietf-lwig-cellular] 867 Arkko, J., Eriksson, A., and A. Keranen, "Building Power- 868 Efficient CoAP Devices for Cellular Networks", draft-ietf- 869 lwig-cellular-00 (work in progress), August 2013. 871 [I-D.ietf-lwig-guidance] 872 Bormann, C., "Guidance for Light-Weight Implementations of 873 the Internet Protocol Suite", draft-ietf-lwig-guidance-03 874 (work in progress), February 2013. 876 [I-D.ietf-lwig-ikev2-minimal] 877 Kivinen, T., "Minimal IKEv2", draft-ietf-lwig- 878 ikev2-minimal-01 (work in progress), October 2013. 880 [I-D.ietf-lwig-terminology] 881 Bormann, C., Ersue, M., and A. Keranen, "Terminology for 882 Constrained Node Networks", draft-ietf-lwig-terminology-05 883 (work in progress), July 2013. 885 [I-D.ietf-lwig-tls-minimal] 886 Kumar, S., Keoh, S., and H. Tschofenig, "A Hitchhiker's 887 Guide to the (Datagram) Transport Layer Security Protocol 888 for Smart Objects and Constrained Node Networks", draft- 889 ietf-lwig-tls-minimal-00 (work in progress), September 890 2013. 892 [I-D.jennings-core-transitive-trust-enrollment] 893 Jennings, C., "Transitive Trust Enrollment for Constrained 894 Devices", draft-jennings-core-transitive-trust- 895 enrollment-01 (work in progress), October 2012. 897 [I-D.kovatsch-lwig-class1-coap] 898 Kovatsch, M., "Implementing CoAP for Class 1 Devices", 899 draft-kovatsch-lwig-class1-coap-00 (work in progress), 900 October 2012. 902 [I-D.kovatsch-lwig-coap] 903 Kovatsch, M., Bergmann, O., Dijk, E., He, X., and C. 904 Bormann, "CoAP Implementation Guidance", draft-kovatsch- 905 lwig-coap-01 (work in progress), July 2013. 907 [I-D.li-core-coap-payload-length-option] 908 Li, K., "CoAP Payload-Length Option Extension", draft-li- 909 core-coap-payload-length-option-02 (work in progress), 910 August 2013. 912 [I-D.pporamba-dtls-certkey] 913 Porambage, P., Kumar, P., Gurtov, A., Ylianttila, M., and 914 E. Harjula, "Certificate based keying scheme for DTLS 915 secured IoT", draft-pporamba-dtls-certkey-00 (work in 916 progress), June 2013. 918 [I-D.rahman-core-sleepy-problem-statement] 919 Rahman, A., Fossati, T., Loreto, S., and M. Vial, "Sleepy 920 Devices in CoAP - Problem Statement", draft-rahman-core- 921 sleepy-problem-statement-01 (work in progress), October 922 2012. 924 [I-D.rahman-core-sleepy] 925 Rahman, A., "Enhanced Sleepy Node Support for CoAP", 926 draft-rahman-core-sleepy-04 (work in progress), October 927 2013. 929 [I-D.sarikaya-core-secure-bootsolution] 930 Sarikaya, B., "Security Bootstrapping Solution for 931 Resource-Constrained Devices", draft-sarikaya-core-secure- 932 bootsolution-00 (work in progress), February 2013. 934 [I-D.schmitt-two-way-authentication-for-iot] 935 Schmitt, C., Stiller, B., Kothmayr, T., and W. Hu, "DTLS- 936 based Security with two-way Authentication for IoT", 937 draft-schmitt-two-way-authentication-for-iot-01 (work in 938 progress), October 2013. 940 [I-D.seitz-core-sec-usecases] 941 Seitz, L., Gerdes, S., and G. Selander, "Use cases for 942 CoRE security", draft-seitz-core-sec-usecases-00 (work in 943 progress), September 2013. 945 [I-D.selander-core-access-control] 946 Selander, G., Sethi, M., and L. Seitz, "Access Control 947 Framework for Constrained Environments", draft-selander- 948 core-access-control-01 (work in progress), October 2013. 950 [I-D.silverajan-core-coap-alternative-transports] 951 Silverajan, B. and T. Savolainen, "CoAP Communication with 952 Alternative Transports", draft-silverajan-core-coap- 953 alternative-transports-03 (work in progress), October 954 2013. 956 [I-D.urien-core-racs] 957 Urien, P., "Remote APDU Call Secure (RACS)", draft-urien- 958 core-racs-00 (work in progress), August 2013. 960 [I-D.vanderstok-core-dna] 961 Stok, P., Lynn, K., and A. Brandt, "CoRE Discovery, 962 Naming, and Addressing", draft-vanderstok-core-dna-02 963 (work in progress), July 2012. 965 [I-D.vial-core-mirror-proxy] 966 Vial, M., "CoRE Mirror Server", draft-vial-core-mirror- 967 proxy-01 (work in progress), July 2012. 969 [I-D.vial-core-mirror-server] 970 Vial, M., "CoRE Mirror Server", draft-vial-core-mirror- 971 server-01 (work in progress), April 2013. 973 [I-D.zhu-core-groupauth] 974 Zhu, J. and M. Qi, "Group Authentication", draft-zhu-core- 975 groupauth-01 (work in progress), September 2013. 977 [REST] Fielding, R., "Architectural Styles and the Design of 978 Network-based Software Architectures", Ph.D. Dissertation, 979 University of California, Irvine, 2000, . 983 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 984 Procedures", BCP 25, RFC 2418, September 1998. 986 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 987 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 988 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 990 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 992 [RFC4815] Jonsson, L-E., Sandlund, K., Pelletier, G., and P. Kremer, 993 "RObust Header Compression (ROHC): Corrections and 994 Clarifications to RFC 3095", RFC 4815, February 2007. 996 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 997 over Low-Power Wireless Personal Area Networks (6LoWPANs): 998 Overview, Assumptions, Problem Statement, and Goals", RFC 999 4919, August 2007. 1001 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 1003 [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, 1004 "Known Issues and Best Practices for the Use of Long 1005 Polling and Streaming in Bidirectional HTTP", RFC 6202, 1006 April 2011. 1008 [SB] Bormann, C., Castellani, A., and Z. Shelby, "CoAP: An 1009 Application Protocol for Billions of Tiny Internet Nodes", 1010 DOI 10.1109/MIC.2012.29, 2012. 1012 [WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded 1013 Internet", ISBN 9780470747995, 2009. 1015 Author's Address 1017 Carsten Bormann 1018 Universitaet Bremen TZI 1019 Postfach 330440 1020 Bremen D-28359 1021 Germany 1023 Phone: +49-421-218-63921 1024 Email: cabo@tzi.org