idnits 2.17.1 draft-ietf-madman-nsm-mib-06.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-26) 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 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. -- The draft header indicates that this document obsoletes RFC1565, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 89 has weird spacing: '...defines trans...' == Line 731 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 (August 1997) is 9751 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 (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Ned Freed, Innosoft 3 Internet Draft Steve Kille, ISODE Consortium 4 Obsoletes: 1565 6 Network Services Monitoring MIB 8 August 1997 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 A networked application is a realization of some well defined service on 31 one or more host computers that is accessible via some network, uses 32 some network for its internal operations, or both. 34 There are a wide range of networked applications for which it is 35 appropriate to provide SNMP monitoring of their network usage. This 36 includes applications using both TCP/IP and OSI networking. This 37 document defines a MIB which contains the elements common to the 38 monitoring of any network service application. This information 39 includes a table of all monitorable network service applications, a 40 count of the associations (connections) to each application, and basic 41 information about the parameters and status of each application-related 42 association. 44 This MIB may be used on its own for any application, and for most simple 45 applications this will suffice. This MIB is also designed to serve as a 46 building block which can be used in conjunction with application- 47 specific monitoring and management. Two examples of this are MIBs 48 defining additional variables for monitoring a Message Transfer Agent 49 (MTA) service or a Directory Service Agent (DSA) service. It is expected 50 that further MIBs of this nature will be specified. 52 This MIB does not attempt to provide facilities for management of the 53 host or hosts the network service application runs on, nor does it 54 provide facilities for monitoring applications that provide something 55 other than a network service. Host resource and general application 56 monitoring is handled by the Host Resources MIB at present; development 57 of an additional application MIB is currently underway in the IETF. 59 2. Table of Contents 61 1 Introduction .................................................... 1 62 2 Table of Contents ............................................... 2 63 3 The SNMPv2 Network Management Framework ......................... 2 64 3.1 Object Definitions ............................................ 3 65 4 Rationale for having a Network Services Monitoring MIB .......... 3 66 4.1 General Relationship to Other MIBs ............................ 4 67 4.2 Restriction of Scope .......................................... 4 68 4.3 Configuration Information ..................................... 5 69 5 Application Objects ............................................. 5 70 6 Definitions ..................................................... 5 71 7 Changes made since RFC 1565 ..................................... 19 72 8 Acknowledgements ................................................ 20 73 9 References ...................................................... 20 74 10 Security Considerations ........................................ 21 75 11 Author and Chair Addresses ..................................... 21 77 3. The SNMPv2 Network Management Framework 79 The SNMPv2 Network Management Framework consists of seven major 80 components. They are: 82 o RFC 1902 [1] which defines the SMI, the mechanisms used for 83 describing and naming objects for the purpose of management. 85 o RFC 1903 [2] defines textual conventions for SNMPv2. 87 o RFC 1904 [3] defines conformance statements for SNMPv2. 89 o RFC 1905 [4] defines transport mappings for SNMPv2. 91 o RFC 1906 [5] defines the protocol operations used for network 92 access to managed objects. 94 o RFC 1907 [6] defines the Management Information Base for SNMPv2. 96 o RFC 1908 [7] specifies coexistance between SNMP and SNMPv2. 98 The Framework permits new objects to be defined for the purpose of 99 experimentation and evaluation. 101 3.1. Object Definitions 103 Managed objects are accessed via a virtual information store, termed the 104 Management Information Base or MIB. Objects in the MIB are defined using 105 the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. 106 In particular, each object type is named by an OBJECT IDENTIFIER, an 107 administratively assigned name. The object type together with an object 108 instance serves to uniquely identify a specific instantiation of the 109 object. For human convenience, we often use a textual string, termed 110 the descriptor, to refer to the object type. 112 4. Rationale for having a Network Services Monitoring MIB 114 Much effort has been expended in developing tools to manage lower layer 115 network facilities. However, relatively little work has been done on 116 managing application layer entities. It is neither efficient nor 117 reasonable to manage all aspects of application layer entities using 118 only lower layer information. Moreover, the difficulty of managing 119 application entities in this way increases dramatically as application 120 entities become more complex. 122 This leads to a substantial need to monitor applications which provide 123 network services, particularly distributed components such as MTAs and 124 DSAs, by monitoring specific aspects of the application itself. Reasons 125 to monitor such components include but are not limited to measuring 126 load, detecting broken connectivity, isolating system failures, and 127 locating congestion. 129 In order to manage network service applications effectively two 130 requirements must be met: 132 (1) It must be possible to monitor a large number of components 133 (typical for a large organization). 135 (2) Application monitoring must be integrated into general network 136 management. 138 This specification defines simple read-only access; this is sufficient 139 to determine up/down status and provide an indication of a broad class 140 of operational problems. 142 4.1. General Relationship to Other MIBs 144 This MIB is intended to only provide facilities common to the monitoring 145 of any network service application. It does not provide all the 146 facilities necessary to monitor any specific application. Each specific 147 type of network service application is expected to have a MIB of its own 148 that makes use of these common facilities. 150 4.2. Restriction of Scope 152 The framework provided here is very minimal; there is a lot more that 153 could be done. For example: 155 (1) General network service application configuration monitoring and 156 control. 158 (2) Detailed examination and modification of individual entries in 159 service-specific request queues. 161 (3) Probing to determine the status of a specific request (e.g. the 162 location of a mail message with a specific message-id). 164 (4) Requesting that certain actions be performed (e.g. forcing an 165 immediate connection and transfer of pending messages to some 166 specific system). 168 All these capabilities are both impressive and useful. However, these 169 capabilities would require provisions for strict security checking. 170 These capabilities would also mandate a much more complex design, with 171 many characteristics likely to be fairly implementation-specific. As a 172 result such facilities are likely to be both contentious and difficult 173 to implement. 175 This document religiously keeps things simple and focuses on the basic 176 monitoring aspect of managing applications providing network services. 177 The goal here is to provide a framework which is simple, useful, and 178 widely implementable. 180 4.3. Configuration Information 182 This MIB attempts to provide information about the operational aspects 183 of an application. Further information about the actual configuration of 184 a given application may be kept in other places; the applDirectoryName 185 or applURL may be used to point to places where such information is 186 kept. 188 5. Application Objects 190 This MIB defines a set of general purpose attributes which would be 191 appropriate for a range of applications that provide network services. 192 Both OSI and non-OSI services can be accomodated. Additional tables 193 defined in extensions to this MIB provide attributes specific to 194 specific network services. 196 A table is defined which will have one row for each operational network 197 service application on the system. The only static information held on 198 the application is its name. All other static information should be 199 obtained from various directory services. The applDirectoryName is an 200 external key, which allows an SNMP MIB entry to be cleanly related to 201 the X.500 Directory. In SNMP terms, the applications are grouped in a 202 table called applTable, which is indexed by an integer key applIndex. 204 The type of the application will be determined by one or both of: 206 (1) Additional MIB variables specific to the applications. 208 (2) An association to the application of a specific protocol. 210 6. Definitions 212 NETWORK-SERVICES-MIB DEFINITIONS ::= BEGIN 213 IMPORTS 214 OBJECT-TYPE, Counter32, Gauge32, MODULE-IDENTITY, mib-2 215 FROM SNMPv2-SMI 216 DisplayString, TimeStamp, TEXTUAL-CONVENTION 217 FROM SNMPv2-TC 218 MODULE-COMPLIANCE, OBJECT-GROUP 219 FROM SNMPv2-CONF; 221 application MODULE-IDENTITY 222 LAST-UPDATED "9708170000Z" 223 ORGANIZATION "IETF Mail and Directory Management Working Group" 224 CONTACT-INFO 225 " Ned Freed 227 Postal: Innosoft International, Inc. 228 1050 Lakes Drive 229 West Covina, CA 91790 230 US 232 Tel: +1 626 919 3600 233 Fax: +1 626 919 3614 235 E-Mail: ned.freed@innosoft.com" 236 DESCRIPTION 237 "The MIB module describing network service applications" 238 REVISION "9311280000Z" 239 DESCRIPTION 240 "The original version of this MIB was published in RFC 1565" 241 ::= {mib-2 27} 243 -- Textual conventions 245 -- DistinguishedName is used to refer to objects in the 246 -- directory. 248 DistinguishedName ::= TEXTUAL-CONVENTION 249 STATUS current 250 DESCRIPTION 251 "A Distinguished Name represented in accordance with 252 RFC 1779 [8]." 253 SYNTAX DisplayString 255 -- Uniform Resource Locators are stored in URLStrings. 257 URLString ::= TEXTUAL-CONVENTION 258 STATUS current 259 DESCRIPTION 260 "A Uniform Resource Locator represented in accordance 261 with RFC 1738 [10]." 262 SYNTAX DisplayString 264 -- The basic applTable contains a list of the application 265 -- entities. 267 applTable OBJECT-TYPE 268 SYNTAX SEQUENCE OF ApplEntry 269 MAX-ACCESS not-accessible 270 STATUS current 271 DESCRIPTION 272 "The table holding objects which apply to all different 273 kinds of applications providing network services. 274 Each network service application capable of being 275 monitored should have a single entry in this table." 276 ::= {application 1} 278 applEntry OBJECT-TYPE 279 SYNTAX ApplEntry 280 MAX-ACCESS not-accessible 281 STATUS current 282 DESCRIPTION 283 "An entry associated with a single network service 284 application." 285 INDEX {applIndex} 286 ::= {applTable 1} 288 ApplEntry ::= SEQUENCE { 289 applIndex 290 INTEGER, 291 applName 292 DisplayString, 293 applDirectoryName 294 DistinguishedName, 295 applVersion 296 DisplayString, 297 applUptime 298 TimeStamp, 299 applOperStatus 300 INTEGER, 301 applLastChange 302 TimeStamp, 303 applInboundAssociations 304 Gauge32, 305 applOutboundAssociations 306 Gauge32, 307 applAccumulatedInboundAssociations 308 Counter32, 309 applAccumulatedOutboundAssociations 310 Counter32, 311 applLastInboundActivity 312 TimeStamp, 313 applLastOutboundActivity 314 TimeStamp, 315 applRejectedInboundAssociations 316 Counter32, 317 applFailedOutboundAssociations 318 Counter32, 319 applDescription 320 DisplayString, 321 applURL 322 URLString 323 } 325 applIndex OBJECT-TYPE 326 SYNTAX INTEGER (1..2147483647) 327 MAX-ACCESS not-accessible 328 STATUS current 329 DESCRIPTION 330 "An index to uniquely identify the network service 331 application. This attribute is the index used for 332 lexicographic ordering of the table." 334 ::= {applEntry 1} 336 applName OBJECT-TYPE 337 SYNTAX DisplayString 338 MAX-ACCESS read-only 339 STATUS current 340 DESCRIPTION 341 "The name the network service application chooses to be 342 known by." 343 ::= {applEntry 2} 345 applDirectoryName OBJECT-TYPE 346 SYNTAX DistinguishedName 347 MAX-ACCESS read-only 348 STATUS current 349 DESCRIPTION 350 "The Distinguished Name of the directory entry where 351 static information about this application is stored. 352 An empty string indicates that no information about 353 the application is available in the directory." 354 ::= {applEntry 3} 356 applVersion OBJECT-TYPE 357 SYNTAX DisplayString 358 MAX-ACCESS read-only 359 STATUS current 360 DESCRIPTION 361 "The version of network service application software. 362 This field is usually defined by the vendor of the 363 network service application software." 364 ::= {applEntry 4} 366 applUptime OBJECT-TYPE 367 SYNTAX TimeStamp 368 MAX-ACCESS read-only 369 STATUS current 370 DESCRIPTION 371 "The value of sysUpTime at the time the network service 372 application was last initialized. If the application was 373 last initialized prior to the last initialization of the 374 network management subsystem, then this object contains 375 a zero value." 376 ::= {applEntry 5} 378 applOperStatus OBJECT-TYPE 379 SYNTAX INTEGER { 380 up(1), 381 down(2), 382 halted(3), 383 congested(4), 384 restarting(5), 385 quiescing(6) 386 } 387 MAX-ACCESS read-only 388 STATUS current 389 DESCRIPTION 390 "Indicates the operational status of the network service 391 application. 'down' indicates that the network service is 392 not available. 'up' indicates that the network service 393 is operational and available. 'halted' indicates that the 394 service is operational but not available. 'congested' 395 indicates that the service is operational but no additional 396 inbound associations can be accomodated. 'restarting' 397 indicates that the service is currently unavailable but is 398 in the process of restarting and will be available soon. 399 'quiescing' indicates that service is currently operational 400 but is in the process of shutting down. Additional inbound 401 associations may be rejected by applications in the 402 'quiescing' state." 403 ::= {applEntry 6} 405 applLastChange OBJECT-TYPE 406 SYNTAX TimeStamp 407 MAX-ACCESS read-only 408 STATUS current 409 DESCRIPTION 410 "The value of sysUpTime at the time the network service 411 application entered its current operational state. If 412 the current state was entered prior to the last 413 initialization of the local network management subsystem, 414 then this object contains a zero value." 415 ::= {applEntry 7} 417 applInboundAssociations OBJECT-TYPE 418 SYNTAX Gauge32 419 MAX-ACCESS read-only 420 STATUS current 421 DESCRIPTION 422 "The number of current associations to the network service 423 application, where it is the responder. An inbound 424 assocation occurs when a another application successfully 425 connects to this one." 426 ::= {applEntry 8} 428 applOutboundAssociations OBJECT-TYPE 429 SYNTAX Gauge32 430 MAX-ACCESS read-only 431 STATUS current 432 DESCRIPTION 433 "The number of current associations to the network service 434 application, where it is the initiator. An outbound 435 association occurs when this application successfully 436 connects to another one." 437 ::= {applEntry 9} 439 applAccumulatedInboundAssociations OBJECT-TYPE 440 SYNTAX Counter32 441 MAX-ACCESS read-only 442 STATUS current 443 DESCRIPTION 444 "The total number of associations to the application entity 445 since application initialization, where it was the responder." 446 ::= {applEntry 10} 448 applAccumulatedOutboundAssociations OBJECT-TYPE 449 SYNTAX Counter32 450 MAX-ACCESS read-only 451 STATUS current 452 DESCRIPTION 453 "The total number of associations to the application entity 454 since application initialization, where it was the initiator." 455 ::= {applEntry 11} 457 applLastInboundActivity OBJECT-TYPE 458 SYNTAX TimeStamp 459 MAX-ACCESS read-only 460 STATUS current 461 DESCRIPTION 462 "The value of sysUpTime at the time this application last 463 had an inbound association. If the last association 464 occurred prior to the last initialization of the network 465 subsystem, then this object contains a zero value." 466 ::= {applEntry 12} 468 applLastOutboundActivity OBJECT-TYPE 469 SYNTAX TimeStamp 470 MAX-ACCESS read-only 471 STATUS current 472 DESCRIPTION 473 "The value of sysUpTime at the time this application last 474 had an outbound association. If the last association 475 occurred prior to the last initialization of the network 476 subsystem, then this object contains a zero value." 477 ::= {applEntry 13} 479 applRejectedInboundAssociations OBJECT-TYPE 480 SYNTAX Counter32 481 MAX-ACCESS read-only 482 STATUS current 483 DESCRIPTION 484 "The total number of inbound associations the application 485 entity has rejected, since application initialization. 486 Rejected associations are not counted in the accumulated 487 association totals. Note that this only counts 488 associations the application entity has rejected itself; 489 it does not count rejections that occur at lower layers 490 of the network. Thus, this counter may not reflect the 491 true number of failed inbound associations." 492 ::= {applEntry 14} 494 applFailedOutboundAssociations OBJECT-TYPE 495 SYNTAX Counter32 496 MAX-ACCESS read-only 497 STATUS current 498 DESCRIPTION 499 "The total number associations where the application entity 500 is initiator and association establishment has failed, 501 since application initialization. Failed associations are 502 not counted in the accumulated association totals." 503 ::= {applEntry 15} 505 applDescription OBJECT-TYPE 506 SYNTAX DisplayString 507 MAX-ACCESS read-only 508 STATUS current 509 DESCRIPTION 510 "A text description of the application. This information 511 is intended to identify and briefly describe the 512 application in a status display." 513 ::= {applEntry 16} 515 applURL OBJECT-TYPE 516 SYNTAX URLString 517 MAX-ACCESS read-only 518 STATUS current 519 DESCRIPTION 520 "A URL pointing to a description of the application. 521 This information is intended to identify and describe 522 the application in a status display." 523 ::= {applEntry 17} 525 -- The assocTable augments the information in the applTable 526 -- with information about associations. Note that two levels 527 -- of compliance are specified below, depending on whether 528 -- association monitoring is mandated. 530 assocTable OBJECT-TYPE 531 SYNTAX SEQUENCE OF AssocEntry 532 MAX-ACCESS not-accessible 533 STATUS current 534 DESCRIPTION 535 "The table holding a set of all active application 536 associations." 537 ::= {application 2} 539 assocEntry OBJECT-TYPE 540 SYNTAX AssocEntry 541 MAX-ACCESS not-accessible 542 STATUS current 543 DESCRIPTION 544 "An entry associated with an association for a network 545 service application." 546 INDEX {applIndex, assocIndex} 547 ::= {assocTable 1} 549 AssocEntry ::= SEQUENCE { 550 assocIndex 551 INTEGER, 552 assocRemoteApplication 553 DisplayString, 554 assocApplicationProtocol 555 OBJECT IDENTIFIER, 556 assocApplicationType 557 INTEGER, 558 assocDuration 559 TimeStamp 560 } 562 assocIndex OBJECT-TYPE 563 SYNTAX INTEGER (1..2147483647) 564 MAX-ACCESS not-accessible 565 STATUS current 566 DESCRIPTION 567 "An index to uniquely identify each association for a network 568 service application. This attribute is the index that is 569 used for lexicographic ordering of the table. Note that the 570 table is also indexed by the applIndex." 571 ::= {assocEntry 1} 573 assocRemoteApplication OBJECT-TYPE 574 SYNTAX DisplayString 575 MAX-ACCESS read-only 576 STATUS current 577 DESCRIPTION 578 "The name of the system running remote network service 579 application. For an IP-based application this should be 580 either a domain name or IP address. For an OSI application 581 it should be the string encoded distinguished name of the 582 managed object. For X.400(1984) MTAs which do not have a 583 Distinguished Name, the RFC 1327 [9] syntax 584 'mta in globalid' should be used. Note, however, that not 585 all connections an MTA are necessarily to another MTA." 586 ::= {assocEntry 2} 588 assocApplicationProtocol OBJECT-TYPE 589 SYNTAX OBJECT IDENTIFIER 590 MAX-ACCESS read-only 591 STATUS current 592 DESCRIPTION 593 "An identification of the protocol being used for the 594 application. For an OSI Application, this will be the 595 Application Context. For Internet applications, the IANA 596 maintains a registry of the OIDs which correspond to 597 well-known applications. If the application protocol is 598 not listed in the registry, an OID value of the form 599 {applTCPProtoID port} or {applUDProtoID port} are used for 600 TCP-based and UDP-based protocols, respectively. In either 601 case 'port' corresponds to the primary port number being 602 used by the protocol." 603 ::= {assocEntry 3} 605 assocApplicationType OBJECT-TYPE 606 SYNTAX INTEGER { 607 ua-initiator(1), 608 ua-responder(2), 609 peer-initiator(3), 610 peer-responder(4)} 611 MAX-ACCESS read-only 612 STATUS current 613 DESCRIPTION 614 "This indicates whether the remote application is some type of 615 client making use of this network service (e.g. a Mail User 616 Agent) or a server acting as a peer. Also indicated is whether 617 the remote end initiated an incoming connection to the network 618 service or responded to an outgoing connection made by the 619 local application. MTAs and messaging gateways are 620 considered to be peers for the purposes of this variable." 621 ::= {assocEntry 4} 623 assocDuration OBJECT-TYPE 624 SYNTAX TimeStamp 625 MAX-ACCESS read-only 626 STATUS current 627 DESCRIPTION 628 "The value of sysUpTime at the time this association was 629 started. If this association started prior to the last 630 initialization of the network subsystem, then this 631 object contains a zero value." 632 ::= {assocEntry 5} 634 -- Conformance information 636 applConformance OBJECT IDENTIFIER ::= {application 3} 638 applGroups OBJECT IDENTIFIER ::= {applConformance 1} 639 applCompliances OBJECT IDENTIFIER ::= {applConformance 2} 640 -- Compliance statements 642 applCompliance MODULE-COMPLIANCE 643 STATUS current 644 DESCRIPTION 645 "The compliance statement for SNMPv2 entities 646 which implement the Network Services Monitoring MIB 647 for basic monitoring of network service applications." 648 MODULE -- this module 649 MANDATORY-GROUPS {applGroup} 650 ::= {applCompliances 1} 652 assocCompliance MODULE-COMPLIANCE 653 STATUS current 654 DESCRIPTION 655 "The compliance statement for SNMPv2 entities which 656 implement the Network Services Monitoring MIB for basic 657 monitoring of network service applications and their 658 associations." 659 MODULE -- this module 660 MANDATORY-GROUPS {applGroup, assocGroup} 661 ::= {applCompliances 2} 663 -- Units of conformance 665 applGroup OBJECT-GROUP 666 OBJECTS { 667 applName, applVersion, applUptime, applOperStatus, 668 applLastChange, applInboundAssociations, 669 applOutboundAssociations, applAccumulatedInboundAssociations, 670 applAccumulatedOutboundAssociations, applLastInboundActivity, 671 applLastOutboundActivity, applRejectedInboundAssociations, 672 applFailedOutboundAssociations, applDescription, applURL} 673 STATUS current 674 DESCRIPTION 675 "A collection of objects providing basic monitoring of 676 network service applications." 677 ::= {applGroups 1} 679 assocGroup OBJECT-GROUP 680 OBJECTS { 681 assocRemoteApplication, assocApplicationProtocol, 682 assocApplicationType, assocDuration} 683 STATUS current 684 DESCRIPTION 685 "A collection of objects providing basic monitoring of 686 network service applications' associations." 687 ::= {applGroups 2} 689 -- OIDs of the form {applTCPProtoID port} are intended to be used 690 -- for TCP-based protocols that don't have OIDs assigned by other 691 -- means. {applUDPProtoID port} serves the same purpose for 692 -- UDP-based protocols. In either case 'port' corresponds to 693 -- the primary port number being used by the protocol. For example, 694 -- assuming no other OID is assigned for SMTP, an OID of 695 -- {applTCPProtoID 25} could be used, since SMTP is a TCP-based 696 -- protocol that uses port 25 as its primary port. 698 applTCPProtoID OBJECT IDENTIFIER ::= {application 4} 699 applUDPProtoID OBJECT IDENTIFIER ::= {application 5} 701 END 702 7. Changes made since RFC 1565 704 The only changes made to this document since it was issued as RFC 1565 705 [11] are the following: 707 (1) applDescription and applURL fields have been added. These fields 708 are intended to identify and describe the application. 710 (2) A number of DESCRIPTION fields have been reworded, hopefully 711 making them clearer. 713 (3) The new "quiescing" state has been added to applOperStatus. 715 (4) The prose about "dynamic single threaded processes" has been 716 removed -- it was simply too confusing. 718 (5) Various RFC references have been updated to refer to more recent 719 versions. 721 (6) The MIB has been renamed from APPLICATION-MIB to NETWORK- 722 SERVICES-MIB. This was done because an application MIB is now 723 under development within the IETF that provides very different 724 functionality from this MIB. 726 8. Acknowledgements 728 This document is a product of the Mail and Directory Management (MADMAN) 729 Working Group. It is based on an earlier MIB designed by S. Kille, T. 730 Lenggenhager, D. Partain, and W. Yeong. The Electronic Mail 731 Association's TSC committee was instrumental in providing feedback on 732 and suggesting enhancements to RFC 1565 [11] that have led to the 733 present document. 735 9. References 737 [1] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Structure 738 of Management Information for Version 2 of the Simple Network 739 Management Protocol (SNMPv2)", RFC 1902, January 1996. 741 [2] Case, J., McCloghrie, K., Rose, M., Waldbusser, S., "Textual 742 Conventions for Version 2 of the Simple Network Management Protocol 743 (SNMPv2)", RFC 1903, January 1996. 745 [3] Case, J., McCloghrie, K., Rose, M., Waldbusser, S., "Conformance 746 Statements for Version 2 of the Simple Network Management Protocol 747 (SNMPv2)", RFC 1904, January 1996. 749 [4] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol 750 Operations for Version 2 of the Simple Network Management Protocol 751 (SNMPv2)", RFC 1905, January 1996. 753 [5] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Transport 754 Mappings for Version 2 of the Simple Network Management Protocol 755 (SNMPv2)", RFC 1906, January 1996. 757 [6] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Management 758 Information Base for Version 2 of the Simple Network Management 759 Protocol (SNMPv2)", RFC 1907, January 1996. 761 [7] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., 762 "Coexistence between Version 1 and Version 2 of the Internet- 763 standard Network Management Framework", RFC 1908, January 1996. 765 [8] Kille, S., "A String Representation of Distinguished Names", RFC 766 1779, March 1995. 768 [9] Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC 822", 769 RFC 1327, May 1992. 771 [10] Berners-Lee, T., Masinter, L., McCahill, M., iform Resource 772 Locators (URL)", RFC 1738, December 1994. 774 [11] Freed, N., Kille, S., "Network Services Monitoring MIB", RFC 1565, 775 January 1994. 777 10. Security Considerations 779 This MIB does not offer write access, and as such cannot be used to 780 actively attack a system. However, this MIB does provide passive 781 information about the existance, type, and configuration of applications 782 on a given host that could potentially indicate some sort of 783 vulnerability. Finally, the information MIB provides about network usage 784 could be used to analyze network traffic patterns. 786 11. Author and Chair Addresses 788 Ned Freed 789 Innosoft International, Inc. 790 1050 Lakes Drive 791 West Covina, CA 91790 792 USA 793 tel: +1 626 919 3600 794 fax: +1 626 919 3614 795 email: ned.freed@innosoft.com 797 Steve Kille, MADMAN WG Chair 798 ISODE Consortium 799 The Dome, The Square 800 Richmond TW9 1DT 801 UK 802 tel: +44 181 332 9091 803 email: S.Kille@isode.com