<?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.22 (Ruby 3.1.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-boucla-opsawg-ipfix-fixes-04" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.16.0 -->
  <front>
    <title abbrev="IPFIX IANA Fixes">Simple Fixes to the IP Flow Information Export (IPFIX) IANA Registry</title>
    <seriesInfo name="Internet-Draft" value="draft-boucla-opsawg-ipfix-fixes-04"/>
    <author fullname="Mohamed Boucadair">
      <organization>Orange</organization>
      <address>
        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>
    <author fullname="Benoit Claise">
      <organization>Huawei</organization>
      <address>
        <email>benoit.claise@huawei.com</email>
      </address>
    </author>
    <date year="2023" month="February" day="07"/>
    <area>Operations and Management</area>
    <workgroup>OPSAWG</workgroup>
    <keyword>IPFIX</keyword>
    <abstract>
      <t>This document describes simple fixes to the IANA IP Flow Information Export (IPFIX) registry. These fixes are mainly updates to point to newer IANA registries and also updates to the description of some Information Elements (IEs).</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the
    Operations and Management Area Working Group 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/boucadair/simple-ipfix-fixes"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>As the OPSAWG is currently considering <xref target="I-D.boucadair-opsawg-rfc7125-update"/> that updates <xref target="RFC7125"/>, the WG realized that some other parts of the IANA IPFIX registry <xref target="IANA-IPFIX"/> were not up-to-date. Indeed, since its initial creation in 2007, some IPFIX Information Elements (IEs) are not adequately specified any longer (while they were at some point in time in the past). This document intends to update the IANA registry and bringing some consistency among the entries of the registry.</t>
      <t>As discussed with IANA, the "Additional Information" entry in <xref target="IANA-IPFIX"/> should contain a link to the existing registry, when applicable, as opposed to having:</t>
      <ul spacing="normal">
        <li>A link to an exiting registry in the "Description" entry.</li>
        <li>The registry detailed values repeated in the "Description" entry. This solution has the drawback that the description must be updated each time the registry is updated.</li>
      </ul>
      <t>Therefore, this document lists a set of simple fixes to the IPFIX IANA registry <xref target="IANA-IPFIX"/>. These fixes are classified as follows:</t>
      <ul spacing="normal">
        <li>Updates that fix a shortcoming in the description of an IE (<xref target="desc"/>).</li>
        <li>Updates that require adding a pointer to an existing IANA registry (<xref target="to-iana"/>).</li>
        <li>Updates that are meant to ensure a consistent structure when calling an existing IANA registry (<xref target="consistent"/>).</li>
        <li>Miscellaneous updates that fix broken pointers, orphan section references, etc. (<xref target="misc"/>).</li>
      </ul>
      <t>These updates are also meant to facilitate the automatic extraction of the values maintained in IANA registries (e.g., with a cron job), required by Collectors to be able to support new IPFIX IEs and, more importantly, adequately interpret new values in registries specified by those IPFIX IEs.</t>
      <t>Note that, as per <xref section="5" sectionFormat="of" target="RFC7012"/>, <xref target="IANA-IPFIX"/> is the normative reference for the IPFIX IEs that were defined in <xref target="RFC5102"/>. Therefore, the updates in this document do not update any part of <xref target="RFC7011"/>.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" 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>
      <t>This document uses the IPFIX-specific terminology (Information Element, Template,
   Collector,  Data Record, Flow Record, Exporting Process,
   Collecting Process, etc.) defined in
   Section 2 of <xref target="RFC7011"/>. As in <xref target="RFC7011"/>, these IPFIX-specific terms
   have the first letter of a word capitalized.</t>
    </section>
    <section anchor="why-a-document-is-needed-for-these-updates">
      <name>Why A Document is Needed for These Updates?</name>
      <t>Many of the edits in this document may be handled by the IPFIX Design Experts. However, and given that many of the impacted IEs were created via the IETF stream, the following from Section 5.1 of <xref target="RFC7013"/> should be followed:</t>
      <ul empty="true">
        <li>
          <t>This process should not in any way be construed as allowing the IE-DOCTORS to overrule IETF consensus.  Specifically, Information Elements in the IANA IE registry that were added with IETF consensus require IETF consensus for revision or deprecation.</t>
        </li>
      </ul>
    </section>
    <section anchor="desc">
      <name>Update the Description</name>
      <t>The IEs listed in the following subsections cannot echo some values that can be seen in a packet.</t>
      <section anchor="ipv6extensionheaders-information-element">
        <name>ipv6ExtensionHeaders Information Element</name>
        <section anchor="issues">
          <name>Issues</name>
          <t>The current specification of ipv6ExtensionHeaders Information Element should be updated to:</t>
          <ul spacing="normal">
            <li>Reflect missing IPv6 EHs, specifically 139, 140, 253, and 254.</li>
            <li>Specify how to automatically update the registry when a new value is assigned in <xref target="IPv6-EH"/>.</li>
            <li>Specify the procedure to follow when all bits are exhausted.</li>
          </ul>
          <t>The following section proposes a fix for the first two issues. A companion document [I-D.boucadair-opsawg-ipfix-tcpo-v6eh] specifies a new option to fix the last issue.</t>
        </section>
        <section anchor="updates-to-the-ipv6extensionheaders-description">
          <name>Updates to the ipv6ExtensionHeaders Description</name>
          <section anchor="old">
            <name>OLD</name>
            <artwork><![CDATA[
   Description:
      IPv6 extension headers observed in packets of this Flow.  The
      information is encoded in a set of bit fields.  For each IPv6
      option header, there is a bit in this set.  The bit is set to 1 if
      any observed packet of this Flow contains the corresponding IPv6
      extension header.  Otherwise, if no observed packet of this Flow
      contained the respective IPv6 extension header, the value of the
      corresponding bit is 0.

               0     1     2     3     4     5     6     7
           +-----+-----+-----+-----+-----+-----+-----+-----+
           | DST | HOP | Res | UNK |FRA0 | RH  |FRA1 | Res |  ...
           +-----+-----+-----+-----+-----+-----+-----+-----+

               8     9    10    11    12    13    14    15
           +-----+-----+-----+-----+-----+-----+-----+-----+
       ... |           Reserved    | MOB | ESP | AH  | PAY | ...
           +-----+-----+-----+-----+-----+-----+-----+-----+

              16    17    18    19    20    21    22    23
           +-----+-----+-----+-----+-----+-----+-----+-----+
       ... |                  Reserved                     | ...
           +-----+-----+-----+-----+-----+-----+-----+-----+

              24    25    26    27    28    29    30    31
           +-----+-----+-----+-----+-----+-----+-----+-----+
       ... |                  Reserved                     |
           +-----+-----+-----+-----+-----+-----+-----+-----+

       Bit    IPv6 Option   Description

       0, DST      60       Destination option header
       1, HOP       0       Hop-by-hop option header
       2, Res               Reserved
       3, UNK               Unknown Layer 4 header
                            (compressed, encrypted, not supported)
       4, FRA0     44       Fragment header - first fragment
       5, RH       43       Routing header
       6, FRA1     44       Fragmentation header - not first fragment
       7, Res               Reserved
       8 to 11              Reserved
       12, MOB     135      IPv6 mobility [RFC3775]
       13, ESP      50      Encrypted security payload
       14, AH       51      Authentication Header
       15, PAY     108      Payload compression header
       16 to 31             Reserved

   Abstract Data Type: unsigned32
   Data Type Semantics: flags
   ElementId: 64
   Status: current
   Reference: [RFC5102]
   Additional Information:
      See [RFC8200] for the general definition of IPv6 extension headers
      and for the specification of the hop-by-hop options header, the
      routing header, the fragment header, and the destination options
      header. See [RFC4302] for the specification of the authentication
      header. See [RFC4303] for the specification of the encapsulating
      security payload. The diagram provided in [RFC5102] is incorrect.
      The diagram in this registry is taken from Errata 1738.
      See [RFC Errata 1738].
]]></artwork>
          </section>
          <section anchor="new">
            <name>NEW</name>
            <artwork><![CDATA[
   Description:
      IPv6 extension headers observed in packets of this Flow. The
      information is encoded in a set of bit fields.  For each IPv6
      option header, there is a bit in this set.  The bit is set to 1 if
      any observed packet of this Flow contains the corresponding IPv6
      extension header.  Otherwise, if no observed packet of this Flow
      contained the respective IPv6 extension header, the value of the
      corresponding bit is 0. The IPv6 EH associated with each bit
      is provided in  [NEW_IPFIX_IPv6EH_SUBREGISTRY]. This IE is used
      only when when the observed extension headers are in the 0-31
      range. If the observed EHs exceeds that range,
      ipv6ExtensionHeadersFull Information Element MUST be used.
   Abstract Data Type: unsigned32
   Data Type Semantics: flags
   ElementId: 64
   Status: current
   Reference: [RFC5102][This-Document]
   Additional Information:
      See the assigned bits to each IPv6 extension header in
      [NEW_IPFIX_IPv6EH_SUBREGISTRY].
      See [RFC8200] for the general definition of IPv6 extension headers
      and [IPv6-EH] for assigned extension headers.
]]></artwork>
          </section>
        </section>
      </section>
      <section anchor="tcpoptions">
        <name>tcpOptions</name>
        <section anchor="issues-1">
          <name>Issues</name>
          <t>Only options having a kind =&lt; 63 can be included in a tcpOptions IE. An update is thus required to specify how any observed TCP option in a packet can be exported using IPFIX. Also, there is no way to report the observed Experimental Identifiers (ExIDs) that are carried in shared TCP options (kind=253 or 254) <xref target="RFC6994"/>.</t>
        </section>
        <section anchor="update-the-description-of-the-tcpoptions-ie">
          <name>Update the Description of the tcpOptions IE</name>
          <t>This document requests IANA to update the description of the tcpOptions IE in the IANA IPFIX registry <xref target="IANA-IPFIX"/> as follows.</t>
          <section anchor="old-description">
            <name>OLD Description</name>
            <t>TCP options in packets of this Flow.  The information is encoded
      in a set of bit fields.  For each TCP option, there is a bit in
      this set.  The bit is set to 1 if any observed packet of this Flow
      contains the corresponding TCP option.  Otherwise, if no observed
      packet of this Flow contained the respective TCP option, the value
      of the corresponding bit is 0.
      Options are mapped to bits according to their option numbers.
      Option number X is mapped to bit X.  TCP option numbers are
      maintained by IANA.</t>
            <artwork><![CDATA[
            0     1     2     3     4     5     6     7
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |   7 |   6 |   5 |   4 |   3 |   2 |   1 |   0 |  ...
        +-----+-----+-----+-----+-----+-----+-----+-----+

            8     9    10    11    12    13    14    15
        +-----+-----+-----+-----+-----+-----+-----+-----+
    ... |  15 |  14 |  13 |  12 |  11 |  10 |   9 |   8 |...
        +-----+-----+-----+-----+-----+-----+-----+-----+

           16    17    18    19    20    21    22    23
        +-----+-----+-----+-----+-----+-----+-----+-----+
    ... |  23 |  22 |  21 |  20 |  19 |  18 |  17 |  16 |...
        +-----+-----+-----+-----+-----+-----+-----+-----+

                              . . .

           56    57    58    59    60    61    62    63
        +-----+-----+-----+-----+-----+-----+-----+-----+
    ... |  63 |  62 |  61 |  60 |  59 |  58 |  57 |  56 |
        +-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
          </section>
          <section anchor="new-description">
            <name>NEW Description</name>
            <t>TCP options in packets of this Flow.  The information is encoded
      in a set of bit fields.  For each TCP option, there is a bit in
      this set.  The bit is set to 1 if any observed packet of this Flow
      contains the corresponding TCP option.  Otherwise, if no observed
      packet of this Flow contained the respective TCP option, the value
      of the corresponding bit is 0.
      Options are mapped to bits according to their option numbers.
      Option number X is mapped to bit X.  TCP option numbers are
      maintained by IANA. This information element is used only
      when the observed kinds are within the 0-63 range. If not, the tcpOptionsFull IE <bcp14>MUST</bcp14> be used.</t>
            <artwork><![CDATA[
            0     1     2     3     4     5     6     7
        +-----+-----+-----+-----+-----+-----+-----+-----+
        |   7 |   6 |   5 |   4 |   3 |   2 |   1 |   0 |  ...
        +-----+-----+-----+-----+-----+-----+-----+-----+

            8     9    10    11    12    13    14    15
        +-----+-----+-----+-----+-----+-----+-----+-----+
    ... |  15 |  14 |  13 |  12 |  11 |  10 |   9 |   8 |...
        +-----+-----+-----+-----+-----+-----+-----+-----+

           16    17    18    19    20    21    22    23
        +-----+-----+-----+-----+-----+-----+-----+-----+
    ... |  23 |  22 |  21 |  20 |  19 |  18 |  17 |  16 |...
        +-----+-----+-----+-----+-----+-----+-----+-----+

                              . . .

           56    57    58    59    60    61    62    63
        +-----+-----+-----+-----+-----+-----+-----+-----+
    ... |  63 |  62 |  61 |  60 |  59 |  58 |  57 |  56 |
        +-----+-----+-----+-----+-----+-----+-----+-----+
]]></artwork>
          </section>
        </section>
      </section>
    </section>
    <section anchor="to-iana">
      <name>Point to An Existing IANA Registry</name>
      <t>This document requests IANA to update the following entries by adding the indicated "Additional Information" to the <xref target="IANA-IPFIX"/> registry:</t>
      <table>
        <name>Cite an IANA Registry under Additional Information</name>
        <thead>
          <tr>
            <th align="left">IE</th>
            <th align="left">Additional Information</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">icmpTypeCodeIPv4</td>
            <td align="left">https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml</td>
          </tr>
          <tr>
            <td align="left">igmpType</td>
            <td align="left">https://www.iana.org/assignments/igmp-type-numbers/igmp-type-numbers.xhtml#igmp-type-numbers-1</td>
          </tr>
          <tr>
            <td align="left">icmpTypeCodeIPv6</td>
            <td align="left">https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml</td>
          </tr>
          <tr>
            <td align="left">icmpTypeIPv4</td>
            <td align="left">https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#icmp-parameters-types</td>
          </tr>
          <tr>
            <td align="left">icmpCodeIPv4</td>
            <td align="left">https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#icmp-parameters-codes</td>
          </tr>
          <tr>
            <td align="left">icmpTypeIPv6</td>
            <td align="left">https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-2</td>
          </tr>
          <tr>
            <td align="left">icmpCodeIPv6</td>
            <td align="left">https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-3</td>
          </tr>
          <tr>
            <td align="left">privateEnterpriseNumber</td>
            <td align="left">https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="consistent">
      <name>Consistent Citation of Registries</name>
      <t>This document requests IANA to update <xref target="IANA-IPFIX"/> for each of the IE entries listed in the following subsections.</t>
      <section anchor="mplstoplabeltype">
        <name>mplsTopLabelType</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: This field identifies the control protocol that allocated the top-of-stack label. Values for this field are listed in the MPLS label type registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mpls-label-type.</li>
              <li>Additional Information: See <xref target="RFC3031"/> for the MPLS label structure. See the list of MPLS label types assigned by IANA at [https://www.iana.org/assignments/mpls-label-values].</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: This field identifies the control protocol that allocated the top-of-stack label. Values for this field are listed in the MPLS label type registry.</li>
              <li>Additional Information: See the list of MPLS label types assigned by IANA at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mpls-label-type]. See <xref target="RFC3031"/> for the MPLS label structure.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="forwardingstatus">
        <name>forwardingStatus</name>
        <ul spacing="normal">
          <li>OLD:</li>
        </ul>
        <artwork><![CDATA[
   - Description:  This Information Element describes the forwarding
                   status of the flow and any attached reasons.

                   The layout of the encoding is as follows:

                   MSB  -  0   1   2   3   4   5   6   7  -  LSB
                         +---+---+---+---+---+---+---+---+
                         | Status|  Reason code or flags |
                         +---+---+---+---+---+---+---+---+

                   See the Forwarding Status sub-registries at
                   https://www.iana.org/assignments/ipfix/ipfix.xhtml#forwarding-status.

                   Examples:

                   value : 0x40 = 64
                   binary: 01000000
                   decode: 01        -> Forward
                             000000  -> No further information

                   value : 0x89 = 137
                   binary: 10001001
                   decode: 10        -> Drop
                             001001  -> Bad TTL

   - Additional Information: See "NetFlow Version 9 Flow-Record Format"
             [CCO-NF9FMT].
]]></artwork>
        <ul spacing="normal">
          <li>NEW:</li>
        </ul>
        <artwork><![CDATA[
   - Description:  This Information Element describes the forwarding
                   status of the flow and any attached reasons.

                   The layout of the encoding is as follows:

                   MSB  -  0   1   2   3   4   5   6   7  -  LSB
                         +---+---+---+---+---+---+---+---+
                         | Status|  Reason code or flags |
                         +---+---+---+---+---+---+---+---+

                   Examples:

                   value : 0x40 = 64
                   binary: 01000000
                   decode: 01        -> Forward
                             000000  -> No further information

                   value : 0x89 = 137
                   binary: 10001001
                   decode: 10        -> Drop
                             001001  -> Bad TTL

   - Additional Information: See the Forwarding Status sub-registries
       at https://www.iana.org/assignments/ipfix/ipfix.xhtml#forwarding-status.
]]></artwork>
      </section>
      <section anchor="classificationengineid">
        <name>classificationEngineId</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description:  A unique identifier for the engine that determined the Selector ID. Thus, the Classification Engine ID defines the context for the Selector ID. The Classification Engine can be considered a specific registry for application assignments.
Values for this field are listed in the Classification Engine IDs registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#classification-engine-ids.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: A unique identifier for the engine that determined the Selector ID. Thus, the Classification Engine ID defines the context for the Selector ID. The Classification Engine can be considered a specific registry for application assignments.
Values for this field are listed in the Classification Engine IDs registry.</li>
              <li>Additional Information: See https://www.iana.org/assignments/ipfix/ipfix.xhtml#classification-engine-ids.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="flowendreason">
        <name>flowEndReason</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: The reason for Flow termination. Values are listed in the flowEndReason registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-flow-end-reason.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: The reason for Flow termination. Values are listed in the flowEndReason registry.</li>
              <li>Additional Information: See the Classification Engine IDs registry available at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-flow-end-reason].</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="natoriginatingaddressrealm">
        <name>natOriginatingAddressRealm</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: Indicates whether the session was created because traffic originated in the private or public address realm. postNATSourceIPv4Address, postNATDestinationIPv4Address, postNAPTSourceTransportPort, and postNAPTDestinationTransportPort are qualified with the address realm in perspective. Values are listed in the natOriginatingAddressRealm registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-originating-address-realm.</li>
              <li>Additional Information: See <xref target="RFC3022"/> for the definition of NAT.</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description:  Indicates whether the session was created because traffic originated in the private or public address realm. postNATSourceIPv4Address, postNATDestinationIPv4Address, postNAPTSourceTransportPort, and postNAPTDestinationTransportPort are qualified with the address realm in perspective. Values are listed in the natOriginatingAddressRealm registry.</li>
              <li>Additional Information: See the assigned NAT originating address realm at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-originating-address-realm]. See <xref target="RFC3022"/> for the definition of NAT.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="natevent">
        <name>natEvent</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element identifies a NAT event. This IE identifies the type of a NAT event. Examples of NAT events include, but are not limited to, NAT translation create, NAT translation delete, Threshold Reached, or Threshold Exceeded, etc. Values for this Information Element are listed in the "NAT Event Type" registry, see https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-event-type.</li>
              <li>Additional Information: See <xref target="RFC3022"/> for the definition of NAT. See <xref target="RFC3234"/> for the definition of middleboxes. See <xref target="RFC8158"/> for the definitions of values 4-16.</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element identifies a NAT event. This IE identifies the type of a NAT event. Examples of NAT events include, but are not limited to, NAT translation create, NAT translation delete, Threshold Reached, or Threshold Exceeded, etc. Values for this Information Element are listed in the "NAT Event Type" registry.</li>
              <li>Additional Information: See the assigned NAT Event Types at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-event-type]. See <xref target="RFC3022"/> for the definition of NAT. See <xref target="RFC3234"/> for the definition of middleboxes. See <xref target="RFC8158"/> for the definitions of values 4-16.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="firewallevent">
        <name>firewallEvent</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: Indicates a firewall event. Allowed values are listed in the firewallEvent registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-firewall-event.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: Indicates a firewall event. Allowed values are listed in the firewallEvent registry.</li>
              <li>Additional Information: See the assigned firewall events at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-firewall-event].</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="biflowdirection">
        <name>biflowDirection</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description:  A description of the direction assignment method used to assign the Biflow Source and Destination. This Information Element <bcp14>MAY</bcp14> be present in a Flow Data Record, or applied to all flows exported from an Exporting Process or Observation Domain using IPFIX Options. If this Information Element is not present in a Flow Record or associated with a Biflow via scope, it is assumed that the configuration of the direction assignment method is done out-of-band. Note that when using IPFIX Options to apply this Information Element to all flows within an Observation Domain or from an Exporting Process, the Option <bcp14>SHOULD</bcp14> be sent reliably. If reliable transport is not available (i.e., when using UDP), this Information Element <bcp14>SHOULD</bcp14> appear in each Flow Record. Values are listed in the biflowDirection registry. See [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-biflow-direction].</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: A description of the direction assignment method used to assign the Biflow Source and Destination. This Information Element <bcp14>MAY</bcp14> be present in a Flow Data Record, or applied to all flows exported from an Exporting Process or Observation Domain using IPFIX Options. If this Information Element is not present in a Flow Record or associated with a Biflow via scope, it is assumed that the configuration of the direction assignment method is done out-of-band. Note that when using IPFIX Options to apply this Information Element to all flows within an Observation Domain or from an Exporting Process, the Option <bcp14>SHOULD</bcp14> be sent reliably. If reliable transport is not available (i.e., when using UDP), this Information Element <bcp14>SHOULD</bcp14> appear in each Flow Record. Values are listed in the biflowDirection registry.</li>
              <li>Additional Information: See the assigned biflow direction values at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-biflow-direction].</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="observationpointtype">
        <name>observationPointType</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: Type of observation point. Values are listed in the observationPointType registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-observation-point-type.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: Type of observation point. Values are listed in the observationPointType registry.</li>
              <li>Additional Information: See the assigned observation point type at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-observation-point-type].</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="anonymizationtechnique">
        <name>anonymizationTechnique</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: A description of the anonymization technique applied to a referenced Information Element within a referenced Template. Each technique may be applicable only to certain Information Elements and recommended only for certain Information Elements. Values are listed in the anonymizationTechnique registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-anonymization-technique.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: A description of the anonymization technique applied to a referenced Information Element within a referenced Template. Each technique may be applicable only to certain Information Elements and recommended only for certain Information Elements. Values are listed in the anonymizationTechnique registry.</li>
              <li>Additional Information: See the assigned anonymization techniques at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-anonymization-technique].</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="nattype">
        <name>natType</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: Values are listed in the natType registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-type.</li>
              <li>Additional Information: See <xref target="RFC3022"/> for the definition of NAT. See <xref target="RFC1631"/> for the definition of NAT44. See <xref target="RFC6144"/> for the definition of NAT64. See <xref target="RFC6146"/> for the definition of NAT46. See <xref target="RFC6296"/> for the definition of NAT66. See <xref target="RFC0791"/> for the definition of IPv4. See <xref target="RFC8200"/> for the definition of IPv6.</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: Values are listed in the natType registry.</li>
              <li>Additional Information: See the assigned NAT types at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-type]. See <xref target="RFC3022"/> for the definition of NAT. See <xref target="RFC1631"/> for the definition of NAT44. See <xref target="RFC6144"/> for the definition of NAT64. See <xref target="RFC6146"/> for the definition of NAT46. See <xref target="RFC6296"/> for the definition of NAT66. See <xref target="RFC0791"/> for the definition of IPv4. See <xref target="RFC8200"/> for the definition of IPv6.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="selectoralgorithm">
        <name>selectorAlgorithm</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element identifies the packet selection methods (e.g., Filtering, Sampling) that are applied by the Selection Process. Most of these methods have parameters. Further Information Elements are needed to fully specify packet selection with these methods and all their parameters. The methods listed below are defined in <xref target="RFC5475"/>. For their parameters, Information Elements are defined in the information model document. The names of these Information Elements are listed for each method identifier. Further method identifiers may be added to the list below. It might be necessary to define new Information Elements to specify their parameters. The following packet selection methods identifiers are defined here: https://www.iana.org/assignments/psamp-parameters. There is a broad variety of possible parameters that could be used for Property match Filtering (5) but currently there are no agreed parameters specified.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element identifies the packet selection methods (e.g., Filtering, Sampling) that are applied by the Selection Process. Most of these methods have parameters. Further Information Elements are needed to fully specify packet selection with these methods and all their parameters. For the methods parameters, Information Elements are defined in the information model document. The names of these Information Elements are listed for each method identifier. Further method identifiers may be added to the list. It might be necessary to define new Information Elements to specify their parameters. There is a broad variety of possible parameters that could be used for Property match Filtering (5) but currently there are no agreed parameters specified.</li>
              <li>Additional Information: See the assigned PSAMP parameters at [https://www.iana.org/assignments/psamp-parameters].</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="informationelementdatatype">
        <name>informationElementDataType</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: A description of the abstract data type of an IPFIX information element.These are taken from the abstract data types defined in section 3.1 of the IPFIX Information Model <xref target="RFC5102"/>; see that section for more information on the types described in the [informationElementDataType] subregistry. These types are registered in the IANA IPFIX Information Element Data Type subregistry. This subregistry is intended to assign numbers for type names, not to provide a mechanism for adding data types to the IPFIX Protocol, and as such requires a Standards Action <xref target="RFC8126"/> to modify.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: A description of the abstract data type of an IPFIX information element.These are taken from the abstract data types defined in section 3.1 of the IPFIX Information Model <xref target="RFC5102"/>; see that section for more information on the types described in the [informationElementDataType] subregistry. These types are registered in the IANA IPFIX Information Element Data Type subregistry. This subregistry is intended to assign numbers for type names, not to provide a mechanism for adding data types to the IPFIX Protocol, and as such requires a Standards Action <xref target="RFC8126"/> to modify.</li>
              <li>Additional Information: See the assigned emelement data types at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-element-data-types].</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="informationelementsemantics">
        <name>informationElementSemantics</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: A description of the semantics of an IPFIX Information Element. These are taken from the data type semantics defined in section 3.2 of the IPFIX Information Model <xref target="RFC5102"/>; see that section for more information on the types defined in the [IPFIX Information Element Semantics] subregistry. This field may take the values in the semantics registry; the special value 0x00 (default) is used to note that no semantics apply to the field; it cannot be manipulated by a Collecting Process or File Reader that does not understand it a priori. These semantics are registered in the IANA IPFIX Information Element Semantics subregistry. This subregistry is intended to assign numbers for semantics names, not to provide a mechanism for adding semantics to the IPFIX Protocol, and as such requires a Standards Action <xref target="RFC8126"/> to modify.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: A description of the semantics of an IPFIX Information Element. These are taken from the data type semantics defined in section 3.2 of the IPFIX Information Model <xref target="RFC5102"/>; see that section for more information on the types defined in the [IPFIX Information Element Semantics] subregistry. This field may take the values in the semantics registry; the special value 0x00 (default) is used to note that no semantics apply to the field; it cannot be manipulated by a Collecting Process or File Reader that does not understand it a priori. These semantics are registered in the IANA IPFIX Information Element Semantics subregistry. This subregistry is intended to assign numbers for semantics names, not to provide a mechanism for adding semantics to the IPFIX Protocol, and as such requires a Standards Action <xref target="RFC8126"/> to modify.</li>
              <li>Additional Information: See the assigned semantics of an IPFIX Information Element at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-element-semantic].</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="informationelementunits">
        <name>informationElementUnits</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: A description of the units of an IPFIX Information Element. These correspond to the units implicitly defined in the Information Element definitions in section 5 of the IPFIX Information Model <xref target="RFC5102"/>; see that section for more information on the types described in the informationElementsUnits subregistry. This field may take the values in Table 3 below; the special value 0x00 (none) is used to note that the field is unitless. These types are registered in the [IANA IPFIX Information Element Units] subregistry.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: A description of the units of an IPFIX Information Element. These correspond to the units implicitly defined in the Information Element definitions in Section 5 of the IPFIX Information Model <xref target="RFC5102"/>; see that section for more information on the types described in the informationElementsUnits subregistry. The special value 0x00 (none) is used to note that the field is unitless. These types are registered in the [IANA IPFIX Information Element Units] subregistry.</li>
              <li>Additional Information: See the assigned units of an IPFIX Information Element at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-element-units].</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="portrangestart">
        <name>portRangeStart</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: The port number identifying the start of a range of ports. A value of zero indicates that the range start is not specified, ie the range is defined in some other way. Additional information on defined TCP port numbers can be found at https://www.iana.org/assignments/service-names-port-numbers.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: The port number identifying the start of a range of ports. A value of zero indicates that the range start is not specified, i.e., the range is defined in some other way.</li>
              <li>Additional Information: Additional information on defined TCP port numbers can be found at https://www.iana.org/assignments/service-names-port-numbers.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="portrangeend">
        <name>portRangeEnd</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: The port number identifying the end of a range of ports. A value of zero indicates that the range end is not specified, ie the range is defined in some other way. Additional information on defined TCP port numbers can be found at https://www.iana.org/assignments/service-names-port-numbers.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: The port number identifying the end of a range of ports. A value of zero indicates that the range end is not specified, i.e., the range is defined in some other way.</li>
              <li>Additional Information: Additional information on defined TCP port numbers can be found at https://www.iana.org/assignments/service-names-port-numbers.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="ingressinterfacetype">
        <name>ingressInterfaceType</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: The type of interface where packets of this Flow are being received. The value matches the value of managed object 'ifType' as defined in https://www.iana.org/assignments/ianaiftype-mib.</li>
              <li>Additional Information: https://www.iana.org/assignments/ianaiftype-mib</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: The type of interface where packets of this Flow are being received. The value matches the value of managed object 'ifType'.</li>
              <li>Additional Information: See the assigned ingress interface types at [https://www.iana.org/assignments/ianaiftype-mib].</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="egressinterfacetype">
        <name>egressInterfaceType</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: The type of interface where packets of this Flow are being sent. The value matches the value of managed object 'ifType' as defined in https://www.iana.org/assignments/ianaiftype-mib.</li>
              <li>Additional Information: https://www.iana.org/assignments/ianaiftype-mib</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: The type of interface where packets of this Flow are being sent. The value matches the value of managed object 'ifType'.</li>
              <li>Additional Information: See the assigned egress interface types at [https://www.iana.org/assignments/ianaiftype-mib].</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="valuedistributionmethod">
        <name>valueDistributionMethod</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: A description of the method used to distribute the counters from Contributing Flows into the Aggregated Flow records described by an associated scope, generally a Template. The method is deemed to apply to all the non-key Information Elements in the referenced scope for which value distribution is a valid operation; if the originalFlowsInitiated and/or originalFlowsCompleted Information Elements appear in the Template, they are not subject to this distribution method, as they each infer their own distribution method. The valueDistributionMethod registry is intended to list a complete set of possible value distribution methods. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-value-distribution-method.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: A description of the method used to distribute the counters from Contributing Flows into the Aggregated Flow records described by an associated scope, generally a Template. The method is deemed to apply to all the non-key Information Elements in the referenced scope for which value distribution is a valid operation; if the originalFlowsInitiated and/or originalFlowsCompleted Information Elements appear in the Template, they are not subject to this distribution method, as they each infer their own distribution method. The valueDistributionMethod registry is intended to list a complete set of possible value distribution methods.</li>
              <li>Additional Information: See the assigned distributed methods at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-value-distribution-method].</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="flowselectoralgorithm">
        <name>flowSelectorAlgorithm</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element identifies the Intermediate Flow Selection Process technique (e.g., Filtering, Sampling) that is applied by the Intermediate Flow Selection Process. Most of these techniques have parameters. Its configuration parameter(s) <bcp14>MUST</bcp14> be clearly specified. Further Information Elements are needed to fully specify packet selection with these methods and all their parameters. Further method identifiers may be added to the flowSelectorAlgorithm registry. It might be necessary to define new Information Elements to specify their parameters. Please note that the purpose of the flow selection techniques described in this document is the improvement of measurement functions as defined in the Scope (Section 1). The Intermediate Flow Selection Process Techniques identifiers are defined at https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-flowselectoralgorithm.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element identifies the Intermediate Flow Selection Process technique (e.g., Filtering, Sampling) that is applied by the Intermediate Flow Selection Process. Most of these techniques have parameters. Its configuration parameter(s) <bcp14>MUST</bcp14> be clearly specified. Further Information Elements are needed to fully specify packet selection with these methods and all their parameters. Further method identifiers may be added to the flowSelectorAlgorithm registry. It might be necessary to define new Information Elements to specify their parameters.</li>
              <li>Additional Information: See the assigned flow selector algorithms at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-flowselectoralgorithm].</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="datalinkframetype">
        <name>dataLinkFrameType</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element specifies the type of the selected data link frame. Data link types are defined in the dataLinkFrameType registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-data-link-frame-type. Further values may be assigned by IANA. Note that the assigned values are bits so that multiple observations can be OR'd together. The data link layer is defined in [ISO/IEC.7498-1:1994].</li>
              <li>Additional Information: [IEEE802.3][IEEE802.11][ISO/IEC.7498-1:1994]</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element specifies the type of the selected data link frame. Data link types are defined in the dataLinkFrameType registry. Further values may be assigned by IANA. Note that the assigned values are bits so that multiple observations can be OR'd together. The data link layer is defined in [ISO/IEC.7498-1:1994].</li>
              <li>Additional Information: See the assigned data link frame types at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-data-link-frame-type]. More information about the data link layer can be found in [IEEE802.3][IEEE802.11][ISO/IEC.7498-1:1994].</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="mibcapturetimesemantics">
        <name>mibCaptureTimeSemantics</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: Indicates when in the lifetime of the Flow the MIB value was retrieved from the MIB for a mibObjectIdentifier. This is used to indicate if the value exported was collected from the MIB closer to Flow creation or Flow export time and refers to the Timestamp fields included in the same Data Record. This field <bcp14>SHOULD</bcp14> be used when exporting a mibObjectValue that specifies counters or statistics. If the MIB value was sampled by SNMP prior to the IPFIX Metering Process or Exporting Process retrieving the value (i.e., the data is already stale) and it is important to know the exact sampling time, then an additional observationTime* element should be paired with the OID using IPFIX Structured Data <xref target="RFC6313"/>. Similarly, if different MIB capture times apply to different mibObjectValue elements within the Data Record, then individual mibCaptureTimeSemantics Information Elements should be paired with each OID using IPFIX Structured Data. Values are listed in the mibCaptureTimeSemantics registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mib-capture-time-semantics.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: Indicates when in the lifetime of the Flow the MIB value was retrieved from the MIB for a mibObjectIdentifier. This is used to indicate if the value exported was collected from the MIB closer to Flow creation or Flow export time and refers to the Timestamp fields included in the same Data Record. This field <bcp14>SHOULD</bcp14> be used when exporting a mibObjectValue that specifies counters or statistics. If the MIB value was sampled by SNMP prior to the IPFIX Metering Process or Exporting Process retrieving the value (i.e., the data is already stale) and it is important to know the exact sampling time, then an additional observationTime* element should be paired with the OID using IPFIX Structured Data <xref target="RFC6313"/>. Similarly, if different MIB capture times apply to different mibObjectValue elements within the Data Record, then individual mibCaptureTimeSemantics Information Elements should be paired with each OID using IPFIX Structured Data. Values are listed in the mibCaptureTimeSemantics registry.</li>
              <li>Additional Information: See the assigned values for the MIB capture time semantics at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mib-capture-time-semantics].</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="natquotaexceededevent">
        <name>natQuotaExceededEvent</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element identifies the type of a NAT Quota Exceeded event. Values for this Information Element are listed in the "NAT Quota Exceeded Event Type" registry, see https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-quota-exceeded-event.</li>
              <li>Additional Information: See <xref target="RFC0791"/> for the definition of the IPv4 source address field. See <xref target="RFC3022"/> for the definition of NAT. See <xref target="RFC3234"/> for the definition of middleboxes.</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element identifies the type of a NAT Quota Exceeded event. Values for this Information Element are listed in the "NAT Quota Exceeded Event Type" registry.</li>
              <li>Additional Information: See the assigned events for exceeded NAT quota at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-quota-exceeded-event]. See <xref target="RFC0791"/> for the definition of the IPv4 source address field. See <xref target="RFC3022"/> for the definition of NAT. See <xref target="RFC3234"/> for the definition of middleboxes.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="natthresholdevent">
        <name>natThresholdEvent</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element identifies a type of a NAT Threshold event. Values for this Information Element are listed in the "NAT Threshold Event Type" registry, see https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-threshold-event.</li>
              <li>Additional Information: See <xref target="RFC0791"/> for the definition of the IPv4 source address field. See <xref target="RFC3022"/> for the definition of NAT. See <xref target="RFC3234"/> for the definition of middleboxes.</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element identifies a type of a NAT Threshold event. Values for this Information Element are listed in the "NAT Threshold Event Type" registry.</li>
              <li>Additional Information: See the assigned values for the NAT Threshold events at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-threshold-event]. See <xref target="RFC0791"/> for the definition of the IPv4 source address field. See <xref target="RFC3022"/> for the definition of NAT. See <xref target="RFC3234"/> for the definition of middleboxes.</li>
            </ul>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="misc">
      <name>Misc</name>
      <t>This document requests IANA to update the description of the following entries in <xref target="IANA-IPFIX"/>.</t>
      <section anchor="collectiontimemilliseconds">
        <name>collectionTimeMilliseconds</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: The absolute timestamp at which the data within the scope containing this Information Element was received by a Collecting Process. This Information Element <bcp14>SHOULD</bcp14> be bound to its containing IPFIX Message via IPFIX Options and the messageScope Information Element, as defined below.</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: The absolute timestamp at which the data within the scope containing this Information Element was received by a Collecting Process. This Information Element <bcp14>SHOULD</bcp14> be bound to its containing IPFIX Message via IPFIX Options and the messageScope Information Element.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="messagemd5checksum">
        <name>messageMD5Checksum</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: The MD5 checksum of the IPFIX Message containing this record. This Information Element <bcp14>SHOULD</bcp14> be bound to its containing IPFIX Message via an options record and the messageScope Information Element, as defined below, and <bcp14>SHOULD</bcp14> appear only once in a given IPFIX Message. To calculate the value of this Information Element, first buffer the containing IPFIX Message, setting the value of this Information Element to all zeroes. Then calculate the MD5 checksum of the resulting buffer as defined in <xref target="RFC1321"/>, place the resulting value in this Information Element, and export the buffered message. This Information Element is intended as a simple checksum only; therefore collision resistance and algorithm agility are not required, and MD5 is an appropriate message digest. This Information Element has a fixed length of 16 octets.</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: The MD5 checksum of the IPFIX Message containing this record. This Information Element <bcp14>SHOULD</bcp14> be bound to its containing IPFIX Message via an options record and the messageScope Information Element, and <bcp14>SHOULD</bcp14> appear only once in a given IPFIX Message. To calculate the value of this Information Element, first buffer the containing IPFIX Message, setting the value of this Information Element to all zeroes. Then calculate the MD5 checksum of the resulting buffer as defined in <xref target="RFC1321"/>, place the resulting value in this Information Element, and export the buffered message. This Information Element is intended as a simple checksum only; therefore collision resistance and algorithm agility are not required, and MD5 is an appropriate message digest. This Information Element has a fixed length of 16 octets.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="anonymizationflags">
        <name>anonymizationFlags</name>
        <ul spacing="normal">
          <li>OLD:</li>
        </ul>
        <artwork><![CDATA[
+--------+----------+-----------------------------------------------+
| bit(s) | name     | description                                   |
| (LSB = |          |                                               |
| 0)     |          |                                               |
+--------+----------+-----------------------------------------------+
| 0-1    | SC       | Stability Class: see the Stability Class      |
|        |          | table below, and section Section 5.1.         |
| 2      | PmA      | Perimeter Anonymization: when set (1),        |
|        |          | source- Information Elements as described in  |
|        |          | [RFC5103] are interpreted as external         |
|        |          | addresses, and destination- Information       |
|        |          | Elements as described in [RFC5103] are        |
|        |          | interpreted as internal addresses, for the    |
|        |          | purposes of associating                       |
|        |          | anonymizationTechnique to Information         |
|        |          | Elements only; see Section 7.2.2 for details. |
|        |          | This bit MUST NOT be set when associated with |
|        |          | a non-endpoint (i.e., source- or              |
|        |          | destination-) Information Element.  SHOULD be |
|        |          | consistent within a record (i.e., if a        |
|        |          | source- Information Element has this flag     |
|        |          | set, the corresponding destination- element   |
|        |          | SHOULD have this flag set, and vice-versa.)   |
| 3      | LOR      | Low-Order Unchanged: when set (1), the        |
|        |          | low-order bits of the anonymized Information  |
|        |          | Element contain real data.  This modification |
|        |          | is intended for the anonymization of          |
|        |          | network-level addresses while leaving         |
|        |          | host-level addresses intact in order to       |
|        |          | preserve host level-structure, which could    |
|        |          | otherwise be used to reverse anonymization.   |
|        |          | MUST NOT be set when associated with a        |
|        |          | truncation-based anonymizationTechnique.      |
| 4-15   | Reserved | Reserved for future use: SHOULD be cleared    |
|        |          | (0) by the Exporting Process and MUST be      |
|        |          | ignored by the Collecting Process.            |
+--------+----------+-----------------------------------------------+
]]></artwork>
        <ul spacing="normal">
          <li>NEW:</li>
        </ul>
        <artwork><![CDATA[
+--------+----------+-----------------------------------------------+
| bit(s) | name     | description                                   |
| (LSB = |          |                                               |
| 0)     |          |                                               |
+--------+----------+-----------------------------------------------+
| 0-1    | SC       | Stability Class: see the Stability Class      |
|        |          | table below, and Section 5.1 of [RFC6235].    |
| 2      | PmA      | Perimeter Anonymization: when set (1),        |
|        |          | source- Information Elements as described in  |
|        |          | [RFC5103] are interpreted as external         |
|        |          | addresses, and destination- Information       |
|        |          | Elements as described in [RFC5103] are        |
|        |          | interpreted as internal addresses, for the    |
|        |          | purposes of associating                       |
|        |          | anonymizationTechnique to Information         |
|        |          | Elements only; see Section 7.2.2 of [RFC6235] |
|        |          | for details.                                  |
|        |          | This bit MUST NOT be set when associated with |
|        |          | a non-endpoint (i.e., source- or              |
|        |          | destination-) Information Element.  SHOULD be |
|        |          | consistent within a record (i.e., if a        |
|        |          | source- Information Element has this flag     |
|        |          | set, the corresponding destination- element   |
|        |          | SHOULD have this flag set, and vice-versa.)   |
| 3      | LOR      | Low-Order Unchanged: when set (1), the        |
|        |          | low-order bits of the anonymized Information  |
|        |          | Element contain real data.  This modification |
|        |          | is intended for the anonymization of          |
|        |          | network-level addresses while leaving         |
|        |          | host-level addresses intact in order to       |
|        |          | preserve host level-structure, which could    |
|        |          | otherwise be used to reverse anonymization.   |
|        |          | MUST NOT be set when associated with a        |
|        |          | truncation-based anonymizationTechnique.      |
| 4-15   | Reserved | Reserved for future use: SHOULD be cleared    |
|        |          | (0) by the Exporting Process and MUST be      |
|        |          | ignored by the Collecting Process.            |
+--------+----------+-----------------------------------------------+
]]></artwork>
      </section>
      <section anchor="informationelementdescription">
        <name>informationElementDescription</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: A UTF-8 <xref target="RFC3629"/> encoded Unicode string containing a human-readable description of an Information Element. The content of the informationElementDescription <bcp14>MAY</bcp14> be annotated with one or more language tags <xref target="RFC4646"/>, encoded in-line <xref target="RFC2482"/> within the UTF-8 string, in order to specify the language in which the description is written. Description text in multiple languages <bcp14>MAY</bcp14> tag each section with its own language tag; in this case, the description information in each language <bcp14>SHOULD</bcp14> have equivalent meaning. In the absence of any language tag, the "i-default" <xref target="RFC2277"/> language <bcp14>SHOULD</bcp14> be assumed. See the Security Considerations section for notes on string handling for Information Element type records.</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: A UTF-8 <xref target="RFC3629"/> encoded Unicode string containing a human-readable description of an Information Element. The content of the informationElementDescription <bcp14>MAY</bcp14> be annotated with one or more language tags <xref target="RFC4646"/>, encoded in-line <xref target="RFC2482"/> within the UTF-8 string, in order to specify the language in which the description is written. Description text in multiple languages <bcp14>MAY</bcp14> tag each section with its own language tag; in this case, the description information in each language <bcp14>SHOULD</bcp14> have equivalent meaning. In the absence of any language tag, the "i-default" <xref target="RFC2277"/> language <bcp14>SHOULD</bcp14> be assumed. See the Security Considerations section of <xref target="RFC5610"/> for notes on string handling for Information Element type records.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="distinctcountofdestinationipaddress">
        <name>distinctCountOfDestinationIPAddress</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: The count of distinct destination IP address values for Original Flows contributing to this Aggregated Flow, without regard to IP version. This Information Element is preferred to the version-specific counters below, unless it is important to separate the counts by version.</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: The count of distinct destination IP address values for Original Flows contributing to this Aggregated Flow, without regard to IP version. This Information Element is preferred to the version-specific counters, unless it is important to separate the counts by version.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="externaladdressrealm">
        <name>externalAddressRealm</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element represents the external address realm where the packet is originated from or destined to. The detailed definition is in the internal address realm as specified above.</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element represents the external address realm where the packet is originated from or destined to. See the internalAddressRealm IE for the detailed definition.</li>
            </ul>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>IPFIX security considerations are discussed in <xref section="8" sectionFormat="of" target="RFC7012"/>.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>A set of requested IANA actions are described in the main document. These actions are not repeated here.</t>
      <t>This document also requests IANA to update the reference clause of the "IPFIX Information Elements" subregistry with the reference to this document.</t>
      <section anchor="ipfix-subregistry-for-ipv6-extension-headers">
        <name>IPFIX Subregistry for IPv6 Extension Headers</name>
        <t>This document requests IANA to create a new subregistry entitled "ipv6ExtensionHeaders Bits" under the IANA IPFIX registry <xref target="IANA-IPFIX"/>.</t>
        <t>The initial values of this subregistry are as follows:</t>
        <artwork><![CDATA[
   Bit    IPv6 Option   Description
    0, DST      60       Destination option header
    1, HOP       0       Hop-by-hop option header
    2, U                 Unassigned
    3, UNK               Unknown Layer 4 header
                         (compressed, encrypted, not supported)
    4, FRA0     44       Fragment header - first fragment
    5, RH       43       Routing header
    6, FRA1     44       Fragmentation header - not first fragment
    7 to 11              Unassigned
    12, MOB     135      IPv6 mobility [RFC3775]
    13, ESP      50      Encrypted security payload
    14, AH       51      Authentication Header
    15, PAY     108      Payload compression header
    16, HIP     139      Host Identity Protocol
    17, SHIM6   140      Shim6 Protocol
    18          253      Use for experimentation and testing
    19          254      Use for experimentation and testing
    20 to 255            Unassigned
]]></artwork>
        <t>Values are not added directly into this subregistry. When a new code is assigned to an IPv6 EH in <xref target="IPv6-EH"/>, a free bit is selected by IANA for this EH from "ipv6ExtensionHeaders Bits" subregistry and the subregistry is udpated with the details that mirror the assigned EH.</t>
        <t>IANA is requested to add this note to <xref target="IPv6-EH"/>:</t>
        <dl>
          <dt>Note:</dt>
          <dd>
            <t>When a new code is assigned to an IPv6 Extension Header, a free bit in [NEW_IPFIX_IPv6EH_SUBREGISTRY] is selected for this new Extension Header [NEW_IPFIX_IPv6EH_SUBREGISTRY] is updated accordingly.</t>
          </dd>
        </dl>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="IANA-IPFIX" target="https://www.iana.org/assignments/ipfix/ipfix.xhtml">
          <front>
            <title>IP Flow Information Export (IPFIX) Entities</title>
            <author>
              <organization/>
            </author>
            <date year="2022" month="November"/>
          </front>
        </reference>
        <reference anchor="IPv6-EH" target="https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-1">
          <front>
            <title>Internet Protocol Version 6 (IPv6) Parameters, IPv6 Extension Header Types</title>
            <author>
              <organization/>
            </author>
            <date year="2022" month="November"/>
          </front>
        </reference>
        <reference anchor="IANA-TCP" target="https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-parameters-1">
          <front>
            <title>Transmission Control Protocol (TCP) Parameters, TCP Option Kind Numbers</title>
            <author>
              <organization/>
            </author>
            <date year="2022" month="November"/>
          </front>
        </reference>
        <reference anchor="RFC7011">
          <front>
            <title>Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information</title>
            <author fullname="B. Claise" initials="B." role="editor" surname="Claise">
              <organization/>
            </author>
            <author fullname="B. Trammell" initials="B." role="editor" surname="Trammell">
              <organization/>
            </author>
            <author fullname="P. Aitken" initials="P." surname="Aitken">
              <organization/>
            </author>
            <date month="September" year="2013"/>
            <abstract>
              <t>This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network.  In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required.  This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process.  This document obsoletes RFC 5101.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="77"/>
          <seriesInfo name="RFC" value="7011"/>
          <seriesInfo name="DOI" value="10.17487/RFC7011"/>
        </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>
        <reference anchor="RFC7013">
          <front>
            <title>Guidelines for Authors and Reviewers of IP Flow Information Export (IPFIX) Information Elements</title>
            <author fullname="B. Trammell" initials="B." surname="Trammell">
              <organization/>
            </author>
            <author fullname="B. Claise" initials="B." surname="Claise">
              <organization/>
            </author>
            <date month="September" year="2013"/>
            <abstract>
              <t>This document provides guidelines for how to write definitions of new Information Elements for the IP Flow Information Export (IPFIX) protocol.  It provides instructions on using the proper conventions for Information Elements to be registered in the IANA IPFIX Information Element registry, and provides guidelines for expert reviewers to evaluate new registrations.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="184"/>
          <seriesInfo name="RFC" value="7013"/>
          <seriesInfo name="DOI" value="10.17487/RFC7013"/>
        </reference>
        <reference anchor="RFC6994">
          <front>
            <title>Shared Use of Experimental TCP Options</title>
            <author fullname="J. Touch" initials="J." surname="Touch">
              <organization/>
            </author>
            <date month="August" year="2013"/>
            <abstract>
              <t>This document describes how the experimental TCP option codepoints can concurrently support multiple TCP extensions, even within the same connection, using a new IANA TCP experiment identifier. This approach is robust to experiments that are not registered and to those that do not use this sharing mechanism.  It is recommended for all new TCP options that use these codepoints.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6994"/>
          <seriesInfo name="DOI" value="10.17487/RFC6994"/>
        </reference>
        <reference anchor="RFC7012">
          <front>
            <title>Information Model for IP Flow Information Export (IPFIX)</title>
            <author fullname="B. Claise" initials="B." role="editor" surname="Claise">
              <organization/>
            </author>
            <author fullname="B. Trammell" initials="B." role="editor" surname="Trammell">
              <organization/>
            </author>
            <date month="September" year="2013"/>
            <abstract>
              <t>This document defines the data types and management policy for the information model for the IP Flow Information Export (IPFIX) protocol.  This information model is maintained as the IANA "IPFIX                         Information Elements" registry, the initial contents of which were defined by RFC 5102.  This information model is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process.  Although this model was developed for the IPFIX protocol, it is defined in an open way that allows it to be easily used in other protocols, interfaces, and applications. This document obsoletes RFC 5102.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7012"/>
          <seriesInfo name="DOI" value="10.17487/RFC7012"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="I-D.boucadair-opsawg-rfc7125-update">
          <front>
            <title>An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element</title>
            <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
              <organization>Orange</organization>
            </author>
            <date day="5" month="January" year="2023"/>
            <abstract>
              <t>   RFC 7125 revised the tcpControlBits IP Flow Information Export
   (IPFIX) Information Element that was originally defined in RFC 5102
   to reflect changes to the TCP Flags header field since RFC 793.
   However, that update is still problematic for interoperability
   because some flag values were deprecated since then.

   This document updates RFC 7125 by removing stale information from the
   IPFIX registry and avoiding future conflicts with the authoritative
   TCP Header Flags registry.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-boucadair-opsawg-rfc7125-update-02"/>
        </reference>
        <reference anchor="RFC7125">
          <front>
            <title>Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element</title>
            <author fullname="B. Trammell" initials="B." surname="Trammell">
              <organization/>
            </author>
            <author fullname="P. Aitken" initials="P." surname="Aitken">
              <organization/>
            </author>
            <date month="February" year="2014"/>
            <abstract>
              <t>This document revises the tcpControlBits IP Flow Information Export (IPFIX) Information Element as originally defined in RFC 5102 to reflect changes to the TCP Flags header field since RFC 793.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7125"/>
          <seriesInfo name="DOI" value="10.17487/RFC7125"/>
        </reference>
        <reference anchor="RFC5102">
          <front>
            <title>Information Model for IP Flow Information Export</title>
            <author fullname="J. Quittek" initials="J." surname="Quittek">
              <organization/>
            </author>
            <author fullname="S. Bryant" initials="S." surname="Bryant">
              <organization/>
            </author>
            <author fullname="B. Claise" initials="B." surname="Claise">
              <organization/>
            </author>
            <author fullname="P. Aitken" initials="P." surname="Aitken">
              <organization/>
            </author>
            <author fullname="J. Meyer" initials="J." surname="Meyer">
              <organization/>
            </author>
            <date month="January" year="2008"/>
            <abstract>
              <t>This memo defines an information model for the IP Flow Information eXport (IPFIX) protocol.  It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process.  Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5102"/>
          <seriesInfo name="DOI" value="10.17487/RFC5102"/>
        </reference>
        <reference anchor="RFC3031">
          <front>
            <title>Multiprotocol Label Switching Architecture</title>
            <author fullname="E. Rosen" initials="E." surname="Rosen">
              <organization/>
            </author>
            <author fullname="A. Viswanathan" initials="A." surname="Viswanathan">
              <organization/>
            </author>
            <author fullname="R. Callon" initials="R." surname="Callon">
              <organization/>
            </author>
            <date month="January" year="2001"/>
            <abstract>
              <t>This document specifies the architecture for Multiprotocol Label Switching (MPLS).  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3031"/>
          <seriesInfo name="DOI" value="10.17487/RFC3031"/>
        </reference>
        <reference anchor="RFC3022">
          <front>
            <title>Traditional IP Network Address Translator (Traditional NAT)</title>
            <author fullname="P. Srisuresh" initials="P." surname="Srisuresh">
              <organization/>
            </author>
            <author fullname="K. Egevang" initials="K." surname="Egevang">
              <organization/>
            </author>
            <date month="January" year="2001"/>
            <abstract>
              <t>The NAT operation described in this document extends address translation introduced in RFC 1631 and includes a new type of network address and TCP/UDP port translation.  In addition, this document corrects the Checksum adjustment algorithm published in RFC 1631 and attempts to discuss NAT operation and limitations in detail.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3022"/>
          <seriesInfo name="DOI" value="10.17487/RFC3022"/>
        </reference>
        <reference anchor="RFC3234">
          <front>
            <title>Middleboxes: Taxonomy and Issues</title>
            <author fullname="B. Carpenter" initials="B." surname="Carpenter">
              <organization/>
            </author>
            <author fullname="S. Brim" initials="S." surname="Brim">
              <organization/>
            </author>
            <date month="February" year="2002"/>
            <abstract>
              <t>This document is intended as part of an IETF discussion about "middleboxes" - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host.  This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions.  It does not, however, claim to be definitive.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3234"/>
          <seriesInfo name="DOI" value="10.17487/RFC3234"/>
        </reference>
        <reference anchor="RFC8158">
          <front>
            <title>IP Flow Information Export (IPFIX) Information Elements for Logging NAT Events</title>
            <author fullname="S. Sivakumar" initials="S." surname="Sivakumar">
              <organization/>
            </author>
            <author fullname="R. Penno" initials="R." surname="Penno">
              <organization/>
            </author>
            <date month="December" year="2017"/>
            <abstract>
              <t>Network operators require NAT devices to log events like creation and deletion of translations and information about the resources that the NAT device is managing.  In many cases, the logs are essential to identify an attacker or a host that was used to launch malicious attacks and for various other purposes of accounting.  Since there is no standard way of logging this information, different NAT devices use proprietary formats; hence, it is difficult to expect consistent behavior.  This lack of standardization makes it difficult to write the Collector applications that would receive this data and process it to present useful information.  This document describes the formats for logging NAT events.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8158"/>
          <seriesInfo name="DOI" value="10.17487/RFC8158"/>
        </reference>
        <reference anchor="RFC1631">
          <front>
            <title>The IP Network Address Translator (NAT)</title>
            <author fullname="K. Egevang" initials="K." surname="Egevang">
              <organization/>
            </author>
            <author fullname="P. Francis" initials="P." surname="Francis">
              <organization/>
            </author>
            <date month="May" year="1994"/>
            <abstract>
              <t>This memo proposes another short-term solution, address reuse, that complements CIDR or even makes it unnecessary. The address reuse solution is to place Network Address Translators (NAT) at the borders of stub domains.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1631"/>
          <seriesInfo name="DOI" value="10.17487/RFC1631"/>
        </reference>
        <reference anchor="RFC6144">
          <front>
            <title>Framework for IPv4/IPv6 Translation</title>
            <author fullname="F. Baker" initials="F." surname="Baker">
              <organization/>
            </author>
            <author fullname="X. Li" initials="X." surname="Li">
              <organization/>
            </author>
            <author fullname="C. Bao" initials="C." surname="Bao">
              <organization/>
            </author>
            <author fullname="K. Yin" initials="K." surname="Yin">
              <organization/>
            </author>
            <date month="April" year="2011"/>
            <abstract>
              <t>This note describes a framework for IPv4/IPv6 translation.  This is in the context of replacing Network Address Translation - Protocol Translation (NAT-PT), which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network.  This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6144"/>
          <seriesInfo name="DOI" value="10.17487/RFC6144"/>
        </reference>
        <reference anchor="RFC6146">
          <front>
            <title>Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers</title>
            <author fullname="M. Bagnulo" initials="M." surname="Bagnulo">
              <organization/>
            </author>
            <author fullname="P. Matthews" initials="P." surname="Matthews">
              <organization/>
            </author>
            <author fullname="I. van Beijnum" initials="I." surname="van Beijnum">
              <organization/>
            </author>
            <date month="April" year="2011"/>
          </front>
          <seriesInfo name="RFC" value="6146"/>
          <seriesInfo name="DOI" value="10.17487/RFC6146"/>
        </reference>
        <reference anchor="RFC6296">
          <front>
            <title>IPv6-to-IPv6 Network Prefix Translation</title>
            <author fullname="M. Wasserman" initials="M." surname="Wasserman">
              <organization/>
            </author>
            <author fullname="F. Baker" initials="F." surname="Baker">
              <organization/>
            </author>
            <date month="June" year="2011"/>
            <abstract>
              <t>This document describes a stateless, transport-agnostic IPv6-to-IPv6 Network Prefix Translation (NPTv6) function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT (NAPT44) and provides a 1:1 relationship between addresses in the "inside" and "outside" prefixes, preserving end-to-end reachability at the network layer.  This document defines an Experimental Protocol  for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6296"/>
          <seriesInfo name="DOI" value="10.17487/RFC6296"/>
        </reference>
        <reference anchor="RFC0791">
          <front>
            <title>Internet Protocol</title>
            <author fullname="J. Postel" initials="J." surname="Postel">
              <organization/>
            </author>
            <date month="September" year="1981"/>
          </front>
          <seriesInfo name="STD" value="5"/>
          <seriesInfo name="RFC" value="791"/>
          <seriesInfo name="DOI" value="10.17487/RFC0791"/>
        </reference>
        <reference anchor="RFC8200">
          <front>
            <title>Internet Protocol, Version 6 (IPv6) Specification</title>
            <author fullname="S. Deering" initials="S." surname="Deering">
              <organization/>
            </author>
            <author fullname="R. Hinden" initials="R." surname="Hinden">
              <organization/>
            </author>
            <date month="July" year="2017"/>
            <abstract>
              <t>This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="86"/>
          <seriesInfo name="RFC" value="8200"/>
          <seriesInfo name="DOI" value="10.17487/RFC8200"/>
        </reference>
        <reference anchor="RFC5475">
          <front>
            <title>Sampling and Filtering Techniques for IP Packet Selection</title>
            <author fullname="T. Zseby" initials="T." surname="Zseby">
              <organization/>
            </author>
            <author fullname="M. Molina" initials="M." surname="Molina">
              <organization/>
            </author>
            <author fullname="N. Duffield" initials="N." surname="Duffield">
              <organization/>
            </author>
            <author fullname="S. Niccolini" initials="S." surname="Niccolini">
              <organization/>
            </author>
            <author fullname="F. Raspall" initials="F." surname="Raspall">
              <organization/>
            </author>
            <date month="March" year="2009"/>
            <abstract>
              <t>This document describes Sampling and Filtering techniques for IP packet selection.  It provides a categorization of schemes and defines what parameters are needed to describe the most common selection schemes.  Furthermore, it shows how techniques can be combined to build more elaborate packet Selectors.  The document provides the basis for the definition of information models for configuring selection techniques in Metering Processes and for reporting the technique in use to a Collector.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5475"/>
          <seriesInfo name="DOI" value="10.17487/RFC5475"/>
        </reference>
        <reference anchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton">
              <organization/>
            </author>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <author fullname="T. Narten" initials="T." surname="Narten">
              <organization/>
            </author>
            <date month="June" year="2017"/>
            <abstract>
              <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters.  To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper.  For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed.  This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t>This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC6313">
          <front>
            <title>Export of Structured Data in IP Flow Information Export (IPFIX)</title>
            <author fullname="B. Claise" initials="B." surname="Claise">
              <organization/>
            </author>
            <author fullname="G. Dhandapani" initials="G." surname="Dhandapani">
              <organization/>
            </author>
            <author fullname="P. Aitken" initials="P." surname="Aitken">
              <organization/>
            </author>
            <author fullname="S. Yates" initials="S." surname="Yates">
              <organization/>
            </author>
            <date month="July" year="2011"/>
            <abstract>
              <t>This document specifies an extension to the IP Flow Information Export (IPFIX) protocol specification in RFC 5101 and the IPFIX information model specified in RFC 5102 to support hierarchical structured data and lists (sequences) of Information Elements in data records.  This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates. Finally, the semantics are provided in order to express the relationship among multiple list elements in a structured data record.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6313"/>
          <seriesInfo name="DOI" value="10.17487/RFC6313"/>
        </reference>
        <reference anchor="RFC1321">
          <front>
            <title>The MD5 Message-Digest Algorithm</title>
            <author fullname="R. Rivest" initials="R." surname="Rivest">
              <organization/>
            </author>
            <date month="April" year="1992"/>
            <abstract>
              <t>This document describes the MD5 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input.  This memo provides information for the Internet community.  It does not specify an Internet standard.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1321"/>
          <seriesInfo name="DOI" value="10.17487/RFC1321"/>
        </reference>
        <reference anchor="RFC3629">
          <front>
            <title>UTF-8, a transformation format of ISO 10646</title>
            <author fullname="F. Yergeau" initials="F." surname="Yergeau">
              <organization/>
            </author>
            <date month="November" year="2003"/>
            <abstract>
              <t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems.  The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo.  UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values.  This memo obsoletes and replaces RFC 2279.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="63"/>
          <seriesInfo name="RFC" value="3629"/>
          <seriesInfo name="DOI" value="10.17487/RFC3629"/>
        </reference>
        <reference anchor="RFC4646">
          <front>
            <title>Tags for Identifying Languages</title>
            <author fullname="A. Phillips" initials="A." surname="Phillips">
              <organization/>
            </author>
            <author fullname="M. Davis" initials="M." surname="Davis">
              <organization/>
            </author>
            <date month="September" year="2006"/>
            <abstract>
              <t>This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object.  It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange.  This document, in combination with RFC 4647, replaces RFC 3066, which replaced RFC 1766.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4646"/>
          <seriesInfo name="DOI" value="10.17487/RFC4646"/>
        </reference>
        <reference anchor="RFC2482">
          <front>
            <title>Language Tagging in Unicode Plain Text</title>
            <author fullname="K. Whistler" initials="K." surname="Whistler">
              <organization/>
            </author>
            <author fullname="G. Adams" initials="G." surname="Adams">
              <organization/>
            </author>
            <date month="January" year="1999"/>
            <abstract>
              <t>This document proposed a mechanism for language tagging in plain text. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2482"/>
          <seriesInfo name="DOI" value="10.17487/RFC2482"/>
        </reference>
        <reference anchor="RFC2277">
          <front>
            <title>IETF Policy on Character Sets and Languages</title>
            <author fullname="H. Alvestrand" initials="H." surname="Alvestrand">
              <organization/>
            </author>
            <date month="January" year="1998"/>
            <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="RFC5610">
          <front>
            <title>Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements</title>
            <author fullname="E. Boschi" initials="E." surname="Boschi">
              <organization/>
            </author>
            <author fullname="B. Trammell" initials="B." surname="Trammell">
              <organization/>
            </author>
            <author fullname="L. Mark" initials="L." surname="Mark">
              <organization/>
            </author>
            <author fullname="T. Zseby" initials="T." surname="Zseby">
              <organization/>
            </author>
            <date month="July" year="2009"/>
            <abstract>
              <t>This document describes an extension to the IP Flow Information Export (IPFIX) protocol, which is used to represent and transmit data from IP flow measurement devices for collection, storage, and analysis, to allow the encoding of IPFIX Information Model properties within an IPFIX Message stream.  This enables the export of extended type information for enterprise-specific Information Elements and the storage of such information within IPFIX Files, facilitating interoperability and reusability among a wide variety of applications and tools.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5610"/>
          <seriesInfo name="DOI" value="10.17487/RFC5610"/>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>Thanks to Paul Aitken for the review.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+097XLjuJH/9RQ4z4+ME1FrSZY8473NncaWY1fGY8cfSbam
