summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6248.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6248.txt')
-rw-r--r--doc/rfc/rfc6248.txt339
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]
+