idnits 2.17.1 draft-ietf-ippm-metrics-registry-03.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? == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 8) being 59 lines == 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 : ---------------------------------------------------------------------------- ** 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.) ** There is 1 instance of too long lines in the document, the longest one being 8 characters in excess of 72. ** There are 320 instances of lines with control characters in the document. 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 (April 2003) is 7654 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 650, 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: 6 errors (**), 0 flaws (~~), 6 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-03.txt April 2003 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; 96 + The IPPM-REPORTING-MIB for reporting the results of the 97 measures and for interfacing heterogeneous measurement systems 98 with management entities. 100 5. Overview 102 This memo defines a registry of the current metrics and a framework 103 for the integration of future metrics for the following reasons: 105 + to permit metrics to be clearly referenced by MIBs or other 106 data models; 108 + Metrics identifiers are needed to allow measurement 109 interoperability; 111 + As specification of new metrics is a continuous process, 112 special care must be taken for the integration of future 113 standardized metrics; 115 + As the intent of the IPPM WG is to cooperate with other 116 appropriate standards bodies and other areas of IETF to promote 117 consistent metrics, there is a need to permit registration of 118 such metrics. 120 6. IPPM metrics Registry framework 122 MIBs need OBJECT INDENTIFIERs to refer precisely to the standardized 123 metrics. The registry associates an OBJECT IDENTIFIER with each 124 metric. As an example oneWayDelay and oneWayDelayPoissonStream have 125 different identifiers. 127 The registry has 2 root branches. The category of the document 128 determines the node which branch the metric is identified in: 130 + Metrics defined in a RFC are identified in the 'rfc' tree; 131 + Metrics defined in cooperation with other bodies may be 132 identified in the 'otherBodies' tree. 134 The name of the metric in the registry must respect the SMIv2 rules 135 for descriptors ([RFC2578], section 3.1) and should be easily 136 readable. Consequently the following is applied to adapt the name 137 used in the metric definition: 139 + The first letter is forced to lower case; 140 + '-' are removed; 141 + The letter following a '-' is forced to upper case; 142 + 'Type-P' prefix is removed. 144 This document defines an initial registry of the existing metrics. 145 Documents defining metrics in the future will include a registry 146 section to clearly identify these metrics. 148 6.1. Metrics registry template 150 Each memo includes a registry which identifies the metrics. The 151 registry is defined using a MODULE-IDENTITY macro. The name of the 152 module must be unique. Each metric is identified in the registry 153 using an OBJECT-IDENTITY macro defining the metric name, status, 154 reference and OBJECT IDENTIFIER. 156 The registry is defined in a dedicated section of the memo. 158 As an example, consider an improbable IPPM WG draft that defines 4 159 metrics in the sections 4, 4.1, 4.2 and 4.3, respectively: 161 + Type-P-Packet-Speed metric; 162 + Type-P-Average-Packet-Speed metric; 163 + Type-P-Minimum-Packet-Speed metric; 164 + Type-P-Maximum-Packet-Speed metric. 166 Following is the registry that may be included in the document: 168 + The name of the section is 'IPPM Packet Speed metrics registry'; 169 + The name of the module is ippmPacketSpeedMetricsRegistry; 170 + 'N' is the node assigned by IANA to the registry module; 171 + The next free node of the sub tree ippmMetricsRegistry.rfc(1) is 172 '34'. 174 IPPM-PACKET-SPEED-METRICS-REGISTRY DEFINITIONS ::= BEGIN 176 IMPORTS 177 OBJECT-IDENTITY, MODULE-IDENTITY, mib-2 178 FROM SNMPv2-SMI 179 rfc 180 FROM IPPM-METRICS-REGISTRY; 182 ippmPacketSpeedMetricsRegistry MODULE-IDENTITY 183 LAST-UPDATED "YYYYMMDD0000Z" 184 ORGANIZATION "IETF IPPM working Group" 185 CONTACT-INFO " 187 Tel: 188 E-mail: 189 Postal: 191 Send comments to 192 Mailing list subscription info: 193 https://www1.ietf.org/mailman/listinfo/ippm " 194 DESCRIPTION 195 " This memo defines the registry for IPPM Packet Speed metrics. 197 Copyright (C) The Internet Society (2002). 199 This version of this MIB module is part of RFC yyyy; see the 200 RFC itself for full legal notices." 201 REVISION "YYYYMMDD0000Z" 202 DESCRIPTION 203 "Initial version of the module of the registry for IPPM Packet 204 Speed metrics. 205 This version published as RFC yyyy." 206 ::= { mib-2 N } 208 ippmPacketSpeedMetric OBJECT-IDENTITY 209 STATUS current 210 DESCRIPTION 211 "The identifier for the Type-P-Packet-Speed metric." 212 REFERENCE "RFCyyyy, section 4." 213 ::= { rfc 34 } 215 ippmAvgPacketSpeedmetric OBJECT-IDENTITY 216 STATUS current 217 DESCRIPTION 218 "The identifier for the Type-P-Average-Packet-Speed metric." 219 REFERENCE "RFCyyyy, section 4.1." 220 ::= { rfc 35 } 222 ippmMinPacketSpeedmetric OBJECT-IDENTITY 223 STATUS current 224 DESCRIPTION 225 "The identifier for the Type-P-Minimum-Packet-Speed metric." 226 REFERENCE "RFCyyyy, section 4.2." 227 ::= { rfc 36 } 229 ippmMaxPacketSpeedmetric OBJECT-IDENTITY 230 STATUS current 231 DESCRIPTION 232 "The identifier for the Type-P-Maximum-Packet-Speed metric." 233 REFERENCE "RFCyyyy, section 4.3." 234 ::= { rfc 37 } 236 END 238 6.2. Initial IPPM metrics registry creation 239 The initial registry identifies the metrics currently defined in the 240 RFCs produced in the IPPM WG. 242 By now, the IPPM WG defined 33 metrics related to 7 topics: 244 + IPPM Metrics for Measuring Connectivity, RFC 2678 [RFC2678]; 245 + One-way Delay Metrics, RFC 2679 [RFC2679]; 246 + One-way Packet Loss Metrics, RFC 2680 [RFC2680]; 247 + Round-trip Delay Metrics, RFC 2681 [RFC2681]; 248 + One-way Loss Pattern Sample Metrics, RFC 3357 [RFC3357]; 249 + IP Packet Delay Variation Metric, RFC 3393 [RFC3393]; 250 + IPPM Metrics for periodic streams, RFC 3432 [RFC3432]; 252 They are registered in the node rfc(1). They are numbered using the RFC 253 order and the metrics definitions order in each memo. The node assigned 254 to a metric is definitive and cannot be reused. 256 6.3. Future IPPM metrics registration 258 When the IPPM WG draft is considered mature enough: 260 + The chair of the IPPM WG, or someone proposed by the directors of 261 the Transport Area, assigns to each metric a sub node chosen in the 262 tree rfc(1) of the IPPM-METRICS-REGISTRY; 264 + Authors insert a registry template in their document. Then they 265 create an OBJECT-IDENTITY instance per metric and complete the 266 instance with the assigned sub nodes. 268 That helps to prepare the final version of the draft. Moreover it 269 facilitates software integration and interoperability measurement 270 during the specification process. 272 6.4. Metric defined in cooperation with other bodies 274 Such metrics may be registered in the node otherBodies(2). 276 Nothing prevents these bodies from registering metrics in their own 277 object identifier trees. 279 7. Initial IPPM registry definition 281 IPPM-METRICS-REGISTRY DEFINITIONS ::= BEGIN 283 IMPORTS 284 OBJECT-IDENTITY, MODULE-IDENTITY, mib-2 285 FROM SNMPv2-SMI; 287 ippmMetricsRegistry MODULE-IDENTITY 288 LAST-UPDATED "200304160000Z" -- April 16th, 2003 289 ORGANIZATION "IETF IPPM working Group" 290 CONTACT-INFO " 291 Emile STEPHAN 292 France Telecom R & D 293 Tel: +1 33 2 96 05 36 10 294 E-mail: emile.stephan@francetelecom.com 295 Postal: 2, avenue Pierre Marzin 296 Lannion, FRANCE 22307 298 Send comments to 299 Mailing list subscription info: 300 https://www1.ietf.org/mailman/listinfo/ippm " 301 DESCRIPTION 302 "This memo defines a registry of the IPPM working group 303 metrics. 305 Copyright (C) The Internet Society (2002). This version of this 306 MIB module is part of RFC yyyy; see the RFC itself for full 307 legal notices." 308 REVISION "200304160000Z" -- April 16th, 2003 309 DESCRIPTION 310 "Initial version of the IPPM metrics registry module. 311 This version published as RFC yyyy." 312 ::= { mib-2 XXX } 314 rfc OBJECT IDENTIFIER ::= { ippmMetricsRegistry 1 } 315 otherBodies OBJECT IDENTIFIER ::= { ippmMetricsRegistry 2 } 317 -- 318 -- Registry of the metrics of the IPPM WG RFCs 319 -- 321 -- 322 -- RFC 2678 " IPPM Metrics for Measuring Connectivity" 323 -- 325 instantUnidirectionConnectivity OBJECT-IDENTITY 326 STATUS current 327 DESCRIPTION 328 "The identifier for the Type-P-Instantaneous-Unidirectional- 329 Connectivity metric." 330 REFERENCE "RFC2678, section 2." 331 ::={rfc 1} 333 instantBidirectionConnectivity OBJECT-IDENTITY 334 STATUS current 335 DESCRIPTION 336 "The identifier for the Type-P-Instantaneous-Bidirectional- 337 Connectivity metric." 338 REFERENCE "RFC2678, section 3." 339 ::={rfc 2} 341 intervalUnidirectionConnectivity OBJECT-IDENTITY 342 STATUS current 343 DESCRIPTION 344 "The identifier for the Type-P-Interval-Unidirectional- 345 Connectivity metric." 346 REFERENCE "RFC2678, section 4." 347 ::= { rfc 3 } 349 intervalBidirectionConnectivity OBJECT-IDENTITY 350 STATUS current 351 DESCRIPTION 352 "The identifier for the Type-P-Interval-Bidirectional- 353 Connectivity metric." 354 REFERENCE "RFC2678, section 5." 355 ::= { rfc 4 } 357 intervalTemporalConnectivity OBJECT-IDENTITY 358 STATUS current 359 DESCRIPTION 360 "The identifier for the Type-P1-P2-Interval-Temporal- 361 Connectivity metric." 362 REFERENCE "RFC2678, section 6." 363 ::= { rfc 5 } 365 -- 366 -- RFC 2679 "A One-way Delay Metric for IPPM" 367 -- 369 oneWayDelay OBJECT-IDENTITY 370 STATUS current 371 DESCRIPTION 372 "The identifier for the Type-P-One-way-Delay metric." 373 REFERENCE "RFC2679, section 3." 374 ::= { rfc 6 } 376 oneWayDelayPoissonStream OBJECT-IDENTITY 377 STATUS current 378 DESCRIPTION 379 "The identifier for the Type-P-One-way-Delay-Poisson-Stream 380 metric." 381 REFERENCE "RFC2679, section 4." 382 ::= { rfc 7 } 384 oneWayDelayPercentile OBJECT-IDENTITY 385 STATUS current 386 DESCRIPTION 387 "The identifier for the Type-P-One-way-Delay-Percentile 388 metric." 389 REFERENCE "RFC2679, section 5.1." 390 ::= { rfc 8 } 392 oneWayDelayMedian OBJECT-IDENTITY 393 STATUS current 394 DESCRIPTION 395 "The identifier for the Type-P-One-way-Delay-Median metric." 396 REFERENCE "RFC2679, section 5.2." 397 ::= { rfc 9 } 399 oneWayDelayMinimum OBJECT-IDENTITY 400 STATUS current 401 DESCRIPTION 402 "The identifier for the Type-P-One-way-Delay-Minimum metric." 403 REFERENCE "RFC2679, section 5.3." 404 ::= { rfc 10 } 406 oneWayDelayInversePercentile OBJECT-IDENTITY 407 STATUS current 408 DESCRIPTION 409 "The identifier for the Type-P-One-way-Delay-Inverse-Percentile 410 metric. " 411 REFERENCE "RFC2679, section 5.4." 412 ::= { rfc 11 } 414 -- 415 -- RFC 2680 "One Way Packet Loss Metric for IPPM" 416 -- 418 oneWayPacketLoss OBJECT-IDENTITY 419 STATUS current 420 DESCRIPTION 421 "The identifier for the Type-P-One-way-Packet-Loss metric." 422 REFERENCE "RFC2680, section 2." 423 ::= { rfc 12 } 425 oneWayPacketLossPoissonStream OBJECT-IDENTITY 426 STATUS current 427 DESCRIPTION 428 "The identifier for the Type-P-One-way-Packet-Loss-Poisson- 429 Stream metric." 430 REFERENCE "RFC2680, section 3." 431 ::= { rfc 13 } 433 oneWayPacketLossAverage OBJECT-IDENTITY 434 STATUS current 435 DESCRIPTION 436 "The identifier for the Type-P-One-way-Packet-Loss-Average 437 metric." 438 REFERENCE "RFC2680, section 4." 439 ::= { rfc 14 } 441 -- 442 -- RFC2681 "A Round-trip Delay Metric for IPPM" 443 -- 445 roundtripDelay OBJECT-IDENTITY 446 STATUS current 447 DESCRIPTION 448 "The identifier for the Type-P-Round-trip-Delay metric." 449 REFERENCE " section 2 of the rfc2681." 450 ::= { rfc 15 } 452 roundtripDelayPoissonStream OBJECT-IDENTITY 453 STATUS current 454 DESCRIPTION 455 "The identifier for the Type-P-Round-trip-Delay-Poisson-Stream 456 metric." 457 REFERENCE "RFC2681, section 4." 458 ::= { rfc 16 } 460 roundtripDelayPercentile OBJECT-IDENTITY 461 STATUS current 462 DESCRIPTION 463 "The identifier for the Type-P-Round-trip-Delay-Percentile 464 metric." 465 REFERENCE "RFC2681, section 4.1." 466 ::= { rfc 17 } 468 roundtripDelayMedian OBJECT-IDENTITY 469 STATUS current 470 DESCRIPTION 471 "The identifier for the Type-P-Round-trip-Delay-Median metric." 472 REFERENCE "RFC2681, section 4.2." 473 ::= { rfc 18 } 475 roundtripDelayMinimum OBJECT-IDENTITY 476 STATUS current 477 DESCRIPTION 478 "The identifier for the Type-P-Round-trip-Delay-Minimum 479 metric." 480 REFERENCE "RFC2681, section 4.3." 481 ::= { rfc 19 } 483 roundtripDelayInversePercentile OBJECT-IDENTITY 484 STATUS current 485 DESCRIPTION 486 "The identifier for the Type-P-Round-trip-Inverse-Percentile 487 metric." 488 REFERENCE "RFC2681, section 4.4." 489 ::= { rfc 20 } 491 -- 492 -- RFC3357: "One-way Loss Pattern Sample Metrics" 493 -- 494 oneWayLossDistanceStream OBJECT-IDENTITY 495 STATUS current 496 DESCRIPTION 497 "The identifier for the Type-P-One-Way-Loss-Distance-Stream 498 metric." 499 REFERENCE " RFC3357, section 5.4.1." 500 ::={ rfc 21} 502 oneWayLossPeriodStream OBJECT-IDENTITY 503 STATUS current 504 DESCRIPTION 505 "The identifier for the Type-P-One-Way-Loss-Period-Stream 506 metric." 507 REFERENCE " RFC3357, section 5.4.2." 508 ::={ rfc 22} 510 oneWayLossNoticeableRate OBJECT-IDENTITY 511 STATUS current 512 DESCRIPTION 513 "The identifier for the Type-P-One-Way-Loss-Noticeable-Rate 514 metric." 515 REFERENCE " RFC3357, section 6.1." 516 ::= { rfc 23 } 518 oneWayLossPeriodTotal OBJECT-IDENTITY 519 STATUS current 520 DESCRIPTION 521 "The identifier for the Type-P-One-Way-Loss-Period-Total 522 metric." 523 REFERENCE " RFC3357, section 6.2." 524 ::= { rfc 24 } 526 oneWayLossPeriodLengths OBJECT-IDENTITY 527 STATUS current 528 DESCRIPTION 529 "The identifier for the Type-P-One-Way-Loss-Period-Lengths 530 metric." 531 REFERENCE " RFC3357, section 6.3." 532 ::= { rfc 25 } 534 oneWayInterLossPeriodLengths OBJECT-IDENTITY 535 STATUS current 536 DESCRIPTION 537 "The identifier for the Type-P-One-Way-Inter-Loss-Period- 538 Lengths metric." 539 REFERENCE " RFC3357, section 6.4." 540 ::= { rfc 26 } 542 -- 543 -- RFC3393: "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)" 544 -- 546 oneWayIpdv OBJECT-IDENTITY 547 STATUS current 548 DESCRIPTION 549 "The identifier for the Type-P-One-way-ipdv metric." 550 REFERENCE " RFC3393, section 2." 551 ::= { rfc 27 } 553 oneWayIpdvPoissonStream OBJECT-IDENTITY 554 STATUS current 555 DESCRIPTION 556 "The identifier for the Type-P-One-way-ipdv-Poisson-stream 557 metric." 558 REFERENCE " RFC3393, section 3." 559 ::= { rfc 28 } 561 oneWayIpdvPercentile OBJECT-IDENTITY 562 STATUS current 563 DESCRIPTION 564 "The identifier for the Type-P-One-way-ipdv-percentile metric." 565 REFERENCE " RFC3393, section 4.3." 566 ::= { rfc 29 } 568 oneWayIpdvInversePercentile OBJECT-IDENTITY 569 STATUS current 570 DESCRIPTION 571 "The identifier for the Type-P-One-way-ipdv-inverse-percentile 572 metric." 573 REFERENCE " RFC3393, section 4.4." 574 ::= { rfc 30 } 576 oneWayIpdvJitter OBJECT-IDENTITY 577 STATUS current 578 DESCRIPTION 579 "The identifier for the Type-P-One-way-ipdv-jitter metric." 580 REFERENCE " RFC3393, section 4.5." 581 ::= { rfc 31 } 583 oneWayPeakToPeakIpdv OBJECT-IDENTITY 584 STATUS current 585 DESCRIPTION 586 "The identifier for the Type-P-One-way-peak-to-peak-ipdv 587 metric." 588 REFERENCE " RFC3393, section 4.6." 589 ::= { rfc 32 } 591 -- 592 -- RFC3432: "Network performance measurement with periodic streams" 593 -- 594 oneWayDelayPeriodicStream OBJECT-IDENTITY 595 STATUS current 596 DESCRIPTION 597 "The identifier for the Type-P-One-way-Delay-Periodic-Stream 598 metric." 599 REFERENCE " RFC3432, section 4." 600 ::= { rfc 33 } 602 END 604 8. Intellectual Property 606 The IETF takes no position regarding the validity or scope of any 607 intellectual property or other rights that might be claimed to 608 pertain to the implementation or use of the technology described in 609 this document or the extent to which any license under such rights 610 might or might not be available; neither does it represent that it 611 has made any effort to identify any such rights. Information on the 612 IETF's procedures with respect to rights in standards-track and 613 standards-related documentation can be found in BCP-11. Copies of 614 claims of rights made available for publication and any assurances of 615 licenses to be made available, or the result of an attempt made to 616 obtain a general license or permission for the use of such 617 proprietary rights by implementors or users of this specification can 618 be obtained from the IETF Secretariat. 620 The IETF invites any interested party to bring to its attention any 621 copyrights, patents or patent applications, or other proprietary 622 rights which may cover technology that may be required to practice 623 this standard. Please address the information to the IETF Executive 624 Director. 626 9. Acknowledgments 628 The author gratefully acknowledges Andy Bierman and Randy Presuhn for 629 their guidance and comments. 631 10. Normative References 633 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 634 Rose, M. and S. Waldbusser, "Structure of Management Information 635 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 637 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 638 Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 639 58, RFC 2579, April 1999. 641 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 642 Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", 643 STD 58, RFC 2580, April 1999. 645 11. Informative References 647 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 648 3", BCP 9, RFC 2026, October 1996. 650 [RFC2330] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, 651 "Framework for IP Performance Metrics", RFC 2330, May 1998. 653 [RFC2678] Mahdavi J. and V. Paxson, "IPPM Metrics for Measuring 654 Connectivity", RFC 2678, September 1999. 656 [RFC2679] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way 657 Delay Metric for IPPM", RFC 2679, September 1999. 659 [RFC2680] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way 660 Packet Loss Metric for IPPM", RFC 2680, September 1999. 662 [RFC2681] Almes, G., Kalidindi, S. and M. Zekauskas, "A Round-trip 663 Delay Metric for IPPM", RFC 2681, September 1999. 665 [RFC3357] Koodli, R. and Ravikanth, R., "One-way Loss Pattern Sample 666 Metrics", RFC 3357, August 2002. 668 [RFC3393] Demichelis, C. and P. Chimento, " IP Packet Delay Variation 669 Metric for IP Performance Metrics (IPPM)", RFC 3393, November 670 2002. 672 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 673 "Introduction and Applicability Statements for Internet Standard 674 Management Framework", RFC 3410, December 2002. 676 [RFC3432] Raisanen, V., Grotefeld, G. and A. Morton, "Network 677 performance measurement with periodic streams", RFC 3432, November 678 2002. 680 12. Security Considerations 682 All the items specified in this MIB module are defined using the 683 macro OBJECT-IDENTITY. This macro does not have a MAX-ACCESS clause. 685 There are no management objects defined in this MIB module that have 686 a MAX-ACCESS clause of read-write and/or read-create. So, if this 687 MIB module is implemented correctly, then there is no risk that an 688 intruder can alter or create any management objects of this MIB 689 module via direct SNMP SET operations. 691 It is RECOMMENDED that implementers consider the security features as 692 provided by the SNMPv3 framework (see [RFC3410], section 8), 693 including full support for the SNMPv3 cryptographic mechanisms (for 694 authentication and privacy). 696 Further, deployment of SNMP versions prior to SNMPv3 is NOT 697 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 698 enable cryptographic security. It is then a customer/operator 699 responsibility to ensure that the SNMP entity giving access to an 700 instance of this MIB module is properly configured to give access to 701 the objects only to those principals (users) that have legitimate 702 rights to indeed GET or SET (change/create/delete) them. 704 13. Author's Addresses 706 Emile STEPHAN 707 France Telecom R & D 708 2, avenue Pierre Marzin 709 F-22307 Lannion cedex 710 Phone: (+ 33) 2 96 05 36 10 711 Email: emile.stephan@francetelecom.com 713 14. Full Copyright Statement 715 "Copyright (C) The Internet Society (2003). All Rights Reserved. 717 This document and translations of it may be copied and furnished to 718 others, and derivative works that comment on or otherwise explain it 719 or assist its implementation may be prepared, copied, published and 720 distributed, in whole or in part, without restriction of any kind, 721 provided that the above copyright notice and this paragraph are 722 included on all such copies and derivative works. However, this 723 document itself may not be modified in any way, such as by removing 724 the copyright notice or references to the Internet Society or other 725 Internet organizations, except as needed for the purpose of 726 developing Internet standards in which case the procedures for 727 copyrights defined in the Internet Standards process must be 728 followed, or as required to translate it into languages other than 729 English. 731 The limited permissions granted above are perpetual and will not be 732 revoked by the Internet Society or its successors or assigns. 734 This document and the information contained herein is provided on an 735 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 736 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 737 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 738 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 739 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.