idnits 2.17.1 draft-ietf-madman-nsm-mib-00.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-23) 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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (November 1995) is 10387 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 1442 (ref. '1') (Obsoleted by RFC 1902) ** Downref: Normative reference to an Historic RFC: RFC 1445 (ref. '3') ** Obsolete normative reference: RFC 1448 (ref. '4') (Obsoleted by RFC 1905) ** Obsolete normative reference: RFC 1485 (ref. '5') (Obsoleted by RFC 1779, RFC 3494) ** Obsolete normative reference: RFC 1327 (ref. '6') (Obsoleted by RFC 2156) Summary: 14 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Steve Kille, WG Chair 2 Internet Draft Ned Freed, Editor 3 5 Network Services Monitoring MIB 7 November 1995 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 There are a wide range of networked applications for which it is 30 appropriate to provide SNMP Monitoring. This includes both TCP/IP and 31 OSI applications. This document defines a MIB which contains the 32 elements common to the monitoring of any network service application. 33 This information includes a table of all monitorable network service 34 applications, a count of the associations (connections) to each 35 application, and basic information about the parameters and status of 36 each application-related association. 38 This MIB may be used on its own for any application, and for most simple 39 applications this will suffice. This MIB is also designed to serve as a 40 building block which can be used in conjunction with application- 41 specific monitoring and management. Two examples of this are MIBs 42 defining additional variables for monitoring a Message Transfer Agent 43 (MTA) service or a Directory Service Agent (DSA) service. It is expected 44 that further MIBs of this nature will be specified. 46 This MIB does not attempt to provide facilities for management of the 47 host or hosts the network service application runs on, nor does it 48 provide facilities for monitoring applications that provide something 49 other than a network service. Host resource and general application 50 monitoring is handled by the Host Resources MIB. 52 2. Table of Contents 54 1 Introduction .................................................... 1 55 2 Table of Contents ............................................... 2 56 3 The SNMPv2 Network Management Framework ......................... 2 57 3.1 Object Definitions ............................................ 3 58 4 Rationale for having a Network Services Monitoring MIB .......... 3 59 4.1 General Relationship to Other MIBs ............................ 4 60 4.2 Restriction of Scope .......................................... 4 61 4.3 Relationship to Directory Services ............................ 5 62 5 Application Objects ............................................. 5 63 6 Definitions ..................................................... 6 64 7 Changes made since RFC1565 ...................................... 18 65 8 Acknowledgements ................................................ 19 66 9 References ...................................................... 19 67 10 Security Considerations ........................................ 19 68 11 Authors' Addresses ............................................. 20 70 3. The SNMPv2 Network Management Framework 72 The SNMPv2 Network Management Framework consists of four major 73 components. They are: 75 o RFC 1442 [1] which defines the SMI, the mechanisms used for 76 describing and naming objects for the purpose of management. 78 o RFC 1213 [2] defines MIB-II, the core set of managed objects for 79 the Internet suite of protocols. 81 o RFC 1445 [3] which defines the administrative and other 82 architectural aspects of the framework. 84 o RFC 1448 [4] which defines the protocol used for network access to 85 managed objects. 87 The Framework permits new objects to be defined for the purpose of 88 experimentation and evaluation. 90 3.1. Object Definitions 92 Managed objects are accessed via a virtual information store, termed the 93 Management Information Base or MIB. Objects in the MIB are defined using 94 the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. 95 In particular, each object type is named by an OBJECT IDENTIFIER, an 96 administratively assigned name. The object type together with an object 97 instance serves to uniquely identify a specific instantiation of the 98 object. For human convenience, we often use a textual string, termed 99 the descriptor, to refer to the object type. 101 4. Rationale for having a Network Services Monitoring MIB 103 Much effort has been expended in developing tools to manage lower layer 104 network facilities. However, relatively little work has been done on 105 managing application layer entities. It is neither efficient nor 106 reasonable to manage all aspects of application layer entities using 107 only lower layer information. Moreover, the difficulty of managing 108 application entities in this way increases dramatically as application 109 entities become more complex. 111 This leads to a substantial need to monitor applications which provide 112 network services, particularly distributed components such as MTAs and 113 DSAs, by monitoring specific aspects of the application itself. Reasons 114 to monitor such components include but are not limited to measuring 115 load, detecting broken connectivity, isolating system failures, and 116 locating congestion. 118 In order to manage network service applications effectively two 119 requirements must be met: 121 (1) It must be possible to monitor a large number of components 122 (typical for a large organization). 124 (2) Application monitoring must be integrated into general network 125 management. 127 This specification defines simple read-only access; this is sufficient 128 to determine up/down status and provide an indication of a broad class 129 of operational problems. 131 4.1. General Relationship to Other MIBs 133 This MIB is intended to only provide facilities common to the monitoring 134 of any network service application. It does not provide all the 135 facilities necessary to monitor any specific application. Each specific 136 type of network service application is expected to have a MIB of its own 137 that makes use of these common facilities. 139 4.2. Restriction of Scope 141 The framework provided here is very minimal; there is a lot more that 142 could be done. For example: 144 (1) General network service application configuration monitoring and 145 control. 147 (2) Detailed examination and modification of individual entries in 148 service-specific request queues. 150 (3) Probing to determine the status of a specific request (e.g. the 151 location of a mail message with a specific message-id). 153 (4) Requesting that certain actions be performed (e.g. forcing an 154 immediate connection and transfer of pending messages to some 155 specific system). 157 All these capabilities are both impressive and useful. However, these 158 capabilities would require provisions for strict security checking. 159 These capabilities would also mandate a much more complex design, with 160 many characteristics likely to be fairly implementation-specific. As a 161 result such facilities are likely to be both contentious and difficult 162 to implement. 164 This document religiously keeps things simple and focuses on the basic 165 monitoring aspect of managing applications providing network services. 166 The goal here is to provide a framework which is simple, useful, and 167 widely implementable. 169 4.3. Relationship to Directory Services 171 Use of and management of directory services already is tied up with 172 network service application management. There are clearly many things 173 which could be dealt with by directory services and protocols. We take 174 the line here that static configuration information is both provided by 175 and dealt with by directory services and protocols. The emphasis here 176 is on transient application status. 178 By placing static information in the directory, the richness and linkage 179 of the directory information framework does not need to be repeated in 180 the MIB. Static information is information which has a mean time to 181 change of the order of days or longer. 183 When information about network service applications is stored in the 184 directory (regardless of whether or not the network service application 185 makes direct use of the directory), it is recommended that a linkage be 186 established, so that: 188 (1) The managed object contains its own directory name. This allows 189 all directory information to be obtained by reference. This will 190 let a SNMP monitor capable of performing directory queries 191 present this information to the manager in an appropriate format. 192 It is intended that this will be the normal case. 194 (2) The directory will reference the location of the SNMP agent, so 195 that an SNMP capable directory query agent could probe dynamic 196 characteristics of the object. 198 (3) This approach could be extended further, so that the SNMP 199 attributes are modelled as directory attributes. This would 200 dramatically simplify the design of directory service agents that 201 use SNMP to obtain the information they need. 203 5. Application Objects 205 This MIB defines a set of general purpose attributes which would be 206 appropriate for a range of applications that provide network services. 207 Both OSI and non-OSI services can be accomodated. Additional tables 208 defined in extensions to this MIB provide attributes specific to 209 specific network services. 211 A table is defined which will have one row for each network service 212 application running on the system. The only static information held on 213 the application is its name. All other static information should be 214 obtained from various directory services. The applDirectoryName is an 215 external key, which allows an SNMP MIB entry to be cleanly related to 216 the X.500 Directory. In SNMP terms, the applications are grouped in a 217 table called applTable, which is indexed by an integer key applIndex. 219 The type of the application will be determined by one or both of: 221 (1) Additional MIB variables specific to the applications. 223 (2) An association to the application of a specific protocol. 225 6. Definitions 227 APPLICATION-MIB DEFINITIONS ::= BEGIN 229 IMPORTS 230 OBJECT-TYPE, Counter32, Gauge32, MODULE-IDENTITY 231 FROM SNMPv2-SMI 232 mib-2 233 FROM RFC1213-MIB 234 DisplayString, TimeStamp, TEXTUAL-CONVENTION 235 FROM SNMPv2-TC 236 MODULE-COMPLIANCE, OBJECT-GROUP 237 FROM SNMPv2-CONF; 239 -- Textual conventions 241 -- DistinguishedName [5] is used to refer to objects in the 242 -- directory. 244 DistinguishedName ::= TEXTUAL-CONVENTION 245 STATUS current 246 DESCRIPTION 247 "A Distinguished Name represented in accordance with 248 RFC1485." 249 SYNTAX DisplayString 251 application MODULE-IDENTITY 252 LAST-UPDATED "9511190000Z" 253 ORGANIZATION "IETF Mail and Directory Management Working Group" 254 CONTACT-INFO 255 " Ned Freed 257 Postal: Innosoft International, Inc. 258 1050 East Garvey Avenue South 259 West Covina, CA 91790 260 US 262 Tel: +1 818 919 3600 263 Fax: +1 818 919 3614 265 E-Mail: ned@innosoft.com" 266 DESCRIPTION 267 "The MIB module describing network service applications" 268 ::= {mib-2 27} 270 -- The basic applTable contains a list of the application 271 -- entities. 273 applTable OBJECT-TYPE 274 SYNTAX SEQUENCE OF ApplEntry 275 MAX-ACCESS not-accessible 276 STATUS current 277 DESCRIPTION 278 "The table holding objects which apply to all different 279 kinds of applications providing network services. 280 Each network service application capable of being 281 monitored should have a single entry in this table." 282 ::= {application 1} 284 applEntry OBJECT-TYPE 285 SYNTAX ApplEntry 286 MAX-ACCESS not-accessible 287 STATUS current 288 DESCRIPTION 289 "An entry associated with a single network service 290 application." 291 INDEX {applIndex} 292 ::= {applTable 1} 294 ApplEntry ::= SEQUENCE { 295 applIndex 296 INTEGER, 297 applName 298 DisplayString, 299 applDirectoryName 300 DistinguishedName, 301 applVersion 302 DisplayString, 303 applUptime 304 TimeStamp, 305 applOperStatus 306 INTEGER, 307 applLastChange 308 TimeStamp, 309 applInboundAssociations 310 Gauge32, 311 applOutboundAssociations 312 Gauge32, 313 applAccumulatedInboundAssociations 314 Counter32, 315 applAccumulatedOutboundAssociations 316 Counter32, 317 applLastInboundActivity 318 TimeStamp, 319 applLastOutboundActivity 320 TimeStamp, 321 applRejectedInboundAssociations 322 Counter32, 323 applFailedOutboundAssociations 324 Counter32 325 } 327 applIndex OBJECT-TYPE 328 SYNTAX INTEGER (1..2147483647) 329 MAX-ACCESS not-accessible 330 STATUS current 331 DESCRIPTION 332 "An index to uniquely identify the network service 333 application. This attribute is the index used for 334 lexicographic ordering of the table." 335 ::= {applEntry 1} 337 applName OBJECT-TYPE 338 SYNTAX DisplayString 339 MAX-ACCESS read-only 340 STATUS current 341 DESCRIPTION 342 "The name the network service application chooses to be 343 known by." 344 ::= {applEntry 2} 346 applDirectoryName OBJECT-TYPE 347 SYNTAX DistinguishedName 348 MAX-ACCESS read-only 349 STATUS current 350 DESCRIPTION 351 "The Distinguished Name of the directory entry where 352 static information about this application is stored. 353 An empty string indicates that no information about 354 the application is available in the directory." 355 ::= {applEntry 3} 357 applVersion OBJECT-TYPE 358 SYNTAX DisplayString 359 MAX-ACCESS read-only 360 STATUS current 361 DESCRIPTION 362 "The version of network service application software. 363 This field is usually defined by the vendor of the 364 network service application software." 365 ::= {applEntry 4} 367 applUptime OBJECT-TYPE 368 SYNTAX TimeStamp 369 MAX-ACCESS read-only 370 STATUS current 371 DESCRIPTION 372 "The value of sysUpTime at the time the network service 373 application was last initialized. If the application was 374 last initialized prior to the last initialization of the 375 network management subsystem, then this object contains 376 a zero value." 377 ::= {applEntry 5} 379 applOperStatus OBJECT-TYPE 380 SYNTAX INTEGER { 381 up(1), 382 down(2), 383 halted(3), 384 congested(4), 385 restarting(5), 386 quiescing(6) 387 } 388 MAX-ACCESS read-only 389 STATUS current 390 DESCRIPTION 391 "Indicates the operational status of the network service 392 application. 'down' indicates that the network service is 393 not available. 'up' indicates that the network service 394 is operational and available. 'halted' indicates that the 395 service is operational but not available. 'congested' 396 indicates that the service is operational but no additional 397 inbound associations can be accomodated. 'restarting' 398 indicates that the service is currently unavailable but is 399 in the process of restarting and will be available soon. 400 'quiescing' indicates that service is currently operational 401 but is in the process of shutting down. Additional inbound 402 associations may be rejected by applications in the 403 'quiescing' state." 404 ::= {applEntry 6} 406 applLastChange OBJECT-TYPE 407 SYNTAX TimeStamp 408 MAX-ACCESS read-only 409 STATUS current 410 DESCRIPTION 411 "The value of sysUpTime at the time the network service 412 application entered its current operational state. If 413 the current state was entered prior to the last 414 initialization of the local network management subsystem, 415 then this object contains a zero value." 416 ::= {applEntry 7} 418 applInboundAssociations OBJECT-TYPE 419 SYNTAX Gauge32 420 MAX-ACCESS read-only 421 STATUS current 422 DESCRIPTION 423 "The number of current associations to the network service 424 application, where it is the responder. An inbound 425 assocation occurs when a another application successfully 426 connects to this one." 427 ::= {applEntry 8} 429 applOutboundAssociations OBJECT-TYPE 430 SYNTAX Gauge32 431 MAX-ACCESS read-only 432 STATUS current 433 DESCRIPTION 434 "The number of current associations to the network service 435 application, where it is the initiator. An outbound 436 association occurs when this application successfully 437 connects to another one." 438 ::= {applEntry 9} 440 applAccumulatedInboundAssociations OBJECT-TYPE 441 SYNTAX Counter32 442 MAX-ACCESS read-only 443 STATUS current 444 DESCRIPTION 445 "The total number of associations to the application entity 446 since application initialization, where it was the responder." 447 ::= {applEntry 10} 449 applAccumulatedOutboundAssociations OBJECT-TYPE 450 SYNTAX Counter32 451 MAX-ACCESS read-only 452 STATUS current 453 DESCRIPTION 454 "The total number of associations to the application entity 455 since application initialization, where it was the initiator." 456 ::= {applEntry 11} 458 applLastInboundActivity OBJECT-TYPE 459 SYNTAX TimeStamp 460 MAX-ACCESS read-only 461 STATUS current 462 DESCRIPTION 463 "The value of sysUpTime at the time this application last 464 had an inbound association. If the last association 465 occurred prior to the last initialization of the network 466 subsystem, then this object contains a zero value." 467 ::= {applEntry 12} 469 applLastOutboundActivity OBJECT-TYPE 470 SYNTAX TimeStamp 471 MAX-ACCESS read-only 472 STATUS current 473 DESCRIPTION 474 "The value of sysUpTime at the time this application last 475 had an outbound association. If the last association 476 occurred prior to the last initialization of the network 477 subsystem, then this object contains a zero value." 478 ::= {applEntry 13} 480 applRejectedInboundAssociations OBJECT-TYPE 481 SYNTAX Counter32 482 MAX-ACCESS read-only 483 STATUS current 484 DESCRIPTION 485 "The total number of inbound associations the application 486 entity has rejected, since application initialization. 487 Rejected associations are not counted in the accumulated 488 association totals. Note that this only counts 489 associations the application entity has rejected itself; 490 it does not count rejections that occur at lower layers 491 of the network. Thus, this counter may not reflect the 492 true number of failed inbound associations." 493 ::= {applEntry 14} 495 applFailedOutboundAssociations OBJECT-TYPE 496 SYNTAX Counter32 497 MAX-ACCESS read-only 498 STATUS current 499 DESCRIPTION 500 "The total number associations where the application entity 501 is initiator and association establishment has failed, 502 since application initialization. Failed associations are 503 not counted in the accumulated association totals." 504 ::= {applEntry 15} 506 -- The assocTable augments the information in the applTable 507 -- with information about associations. Note that two levels 508 -- of compliance are specified below, depending on whether 509 -- association monitoring is mandated. 511 assocTable OBJECT-TYPE 512 SYNTAX SEQUENCE OF AssocEntry 513 MAX-ACCESS not-accessible 514 STATUS current 515 DESCRIPTION 516 "The table holding a set of all active application 517 associations." 518 ::= {application 2} 520 assocEntry OBJECT-TYPE 521 SYNTAX AssocEntry 522 MAX-ACCESS not-accessible 523 STATUS current 524 DESCRIPTION 525 "An entry associated with an association for a network 526 service application." 527 INDEX {applIndex, assocIndex} 528 ::= {assocTable 1} 530 AssocEntry ::= SEQUENCE { 531 assocIndex 532 INTEGER, 533 assocRemoteApplication 534 DisplayString, 535 assocApplicationProtocol 536 OBJECT IDENTIFIER, 537 assocApplicationType 538 INTEGER, 539 assocDuration 540 TimeStamp 541 } 543 assocIndex OBJECT-TYPE 544 SYNTAX INTEGER (1..2147483647) 545 MAX-ACCESS not-accessible 546 STATUS current 547 DESCRIPTION 548 "An index to uniquely identify each association for a network 549 service application. This attribute is the index that is 550 used for lexicographic ordering of the table. Note that the 551 table is also indexed by the applIndex." 552 ::= {assocEntry 1} 554 assocRemoteApplication OBJECT-TYPE 555 SYNTAX DisplayString 556 MAX-ACCESS read-only 557 STATUS current 558 DESCRIPTION 559 "The name of the system running remote network service 560 application. For an IP-based application this should be 561 either a domain name or IP address. For an OSI application 562 it should be the string encoded distinguished name of the 563 managed object. For X.400(1984) MTAs which do not have a 564 Distinguished Name, the RFC1327 [6] syntax 565 'mta in globalid' should be used. Note, however, that not 566 all connections an MTA are necessarily to another MTA." 567 ::= {assocEntry 2} 569 assocApplicationProtocol OBJECT-TYPE 570 SYNTAX OBJECT IDENTIFIER 571 MAX-ACCESS read-only 572 STATUS current 573 DESCRIPTION 574 "An identification of the protocol being used for the 575 application. For an OSI Application, this will be the 576 Application Context. For Internet applications, the IANA 577 maintains a registry of the OIDs which correspond to 578 well-known applications. If the application protocol is 579 not listed in the registry, an OID value of the form 580 {applTCPProtoID port} or {applUDProtoID port} are used for 581 TCP-based and UDP-based protocols, respectively. In either 582 case 'port' corresponds to the primary port number being 583 used by the protocol." 584 ::= {assocEntry 3} 586 assocApplicationType OBJECT-TYPE 587 SYNTAX INTEGER { 588 ua-initiator(1), 589 ua-responder(2), 590 peer-initiator(3), 591 peer-responder(4)} 592 MAX-ACCESS read-only 593 STATUS current 594 DESCRIPTION 595 "This indicates whether the remote application is some type of 596 client making use of this network service (e.g. a User Agent) 597 or a server acting as a peer. Also indicated is whether the 598 remote end initiated an incoming connection to the network 599 service or responded to an outgoing connection made by the 600 local application. MTAs and messaging gateways are 601 considered to be peers for the purposes of this variable." 602 ::= {assocEntry 4} 604 assocDuration OBJECT-TYPE 605 SYNTAX TimeStamp 606 MAX-ACCESS read-only 607 STATUS current 608 DESCRIPTION 609 "The value of sysUpTime at the time this association was 610 started. If this association started prior to the last 611 initialization of the network subsystem, then this 612 object contains a zero value." 613 ::= {assocEntry 5} 615 -- Conformance information 617 applConformance OBJECT IDENTIFIER ::= {application 3} 619 applGroups OBJECT IDENTIFIER ::= {applConformance 1} 620 applCompliances OBJECT IDENTIFIER ::= {applConformance 2} 622 -- Compliance statements 624 applCompliance MODULE-COMPLIANCE 625 STATUS current 626 DESCRIPTION 627 "The compliance statement for SNMPv2 entities 628 which implement the Network Services Monitoring MIB 629 for basic monitoring of network service applications." 630 MODULE -- this module 631 MANDATORY-GROUPS {applGroup} 632 ::= {applCompliances 1} 634 assocCompliance MODULE-COMPLIANCE 635 STATUS current 636 DESCRIPTION 637 "The compliance statement for SNMPv2 entities which 638 implement the Network Services Monitoring MIB for basic 639 monitoring of network service applications and their 640 associations." 641 MODULE -- this module 642 MANDATORY-GROUPS {applGroup, assocGroup} 643 ::= {applCompliances 2} 645 -- Units of conformance 647 applGroup OBJECT-GROUP 648 OBJECTS { 649 applName, applVersion, applUptime, applOperStatus, 650 applLastChange, applInboundAssociations, 651 applOutboundAssociations, applAccumulatedInboundAssociations, 652 applAccumulatedOutboundAssociations, applLastInboundActivity, 653 applLastOutboundActivity, applRejectedInboundAssociations, 654 applFailedOutboundAssociations} 655 STATUS current 656 DESCRIPTION 657 "A collection of objects providing basic monitoring of 658 network service applications." 659 ::= {applGroups 1} 661 assocGroup OBJECT-GROUP 662 OBJECTS { 663 assocRemoteApplication, assocApplicationProtocol, 664 assocApplicationType, assocDuration} 665 STATUS current 666 DESCRIPTION 667 "A collection of objects providing basic monitoring of 668 network service applications' associations." 669 ::= {applGroups 2} 671 -- OIDs of the form {applTCPProtoID port} are intended to be used 672 -- for TCP-based protocols that don't have OIDs assigned by other 673 -- means. {applUDPProtoID port} serves the same purpose for 674 -- UDP-based protocols. In either case 'port' corresponds to 675 -- the primary port number being used by the protocol. For example, 676 -- assuming no other OID is assigned for SMTP, an OID of 677 -- {applTCPProtoID 25} could be used, since SMTP is a TCP-based 678 -- protocol that uses port 25 as its primary port. 680 applTCPProtoID OBJECT IDENTIFIER ::= {application 4} 681 applUDPProtoID OBJECT IDENTIFIER ::= {application 5} 683 END 684 7. Changes made since RFC1565 686 The only changes made to this document since it was issued as RFC1565 687 are the following: 689 (1) A number of DESCRIPTION fields have been reworded, hopefully 690 making them clearer. 692 (2) The new "quiescing" state has been addedto applOperStatus. 694 (3) The prose about "dynamic single threaded processes" has been 695 removed -- it was simply too confusing. 697 8. Acknowledgements 699 This document is a product of the Mail and Directory Management (MADMAN) 700 Working Group. It is based on an earlier MIB designed by S. Kille, T. 701 Lenggenhager, D. Partain, and W. Yeong. 703 9. References 705 [1] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure 706 of Management Information for version 2 of the Simple Network 707 Management Protocol (SNMPv2)", RFC1442, SNMP Research, Inc., Hughes 708 LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon 709 University, April 1993. 711 [2] McCloghrie, K., and Rose, M., Editors, "Management Information Base 712 for Network Management of TCP/IP-based internets: MIB-II", STD 17, 713 RFC 1213, Hughes LAN Systems, Performance Systems International, 714 March 1991. 716 [3] Galvin, J., McCloghrie, K., " Administrative Model for version 2 of 717 the Simple Network Management Protocol (SNMPv2)", RFC 1445, Trusted 718 Information Systems, Hughes LAN Systems, April 1993. 720 [4] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol 721 Operations for version 2 of the Simple Network Management Protocol 722 (SNMPv2)", RFC1448, SNMP Research, Inc., Hughes LAN Systems, Dover 723 Beach Consulting, Inc., Carnegie Mellon University, April 1993. 725 [5] Kille, S., "A String Representation of Distinguished Names", RFC 726 1485, July, 1993. 728 [6] Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC822", 729 RFC1327, May 1992. 731 10. Security Considerations 733 Security issues are not discussed in this memo. 735 11. Authors' Addresses 737 Ned Freed, Editor 738 Innosoft International, Inc. 739 1050 East Garvey Avenue South 740 West Covina, CA 91790 741 USA 742 tel: +1 818 919 3600 743 fax: +1 818 919 3614 744 email: ned@innosoft.com 746 Steve Kille, WG Chair 747 ISODE Consortium 748 The Dome, The Square 749 Richmond TW9 1DT 750 UK 751 tel: +44 81 332 9091 752 email: S.Kille@isode.com