idnits 2.17.1 draft-groves-coap-webrtcdc-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: On establishment of the CoAP over WebRTC DC the client and server MAY send a CoAP Capability and Settings message (CSM see Section 4.3/[I-D.ietf-core-coap-tcp-tls]) as its first message on the connection to establish CoAP specific capabilities. Any capabilities signalled SHALL not contradict previously negotiated chracteristics. Consideration for the individual options are below: == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: WebRTC DCs allows the indication of whether a SCTP user message is empty through the use of PPIDs (WebRTC String Empty and WebRTC Binary Empty). CoAP defines the use of empty messages. However from the perspective of SCTP these CoAP messages would still contain header information thus PPIDs for empty data MUST not be used. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: CoAP uses an Empty Confirmable message to provoke a Reset message to check the liveness of an endpoint (so called "CoAP" ping). In WebRTC liveness and the ability to send data is determined through the usage of Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness [RFC7675]. Therefore endpoints utilising CoAP over WebRTC DC MUST not use CoAP "reset" messages. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: CoAP also uses Empty messages to acknowledge a request. This is not required due to the SCTP level acknowledgement. Therefore Empty messages MUST not be used with CoAP over WebRTC. -- The document date (April 19, 2017) is 2564 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-28) exists of draft-ietf-mmusic-data-channel-sdpneg-12 == Outdated reference: A later version (-26) exists of draft-ietf-mmusic-sctp-sdp-25 == Outdated reference: A later version (-26) exists of draft-ietf-rtcweb-jsep-20 == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-18 == Outdated reference: A later version (-12) exists of draft-ietf-rtcweb-security-08 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-12 == Outdated reference: A later version (-13) exists of draft-ietf-tsvwg-sctp-ndata-09 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-11) exists of draft-ietf-core-coap-tcp-tls-07 == Outdated reference: A later version (-11) exists of draft-silverajan-core-coap-alternative-transports-09 Summary: 4 errors (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group C. Groves 3 Internet-Draft 4 Intended status: Informational W. Yang 5 Expires: October 21, 2017 Huawei 6 April 19, 2017 8 A WebRTC Data Channel Transport for the Constrained Application Protocol 9 (CoAP) 10 draft-groves-coap-webrtcdc-02 12 Abstract 14 The WebRTC framework defines a generic transport service allowing 15 WEB-browsers and other endpoints to exchange generic data from peer 16 to peer utilizing a Stream Control Transmission Protocol (SCTP) 17 transport. This service is known as Web Real Time Communication 18 WebRTC data channels (WebRTC DC). The use of WebRTC DCs for the 19 Constrained Application Protocol (CoAP) allows WebRTC enabled devices 20 to exchange CoAP data between peers in a secure reliable manner. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 21, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 58 3. Constrained Application Protocol . . . . . . . . . . . . . . 5 59 3.1. Message Model . . . . . . . . . . . . . . . . . . . . . . 5 60 3.2. Request Response Model . . . . . . . . . . . . . . . . . 6 61 3.3. Intermediaries and Caching . . . . . . . . . . . . . . . 7 62 3.4. Resource Discovery . . . . . . . . . . . . . . . . . . . 7 63 3.5. Opening Handshake . . . . . . . . . . . . . . . . . . . . 7 64 3.6. Message Format . . . . . . . . . . . . . . . . . . . . . 8 65 3.7. Option Format and Value . . . . . . . . . . . . . . . . . 9 66 4. Message Transmission . . . . . . . . . . . . . . . . . . . . 9 67 4.1. Messages and Endpoints . . . . . . . . . . . . . . . . . 10 68 4.2. Messages Transmitted Reliably . . . . . . . . . . . . . . 10 69 4.3. Messages Transmitted without Reliability . . . . . . . . 11 70 4.4. Message Correlation . . . . . . . . . . . . . . . . . . . 11 71 4.5. Message Duplication . . . . . . . . . . . . . . . . . . . 11 72 4.6. Message Size . . . . . . . . . . . . . . . . . . . . . . 11 73 4.7. Congestion Control . . . . . . . . . . . . . . . . . . . 12 74 4.8. Transmission Parameters . . . . . . . . . . . . . . . . . 12 75 5. Request/Response Semantics . . . . . . . . . . . . . . . . . 12 76 6. CoAP URI . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 6.1. coaps+wr URI scheme . . . . . . . . . . . . . . . . . . . 13 78 7. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 7.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 13 80 7.2. Resource Discovery . . . . . . . . . . . . . . . . . . . 14 81 8. Multicast CoAP . . . . . . . . . . . . . . . . . . . . . . . 14 82 9. Securing CoAP . . . . . . . . . . . . . . . . . . . . . . . . 14 83 10. Interworking . . . . . . . . . . . . . . . . . . . . . . . . 14 84 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 85 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 12.1. New WebRTC DC Protocol Value . . . . . . . . . . . . . . 15 87 12.2. Secure Service Name and Port Number Registration . . . . 16 88 12.3. ALPN Protocol ID . . . . . . . . . . . . . . . . . . . . 16 89 12.4. URI Schemes . . . . . . . . . . . . . . . . . . . . . . 16 90 12.5. New SIP Media Feature Tag . . . . . . . . . . . . . . . 16 91 13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 93 15. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 95 16.1. Normative References . . . . . . . . . . . . . . . . . . 19 96 16.2. Informative References . . . . . . . . . . . . . . . . . 22 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 100 1. Introduction 102 Whilst the Constrained Application Protocol (CoAP) [RFC7252] was 103 designed for Internet of Things (IoT) deployments in constrained 104 network environments its ready adoption has seen the use of it in a 105 multitude of different network environments. For example 106 [I-D.silverajan-core-coap-alternative-transports] provides use cases 107 for alternate CoAP transports. 109 [I-D.ietf-core-coap-tcp-tls] highlights a number of issues using the 110 native User Datagram Transport (UDP) and envisages deployments more 111 closely integrated with a Web environment. It also proposes the use 112 of the WebSocket protocol [RFC6455]. The use of CoAP over WebRTC DCs 113 has not yet been discussed. 115 WebRTC is a framework [I-D.ietf-rtcweb-overview] that defines real 116 time protocols for browser-based applications. It allows 117 communications between peer WebRTC endpoints (e.g. browsers) without 118 the need to communicate through a web server. 120 In addition to protocols for the realtime transport of audio and 121 video, the transport of generic peer-to-peer non-media data has been 122 defined using WebRTC DCs. The non-media data is transported using 123 the Stream Control Transmission Protocol (SCTP) [RFC4960] 124 encapsulated in the Datagram Transport Layer Security (DTLS) 125 [RFC6347]. It allows both reliable and partially reliable transport 126 and provides confidentiality, source authenticated and integrity 127 protected transfers. The use of Interactive Connectivity 128 Establishment (ICE) [RFC5245] allows network address translator (NAT) 129 traversal. The SCTP/DTLS association may be shared with existing 130 audio and video streams enabling multiplexing of several data streams 131 over a single port further facilitating NAT traversal. 133 Use cases for WebRTC DCs (section 3.1/[I-D.ietf-rtcweb-data-channel] 134 envisage scenarios where the real-time gaming experience is enhanced 135 by additional object state information. Additional scenarios are 136 considered where information such as heart rate sensor or oxygen 137 saturation sensors could augment audio and video in remote medicine 138 scenarios. The transport of such sensor information is what CoAP has 139 been designed for. 141 This is illustrated in Figure 1 showing the WebRTC Trapeziod with 142 added sensor/CoAP information. The left hand side WebRTC endpoint 143 acts as a CoAP to CoAP proxy. 145 +-----------+ +-----------+ 146 | Web | | Web | 147 | | Signaling | | 148 | |-------------| | 149 | Server | path | Server | 150 | | | | 151 +-----------+ +-----------+ 152 / \ 153 / \ Application- 154 / \ defined over 155 / \ HTTP/Websockets 156 / Application-defined over \ 157 / HTTP/Websockets \ 158 / \ 159 +-----------+ +-----------+ 160 |JS/HTML/CSS| |JS/HTML/CSS| 161 +-----------+ +-----------+ 162 +-----------+ +-----------+ 163 SensorA | | | | 164 CoAP/UDP | | | | 165 +------+ Browser | ------------------------- | Browser + 166 | | Media path | | 167 | | (CoAP/WebRTC DC) | | 168 +-----------+ +-----------+ 170 Figure 1: CoAP and WebRTC Trapeziod 172 By utilizing the WebRTC DC (SCTP over DTLS over ICE/UDP (or ICE/TCP)) 173 transport for CoAP a number of important features are inherited 174 including: congestion control, order and unordered messages delivery, 175 large message transmission by providing segmentation and reassembly 176 and multiple unidirectional streams. A more detailed analysis of the 177 benefits of WebRTC DCs can be found in section 178 5/[I-D.ietf-rtcweb-data-channel]. [I-D.ietf-tsvwg-sctp-dtls-encaps] 179 describes the usage of SCTP over DTLS. 181 WebRTC defines in-band and out-of-band methods for establishing a 182 data channel and indicating its characteristics. The Data Channel 183 Establishment Protocol (DCEP) [I-D.ietf-rtcweb-data-protocol] 184 provides an in band means of establishing individual data channels. 185 [I-D.ietf-mmusic-data-channel-sdpneg] uses the Session Description 186 Protocol (SDP) [RFC4566] to provide an out-of-band means to establish 187 data channels. 189 By defining the use of CoAP over WebRTC DC it negates the need for 190 the WebRTC endpoint to interwork between any CoAP messages received 191 from local devices to a proprietary WebRTC DC format when signalling 192 a remote WebRTC endpoint. 194 The SCTP Payload Protocol Identifier (PPID) allows the identification 195 of whether a UTF-8 or Binary encoding is being used and thus 196 facilitates the use of text or binary CoAP protocol serializations. 198 2. Requirements Language 200 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 201 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 202 "OPTIONAL" in this document are to be interpreted as described in 203 [RFC2119]. 205 3. Constrained Application Protocol 207 This section describes the use of CoAP over WebRTC DC as a delta to 208 the information contained in section 2/[RFC7252]. 210 Figure 2 shows the CoAP abstract layering as applied to the WebRTC 211 framework. 213 +---------------------------+ 214 | Application | 215 +------+------+-------------+ \ 216 | DCEP | Requests/Responses | | 217 | +--------------------| | CoAP 218 | | Messages | | 219 +------+--------------------+ / 220 | SCTP | 221 +-----------------------------------------+ 222 | STUN | SRTP | DTLS | 223 +-----------------------------------------+ 224 | ICE | 225 +-----------------------------------------+ 226 | UDP1 | UDP2 | UDP3 | ... | 227 +-----------------------------------------+ 229 Figure 2: WebRTC protocol layers including CoAP 231 WebRTC DC mandates the use of SCTP over DTLS. Whilst the above 232 diagram indicates the use of ICE over UDP the use of TCP is also 233 possible in fall back scenarios. 235 3.1. Message Model 237 WebRTC DC allows application protocol messages to be exchanged by 238 peers. WebRTC supports both a reliable and partially reliable 239 methods of transmitting user messages. 241 CoAP [RFC7252] supports four message types "Confirmable, Non- 242 Confirmable, Acknowledge and Reset". As SCTP provides the 243 reliability mechanism the CoAP message types are not needed for CoAP 244 over WebRTC DC. 246 WebRTC DC does not support multicast usage. 248 3.2. Request Response Model 250 WebRTC DCs are realized as a pair of one incoming and one outgoing 251 SCTP stream (with the same identifier) allowing bi-directional 252 communication. Each channel has properties (see section 253 6.4/[I-D.ietf-rtcweb-data-channel] as discussed below: 255 o reliable or unreliable message transmission: WebRTC DCs support 256 the per message indication whether user messages are reliable or 257 partially reliable. Partial reliability indicates that message 258 retransmission is limited to a certain number of retransmissions 259 or lifetime. This loosely parallels to the CoAP usage of 260 Confirmable (CON) or Non-confirmable (NON) messages. 262 o in-order or out-of-order message delivery: WebRTC DCs support the 263 per message indication whether user messages are delivered in or 264 out of order. CoAP has been designed for unreliable transports 265 and therefore assumes that messages may arrive out-of-order. CoAP 266 implements a lightweight reliability mechanism to deal with this 267 issue. 269 o priority: WebRTC DCs allows a priority to specified for stream 270 scheduling. The usage of this is application specific. Usage of 271 CoAP has no impact on this parameter. It's up to the application 272 using CoAP to set this indication. 274 o an optional label: This is an application/implementation specific 275 label. Uniqueness is not guaranteed. Usage of CoAP has no impact 276 on this parameter. 278 o an optional protocol: This is used to indicate the application 279 protocol in use. A value is required to identify the usage of 280 CoAP. 282 As discussed above WebRTC DC supports an unreliable / un-ordered 283 delivery of messages. Implementations utilizing these data channel 284 characteristics may use CoAP messages and request/response model 285 largely unchanged. In this case the CoAP reliability mechanisms 286 would be used. However as WebRTC DC's usage of SCTP is reliable or 287 partially reliable there is some redundancy between the functionality 288 that WebRTC DCs and CoAP provides. 290 The redundancies are identified and discussed in section 291 2/[I-D.ietf-core-coap-tcp-tls]. Namely: 293 1. There is no need to carry acknowledgement semantics at a CoAP 294 level. 296 2. There is no need for duplicate delivery detection. This is part 297 of the SCTP layer. 299 3.3. Intermediaries and Caching 301 As CoAP over WebRTC DC is peer to peer no intermediares or caching is 302 expected. 304 3.4. Resource Discovery 306 The usage of CoAP over WebRTC DC has no foreseeable impacts on 307 resource discovery. 309 3.5. Opening Handshake 311 Prior to the establishment of a CoAP over WebRTC DC the 312 characteristics of the SCTP association and data channel may be 313 negotiated by signalling. See Section 4 for further details. For 314 example when using SDP [I-D.ietf-mmusic-sctp-sdp] the use of the "SDP 315 max-message-size" attribute indicates the maximum received SCTP 316 message size. 318 Further characteristics (such as those described in Section 3.2) are 319 negotiated at the establishment of the WebRTC DC. 321 On establishment of the CoAP over WebRTC DC the client and server MAY 322 send a CoAP Capability and Settings message (CSM see 323 Section 4.3/[I-D.ietf-core-coap-tcp-tls]) as its first message on the 324 connection to establish CoAP specific capabilities. Any capabilities 325 signalled SHALL not contradict previously negotiated chracteristics. 326 Consideration for the individual options are below: 328 o Server-Name Setting: CoAP over WebRTC DC clients MAY use the 329 server-name setting option. The initial value is derived based on 330 the signalling method used to establish the WebRTC peer to peer 331 communications. WebRTC does not mandate a signalling method. For 332 example if Websockets is used then the value may be taken from the 333 HTTP host header field. 335 o Max-message size Capability: The CoAP Max-Message-Size shall not 336 exceed the SCTP message size. 338 o Block-wise Transfer Capability: CoAP over WebRTC DC client and 339 server MAY support the use of BERT 340 (Section 5/[I-D.ietf-core-coap-tcp-tls]). See Section 4.6 for 341 message size considerations. 343 o Ping and Pong Messages: Ping and Pong messages MAY be sent by CoAP 344 over WebRTC DC clients and servers. However its use as a basic 345 keepalive is not required as WebRTC defines a method to determine 346 liveness (see Section 4.1). 348 o Release Messages: CoAP over WebRTC DC clients and servers may 349 support the CoAP Release message. On receipt of a release message 350 the CoAP over WebRTC DC SHALL be closed as per Section 4. 352 o Abort Messages: CoAP over WebRTC DC clients and servers may 353 support the CoAP Abort message. Senders SHALL then close the CoAP 354 over WebRTC DC as per Section 4. 356 3.6. Message Format 358 As discussed in [I-D.ietf-core-coap-tcp-tls] the use of a reliable 359 underlying transport allows the use of a modified CoAP header format. 360 The modified format removes the "Type (T)" and "Message ID" fields 361 and introduces a "length" as illustrated below in Figure 3. 363 0 1 2 3 364 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 |Len=13 | TKL | Length (8-bit)| Code | TKL bytes ... 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Options (if any) ... 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 |1 1 1 1 1 1 1 1| Payload (if any) ... 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 Figure 3: CoAP Header with TCP with 8-bit Length in Header 375 CoAP over WebRTC DC implementations shall also use the message format 376 in Figure 3 with the following consideration: 378 o The length field was added for message delimitation to keep 379 messages separate in TCP. WebRTC DC uses the message orientation 380 of SCTP to preserve message boundaries thus the use of single 381 application message per SCTP user message is mandated by the 382 WebRTC framework. The length field shall be set to 0. 384 CoAP [RFC7252] supports the use of different content-formats. WebRTC 385 DC defines the use of PPIDs per SCTP user message as follows: 387 o WebRTC String: to identify a non-empty JavaScript string encoded 388 in UTF-8. 390 o WebRTC Binary: to identify a non-empty JavaScript binary data 391 (ArrayBuffer, ArrayBufferView or Blob). 393 Depending on the content-format (see section 12.3/[RFC7252]) an 394 appropriate PPID to the encoding type SHOULD be used to minimise the 395 need for translating between encodings. For example content type of 396 "text/plain" would result in the use of PPID "WebRTC String". 398 Author's note: Specific mappings for each content-format could be 399 provided however given that the formats may change in the future it 400 may be sufficient to offer broad guidance instead. 402 3.7. Option Format and Value 404 There are no impacts to option formats or values due to the use of 405 CoAP over WebRTC DCs. 407 Author's note: Given that the host is determined by the usage of 408 WebRTC are the Uri-Host and Uri-Port relevant? It would seem that 409 this may be valuable to establish a resource tree independent of 410 WebRTC. 412 4. Message Transmission 414 In order to use a WebRTC DC, a SCTP over DTLS over ICE/UDP (or ICE/ 415 TCP) association must be established. A DTLS connection is 416 established followed by an SCTP association. The out-of-band 417 establishment method through the use of SDP-based Data Channel 418 Negotiation [I-D.ietf-mmusic-data-channel-sdpneg] allows the 419 negotiation of SCTP over DTLS over ICE/UDP as well as the negotiation 420 and establishment of the characteristics of an individual WebRTC DC. 422 The in-band establishment method through the use of the Data Channel 423 Establishment Protocol (DCEP) [I-D.ietf-rtcweb-data-protocol] only 424 allows for the establishment of a WebRTC DC once the SCTP over DTLS 425 is established. It relies on DATA_CHANNEL_OPEN and DATA_CHANNEL_ACK 426 messages on the relevant SCTP stream to negotiate the properties of 427 the channel. A separate SCTP PPID (50) indicates that the SCTP user 428 message is a WebRTC DCEP message to allow de-multiplexing by the 429 endpoint. 431 WebRTC DCs are realized as a pair of one incoming and one outgoing 432 SCTP stream (with the same identifier). Requests are sent on an 433 outgoing SCTP stream and received on the peer incoming stream. The 434 SCTP stream identifier is bound to the WebRTC DC instance at the 435 establishment of the data channel. The establishment protocol 436 provides rules for determining the SCTP stream IDs. 438 WebRTC DC closure (Stream Reset) is supported through the use of the 439 SCTP stream reconfiguration extension defined in [RFC6525]. The SCTP 440 Stream Reconfiguration reset has the effect of setting the numbering 441 sequence of the SCTP stream back to zero. This is separate function 442 to the CoAP "Reset" message. There is no mapping between the SCTP 443 Stream Reset and the CoAP "Reset" message. 445 4.1. Messages and Endpoints 447 As per section 2.5/[I-D.ietf-core-coap-tcp-tls] requests can be sent 448 from both the connecting host and the endpoint that accepted the 449 connection. Who initiated the SCTP/DTLS connection has no bearing on 450 the meaning of the CoAP terms client and server. 452 WebRTC DC mandates the use of DTLS thus the endpoint is identified 453 depending on the security mode. 455 WebRTC DCs allows the indication of whether a SCTP user message is 456 empty through the use of PPIDs (WebRTC String Empty and WebRTC Binary 457 Empty). CoAP defines the use of empty messages. However from the 458 perspective of SCTP these CoAP messages would still contain header 459 information thus PPIDs for empty data MUST not be used. 461 CoAP uses an Empty Confirmable message to provoke a Reset message to 462 check the liveness of an endpoint (so called "CoAP" ping). In WebRTC 463 liveness and the ability to send data is determined through the usage 464 of Session Traversal Utilities for NAT (STUN) Usage for Consent 465 Freshness [RFC7675]. Therefore endpoints utilising CoAP over WebRTC 466 DC MUST not use CoAP "reset" messages. 468 CoAP also uses Empty messages to acknowledge a request. This is not 469 required due to the SCTP level acknowledgement. Therefore Empty 470 messages MUST not be used with CoAP over WebRTC. 472 4.2. Messages Transmitted Reliably 474 For CoAP messages marked as confirmable the sender SHALL use a 475 reliable SCTP user message. 477 A CoAP endpoint MUST use the ordered delivery SCTP service, as 478 described in [RFC4960], for the CoAP protocol. 480 CoAP receivers MUST NOT generate CoAP "ACK" or "reset" messages. 481 SCTP level acknowledgement mechanisms are used. 483 4.3. Messages Transmitted without Reliability 485 WebRTC DC makes use of the SCTP Partial Reliability (SCTP-PR) 486 Extension [RFC3758]. This extension allows a user to indicate on a 487 per message basis how persistent the transport service should be in 488 attempting to send the message to the receiver. One of the benefits 489 of using this extension identified by [RFC3758] is: 491 1. Some application layer protocols may benefit from being able to 492 use a single SCTP association to carry both reliable content, - 493 such as text pages, billing and accounting information, setup 494 signaling - and unreliable content, e.g., state that is highly 495 sensitive to timeliness, where generating a new packet is more 496 advantageous than transmitting an old one. 498 This benefit is also one of the reasons the CoAP "Non-Confirmable" 499 message was introduced. However the SCTP-PR and the CoAP "Non- 500 Confirmable" message mechanisms differs in their approach. The SCTP- 501 PR mechanism focuses on sender side behaviour (e.g. when to abandon 502 retransmission). The CoAP "Non-Confirmable" message focuses on 503 receiver side behaviour (e.g. must not send a CoAP ACK). Even with 504 the use of SCTP-PR an SCTP receiver will send an SCTP level ACK for a 505 successfully received SCTP CHUNK. The CoAP "Non-Confirmable" message 506 has no effect on the SCTP level function. 508 Therefore the use of a CoAP "Non-Confirmable" message type is 509 redundant as the CoAP receiver will never send a CoAP ACK message in 510 response. 512 SCTP-PR provides a complimentary function and thus CoAP senders who 513 send Non-confirmable messages SHALL also use SCTP-PR for that 514 message. 516 4.4. Message Correlation 518 Due to reliability being handled at the SCTP layers the CoAP "Message 519 ID" is not required. 521 4.5. Message Duplication 523 The SCTP layer provides message duplication protection. The CoAP 524 application level procedure is not required. 526 4.6. Message Size 528 The considerations in section 4.1/[I-D.ietf-core-coap-tcp-tls] 529 regarding message size limitations also apply to the use of WebRTC 530 DCs. However [I-D.ietf-rtcweb-data-channel] indicates that senders 531 SHOULD limit the maximum message size to 16KB to avoid monopolization 532 of the SCTP association. Section 5/[I-D.ietf-tsvwg-sctp-dtls-encaps] 533 provides further details regarding segmentation and reassembly and 534 path maximum transmission unit (MTU) discovery. 536 Interleaving of large user messages is supported by an SCTP protocol 537 extension defined in [I-D.ietf-tsvwg-sctp-ndata]. 539 4.7. Congestion Control 541 SCTP provides congestion control on a per-association basis (see 542 section 5/[I-D.ietf-rtcweb-data-channel]. 544 4.8. Transmission Parameters 546 The application level parameters defined in section 4.8/[RFC7252] are 547 not relevant to SCTP. 549 5. Request/Response Semantics 551 Request and response semantics for CoAP over WebRTC DC is as per 552 section 5/[RFC7252] with the following exceptions: 554 o section 5.2/[RFC7252]: separate responses MUST be used. Given 555 that WebRTC DC provides an SCTP level acknowledgement it is not 556 possible to piggy back CoAP responses. 558 o section 5.3.1/[RFC7252]: due to the use of DTLS the advice 559 regarding token use without using TLS is invalid. 561 o section 5.3.2/[RFC7252]: In addition CoAP request/response 562 matching is unique to a particular WebRTC DC (SCTP StreamID pair). 564 o section 5.8/[RFC7252]: It is not possible to use a 4.05 565 piggybacked response. 567 6. CoAP URI 569 CoAP [RFC7252] defines the "coap" and "coaps" URI schemes for 570 identifying CoAP resources and providing a means of locating the 571 resource. [RFC7252] defines these resources for use with CoAP over 572 UDP. 574 Section 8/[RFC7252] (Multicast CoAP), does not apply to the URI 575 schemes defined in the present specification. 577 Resources made available via the "coaps+wr" schemes have no shared 578 identity with the other scheme or with the "coap" or "coaps" scheme, 579 even if their resource identifiers indicate the same authority (the 580 same host listening to the same port). The schemes constitute 581 distinct namespaces and, in combination with the authority, are 582 considered to be distinct origin servers. 584 6.1. coaps+wr URI scheme 586 coaps-wr-URI = "coaps+wr:" "//" host [ ":" port ] path-abempty 587 [ "?" query ] 589 The semantics defined in section 6.3/[RFC7252], apply to this URI 590 scheme, with the following changes: 592 o The port SHALL be omitted. The underlying UDP or TCP port and 593 SCTP port is negotiated prior to the establishment of the CoAP 594 over WebRTC DC. 596 7. Discovery 598 7.1. Service Discovery 600 WebRTC does not define peer discovery mechanisms. Peers discover 601 each other through the use of the ICE protocol. ICE candidates need 602 to be sent from peer to peer via signalling. The Javascript Session 603 Establishment Protocol (JSEP) [I-D.ietf-rtcweb-jsep] details the 604 generic SDP media descriptions for peer endpoints to determine the 605 characteristics of a session. The actual signalling protocol between 606 application servers is unspecified. WebRTC endpoints MUST implement 607 the network functions detailed by JSEP including ICE functionality. 609 Whilst the inter-application server signalling protocol is 610 unspecified, the Session Initiation Protocol (SIP) is able to carry 611 SDP for the purposes of establishing a CoAP over WebRTC DC session. 612 SIP allows the use of media feature tags to indicate user agent 613 capabilities [RFC3840]. In order to indicate that a SIP user agent 614 supports the use of CoAP a new "sip.coap" media feature tag is 615 proposed. A CoAP-capable endpoint SHOULD include this media feature 616 tag in its REGISTER requests and OPTION responses. It SHOULD also 617 include the media feature tag in INVITE and UPDATE [RFC3311] requests 618 and responses. Presence of the media feature tag in the contact 619 field of a requestor response can be used to determine that the far 620 end supports CLUE. 622 The exchange of SDP results in: the underlying transport address 623 (e.g. IPv4 or IPv6), the underlying transport port (e.g. UDP port) 624 the SCTP port and the SCTP StreamID used for the CoAP WebRTC DC being 625 exchanged between the peer endpoints. 627 7.2. Resource Discovery 629 On establishment of a CoAP WebRTC DC endpoints are able to use the 630 resource discovery mechanism defined in [RFC6690] for CoAP resources. 632 8. Multicast CoAP 634 WebRTC DCs do not support multicast. 636 9. Securing CoAP 638 This document defines how to convey CoAP over WebRTC DCs. The WebRTC 639 security architecture [I-D.ietf-rtcweb-security-arch] mandates the 640 use of DTLS for data channels. The use of DTLS 1.2 is compatible 641 with CoAP [RFC7252] which allows makes use of DTLS 1.2. 643 The use of DTLS for WebRTC is detailed in 644 [I-D.ietf-rtcweb-security-arch]. 646 10. Interworking 648 An WebRTC endpoint supporting CoAP may in affect act as a gateway 649 between local sensor devices and a remote peer endpoint. The local 650 sensors may utilise CoAP over an alternate signalling transport such 651 as UDP to the local WebRTC endpoint. The WebRTC endpoint may then 652 utilise CoAP over WebRTC to signal to the remote peer. 654 A CoAP gateway when converting to and from a WebRTC transport will in 655 general perform the following functions: 657 o Map received Empty CoAP message to SCTP level operations and 658 discard the empty message. 660 o Map received ACK message to SCTP level operations and discard the 661 ACK message. 663 o Separate piggy-backed messages. 665 o Provide a mapping between received and sent Tokens in order to 666 match requests and responses. 668 Other behaviour depends on the type of proxy behaviour the gateway is 669 performing. See section 5.7/[RFC7252] for more details. 671 11. Security Considerations 673 Security considerations for WebRTC are discussed in 674 [I-D.ietf-rtcweb-security]. 676 The use of CoAP over WebRTC can potentially negate the risks 677 mentioned in: 679 o section 11.3/[RFC7252] on insecure UDP and multicast being used to 680 aid an amplification attack. 682 o section 11.4/[RFC7252] on IP address spoofing and section 683 11.5/[RFC7252] on Cross-Protocol attacks. 685 o section 11.6/[RFC7252] may also not be relevant as WebRTC 686 endpoints are not expected to be severely constrained. 688 Of particular relevance to the support of CoAP over WebRTC DC is 689 access to local devices. Devices generating CoAP data are 690 essentially the same as cameras and microphones in that they may 691 expose sensitive data about the user or the location of the device. 692 Thus the guidance of section 4.1/[I-D.ietf-rtcweb-security] applies 693 to devices generating CoAP data. Whilst CoAP has been designed for 694 constrained devices where there is no user interface to inform/ 695 request consent, it is assumed that device utilising WebRTC DC for 696 CoAP is more likely at minimum a Class 2 [RFC7228] device that could 697 facilitate consent. 699 The CoAP media feature tag defined by this document tag may be 700 present in sessions not utilising CoAP, which increases the metadata 701 available about the sending device, which can help an attacker 702 differentiate between multiple devices and help them identify 703 otherwise anonymised users via the fingerprint of features their 704 device supports. To prevent this, SIP signalling SHOULD always be 705 encrypted using TLS [RFC5630]. 707 12. IANA Considerations 709 12.1. New WebRTC DC Protocol Value 711 NOTE: This registration is exactly the same as the registration in 712 [I-D.savolainen-core-coap-websockets]. 714 This document requests the registration of the subprotocol name 715 "coap.v1" in the WebSocket Subprotocol Name Registry. 717 o Subprotocol Identifier: coap.v1 718 o Subprotocol Common Name: Constrained Application Protocol (CoAP) 720 o Subprotocol Definition: This document 722 12.2. Secure Service Name and Port Number Registration 724 No need has been identified to register a new service name and port 725 number for CoAP over WebRTC. Port number allocation is dynamic. The 726 use of the SCTP over DTLS over UDP/TCP results in a layering of 727 services. 729 12.3. ALPN Protocol ID 731 [I-D.ietf-core-coap-tcp-tls] defines a new "coap" application 732 protocol negotiation protocol identity. However as the DTLS 733 connection is used to establish a WebRTC application the protocol 734 identifiers defined in [I-D.ietf-rtcweb-alpn] MUST be used. Note: 735 that confidentiality protection does not extend to WebRTC DCs. 737 12.4. URI Schemes 739 This document registers a new URI scheme "coaps+wr" for the use of 740 CoAP over WebRTC DCs. The "coaps+wr" URI schemes can be compared to 741 the "https" URI scheme. 743 The IANA is requested to add this new URI schemes to the registry 744 established with [RFC7595]. 746 12.5. New SIP Media Feature Tag 748 This specification registers a new media feature tag in the SIP 749 [RFC3264] tree per the procedures defined in [RFC2506] and [RFC3840]. 751 Media feature tag name: sip.coap 753 ASN.1 Identifier: 1.3.6.1.8.4.30 755 Summary of the media feature indicated by this tag: This feature tag 756 indicates that the device supports the Constrained Application 757 Protocol (CoAP). 759 Values appropriate for use with this feature tag: Boolean. 761 The feature tag is intended primarily for use in the following 762 applications, protocols, services, or negotiation mechanisms: This 763 feature tag is useful to indicate the support of CoAP. 765 Related standards or documents: This document 766 Security Considerations: Security considerations for this media 767 feature tag are discussed in Section 11. 769 Name(s) and email address(es) of person(s) to contact for further 770 information: 772 o CORE workgroup: core@ietf.org 774 o CORE chairs: core-chairs@ietf.org 776 Intended usage: COMMON 778 13. Examples 780 The example SDP Offer shows a CoAP over WebRTC DC utilising out-of- 781 band negotiation [I-D.ietf-mmusic-data-channel-sdpneg]. It is based 782 on the example in section 7.2/[I-D.ietf-rtcweb-jsep]. Modified lines 783 are indicated with ">>>" at the start of the line. These indicators 784 are NOT part of the SDP syntax. Note: some lines have been broken 785 into two lines for formatting reasons. 787 v=0 788 o=- 4962303333179871723 1 IN IP4 0.0.0.0 789 s=- 790 t=0 0 791 a=group:BUNDLE a1 d1 792 a=ice-options:trickle 793 m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98 794 c=IN IP4 0.0.0.0 795 a=rtcp:9 IN IP4 0.0.0.0 796 a=mid:a1 797 a=msid:57017fee-b6c1-4162-929c-a25110252400 798 e83006c5-a0ff-4e0a-9ed9-d3e6747be7d9 799 a=sendrecv 800 a=rtpmap:96 opus/48000/2 801 a=rtpmap:0 PCMU/8000 802 a=rtpmap:8 PCMA/8000 803 a=rtpmap:97 telephone-event/8000 804 a=rtpmap:98 telephone-event/48000 805 a=maxptime:120 806 a=ice-ufrag:ATEn1v9DoTMB9J4r 807 a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl 808 a=fingerprint:sha-256 809 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 810 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 811 a=setup:actpass 812 a=rtcp-mux 813 a=rtcp-rsize 814 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level 815 a=extmap:2 urn:ietf:params:rtp-hdrext:sdes:mid 816 a=ssrc:1732846380 cname:FocUG1f0fcg/yvY7 818 m=application 0 UDP/DTLS/SCTP webrtc-datachannel 819 c=IN IP4 0.0.0.0 820 a=bundle-only 821 a=mid:d1 822 a=fmtp:webrtc-datachannel max-message-size=65536 823 a=sctp-port 5000 824 a=fingerprint:sha-256 825 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04 826 :BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2 827 a=setup:actpass 828 >>>a=dcmap:0 subprotocol="coap.v1";"label="coap" 830 Figure 4: Example SDP Offer 832 14. Acknowledgements 834 We would like to thank the authors of [I-D.ietf-core-coap-tcp-tls] 835 and [I-D.savolainen-core-coap-websockets] for providing a framework 836 for this document. In addition we would like to thank Carsten 837 Bormann for his feedback on message format. 839 15. Changelog 841 draft-groves-coap-webrtcdc-02: 843 o Keep alive update. No changes. 845 draft-groves-coap-webrtcdc-01: 847 o Updated message format to align with draft-core-coap-tcp-tls-04 849 o Updates to align with draft-core-coap-tcp-tls-04 as a result of 850 the merger with websockets. Added section on opening handshake. 851 Added support of CoAP capability messages and BERT. 853 16. References 855 16.1. Normative References 857 [I-D.ietf-mmusic-data-channel-sdpneg] 858 Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., 859 and J. Marcon, "SDP-based Data Channel Negotiation", 860 draft-ietf-mmusic-data-channel-sdpneg-12 (work in 861 progress), March 2017. 863 [I-D.ietf-mmusic-sctp-sdp] 864 Holmberg, C., Shpount, R., Loreto, S., and G. Camarillo, 865 "Session Description Protocol (SDP) Offer/Answer 866 Procedures For Stream Control Transmission Protocol (SCTP) 867 over Datagram Transport Layer Security (DTLS) Transport.", 868 draft-ietf-mmusic-sctp-sdp-25 (work in progress), March 869 2017. 871 [I-D.ietf-rtcweb-alpn] 872 Thomson, M., "Application Layer Protocol Negotiation for 873 Web Real-Time Communications (WebRTC)", draft-ietf-rtcweb- 874 alpn-04 (work in progress), May 2016. 876 [I-D.ietf-rtcweb-data-channel] 877 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data 878 Channels", draft-ietf-rtcweb-data-channel-13 (work in 879 progress), January 2015. 881 [I-D.ietf-rtcweb-data-protocol] 882 Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Channel 883 Establishment Protocol", draft-ietf-rtcweb-data- 884 protocol-09 (work in progress), January 2015. 886 [I-D.ietf-rtcweb-jsep] 887 Uberti, J., Jennings, C., and E. Rescorla, "Javascript 888 Session Establishment Protocol", draft-ietf-rtcweb-jsep-20 889 (work in progress), March 2017. 891 [I-D.ietf-rtcweb-overview] 892 Alvestrand, H., "Overview: Real Time Protocols for 893 Browser-based Applications", draft-ietf-rtcweb-overview-18 894 (work in progress), March 2017. 896 [I-D.ietf-rtcweb-security] 897 Rescorla, E., "Security Considerations for WebRTC", draft- 898 ietf-rtcweb-security-08 (work in progress), February 2015. 900 [I-D.ietf-rtcweb-security-arch] 901 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 902 rtcweb-security-arch-12 (work in progress), June 2016. 904 [I-D.ietf-tsvwg-sctp-dtls-encaps] 905 Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS 906 Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- 907 dtls-encaps-09 (work in progress), January 2015. 909 [I-D.ietf-tsvwg-sctp-ndata] 910 Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, 911 "Stream Schedulers and User Message Interleaving for the 912 Stream Control Transmission Protocol", draft-ietf-tsvwg- 913 sctp-ndata-09 (work in progress), March 2017. 915 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 916 Requirement Levels", BCP 14, RFC 2119, 917 DOI 10.17487/RFC2119, March 1997, 918 . 920 [RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 921 Registration Procedure", BCP 31, RFC 2506, 922 DOI 10.17487/RFC2506, March 1999, 923 . 925 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 926 with Session Description Protocol (SDP)", RFC 3264, 927 DOI 10.17487/RFC3264, June 2002, 928 . 930 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 931 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 932 2002, . 934 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 935 Conrad, "Stream Control Transmission Protocol (SCTP) 936 Partial Reliability Extension", RFC 3758, 937 DOI 10.17487/RFC3758, May 2004, 938 . 940 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 941 "Indicating User Agent Capabilities in the Session 942 Initiation Protocol (SIP)", RFC 3840, 943 DOI 10.17487/RFC3840, August 2004, 944 . 946 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 947 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 948 July 2006, . 950 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 951 RFC 4960, DOI 10.17487/RFC4960, September 2007, 952 . 954 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 955 (ICE): A Protocol for Network Address Translator (NAT) 956 Traversal for Offer/Answer Protocols", RFC 5245, 957 DOI 10.17487/RFC5245, April 2010, 958 . 960 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 961 Initiation Protocol (SIP)", RFC 5630, 962 DOI 10.17487/RFC5630, October 2009, 963 . 965 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 966 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 967 January 2012, . 969 [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control 970 Transmission Protocol (SCTP) Stream Reconfiguration", 971 RFC 6525, DOI 10.17487/RFC6525, February 2012, 972 . 974 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 975 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 976 . 978 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 979 Constrained-Node Networks", RFC 7228, 980 DOI 10.17487/RFC7228, May 2014, 981 . 983 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 984 Application Protocol (CoAP)", RFC 7252, 985 DOI 10.17487/RFC7252, June 2014, 986 . 988 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 989 and Registration Procedures for URI Schemes", BCP 35, 990 RFC 7595, DOI 10.17487/RFC7595, June 2015, 991 . 993 [RFC7675] Perumal, M., Wing, D., Ravindranath, R., Reddy, T., and M. 994 Thomson, "Session Traversal Utilities for NAT (STUN) Usage 995 for Consent Freshness", RFC 7675, DOI 10.17487/RFC7675, 996 October 2015, . 998 16.2. Informative References 1000 [I-D.ietf-core-coap-tcp-tls] 1001 Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 1002 Silverajan, B., and B. Raymor, "CoAP (Constrained 1003 Application Protocol) over TCP, TLS, and WebSockets", 1004 draft-ietf-core-coap-tcp-tls-07 (work in progress), March 1005 2017. 1007 [I-D.savolainen-core-coap-websockets] 1008 Savolainen, T., Hartke, K., and B. Silverajan, "CoAP over 1009 WebSockets", draft-savolainen-core-coap-websockets-07 1010 (work in progress), June 2016. 1012 [I-D.silverajan-core-coap-alternative-transports] 1013 Silverajan, B. and T. Savolainen, "CoAP Communication with 1014 Alternative Transports", draft-silverajan-core-coap- 1015 alternative-transports-09 (work in progress), December 1016 2015. 1018 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 1019 RFC 6455, DOI 10.17487/RFC6455, December 2011, 1020 . 1022 Authors' Addresses 1024 Christian Groves 1026 Email: cngroves.std@gmail.com 1028 Weiwei Yang 1029 Huawei 1031 Email: tommy@huawei.com