<?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.0.40 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC7871 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7871.xml">
<!ENTITY RFC6891 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6891.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC7719 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7719.xml">
<!ENTITY RFC2308 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2308.xml">
<!ENTITY RFC1700 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1700.xml">
<!ENTITY RFC1930 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1930.xml">
<!ENTITY RFC7858 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7858.xml">
<!ENTITY I-D.hardie-privsec-metadata-insertion SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.hardie-privsec-metadata-insertion.xml">
<!ENTITY RFC7042 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7042.xml">
<!ENTITY RFC3315 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3315.xml">
<!ENTITY RFC6355 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6355.xml">
]>

<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>

<rfc ipr="trust200902" docName="draft-tale-dnsop-edns0-clientid-01" category="std">

  <front>
    <title>Client ID in Forwarded DNS Queries</title>

    <author initials="R." surname="Licht" fullname="Robert Licht">
      <organization>Charter Communications</organization>
      <address>
        <postal>
          <street>13820 Sunrise Valley Dr</street>
          <city>Herndon</city>
          <code>VA 20171</code>
          <country>USA</country>
        </postal>
        <email>robert.licht@charter.com</email>
      </address>
    </author>
    <author initials="D.C." surname="Lawrence" fullname="David C Lawrence" role="editor">
      <organization>Akamai Technologies</organization>
      <address>
        <postal>
          <street>150 Broadway</street>
          <city>Cambridge</city>
          <code>MA 02142-1054</code>
          <country>USA</country>
        </postal>
        <email>tale@akamai.com</email>
      </address>
    </author>

    <date year="2017"/>

    <area>Internet</area>
    <workgroup>DNSOP Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This draft defines a DNS EDNS option to carry a client-specific
identifier in DNS queries, with guidance for privacy protection of
such information.</t>



    </abstract>


    <note title="Ed note">


<t>Text inside square brackets ([]) is additional background
information, answers to frequently asked questions, general musings,
etc.  They will be removed before publication.  This document is being
collaborated on in GitHub at
&lt;https://github.com/vttale/edns0-clientid&gt;.  The most recent
version of the document, open issues, etc should all be available
here.  The authors gratefully accept pull requests.</t>


    </note>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>Some DNS operators generate, or wish to generate, customized DNS
responses based on the originator of a DNS query.  For example,
<xref target="RFC7871"/>, "Client Subnet in DNS Queries", defines a method to
convey partial IP network address information about the device that
originated a DNS request, so that a response could be targeted to be
topographically near the source.</t>

<t>Some specialized services, however, need more precise client identity
information to function adequately.  For example, a parental control
service that restricts access to particular domains from particular
devices needs to have a device-specific identifier.</t>

<t>This document defines an EDNS <xref target="RFC6891"/> option to convey client
identification information that is relevant to the DNS query.  It is
added by software on the client's local area network, for transmission
to the upstream DNS provider.</t>

<t>A similar EDNS option is already being used on the public Internet in
two different implementations.  One is between the <xref target="dnsmasq"/>
resolver on the client side and Nominum's <xref target="Vantio_CacheServe"/>
upstream.  It uses EDNS option code 65073 from the "Reserved for
Local/Experimental Use" range to pass the client's Media Access
Control (MAC) address.  The other implementation is for Cisco's
<xref target="Umbrella"/>, aka OpenDNS, which encodes the client's MAC address and
complete IP address.  It uses option codes 26946 and 20292,
respectively, from the middle of the "Unassigned" range.</t>

<t>This document codifies a more flexible format that can accommodate the
needs of both implementations, as well as other more opaque
identifiers.  It is intended to supersede those non-standard options.</t>

<t>This option is intended only for constrained environments where its
use can be carefully controlled.  It is completely optional and should
be ignored by most DNS software.</t>

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

<t>The IETF is actively working on enhancing DNS privacy
<xref target="DPRIVE_Working_Group"/>, and the re-injection of personally
identifiable information has been identified as a problematic design
pattern <xref target="I-D.hardie-privsec-metadata-insertion"/>.</t>

<t>Because this option transmits information that is meant to identify
specific clients, to be considered compliant with this draft
implementations MUST NOT add the option without explicit opt-in by an
administrator on the local area network.  For example, agreeing to the
terms of service for a device-specific DNS filtering product would
allow the option to be enabled, and only for communication to the
product's DNS server(s).</t>

