idnits 2.17.1 draft-amsuess-core-resource-directory-extensions-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 8 instances of too long lines in the document, the longest one being 21 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 126: '... proxy) MUST come up with a "Proxy U...' RFC 2119 keyword, line 130: '... The Proxy URL SHOULD have no path c...' RFC 2119 keyword, line 135: '... The RD MAY mint several alternative...' RFC 2119 keyword, line 152: '...rminates, the RD SHOULD treat the regi...' RFC 2119 keyword, line 153: '...ifetime has not been exceeded) and MAY...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 23, 2019) is 1670 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 658 -- Looks like a reference, but probably isn't: '2' on line 660 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-23 == Outdated reference: A later version (-15) exists of draft-tiloca-core-oscore-discovery-03 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE C. Amsuess 3 Internet-Draft September 23, 2019 4 Intended status: Experimental 5 Expires: March 26, 2020 7 CoRE Resource Directory Extensions 8 draft-amsuess-core-resource-directory-extensions-02 10 Abstract 12 [ See Introduction ] 14 Status of This Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute 21 working documents as Internet-Drafts. The list of current Internet- 22 Drafts is at https://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 This Internet-Draft will expire on March 26, 2020. 31 Copyright Notice 33 Copyright (c) 2019 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (https://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 2. Reverse Proxy requests . . . . . . . . . . . . . . . . . . . 3 50 2.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2.2. Registration . . . . . . . . . . . . . . . . . . . . . . 3 52 2.2.1. Registration updates . . . . . . . . . . . . . . . . 4 53 2.2.2. Proxy behavior . . . . . . . . . . . . . . . . . . . 4 54 2.2.3. On-Demand proxying . . . . . . . . . . . . . . . . . 5 55 2.2.4. Examples . . . . . . . . . . . . . . . . . . . . . . 5 56 2.2.5. Notes on stability and maturity . . . . . . . . . . . 6 57 2.2.6. Security considerations . . . . . . . . . . . . . . . 6 58 3. Infinite lifetime . . . . . . . . . . . . . . . . . . . . . . 7 59 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4. Lookup across link relations . . . . . . . . . . . . . . . . 7 61 4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 5. Lifetime Age . . . . . . . . . . . . . . . . . . . . . . . . 8 63 6. Zone identifier introspection . . . . . . . . . . . . . . . . 8 64 6.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 7. Proxying multicast requests . . . . . . . . . . . . . . . . . 9 66 7.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 10 67 8. Opportunistic RD . . . . . . . . . . . . . . . . . . . . . . 10 68 8.1. Applications . . . . . . . . . . . . . . . . . . . . . . 13 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 71 9.2. Informative References . . . . . . . . . . . . . . . . . 14 72 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 15 74 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 15 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 77 1. Introduction 79 This document pools some extensions to the Resource Directory 80 [I-D.ietf-core-resource-directory] that might be useful but have no 81 place in the original document. 83 They might become individual documents for IETF submission, simple 84 registrations in the RD Parameter Registry at IANA, or grow into a 85 shape where they can be submitted as a collection of tools. 87 At its current state, this draft is a collection of ideas. 89 [ This document is being developed at https://gitlab.com/chrysn/ 90 resource-directory-extensions [1]. ] 92 2. Reverse Proxy requests 94 When a registrant registers at a Resource Directory, it might not 95 have a suitable address it can use as a base address. Typical 96 reasons include being inside a NAT without control over port 97 forwarding, or only being able to open outgoing connections (as 98 program running inside a web browser utilizing CoAP over WebSocket 99 [RFC8323] might be). 101 [I-D.ietf-core-resource-directory] suggests (in the Cellular M2M use 102 case) that proxy access to such endpoints can be provided, it gives 103 no concrete mechanism to do that; this is such a mechanism. 105 This mechanism is intended to be a last-resort option to provide 106 connectivity. Where possible, direct connections are preferred. 107 Before registering for proxying, the registrant should attempt to 108 obtain a publicly available port, for example using PCP ([RFC6887]). 110 The same mechanism can also be employed by clients that want to 111 conceal their network address from its clients. 113 2.1. Discovery 115 An RD that provides proxying functionality advertises it by 116 announcing the additional resource type "TBD1" on its directory 117 resource. 119 2.2. Registration 121 A client passes the "proxy=yes" or "proxy=ondemand" query parameter 122 in addition to (but typically instead of) a "base" query parameter. 124 A server that receives a "proxy=yes" query parameter in a 125 registration (or receives "proxy=ondemand" and decides it needs to 126 proxy) MUST come up with a "Proxy URL" on which it accepts requests, 127 and which it uses as a Registration Base URI for lookups on the 128 present registration. 130 The Proxy URL SHOULD have no path component, as acting as a reverse 131 proxy in such a scenario means that any relative references in all 132 representations that are proxied must be recognized and possibly 133 rewritten. 135 The RD MAY mint several alternative Registration Base URIs using 136 different protocols to make the proxied content available; 137 [I-D.silverajan-core-coap-protocol-negotiation] can be used to 138 advertise them. 140 The registrant is not informed of the chosen public name by the RD. 142 This mechanism is applicable to all transports that can be used to 143 register. If proxying is active, the restrictions on when the base 144 parameter needs to be present ([I-D.ietf-core-resource-directory] 145 Registration template) are relaxed: The base parameter may also be 146 absent if the connection originates from an ephemeral port, as long 147 as the underlying protocol supports role reversal, and link-local 148 IPv6 addresses may be used without any concerns of expressibility. 150 If the client uses the role reversal rule relaxation, it keeps that 151 connection open for as long as it wants to be reachable. When the 152 connection terminates, the RD SHOULD treat the registration as having 153 timed out (even if its lifetime has not been exceeded) and MAY 154 eventually remove the registration. 156 2.2.1. Registration updates 158 The "proxy" query parameter can not be changed or repeated in a 159 registration update; RD servers MUST answer 4.00 Bad Request to any 160 registration update that has a "proxy" query parameter. 162 As always, registration updates can explicitly or implicitly update 163 the Registration Base URI. In proxied registrations, those changes 164 are not propagated to lookup, but do change the forwarding address of 165 the proxy. 167 For example, if a registration is established over TCP, an update can 168 come along in a new TCP connection. Starting then, proxied requests 169 are forwarded along that new connection. 171 Note that transports can not be switched in a registration update, as 172 the protocol is part of the registration resource. 174 2.2.2. Proxy behavior 176 The RD operates as a reverse-proxy as described in [RFC7252] 177 Section 5.7.3 at the announced Proxy URL(s), where it decides based 178 on the requested host and port to which registrant endpoint to 179 forward the request. 181 The address the incoming request are forwarded to is the base address 182 of the registration. If an explicit "base" paremter is given, the RD 183 will forward requests to that location. Otherwise, it forwards to 184 the registration's source address (which is the implied base 185 parameter). 187 2.2.3. On-Demand proxying 189 If an endpoint is deployed in an unknown network, it might not know 190 whether it is behind a NAT that would require it to configure an 191 explicit base address, and ask the RD to assist by proxying if 192 necessary by registering with the "proxy=ondemand" query parameter. 194 A server receiving that SHOULD use a different IP address to try to 195 access the registrant's .well-known/core file using a GET request 196 under the Registration Base URI. If that succeeds, it may assume 197 that no NAT is present, and ignore the proxying request. Otherwise, 198 it configures proxying as if "proxy=yes" were requested. 200 Note that this is only a heuristic [ and not tested in deployments 201 yet ]. 203 2.2.4. Examples 205 2.2.4.1. Registration through a firewall 207 Req from [2001:db8:42::9876]:5683: 208 POST coap://rd.example.net/rd?ep=node9876&proxy=ondemand 209 ;rt="example.x" 211 Req from other-address.rd.example.net: 212 GET coap://[2001:db8:42::9876]/.well-known/core 214 Request blocked by stateful firewall around [2001:db8:42::] 216 RD decides that proxying is necessary 218 Res: 2.04 Created 219 Location: /reg/abcd 221 Later, lookup of that registration might say: 223 Req: GET coap://rd.example.net/lookup/res?rt=example.x 225 Res: 2.05 Content 226 ;rt="example.x 228 A request to that resource will end up at an IP address of the RD, 229 which will forward it using its the IP and port on which the 230 registrant had registered as source port, thus reaching the 231 registrant through the stateful firewall. 233 2.2.4.2. Registration from a browser context 235 Req: POST coaps+ws://rd.example.net/rd?ep=node1234&proxy=yes 236 ;rt="core.s" 238 Res: 2.04 Created 239 Location: /reg/123 241 The gyroscope can now not only be looked up in the RD, but also be 242 reached: 244 Req: GET coap://rd.example.net/lookup/res?rt=core.s 246 Res: 2.05 Content 247 ;rt="core.s" 249 In this example, the RD has chosen to do port-based rather than host- 250 based virtual hosting and announces its literal IP address as that 251 allows clients to not send the lengthy Uri-Host option with all 252 requests. 254 2.2.5. Notes on stability and maturity 256 Using this with UDP can be quite fragile; the author only draws on 257 own experience that this can work across cell-phone NATs and does not 258 claim that this will work over generic firewalls. 260 [ It may make sense to have the example as TCP right away. ] 262 2.2.6. Security considerations 264 An RD MAY impose additional restrictions on which endpoints can 265 register for proxying, and thus respond 4.01 Unauthorized to request 266 that would pass had they not requested proxying. 268 Attackers could do third party registrations with an attacked 269 device's address as base URI, though the RD would probably not 270 amplify any attacks in that case. 272 The RD MUST NOT reveal the address at which it reaches the registrant 273 except for adaequately authenticated and authorized debugging 274 purposes, as that address could reveal sensitive location data the 275 registrant may wish to hide by using a proxy. 277 Usual caveats for proxies apply. 279 3. Infinite lifetime 281 An RD can indicate support for infinite lifetimes by adding the 282 resoruce type "TBD2" to its list of resource types. 284 A registrant that wishes to keep its registration alive indefinitely 285 can set the lifetime value as "lt=inf". 287 Registrations with infinite lifetimes never time out. 289 Infinite lifetimes SHOULD only be used by commissioning tools, or for 290 proxy registrations over stateful connections. 292 3.1. Example 294 Had the example of Section 2.2.4.2 discovered support for infinite 295 lifetimes during lookup like this: 297 Req: GET coaps+ws://rd.example.net/.well-known/coer?rt=core.rd* 299 Res: 2.05 Content 300 ;rt="core.rd TBD1 TBD2";ct=40 302 it could register like that: 304 Req: POST coaps+ws://rd.example.net/rd?ep=node1234&proxy=yes<=inf 305 ;rt="core.s" 307 Res: 2.04 Created 308 Location: /reg/123 310 and never need to update the registration for as long as the 311 websocket connection is open. 313 (When it gets terminated, it could try renewing the registration, but 314 needs to be prepared for the RD to already have removed the original 315 registration.) 317 4. Lookup across link relations 319 Resource lookup occasionally needs execute multiple queries to follow 320 links. 322 An RD server (or any other server that supports [RFC6690] compatible 323 lookup), can announce support for following links in resource lookups 324 by announcing support for the TBD3 interface type on its resource 325 lookup. 327 A client can the query that server to not only provide the matched 328 links, but also links that are reachable over relations given in 329 "follow" query parameters. 331 4.1. Example 333 Assume a node presents the following data in its <.well-known/core> 334 resource (and submitted the same to the RD): 336 ;if="core.s";rt="example.temperature", 337 ;rel="calibration-protocol";anchor="/temp", 338 ;rel="describedby";anchor="/temp", 339 ;if="core.s";rt="example.humidity", 340 ;rel="calibration-protocol";anchor="/hum", 342 A lookup client can, in one query, find the temperature sensor and 343 its relevant metadata: 345 Req: GET /rd-lookup/res?rt=example.temperature&follow=calibration-protocol&follow=describedby 347 ;if="core.s";rt="example.temperature";anchor="coap://node1", 348 ;rel="calibration-protocol";anchor="coap://node1/temp", 349 ;rel="describedby";anchor="coap://node1/temp", 351 [ There is a better example [2] in an earlier stage of 352 [I-D.tiloca-core-oscore-discovery] ] 354 [ Given the likelihood of a CoRAL based successor to [RFC6690], this 355 lookup variant might easily be superseeded by a CoRAL FETCH format. 356 ] 358 5. Lifetime Age 360 This extension is described in [I-D.amsuess-core-rd-replication] 361 Section 5.2. 363 The "provenance" extension in Section 5.1 of the same document should 364 probably be expressed differently to avoid using non-target link 365 attributes. 367 6. Zone identifier introspection 369 The 'split-horizon' mechanism introduced in 370 [I-D.ietf-core-resource-directory] (-19) (that registrations with 371 link-local bases can only be read from the zone they registered on) 372 reduces the usability of the endpoint lookup interface for debugging 373 purposes. 375 To allow an administrator to read out the "show-zone-id" query 376 parameter for endpoint and resource lookup is introduced. 378 A Resource Directory that understands this parameter MUST NOT limit 379 lookup results to registrations from the lookup's zone, and MUST use 380 [RFC6874] zone identifiers to annotate which zone those registrations 381 are valid on. 383 The RD MUST limit such requests to authenticated and authorized 384 debugging requests, as registrants may rely on the RD to keep their 385 presence secret from other links. 387 6.1. Example 389 Req: GET /rd-lookup/ep?show-zone-id&et=printer 391 Res: 2.05 Content 392 ;base="coap://[2001:db8::1]";et=printer;ep="bigprinter", 393 ;base="coap://[fe80::99%wlan0]";et=printer;ep="localprinter-1234", 394 ;base="coap://[fe80::99%eth2]";et=printer;ep="localprinter-5678", 396 7. Proxying multicast requests 398 Multicast requests are hard to forward at a proxy: Even if a media 399 type is used in which multiple responses can be aggregated 400 transparently, the proxy can not reliably know when all responses 401 have come in. [RFC7390] Section 2.9 destribes the difficulties in 402 more detail. 404 A proxy MAY expose an interface compatible with the RD lookup 405 interface, which SHOULD be advertised by a link to it that indicates 406 the resource types core.rd-lookup-res and TBD4. 408 The proxy sends multicast requests to All CoAP Nodes ([RFC7252] 409 Section 12.8) requesting their .well-known/core files either eagerly 410 (ie. in regular intervals independent of queries) or on demand (in 411 which case it SHOULD limit the results by applying [RFC6690] query 412 filtering; if it has received multiple query parameters it should 413 forward the one it deems most likely to limit the results, as .well- 414 known/core only supports a single query parameter). 416 In comparison to classical RD operation, this RD behaves roughly as 417 if it had received a simple registration with a All CoAP Nodes 418 address as the source address, if such behavior were specified. The 419 individual registrations that result from this neither have an 420 explicit registration resource nor an explicit endpoint name; given 421 that the endpoint lookup interface is not present on such proxies, 422 neither can be queried. 424 Clients that would intend to do run a multicast discovery operation 425 behind the proxy can then instead query that resource lookup 426 interface. They SHOULD use observation on lookups, as an on-demand 427 implementation MAY return the first result before others have 428 arrived, or MAY even return an empty link set immediately. 430 7.1. Example 432 Req: GET coap+ws://gateway.example.com/.well-known/core?rt=TBD4 434 Res: 2.05 Content 435 ;rt="core.rd-lookup-res TBD4";ct=40 437 Req: GET coap+ws://gateway.example.com/discover?rt=core.s 438 Observe: 0 440 Res: 2.05 Content 441 Observe: 0 442 Content-Format: 40 443 (empty payload) 445 At the same time, the proxy sends out multicast requests on its 446 interfaces: 448 Req: GET coap://ff05::fd/.well-known/core?rt=core.s 450 Res (from [2001:db8::1]:5683): 2.05 Content 451 ;ct="0 112";rt="core.s" 453 Res (from [2001:db8::2]:5683): 2.05 Content 454 ;ct="0 112";rt="core.s" 456 upon receipt of which it sends out a notification to the websocket 457 client: 459 Res: 2.05 Content 460 Observe: 1 461 Content-Format: 40 462 ;ct="0 112";rt="core.s";anchor="coap://[2001:db8::1]", 463 ;ct="0 112";rt="core.s";anchro="coap://[2001:db8::2]" 465 8. Opportunistic RD 467 An application that wants to advertise its resources in Resource 468 Directory can find itself in a network that has no RD deployed. It 469 may be able to start an RD on its own to fill in that gap until an 470 explicitly configured one gets installed. 472 This bears the risk of having competing RDs on the same network, 473 where resources registered at one can not be discovered on the other. 474 To mitigate that, such Opportunistic Resource Directories should 475 follow those steps: 477 o The RD chooses its own Opportunistic Capability value. That 478 integer number is an estimate of number of target attributes it 479 expects to be able to store, where in absence of better estimates 480 one would assume that a registration contains 16 links, and each 481 links contains three target attributes each with an eight byte key 482 and a 16 byte value. 484 The Opportunistic Capability value is advertised as a TBD5-cap= 485 target attribute on the registration resource. 487 o The RD chooses its own Opportunistic Tie-Break value. That 488 integer number needs no other properties than being likely to be 489 different even for two instances of the same device being started; 490 numeric forms of MAC addresses or random numbers make good 491 candidates. 493 The Opportunistic Capability value is advertised as a TBD5-tie= 494 target attribute on the registration resource. 496 o The Opportunistic RD, before advertising its resources, performs 497 RD discovery itself, using at least all the discovery paths it may 498 become discoverable on itself. 500 o If the Opportunistic RD finds no other RD, or if the RD it finds 501 is less capable than itself, it can start advertising itself as a 502 Resource Directory. 504 An RD is called more capable than another if its TBD5-cap value is 505 greater than the other's, or if its TBD5-tie value is greater than 506 the other's if the former results in a tie. Absent or unparsable 507 attributes are considered greater than any present attribute. 509 In case an RD observes a tie even after evaluating the tie 510 breaker, it may change its Opportunistic Tie-Break value if that 511 was picked randomly, or reevaluate its life choices if it uses its 512 own MAC address. 514 o A running Opportunistic RD needs to perform discovery for other 515 RDs repeatedly. If it discovers a more capable RD, it stops 516 advertising its own resources. It should continue to serve lookup 517 requests, but refuse any new registration or registration updates 518 (which will trigger the registrant endpoints to look for a new 519 RD). 521 An inactive Opportunistic RD will be notified of the highter 522 capability RD's shutdown by the expiry of whatever it may be 523 started to advertise that was now advertised there; see below for 524 possible improvements. 526 o An RD that discovers an Opportunistic RD of lower capability may 527 speed up the transition process by (not mutually exclusive) two 528 ways 530 * It can register its own (registration) resource(s) into the 531 lower capability directory. That RD can take that as having 532 discovered a higher capability RD and stop advertising. 534 * It can expose resources and registrations of the lower 535 capability directory using the methods described in 536 [I-D.amsuess-core-rd-replication]. 538 o An Opportunistic RD that yields to a more capable RD may ease the 539 transition by attempting to register its active registrations at 540 the more capable RD, taking the role of a CT. The lifetimes 541 picked for those must not exceed the remaining lifetime of its 542 registrations, and it must not renew those registrations. 544 Future iterations of this document may want to cut down on the 545 possibilities listed above. 547 Some ideas are around for making the shutdown of a commissioned or 548 otherwise high-capability RD more graceful, but they still have some 549 problems 551 o Setting a commissioned or high-capability RD's Capability to zero 552 in preparation of the shutdown may create loops in any distributed 553 lookups. 555 o Asking the lower capability RD to register its registration 556 resource (even though not otherwise advertised) at the higher 557 capability RD still creates a situation where clients may find two 558 RDs running simultaneously, and we can't expect clients to make 559 any decisions based on TBD5 values. 561 o Asking the higher capability RD to register its registration 562 resource with the lower capability RD contradicts the current 563 recommendation for the passive Opportunistic RD to not accept 564 registrations / renewals. Also, the deployed RD may not know that 565 Opportunistic RDs are a thing. 567 o Advertising an almost-but-not-quite rt= value on passive 568 registration resources may be an option, but needs to be thought 569 through thoroughly. 571 Installations of Opportunistic RDs are at special risk of resource 572 exhaustion because they are not sized with their actual deployment in 573 mind, but rely on defaults set by the application that starts the RD. 574 Opportunistic RDs should only be started if the application's 575 administrator can be informed in a timely fashion when the RD's 576 resources are nearing exhaustion; guidance towards installing a more 577 capable RD on the network should be provided in that case. 579 8.1. Applications 581 o Group managers using [I-D.tiloca-core-oscore-discovery] can ship 582 its own low-priority Opportunistic RD to announce its join 583 resources. This provides benefits over announcing them on 584 multicast discovery if the network can efficiently route requests 585 to the All CoAP Resource Directories multicast address (so group 586 members get a response back from an early focused request to all 587 RDs rather than falling back to multicasting All CoAP Nodes for 588 "?rt=osc.j&..."), or if discovery of the group's multicast address 589 is used. 591 o Administrative tools that try to provide a broad overview of a 592 network's CoAP devices could offer to open an Opportunistic RD if 593 they find no active RD on the network (but should ask the user in 594 interactive scenarios). 596 That allows them to see devices that newly join the network 597 quickly (by observing their own or the found RD), rather than 598 relying periodic multicasts. 600 9. References 602 9.1. Normative References 604 [I-D.amsuess-core-rd-replication] 605 Amsuess, C., "Resource Directory Replication", draft- 606 amsuess-core-rd-replication-02 (work in progress), March 607 2019. 609 [I-D.ietf-core-resource-directory] 610 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 611 Amsuess, "CoRE Resource Directory", draft-ietf-core- 612 resource-directory-23 (work in progress), July 2019. 614 [RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing 615 IPv6 Zone Identifiers in Address Literals and Uniform 616 Resource Identifiers", RFC 6874, DOI 10.17487/RFC6874, 617 February 2013, . 619 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 620 Application Protocol (CoAP)", RFC 7252, 621 DOI 10.17487/RFC7252, June 2014, 622 . 624 9.2. Informative References 626 [I-D.silverajan-core-coap-protocol-negotiation] 627 Silverajan, B. and M. Ocak, "CoAP Protocol Negotiation", 628 draft-silverajan-core-coap-protocol-negotiation-09 (work 629 in progress), July 2018. 631 [I-D.tiloca-core-oscore-discovery] 632 Tiloca, M., Amsuess, C., and P. Stok, "Discovery of OSCORE 633 Groups with the CoRE Resource Directory", draft-tiloca- 634 core-oscore-discovery-03 (work in progress), July 2019. 636 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 637 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 638 . 640 [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and 641 P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, 642 DOI 10.17487/RFC6887, April 2013, 643 . 645 [RFC7390] Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for 646 the Constrained Application Protocol (CoAP)", RFC 7390, 647 DOI 10.17487/RFC7390, October 2014, 648 . 650 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 651 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 652 Application Protocol) over TCP, TLS, and WebSockets", 653 RFC 8323, DOI 10.17487/RFC8323, February 2018, 654 . 656 9.3. URIs 658 [1] https://gitlab.com/chrysn/resource-directory-extensions 660 [2] https://github.com/ace-wg/ace-oauth/ 661 issues/120#issuecomment-407997786 663 Appendix A. Change log 665 Since -01: 667 o Added section on Opportunistic RDs 669 Since -00: 671 o Add multicast proxy usage pattern 673 o ondemand proxying: Probing queries must be sent from a different 674 address 676 o proxying: Point to RFC7252 to describe how the actual proxying 677 happens 679 o proxying: Describe this as a last-resort options and suggest 680 attempting PCP first 682 Appendix B. Acknowledgements 684 [ Reviews from: Jaime Jimenez ] 686 Author's Address 688 Christian Amsuess 689 Hollandstr. 12/4 690 1020 691 Austria 693 Phone: +43-664-9790639 694 Email: christian@amsuess.com