rfc9953.original.xml   rfc9953.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.29 (Ruby 3.4. <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.30 (Ruby 2.5.
4) --> 9) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
-ietf-core-dns-over-coap-20" category="std" consensus="true" submissionType="IET -ietf-core-dns-over-coap-20" category="std" consensus="true" submissionType="IET
F" tocInclude="true" sortRefs="true" symRefs="true" version="3"> F" xml:lang="en" number="9953" tocInclude="true" sortRefs="true" symRefs="true"
<!-- xml2rfc v2v3 conversion 3.30.1 --> version="3">
<?v3xml2rfc silence="Found SVG with width or height specified"?> <!-- xml2rfc v2v3 conversion 3.32.0 -->
<link href="https://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap-20"
rel="prev"/>
<front> <front>
<title abbrev="DoC">DNS over CoAP (DoC)</title> <title abbrev="DoC">DNS over CoAP (DoC)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-core-dns-over-coap-20"/> <seriesInfo name="RFC" value="9953"/>
<author initials="M. S." surname="Lenders" fullname="Martine Sophie Lenders" > <author initials="M. S." surname="Lenders" fullname="Martine Sophie Lenders" >
<organization abbrev="TU Dresden">TUD Dresden University of Technology</or ganization> <organization abbrev="TU Dresden">TUD Dresden University of Technology</or ganization>
<address> <address>
<postal> <postal>
<street>Helmholtzstr. 10</street> <street>Helmholtzstr. 10</street>
<city>Dresden</city> <city>Dresden</city>
<code>D-01069</code> <code>D-01069</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>martine.lenders@tu-dresden.de</email> <email>martine.lenders@tu-dresden.de</email>
skipping to change at line 70 skipping to change at line 70
<address> <address>
<postal> <postal>
<street>Helmholtzstr. 10</street> <street>Helmholtzstr. 10</street>
<city>Dresden</city> <city>Dresden</city>
<code>D-01069</code> <code>D-01069</code>
<country>Germany</country> <country>Germany</country>
</postal> </postal>
<email>m.waehlisch@tu-dresden.de</email> <email>m.waehlisch@tu-dresden.de</email>
</address> </address>
</author> </author>
<date year="2025" month="September" day="16"/> <date year="2026" month="March"/>
<area>Applications</area> <area>WIT</area>
<workgroup>CoRE</workgroup> <workgroup>CoRE</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>CoRE</keyword> <keyword>CoRE</keyword>
<keyword>CoAP</keyword> <keyword>CoAP</keyword>
<keyword>DNS</keyword> <keyword>DNS</keyword>
<abstract> <abstract>
<?line 116?> <?line 164?>
<!--[rfced] FYI: We updated [I-D.ietf-core-coap-dtls-alpn] to [PRE-RFC9952]
for now. We will make the final updates in RFCXML (i.e., remove "PRE-").
-->
<t>This document defines a protocol for exchanging DNS queries (OPCODE 0) over t he <t>This document defines a protocol for exchanging DNS queries (OPCODE 0) over t he
Constrained Application Protocol (CoAP). These CoAP messages can be protected Constrained Application Protocol (CoAP). These CoAP messages can be protected
by (D)TLS-Secured CoAP (CoAPS) or Object Security for Constrained RESTful by (D)TLS-Secured CoAP or Object Security for Constrained RESTful
Environments (OSCORE) to provide encrypted DNS message exchange for Environments (OSCORE) to provide encrypted DNS message exchange for
constrained devices in the Internet of Things (IoT).</t> constrained devices in the Internet of Things (IoT).</t>
</abstract> </abstract>
<note removeInRFC="true">
<name>About This Document</name>
<t>
The latest revision of this draft can be found at <eref target="https://
core-wg.github.io/draft-dns-over-coap/draft-ietf-core-dns-over-coap.html"/>.
Status information for this document may be found at <eref target="https
://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap/"/>.
</t>
<t>
Discussion of this document takes place on the
CoRE Working Group mailing list (<eref target="mailto:core@ietf.org"/>),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
wse/core/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/core/"/
>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://github.com/core-wg/draft-dns-over-coap"/>.</t>
</note>
</front> </front>
<middle> <middle>
<?line 124?> <?line 176?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>This document defines DNS over CoAP (DoC), a protocol to send DNS <t>This document defines DNS over CoAP (DoC), a protocol to send DNS
<xref target="STD13"/> queries and get DNS responses over the Constrained Applic ation <xref target="STD13"/> queries and get DNS responses over the Constrained Applic ation
Protocol (CoAP) <xref target="RFC7252"/> using OPCODE 0 (Query). Each DNS query- response pair is mapped into a Protocol (CoAP) <xref target="RFC7252"/> using OPCODE 0 (Query). Each DNS query- response pair is mapped into a
CoAP message exchange. Each CoAP message can be secured by DTLS 1.2 or newer <xr CoAP message exchange. Each CoAP message can be secured by any combination of DT
ef target="RFC6347"/> <xref target="RFC9147"/> LS 1.2 or newer <xref target="RFC6347"/> <xref target="RFC9147"/>, TLS 1.3 or ne
as well as Object Security for Constrained RESTful Environments (OSCORE) <xref t wer <xref target="RFC8323"/> <xref target="RFC8446"/>, or Object Security for Co
arget="RFC8613"/> nstrained RESTful Environments (OSCORE) <xref target="RFC8613"/> to ensure messa
but also TLS 1.3 or newer <xref target="RFC8323"/> <xref target="RFC8446"/> ge integrity and confidentiality.</t>
to ensure message integrity and confidentiality.</t> <t>The application use case of DoC is inspired by DNS over HTTPS (DoH) <xr
<t>The application use case of DoC is inspired by DNS over HTTPS <xref tar ef target="RFC8484"/>.
get="RFC8484"/> However, DoC aims for deployment in the constrained Internet of
(DoH). DoC, however, aims for deployment in the constrained Internet of
Things (IoT), which usually conflicts with the requirements introduced by Things (IoT), which usually conflicts with the requirements introduced by
HTTPS. HTTPS.
Constrained IoT devices may be restricted in memory, power consumption, Constrained IoT devices may be restricted in memory, power consumption,
link-layer frame sizes, throughput, and latency. They may link-layer frame sizes, throughput, and latency. They may
only have a handful kilobytes of both RAM and ROM. They may sleep for long only have a handful kilobytes of both RAM and ROM. They may sleep for long
durations of time, after which they need to refresh the named resources they durations of time, after which they need to refresh the named resources they
know about. Name resolution in such scenarios must take into account link know about. Name resolution in such scenarios must take into account link-layer
layer frame sizes of only a few hundred bytes, bit rates in the magnitude frame sizes of only a few hundred bytes, bit rates in the magnitude
of kilobits per second, and latencies of several seconds <xref target="RFC7228"/ of kilobits per second, and latencies of several seconds <xref target="RFC7228"/
> <xref target="I-D.ietf-iotops-7228bis"/> <cref anchor="remove-constr-nodes">RF > <xref target="I-D.ietf-iotops-7228bis"/>.</t>
C Ed.: Please remove the <xref target="RFC7228"/> reference and replace it with
<xref target="I-D.ietf-iotops-7228bis"/> throughout the document in case <xref t
arget="I-D.ietf-iotops-7228bis"/> becomes an RFC before publication.</cref>.</t>
<t>In order not to be burdened by the resource requirements of TCP and HTT PS, constrained IoT devices could use DNS over DTLS <xref target="RFC8094"/>. <t>In order not to be burdened by the resource requirements of TCP and HTT PS, constrained IoT devices could use DNS over DTLS <xref target="RFC8094"/>.
In contrast to DNS over DTLS, DoC In contrast to DNS over DTLS, DoC
can take advantage of CoAP features to mitigate drawbacks of datagram-based can take advantage of CoAP features to mitigate drawbacks of datagram-based
communication. These features include: block-wise transfer <xref target="RFC7959 communication. These features include (1) block-wise transfer <xref target="RFC7
"/>, which solves 959"/>, which solves
the Path MTU problem of DNS over DTLS (see <xref section="5" sectionFormat="comm the Path MTU problem of DNS over DTLS (see <xref section="5" sectionFormat="comm
a" target="RFC8094"/>); CoAP a" target="RFC8094"/>), (2) CoAP
proxies, which provide an additional level of caching; re-use of data proxies, which provide an additional level of caching, and (3) reuse of data
structures for application traffic and DNS information, which saves memory structures for application traffic and DNS information, which saves memory
on constrained devices.</t> on constrained devices.</t>
<t>To avoid the resource requirements of DTLS or TLS on top of UDP (e.g., introduced by DNS over DTLS <xref target="RFC8094"/> or DNS over QUIC <xref targ et="RFC9250"/>), DoC allows for lightweight message protection based on OSCORE.< /t> <t>To avoid the resource requirements of DTLS or TLS on top of UDP (e.g., introduced by DNS over DTLS <xref target="RFC8094"/> or DNS over QUIC <xref targ et="RFC9250"/>), DoC allows for lightweight message protection based on OSCORE.< /t>
<figure anchor="fig-overview-arch"> <figure anchor="fig-overview-arch">
<name>Basic DoC architecture</name> <name>Basic DoC Architecture</name>
<artset> <artset>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 .1" height="224" width="608" viewBox="0 0 608 224" class="diagram" text-anchor=" middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 .1" height="208" width="584" viewBox="0 0 584 208" class="diagram" text-anchor=" middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<path d="M 8,96 L 8,144" fill="none" stroke="black"/> <path d="M 8,96 L 8,144" fill="none" stroke="black"/>
<path d="M 64,96 L 64,144" fill="none" stroke="black"/> <path d="M 64,96 L 64,144" fill="none" stroke="black"/>
<path d="M 208,96 L 208,144" fill="none" stroke="black"/> <path d="M 192,96 L 192,144" fill="none" stroke="black"/>
<path d="M 264,96 L 264,144" fill="none" stroke="black"/> <path d="M 248,96 L 248,144" fill="none" stroke="black"/>
<path d="M 320,96 L 320,144" fill="none" stroke="black"/> <path d="M 304,96 L 304,144" fill="none" stroke="black"/>
<path d="M 456,112 L 456,128" fill="none" stroke="black"/> <path d="M 440,112 L 440,128" fill="none" stroke="black"/>
<path d="M 600,112 L 600,128" fill="none" stroke="black"/> <path d="M 576,112 L 576,128" fill="none" stroke="black"/>
<path d="M 8,96 L 64,96" fill="none" stroke="black"/> <path d="M 8,96 L 64,96" fill="none" stroke="black"/>
<path d="M 208,96 L 320,96" fill="none" stroke="black"/> <path d="M 192,96 L 304,96" fill="none" stroke="black"/>
<path d="M 472,96 L 584,96" fill="none" stroke="black"/> <path d="M 456,96 L 560,96" fill="none" stroke="black"/>
<path d="M 72,112 L 200,112" fill="none" stroke="black"/> <path d="M 72,112 L 184,112" fill="none" stroke="black"/>
<path d="M 328,112 L 344,112" fill="none" stroke="black"/> <path d="M 312,112 L 328,112" fill="none" stroke="black"/>
<path d="M 360,112 L 376,112" fill="none" stroke="black"/> <path d="M 344,112 L 360,112" fill="none" stroke="black"/>
<path d="M 392,112 L 408,112" fill="none" stroke="black"/> <path d="M 376,112 L 392,112" fill="none" stroke="black"/>
<path d="M 424,112 L 448,112" fill="none" stroke="black"/> <path d="M 408,112 L 432,112" fill="none" stroke="black"/>
<path d="M 72,128 L 200,128" fill="none" stroke="black"/> <path d="M 72,128 L 184,128" fill="none" stroke="black"/>
<path d="M 328,128 L 352,128" fill="none" stroke="black"/> <path d="M 312,128 L 336,128" fill="none" stroke="black"/>
<path d="M 368,128 L 384,128" fill="none" stroke="black"/> <path d="M 352,128 L 368,128" fill="none" stroke="black"/>
<path d="M 400,128 L 416,128" fill="none" stroke="black"/> <path d="M 384,128 L 400,128" fill="none" stroke="black"/>
<path d="M 432,128 L 448,128" fill="none" stroke="black"/> <path d="M 416,128 L 432,128" fill="none" stroke="black"/>
<path d="M 8,144 L 64,144" fill="none" stroke="black"/> <path d="M 8,144 L 64,144" fill="none" stroke="black"/>
<path d="M 208,144 L 320,144" fill="none" stroke="black"/> <path d="M 192,144 L 304,144" fill="none" stroke="black"/>
<path d="M 472,144 L 584,144" fill="none" stroke="black"/> <path d="M 456,144 L 560,144" fill="none" stroke="black"/>
<path d="M 40,192 L 88,192" fill="none" stroke="black"/> <path d="M 40,192 L 80,192" fill="none" stroke="black"/>
<path d="M 200,192 L 248,192" fill="none" stroke="black"/> <path d="M 192,192 L 232,192" fill="none" stroke="black"/>
<path d="M 280,192 L 312,192" fill="none" stroke="black"/> <path d="M 264,192 L 296,192" fill="none" stroke="black"/>
<path d="M 528,192 L 568,192" fill="none" stroke="black"/> <path d="M 512,192 L 544,192" fill="none" stroke="black"/>
<path d="M 32,176 L 40,192" fill="none" stroke="black"/> <path d="M 32,176 L 40,192" fill="none" stroke="black"/>
<path d="M 272,176 L 280,192" fill="none" stroke="black"/> <path d="M 256,176 L 264,192" fill="none" stroke="black"/>
<path d="M 104,64 L 120,32" fill="none" stroke="black"/> <path d="M 104,64 L 120,32" fill="none" stroke="black"/>
<path d="M 248,192 L 256,176" fill="none" stroke="black"/> <path d="M 232,192 L 240,176" fill="none" stroke="black"/>
<path d="M 568,192 L 576,176" fill="none" stroke="black"/> <path d="M 544,192 L 552,176" fill="none" stroke="black"/>
<path d="M 472,96 C 463.16936,96 456,103.16936 456,112" fill="none <path d="M 456,96 C 447.16936,96 440,103.16936 440,112" fill="none
" stroke="black"/> " stroke="black"/>
<path d="M 584,96 C 592.83064,96 600,103.16936 600,112" fill="none <path d="M 560,96 C 568.83064,96 576,103.16936 576,112" fill="none
" stroke="black"/> " stroke="black"/>
<path d="M 472,144 C 463.16936,144 456,136.83064 456,128" fill="no <path d="M 456,144 C 447.16936,144 440,136.83064 440,128" fill="no
ne" stroke="black"/> ne" stroke="black"/>
<path d="M 584,144 C 592.83064,144 600,136.83064 600,128" fill="no <path d="M 560,144 C 568.83064,144 576,136.83064 576,128" fill="no
ne" stroke="black"/> ne" stroke="black"/>
<polygon class="arrowhead" points="456,112 444,106.4 444,117.6" fi <polygon class="arrowhead" points="440,112 428,106.4 428,117.6" fi
ll="black" transform="rotate(0,448,112)"/> ll="black" transform="rotate(0,432,112)"/>
<polygon class="arrowhead" points="336,128 324,122.4 324,133.6" fi <polygon class="arrowhead" points="320,128 308,122.4 308,133.6" fi
ll="black" transform="rotate(180,328,128)"/> ll="black" transform="rotate(180,312,128)"/>
<polygon class="arrowhead" points="208,112 196,106.4 196,117.6" fi <polygon class="arrowhead" points="192,112 180,106.4 180,117.6" fi
ll="black" transform="rotate(0,200,112)"/> ll="black" transform="rotate(0,184,112)"/>
<polygon class="arrowhead" points="80,128 68,122.4 68,133.6" fill= "black" transform="rotate(180,72,128)"/> <polygon class="arrowhead" points="80,128 68,122.4 68,133.6" fill= "black" transform="rotate(180,72,128)"/>
<g class="text"> <g class="text">
<text x="152" y="36">FETCH</text> <text x="152" y="36">FETCH</text>
<text x="268" y="36">coaps://[2001:db8::1]/</text> <text x="268" y="36">coaps://[2001:db8::1]/</text>
<text x="108" y="84">CoAP</text> <text x="100" y="84">CoAP</text>
<text x="160" y="84">request</text> <text x="152" y="84">request</text>
<text x="108" y="100">[DNS</text> <text x="100" y="100">[DNS</text>
<text x="156" y="100">query]</text> <text x="148" y="100">query]</text>
<text x="360" y="100">DNS</text> <text x="344" y="100">DNS</text>
<text x="400" y="100">query</text> <text x="384" y="100">query</text>
<text x="32" y="116">DoC</text> <text x="32" y="116">DoC</text>
<text x="232" y="116">DoC</text> <text x="216" y="116">DoC</text>
<text x="288" y="116">DNS</text> <text x="272" y="116">DNS</text>
<text x="520" y="116">DNS</text> <text x="504" y="116">DNS</text>
<text x="36" y="132">Client</text> <text x="36" y="132">Client</text>
<text x="236" y="132">Server</text> <text x="220" y="132">Server</text>
<text x="292" y="132">Client</text> <text x="276" y="132">Client</text>
<text x="524" y="132">Infrastructure</text> <text x="508" y="132">Infrastructure</text>
<text x="100" y="148">CoAP</text> <text x="92" y="148">CoAP</text>
<text x="156" y="148">response</text> <text x="148" y="148">response</text>
<text x="352" y="148">DNS</text> <text x="336" y="148">DNS</text>
<text x="404" y="148">response</text> <text x="388" y="148">response</text>
<text x="100" y="164">[DNS</text> <text x="92" y="164">[DNS</text>
<text x="160" y="164">response]</text> <text x="152" y="164">response]</text>
<text x="104" y="196">DNS</text> <text x="96" y="196">DNS</text>
<text x="140" y="196">over</text> <text x="132" y="196">over</text>
<text x="180" y="196">CoAP</text> <text x="172" y="196">CoAP</text>
<text x="328" y="196">DNS</text> <text x="312" y="196">DNS</text>
<text x="364" y="196">over</text> <text x="348" y="196">over</text>
<text x="456" y="196">UDP/HTTPS/QUIC/..</text> <text x="440" y="196">UDP/HTTPS/QUIC/..</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art"><![CDATA[
. FETCH coaps://[2001:db8::1]/ . FETCH coaps://[2001:db8::1]/
/ /
/ /
CoAP request CoAP request
+------+ [DNS query] +------+------+ DNS query .---------------. +------+ [DNS query] +------+------+ DNS query .--------------.
| DoC |---------------->| DoC | DNS |--- --- --- --->| DNS | | DoC |-------------->| DoC | DNS |--- --- --- --->| DNS |
|Client|<----------------|Server|Client|<--- --- --- ---| Infrastructure | |Client|<--------------|Server|Client|<--- --- --- ---| Infrastructure |
+------+ CoAP response +------+------+ DNS response '---------------' +------+ CoAP response +------+------+ DNS response '--------------'
[DNS response] [DNS response]
\ / \ / \ / \ /
'------DNS over CoAP------' '----DNS over UDP/HTTPS/QUIC/...----' '-----DNS over CoAP-----' '----DNS over UDP/HTTPS/QUIC/...---'
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>The most important components of DoC can be seen in <xref target="fig-o verview-arch"/>: a DoC <t>The most important components of DoC can be seen in <xref target="fig-o verview-arch"/>: a DoC
client tries to resolve DNS information by sending DNS queries carried within client tries to resolve DNS information by sending DNS queries carried within
CoAP requests to a DoC server. CoAP requests to a DoC server.
That DoC server can be the authoritive name server for the queried record or a D NS client (i.e., a stub or recursive resolver) that resolves DNS information by using other DNS transports such That DoC server can be the authoritative name server for the queried record or a DNS client (i.e., a stub or recursive resolver) that resolves DNS information b y using other DNS transports such
as DNS over UDP <xref target="STD13"/>, DNS over HTTPS <xref target="RFC8484"/>, or DNS over QUIC <xref target="RFC9250"/> when communicating with the upstream as DNS over UDP <xref target="STD13"/>, DNS over HTTPS <xref target="RFC8484"/>, or DNS over QUIC <xref target="RFC9250"/> when communicating with the upstream
DNS infrastructure. DNS infrastructure.
Using that information, the DoC server then replies to the queries of the DoC cl ient with DNS Using that information, the DoC server then replies to the queries of the DoC cl ient with DNS
responses carried within CoAP responses. responses carried within CoAP responses.
A DoC server <bcp14>MAY</bcp14> also serve as DNSSEC validator to provide DNSSEC validation to the more A DoC server <bcp14>MAY</bcp14> also serve as a DNSSEC validator to provide DNSS EC validation to the more
constrained DoC clients.</t> constrained DoC clients.</t>
<t>Note that this specification is distinct from DoH, since the CoAP-speci <t>Note that this specification is distinct from DoH because the CoAP-spec
fic FETCH method <xref target="RFC8132"/> is used. ific FETCH method <xref target="RFC8132"/> is used.
This has the benefit of having the DNS query in the body as when using the POST A benefit of using this method is having the DNS query in the body such as when
method, but still with the same caching advantages of responses to requests that using the POST method, but with the same caching advantages of responses to requ
use the GET method. ests that use the GET method.
Having the DNS query in the body means that we do not need extra base64 encoding Having the DNS query in the body means that there is no need for extra base64 en
, which would increase coding, which would increase
code complexity and message sizes. code complexity and message sizes.
Also, this allows for the block-wise transfer of queries <xref target="RFC7959"/ >.</t> Also, this allows for the block-wise transfer of queries <xref target="RFC7959"/ >.</t>
</section> </section>
<section anchor="terminology-and-conventions"> <section anchor="terminology-and-conventions">
<name>Terminology and Conventions</name> <name>Terminology and Conventions</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 >REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14 >REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t> appear in all capitals, as shown here.</t>
<?line -18?> <?line -18?>
<t>A server that provides the service specified in this document is called a "Do C <t>A server that provides the service specified in this document is called a "Do C
server" to differentiate it from a classic "DNS server". server" to differentiate it from a classic "DNS server".
A DoC server acts either as a DNS stub resolver or a DNS recursive resolver <xre f target="BCP219"/>. A DoC server acts as either a DNS stub resolver or a DNS recursive resolver <xre f target="BCP219"/>.
As such, the DoC server communicates with an "upstream DNS infrastructure" or a single "upstream DNS server". As such, the DoC server communicates with an "upstream DNS infrastructure" or a single "upstream DNS server".
A "DoC resource" is a CoAP resource <xref target="RFC7252"/> at the DoC server t A "DoC resource" is a CoAP resource <xref target="RFC7252"/> at the DoC server t
hat DoC clients can target to send a DNS query in a CoAP request.</t> hat DoC clients can target in order to send a DNS query in a CoAP request.</t>
<t>A client using the service specified in this document to retrieve the <t>A client using the service specified in this document to retrieve
DNS information is called a "DoC client".</t> the DNS information is called a "DoC client".</t>
<t>The term "constrained nodes" is used as defined in <xref target="RFC722 8"/>. <t>The term "constrained nodes" is used as defined in <xref target="RFC722 8"/>.
<xref target="RFC6690"/> describes that "Constrained RESTful Environments (CoRE) " realize the Representational State Transfer (REST) architecture <xref target=" REST"/> in a suitable form for such constrained nodes.</t> <xref target="RFC6690"/> describes that Constrained RESTful Environments (CoRE) realize the Representational State Transfer (REST) architecture <xref target="RE ST"/> in a suitable form for such constrained nodes.</t>
<t>A DoC server can provide Observe capabilities as defined in <xref secti on="1.2" sectionFormat="comma" target="RFC7641"/>. <t>A DoC server can provide Observe capabilities as defined in <xref secti on="1.2" sectionFormat="comma" target="RFC7641"/>.
As part of that, it administers a "list of observers". As part of that, it administers a "list of observers". DoC clients using these c
DoC clients using these capabilities are "observers" as defined in <xref section apabilities are "observers" as defined in <xref section="1.2" sectionFormat="com
="1.2" sectionFormat="comma" target="RFC7641"/> in that case. ma" target="RFC7641"/>.
A "notification" is a CoAP response message with an Observe option, see <xref se A "notification" is a CoAP response message with an Observe option; see <xref se
ction="4.2" sectionFormat="comma" target="RFC7641"/>.</t> ction="4.2" sectionFormat="comma" target="RFC7641"/>.</t>
<t>The terms "payload" and "body" are used as defined in <xref section="2" sectionFormat="comma" target="RFC7959"/>. <t>The terms "payload" and "body" are used as defined in <xref section="2" sectionFormat="comma" target="RFC7959"/>.
Note that, when block-wise transfer is not used, the terms "payload" and "body" are to be understood as equal.</t> Note that, when block-wise transfer is not used, the terms "payload" and "body" are to be understood as equal.</t>
<t>For better readability, in the examples in this document the binary pay <t>In the examples in this document, the binary payload and resource recor
load and resource records are shown in a hexadecimal representation as well as a ds are shown in a hexadecimal representation as well as a human-readable format
human-readable format. for better readability. However, in the actual message sent and received, they a
In the actual message sent and received, however, they are encoded in the binary re encoded in the binary message format defined in <xref target="STD13"/>.</t>
message format defined in <xref target="STD13"/>.</t>
</section> </section>
<section anchor="sec_doc-server-selection"> <section anchor="sec_doc-server-selection">
<name>Selection of a DoC Server</name> <name>Selection of a DoC Server</name>
<t>While there is no path specified for the DoC resource, it is <bcp14>REC OMMENDED</bcp14> to use the root path "/" <t>While there is no path specified for the DoC resource, it is <bcp14>REC OMMENDED</bcp14> to use the root path "/"
to keep the CoAP requests small.</t> to keep the CoAP requests small.</t>
<t>The DoC client needs to know the DoC server and the DoC resource at the DoC server. <t>The DoC client needs to know the DoC server and the DoC resource at the DoC server.
Possible options to assure this could be manual configuration of a Uniform Resou Possible options to assure this could be (1) manual configuration of a Uniform R
rce Identifier (URI) <xref target="RFC3986"/> or Constrained Resource Identifier esource Identifier (URI) <xref target="RFC3986"/> or Constrained Resource Identi
(CRI) <xref target="I-D.ietf-core-href"/>, fier (CRI) <xref target="I-D.ietf-core-href"/>
or automatic configuration, e.g., using a CoRE resource directory or (2) automatic configuration, e.g., using a CoRE resource directory
<xref target="RFC9176"/>, DHCP or Router Advertisement options <xref target="RFC 9463"/>, or discovery of designated resolvers <xref target="RFC9176"/>, DHCP or Router Advertisement options <xref target="RFC 9463"/>, or discovery of designated resolvers
<xref target="RFC9462"/>. <xref target="RFC9462"/>.
Automatic configuration <bcp14>MUST</bcp14> only be done from a trusted source.< /t> Automatic configuration <bcp14>MUST</bcp14> only be done from a trusted source.< /t>
<section anchor="discovery-by-resource-type"> <section anchor="discovery-by-resource-type">
<name>Discovery by Resource Type</name> <name>Discovery by Resource Type</name>
<t>For discovery of the DoC resource through a link mechanism that allow s describing a resource type <t>For discovery of the DoC resource through a link mechanism that allow s describing a resource type
(e.g., the Resource Type attribute in <xref target="RFC6690"/>), this document i ntroduces the resource type "core.dns". (e.g., the Resource Type attribute in <xref target="RFC6690"/>), this document i ntroduces the resource type "core.dns".
It can be used to identify a generic DNS resolver that is available to the clien t.</t> It can be used to identify a generic DNS resolver that is available to the clien t.</t>
</section> </section>
<section anchor="discovery-using-svcb-resource-records-or-dnr"> <section anchor="discovery-using-svcb-resource-records-or-dnr">
<name>Discovery using SVCB Resource Records or DNR</name> <name>Discovery Using SVCB Resource Records or DNR</name>
<t>A DoC server can also be discovered using Service Binding (SVCB) Reso <t>A DoC server can also be discovered using Service Binding (SVCB) Reso
urce Records (RR) <xref target="RFC9460"/> <xref target="RFC9461"/> resolved via urce Records (RRs) <xref target="RFC9460"/> <xref target="RFC9461"/> resolved vi
another DNS service (e.g., provided by an unencrypted local resolver) or Discov a another DNS service (e.g., provided by an unencrypted local resolver) or Disco
ery of Network-designated Resolvers (DNR) very of Network-designated Resolvers (DNR)
Service Parameters <xref target="RFC9463"/> via DHCP or Router Advertisements. Service Parameters <xref target="RFC9463"/> via DHCP or Router Advertisements.
<xref target="RFC8323"/> defines the Application-Layer Protocol Negotiation (ALP <xref target="RFC8323"/> defines the Application-Layer Protocol Negotiation (ALP
N) ID for CoAP over TLS servers and <xref target="I-D.ietf-core-coap-dtls-alpn"/ N) ID for CoAP over TLS servers and <xref target="PRE-RFC9952"/> defines the ALP
> defines the ALPN ID for CoAP over DTLS servers. N ID for CoAP over DTLS servers.
DoC servers that use only OSCORE <xref target="RFC8613"/> and Ephemeral Diffie-H DoC servers that use only OSCORE <xref target="RFC8613"/> and Ephemeral Diffie-H
ellman Over COSE (EDHOC) <xref target="RFC9528"/> (with COSE abbreviating "Conci ellman Over COSE (EDHOC) <xref target="RFC9528"/> (COSE stands for "Concise Bina
se Binary Object Notation (CBOR) Object Signing and Encryption" <xref target="RF ry Object Notation (CBOR) Object Signing and Encryption" <xref target="RFC9052"/
C9052"/>) to support security cannot be discovered using these SVCB RR or DNR me >) to support security cannot be discovered using these SVCB RR or DNR mechanism
chanisms. s.
Specifying an alternate discovery mechanism is out of scope of this document.</t Specifying an alternate discovery mechanism is out of the scope of this document
> .</t>
<t>This document is not an SVCB mapping document for the CoAP schemes <t>This document is not an SVCB mapping document for the CoAP schemes
as defined in <xref section="2.4.3" sectionFormat="of" target="RFC9460"/>. as defined in <xref section="2.4.3" sectionFormat="of" target="RFC9460"/>.
A full SVCB mapping is specified in <xref target="I-D.ietf-core-transport-indica tion"/>. A full SVCB mapping is specified in <xref target="I-D.ietf-core-transport-indica tion"/>.
It generalizes mechanisms for all CoAP services. It generalizes mechanisms for all CoAP services.
This document introduces only the discovery of DoC services.</t> This document introduces only the discovery of DoC services.</t>
<t>This document specifies "docpath" as <t>This document specifies "docpath" as
a single-valued SvcParamKey that is mandatory for DoC SVCB records. a single-valued Service Parameter Key (SvcParamKey) that is mandatory for DoC SV CB records.
If the "docpath" SvcParamKey is absent, the service should not be considered a v alid DoC service.</t> If the "docpath" SvcParamKey is absent, the service should not be considered a v alid DoC service.</t>
<t>The docpath is devided up into segments of the absolute path to the D oC resource (docpath-segment), <t>The docpath is divided up into segments of the absolute path to the D oC resource (docpath-segment),
each a sequence of 1-255 octets. each a sequence of 1-255 octets.
In ABNF <xref target="RFC5234"/>:</t> In ABNF <xref target="RFC5234"/>:</t>
<artwork><![CDATA[ <sourcecode type="abnf"><![CDATA[
docpath-segment = 1*255OCTET docpath-segment = 1*255OCTET
]]></artwork> ]]></sourcecode>
<t>Note that this restricts the length of each docpath-segment to at mos t 255 octets. <t>Note that this restricts the length of each docpath-segment to at mos t 255 octets.
Paths with longer segments cannot be advertised with the "docpath" SvcParam and are thus <bcp14>NOT Paths with longer segments cannot be advertised with the "docpath" SvcParam and are thus <bcp14>NOT
RECOMMENDED</bcp14> for the path to the DoC resource.</t> RECOMMENDED</bcp14> for the path to the DoC resource.</t>
<t>The presentation format value of "docpath" <bcp14>SHALL</bcp14> be a comma-separated list (<xref section="A.1" sectionFormat="of" target="RFC9460"/>) <t>The presentation format value of "docpath" <bcp14>SHALL</bcp14> be a comma-separated list (<xref section="A.1" sectionFormat="of" target="RFC9460"/>)
of 0 or more docpath-segments. of 0 or more docpath-segments.
The root path "/" is represented by 0 docpath-segments, i.e., an empty list. The root path "/" is represented by 0 docpath-segments, i.e., an empty list.
The same considerations for the "," and "" characters in docpath-segments for zo The same considerations apply for the "," and "\" characters in docpath-segments
ne-file for zone-file
implementations as for the alpn-ids in an "alpn" SvcParam apply (<xref section=" implementations and the alpn-ids in an "alpn" SvcParam (<xref section="7.1.1" se
7.1.1" sectionFormat="of" target="RFC9460"/>).</t> ctionFormat="of" target="RFC9460"/>).</t>
<t>The wire-format value for "docpath" consists of 0 or more sequences o f octets prefixed by their <t>The wire-format value for "docpath" consists of 0 or more sequences o f octets prefixed by their
respective length as a single octet. respective length as a single octet.
We call this single octet the length octet. We call this single octet the length octet.
The length octet and the corresponding sequence form a length-value pair. The length octet and the corresponding sequence form a length-value pair.
These length-value pairs are concatenated to form the SvcParamValue. These length-value pairs are concatenated to form the SvcParamValue.
These pairs <bcp14>MUST</bcp14> exactly fill the SvcParamValue; otherwise, the S vcParamValue is malformed. These pairs <bcp14>MUST</bcp14> exactly fill the SvcParamValue; otherwise, the S vcParamValue is malformed.
Each such length-value pair represents one segment of the absolute path to the D oC resource. Each such length-value pair represents one segment of the absolute path to the D oC resource.
The root path "/" is represented by 0 length-value pairs, i.e., SvcParamValue le ngth 0.</t> The root path "/" is represented by 0 length-value pairs, i.e., SvcParamValue le ngth 0.</t>
<t>Note that this format uses the same encoding as the "alpn" SvcParam a nd can reuse the <t>Note that this format uses the same encoding as the "alpn" SvcParam, and it can reuse the
decoders and encoders for that SvcParam with the adaption that a length of zero is allowed. decoders and encoders for that SvcParam with the adaption that a length of zero is allowed.
As long as each docpath-segment is of length 0 and 24 octets, it is easily trans ferred into the path As long as each docpath-segment has a length between 0 and 23 octets, inclusive, it is easily transferred into the path
representation in CRIs <xref target="I-D.ietf-core-href"/> by masking each lengt h octet with the CBOR text string major type 3 representation in CRIs <xref target="I-D.ietf-core-href"/> by masking each lengt h octet with the CBOR text string major type 3
(<tt>0x60</tt> as an octet, see <xref target="RFC8949"/>). (<tt>0x60</tt> as an octet; see <xref target="RFC8949"/>).
Furthermore, it is easily transferable into a sequence of CoAP Uri-Path options by Furthermore, it is easily transferable into a sequence of CoAP Uri-Path options by
mapping each length octet into the Option Delta and Option Length of the corresp onding CoAP Uri-Path mapping each length octet into the Option Delta and Option Length of the corresp onding CoAP Uri-Path
option, provided the docpath-segments are all of a length between 0 and 12 octet option, provided the docpath-segments are all of a length between 0 and 12 octet
s (see <xref section="3.1" sectionFormat="comma" target="RFC7252"/>). s (see <xref section="3.1" sectionFormat="comma" target="RFC7252"/>). Likewise,
Likewise, it can be transferred into a URI path-abempty form by replacing each l it can be transferred into a URI path-abempty form by replacing each length octe
ength octet with the "/" character t with the "/" character.
None of the abovementioned prevent longer docpath-segments than the considered, None of the abovementioned prevent longer docpath-segments than the considered o
they just make the nes; they just make the
translation harder, as they require to make space for the longer delimiters, in translation harder as space is required for the longer delimiters, which in turn
turn requiring to move octets.</t> require octets to be moved.</t>
<t>To use the service binding from an SVCB RR or DNR Encrypted DNS optio n, the DoC client <bcp14>MUST</bcp14> send a DoC request constructed from the Sv cParams including "docpath". <t>To use the service binding from an SVCB RR or DNR Encrypted DNS optio n, the DoC client <bcp14>MUST</bcp14> send a DoC request constructed from the Sv cParams including "docpath".
The construction algorithm for DoC requests is as follows, going through the pro vided records in order of their priority. The construction algorithm for DoC requests is as follows, with the provided rec ords in order of their priority.
For the purposes of this algorithm, the DoC client is assumed to be SVCB-optiona l (see <xref section="3" sectionFormat="of" target="RFC9460"/>).</t> For the purposes of this algorithm, the DoC client is assumed to be SVCB-optiona l (see <xref section="3" sectionFormat="of" target="RFC9460"/>).</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>If the "alpn" SvcParam value for the service is "coap", a CoAP re quest for CoAP over TLS <bcp14>MUST</bcp14> be constructed <xref target="RFC8323 "/>. <t>If the "alpn" SvcParam value for the service is "coap", a CoAP re quest for CoAP over TLS <bcp14>MUST</bcp14> be constructed <xref target="RFC8323 "/>.
If it is "co", a CoAP request for CoAP over DTLS <bcp14>MUST</bcp14> be construc ted <xref target="I-D.ietf-core-coap-dtls-alpn"/>. If it is "co", a CoAP request for CoAP over DTLS <bcp14>MUST</bcp14> be construc ted <xref target="PRE-RFC9952"/>.
Any other SvcParamKeys specifying a transport are out of the scope of this docum ent.</t> Any other SvcParamKeys specifying a transport are out of the scope of this docum ent.</t>
</li> </li>
<li> <li>
<t>The destination address for the request <bcp14>SHOULD</bcp14> be taken from additional information about the target. <t>The destination address for the request <bcp14>SHOULD</bcp14> be taken from additional information about the target.
This may include (1) A or AAAA RRs associated with the target name and delivered with the SVCB RR (see <xref target="RFC9462"/>), (2) "ipv4hint" or "ipv6hint" S vcParams from the SVCB RR (see <xref target="RFC9461"/>), or (3) from IPv4 or IP v6 addresses provided if DNR <xref target="RFC9463"/> is used. This may include (1) A or AAAA RRs associated with the target name and delivered with the SVCB RR (see <xref target="RFC9462"/>), (2) "ipv4hint" or "ipv6hint" S vcParams from the SVCB RR (see <xref target="RFC9461"/>), or (3) IPv4 or IPv6 ad dresses provided if DNR <xref target="RFC9463"/> is used.
As a fallback, an address <bcp14>MAY</bcp14> be queried for the target name of t he SVCB record from another DNS service.</t> As a fallback, an address <bcp14>MAY</bcp14> be queried for the target name of t he SVCB record from another DNS service.</t>
</li> </li>
<li> <li>
<t>The destination port for the request <bcp14>MUST</bcp14> be taken from the "port" SvcParam value, if present. <t>The destination port for the request <bcp14>MUST</bcp14> be taken from the "port" SvcParam value, if present.
Otherwise, take the default port of the CoAP transport, e.g., with regards to th is specification TCP port 5684 for "coap" or UDP port 5684 for "co". Otherwise, take the default port of the CoAP transport, e.g., with regards to th is specification, the default is TCP port 5684 for "coap" or UDP port 5684 for " co".
This document introduces no limitations on the ports that can be used. This document introduces no limitations on the ports that can be used.
If a malicious SVCB record allows its originator to influence message payloads, <xref section="12" sectionFormat="of" target="RFC9460"/> recommends placing such restrictions in the SVCB mapping document. If a malicious SVCB record allows its originator to influence message payloads, <xref section="12" sectionFormat="of" target="RFC9460"/> recommends placing such restrictions in the SVCB mapping document.
The records used in this document only infuence the Uri-Path option. The records used in this document only influence the Uri-Path option.
That option is only sent in the plaintext of an encrytped (D)TLS channel, That option is only sent in the plaintext of an encrypted (D)TLS channel
and thus does not warrant any limitations.</t> and thus does not warrant any limitations.</t>
</li> </li>
<li> <li>
<t>The request URI's hostname component <bcp14>MUST</bcp14> be the A uthentication Domain Name (ADN) when obtained through DNR <t>The request URI's hostname component <bcp14>MUST</bcp14> be the A uthentication Domain Name (ADN) when obtained through DNR
and <bcp14>MUST</bcp14> be the target name of the SVCB record when obtained thro ugh a <tt>_dns</tt> query and <bcp14>MUST</bcp14> be the target name of the SVCB record when obtained thro ugh a <tt>_dns</tt> query
(if AliasMode is used, to the target name of the AliasMode record). (if AliasMode is used to the target name of the AliasMode record).
This can be achieved efficiently by setting that name in TLS Server Name Indicat This can be achieved efficiently by setting that name in TLS Server Name Indicat
ion (SNI) <xref target="RFC8446"/>, ion (SNI) <xref target="RFC8446"/>
or by setting the Uri-Host option on each request.</t> or by setting the Uri-Host option on each request.</t>
</li> </li>
<li> <li>
<t>For each element in the CBOR sequence of the "docpath" SvcParam v alue, a Uri-Path option <bcp14>MUST</bcp14> be added to the request.</t> <t>For each element in the CBOR sequence of the "docpath" SvcParam v alue, a Uri-Path option <bcp14>MUST</bcp14> be added to the request.</t>
</li> </li>
<li> <li>
<t>If the request constructed this way receives a response, the same SVCB record <bcp14>MUST</bcp14> be used for construction of future DoC queries. <t>If the request constructed this way receives a response, the same SVCB record <bcp14>MUST</bcp14> be used for construction of future DoC queries.
If not, or if the endpoint becomes unreachable, the algorithm repeats with the S VCB RR or DNR Encrypted DNS option with the next highest Service Priority as a f allback (see Sections <xref target="RFC9460" section="2.4.1" sectionFormat="bare "/> and <xref target="RFC9460" section="3" sectionFormat="bare"/> of <xref targe t="RFC9460"/>).</t> If not, or if the endpoint becomes unreachable, the algorithm repeats with the S VCB RR or DNR Encrypted DNS option with the next highest Service Priority as a f allback (see Sections <xref target="RFC9460" section="2.4.1" sectionFormat="bare "/> and <xref target="RFC9460" section="3" sectionFormat="bare"/> of <xref targe t="RFC9460"/>).</t>
</li> </li>
</ul> </ul>
<t>A more generalized construction algorithm for any CoAP request can be found in <xref target="I-D.ietf-core-transport-indication"/>.</t> <t>A more generalized construction algorithm for any CoAP request can be found in <xref target="I-D.ietf-core-transport-indication"/>.</t>
<section anchor="examples"> <section anchor="examples">
<name>Examples</name> <name>Examples</name>
<t><cref anchor="replace-hex">RFC Ed.: Since the number for "docpath"
was not assigned at the time of writing, we
used the hex <tt>ff 0a</tt> (in decimal 65290; from the private use range of Svc
ParamKeys) throughout
this section. Before publication, please replace <tt>ff 0a</tt> with the hexadec
imal representation of
the final value assigned by IANA in this section. Please remove this paragraph a
fter that.</cref></t>
<t>A typical SVCB resource record response for a DoC server at the roo t path "/" of the server looks <t>A typical SVCB resource record response for a DoC server at the roo t path "/" of the server looks
like the following (the "docpath" SvcParam is the last 4 bytes <tt>ff 0a 00 00</ like the following (the "docpath" SvcParam is the last 4 bytes <tt>00 0a 00 00</
tt> in the binary):</t> tt> in the binary):</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
Resource record (binary): Resource record (binary):
04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72
67 00 00 40 00 01 00 00 06 28 00 1e 00 01 03 64 67 00 00 40 00 01 00 00 06 28 00 1e 00 01 03 64
6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 00 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 00
01 00 03 02 63 6f ff 0a 00 00 01 00 03 02 63 6f 00 0a 00 00
Resource record (human-readable): Resource record (human-readable):
_dns.example.org. 1576 IN SVCB 1 dns.example.org ( _dns.example.org. 1576 IN SVCB 1 dns.example.org (
alpn=co docpath ) alpn=co docpath )
]]></artwork> ]]></sourcecode>
<t>The root path is <bcp14>RECOMMENDED</bcp14> but not required. Here are two examples where the "docpath" represents <t>The root path is <bcp14>RECOMMENDED</bcp14> but not required. Here are two examples where the "docpath" represents
paths of varying depth. First, "/dns" is provided in the following example paths of varying depth. First, "/dns" is provided in the following example
(the last 8 bytes <tt>ff 0a 00 04 03 64 6e 73</tt>):</t> (the last 8 bytes <tt>00 0a 00 04 03 64 6e 73</tt>):</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
Resource record (binary): Resource record (binary):
04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72
67 00 00 40 00 01 00 00 00 55 00 22 00 01 03 64 67 00 00 40 00 01 00 00 00 55 00 22 00 01 03 64
6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 00 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 00
01 00 03 02 63 6f ff 0a 00 04 03 64 6e 73 01 00 03 02 63 6f 00 0a 00 04 03 64 6e 73
Resource record (human-readable): Resource record (human-readable):
_dns.example.org. 85 IN SVCB 1 dns.example.org ( _dns.example.org. 85 IN SVCB 1 dns.example.org (
alpn=co docpath=dns ) alpn=co docpath=dns )
]]></artwork> ]]></sourcecode>
<t>Second, an examples for the path "/n/s" (the last 8 bytes <tt>ff 0a <t>Second, see an example for the path "/n/s" (the last 8 bytes <tt>00
00 04 01 6e 01 73</tt>):</t> 0a 00 04 01 6e 01 73</tt>):</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
Resource record (binary): Resource record (binary):
04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72
67 00 00 40 00 01 00 00 06 6b 00 22 00 01 03 64 67 00 00 40 00 01 00 00 06 6b 00 22 00 01 03 64
6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 00 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 00
01 00 03 02 63 6f ff 0a 00 04 01 6e 01 73 01 00 03 02 63 6f 00 0a 00 04 01 6e 01 73
Resource record (human-readable): Resource record (human-readable):
_dns.example.org. 643 IN SVCB 1 dns.example.org ( _dns.example.org. 1643 IN SVCB 1 dns.example.org (
alpn=co docpath=n,s ) alpn=co docpath=n,s )
]]></artwork> ]]></sourcecode>
<t>If the server also provides DNS over HTTPS, "dohpath" and "docpath" <t>If the server also provides DNS over HTTPS, "dohpath" and "docpath"
<bcp14>MAY</bcp14> co-exist:</t> <bcp14>MAY</bcp14> coexist:</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
Resource record (binary): Resource record (binary):
04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 04 5f 64 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72
67 00 00 40 00 01 00 00 01 ad 00 2b 00 01 03 64 67 00 00 40 00 01 00 00 01 ad 00 2c 00 01 03 64
6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 00 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 00
01 00 06 02 68 33 02 63 6f 00 07 00 07 2f 7b 3f 01 00 06 02 68 33 02 63 6f 00 07 00 07 2f 7b 3f
64 6e 73 7d ff 0a 00 00 64 6e 73 7d 00 0a 00 00
Resource record (human-readable): Resource record (human-readable):
_dns.example.org. 429 IN SVCB 1 dns.example.org ( _dns.example.org. 429 IN SVCB 1 dns.example.org (
alpn=h3,co dohpath=/{?dns} docpath ) alpn=h3,co dohpath=/{?dns} docpath )
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
</section> </section>
<section anchor="basic-message-exchange"> <section anchor="basic-message-exchange">
<name>Basic Message Exchange</name> <name>Basic Message Exchange</name>
<section anchor="sec_content-format"> <section anchor="sec_content-format">
<name>The "application/dns-message" Content-Format</name> <name>The "application/dns-message" Content-Format</name>
<t>This document defines a CoAP Content-Format identifier for the Intern <t>This document defines a CoAP Content-Format ID for the Internet
et media type "application/dns-message" to be the mnemonic 553, based on the port a
media type "application/dns-message" to be the mnemonic 553 — based on the port ssignment of DNS.
assignment of DNS.
This media type is defined as in <xref section="6" sectionFormat="of" target="RF C8484"/>, i.e., a single DNS message encoded in the DNS on-the-wire format <xref target="STD13"/>. This media type is defined as in <xref section="6" sectionFormat="of" target="RF C8484"/>, i.e., a single DNS message encoded in the DNS on-the-wire format <xref target="STD13"/>.
Both DoC client and DoC server <bcp14>MUST</bcp14> be able to parse contents in the "application/dns-message" Content-Format. Both DoC client and DoC server <bcp14>MUST</bcp14> be able to parse contents in the "application/dns-message" Content-Format.
This document only specifies OPCODE 0 (Query) for DNS over CoAP messages. This document only specifies OPCODE 0 (Query) for DNS over CoAP messages.
Future documents can provide considerations for additional OPCODEs or extend its specification (e.g. by describing whether other CoAP codes need to be used for which OPCODE). Future documents can provide considerations for additional OPCODEs or extend its specification (e.g., by describing whether other CoAP codes need to be used for which OPCODE).
Unless another error takes precedence, a DoC server uses RCODE = 4, NotImp <xref target="STD13"/>, in its response to a query with an OPCODE that it does not im plement (see also <xref target="sec_resp-examples"/>).</t> Unless another error takes precedence, a DoC server uses RCODE = 4, NotImp <xref target="STD13"/>, in its response to a query with an OPCODE that it does not im plement (see also <xref target="sec_resp-examples"/>).</t>
</section> </section>
<section anchor="sec_queries"> <section anchor="sec_queries">
<name>DNS Queries in CoAP Requests</name> <name>DNS Queries in CoAP Requests</name>
<t>A DoC client encodes a single DNS query in one or more CoAP request <t>A DoC client encodes a single DNS query in one or more CoAP request
messages that use the CoAP FETCH <xref target="RFC8132"/> request method. messages that use the CoAP FETCH <xref target="RFC8132"/> request method.
Requests <bcp14>SHOULD</bcp14> include an Accept option to indicate the type of content that can be parsed in the response.</t> Requests <bcp14>SHOULD</bcp14> include an Accept option to indicate the type of content that can be parsed in the response.</t>
<t>Since CoAP provides reliability at the message layer (e.g., through C onfirmable messages) the retransmission mechanism of the <t>Since CoAP provides reliability at the message layer (e.g., through C onfirmable messages), the retransmission mechanism of the
DNS protocol as defined in <xref target="STD13"/> is not needed.</t> DNS protocol as defined in <xref target="STD13"/> is not needed.</t>
<section anchor="request-format"> <section anchor="request-format">
<name>Request Format</name> <name>Request Format</name>
<t>When sending a CoAP request, a DoC client <bcp14>MUST</bcp14> inclu de the DNS query in the body of the CoAP request. <t>When sending a CoAP request, a DoC client <bcp14>MUST</bcp14> inclu de the DNS query in the body of the CoAP request.
As specified in <xref section="2.3.1" sectionFormat="of" target="RFC8132"/>, the type of content of the body <bcp14>MUST</bcp14> be indicated using the Content- Format option. As specified in <xref section="2.3.1" sectionFormat="of" target="RFC8132"/>, the type of content of the body <bcp14>MUST</bcp14> be indicated using the Content- Format option.
This document specifies the usage of Content-Format "application/dns-message" (f or details, see <xref target="sec_content-format"/>).</t> This document specifies the usage of Content-Format "application/dns-message" (f or details, see <xref target="sec_content-format"/>).</t>
</section> </section>
<section anchor="sec_req-caching"> <section anchor="sec_req-caching">
<name>Support of CoAP Caching</name> <name>Support of CoAP Caching</name>
<t>The DoC client <bcp14>SHOULD</bcp14> set the ID field of the DNS he ader to 0 to enable a CoAP cache (e.g., a CoAP proxy en-route) to respond to the same DNS queries with a cache entry. <t>The DoC client <bcp14>SHOULD</bcp14> set the ID field of the DNS he ader to 0 to enable a CoAP cache (e.g., a CoAP proxy en route) to respond to the same DNS queries with a cache entry.
This ensures that the CoAP Cache-Key (see <xref section="2" sectionFormat="comma " target="RFC8132"/>) does not change when multiple DNS queries for the same DNS data, carried in CoAP requests, are issued. This ensures that the CoAP Cache-Key (see <xref section="2" sectionFormat="comma " target="RFC8132"/>) does not change when multiple DNS queries for the same DNS data, carried in CoAP requests, are issued.
Apart from losing these caching benefits, there is no harm it not setting it to 0, e.g., when the query was received from somewhere else. Apart from losing these caching benefits, there is no harm in not setting it to 0, e.g., when the query was received from somewhere else.
In any instance, a DoC server <bcp14>MUST</bcp14> copy the ID from the query in its response to that query.</t> In any instance, a DoC server <bcp14>MUST</bcp14> copy the ID from the query in its response to that query.</t>
</section> </section>
<section anchor="sec_req-examples"> <section anchor="sec_req-examples">
<name>Example</name> <name>Example</name>
<t>The following example illustrates the usage of a CoAP message to <t>The following example illustrates the usage of a CoAP message to
resolve "example.org. IN AAAA" based on the URI "coaps://[2001:db8::1]/". The resolve "example.org. IN AAAA" based on the URI "coaps://[2001:db8::1]/". The
CoAP body is encoded in the "application/dns-message" Content-Format.</t> CoAP body is encoded in the "application/dns-message" Content-Format.</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
FETCH coaps://[2001:db8::1]/ FETCH coaps://[2001:db8::1]/
Content-Format: 553 (application/dns-message) Content-Format: 553 (application/dns-message)
Accept: 553 (application/dns-message) Accept: 553 (application/dns-message)
Payload (binary): Payload (binary):
00 00 01 00 00 01 00 00 00 00 00 00 07 65 78 61 00 00 01 00 00 01 00 00 00 00 00 00 07 65 78 61
6d 70 6c 65 03 6f 72 67 00 00 1c 00 01 6d 70 6c 65 03 6f 72 67 00 00 1c 00 01
Payload (human-readable): Payload (human-readable):
;; ->>Header<<- opcode: QUERY, status: NOERROR, id: 0 ;; ->>Header<<- opcode: QUERY, status: NOERROR, id: 0
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION: ;; QUESTION SECTION:
;example.org. IN AAAA ;example.org. IN AAAA
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
<section anchor="dns-responses-in-coap-responses"> <section anchor="dns-responses-in-coap-responses">
<name>DNS Responses in CoAP Responses</name> <name>DNS Responses in CoAP Responses</name>
<t>Each DNS query-response pair is mapped to a CoAP request-response ope ration. <t>Each DNS query-response pair is mapped to a CoAP request-response ope ration.
DNS responses are provided in the body of the CoAP response, i.e., it is also po ssible to transfer them using block-wise transfer <xref target="RFC7959"/>. DNS responses are provided in the body of the CoAP response, i.e., it is also po ssible to transfer them using block-wise transfer <xref target="RFC7959"/>.
A DoC server <bcp14>MUST</bcp14> be able to produce responses in the "applicatio n/dns-message" A DoC server <bcp14>MUST</bcp14> be able to produce responses in the "applicatio n/dns-message"
Content-Format (for details, see <xref target="sec_content-format"/>) when reque sted. Content-Format (for details, see <xref target="sec_content-format"/>) when reque sted.
The use of the Accept option in the request is optional. The use of the Accept option in the request is <bcp14>OPTIONAL</bcp14>.
However, all DoC clients <bcp14>MUST</bcp14> be able to parse a "application/dns However, all DoC clients <bcp14>MUST</bcp14> be able to parse an "application/dn
-message" response (see also <xref target="sec_content-format"/>). s-message" response (see also <xref target="sec_content-format"/>).
Any response Content-Format other than "application/dns-message" <bcp14>MUST</bc p14> be indicated with Any response Content-Format other than "application/dns-message" <bcp14>MUST</bc p14> be indicated with
the Content-Format option by the DoC server.</t> the Content-Format option by the DoC server.</t>
<section anchor="sec_resp-codes"> <section anchor="sec_resp-codes">
<name>Response Codes and Handling DNS and CoAP errors</name> <name>Response Codes and Handling DNS and CoAP Errors</name>
<t>A DNS response indicates either success or failure in the RCODE of the DNS header (see <xref target="STD13"/>). <t>A DNS response indicates either success or failure in the RCODE of the DNS header (see <xref target="STD13"/>).
It is <bcp14>RECOMMENDED</bcp14> that CoAP responses that carry a parseable DNS response use a 2.05 (Content) response code.</t> It is <bcp14>RECOMMENDED</bcp14> that CoAP responses that carry a parsable DNS r esponse use a 2.05 (Content) response code.</t>
<t>CoAP responses using non-successful response codes <bcp14>MUST NOT< /bcp14> contain a DNS response <t>CoAP responses using non-successful response codes <bcp14>MUST NOT< /bcp14> contain a DNS response
and <bcp14>MUST</bcp14> only be used for errors in the CoAP layer or when a requ est does not and <bcp14>MUST</bcp14> only be used for errors in the CoAP layer or when a requ est does not
fulfill the requirements of the DoC protocol.</t> fulfill the requirements of the DoC protocol.</t>
<t>Communication errors with an upstream DNS server (e.g., timeouts) < bcp14>MUST</bcp14> be indicated by including a DNS response with the appropriate RCODE in a successful CoAP response, i.e., using a 2.xx response code. <t>Communication errors with an upstream DNS server (e.g., timeouts) < bcp14>MUST</bcp14> be indicated by including a DNS response with the appropriate RCODE in a successful CoAP response, i.e., using a 2.xx response code.
When an error occurs at the CoAP layer, e.g., if an unexpected request method or an unsupported Content-Format in the request are used, the DoC server <bcp14>SH OULD</bcp14> respond with an appropriate CoAP error.</t> When an error occurs at the CoAP layer, e.g., if an unexpected request method or an unsupported Content-Format in the request are used, the DoC server <bcp14>SH OULD</bcp14> respond with an appropriate CoAP error.</t>
<t>A DoC client might try to repeat a non-successful exchange unless o therwise prohibited. <t>A DoC client might try to repeat a non-successful exchange unless o therwise prohibited.
The DoC client might also decide to repeat a non-successful exchange with a diff erent URI, for instance, when the response indicates an unsupported Content-Form at.</t> The DoC client might also decide to repeat a non-successful exchange with a diff erent URI, for instance, when the response indicates an unsupported Content-Form at.</t>
</section> </section>
<section anchor="sec_resp-caching"> <section anchor="sec_resp-caching">
<name>Support of CoAP Caching</name> <name>Support of CoAP Caching</name>
<t>For reliability and energy saving measures, content decoupling (suc h as en-route caching on proxies) takes a far greater role than it does in HTTP. <t>For reliability and energy-saving measures, content decoupling (suc h as en-route caching on proxies) takes a far greater role than it does in HTTP.
Likewise, CoAP makes it possible to use cache validation to refresh stale cache entries to reduce the number of large response messages. Likewise, CoAP makes it possible to use cache validation to refresh stale cache entries to reduce the number of large response messages.
For cache validation, CoAP implementations regularly use hashing over the messag e content for ETag generation (see <xref section="5.10.6" sectionFormat="comma" target="RFC7252"/>). For cache validation, CoAP implementations regularly use hashing over the messag e content for ETag generation (see <xref section="5.10.6" sectionFormat="comma" target="RFC7252"/>).
As such, the approach to guarantee the same cache key for DNS responses as propo sed in DoH (<xref section="5.1" sectionFormat="comma" target="RFC8484"/>) is not sufficient and needs to be updated so that the TTLs in the response are more of ten the same regardless of query time.</t> As such, the approach to guarantee the same cache key for DNS responses as propo sed in DoH (<xref section="5.1" sectionFormat="comma" target="RFC8484"/>) is not sufficient and needs to be updated so that the TTLs in the response are more of ten the same regardless of query time.</t>
<t>The DoC server <bcp14>MUST</bcp14> ensure that the sum of the Max-A ge value of a CoAP response and any TTL in the <t>The DoC server <bcp14>MUST</bcp14> ensure that the sum of the Max-A ge value of a CoAP response and any TTL in the
DNS response is less than or equal to the corresponding TTL received from an ups tream DNS server. DNS response is less than or equal to the corresponding TTL received from an ups tream DNS server.
This also includes the default Max-Age value of 60 seconds (see <xref section="5 .10.5" sectionFormat="of" target="RFC7252"/>) when no Max-Age option is provided . This also includes the default Max-Age value of 60 seconds (see <xref section="5 .10.5" sectionFormat="of" target="RFC7252"/>) when no Max-Age option is provided .
The DoC client <bcp14>MUST</bcp14> then add the Max-Age value of the carrying Co AP response to all TTLs in a DNS response on reception and use these calculated TTLs for the associated records.</t> The DoC client <bcp14>MUST</bcp14> then add the Max-Age value of the carrying Co AP response to all TTLs in a DNS response on reception and use these calculated TTLs for the associated records.</t>
<t>The <bcp14>RECOMMENDED</bcp14> algorithm for a DoC server to meet t he requirement for DoC is as follows: <t>To meet the requirement for DoC, the <bcp14>RECOMMENDED</bcp14> alg orithm for a DoC server is as follows:
Set the Max-Age option of a response to the minimum TTL of a DNS response and su btract this value from all TTLs of that DNS response. Set the Max-Age option of a response to the minimum TTL of a DNS response and su btract this value from all TTLs of that DNS response.
This prevents expired records unintentionally being served from an intermediate CoAP cache. This prevents expired records from unintentionally being served from an intermed iate CoAP cache.
Additionally, if the ETag for cache validation is based on the content of the re sponse, it allows that ETag not to change. Additionally, if the ETag for cache validation is based on the content of the re sponse, it allows that ETag not to change.
This then remains the case even if the TTL values are updated by an upstream DNS cache. This then remains the case even if the TTL values are updated by an upstream DNS cache.
If only one record set per DNS response is assumed, a simplification of this alg orithm is to just set all TTLs in the response to 0 and set the TTLs at the DoC client to the value of the Max-Age option.</t> If only one record set per DNS response is assumed, a simplification of this alg orithm is to just set all TTLs in the response to 0 and set the TTLs at the DoC client to the value of the Max-Age option.</t>
<t>If shorter caching periods are plausible, e.g., if the RCODE of the message indicates an error that should only be cached for a minimal duration, t he value for the Max-Age option <bcp14>SHOULD</bcp14> be set accordingly. <t>If shorter caching periods are plausible, e.g., if the RCODE of the message indicates an error that should only be cached for a minimal duration, t he value for the Max-Age option <bcp14>SHOULD</bcp14> be set accordingly.
This value might be 0, but if the DoC server knows that the error will persist, greater values are also conceivable, depending on the projected duration of the error. This value might be 0, but if the DoC server knows that the error will persist, greater values are also conceivable, depending on the projected duration of the error.
The same applies for DNS responses that for any reason do not carry any records with a TTL.</t> The same applies for DNS responses that, for any reason, do not carry any record s with a TTL.</t>
</section> </section>
<section anchor="sec_resp-examples"> <section anchor="sec_resp-examples">
<name>Examples</name> <name>Examples</name>
<t>The following example illustrates the response to the query "exampl e.org. IN <t>The following example illustrates the response to the query "exampl e.org. IN
AAAA record", with recursion turned on. Successful responses carry one answer AAAA record", with recursion turned on. Successful responses carry one answer
record including address 2001:db8:1:0:1:2:3:4 and TTL 79689.</t> record including the address 2001:db8:1:0:1:2:3:4 and TTL 79689.</t>
<t>A successful response:</t> <t>A successful response:</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
2.05 Content 2.05 Content
Content-Format: 553 (application/dns-message) Content-Format: 553 (application/dns-message)
Max-Age: 58719 Max-Age: 58719
Payload (human-readable): Payload (human-readable):
;; ->>Header<<- opcode: QUERY, status: NOERROR, id: 0 ;; ->>Header<<- opcode: QUERY, status: NOERROR, id: 0
;; flags: qr rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; flags: qr rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION: ;; QUESTION SECTION:
;example.org. IN AAAA ;example.org. IN AAAA
;; ANSWER SECTION: ;; ANSWER SECTION:
;example.org. 79689 IN AAAA 2001:db8:1:0:1:2:3:4 ;example.org. 79689 IN AAAA 2001:db8:1:0:1:2:3:4
]]></artwork> ]]></sourcecode>
<t>When a DNS error – NxDomain (RCODE = 3) for "does.not.exist" in thi <t>When a DNS error - NxDomain (RCODE = 3) for "does.not.exist" in thi
s case – is noted in the DNS response, the CoAP response still indicates success s case - is noted in the DNS response, the CoAP response still indicates success
.</t> .</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
2.05 Content 2.05 Content
Content-Format: 553 (application/dns-message) Content-Format: 553 (application/dns-message)
Payload (human-readable): Payload (human-readable):
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 0 ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 0
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION: ;; QUESTION SECTION:
;does.not.exist. IN AAAA ;does.not.exist. IN AAAA
]]></artwork> ]]></sourcecode>
<t>As described in <xref target="sec_content-format"/>, a DoC server u <t>As described in <xref target="sec_content-format"/>, a DoC server u
ses NotImp (RCODE = 4) if it does not support an OPCODE—a DNS Update (OPCODE = 5 ses NotImp (RCODE = 4) if it does not support an OPCODE - in this case, it error
) for "example.org" in this case.</t> s on a DNS Update (OPCODE = 5) for "example.org".</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
2.05 Content 2.05 Content
Content-Format: 553 (application/dns-message) Content-Format: 553 (application/dns-message)
Payload (human-readable): Payload (human-readable):
;; ->>Header<<- opcode: UPDATE, status: NOTIMP, id: 0 ;; ->>Header<<- opcode: UPDATE, status: NOTIMP, id: 0
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION: ;; QUERY SECTION:
;example.org. IN AAAA ;example.org. IN AAAA
]]></artwork> ]]></sourcecode>
<t>When an error occurs at the CoAP layer, the DoC server responds wit h <t>When an error occurs at the CoAP layer, the DoC server responds wit h
an appropriate CoAP error, for instance 4.15 (Unsupported Content-Format) an appropriate CoAP error, for instance, 4.15 (Unsupported Content-Format)
if the Content-Format option in the request was not set to if the Content-Format option in the request was not set to
"application/dns-message" and the Content-Format is not otherwise supported by "application/dns-message" and the Content-Format is not otherwise supported by
the server.</t> the server.</t>
<artwork><![CDATA[ <sourcecode><![CDATA[
4.15 Unsupported Content-Format 4.15 Unsupported Content-Format
[no payload] [no payload]
]]></artwork> ]]></sourcecode>
</section> </section>
</section> </section>
</section> </section>
<section anchor="interaction-with-other-coap-and-core-features"> <section anchor="interaction-with-other-coap-and-core-features">
<name>Interaction with other CoAP and CoRE Features</name> <name>Interaction with Other CoAP and CoRE Features</name>
<section anchor="dns-push-notifications-and-coap-observe"> <section anchor="dns-push-notifications-and-coap-observe">
<name>DNS Push Notifications and CoAP Observe</name> <name>DNS Push Notifications and CoAP Observe</name>
<t>DNS Push Notifications <xref target="RFC8765"/> provides the capabili ty to asynchronously notify clients about resource record changes. <t>DNS Push Notifications <xref target="RFC8765"/> provide the capabilit y to asynchronously notify clients about resource record changes.
However, it results in additional overhead, which conflicts with constrained res ources. However, it results in additional overhead, which conflicts with constrained res ources.
This is the reason why it is <bcp14>RECOMMENDED</bcp14> to use CoAP Observe <xre f target="RFC7641"/> instead of DNS Push This is the reason why it is <bcp14>RECOMMENDED</bcp14> to use CoAP Observe <xre f target="RFC7641"/> instead of DNS Push
in the DoC domain. in the DoC domain.
This is particularly useful if a short-lived record is requested frequently. This is particularly useful if a short-lived record is requested frequently.
The DoC server <bcp14>SHOULD</bcp14> provide Observe capabilities on its DoC res ource and do as follows.</t> The DoC server <bcp14>SHOULD</bcp14> provide Observe capabilities on its DoC res ource and do as follows.</t>
<t>If a DoC clients wants to observe a resource record, a DoC server can <t>If a DoC client wants to observe a resource record, a DoC server can
respond with a notification respond with a notification
and add the client to its list of observers for that resource in accordance to < and add the client to its list of observers for that resource in accordance with
xref target="RFC7641"/>. <xref target="RFC7641"/>.
The DoC server <bcp14>MAY</bcp14> subscribe to DNS push notifications for that r The DoC server <bcp14>MAY</bcp14> subscribe to DNS Push Notifications for that r
ecord. ecord.
This involves sending a DNS Subscribe message (see (<xref section="6.2" sectionF This involves sending a DNS Subscribe message (see <xref section="6.2" sectionFo
ormat="of" target="RFC8765"/>), rmat="of" target="RFC8765"/>),
instead of a classic DNS query to fetch the instead of a classic DNS query to fetch the
information on behalf of the DoC client.</t> information on behalf of the DoC client.</t>
<t>After the list of observers for a particular DNS query has become emp ty <t>After the list of observers for a particular DNS query has become emp ty
(by explicit or implicit cancellation of the observation as per <xref section="3 .6" sectionFormat="of" target="RFC7641"/>), (by explicit or implicit cancellation of the observation as per <xref section="3 .6" sectionFormat="of" target="RFC7641"/>),
and no other reason to subscribe to that request is present, and no other reason to subscribe to that request is present,
the DoC server <bcp14>SHOULD</bcp14> cancel the corresponding subscription. the DoC server <bcp14>SHOULD</bcp14> cancel the corresponding subscription.
This can involve sending an DNS Unsubscribe message or closing the session (see This can involve sending a DNS Unsubscribe message or closing the session (see <
<xref section="6.4" sectionFormat="of" target="RFC8765"/>). xref section="6.4" sectionFormat="of" target="RFC8765"/>).
As there is no CoAP observer anymore from the perspective of the DoC server, a f As there is no CoAP observer anymore from the perspective of the DoC server, a f
ailure to do so cannot be communicated back to any DoC observer. ailure to unsubscribe or close the session cannot be communicated back to any Do
C observer.
As such, error handling (if any) needs to be resolved between the DoC server and the upstream DNS infrastructure.</t> As such, error handling (if any) needs to be resolved between the DoC server and the upstream DNS infrastructure.</t>
<t>Whenever the DoC server receives a DNS Push message from the DNS <t>Whenever the DoC server receives a DNS Push message from the DNS
infrastructure for an observed resource record, the DoC server sends an appropri ate Observe notification response infrastructure for an observed resource record, the DoC server sends an appropri ate Observe notification response
to the DoC client.</t> to the DoC client.</t>
<t>A server that responds with notifications (i.e., sends the Observe op <t>A server that responds with notifications (i.e., sends the Observe op
tion) needs to have means of obtaining current resource records. tion) needs to have the means of obtaining current resource records.
This may happen through DNS Push, but also by upstream polling or implicit circu This may happen through DNS Push or also by upstream polling or implicit circums
mstances (e.g., if the DoC server is the authoritative name server for the recor tances (e.g., if the DoC server is the authoritative name server for the record
d and wants to notify about changes).</t> and wants to notify about changes).</t>
</section> </section>
<section anchor="oscore"> <section anchor="oscore">
<name>OSCORE</name> <name>OSCORE</name>
<t>It is <bcp14>RECOMMENDED</bcp14> to carry DNS messages protected usin g OSCORE <xref target="RFC8613"/> between the DoC client <t>It is <bcp14>RECOMMENDED</bcp14> to carry DNS messages protected usin g OSCORE <xref target="RFC8613"/> between the DoC client
and the DoC server. The establishment and maintenance of the OSCORE Security Con text is out of the and the DoC server. The establishment and maintenance of the OSCORE security con text is out of the
scope of this document.</t> scope of this document.</t>
<t><xref target="I-D.amsuess-core-cachable-oscore"/> describes a method to allow cache retrieval of OSCORE responses and discusses <t><xref target="I-D.ietf-core-cacheable-oscore"/> describes a method to allow cache retrieval of OSCORE responses and discusses
the corresponding implications on message sizes and security properties.</t> the corresponding implications on message sizes and security properties.</t>
</section> </section>
<section anchor="mapping-doc-to-doh"> <section anchor="mapping-doc-to-doh">
<name>Mapping DoC to DoH</name> <name>Mapping DoC to DoH</name>
<t>This document provides no specification on how to map between DoC and <t>This document provides no specification on how to map between DoC and
DoH, e.g., at a CoAP-to-HTTP-proxy; such a direct mapping is <bcp14>NOT RECOMME DoH, e.g., at a CoAP-to-HTTP proxy. Such a direct mapping is <bcp14>NOT RECOMME
NDED</bcp14>: NDED</bcp14>:
rewriting the FETCH method (<xref target="sec_queries"/>) and the TTL rewriting Rewriting the FETCH method (<xref target="sec_queries"/>) and TTL (<xref target=
(<xref target="sec_resp-caching"/>) as "sec_resp-caching"/>) as
specified in this draft would be non-trivial. specified in this document would be non-trivial.
It is <bcp14>RECOMMENDED</bcp14> to use a DNS forwarder to map between DoC and D oH, as would be the case for It is <bcp14>RECOMMENDED</bcp14> to use a DNS forwarder to map between DoC and D oH, as would be the case for
mapping between any other pair of DNS transports.</t> mapping between any other pair of DNS transports.</t>
</section> </section>
</section> </section>
<section anchor="sec_unprotected-coap"> <section anchor="sec_unprotected-coap">
<name>Considerations for Unprotected Use</name> <name>Considerations for Unprotected Use</name>
<t>The use of DoC without confidentiality and integrity protection is <bcp 14>NOT RECOMMENDED</bcp14>. <t>The use of DoC without confidentiality and integrity protection is <bcp 14>NOT RECOMMENDED</bcp14>.
Without secure communication, many possible attacks need to be evaluated in the context of Without secure communication, many possible attacks need to be evaluated in the context of
the application's threat model. the application's threat model.
This includes known threats for unprotected DNS <xref target="RFC3833"/> <xref t arget="RFC9076"/> and CoAP <xref section="11" sectionFormat="of" target="RFC7252 "/>. This includes known threats for unprotected DNS <xref target="RFC3833"/> <xref t arget="RFC9076"/> and CoAP (<xref section="11" sectionFormat="of" target="RFC725 2"/>).
While DoC does not use the random ID of the DNS header (see <xref target="sec_re q-caching"/>), equivalent protection against off-path poisoning attacks is achie ved by using random large token values for unprotected CoAP requests. While DoC does not use the random ID of the DNS header (see <xref target="sec_re q-caching"/>), equivalent protection against off-path poisoning attacks is achie ved by using random large token values for unprotected CoAP requests.
If a DoC message is unprotected it <bcp14>MUST</bcp14> use a random token of at If a DoC message is unprotected, it <bcp14>MUST</bcp14> use a random token with
least 2 bytes length to mitigate this kind of poisoning attack.</t> a length of at least 2 bytes to mitigate this kind of poisoning attack.</t>
</section>
<section anchor="implementation-status">
<name>Implementation Status</name>
<t>This section records the status of known implementations of the
protocol defined by this specification at the time of posting of
this Internet-Draft, and is based on a proposal described in
<xref target="RFC7942"/>. The description of implementations in this section is
intended to assist the IETF in its decision processes in
progressing drafts to RFCs. Please note that the listing of any
individual implementation here does not imply endorsement by the
IETF. Furthermore, no effort has been spent to verify the
information presented here that was supplied by IETF contributors.
This is not intended as, and must not be construed to be, a
catalog of available implementations or their features. Readers
are advised to note that other implementations may exist.</t>
<t>According to <xref target="RFC7942"/>, "this will allow reviewers and w
orking
groups to assign due consideration to documents that have the
benefit of running code, which may serve as evidence of valuable
experimentation and feedback that have made the implemented
protocols more mature. It is up to the individual working groups
to use this information as they see fit".
<?line -20?>
</t>
<t><cref anchor="remove-impl-status">RFC Ed.: Please remove this section b
efore publication. When deleting this
section, please also remove RFC7942 from the references of this document.</cref>
</t>
<section anchor="doc-client">
<name>DoC Client</name>
<t>The authors of this document provide a <eref target="https://doc.riot
-os.org/group__net__gcoap__dns.html">DoC client implementation available
in the IoT operating system RIOT</eref>.</t>
<dl>
<dt>Level of maturity:</dt>
<dd>
<t>production</t>
</dd>
<dt>Version compatibility:</dt>
<dd>
<t>draft-ietf-core-dns-over-coap-13</t>
</dd>
<dt>License:</dt>
<dd>
<t>LGPL-2.1</t>
</dd>
<dt>Contact information:</dt>
<dd>
<t><tt>Martine S. Lenders &lt;martine.lenders@tu-dresden.de&gt;</tt>
</t>
</dd>
<dt>Last update of this information:</dt>
<dd>
<t>September 2024</t>
</dd>
</dl>
</section>
<section anchor="doc-server">
<name>DoC Server</name>
<t>The authors of this document provide a <eref target="https://github.c
om/anr-bmbf-pivot/aiodnsprox">DoC server implementation in
Python</eref>.</t>
<dl>
<dt>Level of maturity:</dt>
<dd>
<t>production</t>
</dd>
<dt>Version compatibility:</dt>
<dd>
<t>draft-ietf-core-dns-over-coap-13</t>
</dd>
<dt>License:</dt>
<dd>
<t>MIT</t>
</dd>
<dt>Contact information:</dt>
<dd>
<t><tt>Martine S. Lenders &lt;martine.lenders@tu-dresden.de&gt;</tt>
</t>
</dd>
<dt>Last update of this information:</dt>
<dd>
<t>September 2024</t>
</dd>
</dl>
</section>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>General CoAP security considerations (<xref section="11" sectionFormat= "comma" target="RFC7252"/>) apply to DoC. <t>General CoAP security considerations (<xref section="11" sectionFormat= "comma" target="RFC7252"/>) apply to DoC.
DoC also inherits the security considerations of the protocols used for secure c ommunication, e.g., OSCORE (<xref section="12" sectionFormat="comma" target="RFC 8613"/>) as well as DTLS 1.2 or newer (<xref section="5" sectionFormat="comma" t arget="RFC6347"/> <xref section="11" sectionFormat="comma" target="RFC9147"/>). DoC also inherits the security considerations of the protocols used for secure c ommunication, e.g., OSCORE (<xref section="12" sectionFormat="comma" target="RFC 8613"/>) as well as DTLS 1.2 or newer (<xref section="5" sectionFormat="comma" t arget="RFC6347"/> and <xref section="11" sectionFormat="comma" target="RFC9147"/ >).
Additionally, DoC uses request patterns that require the maintenance of long-liv ed security Additionally, DoC uses request patterns that require the maintenance of long-liv ed security
contexts. contexts.
<xref section="2.6" sectionFormat="of" target="I-D.ietf-core-corr-clar"/> provid <xref section="2.7" sectionFormat="of" target="I-D.ietf-core-corr-clar"/> provid
es insights on what can be done when those are resumed from a new endpoint.</t> es insights on what can be done when those are resumed from a new endpoint.</t>
<t>Though DTLS v1.2 <xref target="RFC6347"/> was obsoleteted by DTLS v1.3 <t>Though DTLS v1.2 <xref target="RFC6347"/> was obsoleted by DTLS v1.3 <x
<xref target="RFC9147"/> there are still many CoAP ref target="RFC9147"/>, there are many CoAP
implementations that still use v1.2 at the time of writing. implementations that still use v1.2 at the time of writing.
As such, this document also accounts for the usage of DTLS v1.2 even though newe r versions are As such, this document also accounts for the usage of DTLS v1.2 even though newe r versions are
<bcp14>RECOMMENDED</bcp14> when using DTLS to secure CoAP.</t> <bcp14>RECOMMENDED</bcp14> when using DTLS to secure CoAP.</t>
<t>When using unprotected CoAP (see <xref target="sec_unprotected-coap"/>) , setting the ID of a DNS message to 0 as <t>When using unprotected CoAP (see <xref target="sec_unprotected-coap"/>) , setting the ID of a DNS message to 0 as
specified in <xref target="sec_req-caching"/> opens the DNS cache of a DoC clien t to cache poisoning attacks specified in <xref target="sec_req-caching"/> opens the DNS cache of a DoC clien t to cache poisoning attacks
via response spoofing. via response spoofing.
This document requires an unpredictable CoAP token in each DoC query from the cl ient when CoAP is This document requires an unpredictable CoAP token in each DoC query from the cl ient when CoAP is
not secured to mitigate such an attack over DoC (see <xref target="sec_unprotect ed-coap"/>).</t> not secured to mitigate such an attack over DoC (see <xref target="sec_unprotect ed-coap"/>).</t>
<t>For secure communication via (D)TLS or OSCORE, an unpredictable ID agai nst spoofing is not necessary. <t>For secure communication via (D)TLS or OSCORE, an unpredictable ID to p rotect against spoofing is not necessary.
Both (D)TLS and OSCORE offer mechanisms to harden against injecting spoofed resp onses in their protocol design. Both (D)TLS and OSCORE offer mechanisms to harden against injecting spoofed resp onses in their protocol design.
Consequently, the ID of the DNS message can be set to 0 without any concern in o rder to leverage the advantages of CoAP caching.</t> Consequently, the ID of the DNS message can be set to 0 without any concern in o rder to leverage the advantages of CoAP caching.</t>
<t>A DoC client must be aware that the DoC server <t>A DoC client must be aware that the DoC server
may communicate unprotected with the upstream DNS infrastructure, e.g., using DN S over UDP. may communicate unprotected with the upstream DNS infrastructure, e.g., using DN S over UDP.
DoC can only guarantee confidentiality and integrity of communication between pa rties for which the DoC can only guarantee confidentiality and integrity of communication between pa rties for which the
security context is exchanged. security context is exchanged.
The DoC server may use another security context to communicate upstream with bot h confidentiality and integrity The DoC server may use another security context to communicate upstream with bot h confidentiality and integrity
(e.g., DNS over QUIC <xref target="RFC9250"/>), but, while recommended, this is opaque to the DoC client on the protocol level. (e.g., DNS over QUIC <xref target="RFC9250"/>); however, while recommended, this is opaque to the DoC client on the protocol level.
Record integrity can also be ensured upstream using DNSSEC <xref target="BCP237" />.</t> Record integrity can also be ensured upstream using DNSSEC <xref target="BCP237" />.</t>
<t>A DoC client may not be able to perform DNSSEC validation, <t>A DoC client may not be able to perform DNSSEC validation,
e.g., due to code size constraints, or due to the size of the responses. e.g., due to code size constraints or the size of the responses.
It may trust its DoC server to perform DNSSEC validation; It may trust its DoC server to perform DNSSEC validation;
how that trust is expressed is out of the scope of this document. how that trust is expressed is out of the scope of this document.
For instance, a DoC client may be, configured to use a particular credential by which it recognizes an eligible DoC server. For instance, a DoC client may be configured to use a particular credential by w hich it recognizes an eligible DoC server.
That information can also imply trust in the DNSSEC validation by that DoC serve r.</t> That information can also imply trust in the DNSSEC validation by that DoC serve r.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t><cref anchor="replace-xxxx">RFC Ed.: throughout this section, please re
place
RFC-XXXX with the RFC number of this specification and remove this
note.</cref></t>
<t>This document has the following actions for IANA.</t>
<section anchor="coap-content-formats-registry"> <section anchor="coap-content-formats-registry">
<name>CoAP Content-Formats Registry</name> <name>CoAP Content-Formats Registry</name>
<t>IANA is requested to assign a CoAP Content-Format ID for the "applica <t>IANA has assigned a CoAP Content-Format ID for the "application/dns-m
tion/dns-message" media essage" media
type in the "CoAP Content-Formats" registry, within the "Constrained RESTful Env type in the "CoAP Content-Formats" registry in the "Constrained RESTful Environm
ironments (CoRE) Parameters" ents (CoRE) Parameters"
registry group <xref target="RFC7252"/>, corresponding to the "application/dns-m registry group <xref target="RFC7252"/>; this corresponds to the "application/dn
essage" media s-message" media
type from the "Media Types" registry (see <xref target="RFC8484"/>).</t> type from the "Media Types" registry (see <xref target="RFC8484"/>).</t>
<t>Content Type: application/dns-message</t> <table anchor="tab-coap-content-format">
<t>Content Coding: -</t> <name>CoAP Content-Format ID</name>
<t>ID: 553 (suggested)</t> <thead>
<t>Reference: <xref target="RFC8484"/> and [RFC-XXXX], <xref target="sec <tr>
_content-format"/></t> <th align="left">Content Type</th>
<th align="left">ID</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">application/dns-message</td>
<td align="left">553</td>
<td align="left">
<xref target="RFC8484"/> and RFC 9953, <xref target="sec_content
-format"/></td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="dns-service-bindings-svcb-registry"> <section anchor="dns-svbc-service-parameter-keys-svcparamkeys-registry">
<name>DNS Service Bindings (SVCB) Registry</name> <name>DNS SVBC Service Parameter Keys (SvcParamKeys) Registry</name>
<t>IANA is requested to add the following entry to the "Service Paramete <t>IANA has added the following entry to the "DNS SVCB Service Parameter
r Keys (SvcParamKeys)" registry within the "DNS Service Bindings (SVCB)" registr Keys (SvcParamKeys)" registry in the "DNS Service Bindings (SVCB)" registry gro
y group. up.
The definition of this parameter can be found in <xref target="sec_doc-server-se lection"/>.</t> The definition of this parameter can be found in <xref target="sec_doc-server-se lection"/>.</t>
<table anchor="tab-svc-param-keys"> <table anchor="tab-svc-param-keys">
<name>Values for SvcParamKeys</name> <name>Value for SvcParamKeys</name>
<thead> <thead>
<tr> <tr>
<th align="left">Number</th> <th align="left">Number</th>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">Meaning</th> <th align="left">Meaning</th>
<th align="left">Change Controller</th> <th align="left">Change Controller</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">10 (suggested)</td> <td align="left">10</td>
<td align="left">docpath</td> <td align="left">docpath</td>
<td align="left">DNS over CoAP resource path</td> <td align="left">DNS over CoAP resource path</td>
<td align="left">IETF</td> <td align="left">IETF</td>
<td align="left">[RFC-XXXX], <xref target="sec_doc-server-selectio n"/></td> <td align="left">RFC 9953, <xref target="sec_doc-server-selection" /></td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="resource-type-rt-link-target-attribute-values-registry"> <section anchor="resource-type-rt-link-target-attribute-values-registry">
<name>Resource Type (rt=) Link Target Attribute Values Registry</name> <name>Resource Type (rt=) Link Target Attribute Values Registry</name>
<t>IANA is requested to add a new Resource Type (rt=) Link Target Attrib <t>IANA has added "core.dns" to the "Resource Type (rt=) Link Target Att
ute "core.dns" to the "Resource Type (rt=) Link Target Attribute Values" registr ribute Values" registry in the "Constrained RESTful Environments (CoRE) Paramete
y within the "Constrained RESTful Environments (CoRE) Parameters" registry group rs" registry group.</t>
.</t> <table anchor="tab-resource-type">
<t>Value: core.dns</t> <name>Resource Type (rt=) Link Target Attribute</name>
<t>Description: DNS over CoAP resource.</t> <thead>
<t>Reference: [RFC-XXXX], <xref target="sec_doc-server-selection"/></t> <tr>
<th align="left">Value</th>
<th align="left">Description</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">core.dns</td>
<td align="left">DNS over CoAP resource</td>
<td align="left">RFC 9953, <xref target="sec_doc-server-selection"
/></td>
</tr>
</tbody>
</table>
</section> </section>
</section> </section>
<section anchor="operational-considerations"> <section anchor="operational-considerations">
<name>Operational Considerations</name> <name>Operational Considerations</name>
<section anchor="co-existence-of-different-dns-and-coap-transports"> <section anchor="coexistence-of-different-dns-and-coap-transports">
<name>Co-existence of different DNS and CoAP transports</name> <name>Coexistence of Different DNS and CoAP Transports</name>
<t>Many DNS transports may co-exist on the DoC server, such as DNS over <t>Many DNS transports may coexist on the DoC server, such as DNS over U
UDP <xref target="STD13"/>, DNS over (D)TLS <xref target="RFC7858"/> <xref targe DP <xref target="STD13"/>, DNS over (D)TLS <xref target="RFC7858"/> <xref target
t="RFC8094"/>, DNS over HTTPS <xref target="RFC8484"/>, or DNS over QUIC <xref t ="RFC8094"/>, DNS over HTTPS <xref target="RFC8484"/>, or DNS over QUIC <xref ta
arget="RFC9250"/>. rget="RFC9250"/>.
In principle, transports employing channel or object security should be preferre d. In principle, transports employing channel or object security should be preferre d.
In constrained scenarios, DNS over CoAP is preferable to DNS over DTLS. In constrained scenarios, DNS over CoAP is preferable to DNS over DTLS.
The final decision regarding the preference, however, heavily depends on the use case and is therefore left to the implementers or users and is not defined in t his document.</t> The final decision regarding the preference, however, heavily depends on the use case and is therefore left to the implementers or users and is not defined in t his document.</t>
<t>CoAP supports Confirmable and Non-Confirmable messages <xref target=" RFC7252"/> to deploy different levels of reliability. <t>CoAP supports Confirmable and Non-Confirmable messages <xref target=" RFC7252"/> to deploy different levels of reliability.
This document, however, does not enforce any of these message types, as the deci sion on which one is appropriate depends on the characteristics of the network w here DoC is deployed.</t> However, this document does not enforce any of these message types, as the decis ion on which one is appropriate depends on the characteristics of the network wh ere DoC is deployed.</t>
</section> </section>
<section anchor="redirects"> <section anchor="redirects">
<name>Redirects</name> <name>Redirects</name>
<t>Application-layer redirects (e.g., HTTP) redirct a client to a new se rver. <t>Application-layer redirects (e.g., HTTP) redirect a client to a new s erver.
In the case of DoC, this leads to a new DNS server. In the case of DoC, this leads to a new DNS server.
This new DNS server may provide different answers to the same DNS query than the previous DNS server. This new DNS server may provide different answers to the same DNS query than the previous DNS server.
At the time of writing, CoAP does not support redirection. At the time of writing, CoAP does not support redirection.
Future specifications of CoAP redirect may need to consider the impact of differ ent results between previous and new DNS server.</t> Future specifications of CoAP redirect may need to consider the impact of differ ent results between previous and new DNS servers.</t>
</section> </section>
<section anchor="proxy-hop-limit"> <section anchor="proxy-hop-limit">
<name>Proxy Hop-Limit</name> <name>Proxy Hop Limit</name>
<t>Mistakes might lead to CoAP proxies forming infinite loops. <t>Mistakes might lead to CoAP proxies forming infinite loops.
Using the CoAP Hop-Limit option <xref target="RFC8768"/> mitigates such loops.</ t> Using the CoAP Hop-Limit option <xref target="RFC8768"/> mitigates such loops.</ t>
</section> </section>
<section anchor="error-handling"> <section anchor="error-handling">
<name>Error Handling</name> <name>Error Handling</name>
<t><xref target="sec_resp-codes"/> specifies that DNS operational errors should be reported back to a DoC client <t><xref target="sec_resp-codes"/> specifies that DNS operational errors should be reported back to a DoC client
using the appropriate DNS RCODE. using the appropriate DNS RCODE.
If a DoC client did not receive any successful DNS message from a DoC server for a while, it might If a DoC client did not receive any successful DNS messages from a DoC server fo r a while, it might
indicate that the DoC server lost connectivity to the upstream DNS infrastructur e. indicate that the DoC server lost connectivity to the upstream DNS infrastructur e.
The DoC client should handle this error case like a recursive resolver that lost connectivity to the upstream DNS infrastructure. The DoC client should handle this error case like a recursive resolver that lost connectivity to the upstream DNS infrastructure.
In case of CoAP errors, the usual mechanisms for CoAP response codes apply.</t> In case of CoAP errors, the usual mechanisms for CoAP response codes apply.</t>
</section> </section>
<section anchor="dns-extensions"> <section anchor="dns-extensions">
<name>DNS Extensions</name> <name>DNS Extensions</name>
<t>DNS extensions that are specific to the choice of transport, such as <xref target="RFC7828"/>, are not applicable to DoC.</t> <t>DNS extensions that are specific to the choice of transport, such as described in <xref target="RFC7828"/>, are not applicable to DoC.</t>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-core-href" to="CRI"/>
<displayreference target="I-D.ietf-core-transport-indication" to="TRANSPORT-
IND"/>
<displayreference target="I-D.ietf-iotops-7228bis" to="RFC7228bis"/>
<displayreference target="I-D.ietf-core-cacheable-oscore" to="CACHEABLE-OSCO
RE"/>
<displayreference target="I-D.ietf-core-corr-clar" to="CoAP-CORR-CLAR"/>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<referencegroup anchor="STD13" target="https://www.rfc-editor.org/info/s td13"> <referencegroup anchor="STD13" target="https://www.rfc-editor.org/info/s td13">
<reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rf <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
c1034"> .1034.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
<title>Domain names - concepts and facilities</title> .1035.xml"/>
<author fullname="P. Mockapetris" initials="P." surname="Mockapetr
is"/>
<date month="November" year="1987"/>
<abstract>
<t>This RFC is the revised basic definition of The Domain Name S
ystem. It obsoletes RFC-882. This memo describes the domain style names and thei
r used for host address look up and electronic mail forwarding. It discusses the
clients and servers in the domain name system and the protocol used between the
m.</t>
</abstract>
</front>
<seriesInfo name="STD" value="13"/>
<seriesInfo name="RFC" value="1034"/>
<seriesInfo name="DOI" value="10.17487/RFC1034"/>
</reference>
<reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rf
c1035">
<front>
<title>Domain names - implementation and specification</title>
<author fullname="P. Mockapetris" initials="P." surname="Mockapetr
is"/>
<date month="November" year="1987"/>
<abstract>
<t>This RFC is the revised specification of the protocol and for
mat used in the implementation of the Domain Name System. It obsoletes RFC-883.
This memo documents the details of the domain name client - server communication
.</t>
</abstract>
</front>
<seriesInfo name="STD" value="13"/>
<seriesInfo name="RFC" value="1035"/>
<seriesInfo name="DOI" value="10.17487/RFC1035"/>
</reference>
</referencegroup> </referencegroup>
<reference anchor="RFC3986"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<front> 986.xml"/>
<title>Uniform Resource Identifier (URI): Generic Syntax</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee 234.xml"/>
"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<author fullname="R. Fielding" initials="R." surname="Fielding"/> 347.xml"/>
<author fullname="L. Masinter" initials="L." surname="Masinter"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<date month="January" year="2005"/> 252.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<t>A Uniform Resource Identifier (URI) is a compact sequence of ch 641.xml"/>
aracters that identifies an abstract or physical resource. This specification de <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
fines the generic URI syntax and a process for resolving URI references that mig 959.xml"/>
ht be in relative form, along with guidelines and security considerations for th <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
e use of URIs on the Internet. The URI syntax defines a grammar that is a supers 132.xml"/>
et of all valid URIs, allowing an implementation to parse the common components <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
of a URI reference without knowing the scheme-specific requirements of every pos 323.xml"/>
sible identifier. This specification does not define a generative grammar for UR <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
Is; that task is performed by the individual specifications of each URI scheme. 484.xml"/>
[STANDARDS-TRACK]</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
</abstract> 613.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<seriesInfo name="STD" value="66"/> 765.xml"/>
<seriesInfo name="RFC" value="3986"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<seriesInfo name="DOI" value="10.17487/RFC3986"/> 768.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<reference anchor="RFC5234"> 949.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<title>Augmented BNF for Syntax Specifications: ABNF</title> 147.xml"/>
<author fullname="D. Crocker" initials="D." role="editor" surname="C <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
rocker"/> 460.xml"/>
<author fullname="P. Overell" initials="P." surname="Overell"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<date month="January" year="2008"/> 461.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<t>Internet technical specifications often need to define a formal 462.xml"/>
syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Au <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
gmented BNF (ABNF), has been popular among many Internet specifications. The cur 463.xml"/>
rent specification documents ABNF. It balances compactness and simplicity with r <reference anchor="PRE-RFC9952" target="https://www.rfc-editor.org/info/
easonable representational power. The differences between standard BNF and ABNF rfc9952">
involve naming rules, repetition, alternatives, order-independence, and value ra
nges. This specification also supplies additional rule definitions and encoding
for a core lexical analyzer of the type common to several Internet specification
s. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="68"/>
<seriesInfo name="RFC" value="5234"/>
<seriesInfo name="DOI" value="10.17487/RFC5234"/>
</reference>
<reference anchor="RFC6347">
<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<author fullname="N. Modadugu" initials="N." surname="Modadugu"/>
<date month="January" year="2012"/>
<abstract>
<t>This document specifies version 1.2 of the Datagram Transport L
ayer Security (DTLS) protocol. The DTLS protocol provides communications privacy
for datagram protocols. The protocol allows client/server applications to commu
nicate in a way that is designed to prevent eavesdropping, tampering, or message
forgery. The DTLS protocol is based on the Transport Layer Security (TLS) proto
col and provides equivalent security guarantees. Datagram semantics of the under
lying transport are preserved by the DTLS protocol. This document updates DTLS 1
.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6347"/>
<seriesInfo name="DOI" value="10.17487/RFC6347"/>
</reference>
<reference anchor="RFC7252">
<front>
<title>The Constrained Application Protocol (CoAP)</title>
<author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
<author fullname="K. Hartke" initials="K." surname="Hartke"/>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<date month="June" year="2014"/>
<abstract>
<t>The Constrained Application Protocol (CoAP) is a specialized we
b transfer protocol for use with constrained nodes and constrained (e.g., low-po
wer, lossy) networks. The nodes often have 8-bit microcontrollers with small amo
unts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wire
less 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-ma
chine (M2M) applications such as smart energy and building automation.</t>
<t>CoAP provides a request/response interaction model between appl
ication endpoints, supports built-in discovery of services and resources, and in
cludes key concepts of the Web such as URIs and Internet media types. CoAP is de
signed to easily interface with HTTP for integration with the Web while meeting
specialized requirements such as multicast support, very low overhead, and simpl
icity for constrained environments.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7252"/>
<seriesInfo name="DOI" value="10.17487/RFC7252"/>
</reference>
<reference anchor="RFC7641">
<front>
<title>Observing Resources in the Constrained Application Protocol (
CoAP)</title>
<author fullname="K. Hartke" initials="K." surname="Hartke"/>
<date month="September" year="2015"/>
<abstract>
<t>The Constrained Application Protocol (CoAP) is a RESTful applic
ation protocol for constrained nodes and networks. The state of a resource on a
CoAP server can change over time. This document specifies a simple protocol exte
nsion for CoAP that enables CoAP clients to "observe" resources, i.e., to retrie
ve a representation of a resource and keep this representation updated by the se
rver over a period of time. The protocol follows a best-effort approach for send
ing new representations to clients and provides eventual consistency between the
state observed by each client and the actual resource state at the server.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7641"/>
<seriesInfo name="DOI" value="10.17487/RFC7641"/>
</reference>
<reference anchor="RFC7959">
<front>
<title>Block-Wise Transfers in the Constrained Application Protocol
(CoAP)</title>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="Z. Shelby" initials="Z." role="editor" surname="Sh
elby"/>
<date month="August" year="2016"/>
<abstract>
<t>The Constrained Application Protocol (CoAP) is a RESTful transf
er protocol for constrained nodes and networks. Basic CoAP messages work well fo
r small payloads from sensors and actuators; however, applications will need to
transfer larger payloads occasionally -- for instance, for firmware updates. In
contrast to HTTP, where TCP does the grunt work of segmenting and resequencing,
CoAP is based on datagram transports such as UDP or Datagram Transport Layer Sec
urity (DTLS). These transports only offer fragmentation, which is even more prob
lematic in constrained nodes and networks, limiting the maximum size of resource
representations that can practically be transferred.</t>
<t>Instead of relying on IP fragmentation, this specification exte
nds basic CoAP with a pair of "Block" options for transferring multiple blocks o
f information from a resource representation in multiple request-response pairs.
In many important cases, the Block options enable a server to be truly stateles
s: the server can handle each block transfer separately, with no need for a conn
ection setup or other server-side memory of previous block transfers. Essentiall
y, the Block options provide a minimal way to transfer larger representations in
a block-wise fashion.</t>
<t>A CoAP implementation that does not support these options gener
ally is limited in the size of the representations that can be exchanged, so the
re is an expectation that the Block options will be widely used in CoAP implemen
tations. Therefore, this specification updates RFC 7252.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7959"/>
<seriesInfo name="DOI" value="10.17487/RFC7959"/>
</reference>
<reference anchor="RFC8132">
<front>
<title>PATCH and FETCH Methods for the Constrained Application Proto
col (CoAP)</title>
<author fullname="P. van der Stok" initials="P." surname="van der St
ok"/>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="A. Sehgal" initials="A." surname="Sehgal"/>
<date month="April" year="2017"/>
<abstract>
<t>The methods defined in RFC 7252 for the Constrained Application
Protocol (CoAP) only allow access to a complete resource, not to parts of a res
ource. In case of resources with larger or complex data, or in situations where
resource continuity is required, replacing or requesting the whole resource is u
ndesirable. Several applications using CoAP need to access parts of the resource
s.</t>
<t>This specification defines the new CoAP methods, FETCH, PATCH,
and iPATCH, which are used to access and update parts of a resource.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8132"/>
<seriesInfo name="DOI" value="10.17487/RFC8132"/>
</reference>
<reference anchor="RFC8323">
<front>
<title>CoAP (Constrained Application Protocol) over TCP, TLS, and We
bSockets</title>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="S. Lemay" initials="S." surname="Lemay"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
>
<author fullname="K. Hartke" initials="K." surname="Hartke"/>
<author fullname="B. Silverajan" initials="B." surname="Silverajan"/
>
<author fullname="B. Raymor" initials="B." role="editor" surname="Ra
ymor"/>
<date month="February" year="2018"/>
<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 do
cument outlines the changes required to use CoAP over TCP, TLS, and WebSockets t
ransports. It also formally updates RFC 7641 for use with these transports and R
FC 7959 to enable the use of larger messages over a reliable transport.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8323"/>
<seriesInfo name="DOI" value="10.17487/RFC8323"/>
</reference>
<reference anchor="RFC8484">
<front>
<title>DNS Queries over HTTPS (DoH)</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<author fullname="P. McManus" initials="P." surname="McManus"/>
<date month="October" year="2018"/>
<abstract>
<t>This document defines a protocol for sending DNS queries and ge
tting DNS responses over HTTPS. Each DNS query-response pair is mapped into an H
TTP exchange.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8484"/>
<seriesInfo name="DOI" value="10.17487/RFC8484"/>
</reference>
<reference anchor="RFC8613">
<front>
<title>Object Security for Constrained RESTful Environments (OSCORE)
</title>
<author fullname="G. Selander" initials="G." surname="Selander"/>
<author fullname="J. Mattsson" initials="J." surname="Mattsson"/>
<author fullname="F. Palombini" initials="F." surname="Palombini"/>
<author fullname="L. Seitz" initials="L." surname="Seitz"/>
<date month="July" year="2019"/>
<abstract>
<t>This document defines Object Security for Constrained RESTful E
nvironments (OSCORE), a method for application-layer protection of the Constrain
ed Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE).
OSCORE provides end-to-end protection between endpoints communicating using CoA
P or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks s
upporting a range of proxy operations, including translation between different t
ransport protocols.</t>
<t>Although an optional functionality of CoAP, OSCORE alters CoAP
options processing and IANA registration. Therefore, this document updates RFC 7
252.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8613"/>
<seriesInfo name="DOI" value="10.17487/RFC8613"/>
</reference>
<reference anchor="RFC8765">
<front>
<title>DNS Push Notifications</title>
<author fullname="T. Pusateri" initials="T." surname="Pusateri"/>
<author fullname="S. Cheshire" initials="S." surname="Cheshire"/>
<date month="June" year="2020"/>
<abstract>
<t>The Domain Name System (DNS) was designed to return matching re
cords efficiently for queries for data that are relatively static. When those re
cords change frequently, DNS is still efficient at returning the updated results
when polled, as long as the polling rate is not too high. But, there exists no
mechanism for a client to be asynchronously notified when these changes occur. T
his document defines a mechanism for a client to be notified of such changes to
DNS records, called DNS Push Notifications.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8765"/>
<seriesInfo name="DOI" value="10.17487/RFC8765"/>
</reference>
<reference anchor="RFC8768">
<front>
<title>Constrained Application Protocol (CoAP) Hop-Limit Option</tit
le>
<author fullname="M. Boucadair" initials="M." surname="Boucadair"/>
<author fullname="T. Reddy.K" initials="T." surname="Reddy.K"/>
<author fullname="J. Shallow" initials="J." surname="Shallow"/>
<date month="March" year="2020"/>
<abstract>
<t>The presence of Constrained Application Protocol (CoAP) proxies
may lead to infinite forwarding loops, which is undesirable. To prevent and det
ect such loops, this document specifies the Hop-Limit CoAP option.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8768"/>
<seriesInfo name="DOI" value="10.17487/RFC8768"/>
</reference>
<reference anchor="RFC8949">
<front>
<title>Concise Binary Object Representation (CBOR)</title>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<date month="December" year="2020"/>
<abstract>
<t>The Concise Binary Object Representation (CBOR) is a data forma
t whose design goals include the possibility of extremely small code size, fairl
y small message size, and extensibility without the need for version negotiation
. These design goals make it different from earlier binary serializations such a
s ASN.1 and MessagePack.</t>
<t>This document obsoletes RFC 7049, providing editorial improveme
nts, new details, and errata fixes while keeping full compatibility with the int
erchange format of RFC 7049. It does not create a new version of the format.</t>
</abstract>
</front>
<seriesInfo name="STD" value="94"/>
<seriesInfo name="RFC" value="8949"/>
<seriesInfo name="DOI" value="10.17487/RFC8949"/>
</reference>
<reference anchor="RFC9147">
<front>
<title>The Datagram Transport Layer Security (DTLS) Protocol Version
1.3</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
>
<author fullname="N. Modadugu" initials="N." surname="Modadugu"/>
<date month="April" year="2022"/>
<abstract>
<t>This document specifies version 1.3 of the Datagram Transport L
ayer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to com
municate over the Internet in a way that is designed to prevent eavesdropping, t
ampering, and message forgery.</t>
<t>The DTLS 1.3 protocol is based on the Transport Layer Security
(TLS) 1.3 protocol and provides equivalent security guarantees with the exceptio
n of order protection / non-replayability. Datagram semantics of the underlying
transport are preserved by the DTLS protocol.</t>
<t>This document obsoletes RFC 6347.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9147"/>
<seriesInfo name="DOI" value="10.17487/RFC9147"/>
</reference>
<reference anchor="RFC9460">
<front>
<title>Service Binding and Parameter Specification via the DNS (SVCB
and HTTPS Resource Records)</title>
<author fullname="B. Schwartz" initials="B." surname="Schwartz"/>
<author fullname="M. Bishop" initials="M." surname="Bishop"/>
<author fullname="E. Nygren" initials="E." surname="Nygren"/>
<date month="November" year="2023"/>
<abstract>
<t>This document specifies the "SVCB" ("Service Binding") and "HTT
PS" DNS resource record (RR) types to facilitate the lookup of information neede
d to make connections to network services, such as for HTTP origins. SVCB record
s allow a service to be provided from multiple alternative endpoints, each with
associated parameters (such as transport protocol configuration), and are extens
ible to support future uses (such as keys for encrypting the TLS ClientHello). T
hey also enable aliasing of apex domains, which is not possible with CNAME. The
HTTPS RR is a variation of SVCB for use with HTTP (see RFC 9110, "HTTP Semantics
"). By providing more information to the client before it attempts to establish
a connection, these records offer potential benefits to both performance and pri
vacy.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9460"/>
<seriesInfo name="DOI" value="10.17487/RFC9460"/>
</reference>
<reference anchor="RFC9461">
<front>
<title>Service Binding Mapping for DNS Servers</title>
<author fullname="B. Schwartz" initials="B." surname="Schwartz"/>
<date month="November" year="2023"/>
<abstract>
<t>The SVCB DNS resource record type expresses a bound collection
of endpoint metadata, for use when establishing a connection to a named service.
DNS itself can be such a service, when the server is identified by a domain nam
e. This document provides the SVCB mapping for named DNS servers, allowing them
to indicate support for encrypted transport protocols.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9461"/>
<seriesInfo name="DOI" value="10.17487/RFC9461"/>
</reference>
<reference anchor="RFC9462">
<front>
<title>Discovery of Designated Resolvers</title>
<author fullname="T. Pauly" initials="T." surname="Pauly"/>
<author fullname="E. Kinnear" initials="E." surname="Kinnear"/>
<author fullname="C. A. Wood" initials="C. A." surname="Wood"/>
<author fullname="P. McManus" initials="P." surname="McManus"/>
<author fullname="T. Jensen" initials="T." surname="Jensen"/>
<date month="November" year="2023"/>
<abstract>
<t>This document defines Discovery of Designated Resolvers (DDR),
a set of mechanisms for DNS clients to use DNS records to discover a resolver's
encrypted DNS configuration. An Encrypted DNS Resolver discovered in this manner
is referred to as a "Designated Resolver". These mechanisms can be used to move
from unencrypted DNS to encrypted DNS when only the IP address of a resolver is
known. These mechanisms are designed to be limited to cases where Unencrypted D
NS Resolvers and their Designated Resolvers are operated by the same entity or c
ooperating entities. It can also be used to discover support for encrypted DNS p
rotocols when the name of an Encrypted DNS Resolver is known.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9462"/>
<seriesInfo name="DOI" value="10.17487/RFC9462"/>
</reference>
<reference anchor="RFC9463">
<front>
<title>DHCP and Router Advertisement Options for the Discovery of Ne
twork-designated Resolvers (DNR)</title>
<author fullname="M. Boucadair" initials="M." role="editor" surname=
"Boucadair"/>
<author fullname="T. Reddy.K" initials="T." role="editor" surname="R
eddy.K"/>
<author fullname="D. Wing" initials="D." surname="Wing"/>
<author fullname="N. Cook" initials="N." surname="Cook"/>
<author fullname="T. Jensen" initials="T." surname="Jensen"/>
<date month="November" year="2023"/>
<abstract>
<t>This document specifies new DHCP and IPv6 Router Advertisement
options to discover encrypted DNS resolvers (e.g., DNS over HTTPS, DNS over TLS,
and DNS over QUIC). Particularly, it allows a host to learn an Authentication D
omain Name together with a list of IP addresses and a set of service parameters
to reach such encrypted DNS resolvers.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9463"/>
<seriesInfo name="DOI" value="10.17487/RFC9463"/>
</reference>
<reference anchor="I-D.ietf-core-coap-dtls-alpn">
<front> <front>
<title>ALPN ID Specification for CoAP over DTLS</title> <title>The Application-Layer Protocol Negotiation (ALPN) ID Specific
<author fullname="Martine Sophie Lenders" initials="M. S." surname=" ation for the Constrained Application Protocol (CoAP) over DTLS</title>
Lenders"> <author initials="M. S." surname="Lenders" fullname="Martine Sophie
<organization>TUD Dresden University of Technology</organization> Lenders">
<organization/>
</author> </author>
<author fullname="Christian Amsüss" initials="C." surname="Amsüss"> <author initials="C." surname="Amsüss" fullname="Christian Amsüss">
</author> <organization/>
<author fullname="Thomas C. Schmidt" initials="T. C." surname="Schmi
dt">
<organization>HAW Hamburg</organization>
</author> </author>
<author fullname="Matthias Wählisch" initials="M." surname="Wählisch <author initials="T. C." surname="Schmidt" fullname="Thomas C. Schmi
"> dt">
<organization>TUD Dresden University of Technology &amp; Barkhause <organization/>
n Institut</organization>
</author> </author>
<date day="11" month="August" year="2025"/> <author initials="M." surname="Wählisch" fullname="Matthias Wählisch
<abstract> ">
<t> This document specifies an Application-Layer Protocol Negoti <organization/>
ation </author>
(ALPN) ID for transport-layer-secured Constrained Application <date year="2026" month="March"/>
Protocol (CoAP) services.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-core-coap-dtls-alp
n-05"/>
</reference>
<reference anchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front> </front>
<seriesInfo name="BCP" value="14"/> <seriesInfo name="RFC" value="PRE-9952"/>
<seriesInfo name="RFC" value="8174"/> <seriesInfo name="DOI" value="10.17487/PRE-RFC9952"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<referencegroup anchor="BCP219" target="https://www.rfc-editor.org/info/ bcp219"> <referencegroup anchor="BCP219" target="https://www.rfc-editor.org/info/ bcp219">
<reference anchor="RFC9499" target="https://www.rfc-editor.org/info/rf <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
c9499"> .9499.xml"/>
<front>
<title>DNS Terminology</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<author fullname="K. Fujiwara" initials="K." surname="Fujiwara"/>
<date month="March" year="2024"/>
<abstract>
<t>The Domain Name System (DNS) is defined in literally dozens o
f different RFCs. The terminology used by implementers and developers of DNS pro
tocols, and by operators of DNS systems, has changed in the decades since the DN
S was first defined. This document gives current definitions for many of the ter
ms used in the DNS in a single document.</t>
<t>This document updates RFC 2308 by clarifying the definitions
of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and c
larifications. Comprehensive lists of changed and new definitions can be found i
n Appendices A and B.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="219"/>
<seriesInfo name="RFC" value="9499"/>
<seriesInfo name="DOI" value="10.17487/RFC9499"/>
</reference>
</referencegroup> </referencegroup>
<referencegroup anchor="BCP237" target="https://www.rfc-editor.org/info/ bcp237"> <referencegroup anchor="BCP237" target="https://www.rfc-editor.org/info/ bcp237">
<reference anchor="RFC9364" target="https://www.rfc-editor.org/info/rf <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC
c9364"> .9364.xml"/>
<front>
<title>DNS Security Extensions (DNSSEC)</title>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<date month="February" year="2023"/>
<abstract>
<t>This document describes the DNS Security Extensions (commonly
called "DNSSEC") that are specified in RFCs 4033, 4034, and 4035, as well as a
handful of others. One purpose is to introduce all of the RFCs in one place so t
hat the reader can understand the many aspects of DNSSEC. This document does not
update any of those RFCs. A second purpose is to state that using DNSSEC for or
igin authentication of DNS data is the best current practice. A third purpose is
to provide a single reference for other documents that want to refer to DNSSEC.
</t>
</abstract>
</front>
<seriesInfo name="BCP" value="237"/>
<seriesInfo name="RFC" value="9364"/>
<seriesInfo name="DOI" value="10.17487/RFC9364"/>
</reference>
</referencegroup> </referencegroup>
<reference anchor="RFC3833"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<front> 833.xml"/>
<title>Threat Analysis of the Domain Name System (DNS)</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<author fullname="D. Atkins" initials="D." surname="Atkins"/> 690.xml"/>
<author fullname="R. Austein" initials="R." surname="Austein"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<date month="August" year="2004"/> 228.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<t>Although the DNS Security Extensions (DNSSEC) have been under d 858.xml"/>
evelopment for most of the last decade, the IETF has never written down the spec <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
ific set of threats against which DNSSEC is designed to protect. Among other dra 094.xml"/>
wbacks, this cart-before-the-horse situation has made it difficult to determine <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
whether DNSSEC meets its design goals, since its design goals are not well speci 076.xml"/>
fied. This note attempts to document some of the known threats to the DNS, and, <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool 176.xml"/>
in defending against these threats. This memo provides information for the Inte <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
rnet community.</t> 250.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
</front> 528.xml"/>
<seriesInfo name="RFC" value="3833"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<seriesInfo name="DOI" value="10.17487/RFC3833"/> ietf-core-href.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<reference anchor="RFC6690"> ietf-core-transport-indication.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<title>Constrained RESTful Environments (CoRE) Link Format</title> ietf-iotops-7228bis.xml"/>
<author fullname="Z. Shelby" initials="Z." surname="Shelby"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.
<date month="August" year="2012"/> ietf-core-cacheable-oscore.xml"/>
<abstract>
<t>This specification defines Web Linking using a link format for
use by constrained web servers to describe hosted resources, their attributes, a
nd other relationships between links. Based on the HTTP Link Header field define
d in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carrie
d as a payload and is assigned an Internet media type. "RESTful" refers to the R
epresentational 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>
<seriesInfo name="RFC" value="6690"/>
<seriesInfo name="DOI" value="10.17487/RFC6690"/>
</reference>
<reference anchor="RFC7228">
<front>
<title>Terminology for Constrained-Node Networks</title>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="M. Ersue" initials="M." surname="Ersue"/>
<author fullname="A. Keranen" initials="A." surname="Keranen"/>
<date month="May" year="2014"/>
<abstract>
<t>The Internet Protocol Suite is increasingly used on small devic
es with severe constraints on power, memory, and processing resources, creating
constrained-node networks. This document provides a number of basic terms that h
ave been useful in the standardization work for constrained-node networks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7228"/>
<seriesInfo name="DOI" value="10.17487/RFC7228"/>
</reference>
<reference anchor="RFC7858">
<front>
<title>Specification for DNS over Transport Layer Security (TLS)</ti
tle>
<author fullname="Z. Hu" initials="Z." surname="Hu"/>
<author fullname="L. Zhu" initials="L." surname="Zhu"/>
<author fullname="J. Heidemann" initials="J." surname="Heidemann"/>
<author fullname="A. Mankin" initials="A." surname="Mankin"/>
<author fullname="D. Wessels" initials="D." surname="Wessels"/>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<date month="May" year="2016"/>
<abstract>
<t>This document describes the use of Transport Layer Security (TL
S) to provide privacy for DNS. Encryption provided by TLS eliminates opportuniti
es for eavesdropping and on-path tampering with DNS queries in the network, such
as discussed in RFC 7626. In addition, this document specifies two usage profil
es for DNS over TLS and provides advice on performance considerations to minimiz
e overhead from using TCP and TLS with DNS.</t>
<t>This document focuses on securing stub-to-recursive traffic, as
per the charter of the DPRIVE Working Group. It does not prevent future applica
tions of the protocol to recursive-to-authoritative traffic.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7858"/>
<seriesInfo name="DOI" value="10.17487/RFC7858"/>
</reference>
<reference anchor="RFC8094">
<front>
<title>DNS over Datagram Transport Layer Security (DTLS)</title>
<author fullname="T. Reddy" initials="T." surname="Reddy"/>
<author fullname="D. Wing" initials="D." surname="Wing"/>
<author fullname="P. Patil" initials="P." surname="Patil"/>
<date month="February" year="2017"/>
<abstract>
<t>DNS queries and responses are visible to network elements on th
e path between the DNS client and its server. These queries and responses can co
ntain privacy-sensitive information, which is valuable to protect.</t>
<t>This document proposes the use of Datagram Transport Layer Secu
rity (DTLS) for DNS, to protect against passive listeners and certain active att
acks. As latency is critical for DNS, this proposal also discusses mechanisms to
reduce DTLS round trips and reduce the DTLS handshake size. The proposed mechan
ism runs over port 853.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8094"/>
<seriesInfo name="DOI" value="10.17487/RFC8094"/>
</reference>
<reference anchor="RFC9076">
<front>
<title>DNS Privacy Considerations</title>
<author fullname="T. Wicinski" initials="T." role="editor" surname="
Wicinski"/>
<date month="July" year="2021"/>
<abstract>
<t>This document describes the privacy issues associated with the
use of the DNS by Internet users. It provides general observations about typical
current privacy practices. It is intended to be an analysis of the present situ
ation and does not prescribe solutions. This document obsoletes RFC 7626.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9076"/>
<seriesInfo name="DOI" value="10.17487/RFC9076"/>
</reference>
<reference anchor="RFC9176">
<front>
<title>Constrained RESTful Environments (CoRE) Resource Directory</t
itle>
<author fullname="C. Amsüss" initials="C." role="editor" surname="Am
süss"/>
<author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
<author fullname="M. Koster" initials="M." surname="Koster"/>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="P. van der Stok" initials="P." surname="van der St
ok"/>
<date month="April" year="2022"/>
<abstract>
<t>In many Internet of Things (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 cal
led a Resource Directory (RD), which contains information about resources held o
n 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 interface
s that an RD supports for web servers to discover the RD and to register, mainta
in, look up, and remove information on resources. Furthermore, new target attrib
utes useful in conjunction with an RD are defined.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9176"/>
<seriesInfo name="DOI" value="10.17487/RFC9176"/>
</reference>
<reference anchor="RFC9250">
<front>
<title>DNS over Dedicated QUIC Connections</title>
<author fullname="C. Huitema" initials="C." surname="Huitema"/>
<author fullname="S. Dickinson" initials="S." surname="Dickinson"/>
<author fullname="A. Mankin" initials="A." surname="Mankin"/>
<date month="May" year="2022"/>
<abstract>
<t>This document describes the use of QUIC to provide transport co
nfidentiality for DNS. The encryption provided by QUIC has similar properties to
those provided by TLS, while QUIC transport eliminates the head-of-line blockin
g issues inherent with TCP and provides more efficient packet-loss recovery than
UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) s
pecified in RFC 7858, and latency characteristics similar to classic DNS over UD
P. This specification describes the use of DoQ as a general-purpose transport fo
r DNS and includes the use of DoQ for stub to recursive, recursive to authoritat
ive, and zone transfer scenarios.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9250"/>
<seriesInfo name="DOI" value="10.17487/RFC9250"/>
</reference>
<reference anchor="RFC9528">
<front>
<title>Ephemeral Diffie-Hellman Over COSE (EDHOC)</title>
<author fullname="G. Selander" initials="G." surname="Selander"/>
<author fullname="J. Preuß Mattsson" initials="J." surname="Preuß Ma
ttsson"/>
<author fullname="F. Palombini" initials="F." surname="Palombini"/>
<date month="March" year="2024"/>
<abstract>
<t>This document specifies Ephemeral Diffie-Hellman Over COSE (EDH
OC), a very compact and lightweight authenticated Diffie-Hellman key exchange wi
th ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and id
entity protection. EDHOC is intended for usage in constrained scenarios, and a m
ain use case is to establish an Object Security for Constrained RESTful Environm
ents (OSCORE) security context. By reusing CBOR Object Signing and Encryption (C
OSE) for cryptography, Concise Binary Object Representation (CBOR) for encoding,
and Constrained Application Protocol (CoAP) for transport, the additional code
size can be kept very low.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9528"/>
<seriesInfo name="DOI" value="10.17487/RFC9528"/>
</reference>
<reference anchor="I-D.ietf-core-href">
<front>
<title>Constrained Resource Identifiers</title>
<author fullname="Carsten Bormann" initials="C." surname="Bormann">
<organization>Universität Bremen TZI</organization>
</author>
<author fullname="Henk Birkholz" initials="H." surname="Birkholz">
<organization>Fraunhofer SIT</organization>
</author>
<date day="30" month="August" year="2025"/>
<abstract>
<t> The Constrained Resource Identifier (CRI) is a complement to
the
Uniform Resource Identifier (URI) that represents the URI components
in Concise Binary Object Representation (CBOR) rather than as a
sequence of characters. This approach simplifies parsing,
comparison, and reference resolution in environments with severe
limitations on processing power, code size, and memory size.
This RFC updates RFC 7595 to add a note on how the "URI Schemes"
registry of RFC 7595 cooperates with the "CRI Scheme Numbers"
registry created by the present RFC.
// (This "cref" paragraph will be removed by the RFC editor:) The
// present revision –24 attempts to address follow-on AD review
// comments as well as comments from the ARTART review.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-core-href-24"/>
</reference>
<reference anchor="I-D.ietf-core-transport-indication">
<front>
<title>CoAP Transport Indication</title>
<author fullname="Christian Amsüss" initials="C." surname="Amsüss">
</author>
<author fullname="Martine Sophie Lenders" initials="M. S." surname="
Lenders">
<organization>TUD Dresden University of Technology</organization>
</author>
<date day="7" month="July" year="2025"/>
<abstract>
<t> The Constrained Application Protocol (CoAP, [RFC7252]) is av
ailable
over different transports (UDP, DTLS, TCP, TLS, WebSockets), but
lacks a way to unify these addresses. This document provides
terminology and provisions based on Web Linking [RFC8288] and Service
Bindings (SVCB, [RFC9460]) to express alternative transports
available to a device, and to optimize exchanges using these.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-core-transport-ind
ication-09"/>
</reference>
<reference anchor="I-D.ietf-iotops-7228bis">
<front>
<title>Terminology for Constrained-Node Networks</title>
<author fullname="Carsten Bormann" initials="C." surname="Bormann">
<organization>Universität Bremen TZI</organization>
</author>
<author fullname="Mehmet Ersue" initials="M." surname="Ersue">
</author>
<author fullname="Ari Keränen" initials="A." surname="Keränen">
<organization>Ericsson</organization>
</author>
<author fullname="Carles Gomez" initials="C." surname="Gomez">
<organization>Universitat Politecnica de Catalunya</organization>
</author>
<date day="7" month="July" year="2025"/>
<abstract>
<t> The Internet Protocol Suite is increasingly used on small de
vices
with severe constraints on power, memory, and processing resources,
creating constrained-node networks. This document provides a number
of basic terms that have been useful in the standardization work for
constrained-node networks.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-iotops-7228bis-02"
/>
</reference>
<reference anchor="I-D.amsuess-core-cachable-oscore">
<front>
<title>Cacheable OSCORE</title>
<author fullname="Christian Amsüss" initials="C." surname="Amsüss">
</author>
<author fullname="Marco Tiloca" initials="M." surname="Tiloca">
<organization>RISE AB</organization>
</author>
<date day="6" month="July" year="2025"/>
<abstract>
<t> Group communication with the Constrained Application Protoco
l (CoAP)
can be secured end-to-end using Group Object Security for Constrained
RESTful Environments (Group OSCORE), also across untrusted
intermediary proxies. However, this sidesteps the proxies' abilities
to cache responses from the origin server(s). This specification
restores cacheability of protected responses at proxies, by
introducing consensus requests which any client in a group can send
to one server or multiple servers in the same group.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-amsuess-core-cachable-o
score-11"/>
</reference>
<reference anchor="DoC-paper"> <reference anchor="DoC-paper">
<front> <front>
<title>Securing Name Resolution in the IoT: DNS over CoAP</title> <title>Securing Name Resolution in the IoT: DNS over CoAP</title>
<author fullname="Martine S. Lenders" initials="M." surname="Lenders "> <author initials="M. S." surname="Lenders" fullname="Martine S. Lend ers">
<organization>TU Dresden, Germany</organization> <organization>TU Dresden, Germany</organization>
</author> </author>
<author fullname="Christian Amsüss" initials="C." surname="Amsüss"> <author initials="C." surname="Amsüss" fullname="Christian Amsüss">
<organization>Unaffiliated, Vienna, Austria</organization> <organization>Unaffiliated, Vienna, Austria</organization>
</author> </author>
<author fullname="Cenk Gündogan" initials="C." surname="Gündogan"> <author initials="C." surname="Gündogan" fullname="Cenk Gündogan">
<organization>Huawei Technologies, Munich, Germany</organization> <organization>Huawei Technologies, Munich, Germany</organization>
</author> </author>
<author fullname="Marcin Nawrocki" initials="M." surname="Nawrocki"> <author initials="M." surname="Nawrocki" fullname="Marcin Nawrocki">
<organization>TU Dresden, Germany</organization> <organization>TU Dresden, Germany</organization>
</author> </author>
<author fullname="Thomas C. Schmidt" initials="T." surname="Schmidt" > <author initials="T." surname="Schmidt" fullname="Thomas C. Schmidt" >
<organization>HAW Hamburg, Hamburg, Germany</organization> <organization>HAW Hamburg, Hamburg, Germany</organization>
</author> </author>
<author fullname="Matthias Wählisch" initials="M." surname="Wählisch "> <author initials="M." surname="Wählisch" fullname="Matthias Wählisch ">
<organization>TU Dresden &amp;amp; Barkhausen Institut, Dresden, G ermany</organization> <organization>TU Dresden &amp;amp; Barkhausen Institut, Dresden, G ermany</organization>
</author> </author>
<date month="September" year="2023"/> <date year="2023" month="September"/>
</front> </front>
<seriesInfo name="Proceedings of the ACM on Networking" value="vol. 1, no. CoNEXT2, pp. 1-25"/>
<seriesInfo name="DOI" value="10.1145/3609423"/> <seriesInfo name="DOI" value="10.1145/3609423"/>
<refcontent>Association for Computing Machinery (ACM)</refcontent> <refcontent>Proceedings of the ACM on Networking, vol. 1, no. CoNEXT2,
</reference> pp. 1-25</refcontent>
<reference anchor="I-D.ietf-core-corr-clar">
<front>
<title>Constrained Application Protocol (CoAP): Corrections and Clar
ifications</title>
<author fullname="Carsten Bormann" initials="C." surname="Bormann">
<organization>Universität Bremen TZI</organization>
</author>
<date day="20" month="June" year="2025"/>
<abstract>
<t> RFC 7252 defines the Constrained Application Protocol (CoAP)
, along
with a number of additional specifications, including RFC 7641, RFC
7959, RFC 8132, and RFC 8323. RFC 6690 defines the link format that
is used in CoAP self-description documents.
Some parts of the specification may be unclear or even contain errors
that may lead to misinterpretations that may impair interoperability
between different implementations. The present document provides
corrections, additions, and clarifications to the RFCs cited; this
document thus updates these RFCs. In addition, other clarifications
related to the use of CoAP in other specifications, including RFC
7390 and RFC 8075, are also provided.
</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-core-corr-clar-02"
/>
</reference> </reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D. ietf-core-corr-clar.xml"/>
<reference anchor="REST" target="https://www.ics.uci.edu/~fielding/pubs/ dissertation/fielding_dissertation.pdf"> <reference anchor="REST" target="https://www.ics.uci.edu/~fielding/pubs/ dissertation/fielding_dissertation.pdf">
<front> <front>
<title>Architectural Styles and the Design of Network-based Software Architectures</title> <title>Architectural Styles and the Design of Network-based Software Architectures</title>
<author initials="R." surname="Fielding" fullname="Roy Thomas Fieldi ng"> <author initials="R." surname="Fielding" fullname="Roy Thomas Fieldi ng">
<organization>University of California, Irvine</organization> <organization>University of California, Irvine</organization>
</author> </author>
<date year="2000"/> <date year="2000"/>
</front> </front>
<seriesInfo name="Ph.D." value="Dissertation, University of California , Irvine"/>
<format type="HTML" target="https://ics.uci.edu/~fielding/pubs/dissert ation/top.htm"/> <format type="HTML" target="https://ics.uci.edu/~fielding/pubs/dissert ation/top.htm"/>
<refcontent>Ph.D. Dissertation, University of California, Irvine</refc ontent>
</reference> </reference>
<reference anchor="RFC8446"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<front> 446.xml"/>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
e> 052.xml"/>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<date month="August" year="2018"/> 828.xml"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC9052">
<front>
<title>CBOR Object Signing and Encryption (COSE): Structures and Pro
cess</title>
<author fullname="J. Schaad" initials="J." surname="Schaad"/>
<date month="August" year="2022"/>
<abstract>
<t>Concise Binary Object Representation (CBOR) is a data format de
signed for small code size and small message size. There is a need to be able to
define basic security services for this data format. This document defines the
CBOR Object Signing and Encryption (COSE) protocol. This specification describes
how to create and process signatures, message authentication codes, and encrypt
ion using CBOR for serialization. This specification additionally describes how
to represent cryptographic keys using CBOR.</t>
<t>This document, along with RFC 9053, obsoletes RFC 8152.</t>
</abstract>
</front>
<seriesInfo name="STD" value="96"/>
<seriesInfo name="RFC" value="9052"/>
<seriesInfo name="DOI" value="10.17487/RFC9052"/>
</reference>
<reference anchor="RFC7942">
<front>
<title>Improving Awareness of Running Code: The Implementation Statu
s Section</title>
<author fullname="Y. Sheffer" initials="Y." surname="Sheffer"/>
<author fullname="A. Farrel" initials="A." surname="Farrel"/>
<date month="July" year="2016"/>
<abstract>
<t>This document describes a simple process that allows authors of
Internet-Drafts to record the status of known implementations by including an I
mplementation Status section. This will allow reviewers and working groups to as
sign due consideration to documents that have the benefit of running code, which
may serve as evidence of valuable experimentation and feedback that have made t
he implemented protocols more mature.</t>
<t>This process is not mandatory. Authors of Internet-Drafts are e
ncouraged to consider using the process for their documents, and working groups
are invited to think about applying the process to all of their protocol specifi
cations. This document obsoletes RFC 6982, advancing it to a Best Current Practi
ce.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="205"/>
<seriesInfo name="RFC" value="7942"/>
<seriesInfo name="DOI" value="10.17487/RFC7942"/>
</reference>
<reference anchor="RFC7828">
<front>
<title>The edns-tcp-keepalive EDNS0 Option</title>
<author fullname="P. Wouters" initials="P." surname="Wouters"/>
<author fullname="J. Abley" initials="J." surname="Abley"/>
<author fullname="S. Dickinson" initials="S." surname="Dickinson"/>
<author fullname="R. Bellis" initials="R." surname="Bellis"/>
<date month="April" year="2016"/>
<abstract>
<t>DNS messages between clients and servers may be received over e
ither UDP or TCP. UDP transport involves keeping less state on a busy server, bu
t can cause truncation and retries over TCP. Additionally, UDP can be exploited
for reflection attacks. Using TCP would reduce retransmits and amplification. Ho
wever, clients commonly use TCP only for retries and servers typically use idle
timeouts on the order of seconds.</t>
<t>This document defines an EDNS0 option ("edns-tcp-keepalive") th
at allows DNS servers to signal a variable idle timeout. This signalling encoura
ges the use of long-lived TCP connections by allowing the state associated with
TCP transport to be managed effectively with minimal impact on the DNS transacti
on time.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7828"/>
<seriesInfo name="DOI" value="10.17487/RFC7828"/>
</reference>
</references> </references>
</references> </references>
<?line 825?> <?line 802?>
<section anchor="sec_evaluation"> <section anchor="sec_evaluation">
<name>Evaluation</name> <name>Evaluation</name>
<t>The authors of this document presented the design, implementation, and analysis of DoC in their <t>The authors of this document presented the design, implementation, and analysis of DoC in their
paper "Securing Name Resolution in the IoT: DNS over CoAP" <xref target="DoC-pap er"/>.</t> paper "Securing Name Resolution in the IoT: DNS over CoAP" <xref target="DoC-pap er"/>.</t>
</section> <!--[rfced] Sourcecode and artwork
<section anchor="change-log">
<name>Change Log</name> c) The blocks in Section 4.3.3 are too long for the TXT output. We marked
<t><cref anchor="remove-changelog">RFC Ed.: Please remove this section bef these as sourcecode, so they should have a width of 69 characters or less. The
ore publication.</cref></t> long lines are currently 70 characters. Would moving all the lines with
<section anchor="since-draft-ietf-core-dns-over-coap-18"> semicolons over to the left one space (in just this section or in all the
<name>Since <eref target="https://datatracker.ietf.org/doc/html/draft-ie sourcecode in the document) be a good solution? We tried this in the test
tf-core-dns-over-coap-18">draft-ietf-core-dns-over-coap-18</eref></name> files listed above so you can see what the output will look like. Feel free to
<ul spacing="normal"> offer other suggestions as well.
<li> -->
<t>Address Address Mohamed Boucadair's COMMENT:
</t> </section>
<ul spacing="normal">
<li>
<t>Add Operational Considerations Section</t>
</li>
<li>
<t>Make SVCB references normative</t>
</li>
<li>
<t>Remove redundant requirement on parsing application/dns-messa
ge</t>
</li>
<li>
<t>Remove contradicting statement and outdated reference about A
LPN</t>
</li>
<li>
<t>Add DNS client to Fig. 1</t>
</li>
<li>
<t>Clarify recursion termination in the CoAP realm</t>
</li>
<li>
<t>Clarify where addresses are coming from with DDR/DNR</t>
</li>
</ul>
</li>
<li>
<t>Address Gorry Fairhurst's follow-up DISCUSS:
</t>
<ul spacing="normal">
<li>
<t>Refer to Observe terminology in Section 2</t>
</li>
<li>
<t>Clarify registration</t>
</li>
<li>
<t>Provide alternative observation examples</t>
</li>
<li>
<t>Clarify that error handling is in the hands of the DoC server
</t>
</li>
</ul>
</li>
</ul>
</section>
<section anchor="since-draft-ietf-core-dns-over-coap-17">
<name>Since <eref target="https://datatracker.ietf.org/doc/html/draft-ie
tf-core-dns-over-coap-17">draft-ietf-core-dns-over-coap-17</eref></name>
<ul spacing="normal">
<li>
<t>Address Roman Danyliw's COMMENT:
</t>
<ul spacing="normal">
<li>
<t>Remove unused RFC8742 reference</t>
</li>
</ul>
</li>
<li>
<t>Address Vladimír Čunát's DNSDIR review
</t>
<ul spacing="normal">
<li>
<t>Address Éric Vyncke' COMMENT:</t>
</li>
<li>
<t>Mention OPCODE 0 in Abstract and Introduction</t>
</li>
<li>
<t>Reference to STD13 instead of RFC1035</t>
</li>
<li>
<t>Provide extension pointers for future documents on other OPCO
DES</t>
</li>
<li>
<t>Use only singular for example section if there is only one ex
ample</t>
</li>
<li>
<t>Improvements on DNSSEC</t>
</li>
<li>
<t>Hyphenate link-layer as modifier to frame</t>
</li>
</ul>
</li>
<li>
<t>Address Paul Wouters's DISCUSS and COMMENT:
</t>
<ul spacing="normal">
<li>
<t>Remove unnecessary and confusing ad flag from query example</
t>
</li>
<li>
<t>Phrase full SVCB mapping sentence more neutrally</t>
</li>
</ul>
</li>
<li>
<t>Address Gorry Fairhurst's COMMENT:
</t>
<ul spacing="normal">
<li>
<t>Add note (in addition to the <tt>RFC Ed.:</tt>) about paragra
ph removal</t>
</li>
<li>
<t>Add references for "coap" and "co" ALPN to SvcParam algorithm
</t>
</li>
<li>
<t>Address Gorry's nits</t>
</li>
</ul>
</li>
<li>
<t>Address Gorry Fairhurst's DISCUSS:
</t>
<ul spacing="normal">
<li>
<t>Update push notifications</t>
</li>
<li>
<t>observation: Do not use normative language</t>
</li>
</ul>
</li>
<li>
<t>Address Orie Steele's COMMENT:
</t>
<ul spacing="normal">
<li>
<t>Automatic configuration <bcp14>MUST</bcp14> only be done from
a trusted source</t>
</li>
<li>
<t>Remove confusing and unnecessary <bcp14>MAY</bcp14></t>
</li>
<li>
<t>Remove normative repeat of SvcParam algorithm by citing RFC 9
461</t>
</li>
<li>
<t>Fix wording around Accept option</t>
</li>
</ul>
</li>
<li>
<t>Address Deb Cooley's COMMENT:
</t>
<ul spacing="normal">
<li>
<t>Group (D)TLS references</t>
</li>
<li>
<t>Automatic configuration <bcp14>MUST</bcp14> only be done from
a trusted source</t>
</li>
<li>
<t>Fix wording about unpredictable ID and spoofing</t>
</li>
<li>
<t>Remove confusing "e.g."</t>
</li>
</ul>
</li>
</ul>
</section>
<section anchor="since-draft-ietf-core-dns-over-coap-16">
<name>Since <eref target="https://datatracker.ietf.org/doc/html/draft-ie
tf-core-dns-over-coap-16">draft-ietf-core-dns-over-coap-16</eref></name>
<ul spacing="normal">
<li>
<t>Mention TLS as possible protection mechanism in abstract and intr
o</t>
</li>
<li>
<t>Fix representation format in the docpath examples</t>
</li>
<li>
<t>Make docpath wire-format paragraph easier to parse</t>
</li>
</ul>
</section>
<section anchor="since-draft-ietf-core-dns-over-coap-15">
<name>Since <eref target="https://datatracker.ietf.org/doc/html/draft-ie
tf-core-dns-over-coap-15">draft-ietf-core-dns-over-coap-15</eref></name>
<ul spacing="normal">
<li>
<t>Address Genart and Artart review:
</t>
<ul spacing="normal">
<li>
<t>Add editor's note about removing RFC7228 reference in case rf
c7228bis comes out before
publication</t>
</li>
<li>
<t>Address minor nits</t>
</li>
<li>
<t>Resolve less well-known abbreviations</t>
</li>
<li>
<t>Name default ports for "coap" and "co"</t>
</li>
<li>
<t>Add reasoning why we also consider DTLS v1.2 (RFC 6347)</t>
</li>
<li>
<t>Add illustrative reference for ETag generation</t>
</li>
</ul>
</li>
<li>
<t>Address DNS SVCB SvcParamKeys IANA expert review:
</t>
<ul spacing="normal">
<li>
<t>docpath: clarifications and examples</t>
</li>
<li>
<t>Rework representation format and wire-format of "docpath"</t>
</li>
<li>
<t>State that we don't do the full SVCB mapping</t>
</li>
<li>
<t>Explicitly do not limit what port= can do.</t>
</li>
<li>
<t>port limitations: We're not the SVCB mapping document</t>
</li>
</ul>
</li>
<li>
<t>Address Tsvart Review
</t>
<ul spacing="normal">
<li>
<t>Prefer ADN for Uri-Host; don't prescribe <em>how</em> it is s
et</t>
</li>
</ul>
</li>
</ul>
</section>
<section anchor="since-draft-ietf-core-dns-over-coap-14">
<name>Since <eref target="https://datatracker.ietf.org/doc/html/draft-ie
tf-core-dns-over-coap-14">draft-ietf-core-dns-over-coap-14</eref></name>
<ul spacing="normal">
<li>
<t>Remove superfluous and confusing step in SVCB to request algorith
m</t>
</li>
<li>
<t>Address AD review:
</t>
<ul spacing="normal">
<li>
<t>Remove RFC8949 as CBOR diagnostic notation reference</t>
</li>
<li>
<t>CoRE-specific FETCH method -&gt; CoAP-specific FETCH method</
t>
</li>
<li>
<t>Remove double reference to BCP 219</t>
</li>
<li>
<t>Fix wording and references around SVCB records and ALPN</t>
</li>
<li>
<t>Move format description for examples to Terminology section</
t>
</li>
<li>
<t>Retitle section 5 to "Interaction with other CoAP and CoRE Fe
atures"</t>
</li>
<li>
<t>Make prevention of poisoning attacks normative for unprotecte
d CoAP</t>
</li>
<li>
<t>Provide specs on if the <bcp14>SHOULD</bcp14> on ID=0 does no
t apply</t>
</li>
<li>
<t>Make construction algorithm normative</t>
</li>
<li>
<t>Add definition for CoRE</t>
</li>
<li>
<t>General grammar, wording, and spelling cleanups</t>
</li>
</ul>
</li>
</ul>
</section>
<section anchor="since-draft-ietf-core-dns-over-coap-13">
<name>Since <eref target="https://datatracker.ietf.org/doc/html/draft-ie
tf-core-dns-over-coap-13">draft-ietf-core-dns-over-coap-13</eref></name>
<ul spacing="normal">
<li>
<t>Address shepherd review</t>
</li>
</ul>
</section>
<section anchor="since-draft-ietf-core-dns-over-coap-12">
<name>Since <eref target="https://datatracker.ietf.org/doc/html/draft-ie
tf-core-dns-over-coap-12">draft-ietf-core-dns-over-coap-12</eref></name>
<ul spacing="normal">
<li>
<t>Address Esko's review</t>
</li>
<li>
<t>Address Marcos's review</t>
</li>
<li>
<t>Address Mikolai's review</t>
</li>
</ul>
</section>
<section anchor="since-draft-ietf-core-dns-over-coap-10">
<name>Since <eref target="https://datatracker.ietf.org/doc/html/draft-ie
tf-core-dns-over-coap-10">draft-ietf-core-dns-over-coap-10</eref></name>
<ul spacing="normal">
<li>
<t>Replace imprecise or wrong terms:
</t>
<ul spacing="normal">
<li>
<t>disjunct =&gt; distinct</t>
</li>
<li>
<t>unencrypted CoAP =&gt; unprotected CoAP</t>
</li>
<li>
<t>security mode =&gt; confidential communication</t>
</li>
</ul>
</li>
<li>
<t>Pull in definition of CBOR sequences and their EDN</t>
</li>
<li>
<t>Fix broken external section references</t>
</li>
<li>
<t>Define terminology for "upstream DNS infrastructure" and "upstrea
m DNS server"</t>
</li>
<li>
<t>Fix wording on DNS error handling</t>
</li>
<li>
<t>Clarify that any OpCode beyond 0 is not supported for now and rem
ove now redundant DNS Upgrade
section as a consequence</t>
</li>
<li>
<t>Clarify that the DoC/DoH mapping is what is <bcp14>NOT RECOMMENDE
D</bcp14></t>
</li>
<li>
<t>Avoid use of undefined term “CoAP resource identifier”</t>
</li>
<li>
<t>Discuss Max-Age option value in an error case</t>
</li>
<li>
<t>Add human-readable format to examples</t>
</li>
<li>
<t>General language check pass</t>
</li>
</ul>
</section>
<section anchor="since-draft-ietf-core-dns-over-coap-09">
<name>Since <eref target="https://datatracker.ietf.org/doc/html/draft-ie
tf-core-dns-over-coap-09">draft-ietf-core-dns-over-coap-09</eref></name>
<ul spacing="normal">
<li>
<t>Update SVCB SvcParamKey</t>
</li>
<li>
<t>Update corr-clar reference</t>
</li>
<li>
<t>Add reference to DNS Update <eref target="https://datatracker.iet
f.org/doc/html/rfc2136">[RFC2136]</eref>, clarify that it is currently not consi
dered</t>
</li>
<li>
<t>Add to security considerations: unprotected upstream DNS and DNSS
EC</t>
</li>
</ul>
</section>
<section anchor="since-draft-ietf-core-dns-over-coap-08">
<name>Since <eref target="https://datatracker.ietf.org/doc/html/draft-ie
tf-core-dns-over-coap-08">draft-ietf-core-dns-over-coap-08</eref></name>
<ul spacing="normal">
<li>
<t>Update Cenk's Affiliation</t>
</li>
</ul>
</section>
<section anchor="since-draft-ietf-core-dns-over-coap-07">
<name>Since <eref target="https://datatracker.ietf.org/doc/html/draft-ie
tf-core-dns-over-coap-07">draft-ietf-core-dns-over-coap-07</eref></name>
<ul spacing="normal">
<li>
<t>Address IANA early review #1368678</t>
</li>
<li>
<t>Update normative reference to CoAP over DTLS alpn SvcParam</t>
</li>
<li>
<t>Add missing DTLSv1.2 reference</t>
</li>
<li>
<t>Security considerations: Point into corr-clar-future</t>
</li>
<li>
<t>Implementation Status: Update to current version</t>
</li>
</ul>
</section>
<section anchor="since-draft-ietf-core-dns-over-coap-06">
<name>Since <eref target="https://datatracker.ietf.org/doc/html/draft-ie
tf-core-dns-over-coap-06">draft-ietf-core-dns-over-coap-06</eref></name>
<ul spacing="normal">
<li>
<t>Add "docpath" SVCB ParamKey definition</t>
</li>
<li>
<t>IANA fixes
</t>
<ul spacing="normal">
<li>
<t>Use new column names (see Errata 4954)</t>
</li>
<li>
<t>Add reference to RFC 8484 for application/dns-message Media T
ype</t>
</li>
<li>
<t>IANA: unify self references</t>
</li>
</ul>
</li>
</ul>
</section>
<section anchor="since-draft-ietf-core-dns-over-coap-05">
<name>Since <eref target="https://datatracker.ietf.org/doc/html/draft-ie
tf-core-dns-over-coap-05">draft-ietf-core-dns-over-coap-05</eref></name>
<ul spacing="normal">
<li>
<t>Add references to relevant SVCB/DNR RFCs and drafts</t>
</li>
</ul>
</section>
<section anchor="since-draft-ietf-core-dns-over-coap-04">
<name>Since <eref target="https://datatracker.ietf.org/doc/html/draft-ie
tf-core-dns-over-coap-04">draft-ietf-core-dns-over-coap-04</eref></name>
<ul spacing="normal">
<li>
<t>Add note on cacheable OSCORE</t>
</li>
<li>
<t>Address early IANA review</t>
</li>
</ul>
</section>
<section anchor="since-draft-ietf-core-dns-over-coap-03">
<name>Since <eref target="https://datatracker.ietf.org/doc/html/draft-ie
tf-core-dns-over-coap-03">draft-ietf-core-dns-over-coap-03</eref></name>
<ul spacing="normal">
<li>
<t>Amended Introduction with short contextualization of constrained
environments</t>
</li>
<li>
<t>Add <xref target="sec_evaluation"/> on evaluation</t>
</li>
</ul>
</section>
<section anchor="since-draft-ietf-core-dns-over-coap-02">
<name>Since <eref target="https://datatracker.ietf.org/doc/html/draft-ie
tf-core-dns-over-coap-02">draft-ietf-core-dns-over-coap-02</eref></name>
<ul spacing="normal">
<li>
<t>Move implementation details to Implementation Status (in accordan
ce with <xref target="RFC7942"/>)</t>
</li>
<li>
<t>Recommend root path to keep the CoAP options small</t>
</li>
<li>
<t>Set Content-Format for application/dns-message to 553</t>
</li>
<li>
<t>SVCB/DNR: Move to Server Selection Section but leave TBD based on
DNSOP discussion for now</t>
</li>
<li>
<t>Clarify that DoC and DoH are distinct</t>
</li>
<li>
<t>Clarify mapping between DoC and DoH</t>
</li>
<li>
<t>Update considerations on unprotected use</t>
</li>
<li>
<t>Don't call OSCORE end-to-end encrypted</t>
</li>
</ul>
</section>
<section anchor="since-draft-ietf-core-dns-over-coap-01">
<name>Since <eref target="https://datatracker.ietf.org/doc/html/draft-ie
tf-core-dns-over-coap-01">draft-ietf-core-dns-over-coap-01</eref></name>
<ul spacing="normal">
<li>
<t>Specify DoC server role in terms of DNS terminology</t>
</li>
<li>
<t>Clarify communication of DoC to DNS infrastructure is agnostic of
the transport</t>
</li>
<li>
<t>Add subsection on how to implement DNS Push in DoC</t>
</li>
<li>
<t>Add appendix on reference implementation</t>
</li>
</ul>
</section>
<section anchor="since-draft-ietf-core-dns-over-coap-00">
<name>Since <eref target="https://datatracker.ietf.org/doc/html/draft-ie
tf-core-dns-over-coap-00">draft-ietf-core-dns-over-coap-00</eref></name>
<ul spacing="normal">
<li>
<t>SVGify ASCII art</t>
</li>
<li>
<t>Move section on "DoC Server Considerations" (was Section 5.1) to
its own draft
(<eref target="https://datatracker.ietf.org/doc/draft-lenders-dns-cns/">draft-le
nders-dns-cns</eref>)</t>
</li>
<li>
<t>Replace layer violating statement for CON with statement of fact<
/t>
</li>
<li>
<t>Add security considerations on ID=0</t>
</li>
</ul>
</section>
<section anchor="since-draft-lenders-dns-over-coap-04">
<name>Since <eref target="https://datatracker.ietf.org/doc/html/draft-le
nders-dns-over-coap-04">draft-lenders-dns-over-coap-04</eref></name>
<ul spacing="normal">
<li>
<t>Removed change log of draft-lenders-dns-over-coap</t>
</li>
</ul>
</section>
</section>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>The authors of this document want to thank Mike Bishop, Carsten Bormann <t>The authors of this document want to thank <contact fullname="Mike Bish
, Mohamed Boucadair, Deb Cooley, Vladimír Čunát, Roman Danyliw, Elwyn B. Davies, op"/>, <contact fullname="Carsten Bormann"/>, <contact fullname="Mohamed Boucada
Esko Dijk, Gorry Fairhurst, Thomas Fossati, Mikolai Gütschow, Todd Herr, Tommy ir"/>, <contact fullname="Deb Cooley"/>, <contact fullname="Vladimír Čunát"/>, <
Pauly, Jan Romann, Ben Schwartz, Orie Steele, Marco Tiloca, Éric Vyncke, Tim Wic contact fullname="Roman Danyliw"/>, <contact fullname="Elwyn B. Davies"/>, <cont
inski, and Paul Wouters for their feedback and comments.</t> act fullname="Esko Dijk"/>, <contact fullname="Gorry Fairhurst"/>, <contact full
name="Thomas Fossati"/>, <contact fullname="Mikolai Gütschow"/>, <contact fullna
me="Todd Herr"/>, <contact fullname="Tommy Pauly"/>, <contact fullname="Jan Roma
nn"/>, <contact fullname="Ben Schwartz"/>, <contact fullname="Orie Steele"/>, <c
ontact fullname="Marco Tiloca"/>, <contact fullname="Éric Vyncke"/>, <contact fu
llname="Tim Wicinski"/>, and <contact fullname="Paul Wouters"/> for their feedba
ck and comments.</t>
<t>This work was supported in parts by the German Federal Ministry of Rese
arch, Technology and Space (BMFTR) under the grant numbers 16KIS1386K (TU Dresde
n) and 16KIS1387 (HAW Hamburg) within the research project PIVOT and under the g
rant numbers 16KIS1694K (TU Dresden) and 16KIS1695 (HAW Hamburg) within the rese
arch project C-ray4edge.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source: <!-- ##markdown-source:
H4sIAAAAAAAAA8V92XIb2ZXge37FbVREF+kGQHCnWFbZFEkV2SOKNElVtaNK H4sIANfmuWkAA7192XLj2JXgO77iWhXRJXUTFLUvtdhKSVlSO5VKS8wqO9IV
40ogL4g0E5lwLqTgkhx+nYh57MeZ6JmIeZ0/6Kep/hJ/yZztLpkJkJSsthm2 NkhckrBAgAZAKVlZ6feJmH/omYh5nT/w01R/2JztLgBISVVOW2FnSSBxl7Nv
igQy73Lu2bfb6/WCu321GQRlXCZ6X3WOXl+p7E7n6jA7uFArR9nhaicIh8Nc 99wwDIMqqVJ9rNbOXt+q/F4X6jQ/eaPWz/LTjbUgGgwKfX+s4K8gzodZNIWv
w3PwVxBlozScwqNRHo7LXqzLcW+U5boXpUUP34S/wllvYxCMwlLfZPl8XxVl xkU0qsJEV6NwmBc6jLMyxDfhr2gWbveCbD4d6OJYHR3t7QTJDH6rinlZbfd6
FBTVcBoXRZyl5XwGr58eX78MgrvNd9NkIx+P9gOlijjR6Ujjrz31MqvSSF19 R73tII2y8bHSWTDMs1Jn5bykz3WQD8o81ZUuj4P5LI7ol1lyrN5V+bCjysW0
+426j8sJ/BPBv1muJjq+mZSqmOlRPI51FARhrsN9dTCbJTFMCRMUwX2W397k 0KMSfsmLCn/7PhjCd8Z5sThWZRUH5XwwTcoyybNqMYNlXp73Xwaw9p0gwMGO
WTXbh31cHge3eg4fRTzyaVrqPNVl7wh3QB/RQ/zLwQX9AnAI7nRa0WqU8gfD 1XZvez/s7QRRoaNj9d1lP3jIi7txkc9nx7Drm/PgTi/gUXwcKBXyE/7l5A39
v3kP38E0cXqjvsFv6fNpGCf7CuHxa4RMP8tv6PMwH00AupOynBX7a2v4GH4U AiAKgmheTfICvhIqxfC4iooqybS6zWeTRKtXOot1UcIbSuUFbLX/9kydFbqM
3+m+eW4NP1gb5tl9oddwhLUOTw3br4bwMkH5/maNAV8DNz+ZAMCL0ptG3ujz dabeZglAqkyqhcpHqq+HkyxP8/GCvm2g3X9rvk+PS9iuro7VhU6nkzytfoAH
EP04W/Tu2oMH2Z+U06QDQK7KSZYDMHpK8fmfhXkZp1pdZbNJrNUrnUY6L2gh XbXVow+HMNRx7evDPIZFnYW9rd7+kTyZZxWC6RtdTKOMJ9PTKEmP1ZQX3015
sJt9df3mSB3luoh0qt6ksNO8iMu5ysbqWo8maZZkN3OGjWDX9RvzPH1clLnW 1b+p5mHMg3Vj7W3ydFIkZZVEmTqZlj/9vSz9QYbmw99E03Kuy7I7zKf+yzq7
sJsTnUwnWVL+ET7oq/UBfTmCofZrj4+yCBZ11BusD3aeySdVWiL6faPzaZjy U9/89Pcszv/7v6LMgea1nhdRejLWWaW+mQ4uavu9SnQZ3kdZCAsLb/KJDm+r
ZJpPaMqL7ye86l+XVS/iwfqR9jZ5OMnjoozDVB1Mi5//vSj8QUbmy1+H06LS Ivrpv7Ta97Z+Nc+S4aS288PeYe/gyZ0PYVHd8RzWNIaFZ7SSCFfSjRJv7f1J
RdEfZVP/ZZ3eqm9+/vc0yv7j38LUgea1rvIwObjRaam+mQ5Pavs9i3XRuwvT Po1KddpVt8PJNIkrt/qLk+/URTQdzItxbeEvdJECTAvVzwt14K3V/7JZLHLF
Hiysd5lNdO+qzMOf/02rHW/rZ1Uajya1ne8N9ga7j+58BIvq3wBtZTew8JRW 02iquiXP/ptJ9BBOeJw6hq6iqpoksNTvfvo/kzQpBSjPJkH1b+pFVNxNojlw
EuJK+mHsrf16kk3DQh321dVoMgXic6s/OfhOnYTTYSW4bRb+QucJwDRX10Cm pbrMAKHVvFpBmI98+Z9Lrt2HSPPuGqQaZDl8u4K9Ifve9s+2dkBUZUinNy9P
u95a/YfNYjcGg2ePH1PZL3j2X0/C+96Ex6mf0FlYlpMYlvrdz/9nksSFAOXJ d44O94/VvEj4z73tnd1j2FY24r/3d3YP4NtVWm5t85OD7b1toBGQaPL3/u4W
KKj+Ub0I89tJWBXw1GkKB1pW5RLEfODh/1x07d+HmnfXQNUgzeDpEvaGjOrq /x2CnNLFvZbnR3tH8nyQ5sO7h6SUTw63dmSEcKQrwgY+3dnekafVUMY+3D2E
+mh9E1hzinh6+fJw89nezr6q8pj/3N7Y3NqHbaVj/ntnc2sXni6TYn2DP9nd 1cS5+co+Lj0vUbjKk4P9PdpMOJuXE/vsUAaa5LMwTaZJJZ8c7eKSBnnBfx9t
2N5A/hXO5O+drXX+u5cNC53fafn82fYz+XyYZKPb+7iQb/bWN2WE3liXdBr4 2c3tyJPd/R4IzfvhwP69xX+HFmLwDJYfx4X9k+CJf765OQ/x0RGAiJAjOuRr
6ebGpnxajmTsva09WE2UmUd2cOlZgTxIPtnd2abN9GZVMbGf7clAk2zWS+Jp +kMBy2h1MpulCQhoEMfhq2gBzPCmyEGQ5ykw/TgHYYEfqfWTV29eb6jLM3U7
XMo3z7ZwScMs57+frdvNbconWzsDEEZ3o6H9e53/7lmIwWew/CjK7Z8ET/zz 08NkJK+oEXBOBcOcgo4Apgduiv0h3WDrKJ03WHOd9V/d8nqiYowkOKmqWXm8
tHfUd1ySloCj98JklsqS7N9BEKdj/2ReHF5srD/j3YD4mcaWAeI3m7v0TaFH ufnw8NAtRsNQx0mVF11gic0kG+Wb8Aw3wWSrC5A3+PhYtgFbPKa92u8odXZ9
cm57m5vy7ASkWymL29l5NmDpAhtPb3s8gzm5DQIM4GTeSwG75J3dve09hLKB eQy03N062D082PQAQZ+zngF9MJyQtmHmMQqDfkL5r1JJBorvCsRKt6YyaC3z
0uAZAR1XKlsc7O4IlPP4LhzNDfjwY5orj+Sjje0BvvsH+XMbZ9TRJBu1oAOr gnm6+cFonqZPKp3WJCC7fKFdm6H5gZthucRvDd7vNmVjbfzmB2785YJ1GYTq
HsPbhHj1b4CXpcUsy0HipJEIbCD0BZ/6r8ZZmc2KHm5yGBf1ffbgE3lW+LCc Aq02fPsjH0QtgRggfj0x8eL0zfbWEbNWBdImsdoYP9k5oE9KPRQhcrizI9+d
UDiahMNE9xin4KX6B/AOKDS9WTjTOZDi+Wl/fdBfX9/aXtvcAShtbC448xyk gA1RCafs7x/1kBPBFAKxfxfyDEaMbBOXIhWHGYg6eefgcO8QWd6wbO+IJAAy
IkhuAQz+jX8iPI6vrllVKMP8BhmBEcL39/f9eFT0q1Hc11G19ifQWpII1Ia1 qfBb72BfWL5I7qPhwvAyPqa5ilgebe/18N2/yp97OKOOJzmu+jI86zpLDVY9
WTUs1iJQinRe0o7XzFe/8z/tz6Ixj8w62gEqDqUelci61VU5T3ShQlCWyolW YkKMk3KWRiBjT28uW18DhsvKGZhZYZLFwnGN1/o3J69v31zf9MPL12f+AAnw
R7qIb1Jkca91iWpQbxgWGhSpbFzeg6bkv61ZmlnRTj9xCuC97KuXshT5mJnt 5awMcd+DpGy8JQCBD1pzDqPhREeDVIcs+JrLPDm9OD958eo8vL49vb45Vwo+
ZTY3kqHxPfHbOo89DJMYMDSNw646ze9ANNCzEWgp+wr4P7NG2CYIPKQWs4LO B6s0nEUzLczV5mDLrVu7e5s7+wDk7R1fYH1+q4egE7Kxeg0Uo240GKBzki9J
xaR/1O+gMupBofvo6KwEMU2YsU6uz165o3jqMQCuod4jY1wcvfzcp9nr9YAN RuLnMu8fq5pl/HmLp8OmGdjk55WMLqrZqMNOTeGFjxpeqzibhnybRaNRkoKI
AwaHozIIridxAWQ1qqaoEER6DJuBE1WzHLB+lCW4J6XfAfKmN6huoo7+h4rg 1XFHfZvoLIs66gRM8CKJ6oM7w2wsdpkbufmcbZ559KATZzYAxDtigy1fP0pD
plbOLw7Pj47VYJXVdsCB4JCII4RRIl8tVhdmvBVUc1f7cJS60KzpT4FsQA0o gObr6KEA9Zg0YNJ4/CyIrBIcRhzVnzYttY77Zflyl1pRq4VRY8nq36Lp7Itl
gEhSNdQ0NyAJ6NfDOZgBq9evrnpXegRIE4lpgP9eraJKfj78PTyq6Gs8HVyu xlFn+a5YZ3wO6mIn7B2F24dMYcCpIDUqMEePUdkNNeiubFyiyYaEeXJ6pYBM
vwakjXGVBMfpXZxnKe4SF351eH55vKrKDCe7iyOtQPvP5zOYlLYoSzI71zhu X+sKfRj4pKPu8xTMrI7KcpDI+evz3/e3O2o2g2fh9l6b3/ICHLY0KpqMBjQe
MPLGjfRdPIIlxymhvtHrSb5PAFAwyWl2vdoPCN6gRkQJCEx4LM+iakQs5rn3 AofdhKevTm5QpJzf9o9XatVkWHbnw6Sr4/nm30aJTnGVm7P5oNyEIYEjK5Ie
s+wgFphEXf90YAOgDdCag59+QlHy4YM9H6RLYAc0CBDcDJYPn5qjUkuOKmgc m+ajP/lPu7N45LPjCejNpNLDCk1xdVstUl2qKItpx2fA2uMM9y+bDgdRCVbB
lYJxUcDAwFWBKGBOXa38Biaaw1keA3OzmDHvmbnULIxzBduahrMZTBKnsNww bT6qHsCl89/W5RLNSwi86aqXshR5zGi/yReGrhqfC0f5NvNplCYg5LMEuOqy
8M/cAlgGqX0n6FDI0QMyHAEqqPX+Bp58qu9hI7hp0iFgeeb3zQ8fAuAS9zpJ uAem9zAJ9nyviUEZau3NpHvWVWceCDpPDr1GL7NOMQNd9K9eOTw8FwcgmLuT
FPz3iSiiFqMIDMosGwYdVqUKkyJTvIzN2jKMgkEL+RXpGFs78BLsWacF7MDu aipjvDl7+alRGYYh2NRorw2rIPjyV2H4DiwsHX+vXv4BBPF3WrFfH6t3TWIE
C+Cgb2gpeEKAVWNAwBSU+QQ+6yMqaBV6tAMKH8AC/gHkAgxAiAKnnMUGKAZH KxZ1Xxils+x7VeXqnWdbfR+gOZjlD10c4yFJU3Bb7zSRxSjJgFYkXoBiG975
Tq6vL64ICtkEJgZsOYHDgTe6apLda3gEcCeeFgSBSM+SbE7IJjjso7eHz4GP /dUrtQ4b6XYACVMQ3QB5GG1towtL/DoI+pOkBIU5nE/R74w1jIGEpmbGqMTp
z111PwHdH5ZUhUkyp8XDOgFgZCnjMLn+QwVLYzDGgvC00oAW2K/xCBjU0tI0 9PvhJMrGqBxQAfx1TtpFrV+/Ob0+O1c9sTlhDcEzjdQuGsal5gDLFLxk8DZL
nON5A/qUeYz0jyub6inY8V01yxDOuMZqOiOmHJAekoRz+Hycg4wAI/6PuujC NQTJPtA0N9CujoPBQq2fbYApG5J2gjHpBVjS9eAv8BXFSgvoBZfpz42sCuZP
KsAmvpnMqrJLEEbbNB3NiefMcZYgS2Htk/AO4Az/SSM8/ts4yYbzEilkrIYZ cJ7dJ0We4e5wwaQwNxCoMMl9Emuls2GxmCEicGuyFLNjjeMGQ2/cWN8nQ4Yu
7Oby4Izevzw/c++qItF6RiBMMhBBEUhCMvzxtTKeaphzDMATQJX4WqphL4AH KUUg6iLTFbmPE5JK66AoAbpEASB74xT8MfhakcfzIYIi+Mr7WYWAJRGojo8V
oJjA5hhMKNQi3GtW5bh5fDC4TbN7YM5ZVfbVa9wRfp9UhAUAi6KCEQuwosI8 2ADIU1pz8OEDeiofP1q8oJgA6USDAP/PMLZUWhSt8iOCph8B4yIxwsDzElFv
zgBeVVGCyL/VQlkjUuMVgiVogQWXR9sO1VjfqwlYYYw/JYJsGJcqRxPeIMM0 sK3WfwcTLQCH52CoWIpYhGYuNYuSQsG2ptFsBpMkGSw3CnxcWwDLILXPhAxK
vEnBvgAtH94j0MRwnKCtIDlmaeRDNubRC8Qw0Ar4gYJpwqlKTKBN5Qk+/f6/ QTkQASgIMPSmAyBwoiaANjo4aqu7jcSQ6QfYG8KBvFZYsfl95+PHjuJv7tS+
ArYAAte+ewt0sPiLfdT/1HHU31cXiUay4Kdo2e05AeY6R9cOLTgHrA/hd9gu abxO+u6vyfHc3ccvP5+21HLagsHZbIOhYd8Y1QOJbPYGsNBjGhWxBJQ1AiLM
IeziFQkCwTHQoJYrA2yIDhe/NYR9T4nt0gqHGnAEeGA1NITcRwEAPAOMa5Vm wKZJ4VkXyUGryOMbUJsAD/gHt5yfIlRBeM8SAYylk4t+/80tEsoFrQAc6I8f
JWIEoDuYlUD9TMpMP4wSdUJCuXJ4QXsgKurWydWjIkCCJCKeYRkDsU3iC8gf u8FF/qDh0w69GiXTkvYS61maL4jehIx9CvdIOvBJuqMeJmDZwIrmUZouaO2w
P3zo4zrgfXi9oGXUnuySrw2ZL+FWGN2FaYl8CzUf5M9jsApQg8M3wQSKbwAL TNj6Q1JNaJhC/3UOK2OAJELztNCA1tetiQcY1LLTNFogyoGCwC5D1seVTUFg
0CV3PwxHt7RU0LPCG8A9VgBBcE6n6DNgKIjot6PE6Sip0CIla66H5hzr5GOP FQtQ3DkiDdc4n85IUwTkXKTkS48KtFfL5Ae0vsAZyefjyQxNDARwCqIwGy5I
sVpL78MHw4OAMu5AjUSYXYRwlmdgK4NgBCV7SpyytvuVQmsHgi5KA6Kq7Q8f 3CxwliDPYO2TCARhBP/JYkTkXZLmgwUKTYDyIIfd3Jxc0fs311fuXVWmWs8I
Vr9i1xu8+y5GYuDhjWIAcAijKManAbkTQPIEh0eFHvjiV3BMvYp5M+46gDOp hGkOSjEG3YzLYUskmWqYcwTAE0BV+FoGxgqSAWhA2ByDCdVsjHvN5wVuHr8Y
WMElHuHzcdjUeByP6BBxddZMQw1T9gQ8qRCeB1xKLVA5UEAAsd9lcfQwvtC+ 3IFMB42Rz6suW+BFzQIv5zBiOdRZVCQ5wAsMWDBC7rQw15ACRcqBJfDAgsuj
YQn0H5g9m+Gnb45Aj9D9m363zpyXYwuOYb/8zZvTQ/7yDwA5QhUQiUl2z9tN bUdqpB/UZJ7FTD4VgmyQVKowGgOXN43GGRhpsQ7gPQJNAugE1wI5Ms9iH7IJ
0EF6z25SI+5EnUMIsD0Av7B0ha386U9/UmFY3N0EovGaH7ACjq8PT8i2ReX3 j14ilYHu4S+UzGDOzyMmW+EWIZmCfAS+A28AFFuF0AJSALMUGIOpnGmLwVUn
e9Da1/ej4d7+/vrbtfrD9T9rfxHCImRAqAT/1KOff4LPv7fqylv4y3zhvrdf MhS7p29oQURhnTopexQGAEpjYifLMyRCiFlQVuBCYB1opxRRScuofZOYKEDZ
82J69Z9+8J52rt43vuh9bb6gEeh75f0fvqYf+pJ/3gfvD5MYDu39L5uDvb9C RHCP4vsoq5Cl0VRB8TUCNxjtLXxzmlTJGCCECYKHQTS8o6WCYo7GgBc210Cv
r0fuf+8P9h7E9BhJWDAOx3JbkJ2LKtbeoq8VwjK+bMz9pQfF7/1n3+IXP6jl TKfoLbDVIBrRjpJkwxSQoNa3NhSF00KMpylySEeeELOhNpReTHlAOPdg9yHY
P2sPfts8J5m3pujKCsy39jvA3TXifmuIhmv9fp9XilgU/LSvvhjHN+Q+vov1 3kRAzVdgk4PqAI9ySnKkBoD1UmsHhQ6KPSK6vY8fgefXtzc46A/vvycHh6cw
fQ992my3Pu+8CAsgPEJWzwbtfAhY25pmwAfjKToBgNcBzsGvqaUjeMuqopoE 6hPAEcVxgm8A/lOggxSnQBeWLHHEzPrOBmBtzkIMYRAAhuZsnBI3+QIP9gcO
8U8/tWb68GEfRCtxTjotoPaYWSTJ8DvdJHmkOdTdm1bVKMzhvxHJpzgNfASm 25BexIXaKAUaiLI94N5SpAPws1qin1GSAlvc50n8OPUQCGAJ9B+YPZ/h07dn
4WgSRf6wvA+rD0vvA7NQZAxsW8foBSJtwzyCdIrf84QoE0G9jZDKQ1qIrH8F oHR1dwxWU02MraYdHMN++Lu3l6f84V8JiCR90zR/4O2myXhSgecI/1q9IDYP
jMw+GhtFWQ3x2xwV6AJHkx3lYEDh9PJnsWiHbDKANqWZiVhnS0HaDOrp/vEq QoBtefiFNQps5W9/+5uKovLe2OHmBwz48/7pBUU+0XR9Bwb31nE8ODw+3vp+
Y8R0l6m13eXsCHioRpZphQ3MbNXSaoZe0nAayCI9uukHb2iVtJkaUyavhgNu s/7l+p/+X0S8CBcQvsF/hPTzH0q9s4r9e6XMY/upU/u8krD20w1+pE2rH+vP
ieOjCiEn66DI2p88LQCkqdEwc7ZX/WzrJAqM/cCf7Ozgt2xs0N+KAXV1fKju vzaP6XX6VHn/h4/phz6knx+DH09TcNqrH7+sj/TjLcadC/9Tf6QfQY2NkI2F
wE4AUYOn6MzX+nckbXh9U/Q2+WLErRBFyWvgzbzxEg1QCW2JwEKLFKMMKZhP zmAgu3bZr9gqrZ35VhOs4PP6vJ87wL3zv/k9Pv+jWvWz+chnLbTwlDUTkOc2
4zybwrsnXVAnUZtiCxJo1bwi/HqqAesiK7fJDwtHA0OBlIz6bOdOQlJ4AVNT n9mPgE43Se5tIsltdrtdWiLQS/DhWH02SsaUjbxP9ENIkVjyLr9aexGVwGKI
MHTJagZtnM9Ae7xXlNFhFs0RAHS+VWGeuzi/upb5QIMFZQ2WCiafPfICkV7k Ct9TXPvI9sc0B/GXTDHqBSIODS/YomUYeMkaaJp004cPrYk+fjwGbUMCkxAE
tFNj6KjckRCBGupCOKAwx7e/OTaD94OTxxY31YDW/P49Koyk35Har98B4Enw bJ2wZCS1dq+bvI3MhRZt08cYRgX8NyYbI8kCn1ZpOJpEURKi6MLqo8p7YBaK
7WyhkyFDgjfi/p50NYBnjopsgI55Yj6JfmfMQyNFSYkHFAGM6PJZeWKX1rFA EoAd4KSieCepYPMlE1/nKVExg/UWI0NHtBTZgXhRkSqr+QA/LdA+LHE02VMB
e4KdGvxcoEj1kfs5fzBNB7bZHdqiGMl8vvyH2eYt2DYY2yxU5+zN1XWny/9V jgUuQP4sl+2RTWkwMTTLCxtfLEnFB5Fn+6MUMsZ9p2nqGSOvs1rygLjUKB2t
r8/p98tjIM/L4yP8/erk4NUr+0sgT1ydnL95deR+c28enp+dHb8+4pfhU1X7 loGZra02n2FyKpoGskiPWbrBW1olbaYmfyn44MBb4fgFWJOCWwdFG5whcmEA
KOgAdXTYBumcX1yfnr8+eNXhE/HdKOh0ZC0bbe58lmu0KsMiAK19lMdDNjFf 0tTosDifpI7dOmeCDD/xJ7s6+QMI0TLnv1VUMnpuz0/VPVjPoFcQj86xq39G
HF78v/+1vgUg+gdQ3DfW15+RrfIPFFHY3RLGwrORCcV/ksWGno0wx1HgOADZ qoVXOMVckq8z3BpRb7wGQcxbr9A1K2u5GPTVMASZgX8wKvIpvHsBFDbE8JY4
ZnEZon4J2FqA0Z0qYHzAYIJffI+QAePll8PRbH3ra/kAN1z70MCs9iHBrP1J V8Cs5h0Rz1MNpBdbhU0ZMMAOjAVvxbjNAVg6o4S8yLmAHt0nfg9+A3uVn2pP
62UG4oKPFkxjoVn7vAHp+noPflv728Dd+/CXv8IonOqt7/3qa0CuA8c4gTCE 7oq5NsjjBZuHABLCuBkCtP/1bV+GAUNvXjn0l8gAoqWdLUNoc+ghdjW8hhAx
VTHl4xegzbpYevvwYuSXSYIHpjooWHmwDp5oFI/JrCtjtD1iYU8hMLawQElP u/zm3AwLPsZTa5tqIHEDUQ2yGDaU5WwZc3QBEEFab38X3fE8JsuBdf0DmW0A
uQTyfIOvhuit0DFJpLAQmUcyzog1JwrbIk8ElB9HQUI6YHHWkhhOGGlxkYB8 b6DVEtEWaxJIqX5vnCijQsnWBWgCjXQYgJ7OpdUssaJgv4ZilxhUQA5B3+VC
7hhZpNqyqMOTI49LdONJbz8ID6v5dxBUoZUmbA04r11YtuWYKA0iBxQbexg7 aDpwYe7RYwMQ1Vz5xg+L0jtwAbCMolRrV29v+2sd/q96fU2/35wDw96cn+Hv
sB7FsM7pwpom3cezFTHn+PETzpS4LWpGbK8HTY2heeYySUe8Ygh1TEZw0owM txcnr17ZXwL5xu3F9dtXZ+439+bp9dXV+eszfhmeqtqjYA34ZY3tr7XrN/3L
8I4RL3ig7DqNWE1reAP6AX1Uj2EBiAw7EBbeedw9iNkYqx3YDAjcP7LAuNTA 69cnr9YYL37AAaOFbHCjZ1rMCo3OV1QGYLYPi2TAntiL0zf/739t7QKIfgWu
XwB27Gun8Agi57Vhxis40mpNAYUV4ocoHxHERQXcA+xXCiQQYyePT2u/BP6G 8vbW1hGZ9L+i1O7Brogano08Df6THBuMAUQFjgLoAJKbgQxGOxOotZzkD5lC
0mcUgXMOlSIrCodxAuofuiTaYHFRVWcMr/c3BJlnYV6yShOWXaSvMAJ0B11A mgBA//s7hMz3x+rLwXC2tfu1PMAN1x4amNUeEszaT1ovMxCXPFoyjYVm7XkD
54hqnQR+JY8SD5EXcEI+QlmkKJorgU133FsftTJGJzgfdMIQFYCUtdpKgwrY 0vX1nvyh9reBu/fwy19jOYQKtw5//TUQ14kTpcAeIrpK5lBUp2CxijBhRNSR
rjHS05CegU7GLkQlXoHFk24xOCzmgZibhfMkC6MOSx4U/R3a0jLk8wWuG5iG l6AETVNEmFpDZcuDrSFG42QE9E2hBZBniYirCARdVKLypyIn+X5D0kbo1AN6
tZpXl/WaRfIbdoSKBI7OrOWRZbCsqyivpMwyWhJQbJjALl4COg11ia5JwNqI dEJqirUgaT2j6JxybCtBUVl+DhEZ6YQVXEuHOPWkJZIAOnvNaCfV1k5rPDnK
j2TeNWqMfhei3lEsoFlULuI0BEYg84orzfodRqQD4AJY5hEyT2DECBjBFCgh uFQ3vuntB+Fhzf41BFVk9Qu7Ai6+xZKprtnEkBC9oNjvw6A/ooGdVROEi+qC
r5GG8pzz8Fw1DdMeL0lQPyzJQ0VGDNAJDGC1IJLqNPtIA1+OPNc2uVpxEaRl L6pZ1F1EsmhAJ5ifgVwSvmg23evACFffmGgiXyZZkyASgl+t+WqOXPE1o3YQ
Ge5j126G4AkaJ0U2BwDpSidyRoDcbGmxDQ626E9fFHq0D2DpMfbCf+ThD8tV wRxtjNmGa3js3YAe1RO5ACsjF0SiPx0Xw9ox9P9AD//A2uNGg5gByHG4nNIb
pSD4bhInxCBgZXSeAEVARsckjQLns3SiOXjak8V4uEY3zTPAChqms9bBCMMt SKN9I5PXcaANFXmmKawPH6LWRACXcxAi4M5SLoDkOynA1m4J+A170NgH11y6
+qSNSu4U2gKAnwgGe5YJKqak+ZK/uSEcbDTXW05bhvSDiwwkLZ4Y0xLbpgUF ghIpGiQpuLC6XAYUV+XifOOt7rbQ9CwqKrZ1oqqDbBbFQPVgIugCKW4thV8p
Ogh/2A85RFdyikdIcY4b8ZYzeN+kMXG6SzPNKcVBACrALd9cnlL0pcpj9kHV /sJDFOVat0ZXliTK5kpg02vurZ+7MrWW5ZW1Wxr0z76N0ZuG6QxAcoqxfaEk
mPKiNw7ljRG+0Q1QkFZlhpJlVJ+9q9gBxlwqpNQ6t9coBuQq0QFnhEUekUF6 LrB8nl2ex5IaKLhZtEjzKF5jnYOqf412sYrafFXrBqZhrQ3WYYtmmeYmK4JM
cniB67jMKiSigwjAUAK5EpEYIBAu5WKmgvE0QjOVgsYRRcfDUrz+qEwUFLOL kpiFyhPLYC03p6Rzlee0JGDRKOX4E46g30doWZQtZuQJMPwMLC4T0PheXGFI
cmK6i5eqSEskrXOIhgVoV6LqgMZQ4GC8ajjkL75QR3ZCML0tjK7nM03kX1tP ah5nYrVGhDqBIWNg8SlQeVEje7LWNGhEMmQn82mUhcAksSVrYC4k7IGuMKTI
64zF6w1Do3AEesHIXFxMmeeKtSGSkuHmXsUZxKvIotCbGpAHJD7YZ9qyxaYA HyUUJVY2rCtmFghs2IczhEix0+qGGkQzw2dBayP7yogbuyXzpsxbxxT5HwCk
Xu02dT/jmizqPk6ciLMR+0CyIHROS+PyIBYMOMixtDEGOm7AvMzR78PuK1bg W50KjoCe2e9iJxzc0g+flXp4DOAKmWDhP/Llj6uNpCD4bpKkumYVzjBe5aSi
2MoHznOHiZCIwGIpM3E0Ack4cvXt4Qu3q0vheOSJuGzLYjLb8bhkFB2ZYURD Md18YU5sBt/2tDAi19imRQ5UQcOsba4F8MEdBm2Nbe4M2hJwkgoFe14KmqVk
ehGz32cFx11tD7xyeUmYjPlBHDcxmUIU0aCdROouDoFanW/F6F9yEKIRkHMX +VJAtqEWbALWW05be3SDNznoWEQk8xJ7qiUlAoiuOBg54OAeYB6xR7mAsYSU
FlWlLsQNooa4snHj4EZ83DD5Gx7OXhqcVSuw59XAbOUixBgT6QUG92lhD1FL GcRvs4QE3I2Z6pJyBQAZEJJvby4p1D8vEg4/1UTxsjdO+Y12HczHjwG8j6E+
IXqYDZiacDcegxeK7r2iKJYNSL/WNxlq/EgXKwevLl6vqtMjiecC2yOPEDqv 8JJz1C/D+nI6ioNhLK0iqgd2AIgTILQKg3FGZRQxeawXp5Sru8nnSMInMcCm
RbsgVmYmsulRzelgmPYoR94wrNmYMa2PgGiS/dh+kJgmPZ5NYKMYDDsCQyXW Ah4m9WYgQwRWiB8LvtUQ/VjK/8aU5aYcqbEtSkp2xQWJuOVLVWQ0khEK8I1z
vRMQd1PUP8jFeX51rFaOj07OD+mUKY0J3lwhLYW+5fS/mH1YqI6OUC94wZJM MLbE8qHCaxiMVw2Y/+wzzD/LhOCbW6D1FzMdvGyup4V4STbA0KgigYkwpZWU
AtqgQAgoDl+cA76YODecGJEnroNPnLQjDko/G2yD9kGZD0U1Q0ccx9fR3QCo U9aM4nyIvmS4uVdxBokwskr0pgaKAr0P7pq2srKphjc6TVPQhCnLerwTJ0Iz
i9rGIsRlTY6p4FLw3nEIANEVibM5TwwEgOFjCgtZtHL8BIgPQ2sYMhxlM83M AExs4GMwDi4rExUhuQyEyQmoEaYHxuCHFhgZ4sgW23McBgApdR8lKYkncaSZ
yKP+fjMbQtQgGJhWgOkEOJH93khQOr9ihLAvgqY2ZpWv/hZG7sdKqAsVSdDv Y5qA5NjB7benL9yubkQ6Uqjipq2Tya9HdMkoOhZSuxU76UXCoaF1HHejPfD6
k/rYzhdmdYRFeWIUSyuZ0ZAlUHhQ4QAQjMzrYoIp+s3NOVZHKEURR58YDfaZ zU1J3ICFm5z/MyWc8JdsJVb3SQQ87KIvxgwTTIhpIClH0BUuOQwKiES4CfTg
4E/tbbNIUArhM1QJUKcOjAXZuwuTClOw7kZEqP9Fzy0DBHwkNyJnRJCqgxAQ TnziMIUYHtHeGKJV67DpjcDs5U2EqRkyEAzx08IeY5dSzDGbtDSJ4uqX1Jdy
dQ72xTLCjesPggx0iNpYt276TUjqCxqh4QIcKCdzjlyT/mZEL5HhydmomWFV QhMT6YgAjGSLmUEC7sMHr96gORUM0R7hzBuiGzjcelEDYkipV/MzpDjh+WwC
M45oF/rGRrNIGRxSNFyz6iNsuybDVmS0nry62g005pUAPFAnQscljLXe29je m8T80Rk4LYkOL0AvTtEiofDn9e25Wj8/u7g+JQxTOR+8uU4flFWECSdczxoI
Vtmo1MiKQNM8ePH6JR4xpqd++LDPAYXGUOq5Wv8FvHd+eH18TQ80nacmcYEZ wCGaCC9YqUkaF2wJ2f/pi+ubDZvdBTQRU+ICGM1kKHE2+KiHW6dCgXI+w/gc
S6LTGywbGCtaQXM01JZKDjz4i8FIpngKML2A4u0CBEeeoWGmkXN2to+JOABZ p6Mx5gAEi4bHMnJlO45p/0ao3ckFgA1X9i54YiB7TLVSmsjSkpMiwHJACUby
BZOqQA9Q4GuThmaWgVJOp6a3i+pMOIUb8+YkfxQujVweIWwTTEgSHGQqrvz0 wOczzX94fN9tFhCIVQSD0yowA4+T2c9dMTEgrxwi4MugaZxZW6y7i2nzkRK2
E/B1jHa8Uwf9dY/8VjHBYIAsBT3VTTARtTT0XUWgloWxeBu03gMFmsMXqdLT QrsSa0rrY7sgmXn/6RJKSrZVLG/IMSg9MHFOCKbhRTLblN3mTp3EI+LCXdXk
GTA3XAYPxm5hQU3J3TDQ6HTFpvqho4CMMUcOmT4wgOYE9MofQR/rjUG/D2I0 taFDkw+qvW1WDAYjPENzAU3swPiV4X2UzrGiqsmz6rdgSK3f3g/pCfyxYeUj
nqYGUmRxmzFR6PTiiEZB7w/+7Z8SyLs5AsgwqN3+eh1CchT3oJf2akeAM7gz UCwFIblggMwjBJNYhrBfRqSbzxuF5OugtKam9Q8nZCkIvaF/A/KpIJ+PApv+
oC0VTC0OoAbvOQGEsAwPdRy/sykHcU4hCpz+zuIt2WbihqLX+sF3mpwzEinw JsWWkeE5VMnibD7jNHGpxzbxRXbjgFLMms0lkeo1Fbcuo4Xy6kYn0FivAXBC
vqrhOz973fjEmhWYt0rWOSlAlirJDgjlFeZalD5GIxW6/QXbm7Bn9K2xigJY OyobEkliVd2eyoeVRkEFxvTJi9cvkVfxVMHHj8eSwcIjBo3x1Fdq69/h5evT
TMPgNAa83+ILZhB+jzRqME5HJcB9HNOGGi98xRErttpb3zLzTHAujGhQ4ho5 /nmf8hbN+KspCWD5k+psDEuFOWkZzdHQzKo4f+GvCJOgElzAxD1lsgUSjpkj
alqLdHiKzF0bWn4yP3sq9rehY/C/vnA5kUE78CN4VRXGP4tEYsIVSsI1LdTF I29jFyVt44rkBbkTk3mJQaPAN0MNd62Cp6Co5geIzU0Ehxvz5qQQFi6NoiQR
9LUQQ2JimAZg8GeRUb3YDs8NJcDw9k3LtsDqn3G4iowMj2v+UeeZMmEOhPNB bBPcTdIt5Fauf/gAoh+TJu/VSXfLY9QNTN33UABhsLsJJmKlhqGsCNSyMNaA
QSyRfBqLOGpMKG62SCvY2BKUN/a0DosYZaw4WHKTlWg4YdDwVGCQ7vK0sFYl vdZ7YHlzDiRTejoDUYjL4ME4niz0KVURmNZdWJisdcQl++Mf1xSwOlbGoYoA
gnsaFlR5RYuo4bjdFSpkqtTvMCSV47PT8PcIA7ReNoOVHwfvdgY/Eoml/Krz idGch975AUy3cAT+QZCgUzY1AHNlkFggFyYxDYFBI/zbw9S6E2QH3a06fAQR
RA2znEj+ZZUjCiINL1k82S6c+VWTbqRtvMnjHmXFGMN0OA+MbtNeuIXBOR/G D2C5hjUEkCKxGKANlcwwDpyG9LmwgmgMUTpK3ttyhaSgLAdOf2+pljw9iVvR
kU7KkCAoH7yyx9Km4dp8gfGsWeujnLS5OtEushJyA8hShmB0YHydj259w3Cr a93gO01BHEk1eB/VqJ2/2288sXDA+lVy6slEsoxJrkMkr7BAo8osGqnU7Q/Y
Fc9J1w0Ml9zsrxOcXsW3muk0tqZg63hD9ebylA4YRDzLA+IUcJqcEfbIeSLd e4U9YzCObRigYRoGpzGA/RZfMIPwe2Rzg6s7rBDhCW2o8cIXnPRiZ7/1KcvP
WXEApJNqR8Kgp005YgazAfJg+MzI7ta+ActdsiWrRuK4+j0m800x4QrpiHaQ FOfCjAjVhFFIp7VIR6Uo97Xh5GeLtOfSfhs6hvrrCxeM9NqZI6GreWkCusgi
MA7CvBGlbnKSoMnzoewrfL6YhcxAmQ3LzJrKUzRxApiyylN5kdR5eBVT5ozW Jr+BxEBcUSdaDqEnbKNzzQRWVcYavXaxz9iFL0xeA6awJG8FVxRHM855kSvi
gRlFxrdkVLmh2Kjsbkibyv9xLV/anHojBE6s1oQTiK+RY0o82hXleNL4Po81 yc0fdJErkxuh7FNJQpHCIctk6oTIVgYYgJmLWd8erWR7R8i/w9UqGAc23rmO
GWFk+hjpxpzQvkdexOQG0xsmU6u/Wr9XLAKYfBZddZOxDcP+DaJ1g53GeRmb ygS1soRrClMHaMRj0AiHYPrv5rJc4Z8iTqZRidXdvMoaI9hto4WnKv2+wpN3
xDw+V2DdszzG4ed9cp3QS1U+ywoT6yfWJCtobZwWUFRTlkpDNp16DCWwCgWl +N1p9BcEEjpBO8H6n3vv93t/Jj7M+FUX5RrkBcmFl/MC6RQZfcVWyAXisqua
LS43pH1PGd27wXCd2PdPCibrUCVmtxGmWWAa04kMde0EarZ4HytPxsJxYNjH FiRr5W2RhFRzY/zbwSIwhlJ74RYi14ytM51WEYFWHryyeGszem2+gOfzfJhq
Bj16bFTP8MaxD9K5pIN45oQxtth+dEkixCfEVqQdL7EXe4osCY25CuJijrBQ 0hb8xOAobyi8sBSnW9tGpK17AcBOYETpTncL4aReJXeamTmxHmUL2ZF6e3NJ
zSlhZvESD0UmAbSTCna7/D4/GEWJuOx2p9gYLp+sL0wDlqxFtbK+qg6QKA7g 6AZTgFUGiRPAJqaNo+ET+ETmtKoCw4KZdowOht6UE3EwHdASZuWMfm9tHPjA
B+iDDj4bxaSRWAYiwTVKw0HuhuTJ9rV9xNCXzVREv+BqV61srKpOPLvbmgAr lTqKDQUvll9waOwvWE9nCqkD2kfKdAmzY6wfs1WzaKhZVlANkYtOmUk1nTzU
o/Ag/rXDfzmacWTUGMd5jlbJKbmyucoPn17cbeEH8N8dAy9dONKIx0To1qtj ha2SwijbvMjMGwayHIrEauyYC5VM7MqYfQNxdzlykTU9ivNazbLBfCPdTjLZ
UzjgEFE5HAMDx4zPrqRIErwxa2XocosM+P39y1l6xqbhMS1X1qKTJbxoHqtB 5CdIAFLgS4LkcyqypPF9YWzKznByqwZZZNr3KHiZjrGYYjK1tq6NqyUURR/l
QO9QiX7w4Sb9dHFnIuVxM+eeqif8Fz0HYZWUPJksmHDeoqbxIdP55fomzCPJ FP7oOFxawjShUptHYYyCaJ8VCY666FLwhV6aF7O8NOUEJLZk4tZ+ad5yPmWt
CWql0WDiLg20vbO3xUo7kSsCH3OeWt91LKYt8hKkmSLebtLOWaBwTpWEx6xD NWA3LGTggGsp1GzJuGENhMqY5w0rwpkFPoJgsjXkC8yw1uKKS3xrQsRA1wBf
VKg5RH01HsUZGII+3MWpi6ndwMhuEMScVgRkkLBCYbM4OfQD3NTxLZTRlnHR c+a7eCJlJMIGhn1q0LPVo9Y8dxz3JFtItYnnbRiHjf1QV4NC4uEZPmdIx1pj
mFNYLMDBiFTSio1ZTKuVmMxCPw7v2gWUyKPbCkeRkwTWx8vDwRq6Dg8TGp88 jYUQEsyO8fixS7WbhUtyFWUDMFcmBO0KBv2EFhW/ciSfEm24fHLasPTWr4Y8
6YX4TuHVOsACMSPkHR0u2ogozUosUuF6I5T2aaqTLozFlkuFS9DsiLoP8zyk QT44gR9gCUJ6PqTzXY7WJFNHVT4o1JAz2U+3XzEsZcsfMaooBY9ryex+dwIS
QNTcPwqDrQYpQef4slATMPFTNjklq9BhK/ofK/gX1AfBlaNsCivj5P+Vg6PX jHKN+Nc+/+XYxHFOYxwXdtqgkCYWP16+ud/F3+G/+wZUunQckYyIrW00yFaG
qxwczIYlBz6MEEO/My/NH+wRMls8VKh+/B3whx852A+jrgB9HCRxWJxhPpKQ AP5Q+Y5AZGMRaUfKLQnUWA8zcFVLBvL+1gWNnhtqJEorBLYMqUQSTYwauvPw
fdfYJwvmcA/zRKsWfwUVMQdLo8taYwI0SshkzvmPZWkz72hE2DuCX4JuBIZT SWyDX26yTQd3JloeN3PtWYDm0EqsR9E8rXgyWTCRuqVKE3wm1BV6HBWxVBs1
621TK1evKcTjymvwgDCw6Y/FGHGCrhVBAfgfaXc2fQF7POT8mWa73WAGqe6+ y3M6tRHhU6wNpoH39g932bYnrkVkYHVV67M1S3TL4gxZrkjCm6pv1ihcvUWG
Or3EuSKsJGxinz0P4Igs/T0+1XeifZEqRIh+H85NdLPgGAuFsrvOLPOP1MxG lhdZFaaO0KxNhkkO3qKPB4kOY2U1yLMxgpzLl4AjUjYpbGko55tAljrxhVra
tILso6YiwfLHFSUaoG4iqWDCEwCRSR7EvB6g2xmoSaUtY6jSXEvRalf8GEbf yi8acwqLBbgYpUrGs/GdabWS8VkaFuJduywWhYZbGWkKs7j14WgNc4fHiUx0
Ap0ZC4PbsusB3dA9nCLZTeKbCcljE0YQbYv9Dka0NBSlgpy364T2TZ3pgN0d n0JY+FLpnTWAFWKpyXvCNnqSVpnxUR9U+FmmUxiKHZw5LkFzXOshKoqIslsL
zhMbPaQtIuXWlBpB1DF1/njY3xt88cUX6ljC5VylQkUlvYl+97b5t1etcmXz HxWGeg2RgtXxeakmeVll7JdKBaOjXoxlzuFfsB+ktOssn0Z0OBNeWD85e73B
JtNqOpREXIdZ96F4uQuMuaDLVHSPmAntHlN5KXWQa1k53gUPwDTqx/FYDcIf qcd8UHFKxUT7MYDNS/MHe4Ltlg8VqT//CUTFn7l2AEZdB345SZOovMI6J5Op
gXRTZYLuO9sbzwZfOWFIJdYloYrKqagRRvWVsFXlCl+46JdkGcO+r160ClrA FxtxyRTuuzzPhiVfoUQs8NIY+dZYVI16Ml1wqWVV2RI/GhG2jsCXjB5B4dKG
yjMVOFxWY5Zhz/qBJIBMCovhqXGMqhcrt3b7QNKnB68PrACw62hW/cSUroL1 69T67WvKHbmTMgEeB6wPxeRwgdEXwT/8j6w7WwsRKtTs9EyzT2/Igkx335xe
JrOJ1F4hPyGcAIs7xlCXkEwtY8FliYw54cuLgZftMLvVQfmRJMtuiyCJRWFg EX8RwRI1Sc9iA+Sjg5k3sej3ZWYQkflDtDAJ05JTNZQm7zjfzUeomY0QhMKj
W4NieksYRixuYSy52eK6K4GXGgzgfz/W8xVW97ki4rKx6BX7NWfRD7bU9ljt Zh7B8kdzqltAA0UKzEQiABmTYkh4PcC1sxwYAqsIc2B5Nc8KhA96GR0Jcxhb
bKkdrXY31WAXzl3t7qmddbUTqd2B2hnhJ4NNtTNWuxvy1s4uT6q26N/Buvw5 C2xmPGrfVmKP2IXuyxny3CQZT0gxm8CmmFwcnDCKpmEtlRQJ3iKibxpOJxwT
2FEbe/jLujafw4tb5q0nTWEHNyvkweFF+Iqe8Xa9ZJP1pBC7WZRTfclUwb41 cZHc+DFLEfm2ZtkInY7yefazgsfBZ599ps4lX4+rAB8vwRSNIKmWlnc1DyMu
faXWt3d3gJ+95iNeV40n1IpXx4BWyPNRZkMOq0HDv9bIuMCcYiRJsbijvjrB XPIyulU7aWzNH/5Kmud3ZZAm5pQlWbaUjFpBoonEKvEUyS4fs1F/7vVUL1L4
LA7yqd9nLmXmnpI76ufuPH/BjHz6gD53cHCk8OhZOcEy97wAHtxZw1A2zu1U L3igtez7BsdHg5vGotftx6q3q/ZGan9X7Wt1sKN6B2p/Tx0cqv0ttR+rg57a
77SBVDJVsGJRaK+NQlt8WHxMP/6dEGigtrfx342NvwkC1fb8VyOTUnvbn4hM H+KT3o7aH6mD7UDtH/BUapf+7W3Jn719tX2Iv2xp8xze2Q2eObAdNzBDwjvw
z+FZRKgrWx7p8KMWa+mspWtw3I+d5DpuCf79+53kjtoZ/m1P0u35rz/Jna3N lD72dhi0N1OvcMBNoejrSskF9iHpKrW1d7APTPKasbilGt9Q61x9jyb6V8Pc
Tz3JtEsnaQKgRiZgUofNYa5Xp3SR8CcSfcXwkWUDaA+Psp5+Fxfl3+cYQV2K hro3TMX7OPlqjefFEImpZ3fIbVQNYEUsahXj0HXVBVYiUHj3IXflIA9UoFDH
6BiHn/sYd+gY99Smd574+a78uwHvDtXm2MxldrQbfVYJoLY2nn3UUU82u3Ta tgtDBTMKLwPR3AO6SK3qWTXB09VFCby+tomZV5zbGXxZg5RkqmDdEs5hm3B2
dGDP1376FXpHfKHA1WJnYvkeS4uCJUl+LEM6XqEn8vOe2M0dTFsrQQz0XnKE GVmMqz//S8mmp/b28N/t7X8i2dT290tJSKnDvZ9PQl/B1x4jo1s5+YZiEW0W
RZlEwpF8LjlQQbP476GfpW07SKdtzBi7FDnDiEx5fzDVURxKVtXSHbAHE9+b HrAe71/bzDYBz0+hcAv3B//+q1G4r/YH/woUuv39YhRu7e/u/AIcZp1HcXhZ
pqB0pQCb7e1N9Zc//6sr6DQuCNHfTJQLyETyHbyZYpeZERb15Iwd0uql0MsW k+pUcmALbuuHKzrI5xNJCmLKwnI9Ol3DXL9PyupfiTtQvTHhbvhpcLdPuDtU
oHGosdaXo57iSdSY9uDXHkZJTTTLJXa+wHp+zz9LJbherZWx2SQdDPTJgryZ Ow0kHsi/2/DaQO2MArf6g/hTCHi1u330XMxOdjqEXELEV5sffo1e9XNkPp9u
pXQxEG/s0864meHB3gebqNHsn8Hu61qjD9MRBcNAZL6ZsYparveCILbnyuR5 uhL36VxOmq+oQ2MVseYdQURxHYrztYZVVdi3InzJ0Xxb6yb9LExFThD+jJ+V
KEsNLC50wqOfp+6aolQxVLW9vD7QZsgPx944Wg8Cu7BtDHxzk+uYeCoww96k XRfINGrMeOnSiuZodjDVcRJJbc/KlXMUDN+bZnqaZwCTvb2djjtfaJxXDKEk
CXoBjStP5zliXHhLfkUwaiO0qrt1ZZtijpcEk+dqq4t5TafTmVcJCODHlVt1 48ykUYAXJNfuTZO4EoGorFcJ7JNFKIeR7CEpzmXVeirUSw+J5bIQfg0xDWfS
nQI6XJlg87oZppzaUjpPjQ3LsyVJPPynn5D8cLSekdBsQuIZ/EbKpUx13qUJ Ja7g8AUexPYCfHQi1DsPZOx9qUiaRUVJ4bBKjp9LOO95iG1WF7DbaosEmr0P
KVi6FSv6YYI1CfqCboyuRR2XbW0FhZMkXF+rV7aNcWqFafQIF9s1q+yMNWvq OOxZa9JgulhgCoFMfzNWWSs7buRIySB18TCehwqlwFrXlAtqnkGSYiVwvbza
1uzqxe1tnNbYU3A0Ai3UGOfk8iMjVxxJc/azCwnU/IpEHJb0zKlg8jQZuLQ8 MjBRKKTDgR1aEEK7tAfQfV+Fg9M8F9jwb7MUA0omKqSLAuktuqMQFXhEMbpk
KydzncSSam6sKkPD3KLCZo2yM+oQk1+BiJAQzfZXZSIyyKWRp5dOxnYZnZ7t nbrdTFmtGwLKV2q3g1U2l9OZd1wN4I9Lt5Y3ZQO4Rt4WHDNQuX6ick6+zfey
i9NKxefUSUkkQ0RG3yhZ8gIjxbSL+do6tYW59dCHQVw/umVAathQuzbQdx9b G0KS+sMHZDocLTRmGfsfiITfyQkec4TsxsSiLbeKC/Y4m5picaE3pteyTsy2
P9BBK7/M5adtSvqHf7TdhcciQ9M0hoeZc/RS95oSwfhJl6WS4StVYVs+1N5d yp9SEZIQrp2gtd1Maiem6Ct8HKx5Dsy4QuZAlV29BE9N6BPbXg2HYFoaz46i
zgRXuK1MGcZYAMeOmwWCjkgNAX8l+YcmZH0olZpMZgCpntRufmglsAs6F5J6 ReQUSQxiwdFa4YFaSIq4w/KewQpW9Sbob9PyrDYsdJpIsbFxkAwTc88FW7nI
gumb2O/KpjXDOUxAc9Dkyx4oasFDKCXniQPbPNnQouy7OTzXyzFjdVUqtzHI cYxTLMAELkJONNvf6MhM5MFJN1qvuol9LEKf7WrSKhLn8j2paUJKpoQJun4C
bZx45HzzS7WZ+8hoGjsoCky54U9h8iu026DuYfacH9LmE64Vh6w6Bibtp8hz JMXci5XEOrMHSOvRc0O5fl7EwNQIovapNT8UaaMIJ61SJ1cqtSMVBj5uO0vx
O62SMp4l9TXYYKBZHHah6NpKY1dlzJygS9Yr0FBFKRVU50MeoiSrlezwUUh9 IkPTNEaKGUR6lWRNRWBCbKsKmfCVeWk7EtTeXS0G17kjSBUleCiL3f4l+o14
LvXUcfULkzCfIpfF9Rmva0wZbQMbFcH14rKETYeFrdjg6Ypsqtls1gkyj9OU DQF/K+VwJuF5KmcImc8AUqGcKvzYKq0Wei6lugEVG/ZPsrW1gIcJmA98sqbH
fHJxWpRhW0QQbo+y2dwet3FqWXJrSggCPX1b99h56GW5P+NXy9pWcZJUWHJQ zVOIpgSf1BfP0F5kafb9QuExVKya3JATxpgiNSEgCt34R4pZ/MhoGturCky5
NmkirDeqKrPAFPl3aropKKUYFuzU9STMReiYvhY/+I0tfni71qH+KFz2T3RN VYs7qug2qEMq+/JPRBCGa8cWNpwEk+ZBFPWbztMqmaX1Ndh8klkctkXo2POw
6FTTdp6uh5Dm+2gfjfpb+6TcrSyZY5XeYOHxlCcvpGKoZeS0rBTrP3D/c2aJ 7iwsi4IO+aTAQ3PK2NOhEwq9p3nt/AijQk6TUjsUV1k/iYopDozrMzG7hEqm
MSEeMk7U+oiHCuozL7EkvvpK9b7++oTYxC9/2QOmyH1Rf/Pm+PK3wL/KsKyK ejbCjuvFZYmcjkp7hICnK/OpZmdYpyg9LjOK6CQZlmG2dATR9jCfLSy6TbbA
ffX6/Pjy8vwStJBoXw3cu+MkvIGv8+grfmNfrXfVweur744v95EODt5cn5xf sltTRRDo6dN6iMcjLyv+mb5aPrRK0hTb+9GBshpPRPU2Q1UemMPoazUrFcxT
nl7/lv86OjrlalkcxI0Cr17h5+rq+BD/axfX9EvYH0Ap+kG8ClhnubTF7E5r zC6t1S0lzGSvmU4Lf/RbLfzx+801at/Bx9OJr4mcavbO8y0Rsmwf7exQf+MY
kU8esyqC4Im920jn8jmJezKbiQbaD+qd5pDTNF1aCySiiW+wus+JB2xsmwoj 7Tq1vmL8jYC1xlPfeiPHWnwHpuWG2HCA+59zPoLHvQ+1Jd5L4OZqOw1ffKHC
JGdTEgcvTkWyPbFfULOvQlPX57iqt+7HyCxoiMQnCz5miwJAbobA7ngTR6vp r7++IDnw5ZchSD3uivy7t+c3f+hgvW+FXdJfX5/f3FzfgJ0RH6sevTZKozF8
ZFbBYv0Ew5iSP9IPTmw/tySpVfIutmTCB3iGPcemhrxAbmPyhn2+qVSQxk8J UsRf8JePsQPgyevb785vjpHGT972L65vLvt/4L/Ozi75dCa+TwPAW7f4SN2e
TssnayspKEODpTqKaYrlF56J1mZXEUmrwxP4JzHdVLiXAeAXmSCF5fqg9JMq n+J/cTXN4IL9ASKhH6SU1a4IsvaNPU/t7BN58pTXEATPbLFF1pUvMtw385kY
/oE0dL8FjlmSLQ4vKjiOguynMRwtmmFyJGystJUNm7qRskVx2q7hQ6lUb/th m92g3hAMRUozIrVE9ZkwOFv2nKRm59kcckG+Naey4MWpqLBnNq1pHvNvmvWc
dOs8x5IlOi86vNriKjrEjf5gG0uPCVCr7lvcEcClMS4TSQp2sewEq5hr7wi6 fPPW/RQ/Nbjj+RqO5Z8AEAVtn6SHy7bUrC9rSrEhkqCTwATl9d3CWhv/uN9y
YNE/HnZIdZv+vIENMJsKNGv4CVxN1BSnZoWejEKdUuiSMdcoMwEswObbNrtV p4WKF1dJB4vIpjG8RENjtt9+v2k+kHFPdTCrJ2ubI6gtg5XWiOnO5B9+EvvM
mVM2Kjztx2sbZiY0Ft+CynhrS8RTDToc2A1tdBuazB3W7mtAdkmpM1jFLKfe riKWlnQX8E9q+nvwSXogsHP0Nkor38G+J6v7IxnjfisWsyR7LrmcAz5K8pVG
AnzWUp5twbiQdZlywo3+u3fNwyGrIpRdqGyEfQWUrxwS8Iz6FI+lYuvdjBqh gFt0uQQn7Je0zQqb68/YebhsnyPjM61+GwpjRhcFnpBBhBHyamtDIonABuzt
Ngw76hGA30sJD/VFrft86rzDlCi3+hOIIm0UXQNcHwCOivoNq3ZKbb5A62Vd 4XlXgtOG+xQ3BGBpDMtMkoELLBvBo7O1d4Rc8MQ54jqiE4X+vIHNQprzTtbF
GWPCsPsGwtkOqhW7BmxiNZ70JB7GlhG2RiZehNHDSD9pBlHHbW8IVLS6hKxO 0wxWk1zDqdl0J/dPZ5ThYso1VksAC7C1m80+SQbJxlan/Xjtq8yExrdbcizb
rbSK6QK6fxCkTzRakL9Yq+UldU3yDGBKitb5zRwbvVFesA7JUuhakw4zqKsZ eg3JVIOxVm4sobaBqfRgM74GZFfcOINVzAo62M6olkPBFoxLRZc5vLbdff++
8bEVSp/BdGcxSqxenpEPCLvVrYp3BWPmubrBht1Y4J1RyXGYWmcIIAR6qv18 iRxyHyLZhcqHeKhd+VYgAc/YSclIjge9n1GfyoYLRwfU8XM5OkJtK2vM05Ad
WVZh6e24rAnbSkwA3egnZPpXAjAT7Zk9ttEVCVIvwo352Jgu0irILzirsjmJ 5pRs63C8WMzGojXA9QFAq6Nldxv+65QaTIF5y0Yxpg5h9w2Cs40u5xwEsEW6
LKpZTJHrmwrGSea0sklYMBBMI1vbL1ZAiCd+fB3eSDIAO7r8JGLX/Q/bbu+w iOlJMkisIGyNTKIID7fG+lkziN1tGxOgRdUhYnX2o7VAl7D9oyB9pneC4sW6
aPM7eBD+o2IEu7qpQkz20dqZWbxs7H5jXHee0kNhPMwTJZ3nKDvB2g50adam Jy+piY/n6lJxrS7Gi7DkpiZTHZFL0LG+G1bizmckxtZN0xUNFgx6H9YAzync
RW1AvBFFZZJiCEFscTZy21kUco2vMyWvr18VTecLETj5j7JxKQhecP9QTExj g+3SNiSOgqnVQo2xUzoe5s3p1GuU2bAHEARGnruBK6tkW5XeTqqasp2Lra8b
whuLsYTs0asJ99UiaVRr5yoq415RZ+G73sGNdsU/zVYLVG0E+gGsT5YX1OVr zW1Mj0EAZqo9/8Z2XiJFSqlgupUGoZRiUUHrTHjJFXjNSWRRzXr8Qo/nME66
oWgdhJYoQLAvga29rWWU4xB1c3Exwxdrm/iE+GGKWvpea9E7A9uetJGDS6iw oJVNopKBYPqN2raeAkLE+Hk/GkvOmGNafq2pa0HX3ep191mz+e0jiP7RMIJd
bf0uVlsDe9eM4vLJjFbbYlwExZJ4fRQthhttF6W9zZ2vOTZBPJoTboinLCWg jecRVoRo7fwpXja2XjFROs/ooSwc1hSSzYPte9a5lVJtWrQGJOxQzk3pBBGI
8CIQ2uIQJGJNRlVCqEIv29Ijl4pqy/poyb5O0siMqTWKyYC4xMniCWybcF3L PR88cC18y9z5jP3+q7IZZiEGp0hRPqqEwEvu8YjVTMx4I/GKUDx6x5J9s0h6
s94PruTRBsAIWeq2OWBrnMZTQC88a+614O8Vt1dUQ2pSzikekvpMyGBgJA1K idq5yrmJo6ir6H14MtbuGEnztD+dWwHzANYnywvq6rVUtA4iS1QgeDTenvSs
aq8KTkgiPvDOd9wo2SYVpjFxCVKkSafhOqTcxzXqFkURCyMAieSBS1j3ejLv FR7jEHW/cLnAF7ea5IQEXMpahVZr0fs920KyUa9JpLBnAyzWWgPH1oziao6M
mtQp4jXjBewM4VOz/Bt+O0+BsAX2tCEaUVrESn9s3lbJBgTmCBaCSQAt3KpZ VdsSXATFimR9HC+HG20Xlb0tsa6FMEE9Ggw31FOeEVB4EQhtCf0Rs6bDeUqk
DMKTYMX2l+EgUgPu05Bs6VT6AqMXWoJv6Feb6Vw16VdS2jkmAzzaxRFaGfGU Qi8b798rXbSnxLAceKolROJpYVNoK+eFPZulUWHhU02tFvc4uJVhGxAjaql7
7pJxVQMO5+N1jXORg46OW3v8zes3YdopMtrUyKiOZ32K2BYTlN65FZWwjziT 4UCuSZZMgb4Q2Xze398s7q+cD6i9NZfPSJ0sUYMBkvTFqL0qRCH12iA833Mz
7iSzJKxIyHl6Vkufd126Pb1AAhl4NlLiahRigmIkpENIDVwtso0m3JoNTTaI W1N6RiOAWUGygoLiZNnwyZbCpzhqWEQpCqMGifFBVth4erromDobkjijJUIN
wyWkE5hGeAAYIzCuRH6ZFSJ4aMCd7mKnMAupYisPz+HIC75HbXuGFxeg89po gVRz9BthOs+MsIe6aVc0ojQslWbGvLeK3QgsJyuFngBkuF+zGAQqAYy9MCNH
Bx56EOvEIjrgtZzpF+mZ+L5NVC/Pfs9KaOQ177BzeDWVZPWJS7IuFGlZJu8O 5Nixz0mypUvp4IpRZ0m4YRhtpgvV5GIpguYkDEhqlzho1VBTpUrOxe84nE/d
e91lqWmSJ4YPfc4UKmoc4EEj185Xsj7ad9fkPywLm+66gLL4eSUdm9xNTcAy NflF8TjCufaknNf4wHT5Y9qpMVOd2LqUhy0nqMMLqzBhH0ku3TNmaTQnVedZ
rqIhYu6DHtgyqQrZCxJSmBb3GssqiZ48i0PS5K0Tbn1/AP/f2N/c3yIqQPLd Wy2j3rVT9qwDSVwgbuTcpDGLCYqx8AdRNsi22DY3cGs2nNngEFfGTGAaIgIw
fbaz94yU7QWGmyQRkCkoGuonOvEEEeHRvd31Z39Dn9kfQEEFXWGh52z9P89z J2Aih/wym0XwpR43W0uc2Sz8iD0lvPgiL5iauM+w7z3Gqo2N4JEHCVA8lgUS
1vKe2bF48qeNRIfTGIkOZMGJSjCJZRtT5D+mEaivX6nX7yTTe8VEPjdXTUIo l8vCYj2TULdJ4xX5X9gUjb0OEnYO74weuX4SgayrRu63Yqq0sN8awibOOaLJ
aMdAGX3KGXFNDYnTm9dZdawHwOuZwnXNgjtjOpYmiNX/bMj0RMw5Pjg6vnwI /g99wIwq5hxQQqMayze2fnawrimGWCc243MBVX/zStZsZTB1osr5yAWxcxfs
c/7l6Pzs4PT1w6iTh/85Ttc66BvYU3e8HthWOCZ+t8hltijSLeFte+5bq8jN wZZrVcpekJWirHzQeFSPOMp5HiScpc7aRt62jnvw/+3jneNd4gVk4oOj/cMj
/aC1acxh49p/+fO/Mg69IWluL155rrYFaTxUrWPM3/yEW7zhzcXRwfWxzxyu MryXOHFSIUBuoVirPzNyJ2QIXzs82Dr6p4bN/gpmKVgIS4NnW586eNYKoOEI
T88uHjrgv/p0L3/7V3CFJ7tqGgJY7BeWX8FSJ0rdIaG2+uvbauXNUrfDahAb PNuT7xPIG+/jf5fhaXVgjh0+4gDmwlC9fi8lwOsmr7mzYc6DgkUMXNClwg/X
Z/ki92jDz2NyyEmXyoLlflhTjd90G/HrzkfjljWcBy4ZTrCKFr987fTM99Tw RY/keiiGYj2zXS8frdsRZYUc70SXkE73HyaXp+nj/OTs/OYx+vj92fXVyeXr
jFDnLV2Ao1GntwUBXpIJu2wvj9VLuRngoQa0i/KwkEIuqmKCJGZV08K5gqX5 lQRSRJ8yuloHbPcRAlmJyBPbYsWk5JbFxpZlryVlbbG9u4ES209Em9YPLlcd
31MzrZaNJx1A8V64Dx/qXU1tq8M5d0Obp6NJnqVZVYCySM0K59ZTz9WFzZx0 1nBPJoEEPnJDTm9JmdvLMb5Se0JFHjWv/Stw3ZIFb9+cnfTPfWHQv7x6swLV
1vYLz8Mf00NgzbJN6PJ70P+BjmfTTLhxF4vfNdLMYprPxEYnIk3sfjJf3m7O /wieb/7wy6TAE9z6dHimoW7FZ2FdFawMnDSDELvdrT21/nZlrGEjSEyEfFlI
h1yzVSK1ZCxKWIO5cAHBFRiZBLQRkZBzs2K8OR45Zw5qNujsZLW9l5DFb7Sm tBHcwSya5Nww5bQ69mqOczdjRfy6C8y4ZQ0WgatoE5Kixa9ee/COmmwR7Xz/
woVKwDKjkpyS9eJFPswHG2BmHCCu97TDOszMM2DZgAhr8ZT7MOW267Jlv+sZ SK0c2tbR0BWQX7u6Eg7d3pyrl9Kq/rE2qMsKrpBL3szLCXKgtU5LFxKWRnTP
r7PB47kfgu9OVX6XSvKoG9+AM21wca2emq5vgp0SMYBMBGIeZdY+kRZ4MAMV LalaNZ70ocRrIj9+tPU3bI/PTMyHGnMtsuGkyLN8XoK5SH3zFjZiz6fSmgXl
TGmWVeayD0Te2rpqk+EE5szSO+7t7jJi8P0rO6Axl8id4nUx2elzcaAjldVu bO+XXqQ/oS+BV8u+oSvpwTgIxp/NmdDGvRl+z0Izi+l1khibCE0xeH2xuvOZ
4GGL69XrsmawgQcmQ5DzyK/ExUCQnoTJuN1mHfVkqfnQS0AYemjnzYZNyLnY D7hm1z7qmlhWsAbT/R+hFRhtBfwSk+Jzs2KCORm6oA5aNRj0ZMM9TMnzN1ZT
iVvEBCtgJOt3yDGxJXlObkj6fYTQTpKa8cNT2H6WM4o9uuYEOy6Dxx4NAIAc 6VIm4JvRCY6KLeNlscxH2y/mnBGut1fD83u558eyC1Gr6XiIMj5WKzv2W23x
fJlwPSE/asXlnY8cgo36SR1BN1jsu+fFLfCiyaB+rs+IfBt0ou5AU1Yt0qJ1 MhsKgI/X+1FV5fdLpMC6CRE43wbX1mro6I7h2ymRAMhHQHnC47dQ0oIPlpaC
pujScHkh8AanXjU8Zzv9reZJkzvVTxnhevGhbTE5J2elK02CozL9Z7Kmadsl S82qzNw+sYSsvelwCoO07J57jrsaGHz/1g5oPKZGXGW/yyfJHKdsdAKPWlzD
5zYH4LD1c4buUNcMyWuxDFIKi8aQ9YI9iSOYKT3/Lov1iQkWrlCsZb5a87va WFcmg00hsPqBgkj+CU7MB+lJlI7a3b/RRqa7UfDxchhGHtl5s2H/AT4bw01H
FnumJ0UD9EZ8PtDIuc+KhDZO6pqmYKv7rIix3UkNSPDigPqIYkCbPbU6sLY0 gnVwk/V7FKLYMbugcCT9PkRwp2nN/eEpbMfFGeUg3Vn2fVeyYzEDAKBAXy4p
koJqcRuaiGGPPvG7eJ/Xg8aRV61tdE3NabAQuTKC58Vx6u12PRjT3VvcNJ/I M2E/agXloUdwYLN/chygEyyP4fPilkTTZFC/uGdI0Q1CaAOfKNibGMWYhqsD
FWOPeBqga1Hkptlc1iQRh0i22EhKuUJYhiD7Rbjz4twdzAxYOzkzfHKO81E1 gRe41KqF6N0moimq6peI8BHjgW12uKCYpa3aQB/VtDTJm75th2LcnIZDmeQt
ZQWssJfhtDwqIiTNNRrh0os0TDE1cnwjLkTYs5AXoY6Jb9wwUFSQRQHiTLwI VBaoa8tzjXe8DsCg0vD0EQpl8DRxcLMaLwLMRsDEZBPXKRuz2KhFZm3HN9Pc
XrZz4W5ENFfwtdsONjGVjy/wu7kKKVCNMvAW0N7jYjI1cYcpVUSnoVf2KtPY oIEUo2sf6TPcZbNDmzB2za6wx8Qsk9oWmgZa2Om+PqL41mZPre6hLfulpCOd
m/NIvXtXeg38kFEvbeJHTR7r957Wem2HJpzJfu/sXhyo0iE8pPYwsgYvwIJi DbvFCE5fXrmMoNfxxDFeratxzSiqjVKaOw54Xhyn3hPWgzHdoMSRmIgvQOLT
Oy5GFXYrCNpsj4/ZFcfXLlAQT6PsB6kCG6lRX70zqUZHSKGUzE4WKIqNlEmr jYgRsM4ov9NsjmqqiiNkamxcpNyZSoFiLoX5eFOCQc0MxD6FOnxWT4rhfMoG
/AGLqydWY98W7K2LPVpm9nDoAhpKPT8xLkiKaNJFGmXWwxBdjxIRv+La+VC6 W2mvamnFW0SBPn33gzmVi+rA6BIxBNgAEIWPVXDcxU6sk2U55FwiDF7xc+ku
0fp9CRs9+veDXEttKB1a7RqOFbZLTc7yh1XLujjGYl5c8ZKiTfwSHy6CBc3c tTO3qbV74TVplREY+E1HhRnosCvIHbD4k3IyNbmJKZ2szSLvBKVM45rX5Xz2
8c52ubpiqCkaC+d1F2NeykKE5uQFRGigmHvqZvMgYLA9tBnd+rjxAk4DBPNW ttZcLljZXC5onsdr3k1b6wgdmQQoR8rzBwm2Sh/riPqOyIq8lAwq+KQczvFQ
aHuJULaS6KDuihnKIWilyL9JHTm9KUxCYOU+5QDQE6wPP38Hd4Askei9fqUj fNAWkIx0d+a61u9fopKyO+QSbOJFDd+u5JAzwg3VaX6xxKJsVFPaEliQhvWq
7cxd+ujdh9U+zX7wnQzC116q2t1pXWzaOHex2rAs6co1LzMf6aYKPdfQKDON a2wFgg1hcyy5saiim32oLv3ChCspB0rXQFR5iEk9rlGkWBTnP7Fbqt89r9FS
DgIJbRry+BIZHPqE1RQs9cRqfBJIQ49yKk8w5DwYEaTNXQj8iNzA6S5zlmao /ji40Q+wHSPQa5dIrLN/a+qZP27YUNS6VyJtcpz4cRk80mT8wTSixaQtIOk+
JPu9phHrXpCtL+2x2VbQtt0581V4G/uUHC1PtWlmCmOPE4xTARCEPg2owxuM wX7IS2maaxyQpoFpHiLTAX0lNLC/sRndBsHxOkWzc/NWZFtUUFGTmKjuYhQq
mSAYxj2q85llMWhfpAEJFDF+YRoV2KuLZBEcxi4zbC8i/vMmRGp5tn1nStiA NWgVzb/NHEe9LU2B4Nw95TzRM3wTv8wHd4BykVi+fjkfd2ay1/d5Fza1UdgN
QlF7PJZoIVOHTMMToHpcKixzLtWGVAdKYyr/yj2ixts4JX26uR00ZmphdLqO vpNB+BJDVbvqq4OtAhcupRtVFd0Q5pXqI7PMIy+mZPg2HwWSATU88TnKOAwa
oFpiVEtbUamxtq540vroNZyCEaIZnBcpYFPvTd49ZW61eqE0itoBk4n/EHLC qyk4b6m1ByXfhiHnTL7BkPNgRJA2/fr5K3J5ortsW5p08kWUXgeCLT8Z15VW
w6YwqXeETIavXPGDaKEE1zHG4rnfAm4JsftsC1vrK9Mzxmi/OFNz2Y2ycpgl zuxMaNuam4UrvA9K8fJsdUlOs3YYm2dg7gvAIGxpgB2NMa2CgBiFdBBolidg
IPknTRvQNCkku/z4+qXJMMZsFNKBYRkj7pcDs8MfN+jWp9peXDipALCgAtYi npGJJHDEFIc5926v3JFFcL67yrF5hYTYmzCpVd52na9hcw6l/3Xy/CivyAwi
5eqp12+PDRXeNzKxAB2zIEgwIF5fJ10fUy9nwRz1KMul7zjnxwW4Rpir1jQO 8/AM4lq47luApVTj2cBtORvo3xVHrHmXZGR4N7dFDbhFzNXZYRWJB8E3fCjb
ZJIej9GRyJYOljXMxN4EPQDVk6ad5doKSkVzyD4l9PAksRTlIzjo8kjs6Z3l 9NF0KsBnJsAp3UW+t+11kacEOPfvI9F5ym1dJZULvJpU5paK5aMKpk25UOkq
nk+BlmiAGBZ8fHRLqdcQFtRZw6zggQDwIkwyhoTtyN3CMVK0gMWbSyP7WDGI k5ZzBMtO0Q3rVit6S9pmaWabprcvAF23N4DWbrGTprZyIWhjk81sIe6SooPG
jKAIKIwV3cXS/tvBmSVDcyhUIdm9C5qtibaxJe1QqKs63IsDveasmmA7Zrzq sgcaw0NXpbP3EzkL3NC22ARKPGMDlEC4lrr3upMCB/j1FVdQu0gFXfSJGSVS
l1UI7I6NF5DfgBI6M63v8fLzqGqUZbHJYqq3aGGk/CLoveuv8iplBRg4sXHo eg/eWQ5qai2VMrlUF2DsYWqTowgQ21mAignYzEKQ3SPM/LtSMUCVY9s8LTlI
0G2z5vIvao0ruhmxeIBTgPlheeywBZc2BlnAZpCdaxpKgYoFho4swRacODIl 87Wd+jWq7ClQKYM5xt9qzcjJN4pvIzvQXBKnw7oG3LiotlpJR+1GGqQxudDS
wAJcWYRXMxMo83BTdq1414G9kICkhtc3SxrVIYuG7XX69l6gjQHdC2QvdsX1 pcptEbfbAyVUK94ZEwBdHk2hpELX+nJ61yLR+9QLlcgQdyGWvnyhJQo8EdVS
9JjBvF3y8QPXvXrUu+CyVUV+XJBrWlSjuJBL30e13hVkMsiYggDOCrO3xxaL Lyin/AYYLOOi2rk3Tp421PASkYeVupIwtplf12rfRSH4g5bYC7CHtMsxzPJ8
FFzk7nw3Y1BTEY3R0H7J3SqqvvfbxdWJ3hKCcaXh/a6SZo2G/bwo9VRdnp5f RGCuGzhCwFJNBT5rnAz5Kg1uukNiK5G2HaZ5xcJ5NSbggvDiYqAy4OgmX9br
v/3+BgUpVsXijbmvzO2kdJqgbOwH+5LgTM6n4FvNkUzsRQSDsa8SHyK21Yt1 yzOuj8pkgdK7CoZ8HKBdLsxaJiaoTbZ0icF7ekladNpbuTyTymEc2WoMAxJ3
Oeb2/CjG0cHILoz1TRg7HmmKP+6rV99cvOpt9NdJvSoxRcM7fnzgxzN0uMCJ ngizLhEeNaCjhjIwdd9jOZRjpZrfmJgcH7yX1A6aZJh3JT8eh9exZ9iy6qa+
X/WxdSQ1Af3llD/rJ/zBr8uqh8FQwOp+pL/+EWZAeccJCxZwjYGv9Ay2jqll ZnLAibuD8zW4JlDW8QjH4L51EzKf07CmCd+HDIKnyGrX0aR0D+tYbryr3epl
G4ONLT4B7hX0qSdgjL36CQBTv5jDAOnb78M4A2CgUv43hPDZ6fXfH7i+3ecp CySIKBqVglgAgFXJD5FfXuQcjgB9Ns9PrzFJ60q5Jc50/QIB/4Y7Viy4UUrW
0csU4yD4hpvvmH7npq18XQUHUwPJbGN7w7veh/LhuBMy2V6H3HRfMruAj8el u3Kux80vOk7lk4axJimGJFrd3sMbLPN/TGFi3ArF4W5Jm8uJyNbbyIU+NMzG
uTds8aiiITqmZhOVF+vRbHyJcbliDWlvSRtsANmbatp3z6/Yy+dr9wm7e+gb CRR0gfCjqzed/1dcGPoFehocVX4gq8r2d+ISUY7R5rMIKEi1HH6vJICJji5l
G2ymD+EOKSRonH2AMKj+FM4FGEtfkYZxjk0+xVluABKInk93K7haQuOHzPEW xWOFkuQ2IPQb73NlWex2YhGFd+ixQQhQoM4rddKJFqY7ta1p1wU1eWxdwNcJ
7TwfgR7rBy1AJcbMEjKU770aT7poRHJlM8kvxCjE1CZJIQxs0yjKKmN3DELp eNsxL5vuckMnzsXAqRsW2xX4vFGBU5JngjPSVQ42VGyiG49M/UVAzhtRNr9L
DsFkgYP35wH8Mmx2rEst2UjmwU0HLrp52zRY4Yj11DRqajXY5lwcegiFEE25 lUfUiC1+Zqf1l7UkUdSEwkDbiyhYDrI96MU0h4UWikAtKx0iOY47zsSZVTpN
uGNSLbezdjsgYpfcmu5y5myRl9sK5VeVvEE++jumckqiqbVV966opPepiz0h xuQVtO619COtFneogC08bPq5cfEhFenXbsbEGPrJ65NnWJJSt17PIoFzqMcJ
IO5CnILyQMt48IyaljmKlo3f4oytorBWFc+5VA2bfYGRhLJE8sdsIpi78MhF 4GzxeJJGZqEWsnTGnDqXP3HKfXWGjIq9Aj6PLodAli0Oz0zw6ryvPe+aKnc3
JfiLlqEU4P0eLrVglmVjAnPdNyLoK2nVoFlG8YhvN+NGimTpxNKYzbQnmzvR w1pgBxkX+Xzmrgv7QhLANkhh77581spdy7wrOl6PN374S3b3MXOMNvjR7I8v
a25RRXhxVnARcGwTwRnVLCH2laSyQGlMCkM+DFC5FGsRg6ArTKQVIDzCfKLb B/kRYcU/PwIaqJZ6qNt3yZqfH2EAHyfK/anqnyz/oQFWbAwGwCy1WY1ZNV+d
3gqcgjEsDRxckTEaCCHWH1L3ARmNmioz28kwT92/L4Ico3gbvB00TjH3ioQ+ /vJUHR1hw4HlKXkYF++oBY3N8ff65+am2uW0Yo5W3X774nR5j/6y1qS/3Hgm
Dq8jzxHGugF1qrWmF+qgfXJ6mHBZ18MWc+A2YdrcaszFm9Z/gURHSWF56hrj wS6h29g00/WKlzKpqic08kJOXzxvIUuIkwaoX3RSyk0n3reJCllV0SHppFbT
whN4+XlOiDbRjQtVbZIkYUKjTgAtAKxJug/95GInfQPUdD0/fo0yWjf4LnC2 N7Nztjtqrbya6SNR12suBgf8Udc3j3LUlY7IxHzkB6iTy/sRSQWACIZq06VH
1y908i8Ulmvp0G2OCXsumfthHw3VWPv4YFxOFEkS45+1dHKBelLJeEhNWULU hC2ieyYVtr/UfkbzbPVkYaZViF1pvWGDDU/Tl4CtzvsvcekNul0OOY96y/th
isjhbsnqly4JrbeR9HxomI0TKIYZB3eXr97cxLT00naw28jGSNh3TU07uTiE SOAP7xDdQrjf2npCH/1IuPW7ftaL6qsN9QovEOpzg78Te/vPtxyg+Fmku/Sn
7bhsFgL2qFYwwEsJZIRDhEiwzYCkuRnw+ZcgcU555HZhDwkvLGaPEUCAOuvV Rc/uRiBLxj93WZ9GyrboGxDIoHNY0zY/tkzkPSLfHiESs//HKcMt4mdThRkj
0SacG7vRVrPpnPp2t2477ga85YiXTRfposPXRcGxiBnL9Ny+6PtGJm5BLkyc JKEvRPFsGCOdXJuDmxTBeU7Eh9T1Z5/Bt6meynRSPLMnbmon7/o2woqx8mzR
ma7XskFjlw+9dAlfBeTwJezmdyn5mLrqRnWX+dI+xi9rtSphExpoMZvbwZgD vI+abX4aydiUfrrPnH556rpqcatIN1QSXcwxqvDLLrWmQ+ezIsmGeKi+4y9Y
svPIC2+Oci1ogUKWMTTmmO5NKh5wpZP4hvyHrZvEfTPOHiJ7HWRTNt+scd30 gy2UU92+tBDFUXK+7sea8FIZPKBbOLhXOQ3p12GUQ51FRZKXnQZhcJrX9ICX
UC6WqVXqUQO/x7VHv2niO/h52/rAswJdj8KaCdjsRchdhV4e9v4FfhwTwWFc HL3tyczCGUQzFheDr19yZg6PeJj4AL/N/VSskT/R0T02mOeqXttXlo/5SLF9
ccoiBxVdLmgtTBoGfQqtm3fMHdYu9TQcOScz7tyU5NWzYgp1qW9iQMr5w4ko IpnaEWZkUz2ytdY2AoNp9JxK2+SeAHFzvY4azewOxwW5UqisdfHA91/nWbis
Ar1aFoTzMyxu9XPq7nVZnvtDee0Bd+KRStdFy8TKUF5n19xXLs8+6W5U72Kw s4d3cSreM6sR6N6pLnI35CJpe7bKK5SpR3tssFijdUvlHuYAsndFJfIQXxlc
TmBGYs+Bu5u224jdCGU+ae2uyfMZtRbCq+a8RbtizIwj0qZqlx7cV0umcI8d kfoT2FJcDK1oDIglZS1N2gCm7SKPt3cPbXwy42u7pMMfkjc1OsItSasRkDec
0tUX+woP4kgS5Irq5oZOYjUApieugX07CyHPD98brPvhbXdJXiDnKjVugyvc scEuk95FW3yasjAfmhwk0vGGfUzlEyZuw1E5Y3/LlZOEYE48CGhSHcWl+37r
dXBPwY9H0ERSTLzE6FQq9QhmrevbFLVhX6n1A/Wg6WPAA2v33qCjZtlHLuG4 OE39IXGpqalxSODCZmuY1npgkDNgfER9T62J/VlOlsbr5OxXqzbSbJWqF6Tz
Vigws/O2O68uvWYTRcR79ZrJV73n9sDu57060yEpqg/8vFeHXC2I55wDdGCo US1z5qIPFirkNEqyw8SNDTHjgRK8/M9uxVRVWQffrJlPY/nAKBljb6gnyEU+
98oepnkK5hEAK/vbsg8W/Sx6qP0ZzbM+8BFLFmm6kdlV1xtE2fg4PfSenbLv A9k6TSqQboB0OkjHFfoIYZzaNhCReMGUgkMZ2VbY1D+fwYBvvXYs8HUYNaRR
F+LeYkjCzD/tqy9Ai8Ueuj06jt4tokAZl4l+3vnWBTl8nOh8QMz3b3dcycvn TbWfKeyZwAfUkRjYwkTASrnDhEfCpdFpZ3sSGtOrjWPPH2sNXeTsTO5pAik3
q+oVXhl5za2hD+x9jzLIRyH0wp8gUEvRnE3Rpy/KXR9pqeFjd7SEMD6BNbbo dWKs0KYa0JRO+Mlj103GZw5qS4Dlqd1WKVWcxNITk2ociB+92vZaTluCzZ4P
JaAZ9pVZJLAKF8jYX4IG/Ro7ejoWBMG5ad5AbpunuHlIXn/xBTzNXQ2NU9qV znU8FLWgxAgBPPC6FLWvWk5z7sabUWWJ1OQ9WZthIjayagEHFYVIIoXLRIi/
3dbq7100FkPs6bwRolWs+vNQRr/0c39MDayv1Hu9wezHYl4RKy7FCZOhX6H2 qHdrZE4I+HdV04J+2QpQZwjzulJS7rkCQpjvY63daFYvApfeUphikRsUYY5z
FHVrtPy6q/zOazUtmTrSzPI4HWHHna6/Yg3qUEbVe9IkHkfJ+PJFq8pLldCQ 7PlFIWz2b7T9m1caecxlz+ZN8kTy/a5julHOjdJobN98cLh9SAXRhear4lio
blDjq2hoSD8rsxjpNMzjrOg2jpWTvswVP5KyZ2/bYJ7KPZNtPIoLPY1zYGb9 GYWGqR40NImcguCcE5FE6ZRh1faBn1slfHCZRdkKnSh3tQ6Lb4wEdBrHSDty
1t79yBMd3uH9QVzhYy8O4GJfqbmLJW2LvOmJHtu6Kxc5yCkcA29JKETMXa/d QjFKF2VSmlysCaEGswhLt9Y4BQYUTa4K3bA494tuL/P+cV1n441+MFJIA5DH
VtNNzu5AThIuah2+8P3XWdpb1PXLu8EeQygage4hGZkeZHp6FdYNH4S3eRtC 8+WvwvBdMRrq+Ht1a6te5WIvUgdBMNygEgtqU0GBXHfv8U53R+4TzvniHBO3
06jhUvan6UPiXROOikVhbtpxwCXnGGrS6BXDKLGXT9WApr0lCAN8I+uXTPlC 6P++j2Gk2bzqqu8wSVLc6ThgRYbXh9ipOnxgVC8c2VLJ4kMSc5Zw/8i/IAuG
VekULKWTvCdpRAYMjFM9gE78K1C5qUJuvjTpSojIq/zxqKRkSuO0YXZoVHC5 x5OZ3GGGZky5XSCGx7nUBoyHg573DiyABp7mdIw5kkP9/B4VQ5d6mgzzlMSz
RpsOmLMUxMwDZZlTsfj5VlFt/UMiU+M5d4fAZU7FwgZZZA8Ye1Hf0d0T/iwH BM/oG2hZ0LVKdNnJOuycTodxr31z/W9BFY48aOD2ZZBg8L7Bd5eN8bJlg6hf
S9qbE7a0aiEMACiXUZoi1hR354Uwj7IBKZkRxl1skBn96jWmZXKsraFv1sw1 I2gqanLEgUx+pcLOaXjZFxdYYpgI73dBQC3yOfm0GBZ5MPKD4cxHp7A/M7F4
2XUI4XldUL+wk2zWe4VXQAB3gyOnanou1kMA48y2uZi4DabkI0pJI8LrmrIZ V73UYPSNCk3NfTh6LxHc+XiMNxtQcohziF2g8q+B89TJEHPkqY75qhiw4OcZ
GJ1vvFZt8Lgd1eT5mzTfCXxBN04AVRjvVyGXz/FIuLRjSnE0/VAwD6vR/ORD H5DWsZxbWknZWCwkxYBgxX/48OEKRc2LBBAL9tFH9BY+nEYF2uLqBUYvssw8
rdmbVNBmniiQZhuOi4FVJXUAJsPSzzJzneZ80qDeRFio0m/mVQPcI+msTamQ vsonEWbsXuTzYRRHSWE+ONMDoNw81Qvz5Ns0ipPpT/+3UP/9P+fZT/+7Mh/c
RI1esZvvpBJ3s2eFc04v+S8oPZ7gHXj9C1sOJuxuRmk5KSWZSn7+oxmcxm8j 5HhN5hnI6DR5MA/P04cFzNaF5/dUIyKPyztg7+Qvd+bBNzkWKb2EmScgFu2Y
ixZoUOqoxB85mZSoi1rBh6Za8M4mkUre5KetACWGkK7XzaYrjBtjso3rZutl /QkMWqqXOQj5KrGrTe7yNErUNz/9vSpB5NjZ+nkcY9vkwj2YThfg4s1Tu/7/
X9J1EuMqcq81zHGMzUDJe81miLZ/80pDj7Rsff4kiyUv0F2AY0SzRM73Nvao hEXSUu3mXwA8boeTB2C4H8yza6AKdVsBCrWdNSqGueonePuqefbT/8Abar9d
4inXfI8BMzEjwTCkg/ofIVAQHHOaEuE25V9p+4GfefVYKM+kKzC7Rsu42wjl ZMM7+71+MlXfJcMkK+94xZzy/YCrQFZAnoDnhlUTUFRgfpDCxG9ydL2yt0Sy
daUxQZjMC74hkLiv+E6DWYiZ2x0OdQEOk0lBd11XfoHNaXbd0L3wQmUYqUcD SYg8a6voE84slKbhyTcakQkEF1OG/YrufOd7J0Eqaby7vqP6oAAyYLIxx/9v
kGUidsWr7MbfgItqszswyW7eLvzwkwPdpvHm949EGPfePln/DnrqQCpVzX/P madeXL3s32zwTeQ01piuNGCSK9XW/m8vb7d2Dvd/q9b7b9UZyM5YZ1znYz47
skmI0Z8XWTUKozDOvwRRTmGPay6yolfUcn3SxMLk4TO8akmuZbAx9pSdT3da UOsXJ9+BHTEdzIvxBrG0O7NJs5sjgerN5bfXfT6Q/OiM+0e7K2fcP9r7GTOe
HrpkCGBjkTQKXVBB2upStyTyvCwx5mujUM5KiK578qcDemib/JpVZSRtEowh hkW02AV+whrKd3ERjarQpboxfIgih82mrcPvj9WkqqjLFTZBwyPFd2CG4gt4
yKm7eD24tz0Kl1hR+zK+6at1+fowCSmnxisX1sjsQx+PhDzDZNp4ixUDdwsX ZGQTeG1zUk3TzacGenKqg0811cGTU+1/qqn2n5xq71NNtffkVLufaqrdJ6fa
X246tRfwkQPr6OhyDS/+cafzTYa5wi/hOCYwafmlqWXpVTN1dHp1+Obqat9C +VRT7Tw51fanmmr7yal6n2qq3lNT9Y4+0VS9oyen+lQs3HuShXufioV7T7Jw
YcweTJOUzcvLAPeogaKNGbb2QwZK6J3dhQmhyzXflLbv1UOY4uzGSMRdGun3 71OxcO9JFu59KhbuPcnCvU/Fwr0nWbj3qVi49yQL9z4VC/eeZOHe1qeaauvJ
se0IgB/VOkFJbOCJ2L37Sdh9meGt7EcgfpL4vo3RgjlVStFkvHRod2vD4Yg3 qT6VtOhZaZFiDUFR0ufDrHzO+Etf3Fw24D9AZauGCd6N8TdsJO+PmA+7RZJX
0LcJYNb05/+bq//471X68//GowBkOTq9lMwhh0T0/M//LQfu+u08Hd3qL5vT YV7SYJQ5+NOfMl396U/8feo8j+MH76Ikhz8wyuONMAbrZT7ogt23GWVFOJgO
nnF/CtcpGkB0MCy4Gwai66ncBuadifNgwBFfXR+tb/q1WbD09cHmduP8LOdX RuEsuc+rTff14P8DMHXuyxKwAAA=
FMU19TLjZs9pVIEpUsELupJh3lBTEuxtDSdJ3mdqDCYF+DaxbqxsJYhtNGHu
s+CBTqeoWmo7GXuX5cuT+WxCF/yChE1vRR8OMWsp4qbmWDWE9rR3GhchKBHf
YcukvMCDYEpgo3TJCdtwHd9qCwaJtPOKqDSVqZD12vriLyY55Se3rpAn0URX
qCHHTnUF55ck8wepdwFHpYS2Fa/0z8jkH428+HFVmJW7BodER5h4w3hc1ruB
ji4rGGUd4nOEOfZuX9PJo4G4tGZYKWivxYNbabAfKV1uF57J9x7/AEmb2URg
KxJUApKyQq7uZj3PYxAipdaJXgC8qszw1ZGNmTB3qvWzo0QHUTEpwkHdltCn
0hIeBiGw846HLmcHv60/6lYsHcu8a5a8BinDuRpx8j2e47OtHSNIXsbvMNOO
i7NycovWGkN6+z/SQxApWaLn7e1/Q652cYu40/+swKktlVCwHR7HggsJjS8D
aQdt2s5TOf3OR3F6w0sp9l641HkvNdy1Ekcq8/ks3boY8D4b11eNa432jLvW
Sj5RcMzn/t3tjkrxQmeJKmLbx6cCYPuTRN036GzibR3kZUg2NQomn9fAyZUZ
anbEdEyFMpyWoOnuxsaepyLFYp3k4xF+M8QKQ7o7Dt9jTVXq7z19tcFPUAXJ
mZsY7OBOytQsDJOvepx3Hg6HuOAa0yBt3b+rcyFzq3HBUHJZsOj53jXAYeeA
S/lZQaLc2dzaXfXetj1lmLgNGBb0m/NpFKMlKBdq992SN5vSd5vnICizj/Wx
eaOMvaFYXWpyKi3GTEpT9tAOuJC9lkbex4oAk+VN1P4ldqHguFFTnMkrx1If
i35EZtLkjuDkMTyB5xTQibK+vEDeG++SzH31nf5STEScaOFNoB74ros7xNVL
X4m6INirg6PXXNAjtz1+JVtAaHAh6y8m2f0vpLa90OVTCWzrowhM2FlRYWpA
UhmfkWNvwDdnpGHjVqlPonTltCLWM7eOPHSwY6Pm+WzrGTIwup8yisObFEsn
RghHU8NptFLSubPL45614ms1Yb2vud5s4bf+rFFWDRMf0WHtLw4v1AZ1C2pw
/7SmYojc8m6qZKCIOQXcEScQzPQrNTwNktyK156RUlgDEpdIcSqrZW7jw52P
ai/RCawdKt3iJEDZrgxyIn1R0U/g69QIVe43IPevcpU2fHB69HzgHJvklHEr
WHJXpW8QMw/yYqns77k8pu9M7i1Iluk0zLvmZLoigTXXwY4SHaaYvP9EUtj8
JFlTTDQo7XTFIpHtEyfb+KTJjovb7MvCTOU+PwvzUVYs/Ca+zZIwdl89cX2D
j+QLfClmPMWrb7CbCuaM5Rl6SgGrC8vw4+L3VQoax/Ov8XdQCUelfFWl2l6l
SkgMjyzAPnzURp6wlg+f81PE6slssLaLitpBNSLztbtvC1MqGoN0O3otWtAw
p7xNtBxz9PG4ijGrYPZALcVYUM3BQGL5AVenSOsFTT47QZ3TsH3Y8CMEDS8D
+pPPZ9gbHPSQOfbiGLh2q6ZbDa4JVAs/5SelSh/jbeKWS0BREdKf2SrdUDsy
KZbkBajNLf6LNWz96pXtkoRsF3wiWt5lcWTqSGFqiaQh+NRf/vw/6gF/d5vX
X/78PxHWXArdbCvIbQNjr5ERampMA6rewcmw4TLz1VfDT4zVpUYTPboFRbV4
Ku8YPPsochEDsakquW8wVaiHSlHTAVOXUF6frO8pEr6xvrnzw9u3K5OypBsw
8IIUVPFvdd7HtWNPqDXQPNYm5TRZA10WX1jtiv4lh8o6hLQn4GY+Vm3UkazD
JHu36xP2a2Rbw3Iqe2aHxxPh+nGOXIHFoU5vgeEdjMdxwkr0U6f7NM8aK7jU
54eZrPoCwLq3s7vn1uRbyt4JcrMQE+6mO/ssRgik6RYoybEnfd1HiatlZ3BB
F1zD/zOHTD32dgXkhWqXy+6bteI70pxCkv+fCr+Ps1dxd97twUgNhhQ8bo3L
RQCP43dkDfwTOeMwTDnKkmqaUp8K6XF8nAMAQrX1bHtrlR5tkQzaOntbe1sc
WVvsS1cuy44GwekRq5FCCp2MfQnwRMB8tB3ra5ikRycac9AJSugYp5JbbhBB
VbhPXcjH6fvWKUc5ssAWiYmaxh6WABj36ZQ+SssYfKTKxcnbNZcw677UUsvk
lFd4J7ptYORnoWgvQUl2x/FiLyL3Affq/n7qTj5GnwvEJmgU4sm1KnjcC+mT
PaOuJRbtnCvMqJJ3lRQxyXH3bnqG8W41mGU2KMNyE1TXaZgkxETKZnbtQ9QB
421vb+J7gov7vB10qUq7JpN2ZSMt2LAG1HF46vrFkatxB2FwfmFanBg9HxST
pp7h9cygcJHVHd1zzYYZ3iu+XK1X0qV1WUVawxEZ1iPs4izFKwBO7Fii6UoD
0VGDpyLG+schxhVZqvNaDyW84SDmGFthO384hdMDQr2QQwLAoig0Oixhbo8x
rCUSZePdQhvYJUvOz/V4cddM2oZO1Pv/UF6ilkURKLG+ptxA9afC7mOMEMLH
bxAIB1eHp6eAJqWhM28THVdF24jZdtQKlu55PfJXTbc6dMnRSkEarMiapfiU
VjxKi7ernhXEcZu7OEvCRvyVzNjz18K07McA/3E4smBfVvfJdnUDeP5CPoXP
B9atYzoyKulR8MD4QfCFOhihszLR0Q3z05/2q5TLDXQkraqXZjNg7yjp/5be
oo2K2dXAxGdddRjmmGipXiAjStNuOxrf9WIB3XY0sluPdHbVcXI/h/H68AnI
pqJLVjQYE7+/7TZjOV11PYGXC/UyA15Xxl1jP6tvfv73shgBDcAjGRzSCVga
+Ot0OqcQHKzkn2FSmhoW/QJ2cDWa3AMW/rHrx266bKur6zjJRmG3FhyF8eKp
+i4exWlxG7M3ww/vmYIHag4hnQ/Y/TalI+gHweOJEfvqacbBYwM9OtXu55pq
99Gpdj7XVDuPTrX9uabafnSqrc811dajU21+rqk2H51q43NNtfHoVIPPNdXg
sanA/v88Uw2ePTrV5yLhwaMkPPhcJDx4lIQHn4uEB4+S8OBzkfDgURIefC4S
HjxKwoPPRcKDR0l48LlIePAoCYP2/JmmWn90qs/FLQaWWzR1xCeMv/DFtUUD
/hVYtmyYwOuw442Yjfp5nJW9rKDBqHjnd79Ldfm73/Hz+EIfxw/8DjJuhBvQ
dqthH9SUtTDNe8PpcNybxXdZueYeD/4/qHEquyTRAAA=
--> -->
</rfc> </rfc>
 End of changes. 146 change blocks. 
2434 lines changed or deleted 856 lines changed or added

This html diff was produced by rfcdiff 1.48.