<t>Implementers need to be aware of the various laws and regulations
governing handling personal data, but they are out of scope of this
document.</t>

<t>No explicit provision is made in the protocol to opt-out.  For more
discussion on this, see <xref target="security-considerations"/>, "Security
Considerations".</t>

</section>
<section anchor="terminology" title="Terminology">

<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119"/></t>

<t>For a comprehensive treatment of DNS terms, please see <xref target="RFC7719"/>.
This document uses the following additional terms:</t>

<t><list style="hanging">
  <t hangText='ECID'>
  EDNS Client Identification.</t>
  <t hangText='Client'>
  The user or device that originates a DNS lookup.</t>
  <t hangText='Nameserver'>
  A DNS server capable of resolving a DNS query and formulating a response.</t>
  <t hangText='Forwarding Resolver'>
  A nameserver that does not do iterative resolution itself, but
instead passes that responsibility to another resolver, called a
"Forwarder" in <xref target="RFC2308"/> section 1.</t>
  <t hangText='Tailored Response'>
  A response from a nameserver that is customized based on a
policy defined for the client requesting the query.</t>
</list></t>

</section>
<section anchor="option-format" title="Option Format">

<t>This protocol uses an EDNS <xref target="RFC6891"/> option to include client
identification information in DNS messages.  The option is structured
as follows:</t>

<figure><artwork><![CDATA[
              +0 (MSB)                        +1 (LSB)
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0: |                         OPTION-CODE                       |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
2: |                        OPTION-LENGTH                      |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
4: |                       IDENTIFIER-TYPE                     |
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
6: |                                                           /
   /                      CLIENT-IDENTIFIER                    /
   /                                                           /
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
]]></artwork></figure>

<t><list style="hanging">
  <t hangText='OPTION-CODE:'>
  2 octets per <xref target="RFC6891"/>.  For ECID the code is TBD by IANA.</t>
  <t hangText='OPTION-LENGTH:'>
  2 octets per <xref target="RFC6891"/>.  Contains the length of the payload
following OPTION-LENGTH, in octets.</t>
  <t hangText='IDENTIFIER-TYPE:'>
  2 octets per <xref target="Address_Family_Numbers"/>, describing the format of
CLIENT-IDENTIFIER as elaborated below. [ Is it better to call this
ADDRESS-FAMILY? ]</t>
  <t hangText='CLIENT-IDENTIFIER:'>
  A variable number of octets, depending on IDENTIFIER-TYPE.</t>
</list></t>

<t>All fields are in network byte order ("big-endian", per <xref target="RFC1700"/>,
Data Notation).</t>

<t>This draft only specifies behaviour for the following IDENTIFIER-TYPE
values and the corresponding CLIENT-IDENTIFIER lengths:</t>

<t><list style="symbols">
  <t>16389 (0x4005, 48-bit MAC): 6 octets, fixed.</t>
  <t>1 (0x0001, IP version 4): 4 octets, fixed.</t>
  <t>2 (0x0002, IP version 6): 16 octets, fixed.</t>
  <t>16 (0x0010, Domain Name System): Variable-length domain name in
uncompressed wire format followed by a variable-length custom token.</t>
</list></t>

<t>For DNS servers that implement ECID, it is RECOMMENDED that they
recognize at least the 48-bit MAC CLIENT-IDENTIFIER.</t>

<t>The use of Domain Name System as an address family is to facilitate
custom tokens that are not well-conceptualized as addresses, as
described in <xref target="using-the-dns-address-family"/>.</t>

<t>Other types of identifying addresses, such as a 64-bit MAC
<xref target="RFC7042"/> or a DHCP Unique Identifier <xref target="RFC3315"/> and <xref target="RFC6355"/>
could be accommodated as devices and needs change, without needing to
define new EDNS option codes to cover them. [ Why not just
bless those obvious candidates now? ]</t>

<t>Multiple ECID options MAY appear in the OPT record.  However, the same
IDENTIFIER-TYPE SHOULD not appear more than once, and each ECID option
MUST only carry one IDENTIFIER-TYPE and CLIENT-IDENTIFIER pair.</t>

</section>
<section anchor="protocol-description" title="Protocol Description">

<section anchor="dns-query" title="DNS Query">

<t>Any client that originates a DNS query message MAY include the
ECID option in the DNS Query message.  It is normally expected that
the client itself would not do this, but rather that it will be added
by the local forwarding resolver.</t>

