<?xml version="1.0" encoding="us-ascii"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.13 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8145 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8145.xml">
<!ENTITY RFC3646 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3646.xml">
]>

<?rfc rfcedstyle="yes"?>
<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc docmapping="yes"?>

<rfc docName="draft-mglt-dprive-add-dofoo-discovery-00" category="info">

  <front>
    <title abbrev="DoFoo Discovery Mechanism">DNS over Foo Discovery Mechanism</title>

    <author initials="D." surname="Migault" fullname="Daniel Migault">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>8275 Trans Canada Route</street>
          <city>Saint Laurent, QC</city>
          <code>4S 0B6</code>
          <country>Canada</country>
        </postal>
        <email>daniel.migault@ericsson.com</email>
      </address>
    </author>

    <date year="2020" month="January" day="23"/>

    <area>operational</area>
    <workgroup>dnsop</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document describes a mechanism that enables a DNS client to discover other
DNS alternatives such as DoT or DoH for one specific domain. This document also
extends this discovery mechanism to an Internet wide of open resolvers search
&#8211; though this is expected to be described further in a separate document.
While search are always initiated by the DNS client, this document also
indicates how a resolver MAY indicate a DNS client its preference for using
alternative flavors of transport layer.</t>



    </abstract>


  </front>

  <middle>


<section anchor="requirements-notation" title="Requirements Notation">

<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 BCP 14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all
capitals, as shown here.</t>

</section>
<section anchor="sec-intro" title="Introduction">

</section>
<section anchor="discovery-mechanism-associated-to-one-domain" title="Discovery mechanism associated to one domain">

<t>The discovery mechanism is intended to enable a DNS client to discover what are
the resolvers options available as well as how to further use these resolvers.</t>

<t>The procedure is based on service discovery <xref target="RFC8145"/> and the overall
procedure consists in finding various instances of the service "rdns". The
resolution service is designated as "rdns" and differs from the service
"domain" defined by IANA. The motivation for creating a new service is that
"domain" is associated to port 53 as well as TCP and UDP and designates both
the authoritative as well as the resoling service.  On the other hand the
service "rdns" is expected to be limited to the DNS resolution service that can
have various transport flavors including using different ports.</t>

<t>In this document, the service "rdns" is associated to a domain such as
example.com. This means that the discovery process is performed over a specific
portion of the internet, and resolvers that have no relation to that domain are
not expected to be found. It is expected that the domain may be provisioned as
a configuration parameter in the DNS client. It is expected that the domain
provides a good meaning of the administrative entity managing the resolver, as
it reflects the trust/mistrust the end user puts in the resolution. This
configuration parameters differs from the one that is currently provisioned and
discussion on how to proceed to resolver discovery from a legacy provisioning
is described in more details in <xref target="ip2d"/>.</t>

<t>The DNS client then searches for the rdns service associated to the domain
example.com by querying PTR RRsets associated to _rdns_udp.example.com. This
query corresponds to the general case of DNS service discovery. While tcp is
reserved for TCP only and DNS is not only running on top of TCP we use _udp as a
representation of _srv.</t>

<t>The difference with service discovery is that the response is expected to
return instances of the service type. These instances may offer completely
different services, but the end user is expected to select them according to
their human readable name. In our case, the rdns service type can be
implemented into different sub services types that are in our cases (DOT, DOH
DNS). DOT, DOH and DNS are only example and any other designation may have been
provided. Possible ways to distinguish these services could have been to adopt
a convention in the service instance names or to have standard value for the
service names. We prefer not to take that path and remove any constraints on
the service name as it usually appears to the end user and we want to leave it
free to contain what is going to be meaningful for the end user. Typically,
DOT, DOH or DNS are unlikely to be meaningful to the waste majority of the
internet users. Instead we used the DNS-SD capabilities to specify sub services
by prefixing with _dot, _doh and _dns53 the dns._udp service type.</t>

<figure><artwork><![CDATA[
DNS client  -->    Resolver
_rdns.example.com PTR ?

            <--
_rdns_udp.example.com PTR DOT._dot._sub._rdns._udp.example.com
_rdns_udp.example.com PTR DOH._doh_sub._rdns._udp.example.com
_rdns_udp.example.com PTR DNS._dns53_sub._rdns._udp.example.com

]]></artwork></figure>

<t>Note that "DOT", "DOH" and "DNS" are the strings that may be shown to the end
user. The main difference with DNS-SD is that the sub type was initially
designed so the end user can narrow down its search. More explicitly its
purpose was to enable an end user to narrow down the search on services
providing DNS resolution over HTTPS with _doh._sub._rdns._udp.example.com. The
purpose was not to split a generic service into multiple sub types of services.</t>

<t>Note that the user interface is expected to interpret and present to the end
user the different services by interpreting the _dot, _doh or _dns53 sub
service types and easing the understanding of the end user. If the DNS client
is implementing a specific configuration, it will also have to interprete the
sub types according to the configuration of the end user.</t>

<t>Now that the end user has the various services available ("DOH", "DOT" and
"DNS") with there associated types, the selection can occur, and the DNS client
can request additional information about the service itself to set up a session
with the chosen service. In our case this is mostly the host name, ports, the
ip address, the certificates, &#8230;. If the DNS client choses to use DoH, for
example, it will request the SRV RRsets associated to that service.</t>

