<?xml version='1.0' encoding='utf-8'?> 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.2 (Ruby 3.2.2) -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
ipr="trust200902"
docName="draft-ietf-opsawg-rfc7125-update-07"
number="9565"
category="std"
consensus="true"
submissionType="IETF"
obsoletes="7125"
updates=""
tocInclude="true"
sortRefs="true"
symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.18.2 -->
version="3"
xml:lang="en">

  <front>
    <title abbrev="tcpControlBits IPFIX">An IPFIX Information Element">An Update to the tcpControlBits IP Flow Information Export (IPFIX) Information Element</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-opsawg-rfc7125-update-07"/> name="RFC" value="9565"/>
    <author fullname="Mohamed Boucadair">
      <organization>Orange</organization>
      <address>
        <postal>
          <city>Rennes</city>
          <code>35000</code>
          <country>France</country>
        </postal>
        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <date year="2023" month="November" day="29"/> year="2024" month="March"/>

    <area>Operations and Management</area>
    <workgroup>OPSAWG</workgroup>

    <keyword>IPFIX</keyword>
    <keyword>TCP</keyword>
    <keyword>Measurement</keyword>
    <keyword>Export</keyword>
    <keyword>Observability</keyword>
    <abstract>
      <?line 45?>

<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
   IPFIX IANA
   "IPFIX Information Elements" registry and avoids future conflicts with the authoritative
   TCP
   IANA "TCP Header Flags Flags" registry.</t>
      <t>This document obsoletes RFC 7125.</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/-ipfix-rfc7125-update"/>.</t>
    </note>
  </front>
  <middle>
    <?line 59?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>TCP defines a set of control bits (also known as "flags") for
   managing connections (<xref section="3.1" sectionFormat="of" target="RFC9293"/>). The "Transmission Control Protocol (TCP) "TCP
   Header Flags" registry was initially set by <xref target="RFC3168"/>, but it was
   populated with only TCP control bits that were defined in <xref target="RFC3168"/>.
   <xref target="RFC9293"/> fixed that by moving that registry to be listed as a
   subregistry under the "Transmission Control Protocol (TCP)
   Parameters" registry <xref target="TCP-FLAGS"/>, adding bits that had previously been specified
   in <xref target="RFC0793"/>, and removing the NS (Nonce Sum) bit as per <xref target="RFC8311"/>.
   Also, <xref section="6" sectionFormat="of" target="RFC9293"/> introduces "Bit Offset" to ease referencing each
   header flag's offset within the 16-bit aligned view of the TCP header
   (Figure 1 of <xref target="RFC9293"/>). <xref target="TCP-FLAGS"/> is thus settled as the
   authoritative reference for the assigned TCP control bits.</t>
      <ul empty="true">
        <li>
          <t>Note:
          <t indent="3">Note: The bits in offsets 0 through 3 are not header flags, but the TCP segment Data Offset field.</t>
        </li>
      </ul>
      <t><xref target="RFC7125"/> revised the tcpControlBits IP Flow Information Export
   (IPFIX) Information Element (IE) that was originally defined in
   <xref target="RFC5102"/> to reflect changes to the TCP control bits since
   <xref target="RFC0793"/>.  However, that update is still problematic for
   interoperability because a value was deprecated since then (<xref section="7" sectionFormat="of" target="RFC8311"/>) target="RFC8311"/>),
   and, therefore, <xref target="RFC7125"/> risks deviating from the
   authoritative TCP "TCP Header Flags" registry <xref target="TCP-FLAGS"/>.</t>
      <t>This document fixes that problem by removing stale information from
   the IPFIX "IPFIX Information Elements" registry <xref target="IPFIX"/> and avoiding future conflicts with the
   authoritative TCP "TCP Header Flags" registry <xref target="TCP-FLAGS"/>. The update in this document is also useful
   to enhance
   enhances observability. For example, network operators can identify
   when
   packets that are being observed with unassigned TCP flags set and,
   therefore, identify which applications in the network should be upgraded
   to reflect the changes to TCP flags that were introduced, e.g., in <xref target="RFC8311"/>.</t>
      <t>The main changes to from <xref target="RFC7125"/> are listed in <xref target="changes"/>.</t>
    </section>
    <section anchor="terminology">
      <name>Terminology</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 BCP&nbsp;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 terms defined in Section 2 of <xref target="RFC7011"/>.</t> target="RFC7011" section="2" sectionFormat="of"/>.</t>
    </section>
    <section anchor="revised-tcpcontrolbits-information-element">
      <name>Revised tcpControlBits Information Element</name>
      <dl>
        <dt>ElementId:</dt>
        <dt>ElementID:</dt>
        <dd>
          <t>6</t>
        </dd>
        <dt>Data
        <dt>Name:</dt>
        <dd>
           <t>tcpControlBits</t>
        </dd>
        <dt>Abstract Data Type:</dt>
        <dd>
          <t>unsigned16</t>
        </dd>
        <dt>Data Type Semantics:</dt>
        <dd>
          <t>flags</t>
        </dd>
        <dt>Status:</dt>
        <dd>
           <t>current</t>
        </dd>
        <dt>Description:</dt>
        <dd>
          <t>TCP control bits observed for the packets of this Flow.
