idnits 2.17.1 draft-kzm-hcdata-types-04.txt: ** The Abstract section seems to be numbered 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? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 == Line 319 has weird spacing: '...imed to perta...' -- 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 (25 February 2000) is 8798 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 section? 'RFC2026' on line 383 looks like a reference -- Missing reference section? 'RFC2571' on line 392 looks like a reference -- Missing reference section? 'RFC1155' on line 345 looks like a reference -- Missing reference section? 'RFC1212' on line 355 looks like a reference -- Missing reference section? 'RFC1215' on line 359 looks like a reference -- Missing reference section? 'RFC2578' on line 417 looks like a reference -- Missing reference section? 'RFC2579' on line 424 looks like a reference -- Missing reference section? 'RFC2580' on line 430 looks like a reference -- Missing reference section? 'RFC1157' on line 349 looks like a reference -- Missing reference section? 'RFC1901' on line 363 looks like a reference -- Missing reference section? 'RFC1906' on line 374 looks like a reference -- Missing reference section? 'RFC2572' on line 396 looks like a reference -- Missing reference section? 'RFC2574' on line 406 looks like a reference -- Missing reference section? 'RFC1905' on line 368 looks like a reference -- Missing reference section? 'RFC2573' on line 402 looks like a reference -- Missing reference section? 'RFC2575' on line 411 looks like a reference -- Missing reference section? 'RFC2570' on line 386 looks like a reference -- Missing reference section? 'HC-RMON' on line 340 looks like a reference -- Missing reference section? 'RFC2021' on line 380 looks like a reference -- Missing reference section? 'APPLICATION 6' on line 146 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Andy Bierman 3 Cisco Systems, Inc. 4 Keith McCloghrie 5 Cisco Systems, Inc. 6 Randy Presuhn 7 BMC Software, Inc. 8 25 February 2000 10 Textual Conventions for Additional High Capacity Data Types 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with all 17 provisions of Section 10 of RFC2026 [RFC2026]. 19 Internet-Drafts are working documents of the Internet Engineering Task 20 Force (IETF), its areas, and its working groups. Note that other groups 21 may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference material 26 or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Distribution of this document is unlimited. Please send comments to the 35 authors. 37 1. Copyright Notice 39 Copyright (C) The Internet Society (2000). All Rights Reserved. 41 2. Abstract 43 This memo specifies new textual conventions for additional high capacity 44 data types, intended for SNMP implementations which already support the 45 Counter64 data type. The definitions contained in this document 46 represent a short term solution which may be deprecated in the future. 48 3. Table of Contents 50 1 Copyright Notice ................................................ 1 51 2 Abstract ........................................................ 2 52 3 Table of Contents ............................................... 2 53 4 The SNMP Management Framework ................................... 2 54 5 Overview ........................................................ 3 55 5.1 Short Term and Long Term Objectives ........................... 3 56 5.2 Limitations of the Textual Convention Approach ................ 4 57 6 New Textual Conventions ......................................... 5 58 6.1 CounterBasedGauge64 ........................................... 5 59 6.2 ZeroBasedCounter64 ............................................ 5 60 7 Definitions ..................................................... 5 61 8 Intellectual Property ........................................... 9 62 9 References ...................................................... 9 63 10 Security Considerations ........................................ 12 64 11 Authors' Addresses ............................................. 13 65 12 Full Copyright Statement ....................................... 14 67 4. The SNMP Management Framework 69 The SNMP Management Framework presently consists of five major 70 components: 72 o An overall architecture, described in RFC 2571 [RFC2571]. 74 o Mechanisms for describing and naming objects and events for the 75 purpose of management. The first version of this Structure of 76 Management Information (SMI) is called SMIv1 and described in 77 STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 78 1215 [RFC1215]. The second version, called SMIv2, is described 79 in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and 80 STD 58, RFC 2580 [RFC2580]. 82 o Message protocols for transferring management information. The 83 first version of the SNMP message protocol is called SNMPv1 and 84 described in STD 15, RFC 1157 [RFC1157]. A second version of 85 the SNMP message protocol, which is not an Internet standards 86 track protocol, is called SNMPv2c and described in RFC 1901 87 [RFC1901] and RFC 1906 [RFC1906]. The third version of the 88 message protocol is called SNMPv3 and described in RFC 1906 89 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. 91 o Protocol operations for accessing management information. The 92 first set of protocol operations and associated PDU formats is 93 described in STD 15, RFC 1157 [RFC1157]. A second set of 94 protocol operations and associated PDU formats is described in 95 RFC 1905 [RFC1905]. 97 o A set of fundamental applications described in RFC 2573 98 [RFC2573] and the view-based access control mechanism described 99 in RFC 2575 [RFC2575]. 101 A more detailed introduction to the current SNMP Management Framework 102 can be found in RFC 2570 [RFC2570]. 104 Managed objects are accessed via a virtual information store, termed 105 the Management Information Base or MIB. Objects in the MIB are 106 defined using the mechanisms defined in the SMI. 108 This memo specifies a MIB module that is compliant to the SMIv2. A 109 MIB conforming to the SMIv1 cannot be produced through any 110 translation, since textual conventions are not supported in SMIv1. 112 5. Overview 114 The Structure of Management Information [RFC2578] does not explicitly 115 address the question of how to represent integer objects other than 116 counters that would require up to 64 bits to provide the necessary range 117 and precision. There are MIBs in progress targeted for the standards 118 track, such as the RMON MIB for High Capacity Networks [HC-RMON], which 119 need such data types. This memo specifies a short term solution, using 120 textual conventions, to meet these needs. 122 5.1. Short Term and Long Term Objectives 124 There is an immediate need to provide a Gauge64 data type, similar in 125 semantics to the Gauge32 data type, in order to support common data 126 representations such as: 128 - a snapshot of a Counter64 at a given moment, e.g., history ring 129 buffer 131 - the difference between 2 Counter64 values 133 There is also an immediate need for a temporary zero-based counter type 134 for 64-bit, similar in semantics to the ZeroBasedCounter32 TC defined in 135 the RMON-2 MIB [RFC2021]. 137 Both of these textual conventions should use a base type of Gauge64 or 138 Unsigned64, but such a base type is not available. Until such a base 139 type is defined and deployed, these temporary textual conventions (which 140 use a base type of Counter64) will be used in MIBs such as the High 141 Capacity RMON MIB [HC-RMON]. 143 In order to be backward compatible with existing implementations of 144 Counter64, the ASN.1 encoding of unsigned 64-bit data types must be 145 identical to the encoding of Counter64 objects, i.e., identified by the 146 [APPLICATION 6] ASN.1 tag. 148 Note that the textual conventions defined in this document represent a 149 limited and short-term solution to the problem. These textual 150 conventions may be deprecated as a long term solution is defined and 151 deployed to replace them. A MIB object which uses either of these 152 textual conventions may also have to be deprecated, in which case, a 153 'duplicate' object of the appropriate type may need to be defined to 154 replace it. 156 5.2. Limitations of the Textual Convention Approach 158 New unsigned data types with textual conventions based on the Counter64 159 tag, instead of a new (or other existing) ASN.1 tag has some 160 limitations: 162 - The MAX-ACCESS of the TC must be read-only, because the MAX-ACCESS 163 of the underlying Counter64 type is read-only. 165 - No sub-range can be specified on the TC-derived types, because sub- 166 ranges are not allowed on Counter64 objects. 168 - No DEFVAL clause can be specified for the TC-derived types, because 169 DEFVALs are not allowed on Counter64 objects. 171 - The TC-derived types cannot be used in an INDEX clause, because 172 there is no INDEX clause mapping defined for objects of type 173 Counter64. 175 6. New Textual Conventions 177 The following textual conventions are defined to support unsigned 64-bit 178 data types for HC-RMON [HC-RMON]. 180 6.1. CounterBasedGauge64 182 This textual convention defines a 64-bit gauge, but defined with 183 Counter64 syntax, since no Gauge64 or Unsigned64 base type is available 184 in SMIv2. 186 This TC is used for storing the difference between 2 Counter64 values, 187 or simply storing a snapshot of a Counter64 value at a given moment in 188 time. 190 6.2. ZeroBasedCounter64 192 This textual convention defines a 64-bit counter with an initial value 193 of zero, instead of an arbitrary initial value. 195 This TC is used for counter objects in tables which are instantiated by 196 management application action. 198 7. Definitions 200 HCNUM-TC DEFINITIONS ::= BEGIN 202 IMPORTS 203 MODULE-IDENTITY, mib-2, Counter64 204 FROM SNMPv2-SMI 205 TEXTUAL-CONVENTION 206 FROM SNMPv2-TC; 208 hcnumTC MODULE-IDENTITY 209 LAST-UPDATED "200002250000Z" 210 ORGANIZATION "IETF OPS Area" 211 CONTACT-INFO 212 " E-mail: mibs@ops.ietf.org 213 Subscribe: majordomo@psg.com 214 w/ msg body: subscribe mibs 216 Andy Bierman 217 Cisco Systems Inc. 218 170 West Tasman Drive 219 San Jose, CA 95134 220 +1 408-527-3711 221 abierman@cisco.com 223 Keith McCloghrie 224 Cisco Systems Inc. 225 170 West Tasman Drive 226 San Jose, CA 95134 227 +1 408-526-5260 228 kzm@cisco.com 230 Randy Presuhn 231 BMC Software, Inc. 232 Office 1-3141 233 2141 North First Street 234 San Jose, California 95131 USA 235 +1 408 546-1006 236 rpresuhn@bmc.com" 237 DESCRIPTION 238 "A MIB module containing textual conventions 239 for high capacity data types. This module 240 addresses an immediate need for data types not directly 241 supported in the SMIv2. This short-term solution 242 is meant to be deprecated as a long-term solution 243 is deployed." 244 REVISION "200002250000Z" 245 DESCRIPTION 246 "Initial Version of the High Capacity Numbers 247 MIB module. This version published as RFC xxxx 248 (to be assigned by the RFC Editor)." 249 ::= { mib-2 xxx } 251 CounterBasedGauge64 ::= TEXTUAL-CONVENTION 252 STATUS current 253 DESCRIPTION 254 "The CounterBasedGauge64 type represents a non-negative 255 integer, which may increase or decrease, but shall never 256 exceed a maximum value, nor fall below a minimum value. The 257 maximum value can not be greater than 2^64-1 258 (18446744073709551615 decimal), and the minimum value can 259 not be smaller than 0. The value of a CounterBasedGauge64 260 has its maximum value whenever the information being modeled 261 is greater than or equal to its maximum value, and has its 262 minimum value whenever the information being modeled is 263 smaller than or equal to its minimum value. If the 264 information being modeled subsequently decreases below 265 (increases above) the maximum (minimum) value, the 266 CounterBasedGauge64 also decreases (increases). 268 Note that this TC is not strictly supported in SMIv2, 269 because the 'always increasing' and 'counter wrap' semantics 270 associated with the Counter64 base type are not preserved. 271 It is possible that management applications which rely 272 solely upon the (Counter64) ASN.1 tag to determine object 273 semantics will mistakenly operate upon objects of this type 274 as they would for Counter64 objects. 276 This textual convention represents a limited and short-term 277 solution, and may be deprecated as a long term solution is 278 defined and deployed to replace it." 279 SYNTAX Counter64 281 ZeroBasedCounter64 ::= TEXTUAL-CONVENTION 282 STATUS current 283 DESCRIPTION 284 "This TC describes an object which counts events with the 285 following semantics: objects of this type will be set to 286 zero(0) on creation and will thereafter count appropriate 287 events, wrapping back to zero(0) when the value 2^64 is 288 reached. 290 Provided that an application discovers the new object within 291 the minimum time to wrap it can use the initial value as a 292 delta since it last polled the table of which this object is 293 part. It is important for a management station to be aware 294 of this minimum time and the actual time between polls, and 295 to discard data if the actual time is too long or there is 296 no defined minimum time. 298 Typically this TC is used in tables where the INDEX space is 299 constantly changing and/or the TimeFilter mechanism is in 300 use. 302 Note that this textual convention does not retain all the 303 semantics of the Counter64 base type. Specifically, a 304 Counter64 has an arbitrary initial value, but objects 305 defined with this TC are required to start at the value 306 zero. This behavior is not likely to have any adverse 307 effects on management applications which are expecting 308 Counter64 semantics. 310 This textual convention represents a limited and short-term 311 solution, and may be deprecated as a long term solution is 312 defined and deployed to replace it." 313 SYNTAX Counter64 315 END 316 8. Intellectual Property 318 The IETF takes no position regarding the validity or scope of any 319 intellectual property or other rights that might be claimed to pertain 320 to the implementation or use of the technology described in this 321 document or the extent to which any license under such rights might or 322 might not be available; neither does it represent that it has made any 323 effort to identify any such rights. Information on the IETF's 324 procedures with respect to rights in standards-track and standards- 325 related documentation can be found in BCP-11. Copies of claims of 326 rights made available for publication and any assurances of licenses to 327 be made available, or the result of an attempt made to obtain a general 328 license or permission for the use of such proprietary rights by 329 implementors or users of this specification can be obtained from the 330 IETF Secretariat. 332 The IETF invites any interested party to bring to its attention any 333 copyrights, patents or patent applications, or other proprietary rights 334 which may cover technology that may be required to practice this 335 standard. Please address the information to the IETF Executive 336 Director. 338 9. References 340 [HC-RMON] Waldbusser, S., "Remote Network Monitoring Management 341 Information Base for High Capacity Networks", draft-ietf- 342 rmonmib-hcrmon-06.txt, International Network Services, June 343 1999. 345 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification 346 of Management Information for TCP/IP-based Internets", STD 347 16, RFC 1155, May 1990. 349 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 350 Network Management Protocol", RFC 1157, STD 15, SNMP 351 Research, Performance Systems International, Performance 352 Systems International, MIT Laboratory for Computer Science, 353 May 1990. 355 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 356 1212, STD 16, Performance Systems International, Hughes LAN 357 Systems, March 1991. 359 [RFC1215] M. Rose, "A Convention for Defining Traps for use with the 360 SNMP", RFC 1215, Performance Systems International, March 361 1991. 363 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 364 "Introduction to Community-based SNMPv2", RFC 1901, SNMP 365 Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, 366 Inc., International Network Services, January 1996. 368 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 369 "Protocol Operations for Version 2 of the Simple Network 370 Management Protocol (SNMPv2)", RFC 1905, SNMP Research, 371 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 372 International Network Services, January 1996. 374 [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 375 "Transport Mappings for Version 2 of the Simple Network 376 Management Protocol (SNMPv2)", RFC 1906, SNMP Research, 377 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 378 International Network Services, January 1996. 380 [RFC2021] S. Waldbusser, "Remote Network Monitoring MIB (RMON-2)", RFC 381 2021, International Network Services, January 1997. 383 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", 384 RFC 2026, Harvard University, October, 1996. 386 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, 387 "Introduction to Version 3 of the Internet-standard Network 388 Management Framework", RFC 2570, SNMP Research, Inc., TIS 389 Labs at Network Associates, Inc., Ericsson, Cisco Systems, 390 April 1999. 392 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture 393 for Describing SNMP Management Frameworks", RFC 2571, April 394 1999. 396 [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 397 Processing and Dispatching for the Simple Network Management 398 Protocol (SNMP)", RFC 2572, SNMP Research, Inc., Cabletron 399 Systems, Inc., BMC Software, Inc., IBM T. J. Watson 400 Research, April 1999. 402 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", 403 RFC 2573, SNMP Research, Inc., Secure Computing Corporation, 404 Cisco Systems, April 1999. 406 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model 407 (USM) for version 3 of the Simple Network Management 408 Protocol (SNMPv3)", RFC 2574, IBM T. J. Watson Research, 409 April 1999. 411 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 412 Access Control Model (VACM) for the Simple Network 413 Management Protocol (SNMP)", RFC 2575, IBM T. J. Watson 414 Research, BMC Software, Inc., Cisco Systems, Inc., April 415 1999. 417 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 418 Rose, M., and S. Waldbusser, "Structure of Management 419 Information Version 2 (SMIv2)", RFC 2578, STD 58, Cisco 420 Systems, SNMPinfo, TU Braunschweig, SNMP Research, First 421 Virtual Holdings, International Network Services, April 422 1999. 424 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 425 Rose, M., and S. Waldbusser, "Textual Conventions for 426 SMIv2", RFC 2579, STD 58, Cisco Systems, SNMPinfo, TU 427 Braunschweig, SNMP Research, First Virtual Holdings, 428 International Network Services, April 1999. 430 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 431 Rose, M., and S. Waldbusser, "Conformance Statements for 432 SMIv2", RFC 2580, STD 58, Cisco Systems, SNMPinfo, TU 433 Braunschweig, SNMP Research, First Virtual Holdings, 434 International Network Services, April 1999. 436 10. Security Considerations 438 This module does not define any management objects. Instead, it defines 439 a set of textual conventions which may be used by other MIB modules to 440 define management objects. 442 Meaningful security considerations can only be written in the modules 443 that define management objects. 445 11. Authors' Addresses 447 Andy Bierman 448 Cisco Systems, Inc. 449 170 West Tasman Drive 450 San Jose, CA 95134 USA 451 Phone: +1 408-527-3711 452 Email: abierman@cisco.com 454 Keith McCloghrie 455 Cisco Systems, Inc. 456 170 West Tasman Drive 457 San Jose, CA 95134 USA 458 Phone: +1 408-526-5260 459 Email: kzm@cisco.com 461 Randy Presuhn 462 BMC Software, Inc. 463 Office 1-3141 464 2141 North First Street 465 San Jose, California 95131 USA 466 Phone: +1 408 546-1006 467 EMail: rpresuhn@bmc.com 469 12. Full Copyright Statement 471 Copyright (C) The Internet Society (2000). All Rights Reserved. 473 This document and translations of it may be copied and furnished to 474 others, and derivative works that comment on or otherwise explain it or 475 assist in its implementation may be prepared, copied, published and 476 distributed, in whole or in part, without restriction of any kind, 477 provided that the above copyright notice and this paragraph are included 478 on all such copies and derivative works. However, this document itself 479 may not be modified in any way, such as by removing the copyright notice 480 or references to the Internet Society or other Internet organizations, 481 except as needed for the purpose of developing Internet standards in 482 which case the procedures for copyrights defined in the Internet 483 Standards process must be followed, or as required to translate it into 484 languages other than English. 486 The limited permissions granted above are perpetual and will not be 487 revoked by the Internet Society or its successors or assigns. 489 This document and the information contained herein is provided on an "AS 490 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 491 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 492 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 493 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 494 FITNESS FOR A PARTICULAR PURPOSE.