<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc [
  <!ENTITY nbsp "&#160;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     category="info"
     docName="draft-gaikwad-llm-fault-detection-terminology-00"
     ipr="trust200902"
     submissionType="IETF"
     xml:lang="en"
     version="3">

  <front>
    <title abbrev="Behavior Fault Terminology">
      Benchmarking Terminology for Output Behavior Fault Detection in Large
      Language Model Serving Systems
    </title>

    <seriesInfo name="Internet-Draft"
                value="draft-gaikwad-llm-fault-detection-terminology-00"
                status="informational"/>

    <author fullname="Madhava Gaikwad" initials="M." surname="Gaikwad">
      <organization>Independent</organization>
      <address>
        <email>gaikwad.madhav@gmail.com</email>
      </address>
    </author>

    <date year="2026"/>

    <area>Operations and Management</area>
    <workgroup>Benchmarking Methodology</workgroup>

    <keyword>benchmarking</keyword>
    <keyword>LLM</keyword>
    <keyword>fault detection</keyword>
    <keyword>gray failure</keyword>
    <keyword>observability</keyword>

    <abstract>
      <t>
        This document defines terminology for benchmarking the fault detection
        capability of observability systems that monitor Large Language Model
        (LLM) serving deployments. It defines terms for injectable output
        behavior fault classes, for the detection events and latency intervals
        those faults produce, and for the coverage and accuracy characteristics
        of the detector under test.
      </t>
      <t>
        The System Under Test is the observability system, and not the language
        model. Faults are injected at a known time under controlled conditions,
        which makes detection latency measurable in a way it is not in
        production.
      </t>
      <t>
        This document defines terminology only. A companion document defines the
        corresponding methodology. This document specifies no test procedures,
        no acceptance thresholds, and no service-level objectives.
      </t>
    </abstract>
  </front>

  <middle>

    <section anchor="introduction">
      <name>Introduction</name>
      <t>
        LLM serving deployments are monitored by observability systems that
        report behavioral indicators such as hallucination rate, refusal rate,
        and guardrail activation rate. These systems are widely deployed. Their
        detection capability is not characterized.
      </t>
      <t>
        Operators do not currently know how long their observability system takes
        to raise a behavioral degradation, nor what fraction of degradations it
        raises at all. Both quantities are difficult to obtain from production
        records. A production incident has no independently known start time. The
        moment behavior first departed from intent is inferred after the fact,
        if it is recovered at all.
      </t>
      <t>
        Fault injection removes this difficulty. When a fault is introduced at a
        known time under controlled conditions, the interval from introduction to
        detection is directly measurable. The fraction of injected faults that
        are detected is directly measurable. These are properties of the
        observability system, and this document provides the vocabulary to state
        them.
      </t>
      <t>
        The terms defined here follow the pattern established by
        <xref target="RFC1242"/> and <xref target="RFC8238"/>. Each term is given
        a definition, a discussion, measurement units where applicable, and a
        statement of known issues.
      </t>

      <section anchor="scope">
        <name>Scope</name>
        <t>
          This document defines terminology only. It does not specify test
          procedures, traffic profiles, injection mechanisms, acceptance
          thresholds, or service-level objectives. A companion methodology
          document is intended to specify those. That document does not yet
          exist. Statements in this document that defer a detail to the
          methodology identify work still to be done.
        </t>
        <t>
          The behavioral indicators whose degradation is injected are defined by
          reference. This document does not define hallucination, refusal, or
          policy violation. It defines the fault classes constructed from them
          and the detection characteristics measured against them.
        </t>
        <t>
          Benchmarking activity described by this terminology is confined to a
          test environment. <xref target="security"/> states this requirement.
        </t>
      </section>

      <section anchor="relationship">
        <name>Relationship to Other Work</name>
        <t>
          <xref target="RFC1242"/> and <xref target="RFC2544"/> establish the
          terminology and methodology pattern this document follows.
          <xref target="RFC8238"/> and <xref target="RFC8239"/> apply that pattern
          to data center benchmarking.
        </t>
        <t>
          <xref target="LLM-TERMS"/> defines System Under Test boundaries for LLM
          serving, and <xref target="LLM-METHOD"/> defines the corresponding
          methodology. Those boundaries are reused here to locate the observation
          point of the detector under test.
          <xref target="AI-FABRIC-TERMS"/> defines terminology for the network
          fabric beneath those serving boundaries.
        </t>
        <t>
          <xref target="RFC9940"/> defines terms for network fault and problem
          management. This document adopts its separation between a fault and its
          detection. It applies that separation to behavioral faults in model
          serving.
        </t>
      </section>
    </section>

    <section anchor="conventions">
      <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&nbsp;14 <xref target="RFC2119"/>
        <xref target="RFC8174"/> when, and only when, they appear in all capitals,
        as shown here.
      </t>
    </section>

    <section anchor="architecture">
      <name>Test Architecture Terms</name>

      <section anchor="term-dut">
        <name>Detector Under Test</name>
        <dl newline="true" spacing="normal">
          <dt>Definition:</dt>
          <dd>
            The observability system whose fault detection capability is
            characterized by a benchmark using this terminology.
          </dd>
          <dt>Discussion:</dt>
          <dd>
            The Detector Under Test (DUT) comprises the classifiers, judges,
            heuristics, sampling logic, aggregation, alerting rules, and
            thresholds that together determine whether a behavioral degradation
            is raised. The language model is not under test. The model and its
            serving stack form part of the test environment, and their
            configuration is held constant across trials.
          </dd>
          <dt>Issues:</dt>
          <dd>
            Where the DUT includes a language model as a judge, that model is
            part of the DUT and its version is reported as DUT configuration.
          </dd>
          <dt>See Also:</dt>
          <dd>Observation Point; Behavior Fault.</dd>
        </dl>
      </section>

      <section anchor="term-obs-point">
        <name>Observation Point</name>
        <dl newline="true" spacing="normal">
          <dt>Definition:</dt>
          <dd>
            The boundary within the serving deployment at which the Detector
            Under Test samples requests and responses.
          </dd>
          <dt>Discussion:</dt>
          <dd>
            The available boundaries are the Model Engine, the Application
            Gateway, and the Compound System, as defined in
            <xref target="LLM-TERMS"/>. A detector observing at the Application
            Gateway sees responses after output filtering. A detector observing
            at the Model Engine sees them before. The same injected fault may be
            visible at one boundary and masked at another.
          </dd>
          <dt>Issues:</dt>
          <dd>
            A benchmark result is valid only for the Observation Point at which
            it was obtained. Results obtained at different Observation Points
            <bcp14>MUST NOT</bcp14> be compared.
          </dd>
          <dt>See Also:</dt>
          <dd>Detector Under Test; Fault Injection Point.</dd>
        </dl>
      </section>

      <section anchor="term-inject-point">
        <name>Fault Injection Point</name>
        <dl newline="true" spacing="normal">
          <dt>Definition:</dt>
          <dd>
            The location within the test environment at which an Behavior Fault
            is introduced.
          </dd>
          <dt>Discussion:</dt>
          <dd>
            Injection may occur upstream or downstream of the Observation Point.
            An injection point downstream of the Observation Point produces a
            fault the detector cannot observe, which is a valid configuration for
            characterizing detection blind spots. The relative order of the
            Fault Injection Point and the Observation Point is reported with
            every result.
          </dd>
          <dt>See Also:</dt>
          <dd>Observation Point; Behavior Fault.</dd>
        </dl>
      </section>
    </section>

    <section anchor="faults">
      <name>Fault Terms</name>

      <section anchor="term-fault">
        <name>Behavior Fault</name>
        <dl newline="true" spacing="normal">
          <dt>Definition:</dt>
          <dd>
            A controlled, reversible change to the behavior of a serving
            deployment that shifts one or more behavioral indicators away from
            their baseline distribution, introduced for the purpose of
            characterizing a Detector Under Test.
          </dd>
          <dt>Discussion:</dt>
          <dd>
            An Behavior Fault is defined by the indicator it shifts, the
            magnitude of the shift, and the fault profile through which the shift
            is applied. A fault is not defined by its cause. Two faults that
            produce the same indicator shift are equivalent for benchmarking
            purposes regardless of the mechanism used to produce them.
          </dd>
          <dt>Measurement Units:</dt>
          <dd>
            Magnitude is expressed in the units of the affected indicator. For
            rate-valued indicators, magnitude is expressed as an absolute change
            in the rate.
          </dd>
          <dt>Issues:</dt>
          <dd>
            A fault of sufficiently small magnitude is indistinguishable from
            baseline variation. Reported results state the baseline variability
            of the affected indicator so that the magnitude can be interpreted.
          </dd>
          <dt>See Also:</dt>
          <dd>Fault Profile; Fault Class; Baseline Interval.</dd>
        </dl>
      </section>

      <section anchor="term-fault-class">
        <name>Fault Class</name>
        <dl newline="true" spacing="normal">
          <dt>Definition:</dt>
          <dd>
            A category of Behavior Fault distinguished by the behavioral
            indicator it shifts.
          </dd>
          <dt>Discussion:</dt>
          <dd>
            <t>
              The following classes are defined for use with this terminology.
              The list is extensible.
            </t>
            <ul>
              <li>Refusal Shift: a change in the fraction of requests declined.</li>
              <li>Groundedness Degradation: a change in the fraction of responses
                  unsupported by provided context.</li>
              <li>Policy Filter Degradation: a change in the fraction of
                  responses that violate a declared policy and are emitted.</li>
              <li>Version-Scoped Degradation: any of the above applied to one
                  model version while sibling versions on the same deployment
                  remain at baseline.</li>
            </ul>
          </dd>
          <dt>Issues:</dt>
          <dd>
            Detection characteristics are not comparable across Fault Classes. A
            detector may be fast on Refusal Shift and blind to Groundedness
            Degradation. Results are reported per class.
          </dd>
          <dt>See Also:</dt>
          <dd>Behavior Fault; Consistency Degradation.</dd>
        </dl>
      </section>

      <section anchor="term-consistency">
        <name>Consistency Degradation</name>
        <dl newline="true" spacing="normal">
          <dt>Definition:</dt>
          <dd>
            A change in the dissimilarity between responses to identical requests
            issued under identical configuration.
          </dd>
          <dt>Discussion:</dt>
          <dd>
            Consistency Degradation is noted separately from the Fault Classes of
            <xref target="term-fault-class"/> because it is produced differently.
            The other classes shift an indicator computed over independent
            requests. Consistency is computed over repeated requests, and
            injecting a shift in it requires perturbing the sampling
            configuration of the serving deployment. That perturbation is a
            configuration change and not a behavioral fault in the same sense.
            A benchmark using this terminology <bcp14>MAY</bcp14> include
            Consistency Degradation, and results for it are reported separately
            from the Fault Classes.
          </dd>
          <dt>Measurement Units:</dt>
          <dd>
            The units of the declared dissimilarity measure.
          </dd>
          <dt>Issues:</dt>
          <dd>
            A serving deployment configured for deterministic decoding has no
            baseline consistency variation, and Consistency Degradation is not
            applicable to it.
          </dd>
          <dt>See Also:</dt>
          <dd>Fault Class.</dd>
        </dl>
      </section>

      <section anchor="term-profile">
        <name>Fault Profile</name>
        <dl newline="true" spacing="normal">
          <dt>Definition:</dt>
          <dd>
            The function describing how the magnitude of an Behavior Fault
            varies over the duration of its application.
          </dd>
          <dt>Discussion:</dt>
          <dd>
            Three profiles are defined. A Step profile applies the full magnitude
            at the Fault Onset and holds it. A Ramp profile increases magnitude
            linearly from zero over a stated interval. An Intermittent profile
            alternates between full magnitude and baseline at a stated duty cycle
            and period.
          </dd>
          <dt>Measurement Units:</dt>
          <dd>
            Ramp interval and Intermittent period are expressed in seconds. Duty
            cycle is expressed as a fraction.
          </dd>
          <dt>Issues:</dt>
          <dd>
            Detection Latency is defined relative to Fault Onset for all
            profiles. For Ramp and Intermittent profiles the detector may
            reasonably raise the fault well after onset, since the fault is not
            at full magnitude at that time. Results for these profiles are
            interpreted with the profile parameters.
          </dd>
          <dt>See Also:</dt>
          <dd>Fault Onset; Detection Latency.</dd>
        </dl>
      </section>
    </section>

    <section anchor="events">
      <name>Event Terms</name>

      <section anchor="term-onset">
        <name>Fault Onset</name>
        <dl newline="true" spacing="normal">
          <dt>Definition:</dt>
          <dd>
            The time at which an Behavior Fault begins to be applied at the
            Fault Injection Point.
          </dd>
          <dt>Discussion:</dt>
          <dd>
            Fault Onset is known by construction. It is recorded by the injection
            apparatus and is not inferred from detector output. This is the
            property that distinguishes a benchmark from an observation of a
            production incident.
          </dd>
          <dt>Measurement Units:</dt>
          <dd>
            A timestamp with resolution of one millisecond or finer.
          </dd>
          <dt>Issues:</dt>
          <dd>
            The injection apparatus and the Detector Under Test may run on
            different hosts. Clock synchronization requirements are stated in the
            companion methodology. Reported Detection Latency values are valid
            only to the accuracy of that synchronization.
          </dd>
          <dt>See Also:</dt>
          <dd>Detection Event; Detection Latency.</dd>
        </dl>
      </section>

      <section anchor="term-detection">
        <name>Detection Event</name>
        <dl newline="true" spacing="normal">
          <dt>Definition:</dt>
          <dd>
            The time at which the Detector Under Test emits a signal attributable
            to an applied Behavior Fault.
          </dd>
          <dt>Discussion:</dt>
          <dd>
            The signal may be an alert, a threshold crossing, a state change, or
            a log record, according to the DUT configuration. The form of signal
            that constitutes a Detection Event is declared before the trial
            begins. Changing it after observing results invalidates the trial.
          </dd>
          <dt>Measurement Units:</dt>
          <dd>
            A timestamp with resolution of one millisecond or finer.
          </dd>
          <dt>Issues:</dt>
          <dd>
            Attribution of a signal to a specific applied fault requires that
            only one fault be applied at a time, or that the signal carry
            sufficient information to identify the affected indicator. The
            companion methodology states the requirement.
          </dd>
          <dt>See Also:</dt>
          <dd>Fault Onset; False Detection.</dd>
        </dl>
      </section>

      <section anchor="term-false">
        <name>False Detection</name>
        <dl newline="true" spacing="normal">
          <dt>Definition:</dt>
          <dd>
            A signal emitted by the Detector Under Test during a Baseline
            Interval, in which no Behavior Fault is applied.
          </dd>
          <dt>Discussion:</dt>
          <dd>
            False Detection is measured over Baseline Intervals of stated
            duration under stated traffic. A detector can achieve arbitrarily low
            Detection Latency by lowering its thresholds, at the cost of False
            Detection Rate. The two are reported together.
          </dd>
          <dt>Measurement Units:</dt>
          <dd>
            Count per unit time, with the interval duration and traffic profile
            stated.
          </dd>
          <dt>See Also:</dt>
          <dd>Baseline Interval; Detection Latency.</dd>
        </dl>
      </section>

      <section anchor="term-baseline">
        <name>Baseline Interval</name>
        <dl newline="true" spacing="normal">
          <dt>Definition:</dt>
          <dd>
            A period during which traffic is offered to the serving deployment
            and no Behavior Fault is applied.
          </dd>
          <dt>Discussion:</dt>
          <dd>
            Baseline Intervals serve two purposes. They establish the baseline
            distribution of each affected indicator, against which fault
            magnitude is expressed. They provide the observation period for False
            Detection.
          </dd>
          <dt>Measurement Units:</dt>
          <dd>Seconds.</dd>
          <dt>Issues:</dt>
          <dd>
            A Baseline Interval that is short relative to the DUT aggregation
            window does not establish a stable baseline. The companion
            methodology states a minimum.
          </dd>
          <dt>See Also:</dt>
          <dd>False Detection; Behavior Fault.</dd>
        </dl>
      </section>
    </section>

    <section anchor="metrics">
      <name>Detection Characteristic Terms</name>

      <section anchor="term-latency">
        <name>Detection Latency</name>
        <dl newline="true" spacing="normal">
          <dt>Definition:</dt>
          <dd>
            The interval from Fault Onset to the Detection Event attributable to
            that fault.
          </dd>
          <dt>Discussion:</dt>
          <dd>
            Detection Latency is defined per trial. A trial in which no Detection
            Event occurs before the end of the fault application yields no
            Detection Latency value. Such trials are counted separately and are
            reflected in Detection Coverage.
          </dd>
          <dt>Measurement Units:</dt>
          <dd>Seconds.</dd>
          <dt>Issues:</dt>
          <dd>
            Detection Latency depends on offered load. A detector observing a
            rate indicator requires a number of requests to accumulate evidence,
            and that number takes longer to accumulate at low request rates. A
            reported value is valid only for the offered load at which it was
            obtained. Results are reported across a range of loads.
          </dd>
          <dt>See Also:</dt>
          <dd>Fault Onset; Detection Event; Detection Coverage.</dd>
        </dl>
      </section>

      <section anchor="term-coverage">
        <name>Detection Coverage</name>
        <dl newline="true" spacing="normal">
          <dt>Definition:</dt>
          <dd>
            The fraction of applied Behavior Faults of a given Fault Class and
            magnitude for which a Detection Event occurred.
          </dd>
          <dt>Discussion:</dt>
          <dd>
            Detection Coverage is measurable in a benchmark because the number of
            applied faults is known. It is not measurable from production
            records, where undetected faults leave no trace. Detection Coverage
            is the term that gives a Detection Latency figure its meaning. A
            detector that raises one fault in ten may report a low mean Detection
            Latency across the faults it raises.
          </dd>
          <dt>Measurement Units:</dt>
          <dd>A fraction between zero and one.</dd>
          <dt>Issues:</dt>
          <dd>
            Detection Coverage is a function of fault magnitude. A coverage
            figure reported without the magnitude at which it was obtained is not
            interpretable. Results are reported as coverage against magnitude.
          </dd>
          <dt>See Also:</dt>
          <dd>Detection Latency; False Detection.</dd>
        </dl>
      </section>

      <section anchor="term-threshold">
        <name>Detection Threshold Magnitude</name>
        <dl newline="true" spacing="normal">
          <dt>Definition:</dt>
          <dd>
            The smallest fault magnitude of a given Fault Class at which the
            Detector Under Test achieves a stated Detection Coverage.
          </dd>
          <dt>Discussion:</dt>
          <dd>
            This term characterizes detector sensitivity. It is obtained by
            repeating trials at decreasing magnitude until coverage falls below
            the stated level. The coverage level used <bcp14>MUST</bcp14> be
            reported with the value.
          </dd>
          <dt>Measurement Units:</dt>
          <dd>The units of the affected indicator.</dd>
          <dt>Issues:</dt>
          <dd>
            Detection Threshold Magnitude approaches the baseline variability of
            the affected indicator as a lower bound. A reported value at or below
            baseline variability indicates that the trial was not correctly
            configured.
          </dd>
          <dt>See Also:</dt>
          <dd>Detection Coverage; Baseline Interval.</dd>
        </dl>
      </section>

      <section anchor="term-masking">
        <name>Boundary Masking</name>
        <dl newline="true" spacing="normal">
          <dt>Definition:</dt>
          <dd>
            The reduction in observed fault magnitude between the Fault Injection
            Point and the Observation Point.
          </dd>
          <dt>Discussion:</dt>
          <dd>
            A fault injected at the Model Engine may be partly or wholly
            suppressed by output filtering before it reaches an Application
            Gateway Observation Point. Boundary Masking quantifies that
            suppression. A masking value near one indicates that the intervening
            components absorb the fault, and that detection at the Observation
            Point characterizes those components as much as the detector.
          </dd>
          <dt>Measurement Units:</dt>
          <dd>A fraction between zero and one.</dd>
          <dt>See Also:</dt>
          <dd>Observation Point; Fault Injection Point.</dd>
        </dl>
      </section>
    </section>

    <section anchor="security">
      <name>Security Considerations</name>
      <t>
        Benchmarking activity described by this terminology is confined to a
        laboratory test environment. The faults defined here deliberately degrade
        the behavioral safety properties of a serving deployment. Applying them
        to a deployment serving production traffic exposes users to unsafe,
        ungrounded, or incorrectly refused responses.
      </t>
      <t>
        Test environments <bcp14>MUST</bcp14> be isolated from production
        traffic. Fault injection mechanisms <bcp14>MUST NOT</bcp14> be reachable
        from a production control plane. The reasoning of
        <xref target="RFC6815"/> applies to this document.
      </t>
      <t>
        Benchmark results characterize where a detector is insensitive. A
        published Detection Threshold Magnitude states the degradation an
        operator would not observe. Publishers <bcp14>SHOULD</bcp14> consider
        this when selecting a disclosure audience.
      </t>
    </section>

    <section anchor="iana">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>

  </middle>

  <back>
    <references>
      <name>Normative References</name>

      <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner"/>
          <date year="1997" month="March"/>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
      </reference>

      <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author fullname="B. Leiba" initials="B." surname="Leiba"/>
          <date year="2017" month="May"/>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
      </reference>

      <reference anchor="RFC1242" target="https://www.rfc-editor.org/info/rfc1242">
        <front>
          <title>Benchmarking Terminology for Network Interconnection
                 Devices</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner"/>
          <date year="1991" month="July"/>
        </front>
        <seriesInfo name="RFC" value="1242"/>
      </reference>

      <reference anchor="LLM-TERMS">
        <front>
          <title>Benchmarking Terminology for Large Language Model Serving</title>
          <author fullname="Madhava Gaikwad" initials="M." surname="Gaikwad"/>
          <date year="2026"/>
        </front>
        <seriesInfo name="Internet-Draft"
                    value="draft-gaikwad-llm-benchmarking-terminology"/>
      </reference>
    </references>

    <references>
      <name>Informative References</name>

      <reference anchor="RFC2544" target="https://www.rfc-editor.org/info/rfc2544">
        <front>
          <title>Benchmarking Methodology for Network Interconnect
                 Devices</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner"/>
          <author fullname="J. McQuaid" initials="J." surname="McQuaid"/>
          <date year="1999" month="March"/>
        </front>
        <seriesInfo name="RFC" value="2544"/>
      </reference>

      <reference anchor="RFC6815" target="https://www.rfc-editor.org/info/rfc6815">
        <front>
          <title>Applicability Statement for RFC 2544: Use on Production
                 Networks Considered Harmful</title>
          <author fullname="S. Bradner" initials="S." surname="Bradner"/>
          <author fullname="K. Dubray" initials="K." surname="Dubray"/>
          <author fullname="J. McQuaid" initials="J." surname="McQuaid"/>
          <author fullname="A. Morton" initials="A." surname="Morton"/>
          <date year="2012" month="November"/>
        </front>
        <seriesInfo name="RFC" value="6815"/>
      </reference>

      <reference anchor="RFC8238" target="https://www.rfc-editor.org/info/rfc8238">
        <front>
          <title>Data Center Benchmarking Terminology</title>
          <author fullname="L. Avramov" initials="L." surname="Avramov"/>
          <author fullname="J. Rapp" initials="J." surname="Rapp"/>
          <date year="2017" month="August"/>
        </front>
        <seriesInfo name="RFC" value="8238"/>
      </reference>

      <reference anchor="RFC8239" target="https://www.rfc-editor.org/info/rfc8239">
        <front>
          <title>Data Center Benchmarking Methodology</title>
          <author fullname="L. Avramov" initials="L." surname="Avramov"/>
          <author fullname="J. Rapp" initials="J." surname="Rapp"/>
          <date year="2017" month="August"/>
        </front>
        <seriesInfo name="RFC" value="8239"/>
      </reference>

      <reference anchor="RFC9940" target="https://www.rfc-editor.org/info/rfc9940">
        <front>
          <title>Some Key Terms for Network Fault and Problem Management</title>
          <author fullname="N. Davis" initials="N." surname="Davis" role="editor"/>
          <author fullname="A. Farrel" initials="A." surname="Farrel" role="editor"/>
          <date year="2026" month="April"/>
        </front>
        <seriesInfo name="RFC" value="9940"/>
      </reference>

      <reference anchor="AI-FABRIC-TERMS">
        <front>
          <title>Benchmarking Terminology for AI Network Fabrics</title>
          <author fullname="F. Calabria" initials="F." surname="Calabria"/>
          <author fullname="C. Pignataro" initials="C." surname="Pignataro"/>
          <author fullname="Q. Wu" initials="Q." surname="Wu"/>
          <author fullname="G. Fioccola" initials="G." surname="Fioccola"/>
          <date year="2026" month="April"/>
        </front>
        <seriesInfo name="Internet-Draft"
                    value="draft-calabria-bmwg-ai-fabric-terminology"/>
      </reference>

      <reference anchor="LLM-METHOD">
        <front>
          <title>Benchmarking Methodology for Large Language Model Serving</title>
          <author fullname="Madhava Gaikwad" initials="M." surname="Gaikwad"/>
          <date year="2026"/>
        </front>
        <seriesInfo name="Internet-Draft"
                    value="draft-gaikwad-llm-benchmarking-methodology"/>
      </reference>
    </references>

    <section anchor="acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>
        This document follows the terminology structure established by
        <xref target="RFC1242"/> and applied to data center benchmarking in
        <xref target="RFC8238"/>. The author thanks the Benchmarking Methodology
        Working Group for that foundation.
      </t>
    </section>

  </back>
</rfc>
