draft-sahib-451-new-protocol-elements-00.xml

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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?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 text-list-symbols="-o*+"?>

<rfc ipr="trust200902" docName="draft-sahib-451-new-protocol-elements-00" category="info">

  <front>
    <title abbrev="New elements for HTTP 451">New protocol elements for HTTP Status Code 451</title>

    <author initials="S.K." surname="Sahib" fullname="Shivan Kaul Sahib">
      <organization></organization>
      <address>
        <email>shivankaulsahib@gmail.com</email>
      </address>
    </author>

    <date year="2018" month="March" day="19"/>

    
    <workgroup>Network Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This draft recommends protocol updates to Hypertext Transfer Protocol (HTTP) status
code 451 (defined by RFC7725) based on an examination of how the new status code is being used by parties involved in denial of Internet resources because of legal demands. Also included is an analysis of HTTP 451 from a human rights perspective using guidelines from RFC8280.</t>

<t>Discussion of this draft is at <eref target="https://www.irtf.org/mailman/listinfo/hrpc">https://www.irtf.org/mailman/listinfo/hrpc</eref> and <eref target="https://lists.ghserv.net/mailman/listinfo/statuscode451">https://lists.ghserv.net/mailman/listinfo/statuscode451</eref>.</t>



    </abstract>


  </front>

  <middle>


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

<t><xref target="RFC7725"/> was standardized by the IETF in February 2016. It defined HTTP status code 451 - to be used when a “a server operator has received a legal demand to deny access to a resource or to a set of resources”.</t>

<t>Subsequently, an effort was made to investigate usage of HTTP 451 and evaluate if it fulfills its mandate of providing “transparency in circumstances where issues of law or public policy affect server operations” <xref target="IMPL_REPORT_DRAFT"/>. This draft attempts to explicate the protocol recommendations arising out of that investigation.</t>

</section>
<section anchor="requirements" title="Requirements">

<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>

</section>
<section anchor="existing-protocol-elements" title="Existing Protocol Elements">

<t>The status code as standardized by the IETF specifies the following elements <xref target="RFC7725"/> -</t>

<t><list style="symbols">
  <t>A server can return status code 451 to indicate that it is denying access to a resource or multiple resources on account of a legal demand.</t>
  <t>Responses using the status code SHOULD include an explanation in the response body of the details of the legal demand.</t>
  <t>Responses SHOULD include a “Link” HTTP header field <xref target="RFC8288"/> whose value is a URI reference <xref target="RFC3986"/> identifying itself.  The “Link” header field MUST have a “rel” parameter whose value is “blocked-by”. The intent is that the header be used to identify the entity actually implementing blockage, not any other entity mandating it.</t>
</list></t>

</section>
<section anchor="recommendations" title="Recommendations">

<t><list style="symbols">
  <t>In addition to the “blocked-by” header, an HTTP response with status code 451 SHOULD include another “Link” HTTP header field which has a “rel” parameter whose value is “blocking-authority”. It’s important to distinguish between the implementer of the block, and the authority that mandated the block in the first place. This is because these two organizations might not be the same - a government (the blocking authority) could force an Internet Service Provider (the implementer of the block) to deny access to a certain resource. <xref target="IMPL_REPORT_DRAFT"/> notes that  there is confusion amongst implementors of <xref target="RFC7725"/> about the meaning of the term “blocked-by”, perhaps in part because of the example given <xref target="ERRATA_ID-5181"/> - it would be useful to explicitly include space for both, as both provide essential information about the legal block.</t>
  <t>HTTP status code 451 is increasingly being used to deny access to resources based on geographical IP. The response SHOULD contain a provisional header with geographical scope of block. This scope SHOULD correspond to alpha-2 country code defined in <xref target="ISO.3166-1"/>. The rationale for keeping the geographical scope to country-level granularity is that most blocks are mandated by national governments <xref target="IMPL_REPORT_DRAFT"/>. In addition, as the serving of this status code is voluntary, there is value in not complicating the specification.</t>
</list></t>

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

