idnits 2.17.1 draft-ietf-madman-nsm-mib-01.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-27) 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: ---------------------------------------------------------------------------- == Line 742 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 1996) is 10270 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) ** Downref: Normative reference to an Historic RFC: RFC 1445 (ref. '3') ** Obsolete normative reference: RFC 1905 (ref. '4') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1779 (ref. '5') (Obsoleted by RFC 2253, RFC 3494) ** Obsolete normative reference: RFC 1327 (ref. '6') (Obsoleted by RFC 2156) ** Obsolete normative reference: RFC 1738 (ref. '7') (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1565 (ref. '8') (Obsoleted by RFC 2248) Summary: 16 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Steve Kille, WG Chair 3 Internet Draft Ned Freed, Editor 4 6 Network Services Monitoring MIB 8 March 1996 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months. 18 Internet-Drafts may be updated, replaced, or obsoleted by other 19 documents at any time. It is not appropriate to use Internet-Drafts as 20 reference material or to cite them other than as a "working draft" or 21 "work in progress". 23 To learn the current status of any Internet-Draft, please check the 24 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 25 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 26 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 28 1. Introduction 30 There are a wide range of networked applications for which it is 31 appropriate to provide SNMP Monitoring. This includes both TCP/IP and 32 OSI applications. This document defines a MIB which contains the 33 elements common to the monitoring of any network service application. 34 This information includes a table of all monitorable network service 35 applications, a count of the associations (connections) to each 36 application, and basic information about the parameters and status of 37 each application-related association. 39 This MIB may be used on its own for any application, and for most simple 40 applications this will suffice. This MIB is also designed to serve as a 41 building block which can be used in conjunction with application- 42 specific monitoring and management. Two examples of this are MIBs 43 defining additional variables for monitoring a Message Transfer Agent 44 (MTA) service or a Directory Service Agent (DSA) service. It is expected 45 that further MIBs of this nature will be specified. 47 This MIB does not attempt to provide facilities for management of the 48 host or hosts the network service application runs on, nor does it 49 provide facilities for monitoring applications that provide something 50 other than a network service. Host resource and general application 51 monitoring is handled by the Host Resources MIB. 53 2. Table of Contents 55 1 Introduction .................................................... 1 56 2 Table of Contents ............................................... 2 57 3 The SNMPv2 Network Management Framework ......................... 2 58 3.1 Object Definitions ............................................ 3 59 4 Rationale for having a Network Services Monitoring MIB .......... 3 60 4.1 General Relationship to Other MIBs ............................ 4 61 4.2 Restriction of Scope .......................................... 4 62 4.3 Relationship to Directory Services ............................ 5 63 5 Application Objects ............................................. 5 64 6 Definitions ..................................................... 6 65 7 Changes made since RFC 1565 ..................................... 19 66 8 Acknowledgements ................................................ 20 67 9 References ...................................................... 20 68 10 Security Considerations ........................................ 20 69 11 Authors' Addresses ............................................. 21 71 3. The SNMPv2 Network Management Framework 73 The SNMPv2 Network Management Framework consists of four major 74 components. They are: 76 o RFC 1902 [1] which defines the SMI, the mechanisms used for 77 describing and naming objects for the purpose of management. 79 o RFC 1213 [2] defines MIB-II, the core set of managed objects for 80 the Internet suite of protocols. 82 o RFC 1445 [3] which defines the administrative and other 83 architectural aspects of the framework. 85 o RFC 1905 [4] which defines the protocol used for network access to 86 managed objects. 88 The Framework permits new objects to be defined for the purpose of 89 experimentation and evaluation. 91 3.1. Object Definitions 93 Managed objects are accessed via a virtual information store, termed the 94 Management Information Base or MIB. Objects in the MIB are defined using 95 the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. 96 In particular, each object type is named by an OBJECT IDENTIFIER, an 97 administratively assigned name. The object type together with an object 98 instance serves to uniquely identify a specific instantiation of the 99 object. For human convenience, we often use a textual string, termed 100 the descriptor, to refer to the object type. 102 4. Rationale for having a Network Services Monitoring MIB 104 Much effort has been expended in developing tools to manage lower layer 105 network facilities. However, relatively little work has been done on 106 managing application layer entities. It is neither efficient nor 107 reasonable to manage all aspects of application layer entities using 108 only lower layer information. Moreover, the difficulty of managing 109 application entities in this way increases dramatically as application 110 entities become more complex. 112 This leads to a substantial need to monitor applications which provide 113 network services, particularly distributed components such as MTAs and 114 DSAs, by monitoring specific aspects of the application itself. Reasons 115 to monitor such components include but are not limited to measuring 116 load, detecting broken connectivity, isolating system failures, and 117 locating congestion. 119 In order to manage network service applications effectively two 120 requirements must be met: 122 (1) It must be possible to monitor a large number of components 123 (typical for a large organization). 125 (2) Application monitoring must be integrated into general network 126 management. 128 This specification defines simple read-only access; this is sufficient 129 to determine up/down status and provide an indication of a broad class 130 of operational problems. 132 4.1. General Relationship to Other MIBs 134 This MIB is intended to only provide facilities common to the monitoring 135 of any network service application. It does not provide all the 136 facilities necessary to monitor any specific application. Each specific 137 type of network service application is expected to have a MIB of its own 138 that makes use of these common facilities. 140 4.2. Restriction of Scope 142 The framework provided here is very minimal; there is a lot more that 143 could be done. For example: 145 (1) General network service application configuration monitoring and 146 control. 148 (2) Detailed examination and modification of individual entries in 149 service-specific request queues. 151 (3) Probing to determine the status of a specific request (e.g. the 152 location of a mail message with a specific message-id). 154 (4) Requesting that certain actions be performed (e.g. forcing an 155 immediate connection and transfer of pending messages to some 156 specific system). 158 All these capabilities are both impressive and useful. However, these 159 capabilities would require provisions for strict security checking. 160 These capabilities would also mandate a much more complex design, with 161 many characteristics likely to be fairly implementation-specific. As a 162 result such facilities are likely to be both contentious and difficult 163 to implement. 165 This document religiously keeps things simple and focuses on the basic 166 monitoring aspect of managing applications providing network services. 167 The goal here is to provide a framework which is simple, useful, and 168 widely implementable. 170 4.3. Relationship to Directory Services 172 Use of and management of directory services already is tied up with 173 network service application management. There are clearly many things 174 which could be dealt with by directory services and protocols. We take 175 the line here that static configuration information is both provided by 176 and dealt with by directory services and protocols. The emphasis here 177 is on transient application status. 179 By placing static information in the directory, the richness and linkage 180 of the directory information framework does not need to be repeated in 181 the MIB. Static information is information which has a mean time to 182 change of the order of days or longer. 184 When information about network service applications is stored in the 185 directory (regardless of whether or not the network service application 186 makes direct use of the directory), it is recommended that a linkage be 187 established, so that: 189 (1) The managed object contains its own directory name. This allows 190 all directory information to be obtained by reference. This will 191 let a SNMP monitor capable of performing directory queries 192 present this information to the manager in an appropriate format. 193 It is intended that this will be the normal case. 195 (2) The directory will reference the location of the SNMP agent, so 196 that an SNMP capable directory query agent could probe dynamic 197 characteristics of the object. 199 (3) This approach could be extended further, so that the SNMP 200 attributes are modelled as directory attributes. This would 201 dramatically simplify the design of directory service agents that 202 use SNMP to obtain the information they need. 204 5. Application Objects 206 This MIB defines a set of general purpose attributes which would be 207 appropriate for a range of applications that provide network services. 208 Both OSI and non-OSI services can be accomodated. Additional tables 209 defined in extensions to this MIB provide attributes specific to 210 specific network services. 212 A table is defined which will have one row for each operational network 213 service application on the system. The only static information held on 214 the application is its name. All other static information should be 215 obtained from various directory services. The applDirectoryName is an 216 external key, which allows an SNMP MIB entry to be cleanly related to 217 the X.500 Directory. In SNMP terms, the applications are grouped in a 218 table called applTable, which is indexed by an integer key applIndex. 220 The type of the application will be determined by one or both of: 222 (1) Additional MIB variables specific to the applications. 224 (2) An association to the application of a specific protocol. 226 6. Definitions 228 APPLICATION-MIB DEFINITIONS ::= BEGIN 230 IMPORTS 231 OBJECT-TYPE, Counter32, Gauge32, MODULE-IDENTITY 232 FROM SNMPv2-SMI 233 mib-2 234 FROM RFC1213-MIB 235 DisplayString, TimeStamp, TEXTUAL-CONVENTION 236 FROM SNMPv2-TC 237 MODULE-COMPLIANCE, OBJECT-GROUP 238 FROM SNMPv2-CONF; 240 -- Textual conventions 242 -- DistinguishedName is used to refer to objects in the 243 -- directory. 245 DistinguishedName ::= TEXTUAL-CONVENTION 246 STATUS current 247 DESCRIPTION 248 "A Distinguished Name represented in accordance with 249 RFC 1779 [5]." 250 SYNTAX DisplayString 252 -- Uniform Resource Locators are stored in URLStrings. 254 URLString ::= TEXTUAL-CONVENTION 255 STATUS current 256 DESCRIPTION 257 "A Uniform Resource Locator represented in accordance 258 with RFC 1738 [7]." 259 SYNTAX DisplayString 261 application MODULE-IDENTITY 262 LAST-UPDATED "9603100000Z" 263 ORGANIZATION "IETF Mail and Directory Management Working Group" 264 CONTACT-INFO 265 " Ned Freed 267 Postal: Innosoft International, Inc. 268 1050 East Garvey Avenue South 269 West Covina, CA 91790 270 US 272 Tel: +1 818 919 3600 273 Fax: +1 818 919 3614 275 E-Mail: ned@innosoft.com" 276 DESCRIPTION 277 "The MIB module describing network service applications" 278 ::= {mib-2 27} 280 -- The basic applTable contains a list of the application 281 -- entities. 283 applTable OBJECT-TYPE 284 SYNTAX SEQUENCE OF ApplEntry 285 MAX-ACCESS not-accessible 286 STATUS current 287 DESCRIPTION 288 "The table holding objects which apply to all different 289 kinds of applications providing network services. 290 Each network service application capable of being 291 monitored should have a single entry in this table." 292 ::= {application 1} 294 applEntry OBJECT-TYPE 295 SYNTAX ApplEntry 296 MAX-ACCESS not-accessible 297 STATUS current 298 DESCRIPTION 299 "An entry associated with a single network service 300 application." 301 INDEX {applIndex} 302 ::= {applTable 1} 304 ApplEntry ::= SEQUENCE { 305 applIndex 306 INTEGER, 307 applName 308 DisplayString, 309 applDirectoryName 310 DistinguishedName, 311 applVersion 312 DisplayString, 313 applUptime 314 TimeStamp, 315 applOperStatus 316 INTEGER, 317 applLastChange 318 TimeStamp, 319 applInboundAssociations 320 Gauge32, 321 applOutboundAssociations 322 Gauge32, 323 applAccumulatedInboundAssociations 324 Counter32, 325 applAccumulatedOutboundAssociations 326 Counter32, 327 applLastInboundActivity 328 TimeStamp, 329 applLastOutboundActivity 330 TimeStamp, 331 applRejectedInboundAssociations 332 Counter32, 333 applFailedOutboundAssociations 334 Counter32, 336 applDescription 337 DisplayString, 338 applURL 339 URLString 340 } 342 applIndex OBJECT-TYPE 343 SYNTAX INTEGER (1..2147483647) 344 MAX-ACCESS not-accessible 345 STATUS current 346 DESCRIPTION 347 "An index to uniquely identify the network service 348 application. This attribute is the index used for 349 lexicographic ordering of the table." 350 ::= {applEntry 1} 352 applName OBJECT-TYPE 353 SYNTAX DisplayString 354 MAX-ACCESS read-only 355 STATUS current 356 DESCRIPTION 357 "The name the network service application chooses to be 358 known by." 359 ::= {applEntry 2} 361 applDirectoryName OBJECT-TYPE 362 SYNTAX DistinguishedName 363 MAX-ACCESS read-only 364 STATUS current 365 DESCRIPTION 366 "The Distinguished Name of the directory entry where 367 static information about this application is stored. 368 An empty string indicates that no information about 369 the application is available in the directory." 370 ::= {applEntry 3} 372 applVersion OBJECT-TYPE 373 SYNTAX DisplayString 374 MAX-ACCESS read-only 375 STATUS current 376 DESCRIPTION 377 "The version of network service application software. 378 This field is usually defined by the vendor of the 379 network service application software." 380 ::= {applEntry 4} 382 applUptime OBJECT-TYPE 383 SYNTAX TimeStamp 384 MAX-ACCESS read-only 385 STATUS current 386 DESCRIPTION 387 "The value of sysUpTime at the time the network service 388 application was last initialized. If the application was 389 last initialized prior to the last initialization of the 390 network management subsystem, then this object contains 391 a zero value." 392 ::= {applEntry 5} 394 applOperStatus OBJECT-TYPE 395 SYNTAX INTEGER { 396 up(1), 397 down(2), 398 halted(3), 399 congested(4), 400 restarting(5), 401 quiescing(6) 402 } 403 MAX-ACCESS read-only 404 STATUS current 405 DESCRIPTION 406 "Indicates the operational status of the network service 407 application. 'down' indicates that the network service is 408 not available. 'up' indicates that the network service 409 is operational and available. 'halted' indicates that the 410 service is operational but not available. 'congested' 411 indicates that the service is operational but no additional 412 inbound associations can be accomodated. 'restarting' 413 indicates that the service is currently unavailable but is 414 in the process of restarting and will be available soon. 415 'quiescing' indicates that service is currently operational 416 but is in the process of shutting down. Additional inbound 417 associations may be rejected by applications in the 418 'quiescing' state." 419 ::= {applEntry 6} 421 applLastChange OBJECT-TYPE 422 SYNTAX TimeStamp 423 MAX-ACCESS read-only 424 STATUS current 425 DESCRIPTION 426 "The value of sysUpTime at the time the network service 427 application entered its current operational state. If 428 the current state was entered prior to the last 429 initialization of the local network management subsystem, 430 then this object contains a zero value." 431 ::= {applEntry 7} 433 applInboundAssociations OBJECT-TYPE 434 SYNTAX Gauge32 435 MAX-ACCESS read-only 436 STATUS current 437 DESCRIPTION 438 "The number of current associations to the network service 439 application, where it is the responder. An inbound 440 assocation occurs when a another application successfully 441 connects to this one." 442 ::= {applEntry 8} 444 applOutboundAssociations OBJECT-TYPE 445 SYNTAX Gauge32 446 MAX-ACCESS read-only 447 STATUS current 448 DESCRIPTION 449 "The number of current associations to the network service 450 application, where it is the initiator. An outbound 451 association occurs when this application successfully 452 connects to another one." 453 ::= {applEntry 9} 455 applAccumulatedInboundAssociations OBJECT-TYPE 456 SYNTAX Counter32 457 MAX-ACCESS read-only 458 STATUS current 459 DESCRIPTION 460 "The total number of associations to the application entity 461 since application initialization, where it was the responder." 462 ::= {applEntry 10} 464 applAccumulatedOutboundAssociations OBJECT-TYPE 465 SYNTAX Counter32 466 MAX-ACCESS read-only 467 STATUS current 468 DESCRIPTION 469 "The total number of associations to the application entity 470 since application initialization, where it was the initiator." 471 ::= {applEntry 11} 473 applLastInboundActivity OBJECT-TYPE 474 SYNTAX TimeStamp 475 MAX-ACCESS read-only 476 STATUS current 477 DESCRIPTION 478 "The value of sysUpTime at the time this application last 479 had an inbound association. If the last association 480 occurred prior to the last initialization of the network 481 subsystem, then this object contains a zero value." 482 ::= {applEntry 12} 484 applLastOutboundActivity OBJECT-TYPE 485 SYNTAX TimeStamp 486 MAX-ACCESS read-only 487 STATUS current 488 DESCRIPTION 489 "The value of sysUpTime at the time this application last 490 had an outbound association. If the last association 491 occurred prior to the last initialization of the network 492 subsystem, then this object contains a zero value." 493 ::= {applEntry 13} 495 applRejectedInboundAssociations OBJECT-TYPE 496 SYNTAX Counter32 497 MAX-ACCESS read-only 498 STATUS current 499 DESCRIPTION 500 "The total number of inbound associations the application 501 entity has rejected, since application initialization. 502 Rejected associations are not counted in the accumulated 503 association totals. Note that this only counts 504 associations the application entity has rejected itself; 505 it does not count rejections that occur at lower layers 506 of the network. Thus, this counter may not reflect the 507 true number of failed inbound associations." 508 ::= {applEntry 14} 510 applFailedOutboundAssociations OBJECT-TYPE 511 SYNTAX Counter32 512 MAX-ACCESS read-only 513 STATUS current 514 DESCRIPTION 515 "The total number associations where the application entity 516 is initiator and association establishment has failed, 517 since application initialization. Failed associations are 518 not counted in the accumulated association totals." 519 ::= {applEntry 15} 521 applDescription OBJECT-TYPE 522 SYNTAX DisplayString 523 MAX-ACCESS read-only 524 STATUS current 525 DESCRIPTION 526 "A description of the application. This information 527 is intended to identify the application in a status 528 display." 529 ::= {applEntry 16} 531 applURL OBJECT-TYPE 532 SYNTAX URLString 533 MAX-ACCESS read-only 534 STATUS current 535 DESCRIPTION 536 "A URL pointing to a description of the application. 537 This information is intended to identify and describe 538 the application in a status display." 539 ::= {applEntry 17} 541 -- The assocTable augments the information in the applTable 542 -- with information about associations. Note that two levels 543 -- of compliance are specified below, depending on whether 544 -- association monitoring is mandated. 546 assocTable OBJECT-TYPE 547 SYNTAX SEQUENCE OF AssocEntry 548 MAX-ACCESS not-accessible 549 STATUS current 550 DESCRIPTION 551 "The table holding a set of all active application 552 associations." 553 ::= {application 2} 555 assocEntry OBJECT-TYPE 556 SYNTAX AssocEntry 557 MAX-ACCESS not-accessible 558 STATUS current 559 DESCRIPTION 560 "An entry associated with an association for a network 561 service application." 562 INDEX {applIndex, assocIndex} 563 ::= {assocTable 1} 565 AssocEntry ::= SEQUENCE { 566 assocIndex 567 INTEGER, 568 assocRemoteApplication 569 DisplayString, 570 assocApplicationProtocol 571 OBJECT IDENTIFIER, 572 assocApplicationType 573 INTEGER, 574 assocDuration 575 TimeStamp 576 } 578 assocIndex OBJECT-TYPE 579 SYNTAX INTEGER (1..2147483647) 580 MAX-ACCESS not-accessible 581 STATUS current 582 DESCRIPTION 583 "An index to uniquely identify each association for a network 584 service application. This attribute is the index that is 585 used for lexicographic ordering of the table. Note that the 586 table is also indexed by the applIndex." 587 ::= {assocEntry 1} 589 assocRemoteApplication OBJECT-TYPE 590 SYNTAX DisplayString 591 MAX-ACCESS read-only 592 STATUS current 593 DESCRIPTION 594 "The name of the system running remote network service 595 application. For an IP-based application this should be 596 either a domain name or IP address. For an OSI application 597 it should be the string encoded distinguished name of the 598 managed object. For X.400(1984) MTAs which do not have a 599 Distinguished Name, the RFC 1327 [6] syntax 600 'mta in globalid' should be used. Note, however, that not 601 all connections an MTA are necessarily to another MTA." 602 ::= {assocEntry 2} 604 assocApplicationProtocol OBJECT-TYPE 605 SYNTAX OBJECT IDENTIFIER 606 MAX-ACCESS read-only 607 STATUS current 608 DESCRIPTION 609 "An identification of the protocol being used for the 610 application. For an OSI Application, this will be the 611 Application Context. For Internet applications, the IANA 612 maintains a registry of the OIDs which correspond to 613 well-known applications. If the application protocol is 614 not listed in the registry, an OID value of the form 615 {applTCPProtoID port} or {applUDProtoID port} are used for 616 TCP-based and UDP-based protocols, respectively. In either 617 case 'port' corresponds to the primary port number being 618 used by the protocol." 619 ::= {assocEntry 3} 621 assocApplicationType OBJECT-TYPE 622 SYNTAX INTEGER { 623 ua-initiator(1), 624 ua-responder(2), 625 peer-initiator(3), 626 peer-responder(4)} 627 MAX-ACCESS read-only 628 STATUS current 629 DESCRIPTION 630 "This indicates whether the remote application is some type of 631 client making use of this network service (e.g. a User Agent) 632 or a server acting as a peer. Also indicated is whether the 633 remote end initiated an incoming connection to the network 634 service or responded to an outgoing connection made by the 635 local application. MTAs and messaging gateways are 636 considered to be peers for the purposes of this variable." 637 ::= {assocEntry 4} 639 assocDuration OBJECT-TYPE 640 SYNTAX TimeStamp 641 MAX-ACCESS read-only 642 STATUS current 643 DESCRIPTION 644 "The value of sysUpTime at the time this association was 645 started. If this association started prior to the last 646 initialization of the network subsystem, then this 647 object contains a zero value." 648 ::= {assocEntry 5} 650 -- Conformance information 652 applConformance OBJECT IDENTIFIER ::= {application 3} 654 applGroups OBJECT IDENTIFIER ::= {applConformance 1} 655 applCompliances OBJECT IDENTIFIER ::= {applConformance 2} 656 -- Compliance statements 658 applCompliance MODULE-COMPLIANCE 659 STATUS current 660 DESCRIPTION 661 "The compliance statement for SNMPv2 entities 662 which implement the Network Services Monitoring MIB 663 for basic monitoring of network service applications." 664 MODULE -- this module 665 MANDATORY-GROUPS {applGroup} 666 ::= {applCompliances 1} 668 assocCompliance MODULE-COMPLIANCE 669 STATUS current 670 DESCRIPTION 671 "The compliance statement for SNMPv2 entities which 672 implement the Network Services Monitoring MIB for basic 673 monitoring of network service applications and their 674 associations." 675 MODULE -- this module 676 MANDATORY-GROUPS {applGroup, assocGroup} 677 ::= {applCompliances 2} 679 -- Units of conformance 681 applGroup OBJECT-GROUP 682 OBJECTS { 683 applName, applVersion, applUptime, applOperStatus, 684 applLastChange, applInboundAssociations, 685 applOutboundAssociations, applAccumulatedInboundAssociations, 686 applAccumulatedOutboundAssociations, applLastInboundActivity, 687 applLastOutboundActivity, applRejectedInboundAssociations, 688 applFailedOutboundAssociations, applDescription, applURL} 689 STATUS current 690 DESCRIPTION 691 "A collection of objects providing basic monitoring of 692 network service applications." 693 ::= {applGroups 1} 695 assocGroup OBJECT-GROUP 696 OBJECTS { 697 assocRemoteApplication, assocApplicationProtocol, 698 assocApplicationType, assocDuration} 699 STATUS current 700 DESCRIPTION 701 "A collection of objects providing basic monitoring of 702 network service applications' associations." 703 ::= {applGroups 2} 705 -- OIDs of the form {applTCPProtoID port} are intended to be used 706 -- for TCP-based protocols that don't have OIDs assigned by other 707 -- means. {applUDPProtoID port} serves the same purpose for 708 -- UDP-based protocols. In either case 'port' corresponds to 709 -- the primary port number being used by the protocol. For example, 710 -- assuming no other OID is assigned for SMTP, an OID of 711 -- {applTCPProtoID 25} could be used, since SMTP is a TCP-based 712 -- protocol that uses port 25 as its primary port. 714 applTCPProtoID OBJECT IDENTIFIER ::= {application 4} 715 applUDPProtoID OBJECT IDENTIFIER ::= {application 5} 717 END 718 7. Changes made since RFC 1565 720 The only changes made to this document since it was issued as RFC 1565 721 [8] are the following: 723 (1) applDescription and applURL fields have been added. These fields 724 are intended to identify and describe the application. 726 (2) A number of DESCRIPTION fields have been reworded, hopefully 727 making them clearer. 729 (3) The new "quiescing" state has been addedto applOperStatus. 731 (4) The prose about "dynamic single threaded processes" has been 732 removed -- it was simply too confusing. 734 (5) Various RFC references have been updated to refer to more recent 735 versions. 737 8. Acknowledgements 739 This document is a product of the Mail and Directory Management (MADMAN) 740 Working Group. It is based on an earlier MIB designed by S. Kille, T. 741 Lenggenhager, D. Partain, and W. Yeong. The Electronic Mail 742 Association's TSC committee was instrumental in providing feedback on 743 and suggesting enhancements to RFC 1565 [8] that have led to the present 744 document. 746 9. References 748 [1] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure 749 of Management Information for Version 2 of the Simple Network 750 Management Protocol (SNMPv2)", RFC 1902, January 1996. 752 [2] McCloghrie, K., and Rose, M., Editors, "Management Information Base 753 for Network Management of TCP/IP-based internets: MIB-II", STD 17, 754 RFC 1213, March 1991. 756 [3] Galvin, J., McCloghrie, K., " Administrative Model for version 2 of 757 the Simple Network Management Protocol (SNMPv2)", RFC 1445, April 758 1993. 760 [4] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol 761 Operations for Version 2 of the Simple Network Management Protocol 762 (SNMPv2)", RFC 1905, January 1996. 764 [5] Kille, S., "A String Representation of Distinguished Names", RFC 765 1779, March 1995. 767 [6] Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC 822", 768 RFC 1327, May 1992. 770 [7] Berners-Lee, T., Masinter, L., McCahill, M., iform Resource 771 Locators (URL)", RFC 1738, December 1994. 773 [8] Freed, N., Kille, S., "Network Services Monitoring MIB", RFC 1565, 774 January 1994. 776 10. Security Considerations 778 Security issues are not discussed in this memo. 780 11. Authors' Addresses 782 Ned Freed, Editor 783 Innosoft International, Inc. 784 1050 East Garvey Avenue South 785 West Covina, CA 91790 786 USA 787 tel: +1 818 919 3600 788 fax: +1 818 919 3614 789 email: ned@innosoft.com 791 Steve Kille, WG Chair 792 ISODE Consortium 793 The Dome, The Square 794 Richmond TW9 1DT 795 UK 796 tel: +44 181 332 9091 797 email: S.Kille@isode.com