<?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.8 -->
<!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-schinazi-httpbis-doh-preference-hints-02" category="exp" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.40.1 -->
  <front>
    <title abbrev="DoH Preference Hints">DoH Preference Hints for HTTP</title>
    <seriesInfo name="Internet-Draft" value="draft-schinazi-httpbis-doh-preference-hints-02"/>
    <author initials="D." surname="Schinazi" fullname="David Schinazi">
      <organization>Google LLC</organization>
      <address>
        <postal>
          <street>1600 Amphitheatre Parkway</street>
          <city>Mountain View, California 94043</city>
          <country>United States of America</country>
        </postal>
        <email>dschinazi.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="N." surname="Sullivan" fullname="Nick Sullivan">
      <organization>Cloudflare</organization>
      <address>
        <email>nick@cloudflare.com</email>
      </address>
    </author>
    <author initials="J." surname="Kipp" fullname="Jesse Kipp">
      <organization>Cloudflare</organization>
      <address>
        <email>jkipp@cloudflare.com</email>
      </address>
    </author>
    <date year="2020" month="July" day="13"/>
    <area>Applications</area>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <t>When using a publicly available DNS-over-HTTPS (DoH) server, some clients may
suffer poor performance when the authoritative DNS server is located far from
the DoH server. For example, a publicly available DoH server provided by a
Content Delivery Network (CDN) should be able to resolve names hosted by that
CDN with good performance but might take longer to resolve names provided by
other CDNs, or might provide suboptimal results if that CDN is using DNS-based
load balancing and returns different address records depending or where the DNS
query originated from. This document attempts to lessen these issues by allowing
the web server to indicate to the client which DoH server can best resolve its
addresses. This document defines an HTTP header field that enables web host
operators to inform user agents of the preferred DoH servers to use for
subsequent DNS lookups for the host's domain.</t>
      <t>Discussion of this work is encouraged to happen on the ADD IETF mailing
list <eref target="add@ietf.org"/> or on the GitHub repository which contains the draft:
<eref target="https://github.com/DavidSchinazi/draft-httpbis-doh-preference-hints"/>.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
      <t>When using a publicly available DNS-over-HTTPS (DoH) server, some clients may
suffer poor performance when the authoritative DNS server is located far from
the DoH server. For example, a publicly available DoH server provided by a
Content Delivery Network (CDN) should be able to resolve names hosted by that
CDN with good performance but might take longer to resolve names provided by
other CDNs, or might provide suboptimal results if that CDN is using DNS-based
load balancing and returns different address records depending or where the DNS
query originated from. This document attempts to lessen these issues by allowing
the web server to indicate to the client which DoH server can best resolve its
addresses. This document defines an HTTP header field that enables web host
operators to inform user agents of the preferred DoH servers to use for
subsequent DNS lookups for the host's domain.</t>
      <t>When a web server wishes its client to use a specific DoH server to resolve its
addresses, it can send the DoH-Preference header to indicate that preference to
the user agent. The header is not prescriptive, it only indicates the server's
preference to the user. It also only applies to the web server's current
hostname.</t>
      <t>The header defined in this document is not intended to be used as a discovery
mechanism for clients learning about the existence of new DoH servers. Instead,
it is intended to be used as an optimization technique for clients with support
for multiple DoH servers who wish to choose the most performant DNS server for
a given query.</t>
      <t>Discussion of this work is encouraged to happen on the ADD IETF mailing
list <eref target="add@ietf.org"/> or on the GitHub repository which contains the draft:
<eref target="https://github.com/DavidSchinazi/draft-httpbis-doh-preference-hints"/>.</t>
      <section anchor="conventions-and-definitions" numbered="true" toc="default">
        <name>Conventions and Definitions</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>
        <t>This document uses the Augmented BNF defined in <xref target="RFC5234" format="default"/> and updated by
<xref target="RFC7405" format="default"/> along with the "#rule" extension defined in Section 7 of
<xref target="RFC7230" format="default"/>. The rules below are defined in <xref target="RFC5234" format="default"/>, <xref target="RFC7230" format="default"/>, and
<xref target="RFC7234" format="default"/>:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
  OWS           = <OWS, see {{RFC7230}}, Section 3.2.3>
  delta-seconds = <delta-seconds; see {{RFC7234}}, Section 1.2.1>
  quoted-string = <quoted-string, see {{RFC7230}}, Section 3.2.6>
  token         = <token, see {{RFC7230}}, Section 3.2.6>
]]></artwork>
      </section>
    </section>
    <section anchor="doh-header" numbered="true" toc="default">
      <name>The DoH-Preference Header Field</name>
      <t>An HTTPS origin can indicate its preference regarding DoH servers to the client
