RFCs in HTML Format


RFC 1442

          Network Working Group                                  J. Case
          Request for Comments: 1442                 SNMP Research, Inc.
                                                           K. McCloghrie
                                                      Hughes LAN Systems
                                                                 M. Rose
                                            Dover Beach Consulting, Inc.
                                                           S. Waldbusser
                                              Carnegie Mellon University
                                                              April 1993


                       Structure of Management Information
                               for version 2 of the
                   Simple Network Management Protocol (SNMPv2)


          Table of Contents


          1 Introduction ..........................................    2
          1.1 A Note on Terminology ...............................    3
          2 Definitions ...........................................    4
          3.1 The MODULE-IDENTITY macro ...........................    5
          3.2 Object Names and Syntaxes ...........................    7
          3.3 The OBJECT-TYPE macro ...............................   10
          3.5 The NOTIFICATION-TYPE macro .........................   12
          3 Information Modules ...................................   13
          3.1 Macro Invocation ....................................   13
          3.1.1 Textual Clauses ...................................   14
          3.2 IMPORTing Symbols ...................................   14
          4 Naming Hierarchy ......................................   16
          5 Mapping of the MODULE-IDENTITY macro ..................   17
          5.1 Mapping of the LAST-UPDATED clause ..................   17
          5.2 Mapping of the ORGANIZATION clause ..................   17
          5.3 Mapping of the CONTACT-INFO clause ..................   17
          5.4 Mapping of the DESCRIPTION clause ...................   17
          5.5 Mapping of the REVISION clause ......................   17
          5.6 Mapping of the DESCRIPTION clause ...................   18
          5.7 Mapping of the MODULE-IDENTITY value ................   18
          5.8 Usage Example .......................................   19



          Case, McCloghrie, Rose & Waldbusser                  [Page  i]

