One document matched: draft-morton-ippm-rfc4148-obsolete-01.xml

<?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-morton-ippm-rfc4148-obsolete-01"
     ipr="trust200902">
  <front>
    <title abbrev="RFC 4148 is Obsolete">RFC 4148 and the IPPM Metrics
    Registry are Obsolete</title>

    <author fullname="Al Morton" initials="A." surname="Morton">
      <organization>AT&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>

    <date day="1" month="July" year="2010" />

    <abstract>
      <t>This memo recommends that RFC 4148, the IP Performance Metrics (IPPM)
      Registry be reclassified as Historic, and the IANA IPPM Metrics Registry
      itself be withdrawn from use. The current registry structure has been
      found to be insufficiently detailed to uniquely identify IPPM
      metrics.</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></t>
    </note>
  </front>

  <middle>
    <section title="Introduction">
      <t>The IP Performance Metrics (IPPM) framework <xref
      target="RFC2330"></xref> describes several ways to record options and
      metric parameter settings, in order to account for sources of
      measurement variability. For example, Section 13 of<xref
      target="RFC2330"></xref> describes the notion of "Type P" so that
      metrics can be specified in general, but the specifics (such as payload
      length in octets and protocol type) can replace P to disambiguate the
      results.</t>

      <t>When the IPPM Metric Registry <xref target="RFC4148"></xref> was
      designed, the variability of the Type P notion, and the variability
      possible with the many metric parameters (see Section 4.1 of <xref
      target="RFC2679"></xref> ) was not fully appreciated. Further, some of
      the early metric definitions only indicate Poisson streams <xref
      target="RFC2330"></xref> (see the metrics in <xref
      target="RFC2679"></xref>, <xref target="RFC2680"></xref>, and <xref
      target="RFC3393"></xref>), but later work standardized the methods for
      Periodic Stream measurements <xref target="RFC3432"></xref>, adding to
      the variability possible when characterizing a metric exactly.</t>

      <t>It is not believed to be feasible or even useful to register every
      possible combination of Type P, metric parameters, and Stream parameters
      using the current structure of the IPPM Metric Registry.</t>

      <t>The IPPM Metrics Registry is believed to have very few, if any users.
      Evidence of this provided by the fact that one registry entry was
      syntactically incorrect for months after <xref target="RFC5644"></xref>
      was published. The text ":=" was used for the metrics in that document
      instead of "::=". It took eight months before someone complained that a
      parser found the error. Even the original registry author agrees that
      the current registry is not efficient, and has submitted a proposal to
      effectively create a new registry [draft-stephan-ippm-registry-ext-00,
      work in progress].</t>
    </section>

    <section title="Recommendation to Reclassify RFC 4148 and Withdraw the corresponding IANA registry">
      <t>Due to the ambiguities between the current metrics registrations and
      the metrics used, and the apparent minimal adoption of the registry in
      practice, this memo RECOMMENDS that:</t>

      <t><list style="symbols">
          <t>the IETF reclassify <xref target="RFC4148"></xref> as
          Historic</t>

          <t>the IANA withdraw the current IPPM Metrics Registry</t>
        </list>It is assumed that parties who wish to establish a replacement
      registry function will work to specify such a registry.</t>
    </section>

    <section title="Security Considerations">
      <t>This memo and its recommendations have no known impact on the
      security of the Internet (especially if there is a a zombie apocalypse
      on the day it is published).</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>Metrics defined in IETF are typically registered in the IANA IPPM
      METRICS REGISTRY as described in initial version of the registry <xref
      target="RFC4148"></xref>. However, areas for improvement of this
      registry have been identified, and the registry structure has to be
      revisited when there is consensus to do so.</t>

      <t>The current consensus is to withdraw the IPPM Metrics Registry, as
      originally described in <xref target="RFC4148"></xref>.</t>
    </section>

    <section title="Acknowledgements">
      <t>Henk Uijterwaal suggested additional rationale for the recommendation
      in this memo.</t>
    </section>
  </middle>

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

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

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

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

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

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

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

      <?rfc include='reference.RFC.5644'?>
    </references>

    <references title="Informative References">
      <reference anchor="....">
        <front>
          <title>None</title>

          <author fullname="" surname="">
            <organization></organization>
          </author>

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