<t>When a DNS forwarding resolver, provided as part of a router for
example, receives a DNS query message from the originating client it
adds any IDENTIFIER-TYPE / CLIENT-IDENTIFIER pairs that it supports but
which are not present in the existing client request.  It then sends
the request to the upstream full-service resolver.</t>

<t>Because the option contains personally identifiable information, it
should be protected by either only being used within Autonomous
Systems <xref target="RFC1930"/> controlled by the same provider, by going over an
opaque channel such as DNS over TLS <xref target="RFC7858"/>, or by being securely
encoded and varying per request.  It MUST NOT be sent in clear-text
across the Internet.</t>

</section>
<section anchor="dns-response" title="DNS Response">

<t>The logic used by a full-service resolver to customize a response
based on ECID is out of scope for this document.  The resolver MUST
NOT include the ECID option in any queries that it makes to external
authoritative DNS servers.</t>

<t>For possible caching purposes, the forwarding resolver needs to know
whether filtering affected the response.  If the name resolution
involved any names for which customization was possible, even if such
filtering resulted in delivering the original data, the response
SHOULD include an ECID option which contains the FAMILY-ADDRESS and
CLIENT-IDENTIFIER pairs that were considered for filtering.</t>

<t>For example, if a filter is set such that only names in the
example.com domain are possibly restricted to some devices, then a
request for foo.example.com would have the ECID in the response even
when the request came from a device which was not restricted.
Requests for any other names would not include ECID in the response.</t>

<t>So that the caching forwarding resolver does not need to have any
knowledge about what filters are in place, it is the full-service
resolver's responsibility to adjust any TTLs in the response as might
be dictated by the filter policy it has configured.  That is, if some
name is filtered only between the hours of 09:00 and 17:00 and a
request is received for that name at 16:59:59, the TTL on a positive
response or the SOA ncache field on a negative response should be set
to just one second and the ECID option included as described above.</t>

<t>If the request contains a malformed ECID option, such as
CLIENT-IDENTIFIER not correctly matching the length of described by
OPTION-LENGTH and IDENTIFIER-TYPE, the resolver SHOULD reply with DNS
rcode FORMERR.</t>

<t>If the resolver by policy does not respond to requests that are
lacking ECID of the appropriate IDENTIFIER-TYPE, it SHOULD reply with
DNS rcode REFUSED.</t>

</section>
</section>
<section anchor="using-the-dns-address-family" title="Using the DNS Address Family">

<t>When IDENTIFIER-TYPE 16 is used, the uncompressed wire format of the
domain name is followed by a token that is otherwise opaque to this
specification.  The length of that token is defined by OPTION-LENGTH
less the two octets used for IDENTIFIER-TYPE and the length of the
domain name.</t>

<t>The name used SHOULD be in a namespace that is controlled by the
service provider that is using the option, but need not be resolvable
in the DNS.  We RECOMMEND that providers use short domain names to
minimize DNS packet length.</t>

<t>The domain name provides protection against conflicts with other users
of the option without the burden of creating yet another IANA Registry
to manage yet another two-octet code. Co-operating forwarder/resolver
pairs are the only users of the data who need to be concerned with its
format.</t>

</section>
<section anchor="implementation-status" title="Implementation Status">

<t>[RFC Editor: per RFC 6982 this section should be removed prior to
publication.]</t>

<t>The protocol proposed here is not currently used anywhere exactly as
described, though the Nominum and Umbrella implementations are
substantially similar.</t>

<t>The authors know of at least two providers who wish to have it
properly standardized and would implement the standard in preference
to either of the existing non-standard methods.</t>

</section>
<section anchor="nat-considerations" title="NAT Considerations">

<t>Devices that perform Network Address Translation (NAT) SHOULD NOT give
special consideration for ECID. NAT translates between a layer 3
private IP address assigned to a client device on the Local Area
Network and a layer 3 public IP address for use within the Wide Area
Network.  If ECID is being used to pass an IPv4 or IPv6 address, it
SHOULD use the internal address without NAT translation, because
transforming it to the public address of the NAT device would coalesce
all internal devices to just one address.</t>

<t>Other ECID options identify a client device by a different means,
e.g. its layer 2 address. This sort of device's identifier is not
impacted by NAT.  Therefore, DNS queries may be passed without
modification of any ECID information.</t>

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

