As per Relevance of the word definition, we have this rfc below:
Network Working Group M.
Request for Comments: 1212 Performance Systems
K.
Hughes LAN
March 1991
Concise MIB
Status of this
This memo defines a format for producing MIB modules. This
specifies an IAB standards track document for the Internet community
and requests discussion and suggestions for improvements.
refer to the current edition of the "IAB Official Protocol Standards
for the standardization state and status of this protocol
Distribution of this memo is unlimited
Table of
1. Abstract.............................................. 2
2. Historical Perspective ............................... 2
3. Columnar Objects ..................................... 3
3.1 Row Deletion ........................................ 4
3.2 Row Addition ........................................ 4
4. Defining Objects ..................................... 5
4.1 Mapping of the OBJECT-TYPE macro .................... 7
4.1.1 Mapping of the SYNTAX clause ...................... 7
4.1.2 Mapping of the ACCESS clause ...................... 8
4.1.3 Mapping of the STATUS clause ...................... 8
4.1.4 Mapping of the DESCRIPTION clause ................. 8
4.1.5 Mapping of the REFERENCE clause ................... 8
4.1.6 Mapping of the INDEX clause ....................... 8
4.1.7 Mapping of the DEFVAL clause ...................... 10
4.1.8 Mapping of the OBJECT-TYPE value .................. 11
4.2 Usage Example ....................................... 11
5. Appendix: DE-osifying MIBs ........................... 13
5.1 Managed Object Mapping .............................. 14
5.1.1 Mapping to the SYNTAX clause ...................... 15
5.1.2 Mapping to the ACCESS clause ...................... 15
5.1.3 Mapping to the STATUS clause ...................... 15
5.1.4 Mapping to the DESCRIPTION clause ................. 15
5.1.5 Mapping to the REFERENCE clause ................... 16
5.1.6 Mapping to the INDEX clause ....................... 16
5.1.7 Mapping to the DEFVAL clause ...................... 16
5.2 Action Mapping ...................................... 16
5.2.1 Mapping to the SYNTAX clause ...................... 16
5.2.2 Mapping to the ACCESS clause ...................... 16
SNMP Working Group [Page 1]
RFC 1212 Concise MIB Definitions March 1991
5.2.3 Mapping to the STATUS clause ...................... 16
5.2.4 Mapping to the DESCRIPTION clause ................. 16
5.2.5 Mapping to the REFERENCE clause ................... 16
6. Acknowledgements ..................................... 17
7. References ........................................... 18
8. Security Considerations............................... 19
9. Authors' Addresses.................................... 19
1.
This memo describes a straight-forward approach toward
concise, yet descriptive, MIB modules. It is intended that
future MIB modules be written in this format
2. Historical
As reported in RFC 1052, IAB Recommendations for the Development
Internet Network Management Standards [1], a two-prong strategy
network management of TCP/IP-based internets was undertaken. In
short-term, the Simple Network Management Protocol (SNMP), defined
RFC 1067, was to be used to manage nodes in the Internet community
In the long-term, the use of the OSI network management framework
to be examined. Two documents were produced to define the
information: RFC 1065, which defined the Structure of
Information (SMI), and RFC 1066, which defined the
Information Base (MIB). Both of these documents were designed so
to be compatible with both the SNMP and the OSI network
framework
This strategy was quite successful in the short-term: Internet-
network management technology was fielded, by both the research
commercial communities, within a few months. As a result of this
portions of the Internet community became network manageable in
timely fashion
As reported in RFC 1109, Report of the Second Ad Hoc
Management Review Group [2], the requirements of the SNMP and the
network management frameworks were more different than anticipated
As such, the requirement for compatibility between the SMI/MIB
both frameworks was suspended. This action permitted the
network management framework, based on the SNMP, to respond to
operational needs in the Internet community by producing MIB-II
In May of 1990, the core documents were elevated to "
Protocols" with "Recommended" status. As such, the Internet-
network management framework consists of: Structure
Identification of Management Information for TCP/IP-based internets
RFC 1155 [3], which describes how managed objects contained in
SNMP Working Group [Page 2]
RFC 1212 Concise MIB Definitions March 1991
MIB are defined; Management Information Base for Network
of TCP/IP-based internets, which describes the managed
contained in the MIB, RFC 1156 [4]; and, the Simple
Management Protocol, RFC 1157 [5], which defines the protocol used
manage these objects. Consistent with the IAB directive to
simple, workable systems in the short-term, the list of
objects defined in the Internet-standard MIB was derived by
only those elements which are considered essential. However, the
defined three extensibility mechanisms: one, the addition of
standard objects through the definitions of new versions of the MIB
two, the addition of widely-available but non-standard
through the experimental subtree; and three, the addition of
objects through the enterprises subtree. Such additional objects
not only be used for vendor-specific elements, but also
experimentation as required to further the knowledge of which
objects are essential
As more objects are defined using the second method, experience
shown that the resulting MIB descriptions contain
information. In order to provide for MIB descriptions which are
concise, and yet as informative, an enhancement is suggested.
enhancement allows the author of a MIB to remove the
information, while retaining the important descriptive text
Before presenting the approach, a brief presentation of
object handling by the SNMP is necessary. This explains and
motivates the value of the enhancement
3. Columnar
The SNMP supports operations on MIB objects whose syntax
ObjectSyntax as defined in the SMI. Informally stated,
operations apply exclusively to scalar objects. However, it
convenient for developers of management applications to
imaginary, tabular structures on the ordered collection of
that constitute the MIB. Each such conceptual table contains zero
more rows, and each row may contain one or more scalar objects
termed columnar objects. Historically, this conceptualization
been formalized by using the OBJECT-TYPE macro to define both
object which corresponds to a table and an object which
to a row in that table. (The ACCESS clause for such objects
"not-accessible", of course.) However, it must be emphasized that,
the protocol level, relationships among columnar objects in the
row is a matter of convention, not of protocol
Note that there are good reasons why the tabular structure is not
matter of protocol. Consider the operation of the SNMP Get-Next-
acting on the last columnar object of an instance of a
SNMP Working Group [Page 3]
RFC 1212 Concise MIB Definitions March 1991
row; it returns the next column of the first conceptual row or
first object instance occurring after the table. In contrast, if
rows were a matter of protocol, then it would instead return
error. By not returning an error, a single PDU exchange informs
manager that not only has the end of the conceptual row/table
reached, but also provides information on the next object instance
thereby increasing the information density of the PDU exchange
3.1. Row
Nonetheless, it is highly useful to provide a means whereby
conceptual row may be removed from a table. In MIB-II, this
achieved by defining, for each conceptual row, an integer-
columnar object. If a management station sets the value of
object to some value, usually termed "invalid", then the effect
one of invalidating the corresponding row in the table. However,
is an implementation-specific matter as to whether an agent
an invalidated entry from the table. Accordingly,
stations must be prepared to receive tabular information from
that corresponds to entries not currently in use.
interpretation of such entries requires examination of the
object indicating the in-use status
3.2. Row
It is also highly useful to have a clear understanding of how
conceptual row may be added to a table. In the SNMP, at the
level, a management station issues an SNMP set operation
an arbitrary set of variable bindings. In the case that an
detects that one or more of those variable bindings refers to
object instance not currently available in that agent, it may
according to the rules of the SNMP, behave according to any of
following paradigms
(1) It may reject the SNMP set operation as referring
non-existent object instances by returning a
with the error-status field set to "noSuchName" and
error-index field set to refer to the first
reference
(2) It may accept the SNMP set operation as requesting
creation of new object instances corresponding to
of the object instances named in the variable bindings
The value of each (potentially) newly created
instance is specified by the "value" component of
relevant variable binding. In this case, if the
specifies a value for a newly (or previously)
object that it deems inappropriate by reason of value
SNMP Working Group [Page 4]
RFC 1212 Concise MIB Definitions March 1991
syntax, then it rejects the SNMP set operation
responding with the error-status field set to
and the error-index field set to refer to the
offending variable binding
(3) It may accept the SNMP set operation and create
object instances as described in (2) above and,
addition, at its discretion, create supplemental
instances to complete a row in a conceptual table
which the new object instances specified in the
may be a part
It should be emphasized that all three of the above behaviors
fully conformant to the SNMP specification and are fully acceptable
subject to any restrictions which may be imposed by access
and/or the definitions of the MIB objects themselves
4. Defining
The Internet-standard SMI employs a two-level approach towards
definition. A MIB definition consists of two parts: a textual part
in which objects are placed into groups, and a MIB module, in
objects are described solely in terms of the ASN.1 macro OBJECT-TYPE
which is defined by the SMI
An example of the former definition might be
OBJECT
-------
sysLocation { system 6 }
Syntax
DisplayString (SIZE (0..255))
Definition
The physical location of this node (e.g., "
closet, 3rd floor").
Access
read-only
Status
mandatory
An example of the latter definition might be
sysLocation OBJECT-
SYNTAX DisplayString (SIZE (0..255))
SNMP Working Group [Page 5]
RFC 1212 Concise MIB Definitions March 1991
ACCESS read-
STATUS
::= { system 6 }
In the interests of brevity and to reduce the chance
editing errors, it would seem useful to combine the
definitions. This can be accomplished by defining
extension to the OBJECT-TYPE macro
FROM RFC1155-
FROM RFC1158-MIB
OBJECT-TYPE MACRO ::=
TYPE NOTATION ::=
-- must conform
-- RFC1155's
"SYNTAX" type(ObjectSyntax
"ACCESS"
"STATUS"
VALUE NOTATION ::= value (VALUE ObjectName
Access ::= "read-only
| "read-write
| "write-only
| "not-accessible
Status ::= "mandatory
| "optional
| "obsolete
| "deprecated
DescrPart ::=
"DESCRIPTION" value (description DisplayString
|
ReferPart ::=
"REFERENCE" value (reference DisplayString
|
IndexPart ::=
"INDEX" "{" IndexTypes "}"
SNMP Working Group [Page 6]
RFC 1212 Concise MIB Definitions March 1991
|
IndexTypes ::=
IndexType | IndexTypes ","
IndexType ::=
-- if indexobject, use the
-- value of the
-- OBJECT-TYPE
value (indexobject ObjectName
-- otherwise use named SMI
-- must conform to IndexSyntax
| type (indextype
DefValPart ::=
"DEFVAL" "{" value (defvalue ObjectSyntax) "}"
|
IndexSyntax ::=
CHOICE {
INTEGER (0..MAX),
OCTET STRING
OBJECT IDENTIFIER
NetworkAddress
}
4.1. Mapping of the OBJECT-TYPE
It should be noted that the expansion of the OBJECT-TYPE macro
something which conceptually happens during implementation and
during run-time
4.1.1. Mapping of the SYNTAX
The SYNTAX clause, which must be present, defines the abstract
structure corresponding to that object type. The ASN.1 language [6]
is used for this purpose. However, the SMI purposely restricts
ASN.1 constructs which may be used. These restrictions are
expressly for simplicity
SNMP Working Group [Page 7]
RFC 1212 Concise MIB Definitions March 1991
4.1.2. Mapping of the ACCESS
The ACCESS clause, which must be present, defines the minimum
of support required for that object type. As a local matter
implementations may support other access types (e.g.,
implementation may elect to permitting writing a variable marked
read-only). Further, protocol-specific "views" (e.g.,
indirectly implied by an SNMP community) may make
restrictions on access to a variable
4.1.3. Mapping of the STATUS
The STATUS clause, which must be present, defines the
support required for that object type
4.1.4. Mapping of the DESCRIPTION
The DESCRIPTION clause, which need not be present, contains a
definition of that object type which provides all
definitions necessary for implementation, and should embody
information which would otherwise be communicated in any ASN.1
commentary annotations associated with the object. Note that,
order to conform to the ASN.1 syntax, the entire value of this
must be enclosed in double quotation marks, although the value may
multi-line
Further, note that if the MIB module does not contain a
description of the object type elsewhere then the DESCRIPTION
must be present
4.1.5. Mapping of the REFERENCE
The REFERENCE clause, which need not be present, contains a
cross-reference to an object defined in some other MIB module.
is useful when de-osifying a MIB produced by some other organization
4.1.6. Mapping of the INDEX
The INDEX clause, which may be present only if that object
corresponds to a conceptual row, defines instance
information for that object type. (Historically, each MIB
contained a section entitled "Identification of OBJECT instances
use with the SNMP". By using the INDEX clause, this section need
longer occur as this clause concisely captures the precise
needed for instance identification.)
If the INDEX clause is not present, and the object type
to a non-columnar object, then instances of the object are
SNMP Working Group [Page 8]
RFC 1212 Concise MIB Definitions March 1991
by appending a sub-identifier of zero to the name of that object
Further, note that if the MIB module does not contain a
description of how instance identification information is derived
columnar objects, then the INDEX clause must be present
To define the instance identification information, determine
object value(s) will unambiguously distinguish a conceptual row.
syntax of those objects indicate how to form the instance-identifier
(1) integer-valued: a single sub-identifier taking
integer value (this works only for non-
integers);
(2) string-valued, fixed-length strings: `n' sub-identifiers
where `n' is the length of the string (each octet of
string is encoded in a separate sub-identifier);
(3) string-valued, variable-length strings: `n+1' sub
identifiers, where `n' is the length of the string (
first sub-identifier is `n' itself, following this,
octet of the string is encoded in a separate sub
identifier);
(4) object identifier-valued: `n+1' sub-identifiers,
`n' is the number of sub-identifiers in the value (
first sub-identifier is `n' itself, following this,
sub-identifier in the value is copied);
(5) NetworkAddress-valued: `n+1' sub-identifiers, where `n
depends on the kind of address being encoded (the
sub-identifier indicates the kind of address, value 1
indicates an IpAddress); or
(6) IpAddress-valued: 4 sub-identifiers, in the
a.b.c.d notation
Note that if an "indextype" value is present (e.g., INTEGER
than ifIndex), then a DESCRIPTION clause must be present; the
contained therein indicates the semantics of the "indextype" value
SNMP Working Group [Page 9]
RFC 1212 Concise MIB Definitions March 1991
By way of example, in the context of MIB-II [7], the following
clauses might be present
objects under INDEX
----------------- ------------
ifEntry { ifIndex }
atEntry { atNetIfIndex
atNetAddress }
ipAddrEntry { ipAdEntAddr }
ipRouteEntry { ipRouteDest }
ipNetToMediaEntry { ipNetToMediaIfIndex
ipNetToMediaNetAddress }
tcpConnEntry { tcpConnLocalAddress
tcpConnLocalPort
tcpConnRemoteAddress
tcpConnRemotePort }
udpEntry { udpLocalAddress
udpLocalPort }
egpNeighEntry { egpNeighAddr }
4.1.7. Mapping of the DEFVAL
The DEFVAL clause, which need not be present, defines an
default value which may be used when an object instance is created
the discretion of the agent acting in conformance with the
paradigm described in Section 4.2 above
During conceptual row creation, if an instance of a columnar
is not present as one of the operands in the correspondent SNMP
operation, then the value of the DEFVAL clause, if present,
an acceptable default value that the agent might use
The value of the DEFVAL clause must, of course, correspond to
SYNTAX clause for the object. Note that if an operand to the
set operation is an instance of a read-only object, then the
noSuchName will be returned. As such, the DEFVAL clause can be
to provide an acceptable default value that the agent might use
It is possible that no acceptable default value may exist for any
the columnar objects in a conceptual row for which the creation
new object instances is allowed. In this case, the objects
in the INDEX clause must have a corresponding ACCESS clause value
read-write
SNMP Working Group [Page 10]
RFC 1212 Concise MIB Definitions March 1991
By way of example, consider the following possible DEFVAL clauses
ObjectSyntax DEFVAL
----------------- ------------
INTEGER 1 -- same for Counter, Gauge,
OCTET STRING 'ffffffffffff'
DisplayString "any NVT ASCII string
OBJECT IDENTIFIER
OBJECT IDENTIFIER { system 2 }
NULL
NetworkAddress { internet 'c0210415'h }
IpAddress 'c0210415'h -- 192.33.4.21
4.1.8. Mapping of the OBJECT-TYPE
The value of an invocation of the OBJECT-TYPE macro is the name
the object, which is an object identifier
4.2. Usage
Consider how the ipNetToMediaTable from MIB-II might be
described
-- the IP Address Translation
-- The Address Translation tables contain IpAddress
-- "physical" address equivalences. Some interfaces do
-- use translation tables for determining address
-- (e.g., DDN-X.25 has an algorithmic method); if
-- interfaces are of this type, then the Address
-- table is empty, i.e., has zero entries
ipNetToMediaTable OBJECT-
SYNTAX SEQUENCE OF
ACCESS not-
STATUS
"The IP Address Translation table used for
from IP addresses to physical addresses."
::= { ip 22 }
ipNetToMediaEntry OBJECT-
SYNTAX
ACCESS not-
STATUS
"Each entry contains one IpAddress to 'physical
SNMP Working Group [Page 11]
RFC 1212 Concise MIB Definitions March 1991
address equivalence."
INDEX { ipNetToMediaIfIndex
ipNetToMediaNetAddress }
::= { ipNetToMediaTable 1 }
IpNetToMediaEntry ::=
SEQUENCE {
INTEGER
OCTET STRING
IpAddress
}
ipNetToMediaIfIndex OBJECT-
SYNTAX
ACCESS read-
STATUS
"The interface on which this entry's
is effective. The interface identified by
particular value of this index is the
interface as identified by the same value
ifIndex."
::= { ipNetToMediaEntry 1 }
ipNetToMediaPhysAddress OBJECT-
SYNTAX OCTET
ACCESS read-
STATUS
"The media-dependent 'physical' address."
::= { ipNetToMediaEntry 2 }
ipNetToMediaNetAddress OBJECT-
SYNTAX
ACCESS read-
STATUS
"The IpAddress corresponding to the media
dependent 'physical' address."
::= { ipNetToMediaEntry 3 }
ipNetToMediaType OBJECT-
SYNTAX INTEGER {
SNMP Working Group [Page 12]
RFC 1212 Concise MIB Definitions March 1991
other(1), -- none of the
invalid(2), -- an invalidated
dynamic(3),
static(4)
}
ACCESS read-
STATUS
"The type of mapping
Setting this object to the value invalid(2)
the effect of invalidating the corresponding
in the ipNetToMediaTable. That is, it
disassociates the interface identified with
entry from the mapping identified with said entry
It is an implementation-specific matter as
whether the agent removes an invalidated
from the table. Accordingly, management
must be prepared to receive tabular
from agents that corresponds to entries
currently in use. Proper interpretation of
entries requires examination of the
ipNetToMediaType object."
::= { ipNetToMediaEntry 4 }
5. Appendix: DE-osifying
There has been an increasing amount of work recently on taking
defined by other organizations (e.g., the IEEE) and de-osifying
for use with the Internet-standard network management framework.
steps to achieve this are straight-forward, though tedious.
course, it is helpful to already be experienced in writing
modules for use with the Internet-standard network
framework
The first step is to construct a skeletal MIB module, e.g.,
RFC1213-MIB DEFINITIONS ::=
experimental, OBJECT-TYPE,
FROM RFC1155-SMI
-- contact IANA for actual
root OBJECT IDENTIFIER ::= { experimental xx }
SNMP Working Group [Page 13]
RFC 1212 Concise MIB Definitions March 1991
The next step is to categorize the objects into groups.
experimental MIBs, optional objects are permitted. However, when
MIB module is placed in the Internet-standard space, these
objects are either removed, or placed in a optional group, which,
implemented, all objects in the group must be implemented. For
first pass, it is wisest to simply ignore any optional objects in
original MIB: experience shows it is better to define a core
module first, containing only essential objects; later, if
demands, other objects can be added
It must be emphasized that groups are "units of conformance" within
MIB: everything in a group is "mandatory" and implementations
either whole groups or none
5.1. Managed Object
Next for each managed object class, determine whether there can
multiple instances of that managed object class. If not, then
each of its attributes, use the OBJECT-TYPE macro to make
equivalent definition
Otherwise, if multiple instances of the managed object class
exist, then define a conceptual table having conceptual rows
containing a columnar object for each of the managed object class'
attributes. If the managed object class is contained within
containment tree of another managed object class, then the
of an object type is normally required for each of the "
attributes" of the containing managed object class. If they do
already exist within the MIB module, then they can be added via
definition of additional columnar objects in the conceptual
corresponding to the contained managed object class
In defining a conceptual row, it is useful to consider
optimization of network management operations which will act upon
columnar objects. In particular, it is wisest to avoid defining
columnar objects within a conceptual row, than can fit in a
PDU. As a rule of thumb, a conceptual row should contain no
than approximately 20 objects. Similarly, or as a way to abide
the "20 object guideline", columnar objects should be grouped
tables according to the expected grouping of network
operations upon them. As such, the content of conceptual rows
reflect typical access scenarios, e.g., they should be
along functional lines such as one row for statistics and another
for parameters, or along usage lines such as commonly-needed
versus rarely-needed objects
On the other hand, the definition of conceptual rows where the
of columnar objects used as indexes outnumbers the number used
SNMP Working Group [Page 14]
RFC 1212 Concise MIB Definitions March 1991
hold information, should also be avoided. In particular,
splitting of a managed object class's attributes into many
tables should not be used as a way to obtain the same degree
flexibility/complexity as is often found in MIB's with a myriad
optionals
5.1.1. Mapping to the SYNTAX
When mapping to the SYNTAX clause of the OBJECT-type macro
(1) An object with BOOLEAN syntax becomes an INTEGER
either of values true(1) or false(2).
(2) An object with ENUMERATED syntax becomes an INTEGER
taking any of the values given
(3) An object with BIT STRING syntax containing no more
32 bits becomes an INTEGER defined as a sum; otherwise
more than 32 bits are present, the object becomes
OCTET STRING, with the bits numbered from left-to-right
in which the least significant bits of the last octet
be "reserved for future use".
(4) An object with a character string syntax becomes
an OCTET STRING or a DisplayString, depending on
repertoire of the character string
(5) An non-tabular object with a complex syntax, such as
or EXTERNAL, must be decomposed, usually into an
STRING (if sensible). As a rule, any object with
complicated syntax should be avoided
(6) Tabular objects must be decomposed into rows of
objects
5.1.2. Mapping to the ACCESS
This is straight-forward
5.1.3. Mapping to the STATUS
This is usually straight-forward; however, some osified-MIBs use
term "recommended". In this case, a choice must be made
"mandatory" and "optional".
5.1.4. Mapping to the DESCRIPTION
This is straight-forward: simply copy the text, making sure that
SNMP Working Group [Page 15]
RFC 1212 Concise MIB Definitions March 1991
embedded double quotation marks are sanitized (i.e., replaced
single-quotes or removed).
5.1.5. Mapping to the REFERENCE
This is straight-forward: simply include a textual reference to
object being mapped, the document which defines the object,
perhaps a page number in the document
5.1.6. Mapping to the INDEX
Decide how instance-identifiers for columnar objects are to be
and define this clause accordingly
5.1.7. Mapping to the DEFVAL
Decide if a meaningful default value can be assigned to the
being mapped, and if so, define the DEFVAL clause accordingly
5.2. Action
Actions are modeled as read-write objects, in which writing
particular value results in the action taking place
5.2.1. Mapping to the SYNTAX
Usually an INTEGER syntax is used with a distinguished value
for each action that the object provides access to. In addition
there is usually one other distinguished value, which is the
returned when the object is read
5.2.2. Mapping to the ACCESS
Always use read-write
5.2.3. Mapping to the STATUS
This is straight-forward
5.2.4. Mapping to the DESCRIPTION
This is straight-forward: simply copy the text, making sure that
embedded double quotation marks are sanitized (i.e., replaced
single-quotes or removed).
5.2.5. Mapping to the REFERENCE
This is straight-forward: simply include a textual reference to
SNMP Working Group [Page 16]
RFC 1212 Concise MIB Definitions March 1991
action being mapped, the document which defines the action,
perhaps a page number in the document
6.
This document was produced by the SNMP Working Group
Anne Ambler,
Karl Auerbach,
Fred Baker,
Ken
Ron Broersma,
Jack Brown, US
Theodore Brunner,
Jeffrey Buffum,
John Burress,
Jeffrey D. Case, University of Tennessee at
Chris Chiptasso,
Paul Ciarfella,
Bob
John Cook,
Tracy Cox,
James R. Davin, MIT-
Eric Decker,
Kurt Dobbins,
Nadya El-Afandi, Network
Gary Ellis,
Fred
Mike
Mark S. Fedor,
Richard Fox,
Karen Frisa,
Chris Gunner,
Fred Harris, University of Tennessee at
Ken Hibbard,
Ole Jacobsen,
Ken
Satish Joshi,
Frank Kastenholz, Racal-
Shimshon Kaufman,
Ken Key, University of Tennessee at
Jim Kinder,
Alex Koifman,
Christopher Kolb,
Cheryl Krupczak,
Paul Langille,
Peter Lin,
John Lunny,
SNMP Working Group [Page 17]
RFC 1212 Concise MIB Definitions March 1991
Carl
Randy Mayhew, University of Tennessee at
Keith McCloghrie, Hughes LAN
Donna McMaster, David
Lynn Monsanto,
Dave Perkins, 3
Jim Reinstedler, Ungerman
Anil Rijsinghani,
Kathy Rinehart, Arnold
Kary
Marshall T. Rose, PSI (chair
L. Michael Sabo,
Jon Saperia,
Greg Satz,
Martin Schoffstall,
John
Steve Sherry,
Fei Shu,
Sam Sjogren,
Mark Sleeper,
Lance
Mike St.
Bob Stewart,
Emil
Kaj Tesink,
Dean Throop, Data
Bill Townsend,
Maurice Turcotte, Racal-
Kannan
Sudhanshu Verma,
Bill Versteeg, Network Research
Warren Vik, Interactive
David Waitzman,
Steve Waldbusser,
Dan
David
Wengyik Yeong,
Jeff Young, Cray
7.
[1] Cerf, V., "IAB Recommendations for the Development of
Network Management Standards", RFC 1052, NRI, April 1988.
[2] Cerf, V., "Report of the Second Ad Hoc Network Management
Group", RFC 1109, NRI, August 1989.
[3] Rose M., and K. McCloghrie, "Structure and Identification
SNMP Working Group [Page 18]
RFC 1212 Concise MIB Definitions March 1991
Management Information for TCP/IP-based internets", RFC 1155,
Performance Systems International, Hughes LAN Systems, May 1990.
[4] McCloghrie K., and M. Rose, "Management Information Base
Network Management of TCP/IP-based internets", RFC 1156,
LAN Systems, Performance Systems International, May 1990.
[5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "
Network Management Protocol", RFC 1157, SNMP Research
Performance Systems International, Performance
International, MIT Laboratory for Computer Science, May 1990.
[6] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization
Standard 8824, December 1987.
[7] Rose M., Editor, "Management Information Base for
Management of TCP/IP-based internets: MIB-II", RFC 1213,
Performance Systems International, March 1991.
8. Security
Security issues are not discussed in this memo
9. Authors'
Marshall T.
Performance Systems
5201 Great America
Suite 3106
Santa Clara, CA 95054
Phone: +1 408 562 6222
EMail: mrose@psi.
X.500: rose, psi,
Keith
Hughes LAN
1225 Charleston
Mountain View, CA 94043
1225 Charleston
Mountain View, CA 94043
Phone: (415) 966-7934
EMail: kzm@hls.
SNMP Working Group [Page 19]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
