doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc2856.txt b/doc/rfc/rfc2856.txt
new file mode 100644
index 0000000..52f8a60
--- /dev/null
+++ b/doc/rfc/rfc2856.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                        A. Bierman
+Request for Comments: 2856                                K. McCloghrie
+Category: Standards Track                           Cisco Systems, Inc.
+                                                             R. Presuhn
+                                                     BMC Software, Inc.
+                                                              June 2000
+
+
+      Textual Conventions for Additional High Capacity Data Types
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This memo specifies new textual conventions for additional high
+   capacity data types, intended for SNMP implementations which already
+   support the Counter64 data type. The definitions contained in this
+   document represent a short term solution which may be deprecated in
+   the future.
+
+Table of Contents
+
+   1 The SNMP Management Framework .................................  2
+   2 Overview ......................................................  3
+   2.1 Short Term and Long Term Objectives .........................  3
+   2.2 Limitations of the Textual Convention Approach ..............  3
+   3 New Textual Conventions .......................................  4
+   3.1 CounterBasedGauge64 .........................................  4
+   3.2 ZeroBasedCounter64 ..........................................  4
+   4 Definitions ...................................................  4
+   5 Intellectual Property .........................................  7
+   6 References ....................................................  7
+   7 Security Considerations .......................................  9
+   8 Authors' Addresses ............................................  9
+   9 Full Copyright Statement ...................................... 10
+
+
+
+
+
+
+Bierman, et al.             Standards Track                     [Page 1]
+
+RFC 2856                High Capacity Data Types               June 2000
+
+
+1.  The SNMP Management Framework
+
+   The SNMP Management Framework presently consists of five major
+   components:
+
+   o   An overall architecture, described in RFC 2571 [RFC2571].
+
+   o   Mechanisms for describing and naming objects and events for the
+       purpose of management. The first version of this Structure of
+       Management Information (SMI) is called SMIv1 and described in STD
+       16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215
+       [RFC1215].  The second version, called SMIv2, is described in STD
+       58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58,
+       RFC 2580 [RFC2580].
+
+   o   Message protocols for transferring management information. The
+       first version of the SNMP message protocol is called SNMPv1 and
+       described in STD 15, RFC 1157 [RFC1157].  A second version of the
+       SNMP message protocol, which is not an Internet standards track
+       protocol, is called SNMPv2c and described in RFC 1901 [RFC1901]
+       and RFC 1906 [RFC1906].  The third version of the message
+       protocol is called SNMPv3 and described in RFC 1906 [RFC1906],
+       RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
+
+   o   Protocol operations for accessing management information. The
+       first set of protocol operations and associated PDU formats is
+       described in STD 15, RFC 1157 [RFC1157].  A second set of
+       protocol operations and associated PDU formats is described in
+       RFC 1905 [RFC1905].
+
+   o   A set of fundamental applications described in RFC 2573 [RFC2573]
+       and the view-based access control mechanism described in RFC 2575
+       [RFC2575].
+
+   A more detailed introduction to the current SNMP Management Framework
+   can be found in RFC 2570 [RFC2570].
+
+   Managed objects are accessed via a virtual information store, termed
+   the Management Information Base or MIB.  Objects in the MIB are
+   defined using the mechanisms defined in the SMI.
+
+   This memo specifies a MIB module that is compliant to the SMIv2.  The
+   textual conventions defined in this MIB module cannot be translated
+   to SMIv1 since the Counter64 type does not exist in SMIv1.
+
+
+
+
+
+
+
+Bierman, et al.             Standards Track                     [Page 2]
+
+RFC 2856                High Capacity Data Types               June 2000
+
+
+2.  Overview
+
+   The Structure of Management Information [RFC2578] does not explicitly
+   address the question of how to represent integer objects other than
+   counters that would require up to 64 bits to provide the necessary
+   range and precision.  There are MIBs in progress targeted for the
+   standards track, which need such data types. This memo specifies a
+   short term solution, using textual conventions, to meet these needs.
+
+2.1.  Short Term and Long Term Objectives
+
+   There is an immediate need to provide a Gauge64 data type, similar in
+   semantics to the Gauge32 data type, in order to support common data
+   representations such as:
+
+   -  a snapshot of a Counter64 at a given moment, e.g., history ring
+      buffer
+
+   -  the difference between two Counter64 values
+
+   There is also an immediate need for a 64-bit zero-based counter type,
+   similar in semantics to the ZeroBasedCounter32 TC defined in the
+   RMON-2 MIB [RFC2021].
+
+   Both of these textual conventions should use a base type of Gauge64
+   or Unsigned64, but such a base type is not available.  Until such a
+   base type is defined and deployed, these temporary textual
+   conventions (which use a base type of Counter64) will be used in MIBs
+   which require unsigned 64-bit data types.
+
+   In order to be backward compatible with existing implementations of
+   Counter64, the ASN.1 encoding of unsigned 64-bit data types must be
+   identical to the encoding of Counter64 objects, i.e., identified by
+   the [APPLICATION 6] ASN.1 tag.
+
+   Note that the textual conventions defined in this document represent
+   a limited and short-term solution to the problem.  These textual
+   conventions may be deprecated as a long term solution is defined and
+   deployed to replace them.  A MIB object which uses either of these
+   textual conventions may also eventually have to be deprecated.
+
+2.2.  Limitations of the Textual Convention Approach
+
+   New unsigned data types with textual conventions based on the
+   Counter64 tag, instead of a new (or other existing) ASN.1 tag have
+   some limitations:
+
+
+
+
+
+Bierman, et al.             Standards Track                     [Page 3]
+
+RFC 2856                High Capacity Data Types               June 2000
+
+
+   -  The MAX-ACCESS of the TC must be read-only, because the MAX-ACCESS
+      of the underlying Counter64 type is read-only.
+
+   -  No sub-range can be specified on the TC-derived types, because
+      sub-ranges are not allowed on Counter64 objects.
+
+   -  No DEFVAL clause can be specified for the TC-derived types,
+      because DEFVALs are not allowed on Counter64 objects.
+
+   -  The TC-derived types cannot be used in an INDEX clause, because
+      there is no INDEX clause mapping defined for objects of type
+      Counter64.
+
+3.  New Textual Conventions
+
+   The following textual conventions are defined to support unsigned
+   64-bit data types.
+
+3.1.  CounterBasedGauge64
+
+   This textual convention defines a 64-bit gauge, but defined with
+   Counter64 syntax, since no Gauge64 or Unsigned64 base type is
+   available in SMIv2.
+
+   This TC is used for storing the difference between two Counter64
+   values, or simply storing a snapshot of a Counter64 value at a given
+   moment in time.
+
+3.2.  ZeroBasedCounter64
+
+   This textual convention defines a 64-bit counter with an initial
+   value of zero, instead of an arbitrary initial value.
+
+   This TC is used for counter objects in tables which are instantiated
+   by management application action.
+
+4. Definitions
+
+   HCNUM-TC DEFINITIONS ::= BEGIN
+
+   IMPORTS
+     MODULE-IDENTITY, mib-2, Counter64
+         FROM SNMPv2-SMI
+     TEXTUAL-CONVENTION
+         FROM SNMPv2-TC;
+
+   hcnumTC MODULE-IDENTITY
+     LAST-UPDATED "200006080000Z"
+
+
+
+Bierman, et al.             Standards Track                     [Page 4]
+
+RFC 2856                High Capacity Data Types               June 2000
+
+
+     ORGANIZATION "IETF OPS Area"
+     CONTACT-INFO
+           "        E-mail: mibs@ops.ietf.org
+                    Subscribe: majordomo@psg.com
+                      with msg body: subscribe mibs
+
+                    Andy Bierman
+                    Cisco Systems Inc.
+                    170 West Tasman Drive
+                    San Jose, CA 95134 USA
+                    +1 408-527-3711
+                    abierman@cisco.com
+
+                    Keith McCloghrie
+                    Cisco Systems Inc.
+                    170 West Tasman Drive
+                    San Jose, CA 95134 USA
+                    +1 408-526-5260
+                    kzm@cisco.com
+
+                    Randy Presuhn
+                    BMC Software, Inc.
+                    Office 1-3141
+                    2141 North First Street
+                    San Jose,  California 95131 USA
+                    +1 408 546-1006
+                    rpresuhn@bmc.com"
+     DESCRIPTION
+           "A MIB module containing textual conventions
+            for high capacity data types. This module
+            addresses an immediate need for data types not directly
+            supported in the SMIv2. This short-term solution
+            is meant to be deprecated as a long-term solution
+            is deployed."
+     REVISION        "200006080000Z"
+     DESCRIPTION
+           "Initial Version of the High Capacity Numbers
+            MIB module, published as RFC 2856."
+     ::= { mib-2 78 }
+
+   CounterBasedGauge64 ::= TEXTUAL-CONVENTION
+     STATUS       current
+     DESCRIPTION
+           "The CounterBasedGauge64 type represents a non-negative
+           integer, which may increase or decrease, but shall never
+           exceed a maximum value, nor fall below a minimum value. The
+           maximum value can not be greater than 2^64-1
+           (18446744073709551615 decimal), and the minimum value can
+
+
+
+Bierman, et al.             Standards Track                     [Page 5]
+
+RFC 2856                High Capacity Data Types               June 2000
+
+
+           not be smaller than 0.  The value of a CounterBasedGauge64
+           has its maximum value whenever the information being modeled
+           is greater than or equal to its maximum value, and has its
+           minimum value whenever the information being modeled is
+           smaller than or equal to its minimum value.  If the
+           information being modeled subsequently decreases below
+           (increases above) the maximum (minimum) value, the
+           CounterBasedGauge64 also decreases (increases).
+
+           Note that this TC is not strictly supported in SMIv2,
+           because the 'always increasing' and 'counter wrap' semantics
+           associated with the Counter64 base type are not preserved.
+           It is possible that management applications which rely
+           solely upon the (Counter64) ASN.1 tag to determine object
+           semantics will mistakenly operate upon objects of this type
+           as they would for Counter64 objects.
+
+           This textual convention represents a limited and short-term
+           solution, and may be deprecated as a long term solution is
+           defined and deployed to replace it."
+     SYNTAX Counter64
+
+
+   ZeroBasedCounter64 ::= TEXTUAL-CONVENTION
+     STATUS current
+     DESCRIPTION
+           "This TC describes an object which counts events with the
+           following semantics: objects of this type will be set to
+           zero(0) on creation and will thereafter count appropriate
+           events, wrapping back to zero(0) when the value 2^64 is
+           reached.
+
+           Provided that an application discovers the new object within
+           the minimum time to wrap it can use the initial value as a
+           delta since it last polled the table of which this object is
+           part.  It is important for a management station to be aware
+           of this minimum time and the actual time between polls, and
+           to discard data if the actual time is too long or there is
+           no defined minimum time.
+
+           Typically this TC is used in tables where the INDEX space is
+           constantly changing and/or the TimeFilter mechanism is in
+           use.
+
+           Note that this textual convention does not retain all the
+           semantics of the Counter64 base type. Specifically, a
+           Counter64 has an arbitrary initial value, but objects
+           defined with this TC are required to start at the value
+
+
+
+Bierman, et al.             Standards Track                     [Page 6]
+
+RFC 2856                High Capacity Data Types               June 2000
+
+
+           zero.  This behavior is not likely to have any adverse
+           effects on management applications which are expecting
+           Counter64 semantics.
+
+           This textual convention represents a limited and short-term
+           solution, and may be deprecated as a long term solution is
+           defined and deployed to replace it."
+     SYNTAX Counter64
+
+   END
+
+5.  Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards- related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+6.  References
+
+   [RFC1155]   Rose, M. and K. McCloghrie, "Structure and Identification
+               of Management Information for TCP/IP-based Internets",
+               STD 16, RFC 1155, May 1990.
+
+   [RFC1157]   Case, J., Fedor, M., Schoffstall, M. and J. Davin,
+               "Simple Network Management Protocol", STD 15, RFC 1157,
+               May 1990.
+
+   [RFC1212]   Rose, M. and K. McCloghrie, "Concise MIB Definitions",
+               STD 16, RFC 1212, March 1991.
+
+   [RFC1215]   Rose, M., "A Convention for Defining Traps for use with
+               the SNMP", RFC 1215, March 1991.
+
+
+
+Bierman, et al.             Standards Track                     [Page 7]
+
+RFC 2856                High Capacity Data Types               June 2000
+
+
+   [RFC1901]   Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
+               "Introduction to Community-based SNMPv2", RFC 1901,
+               January 1996.
+
+   [RFC1905]   Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
+               "Protocol Operations for Version 2 of the Simple Network
+               Management Protocol (SNMPv2)", RFC 1905, January 1996.
+
+   [RFC1906]   Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
+               "Transport Mappings for Version 2 of the Simple Network
+               Management Protocol (SNMPv2)", RFC 1906, January 1996.
+
+   [RFC2021]   Waldbusser, S., "Remote Network Monitoring MIB (RMON-2)",
+               RFC 2021, January 1997.
+
+   [RFC2026]   Bradner, S., "The Internet Standards Process -- Revision
+               3", BCP 9, RFC 2026, October 1996.
+
+   [RFC2570]   Case, J., Mundy, R., Partain, D. and B. Stewart,
+               "Introduction to Version 3 of the Internet-standard
+               Network Management Framework", RFC 2570, April 1999.
+
+   [RFC2571]   Harrington, D., Presuhn, R. and B. Wijnen, "An
+               Architecture for Describing SNMP Management Frameworks",
+               RFC 2571, April 1999.
+
+   [RFC2572]   Case, J., Harrington D., Presuhn R. and B. Wijnen,
+               "Message Processing and Dispatching for the Simple
+               Network Management Protocol (SNMP)", RFC 2572, April
+               1999.
+
+   [RFC2573]   Levi, D., Meyer, P. and B. Stewart, "SNMPv3
+               Applications", RFC 2573, April 1999.
+
+   [RFC2574]   Blumenthal, U. and B. Wijnen, "User-based Security Model
+               (USM) for version 3 of the Simple Network Management
+               Protocol (SNMPv3)", RFC 2574, April 1999.
+
+   [RFC2575]   Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
+               Access Control Model (VACM) for the Simple Network
+               Management Protocol (SNMP)", RFC 2575, April 1999.
+
+   [RFC2578]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+               Rose, M. and S. Waldbusser, "Structure of Management
+               Information Version 2 (SMIv2)", STD 58, RFC 2578, April
+               1999.
+
+
+
+
+
+Bierman, et al.             Standards Track                     [Page 8]
+
+RFC 2856                High Capacity Data Types               June 2000
+
+
+   [RFC2579]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+               Rose, M. and S. Waldbusser, "Textual Conventions for
+               SMIv2", STD 58, RFC 2579, April 1999.
+
+   [RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+               Rose, M. and S. Waldbusser, "Conformance Statements for
+               SMIv2", STD 58, RFC 2580, April 1999.
+
+7.  Security Considerations
+
+   This module does not define any management objects. Instead, it
+   defines a set of textual conventions which may be used by other MIB
+   modules to define management objects.
+
+   Meaningful security considerations can only be written in the modules
+   that define management objects.
+
+8.  Authors' Addresses
+
+   Andy Bierman
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134 USA
+
+   Phone: +1 408-527-3711
+   EMail: abierman@cisco.com
+
+
+   Keith McCloghrie
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134 USA
+
+   Phone: +1 408-526-5260
+   EMail: kzm@cisco.com
+
+
+   Randy Presuhn
+   BMC Software, Inc.
+   Office 1-3141
+   2141 North First Street
+   San Jose,  California 95131 USA
+
+   Phone: +1 408 546-1006
+   EMail: rpresuhn@bmc.com
+
+
+
+
+
+
+Bierman, et al.             Standards Track                     [Page 9]
+
+RFC 2856                High Capacity Data Types               June 2000
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bierman, et al.             Standards Track                    [Page 10]
+