<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.17 (Ruby 3.1.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-boucla-opsawg-ipfix-fixes-00" category="info" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.15.2 -->
  <front>
    <title abbrev="IPFIX IANA Fixes">Simple Fixes to the IP Flow Information Export (IPFIX) IANA Registry</title>
    <seriesInfo name="Internet-Draft" value="draft-boucla-opsawg-ipfix-fixes-00"/>
    <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="2022" month="November" day="30"/>
    <area>Operations and Management</area>
    <workgroup>Operations and Management Area Working Group</workgroup>
    <keyword>IPFIX</keyword>
    <abstract>
      <t>This document describes simple fixes to the IANA IP Flow Information Export (IPFIX) registry. These fixes are mainly updates to point to newer IANA registries and also updates to the description of some Information Elements (IEs).</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the
    Operations and Management Area Working Group Working Group mailing list (opsawg@ietf.org),
    which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/opsawg/"/>.</t>
      <t>Source for this draft and an issue tracker can be found at
    <eref target="https://github.com/boucadair/simple-ipfix-fixes"/>.</t>
    </note>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>As the OPSAWG is currently considering <xref target="I-D.boucadair-opsawg-rfc7125-update"/> that updates <xref target="RFC7125"/>, the WG realized that some other parts of the IANA IPFIX registry <xref target="IANA-IPFIX"/> were not up to date. Indeed, since its initial creation in 2007, some IPFIX Information Elements (IEs) are not adequately specified any longer (while they were at some point in time in the past). This document intends to update the registry and bringing some consistency.</t>
      <t>This document lists a set of simple fixes to the IPFIX IANA registry <xref target="IANA-IPFIX"/>. These fixes are classified as follows:</t>
      <ul spacing="normal">
        <li>Updates that fix a shortcoming in the description of an IE (<xref target="desc"/>).</li>
        <li>Updates that require adding a pointer to an existing IANA registry (<xref target="to-iana"/>).</li>
        <li>Updates that are meant to ensure a consistent structure when calling an existing IANA registry (<xref target="consistent"/>).</li>
      </ul>
      <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="RFC7125"/>.</t>
      <t>Fixes that require defining new IEs may be moved to a separate document.</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>
    </section>
    <section anchor="desc">
      <name>Update the Description</name>
      <t>The IEs listed in the following subsections cannot echo some values that can be seen in a packet.</t>
      <section anchor="tcpoptions">
        <name>tcpOptions</name>
        <t>Only options having a kind =&lt; 56 can be included in a tcpOptions IE. An update is required to specify how any observed TCP option in a packet can be exported using IPFIX.</t>
      </section>
      <section anchor="ipv6extensionheaders">
        <name>ipv6ExtensionHeaders</name>
        <t>The description should be updated to:
- reflect missing IPv6 EHs, specifically 139, 140, 253, and 254.
- specify how to automatically update the registry when a new value is assigned in <xref target="IPv6-EH"/>.
- specify the procedure to follow when all bits are exhausted.</t>
      </section>
    </section>
    <section anchor="to-iana">
      <name>Point to An Existing IANA Registry</name>
      <t>IANA is requested to update the following entries by adding the indicated pointer to an IANA registry under "Additional Information" of <xref target="IANA-IPFIX"/>:</t>
      <table>
        <name>Cite an IANA Registry under Additional Information</name>
        <thead>
          <tr>
            <th align="left">IE</th>
            <th align="left">Additional Information</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">icmpTypeCodeIPv4</td>
            <td align="left">https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml</td>
          </tr>
          <tr>
            <td align="left">igmpType</td>
            <td align="left">https://www.iana.org/assignments/igmp-type-numbers/igmp-type-numbers.xhtml#igmp-type-numbers-1</td>
          </tr>
          <tr>
            <td align="left">icmpTypeCodeIPv6</td>
            <td align="left">https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml</td>
          </tr>
          <tr>
            <td align="left">icmpTypeIPv4</td>
            <td align="left">https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#icmp-parameters-types</td>
          </tr>
          <tr>
            <td align="left">icmpCodeIPv4</td>
            <td align="left">https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml#icmp-parameters-codes</td>
          </tr>
          <tr>
            <td align="left">icmpTypeIPv6</td>
            <td align="left">https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-2</td>
          </tr>
          <tr>
            <td align="left">icmpCodeIPv6</td>
            <td align="left">https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-3</td>
          </tr>
          <tr>
            <td align="left">privateEnterpriseNumber</td>
            <td align="left">https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="consistent">
      <name>Consistent Citation of Registries</name>
      <t>IANA is requested to update <xref target="IANA-IPFIX"/> for each of the IE entries listed in the following subsections.</t>
      <section anchor="flowendreason">
        <name>flowEndReason</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: The reason for Flow termination. Values are listed in the flowEndReason registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-flow-end-reason.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: The reason for Flow termination. Values are listed in the flowEndReason registry.</li>
              <li>Additional Information: See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-flow-end-reason.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="natoriginatingaddressrealm">
        <name>natOriginatingAddressRealm</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: Indicates whether the session was created because traffic originated in the private or public address realm. postNATSourceIPv4Address, postNATDestinationIPv4Address, postNAPTSourceTransportPort, and postNAPTDestinationTransportPort are qualified with the address realm in perspective. Values are listed in the natOriginatingAddressRealm registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-originating-address-realm.</li>
              <li>Additional Information: See <xref target="RFC3022"/> for the definition of NAT.</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description:  Indicates whether the session was created because traffic originated in the private or public address realm. postNATSourceIPv4Address, postNATDestinationIPv4Address, postNAPTSourceTransportPort, and postNAPTDestinationTransportPort are qualified with the address realm in perspective. Values are listed in the natOriginatingAddressRealm registry.</li>
              <li>Additional Information: See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-originating-address-realm. See <xref target="RFC3022"/> for the definition of NAT.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="natevent">
        <name>natEvent</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element identifies a NAT event. This IE identifies the type of a NAT event. Examples of NAT events include, but are not limited to, NAT translation create, NAT translation delete, Threshold Reached, or Threshold Exceeded, etc. Values for this Information Element are listed in the "NAT Event Type" registry, see https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-event-type.</li>
              <li>Additional Information: See <xref target="RFC3022"/> for the definition of NAT. See <xref target="RFC3234"/> for the definition of middleboxes. See <xref target="RFC8158"/> for the definitions of values 4-16.</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element identifies a NAT event. This IE identifies the type of a NAT event. Examples of NAT events include, but are not limited to, NAT translation create, NAT translation delete, Threshold Reached, or Threshold Exceeded, etc. Values for this Information Element are listed in the "NAT Event Type" registry.</li>
              <li>Additional Information: See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-event-type. See <xref target="RFC3022"/> for the definition of NAT. See <xref target="RFC3234"/> for the definition of middleboxes. See <xref target="RFC8158"/> for the definitions of values 4-16.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="firewallevent">
        <name>firewallEvent</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: Indicates a firewall event. Allowed values are listed in the firewallEvent registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-firewall-event.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: Indicates a firewall event. Allowed values are listed in the firewallEvent registry.</li>
              <li>Additional Information: See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-firewall-event.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="biflowdirection">
        <name>biflowDirection</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description:  A description of the direction assignment method used to assign the Biflow Source and Destination. This Information Element <bcp14>MAY</bcp14> be present in a Flow Data Record, or applied to all flows exported from an Exporting Process or Observation Domain using IPFIX Options. If this Information Element is not present in a Flow Record or associated with a Biflow via scope, it is assumed that the configuration of the direction assignment method is done out-of-band. Note that when using IPFIX Options to apply this Information Element to all flows within an Observation Domain or from an Exporting Process, the Option <bcp14>SHOULD</bcp14> be sent reliably. If reliable transport is not available (i.e., when using UDP), this Information Element <bcp14>SHOULD</bcp14> appear in each Flow Record. Values are listed in the biflowDirection registry. See [https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-biflow-direction].</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: A description of the direction assignment method used to assign the Biflow Source and Destination. This Information Element <bcp14>MAY</bcp14> be present in a Flow Data Record, or applied to all flows exported from an Exporting Process or Observation Domain using IPFIX Options. If this Information Element is not present in a Flow Record or associated with a Biflow via scope, it is assumed that the configuration of the direction assignment method is done out-of-band. Note that when using IPFIX Options to apply this Information Element to all flows within an Observation Domain or from an Exporting Process, the Option <bcp14>SHOULD</bcp14> be sent reliably. If reliable transport is not available (i.e., when using UDP), this Information Element <bcp14>SHOULD</bcp14> appear in each Flow Record. Values are listed in the biflowDirection registry.</li>
              <li>Additional Information: See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-biflow-direction.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="observationpointtype">
        <name>observationPointType</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: Type of observation point. Values are listed in the observationPointType registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-observation-point-type.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: Type of observation point. Values are listed in the observationPointType registry.</li>
              <li>Additional Information: See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-observation-point-type.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="anonymizationtechnique">
        <name>anonymizationTechnique</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: A description of the anonymization technique applied to a referenced Information Element within a referenced Template. Each technique may be applicable only to certain Information Elements and recommended only for certain Information Elements. Values are listed in the anonymizationTechnique registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-anonymization-technique.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: A description of the anonymization technique applied to a referenced Information Element within a referenced Template. Each technique may be applicable only to certain Information Elements and recommended only for certain Information Elements. Values are listed in the anonymizationTechnique registry.</li>
              <li>Additional Information: See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-anonymization-technique.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="nattype">
        <name>natType</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: Values are listed in the natType registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-type.</li>
              <li>Additional Information: See <xref target="RFC3022"/> for the definition of NAT. See <xref target="RFC1631"/> for the definition of NAT44. See <xref target="RFC6144"/> for the definition of NAT64. See <xref target="RFC6146"/> for the definition of NAT46. See <xref target="RFC6296"/> for the definition of NAT66. See <xref target="RFC0791"/> for the definition of IPv4. See <xref target="RFC8200"/> for the definition of IPv6.</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: Values are listed in the natType registry.</li>
              <li>Additional Information: See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-type. See <xref target="RFC3022"/> for the definition of NAT. See <xref target="RFC1631"/> for the definition of NAT44. See <xref target="RFC6144"/> for the definition of NAT64. See <xref target="RFC6146"/> for the definition of NAT46. See <xref target="RFC6296"/> for the definition of NAT66. See <xref target="RFC0791"/> for the definition of IPv4. See <xref target="RFC8200"/> for the definition of IPv6.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="selectoralgorithm">
        <name>selectorAlgorithm</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element identifies the packet selection methods (e.g., Filtering, Sampling) that are applied by the Selection Process. Most of these methods have parameters. Further Information Elements are needed to fully specify packet selection with these methods and all their parameters. The methods listed below are defined in <xref target="RFC5475"/>. For their parameters, Information Elements are defined in the information model document. The names of these Information Elements are listed for each method identifier. Further method identifiers may be added to the list below. It might be necessary to define new Information Elements to specify their parameters. The following packet selection methods identifiers are defined here: https://www.iana.org/assignments/psamp-parameters. There is a broad variety of possible parameters that could be used for Property match Filtering (5) but currently there are no agreed parameters specified.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element identifies the packet selection methods (e.g., Filtering, Sampling) that are applied by the Selection Process. Most of these methods have parameters. Further Information Elements are needed to fully specify packet selection with these methods and all their parameters. 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. It might be necessary to define new Information Elements to specify their parameters. There is a broad variety of possible parameters that could be used for Property match Filtering (5) but currently there are no agreed parameters specified.</li>
              <li>Additional Information: See https://www.iana.org/assignments/psamp-parameters</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="informationelementdatatype">
        <name>informationElementDataType</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: A description of the abstract data type of an IPFIX information element.These are taken from the abstract data types defined in section 3.1 of the IPFIX Information Model <xref target="RFC5102"/>; see that section for more information on the types described in the [informationElementDataType] subregistry. These types are registered in the IANA IPFIX Information Element Data Type subregistry. This subregistry is intended to assign numbers for type names, not to provide a mechanism for adding data types to the IPFIX Protocol, and as such requires a Standards Action <xref target="RFC8126"/> to modify.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: A description of the abstract data type of an IPFIX information element.These are taken from the abstract data types defined in section 3.1 of the IPFIX Information Model <xref target="RFC5102"/>; see that section for more information on the types described in the [informationElementDataType] subregistry. These types are registered in the IANA IPFIX Information Element Data Type subregistry. This subregistry is intended to assign numbers for type names, not to provide a mechanism for adding data types to the IPFIX Protocol, and as such requires a Standards Action <xref target="RFC8126"/> to modify.</li>
              <li>Additional Information: See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-element-data-types</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="informationelementsemantics">
        <name>informationElementSemantics</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: A description of the semantics of an IPFIX Information Element. These are taken from the data type semantics defined in section 3.2 of the IPFIX Information Model <xref target="RFC5102"/>; see that section for more information on the types defined in the [IPFIX Information Element Semantics] subregistry. This field may take the values in the semantics registry; the special value 0x00 (default) is used to note that no semantics apply to the field; it cannot be manipulated by a Collecting Process or File Reader that does not understand it a priori. These semantics are registered in the IANA IPFIX Information Element Semantics subregistry. This subregistry is intended to assign numbers for semantics names, not to provide a mechanism for adding semantics to the IPFIX Protocol, and as such requires a Standards Action <xref target="RFC8126"/> to modify.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: A description of the semantics of an IPFIX Information Element. These are taken from the data type semantics defined in section 3.2 of the IPFIX Information Model <xref target="RFC5102"/>; see that section for more information on the types defined in the [IPFIX Information Element Semantics] subregistry. This field may take the values in the semantics registry; the special value 0x00 (default) is used to note that no semantics apply to the field; it cannot be manipulated by a Collecting Process or File Reader that does not understand it a priori. These semantics are registered in the IANA IPFIX Information Element Semantics subregistry. This subregistry is intended to assign numbers for semantics names, not to provide a mechanism for adding semantics to the IPFIX Protocol, and as such requires a Standards Action <xref target="RFC8126"/> to modify.</li>
              <li>Additional Information: See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-element-semantic</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="informationelementunits">
        <name>informationElementUnits</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: A description of the units of an IPFIX Information Element. These correspond to the units implicitly defined in the Information Element definitions in section 5 of the IPFIX Information Model <xref target="RFC5102"/>; see that section for more information on the types described in the informationElementsUnits subregistry. This field may take the values in Table 3 below; the special value 0x00 (none) is used to note that the field is unitless. These types are registered in the [IANA IPFIX Information Element Units] subregistry.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: A description of the units of an IPFIX Information Element. These correspond to the units implicitly defined in the Information Element definitions in section 5 of the IPFIX Information Model <xref target="RFC5102"/>; see that section for more information on the types described in the informationElementsUnits subregistry. This field may take the values in Table 3 below; the special value 0x00 (none) is used to note that the field is unitless. These types are registered in the [IANA IPFIX Information Element Units] subregistry.</li>
              <li>Additional Information: See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-information-element-units</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="portrangestart">
        <name>portRangeStart</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: The port number identifying the start of a range of ports. A value of zero indicates that the range start is not specified, ie the range is defined in some other way. Additional information on defined TCP port numbers can be found at https://www.iana.org/assignments/service-names-port-numbers.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: The port number identifying the start of a range of ports. A value of zero indicates that the range start is not specified, i.e., the range is defined in some other way.</li>
              <li>Additional Information: Additional information on defined TCP port numbers can be found at https://www.iana.org/assignments/service-names-port-numbers.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="portrangeend">
        <name>portRangeEnd</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: The port number identifying the end of a range of ports. A value of zero indicates that the range end is not specified, ie the range is defined in some other way. Additional information on defined TCP port numbers can be found at https://www.iana.org/assignments/service-names-port-numbers.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: The port number identifying the end of a range of ports. A value of zero indicates that the range end is not specified, i.e., the range is defined in some other way.</li>
              <li>Additional Information: Additional information on defined TCP port numbers can be found at https://www.iana.org/assignments/service-names-port-numbers.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="ingressinterfacetype">
        <name>ingressInterfaceType</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: The type of interface where packets of this Flow are being received. The value matches the value of managed object 'ifType' as defined in https://www.iana.org/assignments/ianaiftype-mib.</li>
              <li>Additional Information: https://www.iana.org/assignments/ianaiftype-mib</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: The type of interface where packets of this Flow are being received. The value matches the value of managed object 'ifType'.</li>
              <li>Additional Information: See https://www.iana.org/assignments/ianaiftype-mib</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="egressinterfacetype">
        <name>egressInterfaceType</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: The type of interface where packets of this Flow are being sent. The value matches the value of managed object 'ifType' as defined in https://www.iana.org/assignments/ianaiftype-mib.</li>
              <li>Additional Information: https://www.iana.org/assignments/ianaiftype-mib</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: The type of interface where packets of this Flow are being sent. The value matches the value of managed object 'ifType'.</li>
              <li>Additional Information: See https://www.iana.org/assignments/ianaiftype-mib</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="valuedistributionmethod">
        <name>valueDistributionMethod</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: A description of the method used to distribute the counters from Contributing Flows into the Aggregated Flow records described by an associated scope, generally a Template. The method is deemed to apply to all the non-key Information Elements in the referenced scope for which value distribution is a valid operation; if the originalFlowsInitiated and/or originalFlowsCompleted Information Elements appear in the Template, they are not subject to this distribution method, as they each infer their own distribution method. The valueDistributionMethod registry is intended to list a complete set of possible value distribution methods. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-value-distribution-method.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: A description of the method used to distribute the counters from Contributing Flows into the Aggregated Flow records described by an associated scope, generally a Template. The method is deemed to apply to all the non-key Information Elements in the referenced scope for which value distribution is a valid operation; if the originalFlowsInitiated and/or originalFlowsCompleted Information Elements appear in the Template, they are not subject to this distribution method, as they each infer their own distribution method. The valueDistributionMethod registry is intended to list a complete set of possible value distribution methods.</li>
              <li>Additional Information: See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-value-distribution-method.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="flowselectoralgorithm">
        <name>flowSelectorAlgorithm</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element identifies the Intermediate Flow Selection Process technique (e.g., Filtering, Sampling) that is applied by the Intermediate Flow Selection Process. Most of these techniques have parameters. Its configuration parameter(s) <bcp14>MUST</bcp14> be clearly specified. Further Information Elements are needed to fully specify packet selection with these methods and all their parameters. Further method identifiers may be added to the flowSelectorAlgorithm registry. It might be necessary to define new Information Elements to specify their parameters. Please note that the purpose of the flow selection techniques described in this document is the improvement of measurement functions as defined in the Scope (Section 1). The Intermediate Flow Selection Process Techniques identifiers are defined at https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-flowselectoralgorithm.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element identifies the Intermediate Flow Selection Process technique (e.g., Filtering, Sampling) that is applied by the Intermediate Flow Selection Process. Most of these techniques have parameters. Its configuration parameter(s) <bcp14>MUST</bcp14> be clearly specified. Further Information Elements are needed to fully specify packet selection with these methods and all their parameters. Further method identifiers may be added to the flowSelectorAlgorithm registry. It might be necessary to define new Information Elements to specify their parameters.</li>
              <li>Additional Information: See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-flowselectoralgorithm.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="datalinkframetype">
        <name>dataLinkFrameType</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element specifies the type of the selected data link frame. Data link types are defined in the dataLinkFrameType registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-data-link-frame-type. Further values may be assigned by IANA. Note that the assigned values are bits so that multiple observations can be OR'd together. The data link layer is defined in [ISO/IEC.7498-1:1994].</li>
              <li>Additional Information: [IEEE802.3][IEEE802.11][ISO/IEC.7498-1:1994]</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element specifies the type of the selected data link frame. Data link types are defined in the dataLinkFrameType registry. Further values may be assigned by IANA. Note that the assigned values are bits so that multiple observations can be OR'd together. The data link layer is defined in [ISO/IEC.7498-1:1994].</li>
              <li>Additional Information: See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-data-link-frame-type. [IEEE802.3][IEEE802.11][ISO/IEC.7498-1:1994]</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="mibcapturetimesemantics">
        <name>mibCaptureTimeSemantics</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: Indicates when in the lifetime of the Flow the MIB value was retrieved from the MIB for a mibObjectIdentifier. This is used to indicate if the value exported was collected from the MIB closer to Flow creation or Flow export time and refers to the Timestamp fields included in the same Data Record. This field <bcp14>SHOULD</bcp14> be used when exporting a mibObjectValue that specifies counters or statistics. If the MIB value was sampled by SNMP prior to the IPFIX Metering Process or Exporting Process retrieving the value (i.e., the data is already stale) and it is important to know the exact sampling time, then an additional observationTime* element should be paired with the OID using IPFIX Structured Data <xref target="RFC6313"/>. Similarly, if different MIB capture times apply to different mibObjectValue elements within the Data Record, then individual mibCaptureTimeSemantics Information Elements should be paired with each OID using IPFIX Structured Data. Values are listed in the mibCaptureTimeSemantics registry. See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mib-capture-time-semantics.</li>
              <li>Additional Information:</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: Indicates when in the lifetime of the Flow the MIB value was retrieved from the MIB for a mibObjectIdentifier. This is used to indicate if the value exported was collected from the MIB closer to Flow creation or Flow export time and refers to the Timestamp fields included in the same Data Record. This field <bcp14>SHOULD</bcp14> be used when exporting a mibObjectValue that specifies counters or statistics. If the MIB value was sampled by SNMP prior to the IPFIX Metering Process or Exporting Process retrieving the value (i.e., the data is already stale) and it is important to know the exact sampling time, then an additional observationTime* element should be paired with the OID using IPFIX Structured Data <xref target="RFC6313"/>. Similarly, if different MIB capture times apply to different mibObjectValue elements within the Data Record, then individual mibCaptureTimeSemantics Information Elements should be paired with each OID using IPFIX Structured Data. Values are listed in the mibCaptureTimeSemantics registry.</li>
              <li>Additional Information: See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-mib-capture-time-semantics</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="natquotaexceededevent">
        <name>natQuotaExceededEvent</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element identifies the type of a NAT Quota Exceeded event. Values for this Information Element are listed in the "NAT Quota Exceeded Event Type" registry, see https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-quota-exceeded-event.</li>
              <li>Additional Information: See <xref target="RFC0791"/> for the definition of the IPv4 source address field. See <xref target="RFC3022"/> for the definition of NAT. See <xref target="RFC3234"/> for the definition of middleboxes.</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element identifies the type of a NAT Quota Exceeded event. Values for this Information Element are listed in the "NAT Quota Exceeded Event Type" registry.</li>
              <li>Additional Information: See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-quota-exceeded-event. See <xref target="RFC0791"/> for the definition of the IPv4 source address field. See <xref target="RFC3022"/> for the definition of NAT. See <xref target="RFC3234"/> for the definition of middleboxes.</li>
            </ul>
          </li>
        </ul>
      </section>
      <section anchor="natthresholdevent">
        <name>natThresholdEvent</name>
        <ul spacing="normal">
          <li>
            <t>OLD:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element identifies a type of a NAT Threshold event. Values for this Information Element are listed in the "NAT Threshold Event Type" registry, see https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-threshold-event.</li>
              <li>Additional Information: See <xref target="RFC0791"/> for the definition of the IPv4 source address field. See <xref target="RFC3022"/> for the definition of NAT. See <xref target="RFC3234"/> for the definition of middleboxes.</li>
            </ul>
          </li>
          <li>
            <t>NEW:
            </t>
            <ul spacing="normal">
              <li>Description: This Information Element identifies a type of a NAT Threshold event. Values for this Information Element are listed in the "NAT Threshold Event Type" registry.</li>
              <li>Additional Information: See https://www.iana.org/assignments/ipfix/ipfix.xhtml#ipfix-nat-threshold-event. See <xref target="RFC0791"/> for the definition of the IPv4 source address field. See <xref target="RFC3022"/> for the definition of NAT. See <xref target="RFC3234"/> for the definition of middleboxes.</li>
            </ul>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>IPFIX security considerations are discussed in <xref section="8" sectionFormat="of" target="RFC7012"/>.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>Requested IANA actions are described in the main document. These actions are not repeated here.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="IANA-IPFIX" target="https://www.iana.org/assignments/ipfix/ipfix.xhtml">
          <front>
            <title>IP Flow Information Export (IPFIX) Entities</title>
            <author>
              <organization/>
            </author>
            <date year="2022" month="November"/>
          </front>
        </reference>
        <reference anchor="IPv6-EH" target="https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-1">
          <front>
            <title>Internet Protocol Version 6 (IPv6) Parameters, IPv6 Extension Header Types</title>
            <author>
              <organization/>
            </author>
            <date year="2022" month="November"/>
          </front>
        </reference>
        <reference anchor="RFC7125">
          <front>
            <title>Revision of the tcpControlBits IP Flow Information Export (IPFIX) Information Element</title>
            <author fullname="B. Trammell" initials="B." surname="Trammell">
              <organization/>
            </author>
            <author fullname="P. Aitken" initials="P." surname="Aitken">
              <organization/>
            </author>
            <date month="February" year="2014"/>
            <abstract>
              <t>This document revises the tcpControlBits IP Flow Information Export (IPFIX) Information Element as originally defined in RFC 5102 to reflect changes to the TCP Flags header field since RFC 793.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7125"/>
          <seriesInfo name="DOI" value="10.17487/RFC7125"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC7012">
          <front>
            <title>Information Model for IP Flow Information Export (IPFIX)</title>
            <author fullname="B. Claise" initials="B." role="editor" surname="Claise">
              <organization/>
            </author>
            <author fullname="B. Trammell" initials="B." role="editor" surname="Trammell">
              <organization/>
            </author>
            <date month="September" year="2013"/>
            <abstract>
              <t>This document defines the data types and management policy for the information model for the IP Flow Information Export (IPFIX) protocol.  This information model is maintained as the IANA "IPFIX                         Information Elements" registry, the initial contents of which were defined by RFC 5102.  This information model is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process.  Although this model was developed for the IPFIX protocol, it is defined in an open way that allows it to be easily used in other protocols, interfaces, and applications. This document obsoletes RFC 5102.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7012"/>
          <seriesInfo name="DOI" value="10.17487/RFC7012"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="I-D.boucadair-opsawg-rfc7125-update">
          <front>
            <title>An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element</title>
            <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
              <organization>Orange</organization>
            </author>
            <date day="20" month="September" year="2022"/>
            <abstract>
              <t>   RFC 7125 revised the tcpControlBits IP Flow Information Export
   (IPFIX) Information Element that was originally defined in RFC 5102
   to reflect changes to the TCP Flags header field since RFC 793.
   However, that update is still problematic for interoperability
   because some values were deprecated since then.

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

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-boucadair-opsawg-rfc7125-update-01"/>
        </reference>
        <reference anchor="RFC5102">
          <front>
            <title>Information Model for IP Flow Information Export</title>
            <author fullname="J. Quittek" initials="J." surname="Quittek">
              <organization/>
            </author>
            <author fullname="S. Bryant" initials="S." surname="Bryant">
              <organization/>
            </author>
            <author fullname="B. Claise" initials="B." surname="Claise">
              <organization/>
            </author>
            <author fullname="P. Aitken" initials="P." surname="Aitken">
              <organization/>
            </author>
            <author fullname="J. Meyer" initials="J." surname="Meyer">
              <organization/>
            </author>
            <date month="January" year="2008"/>
            <abstract>
              <t>This memo defines an information model for the IP Flow Information eXport (IPFIX) protocol.  It is used by the IPFIX protocol for encoding measured traffic information and information related to the traffic Observation Point, the traffic Metering Process, and the Exporting Process.  Although developed for the IPFIX protocol, the model is defined in an open way that easily allows using it in other protocols, interfaces, and applications.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5102"/>
          <seriesInfo name="DOI" value="10.17487/RFC5102"/>
        </reference>
        <reference anchor="RFC3022">
          <front>
            <title>Traditional IP Network Address Translator (Traditional NAT)</title>
            <author fullname="P. Srisuresh" initials="P." surname="Srisuresh">
              <organization/>
            </author>
            <author fullname="K. Egevang" initials="K." surname="Egevang">
              <organization/>
            </author>
            <date month="January" year="2001"/>
            <abstract>
              <t>The NAT operation described in this document extends address translation introduced in RFC 1631 and includes a new type of network address and TCP/UDP port translation.  In addition, this document corrects the Checksum adjustment algorithm published in RFC 1631 and attempts to discuss NAT operation and limitations in detail.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3022"/>
          <seriesInfo name="DOI" value="10.17487/RFC3022"/>
        </reference>
        <reference anchor="RFC3234">
          <front>
            <title>Middleboxes: Taxonomy and Issues</title>
            <author fullname="B. Carpenter" initials="B." surname="Carpenter">
              <organization/>
            </author>
            <author fullname="S. Brim" initials="S." surname="Brim">
              <organization/>
            </author>
            <date month="February" year="2002"/>
            <abstract>
              <t>This document is intended as part of an IETF discussion about "middleboxes" - defined as any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host.  This document establishes a catalogue or taxonomy of middleboxes, cites previous and current IETF work concerning middleboxes, and attempts to identify some preliminary conclusions.  It does not, however, claim to be definitive.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3234"/>
          <seriesInfo name="DOI" value="10.17487/RFC3234"/>
        </reference>
        <reference anchor="RFC8158">
          <front>
            <title>IP Flow Information Export (IPFIX) Information Elements for Logging NAT Events</title>
            <author fullname="S. Sivakumar" initials="S." surname="Sivakumar">
              <organization/>
            </author>
            <author fullname="R. Penno" initials="R." surname="Penno">
              <organization/>
            </author>
            <date month="December" year="2017"/>
            <abstract>
              <t>Network operators require NAT devices to log events like creation and deletion of translations and information about the resources that the NAT device is managing.  In many cases, the logs are essential to identify an attacker or a host that was used to launch malicious attacks and for various other purposes of accounting.  Since there is no standard way of logging this information, different NAT devices use proprietary formats; hence, it is difficult to expect consistent behavior.  This lack of standardization makes it difficult to write the Collector applications that would receive this data and process it to present useful information.  This document describes the formats for logging NAT events.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8158"/>
          <seriesInfo name="DOI" value="10.17487/RFC8158"/>
        </reference>
        <reference anchor="RFC1631">
          <front>
            <title>The IP Network Address Translator (NAT)</title>
            <author fullname="K. Egevang" initials="K." surname="Egevang">
              <organization/>
            </author>
            <author fullname="P. Francis" initials="P." surname="Francis">
              <organization/>
            </author>
            <date month="May" year="1994"/>
            <abstract>
              <t>This memo proposes another short-term solution, address reuse, that complements CIDR or even makes it unnecessary. The address reuse solution is to place Network Address Translators (NAT) at the borders of stub domains.  This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="1631"/>
          <seriesInfo name="DOI" value="10.17487/RFC1631"/>
        </reference>
        <reference anchor="RFC6144">
          <front>
            <title>Framework for IPv4/IPv6 Translation</title>
            <author fullname="F. Baker" initials="F." surname="Baker">
              <organization/>
            </author>
            <author fullname="X. Li" initials="X." surname="Li">
              <organization/>
            </author>
            <author fullname="C. Bao" initials="C." surname="Bao">
              <organization/>
            </author>
            <author fullname="K. Yin" initials="K." surname="Yin">
              <organization/>
            </author>
            <date month="April" year="2011"/>
            <abstract>
              <t>This note describes a framework for IPv4/IPv6 translation.  This is in the context of replacing Network Address Translation - Protocol Translation (NAT-PT), which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network.  This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6144"/>
          <seriesInfo name="DOI" value="10.17487/RFC6144"/>
        </reference>
        <reference anchor="RFC6146">
          <front>
            <title>Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers</title>
            <author fullname="M. Bagnulo" initials="M." surname="Bagnulo">
              <organization/>
            </author>
            <author fullname="P. Matthews" initials="P." surname="Matthews">
              <organization/>
            </author>
            <author fullname="I. van Beijnum" initials="I." surname="van Beijnum">
              <organization/>
            </author>
            <date month="April" year="2011"/>
          </front>
          <seriesInfo name="RFC" value="6146"/>
          <seriesInfo name="DOI" value="10.17487/RFC6146"/>
        </reference>
        <reference anchor="RFC6296">
          <front>
            <title>IPv6-to-IPv6 Network Prefix Translation</title>
            <author fullname="M. Wasserman" initials="M." surname="Wasserman">
              <organization/>
            </author>
            <author fullname="F. Baker" initials="F." surname="Baker">
              <organization/>
            </author>
            <date month="June" year="2011"/>
            <abstract>
              <t>This document describes a stateless, transport-agnostic IPv6-to-IPv6 Network Prefix Translation (NPTv6) function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT (NAPT44) and provides a 1:1 relationship between addresses in the "inside" and "outside" prefixes, preserving end-to-end reachability at the network layer.  This document defines an Experimental Protocol  for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6296"/>
          <seriesInfo name="DOI" value="10.17487/RFC6296"/>
        </reference>
        <reference anchor="RFC0791">
          <front>
            <title>Internet Protocol</title>
            <author fullname="J. Postel" initials="J." surname="Postel">
              <organization/>
            </author>
            <date month="September" year="1981"/>
          </front>
          <seriesInfo name="STD" value="5"/>
          <seriesInfo name="RFC" value="791"/>
          <seriesInfo name="DOI" value="10.17487/RFC0791"/>
        </reference>
        <reference anchor="RFC8200">
          <front>
            <title>Internet Protocol, Version 6 (IPv6) Specification</title>
            <author fullname="S. Deering" initials="S." surname="Deering">
              <organization/>
            </author>
            <author fullname="R. Hinden" initials="R." surname="Hinden">
              <organization/>
            </author>
            <date month="July" year="2017"/>
            <abstract>
              <t>This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="86"/>
          <seriesInfo name="RFC" value="8200"/>
          <seriesInfo name="DOI" value="10.17487/RFC8200"/>
        </reference>
        <reference anchor="RFC5475">
          <front>
            <title>Sampling and Filtering Techniques for IP Packet Selection</title>
            <author fullname="T. Zseby" initials="T." surname="Zseby">
              <organization/>
            </author>
            <author fullname="M. Molina" initials="M." surname="Molina">
              <organization/>
            </author>
            <author fullname="N. Duffield" initials="N." surname="Duffield">
              <organization/>
            </author>
            <author fullname="S. Niccolini" initials="S." surname="Niccolini">
              <organization/>
            </author>
            <author fullname="F. Raspall" initials="F." surname="Raspall">
              <organization/>
            </author>
            <date month="March" year="2009"/>
            <abstract>
              <t>This document describes Sampling and Filtering techniques for IP packet selection.  It provides a categorization of schemes and defines what parameters are needed to describe the most common selection schemes.  Furthermore, it shows how techniques can be combined to build more elaborate packet Selectors.  The document provides the basis for the definition of information models for configuring selection techniques in Metering Processes and for reporting the technique in use to a Collector.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5475"/>
          <seriesInfo name="DOI" value="10.17487/RFC5475"/>
        </reference>
        <reference anchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton">
              <organization/>
            </author>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <author fullname="T. Narten" initials="T." surname="Narten">
              <organization/>
            </author>
            <date month="June" year="2017"/>
            <abstract>
              <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters.  To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper.  For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed.  This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t>This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC6313">
          <front>
            <title>Export of Structured Data in IP Flow Information Export (IPFIX)</title>
            <author fullname="B. Claise" initials="B." surname="Claise">
              <organization/>
            </author>
            <author fullname="G. Dhandapani" initials="G." surname="Dhandapani">
              <organization/>
            </author>
            <author fullname="P. Aitken" initials="P." surname="Aitken">
              <organization/>
            </author>
            <author fullname="S. Yates" initials="S." surname="Yates">
              <organization/>
            </author>
            <date month="July" year="2011"/>
            <abstract>
              <t>This document specifies an extension to the IP Flow Information Export (IPFIX) protocol specification in RFC 5101 and the IPFIX information model specified in RFC 5102 to support hierarchical structured data and lists (sequences) of Information Elements in data records.  This extension allows definition of complex data structures such as variable-length lists and specification of hierarchical containment relationships between Templates. Finally, the semantics are provided in order to express the relationship among multiple list elements in a structured data record.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6313"/>
          <seriesInfo name="DOI" value="10.17487/RFC6313"/>
        </reference>
      </references>
    </references>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>TODO acknowledge.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+097XbbNrL/9RRY50fjHlOxbMdJ3O2969jyxufEsdd2trcn
pz8gEpJwQ5EqQdpW07zLfZZ9sp0PgAQlSrZjK2n3Kue0lkhgZjBfGACDURAE
rVznsdoTaxd6NI6VONI3yog8FflQieMzcRSn1+I46afZSOY6TUT3ZpxmuXh6
fHZ0/D/r4nj/3b44VwNt8myy1pK9XqauABy95rcEcq0VylwN0myyJzSAa7Wi
NEzkCFBHmeznQS8twlgG6djI60Ggx319E/SxZ7C52TJFb6SNAfz5ZAxdjruX
R62kGPVUtteKAPBeK0wToxJTmD2RZ4VqARHbLZkpCcScjlVG1Bshk0icyEQO
1Egl+VrrOs0+DrK0GC9qJvYBjvgJmupkIP6OzddaH9UEOkd7LREIGm1LFvkw
zfBBS8C/fhHHPMKTdAh/I/EaxigjqTN6n2YDmejfCOOeOM1kMlD0Qo2kjvfE
iHu1e67X31Jq0w7TUWsWyWuVpDoXB7HURjUgeFPIa6V9BD3q0Q6px9+G9J6B
JyzuK+Artic5BjRI+wD+WcW5g450E2irlam6ymyg8j0xzPOx2Xv27Pr6uq2B
222g+JkEOQ8SZLt5RmrA/2/fDPNRXIIgoYutza2toNOxRJ5d7QbdN7MUJrnK
EpWLsyzN0zCNxT9VhrokdpHEq911cSYz4CE0MxsEBkaQgzJhmzdKRioTl6B3
XzQAoGlcQp/+zoN6MvU06MwZZks7JqNkWq0gCITsgeXJMG+1LofaCLCqglQ2
UibMdA+M2bBl92uWjYZ5B9Fl1rLb4nKojAMCZiVAhZJ4Iooxkkhwx6kGvPAh
UdfAMUJh+2vFJiVjk/pdkBQmdEzY074w6UjVKYrJBg3Q1DXrbTvskY6iWLVa
T1C8WRoVITZutfYNAT09u9j/6e8CGBIWWQbdgVT0EBpkiTb86dN/HweHlWk5
v5P1wxedrecB0/j5MwCTeUkx9Do/OsAGnz9vEB7AAa4h1r+BdVNTIj+FV5kA
gQLVMCSP4egUHU8BXGVXgAqYpkSSIjrkDaJsw+gipaINEGISKqEBoE7AmGQs
QkBMDNIJKMjmiw3LOna8cxlIwkMsoNa/FoADOGPGKtR9DWOQyUTEKTiZTDy9
HmpQGyB+wqS50bGcAWuu4Rv+hfGNpcnXUUt8HYR2KolI0sxCalqOHzWih+JA
iRBoEpGBTuGkPa3QMbwALRIGLBn1pEmrq0lnDpNn9Ri8H9grD96IfhqDRRgw
rkC8d3qKcoUOiBv8ew4eEgm2A59SX5nA5CSefvqEzz9/Bn2dApQB1zVyM4oQ
imR2Ar9hDNBZ3QDZ+KI+CgCYpwG6mCaYZI9KsvXhJIjwK2aC3GBKDHN8fD1U
iQhlHBPyRfiq7oSy9S4l+cl8AxkFUyWw9kKR2YnnOHQ0jc3OFprGlGZrNspy
VgE8fdAo1GhQU190XTsiUrhI9XUCcgFOs+U972xuWRkChDRTbITOPEkiNR+Y
Wnsi3UPdRptEWj99+ktpyTA2G/X48iHkyBjwZkTXSE5gxoRZ+QptPSVNRJ8N
kB3CNvqjgzS5gs9lGHFIgOg7qrQSH9GgIHIwYu3k/cXl2gb/Fe9O6fN59x/v
j8+7h/j54s3+27flh5ZtcfHm9P3bw+pT1fPg9OSk++6QO8NTUXvUWjvZ/xne
IFVrp2eXx6fv9t+uzbIN1QkG2FNkwNk4g1kJraPl5hQSyeuDs3/9X2fHsnKr
03kFkuYvLzsvdtChga4xthSnCv6K/qQlx2MlM4QCmgjqONY5TA2kWGBi14lA
AQM3v/+AnPllT/y1F447O/9lH+CAaw8dz2oPiWezT2Y6MxMbHjWgKblZez7F
6Tq9+z/Xvju+ew9bqDbvKwd56LmUT0/IkbDmoBqiG2QBYFP2V+Q/i55ha4Q5
Tyao9yocpuxXr2RcOAWHlyhaoxRNHeCAZPhRke4+EXk4Ph1bXT1FoaX8TQzl
FbsrCIEj8eNfxfNdBwlmpriImCbpQQBy22I/ceYHGmZti8yH55yJAHGTZaZA
foamdXlwZrH65DlkiuITaFYY8lroNph0DKLKsI2jNmtwvosG9SriCCExWUjL
HvhT8CcxsE/QMoMAYxT4BnTSTo7oMyeis/1qQ3R2NjfE1vNt1u2t5zvokP3x
oHco8hSdHXdrmv3IE0tyLyQeZBCHjs7l2YAWPVQFnybbLA1VVLCZsgpYcGBN
PQwS0ITVzVAWqCxtUrAzF57tY5Tne/3zcq584iaZVoveWJkpw4zyx1FpHrgM
CvB6Ezep4XtQEx0Sg+sTXH2eKRIMrtf2oR+KB8IaL3JZY0/tTyUwMf+OE2zT
v99FMxjxO/TR4WiMMfxBGing607Z5/YQHnrWQvj6dw7hGRjiGTCeu4OHDgGu
agNezzY8cauE6edBp0JbH97u/YY3tUaZflIN0Ue1BC4+mXpKozU+4iWJbwZx
CHhMw4iXwdgnM8+DrZkRfyXE24x4nOkrsN0uT//aqHekcY6GW0lQZcdSq2cf
MXs/7fE6/ce1A01B2pRPYg8xx0F8tgGXi3MBhHSR+Hm19Pz0xAtmF7u2qcgV
w1Mlw2G5jOuW7u4OEzFPTH140U2icyUNrlC/F6dvD2mTIvBn+j2ManExCY0I
LS3NgWew2KAxtcU/eRZH3z6F3MfgrdkvlPqCPZYndvMNgAawfAuYpjZT3CyI
PRjVu+5PX2VUC+l45CGT/IDQ00wPiOBkAIgzZQxQFY8WCPPYTn8GJ2baDsAh
GUWbmOIaAl1avysMRUKYpmFSzWQfwgyRWlwVI6w1whsxLnoxtJFMBO09jNow
w5r83f7lRVpkIblHS+SGewOk5ZbhDa/PbM/LTCYGw6sz+I+DG9fAA1BrRWL7
tZAxr6CvdT4kkmsE4jhgvYgRDK7+Foh8PqsfS6sBcpBWKAJLaMCcvF23eCG6
vbm1Zb0D7wG4JR76CeB3e749rDRjaZqxRM+wWG3upRnWpXRxk2DhbAAzVMM2
ntAR7i70aUsVIQqFkOzWG8xP3nukAEMo2pjy23ZvJO6eGUsUPzZuJbchekVe
7hPGeqR5jtygtjlKOWaaWFNnn0cqVvj8cghcGqaw4DrHWRQ3MoEx1dPuTahU
hI9VHpbSZ+bNGf6saqwhdmIn7dKvlQqxgYvch8mcGENh6OP5Br/t1vbO3La8
xd1Lb5Tx+7zsPH/Z2IekaVf6O0Fnd4ETWinXg5Vr2d7G07w/pnJRaKszdS3j
+DZnVs15suzj1GUfA2dg+NXcONBH8mjRrQXKfP7S4HYZ41pmfDs1aBRhT2PU
ewhv7AnaXCGK/enDDlIR11NUFAhYTQ5T3KOzW+X0hpq/JnSCwwq7P14GEO35
julk/2fctBuDcfPJEnCc1hKHMpfgAMI0Y/uX43GsLVoQBmIz1a5hP0tHuMbk
Y05crp3hXhrEI9D1lLYgGe9higec/i6jsNuabXHcn+9B4DH6tVk6mUSi0Jg0
1BTGUVQkHVOutBQmTMfg23RutwOLkTtZRO7BMravB0Um7yoB2tZPwEcXEL/0
gx4wvC3KkxzeNGwYI3EPGDmZP9Aaf3EcONSkiYcw5Lls5wMcxirsrjttTpNF
xFr24gkx3H5RPBPQGbVltbySOqZXT3VbtTf8Qb0/PFvfmD8Gi7A6jaClvieu
BQHplN1M+aUPX2yjDDcohfrLl/qmlbWurHVlrbdZ6xJn22lLtttJacVzOpLB
sHLROtCG2F43PlFZMNomFI8VOHmwA6LjDqujBQuRRx/dEgU6b+goVZmkyWRk
k+0uVThM9K/FIrk2uucaFJE7MDU3WSVPRI1m4qzbb3epYEVG+URdtJkKsE1q
IPghmSUd1QOeUGU5+oPGTCKcCUCr0xF8xZNf6oSLhkW9Foi0mXuPpbI16EE5
+EedWFeSa5bcEs1xrljtDtstjnXRVuNjOkxczC9tA6mzu91Z1HZnx2+929mZ
vyMArXenW+8uhL1ba731amHr3VrrzRev5tONG9G1TYmtzc1FjRftdN1dykve
z3nITs5KyixlsmyjMFEnzfbjQZqBx1x0CneXfU7OXqUcIwaN7TggN+Kpag8g
SD3ScU6JwxviAjc34dN6lXrpfHyPs3MuSig2bG6Lk9TkdqYwqgQ+lFeIujyU
F0dFRgdCzZ4bt0xpQ5Oyfoq4TNydzNLvjls8bJx/HeNTndXQ4hGta2WNpKcw
rJaNSZg7LzBpUhyxoGqwNuaT7sHh9KCq3SiNVFwlURI9eKfBVCybC9bSW57T
u5WUk29WcXXmVZnTKSPLVaQMIfL4YSmDCWGDIX4H3qMsZUZzLI+Gc0ObSPMS
3Jr5XeULzNU9n1Cfg5gbeYerB2Mj65kunDZLK1XRy1KJW5OZVvkE2TxOoStG
EVUHmy5Y5ssZy2fQ6jEECxPgXo4LMGcb4unzddrcr1Luc8LIm/1CDjKF6WAV
gjLv/MuTC1b2vbLv+9v3Ei37T2lhdwtvpj0Kp91WYCyPcI/vlti7eQllbzLh
zRdZHS0mdrPL1yjFmNp8mYPy1eVHlfDOVTMs42uoTdAS2+1Omdk1c2/mhNTW
v3nwAx0o8z0fCwHFNUqzusKnSXk6asqLWKVpfJjPsl8we2z6zhWDwUHyG5VV
sLxrRU1ukLZbKcydggsq6j1BjeW7OrUdYJenRyEZAiGj3aB9PLzvlaVXYGyg
6yNYe8lEmxE1tUnAHudr13PcLTxOI8GM/wJ03KaGo+Vc5PBC4v2IfeaxO5rc
wtATYIE/AfN73OX7SvdWuvdYuvewxaInocDqWoDj4WToOT73Qo0kzHqhua/T
Na5jTd8b5Ok0okHhK5upoDUq/NZXUPhaFPJhvnqWHJvRe1BImDFhSsboAYdK
oOwxvgVcDdT1/IGf43wL6sA3OjZvNjfFU6BJFnG+jpruztiS8lAHpu0KmD3F
SW1+ABDxAx4u2fs8ePsMVH1cxJweOAGFPYB1BHKnfjZ2hDc3z/nmMmGJUsXn
L5RObVDLEbDEDEJYRTvhepR8icmXPH2wyVeE3Mvuq25//ClnZXkry1tZ3h90
wnXDmTPdvk90fu+ptsBOdzX2MIUVnhmnSblu5e54612HGpd+UxbXpBZ+/p7n
D55//cBzloeGmHhfF3BJR13bvIEx3/KTNFFzzL40cHqd4N0jY+4S7364xQZp
PHWf9pjzxUp9VuqzXKdXsFdDl4cpO+dYbAj8c7b4moKixnYOcbtvE3cN2OS2
4oIUVLyId8IyPFPetyyHJ7+pLC1vDJuK0dyFYdgEonJHa0No5TXS9cinKsNy
LUEzPB5OKZ3rhNfOvYEYd+G8nxY4c+W3sxqTQ3SoApo3A4RVXuB9wN25b8Zc
ys66I38XK+q3Zn5NobtJ9AB1VljM4kH8RggrVf56jP3PUmNgF947o5JmfRmq
25IHvTs62vXBlMvMnYnZMxhgy5E7EeopFEqmQqWvVMTHNSwDOo6wR2qlVEZU
Jg+k1/tfLKDxne4jUd9hsO9x+vaJCh7qPpU3GOneLaK4J7TFavmNGPQos3t9
mKgh6mspiCnP8lbK8ajMWYZioGYQ3kOqidArENYJHZjedxk7dVsgcgB5BgvB
1dHJI+1RHaSJxQY8OaLkc2AkL0j2B6CpA9pPIeZllMPtx/64zZL4Cfg23X6g
EpVRXR3p5UdWp9zs5NXI7nG4nR17OA4zRBJgDa7G410brHsZmISU1izXQx0O
rfgij4984AvPNcjS1RD9QWjml702HNPwj6l4H5XTSqJnALP29iDFi5N5c3qo
8TLfEa4bOZfUKm9UwvqBtIm4jIzwCWX+UJ0t6kRH6jCZKXfUj7W3Gnp4qjyr
QGLe7hJl0mAdOh6Vq9xXHoQ3cNKmKTww5ZIABz7gwI7jMRfkK0NYGcLSDWGJ
WwALrMSVrblYQq4lhSagkih9VviZhCovzf3WBC1tpvOz7oBgOmOrxNeQtHUM
Cle/yVW+fWrWBdUj7GEdUVBJv5bqN0v3umc+VKOcveT35WRKnQG7jJraVxsX
GdiEcg6WrtlVTPCENLU/WKs5y1qmR3hgwQqIoRZgKzL+2i8SWydRzhxbXZCP
e+rqmnbW2eDvorOXFXnzMjfvsgJcVJvIpT5LJ6Zl502ubHVlq8suuNWg1Dj9
4NH2W518PEI6bl3FzlFnJ+B6tRI+RkaswFk6Qgcd/QiBGmBqc94SPah286e8
xAxtj3VXiPJ8EHdAxNhLI05J7DGGUwxXKxRMCY8W/JvCSGT53itAQbVBTcqN
RkWca6yh7d1rLLesTs+/Q60bUIUqdoIVp2I5wS28mvf8cHxx+uy4e9B+sfPq
ZdDZ67x6tXPL3XXo0+12X25utbd/KT92Or80gvoCZ/YNpP8fK6olqPW9pI8u
YaR7B3KMZcwv9UjdJeWtVmstcQKMdV9R7XqrDVyTED6cHL+2sTiWYcsUFnq8
cnUIXANKekBaTml9cexlopMmeqeGbq/arYAYdlnegGq9cRbJNJIwhjiISuYS
cWWtf1dBkWFwBX6+0tmnfHKeJpA9Joe5l08qy9pLpQobkIJfi6F2dFpd7Kdx
EOdUWQrAGzrdrbNHu6WpletezCXBapwGZWTLMEyz2FClKLKLi3cnZ5wTU88g
OVE2991LspmtB2Fl5U4TGMPTavOfDALDjxg4GU2QslitC5uMo+lgHEDaEvof
E6sQ6gbzeI2NYojdBI+KJ8jKVDyzRN5/75KEvXLTY0mVr8s6eKfHh7VaDheu
RH/EgrH37bY723gZ40KPdIwxywbqUqT7tCrPWVfYJog6L5GpajQlMOUmfXvf
GKmp1eXI2VYifaWjAkY3x+6aI4nmEdP6+pYhL7hlPI+CR5p2AXxguRggF8v0
ny8+7lo5npXjWTme/weOZ4lR03yv5Coc/KNIc+nKHD5GQVE/TuaajoSiLKXo
ats9oJbiFMAl1e38FbEEymK5S5G/u15bZwdxtQOxORfFsvVsyYUtvVTjw7d0
vr14l11poVH2fxLxutIlrojp41QJrsu8qpD6cHF71VaXY8i5Q7Cy4W8tzaVX
SJkS9Z9EmvgTFBcqLDKdT/i3KCL3M6KtFscbxr0Oa695c0mbsDDG3cB3Jw8v
Ec9fyp9UYzSUQTyN4rz8FQt6LUMP9nQaNVX4q13Ex3tFXg88OM3UmOvP2x/h
ot9b7MnwI5KwH2KMCqHzgATa+rTH+Wkq+nGtL2Oj8Dc5Lk8PTwGsa4lA/g2i
Je2ya3YAAA==

-->

</rfc>
