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

<!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 RFC8509 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8509.xml">
<!ENTITY RFC6975 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6975.xml">
<!ENTITY RFC6891 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6891.xml">
<!ENTITY I-D.ietf-dnsop-extended-error SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-dnsop-extended-error.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-add-signaling-filtering-policies-00" category="std">

  <front>
    <title abbrev="filtering policies by the resolver">Signaling resolver's filtering policies</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="March" day="09"/>

    <area>ART</area>
    <workgroup>add</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document defines one mechanism that enables a DNS resolver to inform a DNS
client that filtering policies are in place and what their concern is. The
second mechanism describes how a DNS client can request a resolver whether
filtering policies are in place and what their concern is.</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">

<t>This document defines mechanisms that enable a DNSSEC resolver to signal that
filtering policies are enabled by the DNSSEC resolver. There are two distinct
mechanisms. The first mechanism enables a resolver to advertise policies that
are enabled/disabled without any explicit request from the DNS client. The
second mechanism enables a DNS client to request the status of the resolver.
Such consideration may be used, by a stub resolver for example to select an
appropriated resolver.</t>

<t>The ability for a resolver to provide such information to a DNS client will
help a DNS client to appropriately chose its resolver.</t>

<t>The ability to request or signal configuration information has already been
done in the past for the TA. <xref target="RFC8145"/> enables a resolver to advertise an
authoritative server via an EDNS option in the OPT RR which TA is used for the
DNSSEC validation. The RR is inserted when DNSKEY RRsets are requested.  In
addition, the resolver may also request the appropriated TA with a specific DNS
query. The RRsets are stored in the authoritative zone.</t>

<t><xref target="RFC8509"/> describes a sentinel mechanism where the resolver has a specific
behavior based on the left side label. This mechanism enable a user to evaluate
which KSK the resolver provisioned with.</t>

<t><xref target="RFC6975"/> describes how resolvers can indicate the supported cryptographic
primitives. These are advertised though EDNS0 options in OPT RR.</t>

</section>
<section anchor="filtering-semantics" title="Filtering semantics">

<t>Filtering can be enforced in various ways, and the resolver should be able to
provide some insight of the filtering policies in place. This document
considers various filtering policies that may be extended in the future. The
filtering policies are informative and are expected to provide a good
understanding to the DNS client of the status of the filtering policies. The
filtering policy enforced by the resolver may result in a combination of
various filtering policies.</t>

<figure><artwork><![CDATA[
Values   | Name         
------------------------
 0       | no_filetring 
 1       | undefined    
 2       | malware      
 3       | illegal      
 4       | child        
 200-255 | unassigned   
]]></artwork></figure>

<t><list style="hanging">
  <t hangText='no_filetring'>
  indicates no filtering is performed by the resolver. This policy is
incompatible with other policies.</t>
  <t hangText='undefined'>
  indicates a filtering policy but does not provide indications on the
policies. When used in combination of other filtering policies, it indicates
additional filtering policies are considered.</t>
  <t hangText='malware'>
  sites that are security risks or sources of malware, or that allow users to
circumvent policies.</t>
  <t hangText='illegal'>
  Users may be committing crimes or exposing the organization to legal
liability with these sites.</t>
  <t hangText='child'>
  sites that can be seen by kids.</t>
</list></t>

<t>source: 
https://campus.barracuda.com/product/campus/doc/5472264/web-use-categories
https://campus.barracuda.com/product/ContentShield/doc/77401148/how-to-configure-dns-filtering-policies/</t>

<t>Note that the client should consider information related to the filtering
policies enforced by the resolver cautiously and interpretation of the policies
will depend on the trust as well as additional knowledge of the resolver.
Typically, illegal categories result in the enforcement of the local
jurisdiction which could results in site not being blocked within other
jurisdictions.</t>

</section>
<section anchor="opt" title="DNS resolver advertising filtering status">

<t>The resolver MAY advertise its filtering policy to the DNS client using an OPT
RR in an EDNS0 option <xref target="RFC6891"/>. The variable part of the RDATA to define
filtering status is defined below:</t>

<figure><artwork><![CDATA[
0                       8                      16
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                  OPTION-CODE                  |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                                               |
/                   DATA                        /      
|                                               |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
]]></artwork></figure>

<t>and DATA defined as</t>

<figure><artwork><![CDATA[
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|                    LENGTH                     |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|   filtering_policy    |           ...         | 
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 
|                      ...                      /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
]]></artwork></figure>

<t>where:</t>

