idnits 2.17.1 draft-morton-ippm-rfc4148-obsolete-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC4148, but the abstract doesn't seem to directly say this. It does mention RFC4148 though, so this could be OK. -- The draft header indicates that this document updates RFC5560, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5644, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4737, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4737, updated by this document, for RFC5378 checks: 2002-06-21) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 10, 2011) is 4853 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4148 (Obsoleted by RFC 6248) -- Obsolete informational reference (is this intentional?): RFC 2679 (Obsoleted by RFC 7679) -- Obsolete informational reference (is this intentional?): RFC 2680 (Obsoleted by RFC 7680) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Morton 3 Internet-Draft AT&T Labs 4 Obsoletes: 4148 (if approved) January 10, 2011 5 Updates: 4737, 5560, 5644, 6049 6 (if approved) 7 Intended status: Informational 8 Expires: July 14, 2011 10 RFC 4148 and the IPPM Metrics Registry are Obsolete 11 draft-morton-ippm-rfc4148-obsolete-03 13 Abstract 15 This memo reclassifies RFC 4148, the IP Performance Metrics (IPPM) 16 Registry as Obsolete, and withdraws the IANA IPPM Metrics Registry 17 itself from use because it is obsolete. The current registry 18 structure has been found to be insufficiently detailed to uniquely 19 identify IPPM metrics. Despite apparent efforts to find current or 20 even future users, no one has responded to the call for interest in 21 the RFC 4148 registry during the second half of 2010. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 14, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Action to Reclassify RFC 4148 and the corresponding IANA 59 registry as Obsolete . . . . . . . . . . . . . . . . . . . . . 4 60 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 62 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 65 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 1. Introduction 70 The IP Performance Metrics (IPPM) framework [RFC2330] describes 71 several ways to record options and metric parameter settings, in 72 order to account for sources of measurement variability. For 73 example, Section 13 of[RFC2330] describes the notion of "Type P" so 74 that metrics can be specified in general, but the specifics (such as 75 payload length in octets and protocol type) can replace P to 76 disambiguate the results. 78 When the IPPM Metric Registry [RFC4148] was designed, the variability 79 of the Type P notion, and the variability possible with the many 80 metric parameters (see Section 4.1 of [RFC2679] ) was not fully 81 appreciated. Further, some of the early metric definitions only 82 indicate Poisson streams [RFC2330] (see the metrics in [RFC2679], 83 [RFC2680], and [RFC3393]), but later work standardized the methods 84 for Periodic Stream measurements [RFC3432], adding to the variability 85 possible when characterizing a metric exactly. 87 It is not believed to be feasible or even useful to register every 88 possible combination of Type P, metric parameters, and Stream 89 parameters using the current structure of the IPPM Metric Registry. 91 The IPPM Metrics Registry is believed to have very few users, if any. 92 Evidence of this provided by the fact that one registry entry was 93 syntactically incorrect for months after [RFC5644] was published. 94 The text ":=" was used for the metrics in that document instead of 95 "::=". It took eight months before someone offered that a parser 96 found the error. Even the original registry author agrees that the 97 current registry is not efficient, and has submitted a proposal to 98 effectively create a new registry. 100 Despite apparent efforts to find current or even future users, no one 101 has responded to the second half of 2010 call for interest in the RFC 102 4148 registry. Therefore, the IETF now declares the registry 103 Obsolete without any further reservations. 105 When a registry is designated Obsolete, it simply prevents IANA from 106 registering new objects, in this case new metrics. So, even if a 107 registry user was eventually found, they could continue to use the 108 current registry and its contents will continue to be available. 110 The most recently published memo that added metrics to the registry 111 is [RFC6049]. This memo updates all previous memos that registered 112 new metrics, including [RFC4737] and [RFC5560], so that the 113 registry's Obsolete status will be evident. 115 2. Action to Reclassify RFC 4148 and the corresponding IANA registry as 116 Obsolete 118 Due to the ambiguities between the current metrics registrations and 119 the metrics used, and the apparent minimal adoption of the registry 120 in practice, it is required that: 122 o the IETF reclassify [RFC4148] as Obsolete. 124 o the IANA withdraw the current IPPM Metrics Registry from further 125 updates and note that it too is Obsolete. 127 It is assumed that parties who wish to establish a replacement 128 registry function will work to specify such a registry. 130 3. Security Considerations 132 This memo and its recommendations have no known impact on the 133 security of the Internet (especially if there is a zombie apocalypse 134 on the day it is published; humans will have many more security 135 issues to worry about stemming from the rise of the un-dead). 137 4. IANA Considerations 139 Metrics defined in IETF have been typically registered in the IANA 140 IPPM METRICS REGISTRY as described in initial version of the registry 141 [RFC4148]. However, areas for improvement of this registry have been 142 identified, and the registry structure has to be revisited when there 143 is working group consensus to do so. 145 The current consensus is to designate the IPPM Metrics Registry, 146 originally described in [RFC4148], as Obsolete. 148 The DESCRIPTION of the registry MIB should be modified as follows, 149 and the first two sentences should be included on any IANA-maintained 150 web-page describing this registry or its contents (with the RFC 151 number of this memo replacing "XXXX"): 153 DESCRIPTION 155 "With the approval and publication of RFC XXXX, this module is 156 designated Obsolete. 158 The registry will no longer be updated, and the current contents will 159 be maintained as-is on the day that RFC XXXX was published. 161 The original Description text follows below: 163 This module defines a registry for IP Performance Metrics. 165 ... " 167 5. Acknowledgements 169 Henk Uijterwaal suggested additional rationale for the recommendation 170 in this memo. 172 6. References 174 6.1. Normative References 176 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 177 Registry", BCP 108, RFC 4148, August 2005. 179 6.2. Informative References 181 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 182 "Framework for IP Performance Metrics", RFC 2330, 183 May 1998. 185 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 186 Delay Metric for IPPM", RFC 2679, September 1999. 188 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 189 Packet Loss Metric for IPPM", RFC 2680, September 1999. 191 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 192 Metric for IP Performance Metrics (IPPM)", RFC 3393, 193 November 2002. 195 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 196 performance measurement with periodic streams", RFC 3432, 197 November 2002. 199 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 200 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 201 November 2006. 203 [RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric", 204 RFC 5560, May 2009. 206 [RFC5644] Stephan, E., Liang, L., and A. Morton, "IP Performance 207 Metrics (IPPM): Spatial and Multicast", RFC 5644, 208 October 2009. 210 [RFC6049] Morton, A. and E. Stephan, "Spatial Composition of 211 Metrics", RFC 6049, January 2011. 213 Author's Address 215 Al Morton 216 AT&T Labs 217 200 Laurel Avenue South 218 Middletown,, NJ 07748 219 USA 221 Phone: +1 732 420 1571 222 Fax: +1 732 368 1192 223 Email: acmorton@att.com 224 URI: http://home.comcast.net/~acmacm/