<t>The identifier of the client that initiated the request will be
visible to all servers that are passed the ECID option, and the
various devices on the path between the local network and the
full-service resolver being used by the forwarding resolver.</t>

<t>DNS filtering products are easy circumvented and should not be
considered real security measures.  With commonly available tools it
is trivial to discover the non-filtered DNS responses and use them in
place of the filtered responses.</t>

<t>Along those lines, opting out of this specific protocol is as simple
as using a different resolver, such as a full-service resolver on the
device itself or one of the well-known public resolvers.  Of course,
other devices on the local network will still be able to see
unencrypted DNS requests from the device, and the only way to really
protect against such monitoring is to use an opaque tunnel to a
trusted resolver.</t>

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

<t>IANA is requested to assign a new value in the DNS EDNS Option Codes
registry for the Device ID option.</t>

</section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>The authors wish to thank the Barry Greene, Martin Deen, Benjamin
Petrin, and Robert Fleischman for their feedback and review during the
initial development of this document.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>

<reference anchor="Address_Family_Numbers" target="http://www.iana.org/assignments/address-family-numbers/">
  <front>
    <title>Address Family Numbers</title>
    <author initials="." surname="IANA" fullname="IANA">
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
&RFC7871;
&RFC6891;
&RFC2119;
&RFC7719;
&RFC2308;
&RFC1700;
&RFC1930;
&RFC7858;


    </references>

    <references title='Informative References'>

<reference anchor="DPRIVE_Working_Group" target="https://datatracker.ietf.org/wg/dprive/charter/">
  <front>
    <title>DPRIVE Working Group</title>
    <author initials="W." surname="Kumari" fullname="Warren Kumari">
      <organization></organization>
    </author>
    <author initials="T." surname="Wicinski" fullname="Tim Wicinski">
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="dnsmasq" target="http://www.thekelleys.org.uk/dnsmasq/doc.html">
  <front>
    <title>dnsmasq</title>
    <author initials="S." surname="Kelley" fullname="Simon Kelley">
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="Vantio_CacheServe" target="http://www.nominum.com/product/caching-dns/">
  <front>
    <title>Vantio CacheServe</title>
    <author >
      <organization>Nominum, Inc.</organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="Umbrella" target="https://docs.umbrella.com/developer/networkdevices-api/identifying-dns-traffic2">
  <front>
    <title>Umbrella</title>
    <author >
      <organization>Cisco Systems, Inc.</organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
&I-D.hardie-privsec-metadata-insertion;
&RFC7042;
&RFC3315;
&RFC6355;


    </references>



  </back>