<t>This document does not add additional security considerations to <xref target="RFC7725"/>.</t>

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

<t>The Link Relation Type Registry should be updated with the following entry:</t>

<t><list style="symbols">
  <t>Relation Name: blocking-authority</t>
  <t>Description: Identifies the authority that has issued the block.</t>
  <t>Reference: this document</t>
</list></t>

<t>In addition, IANA should be updated with the following provisional header:</t>

<t><list style="symbols">
  <t>Header field name: geo-scope-block</t>
  <t>Applicable protocol: http</t>
  <t>Status: provisional</t>
  <t>Specification document(s): this document</t>
</list></t>

</section>
<section anchor="human-rights-considerations" title="Human Rights Considerations">

<t>The use of HTTP 451 has implications for human rights, and is thus worth examining under the guidelines for developing human rights considerations for protocols <xref target="RFC8280"/>.</t>

<section anchor="connectivity" title="Connectivity">

<t>HTTP 451 status code response can be sent by the server hosting the blocked resource (end node) or an intermediary node that implements the block. If a resource is “blocked-by” a particular ISP then the ISP will be the one serving the status code.</t>

</section>
<section anchor="privacy" title="Privacy">

<t>HTTP 451 is used as a response when the client requests a resource that’s unavailable because of legal reasons. Consequentially, there are potential privacy (and anonymity) ramifications if there is leakage of who accessed what resource.</t>

<t>HTTP status code 451 is cacheable by default <xref target="RFC7725"/>. Caching status code 451 on users’ devices means that there will be a record of their attempt to access the blocked content stored on their devices. If caching is used, the software used to access the web resource should notify users that the HTTP 451 response has been received and cached.</t>

</section>
<section anchor="content-agnosticism" title="Content Agnosticism">

<t>The scope of the blocking order may be geographical in nature. This results in an issue related to content agnosticism. This is not a protocol issue, but rather an artefact of the blocking order.</t>

</section>
<section anchor="security" title="Security">

<t>Refer to section 5, Security Considerations, of <xref target="RFC7725"/>.</t>

</section>
<section anchor="internationalization" title="Internationalization">

<t><xref target="RFC7725"/> does not require the use of any particular language for user-facing strings such as the response body or the value of the header fields. The header field names, however, are in English. This is a common attribute of protocol elements within the IETF <xref target="RFC2277"/>.</t>

</section>
<section anchor="censorship-resistance" title="Censorship Resistance">

<t>While HTTP 451 status code cannot prevent censorship, it can help make censorship more transparent and make assessment of Internet censorship cases easier by providing information about the block in a parseable manner.</t>

</section>
<section anchor="open-standards" title="Open Standards">

<t><xref target="RFC7725"/> is an open standard.</t>

</section>
<section anchor="heterogeneity-support" title="Heterogeneity Support">

<t>An HTTP 451 status code response can be used for any web resource and for any software that is capable of understanding HTTP header responses.</t>

</section>
<section anchor="anonymity" title="Anonymity">

<t>HTTP 451 is an HTTP status code. If the connection between the client and the server is not over HTTPS, then there is potential for a network observer to identify what a particular user is accessing. Even with HTTPS, meta-data might be available that could be used to identify a user.</t>

</section>
<section anchor="pseudonymity" title="Pseudonymity">

<t>HTTP 451 does not involve pseudonyms or nicknames.</t>

</section>
<section anchor="accessibility" title="Accessibility">

<t>HTTP 451, being an HTTP status code, does not prescribe how the client should parse the information contained in the response fields. Depending on the software that is used to access the resource, there could be accessibility concerns related to understanding this information.</t>

</section>
<section anchor="localization" title="Localization">

<t>The values of the header fields and the response body can be localized by the blocker to suit the geographical scope of the block.</t>

</section>
<section anchor="decentralization" title="Decentralization">

<t>HTTP 451 is used to provide information about a block mandated by a (centralized) blocking authority. The status code itself does not add any additional centralization.</t>

</section>
<section anchor="reliability" title="Reliability">

