idnits 2.17.1 draft-ietf-ippm-metrics-registry-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3. Overview' ) ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 440 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [4], [5], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 62 has weird spacing: '...scribed in th...' == Line 141 has weird spacing: '...= { rfc i }...' == Line 148 has weird spacing: '...= { rfc j }...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 527 looks like a reference -- Missing reference section? '2' on line 530 looks like a reference -- Missing reference section? '3' on line 533 looks like a reference -- Missing reference section? '4' on line 536 looks like a reference -- Missing reference section? '5' on line 69 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Stephan 3 Internet Draft France Telecom R&D 4 Document: draft-ietf-ippm-metrics-registry-02.txt March 1st, 2002 6 IPPM metrics registry 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 [1]. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet- Drafts as reference 19 material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt. 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Abstract 29 This memo defines a registry of the IPPM working group metrics. It 30 provides an OBJECT IDENTIFIER to each metric currently standardized 31 by the IPPM WG. It defines the rules for the identification of the 32 metrics standardized in the future. 34 Table of Contents 36 1. Introduction................................................2 37 2. The IPPM Framework..........................................2 38 3. Overview....................................................2 39 4. IPPM metrics Registry framework.............................2 40 4.1. Metrics registry template...................................3 41 4.2. Initial IPPM metrics registry...............................4 42 4.3. IPPM registry management....................................4 43 4.4. Identification of metric from other organization............4 44 5. Initial IPPM registry.......................................4 45 6. Change since release 00....................................11 46 7. Change since release 01....................................11 47 8. References.................................................11 48 9. Author's Addresses.........................................12 50 1. Introduction 52 This memo defines a registry of the IPPM working group metrics. It 53 provides an OBJECT IDENTIFIER to each metric currently standardized 54 by the IPPM WG. It defines the rules for the identification of the 55 metrics standardized in the future. 57 2. The IPPM Framework 59 The IPPM Framework consists in four major components: 61 + A general framework for defining performance metrics, 62 described in the Framework for IP Performance Metrics, RFC 63 2330; 65 + A set of standardized metrics, which conform to this 66 framework. The IPPM Metrics for Measuring Connectivity, RFC 2678 67 [2]. The One-way Delay Metric for IPPM, RFC 2679 [3]. The One- 68 way Packet Loss Metric for IPPM, RFC 2680 [4]. The Round-trip 69 Delay Metric for IPPM, RFC 2681 [5]; 71 + Emerging metrics which are being specified in respect of this 72 framework; 74 + The IPPM-REPORTING-MIB for reporting the results of the 75 measures and for interfacing heterogeneous measurement systems 76 with management entities. 78 3. Overview 80 This memo defines a registry of the current metrics and a framework 81 for the integration of the future metrics for the following reasons: 83 + to permit metrics to be clearly referenced by MIBs or other 84 data models; 86 + Metrics identifiers are needed to allow measurement 87 interoperability; 89 + Specification of new metrics is a continuous process, special 90 care must be taken for the integration of the future 91 standardized metrics. 93 4. IPPM metrics Registry framework 95 MIBs need OBJECT INDENTIFIER to refer precisely to the standardized 96 metrics. The registry associates an OBJECT IDENTIFIER to each metric. 98 As an example oneWayDelay and oneWayDelayPoissonStream have different 99 identifiers. 101 The registry has 2 root branches. The category of the document 102 determines the node the branch the metric is identified in: 104 + Metrics defined in a RFC are identified in the 'rfc' tree; 105 + Metrics defined elsewhere may be identified in the 'other' tree. 107 The name of the metric has to respect ASN.1 constraints. The name has 108 to start with a lower case. The letter - is forbidden (more or less) 109 in the name. In a way to preserve the readability of the metric name 110 the letters following a - are forced to upper case. 112 Sometime the name of the metric starts with 'Type-P'. It depends on 113 the document not the semantic of the metric. In the registry it is 114 removed from the name of the metric to reduce the length of the name 115 and to uniforms the metrics names. 117 Each metrics specification will include a section describing its 118 metrics identifiers. 120 4.1. Metrics registry template 122 Each memo includes a registry where are identified the metrics. The 123 name of the section where is defined the registry terminate by 124 'metrics registry'. The registry is defined using a MODULE-IDENTITY 125 macro. Each metric is identify in the registry using a OBJECT- 126 IDENTITY macro. The identification defines the metric name, status, 127 reference and OBJECT IDENTIFIER. 129 IPPM-XXX-METRICS-REGISTRY DEFINITIONS ::= BEGIN 131 XXXMetricsRegistry MODULE-IDENTITY 132 DESCRIPTION 133 " This memo defines a registry for XXX metrics." 134 ::= { xxx N } 136 xxxMetric1Name OBJECT-IDENTITY 137 DESCRIPTION 138 "The identifier for the metric1." 139 REFERENCE 140 "xxx, section x." 141 ::= { rfc i } 143 xxxMetric2Name OBJECT-IDENTITY 144 DESCRIPTION 145 "The identifier for the metric1." 146 REFERENCE 147 "xxx, section y." 148 ::= { rfc j } 150 END 152 4.2. Initial IPPM metrics registry 154 Metrics specified in a RFC of the WG IPPM are registered in the node 155 rfc(1). They are numbered using the RFC order and the metrics 156 definitions order in each memo. The value assigned to a metric is 157 definitive and cannot be reused. 159 These rules are applied to create the first IPPM the registry. The 160 metrics already standardized are registered in the section named 161 'IPPM metrics registry' of this memo. 163 4.3. IPPM registry management 165 Usually, metrics are implemented during the specification process. At 166 this step, a metric is not identified as an IPPM metric. There is a 167 need to provide temporary metric identifiers to facilitate software 168 integration and to permit interoperability measurement among 169 different implementations. Otherwise the interoperability will be 170 extremely limited du to the fact that implementers will choose 171 arbitrary values to identify the new metrics. 173 When the draft is considered mature, that is when all the metrics are 174 defined and when they names are chosen: 176 The authors will insert a registry in the section 'Standard 177 metrics registry' of their document. A registry template is 178 proposed above. 180 The chairs of the IPPM WG provide metrics identifiers from the 181 rfc(1) node of the registry. 183 4.4. Identification of metric from other organization 185 Metrics defined by other organization may be registered in the node 186 other(2). 188 5. Initial IPPM registry 190 IPPM-METRICS-REGISTRY DEFINITIONS ::= BEGIN 191 IMPORTS 192 OBJECT-IDENTITY, 193 experimental, 194 MODULE-IDENTITY 195 FROM SNMPv2-SMI; 197 ippmMetricsRegistry MODULE-IDENTITY 198 LAST-UPDATED "200303011100Z" -- March 1st, 2003 199 ORGANIZATION "IPPM working Group" 200 CONTACT-INFO "ippm@advanced.org" 201 DESCRIPTION 202 " This memo defines a portion of the Management Information Base 203 (MIB) for use with network management protocols in TCP/IP-based 204 internets. In particular, it defines a registry of the IPPM 205 working group metrics." 206 REVISION "200303011100Z" 207 DESCRIPTION 208 "Registration rules simplified: see section change since 01." 209 REVISION "200206241100Z" 210 DESCRIPTION 211 "Each metric identifier is defined in a OBJECT IDENTITY macro." 212 ::= { experimental 10002 } 214 rfc OBJECT IDENTIFIER ::= { ippmMetricsRegistry 1 } 215 other OBJECT IDENTIFIER ::= { ippmMetricsRegistry 2 } 217 -- 218 -- Registry of the metrics of the IPPM WG RFCs 219 -- 221 -- 222 -- RFC 2678 " IPPM Metrics for Measuring Connectivity" 223 -- 225 instantUnidirectionConnectivity OBJECT-IDENTITY 226 STATUS current 227 DESCRIPTION 228 "The identifier for the Type-P-Instantaneous-Unidirectional- 229 Connectivity metric." 230 REFERENCE "RFC2678, section 2." 231 ::={rfc 1} 233 instantBidirectionConnectivity OBJECT-IDENTITY 234 STATUS current 235 DESCRIPTION 236 "The identifier for the Type-P-Instantaneous-Bidirectional- 237 Connectivity metric." 238 REFERENCE "RFC2678, section 3." 239 ::={rfc 2} 241 intervalUnidirectionConnectivity OBJECT-IDENTITY 242 STATUS current 243 DESCRIPTION 244 "The identifier for the Type-P-Interval-Unidirectional- 245 Connectivity metric." 246 REFERENCE "RFC2678, section 4." 247 ::= { rfc 3 } 249 intervalBidirectionConnectivity OBJECT-IDENTITY 250 STATUS current 251 DESCRIPTION 252 "The identifier for the Type-P-Interval-Bidirectional- 253 Connectivity metric." 254 REFERENCE "RFC2678, section 5." 255 ::= { rfc 4 } 257 intervalTemporalConnectivity OBJECT-IDENTITY 258 STATUS current 259 DESCRIPTION 260 "The identifier for the Type-P1-P2-Interval-Temporal- 261 Connectivity metric. " 262 REFERENCE "RFC2678, section 6." 263 ::= { rfc 5 } 265 -- 266 -- RFC 2679 "A One-way Delay Metric for IPPM" 267 -- 269 oneWayDelay OBJECT-IDENTITY 270 STATUS current 271 DESCRIPTION 272 "The identifier for the Type-P-One-way-Delay metric. " 273 REFERENCE "RFC2679, section 3." 274 ::= { rfc 6 } 276 oneWayDelayPoissonStream OBJECT-IDENTITY 277 STATUS current 278 DESCRIPTION 279 "The identifier for the Type-P-One-way-Delay-Poisson-Stream 280 metric. " 281 REFERENCE "RFC2679, section 4" 282 ::= { rfc 7 } 284 oneWayDelayPercentile OBJECT-IDENTITY 285 STATUS current 286 DESCRIPTION 287 "The identifier for the Type-P-One-way-Delay-Percentile metric." 288 REFERENCE "RFC2679, section 5.1." 289 ::= { rfc 8 } 291 oneWayDelayMedian OBJECT-IDENTITY 292 STATUS current 293 DESCRIPTION 294 "The identifier for the Type-P-One-way-Delay-Median metric." 295 REFERENCE "RFC2679, section 5.2." 296 ::= { rfc 9 } 298 oneWayDelayMinimum OBJECT-IDENTITY 299 STATUS current 300 DESCRIPTION 301 "The identifier for the Type-P-One-way-Delay-Minimum metric. " 302 REFERENCE "RFC2679, section 5.3." 303 ::= { rfc 10 } 305 oneWayDelayInversePercentile OBJECT-IDENTITY 306 STATUS current 307 DESCRIPTION 308 "The identifier for the Type-P-One-way-Delay-Inverse-Percentile 309 metric. " 310 REFERENCE "RFC2679, section 5.4." 311 ::= { rfc 11 } 313 -- 314 -- RFC 2680 "One Way Packet Loss Metric for IPPM" 315 -- 317 oneWayPacketLoss OBJECT-IDENTITY 318 STATUS current 319 DESCRIPTION 320 "The identifier for the Type-P-One-way-Packet-Loss metric." 321 REFERENCE "RFC2680, section 2." 322 ::= { rfc 12 } 324 oneWayPacketLossPoissonStream OBJECT-IDENTITY 325 STATUS current 326 DESCRIPTION 327 "The identifier for the Type-P-One-way-Packet-Loss-Poisson- 328 Stream metric." 329 REFERENCE "RFC2680, section 3." 330 ::= { rfc 13 } 332 oneWayPacketLossAverage OBJECT-IDENTITY 333 STATUS current 334 DESCRIPTION 335 "The identifier for the Type-P-One-way-Packet-Loss-Average 336 metric." 337 REFERENCE "RFC2680, section 4." 338 ::= { rfc 14 } 340 -- 341 -- RFC2681 "A Round-trip Delay Metric for IPPM" 342 -- 343 roundtripDelay OBJECT-IDENTITY 344 STATUS current 345 DESCRIPTION 346 "The identifier for the Type-P-Round-trip-Delay metric." 347 REFERENCE " section 2 of the rfc2681." 348 ::= { rfc 15 } 350 roundtripDelayPoissonStream OBJECT-IDENTITY 351 STATUS current 352 DESCRIPTION 353 "The identifier for the Type-P-Round-trip-Delay-Poisson-Stream 354 metric." 355 REFERENCE "RFC2681, section 4." 356 ::= { rfc 16 } 358 roundtripDelayPercentile OBJECT-IDENTITY 359 STATUS current 360 DESCRIPTION 361 "The identifier for the Type-P-Round-trip-Delay-Percentile 362 metric." 363 REFERENCE "RFC2681, section 4.1." 364 ::= { rfc 17 } 366 roundtripDelayMedian OBJECT-IDENTITY 367 STATUS current 368 DESCRIPTION 369 "The identifier for the Type-P-Round-trip-Delay-Median metric." 370 REFERENCE "RFC2681, section 4.2." 371 ::= { rfc 18 } 373 roundtripDelayMinimum OBJECT-IDENTITY 374 STATUS current 375 DESCRIPTION 376 "The identifier for the Type-P-Round-trip-Delay-Minimum metric." 377 REFERENCE "RFC2681, section 4.3." 378 ::= { rfc 19 } 380 roundtripDelayInversePercentile OBJECT-IDENTITY 381 STATUS current 382 DESCRIPTION 383 "The identifier for the Type-P-Round-trip-Inverse-Percentile 384 metric." 385 REFERENCE "RFC2681, section 4.4." 386 ::= { rfc 20 } 388 -- 389 -- RFC3357: "One-way Loss Pattern Sample Metrics" 390 -- 392 oneWayLossDistanceStream OBJECT-IDENTITY 393 STATUS current 394 DESCRIPTION 395 "The identifier for the Type-P-One-Way-Loss-Distance-Stream 396 metric." 397 REFERENCE " RFC3357, section 5.4.1." 398 ::={ rfc 21} 400 oneWayLossPeriodStream OBJECT-IDENTITY 401 STATUS current 402 DESCRIPTION 403 "The identifier for the Type-P-One-Way-Loss-Period-Stream 404 metric." 405 REFERENCE " RFC3357, section 5.4.2." 406 ::={ rfc 22} 408 oneWayLossNoticeableRate OBJECT-IDENTITY 409 STATUS current 410 DESCRIPTION 411 "The identifier for the Type-P-One-Way-Loss-Noticeable-Rate 412 metric." 413 REFERENCE " RFC3357, section 6.1." 414 ::= { rfc 23 } 416 oneWayLossPeriodTotal OBJECT-IDENTITY 417 STATUS current 418 DESCRIPTION 419 "The identifier for the Type-P-One-Way-Loss-Period-Total 420 metric." 421 REFERENCE " RFC3357, section 6.2." 422 ::= { rfc 24 } 424 oneWayLossPeriodLengths OBJECT-IDENTITY 425 STATUS current 426 DESCRIPTION 427 "The identifier for the Type-P-One-Way-Loss-Period-Lengths 428 metric." 429 REFERENCE " RFC3357, section 6.3." 430 ::= { rfc 25 } 432 oneWayInterLossPeriodLengths OBJECT-IDENTITY 433 STATUS current 434 DESCRIPTION 435 "The identifier for the Type-P-One-Way-Inter-Loss-Period-Lengths 436 metric." 437 REFERENCE " RFC3357, section 6.4." 438 ::= { rfc 26 } 440 -- 441 -- RFC3393: "IP Packet Delay Variation Metric for IP Performance 442 Metrics (IPPM)" 443 -- 444 oneWayIpdv OBJECT-IDENTITY 445 STATUS current 446 DESCRIPTION 447 "The identifier for the Type-P-One-way-ipdv metric." 448 REFERENCE " RFC3393, section 2." 449 ::= { rfc 27 } 451 oneWayIpdvPoissonStream OBJECT-IDENTITY 452 STATUS current 453 DESCRIPTION 454 "The identifier for the Type-P-One-way-ipdv-Poisson-stream 455 metric." 456 REFERENCE " RFC3393, section 3." 457 ::= { rfc 28 } 459 oneWayIpdvPercentile OBJECT-IDENTITY 460 STATUS current 461 DESCRIPTION 462 "The identifier for the Type-P-One-way-ipdv-percentile metric." 463 REFERENCE " RFC3393, section 4.3." 464 ::= { rfc 29 } 466 oneWayIpdvInversePercentile OBJECT-IDENTITY 467 STATUS current 468 DESCRIPTION 469 "The identifier for the Type-P-One-way-ipdv-inverse-percentile 470 metric." 471 REFERENCE " RFC3393, section 4.4." 472 ::= { rfc 30 } 474 oneWayIpdvJitter OBJECT-IDENTITY 475 STATUS current 476 DESCRIPTION 477 "The identifier for the Type-P-One-way-ipdv-jitter metric." 478 REFERENCE " RFC3393, section 4.5." 479 ::= { rfc 31 } 481 oneWayPeakToPeakIpdv OBJECT-IDENTITY 482 STATUS current 483 DESCRIPTION 484 "The identifier for the Type-P-One-way-peak-to-peak-ipdv 485 metric." 486 REFERENCE " RFC3393, section 4.6." 487 ::= { rfc 32 } 489 -- 490 -- RFC3432: "Network performance measurement with periodic streams" 491 -- 492 oneWayDelayPeriodicStream OBJECT-IDENTITY 493 STATUS current 494 DESCRIPTION 495 "The identifier for the Type-P-One-way-Delay-Periodic-Stream 496 metric." 497 REFERENCE " RFC3432, section 4." 498 ::= { rfc 33 } 500 END 502 6. Change since release 00 504 Macro OBJECT-IDENTITY used to identify the metrics 506 7. Change since release 01 508 + Registrations rules simplified; 510 + Draft sub tree removed; 512 + Loss pattern metrics of the RFC3357 added to the registry. 514 + ipdv metrics of the RFC3393 added to the registry. 516 + Periodic streams metrics of the RFC3432 added to the registry. 518 56th IETF open issues: 519 should metrics OID be 8 bytes length ? Y/N 520 -- should be ::= { ippm 1 } 521 -- with ippm OBJECT IDENTIFIER ::= { mgmt xxx } 522 -- to have metrics OID to be 8 bytes length. 523 -- 1.3.6.1.2.ippm.ippmMetricRegistry.rfc.oneWayDelay 525 8. References 527 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 528 9, RFC 2026, October 1996. 530 [2] Mahdavi J. and V. Paxson, "IPPM Metrics for Measuring 531 Connectivity", RFC 2678, September 1999. 533 [3] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Delay 534 Metric for IPPM", RFC 2679, September 1999. 536 [4] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Packet 537 Loss Metric for IPPM", RFC 2680, September 1999. 539 [5]Almes, G., Kalidindi, S. and M. Zekauskas, "A Round-trip Delay 540 Metric for IPPM.", RFC 2681, September 1999. 542 9. Author's Addresses 544 Emile STEPHAN 545 France Telecom R & D 546 2 avenue Pierre Marzin 547 F-22307 Lannion cedex 548 Phone: (+ 33) 2 96 05 11 11 549 Email: emile.stephan@francetelecom.com 551 Full Copyright Statement 553 "Copyright (C) The Internet Society (2001). All Rights Reserved. 555 This document and translations of it may be copied and furnished to 556 others, and derivative works that comment on or otherwise explain it 557 or assist its implementation may be prepared, copied, published and 558 distributed, in whole or in part, without restriction of any kind, 559 provided that the above copyright notice and this paragraph are 560 included on all such copies and derivative works. However, this 561 document itself may not be modified in any way, such as by removing 562 the copyright notice or references to the Internet Society or other 563 Internet organizations, except as needed for the purpose of 564 developing Internet standards in which case the procedures for 565 copyrights defined in the Internet Standards process must be 566 followed, or as required to translate it into languages other than 567 English. 569 The limited permissions granted above are perpetual and will not be 570 revoked by the Internet Society or its successors or assigns. 572 This document and the information contained herein is provided on an 573 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 574 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 575 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 576 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 577 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.