<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.34 (Ruby 2.6.10) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

]>


<rfc ipr="trust200902" docName="draft-lear-bcp83-replacement-00" category="bcp" consensus="true" submissionType="IETF" obsoletes="rfc3683" updates="rfc9245, rfc3934" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="IETF Lists">IETF Plenary List Management Procedures</title>

    <author initials="E." surname="Lear" fullname="Eliot Lear">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street>Richtistrasse 7</street>
          <city>Wallisellen</city>
          <code>CH-8304</code>
          <country>Switzerland</country>
        </postal>
        <phone>+41 44 878 9200</phone>
        <email>lear@lear.ch</email>
      </address>
    </author>
    <author initials="R." surname="Wilton" fullname="Robert Wilton">
      <organization>Cisco Systems</organization>
      <address>
        <email>rwilton@cisco.com</email>
      </address>
    </author>
    <author initials="B." surname="Gondwana" fullname="Bron Gondwana">
      <organization>Fastmail Pty Ltd</organization>
      <address>
        <postal>
          <street>Level 2, 114 William Street</street>
          <code>3000</code>
          <country>Australia</country>
        </postal>
        <phone>+61 457 416 436</phone>
        <email>brong@fastmailteam.com</email>
      </address>
    </author>
    <author initials="J." surname="Levine" fullname="John Levine">
      <organization>Standcore LLC</organization>
      <address>
        <phone>+1 607 330 5711</phone>
        <email>standards@standcore.com</email>
      </address>
    </author>

    <date year="2024" month="June" day="19"/>

    
    
    <keyword>Internet-Draft</keyword>

    <abstract>


<?line 52?>

<t>This memo provides a procedure and authority to address inappropriate
behavior on IETF plenary lists.  It obsoletes RFC 3683 and
updates RFC 9245.</t>



    </abstract>



  </front>

  <middle>


<?line 59?>

<section anchor="introduction"><name>Introduction</name>

<t>The charter for the IETF discussion list is layed out in <xref target="RFC9245"/>.
Individuals are expected to behave at all times in a professional
manner for the purposes of the organization, as specified in
<xref target="RFC3935"/>, and for the purposes of individual mailing lists.</t>

<t>Thankfully the need to take action against individuals is relatively
rare. Experience has shown that when the existing procedure is invoked,
the procedure itself causes as many problems as it solves, including:</t>

<t><list style="symbols">
  <t>Community discussion drawing away from the fundamental mission of the
organization;</t>
  <t>Humiliation the individual who has behaved inappropriately;</t>
  <t>The need for a committee draws scarce volunteer resources from
other potentially more fruitful activities;</t>
  <t>Consumption of IESG resources.</t>
</list></t>

<section anchor="goals"><name>Goals</name>

<t>For these reasons, a new approach that aligns with other professional
bodies is specified. The goals of the approach address the problems
above as follows:</t>

<t><list style="symbols">
  <t>Minimize inappropriate behavior.</t>
  <t>Maximize appropriate participation in IETF activities.</t>
  <t>Minimize volunteer resources necessary to address inappropriate
behavior.</t>
  <t>Allow for approaches that are tailored to each situation.</t>
  <t>Limit humiliation of those who have offended.</t>
  <t>Provide a right of appeal.</t>
  <t>Provide for transparency.</t>
</list></t>

</section>
<section anchor="summary-of-changes"><name>Summary of changes</name>

<t>The following changes are made to IETF policy:</t>

<t><list style="symbols">
  <t><xref target="RFC3686"/> and all processes therein are obsoleted by the new process
that vests authority in the executive director.</t>
  <t>Only the moderation function in Section 3 of <xref target="RFC9245"/> is obsoleted.</t>
  <t>Additional authority is given to the executive director to address
other IETF mailing lists in limited circumstances.  Thus <xref target="RFC3934"/>
is updated accordingly.</t>
</list></t>

<t>What is and is not acceptable behavior has not changed.</t>

</section>
<section anchor="why-shift-this-function-from-the-community-to-the-executive-director"><name>Why shift this function from the community to the executive director?</name>