RFC 1442 SMI for SNMPv2 April 1993 6 Mapping of the OBJECT-IDENTITY macro .................. 20 6.1 Mapping of the STATUS clause ........................ 20 6.2 Mapping of the DESCRIPTION clause ................... 20 6.3 Mapping of the REFERENCE clause ..................... 20 6.4 Mapping of the OBJECT-IDENTITY value ................ 20 6.5 Usage Example ....................................... 21 7 Mapping of the OBJECT-TYPE macro ...................... 22 7.1 Mapping of the SYNTAX clause ........................ 22 7.1.1 Integer32 and INTEGER ............................. 22 7.1.2 OCTET STRING ...................................... 23 7.1.3 OBJECT IDENTIFIER ................................. 23 7.1.4 BIT STRING ........................................ 23 7.1.5 IpAddress ......................................... 23 7.1.6 Counter32 ......................................... 24 7.1.7 Gauge32 ........................................... 24 7.1.8 TimeTicks ......................................... 24 7.1.9 Opaque ............................................ 25 7.1.10 NsapAddress ...................................... 25 7.1.11 Counter64 ........................................ 26 7.1.12 UInteger32 ....................................... 26 7.2 Mapping of the UNITS clause ......................... 26 7.3 Mapping of the MAX-ACCESS clause .................... 27 7.4 Mapping of the STATUS clause ........................ 27 7.5 Mapping of the DESCRIPTION clause ................... 27 7.6 Mapping of the REFERENCE clause ..................... 28 7.7 Mapping of the INDEX clause ......................... 28 7.7.1 Creation and Deletion of Conceptual Rows .......... 30 7.8 Mapping of the AUGMENTS clause ...................... 31 7.8.1 Relation between INDEX and AUGMENTS clauses ....... 31 7.9 Mapping of the DEFVAL clause ........................ 32 7.10 Mapping of the OBJECT-TYPE value ................... 33 7.11 Usage Example ...................................... 35 8 Mapping of the NOTIFICATION-TYPE macro ................ 37 8.1 Mapping of the OBJECTS clause ....................... 37 8.2 Mapping of the STATUS clause ........................ 37 8.3 Mapping of the DESCRIPTION clause ................... 37 8.4 Mapping of the REFERENCE clause ..................... 37 8.5 Mapping of the NOTIFICATION-TYPE value .............. 38 8.6 Usage Example ....................................... 39 9 Refined Syntax ........................................ 40 10 Extending an Information Module ...................... 41 10.1 Object Assignments ................................. 41 10.2 Object Definitions ................................. 41 10.3 Notification Definitions ........................... 42 Case, McCloghrie, Rose & Waldbusser [Page ii]
RFC 1442 SMI for SNMPv2 April 1993 11 Appendix: de-OSIfying a MIB module ................... 43 11.1 Managed Object Mapping ............................. 43 11.1.1 Mapping to the SYNTAX clause ..................... 44 11.1.2 Mapping to the UNITS clause ...................... 45 11.1.3 Mapping to the MAX-ACCESS clause ................. 45 11.1.4 Mapping to the STATUS clause ..................... 45 11.1.5 Mapping to the DESCRIPTION clause ................ 45 11.1.6 Mapping to the REFERENCE clause .................. 45 11.1.7 Mapping to the INDEX clause ...................... 45 11.1.8 Mapping to the DEFVAL clause ..................... 45 11.2 Action Mapping ..................................... 46 11.2.1 Mapping to the SYNTAX clause ..................... 46 11.2.2 Mapping to the MAX-ACCESS clause ................. 46 11.2.3 Mapping to the STATUS clause ..................... 46 11.2.4 Mapping to the DESCRIPTION clause ................ 46 11.2.5 Mapping to the REFERENCE clause .................. 46 11.3 Event Mapping ...................................... 46 11.3.1 Mapping to the STATUS clause ..................... 47 11.3.2 Mapping to the DESCRIPTION clause ................ 47 11.3.3 Mapping to the REFERENCE clause .................. 47 12 Acknowledgements ..................................... 48 13 References ........................................... 52 14 Security Considerations .............................. 54 15 Authors' Addresses ................................... 54 Case, McCloghrie, Rose & Waldbusser [Page 1]
RFC 1442 SMI for SNMPv2 April 1993 1. Introduction A network management system contains: several (potentially many) nodes, each with a processing entity, termed an agent, which has access to management instrumentation; at least one management station; and, a management protocol, used to convey management information between the agents and management stations. Operations of the protocol are carried out under an administrative framework which defines both authentication and authorization policies. Network management stations execute management applications which monitor and control network elements. Network elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled through access to their management information. Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1]. It is the purpose of this document, the Structure of Management Information (SMI), to define that subset. The SMI is divided into three parts: module definitions, object definitions, and, trap definitions. (1) Module definitions are used when describing information modules. An ASN.1 macro, MODULE-IDENTITY, is used to concisely convey the semantics of an information module. (2) Object definitions are used when describing managed objects. An ASN.1 macro, OBJECT-TYPE, is used to concisely convey the syntax and semantics of a managed object. (3) Notification definitions are used when describing unsolicited transmissions of management information. An ASN.1 macro, NOTIFICATION-TYPE, is used to concisely convey the syntax and semantics of a notification. Case, McCloghrie, Rose & Waldbusser [Page 2]
RFC 1442 SMI for SNMPv2 April 1993 1.1. A Note on Terminology For the purpose of exposition, the original Internet-standard Network Management Framework, as described in RFCs 1155, 1157, and 1212, is termed the SNMP version 1 framework (SNMPv1). The current framework is termed the SNMP version 2 framework (SNMPv2). Case, McCloghrie, Rose & Waldbusser [Page 3]
RFC 1442 SMI for SNMPv2 April 1993 2. Definitions SNMPv2-SMI DEFINITIONS ::= BEGIN -- the path to the root internet OBJECT IDENTIFIER ::= { iso 3 6 1 } directory OBJECT IDENTIFIER ::= { internet 1 } mgmt OBJECT IDENTIFIER ::= { internet 2 } experimental OBJECT IDENTIFIER ::= { internet 3 } private OBJECT IDENTIFIER ::= { internet 4 } enterprises OBJECT IDENTIFIER ::= { private 1 } security OBJECT IDENTIFIER ::= { internet 5 } snmpV2 OBJECT IDENTIFIER ::= { internet 6 } -- transport domains snmpDomains OBJECT IDENTIFIER ::= { snmpV2 1 } -- transport proxies snmpProxys OBJECT IDENTIFIER ::= { snmpV2 2 } -- module identities snmpModules OBJECT IDENTIFIER ::= { snmpV2 3 } Case, McCloghrie, Rose & Waldbusser [Page 4]
RFC 1442 SMI for SNMPv2 April 1993 -- definitions for information modules MODULE-IDENTITY MACRO ::= BEGIN TYPE NOTATION ::= "LAST-UPDATED" value(Update UTCTime) "ORGANIZATION" Text "CONTACT-INFO" Text "DESCRIPTION" Text RevisionPart VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER) RevisionPart ::= Revisions | empty Revisions ::= Revision | Revisions Revision Revision ::= "REVISION" value(Update UTCTime) "DESCRIPTION" Text -- uses the NVT ASCII character set Text ::= """" string """" END Case, McCloghrie, Rose & Waldbusser [Page 5]
RFC 1442 SMI for SNMPv2 April 1993 OBJECT-IDENTITY MACRO ::= BEGIN TYPE NOTATION ::= "STATUS" Status "DESCRIPTION" Text ReferPart VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER) Status ::= "current" | "obsolete" ReferPart ::= "REFERENCE" Text | empty Text ::= """" string """" END Case, McCloghrie, Rose & Waldbusser [Page 6]
RFC 1442 SMI for SNMPv2 April 1993 -- names of objects ObjectName ::= OBJECT IDENTIFIER -- syntax of objects ObjectSyntax ::= CHOICE { simple SimpleSyntax, -- note that SEQUENCEs for conceptual tables and -- rows are not mentioned here... application-wide ApplicationSyntax } -- built-in ASN.1 types SimpleSyntax ::= CHOICE { -- INTEGERs with a more restrictive range -- may also be used integer-value INTEGER (-2147483648..2147483647), string-value OCTET STRING, objectID-value OBJECT IDENTIFIER, -- only the enumerated form is allowed bit-value BIT STRING } Case, McCloghrie, Rose & Waldbusser [Page 7]
RFC 1442 SMI for SNMPv2 April 1993 -- indistinguishable from INTEGER, but never needs more than -- 32-bits for a two's complement representation Integer32 ::= [UNIVERSAL 2] IMPLICIT INTEGER (-2147483648..2147483647) -- application-wide types ApplicationSyntax ::= CHOICE { ipAddress-value IpAddress, counter-value Counter32, gauge-value Gauge32, timeticks-value TimeTicks, arbitrary-value Opaque, nsapAddress-value NsapAddress, big-counter-value Counter64, unsigned-integer-value UInteger32 } -- in network-byte order -- (this is a tagged type for historical reasons) IpAddress ::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4)) Case, McCloghrie, Rose & Waldbusser [Page 8]
RFC 1442 SMI for SNMPv2 April 1993 -- this wraps Counter32 ::= [APPLICATION 1] IMPLICIT INTEGER (0..4294967295) -- this doesn't wrap Gauge32 ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295) -- hundredths of seconds since an epoch TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0..4294967295) -- for backward-compatibility only Opaque ::= [APPLICATION 4] IMPLICIT OCTET STRING -- for OSI NSAP addresses -- (this is a tagged type for historical reasons) NsapAddress ::= [APPLICATION 5] IMPLICIT OCTET STRING (SIZE (1 | 4..21)) -- for counters that wrap in less than one hour with only 32 bits Counter64 ::= [APPLICATION 6] IMPLICIT INTEGER (0..18446744073709551615) -- an unsigned 32-bit quantity UInteger32 ::= [APPLICATION 7] IMPLICIT INTEGER (0..4294967295) Case, McCloghrie, Rose & Waldbusser [Page 9]
RFC 1442 SMI for SNMPv2 April 1993 -- definition for objects OBJECT-TYPE MACRO ::= BEGIN TYPE NOTATION ::= "SYNTAX" type(Syntax) UnitsPart "MAX-ACCESS" Access "STATUS" Status "DESCRIPTION" Text ReferPart IndexPart DefValPart VALUE NOTATION ::= value(VALUE ObjectName) UnitsPart ::= "UNITS" Text | empty Access ::= "not-accessible" | "read-only" | "read-write" | "read-create" Status ::= "current" | "deprecated" | "obsolete" ReferPart ::= "REFERENCE" Text | empty IndexPart ::= "INDEX" "{" IndexTypes "}" | "AUGMENTS" "{" Entry "}" | empty IndexTypes ::= IndexType | IndexTypes "," IndexType Case, McCloghrie, Rose & Waldbusser [Page 10]
RFC 1442 SMI for SNMPv2 April 1993 IndexType ::= "IMPLIED" Index | Index Index ::= -- use the SYNTAX value of the -- correspondent OBJECT-TYPE invocation value(Indexobject ObjectName) Entry ::= -- use the INDEX value of the -- correspondent OBJECT-TYPE invocation value(Entryobject ObjectName) DefValPart ::= "DEFVAL" "{" value(Defval Syntax) "}" | empty -- uses the NVT ASCII character set Text ::= """" string """" END Case, McCloghrie, Rose & Waldbusser [Page 11]
RFC 1442 SMI for SNMPv2 April 1993 -- definitions for notifications NOTIFICATION-TYPE MACRO ::= BEGIN TYPE NOTATION ::= ObjectsPart "STATUS" Status "DESCRIPTION" Text ReferPart VALUE NOTATION ::= value(VALUE OBJECT IDENTIFIER) ObjectsPart ::= "OBJECTS" "{" Objects "}" | empty Objects ::= Object | Objects "," Object Object ::= value(Name ObjectName) Status ::= "current" | "deprecated" | "obsolete" ReferPart ::= "REFERENCE" Text | empty -- uses the NVT ASCII character set Text ::= """" string """" END END Case, McCloghrie, Rose & Waldbusser [Page 12]
RFC 1442 SMI for SNMPv2 April 1993 3. Information Modules An "information module" is an ASN.1 module defining information relating to network management. The SMI describes how to use a subset of ASN.1 to define an information module. Further, additional restrictions are placed on "standard" information modules. It is strongly recommended that "enterprise-specific" information modules also adhere to these restrictions. Typically, there are three kinds of information modules: (1) MIB modules, which contain definitions of inter-related managed objects, make use of the OBJECT-TYPE and NOTIFICATION-TYPE macros; (2) compliance statements for MIB modules, which make use of the MODULE-COMPLIANCE and OBJECT-GROUP macros [2]; and, (3) capability statements for agent implementations which make use of the AGENT-CAPABILITIES macros [2]. This classification scheme does not imply a rigid taxonomy. For example, a "standard" information module might include definitions of managed objects and a compliance statement. Similarly, an "enterprise-specific" information module might include definitions of managed objects and a capability statement. Of course, a "standard" information module may not contain capability statements. All information modules start with exactly one invocation of the MODULE-IDENTITY macro, which provides contact and revision history. This invocation must appear immediately after any IMPORTs or EXPORTs statements. 3.1. Macro Invocation Within an information module, each macro invocation appears as: <descriptor> <macro> <clauses> ::= <value> where <descriptor> corresponds to an ASN.1 identifier, <macro> Case, McCloghrie, Rose & Waldbusser [Page 13]
RFC 1442 SMI for SNMPv2 April 1993 names the macro being invoked, and <clauses> and <value> depend on the definition of the macro. An ASN.1 identifier consists of one or more letters, digits, or hyphens. The initial character must be a lower-case letter, and the final character may not be a hyphen. Further, a hyphen may not be immediatedly followed by another hyphen. For all descriptors appearing in an information module, the descriptor shall be unique and mnemonic, and shall not exceed 64 characters in length. This promotes a common language for humans to use when discussing the information module and also facilitates simple table mappings for user-interfaces. The set of descriptors defined in all "standard" information modules shall be unique. Further, within any information module, the hyphen is not allowed as a character in any descriptor. Finally, by convention, if the descriptor refers to an object with a SYNTAX clause value of either Counter32 or Counter64, then the descriptor used for the object should denote plurality. 3.1.1. Textual Clauses Some clauses in a macro invocation may take a textual value (e.g., the DESCRIPTION clause). Note that, in order to conform to the ASN.1 syntax, the entire value of these clauses must be enclosed in double quotation marks, and therefore cannot itself contain double quotation marks, although the value may be multi-line. 3.2. IMPORTing Symbols To reference an external object, the IMPORTS statement must be used to identify both the descriptor and the module defining the descriptor. Note that when symbols from "enterprise-specific" information modules are referenced (e.g., a descriptor), there is the possibility of collision. As such, if different objects with the same descriptor are IMPORTed, then this ambiguity is Case, McCloghrie, Rose & Waldbusser [Page 14]
RFC 1442 SMI for SNMPv2 April 1993 resolved by prefixing the descriptor with the name of the information module and a dot ("."), i.e., "module.descriptor" (All descriptors must be unique within any information module.) Of course, this notation can be used even when there is no collision when IMPORTing symbols. Finally, the IMPORTS statement may not be used to import an ASN.1 named type which corresponds to either the SEQUENCE or SEQUENCE OF type. Case, McCloghrie, Rose & Waldbusser [Page 15]
RFC 1442 SMI for SNMPv2 April 1993
RFC 1442 SMI for SNMPv2 April 1993 11. Appendix: de-OSIfying a MIB module There has been an increasing amount of work recently on taking MIBs defined by other organizations (e.g., the IEEE) and de- osifying them for use with the Internet-standard network management framework. The steps to achieve this are straight-forward, though tedious. Of course, it is helpful to already be experienced in writing MIB modules for use with the Internet-standard network management framework. The first step is to construct a skeletal MIB module, as shown earlier in Section 5.8. The next step is to categorize the objects into groups. Optional objects are not permitted. Thus, when a MIB module is created, optional objects must be placed in a additional groups, which, if implemented, all objects in the group must be implemented. For the first pass, it is wisest to simply ignore any optional objects in the original MIB: experience shows it is better to define a core MIB module first, containing only essential objects; later, if experience demands, other objects can be added. 11.1. Managed Object Mapping Next for each managed object class, determine whether there can exist multiple instances of that managed object class. If not, then for each of its attributes, use the OBJECT-TYPE macro to make an equivalent definition. Otherwise, if multiple instances of the managed object class can exist, then define a conceptual table having conceptual rows each containing a columnar object for each of the managed object class's attributes. If the managed object class is contained within the containment tree of another managed object class, then the assignment of an object is normally required for each of the "distinguished attributes" of the containing managed object class. If they do not already exist within the MIB module, then they can be added via the definition of additional columnar objects in the conceptual row corresponding to the contained managed object class. In defining a conceptual row, it is useful to consider the optimization of network management operations which will act upon its columnar objects. In particular, it is wisest to avoid defining more columnar objects within a conceptual row, Case, McCloghrie, Rose & Waldbusser [Page 43]
RFC 1442 SMI for SNMPv2 April 1993 than can fit in a single PDU. As a rule of thumb, a conceptual row should contain no more than approximately 20 objects. Similarly, or as a way to abide by the "20 object guideline", columnar objects should be grouped into tables according to the expected grouping of network management operations upon them. As such, the content of conceptual rows should reflect typical access scenarios, e.g., they should be organized along functional lines such as one row for statistics and another row for parameters, or along usage lines such as commonly-needed objects versus rarely-needed objects. On the other hand, the definition of conceptual rows where the number of columnar objects used as indexes outnumbers the number used to hold information, should also be avoided. In particular, the splitting of a managed object class's attributes into many conceptual tables should not be used as a way to obtain the same degree of flexibility/complexity as is often found in MIBs with a myriad of optionals. 11.1.1. Mapping to the SYNTAX clause When mapping to the SYNTAX clause of the OBJECT-type macro: (1) An object with BOOLEAN syntax becomes a TruthValue [3]. (2) An object with INTEGER syntax becomes an Integer32. (3) An object with ENUMERATED syntax becomes an INTEGER with enumerations, taking any of the values given which can be represented with an Integer32. (4) An object with BIT STRING syntax but no enumerations becomes an OCTET STRING. (5) An object with a character string syntax becomes either an OCTET STRING, or a DisplayString [3], depending on the repertoire of the character string. (6) A non-tabular object with a complex syntax, such as REAL or EXTERNAL, must be decomposed, usually into an OCTET STRING (if sensible). As a rule, any object with a complicated syntax should be avoided. Case, McCloghrie, Rose & Waldbusser [Page 44]
RFC 1442 SMI for SNMPv2 April 1993 (7) Tabular objects must be decomposed into rows of columnar objects. 11.1.2. Mapping to the UNITS clause If the description of this managed object defines a unit- basis, then mapping to this clause is straight-forward. 11.1.3. Mapping to the MAX-ACCESS clause This is straight-forward. 11.1.4. Mapping to the STATUS clause This is straight-forward. 11.1.5. Mapping to the DESCRIPTION clause This is straight-forward: simply copy the text, making sure that any embedded double quotation marks are sanitized (i.e., replaced with single-quotes or removed). 11.1.6. Mapping to the REFERENCE clause This is straight-forward: simply include a textual reference to the object being mapped, the document which defines the object, and perhaps a page number in the document. 11.1.7. Mapping to the INDEX clause If necessary, decide how instance-identifiers for columnar objects are to be formed and define this clause accordingly. 11.1.8. Mapping to the DEFVAL clause Decide if a meaningful default value can be assigned to the object being mapped, and if so, define the DEFVAL clause accordingly. Case, McCloghrie, Rose & Waldbusser [Page 45]
RFC 1442 SMI for SNMPv2 April 1993 11.2. Action Mapping Actions are modeled as read-write objects, in which writing a particular value results in a state change. (Usually, as a part of this state change, some action might take place.) 11.2.1. Mapping to the SYNTAX clause Usually the Integer32 syntax is used with a distinguished value provided for each action that the object provides access to. In addition, there is usually one other distinguished value, which is the one returned when the object is read. 11.2.2. Mapping to the MAX-ACCESS clause Always use read-write or read-create. 11.2.3. Mapping to the STATUS clause This is straight-forward. 11.2.4. Mapping to the DESCRIPTION clause This is straight-forward: simply copy the text, making sure that any embedded double quotation marks are sanitized (i.e., replaced with single-quotes or removed). 11.2.5. Mapping to the REFERENCE clause This is straight-forward: simply include a textual reference to the action being mapped, the document which defines the action, and perhaps a page number in the document. 11.3. Event Mapping Events are modeled as SNMPv2 notifications using NOTIFICATION-TYPE macro. However, recall that SNMPv2 emphasizes trap-directed polling. As such, few, and usually no, notifications, need be defined for any MIB module. Case, McCloghrie, Rose & Waldbusser [Page 46]
RFC 1442 SMI for SNMPv2 April 1993 11.3.1. Mapping to the STATUS clause This is straight-forward. 11.3.2. Mapping to the DESCRIPTION clause This is straight-forward: simply copy the text, making sure that any embedded double quotation marks are sanitized (i.e., replaced with single-quotes or removed). 11.3.3. Mapping to the REFERENCE clause This is straight-forward: simply include a textual reference to the notification being mapped, the document which defines the notification, and perhaps a page number in the document. Case, McCloghrie, Rose & Waldbusser [Page 47]
RFC 1442 SMI for SNMPv2 April 1993 12. Acknowledgements The section on object definitions (and MIB de-osification) is based, in part, on RFCs 1155 and 1212. The IMPLIED keyword is based on a conversation with David T. Perkins in December, 1991 The section on trap definitions is based, in part, on RFC 1215 Finally, the comments of the SNMP version 2 working group are gratefully acknowledged: Beth Adams, Network Management Forum Steve Alexander, INTERACTIVE Systems Corporation David Arneson, Cabletron Systems Toshiya Asaba Fred Baker, ACC Jim Barnes, Xylogics, Inc. Brian Bataille Andy Bierman, SynOptics Communications, Inc. Uri Blumenthal, IBM Corporation Fred Bohle, Interlink Jack Brown Theodore Brunner, Bellcore Stephen F. Bush, GE Information Services Jeffrey D. Case, University of Tennessee, Knoxville John Chang, IBM Corporation Szusin Chen, Sun Microsystems Robert Ching Chris Chiotasso, Ungermann-Bass Bobby A. Clay, NASA/Boeing John Cooke, Chipcom Tracy Cox, Bellcore Juan Cruz, Datability, Inc. David Cullerot, Cabletron Systems Cathy Cunningham, Microcom James R. (Chuck) Davin, Bellcore Michael Davis, Clearpoint Mike Davison, FiberCom Cynthia DellaTorre, MITRE Taso N. Devetzis, Bellcore Manual Diaz, DAVID Systems, Inc. Jon Dreyer, Sun Microsystems David Engel, Optical Data Systems Case, McCloghrie, Rose & Waldbusser [Page 48]
RFC 1442 SMI for SNMPv2 April 1993 Mike Erlinger, Lexcel Roger Fajman, NIH Daniel Fauvarque, Sun Microsystems Karen Frisa, CMU Shari Galitzer, MITRE Shawn Gallagher, Digital Equipment Corporation Richard Graveman, Bellcore Maria Greene, Xyplex, Inc. Michel Guittet, Apple Robert Gutierrez, NASA Bill Hagerty, Cabletron Systems Gary W. Haney, Martin Marietta Energy Systems Patrick Hanil, Nokia Telecommunications Matt Hecht, SNMP Research, Inc. Edward A. Heiner, Jr., Synernetics Inc. Susan E. Hicks, Martin Marietta Energy Systems Geral Holzhauer, Apple John Hopprich, DAVID Systems, Inc. Jeff Hughes, Hewlett-Packard Robin Iddon, Axon Networks, Inc. David Itusak Kevin M. Jackson, Concord Communications, Inc. Ole J. Jacobsen, Interop Company Ronald Jacoby, Silicon Graphics, Inc. Satish Joshi, SynOptics Communications, Inc. Frank Kastenholz, FTP Software Mark Kepke, Hewlett-Packard Ken Key, SNMP Research, Inc. Zbiginew Kielczewski, Eicon Jongyeoi Kim Andrew Knutsen, The Santa Cruz Operation Michael L. Kornegay, VisiSoft Deirdre C. Kostik, Bellcore Cheryl Krupczak, Georgia Tech Mark S. Lewis, Telebit David Lin David Lindemulder, AT&T/NCR Ben Lisowski, Sprint David Liu, Bell-Northern Research John Lunny, The Wollongong Group Robert C. Lushbaugh Martin, Marietta Energy Systems Michael Luufer, BBN Carl Madison, Star-Tek, Inc. Keith McCloghrie, Hughes LAN Systems Evan McGinnis, 3Com Corporation Case, McCloghrie, Rose & Waldbusser [Page 49]
RFC 1442 SMI for SNMPv2 April 1993 Bill McKenzie, IBM Corporation Donna McMaster, SynOptics Communications, Inc. John Medicke, IBM Corporation Doug Miller, Telebit Dave Minnich, FiberCom Mohammad Mirhakkak, MITRE Rohit Mital, Protools George Mouradian, AT&T Bell Labs Patrick Mullaney, Cabletron Systems Dan Myers, 3Com Corporation Rina Nathaniel, Rad Network Devices Ltd. Hien V. Nguyen, Sprint Mo Nikain Tom Nisbet William B. Norton, MERIT Steve Onishi, Wellfleet Communications, Inc. David T. Perkins, SynOptics Communications, Inc. Carl Powell, BBN Ilan Raab, SynOptics Communications, Inc. Richard Ramons, AT&T Venkat D. Rangan, Metric Network Systems, Inc. Louise Reingold, Sprint Sam Roberts, Farallon Computing, Inc. Kary Robertson, Concord Communications, Inc. Dan Romascanu, Lannet Data Communications Ltd. Marshall T. Rose, Dover Beach Consulting, Inc. Shawn A. Routhier, Epilogue Technology Corporation Chris Rozman Asaf Rubissa, Fibronics Jon Saperia, Digital Equipment Corporation Michael Sapich Mike Scanlon, Interlan Sam Schaen, MITRE John Seligson, Ultra Network Technologies Paul A. Serice, Corporation for Open Systems Chris Shaw, Banyan Systems Timon Sloane Robert Snyder, Cisco Systems Joo Young Song Roy Spitier, Sprint Einar Stefferud, Network Management Associates John Stephens, Cayman Systems, Inc. Robert L. Stewart, Xyplex, Inc. (chair) Kaj Tesink, Bellcore Dean Throop, Data General Case, McCloghrie, Rose & Waldbusser [Page 50]
RFC 1442 SMI for SNMPv2 April 1993 Ahmet Tuncay, France Telecom-CNET Maurice Turcotte, Racal Datacom Warren Vik, INTERACTIVE Systems Corporation Yannis Viniotis Steven L. Waldbusser, Carnegie Mellon Universitty Timothy M. Walden, ACC Alice Wang, Sun Microsystems James Watt, Newbridge Luanne Waul, Timeplex Donald E. Westlake III, Digital Equipment Corporation Gerry White Bert Wijnen, IBM Corporation Peter Wilson, 3Com Corporation Steven Wong, Digital Equipment Corporation Randy Worzella, IBM Corporation Daniel Woycke, MITRE Honda Wu Jeff Yarnell, Protools Chris Young, Cabletron Kiho Yum, 3Com Corporation Case, McCloghrie, Rose & Waldbusser [Page 51]
RFC 1442 SMI for SNMPv2 April 1993 13. References [1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, (December, 1987). [2] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Conformance Statements for version 2 of the the Simple Network Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [3] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Textual Conventions for version 2 of the the Simple Network Management Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [4] Information processing systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8825, (December, 1987). [5] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1450, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [6] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon University, April 1993. [7] McCloghrie, K., and Rose, M., "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991. [8] McCloghrie, K., and Galvin, J., "Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1447, Hughes LAN Systems, Trusted Information Systems, Case, McCloghrie, Rose & Waldbusser [Page 52]
RFC 1442 SMI for SNMPv2 April 1993 April 1993. Case, McCloghrie, Rose & Waldbusser [Page 53]
RFC 1442 SMI for SNMPv2 April 1993 14. Security Considerations Security issues are not discussed in this memo.



Back to RFC index

 

 



Sponsered-Sites:

Register domain name and transfer | Cheap webhosting service | Domain name registration

 

 

""