From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6248.txt | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/rfc/rfc6248.txt (limited to 'doc/rfc/rfc6248.txt') 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] + -- cgit v1.2.3