<t>Note that in our case, the sub service type carries sufficient information and
no additional information is needed. There is no need to request the TXT
reccord. Note also that carrying the sub type into the TXT RRsets would not be
appropriated as this is believe to be a sufficiently important information to
prevent a DNS client to browse thought all the different service instances.</t>

<t>While the TXT RRset is not necessary now, it MAY contain additional information
that may be usefull to the DNS client as well.</t>

<t>It is expected these exchanges are protected with DNSSEC as these could be
performed over an untrusted channel as well as through semi trusted resolver.
The additional section SHOULD also carry the necessary information to set up
the session between the DNS client and the resolver. This includes the IP
addresses (A and AAAA) RRsets, for services implemented over TLS the necessary
security credentials (TLSA RRsets).</t>

<figure><artwork><![CDATA[
DNS client  -->    Resolver
DOH._doh_sub._rdns._udp.example.com SRV ?
            <--
DOH._doh_sub_rdns.example.com SRV priority=0, weight=0, 
                           port=443 host=resolver.example.com 
DOH._doh_sub_rdns.example.com SRV priority=0, weight=1, 
                           port=443 host=resolver.example.com 
DOH._doh_sub_rdns.example.com RRSIG (SRV) <signature>
resolver.example.com AAAA <ip6_address>
resolver.example.com AAAA <ip6_address>
resolver.example.com RRSIG (A) <signature>
resolver.example.com TLSA <certificate>
resolver.example.com RRSIG (TLSA) <signature>
]]></artwork></figure>

<section anchor="ip2d" title="Infering domain from resolvers IP address">

<t>When an application such as an web browser has a DNS client as part of its
components, the configuration of that DNS client can be part of the application
configuration. In such case, the domain may be provisioned in the configuration
either by the software vendor or manually by the end user. On the other hand, a
non negligible part of the systems the resolver is automatically provided by
the network and designated by an IP address <xref target="RFC3646"/>. In such cases, there
is a need to derive the domain associated to that domain name.</t>

<t>This section describes a procedure performed by the DNS client to derive the
domain from the IP address. It is also expected that resolver adapt their
naming convention so that the procedure works. More precisely, the domain will
be derived from the IP address by:</t>

<t><list style="numbers">
  <t>performing a reverse resolution</t>
  <t>assuming the resulting FQDN is composed of a hostname and the domain name.
For example, if resolver.example.com is the resulting FQDN from the reverse
resolution, then the domain will be example.com.</t>
</list></t>

</section>
</section>
<section anchor="resolver-advertising-other-service-sub-type" title="Resolver advertising other service sub type">

<t>A resolver receiving a DNS request over a service sub type MAY be willing to
advertise the DNS client that other sub service type are available. This is
especially useful, when, for example, a resolver wants that the DNS resolver
switches to other service sub types that are more secure.</t>

<t>In order to do so the resolver MAY provide in the additional data field the
appropriated SRV RRsets. As an example, if the resolver wants to advertise the
existence of resolver using dot or doh sub service type, the resolver would add
the following RRsets. Additional RRSets such as A, AAAA or TLSA RRSets MAY also
be added.</t>

<figure><artwork><![CDATA[
DOH._doh._sub_rdns.example.com SRV priority=0, weight=0, 
                                 port=443 host=resolver.example.com 
DOH._doh._sub_rdns.example.com SRV priority=0, weight=1, 
                                 port=443 host=resolver.example.com 
DOH._doh._sub_rdns.example.com RRSIG (SRV) <signature>
DOT._dot._sub_rdns.example.com SRV priority=0, weight=0, 
                                 port=443 host=resolver.example.com 
DOT._dot._sub_rdns.example.com SRV priority=0, weight=1, 
                                 port=443 host=resolver.example.com 
DOT._dot._sub_rdns.example.com RRSIG (SRV) <signature>
]]></artwork></figure>

</section>
<section anchor="migration-to-service-sub-types" title="Migration to service sub types">

<t>The principle of the discovery mechanism is that the resolver indicates the
available service sub types and let the DNS client chose which sub type it
prefers. On the other hand, the resolver MAY also indicate a preference using
the priority and weight fields however, there is no mechanisms that could
permit an indirection from one service sub type to another service sub type.
Redirection MAY especially be needed when a DNS client is using the dns53 sub
type and the resolver would liek to upgrade the DNS client session to a more
secure session. The MAY require a specific ERROR code that will request the DNS
client to perform service discovery.</t>

<t>It is expected that dns53 sub type MUST always be provided to perform resolver
discovery. In other words, resolver discovery MUST be available though the non
confidential channels designated by the sub service type dns53. However, this
does not mean that a resolver is expected to implement the dns53 sub type
service for resolutions. The availability of the sub service types for
resolution. If a resolver chose not to provide the dns53 sub service type, that
service MUST NOT be pointed by the _rdns.example.com search.</t>

</section>
<section anchor="service-discovery-over-the-internet" title="Service discovery over the Internet">

<t>THIS SECTION NEEDS PROBABLY TO THE TOPIC OF A DEDICATED DRAFT.</t>

<t>The current document describes a search mechanism over a single domain. This is
mostly useful for one resolver to anounce availability of other sub service
types as well as for resolver to discover available alternatives. However, this
requires the knowledge of a domain. The domain can be provisionned out-of band
and results from a configuration setting. In the case of local scope resolver,
it can also be derived from a provisioned IP address. This section aims at
extending the ability for one DNS client to learn about the different available
domain associated to a resolver on the Internet. This section will list open
resolvers that are available.</t>

