idnits 2.17.1 draft-bormann-core-overview-01.txt: -(3): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(4): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (30 March 2020) is 1489 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-14) exists of draft-ietf-core-coap-pubsub-09 == Outdated reference: A later version (-06) exists of draft-ietf-core-coral-03 == Outdated reference: A later version (-14) exists of draft-ietf-core-echo-request-tag-09 == Outdated reference: A later version (-11) exists of draft-ietf-core-groupcomm-bis-00 == Outdated reference: A later version (-15) exists of draft-ietf-core-href-03 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-07 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-24 == Outdated reference: A later version (-08) exists of draft-ietf-core-stateless-05 == Outdated reference: A later version (-20) exists of draft-ietf-core-yang-cbor-12 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bormann 3 Internet-Draft Universität Bremen TZI 4 Intended status: Informational J. Jiménez 5 Expires: 1 October 2020 Ericsson 6 30 March 2020 8 CoRE Working Group -- Overview 9 draft-bormann-core-overview-01 11 Abstract 13 The IETF "Constrained RESTful Environments" (CoRE) Working Group 14 standardizes application layer protocols that can be used by 15 resource-constrained devices, as can be found in the Internet of 16 Things (IoT). It is part of a cluster of about a dozen IETF WGs 17 defining specifications for these environments. 19 This short document provides an overview of the activities of the 20 CoRE WG as of end of March, 2020. 22 About This Document 24 This document is not intended for publication as an RFC. It provides 25 a snapshot of the current status of the WG, from the personal view of 26 the authors. The intention is to keep it updated, roughly once per 27 physical IETF meeting (or its digital replacement). 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 1 October 2020. 46 Copyright Notice 48 Copyright (c) 2020 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Main Specification . . . . . . . . . . . . . . . . . . . . . 2 64 3. Security . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 4. Operations and Management . . . . . . . . . . . . . . . . . . 3 66 5. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 4 67 6. Further Information . . . . . . . . . . . . . . . . . . . . . 4 68 7. Informative References . . . . . . . . . . . . . . . . . . . 4 69 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 72 1. Introduction 74 The IETF "Constrained RESTful Environments" (CoRE) Working Group 75 standardizes application layer protocols that can be used by 76 resource-constrained devices, as can be found in the Internet of 77 Things (IoT). It is part of a cluster of about a dozen IETF WGs that 78 define networking (e.g., 6Lo), routing (e.g., ROLL), and security 79 (e.g., ACE, LAKE, SUIT) for these environments. This cluster has 80 been growing since 2005; ten years ago, on 2010-03-09, CoRE was added 81 to it. 83 2. Main Specification 85 The main specification of CoRE is the Constrained Application 86 Protocol (CoAP) [RFC7252]. CoAP is for applications including 87 constrained devices what HTTP is for general purpose applications. 88 By using UDP as the transport protocol as opposed to HTTP's use of 89 TCP, and by removing much of the baggage of of HTTP, CoAP can be run 90 on quite simple platforms and with very little power use. Both 91 protocols share the Representational State Transfer (REST) 92 architecture, the same set of verbs (GET, PUT, POST, DELETE), and 93 quite similar semantics. 95 Since CoAP's approval in 2013, further specifications have been added 96 to support the Observe pattern of change notifications from a server 97 (low-complexity server-push) [RFC7641], to support larger transfers 98 [RFC7959], to add verbs (FETCH, PATCH, and idempotent iPATCH 99 [RFC8132]), and to enable the use of CoAP over TCP [RFC8323]. 100 [RFC8768] recently added a way to detect and mitigate loops in a 101 proxy configuration, motivated by the requirements of the Distributed 102 Denial-of-Service Open Threat Signaling (DOTS 103 [I-D.ietf-dots-signal-channel]) specification. 105 Two further extensions are now in completion: reducing the need for 106 per-request state in clients and proxies [I-D.ietf-core-stateless] 107 (in IETF last call) and improving the security between multiple 108 active requests [I-D.ietf-core-echo-request-tag], further reducing 109 CoAP's exploitability in denial of service attacks (completed 110 working-group last call). 112 3. Security 114 Security has always been a critical enabler for IoT. Similar to the 115 way the HTTP web uses TLS, CoAP was kicked off with a security 116 architecture based on Datagram TLS (DTLS), which provides high levels 117 of security, but does not support end-to-end security in a 118 configuration that includes proxies. Object Security for CoRE 119 (OSCORE) now provides end-to-end security over proxy paths that may 120 include both CoAP and HTTP [RFC8613]. 122 One interesting aspect of OSCORE is that it also supports group 123 communication, as it occurs in multicasting requests to collect 124 responses from a group of nodes. CoAP has supported multicast 125 requests from the outset, and [RFC7390], Group Communication on top 126 of IP multicast, provides additional specification for this. As DTLS 127 only supports unicast, without a security architecture RFC 7390 was 128 published an experimental RFC. Work is now underway to revise this 129 RFC [I-D.ietf-core-groupcomm-bis], which includes making use of the 130 capabilities provided by OSCORE for group communication 131 [I-D.ietf-core-oscore-groupcomm]. Work is now under way in the CoRE, 132 ACE, and LAKE working groups to complement this basis with additional 133 specifications making use of OSCORE and CoAP group communication. 135 4. Operations and Management 137 IoT systems need to support a large number of nodes, which need to be 138 configured and integrated into an IoT system. A discovery and self- 139 description architecture based on web links has been the first 140 product of the WG [RFC6690], which is now being complemented by a 141 registration and discovery function (CoRE Resource Directory 142 [I-D.ietf-core-resource-directory], in IESG processing). 144 Constrained nodes also need management functions. While many IoT 145 SDOs are integrating these right into their IoT data format 146 specifications, the IETF has its own architecture for describing 147 management information, YANG [RFC7950]. The "CORECONF" 148 specifications that are in Working Group Last Call (including YANG- 149 CBOR [I-D.ietf-core-yang-cbor]) make this widely used approach of 150 providing management interfaces available in a highly efficient way 151 that is applicable to constrained environments, as our complement to 152 the established YANG protocols NETCONF and RESTCONF. 154 5. Data Formats 156 While CoAP can be used with many different data formats, a simple 157 CoRE format for sensor and actuator data, Sensor Measurement Lists 158 (SenML), was defined in [RFC8428]. Recently, a number of 159 specifications have been readied in support of SenML that are now 160 undergoing final processing by the RFC editor: Support for the RFC 161 8132 verbs [I-D.ietf-core-senml-etch], and modifications to the SenML 162 units registry [I-D.ietf-core-senml-more-units] that make it more 163 accessible as a basis for data format standards of other Standards 164 Development Organizations (SDOs). A foundation for further data 165 format specification that combines the web-linking approach of RFC 166 6690 with more modern data representation techniques is now being 167 worked on under the name CoRAL [I-D.ietf-core-coral] 168 [I-D.ietf-core-href]; application specifications such as CoAP pubsub 169 [I-D.ietf-core-coap-pubsub] are expected to pivot to this basis. 171 6. Further Information 173 To follow and contribute to CoRE's work, please refer to the core 174 status page (https://tools.ietf.org/wg/core/ 175 (https://tools.ietf.org/wg/core/)) and join the core mailing list: 176 _core@ietf.org_ via https://www.ietf.org/mailman/listinfo/core 177 (https://www.ietf.org/mailman/listinfo/core). 179 7. Informative References 181 [I-D.ietf-core-coap-pubsub] 182 Koster, M., Keranen, A., and J. Jimenez, "Publish- 183 Subscribe Broker for the Constrained Application Protocol 184 (CoAP)", Work in Progress, Internet-Draft, draft-ietf- 185 core-coap-pubsub-09, 30 September 2019, 186 . 189 [I-D.ietf-core-coral] 190 Hartke, K., "The Constrained RESTful Application Language 191 (CoRAL)", Work in Progress, Internet-Draft, draft-ietf- 192 core-coral-03, 9 March 2020, . 195 [I-D.ietf-core-echo-request-tag] 196 Amsuess, C., Mattsson, J., and G. Selander, "CoAP: Echo, 197 Request-Tag, and Token Processing", Work in Progress, 198 Internet-Draft, draft-ietf-core-echo-request-tag-09, 9 199 March 2020, . 202 [I-D.ietf-core-groupcomm-bis] 203 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 204 for the Constrained Application Protocol (CoAP)", Work in 205 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 206 00, 30 March 2020, . 209 [I-D.ietf-core-href] 210 Hartke, K., "Constrained Resource Identifiers", Work in 211 Progress, Internet-Draft, draft-ietf-core-href-03, 9 March 212 2020, . 215 [I-D.ietf-core-oscore-groupcomm] 216 Tiloca, M., Selander, G., Palombini, F., and J. Park, 217 "Group OSCORE - Secure Group Communication for CoAP", Work 218 in Progress, Internet-Draft, draft-ietf-core-oscore- 219 groupcomm-07, 9 March 2020, . 222 [I-D.ietf-core-resource-directory] 223 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 224 Amsuess, "CoRE Resource Directory", Work in Progress, 225 Internet-Draft, draft-ietf-core-resource-directory-24, 9 226 March 2020, . 229 [I-D.ietf-core-senml-etch] 230 Keranen, A. and M. Mohajer, "FETCH & PATCH with Sensor 231 Measurement Lists (SenML)", Work in Progress, Internet- 232 Draft, draft-ietf-core-senml-etch-07, 9 March 2020, 233 . 236 [I-D.ietf-core-senml-more-units] 237 Bormann, C., "Additional Units for SenML", Work in 238 Progress, Internet-Draft, draft-ietf-core-senml-more- 239 units-06, 19 March 2020, . 242 [I-D.ietf-core-stateless] 243 Hartke, K., "Extended Tokens and Stateless Clients in the 244 Constrained Application Protocol (CoAP)", Work in 245 Progress, Internet-Draft, draft-ietf-core-stateless-05, 12 246 March 2020, . 249 [I-D.ietf-core-yang-cbor] 250 Veillette, M., Petrov, I., and A. Pelov, "CBOR Encoding of 251 Data Modeled with YANG", Work in Progress, Internet-Draft, 252 draft-ietf-core-yang-cbor-12, 9 March 2020, 253 . 256 [I-D.ietf-dots-signal-channel] 257 Reddy.K, T., Boucadair, M., Patil, P., Mortensen, A., and 258 N. Teague, "Distributed Denial-of-Service Open Threat 259 Signaling (DOTS) Signal Channel Specification", Work in 260 Progress, Internet-Draft, draft-ietf-dots-signal-channel- 261 41, 6 January 2020, . 264 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 265 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 266 . 268 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 269 Application Protocol (CoAP)", RFC 7252, 270 DOI 10.17487/RFC7252, June 2014, 271 . 273 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 274 the Constrained Application Protocol (CoAP)", RFC 7390, 275 DOI 10.17487/RFC7390, October 2014, 276 . 278 [RFC7641] Hartke, K., "Observing Resources in the Constrained 279 Application Protocol (CoAP)", RFC 7641, 280 DOI 10.17487/RFC7641, September 2015, 281 . 283 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 284 RFC 7950, DOI 10.17487/RFC7950, August 2016, 285 . 287 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 288 the Constrained Application Protocol (CoAP)", RFC 7959, 289 DOI 10.17487/RFC7959, August 2016, 290 . 292 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 293 FETCH Methods for the Constrained Application Protocol 294 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 295 . 297 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 298 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 299 Application Protocol) over TCP, TLS, and WebSockets", 300 RFC 8323, DOI 10.17487/RFC8323, February 2018, 301 . 303 [RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. 304 Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, 305 DOI 10.17487/RFC8428, August 2018, 306 . 308 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 309 "Object Security for Constrained RESTful Environments 310 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 311 . 313 [RFC8768] Boucadair, M., Reddy.K, T., and J. Shallow, "Constrained 314 Application Protocol (CoAP) Hop-Limit Option", RFC 8768, 315 DOI 10.17487/RFC8768, March 2020, 316 . 318 Acknowledgements 320 Marco Tiloca provided comments on a draft of this document. 322 Authors' Addresses 324 Carsten Bormann 325 Universität Bremen TZI 326 Postfach 330440 327 D-28359 Bremen 328 Germany 330 Phone: +49-421-218-63921 331 Email: cabo@tzi.org 332 Jaime Jiménez 333 Ericsson 335 Phone: +358-442-992-827 336 Email: jaime@iki.fi