<t>HTTP 451 does not by itself prevent the misuse of the status code or wrong tagging of resources. The informational requirement as part of the protocol address this concern to some extent, but commonly it will be difficult for the end user to verify if the code has been correctly used. Objective of this draft is to increase reliability by making it clearer what a good HTTP 451 response looks like.</t>

</section>
<section anchor="confidentiality" title="Confidentiality">

<t>HTTP 451 status code use implies sharing of information by the reporter that make it easier to identify where censorship is taking place. See section on Privacy and Anonymity.</t>

</section>
<section anchor="integrity" title="Integrity">

<t>HTTP 451 does not prescribe the use of any encryption to transport it, and is thus susceptible to leakage through man-in-the-middle attacks.</t>

</section>
<section anchor="authenticity" title="Authenticity">

<t>Authenticity of the server implementing HTTP 451 is dependent on the connection being over HTTPS.</t>

</section>
<section anchor="adaptability" title="Adaptability">

<t>HTTP 451 does not have any legal or technical limitations which prevents the development of other standards / protocols.</t>

</section>
<section anchor="outcome-transparency" title="Outcome Transparency">

<t>The assumption behind the development of the status code 451 is that transparency has a chilling effect on censorship and that transparency will enable the process of justice by allowing acts of censorship to be challenged. In some countries, blocks orders are unevenly implemented by ISPs either because it does not serve their bottom-lines or they are resisting censorship - governments in those countries could mandate the implementation of status code 451 which will make it easier for them to monitor the implementation of their block orders. Surveillance systems in some countries could be updated to watch out for the 451 error code on unencrypted traffic making it easier to identify those trying to access prohibited content. Before the implementation of this standard there would be no uniformity in which websites would implement a block order increasing the number of false positives for any automated monitoring systems.</t>

</section>
</section>


  </middle>

  <back>

    <references title='Normative References'>

<reference anchor="ERRATA_ID-5181" target="https://www.rfc-editor.org/errata/eid5181">
  <front>
    <title>[Technical Errata Reported] RFC7725 (5181)</title>
    <author initials="S." surname="Bortzmeyer">
      <organization></organization>
    </author>
    <date year="2017"/>
  </front>
</reference>
<reference anchor="ISO.3166-1" >
  <front>
    <title>Codes for the representation of names of countries and their subdivisions - Part 1: Country code</title>
    <author >
      <organization>International Organization for Standardization</organization>
    </author>
    <date year="1997"/>
  </front>
  <seriesInfo name="ISO Standard 3166- 1:1997" value=""/>
</reference>




<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author 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>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor="RFC8280" target='https://www.rfc-editor.org/info/rfc8280'>
<front>
<title>Research into Human Rights Protocol Considerations</title>
<author initials='N.' surname='ten Oever' fullname='N. ten Oever'><organization /></author>
<author initials='C.' surname='Cath' fullname='C. Cath'><organization /></author>
<date year='2017' month='October' />
<abstract><t>This document aims to propose guidelines for human rights considerations, similar to the work done on the guidelines for privacy considerations (RFC 6973).  The other parts of this document explain the background of the guidelines and how they were developed.</t><t>This document is the first milestone in a longer-term research effort.  It has been reviewed by the Human Rights Protocol Considerations (HRPC) Research Group and also by individuals from outside the research group.</t></abstract>
</front>
<seriesInfo name='RFC' value='8280'/>
<seriesInfo name='DOI' value='10.17487/RFC8280'/>
</reference>



<reference  anchor="RFC2277" target='https://www.rfc-editor.org/info/rfc2277'>
<front>
<title>IETF Policy on Character Sets and Languages</title>
<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'><organization /></author>
<date year='1998' month='January' />
<abstract><t>This document is the current policies being applied by the Internet Engineering Steering Group (IESG) towards the standardization efforts in the Internet Engineering Task Force (IETF) in order to help Internet protocols fulfill these requirements.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
</front>
<seriesInfo name='BCP' value='18'/>
<seriesInfo name='RFC' value='2277'/>
<seriesInfo name='DOI' value='10.17487/RFC2277'/>
</reference>



