idnits 2.17.1 draft-silverajan-core-coap-protocol-negotiation-07.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 7 instances of too long lines in the document, the longest one being 12 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 (October 30, 2017) is 2363 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 608, but no explicit reference was found in the text == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-11 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group B. Silverajan 3 Internet-Draft TUT 4 Intended status: Informational M. Ocak 5 Expires: May 3, 2018 Ericsson 6 October 30, 2017 8 CoAP Protocol Negotiation 9 draft-silverajan-core-coap-protocol-negotiation-07 11 Abstract 13 CoAP has been standardised as an application-level REST-based 14 protocol. When multiple transport protocols exist for exchanging 15 CoAP resource representations, this document introduces a way forward 16 for CoAP endpoints as well as intermediaries to agree upon alternate 17 transport and protocol configurations as well as URIs for CoAP 18 messaging. Several mechanisms are proposed: Extending the CoRE 19 Resource Directory with new parameter types, introducing a new CoAP 20 Option with which clients can interact directly with servers without 21 needing the Resource Directory, and finally a new CoRE Link Attribute 22 allowing exposing alternate locations on a per-resource basis. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 3, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Overcoming Middlebox Issues . . . . . . . . . . . . . . . 4 61 2.2. Better resource caching and serving in proxies . . . . . 5 62 3. Node Types based on Transport Availability . . . . . . . . . 6 63 4. New Resource Directory Parameters . . . . . . . . . . . . . . 7 64 4.1. The 'at' RD parameter . . . . . . . . . . . . . . . . . . 7 65 4.2. The 'tt' RD parameter . . . . . . . . . . . . . . . . . . 9 66 5. CoAP Alternative-Transport Option . . . . . . . . . . . . . . 9 67 6. The 'ol' CoRE Link Attribute . . . . . . . . . . . . . . . . 13 68 6.1. Using /.well-known/core . . . . . . . . . . . . . . . . . 13 69 6.2. Using CoRE Resource Directory . . . . . . . . . . . . . . 14 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 75 10.2. Informative References . . . . . . . . . . . . . . . . . 15 76 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 15 77 A.1. From -06 to -07 . . . . . . . . . . . . . . . . . . . . . 15 78 A.2. From -05 to -06 . . . . . . . . . . . . . . . . . . . . . 16 79 A.3. From -04 to -05 . . . . . . . . . . . . . . . . . . . . . 16 80 A.4. From -03 to -04 . . . . . . . . . . . . . . . . . . . . . 16 81 A.5. From -02 to -03 . . . . . . . . . . . . . . . . . . . . . 16 82 A.6. From -01 to -02 . . . . . . . . . . . . . . . . . . . . . 16 83 A.7. From -00 to -01 . . . . . . . . . . . . . . . . . . . . . 16 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 86 1. Introduction 88 The Constrained Application Protocol (CoAP) [RFC7252] allows clients, 89 origin servers and proxies, to exchange and manipulate resource 90 representations using REST-based methods over UDP or DTLS. CoAP 91 messaging is however being extended to use other alternative 92 underlying transports. These include reliable transports such as 93 TCP, WebSockets and TLS. In addition, the use of SMS as a CoAP 94 transport remains a possibility for simple communication in cellular 95 networks. 97 When CoAP-based endpoints and proxies possess the ability to perform 98 CoAP messaging over multiple transports, significant benefits can be 99 obtained if communicating client endpoints can discover that multiple 100 transport bindings may exist on an origin server over which CoAP 101 resources can be retrieved. This allows a client to understand and 102 possibly substitute a different transport protocol configuration for 103 the same CoAP resources on the origin server, based on the 104 preferences of the communicating peers. Inevitably, if two CoAP 105 endpoints reside in distinctly separate networks with orthogonal 106 transports, a CoAP proxy node is needed between the two networks so 107 that CoAP Requests and Responses can be exchanged properly. 109 A URI in CoAP, however, serves two purposes simultaneously. It 110 firstly functions as a locator, by specifying the network location of 111 the endpoint hosting the resource, and the underlying transport used 112 by CoAP for accessing the resource representation. It secondly 113 identifies the name of the specific resource found at that endpoint 114 together with its namespace, or resource path. A single CoAP URI 115 cannot be used to express the identity of the resource independently 116 of alternate underlying transports or protocol configuration. 117 Multiple URIs can result for a single CoAP resource representations 118 if: 120 o the authority components of the URI differ, owing to the same 121 physical host exposing several network endpoints. For example, 122 "coap://example.org/sensors/temperature" and 123 "coap://example.net/sensors/temperature" 125 o the scheme components of the URI differ, owing to the origin 126 server exposing several underlying transport alternatives. For 127 example, "coap://example.org/sensors/temperature" and 128 "coap+tcp://example.org/sensors/temperature" 130 o the path components of the URI differ, should an origin server 131 also allow alternative transport endpoint such as the WebSocket 132 protocol, to be expressed using the path. For example, 133 "coap://example.org/sensors/temperature" and 134 "coap+ws://example.org/ws-endpoint/sensors/temperature" 136 Without a priori knowledge, clients would be unable to ascertain if 137 two or more URIs provided by an origin server are associated to the 138 same representation or not. Consequently, a communication mechanism 139 needs to be conceived to allow an origin server to properly capture 140 the relationship between these alternate representations or locations 141 and then subsequently supply this information to clients. This also 142 goes some way in limiting URI aliasing [WWWArchv1]. 144 In order to support CoAP clients, proxies and servers wishing to use 145 CoAP over multiple transports, this draft proposes the following: 147 o An ability for servers to register supported CoAP transports to a 148 CoRE Resource Directory [I-D.ietf-core-resource-directory] with 149 optional registration lifetime values 151 o A means for CoAP clients to interact with a CoRE resource 152 directory interface for requesting and discovering alternative 153 transports and locations of CoAP resources 155 o New Resource Directory parameter types enabling the above- 156 mentioned features. 158 o A new CoAP Option called Alternative-Transport that can be used by 159 CoAP clients to discover and retrieve the types of alternative 160 transports available at the origin server, as well as the links 161 describing the transport-specific endpoint address at which CoAP 162 resources are exposed from. 164 o A new CoRE Link attribute for exposing transports and endpoint 165 locations on an origin server on a per-resource basis. 167 2. Aim 169 The following simple scenarios aim to better portray how CoAP 170 protocol negotiation benefits communicating nodes 172 2.1. Overcoming Middlebox Issues 174 Discovering which transports are available is important for a client 175 to determine the optimal alternative to perform CoAP messaging 176 according to its needs, particularly when separated from a CoAP 177 server via a NAT. It is well-known that some firewalls as well as 178 many NATs, particularly home gateways, hinder the proper operation of 179 UDP traffic. NAT bindings for UDP-based traffic do not have as long 180 timeouts as TCP-based traffic. 182 +-----------+ 183 | Resource | 184 +--4-->| Directory | 185 | +-----------+ 186 +---+ | ^ 187 +----4--->| |<---+ +---1----+ 188 +-------------+--V--+ | | +-V-----------------+ 189 | | |--2-->| |--2-->| | | 190 | | UDP | | N | | UDP | | 191 | | |<--3--| |<--3--| | | 192 | CoAP Client +-----+ | A | +-----+ CoAP Server | 193 | | |--5-->| |--5-->| | | 194 | | TCP | | T | | TCP | | 195 | | |<--6--| |<--6--| | | 196 +-------------+-----+ +---+ +-----+-------------+ 198 Figure 1: CoAP Client initially accesses CoAP Server over UDP and 199 then switching to TCP 201 Figure 1 depicts such a scenario. Step 1 depicts the CoAP Server 202 registering its transports to a Resource Directory. A CoAP client 203 uses UDP initially for accessing a CoAP Server in Step 2 and receives 204 a response in Step 3. Subsequently a CoAP client, residing behind a 205 NAT, performs a lookup on the Resource Directory in Step 4 to 206 discover alternative transports offered by the server. Steps 5 and 6 207 illustrate the client then deciding to use TCP for CoAP messaging 208 instead of UDP to set up an Observe relationship for a resource at 209 the CoAP Server, in order to avoid incoming packets containing 210 resource updates being discarded by the NAT. 212 2.2. Better resource caching and serving in proxies 214 Figure 2 outlines a more complex example of intermediate nodes such 215 as CoAP-based proxies to intelligently cache and respond to CoAP or 216 HTTP clients with the same resource representation requested over 217 alternative transports or server endpoints. As with the earlier 218 example, the CoAP Server registers its transports to a Resource 219 Directory (This is assumed to be performed beforehand and not 220 depicted in the figure, for brevity) 222 In this example, a CoAP over WebSockets client successfully obtains a 223 response from a CoAP forward proxy to retrieve a resource 224 representation from an origin server using UDP, by supplying the CoAP 225 server's endpoint address and resource in a Proxy-URI option. Arrow 226 1 represents a GET request to "coap+ws://proxy.example.com" which 227 subsequently retrieves the resource from the CoAP server using the 228 URI "coap://example.org/sensors/temperature", shown as arrow 2. 230 +---------+ 231 | CoAP+WS | +--------+-------+---+ +-----+---------+ 232 | Client |<-1->| Web | | |<-2->| | | 233 +---------+ | Socket | CoAP | U | | UDP | CoAP | 234 +---------+ +--------+ Proxy | D | +-----+ Server | 235 | HTTP |<-3->| HTTP | | P | | TCP | | 236 | Client |<-4->| | | | | | | 237 +---------+ +--------+-------+---+ +-----+---------+ 239 Figure 2: Proxying and returning a resource's alternate cached 240 representations to multiple clients 242 Subsequently, assume an HTTP client requests the same resource, but 243 instead specifies a CoAP over TCP alternative URI instead. Arrow 3 244 represents this event, where the HTTP client performs a GET request 245 to "http://proxy.example.com/coap+tcp://example.org/sensors/ 246 temperature". When the proxy receives the request, instead of 247 immediately retrieving the temperature resource again over TCP, it 248 first verifies either from the Resource Directory or directly from 249 the server, whether the cached resource retrieved over UDP is a valid 250 equivalent representation of the resource requested by the HTTP 251 client over TCP. Upon confirmation, the proxy is able to supply the 252 same cached representation to the HTTP client as well (arrow 4). 254 3. Node Types based on Transport Availability 256 In [RFC7228], Tables 1, 3 and 4 introduced classification schemes for 257 devices, in terms of their resource constraints, energy limitations 258 and communication power. For this document, in addition to these 259 capabilities, it seems useful to also identify devices based on their 260 transport capabilities. 262 +-------+----------------------------+ 263 | Name | Transport Availability | 264 +-------+----------------------------+ 265 | T0 | Single transport | 266 | | | 267 | T1 | Multiple transports, with | 268 | | one or more active at any | 269 | | point in time | 270 | | | 271 | T2 | Multiple active and | 272 | | persistent transports | 273 | | at all times | 274 +-------+----------------------------+ 276 Table 1: Classes of Available Transports 278 Type T0 nodes possess the capability of exactly 1 type of transport 279 channel for CoAP, at all times. These include both active and sleepy 280 nodes, which may choose to perform duty cycling for power saving. 282 Type T1 nodes possess multiple different transports, and can retrieve 283 or expose CoAP resources over any or all of these transports. 284 However, not all transports are constantly active and certain 285 transport channels and interfaces could be kept in a mostly-off state 286 for energy-efficiency, such as when using CoAP over SMS. 288 Type T2 nodes possess more than 1 transport, and multiple transports 289 are simultaneously active at all times in a persistent manner. CoAP 290 proxy nodes which allow CoAP endpoints from disparate transports to 291 communicate with each other, are a good example of this. 293 4. New Resource Directory Parameters 295 In order to allow resource interactions between clients and servers 296 with multiple locations or transports, the registration, update and 297 lookup interfaces of the CoRE Resource Directory need to be extended. 298 In this section two new RD parameters, "at" and "tt" are introduced. 299 Both are optional CoAP features. If supported, they occur at the 300 granularity level of an origin server, ie. they cannot be applied 301 selectively on some resources only. When absent, it is assumed that 302 the server does not support multiple transports or locations. 304 4.1. The 'at' RD parameter 306 A CoAP server wishing to advertise its resources over multiple 307 transports does so by using a new "at" parameter to register a list 308 of CoAP alternative transport URIs during registration with a 309 Resource Directory. Such a URI would contain the schemes, addresses 310 as well as any ports or paths at which the server is available. 312 +-----------+-------+---------------+-------------------------------+ 313 | Name | Query | Validity | Description | 314 +-----------+-------+---------------+-------------------------------+ 315 | CoAP | at | URI | Comma separated list of URIs | 316 | Transport | | | (scheme, address, port, and | 317 | URI List | | | path) available at the server | 318 +-----------+-------+---------------+-------------------------------+ 320 Table 2: The "at" RD parameter 322 The "at" parameter extends the Resource Directory's Registration and 323 Update interfaces. 325 The following example shows a type T1 endpoint registering its 326 resources and advertising its ability to use TCP as an alternative 327 transport: 329 Req: POST coap:/rd.example.com/rd 330 ?ep=node1&at=coap+tcp://server.example.com,coap+ws://server.example.com:5683/ws/ 331 Content-Format: 40 332 Payload: 333 ;ct=41;rt="temperature-f";if="sensor", 334 ;ct=41;rt="door";if="sensor" 336 Res: 2.01 Created 337 Location: /rd/4521 339 The next example shows the same endpoint updating its registration 340 with a new lifetime and the availability of a single alternative 341 transport for CoAP (in this case WebSockets): 343 Req: POST /rd/4521?lt=600&at=coap+ws://server.example.com:5683/ws/ 344 Content-Format: 40 345 Payload: 346 ;ct=41;rt="temperature-f";if="sensor", 347 ;ct=41;rt="door";if="sensor" 349 Res: 2.04 Changed 351 4.2. The 'tt' RD parameter 353 A CoAP client wishing to perform a look-up on the Resource Directory 354 for CoAP servers supporting multiple transports does so by using a 355 new "tt" parameter to query for CoAP alternative transport URIs. 357 +-----------+-------+---------------+-------------------------------+ 358 | Name | Query | Validity | Description | 359 +-----------+-------+---------------+-------------------------------+ 360 | CoAP | tt | | Transport type | 361 | Transport | | | requested by | 362 | Type | | | the client | 363 +-----------+-------+---------------+-------------------------------+ 365 Table 3: The "tt" RD parameter 367 The "tt" parameter extends the Resource Directory's rd-lookup 368 interface. 370 The following example shows a client performing a lookup for 371 endpoints supporting TCP: 373 Req: GET /rd-lookup/ep?tt=tcp 375 Res: 2.05 Content 376 ;ep="node5", 377 ;ep="node7" 379 The next example shows a client performing a lookup for all 380 transports supported by a specific endpoint: 382 Req: GET /rd-lookup/ep?ep=node5&tt=* 384 Res: 2.05 Content 385 ;ep="node5", 386 ;ep="node5" 388 5. CoAP Alternative-Transport Option 390 The CoAP Alternative-Transport Option can be used by CoAP clients and 391 CoAP servers in both Request and Response messages in constrained 392 environments where a CoRE Resource Directory is not present. 394 Figure 3 depicts the properties of the Alternative-Transport Option. 396 +-----+---+---+---+---+------------------------+--------+--------+----------+ 397 | No. | C | U | N | R | Name | Format | Length | Default | 398 +-----+---+---+---+---+------------------------+--------+--------+----------+ 399 | 66 | | x | - | x | Alternative-Transport | string | 0-1034 | (none) | 400 +-----+---+---+---+---+------------------------+--------+--------+----------+ 402 C=Critical, U=Unsafe, N=No-Cache-Key, R=Repeatable 404 Figure 3: The Alternative-Transport Option 406 When included in a Request message, this option is used by the client 407 in 2 possible ways. In the first case, a CoAP client can include the 408 Option with Length 0 to retrieve all alternative transports from a 409 CoAP server. In response to the client, the server includes base URI 410 for each transport in its own Option. In the second case, a CoAP 411 client can include the Option with a specific value in a CoAP 412 Request, and the CoAP server returns the base URI(s) for the 413 specified transport. If the specified transport by a CoAP client 414 returns multiple results on a CoAP server, the server returns all 415 base URIs of the transport in the response, each base URI in its own 416 Option. 418 A CoAP client can also use this Option to retrieve several transports 419 at once by including multiple Options in the request to a CoAP 420 server. If any of the specified transports is supported by the 421 server, the server returns all base URIs in its own option. There 422 can be more than 1 result for any of the transports so that each 423 transport base URI is still included in the response in its own 424 option. 426 Figure 4 describes a simple interaction between a client and a 427 server, in which the client uses an Alternative-Transports Option 428 with a null value to discover and retrieve all the available 429 transports from the server, as part of a GET operation to retrieve a 430 resource representation. The server responds with a CoAP Response 431 message which contains the resource representation as a payload. In 432 addition, the server also supplies multiple Alternative-Transport 433 Options in the message, with each Option containing the base URI for 434 an available transport. In this case the base URIs returned for TCP- 435 based and WebSocket transports indicate their availability over a 436 non-standard port. 438 Client Server 439 + | 440 | GET /temperature | 441 | Token: 0x64 | 442 | Alternative-Transport: (null) | 443 +-------------------------------------->| 444 | | 445 | 2.05 Content | 446 | Token: 0x64 | 447 | Payload: 21.0 Cel | 448 | Alternative-Transport: | 449 | coap+tcp://example.org:5555/ | 450 | Alternative-Transport: | 451 | coaps+tcp://example.org:6666/ | 452 | Alternative-Transport: | 453 | coap+sms://0015105550101/ | 454 | Alternative-Transport: | 455 | coap+ws://example.org:8080/ | 456 | | 457 |<--------------------------------------+ 458 | | 460 Figure 4: Requesting all available alternative transports on the 461 server, and their locations 463 Alternatively, a client can also request for the availability of a 464 specific transport on the server, as shown in Figure 5. Here, the 465 CoAP Request contains an Alternative-Transport Option with the value 466 set to request the Base URIs for TCP-based endpoints. 468 Client Server 469 + | 470 | GET /temperature | 471 | Token: 0x64 | 472 | Alternative-Transport: tcp | 473 +-------------------------------------->| 474 | | 475 | 2.05 Content | 476 | Token: 0x64 | 477 | Payload: 21.0 Cel | 478 | Alternative-Transport: | 479 | coap+tcp://example.org:5555/ | 480 | Alternative-Transport: | 481 | coaps+tcp://example.org:6666/ | 482 | | 483 |<--------------------------------------+ 484 | | 486 Figure 5: Requesting TCP-based alternative transports on the server, 487 and their locations 489 A client may also request a subset of available transports on the 490 server, by providing multiple Options, each having a single transport 491 identifier. The server likewise responds to the client request by 492 supplying the requested transport information. This is shown in 493 Figure 6. 495 Client Server 496 + | 497 | GET /temperature | 498 | Token: 0x64 | 499 | Alternative-Transport: ws | 500 | Alternative-Transport: sms | 501 +-------------------------------------->| 502 | | 503 | 2.05 Content | 504 | Token: 0x64 | 505 | Payload: 21.0 Cel | 506 | Alternative-Transport: | 507 | coap+sms://0015105550101/ | 508 | Alternative-Transport: | 509 | coap+ws://example.org:8080/ | 510 | | 511 |<--------------------------------------+ 512 | | 514 Figure 6: Requesting WebSocket- and SMS-based alternative transports 515 on the server, and their locations 517 6. The 'ol' CoRE Link Attribute 519 In the majority of cases, it is expected that an origin server would 520 expose all its resources uniformly on its available transports or 521 endpoint addresses. Exceptions can exist however, where alternate 522 locations are made available on a per-resource basis. For such 523 cases, a new 'ol' ("other locations") attribute is provided. This 524 attribute is a string used to provide a list of base URIs from which 525 a specific resource can be reached. Allowing per-resource endpoint 526 or transport availabilty enables specific functions such as firmware 527 updates or hardware-specific operations. It also facilities mapping 528 to and from OCF-based resource-specific endpoint descriptions. 530 6.1. Using /.well-known/core 532 REQ: GET /.well-known/core 534 RES: 2.05 Content 535 ;ct=41;rt="temperature-f";if="sensor", 536 ;ct=41;rt="door";if="sensor", 537 ;if="sensor"; ol="http://[FDFD::123]:61616, 538 coap://server2.example.com" 540 6.2. Using CoRE Resource Directory 542 Req: POST coap:/rd.example.com/rd 543 ?ep=node1&at=coap+tcp://server.example.com,coap+ws://server.example.com:5683/ws/ 544 Content-Format: 40 545 Payload: 546 ;ct=41;rt="temperature-f";if="sensor", 547 ;ct=41;rt="door";if="sensor", 548 ;if="sensor"; ol="http://[FDFD::123]:61616, 549 coap://server2.example.com" 551 Res: 2.01 Created 552 Location: /rd/4521 554 7. IANA Considerations 556 This document requests the registration of new RD parameter types 557 "at" and "tt". 559 The following entry needs to be added to the CoAP Option Numbers 560 Registry: 562 +--------+------------------------+------------------+ 563 | Number | Name | Reference | 564 +--------+------------------------+------------------+ 565 | 66 | Alternative-Transports | (this document) | 566 +--------+------------------------+------------------+ 568 8. Security Considerations 570 When multiple transports, locations and representations are used, 571 some obvious risks are present both at the origin server as well as 572 by requesting clients. 574 When a client is presented with alternate URIs for retrieving 575 resources, it presents an opportunity for attackers to mount a series 576 of attacks, either by hijacking communication and masquerading as an 577 alternate location or by using a man-in-the-middle attack on TLS- 578 based communication to a server and redirecting traffic to an 579 alternate location. A malicious or compromised server could also be 580 used for reflective denial-of-service attacks on innocent third 581 parties. Moreover, clients may obtain web links to alternate URIs 582 containing weaker security properties than the existing session. 584 9. Acknowledgements 586 Thanks to Klaus Hartke for comments and reviewing this draft, and 587 Teemu Savolainen for initial discussions about protocol negotations 588 and lifetime values. Zach Shelby provided significant suggestions on 589 how the Resource Directory can be employed and extended in place of 590 link attributes and relation types. 592 10. References 594 10.1. Normative References 596 [I-D.ietf-core-resource-directory] 597 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 598 Amsuess, "CoRE Resource Directory", draft-ietf-core- 599 resource-directory-11 (work in progress), July 2017. 601 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 602 Application Protocol (CoAP)", RFC 7252, 603 DOI 10.17487/RFC7252, June 2014, 604 . 606 10.2. Informative References 608 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 609 Requirement Levels", BCP 14, RFC 2119, 610 DOI 10.17487/RFC2119, March 1997, 611 . 613 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 614 Constrained-Node Networks", RFC 7228, 615 DOI 10.17487/RFC7228, May 2014, 616 . 618 [WWWArchv1] 619 http://www.w3.org/TR/webarch/#uri-aliases, "Architecture 620 of the World Wide Web, Volume One", December 2004. 622 Appendix A. Change Log 624 A.1. From -06 to -07 626 Added support for 'ol' Link attribute 628 A.2. From -05 to -06 630 Added support for CoAP Alternative-Transports Option 632 A.3. From -04 to -05 634 Freshness update 636 A.4. From -03 to -04 638 Removed previously introduced link attribute and relation types 640 Initial foray with Resource Directory support 642 A.5. From -02 to -03 644 Added new author 646 Rewrite of "Introduction" section 648 Added new Aims Section 650 Added new Section on Node Types 652 Introduced "al" Active Lifetime link attribute 654 Added new Section on Observing transports and resources 656 Security and IANA considerations sections populated 658 A.6. From -01 to -02 660 Freshness update. 662 A.7. From -00 to -01 664 Reworked "Introduction" section, added "Rationale", and "Goals" 665 sections. 667 Authors' Addresses 669 Bilhanan Silverajan 670 Tampere University of Technology 671 Korkeakoulunkatu 10 672 FI-33720 Tampere 673 Finland 675 Email: bilhanan.silverajan@tut.fi 676 Mert Ocak 677 Ericsson 678 Hirsalantie 11 679 02420 Jorvas 680 Finland 682 Email: mert.ocak@ericsson.com