<t>The mechanism involves the creation of a special domain name rdns.arpa that
will list the various rdns domains. This mechanism remains valid as long as the
list of rdns domain name remains relatively limited. The number of rdns domain
that can fit into a payload will depend on the length of the rnds domain, so
rdns domains are expected to have limited length. However the compactness is
not expected to match the one achieved for the root servers that are designated
by a one character size identity. The reason for it is that the identity of the
resolver is expected to carry some meaning to the DNS client as opposed to the
root servers.</t>

<t>That said, a UDP packet of 4096 bytes is expected to contain a significant
amount of resolvers. The number of open resolver is not expected to reach that
limit and if so the list can be retrieved through TCP.</t>

<t>The traffic associated to that domain is expected to be limited as most
applications are expected to be provisioned with that RRset.</t>

<figure><artwork><![CDATA[
b._rdns.rdns.arpa  PTR <rdns domain0>
b._rdns.rdns.arpa  PTR <rdns domain1>
[...]
]]></artwork></figure>

<t>TBD:
* IANA procedure to register
* criterias that needs to be met to appear in the list</t>

<t>QUESTION:
* Do we need to add some criteria for the search ?</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<section anchor="use-of-protected-channel-is-recommended" title="Use of protected channel is RECOMMENDED">

<t>When available, it is recommended to chose a protected version of the rdns
service. More specifically, the use of end-to-end protection ensures that the
DNS client is connected to the expected platform and that its traffic cannot be
intercepted on path. Typically, the selection of resolver on the Internet (and
not on your ISP network) and the use of a non protected channel enables an
attacker to monitor your DNS traffic.  The similar observation remains true if
you are connected to the resolver of your ISP. It is commonly believed that
trusting your ISP (that is your first hop) makes encryption unecessary.
Trusting your ISP is mandatory in any case, but the associated level of trust
with an protected channel is restricted to the operation of the DNS platform.
With non protected channel the trust is extended to any segment between the DNS
client and the resolver, which is consequently larger.   The use of a protected
channel is recommended as it will prevent anyone on path to monitor your
traffic.</t>

</section>
<section anchor="dnssec-is-recommended" title="DNSSEC is RECOMMENDED">

<t>The exchanges SHOULD be protected with DNSSEC to ensure integrity of the
information between the authoritative servers and the DNS client. Without
DNSSEC protection, DNS messages may be tampered typically when they are
transmitted over an unprotected channel either between the DNS client and the
resolver or between the resolver and the authoritative servers. The messages
may be tampered by an online attacker intercepting the messages or by the
intermediary devices. It is important to realize that protection provided by
TLS is limited to the channel between the DNS client and the resolver. There
are a number of cases were the trust in the resolver is not sufficient which
justify the generalization of the use of DNSSEC. The following examples are
illustrative and are intended to be exhaustive.</t>

<t>First, the discovery exchanges may happen over an unprotected channel, in which
case, the messages exchanged may be tampered by anyone on-path between the DNS
client and the resolver as well as between the resolver and the authoritative
servers - including the resolver. When TLS is used between the DNS client and
the resolver, this does not necessarily mean the DNS client trusts the
resolver. Typically, the TLS session may be established with a self-signed
certificate in which case the session is basically protected by a
proof-of-ownership. In other cases, the session may be established based on
Certificate Authorities (CA) that have been configured into the TLS client, but
that are not necessarily trusted by the DNS client. In such cases, the
connected resolver may be used to discover resolvers from another domain. In
this case, the resolver is probably interacting with authoritative servers
using untrusted and unprotected channels. Integrity protection relies on
DNSSEC.</t>

</section>
<section anchor="tlsa-is-recommended" title="TLSA is RECOMMENDED">

<t>When TLS is used to protect the DNS exchanges, certificates or fingerprint
SHOULD be provided to implement trust into the communication between the DNS
client and the resolver. The TLS session and the association of the private key
to a specific identity can be based on two different trust model. The Web PKI
that will rely on CA provisioned in the TLS library or the TA provided to the
DNS client. A DNS client SHOULD be able to validate the trust of a TLS session
based on the DNSSEC trust model using DANE.</t>

<t>When the DNS client is protecting its session to the resolver via TLS, the DNS
client may initiate an TLS session that is not validated by a CA or a TLSA
RRsets. The DNS client MUST proceed to the discovery process and validate the
certificate match the TLSA RRset. In case of mismatch the DNS client MUST abort
the session.</t>

</section>
</section>
<section anchor="privacy-considerations" title="Privacy Considerations">

<t>When the discovery protocol is performed using a resolver that belongs to one
domain for another domain, or over an unprotected channel, the DNS client must
be conscious that its is revealing to the resolver its intention to use another
resolver. More specifically, suppose an resolver is complying some legal
requirements that DNS traffic must be unencrypted. Using this resolver to
perform a resolver discovery reveals the intention of potentially using
alternative resolvers. Alternatively, narrowing down the discovery over a
specific sub type of resolver (DoT, or DoH) may reveal to that resolver the
type of communication. As result, when performing a discovery over a domain
that differs to the domain the resolver belongs to, it is RECOMMENDED to
request the SRV RRsets associated to all different sub type of proposed
services.</t>

