<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.8 (Ruby 3.2.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-opsawg-ipfix-fixes-07" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.20.1 -->
  <front>
    <title abbrev="IPFIX IANA Fixes">Simple Fixes to the IP Flow Information Export (IPFIX) IANA Registry</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-ipfix-fixes-07"/>
    <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="2024" month="April" day="16"/>
    <area>Operations and Management</area>
    <workgroup>OPSAWG</workgroup>
    <keyword>IPFIX</keyword>
    <abstract>
      <?line 55?>

<t>This document provides simple fixes to the IANA IP Flow Information Export (IPFIX) registry. Specifically, this document provides updates to fix a shortcoming in the description of some Information Elements (IE), updates to ensure a consistent structure when calling an existing IANA registry, and updates to fix broken pointers, orphaned section references, etc. The updates are also meant to bring some consistency among the entries of the registry.</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>
    <?line 60?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>When OPSAWG was considering <xref target="RFC9565"/> which updates <xref target="RFC7125"/>, the WG realized that some other parts of the IANA IP Flow Information Export (IPFIX) registry <xref target="IANA-IPFIX"/> were not up-to-date. This document intends to update the IANA registry and bring some consistency among the entries of the registry.</t>
      <t>As discussed with IANA during the publication process of <xref target="RFC9487"/>, the "Additional Information" entry in <xref target="IANA-IPFIX"/> should contain a link to an existing registry, when applicable, as opposed to having:</t>
      <ul spacing="normal">
        <li>
          <t>A link to an existing registry in the "Description" entry.</t>
        </li>
        <li>
          <t>The registry detailed values repeated in the "Description" entry. This practice has the drawback that the description must be updated each time the registry is updated.</t>
        </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>
          <t>Updates that fix a shortcoming in the description of an IE (<xref target="desc"/>).</t>
        </li>
        <li>
          <t>Updates that require adding a pointer to an existing IANA registry (<xref target="to-iana"/>).</t>
        </li>
        <li>
          <t>Updates that are meant to ensure a consistent structure when calling an existing IANA registry (<xref target="consistent"/>).</t>
        </li>
        <li>
          <t>Miscellaneous updates that fix broken pointers, orphaned section references, etc. (<xref target="misc"/>).</t>
        </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>
      <t>Likewise, this document is not marked as formally updating <xref target="RFC5477"/>, <xref target="RFC5610"/>, <xref target="RFC5655"/>, <xref target="RFC6235"/>, <xref target="RFC6759"/>, <xref target="RFC7014"/>, <xref target="RFC7015"/>, <xref target="RFC7133"/>, <xref target="RFC7270"/>, <xref target="RFC8038"/>, and <xref target="RFC8158"/>.</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>
      <?line -18?>

<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-an-rfc-is-needed-for-these-updates">
      <name>Why An RFC is Needed for These Updates?</name>
      <t>Many of the edits in this document may be handled by the IPFIX Experts (informally called the IE-DOCTORS <xref target="RFC7013"/>). However, and given that many of the impacted IEs were created via the IETF stream, the following from <xref section="5.1" sectionFormat="of" 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>
      <section anchor="forwardingstatus">
        <name>forwardingStatus</name>
        <t>The current forwardingStatus entry in <xref target="IANA-IPFIX"/> deviates from what is provided in <xref target="RFC7270"/>. In particular, the registered Abstract Data Type is unsigned8, while it must be unsigned32. The following update fixes that issue. The description is also updated to clarify the use of the reduced-size encoding as per <xref section="6.2" sectionFormat="of" target="RFC7011"/>.</t>
        <section anchor="old">
          <name>OLD</name>
          <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
                   [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].

   - Abstract Data Type: unsigned8
]]></artwork>
        </section>
        <section anchor="new">
          <name>NEW</name>
          <artwork><![CDATA[
   - Description:  This Information Element describes the forwarding
                   status of the flow and any attached reasons.
                   IPFIX reduced-size encoding is used as required.

                   A structure is currently associated with the first
                   byte. Future versions may be defined to associate
                   meanings with the remaining bits.

                   The current version of the Information Element
                   should be exported as unsigned8.

                   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 "NetFlow Version 9 Flow-Record Format"
             [CCO-NF9FMT]. See the Forwarding Status sub-registries
             at [Forwarding-Status].

   - Abstract Data Type: unsigned32
]]></artwork>
        </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 IANA 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>
        <section anchor="old-1">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt/>
            <dd>
              <t>See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mpls-label-type.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See <xref target="RFC3031"/> for the MPLS label structure.</t>
            </dd>
            <dt/>
            <dd>
              <t>See the list of MPLS label types assigned by IANA at [https://www.iana.org/assignments/mpls-label-values].</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-1">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See the list of MPLS label types assigned by IANA at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mpls-label-type].</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC3031"/> for the MPLS label structure.</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="classificationengineid">
        <name>classificationEngineId</name>
        <section anchor="old-2">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt/>
            <dd>
              <t>Values for this field are listed in the Classification Engine IDs registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#classification-engine-ids.</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-2">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt/>
            <dd>
              <t>Values for this field are listed in the Classification Engine IDs registry.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See https://www.iana.org/assignments/ipfix/ipfix.xhtml#classification-engine-ids.</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="flowendreason">
        <name>flowEndReason</name>
        <section anchor="old-3">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-3">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>The reason for Flow termination. Values are listed in the flowEndReason registry.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See the Classification Engine IDs registry available at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-flow-end-reason].</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="natoriginatingaddressrealm">
        <name>natOriginatingAddressRealm</name>
        <section anchor="old-4">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt/>
            <dd>
              <t>Values are listed in the natOriginatingAddressRealm registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-originating-address-realm.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See <xref target="RFC3022"/> for the definition of NAT.</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-4">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt/>
            <dd>
              <t>Values are listed in the natOriginatingAddressRealm registry.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>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.</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="natevent">
        <name>natEvent</name>
        <section anchor="old-5">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See <xref target="RFC3022"/> for the definition of NAT.</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC3234"/> for the definition of middleboxes.</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC8158"/> for the definitions of values 4-16.</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-5">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See the assigned NAT Event Types at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-event-type].</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC3022"/> for the definition of NAT.</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC3234"/> for the definition of middleboxes.</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC8158"/> for the definitions of values 4-16.</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="firewallevent">
        <name>firewallEvent</name>
        <section anchor="old-6">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>Indicates a firewall event. Allowed values are listed in the firewallEvent registry.</t>
            </dd>
            <dt/>
            <dd>
              <t>See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-firewall-event.</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-6">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>Indicates a firewall event. Allowed values are listed in the firewallEvent registry.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See the assigned firewall events at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-firewall-event].</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="biflowdirection">
        <name>biflowDirection</name>
        <section anchor="old-7">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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].</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-7">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See the assigned biflow direction values at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-biflow-direction].</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="observationpointtype">
        <name>observationPointType</name>
        <section anchor="old-8">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>Type of observation point. Values are listed in the observationPointType registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-observation-point-type.</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-8">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>Type of observation point. Values are listed in the observationPointType registry.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See the assigned observation point type at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-observation-point-type].</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="anonymizationtechnique">
        <name>anonymizationTechnique</name>
        <section anchor="old-9">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-9">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See the assigned anonymization techniques at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-anonymization-technique].</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="nattype">
        <name>natType</name>
        <section anchor="old-10">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>Values are listed in the natType registry.</t>
            </dd>
            <dt/>
            <dd>
              <t>See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-type.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See <xref target="RFC3022"/> for the definition of NAT.</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC1631"/> for the definition of NAT44.</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC6144"/> for the definition of NAT64.</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC6146"/> for the definition of NAT46.</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC6296"/> for the definition of NAT66.</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC0791"/> for the definition of IPv4.</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC8200"/> for the definition of IPv6.</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-10">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>This Information Element identifies the NAT type applied to packets of the Flow.</t>
            </dd>
            <dt/>
            <dd>
              <t>Values are listed in the natType registry.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See the assigned NAT types at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-type].</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC3022"/> for the definition of NAT.</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC3022"/> for the definition of NAT44.</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC6144"/> for the definition of NAT46.</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC6146"/> for the definition of NAT64.</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC6296"/> for the definition of NPTv6.</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC0791"/> for the definition of IPv4.</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC8200"/> for the definition of IPv6.</t>
            </dd>
          </dl>
          <ul empty="true">
            <li>
              <t>Note to IANA: This change also corrects errors in the pointers provided for NAT46/NAT64.</t>
            </li>
          </ul>
        </section>
      </section>
      <section anchor="selectoralgorithm">
        <name>selectorAlgorithm</name>
        <section anchor="old-11">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt/>
            <dd>
              <t>The following packet selection methods identifiers are defined here: https://www.iana.org/assignments/psamp-parameters.</t>
            </dd>
            <dt/>
            <dd>
              <t>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.</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-11">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt/>
            <dd>
              <t>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.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See the assigned PSAMP parameters at [https://www.iana.org/assignments/psamp-parameters].</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="informationelementdatatype">
        <name>informationElementDataType</name>
        <section anchor="old-12">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-12">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt/>
            <dd>
              <t>The [informationElementDataType] 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.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See the assigned emelement data types at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-element-data-types].</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="informationelementsemantics">
        <name>informationElementSemantics</name>
        <section anchor="old-13">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-13">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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 [IPFIX Information Element Semantics] subregistry; 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.</t>
            </dd>
            <dt/>
            <dd>
              <t>The [IPFIX Information Element Semantics] 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.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See the assigned semantics of an IPFIX Information Element at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-element-semantic].</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="informationelementunits">
        <name>informationElementUnits</name>
        <section anchor="old-14">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-14">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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. These types can take the values in the [IANA IPFIX Information Element Units] subregistry. The special value 0x00 (none) is used to note that the field is unitless.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See the assigned units of an IPFIX Information Element at [IANA IPFIX Information Element Units].</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="portrangestart">
        <name>portRangeStart</name>
        <section anchor="old-15">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt/>
            <dd>
              <t>Additional information on defined TCP port numbers can be found at https://www.iana.org/assignments/service-names-port-numbers.</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-15">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>Additional information on defined TCP port numbers can be found at https://www.iana.org/assignments/service-names-port-numbers.</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="portrangeend">
        <name>portRangeEnd</name>
        <section anchor="old-16">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-16">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>Additional information on defined TCP port numbers can be found at https://www.iana.org/assignments/service-names-port-numbers.</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="ingressinterfacetype">
        <name>ingressInterfaceType</name>
        <section anchor="old-17">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>https://www.iana.org/assignments/ianaiftype-mib</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-17">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>The type of interface where packets of this Flow are being received. The value matches the value of managed object 'ifType'.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See the assigned ingress interface types at [https://www.iana.org/assignments/ianaiftype-mib].</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="egressinterfacetype">
        <name>egressInterfaceType</name>
        <section anchor="old-18">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>https://www.iana.org/assignments/ianaiftype-mib</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-18">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>The type of interface where packets of this Flow are being sent. The value matches the value of managed object 'ifType'.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See the assigned egress interface types at [https://www.iana.org/assignments/ianaiftype-mib].</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="valuedistributionmethod">
        <name>valueDistributionMethod</name>
        <section anchor="old-19">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt/>
            <dd>
              <t>See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-value-distribution-method.</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-19">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See the assigned value distribution methods at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-value-distribution-method].</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="flowselectoralgorithm">
        <name>flowSelectorAlgorithm</name>
        <section anchor="old-20">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt/>
            <dd>
              <t>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).</t>
            </dd>
            <dt/>
            <dd>
              <t>The Intermediate Flow Selection Process Techniques identifiers are defined at https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-flowselectoralgorithm.</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-20">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See the assigned flow selector algorithms at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-flowselectoralgorithm].</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="datalinkframetype">
        <name>dataLinkFrameType</name>
        <section anchor="old-21">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt/>
            <dd>
              <t>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].</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>(IEEE802.3)(IEEE802.11)(ISO/IEC.7498-1:1994)</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-21">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>This Information Element specifies the type of the selected data link frame. Data link types are defined in the dataLinkFrameType registry.</t>
            </dd>
            <dt/>
            <dd>
              <t>Further values may be assigned by IANA. Note that the assigned values are bits so that multiple observations can be OR'd together.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See the assigned data link frame types at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-data-link-frame-type].</t>
            </dd>
            <dt/>
            <dd>
              <t>More information about the data link layer can be found in (IEEE802.3)(IEEE802.11)(ISO/IEC.7498-1:1994).</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="mibcapturetimesemantics">
        <name>mibCaptureTimeSemantics</name>
        <section anchor="old-22">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt/>
            <dd>
              <t>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.</t>
            </dd>
            <dt/>
            <dd>
              <t>Values are listed in the mibCaptureTimeSemantics registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mib-capture-time-semantics.</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-22">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt/>
            <dd>
              <t>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.</t>
            </dd>
            <dt/>
            <dd>
              <t>Values are listed in the mibCaptureTimeSemantics registry.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See the assigned values for the MIB capture time semantics at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mib-capture-time-semantics].</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="natquotaexceededevent">
        <name>natQuotaExceededEvent</name>
        <section anchor="old-23">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See <xref target="RFC0791"/> for the definition of the IPv4 source address field.</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC3022"/> for the definition of NAT.</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC3234"/> for the definition of middleboxes.</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-23">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See the assigned events for exceeded NAT quota at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-quota-exceeded-event].</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC0791"/> for the definition of the IPv4 source address field.</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC3022"/> for the definition of NAT.</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC3234"/> for the definition of middleboxes.</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="natthresholdevent">
        <name>natThresholdEvent</name>
        <section anchor="old-24">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See <xref target="RFC0791"/> for the definition of the IPv4 source address field.</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC3022"/> for the definition of NAT.</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC3234"/> for the definition of middleboxes.</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-24">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt>Additional Information:</dt>
            <dd>
              <t>See the assigned values for the NAT Threshold events at [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-threshold-event].</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC0791"/> for the definition of the IPv4 source address field.</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC3022"/> for the definition of NAT.</t>
            </dd>
            <dt/>
            <dd>
              <t>See <xref target="RFC3234"/> for the definition of middleboxes.</t>
            </dd>
          </dl>
        </section>
      </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>
        <section anchor="old-25">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-25">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="messagemd5checksum">
        <name>messageMD5Checksum</name>
        <section anchor="old-26">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt/>
            <dd>
              <t>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.</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-26">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt/>
            <dd>
              <t>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.</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="anonymizationflags">
        <name>anonymizationFlags</name>
        <section anchor="old-27">
          <name>OLD</name>
          <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.)   |