This information is encoded as a bit field; each TCP control
bit has a corresponding bit in that field. A bit is set to 1 if any
observed packet of this Flow has the corresponding TCP control bit
set to 1. The bit is cleared to 0 otherwise.</t>
        </dd>
        <dt/>
        <dd>
          <t>As per
          <t>Per <xref target="RFC9293"/>, the assignment of the TCP control bits is
managed by IANA from via the "TCP Header Flags" registry <xref target="TCP-FLAGS"/>.
That registry is authoritative to
Implementers can retrieve the most recent current TCP control bits.</t>
        </dd>
        <dt/>
        <dd> bits from that registry,
which is authoritative for them.</t>
          <t>As the most significant 4 bits of octets 12 and 13 (counting from
zero) of the TCP header <xref target="RFC9293"/> are used to encode the TCP data
offset (header length), the corresponding bits in this Information
Element <bcp14>MUST</bcp14> be reported by the Exporter with a value of zero and <bcp14>MUST</bcp14> be ignored
by the Collector. Use the tcpHeaderLength Information Element to
encode this value.</t>
        </dd>
        <dt/>
        <dd>
          <t>All TCP control bits (including those unassigned) <bcp14>MUST</bcp14> be exported
as observed in the TCP headers of the packets of this Flow.</t>
        </dd>
        <dt/>
        <dd>
          <t>If exported as a single octet with reduced-size encoding (<xref section="6.2" sectionFormat="of" target="RFC7011"/>), this
Information Element covers the low-order octet of this field (i.e.,
bit offset positions 8 to 15) <xref target="TCP-FLAGS"/>. A Collector receiving this Information Element
with reduced-size encoding must not assume anything about the
content of the four bits with bit offset positions 4 to 7.</t>
        </dd>
        <dt/>
        <dd>
          <t>Exporting Processes exporting this Information Element on behalf
of a Metering Process that is not capable of observing any of the
flags with bit offset positions 4 to 7 <bcp14>SHOULD</bcp14> use reduced-size encoding,
and only export the least significant 8 bits of this Information
Element.</t>
        </dd>
        <dt/>
        <dd>
          <t>Note that previous revisions of this Information Element's
definition specified that flags with bit offset positions 8 and 9 must be exported as
zero, even if observed.  Collectors should therefore not assume
that a value of zero for these bits in this Information Element
indicates the bits were never set in the observed traffic,
especially if these bits are zero in every Flow Record sent by a
given Exporter.</t>
        </dd>
        <dt/>
        <dd>
          <t>Note also that the "TCP Header Flags" registry <xref target="TCP-FLAGS"/> indexes the bit offset from the most-significant most significant
