<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version  -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc subcompact="no"?>
<?rfc iprnotified="no"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-amsuess-core-resource-directory-extensions-05" category="exp" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRefs="true" sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.47.0 -->
  <front>
    <title>CoRE Resource Directory Extensions</title>
    <seriesInfo name="Internet-Draft" value="draft-amsuess-core-resource-directory-extensions-05"/>
    <author initials="C." surname="Amsüss" fullname="Christian Amsüss">
      <organization/>
      <address>
        <postal>
          <street>Hollandstr. 12/4</street>
          <code>1020</code>
          <country>Austria</country>
        </postal>
        <phone>+43-664-9790639</phone>
        <email>christian@amsuess.com</email>
      </address>
    </author>
    <date year="2021" month="February" day="22"/>
    <area>Internet</area>
    <workgroup>CoRE</workgroup>
    <keyword>CoRE, Web Linking, Resource Discovery, Resource Directory, Proxy</keyword>
    <abstract>
      <t>A collection of extensions to the Resource Directory <xref target="I-D.ietf-core-resource-directory" format="default"/>
that can stand on their own, and have no clear future in specification yet.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>This document pools some extensions to the Resource Directory
<xref target="I-D.ietf-core-resource-directory" format="default"/> that might be useful but have no place in
the original document.</t>
      <t>They might become individual documents for IETF submission, simple
registrations in the RD Parameter Registry at IANA, or grow into a shape where
they can be submitted as a collection of tools.</t>
      <t>At its current state, this draft is a collection of ideas.</t>
      <t>[
This document is being developed at <eref target="https://gitlab.com/chrysn/resource-directory-extensions">https://gitlab.com/chrysn/resource-directory-extensions</eref>.
]</t>
    </section>
    <section anchor="reverse-proxy-requests" numbered="true" toc="default">
      <name>Reverse Proxy requests</name>
      <t>When a registrant registers at a Resource Directory, it might not have a
suitable address it can use as a base address.
Typical reasons include being inside a NAT without control over port forwarding,
or only being able to open outgoing connections
(as program running inside a web browser utilizing CoAP over WebSocket <xref target="RFC8323" format="default"/> might be).</t>
      <t><xref target="I-D.ietf-core-resource-directory" format="default"/> suggests (in the Cellular M2M use case) that proxy access to such endpoints can be provided,
it gives no concrete mechanism to do that; this is such a mechanism.</t>
      <t>This mechanism is intended to be a last-resort option to provide connectivity.
Where possible, direct connections are preferred.
Before registering for proxying,
the registrant should attempt to obtain a publicly available port,
for example using PCP (<xref target="RFC6887" format="default"/>).</t>
      <t>The same mechanism can also be employed by clients that want to conceal their network address from its clients.</t>
      <t>A deployed application where this is implicitly done is LwM2M [citation missing].
Notable differences are that the protocol used between the client and the proxying RD is not CoAP but application specific,
and that the RD (depending on some configuration) eagerly populates its proxy caches
by sending requests and starting observations at registration time.</t>
      <section anchor="discovery" numbered="true" toc="default">
        <name>Discovery</name>
        <t>An RD that provides proxying functionality advertises it by announcing the additional resource type "TBD1" on its directory resource.</t>
      </section>
      <section anchor="registration" numbered="true" toc="default">
        <name>Registration</name>
        <t>A client passes the "proxy=yes" or "proxy=ondemand" query parameter
in addition to (but typically instead of) a "base" query parameter.</t>
        <t>A server that receives a "proxy=yes" query parameter in a registration
(or receives "proxy=ondemand" and decides it needs to proxy)
MUST come up with a "Proxy URL" on which it accepts requests,
and which it uses as a Registration Base URI for lookups on the present registration.</t>
        <t>The Proxy URL SHOULD have no path component,
as acting as a reverse proxy in such a scenario
means that any relative references in all representations that are proxied must be recognized
and possibly rewritten.</t>
        <t>The RD MAY mint several alternative Registration Base URIs
using different protocols
to make the proxied content available;
<xref target="I-D.silverajan-core-coap-protocol-negotiation" format="default"/> can be used to advertise them.</t>
        <t>The registrant is not informed of the chosen public name by the RD.</t>
        <t>This mechanism is applicable to all transports that can be used to register.
If proxying is active, the restrictions on when the base parameter needs to be present
(<xref target="I-D.ietf-core-resource-directory" format="default"/> Registration template)
are relaxed:
The base parameter may also be absent if the connection originates from an ephemeral port,
as long as the underlying protocol supports role reversal,
and link-local IPv6 addresses may be used without any concerns of expressibility.</t>
        <t>If the client uses the role reversal rule relaxation,
both it and the server keep that connection open for as long as it wants to be reachable.
When the connection terminates, the RD SHOULD treat the registration as having timed out
(even if its lifetime has not been exceeded) and MAY eventually remove the registration.
It is yet to be decided whether the RD's announced ability to do proxying
should imply that infinite lifetimes are necessarily supported for such registrations;
at least, it is RECOMMENDED.</t>
        <section anchor="registration-updates" numbered="true" toc="default">
          <name>Registration updates</name>
          <t>The "proxy" query parameter can not be changed or repeated in a registration update;
RD servers MUST answer 4.00 Bad Request to any registration update that has a "proxy" query parameter.</t>
          <t>As always, registration updates can explicitly or implicitly update the Registration Base URI.
In proxied registrations, those changes are not propagated to lookup,
but do change the forwarding address of the proxy.</t>
          <t>For example, if a registration is established over TCP,
an update can come along in a new TCP connection.
Starting then, proxied requests are forwarded along that new connection.</t>
        </section>
        <section anchor="proxy-behavior" numbered="true" toc="default">
          <name>Proxy behavior</name>
          <t>The RD operates as a reverse-proxy as described in <xref target="RFC7252" format="default"/> Section 5.7.3 at the announced Proxy URL(s),
where it decides based on the requested host and port
to which registrant endpoint to forward the request.</t>
          <t>The address the incoming request are forwarded to is the base address of the registration.
If an explicit "base" paremter is given,
the RD will forward requests to that location.
Otherwise, it forwards to the registration's source address
(which is the implied base parameter).</t>
          <t>When an implicit base is used,
the requests forwarded by the RD to the EP contain no Uri-Host option.
EPs that want to run multiple parallel registrations
(especially gateway-like devices)
can either open up separate connections,
or use an additional (to-be-specified) mechanism to set the "virtual host name" for that registration in a separate argument.</t>
        </section>
        <section anchor="on-demand-proxying" numbered="true" toc="default">
          <name>On-Demand proxying</name>
          <t>If an endpoint is deployed in an unknown network,
it might not know whether it is behind a NAT that would require it to configure an explicit base address,
and ask the RD to assist by proxying if necessary by registering with the "proxy=ondemand" query parameter.</t>
          <t>A server receiving that SHOULD use a different IP address to try
to access the registrant's .well-known/core file using a GET request under the Registration Base URI.
If that succeeds, it may assume that no NAT is present, and ignore the proxying request.
Otherwise, it configures proxying as if "proxy=yes" were requested.</t>
          <t>Note that this is only a heuristic
[ and not tested in deployments yet ].</t>
        </section>
        <section anchor="multiple-upstreams" numbered="true" toc="default">
          <name>Multiple upstreams</name>
          <t>When a proxying RD is operating behind a router that has uplinks with multiple provisioning domains (see <xref target="RFC7556" format="default"/>) or a similar setup,
it MAY mint multiple addresses that are reachable on the respective provisioning domains.
When possible, it is preferred to keep the number of URIs handed out low (avoiding URI aliasing);
this can be achieved by announcing both the proxy's public addresses under the same wildcard name.</t>
          <t>If RDs are announced by the uplinks using RDAO,
the proxy may use the methods of <xref target="I-D.amsuess-core-rd-replication" format="default"/> to distribute its registrations to all the announced upstream RDs.</t>
          <t>In such setups, the router can forward the upstream RDs using the PvD option (<xref target="RFC8801" format="default"/>) to PvD-aware hosts
and only announce the local RD to PvD-unaware ones (which then forwards their registrations).
It can be expected that PvD-aware endpoints are capable of registering with multiple RDs simultaneously.</t>
        </section>
        <section anchor="examples" numbered="true" toc="default">
          <name>Examples</name>
          <section anchor="registration-through-a-firewall" numbered="true" toc="default">
            <name>Registration through a firewall</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
Req from [2001:db8:42::9876]:5683:
POST coap://rd.example.net/rd?ep=node9876&proxy=ondemand
</some-resource>;rt="example.x"

Req from other-address.rd.example.net:
GET coap://[2001:db8:42::9876]/.well-known/core

Request blocked by stateful firewall around [2001:db8:42::]

RD decides that proxying is necessary