+--------+----------+-----------------------------------------------+
]]></artwork>
        </section>
        <section anchor="new-27">
          <name>NEW</name>
          <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.)   |
+--------+----------+-----------------------------------------------+
]]></artwork>
        </section>
      </section>
      <section anchor="informationelementdescription">
        <name>informationElementDescription</name>
        <section anchor="old-28">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt/>
            <dd>
              <t>See the Security Considerations section for notes on string handling for Information Element type records.</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-28">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
            <dt/>
            <dd>
              <t>See the Security Considerations Section of <xref target="RFC5610"/> for notes on string handling for Information Element type records.</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="distinctcountofdestinationipaddress">
        <name>distinctCountOfDestinationIPAddress</name>
        <section anchor="old-29">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-29">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
          </dl>
        </section>
      </section>
      <section anchor="externaladdressrealm">
        <name>externalAddressRealm</name>
        <section anchor="old-30">
          <name>OLD</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>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.</t>
            </dd>
          </dl>
        </section>
        <section anchor="new-30">
          <name>NEW</name>
          <dl>
            <dt>Description:</dt>
            <dd>
              <t>This Information Element represents the external address realm where the packet is originated from or destined to.</t>
            </dd>
            <dt/>
            <dd>
              <t>See the internalAddressRealm IE for the detailed definition.</t>
            </dd>
          </dl>
        </section>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document does not add new security considerations to those