<t>The absence of traffic that results from switching completely to a newly
discovered resolver right after the discovery process provides an indication to
the resolver the DNS client is switching to. It is hard to make that switch
unnoticed to the initial resolver and the DNS resolver MUST assume this will be
noticed. The information of switching may be limited by sharing the traffic
between different resolvers, however, the traffic pattern associated to each
resolver may also reveal the switch. In addition, when the initial resolver is
provided by the ISP, the ISP is also able to monitor the IP traffic and infer
the switch. As a result, the DNS client SHOULD assume the switch will be
detected.</t>

<t>With DoT or DoH, the selection of port 443 will make the traffic
indistinguishable from HTTPS traffic. This means that an observer will not be
able to tell whether the traffic carries web traffic or DNS traffic. Note that
it presents an interest if the server offers both a web service as well as a
resolution service. Note that many resolvers have a dedicated IP address for
the resolution service, in which case, the information will be inferred from
the IP address. Note also that traffic analysis may infer this as well.
Typically suppose an IP address hosts one or multiple web sites that are not
popular as well as a resolving service. If this IP address is associated
frequent short size exchanges, it is likely that these exchanges will be DNS
exchanges rather than Web traffic. The size of the packet may also be used as
well as many other patterns. As a result, the use port 443 to hide the DNS
traffic over web traffic should be considered as providing limited privacy.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>This document requests the IANA the creation of a new service name in the 
Service Name and Transport Protocol Port Number Registry
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml</t>

<t>Fields Port Number, Transport Protocol, Assignee, Contact, Modification Date,
Service Unauthorized Use Report, Assignment Notes are void.</t>

<figure><artwork><![CDATA[
Service | Description    | Registration | Reference | 
Name    |                | Date         |           |
--------+----------------+--------------+-----------+
rdns    | DNS resolution |  TBD1        | RFC-TBD   |

]]></artwork></figure>

<t>This document requests the IANA the creation of the following underscored node names in the 
Underscored and Globally Scoped DNS Node Names registry
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-14</t>

<figure><artwork><![CDATA[
RR Type | _NODE NAME | Reference 
--------+------------+----------
SRV     | _rdn       | RFC-TBD
SRV     | _dot       | RFC-TBD
SRV     | _doh       | RFC-TBD
SRV     | _dns53     | RFC-TBD
]]></artwork></figure>

</section>
<section anchor="appendix" title="Appendix">

<t>Example of a file.</t>

<figure><artwork><![CDATA[
_rdns_udp.example.com PTR DOT._dot._sub._rdns._udp.example.com
_rdns_udp.example.com PTR DOH._doh_sub._rdns._udp.example.com
_rdns_udp.example.com PTR DNS._dns53_sub._rdns._udp.example.com

_dot_sub_rdns.example.com PTR DOT._dot_sub_rdns._udp.example.com
_doh_sub_rdns.example.com PTR DOH._doh_sub_rdns._udp.example.com
_dns53_sub_rdns.example.com PTR DNS._dns53_sub_rdns._udp.example.com 

DOT._dot_sub_rdns.example.com SRV port=443 host=dns.example.com
DOT._dot_sub_rdns.example.com SRV port=53 host=dns.example.com
DOH._dot_sub_rdns.example.com SRV port=443 host=dns-dot.example.com
DNS._dns53_sub_rdns.example.com SRV port=53 host=dns53.example.com

dns.example.com AAAA
dns.example.com TLSA
dns.example.com RRSIG

dns53.example.com AAAA
dns53.example.com RRSIG 
]]></artwork></figure>

</section>


  </middle>

  <back>

    <references title='Normative References'>

&RFC2119;
&RFC8174;
&RFC8145;
&RFC3646;


    </references>




  </back>

