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 the Constrained Application Protocol (DoC)</tit
<seriesInfo name="Internet-Draft" value="draft-ietf-core-dns-over-coap-20"/> le>
<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-").
-->
<!--[rfced] Please note that the title of the document has been
updated as follows. The abbreviation has been expanded per Section 3.6
of RFC 7322 ("RFC Style Guide"). We also added "the". Please review.
Original:
DNS over CoAP (DoC)
Current:
DNS over the Constrained Application Protocol (DoC)
-->
<!--[rfced] May we remove "(CoAPS)" in the Abstract as this
term/abbreviation is not used elsewhere in the document? Please
review.
Original:
These CoAP messages can be protected by (D)TLS-Secured CoAP (CoAPS)
or Object Security for Constrained RESTful Environments (OSCORE) to
provide encrypted DNS message exchange for constrained devices in
the Internet of Things (IoT).
Perhaps:
These CoAP messages can be protected by (D)TLS-Secured CoAP or
Object Security for Constrained RESTful Environments (OSCORE) to
provide encrypted DNS message exchange for constrained devices in
the Internet of Things (IoT).
-->
<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 (CoAPS) 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 204?>
<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 ef target="RFC6347"/> <xref target="RFC9147"/> CoAP message exchange. Each CoAP message can be secured by DTLS 1.2 or newer <xr ef target="RFC6347"/> <xref target="RFC9147"/>
as well as Object Security for Constrained RESTful Environments (OSCORE) <xref t arget="RFC8613"/> as well as Object Security for Constrained RESTful Environments (OSCORE) <xref t arget="RFC8613"/>
but also TLS 1.3 or newer <xref target="RFC8323"/> <xref target="RFC8446"/> and TLS 1.3 or newer <xref target="RFC8323"/> <xref target="RFC8446"/>
to ensure message integrity and confidentiality.</t> to ensure message integrity and confidentiality.</t>
<t>The application use case of DoC is inspired by DNS over HTTPS <xref tar <t>The application use case of DoC is inspired by DNS over HTTPS (DoH) <xr
get="RFC8484"/> ef target="RFC8484"/>.
(DoH). DoC, however, aims for deployment in the constrained Internet of However, DoC 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 <!--[rfced] FYI: draft-ietf-iotops-7228bis has not been published yet
<xref target="I-D.ietf-iotops-7228bis"/> throughout the document in case <xref t (currently, its IESG state is "I-D Exists"). Thus, we have left
arget="I-D.ietf-iotops-7228bis"/> becomes an RFC before publication.</cref>.</t> references to RFC 7228 and draft-ietf-iotops-7228bis as is.
<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"/>. Author note:
Please remove the {{RFC7228}} reference and replace
it with {{I-D.ietf-iotops-7228bis}} throughout the document in case
{{I-D.ietf-iotops-7228bis}} becomes an RFC before publication.
-->
<t>In order not to be burdened by the resource requirements of TCP and HTTPS, co
nstrained 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="224" width="608" viewBox="0 0 608 224" 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 208,96 L 208,144" fill="none" stroke="black"/>
<path d="M 264,96 L 264,144" fill="none" stroke="black"/> <path d="M 264,96 L 264,144" fill="none" stroke="black"/>
<path d="M 320,96 L 320,144" fill="none" stroke="black"/> <path d="M 320,96 L 320,144" fill="none" stroke="black"/>
<path d="M 456,112 L 456,128" fill="none" stroke="black"/> <path d="M 456,112 L 456,128" fill="none" stroke="black"/>
<path d="M 600,112 L 600,128" fill="none" stroke="black"/> <path d="M 600,112 L 600,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"/>
skipping to change at line 226 skipping to change at line 252
| 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 <!--[rfced] FYI - We updated "authoritive name server" to "authoritative n
verview-arch"/>: a DoC ame
server" to match other usage in this document and in other RFCs.
Original:
That DoC server can be the authoritive name server for the queried
record or a DNS client (i.e., a stub or recursive resolver) that
resolves DNS information by using other DNS transports such as DNS
over UDP [STD13], DNS over HTTPS [RFC8484], or DNS over QUIC
[RFC9250] when communicating with the upstream DNS infrastructure.
Updated:
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 by using other DNS transports such as DNS
over UDP [STD13], DNS over HTTPS [RFC8484], or DNS over QUIC
[RFC9250] when communicating with the upstream DNS infrastructure.
-->
<t>The most important components of DoC can be seen in <xref target="fig-overvie
w-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 <!-- [rfced] Please clarify "is of length 0 and 24 octets" in this sente
nd can reuse the nce.
Original:
As long as each docpath-
segment is of length 0 and 24 octets, it is easily transferred into
the path representation in CRIs [I-D.ietf-core-href] by masking each
length octet with the CBOR text string major type 3 (0x60 as an
octet, see [RFC8949]).
Perhaps:
As long as each docpath-
segment has a length between 0 and 24 octets, it is easily transferred into
the path representation in CRIs [CRI] by masking each length octet
with the CBOR text string major type 3 (0x60 as an octet; see
[RFC8949]).
-->
<!--[rfced] We are having trouble parsing this sentence. Please let us
know if it can be revised as shown below for clarity.
Original:
Likewise, it can be transferred into a URI path-abempty form by
replacing each length octet with the "/" character None of the
abovementioned prevent longer docpath-segments than the considered,
they just make the translation harder, as they require to make space
for the longer delimiters, in turn requiring to move octets.
Perhaps:
Likewise, it can be transferred into a URI path-abempty form by
replacing each length octet with the "/" character. None of the
abovementioned prevent longer docpath-segments than the considered
ones; they just make the translation harder as space is required
for the longer delimiters, which in turn require octets to be
moved.
-->
<!-- [rfced] May we update "going through" to "with" here to improve clarity?
Original:
The construction algorithm for DoC
requests is as follows, going through the provided records in order
of their priority.
Perhaps:
The construction algorithm for DoC
requests is as follows, with the provided records in order
of their priority.
-->
<t>Note that this format uses the same encoding as the "alpn" SvcParam, and it c
an 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 is of length 0 and 24 octets, it is easily trans ferred 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, they just make the None of the abovementioned prevent longer docpath-segments than the considered, they just make the
translation harder, as they require to make space for the longer delimiters, in turn requiring to move octets.</t> translation harder, as they require to make space for the longer delimiters, in turn requiring to move octets.</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, going through the pro vided records 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"> <!-- [rfced] How may we update the third item in the series for parallel
structure? Would either removing "from" or adding "information" be correct?
Original:
This may include (1) A
or AAAA RRs associated with the target name and delivered with the
SVCB RR (see [RFC9462]), (2) "ipv4hint" or "ipv6hint" SvcParams
from the SVCB RR (see [RFC9461]), or (3) from IPv4 or IPv6
addresses provided if DNR [RFC9463] is used.
Perhaps A (cut "from"):
This may include (1) A
or AAAA RRs associated with the target name and delivered with the
SVCB RR (see [RFC9462]), (2) "ipv4hint" or "ipv6hint" SvcParams
from the SVCB RR (see [RFC9461]), or (3) IPv4 or IPv6
addresses provided if DNR [RFC9463] is used.
or
Perhaps B (add "information"):
This may include (1) A
or AAAA RRs associated with the target name and delivered with the
SVCB RR (see [RFC9462]), (2) "ipv4hint" or "ipv6hint" SvcParams
from the SVCB RR (see [RFC9461]), or (3) information from IPv4 or IPv6
addresses provided if DNR [RFC9463] is used.
-->
<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) from IPv4 or IP v6 addresses 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" <!--[rfced] Per the following note, we have replaced "ff 0a" with "00
was not assigned at the time of writing, we 0a" in
used the hex <tt>ff 0a</tt> (in decimal 65290; from the private use range of Svc the examples in Section 3.2.1 (per IANA's assignment of "10" for
ParamKeys) throughout "docpath"). Please confirm that this is correct and let us know if any further
this section. Before publication, please replace <tt>ff 0a</tt> with the hexadec updates are needed.
imal representation of
the final value assigned by IANA in this section. Please remove this paragraph a Author note:
fter that.</cref></t> Since the number for "docpath" was not assigned at the time of
<t>A typical SVCB resource record response for a DoC server at the roo writing, we used the hex `ff 0a` (in decimal 65290; from the
t path "/" of the server looks private use range of SvcParamKeys) throughout this section. Before
like the following (the "docpath" SvcParam is the last 4 bytes <tt>ff 0a 00 00</ publication, please replace `ff 0a` with the hexadecimal
tt> in the binary):</t> representation of the final value assigned by IANA in this
<artwork><![CDATA[ section. Please remove this paragraph after that.
-->
<t>A typical SVCB resource record response for a DoC server at the root path "/"
of the server looks
like the following (the "docpath" SvcParam is the last 4 bytes <tt>00 0a 00 00</
tt> in the binary):</t>
<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. 643 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 2b 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 <!--[rfced] We note that "Cache-Key" appears as "cache key" in RFC
ader to 0 to enable a CoAP cache (e.g., a CoAP proxy en-route) to respond to the 8132. Would you like to match use in RFC 8132?
same DNS queries with a cache entry.
Original:
This ensures that the CoAP Cache-Key (see [RFC8132], Section 2)
does not change when multiple DNS queries for the same DNS data,
carried in CoAP requests, are issued.
Perhaps:
This ensures that the CoAP cache key (see [RFC8132], Section 2)
does not change when multiple DNS queries for the same DNS data,
carried in CoAP requests, are issued.
-->
<t>The DoC client <bcp14>SHOULD</bcp14> set the ID field of the DNS header 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 optional.
However, all DoC clients <bcp14>MUST</bcp14> be able to parse a "application/dns -message" response (see also <xref target="sec_content-format"/>). However, all DoC clients <bcp14>MUST</bcp14> be able to parse an "application/dn 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 th
s case – is noted in the DNS response, the CoAP response still indicates success is case -- is noted in the DNS response, the CoAP response still indicates succe
.</t> ss.</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 <!-- [rfced] Please review the text starting with "OPCODE—a DNS
ses NotImp (RCODE = 4) if it does not support an OPCODE—a DNS Update (OPCODE = 5 Update ...". Should this be updated as follows or in some other way?
) for "example.org" in this case.</t>
<artwork><![CDATA[ Original:
As described in Section 4.1, a DoC server uses NotImp (RCODE = 4) if
it does not support an OPCODE—a DNS Update (OPCODE = 5) for
"example.org" in this case.
Perhaps:
As described in Section 4.1, a DoC server uses NotImp (RCODE = 4) if
it does not support an OPCODE - in this case, a DNS Update (OPCODE = 5) for
"example.org" is used.
-->
<t>As described in <xref target="sec_content-format"/>, a DoC server uses NotImp
(RCODE = 4) if it does not support an OPCODE-a DNS Update (OPCODE = 5) for "exa
mple.org" in this case.</t>
<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 ecord. The DoC server <bcp14>MAY</bcp14> subscribe to DNS push notifications for that r ecord.
This involves sending a DNS Subscribe message (see (<xref section="6.2" sectionF ormat="of" target="RFC8765"/>), This involves sending a DNS Subscribe message (see <xref section="6.2" sectionFo 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 <!--[rfced] Please clarify what "a failure to do so" refers to in the
ty following sentence.
Original:
As there is no CoAP observer anymore from the perspective of the
DoC server, a failure to do so cannot be communicated back to any
DoC observer.
-->
<t>After the list of observers for a particular DNS query has become empty
(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 <xref section="6.4" sectionFormat="of" target="RFC8765"/>). This can involve sending a DNS Unsubscribe message or closing the session (see < xref section="6.4" sectionFormat="of" target="RFC8765"/>).
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. 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.
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.amsuess-core-cachable-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 es insights on what can be done when those are resumed from a new endpoint.</t> <xref section="2.6" 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>
<t>Though DTLS v1.2 <xref target="RFC6347"/> was obsoleteted by DTLS v1.3 <xref target="RFC9147"/> there are still many CoAP <t>Though DTLS v1.2 <xref target="RFC6347"/> was obsoleted by DTLS v1.3 <x 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 <!--[rfced] FYI: We added "to protect" to this sentence for
nst spoofing is not necessary. clarity. Please let us know if it changes the intended meaning.
Original:
For secure communication via (D)TLS or OSCORE, an unpredictable ID
against spoofing is not necessary.
Updated:
For secure communication via (D)TLS or OSCORE, an unpredictable ID
to protect against spoofing is not necessary.
-->
<t>For secure communication via (D)TLS or OSCORE, an unpredictable ID to protect
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.amsuess-core-cachable-oscore" to="CACHABLE-OSC
ORE"/>
<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"/> amsuess-core-cachable-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." surname="Lenders" fullname="Martine S. Lenders ">
<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 999?>
<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] FYI: We removed the change log, which included a
<section anchor="change-log"> reference to RFC 2136. If RFC 2136 should be mentioned elsewhere in
<name>Change Log</name> the running text, please let us know.
<t><cref anchor="remove-changelog">RFC Ed.: Please remove this section bef -->
ore publication.</cref></t>
<section anchor="since-draft-ietf-core-dns-over-coap-18"> <!--[rfced] We note that "draft-amsuess-core-cachable-oscore" is
<name>Since <eref target="https://datatracker.ietf.org/doc/html/draft-ie expired and has been replaced by "draft-ietf-core-cacheable-oscore".
tf-core-dns-over-coap-18">draft-ietf-core-dns-over-coap-18</eref></name> May we replace the current entry below with the entry for
<ul spacing="normal"> "draft-ietf-core-cacheable-oscore"?
<li>
<t>Address Address Mohamed Boucadair's COMMENT: Current:
</t> [I-D.amsuess-core-cachable-oscore]
<ul spacing="normal"> Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work in Progress,
<li> Internet-Draft, draft-amsuess-core-cachable-oscore-11, 6 July 2025,
<t>Add Operational Considerations Section</t> <https://datatracker.ietf.org/doc/html/draft-amsuess-core-cachable-
</li> oscore-11>.
<li>
<t>Make SVCB references normative</t> Perhaps:
</li> [CACHABLE-OSCORE]
<li> Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work in
<t>Remove redundant requirement on parsing application/dns-messa Progress, Internet-Draft, draft-ietf-core-cacheable-
ge</t> oscore-00, 22 September 2025,
</li> <https://datatracker.ietf.org/doc/html/draft-ietf-core-
<li> cacheable-oscore-00>.
<t>Remove contradicting statement and outdated reference about A -->
LPN</t>
</li> <!--[rfced] Sourcecode and artwork
<li>
<t>Add DNS client to Fig. 1</t> a) Some lines in Figure 1 are too long for the TXT output. This figure is
</li> marked as artwork, so it needs to have a width of 72 characters or less. How
<li> may we revise this figure to fit these parameters? We tested removing some
<t>Clarify recursion termination in the CoAP realm</t> space in the figure; please check out the following test files and let us know
</li> if this would work (see TXT file for ascii art and HTML for SVG). If not, please
<li> provide an updated figure.
<t>Clarify where addresses are coming from with DDR/DNR</t>
</li> Test files:
</ul> https://www.rfc-editor.org/authors/rfc9953test.md
</li> https://www.rfc-editor.org/authors/rfc9953test.txt
<li> https://www.rfc-editor.org/authors/rfc9953test.html
<t>Address Gorry Fairhurst's follow-up DISCUSS:
</t> b) We have updated the blocks in Sections 3.2, 3.2.1, 4.2.3, and 4.3.3 to be
<ul spacing="normal"> marked as sourcecode. We set the type for the block in Section 3.2 as "abnf"
<li> (i.e., "~~~ abnf"). Please let us know if the type should be set for the other
<t>Refer to Observe terminology in Section 2</t> sourcecode blocks. For example, should the ones in Section 3.2.1 be marked as
</li> type "dns-rr"? If the current list of preferred values (see link below) does
<li> not contain an applicable type, feel free to let us know. Also, it is
<t>Clarify registration</t> acceptable to leave the type not set.
</li>
<li> List of sourcecode types:
<t>Provide alternative observation examples</t> https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types
</li>
<li> c) The blocks in Section 4.3.3 are too long for the TXT output. We marked
<t>Clarify that error handling is in the hands of the DoC server these as sourcecode, so they should have a width of 69 characters or less. The
</t> long lines are currently 70 characters. Would moving all the lines with
</li> semicolons over to the left one space (in just this section or in all the
</ul> sourcecode in the document) be a good solution? We tried this in the test
</li> files listed above so you can see what the output will look like. Feel free to
</ul> offer other suggestions as well.
</section> -->
<section anchor="since-draft-ietf-core-dns-over-coap-17">
<name>Since <eref target="https://datatracker.ietf.org/doc/html/draft-ie <!--[rfced] Please review the "Inclusive Language" portion of the online
tf-core-dns-over-coap-17">draft-ietf-core-dns-over-coap-17</eref></name> Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
<ul spacing="normal"> and let us know if any changes are needed. Updates of this nature typically
<li> result in more precise language, which is helpful for readers.
<t>Address Roman Danyliw's COMMENT:
</t> Note that our script did not flag any words in particular, but this should
<ul spacing="normal"> still be reviewed as a best practice.
<li> -->
<t>Remove unused RFC8742 reference</t>
</li> </section>
</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 , Mohamed Boucadair, Deb Cooley, Vladimír Čunát, Roman Danyliw, Elwyn B. Davies, Esko Dijk, Gorry Fairhurst, Thomas Fossati, Mikolai Gütschow, Todd Herr, Tommy Pauly, Jan Romann, Ben Schwartz, Orie Steele, Marco Tiloca, Éric Vyncke, Tim Wic inski, and Paul Wouters for their feedback and comments.</t> <t>The authors of this document want to thank <contact fullname="Mike Bish op"/>, <contact fullname="Carsten Bormann"/>, <contact fullname="Mohamed Boucada ir"/>, <contact fullname="Deb Cooley"/>, <contact fullname="Vladimír Čunát"/>, < contact fullname="Roman Danyliw"/>, <contact fullname="Elwyn B. Davies"/>, <cont 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>
</section> </section>
</back> </back>
<!-- ##markdown-source: <!-- ##markdown-source:
H4sIAAAAAAAAA8V92XIb2ZXge37FbVREF+kGQHCnWFbZFEkV2SOKNElVtaNK H4sIAO49qmkAA+1923LjRpbgO74ih44YSzMERd2r5NuoJJWlmZJULansdlRX
40ogL4g0E5lwLqTgkhx+nYh57MeZ6JmIeZ0/6Kep/hJ/yZztLpkJkJSsthm2 2CCRJNECATYuUrHLcuzrRuzjvs9uxL7uH/TTer5kv2TPLRMJgJRULnXP7sQq
igQy73Lu2bfb6/WCu321GQRlXCZ6X3WOXl+p7E7n6jA7uFArR9nhaicIh8Nc ussSSOTl5Lnf0vd9r4iKWO+pzuHZpUpvdKaKiVYHaZIXWRAlOlT7s1kcDYMi
w3PwVxBlozScwqNRHo7LXqzLcW+U5boXpUUP34S/wllvYxCMwlLfZPl8XxVl ShP1OkuLdJjGauUwPVjteMFgkOmbPQV/eWE6TIIpDBVmwajwI12M/GGaaT9M
FBTVcBoXRZyl5XwGr58eX78MgrvNd9NkIx+P9gOlijjR6Ujjrz31MqvSSF19 ch9Hhr+Cmb/R95JyOtDZnnr+fHvTi2bwW5GVebHR7z/vb3hxkIz3lE68ISxC
+426j8sJ/BPBv1muJjq+mZSqmOlRPI51FARhrsN9dTCbJTFMCRMUwX2W397k J3mZ0+faSwd5GutC53teOQsD+mUW7am3sKSuyufTTI9y+CXNCvztnQeL1uM0
WTXbh31cHge3eg4fRTzyaVrqPNVl7wh3QB/RQ/zLwQX9AnAI7nRa0WqU8gfD m++pvAi9vBxMozyHbRTzGSzz5OjqpQdr3/Q8HGxPbfQ3dvz+phdkOthT359c
v3kP38E0cXqjvsFv6fNpGCf7CuHxa4RMP8tv6PMwH00AupOynBX7a2v4GH4U ebdpdj3O0nK2BxC5OPKu9RwehXueUj4/4V/2X9MvAELPC8pikmbwFV8phsdp
3+m+eW4NP1gb5tl9oddwhLUOTw3br4bwMkH5/maNAV8DNz+ZAMCL0ptG3ujz kBUASXWZziaRVq90EuoshzeUSjPY6tWbQ3WY6TzUiXqTRACpPCrmKh2pKz2c
EP04W/Tu2oMH2Z+U06QDQK7KSZYDMHpK8fmfhXkZp1pdZbNJrNUrnUY6L2gh JGmcjuf0bQPtqzfm+/QYTkrrYk8d63g6SePiz/Cgp9b79OEQhtqrfX2YhrCo
sJt9df3mSB3luoh0qt6ksNO8iMu5ysbqWo8maZZkN3OGjWDX9RvzPH1clLnW Q7+/3t95Lk/KpEAwfauzaZDwZHoaRPGemvLiezGv+p+K0g95sF6onU0eTLIo
sJsTnUwnWVL+ET7oq/UBfTmCofZrj4+yCBZ11BusD3aeySdVWiL6faPzaZjy L6IgUfvT/Ne/5Lk7yNB8+E/BNC91nveG6dR9WSfX6ttf/5KE6b/9a5BUoDnT
ZJpPaMqL7ye86l+XVS/iwfqR9jZ5OMnjoozDVB1Mi5//vSj8QUbmy1+H06LS ZRbE+2OdFOrb6eC4tt/TSOf+TZD4sDD/Ip1o/xJw9td/1WrH2fppmUTDSW3n
RdEfZVP/ZZ3eqm9+/vc0yv7j38LUgea1rvIwObjRaam+mQ5Pavs9i3XRuwvT z/rP+rsP7nwIi+qNS1jTGBae0EoCXEkviJy1X03SaZCrg566HE6mUVhUqz/e
Hiysd5lNdO+qzMOf/02rHW/rZ1Uajya1ne8N9ga7j+58BIvq3wBtZTew8JRW /14dB9NBmY1rC3+hsxhgmqmrNFO7zlrdL5vFIlU8fExFL+fZ/2kS3PoTHqd+
EuJK+mHsrf16kk3DQh321dVoMgXic6s/OfhOnYTTYSW4bRb+QucJwDRX10Cm QqdBUUwiWOr3v/6PSRzlApRHo6D6e/UiyK4nQQlUqU6AQURFWSxBzHu+/NdF
u95a/YfNYjcGg2ePH1PZL3j2X0/C+96Ex6mf0FlYlpMYlvrdz/9nksSFAOXJ 195toHl3DVT1khS+XcDekHwvrw7XN4FVJYinFy8PNp8/29lTZRbxn9sbm1t7
KKj+Ub0I89tJWBXw1GkKB1pW5RLEfODh/1x07d+HmnfXQNUgzeDpEvaGjOrq sK1kxH/vbG7twreLOF/f4Ce7G9sbgCPA0eTvna11/tsHPqWzGy3Pn28/l+eD
+mh9E1hzinh6+fJw89nezr6q8pj/3N7Y3NqHbaVj/ntnc2sXni6TYn2DP9nd OB1e30a5fPJsfVNG8Ee6oNPAp5sbm/K0GMrYz7aewWrC1HxlB5ee5shc5cnu
2N5A/hXO5O+drXX+u5cNC53fafn82fYz+XyYZKPb+7iQb/bWN2WE3liXdBr4 zjZtxp+V+cQ+eyYDTdKZH0fTqJBPnm/hkgZpxn8/X7eb25QnWzt9YJo3w4H9
6ebGpnxajmTsva09WE2UmUd2cOlZgTxIPtnd2abN9GZVMbGf7clAk2zWS+Jp e53/9i3E4BksPwwz+yfBE/98fXHk46PnACI6HJExX9MfCkhGu1LFfxXMgRis
XMo3z7ZwScMs57+frdvNbconWzsDEEZ3o6H9e53/7lmIwWew/CjK7Z8ET/zz bDkDpg3MggTOyv6r12er6uRQXc70MBoZQTRKHyuokDuvsmQ7vHp1yesJsjGi
tHfUd1ySloCj98JklsqS7N9BEKdj/2ReHF5srD/j3YD4mcaWAeI3m7v0TaFH 4KQoZvne2trt7W0vGw19HUZFmvWAJNaiZJSuwTPcBKOtzoDf4OM92QZscY/2
cm57m5vy7ASkWymL29l5NmDpAhtPb3s8gzm5DQIM4GTeSwG75J3dve09hLKB ar+j1OH5yR7gcm99d+vZ7poDCPqc5QzIg+GEpA0TjxEY9OPLf5WKEhB8p8BW
0uAZAR1XKlsc7O4IlPP4LhzNDfjwY5orj+Sjje0BvvsH+XMbZ9TRJBu1oAOr ejWRQWspM6bp5gejMo4fFDqtSYB3uUy7NkPzg2qGxRy/NfhVr8kba+M3P6jG
HsPbhHj1b4CXpcUsy0HipJEIbCD0BZ/6r8ZZmc2KHm5yGBf1ffbgE3lW+LCc X8xYF0GoztBqw7c/ckHUYogenq/DJl4cvN5Yf86kVQC3iaw0xk82d+mTXA+F
UDiahMNE9xin4KX6B/AOKDS9WTjTOZDi+Wl/fdBfX9/aXtvcAShtbC448xyk iTzb3JTvTkCHKIRSdnae95ESQRUCtn/t8wyGjWwQlSIW+wmwOnln99n2MyR5
IkhuAQz+jX8iPI6vrllVKMP8BhmBEcL39/f9eFT0q1Hc11G19ifQWpII1Ia1 Q7L958QBkEiF3vq7O0LyWXQTDOeGlvExzZWF8mhju4/v/kn+3MYZdThJcdUn
WTUs1iJQinRe0o7XzFe/8z/tz6Ixj8w62gEqDqUelci61VU5T3ShQlCWyolW /mGv0tRg1SNGxDDKZ3EAPPbg4qT1NSC4JJ+BmuVHSSgU13jt6mL/7PL1+cWV
R7qIb1Jkca91iWpQbxgWGhSpbFzeg6bkv61ZmlnRTj9xCuC97KuXshT5mJnt f3J26A4QAV3Och/3PYjyxlsCEPhAXhF1gacdBsNJMIi1z6yvudD9g+P9F6+O
ZTY3kqHxPfHbOo89DJMYMDSNw646ze9ANNCzEWgp+wr4P7NG2CYIPKQWs4LO /PPLg/OLI6XgY1BL/Vkw00JdbRK25Lq+tb22uQNQ3th0Odbnl3oIQiEZqzNA
xaR/1O+gMupBofvo6KwEMU2YsU6uz165o3jqMQCuod4jY1wcvfzcp9nr9YAN GXWhQQMticFECfGfk/RqT1nVGXnN5y2i9pt6YJOgDR7Xn4pgNsKwWxN3/r1q
AwaHozIIridxAWQ1qqaoEER6DJuBE1WzHLB+lCW4J6XfAfKmN6huoo7+h4rg 1zK6piHfJMFoFMXAYHXYVd9FOkmCrtoHBTyLgvrglVo2Fq2sGrn5nDWeMrjV
plbOLw7Pj47VYJXVdsCB4JCII4RRIl8tVhdmvBVUc1f7cJS60KzpT4FsQA0o UaU0ALi7ooEtXj/yQgDlWXCbgXCMGgBpPH4URJaxDcOM6k+belq3+mXxchfq
gEhSNdQ0NyAJ6NfDOZgBq9evrnpXegRIE4lpgP9eraJKfj78PTyq6Gs8HVyu UMtZUWPJ6u+D6eyLRapRd/GuWGJ8DsJi0+8/9zeeMXoBnQLPKEAZ3UNRN9Qg
vwakjXGVBMfpXZxnKe4SF351eH55vKrKDCe7iyOtQPvP5zOYlLYoSzI71zhu uZJxjgobYuX+wakCHD3TBVow8ElX3aQxKFldlaTAj9Ozo99fbXTVbAbP/I3t
MPLGjfRdPIIlxymhvtHrSb5PAFAwyWl2vdoPCN6gRkQJCEx4LM+iakQs5rn3 FoXDP2CuxUHWJDJAcB/I68I/eLV/gQzl6PJqb6lMjYZ5rxxGPR2Wa7+MIh3j
s+wgFphEXf90YAOgDdCag59+QlHy4YM9H6RLYAc0CBDcDJYPn5qjUkuOKmgc Ktdm5SBfgyGBHAviHWvmox/dp71ZOHJpcR+kZlToYYGKuLos5rHOVZCEtOND
lYJxUcDAwFWBKGBOXa38Biaaw1keA3OzmDHvmbnULIxzBduahrMZTBKnsNww oOtxgvuXTfuDIAed4DIdFbdg0Llv63yB3KUDvOipl7IUeczHfpHODV41PheK
8M/cAlgGqX0n6FDI0QMyHAEqqPX+Bp58qu9hI7hp0iFgeeb3zQ8fAuAS9zpJ cjXmgyCOgMUnEVDVSXYDFO+cJGjz/eYJylCd15PeYU8dOiDoPjh0h15miWIG
FPz3iSiiFqMIDMosGwYdVqUKkyJTvIzN2jKMgkEL+RXpGFs78BLsWacF7MDu Or46fVWdw2PPANhyb1JMZYzXhy+f+ih93weNGrW1YeF5X/6d778F/UqH79TL
C+Cgb2gpeEKAVWNAwBSU+QQ+6yMqaBV6tAMKH8AC/gHkAgxAiAKnnMUGKAZH H4ALf68VW/WhettERtBhUfL5QTxL3qkiVW8dzeqdh8pgkt72cIzbKI7BaL3W
Tq6vL64ICtkEJgZsOYHDgTe6apLda3gEcCeeFgSBSM+SbE7IJjjso7eHz4GP hBajKAFcEW8B8mx45/enr9QKbKTXhUOYAt8GyMNondUeLPHr+spexxrQCAYv
z111PwHdH5ZUhUkyp8XDOgFgZCnjMLn+QwVLYzDGgvC00oAW2K/xCBjU0tI0 cLygoEEJHw2phemwnKJ5OgHkGGgwWswu4O9RGsfpbd4jjZeNJNFrzbeVfj8D
nON5A/qUeYz0jyub6inY8V01yxDOuMZqOiOmHJAekoRz+Hycg4wAI/6PuujC HIavg5RSIG3o083ejgfjw2LV7ubGhlrp4K+E8urbMgo1LBY3G8R5qoIQX+/A
KsAmvpnMqrJLEEbbNB3NiefMcZYgS2Htk/AO4Az/SSM8/ts4yYbzEilkrIYZ Yjo9s2CcSN/2PO88i8YIA8KNmpxiF47nHZRZZrDwN/iA2jA7DebqVlvYkgJ+
7Oby4Izevzw/c++qItF6RiBMMhBBEUhCMvzxtTKeaphzDMATQJX4WqphL4AH udoxEnNfUADhA7w091CvWqsBJ8oR4qpEAtZxrm8nGihY3jcA/0bJZr3FmwWQ
oJjA5hhMKNQi3GtW5bh5fDC4TbN7YM5ZVfbVa9wRfp9UhAUAi6KCEQuwosI8 55p3OgUVAiz3XA1BTg60msEOANIw+mAOu1gFs8AnQQ9PGDS8Zo8IXJ0P/gjf
zgBeVVGCyL/VQlkjUuMVgiVogQWXR9sO1VjfqwlYYYw/JYJsGJcqRxPeIMM0 VqwKACEiurnAQR4IWqU6Sm6iLE1wcblaYTVkFbAVh4Epb+DclE6G2XyGUyOs
vEnBvgAtH94j0MRwnKCtIDlmaeRDNubRC8Qw0Ar4gYJpwqlKTKBN5Qk+/f6/ ZWGABKDZJPALDj10hg5ha0PCXByEFA7gGVmiC7LNJ8T0V0AJAeT1XutsEszy
ArYAAte+ewt0sPiLfdT/1HHU31cXiUay4Kdo2e05AeY6R9cOLTgHrA/hd9gu T9492YX/r+ya0A8e5RUlhhrIHmUDbZVQFWeQ6VCZw1X8qSRtEJb8+uD88Ej1
IeziFQkCwTHQoJYrA2yIDhe/NYR9T4nt0gqHGnAEeGA1NITcRwEAPAOMa5Vm Vy3qe4+0KnuPArN3P5J9BIZ5y2D9EYD2FgP6IdxC5g1qUxhrz4OvZWlYEqvy
JWIEoDuYlUD9TMpMP4wSdUJCuXJ4QXsgKurWydWjIkCCJCKeYRkDsU3iC8gf vnJ+lh3EAr7TdU8HNgCqEK3Z+/ABXQx3d/Z8UMKDYkGDgOieoVM4f5BLeU0H
P3zo4zrgfXi9oGXUnuySrw2ZL+FWGN2FaYl8CzUf5M9jsApQg8M3wQSKbwAL AIyLcgQGLnNEAXPqauV3MNEczvIIzAuLGXPfzKVmQZQhS5oGsxlMEiWw3MBz
0CV3PwxHt7RU0LPCG8A9VgBBcE6n6DNgKIjot6PE6Sip0CIla66H5hzr5GOP z9wCWAapfSbokMvRAzKgG0Kt9zbw5BN9CxvBTZNvCZZnft+8u/OARd5qkGfw
sVpL78MHw4OAMu5AjUSYXYRwlmdgK4NgBCV7SpyytvuVQmsHgi5KA6Kq7Q8f 308jRxiUjSYcFADKK9isrcD4nGgN35DbaWsHvg/bRS88cGCzJQCBHtMqcCxA
Vr9i1xu8+y5GYuDhjWIAcAijKManAbkTQPIEh0eFHvjiV3BMvYp5M+46gDOp qBHgXgJWSAzPeogFIJocsgFGDmDISWbC4SMwQd2aRQYeBj2Or65eXyJ+HNOK
WMElHuHzcdjUeByP6BBxddZMQw1T9gQ8qRCeB1xKLVA5UEAAsd9lcfQwvtC+ w3Ryd9fzjtNbDZ926dUgmua091DP4nROaCbY6yK2g8mei8lddTsBWwRWVAZx
YQn0H5g9m+Gnb45Aj9D9m363zpyXYwuOYb/8zZvTQ/7yDwA5QhUQiUl2z9tN PKe1wzIBVLdRMaFhMv2nElbGAIwE1WmhHq2vV+MOMKiloikIvgEOgJYUMVhY
0EF6z25SI+5EnUMIsD0Av7B0ha386U9/UmFY3N0EovGaH7ACjq8PT8i2ReX3 2RTEYDYHVTtFMOMay+mMdDuPnAEx+b5GGZqXefRntJeKSZaW48kMjQIEcAzq
e9Da1/ej4d7+/vrbtfrD9T9rfxHCImRAqAT/1KOff4LPv7fqylv4y3zhvrdf RDKcE7eZ4yxemsDaJwGI1wD+k4R48NdRnA7mqOYAlAcp7OZi/5Tevzg/rd5V
82J69Z9+8J52rt43vuh9bb6gEeh75f0fvqYf+pJ/3gfvD5MYDu39L5uDvb9C eaz1jEAYp6DGhqBN43LYdoimGuYcAfAEUAW+loB5gUQKOitsjsGEinGIe03L
r0fuf+8P9h7E9BhJWDAOx3JbkJ2LKtbeoq8VwjK+bMz9pQfF7/1n3+IXP6jl DDePX/SuQQsDPSctix4bzFnNYM5LGDEf6iTIohTgBSYnmA3XWmhqSI5dVYHF
P2sPfts8J5m3pujKCsy39jvA3TXifmuIhmv9fp9XilgU/LSvvhjHN+Q+vov1 c8CCy6NtB2qkb9WkTEJGnwJBNogKlRkdD5c3DcYJmFWhRj2KQBPBcaKOBYSY
fQ992my3Pu+8CAsgPEJWzwbtfAhY25pmwAfjKToBgNcBzsGvqaUjeMuqopoE JqEL2YhHzxHLQFvkL+RMEpVfhshiiRsD0bSt0TpxsPrXSftDDYc0QNChwWKc
8U8/tWb68GEfRCtxTjotoPaYWSTJ8DvdJHmkOdTdm1bVKMzhvxHJpzgNfASm wGbmuvBWhqyPxYAzuOSTo8tvVQ5qtEay6cAC1NF7MPnzDomfEjYPyhbhQqxH
4WgSRf6wvA+rD0vvA7NQZAxsW8foBSJtwzyCdIrf84QoE0G9jZDKQ1qIrH8F BShDI1CWEjqSlDVImJR2u3w9sJwohy3sk0lE6i5pEVabJFUO4doGip2Q5siA
jMw+GhtFWQ3x2xwV6AJHkx3lYEDh9PJnsWiHbDKANqWZiVhnS0HaDOrp/vEq LIMhWTxwJERU90DNoDogTF2ZhlNEhoHD3Pf6AI5qSjKCdjrQgNaaAcqsR/SD
Y8R0l6m13eXsCHioRpZphQ3MbNXSaoZe0nAayCI9uukHb2iVtJkaUyavhgNu E7AMs1DTzhAsQKVg4wPPYgbEZM+YXKd/FIQHr2lnRPzdOpdxiB9wNw6J01l2
ieOjCiEn66DI2p88LQCkqdEwc7ZX/WzrJAqM/cCf7Ozgt2xs0N+KAXV1fKju Rnye+BgydMQRWAcafVmQ0zJq3yT+5qG0IJIIwpsgKZDbot2HAmWkAzJe8c1p
wE4AUYOn6MzX+nckbXh9U/Q2+WLErRBFyWvgzbzxEg1QCW2JwEKLFKMMKZhP VERjxAk409tBMLympYLdEYyBZNj2BUk/naLrhSEhuoodJUqGMdCHWllfVRSZ
4zybwrsnXVAnUZtiCxJo1bwi/HqqAesiK7fJDwtHA0OBlIz6bOdOQlJ4AVNT 8DE0oci3N3Ikgo1a3N0Z7gk0fQNGNILtdQAnfHr1BoX5INZTYvE1AKzkWldQ
MHTJagZtnM9Ae7xXlNFhFs0RAHS+VWGeuzi/upb5QIMFZQ2WCiafPfICkV7k 6FobZ/vuDtjxysYqx0/h/ffkLeIpjEID4AD7JsI3gDRjINEYp0BXILk18GRW
tFNj6KjckRCBGupCOKAwx7e/OTaD94OTxxY31YDW/P49Koyk35Har98B4Enw Nlfh1EqWLwgDD06oZEufGJ0ri2B/o1E0pBdxodbhi9a2bA+IKRfGDax2kWqK
7WyhkyFDgjfi/p50NYBnjopsgI55Yj6JfmfMQyNFSYkHFAGM6PJZeWKX1rFA Qg441k0ahfdjD4EAlkD/gdnTGT59cwhqkO6NwQStSZjluINj2A9/9+bkgD/8
e4KdGvxcoEj1kfs5fzBNB7bZHdqiGMl8vvyH2eYt2DYY2yxU5+zN1XWny/9V EwGRBCNZmszXo/GkuNX4rxXZoo0iBNgxAr+wcgBb+eWXX1QQ5DfGqWF+eurl
r8/p98tjIM/L4yP8/erk4NUr+0sgT1ydnL95deR+c28enp+dHb8+4pfhU1X7 0dXBMQWR0A/wdqPfX98LB8/29tbfrdW/XP+z9hdhLwIGBKP3jz79/CM8f2uV
KOgAdXTYBumcX1yfnr8+eNXhE/HdKOh0ZC0bbe58lmu0KsMiAK19lMdDNjFf rXfwl/mg+tx+zIvx6z8972fauPq58YH/tfmARqDPlfN/+Jh+6EP++dn7+SCO
HF78v/+1vgUg+gdQ3DfW15+RrfIPFFHY3RLGwrORCcV/ksWGno0wx1HgOADZ 4Mx+/rI52M+XGMvL3M/dwX4GVWOE9CwIh2NVW5CdiyLZ3qKr08IyPm/M/bkD
ZnEZon4J2FqA0Z0qYHzAYIJffI+QAePll8PRbH3ra/kAN1z70MCs9iHBrP1J xbfud9/hB39Qy3/W7v20eU4yb01NlxWYT+1ngLprxArXEAvXer0erxSRyPuw
62UG4oKPFkxjoVn7vAHp+noPflv728Dd+/CXv8IonOqt7/3qa0CuA8c4gTCE pz4bRWPK9kCb3KdIF/lLvuq8CHKgOzwZ1xfXuWtJTuW7zqAO++kiDMmQ1qEo
VTHl4xegzbpYevvwYuSXSYIHpjooWHmwDp5oFI/JrCtjtD1iYU8hMLawQElP upp1kA/aDwP7sed8DHQN84MuBAsvRXUlp0MlaZAPwEP+DgiRvO1HCApaNY9r
uQTyfIOvhuit0DFJpLAQmUcyzog1JwrbIk8ElB9HQUI6YHHWkhhOGGlxkYB8 9Hmk+iUrs8FJNmEwDAMnB9p3iFQc0KkPCZ2MHyoACV8O8NMM9fscByTVCUZb
7hhZpNqyqMOTI49LdONJbz8ID6v5dxBUoZUmbA04r11YtuWYKA0iBxQbexg7 JccTj8GMt8m3kHGwUcO7wI9tiCZnrSugt8ihIaeo3lIM/F23qX+/lYgzfNJk
sB7FsM7pwpom3cezFTHn+PETzpS4LWpGbK8HTY2heeYySUe8Ygh1TEZw0owM Ovj+WwkpvQNuqZE5WiEDC7BadDnDMH8wNWt1SAQA/IbP9rHwDf4/hD8SwuIV
8I4RL3ig7DqNWE1reAP6AX1Uj2EBiAw7EBbeedw9iNkYqx3YDAjcP7LAuNTA AT04BVUjmuI6QZ3AsYCBWOEEULfmqSYV/cOHFv3e3e0hSFE5YZAWZJeTPUDg
XwB27Gun8Agi57Vhxis40mpNAYUV4ocoHxHERQXcA+xXCiQQYyePT2u/BP6G WgQttOebnpZhkOFh0RaixHPFAg0XOGjQ854CLz4ZKT4FI7zA8XwgOhjXRgsf
0mcUgXMOlSIrCodxAuofuiTaYHFRVWcMr/c3BJlnYV6yShOWXaSvMAJ0B11A jK3bRgcr5R+FCt4iVHhDq6TN1HQdippU4C1wfNTe5WwrKNqoEqELA5CmRnSv
54hqnQR+JY8SD5EXcEI+QlmkKJorgU133FsftTJGJzgfdMIQFYCUtdpKgwrY PDL1062LPmCq++5kp/s/sO+a/kbSoeO5PDpQN0EcAXPAc6zcWvXPSI3jFU4x
rjHS05CegU7GLkQlXoHFk24xOCzmgZibhfMkC6MOSx4U/R3a0jLk8wWuG5iG BcbVz6o1IiM/c/z2wPTzWgoJSgGMnSbDAuzvFAgpPUaLAuNy4loCMWjeEVVo
tZpXl/WaRfIbdoSKBI7OrOWRZbCsqyivpMwyWhJQbJjALl4COg11ia5JwNqI qgH1QqscU+IOnA6Mhd5q3OYArIpRRD60UkCPziN+j2y/G36qHQVHrNZBGs4t
j2TeNWqMfhei3lEsoFlULuI0BEYg84orzfodRqQD4AJY5hEyT2DECBjBFCgh N6ETN0OApn1+eSXDgL1bFtXx50gAohFXdgMdW3U8RK6G1hAiZpffHplhe97x
r5GG8pzz8Fw1DdMeL0lQPyzJQ0VGDNAJDGC1IJLqNPtIA1+OPNc2uVpxEaRl Q2ubakBxGwnJNLvq2UHAPlY4CNIwd7bQGZmGpKWzXn1LJhLAOyO3PSZ2EUOK
Ge5j126G4AkaJ0U2BwDpSidyRoDcbGmxDQ626E9fFHq0D2DpMfbCf+ThD8tV 9XvjSzLqKpn8AE3AkS4D0NFvaTULLBbYr8HYBcYLoIN3VaVw0HQHaXKDjisA
pSD4bhInxCBgZXSeAEVARsckjQLns3SiOXjak8V4uEY3zTPAChqms9bBCMMt Uc2R2fhhVnqt5wqzP8EKP31zedXp8n/V2Tn9fnEEBHtxdIi/Xx7vv3plf/Hk
+qSNSu4U2gKAnwgGe5YJKqak+ZK/uSEcbDTXW05bhvSDiwwkLZ4Y0xLbpgUF G5fH529eHVa/VW8enJ+eHp0d8svwVNUeeR2glw7bOp3z11cn52f7rzoLVBk4
Ogh/2A85RFdyikdIcY4b8ZYzeN+kMXG6SzPNKcVBACrALd9cnlL0pcpj9kHV DzZu0UGXzTLNYSgPDPVhFg3YIfXi4PX/+m/rWwCivwM5s7G+/pw8G39HGWm7
mPKiNw7ljRG+0Q1QkFZlhpJlVJ+9q9gBxlwqpNQ6t9coBuQq0QFnhEUekUF6 W8JqeDZyuPCf5N9BD2iQ4ShwHIByM+DBaNMBtuaT9DZRiBMA6H94i5B5t6e+
cniB67jMKiSigwjAUAK5EpEYIBAu5WKmgvE0QjOVgsYRRcfDUrz+qEwUFLOL HAxn61tfywPccO2hgVntIcGs/aT1MgNxwaMF01ho1p43IF1f7/4Ptb8N3J2H
cmK6i5eqSEskrXOIhgVoV6LqgMZQ4GC8ajjkL75QR3ZCML0tjK7nM03kX1tP X36DWZzKX3/2DUhbIH3LSoE8hHXlTKEoTsE6FGbCB1E/vAg5aBzjgakOCltH
64zF6w1Do3AEesHIXFxMmeeKtSGSkuHmXsUZxKvIotCbGpAHJD7YZ9qyxaYA jQ2jEflYMClOo1+F2FUAjC7IUaem3G35foPTBujbhOPREYkploIk9Yygq4Rj
Xu02dT/jmizqPk6ciLMR+0CyIHROS+PyIBYMOMixtDEGOm7AvMzR78PuK1bg WwiKyHJTn5CQ9lnAtWRIJZ60OFRBZnfuUVQ6PDnyuFg3vunsB+FhTewOgiqw
2MoHznOHiZCIwGIpM3E0Ack4cvXt4Qu3q0vheOSJuGzLYjLb8bhkFB2ZYURD 8oXN7sq7LzHammQTRULkgmIfC2YrkOZPjiETggjqjC+oGa/oITMSsGLMjzhc
ehGz32cFx11tD7xyeUmYjPlBHDcxmUIU0aCdROouDoFanW/F6F9yEKIRkHMX Yr6oNt1ozzBXV5loHr5M0hFfOoJfdVwxR863jhE7eMAcawlZh2v46HoeParn
FlWlLsQNooa4snHj4EZ83DD5Gx7OXhqcVSuw59XAbOUixBgT6QUG92lhD1FL nwGsDF8Qjv5wOAFT3tHXAnL4zyw9LjSwGYAcx/kpLwNx9Mrw5BUcaFUFjsUH
IXqYDZiacDcegxeK7r2iKJYNSL/WNxlq/EgXKwevLl6vqtMjiecC2yOPEDqv 68OHKDURwHkJTGQQU3BqSvydBGBrtwT8hj5o9INzzrhFjhQMohgsMp0vAkqV
RbsgVmYmsulRzelgmPYoR94wrNmYMa2PgGiS/dh+kJgmPZ5NYKMYDDsCQyXW nFv5odZ7G4LTsyArWNcJCnS+giwFrAcVQWeIcZ0YfiU3NA+R5Z1eDa8sSuTN
vRMQd1PUP8jFeX51rFaOj07OD+mUKY0J3lwhLYW+5fS/mH1YqI6OUC94wZJM lcCmO9VbH7sy1UnSwuotDfxn34GRm4boDEBSCjV8ocQHt3ieLZ7HohoIuFkw
AtqgQAgoDl+cA76YODecGJEnroNPnLQjDko/G2yD9kGZD0U1Q0ccx9fR3QCo j9Mg7LDMQdHfoV0swzZX1FYD07BWB+uyRrNIcjsBf2YqDyyDpVxJ2XJFmtKS
i9rGIsRlTY6p4FLw3nEIANEVibM5TwwEgOFjCgtZtHL8BIgPQ2sYMhxlM83M gESDuEe+XhxBvw9Qs8hbxMgTDMC+BxKXCcR1bX14QxLzOBOLNULUCQwZAolP
yKP+fjMbQtQgGJhWgOkEOJH93khQOr9ihLAvgqY2ZpWv/hZG7sdKqAsVSdDv AcuzGtorJ04H3yunQeIDkYQWrYG4ELEHusDICn8UUbBM2eiWqFnAsGEflSJk
k/rYzhdmdYRFeWIUSyuZ0ZAlUHhQ4QAQjMzrYoIp+s3NOVZHKEURR58YDfaZ fBSwKA2smeEzp7WRfmXYjd2SeVPmrZ8U2R8ApEsdyxkBPrPdxX4uMD8/fJbr
4E/tbbNIUArhM1QJUKcOjAXZuwuTClOw7kZEqP9Fzy0DBHwkNyJnRJCqgxAQ 4R6Ay2eEhf/Il++WK0me9/0kinVNK5yhb7jiikZ1c5k5kRl825HCeLhGN81S
dQ72xTLCjesPggx0iNpYt276TUjqCxqh4QIcKCdzjlyT/mZEL5HhydmomWFV wAoaprPWwUDkNcaujG5eKbQ5nEksGOxYKaiWkuZLcamGWLCZY85y2tKj571O
M45oF/rGRrNIGRxSNFyz6iNsuybDVmS0nry62g005pUAPFAnQscljLXe29je QcbiQTItsaWaUzyU8Iod/wN2pMPJ4+lRSHQskTUG8ZskIgZ3YaY6oZApQAaY
Vtmo1MiKQNM8ePH6JR4xpqd++LDPAYXGUOq5Wv8FvHd+eH18TQ80nacmcYEZ 5JuLE4p4llnErt4aK170xgG/0U7fvbvz4H10q4OVnKJ8GdaX01XseGZuFVAZ
S6LTGywbGCtaQXM01JZKDjz4i8FIpngKML2A4u0CBEeeoWGmkXN2to+JOABZ UwWAMAJEK9DxbURGFpLFenyAiSHqIi0RhfdDgE0BNEzizUCGECwTOxZsqyHa
BZOqQA9Q4GuThmaWgVJOp6a3i+pMOIUb8+YkfxQujVweIWwTTEgSHGQqrvz0 sZS4FlJ6HvnzjG6RU6g/zIjFLV6qIqWRlNABBodA2RLNh+rFYDBeNZz8Z59h
E/B1jHa8Uwf9dY/8VjHBYIAsBT3VTTARtTT0XUWgloWxeBu03gMFmsMXqdLT 4pxMCLa5BdrVfKa9l831tA5eAlEwNIpIICIM6Ef5lCWjGB8iLxlu1as4g3jz
GTA3XAYPxm5hQU3J3TDQ6HTFpvqho4CMMUcOmT4wgOYE9MofQR/rjUG/D2I0 WSQ6UwNGgdwHc01bXtkUw6vdpipoQgJ5PbaAE6EaACo20DEoByeF8YoQXwbE
nqYGUmRxmzFR6PTiiEZB7w/+7Z8SyLs5AsgwqN3+eh1CchT3oJf2akeAM7gz 5Dj8CKOkY7BDM3S4st+Y9Tl2AwCXugmimNiTGNJMMU1Asu/g8ruDF9WuLoQ7
oC0VTC0OoAbvOQGEsAwPdRy/sykHcU4hCpz+zuIt2WbihqLX+sF3mpwzEinw kqvioi2Tya7H45JRdCiodil60ouIXUMrOO5qe+CVi4ucqAHrTTghwlSeULiR
vqrhOz973fjEmhWYt0rWOSlAlirJDgjlFeZalD5GIxW6/QXbm7Bn9K2xigJY thKqmygAGq68L0YNk5MQ1YCiKrCqMqlSY0AAEQs3jh7ciYscJoPUQdoLg7Rq
TMPgNAa83+ILZhB+jzRqME5HJcB9HNOGGi98xRErttpb3zLzTHAujGhQ4ho5 BTa96pm9vA4wQk0KgkF+Wth95JKLOmazLUyaTPFbymI4DwSztvAAMGokagYx
alqLdHiKzF0bWn4yP3sq9rehY/C/vnA5kUE78CN4VRXGP4tEYsIVSsI1LdTF uA8fnETJ5lQwRHuEQ2eInledreM1IIKULHsnsYQmPJpNYJMYRj8EoyXS/jHI
9LUQQ2JimAZg8GeRUb3YDs8NJcDw9k3LtsDqn3G4iowMj2v+UeeZMmEOhPNB xSlqJBRYOL88UitHh8fnB3TCVIUAb67QB3kRYNwd19MBBjhEFeEFCzXJfgFd
QSyRfBqLOGpMKG62SCvY2BKUN/a0DosYZaw4WHKTlWg4YdDwVGCQ7vK0sFYl QvZ/8OL8YtUmxcAxEVHiAviYSVHiNJbnfdw6pUnl5Qz9c5yMgz4HQFiOw7fR
gnsaFlR5RYuo4bjdFSpkqtTvMCSV47PT8PcIA7ReNoOVHwfvdgY/Eoml/Krz lfU4xv0LwfaKLwBsuCBpzhMD2mPGCYVkLS5VXARIDmPcwnng85kkkDp032um
RA2znEj+ZZUjCiINL1k82S6c+VWTbqRtvMnjHmXFGMN0OA+MbtNeuIXBOR/G T4lWBIPTKjD/CCezn1c1UHB4+RABn3tN5czqYr0tzPcZKSEr1CuxFKY+duUk
kU7KkCAoH7yyx9Km4dp8gfGsWeujnLS5OtEushJyA8hShmB0YHydj259w3Cr M+8/XPlBge2C+Q0ZBrkDJo6/wjS8SCabvNfcacXxCLkoF8AlSYOHJvZae9us
Fc9J1w0Ml9zsrxOcXsW3muk0tqZg63hD9ebylA4YRDzLA+IUcJqcEfbIeSLd GBRGeIbqAqrYnrEr/ZsgLjEVvEmz6l9AkVq5vBnSE/hj1fJHwFhyQnKeFalH
WXEApJNqR8Kgp005YgazAfJg+MzI7ta+ActdsiWrRuK4+j0m800x4QrpiHaQ CCbRDGG/fJDVfM4oxF8HuVU1rX04IU1B8A3tG+BPGdl85Nh0Nym6jAzPrkpm
MA7CvBGlbnKSoMnzoewrfL6YhcxAmQ3LzJrKUzRxApiyylN5kdR5eBVT5ozW Z+WMs2VyPbZBZtIbB5Rpo1ldEq5eE3ErMpovr652PY3ZagAn1KMwgwPGwnKA
gRlFxrdkVLmh2Kjsbkibyv9xLV/anHojBE6s1oQTiK+RY0o82hXleNL4Po81 bZUOC42MCpTp/RdnL5FWsRjy7m5PosVYGdkYT32l1v8BXj4/uDq6onBg0/9q
GWFk+hjpxpzQvkdexOQG0xsmU6u/Wr9XLAKYfBZddZOxDcP+DaJ1g53GeRmb MqOY/8Q6GcNSYU5aRnM0VLMKjl+4K8KEA3EuYP4SJfQIJCpiDgy/DSsvafus
xDw+V2DdszzG4ed9cp3QS1U+ywoT6yfWJCtobZwWUFRTlkpDNp16DCWwCgWl iF+QOTEpc3Qaea4aaqhrGTzliGp2gOjchHC4MWdOcmHh0shLEsA2wdwk2UJm
LS43pH1PGd27wXCd2PdPCibrUCVmtxGmWWAa04kMde0EarZ4HytPxsJxYNjH 5cqHD8D6MWjyXu331h1CXcUMpj4yIHR2N8FEpNRQlBWBWhbGErDfeg80b46B
Bj16bFTP8MaxD9K5pIN45oQxtth+dEkixCfEVqQdL7EXe4osCY25CuJijrBQ JEpPZ8AKcRk8GPuTBT8lOQxTKOYWJp2umGR/6CigdEznRgkBDKM5Db3yZ9Dc
zSlhZvESD0UmAbSTCna7/D4/GEWJuOx2p9gYLp+sL0wDlqxFtbK+qg6QKA7g /BGYB16ENtnUwKsq38DEfj8KaQj0GeHfzkGtVHxst7deB4+cwy0orn4N/iRH
B+iDDj4bxaSRWAYiwTVKw0HuhuTJ9rV9xNCXzVREv+BqV61srKpOPLvbmgAr 7AHQfnKmlwqaBvM5vYxQDE90FL23mUFRRkEOnP7GIi0ZeuK2otd63veafDgS
o/Ag/rXDfzmacWTUGMd5jlbJKbmyucoPn17cbeEH8N8dAy9dONKIx0To1qtj aXA+qiE7f/eq8cTCAetuyKYnDcnSJVkOgbzC/IzSUmmkXLc/YOMV9oy+OFZh
UzjgEFE5HAMDx4zPrqRIErwxa2XocosM+P39y1l6xqbhMS1X1qKTJbxoHqtB AIVpGJzGAPY7fMEMwu+Ryg2W7rDA845oQ40XvuCYF9v6rU+ZfcY4FwZEKCGW
QO9QiX7w4Sb9dHFnIuVxM+eeqif8Fz0HYZWUPJksmHDeoqbxIdP55fomzCPJ PDqtRVZIimxfG0J+NEd7LOq3oWOQv75wOZG+5PKpRhEIlkOhat2JCFvMt+ns
CWql0WDiLg20vbO3xUo7kSsCH3OeWt91LKYt8hKkmSLebtLOWaBwTpWEx6xD NrYEeyq3PK0gIT5RyyfYz4lxkcvC5Xv4mYHAfTMYkxnWFKGoFB9KJqnJJmOe
VKg5RH01HsUZGII+3MWpi6ndwMhuEMScVgRkkLBCYbM4OfQD3NTxLZTRlnHR INJwU2BY7uIkb9bXoNn4DkE1DXIsFqN14Tg1FLWMFFUvVej3BVby49enwR+R
mFNYLMDBiFTSio1ZTKuVmMxCPw7v2gWUyKPbCkeRkwTWx8vDwRq6Dg8TGp88 L6B1sqlW+u93+kQflLxP73bJ//RWSs/fNWsVHgORCVGcLGgACjrGq/8KkIF/
6YX4TuHVOsACMSPkHR0u2ogozUosUuF6I5T2aaqTLozFlkuFS9DsiLoP8zyk W6CowQFH+XhQ8LvkhzMRfgOKVv0M1vVk2sYJwS5FOw2kRRVNtLhlcDPWqJpz
QNTcPwqDrQYpQef4slATMPFTNjklq9BhK/ofK/gX1AfBlaNsCivj5P+Vg6PX /m00QjiIYYi1MeKzY1fWQIMpyxUXiM+Ur13Dz1fRtWbSrkZpghL9GRcnBEnQ
qxwczIYlBz6MEEO/My/NH+wRMls8VKh+/B3whx852A+jrgB9HCRxWJxhPpKQ C1h+EHMZzDmNApNAF4LPkcdrjuwAzT4xJVU4QjAA1W/KoTmsjYJtIBaIxG8J
fdfYJwvmcA/zRKsWfwUVMQdLo8taYwI0SshkzvmPZWkz72hE2DuCX4JuBIZT GVAxqhxw1qq6ctxz9UdMM7YVYbSV2BRhoe+/y5VI8E1J3uPMoWv06Esqq5F7
621TK1evKcTjymvwgDCw6Y/FGHGCrhVBAfgfaXc2fQF7POT8mWa73WAGqe6+ Zn5N3RQ0MRKYuMwSeZdOCN7GdFmjsdRw/d8Fur2nBy/RNliSXzwOxoR/CE1m
Or3EuSKsJGxinz0P4Igs/T0+1XeifZEqRIh+H85NdLPgGAuFsrvOLPOP1MxG 0ATm8AHIctC4Dl8DVfYA4wAI6tChItUoQ+M0MtUZp0w95Obh3DEEVodCluQ6
tILso6YiwfLHFSUaoG4iqWDCEwCRSR7EvB6g2xmoSaUtY6jSXEvRalf8GEbf maLLQBuy+KZdTiYxCS58AZVljDkok6kxEfhsxCPJSdVS/9dVtdmZCxn/hPE2
Ap0ZC4PbsusB3dA9nCLZTeKbCcljE0YQbYv9Dka0NBSlgpy364T2TZ3pgN0d m1AUQXbEmgd8K0qFSBvVXZ+wGIskH7sGAnJDpxeVq8xNqBOVRxP5F8pq6nMc
zhMbPaQtIuXWlBpB1DF1/njY3xt88cUX6ljC5VylQkUlvYl+97b5t1etcmXz XBYC4MxdRMxQoz9bPBfs3M5MxB+msNqgXX8QBjPOBiEnnWNR/FlnqTJZA5SX
JtNqOpREXIdZ96F4uQuMuaDLVHSPmAntHlN5KXWQa1k53gUPwDTqx/FYDcIf sUTGPIHEtULFWyJUFrtp75UyjxQx3spPKGN+agkZ8jQO0oz045dlhvoaKrxL
gXRTZYLuO9sbzwZfOWFIJdYloYrKqagRRvWVsFXlCl+46JdkGcO+r160ClrA tkKeQGE9rjFIRvubLPIpzdu4eYENGX9Be+EWIud8NIc6LgKCpzx4ZQ+prfDW
yjMVOFxWY5Zhz/qBJIBMCovhqXGMqhcrt3b7QNKnB68PrACw62hW/cSUroL1 5vN4PseVV0za9g/JStS7ycu+UEFY3zBcY8WJg3W9qtp2HeH0qbz5NzBmz+HL
JrOJ1F4hPyGcAIs7xlCXkEwtY8FliYw54cuLgZftMLvVQfmRJMtuiyCJRWFg TyHzFjBj76MF3idKu6sqfGM8HwPx+LLzPmk61Y5qRYvm1BsZZ2SXmBA9GQHE
W4NieksYRixuYSy52eK6K4GXGgzgfz/W8xVW97ki4rKx6BX7NWfRD7bU9ljt 3Co2iBEmHN81SEyVA05uTUE2G+5nn0/ByBdx0JfGqVBmszQ3qXXEqGQFrY3T
bKkdrXY31WAXzl3t7qmddbUTqd2B2hnhJ4NNtTNWuxvy1s4uT6q26N/Buvw5 AvJyyibcgF2SPkMpiA1KW1xumMY1kXgMmt+0JhZJWk+iDLmxnppIIvdJIVig
2FEbe/jLujafw4tb5q0nTWEHNyvkweFF+Iqe8Xa9ZJP1pBC7WZRTfclUwb41 kyKOdVyVVHyjvic/lmSUUG0QwRehzwkdIQPcyXDosMsrw+BSW7JGXDvnVqTs
faXWt3d3gJ+95iNeV40n1IpXx4BWyPNRZkMOq0HDv9bIuMCcYiRJsbijvjrB S+31PvwAqhAM0iH1LKloSZI4KAGUCpwAU9mFa76CoxhsWzFGCHaueie1J51o
LA7yqd9nLmXmnpI76ufuPH/BjHz6gD53cHCk8OhZOcEy97wAHtxZw1A2zu1U drM1AcqmleNfO/yXRSHSUixiLRhrHcfCmNvmKn/x5PXNFj6A/1KHJ4AH8Dg8
77SBVDJVsGJRaK+NQlt8WHxMP/6dEGigtrfx342NvwkC1fb8VyOTUnvbn4hM bYsr0YgwX0bYfFclEBo5r/bVyrAsBKyr/+Eg9WlASjMLpxdqBd6tY9t/PHC5
z+FZRKgrWx7p8KMWa+mspWtw3I+d5DpuCf79+53kjtoZ/m1P0u35rz/Jna3N 2UKfjmSkyPnKeLEb3rbKfeYycaw+RLmJiYi18PuCEBQx64GuMedazKuHHWdG
Tz3JtEsnaQKgRiZgUofNYa5Xp3SR8CcSfcXwkWUDaA+Psp5+Fxfl3+cYQV2K oozAsA8Nerh81FqAC8fdT+aSlO045U1cg8M1Vao2qQ+PCM34pHOHGvOFJeeD
6BiHn/sYd+gY99Smd574+a78uwHvDtXm2MxldrQbfVYJoLY2nn3UUU82u3Ta AW7hZBYuOYioO4BIldNyatjck6RSWQfjcPmLsfYJULaOYyb4/mh0XYKrtejs
dGDP1376FXpHfKHA1WJnYvkeS4uCJUl+LEM6XqEn8vOe2M0dTFsrQQz0XnKE PYzwHgS1kVOLn+QTCtQIRA8WN3alDJDgjbnjgyrD34Df3b+cpROyMapHK1y8
RZlEwpF8LjlQQbP476GfpW07SKdtzBi7FDnDiEx5fzDVURxKVtXSHbAHE9+b 6GQJL5rHapDPOVSiHfxyk3a6uDMxBXAz54671NjIoR4FZVzwZLJgwneLmiZR
pqB0pQCb7e1N9Zc//6sr6DQuCNHfTJQLyETyHbyZYpeZERb15Iwd0uql0MsW g84v0+MgCyUzv5nK3q2NCJ9izSoNvL3zbIsd4US6eBhYidD6rGMxb1FMLkkV
oHGosdaXo57iSdSY9uDXHkZJTTTLJXa+wHp+zz9LJbherZWx2SQdDPTJgryZ qYCmUJy1BK50INPLyUIQyg7QBxwNo7TMa+cgmRRY2ZyyEiCp/kAWMdsdtmSR
pXQxEG/s0864meHB3gebqNHsn8Hu61qjD9MRBcNAZL6ZsYparveCILbnyuR5 c7NA6arUG1TlrX5DY05hsQAXo3mTp9nEmWi1otMsDKHyrquML0qjaGVvUkiy
KEsNLC50wqOfp+6aolQxVLW9vD7QZsgPx944Wg8Cu7BtDHxzk+uYeCoww96k Wh+O1rCJeJzAZMKQNYkv5U57AlghpmW/p9PGqIvVerk5CFoFSQKalpJoQIlL
CXoBjStP5zliXHhLfkUwaiO0qrt1ZZtijpcEk+dqq4t5TafTmVcJCODHlVt1 0BwDvg2yLKBMsLl7FAZ7DZKCafJ5riZpXiQcw5Fqnwp7Me5fwr9gZUgZxGE6
nQI6XJlg87oZppzaUjpPjQ3LsyVJPPynn5D8cLSekdBsQuIZ/EbKpUx13qUJ DagDG7ywsn94tsppeumg4PQjo+tisgcvzR3sAbJbPFSgfvoR+MVPnGcLo64A
KVi6FSv6YYI1CfqCboyuRR2XbW0FhZMkXF+rV7aNcWqFafQIF9s1q+yMNWvq vezHUZCfYk2AyWoVQ3LBFNV3eZ5Vi76CiVgMoTFLRGOxb0T19FyWVBS2HIZG
1uzqxe1tnNbYU3A0Ai3UGOfk8iMjVxxJc/azCwnU/IpEHJb0zKlg8jQZuLQ8 hK0j8CX7jaBwYkPbauXyjPKsnHYYpD3UhmJ0OMZIpZw//I9MQJs37CvU/OmZ
KydzncSSam6sKkPD3KLCZo2yM+oQk1+BiJAQzfZXZSIyyKWRp5dOxnYZnZ7t 5gCYQQuy712be0msUhhL0EQ9exrcBkpg5kwsQn6RvURofhvMTXJhzmlNlFLa
i9NKxefUSUkkQ0RG3yhZ8gIjxbSL+do6tYW59dCHQVw/umVAathQuzbQdx9b rbw57oGa2eiAqr49pU0mHJWU44sGjBRjCEcANCbpEPF6gGpnYEsVtoa/TDIt
P9BBK7/M5adtSvqHf7TdhcciQ9M0hoeZc/RS95oSwfhJl6WS4StVYVs+1N5d DR67EhM0RhkY1thNsy3J7jEgqy8nSHOTaDwh6WySAMQk40ieETQNayqnrIl1
zgRXuK1MGcZYAMeOmwWCjkgNAX8l+YcmZH0olZpMZgCpntRufmglsAs6F5J6 QvqmYbXPAcQq6yG8z6REuq2pN4Kno7RMPirRwvvss8/UkeS2NnqVSUcctlUR
gumb2O/KpjXDOUxAc9Dkyx4oasFDKCXniQPbPNnQouy7OTzXyzFjdVUqtzHI NbGPQ9UeQlozgKo8Gql+0GEIdfp9+iNKKDPdTZut/CMbAIQVbJ5xsn+2/zkp
bZx45HzzS7WZ+8hoGjsoCky54U9h8iu026DuYfacH9LmE64Vh6w6Bibtp8hz INE4McG6znq/Q62FLNqu2sAE5fNlU8dhSCmTZAhyCw6KXCgTuUBAjdhfZZq8
O62SMp4l9TXYYKBZHHah6NpKY1dlzJygS9Yr0FBFKRVU50MeoiSrlezwUUh9 k4qGqZyk+TdbVFxGhidzV/lG2PdWOm3wijEQYnq4ETehaA5W8FKVksmjg88n
LvXUcfULkzCfIpfF9Rmva0wZbQMbFcH14rKETYeFrdjg6Ypsqtls1gkyj9OU +r36ieD0E3CnRJnE353tjef9L6z85yZX0Q3a0uj1yKjNEsDEVT1XVa3NBcVv
fHJxWpRhW0QQbo+y2dwet3FqWXJrSggCPX1b99h56GW5P+NXy9pWcZJUWHJQ htyT4QV1rKBRqqYVXZAV0neDTswuxKK0k4osEQHX7yhMhHvfsTJvtw+MC8/Q
NmkirDeqKrPAFPl3aropKKUYFuzU9STMReiYvhY/+I0tfni71qH+KFz2T3RN CDkOsclimt0+IkqJx44Ss4k0hcFjFPNhH32QEWbSCX+oZU9Xqekjri9xEm/5
6FTTdp6uh5Dm+2gfjfpb+6TcrSyZY5XeYOHxlCcvpGKoZeS0rBTrP3D/c2aJ BOpxW6N+81fiNL3OvTgyXfwsRq8s4Y6RpJRgY40tbgqjfiLMVvhv/6d6kvQq
MSEeMk7U+oiHCuozL7EkvvpK9b7++oTYxC9/2QOmyH1Rf/Pm+PK3wL/KsKyK p7F4F41Fr9iPlepvqe2R2tlSO1rtbqr+Lpy92n2mdtbVTqh2+2pniE/6m2pn
ffX6/Pjy8vwStJBoXw3cu+MkvIGv8+grfmNfrXfVweur744v95EODt5cn5xf pHaxv/POLk+mtujf/rr82d9RG8/wl3VtnsNLW/jGo4a2A+OqeFB4CR7T584u
nl7/lv86OjrlalkcxI0Cr17h5+rq+BD/axfX9EvYH0Ap+kG8ClhnubTF7E5r vfaG6snotDEUvT2hc2x13VNqfXt3B5j0GR/lump8Q61IIwI0FL8apjYvadVU
kU8esyqC4Im920jn8jmJezKbiQbaD+qd5pDTNF1aCySiiW+wus+JB2xsmwoj /Y+jrzo8M3rtsaa/HppvpHhj+SJSpYkE9dQxRmEoF+c2rZgQN/6rn3mVNODN
JGdTEgcvTkWyPbFfULOvQlPX57iqt+7HyCxoiMQnCz5miwJAbobA7ngTR6vp KBcIUOcGDo30Oj0rJtjDM8tB2HTWME0W564sjqSBUDKVt2LR51kbfbb4wPi4
ZFbBYv0Ew5iSP9IPTmw/tySpVfIutmTCB3iGPcemhrxAbmPyhn2+qVSQxk8J fvobI09fbW/jvxsbf1Xkqe3xNyOSUs+2fwMifQXfuw+ZLqVnE0pnVJ15xHqK
TssnayspKEODpTqKaYrlF56J1mZXEUmrwxP4JzHdVLiXAeAXmSCF5fqg9JMq VmctWYPTfugg13GH8O/f/iB31M7gb3OQ1R5/+0HubG3+loNMuvce5EmNzVOq
/oE0dL8FjlmSLQ4vKjiOguynMRwtmmFyJGystJUNm7qRskVx2q7hQ6lUb/th uC2UrBfFd5HkJ5LMialmlgGgA2CYamyC9bc9QFAEQzrAwVMd4A4d4DO12TjJ
dOs8x5IlOi86vNriKjrEjf5gG0uPCVCr7lvcEcClMS4TSQp2sewEq5hr7wi6 Xfl3A94bqE1UU+wOdsMnYflqa+P5ow94stmlM6bz+Grtwzfo7XmMFOCeL6di
YNE/HnZIdZv+vIENMJsKNGv4CVxN1BSnZoWejEKdUuiSMdcoMwEswObbNrtV 0R9Jm8QlZUQsNDpOtyZk4L74AzpYFIP9kv2XHHK2pUrSR9kUVHjNFj73/Sxt
mVM2Kjztx2sbZiY0Ft+CynhrS8RTDToc2A1tdBuazB3W7mtAdkmpM1jFLKfe HUraemPGkyor1DQY9KY6jAIpzVi6cg7c4HvTBLSrBGCyvb3ZrVoxGX9KQ7MG
AnzWUp5twbiQdZlywo3+u3fNwyGrIpRdqGyEfQWUrxwS8Iz6FI+lYuvdjBqh kpBUaWeaqMrwDvJ6kvcOGSnSS8L2uOBcxFpD0HrlGFFe4sOvPqZRmph+VS/2
Ngw76hGA30sJD/VFrft86rzDlCi3+hOIIm0UXQNcHwCOivoNq3ZKbb5A62Vd AtsJOjEpap7ltHMwJqgUlGCuEqn+hTRRFDfz4w62mRzOnhSb491s3Mkhu1qH
GWPCsPsGwtkOqhW7BmxiNZ70JB7GlhG2RiZehNHDSD9pBlHHbW8IVLS6hKxO UdOKFUPfZI2asfJa1WgjxXUkoSvx0/I8VOcCBqSmhIVmCwmpNQGl2ikNAqWF
rbSK6QK6fxCkTzRakL9Yq+UldU3yDGBKitb5zRwbvVFesA7JUuhakw4zqKsZ vIzsa6QFIbRz20bRNZ85yYXnArPyTRKjj9M4KnWWIb4F1+Q1BSM9RC9Bt65P
8bEVSp/BdGcxSqxenpEPCLvVrYp3BWPmubrBht1Y4J1RyXGYWmcIIAR6qv18 U+rFBQHlK7XVxSKJk+nM6TYC8MelW42cothc4mzrRRmonP5eVH4nm6/LljEx
WVZh6e24rAnbSkwA3egnZPpXAjAT7Zk9ttEVCVIvwo352Jgu0irILzirsjmJ 7A8fkOhwNN8oamwS4yH8ThowmA4gFyaOaqlVvAL3k6mp9RV8Y3zN68hsi7Qp
LKpZTJHrmwrGSea0sklYMBBMI1vbL1ZAiCd+fB3eSDIAO7r8JGLX/Q/bbu+w hi4JvbVeY7Ylb63hBX2Fu3k023gY69z0w7CrF6e+ccnjdQvDISibxtlADkyy
aPM7eBD+o2IEu7qpQkz20dqZWbxs7H5jXHee0kNhPMwTJZ3nKDvB2g50adam 08UtNucogtBAzUtK1GFpz5wKFmWSKUvLs0Ix03EktaLGcDJEzJ1DbeEZu9YO
RW1AvBFFZZJiCEFscTZy21kUco2vMyWvr18VTecLETj5j7JxKQhecP9QTExj 2N4mSjTbX+3KTORUkDvQnOIUyQtDmNqWvK0aX66+kpIUa42jN0KApJh6sRBU
whuLsYTs0asJ99UiaVRr5yoq415RZ+G73sGNdsU/zVYLVG0E+gGsT5YX1OVr J7b/Tz2qYzDXjekbmBpG1G464nrHrWNrv1WpUlW6bEqGuHu23YXnIkPTNIaL
oWgdhJYoQLAvga29rWWU4xB1c3Exwxdrm/iE+GGKWvpea9E7A9uetJGDS6iw mYN0CoGagsB4fZfVoeAr3G+Mkmhq7y5ngyvc17YIIuypwZ6oBfKNaA0BfynV
bf0uVlsDe9eM4vLJjFbbYlwExZJ4fRQthhttF6W9zZ2vOTZBPJoTboinLCWg TCZR50BawDCdAaR8aQpz10owrRrad/At7f+LxtJqau9BCQ8dfJV6nnSkbb6H
8CIQ2uIQJGJNRlVCqEIv29Ijl4pqy/poyb5O0siMqTWKyYC4xMniCWybcF3L 91X1JPg/T0vF5rlpsobUxV9U+MWFQX5uI1z1j6mWTQuogp84wjunjpw6sVum
s94PruTRBsAIWeq2OWBrnMZTQC88a+614O8Vt1dUQ2pSzikekvpMyGBgJA1K JM2sybc8LeMimjkcwSQuWO8lfoBNISkh1DQpqhoUMYF3yfYEyijdGPxDK7cw
aq8KTkgiPvDOd9wo2SYVpjFxCVKkSafhOqTcxzXqFkURCyMAieSBS1j3ejLv +r9m5eiZuarnjwjryqUQAXUYvKLBVsHCJBPQFbkHRl9Rt2diH4G7SWEzgWVP
mtQp4jXjBewM4VOz/Bt+O0+BsAX2tCEaUVrESn9s3lbJBgTmCBaCSQAt3KpZ 7+cKG0ZhfeOq9ALDLC7jgLYbMDtjSSOjaby/TcjnUUhRY9S1BgOrnwzdR4J2
DMKTYMX2l+EgUgPu05Bs6VT6AqMXWoJv6Feb6Vw16VdS2jkmAzzaxRFaGfGU n9pDkOMvTmudHpjqpO8T9W+uauAnQUZpNbg+EzGIqLipb+N7uF5clojkILfF
7pJxVQMO5+N1jXORg46OW3v8zes3YdopMtrUyKiOZ32K2BYTlN65FZWwjziT /jxdnk7lCgS8DIGKstBNGiVYMNlSB4iNDdPZ3B63iVVaztrUBgj09Gndwexw
7iSzJKxIyHl6Vkufd126Pb1AAhl4NlLiahRigmIkpENIDVwtso0m3JoNTTaI EivpWUlvOVBUFMd4gxA5bGvsL6i3Qy9Sz7SN69QsEjBFMMDdqSvFmGzXMf1H
wyWkE5hGeAAYIzCuRH6ZFSJ4aMCd7mKnMAupYisPz+HIC75HbXuGFxeg89po /+A2IP3Du7UONbXlRnLEwgmdaqrt45VOMmLu7Xdaf2MPVXi1smT8VY8VhIe+
Bx56EOvEIjrgtZzpF+mZ+L5NVC/Pfs9KaOQ177BzeDWVZPWJS7IuFGlZJu8O 9VoaUNRM1pbdaV1B1f8qYxONw/vMTbU+5GG8arYFNuIXXyj/66+PiRV8+aUP
e91lqWmSJ4YPfc4UKmoc4EEj185Xsj7ad9fkPywLm+66gLL4eSUdm9xNTcAy Mo5vXvzdm6OLH7rUghpvYj07P7q4OL8ArTLcU31+bxQHY/goC7/gb+/hRUP7
rqIhYu6DHtgyqQrZCxJSmBb3GssqiZ48i0PS5K0Tbn1/AP/f2N/c3yIqQPLd Z5ffH13sIZ7vv7k6Pr84ufqB/zo8POFeSjgAjwCvXeIzdXl0gP+lBTVdS/YH
fbaz94yU7QWGmyQRkCkoGuonOvEEEeHRvd31Z39Dn9kfQEEFXWGh52z9P89z UIV+EF+W255I4Be2/1mlkMqTh8xEz3vkhQCkTruMo/pmOhProufVry9AxtJ0
1vKe2bF48qeNRIfTGIkOZMGJSjCJZRtT5D+mEaivX6nX7yTTe8VEPjdXTUIo Si7QdUwojk05zpZhp4lpSoHUa7qowItT0Vke2dC52ZavacdxAoCz7oeoqkEj
aMdAGX3KGXFNDYnTm9dZdawHwOuZwnXNgjtjOpYmiNX/bMj0RMw5Pjg6vnwI j1dpmAsKAJHdXk04omIivjV12+rOrHliuF3yIZ3rAjAp2G3Ps9hKpWrDZTzC
c/7l6Pzs4PT1w6iTh/85Ttc66BvYU3e8HthWOCZ+t8hltijSLeFte+5bq8jN HmTT+lmgkmHakf1+U18ka44ydpdP1tY/UWZ6S9VP07ncbVYiCrldRSgXaBzD
/aC1acxh49p/+fO/Mg69IWluL155rrYFaTxUrWPM3/yEW7zhzcXRwfWxzxyu P7Hpx8md7wDBjtC8zC2XB4OOzKw7sr7c1sRmSbaPWF7CeeRkHI/gbMvqeh42
T88uHjrgv/p0L3/7V3CFJ7tqGgJY7BeWX8FSJ0rdIaG2+uvbauXNUrfDahAb RNvKhU06SthaPGn3feEeVG7bSGM3ZRl2tMADo8OrrQ2RJAClv7+N/akITqvV
Z/ki92jDz2NyyEmXyoLlflhTjd90G/HrzkfjljWcBy4ZTrCKFr987fTM99Tw p7ghAEtjWCaSJE182Qi2uqq9I+iCHeLwrAPqAOTO69lMCNOfxNr0msFqAvw4
jFDnLV2Ao1GntwUBXpIJu2wvj9VLuRngoQa0i/KwkEIuqmKCJGZV08K5gqX5 NdtqZO/rhKLsjLlGd/FgAbbYstlD3ByyMc5oP05rdzOhMeYXtFGzZmI01aCy
31MzrZaNJx1A8V64Dx/qXU1tq8M5d0Obp6NJnqVZVYCySM0K59ZTz9WFzZx0 5asLsG1gUs7YbqsBuSq5mMEqZhk1ouOjliZeFowLWZdpNrPRe/++eThkLway
1vYLz8Mf00NgzbJN6PJ70P+BjmfTTLhxF4vfNdLMYprPxEYnIk3sfjJf3m7O C5UOsQmdcnVBAp7RlihGjO083s/4EqO6zU75x/i5tHrQYZN4GrzDdLVqNbMT
h1yzVSK1ZCxKWIO5cAHBFRiZBLQRkZBzs2K8OR45Zw5qNujsZLW9l5DFb7Sm vdnotQa4LgBodbTsXsNhMaXm66DksmqM6Quw+wbC2Wt5Svb62KpaPOlJNIgs
woVKwDKjkpyS9eJFPswHG2BmHCCu97TDOszMM2DZgAhr8ZT7MOW267Jlv+sZ I2yNTKwII8ChftQMon3bRoKoV3UJWSst0uqhC8j+XpA+0hxF9mLt0ZfUdNfx
r7PB47kfgu9OVX6XSvKoG9+AM21wca2emq5vgp0SMYBMBGIeZdY+kRZ4MAMV bVDJj87Gcz/nwsepDsgw6FpjHeuDyhmxsRXTJFWDFoM2iFXDU/Lv4VUCq+I4
TGmWVeayD0Te2rpqk+EE5szSO+7t7jJi8P0rO6Axl8id4nUx2elzcaAjldVu w/SOTI3xQlbMV0+pS1WQWD8XIARGHHpeVf/BGiu9HRU1YVuKxq8bzWjN1SgA
4GGL69XrsmawgQcmQ5DzyK/ExUCQnoTJuN1mHfVkqfnQS0AYemjnzYZNyLnY zFg7Vo7tlEyC1ElTwGojTGxq9XDLuUqgOYksqllAn+lxCePEc1rZJMgZCOZ2
iVvEBCtgJOt3yDGxJXlObkj6fYTQTpKa8cNT2H6WM4o9uuYEOy6Dxx4NAIAc JHsJkYAQT/zoKhhL3go7Md2imOp6ht56v7fDks1t90j4j4oR7GpcBpiVpnVl
fJlwPSE/asXlnY8cgo36SR1BN1jsu+fFLfCiyaB+rs+IfBt0ou5AU1Yt0qJ1 VVUmsXHLOkoPBWKx7oF0Hmy3u8Ktj2vTojYgfqa8NOlbhCC2n9egag+fp5Xl
pujScHkh8AanXjU8Zzv9reZJkzvVTxnhevGhbTE5J2elK02CozL9Z7Kmadsl eHX1Km/61YjAyTWYjgpB8JyvpsGMSia8kdhGyB6dNmKuWiRXINm58tI4ztRp
5zYH4LD1c4buUNcMyWuxDFIKi8aQ9YI9iSOYKT3/Lov1iQkWrlCsZb5a87va 8N7fH+uq7UOzOx/1mQD1ANYny/Pq4jVXtA5CSxQg2MrOdmaqVUjhEHXrcDHD
FnumJ0UD9EZ8PtDIuc+KhDZO6pqmYKv7rIix3UkNSPDigPqIYkCbPbU6sLY0 F+Oa+IR42NguM1mirUXv9O3NN42aEkKFbetRs9oamLdmlCrv0Wi1LcZFUCyI
koJqcRuaiGGPPvG7eJ/Xg8aRV61tdE3NabAQuTKC58Vx6u12PRjT3VvcNJ/I 14fhYrjRdlHY21qwms8axKM54YZ4ShMCCi8CoS2+XiLWeFjGhCr0svEBODnU
FWOPeBqga1Hkptlc1iQRh0i22EhKuUJYhiD7Rbjz4twdzAxYOzkzfHKO81E1 tqsL1i5NtThKHClsqoKkv5ejszSyvFysqRUO7XmXMmwDYoQtdVsc0DVKoing
ZQWssJfhtDwqIiTNNRrh0os0TDE1cnwjLkTYs5AXoY6Jb9wwUFSQRQHiTLwI Fx429+dzN4v7y8sBX6JIWTqSsE/YYIAkfSxrrwpSSGVZjndP0h1cJv2VRgC1
XrZz4W5ENFfwtdsONjGVjy/wu7kKKVCNMvAW0N7jYjI1cYcpVUSnoVf2KtPY gngFqdOk2XAriszFOGowTDGpwvWFAa+wARS6wIjPlDjOaAFTQyDVzP2GX9ZR
m/NIvXtXeg38kFEvbeJHTR7r957Wem2HJpzJfu/sXhyo0iE8pPYwsgYvwIJi I2wTNtoVjSiX+cjVa7y3gs0ITGnNBZ8AZLhfsxgEKgGMrTDDR6RNmEtJsqUT
Oy5GFXYrCNpsj4/ZFcfXLlAQT6PsB6kCG6lRX70zqUZHSKGUzE4WKIqNlEmr uXgKwwwSY0Vn2kxnqknFUqjFUTfg1FWkqFXnRSlLKdfq4XAudtf4F3nl6My1
/AGLqydWY98W7K2LPVpm9nDoAhpKPT8xLkiKaNJFGmXWwxBdjxIRv+La+VC6 w+WcRoWmKz/jTo2Y6sjWo/h7PkEZnlmBCfuIUul2OYuDkkSdo221lPrqFjhH
0fp9CRs9+veDXEttKB1a7RqOFbZLTc7yh1XLujjGYl5c8ZKiTfwSHy6CBc3c O5BIFZ6N9DkyajFBMRT6IMwG3hbaZoTVmg1lNiikqqcgMA3xADAIZPyH/DKr
8c52ubpiqCkaC+d1F2NeykKE5uQFRGigmHvqZvMgYLA9tBnd+rjxAk4DBPNW RfClPjdHjyq1WegRMwwdLyMvmG6LneEFuxicMDqCgx7EQLGPCnBcTk0N9Uxi
aHuJULaS6KDuihnKIWilyL9JHTm9KUxCYOU+5QDQE6wPP38Hd4Askei9fqUj GyZum6V/ZFU0dDo+2jmcnjpk+okfsi4auT+qyRTF/ugImzBlvybbP/QBE6qo
7cxd+ujdh9U+zX7wnQzC116q2t1pXWzaOHex2rAs6co1LzMf6aYKPdfQKDON c4AJjYxQV9n6aJddkw2xTGx66TwqQ+GVdGx1AnWOTrk6lMi5B/pgy7TKZS9I
DgIJbRry+BIZHPqE1RQs9cRqfBJIQ49yKk8w5DwYEaTNXQj8iNzA6S5zlmao SkGS32rsrUMUVVkexJyl1sP639b3+vD/jb3NvS2iBSTi3ec7z56T4r3AiJPM
JPu9phHrXpCtL+2x2VbQtt0581V4G/uUHC1PtWlmCmOPE4xTARCEPg2owxuM EDILRVv9SP+doCF87dnu+vO/suvsT6CYgo6w0IG2/vQOtJYTjcbgCR8egQDf
mSAYxj2q85llMWhfpAEJFDF+YRoV2KuLZBEcxi4zbC8i/vMmRGp5tn1nStiA GAH/u+i0lrvn2OwjOmBa9H119l6qEVZMPHtz1ST0gmIMxNCjvJ+qyw6xd3iT
QlF7PJZoIVOHTMMToHpcKixzLtWGVAdKYyr/yj2ixts4JX26uR00ZmphdLqO FcZ6SkM9lb2uT+QFUn7FwgSFep+MNo/Ak6P9w6OL+/Dk94fnp/snZ8sRJQue
oFpiVEtbUamxtq540vroNZyCEaIZnBcpYFPvTd49ZW61eqE0itoBk4n/EHLC 1tNah27vHkRZepyLOibxxcwceOUOBkFW3VzS4aSD//2f/ithgVwKpHq9XgeY
w6YwqXeETIavXPGDaKEE1zHG4rnfAm4JsftsC1vrK9Mzxmi/OFNz2Y2ycpgl BwsROmNH2680KiolSCg2Iu6126DVtGPf9mxlzKg6Xq8vSqKQzAmLfFtgiFCK
IPknTRvQNCkku/z4+qXJMMZsFNKBYRkj7pcDs8MfN+jWp9peXDipALCgAtYi uJsSYXpI2qwJswElGzAXCn+ltgl5cQCXidaRt90L6a+/YuXXltBVH7v+Wh1p
5eqp12+PDRXeNzKxAB2zIEgwIF5fJ10fUy9nwRz1KMul7zjnxwW4Rpir1jQO c8mLPaSPXv39S/fvXer9cP7rU3ZLArx5fbh/deSKgKuT09fLCPuTqPrih9/I
ZJIej9GRyJYOljXMxN4EPQDVk6ad5doKSkVzyD4l9PAksRTlIzjo8kjs6Z3l +x/g0A875hqKllirrKV4S11mTfcTYPi2Wnmz1Mu06kUmNrLIGd5w65m6D1Ka
nk+BlmiAGBZ8fHRLqdcQFtRZw6zggQDwIkwyhoTtyN3CMVK0gMWbSyP7WDGI U2+519103mt6Cfn1yiVXLWsw96ocVkErWvzytXtvqR064c+7e7Jj0aoKhlX5
jKAIKIwV3cXS/tvBmSVDcyhUIdm9C5qtibaxJe1QqKs63IsDveasmmA7Zrzq 0nmVQsZO+4sj9VIu8LzvwppFuZVINq/LfIJUZ+2SvAoGyJUBj82eXDae3Bgy
l1UI7I6NF5DfgBI6M63v8fLzqGqUZbHJYqq3aGGk/CLoveuv8iplBRg4sXHo g0/u7myqHVtiM+Ptoxbq82Q4ydIkLXMwFOiGg7mN1XBhdLOmhC293InxRPSl
0G2z5vIvao0ruhmxeIBTgPlheeywBZc2BlnAZpCdaxpKgYoFho4swRacODIl MuYsQyd7Dz1gGHkwbaQaFz27t0uYWUxX2show6iEw+vz5T3qXcA171eg+y3y
wAJcWYRXMxMo83BTdq1414G9kICkhtc3SxrVIYuG7XX69l6gjQHdC2QvdsX1 AtZg7kRFaHlGPwF6CUnXqWbFBINoWLnzUJ9FdzebbH5MPh+jL+dVsAyscqof
9JjBvF3y8QPXvXrUu+CyVUV+XJBrWlSjuJBL30e13hVkMsiYggDOCrO3xxaL LNgmWuTFvveijJQzAuqN8LGEPHXkLRuPtfSt2yDhTlyyY7cpOi+zwfS53ZPr
FFzk7nw3Y1BTEY3R0H7J3SqqvvfbxdWJ3hKCcaXh/a6SZo2G/bwo9VRdnp5f T1fuzRYUUjHOocqqxbW1rt6o2kLZKREByDpEfmKuHm4cSQs+mEyelwMWX+ZO
v/3+BgUpVsXijbmvzO2kdJqgbOwH+5LgTM6n4FvNkUzsRQSDsa8SHyK21Yt1 XkTe2spq0+EU5tCSG74drkp3w/cv7YDGVm541HZ6XMdcUcpq13Owpbrap8qI
Oeb2/CjG0cHILoz1TRg7HmmKP+6rV99cvOpt9NdJvSoxRcM7fnzgxzN0uMCJ w/6dmP1C7kO3iQBGAvUkiEfte9oat1I3GlneUv5XYCN4eNNQChoVxj1H1PE7
X/WxdSQ1Af3llD/rJ/zBr8uqh8FQwOp+pL/+EWZAeccJCxZwjYGv9Ay2jqll Ne7Kyni8p62lm/fCrRsG9q6FOblgbSoKmtympWrVlq46l65qL8vp7+tcNAT8
G4ONLT4B7hX0qSdgjL36CQBTv5jDAOnb78M4A2CgUv43hPDZ6fXfH7i+3ecp GAs3kaMkczOImdhoKFK7ppfgUeCQngNx7DnJ1ancItdbGczRZ4Z17QXpn1P5
0csU4yD4hpvvmH7npq18XQUHUwPJbGN7w7veh/LhuBMy2V6H3HRfMruAj8el fYgoF8c145+nsPeDzCgCX5VU7lQZihY7AQnIzZ2KRissiBqXOygqeGhj31IP
uTds8aiiITqmZhOVF+vRbHyJcbliDWlvSRtsANmbatp3z6/Yy+dr9wm7e+gb 1fUWR7B4cQt8yTKom8s4JN8eIXUDp1G4NbGamkimzkVInFnaQvatJrJTTOGT
G2ymD+EOKSRonH2AMKj+FM4FGEtfkYZxjk0+xVluABKInk93K7haQuOHzPEW 0OXTcaWBKDbIwdrOxATMV7godbUWfLCXEJhGYw3IG6Xi/ltQUb/SJlJTU6Bs
7TwfgR7rBy1AJcbMEjKU770aT7poRHJlM8kvxCjE1CZJIQxs0yjKKmN3DELp NbYVsvZWFwMStJjqI4r7yOypdaFNS1HLqXNCQ0EzEsJlf1XQ2+nCazlM/d6z
DsFkgYP35wH8Mmx2rEst2UjmwU0HLrp52zRY4Yj11DRqajXY5lwcegiFEE25 mvbXYKJy7SbPi+PUrylyYEwFy+xsxAsHiWIxCI8nAmoohTCb9/WYSokAKRd7
uGNSLbezdjsgYpfcmu5y5myRl9sK5VeVvEE++jumckqiqbVV966opPepiz0h aauqdYFAMZWaI7y80xzNDFgbefNceo6yYTllzTS3N3W3XIqiKTx8HalpfoFy
IO5CnILyQMt48IyaljmKlo3f4oytorBWFc+5VA2bfYGRhLJE8sdsIpi78MhF zwhN0XhY0xHNBjN7+WIFUcMWpUmk4kRzCjpyc7+3TVpecD1DE1f5AD33Hhwh
JfiLlqEU4P0eLrVglmVjAnPdNyLoK2nVoFlG8YhvN+NGimTpxNKYzbQnmzvR BuopAcwFzJson9hrkqfUwCIJnEYFMk11n0LKLS5q9x14S+878LjsPZjmwMty
a25RRXhxVnARcGwTwRnVLCH2laSyQGlMCkM+DFC5FGsRg6ArTKQVIDzCfKLb rnwfShOAauHVNWWBifJzOCi9lYiCXK4WUBdAWZMTd0RdJsqHJXaf8dp8kI+9
3gqcgjEsDRxckTEaCCHWH1L3ARmNmioz28kwT92/L4Ico3gbvB00TjH3ioQ+ am5Su4RSXO+yP6QT7CxPtxCcSjcRhBxqDunxAuW5kSNuE/uB6dVrSbA9H95S
Dq8jzxHGugF1qrWmF+qgfXJ6mHBZ18MWc+A2YdrcaszFm9Z/gURHSWF56hrj hAnVM3tYdLU7VdscG588BfrpbtIi9TFyzem45HDlID8V1ztXOjTuOdzzLrQU
whN4+XlOiDbRjQtVbZIkYUKjTgAtAKxJug/95GInfQPUdD0/fo0yWjf4LnC2 vdMh1m42XWHz3VRp3K1af+uKU/hhAvn4ce7dc/PdrbkdCTMT4JBuIszRWojV
1y908i8Ulmvp0G2OCXsumfthHw3VWPv4YFxOFEkS45+1dHKBelLJeEhNWULU nMiDWA1kcxuYa/mWQgMv3TKj20gP+ivMzs1bgW0IRZl7oo1Xt/VSPk2rFOhN
isjhbsnqly4JrbeR9HxomI0TKIYZB3eXr97cxLT00naw28jGSNh3TU07uTiE UtHUm9zkwpbVUw6GPsIMc3PZcAfIGYnosVaDLuwJbA4EUtjYoFohErR9hD3v
7bhsFgL2qFYwwEsJZIRDhEiwzYCkuRnw+ZcgcU555HZhDwkvLGaPEUCAOuvV exmEUNOVchRVmeKebd5CUBQg92oFSEgsZeA4TA3lpiNPwvyGJj5HLoeRETUF
0SacG7vRVrPpnPp2t2477ga85YiXTRfposPXRcGxiBnL9Ny+6PtGJm5BLkyc OzW2qq8ElTGuksg3GHIOjAjS5hJJ/grf6EPKADZOGM7l5hhSAZxG/+vrbsS5
ma7XskFjlw+9dAlfBeTwJezmdyn5mLrqRnWX+dI+xi9rtSphExpoMZvbwZgD J/eLsd2k7X1xzF7hfWw3dbg876xZEYGtqjDAC2AQsjTADsYYO0RAjHwqb5yl
svPIC2+Oci1ogUKWMTTmmO5NKh5wpZP4hvyHrZvEfTPOHiJ7HWRTNt+scd30 EWhhpAkJHDGOZxrM2HugZRGc1FGk2CVK4khNmNSSzHuVWWUDa7n7dTJyKXjO
UC6WqVXqUQO/x7VHv2niO/h52/rAswJdj8KaCdjsRchdhV4e9v4FfhwTwWFc BCLz8AxiRVWNb+GUUMkv1IZUPyMFAamPuTIJhr6OErIxmtuiW+GEzdXJYRmK
ccoiBxVdLmgtTBoGfQqtm3fMHdYu9TQcOScz7tyU5NWzYgp1qW9iQMr5w4ko e9633P3EXO5SCQGXmOBML14e7G5sbzhXG1KWB18qQazzgO8aknwFoNWoMFen
Ar1aFoTzMyxu9XPq7nVZnvtDee0Bd+KRStdFy8TKUF5n19xXLs8+6W5U72Kw Lh5VTtrkxOVV+t1iimDeKbJhxcpFZ0kbzM3sTX7Uc24dLbUMKOcWcQkRt4jz
TmBGYs+Bu5u224jdCGU+ae2uyfMZtRbCq+a8RbtizIwj0qZqlx7cV0umcI8d dWcn24K+5qPNxiabIXHcJTk/jQIPOIalpHml1kfS86Ahb7EdqzgBDFA8oVq6
0tUX+woP4kgS5Irq5oZOYjUApieugX07CyHPD98brPvhbXdJXiDnKjVugyvc UqqqfyLbot5PBiWej4Zf5ZRBGs4xbEpC79apUKOb1iQdLJUUGnSzTG0GAALE
dXBPwY9H0ERSTLzE6FQq9QhmrevbFLVhX6n1A/Wg6WPAA2v33qCjZtlHLuG4 tvChjBlWtBBkNwgzCym8TxiAmeJlDloC7eZrmxXUpEBLmkBMTb+c1oUhHGGm
Vigws/O2O68uvWYTRcR79ZrJV73n9sDu57060yEpqg/8vFeHXC2I55wDdGCo 4A2SA81Vb+li+rnU8pZckUQ4hp6C0txPUrj1CtUeKGug4J0xAqDFyF6zTNcu
98oepnkK5hEAK/vbsg8W/Sx6qP0ZzbM+8BFLFmm6kdlV1xtE2fg4PfSenbLv i3Hu6qb36YIeQkPchej68oUWK3BYVEu8IJ9yO00xjwtq1bycIdAQwwtYHqaj
F+LeYkjCzD/tqy9Ai8Ueuj06jt4tokAZl4l+3vnWBTl8nOh8QMz3b3dcycvn S1aETW+o7n+sHC78QYvteXixWRVAm6XpiMBcV3AEgSVlEEzTMBry/a7c3Y7Y
q+oVXhl5za2hD+x9jzLIRyH0wp8gUEvRnE3Rpy/KXR9pqeFjd7SEMD6BNbbo ViT9sUyXqHll1xjfEsKLM95yjx25CM6wxs84CTCRBUqnSBjyfoA2nCIvfzjZ
JaAZ9pVZJLAKF8jYX4IG/Ro7ejoWBMG5ad5AbpunuHlIXn/xBTzNXQ2NU9qV ozsXqH9Wh9Pe8Y1O1WxPfB6kXZhrE+pXLyj36gVW5mk7RME4MBoyBK662+Tl
3dbq7100FkPs6bwRolWs+vNQRr/0c39MDayv1Hu9wezHYl4RKy7FCZOhX6H2 EoZFt8hJYzj4CvOtbhuoJ4fU/FNkljmUqk4Tg5oB1fVwyCR8wlkrUD1mAeSJ
FHVrtPy6q/zOazUtmTrSzPI4HWHHna6/Yg3qUEbVe9IkHkfJ+PJFq8pLldCQ +fSJP3JWqlyXgakJOQuAFPNg3WvKyOYElbOS/1GCWR3kJ8HhdehYFKwzUWdn
blDjq2hoSD8rsxjpNMzjrOg2jpWTvswVP5KyZ2/bYJ7KPZNtPIoLPY1zYGb9 qZfluwJ7pEgaZ2zXoVhDdDYhkzkthyeAfI1OiIyP0k2ypGokDd+I0VFAxE7p
1t79yBMd3uH9QVzhYy8O4GJfqbmLJW2LvOmJHtu6Kxc5yCkcA29JKETMXa/d ETdgRZLdZ5JthchbeciYXoQ1D7eBm7xY2XoemsuOi6TGnWzW9z1+jPp1orYO
VtNNzu5AThIuah2+8P3XWdpb1PXLu8EeQygage4hGZkeZHp6FdYNH4S3eRtC /83ha5bouFFKBaqSRe/Xe6k610UNo8aTj07UKXbqk225wPQ0ac9hy92LuyU1
06jhUvan6UPiXROOikVhbtpxwCXnGGrS6BXDKLGXT9WApr0lCAN8I+uXTPlC SgrsW28j+3OhYTZOoBikHDpYvnpzD6iFw+/enByQlEv/BKznCzTxOHJxS+qs
VekULKWTvCdpRAYMjFM9gE78K1C5qUJuvjTpSojIq/zxqKRkSuO0YXZoVHC5 7WDJCegcB0hnAWCQavlanIQjRjpEihir1CWFxoDQvYaT81bDaif2oC6PDkQT
RpsOmLMUxMwDZZlTsfj5VlFt/UMiU+M5d4fAZU7FwgZZZA8Ye1Hf0d0T/iwH ByhQb7k66gRzc1edrZjRGfW6l5ed5GSPtx3ysjGeRdZzFWehfp+s0OHzRn5f
S9qbE7a0aiEMACiXUZoi1hR354Uwj7IBKZkRxl1skBn96jWmZXKsraFv1sw1 TiYhzkgXu9pwhHEs3TP1Fx5ZzYTZ/C7lNVKr2fCR9y6+rAUigyYUBtpeS8sC
2XUI4XldUL+wk2zWe4VXQAB3gyOnanou1kMA48y2uZi4DabkI0pJI8LrmrIZ iBVxx2c8zLRgBKo3cnEJxwrGiXgRlI6B7w/iesEOdQ11vfn27FDzsfCwSS31
GJ1vvFZt8Lgd1eT5mzTfCXxBN04AVRjvVyGXz/FIuLRjSnE0/VAwD6vR/ORD zXMJkFxvbwOS1ODtYRVeqmLqkUqwyvU4gjOb3x8IlFnoWibbWu+hpinLo7CU
rdmbVNBmniiQZhuOi4FVJXUAJsPSzzJzneZ80qDeRFio0m/mVQPcI+msTamQ SupxexMpMVu0OIxM8Oqcrz3u0vrqptaOZwcZZ2k5M1Giu7svJF3AeodyQ4SP
RI1esZvvpBJ3s2eFc04v+S8oPZ7gHXj9C1sOJuxuRmk5KSWZSn7+oxmcxm8j WnnVFPiUurXg/b/ukm0JVMo+cO9nsz++KvhnhBX//AzHQJUaoHQs/fkZBnDP
ixZoUOqoxB85mZSoi1rBh6Za8M4mkUre5KetACWGkK7XzaYrjBtjso3rZutl RFV/qvoni39ogCUbgwEwG8KsxqyauB3W+D9/jv1rFqd6wLgf9tRnILE5vlH/
X9J1EuMqcq81zHGMzUDJe81miLZ/80pDj7Rsff4kiyUv0F2AY0SzRM73Nvao HPT0ItZfLTpf2L8p3Lz87sXB4hs789qVnfnqIxF2Ad6G5k4RJzUykZodOkZe
4inXfI8BMzEjwTCkg/ofIVAQHHOaEuE25V9p+4GfefVYKM+kKzC7Rsu42wjl yMGLxy1kAXLSAPVrj3O599j5NmEhiyrquRHVMoZnds52z9ClF7XfEXadcakJ
daUxQZjMC74hkLiv+E6DWYiZ2x0OdQEOk0lBd11XfoHNaXbd0L3wQmUYqUcD nB/1tXUwR52yOrocufBLB1w8hIeUAYhgqDZeOkjYQrpHYmH7S+1nNM96XxZm
kGUidsWr7MbfgItqszswyW7eLvzwkwPdpvHm949EGPfePln/DnrqQCpVzX/P Ok/Zldb7/9jIAH0JyOro6iUuvYG3iyHnYG9+M/QJ/P41Hrcg7nc2W9k9fkTc
skmI0Z8XWTUKozDOvwRRTmGPay6yolfUcn3SxMLk4TO8akmuZbAx9pSdT3da +s3fK1nx1ap6hdeJX3EL4317F/h37Bn6KNRd+NPC5+p+cIvGH7usp+GyLfyG
HrpkCGBjkTQKXVBB2upStyTyvCwx5mujUM5KiK578qcDemib/JpVZSRtEowh A2TQVaembfxxEcu7h7/dgyRm//djRrWIj8YKM4ZPTF+Q4tEwRjw5N2Xh5Dp7
yKm7eD24tz0Kl1hR+zK+6at1+fowCSmnxisX1sjsQx+PhDzDZNp4ixUDdwsX jKuNxPVnn8G3KUPT9Io+tPV8tbreK+vaxiBFMm/4uxXr/DSS0SndcKqprXOV
X246tRfwkQPr6OhyDS/+cafzTYa5wi/hOCYwafmlqWXpVTN1dHp1+Obqat9C eaedlH0sZhXJhkLcuim6c2rfom5+VoB0ldutq6YdU2OLWRYlQ2zc0XUXrEEX
YcweTJOUzcvLAPeogaKNGbb2QwZK6J3dhQmhyzXflLbv1UOY4uzGSMRdGun3 SqkqSJqk4ygpX/5tVXipOxjQnbx8ZRMN6eb65EOdgPme5t0GYnAY3VyFJXkg
se0IgB/VOkFJbOCJ2L37Sdh9meGt7EcgfpL4vo3RgjlVStFkvHRod2vD4Yg3 9uoJZs7cUBerLnMOimIBmXHM8Nvcnssq+RMd3OA9W1wzYDvncxGhlPJEEgnH
0LcJYNb05/+bq//471X68//GowBkOTq9lMwhh0T0/M//LQfu+u08Hd3qL5vT RsCg0Y9sJYd1fWGaQkopk3I3mpi5ToOmZmCNHbKcjZbXmkLh+2dp4i9qFFVp
nnF/CtcpGkB0MCy4Gwai66ncBuadifNgwBFfXR+tb/q1WbD09cHmduP8LOdX QhRI1wh0p2aUzA0yOZ3KTScZq+5ms156jdotpRSZ9gZVsSM1ZMrNhVQVbMkh
FMU19TLjZs9pVIEpUsELupJh3lBTEuxtDSdJ3mdqDCYF+DaxbqxsJYhtNGHu iVo0eiKjvBahbgDTXqYF2BwNrWM4Aasxza6lhSyiN/XNwy1J5yrgNxwqAyrZ
s+CBTqeoWmo7GXuX5cuT+WxCF/yChE1vRR8OMWsp4qbmWDWE9rR3GhchKBHf r7Qgn2u1M/OhCf8iHq/ax5SiYxxm7A41+vdJUoWjOOIjoIl1wBolf79VrFd/
YcukvMCDYEpgo3TJCdtwHd9qCwaJtPOKqDSVqZD12vriLyY55Se3rpAn0URX SFRq8raqQ+CyCauY1vrskDFgbER9Q5cvuLPsL3SUSmVpK+fWbJWyQ6SRXi1k
qCHHTnUF55ck8wepdwFHpYS2Fa/0z8jkH428+HFVmJW7BodER5h4w3hc1ruB WXkfLFTIaJQok3HYG2TGcjV4odqKydyzBr5ZM9d6usDI+cReU9+h43QGvHUa
ji4rGGUd4nOEOfZuX9PJo4G4tGZYKWivxYNbabAfKV1uF57J9x7/AEmb2URg FcDd4NCpTJfrfxDCOLVtUiT+gik5hxLSrfBes3QGA75xunvB12FUn0Y1GaUm
KxJUApKyQq7uZj3PYxAipdaJXgC8qszw1ZGNmTB3qvWzo0QHUTEpwkHdltCn eWwCH9CdC0AWxvWYy5XGPBIujXop2D4LGNluNFW4q/UHk8q81JEEUsVfsbFM
0hIeBiGw846HLmcHv60/6lYsHcu8a5a8BinDuRpx8j2e47OtHSNIXsbvMNOO m4xTk7Xixu2r5mQucVDTE8yJ7rXS9cIolKbLlF5C9OhUztTSCcTL79jgnCdF
i7NycovWGkN6+z/SQxApWaLn7e1/Q652cYu40/+swKktlVCwHR7HggsJjS8D XguKSBHAPafpXcu1hG2SKMiZUOaO5H0+mBZjPDayagEH5eNIBIszdIi+qAdZ
aQdt2s5TOf3OR3F6w0sp9l641HkvNdy1Ekcq8/ks3boY8D4b11eNa432jLvW YOqPbmxmjiSj/LYVoMwQ4q3SlbmvEzBhLM11HIf2nqJG+wiKbTFq4BxH2EKS
Sj5RcMzn/t3tjkrxQmeJKmLbx6cCYPuTRN036GzibR3kZUg2NQomn9fAyZUZ Ygds32j7N680cIjLVv5O0khSLao7YYxwbqTc4wUVu882nlGifaa55z0zNSPQ
anbEdEyFMpyWoOnuxsaepyLFYp3k4xF+M8QKQ7o7Dt9jTVXq7z19tcFPUAXJ MMaGiiahk+cdcQSYMJ1C29o+cIPadB6c4ZK3XCeqummb2Td6ArqNIvWu1D8H
mZsY7OBOytQsDJOvepx3Hg6HuOAa0yBt3b+rcyFzq3HBUHJZsOj53jXAYeeA 8TznazaJG4sL1ZsFmBrX4dgjYDSZKqhOxaWb2H2SXu3VZXYHtg0j+TQAWTy1
S/lZQaLc2dzaXfXetj1lmLgNGBb0m/NpFKMlKBdq992SN5vSd5vnICizj/Wx GhTj1+d29qGRFWjQxOm4ul6WwtiwPs8KcIQWaoUb65s7Pby6wvzh0GZ1TyP2
eaOMvaFYXWpyKi3GTEpT9tAOuJC9lkbex4oAk+VN1P4ldqHguFFTnMkrx1If 5GIhI1coZGVCphX6E20rfydK0FML73x2WvKFWTAq/PuyYrAGwzPluwhezlWk
i35EZtLkjuDkMTyB5xTQibK+vEDeG++SzH31nf5STEScaOFNoB74ros7xNVL 2le55WEwNwM5UUCM7LjD9Dy5JtdcNUBQkgQrNob5wmjrCuaHfNvDQ6N/A4oI
X4m6INirg6PXXNAjtz1+JVtAaHAh6y8m2f0vpLa90OVTCWzrowhM2FlRYWpA j7Xn8aXj9+3pHaWRTvNf/5IDsR30+K6ZnrqK4nQYdKVTIaEze/E7XfU9injA
UhmfkWNvwDdnpGHjVqlPonTltCLWM7eOPHSwY6Pm+WzrGTIwup8yisObFEsn EBAMY3T5Uas805vXP8QFdtXD4PTX17tqR/1zCbraRn9jm4b5clIU1AYMu8Rh
RghHU8NptFLSubPL45614ms1Yb2vud5s4bf+rFFWDRMf0WHtLw4v1AZ1C2pw tfU1yFDcLdZUrAEJrE2Kabx23+h015yZ4etaqc/bg/2D4/0Xr4583gzt/jdu
/7SmYojc8m6qZKCIOQXcEScQzPQrNTwNktyK156RUlgDEpdIcSqrZW7jw52P n161IFiy/0XnRC/KAvv9LrYmv9SzQpPbwALi4yBRzUPvNpEC5vl6waXnl7YQ
ai/RCawdKt3iJEDZrgxyIn1R0U/g69QIVe43IPevcpU2fHB69HzgHJvklHEr grlFRtqb5wWr8NEUGX3CcZeX5IZV63xZQJrytb7Gw3j1+yt0+M7KoseNG9lr
WHJXpW8QMw/yYqns77k8pu9M7i1Iluk0zLvmZLoigTXXwY4SHaaYvP9EUtj8 i9QyDbJrriCTwbuYJxoVjaRDkHFRyLkUuxuVckkaODZp6OEtmt7UUM0Ntdhy
JFlTTDQo7XTFIpHtEyfb+KTJjovb7MvCTOU+PwvzUVYs/Ca+zZIwdl89cX2D ZsI07agQLdf6bvJvkMQLTte3V2Zi8Zon12LLxQQ0yBeGawDoMK4pd8RVbqqC
j+QLfClmPMWrb7CbCuaM5Rl6SgGrC8vw4+L3VQoax/Ov8XdQCUelfFWl2l6l bsiLYklPc5gLF8lEJjWKVGDyOyJk8A0W5PkwihAO3Bzq6vQV+zO++3a1Z+/q
SkgMjyzAPnzURp6wlg+f81PE6slssLaLitpBNSLztbtvC1MqGoN0O3otWtAw 4TV4RgWl6niuwuNVYtjfrmPPMzhye3vbg0P1QSUs0owwRMTHGjxGSxtX35uG
p7xNtBxz9PG4ijGrYPZALcVYUM3BQGL5AVenSOsFTT47QZ3TsH3Y8CMEDS8D H/tG8b742FcQLT3PG6wi9Ol4zRYQntQIzb3pJserbrp83w0WJG30Nll4bfU2
+pPPZ9gbHPSQOfbiGLh2q6ZbDa4JVAs/5SelSh/jbeKWS0BREdKf2SrdUDsy e5ty53iFR1XxTg/HN/X57AsWhKQ5GpfpUH/VYJCMOp5kxHZ++eUXRU9Wl8WV
KZbkBajNLf6LNWz96pXtkoRsF3wiWt5lcWTqSGFqiaQh+NRf/vw/6gF/d5vX 7ciVDMIJzTwUzvKqFcnmenzvFNeCdc279EKy6JIflGxmf+zU7qBTOMs635iL
X/78PxHWXArdbCvIbQNjr5ERampMA6rewcmw4TLz1VfDT4zVpUYTPboFRbV4 pIx0MKn01tg26U6EbjH6Pkh0cINOiuHbTlpJTTeBabpqpMGqH2Vac7TTkZb7
Ku8YPPsochEDsakquW8wVaiHSlHTAVOXUF6frO8pEr6xvrnzw9u3K5OypBsw cZ5K8zsvoDZwRqUBQN04/Zal3gvw8pWszYEHGZr3Ymk2G67dRtcRMLTrsjeb
8IIUVPFvdd7HtWNPqDXQPNYm5TRZA10WX1jtiv4lh8o6hLQn4GY+Vm3UkazD zL6Jwq+qEcjdA9qbN1yl/NgW9giWPMiXvjcw9phJ1DCpyw1t9LxSfOtMaef5
JHu36xP2a2Rbw3Iqe2aHxxPh+nGOXIHFoU5vgeEdjMdxwkr0U6f7NM8aK7jU QqYEK/JoRmaUuAg5KBBpu33nHdPCV3hQIE3H+D0q2cv1NBqmMRl4En6jb6Bv
54eZrPoCwLq3s7vn1uRbyt4JcrMQE+6mO/ssRgik6RYoybEnfd1HiatlZ3BB Au1x5lh4KxJ1r3BvNJKqXBnUxUdhcEZzXKW4ohqnKbbwYVWPeSS1YuVQKL+C
F1zD/zOHTD32dgXkhWqXy+6bteI70pxCkv+fCr+Ps1dxd97twUgNhhQ8bo3L lOwxs0OcQ9zEm7IRUNiGGL3iiHG3xgJhOHNrB7xIiIwEIAQHwTyO/0sMuByP
RQCP43dkDfwTOeMwTDnKkmqaUp8K6XF8nAMAQrX1bHtrlR5tkQzaOntbe1sc 8fZHyuvh9K8FAqpd0tw5Qd2RrI5XoFaWFA5CJd0tAkkQrsq7LOaAst+WyEi/
WVvsS1cuy44GwekRq5FCCp2MfQnwRMB8tB3ra5ikRycac9AJSugYp5JbbhBB vAcHc/zeGL+2huHFjbXPIjPJj7FM8rW35N4sk3fi3JelpFK2Ut0Tqh40dzfF
VbhPXcjH6fvWKUc5ssAWiYmaxh6WABj36ZQ+SssYfKTKxcnbNZcw677UUsvk c4+tcAQ21Vxgm3mUaWY2qyjnaqLjGVqKI+rdhdmVaPueWb0VDluxQ9famljc
lFd4J7ptYORnoWgvQUl2x/FiLyL3Affq/n7qTj5GnwvEJmgU4sm1KnjcC+mT Smu7NVdjV1FTbtTB2MO47nFi18CAWcQ1PMA8OaqMpBs78Ww+U/tD3HysQ74Q
PaOuJRbtnCvMqJJ3lRQxyXH3bnqG8W41mGU2KMNyE1TXaZgkxETKZnbtQ9QB 3fuwB4o3RTx0KD0vltotmIUvpTTApz58+HCKhuSLCBYyu0MbCh4dBBl6WtUL
421vb+J7gov7vB10qUq7JpN2ZSMt2LAG1HF46vrFkatxB2FwfmFanBg9HxST jE0liXl8mk4CTIR7kZbDIAyizHxwqAdgl6Sxnpsn38VBGE1//Z+Z+rf/Uia/
pp7h9cygcJHVHd1zzYYZ3iu+XK1X0qV1WUVawxEZ1iPs4izFKwBO7Fii6UoD /vfCfHCRwojqEAATR7fm4VF8O4fZevD8hlKv5XF+DcZb9Mdr8+DbFLP/X8LM
0VGDpyLG+schxhVZqvNaDyW84SDmGFthO384hdMDQr2QQwLAoig0Oixhbo8x EzB67ZhXExg0B34PJnwR2dVG12kcROrbX/9S5GBQ2tmu0jDEW5ey6sF0Olev
rCUSZePdQhvYJUvOz/V4cddM2oZO1Pv/UF6ilkURKLG+ptxA9afC7mOMEMLH A9CBzaN/hkXSUu3mXwA8LoeTWzjEP5tn50Cx6rIA8tJ21iAbpqK5mme//ucM
bxAIB1eHp6eAJqWhM28THVdF24jZdtQKlu55PfJXTbc6dMnRSkEarMiapfiU TNvv5gloj3bOaKq+j4ZRkl/zijmT8gOuAtkU8it4btholKGYCMkdgt/k3AlK
VjxKi7ernhXEcZu7OEvCRvyVzNjz18K07McA/3E4smBfVvfJdnUDeP5CPoXP 4H7bVD5RbCH3Yh/O+rN3e+q3abHNgR6cavepptp9cKqdp5pq58Gptp9qqu0H
B9atYzoyKulR8MD4QfCFOhihszLR0Q3z05/2q5TLDXQkraqXZjNg7yjp/5be p9p6qqm2Hpxq86mm2nxwqo2nmmrjwan6TzVV/6Gp+s+faKr+8weneioS7j9I
oo2K2dXAxGdddRjmmGipXiAjStNuOxrf9WIB3XY0sluPdHbVcXI/h/H68AnI wv2nIuH+gyTcfyoS7j9Iwv2nIuH+gyTcfyoS7j9Iwv2nIuH+gyTcfyoS7j9I
pqJLVjQYE7+/7TZjOV11PYGXC/UyA15Xxl1jP6tvfv73shgBDcAjGRzSCVga wv31p5pq/cGpnopb9C23iDGhMcvp82GSP2b8hS+uLRrwE7Bs2TDe2zH+hrek
+Ot0OqcQHKzkn2FSmhoW/QJ2cDWa3AMW/rHrx266bKur6zjJRmG3FhyF8eKp uSOmw14WpYWf5jQYpTH8+GOiix9/5O/TtWrkY3gbRCn8gSEnZ4QxWFPloAdq
+i4exWlxG7M3ww/vmYIHag4hnQ/Y/TalI+gHweOJEfvqacbBYwM9OtXu55pq ylqQZP5gOhj5s+gmLdaqr3v/B1QY//uE1QAA
99Gpdj7XVDuPTrX9uabafnSqrc811dajU21+rqk2H51q43NNtfHoVIPPNdXg
sanA/v88Uw2ePTrV5yLhwaMkPPhcJDx4lIQHn4uEB4+S8OBzkfDgURIefC4S
HjxKwoPPRcKDR0l48LlIePAoCYP2/JmmWn90qs/FLQaWWzR1xCeMv/DFtUUD
/hVYtmyYwOuw442Yjfp5nJW9rKDBqHjnd79Ldfm73/Hz+EIfxw/8DjJuhBvQ
dqthH9SUtTDNe8PpcNybxXdZueYeD/4/qHEquyTRAAA=
--> -->
</rfc> </rfc>
 End of changes. 130 change blocks. 
2304 lines changed or deleted 1019 lines changed or added

This html diff was produced by rfcdiff 1.48.