<reference  anchor="RFC7725" target='https://www.rfc-editor.org/info/rfc7725'>
<front>
<title>An HTTP Status Code to Report Legal Obstacles</title>
<author initials='T.' surname='Bray' fullname='T. Bray'><organization /></author>
<date year='2016' month='February' />
<abstract><t>This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands.</t></abstract>
</front>
<seriesInfo name='RFC' value='7725'/>
<seriesInfo name='DOI' value='10.17487/RFC7725'/>
</reference>


<reference anchor="IMPL_REPORT_DRAFT" target="https://tools.ietf.org/html/draft-451-imp-report-00">
  <front>
    <title>Implementation Report for HTTP Status Code 451</title>
    <author initials="S." surname="Abraham">
      <organization></organization>
    </author>
    <author initials="MP." surname="Canales">
      <organization></organization>
    </author>
    <author initials="J." surname="Hall">
      <organization></organization>
    </author>
    <author initials="O." surname="Khrustaleva">
      <organization></organization>
    </author>
    <author initials="N." surname="ten Oever">
      <organization></organization>
    </author>
    <author initials="C." surname="Runnegar">
      <organization></organization>
    </author>
    <author initials="S.K." surname="Sahib">
      <organization></organization>
    </author>
    <date year="2017"/>
  </front>
</reference>




<reference  anchor="RFC3986" target='https://www.rfc-editor.org/info/rfc3986'>
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='T. Berners-Lee'><organization /></author>
<author initials='R.' surname='Fielding' fullname='R. Fielding'><organization /></author>
<author initials='L.' surname='Masinter' fullname='L. Masinter'><organization /></author>
<date year='2005' month='January' />
<abstract><t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource.  This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet.  The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier.  This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='66'/>
<seriesInfo name='RFC' value='3986'/>
<seriesInfo name='DOI' value='10.17487/RFC3986'/>
</reference>



<reference  anchor="RFC8288" target='https://www.rfc-editor.org/info/rfc8288'>
<front>
<title>Web Linking</title>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'><organization /></author>
<date year='2017' month='October' />
<abstract><t>This specification defines a model for the relationships between resources on the Web (&quot;links&quot;) and the type of those relationships (&quot;link relation types&quot;).</t><t>It also defines the serialisation of such links in HTTP headers with the Link header field.</t></abstract>
</front>
<seriesInfo name='RFC' value='8288'/>
<seriesInfo name='DOI' value='10.17487/RFC8288'/>
</reference>




    </references>




  </back>

