8 Network Working Group Editors of this version:
9 Request for Comments: 2578 K. McCloghrie
11 Obsoletes: 1902 D. Perkins
12 Category: Standards Track SNMPinfo
15 Authors of previous version:
21 First Virtual Holdings
23 International Network Services
27 Structure of Management Information Version 2 (SMIv2)
32 This document specifies an Internet standards track protocol for the
33 Internet community, and requests discussion and suggestions for
34 improvements. Please refer to the current edition of the "Internet
35 Official Protocol Standards" (STD 1) for the standardization state
36 and status of this protocol. Distribution of this memo is unlimited.
40 Copyright (C) The Internet Society (1999). All Rights Reserved.
45 1 Introduction .................................................3
46 1.1 A Note on Terminology ......................................4
47 2 Definitions ..................................................4
48 2.1 The MODULE-IDENTITY macro ..................................5
49 2.2 Object Names and Syntaxes ..................................5
50 2.3 The OBJECT-TYPE macro ......................................8
51 2.5 The NOTIFICATION-TYPE macro ...............................10
52 2.6 Administrative Identifiers ................................11
53 3 Information Modules .........................................11
54 3.1 Macro Invocation ..........................................12
55 3.1.1 Textual Values and Strings ..............................13
58 McCloghrie, et al. Standards Track [Page 1]
64 RFC 2578 SMIv2 April 1999
67 3.2 IMPORTing Symbols .........................................14
68 3.3 Exporting Symbols .........................................14
69 3.4 ASN.1 Comments ............................................14
70 3.5 OBJECT IDENTIFIER values ..................................15
71 3.6 OBJECT IDENTIFIER usage ...................................15
72 3.7 Reserved Keywords .........................................16
73 4 Naming Hierarchy ............................................16
74 5 Mapping of the MODULE-IDENTITY macro ........................17
75 5.1 Mapping of the LAST-UPDATED clause ........................17
76 5.2 Mapping of the ORGANIZATION clause ........................17
77 5.3 Mapping of the CONTACT-INFO clause ........................18
78 5.4 Mapping of the DESCRIPTION clause .........................18
79 5.5 Mapping of the REVISION clause ............................18
80 5.5.1 Mapping of the DESCRIPTION sub-clause ...................18
81 5.6 Mapping of the MODULE-IDENTITY value ......................18
82 5.7 Usage Example .............................................18
83 6 Mapping of the OBJECT-IDENTITY macro ........................19
84 6.1 Mapping of the STATUS clause ..............................19
85 6.2 Mapping of the DESCRIPTION clause .........................20
86 6.3 Mapping of the REFERENCE clause ...........................20
87 6.4 Mapping of the OBJECT-IDENTITY value ......................20
88 6.5 Usage Example .............................................20
89 7 Mapping of the OBJECT-TYPE macro ............................20
90 7.1 Mapping of the SYNTAX clause ..............................21
91 7.1.1 Integer32 and INTEGER ...................................21
92 7.1.2 OCTET STRING ............................................21
93 7.1.3 OBJECT IDENTIFIER .......................................22
94 7.1.4 The BITS construct ......................................22
95 7.1.5 IpAddress ...............................................22
96 7.1.6 Counter32 ...............................................23
97 7.1.7 Gauge32 .................................................23
98 7.1.8 TimeTicks ...............................................24
99 7.1.9 Opaque ..................................................24
100 7.1.10 Counter64 ..............................................24
101 7.1.11 Unsigned32 .............................................25
102 7.1.12 Conceptual Tables ......................................25
103 7.1.12.1 Creation and Deletion of Conceptual Rows .............26
104 7.2 Mapping of the UNITS clause ...............................26
105 7.3 Mapping of the MAX-ACCESS clause ..........................26
106 7.4 Mapping of the STATUS clause ..............................27
107 7.5 Mapping of the DESCRIPTION clause .........................27
108 7.6 Mapping of the REFERENCE clause ...........................27
109 7.7 Mapping of the INDEX clause ...............................27
110 7.8 Mapping of the AUGMENTS clause ............................29
111 7.8.1 Relation between INDEX and AUGMENTS clauses .............30
112 7.9 Mapping of the DEFVAL clause ..............................30
113 7.10 Mapping of the OBJECT-TYPE value .........................31
114 7.11 Usage Example ............................................32
117 McCloghrie, et al. Standards Track [Page 2]
123 RFC 2578 SMIv2 April 1999
126 8 Mapping of the NOTIFICATION-TYPE macro ......................34
127 8.1 Mapping of the OBJECTS clause .............................34
128 8.2 Mapping of the STATUS clause ..............................34
129 8.3 Mapping of the DESCRIPTION clause .........................35
130 8.4 Mapping of the REFERENCE clause ...........................35
131 8.5 Mapping of the NOTIFICATION-TYPE value ....................35
132 8.6 Usage Example .............................................35
133 9 Refined Syntax ..............................................36
134 10 Extending an Information Module ............................37
135 10.1 Object Assignments .......................................37
136 10.2 Object Definitions .......................................38
137 10.3 Notification Definitions .................................39
138 11 Appendix A: Detailed Sub-typing Rules ......................40
139 11.1 Syntax Rules .............................................40
140 11.2 Examples .................................................41
141 12 Security Considerations ....................................41
142 13 Editors' Addresses .........................................41
143 14 References .................................................42
144 15 Full Copyright Statement ...................................43
148 Management information is viewed as a collection of managed objects,
149 residing in a virtual information store, termed the Management
150 Information Base (MIB). Collections of related objects are defined
151 in MIB modules. These modules are written using an adapted subset of
152 OSI's Abstract Syntax Notation One, ASN.1 (1988) [1]. It is the
153 purpose of this document, the Structure of Management Information
154 (SMI), to define that adapted subset, and to assign a set of
155 associated administrative values.
157 The SMI is divided into three parts: module definitions, object
158 definitions, and, notification definitions.
160 (1) Module definitions are used when describing information modules.
161 An ASN.1 macro, MODULE-IDENTITY, is used to concisely convey the
162 semantics of an information module.
164 (2) Object definitions are used when describing managed objects. An
165 ASN.1 macro, OBJECT-TYPE, is used to concisely convey the syntax
166 and semantics of a managed object.
168 (3) Notification definitions are used when describing unsolicited
169 transmissions of management information. An ASN.1 macro,
170 NOTIFICATION-TYPE, is used to concisely convey the syntax and
171 semantics of a notification.
176 McCloghrie, et al. Standards Track [Page 3]
182 RFC 2578 SMIv2 April 1999
185 1.1. A Note on Terminology
187 For the purpose of exposition, the original Structure of Management
188 Information, as described in RFCs 1155 (STD 16), 1212 (STD 16), and
189 RFC 1215, is termed the SMI version 1 (SMIv1). The current version
190 of the Structure of Management Information is termed SMI version 2
195 SNMPv2-SMI DEFINITIONS ::= BEGIN
198 -- the path to the root
200 org OBJECT IDENTIFIER ::= { iso 3 } -- "iso" = 1
201 dod OBJECT IDENTIFIER ::= { org 6 }
202 internet OBJECT IDENTIFIER ::= { dod 1 }
204 directory OBJECT IDENTIFIER ::= { internet 1 }
206 mgmt OBJECT IDENTIFIER ::= { internet 2 }
207 mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
208 transmission OBJECT IDENTIFIER ::= { mib-2 10 }
210 experimental OBJECT IDENTIFIER ::= { internet 3 }
212 private OBJECT IDENTIFIER ::= { internet 4 }
213 enterprises OBJECT IDENTIFIER ::= { private 1 }
215 security OBJECT IDENTIFIER ::= { internet 5 }
217 snmpV2 OBJECT IDENTIFIER ::= { internet 6 }
220 snmpDomains OBJECT IDENTIFIER ::= { snmpV2 1 }
223 snmpProxys OBJECT IDENTIFIER ::= { snmpV2 2 }
226 snmpModules OBJECT IDENTIFIER ::= { snmpV2 3 }
228 -- Extended UTCTime, to allow dates with four-digit years
229 -- (Note that this definition of ExtUTCTime is not to be IMPORTed
231 ExtUTCTime ::= OCTET STRING(SIZE(11 | 13))
232 -- format is YYMMDDHHMMZ or YYYYMMDDHHMMZ
235 McCloghrie, et al. Standards Track [Page 4]
241 RFC 2578 SMIv2 April 1999
244 -- where: YY - last two digits of year (only years
245 -- between 1900-1999)
246 -- YYYY - last four digits of the year (any year)
247 -- MM - month (01 through 12)
248 -- DD - day of month (01 through 31)
249 -- HH - hours (00 through 23)
250 -- MM - minutes (00 through 59)
251 -- Z - denotes GMT (the ASCII character Z)
253 -- For example, "9502192015Z" and "199502192015Z" represent
254 -- 8:15pm GMT on 19 February 1995. Years after 1999 must use
255 -- the four digit year format. Years 1900-1999 may use the
256 -- two or four digit format.
258 -- definitions for information modules
260 MODULE-IDENTITY MACRO ::=
263 "LAST-UPDATED" value(Update ExtUTCTime)
270 value(VALUE OBJECT IDENTIFIER)
279 "REVISION" value(Update ExtUTCTime)
282 -- a character string as defined in section 3.1.1
283 Text ::= value(IA5String)
287 OBJECT-IDENTITY MACRO ::=
294 McCloghrie, et al. Standards Track [Page 5]
300 RFC 2578 SMIv2 April 1999
306 value(VALUE OBJECT IDENTIFIER)
317 -- a character string as defined in section 3.1.1
318 Text ::= value(IA5String)
323 -- (Note that these definitions of ObjectName and NotificationName
324 -- are not to be IMPORTed by MIB modules.)
334 -- the "base types" defined here are:
335 -- 3 built-in ASN.1 types: INTEGER, OCTET STRING, OBJECT IDENTIFIER
336 -- 8 application-defined types: Integer32, IpAddress, Counter32,
337 -- Gauge32, Unsigned32, TimeTicks, Opaque, and Counter64
344 -- note that SEQUENCEs for conceptual tables and
345 -- rows are not mentioned here...
353 McCloghrie, et al. Standards Track [Page 6]
359 RFC 2578 SMIv2 April 1999
362 -- built-in ASN.1 types
366 -- INTEGERs with a more restrictive range
368 integer-value -- includes Integer32
369 INTEGER (-2147483648..2147483647),
371 -- OCTET STRINGs with a more restrictive size
374 OCTET STRING (SIZE (0..65535)),
380 -- indistinguishable from INTEGER, but never needs more than
381 -- 32-bits for a two's complement representation
383 INTEGER (-2147483648..2147483647)
386 -- application-wide types
388 ApplicationSyntax ::=
405 unsigned-integer-value -- includes Gauge32
409 -- in network-byte order
412 McCloghrie, et al. Standards Track [Page 7]
418 RFC 2578 SMIv2 April 1999
421 -- (this is a tagged type for historical reasons)
424 IMPLICIT OCTET STRING (SIZE (4))
429 IMPLICIT INTEGER (0..4294967295)
434 IMPLICIT INTEGER (0..4294967295)
436 -- an unsigned 32-bit quantity
437 -- indistinguishable from Gauge32
440 IMPLICIT INTEGER (0..4294967295)
442 -- hundredths of seconds since an epoch
445 IMPLICIT INTEGER (0..4294967295)
447 -- for backward-compatibility only
450 IMPLICIT OCTET STRING
452 -- for counters that wrap in less than one hour with only 32 bits
455 IMPLICIT INTEGER (0..18446744073709551615)
458 -- definition for objects
460 OBJECT-TYPE MACRO ::=
471 McCloghrie, et al. Standards Track [Page 8]
477 RFC 2578 SMIv2 April 1999
484 value(VALUE ObjectName)
486 Syntax ::= -- Must be one of the following:
487 -- a base type (or its refinement),
488 -- a textual convention (or its refinement), or
489 -- a BITS pseudo-type
491 | "BITS" "{" NamedBits "}"
493 NamedBits ::= NamedBit
494 | NamedBits "," NamedBit
496 NamedBit ::= identifier "(" number ")" -- number is nonnegative
504 | "accessible-for-notify"
519 "INDEX" "{" IndexTypes "}"
520 | "AUGMENTS" "{" Entry "}"
524 | IndexTypes "," IndexType
530 McCloghrie, et al. Standards Track [Page 9]
536 RFC 2578 SMIv2 April 1999
540 -- use the SYNTAX value of the
541 -- correspondent OBJECT-TYPE invocation
544 -- use the INDEX value of the
545 -- correspondent OBJECT-TYPE invocation
548 DefValPart ::= "DEFVAL" "{" Defvalue "}"
551 Defvalue ::= -- must be valid for the type specified in
552 -- SYNTAX clause of same OBJECT-TYPE macro
556 BitsValue ::= BitNames
560 | BitNames "," BitName
562 BitName ::= identifier
564 -- a character string as defined in section 3.1.1
565 Text ::= value(IA5String)
569 -- definitions for notifications
571 NOTIFICATION-TYPE MACRO ::=
580 value(VALUE NotificationName)
583 "OBJECTS" "{" Objects "}"
589 McCloghrie, et al. Standards Track [Page 10]
595 RFC 2578 SMIv2 April 1999
611 -- a character string as defined in section 3.1.1
612 Text ::= value(IA5String)
615 -- definitions of administrative identifiers
617 zeroDotZero OBJECT-IDENTITY
620 "A value used for null identifiers."
625 3. Information Modules
627 An "information module" is an ASN.1 module defining information
628 relating to network management.
630 The SMI describes how to use an adapted subset of ASN.1 (1988) to
631 define an information module. Further, additional restrictions are
632 placed on "standard" information modules. It is strongly recommended
633 that "enterprise-specific" information modules also adhere to these
636 Typically, there are three kinds of information modules:
638 (1) MIB modules, which contain definitions of inter-related managed
639 objects, make use of the OBJECT-TYPE and NOTIFICATION-TYPE macros;
641 (2) compliance statements for MIB modules, which make use of the
642 MODULE-COMPLIANCE and OBJECT-GROUP macros [2]; and,
644 (3) capability statements for agent implementations which make use of
645 the AGENT-CAPABILITIES macros [2].
648 McCloghrie, et al. Standards Track [Page 11]
654 RFC 2578 SMIv2 April 1999
657 This classification scheme does not imply a rigid taxonomy. For
658 example, a "standard" information module will normally include
659 definitions of managed objects and a compliance statement.
660 Similarly, an "enterprise-specific" information module might include
661 definitions of managed objects and a capability statement. Of
662 course, a "standard" information module may not contain capability
665 The constructs of ASN.1 allowed in SMIv2 information modules include:
666 the IMPORTS clause, value definitions for OBJECT IDENTIFIERs, type
667 definitions for SEQUENCEs (with restrictions), ASN.1 type assignments
668 of the restricted ASN.1 types allowed in SMIv2, and instances of
669 ASN.1 macros defined in this document and its companion documents [2,
670 3]. Additional ASN.1 macros must not be defined in SMIv2 information
671 modules. SMIv1 macros must not be used in SMIv2 information modules.
673 The names of all standard information modules must be unique (but
674 different versions of the same information module should have the
675 same name). Developers of enterprise information modules are
676 encouraged to choose names for their information modules that will
677 have a low probability of colliding with standard or other enterprise
678 information modules. An information module may not use the ASN.1
679 construct of placing an object identifier value between the module
680 name and the "DEFINITIONS" keyword. For the purposes of this
681 specification, an ASN.1 module name begins with an upper-case letter
682 and continues with zero or more letters, digits, or hyphens, except
683 that a hyphen can not be the last character, nor can there be two
686 All information modules start with exactly one invocation of the
687 MODULE-IDENTITY macro, which provides contact information as well as
688 revision history to distinguish between versions of the same
689 information module. This invocation must appear immediately after
690 any IMPORTs statements.
692 3.1. Macro Invocation
694 Within an information module, each macro invocation appears as:
696 <descriptor> <macro> <clauses> ::= <value>
698 where <descriptor> corresponds to an ASN.1 identifier, <macro> names
699 the macro being invoked, and <clauses> and <value> depend on the
700 definition of the macro. (Note that this definition of a descriptor
701 applies to all macros defined in this memo and in [2].)
707 McCloghrie, et al. Standards Track [Page 12]
713 RFC 2578 SMIv2 April 1999
716 For the purposes of this specification, an ASN.1 identifier consists
717 of one or more letters or digits, and its initial character must be a
718 lower-case letter. Note that hyphens are not allowed by this
719 specification (except for use by information modules converted from
720 SMIv1 which did allow hyphens).
722 For all descriptors appearing in an information module, the
723 descriptor shall be unique and mnemonic, and shall not exceed 64
724 characters in length. (However, descriptors longer than 32
725 characters are not recommended.) This promotes a common language for
726 humans to use when discussing the information module and also
727 facilitates simple table mappings for user-interfaces.
729 The set of descriptors defined in all "standard" information modules
732 Finally, by convention, if the descriptor refers to an object with a
733 SYNTAX clause value of either Counter32 or Counter64, then the
734 descriptor used for the object should denote plurality.
736 3.1.1. Textual Values and Strings
738 Some clauses in a macro invocation may take a character string as a
739 textual value (e.g., the DESCRIPTION clause). Other clauses take
740 binary or hexadecimal strings (in any position where a non-negative
743 A character string is preceded and followed by the quote character
744 ("), and consists of an arbitrary number (possibly zero) of:
746 - any 7-bit displayable ASCII characters except quote ("),
749 - line terminator characters (\n or \r\n).
751 The value of a character string is interpreted as ASCII.
753 A binary string consists of a number (possibly zero) of zeros and
754 ones preceded by a single (') and followed by either the pair ('B) or
755 ('b), where the number is a multiple of eight.
757 A hexadecimal string consists of an even number (possibly zero) of
758 hexadecimal digits, preceded by a single (') and followed by either
759 the pair ('H) or ('h). Digits specified via letters can be in upper
762 Note that ASN.1 comments can not be enclosed inside any of these
766 McCloghrie, et al. Standards Track [Page 13]
772 RFC 2578 SMIv2 April 1999
775 3.2. IMPORTing Symbols
777 To reference an external object, the IMPORTS statement must be used
778 to identify both the descriptor and the module in which the
779 descriptor is defined, where the module is identified by its ASN.1
782 Note that when symbols from "enterprise-specific" information modules
783 are referenced (e.g., a descriptor), there is the possibility of
784 collision. As such, if different objects with the same descriptor
785 are IMPORTed, then this ambiguity is resolved by prefixing the
786 descriptor with the name of the information module and a dot ("."),
791 (All descriptors must be unique within any information module.)
793 Of course, this notation can be used to refer to objects even when
794 there is no collision when IMPORTing symbols.
796 Finally, if any of the ASN.1 named types and macros defined in this
797 document, specifically:
799 Counter32, Counter64, Gauge32, Integer32, IpAddress, MODULE-
800 IDENTITY, NOTIFICATION-TYPE, Opaque, OBJECT-TYPE, OBJECT-
801 IDENTITY, TimeTicks, Unsigned32,
803 or any of those defined in [2] or [3], are used in an information
804 module, then they must be imported using the IMPORTS statement.
805 However, the following must not be included in an IMPORTS statement:
807 - named types defined by ASN.1 itself, specifically: INTEGER,
808 OCTET STRING, OBJECT IDENTIFIER, SEQUENCE, SEQUENCE OF type,
809 - the BITS construct.
811 3.3. Exporting Symbols
813 The ASN.1 EXPORTS statement is not allowed in SMIv2 information
814 modules. All items defined in an information module are
815 automatically exported.
819 ASN.1 comments can be included in an information module. However, it
820 is recommended that all substantive descriptions be placed within an
821 appropriate DESCRIPTION clause.
825 McCloghrie, et al. Standards Track [Page 14]
831 RFC 2578 SMIv2 April 1999
834 ASN.1 comments commence with a pair of adjacent hyphens and end with
835 the next pair of adjacent hyphens or at the end of the line,
836 whichever occurs first. Comments ended by a pair of hyphens have the
837 effect of a single space character.
839 3.5. OBJECT IDENTIFIER values
841 An OBJECT IDENTIFIER value is an ordered list of non-negative
842 numbers. For the SMIv2, each number in the list is referred to as a
843 sub-identifier, there are at most 128 sub-identifiers in a value, and
844 each sub-identifier has a maximum value of 2^32-1 (4294967295
847 All OBJECT IDENTIFIER values have at least two sub-identifiers, where
848 the value of the first sub-identifier is one of the following well-
856 (Note that this SMI does not recognize "new" well-known names, e.g.,
857 as defined when the CCITT became the ITU.)
859 3.6. OBJECT IDENTIFIER usage
861 OBJECT IDENTIFIERs are used in information modules in two ways:
863 (1) registration: the definition of a particular item is registered as
864 a particular OBJECT IDENTIFIER value, and associated with a
865 particular descriptor. After such a registration, the semantics
866 thereby associated with the value are not allowed to change, the
867 OBJECT IDENTIFIER can not be used for any other registration, and
868 the descriptor can not be changed nor associated with any other
869 registration. The following macros result in a registration:
871 OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE, OBJECT-GROUP,
872 OBJECT-IDENTITY, NOTIFICATION-GROUP, MODULE-COMPLIANCE,
875 (2) assignment: a descriptor can be assigned to a particular OBJECT
876 IDENTIFIER value. For this usage, the semantics associated with
877 the OBJECT IDENTIFIER value is not allowed to change, and a
878 descriptor assigned to a particular OBJECT IDENTIFIER value cannot
879 subsequently be assigned to another. However, multiple descriptors
880 can be assigned to the same OBJECT IDENTIFIER value. Such
881 assignments are specified in the following manner:
884 McCloghrie, et al. Standards Track [Page 15]
890 RFC 2578 SMIv2 April 1999
893 mib OBJECT IDENTIFIER ::= { mgmt 1 } -- from RFC1156
894 mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } -- from RFC1213
895 fredRouter OBJECT IDENTIFIER ::= { flintStones 1 1 }
896 barneySwitch OBJECT IDENTIFIER ::= { flintStones bedrock(2) 1 }
898 Note while the above examples are legal, the following is not:
900 dinoHost OBJECT IDENTIFIER ::= { flintStones bedrock 2 }
902 A descriptor is allowed to be associated with both a registration and
903 an assignment, providing both are associated with the same OBJECT
904 IDENTIFIER value and semantics.
906 3.7. Reserved Keywords
908 The following are reserved keywords which must not be used as
909 descriptors or module names:
911 ABSENT ACCESS AGENT-CAPABILITIES ANY APPLICATION AUGMENTS BEGIN
912 BIT BITS BOOLEAN BY CHOICE COMPONENT COMPONENTS CONTACT-INFO
913 CREATION-REQUIRES Counter32 Counter64 DEFAULT DEFINED
914 DEFINITIONS DEFVAL DESCRIPTION DISPLAY-HINT END ENUMERATED
915 ENTERPRISE EXPLICIT EXPORTS EXTERNAL FALSE FROM GROUP Gauge32
916 IDENTIFIER IMPLICIT IMPLIED IMPORTS INCLUDES INDEX INTEGER
917 Integer32 IpAddress LAST-UPDATED MANDATORY-GROUPS MAX MAX-ACCESS
918 MIN MIN-ACCESS MINUS-INFINITY MODULE MODULE-COMPLIANCE MODULE-
919 IDENTITY NOTIFICATION-GROUP NOTIFICATION-TYPE NOTIFICATIONS NULL
920 OBJECT OBJECT-GROUP OBJECT-IDENTITY OBJECT-TYPE OBJECTS OCTET OF
921 OPTIONAL ORGANIZATION Opaque PLUS-INFINITY PRESENT PRIVATE
922 PRODUCT-RELEASE REAL REFERENCE REVISION SEQUENCE SET SIZE STATUS
923 STRING SUPPORTS SYNTAX TAGS TEXTUAL-CONVENTION TRAP-TYPE TRUE
924 TimeTicks UNITS UNIVERSAL Unsigned32 VARIABLES VARIATION WITH
929 The root of the subtree administered by the Internet Assigned Numbers
930 Authority (IANA) for the Internet is:
932 internet OBJECT IDENTIFIER ::= { iso 3 6 1 }
934 That is, the Internet subtree of OBJECT IDENTIFIERs starts with the
939 Several branches underneath this subtree are used for network
943 McCloghrie, et al. Standards Track [Page 16]
949 RFC 2578 SMIv2 April 1999
952 mgmt OBJECT IDENTIFIER ::= { internet 2 }
953 experimental OBJECT IDENTIFIER ::= { internet 3 }
954 private OBJECT IDENTIFIER ::= { internet 4 }
955 enterprises OBJECT IDENTIFIER ::= { private 1 }
957 However, the SMI does not prohibit the definition of objects in other
958 portions of the object tree.
960 The mgmt(2) subtree is used to identify "standard" objects.
962 The experimental(3) subtree is used to identify objects being
963 designed by working groups of the IETF. If an information module
964 produced by a working group becomes a "standard" information module,
965 then at the very beginning of its entry onto the Internet standards
966 track, the objects are moved under the mgmt(2) subtree.
968 The private(4) subtree is used to identify objects defined
969 unilaterally. The enterprises(1) subtree beneath private is used,
970 among other things, to permit providers of networking subsystems to
971 register models of their products.
973 5. Mapping of the MODULE-IDENTITY macro
975 The MODULE-IDENTITY macro is used to provide contact and revision
976 history for each information module. It must appear exactly once in
977 every information module. It should be noted that the expansion of
978 the MODULE-IDENTITY macro is something which conceptually happens
979 during implementation and not during run-time.
981 Note that reference in an IMPORTS clause or in clauses of SMIv2
982 macros to an information module is NOT through the use of the
983 'descriptor' of a MODULE-IDENTITY macro; rather, an information
984 module is referenced through specifying its module name.
986 5.1. Mapping of the LAST-UPDATED clause
988 The LAST-UPDATED clause, which must be present, contains the date and
989 time that this information module was last edited.
991 5.2. Mapping of the ORGANIZATION clause
993 The ORGANIZATION clause, which must be present, contains a textual
994 description of the organization under whose auspices this information
995 module was developed.
1002 McCloghrie, et al. Standards Track [Page 17]
1008 RFC 2578 SMIv2 April 1999
1011 5.3. Mapping of the CONTACT-INFO clause
1013 The CONTACT-INFO clause, which must be present, contains the name,
1014 postal address, telephone number, and electronic mail address of the
1015 person to whom technical queries concerning this information module
1018 5.4. Mapping of the DESCRIPTION clause
1020 The DESCRIPTION clause, which must be present, contains a high-level
1021 textual description of the contents of this information module.
1023 5.5. Mapping of the REVISION clause
1025 The REVISION clause, which need not be present, is repeatedly used to
1026 describe the revisions (including the initial version) made to this
1027 information module, in reverse chronological order (i.e., most recent
1028 first). Each instance of this clause contains the date and time of
1031 5.5.1. Mapping of the DESCRIPTION sub-clause
1033 The DESCRIPTION sub-clause, which must be present for each REVISION
1034 clause, contains a high-level textual description of the revision
1035 identified in that REVISION clause.
1037 5.6. Mapping of the MODULE-IDENTITY value
1039 The value of an invocation of the MODULE-IDENTITY macro is an OBJECT
1040 IDENTIFIER. As such, this value may be authoritatively used when
1041 specifying an OBJECT IDENTIFIER value to refer to the information
1042 module containing the invocation.
1044 Note that it is a common practice to use the value of the MODULE-
1045 IDENTITY macro as a subtree under which other OBJECT IDENTIFIER
1046 values assigned within the module are defined. However, it is legal
1047 (and occasionally necessary) for the other OBJECT IDENTIFIER values
1048 assigned within the module to be unrelated to the OBJECT IDENTIFIER
1049 value of the MODULE-IDENTITY macro.
1053 Consider how a skeletal MIB module might be constructed: e.g.,
1055 FIZBIN-MIB DEFINITIONS ::= BEGIN
1058 MODULE-IDENTITY, OBJECT-TYPE, experimental
1061 McCloghrie, et al. Standards Track [Page 18]
1067 RFC 2578 SMIv2 April 1999
1073 fizbin MODULE-IDENTITY
1074 LAST-UPDATED "199505241811Z"
1075 ORGANIZATION "IETF SNMPv2 Working Group"
1079 Postal: Dover Beach Consulting, Inc.
1081 Mountain View, CA 94043-2186
1084 Tel: +1 415 968 1052
1085 Fax: +1 415 968 2510
1087 E-mail: mrose@dbc.mtview.ca.us"
1090 "The MIB module for entities implementing the xxxx
1092 REVISION "9505241811Z"
1094 "The latest version of this MIB module."
1095 REVISION "9210070433Z"
1097 "The initial version of this MIB module, published in
1099 -- contact IANA for actual number
1100 ::= { experimental xx }
1104 6. Mapping of the OBJECT-IDENTITY macro
1106 The OBJECT-IDENTITY macro is used to define information about an
1107 OBJECT IDENTIFIER assignment. All administrative OBJECT IDENTIFIER
1108 assignments which define a type identification value (see
1109 AutonomousType, a textual convention defined in [3]) should be
1110 defined via the OBJECT-IDENTITY macro. It should be noted that the
1111 expansion of the OBJECT-IDENTITY macro is something which
1112 conceptually happens during implementation and not during run-time.
1114 6.1. Mapping of the STATUS clause
1116 The STATUS clause, which must be present, indicates whether this
1117 definition is current or historic.
1120 McCloghrie, et al. Standards Track [Page 19]
1126 RFC 2578 SMIv2 April 1999
1129 The value "current" means that the definition is current and valid.
1130 The value "obsolete" means the definition is obsolete and should not
1131 be implemented and/or can be removed if previously implemented.
1132 While the value "deprecated" also indicates an obsolete definition,
1133 it permits new/continued implementation in order to foster
1134 interoperability with older/existing implementations.
1136 6.2. Mapping of the DESCRIPTION clause
1138 The DESCRIPTION clause, which must be present, contains a textual
1139 description of the object assignment.
1141 6.3. Mapping of the REFERENCE clause
1143 The REFERENCE clause, which need not be present, contains a textual
1144 cross-reference to some other document, either another information
1145 module which defines a related assignment, or some other document
1146 which provides additional information relevant to this definition.
1148 6.4. Mapping of the OBJECT-IDENTITY value
1150 The value of an invocation of the OBJECT-IDENTITY macro is an OBJECT
1155 Consider how an OBJECT IDENTIFIER assignment might be made: e.g.,
1157 fizbin69 OBJECT-IDENTITY
1160 "The authoritative identity of the Fizbin 69 chipset."
1161 ::= { fizbinChipSets 1 }
1163 7. Mapping of the OBJECT-TYPE macro
1165 The OBJECT-TYPE macro is used to define a type of managed object. It
1166 should be noted that the expansion of the OBJECT-TYPE macro is
1167 something which conceptually happens during implementation and not
1170 For leaf objects which are not columnar objects (i.e., not contained
1171 within a conceptual table), instances of the object are identified by
1172 appending a sub-identifier of zero to the name of that object.
1173 Otherwise, the INDEX clause of the conceptual row object superior to
1174 a columnar object defines instance identification information.
1179 McCloghrie, et al. Standards Track [Page 20]
1185 RFC 2578 SMIv2 April 1999
1188 7.1. Mapping of the SYNTAX clause
1190 The SYNTAX clause, which must be present, defines the abstract data
1191 structure corresponding to that object. The data structure must be
1192 one of the following: a base type, the BITS construct, or a textual
1193 convention. (SEQUENCE OF and SEQUENCE are also possible for
1194 conceptual tables, see section 7.1.12). The base types are those
1195 defined in the ObjectSyntax CHOICE. A textual convention is a
1196 newly-defined type defined as a sub-type of a base type [3].
1198 An extended subset of the full capabilities of ASN.1 (1988) sub-
1199 typing is allowed, as appropriate to the underlying ASN.1 type. Any
1200 such restriction on size, range or enumerations specified in this
1201 clause represents the maximal level of support which makes "protocol
1202 sense". Restrictions on sub-typing are specified in detail in
1203 Section 9 and Appendix A of this memo.
1205 The semantics of ObjectSyntax are now described.
1207 7.1.1. Integer32 and INTEGER
1209 The Integer32 type represents integer-valued information between
1210 -2^31 and 2^31-1 inclusive (-2147483648 to 2147483647 decimal). This
1211 type is indistinguishable from the INTEGER type. Both the INTEGER
1212 and Integer32 types may be sub-typed to be more constrained than the
1215 The INTEGER type (but not the Integer32 type) may also be used to
1216 represent integer-valued information as named-number enumerations.
1217 In this case, only those named-numbers so enumerated may be present
1218 as a value. Note that although it is recommended that enumerated
1219 values start at 1 and be numbered contiguously, any valid value for
1220 Integer32 is allowed for an enumerated value and, further, enumerated
1221 values needn't be contiguously assigned.
1223 Finally, a label for a named-number enumeration must consist of one
1224 or more letters or digits, up to a maximum of 64 characters, and the
1225 initial character must be a lower-case letter. (However, labels
1226 longer than 32 characters are not recommended.) Note that hyphens
1227 are not allowed by this specification (except for use by information
1228 modules converted from SMIv1 which did allow hyphens).
1232 The OCTET STRING type represents arbitrary binary or textual data.
1233 Although the SMI-specified size limitation for this type is 65535
1234 octets, MIB designers should realize that there may be implementation
1235 and interoperability limitations for sizes in excess of 255 octets.
1238 McCloghrie, et al. Standards Track [Page 21]
1244 RFC 2578 SMIv2 April 1999
1247 7.1.3. OBJECT IDENTIFIER
1249 The OBJECT IDENTIFIER type represents administratively assigned
1250 names. Any instance of this type may have at most 128 sub-
1251 identifiers. Further, each sub-identifier must not exceed the value
1252 2^32-1 (4294967295 decimal).
1254 7.1.4. The BITS construct
1256 The BITS construct represents an enumeration of named bits. This
1257 collection is assigned non-negative, contiguous (but see below)
1258 values, starting at zero. Only those named-bits so enumerated may be
1259 present in a value. (Thus, enumerations must be assigned to
1260 consecutive bits; however, see Section 9 for refinements of an object
1263 As part of updating an information module, for an object defined
1264 using the BITS construct, new enumerations can be added or existing
1265 enumerations can have new labels assigned to them. After an
1266 enumeration is added, it might not be possible to distinguish between
1267 an implementation of the updated object for which the new enumeration
1268 is not asserted, and an implementation of the object prior to the
1269 addition. Depending on the circumstances, such an ambiguity could
1270 either be desirable or could be undesirable. The means to avoid such
1271 an ambiguity is dependent on the encoding of values on the wire;
1272 however, one possibility is to define new enumerations starting at
1273 the next multiple of eight bits. (Of course, this can also result in
1274 the enumerations no longer being contiguous.)
1276 Although there is no SMI-specified limitation on the number of
1277 enumerations (and therefore on the length of a value), except as may
1278 be imposed by the limit on the length of an OCTET STRING, MIB
1279 designers should realize that there may be implementation and
1280 interoperability limitations for sizes in excess of 128 bits.
1282 Finally, a label for a named-number enumeration must consist of one
1283 or more letters or digits, up to a maximum of 64 characters, and the
1284 initial character must be a lower-case letter. (However, labels
1285 longer than 32 characters are not recommended.) Note that hyphens
1286 are not allowed by this specification.
1290 The IpAddress type represents a 32-bit internet address. It is
1291 represented as an OCTET STRING of length 4, in network byte-order.
1297 McCloghrie, et al. Standards Track [Page 22]
1303 RFC 2578 SMIv2 April 1999
1306 Note that the IpAddress type is a tagged type for historical reasons.
1307 Network addresses should be represented using an invocation of the
1308 TEXTUAL-CONVENTION macro [3].
1312 The Counter32 type represents a non-negative integer which
1313 monotonically increases until it reaches a maximum value of 2^32-1
1314 (4294967295 decimal), when it wraps around and starts increasing
1317 Counters have no defined "initial" value, and thus, a single value of
1318 a Counter has (in general) no information content. Discontinuities
1319 in the monotonically increasing value normally occur at re-
1320 initialization of the management system, and at other times as
1321 specified in the description of an object-type using this ASN.1 type.
1322 If such other times can occur, for example, the creation of an object
1323 instance at times other than re-initialization, then a corresponding
1324 object should be defined, with an appropriate SYNTAX clause, to
1325 indicate the last discontinuity. Examples of appropriate SYNTAX
1326 clause include: TimeStamp (a textual convention defined in [3]),
1327 DateAndTime (another textual convention from [3]) or TimeTicks.
1329 The value of the MAX-ACCESS clause for objects with a SYNTAX clause
1330 value of Counter32 is either "read-only" or "accessible-for-notify".
1332 A DEFVAL clause is not allowed for objects with a SYNTAX clause value
1337 The Gauge32 type represents a non-negative integer, which may
1338 increase or decrease, but shall never exceed a maximum value, nor
1339 fall below a minimum value. The maximum value can not be greater
1340 than 2^32-1 (4294967295 decimal), and the minimum value can not be
1341 smaller than 0. The value of a Gauge32 has its maximum value
1342 whenever the information being modeled is greater than or equal to
1343 its maximum value, and has its minimum value whenever the information
1344 being modeled is smaller than or equal to its minimum value. If the
1345 information being modeled subsequently decreases below (increases
1346 above) the maximum (minimum) value, the Gauge32 also decreases
1347 (increases). (Note that despite of the use of the term "latched" in
1348 the original definition of this type, it does not become "stuck" at
1349 its maximum or minimum value.)
1356 McCloghrie, et al. Standards Track [Page 23]
1362 RFC 2578 SMIv2 April 1999
1367 The TimeTicks type represents a non-negative integer which represents
1368 the time, modulo 2^32 (4294967296 decimal), in hundredths of a second
1369 between two epochs. When objects are defined which use this ASN.1
1370 type, the description of the object identifies both of the reference
1373 For example, [3] defines the TimeStamp textual convention which is
1374 based on the TimeTicks type. With a TimeStamp, the first reference
1375 epoch is defined as the time when sysUpTime [5] was zero, and the
1376 second reference epoch is defined as the current value of sysUpTime.
1378 The TimeTicks type may not be sub-typed.
1382 The Opaque type is provided solely for backward-compatibility, and
1383 shall not be used for newly-defined object types.
1385 The Opaque type supports the capability to pass arbitrary ASN.1
1386 syntax. A value is encoded using the ASN.1 Basic Encoding Rules [4]
1387 into a string of octets. This, in turn, is encoded as an OCTET
1388 STRING, in effect "double-wrapping" the original ASN.1 value.
1390 Note that a conforming implementation need only be able to accept and
1391 recognize opaquely-encoded data. It need not be able to unwrap the
1392 data and then interpret its contents.
1394 A requirement on "standard" MIB modules is that no object may have a
1395 SYNTAX clause value of Opaque.
1399 The Counter64 type represents a non-negative integer which
1400 monotonically increases until it reaches a maximum value of 2^64-1
1401 (18446744073709551615 decimal), when it wraps around and starts
1402 increasing again from zero.
1404 Counters have no defined "initial" value, and thus, a single value of
1405 a Counter has (in general) no information content. Discontinuities
1406 in the monotonically increasing value normally occur at re-
1407 initialization of the management system, and at other times as
1408 specified in the description of an object-type using this ASN.1 type.
1409 If such other times can occur, for example, the creation of an object
1410 instance at times other than re-initialization, then a corresponding
1411 object should be defined, with an appropriate SYNTAX clause, to
1412 indicate the last discontinuity. Examples of appropriate SYNTAX
1415 McCloghrie, et al. Standards Track [Page 24]
1421 RFC 2578 SMIv2 April 1999
1424 clause are: TimeStamp (a textual convention defined in [3]),
1425 DateAndTime (another textual convention from [3]) or TimeTicks.
1427 The value of the MAX-ACCESS clause for objects with a SYNTAX clause
1428 value of Counter64 is either "read-only" or "accessible-for-notify".
1430 A requirement on "standard" MIB modules is that the Counter64 type
1431 may be used only if the information being modeled would wrap in less
1432 than one hour if the Counter32 type was used instead.
1434 A DEFVAL clause is not allowed for objects with a SYNTAX clause value
1439 The Unsigned32 type represents integer-valued information between 0
1440 and 2^32-1 inclusive (0 to 4294967295 decimal).
1442 7.1.12. Conceptual Tables
1444 Management operations apply exclusively to scalar objects. However,
1445 it is sometimes convenient for developers of management applications
1446 to impose an imaginary, tabular structure on an ordered collection of
1447 objects within the MIB. Each such conceptual table contains zero or
1448 more rows, and each row may contain one or more scalar objects,
1449 termed columnar objects. This conceptualization is formalized by
1450 using the OBJECT-TYPE macro to define both an object which
1451 corresponds to a table and an object which corresponds to a row in
1452 that table. A conceptual table has SYNTAX of the form:
1454 SEQUENCE OF <EntryType>
1456 where <EntryType> refers to the SEQUENCE type of its subordinate
1457 conceptual row. A conceptual row has SYNTAX of the form:
1461 where <EntryType> is a SEQUENCE type defined as follows:
1463 <EntryType> ::= SEQUENCE { <type1>, ... , <typeN> }
1465 where there is one <type> for each subordinate object, and each
1466 <type> is of the form:
1468 <descriptor> <syntax>
1470 where <descriptor> is the descriptor naming a subordinate object, and
1471 <syntax> has the value of that subordinate object's SYNTAX clause,
1474 McCloghrie, et al. Standards Track [Page 25]
1480 RFC 2578 SMIv2 April 1999
1483 except that both sub-typing information and the named values for
1484 enumerated integers or the named bits for the BITS construct, are
1485 omitted from <syntax>.
1487 Further, a <type> is always present for every subordinate object.
1488 (The ASN.1 DEFAULT and OPTIONAL clauses are disallowed in the
1489 SEQUENCE definition.) The MAX-ACCESS clause for conceptual tables
1490 and rows is "not-accessible".
1492 7.1.12.1. Creation and Deletion of Conceptual Rows
1494 For newly-defined conceptual rows which allow the creation of new
1495 object instances and/or the deletion of existing object instances,
1496 there should be one columnar object with a SYNTAX clause value of
1497 RowStatus (a textual convention defined in [3]) and a MAX-ACCESS
1498 clause value of read-create. By convention, this is termed the
1499 status column for the conceptual row.
1501 7.2. Mapping of the UNITS clause
1503 This UNITS clause, which need not be present, contains a textual
1504 definition of the units associated with that object.
1506 7.3. Mapping of the MAX-ACCESS clause
1508 The MAX-ACCESS clause, which must be present, defines whether it
1509 makes "protocol sense" to read, write and/or create an instance of
1510 the object, or to include its value in a notification. This is the
1511 maximal level of access for the object. (This maximal level of
1512 access is independent of any administrative authorization policy.)
1514 The value "read-write" indicates that read and write access make
1515 "protocol sense", but create does not. The value "read-create"
1516 indicates that read, write and create access make "protocol sense".
1517 The value "not-accessible" indicates an auxiliary object (see Section
1518 7.7). The value "accessible-for-notify" indicates an object which is
1519 accessible only via a notification (e.g., snmpTrapOID [5]).
1521 These values are ordered, from least to greatest: "not-accessible",
1522 "accessible-for-notify", "read-only", "read-write", "read-create".
1524 If any columnar object in a conceptual row has "read-create" as its
1525 maximal level of access, then no other columnar object of the same
1526 conceptual row may have a maximal access of "read-write". (Note that
1527 "read-create" is a superset of "read-write".)
1533 McCloghrie, et al. Standards Track [Page 26]
1539 RFC 2578 SMIv2 April 1999
1542 7.4. Mapping of the STATUS clause
1544 The STATUS clause, which must be present, indicates whether this
1545 definition is current or historic.
1547 The value "current" means that the definition is current and valid.
1548 The value "obsolete" means the definition is obsolete and should not
1549 be implemented and/or can be removed if previously implemented.
1550 While the value "deprecated" also indicates an obsolete definition,
1551 it permits new/continued implementation in order to foster
1552 interoperability with older/existing implementations.
1554 7.5. Mapping of the DESCRIPTION clause
1556 The DESCRIPTION clause, which must be present, contains a textual
1557 definition of that object which provides all semantic definitions
1558 necessary for implementation, and should embody any information which
1559 would otherwise be communicated in any ASN.1 commentary annotations
1560 associated with the object.
1562 7.6. Mapping of the REFERENCE clause
1564 The REFERENCE clause, which need not be present, contains a textual
1565 cross-reference to some other document, either another information
1566 module which defines a related assignment, or some other document
1567 which provides additional information relevant to this definition.
1569 7.7. Mapping of the INDEX clause
1571 The INDEX clause, which must be present if that object corresponds to
1572 a conceptual row (unless an AUGMENTS clause is present instead), and
1573 must be absent otherwise, defines instance identification information
1574 for the columnar objects subordinate to that object.
1576 The instance identification information in an INDEX clause must
1577 specify object(s) such that value(s) of those object(s) will
1578 unambiguously distinguish a conceptual row. The objects can be
1579 columnar objects from the same and/or another conceptual table, but
1580 must not be scalar objects. Multiple occurrences of the same object
1581 in a single INDEX clause is strongly discouraged.
1583 The syntax of the objects in the INDEX clause indicate how to form
1584 the instance-identifier:
1586 (1) integer-valued (i.e., having INTEGER as its underlying primitive
1587 type): a single sub-identifier taking the integer value (this
1588 works only for non-negative integers);
1592 McCloghrie, et al. Standards Track [Page 27]
1598 RFC 2578 SMIv2 April 1999
1601 (2) string-valued, fixed-length strings (or variable-length preceded by
1602 the IMPLIED keyword): `n' sub-identifiers, where `n' is the length
1603 of the string (each octet of the string is encoded in a separate
1606 (3) string-valued, variable-length strings (not preceded by the IMPLIED
1607 keyword): `n+1' sub-identifiers, where `n' is the length of the
1608 string (the first sub-identifier is `n' itself, following this,
1609 each octet of the string is encoded in a separate sub-identifier);
1611 (4) object identifier-valued (when preceded by the IMPLIED keyword):
1612 `n' sub-identifiers, where `n' is the number of sub-identifiers in
1613 the value (each sub-identifier of the value is copied into a
1614 separate sub-identifier);
1616 (5) object identifier-valued (when not preceded by the IMPLIED
1617 keyword): `n+1' sub-identifiers, where `n' is the number of sub-
1618 identifiers in the value (the first sub-identifier is `n' itself,
1619 following this, each sub-identifier in the value is copied);
1621 (6) IpAddress-valued: 4 sub-identifiers, in the familiar a.b.c.d
1624 Note that the IMPLIED keyword can only be present for an object
1625 having a variable-length syntax (e.g., variable-length strings or
1626 object identifier-valued objects), Further, the IMPLIED keyword can
1627 only be associated with the last object in the INDEX clause.
1628 Finally, the IMPLIED keyword may not be used on a variable-length
1629 string object if that string might have a value of zero-length.
1631 Since a single value of a Counter has (in general) no information
1632 content (see section 7.1.6 and 7.1.10), objects defined using the
1633 syntax, Counter32 or Counter64, must not be specified in an INDEX
1635 clause. If an object defined using the BITS construct is used in an
1636 INDEX clause, it is considered a variable-length string.
1638 Instances identified by use of integer-valued objects should be
1639 numbered starting from one (i.e., not from zero). The use of zero as
1640 a value for an integer-valued index object should be avoided, except
1643 Objects which are both specified in the INDEX clause of a conceptual
1644 row and also columnar objects of the same conceptual row are termed
1645 auxiliary objects. The MAX-ACCESS clause for auxiliary objects is
1646 "not-accessible", except in the following circumstances:
1651 McCloghrie, et al. Standards Track [Page 28]
1657 RFC 2578 SMIv2 April 1999
1660 (1) within a MIB module originally written to conform to SMIv1, and
1661 later converted to conform to SMIv2; or
1663 (2) a conceptual row must contain at least one columnar object which is
1664 not an auxiliary object. In the event that all of a conceptual
1665 row's columnar objects are also specified in its INDEX clause, then
1666 one of them must be accessible, i.e., have a MAX-ACCESS clause of
1667 "read-only". (Note that this situation does not arise for a
1668 conceptual row allowing create access, since such a row will have a
1669 status column which will not be an auxiliary object.)
1671 Note that objects specified in a conceptual row's INDEX clause need
1672 not be columnar objects of that conceptual row. In this situation,
1673 the DESCRIPTION clause of the conceptual row must include a textual
1674 explanation of how the objects which are included in the INDEX clause
1675 but not columnar objects of that conceptual row, are used in uniquely
1676 identifying instances of the conceptual row's columnar objects.
1678 7.8. Mapping of the AUGMENTS clause
1680 The AUGMENTS clause, which must not be present unless the object
1681 corresponds to a conceptual row, is an alternative to the INDEX
1682 clause. Every object corresponding to a conceptual row has either an
1683 INDEX clause or an AUGMENTS clause.
1685 If an object corresponding to a conceptual row has an INDEX clause,
1686 that row is termed a base conceptual row; alternatively, if the
1687 object has an AUGMENTS clause, the row is said to be a conceptual row
1688 augmentation, where the AUGMENTS clause names the object
1689 corresponding to the base conceptual row which is augmented by this
1690 conceptual row augmentation. (Thus, a conceptual row augmentation
1691 cannot itself be augmented.) Instances of subordinate columnar
1692 objects of a conceptual row augmentation are identified according to
1693 the INDEX clause of the base conceptual row corresponding to the
1694 object named in the AUGMENTS clause. Further, instances of
1695 subordinate columnar objects of a conceptual row augmentation exist
1696 according to the same semantics as instances of subordinate columnar
1697 objects of the base conceptual row being augmented. As such, note
1698 that creation of a base conceptual row implies the correspondent
1699 creation of any conceptual row augmentations.
1701 For example, a MIB designer might wish to define additional columns
1702 in an "enterprise-specific" MIB which logically extend a conceptual
1703 row in a "standard" MIB. The "standard" MIB definition of the
1704 conceptual row would include the INDEX clause and the "enterprise-
1705 specific" MIB would contain the definition of a conceptual row using
1706 the AUGMENTS clause. On the other hand, it would be incorrect to use
1707 the AUGMENTS clause for the relationship between RFC 2233's ifTable
1710 McCloghrie, et al. Standards Track [Page 29]
1716 RFC 2578 SMIv2 April 1999
1719 and the many media-specific MIBs which extend it for specific media
1720 (e.g., the dot3Table in RFC 2358), since not all interfaces are of
1723 Note that a base conceptual row may be augmented by multiple
1724 conceptual row augmentations.
1726 7.8.1. Relation between INDEX and AUGMENTS clauses
1728 When defining instance identification information for a conceptual
1731 (1) If there is a one-to-one correspondence between the conceptual rows
1732 of this table and an existing table, then the AUGMENTS clause
1735 (2) Otherwise, if there is a sparse relationship between the conceptual
1736 rows of this table and an existing table, then an INDEX clause
1737 should be used which is identical to that in the existing table.
1738 For example, the relationship between RFC 2233's ifTable and a
1739 media-specific MIB which extends the ifTable for a specific media
1740 (e.g., the dot3Table in RFC 2358), is a sparse relationship.
1742 (3) Otherwise, if no existing objects have the required syntax and
1743 semantics, then auxiliary objects should be defined within the
1744 conceptual row for the new table, and those objects should be used
1745 within the INDEX clause for the conceptual row.
1747 7.9. Mapping of the DEFVAL clause
1749 The DEFVAL clause, which need not be present, defines an acceptable
1750 default value which may be used at the discretion of an agent when an
1751 object instance is created. That is, the value is a "hint" to
1754 During conceptual row creation, if an instance of a columnar object
1755 is not present as one of the operands in the correspondent management
1756 protocol set operation, then the value of the DEFVAL clause, if
1757 present, indicates an acceptable default value that an agent might
1758 use (especially for a read-only object).
1760 Note that with this definition of the DEFVAL clause, it is
1761 appropriate to use it for any columnar object of a read-create table.
1762 It is also permitted to use it for scalar objects dynamically created
1763 by an agent, or for columnar objects of a read-write table
1764 dynamically created by an agent.
1769 McCloghrie, et al. Standards Track [Page 30]
1775 RFC 2578 SMIv2 April 1999
1778 The value of the DEFVAL clause must, of course, correspond to the
1779 SYNTAX clause for the object. If the value is an OBJECT IDENTIFIER,
1780 then it must be expressed as a single ASN.1 identifier, and not as a
1781 collection of sub-identifiers.
1783 Note that if an operand to the management protocol set operation is
1784 an instance of a read-only object, then the error `notWritable' [6]
1785 will be returned. As such, the DEFVAL clause can be used to provide
1786 an acceptable default value that an agent might use.
1788 By way of example, consider the following possible DEFVAL clauses:
1790 ObjectSyntax DEFVAL clause
1791 ---------------- ------------
1792 Integer32 DEFVAL { 1 }
1793 -- same for Gauge32, TimeTicks, Unsigned32
1794 INTEGER DEFVAL { valid } -- enumerated value
1795 OCTET STRING DEFVAL { 'ffffffffffff'H }
1796 DisplayString DEFVAL { "SNMP agent" }
1797 IpAddress DEFVAL { 'c0210415'H } -- 192.33.4.21
1798 OBJECT IDENTIFIER DEFVAL { sysDescr }
1799 BITS DEFVAL { { primary, secondary } }
1800 -- enumerated values that are set
1802 -- no enumerated values are set
1804 A binary string used in a DEFVAL clause for an OCTET STRING must be
1805 either an integral multiple of eight or zero bits in length;
1806 similarly, a hexadecimal string must be an even number of hexadecimal
1807 digits. The value of a character string used in a DEFVAL clause must
1808 not contain tab characters or line terminator characters.
1810 Object types with SYNTAX of Counter32 and Counter64 may not have
1811 DEFVAL clauses, since they do not have defined initial values.
1812 However, it is recommended that they be initialized to zero.
1814 7.10. Mapping of the OBJECT-TYPE value
1816 The value of an invocation of the OBJECT-TYPE macro is the name of
1817 the object, which is an OBJECT IDENTIFIER, an administratively
1820 When an OBJECT IDENTIFIER is assigned to an object:
1822 (1) If the object corresponds to a conceptual table, then only a single
1823 assignment, that for a conceptual row, is present immediately
1824 beneath that object. The administratively assigned name for the
1825 conceptual row object is derived by appending a sub-identifier of
1828 McCloghrie, et al. Standards Track [Page 31]
1834 RFC 2578 SMIv2 April 1999
1837 "1" to the administratively assigned name for the conceptual table.
1839 (2) If the object corresponds to a conceptual row, then at least one
1840 assignment, one for each column in the conceptual row, is present
1841 beneath that object. The administratively assigned name for each
1842 column is derived by appending a unique, positive sub-identifier to
1843 the administratively assigned name for the conceptual row.
1845 (3) Otherwise, no other OBJECT IDENTIFIERs which are subordinate to the
1846 object may be assigned.
1848 Note that the final sub-identifier of any administratively assigned
1849 name for an object shall be positive. A zero-valued final sub-
1850 identifier is reserved for future use.
1854 Consider how one might define a conceptual table and its
1855 subordinates. (This example uses the RowStatus textual convention
1858 evalSlot OBJECT-TYPE
1859 SYNTAX Integer32 (0..2147483647)
1860 MAX-ACCESS read-only
1863 "The index number of the first unassigned entry in the
1864 evaluation table, or the value of zero indicating that
1865 all entries are assigned.
1867 A management station should create new entries in the
1868 evaluation table using this algorithm: first, issue a
1869 management protocol retrieval operation to determine the
1870 value of evalSlot; and, second, issue a management
1871 protocol set operation to create an instance of the
1872 evalStatus object setting its value to createAndGo(4) or
1873 createAndWait(5). If this latter operation succeeds,
1874 then the management station may continue modifying the
1875 instances corresponding to the newly created conceptual
1876 row, without fear of collision with other management
1880 evalTable OBJECT-TYPE
1881 SYNTAX SEQUENCE OF EvalEntry
1882 MAX-ACCESS not-accessible
1887 McCloghrie, et al. Standards Track [Page 32]
1893 RFC 2578 SMIv2 April 1999
1896 "The (conceptual) evaluation table."
1899 evalEntry OBJECT-TYPE
1901 MAX-ACCESS not-accessible
1904 "An entry (conceptual row) in the evaluation table."
1910 evalIndex Integer32,
1911 evalString DisplayString,
1912 evalValue Integer32,
1913 evalStatus RowStatus
1916 evalIndex OBJECT-TYPE
1917 SYNTAX Integer32 (1..2147483647)
1918 MAX-ACCESS not-accessible
1921 "The auxiliary variable used for identifying instances of
1922 the columnar objects in the evaluation table."
1925 evalString OBJECT-TYPE
1926 SYNTAX DisplayString
1927 MAX-ACCESS read-create
1930 "The string to evaluate."
1933 evalValue OBJECT-TYPE
1935 MAX-ACCESS read-only
1938 "The value when evalString was last evaluated, or zero if
1939 no such value is available."
1943 evalStatus OBJECT-TYPE
1946 McCloghrie, et al. Standards Track [Page 33]
1952 RFC 2578 SMIv2 April 1999
1956 MAX-ACCESS read-create
1959 "The status column used for creating, modifying, and
1960 deleting instances of the columnar objects in the
1965 8. Mapping of the NOTIFICATION-TYPE macro
1967 The NOTIFICATION-TYPE macro is used to define the information
1968 contained within an unsolicited transmission of management
1969 information (i.e., within either a SNMPv2-Trap-PDU or InformRequest-
1970 PDU). It should be noted that the expansion of the NOTIFICATION-TYPE
1971 macro is something which conceptually happens during implementation
1972 and not during run-time.
1974 8.1. Mapping of the OBJECTS clause
1976 The OBJECTS clause, which need not be present, defines an ordered
1977 sequence of MIB object types. One and only one object instance for
1978 each occurrence of each object type must be present, and in the
1979 specified order, in every instance of the notification. If the same
1980 object type occurs multiple times in a notification's ordered
1981 sequence, then an object instance is present for each of them. An
1982 object type specified in this clause must not have an MAX-ACCESS
1983 clause of "not-accessible". The notification's DESCRIPTION clause
1984 must specify the information/meaning conveyed by each occurrence of
1985 each object type in the sequence. The DESCRIPTION clause must also
1986 specify which object instance is present for each object type in the
1989 Note that an agent is allowed, at its own discretion, to append as
1990 many additional objects as it considers useful to the end of the
1991 notification (i.e., after the objects defined by the OBJECTS clause).
1993 8.2. Mapping of the STATUS clause
1995 The STATUS clause, which must be present, indicates whether this
1996 definition is current or historic.
1998 The value "current" means that the definition is current and valid.
1999 The value "obsolete" means the definition is obsolete and should not
2000 be implemented and/or can be removed if previously implemented.
2001 While the value "deprecated" also indicates an obsolete definition,
2002 it permits new/continued implementation in order to foster
2005 McCloghrie, et al. Standards Track [Page 34]
2011 RFC 2578 SMIv2 April 1999
2014 interoperability with older/existing implementations.
2016 8.3. Mapping of the DESCRIPTION clause
2018 The DESCRIPTION clause, which must be present, contains a textual
2019 definition of the notification which provides all semantic
2020 definitions necessary for implementation, and should embody any
2021 information which would otherwise be communicated in any ASN.1
2022 commentary annotations associated with the notification. In
2023 particular, the DESCRIPTION clause should document which instances of
2024 the objects mentioned in the OBJECTS clause should be contained
2025 within notifications of this type.
2027 8.4. Mapping of the REFERENCE clause
2029 The REFERENCE clause, which need not be present, contains a textual
2030 cross-reference to some other document, either another information
2031 module which defines a related assignment, or some other document
2032 which provides additional information relevant to this definition.
2034 8.5. Mapping of the NOTIFICATION-TYPE value
2036 The value of an invocation of the NOTIFICATION-TYPE macro is the name
2037 of the notification, which is an OBJECT IDENTIFIER, an
2038 administratively assigned name. In order to achieve compatibility
2039 with SNMPv1 traps, both when converting SMIv1 information modules
2040 to/from this SMI, and in the procedures employed by multi-lingual
2041 systems and proxy forwarding applications, the next to last sub-
2042 identifier in the name of any newly-defined notification must have
2045 Sections 4.2.6 and 4.2.7 of [6] describe how the NOTIFICATION-TYPE
2046 macro is used to generate a SNMPv2-Trap-PDU or InformRequest-PDU,
2051 Consider how a configuration change notification might be described:
2053 entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 }
2054 entityMIBTrapPrefix OBJECT IDENTIFIER ::= { entityMIBTraps 0 }
2056 entConfigChange NOTIFICATION-TYPE
2059 "An entConfigChange trap is sent when the value of
2060 entLastChangeTime changes. It can be utilized by an NMS to
2061 trigger logical/physical entity table maintenance polls.
2064 McCloghrie, et al. Standards Track [Page 35]
2070 RFC 2578 SMIv2 April 1999
2074 An agent must not generate more than one entConfigChange
2075 'trap-event' in a five second period, where a 'trap-event'
2076 is the transmission of a single trap PDU to a list of
2077 trap destinations. If additional configuration changes
2078 occur within the five second 'throttling' period, then
2079 these trap-events should be suppressed by the agent. An
2080 NMS should periodically check the value of
2081 entLastChangeTime to detect any missed entConfigChange
2082 trap-events, e.g. due to throttling or transmission loss."
2083 ::= { entityMIBTrapPrefix 1 }
2085 According to this invocation, the notification authoritatively
2088 { entityMIBTrapPrefix 1 }
2090 is used to report a particular type of configuration change.
2094 Some macros have clauses which allows syntax to be refined,
2095 specifically: the SYNTAX clause of the OBJECT-TYPE macro, and the
2096 SYNTAX/WRITE-SYNTAX clauses of the MODULE-COMPLIANCE and AGENT-
2097 CAPABILITIES macros [2]. However, not all refinements of syntax are
2098 appropriate. In particular, the object's primitive or application
2099 type must not be changed.
2101 Further, the following restrictions apply:
2103 Restrictions to Refinement of
2104 object syntax range enumeration size
2105 ----------------- ----- ----------- ----
2109 OCTET STRING - - (3)
2110 OBJECT IDENTIFIER - - -
2123 McCloghrie, et al. Standards Track [Page 36]
2129 RFC 2578 SMIv2 April 1999
2132 (1) the range of permitted values may be refined by raising the lower-
2133 bounds, by reducing the upper-bounds, and/or by reducing the
2134 alternative value/range choices;
2136 (2) the enumeration of named-values may be refined by removing one or
2137 more named-values (note that for BITS, a refinement may cause the
2138 enumerations to no longer be contiguous); or,
2140 (3) the size in octets of the value may be refined by raising the
2141 lower-bounds, by reducing the upper-bounds, and/or by reducing the
2142 alternative size choices.
2144 No other types of refinements can be specified in the SYNTAX clause.
2145 However, the DESCRIPTION clause is available to specify additional
2146 restrictions which can not be expressed in the SYNTAX clause.
2147 Further details on (and examples of) sub-typing are provided in
2150 10. Extending an Information Module
2152 As experience is gained with an information module, it may be
2153 desirable to revise that information module. However, changes are
2154 not allowed if they have any potential to cause interoperability
2155 problems "over the wire" between an implementation using an original
2156 specification and an implementation using an updated
2159 For any change, the invocation of the MODULE-IDENTITY macro must be
2160 updated to include information about the revision: specifically,
2161 updating the LAST-UPDATED clause, adding a pair of REVISION and
2162 DESCRIPTION clauses (see section 5.5), and making any necessary
2163 changes to existing clauses, including the ORGANIZATION and CONTACT-
2166 Note that any definition contained in an information module is
2167 available to be IMPORT-ed by any other information module, and is
2168 referenced in an IMPORTS clause via the module name. Thus, a module
2169 name should not be changed. Specifically, the module name (e.g.,
2170 "FIZBIN-MIB" in the example of Section 5.7) should not be changed
2171 when revising an information module (except to correct typographical
2172 errors), and definitions should not be moved from one information
2175 Also note that obsolete definitions must not be removed from MIB
2176 modules since their descriptors may still be referenced by other
2177 information modules, and the OBJECT IDENTIFIERs used to name them
2178 must never be re-assigned.
2182 McCloghrie, et al. Standards Track [Page 37]
2188 RFC 2578 SMIv2 April 1999
2191 10.1. Object Assignments
2193 If any non-editorial change is made to any clause of a object
2194 assignment, then the OBJECT IDENTIFIER value associated with that
2195 object assignment must also be changed, along with its associated
2198 10.2. Object Definitions
2200 An object definition may be revised in any of the following ways:
2202 (1) A SYNTAX clause containing an enumerated INTEGER may have new
2203 enumerations added or existing labels changed. Similarly, named
2204 bits may be added or existing labels changed for the BITS
2207 (2) The value of a SYNTAX clause may be replaced by a textual
2208 convention, providing the textual convention is defined to use the
2209 same primitive ASN.1 type, has the same set of values, and has
2210 identical semantics.
2212 (3) A STATUS clause value of "current" may be revised as "deprecated"
2213 or "obsolete". Similarly, a STATUS clause value of "deprecated"
2214 may be revised as "obsolete". When making such a change, the
2215 DESCRIPTION clause should be updated to explain the rationale.
2217 (4) A DEFVAL clause may be added or updated.
2219 (5) A REFERENCE clause may be added or updated.
2221 (6) A UNITS clause may be added.
2223 (7) A conceptual row may be augmented by adding new columnar objects at
2224 the end of the row, and making the corresponding update to the
2225 SEQUENCE definition.
2227 (8) Clarifications and additional information may be included in the
2230 (9) Entirely new objects may be defined, named with previously
2231 unassigned OBJECT IDENTIFIER values.
2233 Otherwise, if the semantics of any previously defined object are
2234 changed (i.e., if a non-editorial change is made to any clause other
2235 than those specifically allowed above), then the OBJECT IDENTIFIER
2236 value associated with that object must also be changed.
2241 McCloghrie, et al. Standards Track [Page 38]
2247 RFC 2578 SMIv2 April 1999
2250 Note that changing the descriptor associated with an existing object
2251 is considered a semantic change, as these strings may be used in an
2254 10.3. Notification Definitions
2256 A notification definition may be revised in any of the following
2259 (1) A REFERENCE clause may be added or updated.
2261 (2) A STATUS clause value of "current" may be revised as "deprecated"
2262 or "obsolete". Similarly, a STATUS clause value of "deprecated"
2263 may be revised as "obsolete". When making such a change, the
2264 DESCRIPTION clause should be updated to explain the rationale.
2266 (3) A DESCRIPTION clause may be clarified.
2268 Otherwise, if the semantics of any previously defined notification
2269 are changed (i.e., if a non-editorial change is made to any clause
2270 other those specifically allowed above), then the OBJECT IDENTIFIER
2271 value associated with that notification must also be changed.
2273 Note that changing the descriptor associated with an existing
2274 notification is considered a semantic change, as these strings may be
2275 used in an IMPORTS statement.
2300 McCloghrie, et al. Standards Track [Page 39]
2306 RFC 2578 SMIv2 April 1999
2309 11. Appendix A: Detailed Sub-typing Rules
2314 The syntax rules for sub-typing are given below. Note that while
2315 this syntax is based on ASN.1, it includes some extensions beyond
2316 what is allowed in ASN.1, and a number of ASN.1 constructs are not
2317 allowed by this syntax.
2321 | "(" <range> ["|" <range>]... ")"
2323 <octetStringSubType>
2325 | "(" "SIZE" "(" <range> ["|" <range>]... ")" ")"
2329 | <value> ".." <value>
2338 <empty> is the empty string
2339 <number> is a non-negative integer
2340 <hexString> is a hexadecimal string (e.g., '0F0F'H)
2341 <binString> is a binary string (e.g, '1010'B)
2343 <range> is further restricted as follows:
2344 - any <value> used in a SIZE clause must be non-negative.
2345 - when a pair of values is specified, the first value
2346 must be less than the second value.
2347 - when multiple ranges are specified, the ranges may
2348 not overlap but may touch. For example, (1..4 | 4..9)
2349 is invalid, and (1..4 | 5..9) is valid.
2350 - the ranges must be a subset of the maximum range of the
2359 McCloghrie, et al. Standards Track [Page 40]
2365 RFC 2578 SMIv2 April 1999
2370 Some examples of legal sub-typing:
2372 Integer32 (-20..100)
2373 Integer32 (0..100 | 300..500)
2374 Integer32 (300..500 | 0..100)
2375 Integer32 (0 | 2 | 4 | 6 | 8 | 10)
2376 OCTET STRING (SIZE(0..100))
2377 OCTET STRING (SIZE(0..100 | 300..500))
2378 OCTET STRING (SIZE(0 | 2 | 4 | 6 | 8 | 10))
2379 SYNTAX TimeInterval (0..100)
2380 SYNTAX DisplayString (SIZE(0..32))
2382 (Note the last two examples above are not valid in a TEXTUAL
2383 CONVENTION, see [3].)
2385 Some examples of illegal sub-typing:
2387 Integer32 (150..100) -- first greater than second
2388 Integer32 (0..100 | 50..500) -- ranges overlap
2389 Integer32 (0 | 2 | 0 ) -- value duplicated
2390 Integer32 (MIN..-1 | 1..MAX) -- MIN and MAX not allowed
2391 Integer32 (SIZE (0..34)) -- must not use SIZE
2392 OCTET STRING (0..100) -- must use SIZE
2393 OCTET STRING (SIZE(-10..100)) -- negative SIZE
2395 12. Security Considerations
2397 This document defines a language with which to write and read
2398 descriptions of management information. The language itself has no
2399 security impact on the Internet.
2403 13. Editors' Addresses
2407 170 West Tasman Drive
2408 San Jose, CA 95134-1706
2410 Phone: +1 408 526 5260
2411 EMail: kzm@cisco.com
2418 McCloghrie, et al. Standards Track [Page 41]
2424 RFC 2578 SMIv2 April 1999
2430 Santa Clara, CA 95051
2432 Phone: +1 408 221-8702
2433 EMail: dperkins@snmpinfo.com
2435 Juergen Schoenwaelder
2440 Phone: +49 531 391-3283
2441 EMail: schoenw@ibr.cs.tu-bs.de
2446 [1] Information processing systems - Open Systems Interconnection -
2447 Specification of Abstract Syntax Notation One (ASN.1),
2448 International Organization for Standardization. International
2449 Standard 8824, (December, 1987).
2451 [2] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.
2452 and S. Waldbusser, "Conformance Statements for SMIv2", STD 58,
2453 RFC 2580, April 1999.
2455 [3] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M.
2456 and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
2457 RFC 2579, April 1999.
2459 [4] Information processing systems - Open Systems Interconnection -
2460 Specification of Basic Encoding Rules for Abstract Syntax Notation
2461 One (ASN.1), International Organization for Standardization.
2462 International Standard 8825, (December, 1987).
2464 [5] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and
2465 S. Waldbusser, "Management Information Base for Version 2 of the
2466 Simple Network Management Protocol (SNMPv2)", RFC 1907, January
2469 [6] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and
2470 S. Waldbusser, "Protocol Operations for Version 2 of the Simple
2471 Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
2477 McCloghrie, et al. Standards Track [Page 42]
2483 RFC 2578 SMIv2 April 1999
2486 15. Full Copyright Statement
2488 Copyright (C) The Internet Society (1999). All Rights Reserved.
2490 This document and translations of it may be copied and furnished to
2491 others, and derivative works that comment on or otherwise explain it
2492 or assist in its implementation may be prepared, copied, published
2493 and distributed, in whole or in part, without restriction of any
2494 kind, provided that the above copyright notice and this paragraph are
2495 included on all such copies and derivative works. However, this
2496 document itself may not be modified in any way, such as by removing
2497 the copyright notice or references to the Internet Society or other
2498 Internet organizations, except as needed for the purpose of
2499 developing Internet standards in which case the procedures for
2500 copyrights defined in the Internet Standards process must be
2501 followed, or as required to translate it into languages other than
2504 The limited permissions granted above are perpetual and will not be
2505 revoked by the Internet Society or its successors or assigns.
2507 This document and the information contained herein is provided on an
2508 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2509 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2510 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2511 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2512 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
2536 McCloghrie, et al. Standards Track [Page 43]