Res: 2.04 Created
Location: /reg/abcd
]]></artwork>
            <t>Later, lookup of that registration might say:</t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
Req: GET coap://rd.example.net/lookup/res?rt=example.x

Res: 2.05 Content
<coap://node987.rd.example.net/some-resource>;rt="example.x
]]></artwork>
            <t>A request to that resource will end up at an IP address of the RD,
which will forward it using its the IP and port on which the registrant had registered as source port,
thus reaching the registrant through the stateful firewall.</t>
          </section>
          <section anchor="browser" numbered="true" toc="default">
            <name>Registration from a browser context</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
Req: POST coaps+ws://rd.example.net/rd?ep=node1234&proxy=yes
</gyroscope>;rt="core.s"

Res: 2.04 Created
Location: /reg/123
]]></artwork>
            <t>The gyroscope can now not only be looked up in the RD, but also be reached:</t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
Req: GET coap://rd.example.net/lookup/res?rt=core.s

Res: 2.05 Content
<coap://[2001:db8:1::1]:10123/gyroscope>;rt="core.s"
]]></artwork>
            <t>In this example, the RD has chosen to do port-based rather than host-based virtual hosting
and announces its literal IP address
as that allows clients to not send the lengthy Uri-Host option with all requests.</t>
          </section>
        </section>
        <section anchor="notes-on-stability-and-maturity" numbered="true" toc="default">
          <name>Notes on stability and maturity</name>
          <t>Using this with UDP can be quite fragile;
the author only draws on own experience that this can work across cell-phone NATs
and does not claim that this will work over generic firewalls.</t>
          <t>[ It may make sense to have the example as TCP right away. ]</t>
        </section>
        <section anchor="security-considerations" numbered="true" toc="default">
          <name>Security considerations</name>
          <t>An RD MAY impose additional restrictions on which endpoints can register for proxying,
and thus respond 4.01 Unauthorized to request that would pass had they not requested proxying.</t>
          <t>Attackers could do third party registrations with an attacked device's address as base URI,
though the RD would probably not amplify any attacks in that case.</t>
          <t>The RD MUST NOT reveal the address at which it reaches the registrant
except for adaequately authenticated and authorized debugging purposes,
as that address could reveal sensitive location data the registrant may wish to hide by using a proxy.</t>
          <t>Usual caveats for proxies apply.</t>
        </section>
      </section>
    </section>
    <section anchor="infinite-lifetime" numbered="true" toc="default">
      <name>Infinite lifetime</name>
      <t>An RD can indicate support for infinite lifetimes
by adding the resoruce type "TBD2" to its list of resource types.</t>
      <t>A registrant that wishes to keep its registration alive indefinitely
can set the lifetime value as "lt=inf".</t>
      <t>Registrations with infinite lifetimes never time out.
Unlike regular registrations, they are not "soft state";
the registrant can expect the RD to persist the registrations
across network changes, reboots, softare updates and that like.</t>
      <t>Typical use cases for infinite life times are:</t>
      <ul spacing="normal">
        <li>Commissioning tools (CTs) that do not return to the deployment site,
and thus can not refresh the soft state</li>
        <li>Proxy registrations whose lifetime is limited by a connection that is kept alive</li>
      </ul>
      <section anchor="example" numbered="true" toc="default">
        <name>Example</name>
        <t>Had the example of <xref target="browser" format="default"/> discovered support for infinite lifetimes during lookup like this:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Req: GET coaps+ws://rd.example.net/.well-known/coer?rt=core.rd*

Res: 2.05 Content
</rd>;rt="core.rd TBD1 TBD2";ct=40
]]></artwork>
        <t>it could register like that:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Req: POST coaps+ws://rd.example.net/rd?ep=node1234&proxy=yes&lt=inf
</gyroscope>;rt="core.s"

Res: 2.04 Created
Location: /reg/123
]]></artwork>
        <t>and never need to update the registration for as long as the websocket connection is open.</t>
        <t>(When it gets terminated, it could try renewing the registration,
but needs to be prepared for the RD to already have removed the original registration.)</t>
      </section>
    </section>
    <section anchor="lookup-across-link-relations" numbered="true" toc="default">
      <name>Lookup across link relations</name>
      <t>Resource lookup occasionally needs execute multiple queries to follow links.</t>
      <t>An RD server
(or any other server that supports <xref target="RFC6690" format="default"/> compatible lookup),
can announce support for following links in resource lookups
by announcing support for the TBD3 interface type on its resource lookup.</t>
      <t>A client can the query that server to not only provide the matched links,
but also links that are reachable over relations given in "follow" query parameters.</t>
      <section anchor="example-1" numbered="true" toc="default">
        <name>Example</name>
        <t>Assume a node presents the following data in its &lt;.well-known/core&gt; resource
(and submitted the same to the RD):</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
</temp>;if="core.s";rt="example.temperature",
</t-prot>;rel="calibration-protocol";anchor="/temp",
<http://vendor.example.com/temp9000>;rel="describedby";anchor="/temp",
</hum>;if="core.s";rt="example.humidity",
</h-prot>;rel="calibration-protocol";anchor="/hum",
]]></artwork>
        <t>A lookup client can, in one query,
find the temperature sensor
and its relevant metadata:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Req: GET /rd-lookup/res?rt=example.temperature&follow=calibration-protocol&follow=describedby

<coap://node1/temp>;if="core.s";rt="example.temperature";anchor="coap://node1",
<coap://node1/t-prot>;rel="calibration-protocol";anchor="coap://node1/temp",
<http://vendor.example.com/temp9000>;rel="describedby";anchor="coap://node1/temp",
]]></artwork>
        <t>[
There is a <eref target="https://github.com/ace-wg/ace-oauth/issues/120#issuecomment-407997786">better example</eref> in an earlier stage of <xref target="I-D.tiloca-core-oscore-discovery" format="default"/>
]</t>
        <t>Given the likelihood of a CoRAL based successor to <xref target="RFC6690" format="default"/>,
this lookup variant might easily be superseeded by a
CoRAL FETCH format;
it might look like this there:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Req: FETCH /reef-lookup
Content-Format: application/template-coral+cbor
Payload:
#using core = <...>
#using reef = <...>
reef:content ?x {
  core:rt "example.temperature"
  calibration-protocol ?y {
    core:describedby ?z
  }
}

Res: 2.01 Content
Content-Format: aplication/coral+cbor
Payload:
reef:content <coap://node1/temp> {
    core:rt "example.temperature"
    calibration-protocol <coap://node1/t-prot> {
      core:describedby <http://vendor.example.com/temp9000>
    }
}
]]></artwork>
      </section>
    </section>
    <section anchor="lifetime-age" numbered="true" toc="default">
      <name>Lifetime Age</name>
      <t>This extension is described in <xref target="I-D.amsuess-core-rd-replication" format="default"/> Section 5.2.</t>
      <t>The "provenance" extension in Section 5.1 of the same document
should probably be expressed differently to avoid using non-target link attributes.</t>
    </section>
    <section anchor="zone-identifier-introspection" numbered="true" toc="default">
      <name>Zone identifier introspection</name>
      <t>The 'split-horizon' mechanism introduced in <xref target="I-D.ietf-core-resource-directory" format="default"/> (-19)
(that registrations with link-local bases can only be read from the zone they registered on)
reduces the usability of the endpoint lookup interface for debugging purposes.</t>
      <t>To allow an administrator to read out the "show-zone-id" query parameter for endpoint and resource lookup is introduced.</t>
      <t>A Resource Directory that understands this parameter MUST NOT limit lookup results to registrations from the lookup's zone,
and MUST use <xref target="RFC6874" format="default"/> zone identifiers to annotate which zone those registrations are valid on.</t>
      <t>The RD MUST limit such requests to authenticated and authorized debugging requests,
as registrants may rely on the RD to keep their presence secret from other links.</t>
      <section anchor="example-2" numbered="true" toc="default">
        <name>Example</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Req: GET /rd-lookup/ep?show-zone-id&et=printer

Res: 2.05 Content
</reg/1>;base="coap://[2001:db8::1]";et=printer;ep="bigprinter",
</reg/2>;base="coap://[fe80::99%wlan0]";et=printer;ep="localprinter-1234",
</reg/3>;base="coap://[fe80::99%eth2]";et=printer;ep="localprinter-5678",
]]></artwork>
      </section>
    </section>
    <section anchor="proxying-multicast-requests" numbered="true" toc="default">
      <name>Proxying multicast requests</name>
      <t>Multicast requests are hard to forward at a proxy:
Even if a media type is used
in which multiple responses can be aggregated transparently,
the proxy can not reliably know when all responses have come in.
<xref target="RFC7390" format="default"/> Section 2.9 destribes the difficulties in more detail.</t>
      <t>Note that <xref target="I-D.tiloca-core-groupcomm-proxy" format="default"/> provides a mechanism
