From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2788.txt | 1235 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1235 insertions(+) create mode 100644 doc/rfc/rfc2788.txt (limited to 'doc/rfc/rfc2788.txt') diff --git a/doc/rfc/rfc2788.txt b/doc/rfc/rfc2788.txt new file mode 100644 index 0000000..4a84636 --- /dev/null +++ b/doc/rfc/rfc2788.txt @@ -0,0 +1,1235 @@ + + + + + + +Network Working Group N. Freed +Request for Comments: 2788 Innosoft +Category: Standards Track S. Kille +Obsoletes: 2248 MessagingDirect Ltd. + March 2000 + + + 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. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Introduction + + A networked application is a realization of some well-defined service + on one or more host computers that is accessible via some network, + uses some network for its internal operations, or both. + + There are a wide range of networked applications for which it is + appropriate to provide SNMP monitoring of their network usage. This + includes applications using both TCP/IP and OSI networking. 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. + + + + + + +Freed & Kille Standards Track [Page 1] + +RFC 2788 Network Services Monitoring MIB March 2000 + + + 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 either the Host Resources MIB [1] or the + application MIB [2]. + +Table of Contents + + 1 The SNMP Network Management Framework ....................... 2 + 2 Rationale for having a Network Services Monitoring MIB ...... 3 + 1 General Relationship to Other MIBs ........................ 4 + 2 Restriction of Scope ...................................... 4 + 3 Configuration Information ................................. 5 + 3 Application Objects ......................................... 5 + 4 Definitions ................................................. 5 + 5 Changes made since RFC 2248 ................................. 18 + 6 Acknowledgements ............................................ 18 + 7 References .................................................. 19 + 8 Security Considerations ..................................... 20 + 9 Author and Chair Addresses .................................. 21 + 10 Full Copyright Statement .................................... 22 + +1. The SNMP Network Management Framework + + The SNMP Management Framework presently consists of five major + components: + + o An overall architecture, described in RFC 2571 [3]. + + 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 [4], STD 16, RFC 1212 [5] and RFC 1215 [6]. The + second version, called SMIv2, is described in STD 58, RFC 2578 + [7], STD 58, RFC 2579 [8] and STD 58, RFC 2580 [9]. + + 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 [10]. A second version of the SNMP + message protocol, which is not an Internet standards track + protocol, is called SNMPv2c and described in RFC 1901 [11] and + RFC 1906 [12]. The third version of the message protocol is + called SNMPv3 and described in RFC 1906 [12], RFC 2572 [13] and + RFC 2574 [14]. + + + + + + +Freed & Kille Standards Track [Page 2] + +RFC 2788 Network Services Monitoring 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 [10]. A second set of protocol + operations and associated PDU formats is described in RFC 1905 + [15]. + + o A set of fundamental applications described in RFC 2573 [16] and + the view-based access control mechanism described in RFC 2575 + [17]. + + 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. 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). + + + + + +Freed & Kille Standards Track [Page 3] + +RFC 2788 Network Services Monitoring MIB March 2000 + + + (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. + +2.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. + +2.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. + + + + + + + +Freed & Kille Standards Track [Page 4] + +RFC 2788 Network Services Monitoring MIB March 2000 + + +2.3. Configuration Information + + This MIB attempts to provide information about the operational + aspects of an application. Further information about the actual + configuration of a given application may be kept in other places; the + applDirectoryName or applURL may be used to point to places where + such information is kept. + +3. 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 accommodated. + 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 operational + network service application 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. + +4. Definitions + + NETWORK-SERVICES-MIB DEFINITIONS ::= BEGIN + + IMPORTS + OBJECT-TYPE, Counter32, Gauge32, MODULE-IDENTITY, mib-2 + FROM SNMPv2-SMI + TimeStamp, TEXTUAL-CONVENTION + FROM SNMPv2-TC + MODULE-COMPLIANCE, OBJECT-GROUP + FROM SNMPv2-CONF + SnmpAdminString + FROM SNMP-FRAMEWORK-MIB; + + application MODULE-IDENTITY + LAST-UPDATED "200003030000Z" + ORGANIZATION "IETF Mail and Directory Management Working Group" + + + +Freed & Kille Standards Track [Page 5] + +RFC 2788 Network Services Monitoring MIB March 2000 + + + CONTACT-INFO + " Ned Freed + + Postal: Innosoft International, Inc. + 1050 Lakes Drive + West Covina, CA 91790 + US + + Tel: +1 626 919 3600 + Fax: +1 626 919 3614 + + E-Mail: ned.freed@innosoft.com" + DESCRIPTION + "The MIB module describing network service applications" + REVISION "200003030000Z" + DESCRIPTION + "This revision, published in RFC 2788, changes a number of + DisplayStrings to SnmpAdminStrings. Note that this change + is not strictly supported by SMIv2. However, the alternative + of deprecating the old objects and defining new objects + would have a more adverse impact on backward compatibility + and interoperability, given the particular semantics of + these objects. The defining reference for distinguished + names has also been updated from RFC 1779 to RFC 2253." + REVISION "199905120000Z" + DESCRIPTION + "This revision fixes a few small technical problems found + in previous versions, mostly in regards to the conformance + groups for different versions of this MIB. No changes have + been made to the objects this MIB defines since RFC 2248." + REVISION "199708170000Z" + DESCRIPTION + "This revision, published in RFC 2248, adds the + applDescription and applURL objects, adds the quiescing + state to the applOperStatus object and renames the MIB + from the APPLICATION-MIB to the NETWORK-SERVICE-MIB." + REVISION "199311280000Z" + DESCRIPTION + "The original version of this MIB was published in RFC 1565" + ::= {mib-2 27} + + -- Textual conventions + + -- DistinguishedName is used to refer to objects in the + -- directory. + + DistinguishedName ::= TEXTUAL-CONVENTION + DISPLAY-HINT "255a" + + + +Freed & Kille Standards Track [Page 6] + +RFC 2788 Network Services Monitoring MIB March 2000 + + + STATUS current + DESCRIPTION + "A Distinguished Name represented in accordance with + RFC 2253, presented in the UTF-8 charset defined in + RFC 2279." + SYNTAX OCTET STRING (SIZE (0..255)) + + -- Uniform Resource Locators are stored in URLStrings. + + URLString ::= TEXTUAL-CONVENTION + DISPLAY-HINT "255a" + STATUS current + DESCRIPTION + "A Uniform Resource Locator represented in accordance + with RFCs 1738 and 2368, presented in the NVT ASCII + charset defined in RFC 854." + SYNTAX OCTET STRING (SIZE (0..255)) + + -- The basic applTable contains a list of the application + -- entities. + + 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. + Each network service application capable of being + monitored should have a single entry in this table." + ::= {application 1} + + applEntry OBJECT-TYPE + SYNTAX ApplEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An entry associated with a single network service + application." + INDEX {applIndex} + ::= {applTable 1} + + ApplEntry ::= SEQUENCE { + applIndex + INTEGER, + applName + SnmpAdminString, + applDirectoryName + + + +Freed & Kille Standards Track [Page 7] + +RFC 2788 Network Services Monitoring MIB March 2000 + + + DistinguishedName, + applVersion + SnmpAdminString, + applUptime + TimeStamp, + applOperStatus + INTEGER, + applLastChange + TimeStamp, + applInboundAssociations + Gauge32, + applOutboundAssociations + Gauge32, + applAccumulatedInboundAssociations + Counter32, + applAccumulatedOutboundAssociations + Counter32, + applLastInboundActivity + TimeStamp, + applLastOutboundActivity + TimeStamp, + applRejectedInboundAssociations + Counter32, + applFailedOutboundAssociations + Counter32, + applDescription + SnmpAdminString, + applURL + URLString + } + + applIndex OBJECT-TYPE + SYNTAX INTEGER (1..2147483647) + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "An index to uniquely identify the network service + application. This attribute is the index used for + lexicographic ordering of the table." + ::= {applEntry 1} + + applName OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The name the network service application chooses to be + known by." + + + +Freed & Kille Standards Track [Page 8] + +RFC 2788 Network Services Monitoring MIB March 2000 + + + ::= {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 SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The version of network service application software. + This field is usually defined by the vendor of the + network service application software." + ::= {applEntry 4} + 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), + quiescing(6) + } + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "Indicates the operational status of the network service + application. 'down' indicates that the network service is + + + +Freed & Kille Standards Track [Page 9] + +RFC 2788 Network Services Monitoring MIB March 2000 + + + not available. 'up' 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 accommodated. 'restarting' + indicates that the service is currently unavailable but is + in the process of restarting and will be available soon. + 'quiescing' indicates that service is currently operational + but is in the process of shutting down. Additional inbound + associations may be rejected by applications in the + 'quiescing' state." + ::= {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} + + 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. An inbound + association occurs when another application successfully + connects to this one." + ::= {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. An outbound + association occurs when this application successfully + connects to another one." + ::= {applEntry 9} + + applAccumulatedInboundAssociations OBJECT-TYPE + + + +Freed & Kille Standards Track [Page 10] + +RFC 2788 Network Services Monitoring MIB March 2000 + + + 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." + ::= {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." + ::= {applEntry 11} + + 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. + Rejected associations are not counted in the accumulated + association totals. Note that this only counts + + + +Freed & Kille Standards Track [Page 11] + +RFC 2788 Network Services Monitoring MIB March 2000 + + + associations the application entity has rejected itself; + it does not count rejections that occur at lower layers + of the network. Thus, this counter may not reflect the + true number of failed inbound associations." + ::= {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. Failed associations are + not counted in the accumulated association totals." + ::= {applEntry 15} + + applDescription OBJECT-TYPE + SYNTAX SnmpAdminString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A text description of the application. This information + is intended to identify and briefly describe the + application in a status display." + ::= {applEntry 16} + + applURL OBJECT-TYPE + SYNTAX URLString + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A URL pointing to a description of the application. + This information is intended to identify and describe + the application in a status display." + ::= {applEntry 17} + + -- 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. + + assocTable OBJECT-TYPE + SYNTAX SEQUENCE OF AssocEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The table holding a set of all active application + + + +Freed & Kille Standards Track [Page 12] + +RFC 2788 Network Services Monitoring MIB March 2000 + + + 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 + SnmpAdminString, + 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. This attribute is the index that is + used for lexicographic ordering of the table. Note that the + table is also indexed by the applIndex." + ::= {assocEntry 1} + + assocRemoteApplication OBJECT-TYPE + SYNTAX SnmpAdminString + 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(1984) MTAs which do not have a + Distinguished Name, the RFC 2156 syntax 'mta in + + + +Freed & Kille Standards Track [Page 13] + +RFC 2788 Network Services Monitoring MIB March 2000 + + + globalid' used in X400-Received: fields can be used. Note, + however, that not all connections an MTA makes are + necessarily to another MTA." + ::= {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, OID + values of the form {applTCPProtoID port} or {applUDPProtoID + 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. The + usual IANA procedures may be used to register ports for + new protocols." + ::= {assocEntry 3} + + assocApplicationType OBJECT-TYPE + SYNTAX INTEGER { + uainitiator(1), + uaresponder(2), + peerinitiator(3), + peerresponder(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 Mail 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. MTAs and messaging gateways are + considered to be peers for the purposes of this variable." + ::= {assocEntry 4} + + 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." + + + +Freed & Kille Standards Track [Page 14] + +RFC 2788 Network Services Monitoring MIB March 2000 + + + ::= {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 obsolete + DESCRIPTION + "The compliance statement for RFC 1565 implementations + which support the Network Services Monitoring MIB + for basic monitoring of network service applications. + This is the basic compliance statement for RFC 1565." + MODULE + MANDATORY-GROUPS {applRFC1565Group} + ::= {applCompliances 1} + + assocCompliance MODULE-COMPLIANCE + STATUS obsolete + DESCRIPTION + "The compliance statement for RFC 1565 implementations + which support the Network Services Monitoring MIB + for basic monitoring of network service applications + and their associations." + MODULE + MANDATORY-GROUPS {applRFC1565Group, assocRFC1565Group} + ::= {applCompliances 2} + + applRFC2248Compliance MODULE-COMPLIANCE + STATUS deprecated + DESCRIPTION + "The compliance statement for RFC 2248 implementations + which support the Network Services Monitoring MIB + for basic monitoring of network service applications." + MODULE + MANDATORY-GROUPS {applRFC2248Group} + ::= {applCompliances 3} + + assocRFC2248Compliance MODULE-COMPLIANCE + STATUS deprecated + DESCRIPTION + "The compliance statement for RFC 2248 implementations + + + +Freed & Kille Standards Track [Page 15] + +RFC 2788 Network Services Monitoring MIB March 2000 + + + which support the Network Services Monitoring MIB for + basic monitoring of network service applications and + their associations." + MODULE + MANDATORY-GROUPS {applRFC2248Group, assocRFC2248Group} + ::= {applCompliances 4} + + applRFC2788Compliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for RFC 2788 implementations + which support the Network Services Monitoring MIB + for basic monitoring of network service applications." + MODULE + MANDATORY-GROUPS {applRFC2788Group} + ::= {applCompliances 5} + + assocRFC2788Compliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for RFC 2788 implementations + which support the Network Services Monitoring MIB for + basic monitoring of network service applications and + their associations." + MODULE + MANDATORY-GROUPS {applRFC2788Group, assocRFC2788Group} + ::= {applCompliances 6} + + + -- Units of conformance + + applRFC1565Group OBJECT-GROUP + OBJECTS { + applName, applVersion, applUptime, applOperStatus, + applLastChange, applInboundAssociations, + applOutboundAssociations, applAccumulatedInboundAssociations, + applAccumulatedOutboundAssociations, applLastInboundActivity, + applLastOutboundActivity, applRejectedInboundAssociations, + applFailedOutboundAssociations} + STATUS obsolete + DESCRIPTION + "A collection of objects providing basic monitoring of + network service applications. This is the original set + of such objects defined in RFC 1565." + ::= {applGroups 7} + + assocRFC1565Group OBJECT-GROUP + OBJECTS { + + + +Freed & Kille Standards Track [Page 16] + +RFC 2788 Network Services Monitoring MIB March 2000 + + + assocRemoteApplication, assocApplicationProtocol, + assocApplicationType, assocDuration} + STATUS obsolete + DESCRIPTION + "A collection of objects providing basic monitoring of + network service applications' associations. This is the + original set of such objects defined in RFC 1565." + ::= {applGroups 2} + + applRFC2248Group OBJECT-GROUP + OBJECTS { + applName, applVersion, applUptime, applOperStatus, + applLastChange, applInboundAssociations, + applOutboundAssociations, applAccumulatedInboundAssociations, + applAccumulatedOutboundAssociations, applLastInboundActivity, + applLastOutboundActivity, applRejectedInboundAssociations, + applFailedOutboundAssociations, applDescription, applURL} + STATUS deprecated + DESCRIPTION + "A collection of objects providing basic monitoring of + network service applications. This group was originally + defined in RFC 2248; note that applDirectoryName is + missing." + ::= {applGroups 3} + + assocRFC2248Group OBJECT-GROUP + OBJECTS { + assocRemoteApplication, assocApplicationProtocol, + assocApplicationType, assocDuration} + STATUS deprecated + DESCRIPTION + "A collection of objects providing basic monitoring of + network service applications' associations. This group + was originally defined by RFC 2248." + ::= {applGroups 4} + + applRFC2788Group OBJECT-GROUP + OBJECTS { + applName, applDirectoryName, applVersion, applUptime, + applOperStatus, applLastChange, applInboundAssociations, + applOutboundAssociations, applAccumulatedInboundAssociations, + applAccumulatedOutboundAssociations, applLastInboundActivity, + applLastOutboundActivity, applRejectedInboundAssociations, + applFailedOutboundAssociations, applDescription, applURL} + STATUS current + DESCRIPTION + "A collection of objects providing basic monitoring of + network service applications. This is the appropriate + + + +Freed & Kille Standards Track [Page 17] + +RFC 2788 Network Services Monitoring MIB March 2000 + + + group for RFC 2788 -- it adds the applDirectoryName object + missing in RFC 2248." + ::= {applGroups 5} + + assocRFC2788Group OBJECT-GROUP + OBJECTS { + assocRemoteApplication, assocApplicationProtocol, + assocApplicationType, assocDuration} + STATUS current + DESCRIPTION + "A collection of objects providing basic monitoring of + network service applications' associations. This is + the appropriate group for RFC 2788." + ::= {applGroups 6} + + -- 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 + +5. Changes made since RFC 2248 + + This revision corrects a few minor technical errors in the + construction of the network services MIB in RFC 2248 [22]. In + addition, the applName, applVersion, and applDescription fields have + been changed from DisplayStrings to SnmpAdminStrings. The reference + to RFC 1779 has also been updated to RFC 2253, which in turn adds the + ability for distinguished names to be in the UTF-8 character set. + +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. The Electronic + Mail Association's TSC committee was instrumental in providing + feedback on and suggesting enhancements to RFC 1565 [23] that have + led to the present document. + + + + + +Freed & Kille Standards Track [Page 18] + +RFC 2788 Network Services Monitoring MIB March 2000 + + +9. References + + [1] Grillo, P. and S. Waldbusser, "Host Resources MIB", RFC 1514, + September 1993. + + [2] Krupczak, C. and J. Saperia, "Definitions of System-Level + Managed Objects for Applications", RFC 2287, February 1998. + + [3] Wijnen, B., Harrington, D. and R. Presuhn, "An Architecture for + Describing SNMP Management Frameworks", RFC 2571, April 1999. + + [4] Rose, M. and K. McCloghrie, "Structure and Identification of + Management Information for TCP/IP-based Internets", STD 16, RFC + 1155, May 1990. + + [5] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, + RFC 1212, March 1991. + + [6] Rose, M., "A Convention for Defining Traps for use with the + SNMP", RFC 1215, March 1991. + + [7] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of + Management Information Version 2 (SMIv2)", STD 58, RFC 2578, + April 1999. + + [8] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual + Conventions for SMIv2", STD 58, RFC 2579, April 1999. + + [9] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance + Statements for SMIv2", STD 58, RFC 2580, April 1999. + + [10] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple + Network Management Protocol", STD 15, RFC 1157, May 1990. + + [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, + "Introduction to Community-based SNMPv2", RFC 1901, January + 1996. + + [12] 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. + + [13] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message + Processing and Dispatching for the Simple Network Management + Protocol (SNMP)", RFC 2572, April 1999. + + + + + + +Freed & Kille Standards Track [Page 19] + +RFC 2788 Network Services Monitoring MIB March 2000 + + + [14] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) + for version 3 of the Simple Network Management Protocol + (SNMPv3)", RFC 2574, April 1999. + + [15] 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. + + [16] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC + 2573, April 1999. + + [17] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access + Control Model (VACM) for the Simple Network Management Protocol + (SNMP)", RFC 2575, April 1999. + + [18] Wahl, M., Kille, S. and T.Howes, "Lightweight Directory Access + Protocol (v3): UTF-8 String Representation of Distinguished + Names", RFC 2253, December 1997. + + [19] Kille, S., "Mapping between X.400(1988) and RFC 822/MIME", RFC + 2156, January 1998. + + [20] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource + Locators (URL)", RFC 1738, December 1994. + + [21] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL + Scheme", RFC 2368, July 1998. + + [22] Freed, N. and S. Kille, "Network Services Monitoring MIB", RFC + 2248, January 1998. + + [23] Freed, N. and Kille, "Network Services Monitoring MIB", RFC + 1565, January 1994. + + [29] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD + 8, RFC 854, RFC 855, May 1983. + +8. Security Considerations + + 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 is + implemented correctly, then there is no risk that an intruder can + alter or create any management objects of this MIB via direct SNMP + SET operations. + + + + + + + +Freed & Kille Standards Track [Page 20] + +RFC 2788 Network Services Monitoring MIB March 2000 + + + However, this MIB does provide passive information about the + existence, type, and configuration of applications on a given host + that could potentially indicate some sort of vulnerability. Finally, + the information MIB provides about network usage could be used to + analyze network traffic patterns. + + 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 [14] and the View-based + Access Control Model RFC 2575 [17] is recommended. + + 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. + +9. Author and Chair Addresses + + Ned Freed + Innosoft International, Inc. + 1050 Lakes Drive + West Covina, CA 91790 + USA + + Phone: +1 626 919 3600 + Fax: +1 626 919 3614 + EMail: ned.freed@innosoft.com + + + Steve Kille, MADMAN WG Chair + MessagingDirect Ltd. + The Dome, The Square + Richmond TW9 1DT + UK + + Phone: +44 20 8332 9091 + EMail: Steve.Kille@MessagingDirect.com + + + + + + + + +Freed & Kille Standards Track [Page 21] + +RFC 2788 Network Services Monitoring MIB March 2000 + + +10. 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. + + + + + + + + + + + + + + + + + + + +Freed & Kille Standards Track [Page 22] + -- cgit v1.2.3