diff options
Diffstat (limited to 'doc/rfc/rfc1902.txt')
| -rw-r--r-- | doc/rfc/rfc1902.txt | 2243 |
1 files changed, 2243 insertions, 0 deletions
diff --git a/doc/rfc/rfc1902.txt b/doc/rfc/rfc1902.txt new file mode 100644 index 0000000..d6ff641 --- /dev/null +++ b/doc/rfc/rfc1902.txt @@ -0,0 +1,2243 @@ + + + + + + +Network Working Group SNMPv2 Working Group +Request for Comments: 1902 J. Case +Obsoletes: 1442 SNMP Research, Inc. +Category: Standards Track K. McCloghrie + Cisco Systems, Inc. + M. Rose + Dover Beach Consulting, Inc. + S. Waldbusser + International Network Services + January 1996 + + + Structure of Management Information + for Version 2 of the + Simple Network Management Protocol (SNMPv2) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +1. Introduction + + A 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 + authentication, authorization, access control, and privacy policies. + + Management stations execute management applications which monitor and + control managed elements. Managed elements are devices such as + hosts, routers, terminal servers, etc., which are monitored and + controlled via 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 an adapted 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 adapted subset, and to assign a set of associated + administrative values. + + + + +SNMPv2 Working Group Standards Track [Page 1] + +RFC 1902 SMI for SNMPv2 January 1996 + + + The SMI is divided into three parts: module definitions, object + definitions, and, notification 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. + +1.1. A Note on Terminology + + For the purpose of exposition, the original Internet-standard Network + Management Framework, as described in RFCs 1155 (STD 16), 1157 (STD + 15), and 1212 (STD 16), is termed the SNMP version 1 framework + (SNMPv1). The current framework is termed the SNMP version 2 + framework (SNMPv2). + +2. Definitions + +SNMPv2-SMI DEFINITIONS ::= BEGIN + + +-- the path to the root + +org OBJECT IDENTIFIER ::= { iso 3 } +dod OBJECT IDENTIFIER ::= { org 6 } +internet OBJECT IDENTIFIER ::= { dod 1 } + +directory OBJECT IDENTIFIER ::= { internet 1 } + +mgmt OBJECT IDENTIFIER ::= { internet 2 } +mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } +transmission OBJECT IDENTIFIER ::= { mib-2 10 } + +experimental OBJECT IDENTIFIER ::= { internet 3 } + +private OBJECT IDENTIFIER ::= { internet 4 } +enterprises OBJECT IDENTIFIER ::= { private 1 } + +security OBJECT IDENTIFIER ::= { internet 5 } + + + + +SNMPv2 Working Group Standards Track [Page 2] + +RFC 1902 SMI for SNMPv2 January 1996 + + +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 } + + +-- 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 + + +OBJECT-IDENTITY MACRO ::= +BEGIN + TYPE NOTATION ::= + "STATUS" Status + "DESCRIPTION" Text + ReferPart + + + + +SNMPv2 Working Group Standards Track [Page 3] + +RFC 1902 SMI for SNMPv2 January 1996 + + + VALUE NOTATION ::= + value(VALUE OBJECT IDENTIFIER) + + Status ::= + "current" + | "deprecated" + | "obsolete" + + ReferPart ::= + "REFERENCE" Text + | empty + + Text ::= """" string """" +END + + +-- names of objects + +ObjectName ::= + OBJECT IDENTIFIER + +NotificationName ::= + 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 -- includes Integer32 + INTEGER (-2147483648..2147483647), + + + + +SNMPv2 Working Group Standards Track [Page 4] + +RFC 1902 SMI for SNMPv2 January 1996 + + + -- OCTET STRINGs with a more restrictive size + -- may also be used + string-value + OCTET STRING (SIZE (0..65535)), + + objectID-value + OBJECT IDENTIFIER + } + + +-- 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, + + timeticks-value + TimeTicks, + + arbitrary-value + Opaque, + + big-counter-value + Counter64, + + unsigned-integer-value -- includes Gauge32 + Unsigned32 + } + +-- in network-byte order +-- (this is a tagged type for historical reasons) +IpAddress ::= + [APPLICATION 0] + IMPLICIT OCTET STRING (SIZE (4)) + +-- this wraps +Counter32 ::= + + + +SNMPv2 Working Group Standards Track [Page 5] + +RFC 1902 SMI for SNMPv2 January 1996 + + + [APPLICATION 1] + IMPLICIT INTEGER (0..4294967295) + +-- this doesn't wrap +Gauge32 ::= + [APPLICATION 2] + IMPLICIT INTEGER (0..4294967295) + +-- an unsigned 32-bit quantity +-- indistinguishable from Gauge32 +Unsigned32 ::= + [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 counters that wrap in less than one hour with only 32 bits +Counter64 ::= + [APPLICATION 6] + IMPLICIT INTEGER (0..18446744073709551615) + + +-- definition for objects + +OBJECT-TYPE MACRO ::= +BEGIN + TYPE NOTATION ::= + "SYNTAX" Syntax + UnitsPart + "MAX-ACCESS" Access + "STATUS" Status + "DESCRIPTION" Text + ReferPart + IndexPart + DefValPart + + VALUE NOTATION ::= + value(VALUE ObjectName) + + Syntax ::= + + + +SNMPv2 Working Group Standards Track [Page 6] + +RFC 1902 SMI for SNMPv2 January 1996 + + + type(ObjectSyntax) + | "BITS" "{" Kibbles "}" + Kibbles ::= + Kibble + | Kibbles "," Kibble + Kibble ::= + identifier "(" nonNegativeNumber ")" + + UnitsPart ::= + "UNITS" Text + | empty + + Access ::= + "not-accessible" + | "accessible-for-notify" + | "read-only" + | "read-write" + | "read-create" + + Status ::= + "current" + | "deprecated" + | "obsolete" + + ReferPart ::= + "REFERENCE" Text + | empty + + IndexPart ::= + "INDEX" "{" IndexTypes "}" + | "AUGMENTS" "{" Entry "}" + | empty + IndexTypes ::= + IndexType + | IndexTypes "," IndexType + 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 ::= + + + +SNMPv2 Working Group Standards Track [Page 7] + +RFC 1902 SMI for SNMPv2 January 1996 + + + "DEFVAL" "{" value(Defval Syntax) "}" + | empty + + -- uses the NVT ASCII character set + Text ::= """" string """" +END + + +-- definitions for notifications + +NOTIFICATION-TYPE MACRO ::= +BEGIN + TYPE NOTATION ::= + ObjectsPart + "STATUS" Status + "DESCRIPTION" Text + ReferPart + + VALUE NOTATION ::= + value(VALUE NotificationName) + + 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 + +-- definitions of administrative identifiers + +zeroDotZero OBJECT-IDENTITY + STATUS current + DESCRIPTION + + + +SNMPv2 Working Group Standards Track [Page 8] + +RFC 1902 SMI for SNMPv2 January 1996 + + + "A value used for null identifiers." + ::= { 0 0 } + +END + +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 will normally 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. + + The constructs of ASN.1 allowed in SNMPv2 information modules + include: the IMPORTS clause, value definitions for OBJECT + IDENTIFIERs, type definitions for SEQUENCEs (with restrictions), + ASN.1 type assignments of the restricted ASN.1 types allowed in + SNMPv2, and instances of ASN.1 macros defined in this document and in + other documents [2, 3] of the SNMPv2 framework. Additional ASN.1 + macros may not be defined in SNMPv2 information modules. + + The names of all standard information modules must be unique (but + different versions of the same information module should have the + same name). Developers of enterprise information modules are + encouraged to choose names for their information modules that will + have a low probability of colliding with standard or other enterprise + + + +SNMPv2 Working Group Standards Track [Page 9] + +RFC 1902 SMI for SNMPv2 January 1996 + + + information modules. An information module may not use the ASN.1 + construct of placing an object identifier value between the module + name and the "DEFINITIONS" keyword. + + All information modules start with exactly one invocation of the + MODULE-IDENTITY macro, which provides contact information as well as + revision history to distinguish between versions of the same + information module. This invocation must appear immediately after + any IMPORTs 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> names + the macro being invoked, and <clauses> and <value> depend on the + definition of the macro. (Note that this definition of a descriptor + applies to all macros defined in this memo and in [2].) + + For the purposes of this specification, an ASN.1 identifier consists + of one or more letters or digits, and its initial character must be a + lower-case letter. (Note that hyphens are not allowed by this + specification, even though hyphen is allowed by [1]. This + restriction enables arithmetic expressions in languages which use the + minus sign to reference these descriptors without ambiguity.) + + For all descriptors appearing in an information module, the + descriptor shall be unique and mnemonic, and shall not exceed 64 + characters in length. (However, descriptors longer than 32 + characters are not recommended.) 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. + + 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 + + + +SNMPv2 Working Group Standards Track [Page 10] + +RFC 1902 SMI for SNMPv2 January 1996 + + + 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 in which the + descriptor is defined, where the module is identified by its ASN.1 + module name. + + 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 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. + +3.3. Exporting Symbols + + The ASN.1 EXPORTS statement is not allowed in SNMPv2 information + modules. All items defined in an information module are + automatically exported. + +3.4. ASN.1 Comments + + Comments in ASN.1 commence with a pair of adjacent hyphens and end + with the next pair of adjacent hyphens or at the end of the line, + whichever occurs first. + +3.5. OBJECT IDENTIFIER values + + An OBJECT IDENTIFIER value is an ordered list of non-negative + numbers. For the SNMPv2 framework, each number in the list is + referred to as a sub-identifier, there are at most 128 sub- + identifiers in a value, and each sub-identifier has a maximum value + of 2^32-1 (4294967295 decimal). All OBJECT IDENTIFIER values have at + least two sub-identifiers, where the value of the first sub- + identifier is one of the following well-known names: + + + +SNMPv2 Working Group Standards Track [Page 11] + +RFC 1902 SMI for SNMPv2 January 1996 + + + Value Name + 0 ccitt + 1 iso + 2 joint-iso-ccitt + +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. + +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. + + + +SNMPv2 Working Group Standards Track [Page 12] + +RFC 1902 SMI for SNMPv2 January 1996 + + + Note that reference in an IMPORTS clause or in clauses of SNMPv2 + macros to an information module is NOT through the use of the + 'descriptor' of a MODULE-IDENTITY macro; rather, an information + module is referenced through specifying its module name. + +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. The date and time + are represented in UTC Time format (see Appendix B). + +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 (including the initial version) made to this + information module, in reverse chronological order (i.e., most recent + first). Each instance of this clause contains the date and time of + the revision. The date and time are represented in UTC Time format + (see Appendix B). + +5.5.1. Mapping of the DESCRIPTION sub-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.6. 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 + + + +SNMPv2 Working Group Standards Track [Page 13] + +RFC 1902 SMI for SNMPv2 January 1996 + + + specifying an OBJECT IDENTIFIER value to refer to the information + module containing the invocation. + +5.7. 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 "9505241811Z" + 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 "9505241811Z" + DESCRIPTION + "The latest version of this MIB module." + REVISION "9210070433Z" + DESCRIPTION + "The initial version of this MIB module." +-- contact IANA for actual number + ::= { experimental xx } + + +END + + + + + + + + +SNMPv2 Working Group Standards Track [Page 14] + +RFC 1902 SMI for SNMPv2 January 1996 + + +6. Mapping of the OBJECT-IDENTITY macro + + The OBJECT-IDENTITY macro is used to define information about an + OBJECT IDENTIFIER assignment. All administrative OBJECT IDENTIFIER + assignments which define a type identification value (see + AutonomousType, a textual convention defined in [3]) should be + defined via the OBJECT-IDENTITY macro. 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. The + "deprecated" value indicates that the definition is obsolete, but + that an implementor may wish to support it to foster interoperability + with older implementations. + +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. + +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 } + + + + + + +SNMPv2 Working Group Standards Track [Page 15] + +RFC 1902 SMI for SNMPv2 January 1996 + + +7. Mapping of the OBJECT-TYPE macro + + The OBJECT-TYPE macro is used to define a type of 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. + + For leaf objects which are not columnar objects (i.e., not contained + within a conceptual table), 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. + +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 following: a base type, the BITS construct, or a textual + convention. (SEQUENCE OF and SEQUENCE are also possible for + conceptual tables, see section 7.1.12). The base types are those + defined in the ObjectSyntax CHOICE. A textual convention is a + newly-defined type defined as a sub-type of a base type [3]. + + A extended subset of the full capabilities of ASN.1 sub-typing is + allowed, as appropriate to the underingly ASN.1 type. Any such + restriction on size, range, enumerations or repertoire specified in + this clause represents the maximal level of support which makes + "protocol sense". Restrictions on sub-typing are specified in detail + in Section 9 and Appendix C of this memo. + + 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. Both the INTEGER + and Integer32 types may be sub-typed to be more constrained than the + Integer32 type. + + The INTEGER type may also be used to represent integer-valued + information as named-number enumerations. In this 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. + + + + +SNMPv2 Working Group Standards Track [Page 16] + +RFC 1902 SMI for SNMPv2 January 1996 + + + Finally, a label for a named-number enumeration must consist of one + or more letters or digits (no hyphens), up to a maximum of 64 + characters, and the initial character must be a lower-case letter. + (However, labels longer than 32 characters are not recommended.) + +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. The BITS construct + + The BITS construct 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. + (Thus, enumerations must be assigned to consecutive bits; however, + see Section 9 for refinements of an object with this syntax.) + + Although there is no SMI-specified limitation on the number of + enumerations (and therefore on the length of a value), MIB designers + should realize that there may be implementation and interoperability + limitations for sizes in excess of 128 bits. + + Finally, a label for a named-number enumeration must consist of one + or more letters or digits (no hyphens), up to a maximum of 64 + characters, and the initial character must be a lower-case letter. + (However, labels longer than 32 characters are not recommended.) + +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]. + + + + + + +SNMPv2 Working Group Standards Track [Page 17] + +RFC 1902 SMI for SNMPv2 January 1996 + + +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 either "read-only" or "accessible-for-notify". + + 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. + + 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 the time when sysUpTime [5] was zero, and the + second reference epoch is defined as the current value of sysUpTime. + + The TimeTicks type may not be sub-typed. + + + +SNMPv2 Working Group Standards Track [Page 18] + +RFC 1902 SMI for SNMPv2 January 1996 + + +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. 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 either "read-only" or "accessible-for-notify". + + 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. + + + + + + + +SNMPv2 Working Group Standards Track [Page 19] + +RFC 1902 SMI for SNMPv2 January 1996 + + +7.1.11. Unsigned32 + + The Unsigned32 type represents integer-valued information between 0 + and 2^32-1 inclusive (0 to 4294967295 decimal). + +7.1.12. Conceptual Tables + + Management operations apply exclusively to scalar objects. However, + it is sometimes convenient for developers of management applications + to impose an imaginary, tabular structure on an ordered collection of + objects within 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 object, and + <syntax> has the value of that subordinate object's SYNTAX clause, + normally 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". + +7.1.12.1. Creation and Deletion of Conceptual Rows + + For newly-defined conceptual rows which allow the creation of new + object instances and/or 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. + + + +SNMPv2 Working Group Standards Track [Page 20] + +RFC 1902 SMI for SNMPv2 January 1996 + + +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. + +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, or to include its value in a notification. 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 an auxiliary object (see Section + 7.7). The value "accessible-for-notify" indicates an object which is + accessible only via a notification (e.g., snmpTrapOID [5]). + + These values are ordered, from least to greatest: "not-accessible", + "accessible-for-notify", "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 definition 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. + + + + + + +SNMPv2 Working Group Standards Track [Page 21] + +RFC 1902 SMI for SNMPv2 January 1996 + + +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. + + 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 (when preceded by the IMPLIED keyword): + `n' sub-identifiers, where `n' is the number of sub-identifiers in + the value (each sub-identifier of the value is copied into a + separate sub-identifier); + +(5) object identifier-valued (when not preceded by the IMPLIED + keyword): `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); + +(6) IpAddress-valued: 4 sub-identifiers, in the familiar a.b.c.d + notation. + + Note that the IMPLIED keyword can only be present for an object + having a variable-length syntax (e.g., variable-length strings or + object identifier-valued objects), Further, the IMPLIED keyword can + + + +SNMPv2 Working Group Standards Track [Page 22] + +RFC 1902 SMI for SNMPv2 January 1996 + + + only be associated with the last object in the INDEX clause. + 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 auxiliary objects is + "not-accessible", except in the following circumstances: + +(1) within a MIB module originally written to conform to the SNMPv1 + framework, and later converted to conform to the SNMPv2 framework; + or + +(2) a conceptual row must contain at least one columnar object which is + not an auxiliary object. In the event that all of a conceptual + row's columnar objects are also specified in its INDEX clause, then + one of them must be accessible, i.e., have a MAX-ACCESS clause of + "read-only". (Note that this situation does not arise for a + conceptual row allowing create access, since such a row will have a + status column which will not be an auxiliary object.) + + 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.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 augmentation. (Thus, a conceptual row augmentation + cannot itself be augmented.) Instances of subordinate columnar + objects of a conceptual row augmentation are identified according to + + + +SNMPv2 Working Group Standards Track [Page 23] + +RFC 1902 SMI for SNMPv2 January 1996 + + + 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 augmentation 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. On the other hand, it would be incorrect to use + the AUGMENTS clause for the relationship between RFC 1573's ifTable + and the many media-specific MIBs which extend it for specific media + (e.g., the dot3Table in RFC 1650), since not all interfaces are of + the same media. + + Note that a base conceptual row may be augmented by multiple + conceptual row augmentations. + +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. + +(2) Otherwise, if there is a sparse relationship between the conceptual + rows of this table and an existing table, then an INDEX clause + should be used which is identical to that in the existing table. + For example, the relationship between RFC 1573's ifTable and a + media-specific MIB which extends the ifTable for a specific media + (e.g., the dot3Table in RFC 1650), is a sparse relationship. + +(3) Otherwise, if no existing objects have the required syntax and + semantics, then 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. + + + +SNMPv2 Working Group Standards Track [Page 24] + +RFC 1902 SMI for SNMPv2 January 1996 + + + 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: + + ObjectSyntax DEFVAL clause + ---------------- ------------ + Integer32 DEFVAL { 1 } + -- same for Gauge32, TimeTicks, Unsigned32 + INTEGER DEFVAL { valid } -- enumerated value + OCTET STRING DEFVAL { 'ffffffffffff'H } + OBJECT IDENTIFIER DEFVAL { sysDescr } + BITS DEFVAL { { primary, secondary } } + -- enumerated values that are set + IpAddress DEFVAL { '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. + + + + +SNMPv2 Working Group Standards Track [Page 25] + +RFC 1902 SMI for SNMPv2 January 1996 + + +(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. + + 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. + +7.11. Usage Example + + Consider how one might define a conceptual table and its + subordinates. (This example uses the RowStatus textual convention + defined in [3].) + +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 createAndGo(4) or createAndWait(5). 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 + + + +SNMPv2 Working Group Standards Track [Page 26] + +RFC 1902 SMI for SNMPv2 January 1996 + + + "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 } + +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 + + + +SNMPv2 Working Group Standards Track [Page 27] + +RFC 1902 SMI for SNMPv2 January 1996 + + + 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 } + +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 object types which are contained within every + instance of the notification. An object type specified in this + clause may not have an MAX-ACCESS clause of "not-accessible". + +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 definition is obsolete, but + that an implementor may wish to support the notification 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 notification. 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. + + + + + + +SNMPv2 Working Group Standards Track [Page 28] + +RFC 1902 SMI for SNMPv2 January 1996 + + +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 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. In order to achieve compatibility + with the procedures employed by proxy agents (see Section 3.1.2 of + [7]), the next to last sub-identifier in the name of any newly- + defined notification must have the value zero. + + 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. + +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. + +9. Refined Syntax + + Some macros have clauses which allows syntax to be refined, + specifically: the SYNTAX clause of the OBJECT-TYPE macro, and the + SYNTAX/WRITE-SYNTAX clauses of the MODULE-COMPLIANCE and AGENT- + CAPABILITIES macros [2]. However, not all refinements of syntax are + appropriate. In particular, the object's primitive or application + type must not be changed. + + + + +SNMPv2 Working Group Standards Track [Page 29] + +RFC 1902 SMI for SNMPv2 January 1996 + + + Further, the following restrictions apply: + + Restrictions to Refinement on + object syntax range enumeration size repertoire + ----------------- ----- ----------- ---- ---------- + INTEGER (1) (2) - - + Integer32 (1) - - - + Unsigned32 (1) - - - + OCTET STRING - - (3) (4) + OBJECT IDENTIFIER - - - - + BITS - (2) - - + IpAddress - - - - + Counter32 - - - - + Counter64 - - - - + Gauge32 (1) - - - + TimeTicks - - - - + +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 (note that for BITS, a refinement may cause the + enumerations to no longer be contiguous); + +(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. Further details on sub-typing + are provided in Appendix C. + +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. + + + + +SNMPv2 Working Group Standards Track [Page 30] + +RFC 1902 SMI for SNMPv2 January 1996 + + + 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. + +(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. + + + + + + +SNMPv2 Working Group Standards Track [Page 31] + +RFC 1902 SMI for SNMPv2 January 1996 + + +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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +SNMPv2 Working Group Standards Track [Page 32] + +RFC 1902 SMI for SNMPv2 January 1996 + + +11. Appendix A: 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, 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 + + + +SNMPv2 Working Group Standards Track [Page 33] + +RFC 1902 SMI for SNMPv2 January 1996 + + + 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 having enumerations becomes a BITS + construct. + +(5) An object with BIT STRING syntax but no enumerations becomes an + OCTET STRING. + +(6) An object with a character string syntax becomes either an OCTET + STRING, or a DisplayString [3], depending on the repertoire of the + character string. + +(7) 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. + +(8) 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. + + + + + + +SNMPv2 Working Group Standards Track [Page 34] + +RFC 1902 SMI for SNMPv2 January 1996 + + +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. + +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. + + + + + +SNMPv2 Working Group Standards Track [Page 35] + +RFC 1902 SMI for SNMPv2 January 1996 + + +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. + +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. + + + + + + + + + + + + + +SNMPv2 Working Group Standards Track [Page 36] + +RFC 1902 SMI for SNMPv2 January 1996 + + +12. Appendix B: UTC Time Format + + Several clauses defined in this document use the UTC Time format: + + YYMMDDHHMMZ + + where: YY - last two digits of year + MM - month (01 through 12) + DD - day of month (01 through 31) + HH - hours (00 through 23) + MM - minutes (00 through 59) + Z - the character "Z" denotes Greenwich Mean Time (GMT). + + For example, "9502192015Z" represents 8:15pm GMT on 19 February 1995. + +13. Appendix C: Detailed Sub-typing Rules + +13.1. Syntax Rules + + The syntax rules for sub-typing are given below. Note that while + this syntax is based on ASN.1, it includes some extensions beyond + what is allowed in ASN.1, and a number of ASN.1 constructs are not + allowed by this syntax. + + <integerSubType> + ::= <empty> + | "(" <range> ["|" <range>]... ")" + + <octetStringSubType> + ::= <empty> + | "(" "SIZE" "(" <range> ["|" <range>]... ")" ")" + + <range> + ::= <value> + | <value> ".." <value> + + <value> + ::= "-" <number> + | <number> + | <hexString> + | <binString> + + where: + <empty> is the empty string + <number> is a non-negative integer + <hexString> is a hexadecimal string (i.e. 'xxxx'H) + <binString> is a binary string (i.e. 'xxxx'B) + + + + +SNMPv2 Working Group Standards Track [Page 37] + +RFC 1902 SMI for SNMPv2 January 1996 + + + <range> is further restricted as follows: + - any <value> used in a SIZE clause must be non-negative. + - when a pair of values is specified, the first value + must be less than the second value. + - when multiple ranges are specified, the ranges may + not overlap but may touch. For example, (1..4 | 4..9) + is invalid, and (1..4 | 5..9) is valid. + - the ranges must be a subset of the maximum range of the + base type. + +13.2. Examples + +Some examples of legal sub-typing: + + Integer32 (-20..100) + Integer32 (0..100 | 300..500) + Integer32 (300..500 | 0..100) + Integer32 (0 | 2 | 4 | 6 | 8 | 10) + OCTET STRING (SIZE(0..100)) + OCTET STRING (SIZE(0..100 | 300..500)) + OCTET STRING (SIZE(0 | 2 | 4 | 6 | 8 | 10)) + +Some examples of illegal sub-typing: + + Integer32 (150..100) -- first greater than second + Integer32 (0..100 | 50..500) -- ranges overlap + Integer32 (0 | 2 | 0 ) -- value duplicated + Integer32 (MIN..-1 | 1..MAX) -- MIN and MAX not allowed + Integer32 ((SIZE (0..34)) -- must not use SIZE + OCTET STRING (0..100) -- must use SIZE + OCTET STRING (SIZE(-10..100)) -- negative SIZE + +13.3. Rules for Textual Conventions + + Sub-typing of Textual Conventions (see [3]) is allowed but must be + valid. In particular, each range specified for the textual + convention must be a subset of a range specified for the base type. + For example, + + Tc1 ::= INTEGER (1..10 | 11..20) + Tc2 ::= Tc1 (2..10 | 12..15) -- is valid + Tc3 ::= Tc1 (4..8) -- is valid + Tc4 ::= Tc1 (8..12) -- is invalid + +14. Security Considerations + + Security issues are not discussed in this memo. + + + + +SNMPv2 Working Group Standards Track [Page 38] + +RFC 1902 SMI for SNMPv2 January 1996 + + +15. Editor's Address + + Keith McCloghrie + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 95134-1706 + US + + Phone: +1 408 526 5260 + EMail: kzm@cisco.com + +16. Acknowledgements + + This document is the result of significant work by the four major + contributors: + + Jeffrey D. Case (SNMP Research, case@snmp.com) + Keith McCloghrie (Cisco Systems, kzm@cisco.com) + Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us) + Steven Waldbusser (International Network Services, stevew@uni.ins.com) + + In addition, the contributions of the SNMPv2 Working Group are + acknowledged. In particular, a special thanks is extended for the + contributions of: + + Alexander I. Alten (Novell) + Dave Arneson (Cabletron) + Uri Blumenthal (IBM) + Doug Book (Chipcom) + Kim Curran (Bell-Northern Research) + Jim Galvin (Trusted Information Systems) + Maria Greene (Ascom Timeplex) + Iain Hanson (Digital) + Dave Harrington (Cabletron) + Nguyen Hien (IBM) + Jeff Johnson (Cisco Systems) + Michael Kornegay (Object Quest) + Deirdre Kostick (AT&T Bell Labs) + David Levi (SNMP Research) + Daniel Mahoney (Cabletron) + Bob Natale (ACE*COMM) + Brian O'Keefe (Hewlett Packard) + Andrew Pearson (SNMP Research) + Dave Perkins (Peer Networks) + Randy Presuhn (Peer Networks) + Aleksey Romanov (Quality Quorum) + Shawn Routhier (Epilogue) + Jon Saperia (BGS Systems) + + + +SNMPv2 Working Group Standards Track [Page 39] + +RFC 1902 SMI for SNMPv2 January 1996 + + + Bob Stewart (Cisco Systems, bstewart@cisco.com), chair + Kaj Tesink (Bellcore) + Glenn Waters (Bell-Northern Research) + Bert Wijnen (IBM) + +17. 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] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and + S. Waldbusser, "Conformance Statements for Version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1904, January 1996. + +[3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and + S. Waldbusser, "Textual Conventions for Version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1903, January 1996. + +[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] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and + S. Waldbusser, "Management Information Base for Version 2 of the + Simple Network Management Protocol (SNMPv2)", RFC 1907, + January 1996. + +[6] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and + S. Waldbusser, "Protocol Operations for Version 2 of the Simple + Network Management Protocol (SNMPv2)", RFC 1905, January 1996. + +[7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and + S. Waldbusser, "Coexistence between Version 1 and Version 2 of the + Internet-standard Network Management Framework", RFC 1908, + January 1996. + + + + + + + + + + + + + +SNMPv2 Working Group Standards Track [Page 40] + |