that <em>does</em> allow the forwarding of multicast requests.
It is yet to be determined what the respective pros and cons are.
Conversely, that lookup mechanism may also serve as an alternative to resource lookup on an RD.</t>
      <t>A proxy MAY expose an interface compatible with the RD lookup interface,
which SHOULD be advertised by a link to it that indicates the resource types
core.rd-lookup-res and TBD4.</t>
      <t>The proxy sends multicast requests to All CoAP Nodes (<xref target="RFC7252" format="default"/> Section 12.8)
requesting their .well-known/core files
either eagerly (ie. in regular intervals independent of queries)
or on demand
(in which case it SHOULD limit the results by applying <xref target="RFC6690" format="default"/> query filtering;
if it has received multiple query parameters it should forward the one it deems most likely to limit the results,
as .well-known/core only supports a single query parameter).</t>
      <t>In comparison to classical RD operation,
this RD behaves roughly as if it had received a simple registration
with a All CoAP Nodes address as the source address,
if such behavior were specified.
The individual registrations that result from this
neither have an explicit registration resource
nor an explicit endpoint name;
given that the endpoint lookup interface is not present on such proxies,
neither can be queried.</t>
      <t>Clients that would intend to do run a multicast discovery operation behind the proxy
can then instead query that resource lookup interface.
They SHOULD use observation on lookups,
as an on-demand implementation MAY return the first result before others have arrived,
or MAY even return an empty link set immediately.</t>
      <section anchor="example-3" numbered="true" toc="default">
        <name>Example</name>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Req: GET coap+ws://gateway.example.com/.well-known/core?rt=TBD4

Res: 2.05 Content
</discover>;rt="core.rd-lookup-res TBD4";ct=40

Req: GET coap+ws://gateway.example.com/discover?rt=core.s
Observe: 0

Res: 2.05 Content
Observe: 0
Content-Format: 40
(empty payload)
]]></artwork>
        <t>At the same time, the proxy sends out multicast requests on its interfaces:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Req: GET coap://ff05::fd/.well-known/core?rt=core.s

Res (from [2001:db8::1]:5683): 2.05 Content
</temp>;ct="0 112";rt="core.s"

Res (from [2001:db8::2]:5683): 2.05 Content
</light>;ct="0 112";rt="core.s"
]]></artwork>
        <t>upon receipt of which it sends out a notification to the websocket client:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
Res: 2.05 Content
Observe: 1
Content-Format: 40
<coap://[2001:db8::1]/temp>;ct="0 112";rt="core.s";anchor="coap://[2001:db8::1]",
<coap://[2001:db8::2]/light>;ct="0 112";rt="core.s";anchro="coap://[2001:db8::2]"
]]></artwork>
      </section>
    </section>
    <section anchor="opportunistic-rd" numbered="true" toc="default">
      <name>Opportunistic RD</name>
      <t>An application that wants to advertise its resources in Resource Directory
can find itself in a network that has no RD deployed.
It may be able to start an RD on its own to fill in that gap until an explicitly configured one gets installed.</t>
      <t>This bears the risk of having competing RDs on the same network,
where resources registered at one can not be discovered on the other.
To mitigate that, such Opportunistic Resource Directories should follow those steps:</t>
      <ul spacing="normal">
        <li>
          <t>The RD chooses its own Opportunistic Capability value.
That integer number is an estimate of number of target attributes it expects to be able to store,
where in absence of better estimates one would assume that a registration contains 16 links,
and each links contains three target attributes each with an eight byte key and a 16 byte value.  </t>
          <t>
The Opportunistic Capability value is advertised as a TBD5-cap= target attribute on the registration resource.</t>
        </li>
        <li>
          <t>The RD chooses its own Opportunistic Tie-Break value.
That integer number needs no other properties than being likely to be different
even for two instances of the same device being started;
numeric forms of MAC addresses or random numbers make good candidates.  </t>
          <t>
The Opportunistic Capability value is advertised as a TBD5-tie= target attribute on the registration resource.</t>
        </li>
        <li>The Opportunistic RD, before advertising its resources, performs RD discovery itself,
using at least all the discovery paths it may become discoverable on itself.</li>
        <li>
          <t>If the Opportunistic RD finds no other RD,
or if the RD it finds is less capable than itself,
it can start advertising itself as a Resource Directory.  </t>
          <t>
An RD is called more capable than another if its TBD5-cap value is greater than the other's,
or if its TBD5-tie value is greater than the other's if the former results in a tie.
Absent or unparsable attributes are considered greater than any present attribute.  </t>
          <t>
In case an RD observes a tie even after evaluating the tie breaker,
it may change its Opportunistic Tie-Break value if that was picked randomly,
or reevaluate its life choices if it uses its own MAC address.</t>
        </li>
        <li>
          <t>A running Opportunistic RD needs to perform discovery for other RDs repeatedly.
If it discovers a more capable RD,
it stops advertising its own resources.
It should continue to serve lookup requests,
but refuse any new registration or registration updates
(which will trigger the registrant endpoints to look for a new RD).  </t>
          <t>
An inactive Opportunistic RD will be notified of the highter capability RD's shutdown
by the expiry of whatever it may be started to advertise that was now advertised there;
see below for possible improvements.</t>
        </li>
        <li>
          <t>An RD that discovers an Opportunistic RD of lower capability may speed up the transition process
by (not mutually exclusive) two ways
          </t>
          <ul spacing="normal">
            <li>It can register its own (registration) resource(s) into the lower capability directory.
That RD can take that as having discovered a higher capability RD and stop advertising.</li>
            <li>It can expose resources and registrations of the lower capability directory
using the methods described in <xref target="I-D.amsuess-core-rd-replication" format="default"/>.</li>
          </ul>
        </li>
        <li>An Opportunistic RD that yields to a more capable RD may ease the transition
by attempting to register its active registrations at the more capable RD,
taking the role of a CT.
The lifetimes picked for those must not exceed the remaining lifetime of its registrations,
and it must not renew those registrations.</li>
      </ul>
      <t>Future iterations of this document may want to cut down on the possibilities listed above.</t>
      <t>Some ideas are around for making the shutdown of a commissioned or otherwise high-capability RD more graceful,
but they still have some problems</t>
      <ul spacing="normal">
        <li>Setting a commissioned or high-capability RD's Capability to zero in preparation of the shutdown
may create loops in any distributed lookups.</li>
        <li>Asking the lower capability RD to register its registration resource
(even though not otherwise advertised) at the higher capability RD
still creates a situation where clients may find two RDs running simultaneously,
and we can't expect clients to make any decisions based on TBD5 values.</li>
        <li>Asking the higher capability RD to register its registration resource
with the lower capability RD contradicts the current recommendation for the
passive Opportunistic RD to not accept registrations / renewals.
Also, the deployed RD may not know that Opportunistic RDs are a thing.</li>
        <li>Advertising an almost-but-not-quite rt= value on passive registration resources may be an option,
but needs to be thought through thoroughly.</li>
      </ul>
      <t>Installations of Opportunistic RDs are at special risk of resource exhaustion
because they are not sized with their actual deployment in mind,
but rely on defaults set by the application that starts the RD.
Opportunistic RDs should only be started if the application's administrator
can be informed in a timely fashion when the RD's resources are nearing exhaustion;
guidance towards installing a more capable RD on the network should be provided in that case.</t>
      <section anchor="applications" numbered="true" toc="default">
        <name>Applications</name>
        <ul spacing="normal">
          <li>Group managers using <xref target="I-D.tiloca-core-oscore-discovery" format="default"/> can ship its own low-priority Opportunistic RD
to announce its join resources.
This provides benefits over announcing them on multicast discovery
if the network can efficiently route requests to the All CoAP Resource Directories multicast address
(so group members get a response back from an early focused request to all RDs
rather than falling back to multicasting All CoAP Nodes for <tt>?rt=osc.j&amp;...</tt>),
or if discovery of the group's multicast address is used.</li>
          <li>
            <t>Administrative tools that try to provide a broad overview of a network's CoAP devices
could offer to open an Opportunistic RD if they find no active RD on the network
(but should ask the user in interactive scenarios).  </t>
            <t>
