<?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.dtd" [
]>

<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc subcompact="no"?>
<?rfc iprnotified="no"?>
<?rfc toc="yes"?>

<rfc ipr="trust200902" docName="draft-amsuess-core-rd-replication-02" category="info">

  <front>
    <title>Resource Directory Replication</title>

    <author initials="C." surname="Amsüss" fullname="Christian Amsüss">
      <organization></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="2019" month="March" day="11"/>

    <area>Internet</area>
    <workgroup>CoRE</workgroup>
    <keyword>CoRE, Web Linking, Resource Directory, Federation, Replication</keyword>

    <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.</t>

<t>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>

  <middle>


<section anchor="introduction" title="Introduction">

<t>[ See abstract for now. ]</t>

<t>This document is being developed in a git based workflow.
Please see <eref target="https://github.com/chrysn/resource-directory-replication">https://github.com/chrysn/resource-directory-replication</eref>
for more details and easy ways to contribute.</t>

</section>
<section anchor="terminology" title="Terminology">

<t>This document assumes familiarity with <xref target="RFC7252"/> and <xref target="I-D.ietf-core-resource-directory"/>
and uses terminology from those documents.</t>

<t>Examples in which URI paths like <spanx style="verb">/rd</spanx> or <spanx style="verb">/rd-lookup/res</spanx> are used
assume that those URIs have been obtained before by an RD Discovery process;
these paths are only examples, and no implementation should make assumptions based on the literal paths.</t>

</section>
<section anchor="goals-of-upscaling" title="Goals of upscaling">

<t>The following sections outline different reasons why a Resource Directory should be scaled beyond a singe device.
Not all of them will necessarily apply to all use cases, and not all solution approaches might be suitable for all goals.</t>

<section anchor="large-numbers-of-registrations" title="Large numbers of registrations">

<t>Even at 1kB of link data per registration,
modern server hardware can easily keep the data of millions of registrations in RAM simultaneously.
Thus, the mere size of registration data is not expected to be a factor that requires scaling to multiple nodes.</t>

<t>The traffic produced when millions of nodes with the default 24h lifetime amounts to dozens of exchanges per second,
which is doable with equal ease at central network equipment.</t>

<t>However, if the directory has additional interaction with its registered nodes,
for example because it provides proxying to registered endpoints,
resources like file descriptors can be exhausted earlier,
and the traffic load on the registration server grows with the traffic it is proxying for the endpoint.</t>

</section>
<section anchor="large-number-of-requests" title="Large number of requests">

<t>Not all approaches to constrained restful communication use the Resource Directory only in the setup stage;
some are might also utilize a Resource Directory in more day-to-day operation.</t>

<t>[ TODO: get some numbers on how many requests a single RD can deal with. ]</t>

</section>
<section anchor="redundancy" title="Redundancy">

<t>With the RD as a central part of CoRE infrastructures, outages can affect a large number of users.</t>

<t>A decentralized RD should be able to deal both with scheduled downtimes of hosts
as well as unexpected outages of hosts or parts of the network,
especially with network splits between the individual parts of the directory.</t>

</section>
</section>
<section anchor="approaches" title="Approaches">

<t>In this section, two independent chains of approaches are presented.
The “shared authority” approach
  (using anycast or DNS aliases),
and proxy-based caching
  (in stages from using generic proxies to RD replication that only bears little resemblance to proxies).</t>

<t>In the remainder of this document,
the term “proxy” always refers to a device
which a client can access as if it were a resource directory,
and forwards the request to an actual RD.</t>

<t>Elements from those chains can be mixed.</t>

<section anchor="shared-authority" title="Shared authority">

<t>With this approach, a single host and port
(or “authority” component in the generic URI syntax)
is used for all interactions with the RD.</t>

<t>This can be implemented using a host name pointing to different IP addresses
simultaneously or depending on the requester’s location,
using IP anycast addresses
or both.</t>

<t>From the client’s or proxy’s point of view,
all interaction happens with same Origin Server.</t>

<t>In this setup, the replication is hidden from the REST interactions,
and takes place inside the RD server implementation or its database backend.</t>

<t>Compared to the other approaches, this is more complex to set up
when it involves managing anycast addresses:
Running an IPv4 anycast network on Internet scale requires running an Autonomous System.
In either variation, all server instances are tightly coupled;
they need shared administration
and probably need to run the same software.</t>

<t>The replication characteristics are laregly inherited from the underlying backend.</t>

<t>As registering endpoints only store the URI constructed from the Location-Path option to their registration request,
registration updates can end up at any instance of the server,
though they are likely to reach the same one as before most of the time.</t>

<t>Spontaneous failure of individual nodes can interrupt endpoints’ registrations in scenarious that do not use anycast addresses until the unusable addresses have left DNS caches.</t>

</section>
<section anchor="plain-caching" title="Plain caching">

<t>Caching reverse proxies that are not particularly aware of a Resource Directory can be used to mitigate the effect of large numbers of requests on a single RD server.
In this approach, there exists a single central RD server instance, but proxies are placed in front of it to reduce its load.</t>

<t>Caching is applicable only to the lookup interfaces; the POST request used in registration and renewal are not cacheable.</t>

<t>A prerequisite for successful caching is that fresh copies exist in the cache;
this is likely to happen only if there are many alike requests to the Resource Directory.
The proxy can than serve cached copies, and might find it advantageous to observe frequent queries.</t>

<t>The simplest way to set up such proxying is to have the proxies forward all requests to the central RD
and to advertise only the proxies’ addresses.</t>

<t>Due to the discovery process of the RD, operators can also limit the proxies to the lookup interfaces
and advertise the central server for registration purposes.
A sample exchange between a node and its 6LoWPAN border router could be:</t>

<figure><artwork><![CDATA[
Req: GET coap://[fe80::1]/.well-known/core?rt=core.rd*

Res: 2.05 Content
<coap://central-rd.example.com/rd>;rt="core.rd",
<coap://europe3.proxy.rd.example.com/rd-lookup/res>;rt="core.rd-lookup-res",
<coap://europe3.proxy.rd.example.com/rd-lookup/ep>;rt="core.rd-lookup-ep"
]]></artwork></figure>

<t>Special care should be taken when a reverse proxy is not accessed by the client under the same address as the origin server,
as relative references change their meaning when served from there.
This can be ignored completely on the resource lookup interface
(as long as the provenance extension is not used);
ignoring it on the endpoint lookup interface gives the client “wrong” results,
though that is likely to only matter to applications that use both the lookup
and the registration interface, like Commissioning Tools could do.
Proxies can be configured to do content transcoding
(cf. <xref target="RFC8075"/> Section 6.5.2)
to preserve the lookup responses’ original meanings.</t>

<t>This approach does not help at all with large numbers of registrations.
It can mitigate issues with large numbers of lookup requests, provided that many identical requests arrive at the proxy.
The effect on the redundancy goal is negligible:
The proxy can provide lookup results only for as long as the cache is fresh during a central server outage,
which is 60 seconds unless the RD server says otherwise.</t>

<t>This approach can be run with off-the-shelf RD servers and proxies.
The only configuration required is for the proxy to have a forwarding address,
and for the RD (or its announcer) tho know which lookup addresses to advertise.</t>

</section>
<section anchor="rd-aware-caching" title="RD-aware caching">

<t>Similar to the above, specialized proxies can be employed that are aware that their target is an RD lookup address.</t>

<t>The “plain caching” approach is limited in that it requires a small set of lookups to be frequently performed.
A proxy that is aware that the address it is forwarding to is of the Resource Type “core.rd-lookup-*”
can utilize knowledge of how an RD works to serve more specialized requests as well from fresh generic content.</t>

<t>For example, assume that the proxy frequently receives requests of the shape</t>

<figure><artwork><![CDATA[
Req: GET /rd-lookup/res?rt=core.s&rt=ex.temperature&ex.building=8341&title=X
]]></artwork></figure>

<t>for arbitrary values of X. Then it can use the following request to keep a fresh cache:</t>

<figure><artwork><![CDATA[
Req: GET coap://rd.example.com/rd-lookup/res?rt=core.s&rt=ex.temperature
    &ex.building=8341
Observe: 1
]]></artwork></figure>

<t>and from that serve filtered responses to individual requests.</t>

<t>This method shares the advantages of plain caching,
with reduced limitations but requiring specialized proxying software.
The software does not necessarily need more configuration:
A general-purpose proxy is free to explore the origin server’s <spanx style="verb">.well-known/core</spanx> information,
and can decide to enable RD optimizations after discovering that the frequently accesses resources
are of resource type “core.rd-lookup-*”.</t>

<section anchor="potential-for-improvement" title="Potential for improvement">