bit of octet 12 to the least-significant least significant bit of octet 13 in the TCP header,
but the tcpControlBits is encoded as a regular unsigned 16 bit 16-bit integer.</t>
        </dd>
      </dl>
      <t>Units:</t>
      <t>Range:</t>
      <dl>
        <dt>References:</dt>
        <dd>
          <t><xref target="RFC9293"/>[This-Document]</t>
        </dd>
        <dt>Units:</dt>
        <dd/>
        <dt>Range:</dt>
        <dd/>
        <dt>Additional Information:</dt>
        <dd>
          <t>See the assigned TCP control bits in the "TCP Header Flags" registry <xref target="TCP-FLAGS"/>.</t>
        </dd>
        <dt>Reference:</dt>
        <dd>
          <t><xref target="RFC9293"/>, RFC 9565</t>
        </dd>
        <dt>Revision:</dt>
        <dd>
          <t>2</t>
        </dd>
      </dl>
    </section>
    <section anchor="an-example">
      <name>An Example</name>
      <t><xref target="ex"/> shows an example of a tcpControlBits Information Element set to 146. 0x92, where MSB indicates the most significant bit and LSB indicates the least significant bit. This Information Element is used to report TCP control bits for a Flow
that has CWR (Congestion Window Reduced), ACK, and SYN flag bits set (that is, bit offset positions 8, 11, and 14).</t>
      <figure anchor="ex">
        <name>An Example of the tcpControlBits Information Element</name>
        <artwork align="center"><![CDATA[
MSB                           LSB
                     1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|0|0|0|0|1|0|0|1|0|0|1|0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>IANA is requested to update has updated the "tcpControlBits" entry of the "IPFIX Information Elements" registry <xref target="IPFIX"/>
   to echo the details provided in Section 3.</t> <xref target="revised-tcpcontrolbits-information-element"/>.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>Because the setting of TCP control bits may be misused in some
   flows
   Flows (e.g., Distributed Denial-of-Service (DDoS) attacks), an Exporter
   has to report all observed control bits even if no meaning is associated
   with a given TCP flag. This document uses a stronger requirements language
   compared to <xref target="RFC7125"/>.</t>
      <t>This document does not add new security considerations to those already
   discussed for IPFIX in <xref target="RFC7011"/>.</t>
    </section>
  </middle>
  <back>

    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>

        <reference anchor="TCP-FLAGS" target="https://www.iana.org/assignments/tcp-parameters/tcp-parameters.xhtml#tcp-header-flags"> target="https://www.iana.org/assignments/tcp-parameters/">
          <front>
            <title>TCP Header Flags</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="RFC9293">
          <front>
            <title>Transmission Control Protocol (TCP)</title>
            <author fullname="W. Eddy" initials="W." role="editor" surname="Eddy"/>
            <date month="August" year="2022"/>
            <abstract>
              <t>This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="7"/>
          <seriesInfo name="RFC" value="9293"/>
          <seriesInfo name="DOI" value="10.17487/RFC9293"/>
        </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="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>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9293.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7011.xml"/>

      </references>

      <references anchor="sec-informative-references">
        <name>Informative References</name>

        <reference anchor="IPFIX" target="https://www.iana.org/assignments/ipfix/ipfix.xhtml"> target="https://www.iana.org/assignments/ipfix/">
          <front>
            <title>IP Flow
            <title>IPFIX Information Export (IPFIX) Entities</title> Elements</title>
            <author>
              <organization>IANA</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="RFC3168">
          <front>
            <title>The Addition of Explicit Congestion Notification (ECN) to IP</title>
            <author fullname="K. Ramakrishnan" initials="K." surname="Ramakrishnan"/>
            <author fullname="S. Floyd" initials="S." surname="Floyd"/>
            <author fullname="D. Black" initials="D." surname="Black"/>
            <date month="September" year="2001"/>
            <abstract>
              <t>This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3168"/>
          <seriesInfo name="DOI" value="10.17487/RFC3168"/>
        </reference>
        <reference anchor="RFC0793">
          <front>
            <title>Transmission Control Protocol</title>
            <author fullname="J. Postel" initials="J." surname="Postel"/>
            <date month="September" year="1981"/>
          </front>
          <seriesInfo name="RFC" value="793"/>
          <seriesInfo name="DOI" value="10.17487/RFC0793"/>
        </reference>
        <reference anchor="RFC8311">
          <front>
            <title>Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation</title>
            <author fullname="D. Black" initials="D." surname="Black"/>
            <date month="January" year="2018"/>
            <abstract>
              <t>This memo updates RFC 3168, which specifies Explicit Congestion Notification (ECN) as an alternative to packet drops for indicating network congestion to endpoints. It relaxes restrictions in RFC 3168 that hinder experimentation towards benefits beyond just removal of loss. This memo summarizes the anticipated areas of experimentation and updates RFC 3168 to enable experimentation in these areas. An Experimental RFC in the IETF document stream is required to take advantage of any of these enabling updates. In addition, this memo makes related updates to the ECN specifications for RTP in RFC 6679 and for the Datagram Congestion Control Protocol (DCCP) in RFCs 4341, 4342, and 5622. This memo also records the conclusion of the ECN nonce experiment in RFC 3540 and provides the rationale for reclassification of RFC 3540 from Experimental to Historic; this reclassification enables new experimental use of the ECT(1) codepoint.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8311"/>
          <seriesInfo name="DOI" value="10.17487/RFC8311"/>
        </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="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="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>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8311.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7125.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5102.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9487.xml"/>

      </references>
    </references>
    <?line 222?>

<section anchor="changes">
      <name>Changes from RFC 7125</name>
      <ul spacing="normal">
        <li>
          <t>Clean-up
          <t>Cleaned up the description of the tcpControlBits Information Element by removing mentions of stale flag bits, referring to the flag bits by their bit offset position, and relying upon the IANA TCP "TCP Header Flags" registry.</t>
        </li>
        <li>
          <t>Remove
          <t>Removed the table of TCP flag bits from the description of the tcpControlBits Information Element.</t>
        </li>
        <li>
          <t>Add
          <t>Added the reference  <xref target="TCP-FLAGS"/> to the Additional Information field of the tcpControlBits Information Element.</t>
        </li>
        <li>
          <t>Use
          <t>Used strong normative language for exporting observed flags.</t>
        </li>
        <li>
          <t>Update
          <t>Updated the references of the tcpControlBits Information Element.</t>
        </li>
        <li>
          <t>Bump
          <t>Bumped the revision of the tcpControlBits Information Element.</t>
        </li>
        <li>
          <t>Replace
          <t>Replaced obsolete RFCs (e.g., <xref target="RFC0793"/>).</t>
        </li>
        <li>
          <t>Add
          <t>Added an Example Section</t> example section (<xref target="an-example"/>).</t>
        </li>
      </ul>
    </section>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>This document was triggered by a discussion of the author in the opsawg with working group between the author and the
   authors of <xref target="RFC9487"/>.</t>
      <t>Thanks to Christian Jacquenet, Thomas Graf, and Benoît Claise <contact fullname="Christian Jacquenet"/>, <contact fullname="Thomas Graf"/>, and <contact fullname="Benoît Claise"/> for the
   review and comments.</t>
      <t>Thanks to Michael Scharf <contact fullname="Michael Scharf"/> for the tsvart review, Ketan Talaulikar <contact fullname="Ketan Talaulikar"/> for the rtgdir review,
   and Elwyn Davies <contact fullname="Elwyn Davies"/> for the genart review.</t>
      <t>Thanks to Rob Wilton <contact fullname="Rob Wilton"/> for the AD review.</t>
      <t>Thanks for Tim Bray to <contact fullname="Tim Bray"/> for the artart review and Shawn Emery <contact fullname="Shawn Emery"/> for the secdir review.</t>
      <t>Thanks to Éric Vyncke and Paul Wouters <contact fullname="Éric Vyncke"/> and <contact fullname="Paul Wouters"/> for the comments in the IESG review.</t>
      <dl>
        <dt>Acknowledgments
      <section numbered="false" anchor="acknowledgments7125">
        <name>Acknowledgments from <xref target="RFC7125"/>:</dt>
        <dd> RFC 7125</name>
          <t>Thanks to Andrew Feren, Lothar Braun, Michael Scharf, and Simon
 Josefsson <contact fullname="Andrew Feren"/>, <contact fullname="Lothar Braun"/>, <contact fullname="Michael Scharf"/>, and <contact fullname="Simon
 Josefsson"/> for comments on the revised definition.  This work is
 partially supported by the European Commission under grant agreement
 FP7-ICT-318627 mPlane; this does not imply endorsement by the
 Commission.</t>
        </dd>
      </dl>
      </section>
    </section>
    <section numbered="false" anchor="contributors">
      <name>Contributors</name>
      <t>The authors of <xref target="RFC7125"/> are as follows:</t>
      <ul spacing="normal">
        <li>
          <t>Brian Trammell</t>
        </li>
        <li>
          <t>Paul Aitken</t>
        </li>
      </ul>
      <contact fullname="Brian Trammell">
        <organization/>
      </contact>
      <contact fullname="Paul Aitken">
        <organization/>
      </contact>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA7Va23LbyBF9x1dM6IeVNiQtSrIkc2+hbrZ2dYsox9na2och
MCSnBGK4GEC0Vuu85y/yBfmI7I/ldM8MAFK0va5K5CqLAAc9fT19eqBOpxMV
ukhVX7QGmXgzT2ShRGFEMcWveH5ksiI36aEurDi7FqepWYizbGzymSy0ycTJ
u7nJC7Fxdn169vfN5a9SNVNZ0YrkaJSre2zwRB6eaUUxdpyY/KEvbJFEZmRN
qgpl+2K/t/0iihITZ3IG/ZJcjouOVsW4Y+ZWLiadfBzTmk7JWne29iNbjmba
WmxfPMzxzNnJ7WmUlbORyvsRLepHscmsymyJDYq8VBEU24lkriQUvJqrnJW3
QmaJuJCZnHgjFia/m+SmnNOy6+Hg7atWdKcecDvpR6LjjKEPt0fX9OtCSVvm
/DBdOj/Rp6uRVfm9HOlUFw9RJMtianISEQn8jMs0deZemCl+J+LQlLFMpM75
e5NPZKZ/ZSX74iqX2UTxF7Ep4Vk48RT3Yn8PO/TFjcoyZf2iBJJ3XmxtbfG1
mkmd9sXMbdUdha3+YlhwNzazKMpcRO/hO0HWdU7PB6+GfRbgUwd3xWslE5Uj
Q+TEbVZZJrziCMfgcuCek/lEFX0xLYq57T9/vlgsuhre7mLZc4kATjLynH2O
lOnMZQ71CpWvXnbfTYtZ+oxuTnn3zph3j3RIQ6c0x2ZJ4T+QyicZ1mr1P7RF
z8f6nfvfaR5FnU5HyJEtchkXEUm7OT3ivBeoGG0R/s+qQ5LwkVKEMFmIhbSw
QE90JtP0QSRqrDNspDPe/EVva5vEAAJyNU5VXIh4SslgAypQsJ27kU+slRiR
WlYj75wBL3e6JOO1Wah7lbfdvq5KhcbKQqepmOdmBL2gYSygKhRATA1VoK8N
SBipWJZWCWtmSlBwxb1MS+gylfe4W6KWfilhGewYKZXBmHmuCFCSLrvzdort
gCAlm49yNPeK9pcpFGk4aJybGRlHz7D/sHaiEZcHBgJ5b3RiUZwFSpqsHqc6
hskLXUzZJy4/dMEpxxuvVEQlb51eFeZV4e+61JjpJElVFD2DVuTppIxJ3Sjs
4GIHsBJWQcx4OSAbMrVG3GVmkQnEvMXF0dokZ5OAGaGbzib0UKZiB3sbj49D
91nsdHsk8k/Q6eX2y5337ze70FuJ1i3AwXqYFT4xxXVuChPjwwYU2+ToN8xv
1f6k9NMZSouzj/QePYjHx++wzU5v7+D9+7YYlYXQnKgkZ27mZUohde42GR4j
45dsdZmtEJ1GPjelckI+PtbWCJQh15dkDZAZ5Au+rHRFxo+USHGBldBbkhBk
XbWgzMjE4jO8cl2hV8Mnj48VrpL9MklIl9qwqUxQLkAEU9qQ6nauYj3WKiGp
lbFb+2Rbm7OW090ZpcTlUGxcGqrQYTnbJNlkEKrNP3iw0+t5Lw2QNm1RJ8Le
chpQoXIqIvFaACRxNR4jjC3yFpqeItxAILKYtlYynpJMDxiUgl8AfvgJjic0
J/V6ex1WKQVawtf3Wi1o12W8YXg71RMqQs7NZjyRnUtuJKAppqWlFAPmc/x8
hS9Va6WuYhTiambQxiOraeaK91txaQrqeljKMYINziIrtiAALGEyFTsCpEJk
pmjabl1yB7OsmjAAHMtCejciLVXq0ctFhvAA5vxfGsLG2cnmJ7pCrQi1Bijy
8c7wtCXUAlxydj+zMbj8Xu4NVWOQriGw+jX4+14EnbImou1TztTJzvWIQiE1
kAHYSrVXfK7tHcm911AG2dxsE8tJRKavL+d1gE/Q40vbG0sQVNXr+v7EXRle
XulPj498A9pWnYpV/VCv+izdOcdDfKhSm1bgM3cYxAG01ZMGlU2Jf1JPq2lu
V5yitNQ7OZun8HGmCqLTggNamNyKWGZCJxCqx9z3FxS5uYzvqKaojkaKjHJC
Qycos6VC5frihkIx9d4KYQ3CIVnHUyHnc3jFU30PQUErOzVlmhDwl/NJjtJN
VvgQLW5kfr133YQqiERyqe6k264ROgCtywqFNoyvGuKWEpBM9+2HBfh1/DxI
wa3KZzozqZlgkiBhmEgEjSRA5os3w9tW2/0Wl1f8+ebkr2/Obk6O6fPw9eD8
vPoQ+RXD11dvzo/rT/WTR1cXFyeXx+5h3BVLt6LWxeDHlus7mI9uz64uB+et
pzlDBrmuyiWNgnWtNUqUjXM9coYeHl3/51+9XY/v273eS/jCXRz09ndxQQni
dmM+4C4RmIcIoVWS2CSSM0VizZHmKXAXAIHIggpRUsB9X/5Envm5L74exfPe
7rf+Bhm8dDP4bOkm++zpnScPOyeuubVmm8qbS/dXPL2s7+DHpevg98bNr79L
geOi0zv47ttoDRKhdq1rKUgl2yRPATS360a7v+VTF6l3E9rRSit62mSiyH84
w6TcF3tRxO3ulgZ0XJeZq+Fe8wvsDnqKBmBpiZ/qjjlF5jz6Rv2n3aZCh9DH
A4AwkYDV1CSJ4bALmvCKSxAADMeO5TE74j78FROY5lZ4nL6d8rrY5Lmyc5MF
vuYSXoYuLgbupoMl5H1P6DGyljCu0tZpuaQki2eYWdpgxWIICWK7gYzQXnGK
AqDQGNARQyC4QKgQtr4YBMpX86Z2g/K4aWS8vplrYuM8NEA22hUNwFVHBP9d
mXg+RG9dAJosm/rIUkNirC1yre65h4ObW1oek3Z8vLJKytiwaiVZAmaMnlKI
XZ8aY2HignKht82o0dsRG3xkEto6hP4KirH5lHUuTw0EYKV13nU5Uy1Hl6QB
wZPbDf90qrJJMd1sr4lnII8c90blQEggaAxJIyKpROec40mQo3cQz50wsCDo
Tka4wyv/JJyBDkg9zD96ZFJqYybvijdWBT7pQnfOyq4/OzAQUVkMhXlL53wA
7ZN02QAFS8vEzR8GG9XterNSTjkzSDvZKGDfkesY2BCW9SUNHc7GlTBXw6CA
E7AoDrvzErxAHblj9a/KWULKNfjhXnc7jDoO6jhqnPfrPBKbe9KM1IIWHbRd
xMPtF9RjGIAruqrb9sjh02NurHb044Ar+MXmKvUa1JHi5Nd+ltPrUVZ8zMhZ
ibqgWQQhAPATBNHoNRFyZNw84ouqAQBjU+YulCx4re67pPs+B8BlJMnE0IvZ
kBqLqu59SG20b+TBVKZjrhzE7YKG44YYh6d4mtRHO5ejlBPdJQvbkD14nSHD
MbFPaSx8Fy55XF3jMYpWxS6cGS7QmHCXEeagQpgPlzE7iIbGwPndKO9mOlZr
zePh4S8o/7gxswn14O87zScMPmA7XroUaJSc4NMVggtQ1HvQbT2uChAjWpV7
NhDiik03EikSTolVAPId2KoPYlwjbzXQkMY2V0ou44hEZzQjcovzeFDhQ5HL
MdxPQVLsDp5Z9bi5JwE164KHSdCD66w3ChiMAZFyD4BIgD3RZH5A1DpWPNyw
eSsHC1mi3tXaBpdXrZCaUKeRIlXhe3BAC/IDM2dTc+nKwp2nSMgw4o8QVrjX
KotBgy1TUOHAsERvz3OUQk3Y0DdIKTCs6IamCvodjkKYdjX73k/EmTrHnjb+
HEWDJOEEk2kzqvTYUKmPn6K4UWZ5RL7xlUACtolgDigiPC9G0eOjege/E32n
FzNhkHR48WkCWrGk3b2u437rFuF26Ouu2T7Vm7JachpF/ljOiqO3N2IDCmAq
Y3FvkR2cZgwqaCCDox/coDL88dIdYbujEaIIHtraH6jctuj13LO93U046R/4
iS6Gh+LDP+fDw2jtF70IZLAHNr8DCHwh9oCBB0CFxr3oz51P/It+21r511v5
/w/IYCMe++KZeufexnzTqmPNOPjJgLZQ3Dyrd/i88JsWMUOVt95H7qiciClE
WAz9/nUeTz58XxPq/lIqnqkRa3+4wRR2eecWqonoqW+H1TlLOOiIp66IE1VI
nVo6ybnXyfLwtMPDEq7KnE6t1ih16A+ySBKdVPIxx/hp7s0kHXqJmbacpdiD
3omQhHFKZbHhjhmOiVJrAATWHKsMwNgx486QOmWsxMbxsRluClkUoFF2k3Kr
wj0+pZW2kf80P1eQu6RM6BeZETMlM9KZSLy1BlDs6Fwgpg5cwxlJd934Ca4G
0aignEOj3VtTK1KgUind+83YzOZhqGmekKw7XUuMcmxBJgmayAJ+9f6Pl/zv
UJioqUxzgCufPCXaxqW1fop0Z22MV0sDML2cGcGHFN0jf3bD+F+9v3t8Fs5q
ouhLcQSkzzrl3CdMNccuHfuR8oEMuCPACi7a7pSaeZHvHTWUOF6v83UoEt4E
pA/0aInJw50hUik0z/26UPKGX4+5zhJYVgicB8DQ4pom+Pr4dNnSHmgbK93U
m7O+n3gC/Vlb0FDjEkpUr66rXOKo1rS0PjIgFsVP13hQvRiwn6fAYTmbewGu
qX3e4zdqnkp3gspvBSmnqvpuHqRvBofKGj898DAQDmJ695eqhF8yWICu+0sI
lXzTGoPcKALMJ9VDJ+mAkMmEFjJFCjXRsMTN6/zig/8UY83psnXnRqTuy92D
/bpUZXbHpXc0zZF6Gsp/L2N6i6uKNr42MyjwCgTPpe6hyszv/y5QQVLb6hUN
SSLvorhpEdCBTVzd4kKjCFUqhviVj6tzocLeo4F4AW3xAwAcECVTWab6DoQp
rMuLSaLzsM6/LUCoFg+ZOJa4aaulE5XVIlfVuDEj8IK0oHz26wfH69bSt7d6
Jg5zoH31NiovatGOSUzlAiGfEakNq4Bxta6rCvz+z1zH4m8PGYZnlnANU8Vb
jH40wAYRwYuBdJ6dDF/VAiFxJaEcHDTRmP5Aot/Yd5AlOXQ+pTJqi3MDvpOT
cSWulmPjKZKe8diEn++By2M0FOeySjWPX+FlWD0WdX0e8xG+dn+1IdAywnvm
cr5ygFLS+yRJr2pn4a2te5s7yYmIy0muwoCCn9Pr/c7Z0W1np3ewt70vZtcA
FPVVONz2/UajBDEtggDm1pFKt5kTUW/EpICRgDo1Fq8vzduq0Bq11HgxICl0
KXX/PvWYw5xq6TaXcFWa4gYHeaCLOwU8+C+YG17A6SUAAA==

-->
</rfc>