<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.35 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-carpenter-rswg-authoring-ethics-00" category="info" submissionType="editorial" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.33.0 -->
  <front>
    <title abbrev="Author Ethics">Ethical aspects of RFC authorship</title>
    <seriesInfo name="Internet-Draft" value="draft-carpenter-rswg-authoring-ethics-00"/>
    <author initials="B. E." surname="Carpenter" fullname="Brian E. Carpenter">
      <organization abbrev="Univ. of Auckland">The University of Auckland</organization>
      <address>
        <postal>
          <postalLine>School of Computer Science</postalLine>
          <postalLine>The University of Auckland</postalLine>
          <postalLine>PB 92019</postalLine>
          <postalLine>Auckland 1142</postalLine>
          <postalLine>New Zealand</postalLine>
        </postal>
        <email>brian.e.carpenter@gmail.com</email>
      </address>
    </author>
    <date year="2026" month="April" day="11"/>
    <workgroup>RSWG</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 52?>

<t>This document describes guidelines for assigning authorship in RFC documents,
and guidelines for disclosing the use of artificial intelligence during
document preparation. It also discusses the related issues of acknowledgements,
editors and contributors.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-carpenter-rswg-authoring-ethics/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        RSWG Working Group mailing list (<eref target="mailto:rswg@rfc-editor.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/rswg/"/>.
      </t>
    </note>
  </front>
  <middle>
    <?line 59?>

<section anchor="intro">
      <name>Introduction and Scope</name>
      <t>Questions sometimes come up about who should be listed as the
author(s) of an RFC, who should be listed as editors or contributors,
and what acknowledgements are appropriate. Additionally, questions
arise about the use of artificial intelligence tools during the
drafting of future RFCs.</t>
      <t>The policy guidelines below address these questions and are applicable
to all RFC streams as defined in
in <xref target="RFC7841"/>, <xref target="RFC9920"/> and any streams defined in future. However,
each stream may specify its own authorship policies and requirements in
addition to those described here.</t>
      <t><em>Open issue:</em> In case of conflict, the stream's policy will prevail over this document.</t>
      <t>The guidelines are intended to be compatible with the RFC Editor's
style guide <xref target="RFC7322"/> and with an earlier RFC Editor authorship policy:
<eref target="https://mailarchive.ietf.org/arch/msg/rfc-interest/SHM7dHZd_S1a-CkW2JCBvxdKmcs/">RFCED-policy</eref>.</t>
      <t>For the IETF stream, there is an existing IESG statement on Internet Draft Authorship:
<eref target="https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-on-internet-draft-authorship-20210510/">IESG-policy</eref>.
For the IRTF stream, Section 4 of <xref target="RFC9775"/> covers this topic.</t>
      <t><em>Open issue:</em> Are there items in this draft that should be left as operational choices for the RPC, i.e., they are not really policy issues?</t>
    </section>
    <section anchor="general-aspects-of-authorship-ethics">
      <name>General Aspects of Authorship Ethics</name>
      <t>There are some quite general aspects of the ethics of professional
authorship of academic or technical documents that naturally apply to
RFCs.
This is not the place for a detailed discussion of authorship ethics,
but the most important points are</t>
      <ul spacing="normal">
        <li>
          <t>Factual accuracy.</t>
        </li>
        <li>
          <t>Avoidance of misleading or obfuscating statements.</t>
        </li>
        <li>
          <t>Avoidance of misleading omissions.</t>
        </li>
        <li>
          <t>Balance between opposing arguments, when relevant.</t>
        </li>
        <li>
          <t>Careful acknowledgement and citation of sources and references.</t>
        </li>
        <li>
          <t>Avoidance of unacknowledged plagiarism.</t>
        </li>
      </ul>
      <t>Factual accuracy includes accuracy about who wrote the document: only
people who made a real contribution should be listed as authors or
contributors.</t>
      <t>Other aspects are that personal or business considerations should not
affect accuracy and balance, and any hidden conflicts of interest
should be documented.
Corrections, clarifications and retractions should be made promptly
when needed.</t>
      <t>Many academic journals and universities have published policies about
authorship.
Two examples from medical science are
<eref target="https://www.icmje.org/recommendations/browse/roles-and-responsibilities/">ICMJE</eref>
and <eref target="https://pmc.ncbi.nlm.nih.gov/articles/PMC7821455/">NIH</eref>.
The IEEE also has clear guidance: <eref target="https://journals.ieeeauthorcenter.ieee.org/wp-content/uploads/IEEE-Author-Ethics-Guidelines.pdf">IEEE-ethics</eref>.</t>
      <t>Some organisations have adopted strict policies about the use of artificial intelligence (AI)
during document preparation. Again the IEEE is an example:
<eref target="https://journals.ieeeauthorcenter.ieee.org/become-an-ieee-journal-author/publishing-ethics/guidelines-and-policies/submission-and-peer-review-policies/#ai-generated-content">IEEE-AI</eref>.</t>
      <t>However, the Internet community that contributes to the RFC series has some
peculiarities. Perhaps the most important is that we generally encourage the free
flow of ideas and their re-use in fresh documents.
Sometimes that means that small or large sections of text are copied
from one document into another, and subsequently changed as the
discussion evolves. In the world at large that is considered to be plagiarism.
In an RFC, we generally consider it to be normal business as long as due
acknowledgement is given. We also consider the use of complex software tools during
the preparation of a document to be normal practice.</t>
    </section>
    <section anchor="authors">
      <name>Authors</name>
      <t>Authors are people who have made a substantial creative contribution
to the document.
Normally this means writing text or drawing diagrams.
Occasionally, with the consent of the other authors, it means making
some other substantial creative contribution to the document, for
example by writing a software implementation as part of the design
process.
It is a matter of judgement whether a person who simply makes a key
intellectual contribution should rank as an author.</t>
      <t>People who did not make any such substantial contribution should not
be listed as authors.
Funding support, professional reputation, managerial or supervisory
status, and CV embellishment are irrelevant.
It is also worth noting that in an RFC, authorship by an employee
does not automatically imply endorsement by the employer.
Therefore, authors should not be added just because of who they work
for.</t>
      <t>There are quite a few subjective judgements to be made about whether a
contribution is substantial enough to count as authorship.
What fraction of new or corrected text counts?
Is a particular brilliant idea enough?
Should the author of a previous trail-blazing document be invited to
join?
Should someone who promised to contribute significantly, but only
contributed fragments, be removed?
It is hard to give definite guidelines for such cases.</t>
      <t>In normal circumstances, people should never be listed as authors
without their explicit permission.
In case of doubt, the person submitting the draft should check with
each listed author in advance to avoid any misunderstandings.
If an author wishes to withdraw, this should be honoured, although the
person may then be listed as a contributor or be mentioned in the
acknowledgements.</t>
      <t>The practical impact is that the authors will be listed as such on the
front page, and in public bibliographies, if the document becomes an RFC.</t>
    </section>
    <section anchor="contributors">
      <name>Contributors</name>
      <t>Contributors are people who made smaller creative contributions to the
document than the authors, for example providing initial ideas that
others have transformed into publishable text, or drafting only a few
paragraphs.</t>
      <t>People who did not make any such contribution should not be listed as
contributors.
People should not normally be listed as contributors without their
explicit permission.</t>
      <t>The dividing line between contributors and authors is a matter of
judgement and cannot be rigidly defined.
However, the RFC Editor's policy is to query any document that has
more than five listed authors.
Any list of more than five authors will need to be negotiated if the
document is approved for publication as an RFC.</t>
    </section>
    <section anchor="editors">
      <name>Editors</name>
      <t>When a document has a large number of contributors and potential
authors, it may be appropriate to designate one or two people as both
"Authors" and "Editors" and list the others as contributors.
The editors will indeed do the actual work of editing the document on
behalf of the community.
The practical impact of this is that the editors will be listed as
such on the front page, and in public bibliographies, if the document becomes an RFC.</t>
      <t>In some cases, it may be appropriate to retain a list of authors of
which one or two are designated as editors.
What matters is "truth in advertising": the people involved should all
feel happy that the designations of editors, authors and contributors
are fair and accurate.</t>
      <t>Historically, RFC streams have chosen to retain the word "Author" in most
cases, with the formal designation of editors being exceptional.
Some standards development organizations always remove
individual authorship when a document is formally adopted. This is not done
for RFCs, but in a few instances,
RFCs have been published with "IAB" or "IAB and IESG" listed as authors,
with editors credited as such, e.g., <xref target="RFC4089"/>.</t>
    </section>
    <section anchor="list-of-acknowledgements">
      <name>List of Acknowledgements</name>
      <t>Acknowledgements should be given to people who have made significant
creative contributions smaller than those from the authors and
contributors, or to people who have made useful comments, provided
critical reviews, or otherwise contributed significantly to the
development of the document.
If text or ideas have been adopted from other written sources,
including RFCs and drafts, clearly a reference is an ethical
requirement, but an acknowledgement might also be appropriate.</t>
      <t>Acknowledgements may also be given to people or organizations that
have given material support and assistance, but this should not
include the authors' regular employers unless there are exceptional
circumstances.</t>
      <t>An acknowledgement should be written as a description of a fact.
It does not and should not signify that the person acknowledged agrees
with or supports the document.
In general, people who do not wish to be listed as an author or a
contributor, but have in fact made a significant contribution, should
be given an acknowledgement.
In unusual circumstances, acknowledgements of contributions have
specifically indicated that the contributor does not support the
document as posted.
Language such as the following might be used:</t>
      <ul empty="true">
        <li>
          <t>Thanks to &lt;insert names&gt; for their valuable comments and
help during the development of this document, even
though they did not fully agree with the WG's conclusion.</t>
        </li>
      </ul>
      <t>When in doubt, it is usually better to include an acknowledgement than
to omit it.</t>
    </section>
    <section anchor="bisDrafts">
      <name>Revised or Replacement Documents</name>
      <t>A common occurrence is that an RFC from some years ago
requires updating.
This is often done by people who were not the original authors.
The question then arises of whether to list the original authors on
the "bis" draft, even if they are long gone from active participation.</t>
      <t>When an RFC is drafted by one or more new people but
reuses significant amounts of text from one or more earlier RFCs,
a situation arises that often requires thought and
careful handling.
The criteria above suggest that the authors of the original documents
should continue to be listed as authors.
After all, there is rarely any question that the earlier publications
constitute "a substantial creative contribution" to the revised
document.
However, there are no guarantees that the prior authors will want to
be listed as authors of the new draft and take on whatever
responsibilities that implies.
Ideally, those assembling the newer version will consult with the
authors of the previous ones and make mutually acceptable
arrangements, but, especially when that is not feasible, sensitivity
to all possible issues will be needed.</t>
    </section>
    <section anchor="other-exceptions-and-discussions">
      <name>Other Exceptions and Discussions</name>
      <t>It goes without saying that normally nobody should be listed as an
author, contributor or editor against their will.
Ideally, the parties involved will agree among themselves, or defer to
the judgement of the relevant RFC stream manager(s).
However, we need flexibility to deal with unusual cases, such as
these:</t>
      <ul spacing="normal">
        <li>
          <t>As noted above, an acknowledgement is a statement of fact (the
person contributed to the discussion).
In some cases it may be included even if the person acknowledged
objects, for example if they made a suggestion that might later be
viewed as prior art.</t>
        </li>
        <li>
          <t>Generalising the point made in <xref target="bisDrafts"/>, an earlier author or
contributor may deserve to be listed, even if they cannot be
contacted when a document is updated after a long interval.
Each such case needs to be considered on its merits.</t>
        </li>
        <li>
          <t>In particular, an author or contributor might be deceased.</t>
        </li>
      </ul>
    </section>
    <section anchor="artificial-intelligence-tools">
      <name>Artificial Intelligence Tools</name>
      <t>Authors will use various editing programs and other tools for document preparation,
and in general these do not raise any ethical concerns. For example,
if tables, graphs or diagrams are generated using a specialized software
program, this is of no concern. If formal notation is verified by
specialized software, this is also of no concern.</t>
      <t>If an AI tool is used for document preparation, the following guidelines apply:</t>
      <ul spacing="normal">
        <li>
          <t>The authors or editors remain entirely responsible for any content generated by AI.</t>
        </li>
        <li>
          <t>The authors or editors remain entirely responsible for all intellectual property matters.</t>
        </li>
        <li>
          <t>If a substantial part of the document was created by AI this should be disclosed clearly in the Acknowledgements section.</t>
        </li>
        <li>
          <t>The authors or editors must verify that no unacceptable plagiarism has been performed by the AI. If material has been copied from earlier RFCs or drafts by the AI, as mentioned in <xref target="bisDrafts"/>, this must be clearly acknowledged.</t>
        </li>
        <li>
          <t>If, on the other hand, AI usage has been limited to improving English grammar, translating from a draft in another language, or other purely editorial uses, disclosure is not necessary.</t>
        </li>
      </ul>
    </section>
    <section anchor="intellectual-property-rights">
      <name>Intellectual Property Rights</name>
      <t>This document does not discuss intellectual property rights (IPR) and in no
way preempts or alters the various RFC streams' rules and requirements concerning
IPR.
In particular some of the ethical guidelines above might be mandatory
requirements under those rules.
All authors are strongly advised to be familiar with the applicable
rules.</t>
      <t>It is worth noting that if a document includes complete acknowledgements
and references, it will be much simpler to clarify its status as
possible prior art in years to come.</t>
      <t>Copyright in RFCs is governed by the IETF document <xref target="BCP78"/>, the 
IETF Trust/IPMC's Legal Provisions, and applicable
national and international law.</t>
      <t>The word "contributor" used in this draft might not mean the same
thing as the word "Contributor" used in the IETF document <xref target="BCP79"/>.
That BCP and the specific rules of the relevant RFC stream should be
consulted by anyone concerned about requirements for disclosure of IPR.</t>
    </section>
    <section anchor="security">
      <name>Security Considerations</name>
      <t>None, really.</t>
    </section>
    <section anchor="IANA">
      <name>IANA Considerations</name>
      <t>This memo includes no request to IANA.</t>
    </section>
    <section anchor="changes">
      <name>Change log</name>
      <t>draft-carpenter-rswg-authoring-ethics-00, 2026-04-11: original version (derived from draft-carpenter-whats-an-author-03).</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-informative-references">
      <name>Informative References</name>
      <referencegroup anchor="BCP78" target="https://www.rfc-editor.org/info/bcp78">
        <reference anchor="RFC5378" target="https://www.rfc-editor.org/info/rfc5378">
          <front>
            <title>Rights Contributors Provide to the IETF Trust</title>
            <author fullname="S. Bradner" initials="S." role="editor" surname="Bradner"/>
            <author fullname="J. Contreras" initials="J." role="editor" surname="Contreras"/>
            <date month="November" year="2008"/>
            <abstract>
              <t>The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible. This memo details the IETF policies on rights in Contributions to the IETF. It also describes the objectives that the policies are designed to meet. This memo obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, replaces Section 10 of RFC 2026. 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="78"/>
          <seriesInfo name="RFC" value="5378"/>
          <seriesInfo name="DOI" value="10.17487/RFC5378"/>
        </reference>
      </referencegroup>
      <referencegroup anchor="BCP79" target="https://www.rfc-editor.org/info/bcp79">
        <reference anchor="RFC8179" target="https://www.rfc-editor.org/info/rfc8179">
          <front>
            <title>Intellectual Property Rights in IETF Technology</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <author fullname="J. Contreras" initials="J." surname="Contreras"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information as possible about any IPR constraints on a technical proposal as early as possible in the development process. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This document sets out the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This document updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026. This document also obsoletes RFCs 3979 and 4879.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="79"/>
          <seriesInfo name="RFC" value="8179"/>
          <seriesInfo name="DOI" value="10.17487/RFC8179"/>
        </reference>
      </referencegroup>
      <reference anchor="RFC7841">
        <front>
          <title>RFC Streams, Headers, and Boilerplates</title>
          <author fullname="J. Halpern" initials="J." role="editor" surname="Halpern"/>
          <author fullname="L. Daigle" initials="L." role="editor" surname="Daigle"/>
          <author fullname="O. Kolkman" initials="O." role="editor" surname="Kolkman"/>
          <date month="May" year="2016"/>
          <abstract>
            <t>RFC documents contain a number of fixed elements such as the title page header, standard boilerplates, and copyright/IPR statements. This document describes them and introduces some updates to reflect current usage and requirements of RFC publication. In particular, this updated structure is intended to communicate clearly the source of RFC creation and review. This document obsoletes RFC 5741, moving detailed content to an IAB web page and preparing for more flexible output formats.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7841"/>
        <seriesInfo name="DOI" value="10.17487/RFC7841"/>
      </reference>
      <reference anchor="RFC9920">
        <front>
          <title>RFC Editor Model (Version 3)</title>
          <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
          <author fullname="A. Rossi" initials="A." surname="Rossi"/>
          <date month="February" year="2026"/>
          <abstract>
            <t>This document specifies version 3 of the RFC Editor Model. The model defines two high-level tasks related to the RFC Series. First, policy definition is the joint responsibility of the RFC Series Working Group (RSWG), which produces policy proposals, and the RFC Series Approval Board (RSAB), which approves such proposals. Second, policy implementation is primarily the responsibility of the RFC Production Center (RPC) as contractually overseen by the IETF Administration Limited Liability Company (IETF LLC). In addition, various responsibilities of the RFC Editor function are now performed alone or in combination by the RSWG, RSAB, RPC, RFC Series Consulting Editor (RSCE), and IETF LLC. Finally, this document specifies the Editorial Stream for publication of future policy definition documents produced through the processes defined herein.</t>
            <t>Since the publication of RFC 9280, lessons have been learned about implementing this model. This document lists some of those lessons learned and updates RFC 9280 based on that experience. This document obsoletes RFC 9280.</t>
            <t>This document updates RFCs 7841, 7991, 7992, 7993, 7994, 7995, 7996, 7997, 8729, 8730, and 9720.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9920"/>
        <seriesInfo name="DOI" value="10.17487/RFC9920"/>
      </reference>
      <reference anchor="RFC7322">
        <front>
          <title>RFC Style Guide</title>
          <author fullname="H. Flanagan" initials="H." surname="Flanagan"/>
          <author fullname="S. Ginoza" initials="S." surname="Ginoza"/>
          <date month="September" year="2014"/>
          <abstract>
            <t>This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series. It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC. Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide. This document obsoletes RFC 2223, "Instructions to RFC Authors".</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7322"/>
        <seriesInfo name="DOI" value="10.17487/RFC7322"/>
      </reference>
      <reference anchor="RFC9775">
        <front>
          <title>IRTF Code of Conduct</title>
          <author fullname="C. S. Perkins" initials="C. S." surname="Perkins"/>
          <date month="March" year="2025"/>
          <abstract>
            <t>This document describes the code of conduct for participants in the
Internet Research Task Force (IRTF).</t>
            <t>The IRTF believes that research is most effective when done in an
open and inclusive forum that encourages diversity of ideas and
participation. Through this code of conduct, the IRTF continues to
strive to create and maintain an environment that encourages broad
participation, and one in which people are treated with dignity,
decency, and respect.</t>
            <t>This document is a product of the Internet Research Steering Group
(IRSG).</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9775"/>
        <seriesInfo name="DOI" value="10.17487/RFC9775"/>
      </reference>
      <reference anchor="RFC4089">
        <front>
          <title>IAB and IESG Recommendation for IETF Administrative Restructuring</title>
          <author fullname="S. Hollenbeck" initials="S." role="editor" surname="Hollenbeck"/>
          <author>
            <organization>IAB and IESG</organization>
          </author>
          <date month="May" year="2005"/>
          <abstract>
            <t>This document describes a joint recommendation of the Internet Architecture Board and the Internet Engineering Steering Group for administrative restructuring of the Internet Engineering Task Force. The IETF Chair declared that the IETF had consensus to follow this recommendation on November 11, 2004. Further work has been done to revise and refine the structures proposed. The recommendation is being published for the record. This memo provides information for the Internet community.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="4089"/>
        <seriesInfo name="DOI" value="10.17487/RFC4089"/>
      </reference>
      <reference anchor="I-D.draft-carpenter-whats-an-author">
        <front>
          <title>What is an Author of an IETF Stream Draft?</title>
          <author fullname="Brian E. Carpenter" initials="B. E." surname="Carpenter">
            <organization>Univ. of Auckland</organization>
          </author>
          <date day="13" month="June" year="2015"/>
          <abstract>
            <t>   This draft suggests guidelines for assigning authorship in IETF
   stream Internet-Drafts.  It also discusses the related issues of
   acknowledgements, editors and contributors.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-carpenter-whats-an-author-02"/>
      </reference>
    </references>
    <?line 359?>

<section numbered="false" anchor="ack">
      <name>Acknowledgements</name>
      <t>Valuable comments on this document and its 2015 predecessor 
<xref target="I-D.draft-carpenter-whats-an-author"/> were received from
Loa Andersson,
Andy Bierman,
Carsten Bormann,
Dave Crocker,
David Farmer,
John Klensin (who also contributed some text),
Larry Kreeger,
Eliot Lear,
Tom Petch,
Alexandru Petrescu,
Yaron Sheffer,
and
Joe Touch.</t>
      <t>Especially given the topic of this draft, the author apologises for
any accidental omissions.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA61ba3PbRpb9rir9hy75Q+wpkpI1ySRRbc2MLMuJ8vTG3nHt
ZLdSINAkYQFoDB6kGZf/+55zbzfQoJjEW7uTmYkIAo3u+zj33Afn8/npSZd3
hb0yt90mT5PCJG1t0641bmV+enFjkr7buKbd5PXpSbJcNnZ7Za7lmj7Rnp5k
Lq2SEktkTbLq5mnS1LbqbDNv2t16rgvk1Xpu5f75xcXpyelJ2yVV9ktSuAoP
dk1veTGvG/nQdpcXF19eXPLabn1lfnr15qvTk/vdlbnjwpXt5s/5rtOTNOmu
TF6tHFbsl2XetrmrXu9rLGqzvMOLk4KrnJ7U+dXpiTGdS6/M3rb8u3VN19hV
e2WMeWQyu0r6Aifv3HDDvtTv5TMEIGeRdfifefjDYAu469nC3C7MTTj/+K2K
5xk2U/3GHa7BMV9vrPmPKt/aps27PTVw3af3BQQ13hh0wPsWx2+pHYRbXI0X
5uZVunGu4O03rqx7vBqXclulNr7rY94/Ny+fmS8vL55+GV8L95mnTz+9HL9I
XV91zf7K/GB35p82mS5lyyQvrsySYlnYxWA3f1/zi0XqSsp8a6veymHWjevr
K3NGazgTXYqez9645h72Zb7i9/KFLnxG+/t7s0rnagoLCFm+Tpp0g683XVe3
V+fnvJuXcPBFbrsV7zvnhfNl43atPec652dioLC0pkw63Cpbenbz8vMvhr++
lL/gNZ9/8enT8PeXENZw/c+Xl8P1zz//LPz96cUX+uzd/Pni0It2m6Rr50k1
H6yP/8znc9hC2zVJ2vHz603eGnhiX+Ip2HKbNvnStmbd55kt8gp/Yuvw7jZf
V5TW6NgwXnH18HQ7g6VDlwePZnmbFq7lsx0MpW8tLSRpunyVp3AzLNPZosjX
NCuT9fR5AQfdUt3YOmkgOlctzF1nkqJ1smbftngDl2xskXQ2M/Di3goCJel9
5XaFzdY27Ex12RruMHUwr3zZ88IiSKXMs6wQOHlEuGhc1qd8qzzxKnW1Ne8f
5fziA2/6d7yKX7eAg9J2eYk3w/RwwBoCdn1ndhtn2o3ri8wsrSnylntMZMsB
Eh63T2S7IsjZbz4R9g5pxlv38qaiH5wYArYmqevG1fCTzi7MdYZVsOGkKPYz
86+wfazR5NCJ7vkjNNQBEVqvJz2LWB4/4alV3/V4M46jkiU21K7I031sF0tb
uJ1JsqyxrQgErxx2JAL328eDyZJaAbhi42JvMF6blC0FA+zFetB8RR8z7997
J/rwYaYf6EUfPuiK1X54dHzOb3hhvnY7CwSjpSTpxt8JRMBDCGz5am9yRrdd
FXuAnCy3uuXG/qvPGy9+7ijxEmdkwCM4Y/CvzGwsXkoB/fIj/FVN9+oXGJ5J
E5U/NL3C6t1MlKL7+aQNwtzlkAZ8YwsQMg4bx12RJw+yj4ROkVKTVYb3Y0sw
MRhsDdeChLFgt5E3UcS3YnCftIy3+8Kv4sULLPISlUdguzZpihw7GJ98IKM9
4OdnfH/7fK6f//vxH8No2a7PCcPcNAylO3/19fefZ1//M/vl1dNkfnP/5vKb
m2fbd9m3ZdqeP5Ejv3CNHOLu9vULLzORH4/eyl7fwatoq3e3r77CHXANgRlo
KXAEIxzBsxUegXvn7Q+2niV4Hkh6b5tx61DB+bDuHMax1v8br7lKj0Q+oqg9
imt+eXH59OKzpxdyoOE4P0XHeWUVlz6llaiVIyZAJyntoFVD6Fydp0cM7BqS
8PLAbmin3nDkzB2hJEIgi2twM2CfIjCwAIwgTz20i7m8BHDliMMi571YWeU6
eAOBJpirQvPfFF2/shXWK8z1SBlHYQ/0UOyXKID/EWIBENiyWfuHI77JbShJ
5CdA3soKnyOFiwxR4kKS2TJPiaSdTTeVUNchgOn5qwSIIJsnAO0hytMTj2cS
LfFfHpBvrYsEiCgBEr7dwZLhWj44UUV85bgB3SMQZumRtgTjMnlZg08mDHUu
98jN0//JvECM7nnUNMWG0v1CL19vXZ4lhGIsD+pa2CQT9G2MW676FtyWHwd7
a//oOU9/w33PyLdw19J2OwvTcXWt4Ttp1j7QI+bgC8Rd4I8Hmz+RntpVXxyG
Io24eScGxFe3rm/SATNX0DHednSTfRWtlVHa65zRqlRfPxAPbDkt+owrhytj
IN41rhPLH7R9BZ8v9iD41tXEP9xUwjqgSZruGGi562NB2SsWYkc6cUgofqSP
DTaaiNPBtOBHrXgRdLXsW8IyWUPVAl7Vw9rwLpgYrHe1wgLReSCypapnNgS1
DYgLtBHihThBgEwA+LD1cHCbYYs3rmkUR6DNFADMWJ+M8bexQhHjHWEJERAc
rKw7ik6soLI2kyVPT77ndgYfews946y6Xh/yA0bLTbLFMv0SwtxQr0MUpbpi
n6XL7RxAOymhI4AOXm1K0CG6bauZiPrLz3c3339zO0Lzbrdb5Gn51gom46iu
xNkzPeFA0B0WBUXO5pBVTTUs80K2eP5EudXPP9x9PS5al+miSpf5oirKRZVv
Fmu3PSdPSrHO+cvvwT0un3762WeC3a8lDN3eKmPdwGJwV9JILKUCr8zP/Nqn
t+NLgtgQUaxVUaTC6OWCHGdXz2lxuHre14VLsvZcllIUnSuCzr8aQv+izlYa
H18RSLFEUuWt17YoI8lcTbtGjIEJHWjkY1jh4+s7iMyzwuPk/XqdSLTxYgnx
WFSrIZZHuPtfSWJJxVpmObw090/4eHruTWwsIpyPdEjUHs55PhYB9LplGcJu
c7sb73mU5HONPpBUUICKNZBHPV3gEbQ52D1SYnH+ASRsq4xQuVZrG/UJzSQI
SGlfEOdoiAvz0jabpG6PBYzcR6zdEBYRrqAOSCFZK9qtGoslV6TbhIXMJuqP
+C5v4OVz6pU0GB6wGSPhQk1F0xp5R2mTyv/ZlqTigDDABl7TehyRUGzfdQJ3
yJdyi6RdPNZVI/rQbMDlAW8bCox7gfBbcGd8ie2nm6RaR4lSFE3t1hVbiuRO
zWjnGsASNqT7kL3lI54OLHcSN+6qMd2KxRaeAi/yj1VM2YsRp7GjwjEMMvth
CncQ5/DqNUAOlv7GqtMPa0YORMpd2HfQ9arbSWCI8inkOWQVo9eIy42ym2ys
FoBONY14FCgUP/g/RRFReBNP9zGOMqcN0ZFTBDyWJiYxT1KuOF7iNT/Ii0mJ
yIPUIna0U2aC1DzT/SbZCQbkybpBroXHfkyR0wyZ55BoUDpCvZXBOQ2ZuvUZ
1aAvKJN7kYxwQL3pDzdvDvY+I0dDZqdgY5b7YdvJqIic3/FulTzUDC0M2wOv
yNeQCqIf2AqPdScqT7DBjoUx3Pe2D7aAyKjH8SFfU3u+Yc8DEVnNvd0zayWI
WmUyxzhHk1T3QjdC4inqfjlqNcuFLMiymuT2zF9jER1ZVujFMT7DrKOvhBi2
fU2kmU0oNTCj7lVEM7yzAtCwWErV437bbPPWNXsp1HZ9qw5+8w9jyyWDRbtR
SkhxNxF/9LKk08CrYSDYn9YX6NOjy0ZsermX+AGRuj0xLnNWiTnucay1pWKq
KnOEfjymulnuNWPQJ5uFTzRgIXZ4QSQmehwyeQjpbd/yU5p4V6b0JefBlu8B
dV43Y9qiGUtiVnZHhbwlUMJSBzNpvUOrT3qu6g0nIpVUG6QTq9RWrl9v+LjU
SiP9KWt6Q7mtPIPjXitsQcpHQvsIjfRXeZhp2R0NshYq0wNNWVyFtiTGIGT4
1+G+VyoWyk/fpwDFQkTuepynQQ40XxbJrxMesGSM2ebyXmRTb5HojIvRsRkh
KE5yy7xV5B7jpZHiIwkqQ8TMMH9S8j7ek/G4a5+eLFkULJEOZ38LtrVJGlmV
EK31H8kmp7VKcR0WYJTFI1Z4rE3zBkeh+OH8swCqwUgY+48mB6DIQDtPoRBv
7TtWtHJJBDzf0JAUij6Z65e+4uOBQ5hJ14Xyqebp/sXpxqb3Aqi+ahU2oKqh
32TbRIt2JmFmJQCBN8PDsTx7KVhYwGw1IgxWBC8X4+TaRPSZQv6YCWwcTAIh
Fh5T8ITrjYZrv2vWzTpmB1OpxOVLyYFg+9AYxKDFOC2NHpQyxzqiBjxSz7LG
nwP/Gc2x1cLY5K2iVOcXBx8hLwVqKTThpcISU7PM8S+HmFVvcuo4X01CiFGq
2Xoo8kH3Jkr8eCX+fBh+xcuFO8FajoatwAuj8jfOV8Xnk0gWWDPdZZsLVtOc
hZQLw6NUTk8kWHqCD8esWjYhRNB4jefGrK4KFsx88PaV3IrlDwIXVAouImJp
Py70/Ea4mSjlQcr8cupRuL0KZGOizPgxM3Euhvdj3qW2k+VeUHT2obQxWU3y
aW9F08AOxOon1Yyk8gdq8nWeYY++oLw4SAXiWupYCqOWQXebvcgsVnXHNOD0
pHRaMAAtp4lMvJrCusZjvCiFnOm9Ezdgah44o10jomqbZHVgYzwsOwVbgiis
QB1iYEETg9fTiK2/oX9H5HQjHq5cvOoR7xtfxp6KuHbMm/KoOKdkLxFNRy0L
7lxZFz8wQrBqt3PBp/C6pSP0nXm+eybrn/kt6icR00Av20MT8nl6aLCI1HJg
I8t4SiF9kYkhnsfhnQMWh5OTLS/tJilWgS0Oqd/iN6BL7tNi4gBhk11MvSXC
MPP/CmGIPUKsJej9jiIaVjep7mB3Q/lrxTpQLtsbNETkG1QXt7ACNVHXkuOf
dQ2W8sHKgoGw1nh25WOgaBrcgZlfFuABsAAkt7aAzdX1fpRgeGdIR/1bR1p3
2P1j9wsSTRCbxf2l0NZpSvU1TuoapZGzSedJEDVlR6eKZONTUlig2uMZz8SM
neMGIt0h9Vkpq4i2G+0W0qeF2XeprbXo7rNxIwEbPIYNrK0tXK3WJ+WcX0Px
rtgl+9bTH+YXgnxSJx258+7AdfPWb4mor6WghYmL3RmUKwxXOnvKwMQcSG3z
KhAjLZSrfJYE2LHIJ2c/u7t+dkYj4R8icfZVzh4Sp5kyp0EkCJdZHsXzmbGL
9cI3+dgG//DBA9R33j6vD1iE5MWHTdKRz0jmTmUezZcj/gllHg/dIbL7iM12
nxQ/YnIicwyTFq54zG+8FWkG6+lauiSt1XDPskrK9DWVbIxFKl1HIG7HZm5M
iyfceSQYsQFNYULZYMjnlVCMGg2VQi3sSK7CXBqYHgr7M1odK/G0YrEHKlqo
hdSa2S7cS5nd1/5DKVAniU5PokaqWhqZ6UGxpczXGz8MMAWrxVFFE9TCzYeq
Fioau5CyJzmy3gu00iTXZ8SKFSAYave6yZggS3bt2xGxAXyCQ68lwQrZZ2v6
qvBNcJ81Ro4PRceJh57toTBGMw6qkFCs3eZ6rCOtEHk02R6T5SqLSZcaS4So
ns9P+jBgg9b63Mbn/ZRK+8CKqlBfm8UGjsDKVzHJ8OQkcv8hB3HTHNg1KmXR
CuuVDKKhljVa+MQnZ/5kUuhQTT60JN1nX/Vt/zDPezBVEROaoXqO8CwjAqHi
ULE/IblukGKc9gyiD8Y0JWMsO7lWmzTfJdW6ZyVXwr9WRAHUReGkxKY+sBSg
yGS+568A7aS6F4b5X/8GXEY8lSmy9q+hYYtIt02KXnh/QBbFpb+ajS3qaLLD
PACJaMIACAyB8qkx/dsPGQFwiz5OQxmj3puvPhH2BbcYuLmQSOjTJ765xCLR
hTB/IeA4TPClI0hAvJVipSv5dOfjwE8ARhYSGLKs9Gnl7udDr/f9o2XeSqu/
lYGeaxEHXYUkYAAm0aESJsU8oUt7gBjEtnYDWmHXdSad16hP7FZ0RgZPVp0i
H9hZ3yYXasosohojtOeMYSBGE2mZ0mm17KQlIhx5ZLcHSwgl5RdnOOSZgq9q
zJNCbdRLPXvN7cnREq1PaR0or7VvM1J9FUIYFoBscSZP+iQLYY3Jn3HJPl5j
e245ds+klIrT0CoY2gNhjWiWROab8DT4t6YiKgFRiAp2EL2aYOfjq+9Dwy6y
IugDxg5oJIqz0LalS63Xtu0eFhBCOTpIdOiJDL1UenNe9fYheo0Z2oqGCyOO
pk8a7KvQnC9SbeD+/txR7qVJMu7rWAI7+4ia/Vmoezdq/COsHCSmPtJUzgBf
GixpbZSHIJCOIzyajewS6T4cLxkHkVH/Wp+SDhOLAlL5BhZuObR62GT11V1E
wlxi211mlWsre0KAteWyCGCE1SEfaSJzVe6K4umLbkCYIaMMOxrqkq7yAwdS
qij7TgEGfB+hVifMkqZh5ylUEHv6i+C63CmMOXSYBOFAizg4hSBjK/a1t8j2
hjk1QLh8G2YSQ0oXNcsfGR0SuA3hXjf4fOh3CWVFrF47O5Y62mQ/1MWHCknl
li7bH59SqIJQZofFN+tHtdiWbUOFkhudqsLjgW3HNExOo+AOh1b9lK1lc07L
SGR2Yi58fKydeK2Eun+UU4VOwuP2SWyqO5WYWRX2nZrNXqsCzMip9CFua4Ll
46S8t7VXfqREFEZx0PFnx2KIlHuiYbCV8ovHYlMmkKCYVYcG06At7tuYSTod
ZdM+fmUxBB/jVlzDSaPgoNIXUHto3wl6DRCiVIBjsCyqchWmBWoC3p2bTnZI
ifgBrHwYypXJI11bxijHyPhhFk/4DdyMK8XmxGOCbtpmO0XFg5gzFM7C84n0
Io6koxJMuX8FUo1UMtWylXzYmFsZ0wwFe7GT0E+JOsBsnZD/A/mlkqwCgJrG
ZsdsyjonxwoMK7Mp/H3w3OtxCuIunoJ4zV5u3IEVT2G7aIvoRSAK9SPkK9Ie
FZ93Pp6zESwj00fmJ/ywbz5waqNjs55NN4kM8SK2+DRKiJZtqnZhXox2xNwM
uiDiwcC0qise67u1EhaGIQfTt75HqjiY/8p80vdLpRXKh2ZDJYt9JhdevDDI
In2hAztMQhsLjg3ZCXvwxPlg4XE9ydimiwomSq/i+k4kpnzRVy6PCu6ANccT
sZzv8yjxOqYAzVB4aPhrAzgAoq5E7yGGFX7ur5LRAZY0I7mBGF3fLf5vCxdh
wsY3h5nhgs7vQ+3ML09hTJjBpGkd5LFLWqUMYXOH/Rw/pY+vQ4LuK1oPayY6
7vH7pyvZKhVN70Oskmm+EG6jmQypG2uxyDa+Q+FbtJAhzzek38OdOl2i7DFm
jEMPox2XmBEDJ12mA3zTYQbt7Y7liQiUB0nPQglWHZYEc0ZZ9i2TtGF3RV76
VifJDWs2MLvbas1KGH2uLAk60pEpdFZT2bcnT9Lu1jcUPgEcyzsgiGIuw6+U
aPxwZa+/Xqmm9E8s5xSSZr8YftMwGtPLYEw/EeHaI78ECVmqj3C/YYuNPG4e
37386UkoRleI+zvEA/igLetOlJIUnY4mj0gYFVQ/MU1fHJui914v8x94hebq
UZtaZ0KiCWDsLfZvYfoDiJesnnYynTB5izRDPemUjZDAF2MuJRPIXYMIJOXR
bWhQL1k5LnPOao1JbvyjhbBY6EEfGW2YjPcMA6w6JMTZgQdVzOnUrGTMgVyW
MvghYyySHepYp/5wQccxhBsN3HQgBtSaZrTSdi+1iHbj6r3o1//QRyB5zRnz
anRRGbQfDvD+vfyySb3KItTK16/5y7zzu5ff3yD//86u1f4gRp0+lWJaJLUq
jJqrPXGYLlwpkt3Q0dNSexStzzQOTCfaVfnSpLS+k9omnLLrNrnOco1l+5vj
ax0/pFacX1OJ+Bhm6kyoBHmL/h3GO2CvpnnIY1SqiChMiL3pK23tu6lfRL+r
osfjLeod9PNXNu0bEuWb6Vzx+0et/0bKHT/gJTM/pR8Q4vqH64dP8eqHASBK
W7rRTisn+5I82snzoS8uU3xgbWusoCN9WmX52N96zszlxeVf5hefzp8+vRqT
8ZD+PcYO820IAX/w07f5xZ+fDD/zWsKl9Kdwjx7GtveP8C32+f6qr7SFaTPZ
9j8elMxcMLOhcEdrxReXF08/I/Zlgr9QFJZ7/xE/0PvwQatCDZ4bjnZ68p1L
zLVMa7RCAvH33jxDwAOa4eMNvJalkGckWhWvPGeF9KZx/FWKfswz8yJBXOXH
b9ymMt8WTFkhRZaiwqTi2DAgqLI682TGEmTT7M23gPK1PH9b5PCl7wAW+PAa
sn9pu3TDfSFFgwianldAZtIeF/8zAWqaVxu7WsnTUp/5xpEoA6tEJ7djju0L
8xurv14ZS45avYqGjpLawbSkHCSDfTp3nsJukVIUk180/A+zMA8qrDwAAA==

-->

</rfc>
