idnits 2.17.1 draft-ietf-ippm-metrics-registry-06.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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There are 40 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (May 19, 2004) is 7254 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2460' is defined on line 625, but no explicit reference was found in the text == Unused Reference: 'RFC2463' is defined on line 628, but no explicit reference was found in the text == Unused Reference: 'RFC2473' is defined on line 632, but no explicit reference was found in the text == Unused Reference: 'RFC2895' is defined on line 660, but no explicit reference was found in the text == Unused Reference: 'RFC3032' is defined on line 664, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 681, but no explicit reference was found in the text == Unused Reference: 'RFC2896' is defined on line 688, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2463 (Obsoleted by RFC 4443) ** 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: 8 errors (**), 0 flaws (~~), 9 warnings (==), 2 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 Category: Best Current Practice May 19, 2004 5 Expires: November 17, 2004 7 IPPM metrics registry 8 draft-ietf-ippm-metrics-registry-06.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on November 17, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This memo defines a registry for IP Performance Metrics (IPPM). It 39 assigns and registers an initial set of OBJECT IDENTITIES to 40 currently defined metrics in the IETF. 42 This memo also defines the rules for adding new IP Performance 43 Metrics in the future, both those standardized inside and outside the 44 IETF. 46 IANA has been assigned to administer this new registry. 48 Table of Contents 50 1. The Internet-Standard Management Framework . . . . . . . . . . 3 51 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. The IPPM Framework . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 5. IPPM metrics Registry framework . . . . . . . . . . . . . . . 4 55 6. Initial IPPM metrics registry creation . . . . . . . . . . . . 4 56 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 5 57 7.1 Management rules . . . . . . . . . . . . . . . . . . . . . 5 58 7.1.1 Naming Conventions . . . . . . . . . . . . . . . . . . 5 59 7.1.2 Metrics defined by IETF . . . . . . . . . . . . . . . 5 60 7.1.3 Metrics defined in cooperation with other bodies . . . 5 61 7.1.4 Private Metrics registration . . . . . . . . . . . . . 6 62 7.2 Registration templates . . . . . . . . . . . . . . . . . . 6 63 7.2.1 IETF RFCs . . . . . . . . . . . . . . . . . . . . . . 6 64 7.2.2 Other Organizations . . . . . . . . . . . . . . . . . 7 65 7.2.3 Enterprises . . . . . . . . . . . . . . . . . . . . . 7 66 8. Initial IPPM registry definition . . . . . . . . . . . . . . . 7 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 70 10.2 Informative References . . . . . . . . . . . . . . . . . . . 16 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 17 72 Intellectual Property and Copyright Statements . . . . . . . . 18 74 1. The Internet-Standard Management Framework 76 For a detailed overview of the documents that describe the current 77 Internet-Standard Management Framework, please refer to section 7 of 78 RFC 3410 [RFC3410]. Managed objects are accessed via a virtual 79 information store, termed the Management Information Base or MIB. MIB 80 objects are generally accessed through the Simple Network Management 81 Protocol (SNMP). Objects in the MIB are defined using the mechanisms 82 defined in the Structure of Management Information (SMI). This memo 83 specifies a MIB module that is compliant to the SMIv2, which is 84 described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] 85 and STD 58, RFC 2580 [RFC2580]. 87 2. Terms 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in BCP 14, RFC 2119 92 [RFC2119]. 94 3. The IPPM Framework 96 The IPPM Framework consists in four major components: 98 o A general framework for defining performance metrics described in 99 the Framework for IP Performance Metrics RFC2330 [RFC2330]; 101 o A set of standardized metrics, which conform to this framework. 103 o Emerging metrics which are being specified in respect of this 104 framework; 106 o The IPPM-REPORTING-MIB for reporting the results of the measures 107 and for interfacing heterogeneous measurement systems with 108 management entities. 110 4. Overview 112 This memo defines a registry of the current metrics and a framework 113 for the integration of future metrics for the following reasons: 115 o to permit metrics to be clearly referenced by MIB modules or other 116 data models; 118 o Metrics identifiers are needed to allow measurement 119 interoperability; As specification of new metrics is a continuous 120 process, special care must be taken for the integration of future 121 standardized metrics; 123 o As the intent of the IPPM WG is to cooperate with other 124 appropriate standards bodies and other areas of IETF to promote 125 consistent metrics, there is a need to permit registration of such 126 metrics. 128 5. IPPM metrics Registry framework 130 MIB modules need to be able to precisely reference IPPM Metrics. The 131 registry associates an OBJECT-IDENTITY with each metric. As an 132 example Type-P-One-way-Delay and Type-P-One-way-Delay-Poisson-Stream 133 have different OBJECT IDENTITIES. 135 The registry has 3 main branches. The origin of the document 136 determines the node which branch the metric is identified in: 138 o Metrics defined by IETF are identified in the 'ietf' tree; 140 o Metrics defined in cooperation with other organizations may be 141 identified in the 'otherOrganizations' tree. 143 o Vendors may register private metrics in the 'enterprises' tree. 145 This document defines an initial registry of the existing metrics and 146 the rules to manage the registry. 148 Documents defining metrics in the future will include in the IANA 149 section the registration information to unambiguously identify these 150 metrics. 152 6. Initial IPPM metrics registry creation 154 The initial registry identifies the metrics currently defined in the 155 RFCs produced in the IPPM WG. By now, the IPPM WG defined 33 metrics 156 related to 7 topics: 158 o IPPM Metrics for Measuring Connectivity, RFC 2678 [RFC2678]; 160 o One-way Delay Metrics, RFC 2679 [RFC2679]; 162 o One-way Packet Loss Metrics, RFC 2680 [RFC2680]; 164 o Round-trip Delay Metrics, RFC 2681 [RFC2681]; 166 o One-way Loss Pattern Sample Metrics, RFC 3357 [RFC3357]; 167 o IP Packet Delay Variation Metric, RFC 3393 [RFC3393]; 169 o IPPM Metrics for periodic streams, RFC 3432 [RFC3432]; 171 7. IANA considerations 173 This section describes the rules for the management of the registry 174 by IANA. 176 7.1 Management rules 178 7.1.1 Naming Conventions 180 The name of the metric in the registry must respect the SMIv2 rules 181 for descriptors ([RFC2578], section 3.1) and should be easily 182 readable. Consequently the following is applied to adapt the name 183 used in the metric definition: 185 o The name always starts with the prefix of the organization. 187 o 'Type-P' prefix is removed. 189 o '-' are removed; 191 o The letter following a '-' is changed to upper case; 193 o A node assigned to a metric is definitive and cannot be reused. 195 o If a new version of a metric is produced then it is assigned with 196 a new name and a new identifier. 198 7.1.2 Metrics defined by IETF 200 Such metrics are registered in the node ietf(1) after approval of the 201 document by the IESG. 203 The name always starts with the prefix 'ietf'. They are registered in 204 the node ietf(1). They are numbered using the metrics definitions 205 order in each memo. 207 7.1.3 Metrics defined in cooperation with other bodies 209 After approval of the document by the IESG, IANA will assign the 210 organization with a subtree under the branch otherOrganizations(2). 212 The organization registers metrics under the branch 213 otherOrganizations(2), in the corresponding subtree. The name of the 214 metric always starts with the prefix of the organization. The prefix 215 is the name of the subtree assigned to the organization. 217 Nothing prevents these bodies from registering metrics in their own 218 OBJECT INDENTIFIER trees. 220 7.1.4 Private Metrics registration 222 IANA already assigns enterprises with unambiguous identifiers named 223 enterprise numbers or vendorID. See http://www.iana.org/numbers.html. 225 After approval of the document by the IESG, an enterprise may 226 register private metrics under the branch enterprises(3), in the 227 subtree corresponding to its enterprise number. The name of the 228 metric always starts with the prefix of the company. 230 The enterprise is responsible for the assignment of the number if its 231 subtree. 233 Example: The enterprise Acme,which enterprise number is 100000, will 234 register its metrics in the subtree 235 ippmMetricsRegistry(x).enterprises(3).100000. 237 7.2 Registration templates 239 A document that creates new Metrics would have an IANA considerations 240 section in which it would describe new metrics to register. 242 7.2.1 IETF RFCs 244 For each metric, that section would have a statement aka: 246 IANA has registed the following Metric in the IANA-IPPM-METRICS-MIB: 248 ietfSomeNewMetricName OBJECT-IDENTITY 249 STATUS current 250 DESCRIPTION "The identifier for the Type-P-Some-New_Metric-Name 251 metric." 252 REFERENCE "RFCxxxx, section n." -- RFC-Editor fills in xxxx 253 ::= { ietf nn } -- IANA assigns nn 255 7.2.2 Other Organizations 257 For each metric, that section would have a statement aka: 259 IANA has registed the following Metric in the IANA-IPPM-METRICS-MIB: 261 orgSomeNewMetricName OBJECT-IDENTITY 262 STATUS current 263 DESCRIPTION "The identifier for the Some-New_Metric-Name 264 metric." 265 REFERENCE "URL, section n." -- link to the org document. 266 ::= { org nn } -- org assigns nn 268 7.2.3 Enterprises 270 For each metric, that section would have a statement aka: 272 Vendor has registed the following Metric: 274 vendorSomeNewMetricName OBJECT-IDENTITY 275 STATUS current 276 DESCRIPTION "The identifier for the Some-New_Metric-Name 277 metric." 278 REFERENCE "URL, section n." -- link to the vendor document. 279 ::= { vendorID nn } -- vendor assigns nn 281 8. Initial IPPM registry definition 282 IANA-IPPM-METRICS-REGISTRY DEFINITIONS ::= BEGIN 284 IMPORTS 285 OBJECT-IDENTITY, MODULE-IDENTITY, mib-2 286 FROM SNMPv2-SMI; 288 ippmMetricsRegistry MODULE-IDENTITY 289 REVISION "200405190000Z" -- May 19th, 2004 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 ippm@ietf.org 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. 305 Copyright (C) The Internet Society (2004). This version of 306 this MIB module is part of RFC yyyy; see the RFC itself for 307 full legal notices." 308 REVISION "200405190000Z" -- May 19th, 2004 309 DESCRIPTION 310 "Initial version of the IPPM metrics registry module. 311 This version published as RFC yyyy." 312 ::= { mib-2 XXX } -- XXX to be assigned by IANA 314 ietf OBJECT IDENTIFIER ::= { ippmMetricsRegistry 1 } 315 otherOrganizations OBJECT IDENTIFIER ::= { ippmMetricsRegistry 2 } 316 enterprises OBJECT IDENTIFIER ::= { ippmMetricsRegistry 3 } 318 -- 319 -- Registry of the metrics of the IPPM WG RFCs 320 -- 322 -- 323 -- RFC 2678 " IPPM Metrics for Measuring Connectivity" 324 -- 326 ietfInstantUnidirConnectivity 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 ietfInstantBidirConnectivity 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 ietfIntervalUnidirConnectivity 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 ietfIntervalBidirConnectivity 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 ietfIntervalTemporalConnectivity 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 ietfOneWayDelay 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 ietfOneWayDelayPoissonStream 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 ietfOneWayDelayPercentile 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 ietfOneWayDelayMedian 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 ietfOneWayDelayMinimum 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 ietfOneWayDelayInversePercentile OBJECT-IDENTITY 408 STATUS current 409 DESCRIPTION 410 "The identifier for the Type-P-One-way-Delay-Inverse- 411 Percentile metric. " 412 REFERENCE "RFC2679, section 5.4." 413 ::= { rfc 11 } 415 -- 416 -- RFC 2680 "One Way Packet Loss Metric for IPPM" 417 -- 419 ietfOneWayPktLoss 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 ietfOneWayPktLossPoissonStream 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 ietfOneWayPktLossAverage 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 -- TODO remnae as V5 in v5 dir 443 -- RFC2681 "A Round-trip Delay Metric for IPPM" 444 -- 446 ietfRoundTripDelay 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 ietfRoundTripDelayPoissonStream OBJECT-IDENTITY 454 STATUS current 455 DESCRIPTION 456 "The identifier for the Type-P-Round-trip-Delay-Poisson 457 -Stream metric." 458 REFERENCE "RFC2681, section 4." 459 ::= { rfc 16 } 461 ietfRoundTripDelayPercentile 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 ietfRoundTripDelayMedian OBJECT-IDENTITY 470 STATUS current 471 DESCRIPTION 472 "The identifier for the Type-P-Round-trip-Delay-Median 473 metric." 474 REFERENCE "RFC2681, section 4.2." 475 ::= { rfc 18 } 477 ietfRoundTripDelayMinimum OBJECT-IDENTITY 478 STATUS current 479 DESCRIPTION 480 "The identifier for the Type-P-Round-trip-Delay-Minimum 481 metric." 482 REFERENCE "RFC2681, section 4.3." 483 ::= { rfc 19 } 485 ietfRoundTripDelayInversePercentile OBJECT-IDENTITY 486 STATUS current 487 DESCRIPTION 488 "The identifier for the Type-P-Round-trip-Inverse-Percentile 489 metric." 490 REFERENCE "RFC2681, section 4.4." 491 ::= { rfc 20 } 493 -- 494 -- RFC3357: "One-way Loss Pattern Sample Metrics" 495 -- 497 ietfOneWayLossDistanceStream OBJECT-IDENTITY 498 STATUS current 499 DESCRIPTION 500 "The identifier for the Type-P-One-Way-Loss-Distance-Stream 501 metric." 502 REFERENCE " RFC3357, section 5.4.1." 503 ::={ rfc 21} 505 ietfOneWayLossPeriodStream OBJECT-IDENTITY 506 STATUS current 507 DESCRIPTION 508 "The identifier for the Type-P-One-Way-Loss-Period-Stream 509 metric." 510 REFERENCE " RFC3357, section 5.4.2." 511 ::={ rfc 22} 513 ietfOneWayLossNoticeableRate OBJECT-IDENTITY 514 STATUS current 515 DESCRIPTION 516 "The identifier for the Type-P-One-Way-Loss-Noticeable-Rate 517 metric." 518 REFERENCE " RFC3357, section 6.1." 519 ::= { rfc 23 } 521 ietfOneWayLossPeriodTotal OBJECT-IDENTITY 522 STATUS current 523 DESCRIPTION 524 "The identifier for the Type-P-One-Way-Loss-Period-Total 525 metric." 526 REFERENCE " RFC3357, section 6.2." 527 ::= { rfc 24 } 529 ietfOneWayLossPeriodLengths OBJECT-IDENTITY 530 STATUS current 531 DESCRIPTION 532 "The identifier for the Type-P-One-Way-Loss-Period-Lengths 533 metric." 534 REFERENCE " RFC3357, section 6.3." 535 ::= { rfc 25 } 537 ietfOneWayInterLossPeriodLengths OBJECT-IDENTITY 538 STATUS current 539 DESCRIPTION 540 "The identifier for the Type-P-One-Way-Inter-Loss-Period- 541 Lengths metric." 542 REFERENCE " RFC3357, section 6.4." 543 ::= { rfc 26 } 545 -- 546 -- RFC3393: 547 -- IP Packet Delay Variation Metric for IP Performance Metrics (IPPM) 549 ietfOneWayIpdv OBJECT-IDENTITY 550 STATUS current 551 DESCRIPTION 552 "The identifier for the Type-P-One-way-ipdv metric." 553 REFERENCE " RFC3393, section 2." 554 ::= { rfc 27 } 556 ietfOneWayIpdvPoissonStream OBJECT-IDENTITY 557 STATUS current 558 DESCRIPTION 559 "The identifier for the Type-P-One-way-ipdv-Poisson-stream 560 metric." 561 REFERENCE " RFC3393, section 3." 562 ::= { rfc 28 } 564 ietfOneWayIpdvPercentile OBJECT-IDENTITY 565 STATUS current 566 DESCRIPTION 567 "The identifier for the Type-P-One-way-ipdv-percentile metric." 568 REFERENCE " RFC3393, section 4.3." 569 ::= { rfc 29 } 571 ietfOneWayIpdvInversePercentile OBJECT-IDENTITY 572 STATUS current 573 DESCRIPTION 574 "The identifier for the Type-P-One-way-ipdv-inverse 575 -percentile metric." 576 REFERENCE " RFC3393, section 4.4." 577 ::= { rfc 30 } 579 ietfOneWayIpdvJitter OBJECT-IDENTITY 580 STATUS current 581 DESCRIPTION 582 "The identifier for the Type-P-One-way-ipdv-jitter metric." 583 REFERENCE " RFC3393, section 4.5." 584 ::= { rfc 31 } 586 ietfOneWayPeakToPeakIpdv OBJECT-IDENTITY 587 STATUS current 588 DESCRIPTION 589 "The identifier for the Type-P-One-way-peak-to-peak-ipdv 590 metric." 591 REFERENCE " RFC3393, section 4.6." 592 ::= { rfc 32 } 594 -- 595 -- RFC3432: "Network performance measurement with periodic streams" 596 -- 598 ietfOneWayDelayPeriodicStream OBJECT-IDENTITY 599 STATUS current 600 DESCRIPTION 601 "The identifier for the Type-P-One-way-Delay-Periodic-Stream 602 metric." 603 REFERENCE " RFC3432, section 4." 604 ::= { rfc 33 } 606 END 608 9. Security Considerations 610 This module does not define any management objects. Instead, it 611 assigns a set of OBJECT-IDENTITIES which may be used by other MIB 612 modules to identify specific IP Performance Metrics. 614 Meaningful security considerations can only be written in the MIB 615 modules that define management objects. This document has therefore 616 no impact on the security of the Internet. 618 10. References 620 10.1 Normative References 622 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 623 Requirement Levels", BCP 14, RFC 2119, March 1997. 625 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 626 (IPv6) Specification", RFC 2460, December 1998. 628 [RFC2463] Conta, A. and S. Deering, "Internet Control Message 629 Protocol (ICMPv6) for the Internet Protocol Version 6 630 (IPv6) Specification", RFC 2463, December 1998. 632 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 633 IPv6 Specification", RFC 2473, December 1998. 635 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 636 McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of 637 Management Information Version 2 (SMIv2)", STD 58, RFC 638 2578, April 1999. 640 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 641 McCloghrie, K., Rose, M. and S. Waldbusser, "Textual 642 Conventions for SMIv2", STD 58, RFC 2579, April 1999. 644 [RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, 645 "Conformance Statements for SMIv2", STD 58, RFC 2580, 646 April 1999. 648 [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring 649 Connectivity", RFC 2678, September 1999. 651 [RFC2679] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way 652 Delay Metric for IPPM", RFC 2679, September 1999. 654 [RFC2680] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way 655 Packet Loss Metric for IPPM", RFC 2680, September 1999. 657 [RFC2681] Almes, G., Kalidindi, S. and M. Zekauskas, "A Round-trip 658 Delay Metric for IPPM", RFC 2681, September 1999. 660 [RFC2895] Bierman, A., Bucci, C. and R. Iddon, "Remote Network 661 Monitoring MIB Protocol Identifier Reference", RFC 2895, 662 August 2000. 664 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 665 Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack 666 Encoding", RFC 3032, January 2001. 668 [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample 669 Metrics", RFC 3357, August 2002. 671 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 672 Metric for IP Performance Metrics (IPPM)", RFC 3393, 673 November 2002. 675 [RFC3432] Raisanen, V., Grotefeld, G. and A. Morton, "Network 676 performance measurement with periodic streams", RFC 3432, 677 November 2002. 679 10.2 Informative References 681 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 682 3", BCP 9, RFC 2026, October 1996. 684 [RFC2330] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, 685 "Framework for IP Performance Metrics", RFC 2330, May 686 1998. 688 [RFC2896] Bierman, A., Bucci, C. and R. Iddon, "Remote Network 689 Monitoring MIB Protocol Identifier Macros", RFC 2896, 690 August 2000. 692 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 693 "Introduction and Applicability Statements for 694 Internet-Standard Management Framework", RFC 3410, 695 December 2002. 697 Author's Address 699 Stephan Emile 700 France Telecom R & D 701 2 avenue Pierre Marzin 702 Lannion, F-22307 704 Fax: +33 2 96 05 18 52 705 EMail: emile.stephan@francetelecom.com 707 Intellectual Property Statement 709 The IETF takes no position regarding the validity or scope of any 710 intellectual property or other rights that might be claimed to 711 pertain to the implementation or use of the technology described in 712 this document or the extent to which any license under such rights 713 might or might not be available; neither does it represent that it 714 has made any effort to identify any such rights. Information on the 715 IETF's procedures with respect to rights in standards-track and 716 standards-related documentation can be found in BCP-11. Copies of 717 claims of rights made available for publication and any assurances of 718 licenses to be made available, or the result of an attempt made to 719 obtain a general license or permission for the use of such 720 proprietary rights by implementors or users of this specification can 721 be obtained from the IETF Secretariat. 723 The IETF invites any interested party to bring to its attention any 724 copyrights, patents or patent applications, or other proprietary 725 rights which may cover technology that may be required to practice 726 this standard. Please address the information to the IETF Executive 727 Director. 729 Full Copyright Statement 731 Copyright (C) The Internet Society (2004). All Rights Reserved. 733 This document and translations of it may be copied and furnished to 734 others, and derivative works that comment on or otherwise explain it 735 or assist in its implementation may be prepared, copied, published 736 and distributed, in whole or in part, without restriction of any 737 kind, provided that the above copyright notice and this paragraph are 738 included on all such copies and derivative works. However, this 739 document itself may not be modified in any way, such as by removing 740 the copyright notice or references to the Internet Society or other 741 Internet organizations, except as needed for the purpose of 742 developing Internet standards in which case the procedures for 743 copyrights defined in the Internet Standards process must be 744 followed, or as required to translate it into languages other than 745 English. 747 The limited permissions granted above are perpetual and will not be 748 revoked by the Internet Society or its successors or assignees. 750 This document and the information contained herein is provided on an 751 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 752 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 753 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 754 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 755 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 757 Acknowledgment 759 Funding for the RFC Editor function is currently provided by the 760 Internet Society.