<t><list style="hanging">
  <t hangText='OPTION-CODE'>
  The EDNS0 option code assigned to filtering-policies (TBD1).</t>
  <t hangText='LENGTH'>
  The length in octets of the filtering policies, that is the number of
filtering policies that apply. When RDATA is used in conjunction of EDNS0,
LENGTH corresponds to teh OPTION-LENGTH field as defined in <xref target="RFC6891"/>.</t>
  <t hangText='filtering policies'>
  the list of filtering policies coded over one octet that apply. When RDATA is
used in conjunction of EDNS0, the filtering_policies corresponds to
OPTION-DATA.</t>
</list></t>

<t>The filtering status may be placed by the DNS resolver as an indication to the
DNS client. It is recommended the DNS resolve place the indication in the first
response it provides to the DNS client. When the DNS exchanges are protected by
TLS or DTLS, the OPT RR SHOULD be provided in the first DNS response provided
after the (D)TLS session establishment. When exchanges are not protected over
(D)TLS the resolver MAY insert it at regular time interval. The resolver could
also maintain a list of seen IP addresses, and provide the OPT RR anytime a new
IP address is noticed.</t>

<t>As EDNS0 is not protected by DNSSEC, it is RECOMMENDED to consider such
signaling when the exchanges are protected by (D)TLS.</t>

</section>
<section anchor="requesting-dns-resolver-filtering-status" title="Requesting DNS resolver filtering status">

<t>This section describes a mechanism that enables the DNS client to request the
resolver policies. Policies will be retrieve via a DNS exchange.</t>

<t>The DNS resolver is usually designated by an IP address rather than a name as
to get the IP address from a name would involve a DNS resolution. As a result,
the DNS client may not necessarily be configured with the associated name of
the resolver and a reverse resolution may be required to receive to get this
name. In the remaining of the section, the resolver is designated by example.com</t>

<t>The policies are indicated by the RRset with QTYPE=NULL, QCLASS=IN,
QNAME=_filtering_policies.example.com. The associated RDATA as defined in <xref target="opt"/>.</t>

<t>The resolver supporting this mechanisms is provisioned with the this record and
responds to the query. By this way, the DNS client is aware of the filtering
policies implemented. A resolver not supporting this mechanism will return an
error (NXDOMAIN) thus informing the DNS client that filtering policies are not
provided. The RRsets SHOULD be signed by DNSSEC.</t>

<t>The resolution service is often seen by the end user as a service that may
involve multiple parties. How the different parties collaborate is usually out
of the DNS client perspective. Typically the downstream point must ensure the
provided filtering policies reflects the filtering policies of the upstream
parties. In some cases discovery policies of the upstream resolvers might be
performed and the response may result in the aggregation of multiple RRSets.
At least any party MUST ensure the filtering policies responded reflects the
actual the enforced filtering policies. The entry point of a resolving service
SHOULD provide its corresponding _filtering_policies RRsets as well as RRsets
associated to upstream resolvers. These RRSets MAY be added in the additional
section or the resolver MAY built its filtering policies according to the
upstream filtering policies. If an upstream resolver does not provide filtering
policies, the resolver SHOULD include an undefined filtering p
policies.</t>

</section>
<section anchor="blocking-traffic-under-the-policy" title="Blocking traffic under the policy">

<t>When a resolution fails because of the filtering policy, the error code
returned can be Blocked, Censored or Filtered
<xref target="I-D.ietf-dnsop-extended-error"/>. When filtering policies are requested by
the DNS client - such a parental control for example - Filtered SHOULD be
returned. When blocking results from a legal enforcement Censored SHOULD be
returned. When bocking is performed by the operator's intelligence - such as
malware related traffic for example - Blocked SHOULD be returned.</t>

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

<t>Informative only! the DNS client can hardly check. sensitive to chain of resolvers.</t>

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

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

<t>IANA has assigned an EDNS0 option code for the filtering option in
the "DNS EDNS0 Option Codes (OPT)" registry as follows:</t>

<figure><artwork><![CDATA[
+-------+--------------------+----------+-----------+
| Value | Name               | Status   | Reference |
+-------+--------------------+----------+-----------+
| TBD1  | filtering-policies | Optional | RFC-TBD   |
+-------+--------------------+----------+-----------+
]]></artwork></figure>

<t>https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-14</t>

<t>DNS Filtering Policies</t>

