idnits 2.17.1 draft-ietf-ippm-metrics-registry-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 606. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 613. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 619. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 635), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 100 has weird spacing: '...ded for enter...' -- 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 (November 30, 2004) is 7080 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2330' is defined on line 570, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) ** Downref: Normative reference to an Informational RFC: RFC 3357 Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group E. Stephan 2 Internet-Draft France Telecom R&D 3 Expires: May 31, 2005 November 30, 2004 5 IP Performance Metrics (IPPM) metrics registry 6 draft-ietf-ippm-metrics-registry-08.txt 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on May 31, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This memo defines a registry for IP Performance Metrics (IPPM). It 40 assigns and registers an initial set of OBJECT IDENTITIES to 41 currently defined metrics in the IETF. 43 This memo also defines the rules for adding new IP Performance 44 Metrics that are defined in the future and for encouraging all IP 45 performance metrics to be registered here. 47 IANA has been assigned to administer this new registry. 49 Table of Contents 51 1. The Internet-Standard Management Framework . . . . . . . . . . 3 52 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. IP Performance Metrics Registry Framework . . . . . . . . . . 3 54 4. Initial IPPM Metrics Registry Creation . . . . . . . . . . . . 4 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 56 5.1 Management rules . . . . . . . . . . . . . . . . . . . . . 5 57 5.2 Registration template . . . . . . . . . . . . . . . . . . 5 58 6. Initial IPPM registry definition . . . . . . . . . . . . . . . 6 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 61 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 62 8.2 Informative References . . . . . . . . . . . . . . . . . . . 15 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 64 Intellectual Property and Copyright Statements . . . . . . . . 16 66 1. The Internet-Standard Management Framework 68 For a detailed overview of the documents that describe the current 69 Internet-Standard Management Framework, please refer to section 7 of 70 RFC 3410 [RFC3410]. Managed objects are accessed via a virtual 71 information store, termed the Management Information Base or MIB. 72 MIB objects are generally accessed through the Simple Network 73 Management Protocol (SNMP). Objects in the MIB are defined using the 74 mechanisms defined in the Structure of Management Information (SMI). 75 This memo specifies a MIB module that is compliant to the SMIv2, 76 which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 77 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 79 2. Overview 81 This memo defines a registry of the current metrics and a framework 82 for the integration of future metrics for the following reasons: 84 o to permit metrics to be clearly referenced by MIB modules or other 85 data models; 87 o Metrics identifiers are needed to allow measurement 88 interoperability; 90 o As specification of new metrics is a continuous process, special 91 care must be taken for the integration of future standardized 92 metrics; 94 o Since the intent of the IPPM WG is to cooperate with other 95 appropriate standards bodies (or fora) to promote consistent 96 metrics, room where other standards bodies can register their 97 metrics is provided to encourage IP performance metrics to have 98 OBJECT IDENTITIES rooted at a common point; 100 o Similarly, room is provided for enterprises to register metrics. 102 3. IP Performance Metrics Registry Framework 104 MIB modules need to be able to precisely reference IPPM Metrics. The 105 registry associates an OBJECT-IDENTITY with each metric. As an 106 example Type-P-One-way-Delay and Type-P-One-way-Delay-Poisson-Stream 107 have different OBJECT IDENTITIES. 109 The registry has one branch. Metrics are identified in 110 'ianaIppmMetrics' subtree. 112 This document defines an initial registry of the existing metrics 113 defined in the IPPM WG and the rules to manage the registry. 115 Documents defining metrics in the future will include in the IANA 116 section the registration information to unambiguously identify these 117 metrics. 119 4. Initial IPPM Metrics Registry Creation 121 The initial registry identifies the metrics currently defined in the 122 RFCs produced in the IPPM WG. To date, the IPPM WG defined 33 123 metrics related to 7 topics: 125 o IPPM Metrics for Measuring Connectivity, RFC 2678 [RFC2678]; 127 o One-way Delay Metrics, RFC 2679 [RFC2679]; 129 o One-way Packet Loss Metrics, RFC 2680 [RFC2680]; 131 o Round-trip Delay Metrics, RFC 2681 [RFC2681]; 133 o One-way Loss Pattern Sample Metrics, RFC 3357 [RFC3357]; 135 o IP Packet Delay Variation Metric, RFC 3393 [RFC3393]; 137 o IPPM Metrics for periodic streams, RFC 3432 [RFC3432]; 139 They are sequentially registered in the node ianaIppmMetrics. 141 The naming conventions used for the existing metrics, and encouraged 142 for new IPPM metrics, are : 144 o Metrics names comform SMIv2 rules for descriptors defined in the 145 section 3.1 of [RFC2578]; 147 o The name starts with the prefix 'ietf'; 149 o 'Type-P' prefix is removed; 151 o '-' are removed; 153 o The letter following a '-' is changed to upper case. 155 5. IANA Considerations 157 This section describes the rules for the management of the registry 158 by IANA. 160 5.1 Management rules 162 Registrations are done sequentially by IANA in the ianaIppmMetrics 163 subtree on the bases of 'Specification Required' as defined in 164 [RFC2434]. 166 The reference of the specification must point to a stable document 167 including a title, a revision and a date. 169 The name always starts with the name of the organization and must 170 respect the SMIv2 rules for descriptors defined in the section 3.1 of 171 [RFC2578]; 173 A document that creates new metrics would have an IANA considerations 174 section in which it would describe new metrics to register. 176 An OBJECT IDENTITY assigned to a metric is definitive and cannot be 177 reused. If a new version of a metric is produced then it is assigned 178 with a new name and a new identifier. 180 5.2 Registration template 182 Following is a proposed template to insert in the IANA considerations 183 section. For each metric, that section would instanciate the 184 following statement: 186 IANA has registed the following metric in the 187 IANA-IPPM-METRICS-REGISTRY-MIB: 189 aNewMetricName OBJECT-IDENTITY 190 STATUS current 191 DESCRIPTION 192 "The identifier for a new metric." 193 REFERENCE 194 "Reference R, section n." 195 ::= { ianaIppmMetrics nn } -- IANA assigns nn 197 6. Initial IPPM registry definition 199 IANA-IPPM-METRICS-REGISTRY-MIB DEFINITIONS ::= BEGIN 201 IMPORTS 202 OBJECT-IDENTITY, MODULE-IDENTITY, mib-2 203 FROM SNMPv2-SMI; 205 ianaIppmMetricsRegistry MODULE-IDENTITY 206 LAST-UPDATED "200411300000Z" -- November 30th, 2004 207 ORGANIZATION "IANA" 208 CONTACT-INFO "Internet Assigned Numbers Authority 210 Postal: ICANN 211 4676 Admiralty Way, Suite 330 212 Marina del Rey, CA 90292 214 Tel: +1 310 823 9358 215 E-Mail: iana@iana.org" 217 DESCRIPTION 219 "This module defines a registry for IP Performance Metrics. 221 Registrations are done sequentially by IANA in the ianaIppmMetrics 222 subtree on the bases of 'Specification Required' as defined in 223 [RFC2434]. 225 The reference of the specification must point to a stable document 226 including a title, a revision and a date. 228 The name always starts with the name of the organization and must 229 respect the SMIv2 rules for descriptors defined in the section 3.1 230 of [RFC2578]; 232 A document that creates new metrics would have an IANA 233 considerations section in which it would describe new metrics to 234 register. 236 An OBJECT IDENTITY assigned to a metric is definitive and cannot 237 be reused. If a new version of a metric is produced then it is 238 assigned with a new name and a new identifier. 240 Copyright (C) The Internet Society (2004). The initial version of 241 this MIB module was published in RFC yyyy; for full legal notices 242 see the RFC itself or see: 243 http://www.ietf.org/copyrights/ianamib.html. " 244 -- RFC Ed.: replace yyyy with actual RFC number & remove this note 246 REVISION "200411300000Z" -- November 30th, 2004 247 DESCRIPTION 248 "Initial version of the IPPM metrics registry module. 249 This version published as RFC yyyy." 250 ::= { mib-2 XXX } -- XXX to be assigned by IANA 252 ianaIppmMetrics OBJECT-IDENTITY 253 STATUS current 254 DESCRIPTION 255 "Registration point for IP Performance Metrics." 256 ::= { ianaIppmMetricsRegistry 1 } 258 -- 259 -- Registry of the metrics of the IPPM WG RFCs 260 -- 261 -- 262 -- RFC 2678 " IPPM Metrics for Measuring Connectivity" 263 -- 265 ietfInstantUnidirConnectivity OBJECT-IDENTITY 266 STATUS current 267 DESCRIPTION 268 "Type-P-Instantaneous-Unidirectional-Connectivity" 269 REFERENCE "RFC2678, section 2." 270 ::= { ianaIppmMetrics 1} 272 ietfInstantBidirConnectivity OBJECT-IDENTITY 273 STATUS current 274 DESCRIPTION 275 "Type-P-Instantaneous-Bidirectional-Connectivity" 276 REFERENCE "RFC2678, section 3." 277 ::= { ianaIppmMetrics 2} 279 ietfIntervalUnidirConnectivity OBJECT-IDENTITY 280 STATUS current 281 DESCRIPTION 282 "Type-P-Interval-Unidirectional-Connectivity" 283 REFERENCE "RFC2678, section 4." 284 ::= { ianaIppmMetrics 3 } 286 ietfIntervalBidirConnectivity OBJECT-IDENTITY 287 STATUS current 288 DESCRIPTION 289 "Type-P-Interval-Bidirectional-Connectivity" 290 REFERENCE "RFC2678, section 5." 291 ::= { ianaIppmMetrics 4 } 293 ietfIntervalTemporalConnectivity OBJECT-IDENTITY 294 STATUS current 295 DESCRIPTION 296 "Type-P1-P2-Interval-Temporal-Connectivity" 297 REFERENCE "RFC2678, section 6." 298 ::= { ianaIppmMetrics 5 } 300 -- 301 -- RFC 2679 "A One-way Delay Metric for IPPM" 302 -- 304 ietfOneWayDelay OBJECT-IDENTITY 305 STATUS current 306 DESCRIPTION 307 "Type-P-One-way-Delay" 308 REFERENCE "RFC2679, section 3." 309 ::= { ianaIppmMetrics 6 } 311 ietfOneWayDelayPoissonStream OBJECT-IDENTITY 312 STATUS current 313 DESCRIPTION 314 "Type-P-One-way-Delay-Poisson-Stream" 315 REFERENCE "RFC2679, section 4." 316 ::= { ianaIppmMetrics 7 } 318 ietfOneWayDelayPercentile OBJECT-IDENTITY 319 STATUS current 320 DESCRIPTION 321 "Type-P-One-way-Delay-Percentile" 322 REFERENCE "RFC2679, section 5.1." 323 ::= { ianaIppmMetrics 8 } 325 ietfOneWayDelayMedian OBJECT-IDENTITY 326 STATUS current 327 DESCRIPTION 328 "Type-P-One-way-Delay-Median" 329 REFERENCE "RFC2679, section 5.2." 330 ::= { ianaIppmMetrics 9 } 332 ietfOneWayDelayMinimum OBJECT-IDENTITY 333 STATUS current 334 DESCRIPTION 335 "Type-P-One-way-Delay-Minimum" 336 REFERENCE "RFC2679, section 5.3." 337 ::= { ianaIppmMetrics 10 } 339 ietfOneWayDelayInversePercentile OBJECT-IDENTITY 340 STATUS current 341 DESCRIPTION 342 "Type-P-One-way-Delay-Inverse-Percentile" 343 REFERENCE "RFC2679, section 5.4." 344 ::= { ianaIppmMetrics 11 } 346 -- 347 -- RFC 2680 "One Way Packet Loss Metric for IPPM" 348 -- 350 ietfOneWayPktLoss OBJECT-IDENTITY 351 STATUS current 352 DESCRIPTION 353 "Type-P-One-way-Packet-Loss" 354 REFERENCE "RFC2680, section 2." 355 ::= { ianaIppmMetrics 12 } 357 ietfOneWayPktLossPoissonStream OBJECT-IDENTITY 358 STATUS current 359 DESCRIPTION 360 "Type-P-One-way-Packet-Loss-Poisson-Stream" 361 REFERENCE "RFC2680, section 3." 362 ::= { ianaIppmMetrics 13 } 364 ietfOneWayPktLossAverage OBJECT-IDENTITY 365 STATUS current 366 DESCRIPTION 367 "Type-P-One-way-Packet-Loss-Average" 368 REFERENCE "RFC2680, section 4." 369 ::= { ianaIppmMetrics 14 } 371 -- 372 -- RFC2681 "A Round-trip Delay Metric for IPPM" 373 -- 375 ietfRoundTripDelay OBJECT-IDENTITY 376 STATUS current 377 DESCRIPTION 378 "Type-P-Round-trip-Delay" 379 REFERENCE " section 2 of the rfc2681." 380 ::= { ianaIppmMetrics 15 } 382 ietfRoundTripDelayPoissonStream OBJECT-IDENTITY 383 STATUS current 384 DESCRIPTION 385 "Type-P-Round-trip-Delay-Poisson-Stream" 386 REFERENCE "RFC2681, section 4." 387 ::= { ianaIppmMetrics 16 } 389 ietfRoundTripDelayPercentile OBJECT-IDENTITY 390 STATUS current 391 DESCRIPTION 392 "Type-P-Round-trip-Delay-Percentile" 393 REFERENCE "RFC2681, section 4.1." 394 ::= { ianaIppmMetrics 17 } 396 ietfRoundTripDelayMedian OBJECT-IDENTITY 397 STATUS current 398 DESCRIPTION 399 "Type-P-Round-trip-Delay-Median" 400 REFERENCE "RFC2681, section 4.2." 401 ::= { ianaIppmMetrics 18 } 403 ietfRoundTripDelayMinimum OBJECT-IDENTITY 404 STATUS current 405 DESCRIPTION 406 "Type-P-Round-trip-Delay-Minimum" 407 REFERENCE "RFC2681, section 4.3." 408 ::= { ianaIppmMetrics 19 } 410 ietfRoundTripDelayInvPercentile OBJECT-IDENTITY 411 STATUS current 412 DESCRIPTION 413 "Type-P-Round-trip-Inverse-Percentile" 414 REFERENCE "RFC2681, section 4.4." 415 ::= { ianaIppmMetrics 20 } 417 -- 418 -- RFC3357: "One-way Loss Pattern Sample Metrics" 419 -- 421 ietfOneWayLossDistanceStream OBJECT-IDENTITY 422 STATUS current 423 DESCRIPTION 424 "Type-P-One-Way-Loss-Distance-Stream" 425 REFERENCE " RFC3357, section 5.4.1." 426 ::={ ianaIppmMetrics 21} 428 ietfOneWayLossPeriodStream OBJECT-IDENTITY 429 STATUS current 430 DESCRIPTION 431 "Type-P-One-Way-Loss-Period-Stream" 432 REFERENCE " RFC3357, section 5.4.2." 433 ::={ ianaIppmMetrics 22} 435 ietfOneWayLossNoticeableRate OBJECT-IDENTITY 436 STATUS current 437 DESCRIPTION 438 "Type-P-One-Way-Loss-Noticeable-Rate" 439 REFERENCE " RFC3357, section 6.1." 440 ::= { ianaIppmMetrics 23 } 442 ietfOneWayLossPeriodTotal OBJECT-IDENTITY 443 STATUS current 444 DESCRIPTION 445 "Type-P-One-Way-Loss-Period-Total" 446 REFERENCE " RFC3357, section 6.2." 447 ::= { ianaIppmMetrics 24 } 449 ietfOneWayLossPeriodLengths OBJECT-IDENTITY 450 STATUS current 451 DESCRIPTION 452 "Type-P-One-Way-Loss-Period-Lengths" 453 REFERENCE " RFC3357, section 6.3." 454 ::= { ianaIppmMetrics 25 } 456 ietfOneWayInterLossPeriodLengths OBJECT-IDENTITY 457 STATUS current 458 DESCRIPTION 459 "Type-P-One-Way-Inter-Loss-Period-Lengths" 460 REFERENCE " RFC3357, section 6.4." 461 ::= { ianaIppmMetrics 26 } 463 -- 464 -- RFC3393: 465 -- IP Packet Delay Variation Metric for IP Performance Metrics (IPPM) 467 ietfOneWayIpdv OBJECT-IDENTITY 468 STATUS current 469 DESCRIPTION 470 "Type-P-One-way-ipdv" 471 REFERENCE " RFC3393, section 2." 472 ::= { ianaIppmMetrics 27 } 474 ietfOneWayIpdvPoissonStream OBJECT-IDENTITY 475 STATUS current 476 DESCRIPTION 477 "Type-P-One-way-ipdv-Poisson-stream" 478 REFERENCE " RFC3393, section 3." 479 ::= { ianaIppmMetrics 28 } 481 ietfOneWayIpdvPercentile OBJECT-IDENTITY 482 STATUS current 483 DESCRIPTION 484 "Type-P-One-way-ipdv-percentile" 485 REFERENCE " RFC3393, section 4.3." 486 ::= { ianaIppmMetrics 29 } 488 ietfOneWayIpdvInversePercentile OBJECT-IDENTITY 489 STATUS current 490 DESCRIPTION 491 "Type-P-One-way-ipdv-inverse-percentile" 492 REFERENCE " RFC3393, section 4.4." 493 ::= { ianaIppmMetrics 30 } 495 ietfOneWayIpdvJitter OBJECT-IDENTITY 496 STATUS current 497 DESCRIPTION 498 "Type-P-One-way-ipdv-jitter" 499 REFERENCE " RFC3393, section 4.5." 500 ::= { ianaIppmMetrics 31 } 502 ietfOneWayPeakToPeakIpdv OBJECT-IDENTITY 503 STATUS current 504 DESCRIPTION 505 "Type-P-One-way-peak-to-peak-ipdv" 506 REFERENCE " RFC3393, section 4.6." 507 ::= { ianaIppmMetrics 32 } 509 -- 510 -- RFC3432: "Network performance measurement with periodic streams" 511 -- 513 ietfOneWayDelayPeriodicStream OBJECT-IDENTITY 514 STATUS current 515 DESCRIPTION 516 "Type-P-One-way-Delay-Periodic-Stream" 517 REFERENCE " RFC3432, section 4." 518 ::= { ianaIppmMetrics 33 } 520 END 522 7. Security Considerations 524 This module does not define any management objects. Instead, it 525 assigns a set of OBJECT-IDENTITIES which may be used by other MIB 526 modules to identify specific IP Performance Metrics. 528 Meaningful security considerations can only be written in the MIB 529 modules that define management objects. This document has therefore 530 no impact on the security of the Internet. 532 8. References 534 8.1 Normative References 536 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 537 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 538 October 1998. 540 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 541 McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of 542 Management Information Version 2 (SMIv2)", STD 58, RFC 543 2578, April 1999. 545 [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring 546 Connectivity", RFC 2678, September 1999. 548 [RFC2679] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way 549 Delay Metric for IPPM", RFC 2679, September 1999. 551 [RFC2680] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way 552 Packet Loss Metric for IPPM", RFC 2680, September 1999. 554 [RFC2681] Almes, G., Kalidindi, S. and M. Zekauskas, "A Round-trip 555 Delay Metric for IPPM", RFC 2681, September 1999. 557 [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample 558 Metrics", RFC 3357, August 2002. 560 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 561 Metric for IP Performance Metrics (IPPM)", RFC 3393, 562 November 2002. 564 [RFC3432] Raisanen, V., Grotefeld, G. and A. Morton, "Network 565 performance measurement with periodic streams", RFC 3432, 566 November 2002. 568 8.2 Informative References 570 [RFC2330] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, 571 "Framework for IP Performance Metrics", RFC 2330, May 572 1998. 574 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 575 McCloghrie, K., Rose, M. and S. Waldbusser, "Textual 576 Conventions for SMIv2", STD 58, RFC 2579, April 1999. 578 [RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, 579 "Conformance Statements for SMIv2", STD 58, RFC 2580, 580 April 1999. 582 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 583 "Introduction and Applicability Statements for 584 Internet-Standard Management Framework", RFC 3410, 585 December 2002. 587 Author's Address 589 Stephan Emile 590 France Telecom R & D 591 2 avenue Pierre Marzin 592 Lannion, F-22307 594 Fax: +33 2 96 05 18 52 595 EMail: emile.stephan@francetelecom.com 597 Intellectual Property Statement 599 The IETF takes no position regarding the validity or scope of any 600 Intellectual Property Rights or other rights that might be claimed to 601 pertain to the implementation or use of the technology described in 602 this document or the extent to which any license under such rights 603 might or might not be available; nor does it represent that it has 604 made any independent effort to identify any such rights. Information 605 on the procedures with respect to rights in RFC documents can be 606 found in BCP 78 and BCP 79. 608 Copies of IPR disclosures made to the IETF Secretariat and any 609 assurances of licenses to be made available, or the result of an 610 attempt made to obtain a general license or permission for the use of 611 such proprietary rights by implementers or users of this 612 specification can be obtained from the IETF on-line IPR repository at 613 http://www.ietf.org/ipr. 615 The IETF invites any interested party to bring to its attention any 616 copyrights, patents or patent applications, or other proprietary 617 rights that may cover technology that may be required to implement 618 this standard. Please address the information to the IETF at 619 ietf-ipr@ietf.org. 621 Disclaimer of Validity 623 This document and the information contained herein are provided on an 624 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 625 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 626 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 627 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 628 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 629 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 631 Copyright Statement 633 Copyright (C) The Internet Society (2004). This document is subject 634 to the rights, licenses and restrictions contained in BCP 78, and 635 except as set forth therein, the authors retain all their rights. 637 Acknowledgment 639 Funding for the RFC Editor function is currently provided by the 640 Internet Society.