rfc2605.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                       G. Mansfield
Request for Comments: 2605                          Cyber Solutions Inc.
Obsoletes: 1567                                                 S. Kille
Category: Standards Track                           MessagingDirect Ltd.
                                                               June 1999


                    Directory Server 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.

Copyright Notice

   Copyright (C) The Internet Society (1999).  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 1567, "X.500 Directory Monitoring MIB". This
   memo extends that specification to a more generic MIB for monitoring
   one or more directory servers each of which may support multiple
   access protocols.  The MIB defined in this memo will be used in
   conjunction with the NETWORK-SERVICES-MIB [19] for monitoring
   Directory Servers.

Table of Contents

   1.  The SNMP Network Management Framework ....................... 2
   2.  The Directory Services Model ................................ 3
   3.  MIB Model for Directory Management .......................... 4
   4.  MIB design .................................................. 5
   5.  The Directory Server Monitoring MIB ......................... 5
   6.  Intellectual Property .......................................22
   7.  Changes from RFC1567 ........................................22
   8.  Acknowledgements ............................................22
   9.  References ..................................................23
   Security Considerations .........................................24
   Authors' Addresses ..............................................25
   Full Copyright Statement ........................................26





Mansfield & Kille           Standards Track                     [Page 1]

RFC 2605            Directory Server Monitoring MIB            June 1999


1.  The SNMP Network Management Framework

   The SNMP Network Management Framework presently consists of five
   major components:

    o   An overall architecture, described in RFC 2571 [1].

    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 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The
        second version, called SMIv2, is described in STD 58, RFC 2578
        [5], RFC 2579 [6] and RFC 2580 [7].

    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 [8]. A second version of the SNMP
        message protocol, which is not an Internet standards track
        protocol, is called SNMPv2c and described in RFC 1901 [9] and
        RFC 1906 [10].  The third version of the message protocol is
        called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and
        RFC 2574 [12].

    o   Protocol operations for accessing management information. The
        first set of protocol operations and associated PDU formats is
        described in STD 15, RFC 1157 [8]. A second set of protocol
        operations and associated PDU formats is described in RFC 1905
        [13].

    o   A set of fundamental applications described in RFC 2573 [14] and
        the view-based access control mechanism described in RFC 2575
        [15].

   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.





Mansfield & Kille           Standards Track                     [Page 2]

RFC 2605            Directory Server Monitoring MIB            June 1999


2.  The Directory Services Model.

   The Directory comprises of a set of servers (Directory Servers).
   Clients or Directory User Agents (DUA) are provided access to the
   Directory which maybe local or distributed, by the Directory Servers.
   The server maybe a X.500 Directory System Agent (DSA) [16] running
   over the OSI suite of protocols or, a (C)LDAP[17,18] frontend to the
   X.500 Directory System Agent or, a native LDAP Directory Server
   running directly over TCP or other protocols, or a database acting as
   a backend to another server,  or any other application protocol, or
   any combination of the above. A Directory Server has one or more
   application protocol interfaces.  Through these interfaces the
   Directory Server interacts with the DUA and with the peer Directory
   Servers.

   Fig. 1 shows the case of a Directory Server that receives requests
   and sends back responses in some protocol. Fig. 2 shows one possible
   scenario where the Directory Server speaks multiple protocols.


                              +----------------+
                              |                |
                              |   Directory    | Directory Protocol
                              |     Server     X-------->
                              |                |
                              |                |
                              +----------------+

                                     FIG. 1.


                              +----------------+
                              |                |
               DSP <----------X                X--------> DAP
                              |   Directory    |
             Other            |     Server     |
          Protocol <----------X                X--------> LDAP
                              |                |
                              +----------------+

                                     FIG. 2.


   The Directory contains information in the form of entries. An entry
   is a collection of attributes and is uniquely identified by a name,
   the Distinguished Name (DN). The entries are arranged in a
   hierarchical tree-like structure called the Directory Information
   Tree (DIT).



Mansfield & Kille           Standards Track                     [Page 3]

RFC 2605            Directory Server Monitoring MIB            June 1999


   A DUA requests a Directory Server to perform some operation on the
   Directory. The Directory Server is responsible for performing the
   operation and after completing its effort to carry out the request,
   returns a response to the DUA.

   A Directory Server may use information stored in its local database
   or interact with (chain the request to) other Directory Servers to
   service the DUA request. Alternatively, a Directory Server may return
   a reference to another Directory Server (referral).

   The local database of a Directory Server consists of the part of the
   Directory that is mastered by the Directory Server, the part of the
   Directory for which it keeps slave copies and cached information that
   is gathered during the operation of the Directory Server.

   In the connection oriented mode a DUA "binds" to a Directory Server
   with a particular identification. The Directory Server may
   authenticate the identity of the DUA. In the connectionless mode as
   is employed in CLDAP no binding and/or authentication is carried out
   between the DUA and the Directory Server.  The following type of
   operations are carried out by the Directory Server : Read, Compare,
   Addition of an Entry (AddEntry), Modification of an Entry
   (ModifyEntry), Modification of a DN (ModifyRDN), Deletion of an Entry
   (RemoveEntry), List, Search, Abandon. Some Directory Servers do not
   support some type of operations. For example CLDAP does not support
   AddEntry, ModifyEntry, ModifyRDN, RemoveEntry etc.  In response to
   requests results and/or errors are returned by the Directory Server.

   In the distributed Directory data is often replicated to enhance
   performance and for other advantages. The data to be replicated is
   transferred from the "Supplier" Directory Server to the "Consumer"
   Directory Server according to the replication agreement between the
   supplier and the receiver.

