idnits 2.17.1 draft-ietf-madman-nsm-mib-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 88 has weird spacing: '...defines trans...' == Line 755 has weird spacing: '...ntal in provi...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1997) is 9903 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1902 (ref. '1') (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (ref. '2') (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (ref. '3') (Obsoleted by RFC 2580) ** Obsolete normative reference: RFC 1905 (ref. '4') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1906 (ref. '5') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 1907 (ref. '6') (Obsoleted by RFC 3418) ** Obsolete normative reference: RFC 1908 (ref. '7') (Obsoleted by RFC 2576) ** Obsolete normative reference: RFC 1779 (ref. '8') (Obsoleted by RFC 2253, RFC 3494) ** Obsolete normative reference: RFC 1327 (ref. '9') (Obsoleted by RFC 2156) ** Obsolete normative reference: RFC 1738 (ref. '10') (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1565 (ref. '11') (Obsoleted by RFC 2248) Summary: 21 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Ned Freed 3 Internet Draft 5 Network Services Monitoring MIB 7 March 1997 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups may also distribute working 14 documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months. 17 Internet-Drafts may be updated, replaced, or obsoleted by other 18 documents at any time. It is not appropriate to use Internet-Drafts as 19 reference material or to cite them other than as a "working draft" or 20 "work in progress". 22 To learn the current status of any Internet-Draft, please check the 23 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 25 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 27 1. Introduction 29 A networked application is a realization of some well defined service on 30 one or more host computers that is accessible via some network, uses 31 some network for its internal operations, or both. 33 There are a wide range of networked applications for which it is 34 appropriate to provide SNMP monitoring of their network usage. This 35 includes applications using both TCP/IP and OSI networking. This 36 document defines a MIB which contains the elements common to the 37 monitoring of any network service application. This information 38 includes a table of all monitorable network service applications, a 39 count of the associations (connections) to each application, and basic 40 information about the parameters and status of each application-related 41 association. 43 This MIB may be used on its own for any application, and for most simple 44 applications this will suffice. This MIB is also designed to serve as a 45 building block which can be used in conjunction with application- 46 specific monitoring and management. Two examples of this are MIBs 47 defining additional variables for monitoring a Message Transfer Agent 48 (MTA) service or a Directory Service Agent (DSA) service. It is expected 49 that further MIBs of this nature will be specified. 51 This MIB does not attempt to provide facilities for management of the 52 host or hosts the network service application runs on, nor does it 53 provide facilities for monitoring applications that provide something 54 other than a network service. Host resource and general application 55 monitoring is handled by the Host Resources MIB at present; development 56 of an additional application MIB is currently underway in the IETF. 58 2. Table of Contents 60 1 Introduction .................................................... 1 61 2 Table of Contents ............................................... 2 62 3 The SNMPv2 Network Management Framework ......................... 2 63 3.1 Object Definitions ............................................ 3 64 4 Rationale for having a Network Services Monitoring MIB .......... 3 65 4.1 General Relationship to Other MIBs ............................ 4 66 4.2 Restriction of Scope .......................................... 4 67 4.3 Relationship to Directory Services ............................ 5 68 5 Application Objects ............................................. 6 69 6 Definitions ..................................................... 6 70 7 Changes made since RFC 1565 ..................................... 20 71 8 Acknowledgements ................................................ 21 72 9 References ...................................................... 21 73 10 Security Considerations ........................................ 22 74 11 Author and Chair Addresses ..................................... 22 76 3. The SNMPv2 Network Management Framework 78 The SNMPv2 Network Management Framework consists of seven major 79 components. They are: 81 o RFC 1902 [1] which defines the SMI, the mechanisms used for 82 describing and naming objects for the purpose of management. 84 o RFC 1903 [2] defines textual conventions for SNMPv2. 86 o RFC 1904 [3] defines conformance statements for SNMPv2. 88 o RFC 1905 [4] defines transport mappings for SNMPv2. 90 o RFC 1906 [5] defines the protocol operations used for network 91 access to managed objects. 93 o RFC 1907 [6] defines the Management Information Base for SNMPv2. 95 o RFC 1908 [7] specifies coexistance between SNMP and SNMPv2. 97 The Framework permits new objects to be defined for the purpose of 98 experimentation and evaluation. 100 3.1. Object Definitions 102 Managed objects are accessed via a virtual information store, termed the 103 Management Information Base or MIB. Objects in the MIB are defined using 104 the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. 105 In particular, each object type is named by an OBJECT IDENTIFIER, an 106 administratively assigned name. The object type together with an object 107 instance serves to uniquely identify a specific instantiation of the 108 object. For human convenience, we often use a textual string, termed 109 the descriptor, to refer to the object type. 111 4. Rationale for having a Network Services Monitoring MIB 113 Much effort has been expended in developing tools to manage lower layer 114 network facilities. However, relatively little work has been done on 115 managing application layer entities. It is neither efficient nor 116 reasonable to manage all aspects of application layer entities using 117 only lower layer information. Moreover, the difficulty of managing 118 application entities in this way increases dramatically as application 119 entities become more complex. 121 This leads to a substantial need to monitor applications which provide 122 network services, particularly distributed components such as MTAs and 123 DSAs, by monitoring specific aspects of the application itself. Reasons 124 to monitor such components include but are not limited to measuring 125 load, detecting broken connectivity, isolating system failures, and 126 locating congestion. 128 In order to manage network service applications effectively two 129 requirements must be met: 131 (1) It must be possible to monitor a large number of components 132 (typical for a large organization). 134 (2) Application monitoring must be integrated into general network 135 management. 137 This specification defines simple read-only access; this is sufficient 138 to determine up/down status and provide an indication of a broad class 139 of operational problems. 141 4.1. General Relationship to Other MIBs 143 This MIB is intended to only provide facilities common to the monitoring 144 of any network service application. It does not provide all the 145 facilities necessary to monitor any specific application. Each specific 146 type of network service application is expected to have a MIB of its own 147 that makes use of these common facilities. 149 4.2. Restriction of Scope 151 The framework provided here is very minimal; there is a lot more that 152 could be done. For example: 154 (1) General network service application configuration monitoring and 155 control. 157 (2) Detailed examination and modification of individual entries in 158 service-specific request queues. 160 (3) Probing to determine the status of a specific request (e.g. the 161 location of a mail message with a specific message-id). 163 (4) Requesting that certain actions be performed (e.g. forcing an 164 immediate connection and transfer of pending messages to some 165 specific system). 167 All these capabilities are both impressive and useful. However, these 168 capabilities would require provisions for strict security checking. 169 These capabilities would also mandate a much more complex design, with 170 many characteristics likely to be fairly implementation-specific. As a 171 result such facilities are likely to be both contentious and difficult 172 to implement. 174 This document religiously keeps things simple and focuses on the basic 175 monitoring aspect of managing applications providing network services. 176 The goal here is to provide a framework which is simple, useful, and 177 widely implementable. 179 4.3. Relationship to Directory Services 181 Use of and management of directory services already is tied up with 182 network service application management. There are clearly many things 183 which could be dealt with by directory services and protocols. We take 184 the line here that static configuration information is both provided by 185 and dealt with by directory services and protocols. The emphasis here 186 is on transient application status. 188 By placing static information in the directory, the richness and linkage 189 of the directory information framework does not need to be repeated in 190 the MIB. Static information is information which has a mean time to 191 change of the order of days or longer. 193 When information about network service applications is stored in the 194 directory (regardless of whether or not the network service application 195 makes direct use of the directory), it is recommended that a linkage be 196 established, so that: 198 (1) The managed object contains its own directory name. This allows 199 all directory information to be obtained by reference. This will 200 let a SNMP monitor capable of performing directory queries 201 present this information to the manager in an appropriate format. 202 It is intended that this will be the normal case. 204 (2) The directory will reference the location of the SNMP agent, so 205 that an SNMP capable directory query agent could probe dynamic 206 characteristics of the object. 208 (3) This approach could be extended further, so that the SNMP 209 attributes are modelled as directory attributes. This would 210 dramatically simplify the design of directory service agents that 211 use SNMP to obtain the information they need. 213 5. Application Objects 215 This MIB defines a set of general purpose attributes which would be 216 appropriate for a range of applications that provide network services. 217 Both OSI and non-OSI services can be accomodated. Additional tables 218 defined in extensions to this MIB provide attributes specific to 219 specific network services. 221 A table is defined which will have one row for each operational network 222 service application on the system. The only static information held on 223 the application is its name. All other static information should be 224 obtained from various directory services. The applDirectoryName is an 225 external key, which allows an SNMP MIB entry to be cleanly related to 226 the X.500 Directory. In SNMP terms, the applications are grouped in a 227 table called applTable, which is indexed by an integer key applIndex. 229 The type of the application will be determined by one or both of: 231 (1) Additional MIB variables specific to the applications. 233 (2) An association to the application of a specific protocol. 235 6. Definitions 237 NETWORK-SERVICES-MIB DEFINITIONS ::= BEGIN 239 IMPORTS 240 OBJECT-TYPE, Counter32, Gauge32, MODULE-IDENTITY 241 FROM SNMPv2-SMI 242 mib-2 243 FROM RFC1213-MIB 244 DisplayString, TimeStamp, TEXTUAL-CONVENTION 245 FROM SNMPv2-TC 246 MODULE-COMPLIANCE, OBJECT-GROUP 247 FROM SNMPv2-CONF; 249 -- Textual conventions 250 -- DistinguishedName is used to refer to objects in the 251 -- directory. 253 DistinguishedName ::= TEXTUAL-CONVENTION 254 STATUS current 255 DESCRIPTION 256 "A Distinguished Name represented in accordance with 257 RFC 1779 [8]." 258 SYNTAX DisplayString 260 -- Uniform Resource Locators are stored in URLStrings. 262 URLString ::= TEXTUAL-CONVENTION 263 STATUS current 264 DESCRIPTION 265 "A Uniform Resource Locator represented in accordance 266 with RFC 1738 [10]." 267 SYNTAX DisplayString 269 application MODULE-IDENTITY 270 LAST-UPDATED "9703010000Z" 271 ORGANIZATION "IETF Mail and Directory Management Working Group" 272 CONTACT-INFO 273 " Ned Freed 275 Postal: Innosoft International, Inc. 276 1050 East Garvey Avenue South 277 West Covina, CA 91790 278 US 280 Tel: +1 818 919 3600 281 Fax: +1 818 919 3614 283 E-Mail: ned@innosoft.com" 284 DESCRIPTION 285 "The MIB module describing network service applications" 286 ::= {mib-2 27} 288 -- The basic applTable contains a list of the application 289 -- entities. 291 applTable OBJECT-TYPE 292 SYNTAX SEQUENCE OF ApplEntry 293 MAX-ACCESS not-accessible 294 STATUS current 295 DESCRIPTION 296 "The table holding objects which apply to all different 297 kinds of applications providing network services. 298 Each network service application capable of being 299 monitored should have a single entry in this table." 300 ::= {application 1} 302 applEntry OBJECT-TYPE 303 SYNTAX ApplEntry 304 MAX-ACCESS not-accessible 305 STATUS current 306 DESCRIPTION 307 "An entry associated with a single network service 308 application." 309 INDEX {applIndex} 310 ::= {applTable 1} 312 ApplEntry ::= SEQUENCE { 313 applIndex 314 INTEGER, 315 applName 316 DisplayString, 317 applDirectoryName 318 DistinguishedName, 319 applVersion 320 DisplayString, 321 applUptime 322 TimeStamp, 323 applOperStatus 324 INTEGER, 325 applLastChange 326 TimeStamp, 328 applInboundAssociations 329 Gauge32, 330 applOutboundAssociations 331 Gauge32, 332 applAccumulatedInboundAssociations 333 Counter32, 334 applAccumulatedOutboundAssociations 335 Counter32, 336 applLastInboundActivity 337 TimeStamp, 338 applLastOutboundActivity 339 TimeStamp, 340 applRejectedInboundAssociations 341 Counter32, 342 applFailedOutboundAssociations 343 Counter32, 344 applDescription 345 DisplayString, 346 applURL 347 URLString 348 } 350 applIndex OBJECT-TYPE 351 SYNTAX INTEGER (1..2147483647) 352 MAX-ACCESS not-accessible 353 STATUS current 354 DESCRIPTION 355 "An index to uniquely identify the network service 356 application. This attribute is the index used for 357 lexicographic ordering of the table." 358 ::= {applEntry 1} 360 applName OBJECT-TYPE 361 SYNTAX DisplayString 362 MAX-ACCESS read-only 363 STATUS current 364 DESCRIPTION 365 "The name the network service application chooses to be 366 known by." 367 ::= {applEntry 2} 369 applDirectoryName OBJECT-TYPE 370 SYNTAX DistinguishedName 371 MAX-ACCESS read-only 372 STATUS current 373 DESCRIPTION 374 "The Distinguished Name of the directory entry where 375 static information about this application is stored. 376 An empty string indicates that no information about 377 the application is available in the directory." 378 ::= {applEntry 3} 380 applVersion OBJECT-TYPE 381 SYNTAX DisplayString 382 MAX-ACCESS read-only 383 STATUS current 384 DESCRIPTION 385 "The version of network service application software. 386 This field is usually defined by the vendor of the 387 network service application software." 388 ::= {applEntry 4} 390 applUptime OBJECT-TYPE 391 SYNTAX TimeStamp 392 MAX-ACCESS read-only 393 STATUS current 394 DESCRIPTION 395 "The value of sysUpTime at the time the network service 396 application was last initialized. If the application was 397 last initialized prior to the last initialization of the 398 network management subsystem, then this object contains 399 a zero value." 400 ::= {applEntry 5} 402 applOperStatus OBJECT-TYPE 403 SYNTAX INTEGER { 404 up(1), 405 down(2), 406 halted(3), 407 congested(4), 408 restarting(5), 409 quiescing(6) 410 } 411 MAX-ACCESS read-only 412 STATUS current 413 DESCRIPTION 414 "Indicates the operational status of the network service 415 application. 'down' indicates that the network service is 416 not available. 'up' indicates that the network service 417 is operational and available. 'halted' indicates that the 418 service is operational but not available. 'congested' 419 indicates that the service is operational but no additional 420 inbound associations can be accomodated. 'restarting' 421 indicates that the service is currently unavailable but is 422 in the process of restarting and will be available soon. 423 'quiescing' indicates that service is currently operational 424 but is in the process of shutting down. Additional inbound 425 associations may be rejected by applications in the 426 'quiescing' state." 427 ::= {applEntry 6} 429 applLastChange OBJECT-TYPE 430 SYNTAX TimeStamp 431 MAX-ACCESS read-only 432 STATUS current 433 DESCRIPTION 434 "The value of sysUpTime at the time the network service 435 application entered its current operational state. If 436 the current state was entered prior to the last 437 initialization of the local network management subsystem, 438 then this object contains a zero value." 439 ::= {applEntry 7} 441 applInboundAssociations OBJECT-TYPE 442 SYNTAX Gauge32 443 MAX-ACCESS read-only 444 STATUS current 445 DESCRIPTION 446 "The number of current associations to the network service 447 application, where it is the responder. An inbound 448 assocation occurs when a another application successfully 449 connects to this one." 450 ::= {applEntry 8} 452 applOutboundAssociations OBJECT-TYPE 453 SYNTAX Gauge32 454 MAX-ACCESS read-only 455 STATUS current 456 DESCRIPTION 457 "The number of current associations to the network service 458 application, where it is the initiator. An outbound 459 association occurs when this application successfully 460 connects to another one." 461 ::= {applEntry 9} 463 applAccumulatedInboundAssociations OBJECT-TYPE 464 SYNTAX Counter32 465 MAX-ACCESS read-only 466 STATUS current 467 DESCRIPTION 468 "The total number of associations to the application entity 469 since application initialization, where it was the responder." 470 ::= {applEntry 10} 472 applAccumulatedOutboundAssociations OBJECT-TYPE 473 SYNTAX Counter32 474 MAX-ACCESS read-only 475 STATUS current 476 DESCRIPTION 477 "The total number of associations to the application entity 478 since application initialization, where it was the initiator." 479 ::= {applEntry 11} 481 applLastInboundActivity OBJECT-TYPE 482 SYNTAX TimeStamp 483 MAX-ACCESS read-only 484 STATUS current 485 DESCRIPTION 486 "The value of sysUpTime at the time this application last 487 had an inbound association. If the last association 488 occurred prior to the last initialization of the network 489 subsystem, then this object contains a zero value." 490 ::= {applEntry 12} 492 applLastOutboundActivity OBJECT-TYPE 493 SYNTAX TimeStamp 494 MAX-ACCESS read-only 495 STATUS current 496 DESCRIPTION 497 "The value of sysUpTime at the time this application last 498 had an outbound association. If the last association 499 occurred prior to the last initialization of the network 500 subsystem, then this object contains a zero value." 501 ::= {applEntry 13} 503 applRejectedInboundAssociations OBJECT-TYPE 504 SYNTAX Counter32 505 MAX-ACCESS read-only 506 STATUS current 507 DESCRIPTION 508 "The total number of inbound associations the application 509 entity has rejected, since application initialization. 510 Rejected associations are not counted in the accumulated 511 association totals. Note that this only counts 512 associations the application entity has rejected itself; 513 it does not count rejections that occur at lower layers 514 of the network. Thus, this counter may not reflect the 515 true number of failed inbound associations." 516 ::= {applEntry 14} 518 applFailedOutboundAssociations OBJECT-TYPE 519 SYNTAX Counter32 520 MAX-ACCESS read-only 521 STATUS current 522 DESCRIPTION 523 "The total number associations where the application entity 524 is initiator and association establishment has failed, 525 since application initialization. Failed associations are 526 not counted in the accumulated association totals." 527 ::= {applEntry 15} 529 applDescription OBJECT-TYPE 530 SYNTAX DisplayString 531 MAX-ACCESS read-only 532 STATUS current 533 DESCRIPTION 534 "A text description of the application. This information 535 is intended to identify and briefly describe the 536 application in a status display." 537 ::= {applEntry 16} 539 applURL OBJECT-TYPE 540 SYNTAX URLString 541 MAX-ACCESS read-only 542 STATUS current 543 DESCRIPTION 544 "A URL pointing to a description of the application. 545 This information is intended to identify and describe 546 the application in a status display." 547 ::= {applEntry 17} 549 -- The assocTable augments the information in the applTable 550 -- with information about associations. Note that two levels 551 -- of compliance are specified below, depending on whether 552 -- association monitoring is mandated. 554 assocTable OBJECT-TYPE 555 SYNTAX SEQUENCE OF AssocEntry 556 MAX-ACCESS not-accessible 557 STATUS current 558 DESCRIPTION 559 "The table holding a set of all active application 560 associations." 561 ::= {application 2} 563 assocEntry OBJECT-TYPE 564 SYNTAX AssocEntry 565 MAX-ACCESS not-accessible 566 STATUS current 567 DESCRIPTION 568 "An entry associated with an association for a network 569 service application." 570 INDEX {applIndex, assocIndex} 571 ::= {assocTable 1} 573 AssocEntry ::= SEQUENCE { 574 assocIndex 575 INTEGER, 576 assocRemoteApplication 577 DisplayString, 578 assocApplicationProtocol 579 OBJECT IDENTIFIER, 580 assocApplicationType 581 INTEGER, 582 assocDuration 583 TimeStamp 584 } 586 assocIndex OBJECT-TYPE 587 SYNTAX INTEGER (1..2147483647) 588 MAX-ACCESS not-accessible 589 STATUS current 590 DESCRIPTION 591 "An index to uniquely identify each association for a network 592 service application. This attribute is the index that is 593 used for lexicographic ordering of the table. Note that the 594 table is also indexed by the applIndex." 595 ::= {assocEntry 1} 597 assocRemoteApplication OBJECT-TYPE 598 SYNTAX DisplayString 599 MAX-ACCESS read-only 600 STATUS current 601 DESCRIPTION 602 "The name of the system running remote network service 603 application. For an IP-based application this should be 604 either a domain name or IP address. For an OSI application 605 it should be the string encoded distinguished name of the 606 managed object. For X.400(1984) MTAs which do not have a 607 Distinguished Name, the RFC 1327 [9] syntax 608 'mta in globalid' should be used. Note, however, that not 609 all connections an MTA are necessarily to another MTA." 610 ::= {assocEntry 2} 612 assocApplicationProtocol OBJECT-TYPE 613 SYNTAX OBJECT IDENTIFIER 614 MAX-ACCESS read-only 615 STATUS current 616 DESCRIPTION 617 "An identification of the protocol being used for the 618 application. For an OSI Application, this will be the 619 Application Context. For Internet applications, the IANA 620 maintains a registry of the OIDs which correspond to 621 well-known applications. If the application protocol is 622 not listed in the registry, an OID value of the form 623 {applTCPProtoID port} or {applUDProtoID port} are used for 624 TCP-based and UDP-based protocols, respectively. In either 625 case 'port' corresponds to the primary port number being 626 used by the protocol." 627 ::= {assocEntry 3} 629 assocApplicationType OBJECT-TYPE 630 SYNTAX INTEGER { 631 ua-initiator(1), 632 ua-responder(2), 633 peer-initiator(3), 634 peer-responder(4)} 635 MAX-ACCESS read-only 636 STATUS current 637 DESCRIPTION 638 "This indicates whether the remote application is some type of 639 client making use of this network service (e.g. a Mail User 640 Agent) or a server acting as a peer. Also indicated is whether 641 the remote end initiated an incoming connection to the network 642 service or responded to an outgoing connection made by the 643 local application. MTAs and messaging gateways are 644 considered to be peers for the purposes of this variable." 645 ::= {assocEntry 4} 647 assocDuration OBJECT-TYPE 648 SYNTAX TimeStamp 649 MAX-ACCESS read-only 650 STATUS current 651 DESCRIPTION 652 "The value of sysUpTime at the time this association was 653 started. If this association started prior to the last 654 initialization of the network subsystem, then this 655 object contains a zero value." 656 ::= {assocEntry 5} 658 -- Conformance information 660 applConformance OBJECT IDENTIFIER ::= {application 3} 662 applGroups OBJECT IDENTIFIER ::= {applConformance 1} 663 applCompliances OBJECT IDENTIFIER ::= {applConformance 2} 664 -- Compliance statements 666 applCompliance MODULE-COMPLIANCE 667 STATUS current 668 DESCRIPTION 669 "The compliance statement for SNMPv2 entities 670 which implement the Network Services Monitoring MIB 671 for basic monitoring of network service applications." 672 MODULE -- this module 673 MANDATORY-GROUPS {applGroup} 674 ::= {applCompliances 1} 676 assocCompliance MODULE-COMPLIANCE 677 STATUS current 678 DESCRIPTION 679 "The compliance statement for SNMPv2 entities which 680 implement the Network Services Monitoring MIB for basic 681 monitoring of network service applications and their 682 associations." 683 MODULE -- this module 684 MANDATORY-GROUPS {applGroup, assocGroup} 685 ::= {applCompliances 2} 687 -- Units of conformance 689 applGroup OBJECT-GROUP 690 OBJECTS { 691 applName, applVersion, applUptime, applOperStatus, 692 applLastChange, applInboundAssociations, 693 applOutboundAssociations, applAccumulatedInboundAssociations, 694 applAccumulatedOutboundAssociations, applLastInboundActivity, 695 applLastOutboundActivity, applRejectedInboundAssociations, 696 applFailedOutboundAssociations, applDescription, applURL} 697 STATUS current 698 DESCRIPTION 699 "A collection of objects providing basic monitoring of 700 network service applications." 701 ::= {applGroups 1} 703 assocGroup OBJECT-GROUP 704 OBJECTS { 705 assocRemoteApplication, assocApplicationProtocol, 706 assocApplicationType, assocDuration} 707 STATUS current 708 DESCRIPTION 709 "A collection of objects providing basic monitoring of 710 network service applications' associations." 711 ::= {applGroups 2} 713 -- OIDs of the form {applTCPProtoID port} are intended to be used 714 -- for TCP-based protocols that don't have OIDs assigned by other 715 -- means. {applUDPProtoID port} serves the same purpose for 716 -- UDP-based protocols. In either case 'port' corresponds to 717 -- the primary port number being used by the protocol. For example, 718 -- assuming no other OID is assigned for SMTP, an OID of 719 -- {applTCPProtoID 25} could be used, since SMTP is a TCP-based 720 -- protocol that uses port 25 as its primary port. 722 applTCPProtoID OBJECT IDENTIFIER ::= {application 4} 723 applUDPProtoID OBJECT IDENTIFIER ::= {application 5} 725 END 726 7. Changes made since RFC 1565 728 The only changes made to this document since it was issued as RFC 1565 729 [11] are the following: 731 (1) applDescription and applURL fields have been added. These fields 732 are intended to identify and describe the application. 734 (2) A number of DESCRIPTION fields have been reworded, hopefully 735 making them clearer. 737 (3) The new "quiescing" state has been added to applOperStatus. 739 (4) The prose about "dynamic single threaded processes" has been 740 removed -- it was simply too confusing. 742 (5) Various RFC references have been updated to refer to more recent 743 versions. 745 (6) The MIB has been renamed from APPLICATION-MIB to NETWORK- 746 SERVICES-MIB. This was done because an application MIB is now 747 under development within the IETF that provides very different 748 functionality from this MIB. 750 8. Acknowledgements 752 This document is a product of the Mail and Directory Management (MADMAN) 753 Working Group. It is based on an earlier MIB designed by S. Kille, T. 754 Lenggenhager, D. Partain, and W. Yeong. The Electronic Mail 755 Association's TSC committee was instrumental in providing feedback on 756 and suggesting enhancements to RFC 1565 [11] that have led to the 757 present document. 759 9. References 761 [1] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure 762 of Management Information for Version 2 of the Simple Network 763 Management Protocol (SNMPv2)", RFC 1902, January 1996. 765 [2] Case, J., McCloghrie, K., Rose, M., Waldbusser, S., "Textual 766 Conventions for Version 2 of the Simple Network Management Protocol 767 (SNMPv2)", RFC 1903, January 1996. 769 [3] Case, J., McCloghrie, K., Rose, M., Waldbusser, S., "Conformance 770 Statements for Version 2 of the Simple Network Management Protocol 771 (SNMPv2)", RFC 1904, January 1996. 773 [4] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol 774 Operations for Version 2 of the Simple Network Management Protocol 775 (SNMPv2)", RFC 1905, January 1996. 777 [5] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Transport 778 Mappings for Version 2 of the Simple Network Management Protocol 779 (SNMPv2)", RFC 1906, January 1996. 781 [6] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Management 782 Information Base for Version 2 of the Simple Network Management 783 Protocol (SNMPv2)", RFC 1907, January 1996. 785 [7] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., 786 "Coexistence between Version 1 and Version 2 of the Internet- 787 standard Network Management Framework", RFC 1908, January 1996. 789 [8] Kille, S., "A String Representation of Distinguished Names", RFC 790 1779, March 1995. 792 [9] Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC 822", 793 RFC 1327, May 1992. 795 [10] Berners-Lee, T., Masinter, L., McCahill, M., iform Resource 796 Locators (URL)", RFC 1738, December 1994. 798 [11] Freed, N., Kille, S., "Network Services Monitoring MIB", RFC 1565, 799 January 1994. 801 10. Security Considerations 803 Security issues are not discussed in this memo. 805 11. Author and Chair Addresses 807 Ned Freed 808 Innosoft International, Inc. 809 1050 East Garvey Avenue South 810 West Covina, CA 91790 811 USA 812 tel: +1 818 919 3600 813 fax: +1 818 919 3614 814 email: ned@innosoft.com 816 Steve Kille, MADMAN WG Chair 817 ISODE Consortium 818 The Dome, The Square 819 Richmond TW9 1DT 820 UK 821 tel: +44 181 332 9091 822 email: S.Kille@isode.com