doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc1565.txt b/doc/rfc/rfc1565.txt
new file mode 100644
index 0000000..976e40a
--- /dev/null
+++ b/doc/rfc/rfc1565.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                 S. Kille, WG Chair
+Request for Comments: 1565                              ISODE Consortium
+Category: Standards Track                               N. Freed, Editor
+                                                                Innosoft
+                                                            January 1994
+
+
+                    Network Services Monitoring 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.
+
+Table of Contents
+
+   1. Introduction ................................................. 2
+   2. The SNMPv2 Network Management Framework ...................... 2
+   2.1 Object Definitions .......................................... 3
+   3. Rationale for having a Network Services Monitoring MIB ....... 3
+   3.1 General Relationship to Other MIBs .......................... 4
+   3.2 Restriction of Scope ........................................ 4
+   3.3 Relationship to Directory Services .......................... 4
+   4. Application Objects .......................................... 5
+   5. Definitions .................................................. 6
+   6. Acknowledgements .............................................16
+   7. References ...................................................16
+   8. Security Considerations ......................................16
+   9. Authors' Addresses ...........................................17
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kille & Freed                                                   [Page 1]
+
+RFC 1565            Network Services Monitoring MIB         January 1994
+
+
+1.  Introduction
+
+   There are a wide range of networked applications for which it is
+   appropriate to provide SNMP Monitoring.  This includes both TCP/IP
+   and OSI applications.  This document defines a MIB which contains the
+   elements common to the monitoring of any network service application.
+   This information includes a table of all monitorable network service
+   applications, a count of the associations (connections) to each
+   application, and basic information about the parameters and status of
+   each application-related association.
+
+   This MIB may be used on its own for any application, and for most
+   simple applications this will suffice.  This MIB is also designed to
+   serve as a building block which can be used in conjunction with
+   application-specific monitoring and management.  Two examples of this
+   are MIBs defining additional variables for monitoring a Message
+   Transfer Agent (MTA) service or a Directory Service Agent (DSA)
+   service. It is expected that further MIBs of this nature will be
+   specified.
+
+   This MIB does not attempt to provide facilities for management of the
+   host or hosts the network service application runs on, nor does it
+   provide facilities for monitoring applications that provide something
+   other than a network service.  Host resource and general application
+   monitoring is handled by the Host Resources MIB.
+
+2.  The SNMPv2 Network Management Framework
+
+   The SNMPv2 Network Management Framework consists of four major
+   components.  They are:
+
+      o  RFC 1442 [1] which defines the SMI, the mechanisms used for
+         describing and naming objects for the purpose of management.
+
+      o  STD 17, RFC 1213 [2] defines MIB-II, the core set of managed
+         objects for the Internet suite of protocols.
+
+      o  RFC 1445 [3] which defines the administrative and other
+         architectural aspects of the framework.
+
+      o  RFC 1448 [4] which defines the protocol used for network
+         access to managed objects.
+
+   The Framework permits new objects to be defined for the purpose of
+   experimentation and evaluation.
+
+
+
+
+
+
+Kille & Freed                                                   [Page 2]
+
+RFC 1565            Network Services Monitoring MIB         January 1994
+
+
+2.1  Object Definitions
+
+   Managed objects are accessed via a virtual information store, termed
+   the Management Information Base or MIB.  Objects in the MIB are
+   defined using the subset of Abstract Syntax Notation One (ASN.1)
+   defined in the SMI.  In particular, each object type is named by an
+   OBJECT IDENTIFIER, an administratively assigned name.  The object
+   type together with an object instance serves to uniquely identify a
+   specific instantiation of the object.  For human convenience, we
+   often use a textual string, termed the descriptor, to refer to the
+   object type.
+
+3.  Rationale for having a Network Services Monitoring MIB
+
+   Much effort has been expended in developing tools to manage lower
+   layer network facilities.  However, relatively little work has been
+   done on managing application layer entities.  It is neither efficient
+   nor reasonable to manage all aspects of application layer entities
+   using only lower layer information.  Moreover, the difficulty of
+   managing application entities in this way increases dramatically as
+   application entities become more complex.
+
+   This leads to a substantial need to monitor applications which
+   provide network services, particularly distributed components such as
+   MTAs and DSAs, by monitoring specific aspects of the application
+   itself.  Reasons to monitor such components include but are not
+   limited to measuring load, detecting broken connectivity, isolating
+   system failures, and locating congestion.
+
+   In order to manage network service applications effectively two
+   requirements must be met:
+
+      (1)  It must be possible to monitor a large number of components
+           (typical for a large organization).
+
+      (2)  Application monitoring must be integrated into general
+           network management.
+
+   This specification defines simple read-only access; this is
+   sufficient to determine up/down status and provide an indication of a
+   broad class of operational problems.
+
+
+
+
+
+
+
+
+
+
+Kille & Freed                                                   [Page 3]
+
+RFC 1565            Network Services Monitoring MIB         January 1994
+
+
+3.1  General Relationship to Other MIBs
+
+   This MIB is intended to only provide facilities common to the
+   monitoring of any network service application.  It does not provide
+   all the facilities necessary to monitor any specific application.
+   Each specific type of network service application is expected to have
+   a MIB of its own that makes use of these common facilities.
+
+3.2  Restriction of Scope
+
+   The framework provided here is very minimal; there is a lot more that
+   could be done. For example:
+
+   (1)  General network service application configuration monitoring and
+        control.
+
+   (2)  Detailed examination and modification of individual entries in
+        service-specific request queues.
+
+   (3)  Probing to determine the status of a specific request (e.g. the
+        location of a mail message with a specific message-id).
+
+   (4)  Requesting that certain actions be performed (e.g. forcing an
+        immediate connection and transfer of pending messages to some
+        specific system).
+
+   All these capabilities are both impressive and useful.  However,
+   these capabilities would require provisions for strict security
+   checking.  These capabilities would also mandate a much more complex
+   design, with many characteristics likely to be fairly
+   implementation-specific.  As a result such facilities are likely to
+   be both contentious and difficult to implement.
+
+   This document religiously keeps things simple and focuses on the
+   basic monitoring aspect of managing applications providing network
+   services.  The goal here is to provide a framework which is simple,
+   useful, and widely implementable.
+
+3.3  Relationship to Directory Services
+
+   Use of and management of directory services already is tied up with
+   network service application management.  There are clearly many
+   things which could be dealt with by directory services and protocols.
+   We take the line here that static configuration information is both
+   provided by and dealt with by directory services and protocols.  The
+   emphasis here is on transient application status.
+
+
+
+
+
+Kille & Freed                                                   [Page 4]
+
+RFC 1565            Network Services Monitoring MIB         January 1994
+
+
+   By placing static information in the directory, the richness and
+   linkage of the directory information framework does not need to be
+   repeated in the MIB.  Static information is information which has a
+   mean time to change of the order of days or longer.
+
+   When information about network service applications is stored in the
+   directory (regardless of whether or not the network service
+   application makes direct use of the directory), it is recommended
+   that a linkage be established, so that:
+
+   (1)  The managed object contains its own directory name.  This allows
+        all directory information to be obtained by reference.  This will
+        let a SNMP monitor capable of performing directory queries
+        present this information to the manager in an appropriate format.
+        It is intended that this will be the normal case.
+
+   (2)  The directory will reference the location of the SNMP agent, so
+        that an SNMP capable directory query agent could probe dynamic
+        characteristics of the object.
+
+   (3)  This approach could be extended further, so that the SNMP
+        attributes are modelled as directory attributes.  This would
+        dramatically simplify the design of directory service agents that
+        use SNMP to obtain the information they need.
+
+4.  Application Objects
+
+   This MIB defines a set of general purpose attributes which would be
+   appropriate for a range of applications that provide network
+   services.  Both OSI and non-OSI services can be accomodated.
+   Additional tables defined in extensions to this MIB provide
+   attributes specific to specific network services.
+
+   A table is defined which will have one row for each network service
+   application running on the system.  The only static information held
+   on the application is its name.  All other static information should
+   be obtained from various directory services.  The applDirectoryName
+   is an external key, which allows an SNMP MIB entry to be cleanly
+   related to the X.500 Directory.  In SNMP terms, the applications are
+   grouped in a table called applTable, which is indexed by an integer
+   key applIndex.
+
+   The type of the application will be determined by one or both of:
+
+   (1)  Additional MIB variables specific to the applications.
+
+   (2)  An association to the application of a specific protocol.
+
+
+
+
+Kille & Freed                                                   [Page 5]
+
+RFC 1565            Network Services Monitoring MIB         January 1994
+
+
+5.  Definitions
+
+   APPLICATION-MIB DEFINITIONS ::= BEGIN
+
+   IMPORTS
+       OBJECT-TYPE, Counter32, Gauge32
+         FROM SNMPv2-SMI
+       mib-2
+         FROM RFC1213-MIB
+       DisplayString, TimeStamp
+         FROM SNMPv2-TC;
+
+
+   -- Textual conventions
+
+   -- DistinguishedName [5] is used to refer to objects in the
+   -- directory.
+
+   DistinguishedName ::= TEXTUAL-CONVENTION
+       STATUS current
+       DESCRIPTION
+           "A Distinguished Name represented in accordance with
+            RFC1485."
+       SYNTAX DisplayString
+
+   application MODULE-IDENTITY
+       LAST-UPDATED "9311280000Z"
+       ORGANIZATION "IETF Mail and Directory Management Working Group"
+       CONTACT-INFO
+         "        Ned Freed
+
+          Postal: Innosoft International, Inc.
+                  250 West First Street, Suite 240
+                  Claremont, CA  91711
+                  US
+
+             Tel: +1 909 624 7907
+             Fax: +1 909 621 5319
+
+          E-Mail: ned@innosoft.com"
+       DESCRIPTION
+         "The MIB module describing network service applications"
+       ::= { mib-2 27 }
+
+   -- The basic applTable contains a list of the application
+   -- entities.
+
+
+
+
+
+Kille & Freed                                                   [Page 6]
+
+RFC 1565            Network Services Monitoring MIB         January 1994
+
+
+   applTable OBJECT-TYPE
+       SYNTAX SEQUENCE OF ApplEntry
+       MAX-ACCESS not-accessible
+       STATUS current
+       DESCRIPTION
+           "The table holding objects which apply to all different
+            kinds of applications providing network services."
+       ::= {application 1}
+
+   applEntry OBJECT-TYPE
+       SYNTAX ApplEntry
+       MAX-ACCESS not-accessible
+       STATUS current
+       DESCRIPTION
+         "An entry associated with a network service application."
+       INDEX {applIndex}
+       ::= {applTable 1}
+
+   ApplEntry ::= SEQUENCE {
+       applIndex
+           INTEGER,
+       applName
+           DisplayString,
+       applDirectoryName
+           DistinguishedName,
+       applVersion
+           DisplayString,
+       applUptime
+           TimeStamp,
+       applOperStatus
+           INTEGER,
+       applLastChange
+           TimeStamp,
+       applInboundAssociations
+           Gauge32,
+       applOutboundAssociations
+           Gauge32,
+       applAccumulatedInboundAssociations
+           Counter32,
+       applAccumulatedOutboundAssociations
+           Counter32,
+       applLastInboundActivity
+           TimeStamp,
+       applLastOutboundActivity
+           TimeStamp,
+       applRejectedInboundAssociations
+           Counter32,
+       applFailedOutboundAssociations
+
+
+
+Kille & Freed                                                   [Page 7]
+
+RFC 1565            Network Services Monitoring MIB         January 1994
+
+
+           Counter32
+   }
+
+   applIndex OBJECT-TYPE
+       SYNTAX INTEGER (1..2147483647)
+       MAX-ACCESS not-accessible
+       STATUS current
+       DESCRIPTION
+         "An index to uniquely identify the network service
+          application."
+       ::= {applEntry 1}
+
+   applName OBJECT-TYPE
+       SYNTAX DisplayString
+       MAX-ACCESS read-only
+       STATUS current
+       DESCRIPTION
+         "The name the network service application chooses to be
+          known by."
+       ::= {applEntry 2}
+
+   applDirectoryName OBJECT-TYPE
+       SYNTAX DistinguishedName
+       MAX-ACCESS read-only
+       STATUS current
+       DESCRIPTION
+         "The Distinguished Name of the directory entry where
+          static information about this application is stored.
+          An empty string indicates that no information about
+          the application is available in the directory."
+       ::= {applEntry 3}
+
+   applVersion OBJECT-TYPE
+       SYNTAX DisplayString
+       MAX-ACCESS read-only
+       STATUS current
+       DESCRIPTION
+         "The version of network service application software."
+       ::= {applEntry 4}
+
+
+
+
+
+
+
+
+
+
+
+
+Kille & Freed                                                   [Page 8]
+
+RFC 1565            Network Services Monitoring MIB         January 1994
+
+
+   applUptime OBJECT-TYPE
+       SYNTAX TimeStamp
+       MAX-ACCESS read-only
+       STATUS current
+       DESCRIPTION
+         "The value of sysUpTime at the time the network service
+          application was last initialized.  If the application was
+          last initialized prior to the last initialization of the
+          network management subsystem, then this object contains
+          a zero value."
+       ::= {applEntry 5}
+
+   applOperStatus OBJECT-TYPE
+       SYNTAX INTEGER {
+         up(1),
+         down(2),
+         halted(3),
+         congested(4),
+         restarting(5)
+       }
+       MAX-ACCESS read-only
+       STATUS current
+       DESCRIPTION
+         "Indicates the operational status of the network service
+          application. 'down' indicates that the network service is
+          not available. 'running' indicates that the network service
+          is operational and available.  'halted' indicates that the
+          service is operational but not available.  'congested'
+          indicates that the service is operational but no additional
+          inbound associations can be accomodated.  'restarting'
+          indicates that the service is currently unavailable but is
+          in the process of restarting and will be available soon."
+       ::= {applEntry 6}
+
+   applLastChange OBJECT-TYPE
+       SYNTAX TimeStamp
+       MAX-ACCESS read-only
+       STATUS current
+       DESCRIPTION
+         "The value of sysUpTime at the time the network service
+          application entered its current operational state.  If
+          the current state was entered prior to the last
+          initialization of the local network management subsystem,
+          then this object contains a zero value."
+       ::= {applEntry 7}
+
+
+
+
+
+
+Kille & Freed                                                   [Page 9]
+
+RFC 1565            Network Services Monitoring MIB         January 1994
+
+
+   applInboundAssociations OBJECT-TYPE
+       SYNTAX Gauge32
+       MAX-ACCESS read-only
+       STATUS current
+       DESCRIPTION
+         "The number of current associations to the network service
+          application, where it is the responder.  For dynamic single
+          threaded processes, this will be the number of application
+          instances."
+       ::= {applEntry 8}
+
+   applOutboundAssociations OBJECT-TYPE
+       SYNTAX Gauge32
+       MAX-ACCESS read-only
+       STATUS current
+       DESCRIPTION
+         "The number of current associations to the network service
+          application, where it is the initiator.  For dynamic single
+          threaded processes, this will be the number of application
+          instances."
+       ::= {applEntry 9}
+
+   applAccumulatedInboundAssociations OBJECT-TYPE
+       SYNTAX Counter32
+       MAX-ACCESS read-only
+       STATUS current
+       DESCRIPTION
+         "The total number of associations to the application entity
+          since application initialization, where it was the responder.
+          For  dynamic single threaded processes, this will be the
+          number of application instances."
+       ::= {applEntry 10}
+
+   applAccumulatedOutboundAssociations OBJECT-TYPE
+       SYNTAX Counter32
+       MAX-ACCESS read-only
+       STATUS current
+       DESCRIPTION
+         "The total number of associations to the application entity
+          since application initialization, where it was the initiator.
+          For dynamic single threaded processes, this will be the
+          number of application instances."
+       ::= {applEntry 11}
+
+
+
+
+
+
+
+
+Kille & Freed                                                  [Page 10]
+
+RFC 1565            Network Services Monitoring MIB         January 1994
+
+
+   applLastInboundActivity OBJECT-TYPE
+       SYNTAX TimeStamp
+       MAX-ACCESS read-only
+       STATUS current
+       DESCRIPTION
+         "The value of sysUpTime at the time this application last
+          had an inbound association.  If the last association
+          occurred prior to the last initialization of the network
+          subsystem, then this object contains a zero value."
+       ::= {applEntry 12}
+
+   applLastOutboundActivity OBJECT-TYPE
+       SYNTAX TimeStamp
+       MAX-ACCESS read-only
+       STATUS current
+       DESCRIPTION
+         "The value of sysUpTime at the time this application last
+          had an outbound association.  If the last association
+          occurred prior to the last initialization of the network
+          subsystem, then this object contains a zero value."
+       ::= {applEntry 13}
+
+   applRejectedInboundAssociations OBJECT-TYPE
+       SYNTAX Counter32
+       MAX-ACCESS read-only
+       STATUS current
+       DESCRIPTION
+         "The total number of inbound associations the application
+          entity has rejected, since application initialization."
+       ::= {applEntry 14}
+
+   applFailedOutboundAssociations OBJECT-TYPE
+       SYNTAX Counter32
+       MAX-ACCESS read-only
+       STATUS current
+       DESCRIPTION
+         "The total number associations where the application entity
+          is initiator and association establishment has failed,
+          since application initialization."
+       ::= {applEntry 15}
+
+
+   -- The assocTable augments the information in the applTable
+   -- with information about associations.  Note that two levels
+   -- of compliance are specified below, depending on whether
+   -- association monitoring is mandated.
+
+
+
+
+
+Kille & Freed                                                  [Page 11]
+
+RFC 1565            Network Services Monitoring MIB         January 1994
+
+
+   assocTable OBJECT-TYPE
+       SYNTAX SEQUENCE OF AssocEntry
+       MAX-ACCESS not-accessible
+       STATUS current
+       DESCRIPTION
+           "The table holding a set of all active application
+            associations."
+       ::= {application 2}
+
+   assocEntry OBJECT-TYPE
+       SYNTAX AssocEntry
+       MAX-ACCESS not-accessible
+       STATUS current
+       DESCRIPTION
+         "An entry associated with an association for a network
+          service application."
+       INDEX {applIndex, assocIndex}
+       ::= {assocTable 1}
+
+   AssocEntry ::= SEQUENCE {
+       assocIndex
+           INTEGER,
+       assocRemoteApplication
+           DisplayString,
+       assocApplicationProtocol
+           OBJECT IDENTIFIER,
+       assocApplicationType
+           INTEGER,
+       assocDuration
+           TimeStamp
+   }
+
+   assocIndex OBJECT-TYPE
+       SYNTAX INTEGER (1..2147483647)
+       MAX-ACCESS not-accessible
+       STATUS current
+       DESCRIPTION
+         "An index to uniquely identify each association for a network
+          service application."
+       ::= {assocEntry 1}
+
+
+
+
+
+
+
+
+
+
+
+Kille & Freed                                                  [Page 12]
+
+RFC 1565            Network Services Monitoring MIB         January 1994
+
+
+   assocRemoteApplication OBJECT-TYPE
+       SYNTAX DisplayString
+       MAX-ACCESS read-only
+       STATUS current
+       DESCRIPTION
+         "The name of the system running remote network service
+          application.  For an IP-based application this should be
+          either a domain name or IP address.  For an OSI application
+          it should be the string encoded distinguished name of the
+          managed object.  For X.400(84) MTAs which do not have a
+          Distinguished Name, the RFC1327 [6] syntax
+          'mta in globalid' should be used."
+       ::= {assocEntry 2}
+
+   assocApplicationProtocol OBJECT-TYPE
+       SYNTAX OBJECT IDENTIFIER
+       MAX-ACCESS read-only
+       STATUS current
+       DESCRIPTION
+         "An identification of the protocol being used for the
+          application.  For an OSI Application, this will be the
+          Application Context.  For Internet applications, the IANA
+          maintains a registry of the OIDs which correspond to
+          well-known applications.  If the application protocol is
+          not listed in the registry, an OID value of the form
+          {applTCPProtoID port} or {applUDProtoID port} are used for
+          TCP-based and UDP-based protocols, respectively. In either
+          case 'port' corresponds to the primary port number being
+          used by the protocol."
+       ::= {assocEntry 3}
+
+   assocApplicationType OBJECT-TYPE
+       SYNTAX INTEGER {
+           ua-initiator(1),
+           ua-responder(2),
+           peer-initiator(3),
+           peer-responder(4)}
+       MAX-ACCESS read-only
+       STATUS current
+       DESCRIPTION
+         "This indicates whether the remote application is some type of
+          client making use of this network service (e.g. a User Agent)
+          or a server acting as a peer. Also indicated is whether the
+          remote end initiated an incoming connection to the network
+          service or responded to an outgoing connection made by the
+          local application."
+       ::= {assocEntry 4}
+
+
+
+
+Kille & Freed                                                  [Page 13]
+
+RFC 1565            Network Services Monitoring MIB         January 1994
+
+
+   assocDuration OBJECT-TYPE
+       SYNTAX TimeStamp
+       MAX-ACCESS read-only
+       STATUS current
+       DESCRIPTION
+         "The value of sysUpTime at the time this association was
+          started.  If this association started prior to the last
+          initialization of the network subsystem, then this
+          object contains a zero value."
+       ::= {assocEntry 5}
+
+
+   -- Conformance information
+
+   applConformance OBJECT IDENTIFIER ::= {application 3}
+
+   applGroups      OBJECT IDENTIFIER ::= {applConformance 1}
+   applCompliances OBJECT IDENTIFIER ::= {applConformance 2}
+
+
+   -- Compliance statements
+
+   applCompliance MODULE-COMPLIANCE
+       STATUS current
+       DESCRIPTION
+         "The compliance statement for SNMPv2 entities
+          which implement the Network Services Monitoring MIB
+          for basic monitoring of network service applications."
+       MODULE  -- this module
+         MANDATORY-GROUPS {applGroup}
+       ::= {applCompliances 1}
+
+   assocCompliance MODULE-COMPLIANCE
+       STATUS current
+       DESCRIPTION
+         "The compliance statement for SNMPv2 entities which
+          implement the Network Services Monitoring MIB for basic
+          monitoring of network service applications and their
+          associations."
+       MODULE  -- this module
+         MANDATORY-GROUPS {applGroup, assocGroup}
+       ::= {applCompliances 2}
+
+
+
+
+
+
+
+
+
+Kille & Freed                                                  [Page 14]
+
+RFC 1565            Network Services Monitoring MIB         January 1994
+
+
+   -- Units of conformance
+
+   applGroup OBJECT-GROUP
+       OBJECTS {
+         applName, applVersion, applUptime, applOperStatus,
+         applLastChange, applInboundAssociations,
+         applOutboundAssociations, applAccumulatedInboundAssociations,
+         applAccumulatedOutboundAssociations, applLastInboundActivity,
+         applLastOutboundActivity, applRejectedInboundAssociations,
+         applFailedOutboundAssociations}
+       STATUS current
+       DESCRIPTION
+         "A collection of objects providing basic monitoring of
+          network service applications."
+       ::= {applGroups 1}
+
+   assocGroup OBJECT-GROUP
+       OBJECTS {
+         assocRemoteApplication, assocApplicationProtocol,
+         assocApplicationType, assocDuration}
+       STATUS current
+       DESCRIPTION
+         "A collection of objects providing basic monitoring of
+          network service applications' associations."
+       ::= {applGroups 2}
+
+
+   -- OIDs of the form {applTCPProtoID port} are intended to be used
+   -- for TCP-based protocols that don't have OIDs assigned by other
+   -- means. {applUDPProtoID port} serves the same purpose for
+   -- UDP-based protocols. In either case 'port' corresponds to
+   -- the primary port number being used by the protocol. For example,
+   -- assuming no other OID is assigned for SMTP, an OID of
+   -- {applTCPProtoID 25} could be used, since SMTP is a TCP-based
+   -- protocol that uses port 25 as its primary port.
+
+   applTCPProtoID OBJECT IDENTIFIER ::= {application 4}
+   applUDPProtoID OBJECT IDENTIFIER ::= {application 5}
+
+   END
+
+
+
+
+
+
+
+
+
+
+
+Kille & Freed                                                  [Page 15]
+
+RFC 1565            Network Services Monitoring MIB         January 1994
+
+
+6.  Acknowledgements
+
+   This document is a product of the Mail and Directory Management
+   (MADMAN) Working Group. It is based on an earlier MIB designed by S.
+   Kille, T.  Lenggenhager, D. Partain, and W. Yeong.
+
+7.  References
+
+  [1]  Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure
+       of Management Information for version 2 of the Simple Network
+       Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc.,
+       Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
+       University, April 1993.
+
+  [2]  McCloghrie, K., and M. Rose, Editors, "Management Information
+       Base for Network Management of TCP/IP-based internets: MIB-II",
+       STD 17, RFC 1213, Hughes LAN Systems, Performance Systems
+       International, March 1991.
+
+  [2]  Galvin, J., and K. McCloghrie, "Administrative Model for version
+       2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445,
+       Trusted Information Systems, Hughes LAN Systems, April 1993.
+
+  [4]  Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
+       Operations for version 2 of the Simple Network Management
+       Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN
+       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
+       University, April 1993.
+
+  [5]  Kille, S., "A String Representation of Distinguished Names", RFC
+       1485, ISODE Consortium, July 1993.
+
+  [6]  Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC822",
+       RFC 1327, University College London, May 1992.
+
+8.  Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kille & Freed                                                  [Page 16]
+
+RFC 1565            Network Services Monitoring MIB         January 1994
+
+
+Authors' Addresses
+
+   Steve Kille, WG Chair
+   ISODE Consortium
+   The Dome, The Square
+   Richmond TW9 1DT
+   UK
+
+   Phone: +44 81 332 9091
+   EMail: S.Kille@isode.com
+
+
+   Ned Freed, Editor
+   Innosoft International, Inc.
+   250 West First Street, Suite 240
+   Claremont, CA 91711
+   USA
+
+   Phone: +1 909 624 7907
+   Fax: +1 909 621 5319
+   EMail: ned@innosoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kille & Freed                                                  [Page 17]
+
\ No newline at end of file