home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-madman-alarmmib-02.txt < prev    next >
Text File  |  1996-12-23  |  23KB  |  729 lines
  1.  
  2. MADMAN Working Group                 Gordon B. Jones [gbjones@mitre.org]
  3. INTERNET-DRAFT                                                     MITRE
  4. draft-ietf-madman-alarmmib-02.txt       Niraj Jain [njain@us.oracle.com]
  5.                                                       Oracle Corporation
  6.                                        Glenn Mansfield [glenn@aic.co.jp]
  7.                                                   AIC Systems Laboratory
  8.                                                         December    1996
  9.  
  10.  
  11.                        Mail and Directory Alarms
  12.  
  13.  
  14. Status of this Memo
  15.  
  16.    This document is an  Internet  Draft.  Internet  Drafts  are  working
  17.    documents  of  the Internet Engineering Task Force (IETF), its Areas,
  18.    and its Working Groups. Note that other groups  may  also  distribute
  19.    working documents as Internet Drafts.
  20.  
  21.    Internet Drafts are draft  documents  valid  for  a  maximum  of  six
  22.    months.  Internet  Drafts  may  be updated, replaced, or obsoleted by
  23.    other documents at any time.  It is not appropriate to  use  Internet
  24.    Drafts as reference material or to cite them other than as a "working
  25.    draft" or "work in progress."
  26.  
  27.    To learn the current status of any Internet-Draft, please  check  the
  28.    1id-abstracts.txt  listing  contained  in  the Internet-Drafts Shadow
  29.    Directories on ds.internic.net, nic.nordu.net,  ftp.nisc.sri.com,  or
  30.    munnari.oz.au.
  31.  
  32.  
  33. Abstract
  34.  
  35. This document defines alarms for Mail and Directory usage.  It is to be
  36. used in conjunction with the Mail and Directory Management (MADMAN) 
  37. RFCs.
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55. Expires: January 31, 1997                                     [Page 1]
  56.  
  57. Internet Draft                                             August 1996
  58.  
  59.  
  60. 1.The SNMPv2 Network Management Framework.
  61.  
  62.  
  63. 1.  The SNMPv2 Network Management Framework.
  64.  
  65.    The major components of the SNMPv2 Network Management framework  are
  66.    described in the documents listed below.
  67.  
  68.  
  69.         o RFC 1902 [1] defines the Structure of Management Information
  70.            (SMI), the mechanisms used for describing and naming objects
  71.            for the purpose of management.
  72.  
  73.         o STD 17, RFC 1213 [2] defines MIB-II, the core set of managed
  74.            objects (MO) for the Internet suite of protocols.
  75.  
  76.         o RFC 1905 [3] defines the protocol used for network access to
  77.            managed objects.
  78.  
  79.  
  80. The framework is adaptable/extensible by defining new MIBs to  suit  the
  81. requirements of specific applications/protocols/situations.
  82.  
  83. Managed objects are accessed via a virtual information store,  the  MIB.
  84. Objects  in  the  MIB  are  defined  using the subset of Abstract Syntax
  85. Notation One (ASN.1) defined in the SMI. In particular, each object type
  86. is  named by an OBJECT IDENTIFIER, which is an administratively assigned
  87. name. The object  type  together  with  an  object  instance  serves  to
  88. uniquely  identify  a  specific  instantiation  of the object. For human
  89. convenience, often a textual string, termed the descriptor, is  used  to
  90. refer to the object type.
  91.  
  92.  
  93. 2. The Need for Alarms in Messaging
  94.  
  95. Alarms are notifications of abnormalities associated with an  MTA  or  a
  96. message  processed  by  an  MTA.   Alarms  are generated by a Management
  97. Console.  Two facilities aid the Management Console in the generation of
  98. alarms.  The  first  facility is the trap, which is an unsolicited event
  99. initiated by  the  Management  Agent  and  directed  to  the  Management
  100. Console.   Traps  generated by an agent may optionally convey the values
  101. of MIB variables inside them.  The  Management  Console  interprets  the
  102. traps and generates alarms as it determines appropriate.
  103.  
  104. The second facility consists of variables that  can  be  polled  by  the
  105. Management  Console.  These variables include the existing MIB variables
  106. defined in the other  MADMAN  RFCs  (Network  Services  Monitoring  MIB,
  107. Directory  Services  Monitoring  MIB,  Mail  Monitoring  MIB), plus more
  108.  
  109.  
  110.  
  111. Expires: January 31, 1997                                     [Page 2]
  112.  
  113. Internet Draft                                             August 1996
  114.  
  115.  
  116. variables defined herein  specifically  to  augment  support  for  alarm
  117. generation.  If  the  Management  Console detects a variable value which
  118. indicates that a threshold has been reached,  or  some  other  worrisome
  119. trend  or  event  has  occurred,  it generates an alarm as it determines
  120. appropriate. It is expected that when an abnormality occurs, a trap will
  121. be  generated indicating the specific cause of the problem.  If the trap
  122. is lost or discarded by the network, the console may  still  detect  the
  123. abnormality  on its next regular polling cycle through inspection of the
  124. MIB variables.  This combination of mechanisms provides a flexible alarm
  125. functionality that is either event-driven, polling-driven, or both.
  126.  
  127. It is understood that traps are an unreliable mechanism.  However, traps
  128. may  enhance the effects of polling-based alarms.  This is because traps
  129. can provide a more immediate discovery of a problem than  polling  alone
  130. can,  which  may be important within some operational environments.  For
  131. example, when component  availability  is  required  to  exceed  99%,  a
  132. polling  cycle  consisting  of  fifteen  minute intervals to detect if a
  133. component is operational may fail this  requirement.   A  polling  cycle
  134. more  frequent than fifteen minutes might saturate the network with SNMP
  135. traffic. When a fifteen minute polling cycle  with  99%  reliability  is
  136. combined with an event-driven mechanism that is itself 99% reliable, the
  137. probability that a given component  failure  goes  undetected,  if  both
  138. event-driven  and  polled,  becomes  less  than one one-hundredth of one
  139. percent.  This scenario is  also  applicable  to  the  case  of  message
  140. throughput  requirements, where the detection of queue saturation may be
  141. both event-driven and polling-driven.
  142.  
  143. Alarms  denote  cases  where  outstanding  intervention   is   required.
  144. Implementations that result in a bombardment of superfluous traps should
  145. be avoided (some fault conditions may lend themselves to  this).   Traps
  146. should  not be issued repetitively to signify one basic fault condition.
  147. The  setting  of  threshold  conditions  and  the  evaluation  of  other
  148. composite  information  is  the  responsibility  of the console, or is a
  149. local implementation matter within the agent.  The destinations of  SNMP
  150. traps  as  selected  by  the SNMP agents or applications is also a local
  151. matter.
  152.  
  153.  
  154. 3. MIB Data to Support Alarms
  155.  
  156. The following material is a definition of the traps  and  MIB  variables
  157. defined   specifically  to  support  alarm  functionality.   The  MADMAN
  158. variables used to support alarms are defined in  the MADMAN MTA-MIB and
  159. APPLICATION-MIB.   The  usage  of these traps and MIB variables to fulfill 
  160. specific requirements is defined in a later section.
  161.  
  162.  
  163. 3.1 Traps to Support Alarms
  164.  
  165.  
  166.  
  167. Expires: January 31, 1997                                     [Page 3]
  168.  
  169. Internet Draft                                             August 1996
  170.  
  171.  
  172. Two forms of specific traps are defined to support alarms.   The  first,
  173. called mADAlarm, denotes an MTA- or DSA-related failure, and the second,
  174. messageAlarm, denotes a message-related failure in an MTA. A mADAlarm
  175. trap is generated by the agent in an unsolicited fashion to signify that
  176. a failure has occurred within the MTA or DSA.  Examples of such failures
  177. may include one MTA's inability to contact another MTA, or the detection
  178. of message queue saturation. The mADAlarm trap may convey  a  number  of
  179. values,  including the name of the MTA or DSA reporting the problem, the
  180. name of the remote MTA or  DSA  purportedly  causing  the  problem,  and
  181. variables  describing  the  problem  itself.  A messageAlarm trap is
  182. generated by the agent in an unsolicited fashion to signify that a  non-
  183. recoverable  failure  has  occurred  in processing a message due to some
  184. sort of structural flaw in the message  itself  or  in  its  addressing.
  185. Examples  may  include  cases where a message can not be delivered, non-
  186. delivered, or redirected,  or  the  case  where  a  messaging  loop  was
  187. detected. The messageAlarm trap may convey a number of values, including
  188. the name of the MTA that processed the message, and variables describing
  189. the problem itself.
  190.  
  191.  
  192. 3.2 MIB Variables to Support Alarms
  193.  
  194. A new table is defined in the MIB to supply supplementary  fault-related
  195. information  to  support  alarm  generation.  When a failure occurs, the
  196. identities of the applications responsible  are  retained  in  the  MIB,
  197. along  with  the  ID of the message most recently involved in a failure.
  198. Through polling, any changes  in  the  values  of  these  variables  can
  199. signify  a recent failure. lastMessageIdFailure is  the  identifier  of
  200. the  most recent  message  that  was  the  cause  of a message-related 
  201. failure.  A message-related failure is defined to be a non-recoverable 
  202. error in  the processing  of a message.  In the event of multiple message 
  203. failures, it is a clue to the administrator or application  to  inspect
  204. the  message queues to determine which messages are defective. 
  205. numMessagesFailed is the total number of messages that have failed  
  206. processing  since  the messaging  application  was last initialized.  
  207. This variable may be used in conjunction with  lastMessageIdFailure  to  
  208. detect  multiple  message failures  within  a single unit of time. 
  209. lastFailureMtaGroupName is used when an error involving a  neighboring  
  210. MTA  occurs;  this  variable  holds  the mtaGroupName  (from  the  MADMAN
  211. mtaGroupTable) of the MTA most recently involved in a  failure.  
  212. lastFailureApplName holds  the applName  (from  the  MADMAN  applTable)  
  213. of  the MTA that most recently reported a failure.
  214.  
  215.  
  216. 4.  SNMP Format for Alarms
  217.  
  218. Alarms  are  supported  under  SNMP  using  traps  and  additional   MIB
  219.  
  220.  
  221.  
  222.  
  223. Expires: January 31, 1997                                     [Page 4]
  224.  
  225. Internet Draft                                             August 1996
  226.  
  227.  
  228. variables.  An additional  table  called mADAlarmTable has been defined.
  229. Elements of the existing MADMAN tables and proposed extensions are  also
  230. utilized  for  alarm  purposes.  It  is  expected  that  traps  will  be
  231. implemented under SNMP v1, but that the grammatical constructs  used  to
  232. define  them  are taken from SNMP v2. Page 31 of RFC 1157 shows how trap
  233. Protocol Data Units (PDUs) are formed in SNMP  v1.   We  would  add  two
  234. enterprise-specific  traps  (generic-trap  type  6)  whose specific-trap
  235. values are set to either  mADAlarm  (specific-trap  0)  or  messageAlarm
  236. (specific-trap  1).  The  enterprise field of the trap would contain the
  237. OID "experimental 73" designating the MADMAN  alarm  MIB  (MADAlarmMIB).
  238. The  values  of variables and their corresponding OBJECT IDENTIFIERs are
  239. conveyed within the VarBindList.   These  variables  are  obtained  from
  240. either the mADAlarmTable or tables found in the other MADMAN RFCs.
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279. Expires: January 31, 1997                                     [Page 5]
  280.  
  281. Internet Draft                                             August 1996
  282.  
  283.  
  284. MADMAN-ALARM-MIB DEFINITIONS ::= BEGIN
  285.  
  286.       IMPORTS
  287.         MODULE-IDENTITY,  OBJECT-TYPE,
  288.         NOTIFICATION-TYPE, experimental, Counter32, Gauge32
  289.               FROM SNMPv2-SMI
  290.         DisplayString,
  291.         TEXTUAL-CONVENTION
  292.               FROM SNMPv2-TC
  293.         applOperStatus,   applName
  294.               FROM APPLICATION-MIB
  295.         mtaGroupName,     mtaGroupInboundRejectionReason,
  296.         mtaGroupStoredVolume, mtaLoopsDetected, mtaGroupLoopsDetected,
  297.         mtaGroupOutboundConnectFailureReason
  298.               FROM MTA-MIB;
  299.  
  300. mADAlarmMIB MODULE-IDENTITY
  301. LAST-UPDATED "9608230000Z"
  302.            ORGANIZATION "IETF Mail and Directory Management Working
  303.                             Group"
  304.            CONTACT-INFO
  305.               "        Glenn Mansfield
  306.                Postal: AIC Systems Laboratory
  307.                        6-6-3, Minami Yoshinari
  308.                        Aoba-ku, Sendai, Japan 989-32.
  309.  
  310.                Tel:    +81-22-279-3310
  311.                Fax:    +81-22-279-3640
  312.                E-mail: glenn@aic.co.jp"
  313.             DESCRIPTION
  314.                "The MIB module describing alarms for MADMAN"
  315.    ::= { experimental 73 }
  316.  
  317.  mADAlarmTable OBJECT-TYPE
  318.      SYNTAX SEQUENCE OF mADAlarmEntry
  319.      ACCESS not-accessible
  320.      STATUS mandatory
  321.      DESCRIPTION
  322.           "The table holding alarm information for an individual MTA or DSA."
  323. ::= { mADAlarmMIB 1 }
  324.  
  325. mADAlarmEntry OBJECT-TYPE
  326.     SYNTAX mADAlarmEntry
  327.     ACCESS not-accessible
  328.     STATUS mandatory
  329.         DESCRIPTION
  330.           "The alarm entry associated with each MTA or DSA."
  331. ::= { mADAlarmTable 1 }
  332.  
  333.  
  334.  
  335. Expires: January 31, 1997                                     [Page 6]
  336.  
  337. Internet Draft                                             August 1996
  338.  
  339.  
  340. mADAlarmEntry ::= SEQUENCE {
  341.         lastMessageIdFailure DisplayString,
  342.         numMessagesFailed Counter32,
  343.         lastFailureMtaGroupName DisplayString,
  344.         lastFailureMtaApplName DisplayString
  345. }
  346.  
  347. lastMessageIdFailure OBJECT-TYPE
  348.        SYNTAX DisplayString
  349.        ACCESS read-only
  350.        STATUS mandatory
  351.        DESCRIPTION
  352.         "This is the message ID of the last message to either loop or have
  353.          an unrecoverable error while proccessing"
  354.        ::= {mADAlarmEntry 1}
  355.  
  356.  numMessagesFailed OBJECT-TYPE
  357.        SYNTAX Counter32
  358.        ACCESS read-only
  359.        STATUS mandatory
  360.        DESCRIPTION
  361.         "This is the number of messages that have had an unrecoverable error
  362.          while proccessing since MTA initialization"
  363.        ::= {mADAlarmEntry 2}
  364.  
  365. lastFailureMtaGroupName OBJECT-TYPE
  366.        SYNTAX DisplayString
  367.        ACCESS read-only
  368.        STATUS mandatory
  369.        DESCRIPTION
  370.         "This is the group name of the last MTA group to have a connectivity
  371.          failure"
  372.        ::= {mADAlarmEntry 3}
  373.  
  374. lastFailureMtaApplName OBJECT-TYPE
  375.        SYNTAX DisplayString
  376.        ACCESS read-only
  377.        STATUS mandatory
  378.        DESCRIPTION
  379.         "This is the application name of the last MTA to have a connectivity
  380.          failure"
  381.        ::= {mADAlarmEntry 4}
  382.  
  383.  
  384. mADAlarmNotifications OBJECT IDENTIFIER ::= { mADAlarmMIB 2 }
  385.  
  386. mADAlarm NOTIFICATION-TYPE
  387.         OBJECTS {applOperStatus, applName, mtaGroupName,
  388.  
  389.  
  390.  
  391. Expires: January 31, 1997                                     [Page 7]
  392.  
  393. Internet Draft                                             August 1996
  394.  
  395.  
  396.                  mtaGroupInboundRejectionReason,
  397.                  mtaGroupConnectFailureReason, mtaGroupStoredVolume}
  398.                  -- these OBJECTS are the things that an mADAlarm may convey
  399. ::= {mADAlarmNotifications 1}
  400.  
  401. messageAlarm NOTIFICATION-TYPE
  402.         OBJECTS {lastMessageIdFailure, numMessagesFailed,
  403.                  mtaGroupInboundRejectionReason}
  404. ::= {mADAlarmNotifications 2}
  405.  
  406. mADAlarmConformance OBJECT IDENTIFIER ::= {mADAlarmMIB 3}
  407. mADAlarmGroup  OBJECT IDENTIFIER ::= {mADAlarmConformance 1}
  408. mADAlarmCompliances  OBJECT IDENTIFIER ::= {mADAlarmConformance 2}
  409. mADAlarmTrapCompliance  MODULE-COMPLIANCE
  410.    STATUS current
  411.    DESCRIPTION
  412.       "The most basic level of compliance for MAD SNMPv2 entities that
  413. implement MAD alarms."
  414.    MODULE
  415.       MANDATORY-GROUPS {mADAlarmTrapGroup}
  416.    ::= {mADAlarmCompliances 1}
  417.  
  418. mADAlarmVariableCompliance  MODULE-COMPLIANCE
  419.    STATUS current
  420.    DESCRIPTION
  421.       "The compliance statement for MAD SNMPv2 entities that implement MIB
  422. variables to support
  423.        alarms for MTAs."
  424.    MODULE
  425.       MANDATORY-GROUPS {mADAlarmVariableGroup}
  426.    ::= {mADAlarmCompliances 2}
  427.  
  428. mADAlarmTrapGroup  OBJECT-GROUP
  429.    OBJECTS {mADAlarm, messageAlarm}
  430.    STATUS current
  431.    DESCRIPTION "Two Traps providing the basic level of support for alarms for
  432. MTAs."
  433.    ::= {mADAlarmGroup 1}
  434.  
  435. mADAlarmVariableGroup OBJECT-GROUP
  436.    OBJECTS {lastMessageIdFailure, numMessagesFailed,
  437.       lastFailureMtaGroupName, lastFailureMtaApplName}
  438.    STATUS current
  439.    DESCRIPTION "A collection of objects providing support for alarms for MTAs
  440. that includes some
  441.        other alarm-specific MIB variables"
  442.    ::= {mADAlarmGroup 2}
  443.  
  444.  
  445.  
  446.  
  447. Expires: January 31, 1997                                     [Page 8]
  448.  
  449. Internet Draft                                             August 1996
  450.  
  451.  
  452. END
  453.  
  454.  
  455.  
  456. 5. Scenarios
  457.  
  458. The following scenarios provide examples of how the mADAlarm and messageAlarm
  459. are used in various fault conditions.
  460.  
  461.  
  462. 5.1 Connectivity Failure
  463.  
  464. When an MTA or DSA detects that another MTA or DSA cannot be contacted, a
  465. mADAlarm is sent.  The mADAlarm contains the applName of the MTA reporting the
  466. problem, the mtaGroupName for the MTA that cannot be contacted, and the
  467. mtaGroupOutboundConnectFailureReason or mtaGroupInboundRejectionReason.  In 
  468. the case of a more general connectivity failure, such as the general 
  469. unavailability of the network element, the MTA-trap contains only the variable
  470. mtaGroupOutboundConnectFailureReason. Care should be taken to report these 
  471. conditions only in the case of permanent failure, since intermittent failures 
  472. are more frequent and might result in too many traps being generated.  For 
  473. example, when an MTA cannot connect to another MTA in order to deliver a 
  474. message, the MTA delivering the message usually retries the delivery attempt 
  475. for a specified duration or for a specified number of tries.  If the retry 
  476. limit is exceeded, a case that should not occur, the message is returned.  In 
  477. this case, a trap would be sent when the retry limit is exceeded, but would not
  478. be sent for each individual retry.
  479.  
  480.  
  481. 5.2 MTA or DSA Down
  482.  
  483. This condition signifies that the MTA or DSA is not operational (but should be)
  484. or has not recently registered with the management system.  This condition is
  485. reported with an mADAlarm containing the values of applOperStatus and applName
  486. from the MADMAN Application Monitoring MIB.  Support for this feature is
  487. optional, since an MTA or DSA that has crashed cannot report that fact to an
  488. agent, and since off-the-shelf agents cannot be expected to monitor the
  489. aliveness of applications by themselves.
  490.  
  491.  
  492. 5.3 Messaging Loop Detection
  493.  
  494. This condition may signify that a particular message has been detected,
  495. received, and sent multiple times, perhaps exceeding a locally established
  496. threshold value.  The condition is reported with a messageAlarm trap, where the
  497. trap contains the applName of the MTA reporting the problem, and optionally the
  498. values of lastMessageIdFailure, mtaLoopsDetected, mtaGroupLoopsDetected.
  499.  
  500.  
  501.  
  502.  
  503. Expires: January 31, 1997                                     [Page 9]
  504.  
  505. Internet Draft                                             August 1996
  506.  
  507.  
  508.  
  509. 5.4 Message Processing Failure
  510.  
  511. When an MTA encounters certain non-recoverable errors processing a message,
  512. (e.g., a "dead" message that cannot be delivered, nondelivered, or redirected),
  513. a messageAlarm is generated.  The messageAlarm contains the applName of the MTA
  514. reporting the failure, and optionally the lastMessageIdFailure, which
  515. identifies the most recent message that failed, and numMessagesFailed, which
  516. aids in detecting multiple message failures.  If other messages had failed
  517. processing prior to the immediate condition being reported and after the most
  518. recent polling cycle, the identities of these messages may be detected
  519. manually.
  520.  
  521.  
  522. 5.5 Queue Error
  523.  
  524. When an MTA or agent detects that a queue is full or is approaching saturation,
  525. a mADAlarm is sent.  The applName of the MTA reporting the problem is conveyed
  526. within the variable bindings list of the mADAlarm.  The mADAlarm also contains
  527. the values of the MIB variables mtaGroupName and mtaGroupStoredVolume (both
  528. from the mtaGroupTable).
  529.  
  530.  
  531. 5.6 Security Error
  532.  
  533. When an MTA or agent detects a security error such as an authentication failure
  534. (e.g. when an MTA or DSA fails to authenticate itself to another), a mADAlarm
  535. is sent.  The applName of the MTA reporting the problem is conveyed within the
  536. variable bindings list of the mADAlarm.  The mADAlarm also contains the values
  537. of the MIB variables mtaGroupInboundRejectionReason (stating an authentication
  538. failure) and the mtaGroupName.
  539.  
  540. When an MTA or agent detects a security error such as a data integrity
  541. violation (e.g. while processing a message), a messageAlarm is sent.
  542. The applName of the MTA reporting the problem is conveyed within the variable
  543. bindings list of the messageAlarm.  The messageAlarm also contains the values
  544. of the MIB variables mtaGroupInboundRejectionReason (stating an integrity
  545. violation) and the mtaGroupName.
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559. Expires: January 31, 1997                                    [Page 10]
  560.  
  561. Internet Draft                                             August 1996
  562.  
  563.  
  564. 6.  Acknowledgements
  565.  
  566. This draft is the product of discussions and deliberations carried out
  567. in the following groups:
  568.         ietf-madman-wg  ietf-madman@innosoft.com
  569.  
  570. This draft also incorporates the intellectual contributions of
  571.  
  572.             Bruce Greenblatt
  573.             Sue Lebeck
  574.             Roger Mizumori
  575.             Edward Owens
  576.  
  577.  
  578.  
  579. 7.  References
  580.  
  581.  
  582.    [1] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure
  583.        of Management Information for version 2 of the Simple Network
  584.        Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc.,
  585.        Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
  586.        University, February 1996.
  587.  
  588.    [2] McCloghrie, K., and M. Rose, Editors, "Management Information
  589.        Base for Network Management of TCP/IP-based internets: MIB-II",
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615. Expires: January 31, 1997                                    [Page 11]
  616.  
  617. Internet Draft                                             August 1996
  618.  
  619.  
  620.        STD 17, RFC 1213, Hughes LAN Systems, Performance Systems
  621.        International, March 1991.
  622.  
  623.    [3] Case, J., McCloghrie, K., Rose, M., and S, Waldbusser, "Protocol
  624.        Operations for version 2 of the Simple Network Management
  625.        Protocol (SNMPv2)", RFC 1905, SNMP Research,Inc., Hughes LAN
  626.        Systems, Dover Beach Consulting, Inc., Carnegie Mellon
  627.        University, February 1996.
  628.  
  629.    [4] Freed, N., Kille, S., "Network Services Monitoring MIB"
  630.        Monitoring MIB", RFC 1565, Innosoft, ISODE Consortium, January
  631.        1994.
  632.  
  633.    [5] Freed, N., Kille, S., "Mail Monitoring MIB", RFC 1566,
  634.        Innosoft, ISODE Consortium, January 1994.
  635.  
  636.    [6] Mansfield, G., Kille, S, "X.500 Directory Monitoring MIB",
  637.        Monitoring MIB", RFC 1567, AIC Systems Lab, ISODE Consortium,
  638.        November 1994
  639.  
  640.  
  641. Security Considerations
  642.  
  643.    Security issues are not discussed in this memo.
  644.  
  645.  
  646.  
  647. Authors' Addresses
  648.  
  649.    Glenn Mansfield
  650.    AIC Systems Laboratories
  651.    6-6-3 Minami Yoshinari
  652.    Aoba-ku, Sendai 989-32
  653.    Japan
  654.  
  655.    Phone: +81-22-279-3310
  656.    E-Mail: glenn@aic.co.jp
  657.  
  658.  
  659.   Gordon B. Jones
  660.   MITRE  Corporation
  661.   1820 Dolley Madison Blvd.
  662.   McLean, VA 22102-3481
  663.  
  664.   Phone: (703) 883-76701
  665.   E-Mail: gbjones@mitre.org
  666.  
  667.  
  668.  
  669.  
  670.  
  671. Expires: January 31, 1997                                    [Page 12]
  672.  
  673. Internet Draft                                             August 1996
  674.  
  675.  
  676.   Niraj Jain
  677.   Oracle Corporation
  678.   500 Oracle Parkway
  679.   Redwood Shores
  680.   California 940065
  681.  
  682.   Phone: (415) 506-2581
  683.   E-Mail: njain@us.oracle.com
  684.  
  685.  
  686.  
  687.  
  688.  
  689.  
  690.  
  691.  
  692.  
  693.  
  694.  
  695.  
  696.  
  697.  
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727. Expires: January 31, 1997                                    [Page 13]
  728.  
  729.