already discussed for IPFIX in <xref section="8" sectionFormat="of" target="RFC7012"/>.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>Sections 4 to 7 include actions for IANA. These actions are not repeated here.</t>
      <t>This document also requests IANA to update the reference clause of the "IPFIX Information Elements" registry <xref target="IANA-IPFIX"/> with the reference to this document.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references anchor="sec-normative-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>IANA</organization>
            </author>
            <date/>
          </front>
        </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"/>
            <author fullname="B. Trammell" initials="B." role="editor" surname="Trammell"/>
            <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>
        <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"/>
            <author fullname="B. Trammell" initials="B." role="editor" surname="Trammell"/>
            <author fullname="P. Aitken" initials="P." surname="Aitken"/>
            <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"/>
            <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"/>
            <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"/>
            <author fullname="B. Claise" initials="B." surname="Claise"/>
            <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>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC5103">
          <front>
            <title>Bidirectional Flow Export Using IP Flow Information Export (IPFIX)</title>
            <author fullname="B. Trammell" initials="B." surname="Trammell"/>
            <author fullname="E. Boschi" initials="E." surname="Boschi"/>
            <date month="January" year="2008"/>
            <abstract>
              <t>This document describes an efficient method for exporting bidirectional flow (Biflow) information using the IP Flow Information Export (IPFIX) protocol, representing each Biflow using a single Flow Record. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5103"/>
          <seriesInfo name="DOI" value="10.17487/RFC5103"/>
        </reference>
        <reference anchor="RFC6235">
          <front>
            <title>IP Flow Anonymization Support</title>
            <author fullname="E. Boschi" initials="E." surname="Boschi"/>
            <author fullname="B. Trammell" initials="B." surname="Trammell"/>
            <date month="May" year="2011"/>
            <abstract>
              <t>This document describes anonymization techniques for IP flow data and the export of anonymized data using the IP Flow Information Export (IPFIX) protocol. It categorizes common anonymization schemes and defines the parameters needed to describe them. It provides guidelines for the implementation of anonymized data export and storage over IPFIX, and describes an information model and Options- based method for anonymization metadata export within the IPFIX protocol or storage in IPFIX Files. This document defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6235"/>
          <seriesInfo name="DOI" value="10.17487/RFC6235"/>
        </reference>
        <reference anchor="CCO-NF9FMT" target="https://www.cisco.com/en/US/technologies/tk648/tk362/technologies_white_paper09186a00800a3db9.html">
          <front>
            <title>NetFlow Version 9 Flow-Record Format</title>
            <author>
              <organization>Cisco</organization>
            </author>
            <date year="2011" month="May"/>
          </front>
        </reference>
        <reference anchor="Forwarding-Status" target="https://www.iana.org/assignments/ipfix/ipfix.xhtml#forwarding-status">
          <front>
            <title>Forwarding Status (Value 89)</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date/>
          </front>
        </reference>
        <reference anchor="RFC9565">
          <front>
            <title>An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element</title>
            <author fullname="M. Boucadair" initials="M." surname="Boucadair"/>
            <date month="March" year="2024"/>
            <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 header control bits since RFC 793. However, that update is still problematic for interoperability because some flag values have subsequently been deprecated.</t>
              <t>This document removes stale information from the IANA "IPFIX Information Elements" registry and avoids future conflicts with the authoritative IANA "TCP Header Flags" registry.</t>
              <t>This document obsoletes RFC 7125.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9565"/>
          <seriesInfo name="DOI" value="10.17487/RFC9565"/>
        </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"/>
            <author fullname="P. Aitken" initials="P." surname="Aitken"/>
            <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="RFC9487">
          <front>
            <title>Export of Segment Routing over IPv6 Information in IP Flow Information Export (IPFIX)</title>
            <author fullname="T. Graf" initials="T." surname="Graf"/>
            <author fullname="B. Claise" initials="B." surname="Claise"/>
            <author fullname="P. Francois" initials="P." surname="Francois"/>
            <date month="November" year="2023"/>
            <abstract>
              <t>This document introduces new IP Flow Information Export (IPFIX) Information Elements (IEs) to identify a set of information related to Segment Routing over IPv6 (SRv6) such as data contained in a Segment Routing Header (SRH), the SRv6 control plane, and the SRv6 Endpoint behavior that traffic is being forwarded with.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9487"/>
          <seriesInfo name="DOI" value="10.17487/RFC9487"/>
        </reference>
        <reference anchor="RFC5102">
          <front>
            <title>Information Model for IP Flow Information Export</title>
            <author fullname="J. Quittek" initials="J." surname="Quittek"/>
            <author fullname="S. Bryant" initials="S." surname="Bryant"/>
            <author fullname="B. Claise" initials="B." surname="Claise"/>
            <author fullname="P. Aitken" initials="P." surname="Aitken"/>
            <author fullname="J. Meyer" initials="J." surname="Meyer"/>
            <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="RFC5477">
          <front>
            <title>Information Model for Packet Sampling Exports</title>
            <author fullname="T. Dietz" initials="T." surname="Dietz"/>
            <author fullname="B. Claise" initials="B." surname="Claise"/>
            <author fullname="P. Aitken" initials="P." surname="Aitken"/>
            <author fullname="F. Dressler" initials="F." surname="Dressler"/>
            <author fullname="G. Carle" initials="G." surname="Carle"/>
            <date month="March" year="2009"/>
            <abstract>
              <t>This memo defines an information model for the Packet SAMPling (PSAMP) protocol. It is used by the PSAMP protocol for encoding sampled packet data and information related to the Sampling process. As the PSAMP protocol is based on the IP Flow Information eXport (IPFIX) protocol, this information model is an extension to the IPFIX information model. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5477"/>
          <seriesInfo name="DOI" value="10.17487/RFC5477"/>
        </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"/>
            <author fullname="B. Trammell" initials="B." surname="Trammell"/>
            <author fullname="L. Mark" initials="L." surname="Mark"/>
            <author fullname="T. Zseby" initials="T." surname="Zseby"/>
            <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>
        <reference anchor="RFC5655">
          <front>
            <title>Specification of the IP Flow Information Export (IPFIX) File Format</title>
            <author fullname="B. Trammell" initials="B." surname="Trammell"/>
            <author fullname="E. Boschi" initials="E." surname="Boschi"/>
            <author fullname="L. Mark" initials="L." surname="Mark"/>
            <author fullname="T. Zseby" initials="T." surname="Zseby"/>
            <author fullname="A. Wagner" initials="A." surname="Wagner"/>
            <date month="October" year="2009"/>
            <abstract>
              <t>This document describes a file format for the storage of flow data based upon the IP Flow Information Export (IPFIX) protocol. It proposes a set of requirements for flat-file, binary flow data file formats, then specifies the IPFIX File format to meet these requirements based upon IPFIX Messages. This IPFIX File format is designed to facilitate interoperability and reusability among a wide variety of flow storage, processing, and analysis tools. [STANDARDS TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5655"/>
          <seriesInfo name="DOI" value="10.17487/RFC5655"/>
        </reference>
        <reference anchor="RFC6759">
          <front>
            <title>Cisco Systems Export of Application Information in IP Flow Information Export (IPFIX)</title>
            <author fullname="B. Claise" initials="B." surname="Claise"/>
            <author fullname="P. Aitken" initials="P." surname="Aitken"/>
            <author fullname="N. Ben-Dvora" initials="N." surname="Ben-Dvora"/>
            <date month="November" year="2012"/>
            <abstract>
              <t>This document specifies a Cisco Systems extension to the IPFIX information model specified in RFC 5102 to export application information. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6759"/>
          <seriesInfo name="DOI" value="10.17487/RFC6759"/>
        </reference>
        <reference anchor="RFC7014">
          <front>
            <title>Flow Selection Techniques</title>
            <author fullname="S. D'Antonio" initials="S." surname="D'Antonio"/>
            <author fullname="T. Zseby" initials="T." surname="Zseby"/>
            <author fullname="C. Henke" initials="C." surname="Henke"/>
            <author fullname="L. Peluso" initials="L." surname="Peluso"/>
            <date month="September" year="2013"/>
            <abstract>
              <t>The Intermediate Flow Selection Process is the process of selecting a subset of Flows from all observed Flows. The Intermediate Flow Selection Process may be located at an IP Flow Information Export (IPFIX) Exporter or Collector, or within an IPFIX Mediator. It reduces the effort of post-processing Flow data and transferring Flow Records. This document describes motivations for using the Intermediate Flow Selection process and presents Intermediate Flow Selection techniques. It provides an information model for configuring Intermediate Flow Selection Process techniques and discusses what information about an Intermediate Flow Selection Process should be exported.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7014"/>
          <seriesInfo name="DOI" value="10.17487/RFC7014"/>
        </reference>
        <reference anchor="RFC7015">
          <front>
            <title>Flow Aggregation for the IP Flow Information Export (IPFIX) Protocol</title>
            <author fullname="B. Trammell" initials="B." surname="Trammell"/>
            <author fullname="A. Wagner" initials="A." surname="Wagner"/>
            <author fullname="B. Claise" initials="B." surname="Claise"/>
            <date month="September" year="2013"/>
            <abstract>
              <t>This document provides a common implementation-independent basis for the interoperable application of the IP Flow Information Export (IPFIX) protocol to the handling of Aggregated Flows, which are IPFIX Flows representing packets from multiple Original Flows sharing some set of common properties. It does this through a detailed terminology and a descriptive Intermediate Aggregation Process architecture, including a specification of methods for Original Flow counting and counter distribution across intervals.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7015"/>
          <seriesInfo name="DOI" value="10.17487/RFC7015"/>
        </reference>
        <reference anchor="RFC7133">
          <front>
            <title>Information Elements for Data Link Layer Traffic Measurement</title>
            <author fullname="S. Kashima" initials="S." surname="Kashima"/>
            <author fullname="A. Kobayashi" initials="A." role="editor" surname="Kobayashi"/>
            <author fullname="P. Aitken" initials="P." surname="Aitken"/>
            <date month="May" year="2014"/>
            <abstract>
              <t>This document describes Information Elements related to the data link layer. They are used by the IP Flow Information Export (IPFIX) protocol for encoding measured data link layer traffic information.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7133"/>
          <seriesInfo name="DOI" value="10.17487/RFC7133"/>
        </reference>
        <reference anchor="RFC7270">
          <front>
            <title>Cisco-Specific Information Elements Reused in IP Flow Information Export (IPFIX)</title>
            <author fullname="A. Yourtchenko" initials="A." surname="Yourtchenko"/>
            <author fullname="P. Aitken" initials="P." surname="Aitken"/>
            <author fullname="B. Claise" initials="B." surname="Claise"/>
            <date month="June" year="2014"/>
            <abstract>
              <t>This document describes some additional IP Flow Information Export (IPFIX) Information Elements in the range of 1-127, which is the range compatible with field types used by NetFlow version 9 in RFC 3954, as specified in the IPFIX Information Model in RFC 7012.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7270"/>
          <seriesInfo name="DOI" value="10.17487/RFC7270"/>
        </reference>
        <reference anchor="RFC8038">
          <front>
            <title>Exporting MIB Variables Using the IP Flow Information Export (IPFIX) Protocol</title>
            <author fullname="P. Aitken" initials="P." role="editor" surname="Aitken"/>
            <author fullname="B. Claise" initials="B." surname="Claise"/>
            <author fullname="S. B S" initials="S. B" surname="S"/>
            <author fullname="C. McDowall" initials="C." surname="McDowall"/>
            <author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>This document specifies a way to complement IP Flow Information Export (IPFIX) Data Records with Management Information Base (MIB) objects, avoiding the need to define new IPFIX Information Elements for existing MIB objects that are already fully specified.</t>
              <t>Two IPFIX Options Templates, as well as a method for creating IPFIX Options Templates that are used to export the extra data required to fully describe Simple Network Management Protocol (SNMP) MIB objects in IPFIX, are specified herein.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8038"/>
          <seriesInfo name="DOI" value="10.17487/RFC8038"/>
        </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"/>
            <author fullname="R. Penno" initials="R." surname="Penno"/>
            <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="RFC3031">
          <front>
            <title>Multiprotocol Label Switching Architecture</title>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="A. Viswanathan" initials="A." surname="Viswanathan"/>
            <author fullname="R. Callon" initials="R." surname="Callon"/>
            <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"/>
            <author fullname="K. Egevang" initials="K." surname="Egevang"/>
            <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"/>
            <author fullname="S. Brim" initials="S." surname="Brim"/>
            <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="RFC1631">
          <front>
            <title>The IP Network Address Translator (NAT)</title>
            <author fullname="K. Egevang" initials="K." surname="Egevang"/>
            <author fullname="P. Francis" initials="P." surname="Francis"/>
            <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"/>
            <author fullname="X. Li" initials="X." surname="Li"/>
            <author fullname="C. Bao" initials="C." surname="Bao"/>
            <author fullname="K. Yin" initials="K." surname="Yin"/>
            <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"/>
            <author fullname="P. Matthews" initials="P." surname="Matthews"/>
            <author fullname="I. van Beijnum" initials="I." surname="van Beijnum"/>
            <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"/>
            <author fullname="F. Baker" initials="F." surname="Baker"/>
            <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"/>
            <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"/>
            <author fullname="R. Hinden" initials="R." surname="Hinden"/>
            <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"/>
            <author fullname="M. Molina" initials="M." surname="Molina"/>
            <author fullname="N. Duffield" initials="N." surname="Duffield"/>
            <author fullname="S. Niccolini" initials="S." surname="Niccolini"/>
            <author fullname="F. Raspall" initials="F." surname="Raspall"/>
            <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"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <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"/>
            <author fullname="G. Dhandapani" initials="G." surname="Dhandapani"/>
            <author fullname="P. Aitken" initials="P." surname="Aitken"/>
            <author fullname="S. Yates" initials="S." surname="Yates"/>
            <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"/>
            <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"/>
            <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"/>
            <author fullname="M. Davis" initials="M." surname="Davis"/>
            <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"/>
            <author fullname="G. Adams" initials="G." surname="Adams"/>
            <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"/>
            <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>
      </references>
    </references>
    <?line 809?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>Many thanks to Paul Aitken for the review and many suggestions that enhanced this specification. Special thanks to Andrew Feren for sharing data about scans of IPFIX data he collected.</t>
      <t>Thomas Graf tagged an issue with the forwardingStatus Information Element and for the Shepherd review.</t>
      <t>Thanks to Eric Vyncke for the review and comments.</t>
      <t>Thanks to Qin Wu for the opsdir review and Behcet Sarikay for the genart review.</t>
      <t>Thanks to Mahesh Jethanandani for the AD review.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+097XbbuLH/9RSo86NxaymW7diOt7u9jj+6vieO3cjZvT05
OT0QCcloKFIlSDtukj7LfZb7ZHc+ABKkSFmKnWx2a5+TXYkigMFgZjAzmBl0
u91OprNI7YmVgZ5MIyWO9XtlRJaI7FKJk3NxHCXX4iQeJelEZjqJxdH7aZJm
4vHJ+fHJ/6yKk/2X++KVGmuTpTcrHTkcpuoKuqOf+VfqcqUTyEyNk/RmT5gs
7HTCJIjlBEYOUznKulplo24yNfJ63NXTkX7fHWGz7vpOx+TDiTYGBs9uptDg
5OjiuBPnk6FK9zoh9LrXCZLYqNjkZk9kaa46AMFmR6ZKAiRnU5US6EbIOBSn
MpZjNVFxttK5TtJ34zTJp/ja+WD/57+sdN6pG3gc7nVEV9AkOjLPLpMUH3QE
/I3yKGLIT5NL+H8onid5IEOpU/o9Sccy1v+iIffEWSrjsaIf1ETqaE9MuFVv
6Fr9V0Lv9IJk0pkd5LmKE52Jg0hqoxoG+DGX10r7AwypRS+gFv91Sb9z5zGv
4hVgDN+n5enSJO0D+LP0sMDSH8XwrlamaFogyv51i091oFdw5JVyTJmOVbYn
LrNsavaePLm+vu5pWKcetHoiYenHMS6YeUKUwf/tvb/MJlHRBdGBGMkIkNTR
Duhipq+OD5721zfLb9sbm0/tt4ODs+7L42fHpxcF6BYJL1VGSPhJpUh+4hnh
pPtKBUAh4pjGcE2WmPyBNkFSzL5p8gG+gWv2RMVPXg+eZCq4jJMoGQO6n2Tv
trd24b+b2xuVH/5+fakz9fepBIJff9bf3Zbr67vr63IzHD7r+chiXJ3KG7Gx
3u/zU5jMtUxDHY+7g0xmwEl1iijfEPyGePyTjHIldp+t/pIk8GhUgm4IsGai
6HS7XSGHIKdkkHU6F5faCBBCOXYrpmlypUOQfIbF4KgiBlGKLcAQqRWDPTGY
qkCPdCCj6GYN+mgcKp8ifDQKDCekMIC6DBYdUaxjGhreC1I9pdGSkTDJRFUh
iEiUwVqcHK2u+V2iOEwV9IqyEcDCoQG4PMjw8fWligWCh2PJWKj38Ap+prm6
iayRxKzBOUyTd9B4mug4A75Yg3WdXsoY5KBRAQGVqpFKVRwo+FFlQU9cwExc
LxKBikwiJkoCSNDpMMWBaWoFrMGNkJMEHiMSAPQU6BsRgF8LNNs1negwjGCB
HwFmsjQJc4Ki0/kZ58hiXVxLw52Hikb78OHPIASePd1++ukTIEMHlwWA/NNO
fwN+WqMBoT1sJZH+F8wxu5QZw5rAT6mYyjQrIFuWUGCsUgQjIIA2EScZwNLN
ki7Cg8jzqQeRHoe0GAxwOXDRKy7aHZC6D8OB/MmNgfle6+ySuw9z6hJfnubD
CIibpgbkDAtN/Vikbu3uOMyt7Iehxtdk5ONjhUa/QSKvYQBYII9CBDmT8KsU
QKDvcLI+jZbkSWQsp1OEZhgpoFcAZDpNEHJodCmv4P09IBOxP7cnx24rhyW/
WSB70PjCQxCwJIAWwQBXKP0M/DBVsA7hvD54EacoeXSgAC7D3J3K66EM3jFV
1fl9kpsMNnO7zqFQEqg00xNVWTChnSQJeyjVgIQAz6oudSJ42aCMURkJkiYx
V6psLQRKnGxcM+RkUDJANo80gAdzGiURUL4hhL92UgOntqh8g7U5ORKPP3zA
558+rfbqHaXqn7lGCRLSRiSdGKovbHUW0CGwE24nTX3iPAphdB9iE8crm9sh
T4GlVBSBoExyT/Y77HyGVIVRQC9mNHV4YdqF7EgGOtKZExiwTyfIiwFMgTZE
uwD4m6VrUCaJCZmy/Qmi2HiseuPeGosHQFYKzf+RDGELsisEEuhGHAA9APRJ
SjQGpIxMih9NPiWBGKtrR3ZHpJ6vgXoMsAN1ws8AOm6fMoQuAfDohqRfOk0V
t7SA6tgHzPDWywCAMmJUOQLg6WVCGJAZyQrQlIDEBxbDTxEDv0Phv97fQBFW
E06aubbQosslAcpPfR46sitLAj1UI4dFlpCgiW5YZiqZtVw8Yg2fd8PEbgok
72V8Q7sOS1wLbh/663Re6HfqGpT+OvPDZ+xgItN3jlFhCqCbcJ/lhvh0a2eH
J07ftvvr/renT8tvqD9733aePiu/ATxblW/emzv9zU3v28aON8Lu+uYufsP9
yz7pP92lmT0CWoqvYC6FHXeIWKW9xRD1CzDcBFpuRqycvh5crKzx/8XLM/r8
6uivr09eHR3i58GP+y9eFB869o3Bj2evXxyWn8qWB2enp0cvD7kxPBWVR52V
0/2/rTDYYEZenJy93H+xMruMyJTMBgUZ02p0WAgOmUSeH5z/3//2t+zSbvT7
gFj7Zbe/s0Xqiop5tCSGJeSvQEA3HdgJlUyxF1hckFNTYPjIEKWD7L2OBRIc
YPMPbxAzb/fEn4bBtL/1g32AE648dDirPCSczT6ZacxIbHjUMEyBzcrzGqar
8O7/rfLd4d17+Kc/g5hWotvf/fMPnbrCnxtlSo7tWqkRCFgY2J/QogIx3qBp
r4kLBVsnMOIamhmFhFsT4lBmUrBtuMYqoPvC6h+y2TlrS35b/zEJ9lVPYuB7
TjxtzHC82DcsVcpnRAmmcVpkF4FKxDvASKegXkQqw90Tt15iHkc0qOsS2/18
eSP2Y7SYUYq8VCoEuFDa8YZjN9I/dzqnKJfsDqJA6WuQYxOwOIeo/cRh5OSz
E5mAIoWa9GNru6Nwwo2WVG546ah7eHZwcfZqUM52E3c+8WNyra5UygwxBqkc
s+idePDAdgJbHHSFgplkcpCyznalpe3/4hj3eSUnLIxZlcG1GaXJxN8ken1v
m9gsddaha6RCUIAA1T84rY8VZPsaCmJkUIDumvGBqgJ6rUgySzdsbdYgOBKY
ZppHFtjC5dUTNXOz0T60+hZbKEelqlJuU6BSFfp+ZYBC6ao9RipI1ZUm1wh8
DhWINLYKiHRel/aJpxKLD49IuYM3HonSdGeXAkvyIE9TpJf6r61WQwhQ0NZJ
a3WNU2LEo6Htbby83fQAQ7SD6iCPZLrmqdMKFZd96yNghr64mSrSsWP0Qahw
F60O0P+FzkoN3f62ucG2bkk8ds+2ejYDZnLFr/nKrzassDllH9YbdOtUj5hJ
QFyVlhpYuCrsGuBRwEiQsCZcV2a2exsenbJ+8AhQfvbisNP597//jRTa9Rdm
TzC9NpCPcDuUsbzh1sXz7hR/7INx0I5QDiJrIsHLLAMbBmYHfGaAjnqdpg4Q
NZG8SfKskCdulogl38xoaH06eI4TE+vwuQ//NuDfJvzbgn9P4d82/NuhN14M
njd1wH9/7Ha7c/+1N/1o/WMfBWwAOE/gmVAhh4wiOTbi411GbWo7UMxlsx46
kw+7nm5ceiv9vzczvr+3zQtz9F6i1diCeNLGxZ5Yf7+1Lr4X21tNLw11LPEI
YL2/Tn9N74QK8YXvuCfdH9zc2lGHf9wnvf8STJ48JReNLgn6FsB3nwHg/c2d
eZAj4PCvPw/y/roH+WGaTG8DGzukl5/LUFxcvOgwdzZ7T/ZowVcWcU6vVAd+
U7q67RJ3G6TdXinrSFCQ2Hh59PM3JDYa2rMa0SwcUXwb3l+dedpM4fuerQ+N
7EYEqog0Jgk0SWbaIQsNqpFUbtBvd5xTN1e8PMZpP063Q4eF67SpE7TcAXZT
jpfi+Q4+A1rM5shOt33akQvn5OwCNa5Doc0o0loZbQVFPIjspUd9EKUtkP9m
ROnCO3C1D9AGW/fe+YJ5c4MlM2jZ5+gxRGmyj8cMvjvyVeHEfeS8n3UrGKWh
QscwNaieKZRKrDsqAIPN+l3JqIpDPAMA+dDq5beO5Zq27mwPoP2PaIs0/X1s
WTDgxI9CB5Mp4uMAKOTk/GqraHP74SG07ILqLycKvaz173ygyJ3hOGMeZ/Hu
oUEXgxS6HJ7Q8MSeWc487/bLYavT215uelfb9QlWnpRT9If6Alh8VHtKszX+
wF9o+WYGRkFiGmb8JRD7aOZ5d2Nmxl9p4E0eeJrqK2DTI/Y5aqNeEsU5GG4F
QRUNC6qefcTo/bDHwQLfrxxo8lTXBFEehzBwi7T4ZL287tTlAE8rrP7id4OS
6MMj73xlUaFWE0PovqAjNacfHRWCDg/LygO9UhCCMLenMYasaQF7uLlIpi/k
UEVIVZ6J7avInT3WkUdagWqlQ/Rjj7RVi/GsM00idFdkSQAf+FAKxmTpiu9k
ybSbjDC8IXgHihaM1hM/8ekHnzwUnaOTuQr+6fmLAbcRyILeSS/vfp8RccEB
Wjj5LnVMvI0nx82brB2IfTCb65t9i/0adIXq7SDD33EuuEK1WaBSyVsh7kq0
0Lib3joXD2Y+PXrb8+ybX8Ga3YLjL4CyBZf/bW/5ZUYWcifI7Dg8isdgHZ2E
7Yy0D1JEA4OXS5IWoyhqzYsRKnbl29UYKPbTi5NDdL7lht1+B5XRBQ8P71gz
rVxt9T4rhqn11dZLAPLPuncx7AQNKVE45AsHLHZqIxiosYd6xOiiFNM2EeNH
JX0et1dXqMtI7urQzGGdh1X63FW6jcPvfQHJ13IUh2z4ztvBlHXA0DzJYOLF
Y5e/Q8LsrCsD3J0ebXgwWmgqDrsMEwaDtcvxe4Z8ESl8+1ILeSV1RCERdxLE
NUzwjiZgbmepHtMc4zHAmypjYCLRpH2JT6xJZ/BQmQx+nIlRFHzNMXT23Gyo
AolnEmChjpBREjtUiTqrdqIPhcPF0HZEGCiWbtIT08RkL/cvBkmeBmQHWBjX
3C8AXGaXqOHnc9vyIpWxQUfVOfzjU0D3gtdB5S1a6H/mMuI4kcLBVgEQ5zEF
zXaKCt+V8rh8lkzacX1f1A49d5NyiK4Ftcu4XFTz2tjwtuSwCKBAZQHwPUec
PxDGlyOMRYRJobnB7IVHBzXI7iRG5pKY9XEtQUg49yOM2LnFJmo6N/C0bUlT
VtiRjaIEO62mjZOKTCEM3rvOw2ph4sd4Dh5EeajWxDDn5cbz+EhPNB+6rtG7
GRJFxDAxYc8+D0G9wOcXl4ClywS2+1eKTikwdM97evQ+oKAJG7RX1xSapj9L
Rys4OmGTHIErXgisuatYIcQsZ8HdtvyVtzc2t1rf5tDtYfJemWorDvxqaEXr
aQP/trr97dvMtwfyugt5LS+cyl7M3cVRSZoz1uW3RoJ4GqiuZRTdIvPKnVQW
TRxN7XP0kOu7QR31x7g/R47rlvG9kBpwj8AvQ2HVQe9IYdVpW7V5qFGdPoSf
bBZJ20KCiVsLXicqcQ09C1FMQGVKQj6C5mNf+IVef06jCVZYbFhroZr02iXY
6f7f0GidghTgpBBYEDJrKjGIzma1wwLacDRTHuxSuJSMZ+MTsenZ0Kj0isc9
TPDoGWZAh0t00n42ZT+oOBm1ixobeDwLpz1aQwhrJ+vSIQVD80yQTEEI6oyP
kU0+cSk41uIf6XGeykVXgLzEYIUleYauuSEgvCeKiHCO7m+YI2EPEHnTPtEK
fnEeFOLXhEM8U25DO3s7eFRhg2WHqGcTw0QabMUbQrj9onjLoFB6i+rSpnys
e6q35k/q9eH56lr7HOyAZRAxece95ZpjKNfYpmb2fD6Pcr/dYlHnuWsfGPKB
IR8Y8jaGXGq/5V68JXS7+1323Saexq03KdeGghpuOVCzWrnXirOn5iClaYT7
8tB4fXcJDmdStZon9z6BpZZ2Zli2c+60ss04sJqVjJP4ZmLzvy8wbx0PCOYd
9DSI80onInO9VMRqmZYVNrKVkwb+ey6pAww7yrIsOrZRe2WOKSfdYHi2SilH
tTHcHncOIO9kAl8xBJ0aoSkxr9WchW9G3n3RbqX3bjH5Zffah8VpXpyl+LIF
iXeUuS0rXJ4VzBe28xycF/caVIBm/xfzRfW3K4fSM29vbVXf3+5vtTsO4P3t
2fe35/a/XXt/49nc97dr76/vPGuHH13hNQ/Gxvr6vNfv6jzDTslvRRtHyeRT
GbxTZVUEVFhu85LfYSNzENyDv+nunqZb3l6WwGYI5hYCmyHIuQR2fnH15Qns
B6vPJxRyYgkruMSKR5zxBIosKoJgBaUpZoq7YyKbCV+mceEwhJMndqYouow9
5d+PxkkKe8ec081FSZrJ1/aM77GxUuS8H+sooyoia2KATmD4tCqKSgKOD2x2
46DoxZoUPXGaGBcmb1TROSVmelF94tjGXDdvYeha5mRMTO7PMV2SoxZuZuF3
51jeaJRaEWHcktJpZVg8LHdvWTYdKsrGaExl39p5ihl1x0wClb5aMhFr/XAo
cfneJAlVVATzMTxYCcuUKGvt1sJbRPY5K7OIQSmxOvNTkaDBeZA2dJliqWj+
YOaB2arHl5TxFytcS5mSssGz4WIGTaBhwQO7NjP4tuEJZYxhK/X5oPo4xJzu
BeomTY2sBsvyyJzoIrH+hETnbapVRnmz0wQao0pVNmEiD1x+CLlPENdA2Zi8
ewMYzNBAdfwhHj9dpYOQMo8moxH5YETIcQok7A9QFG+4h53pP5uNLUMWb/72
2PKLMuS3yxZLaEbng/3Tc7+fhRSkuqCwNoJHDBaP6NqcbzY0W4kuryVE12hx
uBpbF59PdIoHcmWHqICGxDI55LBr7sz4VOxq52xy0j62sBVavFFOibT90izf
0ak6l/qyPeCCcmkar2USFwfEpkh2LNjnTTvK3mIoeWm88/SsEptWktErefsz
oDvRV2aq1/rVxn+CNM0FxCqObxfDT3ocdkKMvUbuS1TnWQEDbpgoVNy0mXA8
JOcCeZivFJI6t7HRHHqDJUhy4AKbf4m8NcjgB4kFW/YZx+7cdQN1VugLZA6w
6NJeiOXp63PJa/AfTV5WdVkUjl8r8S0hcGHyLvO5hOtOVqmH267tG8sCSs6m
ahXNAzWRsIEGZknZbFy7Css0kMQckVyyXdlbo0je+Ao8U9Fn3rRTeIGwGdYp
orlRD8GpUldl6bEq2lzL7/g57ttAN5wWu/5+fV08BphkHmWrRVJ6RtW97Nxg
+y87s0dciQ2fACC+w5O3QMbIHEP0f8Z6mkcceHkDVD1bUgiPt46xXMkrJUOK
28So+0Tx4RQlZBlkBexYYmwmWNFucT1IPkdqFDi986ZUArKUcCibfRMb01dg
rsFvkLmW7vjXzXtuV1121r9mNlpii12Yie5/33VDt+66r2OdLbvj5thmUYFA
rlIzTeLCEObmWMxVBxotyRpXNldlKSMZvQ356ddXYWdRaAiHy4qJCzr722RH
XTv7x0msWni/4HIu9YVJzMYsojm/uWUTpPlU5d6S28YvTyGDb59CymXCfL7W
nWTptSJZfC+0tJSUW2jNScItNCUbYINhSa/w4AUkczo3L0MJLs/LlQKsN+7G
Vf4wmS0/KwXdXMF+sRTPyPctkuDJv1SaFEVCTIkabsJ92Bipwr+1JrTyXtJV
y6Gsun4tyfz0MFojKdfs4uDcn4px6Z6jJMdNK7vdb44RLTpQXdoyu9hXUcpj
fsbhL4ZBijJbFIlzqPIbwG5JskfxnJzw29CtsFbunZCNPdyFWL8FZH4eqX4x
3P2WyBSQhblyJ3hiPZKBuq0WSJlUpF0TjAtNVTV2AnBy7I5eh4ovLAiUvlIh
b0y8AHS8YA+9iiWZ0DVHGOb3D9h9xe/1CGH6PerpHppv14/hoR5RoaKJHs5d
hyX7mk+RvxB6ltul7ap7QC7j8atgw9oU6iuRkSnO8B5I6B5Rs6S3+F6pB8mH
4DukIknDHMc9pePUJU3SWnZE6Ppj8AMQmnSYSD6pAyyEQ4MB6o4p2B7mw5bH
/hgmOCYHCeE4pZh1X8lHv0nsJxzY9IKxilVKJcClF/x5UcJGm4WaWE+Hc9XY
k3DYaeIu3gYwrxC2F15Kg5JxwhcB8SqHHhr5LBiea1hyd53cd0IzvmzSdETT
P0G7ieYi4/AJ9Fn59SDBpNGsOfbVeJH+2G9RaB6/3RTZpGCeENERlrWpAsr4
oYr/1IjO22FbVC48B28BaGjhUfws/Yg2HxNFx+BVKTwrd7lMcUbegEkbj3Dn
OFHquut33bUzWdK8fqD2B2r/8tS+zL7Q3s/dfJqtLPO2rAPkiibdYzglaTNA
vEgnzBozwVReSP+twVna1GOzFhigHq3lhdXPBGydZKaWyFb8+tisCrooBQtG
RUC8RbgWxub8YqFey8VONS6zl0nypaKqzgFhRtX8ZNM8xdvaKmW/SzR4y1Tz
DNZuNyJX4QTPMZgEUUWD0fKUv47ymKs21nRXbDYgefjY+Tj7q+4EZhG6vSgB
bAvPXMS8nFfZyQU4S7dU9xAa+cCSDyy5ZOGFkjHxYNDBeNcKDE30bXcjPOl+
oeN3xwjwArVVm8jeEUK1jgufxeOoMDE6UKerIUc4UI9jnfiuyOLYpyYyZkC7
rzw8iuzBsbsEjE2E2ivIqbiZj0moVs7Tz5yeVSh4JkM6O0n4pUkeZRqvgfTy
Ngvn2Nmr3yN9jqncl72vpkBNJG/QVVgRpm9OBmdPTo4Oejtbz3a7/b3+s2db
b+dS2eOTo6Oj3fWN3uZq8bHfh8+zHa1+htD7+qv/TSzVUnxdQ8B9hKw1ETEl
VZ3Wj/7kEC+MyBooq+KgBbwvQym2MrMeHsgplpm90BO1QDxcpcRd7BY70iNF
V656uWz04fTkuVXUr+lWESwcfeUqOLgXKIgCQTkjI+bEC3gnqvWOD5333JlZ
3HdRGILvL44s2VYGCSJQoOgCVAKOCkqRfWsrXXIffHEsZ76OVFrEciB2TAb7
OR9ZFhWsCnI3SBZeFYtetTByWRSBZkK4U0UZBW/yfFc4nwcXjFmY1xidguW+
DS6SLWFRR7KhilvEQ4OXGNiOATPVmJRTZUPsvQic2VoadrXcCQeP8Lg8kCBq
pAu5AJfhDUIWqVVhI3W0Ka8nxdHfxZYk1HuMFDZWNyKEU39UeEKWPOmxMGL/
Dy4M2bt6ZSrpCtWiAOHZyWGlDsbA1VAOeWlstt8m3kcHe5Ce6Ag1oTWkplCP
yPjPmFqYKQg6L8qpfKm2YMqpEjYxG6Gp1DTJmFtCfaXDHGbXwnjN+knzjMmM
v2XKcxNK22C4p20auu9aPHYRj0Vk0Lxztgf58iBfHuTLf4h8Wd7fZ4os6joW
/aDUO9Xrb5VaZRWIv+ZJJl1JyXuo3uor3lw+k0Yoqla64oF3KFtZ6/ALFUn9
J47SVXaUolDiIiUq5ubUs2i52gJFnyuO2Xq+JPy+Ts3LO3uTfvkFXvLclWtH
Ujqq6xUHojW+exGJJlJ5u0SZhW+DJKgoh6syey91nKtkUlawvTuFeNVwvwz3
Z26AB8b/5dfzTptrA6j3UTemSh+/Om4Xp9oE4sOjiaaLuRe/I7DhPH322sCZ
+7rtxT82X4a11FMdASWAzheHc5w06IWUQ5NEdD5fmBZUKhIPswvt2tMm+cAb
b4eRfHtqKzmypcURZG05PXNqgJamypD8Vmh18cGFG9kZEcbIsaJ6mtWylmgB
cEwCvcFHUw1DrfnnWFydZH4s1APOMusW5LdOD58eXKrgncnnHHAT5uBNEdhX
q+kPDqQ6llJbmvNe5wwWXmInzP3fgVY4YataXJRK4CVxoLgk7BiWM66CARNK
wC6JAsp58wxbF0fXODbdkSyG+cjGZLTOEnfpLKuazHN6dgEwGHmsOFEnrkHX
tHIgWtGRjlcoM0jV82BbJW5zA+T1mphGFJRXacaAuSPoZnQDcp1PBNryQNC/
Xaje3A3WiziRuMkaTNxR3jxgnSjBKVUjdKejENV0CQvAqDGb0JYtLo7ThBzr
SGdlRI27AZshRSyhKyJGSkiTaUpHthZWMNvHymRzaPlSci349wBwpOJxRtcp
9rdFEmQquy3u/LfAXA+s9MBKX42VqtVBj/Fucm//wiuh8cpx+is+VD4u9PfH
zkc8fcTQio+UKmxvq/W1vdv/8O7Zxy8Gz8X30NS72Hm5P+xlfbXedPle7gsv
63xR80cxOChgGWRyyIRBl77t2cxHVf+hnNHsND6KjJJYvR3apU0W6Ze9fq+C
lw3X9HyyX3xUqaYAD7Hvk8oee84xZPFxf3XN76UJFjZGui1hM7VorNZe3nAy
6OZbYhjNlwZTPKjEmvfwFS2422CxFhHmqyNWwrIefxW++b20Ql8F8pZeanOg
rzgHD0ZncM3pxQa9cYKnDQdGidj814qX5qrDWGhzBisL4IXFIVKuo7ed3kZv
g+YTKthoItgb2nohoQYig0OxXp5dcJV8W8G/fqNA64wolhlENtcjtycmjhaT
VFT+2nrxCWS1OVfa0xLaeinvl/ZLUpNyYOHS6Pq4BZY5fETyni8LBTE+vxeV
rdkd32V3U+0jnxPcGU97L3bOFFxXjkt9I19RftuVSo3srYr7k5i4J5U64MMO
1d7Lr3CH8nYmlGVvqOLw5tO3PdfLww71sEN98R3Kp7zWXirb2K1/D/vcb3qf
E19sn2sqk1ruSfMSMV9fHHd3ne9+e+PZp09CxUGC5uvrWOMHgYk7gA/P7pfi
Mp/IGO9oDUk41xzysvEuC47mpfvSYxeBPx9wd78VVb8qCZyubrI1XSIZj3M0
dDMwSu08traxXP1aMREdY2CoO6HY2NrF8wzP7cw44GmuCbqbKeTQIy+KvRwJ
XvBc2B60sOjXYLHD9HrCnwXdDw+timha15WhCQLkHBti/Jh/qsRyHVcm+F3h
twikUWuzAHhId/c2Fe19AkUHwpWMKDBGSVzTHqwYH2ENDWbs8TLeVIbnAVd0
1xY0W3EY3djZAYzWR+IAZLyqq+cdkYEQzVPa+VEEhDbPz1Sq9WCyDgpeR3qX
wEEUfIQ/NvqSOB6aUh/nZmI+kPsDuX8T5O50CRjXlq/a7rtLLe5K/pTHgjGH
cZAdYCji2ahyd7m9EHz+eSfFMCJ4rid/QxQn58WRsXfUbS8dj2yScuDnLbtM
2lrC8hotPwbk49OUPOfQOe6Ueu7Vhxqv6MCYz7RMaLKtujYSMygDMa31kMcR
1T6YDXc0CnOU/PRrg+eKDo75Bwq/KVzdEUuF/eJfO/8ZQTypsrdFGhuFWrUo
7NXzXFsDX7CZc9oUF9W7iGJSwXE5aPI2p4h0csxEKQMUdJG3Xjdf3D33Xkl8
zCK5mnvP3lefmCd13AT8NcArxsuwjJnpk9xoE1f14IyimigATWmAxrULqmKO
iA1Muo4LOgYOCXLj7ipwtdFBBjqBuIt89DsQiDvr/Q0K2gCwKAakDpJtYcQW
DrPjQryFtI9pAMp6uuC6ti4ZtzhGmSpCJqK6V58iXRI0LwilKG4ggkjmZTLx
SmtZPFNGE9VCU8qQ6LLXovSAu/yi0wGVXwyBHBAl+wFGaMMajqnrzoc9Lg2l
wu9XRgC8WvnU6ZzinpbB/vGOluIctjGxrzOq7WtJIVVXGhYQbZQJvm3yMZ4Y
8ephWLuKLyWVcCBonLigifXEwNYoLMfYj4HkrsUxzoLLv17KtKiZzrlXJpB8
nTmjin65VGUmAC1GMgF++0sqR7gXj6nWAzCBwah5hyzo/hrkIPQ+AH0pb4n2
isNisoNLNYXVDu2saRwH+FEKQvCnmxi4rQk5fG8fHYiVbf4KpPtzXryeTE2o
U7/Vc3UZAPMOAAXv5E3x4ljFWEWvAYpTCbR6Kf5bIUaxkG2si1b7h0WL/wdM
koyuQ7UAAA==

-->

</rfc>