That allows them to see devices that newly join the network quickly (by observing their own or the found RD),
rather than relying periodic multicasts.</t>
          </li>
        </ul>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="I-D.ietf-core-resource-directory" target="http://www.ietf.org/internet-drafts/draft-ietf-core-resource-directory-26.txt">
          <front>
            <title>CoRE Resource Directory</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-core-resource-directory-26"/>
            <author initials="C" surname="Amsuess" fullname="Christian Amsuess">
              <organization/>
            </author>
            <author initials="Z" surname="Shelby" fullname="Zach Shelby">
              <organization/>
            </author>
            <author initials="M" surname="Koster" fullname="Michael Koster">
              <organization/>
            </author>
            <author initials="C" surname="Bormann" fullname="Carsten Bormann">
              <organization/>
            </author>
            <author initials="P" surname="Stok" fullname="Peter van der Stok">
              <organization/>
            </author>
            <date month="November" day="2" year="2020"/>
            <abstract>
              <t>In many IoT applications, direct discovery of resources is not practical due to sleeping nodes, or networks where multicast traffic is inefficient.  These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources.  The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD.  This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, lookup and remove information on resources.  Furthermore, new target attributes useful in conjunction with an RD are defined.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.amsuess-core-rd-replication" target="http://www.ietf.org/internet-drafts/draft-amsuess-core-rd-replication-02.txt">
          <front>
            <title>Resource Directory Replication</title>
            <seriesInfo name="Internet-Draft" value="draft-amsuess-core-rd-replication-02"/>
            <author initials="C" surname="Amsuess" fullname="Christian Amsuess">
              <organization/>
            </author>
            <date month="March" day="11" year="2019"/>
            <abstract>
              <t>Discovery of endpoints and resources in M2M applications over large networks is enabled by Resource Directories, but no special consideration has been given to how such directories can scale beyond what can be managed by a single device.  This document explores different ways in which Resource Directories can be scaled up from single network to enterprise and global scale. It does not attempt to standardize any of those methods, but only to demonstrate the feasibility of such extensions and to provide terminology and exploratory groundwork for later documents.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6874" target="https://www.rfc-editor.org/info/rfc6874">
          <front>
            <title>Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers</title>
            <seriesInfo name="DOI" value="10.17487/RFC6874"/>
            <seriesInfo name="RFC" value="6874"/>
            <author initials="B." surname="Carpenter" fullname="B. Carpenter">
              <organization/>
            </author>
            <author initials="S." surname="Cheshire" fullname="S. Cheshire">
              <organization/>
            </author>
            <author initials="R." surname="Hinden" fullname="R. Hinden">
              <organization/>
            </author>
            <date year="2013" month="February"/>
            <abstract>
              <t>This document describes how the zone identifier of an IPv6 scoped address, defined as &lt;zone_id&gt; in the IPv6 Scoped Address Architecture (RFC 4007), can be represented in a literal IPv6 address and in a Uniform Resource Identifier that includes such a literal address.  It updates the URI Generic Syntax specification (RFC 3986) accordingly.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7252" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml">
          <front>
            <title>The Constrained Application Protocol (CoAP)</title>
            <seriesInfo name="DOI" value="10.17487/RFC7252"/>
            <seriesInfo name="RFC" value="7252"/>
            <author initials="Z." surname="Shelby" fullname="Z. Shelby">
              <organization/>
            </author>
            <author initials="K." surname="Hartke" fullname="K. Hartke">
              <organization/>
            </author>
            <author initials="C." surname="Bormann" fullname="C. Bormann">
              <organization/>
            </author>
            <date year="2014" month="June"/>
            <abstract>
              <t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks.  The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s.  The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t>
              <t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types.  CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t>
            </abstract>
          </front>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC8323" target="https://www.rfc-editor.org/info/rfc8323">
          <front>
            <title>CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets</title>
            <seriesInfo name="DOI" value="10.17487/RFC8323"/>
            <seriesInfo name="RFC" value="8323"/>
            <author initials="C." surname="Bormann" fullname="C. Bormann">
              <organization/>
            </author>
            <author initials="S." surname="Lemay" fullname="S. Lemay">
              <organization/>
            </author>
            <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
              <organization/>
            </author>
            <author initials="K." surname="Hartke" fullname="K. Hartke">
              <organization/>
            </author>
            <author initials="B." surname="Silverajan" fullname="B. Silverajan">
              <organization/>
            </author>
            <author initials="B." surname="Raymor" fullname="B. Raymor" role="editor">
              <organization/>
            </author>
            <date year="2018" month="February"/>
            <abstract>
              <t>The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP.  The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control.</t>
              <t>Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports.  It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6887" target="https://www.rfc-editor.org/info/rfc6887">
          <front>
            <title>Port Control Protocol (PCP)</title>
            <seriesInfo name="DOI" value="10.17487/RFC6887"/>
            <seriesInfo name="RFC" value="6887"/>
            <author initials="D." surname="Wing" fullname="D. Wing" role="editor">
              <organization/>
            </author>
            <author initials="S." surname="Cheshire" fullname="S. Cheshire">
              <organization/>
            </author>
            <author initials="M." surname="Boucadair" fullname="M. Boucadair">
              <organization/>
            </author>
            <author initials="R." surname="Penno" fullname="R. Penno">
              <organization/>
            </author>
            <author initials="P." surname="Selkirk" fullname="P. Selkirk">
              <organization/>
            </author>
            <date year="2013" month="April"/>
            <abstract>
              <t>The Port Control Protocol allows an IPv6 or IPv4 host to control how incoming IPv6 or IPv4 packets are translated and forwarded by a Network Address Translator (NAT) or simple firewall, and also allows a host to optimize its outgoing NAT keepalive messages.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.silverajan-core-coap-protocol-negotiation" target="http://www.ietf.org/internet-drafts/draft-silverajan-core-coap-protocol-negotiation-09.txt">
          <front>
            <title>CoAP Protocol Negotiation</title>
            <seriesInfo name="Internet-Draft" value="draft-silverajan-core-coap-protocol-negotiation-09"/>
            <author initials="B" surname="Silverajan" fullname="Bill Silverajan">
              <organization/>
            </author>
            <author initials="M" surname="Ocak" fullname="Mert Ocak">
              <organization/>
            </author>
            <date month="July" day="2" year="2018"/>
            <abstract>
              <t>CoAP has been standardised as an application-level REST-based protocol.  When multiple transport protocols exist for exchanging CoAP resource representations, this document introduces a way forward for CoAP endpoints as well as intermediaries to agree upon alternate transport and protocol configurations as well as URIs for CoAP messaging.  Several mechanisms are proposed: Extending the CoRE Resource Directory with new parameter types, introducing a new CoAP Option with which clients can interact directly with servers without needing the Resource Directory, and finally a new CoRE Link Attribute allowing exposing alternate locations on a per-resource basis.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7556" target="https://www.rfc-editor.org/info/rfc7556">
          <front>
            <title>Multiple Provisioning Domain Architecture</title>
            <seriesInfo name="DOI" value="10.17487/RFC7556"/>
            <seriesInfo name="RFC" value="7556"/>
            <author initials="D." surname="Anipko" fullname="D. Anipko" role="editor">
              <organization/>
            </author>
            <date year="2015" month="June"/>
            <abstract>
              <t>This document is a product of the work of the Multiple Interfaces Architecture Design team.  It outlines a solution framework for some of the issues experienced by nodes that can be attached to multiple networks simultaneously.  The framework defines the concept of a Provisioning Domain (PvD), which is a consistent set of network configuration information.  PvD-aware nodes learn PvD-specific information from the networks they are attached to and/or other sources.  PvDs are used to enable separation and configuration consistency in the presence of multiple concurrent connections.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8801" target="https://www.rfc-editor.org/info/rfc8801">
          <front>
            <title>Discovering Provisioning Domain Names and Data</title>
            <seriesInfo name="DOI" value="10.17487/RFC8801"/>
            <seriesInfo name="RFC" value="8801"/>
            <author initials="P." surname="Pfister" fullname="P. Pfister">
              <organization/>
            </author>
            <author initials="É." surname="Vyncke" fullname="É. Vyncke">
              <organization/>
            </author>
            <author initials="T." surname="Pauly" fullname="T. Pauly">
              <organization/>
            </author>
            <author initials="D." surname="Schinazi" fullname="D. Schinazi">
              <organization/>
            </author>
            <author initials="W." surname="Shao" fullname="W. Shao">
              <organization/>
            </author>
            <date year="2020" month="July"/>
            <abstract>
              <t>Provisioning Domains (PvDs) are defined as consistent sets of network configuration information. PvDs allows hosts to manage connections to multiple networks and interfaces simultaneously, such as when a home router provides connectivity through both a broadband and cellular network provider.</t>
              <t>This document defines a mechanism for explicitly identifying PvDs through a Router Advertisement (RA) option. This RA option announces a PvD identifier, which hosts can compare to differentiate between PvDs. The option can directly carry some information about a PvD and can optionally point to PvD Additional Information that can be retrieved using HTTP over TLS.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6690" target="https://www.rfc-editor.org/info/rfc6690" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6690.xml">
          <front>
            <title>Constrained RESTful Environments (CoRE) Link Format</title>
            <seriesInfo name="DOI" value="10.17487/RFC6690"/>
            <seriesInfo name="RFC" value="6690"/>
            <author initials="Z." surname="Shelby" fullname="Z. Shelby">
              <organization/>
            </author>
            <date year="2012" month="August"/>
            <abstract>
              <t>This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links.  Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type.  "RESTful" refers to the Representational State Transfer (REST) architecture.  A well-known URI is defined as a default entry point for requesting the links hosted by a server.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.tiloca-core-oscore-discovery" target="http://www.ietf.org/internet-drafts/draft-tiloca-core-oscore-discovery-07.txt">
          <front>
            <title>Discovery of OSCORE Groups with the CoRE Resource Directory</title>
            <seriesInfo name="Internet-Draft" value="draft-tiloca-core-oscore-discovery-07"/>
            <author initials="M" surname="Tiloca" fullname="Marco Tiloca">
              <organization/>
            </author>
            <author initials="C" surname="Amsuess" fullname="Christian Amsuess">
              <organization/>
            </author>
            <author initials="P" surname="Stok" fullname="Peter van der Stok">
              <organization/>
            </author>
            <date month="November" day="2" year="2020"/>
            <abstract>
              <t>Group communication over the Constrained Application Protocol (CoAP) can be secured by means of Group Object Security for Constrained RESTful Environments (Group OSCORE).  At deployment time, devices may not know the exact security groups to join, the respective Group Manager, or other information required to perform the joining process.  This document describes how a CoAP endpoint can use descriptions and links of resources registered at the CoRE Resource Directory to discover security groups and to acquire information for joining them through the respective Group Manager.  A given security group may protect multiple application groups, which are separately announced in the Resource Directory as sets of endpoints sharing a pool of resources.  This approach is consistent with, but not limited to, the joining of security groups based on the ACE framework for Authentication and Authorization in constrained environments.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7390" target="https://www.rfc-editor.org/info/rfc7390">
          <front>
            <title>Group Communication for the Constrained Application Protocol (CoAP)</title>
            <seriesInfo name="DOI" value="10.17487/RFC7390"/>
            <seriesInfo name="RFC" value="7390"/>
            <author initials="A." surname="Rahman" fullname="A. Rahman" role="editor">
              <organization/>
            </author>
            <author initials="E." surname="Dijk" fullname="E. Dijk" role="editor">
              <organization/>
            </author>
            <date year="2014" month="October"/>
            <abstract>
              <t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for constrained devices and constrained networks. It is anticipated that constrained devices will often naturally operate in groups (e.g., in a building automation scenario, all lights in a given room may need to be switched on/off as a group). This specification defines how CoAP should be used in a group communication context.  An approach for using CoAP on top of IP multicast is detailed based on existing CoAP functionality as well as new features introduced in this specification.  Also, various use cases and corresponding protocol flows are provided to illustrate important concepts.  Finally, guidance is provided for deployment in various network topologies.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.tiloca-core-groupcomm-proxy" target="http://www.ietf.org/internet-drafts/draft-tiloca-core-groupcomm-proxy-02.txt">
          <front>
            <title>Proxy Operations for CoAP Group Communication</title>
            <seriesInfo name="Internet-Draft" value="draft-tiloca-core-groupcomm-proxy-02"/>
            <author initials="M" surname="Tiloca" fullname="Marco Tiloca">
              <organization/>
            </author>
            <author initials="E" surname="Dijk" fullname="Esko Dijk">
              <organization/>
            </author>
            <date month="November" day="2" year="2020"/>
            <abstract>
              <t>This document specifies the operations performed by a forward-proxy, when using the Constrained Application Protocol (CoAP) in group communication scenarios.  Proxy operations involve the processing of individual responses from servers, as reply to a single request sent by the client over unicast to the proxy, and then distributed by the proxy over IP multicast to the servers.  When receiving the different responses via the proxy, the client is able to distinguish them and their origin servers, by acquiring their addressing information.</t>
            </abstract>
          </front>
        </reference>
      </references>
    </references>
    <section anchor="change-log" numbered="true" toc="default">
      <name>Change log</name>
      <t>Since -04:</t>
      <ul spacing="normal">
        <li>
          <t>Minor adjustments:
          </t>
          <ul spacing="normal">
            <li>Mention LwM2M and how it is already doing RD proxying.</li>
            <li>Tie proxying in with infinite lifetimes.</li>
            <li>Remove note on not being able to switch protocols: RDs that support some future protocol negotiation can do that.</li>
            <li>Point out that there is no Uri-Host from the RD proxy to the EP, but there could be.</li>
            <li>Infinite lifetimes: Take up CTs more explicitly from RD discussion.</li>
            <li>Start exploring interactions with groupcomm-proxy.</li>
          </ul>
        </li>
      </ul>
      <t>Since -03:</t>
      <ul spacing="normal">
        <li>Added interaction with PvD (Provisioning Domains)</li>
      </ul>
      <t>Since -02:</t>
      <ul spacing="normal">
        <li>Added abstract</li>
        <li>Added example of CoRAL FETCH to Lookup across link relations section</li>
      </ul>
      <t>Since -01:</t>
      <ul spacing="normal">
        <li>Added section on Opportunistic RDs</li>
      </ul>
      <t>Since -00:</t>
      <ul spacing="normal">
        <li>Add multicast proxy usage pattern</li>
        <li>ondemand proxying: Probing queries must be sent from a different address</li>
        <li>proxying: Point to RFC7252 to describe how the actual proxying happens</li>
        <li>proxying: Describe this as a last-resort options and suggest attempting PCP first</li>
      </ul>
    </section>
    <section anchor="acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>[ Reviews from: Jaime Jimenez ]</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAJXLM2AAA61c65LbRnb+j6dARhVrxktyLrpTKzuzM/JaKctSyVKlEq8q
