<?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 overCoAPthe Constrained Application Protocol (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-"). --> <!--[rfced] Please note that the title of the document has been updated as follows. The abbreviation has been expanded per Section 3.6 of RFC 7322 ("RFC Style Guide"). We also added "the". Please review. Original: DNS over CoAP (DoC) Current: DNS over the Constrained Application Protocol (DoC) --> <!--[rfced] May we remove "(CoAPS)" in the Abstract as this term/abbreviation is not used elsewhere in the document? Please review. Original: These CoAP messages can be protected by (D)TLS-Secured CoAP (CoAPS) or Object Security for Constrained RESTful Environments (OSCORE) to provide encrypted DNS message exchange for constrained devices in the Internet of Things (IoT). Perhaps: These CoAP messages can be protected by (D)TLS-Secured CoAP or Object Security for Constrained RESTful Environments (OSCORE) to provide encrypted DNS message exchange for constrained devices in the Internet of Things (IoT). --> <t>This document defines a protocol for exchanging DNS queries (OPCODE 0) over 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?>204?> <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 DTLS 1.2 or newer <xref target="RFC6347"/> <xref target="RFC9147"/> as well as Object Security for Constrained RESTful Environments (OSCORE) <xref target="RFC8613"/>but alsoand 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.:target="I-D.ietf-iotops-7228bis"/>.</t> <!--[rfced] FYI: draft-ietf-iotops-7228bis has not been published yet (currently, its IESG state is "I-D Exists"). Thus, we have left references to RFC 7228 and draft-ietf-iotops-7228bis as is. Author note: Please remove the<xref target="RFC7228"/>{{RFC7228}} reference and replace it with<xref target="I-D.ietf-iotops-7228bis"/>{{I-D.ietf-iotops-7228bis}} throughout the document in case<xref target="I-D.ietf-iotops-7228bis"/>{{I-D.ietf-iotops-7228bis}} becomes an RFC beforepublication.</cref>.</t>publication. --> <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" viewBox="0 0 608 224" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,96 L 8,144" fill="none" stroke="black"/> <path d="M 64,96 L 64,144" fill="none" stroke="black"/> <path d="M 208,96 L 208,144" fill="none" stroke="black"/> <path d="M 264,96 L 264,144" fill="none" stroke="black"/> <path d="M 320,96 L 320,144" fill="none" stroke="black"/> <path d="M 456,112 L 456,128" fill="none" stroke="black"/> <path d="M 600,112 L 600,128" fill="none" stroke="black"/> <path d="M 8,96 L 64,96" fill="none" stroke="black"/> <path d="M 208,96 L 320,96" fill="none" stroke="black"/> <path d="M 472,96 L 584,96" fill="none" stroke="black"/> <path d="M 72,112 L 200,112" fill="none" stroke="black"/> <path d="M 328,112 L 344,112" fill="none" stroke="black"/> <path d="M 360,112 L 376,112" fill="none" stroke="black"/> <path d="M 392,112 L 408,112" fill="none" stroke="black"/> <path d="M 424,112 L 448,112" fill="none" stroke="black"/> <path d="M 72,128 L 200,128" fill="none" stroke="black"/> <path d="M 328,128 L 352,128" fill="none" stroke="black"/> <path d="M 368,128 L 384,128" fill="none" stroke="black"/> <path d="M 400,128 L 416,128" fill="none" stroke="black"/> <path d="M 432,128 L 448,128" fill="none" stroke="black"/> <path d="M 8,144 L 64,144" fill="none" stroke="black"/> <path d="M 208,144 L 320,144" fill="none" stroke="black"/> <path d="M 472,144 L 584,144" fill="none" stroke="black"/> <path d="M 40,192 L 88,192" fill="none" stroke="black"/> <path d="M 200,192 L 248,192" fill="none" stroke="black"/> <path d="M 280,192 L 312,192" fill="none" stroke="black"/> <path d="M 528,192 L 568,192" fill="none" stroke="black"/> <path d="M 32,176 L 40,192" fill="none" stroke="black"/> <path d="M 272,176 L 280,192" fill="none" stroke="black"/> <path d="M 104,64 L 120,32" fill="none" stroke="black"/> <path d="M 248,192 L 256,176" fill="none" stroke="black"/> <path d="M 568,192 L 576,176" fill="none" stroke="black"/> <path d="M 472,96 C 463.16936,96 456,103.16936 456,112" fill="none" stroke="black"/> <path d="M 584,96 C 592.83064,96 600,103.16936 600,112" fill="none" stroke="black"/> <path d="M 472,144 C 463.16936,144 456,136.83064 456,128" fill="none" stroke="black"/> <path d="M 584,144 C 592.83064,144 600,136.83064 600,128" fill="none" stroke="black"/> <polygon class="arrowhead" points="456,112 444,106.4 444,117.6" fill="black" transform="rotate(0,448,112)"/> <polygon class="arrowhead" points="336,128 324,122.4 324,133.6" fill="black" transform="rotate(180,328,128)"/> <polygon class="arrowhead" points="208,112 196,106.4 196,117.6" fill="black" transform="rotate(0,200,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> <text x="108" y="84">CoAP</text> <text x="160" y="84">request</text> <text x="108" y="100">[DNS</text> <text x="156" y="100">query]</text> <text x="360" y="100">DNS</text> <text x="400" y="100">query</text> <text x="32" y="116">DoC</text> <text x="232" y="116">DoC</text> <text x="288" y="116">DNS</text> <text x="520" y="116">DNS</text> <text x="36" y="132">Client</text> <text x="236" y="132">Server</text> <text x="292" y="132">Client</text> <text x="524" y="132">Infrastructure</text> <text x="100" y="148">CoAP</text> <text x="156" y="148">response</text> <text x="352" y="148">DNS</text> <text x="404" y="148">response</text> <text x="100" y="164">[DNS</text> <text x="160" y="164">response]</text> <text x="104" y="196">DNS</text> <text x="140" y="196">over</text> <text x="180" y="196">CoAP</text> <text x="328" y="196">DNS</text> <text x="364" y="196">over</text> <text x="456" 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|<--- --- --- ---| Infrastructure | +------+ CoAP response +------+------+ DNS response '---------------' [DNS response] \ / \ / '------DNS over CoAP------' '----DNS over UDP/HTTPS/QUIC/...----' ]]></artwork> </artset> </figure> <!--[rfced] FYI - We updated "authoritive name server" to "authoritative name server" to match other usage in this document and in other RFCs. Original: That DoC server can be the authoritive name server for the queried record or a DNS client (i.e., a stub or recursive resolver) that resolves DNS information by using other DNS transports such as DNS over UDP [STD13], DNS over HTTPS [RFC8484], or DNS over QUIC [RFC9250] when communicating with the upstream DNS infrastructure. Updated: That DoC server can be the authoritative name server for the queried record or a DNS client (i.e., a stub or recursive resolver) that resolves DNS information by using other DNS transports such as DNS over UDP [STD13], DNS over HTTPS [RFC8484], or DNS over QUIC [RFC9250] when communicating with the upstream DNS infrastructure. --> <t>The most important components of DoC can be seen in <xref target="fig-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> <!-- [rfced] Please clarify "is of length 0 and 24 octets" in this sentence. Original: As long as each docpath- segment is of length 0 and 24 octets, it is easily transferred into the path representation in CRIs [I-D.ietf-core-href] by masking each length octet with the CBOR text string major type 3 (0x60 as an octet, see [RFC8949]). Perhaps: As long as each docpath- segment has a length between 0 and 24 octets, it is easily transferred into the path representation in CRIs [CRI] by masking each length octet with the CBOR text string major type 3 (0x60 as an octet; see [RFC8949]). --> <!--[rfced] We are having trouble parsing this sentence. Please let us know if it can be revised as shown below for clarity. Original: Likewise, it can be transferred into a URI path-abempty form by replacing each length octet with the "/" character None of the abovementioned prevent longer docpath-segments than the considered, they just make the translation harder, as they require to make space for the longer delimiters, in turn requiring to move octets. Perhaps: Likewise, it can be transferred into a URI path-abempty form by replacing each length octet with the "/" character. None of the abovementioned prevent longer docpath-segments than the considered ones; they just make the translation harder as space is required for the longer delimiters, which in turn require octets to be moved. --> <!-- [rfced] May we update "going through" to "with" here to improve clarity? Original: The construction algorithm for DoC requests is as follows, going through the provided records in order of their priority. Perhaps: The construction algorithm for DoC requests is as follows, with the provided records in order of their priority. --> <t>Note that this format uses the same encoding as the "alpn"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-segment is of length 0 and 24 octets, 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 "/" character None of the abovementioned prevent longer docpath-segments than the considered, they just make the translation harder, as they require to make space for the longer delimiters, in turn requiring to move octets.</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 through 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> <!-- [rfced] How may we update the third item in the series for parallel structure? Would either removing "from" or adding "information" be correct? Original: This may include (1) A or AAAA RRs associated with the target name and delivered with the SVCB RR (see [RFC9462]), (2) "ipv4hint" or "ipv6hint" SvcParams from the SVCB RR (see [RFC9461]), or (3) from IPv4 or IPv6 addresses provided if DNR [RFC9463] is used. Perhaps A (cut "from"): This may include (1) A or AAAA RRs associated with the target name and delivered with the SVCB RR (see [RFC9462]), (2) "ipv4hint" or "ipv6hint" SvcParams from the SVCB RR (see [RFC9461]), or (3) IPv4 or IPv6 addresses provided if DNR [RFC9463] is used. or Perhaps B (add "information"): This may include (1) A or AAAA RRs associated with the target name and delivered with the SVCB RR (see [RFC9462]), (2) "ipv4hint" or "ipv6hint" SvcParams from the SVCB RR (see [RFC9461]), or (3) information from IPv4 or IPv6 addresses provided if DNR [RFC9463] is used. --> <ul spacing="normal"> <li> <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) from IPv4 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.:<!--[rfced] Per the following note, we have replaced "ff 0a" with "00 0a" in the examples in Section 3.2.1 (per IANA's assignment of "10" for "docpath"). Please confirm that this is correct and let us know if any further updates are needed. Author note: Since the number for "docpath" was not assigned at the time of writing, we used the hex<tt>ff 0a</tt>`ff 0a` (in decimal 65290; from the private use range of SvcParamKeys) throughout this section. Before publication, please replace<tt>ff 0a</tt>`ff 0a` with the hexadecimal representation of the final value assigned by IANA in this section. Please remove this paragraph afterthat.</cref></t>that. --> <t>A typical SVCB resource record response for a DoC server at the root path "/" of the server looks like the following (the "docpath" SvcParam is the last 4 bytes<tt>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. 643 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 00 2b 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> <!--[rfced] We note that "Cache-Key" appears as "cache key" in RFC 8132. Would you like to match use in RFC 8132? Original: This ensures that the CoAP Cache-Key (see [RFC8132], Section 2) does not change when multiple DNS queries for the same DNS data, carried in CoAP requests, are issued. Perhaps: This ensures that the CoAP cache key (see [RFC8132], Section 2) does not change when multiple DNS queries for the same DNS data, carried in CoAP requests, are issued. --> <t>The DoC client <bcp14>SHOULD</bcp14> set the ID field of the DNS header to 0 to enable a CoAP cache (e.g., a CoAP 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 is optional. 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> <!-- [rfced] Please review the text starting with "OPCODE—a DNS Update ...". Should this be updated as follows or in some other way? Original: As described in Section 4.1, a DoC server uses NotImp (RCODE = 4) if it does not support an OPCODE—a DNS Update (OPCODE = 5) for "example.org" in this case. Perhaps: As described in Section 4.1, a DoC server uses NotImp (RCODE = 4) if it does not support an OPCODE - in this case, a DNS Update (OPCODE = 5) for "example.org" is used. --> <t>As described in <xref target="sec_content-format"/>, a DoC server uses NotImp (RCODE = 4) if it does not support anOPCODE—aOPCODE-a DNS Update (OPCODE = 5) for "example.org" in this case.</t><artwork><![CDATA[<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 DNS push 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> <!--[rfced] Please clarify what "a failure to do so" refers to in the following sentence. Original: As there is no CoAP observer anymore from the perspective of the DoC server, a failure to do so cannot be communicated back to any DoC observer. --> <t>After the list of observers for a particular DNS query has become empty (by explicit or implicit cancellation of the observation as per <xref section="3.6" sectionFormat="of" target="RFC7641"/>), 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 to do so cannot be communicated back to any DoC observer. As such, error handling (if any) needs to be resolved between the DoC server and the upstream DNS infrastructure.</t> <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><xref target="I-D.amsuess-core-cachable-oscore"/> describes a method to allow cache retrieval of OSCORE responses and discusses the corresponding implications on message sizes and security properties.</t> </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. <xref section="2.6" 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> <!--[rfced] FYI: We added "to protect" to this sentence for clarity. Please let us know if it changes the intended meaning. Original: For secure communication via (D)TLS or OSCORE, an unpredictable ID against spoofing is not necessary. Updated: For secure communication via (D)TLS or OSCORE, an unpredictable ID to protect against spoofing is not necessary. --> <t>For secure communication via (D)TLS or OSCORE, an unpredictable ID to protect against spoofing is not necessary. Both (D)TLS and OSCORE offer mechanisms to harden against injecting spoofed 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.amsuess-core-cachable-oscore" to="CACHABLE-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 Application 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 7252 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 ApplicationApplication-Layer 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 queriesNegotiation (ALPN) ID Specification fordata that are relatively static. When those records change frequently, DNS is still efficient at returningtheupdated 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 ofConstrained 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.amsuess-core-cachable-oscore.xml"/> <reference anchor="DoC-paper"> <front> <title>Securing Name Resolution in the IoT: DNS over CoAP</title> <author initials="M." 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?>999?> <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 and outdated<!-- [rfced] FYI: We removed the change log, which included a referenceabout ALPN</t> </li> <li> <t>Add DNS clienttoFig. 1</t> </li> <li> <t>Clarify recursion terminationRFC 2136. If RFC 2136 should be mentioned elsewhere in theCoAP realm</t> </li> <li> <t>Clarify where addresses are coming from with DDR/DNR</t> </li> </ul> </li> <li> <t>Address Gorry Fairhurst's follow-up DISCUSS: </t> <ul spacing="normal"> <li> <t>Refer to Observe terminology in Section 2</t> </li> <li> <t>Clarify registration</t> </li> <li> <t>Provide alternative observation examples</t> </li> <li> <t>Clarifyrunning text, please let us know. --> <!--[rfced] We note thaterror handling"draft-amsuess-core-cachable-oscore" isinexpired and has been replaced by "draft-ietf-core-cacheable-oscore". May we replace thehands ofcurrent entry below with theDoC 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 0entry for "draft-ietf-core-cacheable-oscore"? Current: [I-D.amsuess-core-cachable-oscore] Amsüss, C. and M. Tiloca, "Cacheable OSCORE", Work inAbstractProgress, Internet-Draft, draft-amsuess-core-cachable-oscore-11, 6 July 2025, <https://datatracker.ietf.org/doc/html/draft-amsuess-core-cachable- oscore-11>. Perhaps: [CACHABLE-OSCORE] Amsüss, C. andIntroduction</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 singularM. Tiloca, "Cacheable OSCORE", Work in Progress, Internet-Draft, draft-ietf-core-cacheable- oscore-00, 22 September 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-core- cacheable-oscore-00>. --> <!--[rfced] Sourcecode and artwork a) Some lines in Figure 1 are too long forexample section if therethe TXT output. This figure isonly one example</t> </li> <li> <t>Improvements on DNSSEC</t> </li> <li> <t>Hyphenate link-layermarked asmodifier to frame</t> </li> </ul> </li> <li> <t>Address Paul Wouters's DISCUSS and COMMENT: </t> <ul spacing="normal"> <li> <t>Remove unnecessary and confusing ad flag from query example</t> </li> <li> <t>Phrase full SVCB mapping sentence more neutrally</t> </li> </ul> </li> <li> <t>Address Gorry Fairhurst's COMMENT: </t> <ul spacing="normal"> <li> <t>Add note (in addition to the <tt>RFC Ed.:</tt>) about paragraph removal</t> </li> <li> <t>Add references for "coap" and "co" ALPNartwork, so it needs toSvcParam 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 fromhave 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 in the docpath examples</t> </li> <li> <t>Make docpath wire-format paragraph easier72 characters or less. How may we revise this figure 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 aboutfit these parameters? We tested removingRFC7228 referencesome space incase rfc7228bis comesthe figure; please check outbefore 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"the following test files and"co"</t> </li> <li> <t>Add reasoning why we also consider DTLS v1.2 (RFC 6347)</t> </li> <li> <t>Add illustrative referencelet us know if this would work (see TXT file forETag 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 formatascii art andwire-format of "docpath"</t> </li> <li> <t>State that we don't do the full SVCB mapping</t> </li> <li> <t>Explicitly do not limit what port= can do.</t> </li> <li> <t>port limitations: We're not the SVCB mapping document</t> </li> </ul> </li> <li> <t>Address Tsvart Review </t> <ul spacing="normal"> <li> <t>Prefer ADNHTML forUri-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 stepSVG). If not, please provide an updated figure. Test files: https://www.rfc-editor.org/authors/rfc9953test.md https://www.rfc-editor.org/authors/rfc9953test.txt https://www.rfc-editor.org/authors/rfc9953test.html b) We have updated the blocks inSVCB 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 recordsSections 3.2, 3.2.1, 4.2.3, andALPN</t> </li> <li> <t>Move format description for examples to Terminology section</t> </li> <li> <t>Retitle section 54.3.3 to"Interaction with other CoAP and CoRE Features"</t> </li> <li> <t>Make prevention of poisoning attacks normativebe marked as sourcecode. We set the type forunprotected CoAP</t> </li> <li> <t>Provide specs onthe block in Section 3.2 as "abnf" (i.e., "~~~ abnf"). Please let us know if the<bcp14>SHOULD</bcp14> on ID=0 does not apply</t> </li> <li> <t>Make construction algorithm normative</t> </li> <li> <t>Add definitiontype should be set forCoRE</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 imprecise or wrong 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>Pullthe other sourcecode blocks. For example, should the ones indefinition 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 sectionSection 3.2.1 be marked asa consequence</t> </li> <li> <t>Clarify thattype "dns-rr"? If theDoC/DoH mapping is what is <bcp14>NOT RECOMMENDED</bcp14></t> </li> <li> <t>Avoid usecurrent list ofundefined term “CoAP resource identifier”</t> </li> <li> <t>Discuss Max-Age option value inpreferred values (see link below) does not contain anerror 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 thatapplicable type, feel free to let us know. Also, it iscurrently not considered</t> </li> <li> <t>Addacceptable tosecurity 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 8484leave the type not set. List of sourcecode types: https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types c) The blocks in Section 4.3.3 are too long forapplication/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 contextualizationthe TXT output. We marked these as sourcecode, so they should have a width ofconstrained 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 accordance69 characters or less. The long lines are currently 70 characters. Would moving all the lines with<xref target="RFC7942"/>)</t> </li> <li> <t>Recommend root pathsemicolons over tokeeptheCoAP 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 roleleft one space (in just this section or interms of DNS terminology</t> </li> <li> <t>Clarify communication of DoC to DNS infrastructure is agnostic ofall thetransport</t> </li> <li> <t>Add subsection on how to implement DNS Pushsourcecode inDoC</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)the document) be a good solution? We tried this in the 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 statementoffer other suggestions as well. --> <!--[rfced] Please review the "Inclusive Language" portion offact</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 logthe online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates ofdraft-lenders-dns-over-coap</t> </li> </ul> </section>this nature typically result in more precise language, which is helpful for readers. Note that our script did not flag any words in particular, but this should still be reviewed as a best practice. --> </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> </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=H4sIAO49qmkAA+1923LjRpbgO74ih44YSzMERd2r5NuoJJWlmZJULansdlRX 2CCRJNECATYuUrHLcuzrRuzjvs9uxL7uH/TTer5kv2TPLRMJgJRULnXP7sQq ussSSOTl5Lnf0vd9r4iKWO+pzuHZpUpvdKaKiVYHaZIXWRAlOlT7s1kcDYMi ShP1OkuLdJjGauUwPVjteMFgkOmbPQV/eWE6TIIpDBVmwajwI12M/GGaaT9M ch9Hhr+Cmb/R95JyOtDZnnr+fHvTi2bwW5GVebHR7z/vb3hxkIz3lE68ISxC J3mZ0+faSwd5GutC53teOQsD+mUW7am3sKSuyufTTI9y+CXNCvztnQeL1uM0 m++pvAi9vBxMozyHbRTzGSzz5OjqpQdr3/Q8HGxPbfQ3dvz+phdkOthT359c ebdpdj3O0nK2BxC5OPKu9RwehXueUj4/4V/2X9MvAELPC8pikmbwFV8phsdp kBUASXWZziaRVq90EuoshzeUSjPY6tWbQ3WY6TzUiXqTRACpPCrmKh2pKz2c JGmcjuf0bQPtqzfm+/QYTkrrYk8d63g6SePiz/Cgp9b79OEQhtqrfX2YhrCo Q7+/3t95Lk/KpEAwfauzaZDwZHoaRPGemvLiezGv+p+K0g95sF6onU0eTLIo L6IgUfvT/Ne/5Lk7yNB8+E/BNC91nveG6dR9WSfX6ttf/5KE6b/9a5BUoDnT ZRbE+2OdFOrb6eC4tt/TSOf+TZD4sDD/Ip1o/xJw9td/1WrH2fppmUTDSW3n z/rP+rsP7nwIi+qNS1jTGBae0EoCXEkviJy1X03SaZCrg566HE6mUVhUqz/e /14dB9NBmY1rC3+hsxhgmqmrNFO7zlrdL5vFIlU8fExFL+fZ/2kS3PoTHqd+ QqdBUUwiWOr3v/6PSRzlApRHo6D6e/UiyK4nQQlUqU6AQURFWSxBzHu+/NdF 195toHl3DVT1khS+XcDekHwvrw7XN4FVJYinFy8PNp8/29lTZRbxn9sbm1t7 sK1kxH/vbG7twreLOF/f4Ce7G9sbgCPA0eTvna11/tsHPqWzGy3Pn28/l+eD OB1e30a5fPJsfVNG8Ee6oNPAp5sbm/K0GMrYz7aewWrC1HxlB5ee5shc5cnu zjZtxp+V+cQ+eyYDTdKZH0fTqJBPnm/hkgZpxn8/X7eb25QnWzt9YJo3w4H9 e53/9i3E4BksPwwz+yfBE/98fXHk46PnACI6HJExX9MfCkhGu1LFfxXMgRis bDkDpg3MggTOyv6r12er6uRQXc70MBoZQTRKHyuokDuvsmQ7vHp1yesJsjGi 4KQoZvne2trt7W0vGw19HUZFmvWAJNaiZJSuwTPcBKOtzoDf4OM92QZscY/2 ar+j1OH5yR7gcm99d+vZ7poDCPqc5QzIg+GEpA0TjxEY9OPLf5WKEhB8p8BW ejWRQWspM6bp5gejMo4fFDqtSYB3uUy7NkPzg2qGxRy/NfhVr8kba+M3P6jG X8xYF0GoztBqw7c/ckHUYogenq/DJl4cvN5Yf86kVQC3iaw0xk82d+mTXA+F iTzb3JTvTkCHKIRSdnae95ESQRUCtn/t8wyGjWwQlSIW+wmwOnln99n2MyR5 Q7L958QBkEiF3vq7O0LyWXQTDOeGlvExzZWF8mhju4/v/kn+3MYZdThJcdUn /mGv0tRg1SNGxDDKZ3EAPPbg4qT1NSC4JJ+BmuVHSSgU13jt6mL/7PL1+cWV f3J26A4QAV3Och/3PYjyxlsCEPhAXhF1gacdBsNJMIi1z6yvudD9g+P9F6+O /PPLg/OLI6XgY1BL/Vkw00JdbRK25Lq+tb22uQNQ3th0Odbnl3oIQiEZqzNA GXWhQQMticFECfGfk/RqT1nVGXnN5y2i9pt6YJOgDR7Xn4pgNsKwWxN3/r1q 1zK6piHfJMFoFMXAYHXYVd9FOkmCrtoHBTyLgvrglVo2Fq2sGrn5nDWeMrjV UaU0ALi7ooEtXj/yQgDlWXCbgXCMGgBpPH4URJaxDcOM6k+belq3+mXxchfq UMtZUWPJ6u+D6eyLRapRd/GuWGJ8DsJi0+8/9zeeMXoBnQLPKEAZ3UNRN9Qg uZJxjgobYuX+wakCHD3TBVow8ElX3aQxKFldlaTAj9Ozo99fbXTVbAbP/I3t FoXDP2CuxUHWJDJAcB/I68I/eLV/gQzl6PJqb6lMjYZ5rxxGPR2Wa7+MIh3j Ktdm5SBfgyGBHAviHWvmox/dp71ZOHJpcR+kZlToYYGKuLos5rHOVZCEtOND oOtxgvuXTfuDIAed4DIdFbdg0Llv63yB3KUDvOipl7IUeczHfpHODV41PheK cjXmgyCOgMUnEVDVSXYDFO+cJGjz/eYJylCd15PeYU8dOiDoPjh0h15miWIG Or46fVWdw2PPANhyb1JMZYzXhy+f+ih93weNGrW1YeF5X/6d778F/UqH79TL H4ALf68VW/WhettERtBhUfL5QTxL3qkiVW8dzeqdh8pgkt72cIzbKI7BaL3W hBajKAFcEW8B8mx45/enr9QKbKTXhUOYAt8GyMNondUeLPHr+spexxrQCAYv cLygoEEJHw2phemwnKJ5OgHkGGgwWswu4O9RGsfpbd4jjZeNJNFrzbeVfj8D HIavg5RSIG3o083ejgfjw2LV7ubGhlrp4K+E8urbMgo1LBY3G8R5qoIQX+/A Yjo9s2CcSN/2PO88i8YIA8KNmpxiF47nHZRZZrDwN/iA2jA7DebqVlvYkgJ+ udoxEnNfUADhA7w091CvWqsBJ8oR4qpEAtZxrm8nGihY3jcA/0bJZr3FmwWQ 55p3OgUVAiz3XA1BTg60msEOANIw+mAOu1gFs8AnQQ9PGDS8Zo8IXJ0P/gjf VqwKACEiurnAQR4IWqU6Sm6iLE1wcblaYTVkFbAVh4Epb+DclE6G2XyGUyOs ZWGABKDZJPALDj10hg5ha0PCXByEFA7gGVmiC7LNJ8T0V0AJAeT1XutsEszy T9492YX/r+ya0A8e5RUlhhrIHmUDbZVQFWeQ6VCZw1X8qSRtEJb8+uD88Ej1 Vy3qe4+0KnuPArN3P5J9BIZ5y2D9EYD2FgP6IdxC5g1qUxhrz4OvZWlYEqvy vnJ+lh3EAr7TdU8HNgCqEK3Z+/ABXQx3d/Z8UMKDYkGDgOieoVM4f5BLeU0H AIyLcgQGLnNEAXPqauV3MNEczvIIzAuLGXPfzKVmQZQhS5oGsxlMEiWw3MBz z9wCWAapfSbokMvRAzKgG0Kt9zbw5BN9CxvBTZNvCZZnft+8u/OARd5qkGfw 308jRxiUjSYcFADKK9isrcD4nGgN35DbaWsHvg/bRS88cGCzJQCBHtMqcCxA qBHgXgJWSAzPeogFIJocsgFGDmDISWbC4SMwQd2aRQYeBj2Or65eXyJ+HNOK w3Ryd9fzjtNbDZ926dUgmua091DP4nROaCbY6yK2g8mei8lddTsBWwRWVAZx PKe1wzIBVLdRMaFhMv2nElbGAIwE1WmhHq2vV+MOMKiloikIvgEOgJYUMVhY 2RTEYDYHVTtFMOMay+mMdDuPnAEx+b5GGZqXefRntJeKSZaW48kMjQIEcAzq RDKcE7eZ4yxemsDaJwGI1wD+k4R48NdRnA7mqOYAlAcp7OZi/5Tevzg/rd5V eaz1jEAYp6DGhqBN43LYdoimGuYcAfAEUAW+loB5gUQKOitsjsGEinGIe03L DDePX/SuQQsDPSctix4bzFnNYM5LGDEf6iTIohTgBSYnmA3XWmhqSI5dVYHF c8CCy6NtB2qkb9WkTEJGnwJBNogKlRkdD5c3DcYJmFWhRj2KQBPBcaKOBYSY JqEL2YhHzxHLQFvkL+RMEpVfhshiiRsD0bSt0TpxsPrXSftDDYc0QNChwWKc wGbmuvBWhqyPxYAzuOSTo8tvVQ5qtEay6cAC1NF7MPnzDomfEjYPyhbhQqxH BShDI1CWEjqSlDVImJR2u3w9sJwohy3sk0lE6i5pEVabJFUO4doGip2Q5siA LIMhWTxwJERU90DNoDogTF2ZhlNEhoHD3Pf6AI5qSjKCdjrQgNaaAcqsR/SD E7AMs1DTzhAsQKVg4wPPYgbEZM+YXKd/FIQHr2lnRPzdOpdxiB9wNw6J01l2 Rnye+BgydMQRWAcafVmQ0zJq3yT+5qG0IJIIwpsgKZDbot2HAmWkAzJe8c1p VERjxAk409tBMLympYLdEYyBZNj2BUk/naLrhSEhuoodJUqGMdCHWllfVRSZ 8DE0oci3N3Ikgo1a3N0Z7gk0fQNGNILtdQAnfHr1BoX5INZTYvE1AKzkWldQ 6FobZ/vuDtjxysYqx0/h/ffkLeIpjEID4AD7JsI3gDRjINEYp0BXILk18GRW Nlfh1EqWLwgDD06oZEufGJ0ri2B/o1E0pBdxodbhi9a2bA+IKRfGDax2kWqK Qg441k0ahfdjD4EAlkD/gdnTGT59cwhqkO6NwQStSZjluINj2A9/9+bkgD/8 EwGRBCNZmszXo/GkuNX4rxXZoo0iBNgxAr+wcgBb+eWXX1QQ5DfGqWF+eurl 0dXBMQWR0A/wdqPfX98LB8/29tbfrdW/XP+z9hdhLwIGBKP3jz79/CM8f2uV rXfwl/mg+tx+zIvx6z8972fauPq58YH/tfmARqDPlfN/+Jh+6EP++dn7+SCO 4Mx+/rI52M+XGMvL3M/dwX4GVWOE9CwIh2NVW5CdiyLZ3qKr08IyPm/M/bkD xbfud9/hB39Qy3/W7v20eU4yb01NlxWYT+1ngLprxArXEAvXer0erxSRyPuw pz4bRWPK9kCb3KdIF/lLvuq8CHKgOzwZ1xfXuWtJTuW7zqAO++kiDMmQ1qEo upp1kA/aDwP7sed8DHQN84MuBAsvRXUlp0MlaZAPwEP+DgiRvO1HCApaNY9r 9Hmk+iUrs8FJNmEwDAMnB9p3iFQc0KkPCZ2MHyoACV8O8NMM9fscByTVCUZb JccTj8GMt8m3kHGwUcO7wI9tiCZnrSugt8ihIaeo3lIM/F23qX+/lYgzfNJk Ovj+WwkpvQNuqZE5WiEDC7BadDnDMH8wNWt1SAQA/IbP9rHwDf4/hD8SwuIV AT04BVUjmuI6QZ3AsYCBWOEEULfmqSYV/cOHFv3e3e0hSFE5YZAWZJeTPUDg WgQttOebnpZhkOFh0RaixHPFAg0XOGjQ854CLz4ZKT4FI7zA8XwgOhjXRgsf jK3bRgcr5R+FCt4iVHhDq6TN1HQdippU4C1wfNTe5WwrKNqoEqELA5CmRnSv PDL1062LPmCq++5kp/s/sO+a/kbSoeO5PDpQN0EcAXPAc6zcWvXPSI3jFU4x BcbVz6o1IiM/c/z2wPTzWgoJSgGMnSbDAuzvFAgpPUaLAuNy4loCMWjeEVVo qgH1QqscU+IOnA6Mhd5q3OYArIpRRD60UkCPziN+j2y/G36qHQVHrNZBGs4t N6ETN0OApn1+eSXDgL1bFtXx50gAohFXdgMdW3U8RK6G1hAiZpffHplhe97x Q2ubakBxGwnJNLvq2UHAPlY4CNIwd7bQGZmGpKWzXn1LJhLAOyO3PSZ2EUOK 9XvjSzLqKpn8AE3AkS4D0NFvaTULLBbYr8HYBcYLoIN3VaVw0HQHaXKDjisA Uc2R2fhhVnqt5wqzP8EKP31zedXp8n/V2Tn9fnEEBHtxdIi/Xx7vv3plf/Hk G5fH529eHVa/VW8enJ+eHp0d8svwVNUeeR2glw7bOp3z11cn52f7rzoLVBk4 DzZu0UGXzTLNYSgPDPVhFg3YIfXi4PX/+m/rWwCivwM5s7G+/pw8G39HGWm7 W8JqeDZyuPCf5N9BD2iQ4ShwHIByM+DBaNMBtuaT9DZRiBMA6H94i5B5t6e+ HAxn61tfywPccO2hgVntIcGs/aT1MgNxwaMF01ho1p43IF1f7/4Ptb8N3J2H X36DWZzKX3/2DUhbIH3LSoE8hHXlTKEoTsE6FGbCB1E/vAg5aBzjgakOCltH jQ2jEflYMClOo1+F2FUAjC7IUaem3G35foPTBujbhOPREYkploIk9Yygq4Rj WwiKyHJTn5CQ9lnAtWRIJZ60OFRBZnfuUVQ6PDnyuFg3vunsB+FhTewOgiqw 8oXN7sq7LzHammQTRULkgmIfC2YrkOZPjiETggjqjC+oGa/oITMSsGLMjzhc Yr6oNt1ozzBXV5loHr5M0hFfOoJfdVwxR863jhE7eMAcawlZh2v46HoeParn nwGsDF8Qjv5wOAFT3tHXAnL4zyw9LjSwGYAcx/kpLwNx9Mrw5BUcaFUFjsUH 68OHKDURwHkJTGQQU3BqSvydBGBrtwT8hj5o9INzzrhFjhQMohgsMp0vAkqV nFv5odZ7G4LTsyArWNcJCnS+giwFrAcVQWeIcZ0YfiU3NA+R5Z1eDa8sSuTN lcCmO9VbH7sy1UnSwuotDfxn34GRm4boDEBSCjV8ocQHt3ieLZ7HohoIuFkw j9Mg7LDMQdHfoV0swzZX1FYD07BWB+uyRrNIcjsBf2YqDyyDpVxJ2XJFmtKS gESDuEe+XhxBvw9Qs8hbxMgTDMC+BxKXCcR1bX14QxLzOBOLNULUCQwZAolP AcuzGtorJ04H3yunQeIDkYQWrYG4ELEHusDICn8UUbBM2eiWqFnAsGEflSJk fBSwKA2smeEzp7WRfmXYjd2SeVPmrZ8U2R8ApEsdyxkBPrPdxX4uMD8/fJbr 4R6Ay2eEhf/Il++WK0me9/0kinVNK5yhb7jiikZ1c5k5kRl825HCeLhGN81S wAoaprPWwUDkNcaujG5eKbQ5nEksGOxYKaiWkuZLcamGWLCZY85y2tKj571O QcbiQTItsaWaUzyU8Iod/wN2pMPJ4+lRSHQskTUG8ZskIgZ3YaY6oZApQAaY 5JuLE4p4llnErt4aK170xgG/0U7fvbvz4H10q4OVnKJ8GdaX01XseGZuFVAZ UwWAMAJEK9DxbURGFpLFenyAiSHqIi0RhfdDgE0BNEzizUCGECwTOxZsqyHa sZS4FlJ6HvnzjG6RU6g/zIjFLV6qIqWRlNABBodA2RLNh+rFYDBeNZz8Z59h 4pxMCLa5BdrVfKa9l831tA5eAlEwNIpIICIM6Ef5lCWjGB8iLxlu1as4g3jz WSQ6UwNGgdwHc01bXtkUw6vdpipoQgJ5PbaAE6EaACo20DEoByeF8YoQXwbE 5Dj8CKOkY7BDM3S4st+Y9Tl2AwCXugmimNiTGNJMMU1Asu/g8ruDF9WuLoQ7 kqvioi2Tya7H45JRdCiodil60ouIXUMrOO5qe+CVi4ucqAHrTTghwlSeULiR thKqmygAGq68L0YNk5MQ1YCiKrCqMqlSY0AAEQs3jh7ciYscJoPUQdoLg7Rq BTa96pm9vA4wQk0KgkF+Wth95JKLOmazLUyaTPFbymI4DwSztvAAMGokagYx uA8fnETJ5lQwRHuEQ2eInledreM1IIKULHsnsYQmPJpNYJMYRj8EoyXS/jHI xSlqJBRYOL88UitHh8fnB3TCVIUAb67QB3kRYNwd19MBBjhEFeEFCzXJfgFd QvZ/8OL8YtUmxcAxEVHiAviYSVHiNJbnfdw6pUnl5Qz9c5yMgz4HQFiOw7fR lfU4xv0LwfaKLwBsuCBpzhMD2mPGCYVkLS5VXARIDmPcwnng85kkkDp032um T4lWBIPTKjD/CCezn1c1UHB4+RABn3tN5czqYr0tzPcZKSEr1CuxFKY+duUk M+8/XPlBge2C+Q0ZBrkDJo6/wjS8SCabvNfcacXxCLkoF8AlSYOHJvZae9us GBRGeIbqAqrYnrEr/ZsgLjEVvEmz6l9AkVq5vBnSE/hj1fJHwFhyQnKeFalH CCbRDGG/fJDVfM4oxF8HuVU1rX04IU1B8A3tG+BPGdl85Nh0Nym6jAzPrkpm Z+WMs2VyPbZBZtIbB5Rpo1ldEq5eE3ErMpovr652PY3ZagAn1KMwgwPGwnKA bZUOC42MCpTp/RdnL5FWsRjy7m5PosVYGdkYT32l1v8BXj4/uDq6onBg0/9q MqOY/8Q6GcNSYU5aRnM0VLMKjl+4K8KEA3EuYP4SJfQIJCpiDgy/DSsvafus iF+QOTEpc3Qaea4aaqhrGTzliGp2gOjchHC4MWdOcmHh0shLEsA2wdwk2UJm 5cqHD8D6MWjyXu331h1CXcUMpj4yIHR2N8FEpNRQlBWBWhbGErDfeg80b46B JEpPZ8AKcRk8GPuTBT8lOQxTKOYWJp2umGR/6CigdEznRgkBDKM5Db3yZ9Dc /BGYB16ENtnUwKsq38DEfj8KaQj0GeHfzkGtVHxst7deB4+cwy0orn4N/iRH 7AHQfnKmlwqaBvM5vYxQDE90FL23mUFRRkEOnP7GIi0ZeuK2otd63veafDgS aXA+qiE7f/eq8cTCAetuyKYnDcnSJVkOgbzC/IzSUmmkXLc/YOMV9oy+OFZh AIVpGJzGAPY7fMEMwu+Ryg2W7rDA845oQ40XvuCYF9v6rU+ZfcY4FwZEKCGW PDqtRVZIimxfG0J+NEd7LOq3oWOQv75wOZG+5PKpRhEIlkOhat2JCFvMt+ns NrYEeyq3PK0gIT5RyyfYz4lxkcvC5Xv4mYHAfTMYkxnWFKGoFB9KJqnJJmOe INJwU2BY7uIkb9bXoNn4DkE1DXIsFqN14Tg1FLWMFFUvVej3BVby49enwR+R L6B1sqlW+u93+kQflLxP73bJ//RWSs/fNWsVHgORCVGcLGgACjrGq/8KkIF/ W6CowQFH+XhQ8LvkhzMRfgOKVv0M1vVk2sYJwS5FOw2kRRVNtLhlcDPWqJpz /m00QjiIYYi1MeKzY1fWQIMpyxUXiM+Ur13Dz1fRtWbSrkZpghL9GRcnBEnQ C1h+EHMZzDmNApNAF4LPkcdrjuwAzT4xJVU4QjAA1W/KoTmsjYJtIBaIxG8J GVAxqhxw1qq6ctxz9UdMM7YVYbSV2BRhoe+/y5VI8E1J3uPMoWv06Esqq5F7 Zn5N3RQ0MRKYuMwSeZdOCN7GdFmjsdRw/d8Fur2nBy/RNliSXzwOxoR/CE1m 0ATm8AHIctC4Dl8DVfYA4wAI6tChItUoQ+M0MtUZp0w95Obh3DEEVodCluQ6 maLLQBuy+KZdTiYxCS58AZVljDkok6kxEfhsxCPJSdVS/9dVtdmZCxn/hPE2 m1AUQXbEmgd8K0qFSBvVXZ+wGIskH7sGAnJDpxeVq8xNqBOVRxP5F8pq6nMc XBYC4MxdRMxQoz9bPBfs3M5MxB+msNqgXX8QBjPOBiEnnWNR/FlnqTJZA5SX sUTGPIHEtULFWyJUFrtp75UyjxQx3spPKGN+agkZ8jQO0oz045dlhvoaKrxL tkKeQGE9rjFIRvubLPIpzdu4eYENGX9Be+EWIud8NIc6LgKCpzx4ZQ+prfDW 5vN4PseVV0za9g/JStS7ycu+UEFY3zBcY8WJg3W9qtp2HeH0qbz5NzBmz+HL TyHzFjBj76MF3idKu6sqfGM8HwPx+LLzPmk61Y5qRYvm1BsZZ2SXmBA9GQHE 3Co2iBEmHN81SEyVA05uTUE2G+5nn0/ByBdx0JfGqVBmszQ3qXXEqGQFrY3T AvJyyibcgF2SPkMpiA1KW1xumMY1kXgMmt+0JhZJWk+iDLmxnppIIvdJIVig kyKOdVyVVHyjvic/lmSUUG0QwRehzwkdIQPcyXDosMsrw+BSW7JGXDvnVqTs S+31PvwAqhAM0iH1LKloSZI4KAGUCpwAU9mFa76CoxhsWzFGCHaueie1J51o drM1AcqmleNfO/yXRSHSUixiLRhrHcfCmNvmKn/x5PXNFj6A/1KHJ4AH8Dg8 bYsr0YgwX0bYfFclEBo5r/bVyrAsBKyr/+Eg9WlASjMLpxdqBd6tY9t/PHC5 2UKfjmSkyPnKeLEb3rbKfeYycaw+RLmJiYi18PuCEBQx64GuMedazKuHHWdG oozAsA8Nerh81FqAC8fdT+aSlO045U1cg8M1Vao2qQ+PCM34pHOHGvOFJeeD AW7hZBYuOYioO4BIldNyatjck6RSWQfjcPmLsfYJULaOYyb4/mh0XYKrtejs PYzwHgS1kVOLn+QTCtQIRA8WN3alDJDgjbnjgyrD34Df3b+cpROyMapHK1y8 6GQJL5rHapDPOVSiHfxyk3a6uDMxBXAz54671NjIoR4FZVzwZLJgwneLmiZR g84v0+MgCyUzv5nK3q2NCJ9izSoNvL3zbIsd4US6eBhYidD6rGMxb1FMLkkV qYCmUJy1BK50INPLyUIQyg7QBxwNo7TMa+cgmRRY2ZyyEiCp/kAWMdsdtmSR c7NA6arUG1TlrX5DY05hsQAXo3mTp9nEmWi1otMsDKHyrquML0qjaGVvUkiy Wh+O1rCJeJzAZMKQNYkv5U57AlghpmW/p9PGqIvVerk5CFoFSQKalpJoQIlL 0BwDvg2yLKBMsLl7FAZ7DZKCafJ5riZpXiQcw5Fqnwp7Me5fwr9gZUgZxGE6 DagDG7ywsn94tsppeumg4PQjo+tisgcvzR3sAbJbPFSgfvoR+MVPnGcLo64A vezHUZCfYk2AyWoVQ3LBFNV3eZ5Vi76CiVgMoTFLRGOxb0T19FyWVBS2HIZG hK0j8CX7jaBwYkPbauXyjPKsnHYYpD3UhmJ0OMZIpZw//I9MQJs37CvU/OmZ 5gCYQQuy712be0msUhhL0EQ9exrcBkpg5kwsQn6RvURofhvMTXJhzmlNlFLa rbw57oGa2eiAqr49pU0mHJWU44sGjBRjCEcANCbpEPF6gGpnYEsVtoa/TDIt DR67EhM0RhkY1thNsy3J7jEgqy8nSHOTaDwh6WySAMQk40ieETQNayqnrIl1 QvqmYbXPAcQq6yG8z6REuq2pN4Kno7RMPirRwvvss8/UkeS2NnqVSUcctlUR NbGPQ9UeQlozgKo8Gql+0GEIdfp9+iNKKDPdTZut/CMbAIQVbJ5xsn+2/zkp INE4McG6znq/Q62FLNqu2sAE5fNlU8dhSCmTZAhyCw6KXCgTuUBAjdhfZZq8 k4qGqZyk+TdbVFxGhidzV/lG2PdWOm3wijEQYnq4ETehaA5W8FKVksmjg88n +r36ieD0E3CnRJnE353tjef9L6z85yZX0Q3a0uj1yKjNEsDEVT1XVa3NBcVv htyT4QV1rKBRqqYVXZAV0neDTswuxKK0k4osEQHX7yhMhHvfsTJvtw+MC8/Q CDkOsclimt0+IkqJx44Ss4k0hcFjFPNhH32QEWbSCX+oZU9Xqekjri9xEm/5 BOpxW6N+81fiNL3OvTgyXfwsRq8s4Y6RpJRgY40tbgqjfiLMVvhv/6d6kvQq p7F4F41Fr9iPlepvqe2R2tlSO1rtbqr+Lpy92n2mdtbVTqh2+2pniE/6m2pn pHaxv/POLk+mtujf/rr82d9RG8/wl3VtnsNLW/jGo4a2A+OqeFB4CR7T584u vfaG6snotDEUvT2hc2x13VNqfXt3B5j0GR/lump8Q61IIwI0FL8apjYvadVU /Y+jrzo8M3rtsaa/HppvpHhj+SJSpYkE9dQxRmEoF+c2rZgQN/6rn3mVNODN KBcIUOcGDo30Oj0rJtjDM8tB2HTWME0W564sjqSBUDKVt2LR51kbfbb4wPi4 fvobI09fbW/jvxsbf1Xkqe3xNyOSUs+2fwMifQXfuw+ZLqVnE0pnVJ15xHqK VmctWYPTfugg13GH8O/f/iB31M7gb3OQ1R5/+0HubG3+loNMuvce5EmNzVOq uC2UrBfFd5HkJ5LMialmlgGgA2CYamyC9bc9QFAEQzrAwVMd4A4d4DO12TjJ Xfl3A94bqE1UU+wOdsMnYflqa+P5ow94stmlM6bz+Grtwzfo7XmMFOCeL6di 0R9Jm8QlZUQsNDpOtyZk4L74AzpYFIP9kv2XHHK2pUrSR9kUVHjNFj73/Sxt HUraemPGkyor1DQY9KY6jAIpzVi6cg7c4HvTBLSrBGCyvb3ZrVoxGX9KQ7MG kpBUaWeaqMrwDvJ6kvcOGSnSS8L2uOBcxFpD0HrlGFFe4sOvPqZRmph+VS/2 AtsJOjEpap7ltHMwJqgUlGCuEqn+hTRRFDfz4w62mRzOnhSb491s3Mkhu1qH UdOKFUPfZI2asfJa1WgjxXUkoSvx0/I8VOcCBqSmhIVmCwmpNQGl2ikNAqWF vIzsa6QFIbRz20bRNZ85yYXnArPyTRKjj9M4KnWWIb4F1+Q1BSM9RC9Bt65P U+rFBQHlK7XVxSKJk+nM6TYC8MelW42cothc4mzrRRmonP5eVH4nm6/LljEx 7A8fkOhwNN8oamwS4yH8ThowmA4gFyaOaqlVvAL3k6mp9RV8Y3zN68hsi7Qp hi4JvbVeY7Ylb63hBX2Fu3k023gY69z0w7CrF6e+ccnjdQvDISibxtlADkyy 08UtNucogtBAzUtK1GFpz5wKFmWSKUvLs0Ix03EktaLGcDJEzJ1DbeEZu9YO 2N4mSjTbX+3KTORUkDvQnOIUyQtDmNqWvK0aX66+kpIUa42jN0KApJh6sRBU J7b/Tz2qYzDXjekbmBpG1G464nrHrWNrv1WpUlW6bEqGuHu23YXnIkPTNIaL mYN0CoGagsB4fZfVoeAr3G+Mkmhq7y5ngyvc17YIIuypwZ6oBfKNaA0BfynV TCZR50BawDCdAaR8aQpz10owrRrad/At7f+LxtJqau9BCQ8dfJV6nnSkbb6H 91X1JPg/T0vF5rlpsobUxV9U+MWFQX5uI1z1j6mWTQuogp84wjunjpw6sVum JM2sybc8LeMimjkcwSQuWO8lfoBNISkh1DQpqhoUMYF3yfYEyijdGPxDK7cw +r9m5eiZuarnjwjryqUQAXUYvKLBVsHCJBPQFbkHRl9Rt2diH4G7SWEzgWVP 7+cKG0ZhfeOq9ALDLC7jgLYbMDtjSSOjaby/TcjnUUhRY9S1BgOrnwzdR4J2 n9pDkOMvTmudHpjqpO8T9W+uauAnQUZpNbg+EzGIqLipb+N7uF5clojkILfF /jxdnk7lCgS8DIGKstBNGiVYMNlSB4iNDdPZ3B63iVVaztrUBgj09Gndwexw EivpWUlvOVBUFMd4gxA5bGvsL6i3Qy9Sz7SN69QsEjBFMMDdqSvFmGzXMf1H /+A2IP3Du7UONbXlRnLEwgmdaqrt45VOMmLu7Xdaf2MPVXi1smT8VY8VhIe+ 9VoaUNRM1pbdaV1B1f8qYxONw/vMTbU+5GG8arYFNuIXXyj/66+PiRV8+aUP Mo5vXvzdm6OLH7rUghpvYj07P7q4OL8ArTLcU31+bxQHY/goC7/gb+/hRUP7 Z5ffH13sIZ7vv7k6Pr84ufqB/zo8POFeSjgAjwCvXeIzdXl0gP+lBTVdS/YH UIV+EF+W255I4Be2/1mlkMqTh8xEz3vkhQCkTruMo/pmOhProufVry9AxtJ0 Si7QdUwojk05zpZhp4lpSoHUa7qowItT0Vke2dC52ZavacdxAoCz7oeoqkEj j1dpmAsKAJHdXk04omIivjV12+rOrHliuF3yIZ3rAjAp2G3Ps9hKpWrDZTzC HmTT+lmgkmHakf1+U18ka44ydpdP1tY/UWZ6S9VP07ncbVYiCrldRSgXaBzD P7Hpx8md7wDBjtC8zC2XB4OOzKw7sr7c1sRmSbaPWF7CeeRkHI/gbMvqeh42 RNvKhU06SthaPGn3feEeVG7bSGM3ZRl2tMADo8OrrQ2RJAClv7+N/akITqvV p7ghAEtjWCaSJE182Qi2uqq9I+iCHeLwrAPqAOTO69lMCNOfxNr0msFqAvw4 NdtqZO/rhKLsjLlGd/FgAbbYstlD3ByyMc5oP05rdzOhMeYXtFGzZmI01aCy 5asLsG1gUs7YbqsBuSq5mMEqZhk1ouOjliZeFowLWZdpNrPRe/++eThkLway C5UOsQmdcnVBAp7RlihGjO083s/4EqO6zU75x/i5tHrQYZN4GrzDdLVqNbMT vdnotQa4LgBodbTsXsNhMaXm66DksmqM6Quw+wbC2Wt5Svb62KpaPOlJNIgs I2yNTKwII8ChftQMon3bRoKoV3UJWSst0uqhC8j+XpA+0hxF9mLt0ZfUdNfx bVDJj87Gcz/nwsepDsgw6FpjHeuDyhmxsRXTJFWDFoM2iFXDU/Lv4VUCq+I4 w/SOTI3xQlbMV0+pS1WQWD8XIARGHHpeVf/BGiu9HRU1YVuKxq8bzWjN1SgA zFg7Vo7tlEyC1ElTwGojTGxq9XDLuUqgOYksqllAn+lxCePEc1rZJMgZCOZ2 JHsJkYAQT/zoKhhL3go7Md2imOp6ht56v7fDks1t90j4j4oR7GpcBpiVpnVl VVUmsXHLOkoPBWKx7oF0Hmy3u8Ktj2vTojYgfqa8NOlbhCC2n9egag+fp5Xl eHX1Km/61YjAyTWYjgpB8JyvpsGMSia8kdhGyB6dNmKuWiRXINm58tI4ztRp 8N7fH+uq7UOzOx/1mQD1ANYny/Pq4jVXtA5CSxQg2MrOdmaqVUjhEHXrcDHD F+Oa+IR42NguM1mirUXv9O3NN42aEkKFbetRs9oamLdmlCrv0Wi1LcZFUCyI 14fhYrjRdlHY21qwms8axKM54YZ4ShMCCi8CoS2+XiLWeFjGhCr0svEBODnU tqsL1i5NtThKHClsqoKkv5ejszSyvFysqRUO7XmXMmwDYoQtdVsc0DVKoing Fx429+dzN4v7y8sBX6JIWTqSsE/YYIAkfSxrrwpSSGVZjndP0h1cJv2VRgC1 gngFqdOk2XAriszFOGowTDGpwvWFAa+wARS6wIjPlDjOaAFTQyDVzP2GX9ZR I2wTNtoVjSiX+cjVa7y3gs0ITGnNBZ8AZLhfsxgEKgGMrTDDR6RNmEtJsqUT uXgKwwwSY0Vn2kxnqknFUqjFUTfg1FWkqFXnRSlLKdfq4XAudtf4F3nl6My1 w+WcRoWmKz/jTo2Y6sjWo/h7PkEZnlmBCfuIUul2OYuDkkSdo221lPrqFjhH O5BIFZ6N9DkyajFBMRT6IMwG3hbaZoTVmg1lNiikqqcgMA3xADAIZPyH/DKr RfClPjdHjyq1WegRMwwdLyMvmG6LneEFuxicMDqCgx7EQLGPCnBcTk0N9Uxi GyZum6V/ZFU0dDo+2jmcnjpk+okfsi4auT+qyRTF/ugImzBlvybbP/QBE6qo c4AJjYxQV9n6aJddkw2xTGx66TwqQ+GVdGx1AnWOTrk6lMi5B/pgy7TKZS9I SkGS32rsrUMUVVkexJyl1sP639b3+vD/jb3NvS2iBSTi3ec7z56T4r3AiJPM EDILRVv9SP+doCF87dnu+vO/suvsT6CYgo6w0IG2/vQOtJYTjcbgCR8egQDf GAH/u+i0lrvn2OwjOmBa9H119l6qEVZMPHtz1ST0gmIMxNCjvJ+qyw6xd3iT FcZ6SkM9lb2uT+QFUn7FwgSFep+MNo/Ak6P9w6OL+/Dk94fnp/snZ8sRJQue 1tNah27vHkRZepyLOibxxcwceOUOBkFW3VzS4aSD//2f/ithgVwKpHq9XgeY BwsROmNH2680KiolSCg2Iu6126DVtGPf9mxlzKg6Xq8vSqKQzAmLfFtgiFCK uJsSYXpI2qwJswElGzAXCn+ltgl5cQCXidaRt90L6a+/YuXXltBVH7v+Wh1p c8mLPaSPXv39S/fvXer9cP7rU3ZLArx5fbh/deSKgKuT09fLCPuTqPrih9/I +x/g0A875hqKllirrKV4S11mTfcTYPi2Wnmz1Mu06kUmNrLIGd5w65m6D1Ka U2+519103mt6Cfn1yiVXLWsw96ocVkErWvzytXtvqR064c+7e7Jj0aoKhlX5 0nmVQsZO+4sj9VIu8LzvwppFuZVINq/LfIJUZ+2SvAoGyJUBj82eXDae3Bgy g0/u7myqHVtiM+Ptoxbq82Q4ydIkLXMwFOiGg7mN1XBhdLOmhC293InxRPSl MuYsQyd7Dz1gGHkwbaQaFz27t0uYWUxX2show6iEw+vz5T3qXcA171eg+y3y AtZg7kRFaHlGPwF6CUnXqWbFBINoWLnzUJ9FdzebbH5MPh+jL+dVsAyscqof LNgmWuTFvveijJQzAuqN8LGEPHXkLRuPtfSt2yDhTlyyY7cpOi+zwfS53ZPr T1fuzRYUUjHOocqqxbW1rt6o2kLZKREByDpEfmKuHm4cSQs+mEyelwMWX+ZO XkTe2spq0+EU5tCSG74drkp3w/cv7YDGVm541HZ6XMdcUcpq13Owpbrap8qI w/6dmP1C7kO3iQBGAvUkiEfte9oat1I3GlneUv5XYCN4eNNQChoVxj1H1PE7 Ne7Kyni8p62lm/fCrRsG9q6FOblgbSoKmtympWrVlq46l65qL8vp7+tcNAT8 GAs3kaMkczOImdhoKFK7ppfgUeCQngNx7DnJ1ancItdbGczRZ4Z17QXpn1P5 fYgoF8c145+nsPeDzCgCX5VU7lQZihY7AQnIzZ2KRissiBqXOygqeGhj31IP 1fUWR7B4cQt8yTKom8s4JN8eIXUDp1G4NbGamkimzkVInFnaQvatJrJTTOGT 0OXTcaWBKDbIwdrOxATMV7godbUWfLCXEJhGYw3IG6Xi/ltQUb/SJlJTU6Bs NbYVsvZWFwMStJjqI4r7yOypdaFNS1HLqXNCQ0EzEsJlf1XQ2+nCazlM/d6z mvbXYKJy7SbPi+PUrylyYEwFy+xsxAsHiWIxCI8nAmoohTCb9/WYSokAKRd7 aauqdYFAMZWaI7y80xzNDFgbefNceo6yYTllzTS3N3W3XIqiKTx8HalpfoFy zwhN0XhY0xHNBjN7+WIFUcMWpUmk4kRzCjpyc7+3TVpecD1DE1f5AD33Hhwh BuopAcwFzJson9hrkqfUwCIJnEYFMk11n0LKLS5q9x14S+878LjsPZjmwMty rnwfShOAauHVNWWBifJzOCi9lYiCXK4WUBdAWZMTd0RdJsqHJXaf8dp8kI+9 am5Su4RSXO+yP6QT7CxPtxCcSjcRhBxqDunxAuW5kSNuE/uB6dVrSbA9H95S hAnVM3tYdLU7VdscG588BfrpbtIi9TFyzem45HDlID8V1ztXOjTuOdzzLrQU vdMh1m42XWHz3VRp3K1af+uKU/hhAvn4ce7dc/PdrbkdCTMT4JBuIszRWojV nMiDWA1kcxuYa/mWQgMv3TKj20gP+ivMzs1bgW0IRZl7oo1Xt/VSPk2rFOhN UtHUm9zkwpbVUw6GPsIMc3PZcAfIGYnosVaDLuwJbA4EUtjYoFohErR9hD3v exmEUNOVchRVmeKebd5CUBQg92oFSEgsZeA4TA3lpiNPwvyGJj5HLoeRETUF OzW2qq8ElTGuksg3GHIOjAjS5hJJ/grf6EPKADZOGM7l5hhSAZxG/+vrbsS5 J/eLsd2k7X1xzF7hfWw3dbg876xZEYGtqjDAC2AQsjTADsYYO0RAjHwqb5yl EWhhpAkJHDGOZxrM2HugZRGc1FGk2CVK4khNmNSSzHuVWWUDa7n7dTJyKXjO BCLz8AxiRVWNb+GUUMkv1IZUPyMFAamPuTIJhr6OErIxmtuiW+GEzdXJYRmK e9633P3EXO5SCQGXmOBML14e7G5sbzhXG1KWB18qQazzgO8aknwFoNWoMFen Lh5VTtrkxOVV+t1iimDeKbJhxcpFZ0kbzM3sTX7Uc24dLbUMKOcWcQkRt4jz dWcn24K+5qPNxiabIXHcJTk/jQIPOIalpHml1kfS86Ahb7EdqzgBDFA8oVq6 UqqqfyLbot5PBiWej4Zf5ZRBGs4xbEpC79apUKOb1iQdLJUUGnSzTG0GAALE tvChjBlWtBBkNwgzCym8TxiAmeJlDloC7eZrmxXUpEBLmkBMTb+c1oUhHGGm 4A2SA81Vb+li+rnU8pZckUQ4hp6C0txPUrj1CtUeKGug4J0xAqDFyF6zTNcu i3Hu6qb36YIeQkPchej68oUWK3BYVEu8IJ9yO00xjwtq1bycIdAQwwtYHqaj S1aETW+o7n+sHC78QYvteXixWRVAm6XpiMBcV3AEgSVlEEzTMBry/a7c3Y7Y ViT9sUyXqHll1xjfEsKLM95yjx25CM6wxs84CTCRBUqnSBjyfoA2nCIvfzjZ ozsXqH9Wh9Pe8Y1O1WxPfB6kXZhrE+pXLyj36gVW5mk7RME4MBoyBK662+Tl EoZFt8hJYzj4CvOtbhuoJ4fU/FNkljmUqk4Tg5oB1fVwyCR8wlkrUD1mAeSJ +fSJP3JWqlyXgakJOQuAFPNg3WvKyOYElbOS/1GCWR3kJ8HhdehYFKwzUWdn qZfluwJ7pEgaZ2zXoVhDdDYhkzkthyeAfI1OiIyP0k2ypGokDd+I0VFAxE7p ETdgRZLdZ5JthchbeciYXoQ1D7eBm7xY2XoemsuOi6TGnWzW9z1+jPp1orYO /83ha5bouFFKBaqSRe/Xe6k610UNo8aTj07UKXbqk225wPQ0ac9hy92LuyU1 SgrsW28j+3OhYTZOoBikHDpYvnpzD6iFw+/enByQlEv/BKznCzTxOHJxS+qs 7WDJCegcB0hnAWCQavlanIQjRjpEihir1CWFxoDQvYaT81bDaif2oC6PDkQT ByhQb7k66gRzc1edrZjRGfW6l5ed5GSPtx3ysjGeRdZzFWehfp+s0OHzRn5f TiYhzkgXu9pwhHEs3TP1Fx5ZzYTZ/C7lNVKr2fCR9y6+rAUigyYUBtpeS8sC iBVxx2c8zLRgBKo3cnEJxwrGiXgRlI6B7w/iesEOdQ11vfn27FDzsfCwSS31 zXMJkFxvbwOS1ODtYRVeqmLqkUqwyvU4gjOb3x8IlFnoWibbWu+hpinLo7CU SupxexMpMVu0OIxM8Oqcrz3u0vrqptaOZwcZZ2k5M1Giu7svJF3AeodyQ4SP WnnVFPiUurXg/b/ukm0JVMo+cO9nsz++KvhnhBX//AzHQJUaoHQs/fkZBnDP RFV/qvoni39ogCUbgwEwG8KsxqyauB3W+D9/jv1rFqd6wLgf9tRnILE5vlH/ HPT0ItZfLTpf2L8p3Lz87sXB4hs789qVnfnqIxF2Ad6G5k4RJzUykZodOkZe yMGLxy1kAXLSAPVrj3O599j5NmEhiyrquRHVMoZnds52z9ClF7XfEXadcakJ nB/1tXUwR52yOrocufBLB1w8hIeUAYhgqDZeOkjYQrpHYmH7S+1nNM96XxZm Ok/Zldb7/9jIAH0JyOro6iUuvYG3iyHnYG9+M/QJ/P41Hrcg7nc2W9k9fkTc +s3fK1nx1ap6hdeJX3EL4317F/h37Bn6KNRd+NPC5+p+cIvGH7usp+GyLfyG A2TQVaembfxxEcu7h7/dgyRm//djRrWIj8YKM4ZPTF+Q4tEwRjw5N2Xh5Dp7 jKuNxPVnn8G3KUPT9Io+tPV8tbreK+vaxiBFMm/4uxXr/DSS0SndcKqprXOV eaedlH0sZhXJhkLcuim6c2rfom5+VoB0ldutq6YdU2OLWRYlQ2zc0XUXrEEX SqkqSJqk4ygpX/5tVXipOxjQnbx8ZRMN6eb65EOdgPme5t0GYnAY3VyFJXkg 9uoJZs7cUBerLnMOimIBmXHM8Nvcnssq+RMd3OA9W1wzYDvncxGhlPJEEgnH RsCg0Y9sJYd1fWGaQkopk3I3mpi5ToOmZmCNHbKcjZbXmkLh+2dp4i9qFFVp QhRI1wh0p2aUzA0yOZ3KTScZq+5ms156jdotpRSZ9gZVsSM1ZMrNhVQVbMkh iVo0eiKjvBahbgDTXqYF2BwNrWM4Aasxza6lhSyiN/XNwy1J5yrgNxwqAyrZ r7Qgn2u1M/OhCf8iHq/ax5SiYxxm7A41+vdJUoWjOOIjoIl1wBolf79VrFd/ SFRq8raqQ+CyCauY1vrskDFgbER9Q5cvuLPsL3SUSmVpK+fWbJWyQ6SRXi1k WXkfLFTIaJQok3HYG2TGcjV4odqKydyzBr5ZM9d6usDI+cReU9+h43QGvHUa FcDd4NCpTJfrfxDCOLVtUiT+gik5hxLSrfBes3QGA75xunvB12FUn0Y1GaUm eWwCH9CdC0AWxvWYy5XGPBIujXop2D4LGNluNFW4q/UHk8q81JEEUsVfsbFM m4xTk7Xixu2r5mQucVDTE8yJ7rXS9cIolKbLlF5C9OhUztTSCcTL79jgnCdF XguKSBHAPafpXcu1hG2SKMiZUOaO5H0+mBZjPDayagEH5eNIBIszdIi+qAdZ YOqPbmxmjiSj/LYVoMwQ4q3SlbmvEzBhLM11HIf2nqJG+wiKbTFq4BxH2EKS Ygds32j7N680cIjLVv5O0khSLao7YYxwbqTc4wUVu882nlGifaa55z0zNSPQ MMaGiiahk+cdcQSYMJ1C29o+cIPadB6c4ZK3XCeqummb2Td6ArqNIvWu1D8H 8TznazaJG4sL1ZsFmBrX4dgjYDSZKqhOxaWb2H2SXu3VZXYHtg0j+TQAWTy1 GhTj1+d29qGRFWjQxOm4ul6WwtiwPs8KcIQWaoUb65s7Pby6wvzh0GZ1TyP2 5GIhI1coZGVCphX6E20rfydK0FML73x2WvKFWTAq/PuyYrAGwzPluwhezlWk 2le55WEwNwM5UUCM7LjD9Dy5JtdcNUBQkgQrNob5wmjrCuaHfNvDQ6N/A4oI j7Xn8aXj9+3pHaWRTvNf/5IDsR30+K6ZnrqK4nQYdKVTIaEze/E7XfU9injA EBAMY3T5Uas805vXP8QFdtXD4PTX17tqR/1zCbraRn9jm4b5clIU1AYMu8Rh tfU1yFDcLdZUrAEJrE2Kabx23+h015yZ4etaqc/bg/2D4/0Xr4583gzt/jdu n161IFiy/0XnRC/KAvv9LrYmv9SzQpPbwALi4yBRzUPvNpEC5vl6waXnl7YQ grlFRtqb5wWr8NEUGX3CcZeX5IZV63xZQJrytb7Gw3j1+yt0+M7KoseNG9lr i9QyDbJrriCTwbuYJxoVjaRDkHFRyLkUuxuVckkaODZp6OEtmt7UUM0Ntdhy ZsI07agQLdf6bvJvkMQLTte3V2Zi8Zon12LLxQQ0yBeGawDoMK4pd8RVbqqC bsiLYklPc5gLF8lEJjWKVGDyOyJk8A0W5PkwihAO3Bzq6vQV+zO++3a1Z+/q 4TV4RgWl6niuwuNVYtjfrmPPMzhye3vbg0P1QSUs0owwRMTHGjxGSxtX35uG H/tG8b742FcQLT3PG6wi9Ol4zRYQntQIzb3pJserbrp83w0WJG30Nll4bfU2 e5ty53iFR1XxTg/HN/X57AsWhKQ5GpfpUH/VYJCMOp5kxHZ++eUXRU9Wl8WV 7ciVDMIJzTwUzvKqFcnmenzvFNeCdc279EKy6JIflGxmf+zU7qBTOMs635iL pIx0MKn01tg26U6EbjH6Pkh0cINOiuHbTlpJTTeBabpqpMGqH2Vac7TTkZb7 cZ5K8zsvoDZwRqUBQN04/Zal3gvw8pWszYEHGZr3Ymk2G67dRtcRMLTrsjeb zL6Jwq+qEcjdA9qbN1yl/NgW9giWPMiXvjcw9phJ1DCpyw1t9LxSfOtMaef5 QqYEK/JoRmaUuAg5KBBpu33nHdPCV3hQIE3H+D0q2cv1NBqmMRl4En6jb6Bv Au1x5lh4KxJ1r3BvNJKqXBnUxUdhcEZzXKW4ohqnKbbwYVWPeSS1YuVQKL+C lOwxs0OcQ9zEm7IRUNiGGL3iiHG3xgJhOHNrB7xIiIwEIAQHwTyO/0sMuByP 8fZHyuvh9K8FAqpd0tw5Qd2RrI5XoFaWFA5CJd0tAkkQrsq7LOaAst+WyEi/ vAcHc/zeGL+2huHFjbXPIjPJj7FM8rW35N4sk3fi3JelpFK2Ut0Tqh40dzfF c4+tcAQ21Vxgm3mUaWY2qyjnaqLjGVqKI+rdhdmVaPueWb0VDluxQ9famljc Smu7NVdjV1FTbtTB2MO47nFi18CAWcQ1PMA8OaqMpBs78Ww+U/tD3HysQ74Q 3fuwB4o3RTx0KD0vltotmIUvpTTApz58+HCKhuSLCBYyu0MbCh4dBBl6WtUL jE0liXl8mk4CTIR7kZbDIAyizHxwqAdgl6Sxnpsn38VBGE1//Z+Z+rf/Uia/ /vfCfHCRwojqEAATR7fm4VF8O4fZevD8hlKv5XF+DcZb9Mdr8+DbFLP/X8LM EzB67ZhXExg0B34PJnwR2dVG12kcROrbX/9S5GBQ2tmu0jDEW5ey6sF0Olev A9CBzaN/hkXSUu3mXwA8LoeTWzjEP5tn50Cx6rIA8tJ21iAbpqK5mme//ucM TNvv5gloj3bOaKq+j4ZRkl/zijmT8gOuAtkU8it4btholKGYCMkdgt/k3AlK 4H7bVD5RbCH3Yh/O+rN3e+q3abHNgR6cavepptp9cKqdp5pq58Gptp9qqu0H p9p6qqm2Hpxq86mm2nxwqo2nmmrjwan6TzVV/6Gp+s+faKr+8weneioS7j9I wv2nIuH+gyTcfyoS7j9Iwv2nIuH+gyTcfyoS7j9Iwv2nIuH+gyTcfyoS7j9I wv31p5pq/cGpnopb9C23iDGhMcvp82GSP2b8hS+uLRrwE7Bs2TDe2zH+hrek uSOmw14WpYWf5jQYpTH8+GOiix9/5O/TtWrkY3gbRCn8gSEnZ4QxWFPloAdq ylqQZP5gOhj5s+gmLdaqr3v/B1QY//uE1QAA --> </rfc>