As per Relevance of the word instance, we have this rfc below:
Network Working Group M.
Request for Comments: 1155 Performance Systems
Obsoletes: RFC 1065 K.
Hughes LAN
May 1990
Structure and Identification of Management
for TCP/IP-based
Table of
1. Status of this Memo ............................................. 1
2. Introduction .................................................... 2
3. Structure and Identification of Management Information........... 4
3.1 Names .......................................................... 4
3.1.1 Directory .................................................... 5
3.1.2 Mgmt ......................................................... 6
3.1.3 Experimental ................................................. 6
3.1.4 Private ...................................................... 7
3.2 Syntax ......................................................... 7
3.2.1 Primitive Types .............................................. 7
3.2.1.1 Guidelines for Enumerated INTEGERs ......................... 7
3.2.2 Constructor Types ............................................ 8
3.2.3 Defined Types ................................................ 8
3.2.3.1 NetworkAddress ............................................. 8
3.2.3.2 IpAddress .................................................. 8
3.2.3.3 Counter .................................................... 8
3.2.3.4 Gauge ...................................................... 9
3.2.3.5 TimeTicks .................................................. 9
3.2.3.6 Opaque ..................................................... 9
3.3 Encodings ...................................................... 9
4. Managed Objects ................................................. 10
4.1 Guidelines for Object Names .................................... 10
4.2 Object Types and Instances ..................................... 10
4.3 Macros for Managed Objects ..................................... 14
5. Extensions to the MIB ........................................... 16
6. Definitions ..................................................... 17
7. Acknowledgements ................................................ 20
8. References ...................................................... 21
9. Security Considerations.......................................... 21
10. Authors' Addresses.............................................. 22
1. Status of this
This RFC is a re-release of RFC 1065, with a changed "Status of
Memo", plus a few minor typographical corrections. The
Rose & McCloghrie [Page 1]
RFC 1155 SMI May 1990
content of the document is unchanged from RFC 1065.
This memo provides the common definitions for the structure
identification of management information for TCP/IP-based internets
In particular, together with its companion memos which describe
management information base along with the network
protocol, these documents provide a simple, workable architecture
system for managing TCP/IP-based internets and in particular,
Internet
This memo specifies a Standard Protocol for the Internet community
Its status is "Recommended". TCP/IP implementations in the
which are network manageable are expected to adopt and implement
specification
The Internet Activities Board recommends that all IP and
implementations be network manageable. This implies
of the Internet MIB (RFC-1156) and at least one of the
recommended management protocols SNMP (RFC-1157) or CMOT (RFC-1095).
It should be noted that, at this time, SNMP is a full
standard and CMOT is a draft standard. See also the Host and
Requirements RFCs for more specific information on the
of this standard
Please refer to the latest edition of the "IAB Official
Standards" RFC for current information on the state and status
standard Internet protocols
Distribution of this memo is unlimited
2.
This memo describes the common structures and identification
for the definition of management information used in
TCP/IP-based internets. Included are descriptions of an
information model for network management along with a set of
types used to describe management information. Formal
of the structure are given using Abstract Syntax Notation One (ASN.1)
[1].
This memo is largely concerned with organizational concerns
administrative policy: it neither specifies the objects which
managed, nor the protocols used to manage those objects.
concerns are addressed by two companion memos: one describing
Management Information Base (MIB) [2], and the other describing
Simple Network Management Protocol (SNMP) [3].
This memo is based in part on the work of the Internet
Rose & McCloghrie [Page 2]
RFC 1155 SMI May 1990
Task Force, particularly the working note titled "Structure
Identification of Management Information for the Internet" [4].
memo uses a skeletal structure derived from that note, but differs
one very significant way: that note focuses entirely on the use
OSI-style network management. As such, it is not suitable for
with SNMP
This memo attempts to achieve two goals: simplicity
extensibility. Both are motivated by a common concern: although
management of TCP/IP-based internets has been a topic of study
some time, the authors do not feel that the depth and breadth of
understanding is complete. More bluntly, we feel that
experiences, while giving the community insight, are
conclusive. By fostering a simple SMI, the minimal number
constraints are imposed on future potential approaches; further,
fostering an extensible SMI, the maximal number of
approaches are available for experimentation
It is believed that this memo and its two companions comply with
guidelines set forth in RFC 1052, "IAB Recommendations for
Development of Internet Network Management Standards" [5] and
1109, "Report of the Second Ad Hoc Network Management Review Group
[6]. In particular, we feel that this memo, along with the
describing the management information base, provide a solid basis
network management of the Internet
Rose & McCloghrie [Page 3]
RFC 1155 SMI May 1990
3. Structure and Identification of Management
Managed objects are accessed via a virtual information store,
the Management Information Base or MIB. Objects in the MIB
defined using Abstract Syntax Notation One (ASN.1) [1].
Each type of object (termed an object type) has a name, a syntax,
an encoding. The name is represented uniquely as an
IDENTIFIER. An OBJECT IDENTIFIER is an administratively
name. The administrative policies used for assigning names
discussed later in this memo
The syntax for an object type defines the abstract data
corresponding to that object type. For example, the structure of
given object type might be an INTEGER or OCTET STRING. Although
general, we should permit any ASN.1 construct to be available for
in defining the syntax of an object type, this memo
restricts the ASN.1 constructs which may be used. These
are made solely for the sake of simplicity
The encoding of an object type is simply how instances of that
type are represented using the object's type syntax. Implicitly
to the notion of an object's syntax and encoding is how the object
represented when being transmitted on the network. This
specifies the use of the basic encoding rules of ASN.1 [7].
It is beyond the scope of this memo to define either the MIB used
network management or the network management protocol. As
earlier, these tasks are left to companion memos. This memo
to minimize the restrictions placed upon its companions so as
maximize generality. However, in some cases, restrictions have
made (e.g., the syntax which may be used when defining object
in the MIB) in order to encourage a particular style of management
Future editions of this memo may remove these restrictions
3.1.
Names are used to identify managed objects. This memo
names which are hierarchical in nature. The OBJECT
concept is used to model this notion. An OBJECT IDENTIFIER can
used for purposes other than naming managed object types;
example, each international standard has an OBJECT
assigned to it for the purposes of identification. In short,
IDENTIFIERs are a means for identifying some object, regardless
the semantics associated with the object (e.g., a network object,
standards document, etc.)
An OBJECT IDENTIFIER is a sequence of integers which traverse
Rose & McCloghrie [Page 4]
RFC 1155 SMI May 1990
global tree. The tree consists of a root connected to a number
labeled nodes via edges. Each node may, in turn, have children
its own which are labeled. In this case, we may term the node
subtree. This process may continue to an arbitrary level of depth
Central to the notion of the OBJECT IDENTIFIER is the
that administrative control of the meanings assigned to the nodes
be delegated as one traverses the tree. A label is a pairing of
brief textual description and an integer
The root node itself is unlabeled, but has at least three
directly under it: one node is administered by the
Organization for Standardization, with label iso(1); another
administrated by the International Telegraph and
Consultative Committee, with label ccitt(0); and the third is
administered by the ISO and the CCITT, joint-iso-ccitt(2).
Under the iso(1) node, the ISO has designated one subtree for use
other (inter)national organizations, org(3). Of the children
present, two have been assigned to the U.S. National Institutes
Standards and Technology. One of these subtrees has been
by the NIST to the U.S. Department of Defense, dod(6).
As of this writing, the DoD has not indicated how it will manage
subtree of OBJECT IDENTIFIERs. This memo assumes that DoD
allocate a node to the Internet community, to be administered by
Internet Activities Board (IAB) as follows
internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }
That is, the Internet subtree of OBJECT IDENTIFIERs starts with
prefix
1.3.6.1.
This memo, as a standard approved by the IAB, now specifies
policy under which this subtree of OBJECT IDENTIFIERs
administered. Initially, four nodes are present
directory OBJECT IDENTIFIER ::= { internet 1 }
mgmt OBJECT IDENTIFIER ::= { internet 2 }
experimental OBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 }
3.1.1.
The directory(1) subtree is reserved for use with a future memo
discusses how the OSI Directory may be used in the Internet
Rose & McCloghrie [Page 5]
RFC 1155 SMI May 1990
3.1.2.
The mgmt(2) subtree is used to identify objects which are defined
IAB-approved documents. Administration of the mgmt(2) subtree
delegated by the IAB to the Internet Assigned Numbers Authority
the Internet. As RFCs which define new versions of the Internet
standard Management Information Base are approved, they are
an OBJECT IDENTIFIER by the Internet Assigned Numbers Authority
identifying the objects defined by that memo
For example, the RFC which defines the initial Internet standard
would be assigned management document number 1. This RFC would
the OBJECT
{ mgmt 1 }
1.3.6.1.2.1
in defining the Internet-standard MIB
The generation of new versions of the Internet-standard MIB is
rigorous process. Section 5 of this memo describes the rules
when a new version is defined
3.1.3.
The experimental(3) subtree is used to identify objects used
Internet experiments. Administration of the experimental(3)
is delegated by the IAB to the Internet Assigned Numbers Authority
the Internet
For example, an experimenter might received number 17, and would
available the OBJECT
{ experimental 17 }
1.3.6.1.3.17
for use
As a part of the assignment process, the Internet Assigned
Authority may make requirements as to how that subtree is used
Rose & McCloghrie [Page 6]
RFC 1155 SMI May 1990
3.1.4.
The private(4) subtree is used to identify objects
unilaterally. Administration of the private(4) subtree is
by the IAB to the Internet Assigned Numbers Authority for
Internet. Initially, this subtree has at least one child
enterprises OBJECT IDENTIFIER ::= { private 1 }
The enterprises(1) subtree is used, among other things, to
parties providing networking subsystems to register models of
products
Upon receiving a subtree, the enterprise may, for example, define
MIB objects in this subtree. In addition, it is strongly
that the enterprise will also register its networking
under this subtree, in order to provide an unambiguous
mechanism for use in management protocols. For example, if
"Flintstones, Inc." enterprise produced networking subsystems,
they could request a node under the enterprises subtree from
Internet Assigned Numbers Authority. Such a node might be numbered
1.3.6.1.4.1.42
The "Flintstones, Inc." enterprise might then register their "
Router" under the name of
1.3.6.1.4.1.42.1.1
3.2.
Syntax is used to define the structure corresponding to object types
ASN.1 constructs are used to define this structure, although the
generality of ASN.1 is not permitted
The ASN.1 type ObjectSyntax defines the different syntaxes which
be used in defining an object type
3.2.1. Primitive
Only the ASN.1 primitive types INTEGER, OCTET STRING,
IDENTIFIER, and NULL are permitted. These are sometimes referred
as non-aggregate types
3.2.1.1. Guidelines for Enumerated
If an enumerated INTEGER is listed as an object type, then a named
number having the value 0 shall not be present in the list
Rose & McCloghrie [Page 7]
RFC 1155 SMI May 1990
enumerations. Use of this value is prohibited
3.2.2. Constructor
The ASN.1 constructor type SEQUENCE is permitted, providing that
is used to generate either lists or tables
For lists, the syntax takes the form
SEQUENCE { , ..., }
where each resolves to one of the ASN.1 primitive types
above. Further, these ASN.1 types are always present (the
and OPTIONAL clauses do not appear in the SEQUENCE definition).
For tables, the syntax takes the form
SEQUENCE OF
where resolves to a list constructor
Lists and tables are sometimes referred to as aggregate types
3.2.3. Defined
In addition, new application-wide types may be defined, so long
they resolve into an IMPLICITly defined ASN.1 primitive type, list
table, or some other application-wide type. Initially,
application-wide types are defined. Future memos will no
define others once a consensus is reached
3.2.3.1.
This CHOICE represents an address from one of possibly
protocol families. Currently, only one protocol family, the
family, is present in this CHOICE
3.2.3.2.
This application-wide type represents a 32-bit internet address.
is represented as an OCTET STRING of length 4, in network byte-order
When this ASN.1 type is encoded using the ASN.1 basic encoding rules
only the primitive encoding form shall be used
3.2.3.3.
This application-wide type represents a non-negative integer
Rose & McCloghrie [Page 8]
RFC 1155 SMI May 1990
monotonically increases until it reaches a maximum value, when
wraps around and starts increasing again from zero. This
specifies a maximum value of 2^32-1 (4294967295 decimal)
counters
3.2.3.4.
This application-wide type represents a non-negative integer,
may increase or decrease, but which latches at a maximum value.
memo specifies a maximum value of 2^32-1 (4294967295 decimal)
gauges
3.2.3.5.
This application-wide type represents a non-negative integer
counts the time in hundredths of a second since some epoch.
object types are defined in the MIB which use this ASN.1 type,
description of the object type identifies the reference epoch
3.2.3.6.
This application-wide type supports the capability to pass
ASN.1 syntax. A value is encoded using the ASN.1 basic rules into
string of octets. This, in turn, is encoded as an OCTET STRING,
effect "double-wrapping" the original ASN.1 value
Note that a conforming implementation need only be able to accept
recognize opaquely-encoded data. It need not be able to unwrap
data and then interpret its contents
Further note that by use of the ASN.1 EXTERNAL type, encodings
than ASN.1 may be used in opaquely-encoded data
3.3.
Once an instance of an object type has been identified, its value
be transmitted by applying the basic encoding rules of ASN.1 to
syntax for the object type
Rose & McCloghrie [Page 9]
RFC 1155 SMI May 1990
4. Managed
Although it is not the purpose of this memo to define objects in
MIB, this memo specifies a format to be used by other memos
define these objects
An object type definition consists of five fields
OBJECT
-------
A textual name, termed the OBJECT DESCRIPTOR, for the object type
along with its corresponding OBJECT IDENTIFIER
Syntax
The abstract syntax for the object type. This must resolve to
instance of the ASN.1 type ObjectSyntax (defined below).
Definition
A textual description of the semantics of the object type
Implementations should ensure that their instance of the
fulfills this definition since this MIB is intended for use
multi-vendor environments. As such it is vital that objects
consistent meaning across all machines
Access
One of read-only, read-write, write-only, or not-accessible
Status
One of mandatory, optional, or obsolete
Future memos may also specify other fields for the objects which
define
4.1. Guidelines for Object
No object type in the Internet-Standard MIB shall use a sub
identifier of 0 in its name. This value is reserved for use
future extensions
Each OBJECT DESCRIPTOR corresponding to an object type in
internet-standard MIB shall be a unique, but mnemonic,
string. This promotes a common language for humans to use
discussing the MIB and also facilitates simple table mappings
user interfaces
4.2. Object Types and
An object type is a definition of a kind of managed object; it
Rose & McCloghrie [Page 10]
RFC 1155 SMI May 1990
declarative in nature. In contrast, an object instance is
instantiation of an object type which has been bound to a value.
example, the notion of an entry in a routing table might be
in the MIB. Such a notion corresponds to an object type;
entries in a particular routing table which exist at some time
object instances of that object type
A collection of object types is defined in the MIB. Each
subject type is uniquely named by its OBJECT IDENTIFIER and also
a textual name, which is its OBJECT DESCRIPTOR. The means
object instances are referenced is not defined in the MIB.
to object instances is achieved by a protocol-specific mechanism:
is the responsibility of each management protocol adhering to the
to define this mechanism
An object type may be defined in the MIB such that an instance
that object type represents an aggregation of information
represented by instances of some number of "subordinate"
types. For example, suppose the following object types are
in the MIB
OBJECT
-------
atIndex { atEntry 1 }
Syntax
Definition
The interface number for the physical address
Access
read-write
Status
mandatory
OBJECT
-------
atPhysAddress { atEntry 2 }
Syntax
OCTET
Definition
The media-dependent physical address
Rose & McCloghrie [Page 11]
RFC 1155 SMI May 1990
Access
read-write
Status
mandatory
OBJECT
-------
atNetAddress { atEntry 3 }
Syntax
Definition
The network address corresponding to the media-dependent
address
Access
read-write
Status
mandatory
Then, a fourth object type might also be defined in the MIB
OBJECT
-------
atEntry { atTable 1 }
Syntax
AtEntry ::= SEQUENCE {
INTEGER
OCTET STRING
}
Definition
An entry in the address translation table
Access
read-write
Rose & McCloghrie [Page 12]
RFC 1155 SMI May 1990
Status
mandatory
Each instance of this object type comprises information
by instances of the former three object types. An object
defined in this way is called a list
Similarly, tables can be formed by aggregations of a list type.
example, a fifth object type might also be defined in the MIB
OBJECT
------
atTable { at 1 }
Syntax
SEQUENCE OF
Definition
The address translation table
Access
read-write
Status
mandatory
such that each instance of the atTable object comprises
represented by the set of atEntry object types that
constitute a given atTable object instance, that is, a given
translation table
Consider how one might refer to a simple object within a table
Continuing with the previous example, one might name the object
{ atPhysAddress }
and specify, using a protocol-specific mechanism, the object
{ atNetAddress } = { internet "10.0.0.52" }
This pairing of object type and object instance would refer to
instances of atPhysAddress which are part of any entry in
address translation table for which the associated atNetAddress
is { internet "10.0.0.52" }.
To continue with this example, consider how one might refer to
aggregate object (list) within a table. Naming the object
Rose & McCloghrie [Page 13]
RFC 1155 SMI May 1990
{ atEntry }
and specifying, using a protocol-specific mechanism, the
{ atNetAddress } = { internet "10.0.0.52" }
refers to all instances of entries in the table for which
associated atNetAddress value is { internet "10.0.0.52" }.
Each management protocol must provide a mechanism for
simple (non-aggregate) object types. Each management
specifies whether or not it supports access to aggregate
types. Further, the protocol must specify which instances
"returned" when an object type/instance pairing refers to more
one instance of a type
To afford support for a variety of management protocols,
information by which instances of a given object type may be
distinguished, one from another, is represented by instances
object types defined in the MIB
4.3. Macros for Managed
In order to facilitate the use of tools for processing the
of the MIB, the OBJECT-TYPE macro may be used. This macro
the key aspects of an object type to be represented in a formal way
OBJECT-TYPE MACRO ::=
TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax
"ACCESS"
"STATUS"
VALUE NOTATION ::= value (VALUE ObjectName
Access ::= "read-only
| "read-write
| "write-only
| "not-accessible
Status ::= "mandatory
| "optional
| "obsolete
Given the object types defined earlier, we might imagine
following definitions being present in the MIB
atIndex OBJECT-
Rose & McCloghrie [Page 14]
RFC 1155 SMI May 1990
SYNTAX
ACCESS read-
STATUS
::= { atEntry 1 }
atPhysAddress OBJECT-
SYNTAX OCTET
ACCESS read-
STATUS
::= { atEntry 2 }
atNetAddress OBJECT-
SYNTAX
ACCESS read-
STATUS
::= { atEntry 3 }
atEntry OBJECT-
SYNTAX
ACCESS read-
STATUS
::= { atTable 1 }
atTable OBJECT-
SYNTAX SEQUENCE OF
ACCESS read-
STATUS
::= { at 1 }
AtEntry ::= SEQUENCE {
INTEGER
OCTET STRING
}
The first five definitions describe object types, relating,
example, the OBJECT DESCRIPTOR atIndex to the OBJECT IDENTIFIER {
atEntry 1 }. In addition, the syntax of this object is
(INTEGER) along with the access permitted (read-write) and
(mandatory). The sixth definition describes an ASN.1 type
AtEntry
Rose & McCloghrie [Page 15]
RFC 1155 SMI May 1990
5. Extensions to the
Every Internet-standard MIB document obsoletes all previous
documents. The portion of a name, termed the tail, following
OBJECT
{ mgmt version-number }
used to name objects shall remain unchanged between versions.
versions may
(1) declare old object types obsolete (if necessary), but
delete their names
(2) augment the definition of an object type corresponding to
list by appending non-aggregate object types to the object
in the list; or
(3) define entirely new object types
New versions may not
(1) change the semantics of any previously defined object
changing the name of that object
These rules are important because they admit easier support
multiple versions of the Internet-standard MIB. In particular,
semantics associated with the tail of a name remain
throughout different versions of the MIB. Because multiple
of the MIB may thus coincide in "tail-space,"
supporting multiple versions of the MIB can be vastly simplified
However, as a consequence, a management agent might return
instance corresponding to a superset of the expected object type
Following the principle of robustness, in this exceptional case,
manager should ignore any additional information beyond
definition of the expected object type. However, the
principle requires that one exercise care with respect to
actions: if an instance does not have the same syntax as
expected object type, then those control actions must fail. In
the monitoring and control cases, the name of an object returned
an operation must be identical to the name requested by an operation
Rose & McCloghrie [Page 16]
RFC 1155 SMI May 1990
6.
RFC1155-SMI DEFINITIONS ::=
EXPORTS --
internet, directory, mgmt
experimental, private, enterprises
OBJECT-TYPE, ObjectName, ObjectSyntax, SimpleSyntax
ApplicationSyntax, NetworkAddress, IpAddress
Counter, Gauge, TimeTicks, Opaque
-- the path to the
internet OBJECT IDENTIFIER ::= { iso org(3) dod(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 }
-- definition of object
OBJECT-TYPE MACRO ::=
TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax
"ACCESS"
"STATUS"
VALUE NOTATION ::= value (VALUE ObjectName
Access ::= "read-only
| "read-write
| "write-only
| "not-accessible
Status ::= "mandatory
| "optional
| "obsolete
-- names of objects in the
ObjectName ::=
OBJECT
Rose & McCloghrie [Page 17]
RFC 1155 SMI May 1990
-- syntax of objects in the
ObjectSyntax ::=
CHOICE {
SimpleSyntax
-- note that simple SEQUENCEs are not
-- mentioned here to keep things simple (i.e.,
-- prevent mis-use). However, application-
-- types which are IMPLICITly encoded
-- SEQUENCEs may appear in the following
application-
}
SimpleSyntax ::=
CHOICE {
INTEGER
OCTET STRING
OBJECT IDENTIFIER
}
ApplicationSyntax ::=
CHOICE {
NetworkAddress
Counter
Gauge
TimeTicks
Rose & McCloghrie [Page 18]
RFC 1155 SMI May 1990
-- other application-wide types, as they
-- defined, will be added
}
-- application-wide
NetworkAddress ::=
CHOICE {
}
IpAddress ::=
[APPLICATION 0] -- in network-byte
IMPLICIT OCTET STRING (SIZE (4))
Counter ::=
[APPLICATION 1]
IMPLICIT INTEGER (0..4294967295)
Gauge ::=
[APPLICATION 2]
IMPLICIT INTEGER (0..4294967295)
TimeTicks ::=
[APPLICATION 3]
IMPLICIT INTEGER (0..4294967295)
Opaque ::=
[APPLICATION 4] -- arbitrary ASN.1 value
IMPLICIT OCTET STRING -- "double-wrapped
Rose & McCloghrie [Page 19]
RFC 1155 SMI May 1990
7.
This memo was influenced by three sets of contributors to
drafts
First, Lee Labarre of the MITRE Corporation, who as author of
NETMAN SMI [4], presented the basic roadmap for the SMI
Second, several individuals who provided valuable comments on
memo prior to its initial distribution
James R. Davin,
Mark S. Fedor,
Craig Partridge, BBN
Martin Lee Schoffstall, Rensselaer Polytechnic
Wengyik Yeong,
Third, the IETF MIB working group
Karl Auerbach, Epilogue
K. Ramesh Babu,
Lawrence Besaw, Hewlett-
Jeffrey D. Case, University of Tennessee at
James R. Davin,
Mark S. Fedor,
Robb Foster,
Phill Gross, The MITRE
Bent Torp Jensen, Convergent
Lee Labarre, The MITRE
Dan Lynch, Advanced Computing
Keith McCloghrie, The Wollongong
Dave Mackie, 3Com/
Craig Partridge, BBN (chair
Jim Robertson, 3Com/
Marshall T. Rose, The Wollongong
Greg Satz,
Martin Lee Schoffstall, Rensselaer Polytechnic
Lou Steinberg,
Dean Throop, Data
Unni Warrier,
Rose & McCloghrie [Page 20]
RFC 1155 SMI May 1990
8.
[1] Information processing systems - Open Systems Interconnection
"Specification of Abstract Syntax Notation One (ASN.1)",
International Organization for Standardization,
Standard 8824, December 1987.
[2] McCloghrie K., and M. Rose, "Management Information Base
Network Management of TCP/IP-based Internets", RFC 1156,
Performance Systems International and Hughes LAN Systems,
1990.
[3] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The
Network Management Protocol", RFC 1157, University of
at Knoxville, Performance Systems International,
Systems International, and the MIT Laboratory for
Science, May 1990.
[4] LaBarre, L., "Structure and Identification of
Information for the Internet", Internet Engineering Task
working note, Network Information Center, SRI International
Menlo Park, California, April 1988.
[5] Cerf, V., "IAB Recommendations for the Development of
Network Management Standards", RFC 1052, IAB, April 1988.
[6] Cerf, V., "Report of the Second Ad Hoc Network Management
Group", RFC 1109, IAB, August 1989.
[7] Information processing systems - Open Systems Interconnection
"Specification of Basic Encoding Rules for Abstract Notation
(ASN.1)", International Organization for Standardization
International Standard 8825, December 1987.
Security
Security issues are not discussed in this memo
Rose & McCloghrie [Page 21]
RFC 1155 SMI May 1990
Authors'
Marshall T.
PSI, Inc
PSI California
P.O. Box 391776
Mountain View, CA 94039
Phone: (415) 961-3380
EMail: mrose@PSI.
Keith
The Wollongong
1129 San Antonio
Palo Alto, CA 04303
Phone: (415) 962-7160
EMail: sytek!kzm@HPLABS.HP.
Rose & McCloghrie [Page 22]
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