<t>The previous policy required that a discussion take place within the
community to ban an individual.  Those discussions have proven to be
long, meandering, emotional, and time consuming.  The reason we have
juries is so that the public needn't vote in a popularity contest
about whether someone should be convicted.</t>

<t>The executive director is in a position to address complaints and
observe bad behavior outside the melee of any particular technical
discussion, because they carry no agenda other than the aims of the
organization.  In addition, as a managerial arm of the IETF, the
executive director has the capability to manage what are sometimes
difficult personal situations.</t>

<t>Finally, the executive director is in a position to engage and make
decisions in an effective manner, without consuming inordinate
amounts of community resources.</t>

</section>
</section>
<section anchor="mailing-list-policy"><name>Mailing List Policy</name>

<section anchor="applicability"><name>Applicability</name>

<t>This policy applies to all IETF plenary lists mentioned in <xref target="RFC9245"/>.
In addition, certain aspects of this policy may be applied across all
IETF lists, as stated below.</t>

</section>
<section anchor="what-is-appropriate-or-inappropriate-behavior"><name>What is appropriate or inappropriate behavior?</name>

<t><xref target="RFC9245"/> describes both appropriate and inappropriate
contributions to the IETF list, and lays out charters of other plenary
lists.  Any new plenary lists created shall contain a statement as to
what the list is to be used for.  Messages beyond that purpose are
inappropriate, as are messages that violate our community standards as
specified by <xref target="RFC7776"/>, <xref target="RFC8716"/>, and <xref target="BCP54"/>.</t>

</section>
<section anchor="initiating-complaints"><name>Initiating Complaints</name>

<t>Complaints against individuals shall be transmitted to the executive
director via a mailing list [TBD].  Complaints must not be sent to
other IETF mailing lists.  The executive director may also take action
on their own initiative.</t>

<t>It is beyond the scope of ANY mailing list to discuss the behavior of
an individual, except for the purposes of reviewing this policy, in
which case a separate mailing list shall be designated by the IESG for
that purpose.</t>

</section>
<section anchor="who-is-responsible-for-addressing-inappropriate-messages"><name>Who is responsible for addressing inappropriate messages?</name>

<t>The executive director of the IETF shall be responsible for addressing
inappropriate messages.  The executive director may delegate this function.
The moderation function described in Section 3 of <xref target="RFC9245"/> is
discontinued.</t>

<t>The executive director may consult with members of the community,
including but not limited to area directors, working group chairs, and
IETF participants; in order to seek a good outcome.</t>

</section>
<section anchor="actions"><name>What actions may be taken?</name>

<t>The executive director may take any action they deem appropriate in
a given circumstance, including but not limited to no action,
advising, warning, moderating, rate-limiting, suspending, or banning
individuals.  In performing this function, the executive director
should apply all appropriate processes specified by the IETF in
relevant BCPs in an even-handed way, using the least amount of
intervention necessary to satisfy the goals in <xref target="introduction"></xref>.</t>

<t>The executive director MAY, in consultations with the IESG, apply any
action taken across all IETF mailing lists.  However, posting rights
limitations across all lists should be viewed as an absolute last
resort.</t>

</section>
<section anchor="community-notice"><name>Community Notice</name>

<t>When the executive director takes an action in accordance with this
policy, they shall inform the IESG by email.  In the case of bans or
suspensions, this notification shall be noted and minuted in the next
IESG meeting.  In cases where an individual is banned or suspended
from any working group list, notice shall be given to either the
impacted working group or to IETF-Announce.</t>

</section>
<section anchor="appeals"><name>Appeals</name>

<t>Individuals may appeal the decisions taken by the executive director,
as specified in <xref target="actions"></xref>.  Appeals follow a fairly usual IETF
appeals process and timeline, as follows.  Any initial appeal should
be made to the executive director, and if the appeallant is unhappy
with the outcome of the appeal decision, they may escalate the
complaint to the IESG, and finally the IAB, as described in
<xref target="RFC2026"/>.  Appeals must be made within one month of receiving
initial notification of the moderation action, or subsequent appeal
outcome.  In taking any action, the executive director shall notify the
offender of these rights.</t>

