idnits 2.17.1 draft-jimenez-p2psip-coap-reload-03.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 18, 2013) is 4056 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: 'I-D.ietf-core-coap' is defined on line 663, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 682, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-13 == Outdated reference: A later version (-09) exists of draft-ietf-p2psip-concepts-04 ** Downref: Normative reference to an Informational draft: draft-ietf-p2psip-concepts (ref. 'I-D.ietf-p2psip-concepts') == Outdated reference: A later version (-26) exists of draft-ietf-p2psip-base-24 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 6 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: August 22, 2013 University of Granada 6 J. Maenpaa 7 G. Camarillo 8 Ericsson 9 February 18, 2013 11 A Constrained Application Protocol (CoAP) Usage for REsource LOcation 12 And Discovery (RELOAD) 13 draft-jimenez-p2psip-coap-reload-03 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 August 22, 2013. 42 Copyright Notice 44 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Registering CoAP URIs . . . . . . . . . . . . . . . . . . . . 6 63 5. Rendezvous . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. Forming a direct connection and reading data . . . . . . . . . 7 65 7. Caching Mechanisms . . . . . . . . . . . . . . . . . . . . . . 10 66 7.1. ProxyCache . . . . . . . . . . . . . . . . . . . . . . . . 10 67 7.2. SensorCache . . . . . . . . . . . . . . . . . . . . . . . 11 68 8. CoAP Usage Kinds Definition . . . . . . . . . . . . . . . . . 13 69 8.1. CoAP-REGISTRATION Kind . . . . . . . . . . . . . . . . . . 13 70 8.2. CoAP-CACHING Kind . . . . . . . . . . . . . . . . . . . . 13 71 9. Access Control Rules . . . . . . . . . . . . . . . . . . . . . 14 72 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 74 11.1. RELOAD Sensor Type Registry . . . . . . . . . . . . . . . 15 75 11.2. CoAP-REGISTRATION Kind-ID . . . . . . . . . . . . . . . . 15 76 11.3. CoAP-CACHING Kind-ID . . . . . . . . . . . . . . . . . . . 15 77 11.4. Access Control Policies . . . . . . . . . . . . . . . . . 16 78 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 80 12.2. Informative References . . . . . . . . . . . . . . . . . . 17 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 83 1. Introduction 85 The Constrained Application Protocol (CoAP) is a specialized web 86 transfer protocol. It realizes the Representational State Transfer 87 (REST) architecture for the most constrained nodes, such as sensors 88 and actuators. CoAP can be used not only between nodes on the same 89 constrained network but also between constrained nodes and nodes on 90 the Internet. The latter is possible since CoAP can be translated to 91 Hypertext Transfer Protocol (HTTP) for integration with the web. 92 Application areas of CoAP include different forms of M2M 93 communication, such as home automation, construction, health care or 94 transportation. Areas with heavy use of sensor and actuator devices 95 that monitor and interact with the surrounding environment. 97 The CoAP Usage for RELOAD allows CoAP nodes to store resources in a 98 RELOAD peer-to-peer overlay, provides a rendezvous service, and 99 enables the use of RELOAD overlay as a cache for sensor data. This 100 functionality is implemented in the RELOAD overlay itself, without 101 the use of centralized servers. The CoAP Usage involves three basic 102 functions: 104 1. Registration: CoAP nodes can use the RELOAD data storage 105 functionality to store a mapping from their CoAP URI to their 106 Node-ID in the overlay, and to retrieve the Node-IDs of other 107 nodes. 108 2. Rendezvous: Once a CoAP node has identified the Node-ID for an 109 URI it wishes to retrieve, it can use the RELOAD message routing 110 system to set up a direct connection which can be used to 111 exchange CoAP messages. 112 3. Caching: Nodes can use the RELOAD overlay as a caching mechanism 113 for their sensor information. This is specially useful for 114 battery constrained nodes that can make their data available in 115 the cache provided by the overlay while in sleep mode. 117 For instance, a CoAP proxy (See Section 3) could register its Node-ID 118 (e.g. "9996172") and a list of sensors (e.g. "/temperature-1; 119 ./temperature-2; ./temperature-3") under its URI (e.g. 120 "coap://overlay-1.com/proxy-1/"). 122 When a node wants to discover the values associated with that URI, it 123 queries the overlay for "coap://overlay-1.com/proxy-1/" and gets back 124 the Node-ID of the proxy and the list of its associated sensors. The 125 requesting node can then use the RELOAD overlay to establish a direct 126 connection with the proxy and to read sensor values. 128 Moreover, the CoAP proxy can store the sensor information in the 129 overlay. In this way information can be retrieved directly from the 130 overlay without performing a direct connection to the storing proxy. 132 2. Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [RFC2119]. 138 We use the terminology and definitions from Concepts and Terminology 139 for Peer to Peer SIP [I-D.ietf-p2psip-concepts] and the RELOAD Base 140 Protocol [I-D.ietf-p2psip-base] extensively in this document. 142 3. Architecture 144 In our architecture we extend the different nodes present in RELOAD 145 (Peer, Client) and add support for sensor devices or other 146 constrained devices. Figure 1 illustrates our architecture. The 147 different nodes, according to their functionality are : 149 Client 150 Devices that are capable of participating in a RELOAD overlay as 151 client nodes, that is they do not route messages in the overlay. 152 Router 153 Devices that are members of (i.e., peers in) a RELOAD overlay and 154 capable of forwarding RELOAD messages following a path through the 155 overlay to the destination. 156 Sensor 157 Devices capable of measuring a physical quantity. Sensors usually 158 acquire quantifiable information about their surrounding 159 environment such as: temperature, humidity, electric current, 160 moisture, radiation, and so on. 161 Actuator 162 Devices capable of interacting and affecting their environment 163 such as: electrical motors, pneumatic actuators, electric 164 switches, and so on. 165 Proxy 166 Devices having sufficient resources to run RELOAD either as client 167 or peer. These devices are located at the edge of the sensor 168 network and, in case of Wireless Sensor Networks (WSN), act as 169 coordinators of the network. 171 Physical devices can have one or several of the previous functional 172 roles. According to the functionalities that are present in each of 173 the nodes, they can be: 175 Constrained Node 176 A Constrained Node (CN) is a node with limited computational 177 capabilities. If it is wireless then it will be part of a Low- 178 Rate Wireless Personal Area Network (LR-WPAN), it might be movable 179 and often offer unreliable connectivity. Also, devices will 180 usually be in sleep mode in order to prevent battery drain, and 181 will not communicate during those periods. A CN is NOT part of 182 the RELOAD overlay, therefore it can not act as a client, router 183 nor proxy. A CN is always either a either a Sensor or an 184 Actuator. In the latter case the node is often connected to a 185 continuous energy power supply. 187 Reload Node 188 A Reload Node (RN) MUST implement the client functionality in the 189 Overlay. Additionally the node will often be a full RELOAD peer 190 with Proxy functionality. A RN may also be sensor or actuator 191 since it can have those devices connected to it. 193 +------+ 194 | | 195 +--------+ RN +---------+ 196 | | | | 197 +---+--+ +------+ +--+---+ 198 | | | | 199 | RN | | RN | 200 | | | | +------------+ 201 +---+--+ +--+---+ | WSN | 202 | RELOAD | | +----+ | 203 | OVERLAY | | +---+ CN | | 204 +---+--+ +--+---+ | | +----+ | 205 | | | +-----+ | 206 | RN | | PN | | | 207 | | | +-----+ | 208 +---+--+ +------+ +--+---+ | | +----+ | 209 | | | | | +---+ CN | | 210 +--------+ PN +---------+ | +----+ | 211 | | +------------+ 212 +-+--+-+ 213 | | 214 +--------|--|--------+ 215 | +--+ +--+ | 216 | | | | 217 | +--+-+ +-+--+ | 218 | | CN | | CN | | 219 | +----+ +----+ | 220 | WSN | 221 +--------------------+ 222 Figure 1: Architecture 224 4. Registering CoAP URIs 226 CoAP URIs are typically resolved using a DNS. When CoAP is needed in 227 a RELOAD environment, URI resolution is provided by the overlay as a 228 whole. Instead of registering register a URI, a peer stores a 229 CoAPRegistration structure under a hash of its own URI. This uses 230 the CoAP REGISTRATION Kind-ID, which is formally defined in 231 Section 6, and that uses a DICTIONARY data model. 233 As an example, if a CoAP proxy that is located in an overlay overlay- 234 1.com using a Node-ID "9996172" wants to register three different 235 temperature sensors to the URI 236 "coap://overlay-1.com/proxy-1/.well-known/", it might store the 237 following mapping in the overlay: 239 Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/) 240 KEY = 9996172, 241 VALUE = {./temperature-1; 242 ./temperature-2; 243 ./temperature-3} 245 Note that the Resource-ID stored in the overlay is calculated as hash 246 over the URI (i.e. h(URI)), for instance SHA-1 in RELOAD. 248 This would inform any other node performing a lookup for the previous 249 URI "coap://overlay-1.com/proxy-1/.well-known" that the Node-ID value 250 for proxy-1 is "9996172". In addition, this mapping provides 251 relevant information as to the number of sensors (CNs) and the URI 252 path to connect to them using CoAP. 254 5. Rendezvous 256 The RELOAD overlay supports rendezvous by fetching mapping 257 information between CoAP URIs and Node-IDs. 259 As an example, if a node RN located in the overlay overlay-1.com 260 wishes to read which resources are served at a RN with URI 261 coap://overlay-1.com/proxy-1/, it performs a fetch in the overlay. 262 The Resource-ID used in this fetch is a SHA-1 hash over the URI 263 "coap://overlay-1.com/proxy-1/.well-known/". 265 After this fetch request, the overlay will return the following 266 result: 268 Resource-ID = h(coap://overlay-1.com/proxy-1/.well-known/) 269 KEY = 9996172, 270 VALUE = { ./temperature-1; 271 ./temperature-2; 272 ./temperature-3} 274 The obtained KEY is the Node-ID of the RN responsible of this KEY/ 275 VALUE pair. The VALUE is the set of URIs necessary to read data from 276 the CNs associated with the RN. 278 Using the RELOAD DICTIONARY model allows for multiple nodes to 279 perform a store to the same Resource-ID. This feature allows for 280 performing rendezvous with multiple RNs that host CNs of the same 281 class. 283 As an example, a fetch to the URI 284 "coap://overlay-1.com/temperature/.well-known/" could return the 285 following results: 287 Resource-ID = h(coap://overlay-1.com/temperature/.well-known/) 288 KEY = 9992323, 289 VALUE = { ./temperature} 291 KEY = 9996172, 292 VALUE = { ./temperature-1; 293 ./temperature-2; 294 ./temperature-3} 296 KEY = 9996173, 297 VALUE = { ./temp-a; 298 ./temp-b} 300 6. Forming a direct connection and reading data 302 Once a RN (e.g., node-A) has obtained the rendezvous information for 303 a node in the overlay (e.g., proxy-1), it can open a direct 304 connection to that node. This is performed by sending an AppAttach 305 request to the Node-ID obtained during the rendezvous process. 307 After the AppAttach negotiation, node-A can access to the values of 308 the CNs at proxy-1 using the URIs obtained during the rendezvous. 309 Following the example in Section 5, the URIs for accessing to the CNs 310 at proxy-1 would be: 312 coap://overlay-1.com/proxy-1/temperature-1 313 coap://overlay-1.com/proxy-1/temperature-2 314 coap://overlay-1.com/proxy-1/temperature-3 316 Note that the ".well-known" string has been removed from the URIs, as 317 this is only used during CNs discovery. Figure 1 shows a sample of a 318 node reading humidity data. 320 +---+ +-----+ +---------+ +-----+ +---+ 321 |CNA| | PNA | | OVERLAY | | PNB | |CNB| 322 +---+ +-----+ +---------+ +-----+ +---+ 323 | | | | | 324 | .COAP CON GET | | | | 325 | /humidity | 2.RELOAD | | | 326 |+------------->| FetchReq | | | 327 | |+----------->| | | 328 | | | | | 329 | | 3.RELOAD | | | 330 | | FetchAns | | | 331 | |<-----------+| | | 332 | | | | | 333 | | 4.RELOAD | | | 334 | | AppAttach | | | 335 | |+----------->| | | 336 | | | 5.RELOAD | | 337 | | | AppAttach | | 338 | | |+---------->| | 339 | | | | | 340 | | | 6.RELOAD | | 341 | | 7.RELOAD |AppAttachAns| | 342 | |AppAttachAns |<----------+| | 343 | |<-----------+| | | 344 | | | | | 345 | | | | 346 | | --------------------- | | 347 | | / 8.ICE \| | 348 | | \ connectivity checks /| | 349 | | --------------------- | | 350 | | | | 351 | | 9.CoAP CON | | 352 | | GET humidity | | 353 | |+------------------------>| | 354 | | | 10.CoAP CON | 355 | | | GET humidity | 356 | | |+-------------->| 357 | | | 11.CoAP | 358 | | 12.CoAP | ACK 200 | 359 | 12.CoAP | ACK 200 |<--------------+| 360 | ACK 200 |<------------------------+| | 361 |<-------------+| | | 362 | | | | 364 Figure 2: An Example of a Message Sequence 366 7. Caching Mechanisms 368 The CoAP protocol itself supports the caching of sensor information 369 in order to reduce the response time and network bandwidth 370 consumption of future, equivalent requests. This storage is done in 371 CoAP proxies. 373 This CoAP usage proposes an additional caching mechanism for storing 374 sensor information directly in the overlay. This caching mechanism 375 is primarily intended for CNs with sensor capabilities, not for RN 376 sensors. This is due to the battery constrains of CNs, forcing them 377 to stay in sleep mode for long periods of time. 379 Whenever a CN wakes up, it sends the most recent data from its 380 sensors to its proxy (RN), which stores the data in the overlay using 381 a RELOAD StoredData structure defined in Section 6 of the RELOAD base 382 draft [I-D.ietf-p2psip-base]. We use the StoredDataValue structure 383 defined in Section 6.2 of the RELOAD base draft, in particular we use 384 the SingleValue format type to store the cached values in the 385 overlay. From that structure length, storage_time, lifetime and 386 Signature are used in the same way. The only difference is DataValue 387 which in our case can be either a ProxyCache or a SensorCache: 389 enum { reserved (0), proxy_cache(1), sensor_cache(2), (255) } 390 CoAPCachingType; 391 struct { 392 CoAPCachingType coap_caching_type; 394 select(coap_caching_type) { 395 case proxy_cache: ProxyCache proxy_cache_entry; 396 case sensor_cache: SensorCache sensor_cache_entry; 398 /* extensions */ 400 } 401 } CoAPCaching; 403 7.1. ProxyCache 405 ProxyCache is meant to store values and sensor information (e.g. 406 inactivity time) for all the sensors associated with a certain proxy, 407 as well as their CoAP URIs. On the other hand, SensorCache is used 408 for storing the information and cached value of only one sensor (CoAP 409 URI is not necessary, as is the same as the one used for generating 410 the Resource-ID associated to that SensorCache entry). 412 ProxyCache contains the fields Node-ID and series of SensorEntry 413 types. 415 struct { 416 Node-ID Node_ID; 417 uint32 length; 418 SensorEntry sensors[length]; 419 } ProxyCache; 421 Node-ID 422 The Node-ID of the Proxy Node (PN) responsible for different 423 sensor devices; 424 length 425 The length of the rest of the structure; 426 SensorEntry 427 List of sensors in the form of SensorEntry types; 429 SensorEntry contains the coap_uri, sensor_info and a series of 430 SensorValue types. 432 struct { 433 opaque coap_uri; 434 SensorInfo sensor_info; 435 uint32 length; 436 SensorValue sensor_value[length]; 437 } SensorEntry; 439 coap_uri 440 CoAP name of the sensor device in question; 441 sensor_info 442 contains relevant sensor information; 443 length 444 The length of the rest of the structure; 445 sensor_value 446 contains a list of values stored by the sensor; 448 7.2. SensorCache 450 SensorCache: contains the information related to one sensor. 452 struct { 453 Node-ID Node_ID; 454 SensorInfo sensor_info; 455 uint32 length; 456 SensorValue sensor_value[length]; 457 } SensorCache; 458 Node_ID 459 identifies the Node-ID of the Proxy Node responsible for the 460 sensor; 461 sensor_info 462 contains relevant sensor information; 463 length 464 The length of the rest of the structure; 465 sensor_value 466 contains a list of values stored by the sensor; 468 SensorInfo contains relevant sensor information, such as sensor_type, 469 duration_of_inactivity and c fields. 471 struct { 472 integer sensor_type; 473 uint32 duration_of_inactivity; 474 uint32 last_awake; 476 /* extensions */ 478 } SensorInfo; 480 sensor_type 481 is an integer identifying the type of the sensor. See Figure 3; 482 duration_of_inactivity 483 contains the sleep pattern (if any) that the sensor device 484 follows, specified in seconds; 485 last_awake 486 indicates the last time that the sensor was awake represented as 487 the number of milliseconds elapsed since midnight Jan 1, 1970 UTC 488 not counting leap seconds. This will have the same values for 489 seconds as standard UNIX time or POSIX time; 491 SensorValue contains the measurement_time, lifetime and value. 493 struct { 494 uint32 measurement_time; 495 uint32 lifetime; 496 opaque value; 498 /* extensions */ 500 } SensorValue; 501 measurement_time 502 indicates the moment in which the measure was taken represented as 503 the number of milliseconds elapsed since midnight Jan 1, 1970 UTC 504 not counting leap seconds; 505 lifetime 506 indicates the validity time of that measured value in milliseconds 507 since measurement_time; 508 value 509 indicates the actual value measured. It can be of different types 510 (integer, long, string) therefore opaque has been used; 512 8. CoAP Usage Kinds Definition 514 This section defines the CoAP-REGISTRATION and CoAP-CACHING kinds. 516 8.1. CoAP-REGISTRATION Kind 517 Kind IDs 518 The Resource Name for the CoAP-REGISTRATION Kind-ID is the CoAP 519 URI. The data stored is a CoAPRegistration, which contains a set 520 of CoAP URIs. 521 Data Model 522 The data model for the CoAP-REGISTRATION Kind-ID is dictionary. 523 The dictionary key is the Node-ID of the storing RN. This allows 524 each RN to store a single mapping. 525 Access Control 526 URI-NODE-MATCH. The "coap:" prefix needs to be removed from the 527 COAP URI before matching. See Section 9. 529 Data stored under the COAP-REGISTRATION kind is of type 530 CoAPRegistration, defined below. 532 struct { 533 Node-ID Node_ID; 534 uint16 coap_uris_length; 535 opaque coap_uris (0..2^16-1); 536 } CoAPRegistration; 538 8.2. CoAP-CACHING Kind 539 KindIDs 540 The Resource Name for the CoAP-CACHING Kind-ID is the CoAP URI. 541 The data stored is a CoAPCaching, which contains a cached value. 542 Data Model 543 The data model for the CoAP-CACHING Kind-ID is single value. 545 Access Control 546 URI-MATCH. The "coap:" prefix needs to be removed from the COAP 547 URI before matching. See Section 9. 549 Data stored under the CoAP-CACHING kind is of type CoAPCaching, 550 defined in Section 7. 552 9. Access Control Rules 554 As specified in RELOAD base [I-D.ietf-p2psip-base], every kind which 555 is storable in an overlay must be associated with an access control 556 policy. This policy defines whether a request from a given node to 557 operate on a given value should succeed or fail. Usages can define 558 any access control rules they choose, including publicly writable 559 values. 561 CoAP Usage for RELOAD requires an access control policy that allows 562 multiple nodes in the overlay read and write access. This access is 563 for registering and caching information using CoAP URIs as 564 identifiers. Therefore, none of the access control policies 565 specified in RELOAD base are sufficient [I-D.ietf-p2psip-base]. 567 This document defines two access control policies , called URI-MATCH 568 and URI-NODE-MATCH. In URI-MATCH policy, a given value MUST be 569 written and overwritten if and only if the signer's certificate has 570 an associated URI which canonicalized form hashes (using the hash 571 function for the overlay) to the Resource-ID for the resource. 573 In URI-NODE-MATCH policy, a given value MUST be written and 574 overwritten if and only if the signer's certificate has an associated 575 URI which canonicalized form hashes (using the hash function for the 576 overlay) to the Resource-ID for the resource. In addition, the 577 dictionary key MUST be equal to the Node-ID in the certificate and 578 that Node-ID MUST be the one indicated in the SignerIdentity value 579 cert_hash. 581 These Access Control Policies are specified for IANA in Section 582 Section 11.4. 584 10. Security Considerations 586 TBD. 588 11. IANA Considerations 590 11.1. RELOAD Sensor Type Registry 592 IANA SHALL create a "RELOAD sensor type" Registry. Entries in this 593 registry are 16-bit integers denoting method codes as described in 594 Section 7. The initial contents of this registry are: 596 +-----------------+-------+ 597 | Code Name | Value | 598 +-----------------+-------+ 599 | temperature | 0 | 600 | humidity | 1 | 601 | acceleration | 2 | 602 | pressure | 3 | 603 | altitude | 4 | 604 | luminance | 5 | 605 | velocity | 6 | 606 | signal_strength | 7 | 607 | battery | 8 | 608 | heart_rate | 9 | 609 +-----------------+-------+ 611 Figure 3 613 11.2. CoAP-REGISTRATION Kind-ID 615 This document introduces one additional data Kind-ID to the "RELOAD 616 Data Kind-ID" Registry: 618 +-------------------+------------+----------+ 619 | Kind | Kind-ID | RFC | 620 +-------------------+------------+----------+ 621 | CoAP-REGISTRATION | 105 | RFC-AAAA | 622 +-------------------+------------+----------+ 624 This Kind-ID was defined in Section 4. 626 11.3. CoAP-CACHING Kind-ID 628 This document introduces one additional data Kind-ID to the "RELOAD 629 Data Kind-ID" Registry: 631 +--------------+------------+----------+ 632 | Kind | Kind-ID | RFC | 633 +--------------+------------+----------+ 634 | CoAP-CACHING | 106 | RFC-AAAA | 635 +--------------+------------+----------+ 637 This Kind-ID was defined in Section 4. 639 11.4. Access Control Policies 641 IANA SHALL create a "CoAP Usage for RELOAD Access Control Policy" 642 Registry. Entries in this registry are strings denoting access 643 control policies, as described in Section 8.1. New entries in this 644 registry SHALL be registered via RFC 5226 [RFC5226]. Standards 645 Action. The initial contents of this registry are: 647 +-----------------+----------+ 648 | Access Policy | RFC | 649 +-----------------+----------+ 650 | URI-NODE-MATCH | RFC-AAAA | 651 | URI-MATCH | RFC-AAAA | 652 +-----------------+----------+ 654 This access control policy was described in Section 9. 656 12. References 658 12.1. Normative References 660 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 661 Requirement Levels", BCP 14, RFC 2119, March 1997. 663 [I-D.ietf-core-coap] 664 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 665 "Constrained Application Protocol (CoAP)", 666 draft-ietf-core-coap-13 (work in progress), December 2012. 668 [I-D.ietf-p2psip-concepts] 669 Bryan, D., Willis, D., Shim, E., Matthews, P., and S. 670 Dawkins, "Concepts and Terminology for Peer to Peer SIP", 671 draft-ietf-p2psip-concepts-04 (work in progress), 672 October 2011. 674 [I-D.ietf-p2psip-base] 675 Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and 676 H. Schulzrinne, "REsource LOcation And Discovery (RELOAD) 677 Base Protocol", draft-ietf-p2psip-base-24 (work in 678 progress), January 2013. 680 12.2. Informative References 682 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 683 A., Peterson, J., Sparks, R., Handley, M., and E. 684 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 685 June 2002. 687 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 688 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 689 May 2008. 691 Authors' Addresses 693 Jaime Jimenez 694 Ericsson 695 Hirsalantie 11 696 Jorvas 02420 697 Finland 699 Email: jaime.j.jimenez@ericsson.com 701 Jose M. Lopez-Vega 702 University of Granada 703 CITIC-UGR Periodista Rafael Gomez Montero 2 704 Granada 18071 705 Spain 707 Email: jmlvega@ugr.es 709 Jouni Maenpaa 710 Ericsson 711 Hirsalantie 11 712 Jorvas 02420 713 Finland 715 Email: jouni.maenpaa@ericsson.com 716 Gonzalo Camarillo 717 Ericsson 718 Hirsalantie 11 719 Jorvas 02420 720 Finland 722 Email: gonzalo.camarillo@ericsson.com