📄 rfc2578.txt
字号:
-- built-in ASN.1 typesSimpleSyntax ::= CHOICE { -- INTEGERs with a more restrictive range -- may also be used integer-value -- includes Integer32 INTEGER (-2147483648..2147483647), -- 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 representationInteger32 ::= INTEGER (-2147483648..2147483647)-- application-wide typesApplicationSyntax ::= 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 orderMcCloghrie, et al. Standards Track [Page 7]RFC 2578 SMIv2 April 1999-- (this is a tagged type for historical reasons)IpAddress ::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4))-- this wrapsCounter32 ::= [APPLICATION 1] IMPLICIT INTEGER (0..4294967295)-- this doesn't wrapGauge32 ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295)-- an unsigned 32-bit quantity-- indistinguishable from Gauge32Unsigned32 ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295)-- hundredths of seconds since an epochTimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0..4294967295)-- for backward-compatibility onlyOpaque ::= [APPLICATION 4] IMPLICIT OCTET STRING-- for counters that wrap in less than one hour with only 32 bitsCounter64 ::= [APPLICATION 6] IMPLICIT INTEGER (0..18446744073709551615)-- definition for objectsOBJECT-TYPE MACRO ::=BEGIN TYPE NOTATION ::= "SYNTAX" Syntax UnitsPart "MAX-ACCESS" Access "STATUS" Status "DESCRIPTION" Text ReferPartMcCloghrie, et al. Standards Track [Page 8]RFC 2578 SMIv2 April 1999 IndexPart DefValPart VALUE NOTATION ::= value(VALUE ObjectName) Syntax ::= -- Must be one of the following: -- a base type (or its refinement), -- a textual convention (or its refinement), or -- a BITS pseudo-type type | "BITS" "{" NamedBits "}" NamedBits ::= NamedBit | NamedBits "," NamedBit NamedBit ::= identifier "(" number ")" -- number is nonnegative 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 | IndexMcCloghrie, et al. Standards Track [Page 9]RFC 2578 SMIv2 April 1999 Index ::= -- use the SYNTAX value of the -- correspondent OBJECT-TYPE invocation value(ObjectName) Entry ::= -- use the INDEX value of the -- correspondent OBJECT-TYPE invocation value(ObjectName) DefValPart ::= "DEFVAL" "{" Defvalue "}" | empty Defvalue ::= -- must be valid for the type specified in -- SYNTAX clause of same OBJECT-TYPE macro value(ObjectSyntax) | "{" BitsValue "}" BitsValue ::= BitNames | empty BitNames ::= BitName | BitNames "," BitName BitName ::= identifier -- a character string as defined in section 3.1.1 Text ::= value(IA5String)END-- definitions for notificationsNOTIFICATION-TYPE MACRO ::=BEGIN TYPE NOTATION ::= ObjectsPart "STATUS" Status "DESCRIPTION" Text ReferPart VALUE NOTATION ::= value(VALUE NotificationName) ObjectsPart ::= "OBJECTS" "{" Objects "}" | empty Objects ::= ObjectMcCloghrie, et al. Standards Track [Page 10]RFC 2578 SMIv2 April 1999 | Objects "," Object Object ::= value(ObjectName) Status ::= "current" | "deprecated" | "obsolete" ReferPart ::= "REFERENCE" Text | empty -- a character string as defined in section 3.1.1 Text ::= value(IA5String)END-- definitions of administrative identifierszeroDotZero OBJECT-IDENTITY STATUS current DESCRIPTION "A value used for null identifiers." ::= { 0 0 }END3. Information Modules An "information module" is an ASN.1 module defining information relating to network management. The SMI describes how to use an adapted subset of ASN.1 (1988) 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].McCloghrie, et al. Standards Track [Page 11]RFC 2578 SMIv2 April 1999 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 SMIv2 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 SMIv2, and instances of ASN.1 macros defined in this document and its companion documents [2, 3]. Additional ASN.1 macros must not be defined in SMIv2 information modules. SMIv1 macros must not be used in SMIv2 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 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. For the purposes of this specification, an ASN.1 module name begins with an upper-case letter and continues with zero or more letters, digits, or hyphens, except that a hyphen can not be the last character, nor can there be two consecutive hyphens. 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].)McCloghrie, et al. Standards Track [Page 12]RFC 2578 SMIv2 April 1999 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 (except for use by information modules converted from SMIv1 which did allow hyphens). For all descriptors appearing in an information module, the
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -