<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.37 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-add-requirements-00" category="info" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.5.0 -->
  <front>
    <title abbrev="ADDREQ">Requirements for Discovering Designated Resolvers</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-add-requirements-00"/>
    <author initials="C." surname="Box" fullname="Chris Box">
      <organization>BT</organization>
      <address>
        <postal>
          <street>2000 Park Avenue</street>
          <city>Bristol</city>
          <country>UK</country>
        </postal>
        <email>chris.box@bt.com</email>
      </address>
    </author>
    <author initials="T." surname="Pauly" fullname="Tommy Pauly">
      <organization>Apple</organization>
      <address>
        <postal>
          <street>One Apple Park Way</street>
          <city>Cupertino, California 95014</city>
          <country>United States of America</country>
        </postal>
        <email>tpauly@apple.com</email>
      </address>
    </author>
    <author initials="C.A." surname="Wood" fullname="Christopher A. Wood">
      <organization>Cloudflare</organization>
      <address>
        <postal>
          <street>101 Townsend St</street>
          <city>San Francisco</city>
          <country>United States of America</country>
        </postal>
        <email>caw@heapingbits.net</email>
      </address>
    </author>
    <author initials="T." surname="Reddy" fullname="Tirumaleswar Reddy">
      <organization>McAfee</organization>
      <address>
        <postal>
          <street>Embassy Golf Link Business Park</street>
          <city>Bangalore</city>
          <country>India</country>
        </postal>
        <email>TirumaleswarReddy_Konda@McAfee.com</email>
      </address>
    </author>
    <author initials="D." surname="Migault" fullname="Daniel Migault">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>8275 Trans Canada Route</street>
          <city>Saint Laurent, QC</city>
          <country>Canada</country>
        </postal>
        <email>daniel.migault@ericsson.com</email>
      </address>
    </author>
    <date year="2021" month="March" day="07"/>
    <area>Internet</area>
    <workgroup>ADD</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>Adaptive DNS Discovery is chartered to define mechanisms that allow clients to discover and select encrypted DNS
resolvers. This document describes one common use case, namely that of clients that connect to a network but where they
cannot securely authenticate the identity of that network. In such cases the client would like to learn which
encrypted DNS resolvers are designated by that network or by the Do53 resolver offered by that network.
It lists requirements that any proposed discovery mechanisms should seek to address.</t>
    </abstract>
    <note>
      <name>Discussion Venues</name>
      <t>Source for this draft can be found at
  <eref target="https://github.com/ietf-wg-add/draft-ietf-add-requirements/"/>.</t>
      <t>Discussion of this document and associated solutions takes place in the
  ADD Working Group mailing list (add@ietf.org), which is archived at
  <eref target="https://mailarchive.ietf.org/arch/browse/add/"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>Several protocols for protecting DNS traffic with encrypted transports have been defined, such as DNS-over-TLS
(DoT) <xref target="RFC7858" format="default"/> and DNS-over-HTTPS (DoH) <xref target="RFC8484" format="default"/>. Encrypted DNS can provide many security and privacy
benefits for network clients.</t>
      <t>While it is possible for clients to statically configure encrypted DNS resolvers to use, dynamic discovery and
provisioning of encrypted resolvers can expand the usefulness and applicability of encrypted DNS to many more use cases.</t>
      <t>The Adaptive DNS Discovery (ADD) Working Group is chartered to define mechanisms that allow clients to automatically
discover and select encrypted DNS resolvers in a wide variety of network environments. This document describes one common
use case, namely that of clients that connect to a network but where they cannot securely authenticate
that network. Whether the network required credentials before the client was permitted to join is irrelevant; the client
still cannot be sure that it has connected to the network it was expecting.</t>
      <t>In such cases the client would like to learn which encrypted DNS resolvers are designated by that network, or by the Do53
resolver offered by that network. It lists requirements that any proposed discovery mechanisms should seek to address.
They can do this either by providing a solution, or by explicitly stating why it is not in scope.</t>
      <section anchor="requirements-language" numbered="true" toc="default">
        <name>Requirements language</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/>
when, and only when, they appear in all capitals, as shown here.</t>
      </section>
    </section>
    <section anchor="terminology" numbered="true" toc="default">
      <name>Terminology</name>
      <t>This document makes use of the following terms.</t>
      <t>Encrypted DNS: DNS-over-HTTPS <xref target="RFC8484" format="default"/>, DNS-over-TLS <xref target="RFC7858" format="default"/>, or any other encrypted DNS technology that
the IETF may publish, such as DNS-over-QUIC <xref target="I-D.ietf-dprive-dnsoquic" format="default"/>.</t>
      <t>Do53: Unencrypted DNS over UDP port 53, or TCP port 53 <xref target="RFC1035" format="default"/>.</t>
      <t>Designated: See <xref target="designation" format="default"/>.</t>
      <t>Designator: The network or resolver that issued the designation.</t>
    </section>
    <section anchor="use-case-description" numbered="true" toc="default">
      <name>Use case description</name>
      <t>It is often the case that a client possesses no specific configuration for how to operate DNS, and at some point
joins a network that it cannot authenticate. It may have no prior knowledge of the network, or it may have connected
previously to a network that looked the same. In either case the usual behaviour, because of lack of specific
configuration, is to dynamically discover the network's designated Do53 resolver and use it. This long-standing practice
works in nearly all networks, but presents a number of privacy and security risks that were the motivation for the
development of encrypted DNS.</t>
      <t>The network's designated Do53 resolver may have a number of properties that differ from a generic resolver.
It may be able to answer names that are not known globally, it may exclude some names (for positive or negative
reasons), and it may provide address answers that have improved proximity. In this use case it is assumed that
the user who chose to join this network would also like to make use of these properties of the network's unencrypted resolver,
at least some of the time. However they would like to use an encrypted DNS protocol rather than Do53.</t>
      <t>Using an encrypted and authenticated resolver can provide several benefits that are not possible if only unencrypted DNS is used:</t>
      <ul spacing="normal">
        <li>Prevent other devices on the network from observing client DNS messages</li>
        <li>Authenticate that the DNS resolver is the correct one</li>
        <li>Verify that answers come from the selected DNS resolver</li>
      </ul>
      <t>To meet this case there should be a means by which the client can learn how to contact a set of encrypted DNS resolvers that
