Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa23332; 3 Jul 93 1:57 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa23328; 3 Jul 93 1:57 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa05370; 3 Jul 93 1:57 EDT Return-path: glenn@aic.co.jp Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-13 #1336) id <01H0308YBZW08WW866@INNOSOFT.COM>; Fri, 2 Jul 1993 22:30:57 PDT Received: from CUNYVM.CUNY.EDU (MAILER@CUNYVMV2) by INNOSOFT.COM (PMDF V4.2-13 #1336) id <01H0308TXEZK8WWAIM@INNOSOFT.COM>; Fri, 2 Jul 1993 22:30:46 PDT Received: from CUNYVM (NJE origin SMTP@CUNYVM) by CUNYVM.CUNY.EDU (LMail V1.1d/1.7f) with BSMTP id 0636; Sat, 3 Jul 1993 01:30:19 -0400 Received: from aic-wide.aic.co.jp by CUNYVM.CUNY.EDU (IBM VM SMTP V2R2) with TCP; Sat, 03 Jul 93 01:30:07 EDT Received: by aic-wide.aic.co.jp (4.1/2.7W) id AA03243; Sat, 3 Jul 93 14:30:10 JST Date: Sat, 03 Jul 1993 14:30:10 +0900 (JST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Glenn Mansfield Subject: Revised DSA mib To: ietf-madman@innosoft.com, isode-wg@wide.ad.jp, netman@wide.ad.jp Errors-to: ned+madman-errors@INNOSOFT.COM Resent-message-id: <01H0308YEEPE8WW866@INNOSOFT.COM> Message-id: <9307030530.AA03243@aic-wide.aic.co.jp> X-VMS-To: IN%"ietf-madman@INNOSOFT.COM", IN%"isode-wg@wide.ad.jp", IN%"netman@wide.ad.jp" Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Folks, In response to the reactions to the DSAmib [complex, too many objects, ...], a revised version has been prepared, to address the comments and suggestions. The revision does, I believe, bring this MIB to the same level of complexity [Simplicity :-)] as the other two MIBs [ networkmib, mtamib]. In the following I have summarized the model on which the MIB is based followed by a list of changes that have been made. The Model. ========== The new MIB view is very simply explained in the diagram below. There are bind/unbind requests that arrive at and originate from a DSA.Then there are also requests for {Read, Compare, AddEntry, ModifyEntry, ModifyRDN, RemoveEntry, List, Search, Abandon} that arrive at the DSA. Some requests are chained to other DSAs. Others are performed locally and (partial)results and/or errors are returned. +--------------------+ (un)bind----------->| |-------> (un)bind request ----------->| |-------> chainings | Operations | results <-----------| |<------- results errors <-----------| |<------- errors +--------------------+ The MIB covers as objects of interest the binds, total incoming re- quests, total outgoing chainings, results and errors. For the locally performed operations I have choosen to provide counters for each request-type. For the errors, separate counters for referrals and secu- rity errors are provided. Other errors are consolidated into one counter. I have retained the DSAinfo Table. This provides information on the Directory [a part of it] as learnt through the operations of the DSA. I like it :-) OK. Now a list of the things that have gone.... *The major chunk of deleted objects never really belonged here - they should have gone into the generic-MIB.[I had made a note of that in the earlier MIB. I hope it will be included there.] MOs pertaining to {contactperson, [DSA]name, [DSA]type} are important for any applica- tion .... *Other objects pertaining to details of chaining operations and errors have gone. *Also, the Traps have gone. These are of generic nature, too. They are very important - many managers had indicated that traps are the most interesting objects in the MIB ;-) I suggest that these be included in the generic network-service-application MIB. *Other changes- precision in definitions, "dsa" prefix for object names, ... So, there is our lean and thin and SIMPLE DSAmib :-) Looking forward to your reactions. Cheers glenn DSA Monitoring MIB MADMAN Working Group July 1993 Abstract This document defines an MIB for monitoring Directory System Agents[DSA], a component of the OSI Directory. The DSAmib will be used in conjunction with the application-mib for monitoring DSAs. Contents ======== 1.The Network Management Framework. 2 2.Model of the management information base for a DSA Manager. 2 3.The DSA functions and operations. 3 4.MIB design. 4 5.The DSAmib 4 6.Acknowledgements 7.References 1.The Network Management Framework. ================================== The Internet Network Management framework is laid out in the three documents- STD 16/ RFC 1155 [1] defines the generic structure of network management information STD 15/ RFC 1157 [2] defines the protocol for accessing network management information STD 17/ RFC 1213 [3] defines the primary set of managed objects. The framework is adaptable/extensible by defining newer MIBs to suit the requirements of specific applications/protocols/situations. 2.Model of the management information base for a DSA Manager. ============================================================== A DSA-manager[application] may wish to monitor several as- pects of the the operational DSA. It may want to know the process related aspects- the CPU, memory, .. utilization of the operational DSA; the network service related aspects - inbound-associations, outbound-associations, operational status, ... and finally the information specific to the DSA application- its operations and performance. July 3, 1993 MADMAN-wg Draft - 2 - July 1993 The MIB proposed in this document covers only the portion which is specific to the DSA-application. The network ser- vice related part of the MIB, and the host-resources related part, of the MIB , as well other parts of interest to a Manager monitoring the DSA-application, are covered in separate documents [6][7]. The relationship of this MIB with the other MIBs (existing and potential) is shown in the following diagram. ------------------------------------------ | HOST RESOURCES mib | | | ------------------------------------------- | | | | O | | | | | | | | T | | |O| | DSA | MTA |FTAM | H | NFS | DNS |T| | mib | mib |mib | E | mib | mib |H| | | | | R | | |E| --------------------------| | |R| | NETWORK APPLN mib | | | | | for CO-AP | | | | ------------------------------------------- | | | Other mibs [MIB-II, ... ] | | | ------------------------------------------- Fig. 1 The manager (application) of a network service application will use the Host-resources-mib to obtain process related information [ resource usage,..] the network service appli- cation mib provides the information for the generic objects[peer associations]. The Application specific objects are defined in the corresponding MIB, e.g., the DSA- specific MIB is the one that is being proposed in this Pa- per. For management information pertaining to the lower layer TCP/UDP/IP/... the MIB-II offers the repertoire of MOs. 3.The DSA functions and operations. ================================== The Directory System Agent [DSA], a component of the OSI- Directory, is an application process. It provides access to the Directory Information Base [DIB] to Directory User Agents [DUA] and/or other DSAs. Functionally , a User [ DUA ] and the Directory are bound together for a period of time at an access point to the Directory [DSA]. A DSA may use in- formation stored in its local database or interact with (chain the request to) other DSAs to service requirements. Alternatively, a DSA may return a reference to another DSA. July 3, 1993 MADMAN-wg Draft - 3 - July 1993 The local database of a DSA consists of the part of the DIT that is masered by the DSA, the part of the DIT for which it keeps slave copies and cached information that is gathered during the operation of the DSA. The specific operations carried out by the DSA are : Read, Compare, AddEntry, ModifyEntry, ModifyRDN, RemoveEntry, List, Search. There is also the special operation Abandon. In response to request results and/or errors are returned by the DSA. 4. MIB design. ============= The basic principle has been to keep the MIB as simple as possible. The Managed objects included in the MIB are divid- ed into two tables- the dsaTable and dsaInfoTable. - The dsaTable provides summary data on the accesses, operations errors and cache performance - The dsaInfoTable provides some useful information on the performance of other DSAs with which the monitored DSA interacts. There are references to the Directory itself for static information pertaining to the DSA. These references are in the form of "Directory Distinguished Name" of the corresponding object. It is intended that DSA management applications will use these references to obtain further related information on the objects of interest. 5. The DSAmib ============= DSA-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE FROM RFC1212 Counter, TimeTicks, DisplayString FROM RFC1151-SMI; -- textual conventions -- Distinguished Name- is used to refer to objects in the directory. DistinguishedName::= DisplayString dsa OBJECT IDENTIFIER ::= { experimental XX} July 3, 1993 MADMAN-wg Draft - 4 - July 1993 dsaTable OBJECT-TYPE SYNTAX SEQUENCE OF DSAEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The table holding information specific to the DSA" ::= {dsa 1} dsaEntry OBJECT-TYPE SYNTAX DSAEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Entry associated with each DSA" INDEX { dsaApplIndex } ::= {dsaTable 1} DSAEntry ::= SEQUENCE { dsaApplIndex INTEGER, --bindings dsaAnonymousBinds Counter, dsaUnauthNameBinds Counter, dsaSimpleBinds Counter, dsaProtectedBinds Counter, dsaExternalBinds Counter, dsaBindSecurityErrors Counter, -- in-coming operations dsainOps Counter, -- locally executed dsaReadOps Counter, dsaCompareOps Counter, dsaAddEntryOps Counter, dsaRemoveEntryOps Counter, dsaModifyEntryOps Counter, dsaModifyRDNOps Counter, July 3, 1993 MADMAN-wg Draft - 5 - July 1993 dsaListOps Counter, dsaSearchOps Counter, dsaOneLevelSearchOps Counter, dsaWholeTreeSearchOps Counter, -- out going operations dsaReferrals Counter, dsaChainings Counter, dsaMulticastChainings Counter, -- errors dsaSecurityErrors Counter, dsaErrors Counter, -- Cache performance dsaMasterEntries INTEGER, dsaCopyEntries INTEGER, dsaCacheEntries INTEGER, dsaCacheHits Counter, dsaSlaveHits Counters } dsaApplIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Reference into application table to allow correlation with general application parameters" ::= {dsaEntry 1} July 3, 1993 MADMAN-wg Draft - 6 - July 1993 ---- for more information on the DSA ---- [Contact person , Directory Distinguished name ... ?] ---- the corresponding ApplEntry [ applicationIndex = dsaApplIndex] ---- in the applTable should be looked up ---- [ the dsa's appn entry-id = experimental.46.1.1.dsaApplIndex ] dsaAnonymousBinds OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " Number of anonymous (DAP) binds to this DSA since application start" ::= {dsaEntry 2} dsaUnauthNameBinds OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " Number of un-authenticated binds to this DSA , since application start" ::= {dsaEntry 3} dsaSimpleBinds OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " Number of binds to this DSA that passed simple authentication, since application start" ::= {dsaEntry 4} dsaProtectedBinds OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " Number of binds to this DSA that passed protected authentication, since application start" ::= {dsaEntry 5} dsaExternalBinds OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " Number of binds to this DSA that were authenticated using the external authentication procedures, since application start" ::= {dsaEntry 6} July 3, 1993 MADMAN-wg Draft - 7 - July 1993 dsaBindSecurityErrors OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of bind operations that have been rejected by this DSA due to inappropriateAuthentication or invalidCredentials." ::= {dsaEntry 7} dsaInOps OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " Number of operations forwarded to this DSA from DUAs or other DSAs , since application start" ::= {dsaEntry 8} dsaReadOps OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of read operations locally executed by this DSA since application startup." ::= {dsaEntry 9} dsaCompareOps OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of compare operations locally executed by this DSA since application startup." ::= {dsaEntry 10} dsaAddEntryOps OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of addEntry operations locally executed by this DSA since application startup." ::= {dsaEntry 11} dsaRemoveEntryOps OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of removeEntry operations locally executed by this DSA since application startup." July 3, 1993 MADMAN-wg Draft - 8 - July 1993 ::= {dsaEntry 12} dsaModifyEntryOps OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of modifyEntry operations locally executed by this DSA since application startup." ::= {dsaEntry 13} dsaModifyRDNOps OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of modifyRDN operations locally executed by this DSA since application startup." ::= {dsaEntry 14} dsaListOps OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of list operations locally executed by this DSA since application startup." ::= {dsaEntry 15} dsaSearchOps OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of search operations- baseObjectSearches, oneLevelSearches and subTreeSearches, locally executed by this DSA since application startup." ::= {dsaEntry 16} dsaOneLevelSearchOps OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of oneLevelSearch operations locally executed by this DSA since application startup." ::= {dsaEntry 17} July 3, 1993 MADMAN-wg Draft - 9 - July 1993 dsaWholeTreeSearchOps OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of wholeTreeSearch operations locally executed by this DSA since application startup." ::= {dsaEntry 18} dsaReferrals OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of referrals returned by this DSA in response to requests for operations since application startup." ::= {dsaEntry 19} dsaChainings OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of operations forwarded by this DSA to other DSAs since application startup." ::= {dsaEntry 20} dsaMulticastChainings OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of parallel multicast chainings that were originated from this DSA since application start up." ::= {dsaEntry 21} dsaSecurityErrors OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of operations forwarded to this DSA which did not meet the security requirements " ::= {dsaEntry 22} July 3, 1993 MADMAN-wg Draft - 10 - July 1993 dsaErrors OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of operations that could not be serviced due to errors other than security errors, and referrals. A partially serviced operation will not be counted as an error. The errors include NameErrors, UpdateErrors, Attribute errors and ServiceErrors." ::= {dsaEntry 23} dsaMasterEntries OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Number of Entries mastered in the DSA" ::= {dsaEntry 24} dsaCopyEntries OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Number of Entries with systematic (slave) copies maintained in the DSA" ::= {dsaEntry 25} dsaCacheEntries OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Number of Entries cached (non-systematic copies) in the DSA" ::= {dsaEntry 26} dsaCacheHits OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of operations that were serviced from the locally held cache, since application startup." ::= {dsaEntry 27} dsaSlaveHits OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory July 3, 1993 MADMAN-wg Draft - 11 - July 1993 DESCRIPTION " number of operations that were serviced from the locally held object replications [ shadow entries] since application startup." ::= {dsaEntry 28} -- The DSAInfo table contains statistical data on the DSAs -- with which it [attempts to] interact. This table will -- provide a useful insight into the effect of neighbours -- on the DSA performance. -- Due to resource constraints it may be necessary to -- delete entries. It is suggested that the least recently -- used entries be deleted first. The size of the table and -- procedures for its maintenance will be left to the -- implementation. dsaInfoTable OBJECT-TYPE SYNTAX SEQUENCE OF dsaInfoEntry ACCESS read-only STATUS mandatory ::= { dsa 2 } dsaInfoEntry OBJECT-TYPE SYNTAX DsaInfoEntry ACCESS read-only STATUS mandatory ::= { dsaInfoTable 1 } DsaInfoEntry ::= SEQUENCE { dsaName DistinguishedName, dsaTimeOfCreation TimeTicks, dsaTimeOfLastAttempt TimeTicks, dsaTimeOfLastSuccess TimeTicks, dsaFailuresSinceLastSuccess Counter, dsaFailures Counter, dsaSuccesses Counter } dsaName OBJECT-TYPE SYNTAX DistinguishedName ACCESS read-only STATUS mandatory DESCRIPTION " distinguished name of the DSA to which this entry pertains." ::= {dsaInfoEntry 1} July 3, 1993 MADMAN-wg Draft - 12 - July 1993 dsaTimeOfCreation OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION " The value of sysUpTime when this entry was created. If the entry was created before the network management subsystem was initialized, this object will contain a value of zero." ::= {dsaInfoEntry 2} dsaTimeOfLastAttempt OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION " The value of sysUpTime when the last attempt was made to contact this DSA. If the last attempt was made before the network management subsystem was initialized, this object will contain a value of zero." ::= {dsaInfoEntry 3} dsaTimeOfLastSuccess OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION " The value of sysUpTime when the last attempt made to contact this DSA was successful. If there have been no successful attempts this entry will be 0. If the last successful attempt was made before the network management subsystem was initialized, this object will contain a value of zero." ::= {dsaInfoEntry 4} dsaFailuresSinceLastSuccess OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION " The number of failures since the last time an attempt to contact this DSA was successful." ::= {dsaInfoEntry 5} dsaFailures OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION " cumulative failures since the creation of this entry." ::= {dsaInfoEntry 6} July 3, 1993 MADMAN-wg Draft - 13 - July 1993 dsaSuccesses OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION " cumulative successes since the creation of this entry." ::= {dsaInfoEntry 7} END   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10881; 7 Jul 93 15:07 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa10877; 7 Jul 93 15:07 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa22525; 7 Jul 93 15:07 EDT Return-path: ginsburg@paladin.mitre.org Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-13 #1336) id <01H09CQQ2NVK8WWAS8@INNOSOFT.COM>; Wed, 7 Jul 1993 11:33:45 PDT Received: from gateway.mitre.org by INNOSOFT.COM (PMDF V4.2-13 #1336) id <01H09CQFP8KW8WWAME@INNOSOFT.COM>; Wed, 7 Jul 1993 11:33:22 PDT Received: from paladin.mitre.org by gateway.mitre.org (5.61/SMI-2.2) id AA03512; Wed, 7 Jul 93 14:31:16 -0400 Received: by paladin.mitre.org (4.1/SMI-4.1) id AA00295; Wed, 7 Jul 93 14:31:12 EDT Date: Wed, 07 Jul 1993 14:31:10 -0400 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: ginsburg@paladin.mitre.org Subject: MITRE contribution to the MADMAN working group To: ietf-madman@innosoft.com Cc: cooney@wnyose.nctsw.navy.mil, rbennis@mitre.org, l_bettis%w035_nw@mwmgate1.mitre.org, gjones@gateway.mitre.org, epg@gateway.mitre.org Errors-to: ned+madman-errors@INNOSOFT.COM Resent-message-id: <01H09CQQBRSY8WWAS8@INNOSOFT.COM> Message-id: <9307071831.AA00295@paladin.mitre.org> X-VMS-To: IN%"ietf-madman@INNOSOFT.COM" X-VMS-Cc: IN%"cooney@wnyose.nctsw.navy.mil", IN%"rbennis@mitre.org", IN%"l_bettis%w035_nw@mwmgate1.mitre.org", IN%"gjones@gateway.mitre.org", IN%"epg@gateway.mitre.org" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Steve, MITRE is submitting this contribution to the MADMAN working group for consideration during development of the MADMAN MIBs. It represents some DoD requirements for Directory Service management and a proposal for inclusion of several attributes in the MIBs. We expect Bob Cooney, who is developing the DoD Directory Service, to present this to the working group. ----------------------------------------------------------------------------------- MIB for Monitoring DSAs 1.1 Purpose MITRE proposes the addition of attributes to the Network Services and DSA Monitoring MIBs for Directory Service management. We include a definiton and description of the proposed new attributes and a rationale for their use in system management. 1.2 Rationale The Defense Message System (DMS) X.500 directory will provide the Directory Service for a messaging system serving a mission-critical function. The Directory is responsible for dissemination of both address and cryptographic information and is essential for the functioning of the messaging service. The management function must provide for: o availability o reliability o speed of service Our management philosophy and approach are summarized below. o There is a central management station for the entire Directory Service -- our service will initially be provided by nine DSAs, but this number is expected to grow. We do not plan at this time to provide management stations at each DSA platform. o The primary real-time function of this manager is to keep the service running to provide the required quality of service. Longer term performance and planning functions need not, at least initially, be embedded in the real-time remote system management function. Logs at the platform will contain the raw data necessary to perform these functions. Note that short-term performance problems do need to be detected and reported real-time, although we have not yet developed adequate attributes for this. o A central network manager can digest only so much information; therefore, minimal but sufficient information should be transferred to the management station as part of the monitoring function; the bulk of the data remains at the platform, to be accessed and used as needed, including problem diagnosis. Whether this access is via the management station or via other means (file transfer, remote access, etc.) is to be determined. o An operator cannot be expected to try to monitor the state of multiple DSAs 24 hours a day using monitor windows. The system must alert the operator to fault or failure conditions which require immediate attention. 1.3 Attribute Descriptions We have defined a DSA monitoring MIB and built a CMIP-based prototype which monitors QUIPU DSAs. The key features of this MIB are the alarms for fault and error conditions. We attempted to identify all faults, most of which are connection problems. We also had the requirement to report security (authentication) errors in order to expedite the recognition of potential security breaches. Threshhold attributes are defined which can trigger the following alarms: o failed bound session alarm -- if a successfully bound session fails o failed inbound attempt alarm -- if a DSA rejects an association or a bind o failed outbound attempt alarm -- for any outbound connection failure o bind authentication error alarm -- if a bind fails to authenticate successfully o operational state alarm - for a DSA failure Note that there are a number of ways to define a DSA operational failure. We defined it as a failure of a DSA entity to send n consecutive "I'm alive" messages; this catches the case of a hung application as well as a failed one. We also included cumulative totals for both successful and unsuccessful connections and for authentication faults. We recognize the need to detect such other problems as: o excessive chaining o excessive read failures (name resolution errors) o excessive response time for different operations o attempted access control violations Many of above, and a number of other similar, attributes are included in the latest draft MADMAN DSA Monitoring MIB. We are currently analyzing this latest draft. We also have an object and attributes for each association, which parallels the assocTable in the Network Services Monitoring MIB. We are not sure at this time how we will use this object. 1.4 Relationship to the Latest MADMAN MIBs The MADMAN MIBs lack our alarms. Since we believe that the alarms (traps) we have proposed are essential for a central Directory Service manager, we propose their inclusion, in some form, in the MADMAN MIB. We also propose that the cumulative total attributes for the inbound connection, failed bound, and authentication failures be added. In addition, we propose that in the future any error/fault conditions which are identified as requiring immeditate attention have associated alarms (traps) defined for them as well as cumulative totals.   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01557; 8 Jul 93 7:22 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa01553; 8 Jul 93 7:22 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa04727; 8 Jul 93 7:22 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-13 #1336) id <01H0AAO9834G8WWBKS@INNOSOFT.COM>; Thu, 8 Jul 1993 03:45:11 PDT Received: from haig.cs.ucl.ac.uk by INNOSOFT.COM (PMDF V4.2-13 #1336) id <01H0AAO0YFGG8WW8W4@INNOSOFT.COM>; Thu, 8 Jul 1993 03:44:57 PDT Received: from glengoyne.isode.com by haig.cs.ucl.ac.uk with Internet SMTP id ; Thu, 8 Jul 1993 11:44:40 +0100 Received: from glengoyne.isode.com by glengoyne.isode.com with SMTP (PP); Thu, 8 Jul 1993 11:44:44 +0100 Date: Thu, 08 Jul 1993 11:44:36 +0100 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Steve Kille Subject: MADMAN (Mail and Directory Management) WG Agenda To: ietf-madman@innosoft.com Cc: ietf@nic.ddn.mil Errors-to: ned+madman-errors@INNOSOFT.COM Resent-message-id: <01H0AAO9ARKI8WWBKS@INNOSOFT.COM> Message-id: <6544.742128276@isode.com> X-VMS-To: IN%"ietf-madman@INNOSOFT.COM" X-VMS-Cc: IN%"ietf@nic.ddn.mil" MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Phone: +44-71-721-7582 Agenda for the MADMAN WG Meeting Amsterdam IETF Tuesday 13th July 1993 19:30-22:00 19:30 Introduction 19:35 Minutes of Previous Meeting 19:40 Review "Network Services Monitoring MIB" 20:00 Review "Directory Monitoring MIB" 20:40 Review "Mail Monitoring MIB" 21:45 Review (lack of) progress on Message Store MIB 22:00 Adjourn to Bar   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa21613; 19 Jul 93 8:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa21609; 19 Jul 93 8:53 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa28211; 19 Jul 93 8:52 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-13 #1336) id <01H0PRYRIU7490MYZA@INNOSOFT.COM>; Mon, 19 Jul 1993 05:42:38 PST Received: from kiyoko (kiyoko.fp.trw.com) by INNOSOFT.COM (PMDF V4.2-13 #1336) id <01H0PRYO9RB490MY2W@INNOSOFT.COM>; Mon, 19 Jul 1993 05:42:32 PST Received: by kiyoko (4.1/SMI-4.1) id AA01930; Mon, 19 Jul 93 08:40:57 EDT Date: Mon, 19 Jul 1993 08:40:57 -0400 (EDT) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Al Marfurt Subject: Where can I find the draft ? To: madman@innosoft.com Errors-to: ned+madman-errors@INNOSOFT.COM Resent-message-id: <01H0PRYRKZCY90MYZA@INNOSOFT.COM> Message-id: <9307191240.AA01930@kiyoko> X-VMS-To: IN%"madman@INNOSOFT.COM" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT I got a mail message that wetted my appetite, but I wasn't able to dig up the draft in all the usual spots I hunt for such things. Would some kind soul point me in the direction of a copy of: draft-ietf-madman-mtamib-01.txt Thanks. amarfurt@kiyoko.fp.trw.com   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06667; 21 Jul 93 13:58 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa06662; 21 Jul 93 13:58 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa18505; 21 Jul 93 13:58 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-13 #1336) id <01H0SV0PAR4W984JMV@INNOSOFT.COM>; Wed, 21 Jul 1993 10:42:08 PST Received: from comm.Tandem.COM by INNOSOFT.COM (PMDF V4.2-13 #1336) id <01H0SV0GJVA8984JYZ@INNOSOFT.COM>; Wed, 21 Jul 1993 10:41:55 PST Received: by comm.Tandem.COM (4.1/4.3) id AA5433; 21 Jul 93 10:43:41 -0700 Date: Wed, 21 Jul 1993 09:08:00 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: LEBECK_SUE@innosoft.com Subject: Email-Mgmt MIB: Progress Report and Meeting Agenda To: emib@stubby.dacnet.com, ifip-emailmgmt@ics.uci.edu Cc: ietf-madman@innosoft.com Errors-to: ned+madman-errors@INNOSOFT.COM Resent-message-id: <01H0SV0PAR4Y984JMV@INNOSOFT.COM> Message-id: <199307211043.AA5433@comm.Tandem.COM> X-VMS-To: IN%"emib@stubby.dacnet.com", IN%"ifip-emailmgmt@ics.uci.edu" X-VMS-Cc: IN%"ietf-madman@INNOSOFT.COM" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT ------------ REPLY ATTACHMENT -------- SENT 07-21-93 FROM LEBECK_SUE ----------------------------- EMAIL-MGMT MIB Working Group: ----------------------------- Progress Report and Interim Meeting Schedules and Agendas. (written by Sue Lebeck, Tandem Computers) PROGRESS REPORT --------------- The EMAIL-MGMT sub- working group on MIB definition last met at the June meeting of the OSE Implementors Workshop (OIW), in Gaithersburg, MD. At that meeting, we made significant progress on our work. Participants put a good deal of energy into this effort, both during the meeting, and in accepting off-line assignments to progress the work between meetings. This energy reflects a great deal of interest, as well as helpful attitudes on the part of the contributing individuals. Among our accomplishments and agreements: - We established a set of "Definition Guidelines" for use in our work. (These have been sent to "Emib@dacnet.com" list. Let me know if you are interested in seeing these now. They will also be included in a "strawman" document we are creating... read on. -- Sue) - We decided on a set of Object Classes to FOCUS ON FIRST. The Object Classes are related to the MTA, and include: MTA Adjacent MTA Route Message Queue Access Point Association Message Translator/Gateway object(s) Distribution List Electronic Mail System (EMS) object We will bring these objects to a a complete enough status to be understandable, before beginning work on other objects (eg. Message Stores, Users of various types). "Understandable" status means: - include: full text descriptions of Attributes, Notifications,Actions - include: data-typing considerations - include: Containment Heirarchy - Label as preliminary, and subject to change. In particular, subsequent work on other objects (Message Stores, Users), could lead to significant changes to this intial set of objects. Acknowledge that it still needs: Name bindings, data-typing. State which items in our "Definition Guidelines" have been considered, and which have not. - May or may not be in GDMO form yet. - We discussed the definitions of most of the Object Classes within our initial focus set. - We established a tentative Containment Heirarchy for the set of Object Classes within our initial focus set. - We established a plan to create a Strawman document on EMAIL-MGMT Managed Object defintions, which would then be posted to the "Email-Mgmt" main list for feedback. The goal is to create this Strawman document by the time of the next meeting of the OIW, in September. The Strawman will be created as follows: - work assignments will be executed offline; these assignments have as their goal to compile the outputs of the June OIW meeting into a preliminary strawman document. (These assignments were posted to the "emib@dacnet.com" about a month ago.) - The preliminary strawman document will be progressed into a somewhat more mature strawman document during INTERIM MEETINGS. To minimize travel obligations as much as possible, it was decided to have TWO interim meetings, one on the EAST COAST, and one on the WEST COAST. The EAST and WEST coast meeting schedules and agendas are coordinated to maximize progress. They are described below. YOU ARE ENCOURAGED TO PARTICIPATE IN ONE (or more) OF THESE MEETINGS, EVEN IF YOU WERE NOT OR WILL NOT ATTEND THE MEETINGS HELD IN THE OIW VENUE. - Bernard Ferret (bernard@dacnet.com) led the technical discussions. Bernard is also collating the Strawman document. Sue Lebeck (lebeck_sue@tandem.com) led the organizational/work-plan discussions. Sue is continuing to lead the organizational aspects of the work. INTERIM MEETING SCHEDULE ------------------------ EAST COAST "Interim" Meeting: June 21-23, 1993 in Gaithersburg, MD, hosted by NIST contact: Bernard Ferret WEST COAST "Interim" Meeting: June 28-30, 1993 in Cupertino, CA, hosted by Tandem Computers contact: Sue Lebeck The details of both meetings have been sent to "Emib@dacnet.com". Contact Bernard or Sue directly if you wish to attend, but did not see those notices. INTERIM MEETING AGENDAS ----------------------- These agendas are as agreed on the final day (Thursday) of the June OIW meeting. EAST COAST "Interim" Meeting: June 21-23, 1993 ----------------------------------------------- contact: Bernard Ferret - review Preliminary Strawman: - put each Object Class thru usage scenarios (informal) - put Containment Heirarchy thru usage scenarios (informal) - review text descriptions for clarity - begin work on NOTIFICATIONS and ACTIONS - Look at pre-existing Object Class and Attribute definitions (located in advanced by Bob Aronoff) and see how they can be applied to our Object Class definitions. - Discuss consideration for use in Mandatory/Optional/Conditional packaging decisions. - establish off-line work-plan to fold into Strawman or otherwise represent EAST COAST work for use in WEST COAST work the following week. - solicit volunteers to go thru the "Requirements" document off-line, and identify requirements relevant to the objects we've defined. The volunteers should write up their findings, for discussion at the September OIW meeting, to see where requirements are met, and where gaps exist. WEST COAST "Interim" Meeting: June 28-30, 1993 ----------------------------------------------- contact: Sue Lebeck - Use output of EAST COAST meeting as input. Bernard Ferret will be available by telephone to discuss any questions on EAST COAST output. Record any decision reversals or disagreements with EAST COAST output; record any questions/issues, and bring to Septemeber OIW. - review Preliminary Strawman: - put each Object Class thru usage scenarios (informal) - put Containment Heirarchy thru usage scenarios (informal) - review text descriptions for clarity - continue work on NOTIFICATIONS and ACTIONS - Look at proposed types in light of: Messaging/protocol independence. Look especially at types of attributes which are common to all or to multiple protocols. - revisit original MIB contributions, checking to ensure that all contributions have been adequately represented. - Discuss consideration for use in Mandatory/Optional/Conditional packaging decisions. - establish off-line work-plan to fold into Strawman or otherwise represent WEST COAST work for use in Sept. OIW meeting. - solicit volunteers to go thru the "Requirements" document off-line, and identify requirements relevant to the objects we've defined. The volunteers should write up their findings, for discussion at the September OIW meeting, to see where requirements are met, and where gaps exist. CONTACTS -------- Email-Mgmt MIB list: emib@dacnet.com Bernard Ferret: bernard@dacnet.com (703-476-5900) Sue Lebeck: lebeck_sue@tandem.com (408-285-4336)   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17747; 21 Jul 93 22:54 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17729; 21 Jul 93 22:53 EDT Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa05625; 21 Jul 93 22:53 EDT Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17497; 21 Jul 93 22:53 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa16375; 21 Jul 93 22:52 EDT Received: from aerospace.aero.org by CNRI.Reston.VA.US id aa05610; 21 Jul 93 22:51 EDT Received: from antares.aero.org by aerospace.aero.org with SMTP (5.65c/6.0.GT) id AA00626 for ietf@cnri.reston.va.us; Wed, 21 Jul 1993 19:50:28 -0700 Posted-Date: Wed, 21 Jul 1993 18:22:21 -0700 Message-Id: <199307220250.AA00626@aerospace.aero.org> Received: from merlin.aero.org by antares.aero.org (4.1/AMS-1.0) id AA22262 for cnom@maestro.bellcore.com; Wed, 21 Jul 93 18:22:41 PDT To: cnom@maestro.bellcore.com, ietf@CNRI.Reston.VA.US, snmp@uu.psi.com, rmonmib@jarthur.claremont.edu To: Joe Betser , Mike Erlinger , Keith McCloghrie , Steve Waldbusser , Stuart Noyce , "Steven M. Dauber" , Garry Baer , Rich Waterman , Kirk Hsin , Jim Warner , Paul Brusil , Branislav Meandzija , Michele Nessier <4367585@mcimail.com>, Frank Kaplan , joseph Ghetie , Shri Goyal , Jim Fox , Gary Haney , Thomas Cikoski , Bob Donnelly , Wallace Matthews , ositc@aero.org, NOMS , OIW Security SIG To: Electronic Mail Management Group To: OIW NMSIG To: Mike Erlinger , mike@jarthur.claremont.edu, Joe Betser , Kraig Meyer , Peter DeVries , Dave Mahler , Philip Almquist , Nan Dorio , Suzanne Carey , Branislav Meandzija To: Regional Workshop To: ANSI To: MITRE-NADIS To: MITRE-OSI To: MITRE To: OSI Mgt Implementation , OSI API , IETF MADMAN MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US To: "Dr. Melvyn P. Galin" , Kim Kappel , Donna Cowan , Douglas N Zuckerman +1 908 957 7874 Subject: NOMS 94 - Invitation to Submit Date: Wed, 21 Jul 1993 18:22:21 -0700 X-Orig-Sender:ietf-request@IETF.CNRI.Reston.VA.US Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Joe Betser Dear Colleague, We would like to invite you to submit a contributiontion for NOMS'94, the IEEE/IFIP 1994 Network Operations and Management Symposium "It's a Small World - Networking in the 90's" NOMS'94 will be held in Orlando, Florida, February 14-17, 1994. NOMS 94 will address the operations and management of public and private telecommunication and data networks, and of distributed systems. We (Joe and Mac) are organizing a NOMS'94 session entitled : "Management Platforms - Integration Issues" The management of increasingly complex data communications networks is becoming a challenge which is addressed by several commercial products, which have been introduced to the marketplace over the past several years. There is a strong movement in the direction of standards conformance, and commercial-off-the-shelf (COTS) technology availability. The integration of such technologies among themselves and into experimental and production networks provides a myriad of exciting technical issues that merit presentation to our growing community. You are encouraged to submit your experience, present and future challenges, as well as open issues you might have as an end-user, developer, researcher, standards contributor, product manager, or technology vendor. TOPICS OF INTEREST: - Integration of Network Management Stations (NMS) and Passive Network Monitors (PNM) - Scalability issues - Interoperability and standards - OSI - SNMP - RMON (Remote Monitoring MIB) - Applications - OMNIPoint - Performance issues - Heterogeneous systems - Multi-vendor support - Technologies and specifications for design, development, and construction Please inform us as soon as possible of your plans (See attached information). We look forward to receiving your contribution. Feel free to communicate with us with any issues. Sincerely, Dr. Makoto Yoshida NTT Network Information Laboratories myoshida@attmail.com (MYOSHIDA ) Phone: +81422593030 Fax-Phone: +81422592460 Dr. Joe Betser The Aerospace Corporation +:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+ | Joseph BETSER | | Computer Science and Technology tel: +1 310 336-0577 | | The Aerospace Corporation fax: +1 310 336-4402 | | Mail Station: M1-102 beep: +1 310 576-8575 | | 2350 East El Segundo Boulevard | | El Segundo, CA 90245-4691 e-mail: betser@aero.org | ==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:== INSTRUCTIONS AND SCHEDULE Submissions should consist of about ten visuals with explanatory text accompanying each one. The format should have a visual in the upper half of a page and the explanatory text in the lower half. A formal paper for publication is not required. For detailed instructions and a schedule, please contact the NMOS '94 Technical Program Chair (or Joe Betser / Makoto Yoshida regarding this session.) Shri K. Goyal GTE Laboratories, MS 45 Email: goyal@gte.com 40 Sylvan Road Phone: +1 617 466 2940 Waltham, MA 02254 USA Fax: +1 617 466 2960 All submissions will be refereed. Preliminary Schedule: DRAFT VISUAL AND TEXT DUE AUGUST 10, 1993 - SOON ! Notification of Acceptance mailed October 29, 1993 Camera-ready visuals and text due December 15, 1993   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18370; 21 Jul 93 23:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa18366; 21 Jul 93 23:38 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa06759; 21 Jul 93 23:38 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-13 #1336) id <01H0TFC1TI9C984K5Z@INNOSOFT.COM>; Wed, 21 Jul 1993 20:23:54 PST Received: from aerospace.aero.org by INNOSOFT.COM (PMDF V4.2-13 #1336) id <01H0TFBQNDZK984IJI@INNOSOFT.COM>; Wed, 21 Jul 1993 20:23:46 PST Received: from antares.aero.org by aerospace.aero.org with SMTP (5.65c/6.0.GT) id AA00578 for ietf-madman@innosoft.com; Wed, 21 Jul 1993 19:48:25 -0700 Received: from merlin.aero.org by antares.aero.org (4.1/AMS-1.0) id AA22262 for cnom@maestro.bellcore.com; Wed, 21 Jul 93 18:22:41 PDT Date: Wed, 21 Jul 1993 18:22:21 -0700 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Joe Betser Subject: NOMS 94 - Invitation to Submit To: cnom@maestro.bellcore.com, ietf@CNRI.Reston.VA.US, snmp@uu.psi.com, rmonmib@jarthur.claremont.edu To: Joe Betser , Mike Erlinger , Keith McCloghrie , Steve Waldbusser , Stuart Noyce , "Steven M. Dauber" , Garry Baer , Rich Waterman , Kirk Hsin , Jim Warner , Paul Brusil , Branislav Meandzija , Michele Nessier <4367585@mcimail.com>, Frank Kaplan , joseph Ghetie , Shri Goyal , Jim Fox , Gary Haney , Thomas Cikoski , Bob Donnelly , Wallace Matthews , ositc@aero.org, NOMS , OIW Security SIG To: Electronic Mail Management Group To: OIW NMSIG To: Mike Erlinger , mike@jarthur.claremont.edu, Joe Betser , Kraig Meyer , Peter DeVries , Dave Mahler , Philip Almquist , Nan Dorio , Suzanne Carey , Branislav Meandzija To: Regional Workshop To: ANSI To: MITRE-NADIS To: MITRE-OSI To: MITRE To: OSI Mgt Implementation , "To:OSI API" , "To:IETF MADMAN" To: "Dr. Melvyn P. Galin" , Kim Kappel , Donna Cowan , Douglas N Zuckerman +1 908 957 7874 Errors-to: ned+madman-errors@INNOSOFT.COM Resent-message-id: <01H0TFC1WGCI984K5Z@INNOSOFT.COM> Message-id: <199307220248.AA00578@aerospace.aero.org> X-VMS-To: IN%"cnom@maestro.bellcore.com", IN%"ietf@cnri.reston.va.us", IN%"snmp@uu.psi.com", IN%"rmonmib@jarthur.claremont.edu" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Posted-Date: Wed, 21 Jul 1993 18:22:21 -0700 Dear Colleague, We would like to invite you to submit a contributiontion for NOMS'94, the IEEE/IFIP 1994 Network Operations and Management Symposium "It's a Small World - Networking in the 90's" NOMS'94 will be held in Orlando, Florida, February 14-17, 1994. NOMS 94 will address the operations and management of public and private telecommunication and data networks, and of distributed systems. We (Joe and Mac) are organizing a NOMS'94 session entitled : "Management Platforms - Integration Issues" The management of increasingly complex data communications networks is becoming a challenge which is addressed by several commercial products, which have been introduced to the marketplace over the past several years. There is a strong movement in the direction of standards conformance, and commercial-off-the-shelf (COTS) technology availability. The integration of such technologies among themselves and into experimental and production networks provides a myriad of exciting technical issues that merit presentation to our growing community. You are encouraged to submit your experience, present and future challenges, as well as open issues you might have as an end-user, developer, researcher, standards contributor, product manager, or technology vendor. TOPICS OF INTEREST: - Integration of Network Management Stations (NMS) and Passive Network Monitors (PNM) - Scalability issues - Interoperability and standards - OSI - SNMP - RMON (Remote Monitoring MIB) - Applications - OMNIPoint - Performance issues - Heterogeneous systems - Multi-vendor support - Technologies and specifications for design, development, and construction Please inform us as soon as possible of your plans (See attached information). We look forward to receiving your contribution. Feel free to communicate with us with any issues. Sincerely, Dr. Makoto Yoshida NTT Network Information Laboratories myoshida@attmail.com (MYOSHIDA ) Phone: +81422593030 Fax-Phone: +81422592460 Dr. Joe Betser The Aerospace Corporation +:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+:+ | Joseph BETSER | | Computer Science and Technology tel: +1 310 336-0577 | | The Aerospace Corporation fax: +1 310 336-4402 | | Mail Station: M1-102 beep: +1 310 576-8575 | | 2350 East El Segundo Boulevard | | El Segundo, CA 90245-4691 e-mail: betser@aero.org | ==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:==:== INSTRUCTIONS AND SCHEDULE Submissions should consist of about ten visuals with explanatory text accompanying each one. The format should have a visual in the upper half of a page and the explanatory text in the lower half. A formal paper for publication is not required. For detailed instructions and a schedule, please contact the NMOS '94 Technical Program Chair (or Joe Betser / Makoto Yoshida regarding this session.) Shri K. Goyal GTE Laboratories, MS 45 Email: goyal@gte.com 40 Sylvan Road Phone: +1 617 466 2940 Waltham, MA 02254 USA Fax: +1 617 466 2960 All submissions will be refereed. Preliminary Schedule: DRAFT VISUAL AND TEXT DUE AUGUST 10, 1993 - SOON ! Notification of Acceptance mailed October 29, 1993 Camera-ready visuals and text due December 15, 1993   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa17325; 23 Jul 93 21:23 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa17321; 23 Jul 93 21:23 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa19006; 23 Jul 93 21:23 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1336) id <01H0W3AKHZE8984KRI@INNOSOFT.COM>; Fri, 23 Jul 1993 18:11:29 PST Received: from comm.Tandem.COM by INNOSOFT.COM (PMDF V4.2-14 #1336) id <01H0W3AGJYK0984LNT@INNOSOFT.COM>; Fri, 23 Jul 1993 18:11:22 PST Received: by comm.Tandem.COM (3.6/2.D) id AA1337; 23 Jul 93 18:13:46 +1800 Date: 23 Jul 93 13:08:00 +1800 Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: LEBECK_SUE@tandem.com Subject: Email Mgmt meetings: DATE ERROR To: emib@stubby.dacnet.com, ifip-emailmgt@ics.uci.edu Cc: ietf-madman@innosoft.com Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Resent-message-id: <01H0W3AKLQFM984KRI@INNOSOFT.COM> Message-id: <199307231813.AA1337@comm.Tandem.COM> X-VMS-To: IN%"emib@stubby.dacnet.com", IN%"ifip-emailmgt@ics.uci.edu" X-VMS-Cc: IN%"ietf-madman@INNOSOFT.COM" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Folks -- Someone just pointed out to me a very significant "off-by-one" error in the meeting report/announcement I sent a few days ago. Only this time the "off-by-one" unit is one MONTH. The EAST COAST and WEST COAST interim meetings are JULY 21-23 and JULY 28-30 respectively. The EAST COAST meeting has completed and the WEST COAST meeting will be held startomg next Wednesday, hosted by Tandem Computers in CUpertino, CA. Contact me for details. Hope the date error didn't confuse anyone, or lead them to decide not to attend. There's still time to sign up for the WEST COAST meeting. Contact me by Monday. THANKS, Cheers, Sue   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa14686; 25 Jul 93 11:23 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa14682; 25 Jul 93 11:23 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa16482; 25 Jul 93 11:23 EDT Return-path: glenn@aic.co.jp Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1336) id <01H0YAHOT2QO984MGU@INNOSOFT.COM>; Sun, 25 Jul 1993 07:58:51 PST Received: from CUNYVM.CUNY.EDU (MAILER@CUNYVMV2) by INNOSOFT.COM (PMDF V4.2-14 #1336) id <01H0YAHKYTW0984LJ9@INNOSOFT.COM>; Sun, 25 Jul 1993 07:58:43 PST Received: from CUNYVM (NJE origin SMTP@CUNYVM) by CUNYVM.CUNY.EDU (LMail V1.1d/1.7f) with BSMTP id 1042; Sun, 25 Jul 1993 10:58:04 -0400 Received: from aic-wide.aic.co.jp by CUNYVM.CUNY.EDU (IBM VM SMTP V2R2) with TCP; Sun, 25 Jul 93 10:57:53 EDT Received: by aic-wide.aic.co.jp (4.1/2.7W) id AA11456; Sun, 25 Jul 93 23:58:08 JST Date: Sun, 25 Jul 1993 23:58:08 +0900 (JST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Glenn Mansfield Subject: Revised Directory Monitoring MIB To: ietf-madman@innosoft.com Cc: glenn@aic-wide.aic.co.jp Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Resent-message-id: <01H0YAHOV7WI984MGU@INNOSOFT.COM> Message-id: <9307251458.AA11456@aic-wide.aic.co.jp> X-VMS-To: IN%"ietf-madman@INNOSOFT.COM" X-VMS-Cc: IN%"glenn@aic-wide.aic.co.jp" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Folks, The feedback from Amsterdam has been incorporated into the latest version of the DSA-MIB draft appended below. Looking forward to your comments. Cheers glenn ++++++++++++++++++++ Feed back from Amsterdam ++++++++++++++++++++++++++ Title changed to "Directory Monitoring MIB" Reference for DN format to be added. Page 3, Figure 1, FTAM MIB removed from diagram. Page 7, dsaSimpleBinds and dsaProtectedBinds to be merged. Page 8, dsaExternalBinds to include strong authentication. Page 11, dsaMulticastChainings to be removed. ----- +++++++++++++++++++++++++++ Changes ++++++++++++++++++++++++++++++++++ - As above. [ dsaSimpleBinds + dsaProtectedBinds => dsaSimpleAuthBinds dsaExternalBinds + => dsaStrongAuthBinds ] - Some explanations have been moved to the Network Services Monitoring MIB. - OID assigned to dsa dsa OBJECT IDENTIFIER ::= { experimental 48} - latest reference to DNS-MIB added ++++++++++++++++++++++++ Modified Draft ++++++++++++++++++++++++++++++++ MADMAN Working Group Glenn Mansfield [glenn@aic.co.jp] INTERNET-DRAFT AIC Systems Laboratory S.E.Hardcastle-Kille [steve@isode.com] ISODE Consortium July 1993 Directory Monitoring MIB Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. Abstract This document defines an MIB for monitoring Directory System Agents[DSA], a component of the OSI Directory. The DSA-MIB will be used in conjunction with the APPLICATION-MIB for monitoring DSAs. Contents ======== 1.The Network Management Framework. 2 2.MIB Model for DSA Management 2 3.The DSA functions and operations. 3 4.MIB design. 4 5.The Directory Monitoring MIB 4 6.Acknowledgements 14 7.References 15 Expires: January 25, 1994 [Page 1] Internet Draft July 1993 1.The Network Management Framework. ================================== The Internet Network Management framework is laid out in the three documents- STD 16/ RFC 1155 [1] defines the generic structure of network management information STD 15/ RFC 1157 [2] defines the protocol for accessing network management information STD 17/ RFC 1213 [3] defines the primary set of managed objects. The framework is adaptable/extensible by defining newer MIBs to suit the requirements of specific applications/protocols/situations. 2.MIB Model for DSA Management. ================================ A DSA-manager[application] may wish to monitor several aspects of the the operational DSA. He/she may want to know the process related aspects- the CPU, memory, .. utilization of the operational DSA; the network service related aspects - inbound-associations, outbound- associations, operational status, ... and finally the information specific to the DSA application- its operations and performance. The MIB proposed in this document covers only the portion which is specific to the DSA-application. The network service related part of the MIB, and the host-resources related part, of the MIB , as well other parts of interest to a Manager monitoring the DSA-application, are covered in separate documents [6][7]. The relationship of this MIB with the other MIBs is shown in fig.1. Expires: January 25, 1994 [Page 2] Internet Draft July 1993 +----------------------+ | Host Resources MIB | +----------------------+ | | | DSA-specific MIB | | | +----------------------| | generic NSA MIB | +----------------------+ | Other MIBs | | [MIB-II, ... ] | +----------------------+ Fig. 1 The manager (application) of a network service application will use the Host Resources MIB to obtain process related information [ resource usage,..] the generic NSA MIB provides the information for the generic objects[peer associations]. The DSA-specific MIB is the one that is being proposed in this paper. For management information pertaining to the lower layer TCP/UDP/IP/... the MIB-II offers the repertoire of MOs. 3.The DSA functions and operations. ================================== The Directory System Agent [DSA], a component of the OSI-Directory, is an application process. It provides access to the Directory Information Base [DIB] to Directory User Agents [DUA] and/or other DSAs. Functionally , a User [ DUA ] and the Directory are bound together for a period of time at an access point to the Directory [DSA]. A DSA may use information stored in its local database or interact with (chain the request to) other DSAs to service requirements. Alternatively, a DSA may return a reference to another DSA. The local database of a DSA consists of the part of the DIT that is masered by the DSA, the part of the DIT for which it keeps slave copies and cached information that is gathered during the operation of the DSA. The specific operations carried out by the DSA are : Read, Compare, AddEntry, ModifyEntry, ModifyRDN, RemoveEntry, List, Search. There is also the special operation Abandon. In response to request results and/or errors are returned by the DSA. Expires: January 25, 1994 [Page 3] Internet Draft July 1993 4. MIB design. ============= The basic principle has been to keep the MIB as simple as possible. The Managed objects included in the MIB are divided into two tables- the dsaTable and dsaInfoTable. - The dsaTable provides summary data on the accesses, operations errors and cache performance - The dsaInfoTable provides some useful information on the performance of other DSAs with which the monitored DSA interacts. There are references to the Directory itself for static information pertaining to the DSA. These references are in the form of "Directory Distinguished Name" [5] of the corresponding object. It is intended that DSA management applications will use these references to obtain further related information on the objects of interest. 5. The Directory Monitoring MIB. =============================== DSA-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE FROM RFC1212 Counter, TimeTicks, DisplayString FROM RFC1151-SMI; -- textual conventions -- Distinguished Name [5]- is used to refer to objects in the directory. DistinguishedName::= DisplayString dsa OBJECT IDENTIFIER ::= { experimental 48} dsaTable OBJECT-TYPE SYNTAX SEQUENCE OF DSAEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The table holding information specific to the DSA" ::= {dsa 1} dsaEntry OBJECT-TYPE SYNTAX DSAEntry ACCESS not-accessible STATUS mandatory Expires: January 25, 1994 [Page 4] Internet Draft July 1993 DESCRIPTION "Entry associated with each DSA" INDEX { dsaApplIndex } ::= {dsaTable 1} DSAEntry ::= SEQUENCE { dsaApplIndex INTEGER, --bindings dsaAnonymousBinds Counter, dsaUnauthBinds Counter, dsaSimpleAuthBinds Counter, dsaStrongAuthBinds Counter, dsaBindSecurityErrors Counter, -- in-coming operations dsainOps Counter, -- locally executed dsaReadOps Counter, dsaCompareOps Counter, dsaAddEntryOps Counter, dsaRemoveEntryOps Counter, dsaModifyEntryOps Counter, dsaModifyRDNOps Counter, dsaListOps Counter, dsaSearchOps Counter, dsaOneLevelSearchOps Counter, dsaWholeTreeSearchOps Counter, Expires: January 25, 1994 [Page 5] Internet Draft July 1993 -- out going operations dsaReferrals Counter, dsaChainings Counter, dsaMulticastChainings Counter, -- errors dsaSecurityErrors Counter, dsaErrors Counter, -- Cache performance dsaMasterEntries INTEGER, dsaCopyEntries INTEGER, dsaCacheEntries INTEGER, dsaCacheHits Counter, dsaSlaveHits Counters } dsaApplIndex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Reference into application table to allow correlation with general application parameters" ::= {dsaEntry 1} ---- for more information on the DSA ---- [Contact person , Directory Distinguished name ... ?] ---- the corresponding ApplEntry [ applicationIndex = dsaApplIndex] ---- in the applTable should be looked up ---- [ the dsa's appn entry-id = experimental.46.1.1.dsaApplIndex ] dsaAnonymousBinds OBJECT-TYPE Expires: January 25, 1994 [Page 6] Internet Draft July 1993 SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " Number of anonymous (DAP) binds to this DSA since application start" ::= {dsaEntry 2} dsaUnauthBinds OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " Number of un-authenticated binds to this DSA , since application start" ::= {dsaEntry 3} dsaSimpleAuthBinds OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " Number of binds to this DSA that were authenticated using simple authentication procedures, since application start" ::= {dsaEntry 4} dsaStrongAuthBinds OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " Number of binds to this DSA that were authenticated using the strong authentication procedures, since application start. This includes the binds that were authenticated using external authentication procedures" ::= {dsaEntry 5} Expires: January 25, 1994 [Page 7] Internet Draft July 1993 dsaBindSecurityErrors OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of bind operations that have been rejected by this DSA due to inappropriateAuthentication or invalidCredentials." ::= {dsaEntry 6} dsaInOps OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " Number of operations forwarded to this DSA from DUAs or other DSAs , since application start" ::= {dsaEntry 7} dsaReadOps OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of read operations locally executed by this DSA since application startup." ::= {dsaEntry 8} dsaCompareOps OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of compare operations locally executed by this DSA since application startup." ::= {dsaEntry 9} dsaAddEntryOps OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of addEntry operations locally executed by this DSA since application startup." ::= {dsaEntry 10} dsaRemoveEntryOps OBJECT-TYPE Expires: January 25, 1994 [Page 8] Internet Draft July 1993 SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of removeEntry operations locally executed by this DSA since application startup." ::= {dsaEntry 11} dsaModifyEntryOps OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of modifyEntry operations locally executed by this DSA since application startup." ::= {dsaEntry 12} dsaModifyRDNOps OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of modifyRDN operations locally executed by this DSA since application startup." ::= {dsaEntry 13} dsaListOps OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of list operations locally executed by this DSA since application startup." ::= {dsaEntry 14} dsaSearchOps OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of search operations- baseObjectSearches, oneLevelSearches and subTreeSearches, locally executed by this DSA since application startup." ::= {dsaEntry 15} Expires: January 25, 1994 [Page 9] Internet Draft July 1993 dsaOneLevelSearchOps OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of oneLevelSearch operations locally executed by this DSA since application startup." ::= {dsaEntry 16} dsaWholeTreeSearchOps OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of wholeTreeSearch operations locally executed by this DSA since application startup." ::= {dsaEntry 17} dsaReferrals OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of referrals returned by this DSA in response to requests for operations since application startup." ::= {dsaEntry 18} dsaChainings OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of operations forwarded by this DSA to other DSAs since application startup." ::= {dsaEntry 19} dsaSecurityErrors OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of operations forwarded to this DSA which did not meet the security requirements " ::= {dsaEntry 20} Expires: January 25, 1994 [Page 10] Internet Draft July 1993 dsaErrors OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of operations that could not be serviced due to errors other than security errors, and referrals. A partially serviced operation will not be counted as an error. The errors include NameErrors, UpdateErrors, Attribute errors and ServiceErrors." ::= {dsaEntry 21} dsaMasterEntries OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Number of Entries mastered in the DSA" ::= {dsaEntry 22} dsaCopyEntries OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Number of Entries with systematic (slave) copies maintained in the DSA" ::= {dsaEntry 23} dsaCacheEntries OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "Number of Entries cached (non-systematic copies) in the DSA" ::= {dsaEntry 24} Expires: January 25, 1994 [Page 11] Internet Draft July 1993 dsaCacheHits OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of operations that were serviced from the locally held cache, since application startup." ::= {dsaEntry 25} dsaSlaveHits OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION " number of operations that were serviced from the locally held object replications [ shadow entries] since application startup." ::= {dsaEntry 26} -- The DSAInfo table contains statistical data on the DSAs -- with which it [attempts to] interact. This table will -- provide a useful insight into the effect of neighbours -- on the DSA performance. -- Due to resource constraints it may be necessary to -- delete entries. It is suggested that the least recently -- used entries be deleted first. The size of the table and -- procedures for its maintenance will be left to the -- implementation. dsaInfoTable OBJECT-TYPE SYNTAX SEQUENCE OF dsaInfoEntry ACCESS read-only STATUS mandatory ::= { dsa 2 } dsaInfoEntry OBJECT-TYPE SYNTAX DsaInfoEntry ACCESS read-only STATUS mandatory ::= { dsaInfoTable 1 } DsaInfoEntry ::= SEQUENCE { dsaName DistinguishedName, dsaTimeOfCreation TimeTicks, Expires: January 25, 1994 [Page 12] Internet Draft July 1993 dsaTimeOfLastAttempt TimeTicks, dsaTimeOfLastSuccess TimeTicks, dsaFailuresSinceLastSuccess Counter, dsaFailures Counter, dsaSuccesses Counter } dsaName OBJECT-TYPE SYNTAX DistinguishedName ACCESS read-only STATUS mandatory DESCRIPTION " distinguished name of the DSA to which this entry pertains." ::= {dsaInfoEntry 1} dsaTimeOfCreation OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION " The value of sysUpTime when this entry was created. If the entry was created before the network management subsystem was initialized, this object will contain a value of zero." ::= {dsaInfoEntry 2} dsaTimeOfLastAttempt OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION " The value of sysUpTime when the last attempt was made to contact this DSA. If the last attempt was made before the network management subsystem was initialized, this object will contain a value of zero." ::= {dsaInfoEntry 3} dsaTimeOfLastSuccess OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION Expires: January 25, 1994 [Page 13] Internet Draft July 1993 " The value of sysUpTime when the last attempt made to contact this DSA was successful. If there have been no successful attempts this entry will be 0. If the last successful attempt was made before the network management subsystem was initialized, this object will contain a value of zero." ::= {dsaInfoEntry 4} dsaFailuresSinceLastSuccess OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION " The number of failures since the last time an attempt to contact this DSA was successful." ::= {dsaInfoEntry 5} dsaFailures OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION " cumulative failures since the creation of this entry." ::= {dsaInfoEntry 6} dsaSuccesses OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION " cumulative successes since the creation of this entry." ::= {dsaInfoEntry 7} END 6. Acknowledgements ==================== This draft is the product of discussions and deliberations carried out in the following working groups ietf-madman-wg ietf-madman@innosoft.com wide-isode-wg isode-wg@wide.ad.jp wide-netman-wg netman-wg@wide.ad.jp Expires: January 25, 1994 [Page 14] Internet Draft July 1993 7. References ============== [1] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", STD 16, RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990. [2] Case, J., M. Fedor, M. Schoffstall, and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [3] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [4] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions", STD 16, RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991. [5] The X.500 blue book. [6] Freed, N., Kille, S., The Network Services Monitoring MIB, Internet Draft, May 17, 1993. [7] Grillo, P., Waldbusser, S., Host Resources MIB, Internet Draft, June, 1993. [8] Austein, R., Saperia J., DNS Resolver MIB, Internet Draft, July 1993. [9] Austein, R., Saperia J., DNS Server MIB Extensions, Internet Draft, July 1993. Expires: January 25, 1994 [Page 15]   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa25992; 26 Jul 93 5:38 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa25988; 26 Jul 93 5:38 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa26432; 26 Jul 93 5:38 EDT Return-path: glenn@aic.co.jp Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1336) id <01H0ZCAVLLHC984L4B@INNOSOFT.COM>; Mon, 26 Jul 1993 02:01:31 PST Received: from CUNYVM.CUNY.EDU (MAILER@CUNYVMV2) by INNOSOFT.COM (PMDF V4.2-14 #1336) id <01H0ZCAPX6B4984MHK@INNOSOFT.COM>; Mon, 26 Jul 1993 02:01:14 PST Received: from CUNYVM (NJE origin SMTP@CUNYVM) by CUNYVM.CUNY.EDU (LMail V1.1d/1.7f) with BSMTP id 6099; Mon, 26 Jul 1993 05:00:37 -0400 Received: from aic-wide.aic.co.jp by CUNYVM.CUNY.EDU (IBM VM SMTP V2R2) with TCP; Mon, 26 Jul 93 05:00:24 EDT Received: by aic-wide.aic.co.jp (4.1/2.7W) id AA26449; Mon, 26 Jul 93 17:58:09 JST Date: Mon, 26 Jul 1993 17:58:09 +0900 (JST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Glenn Mansfield Subject: Traps & stuff To: steve@isode.com Cc: cooney@wnyose.nctsw.navy.mil, ginsburg@paladin.mitre.org, ietf-madman@innosoft.com Errors-to: ~ned+madman-errors@SIGURD.INNOSOFT.COM Resent-message-id: <01H0ZCAVOJKY984L4B@INNOSOFT.COM> Message-id: <9307260858.AA26449@aic-wide.aic.co.jp> X-VMS-To: IN%"steve@isode.com" X-VMS-Cc: IN%"cooney@wnyose.nctsw.navy.mil", IN%"ginsburg@paladin.mitre.org", IN%"ietf-madman@INNOSOFT.COM" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Steve, Here is the promised write-up on Traps. 1. SNMP (v1) is weak on Traps. A lot of things will have to be left to the implementation. e.g. The choice and selection of the destinations [what trap will be sent to whom] etc. will be implementation specific. In SNMPv2 this situation is rectified. Traps are sent based on the contents of the aclTable and viewTable Tables. 2. The definitions of Traps itself has undergone a big change: the new macro called NOTIFICATION-TYPE is quite different from the earlier TRAP-TYPE. 3. So, I propose that we leave the TRAP definitions aside for the time being. Wherever there is an urgency for TRAPS the generic Traps defined in SNMP (v1) [RFC 1157] may be used. There are coldStart warmStart .... authenticationFailure Traps There is also the enterpriseSpecific Trap which may be qualified further by the specific trap field. 4. Alarms could be and possibly SHOULD be implemented in the Manager AP. Ofcourse, once again, SNMPv2 implementations could use the Alarms, Events and Notifications defined in the Manager-to-Manager MIB [RFC1451]. So, it is unnecessary to define Alarms now. At a later date we may want to make a separate proposal on TRAPS/ NOTIFICATIONS for Network Service Applications [NSAs]. It will be necessary and very useful. cheers Glenn   Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15060; 20 Jul 93 20:06 EDT Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15056; 20 Jul 93 20:06 EDT Received: from THOR.INNOSOFT.COM by CNRI.Reston.VA.US id aa29246; 20 Jul 93 20:06 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-13 #1336) id <01H0Q590BF5C984I4N@INNOSOFT.COM>; Mon, 19 Jul 1993 12:02:48 PST Received: from conversion.innosoft.com by INNOSOFT.COM (PMDF V4.2-13 #1336) id <01H0Q58X6MKW984I4K@INNOSOFT.COM>; Mon, 19 Jul 1993 12:02:37 PST Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-13 #1336) id <01H0Q3KI38ZK984I58@INNOSOFT.COM>; Mon, 19 Jul 1993 12:02:34 PST Date: Mon, 19 Jul 1993 12:01:02 -0800 (PST) Sender:ietf-archive-request@IETF.CNRI.Reston.VA.US From: Ned Freed Subject: RE: Where can I find the draft ? In-reply-to: Your message dated "Mon, 19 Jul 1993 08:40:57 -0400 (EDT)" <9307191240.AA01930@kiyoko> To: amarfurt@kiyoko.fp.trw.com Cc: madman@innosoft.com Errors-to: ned+madman-errors@INNOSOFT.COM Resent-message-id: <01H0Q590BOSI984I4N@INNOSOFT.COM> Message-id: <01H0Q58VCPW2984I58@INNOSOFT.COM> X-VMS-To: IN%"amarfurt@kiyoko.fp.trw.com" X-VMS-Cc: IN%"madman@INNOSOFT.COM" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > I got a mail message that wetted my appetite, but I wasn't able to dig > up the draft in all the usual spots I hunt for such things. Would some > kind soul point me in the direction of a copy of: > draft-ietf-madman-mtamib-01.txt Last time I checked there was a copy at the IETF archive site I use, ftp.nisc.sri.com, in the internet-drafts directory. Ned