<!-- ##markdown-source:
H4sIAE8vx1gAA7VbbXPbRpL+Pr9iTvkQ+5akKNmWbdXVZWVJjlUnS15JjisV
b7mGwJBEBGIYDCCa6/V/36e7ZwYgJSd7e3uuzVICgUa/99M9reFwqJqiKe2h
Pi4LWzX67EQXlX7t6pWpc5vrk4tr/ZfW1oX1KndZZRa4N6/NtBk2prTDvPJu
ObT4GA8zJlHkw/Geyk2DG/fHe8+VKpb1oW7q1jf74/HL8b4ytTWH+qxqbF3Z
Rq1mh/Sey3f6g6tvi2qmf6xdu1S3q+6m4Qm9U2WmOdS+yZXKXI47D3Xrh8Zn
RaGWxaHSeqgbl/GnXy9qO/Xys6sb/kWZtpm7mu/EfxrC+kN9NdLnRTZv+IqI
eOUmtm56l12Nlx3PTQ1+9LFbLNqqADeFqzx/7/ECC+b2nrzYH+vrtqoLb/VP
piztWp/UfE9WNOtD/QYC5a6SKy7Hy346Yk3thUtt1dS47/31EV+wC1OUh7pm
jkYlcfTnTBgZZW6hNmU5GR1DGrOqbZXZnkAn5q7I9fHmV7Uj09u8aFzdSXl0
a/BKfWOzeeVKNyPbb4j4bKxf1c7kK7PuyXVsFpO6yGe2J9nbIz3e33u6P9wb
P3v6u+KRN/3Z8JtFqsrVC+j3zpKxjvK8tt5/em0WRbn+dNEuoAx/yAQ6k8o/
kffs6ELoB/8OFLRQ0IGC3GHqGck1b5rl4e7uarUaFaYyIyhj13hfzKoF/Nrv
GiExnDKJYSUkduHg1bTP7Mm7q7OfTj8FZ/7EzvwQq8Mtlj+YGqbR/9MuTF2k
79iqH0abl7cfvSkW+kOR4d7brSdvRptfBHUIj1sBt60MD20gkE1Tm+wW3lbY
ZspaWc1282UNcXeDI+6SFyIJLIz/7SFRhcvrYuEgn6WYUD0er0f9i4HDQO1b
Fmrm9paf8cTRqL3dDQ/sIk2N5s2iJJZ+MkhI7tOxyeb22tZin23m8Lypir9x
MB/qC7coYNoBUk826jMktHRH61usVUKB3Hh3Wbu8zZrdDE9B0ZQvWVfvEStg
33yDH0RT4TOnr9e+sQt/n5n4/MM2c5kfteEOZiO3d7Z0SxgKuXQFo+NCkVnk
zmWxW+SUtqfrwN8Q5p5Oi2xfqeFwqM3Ek/0bpW7mhZfcr3M7LSrrteECcUr/
55akP6RfncGP1/hK6sHQL21WgJ4K7ymQQFFj6JnfpLIM9Kpo5nrWFrlBatKI
Jk3uZbI1Pl1jMybtpsq32VyncHPVSHiscM+n0/wTfYJP+7khx8L7tP+tRbXR
E/bgxutHH3/5+NfHGoIgmgsiYUo9wZczRECVqx7tgTaVXyHCSaZpbcFs1SB1
GH+LwojfPGf/gZ7ZytYgs2g9VOgHyjbZSOubOTL/qihB3+raLtwdHptY0Ld6
2U7KUD74TlKsy1rKM8TbxIIQShzMN3E1SmmuIT+U9mPRvGkn2jTq439Fa8+g
u3bCZr5rKI3ubpbjj/8tzOiF8w0YyXBV3UEu0alGJKWXD2BGpKDC+5bMAkG0
n7u2zLUROcwdsrWZlFbNbW0DYXFfr2fE6rQtSUlZZpcN5MRjrDrf+GCsRZHn
eF59R8VdwgOcKHXtFlaLJ0GdDRNkzTYWbNVQpZ+TKbqLGSAFYu1vglMUkvMS
BoFbTowXlZFsri5mRUUESVqTHG8N7gF0tP1sFsvSDtSXL/9x9fr4+Yvne1+/
DvROQETX7QQxEz02YKGdQS8EFhbi52ANFqvuYPQlcmIBhzh7p0O46VA7+r6L
yHJtI+rnaMSPMGxkFwIIr0F9A6AYvgOXo6RUTUtyqpACLHGBX1Xjlg7WWM7h
ZGSOypqa3+RdW2d2FLTNoWlK1qBHSqOUMNBzt0K6qAd4CtcX7K9wG8Iz4lNa
IrlZ98OFo6StJFRNDqYhQ7mtZDAP7eBpqAfagv1LFd4swkG0pi4yhCq5kOfg
Y31mbQkZcgeAUHnEo1v0rquQz5hlfmZu7uCYQbMpB+kuB41iQotxlwxaSUIT
dzh48RLu0M9uYmPRRMppEssb5mVx8AJkYXuH2kEPkwn6/ndGdyg4B6WGNawz
bVaUr4Lryku+97p0sKMm3Bw9asBZEpkZVQ/hShEU6LdLAmpmwS9C+gTuY2mP
tC8AXKDEfr6mTFji9nwtWQeAugsdSVMJhEM8hZfrvJhObc2OQEYl7QkShkSX
lZUM1qysFSpfvoTS/PUrxagr4VybEmrO1abKY/WFyF++3CveeD4KJ7prKdj7
0hDq1AfPxs+fiIfQK3auLHkYpILG1Dlpcvf0M3JMsRA/fO/tjoYiZ1acjZyu
r/y3AMhGH7E7qmNxWv3o7dHx4xjWIQ86PFZv6YSUQZbiev69R5KJpZuSDACv
vkTGhQgogojWuQY4hxDbLBwdpxQCNSHR0EsaSymm4yFqpKcMr/cPXj49YN3u
j/df7g84TVJFBSJYDzo1SVqOBWHnfSXQ1+ZBN/fihTowBBJnQMoR09J+LlAZ
tISA+H+GaEIgo19y1BISbSUxihdNoLBtF4JOvF5BP/QpCmXqbmkQND0M4WP4
wCsbW+WS+3wLw8KD6U0OCaty1dA3kB7tbNCLj5J0EZAouArJksyFKCfYg4SQ
wyJ3Re2kCYCR4Pm6aLxqKR9CvAl91KHuhZxW2jyxF22Fb+WNFMkwhxRWhceh
ZojIGYBrNDl0TAUjKpTvAhiC81Gk1KHvVOR0Z6c3rzmKg0n1KmB6iGarOQAV
/SK5gKnABR/qUNgdwRZZv7bDovo1wS5NOiW+y3UyAGGAjXQ3NxT1BB6iiXIy
oaEUhHvprgw5lnxKLU1DGQUx/sPZ8GSEHiIv7JD48zYbop4aajvAAwKXiH/9
CjW8spkhnTc924X81/gHM+/ChrQbEa5KdUAiC97G9ZLNTYoFz2yugh5kUNok
0Ku2PFW/fX99oy8ubygCBWkIU/QcVXb7GYTQG9N1yELmNRWSPTJcQc7FiETS
4P38fq9uztB8kyUlyyvob8FBFKsnee39ekd2nxYl7qZnQzcCFyHPgz3dqs+4
6MJWZNtcvKEXEL2RR2Qi0EOCYpelLFs/8o9hrLOoK8LPjCOEuJHyJknmDg2t
a1HdzIrTGvxuhmouzj0DXq4r4ho+nJfMfnBDTd4x0BNBT2vNJPELaSMDehT6
BU+sOFeBoQvX2YOLog+xvwBWIXTH9Q7NhgPsJmbJaCAa7EA5SOXI4a0X3Fzx
GwDKLBU4uG1bAxANs40IZRx5Hb5Tm9G7w5F9AzMWPGVZSzjfWo5gJMgd8i8A
zZ3oZ/Tz1elf3p9dnZ7Qz9dvjs7P0w9yh8Ivl+/Pw/f0U/fk8eXbt6cXJ/Lw
26Ofd8TEO5fvbs4uL47Od0QNPb2xZsVwlCJrwMBGwhqBnNXFBL8UVUBK+3t7
L1Gh1Wt2RAqj2s4tRAYQo5rdMEWYhnyF3Xeg4SSA6kGJjL6fE5HRVqnhqkYG
mjryWfKFXvvGtA6VOj0+O1GHggfiOHMDnkHjch13ka5BtqbOoge/U7eQmtvS
udt2SR5kFgIkajx+1PN4pP8lp0PIJviGGeyAHquZ0hM7N38XEfyI9UXDVrp+
FdARv6BK7xPOckf41tEPqD/sRndWXthKIWu8LaccFwDmvgGoYzTDuhNoTe8s
JkUJdyS7mkoqbERlaKloYAkLq504A653eiZ+Mn4BMOxDZdijSop+kIvXVZCI
eU8NCsMLc08WKotd85baNaOWDiG6Dlg8F4zbwcTQCnEaxFVB0RRGl5LAXnMJ
COU9BTN7zx+g+qLKyja3/wSsD40g5PFmZhP0S1gCmR0psYVKlPHBYck701iu
+/enMWDk9avH978J3+/pR+f4Pj76J7TP//J/TGR8qP/+rbdpyQPD48uT02/c
8fd/Hyf7v8NJYOT89OLHmzf/75w8/TYnZyenFzdnr89Or4Y3P797WCv/Rk4O
fs86f/xvN3Ky+/D3x+dnEGfYCfWvEPnfcfJ/04nqeeQh8sq+dllDUzwAgY1A
DkWaCoCkC2oDEYs3r04IddFZwChRE7f6I3rU5/GkgeGZrWbAggG2LM26dCZX
XTHaoDygFCGECQhtutADr334bIOgQyiyMd2FvspN1X1LItXYblg4sWBspD/+
os+AjBvqxunYimez6Ky4xh+dnFydXl8PXx+9PTv/+Qf98a/qPt1DzuaE07jA
yZEH6UEkIBbRveah3diSlWYOeBs6gRJwhqAEFBMHYpN1Q6M51Bf9aGdSzIZE
xlTAJJ0x9p6Px9CDOgHc0xdOcPfj0cYkmgFqgLs0+bNzcwdQWafS0Vlpiz11
Z8rW+tT0ZK6WssXi3FexOAGl8v/UewdPXrzUj8afn47Hzwb66YvhBGqmkcCh
PkjKmRaf0QfS7XTreDzeG1DDHmevT3Hz0/s374eb9zduPsDNew+RPpDb98YD
fcLDMU1AJZwcPKZjCzHeMDixTNC4ItM8p60EqXkqwauiTm4mepOu1CQXiFSk
esOjbm0lGKYHiALeSP0SB+aAHBFm6+FQuY0gvKpt5mYV0IDGFQKFMhjtFHvf
ICMBzNQSEqi8Jzt3n1Uam8ipHXFAg0qTEQhCsKi+JIFxclUCWjSGIERPo+w2
jEmNjxQtzyrUFhLmM4AheOejlM0jQ25jLxlxNeul5fatd/jSJ8wHHdw+HzyN
KkDj/gNB5PHTfcIuhLJP3hy/0++rAkgoYV0OH7rxyZO9Z7iR/FsuHDx5hgsq
DY17g5kA6mWISk/IkCab0+hnkFpauipNqBKIhiurexM4L3NSQXt2wYnow3zN
Ov0V6lZwJB6y0YTGTe64Cczw1iJn4F25leSjt23ZFHAiyexhfANV/KzNckkj
7dC3If/SwQbSCTL3mzi+5nk3/GE7B+vQGBE7gQ6PmGB7auwyK32RNTBB78WK
+zDON3LC5SD+Nml68H7qWJqiDoOcgElP2GuErvruu3S2gC7wqIrT5W90JNJT
BADK2ojolXryHsdRPYl4fCjNpviQneZW6I0B6qlNpzOIHuSWpkImBrH7kM6X
2m+Um3nC9E067eKBtkLi6GYb067Lid0GNPIBDWKQ6oEbBnF8zd5J0345wanh
ipYzvErzETrXQj/0sI7SkDPqkt6SBKT5Ozn9+p41d79hS58k9u1y6WrUcmq6
ZIAbswclVX6BGMF+Lnz/vaGXEVM0pAfcnXsl8zf+Tm9P9GnGOIwDn54au9GY
7eIw4Jdudqe/Nbuj1KzCOd/ExiNXSf22YAuz2/cOCCghQLCjtnGVWyB+VTiq
jqX75ROU7t44VAdvoIBMpxIDujpzDB8oW5hKyZyXE09ly5QHOcPQLTfnsYd7
/uLZC0JJSISTyBvPYWy5VjJFzzkeUbvWYXy0qfU0wJvQCEJMlaH41MPGfoZb
ZLULZwHxBGSUgjW1u1yEaEsmE81wuXzQUJwVY9fbmwGo1P9y7NJ0sz/MEiDT
G4eEljORJTEUidFLA3orDZB3h9P25LsLcyupGsJCOlOG7SiqizRa6BX0UOKX
0AeP+MM6g162Na5RwQoAdTuEuwO5W2R1RIhld+pGkmY6jYnHdlMRmEewNsOU
bsahiuqO6OYsEE8VWD8SeVG50qivKGcEhgcaJQGKmLJDqe71II0aI8U7tyXE
riPcDrkiThv7/KlQQaLCTbWh78BNv4MQlD0MoJvPcH43tazolKE3lSYhE9fB
Gin3FZQU5VueQNhG4kbKB0WuaEoyUcyZtDEQ0SDlrKCrdTqCDScqdFAckMFA
EpVRMUExW86N+iSlVPD5a3LEkAPTWIisQc4QLwu1jIwdJkZhJieqJFNSSu04
G6mrsFUgg294g4yyRNKuXEUTPcQGH4MnEJqc+iE3TsO3OMuW8+Vqrcivkd9Q
ZeQ8f0XkxBip6VmWhlCFAGCOlF5+SGei3/uHRnQ5ISYW8Obm3N/TJDSzKGbz
hs6RcqjGNF2uDS4RZmp4O53RwKmmxYzmU5xHeBjHLkSGVtIW+PBoPBHrn+ai
TNSMXMcvD8djTrB7z+NPnWfwwTeX5DjFw5uYOj73Dg6fvcT/JKogFw//yAML
yjxpk0OHHu768khXZB4r3aTcXtlZmoHK7V0NQwzQeTjrjnAaCoOr8tTrbWZH
9pCtsTaMeUcOEvJQctEY1Abps6QKint71BJyfyC8yX24ycxojQilV9xtc8DQ
cTBZb04smPkthJLSknhpSEu1XdI5IB1f8V4Mj0NeX169Pb266osUnoK3xLFr
9PLQCJMDxu2d1BopODMfMIrYQgw4unZL9IjNPUzMfn+PM8WrLczZ1enr99en
JwyQ3/uoEvp+c2kzwMVtkIYOGM5GtVe08c2OVlhVGw2w3+pzuQ1MM2pOKSta
fAmwpBHwm84Ruw2uzSERZRSmRGU7zLJBf8OeKjRBoLpycSTEEILi5aHG4t4o
qi9LaIdZLKYSVM5nN3EEvzTxnIMPprfAWdrEifgs3doms0Q3n4RukN1lEr2J
N8O6rgOa+WC7jl/IReIsLIVs3fSHEgQWFB2RMkric2ve3QuSBzH7RgwEfX9X
0MwoSjlepyWvE3E4SI2gcx+vguduHdrSpUlbAymTjjM6tyLR17ZJpyU0TgT+
m9Eh7pqyzMJU1GX074FJh2xSbohH+hi/8lpbr8DYejfGoJLSz8dtxBMlXeYy
LejRCGw1d/2zVJ5M1FVA47yTIJ7OkXS2uYZyjU+gdPXxF0Bnfcor34cMien3
g5cv9gVkxrOdLpXG1UVEN6Vjp/rLi9Sl3/RPTikNOHI/2ZOQdAJQXsvyJHsm
ipmsUQA2ZLJS2Y1RKIhdO5uz2GEdiL0/7s1sb4xwTvLthNY8aO2O5oGy6BR8
Ja4nUqXmBjJNmBB3nTeSduOOIVd3NEUkja2JYtghkRkQuBGE0Y24uLeJiyZU
8mvLO1IZLeOlLmq62QpubKfIGqFn410c3dxb9jgJ0xkJIluTrfVFGKfGTHlD
CxFyhK4fgcpj3Z0C6xnV1rDzpzdOqjnlUD4f8aubQMV2i1xGl2YNEZ4oXiPZ
WD3ScVWIAUtscAOCCxsOvHeljxBPKvLMgCGSTbtmHVXiiVJE6DWJygfaE+sT
kU4h9k29BjVucgGan727e0pIAp8HkTi3vEE1sXPmI27ezgkMxJzQV4kkP+m3
FV8kO9Bri9SvB1EimWB1ohJRLTtP5gxKAByEZvLp5XEI10cvccUrTg83xmFx
gnhP81zQul092oah5eTRbES5Iih+v9sf46k6/amM4BCi8b3X/a1tjmbagzFx
PAChpPzVvNg86K91Iy+ueZ5gfBwZQJtqwXtj4WSVwhHQNqDz/l73dzouTjy4
9tRjK+i3PzND+WgK07WVAt7CeErR8gd1seStuLIxtOZOSBjeAoppPUrFvZVo
qrgtaZCF+1BZJl9Vz93p6YdnAz3Xjej9wYnZgws9UjmQ09Y6K+qsXdzR5k3e
WzMLZVr1WkpEUanj4gp5h0dTQOfZH6ia8GSYylDa+Ia6XEnHSYqaGCQByiIN
bYP6NOvljJZ6B9lejkvZxEwItQWdPHBTFI2Xnkn38+mRY9RBY+KSdnMHbAqa
FrVNXPLRadcp1SDahvNUBJCc6RBe0Es/FroJYzdof9guYtuwXxynoby4lXjn
YwIqLlWM/Pg0L8ROaUu79nagBBpsec2mk7CLojiEOWrwUm+taisUk3q9bJJi
Y/8bh5tCuNviY/OtzFpQPG/vBYSU4BFLDzsTGuAcxnmHrESj8IB5W57EUbAo
/is+sVJ0yO8ED23HKF/kJpDZDLWB6wS3bivNx2/9ETUfI4RNjmM6RkAfKCAr
HeZJDdQpJvn9R1nqwXlHc7Pqx5JO0/1bJvKKp/c/1ghTaOstLZFXoGwR4a9s
9St6jUq9s/DwEPLhbwFflxaePgfYi+wUtZ4CjtGfj4T1tbsCguVtnCEpyUOc
1Onvb+IG1OY4T/4sgqiofwB9gTTokTkAAA==

-->

</rfc>

