<?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.6.14 (Ruby 3.1.2) -->
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc inline="yes"?>
<?rfc strict="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-richardson-opsawg-pcapng-extras-01" category="info" tocInclude="true" sortRefs="false" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.13.0 -->
  <front>
    <title abbrev="pcapng">Additional block types for PCAP Next Generation (pcapng) Capture File Format</title>
    <seriesInfo name="Internet-Draft" value="draft-richardson-opsawg-pcapng-extras-01"/>
    <author initials="M." surname="Tuexen" fullname="Michael Tuexen" role="editor">
      <organization abbrev="Muenster Univ. of Appl. Sciences">Muenster University of Applied Sciences</organization>
      <address>
        <postal>
          <street>Stegerwaldstrasse 39</street>
          <city>Steinfurt</city>
          <code>48565</code>
          <country>DE</country>
        </postal>
        <email>tuexen@fh-muenster.de</email>
      </address>
    </author>
    <author initials="F." surname="Risso" fullname="Fulvio Risso">
      <organization>Politecnico di Torino</organization>
      <address>
        <postal>
          <street>Corso Duca degli Abruzzi, 24</street>
          <city>Torino</city>
          <code>10129</code>
          <country>IT</country>
        </postal>
        <email>fulvio.risso@polito.it</email>
      </address>
    </author>
    <author initials="J." surname="Bongertz" fullname="Jasper Bongertz">
      <organization abbrev="Airbus DS CyberSecurity">Airbus Defence and Space CyberSecurity</organization>
      <address>
        <postal>
          <street>Kanzlei 63c</street>
          <city>Meerbusch</city>
          <code>40667</code>
          <country>DE</country>
        </postal>
        <email>jasper@packet-foo.com</email>
      </address>
    </author>
    <author initials="G." surname="Combs" fullname="Gerald Combs">
      <organization abbrev="Wireshark">Wireshark Foundation</organization>
      <address>
        <postal>
          <street>339 Madson Pl</street>
          <city>Davis</city>
          <region>CA</region>
          <code>95618</code>
          <country>US</country>
        </postal>
        <email>gerald@wireshark.org</email>
      </address>
    </author>
    <author initials="G." surname="Harris" fullname="Guy Harris">
      <organization/>
      <address>
        <email>gharris@sonic.net</email>
      </address>
    </author>
    <author initials="E." surname="Chaudron" fullname="Eelco Chaudron">
      <organization abbrev="Red Hat">Red Hat</organization>
      <address>
        <postal>
          <street>De Entree 238</street>
          <city>Amsterdam</city>
          <code>1101 EE</code>
          <country>NL</country>
        </postal>
        <email>eelco@redhat.com</email>
      </address>
    </author>
    <author initials="M." surname="Richardson" fullname="Michael C. Richardson">
      <organization abbrev="Sandelman">Sandelman Software Works</organization>
      <address>
        <email>mcr+ietf@sandelman.ca</email>
        <uri>http://www.sandelman.ca/</uri>
      </address>
    </author>
    <date year="2022" month="July" day="30"/>
    <abstract>
      <t>This document contains a number of extensions to the PCAPng file format which are outside of the IETF networking mandate.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the
  OPSAWG Working Group mailing list (opsawg@ietf.org),
  which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/opsawg/"/>.</t>
      <t>Source for this draft and an issue tracker can be found at
  <eref target="https://github.com/pcapng/pcapng"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction-to-additional-block-types">
      <name>Introduction to Additional Block Types</name>
      <t>TBD</t>
    </section>
    <section anchor="terminology">
      <name>Terminology</name>
      <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 in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
    </section>
    <section anchor="additional-block-types">
      <name>Additional Block Types</name>
      <section anchor="section_sdj_export">
        <name>systemd Journal Export Block</name>
        <t>The <eref target="https://www.freedesktop.org/wiki/Software/systemd/">systemd</eref>  <eref target="https://www.freedesktop.org/wiki/Software/systemd/export/">Journal Export Block</eref> is a lightweight container for systemd