<t>Observing a large lookup result is relatively inefficient
as the complete document needs to be transferred when a change happens.
Serializations of web links that are suitable for expressing small deltas are expected to be developed
for PATCH operations on registration resources.
If those formats are compatible with observation, they can be applied directly.
Otherwise, the proxy can try to establish a “push” dynamic link (<xref target="I-D.ietf-core-dynlink"/>)
to receive continuous PATCH updates on its resource.</t>

<t>The applicability of the RD-aware approach is further limited to query parameters
of which the proxy knows that they are not subject to lookup filtering on other entities than the queried one.
In the example above, were the variable part the <spanx style="verb">d</spanx> attribute (of endpoints, as opposed to the <spanx style="verb">title</spanx> of resources),
the proxy could not do the filtering on its own becaus it would not have the required information.
Even the above example does not allow for fully accurate replication, as the endpoint <spanx style="emph">might</spanx> register
with a <spanx style="verb">title</spanx> endpoint attribute, even though no such attribute is specified right now.
Also, annotating the links in the endpoint lookup with information about which registration they belong to
would help the proxy keep all the data around to solve more complex queries.
The provenance extension is proposed for that purpose.</t>

<t>In its extreme form, the proxy can observe the complete endpoint lookup resource of the Resource Directory.
and run a dedicated observation for each registration.
It can then answer all queries on its own based on the continuously fresh state transferred in the observations.</t>

<t>For such proxies, it can be suitable to configure them to use stale cache values
for extended periods of time when the RD becomes intermittently unavailable.</t>

</section>
</section>
<section anchor="distinct-registration-points" title="Distinct registration points">

<t>Caching proxies that are aware of RD semantics could be extended
to gather information from more than one Resource Directory.</t>

<t>When executing queries,
they would consider candidates from all configured upstream servers
and report the union of the respective query results.
At this stage, it is highly recommended that content transcoding takes place.</t>

<t>With this approach, many distinct registration URIs can be advertised,
for example due to geographic proximity.</t>

<t>Unlike the other proxying approaches,
this helps with the “large number of registrations” goal.
If that number is unmanageable for single devices,
proxies need not keep full copies of all the RDs’ states
but rather send out queries to all of their upstreams,
behaving more like the “plain caching” proxies.
This multiplies the lookup traffic,
but allows for huge numbers of registrations.
The problems of “too many lookups” versus “too many registrations”
can be traded off against each other
if the proxies keep parts of the RDs’ states locally at hand
while forwarding more exotic requests to all RDs.</t>

<section anchor="redundancy-and-handover" title="Redundancy and handover">

<t>This approach also tackles the redundancy goal.
When an endpoint registeres at its RD,
the RD updates its endpoint and resource lookup results
and includes the registration data until further notice
(for correct operation, the “Lifetime Age” extension is useful).</t>

<t>If at some point in time that RD server becomes unavailable,
the proxies can keep the cached information around.
Before the lifetime expires,
the endpoint will attempt to renew its registration
and find that the RD is unavailable.
It will then go through discovery again,
find the most recently advertised registration URI
or pick another one out of a set
and start a new registration there.</t>

<t>If the lookup proxies do not evict the old (and soon-to-time-out) registration
when the new one on a different RD with the same endpoint name and domain arrives,
at worst there will be the same information twice from two registration resources
available for lookup.</t>

</section>
<section anchor="loops-between-rds-and-proxies" title="Loops between RDs and proxies">

<t>In this configuration, it can be tempting to run a Resource Directory
and a lookup proxy (aimed at multiple resource directories)
on the same host.</t>

<t>[ It might be easier to recommend simply using different hosts, at least host names, in those cases,
or anything else that allows direct and not publically advertised access to the real RDs’ lookups. ]</t>