by adding an DoH-Preference header field to responses.</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
  DoH-Preference = doh-uri *( OWS ";" OWS parameter )
  doh-uri        = quoted-string
  parameter      = token "=" ( token / quoted-string )
]]></artwork>
      <t>The "doh-uri" component consists of the DoH URI Template as defined in
<xref target="RFC8484" format="default"/>.</t>
      <t>Sending multiple DoH-Preference header fields indicates that the server prefers
multiple DoH servers. They are sent in decreasing order of preference.</t>
      <section anchor="the-max-age-directive" numbered="true" toc="default">
        <name>The max-age Directive</name>
        <t>The REQUIRED "max-age" directive specifies the number of seconds, after the
reception of the DoH-Preference header field, during which the user agent
caches the server's DoH preferences.</t>
        <t>The syntax of the max-age directive's REQUIRED value (after quoted-string
unescaping, if necessary) is defined as:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
    max-age-value = delta-seconds
]]></artwork>
        <t>A max-age value of zero (i.e., "max-age=0") signals the user agent to remove
the DoH URI template from its cache.</t>
      </section>
      <section anchor="examples" numbered="true" toc="default">
        <name>Examples</name>
        <t>The header below indicates that the user agent should consider querying DNS
results for the web server's hostname using "dnsserver.example.net" for
approximately six months. (Lines are folded to fit.)</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
DoH-Preference: "https://dnsserver.example.net/dns-query{?dns}";
    max-age=15768000
]]></artwork>
      </section>
    </section>
    <section anchor="server-behavior" numbered="true" toc="default">
      <name>Server Behavior</name>
      <t>Web servers MAY send a DoH-Preference header to indicate to clients that it
would prefer they use that DoH server when resolving addresses for the hostname
of the web server. Web servers MAY send multiple DoH-Preference headers. Web
servers MUST NOT send the DoH-Preference header in HTTP responses conveyed over
a non-secure transport.</t>
      <section anchor="considerations-for-choosing-a-preferred-doh-server" numbered="true" toc="default">
        <name>Considerations For Choosing a Preferred DoH Server</name>
        <t>The choice of DoH server can affect overall performance and responsiveness as
perceived by the client. Some example considerations in choosing a preferred
DoH server are:</t>
        <ul spacing="normal">
          <li>A DoH host specified as a host name rather than an IP address will require
one or more additional DNS resolutions when the cached DNS entries for the
resolver or resolvers expire.</li>
          <li>Support for extension mechanisms (e.g. EDNS(0)) may be desired.</li>
          <li>Clients, particularly mobile device clients, may frequently move between
networks that have different network paths to the DoH server.</li>
        </ul>
      </section>
    </section>
    <section anchor="client-behavior" numbered="true" toc="default">
      <name>Client Behavior</name>
      <t>If a client chooses to act on received DoH-Preference headers, it SHOULD cache
the server's hostname and the corresponding DoH URI template and lifetime. It
SHOULD then send subsequent DNS requests for A and AAAA records for that host
name to the provided DoH server, until the cache entry expires after the time
specified in the "max-age" directive. Any received DoH-Preference header
replaces and overrides any and all information received in a previous
DoH-Preference header for the same host name and DoH URI template.</t>
      <t>Clients MAY decide to only respect the DoH-Preference header for a subset of
vetted DoH servers.</t>
      <t>Clients MUST NOT use the contents of the DoH-Preference header to impact how
it resolves other domain names. Clients MUST ignore the DoH-Preference header
in HTTP responses conveyed over a non-secure transport.</t>
      <t>If the DoH-Preference URI contains a host expressed as a host name rather than
as an IP address and that host name is resolved via DoH, the DoH server might
also specify a DoH-Preference header. This means that respecting the DoH server
recommendation could result in an excessively long chain of DoH queries or a
loop of DoH servers. Clients SHOULD be capable of detecting a loop or an
excessively long chain of DoH servers and treat these conditions as a query
failure.</t>
      <section anchor="fallback" numbered="true" toc="default">
        <name>Fallback</name>
        <t>If resolution using the recommended DoH server fails, clients MUST fall back