</section>
<section anchor="review"><name>Review</name>

<t>An individual who has been moderated, rate-limited, suspended, or
banned from a list within the scope of this policy may apply to the
executive director to restore normal posting rights after a period of
twelve months, and every twelve months thereafter.  At their sole
discretion, the executive director may reinstate some or all posting
priveleges to an individual.  Such decisions are not subject to
appeal.</t>

</section>
</section>
<section anchor="handling-of-spam-phishing-and-other-automated-messages"><name>Handling of Spam, Phishing, and other automated messages</name>

<t>The executive director may take any action they deem appropriate to
limit spam, phishing, and other such automated attacks.  They shall
inform the IETF community of the mechanisms in place to the extent
that sensible operational security permits.</t>

</section>
<section anchor="informational-collection-and-reporting"><name>Informational Collection and Reporting</name>

<t>The executive director shall collect and report aggregate statistics
annually to the community about complaints received and their disposition.</t>

</section>
<section anchor="llc-considerations"><name>LLC Considerations</name>

<t>The IETF requests that, if requested by the executive director,
sufficient resources be allocated for this purpose.</t>

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

<t>This policy attempts to limit exposure of the names of individuals
accused of inappropriate behavior.  However, the transparency needs of
the organization demand that the community be informed of certain
actions taken against individuals.  This permits community oversight
of the function without causing undue embarressment or humiliation.</t>

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

<t>This memo creates no new technical mechanisms and therefore there
are no security considerations.</t>

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

<t>[This section to be removed by RFC Editor.]</t>

<t>No registries are requested.</t>

</section>
<section anchor="acknowledgments"><name>Acknowledgments</name>

<t>The authors would like to thank Marshall Rose for having first
addressed this difficult subject in our series, as well as all those
who have served as moderators and ombudspeople.</t>

</section>


  </middle>

  <back>


    <references title='Normative References'>



<reference anchor='RFC9245'>
  <front>
    <title>IETF Discussion List Charter</title>
    <author fullname='L. Eggert' initials='L.' surname='Eggert'/>
    <author fullname='S. Harris' initials='S.' surname='Harris'/>
    <date month='June' year='2022'/>
    <abstract>
      <t>The Internet Engineering Task Force (IETF) discussion mailing list furthers the development and specification of Internet technology through the general discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist. As this is the most general IETF mailing list, considerable latitude in terms of topics is allowed, but there are posts and topics that are unsuitable for this mailing list. This document defines the charter for the IETF discussion list and explains its scope.</t>
      <t>This document obsoletes RFC 3005 and updates RFC 3683.</t>
    </abstract>
  </front>
  <seriesInfo name='BCP' value='45'/>
  <seriesInfo name='RFC' value='9245'/>
  <seriesInfo name='DOI' value='10.17487/RFC9245'/>
</reference>

<reference anchor='RFC3935'>
  <front>
    <title>A Mission Statement for the IETF</title>
    <author fullname='H. Alvestrand' initials='H.' surname='Alvestrand'/>
    <date month='October' year='2004'/>
    <abstract>
      <t>This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point. 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='95'/>
  <seriesInfo name='RFC' value='3935'/>
  <seriesInfo name='DOI' value='10.17487/RFC3935'/>
</reference>

<reference anchor='RFC3686'>
  <front>
    <title>Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)</title>
    <author fullname='R. Housley' initials='R.' surname='Housley'/>
    <date month='January' year='2004'/>
    <abstract>
      <t>This document describes the use of Advanced Encryption Standard (AES) Counter Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload (ESP) confidentiality mechanism.</t>
    </abstract>
  </front>
  <seriesInfo name='RFC' value='3686'/>
  <seriesInfo name='DOI' value='10.17487/RFC3686'/>
</reference>

