idnits 2.17.1 draft-ietf-ippm-metrics-registry-05.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 2004) is 7406 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) == Missing Reference: 'RFC2119' is mentioned on line 75, but not defined == Missing Reference: 'RFC 2330' is mentioned on line 89, but not defined == Unused Reference: 'RFC2330' is defined on line 651, but no explicit reference was found in the text -- 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: 4 errors (**), 0 flaws (~~), 4 warnings (==), 4 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-05.txt January 2004 5 Category: Standards Track 7 IPPM metrics registry 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026 [RFC2026]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This memo defines a registry of the IPPM working group metrics. It 31 assigns an OBJECT IDENTIFIER to each metric currently standardized by 32 the IPPM WG. It defines the rules for the identification of the 33 metrics standardized in the future. 35 Table of Contents 37 1. The Internet-Standard Management Framework...................2 38 2. Terms........................................................2 39 3. Overview.....................................................2 40 4. The IPPM Framework...........................................2 41 5. Overview.....................................................3 42 6. IPPM metrics Registry framework..............................3 43 6.1. Metrics registry template....................................4 44 6.2. Initial IPPM metrics registry creation.......................5 45 6.3. Future IPPM metrics registration.............................6 46 6.4. Metric defined in cooperation with other bodies..............6 47 7. Initial IPPM registry definition.............................6 48 8. Intellectual Property.......................................13 49 9. Acknowledgments.............................................13 50 10. Normative References........................................13 51 11. Informative References......................................14 52 12. Security Considerations.....................................14 53 13. Author's Addresses..........................................15 54 14. Full Copyright Statement....................................15 56 1. The Internet-Standard Management Framework 58 For a detailed overview of the documents that describe the current 59 Internet-Standard Management Framework, please refer to section 7 of 60 RFC 3410 [RFC3410]. Managed objects are accessed via a virtual 61 information store, termed the Management Information Base or MIB. 62 MIB objects are generally accessed through the Simple Network 63 Management Protocol (SNMP). Objects in the MIB are defined using the 64 mechanisms defined in the Structure of Management Information (SMI). 65 This memo specifies a MIB module that is compliant to the SMIv2, 66 which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 67 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 69 2. Terms 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in BCP 14, RFC 2119 74 [RFC2119]. 76 3. Overview 78 This memo defines a registry of the IPPM working group metrics. It 79 assigns an OBJECT IDENTIFIER to each metric currently standardized by 80 the IPPM WG. It defines the rules for the identification of the 81 metrics standardized in the future. 83 4. The IPPM Framework 85 The IPPM Framework consists in four major components: 87 + A general framework for defining performance metrics 88 described in the Framework for IP Performance Metrics RFC2330 89 [RFC 2330]; 91 + A set of standardized metrics, which conform to this 92 framework. 94 + Emerging metrics which are being specified in respect of this 95 framework; 97 + The IPPM-REPORTING-MIB for reporting the results of the 98 measures and for interfacing heterogeneous measurement systems 99 with management entities. 101 5. Overview 103 This memo defines a registry of the current metrics and a framework 104 for the integration of future metrics for the following reasons: 106 + to permit metrics to be clearly referenced by MIBs or other data 107 models; 109 + Metrics identifiers are needed to allow measurement 110 interoperability; 112 + As specification of new metrics is a continuous process, special 113 care must be taken for the integration of future standardized 114 metrics; 116 + As the intent of the IPPM WG is to cooperate with other 117 appropriate standards bodies and other areas of IETF to promote 118 consistent metrics, there is a need to permit registration of 119 such metrics. 121 6. IPPM metrics Registry framework 123 MIBs need OBJECT INDENTIFIERs to refer precisely to the standardized 124 metrics. The registry associates an OBJECT IDENTIFIER with each 125 metric. As an example oneWayDelay and oneWayDelayPoissonStream have 126 different identifiers. 128 The registry has 2 root branches. The category of the document 129 determines the node which branch the metric is identified in: 131 + Metrics defined in a RFC are identified in the 'rfc' tree; 132 + Metrics defined in cooperation with other bodies may be 133 identified in the 'otherBodies' tree. 135 The name of the metric in the registry must respect the SMIv2 rules 136 for descriptors ([RFC2578], section 3.1) and should be easily 137 readable. Consequently the following is applied to adapt the name 138 used in the metric definition: 140 + The first letter is forced to lower case; 141 + '-' are removed; 142 + The letter following a '-' is forced to upper case; 143 + 'Type-P' prefix is removed. 145 This document defines an initial registry of the existing metrics. 146 Documents defining metrics in the future will include a registry 147 section to clearly identify these metrics. 149 6.1. Metrics registry template 151 Each memo includes a registry which identifies the metrics. The 152 registry is defined using a MODULE-IDENTITY macro. The name of the 153 module must be unique. Each metric is identified in the registry 154 using an OBJECT-IDENTITY macro defining the metric name, status, 155 reference and OBJECT IDENTIFIER. 157 The registry is defined in a dedicated section of the memo. 159 As an example, consider an improbable IPPM WG draft that defines 4 160 metrics in the sections 4, 4.1, 4.2 and 4.3, respectively: 162 + Type-P-Packet-Speed metric; 163 + Type-P-Average-Packet-Speed metric; 164 + Type-P-Minimum-Packet-Speed metric; 165 + Type-P-Maximum-Packet-Speed metric. 167 Following is the registry that may be included in the document: 169 + The name of the section is 'IPPM Packet Speed metrics registry'; 170 + The name of the module is ippmPacketSpeedMetricsRegistry; 171 + 'N' is the node assigned by IANA to the registry module; 172 + The next free node of the sub tree ippmMetricsRegistry.rfc(1) is 173 '34'. 175 IPPM-PACKET-SPEED-METRICS-REGISTRY DEFINITIONS ::= BEGIN 177 IMPORTS 178 OBJECT-IDENTITY, MODULE-IDENTITY, mib-2 179 FROM SNMPv2-SMI 180 rfc 181 FROM IPPM-METRICS-REGISTRY; 183 ippmPacketSpeedMetricsRegistry MODULE-IDENTITY 184 LAST-UPDATED "YYYYMMDD0000Z" 185 ORGANIZATION "IETF IPPM working Group" 186 CONTACT-INFO " 188 Tel: 189 E-mail: 190 Postal: 192 Send comments to 193 Mailing list subscription info: 194 https://www1.ietf.org/mailman/listinfo/ippm " 195 DESCRIPTION 196 " This memo defines the registry for IPPM Packet Speed metrics. 198 Copyright (C) The Internet Society (2003). 200 This version of this MIB module is part of RFC yyyy; see the 201 RFC itself for full legal notices." 202 REVISION "YYYYMMDD0000Z" 203 DESCRIPTION 204 "Initial version of the module of the registry for IPPM Packet 205 Speed metrics. 206 This version published as RFC yyyy." 207 ::= { mib-2 N } 209 ippmPacketSpeedMetric OBJECT-IDENTITY 210 STATUS current 211 DESCRIPTION 212 "The identifier for the Type-P-Packet-Speed metric." 213 REFERENCE "RFCyyyy, section 4." 214 ::= { rfc 34 } 216 ippmAvgPacketSpeedmetric OBJECT-IDENTITY 217 STATUS current 218 DESCRIPTION 219 "The identifier for the Type-P-Average-Packet-Speed metric." 220 REFERENCE "RFCyyyy, section 4.1." 221 ::= { rfc 35 } 223 ippmMinPacketSpeedmetric OBJECT-IDENTITY 224 STATUS current 225 DESCRIPTION 226 "The identifier for the Type-P-Minimum-Packet-Speed metric." 227 REFERENCE "RFCyyyy, section 4.2." 228 ::= { rfc 36 } 230 ippmMaxPacketSpeedmetric OBJECT-IDENTITY 231 STATUS current 232 DESCRIPTION 233 "The identifier for the Type-P-Maximum-Packet-Speed metric." 234 REFERENCE "RFCyyyy, section 4.3." 235 ::= { rfc 37 } 237 END 239 6.2. Initial IPPM metrics registry creation 240 The initial registry identifies the metrics currently defined in the 241 RFCs produced in the IPPM WG. 243 By now, the IPPM WG defined 33 metrics related to 7 topics: 245 + IPPM Metrics for Measuring Connectivity, RFC 2678 [RFC2678]; 246 + One-way Delay Metrics, RFC 2679 [RFC2679]; 247 + One-way Packet Loss Metrics, RFC 2680 [RFC2680]; 248 + Round-trip Delay Metrics, RFC 2681 [RFC2681]; 249 + One-way Loss Pattern Sample Metrics, RFC 3357 [RFC3357]; 250 + IP Packet Delay Variation Metric, RFC 3393 [RFC3393]; 251 + IPPM Metrics for periodic streams, RFC 3432 [RFC3432]; 253 They are registered in the node rfc(1). They are numbered using the RFC 254 order and the metrics definitions order in each memo. The node assigned 255 to a metric is definitive and cannot be reused. 257 6.3. Future IPPM metrics registration 259 When the IPPM WG draft is considered mature enough: 261 + The chair of the IPPM WG, or someone proposed by the directors 262 of the Transport Area, assigns to each metric a sub node chosen 263 in the tree rfc(1) of the IPPM-METRICS-REGISTRY; 265 + Authors insert a registry template in their document. Then they 266 create an OBJECT-IDENTITY instance per metric and complete the 267 instance with the assigned sub nodes. 269 That helps to prepare the final version of the draft. Moreover it 270 facilitates software integration and interoperability measurement 271 during the specification process. 273 6.4. Metric defined in cooperation with other bodies 275 Such metrics may be registered in the node otherBodies(2). 277 Nothing prevents these bodies from registering metrics in their own 278 object identifier trees. 280 7. Initial IPPM registry definition 282 IPPM-METRICS-REGISTRY DEFINITIONS ::= BEGIN 284 IMPORTS 285 OBJECT-IDENTITY, MODULE-IDENTITY, mib-2 286 FROM SNMPv2-SMI; 288 ippmMetricsRegistry MODULE-IDENTITY 289 LAST-UPDATED "200304170000Z" -- April 17th, 2003 290 ORGANIZATION "IETF IPPM working Group" 291 CONTACT-INFO " 292 Emile STEPHAN 293 France Telecom R&D 294 Tel: +1 33 2 96 05 36 10 295 E-mail: emile.stephan@francetelecom.com 296 Postal: 2, avenue Pierre Marzin 297 Lannion, FRANCE 22307 299 Send comments to 300 Mailing list subscription info: 301 https://www1.ietf.org/mailman/listinfo/ippm " 302 DESCRIPTION 303 "This memo defines a registry of the IPPM working group 304 metrics. 306 Copyright (C) The Internet Society (2003). This version of this 307 MIB module is part of RFC yyyy; see the RFC itself for full 308 legal notices." 309 REVISION "200304170000Z" -- April 17th, 2003 310 DESCRIPTION 311 "Initial version of the IPPM metrics registry module. 312 This version published as RFC yyyy." 313 ::= { mib-2 XXX } -- XXX to be assigned by IANA 315 rfc OBJECT IDENTIFIER ::= { ippmMetricsRegistry 1 } 316 otherBodies OBJECT IDENTIFIER ::= { ippmMetricsRegistry 2 } 318 -- 319 -- Registry of the metrics of the IPPM WG RFCs 320 -- 322 -- 323 -- RFC 2678 " IPPM Metrics for Measuring Connectivity" 324 -- 326 instantUnidirectionConnectivity OBJECT-IDENTITY 327 STATUS current 328 DESCRIPTION 329 "The identifier for the Type-P-Instantaneous-Unidirectional- 330 Connectivity metric." 331 REFERENCE "RFC2678, section 2." 332 ::={rfc 1} 334 instantBidirectionConnectivity OBJECT-IDENTITY 335 STATUS current 336 DESCRIPTION 337 "The identifier for the Type-P-Instantaneous-Bidirectional- 338 Connectivity metric." 339 REFERENCE "RFC2678, section 3." 340 ::={rfc 2} 342 intervalUnidirectionConnectivity OBJECT-IDENTITY 343 STATUS current 344 DESCRIPTION 345 "The identifier for the Type-P-Interval-Unidirectional- 346 Connectivity metric." 347 REFERENCE "RFC2678, section 4." 348 ::= { rfc 3 } 350 intervalBidirectionConnectivity OBJECT-IDENTITY 351 STATUS current 352 DESCRIPTION 353 "The identifier for the Type-P-Interval-Bidirectional- 354 Connectivity metric." 355 REFERENCE "RFC2678, section 5." 356 ::= { rfc 4 } 358 intervalTemporalConnectivity OBJECT-IDENTITY 359 STATUS current 360 DESCRIPTION 361 "The identifier for the Type-P1-P2-Interval-Temporal- 362 Connectivity metric." 363 REFERENCE "RFC2678, section 6." 364 ::= { rfc 5 } 366 -- 367 -- RFC 2679 "A One-way Delay Metric for IPPM" 368 -- 370 oneWayDelay OBJECT-IDENTITY 371 STATUS current 372 DESCRIPTION 373 "The identifier for the Type-P-One-way-Delay metric." 374 REFERENCE "RFC2679, section 3." 375 ::= { rfc 6 } 377 oneWayDelayPoissonStream OBJECT-IDENTITY 378 STATUS current 379 DESCRIPTION 380 "The identifier for the Type-P-One-way-Delay-Poisson-Stream 381 metric." 382 REFERENCE "RFC2679, section 4." 383 ::= { rfc 7 } 385 oneWayDelayPercentile OBJECT-IDENTITY 386 STATUS current 387 DESCRIPTION 388 "The identifier for the Type-P-One-way-Delay-Percentile 389 metric." 390 REFERENCE "RFC2679, section 5.1." 391 ::= { rfc 8 } 393 oneWayDelayMedian OBJECT-IDENTITY 394 STATUS current 395 DESCRIPTION 396 "The identifier for the Type-P-One-way-Delay-Median metric." 397 REFERENCE "RFC2679, section 5.2." 398 ::= { rfc 9 } 400 oneWayDelayMinimum OBJECT-IDENTITY 401 STATUS current 402 DESCRIPTION 403 "The identifier for the Type-P-One-way-Delay-Minimum metric." 404 REFERENCE "RFC2679, section 5.3." 405 ::= { rfc 10 } 407 oneWayDelayInversePercentile OBJECT-IDENTITY 408 STATUS current 409 DESCRIPTION 410 "The identifier for the Type-P-One-way-Delay-Inverse-Percentile 411 metric. " 412 REFERENCE "RFC2679, section 5.4." 413 ::= { rfc 11 } 415 -- 416 -- RFC 2680 "One Way Packet Loss Metric for IPPM" 417 -- 419 oneWayPacketLoss OBJECT-IDENTITY 420 STATUS current 421 DESCRIPTION 422 "The identifier for the Type-P-One-way-Packet-Loss metric." 423 REFERENCE "RFC2680, section 2." 424 ::= { rfc 12 } 426 oneWayPacketLossPoissonStream OBJECT-IDENTITY 427 STATUS current 428 DESCRIPTION 429 "The identifier for the Type-P-One-way-Packet-Loss-Poisson- 430 Stream metric." 431 REFERENCE "RFC2680, section 3." 432 ::= { rfc 13 } 434 oneWayPacketLossAverage OBJECT-IDENTITY 435 STATUS current 436 DESCRIPTION 437 "The identifier for the Type-P-One-way-Packet-Loss-Average 438 metric." 439 REFERENCE "RFC2680, section 4." 440 ::= { rfc 14 } 442 -- 443 -- RFC2681 "A Round-trip Delay Metric for IPPM" 444 -- 446 roundtripDelay OBJECT-IDENTITY 447 STATUS current 448 DESCRIPTION 449 "The identifier for the Type-P-Round-trip-Delay metric." 450 REFERENCE " section 2 of the rfc2681." 451 ::= { rfc 15 } 453 roundtripDelayPoissonStream OBJECT-IDENTITY 454 STATUS current 455 DESCRIPTION 456 "The identifier for the Type-P-Round-trip-Delay-Poisson-Stream 457 metric." 458 REFERENCE "RFC2681, section 4." 459 ::= { rfc 16 } 461 roundtripDelayPercentile OBJECT-IDENTITY 462 STATUS current 463 DESCRIPTION 464 "The identifier for the Type-P-Round-trip-Delay-Percentile 465 metric." 466 REFERENCE "RFC2681, section 4.1." 467 ::= { rfc 17 } 469 roundtripDelayMedian OBJECT-IDENTITY 470 STATUS current 471 DESCRIPTION 472 "The identifier for the Type-P-Round-trip-Delay-Median metric." 473 REFERENCE "RFC2681, section 4.2." 474 ::= { rfc 18 } 476 roundtripDelayMinimum OBJECT-IDENTITY 477 STATUS current 478 DESCRIPTION 479 "The identifier for the Type-P-Round-trip-Delay-Minimum 480 metric." 481 REFERENCE "RFC2681, section 4.3." 482 ::= { rfc 19 } 484 roundtripDelayInversePercentile OBJECT-IDENTITY 485 STATUS current 486 DESCRIPTION 487 "The identifier for the Type-P-Round-trip-Inverse-Percentile 488 metric." 489 REFERENCE "RFC2681, section 4.4." 490 ::= { rfc 20 } 492 -- 493 -- RFC3357: "One-way Loss Pattern Sample Metrics" 494 -- 495 oneWayLossDistanceStream OBJECT-IDENTITY 496 STATUS current 497 DESCRIPTION 498 "The identifier for the Type-P-One-Way-Loss-Distance-Stream 499 metric." 500 REFERENCE " RFC3357, section 5.4.1." 501 ::={ rfc 21} 503 oneWayLossPeriodStream OBJECT-IDENTITY 504 STATUS current 505 DESCRIPTION 506 "The identifier for the Type-P-One-Way-Loss-Period-Stream 507 metric." 508 REFERENCE " RFC3357, section 5.4.2." 509 ::={ rfc 22} 511 oneWayLossNoticeableRate OBJECT-IDENTITY 512 STATUS current 513 DESCRIPTION 514 "The identifier for the Type-P-One-Way-Loss-Noticeable-Rate 515 metric." 516 REFERENCE " RFC3357, section 6.1." 517 ::= { rfc 23 } 519 oneWayLossPeriodTotal OBJECT-IDENTITY 520 STATUS current 521 DESCRIPTION 522 "The identifier for the Type-P-One-Way-Loss-Period-Total 523 metric." 524 REFERENCE " RFC3357, section 6.2." 525 ::= { rfc 24 } 527 oneWayLossPeriodLengths OBJECT-IDENTITY 528 STATUS current 529 DESCRIPTION 530 "The identifier for the Type-P-One-Way-Loss-Period-Lengths 531 metric." 532 REFERENCE " RFC3357, section 6.3." 533 ::= { rfc 25 } 535 oneWayInterLossPeriodLengths OBJECT-IDENTITY 536 STATUS current 537 DESCRIPTION 538 "The identifier for the Type-P-One-Way-Inter-Loss-Period- 539 Lengths metric." 540 REFERENCE " RFC3357, section 6.4." 541 ::= { rfc 26 } 543 -- 544 -- RFC3393: 545 -- "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)" 547 oneWayIpdv OBJECT-IDENTITY 548 STATUS current 549 DESCRIPTION 550 "The identifier for the Type-P-One-way-ipdv metric." 551 REFERENCE " RFC3393, section 2." 552 ::= { rfc 27 } 554 oneWayIpdvPoissonStream OBJECT-IDENTITY 555 STATUS current 556 DESCRIPTION 557 "The identifier for the Type-P-One-way-ipdv-Poisson-stream 558 metric." 559 REFERENCE " RFC3393, section 3." 560 ::= { rfc 28 } 562 oneWayIpdvPercentile OBJECT-IDENTITY 563 STATUS current 564 DESCRIPTION 565 "The identifier for the Type-P-One-way-ipdv-percentile metric." 566 REFERENCE " RFC3393, section 4.3." 567 ::= { rfc 29 } 569 oneWayIpdvInversePercentile OBJECT-IDENTITY 570 STATUS current 571 DESCRIPTION 572 "The identifier for the Type-P-One-way-ipdv-inverse-percentile 573 metric." 574 REFERENCE " RFC3393, section 4.4." 575 ::= { rfc 30 } 577 oneWayIpdvJitter OBJECT-IDENTITY 578 STATUS current 579 DESCRIPTION 580 "The identifier for the Type-P-One-way-ipdv-jitter metric." 581 REFERENCE " RFC3393, section 4.5." 582 ::= { rfc 31 } 584 oneWayPeakToPeakIpdv OBJECT-IDENTITY 585 STATUS current 586 DESCRIPTION 587 "The identifier for the Type-P-One-way-peak-to-peak-ipdv 588 metric." 589 REFERENCE " RFC3393, section 4.6." 590 ::= { rfc 32 } 592 -- 593 -- RFC3432: "Network performance measurement with periodic streams" 594 -- 595 oneWayDelayPeriodicStream OBJECT-IDENTITY 596 STATUS current 597 DESCRIPTION 598 "The identifier for the Type-P-One-way-Delay-Periodic-Stream 599 metric." 600 REFERENCE " RFC3432, section 4." 601 ::= { rfc 33 } 603 END 605 8. Intellectual Property 607 The IETF takes no position regarding the validity or scope of any 608 intellectual property or other rights that might be claimed to 609 pertain to the implementation or use of the technology described in 610 this document or the extent to which any license under such rights 611 might or might not be available; neither does it represent that it 612 has made any effort to identify any such rights. Information on the 613 IETF's procedures with respect to rights in standards-track and 614 standards-related documentation can be found in BCP-11. Copies of 615 claims of rights made available for publication and any assurances of 616 licenses to be made available, or the result of an attempt made to 617 obtain a general license or permission for the use of such 618 proprietary rights by implementors or users of this specification can 619 be obtained from the IETF Secretariat. 621 The IETF invites any interested party to bring to its attention any 622 copyrights, patents or patent applications, or other proprietary 623 rights which may cover technology that may be required to practice 624 this standard. Please address the information to the IETF Executive 625 Director. 627 9. Acknowledgments 629 The author gratefully acknowledges Andy Bierman and Randy Presuhn for 630 their guidance and comments. 632 10. Normative References 634 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 635 Rose, M. and S. Waldbusser, "Structure of Management Information 636 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 638 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 639 Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 640 58, RFC 2579, April 1999. 642 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 643 Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", 644 STD 58, RFC 2580, April 1999. 646 11. Informative References 648 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 649 3", BCP 9, RFC 2026, October 1996. 651 [RFC2330] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, 652 "Framework for IP Performance Metrics", RFC 2330, May 1998. 654 [RFC2678] Mahdavi J. and V. Paxson, "IPPM Metrics for Measuring 655 Connectivity", RFC 2678, September 1999. 657 [RFC2679] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way 658 Delay Metric for IPPM", RFC 2679, September 1999. 660 [RFC2680] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way 661 Packet Loss Metric for IPPM", RFC 2680, September 1999. 663 [RFC2681] Almes, G., Kalidindi, S. and M. Zekauskas, "A Round-trip 664 Delay Metric for IPPM", RFC 2681, September 1999. 666 [RFC3357] Koodli, R. and Ravikanth, R., "One-way Loss Pattern Sample 667 Metrics", RFC 3357, August 2002. 669 [RFC3393] Demichelis, C. and P. Chimento, " IP Packet Delay Variation 670 Metric for IP Performance Metrics (IPPM)", RFC 3393, November 671 2002. 673 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 674 "Introduction and Applicability Statements for Internet Standard 675 Management Framework", RFC 3410, December 2002. 677 [RFC3432] Raisanen, V., Grotefeld, G. and A. Morton, "Network 678 performance measurement with periodic streams", RFC 3432, November 679 2002. 681 12. Security Considerations 683 All the items specified in this MIB module are defined using the 684 macro OBJECT-IDENTITY. This macro does not have a MAX-ACCESS clause. 686 There are no management objects defined in this MIB module that have 687 a MAX-ACCESS clause of read-write and/or read-create. So, if this 688 MIB module is implemented correctly, then there is no risk that an 689 intruder can alter or create any management objects of this MIB 690 module via direct SNMP SET operations. 692 It is RECOMMENDED that implementers consider the security features as 693 provided by the SNMPv3 framework (see [RFC3410], section 8), 694 including full support for the SNMPv3 cryptographic mechanisms (for 695 authentication and privacy). 697 Further, deployment of SNMP versions prior to SNMPv3 is NOT 698 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 699 enable cryptographic security. It is then a customer/operator 700 responsibility to ensure that the SNMP entity giving access to an 701 instance of this MIB module is properly configured to give access to 702 the objects only to those principals (users) that have legitimate 703 rights to indeed GET or SET (change/create/delete) them. 705 13. Author's Address 707 Emile STEPHAN 708 France Telecom R&D 709 2, avenue Pierre Marzin 710 F-22307 Lannion cedex 711 Phone: + 33 2 96 05 36 10 712 Email: emile.stephan@francetelecom.com 714 14. Full Copyright Statement 716 Copyright (C) The Internet Society (2003). All Rights Reserved. 718 This document and translations of it may be copied and furnished to 719 others, and derivative works that comment on or otherwise explain it 720 or assist its implementation may be prepared, copied, published and 721 distributed, in whole or in part, without restriction of any kind, 722 provided that the above copyright notice and this paragraph are 723 included on all such copies and derivative works. However, this 724 document itself may not be modified in any way, such as by removing 725 the copyright notice or references to the Internet Society or other 726 Internet organizations, except as needed for the purpose of 727 developing Internet standards in which case the procedures for 728 copyrights defined in the Internet Standards process must be 729 followed, or as required to translate it into languages other than 730 English. 732 The limited permissions granted above are perpetual and will not be 733 revoked by the Internet Society or its successors or assigns. 735 This document and the information contained herein is provided on an 736 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 737 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 738 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 739 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 740 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.