and retry their query using another DNS resolution mechanism.</t>
      </section>
    </section>
    <section anchor="internationalization-considerations" numbered="true" toc="default">
      <name>Internationalization Considerations</name>
      <t>An internationalized domain name that appears in the header field MUST be
expressed using A-labels; see Section 2.3.2.1 of <xref target="RFC5890" format="default"/>.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The DoH-Preference header allows a web server to impact how a user agent
resolves DNS A and AAAA records for its own host name. Since the web server
has proven ownership of the domain name via its TLS certificate and the DNS
result that led to the initial connection, impacting future DNS resolutions
to the same host name has limited security impact.</t>
      <t>The potential exists for the DoH-Preference header to be used as a form of web
tracking. Because a DoH URI is chosen by the server, cached by the client, and
then subsequently contacted by the client, a uniquely chosen DoH URI could
identify a client even after other client-side state has expired or been
removed. Clients SHOULD expire cached DoH URIs when other client state expires
or is cleared by the user unless the URIs refer to vetted DoH servers or match
common DoH URI patterns that preclude client-unique URIs.</t>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document, if approved, requests IANA to register the DoH-Preference header
in the "Permanent Message Header Field Names" registry maintained at
<eref target="https://www.iana.org/assignments/message-headers/">https://www.iana.org/assignments/message-headers/</eref>.</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
  +-------------------+----------+----------+------------+
  | Header Field Name | Protocol | Status   | Reference  |
  +-------------------+----------+----------+------------+
  | DoH-Preference    | http     | standard | Section 2  |
  +-------------------+----------+----------+------------+
]]></artwork>
      <t>The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task
Force".</t>
    </section>
  </middle>
  <back>
    <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>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="BCP" value="14"/>
          <author initials="S." surname="Bradner" fullname="S. Bradner">
            <organization/>
          </author>
          <date year="1997" month="March"/>
          <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>
      </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>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="BCP" value="14"/>
          <author initials="B." surname="Leiba" fullname="B. Leiba">
            <organization/>
          </author>
          <date year="2017" month="May"/>
          <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>
      </reference>
      <reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5234">
        <front>
          <title>Augmented BNF for Syntax Specifications: ABNF</title>
          <seriesInfo name="DOI" value="10.17487/RFC5234"/>
          <seriesInfo name="RFC" value="5234"/>
          <seriesInfo name="STD" value="68"/>
          <author initials="D." surname="Crocker" fullname="D. Crocker" role="editor">
            <organization/>
          </author>
          <author initials="P." surname="Overell" fullname="P. Overell">
            <organization/>
          </author>
          <date year="2008" month="January"/>
          <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>
      </reference>
      <reference anchor="RFC7405" target="https://www.rfc-editor.org/info/rfc7405">
        <front>
          <title>Case-Sensitive String Support in ABNF</title>
          <seriesInfo name="DOI" value="10.17487/RFC7405"/>
          <seriesInfo name="RFC" value="7405"/>
          <author initials="P." surname="Kyzivat" fullname="P. Kyzivat">
            <organization/>
          </author>
          <date year="2014" month="December"/>
          <abstract>
            <t>This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC7230" target="https://www.rfc-editor.org/info/rfc7230">
        <front>
          <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
          <seriesInfo name="DOI" value="10.17487/RFC7230"/>
          <seriesInfo name="RFC" value="7230"/>
          <author initials="R." surname="Fielding" fullname="R. Fielding" role="editor">
            <organization/>
          </author>
          <author initials="J." surname="Reschke" fullname="J. Reschke" role="editor">
            <organization/>
          </author>
          <date year="2014" month="June"/>
          <abstract>
            <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC7234" target="https://www.rfc-editor.org/info/rfc7234">
        <front>
          <title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
          <seriesInfo name="DOI" value="10.17487/RFC7234"/>
          <seriesInfo name="RFC" value="7234"/>
          <author initials="R." surname="Fielding" fullname="R. Fielding" role="editor">
            <organization/>
          </author>
          <author initials="M." surname="Nottingham" fullname="M. Nottingham" role="editor">
            <organization/>
          </author>
          <author initials="J." surname="Reschke" fullname="J. Reschke" role="editor">
            <organization/>
          </author>
          <date year="2014" month="June"/>
          <abstract>
            <t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems.  This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.</t>
          </abstract>
        </front>
      </reference>
      <reference anchor="RFC8484" target="https://www.rfc-editor.org/info/rfc8484">
        <front>
          <title>DNS Queries over HTTPS (DoH)</title>
          <seriesInfo name="DOI" value="10.17487/RFC8484"/>
          <seriesInfo name="RFC" value="8484"/>
          <author initials="P." surname="Hoffman" fullname="P. Hoffman">
            <organization/>
          </author>
          <author initials="P." surname="McManus" fullname="P. McManus">
            <organization/>
          </author>
          <date year="2018" month="October"/>
          <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>
      </reference>
      <reference anchor="RFC5890" target="https://www.rfc-editor.org/info/rfc5890">
        <front>
          <title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title>
          <seriesInfo name="DOI" value="10.17487/RFC5890"/>
          <seriesInfo name="RFC" value="5890"/>
          <author initials="J." surname="Klensin" fullname="J. Klensin">
            <organization/>
          </author>
          <date year="2010" month="August"/>
          <abstract>
            <t>This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version.  It describes the document collection and provides definitions and other material that are common to the set.  [STANDARDS-TRACK]</t>
          </abstract>
        </front>
      </reference>
    </references>
    <section numbered="false" anchor="acknowledgments" toc="default">
      <name>Acknowledgments</name>
      <t>The authors would like to thank many members of the IETF community, as this
