One document matched: draft-morton-ippm-rfc4148-obsolete-03.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="info" docName="draft-morton-ippm-rfc4148-obsolete-03"
     ipr="trust200902" obsoletes="4148" updates="4737, 5560, 5644, 6049">
  <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="10" month="January" year="2011" />

    <abstract>
      <t>This memo reclassifies RFC 4148, the IP Performance Metrics (IPPM)
      Registry as Obsolete, and withdraws the IANA IPPM Metrics Registry
      itself from use because it is obsolete. The current registry structure
      has been found to be insufficiently detailed to uniquely identify IPPM
      metrics. Despite apparent efforts to find current or even future users,
      no one has responded to the call for interest in the RFC 4148 registry
      during the second half of 2010.</t>
    </abstract>
  </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 users, if any.
      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 offered 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.</t>

      <t>Despite apparent efforts to find current or even future users, no one
      has responded to the second half of 2010 call for interest in the RFC
      4148 registry. Therefore, the IETF now declares the registry Obsolete
      without any further reservations.</t>

      <t>When a registry is designated Obsolete, it simply prevents IANA from
      registering new objects, in this case new metrics. So, even if a
      registry user was eventually found, they could continue to use the
      current registry and its contents will continue to be available.</t>

      <t>The most recently published memo that added metrics to the registry
      is <xref target="RFC6049"></xref>. This memo updates all previous memos
      that registered new metrics, including <xref target="RFC4737"></xref>
      and <xref target="RFC5560"></xref>, so that the registry's Obsolete
      status will be evident.</t>
    </section>

    <section title="Action to Reclassify RFC 4148 and the corresponding IANA registry as Obsolete">
      <t>Due to the ambiguities between the current metrics registrations and
      the metrics used, and the apparent minimal adoption of the registry in
      practice, it is required that:</t>

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

          <t>the IANA withdraw the current IPPM Metrics Registry from further
          updates and note that it too is Obsolete.</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 zombie apocalypse on
      the day it is published; humans will have many more security issues to
      worry about stemming from the rise of the un-dead).</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>Metrics defined in IETF have been 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 working group consensus to do so.</t>

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

      <t>The DESCRIPTION of the registry MIB should be modified as follows,
      and the first two sentences should be included on any IANA-maintained
      web-page describing this registry or its contents (with the RFC number
      of this memo replacing "XXXX"):</t>

      <t>DESCRIPTION</t>

      <t>"With the approval and publication of RFC XXXX, this module is
      designated Obsolete.</t>

      <t>The registry will no longer be updated, and the current contents will
      be maintained as-is on the day that RFC XXXX was published.</t>

      <t>The original Description text follows below:</t>

      <t>This module defines a registry for IP Performance Metrics.</t>

      <t>... "</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 ?>

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

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>
    </references>

    <references title="Informative References">
      <?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.4737'?>

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

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

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