doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc6248.txt b/doc/rfc/rfc6248.txt
new file mode 100644
index 0000000..3b634b5
--- /dev/null
+++ b/doc/rfc/rfc6248.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         A. Morton
+Request for Comments: 6248                                     AT&T Labs
+Obsoletes: 4148                                               April 2011
+Updates: 4737, 5560, 5644, 6049
+Category: Informational
+ISSN: 2070-1721
+
+
+   RFC 4148 and the IP Performance Metrics (IPPM) Registry of Metrics
+                              Are Obsolete
+
+Abstract
+
+   This memo reclassifies RFC 4148, "IP Performance Metrics (IPPM)
+   Metrics 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 responded to the call for
+   interest in the RFC 4148 registry during the second half of 2010.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6248.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Morton                        Informational                     [Page 1]
+
+RFC 6248                  RFC 4148 is Obsolete                April 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Action to Reclassify RFC 4148 and the Corresponding IANA
+      Registry as Obsolete ............................................3
+   3. Security Considerations .........................................4
+   4. IANA Considerations .............................................4
+   5. Acknowledgements ................................................4
+   6. References ......................................................5
+      6.1. Normative References .......................................5
+      6.2. Informative References .....................................5
+
+1.  Introduction
+
+   The IP Performance Metrics (IPPM) framework [RFC2330] describes
+   several ways to record options and metric parameter settings, in
+   order to account for sources of measurement variability.  For
+   example, Section 13 of [RFC2330] 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.
+
+   When the IPPM Metrics Registry [RFC4148] was designed, the
+   variability of the "Type P" notion, and the variability possible with
+   the many metric parameters (see Section 4.2 of [RFC2679]), were not
+   fully appreciated.  Further, some of the early metric definitions
+   only indicate Poisson streams [RFC2330] (see the metrics in
+   [RFC2679], [RFC2680], and [RFC3393]), but later work standardized the
+   methods for Periodic Stream measurements [RFC3432], adding to the
+   variability possible when characterizing a metric exactly.
+
+
+
+
+
+
+Morton                        Informational                     [Page 2]
+
+RFC 6248                  RFC 4148 is Obsolete                April 2011
+
+
+   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 Metrics Registry.
+
+   The IPPM Metrics Registry is believed to have very few users, if any.
+   Evidence of this was provided by the fact that one registry entry was
+   syntactically incorrect for months after [RFC5644] 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.
+
+   Despite apparent efforts to find current or even future users, no one
+   responded to the call for interest in the RFC 4148 registry during
+   the second half of 2010.  Therefore, the IETF now declares the
+   registry Obsolete without any further reservations.
+
+   When a registry is designated Obsolete, it simply prevents the 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.
+
+   The most recently published memo that added metrics to the registry
+   is [RFC6049].  This memo updates all previous memos that registered
+   new metrics, including [RFC4737] and [RFC5560], so that the
+   registry's Obsolete status will be evident.
+
+2.  Action to Reclassify RFC 4148 and the Corresponding IANA Registry as
+    Obsolete
+
+   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:
+
+   o  the IETF reclassify [RFC4148] as Obsolete.
+
+   o  the IANA withdraw the current IPPM Metrics Registry from further
+      updates and note that it too is Obsolete.
+
+   It is assumed that parties who wish to establish a replacement
+   registry function will work to specify such a registry.
+
+
+
+
+
+
+
+
+
+Morton                        Informational                     [Page 3]
+
+RFC 6248                  RFC 4148 is Obsolete                April 2011
+
+
+3.  Security Considerations
+
+   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).
+
+4.  IANA Considerations
+
+   Metrics defined in the IETF have been typically registered in the
+   IANA IPPM Metrics Registry as described in the initial version of the
+   registry [RFC4148].  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.
+
+   The current consensus is to designate the IPPM Metrics Registry,
+   originally described in [RFC4148], as Obsolete.
+
+   The DESCRIPTION of the registry MIB has been modified as follows, and
+   the first two sentences should be included on any IANA-maintained web
+   page describing this registry or its contents:
+
+   DESCRIPTION
+
+      "With the approval and publication of RFC 6248, this module is
+      designated Obsolete.
+
+      The registry will no longer be updated, and the current contents
+      will be maintained as-is on the day that RFC 6248 was published.
+
+      The original Description text follows below:
+
+      This module defines a registry for IP Performance Metrics.
+
+      ... "
+
+5.  Acknowledgements
+
+   Henk Uijterwaal suggested additional rationale for the recommendation
+   in this memo.
+
+
+
+
+
+
+
+
+
+
+
+Morton                        Informational                     [Page 4]
+
+RFC 6248                  RFC 4148 is Obsolete                April 2011
+
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC4148]  Stephan, E., "IP Performance Metrics (IPPM) Metrics
+              Registry", BCP 108, RFC 4148, August 2005.
+
+6.2.  Informative References
+
+   [RFC2330]  Paxson, V., Almes, G., Mahdavi, J., and M. Mathis,
+              "Framework for IP Performance Metrics", RFC 2330,
+              May 1998.
+
+   [RFC2679]  Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
+              Delay Metric for IPPM", RFC 2679, September 1999.
+
+   [RFC2680]  Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
+              Packet Loss Metric for IPPM", RFC 2680, September 1999.
+
+   [RFC3393]  Demichelis, C. and P. Chimento, "IP Packet Delay Variation
+              Metric for IP Performance Metrics (IPPM)", RFC 3393,
+              November 2002.
+
+   [RFC3432]  Raisanen, V., Grotefeld, G., and A. Morton, "Network
+              performance measurement with periodic streams", RFC 3432,
+              November 2002.
+
+   [RFC4737]  Morton, A., Ciavattone, L., Ramachandran, G., Shalunov,
+              S., and J. Perser, "Packet Reordering Metrics", RFC 4737,
+              November 2006.
+
+   [RFC5560]  Uijterwaal, H., "A One-Way Packet Duplication Metric",
+              RFC 5560, May 2009.
+
+   [RFC5644]  Stephan, E., Liang, L., and A. Morton, "IP Performance
+              Metrics (IPPM): Spatial and Multicast", RFC 5644,
+              October 2009.
+
+   [RFC6049]  Morton, A. and E. Stephan, "Spatial Composition of
+              Metrics", RFC 6049, January 2011.
+
+
+
+
+
+
+
+
+
+
+
+Morton                        Informational                     [Page 5]
+
+RFC 6248                  RFC 4148 is Obsolete                April 2011
+
+
+Author's Address
+
+   Al Morton
+   AT&T Labs
+   200 Laurel Avenue South
+   Middletown, NJ  07748
+   USA
+
+   Phone: +1 732 420 1571
+   Fax:   +1 732 368 1192
+   EMail: acmorton@att.com
+   URI:   http://home.comcast.net/~acmacm/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Morton                        Informational                     [Page 6]
+