Journal Export Format entry data.</t>
        <t>One of the primary components of the systemd System and
Service Manager is the "Journal", a message logging system that
uses arrays of key-value pairs. Journal entries are stored in a
database-like file on disk but can be serialized to easily
parseable "Journal Export Format" data or to a JSON object. The
block described here is limited to Journal Export Format data
only.</t>
        <t>A systemd Journal Export Block contains a single systemd
Journal Export Format entry. Each entry MUST contain a
__REALTIME_TIMESTAMP= field. If a timestamp for the block is
required it can be derived from this field. Each entry MUST be
zero-padded to 32 bits. Although the primary use of this block
is intended for importing data from systemd, it could
potentially be used to include arbitrary key-value data in a
capture file.</t>
        <t><xref target="format_sdj_export"/> shows the format of the
Journal Export Block.</t>
        <figure anchor="format_sdj_export">
          <name>systemd Journal Export Block Format</name>
          <artwork align="center"><![CDATA[
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 0 |                    Block Type = 0x00000009                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 4 |                      Block Total Length                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 8 /                                                               /
   /                         Journal Entry                         /
   /              variable length, padded to 32 bits               /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Block Total Length                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>The systemd Journal Export Block has the following fields:</t>
        <ul spacing="normal">
          <li>Block Type: The block type of the Journal Export Block is 9.</li>
          <li>Block Total Length: total size of this block, as described in <xref target="I-D.tuexen-opsawg-pcapng"/>, section "Section Blocks".</li>
          <li>Journal Entry: A journal entry as described in the <eref target="https://www.freedesktop.org/wiki/Software/systemd/export/">Journal Export Format</eref> documentation. Entries consist of a
series of field names followed by text or binary field data.
Common field names can be found in the <eref target="https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html">systemd.journal-fields</eref> documentation. The __REALTIME_TIMESTAMP= field MUST be
present and valid as described above. Entries are not
guaranteed to be a multiple of four octets and must be
zero-padded. This allows the length of the entry to be
determined by finding the last non-zero octet in the Journal
Entry data. An entry may contain an entry separator
(trailing newline) as described in the Journal Export Format
specification</li>
        </ul>
      </section>
      <section anchor="alternative-packet-blocks-experimental">
        <name>Alternative Packet Blocks (experimental)</name>
        <t>Can some other packet blocks (besides the ones described in the
previous paragraphs) be useful?</t>
      </section>
      <section anchor="compression-block-experimental">
        <name>Compression Block (experimental)</name>
        <t>The Compression Block is optional. A file can contain an arbitrary
number of these blocks. A Compression Block, as the name says, is used
to store compressed data. Its format is shown in <xref target="formatcb"/>.</t>
        <figure anchor="formatcb">
          <name>Compression Block Format</name>
          <artwork align="left"><![CDATA[
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 0 |                        Block Type = ?                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 4 |                      Block Total Length                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 8 |  Compr. Type  |                                               /
   +-+-+-+-+-+-+-+-+                                               /
   /                                                               /
   /                       Compressed Data                         /
   /                                                               /
   /  variable length, octet-aligned and padded to end on a 32-bit /
   /                         boundary                              /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Block Total Length                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>The fields have the following meaning:</t>
        <ul spacing="normal">
          <li>Block Type: The block type of the Compression Block is not yet
assigned.</li>
          <li>Block Total Length: total size of this block, as described in <xref target="I-D.tuexen-opsawg-pcapng"/>, section "Section Blocks".</li>
          <li>Compression Type (8 bits): an unsigned value that
specifies the compression algorithm.  Possible values for
this field are 0 (uncompressed), 1 (Lempel-Ziv), 2 (Gzip),
other?? Probably some kind of dumb and fast compression
algorithm could be effective with some types of traffic (for
example web), but which?</li>
          <li>Compressed Data: data of this block. Once decompressed, it is
made of other blocks.</li>
        </ul>
      </section>
      <section anchor="encryption-block-experimental">
        <name>Encryption Block (experimental)</name>
        <t>The Encryption Block is optional. A file can contain an arbitrary
number of these blocks. An Encryption Block is used to store encrypted
data. Its format is shown in <xref target="formateb"/>.</t>
        <figure anchor="formateb">
          <name>Encryption Block Format</name>
          <artwork align="left"><![CDATA[
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 0 |                        Block Type = ?                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 4 |                      Block Total Length                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 8 |   Encr. Type  |                                               /
   +-+-+-+-+-+-+-+-+                                               /
   /                                                               /
   /                       Encrypted Data                          /
   /                                                               /
   /                 variable length, octet-aligned                /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Block Total Length                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>The fields have the following meaning:</t>
        <ul spacing="normal">
          <li>Block Type: The block type of the Encryption Block is not yet
assigned.</li>
          <li>Block Total Length: total size of this block, as described in <xref target="I-D.tuexen-opsawg-pcapng"/>, section "Section Blocks".</li>
          <li>Encryption Type (8 bits): an unsigned value that
specifies the encryption algorithm.  Possible values for
this field are ??? (TODO) NOTE: this block should probably
contain other fields, depending on the encryption algorithm.
To be defined precisely.</li>
          <li>Encrypted Data: data of this block. Once decrypted, it
originates other blocks.</li>
        </ul>
      </section>
      <section anchor="fixed-length-block-experimental">
        <name>Fixed Length Block (experimental)</name>
        <t>The Fixed Length Block is optional. A file can contain an arbitrary
number of these blocks. A Fixed Length Block can be used to optimize
the access to the file. Its format is shown in <xref target="formatflm"/>. A Fixed Length Block stores records with
constant size. It contains a set of Blocks (normally Enhanced Packet
Blocks or Simple Packet Blocks), of which it specifies the size.
Knowing this size a priori helps to scan the file and to load some
portions of it without truncating a block, and is particularly useful
with cell-based networks like ATM.</t>
        <figure anchor="formatflm">
          <name>Fixed Length Block Format</name>
          <artwork align="left"><![CDATA[
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 0 |                        Block Type = ?                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 4 |                      Block Total Length                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 8 |          Cell Size            |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
   /                                                               /
   /                        Fixed Size Data                        /
   /                                                               /
   /                 variable length, octet-aligned                /
   /                                                               /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Block Total Length                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        </figure>
        <t>The fields have the following meaning:</t>
        <ul spacing="normal">
          <li>Block Type: The block type of the Fixed Length Block is not yet
assigned.</li>
          <li>Block Total Length: total size of this block, as described in <xref target="I-D.tuexen-opsawg-pcapng"/>, section "Section Blocks".</li>
          <li>Cell size (16 bits): an unsigned value that indicates the
size of the blocks contained in the data field.</li>
          <li>Fixed Size Data: data of this block.</li>
        </ul>
      </section>
      <section anchor="directory-block-experimental">
        <name>Directory Block (experimental)</name>
        <t>If present, this block contains the following information:</t>
        <ul spacing="normal">
          <li>number of indexed packets (N)</li>
          <li>table with position and length of any indexed packet (N
entries)</li>
        </ul>
        <t>A directory block MUST be followed by at least N packets, otherwise
it MUST be considered invalid. It can be used to efficiently load
portions of the file to memory and to support operations on memory
mapped files. This block can be added by tools like network analyzers
as a consequence of file processing.</t>
      </section>
      <section anchor="traffic-statistics-and-monitoring-blocks-experimental">
        <name>Traffic Statistics and Monitoring Blocks (experimental)</name>
        <t>One or more blocks could be defined to contain network statistics
or traffic monitoring information. They could be use to store data
collected from RMON or Netflow probes, or from other network
monitoring tools.</t>
      </section>
      <section anchor="eventsecurity-block-experimental">
        <name>Event/Security Block (experimental)</name>
        <t>This block could be used to store events. Events could contain
generic information (for example network load over 50%, server
down...) or security alerts. An event could be:</t>
        <ul spacing="normal">
          <li>skipped, if the application doesn't know how to do with it</li>
          <li>processed independently by the packets. In other words, the
applications skips the packets and processes only the alerts</li>
          <li>processed in relation to packets: for example, a security tool
could load only the packets of the file that are near a security
alert; a monitoring tool could skip the packets captured while the
server was down.</li>
        </ul>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>TBD.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>TBD.</t>
      <t>[Open issue: decide whether the block types, option types, NRB Record
types, etc. should be IANA registries. And if so, what the IANA policy
for each should be (see RFC 5226)]</t>
    </section>
    <section anchor="contributors">
      <name>Contributors</name>
      <t>Loris Degioanni and Gianluca Varenni were coauthoring this document
before it was submitted to the IETF.</t>
    </section>
    <section anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>The authors wish to thank
Anders Broman,
Ulf Lamping,
Richard Sharpe
and many others for their invaluable comments.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="I-D.tuexen-opsawg-pcapng">
          <front>
            <title>PCAP Next Generation (pcapng) Capture File Format</title>
            <author fullname="Michael Tuexen">
              <organization>Muenster University of Applied Sciences</organization>
            </author>
            <author fullname="Fulvio Risso">
              <organization>Politecnico di Torino</organization>
            </author>
            <author fullname="Jasper Bongertz">
              <organization>Airbus Defence and Space CyberSecurity</organization>
            </author>
            <author fullname="Gerald Combs">
              <organization>Wireshark Foundation</organization>
            </author>
            <author fullname="Guy Harris">
	 </author>
            <author fullname="Eelco Chaudron">
              <organization>Red Hat</organization>
            </author>
            <author fullname="Michael C. Richardson">
              <organization>Sandelman Software Works</organization>
            </author>
            <date day="4" month="October" year="2021"/>
            <abstract>
              <t>   This document describes a format to record captured packets to a
   file.  This format is extensible; Wireshark can currently read and
   write it, and libpcap can currently read some pcapng files.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-tuexen-opsawg-pcapng-04"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date month="March" year="1997"/>
            <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="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="LINKTYPES" target="http://www.tcpdump.org/linktypes.html">
          <front>
            <title>the tcpdump.org link-layer header types registry</title>
            <author fullname="">
              <organization>The Tcpdump Group</organization>
            </author>
            <date/>
          </front>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+1b63LbOJb+z6fAOrUVe8aSb0k69lZXothK2t2+raXs1Gzv
VAoiIQltkuAApBUlnXmWfZZ9sv3OAUhRtuxOepLeVG8rVY4IAgfnfj5c1Ol0
IlfKPHkjU5OrA1HaSkW6sPzNlbvb2/vbu1Fi4lxmeJ1YOS47VsdTaRNn8o4p
nJxNOkUsi3zSUW9LK11neyeKZXkgdD42UaEPIiHcPLNq7A7Ew7lyD9FQmnjx
EJuskHG5aHDVaNGWG2rSeaqJw6aLsWUg6Tu4Enw1NEpdpujdSxJdapPLVIxS
E1+Jcl4oJ8bGiovD3oU4A8vilcqVldRNrHtJNsShLMrKKvFSp/hjbCbLSI5G
Vl0fCN8nklU5NfYg6ghraC6FqYxlVsHVaVcMK/VW5Wjwyjsltal00WzsBK2V
yl2prHid62tlnS7nwoxFryhSrRIxiLXKY+XQvZ5+aUS37txtd4UulIIuBqWa
KDuTaeLIMk6JvX3Wd0KafPT08ZPHrH9Myp1hscqW3KPKS4vGoz6eVCZ1Cpdg
xp+Pp50ssNBNFMRneV92xaV2zjTivqzSa22aRhb2wqS6VHGuYyMSLYbG6ty0
+D001hlxVMVSJGqSatEb2erdO70pdh81fDajghg72zu7+w/bTB8PF0yPmY2u
JTaeFzS/6eqy5vr7rnhhcuiofNcw/r10BbTbamfee9qOKieO1Ji0LBA0YgAP
VeJwPlJ2oOLKgr2WneoBg1s9anF/kPm7VGnxZC9uWWX7yZNvFlY5VYrIxNO7
rPITs/scrFypsjM2povQqeV71YVOs5FrhHsFT0+TppEl+4u2yiGir+DoVZ5w
JLTkaF63ON/b2xenklKAuEgbXo/ktSaqVk1AAubsLcTaf/xk5+mSlV4PFkJM
mK3ns3qqLhhryfCdtFa3hKjmiyYW4eHDFq0pv3oO5nTczVVj7D6UMZVVYs0i
KPsqhS+2mpncJSLvO1m2lLBoqVVwpEQ/p+9id+9pI+cOvFH0+41KehnFSSKz
tuRnJwtuFTHw3KpkKsu25U4pnuo8eyuHHN54y1wP4JMqzWQuBmZcziTS11+M
vWrnjqbLgoEstn/Wqhw/d/W7bizxGs56IKZlWRxsbc1ms2779VYU5ZwTkbIo
vR93jro+OyxXhIMooiLQ6nlyfPbD8K8X/QE9oAxIOyFltuYp4yKpsoI8YAsp
/4ozdndaZqkf4RN7OVWi1VNQz04q5wjcqZIJ/vOZnlwRFpvz2Dpj0/egZnYc
+nj9No+s0CEmGfpJxCtrqoJfIkDQcyxTp6Ko0+lAuZRd4zKKhlPtBKpllam8
hL3zUmIWIUVeZUgBlKtRcJA7ER4ONZDFoEKUT8SYKo3XlZhNYVxBBjRV6XSi
aCT1Pe4PXwq49Ax21RgEcxA7Xc9IppMkBVMPxDEczSRVzEUN87Tq4Auug0PS
Dhh+cUTdh8pmyKmpmcxJCCWu1FxgjsSJtdPXg+Hapv9fnJ3z98v+v78+vuwf
0ffBd72Tk+ZLFHoMvjt/fXK0+LYYeXh+eto/O/KD0SqWmqK1095f8YbS69r5
xfD4/Kx3sgZbQfy2bkk3kGuk8AoBVlhVIkKlixLlYqtHeMCYF4cX//PfO4/E
+/f/cvnycHdnZ//Dh/DwdOebR3iYTVXuZzN5Og+P0PQ8kkWhpCUqMk0F3FmX
MDn6OuGmZpbDzywpHuq7S7sPHgD4IP6zRHxvKkvv+28LAJfQ7f0Dp9hEb1zy
0xvFrz54A/wYBv5tnULDhdgYI91AwKvS+PiY6Su9VQf7VhiytSHEj6vm+zW0
PFMgqcmNUz2ZljNFf2vvhlcTmgr9oxvzeuQkFOU9ChwJhZ3njTsXVmcSbwjs
AX/mpavf1Hob8P9koGig7LVGvT2VuUS9II6o51qYkpxGZMo5vBTw5AnFhyeD
fkjdlUM+QGmQc54FLt65lmkFLqS2rtuYiJjV3BVsANF5V5IRsT+STnVSfaV8
uCK4Eu2uxKiCPpB34Y5OWS1T/Q6j4J9KOp3Oo0Jap+QoXXC7rKA11g2SDo2R
4vvB+Zkwo5/gHF1KQpHHrgvXJtcj+VOd6dLPtFrxRDYiz4bee/c7YytbOagu
VR9j067oS2Qqb1/OEIEM9PXmzWW/dzI8Pu2/oT+DYe/04lvoTaVJVxyPMU+p
Ya9SIruSC5ExvaCo61b9vdKs+kazSOooIokYW5P5bBBo3WRhpKJ3yppOIZPE
K2dvV4x0CRv3UlSAajJd8j44hnc7kGQGInyhtJLTcGJNZyQ5ORTbiTkI2tlk
Dk2VJlFhMKSE9ZFIwC/I8uQ6j9MKKVxa8GBpwoXrMTnWVhwWHORXMNb7974U
tDPDB0483utDofDRctNCbFBKTf/AJxS025+dFW27K9r2mMI2+u+KPfFIPBZP
xDfiqdj/lDai8efOP/kvAqWfV4myyLriW7H9dtt/9ld1/fkzcfJoNScNLwbV
QpyofFJO79D/5+Lkqdi6Y4aP/WwRJ3cTabyLQ+xTiFxLJENKeykrYlPcCslP
4+TjPlufSbHiazExh/H7A/HgVk7wcPjbh/dmdp+wHyIBMW7soDxN8m/XYkXI
aS0AjnspTGWdddLUzDSjVaReB3z/p1bwecS82Gipi/lKmsix+93W+JY2Ae/5
yaGMLmdmhl9LEO/9+7sWHx8+bIqAr4BCwxeezK3xxEt+jaWa+KmFAOa3ZiJJ
buIqr9p/CljVkJaX3V1mhtAH6qjDyoXEp9UYwQrFuIU1z8sVF+wB9kZzUdJW
FmrVSOdUY3w3D7kErfczSN8eG6rqmJb8jXiBu27QRMeb+X753E3RsCjZWk2I
l3G3RCanuQcsNEVdoGIrx+gfLKOA6mTZSHJkrtVChQTgckNr9kklrYS3+9QD
qYEUq7TURcr+BR1gbRaXCvmISGcVFM8TtnAE8UkgmDTuo8EntdrJvdMweQxM
sB6hNZW3zVjnCUUNj5Ignpu8Q7T9rLX6g3NheH8BmEUvD7QzOV/Aq7rRKYBL
6Tce1wEvdEoT5WpG26UbK514pQ+TjxUq1mMd+w2giNcvAEwKnWn5Li54iymE
kFiHB8Mp2Y7pRhQdgiVnMigUc1jh96N81KLzSNEy1usNSP82VxFse61N5QTJ
M7GymLqNAKPGVfrMswM/Jh9wTSjfYoOc6XYvGM4UfokGhXrwTgHQUmcDz6LF
Yh18uZDQCDzeJsz5iGSimBIOS4tNmougXwRX4OUDr25olArxKI5LVwM4Xa8m
OZX5xnj04cP/J/TWKqkewT27q9fvEr39LLxfdb34d+vojs9quPNriHxRHHm4
iIIjWvX8JpzcAqCcbz0CooKBZL+ApIp3gVAb9nY7yAW/xMmIN8vvQcSfWZzP
4GxfK6KNRzWQvZ2670CvqRqXNXb14AIoFUVqGaZmSuaa96E/BqeurBtAEGKu
+CwAb8ht/m9Ra5tJThjrT3kltXFAVazKPY/C7y/wxldT2UP9jVsUZDoxVpfT
rCvEhUEbBQuP5RJFJ7XNTgsDqm2xXuWLiraxiYqxfqKyQqWd/9TXeN4V66/e
6WJjk84lCAs8eyYurBkhDuceIVxpirSxSFBoOQbHhIlabJGya8b85gohATUe
kz5g5BleeFJ+l5+0beUY2EWse67VW5kRupupEVii/TneU3/W1mDIRAdh861t
sa44p0O+RC0k5Y0ePnHKpN+Q90AnoIOAl/p5bOdFeT8+udXp88CTfCXhehvK
YxHlewCefBQUUX9Akbs+v1Mowj70O4ci/ToI7kciX5STX0AmX4yTz+AnXyuK
UA2KuJUHf0MQsSoHf20YosXjr4MQakHgkxHEM+CB9eH50fkGHQr3D1pCUgGi
Yl8EuMCXJnwJ9MXWG2kTiiiU31Ix+d0MYfjQ+KOjMW/FoJTH2ik+DvvTjTRw
PwzwHQkD8G0LPdE5HM6txAAv9VvQDAFwNwpY0e0zbVOsoBx2+2owQLNk8LGI
dCfjGAinvo7AB1C/hAvGaQZgsHoqBhp08yLmCwSE1SLazSxlXrJjE/Wl40bF
25z1vhLfLKEztH4+lVB/EjaeotDBWDHQDO6WNqQA80DE35wAUlv2V542+iH3
Ac0G5hCTdAgIc4qpSgtWgSNN1XpgcIrG1MiE8WbE54B0eQNzYRYSzgBclhag
WPIJoWzilfZVeTur1HGVSpvOw2ZWxPg1VmnaoQPlpL7RQQe6V0r0hqd/YK4v
WTe+OswVPofwCPg2/LI9053a+BROfoHIl8dcIVOwdPehrt8j5voDuN3g5AZw
QzWpkduKevIbYrfVJflrQ2+cJniO9Z0n9wM3QQdPMSMVOmMRLdZqwNBc5GrO
h/wdF75bQ9PdCNyVOCkgnyONqo/yP78D9hyP6yO8zTbqa7DAsu2aq6MmZ/st
AA+kUsSUP2QCZjjboA4lBzcX18I47dEgqvDioE7m8xuDMZa2i/yRIahEPZE0
Unj2wvnj0mkrVJsq2rU6q5nY9FhwBnwZARnUg/gcN1H+FhmfWXr4s4zHFO1d
aXABjEBgYwlnNGgEHTOVEWMBl7iq4CM8U4QfMDjCw75PlNENxoRHunB4OWpj
Qb/vTSfHxqQBegQgAvoynb9T1kWSEBoJof5e8cV3PoJO6faUIdgIQ3W98Ydh
B25A57oOmMcfpp6anH4XQQa94+SQLwRakdH+VOOTYc+vRu4QtgbBNY+umSei
22Nh9mwxXct/+JB5viBLV76aPTG+JBfDuLB6fb/s8pSu4FlxppCdzIxXJIps
bP17j/sDK1FrUlZm0Ej/GiJu1Rf/71wKtOJgwV57z47IwIRMrtZN0EY0oR+v
QO6WsLwH2uyA1upiDGuuwfXj7X+lDGPxPUoA7Lvd7gYJ5mpGZaps6XcUee6G
MQ5Dd6XJsbAW8q4p6acq/tBYJEa5/GEproC0BRYNJERifEhi6YTRwW04HPwq
zns9+SHdyfPBhBipl3x8DXkzpK/WXI4Zce1R/jwnTOD8jV7mkOW5OTtWKKms
L0gHCgeipbpNXpsEnZBd/R1+aMLrsiZfz74UqpR8+QICXSJe0OGdbXDzb3QF
YdlrAm2SaolsuBmY0NqGKSt/H4RMOaOyQiaMOAOLxtcOQ9rxquKL3v6u8nHv
rHfH2//68Rz2QMVzFf3WC+unRNGNaDZDuVQwKRL8ajs8nV2+EJe84otCiyrj
br2eh0vzvOE2vlbsXAl5kDObmAPK4uvt1Il+pBPPIzYE3exc0Fh3SonLl4fi
8e7uk42/kTiQBPRGFfQIOU6gTfqJzkQbmeea/eGVlnlKvyj6D5iDGmeKz+T9
jwGa5WB9JyUaqTEFHS3u6Kp3Ncp0Ge7Y1jfww63vmLw8VcmExjmPRDxVWvW6
qR8i86sIsiKXihfIHDLfjF6nY3ECF8Pkm1H4HYcY4G+hIr5/QmWKvd/VN2O1
9eWj4hIXm4znJEb+Fx/WKxjENwAA

-->

</rfc>