<!-- ##markdown-source:
H4sIAEGur1oAA5VabW/jSHL+rl/R0X44TyJqbG92Z8Y4LOIbezPKzowd24tD
EASLFtkS+0yymW7SWt1i/3ueqn4hKcmLCzDwSGSzu16feqqoLMtmne4qdSW+
qp1orelMbiqhKlWrpnNiY6z49PR0Lx472fVOfDSFEv/63cVMrtdWvfjHjlfT
isLkjayxc2HlpsucLPU6w42sUbssnpTFZ7Pz81khOyy/PL94n51/m118mOW4
sDV2fyV0szGz2Z//KcuEtEpeidXD048iy36Y6dZeic72rrs8P/9wfjnbGfu8
taZvSbiOvom/4o9utuLf6fLsWe1xtcAeTadso7rshiSczVwnm+IXWZkGYuyV
m7X6SsyEsJtcFa7bV+GyEJB99FE3BVSIF5yxnVUbl77v68nXzuo8Lc5NzerH
77qpdDMco37tsko7WG9fr02FZZn553+ZzWTflcZezTIsEvQU7jwuf1qKR7Ky
v+iN/1jqF9mIn2RfjW+qWurqSji++4yb7J5/29LlJYSazRpja9npF3U1wyO3
Dw/XT9e/rG6y7y7eX1zxJiFw5v/9pPKy0bmsxK21spPiQbUwgir+Rzz8+PHd
u8vvxBk99mbOzyU3v+OvUReWS2RRGfEXbPH3Wu2V9adJu1WwW9l1rbt6+3a3
2y3hmEwVujN2aez2reLT3ypd0Gkk9urxbvntxfffZwciUxj7cO1KJaxqrXJw
A/Q1jTAbtp2jD7npGzgMXxAatFhb4fp1oV+0w1oHee+l7cTFFVKDlu7xSKHG
il58+HBaUYgcY5APhv3u7FY2+u9eDhLvkUJS2iJc42edIoEoI+JeUDOtFKwv
BOJzsQAuuLy4+HAVPr+/fH8eP19evnsXP5Ob+PPqy/3nXx5u7+8enn65ebj+
8WlqulXd+pT1QnpXv4oT/y+PX6+tLGU9vf7lfik+ShiHM2J04z+W4pOsqunF
u6X4qSQwwPoXOb33dYmEasSdegkhle58XIqHvmnUVtpDoSY5dRiDnUFOLrXq
Nhx/ZVdXbz3aEc7pus0sm4fALZj52w/vv/eaD/54Hy+QT8dZh0sZId4aoCFz
INRTqZ3HUwStx47CDbDdt2RpB0wSn/atsoQf4snKxm2UFfdx2Rl56g2QiFw1
y4OrxFmhNgCfQqz3MSDeiLV0uAJHA0TUr7LWTUqS0uw4fYDnYS+OfQER14rg
tnd+sxYZQimkmxdTveCabgQQUyPgsU1EYWjkTG9zRY/nEg/T3QpOqbC6RnQ7
hEjlDB7Pq76gfSgtBQXH3mnO11h9xMaaWkhR9nhQWL0tUZ5gEdeqnMwL2UjC
ba8LRYjr/AMhP5az2Y12ee9cULUb7E5nduLPYxjSNgQAoSfOe0uQTb58W9o2
/4GhIz1A99xyWyKLX5ZQ+/ghb0syJRT5AbJwENS6KCqFL9+Qxawp+pwRYfbb
b8FZv/8udtIJlyDDW59ctLpFtYTVf1Rr20uAFHLx+6VYdSL6nA039iIZMaNI
WivvyF2J5JFiLgmAkELCwJ4S2CtKnIpwVJp8Kycuow3g6r2QORzLkSmTowXh
L11w8D6snAJgDqUf+7VT/9sDaKr9gqNvsyGkIRVrCQE7CoQXBaNtEfSQUW7V
JAToeIBA1dNtvREaMNVXG11VCMWOdmkoXegZZNCLLigi5h2lCyJWNfmeTJZr
m/c1GZUiE0awFOGu9/WhkjvSou3Xlc5Fa/AXum42iLKpmahYzMVvvx2h6++/
L8UorWXXqbrt2FLq1xb7kYjkw5TlKfP9riBEmoPZ9J2PVcTnYBksWXLUPMCa
2nq2RUiiBIiQICbkxPzLz49P84X/X3y9488Pt//58+rh9oY+P366/vw5fYgr
Hj/d/fz5Zvg0PPnx7suX2683/uEv1/81X7A75nf3T6u7r9ef52Ran1UG5oVM
xOtCuGlCBJTkjsIJK5TLrV573OBop3oGu7Fat79y3mwHeLutxkqOY/qPsoOQ
QW8IpujSxlSV2dG2idyO8yxDTorr6OGcIEZ1vW2OMoiDtIhOJMcwglBK0Oav
ZUXdV51GnR1hIkFwznSEnDzNsiWkeVCuRTRgpYe27kD34KGAnR7O20oGOGdv
8HG8iVibYu+DSeGMDhDl4tfXDz48Qsw/6+Z57jOyVEhaK2DhqvC2pMpHmFUa
HEh5yqVDip8fVhAEFQspqPxSqppYqoln6w2bDhmsqs1SCHJyOGhyBodyKV9Y
EKuqOdUh8DrE1uGZ83Vl8mdVZOv9fMkbUgg27Cr2GukdNo9wSJ4N4vBt+tgR
znU9WAmgI/IkEpb3Bz4tRGMQ6cBDg2dsfMgjkdcqJuskxyncVgiAAmSX3IXD
6cyx3EE+hko2ePLlTnflUWAehYMX6FWP7Uqdl4z0/6A1oU3miR40nFOt+ZMj
owDDJSxLdcEnbq9dCat2O6V8ECbLEXj6mOMdF5GDi7Sv904A8mJYGuN5o63r
BMI8VwFl9cAusID+7gwx8US7UReILbCj1h55HfRELZRia5DuDaPVWTqL8zgK
9IY6BpgLpSrnJEvs5hFYoXHtnksNVDv7I13fnCycOSid1E1CheXpgkKyqxC5
tCVXLAjWbHomNLI2zRZ2SYcby9k9Rji5pnJC8tQKtqHy4sWDpPUk8BbEq0rZ
Er9jqjemb5wZoI2EZVvwAwLwaS9JaEqouGO7+exCmR7qH/qOfYpTVOZccbex
RsAuCNHpQyjgOMtRH0fMMnFpUjgp48GLpSfsOsl6KEqa3CpJOIqzR2T22Ckj
0hqZ8laZrZVtyR3x6t4DSsrGkHjwBrtSetGd7/9CynHGTrYBHWzZoF50H8v+
YtrQ+jNYSlm1pcwuQ//qm9LE9biMDq2xZyAQMXSh3r7PSrWxjpwQBWeEvTN0
WqoSWND0leSsjLBZG0QZS+y4vKdEReFNPe+QVO41fjSCPnY5JyXlUwxL7Q47
EHQakA5UdzFkQECohnMb+OrZVSqWngDkkTJ9g5TNe9bnIzxHORvB+GlCXAoD
7zOuF0WSkwwVH88nj5PpRpnGJ62uv16fOEUJgmMUg8rH8ROaOnzbAjjhU1em
lGm9WTluDugLuehqxnU67PKVB0PHII01N0y1Wlp2JVa+vEVKdAC6VAqYB49g
19OBULmvpvxuNpt4kTX+hzQ4zg9W59O4OvlZF8I04+jMWBqiaC37eF0N9Nl3
77jnJxVX4/3p6jgKkvBn7s2ROt+IT9xcPvjm8pT3AgimjoRtFsOOQoESbdyi
+hLH6YNYBjeHNXzXzRDUkMackKO+FVsUlIGG03XS8B4EHi2NZnCJg51ThhHp
+IZ0aLg/pmiYJbHHqZVwjEjvmtIQGRB4dKDDYAMpqUKdGMjtGTgNkqVQb4jn
ysaT/VoVmtpSuhF4cqxNbhReYrUZE+UD5kZYSpOGnGBIrB7v6UnPA+jLDo1f
rOimGQDkgChHW9xb/SLzsRm080WAOdDAruIZeaXJFpaaVrT4Y0FJI7CfvpEv
YNIcjkcjDqo32HDJgeQbX01EMuIX4WdrulDdWi+dOKN4AXlr9jWzD1CyFL2O
mt4EfpWSz6FDBl8LFYzbetmNCEXQ90RNzGWO9GPZ91RKJHqUCZCJj1hBFj18
GIkEVa37EwWqplpJnGKg1lYl50jubm0RuIO2sSHmohaq7iiuqIyS1R04jK++
/qlwEEdMHsQK/lt4j5tNtyObxro+2nyn1oPvAkYB34npsx5DT5BiI4UDpfia
mOwwEIGH2HbFMmUZy3y9bShTcu3q0KrGIj/hlrAGkqqWRESmlZgqGSxtI7eF
EPAJ8zBKLAJnXKs8NTbJVnI4dyDFXL+GGQM/vBBr0CagB3UGNGizHdyed6dF
DNrFojmbcSWgg53iUZX4bvFaSV0c0M+w12Q4Hkfgk4FXqr3WTzdYrpBX1GaN
AAG97ranDCAYJD9m0MWHq8V/YBA9OpzALg4aYY+6nj8E5cfdkfMEqjwsSdCr
NDuaNy84f+GYW1BKNDyD4SW/AyKS2kEOGDwOpA7exFFlDF0Nzyv8IOTy3bsR
fKvGgcqXuqWmXPuZ1Wz211JXo1AdZydAnIzXWsiIyMjTBgui5ATxpapaBN+z
Gt0EryNLp0FZxzHOiyQwxTmmRePR7ujZXNKogMg1NdP70ejtNGNP/Ryju/MI
hBrXpIi7a5Fu8fWHm8aHnxAbWhEnP+GpT9S6mq1qFIXjY99SZzqbXTenLXVY
9xg2NlzC9lPAIFvEGwllfE0jEG1ZARiHqzkLRcqPO+54lguiXkd8nxaj2OhP
itfKR2ceKrlpJq11qFGxjw4FO6Q/8XDe8XGRKqevHUPdYcVEE96rmnXYYTwM
4YIyKcWUbCwwQyy0XYpbagWZ7IUDa9XJrKCXh779plqQiiVbLx81iNPxi+QT
grHuneqLY3sloAgvIUQb1zlK70bnz5yx0eRe1LWuJtssQjN4wvSL4Qh6m8gT
y/SKJNg91BKOYz/qGIV86Ah9fzbBoIgxNwpxzNHi69xxeJ0oZjEuI49IZpRj
Fen0HLnqxgVjGqFMf0cCB0t9NvkIm58iTLqTOJkib4qvIacqv9UwmPVV3teQ
Xnev9aLjchSx8AblF63PSLQjHodd49jgGHpkAJ5xyyrFWdpUFW9OjH98HZi0
ojymPOgRaYIw9IlTQaMCaNe0PIy/YR+IE7aO4M2zGu1Gg5exHIjxnTXkRrnd
hr45zS7izDMZgfloel1ARZEHO2HfVJyghPVx5udLFEHsLFPT2IdAw3MIX+Jo
jtMlqlfozYYAokvv4ak1YKzAFkAVSm0d4awYUSsedeQ0FiI/LsXd+m/hrd7R
qzqev/Msh6lQtCiZD/XKT1yRnQpJZCNybY0pTjC7yphn0Gj9rAYet/EYJKvX
GybyB/d8cJwrpQ22H0dciHb/rpg7PB5qPlP0xEo5RVhO5KGmkqJemzDqfFQq
sS78C70MZ18qJiOOtbWvRNmAZAe8Cg2+3bdpFs1UgN7O6W7awiIcc4V1jOIm
NSFdaU2/LSm7Mt1k2Dzz7zeJBcn8OcFwT4WIuCrJN/6WYjyUsPG0fZzpBWMm
85HmuDKyM1LZi4cWsu3+IPX8OwUYwTduFLzpBzCVhmlD9+VH5iE9XXiVwo16
5Ed+5h6JiRNvh/Y8cpu+yymZnkZvJT3Kgmn1dRv0ADMsTh1wiALBKL5/Gb/o
9IN99ElVxVMj/waTqtIQZR67D5/kdFZNqNMMDlx7cPrfemozuF+UcZqD9sH/
sGbY17/0y0usUc2WEnrVeAhJv75ZxCkidxp+mNg3ZNjxmxaP0uj1wS81mzZ2
2Xo0peOICW3i2nSdqTM/SfEotOfNLfNnEngkaDaZVXKVphcfw2+EfG2N75Un
8/30q4lDd/goYSsepHyAxZoMBPSknzm9smdQhguWtxAgoIea2JV6AOH2Dl00
yzw17IhVhQkcDtvJDiJRFYzITIIqa/HNF5OGrO8hgB4B2gLKR4h6ArS8rTrL
L+8GioJwKcFBuqGXX4q/qI2xr9kvDnv9j53C9CAq0RBp0YSsPIZuonXV2ml6
JeIXpk1Tlfc99jD1979r6eu1fy2zkZWj6Qs2QZVxid6j7puarRb8w+2kt/Vy
9n/z7DNSXSkAAA==

-->

</rfc>