are designated by the network it has joined.</t>
      <section anchor="designation" numbered="true" toc="default">
        <name>Designation</name>
        <t>Designation is the process by which a local network or a resolver can point clients towards a particular set of resolvers.
This is not a new concept, as networks have been able to dynamically designate Do53 resolvers for decades (see <xref target="network" format="default"/>).
However here we extend the concept in two ways:</t>
        <ul spacing="normal">
          <li>To allow resolvers to designate other resolvers</li>
          <li>The inclusion of support for encrypted DNS</li>
        </ul>
        <t>The designated set could be empty, or it could list the contact details (such as DoH URI Template) of DNS resolvers that it recommends.
It is not required that there be any relationship between the resolvers in the set, simply that all of them are options that the
designator asserts are safe and appropriate for the client to use without user intervention.</t>
        <t>There are two possible sources of designation.</t>
        <ul spacing="normal">
          <li>The local network can designate one or more encrypted DNS resolvers (B, C, etc) in addition to any Do53 resolver (A) it may offer. This is known as network-identified.</li>
          <li>During communication with the (often unencrypted) resolver (A), this resolver can designate one or more encrypted DNS resolvers (B, C, etc). This is known as resolver-identified.</li>
        </ul>
        <t>Network-identified has the advantages that it derives from the same source of information as the network's Do53 announcement, and
removes the need to talk to the Do53 resolver at all. However it cannot be the sole mechanism, at least for several years, since
there is a large installed base of local network equipment that is difficult to upgrade with new features. Hence the second mechanism
should support being able to designate resolvers using only existing widely-deployed DNS features.</t>
      </section>
      <section anchor="local-addressing" numbered="true" toc="default">
        <name>Local addressing</name>
        <t>Many networks offer a Do53 resolver on an address that is not globally meaningful, e.g. <xref target="RFC1918" format="default"/>, link-local
or unique local addresses. To support the discovery of encrypted DNS in these environments, a means is needed for
the discovery process to work from a locally-addressed Do53 resolver to an encrypted DNS resolver that is accessible
either at the same (local) address, or at a different global address. Both options need to be supported.</t>
      </section>
      <section anchor="use-of-designation-information" numbered="true" toc="default">
        <name>Use of designation information</name>
        <t>After the client receives designation information, it must come to a decision on whether and when to use any of the
designated resolvers.</t>
        <t>In the case of resolver-identified designation, it would be advantageous for a solution to enable the client to
validate the source of the assertion in some way. For example it may be possible to verify that the designation
comes from an entity who already has full control of the client's Do53 queries. Network-identified designation should
not require this, unless the network-identified resolver in turn initiated a new resolver-identified designation.
It would be beneficial to extend such a verification process to defend against attackers that have only transient
control of such queries.</t>
        <t>Clients may also seek to validate the identity of the designated resolver, beyond what is required by the relevant
protocol. Authors of solution specifications should be aware that clients may impose arbitrary additional
requirements and heuristics as they see fit.</t>
      </section>
      <section anchor="network" numbered="true" toc="default">
        <name>Network-identified designated resolvers</name>
        <t>DNS servers are often provisioned by a network as part of DHCP options <xref target="RFC2132" format="default"/>,
IPv6 Router Advertisement (RA) options <xref target="RFC8106" format="default"/>, Point-to-Point Protocol (PPP) <xref target="RFC1877" format="default"/>, or
3GPP Protocol Configuration Options (TS24.008). Historically this is usually one or more Do53 resolver IP addresses,
to be used for traditional unencrypted DNS.</t>
        <t>A solution is required that enhances the set of information delivered to include details of one or more
designated encrypted DNS resolvers, or states that there are none. Such resolvers could be on the local network, somewhere
upstream, or on the public Internet.</t>
      </section>
      <section anchor="resolver-identified-designated-resolvers" numbered="true" toc="default">
        <name>Resolver-identified designated resolvers</name>
        <t>To support cases where the network is unable to identify an encrypted resolver, it should be possible to learn
the details of one or more designated encrypted DNS resolvers by communicating with the network's designated
Do53 resolver. This should involve an exchange that uses standard DNS messages that can be
handled, or forwarded, by existing deployed software.</t>
        <t>Each resolver in the set may be at a different network location, which leads to several subcases for the mapping from Do53
to a particular designated resolver.</t>
        <section anchor="local-to-local" numbered="true" toc="default">
          <name>Local to local</name>
          <t>If the local resolver has been upgraded to support encrypted DNS, the client may not initially be aware that its local resolver
supports it. Discovering this may require communication with the local resolver, or an upstream resolver, over Do53.
Clients that choose to use this local encrypted DNS gain the benefits of encryption while retaining the benefits
of a local caching resolver with knowledge of the local topology.</t>
          <t>Clients will be aware when the designated resolver has the same IP address as the Do53 (after looking up its name if required). They
can use this information in their decision-making as to the level of trust to place in the designated resolver.
In some networks it will not be possible to deploy encrypted DNS on the same IP address, e.g. because of the increased
resource requirements of encrypted DNS. Discovery solutions should work in the presence of a change to a different
local IP address.</t>
          <t>An additional benefit of using a local resolver occurs with IoT devices. A common usage pattern for such devices
is for it to "call home" to a service that resides on the public Internet, where that service is referenced through a
domain name. As discussed in Manufacturer Usage Description Specification <xref target="RFC8520" format="default"/>, because these devices
tend to require access to very few sites, all other access should be considered suspect. However, if the query
is not accessible for inspection, it becomes quite difficult for the infrastructure to suspect anything.</t>
        </section>
        <section anchor="local-to-upstream" numbered="true" toc="default">
          <name>Local to upstream</name>
          <t>It is frequently the case that Do53 resolvers announced by home networks are difficult to upgrade to support encrypted operation.