<reference anchor='RFC3934'>
  <front>
    <title>Updates to RFC 2418 Regarding the Management of IETF Mailing Lists</title>
    <author fullname='M. Wasserman' initials='M.' surname='Wasserman'/>
    <date month='October' year='2004'/>
    <abstract>
      <t>This document is an update to RFC 2418 that gives WG chairs explicit responsibility for managing WG mailing lists. In particular, it gives WG chairs the authority to temporarily suspend the mailing list posting privileges of disruptive individuals. 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='25'/>
  <seriesInfo name='RFC' value='3934'/>
  <seriesInfo name='DOI' value='10.17487/RFC3934'/>
</reference>

<reference anchor='RFC7776'>
  <front>
    <title>IETF Anti-Harassment Procedures</title>
    <author fullname='P. Resnick' initials='P.' surname='Resnick'/>
    <author fullname='A. Farrel' initials='A.' surname='Farrel'/>
    <date month='March' year='2016'/>
    <abstract>
      <t>IETF Participants must not engage in harassment while at IETF meetings, virtual meetings, or social events or while participating in mailing lists. This document lays out procedures for managing and enforcing this policy.</t>
      <t>This document updates RFC 2418 by defining new working group guidelines and procedures. This document updates RFC 7437 by allowing the Ombudsteam to form a recall petition without further signatories.</t>
    </abstract>
  </front>
  <seriesInfo name='BCP' value='25'/>
  <seriesInfo name='RFC' value='7776'/>
  <seriesInfo name='DOI' value='10.17487/RFC7776'/>
</reference>

<reference anchor='RFC8716'>
  <front>
    <title>Update to the IETF Anti-Harassment Procedures for the Replacement of the IETF Administrative Oversight Committee (IAOC) with the IETF Administration LLC</title>
    <author fullname='P. Resnick' initials='P.' surname='Resnick'/>
    <author fullname='A. Farrel' initials='A.' surname='Farrel'/>
    <date month='February' year='2020'/>
    <abstract>
      <t>The IETF Anti-Harassment Procedures are described in RFC 7776.</t>
      <t>The IETF Administrative Oversight Committee (IAOC) has been replaced by the IETF Administration LLC, and the IETF Administrative Director has been replaced by the IETF LLC Executive Director. This document updates RFC 7776 to amend these terms.</t>
      <t>RFC 7776 contained updates to RFC 7437. RFC 8713 has incorporated those updates, so this document also updates RFC 7776 to remove those updates.</t>
    </abstract>
  </front>
  <seriesInfo name='BCP' value='25'/>
  <seriesInfo name='RFC' value='8716'/>
  <seriesInfo name='DOI' value='10.17487/RFC8716'/>
</reference>

<referencegroup anchor='BCP54' target='https://www.rfc-editor.org/info/bcp54'>
  <reference anchor='RFC7154' target='https://www.rfc-editor.org/info/rfc7154'>
    <front>
      <title>IETF Guidelines for Conduct</title>
      <author fullname='S. Moonesamy' initials='S.' role='editor' surname='Moonesamy'/>
      <date month='March' year='2014'/>
      <abstract>
        <t>This document provides a set of guidelines for personal interaction in the Internet Engineering Task Force. The guidelines recognize the diversity of IETF participants, emphasize the value of mutual respect, and stress the broad applicability of our work.</t>
        <t>This document is an updated version of the guidelines for conduct originally published in RFC 3184.</t>
      </abstract>
    </front>
    <seriesInfo name='BCP' value='54'/>
    <seriesInfo name='RFC' value='7154'/>
    <seriesInfo name='DOI' value='10.17487/RFC7154'/>
  </reference>
</referencegroup>

<reference anchor='RFC2026'>
  <front>
    <title>The Internet Standards Process -- Revision 3</title>
    <author fullname='S. Bradner' initials='S.' surname='Bradner'/>
    <date month='October' year='1996'/>
    <abstract>
      <t>This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. 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='9'/>
  <seriesInfo name='RFC' value='2026'/>
  <seriesInfo name='DOI' value='10.17487/RFC2026'/>
</reference>




    </references>



<?line 257?>

<section anchor="changes-from-earlier-versions"><name>Changes from Earlier Versions</name>

<t>[[This section to be removed by RFC Editor]]</t>

</section>


  </back>

