idnits 2.17.1 draft-ops-smiv2-smi-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 52 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 53 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 699: '...OBJECTS OCTET OF OPTIONAL ORGANIZATION...' RFC 2119 keyword, line 1171: '...SN.1 DEFAULT and OPTIONAL clauses are ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1477 has weird spacing: '...-valued final...' == Line 1696 has weird spacing: '... range enum...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (30 January 1999) is 9215 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'APPLICATION 0' on line 276 -- Looks like a reference, but probably isn't: 'APPLICATION 1' on line 281 -- Looks like a reference, but probably isn't: 'APPLICATION 2' on line 294 -- Looks like a reference, but probably isn't: 'APPLICATION 3' on line 299 -- Looks like a reference, but probably isn't: 'APPLICATION 4' on line 304 -- Looks like a reference, but probably isn't: 'APPLICATION 6' on line 309 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Normative reference to a draft: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 1907 (ref. '5') (Obsoleted by RFC 3418) ** Obsolete normative reference: RFC 1905 (ref. '6') (Obsoleted by RFC 3416) Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Editors of this version: 3 Internet Draft K. McCloghrie 4 Cisco Systems 5 D. Perkins 6 Desktalk Systems & SNMPinfo 7 J. Schoenwaelder 8 TU Braunschweig 9 Authors of previous version: 10 J. Case 11 SNMP Research 12 K. McCloghrie 13 Cisco Systems 14 M. Rose 15 First Virtual Holdings 16 S. Waldbusser 17 International Network Services 18 30 January 1999 20 Structure of Management Information Version 2 (SMIv2) 21 draft-ops-smiv2-smi-01.txt 23 Status of this Memo 25 This document is an Internet-Draft and is in full conformance with all 26 provisions of Section 10 of RFC2026. Internet-Drafts are working 27 documents of the Internet Engineering Task Force (IETF), its areas, and 28 its working groups. Note that other groups may also distribute working 29 documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference material 34 or to cite them other than as ``work in progress.'' 36 To view the current status of any Internet-Draft, please check the 37 ``1id-abstracts.txt'' listing contained in an Internet-Drafts Shadow 38 Directory, see http://www.ietf.org/shadow.html. 40 Copyright Notice 42 Copyright (C) The Internet Society (1999). All Rights Reserved. 44 Draft SMIv2 January 1999 46 1. Introduction 48 Management information is viewed as a collection of managed objects, 49 residing in a virtual information store, termed the Management 50 Information Base (MIB). Collections of related objects are defined in 51 MIB modules. These modules are written using an adapted subset of OSI's 52 Abstract Syntax Notation One, ASN.1 (1988) [1]. It is the purpose of 53 this document, the Structure of Management Information (SMI), to define 54 that adapted subset, and to assign a set of associated administrative 55 values. 57 The SMI is divided into three parts: module definitions, object 58 definitions, and, notification definitions. 60 (1) Module definitions are used when describing information modules. 61 An ASN.1 macro, MODULE-IDENTITY, is used to concisely convey the 62 semantics of an information module. 64 (2) Object definitions are used when describing managed objects. An 65 ASN.1 macro, OBJECT-TYPE, is used to concisely convey the syntax 66 and semantics of a managed object. 68 (3) Notification definitions are used when describing unsolicited 69 transmissions of management information. An ASN.1 macro, 70 NOTIFICATION-TYPE, is used to concisely convey the syntax and 71 semantics of a notification. 73 1.1. A Note on Terminology 75 For the purpose of exposition, the original Structure of Management 76 Information, as described in RFCs 1155 (STD 16), 1212 (STD 16), and RFC 77 1215, is termed the SMI version 1 (SMIv1). The current version of the 78 Structure of Management Information is termed SMI version 2 (SMIv2). 80 Draft SMIv2 January 1999 82 2. Definitions 84 SNMPv2-SMI DEFINITIONS ::= BEGIN 86 -- the path to the root 88 org OBJECT IDENTIFIER ::= { iso 3 } 89 dod OBJECT IDENTIFIER ::= { org 6 } 90 internet OBJECT IDENTIFIER ::= { dod 1 } 92 directory OBJECT IDENTIFIER ::= { internet 1 } 94 mgmt OBJECT IDENTIFIER ::= { internet 2 } 95 mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } 96 transmission OBJECT IDENTIFIER ::= { mib-2 10 } 98 experimental OBJECT IDENTIFIER ::= { internet 3 } 100 private OBJECT IDENTIFIER ::= { internet 4 } 101 enterprises OBJECT IDENTIFIER ::= { private 1 } 103 security OBJECT IDENTIFIER ::= { internet 5 } 105 snmpV2 OBJECT IDENTIFIER ::= { internet 6 } 107 -- transport domains 108 snmpDomains OBJECT IDENTIFIER ::= { snmpV2 1 } 110 -- transport proxies 111 snmpProxys OBJECT IDENTIFIER ::= { snmpV2 2 } 113 -- module identities 114 snmpModules OBJECT IDENTIFIER ::= { snmpV2 3 } 116 Draft SMIv2 January 1999 118 -- Extended UTCTime, to allow dates with four-digit years 119 -- (Note that this definition of ExtUTCTime is not to be IMPORTed 120 -- by MIB modules.) 121 ExtUTCTime ::= OCTET STRING(SIZE(11 | 13)) 122 -- format is YYMMDDHHMMZ or YYYYMMDDHHMMZ 123 -- where: YY - last two digits of year (only years 124 -- between 1900-1999) 125 -- YYYY - last four digits of the year (any year) 126 -- MM - month (01 through 12) 127 -- DD - day of month (01 through 31) 128 -- HH - hours (00 through 23) 129 -- MM - minutes (00 through 59) 130 -- Z - denotes GMT (the ASCII character Z) 131 -- 132 -- For example, "9502192015Z" and "199502192015Z" represent 133 -- 8:15pm GMT on 19 February 1995. Years after 1999 must use 134 -- the four digit year format. Years 1900-1999 may use the 135 -- two or four digit format. 137 -- definitions for information modules 139 MODULE-IDENTITY MACRO ::= 140 BEGIN 141 TYPE NOTATION ::= 142 "LAST-UPDATED" value(Update ExtUTCTime) 143 "ORGANIZATION" Text 144 "CONTACT-INFO" Text 145 "DESCRIPTION" Text 146 RevisionPart 148 VALUE NOTATION ::= 149 value(VALUE OBJECT IDENTIFIER) 151 RevisionPart ::= 152 Revisions 153 | empty 154 Revisions ::= 155 Revision 156 | Revisions Revision 157 Revision ::= 158 "REVISION" value(Update ExtUTCTime) 159 "DESCRIPTION" Text 161 -- a character string as defined in section 3.1.1 162 Text ::= value(IA5String) 164 Draft SMIv2 January 1999 166 END 168 Draft SMIv2 January 1999 170 OBJECT-IDENTITY MACRO ::= 171 BEGIN 172 TYPE NOTATION ::= 173 "STATUS" Status 174 "DESCRIPTION" Text 175 ReferPart 177 VALUE NOTATION ::= 178 value(VALUE OBJECT IDENTIFIER) 180 Status ::= 181 "current" 182 | "deprecated" 183 | "obsolete" 185 ReferPart ::= 186 "REFERENCE" Text 187 | empty 189 -- a character string as defined in section 3.1.1 190 Text ::= value(IA5String) 191 END 193 Draft SMIv2 January 1999 195 -- names of objects 196 -- (Note that these definitions of ObjectName and NotificationName 197 -- are not to be IMPORTed by MIB modules.) 199 ObjectName ::= 200 OBJECT IDENTIFIER 202 NotificationName ::= 203 OBJECT IDENTIFIER 205 -- syntax of objects 207 -- the "base types" defined here are: 208 -- 3 built-in ASN.1 types: INTEGER, OCTET STRING, OBJECT IDENTIFIER 209 -- 8 application-defined types: Integer32, IpAddress, Counter32, 210 -- Gauge32, Unsigned32, TimeTicks, Opaque, and Counter64 212 ObjectSyntax ::= 213 CHOICE { 214 simple 215 SimpleSyntax, 217 -- note that SEQUENCEs for conceptual tables and 218 -- rows are not mentioned here... 220 application-wide 221 ApplicationSyntax 222 } 224 -- built-in ASN.1 types 226 SimpleSyntax ::= 227 CHOICE { 228 -- INTEGERs with a more restrictive range 229 -- may also be used 230 integer-value -- includes Integer32 231 INTEGER (-2147483648..2147483647), 233 -- OCTET STRINGs with a more restrictive size 234 -- may also be used 235 string-value 236 OCTET STRING (SIZE (0..65535)), 238 objectID-value 239 OBJECT IDENTIFIER 241 Draft SMIv2 January 1999 243 } 245 -- indistinguishable from INTEGER, but never needs more than 246 -- 32-bits for a two's complement representation 247 Integer32 ::= 248 INTEGER (-2147483648..2147483647) 250 -- application-wide types 252 ApplicationSyntax ::= 253 CHOICE { 254 ipAddress-value 255 IpAddress, 257 counter-value 258 Counter32, 260 timeticks-value 261 TimeTicks, 263 arbitrary-value 264 Opaque, 266 big-counter-value 267 Counter64, 269 unsigned-integer-value -- includes Gauge32 270 Unsigned32 271 } 273 -- in network-byte order 274 -- (this is a tagged type for historical reasons) 275 IpAddress ::= 276 [APPLICATION 0] 277 IMPLICIT OCTET STRING (SIZE (4)) 279 -- this wraps 280 Counter32 ::= 281 [APPLICATION 1] 282 IMPLICIT INTEGER (0..4294967295) 284 Draft SMIv2 January 1999 286 -- this doesn't wrap 287 Gauge32 ::= 288 [APPLICATION 2] 289 IMPLICIT INTEGER (0..4294967295) 291 -- an unsigned 32-bit quantity 292 -- indistinguishable from Gauge32 293 Unsigned32 ::= 294 [APPLICATION 2] 295 IMPLICIT INTEGER (0..4294967295) 297 -- hundredths of seconds since an epoch 298 TimeTicks ::= 299 [APPLICATION 3] 300 IMPLICIT INTEGER (0..4294967295) 302 -- for backward-compatibility only 303 Opaque ::= 304 [APPLICATION 4] 305 IMPLICIT OCTET STRING 307 -- for counters that wrap in less than one hour with only 32 bits 308 Counter64 ::= 309 [APPLICATION 6] 310 IMPLICIT INTEGER (0..18446744073709551615) 312 Draft SMIv2 January 1999 314 -- definition for objects 316 OBJECT-TYPE MACRO ::= 317 BEGIN 318 TYPE NOTATION ::= 319 "SYNTAX" Syntax 320 UnitsPart 321 "MAX-ACCESS" Access 322 "STATUS" Status 323 "DESCRIPTION" Text 324 ReferPart 325 IndexPart 326 DefValPart 328 VALUE NOTATION ::= 329 value(VALUE ObjectName) 331 Syntax ::= -- Must be one of the following: 332 -- a base type (or its refinement), 333 -- a textual convention (or its refinement), or 334 -- a BITS pseudo-type 335 type 336 | "BITS" "{" NamedBits "}" 338 NamedBits ::= NamedBit 339 | NamedBits "," NamedBit 341 NamedBit ::= identifier "(" number ")" -- number is nonnegative 343 UnitsPart ::= 344 "UNITS" Text 345 | empty 347 Access ::= 348 "not-accessible" 349 | "accessible-for-notify" 350 | "read-only" 351 | "read-write" 352 | "read-create" 354 Status ::= 355 "current" 356 | "deprecated" 357 | "obsolete" 359 Draft SMIv2 January 1999 361 ReferPart ::= 362 "REFERENCE" Text 363 | empty 365 IndexPart ::= 366 "INDEX" "{" IndexTypes "}" 367 | "AUGMENTS" "{" Entry "}" 368 | empty 369 IndexTypes ::= 370 IndexType 371 | IndexTypes "," IndexType 372 IndexType ::= 373 "IMPLIED" Index 374 | Index 375 Index ::= 376 -- use the SYNTAX value of the 377 -- correspondent OBJECT-TYPE invocation 378 value(ObjectName) 379 Entry ::= 380 -- use the INDEX value of the 381 -- correspondent OBJECT-TYPE invocation 382 value(ObjectName) 384 DefValPart ::= "DEFVAL" "{" Defvalue "}" 385 | empty 387 Defvalue ::= -- must be valid for the type specified in 388 -- SYNTAX clause of same OBJECT-TYPE macro 389 value(ObjectSyntax) 390 | "{" BitsValue "}" 392 BitsValue ::= BitNames 393 | empty 395 BitNames ::= BitName 396 | BitNames "," BitName 398 BitName ::= identifier 400 -- a character string as defined in section 3.1.1 401 Text ::= value(IA5String) 402 END 404 Draft SMIv2 January 1999 406 -- definitions for notifications 408 NOTIFICATION-TYPE MACRO ::= 409 BEGIN 410 TYPE NOTATION ::= 411 ObjectsPart 412 "STATUS" Status 413 "DESCRIPTION" Text 414 ReferPart 416 VALUE NOTATION ::= 417 value(VALUE NotificationName) 419 ObjectsPart ::= 420 "OBJECTS" "{" Objects "}" 421 | empty 422 Objects ::= 423 Object 424 | Objects "," Object 425 Object ::= 426 value(ObjectName) 428 Status ::= 429 "current" 430 | "deprecated" 431 | "obsolete" 433 ReferPart ::= 434 "REFERENCE" Text 435 | empty 437 -- a character string as defined in section 3.1.1 438 Text ::= value(IA5String) 439 END 441 -- definitions of administrative identifiers 443 zeroDotZero OBJECT-IDENTITY 444 STATUS current 445 DESCRIPTION 446 "A value used for null identifiers." 447 ::= { 0 0 } 449 END 451 Draft SMIv2 January 1999 453 3. Information Modules 455 An "information module" is an ASN.1 module defining information relating 456 to network management. 458 The SMI describes how to use an adapted subset of ASN.1 (1988) to define 459 an information module. Further, additional restrictions are placed on 460 "standard" information modules. It is strongly recommended that 461 "enterprise-specific" information modules also adhere to these 462 restrictions. 464 Typically, there are three kinds of information modules: 466 (1) MIB modules, which contain definitions of inter-related managed 467 objects, make use of the OBJECT-TYPE and NOTIFICATION-TYPE macros; 469 (2) compliance statements for MIB modules, which make use of the 470 MODULE-COMPLIANCE and OBJECT-GROUP macros [2]; and, 472 (3) capability statements for agent implementations which make use of 473 the AGENT-CAPABILITIES macros [2]. 475 This classification scheme does not imply a rigid taxonomy. For 476 example, a "standard" information module will normally include 477 definitions of managed objects and a compliance statement. Similarly, 478 an "enterprise-specific" information module might include definitions of 479 managed objects and a capability statement. Of course, a "standard" 480 information module may not contain capability statements. 482 The constructs of ASN.1 allowed in SMIv2 information modules include: 483 the IMPORTS clause, value definitions for OBJECT IDENTIFIERs, type 484 definitions for SEQUENCEs (with restrictions), ASN.1 type assignments of 485 the restricted ASN.1 types allowed in SMIv2, and instances of ASN.1 486 macros defined in this document and its companion documents [2, 3]. 487 Additional ASN.1 macros must not be defined in SMIv2 information 488 modules. SMIv1 macros must not be used in SMIv2 information modules. 490 The names of all standard information modules must be unique (but 491 different versions of the same information module should have the same 492 name). Developers of enterprise information modules are encouraged to 493 choose names for their information modules that will have a low 494 probability of colliding with standard or other enterprise information 495 modules. An information module may not use the ASN.1 construct of 496 placing an object identifier value between the module name and the 497 "DEFINITIONS" keyword. For the purposes of this specification, an ASN.1 499 Draft SMIv2 January 1999 501 module name begins with an upper-case letter and continues with zero or 502 more letters, digits, or hyphens, except that a hyphen can not be the 503 last character, nor can there be two consecutive hyphens. 505 All information modules start with exactly one invocation of the 506 MODULE-IDENTITY macro, which provides contact information as well as 507 revision history to distinguish between versions of the same information 508 module. This invocation must appear immediately after any IMPORTs 509 statements. 511 3.1. Macro Invocation 513 Within an information module, each macro invocation appears as: 515 ::= 517 where corresponds to an ASN.1 identifier, names the 518 macro being invoked, and and depend on the definition 519 of the macro. (Note that this definition of a descriptor applies to all 520 macros defined in this memo and in [2].) 522 For the purposes of this specification, an ASN.1 identifier consists of 523 one or more letters or digits, and its initial character must be a 524 lower-case letter. Note that hyphens are not allowed by this 525 specification (except for use by information modules converted from 526 SMIv1 which did allow hyphens). 528 For all descriptors appearing in an information module, the descriptor 529 shall be unique and mnemonic, and shall not exceed 64 characters in 530 length. (However, descriptors longer than 32 characters are not 531 recommended.) This promotes a common language for humans to use when 532 discussing the information module and also facilitates simple table 533 mappings for user-interfaces. 535 The set of descriptors defined in all "standard" information modules 536 shall be unique. 538 Finally, by convention, if the descriptor refers to an object with a 539 SYNTAX clause value of either Counter32 or Counter64, then the 540 descriptor used for the object should denote plurality. 542 Draft SMIv2 January 1999 544 3.1.1. Textual Values and Strings 546 Some clauses in a macro invocation may take a character string as a 547 textual value (e.g., the DESCRIPTION clause). Other clauses take binary 548 or hexadecimal strings (in any position where a non-negative number is 549 allowed). 551 A character string is preceded and followed by the quote character ("), 552 and consists of an arbitrary number (possibly zero) of: 554 - any 7-bit displayable ASCII characters except quote ("), 555 - tab characters, 556 - spaces, and 557 - line terminator characters (\n or \r\n). 559 The value of a character string is interpreted as ASCII. 561 A binary string consists of a number (possibly zero) of zeros and ones 562 preceded by a single (') and followed by either the pair ('B) or ('b), 563 where the number is a multiple of eight. 565 A hexadecimal string consists of an even number (possibly zero) of 566 hexadecimal digits, preceded by a single (') and followed by either the 567 pair ('H) or ('h). Digits specified via letters can be in upper or 568 lower case. 570 Note that ASN.1 comments can not be enclosed inside any of these types 571 of strings. 573 3.2. IMPORTing Symbols 575 To reference an external object, the IMPORTS statement must be used to 576 identify both the descriptor and the module in which the descriptor is 577 defined, where the module is identified by its ASN.1 module name. 579 Note that when symbols from "enterprise-specific" information modules 580 are referenced (e.g., a descriptor), there is the possibility of 581 collision. As such, if different objects with the same descriptor are 582 IMPORTed, then this ambiguity is resolved by prefixing the descriptor 583 with the name of the information module and a dot ("."), i.e., 585 "module.descriptor" 587 (All descriptors must be unique within any information module.) 589 Draft SMIv2 January 1999 591 Of course, this notation can be used to refer to objects even when there 592 is no collision when IMPORTing symbols. 594 Finally, if any of the ASN.1 named types and macros defined in this 595 document, specifically: 597 Counter32, Counter64, Gauge32, Integer32, IpAddress, MODULE- 598 IDENTITY, NOTIFICATION-TYPE, Opaque, OBJECT-TYPE, OBJECT-IDENTITY, 599 TimeTicks, Unsigned32, 601 or any of those defined in [2] or [3], are used in an information 602 module, then they must be imported using the IMPORTS statement. 603 However, the following must not be included in an IMPORTS statement: 605 - named types defined by ASN.1 itself, specifically: INTEGER, OCTET 606 STRING, OBJECT IDENTIFIER, SEQUENCE, SEQUENCE OF type, 607 - the BITS construct. 609 3.3. Exporting Symbols 611 The ASN.1 EXPORTS statement is not allowed in SMIv2 information modules. 612 All items defined in an information module are automatically exported. 614 3.4. ASN.1 Comments 616 ASN.1 comments can be included in an information module. However, it is 617 recommended that all substantive descriptions be placed within an 618 appropriate DESCRIPTION clause. 620 ASN.1 comments commence with a pair of adjacent hyphens and end with the 621 next pair of adjacent hyphens or at the end of the line, whichever 622 occurs first. Comments ended by a pair of hyphens have the effect of a 623 single space character. 625 3.5. OBJECT IDENTIFIER values 627 An OBJECT IDENTIFIER value is an ordered list of non-negative numbers. 628 For the SMIv2, each number in the list is referred to as a sub- 629 identifier, there are at most 128 sub-identifiers in a value, and each 630 sub-identifier has a maximum value of 2^32-1 (4294967295 decimal). 632 Draft SMIv2 January 1999 634 All OBJECT IDENTIFIER values have at least two sub-identifiers, where 635 the value of the first sub-identifier is one of the following well-known 636 names: 638 Value Name 639 0 ccitt 640 1 iso 641 2 joint-iso-ccitt 643 (Note that this SMI does not recognize "new" well-known names, e.g., as 644 defined when the CCITT became the ITU.) 646 3.6. OBJECT IDENTIFIER usage 648 OBJECT IDENTIFIERs are used in information modules in two ways: 650 (1) registration: the definition of a particular item is registered as 651 a particular OBJECT IDENTIFIER value, and associated with a 652 particular descriptor. After such a registration, the semantics 653 thereby associated with the value are not allowed to change, the 654 OBJECT IDENTIFIER can not be used for any other registration, and 655 the descriptor can not be changed nor associated with any other 656 registration. The following macros result in a registration: 658 OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE, OBJECT-GROUP, 659 OBJECT-IDENTITY, NOTIFICATION-GROUP, MODULE-COMPLIANCE, 660 AGENT-CAPABILITIES. 662 (2) assignment: a descriptor can be assigned to a particular OBJECT 663 IDENTIFIER value. For this usage, the semantics associated with 664 the OBJECT IDENTIFIER value is not allowed to change, and a 665 descriptor assigned to a particular OBJECT IDENTIFIER value cannot 666 subsequently be assigned to another. However, multiple descriptors 667 can be assigned to the same OBJECT IDENTIFIER value. Such 668 assignments are specified in the following manner: 670 mib OBJECT IDENTIFIER ::= { mgmt 1 } -- from RFC1156 671 mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } -- from RFC1213 672 fredRouter OBJECT IDENTIFIER ::= { flintStones 1 1 } 673 barneySwitch OBJECT IDENTIFIER ::= { flintStones bedrock(2) 1 } 675 Note while the above examples are legal, the following is not: 677 dinoHost OBJECT IDENTIFIER ::= { flintStones bedrock 2 } 679 Draft SMIv2 January 1999 681 A descriptor is allowed to be associated with both a registration and an 682 assignment, providing both are associated with the same OBJECT 683 IDENTIFIER value and semantics. 685 3.7. Reserved Keywords 687 The following are reserved keywords which must not be used as 688 descriptors or module names: 690 ABSENT ACCESS AGENT-CAPABILITIES ANY APPLICATION AUGMENTS BEGIN BIT 691 BITS BOOLEAN BY CHOICE COMPONENT COMPONENTS CONTACT-INFO CREATION- 692 REQUIRES Counter32 Counter64 DEFAULT DEFINED DEFINITIONS DEFVAL 693 DESCRIPTION DISPLAY-HINT END ENUMERATED ENTERPRISE EXPLICIT EXPORTS 694 EXTERNAL FALSE FROM GROUP Gauge32 IDENTIFIER IMPLICIT IMPLIED 695 IMPORTS INCLUDES INDEX INTEGER Integer32 IpAddress LAST-UPDATED 696 MANDATORY-GROUPS MAX MAX-ACCESS MIN MIN-ACCESS MINUS-INFINITY 697 MODULE MODULE-COMPLIANCE MODULE-IDENTITY NOTIFICATION-GROUP 698 NOTIFICATION-TYPE NOTIFICATIONS NULL OBJECT OBJECT-GROUP OBJECT- 699 IDENTITY OBJECT-TYPE OBJECTS OCTET OF OPTIONAL ORGANIZATION Opaque 700 PLUS-INFINITY PRESENT PRIVATE PRODUCT-RELEASE REAL REFERENCE 701 REVISION SEQUENCE SET SIZE STATUS STRING SUPPORTS SYNTAX TAGS 702 TEXTUAL-CONVENTION TRAP-TYPE TRUE TimeTicks UNITS UNIVERSAL 703 Unsigned32 VARIABLES VARIATION WITH WRITE-SYNTAX 705 Draft SMIv2 January 1999 707 4. Naming Hierarchy 709 The root of the subtree administered by the Internet Assigned Numbers 710 Authority (IANA) for the Internet is: 712 internet OBJECT IDENTIFIER ::= { iso 3 6 1 } 714 That is, the Internet subtree of OBJECT IDENTIFIERs starts with the 715 prefix: 717 1.3.6.1. 719 Several branches underneath this subtree are used for network 720 management: 722 mgmt OBJECT IDENTIFIER ::= { internet 2 } 723 experimental OBJECT IDENTIFIER ::= { internet 3 } 724 private OBJECT IDENTIFIER ::= { internet 4 } 725 enterprises OBJECT IDENTIFIER ::= { private 1 } 727 However, the SMI does not prohibit the definition of objects in other 728 portions of the object tree. 730 The mgmt(2) subtree is used to identify "standard" objects. 732 The experimental(3) subtree is used to identify objects being designed 733 by working groups of the IETF. If an information module produced by a 734 working group becomes a "standard" information module, then at the very 735 beginning of its entry onto the Internet standards track, the objects 736 are moved under the mgmt(2) subtree. 738 The private(4) subtree is used to identify objects defined unilaterally. 739 The enterprises(1) subtree beneath private is used, among other things, 740 to permit providers of networking subsystems to register models of their 741 products. 743 Draft SMIv2 January 1999 745 5. Mapping of the MODULE-IDENTITY macro 747 The MODULE-IDENTITY macro is used to provide contact and revision 748 history for each information module. It must appear exactly once in 749 every information module. It should be noted that the expansion of the 750 MODULE-IDENTITY macro is something which conceptually happens during 751 implementation and not during run-time. 753 Note that reference in an IMPORTS clause or in clauses of SMIv2 macros 754 to an information module is NOT through the use of the 'descriptor' of a 755 MODULE-IDENTITY macro; rather, an information module is referenced 756 through specifying its module name. 758 5.1. Mapping of the LAST-UPDATED clause 760 The LAST-UPDATED clause, which must be present, contains the date and 761 time that this information module was last edited. 763 5.2. Mapping of the ORGANIZATION clause 765 The ORGANIZATION clause, which must be present, contains a textual 766 description of the organization under whose auspices this information 767 module was developed. 769 5.3. Mapping of the CONTACT-INFO clause 771 The CONTACT-INFO clause, which must be present, contains the name, 772 postal address, telephone number, and electronic mail address of the 773 person to whom technical queries concerning this information module 774 should be sent. 776 5.4. Mapping of the DESCRIPTION clause 778 The DESCRIPTION clause, which must be present, contains a high-level 779 textual description of the contents of this information module. 781 5.5. Mapping of the REVISION clause 783 The REVISION clause, which need not be present, is repeatedly used to 784 describe the revisions (including the initial version) made to this 786 Draft SMIv2 January 1999 788 information module, in reverse chronological order (i.e., most recent 789 first). Each instance of this clause contains the date and time of the 790 revision. 792 5.5.1. Mapping of the DESCRIPTION sub-clause 794 The DESCRIPTION sub-clause, which must be present for each REVISION 795 clause, contains a high-level textual description of the revision 796 identified in that REVISION clause. 798 5.6. Mapping of the MODULE-IDENTITY value 800 The value of an invocation of the MODULE-IDENTITY macro is an OBJECT 801 IDENTIFIER. As such, this value may be authoritatively used when 802 specifying an OBJECT IDENTIFIER value to refer to the information module 803 containing the invocation. 805 Note that it is a common practice to use the value of the MODULE- 806 IDENTITY macro as a subtree under which other OBJECT IDENTIFIER values 807 assigned within the module are defined. However, it is legal (and 808 occasionally necessary) for the other OBJECT IDENTIFIER values assigned 809 within the module to be unrelated to the OBJECT IDENTIFIER value of the 810 MODULE-IDENTITY macro. 812 Draft SMIv2 January 1999 814 5.7. Usage Example 816 Consider how a skeletal MIB module might be constructed: e.g., 818 FIZBIN-MIB DEFINITIONS ::= BEGIN 820 IMPORTS 821 MODULE-IDENTITY, OBJECT-TYPE, experimental 822 FROM SNMPv2-SMI; 824 fizbin MODULE-IDENTITY 825 LAST-UPDATED "199505241811Z" 826 ORGANIZATION "IETF SNMPv2 Working Group" 827 CONTACT-INFO 828 " Marshall T. Rose 830 Postal: Dover Beach Consulting, Inc. 831 420 Whisman Court 832 Mountain View, CA 94043-2186 833 US 835 Tel: +1 415 968 1052 836 Fax: +1 415 968 2510 838 E-mail: mrose@dbc.mtview.ca.us" 839 DESCRIPTION 840 "The MIB module for entities implementing the xxxx 841 protocol." 842 REVISION "9505241811Z" 843 DESCRIPTION 844 "The latest version of this MIB module." 845 REVISION "9210070433Z" 846 DESCRIPTION 847 "The initial version of this MIB module, published in RFC 848 yyyy." 849 -- contact IANA for actual number 850 ::= { experimental xx } 852 END 854 Draft SMIv2 January 1999 856 6. Mapping of the OBJECT-IDENTITY macro 858 The OBJECT-IDENTITY macro is used to define information about an OBJECT 859 IDENTIFIER assignment. All administrative OBJECT IDENTIFIER assignments 860 which define a type identification value (see AutonomousType, a textual 861 convention defined in [3]) should be defined via the OBJECT-IDENTITY 862 macro. It should be noted that the expansion of the OBJECT-IDENTITY 863 macro is something which conceptually happens during implementation and 864 not during run-time. 866 6.1. Mapping of the STATUS clause 868 The STATUS clause, which must be present, indicates whether this 869 definition is current or historic. 871 The value "current" means that the definition is current and valid. The 872 value "obsolete" means the definition is obsolete and should not be 873 implemented and/or can be removed if previously implemented. While the 874 value "deprecated" also indicates an obsolete definition, it permits 875 new/continued implementation in order to foster interoperability with 876 older/existing implementations. 878 6.2. Mapping of the DESCRIPTION clause 880 The DESCRIPTION clause, which must be present, contains a textual 881 description of the object assignment. 883 6.3. Mapping of the REFERENCE clause 885 The REFERENCE clause, which need not be present, contains a textual 886 cross-reference to some other document, either another information 887 module which defines a related assignment, or some other document which 888 provides additional information relevant to this definition. 890 6.4. Mapping of the OBJECT-IDENTITY value 892 The value of an invocation of the OBJECT-IDENTITY macro is an OBJECT 893 IDENTIFIER. 895 Draft SMIv2 January 1999 897 6.5. Usage Example 899 Consider how an OBJECT IDENTIFIER assignment might be made: e.g., 901 fizbin69 OBJECT-IDENTITY 902 STATUS current 903 DESCRIPTION 904 "The authoritative identity of the Fizbin 69 chipset." 905 ::= { fizbinChipSets 1 } 907 Draft SMIv2 January 1999 909 7. Mapping of the OBJECT-TYPE macro 911 The OBJECT-TYPE macro is used to define a type of managed object. It 912 should be noted that the expansion of the OBJECT-TYPE macro is something 913 which conceptually happens during implementation and not during run- 914 time. 916 For leaf objects which are not columnar objects (i.e., not contained 917 within a conceptual table), instances of the object are identified by 918 appending a sub-identifier of zero to the name of that object. 919 Otherwise, the INDEX clause of the conceptual row object superior to a 920 columnar object defines instance identification information. 922 7.1. Mapping of the SYNTAX clause 924 The SYNTAX clause, which must be present, defines the abstract data 925 structure corresponding to that object. The data structure must be one 926 of the following: a base type, the BITS construct, or a textual 927 convention. (SEQUENCE OF and SEQUENCE are also possible for conceptual 928 tables, see section 7.1.12). The base types are those defined in the 929 ObjectSyntax CHOICE. A textual convention is a newly-defined type 930 defined as a sub-type of a base type [3]. 932 An extended subset of the full capabilities of ASN.1 (1988) sub-typing 933 is allowed, as appropriate to the underlying ASN.1 type. Any such 934 restriction on size, range or enumerations specified in this clause 935 represents the maximal level of support which makes "protocol sense". 936 Restrictions on sub-typing are specified in detail in Section 9 and 937 Appendix A of this memo. 939 The semantics of ObjectSyntax are now described. 941 7.1.1. Integer32 and INTEGER 943 The Integer32 type represents integer-valued information between -2^31 944 and 2^31-1 inclusive (-2147483648 to 2147483647 decimal). This type is 945 indistinguishable from the INTEGER type. Both the INTEGER and Integer32 946 types may be sub-typed to be more constrained than the Integer32 type. 948 The INTEGER type (but not the Integer32 type) may also be used to 949 represent integer-valued information as named-number enumerations. In 950 this case, only those named-numbers so enumerated may be present as a 951 value. Note that although it is recommended that enumerated values 953 Draft SMIv2 January 1999 955 start at 1 and be numbered contiguously, any valid value for Integer32 956 is allowed for an enumerated value and, further, enumerated values 957 needn't be contiguously assigned. 959 Finally, a label for a named-number enumeration must consist of one or 960 more letters or digits, up to a maximum of 64 characters, and the 961 initial character must be a lower-case letter. (However, labels longer 962 than 32 characters are not recommended.) Note that hyphens are not 963 allowed by this specification (except for use by information modules 964 converted from SMIv1 which did allow hyphens). 966 7.1.2. OCTET STRING 968 The OCTET STRING type represents arbitrary binary or textual data. 969 Although the SMI-specified size limitation for this type is 65535 970 octets, MIB designers should realize that there may be implementation 971 and interoperability limitations for sizes in excess of 255 octets. 973 7.1.3. OBJECT IDENTIFIER 975 The OBJECT IDENTIFIER type represents administratively assigned names. 976 Any instance of this type may have at most 128 sub-identifiers. 977 Further, each sub-identifier must not exceed the value 2^32-1 978 (4294967295 decimal). 980 7.1.4. The BITS construct 982 The BITS construct represents an enumeration of named bits. This 983 collection is assigned non-negative, contiguous (but see below) values, 984 starting at zero. Only those named-bits so enumerated may be present in 985 a value. (Thus, enumerations must be assigned to consecutive bits; 986 however, see Section 9 for refinements of an object with this syntax.) 988 As part of updating an information module, for an object defined using 989 the BITS construct, new enumerations can be added or existing 990 enumerations can have new labels assigned to them. After an enumeration 991 is added, it might not be possible to distinguish between an 992 implementation of the updated object for which the new enumeration is 993 not asserted, and an implementation of the object prior to the addition. 994 Depending on the circumstances, such an ambiguity could either be 995 desirable or could be undesirable. The means to avoid such an ambiguity 996 is dependent on the encoding of values on the wire; however, one 998 Draft SMIv2 January 1999 1000 possibility is to define new enumerations starting at the next multiple 1001 of eight bits. (Of course, this can also result in the enumerations no 1002 longer being contiguous.) 1004 Although there is no SMI-specified limitation on the number of 1005 enumerations (and therefore on the length of a value), except as may be 1006 imposed by the limit on the length of an OCTET STRING, MIB designers 1007 should realize that there may be implementation and interoperability 1008 limitations for sizes in excess of 128 bits. 1010 Finally, a label for a named-number enumeration must consist of one or 1011 more letters or digits, up to a maximum of 64 characters, and the 1012 initial character must be a lower-case letter. (However, labels longer 1013 than 32 characters are not recommended.) Note that hyphens are not 1014 allowed by this specification. 1016 7.1.5. IpAddress 1018 The IpAddress type represents a 32-bit internet address. It is 1019 represented as an OCTET STRING of length 4, in network byte-order. 1021 Note that the IpAddress type is a tagged type for historical reasons. 1022 Network addresses should be represented using an invocation of the 1023 TEXTUAL-CONVENTION macro [3]. 1025 7.1.6. Counter32 1027 The Counter32 type represents a non-negative integer which monotonically 1028 increases until it reaches a maximum value of 2^32-1 (4294967295 1029 decimal), when it wraps around and starts increasing again from zero. 1031 Counters have no defined "initial" value, and thus, a single value of a 1032 Counter has (in general) no information content. Discontinuities in the 1033 monotonically increasing value normally occur at re-initialization of 1034 the management system, and at other times as specified in the 1035 description of an object-type using this ASN.1 type. If such other 1036 times can occur, for example, the creation of an object instance at 1037 times other than re-initialization, then a corresponding object should 1038 be defined, with an appropriate SYNTAX clause, to indicate the last 1039 discontinuity. Examples of appropriate SYNTAX clause include: TimeStamp 1040 (a textual convention defined in [3]), DateAndTime (another textual 1041 convention from [3]) or TimeTicks. 1043 Draft SMIv2 January 1999 1045 The value of the MAX-ACCESS clause for objects with a SYNTAX clause 1046 value of Counter32 is either "read-only" or "accessible-for-notify". 1048 A DEFVAL clause is not allowed for objects with a SYNTAX clause value of 1049 Counter32. 1051 7.1.7. Gauge32 1053 The Gauge32 type represents a non-negative integer, which may increase 1054 or decrease, but shall never exceed a maximum value, nor fall below a 1055 minimum value. The maximum value can not be greater than 2^32-1 1056 (4294967295 decimal), and the minimum value can not be smaller than 0. 1057 The value of a Gauge32 has its maximum value whenever the information 1058 being modeled is greater than or equal to its maximum value, and has its 1059 minimum value whenever the information being modeled is smaller than or 1060 equal to its minimum value. If the information being modeled 1061 subsequently decreases below (increases above) the maximum (minimum) 1062 value, the Gauge32 also decreases (increases). (Note that despite of 1063 the use of the term "latched" in the original definition of this type, 1064 it does not become "stuck" at its maximum or minimum value.) 1066 7.1.8. TimeTicks 1068 The TimeTicks type represents a non-negative integer which represents 1069 the time, modulo 2^32 (4294967296 decimal), in hundredths of a second 1070 between two epochs. When objects are defined which use this ASN.1 type, 1071 the description of the object identifies both of the reference epochs. 1073 For example, [3] defines the TimeStamp textual convention which is based 1074 on the TimeTicks type. With a TimeStamp, the first reference epoch is 1075 defined as the time when sysUpTime [5] was zero, and the second 1076 reference epoch is defined as the current value of sysUpTime. 1078 The TimeTicks type may not be sub-typed. 1080 7.1.9. Opaque 1082 The Opaque type is provided solely for backward-compatibility, and shall 1083 not be used for newly-defined object types. 1085 The Opaque type supports the capability to pass arbitrary ASN.1 syntax. 1086 A value is encoded using the ASN.1 Basic Encoding Rules [4] into a 1088 Draft SMIv2 January 1999 1090 string of octets. This, in turn, is encoded as an OCTET STRING, in 1091 effect "double-wrapping" the original ASN.1 value. 1093 Note that a conforming implementation need only be able to accept and 1094 recognize opaquely-encoded data. It need not be able to unwrap the data 1095 and then interpret its contents. 1097 A requirement on "standard" MIB modules is that no object may have a 1098 SYNTAX clause value of Opaque. 1100 7.1.10. Counter64 1102 The Counter64 type represents a non-negative integer which monotonically 1103 increases until it reaches a maximum value of 2^64-1 1104 (18446744073709551615 decimal), when it wraps around and starts 1105 increasing again from zero. 1107 Counters have no defined "initial" value, and thus, a single value of a 1108 Counter has (in general) no information content. Discontinuities in the 1109 monotonically increasing value normally occur at re-initialization of 1110 the management system, and at other times as specified in the 1111 description of an object-type using this ASN.1 type. If such other 1112 times can occur, for example, the creation of an object instance at 1113 times other than re-initialization, then a corresponding object should 1114 be defined, with an appropriate SYNTAX clause, to indicate the last 1115 discontinuity. Examples of appropriate SYNTAX clause are: TimeStamp (a 1116 textual convention defined in [3]), DateAndTime (another textual 1117 convention from [3]) or TimeTicks. 1119 The value of the MAX-ACCESS clause for objects with a SYNTAX clause 1120 value of Counter64 is either "read-only" or "accessible-for-notify". 1122 A requirement on "standard" MIB modules is that the Counter64 type may 1123 be used only if the information being modeled would wrap in less than 1124 one hour if the Counter32 type was used instead. 1126 A DEFVAL clause is not allowed for objects with a SYNTAX clause value of 1127 Counter64. 1129 7.1.11. Unsigned32 1131 The Unsigned32 type represents integer-valued information between 0 and 1132 2^32-1 inclusive (0 to 4294967295 decimal). 1134 Draft SMIv2 January 1999 1136 7.1.12. Conceptual Tables 1138 Management operations apply exclusively to scalar objects. However, it 1139 is sometimes convenient for developers of management applications to 1140 impose an imaginary, tabular structure on an ordered collection of 1141 objects within the MIB. Each such conceptual table contains zero or 1142 more rows, and each row may contain one or more scalar objects, termed 1143 columnar objects. This conceptualization is formalized by using the 1144 OBJECT-TYPE macro to define both an object which corresponds to a table 1145 and an object which corresponds to a row in that table. A conceptual 1146 table has SYNTAX of the form: 1148 SEQUENCE OF 1150 where refers to the SEQUENCE type of its subordinate 1151 conceptual row. A conceptual row has SYNTAX of the form: 1153 1155 where is a SEQUENCE type defined as follows: 1157 ::= SEQUENCE { , ... , } 1159 where there is one for each subordinate object, and each 1160 is of the form: 1162 1164 where is the descriptor naming a subordinate object, and 1165 has the value of that subordinate object's SYNTAX clause, 1166 except that both sub-typing information and the named values for 1167 enumerated integers or the named bits for the BITS construct, are 1168 omitted from . 1170 Further, a is always present for every subordinate object. (The 1171 ASN.1 DEFAULT and OPTIONAL clauses are disallowed in the SEQUENCE 1172 definition.) The MAX-ACCESS clause for conceptual tables and rows is 1173 "not-accessible". 1175 7.1.12.1. Creation and Deletion of Conceptual Rows 1177 For newly-defined conceptual rows which allow the creation of new object 1178 instances and/or the deletion of existing object instances, there should 1179 be one columnar object with a SYNTAX clause value of RowStatus (a 1181 Draft SMIv2 January 1999 1183 textual convention defined in [3]) and a MAX-ACCESS clause value of 1184 read-create. By convention, this is termed the status column for the 1185 conceptual row. 1187 7.2. Mapping of the UNITS clause 1189 This UNITS clause, which need not be present, contains a textual 1190 definition of the units associated with that object. 1192 7.3. Mapping of the MAX-ACCESS clause 1194 The MAX-ACCESS clause, which must be present, defines whether it makes 1195 "protocol sense" to read, write and/or create an instance of the object, 1196 or to include its value in a notification. This is the maximal level of 1197 access for the object. (This maximal level of access is independent of 1198 any administrative authorization policy.) 1200 The value "read-write" indicates that read and write access make 1201 "protocol sense", but create does not. The value "read-create" 1202 indicates that read, write and create access make "protocol sense". The 1203 value "not-accessible" indicates an auxiliary object (see Section 7.7). 1204 The value "accessible-for-notify" indicates an object which is 1205 accessible only via a notification (e.g., snmpTrapOID [5]). 1207 These values are ordered, from least to greatest: "not-accessible", 1208 "accessible-for-notify", "read-only", "read-write", "read-create". 1210 If any columnar object in a conceptual row has "read-create" as its 1211 maximal level of access, then no other columnar object of the same 1212 conceptual row may have a maximal access of "read-write". (Note that 1213 "read-create" is a superset of "read-write".) 1215 7.4. Mapping of the STATUS clause 1217 The STATUS clause, which must be present, indicates whether this 1218 definition is current or historic. 1220 The value "current" means that the definition is current and valid. The 1221 value "obsolete" means the definition is obsolete and should not be 1222 implemented and/or can be removed if previously implemented. While the 1223 value "deprecated" also indicates an obsolete definition, it permits 1224 new/continued implementation in order to foster interoperability with 1226 Draft SMIv2 January 1999 1228 older/existing implementations. 1230 7.5. Mapping of the DESCRIPTION clause 1232 The DESCRIPTION clause, which must be present, contains a textual 1233 definition of that object which provides all semantic definitions 1234 necessary for implementation, and should embody any information which 1235 would otherwise be communicated in any ASN.1 commentary annotations 1236 associated with the object. 1238 7.6. Mapping of the REFERENCE clause 1240 The REFERENCE clause, which need not be present, contains a textual 1241 cross-reference to some other document, either another information 1242 module which defines a related assignment, or some other document which 1243 provides additional information relevant to this definition. 1245 7.7. Mapping of the INDEX clause 1247 The INDEX clause, which must be present if that object corresponds to a 1248 conceptual row (unless an AUGMENTS clause is present instead), and must 1249 be absent otherwise, defines instance identification information for the 1250 columnar objects subordinate to that object. 1252 The instance identification information in an INDEX clause must specify 1253 object(s) such that value(s) of those object(s) will unambiguously 1254 distinguish a conceptual row. The objects can be columnar objects from 1255 the same and/or another conceptual table, but must not be scalar 1256 objects. Multiple occurrences of the same object in a single INDEX 1257 clause is strongly discouraged. 1259 The syntax of the objects in the INDEX clause indicate how to form the 1260 instance-identifier: 1262 (1) integer-valued (i.e., having INTEGER as its underlying primitive 1263 type): a single sub-identifier taking the integer value (this works 1264 only for non-negative integers); 1266 (2) string-valued, fixed-length strings (or variable-length preceded by 1267 the IMPLIED keyword): `n' sub-identifiers, where `n' is the length 1268 of the string (each octet of the string is encoded in a separate 1269 sub-identifier); 1271 Draft SMIv2 January 1999 1273 (3) string-valued, variable-length strings (not preceded by the IMPLIED 1274 keyword): `n+1' sub-identifiers, where `n' is the length of the 1275 string (the first sub-identifier is `n' itself, following this, 1276 each octet of the string is encoded in a separate sub-identifier); 1278 (4) object identifier-valued (when preceded by the IMPLIED keyword): 1279 `n' sub-identifiers, where `n' is the number of sub-identifiers in 1280 the value (each sub-identifier of the value is copied into a 1281 separate sub-identifier); 1283 (5) object identifier-valued (when not preceded by the IMPLIED 1284 keyword): `n+1' sub-identifiers, where `n' is the number of sub- 1285 identifiers in the value (the first sub-identifier is `n' itself, 1286 following this, each sub-identifier in the value is copied); 1288 (6) IpAddress-valued: 4 sub-identifiers, in the familiar a.b.c.d 1289 notation. 1291 Note that the IMPLIED keyword can only be present for an object having a 1292 variable-length syntax (e.g., variable-length strings or object 1293 identifier-valued objects), Further, the IMPLIED keyword can only be 1294 associated with the last object in the INDEX clause. Finally, the 1295 IMPLIED keyword may not be used on a variable-length string object if 1296 that string might have a value of zero-length. 1298 Since a single value of a Counter has (in general) no information 1299 content (see section 7.1.6 and 7.1.10), objects defined using the 1300 syntax, Counter32 or Counter64, must not be specified in an INDEX 1301 clause. If an object defined using the BITS construct is used in an 1302 INDEX clause, it is considered a variable-length string. 1304 Instances identified by use of integer-valued objects should be numbered 1305 starting from one (i.e., not from zero). The use of zero as a value for 1306 an integer-valued index object should be avoided, except in special 1307 cases. 1309 Objects which are both specified in the INDEX clause of a conceptual row 1310 and also columnar objects of the same conceptual row are termed 1311 auxiliary objects. The MAX-ACCESS clause for auxiliary objects is 1312 "not-accessible", except in the following circumstances: 1314 (1) within a MIB module originally written to conform to SMIv1, and 1315 later converted to conform to SMIv2; or 1317 Draft SMIv2 January 1999 1319 (2) a conceptual row must contain at least one columnar object which is 1320 not an auxiliary object. In the event that all of a conceptual 1321 row's columnar objects are also specified in its INDEX clause, then 1322 one of them must be accessible, i.e., have a MAX-ACCESS clause of 1323 "read-only". (Note that this situation does not arise for a 1324 conceptual row allowing create access, since such a row will have a 1325 status column which will not be an auxiliary object.) 1327 Note that objects specified in a conceptual row's INDEX clause need not 1328 be columnar objects of that conceptual row. In this situation, the 1329 DESCRIPTION clause of the conceptual row must include a textual 1330 explanation of how the objects which are included in the INDEX clause 1331 but not columnar objects of that conceptual row, are used in uniquely 1332 identifying instances of the conceptual row's columnar objects. 1334 7.8. Mapping of the AUGMENTS clause 1336 The AUGMENTS clause, which must not be present unless the object 1337 corresponds to a conceptual row, is an alternative to the INDEX clause. 1338 Every object corresponding to a conceptual row has either an INDEX 1339 clause or an AUGMENTS clause. 1341 If an object corresponding to a conceptual row has an INDEX clause, that 1342 row is termed a base conceptual row; alternatively, if the object has an 1343 AUGMENTS clause, the row is said to be a conceptual row augmentation, 1344 where the AUGMENTS clause names the object corresponding to the base 1345 conceptual row which is augmented by this conceptual row augmentation. 1346 (Thus, a conceptual row augmentation cannot itself be augmented.) 1347 Instances of subordinate columnar objects of a conceptual row 1348 augmentation are identified according to the INDEX clause of the base 1349 conceptual row corresponding to the object named in the AUGMENTS clause. 1350 Further, instances of subordinate columnar objects of a conceptual row 1351 augmentation exist according to the same semantics as instances of 1352 subordinate columnar objects of the base conceptual row being augmented. 1353 As such, note that creation of a base conceptual row implies the 1354 correspondent creation of any conceptual row augmentations. 1356 For example, a MIB designer might wish to define additional columns in 1357 an "enterprise-specific" MIB which logically extend a conceptual row in 1358 a "standard" MIB. The "standard" MIB definition of the conceptual row 1359 would include the INDEX clause and the "enterprise-specific" MIB would 1360 contain the definition of a conceptual row using the AUGMENTS clause. 1361 On the other hand, it would be incorrect to use the AUGMENTS clause for 1362 the relationship between RFC 2233's ifTable and the many media-specific 1364 Draft SMIv2 January 1999 1366 MIBs which extend it for specific media (e.g., the dot3Table in RFC 1367 2358), since not all interfaces are of the same media. 1369 Note that a base conceptual row may be augmented by multiple conceptual 1370 row augmentations. 1372 7.8.1. Relation between INDEX and AUGMENTS clauses 1374 When defining instance identification information for a conceptual 1375 table: 1377 (1) If there is a one-to-one correspondence between the conceptual rows 1378 of this table and an existing table, then the AUGMENTS clause 1379 should be used. 1381 (2) Otherwise, if there is a sparse relationship between the conceptual 1382 rows of this table and an existing table, then an INDEX clause 1383 should be used which is identical to that in the existing table. 1384 For example, the relationship between RFC 2233's ifTable and a 1385 media-specific MIB which extends the ifTable for a specific media 1386 (e.g., the dot3Table in RFC 2358), is a sparse relationship. 1388 (3) Otherwise, if no existing objects have the required syntax and 1389 semantics, then auxiliary objects should be defined within the 1390 conceptual row for the new table, and those objects should be used 1391 within the INDEX clause for the conceptual row. 1393 7.9. Mapping of the DEFVAL clause 1395 The DEFVAL clause, which need not be present, defines an acceptable 1396 default value which may be used at the discretion of an agent when an 1397 object instance is created. That is, the value is a "hint" to 1398 implementors. 1400 During conceptual row creation, if an instance of a columnar object is 1401 not present as one of the operands in the correspondent management 1402 protocol set operation, then the value of the DEFVAL clause, if present, 1403 indicates an acceptable default value that an agent might use 1404 (especially for a read-only object). 1406 Note that with this definition of the DEFVAL clause, it is appropriate 1407 to use it for any columnar object of a read-create table. It is also 1408 permitted to use it for scalar objects dynamically created by an agent, 1410 Draft SMIv2 January 1999 1412 or for columnar objects of a read-write table dynamically created by an 1413 agent. 1415 The value of the DEFVAL clause must, of course, correspond to the SYNTAX 1416 clause for the object. If the value is an OBJECT IDENTIFIER, then it 1417 must be expressed as a single ASN.1 identifier, and not as a collection 1418 of sub-identifiers. 1420 Note that if an operand to the management protocol set operation is an 1421 instance of a read-only object, then the error `notWritable' [6] will be 1422 returned. As such, the DEFVAL clause can be used to provide an 1423 acceptable default value that an agent might use. 1425 By way of example, consider the following possible DEFVAL clauses: 1427 ObjectSyntax DEFVAL clause 1428 ---------------- ------------ 1429 Integer32 DEFVAL { 1 } 1430 -- same for Gauge32, TimeTicks, Unsigned32 1431 INTEGER DEFVAL { valid } -- enumerated value 1432 OCTET STRING DEFVAL { 'ffffffffffff'H } 1433 DisplayString DEFVAL { "SNMP agent" } 1434 IpAddress DEFVAL { 'c0210415'H } -- 192.33.4.21 1435 OBJECT IDENTIFIER DEFVAL { sysDescr } 1436 BITS DEFVAL { { primary, secondary } } 1437 -- enumerated values that are set 1438 BITS DEFVAL { { } } 1439 -- no enumerated values are set 1441 A binary string used in a DEFVAL clause for an OCTET STRING must be 1442 either an integral multiple of eight or zero bits in length; similarly, 1443 a hexadecimal string must be an even number of hexadecimal digits. The 1444 value of a character string used in a DEFVAL clause must not contain tab 1445 characters or line terminator characters. 1447 Object types with SYNTAX of Counter32 and Counter64 may not have DEFVAL 1448 clauses, since they do not have defined initial values. However, it is 1449 recommended that they be initialized to zero. 1451 7.10. Mapping of the OBJECT-TYPE value 1453 The value of an invocation of the OBJECT-TYPE macro is the name of the 1454 object, which is an OBJECT IDENTIFIER, an administratively assigned 1455 name. 1457 Draft SMIv2 January 1999 1459 When an OBJECT IDENTIFIER is assigned to an object: 1461 (1) If the object corresponds to a conceptual table, then only a single 1462 assignment, that for a conceptual row, is present immediately 1463 beneath that object. The administratively assigned name for the 1464 conceptual row object is derived by appending a sub-identifier of 1465 "1" to the administratively assigned name for the conceptual table. 1467 (2) If the object corresponds to a conceptual row, then at least one 1468 assignment, one for each column in the conceptual row, is present 1469 beneath that object. The administratively assigned name for each 1470 column is derived by appending a unique, positive sub-identifier to 1471 the administratively assigned name for the conceptual row. 1473 (3) Otherwise, no other OBJECT IDENTIFIERs which are subordinate to the 1474 object may be assigned. 1476 Note that the final sub-identifier of any administratively assigned name 1477 for an object shall be positive. A zero-valued final sub-identifier is 1478 reserved for future use. 1480 Draft SMIv2 January 1999 1482 7.11. Usage Example 1484 Consider how one might define a conceptual table and its subordinates. 1485 (This example uses the RowStatus textual convention defined in [3].) 1487 evalSlot OBJECT-TYPE 1488 SYNTAX Integer32 (0..2147483647) 1489 MAX-ACCESS read-only 1490 STATUS current 1491 DESCRIPTION 1492 "The index number of the first unassigned entry in the 1493 evaluation table, or the value of zero indicating that all 1494 entries are assigned. 1496 A management station should create new entries in the 1497 evaluation table using this algorithm: first, issue a 1498 management protocol retrieval operation to determine the 1499 value of evalSlot; and, second, issue a management protocol 1500 set operation to create an instance of the evalStatus object 1501 setting its value to createAndGo(4) or createAndWait(5). If 1502 this latter operation succeeds, then the management station 1503 may continue modifying the instances corresponding to the 1504 newly created conceptual row, without fear of collision with 1505 other management stations." 1506 ::= { eval 1 } 1508 evalTable OBJECT-TYPE 1509 SYNTAX SEQUENCE OF EvalEntry 1510 MAX-ACCESS not-accessible 1511 STATUS current 1512 DESCRIPTION 1513 "The (conceptual) evaluation table." 1514 ::= { eval 2 } 1516 evalEntry OBJECT-TYPE 1517 SYNTAX EvalEntry 1518 MAX-ACCESS not-accessible 1519 STATUS current 1520 DESCRIPTION 1521 "An entry (conceptual row) in the evaluation table." 1522 INDEX { evalIndex } 1523 ::= { evalTable 1 } 1525 EvalEntry ::= 1526 SEQUENCE { 1528 Draft SMIv2 January 1999 1530 evalIndex Integer32, 1531 evalString DisplayString, 1532 evalValue Integer32, 1533 evalStatus RowStatus 1534 } 1536 evalIndex OBJECT-TYPE 1537 SYNTAX Integer32 (1..2147483647) 1538 MAX-ACCESS not-accessible 1539 STATUS current 1540 DESCRIPTION 1541 "The auxiliary variable used for identifying instances of 1542 the columnar objects in the evaluation table." 1543 ::= { evalEntry 1 } 1545 evalString OBJECT-TYPE 1546 SYNTAX DisplayString 1547 MAX-ACCESS read-create 1548 STATUS current 1549 DESCRIPTION 1550 "The string to evaluate." 1551 ::= { evalEntry 2 } 1553 evalValue OBJECT-TYPE 1554 SYNTAX Integer32 1555 MAX-ACCESS read-only 1556 STATUS current 1557 DESCRIPTION 1558 "The value when evalString was last evaluated, or zero if no 1559 such value is available." 1560 DEFVAL { 0 } 1561 ::= { evalEntry 3 } 1563 evalStatus OBJECT-TYPE 1564 SYNTAX RowStatus 1565 MAX-ACCESS read-create 1566 STATUS current 1567 DESCRIPTION 1568 "The status column used for creating, modifying, and 1569 deleting instances of the columnar objects in the evaluation 1570 table." 1571 DEFVAL { active } 1572 ::= { evalEntry 4 } 1574 Draft SMIv2 January 1999 1576 8. Mapping of the NOTIFICATION-TYPE macro 1578 The NOTIFICATION-TYPE macro is used to define the information contained 1579 within an unsolicited transmission of management information (i.e., 1580 within either a SNMPv2-Trap-PDU or InformRequest-PDU). It should be 1581 noted that the expansion of the NOTIFICATION-TYPE macro is something 1582 which conceptually happens during implementation and not during run- 1583 time. 1585 8.1. Mapping of the OBJECTS clause 1587 The OBJECTS clause, which need not be present, defines an ordered 1588 sequence of MIB object types. One and only one object instance for each 1589 occurrence of each object type must be present, and in the specified 1590 order, in every instance of the notification. If the same object type 1591 occurs multiple times in a notification's ordered sequence, then an 1592 object instance is present for each of them. An object type specified 1593 in this clause must not have an MAX-ACCESS clause of "not-accessible". 1594 The notification's DESCRIPTION clause must specify the 1595 information/meaning conveyed by each occurrence of each object type in 1596 the sequence. The DESCRIPTION clause must also specify which object 1597 instance is present for each object type in the notification. 1599 Note that an agent is allowed, at its own discretion, to append as many 1600 additional objects as it considers useful to the end of the notification 1601 (i.e., after the objects defined by the OBJECTS clause). 1603 8.2. Mapping of the STATUS clause 1605 The STATUS clause, which must be present, indicates whether this 1606 definition is current or historic. 1608 The value "current" means that the definition is current and valid. The 1609 value "obsolete" means the definition is obsolete and should not be 1610 implemented and/or can be removed if previously implemented. While the 1611 value "deprecated" also indicates an obsolete definition, it permits 1612 new/continued implementation in order to foster interoperability with 1613 older/existing implementations. 1615 Draft SMIv2 January 1999 1617 8.3. Mapping of the DESCRIPTION clause 1619 The DESCRIPTION clause, which must be present, contains a textual 1620 definition of the notification which provides all semantic definitions 1621 necessary for implementation, and should embody any information which 1622 would otherwise be communicated in any ASN.1 commentary annotations 1623 associated with the notification. In particular, the DESCRIPTION clause 1624 should document which instances of the objects mentioned in the OBJECTS 1625 clause should be contained within notifications of this type. 1627 8.4. Mapping of the REFERENCE clause 1629 The REFERENCE clause, which need not be present, contains a textual 1630 cross-reference to some other document, either another information 1631 module which defines a related assignment, or some other document which 1632 provides additional information relevant to this definition. 1634 8.5. Mapping of the NOTIFICATION-TYPE value 1636 The value of an invocation of the NOTIFICATION-TYPE macro is the name of 1637 the notification, which is an OBJECT IDENTIFIER, an administratively 1638 assigned name. In order to achieve compatibility with SNMPv1 traps, 1639 both when converting SMIv1 information modules to/from this SMI, and in 1640 the procedures employed by multi-lingual systems and proxy forwarding 1641 applications, the next to last sub-identifier in the name of any newly- 1642 defined notification must have the value zero. 1644 Sections 4.2.6 and 4.2.7 of [6] describe how the NOTIFICATION-TYPE macro 1645 is used to generate a SNMPv2-Trap-PDU or InformRequest-PDU, 1646 respectively. 1648 Draft SMIv2 January 1999 1650 8.6. Usage Example 1652 Consider how a configuration change notification might be described: 1654 entityMIBTraps OBJECT IDENTIFIER ::= { entityMIB 2 } 1655 entityMIBTrapPrefix OBJECT IDENTIFIER ::= { entityMIBTraps 0 } 1657 entConfigChange NOTIFICATION-TYPE 1658 STATUS current 1659 DESCRIPTION 1660 "An entConfigChange trap is sent when the value of 1661 entLastChangeTime changes. It can be utilized by an NMS to 1662 trigger logical/physical entity table maintenance polls. 1664 An agent must not generate more than one entConfigChange 1665 'trap-event' in a five second period, where a 'trap-event' 1666 is the transmission of a single trap PDU to a list of trap 1667 destinations. If additional configuration changes occur 1668 within the five second 'throttling' period, then these 1669 trap-events should be suppressed by the agent. An NMS should 1670 periodically check the value of entLastChangeTime to detect 1671 any missed entConfigChange trap-events, e.g. due to 1672 throttling or transmission loss." 1673 ::= { entityMIBTrapPrefix 1 } 1675 According to this invocation, the notification authoritatively 1676 identified as 1678 { entityMIBTrapPrefix 1 } 1680 is used to report a particular type of configuration change. 1682 Draft SMIv2 January 1999 1684 9. Refined Syntax 1686 Some macros have clauses which allows syntax to be refined, 1687 specifically: the SYNTAX clause of the OBJECT-TYPE macro, and the 1688 SYNTAX/WRITE-SYNTAX clauses of the MODULE-COMPLIANCE and AGENT- 1689 CAPABILITIES macros [2]. However, not all refinements of syntax are 1690 appropriate. In particular, the object's primitive or application type 1691 must not be changed. 1693 Further, the following restrictions apply: 1695 Restrictions to Refinement of 1696 object syntax range enumeration size 1697 ----------------- ----- ----------- ---- 1698 INTEGER (1) (2) - 1699 Integer32 (1) - - 1700 Unsigned32 (1) - - 1701 OCTET STRING - - (3) 1702 OBJECT IDENTIFIER - - - 1703 BITS - (2) - 1704 IpAddress - - - 1705 Counter32 - - - 1706 Counter64 - - - 1707 Gauge32 (1) - - 1708 TimeTicks - - - 1710 where: 1712 (1) the range of permitted values may be refined by raising the lower- 1713 bounds, by reducing the upper-bounds, and/or by reducing the 1714 alternative value/range choices; 1716 (2) the enumeration of named-values may be refined by removing one or 1717 more named-values (note that for BITS, a refinement may cause the 1718 enumerations to no longer be contiguous); or, 1720 (3) the size in octets of the value may be refined by raising the 1721 lower-bounds, by reducing the upper-bounds, and/or by reducing the 1722 alternative size choices. 1724 No other types of refinements can be specified in the SYNTAX clause. 1725 However, the DESCRIPTION clause is available to specify additional 1726 restrictions which can not be expressed in the SYNTAX clause. Further 1727 details on (and examples of) sub-typing are provided in Appendix A. 1729 Draft SMIv2 January 1999 1731 10. Extending an Information Module 1733 As experience is gained with an information module, it may be desirable 1734 to revise that information module. However, changes are not allowed if 1735 they have any potential to cause interoperability problems "over the 1736 wire" between an implementation using an original specification and an 1737 implementation using an updated specification(s). 1739 For any change, the invocation of the MODULE-IDENTITY macro must be 1740 updated to include information about the revision: specifically, 1741 updating the LAST-UPDATED clause, adding a pair of REVISION and 1742 DESCRIPTION clauses (see section 5.5), and making any necessary changes 1743 to existing clauses, including the ORGANIZATION and CONTACT-INFO 1744 clauses. 1746 Note that any definition contained in an information module is available 1747 to be IMPORT-ed by any other information module, and is referenced in an 1748 IMPORTS clause via the module name. Thus, a module name should not be 1749 changed. Specifically, the module name (e.g., "FIZBIN-MIB" in the 1750 example of Section 5.7) should not be changed when revising an 1751 information module (except to correct typographical errors), and 1752 definitions should not be moved from one information module to another. 1754 Also note that obsolete definitions must not be removed from MIB modules 1755 since their descriptors may still be referenced by other information 1756 modules, and the OBJECT IDENTIFIERs used to name them must never be re- 1757 assigned. 1759 10.1. Object Assignments 1761 If any non-editorial change is made to any clause of a object 1762 assignment, then the OBJECT IDENTIFIER value associated with that object 1763 assignment must also be changed, along with its associated descriptor. 1765 10.2. Object Definitions 1767 An object definition may be revised in any of the following ways: 1769 (1) A SYNTAX clause containing an enumerated INTEGER may have new 1770 enumerations added or existing labels changed. Similarly, named 1771 bits may be added or existing labels changed for the BITS 1772 construct. 1774 Draft SMIv2 January 1999 1776 (2) The value of a SYNTAX clause may be replaced by a textual 1777 convention, providing the textual convention is defined to use the 1778 same primitive ASN.1 type, has the same set of values, and has 1779 identical semantics. 1781 (3) A STATUS clause value of "current" may be revised as "deprecated" 1782 or "obsolete". Similarly, a STATUS clause value of "deprecated" 1783 may be revised as "obsolete". When making such a change, the 1784 DESCRIPTION clause should be updated to explain the rationale. 1786 (4) A DEFVAL clause may be added or updated. 1788 (5) A REFERENCE clause may be added or updated. 1790 (6) A UNITS clause may be added. 1792 (7) A conceptual row may be augmented by adding new columnar objects at 1793 the end of the row, and making the corresponding update to the 1794 SEQUENCE definition. 1796 (8) Clarifications and additional information may be included in the 1797 DESCRIPTION clause. 1799 (9) Entirely new objects may be defined, named with previously 1800 unassigned OBJECT IDENTIFIER values. 1802 Otherwise, if the semantics of any previously defined object are changed 1803 (i.e., if a non-editorial change is made to any clause other than those 1804 specifically allowed above), then the OBJECT IDENTIFIER value associated 1805 with that object must also be changed. 1807 Note that changing the descriptor associated with an existing object is 1808 considered a semantic change, as these strings may be used in an IMPORTS 1809 statement. 1811 10.3. Notification Definitions 1813 A notification definition may be revised in any of the following ways: 1815 (1) A REFERENCE clause may be added or updated. 1817 (2) A STATUS clause value of "current" may be revised as "deprecated" 1818 or "obsolete". Similarly, a STATUS clause value of "deprecated" 1819 may be revised as "obsolete". When making such a change, the 1821 Draft SMIv2 January 1999 1823 DESCRIPTION clause should be updated to explain the rationale. 1825 (3) A DESCRIPTION clause may be clarified. 1827 Otherwise, if the semantics of any previously defined notification are 1828 changed (i.e., if a non-editorial change is made to any clause other 1829 those specifically allowed above), then the OBJECT IDENTIFIER value 1830 associated with that notification must also be changed. 1832 Note that changing the descriptor associated with an existing 1833 notification is considered a semantic change, as these strings may be 1834 used in an IMPORTS statement. 1836 Draft SMIv2 January 1999 1838 11. Appendix A: Detailed Sub-typing Rules 1840 11.1. Syntax Rules 1842 The syntax rules for sub-typing are given below. Note that while this 1843 syntax is based on ASN.1, it includes some extensions beyond what is 1844 allowed in ASN.1, and a number of ASN.1 constructs are not allowed by 1845 this syntax. 1847 1848 ::= 1849 | "(" ["|" ]... ")" 1851 1852 ::= 1853 | "(" "SIZE" "(" ["|" ]... ")" ")" 1855 1856 ::= 1857 | ".." 1859 1860 ::= "-" 1861 | 1862 | 1863 | 1865 where: 1866 is the empty string 1867 is a non-negative integer 1868 is a hexadecimal string (e.g., 'xxxx'H) 1869 is a binary string (e.g, 'xxxx'B) 1871 is further restricted as follows: 1872 - any used in a SIZE clause must be non-negative. 1873 - when a pair of values is specified, the first value 1874 must be less than the second value. 1875 - when multiple ranges are specified, the ranges may 1876 not overlap but may touch. For example, (1..4 | 4..9) 1877 is invalid, and (1..4 | 5..9) is valid. 1878 - the ranges must be a subset of the maximum range of the 1879 base type. 1881 Draft SMIv2 January 1999 1883 11.2. Examples 1885 Some examples of legal sub-typing: 1887 Integer32 (-20..100) 1888 Integer32 (0..100 | 300..500) 1889 Integer32 (300..500 | 0..100) 1890 Integer32 (0 | 2 | 4 | 6 | 8 | 10) 1891 OCTET STRING (SIZE(0..100)) 1892 OCTET STRING (SIZE(0..100 | 300..500)) 1893 OCTET STRING (SIZE(0 | 2 | 4 | 6 | 8 | 10)) 1894 SYNTAX TimeInterval (0..100) 1895 SYNTAX DisplayString (SIZE(0..32)) 1897 (Note the last two examples above are not valid in a TEXTUAL CONVENTION, 1898 see [3].) 1900 Some examples of illegal sub-typing: 1902 Integer32 (150..100) -- first greater than second 1903 Integer32 (0..100 | 50..500) -- ranges overlap 1904 Integer32 (0 | 2 | 0 ) -- value duplicated 1905 Integer32 (MIN..-1 | 1..MAX) -- MIN and MAX not allowed 1906 Integer32 (SIZE (0..34)) -- must not use SIZE 1907 OCTET STRING (0..100) -- must use SIZE 1908 OCTET STRING (SIZE(-10..100)) -- negative SIZE 1910 Draft SMIv2 January 1999 1912 12. Security Considerations 1914 This document defines a language with which to write and read 1915 descriptions of management information. The language itself has no 1916 security impact on the Internet. 1918 13. Editors' Addresses 1920 Keith McCloghrie 1921 Cisco Systems, Inc. 1922 170 West Tasman Drive 1923 San Jose, CA 95134-1706 1924 USA 1925 Phone: +1 408 526 5260 1926 Email: kzm@cisco.com 1928 David Perkins 1929 Desktalk Systems & SNMPinfo 1930 3763 Benton Street 1931 Santa Clara, CA 95051 1932 USA 1933 Phone: +1 408 221-8702 1934 Email: dperkins@snmpinfo.com 1936 Juergen Schoenwaelder 1937 TU Braunschweig 1938 Bueltenweg 74/75 1939 38106 Braunschweig 1940 Germany 1941 Phone: +49 531 391-3283 1942 Email: schoenw@ibr.cs.tu-bs.de 1944 Draft SMIv2 January 1999 1946 14. References 1948 [1] Information processing systems - Open Systems Interconnection - 1949 Specification of Abstract Syntax Notation One (ASN.1), 1950 International Organization for Standardization. International 1951 Standard 8824, (December, 1987). 1953 [2] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 1954 and Waldbusser, S. "Conformance Statements for SMIv2", draft-ops- 1955 smiv2-conf-01.txt, January 1999. 1957 [3] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 1958 and Waldbusser, S. "Textual Conventions for SMIv2", draft-ops- 1959 smiv2-tc-01.txt, January 1999. 1961 [4] Information processing systems - Open Systems Interconnection - 1962 Specification of Basic Encoding Rules for Abstract Syntax Notation 1963 One (ASN.1), International Organization for Standardization. 1964 International Standard 8825, (December, 1987). 1966 [5] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1967 Waldbusser, S., "Management Information Base for Version 2 of the 1968 Simple Network Management Protocol (SNMPv2)", RFC 1907, January 1969 1996. 1971 [6] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 1972 Waldbusser, S., "Protocol Operations for Version 2 of the Simple 1973 Network Management Protocol (SNMPv2)", RFC 1905, January 1996. 1975 Draft SMIv2 January 1999 1977 15. Full Copyright Statement 1979 Copyright (C) The Internet Society (1999). All Rights Reserved. 1981 This document and translations of it may be copied and furnished to 1982 others, and derivative works that comment on or otherwise explain it or 1983 assist in its implementation may be prepared, copied, published and 1984 distributed, in whole or in part, without restriction of any kind, 1985 provided that the above copyright notice and this paragraph are included 1986 on all such copies and derivative works. However, this document itself 1987 may not be modified in any way, such as by removing the copyright notice 1988 or references to the Internet Society or other Internet organizations, 1989 except as needed for the purpose of developing Internet standards in 1990 which case the procedures for copyrights defined in the Internet 1991 Standards process must be followed, or as required to translate it into 1992 languages other than English. 1994 The limited permissions granted above are perpetual and will not be 1995 revoked by the Internet Society or its successors or assigns. 1997 This document and the information contained herein is provided on an "AS 1998 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 1999 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 2000 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 2001 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 2002 FITNESS FOR A PARTICULAR PURPOSE." 2004 Draft SMIv2 January 1999 2006 Table of Contents 2008 1 Introduction .................................................... 2 2009 1.1 A Note on Terminology ......................................... 2 2010 2 Definitions ..................................................... 3 2011 3.1 The MODULE-IDENTITY macro ..................................... 4 2012 3.2 Object Names and Syntaxes ..................................... 7 2013 3.3 The OBJECT-TYPE macro ......................................... 10 2014 3.5 The NOTIFICATION-TYPE macro ................................... 12 2015 3.6 Administrative Identifiers .................................... 12 2016 3 Information Modules ............................................. 13 2017 3.1 Macro Invocation .............................................. 14 2018 3.1.1 Textual Values and Strings .................................. 15 2019 3.2 IMPORTing Symbols ............................................. 15 2020 3.3 Exporting Symbols ............................................. 16 2021 3.4 ASN.1 Comments ................................................ 16 2022 3.5 OBJECT IDENTIFIER values ...................................... 16 2023 3.6 OBJECT IDENTIFIER usage ....................................... 17 2024 3.7 Reserved Keywords ............................................. 18 2025 4 Naming Hierarchy ................................................ 19 2026 5 Mapping of the MODULE-IDENTITY macro ............................ 20 2027 5.1 Mapping of the LAST-UPDATED clause ............................ 20 2028 5.2 Mapping of the ORGANIZATION clause ............................ 20 2029 5.3 Mapping of the CONTACT-INFO clause ............................ 20 2030 5.4 Mapping of the DESCRIPTION clause ............................. 20 2031 5.5 Mapping of the REVISION clause ................................ 20 2032 5.5.1 Mapping of the DESCRIPTION sub-clause ....................... 21 2033 5.6 Mapping of the MODULE-IDENTITY value .......................... 21 2034 5.7 Usage Example ................................................. 22 2035 6 Mapping of the OBJECT-IDENTITY macro ............................ 23 2036 6.1 Mapping of the STATUS clause .................................. 23 2037 6.2 Mapping of the DESCRIPTION clause ............................. 23 2038 6.3 Mapping of the REFERENCE clause ............................... 23 2039 6.4 Mapping of the OBJECT-IDENTITY value .......................... 23 2040 6.5 Usage Example ................................................. 24 2041 7 Mapping of the OBJECT-TYPE macro ................................ 25 2042 7.1 Mapping of the SYNTAX clause .................................. 25 2043 7.1.1 Integer32 and INTEGER ....................................... 25 2044 7.1.2 OCTET STRING ................................................ 26 2045 7.1.3 OBJECT IDENTIFIER ........................................... 26 2046 7.1.4 The BITS construct .......................................... 26 2047 7.1.5 IpAddress ................................................... 27 2048 7.1.6 Counter32 ................................................... 27 2049 7.1.7 Gauge32 ..................................................... 28 2051 Draft SMIv2 January 1999 2053 7.1.8 TimeTicks ................................................... 28 2054 7.1.9 Opaque ...................................................... 28 2055 7.1.10 Counter64 .................................................. 29 2056 7.1.11 Unsigned32 ................................................. 29 2057 7.1.12 Conceptual Tables .......................................... 30 2058 7.1.12.1 Creation and Deletion of Conceptual Rows ................. 30 2059 7.2 Mapping of the UNITS clause ................................... 31 2060 7.3 Mapping of the MAX-ACCESS clause .............................. 31 2061 7.4 Mapping of the STATUS clause .................................. 31 2062 7.5 Mapping of the DESCRIPTION clause ............................. 32 2063 7.6 Mapping of the REFERENCE clause ............................... 32 2064 7.7 Mapping of the INDEX clause ................................... 32 2065 7.8 Mapping of the AUGMENTS clause ................................ 34 2066 7.8.1 Relation between INDEX and AUGMENTS clauses ................. 35 2067 7.9 Mapping of the DEFVAL clause .................................. 35 2068 7.10 Mapping of the OBJECT-TYPE value ............................. 36 2069 7.11 Usage Example ................................................ 38 2070 8 Mapping of the NOTIFICATION-TYPE macro .......................... 40 2071 8.1 Mapping of the OBJECTS clause ................................. 40 2072 8.2 Mapping of the STATUS clause .................................. 40 2073 8.3 Mapping of the DESCRIPTION clause ............................. 41 2074 8.4 Mapping of the REFERENCE clause ............................... 41 2075 8.5 Mapping of the NOTIFICATION-TYPE value ........................ 41 2076 8.6 Usage Example ................................................. 42 2077 9 Refined Syntax .................................................. 43 2078 10 Extending an Information Module ................................ 44 2079 10.1 Object Assignments ........................................... 44 2080 10.2 Object Definitions ........................................... 44 2081 10.3 Notification Definitions ..................................... 45 2082 11 Appendix A: Detailed Sub-typing Rules .......................... 47 2083 11.1 Syntax Rules ................................................. 47 2084 11.2 Examples ..................................................... 48 2085 12 Security Considerations ........................................ 49 2086 13 Editors' Addresses ............................................. 49 2087 14 References ..................................................... 50 2088 15 Full Copyright Statement ....................................... 51