document is the fruit of many hallway conversations.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAF23DF8AA+1a73PbxtH+fn/Flf5QKRVpyXYSR6nbMJIdq68t67XkN9Pp
dDpH4EheBeIQ3EE04yp/+/vs7gEEaMnOTD90phPNaAgCd7t7+/PZBcfjsYou
FvZYn/qX+qK2c1vbMrP6pStj0HNf65dXVxfKzGa1vbl7lcp9VpoVaOS1mcdx
yJauND+78TLGaubCOPfLcdVtGi9p07gw0YaoMnwsfL051vZ9pZSr6mMd6ybE
R4eH3xw+Uqa25lhPq6pwWOp8GdS13ax9nR/rszLaurRxfEp8lQrRlPk/TOFL
yLKxQVXuWP8t+uxAB19HSBBwtVnRxd+VMk1c+vpYaT3Gv9auDMd6dDrRl+kA
I74tRxudmhuX7zzy9cKU7meWC0t+8H5RWP3q1Yk8DmBpIx4cfXV4qKerauni
0hrc1Remvl6bjazLXMT5R699U0bjSv1/zq4P9IkpHPRfOqO/eXL45HFaS4tI
XaN3pYsWEkVSpPZzMLA1lCTr7Mq4AhZpjTFxNs6/W9DdSeZXw0Of48xNUbgb
U/aOfO6y6+H94XlPCt/k8wIW6nMsseu7rHv0MbO/TPT/uKrqMfqLDcFub/4a
Lv+8xupdNkqNx2NtZtC7yeAPPy5tqZvgyoU2umpmcKFio80NKJgZDHV6fjn2
N7Yek4tf6j04974OtsYt8piV1VnhLMXBymxUaObwYF15xERla5hmZSgG1sQF
dtXiTw72cDdMPNHSLujCk6Pnem5qPa8hK22gYJIlE/0CVO17s6oKe3CPtN1q
XdUezghyMyxQJx5xUEZ9amEpW2/0uY0IkGu9d3J6jgMtfVNgKQQkMtHr2gZf
QETSftBLH6KQiksTFfboNfxUL7zPBwedNVGv3GIZdTTXFkcqF5DlI3o94ZTH
MWsNkgg8HFB2pwU6NDNfRbcyBVFoCujZzVkI2kFaE9uRmWYm2FwV3oCsKSAO
G7XMsTM2dRl07uacX6I2eQ5yAU8yZAk8sZUtc1oPCWAsRB8r//xS/dSQumCz
BWKEzQPTTPTVEryR1JoV04vRrioIh5MW5KlsbTisC6HBeckGReHX4MBWXdtZ
ayfscGBNpqdreioeBTlctuybNDMlTBRip0yHxJqOYsOuTLmduxK8sYl8VyOr
5CAydxaWZg3akqwdWBqysPIwpYm+DiIVWRX6xSazYBf3c5ZP8nQNXWyF4y1Y
S+UAYTALFoojh4OLF95fN5VUCtpPvH5PkiJOy4lSpy5kTQgIZeGAU7Bv4hPF
wDc12OdEf2kq2El7iaXp6ak+e371QlO4k2YLB9387e97UMl3lMomyBL7ZNG0
4QcXXzYzaK/yweGYm6TizHNODbyI69OxAhkqTeH44cMFPL2ZUfZ4yAm+ze8P
pZR9qoLtT1LCWbk8L6xSD6gg1T5vMspcv6Wf39LPb+nnP51+OAZNXylrF6A+
Ol+rjETd6FDZzM1d1ldMz78GKjnAV9YaDJLrFE7jHjROOhnYgDSzTSN4xhbb
qoH03O2EwkvP60NWu4qimpn6EnHZ0pS8JrL+HoC3T1y3xCf6DH5UBC97DYFp
G9oVW91AcVlTkxcr0iPFE1TYE0nsnoO7ZPLOIZKsjjJBLvl8xrxzbeAmCI+Q
UarbqJXNlkB3YcUmaxNcYQ2ALsXUzCPMSSz7HhmfTwLXKO267xA4UImHJj9Q
jpnfxxj1hEI8gUkdwbx08J4Bc043oakq9AiKHqyQDFw1yHlYtfTsO8QiW3of
JI5XUNQ2TcV+3iV3NXoBu5WaQ/2/vxw+eKBRDnBg7tQ4Q56Szzjp3NiX0L7R
mZEaR6/fXV6NDuRTn7/h67fP//fd2dvnp3R9+XL66lV30a64fPnm3Ss8V+lq
u/PkzevXz89PZTPu6p1br6d/xQdJNXpzcXX25nz6atQ6s9pm3NomPyK3qnHQ
KO6UcyTOJAC+P7nQR0/0hw+/e/vi5NHR0Te3t+nL06Ovn9zeKirMwoyjTr5C
7RyA8HcigsyNJFKhaBfIKGCBarkuNVUJjrx+jMGpxWzTZkE3IMb35y/6MSns
v3z0GOyZcVPlRoqrkmdfPzn8kp5R8RS/J4KjB3VT2BFCDlHEvtkjemkZzuiv
4bAtlUePD29vJVnRThQhiwrEirtHnAPd38pq2RLD82OlfvnlF3R4b3681Nu/
Z/qPuAE0ZO0OgVasx5NHk8d/wsbcFtGMA6puCdfCxsGNb4cknvRJHIHEEZH4
qfHQ1hjtI6UikBjc+JwUXxGJ6K8RtT3x+cav2EqnJwh59XEleSnJ9wVX1w8P
KPgkH98qNZUKfJlQBFekrt5QjetVhNouTM1IZKe2boGBIjSR54Ju7qloqcpz
XawQ1YAHrfF2NjzTJGtTO/3FHht29O2IPytTo7YgtvQ+WS4t6pQ2UDsWbJen
BaLl0bOR3kvXD3eMty8KJW2OEv0Rkt8KAlMswScCMmgHO0gh796e6StALRpM
SbS3npw89emTp/AbHPYyAbp+nbhPUWFQqk3s1etkm6DuqjccXRsOqcAVloIy
q60JAiWJAYTfmjelXzrxyrwfo47oU1eTk91YUUSbWfUoLRihLqcVLfZJKaZs
VjNhkOIHETsnA+ChwhZbxa6EffL4Bzpv2CBSfoZwR2UmW+5AGNbB9lQhAZCw
Qd163zJsD9iJj33d6W5MgQK/J/IOXakBaKV0S8HsCFWAQTD1Zp/qb2tvE7pk
pFtOYyH6bJhlxMemnTiyCDL+bGuv99zETg46ZT87HKEZcosSqX5HDxJMKwAk
1XfG2DojtQUCWElfydDPpVsLA4AmefgOj+sxSw0Zh0DOKgI0SY2OajuhFk8P
wGELClNjNMrLkPrH1DpOShtHgnsqtFnv0VxFi9oX3HsApTIu4dZ7r6R1qAmE
FQmzzV2c7IvWh850rEctNrmTG90d8wk+/BmXt6Nv+2Z7dvTl1189PTw87NLr
pUTe93YJeAM51Y/dAYMGPBA4b34NmPcdgGQtu6jWrFhxXqn0TUiov9dRcMMu
PQXn2bajGPQwpGaVvH1rg4m+U9xP56HAu1S3K2GtzzUuLvV2XZYnj7mxGxiM
kDyQbelLioSG4FJtykD4edJiQPYtGdjzcOGEILOMQi4GPZ5YRLwYuNoJ4N9p
TQ266ywyY4JM/bGAdOEsIyFtar0NGiFbZxbf02ChrW8TfUlzleRAXQwkOal+
bsXsWlHVEwZui+zwhZ6yhGSpLnOmVofvcZSA7JIdgQ5Q6rOLbjawdgUNHX5q
kL8UKhIPJzz0SLWXZDEFNxLsJY0I1815OAnk/Bwnqt3Wc1TqVGui114HerHi
CE9+oS+lyeH1W7DXtWRB79nJYqKfg/be4f4+zZ0IBgP3gkBOFE7E5Q+oJkeX
NYWpEd8rP3MFrbsh82XtGto+r6Vb51WoMzMb19aWqpQhUQoeRKPtzVDSQzBB
ymgRSm9cRZEskvQi+WwO7aeWXho03mrIbyjgkj/cHSPcWad2ghWsBkWpy3wm
xUzma3G6Dk8NMjYtK9zcove01H2rRDqSETnwduYYrKWQEu+U90/x102RxMKk
KRqmsChJLd28a6ufA92gASu23sKOskmOELalXJN8auvATjzsDnww0dNy8xkl
wv1w+sxK30exWkMw+rbhOxS5MvmRbryjRo0QhRvs2AR1D5pIyTHQ0bcxxh3m
jvbhHslNOUUCNtG4L6bpB5mNcskngAtYGTFQpKbnxsY4HEj1ObTptEkDgUzG
oeHT4Igqyaoi30TDR0OMFK7YxklDBlgy0pzoATNACN8OEe80w2cyt743c5/d
KTGpthsbpPwGT+Ki9amcp2QA00t7EjzJiWW9C+3Jc33juO4e7ES7jG0Vz6/E
VTf3Feg0p1xZU6bEkqxNQTqkSijWr9BH5+KMGddugT/skCUOSfAQHgqv4YYZ
adKVbXUi0EG5l5xFFd5Xw7LVs1qK/RkFY8VDcKzM0c+IXEbLbtAp1ad5tjWc
FYleIKZRMKFRl0YuZA8GRGpuXNHwIAEl+QWib2aya7bytq4kKEe66RQy8HVN
VJAes74LzimUmVqagddcZF0Ck+1Lj1J8eVjJtuWGgWx6iW+k6rWDuiGA4DbX
DddByF6MiLFlrhLaNDboV1numVVbzxUhp+PCADWnAUHblD+aUFt+RHpPU4yn
3xxy78cYEpHj4uYjKe/o3ZMMPKEPw0H0IAXgUa8v6pIBqe6eakD9AM+K2lgC
tnE8+B1ARrU08k6EhonrEt6zdFWbm/oapOgjmlevLnVmUdzngnPbirftDkTZ
hSB3esTzPUAWuGEpCjxIRyMNz5tIiWYHz6i0dyefk7SFW/EvG0KrZ6GVOsHK
U3oldjwh3sLmexPtYBLNLx5wfGhI0c8EriHiBCgiM/IOoC0mSCMAEfS2JQHI
trQm+DWAlTLPkuLe1XVEMKfNLN6xHBWa5tC0Rri0fDkPKXgVzsiJLiEaSwaU
wi1RJffHgV9l0W9AWHdS4nPKJjOCWdJW5h8lI1nXYUlhnkBmn34inZCD8vxa
IqNx/fZQ7LhNSS+n+DtTSk2Q1x9XT0a7JmZLRQnHb89e0buuuk3diNOsaPJW
aWPRGFNPmWN6Pr0jBnszU+7yuRWFDg62IIt3ctO9oJcMn/Af1UKiC0v9Bmnk
Nc0MFjtjuXMq1KNEEBmQ4ooqJrldVH9se9j1ej1xpjQ0rn9oAo0DSM7wcCVE
02AvPPxTN1P7w/jjvz987hJfsPVfH8uIexe1jz7zBS7pt0NN0LTybXdw/a9/
l+uOJpk+aUDLJf9My9Q5CdDm23+Tazfso9KyEBBW+6Lg12jHesTvTvZQrhe9
tyXjcfcLMv28XMBYlkdVVyZcK/SsmR21r/ilcj7Q0+y69GukPp7AB/XhWCZl
Nn82QlEMdnQrcsjLeHq5Q7CicNcJr5vyGr4BQLyytK9DiSwghQO8PG74VcDw
pYST2JrXDb0CnAuRJerK2mwE39VBYoBk/n+uGcDt2CcAAA==

-->

</rfc>