AYkm2SsQYNDAULRKb5Z/ebGc75zTjQZIjeUkLpc9JIHu0+d+7fF4nDS2Kcw0
varePE/fGFe19dyk17Y286aqd+nzj40pna1Kl+TVvMzW9GxeZ4tmnK1da5wb
z6vajGt9c5z7N8cmvDk+e5C4Jivzf8+KqqQFmro1id3U/JdrLs7OnpxdJPOs
mabm4ybZ2GmSpq6p7Zy+ubsz7i59bqp570NuNs2KvrmHz263rs3CdQ+4qm76
38yr9SaLF6Qv1qZs6BH6Aq+0s+6ZssIjBGNZNXZhTa7fZbXJpumLsjF1aZpk
uxTUJR+28sco/RczS3+y5QdbLkcxRt28ujH1bnQAy6P0dV193CVZ26yqepqM
U1sSWFeT9HLt/vu/HKAT1F+tausam5XRL4QoYwjmH6uiICTTx0l6fnF6n4+Y
00t3z88uzuTEbdnUu2l62QK7GX21WTFFjv50/9744cP74yePnpw9vPfkiH4y
68wW03Tut/wnpfiEsJSUVb3OGntjQKoX4+uJNc3iS7zgn+mzTE5PbgpLZCcm
mSa2XHRrJuPxOM1mBCWRI0kuCfSioMXoybRapB1vESekzcocYt1Pn34Prs+f
k2aVNemc8MkMmtLytJqt02pbjlJ8s8puTFpW6bwwWZ0u2qatDZEndRszJ8YQ
6ImDmokAvbZ5XpgkuQMmqau8FaA/3bHRx89J8nZlXUoi1YIH001VFY6Ydm2+
6mzJ15wt5bOt7XLVpDOTts4s2iKdtU0406bI5jhMgl2q2i5tmRUBqAmANLuw
whzQ2TK3NzZvo+dcSoRLXzx/+wNEaG0dgB+lzq43hIjaLC3I2PCJbCknuk5f
ZzVxNIkRHY+f2KUE7YvLny9HBEq6rKstPU0YyFK3yjYm3a5MbQDpjulFJ+Ld
msbkaebosT6LNMAoHeGySS2BOG/rGogmMjdmREAA+9Bjqd1/1+Ymw7t/+3VA
Jvp7Zkiw09zcmKLaYOsm/fOqaTZuenq6JF2azSAfpyQ1O1ee3qoXv5skf3sP
TnlDq9XOiBZIa/OfJCWNS5J/WZmSgPMoJADkT3oY+2YHVYn1NCfNJZTOEtfa
JpsV9GeeE0gODwGJxBOCu1nmwo+T5O1uQ4xd0G6ZE6rNizY3enbSTYQgeunn
y7fp1pLKIpaaV2DvIoWOI26uGzDFNqtzqMGECFqVxU4XYEiIsoQ/QnfbLCt8
SyuUQgKXHBNQm7paEoukdVuWvW23pGBnxB6OdmobW9jf8PNVdfladicF/Es1
/2Aa0gDfv/nh6vG9i3skDZ6NT4iwXyU+rl0uQYf0WLn2yhRFW5AWeHnxklE3
J6ydiJhtmHTZfA7s0tlcO1+lpsw3dDawn3AsPUXCY/JRQgRYkqZzrFqqcl6T
KKRrM19lpXVrrJBXvPJT4VX6l5fMuocmqkS6t/AcWaaSdsAKM2CryFzD5yOS
VBvmcPpJAQlIv7HNbgJ+I+W2qUiCiUSjVLARUybN8AAZVkPilE+Svxgiswls
CUJAGTA2mPLAW8S/jpilgNA0Zr1pmAlmTWbB5Zt2RsaAmCS7IbvDPAI+GiVY
0HzMoE0I69ji9dXr9FiI+/Dx40efP5+IrkodqZQIH8B6VjjGBO1XVDtCzIz0
R2FZbzHltoCrESoYYnrR/2Tct1X9IQjMoq7WokjkXWgW0gK6ZrYJhkz0VCAa
lKCdk17YEUFLg69+2oJ/fqUv5QXWmOXy/ST5uRIpze2CEGwIHkE4wwlMEl7J
8yExI+6jkxCMxghvClhssfRBJgA0rXWsClhAoP1jYL0VGyXypu5Dbx3T4YiT
sAaeg+4nDC3sshVdfpKabGlqOtem2pBUNMYxfkQQ5tl8RU4V4drpIl6rMYik
heuGl56RFN+occiaNLYWaWPXhvB8507nPRHWS0DnZQ5M7LrTLtqS+TQriJ+J
dvRKYx1DBrpnZUke0BxP4pREWytPp14BpM2OTM3R279cnx/h3DhR0AnhKQHq
TQQruyhCgk3msCM2OGLAnpF7eQSbph8rks81YeEoJYzQqhtvCRPIgcIEjjwG
tRrRxYRnUoCNychHWZyQuBxBZe8twWwJlJIeZBwR6Ib1TNaDZvBaamM7wwc6
JoDDy3uQg4g5sU4uuC2NyZ3qlY+7k+Tlu1/epuwvtBs2EdherNu7Nz8xZrcr
S+qM3oXO3BCaPYMIK4afWyCTbVSM7/QvMFjv3rxgdVNU1Yd249R7g35ypuwz
kyqIAEP6y4+v3v103blCGQEJ95+EtCSlgx3nzKK8d60WWrgb7p8oYzc3ZVbb
KlmbrFSFkpXglII92ZRVpUgycFyA1RQ+5Xp5p5a1KdBI1+ScQ2MR9qtlaX8z
OWNE1TLW3tZwe/yZSBxeXv4rqRHoV8BJ/JwVCFAEhIN4c4moUq9qmqBbXEJ0
XGcfTFAkAAr2nRWMV85PyYh+DyvqbIE9/56VYkvnVbYZ+8XGpVlSAMV7k0lV
M8jaC66dF1BstdbjRNZCNZdEBiZntw66blUR/tRgcGAE4Ra9ddAoqsZTtwNE
wPoO5kXxPwDM27NJ8mLRaRcrPHHD/iMAlRCVqSiKX/iPnalOtoJwzAJrJsdf
5YH0KAeLCTV7ghiUGewjRaWMssGG62wXzB7FUOy4KuaCJffuPtQ22zZCgNkQ
FZh9xPAS51O8zhKAl1uSftL3wESwQ67dCBbJ9zMqJVkhIlxQEDwuKjiSL17f
PPSmlDYEgB7b3oGE1LAJroFNhHjAFXG8Ldg3ASUiQ9d6HdvbmJzFQnHDSBsl
s6oRLaOGUXXjB2M2SvkIJfBHoU+ig1txEDz9yCMmviJGmohzPkAqYX8tSB15
O6p6hmJ0ta09E0c7kAZig2SZw1viDTpMCYrB+BR2YfATPSbCMIPFNx/nxFQm
P+FzQfrxTtOynajNmmzl3l7EyyxRFKrqYUSBQ9caerhWiO86byfh2Aj61R/1
kpCoGwfnZidoJBm1pSUf1gMsngshhohIGpKeU16hVYFjVqC94PBpQutQlO0a
DmII1DfPr169fPn85+vn12xy+zaXbEsOVIvaEBO1b9kg2YK3FBphCSTDsm2I
HvT3nuHTVZ8mRDthFpeyOSOFsaX17k/OzkiL5gQK2yvWKKzx99YQzKyyzvge
tNf0c7HNdsQyB9aQ0IGEwXuRBHzkU4aNvqDmiehl0OE9bINBK+eRotSq2Axs
siXjhk4mlpXEiCSUGEAe5u268C74yKqe+aR0sB86v30Edh7gmehL6CNZsm4F
okAs3169hu7wx8LR2YvIWByZVqXZ4rFI6ibJL96dpO3LUXRe73LWAV7wNC/G
tMFi8ULMY+IjzAwEs6qDjSXtUDNBYodgrHEfeYnGzWs7E5b69IlCk0cXDy5I
if+iuuHB5NHkXqpKoJOw4JEcu5NRIsEDcb93rqDafVrKH4i+INKJToNEwWCL
vxTZTh97gop69ngNNbaedPiFovxqHbnqA7TROtZ19m1A9IGmWaQR13pflbje
rNnbdBz8lhIeEm63lmyyhzKQrZEIOIUNkXVfQU9tyWFgDaEvhDxZDMNdZNPY
o1dAk2N1KfWwkCHEUD3TiThSki5lkDJ5hF6DufIBrULYYSc4IB6Y58yiHNuS
e/mutuMfQTMJwSfJ89eD8LNuKRJsi8YizAVARWGKvsiSZeB4jbU8RJS0xriw
H6DJbywp2pOElYVlbc7WjNxvZ7BaE9spxxkZTv6UcRR03FTjmRlrUAjz0stI
OCPMe3Rja9ga4UL4X0es0jXgiGUcEhsAyOqlTyxCzl6V42sOJzq74hnH8y5y
bz7GtkyVtvxQVtvSx+ecSOnSXfgtmDOr+bqVpS0kWyUYZ9sFGlqRNQn+ObQ1
Pb6NGV18msx9iOhMkZ51HFl2PuIi2LwdfogzIxwIRXHhFwPBOIqTGMx6jaXu
BNMuct5fvO5EmfiPAmWAp9monlNNgjHZmqIYMx5P4XymCxtSK1n61+dvgwZg
l+9W67IQsMiawyNxkn6E/+kc0Vq1bMXIt867v5JZt8uyqrsoYxepnqGkB/JE
sT6cs0UvqN2aOtKRhMSfqyYkTyQdw1nILF2Zlosa8+RvvzIsYJ5GVCvxmfCc
5LbhLv3tvbLsSy+gFG3Co1t3SdpBxkWsBT4HBqzJufNhOZyCdgMP2QlbdKKP
pAbSwxydVWtSIC49dsZoNvPRgwcPP38+gR+QIcdukZAkyYSVJkyFSDAs2Lnd
IdIMXmxnWCDzHC0e2l+d3S4xKKIV8oDgOfWoyYlo1zOonwWHmXRSTkfCxS9I
OI+zm8qy14DgPStsBrY7eZowhTQMI+gs2dd8kLNhXz6wCzGyRoDdCTt+5Uwg
mZV8DpMCHSUhxJtrcQc6A6ya21NDxODN9eUr0fVi4MHSrcSppBPJc8rZ8kkU
d0tZC1UYcp0hOpZ8KMM+fb8k4iPSnlfg+QvwAnBNODCdNbZQdgLKYvsev6mH
wdevb659+lczp48fn52DkWh/+nGcbYEWaHSXSCWsCMiXc0soJ5oPb7SlvFOV
hHm1rnDAIrvMqdTecU84DFE6k6IlrjOaeOyg6PLm+DTPNsKri31tGrgcpyVp
oI9ZaarWFTsV2efigTr+NAggmhUhcYk8zoJMwZbIkCQp/UOuvQTFv16cnZ1P
89nj6f2L6fTJ40cP308fPHx8b8qPvX7FWa5sMz09rfOJ+roTMk308XuzeVZW
ucFL3/T1Pb/851PkVEPc/93Tunl25Jf4eDQApII6HPsCTX8zAQZqW2E5APXp
UOeH9VnPzwoUTFgWuECGQqFHCdGAeCAf4OK9LnAdPNWuDKK5kmAH/V5uml5M
zu6nVzXHXvztT+rbTdNTIu5pNpvnSfIT/VyPNPgQD3PoWYjNd9luGk4yjXEw
oIcshXLc94TngOY+ZA/SK8lyCYF0JSXiAOm3Ug/mu+7CQ4Ve/VH2dYnD4Ztx
tjA23upNv7lGKACB6nnGnA5l7DZi1vGmBgFdTnVQcllleZAbKZUqIJLkaVat
E4PgVUX0rhcQ1qhDxpgcEinJJYX6HKcNPzbppzv6zeeIXEF+3J+27jYZOr+4
d/+bYOhVfJa7unJzsrOCfDD1xB39AV6jVSUICitpsmDL7oAWLJkLWSN3xeuR
1FE0xcbIQyrujzOiAP01XNhJ3/l0ev5+en5G4H8RBy9K8XhC+K0+K9wOzZ5q
Rod4YCwxJhFQkkCEA5gB/Tr29eGisxesZsFpiqrhpGHHxknmnY2CbL7r6m0V
YxYlIbEoplw2q90wOtKKAefKJdBSXQ5/jlOtyBtIYgrgrLOG3LmG9Mw7tXdW
vap316+9rSFvn8zvos6WFslrNrfcbiOEzutsy0sjuIBdqq0Rw+e9R6wjJcE5
IZ0+Q6Fy+wy8WzGaeWUkSzcvMruOXmYx5rc5z7E0JW0wD6IkzQbpC/GdOflO
SHKcruYKBcD1NVBCLhIgNWtAMpi7ScptBISgX8ycMQG5Q7XcB45aNYNzSGFt
5Ya1r0Ee2+7Vrr0CGVR3JavKCsRtyLwhO3aevisFsyhdSDZdVWEXfaFIxpqJ
+zmAsS634Zfn5o0mI8NUO7QuFbnUxG2N9+tmN3CkhGtKFJcztmYSFSOfqdo1
k3wKXE8ovqDakIEQsOpqlqHGAoiAbbvYcXZP1tT+Fa4XOBOVX5Af/PnVW84K
ZYUvLsqeTVfLEk0xjMgSZHM3jWSe84zwQBoLzlcLb6qBJwm9Dbnr0JqbWbtc
ci6+rUFRN+qkTreea6DLMIGfLHv4Pp2S5lmTDTU++I/CrhVzHjoEZrsQGfrE
3jsHhTAnvsy0+UcyblJoYccrfTHMB3seBDehiQin8ilhXmM/g4zyMfg02CVX
1W1co7044qwU6yBoj0W/jitF+p45AzWQb3QhZBk65IhJbrjPyQg8xY6zKj75
ERLyN1nRsjAeFc0zAv6Idnuzz5AHEuOl4fIsFiEffpK8KzmJQ1Bwd8lempYk
xGdnj1y10Camo6fD5grNFKNlo8tRkCbjJMUwQUYKS/SY73TQRDCy0LOqaugP
7IWNfSY6tAgAXHC/tgn5Vhi3T8c0lALIPH5Llm2t/WFMVG56O75667SJJq9U
FZA+L30irQvGycFvzIjMYlA7PrlPgShRXv2UgCHs6FuqenThxHcgpAX7rG2j
8WavnsOlDUecsmmEMbjyrzFFkvwoGiyoZg4JvafzGXEfty3Qyrdzepq3HNOo
x8vsALtxyKc47Cz1/XtTB++izr+91b+ghSLngVQreh9SFq6n8+bZ/bMk4QSM
qBK1Agpg1kz/7+7cNyI+/69eHad0WMpQfAUnRYWSnrQPyn34fWtmTvrHIk6Q
lA5KBMecC0H/loFL4yt+uSaqgKeGe0VKsx261FqTbJthURip8VyTqCG7WNAp
8504AFLUE24LnZq9pPsJ1O5PwkAq2shoaCsCewGhXdBHVnMSW3YCYPIYIvOR
XAi0ovnAGqlJK/pyUcGd41VZtbI+lzQlt4vAUHKg2utACSVibdh6+OQMnQDo
tG6QTVJgTkasZkPGIRYY2ZgFhHM0tuwUvfZ+JP1UUfw2UEb8fI974+pF5i2I
tvcMVppErTwACG9LelZOoyeruhjB99JxbihrEAsInEJpDhME7kMJOMnxKomk
LILzHcmZ91LD4gp3GuhS8qxZCsHy+VWnFTqPNTb0Vo7752Em4LuAgeSYe7NC
V23Io/k+5OsTlfc/n6Ib4bundhFEtBcB41c4n21tjkb+DW4KIbE2Bb1EynQm
jBt6RY6eZiUFJ/WzI17dv4jmWtImhJe8qoNGQY8tnnpydnama4YK3Gz3haVO
V+36y0DTj5ac4l339B+AmF6m94h1VLQ6DhoB84gSmJKjZGE1+omQxN5ZVbPe
Ep4szA27Y6bJQL2hISBtOj6c04hW/UY44Nkh0P1vEdKSvbTH+R8gc0BF/L5H
ZX/Nr0frHiz/P0xxaFlp9ubqK+q7v85MA0unS78/jnq8V630eJMmGW+X/L8K
rvkpuTYUw5AJOrvDf+qEyfj+2aMnTx49evzwRKtYJquJP2q4KUv1GriXqrFw
ziWRDDNYox9IWx8/f+Zu8b+yhhBP9IMp7KqquDEqw/jJ5U9aMOZ6jHMVa6pY
8Y4k0a5cepPVltmMY0lDxkByHqQ+Ud02WtnMEln7h+dvr35MZUzjaVd5w2Kd
zwLY2N0LDCuvEaOahTIt/6ZuyPgHXm8a96We+mYnoCIr/jSfkXBwyjXbFVWW
S8rzjgQmXMJ6RoptMvku/h779b7HF1PfyPb9x/QTf5vyAlMyFgf52j9zgE/T
73dhDV0lYrf0+9/0t8+J/LfnxJz33LB9XARU3IaB3okOSO4QvN855BeOeVB8
o6UPnP1rBDS8H/BD/ot3yi+XRjv5wryEVIN7XRa/X33pui8uJl2jEIFFusAc
xYuX0bPnPhHL5s+Pf/i2p5AlkBIG157yrhhbcLsU17k0dC4JmxRJkcMoLlnW
aDmIrXn6b9wYniPWX1huxm3IfdsINAL0XUeHasYc/Vfl3bi9UceKYpT8Tlvh
8fj8yUlyvJdU14g16tubcVQHN8hnQ+GSSpIX6PkNkHOAGmWYq/Ikof+3c810
tM4n6xSpobyvWqjzy+Cu7Wc2QLhKconSsEAetwAt+o1hQoGRa+tEpO0YgI3t
fmWddwj7w9wO3D+doVCUsjN4YLSMUcfFRh4bc6L4ul1CQogDS780bUVetesa
TD3aAz7lwbuOESvpNV4KEfanT//A8w6P7hMJf+uzjFQRyf1F2Kv5JqUNQt3+
bnBAb0jOQalBDkvA1da8rgvnKzNRUQe3i/IS0u9ZI6VVlVF84yvGtla/FV6/
wSRMVPMK0Ubs9H7JFTKb72Pqf2OaZ5uauet3QmDEjd89BbcH56BLuE/P3x89
7ZZ6SlHs0cwu9WPwFrHIxXCRhXl8Np0+efKP2yIrz/bXYTHTL8aIi3vL3fvi
cqZZXfzOag8ePnoMv0Yb2kAgDuoo5AvZVooJX+59xwyy4npy1zrG42Ycs0+T
59qfilmk3GYSTWmDFGYYhP9CBCm5Ya9IUN5fLul00mLIfdiZqM244N5ldgrL
uta39vgmer8mR8c6mjhJtEfiHseYXp9fTJ7AcEDnqkqCrrZzACh9+Wu4EDn5
2rbotY0ccMuWddVu4NhJ6x9tE8ZQotksmSv9FvWAb1VzDZomSRfuk+NQj65k
GLhNN3QQx90akpebq2RPyFUruTWR8Onb51j7dCYj9IdzMMv9jGVvYoAV1CBV
wH4r99dfKom47fijVBPKSIlHoX3oeCKJHyp7X+HUjibwhR8H0EQc20pO8Goi
TtPGPoEep3oTTV+pKoDhY7xQ4H9flZxAjeKTO4B6bHRJnMVjUj9XoOexqNxB
H+f5xeQxDBy/pgkeUmEHm6pcos14flbq2JqJpC8k18vYIGXsOOGMgSt4csQb
mnY5kdHJVBsHjoN0zbkpMfSDieJWtLCRAQaRjQeE3I6qiRcxiASctFGQG49G
c64M6rhP3k/+xMkHPKlOUNxzwsYIPatmTahFIY9jE/aD9iBj67CHLfYvQqoI
nU3lch+AE+mFYQ6rrZMxqXmBPjztTdG+q6rUQOfNtXTyGowotMtVsdPGMesr
43rmTAeW+1NQOrs0YIyoniQZ57jRdASMsgn1LcTSmBa6KifMjdEg9aAfSLsF
CFfeMbAuKZWRZKA36lHsZTNDJqfkdFz3VHB50An1NFlqEKkK5csOmU7g+Imq
SvuQtN4zCmCFIiu4Fm7TVW/EUqYFeDRVC89od80iMQxhbkdB3zkXjEKi+bgy
jMJFibk9P86fYSJT7FHjZDR0iBNpBlFmvvDNWKSNO4DN2k9qsb7zpQnoclu7
QKiZzMGyy6I2KatrMBa32voJDf8+SLPekEfMKg6lJbtmW4py023ODhwBya5r
/28vtBpKFfJCUIC3ez8e9b0yQKxHsUQoBvwBcPzCUacD3n7F6DfT9Ow2uKKn
DgXI9+XrY0HjRoLiEx7379KWFEiOOvZR1Y9A4YD612xwYJuDtRc66GJx9mA6
XeQHkT3o50iPB11k6NxA/9jJQUJIso3wfHSWnp9fHB2sgOyveXHbmgUyNF9e
tN2w1iAduGGzE0rVHa6QWm66my40FxwVSVjSp19Fy/PbaLnf6kLouhUpw4Re
32cffWnVi/e3o4WXratDy5LTDY/6FduptuQeYrIxXAyJ56pDa7/rzznGBQf2
PA/c7cEdnVYywaZY+LEXqdKG7uGykuY76Y5nx1HH6vycIw9Zi9fmuRvNLXDq
0Y3iWxmW2YZCWXJxY4NR7Lqe65ztO1e7oHcxmJD7McuZyWp1x6z7AA7ScTaY
aNNIK20YzGWpDJ37MuvSYSNuUmt4z2h2Kyql6mKsayfIDJCDYZd+3mokFmpA
oSGW4fcHR0bdcziytP/Gcalaw2Lir8ppoxOw11/3Cq2pktvgdoAJsdxbcVUb
s0T5UZqhLVsW+ItrwElo6rqkNTHU5YQgflLG9wXCjqLEoGBrHRMqZbxzziv6
hLVu4hiDYnnjZvzBFJbOqLj0/KEvWkl9HRUqLVuFZ5pVbcwBgPlZ335j5J6N
HZ3zg5EGrQyr8zeKJUaT+R1kMta6kIDHrsgUPRjPs82zPSi6VvYD/tDkawn6
1prxX2qTfbidnlIrJRGUHAVm5gCmdMGWes1J5wPPuisdoBDZE+DK5LYSkeJe
ul7KkVuXdCEWZJM/xS1QREduHCPVyW+8vLyK+t8x2UgIJ/sggDrpJVuiRkDC
lFtu5Pi/4p8O+r/E/1Bvjrzj5Pfxza1BK4zQwCKnhboLXqLoRjCrdifp6Gjo
pe8exWi/83Mpeo2R/9UPQchyAFPHjIeQskaOSI4O3ZSHMX3HLk+k8UOor3D/
lTauM090ANtw4RTUc//g0Pd62cHQLjDVpObO3YhQw5K46O2TlQKgzg97gelI
uuTeCW30DIr0ruvOE94jQv/+ex4DPKNfh/iTrRYtABG6lCF0zJyVFLg5uYqo
0x/c5a8di3So3k5oKvDhR3iFcYFAMJPkAyyc+BhOdhUZyxasEXGEzIfq/OsM
Im5qpQb4QidbcfRbNYKclo27SzeW+wxF5JC/SmW2WHc0YYIbWseyxV+EOy28
AookGPx3GS482mPB7pYNEYmIx6FNPGO6MN2MWCIFR9suwOI0Vcw1wslw+Zpq
4/YkESAGaeTlQgoAdsGWrZgmTiWFRLdPBKfcKV2bhQwb7njitqciqn7DWxjq
Tv1ICbfOEt2XSx3tOTDk6vyssvTz8C5vrk+8yNhS7m3YRykvPjOpv+XPK+EV
jBjHtUEn8mS8W7VNTijBwXba+rWx9U58ZwL8RgYP1RVTzT2860LZBxnNSMFy
3RRKHsNeMwOnhHsrdeoK4SgqV2u5fujbNLoJJyLu0KJBNBYYveqfBgC6jZHG
dhYLZGLl6hnaBsVjOeMxHLB1q3cLmI/zghTuDa69IuOFsXV67NtUZ3pCg5jn
nOOYtieBkY7diVzuJkWPAWx5p/LgwbMB1s7RJvvg/Zhwc0LkGmZMuCHd9Mqh
ahMz9ySGW9OYnS8qlaE4LaOM8WVgGdZu4MpPif3RiqVSdo+IfOidNYWogD0h
ZoqaTGfUOmoKFfXCLem67JNJRWNQI5Iw+oCiIAqErrZKWh6z9OrtRF2KrqVR
laN0YAG7fK8NuElur1BZxoCheEta+a0W+0Ny3imFZPlVuMHuUIELVw/oNY2N
6ZEvvsqPG5391V98u8G2DBcIVf7iEbh06C3mqzCIyWjtX7jWgBsCZZBQpqNw
zHWHGq8nBD3z0PYqt0+wpsZwK7PruM+sjPNlnc0xbCMtZFxhJUYgXcWpJb6N
C1XowmAC9dv0F/L9pUd7uNX+BqTFIk+PTv+bqeGGahtiFi5QjI5B6GcjyYYZ
inYjBr7cRbONuc+kMQu7gIs9kZHyX48JD2cxkd+RRCW36nPHXUBdpzlPPLse
En6+IBWYE+Alt9y08V1tfjwFR5TurG0ldlQtcX+w0DPjlgPUuz5Yi6dc2Otm
7Ji5lbs8w0UO8KzElxgi6qDu+lpMhVLLIXTz7YxZbufaGuhvw6y1RSnvmmHp
Z1wLi5T6IYOpjY9yaddAaZyKTGYF+wmXhatGUQc3nV61VJjUZ5023ELFCuIK
LU0YijwSLlSteTqpbca00FjmeurmmfpnsF8K/EFUhduHkOrdSKVAvJS4JVc4
Lh6Aq7R8wBUIzoJ0muULR2hSva4hJEdCktp8XGWkyKCfKSLJdLS46/N3XFr3
NLU1tDTfudo1w6NsScwqGsJX13OzyNj9Rk5ZPZS9vBR7JU7DlkmyD736d77n
w3sx6uhH6/FsTdSNkWgdINzYpVHAGuAtMrey8T1ZrIsim8v3BWXcCN/h52my
bCls5VmsSsaKNQslCm9oBlWF+3yZHiW6e3M4w3PnTnrZnYjV6V9R4yU+KVG1
81PUX9WiJ5Hdym6CB0TiON7UtuKxrL28YeobN7jnGe/8vbIDh5sTbaHIPCMR
W/DicDX7NxqucfoDNRX494seWtjpQQ3cSsMSD5P3aqF4OpS9DubPuo382B/p
a1elS8GekQQEJwlCvZ7U4PxDd+FYhprogkyy667r8QPxxIi0YDyVuFCi8xrQ
sh4AfDko0UGV/QdS8kSjyd+/mUwm/3HSRbhRtUnwwjDfPXAm39cwSVgTBV6X
MjnmV6SKVu/ia1V5ADaTS41uLLkp7AYo8mGAAahe2pKkOjVQIUMU7sU95MgL
EdVIlZV33fa4HoSAVvC3reqlJa2Tmx65xqHv+gsM3YlmhbqpTWYoDu3CBTOp
vzWJyMaMGvMUaeL5B9S4Se9INN5Vx9kVqjVPAH+JorPRgLzQYdz2ZQgeslUd
MZzerQ3CI/1+JcF6US3JHbOQnPHZfc7avrRc+cz/TspDLndnN/8lupcIR3L1
Kl/rjeul5fJnHbPIK729o5s/xKsU/0dT7eWXhrrk4Tdy9VpZST5MctfxlceO
Xpf6qdy1OGV9G89JiHOn94yHFszoGkWWXb0cWHZ9zbVbaYATT6jWym03WRta
zPwBu3uKZJpZ3pqrttToaO+Y0/QtXBuS76u3TnRvVDLgTTRN17ITKuvw/Vz8
YFULGpUBQ8/hoKtm0tH13lQkTzR3eE9ew60Wx6/jG0uu5caSk26Bi2iBcKO8
/yIa3IpbnAk3t03SoE1NejP9JufRJs5fJ7gvwa5748y/EekcIUzr0BS+QchW
l/SMvzYisOEUHV0znNYP5/grQzlLpiP43eVAXj1/G6/g7wbTBhcuy2uoysLB
ll6cjsD+KzL9puwvdO1f4vCKc5f7V07rrb9yoXYcjOImZy6kQ6wv5/AKC5Mv
JcnBM9FvDBSo9EhO03/OECL+M/2nNL9h7Pl/AFU4kOjDYgAA

-->

</rfc>