<t>In such a setup, other aggregating lookup proxies must take care
to only select locally registered entries.
With the current filtering rules,
observing the resources
<spanx style="verb">/rd-lookup/ep?href=/*</spanx>
and
<spanx style="verb">/rd-lookup/res?provenance=/*</spanx>
crudely provides that kind of filtering.</t>

</section>
</section>
</section>
<section anchor="proposed-rd-extensions" title="Proposed RD extensions">

<section anchor="provenance" title="Provenance">

<t>In order for an RD-aware proxy to serve resource lookup requests that filter on endpoint parameters,
the proxy needs a way to tell which endpoint registration submitted that link.
That information might also be useful for other purposes.</t>

<t>This introduces a new link attribute “provenance”.
Its value is a URI reference as described by <xref target="RFC3986"/> Section 4.1.
The URI is to be interpreted by the same rules that apply to the “anchor” attribute,
namely by resolving the reference relative to the requested document’s URI.
The attribute should not be repeated,
and in presence of multiple attributes, only the last should be considered.</t>

<t>[ TODO: If a something link-format-ish comes up during the development of this document
which allows setting base-hrefs in-line, evaluate whether it really makes sense to
inherit anchor’s rules or whether it’s better to phrase it in a way that
the requested base URI always counts.
A composite CoRAL endpoint-and-resource lookup on the RD might make this extension proposal obsolete.
]</t>

<t>The URI given in the “provenance” attribute describes
where the information in the link was obtained from.
An aggregator of links can thus declare its sources for each link.</t>

<t>It is recommended that a Resource Directory adds the URI of the registration resource
to resource lookups. Thus, if an endpoint registers as</t>

<figure><artwork><![CDATA[
Req: POST /rd?ep=node1
Payload:
</sensors/temp>;if="core.s"

Res: 2.01 Created
Location: /reg/1234
]]></artwork></figure>

<t>then a lookup will add a provenance attribute:</t>

<figure><artwork><![CDATA[
Req: GET /rd-lookup/res?if=core.s

Res: 2.05 Content
Payload:
<coap://.../sensors/temp>;if="core.s";anchor="coap://...";
    provenance="/reg/1234"
]]></artwork></figure>

<t>This is not an IANA consideration as there is no established registry
of link attributes.</t>

<t>By itself, the provenance attribute does not need to be registered in the RD Parameters Registry
because it is just another link attribute.
If it is desired that provenance information is only shown on request
(eg. by RD-aware proxies),
a parameter can be introduced there:</t>

<t><list style="symbols">
  <t>Full name: Link provenance</t>
  <t>short: provenance</t>
  <t>Validity: URI</t>
  <t>Use: Resource lookup only</t>
  <t>Description: If <spanx style="verb">provenance</spanx> or any string starting with <spanx style="verb">provenance=</spanx> is given
as one of the ampersand-delimited query arguments,
the RD is instructed to add the provenance attribute to all looked up links;
otherwise, the RD will not present them.
The filtering rules still apply:
If there is a <spanx style="verb">=</spanx> sign in the query argument,
only links with matching provenance will be reported.</t>
</list></t>

</section>
<section anchor="lifetime-reporting" title="Lifetime reporting">

<t>The result of an endpoint lookup as a whole has inhomogenous cache properties
that would determine its Max-Age:</t>

<t><list style="symbols">
  <t>The document can change at any time when a new endpoint registers.</t>
  <t>The document can change at any time when an endpoint deregisters.</t>
  <t>Each record can be expected to not change until its lifetime has expired.</t>
</list></t>

<t>As currently specified, a lookup client has no way to tell where in its lifetime an endpoint is.
Therefore, a new link attribute is suggested that allows the RD to share that information:</t>

<t>The new link attribute Lifetime Remaining (lt-remaining) is described for use in RD Endpoint Lookups.
Valid values are integers from 0 to the lifetime of the registration.
The value indicates how many seconds have passed since the endpoint last renewed its registration.</t>

<t>Care has to be taken when replicating this value in caches,
as the caching agent might be unaware of the attribute’s semantics and not update it.
(This is unlike the Max-Age attribute,
which a caching agent needs to understand and reduce accordingly when serving from the cache).
It should therefore only be used with responses that carry the default Max-Age of 60 or less.</t>

<t>Clients that use the lookup interface
(especially RD-aware proxies)
are free to treat that record and its corresponding resource records as fresh
until after lt-remaining seconds have passed
since the endpoint lookup result was obtained,
especially if the origin server has become unavailable.</t>

<t>Security considerations:
Given that this leaks information about the endpoint’s communication patterns,
it may be prudent for an RD only to reveal this information on a need-to-know basis.</t>

</section>
</section>
<section anchor="example-scenarios" title="Example scenarios">

<section anchor="redundant-and-replicated-resource-lookup-anycast" title="Redundant and replicated resource lookup (anycast)">

<t>This scenario describes a setup where millions of devices register
in a company-wide Resource Directory.</t>

<t>The directory is scaled using the shared authority / anycast approach,
and the RD implementation is backed by a NoSQL-style distributed database.</t>

<figure><artwork><![CDATA[
        /'''''''\______/'''''\__/''''''''\
     /-                                   -\
     |,           NoSQL database           |
       \,,,                           ,~''
           \_____/'''\__________/''''   \
        /             |                  \
  /''''''\        /''''''\                 /''''''\
  | RD-A |        | RD-B |                 | RD-C |
  \______/        \______/                 \______/
 /  |  | \        / | | | \                  | | |
E   E  C  E       E E E E C                  C C C
]]></artwork></figure>

<t>(<spanx style="verb">E</spanx> and <spanx style="verb">C</spanx> represent endpoints and lookup clients, respectively)</t>

<t>Both endloints and lookup clients receive the RD address <spanx style="verb">2001:db8::an1:ca57</spanx> is announced
to all devices on the network using the RDAO option in IPv6 Neighbor Discovery.
Any packages to that addresses are routed by the network
to the closest of the three RD instances A, B and C.
Discovery invariably looks like this:</t>

<figure><artwork><![CDATA[
Req: GET coap://[2001:db8::an1:ca57/.well-known/core?rt=core.rd*

Res: 2.05 Content
</rd>;rt="core.rd",
</rd-lookup/res>;rt="core.rd-lookup-res",
</rd-lookup/ep>;rt="core.rd-lookup-ep"
]]></artwork></figure>

<t>An endpoint close to B would therefore register with</t>

<figure><artwork><![CDATA[
Req: POST coap://[2001:db8::an1:ca57]/rd?ep=endpoint1&
    d=facility23.eu.example.com
Payload:
</sensors/temp>;if="core.s"

Res: 2.01 Created
Location: /reg/123e4567-e89b-12d3-a456-426655440000
]]></artwork></figure>

<t>Any client could immediately see that the endpoint is registered by issuing</t>

<figure><artwork><![CDATA[
Req: GET coap://[2001:db8::an1:ca57]/rd-lookup/ep?ep=endpoint1&
    d=facility23.eu.example.com

Res: 2.05 Content
Payload:
</reg/123e4567-e89b-12d3-a456-426655440000>;ep="endpoint1";
    d="facility23.eu.example.com";con="coap://[2001:db8:23::1]"
]]></artwork></figure>

<t>If at any point in time the RD instance B becomes unavailable,
the registering endpoint’s renewal requests will be routed
to the next available instance, for example A.
That instance can update the shared database with renewed lifetime
just as B would have done.</t>

<t>How this performs under a net split depends on the database backend.
Registration resources based on UUIDs were chosen in this example
because those would allow the system to keep accepting new registrations
even in a netsplit situation;
the risk of the registration request not being idempotent
towards a node that switches sides during such a split is considered acceptable.</t>

</section>
<section anchor="redundant-and-replicated-resource-lookup-distinct-registration-points" title="Redundant and replicated resource lookup (distinct registration points)">

<t>This scenario takes place in the same environment as the previous one.</t>

<t>Rather than a shared database, distinct registration points are advertised.
The advertised registration points are called RD-A to RD-C;
independent of them are lookup proxies LP-X to LP-Z.
Some of them run on the same hosts.</t>

<figure><artwork><![CDATA[
        /'''''''\______/'''''\__/''''''''\
     /-                                   -\
     |,                                    |
       \,,,                           ,~''
           \_____/'''\__________/''''   \
            |               |            \
  /''''''\  |     /''''''\  |  /''''''\   |  /''''''\
  | RD-A |--+     | RD-B |--+--| RD-C |   +--| LP-Z |
  | LP-X |  |     | LP-Y |  |  |      |   |  |      |
  \_____1/  |     \_____2/  |  \____3/    |  \_____4/
            |               |             |
      +--+--+            +--+--+          +--+
      E  E  C            E  E  E          C  C
]]></artwork></figure>

<t>The lookup proxies in this scenario are constantly observing
the <spanx style="verb">/rd-lookup/ep?href=/*</spanx> and <spanx style="verb">/rd-lookup/res?provenance=/*</spanx> resources
of known RDs on other hosts,
and might get updated internally with state from a co-hosted RD
or observe that using an internal interface.
As there is no really suitable content format and observation mechanism for those yet,
the exchanges are partially described in words here.</t>

<t>RDAO announcements point to the nearest host
(whose IP address ends with the numbers of the respective box in the figure),
and hosts that do not serve both functions provide lookup as follows:</t>

<figure><artwork><![CDATA[
Req: GET coap://[2001:db8:23::3]/.well-known/core?rt=core.rd*

Res: 2.05 Content
Payload:
</rd>;rt="core.rd",
<coap://[2001:db8:23::2]/rd-lookup/ep>;rt="core.rd-lookup-ep",
<coap://[2001:db8:23::2]/rd-lookup/res>;rt="core.rd-lookup-res"
]]></artwork></figure>

<t>When a client then registers as</t>

<figure><artwork><![CDATA[
Req: POST coap://[2001:db8:23::3]/rd?ep=endpoint1&
    d=facility23.eu.example.com
Payload:
</sensors/temp>;if="core.s"

Res: 2.01 Created
Location: /reg/42
]]></artwork></figure>

<t>the RD at 3 sends notifications to the observing lookup proxies X, Y and Z:</t>

<figure><artwork><![CDATA[
Res: Patch Result
Add one record: </reg/42>;ep="endpoint1";d="facility23.eu.example.com";
    con="coap://[2001:db8:23::1]";lt-remaining=90000
]]></artwork></figure>

<t>As soon as that is processed, clients can query LP-Z</t>

<figure><artwork><![CDATA[
Req: GET coap://[2001:db8:4::4]/rd-lookup/ep?ep=endpoint1&
    d=facility23.eu.example.com

Res: 2.05 Content
Payload:
<coap://[2001:db8:23::3]/reg/42>;ep="endpoint1";
    d="facility23.eu.example.com";con="coap://[2001:db8:23::1]"
]]></artwork></figure>

<t>(Note that lt-remaining is elided to the client
as per the security considerations for that information).</t>

<t>When a net split happens that cuts LP-Z’s site off the rest,
it keeps that information available until the lt-remaining runs out.</t>

<t>When RD-C unexpectedly becomes unavailable,
endpoint1 fails to renew its registration.
It then starts the RD discovery process again,
picks the next available RD (this time B)
and gets a new registration from that.</t>

<t>RD-B then sends an update to the proxies:</t>

<figure><artwork><![CDATA[
Res: Patch Result
Add one record: </reg/11>;ep="endpoint1";d="facility23.eu.example.com";
    con="coap://[2001:db8:23::1]";lt-remaining=90000
]]></artwork></figure>

<t>The proxies remove C’s registration <spanx style="verb">/reg/42</spanx> based on the duplicate name
and now answer requests like this:</t>

<figure><artwork><![CDATA[
Req: GET /rd-lookup/ep?ep=endpoint1&d=facility23.eu.example.com

Res: 2.05 Content
Payload:
<coap://[2001:db8:23::2]/reg/11>;ep="endpoint1";
    d="facility23.eu.example.com";con="coap://[2001:db8:23::1]"

Req: GET /rd-lookup/res?if=core.s&d=facility23.eu.example.com

Res: 2.05 Content
Payload:
<coap://[2001:db8:23::1]/sensors/temp>;if="core.s";
    anchor="coap://[2001:db8:23::1]/sensors/temp";
    provenance="coap://[2001:db8:23:2]/reg/11",
...
]]></artwork></figure>

<section anchor="variation-large-number-of-registrations-localized-queries" title="Variation: Large number of registrations, localized queries">

<t>If the lookup proxies are not capable of keeping track of all the registered data,
they can opt to forward requests to all the RDs instead.
In this example, queries are often localized
(queries within a building are often limited to the same building),
so LP-Y could decide to only keep two particular observations active to each RD:</t>

<t><list style="symbols">
  <t><spanx style="verb">/rd-lookup/ep?href=/*&amp;d=facility23.eu.example.com</spanx></t>
  <t><spanx style="verb">/rd-lookup/res?provenance=/*&amp;d=facility23.eu.example.com</spanx></t>
</list></t>

<t>With those observed, it could still accurately respond to the above queries
without calling out to the other RDs.</t>

<t>If a query came in as <spanx style="verb">/rd-lookup/res?if=core.s</spanx>,
it would still need to forward that query to all RDs to build an overview of all sensors in the network for the requester.</t>

</section>
<section anchor="variation-combination-with-anycast" title="Variation: Combination with anycast">

<t>In a variation of this, all the RDs and LPs can use a shared anycast address.
They would be then advertised as in the anycast/NoSQL example.</t>

<t>All RDs would need to be configured such that
they encode their host name in their path
(eg. <spanx style="verb">/reg/rd-c/42</spanx>).
Nodes must then have proxy forwarding rules set up such that</t>

<t><list style="symbols">
  <t><spanx style="verb">/rd</spanx> is served from the local RD if there is one,
or forwarded to any (the closest) RD</t>
  <t><spanx style="verb">/reg/*</spanx> requests are served if hosted locally, otherwise forwarded to the appropriate RD,
or respond with a 5.04 Gateway timeout if that is not available any more</t>
  <t>Lookup request are served from the local lookup proxy,
or forwarded to the closest one on RD-only hosts.</t>
</list></t>

<t>Such a setup is easier if all hosts provide both registration and lookup functionality.</t>

</section>
</section>
<section anchor="anonymous-global-endpoint-lookup" title="Anonymous global endpoint lookup">

<t>This scenario describes a way to provide connectivity into devices in difficult network situations
based on identifiers of their cryptographic keys,
in this case the (sufficently long) ID context plus recipient ID of OSCORE (<xref target="I-D.ietf-core-object-security"/>).
A global network of untrusted Resource Directory servers is built,
and the individual servers provide network relaying services for endpoints that operate behind NAT or firewalls.</t>

<t>It assumes the existance of two other hypothetical mechanisms:</t>

<t><list style="symbols">
  <t>The “proxy” parameter from <xref target="I-D.amsuess-core-resource-directory-extensions"/></t>
  <t>A URI scheme called “oscore”.  <vspace blankLines='1'/>
A URI of the form <spanx style="verb">oscore://VGhh...2aWNl/sensor/temp</spanx> refers to
  a resource <spanx style="verb">/sensor/temp/</spanx> on any OSCORE capable host
  with which the client has a key established under the KID context and recipient ID
  given by the base64 string in the authority component.  <vspace blankLines='1'/>
To resolve the URI to a concrete protocol and socket,
  a form of
  Resource Directory assisted protocol negotiation is used.</t>
</list></t>

<t>RD servers join a global pool of servers using a protocol that is not further described here,
but could conceivably be based on distributed hash tables (DHTs).</t>

<t>Endpoints register only with a key derived name,
and usually do not provide any links
because those would be accessible only to authenticated requesters.</t>

<t>They register at any of a set of preconfigured DNS names
for finding a Resource Directory.
Those names resolve to any of the currently active RD servers,
where geographic proximity could play a role in the choice of address returned.</t>

<t>When the endpoint discovers the registration URI
(for which it uses coap+tcp to make later proxying more stable),
the server returns links to its explicit IP address:</t>

<figure><artwork><![CDATA[
<coap+tcp://[2001:db8:1:2::3]/rd>;rt="core.rd",
<coap+tcp://[2001:db8:1:2::3]/rd-lookup/ep>;rt="core.rd-lookup-ep"
]]></artwork></figure>

<t>(This avoids conflict when the DNS assignment flips
and a different host (on which the registration resource is unknown) is returned.
Alternatively, the servers could use a unified scheme of registration resource naming
like <spanx style="verb">/reg/${name}</spanx> or a UUID-based scheme.)</t>

<t>The endpoint then registers:</t>

<figure><artwork><![CDATA[
Req: POST coap+tcp://[2001:db8:1:2::3]/rd?proxy&ep=VGhhdCdzIHRoZSB\
    LZXlJZENvbnRleHQgdXNlZCB3aXRoIHRoaXMgZGV2aWNl
Payload: empty

Res: 2.01 Created
Location: /reg/123
]]></artwork></figure>

<t>When a client wants to talk to that registered server,
its RD discovery process will yield another instance,
which it then queries:</t>

<figure><artwork><![CDATA[
Req: GET coap://[2001:db8:4:5::6]/rd-lookup/ep?ep=VGhhdCdzIHRoZSBL\
    ZXlJZENvbnRleHQgdXNlZCB3aXRoIHRoaXMgZGV2aWNl
]]></artwork></figure>

<t>The server will look up the given ep name in the backing DHT,
and forward the request right to the (precisely: any) RD server that has announced that ep value,
which then answers:</t>

<figure><artwork><![CDATA[
Res: 2.05 Created
Payload:
<coap+tcp://[2001:db8:1:2::3]/reg/123>;ep="VGhh...2aWNl";
    con="coap://[2001:db8:1:2::3]:10123";
    at="coap+tcp://[2001:db8:1:2::3]:10123"
]]></artwork></figure>

<t>(This particular server uses multiple ports to tell traffic for different endpoints apart;
it could just as well use a catch-all DNS record,
do name based virtual hosting and announce
<spanx style="verb">con="coap://reg123.server3.example.com</spanx> instead.)</t>

<t>The client will then use the discovered address to direct its OSCORE requests to,
and the RD server will proxy for it.</t>

<t>Note that while this setup <spanx style="emph">can</spanx> serve as a generic RD and answer resource requests as well,
it is doubtful whether there would be any interest in it given the data becomes public,
and is limited by the necessity to have an <spanx style="verb">ep=</spanx> filter in all requests
lest the network be flooded with requests.</t>

</section>
</section>


  </middle>

  <back>


    <references title='Informative References'>





<reference  anchor="RFC7252" target='https://www.rfc-editor.org/info/rfc7252'>
<front>
<title>The Constrained Application Protocol (CoAP)</title>
<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>
<seriesInfo name='RFC' value='7252'/>
<seriesInfo name='DOI' value='10.17487/RFC7252'/>
</reference>



<reference anchor="I-D.ietf-core-resource-directory">
<front>
<title>CoRE Resource Directory</title>

<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>

<author initials='C' surname='Amsuess' fullname='Christian Amsuess'>
    <organization />
</author>

<date month='January' day='11' year='2019' />

<abstract><t>In many M2M applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, 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 a Resource Directory 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>

<seriesInfo name='Internet-Draft' value='draft-ietf-core-resource-directory-19' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-core-resource-directory-19.txt' />
</reference>



<reference  anchor="RFC8075" target='https://www.rfc-editor.org/info/rfc8075'>
<front>
<title>Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)</title>
<author initials='A.' surname='Castellani' fullname='A. Castellani'><organization /></author>
<author initials='S.' surname='Loreto' fullname='S. Loreto'><organization /></author>
<author initials='A.' surname='Rahman' fullname='A. Rahman'><organization /></author>
<author initials='T.' surname='Fossati' fullname='T. Fossati'><organization /></author>
<author initials='E.' surname='Dijk' fullname='E. Dijk'><organization /></author>
<date year='2017' month='February' />
<abstract><t>This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the Constrained Application Protocol (CoAP).  This will enable an HTTP client to access resources on a CoAP server through the proxy.  This document describes how an HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to an HTTP response.  This includes guidelines for status code, URI, and media type mappings, as well as additional interworking advice.</t></abstract>
</front>
<seriesInfo name='RFC' value='8075'/>
<seriesInfo name='DOI' value='10.17487/RFC8075'/>
</reference>



<reference anchor="I-D.ietf-core-dynlink">
<front>
<title>Dynamic Resource Linking for Constrained RESTful Environments</title>

<author initials='Z' surname='Shelby' fullname='Zach Shelby'>
    <organization />
</author>

<author initials='M' surname='Koster' fullname='Michael Koster'>
    <organization />
</author>

<author initials='C' surname='Groves' fullname='Christian Groves'>
    <organization />
</author>

<author initials='J' surname='Zhu' fullname='Jintao Zhu'>
    <organization />
</author>

<author initials='B' surname='Silverajan' fullname='Bill Silverajan'>
    <organization />
</author>

<date month='March' day='7' year='2019' />

<abstract><t>This specification defines Link Bindings, which provide dynamic linking of state updates between resources, either on an endpoint or between endpoints, for systems using CoAP (RFC7252).  This specification also defines Conditional Notification Attributes that work with Link Bindings or with CoAP Observe (RFC7641).  Editor note  The git repository for the draft is found at https://github.com/core- wg/dynlink</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-core-dynlink-08' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-core-dynlink-08.txt' />
</reference>



<reference  anchor="RFC3986" target='https://www.rfc-editor.org/info/rfc3986'>
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='T. Berners-Lee'><organization /></author>
<author initials='R.' surname='Fielding' fullname='R. Fielding'><organization /></author>
<author initials='L.' surname='Masinter' fullname='L. Masinter'><organization /></author>
<date year='2005' month='January' />
<abstract><t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource.  This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet.  The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier.  This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='66'/>
<seriesInfo name='RFC' value='3986'/>
<seriesInfo name='DOI' value='10.17487/RFC3986'/>
</reference>



<reference anchor="I-D.ietf-core-object-security">
<front>
<title>Object Security for Constrained RESTful Environments (OSCORE)</title>

<author initials='G' surname='Selander' fullname='Goeran Selander'>
    <organization />
</author>

<author initials='J' surname='Mattsson' fullname='John Mattsson'>
    <organization />
</author>

<author initials='F' surname='Palombini' fullname='Francesca Palombini'>
    <organization />
</author>

<author initials='L' surname='Seitz' fullname='Ludwig Seitz'>
    <organization />
</author>

<date month='March' day='6' year='2019' />

<abstract><t>This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE).  OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.  Although being an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration.  Therefore, this document updates [RFC7252].</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-core-object-security-16' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-core-object-security-16.txt' />
</reference>



<reference anchor="I-D.amsuess-core-resource-directory-extensions">
<front>
<title>CoRE Resource Directory Extensions</title>

<author initials='C' surname='Amsuess' fullname='Christian Amsuess'>
    <organization />
</author>

<date month='January' day='10' year='2019' />

<abstract><t>[ See Introduction ]</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-amsuess-core-resource-directory-extensions-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-amsuess-core-resource-directory-extensions-00.txt' />
</reference>




    </references>



  </back>

<!-- ##markdown-source:
H4sIADt3hlwAA819bXfbRrLmd/wKHM2eSHJIypJlJ6HHk5VlT+K9ju0rO5Pc
3OSMQKJJYgQCHDQgmTP2/WX7bf/Y1lNV/QKSUpw5d2bX82ITBBrd1fVeTzWH
w2HSFm1pxumFsXXXTE36rGjMtK2bNV1alcU0a4u6SvJ6WmVLui9vslk7zJa2
M9YOp3Vjhk0+bMKtw/sniW2zKv9zVtYVPdE2nUmKVcP/su3J/ftf0S108zgt
qlmdrIpxkqa2bYopXdpfG7uPz+tlY2Y2ulA3bf/KtF6usvgZurA0VUu30AU8
0k3CPVWNW2geVd0Ws8Lk/lpbT90YWWOycfqiak1TmTa5mY/T8/rieXJ1I/8Y
pD+YSfqyqK6Kaj7YQbRB+keTm4YpMehRMOvaRd2MkyGtmmZ4PkrPlvb//G+L
iQppzxdNYdsiq6JviCzG0PS/rcuSaEofR+nxydEprzanh/aP75/cl8V3Vdus
x+lZB1pmdGm14A3Y+/z0wfDRo9PhV198df/Rg6/26CuzzIpynE7dK/+n7uiI
CJYkw+EwzSY0DJEuSZ4VdlpfG+KIepaaKl/VBRE5pemkjRLA0qLS706+S7OV
X7FN8VBaZs3cpETNm7q5ovtsYqpsUpo8nay3CVgYO0gnXZtWdWpXZlpkJa2s
soUjarrIbDoxpkrnxTX9f1sni/qGtnq6SPMwSDolMtppVhq6eV3TVG8WWctX
JyZdZlU2lxlkqaWtpNtyc11MzShJ3i0KmxK/d+Cl1LxflcTkdKWYzUyDSzfZ
mtd7syjopbuWoO9JeAJ52q3SWVMv3ZuUFjR1oiZx2or2wDA552U9oQXzY6P0
RUvToMGIYZOsbc1y1eIZFq6syYu/4SHeFOIsGmFp6O9c6VdX5Rp352ZJ5KOd
bA3dZpKZyWwxKcqi5SeZbuZ9a4jE2DLMgp5aNfU1kTyl2S2Lqi7r+Zq/Empk
4PRk3hDH5bySWY19pps93exIuGhZ5HlpkuR3EKqmzrspb+Lff1dEHz8myc//
mb41xjMdj1jVN6P05182d6TA/hMlsWOmrFdEYNqMjPihTSeZpY+Y06ykp5M3
JS3XpJaG/v2ibVd2fHRE9y26CRj9iNh/basjx8VDx0DrWKH9IcFklsQE9MaW
xEaoRAOvhRWIXsSiJHNEdzDQ79J3gWybs8+spX/YdJYtaROyBvtwQzNK//73
ry/+eP7FycOTjx/5BXThxfDZqDDtTPXs1jQ/fkxwZ2dpwHirmNuEKeINef4+
W65KEzHv9xcv0lXWLmxaFlcmvTxq8suUVot/DMu6vupWoM5lSooRr8kTmT8N
TtIkb6AxLEnltRGxrCdEowrCZWagGWSsSi+epUGNEHeRyrCPE2JIGkAmgDcw
0xqd5YCpQHqgwEesQRSAXdRdmZMM04R5NivRNrL3dAONSsshepAo8di8J9/U
Ge0csXy3gnwRA2FrDHFaSawCfrJmqnqra+l7E4k8mQWLb24W0Bg7bKVOinSL
yrxqHVEvQbu8qokFylKE1ixp6+lDZUAO4gVaPRQoCy7uIoqTKrGBFvKwrcuO
SUE3N3U2JSqSoM0XLb+/K1roVxYh3D3HwkGC36UvRRd3y4lpmBaNmResHLBu
YhBoVNrY46un+JaIcJXmWZulKxLt+N5BsiTr09BmmAZKfkH66AY7CMUHDUNr
uDJmxXvBI9BwxPCl0HfjxeDHi7PviFTLriTtZurOlusRbU9HK8cQS9oG+po0
3sazMnjBShLaibbDsAYjSmQkZNgdYdbG/LUroMh193ETXlesoJJpNXYkDEEj
z2bFFFxK+gnqZEFUiSfPd4vU8vrMLKOB0pPTBZFsZtqCBCRbwh6zcsjrvxl5
0LyfLjJiB8sEJX4jFhkkIoqsJHjjeGCaLbEvay/YLWJCsLMzHVjLCiJBc/62
viFF2AzSYibT8UwJU5nleQFC0cMFjE0mCpjfUdD8hJhE3lyWNWBtpzJIVJxm
YEJSrWoSLP7xfq0EjJ72jsEgCV4Ba5VZwebVTptiRfNy1pFesqDBsV8ma8qC
lsDarI32oKwzL9K9bVe+Ixt0E+2Ee6xgK+EnOmMeMH6K28IgbPVX8oBaEgMn
pJF4iY7H61m30QrbWVeyx9lVaihYXPGeHfqBNVshC7GmJY+AzPjcPE5sDWYh
7hYBJlGtUxLukq37rpFoELFF2XrY1kP6KyUbKGQZsSF99/rZ63E6N23Kg3tx
J9+JPKUlfAa31uD+kILGtuSGGAX0FMtLZLowOZn5rJqSKfvBEZruBm95vlxl
TQsawkeGV99kRCoy7l0D3UX6NJurV0QbRAuhR8sN8hPxGojgGc1BhyUa5HhV
UK4sH+zV0EsnNc2G997SHuUd1G5e31SQPxY3Mk+0nTTRG4PdtGlXeRXh5uRu
g9XDKqyqZidqg8SoH1qqoXYyaMlDaOGLtDewe3imqPKChKRTivixvEiyJTrz
bJUkL/Ag8araHtJ2NzWGMStiVlgeUhiFKI+IG8EvKyIt3Md8xFprz5IOpnVJ
mEFexZ5/gNz9gw7bDHeRzEmLtT579ZaYrYBxORS5Y3EZihWd0mOwkPQk8ZsV
UrFXIQPNTWUa0ZHvCxEP2qfIaRKdy1w/IemGJmgpzoTgmOWEQpmpUT8Tzx+O
lBK4gSITWnojtItcp0HCIk5uTrrHc6UVluyAUVgIBofRVEOrOpUYlPRKJX5/
NoWVBRuQoiQNcQObkvkQJmySkIOUBlm03OqsWF74FRipxRZfPINPJa6JjX0u
3TMXbBTvsUmQpbcbe+QlipbpdmsQZBKMyYZ/RbFvckC7thdtL0Jbiu/gEQvp
3KbAqbNrcpfeHyY0MNw27wxENiDSm7wS9lN1zt7lQvQirCOzQaSashJVCxB8
pBdvYGyInMRSSd+Ug+GEpfGU1+dMU9PsE3fUU/Ur5G0YS3k1jEmDQORpqn8U
Whvd3n2RXvAE/ZNnB+65LswN7WV/1WQUVyvjFm+xnNdNMScSvmWTMoplkvT0
QOcaOJu+WVBUQyI/c9O4eP72XY+0asnIRaX5lNkUqsFyQCXKU83XhmdLi4BG
gUsDMSSPdnpFNKMpnSON0YhngyGIDPR40AgDmTH9l20DWKM07zlaJDPQrRL2
YWAWq+u6vIa/iBA41gmezuPkoqsq+Yo24vrU3+I0H03VpUg0xvbOVRMePeva
uqrJDbLp2zXt83IEypqCp35N3q4mSdijVXpUCG6nquFaWERinmnd0WpyDhfW
NAkig1N2OYU83ilwWmxCVkLvg4vSqdXFVtt61sJPVVcv3lYSWuye4YTIVGZA
NsrM2XDTnAsIg9/yDjqqZPcibNNZ8KfwRciVsCK0LfYGD0NCxZ3opr1RX6oc
DN9Q3EJ2XVQp73nR98Cd+MDbiq52K+IeNbWm4tRD1nKawNHW2SQhOZRq3c1Z
DaxlzeSySQRCQc90EWhHuibl3AuHdUtoAx0KBpdW/5bUkYo8ed5F2TX8ssgo
iuOMubGwNN2qDUTa3w4KLDkCxCgYkO1JXrOf33G6ZINtaUfIbdK96Sx7CuFL
jk9LM2vZ8E1ZaEQnvylJWXuDl5zLP2guRB0Ep87C4f2gDyYA415MO2IPRGwc
+MBA73LXVKGyEkbEQc74XHMxqRFfCJHWdmCmDhqivMhHs6qknI4KVgNiBZ+6
6Ll1zkGLdI7ygaSJ3PLYo4Ci4mQK8aOo0KIVRkAgxLoJDvkoUElmABkCuV3O
iQNwTh7IPlMYZuxjvvzmNWlKZ02ZKEXV52tJK1bmhmbt6M37hVewf0ieD+sb
SxLJhs12bNrZIQ8T4x2b0f4vSNZWWCQTx1lLHhM6RfRmYHsxEOqxz5Su7KFD
jDIOafz26Gq3N168MrZJzAM0G41a5M25Tkoie3H+ZyQqIHmWX2cVfC5m/Dqt
J/LgjF9LO0P/jzSjajHLZsRyYjKofEnt+RiosLK2a2E9t+/q5bAS3lxU4J1E
04I0MUOcb91Wh4H2g6zRrJ51xg2Sb2Z9nNK4eDbQwMWFhBz7lMUSTBdN8TaG
4kmFGcUzVlYHb/R4a9U1q5qneAadhgjXheTej89YS/GugOEfvax/eHP2ijyP
Bk5pQ3ED/TXVgGSckIuc0vb/dZx+8/wdXc9W46Oj/5yZL++Px8e/HI0Qegyv
KgpLjpDE+7ppn+DvUZPfc8/acXoyuv+QgidaW9Xy1d/rSLqiYZOPNCbnxGWT
/+ExjbSnQ+0Neg+ZriHKPhjx5o+2Ho0Se71R9DryjP/YgGa1czyz2oNx0GQ+
JCkEdHCRKsmwZD2du3ZJHXHbJVkfXD6xv8E4KffBQLF/JC6ds3EZ7HJJPHBt
JFgw7GTozotxXZqMPReeCz8Y7DIchp57PK/qhkUYVGihOLxTq4pgk12Tgwza
E66Rdex9TdYNFtnn392aoRgPHyf8Ghbe1o3vrOXW+FwOsTGF9m5Ii8/3MCVy
xW1k6bO2r/FYmJcoMTQs5XENh++GweVoOwiiT9X0BMxPZyCpH/Jbl4XF0rCM
d3VdWpWdvB4lb1TClarkEc2Keadubi5ZdayERq9IiyB4SA6ms5Hmyr+8/8XD
jx/JbxfH/tHo4ejkMOGo0ojCjPQGXSL3xEJTCXMQL+qWWxf8OGPqyy7pwpTi
QJWSFdllqCOfheyyxJrezNPiO5cr3HrWT0307sDl2HKhOtubAlkA2o1IPWdN
A0bOgppUa+P8CceKLnHDKWDmLfJmae1kSMcb5skVfAK1wDPCGRw79pmXTRhG
FPuad43EiBsKWJIsUYbz0X3NesJdKyGw/YDIIpzn4OaGdPrWviijwKVnitaz
2ZBuHlrap1kYRgo0aj+ENLwQx2DBgS7AbIX1GUIhiDOUmTOPvDjRMD454GZ+
oFFbVlV1R9LcHCILkELla5FFaRqc0diSihN68WyYaf5c/dC3ZAeJYZz1yyak
LQauJMqJsVVfegyponrteAdjyYhaqYGKa8GALPtSkelPTL2JvVXsEIcskqiM
JUdBheZ3iiitTi7nUkK5NvC21VS881xoE8jkE/WWSImcOXqrRupP2Ot0yeZG
W0FjFsGPcBr33XpFs9+wPT/f20tAIJdSxbZQLDk3kvi7UUpIbZp9J+gNDqJj
WgfZ02QiWwZhfpd2UW2F9ETIoA/SfsHMsVhEEHIYDevu4PNrhEaeqNlwMPrm
23sT9jP6l3k/QpEYLhUp0c/o46QrSlDsyZcPTo8/Y6THkx8TzvBnzaQgUSW/
7DorO0mE/jhK32megGmmXlWokEVpMK7uZM6/hjq4xRe6y/24a/48GP5sLYS/
eS0+8Tg9TkQixVQTkdVXLkqpS3jFz2wTYlFHbadkpHoumQWr/KduOBOnJxak
0qB/JDDKRS7UYCKqEqHgmuKGwLIvHrIQ7L7rp2B14nogpzE0qRNprzEJDzMe
+Ybq1Qa3iTaF/W/FLmx7RPs2vdz0TC8ZjdMsNQ8HmkpBYMp5K2AVOMgjaUFe
Yln8TReczbjwr34+y6fj9YjL1Y2zATKSaNjsXab2FgFmFUmBeg3xgg8J/qWY
Bw4UkmdJIswgJkisbM+OgSbO/+NsjkGVCE5S4uyZOnKhTg+6O+3F/gd5jY0r
BmbOddRk4ih5SyvHNjvky4zUxIQLqFHqoFeapc2BdmN+YMWZm7LNJBLfKGR6
oANL7puzd+ffhpoPpwg2MkNKYXJHHDZEdlZGZ0xUW/hSo4SXmo3jPJCaFHYE
UVThoBYV2dfONA8iXcbhbcNmkwSKFlhYpN73Vp1d7KX5usqWKOWhmHywBWqg
r/HNx4/suakuZF1aVB3iX1muy2vBx2wDE6nNcjkID2sR26w2NbZgs67h/KOz
ZPROBNNrpHQojiBOtgk2jw13WCLExHq+XvvEhO0mf4HLRcMox4ne0TS3pGnB
ta3mkMQ1k/gdlU0zcoUPV3JVS8/VCVznTCn2imtsuHKZX5Lzp3gT8j8iUBbM
DbEG1IHPFV+y3r+MRQ0ln2j/2CHHcnJ5orcGkJt0hJaCuXDi7/fphOBLBR0y
EjiB9178Cr2ey2BXWBhmXSk6omOgUpSXHTiX00c+9zhZcs9nWkUVZ36d/kZP
o0FqZCYc/wBZhtRIICFy/dDTQAWmDadigD1KzkpbD9ixg3JnxWZUpovd4ZiU
1QMNsHKyB8JOPSFlNpoYdqrbOhGacrgRcR3b2LIMKIqMMVfsqCCN38/2+6zQ
uzvCS7ou3DFzwAg1H1L4wG7T/Q0pVtYZm3LuUlE9pblJBa/RN120KDvGab6u
4opdjr2GOARFJCoy26Caj69a1sKVvTFS1tKl9/g1hgMFfVKu1WchTdX2Vbvu
aTQLq86cT6Vxwq7wOEKv0AUeINFrysAeugL/id5SunBJHC3FV7So7+bwhos6
F5cPsBE2LxpZkMTVS0ZrMbarbcWSdlV2nVFsIOlQMozPULGopu1GrosVQkjV
biWyfd6a4yYKNrns4TJbfopQyxTKLjh1HBib/a2leBfgi2r3Nic/YEHmvZl2
LEG6UQOp5QjXO3wnqJoXoud5eOxslBSgcIIYM1u6KE94yKA4qml/LqLNXCIG
NhTGRBS8hrQk1a2W9zg21ehiQVIvvjhjiH0MviMFEZf1RrsruBy55zu3hdFy
zr66IDDvo25ySZ/OTT1vstXC1dmJBUDR7ytOrYQyoPcro3qg5LWhT6Iy794m
5qKXvNjjNIH6DLR0vQ0V5EoAs9536UFm6WWOt9hZhWZnzQWl7lLvKI+oIrt4
ZvdF+mzCzrIwl0W5CsrSybJi4GQ/KXp120/vmxiyPFgxM6Anx2boGmUA4OAL
2KtQ7151lUKGBjwVNkiSDVh0d+Z5VMUSQZb89V5b17LtGvjupWBRMpjhmz61
E2UCugBuq2dEoTlwA63oPd7bRDFdjsBM1x60JKImV9HZjsIyVznSLrJhLnBm
cpn3NUl6L9sPOtNA6mgHxA/nUTAUPPvNZAyn69tselUaB5LoJZxGIvtSiBT7
4OFiNuXsgUUVIFF151w8NkHehkcg843kFIs/CVjZ5X4Cm8BAqQk6pw/If2Ri
sb/kfDacLFt5tD6z0EsH4Dubm72+6SR9TizNWJUZ5s/oKpkmTEfhovyQznIa
PFLZwfFyuRuPk9S6UM99YHs/Sp5K0VX8D50gBQlIvMiAnmAMKI3Q4lxKi5B+
Uamcy00+VqNZF7ZvXF7ocGxt5/ANG/agQk2HOZaUV6HJYK4KN4zfAh96/bal
AwHmWBXTK9pgUWIwIJB+rqNa0/IMia8bYMWwhE3viYv4L2axLDuqapkY2knW
VpOVOeAB67oCag4EHNLrDvtU8dYXL+QZsYPiIS7IFDllymUHT3bGxeANeQ38
kuZokS2Ev9zYVuuITM+JCSPEu93eEHtqJuOmviWoS/wGCeyel66S+7KuVwGR
RhIdJ0IDsKWXSYj9GeYaB+1k52zbpkvZLSb5mmhL9MwhEx5RuwWrAswrqSMs
BvBEAlgkPvPwZYCHpQzhbbEUONcKRAq7wbi9Ad4KlH8bAErw0SoNfAU+DXYj
FdyyJ2RKq5Kq+l6m6CHWq26C6KPsc7DCxzSoagwXRkn3qr4XvCRRWGILBx5S
oM58TpspMcQGry478Aaw7KiMJa4aY02JKTmN3sPZtuLlezAmBU1MjxC2NV3J
i/Zpkbg0ZZPLXs3u60VjZk+O7l1iZ5MN5P/XIY7gW6YNadtyHdDATMcryD9J
rp8B4xzfuFCDxCa0mAjowo/KNJPaKqclqxC3+2S8hBzbZsAZMC7086shsF4m
Q0gfR7uS2MlcsbxFNlfisw0z5ZDG3YR9b1WVCP9g/mG/ItGN0LuC9gAYAQtS
F80XnsWIuu4XzptD2XB2JESke4Hse9DDVoIHTpIzeshXMREeC7Z6IjVSqY09
+OrLR1Ft7HR0LD4Lni1cXquQ7iPThuoqSyazj0qIa0dg40jzWdTNXhRZJ5A3
gDzZwaaYNHCbm6CvvHrREdxf7pNt+xbzkgkGGmiRGBI54ZSAQZA4ULOv+FcJ
Mr3W8U8DdewgCiWUQyg5u3CDQZkeLv2C7U6NLDBLKe3HULZ3WDCChO34ypW6
OCKXtBynCzfBqg6AKgqGlEErSDFrhhA3cMAQPSZITdDOIhQl4yNRFreblFyS
RaBBq4S+qhNFoaWyC/tW94mYLDy6z+pfC7mrRZMJeJ8bpJjjaVOT/i4w1BB8
oWhabiRkiAQjTBllc15fnL30AjKkLRhuimPt41aRBe7PYZoEJ0qSD6Q5STPV
SB2MEunvkglIR5+G4bEIRFzheN3CWKtLFAti4fp/SJ5ukAxz7Ugwq7Soyivj
unE9LlZzCh1EaQrQHztMronBpyJE9uEWcUJ5I1TcCf/KckUQY30+NN1h1yX7
2SOpRTkGHTAUBOzyolGNimouDK0i7f21WT0BhEXqJG+yNTBbY8FzHIGZyB05
gqX/w+NipmANCkd6YJTj9LxhceOrDpU4puHN/Oj45MFpkkgKJiS+4Hbm8Ayi
zJPfts3a0IaRoXnINO6CxPRXotWl0Wh0+5oei6Tgs7t577GvK0WWbc+va88p
aM1QVumLs1dnGy2okpFsjNwVkt7Bz10nrn0qaCTinKdrMJYpZz6ttkWpuArk
CwCR+S+8mL3x5o0Ipm+N+nVobn/pGD9ea8Y7ng2H+XIXSRSnbiUZGKbUkyoH
YV0gtRbQp8mBmY+4kTc22oX0FAQD7HEzzuzlQkBii3vpH5EmkA5oNFZHU6Av
6YVNO+5f+1NWFnnRrsccSNxLv7dx/7pXR+WavnumbUfMvbTkyzASNzoiLke7
NKowCDYYAQTHKrrxySXWz8qJmAc6pfKpzQz1Sgt9SG6R1hQk35Q1c2m8BJQq
BFhFQP0yDCC/nRM0MMeCpImYdRUY2CMkBm5k6SOE8yptIZyEHNGt73r5fLEY
ti2ku6lcQ5pezAI7Z+klLdcWc69J+6vBYpgTRG8yqYhHfIrRrcLFOZKec/0P
PriWy74HU8t0dV/POXgCe2uLGg0RaN6oFvWynpsKxSFJrMKswE0no8BMLGnF
3EhLrCjz77L3QwrpmePwSl/oA2tqNU+R0iERK77ZtuId/aZBoiXB7YjGeC4J
blJXeWiKC6U/hr7KqJLIYASuoyGIITkAhZ5rHAAxddWMQdDQigrDU6Sz+t4v
b37VHz6ediEZr4azEIPdLisyqt18Lj5FHF0ph8KPX3h8R6RcxsIDO4b07HLB
TUFgsYOyHTbu06GqL3V+YadZ+TGk47mb/Es1pgnrDQd3YCNPxmUO/ckh932P
NHWv3WGvxUlVZ7ySwoUNfXUO3MSFsVXGuEWKWqdmo1qUcZqElmzyrdwMw6sb
2V+tPweQpK+MsQ9a+LigUkz7IIkQWpwTnmPXfXjdVT7t38be9r6NagAuEJaM
HE1wlBw4q9iF7LOKVBwN+Lar3tt9LZ1Bm3x+gSb2GFdOkXXN+Ul02Dn0Jfdt
+jYfrO2QE1Lqx7eOG12PmYDJFZXhER9y5kPTrNVhl0ZdN3EiwqP7sAKlwJ/O
WUQizGOUW4qAnFFD4JbZY1CDw18gXd2m2n3MQu5QxZx9xCxzgdWo7ZK7GGXE
RapExF4QFjHn72K0ZBej9WAQsT/c62vULHMPI6IHbSDw2Sg5UVDZ8bkFPa/I
jpNv5EQOySgCLmYyLpVulkPjKe7bjSbaFeNQ0UJVIIjgvV0h61C1IUPgWw0A
Gc5KeV38olqUt8mR7WMsHoU5hZwEoMcg+O4S2+tzdTlnkTOznX4+0NaTQ3UV
3TAhNHHpH9Wsceu4lkxC8ZojM0ZkVOvhDaA2O8tobG1CD7B1xwxITqwVtFiv
tzA9Cj0yrjDlQbvwRfq9ZzhVA31MeijKq/rtv78c2nZdMoRfBTz3vWmjxPvR
+HO0L39+/jP/OXIf3PX9n8PtR8P01/8Mowc+DKIveGKhRS78+RBP6OfBIH5o
88/gv/b3k41rP/uZ6yL8QvBlf7W9Bz9sj+9u1+X/7B/c+JxufpG4IUmxnIWR
+fPTHW/iL8792h35+2v689HWc+6LxK3nA/4b5kkfPsQX4jd+0Nc9l/+dy7/k
ivznfPuxc/wnSQ4un1+yfF2eX0LG1FntHyrUc1go/A2l3HJNQvcUQHR6orzt
CY8iUk53ONLLk/v3j8f55MvxOKuOx9Ps4ReXAoYV5C6XugWJJUJau2KAtD0G
Wbt4dvbadecV3CT5KH1lyMZO0FntqiPINgBYNL1iDCF7F1ncsQZbwQ0lPv2m
r0pcB06JpGHos1vAsEB2fZ/k2SB9yiQ4H0XnNBWVooakHGldibSwtzWsbJPm
H29dua075be1nnxiX8lZ5KYyuUDnpxoCBC/B6Vv2EDaTJrcT4RfNp7hXHH/m
FUH+hLwBBpydPBiZLga5/hMTL+b04aMvhubLrybD45P8wTCjz8PTk0ePHj48
Pb1PfxJmOtf2zlQolkuTFxm3qeAkJF/yi/z7OMUwWXPbAkdnn8gsv/QrCr+d
Yp+c9/lkQvzhMc1iz08jSvzkT/ZuncjeY3JqfMIorPTkAdq59lzpF77+ZuW3
J5nEgrcWf3e1CCObq02Pvq7hY2hWEU4nVOY9vd/XAEM7Z4wgOfMlCp0O47nF
nY+cBW9G1W+WgMTFP4nkj6wXJ3Y2cwYt4tQZ8boUz2+1IwteVytnY2jLv9ej
233tFzsrnAG69f33L55ZgUJOUc3TpATnlHmhPuElxT6ZpsAKeZncdx7g6tOp
kfrmZkHZJkZTzzx/mb4t2o6/fSzbVtirW1K4goqXSgX3a+Uk5QxXpl2TUyS0
rVAQ6kRuPsfDcglNSwqucMjvliqt1il04gHx9em+6m4QkhjbLQe2f15BXOW+
Lpq60vPLNGFFNhIZGOGGC8HwMBQs2+SuwS1QKGfymxgJpVWgW5AD0SMojHJt
kRwlPn5keP44iU9OcUdscVN7v+j68s3wRzxEf/80St7WPtZfctl7s0pt/595
u7f++Rd6u/y6uz5ve7sftj9Hru+HW/3d4fDz8Pkpfx4OnY9L1/kTNs2v/4Ps
5Qf3Tv78H/r5Q5hs9KnnKx8fuS/k84l85g8PjvRp+er06LeRpbdHn/NSPo+/
3rqET9Ejz517vXnpebhA355LcLjB4U5PetkW4D+bA2QIPTSAVdstgADx1O8E
BESoApIgdhYZd+LB7wLSSEKT+9y4xFIuSZUqHK0kmFzBftJsh3iYZRz4jQA9
5uyMnjLihggJmhFyoXF9RqupHqzrMJ2SLeBFxsjjpUHOtbBLhUjDsKyNHj8U
TnDjrA8qBjx4yELibEVO4ihEiWMFF2LIUUHiOXh7joYjQa8kBzf8unCUTsoG
1IOOIkDiBsh1Ur93OlvwsnqqkxxuFZ+eIVTkdt4ZzUl6SDb6P5GA4q6vXw8Y
4Bk9+Mcb3Te9uzsb2/tvPfnlk2KETx7irqBEgcz+QKlWkrG3F2Jvo9P/T/HE
6UniwJfEHg8Ygsu1x2IW+r/1wCEPJdpQND8O0v9gEfppHL35DUpC+GdXyjaf
5dztohnOsfrxpydbXvrdzrmn1p1e+uM4VfrkKw2LLKP/xIHJ3AGBcrbAwKcO
4CdLxQtm5td4/3Q8Pv3XhT63stRuSv73xDsHr+pWdW4vAQ0fvJRedZercA11
K3cww+48ceg8iRK2hyMvYSF+cEd1SRq/a9lx+wmlCmBSgJhWJdhyshg+vt0a
OYqVwglBvaWQy8dnvropsLsRjgrk8sKOUM6Tmg87sreDbbluwQqDS8y+IrZ9
NIrCaQGMtbuCPbSbs1nnkPPpIWt4Mqh2F0bWd8SyESJ3SqbAMh5Fg7UrQEOc
/wEZPj7+18nwuwg6TV+iqex8v09s+CssD5f9DqC80yCJoQaJlLhuXA+Rj7lv
TZTdIeX/POE++eU2Ev/3CPdtK+xhcv6J6zv+5Q7wjl/iBornziFuwffsetQT
Vz2E0UhR1H9yZ9ONd5wRG+UMBgLP5d5ubVq5DZEeDrJayUlZM9ZWnE9usulV
3B8TZeIQQWurFDffCaTfndm02cEhakUgJgbHdL3oJ0sGvrVGKsC0U2EFyYH7
Es4mJ0Jc0318e2ib9RGyu40cTltL+KVHvPjWca7WSZ/DTR2dntbrtcOxmgoT
ZbTdxTMGa+yOTe5iysuNp7ailrsfdsBqOOIac+QCkudVKXhGW1UZm82F3N5J
HZ4fQEyUPJGt4Ibazjv+Eh9J2w2jT8XvmEpXAPyUzUV4kbxke3cTzceBxRxv
sBWUAUN/D8MJsFvQ/7A8OCHTsZ5KkQsiXNHDnXTiT+vcFpLzejkpqiycK611
R4Z2Z+GoRweSHfS4FZr45RvrT5zw6aONE/44MeRaBqWDourh8/3U9cEjKRW6
vSUPUKmg/csBXhf1GHISzoFk1xR9TSVrhwa0cACqvKho+Hh5wcCJ2aH9msL2
HOKk99zD+zFVqdTL4R+hI0sBWdGJbfxy5WAuT22cRSUiy7nmCLdFdpmhWY0b
XPFl1Roeg68kHSKWlsFpthy++0OFjHtTIUciIxMs7QeDADjrD8/URnF5hS3m
M91kEk4mtDX74ej+afoN3cGwI/JdIAbFzDviDLX0Xg4mjU41TPRlD+sfz3KD
HnE/yi5K9Mpp0tlDThErJpfiext1brB/K60ohciHBNIuTubweevcQncGgIbV
WSkdmyQuZ1VdrfksVP2Njw2Ixl1YAsVquVcTt1Yc9MO1phFqX68ktkR3DHRr
OKzVZ7Ft4h0iOVRqVoRUAvHytFmvWt9xemXWgGC4jqFM0TAHtsMLBGaG5vXD
9MUzyaiQp7oqO66+FisOkukbGv312/PXF893HP1Q89kJQxcmfPx4CNC50sef
NTuD297IOfG7fnhBT3wCfoFUWxswDtFZL+4mR0I3OFoT5EQW6EKP9fbVaDnE
mjsEcUDgAm0ur87eMXPRDG6IL6wAwt3PekiOqIiOWiWDp5mw9Qr/kMO8fJLJ
ekSiO9Q6oGaZxZVs/V9c2v7BktBg8/EjRjyTY6CnC3Tya658r7Z4fE/T2Wcx
KB3xUnopN5Cn9KdvFgtyiE6yH16V6mCxf3WZ+sO2eYzo/OzL+L6jS4bgkCTr
9jvPh9NceJJVQzhnI4InZmC+Hqo6HPb3bxG3Se0jMBsPKz0EWk4Hwz86dQBf
Zx48QsafoK0EeVdrE0s4pZfPFKcXTtElA/5p62ldptJLOL0y7UDJwPSrZ84f
3uoDsLZgFvZDVGZet4UH33Rc+0iiM8z+UsvP2og8rOqae6Hdt+5Ubj9erEtd
w2vISsJOSI/z1PXcAyPBEIGJCaFSjPWhvaC9wa7Z9ODZt+/4mPbnXjh8SZ2V
qGp67BztVQENDVM50B+o6SRLWitGWcSQ26WBI95ZxpsY7bkr4rNlsXtyIl4b
zuWSXw5g/8DPSqu0rp+Uj3BC5OpNPQ4C5m5B7r1HC6tQdPdZrpgX3x1YpA4/
v2Qi8K26sWEnB9qqsqufX7djRXoIslSXvvJGMU8hKsSlgokFu6ZiNvnBNaoG
ZLEmE3Z0QgMlzz3PegxfKz8YhJjo83a64mOJ0awjv+DkTxOQQ9B4//W4GAUG
yjysO92o1kNDEF8X8THwGkL/3r2oF4Adj080H3prwveOZz4FGSKQ1ey6LnJp
eS3RDuxbfPkHECyQ7lzXpG9XeqTsRotpelBXkaLa2b0jyFjOfh8KmsJt1VnJ
9QlBLw3SQEZ31Ib4vF0lp8+owt78lRv/HpylVM0T92tN5MT9j7+DLT9KNwNX
zPU3HGSo0aGkTTyj9DPX41156zsI/zWzx2dm9QQWIj/P//bi24v6p7dPQ83w
5U8/lv/rp+evrifVRWm+/fd5/uOr8qfzpw+yHy9q3J39+N38p2/+xLallynA
GYb4UYRPTmAfnzzYTMzfZPqrO21WXnnMVRRTuzNh5fSBHUk4hl2sC8Nhkphu
D7JIvAgxGTXK+9Uayen44Xj8aDtTvEHDl4GIv4mGcoycCCfPHi9BQAFuE4NI
oXcUuTACAzJOWr33axdxqKcnIanvfADlSQFAuR5D7R1GpxwwhdlwOyCdXKJ3
MjrdUa0Nh/b0Eo2SOYp2eTtzdDtHChdIfix2Wn41z6gjjI/v0/NxtqmVm297
pT7g9EuUzFBysHL1Hanoc7G+1cL9QBG0cdAyEfwRwz1OfLLBIXD4zEnRFFOk
ZYeISKDBJBc7SGBZORnDon9dNPwLJVBfUifN/eYklzE9iH60mpFM/UEvEeLz
SKpBnID5EyEcQt6JEP8gg5gq/mEQbqqHmKkLGOWrekjkmHN9gMxdB0koPshZ
JuF3OdJ706y6p8VMdhrdOZyoZvF6NbPrsfX9Izw5hcIdu92Ef8vJNdFKTB18
EP7tBD60pJUmGffLkwpp8tUBOTdAG5TDYake2sm+TBsdL1ull8S2l653He5e
dAx7wme6x7kYHKRKop2HRgd/hCV+axFCnfxfkVADdNN1AAA=

-->

</rfc>

