idnits 2.17.1 draft-ietf-adslmib-hc-tc-04.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 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.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 460: '... It is RECOMMENDED that implementers...' RFC 2119 keyword, line 466: '... RECOMMENDED. Instead, it is RECOMM...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 (June 2003) is 7620 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 411, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2493 (Obsoleted by RFC 3593) -- 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 2558 (Obsoleted by RFC 3592) -- Obsolete informational reference (is this intentional?): RFC 3276 (Obsoleted by RFC 4319) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 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 June 2003 7 High Capacity Textual Conventions for MIB Modules Using 8 Performance History Based on 15 Minute Intervals 9 draft-ietf-adslmib-hc-tc-04.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 2493 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 .............................................. 10 54 9. Authors' Addresses ............................................ 10 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 2. Overview 74 In cases where a manager must obtain performance history data about 75 the behavior of equipment it manages, several strategies can be 76 followed in the design of a MIB module that represents the managed 77 equipment, including: 79 - The agent counts events on a continuous basis and, whenever 80 desired, the manager obtains the value of the event counter and 81 adjusts its understanding of the history of events at the agent. 83 - The agent allocates events to 'buckets' where each bucket 84 represents an interval of time. 86 Telecommunications equipment often makes use of the latter strategy. 87 For such equipment the standard practice is that history data is 88 maintained by the agent in terms of 15-minute intervals [T1.231]. 90 MIB modules for collecting performance history based on 15-minute 91 intervals have been defined for the DS1/E1 [RFC2495], DS3/E3 92 [RFC2496], SONET/SDH [RFC2558], ADSL [RFC2662], HDLS2 and SHDSL 93 [RFC3276] interface types. These MIB modules use a common set of 94 textual conventions defined in [RFC2493]. Those textual 95 conventions are based on the Gauge32 data type. 97 A need has arisen to define 64-bit versions of the textual 98 conventions in [RFC2493]. Ideally, these high-capacity textual 99 conventions would be based on a Gauge64 or Unsigned64 data type, but 100 unfortunately no such types exist in SMIv2. The next best choice 101 would be to base them on the CounterBasedGauge64 textual convention 102 presented in [RFC2856], but that is not possible either since SMIv2 103 allows only base types to be used in defining textual conventions. 104 Therefore, the textual conventions presented in this memo are based 105 directly on the Counter64 type, like those in [RFC2856]. They are 106 subject to the following limitations: 108 - The MAX-ACCESS of objects defined using these textual conventions 109 must be read-only, because the MAX-ACCESS of the underlying 110 Counter64 type is read-only. 112 - No sub-range can be specified in object definitions using these 113 textual conventions, because sub-ranges are not allowed on 114 Counter64 objects. 116 - No DEFVAL clause can be specified in object definitions using 117 these textual conventions, because DEFVALs are not allowed on 118 Counter64 objects. 120 - Objects defined using these textual conventions cannot be used 121 in an INDEX clause, because there is no INDEX clause mapping 122 defined for objects of type Counter64. 124 Use of the textual conventions presented in this memo assumes the 125 following: 127 - The agent supports 15 minute based history counters. 129 - The agent is capable of keeping a history of 96 intervals of 15 130 minute performance data. 132 - The agent may optionally support performance data aggregating the 133 history intervals. 135 - The agent will keep separate tables for the current interval, the 136 history intervals, and the total aggregates. 138 3. Definitions 140 HC-PerfHist-TC-MIB DEFINITIONS ::= BEGIN 142 IMPORTS 143 MODULE-IDENTITY, 144 Counter64, 145 Unsigned32, 146 Gauge32, 147 mib-2 FROM SNMPv2-SMI 148 TEXTUAL-CONVENTION FROM SNMPv2-TC; 150 hcPerfHistTCMIB MODULE-IDENTITY 151 LAST-UPDATED "200306060000Z" -- June 6, 2003 152 ORGANIZATION "ADSLMIB Working Group" 153 CONTACT-INFO "WG-email: adslmib@ietf.org 154 Info: https://www1.ietf.org/mailman/listinfo/adslmib 156 Chair: Mike Sneed 157 Sand Channel Systems 158 Postal: P.O. Box 37324 159 Raleigh NC 27627-7324 160 USA 161 Email: sneedmike@hotmail.com 162 Phone: +1 206 600 7022 164 Co-editor: Bob Ray 165 PESA Switching Systems, Inc. 166 Postal: 330-A Wynn Drive 167 Huntsville, AL 35805 168 USA 169 Email: rray@pesa.com 170 Phone: +1 256 726 9200 ext. 142 172 Co-editor: Rajesh Abbi 173 Alcatel USA 174 Postal: 2912 Wake Forest Road 175 Raleigh, NC 27609-7860 176 USA 177 Email: Rajesh.Abbi@alcatel.com 178 Phone: +1 919 850 6194 179 " 180 DESCRIPTION 181 "This MIB Module provides Textual Conventions to be 182 used by systems supporting 15 minute based performance 183 history counts that require high-capacity counts. 185 Copyright (C) The Internet Society (2003). This version 186 of this MIB module is part of RFC XXXX: see the RFC 187 itself for full legal notices." 188 -- RFC Ed.: replace XXXX with assigned number & remove this note 189 REVISION "200306060000Z" -- June 6, 2003 190 DESCRIPTION "Initial version, published as RFC XXXX." 191 -- RFC Ed.: replace XXXX with assigned number & remove this note 192 ::= { mib-2 YYYY } 193 -- RFC Ed.: replace YYYY with IANA-assigned number & remove this note 195 HCPerfValidIntervals ::= TEXTUAL-CONVENTION 196 STATUS current 197 DESCRIPTION 198 "The number of near end intervals for which data was 199 collected. The value of an object with an 200 HCPerfValidIntervals syntax will be 96 unless the 201 measurement was (re-)started within the last 1440 minutes, 202 in which case the value will be the number of complete 15 203 minute intervals for which the agent has at least some data. 204 In certain cases (e.g., in the case where the agent is a 205 proxy) it is possible that some intervals are unavailable. 206 In this case, this interval is the maximum interval number 207 for which data is available." 208 SYNTAX Gauge32 (0..96) 210 HCPerfInvalidIntervals ::= TEXTUAL-CONVENTION 211 STATUS current 212 DESCRIPTION 213 "The number of near end intervals for which no data is 214 available. The value of an object with an 215 HCPerfInvalidIntervals syntax will typically be zero except 216 in cases where the data for some intervals are not available 217 (e.g., in proxy situations)." 218 SYNTAX Gauge32 (0..96) 220 HCPerfTimeElapsed ::= TEXTUAL-CONVENTION 221 STATUS current 222 DESCRIPTION 223 "The number of seconds that have elapsed since the beginning 224 of the current measurement period. If, for some reason, 225 such as an adjustment in the system's time-of-day clock or 226 the addition of a leap second, the duration of the current 227 interval exceeds the maximum value, the agent will return 228 the maximum value. 230 For 15 minute intervals, the range is limited to (0..899). 231 For 24 hour intervals, the range is limited to (0..86399)." 232 SYNTAX Gauge32 (0..86399) 234 HCPerfIntervalThreshold ::= TEXTUAL-CONVENTION 235 STATUS current 236 DESCRIPTION 237 "This convention defines a range of values that may be set 238 in a fault threshold alarm control. As the number of 239 seconds in a 15-minute interval numbers at most 900, 240 objects of this type may have a range of 0...900, where the 241 value of 0 disables the alarm." 242 SYNTAX Unsigned32 (0..900) 244 HCPerfCurrentCount ::= TEXTUAL-CONVENTION 245 STATUS current 246 DESCRIPTION 247 "A gauge associated with a performance measurement in a 248 current 15 minute measurement interval. The value of an 249 object with an HCPerfCurrentCount syntax starts from zero 250 and is increased when associated events occur, until the 251 end of the 15 minute interval. At that time the value of 252 the gauge is stored in the first 15 minute history 253 interval, and the gauge is restarted at zero. In the case 254 where the agent has no valid data available for the 255 current interval, the corresponding object instance is not 256 available and upon a retrieval request a corresponding 257 error message shall be returned to indicate that this 258 instance does not exist. 260 This count represents a non-negative integer, which 261 may increase or decrease, but shall never exceed 2^64-1 262 (18446744073709551615 decimal), nor fall below 0. The 263 The value of an object with HCPerfCurrentCount syntax 264 assumes its maximum value whenever the underlying count 265 exceeds 2^64-1. If the underlying count subsequently 266 decreases below 2^64-1 (due, e.g., to a retroactive 267 adjustment as a result of entering or exiting unavailable 268 time), then the object's value also decreases. 270 Note that this TC is not strictly supported in SMIv2, 271 because the 'always increasing' and 'counter wrap' 272 semantics associated with the Counter64 base type are not 273 preserved. It is possible that management applications 274 which rely solely upon the (Counter64) ASN.1 tag to 275 determine object semantics will mistakenly operate upon 276 objects of this type as they would for Counter64 objects. 278 This textual convention represents a limited and short- 279 term solution, and may be deprecated as a long term 280 solution is defined and deployed to replace it." 281 SYNTAX Counter64 283 HCPerfIntervalCount ::= TEXTUAL-CONVENTION 284 STATUS current 285 DESCRIPTION 286 "A gauge associated with a performance measurement in 287 a previous 15 minute measurement interval. In the case 288 where the agent has no valid data available for a 289 particular interval, the corresponding object instance is 290 not available and upon a retrieval request a corresponding 291 error message shall be returned to indicate that this 292 instance does not exist. 294 Let X be an object with HCPerfIntervalCount syntax. 295 Let Y be an object with HCPerfCurrentCount syntax. 296 Let Z be an object with HCPerfTotalCount syntax. 297 Then, In a system supporting a history of n intervals with 298 X(1) and X(n) the most and least recent intervals 299 respectively, the following applies at the end of a 15 300 minute interval: 302 - discard the value of X(n) 303 - the value of X(i) becomes that of X(i-1) 304 for n >= i > 1 305 - the value of X(1) becomes that of Y. 307 - the value of Z, if supported, is adjusted. 309 This count represents a non-negative integer, which 310 may increase or decrease, but shall never exceed 2^64-1 311 (18446744073709551615 decimal), nor fall below 0. The 312 The value of an object with HCPerfIntervalCount syntax 313 assumes its maximum value whenever the underlying count 314 exceeds 2^64-1. If the underlying count subsequently 315 decreases below 2^64-1 (due, e.g., to a retroactive 316 adjustment as a result of entering or exiting unavailable 317 time), then the value of the object also decreases. 319 Note that this TC is not strictly supported in SMIv2, 320 because the 'always increasing' and 'counter wrap' 321 semantics associated with the Counter64 base type are not 322 preserved. It is possible that management applications 323 which rely solely upon the (Counter64) ASN.1 tag to 324 determine object semantics will mistakenly operate upon 325 objects of this type as they would for Counter64 objects. 327 This textual convention represents a limited and short- 328 term solution, and may be deprecated as a long term 329 solution is defined and deployed to replace it." 330 SYNTAX Counter64 332 HCPerfTotalCount ::= TEXTUAL-CONVENTION 333 STATUS current 334 DESCRIPTION 335 "A gauge representing the aggregate of previous valid 15 336 minute measurement intervals. Intervals for which no 337 valid data was available are not counted. 339 This count represents a non-negative integer, which 340 may increase or decrease, but shall never exceed 2^64-1 341 (18446744073709551615 decimal), nor fall below 0. The 342 The value of an object with HCPerfTotalCount syntax 343 assumes its maximum value whenever the underlying count 344 exceeds 2^64-1. If the underlying count subsequently 345 decreases below 2^64-1 (due, e.g., to a retroactive 346 adjustment as a result of entering or exiting unavailable 347 time), then the object's value also decreases. 349 Note that this TC is not strictly supported in SMIv2, 350 because the 'always increasing' and 'counter wrap' 351 semantics associated with the Counter64 base type are not 352 preserved. It is possible that management applications 353 which rely solely upon the (Counter64) ASN.1 tag to 354 determine object semantics will mistakenly operate upon 355 objects of this type as they would for Counter64 objects. 357 This textual convention represents a limited and short- 358 term solution, and may be deprecated as a long term 359 solution is defined and deployed to replace it." 360 SYNTAX Counter64 361 END 363 4. Intellectual Property 365 The IETF takes no position regarding the validity or scope of any 366 intellectual property or other rights that might be claimed to 367 pertain to the implementation or use of the technology described in 368 this document or the extent to which any license under such rights 369 might or might not be available; neither does it represent that it 370 has made any effort to identify any such rights. Information on the 371 IETF's procedures with respect to rights in standards-track and 372 standards-related documentation can be found in BCP-11. Copies of 373 claims of rights made available for publication and any assurances 374 of licenses to be made available, or the result of an attempt made 375 to obtain a general license or permission for the use of such 376 proprietary rights by implementors or users of this specification 377 can be obtained from the IETF Secretariat. 379 The IETF invites any interested party to bring to its attention any 380 copyrights, patents or patent applications, or other proprietary 381 rights which may cover technology that may be required to practice 382 this standard. Please address the information to the IETF Executive 383 Director. 385 5. Normative References 387 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 388 Rose, M. and S. Waldbusser, "Structure of Management 389 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 390 1999. 392 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 393 Rose, M. and S. Waldbusser, "Textual Conventions for 394 SMIv2", STD 58, RFC 2579, April 1999. 396 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 397 Rose, M. and S. Waldbusser, "Conformance Statements for 398 SMIv2", STD 58, RFC 2580, April 1999. 400 6. Informative References 402 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 403 "Introduction and Applicability Statements for Internet- 404 Standard Management Framework", RFC 3410, December 2002. 406 [T1.231] American National Standard for Telecommunications - 407 Digital Hierarchy - Layer 1 In-Service Digital 408 Transmission Performance Monitoring, ANSI T1.231-1997, 409 September 1997. 411 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 412 3", BCP 9, RFC 2026, October 1996. 414 [RFC2493] Tesink, K., "Textual Conventions for MIB Modules Using 415 Performance History Based on 15 Minute Intervals", RFC 416 2493, January 1999. 418 [RFC2495] Fowler, D., "Definitions of Managed Objects for the DS1, 419 E1, DS2 and E2 Interface Types", RFC 2495, January 1999. 421 [RFC2496] Fowler, D., "Definitions of Managed Objects for the 422 DS3/E3 Interface Type", RFC 2496, January 1999. 424 [RFC2558] Tesink, K., "Definitions of Managed Objects for the 425 SONET/SDH Interface Type", RFC 2558, March 1999. 427 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 428 Rose, M. and S. Waldbusser, "Structure of Management 429 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 430 1999. 432 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 433 Rose, M. and S. Waldbusser, "Textual Conventions for 434 SMIv2", STD 58, RFC 2579, April 1999. 436 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 437 Rose, M. and S. Waldbusser, "Conformance Statements for 438 SMIv2", STD 58, RFC 2580, April 1999. 440 [RFC2662] Bathrick, G. and F. Ly, "Definitions of Managed Objects 441 for the ADSL Lines", RFC 2662, August 1999. 443 [RFC2856] Bierman, A., McCloghrie, K. and R. Presuhn, "Textual 444 Conventions for Additional High Capacity Data Types", 445 RFC2856, June 2000. 447 [RFC3276] Ray, B. and R. Abbi, "Definitions of Managed Objects 448 for High Bit-rate DSL - 2nd Generation (HDSL2) and 449 Single-Pair High-Speed Digital Subscriber Line (SHDSL) 450 Lines", RFC3276, May 2002. 452 7. Security Considerations 454 SNMP versions prior to SNMPv3 did not include adequate security. 455 Even if the network itself is secure (for example by using IPSec), 456 even then, there is no control as to who on the secure network is 457 allowed to access and GET/SET (read/change/create/delete) objects 458 which utilize the textual conventions defined in this MIB module. 460 It is RECOMMENDED that implementers consider the security features 461 as provided by the SNMPv3 framework (see [RFC3410], section 8), 462 including full support for the SNMPv3 cryptographic mechanisms (for 463 authentication and privacy). 465 Further, deployment of SNMP versions prior to SNMPv3 is NOT 466 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 467 enable cryptographic security. It is then a customer/operator 468 responsibility to ensure that the SNMP entity giving access to an 469 instance of a MIB module which utilizes the textual conventions 470 defined in this MIB module is properly configured to give access to 471 the objects only to those principals (users) that have legitimate 472 rights to indeed GET or SET (change/create/delete) them. 474 8. Acknowledgements 476 This document borrows tremendously from [RFC2493] and [RFC2856]. 477 As such, any credit for the text found within should be fully 478 attributed to the authors of those documents. 480 9. Authors' Addresses 482 Bob Ray 483 PESA Switching Systems, Inc. 484 330-A Wynn Drive 485 Huntsville, AL 35805 486 USA 488 Phone: +1 256 726 9200 ext. 142 489 Fax: +1 256 726 9271 490 EMail: rray@pesa.com 492 Rajesh Abbi 493 Alcatel USA 494 2912 Wake Forest Road 495 Raleigh, NC 27609-7860 496 USA 498 Phone: +1 919 850 6194 499 EMail: Rajesh.Abbi@alcatel.com 501 10. Full Copyright Statement 503 Copyright (C) The Internet Society (2003). All Rights Reserved. 504 This document and translations of it may be copied and furnished to 505 others, and derivative works that comment on or otherwise explain it 506 or assist in its implementation may be prepared, copied, published 507 and distributed, in whole or in part, without restriction of any 508 kind, provided that the above copyright notice and this paragraph 509 are included on all such copies and derivative works. However, this 510 document itself may not be modified in any way, such as by removing 511 the copyright notice or references to the Internet Society or other 512 Internet organizations, except as needed for the purpose of 513 developing Internet standards in which case the procedures for 514 copyrights defined in the Internet Standards process must be 515 followed, or as required to translate it into languages other than 516 English. 518 The limited permissions granted above are perpetual and will not be 519 revoked by the Internet Society or its successors or assigns. 521 This document and the information contained herein is provided on an 522 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 523 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 524 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 525 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 526 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.