3.  MIB Model for  Directory  Management.

   A Directory manager should be able to monitor all the Directory
   Servers in his/her domain of management. The Directory Servers may be
   running on one or more hosts and, multiple Directory Servers may be
   running on the same host.

   The manager may wish to monitor several aspects of the operational
   Directory Servers. He/she may want to know the process related
   aspects - the resource utilization of an operational Directory
   Server; the network service related aspects e.g. inbound-
   associations, outbound-associations, operational status, and finally
   the information specific to the Directory Server application - its
   operations and performance.



Mansfield & Kille           Standards Track                     [Page 4]

RFC 2605            Directory Server Monitoring MIB            June 1999


   The MIB defined in this document covers the portion which is specific
   to Directory services. The network service related part of the MIB,
   and the host-resources related part of the MIB, as well as other
   parts of interest to a Manager monitoring the Directory services, are
   covered in separate documents [19] [20].

   The MIB will cover a group of Directory Servers. The grouping will be
   done on some logical basis by the administrator/manager.  In all
   cases, the grouping will be reflected in the pertinent NETWORK-
   SERVICES-MIB which will have an entry corresponding to each Directory
   Server in the group.

4.  MIB design.

   The basic principle has been to keep the MIB as simple as possible.
   The Managed objects included in the MIB are divided into three tables
   - dsTable, dsApplIfOpsTable, and dsIntTable.

      - The dsTable contains a list of Directory Servers. The list
        contains a description of the Directory Servers as well as
        summary statistics on the entries held by and the cache
        performance of each Directory Server. The group of servers on
        this list is likely to contain a part of, if not all, the
        Directory Servers in the management domain.

      - The dsApplIfOpsTable provides summary statistics on the
        accesses, operations and errors for each application protocol
        interface of a Directory Server.

      - The dsIntTable  provides some useful information on the
        interaction of the monitored Directory Servers with peer
        Directory Servers.

   There are references to the Directory itself for static information
   pertaining to the Directory Server. These references are in the form
   of "Directory Distinguished Name" [21] of the corresponding object.
   It is intended that Directory management applications will use these
   references to obtain further information on the objects of interest.

5.  The Directory Server Monitoring MIB.

   DIRECTORY-SERVER-MIB DEFINITIONS ::= BEGIN

    IMPORTS
      MODULE-IDENTITY,  Counter32, Gauge32, OBJECT-TYPE
                 FROM SNMPv2-SMI
      mib-2      FROM RFC1213-MIB
      DisplayString,    TimeStamp



Mansfield & Kille           Standards Track                     [Page 5]

RFC 2605            Directory Server Monitoring MIB            June 1999


                 FROM SNMPv2-TC
      MODULE-COMPLIANCE, OBJECT-GROUP
                 FROM SNMPv2-CONF
      ZeroBasedCounter32
                 FROM RMON2-MIB
      applIndex, DistinguishedName, URLString

                 FROM NETWORK-SERVICES-MIB;

    dsMIB MODULE-IDENTITY
       LAST-UPDATED "9906070000Z"
       ORGANIZATION "IETF Mail and Directory Management Working
                     Group"
       CONTACT-INFO
      "                      Glenn Mansfield
                     Postal: Cyber Solutions Inc.
                             6-6-3, Minami Yoshinari
                             Aoba-ku, Sendai, Japan 989-3204.

                        Tel: [phone]
                        Fax: [phone]
                   E-mail: [e-mail]
       Working Group E-mail: [e-mail]
               To subscribe: [e-mail]"

       DESCRIPTION
               " The MIB module for monitoring Directory Services."

       -- revision information

       REVISION "9906070000Z"
       DESCRIPTION
         "This revision of this MIB is published in RFC 2605.

          This revision obsoletes RFC 1567. It is incompatible with
          the original MIB and so it has been renamed from dsaMIB
          to dsMIB."

       REVISION "9311250000Z" -- 25th November 1993
       DESCRIPTION
         "The original version of this MIB was published in RFC 1567."
       ::= { mib-2 66 }

    dsTable OBJECT-TYPE
        SYNTAX SEQUENCE OF DsTableEntry
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION



Mansfield & Kille           Standards Track                     [Page 6]

RFC 2605            Directory Server Monitoring MIB            June 1999


          " The table holding information related to the Directory
            Servers."
        ::= {dsMIB 1}

    dsTableEntry OBJECT-TYPE
        SYNTAX DsTableEntry
        MAX-ACCESS not-accessible
        STATUS current
        DESCRIPTION
          " Entry containing summary description for a Directory
            Server."
        INDEX { applIndex }
        ::= {dsTable 1}

   -- General description of the Directory Server application will be
   -- available in the applTable of the NETWORK-SERVICES-MIB indexed by
   -- applIndex.

    DsTableEntry ::= SEQUENCE {
        dsServerType
            BITS,
        dsServerDescription
            DisplayString,