<!-- ##markdown-source:
H4sIAGv4KV4AA9Vc+3Mbx5H+ff6KOekXKQFgy5adROU4RxNUxDqJoknqfKmr
K9UAOyAmWuwi+yAE28rffv11z2sXoCzncnV1LJVI7GOmp6cfXz8G0+lUda4r
7TM9v7jW9Z1t9PO61nPXLvFhr1/Z5dpUrt0os1g09o4erO97oqiXldnQWEVj
Vt10c1t202LbuDs7NUUxLepVXU+L8OL088+VUqax5pmut7YxnasrU6rdLQ1Q
tfVWvds90+dVZ5vKdtM5xlRL0z3TrlrVSi3rwlX0bN9OTbt0Tm3dM6V1s1ra
ou32WNPetnSlq5fZn64qbNWFC23ddI1dtfHzfjP42DVuGR9e1psNvRvvuqp0
VZyGVr8x2y3ThCvK9N26bkATfqb+N16jEeYz/crdmr7s4nXh3Zx4acuDm3VD
w54RNW1bV/Eq0Wct0ff7L373lb5pTNXqU1OZwuiruu9sfG7puv0zfW1c1emX
pm9oFRP9/Wm6Xxc09dNr/fl3X2cX+6pr6D0ZMl63G+NK2iMmdLYRQv/Vetpm
xCWlptOpNgsizyw7pW7WrgV/erBPF7ZdNm5hW230JgiP7tam07Yyi5JvQByX
pcPzXa2D0Oi6W9tG4aYpIRgkNHf0fNsv19q0JJs3xCn69UKv6HddWd1u7dKt
3JLmJ7qrmR4SY8q2VvZ9Z6uiJRpwK0p2RlytTRVlUe9cYXW9gthWurFtXdLz
RIU1zXJNa6eB6v52LePRP/ueiOhsgXEWNjKg0Ku+wYJIJGjJrd0a0gIbiZup
H9autH5cTapC5O7MnsasXOcMRlzsaRabsWviVzFYIAm9I9UhTq3rHU0VaNav
Tv6iw80h113X6i3pgiVhWVpmZ9+ScKuM8XpVmruaVk686CB9W1InXZq9bWZa
ixRsXFGUljT9ob6yf+tdY1mH9EXdscZDOqx+Z/d6Vze0Bw9evbm+eTCR3/ri
Nf99dfb9m/Orszn+vn5x8vJl/EOeUPTh9ZuX/j7+Sm+evn716uxiLi/TVT26
RCygX6Yq1IPXlzfnry9OXj7AhozYSMyX3XOQAuIMuE8ilzbzu9NL/eSp+umn
f7l6fvrFkyd/+PBBy4ffP/ndU/qwW9uKZyLBLPf+I+3eXpPdoD1mMShLMnJb
19G+TTB+SztWaRISOwMPSQabuuiXYJ3+6WFrl1OHSx9wc35EdA0p5VJkheiH
RogiCN+PCTtktoJCyCuik/er5A6KS+xRkMOkDPUWJJIq35G1kBFavbNlid+Q
QhojiH/fWvChzd6faSFw29Rkz8ligayFaS2YRxrR3LllTn5g9NOviNFgMajB
LTA0DbIkklzbYYV6BcGvbvWdaVzd41LbGZJ1Eee1jbM8aMgfPYDlsIoJ7Jn7
4bZjIXC3lfEiIc8zFYVbrcCNVVNv8jHVA9mFB/Qq0SGKfH5yccKz6E1N6sXq
wYq3JCfZgVSjK7vLJ4bVTGPRheF2sz5+9WXO+huSUlD2Zi6/I+nEXrKuvIvi
uVwnSp69HLcYxHgySNNfV8Ju3sy1574asu+IHSzdxvlPwYYdYS87hqWp1NoQ
MWGzkrkJNshVy7LnDWU75VkPacVjLWnP+UipJ0d2+ZCHxitMcDLkLcxmW1o4
Ou9NNhaelwntBkrFgteyDyCEQ1u5gfxCa0x0TArkYcFe6pz3MmIpkkLx8MyD
qqbLpYgH845ueBqhh1XdjTm9IldezPR5N9yFSLC8vDF7PExE37mWBmdpVgZK
s3K3vSA0DSe1IevXiJHMfc8vzaB46IId/G1dF8w47JVfuik25NmAGljwaETC
LURWZW7xVG5gYBuV6+jzqqS5RDS7pm+7zzYYgf7gS2TGYF4ave1F6+MgLGWy
geqeFbaH+gsDyquiZS77BvJV7ocsI08CCejblne1CtaOhUG2JPrfJCo8g9Gl
vTXLbEB4XJd7GexT3QBEdGRYeUk//eS2XxQfPszEZOZ2mlyMhw/EdJgSXj4J
ehT7obBne5WJOYzT33qiErtweXOlr65a240V5S3GfdsX29mBhih+mwSJGEZa
y1hLJru1FWw0KXjLkArEH1j3mRYg1C23xHfYYHoC8IkWBHvG7hTagreJW9AA
vtb0lcgXFGWL8fH4zrLHAakwaoYG3GLMShAJHnvbNnfBBQVDQhTtXLc+4nxc
pvyywNaO7B3N0fVNdb+T6fZby8Yfr8aHoJI1pkfwQSztbLlXybL5lwkpLPqR
vI/MbWuhJniEpGxJG8GWkuiiK46Mdk9aRrQTzoerRihCykys6Bvemsmh4IBg
2GUyGcqBNphUFlBGB5HEfhHJ5Hc8rwCoXJqg1Y/mr28mev76BeD945kOH+PG
4g3eVS9efMNUe+93giPDDoJtbCoX1karQwbwsialxAIZRQuKgWPtXbv2CCTS
SuFPWaRR2BUUhGrEIN7BONVVsCjRJfudYw62iEXoNR4D1wvTFOTByt4GXYxO
kp8nObcedLMMQ0fMO29wtoZkT1zCpoZbrvYMZ8haOgBqgtI5JRgQ0k02sm97
QkEBZUbVi6KCQXfgiSC70oJe16kVBZe4QLN08A87b/dua5EdOAtvwVd9Gc1L
GJekeb+lyIKmnqi4mwjP/Gb2FD+/I4E+HMpTuDMthSUb81eAkb3XGBUcJE/S
QkzpKVN4tS6CT5pez0mytmbhSgqWLC9bfO5+IJRqsWeeu/dYFWv426Im90v/
C8PfktgTiGLbWLUzthtDtUWwo/7+97+rzPbq6fRbhMtX3tYrto+5bWRT+icV
A2v8fDOdqqOGlB8mLs5A3OwtrWAmA44f/OjrL/D6+h98++J6Jqz42PvMBkXR
nRfbB3MJxGhugcQPaJwHEk9BXLuG2O5tggcgEvIkKVVemgCMIYdjg+w3O7fC
2GA2UDsTouUSlpNtBMlIO1IB2LHKNA156gKTI/oVvznTr+BuyZaWbung7Ome
2vbNtm5l+CxGqtKIdDUfUFST4/iEbVtvmiB4I/TLIPHFzc3ldRTJ9cd2XaKT
nCxvQFqiuwPegqN1y8xS0c1NX3YOpjTwi91SoA4OMG0kViCeBfq3Msuxi0uR
Me+zd6njffQIeezBADHi+wHsZXpIZsOrIZGqcu1reTZr2vAWQV2yCzC3GbRM
Rul8NUKtwFfRgUmUFZNGA2A4gTHdOYRCZevNer5sKxY9sjL3szznEGaOKQOz
d4nXUZLWPvAKoU9kWQqtH7F6TUTZJJcBLXsssgP3OAR6IC9EP8AFIAcqUC8J
005i/JzxaMnwgGAc4WpTFE6StZyKbTayHrOoPQiJMtbR8CuBH2Sut5zkYlis
AmF6uSaBrVIwmYGOmD/b1C0UD4/T0x37tomEdRNxCVsQRQLnV7W0FFKtJOU1
0TP6Odx2mZnVF2hwXr+YwIUF3Js2Oywbr19f/ftx8MvbFhaRq40bg6jM9wQM
1TSOk5grIlmSbzlbaTer+j6mA+1SUAFwc8PbzPCXr0mgkWi/+Y8bQqEskzPN
BLIY+/i6EXQ/MJ5sI/yrYdk7hkUwLoT7CFE09bZxIfMRNmxhicV3IWNmsqXB
fm6wc2a0TIKipEN3nGsbpZoWZEVZGpBURUazPG5EEm6G5fIhQ059iA0qi6jc
EHKv6h1vNPKgAeYc57TKPRQJDMGUiFMycn2yBAQcxMKAl/Y90my30N6GQ+1O
7gZHdn126hMtrfUQlPg8Th5UGql5inHpCsarbDlM0zScf27txunwXIg5ZxzU
ZItsvQHwiVMWCpYHXlvi1XC3vEp7zCmx7sJ2O4bKI554cxIpkKyJJGysGLfz
S+U1GKHACb9zQj+PvdyxbibTlwcczJKbl9dDcslHkC0DbFw2FiUfQgA0Mj13
4od8LLjtl2DbJ4AmNgt/OsBx+ZuH4A/vkOowtP3j5xPaPEfSjb8GA41+oDp/
fPr0SzaEf4wczQf+x+Z98r8979XV9fmf9SOa/rH+RkK1vrHfqqNjYev1N277
9VsvFf/D5/zkJ58wNUvIN5kH+fiQeHw4KgNg/DxEup5MFGcjJcXGWZ6U0zu/
DH5L//SQkziwWxZGH9Faifk5F+rrW3R5ZxfeIAoyMCPrszVNB2gBlIqcQV2h
3DK5D3+QTctdIofzcQzOySUyhmkydtVMWPJt9ycSfZw8GEFZx5G7r2G19arb
wSqSEyhQvWuQ+pPQ1T+SUNxByplQC7lJQvH2tnS3HOTny2j3ZAQ37cAOca63
72rYNA5TdcgU0HxKrEm3q5t3w0Q55+pRDsw2j6sPX3799OsPH4Z8Ec43FiDT
RLdMABUJzoxlR9CEvyO5GF9EDbY6r6Gm6kZyEwdlweGsKhdHMb9hLSGHy25g
mMiNfDOF2TKmcI0i8iDfWUokYIpuUL4BH1sfTJGjXzqChvuB1ABsKS6Pgszi
GHG0rmdKqyezsFSB68ANTZvndYlfX8zA1H6TZY4R7dCn59/PLzh/C/XgitKK
BoFhk6SJd1c5/9VzksaEDFf6qElw7bGZ4jo8mVkNaSIZ2hEToDuD0E6Kp5H5
d7BNHO6I+Af4E3CbUidpr4jV1t0JnyTGFEQYqhCjdxkJLSzT4TOEYUJ7IFLY
ZU/CGNRysTrEJ8Hht8pyZMW6Jhhq4sugq5y/WYEaSaksro9RMjxzS6CJE9so
bB7lRJZr5KQ5YwLWJoQZTSFxelGHfMCgLu6NQTBdGWIqTGf0ytlSCl0DFJwi
hJk+YYudi81gEr+2Wg84TAGII1uF7Ead5CwUtZDZbjQi4jHLJ6PBGTsS0WzI
VnVZ1juMEGlLyyFPBmQfnMzJRNxq3WiPlvg2WMLNBAvmBSKOgJ6835/9M4HO
r4cdv276X8A7/7Tp74M9g1Te/wXT/pHp/4lM++j09zFNoNVDdEc1WSAyUvrQ
OUABBie3PAS4p9chr9x4WBC7ZVi7Y5bl0LrAVZS2GxtGziyQYXPLdRZMd0pS
++1R9HJgftgBZ705WTOONOKIf5U98jl8bJIYJu6xsFwo7bK8QFy5XzdHmAgv
N0gSVjxf4zEG+y1uoRr7CG6HOm5xZ+rKpiGwjszkL6xPVrDRH/Ubtd7E+TS7
z/SJMxkFkN640YvvOH2zJWkoDtxTiEq5hg/zLyFhDFclowwSG2lMyhN/Z1dX
r6+4L04YdZAJoolUglYejhwrXR7LBADdhSV6t4tuJ9/dFaCzb8AJY0e/lw0O
N8b7wM1Tk2OFZR55kXljHbvT0ErgUb2PkEM2oR3B3aOJK17CTL9IgkYevqit
JFlQzvHud4C4BxnjEMYPd11QTJgL0CBBpla2za8GtZ19xPgjArninaEtTgJm
xIia+jx58PZDQsYO1nSRrNCfxttVuyrj1KFBC7UEGK/rg/oxYzFGuqG0RSbs
xfm1vj47RUeavjg7m1/ry6vX35189/Iv+ua1vnlxRr8uz0/16+f6RM/P5uen
Jzdncz2/Onl+E0rXvkPheO+lL0ckYxggIWlhaYf9krSxPgkrsC22V0Zmik3o
YZ7Ge3MAEZW3niljFffYDxW7y7L2sazhcyx0XoEFfr+r6l1pi1sruD6tI4Ls
EOaG+BQBat13U3p+gXSrb7whEN+Gvoxh6EwQCvie9Y/DWt+9UNZLJNSW9Tbr
VEGbCmZkgz6Ob8wgSs7DsEG8ZxxZbBI+6VQNZjLwOGzGMNwraX/zrHzKl0am
qqPRZ6YidTWQyxFVbBRLh2hia6uYJslQdwoBRCAzz1vd4WHZMmlwk5yEN8KA
2SkA49aDmWm2RpQwzZxXRrg/Qd5qY2tWmLCxfB31d8fJ6rJGUCROXhaxykfw
8/q3pOHqDtVq37YmElX1mwX4NHhVhZ418sWdZNFpn82+rFGmBumF3VruA2X6
S1vddutgxhq0x8hAEwpMVL4qZmpuQbkIFRrpZJyoHD7jstmaZVdJG9pBc9jG
UAglYIQEyCzXyNsXqVWoriW9PtjV5BtQPDf8KrEZzd5QdPcjwY1CureES7S9
re9ldN0AdIXnQnH/Pk8hCem23sQ+gePJ93orIb3cVDn9YhRRpjEO6SJugSTe
vLO89U8//8PXZMAB+8Zzh8KAxrI5K1h1ymzQH5/HaO1YJAb94aH4kI9MfGHu
k0TzHjLSoTDRh6Msld5YNbZrZG9Cdv/m9DLY+a4xKLB8JIt0f/elkfqayhJ9
h2I2yub56h0Nz+FkSqSHDHlSV24d+CaT4c+//ZSnnnyr/nM2m/1XyKbefDd/
pn7DLbJZUolZeItwuaGb5NnoD2e8eAFqtrG3hE1i6rMO7FXq+zdn13CyGH5e
o4skZOnIFIvEhYGjWnjX+Sdx577OcIre4sIfZGk5/ftG3EIq84RiDW1H1oYe
kr7BWE68lhCM5iMnHggKXjHZcBC6rJQM/qlYSeVUWwC03IXDD/VCE4067eqp
5Uo9j4eBbNX2jU36qYYIfQlfuYzilcnIlswjo1TB6kYOEAS5JBn2FUMuli/t
tpNGbjQ15X1CeliTzhMgI1ekH0lhFJ1+eo8S6/n1ZUjYPo4hg1+tAdI9sg/x
wEmlTNfBFjD82NSV62iveVywwC+EBB3q1pLqlCRH9QLMFs8VHEXX9GTVVope
ZS06YFla0CrSHZKu2G5ucfMFVGGl4hIeTF5c56PQg8pXVq4hQ7Gut4/Jnr+j
5VCU2Oy5AV/3sSI2UzcH48BDoi+NFrvn4wdoKuN0fmgozExKSRSVctaDxpES
vjnGVRZdOTuV1h3PeAVpBV+D2MzUDxjt+CZ1a9/aK1YsHU0Ata29ZWQ7qj2q
e2qPEx+WizC3COi4KE3becunVniDo9REYtRgbUktpcOOfXosX1d7OEQv3WNx
UkGUpEDkS75je3CzzkvFvjK7uK9gzB1ILR+SIO24HTbLpaJtzqJhi3/w8IeN
HzONjSEIqfxcyVhM+LENhOvWt6oShR0FPYQyucnEV1V2Pse9l2Mi6Nwn1xNL
t1zNPqKavjj00Zpywgv18NFUq/BLOrpg31Tml6DGS5A6T83H/HS0D9GEBRge
WVCHWpaYuY0tHArnhfXtVKLkqf9BEEAJvCQtnskQ55Uo1LbpvdFxicCnX1F0
Rx2KUXmGUaT5dmd9P57XsxETPXTJOlRYi9RfYU9WEvT6Tm7340DJ+9jWTcIj
7E65aB8hM9xQpEJ9bP3n1l4vz0HbuSqyNpjyznJe5Tns3mSU3EtqI13AW4Cw
jwjaRHNrK5aTCplxS8NoxYF8s3B4TZ+ypn+iCcrj3k8XWRV0dJqddBluMIMI
LyzcCXu/aKihTfTHYuywPcaV+5DFGcaWkJF2oH4HPhxkhASc5xx5BHK2rl0H
64UURLmaSkumyirucUdCG1hqMZFTYKlc6/cSm4Fmyno1xb8diWK7dtssQZaK
sR+jK5wwU6cZNSd+H9Ck9ej05LFOR3G4MzzkBkLze1h/OJBJrlTF2GnM4NCe
c1CxPVZHVglNRGlJLUnFIHOSonFJNPiEbUiHnCNKhRdM3f2ZthMrF8QU35NJ
cV3sjT5qR5WkblNTEkT4iK5xt3bwUJm1awB3uIU9GAqOKMg/cgXqKFrOBV3y
d50/4cBMjGZgMugGhI1eEa3o2KS1qYFrjSnXLC/p7WHs4Nxs+iq0ZXyiwovZ
yzUiargHV5nBxHl5CN07u1ecN4gp6Rgq+4gwnoYkyJsld4TiTV3YUib+wS70
5b+dqzyPTTtLL56eHOvRAKGlWzRwXT7euTkZsGcYGMyQf0zWIXFUks21ZFxM
lzsYBlcZR1RajPCSYU1aia8NzE8uzqS379CqidSyRNGT0sAdCwAD+b5zPPdk
vG/QpHCyGs4i37GAt6G+YT1idsDFupHlnKhQXr0ZEsfJ4uwA2NBlhWOCEIuc
WQObmDI1qYeNbURIPm5cm54Zz20WhDnyZj1RMdYyfQmZWx5GsJHNA1K7elmX
wyONsjtZ3pDZRUFMzb39fO449pyAWQNjNAH/PuqhRyvaIPxYyGnepRwHDREn
w/M7gKqUIUqGrfNHm0PpEOjE05K5siOBc9tzXkmbYT6HD2Vx3yznCXB4rwzJ
aDnmHjusQigM2tleVz5IQybxja98SeAUsuCh7TNnbNoJWabkT9OikG2oOynm
cLZ+fGQ/S1adpMtYoxxXkC6D3XjfZXtUNEaxcJWH6I/m9c3EfwHDY1YnITIm
ozL5kCIAI9DcpnLThOTepTVk2OkzJmiQcA2HNQfnGIcSkEQy5FgyxyLH9D6h
2RsdyMMTbmEtaARB/jFkYeI5drNoQ0tHkITAkVRmkIYWaacKp/0kIV/ZHR/8
k9Xn7r/hmq9ZdfFoxdiqpEO3Vagn+4brAWsOzWkip6tD8LLGETbOG4dzafKU
6pHhoRVH8+ZP3RzC2ryHxxsn9Gn5dn/fAKX8aGJJ8ygWB1QiYR78hNCI7HFL
FAZo7Dmtgp9Oexa1YDKok8e9ITwP3RjtO7K1agC8uKYThBzGlSljsxz6hSYx
/j1kiWtVFuhJfuv6chL+iH14wZOGRALfv0xpX2SN0WmqchrQfRRVabS7odc7
MD68FdlfWLHB7G051RC/WuVIko4P4qPlg1/3spH4D6mL5yx5LSzucrwpptbG
R+kRei8EYMq44dCBZ0aHGIp4y54k37xwoAKtsuFaPcrjxQMaqM75o0peQ2jj
YQFcOp/LkTKbFnxFAnEVI6cD1DGaM0e+HiKbCqm2fYbLOYIgE2alxyMv/3Hl
OqrnYMDJMDqaeMlKChJaCFkiGl9oVF5kYnlxdAAkiZIp961rPRhaMWtdrNXO
VIzzcp+YEY6mn5YrQujfDefLmGGuyxvyaDfVtt72SKTmPPQMGnzDBB/ecYN+
6cH3NOCoKmfycHaQRJFLUFkEIKY+nDb1ue3BaYzANMDBdJWQkAgXrfGHJE0z
nwX+MfYW+TJSNAkhIDOtCgvbpKPK3rq0R3QUiCRqE+p7LjW2qCjMrBKZdNOq
5aSIfMFJwS7CBNMPVgYLuRWoJ50IXE0Zg77h9yN5f+gPaeD57qBem38nCRdN
vddVodPhIrTV3sRv7bgMOPISny4kHXXFtZxmr9Zdt22fffbZbrebORLJWd3c
fkbb7W4rhlWf+emmfGx6ihGnktL62K3Z+02JpBG3R2XzTo7QNaGt4cQEKdgp
6n9L2qBXdSFoHEufk+BN4hLfVD4w/pGYjLLPlcV4YRjmJVROSmt3tUvtk2GI
n/WcuzMkb08/PweGyIT4GDrAftaKmcpPjX5+ZtKyj9ktfCUT//x2Ovr57f0f
fyslaBl6eEyVBr/5bv4kzXX1/HRKV3guqd39WnnqBilCOcy5rCHQFbqx5GB9
kLA32W0I2J/LesHG6Ro9GPK9ARd47YJfaz5ZwGjB0/Q9IKOPs/frblM+HF6c
PnkqK766QjIMe/T24vX8TF+cvDobbN7xTcg+KCBP4ScKpWPm5rfREPzR2+uP
3uZGp+Ft3rSH+gR508K9V+rMf90C6/rKcS8HHvr/fUwd9B1vPs1XkJ44pODe
k07jNdw7QCDyniEGC7nn5JlSh6QeNPIOGnJHT3zq+1/d+/qLXzv9FKIxGOPI
Sn+JiK++HO7n+B20sB9c5BTN0WZjHmA4ZhxidFmak0Njwn8DBQe/EUNTAAA=

-->

</rfc>