In such cases it is possible that the only option for encrypted operation is to refer to a separate globally-addressed
encrypted DNS resolver, somewhere upstream. Other networks may choose deploy their encrypted DNS resolver away from the
local network, for other reasons.</t>
          <t>The use of an upstream resolver can mean the loss of local knowledge, such as the ability to respond to queries for
locally-relevant names. Solutions should consider how to guide clients when to direct their queries to the local Do53.
For example this could be through pre-emptive communication ("if you ever need to query *.example.com, use your local Do53"),
or reactively ("I don't know the answer to that, but your local Do53 should know").</t>
        </section>
        <section anchor="public-to-public" numbered="true" toc="default">
          <name>Public to public</name>
          <t>In cases where the local network has designated a Do53 resolver on the public Internet, this resolver may designate its
own or another public encrypted DNS service. Since public IP addresses may appear in TLS certificates, solutions may
use this as one way to validate that the designated encrypted resolver is legitimately associated with the original Do53.</t>
        </section>
      </section>
      <section anchor="identification-over-an-encrypted-channel" numbered="true" toc="default">
        <name>Identification over an encrypted channel</name>
        <t>In cases where the designation is delivered over an authenticated and encrypted channel, such as when one encrypted DNS
resolver designates another, one form of attack is removed. Specifically, clients may be more confident that the received
designation was actually sent by the designator. Clients may take this into account when deciding whether to follow the
designation.</t>
      </section>
    </section>
    <section anchor="priv-sec" numbered="true" toc="default">
      <name>Privacy and security requirements</name>
      <t>Encrypted (and authenticated) DNS improves the privacy and security of DNS queries and answers in the presence of malicious
attackers. Such attackers are assumed to interfere with or otherwise impede DNS traffic and corresponding
discovery mechanisms. They may be on-path or off-path between the client and entities with which the client
communicates <xref target="RFC3552" format="default"/>. These attackers can inject, tamper, or otherwise interfere with traffic as needed.
Given these capabilities, an attacker may have a variety of goals, including, though not limited to:</t>
      <ul spacing="normal">
        <li>Monitor and profile clients by observing unencrypted DNS traffic</li>
        <li>Modify unencrypted DNS traffic to filter or augment the user experience</li>
        <li>Block encrypted DNS</li>
      </ul>
      <t>Given this type of attacker, resolver discovery mechanisms must be designed carefully to not worsen a client's security or
privacy posture. In particular, attackers under consideration must not be able to:</t>
      <ul spacing="normal">
        <li>Redirect secure DNS traffic to themselves when they would not otherwise handle DNS traffic.</li>
        <li>Override or interfere with the resolver preferences of a user or administrator.</li>
        <li>Cause clients to use a discovered resolver which has no designation from a client-known entity.</li>
      </ul>
      <t>When discovering DNS resolvers on a local network, clients have no mechanism to distinguish between cases 
