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