<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-mornuley-ippm-initial-registry-01"
     ipr="trust200902">
  <front>
    <title abbrev="Initial Registry">Initial Performance Metric Registry
    Entries</title>

    <author fullname="Al Morton" initials="A." surname="Morton">
      <organization>AT&amp;T Labs</organization>

      <address>
        <postal>
          <street>200 Laurel Avenue South</street>

          <city>Middletown,</city>

          <region>NJ</region>

          <code>07748</code>

          <country>USA</country>
        </postal>

        <phone>+1 732 420 1571</phone>

        <facsimile>+1 732 368 1192</facsimile>

        <email>acmorton@att.com</email>

        <uri>http://home.comcast.net/~acmacm/</uri>
      </address>
    </author>

    <author fullname="Marcelo Bagnulo" initials="M." surname="Bagnulo">
      <organization abbrev="UC3M">Universidad Carlos III de
      Madrid</organization>

      <address>
        <postal>
          <street>Av. Universidad 30</street>

          <city>Leganes</city>

          <region>Madrid</region>

          <code>28911</code>

          <country>SPAIN</country>
        </postal>

        <phone>34 91 6249500</phone>

        <email>marcelo@it.uc3m.es</email>

        <uri>http://www.it.uc3m.es</uri>
      </address>
    </author>

    <author fullname="Philip Eardley" initials="P." surname="Eardley">
      <organization abbrev="BT">BT</organization>

      <address>
        <postal>
          <street>Adastral Park, Martlesham Heath</street>

          <city>Ipswich</city>

          <country>ENGLAND</country>
        </postal>

        <email>philip.eardley@bt.com</email>
      </address>
    </author>

    <date day="9" month="March" year="2015"/>

    <abstract>
      <t>This memo defines the Initial Entries for the Performance Metrics
      Registry.</t>
    </abstract>

    <note title="Requirements Language">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>

      <t/>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>Note: Efforts to synchronize structure and terminology with <xref
      target="I-D.ietf-ippm-metric-registry"/> will likely be incomplete until
      both drafts are stable.</t>

      <t>This memo defines the Initial set of entries for the Performance
      Metric Registry. The registry will contain Active Performance Metrics,
      especially those defined in RFCs prepared in the IP Performance Metrics
      (IPPM) Working Group of the IETF, according to their framework <xref
      target="RFC2330"/>. Three aspects make IPPM metric registration
      difficult: (1) Use of the Type-P notion to allow users to specify their
      own packet types. (2) Use of Flexible input variables, called Parameters
      in IPPM definitions, some which determine the quantity measured and
      others which should not be specified until execution of the measurement.
      (3) Allowing flexibility in choice of statistics to summarize the
      results on a stream of measurement packets. This memo uses terms and
      definitions from the IPPM literature, primarily <xref
      target="RFC2330"/>, and the reader is assumed familiar with them or may
      refer questions there as necessary.</t>

      <t>Although there are several standard templates for organizing
      specifications of performance metrics (see <xref target="RFC2679"/> for
      an example of the traditional IPPM template, based to large extent on
      the Benchmarking Methodology Working Group's traditional template in
      <xref target="RFC1242"/>, and see <xref target="RFC6390"/> for a similar
      template), none of these templates were intended to become the basis for
      the columns of an IETF-wide registry of metrics. As we examined the
      aspects of metric specifications which need to be registered, it was
      clear that none of the existing metric templates fully satisfies the
      particular needs of a registry.</t>
    </section>

    <section title="Scope">
      <t><xref target="I-D.ietf-ippm-metric-registry"/> defines the overall
      structure for a Performance Metric Registry and provides guidance for
      the process to examine proposed metrics and maitain Registered
      Metrics.</t>

      <t>This document defines the initial set of Performance Metrics Registry
      entries; all are active metrics, or those where the packets measured
      have been specially generated for the purpose.</t>

      <t>A row in the registry corresponds to one Registered Performance
      Metric, with entries in the various columns specifying the metric.</t>

      <t>As discussed in <xref target="I-D.ietf-ippm-metric-registry"/>, each
      entry (row) must be tightly defined; the definition must leave open only
      a few parameters that do not change the fundamental nature of the
      measurement (such as source and destination addresses), and so promotes
      comparable results across independent implementations. Also, each
      registered entry must be based on existing reference RFCs (or other
      standards) for performance metrics, and must be operationally useful and
      have significant industry interest. This is ensured by expert review for
      every entry before IANA action.</t>
    </section>

    <section title="Registry Categories and Columns">
      <t>This section defines the categories and columns of the registry.
      Below, categories are described at the 3.x heading level, and columns
      are at the 3.x.y heading level. The Figure below illustrates this
      organization. An entry (row) therefore gives a complete description of a
      Registered Metric.</t>

      <t>Each column serves as a check-list item and helps to avoid omissions
      during registration and expert review. In some cases an entry (row) may
      have some columns without specific entries, marked Not Applicable (NA).
      <figure>
          <artwork><![CDATA[THIS NEEDS UPDATING

Registry Categories and Columns, shown as
                                                Category
                                                ------------------
                                                Column |  Column |

Comments and Remarks
--------------------


]]></artwork>
        </figure></t>
    </section>

    <section title="UDP Round-trip Latency Registry Entry">
      <t>This section gives an initial registry entry for the UDP Round-trip
      Latency.</t>

      <t>Note: If each Registry entry should only produce a "raw" output or a
      statistical summary, then the "Output" Category can be split and this
      section can become two closely-related metrics.</t>

      <section title="Summary">
        <t>This category includes multiple indexes to the registry entries,
        the element ID and metric name.</t>

        <section title="ID (Identifier)">
          <t>&lt;insert numeric identifier, an integer&gt;</t>
        </section>

        <section title="Name">
          <t>&lt;insert name according to metric naming convention&gt;</t>

          <t>Act_IP_UDP_Round-trip_Delay_Raw_95th-percentile_Poisson</t>

          <t>URL: ??</t>
        </section>

        <section title="URI">
          <t>URI: Prefix urn:ietf:params:performance:metric...&lt;name&gt;</t>
        </section>

        <section title="Description">
          <t>This metric assesses the delay of a stream of packets exchanged
          between two hosts (or measurement points), and reports the
          Round-trip delay for all successfully exchanged packets and the 95th
          percentile of their conditional delay distribution.</t>
        </section>
      </section>

      <section title="Metric Definition">
        <t>This category includes columns to prompt the entry of all necessary
        details related to the metric definition, including the RFC reference
        and values of input factors, called fixed parameters.</t>

        <section title="Reference Definition">
          <t>&lt;Full bibliographic reference to an immutable doc.&gt;</t>

          <t>Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
          Metric for IPPM", RFC 2681, September 1999.</t>

          <t><xref target="RFC2681"/></t>

          <t>&lt;specific section reference and additional clarifications, if
          needed&gt;</t>

          <t>Section 2.4 of <xref target="RFC2681"/> provides the reference
          definition of the singleton (single value) Round-trip delay metric.
          Section 3.4 of <xref target="RFC2681"/> provides the reference
          definition expanded to cover a multi-value sample. Note that terms
          such as singleton and sample are defined in Section 11 of <xref
          target="RFC2330"/>.</t>

          <t>Note that although the definition of "Round-trip-Delay between
          Src and Dst at T" is directionally ambiguous in the text, this
          metric tightens the definition further to recognize that the host in
          the "Src" role will send the first packet to "Dst", and ultimately
          receive the corresponding return packet from "Dst" (when neither are
          lost).</t>
        </section>

        <section title="Fixed Parameters">
          <t>&lt;list and specify Fixed Parameters, input factors that must be
          determined and embedded in the measurement system for use when
          needed&gt;</t>

          <t>Type-P: <list style="symbols">
              <t>IPv4 header values: <list style="symbols">
                  <t>DSCP: set to 0</t>

                  <t>TTL set to 255</t>

                  <t>Protocol: Set to 17 (UDP)</t>
                </list></t>

              <t>UDP header values: <list style="symbols">
                  <t>Checksum: the checksum must be calculated</t>
                </list></t>

              <t>Payload <list style="symbols">
                  <t>Sequence number: 8-byte integer</t>

                  <t>Timestamp: 8 byte integer. Expressed as 64-bit NTP
                  timestamp as per section 6 of <xref target="RFC5905">RFC
                  5905</xref></t>

                  <t>No padding (total of 9 bytes)</t>
                </list></t>
            </list></t>

          <t>Timeout, Tmax: 3 seconds</t>
        </section>
      </section>

      <section title="Method of Measurement">
        <t>This category includes columns for references to relevant sections
        of the RFC(s) and any supplemental information needed to ensure an
        unambiguous methods for implementations.</t>

        <section title="Reference Method">
          <t>&lt;for metric, insert relevant section references and
          supplemental info&gt;</t>

          <t>The methodology for this metric is defined as
          Type-P-Round-trip-Delay-Poisson-Stream in section 2.6 of <xref
          target="RFC2681">RFC 2681</xref> and section 3.6 of <xref
          target="RFC2681">RFC 2681</xref> using the Type-P and Timeout
          defined under Fixed Parameters.</t>

          <t>The method requires sequence numbers or other send-order
          information to be retained at the Src or included with each packet
          to dis-ambiguate packet reordering if it occurs. Sequence number is
          part of the payload described under Fixed Parameters.</t>

          <t>Refer to Section 4.4 of <xref target="RFC6673"/> for expanded
          discussion of the instruction to "send a Type-P packet back to the
          Src as quickly as possible" in Section 2.6 of <xref
          target="RFC2681">RFC 2681</xref>. Section 8 of <xref
          target="RFC6673"/> presents additional requirements which shall be
          included in the method of measurement for this metric.</t>
        </section>

        <section title="Packet Generation Stream">
          <t>This section gives the details of the packet traffic which is the
          basis for measurement. In IPPM metrics, this is called the Stream,
          and can easily be dscribed by providing the list of stream
          parameters.</t>

          <t>&lt;list of generation parameters and section/spec references if
          needed&gt;</t>

          <t>Section 11.1.3 of <xref target="RFC2330">RFC 2681</xref> provides
          three methods to generate Poisson sampling intervals. the reciprocal
          of lambda is the average packet rate, thus the Run-time Parameter is
          1/lambda.</t>

          <t>&gt;&gt;&gt; Check with Sam, most likely it is this...</t>

          <t>Method 3 is used, where given a start time (Run-time Parameter),
          the subsequent send times are all computed prior to measurement by
          computing the pseudo-random distribution of inter-packet send times,
          (truncating the distribution as specified in the Run-time
          Parameters), and the Src sends each packet at the computed
          times.</t>
        </section>

        <section title="Traffic Filtering (observation) Details">
          <t>The measured results based on a filtered version of the packets
          observed, and this section provides the filter details (when
          present).</t>

          <t>&lt;section reference&gt;.</t>

          <t>NA</t>
        </section>

        <section title="Sampling Distribution">
          <t>&lt;insert time distribution details, or how this is diff from
          the filter&gt;</t>

          <t>NA</t>
        </section>

        <section title="Run-time Parameters and Data Format">
          <t>Run-time Parameters are input factors that must be determined,
          configured into the measurement system, and reported with the
          results for the context to be complete.</t>

          <t>&lt;list of run-time parameters, and their data formats&gt;</t>

          <t><list style="symbols">
              <t>Src, the IP address of a host (32-bit value for IPv4, 128-bit
              value for IPv6)</t>

              <t>Dst, the IP address of a host (32-bit value for IPv4, 128-bit
              value for IPv6)</t>

              <t>T0, a time (start of measurement interval, 128-bit NTP Date
              Format, see section 6 of <xref target="RFC5905"/>). When T0 is
              "all-zeros", a start time is unspecified and Tf is to be
              interpreted as the Duration of the measurement interval.</t>

              <t>Tf, a time (end of measurement interval, 128-bit NTP Date
              Format, see section 6 of <xref target="RFC5905"/>), interpreted
              as the Duration of the measurement interval.</t>

              <t>1/lambda, average packet rate (for Poisson Streams).
              (1/lambda = 1 packet per second, if fixed)</t>

              <t>Upper limit on Poisson distribution (values above this limit
              will be clipped and set to the limit value). (if fixed, Upper
              limit = 30 seconds.)</t>
            </list>The format for 1/lambda and Upper limit of Poisson Dist.
          are the short format in <xref target="RFC5905"/> (32 bits) and is as
          follows: the first 16 bits represent the integer number of seconds;
          the next 16 bits represent the fractional part of a second.</t>

          <t>&gt;&gt;&gt; should Poisson run-time params be fixed instead?
          probably yes if modeling a specific version of MBA tests.</t>
        </section>

        <section title="Roles">
          <t>&lt;lists the names of the different roles from the measurement
          method&gt;</t>

          <t>Src - launches each packet and waits for return transmissions
          from Dst.</t>

          <t>Dst - waits for each packet from Src and sends a return packet to
          Src.</t>
        </section>
      </section>

      <section title="Output">
        <t>This category specifies all details of the Output of measurements
        using the metric.</t>

        <section title="Type/Value (two diff terms used)">
          <t>&lt;insert name of the output type, raw or a selected summary
          statistic&gt;</t>

          <t>Raw -- for each packet sent, pairs of values.</t>

          <t>Percentile -- for the conditional distribution of all packets
          with a valid value of Round-trip delay (undefined delays are
          excluded), a single value corresponding to the 95th percentile.</t>
        </section>

        <section title="Data Format">
          <t>&lt;describe the data format for each type of result&gt;</t>

          <t>For all outputs ---</t>

          <t><list style="symbols">
              <t>T0, a time (start of measurement interval, 128-bit NTP Date
              Format, see section 6 of <xref target="RFC5905"/>)</t>

              <t>Tf, a time (end of measurement interval, 128-bit NTP Date
              Format, see section 6 of <xref target="RFC5905"/>)</t>
            </list></t>

          <t>Raw -- for each packet sent, pairs of values as follows:</t>

          <t><list style="symbols">
              <t>T, the time when the packet was sent from Src, 128-bit NTP
              Date Format, see section 6 of <xref target="RFC5905"/>)</t>

              <t>dT, a value of Round-trip delay, format is *similar to* the
              32-bit short NTP Time format in Section 6 of <xref
              target="RFC5905"/> and is as follows: the first 16 bits
              represent the *signed* integer number of seconds; the next 16
              bits represent the fractional part of a second.</t>

              <t>dT is undefined when the packet is not received at Src in
              waiting time Tmxax seconds (need undefined code)</t>
            </list></t>

          <t>Percentile -- for the conditional distribution of all packets
          with a valid value of Round-trip delay (undefined delays are
          excluded), a single value as follows:</t>

          <t>See section 4.1 of <xref target="RFC3393"/> for details on the
          conditional distribution to exclude undefined values of delay, and
          Section 5 of <xref target="RFC6703"/> for background on this
          analysis choice.</t>

          <t>See section 4.3 of <xref target="RFC3393"/> for details on the
          percentile statistic (where Round-trip delay should be substituted
          for "ipdv").</t>

          <t>The percentile = 95.</t>

          <t>Data format is a 32-bit signed value, *similar to* the 32-bit
          short NTP Time format in Section 6 of <xref target="RFC5905"/> and
          is as follows: the first 16 bits represent the *signed* integer
          number of seconds; the next 16 bits represent the fractional part of
          a second.</t>
        </section>

        <section title="Reference">
          <t>&lt;pointer to section/spec where output type/format is
          defined&gt;</t>

          <t>See the Data Format column for references.</t>
        </section>

        <section title="Metric Units">
          <t>&lt;insert units for the measured results, and the reference
          specification&gt;.</t>

          <t>Round-trip Delay, dT, is expressed in seconds.</t>

          <t>The 95th Percentile of Round-trip Delay is expressed in
          seconds.</t>
        </section>
      </section>

      <section title="Administrative items">
        <t/>

        <section title="Status">
          <t>&lt;current or depricated&gt;</t>
        </section>

        <section title="Requestor (keep?)">
          <t>name or RFC, etc.</t>
        </section>

        <section title="Revision">
          <t>1.0</t>
        </section>

        <section title="Revision Date">
          <t>YYYY-MM-DD</t>
        </section>
      </section>

      <section title="Comments and Remarks">
        <t>Additional (Informational) details for this entry</t>
      </section>
    </section>

    <section title="Packet Delay Variation Registry Entry">
      <t>This section gives an initial registry entry for a Packet Delay
      Variation metric.</t>

      <t>Note: If each Registry entry should only produce a "raw" output or a
      statistical summary, then the "Output" Category can be split and this
      section can become two closely-related metrics.</t>

      <section title="Summary">
        <t>This category includes multiple indexes to the registry entries,
        the element ID and metric name.</t>

        <t>&lt;skipping some Summary columns for now&gt;</t>

        <section title="ID (Identifier)">
          <t>&lt;insert numeric identifier, an integer&gt;</t>
        </section>

        <section title="Name">
          <t>&lt;insert name according to metric naming convention&gt;</t>

          <t>Act_IP-UDP-One-way-pdv-95th-percentile-Poisson</t>

          <t>URL: ??</t>
        </section>

        <section title="URI">
          <t>URI: Prefix urn:ietf:params:performance:metric&lt;add
          name&gt;</t>
        </section>

        <section title="Description">
          <t>An assessment of packet delay variation with respect to the
          minimum delay observed on the stream.</t>
        </section>
      </section>

      <section title="Metric Definition">
        <t>This category includes columns to prompt the entry of all necessary
        details related to the metric definition, including the RFC reference
        and values of input factors, called fixed parameters.</t>

        <section title="Reference Definition">
          <t>&lt;Full bibliographic reference to an immutable doc.&gt;</t>

          <t>Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for
          IP Performance Metrics", RFC 2330, May 1998. <xref
          target="RFC2330"/></t>

          <t>Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric
          for IP Performance Metrics (IPPM)", RFC 3393, November 2002. <xref
          target="RFC3393"/></t>

          <t>Morton, A. and B. Claise, "Packet Delay Variation Applicability
          Statement", RFC 5481, March 2009. <xref target="RFC5481"/></t>

          <t>Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time
          Protocol Version 4: Protocol and Algorithms Specification", RFC
          5905, June 2010.<xref target="RFC5905"> </xref></t>

          <t>&lt;specific section reference and additional clarifications, if
          needed&gt;</t>

          <t>See sections 2.4 and 3.4 of <xref target="RFC3393"/>. Singleton
          delay differences measured are referred to by the variable name
          "ddT".</t>
        </section>

        <section title="Fixed Parameters">
          <t>&lt;list and specify Fixed Parameters, input factors that must be
          determined and embedded in the measurement system for use when
          needed&gt;</t>

          <t><list style="symbols">
              <t>F, a selection function defining unambiguously the packets
              from the stream selected for the metric. See section 4.2 of
              <xref target="RFC5481"/> for the PDV form.</t>

              <t>L, a packet length in bits. L = 200 bits.</t>

              <t>Tmax, a maximum waiting time for packets to arrive at Dst,
              set sufficiently long to disambiguate packets with long delays
              from packets that are discarded (lost). Tmax = 3 seconds.</t>

              <t>Type-P, as defined in <xref target="RFC2330"/>, which
              includes any field that may affect a packet's treatment as it
              traverses the network. The packets are IP/UDP, with DSCP = 0
              (BE).</t>
            </list></t>
        </section>
      </section>

      <section title="Method of Measurement">
        <t>This category includes columns for references to relevant sections
        of the RFC(s) and any supplemental information needed to ensure an
        unambiguous methods for implementations.</t>

        <section title="Reference Method">
          <t>&lt;for metric, insert relevant section references and
          supplemental info&gt;</t>

          <t>See section 2.6 and 3.6 of <xref target="RFC3393"/> for singleton
          elements.</t>
        </section>

        <section title="Packet Generation Stream">
          <t>&lt;list of generation parameters and section/spec references if
          needed&gt;</t>

          <t>Poisson distributed as described in <xref target="RFC2330"/>,
          with the following Parameters.</t>

          <t><list style="symbols">
              <t>lambda, a rate in reciprocal seconds (for Poisson Streams).
              lambda = 1 packet per second</t>

              <t>Upper limit on Poisson distribution (values above this limit
              will be clipped and set to the limit value). Upper limit = 30
              seconds.</t>
            </list></t>
        </section>

        <section title="Traffic Filtering (observation) Details">
          <t>&lt;insert the measured results based on a filtered version of
          the packets observed, and this section provides the filter details
          (when present), and section reference&gt;.</t>

          <t>NA</t>
        </section>

        <section title="Sampling Distribution">
          <t>&lt;insert time distribution details, or how this is diff from
          the filter&gt;</t>

          <t>NA</t>
        </section>

        <section title="Run-time Parameters and Data Format">
          <t>&lt;list of run-time parameters, and any reference(s)&gt;.</t>

          <t><list style="symbols">
              <t>Src, the IP address of a host (32-bit value for IPv4, 128-bit
              value for IPv6)</t>

              <t>Dst, the IP address of a host (32-bit value for IPv4, 128-bit
              value for IPv6)</t>

              <t>T, a time (start of measurement interval, 128-bit NTP Date
              Format, see section 6 of <xref target="RFC5905"/>). When T0 is
              "all-zeros", a start time is unspecified and Tf is to be
              interpreted as the Duration of the measurement interval.</t>

              <t>Tf, a time (end of measurement interval, 128-bit NTP Date
              Format, see section 6 of <xref target="RFC5905"/>), interpreted
              as the Duration of the measurement interval.</t>
            </list></t>
        </section>

        <section title="Roles">
          <t>&lt;lists the names of the different roles from the measurement
          method&gt;</t>

          <t>Src - the host that sends the stream of packets.</t>

          <t>Dst - the host that receives the stream of packets.</t>
        </section>
      </section>

      <section title="Output">
        <t>This category specifies all details of the Output of measurements
        using the metric.</t>

        <section title="Type/Value (two diff terms used)">
          <t>&lt;insert name of the output type, raw or a selected summary
          statistic&gt;</t>

          <t>Raw -- for each packet sent, pairs of values.</t>

          <t>Percentile -- for the conditional distribution of all packets
          with a valid value of one-way delay (undefined delays are excluded),
          a single value corresponding to the 95th percentile of the
          singletons, ddT.</t>
        </section>

        <section title="Data Format">
          <t>&lt;describe the data format for each type of result&gt;</t>

          <t>For all Output types</t>

          <t><list style="symbols">
              <t>T, a time (start of measurement interval, 128-bit NTP Date
              Format, see section 6 of <xref target="RFC5905"/>)</t>

              <t>Tf, a time (end of measurement interval, 128-bit NTP Date
              Format, see section 6 of <xref target="RFC5905"/>)</t>
            </list></t>

          <t>Raw -</t>

          <t><list style="symbols">
              <t>T1, the wire time of the first packet in a pair, measured at
              MP(Src) as it leaves for Dst (64-bit NTP Timestamp Format, see
              section 6 of <xref target="RFC5905"/>).</t>

              <t>T2, the wire time of the second packet in a pair, measured at
              MP(Src) as it leaves for Dst (64-bit NTP Timestamp Format, see
              section 6 of <xref target="RFC5905"/>).</t>

              <t>I(i),I(i+1), i &gt;=0, pairs of times which mark the
              beginning and ending of the intervals in which the packet stream
              from which the measurement is taken occurs. Here, I(0) = T0 and
              assuming that n is the largest index, I(n) = Tf (pairs of 64-bit
              NTP Timestamp Format, see section 6 of <xref
              target="RFC5905"/>).</t>

              <t>When the one-way delay of a packet in the calculation pair
              for ddT is undefined, then ddT is undefined for that pair.</t>
            </list></t>

          <t>Percentile -- for the conditional distribution of all packets
          with a valid value of one-way delay (undefined delays are excluded),
          a single value as follows:</t>

          <t>See section 4.1 of <xref target="RFC3393"/> for details on the
          conditional distribution to exclude undefined values of delay, and
          Section 5 of <xref target="RFC6703"/> for background on this
          analysis choice.</t>

          <t>See section 4.3 of <xref target="RFC3393"/> for details on the
          percentile statistic (where pdv should be substituted for
          "ipdv").</t>

          <t>The percentile = 95.</t>

          <t>Data format is a 32-bit signed floating point value, *similar to*
          the 32-bit short NTP Time format in Section 6 of <xref
          target="RFC5905"/> and is as follows: the first 16 bits represent
          the *signed* integer number of seconds; the next 16 bits represent
          the fractional part of a second.</t>
        </section>

        <section title="Reference">
          <t>&lt;pointer to section/spec where output type/format is
          defined&gt;</t>

          <t>see Data Format column.</t>
        </section>

        <section title="Metric Units">
          <t>&lt;insert units for the measured results, and the reference
          specification&gt;.</t>

          <t>See section 3.3 of <xref target="RFC3393"/> for singleton
          elements, ddT. The units are seconds, and the same units are used
          for 95th percentile.</t>

          <t><xref target="RFC2330"/> recommends that when a time is given, it
          will be expressed in UTC.</t>

          <t>The timestamp format (for T, Tf, etc.) is the same as in <xref
          target="RFC5905"/> (64 bits) and is as follows: the first 32 bits
          represent the unsigned integer number of seconds elapsed since 0h on
          1 January 1900; the next 32 bits represent the fractional part of a
          second that has elapsed since then.</t>
        </section>
      </section>

      <section title="Administrative items">
        <t/>

        <section title="Status">
          <t>&lt;current or depricated&gt;</t>
        </section>

        <section title="Requestor (keep?)">
          <t>&lt;name of individual or RFC, etc.&gt;</t>
        </section>

        <section title="Revision">
          <t>1.0</t>
        </section>

        <section title="Revision Date">
          <t>YYYY-MM-DD</t>
        </section>
      </section>

      <section title="Comments and Remarks">
        <t>&lt;Additional (Informational) details for this entry&gt;</t>

        <t>Lost packets represent a challenge for delay variation metrics. See
        section 4.1 of <xref target="RFC3393"/> and the delay variation
        applicability statement<xref target="RFC5481"/> for extensive analysis
        and comparison of PDV and an alternate metric, IPDV.</t>
      </section>
    </section>

    <section title="DNS Response Latency Registry Entry">
      <t>This section gives an initial registry entry for DNS Response
      Latency. <xref target="RFC2681">RFC 2681</xref> defines a Round-trip
      delay metric. We build on that metric by specifying several of the input
      parameters to precisely define a metric for measuring DNS latency.</t>

      <section title="Summary">
        <t>This category includes multiple indexes to the registry entries,
        the element ID and metric name.</t>

        <t>&lt;skipping some admin columns for now&gt;</t>

        <section title="ID (Identifier)">
          <t>&lt;insert numeric identifier, an integer&gt;</t>
        </section>

        <section title="Name">
          <t>&lt;insert name according to metric naming convention&gt;</t>

          <t>URL: ??</t>
        </section>

        <section title="URI">
          <t>URI: Prefix urn:ietf:params:performance:metric</t>
        </section>

        <section title="Description">
          <t>This metric assesses the response time, the interval from the
          query transmission to the response.</t>
        </section>
      </section>

      <section title="Metric Definition">
        <t>This category includes columns to prompt the entry of all necessary
        details related to the metric definition, including the RFC reference
        and values of input factors, called fixed parameters.</t>

        <section title="Reference Definition">
          <t>&lt;Full bibliographic reference to an immutable doc.&gt;</t>

          <t>Mockapetris, P., "Domain names - implementation and
          specification", STD 13, RFC 1035, November 1987. (and updates)</t>

          <t><xref target="RFC1035"/></t>

          <t>Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
          Metric for IPPM", RFC 2681, September 1999.</t>

          <t><xref target="RFC2681"/></t>

          <t>&lt;specific section reference and additional clarifications, if
          needed&gt;</t>

          <t>Section 2.4 of <xref target="RFC2681"/> provides the reference
          definition of the singleton (single value) Round-trip delay metric.
          Section 3.4 of <xref target="RFC2681"/> provides the reference
          definition expanded to cover a multi-value sample. Note that terms
          such as singleton and sample are defined in Section 11 of <xref
          target="RFC2330"/>.</t>

          <t>For DNS Response Latency, the entities in <xref
          target="RFC1035"/> must be mapped to <xref target="RFC2681"/>. The
          Local Host with its User Program and Resolver take the role of
          "Src", and the Foreign Name Server takes the role of "Dst".</t>

          <t>Note that although the definition of "Round-trip-Delay between
          Src and Dst at T" is directionally ambiguous in the text, this
          metric tightens the definition further to recognize that the host in
          the "Src" role will send the first packet to "Dst", and ultimately
          receive the corresponding return packet from "Dst" (when neither are
          lost).</t>
        </section>

        <section title="Fixed Parameters">
          <t>&lt;list and specify Fixed Parameters, input factors that must be
          determined and embedded in the measurement system for use when
          needed&gt;</t>

          <t>Type-P: <list style="symbols">
              <t>IPv4 header values: <list style="symbols">
                  <t>DSCP: set to 0</t>

                  <t>TTL set to 255</t>

                  <t>Protocol: Set to 17 (UDP)</t>
                </list></t>

              <t>UDP header values: <list style="symbols">
                  <t>Source port: 53</t>

                  <t>Destination port: 53</t>

                  <t>Checksum: the checksum must be calculated</t>
                </list></t>

              <t>Payload: The payload contains a DNS message as defined in
              <xref target="RFC1035">RFC 1035</xref> with the following
              values: <list style="symbols">
                  <t>The DNS header section contains: <list style="symbols">
                      <t>QR: set to 0 (Query)</t>

                      <t>OPCODE: set to 0 (standard query)</t>

                      <t>AA: not set</t>

                      <t>TC: not set</t>

                      <t>RD: set to one (recursion desired)</t>

                      <t>RA: not set</t>

                      <t>RCODE: not set</t>

                      <t>QDCOUNT: set to one (only one entry)</t>

                      <t>ANCOUNT: not set</t>

                      <t>NSCOUNT: not set</t>

                      <t>ARCOUNT: not set</t>
                    </list></t>

                  <t>The Question section contains: <list style="symbols">
                      <t>QNAME: the FQDN provided as input for the test</t>

                      <t>QTYPE: the query type provided as input for the
                      test</t>

                      <t>QCLASS: set to IN</t>
                    </list></t>

                  <t>The other sections do not contain any Resource
                  Records.</t>
                </list></t>
            </list></t>

          <t>Observation: reply packets will contain a DNS response and may
          contain RRs.</t>

          <t>Timeout: Tmax = 5 seconds (to help disambiguate queries)</t>
        </section>
      </section>

      <section title="Method of Measurement">
        <t>This category includes columns for references to relevant sections
        of the RFC(s) and any supplemental information needed to ensure an
        unambiguous methods for implementations.</t>

        <section title="Reference Method">
          <t>&lt;for metric, insert relevant section references and
          supplemental info&gt;</t>

          <t>The methodology for this metric is defined as
          Type-P-Round-trip-Delay-Poisson-Stream in section 2.6 of <xref
          target="RFC2681">RFC 2681</xref> and section 3.6 of <xref
          target="RFC2681">RFC 2681</xref> using the Type-P and Timeout
          defined under Fixed Parameters.</t>

          <t>The method requires sequence numbers or other send-order
          information to be retained at the Src or included with each packet
          to dis-ambiguate packet reordering if it occurs. Sequence number is
          part of the payload described under Fixed Parameters.</t>

          <t>DNS Messages bearing Queries provide for random ID Numbers, so
          more than one query may be launched while a previous request is
          outstanding when the ID Number is used.</t>

          <t>IF a DNS response does not arrive within Tmax, the result is
          undefined. The Message ID SHALL be used to disambiguate the
          successive queries.</t>

          <t>&gt;&gt;&gt; This would require support of ID generation and
          population in the Message. An alternative would be to use a random
          Source port on the Query Message, but we would choose ONE before
          proceding.</t>

          <t>Refer to Section 4.4 of <xref target="RFC6673"/> for expanded
          discussion of the instruction to "send a Type-P packet back to the
          Src as quickly as possible" in Section 2.6 of <xref
          target="RFC2681">RFC 2681</xref>. Section 8 of <xref
          target="RFC6673"/> presents additional requirements which shall be
          included in the method of measurement for this metric.</t>
        </section>

        <section title="Packet Generation Stream">
          <t>This section gives the details of the packet traffic which is the
          basis for measurement. In IPPM metrics, this is called the Stream,
          and can easily be dscribed by providing the list of stream
          parameters.</t>

          <t>&lt;list of generation parameters and section/spec references if
          needed&gt;</t>

          <t>Section 11.1.3 of <xref target="RFC2330">RFC 2681</xref> provides
          three methods to generate Poisson sampling intervals. the reciprocal
          of lambda is the average packet rate, thus the Run-time Parameter is
          1/lambda.</t>

          <t>&gt;&gt;&gt; Check with Sam, most likely it is this...</t>

          <t>Method 3 is used, where given a start time (Run-time Parameter),
          the subsequent send times are all computed prior to measurement by
          computing the pseudo-random distribution of inter-packet send times,
          (truncating the distribution as specified in the Run-time
          Parameters), and the Src sends each packet at the computed
          times.</t>
        </section>

        <section title="Traffic Filtering (observation) Details">
          <t>The measured results based on a filtered version of the packets
          observed, and this section provides the filter details (when
          present).</t>

          <t>&lt;section reference&gt;.</t>

          <t>NA</t>
        </section>

        <section title="Sampling Distribution">
          <t>&lt;insert time distribution details, or how this is diff from
          the filter&gt;</t>

          <t>NA</t>
        </section>

        <section title="Run-time Parameters and Data Format">
          <t>Run-time Parameters are input factors that must be determined,
          configured into the measurement system, and reported with the
          results for the context to be complete.</t>

          <t>&lt;list of run-time parameters, and their data formats&gt;</t>

          <t><list style="symbols">
              <t>Src, the IP address of a host (32-bit value for IPv4, 128-bit
              value for IPv6)</t>

              <t>Dst, the IP address of a host (32-bit value for IPv4, 128-bit
              value for IPv6)</t>

              <t>T0, a time (start of measurement interval, 128-bit NTP Date
              Format, see section 6 of <xref target="RFC5905"/>). When T0 is
              "all-zeros", a start time is unspecified and Tf is to be
              interpreted as the Duration of the measurement interval.</t>

              <t>Tf, a time (end of measurement interval, 128-bit NTP Date
              Format, see section 6 of <xref target="RFC5905"/>), interpreted
              as the Duration of the measurement interval.</t>

              <t>1/lambda, average packet rate (for Poisson Streams).
              (1/lambda = 0.1 packet per second, if fixed)</t>

              <t>Upper limit on Poisson distribution (values above this limit
              will be clipped and set to the limit value). (if fixed, Upper
              limit = 300 seconds.)</t>

              <t>ID, the 16-bit identifier assigned by the program that
              generates the query, and which must vary in successive queries,
              see Section 4.1.1 of <xref target="RFC1035"/>. This identifier
              is copied into the corresponding reply and can be used by the
              requester to match-up replies to outstanding queries.</t>
            </list>The format for 1/lambda and Upper limit of Poisson Dist.
          are the short format in <xref target="RFC5905"/> (32 bits) and is as
          follows: the first 16 bits represent the integer number of seconds;
          the next 16 bits represent the fractional part of a second.</t>

          <t>&gt;&gt;&gt; should Poisson run-time params be fixed instead?
          probably yes if modeling a specific version of MBA tests.</t>
        </section>

        <section title="Roles">
          <t>&lt;lists the names of the different roles from the measurement
          method&gt;</t>

          <t>Src - launches each packet and waits for return transmissions
          from Dst.</t>

          <t>Dst - waits for each packet from Src and sends a return packet to
          Src.</t>
        </section>
      </section>

      <section title="Output">
        <t>This category specifies all details of the Output of measurements
        using the metric.</t>

        <section title="Type/Value (two diff terms used)">
          <t>&lt;insert name of the output type, raw or a selected summary
          statistic&gt;</t>

          <t>For all output types:</t>

          <t><list style="symbols">
              <t>T0, a time (start of measurement interval, 128-bit NTP Date
              Format, see section 6 of <xref target="RFC5905"/>)</t>

              <t>Tf, a time (end of measurement interval, 128-bit NTP Date
              Format, see section 6 of <xref target="RFC5905"/>)</t>
            </list></t>

          <t>Raw -- for each packet sent, pairs of values.</t>

          <t>&gt;&gt;&gt; and the status of the response, only assigning
          values to successful query-response pairs.</t>

          <t>Percentile -- for the conditional distribution of all packets
          with a valid value of Round-trip delay (undefined delays are
          excluded), a single value corresponding to the 95th percentile.</t>
        </section>

        <section title="Data Format">
          <t>&lt;describe the data format for each type of result&gt;</t>

          <t>Raw -- for each packet sent, pairs of values as follows:</t>

          <t><list style="symbols">
              <t>T, the time when the packet was sent from Src, 128-bit NTP
              Date Format, see section 6 of <xref target="RFC5905"/>)</t>

              <t>dT, a value of Round-trip delay, format is *similar to* the
              32-bit short NTP Time format in Section 6 of <xref
              target="RFC5905"/> and is as follows: the first 16 bits
              represent the *signed* integer number of seconds; the next 16
              bits represent the fractional part of a second.</t>

              <t>dT is undefined when the packet is not received at Src in
              waiting time Tmxax seconds (need undefined code for no-response
              or un-successful response)</t>
            </list></t>

          <t>Percentile -- for the conditional distribution of all packets
          with a valid value of Round-trip delay (undefined delays are
          excluded), a single value as follows:</t>

          <t>See section 4.1 of <xref target="RFC3393"/> for details on the
          conditional distribution to exclude undefined values of delay, and
          Section 5 of <xref target="RFC6703"/> for background on this
          analysis choice.</t>

          <t>See section 4.3 of <xref target="RFC3393"/> for details on the
          percentile statistic (where Round-trip delay should be substituted
          for "ipdv").</t>

          <t>The percentile = 95.</t>

          <t>Data format is a 32-bit signed floating point value, *similar to*
          the 32-bit short NTP Time format in Section 6 of <xref
          target="RFC5905"/> and is as follows: the first 16 bits represent
          the *signed* integer number of seconds; the next 16 bits represent
          the fractional part of a second.</t>
        </section>

        <section title="Reference">
          <t>&lt;pointer to section/spec where output type/format is
          defined&gt;</t>

          <t>See the Data Format column for references.</t>
        </section>

        <section title="Metric Units">
          <t>&lt;insert units for the measured results, and the reference
          specification&gt;.</t>

          <t>Round-trip Delay, dT, is expressed in seconds.</t>

          <t>The 95th Percentile of Round-trip Delay is expressed in
          seconds.</t>
        </section>
      </section>

      <section title="Administrative items">
        <t/>

        <section title="Status">
          <t>&lt;current or depricated&gt;</t>
        </section>

        <section title="Requestor (keep?)">
          <t>name or RFC, etc.</t>
        </section>

        <section title="Revision">
          <t>1.0</t>
        </section>

        <section title="Revision Date">
          <t>YYYY-MM-DD</t>
        </section>
      </section>

      <section title="Comments and Remarks">
        <t>Additional (Informational) details for this entry</t>
      </section>
    </section>

    <section title="partly BLANK Registry Entry">
      <t>This section gives an initial registry entry for ....</t>

      <section title="Summary">
        <t>This category includes multiple indexes to the registry entries,
        the element ID and metric name.</t>

        <t>&lt;skipping the admin columns for now&gt;</t>

        <section title="ID (Identifier)">
          <t>&lt;insert numeric identifier, an integer&gt;</t>
        </section>

        <section title="Name">
          <t>&lt;insert name according to metric naming convention&gt;</t>

          <t>URL: ??</t>
        </section>

        <section title="URI">
          <t>URI: Prefix urn:ietf:params:performance:metric</t>
        </section>

        <section title="Description">
          <t>TBD.</t>
        </section>
      </section>

      <section title="Metric Definition">
        <t>This category includes columns to prompt the entry of all necessary
        details related to the metric definition, including the RFC reference
        and values of input factors, called fixed parameters.</t>

        <section title="Reference Definition">
          <t>&lt;Full bibliographic reference to an immutable doc.&gt;</t>

          <t>Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay
          Metric for IPPM", RFC 2681, September 1999.</t>

          <t>&lt;specific section reference and additional clarifications, if
          needed&gt;</t>

          <t>Section 2.4 of <xref target="RFC2681"/> provides the reference
          definition of the singleton (single value) Round-trip delay metric.
          Section 3.4 of <xref target="RFC2681"/> provides the reference
          definition expanded to cover a multi-value sample. Note that terms
          such as singleton and sample are defined in Section 11 of <xref
          target="RFC2330"/>.</t>

          <t>Note that although the definition of "Round-trip-Delay between
          Src and Dst at T" is directionally ambiguous in the text, this
          metric tightens the definition further to recognize that the host in
          the "Src" role will send the first packet to "Dst", and ultimately
          receive the corresponding return packet from "Dst" (when neither are
          lost).</t>

          <t>&lt;&lt;&lt; Check how the Methodology also makes this clear (or
          not) &gt;&gt;&gt;</t>
        </section>

        <section title="Fixed Parameters">
          <t>&lt;list and specify Fixed Parameters, input factors that must be
          determined and embedded in the measurement system for use when
          needed&gt;</t>

          <t>Type-P: <list style="symbols">
              <t>IPv4 header values: <list style="symbols">
                  <t>DSCP: set to 0</t>

                  <t>TTL set to 255</t>

                  <t>Protocol: Set to 17 (UDP)</t>
                </list></t>

              <t>UDP header values: <list style="symbols">
                  <t>Checksum: the checksum must be calculated</t>
                </list></t>

              <t>Payload <list style="symbols">
                  <t>Sequence number: 8-byte integer</t>

                  <t>Timestamp: 8 byte integer. Expressed as 64-bit NTP
                  timestamp as per section 6 of <xref target="RFC5905">RFC
                  5905</xref></t>

                  <t>No padding (total of 9 bytes)</t>
                </list></t>
            </list></t>

          <t>Timeout: 3 seconds</t>
        </section>
      </section>

      <section title="Method of Measurement">
        <t>This category includes columns for references to relevant sections
        of the RFC(s) and any supplemental information needed to ensure an
        unambiguous methods for implementations.</t>

        <section title="Reference Method">
          <t>&lt;for metric, insert relevant section references and
          supplemental info&gt;</t>
        </section>

        <section title="Packet Generation Stream">
          <t>This section gives the details of the packet traffic which is the
          basis for measurement. In IPPM metrics, this is called the Stream,
          and can easily be dscribed by providing the list of stream
          parameters.</t>

          <t>&lt;list of generation parameters and section/spec references if
          needed&gt;</t>
        </section>

        <section title="Traffic Filtering (observation) Details">
          <t>The measured results based on a filtered version of the packets
          observed, and this section provides the filter details (when
          present).</t>

          <t>&lt;section reference&gt;.</t>
        </section>

        <section title="Sampling Distribution">
          <t>&lt;insert time distribution details, or how this is diff from
          the filter&gt;</t>
        </section>

        <section title="Run-time Parameters and Data Format">
          <t>Run-time Parameters are input factors that must be determined,
          configured into the measurement system, and reported with the
          results for the context to be complete.</t>

          <t>&lt;list of run-time parameters&gt;</t>

          <t>&lt;reference(s)&gt;.</t>
        </section>

        <section title="Roles">
          <t>&lt;lists the names of the different roles from the measurement
          method&gt;</t>
        </section>
      </section>

      <section title="Output">
        <t>This category specifies all details of the Output of measurements
        using the metric.</t>

        <section title="Type/Value (two diff terms used)">
          <t>&lt;insert name of the output type, raw or a selected summary
          statistic&gt;</t>
        </section>

        <section title="Data Format">
          <t>&lt;describe the data format for each type of result&gt;</t>

          <t><list style="symbols">
              <t>Value:</t>

              <t>Data Format: (There may be some precedent to follow here, but
              otherwise use 64-bit NTP Timestamp Format, see section 6 of
              <xref target="RFC5905"/>).</t>

              <t>Reference: &lt;section reference&gt;</t>
            </list></t>
        </section>

        <section title="Reference">
          <t>&lt;pointer to section/spec where output type/format is
          defined&gt;</t>
        </section>

        <section title="Metric Units">
          <t>&lt;insert units for the measured results, and the reference
          specification&gt;.</t>
        </section>
      </section>

      <section title="Administrative items">
        <t/>

        <section title="Status">
          <t>&lt;current or depricated&gt;</t>
        </section>

        <section title="Requestor (keep?)">
          <t>name or RFC, etc.</t>
        </section>

        <section title="Revision">
          <t>1.0</t>
        </section>

        <section title="Revision Date">
          <t>YYYY-MM-DD</t>
        </section>
      </section>

      <section title="Comments and Remarks">
        <t>Additional (Informational) details for this entry</t>
      </section>
    </section>

    <section title="BLANK Registry Entry">
      <t>This section gives an initial registry entry for ....</t>

      <section title="Summary">
        <t>This category includes multiple indexes to the registry entries,
        the element ID and metric name.</t>

        <t>&lt;skipping the Summary columns for now&gt;</t>

        <section title="ID (Identifier)">
          <t>&lt;insert numeric identifier, an integer&gt;</t>
        </section>

        <section title="Name">
          <t>&lt;insert name according to metric naming convention&gt;</t>

          <t>URL: ??</t>
        </section>

        <section title="URI">
          <t>URI: Prefix urn:ietf:params:performance:metric</t>
        </section>

        <section title="Description">
          <t>TBD.</t>
        </section>
      </section>

      <section title="Metric Definition">
        <t>This category includes columns to prompt the entry of all necessary
        details related to the metric definition, including the RFC reference
        and values of input factors, called fixed parameters.</t>

        <section title="Reference Definition">
          <t>&lt;Full bibliographic reference to an immutable doc.&gt;</t>

          <t>&lt;specific section reference and additional clarifications, if
          needed&gt;</t>

          <t/>
        </section>

        <section title="Fixed Parameters">
          <t>&lt;list and specify Fixed Parameters, input factors that must be
          determined and embedded in the measurement system for use when
          needed&gt;</t>

          <t/>
        </section>
      </section>

      <section title="Method of Measurement">
        <t>This category includes columns for references to relevant sections
        of the RFC(s) and any supplemental information needed to ensure an
        unambiguous methods for implementations.</t>

        <section title="Reference Method">
          <t>&lt;for metric, insert relevant section references and
          supplemental info&gt;</t>
        </section>

        <section title="Packet Generation Stream">
          <t>&lt;list of generation parameters and section/spec references if
          needed&gt;</t>
        </section>

        <section title="Traffic Filtering (observation) Details">
          <t>&lt;insert the measured results based on a filtered version of
          the packets observed, and this section provides the filter details
          (when present), and section reference&gt;.</t>
        </section>

        <section title="Sampling Distribution">
          <t>&lt;insert time distribution details, or how this is diff from
          the filter&gt;</t>
        </section>

        <section title="Run-time Parameters and Data Format">
          <t>&lt;list of run-time parameters, and any reference(s)&gt;.</t>
        </section>

        <section title="Roles">
          <t>&lt;lists the names of the different roles from the measurement
          method&gt;</t>
        </section>
      </section>

      <section title="Output">
        <t>This category specifies all details of the Output of measurements
        using the metric.</t>

        <section title="Type/Value (two diff terms used)">
          <t>&lt;insert name of the output type, raw or a selected summary
          statistic&gt;</t>
        </section>

        <section title="Data Format">
          <t>&lt;describe the data format for each type of result&gt;</t>

          <t/>
        </section>

        <section title="Reference">
          <t>&lt;pointer to section/spec where output type/format is
          defined&gt;</t>
        </section>

        <section title="Metric Units">
          <t>&lt;insert units for the measured results, and the reference
          specification&gt;.</t>
        </section>
      </section>

      <section title="Administrative items">
        <t/>

        <section title="Status">
          <t>&lt;current or depricated&gt;</t>
        </section>

        <section title="Requestor (keep?)">
          <t>&lt;name of individual or RFC, etc.&gt;</t>
        </section>

        <section title="Revision">
          <t>1.0</t>
        </section>

        <section title="Revision Date">
          <t>YYYY-MM-DD</t>
        </section>
      </section>

      <section title="Comments and Remarks">
        <t>Additional (Informational) details for this entry</t>
      </section>
    </section>

    <section title="Example RTCP-XR Registry Entry">
      <t>This section is MAY BE DELETED or adapted before submission.</t>

      <t>This section gives an example registry entry for the end-point metric
      described in RFC 7003 <xref target="RFC7003"/>, for RTCP-XR Burst/Gap
      Discard Metric reporting.</t>

      <section title="Registry Indexes">
        <t>This category includes multiple indexes to the registry entries,
        the element ID and metric name.</t>

        <section title="Identifier">
          <t>An integer having enough digits to uniquely identify each entry
          in the Registry.</t>
        </section>

        <section title="Name">
          <t>A metric naming convention is TBD.</t>
        </section>

        <section title="URI">
          <t>Prefix urn:ietf:params:performance:metric</t>
        </section>

        <section title="Status">
          <t>current</t>
        </section>

        <section title="Requestor">
          <t>Alcelip Mornuley</t>
        </section>

        <section title="Revision">
          <t>1.0</t>
        </section>

        <section title="Revision Date">
          <t>2014-07-04</t>
        </section>

        <section title="Description">
          <t>TBD.</t>
        </section>

        <section title="Reference Specification(s)">
          <t><xref target="RFC3611"/><xref target="RFC4566"/><xref
          target="RFC6776"/><xref target="RFC6792"/><xref
          target="RFC7003"/></t>
        </section>
      </section>

      <section title="Metric Definition">
        <t>This category includes columns to prompt the entry of all necessary
        details related to the metric definition, including the RFC reference
        and values of input factors, called fixed parameters. Section 3.2 of
        <xref target="RFC7003"/> provides the reference information for this
        category.</t>

        <section title="Reference Definition">
          <t>Packets Discarded in Bursts:</t>

          <t>The total number of packets discarded during discard bursts. The
          measured value is unsigned value. If the measured value exceeds
          0xFFFFFD, the value 0xFFFFFE MUST be reported to indicate an
          over-range measurement. If the measurement is unavailable, the value
          0xFFFFFF MUST be reported.</t>
        </section>

        <section title="Fixed Parameters">
          <t>Fixed Parameters are input factors that must be determined and
          embedded in the measurement system for use when needed. The values
          of these parameters is specified in the Registry.</t>

          <t>Threshold: 8 bits, set to value = 3 packets.</t>

          <t>The Threshold is equivalent to Gmin in [RFC3611], i.e., the
          number of successive packets that must not be discarded prior to and
          following a discard packet in order for this discarded packet to be
          regarded as part of a gap. Note that the Threshold is set in
          accordance with the Gmin calculation defined in Section 4.7.2 of
          [RFC3611].</t>

          <t>Interval Metric flag: 2 bits, set to value 11=Cumulative
          Duration</t>

          <t>This field is used to indicate whether the burst/gap discard
          metrics are Sampled, Interval, or Cumulative metrics [RFC6792]:</t>

          <t>I=10: Interval Duration - the reported value applies to the most
          recent measurement interval duration between successive metrics
          reports.</t>

          <t>I=11: Cumulative Duration - the reported value applies to the
          accumulation period characteristic of cumulative measurements.</t>

          <t>Senders MUST NOT use the values I=00 or I=01.</t>
        </section>
      </section>

      <section title="Method of Measurement">
        <t>This category includes columns for references to relevant sections
        of the RFC(s) and any supplemental information needed to ensure an
        unambiguous methods for implementations. For the Burst/Gap Discard
        Metric, it appears that the only guidance on methods of measurement is
        in Section 3.0 of <xref target="RFC7003"/> and its supporting
        references. Relevant information is repeated below, although there
        appears to be no section titled "Method of Measurement" in <xref
        target="RFC7003"/>.</t>

        <section title="Reference Method">
          <t>Metrics in this block report on burst/gap discard in the stream
          arriving at the RTP system. Measurements of these metrics are made
          at the receiving end of the RTP stream. Instances of this metrics
          block use the synchronization source (SSRC) to refer to the separate
          auxiliary Measurement Information Block [RFC6776], which describes
          measurement periods in use (see [RFC6776], Section 4.2).</t>

          <t>This metrics block relies on the measurement period in the
          Measurement Information Block indicating the span of the report.
          Senders MUST send this block in the same compound RTCP packet as the
          Measurement Information Block. Receivers MUST verify that the
          measurement period is received in the same compound RTCP packet as
          this metrics block. If not, this metrics block MUST be
          discarded.</t>
        </section>

        <section title="Stream Type and Stream Parameters">
          <t>Since RTCP-XR Measurements are conducted on live RTP traffic, the
          complete description of the stream is contained in SDP messages that
          proceed the establishment of a compatible stream between two or more
          communicating hosts. See Run-time Parameters, below.</t>
        </section>

        <section title="Output Type and Data Format">
          <t>The output type defines the type of result that the metric
          produces.</t>

          <t><list style="symbols">
              <t>Value: Packets Discarded in Bursts</t>

              <t>Data Format: 24 bits</t>

              <t>Reference: Section 3.2 of <xref target="RFC7003"/></t>
            </list></t>
        </section>

        <section title="Metric Units">
          <t>The measured results are apparently expressed in packets,
          although there is no section of <xref target="RFC7003"/> titled
          "Metric Units".</t>
        </section>

        <section title="Run-time Parameters and Data Format">
          <t>Run-Time Parameters are input factors that must be determined,
          configured into the measurement system, and reported with the
          results for the context to be complete. However, the values of these
          parameters is not specified in the Registry, rather these parameters
          are listed as an aid to the measurement system implementor or user
          (they must be left as variables, and supplied on execution).</t>

          <t>The Data Format of each Run-time Parameter SHALL be specified in
          this column, to simplify the control and implementation of
          measurement devices.</t>

          <t>SSRC of Source: 32 bits As defined in Section 4.1 of
          [RFC3611].</t>

          <t>SDP Parameters: As defined in [RFC4566]</t>

          <t>Session description v= (protocol version number, currently only
          0)</t>

          <t>o= (originator and session identifier : username, id, version
          number, network address)</t>

          <t>s= (session name : mandatory with at least one UTF-8-encoded
          character)</t>

          <t>i=* (session title or short information) u=* (URI of
          description)</t>

          <t>e=* (zero or more email address with optional name of
          contacts)</t>

          <t>p=* (zero or more phone number with optional name of
          contacts)</t>

          <t>c=* (connection information&mdash;not required if included in all
          media)</t>

          <t>b=* (zero or more bandwidth information lines) One or more Time
          descriptions ("t=" and "r=" lines; see below)</t>

          <t>z=* (time zone adjustments)</t>

          <t>k=* (encryption key)</t>

          <t>a=* (zero or more session attribute lines)</t>

          <t>Zero or more Media descriptions (each one starting by an "m="
          line; see below)</t>

          <t>m= (media name and transport address)</t>

          <t>i=* (media title or information field)</t>

          <t>c=* (connection information &mdash; optional if included at
          session level)</t>

          <t>b=* (zero or more bandwidth information lines)</t>

          <t>k=* (encryption key)</t>

          <t>a=* (zero or more media attribute lines &mdash; overriding the
          Session attribute lines)</t>

          <t>An example Run-time SDP description follows:</t>

          <t>v=0</t>

          <t>o=jdoe 2890844526 2890842807 IN IP4 192.0.2.5</t>

          <t>s=SDP Seminar i=A Seminar on the session description protocol</t>

          <t>u=http://www.example.com/seminars/sdp.pdf e=j.doe@example.com
          (Jane Doe)</t>

          <t>c=IN IP4 233.252.0.12/127</t>

          <t>t=2873397496 2873404696</t>

          <t>a=recvonly</t>

          <t>m=audio 49170 RTP/AVP 0</t>

          <t>m=video 51372 RTP/AVP 99</t>

          <t>a=rtpmap:99 h263-1998/90000</t>
        </section>
      </section>

      <section title="Comments and Remarks">
        <t>TBD.</t>
      </section>
    </section>

    <section title="Security Considerations">
      <t>These registry entries represent no known security implications for
      Internet Security. Each referenced Metric contains a Security
      Considerations section.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <!--     <t>Metrics previously defined in IETF were registered in the IANA IPPM
      METRICS REGISTRY, however this process was discontinued when the
      registry structure was found to be inadequate, and the registry was
      declared Obsolete <xref target="RFC6248"/>.</t>

      <t>The form of metric registration will finalized in this and other
      memos, and IANA Action will be requested when the initial contents of
      the registry are prepared.</t>-->

      <t>IANA is requested to create The Active Performance Metric
      Sub-registry within the Performance Metric Registry defined in <xref
      target="I-D.ietf-ippm-metric-registry"/>. The Sub-registry will contain
      the following categories and (bullet) columns, (as defined in section 3
      above):</t>

      <t>Common Registry Indexes and Info</t>

      <t><list style="symbols">
          <t>Identifier</t>

          <t>Name</t>

          <t>Status</t>

          <t>Requester</t>

          <t>Revision</t>

          <t>Revision Date</t>

          <t>Description</t>

          <t>Reference Specification(s)</t>
        </list>Metric Definition<list style="symbols">
          <t>Reference Definition</t>

          <t>Fixed Parameters</t>
        </list>Method of Measurement<list style="symbols">
          <t>Reference Method</t>

          <t>Stream Type and Parameters</t>

          <t>Output type and Data format</t>

          <t>Metric Units</t>

          <t>Run-time Parameters</t>
        </list>Comments and Remarks</t>
    </section>

    <section title="Acknowledgements">
      <t>The authors thank Brian Trammell for suggesting the term "Run-time
      Parameters", which led to the distinction between run-time and fixed
      parameters implemented in this memo, for raising the IPFIX metric with
      Flow Key as an example, and for many other productive suggestions.Thanks
      to Peter Koch, who provided several useful suggestions for
      disambiguating successive DNS Queries in the DNS Response time
      metric.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.1035"?>

      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.2330"?>

      <?rfc include="reference.RFC.2679"?>

      <?rfc include='reference.RFC.2680'?>

      <?rfc include='reference.RFC.2681'?>

      <?rfc include='reference.RFC.3393'?>

      <?rfc include='reference.RFC.3432'?>

      <?rfc ?>

      <?rfc include='reference.RFC.5905'?>

      <?rfc include='reference.RFC.4737'?>

      <?rfc include='reference.RFC.5357'?>

      <?rfc include='reference.RFC.6673'?>

      <reference anchor="I-D.ietf-ippm-metric-registry">
        <front>
          <title>Registry for Performance Metrics</title>

          <author fullname="Marcelo Bagnulo" initials="M." surname="Bagnulo">
            <organization/>
          </author>

          <author fullname="Benoit Claise" initials="B." surname="Claise">
            <organization/>
          </author>

          <author fullname="Phil Eardley" initials="P." surname="Eardley">
            <organization/>
          </author>

          <author fullname="Al Morton" initials="A." surname="Morton">
            <organization/>
          </author>

          <date year="2014"/>
        </front>

        <seriesInfo name="Internet Draft (work in progress)"
                    value="draft-ietf-ippm-metric-registry"/>

        <format type="TXT"/>
      </reference>
    </references>

    <references title="Informative References">
      <?rfc include='reference.RFC.1242'?>

      <?rfc include='reference.RFC.3611'?>

      <?rfc include='reference.RFC.4148'?>

      <?rfc include='reference.RFC.4566'?>

      <?rfc include='reference.RFC.5481'?>

      <?rfc include='reference.RFC.5472'?>

      <?rfc include='reference.RFC.5477'?>

      <?rfc include='reference.RFC.6248'?>

      <?rfc include='reference.RFC.6390'?>

      <?rfc include='reference.RFC.6703'?>

      <?rfc include='reference.RFC.6776'?>

      <?rfc include='reference.RFC.6792'?>

      <?rfc include='reference.RFC.7003'?>

      <?rfc include='reference.I-D.ietf-lmap-framework'?>

      <reference anchor="Brow00">
        <front>
          <title>Packet Matching for NeTraMet Distributions</title>

          <author fullname="N.Brownlee" initials="N." surname="Brownlee">
            <organization>&lt;http://www.caida.org/tools/measurement/
            netramet/packetmatching/&gt;</organization>
          </author>

          <date month="March" year="2000"/>
        </front>
      </reference>
    </references>
  </back>
</rfc>
