idnits 2.17.1 draft-jimenez-p2psip-coap-reload-04.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 == Line 442 has weird spacing: '...sorInfo senso...' == Line 465 has weird spacing: '...sorInfo senso...' -- The document date (July 2, 2014) is 3586 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3621' is defined on line 705, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-05 ** Downref: Normative reference to an Informational draft: draft-ietf-p2psip-concepts (ref. 'I-D.ietf-p2psip-concepts') -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP J. Jimenez 3 Internet-Draft Ericsson 4 Intended status: Standards Track J. Lopez-Vega 5 Expires: December 5, 2014 University of Granada 6 J. Maenpaa 7 G. Camarillo 8 Ericsson 9 July 2, 2014 11 A Constrained Application Protocol (CoAP) Usage for REsource LOcation 12 And Discovery (RELOAD) 13 draft-jimenez-p2psip-coap-reload-04 15 Abstract 17 This document defines a Constrained Application Protocol (CoAP) Usage 18 for REsource LOcation And Discovery (RELOAD). The CoAP Usage 19 provides the functionality to federate Wireless Sensor Networks (WSN) 20 in a peer-to-peer fashion. The CoAP Usage also provides a rendezvous 21 service for CoAP Nodes and caching of sensor information. The RELOAD 22 AppAttach method is used to establish a direct connection between 23 nodes through which CoAP messages are exchanged. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 5, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Registering CoAP URIs . . . . . . . . . . . . . . . . . . . . 5 63 5. Rendezvous . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. Forming a direct connection and reading data . . . . . . . . 7 65 7. Caching Mechanisms . . . . . . . . . . . . . . . . . . . . . 9 66 7.1. ProxyCache . . . . . . . . . . . . . . . . . . . . . . . 9 67 7.2. SensorCache . . . . . . . . . . . . . . . . . . . . . . . 10 68 8. CoAP Usage Kinds Definition . . . . . . . . . . . . . . . . . 12 69 8.1. CoAP-REGISTRATION Kind . . . . . . . . . . . . . . . . . 12 70 8.2. CoAP-CACHING Kind . . . . . . . . . . . . . . . . . . . . 12 71 9. Access Control Rules . . . . . . . . . . . . . . . . . . . . 13 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 11.1. RELOAD Sensor Type Registry . . . . . . . . . . . . . . 14 75 11.2. CoAP-REGISTRATION Kind-ID . . . . . . . . . . . . . . . 14 76 11.3. CoAP-CACHING Kind-ID . . . . . . . . . . . . . . . . . . 14 77 11.4. Access Control Policies . . . . . . . . . . . . . . . . 15 78 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 80 12.2. Informative References . . . . . . . . . . . . . . . . . 15 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 83 1. Introduction 85 The Constrained Application Protocol (CoAP) is a specialized web 86 transfer protocol [I-D.ietf-core-coap]. It realizes the 87 Representational State Transfer (REST) architecture for the most 88 constrained nodes, such as sensors and actuators. CoAP can be used 89 not only between nodes on the same constrained network but also 90 between constrained nodes and nodes on the Internet. The latter is 91 possible since CoAP can be translated to Hypertext Transfer Protocol 92 (HTTP) for integration with the web. Application areas of CoAP 93 include different forms of M2M communication, such as home 94 automation, construction, health care or transportation. Areas with 95 heavy use of sensor and actuator devices that monitor and interact 96 with the surrounding environment. 98 The CoAP Usage for RELOAD allows CoAP nodes to store resources in a 99 RELOAD peer-to-peer overlay, provides a rendezvous service, and 100 enables the use of RELOAD overlay as a cache for sensor data. This 101 functionality is implemented in the RELOAD overlay itself, without 102 the use of centralized servers. The CoAP Usage involves three basic 103 functions: 105 Registration: CoAP nodes can use the RELOAD data storage 106 functionality to store a mapping from their CoAP URI to their Node-ID 107 in the overlay, and to retrieve the Node-IDs of other nodes. 109 Rendezvous: Once a CoAP node has identified the Node-ID for an URI it 110 wishes to retrieve, it can use the RELOAD message routing system to 111 set up a direct connection which can be used to exchange CoAP 112 messages. 114 Caching: Nodes can use the RELOAD overlay as a caching mechanism for 115 their sensor information. This is specially useful for battery 116 constrained nodes that can make their data available in the cache 117 provided by the overlay while in sleep mode. 119 For instance, a CoAP proxy (See Section 3) could register its Node-ID 120 (e.g. "9996172") and a list of sensors (e.g. "/temperature-1; 121 ./temperature-2; ./temperature-3") under its URI (e.g. 122 "coap://overlay-1.com/proxy-1/"). 124 When a node wants to discover the values associated with that URI, it 125 queries the overlay for "coap://overlay-1.com/proxy-1/" and gets back 126 the Node-ID of the proxy and the list of its associated sensors. The 127 requesting node can then use the RELOAD overlay to establish a direct 128 connection with the proxy and to read sensor values. 130 Moreover, the CoAP proxy can store the sensor information in the 131 overlay. In this way information can be retrieved directly from the 132 overlay without performing a direct connection to the storing proxy. 134 2. Terminology 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in RFC 2119 [RFC2119]. 140 We use the terminology and definitions from Concepts and Terminology 141 for Peer to Peer SIP [I-D.ietf-p2psip-concepts] and the RELOAD Base 142 Protocol [I-D.ietf-p2psip-base] extensively in this document. 144 3. Architecture 146 In our architecture we extend the different nodes present in RELOAD 147 (Peer, Client) and add support for sensor devices or other 148 constrained devices. Figure 1 illustrates our architecture. The 149 different nodes, according to their functionality are : 151 Client 152 Devices that are capable of participating in a RELOAD overlay as 153 client nodes, that is they do not route messages in the overlay. 155 Router 156 Devices that are members of (i.e., peers in) a RELOAD overlay and 157 capable of forwarding RELOAD messages following a path through the 158 overlay to the destination. 160 Sensor 161 Devices capable of measuring a physical quantity. Sensors usually 162 acquire quantifiable information about their surrounding 163 environment such as: temperature, humidity, electric current, 164 moisture, radiation, and so on. 166 Actuator 167 Devices capable of interacting and affecting their environment 168 such as: electrical motors, pneumatic actuators, electric 169 switches, and so on. 171 Proxy 172 Devices having sufficient resources to run RELOAD either as client 173 or peer. These devices are located at the edge of the sensor 174 network and, in case of Wireless Sensor Networks (WSN), act as 175 coordinators of the network. 177 Physical devices can have one or several of the previous functional 178 roles. According to the functionalities that are present in each of 179 the nodes, they can be: 181 Constrained Node 182 A Constrained Node (CN) is a node with limited computational 183 capabilities. If it is wireless then it will be part of a Low- 184 Rate Wireless Personal Area Network (LR-WPAN), it might be movable 185 and often offer unreliable connectivity. Also, devices will 186 usually be in sleep mode in order to prevent battery drain, and 187 will not communicate during those periods. A CN is NOT part of 188 the RELOAD overlay, therefore it can not act as a client, router 189 nor proxy. A CN is always either a either a Sensor or an 190 Actuator. In the latter case the node is often connected to a 191 continuous energy power supply. 193 RELOAD Node 194 A Reload Node (RN) MUST implement the client functionality in the 195 Overlay. Additionally the node will often be a full RELOAD peer 196 with Proxy functionality. A RN may also be sensor or actuator 197 since it can have those devices connected to it. 199 +------+ 200 | | 201 +--------+ RN +---------+ 202 | | | | 203 +---+--+ +------+ +--+---+ 204 | | | | 205 | RN | | RN | 206 | | | | +------------+ 207 +---+--+ +--+---+ | WSN | 208 | RELOAD | | +----+ | 209 | OVERLAY | | +---+ CN | | 210 +---+--+ +--+---+ | | +----+ | 211 | | | +-----+ | 212 | RN | | PN | | | 213 | | | +-----+ | 214 +---+--+ +------+ +--+---+ | | +----+ | 215 | | | | | +---+ CN | | 216 +--------+ PN +---------+ | +----+ | 217 | | +------------+ 218 +-+--+-+ 219 | | 220 +--------|--|--------+ 221 | +--+ +--+ | 222 | | | | 223 | +--+-+ +-+--+ | 224 | | CN | | CN | | 225 | +----+ +----+ | 226 | WSN | 227 +--------------------+ 229 Figure 1: Architecture 231 4. Registering CoAP URIs 233 CoAP URIs are typically resolved using a DNS. When CoAP is needed in 234 a RELOAD environment, URI resolution is provided by the overlay as a 235 whole. Instead of registering register a URI, a peer stores a 236 CoAPRegistration structure under a hash of its own URI. This uses 237 the CoAP REGISTRATION Kind-ID, which is formally defined in 238 Section 6, and that uses a DICTIONARY data model. 240 As an example, if a CoAP proxy that is located in an overlay 241 overlay-1.com using a Node-ID "9996172" wants to register three 242 different temperature sensors to the URI "coap://overlay-1.com/ 243 proxy-1/.well-known/", it might store the following mapping in the 244 overlay: 246 Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/) 247 KEY = 9996172, 248 VALUE = {./temperature-1; 249 ./temperature-2; 250 ./temperature-3} 252 Note that the Resource-ID stored in the overlay is calculated as hash 253 over the URI (i.e. h(URI)), for instance SHA-1 in RELOAD. 255 This would inform any other node performing a lookup for the previous 256 URI "coap://overlay-1.com/proxy-1/.well-known" that the Node-ID value 257 for proxy-1 is "9996172". In addition, this mapping provides 258 relevant information as to the number of sensors (CNs) and the URI 259 path to connect to them using CoAP. 261 5. Rendezvous 263 The RELOAD overlay supports rendezvous by fetching mapping 264 information between CoAP URIs and Node-IDs. 266 As an example, if a node RN located in the overlay overlay-1.com 267 wishes to read which resources are served at a RN with URI 268 coap://overlay-1.com/proxy-1/, it performs a fetch in the overlay. 269 The Resource-ID used in this fetch is a SHA-1 hash over the URI 270 "coap://overlay-1.com/proxy-1/.well-known/". 272 After this fetch request, the overlay will return the following 273 result: 275 Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/) 276 KEY = 9996172, 277 VALUE = { ./temperature-1; 278 ./temperature-2; 279 ./temperature-3} 281 The obtained KEY is the Node-ID of the RN responsible of this KEY/ 282 VALUE pair. The VALUE is the set of URIs necessary to read data from 283 the CNs associated with the RN. 285 Using the RELOAD DICTIONARY model allows for multiple nodes to 286 perform a store to the same Resource-ID. This feature allows for 287 performing rendezvous with multiple RNs that host CNs of the same 288 class. 290 As an example, a fetch to the URI "coap://overlay-1.com/temperature 291 /.well-known/" could return the following results: 293 Resource-ID = h(coap://overlay-1.com/temperature/.well-known/) 294 KEY = 9992323, 295 VALUE = { ./temperature} 297 KEY = 9996172, 298 VALUE = { ./temperature-1; 299 ./temperature-2; 300 ./temperature-3} 302 KEY = 9996173, 303 VALUE = { ./temp-a; 304 ./temp-b} 306 6. Forming a direct connection and reading data 308 Once a RN (e.g., node-A) has obtained the rendezvous information for 309 a node in the overlay (e.g., proxy-1), it can open a direct 310 connection to that node. This is performed by sending an AppAttach 311 request to the Node-ID obtained during the rendezvous process. 313 After the AppAttach negotiation, node-A can access to the values of 314 the CNs at proxy-1 using the URIs obtained during the rendezvous. 315 Following the example in Section 5, the URIs for accessing to the CNs 316 at proxy-1 would be: 318 coap://overlay-1.com/proxy-1/temperature-1 319 coap://overlay-1.com/proxy-1/temperature-2 320 coap://overlay-1.com/proxy-1/temperature-3 322 Note that the ".well-known" string has been removed from the URIs, as 323 this is only used during CNs discovery. Figure 1 shows a sample of a 324 node reading humidity data. 326 +---+ +-----+ +---------+ +-----+ +---+ 327 |CNA| | PNA | | OVERLAY | | PNB | |CNB| 328 +---+ +-----+ +---------+ +-----+ +---+ 329 | | | | | 330 | .COAP CON GET | | | | 331 | /humidity | 2.RELOAD | | | 332 |+------------->| FetchReq | | | 333 | |+----------->| | | 334 | | | | | 335 | | 3.RELOAD | | | 336 | | FetchAns | | | 337 | |<-----------+| | | 338 | | | | | 339 | | 4.RELOAD | | | 340 | | AppAttach | | | 341 | |+----------->| | | 342 | | | 5.RELOAD | | 343 | | | AppAttach | | 344 | | |+---------->| | 345 | | | | | 346 | | | 6.RELOAD | | 347 | | 7.RELOAD |AppAttachAns| | 348 | |AppAttachAns |<----------+| | 349 | |<-----------+| | | 350 | | | | | 351 | | | | 352 | | --------------------- | | 353 | | / 8.ICE \| | 354 | | \ connectivity checks /| | 355 | | --------------------- | | 356 | | | | 357 | | 9.CoAP CON | | 358 | | GET humidity | | 359 | |+------------------------>| | 360 | | | 10.CoAP CON | 361 | | | GET humidity | 362 | | |+-------------->| 363 | | | 11.CoAP | 364 | | 12.CoAP | ACK 200 | 365 | 12.CoAP | ACK 200 |<--------------+| 366 | ACK 200 |<------------------------+| | 367 |<-------------+| | | 368 | | | | 370 Figure 2: An Example of a Message Sequence 372 7. Caching Mechanisms 374 The CoAP protocol itself supports the caching of sensor information 375 in order to reduce the response time and network bandwidth 376 consumption of future, equivalent requests. This storage is done in 377 CoAP proxies. 379 This CoAP usage proposes an additional caching mechanism for storing 380 sensor information directly in the overlay. This caching mechanism 381 is primarily intended for CNs with sensor capabilities, not for RN 382 sensors. This is due to the battery constrains of CNs, forcing them 383 to stay in sleep mode for long periods of time. 385 Whenever a CN wakes up, it sends the most recent data from its 386 sensors to its proxy (RN), which stores the data in the overlay using 387 a RELOAD StoredData structure defined in Section 6 of the RELOAD base 388 draft [I-D.ietf-p2psip-base]. We use the StoredDataValue structure 389 defined in Section 6.2 of the RELOAD base draft, in particular we use 390 the SingleValue format type to store the cached values in the 391 overlay. From that structure length, storage_time, lifetime and 392 Signature are used in the same way. The only difference is DataValue 393 which in our case can be either a ProxyCache or a SensorCache: 395 enum { reserved (0), proxy_cache(1), sensor_cache(2), (255) } 396 CoAPCachingType; 397 struct { 398 CoAPCachingType coap_caching_type; 400 select(coap_caching_type) { 401 case proxy_cache: ProxyCache proxy_cache_entry; 402 case sensor_cache: SensorCache sensor_cache_entry; 404 /* extensions */ 406 } 407 } CoAPCaching; 409 7.1. ProxyCache 411 ProxyCache is meant to store values and sensor information (e.g. 412 inactivity time) for all the sensors associated with a certain proxy, 413 as well as their CoAP URIs. On the other hand, SensorCache is used 414 for storing the information and cached value of only one sensor (CoAP 415 URI is not necessary, as is the same as the one used for generating 416 the Resource-ID associated to that SensorCache entry). 418 ProxyCache contains the fields Node-ID and series of SensorEntry 419 types. 421 struct { 422 Node-ID Node_ID; 423 uint32 length; 424 SensorEntry sensors[length]; 425 } ProxyCache; 427 Node-D 428 The Node-ID of the Proxy Node (PN) responsible for different 429 sensor devices; 431 length 432 The length of the rest of the structure; 434 Sensor-Entry 435 List of sensors in the form of SensorEntry types; 437 SensorEntry contains the coap_uri, sensor_info and a series of 438 SensorValue types. 440 struct { 441 opaque coap_uri; 442 SensorInfo sensor_info; 443 uint32 length; 444 SensorValue sensor_value[length]; 445 } SensorEntry; 447 coap_uri 448 CoAP name of the sensor device in question; 450 sensor_info 451 contains relevant sensor information; 453 length 454 The length of the rest of the structure; 456 sensor_value 457 contains a list of values stored by the sensor; 459 7.2. SensorCache 461 SensorCache: contains the information related to one sensor. 463 struct { 464 Node-ID Node_ID; 465 SensorInfo sensor_info; 466 uint32 length; 467 SensorValue sensor_value[length]; 468 } SensorCache; 469 Node_ID 470 identifies the Node-ID of the Proxy Node responsible for the 471 sensor; 473 sensor_info 474 contains relevant sensor information; 476 length 477 The length of the rest of the structure; 479 sensor_value 480 contains a list of values stored by the sensor; 482 SensorInfo contains relevant sensor information, such as sensor_type, 483 duration_of_inactivity and c fields. 485 struct { 486 integer sensor_type; 487 uint32 duration_of_inactivity; 488 uint32 last_awake; 490 /* extensions */ 492 } SensorInfo; 494 sensor_type 495 is an integer identifying the type of the sensor. See Figure 3; 497 duration_of_inactivity 498 contains the sleep pattern (if any) that the sensor device 499 follows, specified in seconds; 501 last_awake 502 indicates the last time that the sensor was awake represented as 503 the number of milliseconds elapsed since midnight Jan 1, 1970 UTC 504 not counting leap seconds. This will have the same values for 505 seconds as standard UNIX time or POSIX time; 507 SensorValue contains the measurement_time, lifetime and value. 509 struct { 510 uint32 measurement_time; 511 uint32 lifetime; 512 opaque value; 514 /* extensions */ 516 } SensorValue; 517 measurement_time 518 indicates the moment in which the measure was taken represented as 519 the number of milliseconds elapsed since midnight Jan 1, 1970 UTC 520 not counting leap seconds; 522 lifetime 523 indicates the validity time of that measured value in milliseconds 524 since measurement_time; 526 value 527 indicates the actual value measured. It can be of different types 528 (integer, long, string) therefore opaque has been used; 530 8. CoAP Usage Kinds Definition 532 This section defines the CoAP-REGISTRATION and CoAP-CACHING kinds. 534 8.1. CoAP-REGISTRATION Kind 536 Kind IDs 537 The Resource Name for the CoAP-REGISTRATION Kind-ID is the CoAP 538 URI. The data stored is a CoAPRegistration, which contains a set 539 of CoAP URIs. 541 Data Model 542 The data model for the CoAP-REGISTRATION Kind-ID is dictionary. 543 The dictionary key is the Node-ID of the storing RN. This allows 544 each RN to store a single mapping. 546 Access Control 547 URI-NODE-MATCH. The "coap:" prefix needs to be removed from the 548 COAP URI before matching. See Section 9. 550 Data stored under the COAP-REGISTRATION kind is of type 551 CoAPRegistration, defined below. 553 struct { 554 Node-ID Node_ID; 555 uint16 coap_uris_length; 556 opaque coap_uris (0..2^16-1); 557 } CoAPRegistration; 559 8.2. CoAP-CACHING Kind 561 KindIDs 562 The Resource Name for the CoAP-CACHING Kind-ID is the CoAP URI. 563 The data stored is a CoAPCaching, which contains a cached value. 565 Data Model 566 The data model for the CoAP-CACHING Kind-ID is single value. 568 Access Control 569 URI-MATCH. The "coap:" prefix needs to be removed from the COAP 570 URI before matching. See Section 9. 572 Data stored under the CoAP-CACHING kind is of type CoAPCaching, 573 defined in Section 7. 575 9. Access Control Rules 577 As specified in RELOAD base [I-D.ietf-p2psip-base], every kind which 578 is storable in an overlay must be associated with an access control 579 policy. This policy defines whether a request from a given node to 580 operate on a given value should succeed or fail. Usages can define 581 any access control rules they choose, including publicly writable 582 values. 584 CoAP Usage for RELOAD requires an access control policy that allows 585 multiple nodes in the overlay read and write access. This access is 586 for registering and caching information using CoAP URIs as 587 identifiers. Therefore, none of the access control policies 588 specified in RELOAD base are sufficient [I-D.ietf-p2psip-base]. 590 This document defines two access control policies , called URI-MATCH 591 and URI-NODE-MATCH. In URI-MATCH policy, a given value MUST be 592 written and overwritten if and only if the signer's certificate has 593 an associated URI which canonicalized form hashes (using the hash 594 function for the overlay) to the Resource-ID for the resource. 596 In URI-NODE-MATCH policy, a given value MUST be written and 597 overwritten if and only if the signer's certificate has an associated 598 URI which canonicalized form hashes (using the hash function for the 599 overlay) to the Resource-ID for the resource. In addition, the 600 dictionary key MUST be equal to the Node-ID in the certificate and 601 that Node-ID MUST be the one indicated in the SignerIdentity value 602 cert_hash. 604 These Access Control Policies are specified for IANA in 605 Section Section 11.4. 607 10. Security Considerations 609 TBD. 611 11. IANA Considerations 613 11.1. RELOAD Sensor Type Registry 615 IANA SHALL create a "RELOAD sensor type" Registry. Entries in this 616 registry are 16-bit integers denoting method codes as described in 617 Section 7. The initial contents of this registry are: 619 +-----------------+-------+ 620 | Code Name | Value | 621 +-----------------+-------+ 622 | temperature | 0 | 623 | humidity | 1 | 624 | acceleration | 2 | 625 | pressure | 3 | 626 | altitude | 4 | 627 | luminance | 5 | 628 | velocity | 6 | 629 | signal_strength | 7 | 630 | battery | 8 | 631 | heart_rate | 9 | 632 +-----------------+-------+ 634 Figure 3 636 11.2. CoAP-REGISTRATION Kind-ID 638 This document introduces one additional data Kind-ID to the "RELOAD 639 Data Kind-ID" Registry: 641 +-------------------+------------+----------+ 642 | Kind | Kind-ID | RFC | 643 +-------------------+------------+----------+ 644 | CoAP-REGISTRATION | 105 | RFC-AAAA | 645 +-------------------+------------+----------+ 647 This Kind-ID was defined in Section 4. 649 11.3. CoAP-CACHING Kind-ID 651 This document introduces one additional data Kind-ID to the "RELOAD 652 Data Kind-ID" Registry: 654 +--------------+------------+----------+ 655 | Kind | Kind-ID | RFC | 656 +--------------+------------+----------+ 657 | CoAP-CACHING | 106 | RFC-AAAA | 658 +--------------+------------+----------+ 660 This Kind-ID was defined in Section 4. 662 11.4. Access Control Policies 664 IANA SHALL create a "CoAP Usage for RELOAD Access Control Policy" 665 Registry. Entries in this registry are strings denoting access 666 control policies, as described in Section 8.1. New entries in this 667 registry SHALL be registered via RFC 5226 [RFC5226]. Standards 668 Action. The initial contents of this registry are: 670 +-----------------+----------+ 671 | Access Policy | RFC | 672 +-----------------+----------+ 673 | URI-NODE-MATCH | RFC-AAAA | 674 | URI-MATCH | RFC-AAAA | 675 +-----------------+----------+ 677 This access control policy was described in Section 9. 679 12. References 681 12.1. Normative References 683 [I-D.ietf-core-coap] 684 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 685 Application Protocol (CoAP)", draft-ietf-core-coap-18 686 (work in progress), June 2013. 688 [I-D.ietf-p2psip-base] 689 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 690 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 691 Base Protocol", draft-ietf-p2psip-base-26 (work in 692 progress), February 2013. 694 [I-D.ietf-p2psip-concepts] 695 Bryan, D., Matthews, P., Shim, E., Willis, D., and S. 696 Dawkins, "Concepts and Terminology for Peer to Peer SIP", 697 draft-ietf-p2psip-concepts-05 (work in progress), July 698 2013. 700 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 701 Requirement Levels", BCP 14, RFC 2119, March 1997. 703 12.2. Informative References 705 [RFC3621] Berger, A. and D. Romascanu, "Power Ethernet MIB", RFC 706 3621, December 2003. 708 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 709 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 710 May 2008. 712 Authors' Addresses 714 Jaime Jimenez 715 Ericsson 716 Hirsalantie 11 717 Jorvas 02420 718 Finland 720 Email: jaime.jimenez@ericsson.com 722 Jose M. Lopez-Vega 723 University of Granada 724 CITIC UGR Periodista Rafael Gomez Montero 2 725 Granada 18071 726 Spain 728 Email: jmlvega@ugr.es 730 Jouni Maenpaa 731 Ericsson 732 Hirsalantie 11 733 Jorvas 02420 734 Finland 736 Email: jouni.maenpaa@ericsson.com 738 Gonzalo Camarillo 739 Ericsson 740 Hirsalantie 11 741 Jorvas 02420 742 Finland 744 Email: gonzalo.camarillo@ericsson.com