<?xml version='1.0' encoding='utf-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version1.7.291.7.30 (Ruby3.4.4)2.5.9) --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-core-dns-over-coap-20" category="std" consensus="true" submissionType="IETF" xml:lang="en" number="9953" tocInclude="true" sortRefs="true" symRefs="true" version="3"> <!-- xml2rfc v2v3 conversion3.30.13.32.0 --><?v3xml2rfc silence="Found SVG with width or height specified"?><link href="https://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap-20" rel="prev"/> <front> <title abbrev="DoC">DNS over CoAP (DoC)</title> <seriesInfoname="Internet-Draft" value="draft-ietf-core-dns-over-coap-20"/>name="RFC" value="9953"/> <author initials="M. S." surname="Lenders" fullname="Martine Sophie Lenders"> <organization abbrev="TU Dresden">TUD Dresden University of Technology</organization> <address> <postal> <street>Helmholtzstr. 10</street> <city>Dresden</city> <code>D-01069</code> <country>Germany</country> </postal> <email>martine.lenders@tu-dresden.de</email> </address> </author> <author initials="C." surname="Amsüss" fullname="Christian Amsüss"> <organization/> <address> <email>christian@amsuess.com</email> </address> </author> <author initials="C." surname="Gündoğan" fullname="Cenk Gündoğan"> <organization>NeuralAgent GmbH</organization> <address> <postal> <street>Mies-van-der-Rohe-Straße 6</street> <city>Munich</city> <code>D-80807</code> <country>Germany</country> </postal> <email>cenk.gundogan@neuralagent.ai</email> </address> </author> <author initials="T. C." surname="Schmidt" fullname="Thomas C. Schmidt"> <organization>HAW Hamburg</organization> <address> <postal> <street>Berliner Tor 7</street> <city>Hamburg</city> <code>D-20099</code> <country>Germany</country> </postal> <email>t.schmidt@haw-hamburg.de</email> </address> </author> <author initials="M." surname="Wählisch" fullname="Matthias Wählisch"> <organization abbrev="TU Dresden & Barkhausen Institut">TUD Dresden University of Technology & Barkhausen Institut</organization> <address> <postal> <street>Helmholtzstr. 10</street> <city>Dresden</city> <code>D-01069</code> <country>Germany</country> </postal> <email>m.waehlisch@tu-dresden.de</email> </address> </author> <dateyear="2025" month="September" day="16"/> <area>Applications</area>year="2026" month="March"/> <area>WIT</area> <workgroup>CoRE</workgroup><keyword>Internet-Draft</keyword><keyword>CoRE</keyword> <keyword>CoAP</keyword> <keyword>DNS</keyword> <abstract> <?line116?>164?> <!--[rfced] FYI: We updated [I-D.ietf-core-coap-dtls-alpn] to [PRE-RFC9952] for now. We will make the final updates in RFCXML (i.e., remove "PRE-"). --> <t>This document defines a protocol for exchanging DNS queries (OPCODE 0) over the Constrained Application Protocol (CoAP). 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).</t> </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/browse/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> <middle> <?line124?>176?> <section anchor="introduction"> <name>Introduction</name> <t>This document defines DNS over CoAP (DoC), a protocol to send DNS <xref target="STD13"/> queries and get DNS responses over the Constrained Application 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 any combination of DTLS 1.2 or newer <xref target="RFC6347"/> <xreftarget="RFC9147"/> as well astarget="RFC9147"/>, TLS 1.3 or newer <xref target="RFC8323"/> <xref target="RFC8446"/>, or Object Security for Constrained RESTful Environments (OSCORE) <xref target="RFC8613"/>but also TLS 1.3 or newer <xref target="RFC8323"/> <xref target="RFC8446"/>to ensure message integrity and confidentiality.</t> <t>The application use case of DoC is inspired by DNS over HTTPS (DoH) <xreftarget="RFC8484"/> (DoH). DoC, however,target="RFC8484"/>. However, DoC aims for deployment in the constrained Internet of Things (IoT), which usually conflicts with the requirements introduced by HTTPS. Constrained IoT devices may be restricted in memory, power consumption, link-layer frame sizes, throughput, and latency. They may 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 know about. Name resolution in such scenarios must take into accountlink layerlink-layer 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"/> <xreftarget="I-D.ietf-iotops-7228bis"/> <cref anchor="remove-constr-nodes">RFC Ed.: Please remove the <xref target="RFC7228"/> reference and replace it with <xref target="I-D.ietf-iotops-7228bis"/> throughout the document in case <xref target="I-D.ietf-iotops-7228bis"/> becomes an RFC before publication.</cref>.</t>target="I-D.ietf-iotops-7228bis"/>.</t> <t>In order not to be burdened by the resource requirements of TCP and HTTPS, constrained IoT devices could use DNS over DTLS <xref target="RFC8094"/>. In contrast to DNS over DTLS, DoC can take advantage of CoAP features to mitigate drawbacks of datagram-based communication. These featuresinclude:include (1) block-wise transfer <xref target="RFC7959"/>, which solves the Path MTU problem of DNS over DTLS (see <xref section="5" sectionFormat="comma"target="RFC8094"/>);target="RFC8094"/>), (2) CoAP proxies, which provide an additional level ofcaching; re-usecaching, and (3) reuse of data structures for application traffic and DNS information, which saves memory 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 target="RFC9250"/>), DoC allows for lightweight message protection based on OSCORE.</t> <figure anchor="fig-overview-arch"> <name>Basic DoCarchitecture</name>Architecture</name> <artset> <artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1.1"height="224" width="608"height="208" width="584" viewBox="0 0608 224"584 208" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,96 L 8,144" fill="none" stroke="black"/> <path d="M 64,96 L 64,144" fill="none" stroke="black"/> <path d="M208,96192,96 L208,144"192,144" fill="none" stroke="black"/> <path d="M264,96248,96 L264,144"248,144" fill="none" stroke="black"/> <path d="M320,96304,96 L320,144"304,144" fill="none" stroke="black"/> <path d="M456,112440,112 L456,128"440,128" fill="none" stroke="black"/> <path d="M600,112576,112 L600,128"576,128" fill="none" stroke="black"/> <path d="M 8,96 L 64,96" fill="none" stroke="black"/> <path d="M208,96192,96 L320,96"304,96" fill="none" stroke="black"/> <path d="M472,96456,96 L584,96"560,96" fill="none" stroke="black"/> <path d="M 72,112 L200,112"184,112" fill="none" stroke="black"/> <path d="M328,112312,112 L344,112"328,112" fill="none" stroke="black"/> <path d="M360,112344,112 L376,112"360,112" fill="none" stroke="black"/> <path d="M392,112376,112 L408,112"392,112" fill="none" stroke="black"/> <path d="M424,112408,112 L448,112"432,112" fill="none" stroke="black"/> <path d="M 72,128 L200,128"184,128" fill="none" stroke="black"/> <path d="M328,128312,128 L352,128"336,128" fill="none" stroke="black"/> <path d="M368,128352,128 L384,128"368,128" fill="none" stroke="black"/> <path d="M400,128384,128 L416,128"400,128" fill="none" stroke="black"/> <path d="M432,128416,128 L448,128"432,128" fill="none" stroke="black"/> <path d="M 8,144 L 64,144" fill="none" stroke="black"/> <path d="M208,144192,144 L320,144"304,144" fill="none" stroke="black"/> <path d="M472,144456,144 L584,144"560,144" fill="none" stroke="black"/> <path d="M 40,192 L88,192"80,192" fill="none" stroke="black"/> <path d="M200,192192,192 L248,192"232,192" fill="none" stroke="black"/> <path d="M280,192264,192 L312,192"296,192" fill="none" stroke="black"/> <path d="M528,192512,192 L568,192"544,192" fill="none" stroke="black"/> <path d="M 32,176 L 40,192" fill="none" stroke="black"/> <path d="M272,176256,176 L280,192"264,192" fill="none" stroke="black"/> <path d="M 104,64 L 120,32" fill="none" stroke="black"/> <path d="M248,192232,192 L256,176"240,176" fill="none" stroke="black"/> <path d="M568,192544,192 L576,176"552,176" fill="none" stroke="black"/> <path d="M472,96456,96 C463.16936,96 456,103.16936 456,112"447.16936,96 440,103.16936 440,112" fill="none" stroke="black"/> <path d="M584,96560,96 C592.83064,96 600,103.16936 600,112"568.83064,96 576,103.16936 576,112" fill="none" stroke="black"/> <path d="M472,144456,144 C463.16936,144 456,136.83064 456,128"447.16936,144 440,136.83064 440,128" fill="none" stroke="black"/> <path d="M584,144560,144 C592.83064,144 600,136.83064 600,128"568.83064,144 576,136.83064 576,128" fill="none" stroke="black"/> <polygon class="arrowhead"points="456,112 444,106.4 444,117.6"points="440,112 428,106.4 428,117.6" fill="black"transform="rotate(0,448,112)"/>transform="rotate(0,432,112)"/> <polygon class="arrowhead"points="336,128 324,122.4 324,133.6"points="320,128 308,122.4 308,133.6" fill="black"transform="rotate(180,328,128)"/>transform="rotate(180,312,128)"/> <polygon class="arrowhead"points="208,112 196,106.4 196,117.6"points="192,112 180,106.4 180,117.6" fill="black"transform="rotate(0,200,112)"/>transform="rotate(0,184,112)"/> <polygon class="arrowhead" points="80,128 68,122.4 68,133.6" fill="black" transform="rotate(180,72,128)"/> <g class="text"> <text x="152" y="36">FETCH</text> <text x="268" y="36">coaps://[2001:db8::1]/</text> <textx="108"x="100" y="84">CoAP</text> <textx="160"x="152" y="84">request</text> <textx="108"x="100" y="100">[DNS</text> <textx="156"x="148" y="100">query]</text> <textx="360"x="344" y="100">DNS</text> <textx="400"x="384" y="100">query</text> <text x="32" y="116">DoC</text> <textx="232"x="216" y="116">DoC</text> <textx="288"x="272" y="116">DNS</text> <textx="520"x="504" y="116">DNS</text> <text x="36" y="132">Client</text> <textx="236"x="220" y="132">Server</text> <textx="292"x="276" y="132">Client</text> <textx="524"x="508" y="132">Infrastructure</text> <textx="100"x="92" y="148">CoAP</text> <textx="156"x="148" y="148">response</text> <textx="352"x="336" y="148">DNS</text> <textx="404"x="388" y="148">response</text> <textx="100"x="92" y="164">[DNS</text> <textx="160"x="152" y="164">response]</text> <textx="104"x="96" y="196">DNS</text> <textx="140"x="132" y="196">over</text> <textx="180"x="172" y="196">CoAP</text> <textx="328"x="312" y="196">DNS</text> <textx="364"x="348" y="196">over</text> <textx="456"x="440" y="196">UDP/HTTPS/QUIC/..</text> </g> </svg> </artwork> <artwork type="ascii-art"><![CDATA[ . FETCH coaps://[2001:db8::1]/ / / CoAP request +------+ [DNS query] +------+------+ DNS query.---------------..--------------. | DoC|---------------->||-------------->| DoC | DNS |--- --- --- --->| DNS ||Client|<----------------|Server|Client|<---|Client|<--------------|Server|Client|<--- --- --- ---| Infrastructure | +------+ CoAP response +------+------+ DNS response'---------------''--------------' [DNS response] \ / \ /'------DNS'-----DNS overCoAP------'CoAP-----' '----DNS overUDP/HTTPS/QUIC/...----'UDP/HTTPS/QUIC/...---' ]]></artwork> </artset> </figure> <t>The most important components of DoC can be seen in <xref target="fig-overview-arch"/>: a DoC client tries to resolve DNS information by sending DNS queries carried within CoAP requests to a DoC server. That DoC server can be theauthoritiveauthoritative 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 <xref target="STD13"/>, DNS over HTTPS <xref target="RFC8484"/>, or DNS over QUIC <xref target="RFC9250"/> when communicating with the upstream DNS infrastructure. Using that information, the DoC server then replies to the queries of the DoC client with DNS responses carried within CoAP responses. A DoC server <bcp14>MAY</bcp14> also serve as a DNSSEC validator to provide DNSSEC validation to the more constrained DoC clients.</t> <t>Note that this specification is distinct fromDoH, sinceDoH because the CoAP-specific FETCH method <xref target="RFC8132"/> is used.This has theA benefit of using this method is having the DNS query in the body such as when using the POST method, butstillwith the same caching advantages of responses to requests that use the GET method. Having the DNS query in the body means thatwe do notthere is no need for extra base64 encoding, which would increase code complexity and message sizes. Also, this allows for the block-wise transfer of queries <xref target="RFC7959"/>.</t> </section> <section anchor="terminology-and-conventions"> <name>Terminology and Conventions</name> <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>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t> <?line -18?> <t>A server that provides the service specified in this document is called a "DoC server" to differentiate it from a classic "DNS server". A DoC server actseitheras either a DNS stub resolver or a DNS recursive resolver <xref target="BCP219"/>. 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 that 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 DNS information is called a "DoC client".</t> <t>The term "constrained nodes" is used as defined in <xref target="RFC7228"/>. <xref target="RFC6690"/> describes that"ConstrainedConstrained RESTful Environments(CoRE)"(CoRE) realize the Representational State Transfer (REST) architecture <xref target="REST"/> in a suitable form for such constrained nodes.</t> <t>A DoC server can provide Observe capabilities as defined in <xref section="1.2" sectionFormat="comma" target="RFC7641"/>. As part of that, it administers a "list of observers". DoC clients using these capabilities are "observers" as defined in <xref section="1.2" sectionFormat="comma"target="RFC7641"/> in that case.target="RFC7641"/>. A "notification" is a CoAP response message with an Observeoption,option; see <xref section="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"/>. 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<t>In the examples in thisdocumentdocument, the binary payload and resource records are shown in a hexadecimal representation as well as a human-readableformat. Informat for better readability. However, in the actual message sent and received,however,they are encoded in the binary message format defined in <xref target="STD13"/>.</t> </section> <section anchor="sec_doc-server-selection"> <name>Selection of a DoC Server</name> <t>While there is no path specified for the DoC resource, it is <bcp14>RECOMMENDED</bcp14> to use the root path "/" 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. Possible options to assure this could be (1) manual configuration of a Uniform Resource Identifier (URI) <xref target="RFC3986"/> or Constrained Resource Identifier (CRI) <xreftarget="I-D.ietf-core-href"/>,target="I-D.ietf-core-href"/> or (2) automatic configuration, e.g., using a CoRE resource directory <xref target="RFC9176"/>, DHCP or Router Advertisement options <xref target="RFC9463"/>, or discovery of designated resolvers <xref target="RFC9462"/>. Automatic configuration <bcp14>MUST</bcp14> only be done from a trusted source.</t> <section anchor="discovery-by-resource-type"> <name>Discovery by Resource Type</name> <t>For discovery of the DoC resource through a link mechanism that allows describing a resource type (e.g., the Resource Type attribute in <xref target="RFC6690"/>), this document introduces the resource type "core.dns". It can be used to identify a generic DNS resolver that is available to the client.</t> </section> <section anchor="discovery-using-svcb-resource-records-or-dnr"> <name>DiscoveryusingUsing SVCB Resource Records or DNR</name> <t>A DoC server can also be discovered using Service Binding (SVCB) Resource Records(RR)(RRs) <xref target="RFC9460"/> <xref target="RFC9461"/> resolved via another DNS service (e.g., provided by an unencrypted local resolver) or Discovery of Network-designated Resolvers (DNR) Service Parameters <xref target="RFC9463"/> via DHCP or Router Advertisements. <xref target="RFC8323"/> defines the Application-Layer Protocol Negotiation (ALPN) ID for CoAP over TLS servers and <xreftarget="I-D.ietf-core-coap-dtls-alpn"/>target="PRE-RFC9952"/> defines the ALPN ID for CoAP over DTLS servers. DoC servers that use only OSCORE <xref target="RFC8613"/> and Ephemeral Diffie-Hellman Over COSE (EDHOC) <xref target="RFC9528"/>(with COSE abbreviating(COSE stands for "Concise Binary Object Notation (CBOR) Object Signing and Encryption" <xref target="RFC9052"/>) to support security cannot be discovered using these SVCB RR or DNR mechanisms. 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 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-indication"/>. It generalizes mechanisms for all CoAP services. This document introduces only the discovery of DoC services.</t> <t>This document specifies "docpath" as a single-valuedSvcParamKeyService Parameter Key (SvcParamKey) that is mandatory for DoC SVCB records. If the "docpath" SvcParamKey is absent, the service should not be considered a valid DoC service.</t> <t>The docpath isdevideddivided up into segments of the absolute path to the DoC resource (docpath-segment), each a sequence of 1-255 octets. In ABNF <xref target="RFC5234"/>:</t><artwork><![CDATA[<sourcecode type="abnf"><![CDATA[ docpath-segment = 1*255OCTET]]></artwork>]]></sourcecode> <t>Note that this restricts the length of each docpath-segment to at most 255 octets. 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> <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. The root path "/" is represented by 0 docpath-segments, i.e., an empty list. The same considerations apply for the "," and"""\" characters in docpath-segments for zone-file implementationsas forand the alpn-ids in an "alpn" SvcParamapply(<xref section="7.1.1" sectionFormat="of" target="RFC9460"/>).</t> <t>The wire-format value for "docpath" consists of 0 or more sequences of octets prefixed by their respective length as a single octet. We call this single octet the length octet. The length octet and the corresponding sequence form a length-value pair. These length-value pairs are concatenated to form the SvcParamValue. These pairs <bcp14>MUST</bcp14> exactly fill the SvcParamValue; otherwise, the SvcParamValue is malformed. Each such length-value pair represents one segment of the absolute path to the DoC resource. The root path "/" is represented by 0 length-value pairs, i.e., SvcParamValue length 0.</t> <t>Note that this format uses the same encoding as the "alpn"SvcParamSvcParam, and it can reuse the decoders and encoders for that SvcParam with the adaption that a length of zero is allowed. As long as each docpath-segmentis ofhas a length between 0 and2423 octets, inclusive, it is easily transferred into the path representation in CRIs <xref target="I-D.ietf-core-href"/> by masking each length octet with the CBOR text string major type 3 (<tt>0x60</tt> as anoctet,octet; see <xref target="RFC8949"/>). 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 corresponding CoAP Uri-Path option, provided the docpath-segments are all of a length between 0 and 12 octets (see <xref section="3.1" sectionFormat="comma" target="RFC7252"/>). Likewise, it can be transferred into a URI path-abempty form by replacing each length octet with the "/"charactercharacter. None of the abovementioned prevent longer docpath-segments than theconsidered,considered ones; they just make the translationharder,harder asthey require to makespace is required for the longer delimiters, which in turnrequiringrequire octets tomove octets.</t>be moved.</t> <t>To use the service binding from an SVCB RR or DNR Encrypted DNS option, the DoC client <bcp14>MUST</bcp14> send a DoC request constructed from the SvcParams including "docpath". The construction algorithm for DoC requests is as follows,going throughwith the provided records in order of their priority. For the purposes of this algorithm, the DoC client is assumed to be SVCB-optional (see <xref section="3" sectionFormat="of" target="RFC9460"/>).</t> <ul spacing="normal"> <li> <t>If the "alpn" SvcParam value for the service is "coap", a CoAP request 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 constructed <xreftarget="I-D.ietf-core-coap-dtls-alpn"/>.target="PRE-RFC9952"/>. Any other SvcParamKeys specifying a transport are out of the scope of this document.</t> </li> <li> <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" SvcParams from the SVCB RR (see <xref target="RFC9461"/>), or (3)fromIPv4 or IPv6 addresses provided if DNR <xref target="RFC9463"/> is used. As a fallback, an address <bcp14>MAY</bcp14> be queried for the target name of the SVCB record from another DNS service.</t> </li> <li> <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 thisspecificationspecification, 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. 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 onlyinfuenceinfluence the Uri-Path option. That option is only sent in the plaintext of anencrytpedencrypted (D)TLSchannel,channel and thus does not warrant any limitations.</t> </li> <li> <t>The request URI's hostname component <bcp14>MUST</bcp14> be the Authentication Domain Name (ADN) when obtained through DNR and <bcp14>MUST</bcp14> be the target name of the SVCB record when obtained through a <tt>_dns</tt> query (if AliasMode isused,used to the target name of the AliasMode record). This can be achieved efficiently by setting that name in TLS Server Name Indication (SNI) <xreftarget="RFC8446"/>,target="RFC8446"/> or by setting the Uri-Host option on each request.</t> </li> <li> <t>For each element in the CBOR sequence of the "docpath" SvcParam value, a Uri-Path option <bcp14>MUST</bcp14> be added to the request.</t> </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. If not, or if the endpoint becomes unreachable, the algorithm repeats with the SVCB RR or DNR Encrypted DNS option with the next highest Service Priority as a fallback (see Sections <xref target="RFC9460" section="2.4.1" sectionFormat="bare"/> and <xref target="RFC9460" section="3" sectionFormat="bare"/> of <xref target="RFC9460"/>).</t> </li> </ul> <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"> <name>Examples</name><t><cref anchor="replace-hex">RFC Ed.: Since the number for "docpath" was not assigned at the time of writing, we used the hex <tt>ff 0a</tt> (in decimal 65290; from the private use range of SvcParamKeys) throughout this section. Before publication, please replace <tt>ff 0a</tt> with the hexadecimal representation of the final value assigned by IANA in this section. Please remove this paragraph after that.</cref></t><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>ff<tt>00 0a 00 00</tt> in the binary):</t><artwork><![CDATA[<sourcecode><![CDATA[ Resource record (binary): 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 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 00 01 00 03 02 63 6fff00 0a 00 00 Resource record (human-readable): _dns.example.org. 1576 IN SVCB 1 dns.example.org ( alpn=co docpath )]]></artwork>]]></sourcecode> <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 (the last 8 bytes<tt>ff<tt>00 0a 00 04 03 64 6e 73</tt>):</t><artwork><![CDATA[<sourcecode><![CDATA[ Resource record (binary): 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 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 00 01 00 03 02 63 6fff00 0a 00 04 03 64 6e 73 Resource record (human-readable): _dns.example.org. 85 IN SVCB 1 dns.example.org ( alpn=co docpath=dns )]]></artwork>]]></sourcecode> <t>Second, see anexamplesexample for the path "/n/s" (the last 8 bytes<tt>ff<tt>00 0a 00 04 01 6e 01 73</tt>):</t><artwork><![CDATA[<sourcecode><![CDATA[ Resource record (binary): 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 6e 73 07 65 78 61 6d 70 6c 65 03 6f 72 67 00 00 01 00 03 02 63 6fff00 0a 00 04 01 6e 01 73 Resource record (human-readable): _dns.example.org.6431643 IN SVCB 1 dns.example.org ( alpn=co docpath=n,s )]]></artwork>]]></sourcecode> <t>If the server also provides DNS over HTTPS, "dohpath" and "docpath" <bcp14>MAY</bcp14>co-exist:</t> <artwork><![CDATA[coexist:</t> <sourcecode><![CDATA[ Resource record (binary): 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 002b2c 00 01 03 64 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 64 6e 73 7dff00 0a 00 00 Resource record (human-readable): _dns.example.org. 429 IN SVCB 1 dns.example.org ( alpn=h3,co dohpath=/{?dns} docpath )]]></artwork>]]></sourcecode> </section> </section> </section> <section anchor="basic-message-exchange"> <name>Basic Message Exchange</name> <section anchor="sec_content-format"> <name>The "application/dns-message" Content-Format</name> <t>This document defines a CoAP Content-FormatidentifierID for the Internet media type "application/dns-message" to be the mnemonic553 —553, based on the port assignment of DNS. This media type is defined as in <xref section="6" sectionFormat="of" target="RFC8484"/>, 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. 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.(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 implement (see also <xref target="sec_resp-examples"/>).</t> </section> <section anchor="sec_queries"> <name>DNS Queries in CoAP Requests</name> <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. 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 Confirmablemessages)messages), the retransmission mechanism of the DNS protocol as defined in <xref target="STD13"/> is not needed.</t> <section anchor="request-format"> <name>Request Format</name> <t>When sending a CoAP request, a DoC client <bcp14>MUST</bcp14> include 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. This document specifies the usage of Content-Format "application/dns-message" (for details, see <xref target="sec_content-format"/>).</t> </section> <section anchor="sec_req-caching"> <name>Support of CoAP Caching</name> <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 proxyen-route)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. Apart from losing these caching benefits, there is no harmitin 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> </section> <section anchor="sec_req-examples"> <name>Example</name> <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 CoAP body is encoded in the "application/dns-message" Content-Format.</t><artwork><![CDATA[<sourcecode><![CDATA[ FETCH coaps://[2001:db8::1]/ Content-Format: 553 (application/dns-message) Accept: 553 (application/dns-message) Payload (binary): 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 Payload (human-readable): ;; ->>Header<<- opcode: QUERY, status: NOERROR, id: 0 ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.org. IN AAAA]]></artwork>]]></sourcecode> </section> </section> <section anchor="dns-responses-in-coap-responses"> <name>DNS Responses in CoAP Responses</name> <t>Each DNS query-response pair is mapped to a CoAP request-response operation. DNS responses are provided in the body of the CoAP response, i.e., it is also possible to transfer them using block-wise transfer <xref target="RFC7959"/>. A DoC server <bcp14>MUST</bcp14> be able to produce responses in the "application/dns-message" Content-Format (for details, see <xref target="sec_content-format"/>) when requested. The use of the Accept option in the request isoptional.<bcp14>OPTIONAL</bcp14>. However, all DoC clients <bcp14>MUST</bcp14> be able to parseaan "application/dns-message" response (see also <xref target="sec_content-format"/>). Any response Content-Format other than "application/dns-message" <bcp14>MUST</bcp14> be indicated with the Content-Format option by the DoC server.</t> <section anchor="sec_resp-codes"> <name>Response Codes and Handling DNS and CoAPerrors</name>Errors</name> <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 aparseableparsable DNS response use a 2.05 (Content) response code.</t> <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 request does not 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. 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>SHOULD</bcp14> respond with an appropriate CoAP error.</t> <t>A DoC client might try to repeat a non-successful exchange unless otherwise prohibited. The DoC client might also decide to repeat a non-successful exchange with a different URI, for instance, when the response indicates an unsupported Content-Format.</t> </section> <section anchor="sec_resp-caching"> <name>Support of CoAP Caching</name> <t>For reliability andenergy savingenergy-saving measures, content decoupling (such 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. For cache validation, CoAP implementations regularly use hashing over the message 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 proposed 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 often the same regardless of query time.</t> <t>The DoC server <bcp14>MUST</bcp14> ensure that the sum of the Max-Age value of a CoAP response and any TTL in the DNS response is less than or equal to the corresponding TTL received from an upstream 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. The DoC client <bcp14>MUST</bcp14> then add the Max-Age value of the carrying CoAP response to all TTLs in a DNS response on reception and use these calculated TTLs for the associated records.</t><t>The<t>To meet the requirement for DoC, the <bcp14>RECOMMENDED</bcp14> algorithm for a DoC serverto meet the requirement for DoCis as follows: Set the Max-Age option of a response to the minimum TTL of a DNS response and subtract this value from all TTLs of that DNS response. This prevents expired records from unintentionally being served from an intermediate CoAP cache. Additionally, if the ETag for cache validation is based on the content of the response, it allows that ETag not to change. 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 algorithm 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, the 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. The same applies for DNS responsesthatthat, for anyreasonreason, do not carry any records with a TTL.</t> </section> <section anchor="sec_resp-examples"> <name>Examples</name> <t>The following example illustrates the response to the query "example.org. IN AAAA record", with recursion turned on. Successful responses carry one answer record including the address 2001:db8:1:0:1:2:3:4 and TTL 79689.</t> <t>A successful response:</t><artwork><![CDATA[<sourcecode><![CDATA[ 2.05 Content Content-Format: 553 (application/dns-message) Max-Age: 58719 Payload (human-readable): ;; ->>Header<<- opcode: QUERY, status: NOERROR, id: 0 ;; flags: qr rd ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;example.org. IN AAAA ;; ANSWER SECTION: ;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 this case–- is noted in the DNS response, the CoAP response still indicates success.</t><artwork><![CDATA[<sourcecode><![CDATA[ 2.05 Content Content-Format: 553 (application/dns-message) Payload (human-readable): ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 0 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;does.not.exist. IN AAAA]]></artwork>]]></sourcecode> <t>As described in <xref target="sec_content-format"/>, a DoC server uses NotImp (RCODE = 4) if it does not support anOPCODE—aOPCODE - in this case, it errors on a DNS Update (OPCODE = 5) for"example.org" in this case.</t> <artwork><![CDATA["example.org".</t> <sourcecode><![CDATA[ 2.05 Content Content-Format: 553 (application/dns-message) Payload (human-readable): ;; ->>Header<<- opcode: UPDATE, status: NOTIMP, id: 0 ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;example.org. IN AAAA]]></artwork>]]></sourcecode> <t>When an error occurs at the CoAP layer, the DoC server responds with an appropriate CoAP error, forinstanceinstance, 4.15 (Unsupported Content-Format) if the Content-Format option in the request was not set to "application/dns-message" and the Content-Format is not otherwise supported by the server.</t><artwork><![CDATA[<sourcecode><![CDATA[ 4.15 Unsupported Content-Format [no payload]]]></artwork>]]></sourcecode> </section> </section> </section> <section anchor="interaction-with-other-coap-and-core-features"> <name>Interaction withotherOther CoAP and CoRE Features</name> <section anchor="dns-push-notifications-and-coap-observe"> <name>DNS Push Notifications and CoAP Observe</name> <t>DNS Push Notifications <xref target="RFC8765"/>providesprovide the capability to asynchronously notify clients about resource record changes. However, it results in additional overhead, which conflicts with constrained resources. This is the reason why it is <bcp14>RECOMMENDED</bcp14> to use CoAP Observe <xref target="RFC7641"/> instead of DNS Push in the DoC domain. This is particularly useful if a short-lived record is requested frequently. The DoC server <bcp14>SHOULD</bcp14> provide Observe capabilities on its DoC resource and do as follows.</t> <t>If a DoCclientsclient wants to observe a resource record, a DoC server can respond with a notification and add the client to its list of observers for that resource in accordancetowith <xref target="RFC7641"/>. The DoC server <bcp14>MAY</bcp14> subscribe to DNSpush notificationsPush Notifications for that record. This involves sending a DNS Subscribe message (see(<xref<xref section="6.2" sectionFormat="of" target="RFC8765"/>), instead of a classic DNS query to fetch the information on behalf of the DoC client.</t> <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"/>), and no other reason to subscribe to that request is present, the DoC server <bcp14>SHOULD</bcp14> cancel the corresponding subscription. This can involve sendingana 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 failure todo sounsubscribe or close the session 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> <t>Whenever the DoC server receives a DNS Push message from the DNS infrastructure for an observed resource record, the DoC server sends an appropriate Observe notification response to the DoC client.</t> <t>A server that responds with notifications (i.e., sends the Observe option) needs to have the means of obtaining current resource records. This may happen through DNSPush, butPush or also by upstream polling or implicit circumstances (e.g., if the DoC server is the authoritative name server for the record and wants to notify about changes).</t> </section> <section anchor="oscore"> <name>OSCORE</name> <t>It is <bcp14>RECOMMENDED</bcp14> to carry DNS messages protected using OSCORE <xref target="RFC8613"/> between the DoC client and the DoC server. The establishment and maintenance of the OSCORESecurity Contextsecurity context is out of the scope of this document.</t> <t><xreftarget="I-D.amsuess-core-cachable-oscore"/>target="I-D.ietf-core-cacheable-oscore"/> describes a method to allow cache retrieval of OSCORE responses and discusses the corresponding implications on message sizes and security properties.</t> </section> <section anchor="mapping-doc-to-doh"> <name>Mapping DoC to DoH</name> <t>This document provides no specification on how to map between DoC and DoH, e.g., at aCoAP-to-HTTP-proxy; suchCoAP-to-HTTP proxy. Such a direct mapping is <bcp14>NOT RECOMMENDED</bcp14>:rewritingRewriting the FETCH method (<xref target="sec_queries"/>) andtheTTLrewriting(<xref target="sec_resp-caching"/>) as specified in thisdraftdocument would be non-trivial. It is <bcp14>RECOMMENDED</bcp14> to use a DNS forwarder to map between DoC and DoH, as would be the case for mapping between any other pair of DNS transports.</t> </section> </section> <section anchor="sec_unprotected-coap"> <name>Considerations for Unprotected Use</name> <t>The use of DoC without confidentiality and integrity protection is <bcp14>NOT RECOMMENDED</bcp14>. Without secure communication, many possible attacks need to be evaluated in the context of the application's threat model. This includes known threats for unprotected DNS <xref target="RFC3833"/> <xref target="RFC9076"/> and CoAP<xref(<xref section="11" sectionFormat="of"target="RFC7252"/>.target="RFC7252"/>). While DoC does not use the random ID of the DNS header (see <xref target="sec_req-caching"/>), equivalent protection against off-path poisoning attacks is achieved by using random large token values for unprotected CoAP requests. If a DoC message isunprotectedunprotected, it <bcp14>MUST</bcp14> use a random token with a length of at least 2 byteslengthto mitigate this kind of poisoning attack.</t> </section> <sectionanchor="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 working 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 before 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 <martine.lenders@tu-dresden.de></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.com/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 <martine.lenders@tu-dresden.de></tt></t> </dd> <dt>Last update of this information:</dt> <dd> <t>September 2024</t> </dd> </dl> </section> </section> <sectionanchor="security-considerations"> <name>Security Considerations</name> <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 communication, e.g., OSCORE (<xref section="12" sectionFormat="comma" target="RFC8613"/>) as well as DTLS 1.2 or newer (<xref section="5" sectionFormat="comma" target="RFC6347"/> and <xref section="11" sectionFormat="comma" target="RFC9147"/>). Additionally, DoC uses request patterns that require the maintenance of long-lived security contexts. <xrefsection="2.6"section="2.7" sectionFormat="of" target="I-D.ietf-core-corr-clar"/> provides insights on what can be done when those are resumed from a new endpoint.</t> <t>Though DTLS v1.2 <xref target="RFC6347"/> wasobsoletetedobsoleted by DTLS v1.3 <xreftarget="RFC9147"/>target="RFC9147"/>, there arestillmany CoAP 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 newer versions are <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 specified in <xref target="sec_req-caching"/> opens the DNS cache of a DoC client to cache poisoning attacks via response spoofing. This document requires an unpredictable CoAP token in each DoC query from the client when CoAP is not secured to mitigate such an attack over DoC (see <xref target="sec_unprotected-coap"/>).</t> <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 responses in their protocol design. Consequently, the ID of the DNS message can be set to 0 without any concern in order to leverage the advantages of CoAP caching.</t> <t>A DoC client must be aware that the DoC server may communicate unprotected with the upstream DNS infrastructure, e.g., using DNS over UDP. DoC can only guarantee confidentiality and integrity of communication between parties for which the security context is exchanged. The DoC server may use another security context to communicate upstream with both confidentiality and integrity (e.g., DNS over QUIC <xreftarget="RFC9250"/>), but,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> <t>A DoC client may not be able to perform DNSSEC validation, e.g., due to code sizeconstraints,constraints ordue tothe size of the responses. It may trust its DoC server to perform DNSSEC validation; how that trust is expressed is out of the scope of this document. For instance, a DoC client maybe,be configured to use a particular credential by which it recognizes an eligible DoC server. That information can also imply trust in the DNSSEC validation by that DoC server.</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name><t><cref anchor="replace-xxxx">RFC Ed.: throughout this section, please replace 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"> <name>CoAP Content-Formats Registry</name> <t>IANAis requested to assignhas assigned a CoAP Content-Format ID for the "application/dns-message" media type in the "CoAP Content-Formats"registry, withinregistry in the "Constrained RESTful Environments (CoRE) Parameters" registry group <xreftarget="RFC7252"/>, correspondingtarget="RFC7252"/>; this corresponds to the "application/dns-message" media type from the "Media Types" registry (see <xref target="RFC8484"/>).</t><t>Content Type: application/dns-message</t> <t>Content Coding: -</t> <t>ID: 553 (suggested)</t> <t>Reference:<table anchor="tab-coap-content-format"> <name>CoAP Content-Format ID</name> <thead> <tr> <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-XXXX],RFC 9953, <xreftarget="sec_content-format"/></t>target="sec_content-format"/></td> </tr> </tbody> </table> </section> <sectionanchor="dns-service-bindings-svcb-registry">anchor="dns-svbc-service-parameter-keys-svcparamkeys-registry"> <name>DNS SVBC ServiceBindings (SVCB)Parameter Keys (SvcParamKeys) Registry</name> <t>IANAis requested to addhas added the following entry to the"Service"DNS SVCB Service Parameter Keys (SvcParamKeys)" registrywithinin the "DNS Service Bindings (SVCB)" registry group. The definition of this parameter can be found in <xref target="sec_doc-server-selection"/>.</t> <table anchor="tab-svc-param-keys"><name>Values<name>Value for SvcParamKeys</name> <thead> <tr> <th align="left">Number</th> <th align="left">Name</th> <th align="left">Meaning</th> <th align="left">Change Controller</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <tdalign="left">10 (suggested)</td>align="left">10</td> <td align="left">docpath</td> <td align="left">DNS over CoAP resource path</td> <td align="left">IETF</td> <tdalign="left">[RFC-XXXX],align="left">RFC 9953, <xref target="sec_doc-server-selection"/></td> </tr> </tbody> </table> </section> <section anchor="resource-type-rt-link-target-attribute-values-registry"> <name>Resource Type (rt=) Link Target Attribute Values Registry</name> <t>IANAis requested to add a new Resource Type (rt=) Link Target Attributehas added "core.dns" to the "Resource Type (rt=) Link Target Attribute Values" registrywithinin the "Constrained RESTful Environments (CoRE) Parameters" registry group.</t><t>Value: core.dns</t> <t>Description: DNS<table anchor="tab-resource-type"> <name>Resource Type (rt=) Link Target Attribute</name> <thead> <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 CoAPresource.</t> <t>Reference: [RFC-XXXX],resource</td> <td align="left">RFC 9953, <xreftarget="sec_doc-server-selection"/></t>target="sec_doc-server-selection"/></td> </tr> </tbody> </table> </section> </section> <section anchor="operational-considerations"> <name>Operational Considerations</name> <sectionanchor="co-existence-of-different-dns-and-coap-transports"> <name>Co-existenceanchor="coexistence-of-different-dns-and-coap-transports"> <name>Coexistence ofdifferentDifferent DNS and CoAPtransports</name>Transports</name> <t>Many DNS transports mayco-existcoexist on the DoC server, such as DNS over UDP <xref target="STD13"/>, DNS over (D)TLS <xref target="RFC7858"/> <xref target="RFC8094"/>, DNS over HTTPS <xref target="RFC8484"/>, or DNS over QUIC <xref target="RFC9250"/>. In principle, transports employing channel or object security should be preferred. 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 this document.</t> <t>CoAP supports Confirmable and Non-Confirmable messages <xref target="RFC7252"/> to deploy different levels of reliability.This document, however,However, this document does not enforce any of these message types, as the decision on which one is appropriate depends on the characteristics of the network where DoC is deployed.</t> </section> <section anchor="redirects"> <name>Redirects</name> <t>Application-layer redirects (e.g., HTTP)redirctredirect a client to a new 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. At the time of writing, CoAP does not support redirection. Future specifications of CoAP redirect may need to consider the impact of different results between previous and new DNSserver.</t>servers.</t> </section> <section anchor="proxy-hop-limit"> <name>ProxyHop-Limit</name>Hop Limit</name> <t>Mistakes might lead to CoAP proxies forming infinite loops. Using the CoAP Hop-Limit option <xref target="RFC8768"/> mitigates such loops.</t> </section> <section anchor="error-handling"> <name>Error Handling</name> <t><xref target="sec_resp-codes"/> specifies that DNS operational errors should be reported back to a DoC client using the appropriate DNS RCODE. If a DoC client did not receive any successful DNSmessagemessages from a DoC server for a while, it might indicate that the DoC server 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> </section> <section anchor="dns-extensions"> <name>DNS Extensions</name> <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> </middle> <back> <displayreference target="I-D.ietf-core-href" to="CRI"/> <displayreference target="I-D.ietf-core-transport-indication" to="TRANSPORT-IND"/> <displayreference target="I-D.ietf-iotops-7228bis" to="RFC7228bis"/> <displayreference target="I-D.ietf-core-cacheable-oscore" to="CACHEABLE-OSCORE"/> <displayreference target="I-D.ietf-core-corr-clar" to="CoAP-CORR-CLAR"/> <references anchor="sec-combined-references"> <name>References</name> <references anchor="sec-normative-references"> <name>Normative References</name> <referencegroup anchor="STD13" target="https://www.rfc-editor.org/info/std13"><reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1034"> <front> <title>Domain names - concepts and facilities</title> <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/> <date month="November" year="1987"/> <abstract> <t>This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their 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 them.</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/rfc1035"> <front> <title>Domain names - implementation and specification</title> <author fullname="P. Mockapetris" initials="P." surname="Mockapetris"/> <date month="November" year="1987"/> <abstract> <t>This RFC is the revised specification of the protocol and format 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><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/> </referencegroup> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7641.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7959.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8132.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8323.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8484.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8613.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8765.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8768.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9147.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9460.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9461.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9462.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9463.xml"/> <referenceanchor="RFC3986"> <front> <title>Uniform Resource Identifier (URI): Generic Syntax</title> <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"/> <author fullname="R. Fielding" initials="R." surname="Fielding"/> <author fullname="L. Masinter" initials="L." surname="Masinter"/> <date month="January" year="2005"/> <abstract> <t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]</t> </abstract> </front> <seriesInfo name="STD" value="66"/> <seriesInfo name="RFC" value="3986"/> <seriesInfo name="DOI" value="10.17487/RFC3986"/> </reference> <reference anchor="RFC5234"> <front> <title>Augmented BNF for Syntax Specifications: ABNF</title> <author fullname="D. Crocker" initials="D." role="editor" surname="Crocker"/> <author fullname="P. Overell" initials="P." surname="Overell"/> <date month="January" year="2008"/> <abstract> <t>Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [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 Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying 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">anchor="PRE-RFC9952" target="https://www.rfc-editor.org/info/rfc9952"> <front> <title>TheConstrained 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 web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t> <t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t> </abstract> </front> <seriesInfo name="RFC" value="7252"/> <seriesInfo name="DOI" value="10.17487/RFC7252"/> </reference> <reference anchor="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 application 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 extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending 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="Shelby"/> <date month="August" year="2016"/> <abstract> <t>The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for 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 Security (DTLS). These transports only offer fragmentation, which is even more problematic 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 extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, 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 generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. 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 ApplicationApplication-Layer Protocol(CoAP)</title> <author fullname="P. van der Stok" initials="P." surname="van der Stok"/> <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 7252Negotiation (ALPN) ID Specification for the Constrained Application Protocol (CoAP)only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP need to access parts of the resources.</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 WebSockets</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="Raymor"/> <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 document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport.</t> </abstract> </front> <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 getting DNS responses over HTTPS. Each DNS query-response pair is mapped into an HTTP 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 Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.</t> <t>Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252.</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 records efficiently for queries for data that are relatively static. When those records 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. This 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</title> <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 detect 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 format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t> <t>This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange 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 Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, 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 exception 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 "HTTPS" DNS resource record (RR) types to facilitate the lookup of information needed to make connections to network services, such as for HTTP origins. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration), and are extensible to support future uses (such as keys for encrypting the TLS ClientHello). They 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 privacy.</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 name. 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 DNS Resolvers and their Designated Resolvers are operated by the same entity or cooperating entities. It can also be used to discover support for encrypted DNS protocols 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 Network-designated Resolvers (DNR)</title> <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/> <author fullname="T. Reddy.K" initials="T." role="editor" surname="Reddy.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 Domain 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> <title>ALPN ID Specification for CoAPover DTLS</title> <authorfullname="Martine Sophie Lenders"initials="M. S."surname="Lenders"> <organization>TUD Dresden University of Technology</organization>surname="Lenders" fullname="Martine Sophie Lenders"> <organization/> </author> <authorfullname="Christian Amsüss"initials="C."surname="Amsüss">surname="Amsüss" fullname="Christian Amsüss"> <organization/> </author> <authorfullname="Thomas C. Schmidt"initials="T. C."surname="Schmidt"> <organization>HAW Hamburg</organization>surname="Schmidt" fullname="Thomas C. Schmidt"> <organization/> </author> <authorfullname="Matthias Wählisch"initials="M."surname="Wählisch"> <organization>TUD Dresden University of Technology & Barkhausen Institut</organization>surname="Wählisch" fullname="Matthias Wählisch"> <organization/> </author> <dateday="11" month="August" year="2025"/> <abstract> <t> This document specifies an Application-Layer Protocol Negotiation (ALPN) ID for transport-layer-secured Constrained Application Protocol (CoAP) services. </t> </abstract> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-core-coap-dtls-alpn-05"/> </reference> <reference anchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <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 signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, 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</title> <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 protocol 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>year="2026" month="March"/> </front> <seriesInfoname="BCP" value="14"/> <seriesInfoname="RFC"value="8174"/>value="PRE-9952"/> <seriesInfo name="DOI"value="10.17487/RFC8174"/>value="10.17487/PRE-RFC9952"/> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <references anchor="sec-informative-references"> <name>Informative References</name> <referencegroup anchor="BCP219" target="https://www.rfc-editor.org/info/bcp219"><reference anchor="RFC9499" target="https://www.rfc-editor.org/info/rfc9499"> <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 of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms 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 clarifications. Comprehensive lists of changed and new definitions can be found in 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><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"/> </referencegroup> <referencegroup anchor="BCP237" target="https://www.rfc-editor.org/info/bcp237"><reference anchor="RFC9364" target="https://www.rfc-editor.org/info/rfc9364"> <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 that 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 origin 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><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9364.xml"/> </referencegroup><reference anchor="RFC3833"> <front> <title>Threat Analysis of the Domain Name System (DNS)</title> <author fullname="D. Atkins" initials="D." surname="Atkins"/> <author fullname="R. Austein" initials="R." surname="Austein"/> <date month="August" year="2004"/> <abstract> <t>Although the DNS Security Extensions (DNSSEC) have been under development for most of the last decade, the IETF has never written down the specific set of threats against which DNSSEC is designed to protect. Among other drawbacks, this cart-before-the-horse situation has made it difficult to determine whether DNSSEC meets its design goals, since its design goals are not well specified. This note attempts to document some of the known threats to the DNS, and, in doing so, attempts to measure to what extent (if any) DNSSEC is a useful tool in defending against these threats. This memo provides information for the Internet community.</t> </abstract> </front> <seriesInfo name="RFC" value="3833"/> <seriesInfo name="DOI" value="10.17487/RFC3833"/> </reference> <reference anchor="RFC6690"> <front> <title>Constrained RESTful Environments (CoRE) Link Format</title> <author fullname="Z. Shelby" initials="Z." surname="Shelby"/> <date month="August" year="2012"/> <abstract> <t>This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK]</t> </abstract> </front> <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 devices 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="RFC" value="7228"/> <seriesInfo name="DOI" value="10.17487/RFC7228"/> </reference> <reference anchor="RFC7858"> <front> <title>Specification for DNS over Transport Layer Security (TLS)</title> <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 (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities 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 profiles for DNS over TLS and provides advice on performance considerations to minimize 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 applications 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 the path between the DNS client and its server. These queries and responses can contain privacy-sensitive information, which is valuable to protect.</t> <t>This document proposes the use of Datagram Transport Layer Security (DTLS) for DNS, to protect against passive listeners and certain active attacks. As latency is critical for DNS, this proposal also discusses mechanisms to reduce DTLS round trips and reduce the DTLS handshake size. The proposed mechanism 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 situation 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</title> <author fullname="C. Amsüss" initials="C." role="editor" surname="Amsü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 Stok"/> <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 called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links, and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, look up, and remove information on resources. Furthermore, new target attributes 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 confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking 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) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, 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ß Mattsson"/> <author fullname="F. Palombini" initials="F." surname="Palombini"/> <date month="March" year="2024"/> <abstract> <t>This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a very compact and lightweight authenticated Diffie-Hellman key exchange with ephemeral keys. EDHOC provides mutual authentication, forward secrecy, and identity protection. EDHOC is intended for usage in constrained scenarios, and a main use case is to establish an Object Security for Constrained RESTful Environments (OSCORE) security context. By reusing CBOR Object Signing and Encryption (COSE) 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 available 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-indication-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 devices 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 Protocol (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-oscore-11"/> </reference><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3833.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6690.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7228.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8094.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9076.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9176.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9250.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9528.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-core-href.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-core-transport-indication.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-iotops-7228bis.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-core-cacheable-oscore.xml"/> <reference anchor="DoC-paper"> <front> <title>Securing Name Resolution in the IoT: DNS over CoAP</title> <author initials="M. S." surname="Lenders" fullname="Martine S.Lenders" initials="M." surname="Lenders">Lenders"> <organization>TU Dresden, Germany</organization> </author> <authorfullname="Christian Amsüss"initials="C."surname="Amsüss">surname="Amsüss" fullname="Christian Amsüss"> <organization>Unaffiliated, Vienna, Austria</organization> </author> <authorfullname="Cenk Gündogan"initials="C."surname="Gündogan">surname="Gündogan" fullname="Cenk Gündogan"> <organization>Huawei Technologies, Munich, Germany</organization> </author> <authorfullname="Marcin Nawrocki"initials="M."surname="Nawrocki">surname="Nawrocki" fullname="Marcin Nawrocki"> <organization>TU Dresden, Germany</organization> </author> <author initials="T." surname="Schmidt" fullname="Thomas C.Schmidt" initials="T." surname="Schmidt">Schmidt"> <organization>HAW Hamburg, Hamburg, Germany</organization> </author> <authorfullname="Matthias Wählisch"initials="M."surname="Wählisch">surname="Wählisch" fullname="Matthias Wählisch"> <organization>TU Dresden &amp; Barkhausen Institut, Dresden, Germany</organization> </author> <datemonth="September" year="2023"/>year="2023" month="September"/> </front> <seriesInfoname="Proceedingsname="DOI" value="10.1145/3609423"/> <refcontent>Proceedings of the ACM onNetworking" value="vol.Networking, vol. 1, no. CoNEXT2, pp.1-25"/> <seriesInfo name="DOI" value="10.1145/3609423"/> <refcontent>Association for Computing Machinery (ACM)</refcontent> </reference> <reference anchor="I-D.ietf-core-corr-clar"> <front> <title>Constrained Application Protocol (CoAP): Corrections and Clarifications</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"/>1-25</refcontent> </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"> <front> <title>Architectural Styles and the Design of Network-based Software Architectures</title> <author initials="R." surname="Fielding" fullname="Roy Thomas Fielding"> <organization>University of California, Irvine</organization> </author> <date year="2000"/> </front><seriesInfo name="Ph.D." value="Dissertation, University of California, Irvine"/><format type="HTML" target="https://ics.uci.edu/~fielding/pubs/dissertation/top.htm"/></reference> <reference anchor="RFC8446"> <front> <title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <author fullname="E. Rescorla" initials="E." surname="Rescorla"/> <date month="August" year="2018"/> <abstract> <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t> <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</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 Process</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 designed 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 encryption 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 Status 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 Implementation Status section. This will allow reviewers and working 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.</t> <t>This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice.</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 either UDP or TCP. UDP transport involves keeping less state on a busy server, but can cause truncation and retries over TCP. Additionally, UDP can be exploited for reflection attacks. Using TCP would reduce retransmits and amplification. However, 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") that allows DNS servers to signal a variable idle timeout. This signalling encourages the use<refcontent>Ph.D. Dissertation, University oflong-lived TCP connections by allowing the state associated with TCP transport to be managed effectively with minimal impact on the DNS transaction time.</t> </abstract> </front> <seriesInfo name="RFC" value="7828"/> <seriesInfo name="DOI" value="10.17487/RFC7828"/>California, Irvine</refcontent> </reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9052.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7828.xml"/> </references> </references> <?line825?>802?> <section anchor="sec_evaluation"> <name>Evaluation</name> <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-paper"/>.</t></section> <section anchor="change-log"> <name>Change Log</name> <t><cref anchor="remove-changelog">RFC Ed.: Please remove this section before publication.</cref></t> <section anchor="since-draft-ietf-core-dns-over-coap-18"> <name>Since <eref target="https://datatracker.ietf.org/doc/html/draft-ietf-core-dns-over-coap-18">draft-ietf-core-dns-over-coap-18</eref></name> <ul spacing="normal"> <li> <t>Address Address Mohamed Boucadair's COMMENT: </t> <ul spacing="normal"> <li> <t>Add Operational Considerations Section</t> </li> <li> <t>Make SVCB references normative</t> </li> <li> <t>Remove redundant requirement on parsing application/dns-message</t> </li> <li> <t>Remove contradicting statement<!--[rfced] Sourcecode andoutdated reference about ALPN</t> </li> <li> <t>Add DNS client to Fig. 1</t> </li> <li> <t>Clarify recursion termination in the CoAP realm</t> </li> <li> <t>Clarify where addresses are coming from with DDR/DNR</t> </li> </ul> </li> <li> <t>Address Gorry Fairhurst's follow-up DISCUSS: </t> <ul spacing="normal"> <li> <t>Refer to Observe terminologyartwork c) The blocks in Section2</t> </li> <li> <t>Clarify registration</t> </li> <li> <t>Provide alternative observation examples</t> </li> <li> <t>Clarify that error handling is in the hands of the DoC server</t> </li> </ul> </li> </ul> </section> <section anchor="since-draft-ietf-core-dns-over-coap-17"> <name>Since <eref target="https://datatracker.ietf.org/doc/html/draft-ietf-core-dns-over-coap-17">draft-ietf-core-dns-over-coap-17</eref></name> <ul spacing="normal"> <li> <t>Address Roman Danyliw's COMMENT: </t> <ul spacing="normal"> <li> <t>Remove unused RFC8742 reference</t> </li> </ul> </li> <li> <t>Address Vladimír Čunát's DNSDIR review </t> <ul spacing="normal"> <li> <t>Address Éric Vyncke' COMMENT:</t> </li> <li> <t>Mention OPCODE 0 in Abstract and Introduction</t> </li> <li> <t>Reference to STD13 instead of RFC1035</t> </li> <li> <t>Provide extension pointers for future documents on other OPCODES</t> </li> <li> <t>Use only singular4.3.3 are too long forexample section if there is only one example</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 tothe<tt>RFC Ed.:</tt>) about paragraph 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 fromTXT output. We marked these as sourcecode, so they should have atrusted source</t> </li> <li> <t>Remove confusing and unnecessary <bcp14>MAY</bcp14></t> </li> <li> <t>Remove normative repeatwidth ofSvcParam algorithm by citing RFC 9461</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-ietf-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 intro</t> </li> <li> <t>Fix representation format in69 characters or less. The long lines are currently 70 characters. Would moving all thedocpath examples</t> </li> <li> <t>Make docpath wire-format paragraph easierlines with semicolons over toparse</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-ietf-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 rfc7228bis 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 nottheSVCB 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 set</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-ietf-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 algorithm</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 -> 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>Retitleleft one space (in just this section5 to "Interaction with other CoAP and CoRE Features"</t> </li> <li> <t>Make prevention of poisoning attacks normative for unprotected CoAP</t> </li> <li> <t>Provide specs on if the <bcp14>SHOULD</bcp14> on ID=0 does not 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-ietf-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-ietf-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-ietf-core-dns-over-coap-10">draft-ietf-core-dns-over-coap-10</eref></name> <ul spacing="normal"> <li> <t>Replace impreciseorwrong terms: </t> <ul spacing="normal"> <li> <t>disjunct => distinct</t> </li> <li> <t>unencrypted CoAP => unprotected CoAP</t> </li> <li> <t>security mode => confidential communication</t> </li> </ul> </li> <li> <t>Pullindefinition 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 "upstream 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 remove now redundant DNS Upgrade section as a consequence</t> </li> <li> <t>Clarify thatall theDoC/DoH mapping is what is <bcp14>NOT RECOMMENDED</bcp14></t> </li> <li> <t>Avoid use of undefined term “CoAP resource identifier”</t> </li> <li> <t>Discuss Max-Age option valuesourcecode inan 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-ietf-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.ietf.org/doc/html/rfc2136">[RFC2136]</eref>, clarify that it is currently not considered</t> </li> <li> <t>Add to security considerations: unprotected upstream DNS and DNSSEC</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-ietf-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-ietf-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-ietf-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 Type</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-ietf-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-ietf-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-ietf-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-ietf-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 accordance with <xref target="RFC7942"/>)</t> </li> <li> <t>Recommend root path to keeptheCoAP 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-ietf-core-dns-over-coap-01">draft-ietf-core-dns-over-coap-01</eref></name> <ul spacing="normal"> <li> <t>Specify DoC server roledocument) be a good solution? We tried this interms of DNS terminology</t> </li> <li> <t>Clarify communication of DoC to DNS infrastructure is agnostic ofthetransport</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-ietf-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)test files listed above so you can see what the output will look like. Feel free toits own draft (<eref target="https://datatracker.ietf.org/doc/draft-lenders-dns-cns/">draft-lenders-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-lenders-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>offer other suggestions as well. --> </section> <section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>The authors of this document want to thankMike Bishop, Carsten Bormann, Mohamed Boucadair, Deb Cooley, Vladimír Čunát, Roman Danyliw, Elwyn<contact fullname="Mike Bishop"/>, <contact fullname="Carsten Bormann"/>, <contact fullname="Mohamed Boucadair"/>, <contact fullname="Deb Cooley"/>, <contact fullname="Vladimír Čunát"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="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 Wicinski, and Paul WoutersDavies"/>, <contact fullname="Esko Dijk"/>, <contact fullname="Gorry Fairhurst"/>, <contact fullname="Thomas Fossati"/>, <contact fullname="Mikolai Gütschow"/>, <contact fullname="Todd Herr"/>, <contact fullname="Tommy Pauly"/>, <contact fullname="Jan Romann"/>, <contact fullname="Ben Schwartz"/>, <contact fullname="Orie Steele"/>, <contact fullname="Marco Tiloca"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Tim Wicinski"/>, and <contact fullname="Paul Wouters"/> for their feedback and comments.</t> <t>This work was supported in parts by the German Federal Ministry of Research, Technology and Space (BMFTR) under the grant numbers 16KIS1386K (TU Dresden) and 16KIS1387 (HAW Hamburg) within the research project PIVOT and under the grant numbers 16KIS1694K (TU Dresden) and 16KIS1695 (HAW Hamburg) within the research project C-ray4edge.</t> </section> </back> <!-- ##markdown-source:H4sIAAAAAAAAA8V92XIb2ZXge37FbVREF+kGQHCnWFbZFEkV2SOKNElVtaNK 40ogL4g0E5lwLqTgkhx+nYh57MeZ6JmIeZ0/6Kep/hJ/yZztLpkJkJSsthm2 igQy73Lu2bfb6/WCu321GQRlXCZ6X3WOXl+p7E7n6jA7uFArR9nhaicIh8Nc w3PwVxBlozScwqNRHo7LXqzLcW+U5boXpUUP34S/wllvYxCMwlLfZPl8XxVl FBTVcBoXRZyl5XwGr58eX78MgrvNd9NkIx+P9gOlijjR6Ujjrz31MqvSSF19 +426j8sJ/BPBv1muJjq+mZSqmOlRPI51FARhrsN9dTCbJTFMCRMUwX2W397k WTXbh31cHge3eg4fRTzyaVrqPNVl7wh3QB/RQ/zLwQX9AnAI7nRa0WqU8gfD v3kP38E0cXqjvsFv6fNpGCf7CuHxa4RMP8tv6PMwH00AupOynBX7a2v4GH4U 3+m+eW4NP1gb5tl9oddwhLUOTw3br4bwMkH5/maNAV8DNz+ZAMCL0ptG3ujz EP04W/Tu2oMH2Z+U06QDQK7KSZYDMHpK8fmfhXkZp1pdZbNJrNUrnUY6L2gh sJt9df3mSB3luoh0qt6ksNO8iMu5ysbqWo8maZZkN3OGjWDX9RvzPH1clLnW sJsTnUwnWVL+ET7oq/UBfTmCofZrj4+yCBZ11BusD3aeySdVWiL6faPzaZjy ZJpPaMqL7ye86l+XVS/iwfqR9jZ5OMnjoozDVB1Mi5//vSj8QUbmy1+H06LS RdEfZVP/ZZ3eqm9+/vc0yv7j38LUgea1rvIwObjRaam+mQ5Pavs9i3XRuwvT Hiysd5lNdO+qzMOf/02rHW/rZ1Uajya1ne8N9ga7j+58BIvq3wBtZTew8JRW EuJK+mHsrf16kk3DQh321dVoMgXic6s/OfhOnYTTYSW4bRb+QucJwDRX10Cm u95a/YfNYjcGg2ePH1PZL3j2X0/C+96Ex6mf0FlYlpMYlvrdz/9nksSFAOXJ KKj+Ub0I89tJWBXw1GkKB1pW5RLEfODh/1x07d+HmnfXQNUgzeDpEvaGjOrq +mh9E1hzinh6+fJw89nezr6q8pj/3N7Y3NqHbaVj/ntnc2sXni6TYn2DP9nd 2N5A/hXO5O+drXX+u5cNC53fafn82fYz+XyYZKPb+7iQb/bWN2WE3liXdBr4 6ebGpnxajmTsva09WE2UmUd2cOlZgTxIPtnd2abN9GZVMbGf7clAk2zWS+Jp XMo3z7ZwScMs57+frdvNbconWzsDEEZ3o6H9e53/7lmIwWew/CjK7Z8ET/zz tHfUd1ySloCj98JklsqS7N9BEKdj/2ReHF5srD/j3YD4mcaWAeI3m7v0TaFH cm57m5vy7ASkWymL29l5NmDpAhtPb3s8gzm5DQIM4GTeSwG75J3dve09hLKB 0uAZAR1XKlsc7O4IlPP4LhzNDfjwY5orj+Sjje0BvvsH+XMbZ9TRJBu1oAOr HsPbhHj1b4CXpcUsy0HipJEIbCD0BZ/6r8ZZmc2KHm5yGBf1ffbgE3lW+LCc UDiahMNE9xin4KX6B/AOKDS9WTjTOZDi+Wl/fdBfX9/aXtvcAShtbC448xyk IkhuAQz+jX8iPI6vrllVKMP8BhmBEcL39/f9eFT0q1Hc11G19ifQWpII1Ia1 WTUs1iJQinRe0o7XzFe/8z/tz6Ixj8w62gEqDqUelci61VU5T3ShQlCWyolW R7qIb1Jkca91iWpQbxgWGhSpbFzeg6bkv61ZmlnRTj9xCuC97KuXshT5mJnt ZTY3kqHxPfHbOo89DJMYMDSNw646ze9ANNCzEWgp+wr4P7NG2CYIPKQWs4LO xaR/1O+gMupBofvo6KwEMU2YsU6uz165o3jqMQCuod4jY1wcvfzcp9nr9YAN AwaHozIIridxAWQ1qqaoEER6DJuBE1WzHLB+lCW4J6XfAfKmN6huoo7+h4rg plbOLw7Pj47VYJXVdsCB4JCII4RRIl8tVhdmvBVUc1f7cJS60KzpT4FsQA0o gEhSNdQ0NyAJ6NfDOZgBq9evrnpXegRIE4lpgP9eraJKfj78PTyq6Gs8HVyu vwakjXGVBMfpXZxnKe4SF351eH55vKrKDCe7iyOtQPvP5zOYlLYoSzI71zhu MPLGjfRdPIIlxymhvtHrSb5PAFAwyWl2vdoPCN6gRkQJCEx4LM+iakQs5rn3 s+wgFphEXf90YAOgDdCag59+QlHy4YM9H6RLYAc0CBDcDJYPn5qjUkuOKmgc lYJxUcDAwFWBKGBOXa38Biaaw1keA3OzmDHvmbnULIxzBduahrMZTBKnsNww 8M/cAlgGqX0n6FDI0QMyHAEqqPX+Bp58qu9hI7hp0iFgeeb3zQ8fAuAS9zpJ FPz3iSiiFqMIDMosGwYdVqUKkyJTvIzN2jKMgkEL+RXpGFs78BLsWacF7MDu C+Cgb2gpeEKAVWNAwBSU+QQ+6yMqaBV6tAMKH8AC/gHkAgxAiAKnnMUGKAZH Tq6vL64ICtkEJgZsOYHDgTe6apLda3gEcCeeFgSBSM+SbE7IJjjso7eHz4GP z111PwHdH5ZUhUkyp8XDOgFgZCnjMLn+QwVLYzDGgvC00oAW2K/xCBjU0tI0 nON5A/qUeYz0jyub6inY8V01yxDOuMZqOiOmHJAekoRz+Hycg4wAI/6PuujC KsAmvpnMqrJLEEbbNB3NiefMcZYgS2Htk/AO4Az/SSM8/ts4yYbzEilkrIYZ 7Oby4Izevzw/c++qItF6RiBMMhBBEUhCMvzxtTKeaphzDMATQJX4WqphL4AH oJjA5hhMKNQi3GtW5bh5fDC4TbN7YM5ZVfbVa9wRfp9UhAUAi6KCEQuwosI8 zgBeVVGCyL/VQlkjUuMVgiVogQWXR9sO1VjfqwlYYYw/JYJsGJcqRxPeIMM0 vEnBvgAtH94j0MRwnKCtIDlmaeRDNubRC8Qw0Ar4gYJpwqlKTKBN5Qk+/f6/ ArYAAte+ewt0sPiLfdT/1HHU31cXiUay4Kdo2e05AeY6R9cOLTgHrA/hd9gu IeziFQkCwTHQoJYrA2yIDhe/NYR9T4nt0gqHGnAEeGA1NITcRwEAPAOMa5Vm JWIEoDuYlUD9TMpMP4wSdUJCuXJ4QXsgKurWydWjIkCCJCKeYRkDsU3iC8gf P3zo4zrgfXi9oGXUnuySrw2ZL+FWGN2FaYl8CzUf5M9jsApQg8M3wQSKbwAL 0CV3PwxHt7RU0LPCG8A9VgBBcE6n6DNgKIjot6PE6Sip0CIla66H5hzr5GOP sVpL78MHw4OAMu5AjUSYXYRwlmdgK4NgBCV7SpyytvuVQmsHgi5KA6Kq7Q8f Vr9i1xu8+y5GYuDhjWIAcAijKManAbkTQPIEh0eFHvjiV3BMvYp5M+46gDOp WMElHuHzcdjUeByP6BBxddZMQw1T9gQ8qRCeB1xKLVA5UEAAsd9lcfQwvtC+ YQn0H5g9m+Gnb45Aj9D9m363zpyXYwuOYb/8zZvTQ/7yDwA5QhUQiUl2z9tN 0EF6z25SI+5EnUMIsD0Av7B0ha386U9/UmFY3N0EovGaH7ACjq8PT8i2ReX3 e9Da1/ej4d7+/vrbtfrD9T9rfxHCImRAqAT/1KOff4LPv7fqylv4y3zhvrdf 82J69Z9+8J52rt43vuh9bb6gEeh75f0fvqYf+pJ/3gfvD5MYDu39L5uDvb9C r0fuf+8P9h7E9BhJWDAOx3JbkJ2LKtbeoq8VwjK+bMz9pQfF7/1n3+IXP6jl P2sPfts8J5m3pujKCsy39jvA3TXifmuIhmv9fp9XilgU/LSvvhjHN+Q+vov1 fQ992my3Pu+8CAsgPEJWzwbtfAhY25pmwAfjKToBgNcBzsGvqaUjeMuqopoE 8U8/tWb68GEfRCtxTjotoPaYWSTJ8DvdJHmkOdTdm1bVKMzhvxHJpzgNfASm 4WgSRf6wvA+rD0vvA7NQZAxsW8foBSJtwzyCdIrf84QoE0G9jZDKQ1qIrH8F jMw+GhtFWQ3x2xwV6AJHkx3lYEDh9PJnsWiHbDKANqWZiVhnS0HaDOrp/vEq Y8R0l6m13eXsCHioRpZphQ3MbNXSaoZe0nAayCI9uukHb2iVtJkaUyavhgNu ieOjCiEn66DI2p88LQCkqdEwc7ZX/WzrJAqM/cCf7Ozgt2xs0N+KAXV1fKju wE4AUYOn6MzX+nckbXh9U/Q2+WLErRBFyWvgzbzxEg1QCW2JwEKLFKMMKZhP 4zybwrsnXVAnUZtiCxJo1bwi/HqqAesiK7fJDwtHA0OBlIz6bOdOQlJ4AVNT MHTJagZtnM9Ae7xXlNFhFs0RAHS+VWGeuzi/upb5QIMFZQ2WCiafPfICkV7k tFNj6KjckRCBGupCOKAwx7e/OTaD94OTxxY31YDW/P49Koyk35Har98B4Enw 7WyhkyFDgjfi/p50NYBnjopsgI55Yj6JfmfMQyNFSYkHFAGM6PJZeWKX1rFA e4KdGvxcoEj1kfs5fzBNB7bZHdqiGMl8vvyH2eYt2DYY2yxU5+zN1XWny/9V r8/p98tjIM/L4yP8/erk4NUr+0sgT1ydnL95deR+c28enp+dHb8+4pfhU1X7 KOgAdXTYBumcX1yfnr8+eNXhE/HdKOh0ZC0bbe58lmu0KsMiAK19lMdDNjFf HF78v/+1vgUg+gdQ3DfW15+RrfIPFFHY3RLGwrORCcV/ksWGno0wx1HgOADZ ZnEZon4J2FqA0Z0qYHzAYIJffI+QAePll8PRbH3ra/kAN1z70MCs9iHBrP1J 62UG4oKPFkxjoVn7vAHp+noPflv728Dd+/CXv8IonOqt7/3qa0CuA8c4gTCE VTHl4xegzbpYevvwYuSXSYIHpjooWHmwDp5oFI/JrCtjtD1iYU8hMLawQElP uQTyfIOvhuit0DFJpLAQmUcyzog1JwrbIk8ElB9HQUI6YHHWkhhOGGlxkYB8 7hhZpNqyqMOTI49LdONJbz8ID6v5dxBUoZUmbA04r11YtuWYKA0iBxQbexg7 sB7FsM7pwpom3cezFTHn+PETzpS4LWpGbK8HTY2heeYySUe8Ygh1TEZw0owM 8I4RL3ig7DqNWE1reAP6AX1Uj2EBiAw7EBbeedw9iNkYqx3YDAjcP7LAuNTA XwB27Gun8Agi57Vhxis40mpNAYUV4ocoHxHERQXcA+xXCiQQYyePT2u/BP6G 0mcUgXMOlSIrCodxAuofuiTaYHFRVWcMr/c3BJlnYV6yShOWXaSvMAJ0B11A 54hqnQR+JY8SD5EXcEI+QlmkKJorgU133FsftTJGJzgfdMIQFYCUtdpKgwrY rjHS05CegU7GLkQlXoHFk24xOCzmgZibhfMkC6MOSx4U/R3a0jLk8wWuG5iG tZpXl/WaRfIbdoSKBI7OrOWRZbCsqyivpMwyWhJQbJjALl4COg11ia5JwNqI j2TeNWqMfhei3lEsoFlULuI0BEYg84orzfodRqQD4AJY5hEyT2DECBjBFCgh r5GG8pzz8Fw1DdMeL0lQPyzJQ0VGDNAJDGC1IJLqNPtIA1+OPNc2uVpxEaRl Ge5j126G4AkaJ0U2BwDpSidyRoDcbGmxDQ626E9fFHq0D2DpMfbCf+ThD8tV pSD4bhInxCBgZXSeAEVARsckjQLns3SiOXjak8V4uEY3zTPAChqms9bBCMMt +qSNSu4U2gKAnwgGe5YJKqak+ZK/uSEcbDTXW05bhvSDiwwkLZ4Y0xLbpgUF Ogh/2A85RFdyikdIcY4b8ZYzeN+kMXG6SzPNKcVBACrALd9cnlL0pcpj9kHV mPKiNw7ljRG+0Q1QkFZlhpJlVJ+9q9gBxlwqpNQ6t9coBuQq0QFnhEUekUF6 cniB67jMKiSigwjAUAK5EpEYIBAu5WKmgvE0QjOVgsYRRcfDUrz+qEwUFLOL cmK6i5eqSEskrXOIhgVoV6LqgMZQ4GC8ajjkL75QR3ZCML0tjK7nM03kX1tP 64zF6w1Do3AEesHIXFxMmeeKtSGSkuHmXsUZxKvIotCbGpAHJD7YZ9qyxaYA Xu02dT/jmizqPk6ciLMR+0CyIHROS+PyIBYMOMixtDEGOm7AvMzR78PuK1bg 2MoHznOHiZCIwGIpM3E0Ack4cvXt4Qu3q0vheOSJuGzLYjLb8bhkFB2ZYURD ehGz32cFx11tD7xyeUmYjPlBHDcxmUIU0aCdROouDoFanW/F6F9yEKIRkHMX FlWlLsQNooa4snHj4EZ83DD5Gx7OXhqcVSuw59XAbOUixBgT6QUG92lhD1FL IXqYDZiacDcegxeK7r2iKJYNSL/WNxlq/EgXKwevLl6vqtMjiecC2yOPEDqv RbsgVmYmsulRzelgmPYoR94wrNmYMa2PgGiS/dh+kJgmPZ5NYKMYDDsCQyXW vRMQd1PUP8jFeX51rFaOj07OD+mUKY0J3lwhLYW+5fS/mH1YqI6OUC94wZJM AtqgQAgoDl+cA76YODecGJEnroNPnLQjDko/G2yD9kGZD0U1Q0ccx9fR3QCo i9rGIsRlTY6p4FLw3nEIANEVibM5TwwEgOFjCgtZtHL8BIgPQ2sYMhxlM83M yKP+fjMbQtQgGJhWgOkEOJH93khQOr9ihLAvgqY2ZpWv/hZG7sdKqAsVSdDv k/rYzhdmdYRFeWIUSyuZ0ZAlUHhQ4QAQjMzrYoIp+s3NOVZHKEURR58YDfaZ 4E/tbbNIUArhM1QJUKcOjAXZuwuTClOw7kZEqP9Fzy0DBHwkNyJnRJCqgxAQ dQ72xTLCjesPggx0iNpYt276TUjqCxqh4QIcKCdzjlyT/mZEL5HhydmomWFV M45oF/rGRrNIGRxSNFyz6iNsuybDVmS0nry62g005pUAPFAnQscljLXe29je Vtmo1MiKQNM8ePH6JR4xpqd++LDPAYXGUOq5Wv8FvHd+eH18TQ80nacmcYEZ S6LTGywbGCtaQXM01JZKDjz4i8FIpngKML2A4u0CBEeeoWGmkXN2to+JOABZ BZOqQA9Q4GuThmaWgVJOp6a3i+pMOIUb8+YkfxQujVweIWwTTEgSHGQqrvz0 E/B1jHa8Uwf9dY/8VjHBYIAsBT3VTTARtTT0XUWgloWxeBu03gMFmsMXqdLT GTA3XAYPxm5hQU3J3TDQ6HTFpvqho4CMMUcOmT4wgOYE9MofQR/rjUG/D2I0 nqYGUmRxmzFR6PTiiEZB7w/+7Z8SyLs5AsgwqN3+eh1CchT3oJf2akeAM7gz oC0VTC0OoAbvOQGEsAwPdRy/sykHcU4hCpz+zuIt2WbihqLX+sF3mpwzEinw vqrhOz973fjEmhWYt0rWOSlAlirJDgjlFeZalD5GIxW6/QXbm7Bn9K2xigJY TMPgNAa83+ILZhB+jzRqME5HJcB9HNOGGi98xRErttpb3zLzTHAujGhQ4ho5 alqLdHiKzF0bWn4yP3sq9rehY/C/vnA5kUE78CN4VRXGP4tEYsIVSsI1LdTF 9LUQQ2JimAZg8GeRUb3YDs8NJcDw9k3LtsDqn3G4iowMj2v+UeeZMmEOhPNB QSyRfBqLOGpMKG62SCvY2BKUN/a0DosYZaw4WHKTlWg4YdDwVGCQ7vK0sFYl gnsaFlR5RYuo4bjdFSpkqtTvMCSV47PT8PcIA7ReNoOVHwfvdgY/Eoml/Krz RA2znEj+ZZUjCiINL1k82S6c+VWTbqRtvMnjHmXFGMN0OA+MbtNeuIXBOR/G kU7KkCAoH7yyx9Km4dp8gfGsWeujnLS5OtEushJyA8hShmB0YHydj259w3Cr Fc9J1w0Ml9zsrxOcXsW3muk0tqZg63hD9ebylA4YRDzLA+IUcJqcEfbIeSLd WXEApJNqR8Kgp005YgazAfJg+MzI7ta+ActdsiWrRuK4+j0m800x4QrpiHaQ MA7CvBGlbnKSoMnzoewrfL6YhcxAmQ3LzJrKUzRxApiyylN5kdR5eBVT5ozW gRlFxrdkVLmh2Kjsbkibyv9xLV/anHojBE6s1oQTiK+RY0o82hXleNL4Po81 GWFk+hjpxpzQvkdexOQG0xsmU6u/Wr9XLAKYfBZddZOxDcP+DaJ1g53GeRmb xDw+V2DdszzG4ed9cp3QS1U+ywoT6yfWJCtobZwWUFRTlkpDNp16DCWwCgWl LS43pH1PGd27wXCd2PdPCibrUCVmtxGmWWAa04kMde0EarZ4HytPxsJxYNjH Bj16bFTP8MaxD9K5pIN45oQxtth+dEkixCfEVqQdL7EXe4osCY25CuJijrBQ zSlhZvESD0UmAbSTCna7/D4/GEWJuOx2p9gYLp+sL0wDlqxFtbK+qg6QKA7g B+iDDj4bxaSRWAYiwTVKw0HuhuTJ9rV9xNCXzVREv+BqV61srKpOPLvbmgAr o/Ag/rXDfzmacWTUGMd5jlbJKbmyucoPn17cbeEH8N8dAy9dONKIx0To1qtj UzjgEFE5HAMDx4zPrqRIErwxa2XocosM+P39y1l6xqbhMS1X1qKTJbxoHqtB QO9QiX7w4Sb9dHFnIuVxM+eeqif8Fz0HYZWUPJksmHDeoqbxIdP55fomzCPJ CWql0WDiLg20vbO3xUo7kSsCH3OeWt91LKYt8hKkmSLebtLOWaBwTpWEx6xD VKg5RH01HsUZGII+3MWpi6ndwMhuEMScVgRkkLBCYbM4OfQD3NTxLZTRlnHR mFNYLMDBiFTSio1ZTKuVmMxCPw7v2gWUyKPbCkeRkwTWx8vDwRq6Dg8TGp88 6YX4TuHVOsACMSPkHR0u2ogozUosUuF6I5T2aaqTLozFlkuFS9DsiLoP8zyk QNTcPwqDrQYpQef4slATMPFTNjklq9BhK/ofK/gX1AfBlaNsCivj5P+Vg6PX qxwczIYlBz6MEEO/My/NH+wRMls8VKh+/B3whx852A+jrgB9HCRxWJxhPpKQ fdfYJwvmcA/zRKsWfwUVMQdLo8taYwI0SshkzvmPZWkz72hE2DuCX4JuBIZT 621TK1evKcTjymvwgDCw6Y/FGHGCrhVBAfgfaXc2fQF7POT8mWa73WAGqe6+ Or3EuSKsJGxinz0P4Igs/T0+1XeifZEqRIh+H85NdLPgGAuFsrvOLPOP1MxG tILso6YiwfLHFSUaoG4iqWDCEwCRSR7EvB6g2xmoSaUtY6jSXEvRalf8GEbf Ap0ZC4PbsusB3dA9nCLZTeKbCcljE0YQbYv9Dka0NBSlgpy364T2TZ3pgN0d zhMbPaQtIuXWlBpB1DF1/njY3xt88cUX6ljC5VylQkUlvYl+97b5t1etcmXz JtNqOpREXIdZ96F4uQuMuaDLVHSPmAntHlN5KXWQa1k53gUPwDTqx/FYDcIf gXRTZYLuO9sbzwZfOWFIJdYloYrKqagRRvWVsFXlCl+46JdkGcO+r160ClrA yjMVOFxWY5Zhz/qBJIBMCovhqXGMqhcrt3b7QNKnB68PrACw62hW/cSUroL1 JrOJ1F4hPyGcAIs7xlCXkEwtY8FliYw54cuLgZftMLvVQfmRJMtuiyCJRWFg W4NieksYRixuYSy52eK6K4GXGgzgfz/W8xVW97ki4rKx6BX7NWfRD7bU9ljt bKkdrXY31WAXzl3t7qmddbUTqd2B2hnhJ4NNtTNWuxvy1s4uT6q26N/Buvw5 2FEbe/jLujafw4tb5q0nTWEHNyvkweFF+Iqe8Xa9ZJP1pBC7WZRTfclUwb41 faXWt3d3gJ+95iNeV40n1IpXx4BWyPNRZkMOq0HDv9bIuMCcYiRJsbijvjrB LA7yqd9nLmXmnpI76ufuPH/BjHz6gD53cHCk8OhZOcEy97wAHtxZw1A2zu1U 77SBVDJVsGJRaK+NQlt8WHxMP/6dEGigtrfx342NvwkC1fb8VyOTUnvbn4hM z+FZRKgrWx7p8KMWa+mspWtw3I+d5DpuCf79+53kjtoZ/m1P0u35rz/Jna3N Tz3JtEsnaQKgRiZgUofNYa5Xp3SR8CcSfcXwkWUDaA+Psp5+Fxfl3+cYQV2K 6BiHn/sYd+gY99Smd574+a78uwHvDtXm2MxldrQbfVYJoLY2nn3UUU82u3Ta dGDP1376FXpHfKHA1WJnYvkeS4uCJUl+LEM6XqEn8vOe2M0dTFsrQQz0XnKE RZlEwpF8LjlQQbP476GfpW07SKdtzBi7FDnDiEx5fzDVURxKVtXSHbAHE9+b pqB0pQCb7e1N9Zc//6sr6DQuCNHfTJQLyETyHbyZYpeZERb15Iwd0uql0MsW oHGosdaXo57iSdSY9uDXHkZJTTTLJXa+wHp+zz9LJbherZWx2SQdDPTJgryZ pXQxEG/s0864meHB3gebqNHsn8Hu61qjD9MRBcNAZL6ZsYparveCILbnyuR5 KEsNLC50wqOfp+6aolQxVLW9vD7QZsgPx944Wg8Cu7BtDHxzk+uYeCoww96k CXoBjStP5zliXHhLfkUwaiO0qrt1ZZtijpcEk+dqq4t5TafTmVcJCODHlVt1 nQI6XJlg87oZppzaUjpPjQ3LsyVJPPynn5D8cLSekdBsQuIZ/EbKpUx13qUJ KVi6FSv6YYI1CfqCboyuRR2XbW0FhZMkXF+rV7aNcWqFafQIF9s1q+yMNWvq 1uzqxe1tnNbYU3A0Ai3UGOfk8iMjVxxJc/azCwnU/IpEHJb0zKlg8jQZuLQ8 KydzncSSam6sKkPD3KLCZo2yM+oQk1+BiJAQzfZXZSIyyKWRp5dOxnYZnZ7t i9NKxefUSUkkQ0RG3yhZ8gIjxbSL+do6tYW59dCHQVw/umVAathQuzbQdx9b P9BBK7/M5adtSvqHf7TdhcciQ9M0hoeZc/RS95oSwfhJl6WS4StVYVs+1N5d zgRXuK1MGcZYAMeOmwWCjkgNAX8l+YcmZH0olZpMZgCpntRufmglsAs6F5J6 gumb2O/KpjXDOUxAc9Dkyx4oasFDKCXniQPbPNnQouy7OTzXyzFjdVUqtzHI bZx45HzzS7WZ+8hoGjsoCky54U9h8iu026DuYfacH9LmE64Vh6w6Bibtp8hz O62SMp4l9TXYYKBZHHah6NpKY1dlzJygS9Yr0FBFKRVU50MeoiSrlezwUUh9 LvXUcfULkzCfIpfF9Rmva0wZbQMbFcH14rKETYeFrdjg6Ypsqtls1gkyj9OU fHJxWpRhW0QQbo+y2dwet3FqWXJrSggCPX1b99h56GW5P+NXy9pWcZJUWHJQ NmkirDeqKrPAFPl3aropKKUYFuzU9STMReiYvhY/+I0tfni71qH+KFz2T3RN 6FTTdp6uh5Dm+2gfjfpb+6TcrSyZY5XeYOHxlCcvpGKoZeS0rBTrP3D/c2aJ MSEeMk7U+oiHCuozL7EkvvpK9b7++oTYxC9/2QOmyH1Rf/Pm+PK3wL/KsKyK ffX6/Pjy8vwStJBoXw3cu+MkvIGv8+grfmNfrXfVweur744v95EODt5cn5xf nl7/lv86OjrlalkcxI0Cr17h5+rq+BD/axfX9EvYH0Ap+kG8ClhnubTF7E5r kU8esyqC4Im920jn8jmJezKbiQbaD+qd5pDTNF1aCySiiW+wus+JB2xsmwoj JGdTEgcvTkWyPbFfULOvQlPX57iqt+7HyCxoiMQnCz5miwJAbobA7ngTR6vp ZFbBYv0Ew5iSP9IPTmw/tySpVfIutmTCB3iGPcemhrxAbmPyhn2+qVSQxk8J TssnayspKEODpTqKaYrlF56J1mZXEUmrwxP4JzHdVLiXAeAXmSCF5fqg9JMq /oE0dL8FjlmSLQ4vKjiOguynMRwtmmFyJGystJUNm7qRskVx2q7hQ6lUb/th dOs8x5IlOi86vNriKjrEjf5gG0uPCVCr7lvcEcClMS4TSQp2sewEq5hr7wi6 YNE/HnZIdZv+vIENMJsKNGv4CVxN1BSnZoWejEKdUuiSMdcoMwEswObbNrtV mVM2Kjztx2sbZiY0Ft+CynhrS8RTDToc2A1tdBuazB3W7mtAdkmpM1jFLKfe AnzWUp5twbiQdZlywo3+u3fNwyGrIpRdqGyEfQWUrxwS8Iz6FI+lYuvdjBqh Ngw76hGA30sJD/VFrft86rzDlCi3+hOIIm0UXQNcHwCOivoNq3ZKbb5A62Vd GWPCsPsGwtkOqhW7BmxiNZ70JB7GlhG2RiZehNHDSD9pBlHHbW8IVLS6hKxO rbSK6QK6fxCkTzRakL9Yq+UldU3yDGBKitb5zRwbvVFesA7JUuhakw4zqKsZ 8bEVSp/BdGcxSqxenpEPCLvVrYp3BWPmubrBht1Y4J1RyXGYWmcIIAR6qv18 WVZh6e24rAnbSkwA3egnZPpXAjAT7Zk9ttEVCVIvwo352Jgu0irILzirsjmJ LKpZTJHrmwrGSea0sklYMBBMI1vbL1ZAiCd+fB3eSDIAO7r8JGLX/Q/bbu+w aPM7eBD+o2IEu7qpQkz20dqZWbxs7H5jXHee0kNhPMwTJZ3nKDvB2g50adam RW1AvBFFZZJiCEFscTZy21kUco2vMyWvr18VTecLETj5j7JxKQhecP9QTExj whuLsYTs0asJ99UiaVRr5yoq415RZ+G73sGNdsU/zVYLVG0E+gGsT5YX1OVr oWgdhJYoQLAvga29rWWU4xB1c3Exwxdrm/iE+GGKWvpea9E7A9uetJGDS6iw bf0uVlsDe9eM4vLJjFbbYlwExZJ4fRQthhttF6W9zZ2vOTZBPJoTboinLCWg 8CIQ2uIQJGJNRlVCqEIv29Ijl4pqy/poyb5O0siMqTWKyYC4xMniCWybcF3L s94PruTRBsAIWeq2OWBrnMZTQC88a+614O8Vt1dUQ2pSzikekvpMyGBgJA1K aq8KTkgiPvDOd9wo2SYVpjFxCVKkSafhOqTcxzXqFkURCyMAieSBS1j3ejLv mtQp4jXjBewM4VOz/Bt+O0+BsAX2tCEaUVrESn9s3lbJBgTmCBaCSQAt3KpZ DMKTYMX2l+EgUgPu05Bs6VT6AqMXWoJv6Feb6Vw16VdS2jkmAzzaxRFaGfGU 7pJxVQMO5+N1jXORg46OW3v8zes3YdopMtrUyKiOZ32K2BYTlN65FZWwjziT 7iSzJKxIyHl6Vkufd126Pb1AAhl4NlLiahRigmIkpENIDVwtso0m3JoNTTaI wyWkE5hGeAAYIzCuRH6ZFSJ4aMCd7mKnMAupYisPz+HIC75HbXuGFxeg89po Bx56EOvEIjrgtZzpF+mZ+L5NVC/Pfs9KaOQ177BzeDWVZPWJS7IuFGlZJu8O e91lqWmSJ4YPfc4UKmoc4EEj185Xsj7ad9fkPywLm+66gLL4eSUdm9xNTcAy rqIhYu6DHtgyqQrZCxJSmBb3GssqiZ48i0PS5K0Tbn1/AP/f2N/c3yIqQPLd fbaz94yU7QWGmyQRkCkoGuonOvEEEeHRvd31Z39Dn9kfQEEFXWGh52z9P89z 1vKe2bF48qeNRIfTGIkOZMGJSjCJZRtT5D+mEaivX6nX7yTTe8VEPjdXTUIo aMdAGX3KGXFNDYnTm9dZdawHwOuZwnXNgjtjOpYmiNX/bMj0RMw5Pjg6vnwI c/7l6Pzs4PT1w6iTh/85Ttc66BvYU3e8HthWOCZ+t8hltijSLeFte+5bq8jN /aC1acxh49p/+fO/Mg69IWluL155rrYFaTxUrWPM3/yEW7zhzcXRwfWxzxyu T88uHjrgv/p0L3/7V3CFJ7tqGgJY7BeWX8FSJ0rdIaG2+uvbauXNUrfDahAb Z/ki92jDz2NyyEmXyoLlflhTjd90G/HrzkfjljWcBy4ZTrCKFr987fTM99Tw jFDnLV2Ao1GntwUBXpIJu2wvj9VLuRngoQa0i/KwkEIuqmKCJGZV08K5gqX5 31MzrZaNJx1A8V64Dx/qXU1tq8M5d0Obp6NJnqVZVYCySM0K59ZTz9WFzZx0 1vYLz8Mf00NgzbJN6PJ70P+BjmfTTLhxF4vfNdLMYprPxEYnIk3sfjJf3m7O h1yzVSK1ZCxKWIO5cAHBFRiZBLQRkZBzs2K8OR45Zw5qNujsZLW9l5DFb7Sm woVKwDKjkpyS9eJFPswHG2BmHCCu97TDOszMM2DZgAhr8ZT7MOW267Jlv+sZ r7PB47kfgu9OVX6XSvKoG9+AM21wca2emq5vgp0SMYBMBGIeZdY+kRZ4MAMV TGmWVeayD0Te2rpqk+EE5szSO+7t7jJi8P0rO6Axl8id4nUx2elzcaAjldVu 4GGL69XrsmawgQcmQ5DzyK/ExUCQnoTJuN1mHfVkqfnQS0AYemjnzYZNyLnY iVvEBCtgJOt3yDGxJXlObkj6fYTQTpKa8cNT2H6WM4o9uuYEOy6Dxx4NAIAc fJlwPSE/asXlnY8cgo36SR1BN1jsu+fFLfCiyaB+rs+IfBt0ou5AU1Yt0qJ1 pujScHkh8AanXjU8Zzv9reZJkzvVTxnhevGhbTE5J2elK02CozL9Z7Kmadsl 5zYH4LD1c4buUNcMyWuxDFIKi8aQ9YI9iSOYKT3/Lov1iQkWrlCsZb5a87va FnumJ0UD9EZ8PtDIuc+KhDZO6pqmYKv7rIix3UkNSPDigPqIYkCbPbU6sLY0 koJqcRuaiGGPPvG7eJ/Xg8aRV61tdE3NabAQuTKC58Vx6u12PRjT3VvcNJ/I FWOPeBqga1Hkptlc1iQRh0i22EhKuUJYhiD7Rbjz4twdzAxYOzkzfHKO81E1 ZQWssJfhtDwqIiTNNRrh0os0TDE1cnwjLkTYs5AXoY6Jb9wwUFSQRQHiTLwI XrZz4W5ENFfwtdsONjGVjy/wu7kKKVCNMvAW0N7jYjI1cYcpVUSnoVf2KtPY m/NIvXtXeg38kFEvbeJHTR7r957Wem2HJpzJfu/sXhyo0iE8pPYwsgYvwIJi Oy5GFXYrCNpsj4/ZFcfXLlAQT6PsB6kCG6lRX70zqUZHSKGUzE4WKIqNlEmr /AGLqydWY98W7K2LPVpm9nDoAhpKPT8xLkiKaNJFGmXWwxBdjxIRv+La+VC6 0fp9CRs9+veDXEttKB1a7RqOFbZLTc7yh1XLujjGYl5c8ZKiTfwSHy6CBc3c 8c52ubpiqCkaC+d1F2NeykKE5uQFRGigmHvqZvMgYLA9tBnd+rjxAk4DBPNW aHuJULaS6KDuihnKIWilyL9JHTm9KUxCYOU+5QDQE6wPP38Hd4Askei9fqUj 7cxd+ujdh9U+zX7wnQzC116q2t1pXWzaOHex2rAs6co1LzMf6aYKPdfQKDON DgIJbRry+BIZHPqE1RQs9cRqfBJIQ49yKk8w5DwYEaTNXQj8iNzA6S5zlmao JPu9phHrXpCtL+2x2VbQtt0581V4G/uUHC1PtWlmCmOPE4xTARCEPg2owxuM mSAYxj2q85llMWhfpAEJFDF+YRoV2KuLZBEcxi4zbC8i/vMmRGp5tn1nStiA QlF7PJZoIVOHTMMToHpcKixzLtWGVAdKYyr/yj2ixts4JX26uR00ZmphdLqO oFpiVEtbUamxtq540vroNZyCEaIZnBcpYFPvTd49ZW61eqE0itoBk4n/EHLC w6YwqXeETIavXPGDaKEE1zHG4rnfAm4JsftsC1vrK9Mzxmi/OFNz2Y2ycpgl IPknTRvQNCkku/z4+qXJMMZsFNKBYRkj7pcDs8MfN+jWp9peXDipALCgAtYi 5eqp12+PDRXeNzKxAB2zIEgwIF5fJ10fUy9nwRz1KMul7zjnxwW4Rpir1jQO ZJIej9GRyJYOljXMxN4EPQDVk6ad5doKSkVzyD4l9PAksRTlIzjo8kjs6Z3l nk+BlmiAGBZ8fHRLqdcQFtRZw6zggQDwIkwyhoTtyN3CMVK0gMWbSyP7WDGI jKAIKIwV3cXS/tvBmSVDcyhUIdm9C5qtibaxJe1QqKs63IsDveasmmA7Zrzq l1UI7I6NF5DfgBI6M63v8fLzqGqUZbHJYqq3aGGk/CLoveuv8iplBRg4sXHo 0G2z5vIvao0ruhmxeIBTgPlheeywBZc2BlnAZpCdaxpKgYoFho4swRacODIl wAJcWYRXMxMo83BTdq1414G9kICkhtc3SxrVIYuG7XX69l6gjQHdC2QvdsX1 9JjBvF3y8QPXvXrUu+CyVUV+XJBrWlSjuJBL30e13hVkMsiYggDOCrO3xxaL FFzk7nw3Y1BTEY3R0H7J3SqqvvfbxdWJ3hKCcaXh/a6SZo2G/bwo9VRdnp5f v/3+BgUpVsXijbmvzO2kdJqgbOwH+5LgTM6n4FvNkUzsRQSDsa8SHyK21Yt1 Oeb2/CjG0cHILoz1TRg7HmmKP+6rV99cvOpt9NdJvSoxRcM7fnzgxzN0uMCJ X/WxdSQ1Af3llD/rJ/zBr8uqh8FQwOp+pL/+EWZAeccJCxZwjYGv9Ay2jqll G4ONLT4B7hX0qSdgjL36CQBTv5jDAOnb78M4A2CgUv43hPDZ6fXfH7i+3ecp 0csU4yD4hpvvmH7npq18XQUHUwPJbGN7w7veh/LhuBMy2V6H3HRfMruAj8el uTds8aiiITqmZhOVF+vRbHyJcbliDWlvSRtsANmbatp3z6/Yy+dr9wm7e+gb G2ymD+EOKSRonH2AMKj+FM4FGEtfkYZxjk0+xVluABKInk93K7haQuOHzPEW 7TwfgR7rBy1AJcbMEjKU770aT7poRHJlM8kvxCjE1CZJIQxs0yjKKmN3DELp DsFkgYP35wH8Mmx2rEst2UjmwU0HLrp52zRY4Yj11DRqajXY5lwcegiFEE25 uGNSLbezdjsgYpfcmu5y5myRl9sK5VeVvEE++jumckqiqbVV966opPepiz0h IO5CnILyQMt48IyaljmKlo3f4oytorBWFc+5VA2bfYGRhLJE8sdsIpi78MhF JfiLlqEU4P0eLrVglmVjAnPdNyLoK2nVoFlG8YhvN+NGimTpxNKYzbQnmzvR a25RRXhxVnARcGwTwRnVLCH2laSyQGlMCkM+DFC5FGsRg6ArTKQVIDzCfKLb 3gqcgjEsDRxckTEaCCHWH1L3ARmNmioz28kwT92/L4Ico3gbvB00TjH3ioQ+ Dq8jzxHGugF1qrWmF+qgfXJ6mHBZ18MWc+A2YdrcaszFm9Z/gURHSWF56hrj whN4+XlOiDbRjQtVbZIkYUKjTgAtAKxJug/95GInfQPUdD0/fo0yWjf4LnC2 1y908i8Ulmvp0G2OCXsumfthHw3VWPv4YFxOFEkS45+1dHKBelLJeEhNWULU isjhbsnqly4JrbeR9HxomI0TKIYZB3eXr97cxLT00naw28jGSNh3TU07uTiE 7bhsFgL2qFYwwEsJZIRDhEiwzYCkuRnw+ZcgcU555HZhDwkvLGaPEUCAOuvV 0SacG7vRVrPpnPp2t2477ga85YiXTRfposPXRcGxiBnL9Ny+6PtGJm5BLkyc ma7XskFjlw+9dAlfBeTwJezmdyn5mLrqRnWX+dI+xi9rtSphExpoMZvbwZgD svPIC2+Oci1ogUKWMTTmmO5NKh5wpZP4hvyHrZvEfTPOHiJ7HWRTNt+scd30 UC6WqVXqUQO/x7VHv2niO/h52/rAswJdj8KaCdjsRchdhV4e9v4FfhwTwWFc ccoiBxVdLmgtTBoGfQqtm3fMHdYu9TQcOScz7tyU5NWzYgp1qW9iQMr5w4ko Ar1aFoTzMyxu9XPq7nVZnvtDee0Bd+KRStdFy8TKUF5n19xXLs8+6W5U72Kw TmBGYs+Bu5u224jdCGU+ae2uyfMZtRbCq+a8RbtizIwj0qZqlx7cV0umcI8d 0tUX+woP4kgS5Irq5oZOYjUApieugX07CyHPD98brPvhbXdJXiDnKjVugyvc dXBPwY9H0ERSTLzE6FQq9QhmrevbFLVhX6n1A/Wg6WPAA2v33qCjZtlHLuG4 Vigws/O2O68uvWYTRcR79ZrJV73n9sDu57060yEpqg/8vFeHXC2I55wDdGCo 98oepnkK5hEAK/vbsg8W/Sx6qP0ZzbM+8BFLFmm6kdlV1xtE2fg4PfSenbLv F+LeYkjCzD/tqy9Ai8Ueuj06jt4tokAZl4l+3vnWBTl8nOh8QMz3b3dcycvn q+oVXhl5za2hD+x9jzLIRyH0wp8gUEvRnE3Rpy/KXR9pqeFjd7SEMD6BNbbo JaAZ9pVZJLAKF8jYX4IG/Ro7ejoWBMG5ad5AbpunuHlIXn/xBTzNXQ2NU9qV 3dbq7100FkPs6bwRolWs+vNQRr/0c39MDayv1Hu9wezHYl4RKy7FCZOhX6H2 FHVrtPy6q/zOazUtmTrSzPI4HWHHna6/Yg3qUEbVe9IkHkfJ+PJFq8pLldCQ blDjq2hoSD8rsxjpNMzjrOg2jpWTvswVP5KyZ2/bYJ7KPZNtPIoLPY1zYGb9 1t79yBMd3uH9QVzhYy8O4GJfqbmLJW2LvOmJHtu6Kxc5yCkcA29JKETMXa/d VtNNzu5AThIuah2+8P3XWdpb1PXLu8EeQygage4hGZkeZHp6FdYNH4S3eRtC 06jhUvan6UPiXROOikVhbtpxwCXnGGrS6BXDKLGXT9WApr0lCAN8I+uXTPlC VekULKWTvCdpRAYMjFM9gE78K1C5qUJuvjTpSojIq/zxqKRkSuO0YXZoVHC5 RpsOmLMUxMwDZZlTsfj5VlFt/UMiU+M5d4fAZU7FwgZZZA8Ye1Hf0d0T/iwH S9qbE7a0aiEMACiXUZoi1hR354Uwj7IBKZkRxl1skBn96jWmZXKsraFv1sw1 2XUI4XldUL+wk2zWe4VXQAB3gyOnanou1kMA48y2uZi4DabkI0pJI8LrmrIZ GJ1vvFZt8Lgd1eT5mzTfCXxBN04AVRjvVyGXz/FIuLRjSnE0/VAwD6vR/ORD rdmbVNBmniiQZhuOi4FVJXUAJsPSzzJzneZ80qDeRFio0m/mVQPcI+msTamQ RI1esZvvpBJ3s2eFc04v+S8oPZ7gHXj9C1sOJuxuRmk5KSWZSn7+oxmcxm8j ixZoUOqoxB85mZSoi1rBh6Za8M4mkUre5KetACWGkK7XzaYrjBtjso3rZutl X9J1EuMqcq81zHGMzUDJe81miLZ/80pDj7Rsff4kiyUv0F2AY0SzRM73Nvao 4inXfI8BMzEjwTCkg/ofIVAQHHOaEuE25V9p+4GfefVYKM+kKzC7Rsu42wjl daUxQZjMC74hkLiv+E6DWYiZ2x0OdQEOk0lBd11XfoHNaXbd0L3wQmUYqUcD kGUidsWr7MbfgItqszswyW7eLvzwkwPdpvHm949EGPfePln/DnrqQCpVzX/P skmI0Z8XWTUKozDOvwRRTmGPay6yolfUcn3SxMLk4TO8akmuZbAx9pSdT3da HrpkCGBjkTQKXVBB2upStyTyvCwx5mujUM5KiK578qcDemib/JpVZSRtEowh yKm7eD24tz0Kl1hR+zK+6at1+fowCSmnxisX1sjsQx+PhDzDZNp4ixUDdwsX X246tRfwkQPr6OhyDS/+cafzTYa5wi/hOCYwafmlqWXpVTN1dHp1+Obqat9C YcweTJOUzcvLAPeogaKNGbb2QwZK6J3dhQmhyzXflLbv1UOY4uzGSMRdGun3 se0IgB/VOkFJbOCJ2L37Sdh9meGt7EcgfpL4vo3RgjlVStFkvHRod2vD4Yg3 0LcJYNb05/+bq//471X68//GowBkOTq9lMwhh0T0/M//LQfu+u08Hd3qL5vT nnF/CtcpGkB0MCy4Gwai66ncBuadifNgwBFfXR+tb/q1WbD09cHmduP8LOdX FMU19TLjZs9pVIEpUsELupJh3lBTEuxtDSdJ3mdqDCYF+DaxbqxsJYhtNGHu s+CBTqeoWmo7GXuX5cuT+WxCF/yChE1vRR8OMWsp4qbmWDWE9rR3GhchKBHf YcukvMCDYEpgo3TJCdtwHd9qCwaJtPOKqDSVqZD12vriLyY55Se3rpAn0URX qCHHTnUF55ck8wepdwFHpYS2Fa/0z8jkH428+HFVmJW7BodER5h4w3hc1ruB ji4rGGUd4nOEOfZuX9PJo4G4tGZYKWivxYNbabAfKV1uF57J9x7/AEmb2URg KxJUApKyQq7uZj3PYxAipdaJXgC8qszw1ZGNmTB3qvWzo0QHUTEpwkHdltCn 0hIeBiGw846HLmcHv60/6lYsHcu8a5a8BinDuRpx8j2e47OtHSNIXsbvMNOO i7NycovWGkN6+z/SQxApWaLn7e1/Q652cYu40/+swKktlVCwHR7HggsJjS8D aQdt2s5TOf3OR3F6w0sp9l641HkvNdy1Ekcq8/ks3boY8D4b11eNa432jLvW Sj5RcMzn/t3tjkrxQmeJKmLbx6cCYPuTRN036GzibR3kZUg2NQomn9fAyZUZ anbEdEyFMpyWoOnuxsaepyLFYp3k4xF+M8QKQ7o7Dt9jTVXq7z19tcFPUAXJ mZsY7OBOytQsDJOvepx3Hg6HuOAa0yBt3b+rcyFzq3HBUHJZsOj53jXAYeeA S/lZQaLc2dzaXfXetj1lmLgNGBb0m/NpFKMlKBdq992SN5vSd5vnICizj/Wx eaOMvaFYXWpyKi3GTEpT9tAOuJC9lkbex4oAk+VN1P4ldqHguFFTnMkrx1If i35EZtLkjuDkMTyB5xTQibK+vEDeG++SzH31nf5STEScaOFNoB74ros7xNVL X4m6INirg6PXXNAjtz1+JVtAaHAh6y8m2f0vpLa90OVTCWzrowhM2FlRYWpA UhmfkWNvwDdnpGHjVqlPonTltCLWM7eOPHSwY6Pm+WzrGTIwup8yisObFEsn RghHU8NptFLSubPL45614ms1Yb2vud5s4bf+rFFWDRMf0WHtLw4v1AZ1C2pw /7SmYojc8m6qZKCIOQXcEScQzPQrNTwNktyK156RUlgDEpdIcSqrZW7jw52P ai/RCawdKt3iJEDZrgxyIn1R0U/g69QIVe43IPevcpU2fHB69HzgHJvklHEr WHJXpW8QMw/yYqns77k8pu9M7i1Iluk0zLvmZLoigTXXwY4SHaaYvP9EUtj8 JFlTTDQo7XTFIpHtEyfb+KTJjovb7MvCTOU+PwvzUVYs/Ca+zZIwdl89cX2D j+QLfClmPMWrb7CbCuaM5Rl6SgGrC8vw4+L3VQoax/Ov8XdQCUelfFWl2l6l SkgMjyzAPnzURp6wlg+f81PE6slssLaLitpBNSLztbtvC1MqGoN0O3otWtAw p7xNtBxz9PG4ijGrYPZALcVYUM3BQGL5AVenSOsFTT47QZ3TsH3Y8CMEDS8D +pPPZ9gbHPSQOfbiGLh2q6ZbDa4JVAs/5SelSh/jbeKWS0BREdKf2SrdUDsy KZbkBajNLf6LNWz96pXtkoRsF3wiWt5lcWTqSGFqiaQh+NRf/vw/6gF/d5vX X/78PxHWXArdbCvIbQNjr5ERampMA6rewcmw4TLz1VfDT4zVpUYTPboFRbV4 Ku8YPPsochEDsakquW8wVaiHSlHTAVOXUF6frO8pEr6xvrnzw9u3K5OypBsw 8IIUVPFvdd7HtWNPqDXQPNYm5TRZA10WX1jtiv4lh8o6hLQn4GY+Vm3UkazD JHu36xP2a2Rbw3Iqe2aHxxPh+nGOXIHFoU5vgeEdjMdxwkr0U6f7NM8aK7jU 54eZrPoCwLq3s7vn1uRbyt4JcrMQE+6mO/ssRgik6RYoybEnfd1HiatlZ3BB F1zD/zOHTD32dgXkhWqXy+6bteI70pxCkv+fCr+Ps1dxd97twUgNhhQ8bo3L RQCP43dkDfwTOeMwTDnKkmqaUp8K6XF8nAMAQrX1bHtrlR5tkQzaOntbe1sc WVvsS1cuy44GwekRq5FCCp2MfQnwRMB8tB3ra5ikRycac9AJSugYp5JbbhBB VbhPXcjH6fvWKUc5ssAWiYmaxh6WABj36ZQ+SssYfKTKxcnbNZcw677UUsvk lFd4J7ptYORnoWgvQUl2x/FiLyL3Affq/n7qTj5GnwvEJmgU4sm1KnjcC+mT PaOuJRbtnCvMqJJ3lRQxyXH3bnqG8W41mGU2KMNyE1TXaZgkxETKZnbtQ9QB 421vb+J7gov7vB10qUq7JpN2ZSMt2LAG1HF46vrFkatxB2FwfmFanBg9HxST pp7h9cygcJHVHd1zzYYZ3iu+XK1X0qV1WUVawxEZ1iPs4izFKwBO7Fii6UoD 0VGDpyLG+schxhVZqvNaDyW84SDmGFthO384hdMDQr2QQwLAoig0Oixhbo8x rCUSZePdQhvYJUvOz/V4cddM2oZO1Pv/UF6ilkURKLG+ptxA9afC7mOMEMLH bxAIB1eHp6eAJqWhM28THVdF24jZdtQKlu55PfJXTbc6dMnRSkEarMiapfiU VjxKi7ernhXEcZu7OEvCRvyVzNjz18K07McA/3E4smBfVvfJdnUDeP5CPoXP B9atYzoyKulR8MD4QfCFOhihszLR0Q3z05/2q5TLDXQkraqXZjNg7yjp/5be oo2K2dXAxGdddRjmmGipXiAjStNuOxrf9WIB3XY0sluPdHbVcXI/h/H68AnI pqJLVjQYE7+/7TZjOV11PYGXC/UyA15Xxl1jP6tvfv73shgBDcAjGRzSCVga +Ot0OqcQHKzkn2FSmhoW/QJ2cDWa3AMW/rHrx266bKur6zjJRmG3FhyF8eKp +i4exWlxG7M3ww/vmYIHag4hnQ/Y/TalI+gHweOJEfvqacbBYwM9OtXu55pq 99Gpdj7XVDuPTrX9uabafnSqrc811dajU21+rqk2H51q43NNtfHoVIPPNdXg sanA/v88Uw2ePTrV5yLhwaMkPPhcJDx4lIQHn4uEB4+S8OBzkfDgURIefC4S HjxKwoPPRcKDR0l48LlIePAoCYP2/JmmWn90qs/FLQaWWzR1xCeMv/DFtUUD /hVYtmyYwOuw442Yjfp5nJW9rKDBqHjnd79Ldfm73/Hz+EIfxw/8DjJuhBvQ dqthH9SUtTDNe8PpcNybxXdZueYeD/4/qHEquyTRAAA=H4sIANfmuWkAA7192XLj2JXgO77iWhXRJXUTFLUvtdhKSVlSO5VKS8wqO9IV NkhckrBAgAZAKVlZ6feJmH/omYh5nT/w01R/2JztLgBISVVOW2FnSSBxl7Nv 99wwDIMqqVJ9rNbOXt+q/F4X6jQ/eaPWz/LTjbUgGgwKfX+s4K8gzodZNIWv xkU0qsJEV6NwmBc6jLMyxDfhr2gWbveCbD4d6OJYHR3t7QTJDH6rinlZbfd6 R73tII2y8bHSWTDMs1Jn5bykz3WQD8o81ZUuj4P5LI7ol1lyrN5V+bCjysW0 0KMSfsmLCn/7PhjCd8Z5sThWZRUH5XwwTcoyybNqMYNlXp73Xwaw9p0gwMGO 1XZvez/s7QRRoaNj9d1lP3jIi7txkc9nx7Drm/PgTi/gUXwcKBXyE/7l5A39 AiAKgmheTfICvhIqxfC4iooqybS6zWeTRKtXOot1UcIbSuUFbLX/9kydFbqM dabeZglAqkyqhcpHqq+HkyxP8/GCvm2g3X9rvk+PS9iuro7VhU6nkzytfoAH XbXVow+HMNRx7evDPIZFnYW9rd7+kTyZZxWC6RtdTKOMJ9PTKEmP1ZQX3015 1b+p5mHMg3Vj7W3ydFIkZZVEmTqZlj/9vSz9QYbmw99E03Kuy7I7zKf+yzq7 U9/89Pcszv/7v6LMgea1nhdRejLWWaW+mQ4uavu9SnQZ3kdZCAsLb/KJDm+r Ivrpv7Ta97Z+Nc+S4aS288PeYe/gyZ0PYVHd8RzWNIaFZ7SSCFfSjRJv7f1J Po1KddpVt8PJNIkrt/qLk+/URTQdzItxbeEvdJECTAvVzwt14K3V/7JZLHLF 02iquiXP/ptJ9BBOeJw6hq6iqpoksNTvfvo/kzQpBSjPJkH1b+pFVNxNojlw pbrMAKHVvFpBmI98+Z9Lrt2HSPPuGqQaZDl8u4K9Ifve9s+2dkBUZUinNy9P d44O94/VvEj4z73tnd1j2FY24r/3d3YP4NtVWm5t85OD7b1toBGQaPL3/u4W /x2CnNLFvZbnR3tH8nyQ5sO7h6SUTw63dmSEcKQrwgY+3dnekafVUMY+3D2E 1cS5+co+Lj0vUbjKk4P9PdpMOJuXE/vsUAaa5LMwTaZJJZ8c7eKSBnnBfx9t 2c3tyJPd/R4IzfvhwP69xX+HFmLwDJYfx4X9k+CJf765OQ/x0RGAiJAjOuRr +kMBy2h1MpulCQhoEMfhq2gBzPCmyEGQ5ykw/TgHYYEfqfWTV29eb6jLM3U7 08NkJK+oEXBOBcOcgo4Apgduiv0h3WDrKJ03WHOd9V/d8nqiYowkOKmqWXm8 ufnw8NAtRsNQx0mVF11gic0kG+Wb8Aw3wWSrC5A3+PhYtgFbPKa92u8odXZ9 eQy03N062D082PQAQZ+zngF9MJyQtmHmMQqDfkL5r1JJBorvCsRKt6YyaC3z gnm6+cFonqZPKp3WJCC7fKFdm6H5gZthucRvDd7vNmVjbfzmB2785YJ1GYTq Aq02fPsjH0QtgRggfj0x8eL0zfbWEbNWBdImsdoYP9k5oE9KPRQhcrizI9+d gA1RCafs7x/1kBPBFAKxfxfyDEaMbBOXIhWHGYg6eefgcO8QWd6wbO+IJAAy qfBb72BfWL5I7qPhwvAyPqa5ilgebe/18N2/yp97OKOOJzmu+jI86zpLDVY9 YkKMk3KWRiBjT28uW18DhsvKGZhZYZLFwnGN1/o3J69v31zf9MPL12f+AAnw 5awMcd+DpGy8JQCBD1pzDqPhREeDVIcs+JrLPDm9OD958eo8vL49vb45Vwo+ B6s0nEUzLczV5mDLrVu7e5s7+wDk7R1fYH1+q4egE7Kxeg0Uo240GKBzki9J RuLnMu8fq5pl/HmLp8OmGdjk55WMLqrZqMNOTeGFjxpeqzibhnybRaNRkoKI 1XFHfZvoLIs66gRM8CKJ6oM7w2wsdpkbufmcbZ559KATZzYAxDtigy1fP0pD gObr6KEA9Zg0YNJ4/CyIrBIcRhzVnzYttY77Zflyl1pRq4VRY8nq36Lp7Itl xlFn+a5YZ3wO6mIn7B2F24dMYcCpIDUqMEePUdkNNeiubFyiyYaEeXJ6pYBM X+sKfRj4pKPu8xTMrI7KcpDI+evz3/e3O2o2g2fh9l6b3/ICHLY0KpqMBjQe AofdhKevTm5QpJzf9o9XatVkWHbnw6Sr4/nm30aJTnGVm7P5oNyEIYEjK5Ie m+ajP/lPu7N45LPjCejNpNLDCk1xdVstUl2qKItpx2fA2uMM9y+bDgdRCVbB bT6qHsCl89/W5RLNSwi86aqXshR5zGi/yReGrhqfC0f5NvNplCYg5LMEuOqy uAem9zAJ9nyviUEZau3NpHvWVWceCDpPDr1GL7NOMQNd9K9eOTw8FwcgmLuT aipjvDl7+alRGYYh2NRorw2rIPjyV2H4DiwsHX+vXv4BBPF3WrFfH6t3TWIE KxZ1Xxils+x7VeXqnWdbfR+gOZjlD10c4yFJU3Bb7zSRxSjJgFYkXoBiG975 /dUrtQ4b6XYACVMQ3QB5GG1towtL/DoI+pOkBIU5nE/R74w1jIGEpmbGqMTp 9PvhJMrGqBxQAfx1TtpFrV+/Ob0+O1c9sTlhDcEzjdQuGsal5gDLFLxk8DZL NQTJPtA0N9CujoPBQq2fbYApG5J2gjHpBVjS9eAv8BXFSgvoBZfpz42sCuZP cJ7dJ0We4e5wwaQwNxCoMMl9Emuls2GxmCEicGuyFLNjjeMGQ2/cWN8nQ4Yu KUUg6iLTFbmPE5JK66AoAbpEASB74xT8MfhakcfzIYIi+Mr7WYWAJRGojo8V 2ADIU1pz8OEDeiofP1q8oJgA6USDAP/PMLZUWhSt8iOCph8B4yIxwsDzElFv sK3WfwcTLQCH52CoWIpYhGYuNYuSQsG2ptFsBpMkGSw3CnxcWwDLILXPhAxK QTkQASgIMPSmAyBwoiaANjo4aqu7jcSQ6QfYG8KBvFZYsfl95+PHjuJv7tS+ abxO+u6vyfHc3ccvP5+21HLagsHZbIOhYd8Y1QOJbPYGsNBjGhWxBJQ1AiLM wKZJ4VkXyUGryOMbUJsAD/gHt5yfIlRBeM8SAYylk4t+/80tEsoFrQAc6I8f u8FF/qDh0w69GiXTkvYS61maL4jehIx9CvdIOvBJuqMeJmDZwIrmUZouaO2w TNj6Q1JNaJhC/3UOK2OAJELztNCA1tetiQcY1LLTNFogyoGCwC5D1seVTUFg FQtQ3DkiDdc4n85IUwTkXKTkS48KtFfL5Ae0vsAZyefjyQxNDARwCqIwGy5I 3CxwliDPYO2TCARhBP/JYkTkXZLmgwUKTYDyIIfd3Jxc0fs311fuXVWmWs8I hGkOSjEG3YzLYUskmWqYcwTAE0BV+FoGxgqSAWhA2ByDCdVsjHvN5wVuHr8Y 3IFMB42Rz6suW+BFzQIv5zBiOdRZVCQ5wAsMWDBC7rQw15ACRcqBJfDAgsuj bUdqpB/UZJ7FTD4VgmyQVKowGgOXN43GGRhpsQ7gPQJNAugE1wI5Ms9iH7IJ j14ilYHu4S+UzGDOzyMmW+EWIZmCfAS+A28AFFuF0AJSALMUGIOpnGmLwVUn MhS7p29oQURhnTopexQGAEpjYifLMyRCiFlQVuBCYB1opxRRScuofZOYKEDZ RHCP4vsoq5Cl0VRB8TUCNxjtLXxzmlTJGCCECYKHQTS8o6WCYo7GgBc210Cv TKfoLbDVIBrRjpJkwxSQoNa3NhSF00KMpylySEeeELOhNpReTHlAOPdg9yHY 3kRAzVdgk4PqAI9ySnKkBoD1UmsHhQ6KPSK6vY8fgefXtzc46A/vvycHh6cw 6hPAEcVxgm8A/lOggxSnQBeWLHHEzPrOBmBtzkIMYRAAhuZsnBI3+QIP9gcO 25BexIXaKAUaiLI94N5SpAPws1qin1GSAlvc50n8OPUQCGAJ9B+YPZ/h07dn oHR1dwxWU02MraYdHMN++Lu3l6f84V8JiCR90zR/4O2myXhSgecI/1q9IDYP QoBtefiFNQps5W9/+5uKovLe2OHmBwz48/7pBUU+0XR9Bwb31nE8ODw+3vp+ s/7l+p/+X0S8CBcQvsF/hPTzH0q9s4r9e6XMY/upU/u8krD20w1+pE2rH+vP vzaP6XX6VHn/h4/phz6knx+DH09TcNqrH7+sj/TjLcadC/9Tf6QfQY2NkI2F zmAgu3bZr9gqrZ35VhOs4PP6vJ87wL3zv/k9Pv+jWvWz+chnLbTwlDUTkOc2 n9mPgE43Se5tIsltdrtdWiLQS/DhWH02SsaUjbxP9ENIkVjyLr9aexGVwGKI Ct9TXPvI9sc0B/GXTDHqBSIODS/YomUYeMkaaJp004cPrYk+fjwGbUMCkxAE bJ2wZCS1dq+bvI3MhRZt08cYRgX8NyYbI8kCn1ZpOJpEURKi6MLqo8p7YBaK EoAd4KSieCepYPMlE1/nKVExg/UWI0NHtBTZgXhRkSqr+QA/LdA+LHE02VMB jgUuQP4sl+2RTWkwMTTLCxtfLEnFB5Fn+6MUMsZ9p2nqGSOvs1rygLjUKB2t loGZra02n2FyKpoGskiPWbrBW1olbaYmfyn44MBb4fgFWJOCWwdFG5whcmEA 0tTosDifpI7dOmeCDD/xJ7s6+QMI0TLnv1VUMnpuz0/VPVjPoFcQj86xq39G qoVXOMVckq8z3BpRb7wGQcxbr9A1K2u5GPTVMASZgX8wKvIpvHsBFDbE8JY4 V8Cs5h0Rz1MNpBdbhU0ZMMAOjAVvxbjNAVg6o4S8yLmAHt0nfg9+A3uVn2pP 7oq5NsjjBZuHABLCuBkCtP/1bV+GAUNvXjn0l8gAoqWdLUNoc+ghdjW8hhAx u/zm3AwLPsZTa5tqIHEDUQ2yGDaU5WwZc3QBEEFab38X3fE8JsuBdf0DmW0A b6DVEtEWaxJIqX5vnCijQsnWBWgCjXQYgJ7OpdUssaJgv4ZilxhUQA5B3+VC aDpwYe7RYwMQ1Vz5xg+L0jtwAbCMolRrV29v+2sd/q96fU2/35wDw96cn+Hv txcnr17ZXwL5xu3F9dtXZ+439+bp9dXV+eszfhmeqtqjYA34ZY3tr7XrN/3L 69cnr9YYL37AAaOFbHCjZ1rMCo3OV1QGYLYPi2TAntiL0zf/739t7QKIfgWu 8vbW1hGZ9L+i1O7Brogano08Df6THBuMAUQFjgLoAJKbgQxGOxOotZzkD5lC mgBA//s7hMz3x+rLwXC2tfu1PMAN1x4amNUeEszaT1ovMxCXPFoyjYVm7XkD 0vX1nvyh9reBu/fwy19jOYQKtw5//TUQ14kTpcAeIrpK5lBUp2CxijBhRNSR l6AETVNEmFpDZcuDrSFG42QE9E2hBZBniYirCARdVKLypyIn+X5D0kbo1AN6 dEJqirUgaT2j6JxybCtBUVl+DhEZ6YQVXEuHOPWkJZIAOnvNaCfV1k5rPDnK uFQ3vuntB+Fhzf41BFVk9Qu7Ai6+xZKprtnEkBC9oNjvw6A/ooGdVROEi+qC L6pZ1F1EsmhAJ5ifgVwSvmg23evACFffmGgiXyZZkyASgl+t+WqOXPE1o3YQ wRxtjNmGa3js3YAe1RO5ACsjF0SiPx0Xw9ox9P9AD//A2uNGg5gByHG4nNIb SKN9I5PXcaANFXmmKawPH6LWRACXcxAi4M5SLoDkOynA1m4J+A170NgH11y6 ghIpGiQpuLC6XAYUV+XifOOt7rbQ9CwqKrZ1oqqDbBbFQPVgIugCKW4thV8p /sJDFOVat0ZXliTK5kpg02vurZ+7MrWW5ZW1Wxr0z76N0ZuG6QxAcoqxfaEk LrB8nl2ex5IaKLhZtEjzKF5jnYOqf412sYrafFXrBqZhrQ3WYYtmmeYmK4JM kpiFyhPLYC03p6Rzlee0JGDRKOX4E46g30doWZQtZuQJMPwMLC4T0PheXGFI ah5nYrVGhDqBIWNg8SlQeVEje7LWNGhEMmQn82mUhcAksSVrYC4k7IGuMKTI HyUUJVY2rCtmFghs2IczhEix0+qGGkQzw2dBayP7yogbuyXzpsxbxxT5HwCk W50KjoCe2e9iJxzc0g+flXp4DOAKmWDhP/Llj6uNpCD4bpKkumYVzjBe5aSi Md18YU5sBt/2tDAi19imRQ5UQcOsba4F8MEdBm2Nbe4M2hJwkgoFe14KmqVk +VJAtqEWbALWW05be3SDNznoWEQk8xJ7qiUlAoiuOBg54OAeYB6xR7mAsYSU GcRvs4QE3I2Z6pJyBQAZEJJvby4p1D8vEg4/1UTxsjdO+Y12HczHjwG8j6E+ 8JJz1C/D+nI6ioNhLK0iqgd2AIgTILQKg3FGZRQxeawXp5Sru8nnSMInMcCm Ah4m9WYgQwRWiB8LvtUQ/VjK/8aU5aYcqbEtSkp2xQWJuOVLVWQ0khEK8I1z MLbE8qHCaxiMVw2Y/+wzzD/LhOCbW6D1FzMdvGyup4V4STbA0KgigYkwpZWU U9aM4nyIvmS4uVdxBokwskr0pgaKAr0P7pq2srKphjc6TVPQhCnLerwTJ0Iz AExs4GMwDi4rExUhuQyEyQmoEaYHxuCHFhgZ4sgW23McBgApdR8lKYkncaSZ Y5qA5NjB7benL9yubkQ6Uqjipq2Tya9HdMkoOhZSuxU76UXCoaF1HHejPfD6 zU1J3ICFm5z/MyWc8JdsJVb3SQQ87KIvxgwTTIhpIClH0BUuOQwKiES4CfTg TnziMIUYHtHeGKJV67DpjcDs5U2EqRkyEAzx08IeY5dSzDGbtDSJ4uqX1Jdy QhMT6YgAjGSLmUEC7sMHr96gORUM0R7hzBuiGzjcelEDYkipV/MzpDjh+WwC m8T80Rk4LYkOL0AvTtEiofDn9e25Wj8/u7g+JQxTOR+8uU4flFWECSdczxoI wCGaCC9YqUkaF2wJ2f/pi+ubDZvdBTQRU+ICGM1kKHE2+KiHW6dCgXI+w/gc p6Mx5gAEi4bHMnJlO45p/0ao3ckFgA1X9i54YiB7TLVSmsjSkpMiwHJACUby wOczzX94fN9tFhCIVQSD0yowA4+T2c9dMTEgrxwi4MugaZxZW6y7i2nzkRK2 QrsSa0rrY7sgmXn/6RJKSrZVLG/IMSg9MHFOCKbhRTLblN3mTp3EI+LCXdXk taFDkw+qvW1WDAYjPENzAU3swPiV4X2UzrGiqsmz6rdgSK3f3g/pCfyxYeUj UCwFIblggMwjBJNYhrBfRqSbzxuF5OugtKam9Q8nZCkIvaF/A/KpIJ+PApv+ JsWWkeE5VMnibD7jNHGpxzbxRXbjgFLMms0lkeo1Fbcuo4Xy6kYn0FivAXBC OyobEkliVd2eyoeVRkEFxvTJi9cvkVfxVMHHj8eSwcIjBo3x1Fdq69/h5evT /nmf8hbN+KspCWD5k+psDEuFOWkZzdHQzKo4f+GvCJOgElzAxD1lsgUSjpkj I29jFyVt44rkBbkTk3mJQaPAN0MNd62Cp6Co5geIzU0Ehxvz5qQQFi6NoiQR bBPcTdIt5Fauf/gAoh+TJu/VSXfLY9QNTN33UABhsLsJJmKlhqGsCNSyMNaA vdZ7YHlzDiRTejoDUYjL4ME4niz0KVURmNZdWJisdcQl++Mf1xSwOlbGoYoA idGch975AUy3cAT+QZCgUzY1AHNlkFggFyYxDYFBI/zbw9S6E2QH3a06fAQR D2C5hjUEkCKxGKANlcwwDpyG9LmwgmgMUTpK3ttyhaSgLAdOf2+pljw9iVvR a93gO01BHEk1eB/VqJ2/2288sXDA+lVy6slEsoxJrkMkr7BAo8osGqnU7Q/Y e4U9YzCObRigYRoGpzGA/RZfMIPwe2Rzg6s7rBDhCW2o8cIXnPRiZ7/1KcvP FOfCjAjVhFFIp7VIR6Uo97Xh5GeLtOfSfhs6hvrrCxeM9NqZI6GreWkCusgi Jr+BxEBcUSdaDqEnbKNzzQRWVcYavXaxz9iFL0xeA6awJG8FVxRHM855kSvi yc0fdJErkxuh7FNJQpHCIctk6oTIVgYYgJmLWd8erWR7R8i/w9UqGAc23rmO ygS1soRrClMHaMRj0AiHYPrv5rJc4Z8iTqZRidXdvMoaI9hto4WnKv2+wpN3 +N1p9BcEEjpBO8H6n3vv93t/Jj7M+FUX5RrkBcmFl/MC6RQZfcVWyAXisqua FiRr5W2RhFRzY/zbwSIwhlJ74RYi14ytM51WEYFWHryyeGszem2+gOfzfJhq 0hb8xOAobyi8sBSnW9tGpK17AcBOYETpTncL4aReJXeamTmxHmUL2ZF6e3NJ 6AZTgFUGiRPAJqaNo+ET+ETmtKoCw4KZdowOht6UE3EwHdASZuWMfm9tHPjA lTqKDQUvll9waOwvWE9nCqkD2kfKdAmzY6wfs1WzaKhZVlANkYtOmUk1nTzU ha2SwijbvMjMGwayHIrEauyYC5VM7MqYfQNxdzlykTU9ivNazbLBfCPdTjLZ 5CdIAFLgS4LkcyqypPF9YWzKznByqwZZZNr3KHiZjrGYYjK1tq6NqyUURR/l FP7oOFxawjShUptHYYyCaJ8VCY666FLwhV6aF7O8NOUEJLZk4tZ+ad5yPmWt NWA3LGTggGsp1GzJuGENhMqY5w0rwpkFPoJgsjXkC8yw1uKKS3xrQsRA1wBf c+a7eCJlJMIGhn1q0LPVo9Y8dxz3JFtItYnnbRiHjf1QV4NC4uEZPmdIx1pj jYUQEsyO8fixS7WbhUtyFWUDMFcmBO0KBv2EFhW/ciSfEm24fHLasPTWr4Y8 QT44gR9gCUJ6PqTzXY7WJFNHVT4o1JAz2U+3XzEsZcsfMaooBY9ryex+dwIS jHKN+Nc+/+XYxHFOYxwXdtqgkCYWP16+ud/F3+G/+wZUunQckYyIrW00yFaG AP5Q+Y5AZGMRaUfKLQnUWA8zcFVLBvL+1gWNnhtqJEorBLYMqUQSTYwauvPw SWyDX26yTQd3JloeN3PtWYDm0EqsR9E8rXgyWTCRuqVKE3wm1BV6HBWxVBs1 y3M6tRHhU6wNpoH39g932bYnrkVkYHVV67M1S3TL4gxZrkjCm6pv1ihcvUWG lhdZFaaO0KxNhkkO3qKPB4kOY2U1yLMxgpzLl4AjUjYpbGko55tAljrxhVra yi8acwqLBbgYpUrGs/GdabWS8VkaFuJduywWhYZbGWkKs7j14WgNc4fHiUx0 n0JY+FLpnTWAFWKpyXvCNnqSVpnxUR9U+FmmUxiKHZw5LkFzXOshKoqIslsL HxWGeg2RgtXxeakmeVll7JdKBaOjXoxlzuFfsB+ktOssn0Z0OBNeWD85e73B qcd8UHFKxUT7MYDNS/MHe4Ltlg8VqT//CUTFn7l2AEZdB345SZOovMI6J5Op FxtxyRTuuzzPhiVfoUQs8NIY+dZYVI16Ml1wqWVV2RI/GhG2jsCXjB5B4dKG 69T67WvKHbmTMgEeB6wPxeRwgdEXwT/8j6w7WwsRKtTs9EyzT2/Igkx335xe EX8RwRI1Sc9iA+Sjg5k3sej3ZWYQkflDtDAJ05JTNZQm7zjfzUeomY0QhMKj Zh7B8kdzqltAA0UKzEQiABmTYkh4PcC1sxwYAqsIc2B5Nc8KhA96GR0Jcxhb C2xmPGrfVmKP2IXuyxny3CQZT0gxm8CmmFwcnDCKpmEtlRQJ3iKibxpOJxwT cZHc+DFLEfm2ZtkInY7yefazgsfBZ599ps4lX4+rAB8vwRSNIKmWlnc1DyMu XPIyulU7aWzNH/5Kmud3ZZAm5pQlWbaUjFpBoonEKvEUyS4fs1F/7vVUL1L4 L3igtez7BsdHg5vGotftx6q3q/ZGan9X7Wt1sKN6B2p/Tx0cqv0ttR+rg57a H+KT3o7aH6mD7UDtH/BUapf+7W3Jn719tX2Iv2xp8xze2Q2eObAdNzBDwjvw lD72dhi0N1OvcMBNoejrSskF9iHpKrW1d7APTPKasbilGt9Q61x9jyb6V8Pc hro3TMX7OPlqjefFEImpZ3fIbVQNYEUsahXj0HXVBVYiUHj3IXflIA9UoFDH tgtDBTMKLwPR3AO6SK3qWTXB09VFCby+tomZV5zbGXxZg5RkqmDdEs5hm3B2 GVmMqz//S8mmp/b28N/t7X8i2dT290tJSKnDvZ9PQl/B1x4jo1s5+YZiEW0W HrAe71/bzDYBz0+hcAv3B//+q1G4r/YH/woUuv39YhRu7e/u/AIcZp1HcXhZ k+pUcmALbuuHKzrI5xNJCmLKwnI9Ol3DXL9PyupfiTtQvTHhbvhpcLdPuDtU Ow0kHsi/2/DaQO2MArf6g/hTCHi1u330XMxOdjqEXELEV5sffo1e9XNkPp9u uhL36VxOmq+oQ2MVseYdQURxHYrztYZVVdi3InzJ0Xxb6yb9LExFThD+jJ+V XRfINGrMeOnSiuZodjDVcRJJbc/KlXMUDN+bZnqaZwCTvb2djjtfaJxXDKEk 48ykUYAXJNfuTZO4EoGorFcJ7JNFKIeR7CEpzmXVeirUSw+J5bIQfg0xDWfS Ja7g8AUexPYCfHQi1DsPZOx9qUiaRUVJ4bBKjp9LOO95iG1WF7DbaosEmr0P OOxZa9JgulhgCoFMfzNWWSs7buRIySB18TCehwqlwFrXlAtqnkGSYiVwvbza MjBRKKTDgR1aEEK7tAfQfV+Fg9M8F9jwb7MUA0omKqSLAuktuqMQFXhEMbpk nbrdTFmtGwLKV2q3g1U2l9OZd1wN4I9Lt5Y3ZQO4Rt4WHDNQuX6ick6+zfey G0KS+sMHZDocLTRmGfsfiITfyQkec4TsxsSiLbeKC/Y4m5picaE3pteyTsy2 yp9SEZIQrp2gtd1Maiem6Ct8HKx5Dsy4QuZAlV29BE9N6BPbXg2HYFoaz46i ReQUSQxiwdFa4YFaSIq4w/KewQpW9Sbob9PyrDYsdJpIsbFxkAwTc88FW7nI cYxTLMAELkJONNvf6MhM5MFJN1qvuol9LEKf7WrSKhLn8j2paUJKpoQJun4C JMXci5XEOrMHSOvRc0O5fl7EwNQIovapNT8UaaMIJ61SJ1cqtSMVBj5uO0vx IkPTNEaKGUR6lWRNRWBCbKsKmfCVeWk7EtTeXS0G17kjSBUleCiL3f4l+o14 DQF/K+VwJuF5KmcImc8AUqGcKvzYKq0Wei6lugEVG/ZPsrW1gIcJmA98sqbH zVOIpgSf1BfP0F5kafb9QuExVKya3JATxpgiNSEgCt34R4pZ/MhoGturCky5 VYs7qug2qEMq+/JPRBCGa8cWNpwEk+ZBFPWbztMqmaX1Ndh8klkctkXo2POw 7iwsi4IO+aTAQ3PK2NOhEwq9p3nt/AijQk6TUjsUV1k/iYopDozrMzG7hEqm ejbCjuvFZYmcjkp7hICnK/OpZmdYpyg9LjOK6CQZlmG2dATR9jCfLSy6TbbA sltTRRDo6dN6iMcjLyv+mb5aPrRK0hTb+9GBshpPRPU2Q1UemMPoazUrFcxT zC6t1S0lzGSvmU4Lf/RbLfzx+801at/Bx9OJr4mcavbO8y0Rsmwf7exQf+MY 7Tq1vmL8jYC1xlPfeiPHWnwHpuWG2HCA+59zPoLHvQ+1Jd5L4OZqOw1ffKHC r7++IDnw5ZchSD3uivy7t+c3f+hgvW+FXdJfX5/f3FzfgJ0RH6sevTZKozF8 UsRf8JePsQPgyevb785vjpHGT972L65vLvt/4L/Ozi75dCa+TwPAW7f4SN2e n+J/cTXN4IL9ASKhH6SU1a4IsvaNPU/t7BN58pTXEATPbLFF1pUvMtw385kY m92g3hAMRUozIrVE9ZkwOFv2nKRm59kcckG+Naey4MWpqLBnNq1pHvNvmvWc fPPW/RQ/Nbjj+RqO5Z8AEAVtn6SHy7bUrC9rSrEhkqCTwATl9d3CWhv/uN9y p4WKF1dJB4vIpjG8RENjtt9+v2k+kHFPdTCrJ2ubI6gtg5XWiOnO5B9+EvvM riKWlnQX8E9q+nvwSXogsHP0Nkor38G+J6v7IxnjfisWsyR7LrmcAz5K8pVG gFt0uQQn7Je0zQqb68/YebhsnyPjM61+GwpjRhcFnpBBhBHyamtDIonABuzt 4XlXgtOG+xQ3BGBpDMtMkoELLBvBo7O1d4Rc8MQ54jqiE4X+vIHNQprzTtbF 0wxWk1zDqdl0J/dPZ5ThYso1VksAC7C1m80+SQbJxlan/Xjtq8yExrdbcizb eg3JVIOxVm4sobaBqfRgM74GZFfcOINVzAo62M6olkPBFoxLRZc5vLbdff++ iRxyHyLZhcqHeKhd+VYgAc/YSclIjge9n1GfyoYLRwfU8XM5OkJtK2vM05Ad 5pRs63C8WMzGojXA9QFAq6Nldxv+65QaTIF5y0Yxpg5h9w2Cs40u5xwEsEW6 iOlJMkisIGyNTKIID7fG+lkziN1tGxOgRdUhYnX2o7VAl7D9oyB9pneC4sW6 Jy+piY/n6lJxrS7Gi7DkpiZTHZFL0LG+G1bizmckxtZN0xUNFgx6H9YAzync g+3SNiSOgqnVQo2xUzoe5s3p1GuU2bAHEARGnruBK6tkW5XeTqqasp2Lra8b zW1Mj0EAZqo9/8Z2XiJFSqlgupUGoZRiUUHrTHjJFXjNSWRRzXr8Qo/nME66 oJVNopKBYPqN2raeAkLE+Hk/GkvOmGNafq2pa0HX3ep191mz+e0jiP7RMIJd jecRVoRo7fwpXja2XjFROs/ooSwc1hSSzYPte9a5lVJtWrQGJOxQzk3pBBGI PR88cC18y9z5jP3+q7IZZiEGp0hRPqqEwEvu8YjVTMx4I/GKUDx6x5J9s0h6 idq5yrmJo6ir6H14MtbuGEnztD+dWwHzANYnywvq6rVUtA4iS1QgeDTenvSs FR7jEHW/cLnAF7ea5IQEXMpahVZr0fs920KyUa9JpLBnAyzWWgPH1oziao6M VdsSXATFimR9HC+HG20Xlb0tsa6FMEE9Ggw31FOeEVB4EQhtCf0Rs6bDeUqk Qi8b798rXbSnxLAceKolROJpYVNoK+eFPZulUWHhU02tFvc4uJVhGxAjaql7 4UCuSZZMgb4Q2Xze398s7q+cD6i9NZfPSJ0sUYMBkvTFqL0qRCH12iA833Mz W1N6RiOAWUGygoLiZNnwyZbCpzhqWEQpCqMGifFBVth4erromDobkjijJUIN gVRz9BthOs+MsIe6aVc0ojQslWbGvLeK3QgsJyuFngBkuF+zGAQqAYy9MCNH 5Nixz0mypUvp4IpRZ0m4YRhtpgvV5GIpguYkDEhqlzho1VBTpUrOxe84nE/d NflF8TjCufaknNf4wHT5Y9qpMVOd2LqUhy0nqMMLqzBhH0ku3TNmaTQnVedZ Wy2j3rVT9qwDSVwgbuTcpDGLCYqx8AdRNsi22DY3cGs2nNngEFfGTGAaIgIw J2Aih/wym0XwpR43W0uc2Sz8iD0lvPgiL5iauM+w7z3Gqo2N4JEHCVA8lgUS l8vCYj2TULdJ4xX5X9gUjb0OEnYO74weuX4SgayrRu63Yqq0sN8awibOOaLJ /g99wIwq5hxQQqMayze2fnawrimGWCc243MBVX/zStZsZTB1osr5yAWxcxfs wZZrVcpekJWirHzQeFSPOMp5HiScpc7aRt62jnvw/+3jneNd4gVk4oOj/cMj MryXOHFSIUBuoVirPzNyJ2QIXzs82Dr6p4bN/gpmKVgIS4NnW586eNYKoOEI PNuT7xPIG+/jf5fhaXVgjh0+4gDmwlC9fi8lwOsmr7mzYc6DgkUMXNClwg/X RY/keiiGYj2zXS8frdsRZYUc70SXkE73HyaXp+nj/OTs/OYx+vj92fXVyeXr lQRSRJ8yuloHbPcRAlmJyBPbYsWk5JbFxpZlryVlbbG9u4ES209Em9YPLlcd 1nBPJoEEPnJDTm9JmdvLMb5Se0JFHjWv/Stw3ZIFb9+cnfTPfWHQv7x6swLV /wieb/7wy6TAE9z6dHimoW7FZ2FdFawMnDSDELvdrT21/nZlrGEjSEyEfFlI tBHcwSya5Nww5bQ69mqOczdjRfy6C8y4ZQ0WgatoE5Kixa9ee/COmmwR7Xz/ SK0c2tbR0BWQX7u6Eg7d3pyrl9Kq/rE2qMsKrpBL3szLCXKgtU5LFxKWRnTP LalaNZ70ocRrIj9+tPU3bI/PTMyHGnMtsuGkyLN8XoK5SH3zFjZiz6fSmgXl bO+XXqQ/oS+BV8u+oSvpwTgIxp/NmdDGvRl+z0Izi+l1khibCE0xeH2xuvOZ D7hm1z7qmlhWsAbT/R+hFRhtBfwSk+Jzs2KCORm6oA5aNRj0ZMM9TMnzN1ZT 6VIm4JvRCY6KLeNlscxH2y/mnBGut1fD83u558eyC1Gr6XiIMj5WKzv2W23x MhsKgI/X+1FV5fdLpMC6CRE43wbX1mro6I7h2ymRAMhHQHnC47dQ0oIPlpaC S82qzNw+sYSsvelwCoO07J57jrsaGHz/1g5oPKZGXGW/yyfJHKdsdAKPWlzD WFcmg00hsPqBgkj+CU7MB+lJlI7a3b/RRqa7UfDxchhGHtl5s2H/AT4bw01H gnVwk/V7FKLYMbugcCT9PkRwp2nN/eEpbMfFGeUg3Vn2fVeyYzEDAKBAXy4p M2E/agXloUdwYLN/chygEyyP4fPilkTTZFC/uGdI0Q1CaAOfKNibGMWYhqsD gRe41KqF6N0moimq6peI8BHjgW12uKCYpa3aQB/VtDTJm75th2LcnIZDmeQt VBaoa8tzjXe8DsCg0vD0EQpl8DRxcLMaLwLMRsDEZBPXKRuz2KhFZm3HN9Pc oIEUo2sf6TPcZbNDmzB2za6wx8Qsk9oWmgZa2Om+PqL41mZPre6hLfulpCOd DbvFCE5fXrmMoNfxxDFeratxzSiqjVKaOw54Xhyn3hPWgzHdoMSRmIgvQOLT jYgRsM4ov9NsjmqqiiNkamxcpNyZSoFiLoX5eFOCQc0MxD6FOnxWT4rhfMoG W2mvamnFW0SBPn33gzmVi+rA6BIxBNgAEIWPVXDcxU6sk2U55FwiDF7xc+ku tTO3qbV74TVplREY+E1HhRnosCvIHbD4k3IyNbmJKZ2szSLvBKVM45rX5Xz2 ttZcLljZXC5onsdr3k1b6wgdmQQoR8rzBwm2Sh/riPqOyIq8lAwq+KQczvFQ fNAWkIx0d+a61u9fopKyO+QSbOJFDd+u5JAzwg3VaX6xxKJsVFPaEliQhvWq a2wFgg1hcyy5saiim32oLv3ChCspB0rXQFR5iEk9rlGkWBTnP7Fbqt89r9FS /ji40Q+wHSPQa5dIrLN/a+qZP27YUNS6VyJtcpz4cRk80mT8wTSixaQtIOk+ wX7IS2maaxyQpoFpHiLTAX0lNLC/sRndBsHxOkWzc/NWZFtUUFGTmKjuYhQq NWgVzb/NHEe9LU2B4Nw95TzRM3wTv8wHd4BykVi+fjkfd2ay1/d5Fza1UdgN vpNB+BJDVbvqq4OtAhcupRtVFd0Q5pXqI7PMIy+mZPg2HwWSATU88TnKOAwa qyk4b6m1ByXfhiHnTL7BkPNgRJA2/fr5K3J5ortsW5p08kWUXgeCLT8Z15VW zuxMaNuam4UrvA9K8fJsdUlOs3YYm2dg7gvAIGxpgB2NMa2CgBiFdBBolidg npGJJHDEFIc5926v3JFFcL67yrF5hYTYmzCpVd52na9hcw6l/3Xy/CivyAwi 8/AM4lq47luApVTj2cBtORvo3xVHrHmXZGR4N7dFDbhFzNXZYRWJB8E3fCjb 9NF0KsBnJsAp3UW+t+11kacEOPfvI9F5ym1dJZULvJpU5paK5aMKpk25UOkq k5ZzBMtO0Q3rVit6S9pmaWabprcvAF23N4DWbrGTprZyIWhjk81sIe6SooPG sgcaw0NXpbP3EzkL3NC22ARKPGMDlEC4lrr3upMCB/j1FVdQu0gFXfSJGSVS eg/eWQ5qai2VMrlUF2DsYWqTowgQ21mAignYzEKQ3SPM/LtSMUCVY9s8LTlI 87Wd+jWq7ClQKYM5xt9qzcjJN4pvIzvQXBKnw7oG3LiotlpJR+1GGqQxudDS pcptEbfbAyVUK94ZEwBdHk2hpELX+nJ61yLR+9QLlcgQdyGWvnyhJQo8EdVS Lyin/AYYLOOi2rk3Tp421PASkYeVupIwtplf12rfRSH4g5bYC7CHtMsxzPJ8 RGCuGzhCwFJNBT5rnAz5Kg1uukNiK5G2HaZ5xcJ5NSbggvDiYqAy4OgmX9br yzOuj8pkgdK7CoZ8HKBdLsxaJiaoTbZ0icF7ekladNpbuTyTymEc2WoMAxJ3 ngizLhEeNaCjhjIwdd9jOZRjpZrfmJgcH7yX1A6aZJh3JT8eh9exZ9iy6qa+ ZnLAibuD8zW4JlDW8QjH4L51EzKf07CmCd+HDIKnyGrX0aR0D+tYbryr3epl CySIKBqVglgAgFXJD5FfXuQcjgB9Ns9PrzFJ60q5Jc50/QIB/4Y7Viy4UUrW u3Kux80vOk7lk4axJimGJFrd3sMbLPN/TGFi3ArF4W5Jm8uJyNbbyIU+NMzG CRR0gfCjqzed/1dcGPoFehocVX4gq8r2d+ISUY7R5rMIKEi1HH6vJICJji5l xWOFkuQ2IPQb73NlWex2YhGFd+ixQQhQoM4rddKJFqY7ta1p1wU1eWxdwNcJ eNsxL5vuckMnzsXAqRsW2xX4vFGBU5JngjPSVQ42VGyiG49M/UVAzhtRNr9L lUfUiC1+Zqf1l7UkUdSEwkDbiyhYDrI96MU0h4UWikAtKx0iOY47zsSZVTpN xuQVtO619COtFneogC08bPq5cfEhFenXbsbEGPrJ65NnWJJSt17PIoFzqMcJ 4GzxeJJGZqEWsnTGnDqXP3HKfXWGjIq9Aj6PLodAli0Oz0zw6ryvPe+aKnc3 w1pgBxkX+Xzmrgv7QhLANkhh77581spdy7wrOl6PN374S3b3MXOMNvjR7I8v B/kRYcU/PwIaqJZ6qNt3yZqfH2EAHyfK/anqnyz/oQFWbAwGwCy1WY1ZNV+d /vJUHR1hw4HlKXkYF++oBY3N8ff65+am2uW0Yo5W3X774nR5j/6y1qS/3Hgm wS6h29g00/WKlzKpqic08kJOXzxvIUuIkwaoX3RSyk0n3reJCllV0SHppFbT N7Nztjtqrbya6SNR12suBgf8Udc3j3LUlY7IxHzkB6iTy/sRSQWACIZq06VH hC2ieyYVtr/UfkbzbPVkYaZViF1pvWGDDU/Tl4CtzvsvcekNul0OOY96y/th SOAP7xDdQrjf2npCH/1IuPW7ftaL6qsN9QovEOpzg78Te/vPtxyg+Fmku/Sn Rc/uRiBLxj93WZ9GyrboGxDIoHNY0zY/tkzkPSLfHiESs//HKcMt4mdThRkj JKEvRPFsGCOdXJuDmxTBeU7Eh9T1Z5/Bt6meynRSPLMnbmon7/o2woqx8mzR vI+abX4aydiUfrrPnH556rpqcatIN1QSXcwxqvDLLrWmQ+ezIsmGeKi+4y9Y gy2UU92+tBDFUXK+7sea8FIZPKBbOLhXOQ3p12GUQ51FRZKXnQZhcJrX9ICX HL3tyczCGUQzFheDr19yZg6PeJj4AL/N/VSskT/R0T02mOeqXttXlo/5SLF9 IpnaEWZkUz2ytdY2AoNp9JxK2+SeAHFzvY4azewOxwW5UqisdfHA91/nWbis s4d3cSreM6sR6N6pLnI35CJpe7bKK5SpR3tssFijdUvlHuYAsndFJfIQXxlc kfoT2FJcDK1oDIglZS1N2gCm7SKPt3cPbXwy42u7pMMfkjc1OsItSasRkDec scEuk95FW3yasjAfmhwk0vGGfUzlEyZuw1E5Y3/LlZOEYE48CGhSHcWl+37r OE39IXGpqalxSODCZmuY1npgkDNgfER9T62J/VlOlsbr5OxXqzbSbJWqF6Tz US1z5qIPFirkNEqyw8SNDTHjgRK8/M9uxVRVWQffrJlPY/nAKBljb6gnyEU+ A9k6TSqQboB0OkjHFfoIYZzaNhCReMGUgkMZ2VbY1D+fwYBvvXYs8HUYNaRR TbWfKeyZwAfUkRjYwkTASrnDhEfCpdFpZ3sSGtOrjWPPH2sNXeTsTO5pAik3 dWKs0KYa0JRO+Mlj103GZw5qS4Dlqd1WKVWcxNITk2ociB+92vZaTluCzZ4P znU8FLWgxAgBPPC6FLWvWk5z7sabUWWJ1OQ9WZthIjayagEHFYVIIoXLRIi/ qHdrZE4I+HdV04J+2QpQZwjzulJS7rkCQpjvY63daFYvApfeUphikRsUYY5z 7PlFIWz2b7T9m1caecxlz+ZN8kTy/a5julHOjdJobN98cLh9SAXRhear4lio GYWGqR40NImcguCcE5FE6ZRh1faBn1slfHCZRdkKnSh3tQ6Lb4wEdBrHSDty QjFKF2VSmlysCaEGswhLt9Y4BQYUTa4K3bA494tuL/P+cV1n441+MFJIA5DH 8+WvwvBdMRrq+Ht1a6te5WIvUgdBMNygEgtqU0GBXHfv8U53R+4TzvniHBO3 6P++j2Gk2bzqqu8wSVLc6ThgRYbXh9ipOnxgVC8c2VLJ4kMSc5Zw/8i/IAuG x5OZ3GGGZky5XSCGx7nUBoyHg573DiyABp7mdIw5kkP9/B4VQ5d6mgzzlMSz BM/oG2hZ0LVKdNnJOuycTodxr31z/W9BFY48aOD2ZZBg8L7Bd5eN8bJlg6hf I2gqanLEgUx+pcLOaXjZFxdYYpgI73dBQC3yOfm0GBZ5MPKD4cxHp7A/M7F4 V73UYPSNCk3NfTh6LxHc+XiMNxtQcohziF2g8q+B89TJEHPkqY75qhiw4OcZ H5DWsZxbWknZWCwkxYBgxX/48OEKRc2LBBAL9tFH9BY+nEYF2uLqBUYvssw8 vsonEWbsXuTzYRRHSWE+ONMDoNw81Qvz5Ns0ipPpT/+3UP/9P+fZT/+7Mh/c 5HhN5hnI6DR5MA/P04cFzNaF5/dUIyKPyztg7+Qvd+bBNzkWKb2EmScgFu2Y /QkMWqqXOQj5KrGrTe7yNErUNz/9vSpB5NjZ+nkcY9vkwj2YThfg4s1Tu/7/ hEXSUu3mXwA8boeTB2C4H8yza6AKdVsBCrWdNSqGueonePuqefbT/8Abar9d ZMM7+71+MlXfJcMkK+94xZzy/YCrQFZAnoDnhlUTUFRgfpDCxG9ydL2yt0Sy SYg8a6voE84slKbhyTcakQkEF1OG/YrufOd7J0Eqaby7vqP6oAAyYLIxx/9v madeXL3s32zwTeQ01piuNGCSK9XW/m8vb7d2Dvd/q9b7b9UZyM5YZ1znYz47 UOsXJ9+BHTEdzIvxBrG0O7NJs5sjgerN5bfXfT6Q/OiM+0e7K2fcP9r7GTOe hkW02AV+whrKd3ERjarQpboxfIgih82mrcPvj9WkqqjLFTZBwyPFd2CG4gt4 ZGQTeG1zUk3TzacGenKqg0811cGTU+1/qqn2n5xq71NNtffkVLufaqrdJ6fa +VRT7Tw51fanmmr7yal6n2qq3lNT9Y4+0VS9oyen+lQs3HuShXufioV7T7Jw 71OxcO9JFu59KhbuPcnCvU/Fwr0nWbj3qVi49yQL9z4VC/eeZOHe1qeaauvJ qT6VtOhZaZFiDUFR0ufDrHzO+Etf3Fw24D9AZauGCd6N8TdsJO+PmA+7RZJX YV7SYJQ5+NOfMl396U/8feo8j+MH76Ikhz8wyuONMAbrZT7ogt23GWVFOJgO RuEsuc+rTff14P8DMHXuyxKwAAA= --> </rfc>