where an active attacker with the above capabilities is interfering with discovery, and situations wherein 
the network has no encrypted resolver. Absent such a mechanism, an attacker can always succeed in these
goals. Therefore, in such circumstances, viable solutions for local DNS resolver discovery should consider 
weaker attackers, such as those with only passive eavesdropping capabilities. It is unknown whether such
relaxations represent a realistic attacker in practice. Thus, local discovery solutions designed around
this threat model may have limited value.</t>
    </section>
    <section anchor="requirements-summary" numbered="true" toc="default">
      <name>Statement of Requirements</name>
      <t>This section lists requirements that flow from the above sections.</t>
      <table align="center">
        <thead>
          <tr>
            <th align="left">Requirement</th>
            <th align="left">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">R1.1</td>
            <td align="left">Discovery SHOULD provide a local network the ability to announce to clients a set of, or absence of, designated resolvers.</td>
          </tr>
          <tr>
            <td align="left">R1.2</td>
            <td align="left">Discovery SHOULD provide a resolver the ability to announce to clients a set of, or absence of, designated resolvers.</td>
          </tr>
          <tr>
            <td align="left">R1.3</td>
            <td align="left">Discovery SHOULD support all encrypted DNS protocols standardised by the IETF.</td>
          </tr>
          <tr>
            <td align="left">R2.1</td>
            <td align="left">Networks SHOULD be able to announce one or more designated encrypted DNS resolvers using existing mechanisms such as DHCPv4, DHCPv6, IPv6 Router Advertisement, and the Point-to-Point Protocol.</td>
          </tr>
          <tr>
            <td align="left">R2.2</td>
            <td align="left">The format for resolver designation SHOULD be specified such that provisioning mechanisms defined outside of the IETF can advertise encrypted DNS resolvers.</td>
          </tr>
          <tr>
            <td align="left">R2.3</td>
            <td align="left">This format SHOULD convey, at minimum, the information the client needs to make contact with each designated resolver.</td>
          </tr>
          <tr>
            <td align="left">R2.4</td>
            <td align="left">This format MAY convey additional resolver information.</td>
          </tr>
          <tr>
            <td align="left">R3.1</td>
            <td align="left">In resolver-identified designation (R1.2), the communication with the designator MAY be encrypted or not, depending on the capability of the resolver.</td>
          </tr>
          <tr>
            <td align="left">R3.2</td>
            <td align="left">In resolver-identified designation (R1.2), that resolver MAY be locally or globally reachable. Both options SHOULD be supported.</td>
          </tr>
          <tr>
            <td align="left">R4.1</td>
            <td align="left">If the local network resolver is a forwarder that does not offer encrypted DNS service, an upstream encrypted resolver SHOULD be retrievable via queries sent to that forwarder.</td>
          </tr>
          <tr>
            <td align="left">R4.2</td>
            <td align="left">Achieving requirement 4.1 SHOULD NOT require any changes to DNS forwarders hosted on non-upgradable legacy network devices.</td>
          </tr>
          <tr>
            <td align="left">R5.1</td>
            <td align="left">Discovery MUST NOT worsen a client's security or privacy posture.</td>
          </tr>
          <tr>
            <td align="left">R5.2</td>
            <td align="left">Threat modelling MUST assume that there is a passive eavesdropping attacker on the local network.</td>
          </tr>
          <tr>
            <td align="left">R5.3</td>
            <td align="left">Threat modelling MUST assume that an attacker can actively attack from outside the local network.</td>
          </tr>
          <tr>
            <td align="left">R5.4</td>
            <td align="left">Attackers MUST NOT be able to redirect encrypted DNS traffic to themselves when they would not otherwise handle DNS traffic.</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>See <xref target="priv-sec" format="default"/>.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <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" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <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>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="RFC7858" target="https://www.rfc-editor.org/info/rfc7858">
          <front>
            <title>Specification for DNS over Transport Layer Security (TLS)</title>
            <author fullname="Z. Hu" initials="Z." surname="Hu">
              <organization/>
            </author>
            <author fullname="L. Zhu" initials="L." surname="Zhu">
              <organization/>
            </author>
            <author fullname="J. Heidemann" initials="J." surname="Heidemann">
              <organization/>
            </author>
            <author fullname="A. Mankin" initials="A." surname="Mankin">
              <organization/>
            </author>
            <author fullname="D. Wessels" initials="D." surname="Wessels">
              <organization/>
            </author>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman">
              <organization/>
            </author>
            <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="RFC8484" target="https://www.rfc-editor.org/info/rfc8484">
          <front>
            <title>DNS Queries over HTTPS (DoH)</title>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman">
              <organization/>
            </author>
            <author fullname="P. McManus" initials="P." surname="McManus">
              <organization/>
            </author>
            <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="I-D.ietf-dprive-dnsoquic" target="https://www.ietf.org/archive/id/draft-ietf-dprive-dnsoquic-02.txt">
          <front>
            <title>Specification of DNS over Dedicated QUIC Connections</title>
            <author fullname="Christian Huitema">
              <organization>Private Octopus Inc.</organization>
            </author>
            <author fullname="Allison Mankin">
              <organization>Salesforce</organization>
            </author>
            <author fullname="Sara Dickinson">
              <organization>Sinodun IT</organization>
            </author>
            <date day="22" month="February" year="2021"/>
            <abstract>
              <t>   This document describes the use of QUIC to provide transport privacy
   for DNS.  The encryption provided by QUIC has similar properties to
   that provided by TLS, while QUIC transport eliminates the head-of-
   line blocking issues inherent with TCP and provides more efficient
   error corrections than UDP.  DNS over QUIC (DoQ) has privacy
   properties similar to DNS over TLS (DoT) specified in RFC7858, and
   latency characteristics similar to classic DNS over UDP.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-dprive-dnsoquic-02"/>
        </reference>
        <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1035">
          <front>
            <title>Domain names - implementation and specification</title>
            <author fullname="P.V. Mockapetris" initials="P.V." surname="Mockapetris">
              <organization/>
            </author>
            <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>
        <reference anchor="RFC1918" target="https://www.rfc-editor.org/info/rfc1918">
          <front>
            <title>Address Allocation for Private Internets</title>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter">
              <organization/>
            </author>
            <author fullname="B. Moskowitz" initials="B." surname="Moskowitz">
              <organization/>
            </author>
            <author fullname="D. Karrenberg" initials="D." surname="Karrenberg">
              <organization/>
            </author>
            <author fullname="G. J. de Groot" initials="G. J." surname="de Groot">
              <organization/>
            </author>
            <author fullname="E. Lear" initials="E." surname="Lear">
              <organization/>
            </author>
            <date month="February" year="1996"/>
            <abstract>
              <t>This document describes address allocation for private internets.  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="5"/>
          <seriesInfo name="RFC" value="1918"/>
          <seriesInfo name="DOI" value="10.17487/RFC1918"/>
        </reference>
        <reference anchor="RFC2132" target="https://www.rfc-editor.org/info/rfc2132">
          <front>
            <title>DHCP Options and BOOTP Vendor Extensions</title>
            <author fullname="S. Alexander" initials="S." surname="Alexander">
              <organization/>
            </author>
            <author fullname="R. Droms" initials="R." surname="Droms">
              <organization/>
            </author>
            <date month="March" year="1997"/>
            <abstract>
              <t>This document specifies the current set of DHCP options.  Future options will be specified in separate RFCs.  The current list of valid options is also available in ftp://ftp.isi.edu/in-notes/iana/assignments. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2132"/>
          <seriesInfo name="DOI" value="10.17487/RFC2132"/>
        </reference>
        <reference anchor="RFC8106" target="https://www.rfc-editor.org/info/rfc8106">
          <front>
            <title>IPv6 Router Advertisement Options for DNS Configuration</title>
            <author fullname="J. Jeong" initials="J." surname="Jeong">
              <organization/>
            </author>
            <author fullname="S. Park" initials="S." surname="Park">
              <organization/>
            </author>
            <author fullname="L. Beloeil" initials="L." surname="Beloeil">
              <organization/>
            </author>
            <author fullname="S. Madanapalli" initials="S." surname="Madanapalli">
              <organization/>
            </author>
            <date month="March" year="2017"/>
            <abstract>
              <t>This document specifies IPv6 Router Advertisement (RA) options (called "DNS RA options") to allow IPv6 routers to advertise a list of DNS Recursive Server Addresses and a DNS Search List to IPv6 hosts.</t>
              <t>This document, which obsoletes RFC 6106, defines a higher default value of the lifetime of the DNS RA options to reduce the likelihood of expiry of the options on links with a relatively high rate of packet loss.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8106"/>
          <seriesInfo name="DOI" value="10.17487/RFC8106"/>
        </reference>
        <reference anchor="RFC1877" target="https://www.rfc-editor.org/info/rfc1877">
          <front>
            <title>PPP Internet Protocol Control Protocol Extensions for Name Server Addresses</title>
            <author fullname="S. Cobb" initials="S." surname="Cobb">
              <organization/>
            </author>
            <date month="December" year="1995"/>
            <abstract>
              <t>This document extends the NCP for establishing and configuring the Internet Protocol over PPP [2], defining the negotiation of primary and secondary Domain Name System (DNS) [3] and NetBIOS Name Server (NBNS) [4] addresses.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1877"/>
          <seriesInfo name="DOI" value="10.17487/RFC1877"/>
        </reference>
        <reference anchor="RFC8520" target="https://www.rfc-editor.org/info/rfc8520">
          <front>
            <title>Manufacturer Usage Description Specification</title>
            <author fullname="E. Lear" initials="E." surname="Lear">
              <organization/>
            </author>
            <author fullname="R. Droms" initials="R." surname="Droms">
              <organization/>
            </author>
            <author fullname="D. Romascanu" initials="D." surname="Romascanu">
              <organization/>
            </author>
            <date month="March" year="2019"/>
            <abstract>
              <t>This memo specifies a component-based architecture for Manufacturer Usage Descriptions (MUDs).  The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function.  The initial focus is on access control.  Later work can delve into other aspects.</t>
              <t>This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, a Link Layer Discovery Protocol (LLDP) TLV, a URL, an X.509 certificate extension, and a means to sign and verify the descriptions.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8520"/>
          <seriesInfo name="DOI" value="10.17487/RFC8520"/>
        </reference>
        <reference anchor="RFC3552" target="https://www.rfc-editor.org/info/rfc3552">
          <front>
            <title>Guidelines for Writing RFC Text on Security Considerations</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla">
              <organization/>
            </author>
            <author fullname="B. Korver" initials="B." surname="Korver">
              <organization/>
            </author>
            <date month="July" year="2003"/>
            <abstract>
              <t>All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak.  This document provides guidelines to RFC authors on how to write a good Security Considerations section.   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="72"/>
          <seriesInfo name="RFC" value="3552"/>
          <seriesInfo name="DOI" value="10.17487/RFC3552"/>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgments" toc="default">
      <name>Acknowledgments</name>
      <t>This document was started based on discussion during the ADD meeting of IETF108, subsequent meetings,
