summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1442.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc1442.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc1442.txt')
-rw-r--r--doc/rfc/rfc1442.txt3299
1 files changed, 3299 insertions, 0 deletions
diff --git a/doc/rfc/rfc1442.txt b/doc/rfc/rfc1442.txt
new file mode 100644
index 0000000..33bec18
--- /dev/null
+++ b/doc/rfc/rfc1442.txt
@@ -0,0 +1,3299 @@
+
+
+
+ Network Working Group J. Case
+ Request for Comments: 1442 SNMP Research, Inc.
+ K. McCloghrie
+ Hughes LAN Systems
+ M. Rose
+ Dover Beach Consulting, Inc.
+ S. Waldbusser
+ Carnegie Mellon University
+ April 1993
+
+
+ Structure of Management Information
+ for version 2 of the
+ Simple Network Management Protocol (SNMPv2)
+
+
+ Status of this Memo
+
+ This RFC specifes an IAB standards track protocol for the
+ Internet community, and requests discussion and suggestions
+ for improvements. Please refer to the current edition of the
+ "IAB Official Protocol Standards" for the standardization
+ state and status of this protocol. Distribution of this memo
+ is unlimited.
+
+
+ Table of Contents
+
+
+ 1 Introduction .......................................... 2
+ 1.1 A Note on Terminology ............................... 3
+ 2 Definitions ........................................... 4
+ 3.1 The MODULE-IDENTITY macro ........................... 5
+ 3.2 Object Names and Syntaxes ........................... 7
+ 3.3 The OBJECT-TYPE macro ............................... 10
+ 3.5 The NOTIFICATION-TYPE macro ......................... 12
+ 3 Information Modules ................................... 13
+ 3.1 Macro Invocation .................................... 13
+ 3.1.1 Textual Clauses ................................... 14
+ 3.2 IMPORTing Symbols ................................... 14
+ 4 Naming Hierarchy ...................................... 16
+ 5 Mapping of the MODULE-IDENTITY macro .................. 17
+ 5.1 Mapping of the LAST-UPDATED clause .................. 17
+ 5.2 Mapping of the ORGANIZATION clause .................. 17
+ 5.3 Mapping of the CONTACT-INFO clause .................. 17
+ 5.4 Mapping of the DESCRIPTION clause ................... 17
+ 5.5 Mapping of the REVISION clause ...................... 17
+ 5.6 Mapping of the DESCRIPTION clause ................... 18
+ 5.7 Mapping of the MODULE-IDENTITY value ................ 18
+ 5.8 Usage Example ....................................... 19
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page i]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 6 Mapping of the OBJECT-IDENTITY macro .................. 20
+ 6.1 Mapping of the STATUS clause ........................ 20
+ 6.2 Mapping of the DESCRIPTION clause ................... 20
+ 6.3 Mapping of the REFERENCE clause ..................... 20
+ 6.4 Mapping of the OBJECT-IDENTITY value ................ 20
+ 6.5 Usage Example ....................................... 21
+ 7 Mapping of the OBJECT-TYPE macro ...................... 22
+ 7.1 Mapping of the SYNTAX clause ........................ 22
+ 7.1.1 Integer32 and INTEGER ............................. 22
+ 7.1.2 OCTET STRING ...................................... 23
+ 7.1.3 OBJECT IDENTIFIER ................................. 23
+ 7.1.4 BIT STRING ........................................ 23
+ 7.1.5 IpAddress ......................................... 23
+ 7.1.6 Counter32 ......................................... 24
+ 7.1.7 Gauge32 ........................................... 24
+ 7.1.8 TimeTicks ......................................... 24
+ 7.1.9 Opaque ............................................ 25
+ 7.1.10 NsapAddress ...................................... 25
+ 7.1.11 Counter64 ........................................ 26
+ 7.1.12 UInteger32 ....................................... 26
+ 7.2 Mapping of the UNITS clause ......................... 26
+ 7.3 Mapping of the MAX-ACCESS clause .................... 27
+ 7.4 Mapping of the STATUS clause ........................ 27
+ 7.5 Mapping of the DESCRIPTION clause ................... 27
+ 7.6 Mapping of the REFERENCE clause ..................... 28
+ 7.7 Mapping of the INDEX clause ......................... 28
+ 7.7.1 Creation and Deletion of Conceptual Rows .......... 30
+ 7.8 Mapping of the AUGMENTS clause ...................... 31
+ 7.8.1 Relation between INDEX and AUGMENTS clauses ....... 31
+ 7.9 Mapping of the DEFVAL clause ........................ 32
+ 7.10 Mapping of the OBJECT-TYPE value ................... 33
+ 7.11 Usage Example ...................................... 35
+ 8 Mapping of the NOTIFICATION-TYPE macro ................ 37
+ 8.1 Mapping of the OBJECTS clause ....................... 37
+ 8.2 Mapping of the STATUS clause ........................ 37
+ 8.3 Mapping of the DESCRIPTION clause ................... 37
+ 8.4 Mapping of the REFERENCE clause ..................... 37
+ 8.5 Mapping of the NOTIFICATION-TYPE value .............. 38
+ 8.6 Usage Example ....................................... 39
+ 9 Refined Syntax ........................................ 40
+ 10 Extending an Information Module ...................... 41
+ 10.1 Object Assignments ................................. 41
+ 10.2 Object Definitions ................................. 41
+ 10.3 Notification Definitions ........................... 42
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page ii]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 11 Appendix: de-OSIfying a MIB module ................... 43
+ 11.1 Managed Object Mapping ............................. 43
+ 11.1.1 Mapping to the SYNTAX clause ..................... 44
+ 11.1.2 Mapping to the UNITS clause ...................... 45
+ 11.1.3 Mapping to the MAX-ACCESS clause ................. 45
+ 11.1.4 Mapping to the STATUS clause ..................... 45
+ 11.1.5 Mapping to the DESCRIPTION clause ................ 45
+ 11.1.6 Mapping to the REFERENCE clause .................. 45
+ 11.1.7 Mapping to the INDEX clause ...................... 45
+ 11.1.8 Mapping to the DEFVAL clause ..................... 45
+ 11.2 Action Mapping ..................................... 46
+ 11.2.1 Mapping to the SYNTAX clause ..................... 46
+ 11.2.2 Mapping to the MAX-ACCESS clause ................. 46
+ 11.2.3 Mapping to the STATUS clause ..................... 46
+ 11.2.4 Mapping to the DESCRIPTION clause ................ 46
+ 11.2.5 Mapping to the REFERENCE clause .................. 46
+ 11.3 Event Mapping ...................................... 46
+ 11.3.1 Mapping to the STATUS clause ..................... 47
+ 11.3.2 Mapping to the DESCRIPTION clause ................ 47
+ 11.3.3 Mapping to the REFERENCE clause .................. 47
+ 12 Acknowledgements ..................................... 48
+ 13 References ........................................... 52
+ 14 Security Considerations .............................. 54
+ 15 Authors' Addresses ................................... 54
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 1]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 1. Introduction
+
+ A network management system contains: several (potentially
+ many) nodes, each with a processing entity, termed an agent,
+ which has access to management instrumentation; at least one
+ management station; and, a management protocol, used to convey
+ management information between the agents and management
+ stations. Operations of the protocol are carried out under an
+ administrative framework which defines both authentication and
+ authorization policies.
+
+ Network management stations execute management applications
+ which monitor and control network elements. Network elements
+ are devices such as hosts, routers, terminal servers, etc.,
+ which are monitored and controlled through access to their
+ management information.
+
+ Management information is viewed as a collection of managed
+ objects, residing in a virtual information store, termed the
+ Management Information Base (MIB). Collections of related
+ objects are defined in MIB modules. These modules are written
+ using a subset of OSI's Abstract Syntax Notation One (ASN.1)
+ [1]. It is the purpose of this document, the Structure of
+ Management Information (SMI), to define that subset.
+
+ The SMI is divided into three parts: module definitions,
+ object definitions, and, trap definitions.
+
+ (1) Module definitions are used when describing information
+ modules. An ASN.1 macro, MODULE-IDENTITY, is used to
+ concisely convey the semantics of an information module.
+
+ (2) Object definitions are used when describing managed
+ objects. An ASN.1 macro, OBJECT-TYPE, is used to
+ concisely convey the syntax and semantics of a managed
+ object.
+
+ (3) Notification definitions are used when describing
+ unsolicited transmissions of management information. An
+ ASN.1 macro, NOTIFICATION-TYPE, is used to concisely
+ convey the syntax and semantics of a notification.
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 2]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 1.1. A Note on Terminology
+
+ For the purpose of exposition, the original Internet-standard
+ Network Management Framework, as described in RFCs 1155, 1157,
+ and 1212, is termed the SNMP version 1 framework (SNMPv1).
+ The current framework is termed the SNMP version 2 framework
+ (SNMPv2).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 3]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 2. Definitions
+
+ SNMPv2-SMI DEFINITIONS ::= BEGIN
+
+
+ -- the path to the root
+
+ internet OBJECT IDENTIFIER ::= { iso 3 6 1 }
+
+ directory OBJECT IDENTIFIER ::= { internet 1 }
+
+ mgmt OBJECT IDENTIFIER ::= { internet 2 }
+
+ experimental OBJECT IDENTIFIER ::= { internet 3 }
+
+ private OBJECT IDENTIFIER ::= { internet 4 }
+ enterprises OBJECT IDENTIFIER ::= { private 1 }
+
+ security OBJECT IDENTIFIER ::= { internet 5 }
+
+ snmpV2 OBJECT IDENTIFIER ::= { internet 6 }
+
+ -- transport domains
+ snmpDomains OBJECT IDENTIFIER ::= { snmpV2 1 }
+
+ -- transport proxies
+ snmpProxys OBJECT IDENTIFIER ::= { snmpV2 2 }
+
+ -- module identities
+ snmpModules OBJECT IDENTIFIER ::= { snmpV2 3 }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 4]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ -- definitions for information modules
+
+ MODULE-IDENTITY MACRO ::=
+ BEGIN
+ TYPE NOTATION ::=
+ "LAST-UPDATED" value(Update UTCTime)
+ "ORGANIZATION" Text
+ "CONTACT-INFO" Text
+ "DESCRIPTION" Text
+ RevisionPart
+
+ VALUE NOTATION ::=
+ value(VALUE OBJECT IDENTIFIER)
+
+ RevisionPart ::=
+ Revisions
+ | empty
+ Revisions ::=
+ Revision
+ | Revisions Revision
+ Revision ::=
+ "REVISION" value(Update UTCTime)
+ "DESCRIPTION" Text
+
+ -- uses the NVT ASCII character set
+ Text ::= """" string """"
+ END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 5]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ OBJECT-IDENTITY MACRO ::=
+ BEGIN
+ TYPE NOTATION ::=
+ "STATUS" Status
+ "DESCRIPTION" Text
+ ReferPart
+
+ VALUE NOTATION ::=
+ value(VALUE OBJECT IDENTIFIER)
+
+ Status ::=
+ "current"
+ | "obsolete"
+
+ ReferPart ::=
+ "REFERENCE" Text
+ | empty
+
+ Text ::= """" string """"
+ END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 6]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ -- names of objects
+
+ ObjectName ::=
+ OBJECT IDENTIFIER
+
+
+ -- syntax of objects
+
+ ObjectSyntax ::=
+ CHOICE {
+ simple
+ SimpleSyntax,
+
+ -- note that SEQUENCEs for conceptual tables and
+ -- rows are not mentioned here...
+
+ application-wide
+ ApplicationSyntax
+ }
+
+
+ -- built-in ASN.1 types
+
+ SimpleSyntax ::=
+ CHOICE {
+ -- INTEGERs with a more restrictive range
+ -- may also be used
+ integer-value
+ INTEGER (-2147483648..2147483647),
+
+ string-value
+ OCTET STRING,
+
+ objectID-value
+ OBJECT IDENTIFIER,
+
+ -- only the enumerated form is allowed
+ bit-value
+ BIT STRING
+ }
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 7]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ -- indistinguishable from INTEGER, but never needs more than
+ -- 32-bits for a two's complement representation
+ Integer32 ::=
+ [UNIVERSAL 2]
+ IMPLICIT INTEGER (-2147483648..2147483647)
+
+
+ -- application-wide types
+
+ ApplicationSyntax ::=
+ CHOICE {
+ ipAddress-value
+ IpAddress,
+
+ counter-value
+ Counter32,
+
+ gauge-value
+ Gauge32,
+
+ timeticks-value
+ TimeTicks,
+
+ arbitrary-value
+ Opaque,
+
+ nsapAddress-value
+ NsapAddress,
+
+ big-counter-value
+ Counter64,
+
+ unsigned-integer-value
+ UInteger32
+ }
+
+ -- in network-byte order
+ -- (this is a tagged type for historical reasons)
+ IpAddress ::=
+ [APPLICATION 0]
+ IMPLICIT OCTET STRING (SIZE (4))
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 8]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ -- this wraps
+ Counter32 ::=
+ [APPLICATION 1]
+ IMPLICIT INTEGER (0..4294967295)
+
+ -- this doesn't wrap
+ Gauge32 ::=
+ [APPLICATION 2]
+ IMPLICIT INTEGER (0..4294967295)
+
+ -- hundredths of seconds since an epoch
+ TimeTicks ::=
+ [APPLICATION 3]
+ IMPLICIT INTEGER (0..4294967295)
+
+ -- for backward-compatibility only
+ Opaque ::=
+ [APPLICATION 4]
+ IMPLICIT OCTET STRING
+
+ -- for OSI NSAP addresses
+ -- (this is a tagged type for historical reasons)
+ NsapAddress ::=
+ [APPLICATION 5]
+ IMPLICIT OCTET STRING (SIZE (1 | 4..21))
+
+ -- for counters that wrap in less than one hour with only 32 bits
+ Counter64 ::=
+ [APPLICATION 6]
+ IMPLICIT INTEGER (0..18446744073709551615)
+
+ -- an unsigned 32-bit quantity
+ UInteger32 ::=
+ [APPLICATION 7]
+ IMPLICIT INTEGER (0..4294967295)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 9]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ -- definition for objects
+
+ OBJECT-TYPE MACRO ::=
+ BEGIN
+ TYPE NOTATION ::=
+ "SYNTAX" type(Syntax)
+ UnitsPart
+ "MAX-ACCESS" Access
+ "STATUS" Status
+ "DESCRIPTION" Text
+ ReferPart
+ IndexPart
+ DefValPart
+
+ VALUE NOTATION ::=
+ value(VALUE ObjectName)
+
+ UnitsPart ::=
+ "UNITS" Text
+ | empty
+
+ Access ::=
+ "not-accessible"
+ | "read-only"
+ | "read-write"
+ | "read-create"
+
+ Status ::=
+ "current"
+ | "deprecated"
+ | "obsolete"
+
+ ReferPart ::=
+ "REFERENCE" Text
+ | empty
+
+ IndexPart ::=
+ "INDEX" "{" IndexTypes "}"
+ | "AUGMENTS" "{" Entry "}"
+ | empty
+ IndexTypes ::=
+ IndexType
+ | IndexTypes "," IndexType
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 10]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ IndexType ::=
+ "IMPLIED" Index
+ | Index
+ Index ::=
+ -- use the SYNTAX value of the
+ -- correspondent OBJECT-TYPE invocation
+ value(Indexobject ObjectName)
+ Entry ::=
+ -- use the INDEX value of the
+ -- correspondent OBJECT-TYPE invocation
+ value(Entryobject ObjectName)
+
+ DefValPart ::=
+ "DEFVAL" "{" value(Defval Syntax) "}"
+ | empty
+
+ -- uses the NVT ASCII character set
+ Text ::= """" string """"
+ END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 11]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ -- definitions for notifications
+
+ NOTIFICATION-TYPE MACRO ::=
+ BEGIN
+ TYPE NOTATION ::=
+ ObjectsPart
+ "STATUS" Status
+ "DESCRIPTION" Text
+ ReferPart
+
+ VALUE NOTATION ::=
+ value(VALUE OBJECT IDENTIFIER)
+
+ ObjectsPart ::=
+ "OBJECTS" "{" Objects "}"
+ | empty
+ Objects ::=
+ Object
+ | Objects "," Object
+ Object ::=
+ value(Name ObjectName)
+
+ Status ::=
+ "current"
+ | "deprecated"
+ | "obsolete"
+
+ ReferPart ::=
+ "REFERENCE" Text
+ | empty
+
+ -- uses the NVT ASCII character set
+ Text ::= """" string """"
+ END
+
+
+ END
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 12]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 3. Information Modules
+
+ An "information module" is an ASN.1 module defining
+ information relating to network management.
+
+ The SMI describes how to use a subset of ASN.1 to define an
+ information module. Further, additional restrictions are
+ placed on "standard" information modules. It is strongly
+ recommended that "enterprise-specific" information modules
+ also adhere to these restrictions.
+
+ Typically, there are three kinds of information modules:
+
+ (1) MIB modules, which contain definitions of inter-related
+ managed objects, make use of the OBJECT-TYPE and
+ NOTIFICATION-TYPE macros;
+
+ (2) compliance statements for MIB modules, which make use of
+ the MODULE-COMPLIANCE and OBJECT-GROUP macros [2]; and,
+
+ (3) capability statements for agent implementations which
+ make use of the AGENT-CAPABILITIES macros [2].
+
+ This classification scheme does not imply a rigid taxonomy.
+ For example, a "standard" information module might include
+ definitions of managed objects and a compliance statement.
+ Similarly, an "enterprise-specific" information module might
+ include definitions of managed objects and a capability
+ statement. Of course, a "standard" information module may not
+ contain capability statements.
+
+ All information modules start with exactly one invocation of
+ the MODULE-IDENTITY macro, which provides contact and revision
+ history. This invocation must appear immediately after any
+ IMPORTs or EXPORTs statements.
+
+
+ 3.1. Macro Invocation
+
+ Within an information module, each macro invocation appears
+ as:
+
+ <descriptor> <macro> <clauses> ::= <value>
+
+ where <descriptor> corresponds to an ASN.1 identifier, <macro>
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 13]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ names the macro being invoked, and <clauses> and <value>
+ depend on the definition of the macro.
+
+ An ASN.1 identifier consists of one or more letters, digits,
+ or hyphens. The initial character must be a lower-case
+ letter, and the final character may not be a hyphen. Further,
+ a hyphen may not be immediatedly followed by another hyphen.
+
+ For all descriptors appearing in an information module, the
+ descriptor shall be unique and mnemonic, and shall not exceed
+ 64 characters in length. This promotes a common language for
+ humans to use when discussing the information module and also
+ facilitates simple table mappings for user-interfaces.
+
+ The set of descriptors defined in all "standard" information
+ modules shall be unique. Further, within any information
+ module, the hyphen is not allowed as a character in any
+ descriptor.
+
+ Finally, by convention, if the descriptor refers to an object
+ with a SYNTAX clause value of either Counter32 or Counter64,
+ then the descriptor used for the object should denote
+ plurality.
+
+
+ 3.1.1. Textual Clauses
+
+ Some clauses in a macro invocation may take a textual value
+ (e.g., the DESCRIPTION clause). Note that, in order to
+ conform to the ASN.1 syntax, the entire value of these clauses
+ must be enclosed in double quotation marks, and therefore
+ cannot itself contain double quotation marks, although the
+ value may be multi-line.
+
+
+ 3.2. IMPORTing Symbols
+
+ To reference an external object, the IMPORTS statement must be
+ used to identify both the descriptor and the module defining
+ the descriptor.
+
+ Note that when symbols from "enterprise-specific" information
+ modules are referenced (e.g., a descriptor), there is the
+ possibility of collision. As such, if different objects with
+ the same descriptor are IMPORTed, then this ambiguity is
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 14]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ resolved by prefixing the descriptor with the name of the
+ information module and a dot ("."), i.e.,
+
+ "module.descriptor"
+
+ (All descriptors must be unique within any information
+ module.)
+
+ Of course, this notation can be used even when there is no
+ collision when IMPORTing symbols.
+
+ Finally, the IMPORTS statement may not be used to import an
+ ASN.1 named type which corresponds to either the SEQUENCE or
+ SEQUENCE OF type.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 15]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 4. Naming Hierarchy
+
+ The root of the subtree administered by the Internet Assigned
+ Numbers Authority (IANA) for the Internet is:
+
+ internet OBJECT IDENTIFIER ::= { iso 3 6 1 }
+
+ That is, the Internet subtree of OBJECT IDENTIFIERs starts
+ with the prefix:
+
+ 1.3.6.1.
+
+ Several branches underneath this subtree are used for network
+ management:
+
+ mgmt OBJECT IDENTIFIER ::= { internet 2 }
+ experimental OBJECT IDENTIFIER ::= { internet 3 }
+ private OBJECT IDENTIFIER ::= { internet 4 }
+ enterprises OBJECT IDENTIFIER ::= { private 1 }
+
+ However, the SMI does not prohibit the definition of objects
+ in other portions of the object tree.
+
+ The mgmt(2) subtree is used to identify "standard" objects.
+
+ The experimental(3) subtree is used to identify objects being
+ designed by working groups of the IETF. If an information
+ module produced by a working group becomes a "standard"
+ information module, then at the very beginning of its entry
+ onto the Internet standards track, the objects are moved under
+ the mgmt(2) subtree.
+
+ The private(4) subtree is used to identify objects defined
+ unilaterally. The enterprises(1) subtree beneath private is
+ used, among other things, to permit providers of networking
+ subsystems to register models of their products.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 16]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 5. Mapping of the MODULE-IDENTITY macro
+
+ The MODULE-IDENTITY macro is used to provide contact and
+ revision history for each information module. It must appear
+ exactly once in every information module. It should be noted
+ that the expansion of the MODULE-IDENTITY macro is something
+ which conceptually happens during implementation and not
+ during run-time.
+
+
+ 5.1. Mapping of the LAST-UPDATED clause
+
+ The LAST-UPDATED clause, which must be present, contains the
+ date and time that this information module was last edited.
+
+
+ 5.2. Mapping of the ORGANIZATION clause
+
+ The ORGANIZATION clause, which must be present, contains a
+ textual description of the organization under whose auspices
+ this information module was developed.
+
+
+ 5.3. Mapping of the CONTACT-INFO clause
+
+ The CONTACT-INFO clause, which must be present, contains the
+ name, postal address, telephone number, and electronic mail
+ address of the person to whom technical queries concerning
+ this information module should be sent.
+
+
+ 5.4. Mapping of the DESCRIPTION clause
+
+ The DESCRIPTION clause, which must be present, contains a
+ high-level textual description of the contents of this
+ information module.
+
+
+ 5.5. Mapping of the REVISION clause
+
+ The REVISION clause, which need not be present, is repeatedly
+ used to describe the revisions made to this information
+ module, in reverse chronological order. Each instance of this
+ clause contains the date and time of the revision.
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 17]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 5.6. Mapping of the DESCRIPTION clause
+
+ The DESCRIPTION clause, which must be present for each
+ REVISION clause, contains a high-level textual description of
+ the revision identified in that REVISION clause.
+
+
+ 5.7. Mapping of the MODULE-IDENTITY value
+
+ The value of an invocation of the MODULE-IDENTITY macro is an
+ OBJECT IDENTIFIER. As such, this value may be authoritatively
+ used when referring to the information module containing the
+ invocation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 18]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 5.8. Usage Example
+
+ Consider how a skeletal MIB module might be constructed: e.g.,
+
+ FIZBIN-MIB DEFINITIONS ::= BEGIN
+
+ IMPORTS
+ MODULE-IDENTITY, OBJECT-TYPE, experimental
+ FROM SNMPv2-SMI;
+
+
+ fizbin MODULE-IDENTITY
+ LAST-UPDATED "9210070433Z"
+ ORGANIZATION "IETF SNMPv2 Working Group"
+ CONTACT-INFO
+ " Marshall T. Rose
+
+ Postal: Dover Beach Consulting, Inc.
+ 420 Whisman Court
+ Mountain View, CA 94043-2186
+ US
+
+ Tel: +1 415 968 1052
+ Fax: +1 415 968 2510
+
+ E-mail: mrose@dbc.mtview.ca.us"
+ DESCRIPTION
+ "The MIB module for entities implementing the xxxx
+ protocol."
+ REVISION "9210070433Z"
+ DESCRIPTION
+ "Initial version of this MIB module."
+ -- contact IANA for actual number
+ ::= { experimental xx }
+
+
+ END
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 19]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 6. Mapping of the OBJECT-IDENTITY macro
+
+ The OBJECT-IDENTITY macro is used to define information about
+ an OBJECT IDENTIFIER assignment. It should be noted that the
+ expansion of the OBJECT-IDENTITY macro is something which
+ conceptually happens during implementation and not during
+ run-time.
+
+
+ 6.1. Mapping of the STATUS clause
+
+ The STATUS clause, which must be present, indicates whether
+ this definition is current or historic.
+
+ The values "current", and "obsolete" are self-explanatory.
+
+
+ 6.2. Mapping of the DESCRIPTION clause
+
+ The DESCRIPTION clause, which must be present, contains a
+ textual description of the object assignment.
+
+
+ 6.3. Mapping of the REFERENCE clause
+
+ The REFERENCE clause, which need not be present, contains a
+ textual cross-reference to an object assignment defined in
+ some other information module.
+
+
+ 6.4. Mapping of the OBJECT-IDENTITY value
+
+ The value of an invocation of the OBJECT-IDENTITY macro is an
+ OBJECT IDENTIFIER.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 20]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 6.5. Usage Example
+
+ Consider how an OBJECT IDENTIFIER assignment might be made:
+ e.g.,
+
+ fizbin69 OBJECT-IDENTITY
+ STATUS current
+ DESCRIPTION
+ "The authoritative identity of the Fizbin 69
+ chipset."
+ ::= { fizbinChipSets 1 }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 21]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 7. Mapping of the OBJECT-TYPE macro
+
+ The OBJECT-TYPE macro is used to define a managed object. It
+ should be noted that the expansion of the OBJECT-TYPE macro is
+ something which conceptually happens during implementation and
+ not during run-time.
+
+
+ 7.1. Mapping of the SYNTAX clause
+
+ The SYNTAX clause, which must be present, defines the abstract
+ data structure corresponding to that object. The data
+ structure must be one of the alternatives defined in the
+ ObjectSyntax CHOICE.
+
+ Full ASN.1 sub-typing is allowed, as appropriate to the
+ underingly ASN.1 type, primarily as an aid to implementors in
+ understanding the meaning of the object. Any such restriction
+ on size, range, enumerations or repertoire specified in this
+ clause represents the maximal level of support which makes
+ "protocol sense". Of course, sub-typing is not allowed for
+ the Counter32 or Counter64 types, but is allowed for the
+ Gauge32 type.
+
+ The semantics of ObjectSyntax are now described.
+
+
+ 7.1.1. Integer32 and INTEGER
+
+ The Integer32 type represents integer-valued information
+ between -2^31 and 2^31-1 inclusive (-2147483648 to 2147483647
+ decimal). This type is indistinguishable from the INTEGER
+ type.
+
+ The INTEGER type may also be used to represent integer-valued
+ information, if it contains named-number enumerations, or if
+ it is sub-typed to be more constrained than the Integer32
+ type. In the former case, only those named-numbers so
+ enumerated may be present as a value. Note that although it
+ is recommended that enumerated values start at 1 and be
+ numbered contiguously, any valid value for Integer32 is
+ allowed for an enumerated value and, further, enumerated
+ values needn't be contiguously assigned.
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 22]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ Finally, the hyphen character is not allowed as a part of the
+ label name for any named-number enumeration.
+
+
+ 7.1.2. OCTET STRING
+
+ The OCTET STRING type represents arbitrary binary or textual
+ data. Although there is no SMI-specified size limitation for
+ this type, MIB designers should realize that there may be
+ implementation and interoperability limitations for sizes in
+ excess of 255 octets.
+
+
+ 7.1.3. OBJECT IDENTIFIER
+
+ The OBJECT IDENTIFIER type represents administratively
+ assigned names. Any instance of this type may have at most
+ 128 sub-identifiers. Further, each sub-identifier must not
+ exceed the value 2^32-1 (4294967295 decimal).
+
+
+ 7.1.4. BIT STRING
+
+ The BIT STRING type represents an enumeration of named bits.
+ This collection is assigned non-negative, contiguous values,
+ starting at zero. Only those named-bits so enumerated may be
+ present in a value.
+
+ A requirement on "standard" MIB modules is that the hyphen
+ character is not allowed as a part of the label name for any
+ named-bit enumeration.
+
+
+ 7.1.5. IpAddress
+
+ The IpAddress type represents a 32-bit internet address. It
+ is represented as an OCTET STRING of length 4, in network
+ byte-order.
+
+ Note that the IpAddress type is a tagged type for historical
+ reasons. Network addresses should be represented using an
+ invocation of the TEXTUAL-CONVENTION macro [3].
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 23]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 7.1.6. Counter32
+
+ The Counter32 type represents a non-negative integer which
+ monotonically increases until it reaches a maximum value of
+ 2^32-1 (4294967295 decimal), when it wraps around and starts
+ increasing again from zero.
+
+ Counters have no defined "initial" value, and thus, a single
+ value of a Counter has (in general) no information content.
+ Discontinuities in the monotonically increasing value normally
+ occur at re-initialization of the management system, and at
+ other times as specified in the description of an object-type
+ using this ASN.1 type. If such other times can occur, for
+ example, the creation of an object instance at times other
+ than re-initialization, then a corresponding object should be
+ defined with a SYNTAX clause value of TimeStamp (a textual
+ convention defined in [3]) indicating the time of the last
+ discontinuity.
+
+ The value of the MAX-ACCESS clause for objects with a SYNTAX
+ clause value of Counter32 is always "read-only".
+
+ A DEFVAL clause is not allowed for objects with a SYNTAX
+ clause value of Counter32.
+
+
+ 7.1.7. Gauge32
+
+ The Gauge32 type represents a non-negative integer, which may
+ increase or decrease, but shall never exceed a maximum value.
+ The maximum value can not be greater than 2^32-1 (4294967295
+ decimal). The value of a Gauge has its maximum value whenever
+ the information being modeled is greater or equal to that
+ maximum value; if the information being modeled subsequently
+ decreases below the maximum value, the Gauge also decreases.
+
+
+ 7.1.8. TimeTicks
+
+ The TimeTicks type represents a non-negative integer which
+ represents the time, modulo 2^32 (4294967296 decimal), in
+ hundredths of a second between two epochs. When objects are
+ defined which use this ASN.1 type, the description of the
+ object identifies both of the reference epochs.
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 24]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ For example, [3] defines the TimeStamp textual convention
+ which is based on the TimeTicks type. With a TimeStamp, the
+ first reference epoch is defined as when MIB-II's sysUpTime
+ [7] was zero, and the second reference epoch is defined as the
+ current value of sysUpTime.
+
+
+ 7.1.9. Opaque
+
+ The Opaque type is provided solely for backward-compatibility,
+ and shall not be used for newly-defined object types.
+
+ The Opaque type supports the capability to pass arbitrary
+ ASN.1 syntax. A value is encoded using the ASN.1 Basic
+ Encoding Rules [4] into a string of octets. This, in turn, is
+ encoded as an OCTET STRING, in effect "double-wrapping" the
+ original ASN.1 value.
+
+ Note that a conforming implementation need only be able to
+ accept and recognize opaquely-encoded data. It need not be
+ able to unwrap the data and then interpret its contents.
+
+ A requirement on "standard" MIB modules is that no object may
+ have a SYNTAX clause value of Opaque.
+
+
+ 7.1.10. NsapAddress
+
+ The NsapAddress type represents an OSI address as a variable-
+ length OCTET STRING. The first octet of the string contains a
+ binary value in the range of 0..20, and indicates the length
+ in octets of the NSAP. Following the first octet, is the
+ NSAP, expressed in concrete binary notation, starting with the
+ most significant octet. A zero-length NSAP is used as a
+ "special" address meaning "the default NSAP" (analogous to the
+ IP address of 0.0.0.0). Such an NSAP is encoded as a single
+ octet, containing the value 0. All other NSAPs are encoded in
+ at least 4 octets.
+
+ Note that the NsapAddress type is a tagged type for historical
+ reasons. Network addresses should be represented using an
+ invocation of the TEXTUAL-CONVENTION macro [3].
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 25]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 7.1.11. Counter64
+
+ The Counter64 type represents a non-negative integer which
+ monotonically increases until it reaches a maximum value of
+ 2^64-1 (18446744073709551615 decimal), when it wraps around
+ and starts increasing again from zero.
+
+ Counters have no defined "initial" value, and thus, a single
+ value of a Counter has (in general) no information content.
+ Discontinuities in the monotonically increasing value normally
+ occur at re-initialization of the management system, and at
+ other times as specified in the description of an object-type
+ using this ASN.1 type. If such other times can occur, for
+ example, the creation of an object instance at times other
+ than re-initialization, then a corresponding object should be
+ defined with a SYNTAX clause value of TimeStamp (a textual
+ convention defined in [3]) indicating the time of the last
+ discontinuity.
+
+ The value of the MAX-ACCESS clause for objects with a SYNTAX
+ clause value of Counter64 is always "read-only".
+
+ A requirement on "standard" MIB modules is that the Counter64
+ type may be used only if the information being modeled would
+ wrap in less than one hour if the Counter32 type was used
+ instead.
+
+ A DEFVAL clause is not allowed for objects with a SYNTAX
+ clause value of Counter64.
+
+
+ 7.1.12. UInteger32
+
+ The UInteger32 type represents integer-valued information
+ between 0 and 2^32-1 inclusive (0 to 4294967295 decimal).
+
+
+ 7.2. Mapping of the UNITS clause
+
+ This UNITS clause, which need not be present, contains a
+ textual definition of the units associated with that object.
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 26]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 7.3. Mapping of the MAX-ACCESS clause
+
+ The MAX-ACCESS clause, which must be present, defines whether
+ it makes "protocol sense" to read, write and/or create an
+ instance of the object. This is the maximal level of access
+ for the object. (This maximal level of access is independent
+ of any administrative authorization policy.)
+
+ The value "read-write" indicates that read and write access
+ make "protocol sense", but create does not. The value "read-
+ create" indicates that read, write and create access make
+ "protocol sense". The value "not-accessible" indicates either
+ an auxiliary object (see Section 7.7) or an object which is
+ accessible only via a notificationn (e.g., snmpTrapOID [5]).
+
+ These values are ordered, from least to greatest: "not-
+ accessible", "read-only", "read-write", "read-create".
+
+ If any columnar object in a conceptual row has "read-create"
+ as its maximal level of access, then no other columnar object
+ of the same conceptual row may have a maximal access of
+ "read-write". (Note that "read-create" is a superset of
+ "read-write".)
+
+
+ 7.4. Mapping of the STATUS clause
+
+ The STATUS clause, which must be present, indicates whether
+ this definition is current or historic.
+
+ The values "current", and "obsolete" are self-explanatory.
+ The "deprecated" value indicates that the object is obsolete,
+ but that an implementor may wish to support that object to
+ foster interoperability with older implementations.
+
+
+ 7.5. Mapping of the DESCRIPTION clause
+
+ The DESCRIPTION clause, which must be present, contains a
+ textual definition of that object which provides all semantic
+ definitions necessary for implementation, and should embody
+ any information which would otherwise be communicated in any
+ ASN.1 commentary annotations associated with the object.
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 27]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 7.6. Mapping of the REFERENCE clause
+
+ The REFERENCE clause, which need not be present, contains a
+ textual cross-reference to an object defined in some other
+ information module. This is useful when de-osifying a MIB
+ module produced by some other organization.
+
+
+ 7.7. Mapping of the INDEX clause
+
+ The INDEX clause, which must be present if that object
+ corresponds to a conceptual row (unless an AUGMENTS clause is
+ present instead), and must be absent otherwise, defines
+ instance identification information for the columnar objects
+ subordinate to that object.
+
+ Management operations apply exclusively to scalar objects.
+ However, it is convenient for developers of management
+ applications to impose imaginary, tabular structures on the
+ ordered collection of objects that constitute the MIB. Each
+ such conceptual table contains zero or more rows, and each row
+ may contain one or more scalar objects, termed columnar
+ objects. This conceptualization is formalized by using the
+ OBJECT-TYPE macro to define both an object which corresponds
+ to a table and an object which corresponds to a row in that
+ table. A conceptual table has SYNTAX of the form:
+
+ SEQUENCE OF <EntryType>
+
+ where <EntryType> refers to the SEQUENCE type of its
+ subordinate conceptual row. A conceptual row has SYNTAX of
+ the form:
+
+ <EntryType>
+
+ where <EntryType> is a SEQUENCE type defined as follows:
+
+ <EntryType> ::= SEQUENCE { <type1>, ... , <typeN> }
+
+ where there is one <type> for each subordinate object, and
+ each <type> is of the form:
+
+ <descriptor> <syntax>
+
+ where <descriptor> is the descriptor naming a subordinate
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 28]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ object, and <syntax> has the value of that subordinate
+ object's SYNTAX clause, optionally omitting the sub-typing
+ information. Further, these ASN.1 types are always present
+ (the DEFAULT and OPTIONAL clauses are disallowed in the
+ SEQUENCE definition). The MAX-ACCESS clause for conceptual
+ tables and rows is "not-accessible".
+
+ For leaf objects which are not columnar objects, instances of
+ the object are identified by appending a sub-identifier of
+ zero to the name of that object. Otherwise, the INDEX clause
+ of the conceptual row object superior to a columnar object
+ defines instance identification information.
+
+ The instance identification information in an INDEX clause
+ must specify object(s) such that value(s) of those object(s)
+ will unambiguously distinguish a conceptual row. The syntax
+ of those objects indicate how to form the instance-identifier:
+
+ (1) integer-valued: a single sub-identifier taking the
+ integer value (this works only for non-negative
+ integers);
+
+ (2) string-valued, fixed-length strings (or variable-length
+ preceded by the IMPLIED keyword): `n' sub-identifiers,
+ where `n' is the length of the string (each octet of the
+ string is encoded in a separate sub-identifier);
+
+ (3) string-valued, variable-length strings (not preceded by
+ the IMPLIED keyword): `n+1' sub-identifiers, where `n' is
+ the length of the string (the first sub-identifier is `n'
+ itself, following this, each octet of the string is
+ encoded in a separate sub-identifier);
+
+ (4) object identifier-valued: `n+1' sub-identifiers, where
+ `n' is the number of sub-identifiers in the value (the
+ first sub-identifier is `n' itself, following this, each
+ sub-identifier in the value is copied);
+
+ (5) IpAddress-valued: 4 sub-identifiers, in the familiar
+ a.b.c.d notation.
+
+ (6) NsapAddress-valued: `n' sub-identifiers, where `n' is the
+ length of the value (each octet of the value is encoded
+ in a separate sub-identifier);
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 29]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ Note that the IMPLIED keyword can only be present for objects
+ having a variable-length syntax (e.g., variable-length strings
+ or object identifier-valued objects). Further, the IMPLIED
+ keyword may appear at most once within the INDEX clause, and
+ if so, is associated with the right-most object having a
+ variable-length syntax. Finally, the IMPLIED keyword may not
+ be used on a variable-length string object if that string
+ might have a value of zero-length.
+
+ Instances identified by use of integer-valued objects should
+ be numbered starting from one (i.e., not from zero). The use
+ of zero as a value for an integer-valued index object should
+ be avoided, except in special cases.
+
+ Objects which are both specified in the INDEX clause of a
+ conceptual row and also columnar objects of the same
+ conceptual row are termed auxiliary objects. The MAX-ACCESS
+ clause for newly-defined auxiliary objects is "not-
+ accessible". However, a conceptual row must contain at least
+ one columnar object which is not an auxiliary object (i.e.,
+ the value of the MAX-ACCESS clause for such an object is
+ either "read-only" or "read-create").
+
+ Note that objects specified in a conceptual row's INDEX clause
+ need not be columnar objects of that conceptual row. In this
+ situation, the DESCRIPTION clause of the conceptual row must
+ include a textual explanation of how the objects which are
+ included in the INDEX clause but not columnar objects of that
+ conceptual row, are used in uniquely identifying instances of
+ the conceptual row's columnar objects.
+
+
+ 7.7.1. Creation and Deletion of Conceptual Rows
+
+ For newly-defined conceptual rows which allow the creation of
+ new object instances and the deletion of existing object
+ instances, there should be one columnar object with a SYNTAX
+ clause value of RowStatus (a textual convention defined in
+ [3]) and a MAX-ACCESS clause value of read-create. By
+ convention, this is termed the status column for the
+ conceptual row.
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 30]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 7.8. Mapping of the AUGMENTS clause
+
+ The AUGMENTS clause, which must not be present unless the
+ object corresponds to a conceptual row, is an alternative to
+ the INDEX clause. Every object corresponding to a conceptual
+ row has either an INDEX clause or an AUGMENTS clause.
+
+ If an object corresponding to a conceptual row has an INDEX
+ clause, that row is termed a base conceptual row;
+ alternatively, if the object has an AUGMENTS clause, the row
+ is said to be a conceptual row augmentation, where the
+ AUGMENTS clause names the object corresponding to the base
+ conceptual row which is augmented by this conceptual row
+ extension. Instances of subordinate columnar objects of a
+ conceptual row extension are identified according to the INDEX
+ clause of the base conceptual row corresponding to the object
+ named in the AUGMENTS clause. Further, instances of
+ subordinate columnar objects of a conceptual row extension
+ exist according to the same semantics as instances of
+ subordinate columnar objects of the base conceptual row being
+ augmented. As such, note that creation of a base conceptual
+ row implies the correspondent creation of any conceptual row
+ augmentations.
+
+ For example, a MIB designer might wish to define additional
+ columns in an "enterprise-specific" MIB which logically extend
+ a conceptual row in a "standard" MIB. The "standard" MIB
+ definition of the conceptual row would include the INDEX
+ clause and the "enterprise-specific" MIB would contain the
+ definition of a conceptual row using the AUGMENTS clause.
+
+ Note that a base conceptual row may be augmented by multiple
+ conceptual row extensions.
+
+
+ 7.8.1. Relation between INDEX and AUGMENTS clauses
+
+ When defining instance identification information for a
+ conceptual table:
+
+ (1) If there is a one-to-one correspondence between the
+ conceptual rows of this table and an existing table, then
+ the AUGMENTS clause should be used.
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 31]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ (2) Otherwise, if there is a sparse relationship between the
+ conceptuals rows of this table and an existing table,
+ then an INDEX clause should be used which is identical to
+ that in the existing table.
+
+ (3) Otherwise, auxiliary objects should be defined within the
+ conceptual row for the new table, and those objects
+ should be used within the INDEX clause for the conceptual
+ row.
+
+
+ 7.9. Mapping of the DEFVAL clause
+
+ The DEFVAL clause, which need not be present, defines an
+ acceptable default value which may be used at the discretion
+ of a SNMPv2 entity acting in an agent role when an object
+ instance is created.
+
+ During conceptual row creation, if an instance of a columnar
+ object is not present as one of the operands in the
+ correspondent management protocol set operation, then the
+ value of the DEFVAL clause, if present, indicates an
+ acceptable default value that a SNMPv2 entity acting in an
+ agent role might use.
+
+ The value of the DEFVAL clause must, of course, correspond to
+ the SYNTAX clause for the object. If the value is an OBJECT
+ IDENTIFIER, then it must be expressed as a single ASN.1
+ identifier, and not as a collection of sub-identifiers.
+
+ Note that if an operand to the management protocol set
+ operation is an instance of a read-only object, then the error
+ `notWritable' [6] will be returned. As such, the DEFVAL
+ clause can be used to provide an acceptable default value that
+ a SNMPv2 entity acting in an agent role might use.
+
+ By way of example, consider the following possible DEFVAL
+ clauses:
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 32]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ ObjectSyntax DEFVAL clause
+ ----------------- ------------
+ Integer32 1
+ -- same for Gauge32, TimeTicks, UInteger32
+ INTEGER valid -- enumerated value
+ OCTET STRING 'ffffffffffff'H
+ OBJECT IDENTIFIER sysDescr
+ BIT STRING { primary, secondary } -- enumerated values
+ IpAddress 'c0210415'H -- 192.33.4.21
+
+ Object types with SYNTAX of Counter32 and Counter64 may not
+ have DEFVAL clauses, since they do not have defined initial
+ values. However, it is recommended that they be initialized
+ to zero.
+
+
+ 7.10. Mapping of the OBJECT-TYPE value
+
+ The value of an invocation of the OBJECT-TYPE macro is the
+ name of the object, which is an OBJECT IDENTIFIER, an
+ administratively assigned name.
+
+ When an OBJECT IDENTIFIER is assigned to an object:
+
+ (1) If the object corresponds to a conceptual table, then
+ only a single assignment, that for a conceptual row, is
+ present immediately beneath that object. The
+ administratively assigned name for the conceptual row
+ object is derived by appending a sub-identifier of "1" to
+ the administratively assigned name for the conceptual
+ table.
+
+ (2) If the object corresponds to a conceptual row, then at
+ least one assignment, one for each column in the
+ conceptual row, is present beneath that object. The
+ administratively assigned name for each column is derived
+ by appending a unique, positive sub-identifier to the
+ administratively assigned name for the conceptual row.
+
+ (3) Otherwise, no other OBJECT IDENTIFIERs which are
+ subordinate to the object may be assigned.
+
+ Note that the final sub-identifier of any administratively
+ assigned name for an object shall be positive. A zero-valued
+ final sub-identifier is reserved for future use.
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 33]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ Further note that although conceptual tables and rows are
+ given administratively assigned names, these conceptual
+ objects may not be manipulated in aggregate form by the
+ management protocol.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 34]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 7.11. Usage Example
+
+ Consider how one might define a conceptual table and its
+ subordinates.
+
+ evalSlot OBJECT-TYPE
+ SYNTAX INTEGER
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The index number of the first unassigned entry in
+ the evaluation table.
+
+ A management station should create new entries in
+ the evaluation table using this algorithm: first,
+ issue a management protocol retrieval operation to
+ determine the value of evalSlot; and, second,
+ issue a management protocol set operation to
+ create an instance of the evalStatus object
+ setting its value to underCreation(1). If this
+ latter operation succeeds, then the management
+ station may continue modifying the instances
+ corresponding to the newly created conceptual row,
+ without fear of collision with other management
+ stations."
+ ::= { eval 1 }
+
+ evalTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF EvalEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The (conceptual) evaluation table."
+ ::= { eval 2 }
+
+ evalEntry OBJECT-TYPE
+ SYNTAX EvalEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "An entry (conceptual row) in the evaluation
+ table."
+ INDEX { evalIndex }
+ ::= { evalTable 1 }
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 35]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ EvalEntry ::=
+ SEQUENCE {
+ evalIndex Integer32,
+ evalString DisplayString,
+ evalValue Integer32,
+ evalStatus RowStatus
+ }
+
+ evalIndex OBJECT-TYPE
+ SYNTAX Integer32
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The auxiliary variable used for identifying
+ instances of the columnar objects in the
+ evaluation table."
+ ::= { evalEntry 1 }
+
+ evalString OBJECT-TYPE
+ SYNTAX DisplayString
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The string to evaluate."
+ ::= { evalEntry 2 }
+
+ evalValue OBJECT-TYPE
+ SYNTAX Integer32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The value when evalString was last executed."
+ DEFVAL { 0 }
+ ::= { evalEntry 3 }
+
+ evalStatus OBJECT-TYPE
+ SYNTAX RowStatus
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The status column used for creating, modifying,
+ and deleting instances of the columnar objects in
+ the evaluation table."
+ DEFVAL { active }
+ ::= { evalEntry 4 }
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 36]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 8. Mapping of the NOTIFICATION-TYPE macro
+
+ The NOTIFICATION-TYPE macro is used to define the information
+ contained within an unsolicited transmission of management
+ information (i.e., within either a SNMPv2-Trap-PDU or
+ InformRequest-PDU). It should be noted that the expansion of
+ the NOTIFICATION-TYPE macro is something which conceptually
+ happens during implementation and not during run-time.
+
+
+ 8.1. Mapping of the OBJECTS clause
+
+ The OBJECTS clause, which need not be present, defines the
+ ordered sequence of MIB objects which are contained within
+ every instance of the notification.
+
+
+ 8.2. Mapping of the STATUS clause
+
+ The STATUS clause, which must be present, indicates whether
+ this definition is current or historic.
+
+ The values "current", and "obsolete" are self-explanatory.
+ The "deprecated" value indicates that the notification is
+ obsolete, but that an implementor may wish to support that
+ object to foster interoperability with older implementations.
+
+
+ 8.3. Mapping of the DESCRIPTION clause
+
+ The DESCRIPTION clause, which must be present, contains a
+ textual definition of the notification which provides all
+ semantic definitions necessary for implementation, and should
+ embody any information which would otherwise be communicated
+ in any ASN.1 commentary annotations associated with the
+ object. In particular, the DESCRIPTION clause should document
+ which instances of the objects mentioned in the OBJECTS clause
+ should be contained within notifications of this type.
+
+
+ 8.4. Mapping of the REFERENCE clause
+
+ The REFERENCE clause, which need not be present, contains a
+ textual cross-reference to a notification defined in some
+ other information module. This is useful when de-osifying a
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 37]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ MIB module produced by some other organization.
+
+
+ 8.5. Mapping of the NOTIFICATION-TYPE value
+
+ The value of an invocation of the NOTIFICATION-TYPE macro is
+ the name of the notification, which is an OBJECT IDENTIFIER,
+ an administratively assigned name.
+
+ Sections 4.2.6 and 4.2.7 of [6] describe how the
+ NOTIFICATION-TYPE macro is used to generate a SNMPv2-Trap-PDU
+ or InformRequest-PDU, respectively.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 38]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 8.6. Usage Example
+
+ Consider how a linkUp trap might be described:
+
+ linkUp NOTIFICATION-TYPE
+ OBJECTS { ifIndex }
+ STATUS current
+ DESCRIPTION
+ "A linkUp trap signifies that the SNMPv2 entity,
+ acting in an agent role, recognizes that one of
+ the communication links represented in its
+ configuration has come up."
+ ::= { snmpTraps 4 }
+
+ According to this invocation, the trap authoritatively
+ identified as
+
+ { snmpTraps 4 }
+
+ is used to report a link coming up.
+
+ Note that a SNMPv2 entity acting in an agent role can be
+ configured to send this trap to zero or more SNMPv2 entities
+ acting in a manager role, depending on the contents of the
+ aclTable and viewTable [8] tables. For example, by judicious
+ use of the viewTable, a SNMPv2 entity acting in an agent role
+ might be configured to send all linkUp traps to one particular
+ SNMPv2 entity, and linkUp traps for only certain interfaces to
+ other SNMPv2 entities.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 39]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 9. Refined Syntax
+
+ Some macros allow an object's syntax to be refined (e.g., the
+ SYNTAX clause in the MODULE-COMPLIANCE macro [2]). However,
+ not all refinements of syntax are appropriate. In particular,
+ the object's primitive or application type must not be
+ changed.
+
+ Further, the following restrictions apply:
+
+ Restrictions to Refinement on
+ object syntax range enumeration size repertoire
+ ----------------- ----- ----------- ---- ----------
+ INTEGER (1) (2) - -
+ OCTET STRING - - (3) (4)
+ OBJECT IDENTIFIER - - - -
+ BIT STRING - (2) - -
+ IpAddress - - - -
+ Counter32 - - - -
+ Gauge32 (1) - - -
+ TimeTicks - - - -
+ NsapAddress - - - -
+ Counter64 - - - -
+
+ where:
+
+ (1) the range of permitted values may be refined by raising
+ the lower-bounds, by reducing the upper-bounds, and/or by
+ reducing the alternative value/range choices;
+
+ (2) the enumeration of named-values may be refined by
+ removing one or more named-values;
+
+ (3) the size in characters of the value may be refined by
+ raising the lower-bounds, by reducing the upper-bounds,
+ and/or by reducing the alternative size choices; or,
+
+ (4) the repertoire of characters in the value may be reduced
+ by further sub-typing.
+
+ Otherwise no refinements are possible.
+
+ Note that when refining an object with a SYNTAX clause value
+ of Integer32 or UInteger32, the refined SYNTAX is expressed as
+ an INTEGER and the restrictions of the table above are used.
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 40]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 10. Extending an Information Module
+
+ As experience is gained with a published information module,
+ it may be desirable to revise that information module.
+
+ To begin, the invocation of the MODULE-IDENTITY macro should
+ be updated to include information about the revision.
+ Usually, this consists of updating the LAST-UPDATED clause and
+ adding a pair of REVISION and DESCRIPTION clauses. However,
+ other existing clauses in the invocation may be updated.
+
+ Note that the module's label (e.g., "FIZBIN-MIB" from the
+ example in Section 5.8), is not changed when the information
+ module is revised.
+
+
+ 10.1. Object Assignments
+
+ If any non-editorial change is made to any clause of a object
+ assignment, then the OBJECT IDENTIFIER value associated with
+ that object assignment must also be changed, along with its
+ associated descriptor.
+
+
+ 10.2. Object Definitions
+
+ An object definition may be revised in any of the following
+ ways:
+
+ (1) A SYNTAX clause containing an enumerated INTEGER may have
+ new enumerations added or existing labels changed.
+
+ (2) A STATUS clause value of "current" may be revised as
+ "deprecated" or "obsolete". Similarly, a STATUS clause
+ value of "deprecated" may be revised as "obsolete".
+
+ (3) A DEFVAL clause may be added or updated.
+
+ (4) A REFERENCE clause may be added or updated.
+
+ (5) A UNITS clause may be added.
+
+ (6) A conceptual row may be augmented by adding new columnar
+ objects at the end of the row.
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 41]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ (7) Entirely new objects may be defined, named with
+ previously unassigned OBJECT IDENTIFIER values.
+
+ Otherwise, if the semantics of any previously defined object
+ are changed (i.e., if a non-editorial change is made to any
+ clause other those specifically allowed above), then the
+ OBJECT IDENTIFIER value associated with that object must also
+ be changed.
+
+ Note that changing the descriptor associated with an existing
+ object is considered a semantic change, as these strings may
+ be used in an IMPORTS statement.
+
+ Finally, note that if an object has the value of its STATUS
+ clause changed, then the value of its DESCRIPTION clause
+ should be updated accordingly.
+
+
+ 10.3. Notification Definitions
+
+ A notification definition may be revised in any of the
+ following ways:
+
+ (1) A REFERENCE clause may be added or updated.
+
+ Otherwise, if the semantics of any previously defined
+ notification are changed (i.e., if a non-editorial change is
+ made to any clause other those specifically allowed above),
+ then the OBJECT IDENTIFIER value associated with that
+ notification must also be changed.
+
+ Note that changing the descriptor associated with an existing
+ notification is considered a semantic change, as these strings
+ may be used in an IMPORTS statement.
+
+ Finally, note that if an object has the value of its STATUS
+ clause changed, then the value of its DESCRIPTION clause
+ should be updated accordingly.
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 42]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 11. Appendix: de-OSIfying a MIB module
+
+ There has been an increasing amount of work recently on taking
+ MIBs defined by other organizations (e.g., the IEEE) and de-
+ osifying them for use with the Internet-standard network
+ management framework. The steps to achieve this are
+ straight-forward, though tedious. Of course, it is helpful to
+ already be experienced in writing MIB modules for use with the
+ Internet-standard network management framework.
+
+ The first step is to construct a skeletal MIB module, as shown
+ earlier in Section 5.8. The next step is to categorize the
+ objects into groups. Optional objects are not permitted.
+ Thus, when a MIB module is created, optional objects must be
+ placed in a additional groups, which, if implemented, all
+ objects in the group must be implemented. For the first pass,
+ it is wisest to simply ignore any optional objects in the
+ original MIB: experience shows it is better to define a core
+ MIB module first, containing only essential objects; later, if
+ experience demands, other objects can be added.
+
+
+ 11.1. Managed Object Mapping
+
+ Next for each managed object class, determine whether there
+ can exist multiple instances of that managed object class. If
+ not, then for each of its attributes, use the OBJECT-TYPE
+ macro to make an equivalent definition.
+
+ Otherwise, if multiple instances of the managed object class
+ can exist, then define a conceptual table having conceptual
+ rows each containing a columnar object for each of the managed
+ object class's attributes. If the managed object class is
+ contained within the containment tree of another managed
+ object class, then the assignment of an object is normally
+ required for each of the "distinguished attributes" of the
+ containing managed object class. If they do not already exist
+ within the MIB module, then they can be added via the
+ definition of additional columnar objects in the conceptual
+ row corresponding to the contained managed object class.
+
+ In defining a conceptual row, it is useful to consider the
+ optimization of network management operations which will act
+ upon its columnar objects. In particular, it is wisest to
+ avoid defining more columnar objects within a conceptual row,
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 43]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ than can fit in a single PDU. As a rule of thumb, a
+ conceptual row should contain no more than approximately 20
+ objects. Similarly, or as a way to abide by the "20 object
+ guideline", columnar objects should be grouped into tables
+ according to the expected grouping of network management
+ operations upon them. As such, the content of conceptual rows
+ should reflect typical access scenarios, e.g., they should be
+ organized along functional lines such as one row for
+ statistics and another row for parameters, or along usage
+ lines such as commonly-needed objects versus rarely-needed
+ objects.
+
+ On the other hand, the definition of conceptual rows where the
+ number of columnar objects used as indexes outnumbers the
+ number used to hold information, should also be avoided. In
+ particular, the splitting of a managed object class's
+ attributes into many conceptual tables should not be used as a
+ way to obtain the same degree of flexibility/complexity as is
+ often found in MIBs with a myriad of optionals.
+
+
+ 11.1.1. Mapping to the SYNTAX clause
+
+ When mapping to the SYNTAX clause of the OBJECT-type macro:
+
+ (1) An object with BOOLEAN syntax becomes a TruthValue [3].
+
+ (2) An object with INTEGER syntax becomes an Integer32.
+
+ (3) An object with ENUMERATED syntax becomes an INTEGER with
+ enumerations, taking any of the values given which can be
+ represented with an Integer32.
+
+ (4) An object with BIT STRING syntax but no enumerations
+ becomes an OCTET STRING.
+
+ (5) An object with a character string syntax becomes either
+ an OCTET STRING, or a DisplayString [3], depending on the
+ repertoire of the character string.
+
+ (6) A non-tabular object with a complex syntax, such as REAL
+ or EXTERNAL, must be decomposed, usually into an OCTET
+ STRING (if sensible). As a rule, any object with a
+ complicated syntax should be avoided.
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 44]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ (7) Tabular objects must be decomposed into rows of columnar
+ objects.
+
+
+ 11.1.2. Mapping to the UNITS clause
+
+ If the description of this managed object defines a unit-
+ basis, then mapping to this clause is straight-forward.
+
+
+ 11.1.3. Mapping to the MAX-ACCESS clause
+
+ This is straight-forward.
+
+
+ 11.1.4. Mapping to the STATUS clause
+
+ This is straight-forward.
+
+
+ 11.1.5. Mapping to the DESCRIPTION clause
+
+ This is straight-forward: simply copy the text, making sure
+ that any embedded double quotation marks are sanitized (i.e.,
+ replaced with single-quotes or removed).
+
+
+ 11.1.6. Mapping to the REFERENCE clause
+
+ This is straight-forward: simply include a textual reference
+ to the object being mapped, the document which defines the
+ object, and perhaps a page number in the document.
+
+
+ 11.1.7. Mapping to the INDEX clause
+
+ If necessary, decide how instance-identifiers for columnar
+ objects are to be formed and define this clause accordingly.
+
+
+ 11.1.8. Mapping to the DEFVAL clause
+
+ Decide if a meaningful default value can be assigned to the
+ object being mapped, and if so, define the DEFVAL clause
+ accordingly.
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 45]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 11.2. Action Mapping
+
+ Actions are modeled as read-write objects, in which writing a
+ particular value results in a state change. (Usually, as a
+ part of this state change, some action might take place.)
+
+
+ 11.2.1. Mapping to the SYNTAX clause
+
+ Usually the Integer32 syntax is used with a distinguished
+ value provided for each action that the object provides access
+ to. In addition, there is usually one other distinguished
+ value, which is the one returned when the object is read.
+
+
+ 11.2.2. Mapping to the MAX-ACCESS clause
+
+ Always use read-write or read-create.
+
+
+ 11.2.3. Mapping to the STATUS clause
+
+ This is straight-forward.
+
+
+ 11.2.4. Mapping to the DESCRIPTION clause
+
+ This is straight-forward: simply copy the text, making sure
+ that any embedded double quotation marks are sanitized (i.e.,
+ replaced with single-quotes or removed).
+
+
+ 11.2.5. Mapping to the REFERENCE clause
+
+ This is straight-forward: simply include a textual reference
+ to the action being mapped, the document which defines the
+ action, and perhaps a page number in the document.
+
+
+ 11.3. Event Mapping
+
+ Events are modeled as SNMPv2 notifications using
+ NOTIFICATION-TYPE macro. However, recall that SNMPv2
+ emphasizes trap-directed polling. As such, few, and usually
+ no, notifications, need be defined for any MIB module.
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 46]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 11.3.1. Mapping to the STATUS clause
+
+ This is straight-forward.
+
+
+ 11.3.2. Mapping to the DESCRIPTION clause
+
+ This is straight-forward: simply copy the text, making sure
+ that any embedded double quotation marks are sanitized (i.e.,
+ replaced with single-quotes or removed).
+
+
+ 11.3.3. Mapping to the REFERENCE clause
+
+ This is straight-forward: simply include a textual reference
+ to the notification being mapped, the document which defines
+ the notification, and perhaps a page number in the document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 47]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 12. Acknowledgements
+
+ The section on object definitions (and MIB de-osification) is
+ based, in part, on RFCs 1155 and 1212. The IMPLIED keyword is
+ based on a conversation with David T. Perkins in December,
+ 1991.
+
+ The section on trap definitions is based, in part, on RFC
+ 1215.
+
+ Finally, the comments of the SNMP version 2 working group are
+ gratefully acknowledged:
+
+ Beth Adams, Network Management Forum
+ Steve Alexander, INTERACTIVE Systems Corporation
+ David Arneson, Cabletron Systems
+ Toshiya Asaba
+ Fred Baker, ACC
+ Jim Barnes, Xylogics, Inc.
+ Brian Bataille
+ Andy Bierman, SynOptics Communications, Inc.
+ Uri Blumenthal, IBM Corporation
+ Fred Bohle, Interlink
+ Jack Brown
+ Theodore Brunner, Bellcore
+ Stephen F. Bush, GE Information Services
+ Jeffrey D. Case, University of Tennessee, Knoxville
+ John Chang, IBM Corporation
+ Szusin Chen, Sun Microsystems
+ Robert Ching
+ Chris Chiotasso, Ungermann-Bass
+ Bobby A. Clay, NASA/Boeing
+ John Cooke, Chipcom
+ Tracy Cox, Bellcore
+ Juan Cruz, Datability, Inc.
+ David Cullerot, Cabletron Systems
+ Cathy Cunningham, Microcom
+ James R. (Chuck) Davin, Bellcore
+ Michael Davis, Clearpoint
+ Mike Davison, FiberCom
+ Cynthia DellaTorre, MITRE
+ Taso N. Devetzis, Bellcore
+ Manual Diaz, DAVID Systems, Inc.
+ Jon Dreyer, Sun Microsystems
+ David Engel, Optical Data Systems
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 48]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ Mike Erlinger, Lexcel
+ Roger Fajman, NIH
+ Daniel Fauvarque, Sun Microsystems
+ Karen Frisa, CMU
+ Shari Galitzer, MITRE
+ Shawn Gallagher, Digital Equipment Corporation
+ Richard Graveman, Bellcore
+ Maria Greene, Xyplex, Inc.
+ Michel Guittet, Apple
+ Robert Gutierrez, NASA
+ Bill Hagerty, Cabletron Systems
+ Gary W. Haney, Martin Marietta Energy Systems
+ Patrick Hanil, Nokia Telecommunications
+ Matt Hecht, SNMP Research, Inc.
+ Edward A. Heiner, Jr., Synernetics Inc.
+ Susan E. Hicks, Martin Marietta Energy Systems
+ Geral Holzhauer, Apple
+ John Hopprich, DAVID Systems, Inc.
+ Jeff Hughes, Hewlett-Packard
+ Robin Iddon, Axon Networks, Inc.
+ David Itusak
+ Kevin M. Jackson, Concord Communications, Inc.
+ Ole J. Jacobsen, Interop Company
+ Ronald Jacoby, Silicon Graphics, Inc.
+ Satish Joshi, SynOptics Communications, Inc.
+ Frank Kastenholz, FTP Software
+ Mark Kepke, Hewlett-Packard
+ Ken Key, SNMP Research, Inc.
+ Zbiginew Kielczewski, Eicon
+ Jongyeoi Kim
+ Andrew Knutsen, The Santa Cruz Operation
+ Michael L. Kornegay, VisiSoft
+ Deirdre C. Kostik, Bellcore
+ Cheryl Krupczak, Georgia Tech
+ Mark S. Lewis, Telebit
+ David Lin
+ David Lindemulder, AT&T/NCR
+ Ben Lisowski, Sprint
+ David Liu, Bell-Northern Research
+ John Lunny, The Wollongong Group
+ Robert C. Lushbaugh Martin, Marietta Energy Systems
+ Michael Luufer, BBN
+ Carl Madison, Star-Tek, Inc.
+ Keith McCloghrie, Hughes LAN Systems
+ Evan McGinnis, 3Com Corporation
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 49]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ Bill McKenzie, IBM Corporation
+ Donna McMaster, SynOptics Communications, Inc.
+ John Medicke, IBM Corporation
+ Doug Miller, Telebit
+ Dave Minnich, FiberCom
+ Mohammad Mirhakkak, MITRE
+ Rohit Mital, Protools
+ George Mouradian, AT&T Bell Labs
+ Patrick Mullaney, Cabletron Systems
+ Dan Myers, 3Com Corporation
+ Rina Nathaniel, Rad Network Devices Ltd.
+ Hien V. Nguyen, Sprint
+ Mo Nikain
+ Tom Nisbet
+ William B. Norton, MERIT
+ Steve Onishi, Wellfleet Communications, Inc.
+ David T. Perkins, SynOptics Communications, Inc.
+ Carl Powell, BBN
+ Ilan Raab, SynOptics Communications, Inc.
+ Richard Ramons, AT&T
+ Venkat D. Rangan, Metric Network Systems, Inc.
+ Louise Reingold, Sprint
+ Sam Roberts, Farallon Computing, Inc.
+ Kary Robertson, Concord Communications, Inc.
+ Dan Romascanu, Lannet Data Communications Ltd.
+ Marshall T. Rose, Dover Beach Consulting, Inc.
+ Shawn A. Routhier, Epilogue Technology Corporation
+ Chris Rozman
+ Asaf Rubissa, Fibronics
+ Jon Saperia, Digital Equipment Corporation
+ Michael Sapich
+ Mike Scanlon, Interlan
+ Sam Schaen, MITRE
+ John Seligson, Ultra Network Technologies
+ Paul A. Serice, Corporation for Open Systems
+ Chris Shaw, Banyan Systems
+ Timon Sloane
+ Robert Snyder, Cisco Systems
+ Joo Young Song
+ Roy Spitier, Sprint
+ Einar Stefferud, Network Management Associates
+ John Stephens, Cayman Systems, Inc.
+ Robert L. Stewart, Xyplex, Inc. (chair)
+ Kaj Tesink, Bellcore
+ Dean Throop, Data General
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 50]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ Ahmet Tuncay, France Telecom-CNET
+ Maurice Turcotte, Racal Datacom
+ Warren Vik, INTERACTIVE Systems Corporation
+ Yannis Viniotis
+ Steven L. Waldbusser, Carnegie Mellon Universitty
+ Timothy M. Walden, ACC
+ Alice Wang, Sun Microsystems
+ James Watt, Newbridge
+ Luanne Waul, Timeplex
+ Donald E. Westlake III, Digital Equipment Corporation
+ Gerry White
+ Bert Wijnen, IBM Corporation
+ Peter Wilson, 3Com Corporation
+ Steven Wong, Digital Equipment Corporation
+ Randy Worzella, IBM Corporation
+ Daniel Woycke, MITRE
+ Honda Wu
+ Jeff Yarnell, Protools
+ Chris Young, Cabletron
+ Kiho Yum, 3Com Corporation
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 51]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 13. References
+
+ [1] Information processing systems - Open Systems
+ Interconnection - Specification of Abstract Syntax
+ Notation One (ASN.1), International Organization for
+ Standardization. International Standard 8824, (December,
+ 1987).
+
+ [2] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
+ "Conformance Statements for version 2 of the the Simple
+ Network Management Protocol (SNMPv2)", RFC 1444, SNMP
+ Research, Inc., Hughes LAN Systems, Dover Beach
+ Consulting, Inc., Carnegie Mellon University, April 1993.
+
+ [3] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
+ "Textual Conventions for version 2 of the the Simple
+ Network Management Protocol (SNMPv2)", RFC 1443, SNMP
+ Research, Inc., Hughes LAN Systems, Dover Beach
+ Consulting, Inc., Carnegie Mellon University, April 1993.
+
+ [4] Information processing systems - Open Systems
+ Interconnection - Specification of Basic Encoding Rules
+ for Abstract Syntax Notation One (ASN.1), International
+ Organization for Standardization. International Standard
+ 8825, (December, 1987).
+
+ [5] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
+ "Management Information Base for version 2 of the Simple
+ Network Management Protocol (SNMPv2)", RFC 1450, SNMP
+ Research, Inc., Hughes LAN Systems, Dover Beach
+ Consulting, Inc., Carnegie Mellon University, April 1993.
+
+ [6] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
+ "Protocol Operations for version 2 of the Simple Network
+ Management Protocol (SNMPv2)", RFC 1448, SNMP Research,
+ Inc., Hughes LAN Systems, Dover Beach Consulting, Inc.,
+ Carnegie Mellon University, April 1993.
+
+ [7] McCloghrie, K., and Rose, M., "Management Information
+ Base for Network Management of TCP/IP-based internets:
+ MIB-II", STD 17, RFC 1213, March 1991.
+
+ [8] McCloghrie, K., and Galvin, J., "Party MIB for version 2
+ of the Simple Network Management Protocol (SNMPv2)", RFC
+ 1447, Hughes LAN Systems, Trusted Information Systems,
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 52]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ April 1993.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 53]
+
+
+
+
+
+ RFC 1442 SMI for SNMPv2 April 1993
+
+
+ 14. Security Considerations
+
+ Security issues are not discussed in this memo.
+
+
+ 15. Authors' Addresses
+
+ Jeffrey D. Case
+ SNMP Research, Inc.
+ 3001 Kimberlin Heights Rd.
+ Knoxville, TN 37920-9716
+ US
+
+ Phone: +1 615 573 1434
+ Email: case@snmp.com
+
+
+ Keith McCloghrie
+ Hughes LAN Systems
+ 1225 Charleston Road
+ Mountain View, CA 94043
+ US
+
+ Phone: +1 415 966 7934
+ Email: kzm@hls.com
+
+
+ Marshall T. Rose
+ Dover Beach Consulting, Inc.
+ 420 Whisman Court
+ Mountain View, CA 94043-2186
+ US
+
+ Phone: +1 415 968 1052
+ Email: mrose@dbc.mtview.ca.us
+
+ Steven Waldbusser
+ Carnegie Mellon University
+ 4910 Forbes Ave
+ Pittsburgh, PA 15213
+ US
+
+ Phone: +1 412 268 6628
+ Email: waldbusser@cmu.edu
+
+
+
+
+
+
+ Case, McCloghrie, Rose & Waldbusser [Page 54]
+