idnits 2.17.1 draft-ietf-snmpv2-smi-ds-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 are 27 instances of too long lines in the document, the longest one being 3 characters 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 919: '... (the DEFAULT and OPTIONAL clauses are...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1179 has weird spacing: '...-valued final...' == Line 1360 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 (September 1995) is 10451 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: 'UNIVERSAL 2' on line 203 -- Looks like a reference, but probably isn't: 'APPLICATION 0' on line 232 -- Looks like a reference, but probably isn't: 'APPLICATION 1' on line 237 -- Looks like a reference, but probably isn't: 'APPLICATION 2' on line 248 -- Looks like a reference, but probably isn't: 'APPLICATION 3' on line 253 -- Looks like a reference, but probably isn't: 'APPLICATION 4' on line 258 -- Looks like a reference, but probably isn't: 'APPLICATION 6' on line 263 -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft SMI for SNMPv2 September 1995 4 Structure of Management Information 5 for Version 2 of the 6 Simple Network Management Protocol (SNMPv2) 8 25 September 1995 | 10 draft-ietf-snmpv2-smi-ds-04.txt | 12 Keith McCloghrie 13 Editor + 14 Cisco Systems, Inc. 15 kzm@cisco.com 17 Status of this Memo - 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, and 21 its working groups. Note that other groups may also distribute working 22 documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference material 27 or to cite them other than as ``work in progress.'' 29 To learn the current status of any Internet-Draft, please check the 30 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 31 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 32 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 34 1. Introduction 36 A management system contains: several (potentially many) nodes, each 37 with a processing entity, termed an agent, which has access to 38 management instrumentation; at least one management station; and, a 39 management protocol, used to convey management information between the 40 agents and management stations. Operations of the protocol are carried 41 out under an administrative framework which defines authentication, 42 authorization, access control, and privacy policies. 44 Management stations execute management applications which monitor and 45 control managed elements. Managed elements are devices such as hosts, 46 routers, terminal servers, etc., which are monitored and controlled via 47 access to their management information. 49 Management information is viewed as a collection of managed objects, 50 residing in a virtual information store, termed the Management 51 Information Base (MIB). Collections of related objects are defined in 52 MIB modules. These modules are written using an adapted subset of OSI's 53 Abstract Syntax Notation One (ASN.1) [1]. It is the purpose of this 54 document, the Structure of Management Information (SMI), to define that 55 adapted subset, and to assign a set of associated administrative 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 Internet-standard Network 76 Management Framework, as described in RFCs 1155, 1157, and 1212, is 77 termed the SNMP version 1 framework (SNMPv1). The current framework is | 78 termed the SNMP version 2 framework (SNMPv2), as described in [8]. | 79 2. Definitions 81 SNMPv2-SMI DEFINITIONS ::= BEGIN 83 -- the path to the root 85 org OBJECT IDENTIFIER ::= { iso 3 } 86 dod OBJECT IDENTIFIER ::= { org 6 } 87 internet OBJECT IDENTIFIER ::= { dod 1 } 89 directory OBJECT IDENTIFIER ::= { internet 1 } 91 mgmt OBJECT IDENTIFIER ::= { internet 2 } 92 mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } 93 transmission OBJECT IDENTIFIER ::= { mib-2 10 } 95 experimental OBJECT IDENTIFIER ::= { internet 3 } 97 private OBJECT IDENTIFIER ::= { internet 4 } 98 enterprises OBJECT IDENTIFIER ::= { private 1 } 100 security OBJECT IDENTIFIER ::= { internet 5 } 102 snmpV2 OBJECT IDENTIFIER ::= { internet 6 } 104 -- transport domains 105 snmpDomains OBJECT IDENTIFIER ::= { snmpV2 1 } 107 -- transport proxies 108 snmpProxys OBJECT IDENTIFIER ::= { snmpV2 2 } 110 -- module identities 111 snmpModules OBJECT IDENTIFIER ::= { snmpV2 3 } 112 -- definitions for information modules 114 MODULE-IDENTITY MACRO ::= 115 BEGIN 116 TYPE NOTATION ::= 117 "LAST-UPDATED" value(Update UTCTime) 118 "ORGANIZATION" Text 119 "CONTACT-INFO" Text 120 "DESCRIPTION" Text 121 RevisionPart 123 VALUE NOTATION ::= 124 value(VALUE OBJECT IDENTIFIER) 126 RevisionPart ::= 127 Revisions 128 | empty 129 Revisions ::= 130 Revision 131 | Revisions Revision 132 Revision ::= 133 "REVISION" value(Update UTCTime) 134 "DESCRIPTION" Text 136 -- uses the NVT ASCII character set 137 Text ::= """" string """" 138 END 139 OBJECT-IDENTITY MACRO ::= 140 BEGIN 141 TYPE NOTATION ::= 142 "STATUS" Status 143 "DESCRIPTION" Text 144 ReferPart 146 VALUE NOTATION ::= 147 value(VALUE OBJECT IDENTIFIER) 149 Status ::= 150 "current" 151 | "deprecated" 152 | "obsolete" 154 ReferPart ::= 155 "REFERENCE" Text 156 | empty 158 Text ::= """" string """" 159 END 160 -- names of objects 162 ObjectName ::= 163 OBJECT IDENTIFIER 165 NotificationName ::= 166 OBJECT IDENTIFIER 168 -- syntax of objects 170 ObjectSyntax ::= 171 CHOICE { 172 simple 173 SimpleSyntax, 175 -- note that SEQUENCEs for conceptual tables and 176 -- rows are not mentioned here... 178 application-wide 179 ApplicationSyntax 180 } 182 -- built-in ASN.1 types 184 SimpleSyntax ::= 185 CHOICE { 186 -- INTEGERs with a more restrictive range 187 -- may also be used 188 integer-value -- includes Integer32 189 INTEGER (-2147483648..2147483647), 191 -- OCTET STRINGs with a more restrictive size 192 -- may also be used 193 string-value 194 OCTET STRING (SIZE (0..65535)), 196 objectID-value 197 OBJECT IDENTIFIER 198 } 200 -- indistinguishable from INTEGER, but never needs more than 201 -- 32-bits for a two's complement representation 202 Integer32 ::= 203 [UNIVERSAL 2] 204 IMPLICIT INTEGER (-2147483648..2147483647) 206 -- application-wide types 208 ApplicationSyntax ::= 209 CHOICE { 210 ipAddress-value 211 IpAddress, 213 counter-value 214 Counter32, 216 timeticks-value 217 TimeTicks, 219 arbitrary-value 220 Opaque, 222 big-counter-value 223 Counter64, 225 unsigned-integer-value -- includes Gauge32 - 226 Unsigned32 227 } 229 -- in network-byte order 230 -- (this is a tagged type for historical reasons) 231 IpAddress ::= 232 [APPLICATION 0] 233 IMPLICIT OCTET STRING (SIZE (4)) 235 -- this wraps 236 Counter32 ::= 237 [APPLICATION 1] 238 IMPLICIT INTEGER (0..4294967295) 240 -- this doesn't wrap 241 Gauge32 ::= 242 [APPLICATION 2] 243 IMPLICIT INTEGER (0..4294967295) 245 -- an unsigned 32-bit quantity 246 -- indistinguishable from Gauge32 247 Unsigned32 ::= 248 [APPLICATION 2] 249 IMPLICIT INTEGER (0..4294967295) 251 -- hundredths of seconds since an epoch 252 TimeTicks ::= 253 [APPLICATION 3] 254 IMPLICIT INTEGER (0..4294967295) 256 -- for backward-compatibility only 257 Opaque ::= 258 [APPLICATION 4] 259 IMPLICIT OCTET STRING 261 -- for counters that wrap in less than one hour with only 32 bits 262 Counter64 ::= 263 [APPLICATION 6] 264 IMPLICIT INTEGER (0..18446744073709551615) 266 -- definition for objects - 268 OBJECT-TYPE MACRO ::= 269 BEGIN 270 TYPE NOTATION ::= 271 "SYNTAX" Syntax 272 UnitsPart 273 "MAX-ACCESS" Access 274 "STATUS" Status 275 "DESCRIPTION" Text 276 ReferPart 277 IndexPart 278 DefValPart 280 VALUE NOTATION ::= 281 value(VALUE ObjectName) 283 Syntax ::= 284 type(ObjectSyntax) 285 | "BITS" "{" Kibbles "}" 286 Kibbles ::= 287 Kibble 288 | Kibbles "," Kibble 289 Kibble ::= 290 identifier "(" nonNegativeNumber ")" 292 UnitsPart ::= 293 "UNITS" Text 294 | empty 296 Access ::= 297 "not-accessible" 298 | "accessible-for-notify" 299 | "read-only" 300 | "read-write" 301 | "read-create" 303 Status ::= 304 "current" 305 | "deprecated" 306 | "obsolete" 308 ReferPart ::= 309 "REFERENCE" Text 310 | empty 312 IndexPart ::= 313 "INDEX" "{" IndexTypes "}" 314 | "AUGMENTS" "{" Entry "}" 315 | empty 316 IndexTypes ::= 317 IndexType 318 | IndexTypes "," IndexType 319 IndexType ::= 320 "IMPLIED" Index 321 | Index 322 Index ::= 323 -- use the SYNTAX value of the 324 -- correspondent OBJECT-TYPE invocation 325 value(Indexobject ObjectName) 326 Entry ::= 327 -- use the INDEX value of the 328 -- correspondent OBJECT-TYPE invocation 329 value(Entryobject ObjectName) 331 DefValPart ::= 332 "DEFVAL" "{" value(Defval Syntax) "}" 333 | empty 335 -- uses the NVT ASCII character set 336 Text ::= """" string """" 337 END 338 -- definitions for notifications 340 NOTIFICATION-TYPE MACRO ::= 341 BEGIN 342 TYPE NOTATION ::= 343 ObjectsPart 344 "STATUS" Status 345 "DESCRIPTION" Text 346 ReferPart 348 VALUE NOTATION ::= 349 value(VALUE NotificationName) 351 ObjectsPart ::= 352 "OBJECTS" "{" Objects "}" 353 | empty 354 Objects ::= 355 Object 356 | Objects "," Object 357 Object ::= 358 value(Name ObjectName) 360 Status ::= 361 "current" 362 | "deprecated" 363 | "obsolete" 365 ReferPart ::= 366 "REFERENCE" Text 367 | empty 369 -- uses the NVT ASCII character set 370 Text ::= """" string """" 371 END 373 -- definitions of administrative identifiers 375 zeroDotZero OBJECT-IDENTITY 376 STATUS current 377 DESCRIPTION 378 "A value used for null identifiers." 379 ::= { 0 0 } 381 END 382 3. Information Modules 384 An "information module" is an ASN.1 module defining information relating 385 to network management. 387 The SMI describes how to use a subset of ASN.1 to define an information 388 module. Further, additional restrictions are placed on "standard" 389 information modules. It is strongly recommended that "enterprise- 390 specific" information modules also adhere to these restrictions. 392 Typically, there are three kinds of information modules: 394 (1) MIB modules, which contain definitions of inter-related managed 395 objects, make use of the OBJECT-TYPE and NOTIFICATION-TYPE macros; 397 (2) compliance statements for MIB modules, which make use of the 398 MODULE-COMPLIANCE and OBJECT-GROUP macros [2]; and, 400 (3) capability statements for agent implementations which make use of 401 the AGENT-CAPABILITIES macros [2]. 403 This classification scheme does not imply a rigid taxonomy. For 404 example, a "standard" information module will normally include 405 definitions of managed objects and a compliance statement. Similarly, 406 an "enterprise-specific" information module might include definitions of 407 managed objects and a capability statement. Of course, a "standard" 408 information module may not contain capability statements. 410 The constructs of ASN.1 allowed in SNMPv2 information modules include: 411 the IMPORTS clause, value definitions for OBJECT IDENTIFIERs, type 412 definitions for SEQUENCEs (with restrictions), ASN.1 type assignments of 413 the restricted ASN.1 types allowed in SNMPv2, and instances of ASN.1 414 macros defined in this document and in other documents [2, 3] of the 415 SNMPv2 framework. Additional ASN.1 macros may not be defined in SNMPv2 416 information modules. 418 The names of all standard information modules must be unique (but 419 different versions of the same information module should have the same 420 name). Developers of enterprise information modules are encouraged to 421 choose names for their information modules that will have a low 422 probability of colliding with standard or other enterprise information 423 modules. An information module may not use the ASN.1 construct of 424 placing an object identifier value between the module name and the 425 "DEFINITIONS" keyword. 427 All information modules start with exactly one invocation of the 428 MODULE-IDENTITY macro, which provides contact information as well as 429 revision history to distinguish between versions of the same information 430 module. This invocation must appear immediately after any IMPORTs 431 statements. 433 3.1. Macro Invocation 435 Within an information module, each macro invocation appears as: 437 ::= 439 where corresponds to an ASN.1 identifier, names the 440 macro being invoked, and and depend on the definition 441 of the macro. (Note that this definition of a descriptor applies to all 442 macros defined in this memo and in [2].) 444 For the purposes of this specification, an ASN.1 identifier consists of 445 one or more letters or digits, and its initial character must be a 446 lower-case letter. (Note that hyphens are not allowed by this 447 specification, even though hyphen is allowed by [1]. This restriction 448 enables arithmetic expressions in languages which use the minus sign to 449 reference these descriptors without ambiguity.) 451 For all descriptors appearing in an information module, the descriptor 452 shall be unique and mnemonic, and shall not exceed 64 characters in 453 length. (However, descriptors longer than 32 characters are not 454 recommended.) This promotes a common language for humans to use when 455 discussing the information module and also facilitates simple table 456 mappings for user-interfaces. 458 The set of descriptors defined in all "standard" information modules 459 shall be unique. 461 Finally, by convention, if the descriptor refers to an object with a 462 SYNTAX clause value of either Counter32 or Counter64, then the 463 descriptor used for the object should denote plurality. 465 3.1.1. Textual Clauses 467 Some clauses in a macro invocation may take a textual value (e.g., the 468 DESCRIPTION clause). Note that, in order to conform to the ASN.1 469 syntax, the entire value of these clauses must be enclosed in double 470 quotation marks, and therefore cannot itself contain double quotation 471 marks, although the value may be multi-line. 473 3.2. IMPORTing Symbols 475 To reference an external object, the IMPORTS statement must be used to 476 identify both the descriptor and the module in which the descriptor is 477 defined, where the module is identified by its ASN.1 module name. 479 Note that when symbols from "enterprise-specific" information modules 480 are referenced (e.g., a descriptor), there is the possibility of 481 collision. As such, if different objects with the same descriptor are 482 IMPORTed, then this ambiguity is resolved by prefixing the descriptor 483 with the name of the information module and a dot ("."), i.e., 485 "module.descriptor" 487 (All descriptors must be unique within any information module.) 489 Of course, this notation can be used even when there is no collision 490 when IMPORTing symbols. 492 Finally, the IMPORTS statement may not be used to import an ASN.1 named 493 type which corresponds to either the SEQUENCE or SEQUENCE OF type. 495 3.3. Exporting Symbols 497 The ASN.1 EXPORTS statement is not allowed in SNMPv2 information 498 modules. All items defined in an information module are automatically 499 exported. 501 3.4. ASN.1 Comments 503 Comments in ASN.1 commence with a pair of adjacent hyphens and end with 504 the next pair of adjacent hyphens or at the end of the line, whichever 505 occurs first. 507 3.5. OBJECT IDENTIFIER values 509 An OBJECT IDENTIFIER value is an ordered list of non-negative numbers. 510 For the SNMPv2 framework, each number in the list is referred to as a 511 sub-identifier, there are at most 128 sub-identifiers in a value, and 512 each sub-identifier has a maximum value of 2^32-1 (4294967295 decimal). 513 All OBJECT IDENTIFIER values have at least two sub-identifiers, where 514 the value of the first sub-identifier is one of the following well-known 515 names: 517 Value Name 518 0 ccitt 519 1 iso 520 2 joint-iso-ccitt 522 4. Naming Hierarchy 524 The root of the subtree administered by the Internet Assigned Numbers 525 Authority (IANA) for the Internet is: 527 internet OBJECT IDENTIFIER ::= { iso 3 6 1 } 529 That is, the Internet subtree of OBJECT IDENTIFIERs starts with the 530 prefix: 532 1.3.6.1. 534 Several branches underneath this subtree are used for network 535 management: 537 mgmt OBJECT IDENTIFIER ::= { internet 2 } 538 experimental OBJECT IDENTIFIER ::= { internet 3 } 539 private OBJECT IDENTIFIER ::= { internet 4 } 540 enterprises OBJECT IDENTIFIER ::= { private 1 } 542 However, the SMI does not prohibit the definition of objects in other 543 portions of the object tree. 545 The mgmt(2) subtree is used to identify "standard" objects. 547 The experimental(3) subtree is used to identify objects being designed 548 by working groups of the IETF. If an information module produced by a 549 working group becomes a "standard" information module, then at the very 550 beginning of its entry onto the Internet standards track, the objects 551 are moved under the mgmt(2) subtree. 553 The private(4) subtree is used to identify objects defined unilaterally. 554 The enterprises(1) subtree beneath private is used, among other things, 555 to permit providers of networking subsystems to register models of their 556 products. 558 5. Mapping of the MODULE-IDENTITY macro 560 The MODULE-IDENTITY macro is used to provide contact and revision 561 history for each information module. It must appear exactly once in 562 every information module. It should be noted that the expansion of the 563 MODULE-IDENTITY macro is something which conceptually happens during 564 implementation and not during run-time. 566 Note that reference in an IMPORTS clause or in clauses of SNMPv2 macros 567 to an information module is NOT through the use of the 'descriptor' of a 568 MODULE-IDENTITY macro; rather, an information module is referenced 569 through specifying its module name. 571 5.1. Mapping of the LAST-UPDATED clause 573 The LAST-UPDATED clause, which must be present, contains the date and 574 time that this information module was last edited. The date and time 575 are represented in UTC Time format (see Appendix B). 577 5.2. Mapping of the ORGANIZATION clause 579 The ORGANIZATION clause, which must be present, contains a textual 580 description of the organization under whose auspices this information 581 module was developed. 583 5.3. Mapping of the CONTACT-INFO clause 585 The CONTACT-INFO clause, which must be present, contains the name, 586 postal address, telephone number, and electronic mail address of the 587 person to whom technical queries concerning this information module 588 should be sent. 590 5.4. Mapping of the DESCRIPTION clause 592 The DESCRIPTION clause, which must be present, contains a high-level 593 textual description of the contents of this information module. 595 5.5. Mapping of the REVISION clause 597 The REVISION clause, which need not be present, is repeatedly used to 598 describe the revisions (including the initial version) made to this 599 information module, in reverse chronological order (i.e., most recent 600 first). Each instance of this clause contains the date and time of the 601 revision. The date and time are represented in UTC Time format (see 602 Appendix B). 604 5.5.1. Mapping of the DESCRIPTION sub-clause 606 The DESCRIPTION clause, which must be present for each REVISION clause, 607 contains a high-level textual description of the revision identified in 608 that REVISION clause. 610 5.6. Mapping of the MODULE-IDENTITY value 612 The value of an invocation of the MODULE-IDENTITY macro is an OBJECT 613 IDENTIFIER. As such, this value may be authoritatively used when 614 specifying an OBJECT IDENTIFIER value to refer to the information module 615 containing the invocation. 617 5.7. Usage Example 619 Consider how a skeletal MIB module might be constructed: e.g., 621 FIZBIN-MIB DEFINITIONS ::= BEGIN 623 IMPORTS 624 MODULE-IDENTITY, OBJECT-TYPE, experimental 625 FROM SNMPv2-SMI; 627 fizbin MODULE-IDENTITY 628 LAST-UPDATED "9505241811Z" 629 ORGANIZATION "IETF SNMPv2 Working Group" 630 CONTACT-INFO 631 " Marshall T. Rose 633 Postal: Dover Beach Consulting, Inc. 634 420 Whisman Court 635 Mountain View, CA 94043-2186 636 US 638 Tel: +1 415 968 1052 639 Fax: +1 415 968 2510 641 E-mail: mrose@dbc.mtview.ca.us" 642 DESCRIPTION 643 "The MIB module for entities implementing the xxxx 644 protocol." 645 REVISION "9505241811Z" 646 DESCRIPTION 647 "The latest version of this MIB module." 648 REVISION "9210070433Z" 649 DESCRIPTION 650 "The initial version of this MIB module." 651 -- contact IANA for actual number 652 ::= { experimental xx } 654 END 655 6. Mapping of the OBJECT-IDENTITY macro 657 The OBJECT-IDENTITY macro is used to define information about an OBJECT 658 IDENTIFIER assignment. All administrative OBJECT IDENTIFIER assignments 659 which define a type identification value (see AutonomousType, a textual 660 convention defined in [3]) should be defined via the OBJECT-IDENTITY 661 macro. It should be noted that the expansion of the OBJECT-IDENTITY 662 macro is something which conceptually happens during implementation and 663 not during run-time. 665 6.1. Mapping of the STATUS clause 667 The STATUS clause, which must be present, indicates whether this 668 definition is current or historic. 670 The values "current", and "obsolete" are self-explanatory. The 671 "deprecated" value indicates that the definition is obsolete, but that 672 an implementor may wish to support it to foster interoperability with 673 older implementations. 675 6.2. Mapping of the DESCRIPTION clause 677 The DESCRIPTION clause, which must be present, contains a textual 678 description of the object assignment. 680 6.3. Mapping of the REFERENCE clause 682 The REFERENCE clause, which need not be present, contains a textual 683 cross-reference to an object assignment defined in some other 684 information module. 686 6.4. Mapping of the OBJECT-IDENTITY value 688 The value of an invocation of the OBJECT-IDENTITY macro is an OBJECT 689 IDENTIFIER. 691 6.5. Usage Example 693 Consider how an OBJECT IDENTIFIER assignment might be made: e.g., 695 fizbin69 OBJECT-IDENTITY 696 STATUS current 697 DESCRIPTION 698 "The authoritative identity of the Fizbin 69 chipset." 699 ::= { fizbinChipSets 1 } 701 7. Mapping of the OBJECT-TYPE macro 703 The OBJECT-TYPE macro is used to define a type of managed object. It 704 should be noted that the expansion of the OBJECT-TYPE macro is something 705 which conceptually happens during implementation and not during run- 706 time. 708 For leaf objects which are not columnar objects (i.e., not contained 709 within a conceptual table), instances of the object are identified by 710 appending a sub-identifier of zero to the name of that object. 711 Otherwise, the INDEX clause of the conceptual row object superior to a 712 columnar object defines instance identification information. 714 7.1. Mapping of the SYNTAX clause 716 The SYNTAX clause, which must be present, defines the abstract data 717 structure corresponding to that object. The data structure must be one 718 of the following: a base type, the BITS construct, or a textual 719 convention. (SEQUENCE OF and SEQUENCE are also possible for conceptual 720 tables, see section 7.1.12). The base types are those defined in the 721 ObjectSyntax CHOICE. A textual convention is a newly-defined type 722 defined as a sub-type of a base type [3]. 724 A extended subset of the full capabilities of ASN.1 sub-typing is 725 allowed, as appropriate to the underingly ASN.1 type. Any such 726 restriction on size, range, enumerations or repertoire specified in this 727 clause represents the maximal level of support which makes "protocol 728 sense". Restrictions on sub-typing are specified in detail in Section 9 729 and Appendix C of this memo. 731 The semantics of ObjectSyntax are now described. 733 7.1.1. Integer32 and INTEGER 735 The Integer32 type represents integer-valued information between -2^31 736 and 2^31-1 inclusive (-2147483648 to 2147483647 decimal). This type is 737 indistinguishable from the INTEGER type. Both the INTEGER and Integer32 738 types may be sub-typed to be more constrained than the Integer32 type. 740 The INTEGER type may also be used to represent integer-valued 741 information as named-number enumerations. In this case, only those 742 named-numbers so enumerated may be present as a value. Note that 743 although it is recommended that enumerated values start at 1 and be 744 numbered contiguously, any valid value for Integer32 is allowed for an 745 enumerated value and, further, enumerated values needn't be contiguously 746 assigned. 748 Finally, a label for a named-number enumeration must consist of one or 749 more letters or digits (no hyphens), up to a maximum of 64 characters, 750 and the initial character must be a lower-case letter. (However, labels 751 longer than 32 characters are not recommended.) 753 7.1.2. OCTET STRING 755 The OCTET STRING type represents arbitrary binary or textual data. 756 Although there is no SMI-specified size limitation for this type, MIB 757 designers should realize that there may be implementation and 758 interoperability limitations for sizes in excess of 255 octets. 760 7.1.3. OBJECT IDENTIFIER 762 The OBJECT IDENTIFIER type represents administratively assigned names. 763 Any instance of this type may have at most 128 sub-identifiers. 764 Further, each sub-identifier must not exceed the value 2^32-1 765 (4294967295 decimal). 767 7.1.4. The BITS construct 769 The BITS construct represents an enumeration of named bits. This 770 collection is assigned non-negative, contiguous values, starting at 771 zero. Only those named-bits so enumerated may be present in a value. 772 (Thus, enumerations must be assigned to consecutive bits; however, see 773 Section 9 for refinements of an object with this syntax.) 775 Although there is no SMI-specified limitation on the number of 776 enumerations (and therefore on the length of a value), MIB designers 777 should realize that there may be implementation and interoperability 778 limitations for sizes in excess of 128 bits. 780 Finally, a label for a named-number enumeration must consist of one or 781 more letters or digits (no hyphens), up to a maximum of 64 characters, 782 and the initial character must be a lower-case letter. (However, labels 783 longer than 32 characters are not recommended.) 784 7.1.5. IpAddress 786 The IpAddress type represents a 32-bit internet address. It is 787 represented as an OCTET STRING of length 4, in network byte-order. 789 Note that the IpAddress type is a tagged type for historical reasons. 790 Network addresses should be represented using an invocation of the 791 TEXTUAL-CONVENTION macro [3]. 793 7.1.6. Counter32 795 The Counter32 type represents a non-negative integer which monotonically 796 increases until it reaches a maximum value of 2^32-1 (4294967295 797 decimal), when it wraps around and starts increasing again from zero. 799 Counters have no defined "initial" value, and thus, a single value of a 800 Counter has (in general) no information content. Discontinuities in the 801 monotonically increasing value normally occur at re-initialization of 802 the management system, and at other times as specified in the 803 description of an object-type using this ASN.1 type. If such other 804 times can occur, for example, the creation of an object instance at 805 times other than re-initialization, then a corresponding object should 806 be defined with a SYNTAX clause value of TimeStamp (a textual convention 807 defined in [3]) indicating the time of the last discontinuity. 809 The value of the MAX-ACCESS clause for objects with a SYNTAX clause 810 value of Counter32 is either "read-only" or "accessible-for-notify". 812 A DEFVAL clause is not allowed for objects with a SYNTAX clause value of 813 Counter32. 815 7.1.7. Gauge32 817 The Gauge32 type represents a non-negative integer, which may increase 818 or decrease, but shall never exceed a maximum value. The maximum value 819 can not be greater than 2^32-1 (4294967295 decimal). The value of a 820 Gauge has its maximum value whenever the information being modeled is 821 greater or equal to that maximum value; if the information being modeled 822 subsequently decreases below the maximum value, the Gauge also 823 decreases. 825 7.1.8. TimeTicks 827 The TimeTicks type represents a non-negative integer which represents 828 the time, modulo 2^32 (4294967296 decimal), in hundredths of a second 829 between two epochs. When objects are defined which use this ASN.1 type, 830 the description of the object identifies both of the reference epochs. 832 For example, [3] defines the TimeStamp textual convention which is based 833 on the TimeTicks type. With a TimeStamp, the first reference epoch is 834 defined as the time when sysUpTime [5] was zero, and the second 835 reference epoch is defined as the current value of sysUpTime. 837 The TimeTicks type may not be sub-typed. 839 7.1.9. Opaque 841 The Opaque type is provided solely for backward-compatibility, and shall 842 not be used for newly-defined object types. 844 The Opaque type supports the capability to pass arbitrary ASN.1 syntax. 845 A value is encoded using the ASN.1 Basic Encoding Rules [4] into a 846 string of octets. This, in turn, is encoded as an OCTET STRING, in 847 effect "double-wrapping" the original ASN.1 value. 849 Note that a conforming implementation need only be able to accept and 850 recognize opaquely-encoded data. It need not be able to unwrap the data 851 and then interpret its contents. 853 A requirement on "standard" MIB modules is that no object may have a 854 SYNTAX clause value of Opaque. 856 7.1.10. Counter64 858 The Counter64 type represents a non-negative integer which monotonically 859 increases until it reaches a maximum value of 2^64-1 860 (18446744073709551615 decimal), when it wraps around and starts 861 increasing again from zero. 863 Counters have no defined "initial" value, and thus, a single value of a 864 Counter has (in general) no information content. Discontinuities in the 865 monotonically increasing value normally occur at re-initialization of 866 the management system, and at other times as specified in the 867 description of an object-type using this ASN.1 type. If such other 868 times can occur, for example, the creation of an object instance at 869 times other than re-initialization, then a corresponding object should 870 be defined with a SYNTAX clause value of TimeStamp (a textual convention 871 defined in [3]) indicating the time of the last discontinuity. 873 The value of the MAX-ACCESS clause for objects with a SYNTAX clause 874 value of Counter64 is either "read-only" or "accessible-for-notify". 876 A requirement on "standard" MIB modules is that the Counter64 type may 877 be used only if the information being modeled would wrap in less than 878 one hour if the Counter32 type was used instead. 880 A DEFVAL clause is not allowed for objects with a SYNTAX clause value of 881 Counter64. 883 7.1.11. Unsigned32 885 The Unsigned32 type represents integer-valued information between 0 and 886 2^32-1 inclusive (0 to 4294967295 decimal). 888 7.1.12. Conceptual Tables 890 Management operations apply exclusively to scalar objects. However, it 891 is sometimes convenient for developers of management applications to 892 impose an imaginary, tabular structure on an ordered collection of 893 objects within the MIB. Each such conceptual table contains zero or 894 more rows, and each row may contain one or more scalar objects, termed 895 columnar objects. This conceptualization is formalized by using the 896 OBJECT-TYPE macro to define both an object which corresponds to a table 897 and an object which corresponds to a row in that table. A conceptual 898 table has SYNTAX of the form: 900 SEQUENCE OF 902 where refers to the SEQUENCE type of its subordinate 903 conceptual row. A conceptual row has SYNTAX of the form: 905 907 where is a SEQUENCE type defined as follows: 909 ::= SEQUENCE { , ... , } 911 where there is one for each subordinate object, and each 912 is of the form: 914 916 where is the descriptor naming a subordinate object, and 917 has the value of that subordinate object's SYNTAX clause, 918 normally omitting the sub-typing information. Further, these ASN.1 919 types are always present (the DEFAULT and OPTIONAL clauses are 920 disallowed in the SEQUENCE definition). The MAX-ACCESS clause for 921 conceptual tables and rows is "not-accessible". 923 7.1.12.1. Creation and Deletion of Conceptual Rows 925 For newly-defined conceptual rows which allow the creation of new object 926 instances and/or the deletion of existing object instances, there should 927 be one columnar object with a SYNTAX clause value of RowStatus (a 928 textual convention defined in [3]) and a MAX-ACCESS clause value of 929 read-create. By convention, this is termed the status column for the 930 conceptual row. 932 7.2. Mapping of the UNITS clause 934 This UNITS clause, which need not be present, contains a textual 935 definition of the units associated with that object. 937 7.3. Mapping of the MAX-ACCESS clause 939 The MAX-ACCESS clause, which must be present, defines whether it makes 940 "protocol sense" to read, write and/or create an instance of the object, 941 or to include its value in a notification. This is the maximal level of 942 access for the object. (This maximal level of access is independent of 943 any administrative authorization policy.) 945 The value "read-write" indicates that read and write access make 946 "protocol sense", but create does not. The value "read-create" 947 indicates that read, write and create access make "protocol sense". The 948 value "not-accessible" indicates an auxiliary object (see Section 7.7). 949 The value "accessible-for-notify" indicates an object which is 950 accessible only via a notification (e.g., snmpTrapOID [5]). 952 These values are ordered, from least to greatest: "not-accessible", 953 "accessible-for-notify", "read-only", "read-write", "read-create". 955 If any columnar object in a conceptual row has "read-create" as its 956 maximal level of access, then no other columnar object of the same 957 conceptual row may have a maximal access of "read-write". (Note that 958 "read-create" is a superset of "read-write".) 960 7.4. Mapping of the STATUS clause 962 The STATUS clause, which must be present, indicates whether this 963 definition is current or historic. 965 The values "current", and "obsolete" are self-explanatory. The 966 "deprecated" value indicates that the definition is obsolete, but that 967 an implementor may wish to support that object to foster 968 interoperability with older implementations. 970 7.5. Mapping of the DESCRIPTION clause 972 The DESCRIPTION clause, which must be present, contains a textual 973 definition of that object which provides all semantic definitions 974 necessary for implementation, and should embody any information which 975 would otherwise be communicated in any ASN.1 commentary annotations 976 associated with the object. 978 7.6. Mapping of the REFERENCE clause 980 The REFERENCE clause, which need not be present, contains a textual 981 cross-reference to an object defined in some other information module. 982 This is useful when de-osifying a MIB module produced by some other 983 organization. 985 7.7. Mapping of the INDEX clause 987 The INDEX clause, which must be present if that object corresponds to a 988 conceptual row (unless an AUGMENTS clause is present instead), and must 989 be absent otherwise, defines instance identification information for the 990 columnar objects subordinate to that object. 992 The instance identification information in an INDEX clause must specify 993 object(s) such that value(s) of those object(s) will unambiguously 994 distinguish a conceptual row. The syntax of those objects indicate how 995 to form the instance-identifier: 997 (1) integer-valued: a single sub-identifier taking the integer value 998 (this works only for non-negative integers); 1000 (2) string-valued, fixed-length strings (or variable-length preceded by 1001 the IMPLIED keyword): `n' sub-identifiers, where `n' is the length 1002 of the string (each octet of the string is encoded in a separate 1003 sub-identifier); 1005 (3) string-valued, variable-length strings (not preceded by the IMPLIED 1006 keyword): `n+1' sub-identifiers, where `n' is the length of the 1007 string (the first sub-identifier is `n' itself, following this, 1008 each octet of the string is encoded in a separate sub-identifier); 1010 (4) object identifier-valued (when preceded by the IMPLIED keyword): 1011 `n' sub-identifiers, where `n' is the number of sub-identifiers in 1012 the value (each sub-identifier of the value is copied into a 1013 separate sub-identifier); 1015 (5) object identifier-valued (when not preceded by the IMPLIED 1016 keyword): `n+1' sub-identifiers, where `n' is the number of sub- 1017 identifiers in the value (the first sub-identifier is `n' itself, 1018 following this, each sub-identifier in the value is copied); 1020 (6) IpAddress-valued: 4 sub-identifiers, in the familiar a.b.c.d 1021 notation. 1023 Note that the IMPLIED keyword can only be present for an object having a 1024 variable-length syntax (e.g., variable-length strings or object 1025 identifier-valued objects), Further, the IMPLIED keyword can only be 1026 associated with the last object in the INDEX clause. Finally, the 1027 IMPLIED keyword may not be used on a variable-length string object if 1028 that string might have a value of zero-length. 1030 Instances identified by use of integer-valued objects should be numbered 1031 starting from one (i.e., not from zero). The use of zero as a value for 1032 an integer-valued index object should be avoided, except in special 1033 cases. 1035 Objects which are both specified in the INDEX clause of a conceptual row 1036 and also columnar objects of the same conceptual row are termed 1037 auxiliary objects. The MAX-ACCESS clause for auxiliary objects is 1038 "not-accessible", except in the following circumstances: 1040 (1) within a MIB module originally written to conform to the SNMPv1 1041 framework, and later converted to conform to the SNMPv2 framework; 1042 or 1044 (2) a conceptual row must contain at least one columnar object which is 1045 not an auxiliary object. In the event that all of a conceptual 1046 row's columnar objects are also specified in its INDEX clause, then 1047 one of them must be accessible, i.e., have a MAX-ACCESS clause of 1048 "read-only". (Note that this situation does not arise for a 1049 conceptual row allowing create access, since such a row will have a 1050 status column which will not be an auxiliary object.) 1052 Note that objects specified in a conceptual row's INDEX clause need not 1053 be columnar objects of that conceptual row. In this situation, the 1054 DESCRIPTION clause of the conceptual row must include a textual 1055 explanation of how the objects which are included in the INDEX clause 1056 but not columnar objects of that conceptual row, are used in uniquely 1057 identifying instances of the conceptual row's columnar objects. 1059 7.8. Mapping of the AUGMENTS clause 1061 The AUGMENTS clause, which must not be present unless the object 1062 corresponds to a conceptual row, is an alternative to the INDEX clause. 1063 Every object corresponding to a conceptual row has either an INDEX 1064 clause or an AUGMENTS clause. 1066 If an object corresponding to a conceptual row has an INDEX clause, that 1067 row is termed a base conceptual row; alternatively, if the object has an 1068 AUGMENTS clause, the row is said to be a conceptual row augmentation, 1069 where the AUGMENTS clause names the object corresponding to the base 1070 conceptual row which is augmented by this conceptual row augmentation. 1071 (Thus, a conceptual row augmentation cannot itself be augmented.) 1072 Instances of subordinate columnar objects of a conceptual row 1073 augmentation are identified according to the INDEX clause of the base 1074 conceptual row corresponding to the object named in the AUGMENTS clause. 1075 Further, instances of subordinate columnar objects of a conceptual row 1076 augmentation exist according to the same semantics as instances of 1077 subordinate columnar objects of the base conceptual row being augmented. 1078 As such, note that creation of a base conceptual row implies the 1079 correspondent creation of any conceptual row augmentations. 1081 For example, a MIB designer might wish to define additional columns in 1082 an "enterprise-specific" MIB which logically extend a conceptual row in 1083 a "standard" MIB. The "standard" MIB definition of the conceptual row 1084 would include the INDEX clause and the "enterprise-specific" MIB would 1085 contain the definition of a conceptual row using the AUGMENTS clause. 1086 On the other hand, it would be incorrect to use the AUGMENTS clause for 1087 the relationship between RFC 1573's ifTable and the many media-specific 1088 MIBs which extend it for specific media (e.g., the dot3Table in RFC 1089 1650), since not all interfaces are of the same media. 1091 Note that a base conceptual row may be augmented by multiple conceptual 1092 row augmentations. 1094 7.8.1. Relation between INDEX and AUGMENTS clauses 1096 When defining instance identification information for a conceptual 1097 table: 1099 (1) If there is a one-to-one correspondence between the conceptual rows 1100 of this table and an existing table, then the AUGMENTS clause 1101 should be used. 1103 (2) Otherwise, if there is a sparse relationship between the conceptual 1104 rows of this table and an existing table, then an INDEX clause 1105 should be used which is identical to that in the existing table. 1106 For example, the relationship between RFC 1573's ifTable and a 1107 media-specific MIB which extends the ifTable for a specific media 1108 (e.g., the dot3Table in RFC 1650), is a sparse relationship. 1110 (3) Otherwise, if no existing objects have the required syntax and 1111 semantics, then auxiliary objects should be defined within the 1112 conceptual row for the new table, and those objects should be used 1113 within the INDEX clause for the conceptual row. 1115 7.9. Mapping of the DEFVAL clause 1117 The DEFVAL clause, which need not be present, defines an acceptable 1118 default value which may be used at the discretion of a SNMPv2 entity 1119 acting in an agent role when an object instance is created. 1121 During conceptual row creation, if an instance of a columnar object is 1122 not present as one of the operands in the correspondent management 1123 protocol set operation, then the value of the DEFVAL clause, if present, 1124 indicates an acceptable default value that a SNMPv2 entity acting in an 1125 agent role might use. 1127 The value of the DEFVAL clause must, of course, correspond to the SYNTAX 1128 clause for the object. If the value is an OBJECT IDENTIFIER, then it 1129 must be expressed as a single ASN.1 identifier, and not as a collection 1130 of sub-identifiers. 1132 Note that if an operand to the management protocol set operation is an 1133 instance of a read-only object, then the error `notWritable' [6] will be 1134 returned. As such, the DEFVAL clause can be used to provide an 1135 acceptable default value that a SNMPv2 entity acting in an agent role 1136 might use. 1138 By way of example, consider the following possible DEFVAL clauses: 1140 ObjectSyntax DEFVAL clause 1141 ---------------- ------------ 1142 Integer32 DEFVAL { 1 } 1143 -- same for Gauge32, TimeTicks, Unsigned32 1144 INTEGER DEFVAL { valid } -- enumerated value 1145 OCTET STRING DEFVAL { 'ffffffffffff'H } 1146 OBJECT IDENTIFIER DEFVAL { sysDescr } 1147 BITS DEFVAL { { primary, secondary } } 1148 -- enumerated values that are set 1149 IpAddress DEFVAL { 'c0210415'H } -- 192.33.4.21 1151 Object types with SYNTAX of Counter32 and Counter64 may not have DEFVAL 1152 clauses, since they do not have defined initial values. However, it is 1153 recommended that they be initialized to zero. 1155 7.10. Mapping of the OBJECT-TYPE value 1157 The value of an invocation of the OBJECT-TYPE macro is the name of the 1158 object, which is an OBJECT IDENTIFIER, an administratively assigned 1159 name. 1161 When an OBJECT IDENTIFIER is assigned to an object: 1163 (1) If the object corresponds to a conceptual table, then only a single 1164 assignment, that for a conceptual row, is present immediately 1165 beneath that object. The administratively assigned name for the 1166 conceptual row object is derived by appending a sub-identifier of 1167 "1" to the administratively assigned name for the conceptual table. 1169 (2) If the object corresponds to a conceptual row, then at least one 1170 assignment, one for each column in the conceptual row, is present 1171 beneath that object. The administratively assigned name for each 1172 column is derived by appending a unique, positive sub-identifier to 1173 the administratively assigned name for the conceptual row. 1175 (3) Otherwise, no other OBJECT IDENTIFIERs which are subordinate to the 1176 object may be assigned. 1178 Note that the final sub-identifier of any administratively assigned name 1179 for an object shall be positive. A zero-valued final sub-identifier is 1180 reserved for future use. 1182 Further note that although conceptual tables and rows are given 1183 administratively assigned names, these conceptual objects may not be 1184 manipulated in aggregate form by the management protocol. 1186 7.11. Usage Example 1188 Consider how one might define a conceptual table and its subordinates. 1189 (This example uses the RowStatus textual convention defined in [3].) 1191 evalSlot OBJECT-TYPE 1192 SYNTAX INTEGER 1193 MAX-ACCESS read-only 1194 STATUS current 1195 DESCRIPTION 1196 "The index number of the first unassigned entry in the 1197 evaluation table. 1199 A management station should create new entries in the 1200 evaluation table using this algorithm: first, issue a 1201 management protocol retrieval operation to determine the 1202 value of evalSlot; and, second, issue a management protocol 1203 set operation to create an instance of the evalStatus object 1204 setting its value to createAndGo(4) or createAndWait(5). If 1205 this latter operation succeeds, then the management station 1206 may continue modifying the instances corresponding to the 1207 newly created conceptual row, without fear of collision with 1208 other management stations." 1209 ::= { eval 1 } 1211 evalTable OBJECT-TYPE 1212 SYNTAX SEQUENCE OF EvalEntry 1213 MAX-ACCESS not-accessible 1214 STATUS current 1215 DESCRIPTION 1216 "The (conceptual) evaluation table." 1217 ::= { eval 2 } 1219 evalEntry OBJECT-TYPE 1220 SYNTAX EvalEntry 1221 MAX-ACCESS not-accessible 1222 STATUS current 1223 DESCRIPTION 1224 "An entry (conceptual row) in the evaluation table." 1225 INDEX { evalIndex } 1226 ::= { evalTable 1 } 1228 EvalEntry ::= 1229 SEQUENCE { 1230 evalIndex Integer32, 1231 evalString DisplayString, 1232 evalValue Integer32, 1233 evalStatus RowStatus 1234 } 1236 evalIndex OBJECT-TYPE 1237 SYNTAX Integer32 1238 MAX-ACCESS not-accessible 1239 STATUS current 1240 DESCRIPTION 1241 "The auxiliary variable used for identifying instances of 1242 the columnar objects in the evaluation table." 1243 ::= { evalEntry 1 } 1245 evalString OBJECT-TYPE 1246 SYNTAX DisplayString 1247 MAX-ACCESS read-create 1248 STATUS current 1249 DESCRIPTION 1250 "The string to evaluate." 1251 ::= { evalEntry 2 } 1253 evalValue OBJECT-TYPE 1254 SYNTAX Integer32 1255 MAX-ACCESS read-only 1256 STATUS current 1257 DESCRIPTION 1258 "The value when evalString was last executed." 1259 DEFVAL { 0 } 1260 ::= { evalEntry 3 } 1262 evalStatus OBJECT-TYPE 1263 SYNTAX RowStatus 1264 MAX-ACCESS read-create 1265 STATUS current 1266 DESCRIPTION 1267 "The status column used for creating, modifying, and 1268 deleting instances of the columnar objects in the evaluation 1269 table." 1270 DEFVAL { active } 1271 ::= { evalEntry 4 } 1273 8. Mapping of the NOTIFICATION-TYPE macro 1275 The NOTIFICATION-TYPE macro is used to define the information contained 1276 within an unsolicited transmission of management information (i.e., 1277 within either a SNMPv2-Trap-PDU or InformRequest-PDU). It should be 1278 noted that the expansion of the NOTIFICATION-TYPE macro is something 1279 which conceptually happens during implementation and not during run- 1280 time. 1282 8.1. Mapping of the OBJECTS clause 1284 The OBJECTS clause, which need not be present, defines the ordered 1285 sequence of MIB object types which are contained within every instance 1286 of the notification. An object type specified in this clause may not 1287 have an MAX-ACCESS clause of "not-accessible". 1289 8.2. Mapping of the STATUS clause 1291 The STATUS clause, which must be present, indicates whether this 1292 definition is current or historic. 1294 The values "current", and "obsolete" are self-explanatory. The 1295 "deprecated" value indicates that the definition is obsolete, but that 1296 an implementor may wish to support the notification to foster 1297 interoperability with older implementations. 1299 8.3. Mapping of the DESCRIPTION clause 1301 The DESCRIPTION clause, which must be present, contains a textual 1302 definition of the notification which provides all semantic definitions 1303 necessary for implementation, and should embody any information which 1304 would otherwise be communicated in any ASN.1 commentary annotations 1305 associated with the notification. In particular, the DESCRIPTION clause 1306 should document which instances of the objects mentioned in the OBJECTS 1307 clause should be contained within notifications of this type. 1309 8.4. Mapping of the REFERENCE clause 1311 The REFERENCE clause, which need not be present, contains a textual 1312 cross-reference to a notification defined in some other information 1313 module. This is useful when de-osifying a MIB module produced by some 1314 other organization. 1316 8.5. Mapping of the NOTIFICATION-TYPE value 1318 The value of an invocation of the NOTIFICATION-TYPE macro is the name of 1319 the notification, which is an OBJECT IDENTIFIER, an administratively 1320 assigned name. In order to achieve compatibility with the procedures 1321 employed by proxy agents (see Section 3.1.2 of [7]), the next to last 1322 sub-identifier in the name of any newly-defined notification must have 1323 the value zero. 1325 Sections 4.2.6 and 4.2.7 of [6] describe how the NOTIFICATION-TYPE macro 1326 is used to generate a SNMPv2-Trap-PDU or InformRequest-PDU, 1327 respectively. 1329 8.6. Usage Example 1331 Consider how a linkUp trap might be described: 1333 linkUp NOTIFICATION-TYPE 1334 OBJECTS { ifIndex } 1335 STATUS current 1336 DESCRIPTION 1337 "A linkUp trap signifies that the SNMPv2 entity, acting in 1338 an agent role, recognizes that one of the communication 1339 links represented in its configuration has come up." 1340 ::= { snmpTraps 4 } 1342 According to this invocation, the trap authoritatively identified as 1344 { snmpTraps 4 } 1346 is used to report a link coming up. 1348 9. Refined Syntax 1350 Some macros have clauses which allows syntax to be refined, 1351 specifically: the SYNTAX clause of the OBJECT-TYPE macro, and the 1352 SYNTAX/WRITE-SYNTAX clauses of the MODULE-COMPLIANCE and AGENT- 1353 CAPABILITIES macros [2]. However, not all refinements of syntax are 1354 appropriate. In particular, the object's primitive or application type 1355 must not be changed. 1357 Further, the following restrictions apply: 1359 Restrictions to Refinement on 1360 object syntax range enumeration size repertoire 1361 ----------------- ----- ----------- ---- ---------- 1362 INTEGER (1) (2) - - 1363 Integer32 (1) - - - 1364 Unsigned32 (1) - - - 1365 OCTET STRING - - (3) (4) 1366 OBJECT IDENTIFIER - - - - 1367 BITS - (2) - - 1368 IpAddress - - - - 1369 Counter32 - - - - 1370 Counter64 - - - - 1371 Gauge32 (1) - - - 1372 TimeTicks - - - - 1374 where: 1376 (1) the range of permitted values may be refined by raising the lower- 1377 bounds, by reducing the upper-bounds, and/or by reducing the 1378 alternative value/range choices; 1380 (2) the enumeration of named-values may be refined by removing one or 1381 more named-values (note that for BITS, a refinement may cause the 1382 enumerations to no longer be contiguous); 1384 (3) the size in characters of the value may be refined by raising the 1385 lower-bounds, by reducing the upper-bounds, and/or by reducing the 1386 alternative size choices; or, 1388 (4) the repertoire of characters in the value may be reduced by further 1389 sub-typing. 1391 Otherwise no refinements are possible. Further details on sub-typing 1392 are provided in Appendix C. 1394 10. Extending an Information Module 1396 As experience is gained with a published information module, it may be 1397 desirable to revise that information module. 1399 To begin, the invocation of the MODULE-IDENTITY macro should be updated 1400 to include information about the revision. Usually, this consists of 1401 updating the LAST-UPDATED clause and adding a pair of REVISION and 1402 DESCRIPTION clauses. However, other existing clauses in the invocation 1403 may be updated. 1405 Note that the module's label (e.g., "FIZBIN-MIB" from the example in 1406 Section 5.8), is not changed when the information module is revised. 1408 10.1. Object Assignments 1410 If any non-editorial change is made to any clause of a object 1411 assignment, then the OBJECT IDENTIFIER value associated with that object 1412 assignment must also be changed, along with its associated descriptor. 1414 10.2. Object Definitions 1416 An object definition may be revised in any of the following ways: 1418 (1) A SYNTAX clause containing an enumerated INTEGER may have new 1419 enumerations added or existing labels changed. 1421 (2) A STATUS clause value of "current" may be revised as "deprecated" 1422 or "obsolete". Similarly, a STATUS clause value of "deprecated" 1423 may be revised as "obsolete". 1425 (3) A DEFVAL clause may be added or updated. 1427 (4) A REFERENCE clause may be added or updated. 1429 (5) A UNITS clause may be added. 1431 (6) A conceptual row may be augmented by adding new columnar objects at 1432 the end of the row. 1434 (7) Entirely new objects may be defined, named with previously 1435 unassigned OBJECT IDENTIFIER values. 1437 Otherwise, if the semantics of any previously defined object are changed 1438 (i.e., if a non-editorial change is made to any clause other those 1439 specifically allowed above), then the OBJECT IDENTIFIER value associated 1440 with that object must also be changed. 1442 Note that changing the descriptor associated with an existing object is 1443 considered a semantic change, as these strings may be used in an IMPORTS 1444 statement. 1446 Finally, note that if an object has the value of its STATUS clause 1447 changed, then the value of its DESCRIPTION clause should be updated 1448 accordingly. 1450 10.3. Notification Definitions 1452 A notification definition may be revised in any of the following ways: 1454 (1) A REFERENCE clause may be added or updated. 1456 Otherwise, if the semantics of any previously defined notification are 1457 changed (i.e., if a non-editorial change is made to any clause other 1458 those specifically allowed above), then the OBJECT IDENTIFIER value 1459 associated with that notification must also be changed. 1461 Note that changing the descriptor associated with an existing 1462 notification is considered a semantic change, as these strings may be 1463 used in an IMPORTS statement. 1465 Finally, note that if an object has the value of its STATUS clause 1466 changed, then the value of its DESCRIPTION clause should be updated 1467 accordingly. 1469 11. Appendix A: de-OSIfying a MIB module 1471 There has been an increasing amount of work recently on taking MIBs 1472 defined by other organizations (e.g., the IEEE) and de-osifying them for 1473 use with the Internet-standard network management framework. The steps 1474 to achieve this are straight-forward, though tedious. Of course, it is 1475 helpful to already be experienced in writing MIB modules for use with 1476 the Internet-standard network management framework. 1478 The first step is to construct a skeletal MIB module, as shown earlier 1479 in Section 5.8. The next step is to categorize the objects into groups. 1480 Optional objects are not permitted. Thus, when a MIB module is created, 1481 optional objects must be placed in a additional groups, which, if 1482 implemented, all objects in the group must be implemented. For the 1483 first pass, it is wisest to simply ignore any optional objects in the 1484 original MIB: experience shows it is better to define a core MIB module 1485 first, containing only essential objects; later, if experience demands, 1486 other objects can be added. 1488 11.1. Managed Object Mapping 1490 Next for each managed object class, determine whether there can exist 1491 multiple instances of that managed object class. If not, then for each 1492 of its attributes, use the OBJECT-TYPE macro to make an equivalent 1493 definition. 1495 Otherwise, if multiple instances of the managed object class can exist, 1496 then define a conceptual table having conceptual rows each containing a 1497 columnar object for each of the managed object class's attributes. If 1498 the managed object class is contained within the containment tree of 1499 another managed object class, then the assignment of an object is 1500 normally required for each of the "distinguished attributes" of the 1501 containing managed object class. If they do not already exist within 1502 the MIB module, then they can be added via the definition of additional 1503 columnar objects in the conceptual row corresponding to the contained 1504 managed object class. 1506 In defining a conceptual row, it is useful to consider the optimization 1507 of network management operations which will act upon its columnar 1508 objects. In particular, it is wisest to avoid defining more columnar 1509 objects within a conceptual row, than can fit in a single PDU. As a 1510 rule of thumb, a conceptual row should contain no more than 1511 approximately 20 objects. Similarly, or as a way to abide by the "20 1512 object guideline", columnar objects should be grouped into tables 1513 according to the expected grouping of network management operations upon 1514 them. As such, the content of conceptual rows should reflect typical 1515 access scenarios, e.g., they should be organized along functional lines 1516 such as one row for statistics and another row for parameters, or along 1517 usage lines such as commonly-needed objects versus rarely-needed 1518 objects. 1520 On the other hand, the definition of conceptual rows where the number of 1521 columnar objects used as indexes outnumbers the number used to hold 1522 information, should also be avoided. In particular, the splitting of a 1523 managed object class's attributes into many conceptual tables should not 1524 be used as a way to obtain the same degree of flexibility/complexity as 1525 is often found in MIBs with a myriad of optionals. 1527 11.1.1. Mapping to the SYNTAX clause 1529 When mapping to the SYNTAX clause of the OBJECT-TYPE macro: 1531 (1) An object with BOOLEAN syntax becomes a TruthValue [3]. 1533 (2) An object with INTEGER syntax becomes an Integer32. 1535 (3) An object with ENUMERATED syntax becomes an INTEGER with 1536 enumerations, taking any of the values given which can be 1537 represented with an Integer32. 1539 (4) An object with BIT STRING syntax having enumerations becomes a BITS 1540 construct. 1542 (5) An object with BIT STRING syntax but no enumerations becomes an 1543 OCTET STRING. 1545 (6) An object with a character string syntax becomes either an OCTET 1546 STRING, or a DisplayString [3], depending on the repertoire of the 1547 character string. 1549 (7) A non-tabular object with a complex syntax, such as REAL or 1550 EXTERNAL, must be decomposed, usually into an OCTET STRING (if 1551 sensible). As a rule, any object with a complicated syntax should 1552 be avoided. 1554 (8) Tabular objects must be decomposed into rows of columnar objects. 1556 11.1.2. Mapping to the UNITS clause 1558 If the description of this managed object defines a unit-basis, then 1559 mapping to this clause is straight-forward. 1561 11.1.3. Mapping to the MAX-ACCESS clause 1563 This is straight-forward. 1565 11.1.4. Mapping to the STATUS clause 1567 This is straight-forward. 1569 11.1.5. Mapping to the DESCRIPTION clause 1571 This is straight-forward: simply copy the text, making sure that any 1572 embedded double quotation marks are sanitized (i.e., replaced with 1573 single-quotes or removed). 1575 11.1.6. Mapping to the REFERENCE clause 1577 This is straight-forward: simply include a textual reference to the 1578 object being mapped, the document which defines the object, and perhaps 1579 a page number in the document. 1581 11.1.7. Mapping to the INDEX clause 1583 If necessary, decide how instance-identifiers for columnar objects are 1584 to be formed and define this clause accordingly. 1586 11.1.8. Mapping to the DEFVAL clause 1588 Decide if a meaningful default value can be assigned to the object being 1589 mapped, and if so, define the DEFVAL clause accordingly. 1591 11.2. Action Mapping 1593 Actions are modeled as read-write objects, in which writing a particular 1594 value results in a state change. (Usually, as a part of this state 1595 change, some action might take place.) 1597 11.2.1. Mapping to the SYNTAX clause 1599 Usually the Integer32 syntax is used with a distinguished value provided 1600 for each action that the object provides access to. In addition, there 1601 is usually one other distinguished value, which is the one returned when 1602 the object is read. 1604 11.2.2. Mapping to the MAX-ACCESS clause 1606 Always use read-write or read-create. 1608 11.2.3. Mapping to the STATUS clause 1610 This is straight-forward. 1612 11.2.4. Mapping to the DESCRIPTION clause 1614 This is straight-forward: simply copy the text, making sure that any 1615 embedded double quotation marks are sanitized (i.e., replaced with 1616 single-quotes or removed). 1618 11.2.5. Mapping to the REFERENCE clause 1620 This is straight-forward: simply include a textual reference to the 1621 action being mapped, the document which defines the action, and perhaps 1622 a page number in the document. 1624 11.3. Event Mapping 1626 Events are modeled as SNMPv2 notifications using NOTIFICATION-TYPE 1627 macro. However, recall that SNMPv2 emphasizes trap-directed polling. 1628 As such, few, and usually no, notifications, need be defined for any MIB 1629 module. 1631 11.3.1. Mapping to the STATUS clause 1633 This is straight-forward. 1635 11.3.2. Mapping to the DESCRIPTION clause 1637 This is straight-forward: simply copy the text, making sure that any 1638 embedded double quotation marks are sanitized (i.e., replaced with 1639 single-quotes or removed). 1641 11.3.3. Mapping to the REFERENCE clause 1643 This is straight-forward: simply include a textual reference to the 1644 notification being mapped, the document which defines the notification, 1645 and perhaps a page number in the document. 1647 12. Appendix B: UTC Time Format 1649 Several clauses defined in this document use the UTC Time format: 1651 YYMMDDHHMMZ 1653 where: YY - last two digits of year 1654 MM - month (01 through 12) 1655 DD - day of month (01 through 31) 1656 HH - hours (00 through 23) 1657 MM - minutes (00 through 59) 1658 Z - the character "Z" denotes Greenwich Mean Time (GMT). 1660 For example, "9502192015Z" represents 8:15pm GMT on 19 February 1995. 1662 13. Appendix C: Detailed Sub-typing Rules 1664 13.1. Syntax Rules 1666 The syntax rules for sub-typing are given below. Note that while this 1667 syntax is based on ASN.1, it includes some extensions beyond what is 1668 allowed in ASN.1, and a number of ASN.1 constructs are not allowed by 1669 this syntax. 1671 1672 ::= 1673 | "(" ["|" ]... ")" 1675 1676 ::= 1677 | "(" "SIZE" "(" ["|" ]... ")" ")" 1679 1680 ::= 1681 | ".." 1683 1684 ::= "-" 1685 | 1686 | 1687 | 1689 where: 1690 is the empty string 1691 is a non-negative integer 1692 is a hexadecimal string (i.e. 'xxxx'H) 1693 is a binary string (i.e. 'xxxx'B) 1695 is further restricted as follows: 1696 - any used in a SIZE clause must be non-negative. 1697 - when a pair of values is specified, the first value 1698 must be less than the second value. 1699 - when multiple ranges are specified, the ranges may 1700 not overlap but may touch. For example, (1..4 | 4..9) 1701 is invalid, and (1..4 | 5..9) is valid. 1702 - the ranges must be a subset of the maximum range of the 1703 base type. 1705 13.2. Examples 1707 Some examples of legal sub-typing: 1709 Integer32 (-20..100) 1710 Integer32 (0..100 | 300..500) 1711 Integer32 (300..500 | 0..100) 1712 Integer32 (0 | 2 | 4 | 6 | 8 | 10) 1713 OCTET STRING (SIZE(0..100)) 1714 OCTET STRING (SIZE(0..100 | 300..500)) 1715 OCTET STRING (SIZE(0 | 2 | 4 | 6 | 8 | 10)) 1717 Some examples of illegal sub-typing: 1719 Integer32 (150..100) -- first greater than second 1720 Integer32 (0..100 | 50..500) -- ranges overlap 1721 Integer32 (0 | 2 | 0 ) -- value duplicated 1722 Integer32 (MIN..-1 | 1..MAX) -- MIN and MAX not allowed 1723 Integer32 ((SIZE (0..34)) -- must not use SIZE 1724 OCTET STRING (0..100) -- must use SIZE 1725 OCTET STRING (SIZE(-10..100)) -- negative SIZE 1727 13.3. Rules for Textual Conventions 1729 Sub-typing of Textual Conventions (see [3]) is allowed but must be 1730 valid. In particular, each range specified for the textual convention 1731 must be a subset of a range specified for the base type. For example, 1733 Tc1 ::= INTEGER (1..10 | 11..20) 1734 Tc2 ::= Tc1 (2..10 | 12..15) -- is valid 1735 Tc3 ::= Tc1 (4..8) -- is valid 1736 Tc4 ::= Tc1 (8..12) -- is invalid 1738 14. Acknowledgements 1740 This document is the result of significant work by the four major 1741 contributors: 1743 Jeffrey Case (SNMP Research, case@snmp.com) 1744 Keith McCloghrie (Cisco Systems, kzm@cisco.com) 1745 Marshall Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us) 1746 Steven Waldbusser (International Network Services, stevew@uni.ins.com) 1748 In addition, the contributions of the SNMPv2 Working Group are 1749 acknowledged. In particular, a special thanks is extended for the 1750 contributions of: 1752 Alexander I. Alten (Novell) 1753 Dave Arneson (Cabletron) 1754 Uri Blumenthal (IBM) 1755 Doug Book (Chipcom) 1756 Kim Curran (Bell-Northern Research) 1757 Jim Galvin (Trusted Information Systems) 1758 Maria Greene (Ascom Timeplex) 1759 Iain Hanson (Digital) 1760 Dave Harrington (Cabletron) 1761 Nguyen Hien (IBM) 1762 Jeff Johnson (Cisco Systems) 1763 Michael Kornegay (Object Quest) 1764 Deirdre Kostick (AT&T Bell Labs) 1765 David Levi (SNMP Research) 1766 Daniel Mahoney (Cabletron) 1767 Bob Natale (ACE*COMM) 1768 Brian O'Keefe (Hewlett Packard) 1769 Andrew Pearson (SNMP Research) 1770 Dave Perkins (Peer Networks) 1771 Randy Presuhn (Peer Networks) 1772 Aleksey Romanov (Quality Quorum) 1773 Shawn Routhier (Epilogue) 1774 Jon Saperia (BGS Systems) 1775 Bob Stewart (Cisco Systems, bstewart@cisco.com), chair 1776 Kaj Tesink (Bellcore) 1777 Glenn Waters (Bell-Northern Research) 1778 Bert Wijnen (IBM) 1780 15. References 1782 [1] Information processing systems - Open Systems Interconnection - 1783 Specification of Abstract Syntax Notation One (ASN.1), 1784 International Organization for Standardization. International 1785 Standard 8824, (December, 1987). 1787 [2] McCloghrie, K., Editor, | 1788 "Conformance Statements for Version 2 of the Simple Network 1789 Management Protocol (SNMPv2)", Internet Draft, Cisco Systems, | 1790 September 1995. | 1792 [3] McCloghrie, K., Editor, | 1793 "Textual Conventions for Version 2 of the Simple Network Management 1794 Protocol (SNMPv2)", Internet Draft, Cisco Systems, September 1995. | 1796 [4] Information processing systems - Open Systems Interconnection - 1797 Specification of Basic Encoding Rules for Abstract Syntax Notation 1798 One (ASN.1), International Organization for Standardization. 1799 International Standard 8825, (December, 1987). 1801 [5] McCloghrie, K., Editor, | 1802 "Management Information Base for Version 2 of the Simple Network 1803 Management Protocol (SNMPv2)", Internet Draft, Cisco Systems, | 1804 September 1995. | 1806 [6] McCloghrie, K., Editor, | 1807 "Protocol Operations for Version 2 of the Simple Network Management 1808 Protocol (SNMPv2)", Internet Draft, Cisco Systems, September 1995. | 1810 [7] McCloghrie, K., Editor, | 1811 "Coexistence between Version 1 and Version 2 of the Internet- 1812 standard Network Management Framework", Internet Draft, Cisco | 1813 Systems, September 1995. | 1815 [8] McCloghrie, K., Editor, "Introduction to Version 2 of the | 1816 Internet-standard Network Management Framework", Internet Draft, | 1817 Cisco Systems, September 1995. | 1819 16. Security Considerations 1821 Security issues are not discussed in this memo. 1823 17. Editor's Address 1825 Keith McCloghrie - 1826 Cisco Systems, Inc. 1827 170 West Tasman Drive 1828 San Jose, CA 95134-1706 1829 US 1831 Phone: +1 408 526 5260 1832 Email: kzm@cisco.com 1834 Table of Contents - 1836 1 Introduction .................................................... 2 1837 1.1 A Note on Terminology ......................................... 2 1838 2 Definitions ..................................................... 4 1839 3.1 The MODULE-IDENTITY macro ..................................... 5 1840 3.2 Object Names and Syntaxes ..................................... 7 1841 3.3 The OBJECT-TYPE macro ......................................... 10 1842 3.5 The NOTIFICATION-TYPE macro ................................... 12 1843 3.6 Administrative Identifiers .................................... 12 1844 3 Information Modules ............................................. 13 1845 3.1 Macro Invocation .............................................. 14 1846 3.1.1 Textual Clauses ............................................. 14 1847 3.2 IMPORTing Symbols ............................................. 15 1848 3.3 Exporting Symbols ............................................. 15 1849 3.4 ASN.1 Comments ................................................ 15 1850 3.5 OBJECT IDENTIFIER values ...................................... 15 1851 4 Naming Hierarchy ................................................ 17 1852 5 Mapping of the MODULE-IDENTITY macro ............................ 18 1853 5.1 Mapping of the LAST-UPDATED clause ............................ 18 1854 5.2 Mapping of the ORGANIZATION clause ............................ 18 1855 5.3 Mapping of the CONTACT-INFO clause ............................ 18 1856 5.4 Mapping of the DESCRIPTION clause ............................. 18 1857 5.5 Mapping of the REVISION clause ................................ 19 1858 5.5.1 Mapping of the DESCRIPTION sub-clause ....................... 19 1859 5.6 Mapping of the MODULE-IDENTITY value .......................... 19 1860 5.7 Usage Example ................................................. 20 1861 6 Mapping of the OBJECT-IDENTITY macro ............................ 21 1862 6.1 Mapping of the STATUS clause .................................. 21 1863 6.2 Mapping of the DESCRIPTION clause ............................. 21 1864 6.3 Mapping of the REFERENCE clause ............................... 21 1865 6.4 Mapping of the OBJECT-IDENTITY value .......................... 21 1866 6.5 Usage Example ................................................. 22 1867 7 Mapping of the OBJECT-TYPE macro ................................ 23 1868 7.1 Mapping of the SYNTAX clause .................................. 23 1869 7.1.1 Integer32 and INTEGER ....................................... 23 1870 7.1.2 OCTET STRING ................................................ 24 1871 7.1.3 OBJECT IDENTIFIER ........................................... 24 1872 7.1.4 The BITS construct .......................................... 24 1873 7.1.5 IpAddress ................................................... 25 1874 7.1.6 Counter32 ................................................... 25 1875 7.1.7 Gauge32 ..................................................... 25 1876 7.1.8 TimeTicks ................................................... 26 1877 7.1.9 Opaque ...................................................... 26 1878 7.1.10 Counter64 .................................................. 26 1879 7.1.11 Unsigned32 ................................................. 27 1880 7.1.12 Conceptual Tables .......................................... 27 1881 7.1.12.1 Creation and Deletion of Conceptual Rows ................. 28 1882 7.2 Mapping of the UNITS clause ................................... 28 1883 7.3 Mapping of the MAX-ACCESS clause .............................. 28 1884 7.4 Mapping of the STATUS clause .................................. 29 1885 7.5 Mapping of the DESCRIPTION clause ............................. 29 1886 7.6 Mapping of the REFERENCE clause ............................... 29 1887 7.7 Mapping of the INDEX clause ................................... 29 1888 7.8 Mapping of the AUGMENTS clause ................................ 31 1889 7.8.1 Relation between INDEX and AUGMENTS clauses ................. 32 1890 7.9 Mapping of the DEFVAL clause .................................. 32 1891 7.10 Mapping of the OBJECT-TYPE value ............................. 33 1892 7.11 Usage Example ................................................ 35 1893 8 Mapping of the NOTIFICATION-TYPE macro .......................... 37 1894 8.1 Mapping of the OBJECTS clause ................................. 37 1895 8.2 Mapping of the STATUS clause .................................. 37 1896 8.3 Mapping of the DESCRIPTION clause ............................. 37 1897 8.4 Mapping of the REFERENCE clause ............................... 37 1898 8.5 Mapping of the NOTIFICATION-TYPE value ........................ 38 1899 8.6 Usage Example ................................................. 39 1900 9 Refined Syntax .................................................. 40 1901 10 Extending an Information Module ................................ 41 1902 10.1 Object Assignments ........................................... 41 1903 10.2 Object Definitions ........................................... 41 1904 10.3 Notification Definitions ..................................... 42 1905 11 Appendix A: de-OSIfying a MIB module ........................... 43 1906 11.1 Managed Object Mapping ....................................... 43 1907 11.1.1 Mapping to the SYNTAX clause ............................... 44 1908 11.1.2 Mapping to the UNITS clause ................................ 45 1909 11.1.3 Mapping to the MAX-ACCESS clause ........................... 45 1910 11.1.4 Mapping to the STATUS clause ............................... 45 1911 11.1.5 Mapping to the DESCRIPTION clause .......................... 45 1912 11.1.6 Mapping to the REFERENCE clause ............................ 45 1913 11.1.7 Mapping to the INDEX clause ................................ 45 1914 11.1.8 Mapping to the DEFVAL clause ............................... 45 1915 11.2 Action Mapping ............................................... 46 1916 11.2.1 Mapping to the SYNTAX clause ............................... 46 1917 11.2.2 Mapping to the MAX-ACCESS clause ........................... 46 1918 11.2.3 Mapping to the STATUS clause ............................... 46 1919 11.2.4 Mapping to the DESCRIPTION clause .......................... 46 1920 11.2.5 Mapping to the REFERENCE clause ............................ 46 1921 11.3 Event Mapping ................................................ 46 1922 11.3.1 Mapping to the STATUS clause ............................... 47 1923 11.3.2 Mapping to the DESCRIPTION clause .......................... 47 1924 11.3.3 Mapping to the REFERENCE clause ............................ 47 1925 12 Appendix B: UTC Time Format .................................... 48 1926 13 Appendix C: Detailed Sub-typing Rules .......................... 49 1927 13.1 Syntax Rules ................................................. 49 1928 13.2 Examples ..................................................... 50 1929 13.3 Rules for Textual Conventions ................................ 50 1930 14 Acknowledgements ............................................... 51 1931 15 References ..................................................... 52 1932 16 Security Considerations ........................................ 53 1933 17 Editor's Address ............................................... 53