XFuUCEnMUKRCUPY449lnuWe5J7v+AEiQoj5syzvZPXlrPTJFNLobjUaj0d1w
HKeS+Ekg98XWpT+eBFIc+Z+lEkkkkpEUJ+fiKIjuxEk4iOKxm/hRKLqfJ1Gc
iNcn50cnf98WJ50PHXEhh75K4vutitvrxfIWwNHX/C2B3Kr03UQOo/h+X6jE
q1S8qB+6Y+jZi91B4vSiaT9wnWii3Luh408G/mdngA2dnd2KmvbGvlLQfXI/
gSYn3aujSjgd92S8X/EA7n6lH4VKhmqq9kUST2UFcGhW3Fi6gMvZRMaEvBJu
6IlTN3SHcizDZKtyF8WfhnE0neBr55edv/1pq/JJ3sNjb78iHEFkVNxpMopi
fFAR8DOYBgHjfhqN4F9PvAPsXc/1Y/o+iodu6P+LutwXZ7EbDiV9IceuH+yL
Mbeq9Uyr/47onVo/GldmO3knw8hPxEHg+kqWdHA8de+kb3fQoxa1PrX47xF9
z8BDHsdb4Bi+TwPkEJH6AfxoiVhh8LshvOtLlTV146FM9sUoSSZq/7vv7u7u
aj6wuwYYf+fCCA5D5Lv6jgaYf9c+j5JxkIKg4RSNnUbDqdc1kue3bad7PIth
mMg4lIk4j6Mk6keB+KuMUUpEG1G8bW+LczcGHsJrqkpggIIExATfOZauJ2Nx
BRL1JAIAp0kKvfg3E/Wq8NSpLyQTx+Lq4HyGziuQDqUngDiASRADqSnNr6FJ
nlB4IM4mNGB/9kHgP9BMeQKRSX9i05j/U5OYfziXQt9IEYpepeI4jnB7oDPc
flKpXI18JUAhTLFb4UnVj/0eqCHFOmmQ00moUlaQzVjrpJq4GkllgIBGEDBH
wuBeTCeIIcGdRD70Cx9CeQciQV3o9r5kpeEGKrKbICqMKDM6GggVjWUeo4C0
jAKcumq7pske+54XyErlFcpvHHnTPr5cqXQUAWUtJIAh/WkcQ3NAFZWbD8Lq
h0Px5ct/nTiHme4wKjMe9PfqjZbDOH79CsDcJMUYWl0cHeALX79WqR/oA7Rj
4P8L1Be9SuhH8FUsYDwBayDJYjiqc8NTAJcpDugKmCZFGGF3ThI52GUNqPOk
9KowiGFfCh8A+iFoCzcQfeiYGOSHIB87e1XNOl4y5jKQBg97gXn7zyn0AZxR
E9n3Bz7Q4Ib3IohAi8bi9d3IB7EB5O8ZNUMdjzP0mvjwF/4L9E1clWyjlNgy
CO/J0KORZhZmrEiZgGLRwzHBYSH4NE4KWvbh2zEgQ60AHomR5mcqmDTknq/6
U6WAgDs/GVEPPD5bHc/zkQvAMIsnWwTuHpEvDIIaRdPAQxwSEHDhisAPPxlR
lZ+hT8TT9F4VdyMJb00mgd93e4GsChdQnEwixAVajdxbeB/mqiM6KSg3REg5
QIaNW4fZbNBI1qDtlUUxTBhALQD4t24wBY7EcgKSAH8vgMEDo6JgSiIxcnma
gNVw13P7n1h2i7NxPFUJrIJ67Dwh3f6IB90eAZxk+o0aKiEQFeCzRP7bshDA
y6AEhIKVBqd5mVLKrJ05c2RWDcHqDKqWZVeJQRSAQlPE72ujZpA0aIB9g/2R
wAqOnNfMKmgfGJqTrnj95Qs+//p1u1YEFMOk8XEygFwBFJdnA0yXdFxZQvJU
AECY0bg6lMEkdSpdVp5ofiH8bBrAtANjrJ/gYxK3vhsE1Pmi/rLmustTmCMy
CNxQRlOVKWHDnV4cfQLYmhxY/6J4MoIelCTNCrAHMLKghOArmfRr2Aespsyk
Cg+LAYoEkapPqRq4fT/wE6MCwBSMcCb2gQBavTT78Tst1bi+4BRkuS4uJq9l
bVir8mwHVsXQ/B9Rb7tqxgd0yj0s8kEA2EcxSRgIMs5Q/KimE1rlYKEyQtel
BaoKViXgDrIJX7u4alRtPUmsmcSSW2pE/dBGLFOlgADYu0pmPQCfPkTEATch
RQEWNQj4peZwCzmA68tOvYHrS0Ez+TxlU9szGxEQ+9ieQF09rKS1PTkwTOTl
q1XfaeiZlM3UbOxoXuQMiUgvSqTAcYHAhQ1x/fLlPxjdOsDDpRisqltoku4R
DrFvUr+KRER8wrUEdgVKbJ1eX15tVflf8eGMPl90/3J9ctE9xM+Xx53379MP
Ff3G5fHZ9fvD7FPW8uDs9LT74ZAbw1ORe1TZOu38CN8gVrBFuTo5+9B5vzVL
LEouy0o61qRZKsacIka+Ozj/3/+p72oGNOr1tzA+/Meb+t4uruUwT7m3CK0k
/hOX0gqsFdKNEQrMYpjKE5gVgSJxAPV0B7oZhgW4+fuPyJmbffGfvf6kvvtH
/QAJzj00PMs9JJ7NPplpzEwseVTSTcrN3PMCp/P4dn7M/W34bj0sWq1TJVUm
yo6eTX0BYwFaOwqiISi3EuMGzHUJCwpIaBVN53TmV4U4dBMX9tZ9ELsq27vm
D7Z1UXvCNgAUm7Lb2o9J4W1bUwnfM9O2MTMVREfxdMue0eCrUrJoRwF2AmvG
gR/DohvIBNcUXJBovhg5QTuTZtrfRvdgUBymhpYSH8BMBNxQFbAy1kvMf1Uq
pzhptXaVHtuQBbkfu/co9KDwvcDoLqNPwJyAvQxyS4JBWxPH0Z28lTGL9xA0
UcjqZmx1AxoUtDpAQmVEeojMVTRafJdhd6+OcGGT7pgVEK/dyPZBHI1T9rZq
9RyDm5mR1jONpAcrPnDxj2zmTHjYzGuovXC6AXZ3TCaujejfIJvBNd0yVs7h
2cHV2cUlqoEIyIyngUY2dY7UYPD1CEJjWCJKrW1tYLDh383W5kw1gw2RWqy5
DlIro/AYBzeWtz5tYeGzJ0FB9alfkorrzMi2bEDx5RVZM6yCcUDQFsvsxYzx
atrTyz3sm9wQGSf7o4jNcr3cEfrwJfJRSUnbD7CCwIiUCSLxSuB2PXUQsH9A
lbEIX4btm1IAlnHTezWziDJlOPqrgrQkwxitSUTW4IUc4KwW5ABAe4ncGMcw
t5U1lKLefFsV9d2dqmi0mizhjdYumk884vcCdDTZesaCoWbW7iYdZ94ZZJYC
TlJ2C5jVWHtkcPHM4NNmCgXYm/JaxMOjwcGS0cMJjOuU/Dxypyo1u+1x1HMH
4OBOBM1uNPGMmcA6JrmLACVkPigsEDKYsSE2SnXCx9IdMjsVk/4kcm7bcnST
WjxKExux0CHm0Cf2ByZ6wl3VeMyv8x6A0tG1BJgavRJn7w8rlZ9//hlnuvWt
cfTQiMrUMTXScCIQ6fiWWc5SqveQMBy4GsBkBuZpGL4lUvA9GFeRx03TjQuw
HwiTgYdq4Ag4Srsi7FzD0PRz/6TaYh57amo0L0DjnvkpPUB+1IU/0IBInRrs
GfUc5maTygsmLGmxVJMo9Ix4azBFlkC3Z4jUna/A9PMHoB8XdqPB6M7Iz4FS
jsNOZmgp36uZKa+XhBSMjaamfadWSR1e+meHftfpd4N+N+n3Lv1u0e82/d6z
m/7BwZ9H/LYbP4hDMLAexPHZOfy+AAF9ENcf/iweji46O/jkWNDnevqtqNVq
z+u+SPcb+v2WiCce1IkHdeJBnXhQJx7UW2uhGwhAOtIfoIslgfhxevYOfncv
kR8dpF6cd36E3+smu05DWd+j38SCOrGgQSxoEAsaxIJG80XILqF+5mf9ZDdo
JBskzQ1iQYNY0CAWNIgFTWJBs/7tyF4Pye9gqgutpbVbXeSVvH4R1l6chvTT
3tEP4UWwyLU9YCtY06pepWmrQeh/j6OJ07t3RtGkvFGjSvO4nBnmJTADUAnk
f67DTyFu1t6792Cn7xbglv68xiUWdJ9Cdy6sLPH9JMGPaGVph4T0tg2IXdir
oNahz7v64VHsDmlp5u6Eo5fygX5uGreqpKu4cdPQFU1pU5NHtU391Mv7cS2e
QWeIaXmHe6sw8g2tb/XFL9VhTFDr0Ocm63kWmnHUQxfSvfgIG4Hm3l7rJm0D
Q4Q6imnXg981HEZraBpjw4l7H0Ru1hXwuGPY1NJ4daawVoWJsT2P80IGjEUF
SJ93WFWLc4YqzPCWyGYbKW/mKU8Jx7c6+hCHN6tXdDw7DdlWbDbI4DFfwMYI
NlqAoNoXg8Ad0vZRm78n3r5o79LmFMYOT3G1RV2hDrW7aJ84iG4g4mC5h9xY
VZdS0utvGjs7N6kFOZShjKGBlzp4cJUvt8BSa8ZLm8/Y9/hwVJysyrYlNJQ4
J8R645ifFWy1a99uQWkYZIwlZKjbbQIzFqPn5gRjPpzmEjgwAu5ETQMX6dBg
ihJKzjnh+e4wdsdoxd/62gxNRw7NJj8ka6qfmFXJbmUMTdtNn7jo4qXtdTeO
UaLqe803tcJQ29/d1MjiZgP8Q/dvL2KAb+zvb25/Eyf0nhh3qVHfp90zOSeI
w/CqGSSVE0nxEeTiJ3IV/YQQusc/XV6/u+j+6eTy6uLHG330dNKlcyKVavrU
L8q/EN2UC7NChPtd7a7YcVJjiOM9xMkg3xy29QCiL6VnDm3wvapBv2S3eTQN
glJ/Arlc0ZugcJv9DTX1R+SiYxx+Kypu0lvG5UB+AzxgMvNlhs3asSmWDulL
rA0ftTeEAaVYzzRJFZJI+pMzrdVznqQzlKx0CaEDWJj8nzCG44f/FO2m8V6B
+gymqXrJoIGs1kQnNE4dOnfJfHJ0rKssZ1BOTWDQiFZAll/M9Cg/s5UH4sRK
AhgMXQUqsvQUqAN0U0IvsaRTqrxsoxfWJ+MMht3DFQm0IcyQ193PJ4dqOztR
7Ltx7DN1auTGOeTgdeTHD41WE/2Ijdbutvawtt++3eXTnFdz/Yl6JctxrOjI
R25JPPEl/2c+AMBbAivvOl0YM5Gd+dYyL1F+W2FTvdAHNGf1SZemZWtQ1lHJ
qqOhLF17lq46+eWgbO3J8Fi01Gg4C9a12aWmQCGvL0afD0pQyfw7/JIZYw4g
mkx4NrFHs4+HMuSHJ6+gH5uJxCGKKg9DPxV/R/g5UOLvyNxsHurm2KeGYB0t
9+5Jympk1/yc2789xQP1dPcT7sr36Hebfrfo9y79btLvBv2u0++dou/pma6I
p3idnkar9kDUib460Vcn+upEX53oqxN9gM8D4fawPkqf5Gh6FqUNoq5B1DWI
ugZRVyfqAIcHwueBcFsjpSU/Nfwv91KL2NEidrSIHS1iB/td2sSONrGjvSZ2
tIkdbWJHm9jRJna0iB0tYkeL2AG4PTyjz59z+5bNkrBZEh65JPC+xRYAqTcF
eiNDWxjdfnYPg/YVU4V7qHTvAvKf7VrCKKkWzB/eiXQLG4/KZnHaLE6bxem3
tDhhvMa5iZjvYHiNHcl5ke53XpnA0cfssLJQABM2DVpNh6zSiTvo4j45eOYG
SOuz+cJ+y+zD9iuVB1RTZT8PczwTwLEH4ffHE3SOHMA6Cjv+3bTN8lwRaJnL
Fcn/zYkUDAz7GXI/q4OHBg4mRjl6dZh9YtJRis+detZtnrz248grJMMUn2Qk
2l29ABdfFZ4Stcru+IWGb6ZjNLdUCcUvwdhXM8+dxgzFv1DHTe54Evu3ME27
HIsKJhsnIRkclqIg04apVM8+YvZ+2edEqR+2DnyK8y0oommIHsI52uKrjv41
AesHfpIeelxkwdFfXllR6avqs4IGGhjb2iTWdFMdt0JYG0eojSeBuoom792e
DFCgKpXfo9+IXKdO7miDjUAy7IVvvG3GwuYUsolJIWPPG3TKmpXsumjiRANH
JZhjEWB3NfFXjqNjd2kKHA3FPP6n5+8vuY3A6WelYqHf9fG5ga84cgtpdwgs
zeoa0zzHl0xdcdh4c6dZ1+wvYJdmJ9RSpzNSggNUoMEKgNNWNiYVfVxKi4Uz
RyHe1GDEYFv3Kxmx5Tx+AaatKAA3tUcOMs0geOPOpb0Zn1+kM8jsVAqDog+B
Sk5YsjxFnrQGbpm5qKgvM/MHAXnfOWnNTWDERsCjWLqKJ3oJgCuKRryPpol1
HBuRWUTRmVYCUUnr08t3SBhtvnDJR9sTtx+4CuKWC9eGPXrj/eW7+ebuH7Qh
OPf/+U0f9HHRAx4SIZ0CF0h04dMBUz5W57G9lrU1snmUjovGAJWqY2d3JmXN
nyCkmQQ4PNzlI9n97GIC2ZyR4oPPfbHzeXdH/KBP2oo/PT90MZF+p75DP2Xv
eBIZjO+YJ84fDTMWb2gYJr3/IRKDaYxeF9udsATxN28B8XpzbxHmiDj8X1+E
ed0EQyEmh3E0WYY2AqSX37meuLp6X1muvbY+yITcRCZz/C15jRxOtEB+wdtb
+Y4/HhycOR+O3h6dXpkgA63SNyrkN6VCNjP132imrqLLTbdgZaxHf5sDe5Or
ywFRXUz5lifeAuNbdGDb4f8TcyfSk+7UOJHUnm04T3KCmDbiLiVnf4mTQ3Tj
ThV7WQ9y/QtGAN7RiV2ZkSg/J2k3BVjzoOgTflNjAFOL0viv7PSaQhs4WZwa
W6ysVVY1M+eRoZ6/RciPkMMsdnxPLTZh5xvjmwF82gAun8nrHV2y6WHZ6oYe
rwoLt8RSL5FEKi38PHqciWb2S7OE53pY14YWgQItnsM4PVVS107Vasp4uSwI
99b1A0pdf9a+r8CnGx50oO4s9odEZTgEbDGEGUgJxgsk4ES7jxWee9FqSeGu
Ovj5Dowgk+3Zk313qoDU2B3gRIp0Xxn3tIsLDZDJtAcTC/3UiAQVVhnXxCRS
yYfO1WU0jfvkc9RIVs03Vm5AydfnuiWV/8F4qnP4n2OEzQsWgNxbNNb/nLoB
J/RTLCSF1NkI0gEymL36QHSBnMxn9bqmAkB2oqwLRyPqMCdX9/Q0GpYTIB/H
B/xe4HvZSMaLScZq6iR1FQH1whKFAmbPUiQLpazgTlomSVoFdW8pH3ixF7Zs
62d5+FyiWSIkK+Y47wEktxxl1Vvvmg2KRoofKxMeWhW9aZIWTQr8sc9ZxVV6
N0GpCBgnluzZ5x4YIPj8agRsGkVgElxI2mhijRXraZdClik7COurFK2JMvJn
RWkLeyd2UgzyllWqSD1XtRBjHus1XiIB9ruN5u7cd7neVy/6jOnKWZs39dab
0jY0mjplfdept5c5jDfC9Rzheop2yuCo5+ujTDQfp4B+OfEjC9uP5Z0bBMvU
XbaKumkbI1AdLnhhgJeYo3YnazOyNVBm9FNt7Jeg65GSl+/2mZKX54q2qHs+
WtqHfix1ScJF7o2SUHjPtLQ2l2IMxlTkcdgZVp+gb+j1d9SdYFNGV11KjZba
fOV22vkR97uYssil+mBMaNOTq5djtru6W+Ab9qayTAZKJnPD2Vo62PSMguG4
38MIY+zszAcT+qcTeOYpYUW6cRZP7VzmZJFcvpJrmIK1ZlQ/mmCkY6Lrb0zH
plSjdhYM/OE0dlcdATqxhh1aNE3wnLAHDK+JtKoXxwGW0EjcA0bezyc0x18d
MwiMLeEh+mrnsZ0dJTogUtdyokotNGcCH/aR98Rw/Yfk1YQSTTSrs/3ma78m
a1WbqOvD8+3qfBp0h1mNKzqpt4ZrgRFcmDcFzfX0ScpwnXRQb57uy9rM1s1s
3czWxbP1kesxw7EG0az/z1mXS6Y8Lc1RNjoUerks9kcb9FYzro+5gC9lXazL
CLNgO4THCnuxBduetVP3yKGf6Zh3UM8a+XIWacvMDaPwfqwrvl/J/oiOJhYI
QKnGz0ERiQGT07xZbU6vdOYZhWG/ZwoYwp6R6uymgHVtvqzIMOdOQz99GVOV
4tL6c7i4gPxHY/jT09kKtFNZ1GrB2Jdzb12ynYPupMSvda3ejFz5yD1y3s5h
4zN19hwByI4plijrRc7VdSph9Da8mAus3s7F3828u7trv92u7873WMDb7eLb
7YWw27m3G28Xvt3Ovb2z93Y+3uh6zzlNGjs7i15e5KtbfZSf4JFK1uOLepYX
aiMBLAE065U+uu8EwygGxbvoTHIVLy6dKnF2I4PG93irkJYUP/KDhO6IqIpL
dN3CJ6uoglkqdIHcyxSKNuhr4jRSJjJMyRQ41fe14v7FkQ4zKl8A0CHM9Xyx
jOY0SO9ouJ/F3xw+Wb3xVRsY34w5k3a3eMpt3tITqCcpCK60VPjuXgvrGR/x
QOVgzal6W4CTFHJox5EngzTmn/HB+3lUxrK5YDW+aQKA2eOlkSUZV2e+Uula
7GmuphHXRD9ssrA27HBEFx6EEsfSjWmpZmq4VnwZalY5kHJ+Z4kIc2XPRtTm
IKYMr3DDzES5+WQaLu6uk41jrE5268a+TKg+8ySCpmiMZA1YwPtp7Vyl+QxS
jUWf74F7CW4NzdwQr1vbdHSR3a6SUI98lCHcYSwpVzntIK2L//T4jM38Xj6/
9UxN3/ztzdcXnKm/yhkza8qcX3ZOz21IK1k0RR2iDW9LGDQf0eO4xBYv332Z
ylkeuizTw9JQu95KEu1rVyRgdCdDVrmuHJaypdjUv25y7XhsMXst0imJtn0n
xvd0RM7XOGkIOKR8JYjVMgrT816VBp+n0+fjfJbdYKRt8UotbXXGxnal2MPZ
Ckhlqi8rNVaA6yv7CdcKTHgzmfmjTfofmWEIhCY2FyTF67y4xhvMhzFsxtzQ
V2MOf+Q0Yovzuet7zI1qHEiDt1pMYR7o4lk4uy4T+MLFO0A6zGNzlNpAcxNg
gc6BKbrenf9G9jayty7Zm9W4wBGTipJh9qx9pDWOjoaNF8K5nIk9VzenFQcf
q5yVaZibFyXjbiSnZGJkcyuDVjoxGr/AxMhZNB/ni3HKsZn5kQZwoyWCpBKo
7NKnPNtMy+/5Oa7dIDacJLLzeWdHvAac3GmQbKflYxK6WEnTBiZABkyfPUU6
7gGQ+B6PxPSVHD10LIb+BGvIsqnqllxag+dOR3iB3wXXduQw+0jyqRFlcyuc
DQjYxVhL2GGbwbUweYpqSHn6bNWQIfIo/ZA1+/dfmjYzbzPzNjPvhRbmlSfX
+ldr0/Xctfo69JNHr9NTbLSqpsgKr5nR4OZ49abf93EPWpiu5dm1WVCjpUxa
v7x1O8tDRUx8rP64oqO4Jnv+5quNMArlHJ2Ragf6OsS6KUqtYlR/XDKBiZ68
QlznYvPtxefy3198fr3SMKsAVxrw9Ss/6tZE3WC00gXWPAQlHy/O8pCC72Xl
KkfaHXhvqpapRF886nINRXbN0Z2EnazW/b9kHKUFzlQ2QtyEYejYqdTFVhW+
tF7y8+ZTdqX3nQsSYjG/IHymEZaatAhRJrl0EE1x+VshrxqjWPy+dGjxdRCW
Y9e8fGJ+4zdjLgWmrcjfxRL+rZmfE+huuCh7fRnHJd4O+yx+I4SNKP9yjP1t
iTGwC/P2TrAg3MDty6WV0LIUJ9+0wWjTWJZWUKY1ryf5lvu+9G+lvteGx4DO
R/SZXToqYDK7QwoN/Ade1vk7f4BI/Q53DBanly9V8NAfUInGsd9bMhSPhLZY
LL8Rgx5rFuiht9B8jM8yxw+9v5G/lCyp9BxyI0drZc6jnd5rFSGUIcLwkKrQ
9KbY6ykdCz92j1zIvvAMQMa/D/qTTkXJe3aAJQGpN+DeEQXzA0G82+kMgcIh
eXqIzTHFxNsbC3QAhXZCg05f0FfgBOgfyoJDrzLcaOWQY+19MT4nfaQPy07o
fJL3C6+VtsJPqVPaEN2N/P5ID7Rn8ZGPteG5D6M+kZw/8T1Wf0dQOpc7IPJP
cK9GtLih9x3AzH17EGEya1IeG6usTAKEm97Ijn/dp1musJshuSMuIyNsRJk/
VZyo1IgCB2CFlCYACS9dLGlhCf2sAIl5fi+K/3Hp5j6kytTyT4/7SzipAyue
GURKgB0bsKPpWOdufzMRNhPhxSfCI1eNTAi9LJzpOe6HuVPpJqtqZEpArTOO
lEwdEFyUEZ4WM8FiVibA0uAzXxVjz1booBiNZsXizwSknYBY5vPn0m9fq+30
vol+AIKbhqNh9NE3C2V7XGxY6ThbQf8vEzV2DuxSsuALnExjmDnm4kUuMpkx
wRqkgovSrobts5T5YzxwYQFE0w16m8b852Aack3rglWLzS5JE742ztb6tr7g
cQWZvcrQmxeV+rTCgFkVKhPW7ZpheumY0M1c3czVRxeKyGYtHm8aLJ9bMaJM
/PVKhaf47/3w0xGivEpZ+jLJN7KQL0nDJ+bYLS7BGC0A4vwJb04egz12mD7I
DisKCmUGt3WlU1FQE/btEDKcWpXKkz6zMzJUqINup3Lnxs6qIUIXSamIXxpP
g8SfBLk81tSxdnbxOxTQIZUt0zcwp4wJ6J73vMPv48nl2Xcn3YPa3u7bN059
v/727e6S4gLQptvtvtlp1Jo36cd6/aYU1BP03jcY/d/sUM2arnnOrSPMr0z6
b3ClKBxsuj2sN52U0JnzChOlqwuYvgzD7x24Eyztf+WP5SoRhLkif6ERksAf
yMQfpxLHFTThw+nJO72BwPp/scQiw7emGIV5gWJIEJcz2hSdWEkCfA9bdvBq
vPZm28aw0xoXVGSQg3KKnfQDMMtihMGX2mFNLdov63qfDEMQFZyEO6BQf161
kD0qAVNAX/Qn7AuEaY6hVFgFOXKxCFl1B6KDOCfTehAW6ZTiqA+70+mcbtYx
NAfvVlE4RunV13kWKyo5RnPv8gOmAmCIUT4g51TqtAQrZmm2KIgeK3Ouwj28
zo5BSBjRGgqAk949YhbIbaFjm3wKFQCQLtfL+BRqgZCfMXxaaaOK2E3wqIKG
m01Ha+oj73+fXsCnRibvYuLSlcxpAcazk8NcQY9Lc22FxwOjUxub9SbmtV36
Yz9AE4puQvT8AbkSEpYVnhOEnRUXlr1UGDBpbBDrur9ccZaE54rn3/reFKib
M+/KDZtyiskpsITkBXnh8zBY100zfs/RXHSQi2lI1JMP/jaKZ6N4Norn/4Hi
eaRldmtXs5QzXLSjap91c9JchZZVqfjLNEpcU2xzHWVtbUOeK4tSF2lBT1M/
8RkVPQsAX6h67D+xF0fqXlYpJLlqeQHWLre7sHngsmq61jHpvxcvB/p899S3
H95Hn/1y8UxK7TVwsSsa4+dX0CgTlZuVq018Y3Ew5WpM6d311LbOy0hW1/f5
4mHVCH6ZiZ+YDjZz/luP5jMX1hJk11EvJy8fv6KJLk591RdfXo3hn0fdz1xy
WD97ZTOVYbHvPmXdorcY2jY99QOQArD0Qm+RywZdZG5PRQGd/qf7CaqBiUfl
qVFtGZF8nI7X6bjAAjLF58gib684hG1eVtSC4qbZDqVHbizcavEJiOnZ7B2U
coeSCoXm63Wi4c8RD/QGH3+VdFW1z8q48EtlcSDWhmmJdhPyW6eHrYOR7H9S
08WH6GCFH7ZEX7+aT/YwKBW5FNub13XRDDu7SBPM8J8hLJy+li+bSsX5orAv
udjtEIYzzKMBBEWwHwn6lDZobWhNEF9p3wM/xuJE04EO+ZhLJa7QSZLfKi+A
bOJrMABacpZKWMCubORAsaJHHnrRKOUPnXXxsmYDtHVVTAKKB8w1Y8TMOXc5
u4G5xhMCbbkjihMxfFxQdjgNZ3FxgVWYpCQtKmCUKNMrlgN0rqMS9elOGsDQ
x3RMXY45PZQT7tAP/CQL19HZih7jiTxCB0SIchBHk5iOfjWmsFkfSpUsQHjk
cg38z4BwIMNhQvdZ19si6icS7xJbrJV+C3NrM5M2M+kXmUnFyr9HeM9p/sJq
vL2UftIPuY8r/fyh8oBHmBig8UBJ03SJ5kPO1lv+8wBQXr+/fCd+gKbZ0xVa
FqHsbBebPh7Kuviy49QZgcuDFJfLxO2xXNAdePs6x1MWv8gomiXjQSSUy2ut
ziZBNE00rdVrOb40TNPzcSf9KGOfwkREx5aUffaWYzTk6/p21YZShgtvQ5w5
wTeFcK+5UD5y2mvzhuYLhddPYgo1dbGSP/yJ+7ZluOi9EGbuI1e87JaBPH6L
oczFPo/kEigFGuhPpMHC0Wy3FkDRUXWczaojjVEdlv/M5Ut5LWRQ5bNcWYEv
rA1Rco287dUatQbR40lYZQJYGOZBIZ0GKoMDuj6cXXHtf30vQfGehLkUUZg0
aGyuoa5PSYwsAh4r8cUWkO3yrHDLRJgHhW5PVYnMF8omy0Dj5aPTYwkuC+YR
qXu+XBW0+GIoMqnq5d7ksVPtKHsmmHOd+VA0zRSil/VLsHFeUYLdrYyVW9vW
UJqm6fuzi/RjdOecxVgM5DrEqhlD6RV1i5b+RRThnQYRQen5SXqHuZHoQiz6
Mtk1VhDdCEjb2Jq+Yp1KbZgLSefOactOMJM3Xxgc0MvenwMllMldFH9yAnkr
LX2A+2vQ6oF0b+0ZPg/KKFLJDAjADg/76AIOj89eF0OhO0tiGGYEJwico8yR
VlVv+bng4wIolAB65yuZHrhCx7FEESkwqLYAykoKYek8AuRDfddvz1XSm6P8
ahmUXafeoqYXzAvP/ojDPJjSqRoQtm+pAwpElQv58hrMER0sO3vcS2agDmpd
SJE/DKM4C7stc5hYP+uyX+j+cr0f25iLC6D8Cs1Fy0xEjfWRCp83Wzc1A2Vj
Lm7MxRc3F23JmwslZ1Mu/dkYnRujc2N0lkHZGJ0bo/NXYnSWF2DPLMSFpRGu
r46cN+ZUu914+/WrkGE/wslzHfr4QWDSLNBhOcRdMZqO3RAvc/fIViocVbul
t09xDgaC0YmKyKiFmJsbLamwZiZedFmjruwWgMqaog84cYdK07Hbxitsqikh
fojpE+bsvrH7Bs/5reNY5gGTWc3NSytPLOsJXrCOdi1sQfPcxX4C5NVsNosE
LCxslaarGFCKCATMOVZS2Vl1pEfvwhyB36cO/T7MmuosAhbTzU2NaXt7vUDf
+q0bUKCodHFMazBirCp7ChPleRjvc91zh1u+o2ulbhmONvb2gKPFnjjDBy/n
rKVBI2DRTGMyw3E99nRyvcpV7MM8WbSCjODBquRRKC5+WXrEwslGVG9g0aHY
Rto30v5vJe3Qq65g2a6bu66eK/2UJIoB+GE/OcC4/LOBdXvwyXmH7ZAlcRkU
0Y/4GVC2dSpOztMwKiv460zXvtCVQfp2sRBTvqJQJaRKo49pa/g0JpMEgKNN
4i+86hgeTyj/Ic4ShnUrR+cl9LO0BL2Vn4YBFSOaDf5XEnOA7ZonCldyg8eS
g/bfFLOexSas8aW9CVrOLsCGf1IljVjq+6GVzsrIb/BpczDWBa/wBZ2b7itT
gyXNr6EdMY4HUa8zQWmLjPmaWeien5aLKXoTdGeudd8OZlveysWS8YtTZvSO
wd8eA3HSteIVZ6gnzTFPYVUqHAKhzNf9vD6jbGBf9adKmfgE47p4g/PiP0DF
7e3UGxSdCN1QsGOxi44pKKNjInHXiO+5fauTYrleujw7d/MUbmasFhxKMJHE
NGRprRiC6QYqWhiHmRYPgt2EO81KdmzNrZWrtnKF1NP8nwxSWs7HoE5zR6fI
WE1J6Z/ftmFrAgstRVAcU8F4tTSSlPLHsAY7FkKw0cEQ4wRHf8uf3LZTwBqu
eOcj/lSBnkOGsvLDKYiZkNMrkjoshhQYLWeCYuyu6fY0pcNYlXaUw9SBPnFb
RJSeGbe2vYXBb3eq4hB2YvTT3tE7KWtt02FGMMpICDWpV8Xx2bl+1TQ5jiZO
794ZRZOSFo2quBbFn+vQBDvTO01458OfZ97BDLJQvKeM610bZunPa6yjRB4B
j2y3+H6S4Ecu+jThdMFtar9bFUcXHUZ/d1e3P4rdIfud+AIBR4cwDfRzatmq
iotj3WBXu3/ERcTLjIVhm3qol/fgWjyCbhDBkq72UObq9YWMqwN3T8/e0Vf1
ZovfoUEfR9o9jx7O5t5e64YbAKu7l3oAW3oAu4ZZmT6auPdB5OpOgF0dQ3RL
I9SZYoJbYnxHx5aIAI/OwS6lzztv+PVzhifMGBXFCvh1fHKu6XjLbY7ROcOZ
oYCRucyA39+rgpl4ctom9DQZlyN/3C689yZjXaOlx+taSZ1DM6ETBTMgFEVH
0j/kxm/txruPa9zYweFrtFpzRo8cDVaqHgoBV2vxfLA9scy7rgTnF0ql/40c
RKSEaH+FUVwmcwBj40Kt3451KDv84XSPcUPjgoBJqviAjdLaFLpYRJb4AE1p
NVykznJKSIcfFu66mHqTbNOVrZK67O/Yj2PjTDTod49B8xEuFDtpVi2kyvMY
N675FNmEgdbDMhf7lf2VeVPQ/XnWhOIjWCA/kS7+Cd/vHv90ef3uovunk8ur
ix9vcsxLmYZ9FuGuAIiXRbB++rjfAOkJ7oEHjuOIHlgpuLZ3+qgHYXkh1aAq
X/a5nrD0ftgawFortygJwg0/UeryOWytRMdP6KoazeBY3voSg+7/D3mozxs1
3wAA

-->

</rfc>
