Load cups into easysw/current.

git-svn-id: svn+ssh://src.apple.com/svn/cups/easysw/current@136 a1ca3aef-8c08-0410-bb20-df032aa958be

5 files changed, 6060 insertions, 3 deletions

diff --git a/standards/Makefile b/standards/Makefile
index c93db938b..c7bd373fc 100644
--- a/standards/Makefile
+++ b/standards/Makefile
@@ -1,5 +1,5 @@
 #
-# "$Id: Makefile 5229 2006-03-05 16:48:12Z mike $"
+# "$Id: Makefile 5409 2006-04-15 11:45:38Z mike $"
 #
 #   Standards makefile for the Common UNIX Printing System (CUPS).
 #
@@ -113,9 +113,9 @@ uninstall:
 
 rfctohtml:	rfctohtml.o ../cups/libcups.a
 	$(CC) $(LDFLAGS) -o $@ rfctohtml.o ../cups/libcups.a \
-		$(COMMONLIBS) $(LIBZ)
+		$(SSLLIBS) $(COMMONLIBS) $(LIBZ)
 
 
 #
-# End of "$Id: Makefile 5229 2006-03-05 16:48:12Z mike $".
+# End of "$Id: Makefile 5409 2006-04-15 11:45:38Z mike $".
 #
diff --git a/standards/X.690-0207.pdf b/standards/X.690-0207.pdf
new file mode 100644
index 000000000..8f88864a3
--- /dev/null
+++ b/standards/X.690-0207.pdf
diff --git a/standards/rfc1155.txt b/standards/rfc1155.txt
new file mode 100644
index 000000000..0e0f1b540
--- /dev/null
+++ b/standards/rfc1155.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Network Working Group                                            M. Rose
+Request for Comments:  1155            Performance Systems International
+Obsoletes:  RFC 1065                                       K. McCloghrie
+                                                      Hughes LAN Systems
+                                                                May 1990
+
+
+
+         Structure and Identification of Management Information
+                       for TCP/IP-based Internets
+
+                           Table of Contents
+
+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 Memo
+
+   This RFC is a re-release of RFC 1065, with a changed "Status of this
+   Memo", plus a few minor typographical corrections.  The technical
+
+
+
+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 and
+   identification of management information for TCP/IP-based internets.
+   In particular, together with its companion memos which describe the
+   management information base along with the network management
+   protocol, these documents provide a simple, workable architecture and
+   system for managing TCP/IP-based internets and in particular, the
+   Internet.
+
+   This memo specifies a Standard Protocol for the Internet community.
+   Its status is "Recommended".  TCP/IP implementations in the Internet
+   which are network manageable are expected to adopt and implement this
+   specification.
+
+   The Internet Activities Board recommends that all IP and TCP
+   implementations be network manageable.  This implies implementation
+   of the Internet MIB (RFC-1156) and at least one of the two
+   recommended management protocols SNMP (RFC-1157) or CMOT (RFC-1095).
+   It should be noted that, at this time, SNMP is a full Internet
+   standard and CMOT is a draft standard.  See also the Host and Gateway
+   Requirements RFCs for more specific information on the applicability
+   of this standard.
+
+   Please refer to the latest edition of the "IAB Official Protocol
+   Standards" RFC for current information on the state and status of
+   standard Internet protocols.
+
+   Distribution of this memo is unlimited.
+
+2.  Introduction
+
+   This memo describes the common structures and identification scheme
+   for the definition of management information used in managing
+   TCP/IP-based internets.  Included are descriptions of an object
+   information model for network management along with a set of generic
+   types used to describe management information.  Formal descriptions
+   of the structure are given using Abstract Syntax Notation One (ASN.1)
+   [1].
+
+   This memo is largely concerned with organizational concerns and
+   administrative policy:  it neither specifies the objects which are
+   managed, nor the protocols used to manage those objects.  These
+   concerns are addressed by two companion memos:  one describing the
+   Management Information Base (MIB) [2], and the other describing the
+   Simple Network Management Protocol (SNMP) [3].
+
+   This memo is based in part on the work of the Internet Engineering
+
+
+
+Rose & McCloghrie                                               [Page 2]
+
+RFC 1155                          SMI                           May 1990
+
+
+   Task Force, particularly the working note titled "Structure and
+   Identification of Management Information for the Internet" [4].  This
+   memo uses a skeletal structure derived from that note, but differs in
+   one very significant way:  that note focuses entirely on the use of
+   OSI-style network management.  As such, it is not suitable for use
+   with SNMP.
+
+   This memo attempts to achieve two goals:  simplicity and
+   extensibility.  Both are motivated by a common concern:  although the
+   management of TCP/IP-based internets has been a topic of study for
+   some time, the authors do not feel that the depth and breadth of such
+   understanding is complete.  More bluntly, we feel that previous
+   experiences, while giving the community insight, are hardly
+   conclusive.  By fostering a simple SMI, the minimal number of
+   constraints are imposed on future potential approaches; further, by
+   fostering an extensible SMI, the maximal number of potential
+   approaches are available for experimentation.
+
+   It is believed that this memo and its two companions comply with the
+   guidelines set forth in RFC 1052, "IAB Recommendations for the
+   Development of Internet Network Management Standards" [5] and RFC
+   1109, "Report of the Second Ad Hoc Network Management Review Group"
+   [6].  In particular, we feel that this memo, along with the memo
+   describing the management information base, provide a solid basis for
+   network management of the Internet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose & McCloghrie                                               [Page 3]
+
+RFC 1155                          SMI                           May 1990
+
+
+3.  Structure and Identification of Management Information
+
+   Managed objects are accessed via a virtual information store, termed
+   the Management Information Base or MIB.  Objects in the MIB are
+   defined using Abstract Syntax Notation One (ASN.1) [1].
+
+   Each type of object (termed an object type) has a name, a syntax, and
+   an encoding.  The name is represented uniquely as an OBJECT
+   IDENTIFIER.  An OBJECT IDENTIFIER is an administratively assigned
+   name.  The administrative policies used for assigning names are
+   discussed later in this memo.
+
+   The syntax for an object type defines the abstract data structure
+   corresponding to that object type.  For example, the structure of a
+   given object type might be an INTEGER or OCTET STRING.  Although in
+   general, we should permit any ASN.1 construct to be available for use
+   in defining the syntax of an object type, this memo purposely
+   restricts the ASN.1 constructs which may be used.  These restrictions
+   are made solely for the sake of simplicity.
+
+   The encoding of an object type is simply how instances of that object
+   type are represented using the object's type syntax.  Implicitly tied
+   to the notion of an object's syntax and encoding is how the object is
+   represented when being transmitted on the network.  This memo
+   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 for
+   network management or the network management protocol.  As mentioned
+   earlier, these tasks are left to companion memos.  This memo attempts
+   to minimize the restrictions placed upon its companions so as to
+   maximize generality.  However, in some cases, restrictions have been
+   made (e.g., the syntax which may be used when defining object types
+   in the MIB) in order to encourage a particular style of management.
+   Future editions of this memo may remove these restrictions.
+
+3.1.  Names
+
+   Names are used to identify managed objects.  This memo specifies
+   names which are hierarchical in nature.  The OBJECT IDENTIFIER
+   concept is used to model this notion.  An OBJECT IDENTIFIER can be
+   used for purposes other than naming managed object types; for
+   example, each international standard has an OBJECT IDENTIFIER
+   assigned to it for the purposes of identification.  In short, OBJECT
+   IDENTIFIERs are a means for identifying some object, regardless of
+   the semantics associated with the object (e.g., a network object, a
+   standards document, etc.)
+
+   An OBJECT IDENTIFIER is a sequence of integers which traverse a
+
+
+
+Rose & McCloghrie                                               [Page 4]
+
+RFC 1155                          SMI                           May 1990
+
+
+   global tree.  The tree consists of a root connected to a number of
+   labeled nodes via edges.  Each node may, in turn, have children of
+   its own which are labeled.  In this case, we may term the node a
+   subtree.  This process may continue to an arbitrary level of depth.
+   Central to the notion of the OBJECT IDENTIFIER is the understanding
+   that administrative control of the meanings assigned to the nodes may
+   be delegated as one traverses the tree.  A label is a pairing of a
+   brief textual description and an integer.
+
+   The root node itself is unlabeled, but has at least three children
+   directly under it:  one node is administered by the International
+   Organization for Standardization, with label iso(1); another is
+   administrated by the International Telegraph and Telephone
+   Consultative Committee, with label ccitt(0); and the third is jointly
+   administered by the ISO and the CCITT, joint-iso-ccitt(2).
+
+   Under the iso(1) node, the ISO has designated one subtree for use by
+   other (inter)national organizations, org(3).  Of the children nodes
+   present, two have been assigned to the U.S. National Institutes of
+   Standards and Technology.  One of these subtrees has been transferred
+   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 its
+   subtree of OBJECT IDENTIFIERs.  This memo assumes that DoD will
+   allocate a node to the Internet community, to be administered by the
+   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 the
+   prefix:
+
+      1.3.6.1.
+
+   This memo, as a standard approved by the IAB, now specifies the
+   policy under which this subtree of OBJECT IDENTIFIERs is
+   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.  Directory
+
+   The directory(1) subtree is reserved for use with a future memo that
+   discusses how the OSI Directory may be used in the Internet.
+
+
+
+
+Rose & McCloghrie                                               [Page 5]
+
+RFC 1155                          SMI                           May 1990
+
+
+3.1.2.  Mgmt
+
+   The mgmt(2) subtree is used to identify objects which are defined in
+   IAB-approved documents.  Administration of the mgmt(2) subtree is
+   delegated by the IAB to the Internet Assigned Numbers Authority for
+   the Internet.  As RFCs which define new versions of the Internet-
+   standard Management Information Base are approved, they are assigned
+   an OBJECT IDENTIFIER by the Internet Assigned Numbers Authority for
+   identifying the objects defined by that memo.
+
+   For example, the RFC which defines the initial Internet standard MIB
+   would be assigned management document number 1.  This RFC would use
+   the OBJECT IDENTIFIER
+
+      { mgmt 1 }
+
+   or
+
+      1.3.6.1.2.1
+
+   in defining the Internet-standard MIB.
+
+   The generation of new versions of the Internet-standard MIB is a
+   rigorous process.  Section 5 of this memo describes the rules used
+   when a new version is defined.
+
+3.1.3.  Experimental
+
+   The experimental(3) subtree is used to identify objects used in
+   Internet experiments.  Administration of the experimental(3) subtree
+   is delegated by the IAB to the Internet Assigned Numbers Authority of
+   the Internet.
+
+   For example, an experimenter might received number 17, and would have
+   available the OBJECT IDENTIFIER
+
+      { experimental 17 }
+
+   or
+
+      1.3.6.1.3.17
+
+   for use.
+
+   As a part of the assignment process, the Internet Assigned Numbers
+   Authority may make requirements as to how that subtree is used.
+
+
+
+
+
+Rose & McCloghrie                                               [Page 6]
+
+RFC 1155                          SMI                           May 1990
+
+
+3.1.4.  Private
+
+   The private(4) subtree is used to identify objects defined
+   unilaterally.  Administration of the private(4) subtree is delegated
+   by the IAB to the Internet Assigned Numbers Authority for the
+   Internet.  Initially, this subtree has at least one child:
+
+      enterprises   OBJECT IDENTIFIER ::= { private 1 }
+
+   The enterprises(1) subtree is used, among other things, to permit
+   parties providing networking subsystems to register models of their
+   products.
+
+   Upon receiving a subtree, the enterprise may, for example, define new
+   MIB objects in this subtree.  In addition, it is strongly recommended
+   that the enterprise will also register its networking subsystems
+   under this subtree, in order to provide an unambiguous identification
+   mechanism for use in management protocols.  For example, if the
+   "Flintstones, Inc."  enterprise produced networking subsystems, then
+   they could request a node under the enterprises subtree from the
+   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 "Fred
+   Router" under the name of:
+
+      1.3.6.1.4.1.42.1.1
+
+3.2.  Syntax
+
+   Syntax is used to define the structure corresponding to object types.
+   ASN.1 constructs are used to define this structure, although the full
+   generality of ASN.1 is not permitted.
+
+   The ASN.1 type ObjectSyntax defines the different syntaxes which may
+   be used in defining an object type.
+
+3.2.1.  Primitive Types
+
+   Only the ASN.1 primitive types INTEGER, OCTET STRING, OBJECT
+   IDENTIFIER, and NULL are permitted.  These are sometimes referred to
+   as non-aggregate types.
+
+3.2.1.1.  Guidelines for Enumerated INTEGERs
+
+   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 of
+
+
+
+Rose & McCloghrie                                               [Page 7]
+
+RFC 1155                          SMI                           May 1990
+
+
+   enumerations.  Use of this value is prohibited.
+
+3.2.2.  Constructor Types
+
+   The ASN.1 constructor type SEQUENCE is permitted, providing that it
+   is used to generate either lists or tables.
+
+   For lists, the syntax takes the form:
+
+      SEQUENCE { <type1>, ..., <typeN> }
+
+   where each <type> resolves to one of the ASN.1 primitive types listed
+   above.  Further, these ASN.1 types are always present (the DEFAULT
+   and OPTIONAL clauses do not appear in the SEQUENCE definition).
+
+   For tables, the syntax takes the form:
+
+      SEQUENCE OF <entry>
+
+   where <entry> resolves to a list constructor.
+
+   Lists and tables are sometimes referred to as aggregate types.
+
+3.2.3.  Defined Types
+
+   In addition, new application-wide types may be defined, so long as
+   they resolve into an IMPLICITly defined ASN.1 primitive type, list,
+   table, or some other application-wide type.  Initially, few
+   application-wide types are defined.  Future memos will no doubt
+   define others once a consensus is reached.
+
+3.2.3.1.  NetworkAddress
+
+   This CHOICE represents an address from one of possibly several
+   protocol families.  Currently, only one protocol family, the Internet
+   family, is present in this CHOICE.
+
+3.2.3.2.  IpAddress
+
+   This application-wide type represents a 32-bit internet address.  It
+   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.  Counter
+
+   This application-wide type represents a non-negative integer which
+
+
+
+Rose & McCloghrie                                               [Page 8]
+
+RFC 1155                          SMI                           May 1990
+
+
+   monotonically increases until it reaches a maximum value, when it
+   wraps around and starts increasing again from zero.  This memo
+   specifies a maximum value of 2^32-1 (4294967295 decimal) for
+   counters.
+
+3.2.3.4.  Gauge
+
+   This application-wide type represents a non-negative integer, which
+   may increase or decrease, but which latches at a maximum value.  This
+   memo specifies a maximum value of 2^32-1 (4294967295 decimal) for
+   gauges.
+
+3.2.3.5.  TimeTicks
+
+   This application-wide type represents a non-negative integer which
+   counts the time in hundredths of a second since some epoch.  When
+   object types are defined in the MIB which use this ASN.1 type, the
+   description of the object type identifies the reference epoch.
+
+3.2.3.6.  Opaque
+
+   This application-wide type supports the capability to pass arbitrary
+   ASN.1 syntax.  A value is encoded using the ASN.1 basic rules into a
+   string of octets.  This, in turn, is encoded as an OCTET STRING, in
+   effect "double-wrapping" the original ASN.1 value.
+
+   Note that a conforming implementation need only be able to accept and
+   recognize opaquely-encoded data.  It need not be able to unwrap the
+   data and then interpret its contents.
+
+   Further note that by use of the ASN.1 EXTERNAL type, encodings other
+   than ASN.1 may be used in opaquely-encoded data.
+
+3.3.  Encodings
+
+   Once an instance of an object type has been identified, its value may
+   be transmitted by applying the basic encoding rules of ASN.1 to the
+   syntax for the object type.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose & McCloghrie                                               [Page 9]
+
+RFC 1155                          SMI                           May 1990
+
+
+4.  Managed Objects
+
+   Although it is not the purpose of this memo to define objects in the
+   MIB, this memo specifies a format to be used by other memos which
+   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 an
+      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 object
+      fulfills this definition since this MIB is intended for use in
+      multi-vendor environments.  As such it is vital that objects have
+      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 they
+   define.
+
+4.1.  Guidelines for Object Names
+
+   No object type in the Internet-Standard MIB shall use a sub-
+   identifier of 0 in its name.  This value is reserved for use with
+   future extensions.
+
+   Each OBJECT DESCRIPTOR corresponding to an object type in the
+   internet-standard MIB shall be a unique, but mnemonic, printable
+   string.  This promotes a common language for humans to use when
+   discussing the MIB and also facilitates simple table mappings for
+   user interfaces.
+
+4.2.  Object Types and Instances
+
+   An object type is a definition of a kind of managed object; it is
+
+
+
+Rose & McCloghrie                                              [Page 10]
+
+RFC 1155                          SMI                           May 1990
+
+
+   declarative in nature.  In contrast, an object instance is an
+   instantiation of an object type which has been bound to a value.  For
+   example, the notion of an entry in a routing table might be defined
+   in the MIB.  Such a notion corresponds to an object type; individual
+   entries in a particular routing table which exist at some time are
+   object instances of that object type.
+
+   A collection of object types is defined in the MIB.  Each such
+   subject type is uniquely named by its OBJECT IDENTIFIER and also has
+   a textual name, which is its OBJECT DESCRIPTOR.  The means whereby
+   object instances are referenced is not defined in the MIB.  Reference
+   to object instances is achieved by a protocol-specific mechanism:  it
+   is the responsibility of each management protocol adhering to the SMI
+   to define this mechanism.
+
+   An object type may be defined in the MIB such that an instance of
+   that object type represents an aggregation of information also
+   represented by instances of some number of "subordinate" object
+   types.  For example, suppose the following object types are defined
+   in the MIB:
+
+
+   OBJECT:
+   -------
+      atIndex { atEntry 1 }
+
+   Syntax:
+      INTEGER
+
+   Definition:
+      The interface number for the physical address.
+
+   Access:
+      read-write.
+
+   Status:
+      mandatory.
+
+
+   OBJECT:
+   -------
+      atPhysAddress { atEntry 2 }
+
+   Syntax:
+      OCTET STRING
+
+   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:
+      NetworkAddress
+
+   Definition:
+      The network address corresponding to the media-dependent physical
+      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 {
+            atIndex
+            INTEGER,
+            atPhysAddress
+            OCTET STRING,
+            atNetAddress
+            NetworkAddress
+            }
+
+   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 represented
+   by instances of the former three object types.  An object type
+   defined in this way is called a list.
+
+   Similarly, tables can be formed by aggregations of a list type.  For
+   example, a fifth object type might also be defined in the MIB:
+
+
+   OBJECT:
+   ------
+      atTable { at 1 }
+
+   Syntax:
+      SEQUENCE OF AtEntry
+
+   Definition:
+      The address translation table.
+
+   Access:
+      read-write.
+
+   Status:
+      mandatory.
+
+   such that each instance of the atTable object comprises information
+   represented by the set of atEntry object types that collectively
+   constitute a given atTable object instance, that is, a given address
+   translation table.
+
+   Consider how one might refer to a simple object within a table.
+   Continuing with the previous example, one might name the object type
+
+      { atPhysAddress }
+
+   and specify, using a protocol-specific mechanism, the object instance
+
+      { atNetAddress } = { internet "10.0.0.52" }
+
+   This pairing of object type and object instance would refer to all
+   instances of atPhysAddress which are part of any entry in some
+   address translation table for which the associated atNetAddress value
+   is { internet "10.0.0.52" }.
+
+   To continue with this example, consider how one might refer to an
+   aggregate object (list) within a table.  Naming the object type
+
+
+
+Rose & McCloghrie                                              [Page 13]
+
+RFC 1155                          SMI                           May 1990
+
+
+      { atEntry }
+
+   and specifying, using a protocol-specific mechanism, the object
+   instance
+
+      { atNetAddress } = { internet "10.0.0.52" }
+
+   refers to all instances of entries in the table for which the
+   associated atNetAddress value is { internet "10.0.0.52" }.
+
+   Each management protocol must provide a mechanism for accessing
+   simple (non-aggregate) object types.  Each management protocol
+   specifies whether or not it supports access to aggregate object
+   types.  Further, the protocol must specify which instances are
+   "returned" when an object type/instance pairing refers to more than
+   one instance of a type.
+
+   To afford support for a variety of management protocols, all
+   information by which instances of a given object type may be usefully
+   distinguished, one from another, is represented by instances of
+   object types defined in the MIB.
+
+4.3.  Macros for Managed Objects
+
+   In order to facilitate the use of tools for processing the definition
+   of the MIB, the OBJECT-TYPE macro may be used.  This macro permits
+   the key aspects of an object type to be represented in a formal way.
+
+      OBJECT-TYPE MACRO ::=
+      BEGIN
+          TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax)
+                            "ACCESS" Access
+                            "STATUS" Status
+          VALUE NOTATION ::= value (VALUE ObjectName)
+
+          Access ::= "read-only"
+                          | "read-write"
+                          | "write-only"
+                          | "not-accessible"
+          Status ::= "mandatory"
+                          | "optional"
+                          | "obsolete"
+          END
+
+   Given the object types defined earlier, we might imagine the
+   following definitions being present in the MIB:
+
+                  atIndex OBJECT-TYPE
+
+
+
+Rose & McCloghrie                                              [Page 14]
+
+RFC 1155                          SMI                           May 1990
+
+
+                          SYNTAX  INTEGER
+                          ACCESS  read-write
+                          STATUS  mandatory
+                          ::= { atEntry 1 }
+
+                  atPhysAddress OBJECT-TYPE
+                          SYNTAX  OCTET STRING
+                          ACCESS  read-write
+                          STATUS  mandatory
+                          ::= { atEntry 2 }
+
+                  atNetAddress OBJECT-TYPE
+                          SYNTAX  NetworkAddress
+                          ACCESS  read-write
+                          STATUS  mandatory
+                          ::= { atEntry 3 }
+
+                  atEntry OBJECT-TYPE
+                          SYNTAX  AtEntry
+                          ACCESS  read-write
+                          STATUS  mandatory
+                          ::= { atTable 1 }
+
+                  atTable OBJECT-TYPE
+                          SYNTAX  SEQUENCE OF AtEntry
+                          ACCESS  read-write
+                          STATUS  mandatory
+                          ::= { at 1 }
+
+                  AtEntry ::= SEQUENCE {
+                      atIndex
+                          INTEGER,
+                      atPhysAddress
+                          OCTET STRING,
+                      atNetAddress
+                          NetworkAddress
+                  }
+
+   The first five definitions describe object types, relating, for
+   example, the OBJECT DESCRIPTOR atIndex to the OBJECT IDENTIFIER {
+   atEntry 1 }.  In addition, the syntax of this object is defined
+   (INTEGER) along with the access permitted (read-write) and status
+   (mandatory).  The sixth definition describes an ASN.1 type called
+   AtEntry.
+
+
+
+
+
+
+
+Rose & McCloghrie                                              [Page 15]
+
+RFC 1155                          SMI                           May 1990
+
+
+5.  Extensions to the MIB
+
+   Every Internet-standard MIB document obsoletes all previous such
+   documents.  The portion of a name, termed the tail, following the
+   OBJECT IDENTIFIER
+
+      { mgmt version-number }
+
+   used to name objects shall remain unchanged between versions.  New
+   versions may:
+
+      (1) declare old object types obsolete (if necessary), but not
+      delete their names;
+
+      (2) augment the definition of an object type corresponding to a
+      list by appending non-aggregate object types to the object types
+      in the list; or,
+
+      (3) define entirely new object types.
+
+   New versions may not:
+
+      (1) change the semantics of any previously defined object without
+      changing the name of that object.
+
+   These rules are important because they admit easier support for
+   multiple versions of the Internet-standard MIB.  In particular, the
+   semantics associated with the tail of a name remain constant
+   throughout different versions of the MIB.  Because multiple versions
+   of the MIB may thus coincide in "tail-space," implementations
+   supporting multiple versions of the MIB can be vastly simplified.
+
+   However, as a consequence, a management agent might return an
+   instance corresponding to a superset of the expected object type.
+   Following the principle of robustness, in this exceptional case, a
+   manager should ignore any additional information beyond the
+   definition of the expected object type.  However, the robustness
+   principle requires that one exercise care with respect to control
+   actions:  if an instance does not have the same syntax as its
+   expected object type, then those control actions must fail.  In both
+   the monitoring and control cases, the name of an object returned by
+   an operation must be identical to the name requested by an operation.
+
+
+
+
+
+
+
+
+
+Rose & McCloghrie                                              [Page 16]
+
+RFC 1155                          SMI                           May 1990
+
+
+6.  Definitions
+
+           RFC1155-SMI DEFINITIONS ::= BEGIN
+
+           EXPORTS -- EVERYTHING
+                   internet, directory, mgmt,
+                   experimental, private, enterprises,
+                   OBJECT-TYPE, ObjectName, ObjectSyntax, SimpleSyntax,
+                   ApplicationSyntax, NetworkAddress, IpAddress,
+                   Counter, Gauge, TimeTicks, Opaque;
+
+            -- the path to the root
+
+            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 types
+
+            OBJECT-TYPE MACRO ::=
+            BEGIN
+                TYPE NOTATION ::= "SYNTAX" type (TYPE ObjectSyntax)
+                                  "ACCESS" Access
+                                  "STATUS" Status
+                VALUE NOTATION ::= value (VALUE ObjectName)
+
+                Access ::= "read-only"
+                                | "read-write"
+                                | "write-only"
+                                | "not-accessible"
+                Status ::= "mandatory"
+                                | "optional"
+                                | "obsolete"
+            END
+
+               -- names of objects in the MIB
+
+               ObjectName ::=
+                   OBJECT IDENTIFIER
+
+
+
+
+Rose & McCloghrie                                              [Page 17]
+
+RFC 1155                          SMI                           May 1990
+
+
+               -- syntax of objects in the MIB
+
+               ObjectSyntax ::=
+                   CHOICE {
+                       simple
+                           SimpleSyntax,
+
+               -- note that simple SEQUENCEs are not directly
+               -- mentioned here to keep things simple (i.e.,
+               -- prevent mis-use).  However, application-wide
+               -- types which are IMPLICITly encoded simple
+               -- SEQUENCEs may appear in the following CHOICE
+
+                       application-wide
+                           ApplicationSyntax
+                   }
+
+                  SimpleSyntax ::=
+                      CHOICE {
+                          number
+                              INTEGER,
+
+                          string
+                              OCTET STRING,
+
+                          object
+                              OBJECT IDENTIFIER,
+
+                          empty
+                              NULL
+                      }
+
+                  ApplicationSyntax ::=
+                      CHOICE {
+                          address
+                              NetworkAddress,
+
+                          counter
+                              Counter,
+
+                          gauge
+                              Gauge,
+
+                          ticks
+                              TimeTicks,
+
+                          arbitrary
+                              Opaque
+
+
+
+Rose & McCloghrie                                              [Page 18]
+
+RFC 1155                          SMI                           May 1990
+
+
+                  -- other application-wide types, as they are
+                  -- defined, will be added here
+                      }
+
+
+                  -- application-wide types
+
+                  NetworkAddress ::=
+                      CHOICE {
+                          internet
+                              IpAddress
+                      }
+
+                  IpAddress ::=
+                      [APPLICATION 0]          -- in network-byte order
+                          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"
+
+                  END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose & McCloghrie                                              [Page 19]
+
+RFC 1155                          SMI                           May 1990
+
+
+7.  Acknowledgements
+
+   This memo was influenced by three sets of contributors to earlier
+   drafts:
+
+   First, Lee Labarre of the MITRE Corporation, who as author of the
+   NETMAN SMI [4], presented the basic roadmap for the SMI.
+
+   Second, several individuals who provided valuable comments on this
+   memo prior to its initial distribution:
+
+         James R. Davin, Proteon
+         Mark S. Fedor, NYSERNet
+         Craig Partridge, BBN Laboratories
+         Martin Lee Schoffstall, Rensselaer Polytechnic Institute
+         Wengyik Yeong, NYSERNet
+
+
+   Third, the IETF MIB working group:
+
+         Karl Auerbach, Epilogue Technology
+         K. Ramesh Babu, Excelan
+         Lawrence Besaw, Hewlett-Packard
+         Jeffrey D. Case, University of Tennessee at Knoxville
+         James R. Davin, Proteon
+         Mark S. Fedor, NYSERNet
+         Robb Foster, BBN
+         Phill Gross, The MITRE Corporation
+         Bent Torp Jensen, Convergent Technology
+         Lee Labarre, The MITRE Corporation
+         Dan Lynch, Advanced Computing Environments
+         Keith McCloghrie, The Wollongong Group
+         Dave Mackie, 3Com/Bridge
+         Craig Partridge, BBN (chair)
+         Jim Robertson, 3Com/Bridge
+         Marshall T. Rose, The Wollongong Group
+         Greg Satz, cisco
+         Martin Lee Schoffstall, Rensselaer Polytechnic Institute
+         Lou Steinberg, IBM
+         Dean Throop, Data General
+         Unni Warrier, Unisys
+
+
+
+
+
+
+
+
+
+
+Rose & McCloghrie                                              [Page 20]
+
+RFC 1155                          SMI                           May 1990
+
+
+8.  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] McCloghrie K., and M. Rose, "Management Information Base for
+       Network Management of TCP/IP-based Internets", RFC 1156,
+       Performance Systems International and Hughes LAN Systems, May
+       1990.
+
+   [3] Case, J., M. Fedor, M. Schoffstall, and J. Davin, The Simple
+       Network Management Protocol", RFC 1157, University of Tennessee
+       at Knoxville, Performance Systems International, Performance
+       Systems International, and the MIT Laboratory for Computer
+       Science, May 1990.
+
+   [4] LaBarre, L., "Structure and Identification of Management
+       Information for the Internet", Internet Engineering Task Force
+       working note, Network Information Center, SRI International,
+       Menlo Park, California, April 1988.
+
+   [5] Cerf, V., "IAB Recommendations for the Development of Internet
+       Network Management Standards", RFC 1052, IAB, April 1988.
+
+   [6] Cerf, V., "Report of the Second Ad Hoc Network Management Review
+       Group", RFC 1109, IAB, August 1989.
+
+   [7] Information processing systems - Open Systems Interconnection,
+       "Specification of Basic Encoding Rules for Abstract Notation One
+       (ASN.1)", International Organization for Standardization,
+       International Standard 8825, December 1987.
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose & McCloghrie                                              [Page 21]
+
+RFC 1155                          SMI                           May 1990
+
+
+Authors' Addresses
+
+   Marshall T. Rose
+   PSI, Inc.
+   PSI California Office
+   P.O. Box 391776
+   Mountain View, CA 94039
+
+   Phone: (415) 961-3380
+
+   EMail: mrose@PSI.COM
+
+
+   Keith McCloghrie
+   The Wollongong Group
+   1129 San Antonio Road
+   Palo Alto, CA 04303
+
+   Phone: (415) 962-7160
+
+   EMail: sytek!kzm@HPLABS.HP.COM
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rose & McCloghrie                                              [Page 22]
+
\ No newline at end of file
diff --git a/standards/rfc1157.txt b/standards/rfc1157.txt
new file mode 100644
index 000000000..262e7eb5b
--- /dev/null
+++ b/standards/rfc1157.txt
@@ -0,0 +1,2019 @@
+
+
+
+
+
+
+Network Working Group                                            J. Case
+Request for Comments:  1157                                SNMP Research
+Obsoletes:  RFC 1098                                            M. Fedor
+                                       Performance Systems International
+                                                          M. Schoffstall
+                                       Performance Systems International
+                                                                J. Davin
+                                     MIT Laboratory for Computer Science
+                                                                May 1990
+
+
+              A Simple Network Management Protocol (SNMP)
+
+                           Table of Contents
+
+   1. Status of this Memo ...................................    2
+   2. Introduction ..........................................    2
+   3. The SNMP Architecture .................................    5
+   3.1 Goals of the Architecture ............................    5
+   3.2 Elements of the Architecture .........................    5
+   3.2.1 Scope of Management Information ....................    6
+   3.2.2 Representation of Management Information ...........    6
+   3.2.3 Operations Supported on Management Information .....    7
+   3.2.4 Form and Meaning of Protocol Exchanges .............    8
+   3.2.5 Definition of Administrative Relationships .........    8
+   3.2.6 Form and Meaning of References to Managed Objects ..   12
+   3.2.6.1 Resolution of Ambiguous MIB References ...........   12
+   3.2.6.2 Resolution of References across MIB Versions......   12
+   3.2.6.3 Identification of Object Instances ...............   12
+   3.2.6.3.1 ifTable Object Type Names ......................   13
+   3.2.6.3.2 atTable Object Type Names ......................   13
+   3.2.6.3.3 ipAddrTable Object Type Names ..................   14
+   3.2.6.3.4 ipRoutingTable Object Type Names ...............   14
+   3.2.6.3.5 tcpConnTable Object Type Names .................   14
+   3.2.6.3.6 egpNeighTable Object Type Names ................   15
+   4. Protocol Specification ................................   16
+   4.1 Elements of Procedure ................................   17
+   4.1.1 Common Constructs ..................................   19
+   4.1.2 The GetRequest-PDU .................................   20
+   4.1.3 The GetNextRequest-PDU .............................   21
+   4.1.3.1 Example of Table Traversal .......................   23
+   4.1.4 The GetResponse-PDU ................................   24
+   4.1.5 The SetRequest-PDU .................................   25
+   4.1.6 The Trap-PDU .......................................   27
+   4.1.6.1 The coldStart Trap ...............................   28
+   4.1.6.2 The warmStart Trap ...............................   28
+   4.1.6.3 The linkDown Trap ................................   28
+   4.1.6.4 The linkUp Trap ..................................   28
+
+
+
+Case, Fedor, Schoffstall, & Davin                               [Page 1]
+
+RFC 1157                          SNMP                          May 1990
+
+
+   4.1.6.5 The authenticationFailure Trap ...................   28
+   4.1.6.6 The egpNeighborLoss Trap .........................   28
+   4.1.6.7 The enterpriseSpecific Trap ......................   29
+   5. Definitions ...........................................   30
+   6. Acknowledgements ......................................   33
+   7. References ............................................   34
+   8. Security Considerations................................   35
+   9. Authors' Addresses.....................................   35
+
+1.  Status of this Memo
+
+   This RFC is a re-release of RFC 1098, with a changed "Status of this
+   Memo" section plus a few minor typographical corrections.  This memo
+   defines a simple protocol by which management information for a
+   network element may be inspected or altered by logically remote
+   users.  In particular, together with its companion memos which
+   describe the structure of management information along with the
+   management information base, these documents provide a simple,
+   workable architecture and system for managing TCP/IP-based internets
+   and in particular the Internet.
+
+   The Internet Activities Board recommends that all IP and TCP
+   implementations be network manageable.  This implies implementation
+   of the Internet MIB (RFC-1156) and at least one of the two
+   recommended management protocols SNMP (RFC-1157) or CMOT (RFC-1095).
+   It should be noted that, at this time, SNMP is a full Internet
+   standard and CMOT is a draft standard.  See also the Host and Gateway
+   Requirements RFCs for more specific information on the applicability
+   of this standard.
+
+   Please refer to the latest edition of the "IAB Official Protocol
+   Standards" RFC for current information on the state and status of
+   standard Internet protocols.
+
+   Distribution of this memo is unlimited.
+
+2.  Introduction
+
+   As reported in RFC 1052, IAB Recommendations for the Development of
+   Internet Network Management Standards [1], a two-prong strategy for
+   network management of TCP/IP-based internets was undertaken.  In the
+   short-term, the Simple Network Management Protocol (SNMP) was to be
+   used to manage nodes in the Internet community.  In the long-term,
+   the use of the OSI network management framework was to be examined.
+   Two documents were produced to define the management information: RFC
+   1065, which defined the Structure of Management Information (SMI)
+   [2], and RFC 1066, which defined the Management Information Base
+   (MIB) [3].  Both of these documents were designed so as to be
+
+
+
+Case, Fedor, Schoffstall, & Davin                               [Page 2]
+
+RFC 1157                          SNMP                          May 1990
+
+
+   compatible with both the SNMP and the OSI network management
+   framework.
+
+   This strategy was quite successful in the short-term: Internet-based
+   network management technology was fielded, by both the research and
+   commercial communities, within a few months.  As a result of this,
+   portions of the Internet community became network manageable in a
+   timely fashion.
+
+   As reported in RFC 1109, Report of the Second Ad Hoc Network
+   Management Review Group [4], the requirements of the SNMP and the OSI
+   network management frameworks were more different than anticipated.
+   As such, the requirement for compatibility between the SMI/MIB and
+   both frameworks was suspended.  This action permitted the operational
+   network management framework, the SNMP, to respond to new operational
+   needs in the Internet community by producing documents defining new
+   MIB items.
+
+   The IAB has designated the SNMP, SMI, and the initial Internet MIB to
+   be full "Standard Protocols" with "Recommended" status.  By this
+   action, the IAB recommends that all IP and TCP implementations be
+   network manageable and that the implementations that are network
+   manageable are expected to adopt and implement the SMI, MIB, and
+   SNMP.
+
+   As such, the current network management framework for TCP/IP- based
+   internets consists of:  Structure and Identification of Management
+   Information for TCP/IP-based Internets, which describes how managed
+   objects contained in the MIB are defined as set forth in RFC 1155
+   [5]; Management Information Base for Network Management of TCP/IP-
+   based Internets, which describes the managed objects contained in the
+   MIB as set forth in RFC 1156 [6]; and, the Simple Network Management
+   Protocol, which defines the protocol used to manage these objects, as
+   set forth in this memo.
+
+   As reported in RFC 1052, IAB Recommendations for the Development of
+   Internet Network Management Standards [1], the Internet Activities
+   Board has directed the Internet Engineering Task Force (IETF) to
+   create two new working groups in the area of network management.  One
+   group was charged with the further specification and definition of
+   elements to be included in the Management Information Base (MIB).
+   The other was charged with defining the modifications to the Simple
+   Network Management Protocol (SNMP) to accommodate the short-term
+   needs of the network vendor and operations communities, and to align
+   with the output of the MIB working group.
+
+   The MIB working group produced two memos, one which defines a
+   Structure for Management Information (SMI) [2] for use by the managed
+
+
+
+Case, Fedor, Schoffstall, & Davin                               [Page 3]
+
+RFC 1157                          SNMP                          May 1990
+
+
+   objects contained in the MIB.  A second memo [3] defines the list of
+   managed objects.
+
+   The output of the SNMP Extensions working group is this memo, which
+   incorporates changes to the initial SNMP definition [7] required to
+   attain alignment with the output of the MIB working group.  The
+   changes should be minimal in order to be consistent with the IAB's
+   directive that the working groups be "extremely sensitive to the need
+   to keep the SNMP simple."  Although considerable care and debate has
+   gone into the changes to the SNMP which are reflected in this memo,
+   the resulting protocol is not backwardly-compatible with its
+   predecessor, the Simple Gateway Monitoring Protocol (SGMP) [8].
+   Although the syntax of the protocol has been altered, the original
+   philosophy, design decisions, and architecture remain intact.  In
+   order to avoid confusion, new UDP ports have been allocated for use
+   by the protocol described in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                               [Page 4]
+
+RFC 1157                          SNMP                          May 1990
+
+
+3.  The SNMP Architecture
+
+   Implicit in the SNMP architectural model is a collection of network
+   management stations and network elements.  Network management
+   stations execute management applications which monitor and control
+   network elements.  Network elements are devices such as hosts,
+   gateways, terminal servers, and the like, which have management
+   agents responsible for performing the network management functions
+   requested by the network management stations.  The Simple Network
+   Management Protocol (SNMP) is used to communicate management
+   information between the network management stations and the agents in
+   the network elements.
+
+3.1.  Goals of the Architecture
+
+   The SNMP explicitly minimizes the number and complexity of management
+   functions realized by the management agent itself.  This goal is
+   attractive in at least four respects:
+
+      (1)  The development cost for management agent software
+           necessary to support the protocol is accordingly reduced.
+
+      (2)  The degree of management function that is remotely
+           supported is accordingly increased, thereby admitting
+           fullest use of internet resources in the management task.
+
+      (3)  The degree of management function that is remotely
+           supported is accordingly increased, thereby imposing the
+           fewest possible restrictions on the form and
+           sophistication of management tools.
+
+      (4)  Simplified sets of management functions are easily
+           understood and used by developers of network management
+           tools.
+
+   A second goal of the protocol is that the functional paradigm for
+   monitoring and control be sufficiently extensible to accommodate
+   additional, possibly unanticipated aspects of network operation and
+   management.
+
+   A third goal is that the architecture be, as much as possible,
+   independent of the architecture and mechanisms of particular hosts or
+   particular gateways.
+
+3.2.  Elements of the Architecture
+
+   The SNMP architecture articulates a solution to the network
+   management problem in terms of:
+
+
+
+Case, Fedor, Schoffstall, & Davin                               [Page 5]
+
+RFC 1157                          SNMP                          May 1990
+
+
+      (1)  the scope of the management information communicated by
+           the protocol,
+
+      (2)  the representation of the management information
+           communicated by the protocol,
+
+      (3)  operations on management information supported by the
+           protocol,
+
+      (4)  the form and meaning of exchanges among management
+           entities,
+
+      (5)  the definition of administrative relationships among
+           management entities, and
+
+      (6)  the form and meaning of references to management
+           information.
+
+3.2.1.  Scope of Management Information
+
+   The scope of the management information communicated by operation of
+   the SNMP is exactly that represented by instances of all non-
+   aggregate object types either defined in Internet-standard MIB or
+   defined elsewhere according to the conventions set forth in
+   Internet-standard SMI [5].
+
+   Support for aggregate object types in the MIB is neither required for
+   conformance with the SMI nor realized by the SNMP.
+
+3.2.2.  Representation of Management Information
+
+   Management information communicated by operation of the SNMP is
+   represented according to the subset of the ASN.1 language [9] that is
+   specified for the definition of non-aggregate types in the SMI.
+
+   The SGMP adopted the convention of using a well-defined subset of the
+   ASN.1 language [9].  The SNMP continues and extends this tradition by
+   utilizing a moderately more complex subset of ASN.1 for describing
+   managed objects and for describing the protocol data units used for
+   managing those objects.  In addition, the desire to ease eventual
+   transition to OSI-based network management protocols led to the
+   definition in the ASN.1 language of an Internet-standard Structure of
+   Management Information (SMI) [5] and Management Information Base
+   (MIB) [6].  The use of the ASN.1 language, was, in part, encouraged
+   by the successful use of ASN.1 in earlier efforts, in particular, the
+   SGMP.  The restrictions on the use of ASN.1 that are part of the SMI
+   contribute to the simplicity espoused and validated by experience
+   with the SGMP.
+
+
+
+Case, Fedor, Schoffstall, & Davin                               [Page 6]
+
+RFC 1157                          SNMP                          May 1990
+
+
+   Also for the sake of simplicity, the SNMP uses only a subset of the
+   basic encoding rules of ASN.1 [10].  Namely, all encodings use the
+   definite-length form.  Further, whenever permissible, non-constructor
+   encodings are used rather than constructor encodings.  This
+   restriction applies to all aspects of ASN.1 encoding, both for the
+   top-level protocol data units and the data objects they contain.
+
+3.2.3.  Operations Supported on Management Information
+
+   The SNMP models all management agent functions as alterations or
+   inspections of variables.  Thus, a protocol entity on a logically
+   remote host (possibly the network element itself) interacts with the
+   management agent resident on the network element in order to retrieve
+   (get) or alter (set) variables.  This strategy has at least two
+   positive consequences:
+
+      (1)  It has the effect of limiting the number of essential
+           management functions realized by the management agent to
+           two:  one operation to assign a value to a specified
+           configuration or other parameter and another to retrieve
+           such a value.
+
+      (2)  A second effect of this decision is to avoid introducing
+           into the protocol definition support for imperative
+           management commands:  the number of such commands is in
+           practice ever-increasing, and the semantics of such
+           commands are in general arbitrarily complex.
+
+   The strategy implicit in the SNMP is that the monitoring of network
+   state at any significant level of detail is accomplished primarily by
+   polling for appropriate information on the part of the monitoring
+   center(s).  A limited number of unsolicited messages (traps) guide
+   the timing and focus of the polling.  Limiting the number of
+   unsolicited messages is consistent with the goal of simplicity and
+   minimizing the amount of traffic generated by the network management
+   function.
+
+   The exclusion of imperative commands from the set of explicitly
+   supported management functions is unlikely to preclude any desirable
+   management agent operation.  Currently, most commands are requests
+   either to set the value of some parameter or to retrieve such a
+   value, and the function of the few imperative commands currently
+   supported is easily accommodated in an asynchronous mode by this
+   management model.  In this scheme, an imperative command might be
+   realized as the setting of a parameter value that subsequently
+   triggers the desired action.  For example, rather than implementing a
+   "reboot command," this action might be invoked by simply setting a
+   parameter indicating the number of seconds until system reboot.
+
+
+
+Case, Fedor, Schoffstall, & Davin                               [Page 7]
+
+RFC 1157                          SNMP                          May 1990
+
+
+3.2.4.  Form and Meaning of Protocol Exchanges
+
+   The communication of management information among management entities
+   is realized in the SNMP through the exchange of protocol messages.
+   The form and meaning of those messages is defined below in Section 4.
+
+   Consistent with the goal of minimizing complexity of the management
+   agent, the exchange of SNMP messages requires only an unreliable
+   datagram service, and every message is entirely and independently
+   represented by a single transport datagram.  While this document
+   specifies the exchange of messages via the UDP protocol [11], the
+   mechanisms of the SNMP are generally suitable for use with a wide
+   variety of transport services.
+
+3.2.5.  Definition of Administrative Relationships
+
+   The SNMP architecture admits a variety of administrative
+   relationships among entities that participate in the protocol.  The
+   entities residing at management stations and network elements which
+   communicate with one another using the SNMP are termed SNMP
+   application entities.  The peer processes which implement the SNMP,
+   and thus support the SNMP application entities, are termed protocol
+   entities.
+
+   A pairing of an SNMP agent with some arbitrary set of SNMP
+   application entities is called an SNMP community.  Each SNMP
+   community is named by a string of octets, that is called the
+   community name for said community.
+
+   An SNMP message originated by an SNMP application entity that in fact
+   belongs to the SNMP community named by the community component of
+   said message is called an authentic SNMP message.  The set of rules
+   by which an SNMP message is identified as an authentic SNMP message
+   for a particular SNMP community is called an authentication scheme.
+   An implementation of a function that identifies authentic SNMP
+   messages according to one or more authentication schemes is called an
+   authentication service.
+
+   Clearly, effective management of administrative relationships among
+   SNMP application entities requires authentication services that (by
+   the use of encryption or other techniques) are able to identify
+   authentic SNMP messages with a high degree of certainty.  Some SNMP
+   implementations may wish to support only a trivial authentication
+   service that identifies all SNMP messages as authentic SNMP messages.
+
+   For any network element, a subset of objects in the MIB that pertain
+   to that element is called a SNMP MIB view.  Note that the names of
+   the object types represented in a SNMP MIB view need not belong to a
+
+
+
+Case, Fedor, Schoffstall, & Davin                               [Page 8]
+
+RFC 1157                          SNMP                          May 1990
+
+
+   single sub-tree of the object type name space.
+
+   An element of the set { READ-ONLY, READ-WRITE } is called an SNMP
+   access mode.
+
+   A pairing of a SNMP access mode with a SNMP MIB view is called an
+   SNMP community profile.  A SNMP community profile represents
+   specified access privileges to variables in a specified MIB view. For
+   every variable in the MIB view in a given SNMP community profile,
+   access to that variable is represented by the profile according to
+   the following conventions:
+
+      (1)  if said variable is defined in the MIB with "Access:" of
+           "none," it is unavailable as an operand for any operator;
+
+      (2)  if said variable is defined in the MIB with "Access:" of
+           "read-write" or "write-only" and the access mode of the
+           given profile is READ-WRITE, that variable is available
+           as an operand for the get, set, and trap operations;
+
+      (3)  otherwise, the variable is available as an operand for
+           the get and trap operations.
+
+      (4)  In those cases where a "write-only" variable is an
+           operand used for the get or trap operations, the value
+           given for the variable is implementation-specific.
+
+   A pairing of a SNMP community with a SNMP community profile is called
+   a SNMP access policy. An access policy represents a specified
+   community profile afforded by the SNMP agent of a specified SNMP
+   community to other members of that community.  All administrative
+   relationships among SNMP application entities are architecturally
+   defined in terms of SNMP access policies.
+
+   For every SNMP access policy, if the network element on which the
+   SNMP agent for the specified SNMP community resides is not that to
+   which the MIB view for the specified profile pertains, then that
+   policy is called a SNMP proxy access policy. The SNMP agent
+   associated with a proxy access policy is called a SNMP proxy agent.
+   While careless definition of proxy access policies can result in
+   management loops, prudent definition of proxy policies is useful in
+   at least two ways:
+
+      (1)  It permits the monitoring and control of network elements
+           which are otherwise not addressable using the management
+           protocol and the transport protocol.  That is, a proxy
+           agent may provide a protocol conversion function allowing
+           a management station to apply a consistent management
+
+
+
+Case, Fedor, Schoffstall, & Davin                               [Page 9]
+
+RFC 1157                          SNMP                          May 1990
+
+
+           framework to all network elements, including devices such
+           as modems, multiplexors, and other devices which support
+           different management frameworks.
+
+      (2)  It potentially shields network elements from elaborate
+           access control policies.  For example, a proxy agent may
+           implement sophisticated access control whereby diverse
+           subsets of variables within the MIB are made accessible
+           to different management stations without increasing the
+           complexity of the network element.
+
+   By way of example, Figure 1 illustrates the relationship between
+   management stations, proxy agents, and management agents.  In this
+   example, the proxy agent is envisioned to be a normal Internet
+   Network Operations Center (INOC) of some administrative domain which
+   has a standard managerial relationship with a set of management
+   agents.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 10]
+
+RFC 1157                          SNMP                          May 1990
+
+
+   +------------------+       +----------------+      +----------------+
+   |  Region #1 INOC  |       |Region #2 INOC  |      |PC in Region #3 |
+   |                  |       |                |      |                |
+   |Domain=Region #1  |       |Domain=Region #2|      |Domain=Region #3|
+   |CPU=super-mini-1  |       |CPU=super-mini-1|      |CPU=Clone-1     |
+   |PCommunity=pub    |       |PCommunity=pub  |      |PCommunity=slate|
+   |                  |       |                |      |                |
+   +------------------+       +----------------+      +----------------+
+          /|\                      /|\                     /|\
+           |                        |                       |
+           |                        |                       |
+           |                       \|/                      |
+           |               +-----------------+              |
+           +-------------->| Region #3 INOC  |<-------------+
+                           |                 |
+                           |Domain=Region #3 |
+                           |CPU=super-mini-2 |
+                           |PCommunity=pub,  |
+                           |         slate   |
+                           |DCommunity=secret|
+           +-------------->|                 |<-------------+
+           |               +-----------------+              |
+           |                       /|\                      |
+           |                        |                       |
+           |                        |                       |
+          \|/                      \|/                     \|/
+   +-----------------+     +-----------------+       +-----------------+
+   |Domain=Region#3  |     |Domain=Region#3  |       |Domain=Region#3  |
+   |CPU=router-1     |     |CPU=mainframe-1  |       |CPU=modem-1      |
+   |DCommunity=secret|     |DCommunity=secret|       |DCommunity=secret|
+   +-----------------+     +-----------------+       +-----------------+
+
+
+   Domain:  the administrative domain of the element
+   PCommunity:  the name of a community utilizing a proxy agent
+   DCommunity:  the name of a direct community
+
+
+                                 Figure 1
+                 Example Network Management Configuration
+
+
+
+
+
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 11]
+
+RFC 1157                          SNMP                          May 1990
+
+
+3.2.6.  Form and Meaning of References to Managed Objects
+
+   The SMI requires that the definition of a conformant management
+   protocol address:
+
+      (1)  the resolution of ambiguous MIB references,
+
+      (2)  the resolution of MIB references in the presence multiple
+           MIB versions, and
+
+      (3)  the identification of particular instances of object
+           types defined in the MIB.
+
+3.2.6.1.  Resolution of Ambiguous MIB References
+
+   Because the scope of any SNMP operation is conceptually confined to
+   objects relevant to a single network element, and because all SNMP
+   references to MIB objects are (implicitly or explicitly) by unique
+   variable names, there is no possibility that any SNMP reference to
+   any object type defined in the MIB could resolve to multiple
+   instances of that type.
+
+3.2.6.2.  Resolution of References across MIB Versions
+
+   The object instance referred to by any SNMP operation is exactly that
+   specified as part of the operation request or (in the case of a get-
+   next operation) its immediate successor in the MIB as a whole.  In
+   particular, a reference to an object as part of some version of the
+   Internet-standard MIB does not resolve to any object that is not part
+   of said version of the Internet-standard MIB, except in the case that
+   the requested operation is get-next and the specified object name is
+   lexicographically last among the names of all objects presented as
+   part of said version of the Internet-Standard MIB.
+
+3.2.6.3.  Identification of Object Instances
+
+   The names for all object types in the MIB are defined explicitly
+   either in the Internet-standard MIB or in other documents which
+   conform to the naming conventions of the SMI.  The SMI requires that
+   conformant management protocols define mechanisms for identifying
+   individual instances of those object types for a particular network
+   element.
+
+   Each instance of any object type defined in the MIB is identified in
+   SNMP operations by a unique name called its "variable name." In
+   general, the name of an SNMP variable is an OBJECT IDENTIFIER of the
+   form x.y, where x is the name of a non-aggregate object type defined
+   in the MIB and y is an OBJECT IDENTIFIER fragment that, in a way
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 12]
+
+RFC 1157                          SNMP                          May 1990
+
+
+   specific to the named object type, identifies the desired instance.
+
+   This naming strategy admits the fullest exploitation of the semantics
+   of the GetNextRequest-PDU (see Section 4), because it assigns names
+   for related variables so as to be contiguous in the lexicographical
+   ordering of all variable names known in the MIB.
+
+   The type-specific naming of object instances is defined below for a
+   number of classes of object types.  Instances of an object type to
+   which none of the following naming conventions are applicable are
+   named by OBJECT IDENTIFIERs of the form x.0, where x is the name of
+   said object type in the MIB definition.
+
+   For example, suppose one wanted to identify an instance of the
+   variable sysDescr The object class for sysDescr is:
+
+             iso org dod internet mgmt mib system sysDescr
+              1   3   6     1      2    1    1       1
+
+   Hence, the object type, x, would be 1.3.6.1.2.1.1.1 to which is
+   appended an instance sub-identifier of 0.  That is, 1.3.6.1.2.1.1.1.0
+   identifies the one and only instance of sysDescr.
+
+3.2.6.3.1.  ifTable Object Type Names
+
+   The name of a subnet interface, s, is the OBJECT IDENTIFIER value of
+   the form i, where i has the value of that instance of the ifIndex
+   object type associated with s.
+
+   For each object type, t, for which the defined name, n, has a prefix
+   of ifEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of
+   the form n.s, where s is the name of the subnet interface about which
+   i represents information.
+
+   For example, suppose one wanted to identify the instance of the
+   variable ifType associated with interface 2.  Accordingly, ifType.2
+   would identify the desired instance.
+
+3.2.6.3.2.  atTable Object Type Names
+
+   The name of an AT-cached network address, x, is an OBJECT IDENTIFIER
+   of the form 1.a.b.c.d, where a.b.c.d is the value (in the familiar
+   "dot" notation) of the atNetAddress object type associated with x.
+
+   The name of an address translation equivalence e is an OBJECT
+   IDENTIFIER value of the form s.w, such that s is the value of that
+   instance of the atIndex object type associated with e and such that w
+   is the name of the AT-cached network address associated with e.
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 13]
+
+RFC 1157                          SNMP                          May 1990
+
+
+   For each object type, t, for which the defined name, n, has a prefix
+   of atEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of
+   the form n.y, where y is the name of the address translation
+   equivalence about which i represents information.
+
+   For example, suppose one wanted to find the physical address of an
+   entry in the address translation table (ARP cache) associated with an
+   IP address of 89.1.1.42 and interface 3.  Accordingly,
+   atPhysAddress.3.1.89.1.1.42 would identify the desired instance.
+
+3.2.6.3.3.  ipAddrTable Object Type Names
+
+   The name of an IP-addressable network element, x, is the OBJECT
+   IDENTIFIER of the form a.b.c.d such that a.b.c.d is the value (in the
+   familiar "dot" notation) of that instance of the ipAdEntAddr object
+   type associated with x.
+
+   For each object type, t, for which the defined name, n, has a prefix
+   of ipAddrEntry, an instance, i, of t is named by an OBJECT IDENTIFIER
+   of the form n.y, where y is the name of the IP-addressable network
+   element about which i represents information.
+
+   For example, suppose one wanted to find the network mask of an entry
+   in the IP interface table associated with an IP address of 89.1.1.42.
+   Accordingly, ipAdEntNetMask.89.1.1.42 would identify the desired
+   instance.
+
+3.2.6.3.4.  ipRoutingTable Object Type Names
+
+   The name of an IP route, x, is the OBJECT IDENTIFIER of the form
+   a.b.c.d such that a.b.c.d is the value (in the familiar "dot"
+   notation) of that instance of the ipRouteDest object type associated
+   with x.
+
+   For each object type, t, for which the defined name, n, has a prefix
+   of ipRoutingEntry, an instance, i, of t is named by an OBJECT
+   IDENTIFIER of the form n.y, where y is the name of the IP route about
+   which i represents information.
+
+   For example, suppose one wanted to find the next hop of an entry in
+   the IP routing table associated  with the destination of 89.1.1.42.
+   Accordingly, ipRouteNextHop.89.1.1.42 would identify the desired
+   instance.
+
+3.2.6.3.5.  tcpConnTable Object Type Names
+
+   The name of a TCP connection, x, is the OBJECT IDENTIFIER of the form
+   a.b.c.d.e.f.g.h.i.j such that a.b.c.d is the value (in the familiar
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 14]
+
+RFC 1157                          SNMP                          May 1990
+
+
+   "dot" notation) of that instance of the tcpConnLocalAddress object
+   type associated with x and such that f.g.h.i is the value (in the
+   familiar "dot" notation) of that instance of the tcpConnRemoteAddress
+   object type associated with x and such that e is the value of that
+   instance of the tcpConnLocalPort object type associated with x and
+   such that j is the value of that instance of the tcpConnRemotePort
+   object type associated with x.
+
+   For each object type, t, for which the defined name, n, has a prefix
+   of  tcpConnEntry, an instance, i, of t is named by an OBJECT
+   IDENTIFIER of the form n.y, where y is the name of the TCP connection
+   about which i represents information.
+
+   For example, suppose one wanted to find the state of a TCP connection
+   between the local address of 89.1.1.42 on TCP port 21 and the remote
+   address of 10.0.0.51 on TCP port 2059.  Accordingly,
+   tcpConnState.89.1.1.42.21.10.0.0.51.2059 would identify the desired
+   instance.
+
+3.2.6.3.6.  egpNeighTable Object Type Names
+
+   The name of an EGP neighbor, x, is the OBJECT IDENTIFIER of the form
+   a.b.c.d such that a.b.c.d is the value (in the familiar "dot"
+   notation) of that instance of the egpNeighAddr object type associated
+   with x.
+
+   For each object type, t, for which the defined name, n, has a prefix
+   of egpNeighEntry, an instance, i, of t is named by an OBJECT
+   IDENTIFIER of the form n.y, where y is the name of the EGP neighbor
+   about which i represents information.
+
+   For example, suppose one wanted to find the neighbor state for the IP
+   address of 89.1.1.42.  Accordingly, egpNeighState.89.1.1.42 would
+   identify the desired instance.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 15]
+
+RFC 1157                          SNMP                          May 1990
+
+
+4.  Protocol Specification
+
+   The network management protocol is an application protocol by which
+   the variables of an agent's MIB may be inspected or altered.
+
+   Communication among protocol entities is accomplished by the exchange
+   of messages, each of which is entirely and independently represented
+   within a single UDP datagram using the basic encoding rules of ASN.1
+   (as discussed in Section 3.2.2).  A message consists of a version
+   identifier, an SNMP community name, and a protocol data unit (PDU).
+   A protocol entity receives messages at UDP port 161 on the host with
+   which it is associated for all messages except for those which report
+   traps (i.e., all messages except those which contain the Trap-PDU).
+   Messages which report traps should be received on UDP port 162 for
+   further processing.  An implementation of this protocol need not
+   accept messages whose length exceeds 484 octets.  However, it is
+   recommended that implementations support larger datagrams whenever
+   feasible.
+
+   It is mandatory that all implementations of the SNMP support the five
+   PDUs:  GetRequest-PDU, GetNextRequest-PDU, GetResponse-PDU,
+   SetRequest-PDU, and Trap-PDU.
+
+    RFC1157-SNMP DEFINITIONS ::= BEGIN
+
+     IMPORTS
+          ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
+                  FROM RFC1155-SMI;
+
+
+     -- top-level message
+
+             Message ::=
+                     SEQUENCE {
+                          version        -- version-1 for this RFC
+                             INTEGER {
+                                 version-1(0)
+                             },
+
+                         community      -- community name
+                             OCTET STRING,
+
+                         data           -- e.g., PDUs if trivial
+                             ANY        -- authentication is being used
+                     }
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 16]
+
+RFC 1157                          SNMP                          May 1990
+
+
+     -- protocol data units
+
+             PDUs ::=
+                     CHOICE {
+                         get-request
+                             GetRequest-PDU,
+
+                         get-next-request
+                             GetNextRequest-PDU,
+
+                         get-response
+                             GetResponse-PDU,
+
+                         set-request
+                             SetRequest-PDU,
+
+                         trap
+                             Trap-PDU
+                          }
+
+     -- the individual PDUs and commonly used
+     -- data types will be defined later
+
+     END
+
+
+4.1.  Elements of Procedure
+
+   This section describes the actions of a protocol entity implementing
+   the SNMP. Note, however, that it is not intended to constrain the
+   internal architecture of any conformant implementation.
+
+   In the text that follows, the term transport address is used.  In the
+   case of the UDP, a transport address consists of an IP address along
+   with a UDP port.  Other transport services may be used to support the
+   SNMP.  In these cases, the definition of a transport address should
+   be made accordingly.
+
+   The top-level actions of a protocol entity which generates a message
+   are as follows:
+
+        (1)  It first constructs the appropriate PDU, e.g., the
+             GetRequest-PDU, as an ASN.1 object.
+
+        (2)  It then passes this ASN.1 object along with a community
+             name its source transport address and the destination
+             transport address, to the service which implements the
+             desired authentication scheme.  This authentication
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 17]
+
+RFC 1157                          SNMP                          May 1990
+
+
+             service returns another ASN.1 object.
+
+        (3)  The protocol entity then constructs an ASN.1 Message
+             object, using the community name and the resulting ASN.1
+             object.
+
+        (4)  This new ASN.1 object is then serialized, using the basic
+             encoding rules of ASN.1, and then sent using a transport
+             service to the peer protocol entity.
+
+   Similarly, the top-level actions of a protocol entity which receives
+   a message are as follows:
+
+        (1)  It performs a rudimentary parse of the incoming datagram
+             to build an ASN.1 object corresponding to an ASN.1
+             Message object. If the parse fails, it discards the
+             datagram and performs no further actions.
+
+        (2)  It then verifies the version number of the SNMP message.
+             If there is a mismatch, it discards the datagram and
+             performs no further actions.
+
+        (3)  The protocol entity then passes the community name and
+             user data found in the ASN.1 Message object, along with
+             the datagram's source and destination transport addresses
+             to the service which implements the desired
+             authentication scheme.  This entity returns another ASN.1
+             object, or signals an authentication failure.  In the
+             latter case, the protocol entity notes this failure,
+             (possibly) generates a trap, and discards the datagram
+             and performs no further actions.
+
+        (4)  The protocol entity then performs a rudimentary parse on
+             the ASN.1 object returned from the authentication service
+             to build an ASN.1 object corresponding to an ASN.1 PDUs
+             object.  If the parse fails, it discards the datagram and
+             performs no further actions.  Otherwise, using the named
+             SNMP community, the appropriate profile is selected, and
+             the PDU is processed accordingly.  If, as a result of
+             this processing, a message is returned then the source
+             transport address that the response message is sent from
+             shall be identical to the destination transport address
+             that the original request message was sent to.
+
+
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 18]
+
+RFC 1157                          SNMP                          May 1990
+
+
+4.1.1.  Common Constructs
+
+   Before introducing the six PDU types of the protocol, it is
+   appropriate to consider some of the ASN.1 constructs used frequently:
+
+                  -- request/response information
+
+                  RequestID ::=
+                          INTEGER
+
+                  ErrorStatus ::=
+                          INTEGER {
+                              noError(0),
+                              tooBig(1),
+                              noSuchName(2),
+                              badValue(3),
+                              readOnly(4)
+                              genErr(5)
+                          }
+
+                  ErrorIndex ::=
+                          INTEGER
+
+
+                  -- variable bindings
+
+                  VarBind ::=
+                          SEQUENCE {
+                              name
+                                  ObjectName,
+
+                              value
+                                  ObjectSyntax
+                          }
+
+                  VarBindList ::=
+                          SEQUENCE OF
+                              VarBind
+
+
+   RequestIDs are used to distinguish among outstanding requests.  By
+   use of the RequestID, an SNMP application entity can correlate
+   incoming responses with outstanding requests.  In cases where an
+   unreliable datagram service is being used, the RequestID also
+   provides a simple means of identifying messages duplicated by the
+   network.
+
+   A non-zero instance of ErrorStatus is used to indicate that an
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 19]
+
+RFC 1157                          SNMP                          May 1990
+
+
+   exception occurred while processing a request.  In these cases,
+   ErrorIndex may provide additional information by indicating which
+   variable in a list caused the exception.
+
+   The term variable refers to an instance of a managed object.  A
+   variable binding, or VarBind, refers to the pairing of the name of a
+   variable to the variable's value.  A VarBindList is a simple list of
+   variable names and corresponding values.  Some PDUs are concerned
+   only with the name of a variable and not its value (e.g., the
+   GetRequest-PDU).  In this case, the value portion of the binding is
+   ignored by the protocol entity.  However, the value portion must
+   still have valid ASN.1 syntax and encoding.  It is recommended that
+   the ASN.1 value NULL be used for the value portion of such bindings.
+
+4.1.2.  The GetRequest-PDU
+
+             The form of the GetRequest-PDU is:
+                  GetRequest-PDU ::=
+                      [0]
+                          IMPLICIT SEQUENCE {
+                              request-id
+                                  RequestID,
+
+                              error-status        -- always 0
+                                  ErrorStatus,
+
+                              error-index         -- always 0
+                                  ErrorIndex,
+
+                              variable-bindings
+                                  VarBindList
+                          }
+
+
+   The GetRequest-PDU is generated by a protocol entity only at the
+   request of its SNMP application entity.
+
+   Upon receipt of the GetRequest-PDU, the receiving protocol entity
+   responds according to any applicable rule in the list below:
+
+        (1)  If, for any object named in the variable-bindings field,
+             the object's name does not exactly match the name of some
+             object available for get operations in the relevant MIB
+             view, then the receiving entity sends to the originator
+             of the received message the GetResponse-PDU of identical
+             form, except that the value of the error-status field is
+             noSuchName, and the value of the error-index field is the
+             index of said object name component in the received
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 20]
+
+RFC 1157                          SNMP                          May 1990
+
+
+             message.
+
+        (2)  If, for any object named in the variable-bindings field,
+             the object is an aggregate type (as defined in the SMI),
+             then the receiving entity sends to the originator of the
+             received message the GetResponse-PDU of identical form,
+             except that the value of the error-status field is
+             noSuchName, and the value of the error-index field is the
+             index of said object name component in the received
+             message.
+
+        (3)  If the size of the GetResponse-PDU generated as described
+             below would exceed a local limitation, then the receiving
+             entity sends to the originator of the received message
+             the GetResponse-PDU of identical form, except that the
+             value of the error-status field is tooBig, and the value
+             of the error-index field is zero.
+
+        (4)  If, for any object named in the variable-bindings field,
+             the value of the object cannot be retrieved for reasons
+             not covered by any of the foregoing rules, then the
+             receiving entity sends to the originator of the received
+             message the GetResponse-PDU of identical form, except
+             that the value of the error-status field is genErr and
+             the value of the error-index field is the index of said
+             object name component in the received message.
+
+   If none of the foregoing rules apply, then the receiving protocol
+   entity sends to the originator of the received message the
+   GetResponse-PDU such that, for each object named in the variable-
+   bindings field of the received message, the corresponding component
+   of the GetResponse-PDU represents the name and value of that
+   variable.  The value of the error- status field of the GetResponse-
+   PDU is noError and the value of the error-index field is zero.  The
+   value of the request-id field of the GetResponse-PDU is that of the
+   received message.
+
+4.1.3.  The GetNextRequest-PDU
+
+   The form of the GetNextRequest-PDU is identical to that of the
+   GetRequest-PDU except for the indication of the PDU type.  In the
+   ASN.1 language:
+
+                  GetNextRequest-PDU ::=
+                      [1]
+                          IMPLICIT SEQUENCE {
+                              request-id
+                                  RequestID,
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 21]
+
+RFC 1157                          SNMP                          May 1990
+
+
+                              error-status        -- always 0
+                                  ErrorStatus,
+
+                              error-index         -- always 0
+                                  ErrorIndex,
+
+                              variable-bindings
+                                  VarBindList
+                          }
+
+
+   The GetNextRequest-PDU is generated by a protocol entity only at the
+   request of its SNMP application entity.
+
+   Upon receipt of the GetNextRequest-PDU, the receiving protocol entity
+   responds according to any applicable rule in the list below:
+
+        (1)  If, for any object name in the variable-bindings field,
+             that name does not lexicographically precede the name of
+             some object available for get operations in the relevant
+             MIB view, then the receiving entity sends to the
+             originator of the received message the GetResponse-PDU of
+             identical form, except that the value of the error-status
+             field is noSuchName, and the value of the error-index
+             field is the index of said object name component in the
+             received message.
+
+        (2)  If the size of the GetResponse-PDU generated as described
+             below would exceed a local limitation, then the receiving
+             entity sends to the originator of the received message
+             the GetResponse-PDU of identical form, except that the
+             value of the error-status field is tooBig, and the value
+             of the error-index field is zero.
+
+        (3)  If, for any object named in the variable-bindings field,
+             the value of the lexicographical successor to the named
+             object cannot be retrieved for reasons not covered by any
+             of the foregoing rules, then the receiving entity sends
+             to the originator of the received message the
+             GetResponse-PDU of identical form, except that the value
+             of the error-status field is genErr and the value of the
+             error-index field is the index of said object name
+             component in the received message.
+
+   If none of the foregoing rules apply, then the receiving protocol
+   entity sends to the originator of the received message the
+   GetResponse-PDU such that, for each name in the variable-bindings
+   field of the received message, the corresponding component of the
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 22]
+
+RFC 1157                          SNMP                          May 1990
+
+
+   GetResponse-PDU represents the name and value of that object whose
+   name is, in the lexicographical ordering of the names of all objects
+   available for get operations in the relevant MIB view, together with
+   the value of the name field of the given component, the immediate
+   successor to that value.  The value of the error-status field of the
+   GetResponse-PDU is noError and the value of the errorindex field is
+   zero.  The value of the request-id field of the GetResponse-PDU is
+   that of the received message.
+
+4.1.3.1.  Example of Table Traversal
+
+   One important use of the GetNextRequest-PDU is the traversal of
+   conceptual tables of information within the MIB. The semantics of
+   this type of SNMP message, together with the protocol-specific
+   mechanisms for identifying individual instances of object types in
+   the MIB, affords  access to related objects in the MIB as if they
+   enjoyed a tabular organization.
+
+   By the SNMP exchange sketched below, an SNMP application entity might
+   extract the destination address and next hop gateway for each entry
+   in the routing table of a particular network element. Suppose that
+   this routing table has three entries:
+
+         Destination                     NextHop         Metric
+
+         10.0.0.99                       89.1.1.42       5
+         9.1.2.3                         99.0.0.3        3
+         10.0.0.51                       89.1.1.42       5
+
+
+   The management station sends to the SNMP agent a GetNextRequest-PDU
+   containing the indicated OBJECT IDENTIFIER values as the requested
+   variable names:
+
+   GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )
+
+
+   The SNMP agent responds with a GetResponse-PDU:
+
+                 GetResponse (( ipRouteDest.9.1.2.3 =  "9.1.2.3" ),
+                         ( ipRouteNextHop.9.1.2.3 = "99.0.0.3" ),
+                         ( ipRouteMetric1.9.1.2.3 = 3 ))
+
+
+   The management station continues with:
+
+                 GetNextRequest ( ipRouteDest.9.1.2.3,
+                         ipRouteNextHop.9.1.2.3,
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 23]
+
+RFC 1157                          SNMP                          May 1990
+
+
+                         ipRouteMetric1.9.1.2.3 )
+
+
+   The SNMP agent responds:
+
+                 GetResponse (( ipRouteDest.10.0.0.51 = "10.0.0.51" ),
+                         ( ipRouteNextHop.10.0.0.51 = "89.1.1.42" ),
+                         ( ipRouteMetric1.10.0.0.51 = 5 ))
+
+
+   The management station continues with:
+
+                 GetNextRequest ( ipRouteDest.10.0.0.51,
+                         ipRouteNextHop.10.0.0.51,
+                         ipRouteMetric1.10.0.0.51 )
+
+
+   The SNMP agent responds:
+
+                 GetResponse (( ipRouteDest.10.0.0.99 = "10.0.0.99" ),
+                         ( ipRouteNextHop.10.0.0.99 = "89.1.1.42" ),
+                         ( ipRouteMetric1.10.0.0.99 = 5 ))
+
+
+   The management station continues with:
+
+                 GetNextRequest ( ipRouteDest.10.0.0.99,
+                         ipRouteNextHop.10.0.0.99,
+                         ipRouteMetric1.10.0.0.99 )
+
+
+   As there are no further entries in the table, the SNMP agent returns
+   those objects that are next in the lexicographical ordering of the
+   known object names.  This response signals the end of the routing
+   table to the management station.
+
+4.1.4.  The GetResponse-PDU
+
+   The form of the GetResponse-PDU is identical to that of the
+   GetRequest-PDU except for the indication of the PDU type.  In the
+   ASN.1 language:
+
+                  GetResponse-PDU ::=
+                      [2]
+                          IMPLICIT SEQUENCE {
+                              request-id
+                                  RequestID,
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 24]
+
+RFC 1157                          SNMP                          May 1990
+
+
+                              error-status
+                                  ErrorStatus,
+
+                              error-index
+                                  ErrorIndex,
+
+                              variable-bindings
+                                  VarBindList
+                          }
+
+
+   The GetResponse-PDU is generated by a protocol entity only upon
+   receipt of the GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU,
+   as described elsewhere in this document.
+
+   Upon receipt of the GetResponse-PDU, the receiving protocol entity
+   presents its contents to its SNMP application entity.
+
+4.1.5.  The SetRequest-PDU
+
+   The form of the SetRequest-PDU is identical to that of the
+   GetRequest-PDU except for the indication of the PDU type.  In the
+   ASN.1 language:
+
+                  SetRequest-PDU ::=
+                      [3]
+                          IMPLICIT SEQUENCE {
+                              request-id
+                                  RequestID,
+
+                              error-status        -- always 0
+                                  ErrorStatus,
+
+                              error-index         -- always 0
+                                  ErrorIndex,
+
+                              variable-bindings
+                                  VarBindList
+                          }
+
+
+   The SetRequest-PDU is generated by a protocol entity only at the
+   request of its SNMP application entity.
+
+   Upon receipt of the SetRequest-PDU, the receiving entity responds
+   according to any applicable rule in the list below:
+
+        (1)  If, for any object named in the variable-bindings field,
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 25]
+
+RFC 1157                          SNMP                          May 1990
+
+
+             the object is not available for set operations in the
+             relevant MIB view, then the receiving entity sends to the
+             originator of the received message the GetResponse-PDU of
+             identical form, except that the value of the error-status
+             field is noSuchName, and the value of the error-index
+             field is the index of said object name component in the
+             received message.
+
+        (2)  If, for any object named in the variable-bindings field,
+             the contents of the value field does not, according to
+             the ASN.1 language, manifest a type, length, and value
+             that is consistent with that required for the variable,
+             then the receiving entity sends to the originator of the
+             received message the GetResponse-PDU of identical form,
+             except that the value of the error-status field is
+             badValue, and the value of the error-index field is the
+             index of said object name in the received message.
+
+        (3)  If the size of the Get Response type message generated as
+             described below would exceed a local limitation, then the
+             receiving entity sends to the originator of the received
+             message the GetResponse-PDU of identical form, except
+             that the value of the error-status field is tooBig, and
+             the value of the error-index field is zero.
+
+        (4)  If, for any object named in the variable-bindings field,
+             the value of the named object cannot be altered for
+             reasons not covered by any of the foregoing rules, then
+             the receiving entity sends to the originator of the
+             received message the GetResponse-PDU of identical form,
+             except that the value of the error-status field is genErr
+             and the value of the error-index field is the index of
+             said object name component in the received message.
+
+   If none of the foregoing rules apply, then for each object named in
+   the variable-bindings field of the received message, the
+   corresponding value is assigned to the variable.  Each variable
+   assignment specified by the SetRequest-PDU should be effected as if
+   simultaneously set with respect to all other assignments specified in
+   the same message.
+
+   The receiving entity then sends to the originator of the received
+   message the GetResponse-PDU of identical form except that the value
+   of the error-status field of the generated message is noError and the
+   value of the error-index field is zero.
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 26]
+
+RFC 1157                          SNMP                          May 1990
+
+
+4.1.6.  The Trap-PDU
+
+   The form of the Trap-PDU is:
+
+     Trap-PDU ::=
+         [4]
+
+              IMPLICIT SEQUENCE {
+                 enterprise          -- type of object generating
+                                     -- trap, see sysObjectID in [5]
+                     OBJECT IDENTIFIER,
+
+                 agent-addr          -- address of object generating
+                     NetworkAddress, -- trap
+
+                 generic-trap        -- generic trap type
+                     INTEGER {
+                         coldStart(0),
+                         warmStart(1),
+                         linkDown(2),
+                         linkUp(3),
+                         authenticationFailure(4),
+                         egpNeighborLoss(5),
+                         enterpriseSpecific(6)
+                     },
+
+                 specific-trap     -- specific code, present even
+                     INTEGER,      -- if generic-trap is not
+                                   -- enterpriseSpecific
+
+                 time-stamp        -- time elapsed between the last
+                   TimeTicks,      -- (re)initialization of the network
+                                   -- entity and the generation of the
+                                      trap
+
+                 variable-bindings   -- "interesting" information
+                      VarBindList
+             }
+
+
+   The Trap-PDU is generated by a protocol entity only at the request of
+   the SNMP application entity.  The means by which an SNMP application
+   entity selects the destination addresses of the SNMP application
+   entities is implementation-specific.
+
+   Upon receipt of the Trap-PDU, the receiving protocol entity presents
+   its contents to its SNMP application entity.
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 27]
+
+RFC 1157                          SNMP                          May 1990
+
+
+   The significance of the variable-bindings component of the Trap-PDU
+   is implementation-specific.
+
+   Interpretations of the value of the generic-trap field are:
+
+4.1.6.1.  The coldStart Trap
+
+   A coldStart(0) trap signifies that the sending protocol entity is
+   reinitializing itself such that the agent's configuration or the
+   protocol entity implementation may be altered.
+
+4.1.6.2.  The warmStart Trap
+
+   A warmStart(1) trap signifies that the sending protocol entity is
+   reinitializing itself such that neither the agent configuration nor
+   the protocol entity implementation is altered.
+
+4.1.6.3.  The linkDown Trap
+
+   A linkDown(2) trap signifies that the sending protocol entity
+   recognizes a failure in one of the communication links represented in
+   the agent's configuration.
+
+   The Trap-PDU of type linkDown contains as the first element of its
+   variable-bindings, the name and value of the ifIndex instance for the
+   affected interface.
+
+4.1.6.4.  The linkUp Trap
+
+   A linkUp(3) trap signifies that the sending protocol entity
+   recognizes that one of the communication links represented in the
+   agent's configuration has come up.
+
+   The Trap-PDU of type linkUp contains as the first element of its
+   variable-bindings, the name and value of the ifIndex instance for the
+   affected interface.
+
+4.1.6.5.  The authenticationFailure Trap
+
+   An authenticationFailure(4) trap signifies that the sending protocol
+   entity is the addressee of a protocol message that is not properly
+   authenticated.  While implementations of the SNMP must be capable of
+   generating this trap, they must also be capable of suppressing the
+   emission of such traps via an implementation-specific mechanism.
+
+4.1.6.6.  The egpNeighborLoss Trap
+
+   An egpNeighborLoss(5) trap signifies that an EGP neighbor for whom
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 28]
+
+RFC 1157                          SNMP                          May 1990
+
+
+   the sending protocol entity was an EGP peer has been marked down and
+   the peer relationship no longer obtains.
+
+   The Trap-PDU of type egpNeighborLoss contains as the first element of
+   its variable-bindings, the name and value of the egpNeighAddr
+   instance for the affected neighbor.
+
+4.1.6.7.  The enterpriseSpecific Trap
+
+   A enterpriseSpecific(6) trap signifies that the sending protocol
+   entity recognizes that some enterprise-specific event has occurred.
+   The specific-trap field identifies the particular trap which
+   occurred.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 29]
+
+RFC 1157                          SNMP                          May 1990
+
+
+5.  Definitions
+
+     RFC1157-SNMP DEFINITIONS ::= BEGIN
+
+      IMPORTS
+          ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
+              FROM RFC1155-SMI;
+
+
+          -- top-level message
+
+          Message ::=
+                  SEQUENCE {
+                      version          -- version-1 for this RFC
+                          INTEGER {
+                              version-1(0)
+                          },
+
+                      community        -- community name
+                          OCTET STRING,
+
+                      data             -- e.g., PDUs if trivial
+                          ANY          -- authentication is being used
+                  }
+
+
+          -- protocol data units
+
+          PDUs ::=
+                  CHOICE {
+                              get-request
+                                  GetRequest-PDU,
+
+                              get-next-request
+                                  GetNextRequest-PDU,
+
+                              get-response
+                                  GetResponse-PDU,
+
+                              set-request
+                                  SetRequest-PDU,
+
+                              trap
+                                  Trap-PDU
+                          }
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 30]
+
+RFC 1157                          SNMP                          May 1990
+
+
+          -- PDUs
+
+          GetRequest-PDU ::=
+              [0]
+                  IMPLICIT PDU
+
+          GetNextRequest-PDU ::=
+              [1]
+                  IMPLICIT PDU
+
+          GetResponse-PDU ::=
+              [2]
+                  IMPLICIT PDU
+
+          SetRequest-PDU ::=
+              [3]
+                  IMPLICIT PDU
+
+          PDU ::=
+                  SEQUENCE {
+                     request-id
+                          INTEGER,
+
+                      error-status      -- sometimes ignored
+                          INTEGER {
+                              noError(0),
+                              tooBig(1),
+                              noSuchName(2),
+                              badValue(3),
+                              readOnly(4),
+                              genErr(5)
+                          },
+
+                      error-index       -- sometimes ignored
+                         INTEGER,
+
+                      variable-bindings -- values are sometimes ignored
+                          VarBindList
+                  }
+
+          Trap-PDU ::=
+              [4]
+                 IMPLICIT SEQUENCE {
+                      enterprise        -- type of object generating
+                                        -- trap, see sysObjectID in [5]
+
+
+                          OBJECT IDENTIFIER,
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 31]
+
+RFC 1157                          SNMP                          May 1990
+
+
+                      agent-addr        -- address of object generating
+                          NetworkAddress, -- trap
+
+                      generic-trap      -- generic trap type
+                          INTEGER {
+                              coldStart(0),
+                              warmStart(1),
+                              linkDown(2),
+                              linkUp(3),
+                              authenticationFailure(4),
+                              egpNeighborLoss(5),
+                              enterpriseSpecific(6)
+                          },
+
+                      specific-trap  -- specific code, present even
+                          INTEGER,   -- if generic-trap is not
+                                     -- enterpriseSpecific
+
+                      time-stamp     -- time elapsed between the last
+                          TimeTicks, -- (re)initialization of the
+                                        network
+                                     -- entity and the generation of the
+                                        trap
+
+                       variable-bindings -- "interesting" information
+                          VarBindList
+                  }
+
+
+          -- variable bindings
+
+          VarBind ::=
+                  SEQUENCE {
+                      name
+                          ObjectName,
+
+                      value
+                          ObjectSyntax
+                  }
+
+         VarBindList ::=
+                  SEQUENCE OF
+                     VarBind
+
+         END
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 32]
+
+RFC 1157                          SNMP                          May 1990
+
+
+6.  Acknowledgements
+
+   This memo was influenced by the IETF SNMP Extensions working
+   group:
+
+             Karl Auerbach, Epilogue Technology
+             K. Ramesh Babu, Excelan
+             Amatzia Ben-Artzi, 3Com/Bridge
+             Lawrence Besaw, Hewlett-Packard
+             Jeffrey D. Case, University of Tennessee at Knoxville
+             Anthony Chung, Sytek
+             James Davidson, The Wollongong Group
+             James R. Davin, MIT Laboratory for Computer Science
+             Mark S. Fedor, NYSERNet
+             Phill Gross, The MITRE Corporation
+             Satish Joshi, ACC
+             Dan Lynch, Advanced Computing Environments
+             Keith McCloghrie, The Wollongong Group
+             Marshall T. Rose, The Wollongong Group (chair)
+             Greg Satz, cisco
+             Martin Lee Schoffstall, Rensselaer Polytechnic Institute
+             Wengyik Yeong, NYSERNet
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 33]
+
+RFC 1157                          SNMP                          May 1990
+
+
+7.  References
+
+   [1] Cerf, V., "IAB Recommendations for the Development of
+       Internet Network Management Standards", RFC 1052, IAB,
+       April 1988.
+
+   [2] Rose, M., and K. McCloghrie, "Structure and Identification
+       of Management Information for TCP/IP-based internets",
+       RFC 1065, TWG, August 1988.
+
+   [3] McCloghrie, K., and M. Rose, "Management Information Base
+       for Network Management of TCP/IP-based internets",
+       RFC 1066, TWG, August 1988.
+
+   [4] Cerf, V., "Report of the Second Ad Hoc Network Management
+       Review Group", RFC 1109, IAB, August 1989.
+
+   [5] Rose, M., and K. McCloghrie, "Structure and Identification
+       of Management Information for TCP/IP-based Internets",
+       RFC 1155, Performance Systems International and Hughes LAN
+       Systems, May 1990.
+
+   [6] McCloghrie, K., and M. Rose, "Management Information Base
+       for Network Management of TCP/IP-based Internets",
+       RFC 1156, Hughes LAN Systems and Performance Systems
+       International, May 1990.
+
+   [7] Case, J., M. Fedor, M. Schoffstall, and J. Davin,
+       "A Simple Network Management Protocol", Internet
+       Engineering Task Force working note, Network Information
+       Center, SRI International, Menlo Park, California,
+       March 1988.
+
+   [8] Davin, J., J. Case, M. Fedor, and M. Schoffstall,
+       "A Simple Gateway Monitoring Protocol", RFC 1028,
+       Proteon, University of Tennessee at Knoxville,
+       Cornell University, and Rensselaer Polytechnic
+       Institute, November 1987.
+
+   [9] Information processing systems - Open Systems
+       Interconnection, "Specification of Abstract Syntax
+       Notation One (ASN.1)", International Organization for
+       Standardization, International Standard 8824,
+       December 1987.
+
+  [10] Information processing systems - Open Systems
+       Interconnection, "Specification of Basic Encoding Rules
+       for Abstract Notation One (ASN.1)", International
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 34]
+
+RFC 1157                          SNMP                          May 1990
+
+
+       Organization for Standardization, International Standard
+       8825, December 1987.
+
+  [11] Postel, J., "User Datagram Protocol", RFC 768,
+       USC/Information Sciences Institute, November 1980.
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+Authors' Addresses
+
+   Jeffrey D. Case
+   SNMP Research
+   P.O. Box 8593
+   Knoxville, TN 37996-4800
+
+   Phone:  (615) 573-1434
+
+   Email:  case@CS.UTK.EDU
+
+
+   Mark Fedor
+   Performance Systems International
+   Rensselaer Technology Park
+   125 Jordan Road
+   Troy, NY 12180
+
+   Phone:  (518) 283-8860
+
+   Email:  fedor@patton.NYSER.NET
+
+
+   Martin Lee Schoffstall
+   Performance Systems International
+   Rensselaer Technology Park
+   165 Jordan Road
+   Troy, NY 12180
+
+   Phone:  (518) 283-8860
+
+   Email:  schoff@NISC.NYSER.NET
+
+
+
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 35]
+
+RFC 1157                          SNMP                          May 1990
+
+
+   James R. Davin
+   MIT Laboratory for Computer Science, NE43-507
+   545 Technology Square
+   Cambridge, MA 02139
+
+   Phone:  (617) 253-6020
+
+   EMail:  jrd@ptt.lcs.mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Case, Fedor, Schoffstall, & Davin                              [Page 36]
+
\ No newline at end of file
diff --git a/standards/rfc2790.txt b/standards/rfc2790.txt
new file mode 100644
index 000000000..3b0ddd81b
--- /dev/null
+++ b/standards/rfc2790.txt
@@ -0,0 +1,2803 @@
+
+
+
+
+
+
+Network Working Group                                      S. Waldbusser
+Request for Comments: 2790                      Lucent Technologies Inc.
+Obsoletes: 1514                                                P. Grillo
+Category: Standards Track                                     WeSync.com
+                                                              March 2000
+
+
+                           Host Resources MIB
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This memo defines a portion of the Management Information Base (MIB)
+   for use with network management protocols in the Internet community.
+   This memo obsoletes RFC 1514, the "Host Resources MIB". This memo
+   extends that specification by clarifying changes based on
+   implementation and deployment experience and documenting the Host
+   Resources MIB in SMIv2 format while remaining semantically identical
+   to the existing SMIv1-based MIB.
+
+   This memo defines a MIB for use with managing host systems.  The term
+   "host" is construed to mean any computer that communicates with other
+   similar computers attached to the internet and that is directly used
+   by one or more human beings. Although this MIB does not necessarily
+   apply to devices whose primary function is communications services
+   (e.g., terminal servers, routers, bridges, monitoring equipment),
+   such relevance is not explicitly precluded.  This MIB instruments
+   attributes common to all internet hosts including, for example, both
+   personal computers and systems that run variants of Unix.
+
+
+
+
+
+
+
+
+
+
+
+Waldbusser & Grillo         Standards Track                     [Page 1]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+Table of Contents
+
+   1 The SNMP Management Framework ............................    2
+   2 Host Resources MIB .......................................    3
+   3 IANA Considerations ......................................    4
+   4 Definitions ..............................................    4
+   4.1 Textual Conventions ....................................    6
+   4.2 The Host Resources System Group ........................    7
+   4.3 The Host Resources Storage Group .......................    9
+   4.4 The Host Resources Device Group ........................   12
+   4.5 The Host Resources Running Software Group ..............   26
+   4.6 The Host Resources  Running  Software  Performance
+        Group .................................................   29
+   4.7 The Host Resources Installed Software Group ............   30
+   4.8 Conformance Definitions ................................   33
+   5 Type Definitions .........................................   36
+   6 Internationalization Considerations ......................   44
+   7 Security Considerations ..................................   45
+   8 References ...............................................   46
+   9 Acknowledgments ..........................................   48
+   10 Authors' Addresses ......................................   49
+   11 Intellectual Property ...................................   49
+   12 Full Copyright Statement ................................   50
+
+1.  The SNMP Management Framework
+
+   The SNMP Management Framework presently consists of five major
+   components:
+
+   o   An overall architecture, described in RFC 2571 [RFC2571].
+
+   o   Mechanisms for describing and naming objects and events for the
+       purpose of management. The first version of this Structure of
+       Management Information (SMI) is called SMIv1 and described in STD
+       16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215
+       [RFC1215]. The second version, called SMIv2, is described in STD
+       58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580
+       [RFC2580].
+
+   o   Message protocols for transferring management information. The
+       first version of the SNMP message protocol is called SNMPv1 and
+       described in STD 15, RFC 1157 [RFC1157]. A second version of the
+       SNMP message protocol, which is not an Internet standards track
+       protocol, is called SNMPv2c and described in RFC 1901 [RFC1901]
+       and RFC 1906 [RFC1906]. The third version of the message protocol
+       is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572
+       [RFC2572] and RFC 2574 [RFC2574].
+
+
+
+
+Waldbusser & Grillo         Standards Track                     [Page 2]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+   o   Protocol operations for accessing management information. The
+       first set of protocol operations and associated PDU formats is
+       described in STD 15, RFC 1157 [RFC1157]. A second set of protocol
+       operations and associated PDU formats is described in RFC 1905
+       [RFC1905].
+
+   o   A set of fundamental applications described in RFC 2573 [RFC2573]
+       and the view-based access control mechanism described in RFC 2575
+       [RFC2575].
+
+   A more detailed introduction to the current SNMP Management Framework
+   can be found in RFC 2570 [RFC2570].
+
+   Managed objects are accessed via a virtual information store, termed
+   the Management Information Base or MIB.  Objects in the MIB are
+   defined using the mechanisms defined in the SMI.
+
+   This memo specifies a MIB module that is compliant to the SMIv2. A
+   MIB conforming to the SMIv1 can be produced through the appropriate
+   translations. The resulting translated MIB must be semantically
+   equivalent, except where objects or events are omitted because no
+   translation is possible (use of Counter64). Some machine readable
+   information in SMIv2 will be converted into textual descriptions in
+   SMIv1 during the translation process.  However, this loss of machine
+   readable information is not considered to change the semantics of the
+   MIB.
+
+2.  Host Resources MIB
+
+   The Host Resources MIB defines a uniform set of objects useful for
+   the management of host computers.  Host computers are independent of
+   the operating system, network services, or any software application.
+
+   The Host Resources MIB defines objects which are common across many
+   computer system architectures.
+
+   In addition, there are objects in the SNMPv2-MIB [RFC1907] and IF-MIB
+   [RFC2233] which also provide host management functionality.
+   Implementation of the System and Interfaces groups is mandatory for
+   implementors of the Host Resources MIB.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+
+Waldbusser & Grillo         Standards Track                     [Page 3]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+3.  IANA Considerations
+
+   This MIB contains type definitions for storage types, device types,
+   and file system types for use as values for the hrStorageType,
+   hrDeviceType, and hrFSType objects, respectively. As new computing
+   technologies are developed, new types need to be registered for these
+   technologies. The IANA (Internet Assigned Numbers Authority) is
+   designated as the registration authority for new registrations beyond
+   those published in this document. The IANA will maintain the HOST-
+   RESOURCES-TYPES module as new registrations are added and publish new
+   versions of this module.
+
+   Given the large number of such technologies and potential confusion
+   in naming of these technologies (such as a technology known by two
+   names or a name and an acronym), there is a real danger that more
+   than one registration might be created for what is essentially the
+   same technology. In order to ensure that future type registrations
+   are performed correctly, applications for new types will be reviewed
+   by a Designated Expert appointed by the IESG.
+
+4.  Definitions
+
+   HOST-RESOURCES-MIB DEFINITIONS ::= BEGIN
+
+   IMPORTS
+   MODULE-IDENTITY, OBJECT-TYPE, mib-2,
+   Integer32, Counter32, Gauge32, TimeTicks  FROM SNMPv2-SMI
+
+   TEXTUAL-CONVENTION, DisplayString,
+   TruthValue, DateAndTime, AutonomousType   FROM SNMPv2-TC
+
+   MODULE-COMPLIANCE, OBJECT-GROUP           FROM SNMPv2-CONF
+
+   InterfaceIndexOrZero                      FROM IF-MIB;
+
+   hostResourcesMibModule MODULE-IDENTITY
+      LAST-UPDATED "200003060000Z"    -- 6 March 2000
+      ORGANIZATION "IETF Host Resources MIB Working Group"
+      CONTACT-INFO
+          "Steve Waldbusser
+          Postal: Lucent Technologies, Inc.
+                  1213 Innsbruck Dr.
+                  Sunnyvale, CA 94089
+                  USA
+          Phone:  650-318-1251
+          Fax:    650-318-1633
+          Email:  waldbusser@lucent.com
+
+
+
+
+Waldbusser & Grillo         Standards Track                     [Page 4]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+          In addition, the Host Resources MIB mailing list is
+          dedicated to discussion of this MIB. To join the
+          mailing list, send a request message to
+          hostmib-request@andrew.cmu.edu. The mailing list
+          address is hostmib@andrew.cmu.edu."
+
+      DESCRIPTION
+          "This MIB is for use in managing host systems. The term
+          `host' is construed to mean any computer that communicates
+          with other similar computers attached to the internet and
+          that is directly used by one or more human beings. Although
+          this MIB does not necessarily apply to devices whose primary
+          function is communications services (e.g., terminal servers,
+          routers, bridges, monitoring equipment), such relevance is
+          not explicitly precluded.  This MIB instruments attributes
+          common to all internet hosts including, for example, both
+          personal computers and systems that run variants of Unix."
+
+      REVISION "200003060000Z"        -- 6 March 2000
+      DESCRIPTION
+          "Clarifications and bug fixes based on implementation
+          experience.  This revision was also reformatted in the SMIv2
+          format. The revisions made were:
+
+          New RFC document standards:
+             Added Copyright notice, updated introduction to SNMP
+             Framework, updated references section, added reference to
+             RFC 2119, and added a meaningful Security Considerations
+             section.
+
+          New IANA considerations section for registration of new types
+
+          Conversion to new SMIv2 syntax for the following types and
+          macros:
+              Counter32, Integer32, Gauge32, MODULE-IDENTITY,
+              OBJECT-TYPE, TEXTUAL-CONVENTION, OBJECT-IDENTITY,
+              MODULE-COMPLIANCE, OBJECT-GROUP
+
+          Used new Textual Conventions:
+              TruthValue, DateAndTime, AutonomousType,
+              InterfaceIndexOrZero
+
+          Fixed typo in hrPrinterStatus.
+
+          Added missing error bits to hrPrinterDetectedErrorState and
+          clarified confusion resulting from suggested mappings to
+          hrPrinterStatus.
+
+
+
+
+Waldbusser & Grillo         Standards Track                     [Page 5]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+          Clarified that size of objects of type
+          InternationalDisplayString is number of octets, not number
+          of encoded symbols.
+
+          Clarified the use of the following objects based on
+          implementation experience:
+              hrSystemInitialLoadDevice, hrSystemInitialLoadParameters,
+              hrMemorySize, hrStorageSize, hrStorageAllocationFailures,
+              hrDeviceErrors, hrProcessorLoad, hrNetworkIfIndex,
+              hrDiskStorageCapacity, hrSWRunStatus, hrSWRunPerfCPU,
+              and hrSWInstalledDate.
+
+          Clarified implementation technique for hrSWInstalledTable.
+
+          Used new AUGMENTS clause for hrSWRunPerfTable.
+
+          Added Internationalization Considerations section.
+
+   This revision published as RFC2790."
+
+      REVISION "9910202200Z"    -- 20 October, 1999
+      DESCRIPTION
+          "The original version of this MIB, published as
+          RFC1514."
+      ::= { hrMIBAdminInfo 1 }
+
+   host     OBJECT IDENTIFIER ::= { mib-2 25 }
+
+   hrSystem        OBJECT IDENTIFIER ::= { host 1 }
+   hrStorage       OBJECT IDENTIFIER ::= { host 2 }
+   hrDevice        OBJECT IDENTIFIER ::= { host 3 }
+   hrSWRun         OBJECT IDENTIFIER ::= { host 4 }
+   hrSWRunPerf     OBJECT IDENTIFIER ::= { host 5 }
+   hrSWInstalled   OBJECT IDENTIFIER ::= { host 6 }
+   hrMIBAdminInfo  OBJECT IDENTIFIER ::= { host 7 }
+
+   -- textual conventions
+
+   KBytes ::= TEXTUAL-CONVENTION
+       STATUS current
+       DESCRIPTION
+           "Storage size, expressed in units of 1024 bytes."
+       SYNTAX Integer32 (0..2147483647)
+
+   ProductID ::= TEXTUAL-CONVENTION
+       STATUS current
+       DESCRIPTION
+           "This textual convention is intended to identify the
+
+
+
+Waldbusser & Grillo         Standards Track                     [Page 6]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+           manufacturer, model, and version of a specific
+           hardware or software product.  It is suggested that
+           these OBJECT IDENTIFIERs are allocated such that all
+           products from a particular manufacturer are registered
+           under a subtree distinct to that manufacturer.  In
+           addition, all versions of a product should be
+           registered under a subtree distinct to that product.
+           With this strategy, a management station may uniquely
+           determine the manufacturer and/or model of a product
+           whose productID is unknown to the management station.
+           Objects of this type may be useful for inventory
+           purposes or for automatically detecting
+           incompatibilities or version mismatches between
+           various hardware and software components on a system.
+
+           For example, the product ID for the ACME 4860 66MHz
+           clock doubled processor might be:
+           enterprises.acme.acmeProcessors.a4860DX2.MHz66
+
+           A software product might be registered as:
+           enterprises.acme.acmeOperatingSystems.acmeDOS.six(6).one(1)
+           "
+       SYNTAX OBJECT IDENTIFIER
+
+   -- unknownProduct will be used for any unknown ProductID
+   -- unknownProduct OBJECT IDENTIFIER ::= { 0 0 }
+
+   InternationalDisplayString ::= TEXTUAL-CONVENTION
+       STATUS current
+       DESCRIPTION
+           "This data type is used to model textual information
+           in some character set.  A network management station
+           should use a local algorithm to determine which
+           character set is in use and how it should be
+           displayed.  Note that this character set may be
+           encoded with more than one octet per symbol, but will
+           most often be NVT ASCII. When a size clause is
+           specified for an object of this type, the size refers
+           to the length in octets, not the number of symbols."
+       SYNTAX OCTET STRING
+
+   -- The Host Resources System Group
+
+   hrSystemUptime OBJECT-TYPE
+       SYNTAX     TimeTicks
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+
+
+
+Waldbusser & Grillo         Standards Track                     [Page 7]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+           "The amount of time since this host was last
+           initialized.  Note that this is different from
+           sysUpTime in the SNMPv2-MIB [RFC1907] because
+           sysUpTime is the uptime of the network management
+           portion of the system."
+       ::= { hrSystem 1 }
+
+   hrSystemDate OBJECT-TYPE
+       SYNTAX     DateAndTime
+       MAX-ACCESS read-write
+       STATUS     current
+       DESCRIPTION
+           "The host's notion of the local date and time of day."
+       ::= { hrSystem 2 }
+
+   hrSystemInitialLoadDevice OBJECT-TYPE
+       SYNTAX     Integer32 (1..2147483647)
+       MAX-ACCESS read-write
+       STATUS     current
+       DESCRIPTION
+           "The index of the hrDeviceEntry for the device from
+           which this host is configured to load its initial
+           operating system configuration (i.e., which operating
+           system code and/or boot parameters).
+
+           Note that writing to this object just changes the
+           configuration that will be used the next time the
+           operating system is loaded and does not actually cause
+           the reload to occur."
+       ::= { hrSystem 3 }
+
+   hrSystemInitialLoadParameters OBJECT-TYPE
+       SYNTAX     InternationalDisplayString (SIZE (0..128))
+       MAX-ACCESS read-write
+       STATUS     current
+       DESCRIPTION
+           "This object contains the parameters (e.g. a pathname
+           and parameter) supplied to the load device when
+           requesting the initial operating system configuration
+           from that device.
+
+        Note that writing to this object just changes the
+        configuration that will be used the next time the
+        operating system is loaded and does not actually cause
+        the reload to occur."
+       ::= { hrSystem 4 }
+
+   hrSystemNumUsers OBJECT-TYPE
+
+
+
+Waldbusser & Grillo         Standards Track                     [Page 8]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+       SYNTAX     Gauge32
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The number of user sessions for which this host is
+           storing state information.  A session is a collection
+           of processes requiring a single act of user
+           authentication and possibly subject to collective job
+           control."
+       ::= { hrSystem 5 }
+
+   hrSystemProcesses OBJECT-TYPE
+       SYNTAX     Gauge32
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The number of process contexts currently loaded or
+           running on this system."
+       ::= { hrSystem 6 }
+
+   hrSystemMaxProcesses OBJECT-TYPE
+       SYNTAX     Integer32 (0..2147483647)
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The maximum number of process contexts this system
+           can support.  If there is no fixed maximum, the value
+           should be zero.  On systems that have a fixed maximum,
+           this object can help diagnose failures that occur when
+           this maximum is reached."
+       ::= { hrSystem 7 }
+
+   -- The Host Resources Storage Group
+
+   -- Registration point for storage types, for use with hrStorageType.
+   -- These are defined in the HOST-RESOURCES-TYPES module.
+   hrStorageTypes          OBJECT IDENTIFIER ::= { hrStorage 1 }
+
+   hrMemorySize OBJECT-TYPE
+       SYNTAX     KBytes
+       UNITS      "KBytes"
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The amount of physical read-write main memory,
+           typically RAM, contained by the host."
+       ::= { hrStorage 2 }
+
+
+
+
+Waldbusser & Grillo         Standards Track                     [Page 9]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+   hrStorageTable OBJECT-TYPE
+       SYNTAX     SEQUENCE OF HrStorageEntry
+       MAX-ACCESS not-accessible
+       STATUS     current
+       DESCRIPTION
+           "The (conceptual) table of logical storage areas on
+           the host.
+
+           An entry shall be placed in the storage table for each
+           logical area of storage that is allocated and has
+           fixed resource limits.  The amount of storage
+           represented in an entity is the amount actually usable
+           by the requesting entity, and excludes loss due to
+           formatting or file system reference information.
+
+           These entries are associated with logical storage
+           areas, as might be seen by an application, rather than
+           physical storage entities which are typically seen by
+           an operating system.  Storage such as tapes and
+           floppies without file systems on them are typically
+           not allocated in chunks by the operating system to
+           requesting applications, and therefore shouldn't
+           appear in this table.  Examples of valid storage for
+           this table include disk partitions, file systems, ram
+           (for some architectures this is further segmented into
+           regular memory, extended memory, and so on), backing
+           store for virtual memory (`swap space').
+
+           This table is intended to be a useful diagnostic for
+           `out of memory' and `out of buffers' types of
+           failures.  In addition, it can be a useful performance
+           monitoring tool for tracking memory, disk, or buffer
+           usage."
+       ::= { hrStorage 3 }
+
+   hrStorageEntry OBJECT-TYPE
+       SYNTAX     HrStorageEntry
+       MAX-ACCESS not-accessible
+       STATUS     current
+       DESCRIPTION
+           "A (conceptual) entry for one logical storage area on
+           the host.  As an example, an instance of the
+           hrStorageType object might be named hrStorageType.3"
+       INDEX { hrStorageIndex }
+       ::= { hrStorageTable 1 }
+
+   HrStorageEntry ::= SEQUENCE {
+           hrStorageIndex               Integer32,
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 10]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+           hrStorageType                AutonomousType,
+           hrStorageDescr               DisplayString,
+           hrStorageAllocationUnits     Integer32,
+           hrStorageSize                Integer32,
+           hrStorageUsed                Integer32,
+           hrStorageAllocationFailures  Counter32
+       }
+
+   hrStorageIndex OBJECT-TYPE
+       SYNTAX     Integer32 (1..2147483647)
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "A unique value for each logical storage area
+           contained by the host."
+       ::= { hrStorageEntry 1 }
+
+   hrStorageType OBJECT-TYPE
+       SYNTAX     AutonomousType
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The type of storage represented by this entry."
+       ::= { hrStorageEntry 2 }
+
+   hrStorageDescr OBJECT-TYPE
+       SYNTAX     DisplayString
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "A description of the type and instance of the storage
+           described by this entry."
+       ::= { hrStorageEntry 3 }
+
+   hrStorageAllocationUnits OBJECT-TYPE
+       SYNTAX     Integer32 (1..2147483647)
+       UNITS      "Bytes"
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The size, in bytes, of the data objects allocated
+           from this pool.  If this entry is monitoring sectors,
+           blocks, buffers, or packets, for example, this number
+           will commonly be greater than one.  Otherwise this
+           number will typically be one."
+       ::= { hrStorageEntry 4 }
+
+   hrStorageSize OBJECT-TYPE
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 11]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+       SYNTAX     Integer32 (0..2147483647)
+       MAX-ACCESS read-write
+       STATUS     current
+       DESCRIPTION
+           "The size of the storage represented by this entry, in
+           units of hrStorageAllocationUnits. This object is
+           writable to allow remote configuration of the size of
+           the storage area in those cases where such an
+           operation makes sense and is possible on the
+           underlying system. For example, the amount of main
+           memory allocated to a buffer pool might be modified or
+           the amount of disk space allocated to virtual memory
+           might be modified."
+       ::= { hrStorageEntry 5 }
+
+   hrStorageUsed OBJECT-TYPE
+       SYNTAX     Integer32 (0..2147483647)
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The amount of the storage represented by this entry
+           that is allocated, in units of
+           hrStorageAllocationUnits."
+       ::= { hrStorageEntry 6 }
+
+   hrStorageAllocationFailures OBJECT-TYPE
+       SYNTAX     Counter32
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The number of requests for storage represented by
+           this entry that could not be honored due to not enough
+           storage.  It should be noted that as this object has a
+           SYNTAX of Counter32, that it does not have a defined
+           initial value.  However, it is recommended that this
+           object be initialized to zero, even though management
+           stations must not depend on such an initialization."
+       ::= { hrStorageEntry 7 }
+
+   -- The Host Resources Device Group
+   --
+   -- The device group is useful for identifying and diagnosing the
+   -- devices on a system.  The hrDeviceTable contains common
+   -- information for any type of device.  In addition, some devices
+   -- have device-specific tables for more detailed information.  More
+   -- such tables may be defined in the future for other device types.
+
+   -- Registration point for device types, for use with hrDeviceType.
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 12]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+   -- These are defined in the HOST-RESOURCES-TYPES module.
+   hrDeviceTypes             OBJECT IDENTIFIER ::= { hrDevice 1 }
+
+   hrDeviceTable OBJECT-TYPE
+       SYNTAX     SEQUENCE OF HrDeviceEntry
+       MAX-ACCESS not-accessible
+       STATUS     current
+       DESCRIPTION
+           "The (conceptual) table of devices contained by the
+           host."
+       ::= { hrDevice 2 }
+
+   hrDeviceEntry OBJECT-TYPE
+       SYNTAX     HrDeviceEntry
+       MAX-ACCESS not-accessible
+       STATUS     current
+       DESCRIPTION
+           "A (conceptual) entry for one device contained by the
+           host.  As an example, an instance of the hrDeviceType
+           object might be named hrDeviceType.3"
+       INDEX { hrDeviceIndex }
+       ::= { hrDeviceTable 1 }
+
+   HrDeviceEntry ::= SEQUENCE {
+           hrDeviceIndex           Integer32,
+           hrDeviceType            AutonomousType,
+           hrDeviceDescr           DisplayString,
+           hrDeviceID              ProductID,
+           hrDeviceStatus          INTEGER,
+           hrDeviceErrors          Counter32
+       }
+
+   hrDeviceIndex OBJECT-TYPE
+       SYNTAX     Integer32 (1..2147483647)
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "A unique value for each device contained by the host.
+           The value for each device must remain constant at
+           least from one re-initialization of the agent to the
+           next re-initialization."
+       ::= { hrDeviceEntry 1 }
+
+   hrDeviceType OBJECT-TYPE
+       SYNTAX     AutonomousType
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 13]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+           "An indication of the type of device.
+
+           If this value is
+           `hrDeviceProcessor { hrDeviceTypes 3 }' then an entry
+           exists in the hrProcessorTable which corresponds to
+           this device.
+
+           If this value is
+           `hrDeviceNetwork { hrDeviceTypes 4 }', then an entry
+           exists in the hrNetworkTable which corresponds to this
+           device.
+
+           If this value is
+           `hrDevicePrinter { hrDeviceTypes 5 }', then an entry
+           exists in the hrPrinterTable which corresponds to this
+           device.
+
+           If this value is
+           `hrDeviceDiskStorage { hrDeviceTypes 6 }', then an
+           entry exists in the hrDiskStorageTable which
+           corresponds to this device."
+       ::= { hrDeviceEntry 2 }
+
+   hrDeviceDescr OBJECT-TYPE
+       SYNTAX     DisplayString (SIZE (0..64))
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "A textual description of this device, including the
+           device's manufacturer and revision, and optionally,
+           its serial number."
+       ::= { hrDeviceEntry 3 }
+
+   hrDeviceID OBJECT-TYPE
+       SYNTAX     ProductID
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The product ID for this device."
+       ::= { hrDeviceEntry 4 }
+
+   hrDeviceStatus OBJECT-TYPE
+       SYNTAX     INTEGER {
+                      unknown(1),
+                      running(2),
+                      warning(3),
+                      testing(4),
+                      down(5)
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 14]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+                  }
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The current operational state of the device described
+           by this row of the table.  A value unknown(1)
+           indicates that the current state of the device is
+           unknown.  running(2) indicates that the device is up
+           and running and that no unusual error conditions are
+           known.  The warning(3) state indicates that agent has
+           been informed of an unusual error condition by the
+           operational software (e.g., a disk device driver) but
+           that the device is still 'operational'.  An example
+           would be a high number of soft errors on a disk.  A
+           value of testing(4), indicates that the device is not
+           available for use because it is in the testing state.
+           The state of down(5) is used only when the agent has
+           been informed that the device is not available for any
+           use."
+       ::= { hrDeviceEntry 5 }
+
+   hrDeviceErrors OBJECT-TYPE
+       SYNTAX     Counter32
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The number of errors detected on this device.  It
+           should be noted that as this object has a SYNTAX of
+           Counter32, that it does not have a defined initial
+           value.  However, it is recommended that this object be
+           initialized to zero, even though management stations
+           must not depend on such an initialization."
+       ::= { hrDeviceEntry 6 }
+
+   hrProcessorTable OBJECT-TYPE
+       SYNTAX     SEQUENCE OF HrProcessorEntry
+       MAX-ACCESS not-accessible
+       STATUS     current
+       DESCRIPTION
+           "The (conceptual) table of processors contained by the
+           host.
+
+           Note that this table is potentially sparse: a
+           (conceptual) entry exists only if the correspondent
+           value of the hrDeviceType object is
+           `hrDeviceProcessor'."
+       ::= { hrDevice 3 }
+
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 15]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+   hrProcessorEntry OBJECT-TYPE
+       SYNTAX     HrProcessorEntry
+       MAX-ACCESS not-accessible
+       STATUS     current
+       DESCRIPTION
+           "A (conceptual) entry for one processor contained by
+           the host.  The hrDeviceIndex in the index represents
+           the entry in the hrDeviceTable that corresponds to the
+           hrProcessorEntry.
+
+           As an example of how objects in this table are named,
+           an instance of the hrProcessorFrwID object might be
+           named hrProcessorFrwID.3"
+       INDEX { hrDeviceIndex }
+       ::= { hrProcessorTable 1 }
+
+   HrProcessorEntry ::= SEQUENCE {
+           hrProcessorFrwID            ProductID,
+           hrProcessorLoad             Integer32
+       }
+
+   hrProcessorFrwID OBJECT-TYPE
+       SYNTAX     ProductID
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The product ID of the firmware associated with the
+           processor."
+       ::= { hrProcessorEntry 1 }
+
+   hrProcessorLoad OBJECT-TYPE
+       SYNTAX     Integer32 (0..100)
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The average, over the last minute, of the percentage
+           of time that this processor was not idle.
+           Implementations may approximate this one minute
+           smoothing period if necessary."
+       ::= { hrProcessorEntry 2 }
+
+   hrNetworkTable OBJECT-TYPE
+       SYNTAX     SEQUENCE OF HrNetworkEntry
+       MAX-ACCESS not-accessible
+       STATUS     current
+       DESCRIPTION
+           "The (conceptual) table of network devices contained
+           by the host.
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 16]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+           Note that this table is potentially sparse: a
+           (conceptual) entry exists only if the correspondent
+           value of the hrDeviceType object is
+           `hrDeviceNetwork'."
+       ::= { hrDevice 4 }
+
+   hrNetworkEntry OBJECT-TYPE
+       SYNTAX     HrNetworkEntry
+       MAX-ACCESS not-accessible
+       STATUS     current
+       DESCRIPTION
+           "A (conceptual) entry for one network device contained
+           by the host.  The hrDeviceIndex in the index
+           represents the entry in the hrDeviceTable that
+           corresponds to the hrNetworkEntry.
+
+           As an example of how objects in this table are named,
+           an instance of the hrNetworkIfIndex object might be
+           named hrNetworkIfIndex.3"
+       INDEX { hrDeviceIndex }
+       ::= { hrNetworkTable 1 }
+
+   HrNetworkEntry ::= SEQUENCE {
+           hrNetworkIfIndex    InterfaceIndexOrZero
+       }
+
+   hrNetworkIfIndex OBJECT-TYPE
+       SYNTAX     InterfaceIndexOrZero
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The value of ifIndex which corresponds to this
+           network device. If this device is not represented in
+           the ifTable, then this value shall be zero."
+       ::= { hrNetworkEntry 1 }
+
+   hrPrinterTable OBJECT-TYPE
+       SYNTAX     SEQUENCE OF HrPrinterEntry
+       MAX-ACCESS not-accessible
+       STATUS     current
+       DESCRIPTION
+           "The (conceptual) table of printers local to the host.
+
+           Note that this table is potentially sparse: a
+           (conceptual) entry exists only if the correspondent
+           value of the hrDeviceType object is
+           `hrDevicePrinter'."
+       ::= { hrDevice 5 }
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 17]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+   hrPrinterEntry OBJECT-TYPE
+       SYNTAX     HrPrinterEntry
+       MAX-ACCESS not-accessible
+       STATUS     current
+       DESCRIPTION
+           "A (conceptual) entry for one printer local to the
+           host.  The hrDeviceIndex in the index represents the
+           entry in the hrDeviceTable that corresponds to the
+           hrPrinterEntry.
+
+           As an example of how objects in this table are named,
+           an instance of the hrPrinterStatus object might be
+           named hrPrinterStatus.3"
+       INDEX { hrDeviceIndex }
+       ::= { hrPrinterTable 1 }
+
+   HrPrinterEntry ::= SEQUENCE {
+           hrPrinterStatus             INTEGER,
+           hrPrinterDetectedErrorState OCTET STRING
+       }
+
+   hrPrinterStatus OBJECT-TYPE
+       SYNTAX     INTEGER {
+                      other(1),
+                      unknown(2),
+                      idle(3),
+                      printing(4),
+                      warmup(5)
+                  }
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The current status of this printer device."
+       ::= { hrPrinterEntry 1 }
+
+   hrPrinterDetectedErrorState OBJECT-TYPE
+       SYNTAX     OCTET STRING
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "This object represents any error conditions detected
+           by the printer.  The error conditions are encoded as
+           bits in an octet string, with the following
+           definitions:
+
+                Condition         Bit #
+
+                lowPaper              0
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 18]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+                noPaper               1
+                lowToner              2
+                noToner               3
+                doorOpen              4
+                jammed                5
+                offline               6
+                serviceRequested      7
+                inputTrayMissing      8
+                outputTrayMissing     9
+                markerSupplyMissing  10
+                outputNearFull       11
+                outputFull           12
+                inputTrayEmpty       13
+                overduePreventMaint  14
+
+           Bits are numbered starting with the most significant
+           bit of the first byte being bit 0, the least
+           significant bit of the first byte being bit 7, the
+           most significant bit of the second byte being bit 8,
+           and so on.  A one bit encodes that the condition was
+           detected, while a zero bit encodes that the condition
+           was not detected.
+
+           This object is useful for alerting an operator to
+           specific warning or error conditions that may occur,
+           especially those requiring human intervention."
+       ::= { hrPrinterEntry 2 }
+
+   hrDiskStorageTable OBJECT-TYPE
+       SYNTAX     SEQUENCE OF HrDiskStorageEntry
+       MAX-ACCESS not-accessible
+       STATUS     current
+       DESCRIPTION
+           "The (conceptual) table of long-term storage devices
+           contained by the host.  In particular, disk devices
+           accessed remotely over a network are not included
+           here.
+
+           Note that this table is potentially sparse: a
+           (conceptual) entry exists only if the correspondent
+           value of the hrDeviceType object is
+           `hrDeviceDiskStorage'."
+       ::= { hrDevice 6 }
+
+   hrDiskStorageEntry OBJECT-TYPE
+       SYNTAX     HrDiskStorageEntry
+       MAX-ACCESS not-accessible
+       STATUS     current
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 19]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+       DESCRIPTION
+           "A (conceptual) entry for one long-term storage device
+           contained by the host.  The hrDeviceIndex in the index
+           represents the entry in the hrDeviceTable that
+           corresponds to the hrDiskStorageEntry. As an example,
+           an instance of the hrDiskStorageCapacity object might
+           be named hrDiskStorageCapacity.3"
+       INDEX { hrDeviceIndex }
+       ::= { hrDiskStorageTable 1 }
+
+   HrDiskStorageEntry ::= SEQUENCE {
+           hrDiskStorageAccess         INTEGER,
+           hrDiskStorageMedia          INTEGER,
+           hrDiskStorageRemoveble      TruthValue,
+           hrDiskStorageCapacity       KBytes
+       }
+
+   hrDiskStorageAccess OBJECT-TYPE
+       SYNTAX     INTEGER {
+                      readWrite(1),
+                      readOnly(2)
+                  }
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "An indication if this long-term storage device is
+           readable and writable or only readable.  This should
+           reflect the media type, any write-protect mechanism,
+           and any device configuration that affects the entire
+           device."
+       ::= { hrDiskStorageEntry 1 }
+
+   hrDiskStorageMedia OBJECT-TYPE
+       SYNTAX     INTEGER {
+                      other(1),
+                      unknown(2),
+                      hardDisk(3),
+                      floppyDisk(4),
+                      opticalDiskROM(5),
+                      opticalDiskWORM(6),     -- Write Once Read Many
+                      opticalDiskRW(7),
+                      ramDisk(8)
+                  }
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "An indication of the type of media used in this long-
+           term storage device."
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 20]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+       ::= { hrDiskStorageEntry 2 }
+
+   hrDiskStorageRemoveble OBJECT-TYPE
+       SYNTAX     TruthValue
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "Denotes whether or not the disk media may be removed
+           from the drive."
+       ::= { hrDiskStorageEntry 3 }
+
+   hrDiskStorageCapacity OBJECT-TYPE
+       SYNTAX     KBytes
+       UNITS      "KBytes"
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The total size for this long-term storage device. If
+           the media is removable and is currently removed, this
+           value should be zero."
+       ::= { hrDiskStorageEntry 4 }
+
+   hrPartitionTable OBJECT-TYPE
+       SYNTAX     SEQUENCE OF HrPartitionEntry
+       MAX-ACCESS not-accessible
+       STATUS     current
+       DESCRIPTION
+           "The (conceptual) table of partitions for long-term
+           storage devices contained by the host.  In particular,
+           partitions accessed remotely over a network are not
+           included here."
+       ::= { hrDevice 7 }
+
+   hrPartitionEntry OBJECT-TYPE
+       SYNTAX     HrPartitionEntry
+       MAX-ACCESS not-accessible
+       STATUS     current
+       DESCRIPTION
+           "A (conceptual) entry for one partition.  The
+           hrDeviceIndex in the index represents the entry in the
+           hrDeviceTable that corresponds to the
+           hrPartitionEntry.
+
+           As an example of how objects in this table are named,
+           an instance of the hrPartitionSize object might be
+           named hrPartitionSize.3.1"
+       INDEX { hrDeviceIndex, hrPartitionIndex }
+       ::= { hrPartitionTable 1 }
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 21]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+   HrPartitionEntry ::= SEQUENCE {
+           hrPartitionIndex                Integer32,
+           hrPartitionLabel                InternationalDisplayString,
+           hrPartitionID                   OCTET STRING,
+           hrPartitionSize                 KBytes,
+           hrPartitionFSIndex              Integer32
+       }
+
+   hrPartitionIndex OBJECT-TYPE
+       SYNTAX     Integer32 (1..2147483647)
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "A unique value for each partition on this long-term
+           storage device.  The value for each long-term storage
+           device must remain constant at least from one re-
+           initialization of the agent to the next re-
+           initialization."
+       ::= { hrPartitionEntry 1 }
+
+   hrPartitionLabel OBJECT-TYPE
+       SYNTAX     InternationalDisplayString (SIZE (0..128))
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "A textual description of this partition."
+       ::= { hrPartitionEntry 2 }
+
+   hrPartitionID OBJECT-TYPE
+       SYNTAX     OCTET STRING
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "A descriptor which uniquely represents this partition
+           to the responsible operating system.  On some systems,
+           this might take on a binary representation."
+       ::= { hrPartitionEntry 3 }
+
+   hrPartitionSize OBJECT-TYPE
+       SYNTAX     KBytes
+       UNITS      "KBytes"
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The size of this partition."
+       ::= { hrPartitionEntry 4 }
+
+   hrPartitionFSIndex OBJECT-TYPE
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 22]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+       SYNTAX     Integer32 (0..2147483647)
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The index of the file system mounted on this
+           partition.  If no file system is mounted on this
+           partition, then this value shall be zero.  Note that
+           multiple partitions may point to one file system,
+           denoting that that file system resides on those
+           partitions.  Multiple file systems may not reside on
+           one partition."
+       ::= { hrPartitionEntry 5 }
+
+   -- The File System Table
+
+   -- Registration point for popular File System types,
+   -- for use with hrFSType. These are defined in the
+   -- HOST-RESOURCES-TYPES module.
+   hrFSTypes               OBJECT IDENTIFIER ::= { hrDevice 9 }
+
+   hrFSTable OBJECT-TYPE
+       SYNTAX     SEQUENCE OF HrFSEntry
+       MAX-ACCESS not-accessible
+       STATUS     current
+       DESCRIPTION
+           "The (conceptual) table of file systems local to this
+           host or remotely mounted from a file server.  File
+           systems that are in only one user's environment on a
+           multi-user system will not be included in this table."
+       ::= { hrDevice 8 }
+
+   hrFSEntry OBJECT-TYPE
+       SYNTAX     HrFSEntry
+       MAX-ACCESS not-accessible
+       STATUS     current
+       DESCRIPTION
+           "A (conceptual) entry for one file system local to
+           this host or remotely mounted from a file server.
+           File systems that are in only one user's environment
+           on a multi-user system will not be included in this
+           table.
+
+           As an example of how objects in this table are named,
+           an instance of the hrFSMountPoint object might be
+           named hrFSMountPoint.3"
+       INDEX { hrFSIndex }
+       ::= { hrFSTable 1 }
+
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 23]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+   HrFSEntry ::= SEQUENCE {
+           hrFSIndex                   Integer32,
+           hrFSMountPoint              InternationalDisplayString,
+           hrFSRemoteMountPoint        InternationalDisplayString,
+           hrFSType                    AutonomousType,
+           hrFSAccess                  INTEGER,
+           hrFSBootable                TruthValue,
+           hrFSStorageIndex            Integer32,
+           hrFSLastFullBackupDate      DateAndTime,
+           hrFSLastPartialBackupDate   DateAndTime
+       }
+
+   hrFSIndex OBJECT-TYPE
+       SYNTAX     Integer32 (1..2147483647)
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "A unique value for each file system local to this
+           host.  The value for each file system must remain
+           constant at least from one re-initialization of the
+           agent to the next re-initialization."
+       ::= { hrFSEntry 1 }
+
+   hrFSMountPoint OBJECT-TYPE
+       SYNTAX     InternationalDisplayString (SIZE(0..128))
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The path name of the root of this file system."
+       ::= { hrFSEntry 2 }
+
+   hrFSRemoteMountPoint OBJECT-TYPE
+       SYNTAX     InternationalDisplayString (SIZE(0..128))
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "A description of the name and/or address of the
+           server that this file system is mounted from.  This
+           may also include parameters such as the mount point on
+           the remote file system.  If this is not a remote file
+           system, this string should have a length of zero."
+       ::= { hrFSEntry 3 }
+
+   hrFSType OBJECT-TYPE
+       SYNTAX     AutonomousType
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 24]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+           "The value of this object identifies the type of this
+           file system."
+       ::= { hrFSEntry 4 }
+
+   hrFSAccess OBJECT-TYPE
+       SYNTAX     INTEGER {
+                      readWrite(1),
+                      readOnly(2)
+                  }
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "An indication if this file system is logically
+           configured by the operating system to be readable and
+           writable or only readable.  This does not represent
+           any local access-control policy, except one that is
+           applied to the file system as a whole."
+       ::= { hrFSEntry 5 }
+
+   hrFSBootable OBJECT-TYPE
+       SYNTAX     TruthValue
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "A flag indicating whether this file system is
+           bootable."
+       ::= { hrFSEntry 6 }
+
+   hrFSStorageIndex OBJECT-TYPE
+       SYNTAX     Integer32 (0..2147483647)
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The index of the hrStorageEntry that represents
+           information about this file system.  If there is no
+           such information available, then this value shall be
+           zero.  The relevant storage entry will be useful in
+           tracking the percent usage of this file system and
+           diagnosing errors that may occur when it runs out of
+           space."
+       ::= { hrFSEntry 7 }
+
+   hrFSLastFullBackupDate OBJECT-TYPE
+       SYNTAX     DateAndTime
+       MAX-ACCESS read-write
+       STATUS     current
+       DESCRIPTION
+           "The last date at which this complete file system was
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 25]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+           copied to another storage device for backup.  This
+           information is useful for ensuring that backups are
+           being performed regularly.
+
+           If this information is not known, then this variable
+           shall have the value corresponding to January 1, year
+           0000, 00:00:00.0, which is encoded as
+           (hex)'00 00 01 01 00 00 00 00'."
+       ::= { hrFSEntry 8 }
+
+   hrFSLastPartialBackupDate OBJECT-TYPE
+       SYNTAX     DateAndTime
+       MAX-ACCESS read-write
+       STATUS     current
+       DESCRIPTION
+           "The last date at which a portion of this file system
+           was copied to another storage device for backup.  This
+           information is useful for ensuring that backups are
+           being performed regularly.
+
+           If this information is not known, then this variable
+           shall have the value corresponding to January 1, year
+           0000, 00:00:00.0, which is encoded as
+           (hex)'00 00 01 01 00 00 00 00'."
+       ::= { hrFSEntry 9 }
+
+   -- The Host Resources Running Software Group
+   --
+   -- The hrSWRunTable contains an entry for each distinct piece of
+   -- software that is running or loaded into physical or virtual
+   -- memory in preparation for running.  This includes the host's
+   -- operating system, device drivers, and applications.
+
+   hrSWOSIndex OBJECT-TYPE
+       SYNTAX     Integer32 (1..2147483647)
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The value of the hrSWRunIndex for the hrSWRunEntry
+           that represents the primary operating system running
+           on this host.  This object is useful for quickly and
+           uniquely identifying that primary operating system."
+       ::= { hrSWRun 1 }
+
+   hrSWRunTable OBJECT-TYPE
+       SYNTAX     SEQUENCE OF HrSWRunEntry
+       MAX-ACCESS not-accessible
+       STATUS     current
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 26]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+       DESCRIPTION
+           "The (conceptual) table of software running on the
+           host."
+       ::= { hrSWRun 2 }
+
+   hrSWRunEntry OBJECT-TYPE
+       SYNTAX     HrSWRunEntry
+       MAX-ACCESS not-accessible
+       STATUS     current
+       DESCRIPTION
+           "A (conceptual) entry for one piece of software
+           running on the host Note that because the installed
+           software table only contains information for software
+           stored locally on this host, not every piece of
+           running software will be found in the installed
+           software table.  This is true of software that was
+           loaded and run from a non-local source, such as a
+           network-mounted file system.
+
+           As an example of how objects in this table are named,
+           an instance of the hrSWRunName object might be named
+           hrSWRunName.1287"
+       INDEX { hrSWRunIndex }
+       ::= { hrSWRunTable 1 }
+
+   HrSWRunEntry ::= SEQUENCE {
+           hrSWRunIndex       Integer32,
+           hrSWRunName        InternationalDisplayString,
+           hrSWRunID          ProductID,
+           hrSWRunPath        InternationalDisplayString,
+           hrSWRunParameters  InternationalDisplayString,
+           hrSWRunType        INTEGER,
+           hrSWRunStatus      INTEGER
+       }
+
+   hrSWRunIndex OBJECT-TYPE
+       SYNTAX     Integer32 (1..2147483647)
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "A unique value for each piece of software running on
+           the host.  Wherever possible, this should be the
+           system's native, unique identification number."
+       ::= { hrSWRunEntry 1 }
+
+   hrSWRunName OBJECT-TYPE
+       SYNTAX     InternationalDisplayString (SIZE (0..64))
+       MAX-ACCESS read-only
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 27]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+       STATUS     current
+       DESCRIPTION
+           "A textual description of this running piece of
+           software, including the manufacturer, revision,  and
+           the name by which it is commonly known.  If this
+           software was installed locally, this should be the
+           same string as used in the corresponding
+           hrSWInstalledName."
+       ::= { hrSWRunEntry 2 }
+
+   hrSWRunID OBJECT-TYPE
+       SYNTAX     ProductID
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The product ID of this running piece of software."
+       ::= { hrSWRunEntry 3 }
+
+   hrSWRunPath OBJECT-TYPE
+       SYNTAX     InternationalDisplayString (SIZE(0..128))
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "A description of the location on long-term storage
+           (e.g. a disk drive) from which this software was
+           loaded."
+       ::= { hrSWRunEntry 4 }
+
+   hrSWRunParameters OBJECT-TYPE
+       SYNTAX     InternationalDisplayString (SIZE(0..128))
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "A description of the parameters supplied to this
+           software when it was initially loaded."
+       ::= { hrSWRunEntry 5 }
+
+   hrSWRunType OBJECT-TYPE
+       SYNTAX     INTEGER {
+                      unknown(1),
+                      operatingSystem(2),
+                      deviceDriver(3),
+                      application(4)
+                  }
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The type of this software."
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 28]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+       ::= { hrSWRunEntry 6 }
+
+   hrSWRunStatus OBJECT-TYPE
+       SYNTAX     INTEGER {
+                      running(1),
+                      runnable(2),    -- waiting for resource
+                                      -- (i.e., CPU, memory, IO)
+                      notRunnable(3), -- loaded but waiting for event
+                      invalid(4)      -- not loaded
+                  }
+       MAX-ACCESS read-write
+       STATUS     current
+       DESCRIPTION
+           "The status of this running piece of software.
+           Setting this value to invalid(4) shall cause this
+           software to stop running and to be unloaded. Sets to
+           other values are not valid."
+       ::= { hrSWRunEntry 7 }
+
+   -- The Host Resources Running Software Performance Group
+   --
+   -- The hrSWRunPerfTable contains an entry corresponding to
+   -- each entry in the hrSWRunTable.
+
+   hrSWRunPerfTable OBJECT-TYPE
+       SYNTAX     SEQUENCE OF HrSWRunPerfEntry
+       MAX-ACCESS not-accessible
+       STATUS     current
+       DESCRIPTION
+           "The (conceptual) table of running software
+           performance metrics."
+       ::= { hrSWRunPerf 1 }
+
+   hrSWRunPerfEntry OBJECT-TYPE
+       SYNTAX     HrSWRunPerfEntry
+       MAX-ACCESS not-accessible
+       STATUS     current
+       DESCRIPTION
+           "A (conceptual) entry containing software performance
+           metrics.  As an example, an instance of the
+           hrSWRunPerfCPU object might be named
+           hrSWRunPerfCPU.1287"
+       AUGMENTS { hrSWRunEntry }  -- This table augments information in
+                                  -- the hrSWRunTable.
+       ::= { hrSWRunPerfTable 1 }
+
+   HrSWRunPerfEntry ::= SEQUENCE {
+           hrSWRunPerfCPU          Integer32,
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 29]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+           hrSWRunPerfMem          KBytes
+   }
+
+   hrSWRunPerfCPU OBJECT-TYPE
+       SYNTAX     Integer32 (0..2147483647)
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The number of centi-seconds of the total system's CPU
+           resources consumed by this process.  Note that on a
+           multi-processor system, this value may increment by
+           more than one centi-second in one centi-second of real
+           (wall clock) time."
+       ::= { hrSWRunPerfEntry 1 }
+
+   hrSWRunPerfMem OBJECT-TYPE
+       SYNTAX     KBytes
+       UNITS      "KBytes"
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The total amount of real system memory allocated to
+           this process."
+       ::= { hrSWRunPerfEntry 2 }
+
+   -- The Host Resources Installed Software Group
+   --
+   -- The hrSWInstalledTable contains an entry for each piece
+   -- of software installed in long-term storage (e.g. a disk
+   -- drive) locally on this host.  Note that this does not
+   -- include software loadable remotely from a network
+   -- server.
+   --
+   -- Different implementations may track software in varying
+   -- ways. For example, while some implementations may track
+   -- executable files as distinct pieces of software, other
+   -- implementations may use other strategies such as keeping
+   -- track of software "packages" (e.g., related groups of files)
+   -- or keeping track of system or application "patches".
+   --
+   -- This table is useful for identifying and inventorying
+   -- software on a host and for diagnosing incompatibility
+   -- and version mismatch problems between various pieces
+   -- of hardware and software.
+
+   hrSWInstalledLastChange OBJECT-TYPE
+       SYNTAX     TimeTicks
+       MAX-ACCESS read-only
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 30]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+       STATUS     current
+       DESCRIPTION
+           "The value of sysUpTime when an entry in the
+           hrSWInstalledTable was last added, renamed, or
+           deleted.  Because this table is likely to contain many
+           entries, polling of this object allows a management
+           station to determine when re-downloading of the table
+           might be useful."
+       ::= { hrSWInstalled 1 }
+
+   hrSWInstalledLastUpdateTime OBJECT-TYPE
+       SYNTAX     TimeTicks
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The value of sysUpTime when the hrSWInstalledTable
+           was last completely updated.  Because caching of this
+           data will be a popular implementation strategy,
+           retrieval of this object allows a management station
+           to obtain a guarantee that no data in this table is
+           older than the indicated time."
+       ::= { hrSWInstalled 2 }
+
+   hrSWInstalledTable OBJECT-TYPE
+       SYNTAX     SEQUENCE OF HrSWInstalledEntry
+       MAX-ACCESS not-accessible
+       STATUS     current
+       DESCRIPTION
+           "The (conceptual) table of software installed on this
+           host."
+       ::= { hrSWInstalled 3 }
+
+   hrSWInstalledEntry OBJECT-TYPE
+       SYNTAX     HrSWInstalledEntry
+       MAX-ACCESS not-accessible
+       STATUS     current
+       DESCRIPTION
+           "A (conceptual) entry for a piece of software
+           installed on this host.
+
+           As an example of how objects in this table are named,
+           an instance of the hrSWInstalledName object might be
+           named hrSWInstalledName.96"
+       INDEX { hrSWInstalledIndex }
+       ::= { hrSWInstalledTable 1 }
+
+   HrSWInstalledEntry ::= SEQUENCE {
+           hrSWInstalledIndex       Integer32,
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 31]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+           hrSWInstalledName        InternationalDisplayString,
+           hrSWInstalledID          ProductID,
+           hrSWInstalledType        INTEGER,
+           hrSWInstalledDate        DateAndTime
+   }
+
+   hrSWInstalledIndex OBJECT-TYPE
+       SYNTAX     Integer32 (1..2147483647)
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "A unique value for each piece of software installed
+           on the host.  This value shall be in the range from 1
+           to the number of pieces of software installed on the
+           host."
+       ::= { hrSWInstalledEntry 1 }
+
+   hrSWInstalledName OBJECT-TYPE
+       SYNTAX     InternationalDisplayString (SIZE (0..64))
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "A textual description of this installed piece of
+           software, including the manufacturer, revision, the
+           name by which it is commonly known, and optionally,
+           its serial number."
+       ::= { hrSWInstalledEntry 2 }
+
+   hrSWInstalledID OBJECT-TYPE
+       SYNTAX     ProductID
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The product ID of this installed piece of software."
+       ::= { hrSWInstalledEntry 3 }
+
+   hrSWInstalledType OBJECT-TYPE
+       SYNTAX     INTEGER {
+                      unknown(1),
+                      operatingSystem(2),
+                      deviceDriver(3),
+                      application(4)
+                  }
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The type of this software."
+       ::= { hrSWInstalledEntry 4 }
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 32]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+   hrSWInstalledDate OBJECT-TYPE
+       SYNTAX     DateAndTime
+       MAX-ACCESS read-only
+       STATUS     current
+       DESCRIPTION
+           "The last-modification date of this application as it
+           would appear in a directory listing.
+
+           If this information is not known, then this variable
+           shall have the value corresponding to January 1, year
+           0000, 00:00:00.0, which is encoded as
+           (hex)'00 00 01 01 00 00 00 00'."
+       ::= { hrSWInstalledEntry 5 }
+
+   -- Conformance information
+
+   hrMIBCompliances OBJECT IDENTIFIER ::= { hrMIBAdminInfo 2 }
+   hrMIBGroups      OBJECT IDENTIFIER ::= { hrMIBAdminInfo 3 }
+
+   -- Compliance Statements
+   hrMIBCompliance MODULE-COMPLIANCE
+       STATUS current
+       DESCRIPTION
+           "The requirements for conformance to the Host Resources MIB."
+       MODULE -- this module
+         MANDATORY-GROUPS { hrSystemGroup, hrStorageGroup,
+                            hrDeviceGroup }
+
+         OBJECT hrSystemDate
+             MIN-ACCESS read-only
+             DESCRIPTION
+                 "Write access is not required."
+
+         OBJECT hrSystemInitialLoadDevice
+             MIN-ACCESS read-only
+             DESCRIPTION
+                 "Write access is not required."
+
+         OBJECT hrSystemInitialLoadParameters
+             MIN-ACCESS read-only
+             DESCRIPTION
+                 "Write access is not required."
+
+         OBJECT hrStorageSize
+             MIN-ACCESS read-only
+             DESCRIPTION
+                 "Write access is not required."
+
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 33]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+         OBJECT hrFSLastFullBackupDate
+             MIN-ACCESS read-only
+             DESCRIPTION
+                 "Write access is not required."
+
+         OBJECT hrFSLastPartialBackupDate
+             MIN-ACCESS read-only
+             DESCRIPTION
+                 "Write access is not required."
+
+         GROUP hrSWRunGroup
+             DESCRIPTION
+                 "The Running Software Group. Implementation
+                 of this group is mandatory only when the
+                 hrSWRunPerfGroup is implemented."
+
+         OBJECT hrSWRunStatus
+             MIN-ACCESS read-only
+             DESCRIPTION
+                 "Write access is not required."
+
+         GROUP hrSWRunPerfGroup
+             DESCRIPTION
+                 "The Running Software Performance Group.
+                 Implementation of this group is at the discretion
+                 of the implementor."
+
+         GROUP hrSWInstalledGroup
+             DESCRIPTION
+                 "The Installed Software Group.
+                 Implementation of this group is at the discretion
+                 of the implementor."
+
+       ::= { hrMIBCompliances 1 }
+
+       hrSystemGroup OBJECT-GROUP
+           OBJECTS {
+               hrSystemUptime, hrSystemDate,
+               hrSystemInitialLoadDevice,
+               hrSystemInitialLoadParameters,
+               hrSystemNumUsers, hrSystemProcesses,
+               hrSystemMaxProcesses
+           }
+           STATUS current
+           DESCRIPTION
+               "The Host Resources System Group."
+           ::= { hrMIBGroups 1 }
+
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 34]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+       hrStorageGroup OBJECT-GROUP
+           OBJECTS {
+               hrMemorySize, hrStorageIndex, hrStorageType,
+               hrStorageDescr, hrStorageAllocationUnits,
+               hrStorageSize, hrStorageUsed,
+               hrStorageAllocationFailures
+           }
+           STATUS current
+           DESCRIPTION
+               "The Host Resources Storage Group."
+           ::= { hrMIBGroups 2 }
+
+       hrDeviceGroup OBJECT-GROUP
+           OBJECTS {
+               hrDeviceIndex, hrDeviceType, hrDeviceDescr,
+               hrDeviceID, hrDeviceStatus, hrDeviceErrors,
+               hrProcessorFrwID, hrProcessorLoad,
+               hrNetworkIfIndex, hrPrinterStatus,
+               hrPrinterDetectedErrorState,
+               hrDiskStorageAccess, hrDiskStorageMedia,
+               hrDiskStorageRemoveble, hrDiskStorageCapacity,
+               hrPartitionIndex, hrPartitionLabel,
+               hrPartitionID, hrPartitionSize,
+               hrPartitionFSIndex, hrFSIndex, hrFSMountPoint,
+               hrFSRemoteMountPoint, hrFSType, hrFSAccess,
+               hrFSBootable, hrFSStorageIndex,
+               hrFSLastFullBackupDate,
+               hrFSLastPartialBackupDate
+           }
+           STATUS current
+           DESCRIPTION
+               "The Host Resources Device Group."
+           ::= { hrMIBGroups 3 }
+
+       hrSWRunGroup OBJECT-GROUP
+           OBJECTS {
+               hrSWOSIndex, hrSWRunIndex, hrSWRunName,
+               hrSWRunID, hrSWRunPath, hrSWRunParameters,
+               hrSWRunType, hrSWRunStatus
+           }
+           STATUS current
+           DESCRIPTION
+               "The Host Resources Running Software Group."
+           ::= { hrMIBGroups 4 }
+
+       hrSWRunPerfGroup OBJECT-GROUP
+           OBJECTS { hrSWRunPerfCPU, hrSWRunPerfMem }
+           STATUS current
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 35]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+           DESCRIPTION
+               "The Host Resources Running Software
+               Performance Group."
+           ::= { hrMIBGroups 5 }
+
+       hrSWInstalledGroup OBJECT-GROUP
+           OBJECTS {
+               hrSWInstalledLastChange,
+               hrSWInstalledLastUpdateTime,
+               hrSWInstalledIndex, hrSWInstalledName,
+               hrSWInstalledID, hrSWInstalledType,
+               hrSWInstalledDate
+           }
+           STATUS current
+           DESCRIPTION
+               "The Host Resources Installed Software Group."
+           ::= { hrMIBGroups 6 }
+
+   END
+
+5.  Type Definitions
+
+   HOST-RESOURCES-TYPES DEFINITIONS ::= BEGIN
+
+   IMPORTS
+     MODULE-IDENTITY, OBJECT-IDENTITY        FROM SNMPv2-SMI
+     hrMIBAdminInfo, hrStorage, hrDevice     FROM HOST-RESOURCES-MIB;
+
+   hostResourcesTypesModule MODULE-IDENTITY
+     LAST-UPDATED "200003060000Z"    -- 6 March, 2000
+     ORGANIZATION "IETF Host Resources MIB Working Group"
+     CONTACT-INFO
+         "Steve Waldbusser
+         Postal: Lucent Technologies, Inc.
+                 1213 Innsbruck Dr.
+                 Sunnyvale, CA 94089
+                 USA
+         Phone: 650-318-1251
+         Fax:   650-318-1633
+         Email: waldbusser@ins.com
+
+         In addition, the Host Resources MIB mailing list is dedicated
+         to discussion of this MIB. To join the mailing list, send a
+         request message to hostmib-request@andrew.cmu.edu. The mailing
+         list address is hostmib@andrew.cmu.edu."
+     DESCRIPTION
+         "This MIB module registers type definitions for
+         storage types, device types, and file system types.
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 36]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+         After the initial revision, this module will be
+         maintained by IANA."
+     REVISION "200003060000Z"    -- 6 March 2000
+     DESCRIPTION
+         "The original version of this module, published as RFC
+         2790."
+     ::= { hrMIBAdminInfo 4 }
+
+   -- Registrations for some storage types, for use with hrStorageType
+   hrStorageTypes          OBJECT IDENTIFIER ::= { hrStorage 1 }
+
+   hrStorageOther OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The storage type identifier used when no other defined
+           type is appropriate."
+       ::= { hrStorageTypes 1 }
+
+   hrStorageRam OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The storage type identifier used for RAM."
+       ::= { hrStorageTypes 2 }
+
+   hrStorageVirtualMemory OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The storage type identifier used for virtual memory,
+           temporary storage of swapped or paged memory."
+       ::= { hrStorageTypes 3 }
+
+   hrStorageFixedDisk OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The storage type identifier used for non-removable
+           rigid rotating magnetic storage devices."
+       ::= { hrStorageTypes 4 }
+
+   hrStorageRemovableDisk OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The storage type identifier used for removable rigid
+           rotating magnetic storage devices."
+       ::= { hrStorageTypes 5 }
+
+   hrStorageFloppyDisk OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 37]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+           "The storage type identifier used for non-rigid rotating
+           magnetic storage devices."
+       ::= { hrStorageTypes 6 }
+
+   hrStorageCompactDisc OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The storage type identifier used for read-only rotating
+           optical storage devices."
+       ::= { hrStorageTypes 7 }
+
+   hrStorageRamDisk OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The storage type identifier used for a file system that
+           is stored in RAM."
+       ::= { hrStorageTypes 8 }
+
+   hrStorageFlashMemory OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The storage type identifier used for flash memory."
+       ::= { hrStorageTypes 9 }
+
+   hrStorageNetworkDisk OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The storage type identifier used for a
+           networked file system."
+       ::= { hrStorageTypes 10 }
+
+   -- Registrations for some device types, for use with hrDeviceType
+   hrDeviceTypes             OBJECT IDENTIFIER ::= { hrDevice 1 }
+
+   hrDeviceOther OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The device type identifier used when no other defined
+           type is appropriate."
+       ::= { hrDeviceTypes 1 }
+
+   hrDeviceUnknown OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The device type identifier used when the device type is
+           unknown."
+       ::= { hrDeviceTypes 2 }
+
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 38]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+   hrDeviceProcessor OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The device type identifier used for a CPU."
+       ::= { hrDeviceTypes 3 }
+
+   hrDeviceNetwork OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The device type identifier used for a network interface."
+       ::= { hrDeviceTypes 4 }
+
+   hrDevicePrinter OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The device type identifier used for a printer."
+       ::= { hrDeviceTypes 5 }
+
+   hrDeviceDiskStorage OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The device type identifier used for a disk drive."
+       ::= { hrDeviceTypes 6 }
+
+   hrDeviceVideo OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The device type identifier used for a video device."
+       ::= { hrDeviceTypes 10 }
+
+   hrDeviceAudio OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The device type identifier used for an audio device."
+       ::= { hrDeviceTypes 11 }
+
+   hrDeviceCoprocessor OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The device type identifier used for a co-processor."
+       ::= { hrDeviceTypes 12 }
+
+   hrDeviceKeyboard OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The device type identifier used for a keyboard device."
+       ::= { hrDeviceTypes 13 }
+
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 39]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+   hrDeviceModem OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The device type identifier used for a modem."
+       ::= { hrDeviceTypes 14 }
+
+   hrDeviceParallelPort OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The device type identifier used for a parallel port."
+       ::= { hrDeviceTypes 15 }
+
+   hrDevicePointing OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The device type identifier used for a pointing device
+           (e.g., a mouse)."
+       ::= { hrDeviceTypes 16 }
+
+   hrDeviceSerialPort OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The device type identifier used for a serial port."
+       ::= { hrDeviceTypes 17 }
+
+   hrDeviceTape OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The device type identifier used for a tape storage device."
+       ::= { hrDeviceTypes 18 }
+
+   hrDeviceClock OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The device type identifier used for a clock device."
+       ::= { hrDeviceTypes 19 }
+
+   hrDeviceVolatileMemory OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The device type identifier used for a volatile memory
+           storage device."
+       ::= { hrDeviceTypes 20 }
+
+   hrDeviceNonVolatileMemory OBJECT-IDENTITY
+       STATUS current
+       DESCRIPTION
+           "The device type identifier used for a non-volatile memory
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 40]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+           storage device."
+       ::= { hrDeviceTypes 21 }
+
+   -- Registrations for some popular File System types,
+   -- for use with hrFSType.
+   hrFSTypes               OBJECT IDENTIFIER ::= { hrDevice 9 }
+
+   hrFSOther OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+           "The file system type identifier used when no other
+           defined type is appropriate."
+       ::= { hrFSTypes 1 }
+
+   hrFSUnknown OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+           "The file system type identifier used when the type of
+           file system is unknown."
+       ::= { hrFSTypes 2 }
+
+   hrFSBerkeleyFFS OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+           "The file system type identifier used for the
+           Berkeley Fast File System."
+       ::= { hrFSTypes 3 }
+
+   hrFSSys5FS OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+           "The file system type identifier used for the
+           System V File System."
+       ::= { hrFSTypes 4 }
+
+   hrFSFat OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+           "The file system type identifier used for
+           DOS's FAT file system."
+       ::= { hrFSTypes 5 }
+
+   hrFSHPFS OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+           "The file system type identifier used for OS/2's
+           High Performance File System."
+       ::= { hrFSTypes 6 }
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 41]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+   hrFSHFS OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+           "The file system type identifier used for the
+           Macintosh Hierarchical File System."
+       ::= { hrFSTypes 7 }
+
+   hrFSMFS OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+           "The file system type identifier used for the
+           Macintosh File System."
+       ::= { hrFSTypes 8 }
+
+   hrFSNTFS OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+           "The file system type identifier used for the
+           Windows NT File System."
+       ::= { hrFSTypes 9 }
+
+   hrFSVNode OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+           "The file system type identifier used for the
+           VNode File System."
+       ::= { hrFSTypes 10 }
+
+   hrFSJournaled OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+           "The file system type identifier used for the
+           Journaled File System."
+       ::= { hrFSTypes 11 }
+
+   hrFSiso9660 OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+           "The file system type identifier used for the
+           ISO 9660 File System for CD's."
+       ::= { hrFSTypes 12 }
+
+   hrFSRockRidge OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+           "The file system type identifier used for the
+           RockRidge File System for CD's."
+       ::= { hrFSTypes 13 }
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 42]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+   hrFSNFS OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+           "The file system type identifier used for the
+           NFS File System."
+       ::= { hrFSTypes 14 }
+
+   hrFSNetware OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+           "The file system type identifier used for the
+           Netware File System."
+       ::= { hrFSTypes 15 }
+
+   hrFSAFS OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+           "The file system type identifier used for the
+           Andrew File System."
+       ::= { hrFSTypes 16 }
+
+   hrFSDFS OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+           "The file system type identifier used for the
+           OSF DCE Distributed File System."
+       ::= { hrFSTypes 17 }
+
+   hrFSAppleshare OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+           "The file system type identifier used for the
+           AppleShare File System."
+       ::= { hrFSTypes 18 }
+
+   hrFSRFS OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+           "The file system type identifier used for the
+           RFS File System."
+       ::= { hrFSTypes 19 }
+
+   hrFSDGCFS OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+           "The file system type identifier used for the
+           Data General DGCFS."
+       ::= { hrFSTypes 20 }
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 43]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+   hrFSBFS OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+           "The file system type identifier used for the
+           SVR4 Boot File System."
+       ::= { hrFSTypes 21 }
+
+   hrFSFAT32 OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+           "The file system type identifier used for the
+           Windows FAT32 File System."
+       ::= { hrFSTypes 22 }
+
+   hrFSLinuxExt2 OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+           "The file system type identifier used for the
+           Linux EXT2 File System."
+       ::= { hrFSTypes 23 }
+
+   END
+
+6.  Internationalization Considerations
+
+   This MIB has many objects that identify file-system pathnames on the
+   managed host. Many file systems allow pathnames to be encoded in a
+   variety of character sets (other than ASCII), but do not support the
+   encoding of the actual character set used with the pathname. The
+   implementation strategy is that user interfaces (i.e. character-based
+   shells or graphical applications) will have configuration options
+   that control with which character set they will interpret and display
+   all pathnames. This is often a per-user configuration (e.g. an
+   environment variable), so that users using different languages and
+   character sets on a multi-user system may each work effectively with
+   their preferred character set. A human usually controls this
+   configuration. If an application is not configured or is configured
+   incorrectly, it will often have trouble displaying pathnames in the
+   intended character set.
+
+   This situation made it important for this MIB to handle two issues:
+
+   1) Pathname objects must be able to transfer a variety of character
+      sets with potentially multi-byte encodings; and,
+
+
+
+
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 44]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+   2) HostMIB agents will generally not be correctly configured for the
+      appropriate character set to be used for all files on the system,
+      particularly on a system with multiple users using different
+      character sets. It was thus impossible to mandate that the agent
+      tag pathnames with the character set in use.
+
+   These issues were solved with the introduction of the
+   InternationalDisplayString textual convention, which supports multi-
+   byte encodings. Network management stations should use a local
+   algorithm to determine which character set is in use and how it
+   should be displayed. It is expected that network management station
+   applications will rely on human configuration to choose which
+   character set in which to interpret InternationalDisplayString
+   objects, much like an application running locally on that host.
+
+7.  Security Considerations
+
+   There are a number of management objects defined in this MIB that
+   have a MAX-ACCESS clause of read-write.  Such objects may be
+   considered sensitive or vulnerable in some network environments.  The
+   support for SET operations in a non-secure environment without proper
+   protection can have a negative effect on system operations.
+
+   There are a number of managed objects in this MIB that may contain
+   sensitive information. The objects in the Running Software Group list
+   information about running software on the system (including the
+   operating system software and version).  Some may wish not to
+   disclose to others what software they are running. Further, an
+   inventory of the running software and versions may be helpful to an
+   attacker who hopes to exploit software bugs in certain applications.
+   The same issues exist for the objects in the Installed Software
+   Group.
+
+   It is thus important to control even GET access to these objects and
+   possibly to even encrypt the values of these object when sending them
+   over the network via SNMP.  Not all versions of SNMP provide features
+   for such a secure environment.
+
+   SNMPv1 by itself is not a secure environment.  Even if the network
+   itself is secure (for example by using IPSec), even then, there is no
+   control as to who on the secure network is allowed to access and
+   GET/SET (read/change/create/delete) the objects in this MIB.
+
+   It is recommended that the implementers consider the security
+   features as provided by the SNMPv3 framework.  Specifically, the use
+   of the User-based Security Model RFC 2574 [RFC2574] and the View-
+   based Access Control Model RFC 2575 [RFC2575] is recommended.
+
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 45]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+   It is then a customer/user responsibility to ensure that the SNMP
+   entity giving access to an instance of this MIB, is properly
+   configured to give access to the objects only to those principals
+   (users) that have legitimate rights to indeed GET or SET
+   (change/create/delete) them.
+
+8.  References
+
+   [RFC2571]   Harrington, D., Presuhn, R. and B. Wijnen, "An
+               Architecture for Describing SNMP Management Frameworks",
+               RFC 2571, April 1999.
+
+   [RFC1155]   Rose, M. and K. McCloghrie, "Structure and Identification
+               of Management Information for TCP/IP-based Internets",
+               STD 16, RFC 1155, May 1990.
+
+   [RFC1212]   Rose, M. and K. McCloghrie, "Concise MIB Definitions",
+               STD 16, RFC 1212, March 1991.
+
+   [RFC1215]   Rose, M., "A Convention for Defining Traps for use with
+               the SNMP", RFC 1215, March 1991.
+
+   [RFC2578]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+               Rose, M. and S. Waldbusser, "Structure of Management
+               Information Version 2 (SMIv2)", STD 58, RFC 2578, April
+               1999.
+
+   [RFC2579]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+               Rose, M. and S. Waldbusser, "Textual Conventions for
+               SMIv2", STD 58, RFC 2579, April 1999.
+
+   [RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+               Rose, M. and S. Waldbusser, "Conformance Statements for
+               SMIv2", STD 58, RFC 2580, April 1999.
+
+   [RFC1157]   Case, J., Fedor, M., Schoffstall, M. and J.  Davin,
+               "Simple Network Management Protocol", STD 15, RFC 1157,
+               May 1990.
+
+   [RFC1901]   Case, J., McCloghrie, K., Rose, M. and S.  Waldbusser,
+               "Introduction to Community-based SNMPv2", RFC 1901,
+               January 1996.
+
+   [RFC1906]   Case, J., McCloghrie, K., Rose, M. and S.  Waldbusser,
+               "Transport Mappings for Version 2 of the Simple Network
+               Management Protocol (SNMPv2)", RFC 1906, January 1996.
+
+
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 46]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+   [RFC2572]   Case, J., Harrington D., Presuhn R. and B. Wijnen,
+               "Message Processing and Dispatching for the Simple
+               Network Management Protocol (SNMP)", RFC 2572, April 1999
+
+   [RFC2574]   Blumenthal, U. and B. Wijnen, "User-based Security Model
+               (USM) for version 3 of the Simple Network Management
+               Protocol (SNMPv3)", RFC 2574, April 1999.
+
+   [RFC1905]   Case, J., McCloghrie, K., Rose, M. and S.  Waldbusser,
+               "Protocol Operations for Version 2 of the Simple Network
+               Management Protocol (SNMPv2)", RFC 1905, January 1996.
+
+   [RFC2573]   Levi, D., Meyer, P. and B. Stewart, "SNMPv3
+               Applications", RFC 2573, April 1999.
+
+   [RFC2575]   Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
+               Access Control Model (VACM) for the Simple Network
+               Management Protocol (SNMP)", RFC 2575, April 1999.
+
+   [RFC2570]   Case, J., Mundy, R., Partain, D. and B. Stewart,
+               "Introduction to Version 3 of the Internet- standard
+               Network Management Framework", RFC 2570, April 1999.
+
+   [RFC1907]   Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
+               "Management Information Base for Version 2 of the Simple
+               Network Management Protocol (SNMPv2)", RFC 1907, January
+               1996.
+
+   [RFC2233]   McCloghrie, K. and F. Kastenholz, "The Interfaces Group
+               MIB", RFC 2233, November 1997.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 47]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+9.  Acknowledgments
+
+   This document was produced by the Host Resources MIB working group.
+
+   Bobby Krupczak's efforts were particularly helpful in the creation of
+   the draft standard version of this document.
+
+   In addition, the authors gratefully acknowledge the comments of the
+   following individuals:
+
+           Amatzia Ben-Artzi  NetManage
+           Ron Bergman        Hitachi, Inc.
+           Steve Bostock      Novell
+           Stephen Bush       GE Information Systems
+           Jeff Case          SNMP Research
+           Chuck Davin        Bellcore
+           Ray Edgarton       Bell Atlantic
+           Mike Erlinger      Aerospace Corporation
+           Tim Farley         Magee Enterprises
+           Mark Kepke         Hewlett Packard
+           Bobby Krupczak     Empire Technologies, Inc.
+           Cheryl Krupczak    Empire Technologies, Inc.
+           Harry Lewis        IBM Corp.
+           Keith McCloghrie   Cisco Systems
+           Greg Minshall      Novell
+           Steve Moulton      SNMP Research
+           Dave Perkins       Synoptics
+           Ed Reeder          Objective Systems Integrators
+           Mike Ritter        Apple Computer
+           Marshall Rose      Dover Beach Consulting
+           Jon Saperia        DEC
+           Rodney Thayer      Sable Technology
+           Kaj Tesink         Bellcore
+           Dean Throop        Data General
+           Bert Wijnen        Lucent
+           Lloyd Young        Lexmark International
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 48]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+10.  Authors' Addresses
+
+   Pete Grillo
+   WeSync.com
+   1001 SW Fifth Ave, Fifth Floor
+   Portland, OR 97204
+
+   Phone: 503-425-5051
+   Fax: 503-827-6718
+   email: pete@wesync.com
+   Phone: +1 503 827 6717
+
+
+   Steven Waldbusser
+   Lucent Technologies, Inc.
+   1213 Innsbruck Dr.
+   Sunnyvale CA 94089
+
+   Phone: +1 650 318 1251
+   Fax:   +1 650 318 1633
+   EMail: waldbusser@ins.com
+
+11.  Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of
+   any intellectual property or other rights that might be
+   claimed to pertain to the implementation or use of the
+   technology described in this document or the extent to which
+   any license under such rights might or might not be available;
+   neither does it represent that it has made any effort to
+   identify any such rights.  Information on the IETF's
+   procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.
+   Copies of claims of rights made available for publication and
+   any assurances of licenses to be made available, or the result
+   of an attempt made to obtain a general license or permission
+   for the use of such proprietary rights by implementors or
+   users of this specification can be obtained from the IETF
+   Secretariat.
+
+   The IETF invites any interested party to bring to its
+   attention any copyrights, patents or patent applications, or
+   other proprietary rights which may cover technology that may
+   be required to practice this standard.  Please address the
+   information to the IETF Executive Director.
+
+
+
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 49]
+
+RFC 2790                   Host Resources MIB                 March 2000
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Waldbusser & Grillo         Standards Track                    [Page 50]
+