idnits 2.17.1 draft-ietf-adslmib-hc-tc-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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines 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 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. == Unrecognized Status in 'Category: Internet Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (September 2003) is 7522 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: 'RFC2026' is defined on line 419, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2495 (Obsoleted by RFC 3895) -- Obsolete informational reference (is this intentional?): RFC 2496 (Obsoleted by RFC 3896) -- Obsolete informational reference (is this intentional?): RFC 3276 (Obsoleted by RFC 4319) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group B. Ray 2 Category: Internet Draft PESA Switching Systems 3 R. Abbi 4 Alcatel 5 September 2003 7 High Capacity Textual Conventions for MIB Modules Using 8 Performance History Based on 15 Minute Intervals 9 draft-ietf-adslmib-hc-tc-06.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at: 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at: 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document presents a set of High Capacity Textual Conventions 39 for use in MIB modules which require performance history based upon 40 15 minute intervals. The Textual Conventions defined in this 41 document extend the conventions presented in RFC 3593 to 64 bit 42 resolution using the conventions presented in RFC 2856. 44 Table of Contents 46 1. The Internet-Standard Management Framework .................... 2 47 2. Overview ...................................................... 2 48 3. Definitions ................................................... 3 49 4. Intellectual Property ......................................... 8 50 5. Normative References .......................................... 8 51 6. Informative References ........................................ 8 52 7. Security Considerations ....................................... 9 53 8. Acknowledgements .............................................. 9 54 9. Authors' Addresses ............................................ 9 55 10. Full Copyright Statement ...................................... 10 57 1. The Internet-Standard Management Framework 59 For a detailed overview of the documents that describe the current 60 Internet-Standard Management Framework, please refer to section 7 of 61 RFC 3410 [RFC3410]. 63 Managed objects are accessed via a virtual information store, termed 64 the Management Information Base or MIB. MIB objects are generally 65 accessed through the Simple Network Management Protocol (SNMP). 66 Objects in the MIB are defined using the mechanisms defined in the 67 Structure of Management Information (SMI). This memo specifies a 68 MIB module that is compliant to the SMIv2, which is described in STD 69 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 70 2580 [RFC2580]. 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC2119]. 76 2. Overview 78 In cases where a manager must obtain performance history data about 79 the behavior of equipment it manages, several strategies can be 80 followed in the design of a MIB module that represents the managed 81 equipment, including: 83 - The agent counts events on a continuous basis and, whenever 84 desired, the manager obtains the value of the event counter and 85 adjusts its understanding of the history of events at the agent. 87 - The agent allocates events to 'buckets' where each bucket 88 represents an interval of time. 90 Telecommunications equipment often makes use of the latter strategy. 91 For such equipment the standard practice is that history data is 92 maintained by the agent in terms of 15-minute intervals [T1.231]. 94 MIB modules for collecting performance history based on 15-minute 95 intervals have been defined for the DS1/E1 [RFC2495], DS3/E3 96 [RFC2496], SONET/SDH [RFC3592], ADSL [RFC2662], HDLS2 and SHDSL 98 [RFC3276] interface types. These MIB modules use a common set of 99 textual conventions defined in [RFC3593]. Those textual 100 conventions are based on the Gauge32 data type. 102 A need has arisen to define 64-bit versions of the textual 103 conventions in [RFC3593]. Ideally, these high-capacity textual 104 conventions would be based on a Gauge64 or Unsigned64 data type, but 105 unfortunately no such types exist in SMIv2. The next best choice 106 would be to base them on the CounterBasedGauge64 textual convention 107 presented in [RFC2856], but that is not possible either since SMIv2 108 allows only base types to be used in defining textual conventions. 109 Therefore, the textual conventions presented in this memo are based 110 directly on the Counter64 type, like those in [RFC2856]. They are 111 subject to the following limitations: 113 - The MAX-ACCESS of objects defined using these textual conventions 114 must be read-only, because the MAX-ACCESS of the underlying 115 Counter64 type is read-only. 117 - No sub-range can be specified in object definitions using these 118 textual conventions, because sub-ranges are not allowed on 119 Counter64 objects. 121 - No DEFVAL clause can be specified in object definitions using 122 these textual conventions, because DEFVALs are not allowed on 123 Counter64 objects. 125 - Objects defined using these textual conventions cannot be used 126 in an INDEX clause, because there is no INDEX clause mapping 127 defined for objects of type Counter64. 129 Use of the textual conventions presented in this memo assumes the 130 following: 132 - The agent supports 15 minute based history counters. 134 - The agent is capable of keeping a history of 96 intervals of 15 135 minute performance data. 137 - The agent may optionally support performance data aggregating the 138 history intervals. 140 - The agent will keep separate tables for the current interval, the 141 history intervals, and the total aggregates. 143 3. Definitions 145 HC-PerfHist-TC-MIB DEFINITIONS ::= BEGIN 147 IMPORTS 148 MODULE-IDENTITY, 149 Counter64, 150 Unsigned32, 151 Gauge32, 152 mib-2 FROM SNMPv2-SMI 153 TEXTUAL-CONVENTION FROM SNMPv2-TC; 155 hcPerfHistTCMIB MODULE-IDENTITY 156 LAST-UPDATED "200309240000Z" -- September 24, 2003 157 ORGANIZATION "ADSLMIB Working Group" 158 CONTACT-INFO "WG-email: adslmib@ietf.org 159 Info: https://www1.ietf.org/mailman/listinfo/adslmib 161 Chair: Mike Sneed 162 Sand Channel Systems 163 Postal: P.O. Box 37324 164 Raleigh NC 27627-7324 165 USA 166 Email: sneedmike@hotmail.com 167 Phone: +1 206 600 7022 169 Co-editor: Bob Ray 170 PESA Switching Systems, Inc. 171 Postal: 330-A Wynn Drive 172 Huntsville, AL 35805 173 USA 174 Email: rray@pesa.com 175 Phone: +1 256 726 9200 ext. 142 177 Co-editor: Rajesh Abbi 178 Alcatel USA 179 Postal: 2912 Wake Forest Road 180 Raleigh, NC 27609-7860 181 USA 182 Email: Rajesh.Abbi@alcatel.com 183 Phone: +1 919 850 6194 184 " 185 DESCRIPTION 186 "This MIB Module provides Textual Conventions to be 187 used by systems supporting 15 minute based performance 188 history counts that require high-capacity counts. 190 Copyright (C) The Internet Society (2003). This version 191 of this MIB module is part of RFC XXXX: see the RFC 192 itself for full legal notices." 193 -- RFC Ed.: replace XXXX with assigned number & remove this note 194 REVISION "200309240000Z" -- September 24, 2003 195 DESCRIPTION "Initial version, published as RFC XXXX." 196 -- RFC Ed.: replace XXXX with assigned number & remove this note 197 ::= { mib-2 YYYY } 198 -- RFC Ed.: replace YYYY with IANA-assigned number & remove this note 200 HCPerfValidIntervals ::= TEXTUAL-CONVENTION 201 STATUS current 202 DESCRIPTION 203 "The number of near end intervals for which data was 204 collected. The value of an object with an 205 HCPerfValidIntervals syntax will be 96 unless the 206 measurement was (re-)started within the last 1440 minutes, 207 in which case the value will be the number of complete 15 208 minute intervals for which the agent has at least some data. 209 In certain cases (e.g., in the case where the agent is a 210 proxy) it is possible that some intervals are unavailable. 211 In this case, this interval is the maximum interval number 212 for which data is available." 213 SYNTAX Gauge32 (0..96) 215 HCPerfInvalidIntervals ::= TEXTUAL-CONVENTION 216 STATUS current 217 DESCRIPTION 218 "The number of near end intervals for which no data is 219 available. The value of an object with an 220 HCPerfInvalidIntervals syntax will typically be zero except 221 in cases where the data for some intervals are not available 222 (e.g., in proxy situations)." 223 SYNTAX Gauge32 (0..96) 225 HCPerfTimeElapsed ::= TEXTUAL-CONVENTION 226 STATUS current 227 DESCRIPTION 228 "The number of seconds that have elapsed since the beginning 229 of the current measurement period. If, for some reason, 230 such as an adjustment in the system's time-of-day clock or 231 the addition of a leap second, the duration of the current 232 interval exceeds the maximum value, the agent will return 233 the maximum value. 235 For 15 minute intervals, the range is limited to (0..899). 236 For 24 hour intervals, the range is limited to (0..86399)." 237 SYNTAX Gauge32 (0..86399) 239 HCPerfIntervalThreshold ::= TEXTUAL-CONVENTION 240 STATUS current 241 DESCRIPTION 242 "This convention defines a range of values that may be set 243 in a fault threshold alarm control. As the number of 244 seconds in a 15-minute interval numbers at most 900, 245 objects of this type may have a range of 0...900, where the 246 value of 0 disables the alarm." 247 SYNTAX Unsigned32 (0..900) 249 HCPerfCurrentCount ::= TEXTUAL-CONVENTION 250 STATUS current 251 DESCRIPTION 252 "A gauge associated with a performance measurement in a 253 current 15 minute measurement interval. The value of an 254 object with an HCPerfCurrentCount syntax starts from zero 255 and is increased when associated events occur, until the 256 end of the 15 minute interval. At that time the value of 257 the gauge is stored in the first 15 minute history 258 interval, and the gauge is restarted at zero. In the case 259 where the agent has no valid data available for the 260 current interval, the corresponding object instance is not 261 available and upon a retrieval request a corresponding 262 error message shall be returned to indicate that this 263 instance does not exist. 265 This count represents a non-negative integer, which 266 may increase or decrease, but shall never exceed 2^64-1 267 (18446744073709551615 decimal), nor fall below 0. The 268 The value of an object with HCPerfCurrentCount syntax 269 assumes its maximum value whenever the underlying count 270 exceeds 2^64-1. If the underlying count subsequently 271 decreases below 2^64-1 (due, e.g., to a retroactive 272 adjustment as a result of entering or exiting unavailable 273 time), then the object's value also decreases. 275 Note that this TC is not strictly supported in SMIv2, 276 because the 'always increasing' and 'counter wrap' 277 semantics associated with the Counter64 base type are not 278 preserved. It is possible that management applications 279 which rely solely upon the (Counter64) ASN.1 tag to 280 determine object semantics will mistakenly operate upon 281 objects of this type as they would for Counter64 objects. 283 This textual convention represents a limited and short- 284 term solution, and may be deprecated as a long term 285 solution is defined and deployed to replace it." 286 SYNTAX Counter64 288 HCPerfIntervalCount ::= TEXTUAL-CONVENTION 289 STATUS current 290 DESCRIPTION 291 "A gauge associated with a performance measurement in 292 a previous 15 minute measurement interval. In the case 293 where the agent has no valid data available for a 294 particular interval, the corresponding object instance is 295 not available and upon a retrieval request a corresponding 296 error message shall be returned to indicate that this 297 instance does not exist. 299 Let X be an object with HCPerfIntervalCount syntax. 300 Let Y be an object with HCPerfCurrentCount syntax. 301 Let Z be an object with HCPerfTotalCount syntax. 302 Then, In a system supporting a history of n intervals with 303 X(1) and X(n) the most and least recent intervals 304 respectively, the following applies at the end of a 15 305 minute interval: 307 - discard the value of X(n) 308 - the value of X(i) becomes that of X(i-1) 309 for n >= i > 1 311 - the value of X(1) becomes that of Y. 312 - the value of Z, if supported, is adjusted. 314 This count represents a non-negative integer, which 315 may increase or decrease, but shall never exceed 2^64-1 316 (18446744073709551615 decimal), nor fall below 0. The 317 The value of an object with HCPerfIntervalCount syntax 318 assumes its maximum value whenever the underlying count 319 exceeds 2^64-1. If the underlying count subsequently 320 decreases below 2^64-1 (due, e.g., to a retroactive 321 adjustment as a result of entering or exiting unavailable 322 time), then the value of the object also decreases. 324 Note that this TC is not strictly supported in SMIv2, 325 because the 'always increasing' and 'counter wrap' 326 semantics associated with the Counter64 base type are not 327 preserved. It is possible that management applications 328 which rely solely upon the (Counter64) ASN.1 tag to 329 determine object semantics will mistakenly operate upon 330 objects of this type as they would for Counter64 objects. 332 This textual convention represents a limited and short- 333 term solution, and may be deprecated as a long term 334 solution is defined and deployed to replace it." 335 SYNTAX Counter64 337 HCPerfTotalCount ::= TEXTUAL-CONVENTION 338 STATUS current 339 DESCRIPTION 340 "A gauge representing the aggregate of previous valid 15 341 minute measurement intervals. Intervals for which no 342 valid data was available are not counted. 344 This count represents a non-negative integer, which 345 may increase or decrease, but shall never exceed 2^64-1 346 (18446744073709551615 decimal), nor fall below 0. The 347 The value of an object with HCPerfTotalCount syntax 348 assumes its maximum value whenever the underlying count 349 exceeds 2^64-1. If the underlying count subsequently 350 decreases below 2^64-1 (due, e.g., to a retroactive 351 adjustment as a result of entering or exiting unavailable 352 time), then the object's value also decreases. 354 Note that this TC is not strictly supported in SMIv2, 355 because the 'always increasing' and 'counter wrap' 356 semantics associated with the Counter64 base type are not 357 preserved. It is possible that management applications 358 which rely solely upon the (Counter64) ASN.1 tag to 359 determine object semantics will mistakenly operate upon 360 objects of this type as they would for Counter64 objects. 362 This textual convention represents a limited and short- 363 term solution, and may be deprecated as a long term 364 solution is defined and deployed to replace it." 365 SYNTAX Counter64 366 END 368 4. Intellectual Property 370 The IETF takes no position regarding the validity or scope of any 371 intellectual property or other rights that might be claimed to 372 pertain to the implementation or use of the technology described in 373 this document or the extent to which any license under such rights 374 might or might not be available; neither does it represent that it 375 has made any effort to identify any such rights. Information on the 376 IETF's procedures with respect to rights in standards-track and 377 standards-related documentation can be found in BCP-11. Copies of 378 claims of rights made available for publication and any assurances 379 of licenses to be made available, or the result of an attempt made 380 to obtain a general license or permission for the use of such 381 proprietary rights by implementors or users of this specification 382 can be obtained from the IETF Secretariat. 384 The IETF invites any interested party to bring to its attention any 385 copyrights, patents or patent applications, or other proprietary 386 rights which may cover technology that may be required to practice 387 this standard. Please address the information to the IETF Executive 388 Director. 390 5. Normative References 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, March 1997. 395 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 396 Rose, M. and S. Waldbusser, "Structure of Management 397 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 398 1999. 400 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 401 Rose, M. and S. Waldbusser, "Textual Conventions for 402 SMIv2", STD 58, RFC 2579, April 1999. 404 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 405 Rose, M. and S. Waldbusser, "Conformance Statements for 406 SMIv2", STD 58, RFC 2580, April 1999. 408 6. Informative References 410 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 411 "Introduction and Applicability Statements for Internet- 412 Standard Management Framework", RFC 3410, December 2002. 414 [T1.231] American National Standard for Telecommunications - 415 Digital Hierarchy - Layer 1 In-Service Digital 416 Transmission Performance Monitoring, ANSI T1.231-1997, 417 September 1997. 419 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 420 3", BCP 9, RFC 2026, October 1996. 422 [RFC2495] Fowler, D., "Definitions of Managed Objects for the DS1, 423 E1, DS2 and E2 Interface Types", RFC 2495, January 1999. 425 [RFC2496] Fowler, D., "Definitions of Managed Objects for the 426 DS3/E3 Interface Type", RFC 2496, January 1999. 428 [RFC3592] Tesink, K., "Definitions of Managed Objects for the 429 Synchronous Optical Network/Synchronous Digital 430 Hierachy (SONET/SDH) Interface Type", RFC 3592, 431 September 2003. 433 [RFC2662] Bathrick, G. and F. Ly, "Definitions of Managed Objects 434 for the ADSL Lines", RFC 2662, August 1999. 436 [RFC2856] Bierman, A., McCloghrie, K. and R. Presuhn, "Textual 437 Conventions for Additional High Capacity Data Types", 438 RFC2856, June 2000. 440 [RFC3276] Ray, B. and R. Abbi, "Definitions of Managed Objects 441 for High Bit-rate DSL - 2nd Generation (HDSL2) and 442 Single-Pair High-Speed Digital Subscriber Line (SHDSL) 443 Lines", RFC3276, May 2002. 445 [RFC3593] Tesink, K., "Textual Conventions for MIB Modules Using 446 Performance History Based on 15 Minute Intervals", RFC 447 3593, September 2003. 449 7. Security Considerations 451 This module does not define any management objects. Instead, it 452 defines a set of textual conventions which may be used by other 453 MIB modules to define management objects. 455 Meaningful security considerations can only be written in the MIB 456 modules that define management objects. This document has 457 therefore no impact on the security of the Internet. 459 8. Acknowledgements 461 This document borrows tremendously from [RFC3593] and [RFC2856]. 462 As such, any credit for the text found within should be fully 463 attributed to the authors of those documents. 465 9. Authors' Addresses 467 Bob Ray 468 PESA Switching Systems, Inc. 469 330-A Wynn Drive 470 Huntsville, AL 35805 471 USA 473 Phone: +1 256 726 9200 ext. 142 474 Fax: +1 256 726 9271 475 EMail: rray@pesa.com 477 Rajesh Abbi 478 Alcatel USA 479 2912 Wake Forest Road 480 Raleigh, NC 27609-7860 481 USA 483 Phone: +1 919 850 6194 484 EMail: Rajesh.Abbi@alcatel.com 486 10. Full Copyright Statement 488 Copyright (C) The Internet Society (2003). All Rights Reserved. 489 This document and translations of it may be copied and furnished to 490 others, and derivative works that comment on or otherwise explain it 491 or assist in its implementation may be prepared, copied, published 492 and distributed, in whole or in part, without restriction of any 493 kind, provided that the above copyright notice and this paragraph 494 are included on all such copies and derivative works. However, this 495 document itself may not be modified in any way, such as by removing 496 the copyright notice or references to the Internet Society or other 497 Internet organizations, except as needed for the purpose of 498 developing Internet standards in which case the procedures for 499 copyrights defined in the Internet Standards process must be 500 followed, or as required to translate it into languages other than 501 English. 503 The limited permissions granted above are perpetual and will not be 504 revoked by the Internet Society or its successors or assigns. 506 This document and the information contained herein is provided on an 507 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 508 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 509 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 510 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 511 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.