As per Relevance of the word monitoring, we have this rfc below:
Network Working Group G.
Request for Comments: 2605 Cyber Solutions Inc
Obsoletes: 1567 S.
Category: Standards Track MessagingDirect Ltd
June 1999
Directory Server Monitoring
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
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".
memo extends that specification to a more generic MIB for
one or more directory servers each of which may support
access protocols. The MIB defined in this memo will be used
conjunction with the NETWORK-SERVICES-MIB [19] for
Directory Servers
Table of
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
The SNMP Network Management Framework presently consists of
major components
o An overall architecture, described in RFC 2571 [1].
o Mechanisms for describing and naming objects and events for
purpose of management. The first version of this Structure
Management Information (SMI) is called SMIv1 and described
STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4].
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.
first version of the SNMP message protocol is called SNMPv1
described in STD 15, RFC 1157 [8]. A second version of the
message protocol, which is not an Internet standards
protocol, is called SNMPv2c and described in RFC 1901 [9]
RFC 1906 [10]. The third version of the message protocol
called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11]
RFC 2574 [12].
o Protocol operations for accessing management information.
first set of protocol operations and associated PDU formats
described in STD 15, RFC 1157 [8]. A second set of
operations and associated PDU formats is described in RFC 1905
[13].
o A set of fundamental applications described in RFC 2573 [14]
the view-based access control mechanism described in RFC 2575
[15].
Managed objects are accessed via a virtual information store,
the Management Information Base or MIB. Objects in the MIB
defined using the mechanisms defined in the SMI
This memo specifies a MIB module that is compliant to the SMIv2.
MIB conforming to the SMIv1 can be produced through the
translations. The resulting translated MIB must be
equivalent, except where objects or events are omitted because
translation is possible (use of Counter64). Some machine
information in SMIv2 will be converted into textual descriptions
SMIv1 during the translation process. However, this loss of
readable information is not considered to change the semantics of
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
Directory which maybe local or distributed, by the Directory Servers
The server maybe a X.500 Directory System Agent (DSA) [16]
over the OSI suite of protocols or, a (C)LDAP[17,18] frontend to
X.500 Directory System Agent or, a native LDAP Directory
running directly over TCP or other protocols, or a database acting
a backend to another server, or any other application protocol,
any combination of the above. A Directory Server has one or
application protocol interfaces. Through these interfaces
Directory Server interacts with the DUA and with the peer
Servers
Fig. 1 shows the case of a Directory Server that receives
and sends back responses in some protocol. Fig. 2 shows one
scenario where the Directory Server speaks multiple protocols
+----------------+
| |
| Directory | Directory
| Server X-------->
| |
| |
+----------------+
FIG. 1.
+----------------+
| |
DSP <----------X X-------->
| Directory |
Other | Server |
Protocol <----------X X-------->
| |
+----------------+
FIG. 2.
The Directory contains information in the form of entries. An
is a collection of attributes and is uniquely identified by a name
the Distinguished Name (DN). The entries are arranged in
hierarchical tree-like structure called the Directory
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
Directory. The Directory Server is responsible for performing
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
or interact with (chain the request to) other Directory Servers
service the DUA request. Alternatively, a Directory Server may
a reference to another Directory Server (referral).
The local database of a Directory Server consists of the part of
Directory that is mastered by the Directory Server, the part of
Directory for which it keeps slave copies and cached information
is gathered during the operation of the Directory Server
In the connection oriented mode a DUA "binds" to a Directory
with a particular identification. The Directory Server
authenticate the identity of the DUA. In the connectionless mode
is employed in CLDAP no binding and/or authentication is carried
between the DUA and the Directory Server. The following type
operations are carried out by the Directory Server : Read, Compare
Addition of an Entry (AddEntry), Modification of an
(ModifyEntry), Modification of a DN (ModifyRDN), Deletion of an
(RemoveEntry), List, Search, Abandon. Some Directory Servers do
support some type of operations. For example CLDAP does not
AddEntry, ModifyEntry, ModifyRDN, RemoveEntry etc. In response
requests results and/or errors are returned by the Directory Server
In the distributed Directory data is often replicated to
performance and for other advantages. The data to be replicated
transferred from the "Supplier" Directory Server to the "Consumer
Directory Server according to the replication agreement between
supplier and the receiver
3. MIB Model for Directory Management
A Directory manager should be able to monitor all the
Servers in his/her domain of management. The Directory Servers may
running on one or more hosts and, multiple Directory Servers may
running on the same host
The manager may wish to monitor several aspects of the
Directory Servers. He/she may want to know the process
aspects - the resource utilization of an operational
Server; the network service related aspects e.g. inbound
associations, outbound-associations, operational status, and
the information specific to the Directory Server application -
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
to Directory services. The network service related part of the MIB
and the host-resources related part of the MIB, as well as
parts of interest to a Manager monitoring the Directory services,
covered in separate documents [19] [20].
The MIB will cover a group of Directory Servers. The grouping will
done on some logical basis by the administrator/manager. In
cases, the grouping will be reflected in the pertinent NETWORK
SERVICES-MIB which will have an entry corresponding to each
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
- dsTable, dsApplIfOpsTable, and dsIntTable
- The dsTable contains a list of Directory Servers. The
contains a description of the Directory Servers as well
summary statistics on the entries held by and the
performance of each Directory Server. The group of servers
this list is likely to contain a part of, if not all,
Directory Servers in the management domain
- The dsApplIfOpsTable provides summary statistics on
accesses, operations and errors for each application
interface of a Directory Server
- The dsIntTable provides some useful information on
interaction of the monitored Directory Servers with
Directory Servers
There are references to the Directory itself for static
pertaining to the Directory Server. These references are in the
of "Directory Distinguished Name" [21] of the corresponding object
It is intended that Directory management applications will use
references to obtain further information on the objects of interest
5. The Directory Server Monitoring MIB
DIRECTORY-SERVER-MIB DEFINITIONS ::=
MODULE-IDENTITY, Counter32, Gauge32, OBJECT-
FROM SNMPv2-
mib-2 FROM RFC1213-
DisplayString,
Mansfield & Kille Standards Track [Page 5]
RFC 2605 Directory Server Monitoring MIB June 1999
FROM SNMPv2-
MODULE-COMPLIANCE, OBJECT-
FROM SNMPv2-
ZeroBasedCounter32
FROM RMON2-
applIndex, DistinguishedName,
FROM NETWORK-SERVICES-MIB
dsMIB MODULE-
LAST-UPDATED "9906070000Z
ORGANIZATION "IETF Mail and Directory Management
Group
CONTACT-
" Glenn
Postal: Cyber Solutions Inc
6-6-3, Minami
Aoba-ku, Sendai, Japan 989-3204.
Tel: +81-22-303-4012
Fax: +81-22-303-4015
E-mail: glenn@cysols.
Working Group E-mail: ietf-madman@innosoft.
To subscribe: ietf-madman-request@innosoft.com
" The MIB module for monitoring Directory Services."
-- revision
REVISION "9906070000Z
"This revision of this MIB is published in RFC 2605.
This revision obsoletes RFC 1567. It is incompatible
the original MIB and so it has been renamed from
to dsMIB."
REVISION "9311250000Z" -- 25th November 1993
"The original version of this MIB was published in RFC 1567."
::= { mib-2 66 }
dsTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
Mansfield & Kille Standards Track [Page 6]
RFC 2605 Directory Server Monitoring MIB June 1999
" The table holding information related to the
Servers."
::= {dsMIB 1}
dsTableEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
" Entry containing summary description for a
Server."
INDEX { applIndex }
::= {dsTable 1}
-- General description of the Directory Server application will
-- available in the applTable of the NETWORK-SERVICES-MIB indexed
-- applIndex
DsTableEntry ::= SEQUENCE {
BITS
DisplayString
-- Entry statistics/Cache
Gauge32,
Gauge32,
Gauge32,
Counter32,
Counter32
}
dsServerType OBJECT-
SYNTAX BITS {
frontEndDirectoryServer(0),
backEndDirectoryServer(1)
}
MAX-ACCESS read-
STATUS
"This object indicates whether the server
a frontend or, a backend or, both. If the
is a frontend, then the
Mansfield & Kille Standards Track [Page 7]
RFC 2605 Directory Server Monitoring MIB June 1999
bit will be set. Similarly for the backend."
::= {dsTableEntry 1}
dsServerDescription OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
"A text description of the application. This
is intended to identify and briefly describe
application in a status display."
::= {dsTableEntry 2}
-- A (C)LDAP frontend to the X.500 Directory will not
-- MasterEntries, CopyEntries; the following counters
-- be inaccessible for LDAP/CLDAP frontends to the X.500
-- directory: dsMasterEntries, dsCopyEntries, dsSlaveHits
dsMasterEntries OBJECT-
SYNTAX Gauge32
MAX-ACCESS read-
STATUS
" Number of entries mastered in the Directory Server."
::= {dsTableEntry 3}
dsCopyEntries OBJECT-
SYNTAX Gauge32
MAX-ACCESS read-
STATUS
" Number of entries for which systematic (slave
copies are maintained in the Directory Server."
::= {dsTableEntry 4}
dsCacheEntries OBJECT-
SYNTAX Gauge32
MAX-ACCESS read-
STATUS
" Number of entries cached (non-systematic copies)
the Directory Server. This will include the entries
are cached partially. The negative cache is not counted."
::= {dsTableEntry 5}
dsCacheHits OBJECT-
SYNTAX Counter32
Mansfield & Kille Standards Track [Page 8]
RFC 2605 Directory Server Monitoring MIB June 1999
MAX-ACCESS read-
STATUS
" Number of operations that were serviced
the locally held cache."
::= {dsTableEntry 6}
dsSlaveHits OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
" Number of operations that were serviced
the locally held object replications ( copy
entries)."
::= {dsTableEntry 7}
dsApplIfOpsTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
" The table holding information related to
Directory Server operations."
::= {dsMIB 2}
dsApplIfOpsEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
" Entry containing operations related
for a Directory Server."
INDEX { applIndex, dsApplIfProtocolIndex }
::= {dsApplIfOpsTable 1}
DsApplIfOpsEntry ::= SEQUENCE {
INTEGER
OBJECT IDENTIFIER
--
Counter32,
Counter32,
Mansfield & Kille Standards Track [Page 9]
RFC 2605 Directory Server Monitoring MIB June 1999
Counter32,
Counter32,
-- In-coming
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
Counter32,
-- Out going
Counter32,
Counter32,
--
Counter32,
Counter32,
--
Counter32,
Mansfield & Kille Standards Track [Page 10]
RFC 2605 Directory Server Monitoring MIB June 1999
Counter32,
-- Traffic
Counter32,
Counter32
}
-- CLDAP does not use binds; for the CLDAP interface of a
-- Server the bind related counters will be inaccessible
--
-- CLDAP and LDAP implement "Read" and "List"
-- indirectly via the "search" operation; the
-- counters will be inaccessible for the CLDAP and LDAP interfaces
-- Directory Servers: dsApplIfReadOps,
--
-- CLDAP does not implement "Compare", "Add", "Remove",
-- "Modify", "ModifyRDN"; the following counters will
-- inaccessible for the CLDAP interfaces of Directory Servers
-- dsApplIfCompareOps, dsApplIfAddEntryOps, dsApplIfRemoveEntryOps
-- dsApplIfModifyEntryOps, dsApplIfModifyRDNOps
--
-- CLDAP Directory Servers do not return
-- the following fields will remain inaccessible
-- CLDAP interfaces of Directory Servers: dsApplIfReferrals
dsApplIfProtocolIndex OBJECT-
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS read-
STATUS
"An index to uniquely identify an entry corresponding to
application-layer protocol interface. This index is
for lexicographic ordering of the table."
::= {dsApplIfOpsEntry 1}
dsApplIfProtocol OBJECT-
SYNTAX OBJECT
MAX-ACCESS read-
STATUS
"An identification of the protocol being used by the
on this interface. For an OSI Application, this will be
Application Context. For Internet applications, the
maintains a registry[22] of the OIDs which correspond
Mansfield & Kille Standards Track [Page 11]
RFC 2605 Directory Server Monitoring MIB June 1999
well-known applications. If the application protocol
not listed in the registry, an OID value of the
{applTCPProtoID port} or {applUDProtoID port} are used
TCP-based and UDP-based protocols, respectively. In
case 'port' corresponds to the primary port number
used by the protocol. The OIDs applTCPProtoID
applUDPProtoID are defined in NETWORK-SERVICES-MIB
::= {dsApplIfOpsEntry 2}
dsApplIfUnauthBinds OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
" Number of unauthenticated/anonymous bind
received."
::= {dsApplIfOpsEntry 3}
dsApplIfSimpleAuthBinds OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
" Number of bind requests that were
using simple authentication procedures like
checks. This includes
password authentication using SASL mechanisms
CRAM-MD5."
::= {dsApplIfOpsEntry 4}
dsApplIfStrongAuthBinds OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
" Number of bind requests that were
using TLS and X.500 strong authentication procedures
This includes the binds that
authenticated using external authentication procedures."
::= {dsApplIfOpsEntry 5}
dsApplIfBindSecurityErrors OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
" Number of bind requests that have been
due to inappropriate authentication
Mansfield & Kille Standards Track [Page 12]
RFC 2605 Directory Server Monitoring MIB June 1999
invalid credentials."
::= {dsApplIfOpsEntry 6}
dsApplIfInOps OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
" Number of requests received from DUAs or
Directory Servers."
::= {dsApplIfOpsEntry 7}
dsApplIfReadOps OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
" Number of read requests received."
::= {dsApplIfOpsEntry 8}
dsApplIfCompareOps OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
" Number of compare requests received."
::= {dsApplIfOpsEntry 9}
dsApplIfAddEntryOps OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
" Number of addEntry requests received."
::= {dsApplIfOpsEntry 10}
dsApplIfRemoveEntryOps OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
" Number of removeEntry requests received."
::= {dsApplIfOpsEntry 11}
dsApplIfModifyEntryOps OBJECT-
Mansfield & Kille Standards Track [Page 13]
RFC 2605 Directory Server Monitoring MIB June 1999
SYNTAX Counter32
MAX-ACCESS read-
STATUS
" Number of modifyEntry requests received."
::= {dsApplIfOpsEntry 12}
dsApplIfModifyRDNOps OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
" Number of modifyRDN requests received."
::= {dsApplIfOpsEntry 13}
dsApplIfListOps OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
" Number of list requests received."
::= {dsApplIfOpsEntry 14}
dsApplIfSearchOps OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
" Number of search requests- baseObject searches
oneLevel searches and whole subtree searches
received."
::= {dsApplIfOpsEntry 15}
dsApplIfOneLevelSearchOps OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
" Number of oneLevel search requests received."
::= {dsApplIfOpsEntry 16}
dsApplIfWholeSubtreeSearchOps OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
Mansfield & Kille Standards Track [Page 14]
RFC 2605 Directory Server Monitoring MIB June 1999
" Number of whole subtree search requests received."
::= {dsApplIfOpsEntry 17}
dsApplIfReferrals OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
" Number of referrals returned in
to requests for operations."
::= {dsApplIfOpsEntry 18}
dsApplIfChainings OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
" Number of operations forwarded by this Directory
to other Directory Servers."
::= {dsApplIfOpsEntry 19}
dsApplIfSecurityErrors OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
" Number of requests
which did not meet the security requirements. "
::= {dsApplIfOpsEntry 20}
dsApplIfErrors OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
" Number of requests that could not be
due to errors other than security errors,
referrals
A partially serviced operation will not be
as an error
The errors include naming-related, update-related
attribute-related and service-related errors."
::= {dsApplIfOpsEntry 21}
-- Replication
dsApplIfReplicationUpdatesIn OBJECT-
Mansfield & Kille Standards Track [Page 15]
RFC 2605 Directory Server Monitoring MIB June 1999
SYNTAX Counter32
MAX-ACCESS read-
STATUS
" Number of replication updates fetched or received
supplier Directory Servers."
::= {dsApplIfOpsEntry 22}
dsApplIfReplicationUpdatesOut OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
" Number of replication updates sent to or taken
consumer Directory Servers."
::= {dsApplIfOpsEntry 23}
dsApplIfInBytes OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
" Incoming traffic, in bytes, on the interface
This will include requests from DUAs as
as responses from other Directory Servers."
::= {dsApplIfOpsEntry 24}
dsApplIfOutBytes OBJECT-
SYNTAX Counter32
MAX-ACCESS read-
STATUS
" Outgoing traffic in bytes on the interface
This will include responses to DUAs and
Servers as well as requests to other Directory Servers."
::= {dsApplIfOpsEntry 25}
-- The dsIntTable contains statistical data on the
-- Directory Servers with which the monitored
-- Server interacts or, attempts to interact. This table
-- expected to provide a useful insight into the effect
-- neighbours on the Directory Server's performance
-- The table keeps track of the last "N" Directory
-- with which the monitored Directory has
-- (attempted to interact), where "N" is a locally-
-- constant
-- For a multiprotocol server, statistics for each
Mansfield & Kille Standards Track [Page 16]
RFC 2605 Directory Server Monitoring MIB June 1999
-- are kept separetely
dsIntTable OBJECT-
SYNTAX SEQUENCE OF
MAX-ACCESS not-
STATUS
" Each row of this table contains some
related to the history of the
of the monitored Directory Server with
peer Directory Servers."
::= { dsMIB 3 }
dsIntEntry OBJECT-
SYNTAX
MAX-ACCESS not-
STATUS
" Entry containing interaction details of a
Server with a peer Directory Server."
INDEX { applIndex,dsIntEntIndex, dsApplIfProtocolIndex }
::= { dsIntTable 1 }
DsIntEntry ::= SEQUENCE {
INTEGER
DistinguishedName
TimeStamp
TimeStamp
TimeStamp
Gauge32,
ZeroBasedCounter32,
ZeroBasedCounter32,
}
dsIntEntIndex OBJECT-
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS not-
STATUS
Mansfield & Kille Standards Track [Page 17]
RFC 2605 Directory Server Monitoring MIB June 1999
" Together with applIndex and dsApplIfProtocolIndex,
object forms the unique key
identify the conceptual row which contains useful
on the (attempted) interaction between the
Server (referred to by applIndex) and a peer
Server using a particular protocol."
::= {dsIntEntry 1}
dsIntEntDirectoryName OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
" Distinguished Name of the peer Directory Server
which this entry pertains."
::= {dsIntEntry 2}
dsIntEntTimeOfCreation OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
" The value of sysUpTime when this row was created
If the entry was created before the network
subsystem was initialized, this object will
a value of zero."
::= {dsIntEntry 3}
dsIntEntTimeOfLastAttempt OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
" The value of sysUpTime when the last attempt was
to contact the peer Directory Server. If the last
was made before the network management subsystem
initialized, this object will contain a value of zero."
::= {dsIntEntry 4}
dsIntEntTimeOfLastSuccess OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
" The value of sysUpTime when the last attempt made
contact the peer Directory Server was successful. If
have been no successful attempts this entry will have a
Mansfield & Kille Standards Track [Page 18]
RFC 2605 Directory Server Monitoring MIB June 1999
of zero. If the last successful attempt was made
the network management subsystem was initialized,
object will contain a value of zero."
::= {dsIntEntry 5}
dsIntEntFailuresSinceLastSuccess OBJECT-
SYNTAX Gauge32
MAX-ACCESS read-
STATUS
" The number of failures since the last time
attempt to contact the peer Directory Server was successful
If there have been no successful attempts, this
will contain the number of failures since this
was created."
::= {dsIntEntry 6}
-- note this gauge has a maximum value of 4294967295 and
-- it does not wrap.[5]
dsIntEntFailures OBJECT-
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-
STATUS
" Cumulative failures in contacting the peer Directory
since the creation of this entry."
::= {dsIntEntry 7}
dsIntEntSuccesses OBJECT-
SYNTAX ZeroBasedCounter32
MAX-ACCESS read-
STATUS
" Cumulative successes in contacting the peer Directory
since the creation of this entry."
::= {dsIntEntry 8}
dsIntEntURL OBJECT-
SYNTAX
MAX-ACCESS read-
STATUS
" URL of the peer Directory Server."
::= {dsIntEntry 9}
-- Conformance
Mansfield & Kille Standards Track [Page 19]
RFC 2605 Directory Server Monitoring MIB June 1999
dsConformance OBJECT IDENTIFIER ::= { dsMIB 4 }
dsGroups OBJECT IDENTIFIER ::= { dsConformance 1 }
dsCompliances OBJECT IDENTIFIER ::= { dsConformance 2 }
-- Compliance
dsEntryCompliance MODULE-
STATUS
"The compliance statement for SNMP
which implement the DIRECTORY-SERVER-MIB
a summary overview of the Directory Servers ."
MODULE -- this
MANDATORY-GROUPS { dsEntryGroup }
::= { dsCompliances 1 }
dsOpsCompliance MODULE-
STATUS
"The compliance statement for SNMP
which implement the DIRECTORY-SERVER-MIB for
Directory Server operations, entry statistics and
performance."
MODULE -- this
MANDATORY-GROUPS { dsEntryGroup, dsOpsGroup }
::= { dsCompliances 2 }
dsIntCompliance MODULE-
STATUS
" The compliance statement for SNMP
which implement the DIRECTORY-SERVER-MIB
monitoring Directory Server operations and
interaction of the Directory Server with
Directory Servers."
MODULE -- this
MANDATORY-GROUPS { dsEntryGroup, dsIntGroup }
::= { dsCompliances 3 }
dsOpsIntCompliance MODULE-
STATUS
Mansfield & Kille Standards Track [Page 20]
RFC 2605 Directory Server Monitoring MIB June 1999
" The compliance statement for SNMP
which implement the DIRECTORY-SERVER-MIB for
Directory Server operations and the interaction of
Directory Server with peer Directory Servers."
MODULE -- this
MANDATORY-GROUPS { dsEntryGroup, dsOpsGroup, dsIntGroup }
::= { dsCompliances 4 }
-- Units of
dsEntryGroup OBJECT-
OBJECTS {dsServerType, dsServerDescription
dsMasterEntries, dsCopyEntries
dsCacheEntries, dsCacheHits
dsSlaveHits
STATUS
" A collection of objects for a summary overview of
Directory Servers."
::= { dsGroups 1 }
dsOpsGroup OBJECT-
OBJECTS {
dsApplIfProtocolIndex, dsApplIfProtocol
dsApplIfUnauthBinds, dsApplIfSimpleAuthBinds
dsApplIfStrongAuthBinds, dsApplIfBindSecurityErrors
dsApplIfInOps, dsApplIfReadOps
dsApplIfCompareOps, dsApplIfAddEntryOps
dsApplIfRemoveEntryOps, dsApplIfModifyEntryOps
dsApplIfModifyRDNOps, dsApplIfListOps
dsApplIfSearchOps, dsApplIfOneLevelSearchOps
dsApplIfWholeSubtreeSearchOps, dsApplIfReferrals
dsApplIfChainings, dsApplIfSecurityErrors
dsApplIfErrors, dsApplIfReplicationUpdatesIn
dsApplIfReplicationUpdatesOut, dsApplIfInBytes
dsApplIfOutBytes }
STATUS
" A collection of objects for monitoring the
Server operations."
::= { dsGroups 2 }
dsIntGroup OBJECT-
OBJECTS {
Mansfield & Kille Standards Track [Page 21]
RFC 2605 Directory Server Monitoring MIB June 1999
dsIntEntDirectoryName, dsIntEntTimeOfCreation
dsIntEntTimeOfLastAttempt, dsIntEntTimeOfLastSuccess
dsIntEntFailuresSinceLastSuccess, dsIntEntFailures
dsIntEntSuccesses, dsIntEntURL
STATUS
" A collection of objects for monitoring the
Server's interaction with peer Directory Servers."
::= { dsGroups 3 }
6. Intellectual
The IETF takes no position regarding the validity or scope of
intellectual property or other rights that might be claimed
pertain to the implementation or use of the technology described
this document or the extent to which any license under such
might or might not be available; neither does it represent that
has made any effort to identify any such rights. Information on
IETF's procedures with respect to rights in standards-track
standards-related documentation can be found in BCP-11. Copies
claims of rights made available for publication and any assurances
licenses to be made available, or the result of an attempt made
obtain a general license or permission for the use of
proprietary rights by implementors or users of this specification
be obtained from the IETF Secretariat
The IETF invites any interested party to bring to its attention
copyrights, patents or patent applications, or other
rights which may cover technology that may be required to
this standard. Please address the information to the IETF
Director
7. Changes from RFC1567.
A more general Directory model in which, several Directory
coexist, has been adopted for the purpose of the MIB design.
result is a generic Directory Server Monitoring MIB
8.
This memo is the product of discussions and deliberations carried
in the Mail and Directory Management Working Group (ietf-madman-wg).
Mansfield & Kille Standards Track [Page 22]
RFC 2605 Directory Server Monitoring MIB June 1999
[1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture
Describing SNMP Management Frameworks", RFC 2571, April 1999.
[2] Rose, M. and K. McCloghrie, "Structure and Identification
Management Information for TCP/IP-based Internets", STD 16,
1155, May 1990.
[3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
RFC 1212, March 1991.
[4] Rose, M., "A Convention for Defining Traps for use with
SNMP", RFC 1215, March 1991.
[5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose
M. and S. Waldbusser, "Structure of Management
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose
M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
RFC 2579, April 1999.
[7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose
M. and S. Waldbusser, "Conformance Statements for SMIv2",
58, RFC 2580, April 1999.
[8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "
Network Management Protocol", STD 15, RFC 1157, May 1990.
[9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser
"Introduction to Community-based SNMPv2", RFC 1901,
1996.
[10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "
Mappings for Version 2 of the Simple Network Management
(SNMPv2)", RFC 1906, January 1996.
[11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "
Processing and Dispatching for the Simple Network
Protocol (SNMP)", RFC 2572, April 1999.
[12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM
for version 3 of the Simple Network Management
(SNMPv3)", RFC 2574, April 1999.
Mansfield & Kille Standards Track [Page 23]
RFC 2605 Directory Server Monitoring MIB June 1999
[13] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "
Operations for Version 2 of the Simple Network
Protocol (SNMPv2)", RFC 1905, January 1996.
[14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications",
2573, April 1999.
[15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
Control Model (VACM) for the Simple Network Management
(SNMP)", RFC 2575, April 1999.
[16] ITU-T Rec. X.501, "The Directory: Models", 1993.
[17] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Protocol (v3)", RFC 2251, December 1997.
[18] Young, A., "Connection-less Lightweight X.500 Directory
Protocol", RFC 1798, June 1995.
[19] Freed N. and Kille, S., "Network Services Monitoring MIB",
2248, January 1998.
[20] Grillo, P. and S. Waldbusser, "Host Resources MIB", RFC 1514,
September 1993.
[21] Wahl, W., Kille, S. and T. Howes, "Lightweight Directory
Protocol (v3): UTF-8 String Representation of
Names", RFC 2253, December 1997.
[22] http://www.isi.edu/in-notes/iana/assignments/protocol-
Security
There are no management objects defined in this MIB that have a MAX
ACCESS clause of read-write and/or read-create. So, if this MIB
implemented correctly, then there is no risk that an intruder
alter or create any management objects of this MIB via direct
SET operations
However, the information itself may partly reveal the
of the directory system and passively increase its vulnerability.
information could also be used to analyze network usage and
patterns
Therefore, it may be important in some environments to control
access to these objects and possibly to even encrypt the values
these object when sending them over the network via SNMP. Not
versions of SNMP provide features for such a secure environment
Mansfield & Kille Standards Track [Page 24]
RFC 2605 Directory Server Monitoring MIB June 1999
SNMPv1 by itself is such an insecure environment. Even if
network itself is secure (for example by using IPSec), even then
there is no control as to who on the secure network is allowed
access and GET (read) the objects in this MIB
It is recommended that the implementors consider the
features as provided by the SNMPv3 framework. Specifically, the
of the User-based Security Model RFC 2574 [12] and the View-
Access Control Model RFC 2575 [15] is recommended
It is then a customer/user responsibility to ensure that the
entity giving access to an instance of this MIB, is
configured to give access to those objects only to those
(users) that have legitimate rights to access them
Authors'
Glenn
Cyber Solutions Inc
6-6-3 Minami
Aoba-ku, Sendai 989-3204
Phone: +81-22-303-4012
EMail: glenn@cysols.
Steve E.
MessagingDirect Ltd
The Dome, The
Richmond TW9 1
Phone: +44-181-332-9091
EMail: Steve.Kille@MessagingDirect.
Mansfield & Kille Standards Track [Page 25]
RFC 2605 Directory Server Monitoring MIB June 1999
Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Mansfield & Kille Standards Track [Page 26]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
