7 Network Working Group M. Rose
8 Request for Comments: 1155 Performance Systems International
9 Obsoletes: RFC 1065 K. McCloghrie
15 Structure and Identification of Management Information
16 for TCP/IP-based Internets
20 1. Status of this Memo ............................................. 1
21 2. Introduction .................................................... 2
22 3. Structure and Identification of Management Information........... 4
23 3.1 Names .......................................................... 4
24 3.1.1 Directory .................................................... 5
25 3.1.2 Mgmt ......................................................... 6
26 3.1.3 Experimental ................................................. 6
27 3.1.4 Private ...................................................... 7
28 3.2 Syntax ......................................................... 7
29 3.2.1 Primitive Types .............................................. 7
30 3.2.1.1 Guidelines for Enumerated INTEGERs ......................... 7
31 3.2.2 Constructor Types ............................................ 8
32 3.2.3 Defined Types ................................................ 8
33 3.2.3.1 NetworkAddress ............................................. 8
34 3.2.3.2 IpAddress .................................................. 8
35 3.2.3.3 Counter .................................................... 8
36 3.2.3.4 Gauge ...................................................... 9
37 3.2.3.5 TimeTicks .................................................. 9
38 3.2.3.6 Opaque ..................................................... 9
39 3.3 Encodings ...................................................... 9
40 4. Managed Objects ................................................. 10
41 4.1 Guidelines for Object Names .................................... 10
42 4.2 Object Types and Instances ..................................... 10
43 4.3 Macros for Managed Objects ..................................... 14
44 5. Extensions to the MIB ........................................... 16
45 6. Definitions ..................................................... 17
46 7. Acknowledgements ................................................ 20
47 8. References ...................................................... 21
48 9. Security Considerations.......................................... 21
49 10. Authors' Addresses.............................................. 22
51 1. Status of this Memo
53 This RFC is a re-release of RFC 1065, with a changed "Status of this
54 Memo", plus a few minor typographical corrections. The technical
58 Rose & McCloghrie [Page 1]
63 content of the document is unchanged from RFC 1065.
65 This memo provides the common definitions for the structure and
66 identification of management information for TCP/IP-based internets.
67 In particular, together with its companion memos which describe the
68 management information base along with the network management
69 protocol, these documents provide a simple, workable architecture and
70 system for managing TCP/IP-based internets and in particular, the
73 This memo specifies a Standard Protocol for the Internet community.
74 Its status is "Recommended". TCP/IP implementations in the Internet
75 which are network manageable are expected to adopt and implement this
78 The Internet Activities Board recommends that all IP and TCP
79 implementations be network manageable. This implies implementation
80 of the Internet MIB (RFC-1156) and at least one of the two
81 recommended management protocols SNMP (RFC-1157) or CMOT (RFC-1095).
82 It should be noted that, at this time, SNMP is a full Internet
83 standard and CMOT is a draft standard. See also the Host and Gateway
84 Requirements RFCs for more specific information on the applicability
87 Please refer to the latest edition of the "IAB Official Protocol
88 Standards" RFC for current information on the state and status of
89 standard Internet protocols.
91 Distribution of this memo is unlimited.
95 This memo describes the common structures and identification scheme
96 for the definition of management information used in managing
97 TCP/IP-based internets. Included are descriptions of an object
98 information model for network management along with a set of generic
99 types used to describe management information. Formal descriptions
100 of the structure are given using Abstract Syntax Notation One (ASN.1)
103 This memo is largely concerned with organizational concerns and
104 administrative policy: it neither specifies the objects which are
105 managed, nor the protocols used to manage those objects. These
106 concerns are addressed by two companion memos: one describing the
107 Management Information Base (MIB) [2], and the other describing the
108 Simple Network Management Protocol (SNMP) [3].
110 This memo is based in part on the work of the Internet Engineering
114 Rose & McCloghrie [Page 2]
116 RFC 1155 SMI May 1990
119 Task Force, particularly the working note titled "Structure and
120 Identification of Management Information for the Internet" [4]. This
121 memo uses a skeletal structure derived from that note, but differs in
122 one very significant way: that note focuses entirely on the use of
123 OSI-style network management. As such, it is not suitable for use
126 This memo attempts to achieve two goals: simplicity and
127 extensibility. Both are motivated by a common concern: although the
128 management of TCP/IP-based internets has been a topic of study for
129 some time, the authors do not feel that the depth and breadth of such
130 understanding is complete. More bluntly, we feel that previous
131 experiences, while giving the community insight, are hardly
132 conclusive. By fostering a simple SMI, the minimal number of
133 constraints are imposed on future potential approaches; further, by
134 fostering an extensible SMI, the maximal number of potential
135 approaches are available for experimentation.
137 It is believed that this memo and its two companions comply with the
138 guidelines set forth in RFC 1052, "IAB Recommendations for the
139 Development of Internet Network Management Standards" [5] and RFC
140 1109, "Report of the Second Ad Hoc Network Management Review Group"
141 [6]. In particular, we feel that this memo, along with the memo
142 describing the management information base, provide a solid basis for
143 network management of the Internet.
170 Rose & McCloghrie [Page 3]
172 RFC 1155 SMI May 1990
175 3. Structure and Identification of Management Information
177 Managed objects are accessed via a virtual information store, termed
178 the Management Information Base or MIB. Objects in the MIB are
179 defined using Abstract Syntax Notation One (ASN.1) [1].
181 Each type of object (termed an object type) has a name, a syntax, and
182 an encoding. The name is represented uniquely as an OBJECT
183 IDENTIFIER. An OBJECT IDENTIFIER is an administratively assigned
184 name. The administrative policies used for assigning names are
185 discussed later in this memo.
187 The syntax for an object type defines the abstract data structure
188 corresponding to that object type. For example, the structure of a
189 given object type might be an INTEGER or OCTET STRING. Although in
190 general, we should permit any ASN.1 construct to be available for use
191 in defining the syntax of an object type, this memo purposely
192 restricts the ASN.1 constructs which may be used. These restrictions
193 are made solely for the sake of simplicity.
195 The encoding of an object type is simply how instances of that object
196 type are represented using the object's type syntax. Implicitly tied
197 to the notion of an object's syntax and encoding is how the object is
198 represented when being transmitted on the network. This memo
199 specifies the use of the basic encoding rules of ASN.1 [7].
201 It is beyond the scope of this memo to define either the MIB used for
202 network management or the network management protocol. As mentioned
203 earlier, these tasks are left to companion memos. This memo attempts
204 to minimize the restrictions placed upon its companions so as to
205 maximize generality. However, in some cases, restrictions have been
206 made (e.g., the syntax which may be used when defining object types
207 in the MIB) in order to encourage a particular style of management.
208 Future editions of this memo may remove these restrictions.
212 Names are used to identify managed objects. This memo specifies
213 names which are hierarchical in nature. The OBJECT IDENTIFIER
214 concept is used to model this notion. An OBJECT IDENTIFIER can be
215 used for purposes other than naming managed object types; for
216 example, each international standard has an OBJECT IDENTIFIER
217 assigned to it for the purposes of identification. In short, OBJECT
218 IDENTIFIERs are a means for identifying some object, regardless of
219 the semantics associated with the object (e.g., a network object, a
220 standards document, etc.)
222 An OBJECT IDENTIFIER is a sequence of integers which traverse a
226 Rose & McCloghrie [Page 4]
228 RFC 1155 SMI May 1990
231 global tree. The tree consists of a root connected to a number of
232 labeled nodes via edges. Each node may, in turn, have children of
233 its own which are labeled. In this case, we may term the node a
234 subtree. This process may continue to an arbitrary level of depth.
235 Central to the notion of the OBJECT IDENTIFIER is the understanding
236 that administrative control of the meanings assigned to the nodes may
237 be delegated as one traverses the tree. A label is a pairing of a
238 brief textual description and an integer.
240 The root node itself is unlabeled, but has at least three children
241 directly under it: one node is administered by the International
242 Organization for Standardization, with label iso(1); another is
243 administrated by the International Telegraph and Telephone
244 Consultative Committee, with label ccitt(0); and the third is jointly
245 administered by the ISO and the CCITT, joint-iso-ccitt(2).
247 Under the iso(1) node, the ISO has designated one subtree for use by
248 other (inter)national organizations, org(3). Of the children nodes
249 present, two have been assigned to the U.S. National Institutes of
250 Standards and Technology. One of these subtrees has been transferred
251 by the NIST to the U.S. Department of Defense, dod(6).
253 As of this writing, the DoD has not indicated how it will manage its
254 subtree of OBJECT IDENTIFIERs. This memo assumes that DoD will
255 allocate a node to the Internet community, to be administered by the
256 Internet Activities Board (IAB) as follows:
258 internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
260 That is, the Internet subtree of OBJECT IDENTIFIERs starts with the
265 This memo, as a standard approved by the IAB, now specifies the
266 policy under which this subtree of OBJECT IDENTIFIERs is
267 administered. Initially, four nodes are present:
269 directory OBJECT IDENTIFIER ::= { internet 1 }
270 mgmt OBJECT IDENTIFIER ::= { internet 2 }
271 experimental OBJECT IDENTIFIER ::= { internet 3 }
272 private OBJECT IDENTIFIER ::= { internet 4 }
276 The directory(1) subtree is reserved for use with a future memo that
277 discusses how the OSI Directory may be used in the Internet.
282 Rose & McCloghrie [Page 5]
284 RFC 1155 SMI May 1990
289 The mgmt(2) subtree is used to identify objects which are defined in
290 IAB-approved documents. Administration of the mgmt(2) subtree is
291 delegated by the IAB to the Internet Assigned Numbers Authority for
292 the Internet. As RFCs which define new versions of the Internet-
293 standard Management Information Base are approved, they are assigned
294 an OBJECT IDENTIFIER by the Internet Assigned Numbers Authority for
295 identifying the objects defined by that memo.
297 For example, the RFC which defines the initial Internet standard MIB
298 would be assigned management document number 1. This RFC would use
299 the OBJECT IDENTIFIER
307 in defining the Internet-standard MIB.
309 The generation of new versions of the Internet-standard MIB is a
310 rigorous process. Section 5 of this memo describes the rules used
311 when a new version is defined.
315 The experimental(3) subtree is used to identify objects used in
316 Internet experiments. Administration of the experimental(3) subtree
317 is delegated by the IAB to the Internet Assigned Numbers Authority of
320 For example, an experimenter might received number 17, and would have
321 available the OBJECT IDENTIFIER
331 As a part of the assignment process, the Internet Assigned Numbers
332 Authority may make requirements as to how that subtree is used.
338 Rose & McCloghrie [Page 6]
340 RFC 1155 SMI May 1990
345 The private(4) subtree is used to identify objects defined
346 unilaterally. Administration of the private(4) subtree is delegated
347 by the IAB to the Internet Assigned Numbers Authority for the
348 Internet. Initially, this subtree has at least one child:
350 enterprises OBJECT IDENTIFIER ::= { private 1 }
352 The enterprises(1) subtree is used, among other things, to permit
353 parties providing networking subsystems to register models of their
356 Upon receiving a subtree, the enterprise may, for example, define new
357 MIB objects in this subtree. In addition, it is strongly recommended
358 that the enterprise will also register its networking subsystems
359 under this subtree, in order to provide an unambiguous identification
360 mechanism for use in management protocols. For example, if the
361 "Flintstones, Inc." enterprise produced networking subsystems, then
362 they could request a node under the enterprises subtree from the
363 Internet Assigned Numbers Authority. Such a node might be numbered:
367 The "Flintstones, Inc." enterprise might then register their "Fred
368 Router" under the name of:
374 Syntax is used to define the structure corresponding to object types.
375 ASN.1 constructs are used to define this structure, although the full
376 generality of ASN.1 is not permitted.
378 The ASN.1 type ObjectSyntax defines the different syntaxes which may
379 be used in defining an object type.
381 3.2.1. Primitive Types
383 Only the ASN.1 primitive types INTEGER, OCTET STRING, OBJECT
384 IDENTIFIER, and NULL are permitted. These are sometimes referred to
385 as non-aggregate types.
387 3.2.1.1. Guidelines for Enumerated INTEGERs
389 If an enumerated INTEGER is listed as an object type, then a named-
390 number having the value 0 shall not be present in the list of
394 Rose & McCloghrie [Page 7]
396 RFC 1155 SMI May 1990
399 enumerations. Use of this value is prohibited.
401 3.2.2. Constructor Types
403 The ASN.1 constructor type SEQUENCE is permitted, providing that it
404 is used to generate either lists or tables.
406 For lists, the syntax takes the form:
408 SEQUENCE { <type1>, ..., <typeN> }
410 where each <type> resolves to one of the ASN.1 primitive types listed
411 above. Further, these ASN.1 types are always present (the DEFAULT
412 and OPTIONAL clauses do not appear in the SEQUENCE definition).
414 For tables, the syntax takes the form:
418 where <entry> resolves to a list constructor.
420 Lists and tables are sometimes referred to as aggregate types.
424 In addition, new application-wide types may be defined, so long as
425 they resolve into an IMPLICITly defined ASN.1 primitive type, list,
426 table, or some other application-wide type. Initially, few
427 application-wide types are defined. Future memos will no doubt
428 define others once a consensus is reached.
430 3.2.3.1. NetworkAddress
432 This CHOICE represents an address from one of possibly several
433 protocol families. Currently, only one protocol family, the Internet
434 family, is present in this CHOICE.
438 This application-wide type represents a 32-bit internet address. It
439 is represented as an OCTET STRING of length 4, in network byte-order.
441 When this ASN.1 type is encoded using the ASN.1 basic encoding rules,
442 only the primitive encoding form shall be used.
446 This application-wide type represents a non-negative integer which
450 Rose & McCloghrie [Page 8]
452 RFC 1155 SMI May 1990
455 monotonically increases until it reaches a maximum value, when it
456 wraps around and starts increasing again from zero. This memo
457 specifies a maximum value of 2^32-1 (4294967295 decimal) for
462 This application-wide type represents a non-negative integer, which
463 may increase or decrease, but which latches at a maximum value. This
464 memo specifies a maximum value of 2^32-1 (4294967295 decimal) for
469 This application-wide type represents a non-negative integer which
470 counts the time in hundredths of a second since some epoch. When
471 object types are defined in the MIB which use this ASN.1 type, the
472 description of the object type identifies the reference epoch.
476 This application-wide type supports the capability to pass arbitrary
477 ASN.1 syntax. A value is encoded using the ASN.1 basic rules into a
478 string of octets. This, in turn, is encoded as an OCTET STRING, in
479 effect "double-wrapping" the original ASN.1 value.
481 Note that a conforming implementation need only be able to accept and
482 recognize opaquely-encoded data. It need not be able to unwrap the
483 data and then interpret its contents.
485 Further note that by use of the ASN.1 EXTERNAL type, encodings other
486 than ASN.1 may be used in opaquely-encoded data.
490 Once an instance of an object type has been identified, its value may
491 be transmitted by applying the basic encoding rules of ASN.1 to the
492 syntax for the object type.
506 Rose & McCloghrie [Page 9]
508 RFC 1155 SMI May 1990
513 Although it is not the purpose of this memo to define objects in the
514 MIB, this memo specifies a format to be used by other memos which
515 define these objects.
517 An object type definition consists of five fields:
521 A textual name, termed the OBJECT DESCRIPTOR, for the object type,
522 along with its corresponding OBJECT IDENTIFIER.
525 The abstract syntax for the object type. This must resolve to an
526 instance of the ASN.1 type ObjectSyntax (defined below).
529 A textual description of the semantics of the object type.
530 Implementations should ensure that their instance of the object
531 fulfills this definition since this MIB is intended for use in
532 multi-vendor environments. As such it is vital that objects have
533 consistent meaning across all machines.
536 One of read-only, read-write, write-only, or not-accessible.
539 One of mandatory, optional, or obsolete.
541 Future memos may also specify other fields for the objects which they
544 4.1. Guidelines for Object Names
546 No object type in the Internet-Standard MIB shall use a sub-
547 identifier of 0 in its name. This value is reserved for use with
550 Each OBJECT DESCRIPTOR corresponding to an object type in the
551 internet-standard MIB shall be a unique, but mnemonic, printable
552 string. This promotes a common language for humans to use when
553 discussing the MIB and also facilitates simple table mappings for
556 4.2. Object Types and Instances
558 An object type is a definition of a kind of managed object; it is
562 Rose & McCloghrie [Page 10]
564 RFC 1155 SMI May 1990
567 declarative in nature. In contrast, an object instance is an
568 instantiation of an object type which has been bound to a value. For
569 example, the notion of an entry in a routing table might be defined
570 in the MIB. Such a notion corresponds to an object type; individual
571 entries in a particular routing table which exist at some time are
572 object instances of that object type.
574 A collection of object types is defined in the MIB. Each such
575 subject type is uniquely named by its OBJECT IDENTIFIER and also has
576 a textual name, which is its OBJECT DESCRIPTOR. The means whereby
577 object instances are referenced is not defined in the MIB. Reference
578 to object instances is achieved by a protocol-specific mechanism: it
579 is the responsibility of each management protocol adhering to the SMI
580 to define this mechanism.
582 An object type may be defined in the MIB such that an instance of
583 that object type represents an aggregation of information also
584 represented by instances of some number of "subordinate" object
585 types. For example, suppose the following object types are defined
591 atIndex { atEntry 1 }
597 The interface number for the physical address.
608 atPhysAddress { atEntry 2 }
614 The media-dependent physical address.
618 Rose & McCloghrie [Page 11]
620 RFC 1155 SMI May 1990
632 atNetAddress { atEntry 3 }
638 The network address corresponding to the media-dependent physical
647 Then, a fourth object type might also be defined in the MIB:
652 atEntry { atTable 1 }
656 AtEntry ::= SEQUENCE {
666 An entry in the address translation table.
674 Rose & McCloghrie [Page 12]
676 RFC 1155 SMI May 1990
682 Each instance of this object type comprises information represented
683 by instances of the former three object types. An object type
684 defined in this way is called a list.
686 Similarly, tables can be formed by aggregations of a list type. For
687 example, a fifth object type might also be defined in the MIB:
698 The address translation table.
706 such that each instance of the atTable object comprises information
707 represented by the set of atEntry object types that collectively
708 constitute a given atTable object instance, that is, a given address
711 Consider how one might refer to a simple object within a table.
712 Continuing with the previous example, one might name the object type
716 and specify, using a protocol-specific mechanism, the object instance
718 { atNetAddress } = { internet "10.0.0.52" }
720 This pairing of object type and object instance would refer to all
721 instances of atPhysAddress which are part of any entry in some
722 address translation table for which the associated atNetAddress value
723 is { internet "10.0.0.52" }.
725 To continue with this example, consider how one might refer to an
726 aggregate object (list) within a table. Naming the object type
730 Rose & McCloghrie [Page 13]
732 RFC 1155 SMI May 1990
737 and specifying, using a protocol-specific mechanism, the object
740 { atNetAddress } = { internet "10.0.0.52" }
742 refers to all instances of entries in the table for which the
743 associated atNetAddress value is { internet "10.0.0.52" }.
745 Each management protocol must provide a mechanism for accessing
746 simple (non-aggregate) object types. Each management protocol
747 specifies whether or not it supports access to aggregate object
748 types. Further, the protocol must specify which instances are
749 "returned" when an object type/instance pairing refers to more than
750 one instance of a type.
752 To afford support for a variety of management protocols, all
753 information by which instances of a given object type may be usefully
754 distinguished, one from another, is represented by instances of
755 object types defined in the MIB.
757 4.3. Macros for Managed Objects
759 In order to facilitate the use of tools for processing the definition
760 of the MIB, the OBJECT-TYPE macro may be used. This macro permits
761 the key aspects of an object type to be represented in a formal way.
763 OBJECT-TYPE MACRO ::=
765 TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax)
768 VALUE NOTATION ::= value (VALUE ObjectName)
770 Access ::= "read-only"
774 Status ::= "mandatory"
779 Given the object types defined earlier, we might imagine the
780 following definitions being present in the MIB:
786 Rose & McCloghrie [Page 14]
788 RFC 1155 SMI May 1990
796 atPhysAddress OBJECT-TYPE
802 atNetAddress OBJECT-TYPE
803 SYNTAX NetworkAddress
815 SYNTAX SEQUENCE OF AtEntry
820 AtEntry ::= SEQUENCE {
829 The first five definitions describe object types, relating, for
830 example, the OBJECT DESCRIPTOR atIndex to the OBJECT IDENTIFIER {
831 atEntry 1 }. In addition, the syntax of this object is defined
832 (INTEGER) along with the access permitted (read-write) and status
833 (mandatory). The sixth definition describes an ASN.1 type called
842 Rose & McCloghrie [Page 15]
844 RFC 1155 SMI May 1990
847 5. Extensions to the MIB
849 Every Internet-standard MIB document obsoletes all previous such
850 documents. The portion of a name, termed the tail, following the
853 { mgmt version-number }
855 used to name objects shall remain unchanged between versions. New
858 (1) declare old object types obsolete (if necessary), but not
861 (2) augment the definition of an object type corresponding to a
862 list by appending non-aggregate object types to the object types
865 (3) define entirely new object types.
867 New versions may not:
869 (1) change the semantics of any previously defined object without
870 changing the name of that object.
872 These rules are important because they admit easier support for
873 multiple versions of the Internet-standard MIB. In particular, the
874 semantics associated with the tail of a name remain constant
875 throughout different versions of the MIB. Because multiple versions
876 of the MIB may thus coincide in "tail-space," implementations
877 supporting multiple versions of the MIB can be vastly simplified.
879 However, as a consequence, a management agent might return an
880 instance corresponding to a superset of the expected object type.
881 Following the principle of robustness, in this exceptional case, a
882 manager should ignore any additional information beyond the
883 definition of the expected object type. However, the robustness
884 principle requires that one exercise care with respect to control
885 actions: if an instance does not have the same syntax as its
886 expected object type, then those control actions must fail. In both
887 the monitoring and control cases, the name of an object returned by
888 an operation must be identical to the name requested by an operation.
898 Rose & McCloghrie [Page 16]
900 RFC 1155 SMI May 1990
905 RFC1155-SMI DEFINITIONS ::= BEGIN
907 EXPORTS -- EVERYTHING
908 internet, directory, mgmt,
909 experimental, private, enterprises,
910 OBJECT-TYPE, ObjectName, ObjectSyntax, SimpleSyntax,
911 ApplicationSyntax, NetworkAddress, IpAddress,
912 Counter, Gauge, TimeTicks, Opaque;
914 -- the path to the root
916 internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
918 directory OBJECT IDENTIFIER ::= { internet 1 }
920 mgmt OBJECT IDENTIFIER ::= { internet 2 }
922 experimental OBJECT IDENTIFIER ::= { internet 3 }
924 private OBJECT IDENTIFIER ::= { internet 4 }
925 enterprises OBJECT IDENTIFIER ::= { private 1 }
928 -- definition of object types
930 OBJECT-TYPE MACRO ::=
932 TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax)
935 VALUE NOTATION ::= value (VALUE ObjectName)
937 Access ::= "read-only"
941 Status ::= "mandatory"
946 -- names of objects in the MIB
954 Rose & McCloghrie [Page 17]
956 RFC 1155 SMI May 1990
959 -- syntax of objects in the MIB
966 -- note that simple SEQUENCEs are not directly
967 -- mentioned here to keep things simple (i.e.,
968 -- prevent mis-use). However, application-wide
969 -- types which are IMPLICITly encoded simple
970 -- SEQUENCEs may appear in the following CHOICE
991 ApplicationSyntax ::=
1010 Rose & McCloghrie [Page 18]
1012 RFC 1155 SMI May 1990
1015 -- other application-wide types, as they are
1016 -- defined, will be added here
1020 -- application-wide types
1029 [APPLICATION 0] -- in network-byte order
1030 IMPLICIT OCTET STRING (SIZE (4))
1034 IMPLICIT INTEGER (0..4294967295)
1038 IMPLICIT INTEGER (0..4294967295)
1042 IMPLICIT INTEGER (0..4294967295)
1045 [APPLICATION 4] -- arbitrary ASN.1 value,
1046 IMPLICIT OCTET STRING -- "double-wrapped"
1066 Rose & McCloghrie [Page 19]
1068 RFC 1155 SMI May 1990
1073 This memo was influenced by three sets of contributors to earlier
1076 First, Lee Labarre of the MITRE Corporation, who as author of the
1077 NETMAN SMI [4], presented the basic roadmap for the SMI.
1079 Second, several individuals who provided valuable comments on this
1080 memo prior to its initial distribution:
1082 James R. Davin, Proteon
1083 Mark S. Fedor, NYSERNet
1084 Craig Partridge, BBN Laboratories
1085 Martin Lee Schoffstall, Rensselaer Polytechnic Institute
1086 Wengyik Yeong, NYSERNet
1089 Third, the IETF MIB working group:
1091 Karl Auerbach, Epilogue Technology
1092 K. Ramesh Babu, Excelan
1093 Lawrence Besaw, Hewlett-Packard
1094 Jeffrey D. Case, University of Tennessee at Knoxville
1095 James R. Davin, Proteon
1096 Mark S. Fedor, NYSERNet
1098 Phill Gross, The MITRE Corporation
1099 Bent Torp Jensen, Convergent Technology
1100 Lee Labarre, The MITRE Corporation
1101 Dan Lynch, Advanced Computing Environments
1102 Keith McCloghrie, The Wollongong Group
1103 Dave Mackie, 3Com/Bridge
1104 Craig Partridge, BBN (chair)
1105 Jim Robertson, 3Com/Bridge
1106 Marshall T. Rose, The Wollongong Group
1108 Martin Lee Schoffstall, Rensselaer Polytechnic Institute
1110 Dean Throop, Data General
1111 Unni Warrier, Unisys
1122 Rose & McCloghrie [Page 20]
1124 RFC 1155 SMI May 1990
1129 [1] Information processing systems - Open Systems Interconnection,
1130 "Specification of Abstract Syntax Notation One (ASN.1)",
1131 International Organization for Standardization, International
1132 Standard 8824, December 1987.
1134 [2] McCloghrie K., and M. Rose, "Management Information Base for
1135 Network Management of TCP/IP-based Internets", RFC 1156,
1136 Performance Systems International and Hughes LAN Systems, May
1139 [3] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple
1140 Network Management Protocol", RFC 1157, University of Tennessee
1141 at Knoxville, Performance Systems International, Performance
1142 Systems International, and the MIT Laboratory for Computer
1145 [4] LaBarre, L., "Structure and Identification of Management
1146 Information for the Internet", Internet Engineering Task Force
1147 working note, Network Information Center, SRI International,
1148 Menlo Park, California, April 1988.
1150 [5] Cerf, V., "IAB Recommendations for the Development of Internet
1151 Network Management Standards", RFC 1052, IAB, April 1988.
1153 [6] Cerf, V., "Report of the Second Ad Hoc Network Management Review
1154 Group", RFC 1109, IAB, August 1989.
1156 [7] Information processing systems - Open Systems Interconnection,
1157 "Specification of Basic Encoding Rules for Abstract Notation One
1158 (ASN.1)", International Organization for Standardization,
1159 International Standard 8825, December 1987.
1161 Security Considerations
1163 Security issues are not discussed in this memo.
1178 Rose & McCloghrie [Page 21]
1180 RFC 1155 SMI May 1990
1187 PSI California Office
1189 Mountain View, CA 94039
1191 Phone: (415) 961-3380
1193 EMail: mrose@PSI.COM
1197 The Wollongong Group
1198 1129 San Antonio Road
1201 Phone: (415) 962-7160
1203 EMail: sytek!kzm@HPLABS.HP.COM
1234 Rose & McCloghrie [Page 22]