on the list, and with text from draft-pauly-add-requirements. In particular this document was informed by contributions
from Martin Thomson, Eric Rescorla, Tommy Jensen, Ben Schwartz, Paul Hoffman, Ralf Weber, Michael Richardson,
Mohamed Boucadair, Sanjay Mishra, Jim Reid, Neil Cook, Nic Leymann, Andrew Campling, Eric Orth, Ted Hardie,
Paul Vixie, Vittorio Bertola, and Vinny Parla.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAO/HRGAAA7VcbXMbuZH+Pr8Cp/0QKUWyJL9kvbq6upUl71qJZSuWnK3U
1VUKnAFFRMMBM5gRzXP83+/pbgCDoajdbO6SSmKJHAKNRvfTT79Q0+m06GxX
m1N18NH8rbetWZmm82rhWnVhfekeTGubO3VhvL1rdGcq9dF4V+Nlf1Do+bw1
D/js2cXFxzd/PCgqVzZ6hdWqVi+6qTXdYqqratpma0+Pj4sSK925dnuqbLNw
RWHX7anq2t53z46Pvzt+VujW6FN12XSmbUxXbFx7f9e6fn2qsFVxb7Z4pRoe
mF7QfkXhO91Uf9G1ayDD1vhibU/Vf3WunCjv2q41C4+ftiv64b+LQvfd0rWn
hVJT/E9BGH+qzmfqtfvMv8tZzpet9ek1196dqte3/LPHiqY7VRD6WF3r9l6d
PZimN/xmaTuc7zU+27laXnF909GhP/2BfzcrbetTVdL6s7n7/P28m5VuNRbn
doaV+3qbCXTrVqtt9iqLdLZe12Yk1YfGyKsi2k96m8l13q9N29nGTdS5ri3u
u7Fafffy+OTFjqyNpVu/6XBlXrmFOlvBJEqdn6Bbkyzfa9rs8Qmg0LOZ+sm5
alepnVsvTTt6l89yXru+WtQwgtGBTo5PcPZN401DAmWnudGN+qHVTUkm++vl
L/Xm+6XRa1j63HZ+Ria3ewkfTVWNLsG2/UrXxm90m73J8l+VZwszlv3Naq69
36ofXb1Q72xzr1733jbGe76d3GJ0cwcLDmdP57hsKjsSOheA9//LH1xT6e9l
88fXcDFTV/YOF9Vlp7jQjTX16A0+wRuoyHvXjM7w6tm3L9Ut1OxhM42utPro
+s6M7sE2nXqn+xaePlF/PB+fQT6VH6Li/Wcr2f97E7Zl6Yuice1Kd/bBkIt+
/OH82cnJd6dAC2BGegP/mU6nSs8hpS6BAWeVXtNb6uL9TcKwrYILl0vdAi9g
DZ1TlVlA/Wpl8Gpj/cqrbqk7pevabVRZW4ZBei6soIAsypvalJ0yTdlu12RW
2KNoIyDO1O0S2wAEe0I6bOHL1s7J7LATjrRyjeo9ftTeTPgG6q1sC7tMe9Lv
pWsa2gkCaAVzJABU875TGziMwTNmCxBtGtdBphLqxkKEZljBErjSE8pW9Gu3
pdV51bDQDMakfF8uWRDPz8ruauP6ulK1vTe0dW1022BLWy6L0ZlVOrOCk9JB
Y3SYb0dbwZrkJVyHe/k8fQ4iLfgmdp6fFZcdtvfQQx4zwt00W7Vu3dp5fLBK
N5tdoV+y/N6Ye1ZdVWFDPxMTWdmqAkQW31DYaF3Vl52FhRc3BsvompZGpHC1
RD/6DTfAwQ8HhnEtFrZUG9sts/vvyBvWCC1eLTVsbm5ME0yrmoiOtacFpiTr
9PbdTXF44W6P1Jcv/wmD/vbVy1dfv7JppWfe3t5e3yg89TY+9erFqxdfv87U
m9EV4PpJyAfcslqRatgQ6LppuXVrH3S5LeamgTQhosdLCaYGvfy0tIgPtiP3
gF69neNXejTzAARVMqoaJgazXNg7mJt6yhzwfE/GXW1h3tDXcE2QqmB5PbRO
aoVVDqsMK9C5zOc1HYLMBqst+pqBkl6iGANh5rYOhj0WBNuzLlbAz+RqdNBb
LPUEMhyCUhwhArX3JNWPRDP+abSAD7pVVFfxi9iRHds28PQNXeaDbkGc+HDx
wkzzYFvXsC/8IyhT/L+hjPo5lCnGqPLT0nQUz+na4mrBiytV4v/ocxr+NTcL
J+sn3IGXgJCsbNeJwv/qoBAc07bY1Tzopvv37HkQPVvXUba5gafxepAGtrzE
YuFoslgukJXNYGHi3bCNX4+GT97iz6PhZAcOi1+EQ/UvgcPbcLEwIiwFLRvL
FzffBkQhR9CgzHVPEBnFhs7ge0gXtoIJeGiz3Ab0oIvAlUGKtYFOi2++UaOM
ogat6fWdEVcEg1dE4b06uPp0c3swkX/V+w/8M5KJT5cf31zQzzdvz969Sz/E
J27efvj0Du8X4afhk+cfrq7evL+QD+NVtfPS1dmf8Q955MGH69vLD+/P3h2Q
5KSIInkVXSRUBtOylGOsW0P3CcOJ7lbRZ16fX6uTF4DpQE6A5V++/BtB9sm3
gOwCftTIXq6B1uRXdivgGMyJvZ4NeW07eMaEdsCtbRpFHjijYHVLbtG42t1t
SXe566/0PQyWfJ0jPCE3ARJdDGReEe6NYsbpbpTJ48tkFKZGAYoNgMzNsZns
QC7sTcRjsyxIjss3tz9AOphTP4f5LveEQlzwOW1yOb2YcZ5YUcgy06rxDmZT
IuAVBTkJUfjxjgypny6uFQVe9fI5i3d7nn4Psp8cP38pqySHBEM1Bm9HF4Vx
j55AMqhuM7DAuslFBV28740EpmwNtnf1KWBuMJG1sItL9g636Ewj0EJPiP9G
mKHAa+i/cCLlgUuWmEaMtbwDx2TYBdkkHKwligdViG1hLe9WBuvAVgtCTp/h
eUTFAJY5fjO80DUxd8HmuALsc9+4TW2qu2RWOXzZ7BMJZBHYzYN1vadI43Y3
r527D0rziEZMPwPiBG1QrO5BweYG62KddoIfSx0su9blPf0bVVOMVDMh/VKI
FsbBPCUF3kz63/gcmcdslLRIm9kuRNfaNXdTriaQM60ps7Cl4ToEh+oGzkvB
EL4blofvUuSEIjzjHXTQr+YM7ZGMBRoQWBry3/uA5JsQbUFbwE+GC8dLRQV2
Wrs1+/su3Qm85h84YLqysViOiwAmiFFZikJq0boVnrsDc0Q6ltZgak7rABM1
0US66MZDduYYMSi1hkMB2VCj7mo3pwuZRLMxn8u6B8dhe5WPHTLbdt4yNWOW
ese5HaKjRi7oj8TKwwqR8oZgFkQIu/MR7YqeMcSB3WcLSrFli+NAF3lRCFpI
yYGk1QBceL8FTDuwP+dNIiL82WjTwgqA1i5RAwLiDIfxQ6bbsRPhlvrmMe+d
FOQoOHDw5fChzpK/vHUbE6x5u0NKaFMizCOAjJmMgocIIcMjZBAwmE+eg3v+
EcaQDBYGqUZJhg95UkopRheesge7kGDX76C2aL9Cxj5V14ALNmgWDyYO5yL+
OmJqbIdujht5IJEDWNJSMBsPKuGx0tk46YVATK4yUsbwQMDrQCVBdsGS8bk/
wbYX20ikxIRKUjzvylDFfH2H4cHhcNvGdGISEb6gg8C1yDnwANVI5ttAFjNG
SfoUHhnAHFDWAVyIbZnHDp4nVmSi++jliNoS9SWLNRXFpC+n6ps81BEpuxh+
V0Pgo9+CnnDdJTlWEl8DDQGreVDUOxZCgSdLgzaamJ1Wa2RQtuxrEJ1wuqFW
IlQmEEcKGBvSRWnWHZOgiKpZWh1BZwT0URljvJN0t0IIqQhhPAf9sOTXr0ez
InoUX90G6eznzoSEM0jBlHDjkCxsPWz2twoXL+neKNkdBBBbTm/SJ6gG0wDw
KOPlANavmaKQcOMaEuN4drOkrjIalFmtu20MvmVwf99Fadl+KtNpW9NZI9Fy
b9Wnj5egj6t1jTWPSIDHJkVLwi2QNeL8fhboCt1JytyiV7WGrRs0ECkZm4xf
2jVe6zYmkJtROitOhOv0QOSYglLEFGxbMXQ4pkk+bVJUiYoROhuqrNBzXi9M
LAAAWltLKg8xMjpXgEMq0TiEYsZyZu+ENULTbvkYTO5xtwmzPChHKVA9pnVy
iWP758RpuPaGgxYXHJ7y3cPXE3U+UaYrj5jxV5Vlj+MIut0J1YdnRzHWcVYY
GAn+KzF1cI6pFPgWlrz9t+qi51YN3WXfECDSFlyvIh0dCgXNUPlotOdEEG3k
1//0KffIHJ8bCV28f3QShjASWFeU9RPMJ0OtDKUIPsNoMIhweXR3qTDseMtx
1GUtEwfu4d8rrk9TSQr5qXsw8eFQL9D1fawb7BBFtuAhIg+8ei4MDs9lZaKJ
SlGdbDVG0C0iADWiAA5UQyGTJDICotveEWSAeNY14bsOBHhkf+SXwgdDSsLE
jXBWXGB91wL25OYJVhdGdz1OAKlxdUFMuDycKQlaxFJBQKi5YZYQETfZwXDb
PfMIjvTmM9CIqwG4xno7rcy6dttgH2l3Lgm845ME7oaPFMUVeUBCe7Z4aGKn
WNwQYYmML56atB4JJodcrLfoa1jg7G4Wc8DvTjh/rW1zP2U1FrgHuMff+ujW
YVnSDyA+KoAzvFRTeRSXBd68GVXmJin0M1s0FR7GtRfjtWJ8hV4HmhNiLJQX
xdll8IwVT/heUokuaWmCtCIkWIEQsaMc8h5H8cSS1VPwFeJPFiX6TJUi9RpR
LWF0dA+ut7Ga2Ie/kdR3jJ25LxbFGbBnBNUIOYZd+YmPSMLQ+05IGeeUCOdW
IilV4aTUSBGBqioDFQ7djiGQ5MXlmeJqX8rDM0aSQ1AmFAuySdQuYhJSXfbo
oUhGEphGPCYPScWDrm0VWzIDVjHEcYCTowvtB9uYqR+IHnzWq7WU5kPOlYIV
NnrI2OtOLaIghQWIZIPhDhClNLpGQlVtGWDhJzVzh9bFeBxEjkgJB2ktOcUe
iM4vTYCjyBgDB5IJnKwWbzV74lXGzqG5viUNICbybQkZ/IV7YaaS7kVSktLC
dOkahMwJExJdxXCYOV9lFvSUvtMEuHAE8Kj7cSbJ6MYtHi46Z/ritaOKiuI8
UF+6Kk4MY8l1dPnjftyI76U0EEfZOjZq8ejEwgLXj9XwIuZ4M06BXMvkJRlj
LJUITcuTk42OlfIyExoMjfJd3c4tzkvdmsBRAJijyjM53NL01Ly3pQ9RlnpP
YGO2m0nOEZk2QcPPmE/umUhFAGiU68UyuvCV1DESFQyVJWoYIL1gVvv2/DqB
lOD+s5Pnz4D7xeX1w++kS92qs+qBvM3zSdThR/Cs8YdenRz/joLFNaUz085N
+QckqyGbPry+vo49uZNX334rhdHi+Y/X18ND56Oy3YewweHtzbMXs+PjV6BG
b2nwoQ0JTBd4Ete/8HtOtMYB4PJ6CFWTQmCYEmphwQj54b52E2/cydlgGLlJ
sRWYBgygDAQoZGk5j0JEB1CHNhhnM5VJ2YZb5ALnkPsESeSY42UWI8srpIjQ
mJm6IcfKmoHRbkNtYMSEJoyZ3Ksq+jVNKegVbxAe5uJzmYaEZqEp8TSujA0y
YwPSGUpdsSHjpmJOZElhwe04Tg+eDSgf/DBHcy4ICEvYq1f1y3ol38iIP3Ox
QPz3VQeLkWkFth6Es80Dvcqn+Ez08C7gRU864Joo0vtRHSbgCT4xNwU+UdXU
/Yb0MCOqBdBv84wnJoLo4eQESNSo0NnFZ+ljKjmOiUq8ATIIidNSrIAuK+la
B67t+7ncXkwWV8ggSQiOkNyFY3aR1Sr2mAPbTqSvdGVMJYvLRWaVSXgKsFyx
CFScXSea0ugCJzlXoINKF40iIYHBGK+p5DbeqQiLei5c5/N6DCu0YIzJT2SF
4/VCn0dFZ8rfoINJCfF81EJeulAo7b1E/rDm2FApyPKGqXg4UGoWiOcQWjL/
RuQfHi3waKxBlbASej/pmk/yqGFRh3tac18qC9AbahsntQpz3B+JUx7K1HkA
35hYsgcdaia21OAgqWhwAJtQXZvKoBFoOR2WgZ1BSznGim5smyjudKV5Qe1j
GlpTG4CPR1OS9Oq61qWJjrLXZC8DqUzZFVFZUkDIV3MMEpfcubWAozsaCAlW
1qDppNBF9XpTcVObWe6IODzqXWQTGDE6JQwScA0ozh0VIc1aRUByORoUct+D
iBTzmozDRFuiNSRx1btO68qyb73Y06W7jUVp0KthcgtYB5zoKJxIPk/BKjxY
WIEYy5dzQNFdLaH9A5GVq9hl8GRsaquh4L0TpyYp0FBjL3yO4zaftuTI3br+
Duy2qNyKXKvhvtqZ5zyz5/QRryK37he6pPy7RY5G4l8MvUl1k5PEyIFePjsm
XhNvV7LceEYpkrqEKpJvhoxki1x/o7xFbJ9InU9SNHlmCH2g0XR8ohS+J6La
pXrKhNyGVELUelvE6nDKakXDDX8oJmdzIxkPJOpMVgqJeA9HazXwrGc9CBTz
ApQsdksZARmBe4S/2Lxd0HFhZvV2p4O7U3OOxSVmqsuR53Hhfl+VZm9kkA6v
ZDmj2ZSdQa2U/3GiImR2p7iclgpdUjaiaJKIeZSbxCLKUHt4YtovI1xJSTP1
ga85HZWiTogKAVQE254oXQCJt6mgV+zwOzpLrKtzLzB0PAPu7AtVTEOoChMC
gfdDBS3FiWEegdPwME3G6vFrJzYesjuu4MTiTMy+pHUJtroLXNG2Y3vnrqfO
Wcy0YqWistyJEr3EfSLQs6QSafNCgPSbog9FAAA4Tqk9YB92Q/zhAVxp63rF
dcpYumG/Ur+dhVVpznbC2sSTbbb3wdGk4OEHanw/0NzX4cGlqlzzG2ntit6k
+8uC60763zvrRL3QZw6OgqNdC95RDOOfuCazS7HHNc+lHjW39xQI9wLpuKRN
ljmUMplZbBqhPGJk4fNjSw0IjMumcm3aI8vGJO1PAz00PVNSpsnQSmA4xDc8
WSQKoGVkjxxgXCrYqeqMaH/e1qzNHQIcSAQP5nnvSqmgJHqHNPPONsmeKP+5
DGlPMJMwnphtQBG2MfXeS6nG7cIhN4zLjNvIVCx4tPDge+wOpIH989TD+X28
oQk/TsSJ3Z9LNhIaqYhfzYaQxkMHeYVjbiSX4tmRKlXPpabCxciqyI9HQ4IU
OpmI00hHrMAMDaqZyus+Hc0ABGpH+Fry2LscknhdJfNyYUTShVmtUakyjRJd
7x0YyenUl29oqGSKN7/mQ16Hj3r5R1KvlpmI2OHds3roDkY04nVCX3wPEVtp
mgR0vS9S3Szk7kMdjWJeGrBw0olbcL+VzDMi+8Z6HtkwlRkNWpMA3LJnQKZW
wb4RR2HW8YJBnEHPZO3FQn7O25Mh0RKz7CxPZ7Awu336YsBSE6tDz1++fEZT
2LfMiIZjUryxzV8B6MAboGpIo7LDjQ+eDhh7BLPiR1hfbCiUei3xyDKNatJO
+QxPNiJ853huUCozUBOBHocGYk41jb+w+nns4sohtXRtGBB3C8q5oo/AuodZ
i93ZjSCzrFFRjeOJJ9iwbU1JEe3T34U+VZisoalbSE5tLyz1Ghh/v9sIj7og
urJdm8HPSa8DNOwbd+V+wTx6KCEOTJAq3YyvpA/EEk+TBEOte7D/toh+AX5F
VJGnhoaywCS7876hGB+DvQAG7x4yq1ASYqV/NCHcywj1rraoE+5N/WB8Skfj
jA8tNpiR1FXyj9P3GtQHaKElkuHaR5aWdeTJe0P64CWT4guhS6pWyLnp2zME
abTkOTP/bKqdOytJ53kQEseh6Ny4UXQIXS1ZZCpdYKl+87cOCBPzrxeOalnU
7tut9EVp4qRiuvbwHR2qK/XWD/4uoauQ2EVuxERm8KakIT13D2O3U4LhrMpU
SksWJ9NoSHP6UFznLYCRRV4ZDCp5HLeRpc05nIT2RN4rzpydUEXXNHxCD5ZG
EjqGiIJdnoGo5UH6CbePOEuwbdmvqEZXEno8WC3TDZF+EJ8O5Czn4IM37dLY
YmP0PbcRg+nnzNn5iOWUfqyB9aRhgxvyVeukypbrlcdNuWQq9hCDIa1Y0EzJ
56DR1oQxSh400jU3Gwbd2CZNZJIWegglh6r2VBQSGGgw5qYqBFmWWLYDIQCD
GXA1oiWYWC8z7PK1wTh7+XEcgEdfakWYW+l2+zWMaHtJUJ+c3V9Q6E9jDGKC
4TOU4/w930v9fZS1/53ePZmd0MvpvGEIPg1H7tDnnSwnJqo8gBYcKw6gSQ1w
HiP9ZG9xfBalePbzUmQN6n+RAM/3CRAzaipC7J+MHArZ1g/NNRpbDys/YwW/
j0ltWHg0+hqO8CsL9VJ+SqXw/NsacXLr7fn1w4uJ/Pu7iXqyhyVIRII/0bFK
Z6Frul0Kc9ZSGnnEsrkilI4ZGogmtFHZaEff3soED993UxDRcyRaJG0KjkWh
n1JKkvM5yymVNBI0yAM4ejBbHqahWLXqV5NY2kk11IzfEa3yaSw3TsjJN/c0
V+weF0ujBC92JLg6+3PYPi8nZn2KJEFY4jkbDpjDLzSw1SG5z1HoAOyvzmez
cCTHPFcgDUq7jrxjbWRKPSohIm7qM+8c8jmbw6+SUGqWcuQgSSiJkBxpCIfK
BUtykJ3Bkcys0tyIyPJCtJVX7Ydvjg2Jrk6dpDDrUjkjtUEZGNqbsU9G9aE9
GfQgVms60NIH9m0EzZQF+TBWKJgdRUiykx7PyiU+KT2JAbLpXMMXk4Z6abMN
FWy2T56PiquC24B30s021AudSoWQRUKeT7w0aiaVplmMlzuhIH6P6ufJrnpE
dsNiAhVDeKzpaLym5HJ529bKkO++uJ+C9b7Gbdrs+T+02SNeFGtSoQAgg+IB
fJ7ejFz7LFH4pKYM09tI1Z/Mbf4vbB1yEKOId3CeZw+evoZMQ8opq/8qBOTy
7P3Zo0fH3wILVJOf1IlC8Fee5zgsrXJWxtInc5Diy6l8C8RU/3GwAJk0B193
V6X6B2Jk24U5RLbL0F3guYC+jY26s4sLnokPX+ol3D85fkVMEVGcK+fxbT8p
oj0g/kn8ErQznzu5R/nLIfwHJR796ZCdjEyyxJHEgscS0Xlcx86FBxa8+BV9
toHJuZWn9gH9mQOaCChdW+tJ+MMavzf0FyYm6jXu96Zcwju7/5nwn9tQbwE3
K433Pup6oX4yc0pKr5ACafDIj/RvW9HCxZVbahLjtetLOLHFYze6+SuY5hWS
lBZ7/d6usLOtJiAZlsZGHLKc9xDnndliC+xx1lSt2SAbW61rTuxZ2g9tt4Sk
WPstsRczKViyP9nP+Bn/dDRb4iB82zk6E6n4T7Zp6A+G4JCz4n8BVASDlvRF
AAA=

-->

</rfc>