<figure><artwork><![CDATA[
Values   | Name         | Description             |  Reference
--------------------------------------------------+-----------
 0       | no_filetring | no filtering performed  | RFC-TBD
 1       | undefined    | undefined filtering     | RFC-TBD
 2       | malware      | malware related traffic | RFC-TBD
 3       | illegal      | legal enforcement       | RFC-TBD
 4       | child        | unappropritaed for kids | RFC-TBD
 200-255 | unassigned   |                         | RFC-TBD
]]></artwork></figure>

<t>Underscored and Globally Scoped DNS Node Names</t>

<figure><artwork><![CDATA[
RR Type | _NODE NAME         | Reference 
--------+--------------------+----------
NULL    |_filetring_policies | RFC-TBD   
]]></artwork></figure>

</section>
<section anchor="acknowledgment" title="Acknowledgment">

</section>


  </middle>

  <back>

    <references title='Normative References'>

&RFC2119;
&RFC8174;
&RFC8145;
&RFC8509;
&RFC6975;
&RFC6891;


    </references>

    <references title='Informative References'>

&I-D.ietf-dnsop-extended-error;


    </references>



  </back>

<!-- ##markdown-source:
H4sIALqIZl4AA61aW3PbxhV+31+xsR9qT0RKcuVLNJNpaUlJNJFlW5Tb5smz
BJbkxiDAYheiGcv57f3O2QsAXtzGDcczJoG9nOt3bhoMBsIZV+hTOTazUhWm
nMla26q40/VfrJyawumaHi6rwmRGW6Emk1rfne54JSdr6eY67Rd5lZVqgbPz
Wk3dYDEr3EDl+cDGqwbpkEE8ZHB0JIRQtVancnRzK1azU4k94sPqVF6WWFxq
Nzin80Sm3Km0Lhciq3KccSobO1A2M0YszamQsp5mOrduTeytQbqUrso6X02Z
69LFB7aqXa2nNv1eL3o/XW2ytDirFgvsTW9NCX7SNWB8oZZLpomeCNW4eVUT
TfQZhP9pG044H8pXZqaawqXnXmznqjS62HpZ1Tj2AtRYW5XpKejTGvS9ePL8
qbytVWnlmSpVruRN1Tid1mXGraFtZUonr1RTg4sD+fasfV/luPpkLI9ePus8
bEpXY58/Mj3XC2UK6JcJHS48oX/XgbYhpARlDgYDqSagT2VOiNu5sSSghuQn
cz2F3KysSi0XOpvjILuAFSkndakmBV4peX49TkYFvUFq06pe+BciKwwdxFt2
2CQsCevlslCZlqrM5YoWwkxNDa7KDAYljR3K27kWVuNJ3qEj1zarzQTHzKtV
ICTcl6kSNP270dbhRaJuNdc4uxb/ByUySJfltjB5XmgI8aG8wW2m1mx28rpy
yhmoH/LU8oNey1VV51Y+ePVufPvgwP8vr1/z95uLt+8uby7O6fv4p9HVVfri
Vwj8eP3uKrynb+3Os9evXl1cn/vNeCo3Hr0a/YL/wI548PrN7eXr69HVA2LT
9dRMvENxE5IA5LKstdO5VDZJOJcvz97I4xPx6dM3Nz+cPTk+/u7zZ+l/vDh+
foIfEG3JN8FYinX4CfGtJVxNq5puVUUBWFgapwp7QOdbKK6U0IgekgyBIHWV
NxmJTn56CIUPDD36vM8uky3YrlF6UxhfnPXM0sMar9unf789j0i5cQhbIVax
tFaVzI11poTTtFTwEth5DbNr7bR1lS49KscXZ6xuaWDaOoQc4gpP0coAoRpo
qlxL/XFJ610y8GldLSLBwQH2eEzfaaNvVukkOsTCdBu4/LQXLYZi3GRz8gRr
cl2zdcuFWpPRNFbnByQ0hc3NpOUSOABq1WJZsH1ZXeiMeBAwibpa1kaRnbXy
hVexw6iJKYCDvL8vNGy7w/3SEjEeaDwpJNAuUysDW5vrYrnFa+du2Gk2r6AB
A59tyegT0REPyAlWBDlMzawJcugSModZqwIBMifZ6BJhttTe5aBpRerCMfTj
djRMLnTyFC703+yEBMeRyhC63EEKuqZFd0bhnbwgPqtloIivgM/Lmxs4o4G4
bkcAMFZWJEEEC79DuM+ZfG/A2IKViH64mIwPvkxC/PniF7yy2nlvCVLRORR3
CdLy3NARBz27YRuBu/dtrKd/0EXmTdaz1JmZmowjB1bX60hPutS6qsaewF9f
HL9B0sCRINOnR4RRbYzA8bAAwEbRcYgVe3SPYFZgIkVM9FzdGchrokhylb+4
0FMnyRNkoSaIrZLxadPRcA7EzVrUkHEDdoXXxc/jn/u3smFbiC84+5DiTGDl
2XfPn/ZYoXAXd1qOdciVDBIuz4ptlsuKNZfV66WrZrVa4lYBgS8MScrjlPVQ
luwrl4Qxszkb0lGwJDKDYEbkGA/lDwk6LdILCDRDAtU+JGImBGAwscwr6k7V
pgKirNTa+gjR4xwxoCly2sQic5VITl4tyHPgcnMX8WgHcseoHZQQg4SIWGUT
BTs2c9gIOKY/Oo2cM1nXtHFIwDyU7s0Yguff+aSBwfsjbIek38ErJWdVlYum
JHocVtJJeN9H7chkH4K3r95J0roV+kamz/zhB5I/jsKUHk9M6fGqmor94iGV
//777+IfMF5wLOW9vEbuG/NLToJ2foQ8CkvuZVm9x8na8clCHqcXJA2K4zkf
JZ+kFwtVrEiS/g751/QCoK5ngN/w4iS9yOamyBNV8snR0eDJ06d8h7KE2XwJ
85Ky47i6S584Ta5kQXhHJLCspa5J29sCDpYX1GCsQFpQLZYQMFk0g1tFeWdP
ron73p1qUwuwTMT9vGJ6XDKosIM91GOSaA//JwE2Az3U3Vd2IGRb1QcIgi0d
Cc0h7D2mH92L8F+IoDLwYo2LfsWArbOmpjhaG/vBcgitGlgpm3fYdSA5HtGO
ogC2EWhaQoLM1HDmO3KNxJ0QwQpw1zteGNyXij7jHKMQkE7zZXDGyrKzQV8o
zQDPv6WMwR9TmBjqWVOOkZG5wF1sWH2uAsRZBHcyhA8m57JAeL5OpZg7t7Sn
h4cZMp/GDieqRm3V5IoKrsOlz3DDy0Og1eHTk+dPnjw7OVzpyQCsD0gDM4Q1
qOF/OuqsQtZeuvEcVV7OJz5/fnJ0fHzy4hCRYuCqQUxX9CAv7Y6y/lAIlCza
80eSCngUsDmqupfo1LpQAeV6KJXscD8eZYjbhDjIvwg0U9GRjJRzpdjSoFQO
wW+pyxR+Xd1QYYeYovGOAnZrrh/KaoWUeaa3U9jb9RLmXRTrg4Qkraw7CEm7
AvGLDiwXFTaLX2HOFm7CtPponrGU/H6OR2Qt7K4TTbY3wc4PIbDjLbtg7xwC
BIng2iulY2CmE1ofDLHh00PE588+U007UO110kVKarfAZDvmNHyB4igvKPMr
YzIZc4CQpT578d3x588+I6OQweF6qeokn5vzEXI53OCBTWwRTdE5ID6Spmp1
6qPLkdz9ebH78fEz8e1g8Mf+ifvtc3xBPDh7fX6x/fL+z7nji597cbjjKQtx
zyes/4qb/jg3HCvJPZmgqDdlvc7+JOlcXVz/ePvTn0Yz3ZGs7n0weTqrc+5w
OGzvkH/8kr3S7x7c+xx+rfS5OoGTdCwVoYj8r+ee1BOUKc1xnawlAbx8dPvy
/PgxApqXeDim0OXMUSEtK2Ss7gsp54GPDcby+7JZTIA3yB33pdSo8Ip1yEQ8
LsTak1OS8temzCLaMzMHgTK8rAFoy6rMLaOVnkdPDQumFOZ8d8rbpNlEKLGD
LHDMGG4s49UOukmMiDAEpFSys0T2MyO+yExfiu87d3SZi4qlIzmFELc94QfY
DPkNFznd5lQnVFjZFoEhuQn1fWoIXbL2au1747nON48JvU962jkp1kLU0xKe
do4tMRO12yElSCo+1B+pKp6FtBHbnC+PJmtxezWmJO0c/x90GxahzTnR8Za8
R0ek2tMSlwg1ddq3Vh6dP6ajrbZUUksNQU6g+fmipa5PVUitA2VkAyKc4TYD
rG+LkAQUteBmTaFwqVmE5inqfB8i22yHsgPBPZAF9fUV12DREDmNvHxDGQx2
WB1K5Jjnd4SiyjVfo2SpV6LdQmoF/SbzmfjIBnQwdoMtWI5v+Phc33abxaTF
lOZRd02kMZDv/3BOtFeTQeK+RXDjOz20tWelm4YdurqoENjSuq2aPcOGjdSl
37kUbTMlVUJvouNxEjkhraDO0zB2bpr17HMY2489ohm2GkoaiUCSSeBYddUm
a8V1Fagl5dKAiEIlCJxpn1F31nK/Nixacepoyjv2wM4wpfHtuFFoByKzPBAb
7BMukIZLjXLKIiMrQh0Ukv08FTQUHarMt9v4WiB3z7C5d4Gf1FDSHQIi9tR+
upF7kWea+h2JOYAhHQqIKYO7kJ2TnmM/w2t4ozPI2WBXoqFVTLVN0MRGr8UX
pwkCuS3oeXx7+8ubi++v311d0bTsajQef395fSDeXo9eXXz/fhuIh527vLt2
JOQhfjPAUL79ebiRcYdWmy8wTW8gQQ2Bjaaer13mAYbrnAczvWCH96Hv+XLt
V67U+mDT7vFYcYNkM1y3tZch7gjuCBRGLcFkL3uJ9l4CF2lqKgKErmug86Pr
f52/fjW6vH6M5ZTFcxEYa+quO35hyId7Y18v7zV1W6gP+UtCqdiI71gjNbyB
cySACmBfpiLcV2y5b7f6Bm5YGht8IvrYAq5klqF0YZD4qVrxAbmZTnXNzQb/
Cq5UFGpS1dRZ7QBB1TgRRN9hfwnfoc4ffAMcxlLTn1ytSpoAqwWkQqPdBdWv
urSN7z4n0ewSX62nNDex+/qfgZJm6W8QiS+4I7dQM4WwQuOqjALbeu/OTk95
wT3XCQhLPa9O49bH3X5XkVFmNkNATFV8kvTNzRiqHoqRQ8ZJIxAaYxGZa8mD
0FYQu/lnB+FJUSsJoTLX8Dyv023e0yrFAsd8G1/MxwGL72KznYhgh6m/5rrJ
Gi3cgSJpMNE2IvwT0UETuPW2gGMD3kuG8wpqgOedTKdtaYgYIcPgqJeOTBpD
Ctiu9dnzMoKZttcsEiW7JHU5paC2Rex283EbbzagPQjTlFnRUG1Sdnq9nZs7
LUtOHF5Sn4SprdWU5kDcL2+7QWus4uRNdUFhqkxhIb5Mwfv3VDABQz2gUaIv
PMrRjMS38176Hs2BPIM18owJK/1cA6nlp09/uxycD412U2qhVctBHBYM+Eyq
OpiyPfCXZmWU9W7gxsBPMxV5BH776aKrq6I3Px0kYlrITEyEyydRfrEVFTIN
3+rqdrQSk/vPCkft6ntXS5oAV/QnSJTzFoWZ6TLTiRMb28FtkzAotM9RkHkn
BrREcJue/7JiHDvIZ93hM7LHy87whf7o4JtNRCbVzlWd85xXZx+GNAK0PALj
fHdOqTgMpnVLuu9Nbe5Utn3dQ3k5uh71R+B4LPgpTw1jCb7ZP+MCPY59WwtJ
s1q2iAdEuN/22r84q6i8eoT0//EDqjRQMQDFcNG0oja5PU2tGP58u2sQ8+3O
r9wq4aHO5kQn9kXGvvSkrzeaoyL0e//Vd1H3gc7a0Zm4D+zCQnHXD2cDrI3t
n6+4ixsnsW2+Wq2GRpVqWNWzQ68e/gOdQ2qDw93AOcjZ/Dn8OHeL4mH/4eD4
RHA93c46Y3Hx5RnZvTznwsbrtC/lVrZ7J2n7P12+987b7vtTrNaVW2HvHcnd
70Rt/ybt3TO1a39uQkBn757B3v0OwJKb9+6Z/fHEL/x1gVPhTx1oRNOjefd4
cH9Xtd3L5vWOx7gZAyilRT8W1YRzvXEGaMwZgq7J58kQgnmggEdOSP72/po6
zlSZdM9PTiZ26XeX0gWVO7y71ff7jlu1vuSpBoCNsjgd4Qm5EP8Bw3gbAGIq
AAA=

-->

</rfc>