<!-- ##markdown-source:
H4sIAOybcmYAA61aW3PbxhV+31+xTR7atJRGthTJUSaTyIodO2OnHstTT8b2
dJbAktwIwCK7C9JMxv+93zlncbMptw/Vg0OCwJ7bd75zQY6OjlRyqbKX+umj
V4/1i8o2Juz1MxeTfm4as7a1bZJ+EXxhyy7YqMxyGew230/3RVX6ojE1ziiD
WaWjyppwtCzaB6dHwbaVKfiMo5MTFbtl7WJ0vnm1b7NMVZhk1z7sLzWeUV1b
4nu81GFVfHP/7OsFfTj95vRM+WX0le1/Oz1/cKpcGy51Cl1M909Ovjm5r27t
fudDiZObZENj09GPpJJSMZmm/LepfAOxe5jRukv9JvlioaMPKdhVxKd9TR/e
KWW6tPHhUukjpfHnGgh9dKyfwTK+IOY+qpxP40Uf1pf62sXC65t9TLaOfDni
dJsu9UtXbBL8FUyMVl/wb4Uvcc71k6MHpydncsUleOK1qSoXbYVw5Pu6JpGL
bnYu/WFDBWv4h3bDFn3xj7N7+uxMP7h4oL+BL77gH21tXHWpKR4/0D/HxWZm
0ctj/dpVyTcTm176pQ1pev0Os/LhYcd3/lDQDceFr2cSHh7rn3xT7oCkiYyH
wTfz6yzjsYmJDtUvEhCYypn3ntmtrfT9hb5374y0q5yp9Q3/OPHk6QlQNnPY
VUcex91zd53DXV9f6LN75/rs9HzmriW0W/+wysoka+pPzPqZoLB1jZ0Y9bPf
NNOrbNINwa7wwepnz67nGtzT5ycX+vT0RH99ce/eTAMGqwll/CH2z7MKqvGh
Nslt7SXdrlyzGi8odXR0pM2SzC2A+FcbF3Vta6/b4LeutFEb+ih5rHGuFpQD
cDp5bcoS6R1hoGlxWxsc8lAt7cZsnQ8aEeOMbzNDVJT5x1o/TXpITP3y8bWm
xKTT+0zmi5TJx1nF2pVlZZVCigZfdkUCHajvJn+ku9XFxgTksIaJOuE7Sy+B
so4JhBXQMLEye1tq3+FLo//88y8QR9I+fDiGhNLB8s5UsB022/etLRLuhrls
GNyQNFJNJ1dbMl1ctLIswlSqNk0z0aHtQusj7vQr/o4Ym8b9YciEhTZRRwhw
KwcRrlGiDLgLyizY4YfOcYOSmqLvmnX2LbnBNLerrqr2/FRjRfVkbqE4+02b
tQEi0+SUSE4JtmJYVHsVYPmxfgTTg7NNYfWG9Nz4XYNDYf5uYxs+3r6HWBI/
gsSRT7b+1pYLxXqPvySw00oXpiMzcCI8tafflxUIgi64BGattha86pqi6koc
DZT+XV/7uu4aQt0kmqgcO5JtdmavV8HXrNKqQx5Q8SDnSOHIrld65vxvce6T
rob7+Cs/PHHsbuPZbAl6Ocd4taenX/UOphgZ8Eddu5SsZc3gsMIE+G7rK/CK
BSSQK77DpcjakjqQGXTrE9R1hmJWU96vQucSYsgB27rkbPyWndDErm5Ttujp
o5ufxiMR+i+/BEEimEo9FsygZARrIh4DlKDpTrMJpthIGEFx6yZqlIdNr8oU
yEtfOsvQGCB6zDavSUqP5+HIngxy0DmoqPyeMgYW+6ryu8jRfO4aV7s/7Nyn
uueNY7rFvJdbpje0yG5XuFbi5TK7jE46np59yO2Nxb+RqOhO8tIzNa5IaQlv
NtPG7DvEKSH3EC9OMEsuiC51rBw9+wx6JL2ZIIw9hhzO2IJj/GplmxJ+xf0v
hHIRqeDWm0R3Q6g11fRHZoNgmghfIDP3Evabrq7JKjwCCmzW6FWYD8XplCP5
MqtdGxwElYWbfeWKPYclc8/5g/MPH4TrwXKcvjGy2TZYojsc0dN3qZc9z+z6
W+FC9hDSOMVJvXA9ZdiiI55BKgdQqzj6n00mrBo1OYi7kMlFH+kbKx9PycYp
YxM8B204ZGXpEgN4KjvqNUQ2TIUHlZggYkhMdtCMYEmViuIKywsXiq6makvp
p5EZXdQDf599+IBzIFdKGpxZoCYToVUUtNfkIfxKbsZ/GvSEuMG2ySBvBggy
AdFvEr5Sov16swcZu1WCKXh2cNNAgcXAlnea+70ApEVb7jz0FhggVX7vHCOa
MT5lW64g3JkzYUg01UzU0gAdzYRE2SsE+PGcKMCn/kLCsbQKHfZ6gb4DzkDB
oc9oQSSGUgOp1MIqoj/8zKf21KZ3lk9Uv3WhZysv6kvVXMIwZunmr8AkqDaX
bN92lWFw4GD0HIm4quPaxsGPvrZou6jsdRVwzgpsXcEwY+cdAJHrGwIfnRSV
kWfgKrjPNYmjTqOJDXh2acox3lAgUppzJtjKWmYBqpJMfaSxTrbYNK4AQY9e
XeAIrqv0JCwyAWzQQPYa9GIynOEUSUHj6p6+1bQiUmvWkL5uaE4MFWmcAnJE
PoW6Z31KjQUfcMALhFrGoWnNEtkj6JCD4N/MnuRg7qFgx2pFxiWNhiNy6g5M
SoXtMSgaxXFxV+oe8rpt1iSN0FMDuapEBRP8OQapBfMWfIz0awtGNQFgwBnu
5IylsmBqGg7YayPkZ8UXJUuIgufgF5xPnK5XbYvP2RG5x87pZugnolbPXPtp
s6ypkYHW3H+AXGaN6iRSBeYvQ4ZRpU45uKOcGg3S0mZxREXBA5AQqVgki5Je
NDFXLS3KRk82magmdZhcfrByg1Vm3IwBoghuCQuXgODsDCa+WeWlNMTNHUe9
Z65BPyECNO6R+/bc6bOluXURv6l+yLhC1nBVmvmzAGuQhXFDDieR7DYxnNcW
hF2vdj2B9CMDM5VGhnG3h/OfUydBJXVp977JjJmbdMK3mlknyUTFt39MaqTz
FXu0CxNcDbMcHlLjeIBSK969uLg4p/FAvj24uHfeDwu48vD6xddnBBCK3lOc
R80HYHk90I9S1xMqOjAMiHNgLnca3NOWn5QSNaTf1hnmibFO6rdvXj388e07
uGkiqsZYzdUMJ0dyNfx8V6HNHH8g2QnLUHI20ihp3x0IdEf1R4zeWjjhKUdv
iBEkF75lWr365de50rAwMyrfOJLySs2qGsrTeyrVB0czKqiWW65JAtI4A0g5
tIiFIXjAfjA6RX6mweB4JA5aczNpsLjbh0A1xVmfol7mt9gicxw1ENyxSt0R
IpumXg/B7+8sYxOSH3W6+3x1+PzPx7BEeVvT7bMm5phVOtQE9lxS/rd2kMsi
Ets13edKNenAVI+ywxNQbetlZpRZE7VQwyyqwU6M4L4HJOIGowyngkV3PtzS
revgu5Z4ytFVqvhC7/0Mg4z4lkxBibHcfUZrb4GMtfe8moB8O6FgAXrsqZzA
33yv//wyX//wWTslVUCIeQPATUJpbT2jZGDU5DZ52ttOZvFD9lOXwaculCm3
LnL/tjOh4Q99JOkz4f2In+SvsQO1NSV/hp5oHhvB0kBE0o+gJ6CV1ZBSPSLu
agdU7tio2u25rs5myGGemRHrAHc4IQCZW8RHg0qHdgFeOdpQg1rCOCR0F0Uh
S6tSpK40CMQVjtbIW6nb84kzwhFxJcJkhsbhb9797Us3WWt9dTdkn1/9SsHo
YSv9kYC3p4hFb3azV32wCSqTmn+YbZ/4HWxEGwRe4XrBQ2hUHK8saXKGVNOx
NybSo86CeltaKGL4hrMreEZRlxSSQHnc4/yCBr+wNAjZu+ZC1lwOHOZAmaII
lr3dSPieZBnWwley5hyZEyHmRalASprTyGUAuEPOAzUMR24RFwI0AB34KISH
BhrEVTKU+kowTBI+khH4fVIsrLY2yZwCWSQn0lTBC9TphonqEvWeJcE/Z4Mt
FY9xlKxzJpEmqGG3jdoMU611ucdH41G3hleW8wNkxqXgH101DdBaZH654i1D
VLPdJ5dZ/oGNG9tngVNOmU+DBhaYrzQZ4JmlvqK+TKTl3QQIbwWGBGK7SD7h
tzsm35JzdRgBAVhppPIyKXd5Uu+rXl0BpVqOi447NJUedNhi4dmKsp5m9maD
C3s1pFbm48nOiyT1TsnII5ehSJlKqhoPx9L7jN0sZyhtdWWkkatXD9mqaYXL
ffT9k/vo7SZe4x6qNy3P4TSl1ih4G+k/CosgMpGKW2YwzgZMCmwmb8EgZtLf
O+6CWZ7q65BkjWE0jXXkzoFM4MmC9zJlyp6r7yxoMcn0IgB8yT2TUlez9BgX
sMBbVtiW0zJC34a8IQtUzidJIempxmXF2Pp9PBsJZ0qQDg20+AUslmg3y69T
qo9YUpsVvXYwVKscle+VSjtbbXNcpP5TDaE6MP1Blmr8NAU55S6W1lncxgT7
WT+T7rST4+mFB2oKI6/tRD+FqrelRisPmR8tZ246dKRjahu2LxEOfoMA6s/7
DSTm2yewgUsGHHjTmnqhX8CNG67fZJ608qZLvubGtW8D/w+dCRThgINYSG57
QG4kU0bhJiVT3OYWNBcFNSsKqIHjxNWnhaVFm4s1V2ZZdg38QUt66b6jzW0w
4CRZRLQD+3idhGtQlaCtaADLr9v4nmvwVu5cSfOXtkVlpDDd5aJ+TOXH+JnA
z2BsWwdpnyn29BKmiJhSmk5YxX+0B5TV1mQDJTSRC5mADnjrFygc72fPrvmV
g+upIkeSXUeLQt7vkkMWxKL5ythOHaoNsaNNjyOGGbfytJkAnxccOJmpKD3H
EUe/AIoNcvVTdSa7FEypdZsY5wIW+x4H0IunHF165/rR6zP4rCh4qOfLB99G
THojOmW6fee9YuR0/+jNHjBcm34rMI/F0ubuRKTm1Y3qG/zcrn06ljOWyV7B
1xS9UC4SEals6TA0DTstI/1q15QdIlMvTaDZjRcetLAbX1Kwv296LB90OL8g
lkUKNUm8ZRmWktMcytgKdkXMyZ+UcMyYLcVMAkt/evXL1SeS375h2TGnj6xj
AjTZCuLojfGj0tHrhLfvlPqFGHtN/+eEy289BnyyjKvitvG7ypZr8kFGtrwv
QLPGXW3lbnP2m+ZWPzdBkvEl7XdWvOWkMotKHmh3LMMwb86h5rjR7LmU6nSH
hKY3qrJrQx2ouGGmd8m0JVfDayHeDHM3neseacVcVy+7EgXPtxVlBr0aX4Ln
QDXX+QUPl75HJlQOpPgvwgW577vP/ZFz/3f3vn1H/v0P21XyZAUkAAA=

-->

</rfc>

