Received: from cnri by ietf.org id aa22917; 10 Jul 97 19:57 EDT Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid TAA22056 for ; Thu, 10 Jul 1997 19:56:18 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id TAA22360; Thu, 10 Jul 1997 19:43:30 -0400 (EDT) Received: (from root@localhost) by maelstrom.nexen.com (8.8.5/8.7.3) id TAA12014 for disman-out; Thu, 10 Jul 1997 19:36:52 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id TAA12004 for ; Thu, 10 Jul 1997 19:36:44 -0400 (EDT) Received: from dresden.bmc.com (dresden.bmc.com [198.64.253.250]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id TAA22299 for ; Thu, 10 Jul 1997 19:36:50 -0400 (EDT) Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.5) id SAA23343 for ; Thu, 10 Jul 1997 18:36:57 -0500 (CDT) Received: from cherry.bmc.com(172.17.1.25) by dresden.bmc.com via smap (3.2) id xma023101; Thu, 10 Jul 97 18:36:28 -0500 Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by cherry.bmc.com with ESMTP (8.7.5/8.7.3) id SAA10706 for ; Thu, 10 Jul 1997 18:36:20 -0500 (CDT) Received: by dorothy.peer.com (1.39.111.2/16.2) id AA297217779 for ; Thu, 10 Jul 1997 16:36:19 -0700 Date: Thu, 10 Jul 1997 16:36:19 -0700 From: Randy Presuhn Message-Id: <199707102336.AA297217779@dorothy.peer.com> To: disman@nexen.com Subject: Re: notification filtering and dissemination Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com Hi - A few comments on the X.700-flavored event mib... > Message-Id: <33A1E388.1281@metacomm.com> > Date: Fri, 13 Jun 1997 17:19:20 -0700 > From: Branislav Meandzija > To: Randy Presuhn > Cc: disman@nexen.com > Subject: Re: notification filtering and dissemination > EventType ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "An event type mask is specified as follows: ... > timeDomainViolation(128) > securityServiceORMechanismViolation(256) Change "OR" to "Or" ? > relationshipChange(512) > operationalViolation(1024) > integrationViolation(2048) Change "integration" to "integrity" ? > physicalViolation(4096) > thresholdCrossing(8192) > thresholdClearing(16384) > An event type is indicated if the bit corresponding to its power of > two is set, i.e. if the mask is 3 then communications and > qualityOfService event types are indicated." > SYNTAX OCTET STRING (SIZE (3)) I think EventType should have been defined using BITS. One difficulty with this set is that it is (at least in the CMIP world) architecturally open-ended. This particular representation limits our ability to deal with that open-endedness. > ProbableCause ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "Defined in ITU-T X.733" > SYNTAX BITS { ... > degradedSignal(12), > dTE-DCEInterfaceError(13), eliminate the "-". suggest dteDceInterfaceError. ... > framingError(20), > heatingOrVentilationOrCoolingSystemProblem(21), suggest shortening this label to 32 characters or less, per RFC 1902 7.1.4 > humidityUnacceptable(22), > inputOutputDeviceError(23), > inputDeviceError(24), > lANError(25), suggest lanError ... > softwareError(46), > softwareProgramAbnormallyTerminated(47), suggest shortening this label to 32 characters or less, per RFC 1902 7.1.4 ... > mteEventLastChange OBJECT-TYPE > SYNTAX TimeStamp > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of sysUpTime at the most recent addition or > deletion of a Event or a Event name change. > > A management application can monitor this object to > know that the Event list has changed in a way > requiring reloading of the event names." > ::= { mteEvent 1 } > > mteEventFailures OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of times an attempt to check for a event > condition has failed. This counts individually for each > attempt in a group of targets or each attempt for a > wildcarded object." > ::= { mteEvent 2 } What is the purpose / use of this object and the following two objects? > mteEventLastFailedEvent OBJECT-TYPE > SYNTAX EntryIndex > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The event that last failed an attempt to check for a > event condition." > ::= { mteEvent 3 } > > mteEventLastFailedReason OBJECT-TYPE > SYNTAX FailureReason > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The reason for the last failure of an attempt to check > for a event condition." > ::= { mteEvent 4 } What would this object be used for? I don't see how the description of FailureReason (which is in terms of sending) fits in with this object's description (which is in terms of "checking" (whatever that means)). ... > mteEventLastValueID OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The object identifier from mteEventValueID from the last > attempt to check a event condition. This must > be as full-qualified as possible, including filling in > wild-card information determined in processing." > ::= { mteEvent 7 } What is "mteEventValueID"? I can't find a definition for it. ... > mteEventTable OBJECT-TYPE For several of the objects in this table, it is not clear to me what the initial values should be after the row has been created but before an event has been processed. ... > mteEventChangedObjectId OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The object identifier of the MIB object to check to see > if the event should fire. > > This may be wildcarded by truncating all or part of the > instance portion, in which case the condition is obtained > as if with a GetNext function, checking multiple values > if they exist." > ::= { mteEventEntry 4 } How is "wildcarding" recognized? > mteEventToStateChange OBJECT-TYPE > SYNTAX Unsigned32 > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "If mteEvent ChangedObjectId is a state/status/variable, > this variable identifies the state that causes the > event to be generated." > ::= { mteEventEntry 5 } Is this edge or level sensitive? ... > mteEventProbableCause OBJECT-TYPE > SYNTAX ProbableCause > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This variable defines further probable cause for > the last event of this type." > ::= { mteEventEntry 8 } Value if none yet? > mteEventPerceivedSeverity OBJECT-TYPE > SYNTAX PerceivedSeverity > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "This parameter defines the pereceived severity of the > last event of this type." > ::= { mteEventEntry 9 } Value if none yet? > mteEventTrendIndication OBJECT-TYPE > SYNTAX TrendIndication > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "Indicates the trend of the last event of this type." > ::= { mteEventEntry 10 } Value if none yet? ... ... > mteEventStatus OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The control that allows creation/deletion of entries. > Once made active an entry may not be modified except to > delete it or change its name via mteEventName." > ::= { mteEventEntry 15 } mteEventName is an index. Renaming entries does not sound like a good thing; what requirement does this capability satisfy? What is the motivation for not permitting the other elements of an entry to be modified? It seems like this constraint adds additional complexity without providing any specific value. ... > mteEfdFailures OBJECT-TYPE > SYNTAX Counter32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of times an attempt to invoke an efd > has failed. This counts individually for each > attempt in a group of targets or each attempt for a > wildcarded efd object." > ::= { mteEfd 2 } What is the purpose / use of this attribute and its friends? > mteEfdLastFailedEfd OBJECT-TYPE > SYNTAX EntryIndex > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The efd that last failed an attempted invocation." > ::= { mteEfd 3 } Value if none has failed? > mteEfdLastFailedReason OBJECT-TYPE > SYNTAX FailureReason > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The reason for the last failure of an attempted efd > invocation." > ::= { mteEfd 4 } Value if none has failed? ... > mteEfdStopTime OBJECT-TYPE > SYNTAX DateAndTime > MAX-ACCESS read-create > STATUS current > DESCRIPTION > " This variable defines the date and time at which an unlocked and > enabled EFD starts functioning, i.e. changes its I think you mean "stops". > availability status from available to offDuty." > ::= { mteEfdEntry 6 } What does it mean when this value is less than mteEfdStartTime? > mteEfdDailyStartTime OBJECT-TYPE > SYNTAX TimeTicks > MAX-ACCESS read-create > STATUS current > DESCRIPTION > " This variable defines the daily start time at which an unlocked and > enabled EFD starts functioning, i.e. changes its > availability status from offDuty to available." > ::= { mteEfdEntry 7 } What is the relationship of this to mteEfdStartTime? > mteEfdDailyStopTime OBJECT-TYPE > SYNTAX TimeTicks > MAX-ACCESS read-create > STATUS current > DESCRIPTION > " This variable defines the daily start time at which an unlocked and > enabled EFD starts functioning, i.e. changes its I think you mean "stops" > availability status from available to offDuty." > ::= { mteEfdEntry 8 } Is this in hundredths of a second since midnight, or since the clock time portion of mteEfdStartTime? What if this value is less than the start time? > mteEfdWeeklyMask OBJECT-TYPE > SYNTAX OCTET STRING (SIZE (1)) > MAX-ACCESS read-create > STATUS current > DESCRIPTION > " This variable defines the weekly schedule at which an unlocked and > enabled EFD may start functioning, i.e. changes its > availability status from available to offDuty. A day is > scheduled if the cooresponding power of 2, i.e. 2**3 for > Wednesday is in the mask." > ::= { mteEfdEntry 9 } Use BITS. The current description is far too convoluted, and depends on culture-specific notions of which day is the Nth day of the week. (I bet I can get three different answers from the folks in my office as to what the first day of the week is.) > mteEfdAvailabilityStatus OBJECT-TYPE > SYNTAX AvailabilityStatus > MAX-ACCESS read-only > STATUS current > DESCRIPTION > " This object controls the Availability status of the EFD > which reflects the scheduling." > ::= { mteEfdEntry 10 } Which is it: "controls" or "reflects"? ... > mteEfdDiscriminatedCorrelatedEvents OBJECT-TYPE > SYNTAX EventEntry > MAX-ACCESS read-create > STATUS current > DESCRIPTION > " Any events correlated to this event are ignored." > ::= { mteEfdEntry 15 } Negative descriptions are not helpful. The term "correlated" has been problematic in the ISO/ITU work with notifications. What is it supposed to mean here? > mteEfdChangedObjectId OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "Any events not caused by a change of the value of this object > are ignored." > ::= { mteEfdEntry 16 } This description borders on the incomprehensible. What does "this" refer to? A negative description (defining something in terms of the things it does not do) is generally not useful. ... > mteEfdCreationStatus OBJECT-TYPE > SYNTAX RowStatus > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "The control that allows creation/deletion of entries. > Once made active an entry may not be modified except to > delete it or change its name via mteEfdName." > ::= { mteEfdEntry 21 } This prohibition on entry modification is inconsistant with the inclusion of mteEfdAdministrativeState, and adds complexity without any real justification. At the same time, permitting modification of mteEfdName sounds like a very dangerous thing, since it would scramble the table on the fly, and invalidate any references to the old entry. ... > mteEventStateChange NOTIFICATION-TYPE > OBJECTS > { mteEventName, > mteEventTargetScope, > mteEventToStateChange > } > STATUS current > DESCRIPTION > " State change notification." > ::= { eventMIBNotifications 2 } > > mteEventObjectValueChange NOTIFICATION-TYPE > OBJECTS > { mteEventName, > mteEventTargetScope, > mteEventChangedObjectId > } > STATUS current > DESCRIPTION > " Object value change." > ::= { eventMIBNotifications 3 } How is a StateChange different from an ObjectValueChange? The semantics of the CMIP state change notification can be described in terms of the state attribute group. Since there is no such concept in the SNMP SMI, is this difference really meaningful? ... > mteEventFailureAlarm NOTIFICATION-TYPE > OBJECTS { mteEventName, > mteEventTargetScope, > mteEventLastValueID, > mteEventLastValue, > mteEventLastFailedReason, > mteEventLastFailedTargetGroup, > mteEventLastFailedTargetScope } > STATUS current > DESCRIPTION > "Notification that an attempt to check a event has failed. > > The network manager must enable this notification only with > a certain fear and trembling, as it can easily crowd out more > important information. It should be used only to help diagnose > a problem that has appeared in the error counters and can not > be found otherwise." > ::= { eventMIBNotifications 4 } What possible use could this notification have? I suggest eliminating it. --------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA --------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ---------------------------------------------------------------------   Received: from cnri by ietf.org id aa23402; 10 Jul 97 20:27 EDT Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA22131 for ; Thu, 10 Jul 1997 20:26:47 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id UAA22526; Thu, 10 Jul 1997 20:19:18 -0400 (EDT) Received: (from root@localhost) by maelstrom.nexen.com (8.8.5/8.7.3) id UAA12616 for disman-out; Thu, 10 Jul 1997 20:17:12 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id UAA12606 for ; Thu, 10 Jul 1997 20:17:10 -0400 (EDT) Received: from dresden.bmc.com (dresden.bmc.com [198.64.253.250]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id UAA22485 for ; Thu, 10 Jul 1997 20:17:18 -0400 (EDT) Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.5) id TAA10178 for ; Thu, 10 Jul 1997 19:17:25 -0500 (CDT) Received: from cherry.bmc.com(172.17.1.25) by dresden.bmc.com via smap (3.2) id xma010160; Thu, 10 Jul 97 19:17:23 -0500 Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by cherry.bmc.com with ESMTP (8.7.5/8.7.3) id TAA14861 for ; Thu, 10 Jul 1997 19:17:14 -0500 (CDT) Received: by dorothy.peer.com (1.39.111.2/16.2) id AA054890234 for ; Thu, 10 Jul 1997 17:17:14 -0700 Date: Thu, 10 Jul 1997 17:17:14 -0700 From: Randy Presuhn Message-Id: <199707110017.AA054890234@dorothy.peer.com> To: disman@nexen.com Subject: Disman drafts Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com Hi - There was a lot of enthusiasm and optimism in Memphis. Editors: how are those drafts coming? What shall I put on the agenda for Munich? The deadline for posting drafts is fast approaching... --------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA --------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ---------------------------------------------------------------------   Received: from cnri by ietf.org id aa18569; 11 Jul 97 17:26 EDT Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid RAA25238 for ; Fri, 11 Jul 1997 17:25:07 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id RAA28073; Fri, 11 Jul 1997 17:17:34 -0400 (EDT) Received: (from root@localhost) by maelstrom.nexen.com (8.8.5/8.7.3) id RAA05806 for disman-out; Fri, 11 Jul 1997 17:13:51 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id RAA05797 for ; Fri, 11 Jul 1997 17:13:48 -0400 (EDT) Received: from spog.gaertner.de (spog.gaertner.de [194.45.135.2]) by nexen.nexen.com (8.8.5/8.7.3) with SMTP id RAA17555 for ; Fri, 11 Jul 1997 17:13:56 -0400 (EDT) Received: (from schoenw@localhost) by spog.gaertner.de (8.6.12/Nase) id XAA21862; Fri, 11 Jul 1997 23:13:49 +0200 Date: Fri, 11 Jul 1997 23:13:49 +0200 Message-Id: <199707112113.XAA21862@spog.gaertner.de> From: Juergen Schoenwaelder To: rpresuhn@peer.com CC: disman@nexen.com In-reply-to: <199707110017.AA054890234@dorothy.peer.com> (message from Randy Presuhn on Thu, 10 Jul 1997 17:17:14 -0700) Subject: Re: Disman drafts Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com Randy Presuhn said: Randy> There was a lot of enthusiasm and optimism in Memphis. Randy> Editors: how are those drafts coming? Randy, we had the DISMAN meeting before the SNMPv3 meetings in Memphis. You know that many of the DISMAN volunteers also signed up for SNMPv3 work. The status of the Script MIB is as follows: I have a list of minor modifications that should go into the next document. The reason why I did not go ahead and put out a new draft is actually the ownership thing. We agreed in Memphis to put the ownership into the table index in order to make access control (mib view configurations) simple. This however requires that we have somewhere in the DISMAN MIBs a table which defines the ownership index. This touches a point that I already raised in Memphis: Many of the DISMAN services can be defined pretty much in isolation. There are however some things that are needed to tie all these piececs together and we need to find agreement on these things before we can finish other parts. The critical things are: o Terminology o Common definitions for ownership tables and common TCs. o A model how the DISMAN pieces work together. This probably includes some architectural considerations as well as the internal event handling and the scheduling service. Randy> What shall I put on the agenda for Munich? The three points above are IMHO the most important things to resolve in order to move on. If we can get a solution in Munich, that would be great. Juergen -- Juergen Schoenwaelder (Tel: +49-531-23873-0) Gaertner Datensysteme, Hamburger Strasse 273a, 38114 Braunschweig, Germany   Received: from cnri by ietf.org id aa20187; 11 Jul 97 18:56 EDT Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid SAA25474 for ; Fri, 11 Jul 1997 18:55:39 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id SAA28483; Fri, 11 Jul 1997 18:47:47 -0400 (EDT) Received: (from root@localhost) by maelstrom.nexen.com (8.8.5/8.7.3) id SAA07876 for disman-out; Fri, 11 Jul 1997 18:45:32 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id SAA07866 for ; Fri, 11 Jul 1997 18:45:24 -0400 (EDT) Received: from news1.radix.net (news1.radix.net [209.48.224.41]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id SAA19676 for ; Fri, 11 Jul 1997 18:45:32 -0400 (EDT) Received: from uymfdlvk (port25.annex1.radix.net [209.48.225.25]) by news1.radix.net (8.8.5/8.8.3) with SMTP id SAA29646; Fri, 11 Jul 1997 18:19:27 -0400 (EDT) Message-ID: <33C6AB66.5060@theotg.com> Date: Fri, 11 Jul 1997 17:53:42 -0400 From: "John A. Weiler, Chairman" Reply-To: john_weiler@theotg.com Organization: The OBJECTive Technology Group X-Mailer: Mozilla 3.01 (Win95; I) MIME-Version: 1.0 To: usl@iitb.fhg.de, jleary@nva.lmco.com, tonyw@methods-tools.com, rcliffe@af.pentagon.mil, boylet@af.pentagon.mil CC: xojidm@opengroup.org, nswg@syl.nj.nec.com, nmf-objects@nmf.org, enternet@bbn.com, disman@nexen.com Subject: Re: FED OOTS Update: DISA, White House, Canadian National Defense, UK MoD, DARPA bring international insights References: <199706201410.QAA12075@kreta.iitb.fhg.de> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by cnri.reston.va.us id SAA25474 Dear Object Enthusiast, The US Federal Govt., The White House, Canadian National Defense, UK MoD, Open GIS Consortium and 32 of the top object technology providers are collaborating on this years FED OOTS program to be held on December 8/9, in Alexandria VA. We would like to invite you to participate in our virtual program by linking up with our joint web site with your white papers, and sharing lessons learned and success stories in implementing distributed objects and the internet. Below is an overview of the program. Please feel free to pass it on to your associates as you see fit. thank... John ;~) Federal Object Oriented Technology Symposium =20 =93Architecture Frameworks for Distributed Object Computing and the NET=94= =20 =20 The OBJECTive Technology Group, in conjunction with industry=92s top technology leaders and practitioners, is announcing the third annual Federal Object Oriented Technology Symposium (FED OOTS 97) CIO series.=20 FED OOTS 97 will bring together a thousand of government and industry=92s leading systems CIO=92s, IRM=92s, system architects, and business/technol= ogy managers who seek the benefits of the new distributed object computing model bring and want to learn from those who have already forged ahead. The FED OOTS=92 theme this year will be =93Architecture Frameworks for Distributed Object Computing and the NET=94. This executive forum will b= e taking the next logical step in developing industry-specific Reference Models for Open Distributed Processing (ISO RM-ODP), including the DoD=92= s C4SIR Architecture Framework. This solutions-oriented program is a step-by-step executive educational forum that brings the combined experiences of industry=92s top practitioners to bear in a two day =93boo= t camp=94 with specifically designed solutions segments for CIOs and their IS team.=20 Each of the vertical industry OOTS forums and their domain-specific tracks are presented in four half day =93steps=94 addressing each of the critical stages of designing, developing and deploying distributed enterprise systems:=20 1) Enterprise Architecture, Modeling and Standards (RM-ODP, OMA, UML, Repositories, Use CASE, BPR) 2) Enabling Technologies for the new Internet based Client/Server (GIS, Java, C++, Smalltalk, TCL, CGI, IDL, OORAD, Active X, Push, Browsers, HTML, HTTP, IIOP, RMI, TP Monitors) 3) Distributed Computing Infrastructure (JAVA Beans, CORBA, DCE, DCOM & Messaging Middleware) 4) Data Management, Access and Security (ODBC, RDBMS, OODBMS, ORDMS, JDBC, Firewalls) Responding to feedback from last years FED OOTS, the OTG sponsored Defense Object track at STC, and input from various distributed computing working groups (OMG, DWGC), the OOTS program committee has decided to run three concurrent =93tracks=94 centering on the domain-specific applications of object technology and the internet, and a fourth CIO roundtable exclusively for CIOs, CTO and senior IRM officials; DEFENSE OBJECTS: The New Client/Server Model for the Defense Information Infrastructure (DII COE) INTEL/GEOSPATIAL: Moving Mountains of Complex Data in a Secure World=20 BUSINESS OBJECTS: Bringing the Best of Commercial Practices to Government (Java, Messaging, Medical Informatics, E-Commerce, Data Warehousing) Each of these domain-specific tracks will be produced by its own set of sponsors, track chairs and agencies who have homogeneous interests and will include interlocking sessions from practioners, integrators and ISV=92s. Concurrent with these tracks, industry will be hosting the CIO Round Table, an invite only session that brings these top minds together for some one-on-one discussions on the challenges and rewards of incorporating distributed computing and the internet.=20 Each of these domain-specific tracks will be produced by its own set of sponsors, track chairs and agencies who have homogeneous interests.=20 Each Track will include interlocking sessions from users, integrators and ISV=92s. After each session, our distinguish speakers will meet with the members of the CIO round table. To ensure a top echelon educational and informational experience, the OOTS series has drawn on the combined expertise of industry=92s foremost authorities from BEA, Computer Associates, Canadian National Defense, CIA, Commerse, Digital, DISA, DIA, EDS, Ernst & Young, Expersoft, FANNIE MAE, GIGA, IBM/Transarc, Informix, Iona, Lockheed Martin, Microsoft, Mitre, NASA, Navy, NIMA, Netscape, NIIIP, NIST, NSA, OMG, OpenGroup, OpenGIS, Rational Software, SAIC, Sun Microsystems, Sybase, Tivolli, Unisys, UK MoD, US AF, Visigenic, The White House and other notable organizations.=20 Focused on information infrastructure to support the converging Component Object Technology and Internet markets, The OBJECTive Technology Group (The OTG) and the OOTS sponsors will be cooperating on these industry-specific CIO forums in the coming months: FED OOTS =9197, December 8 - 9, Alexandria, VA (Government, Defense/Aerospace, Intelligence) COMM OOTS =9198, Jan. 98, Princeton, NJ (Telecom, Entertainment, Media) FINANCIAL OOTS =9198, April 98, New York, NY (Banking, Finance, Insurance= ) MED OOTS =9198, Date TBD (Medical and Health Care) >>>>>>>> PARTICIPATION OPTIONS<<<<<<<<<< The success of the OOTS program series is due to the cooperative nature of its sponsors. To make the most of your involvement, each participating organization will be provided the following support options: =B7 Distinguished Speaker - Primary Technologist, CIO or CTO to share in lessons learned. =B7 OOTS Program Committee - to aid in development an oversight of program. =B7 Track/Step Chair - support content development of sessions, recruit speakers and refine agenda. =B7 Bi-directional web link - event promotion, presentations and white papers to be posted on sponsors web site and linked via the www.theotg.com web site. =20 =B7 Joint announcements - sponsors will be provided with program invitations and electronic notices to distribute to key clients, associates and internal staff. Staff of supporting organization may attend at a greatly reduced rate . Attend - For those who want to just come and learn, the all inclusive two day package (lunch, breakfast, etc) is $795. less sponsor, group or early bird discounts as may be available. Booths and sponsorship packages are available from $2,500. Call 703-768-0400 for more information. >>>>>>>>> PAST AND PRESENT OOTS SPEAKERS <<<<<<<<<<<< Albert Gore, Jr., Vice President, The White House (pending final confirmation) Dr. Richard Soley, Technical Director, VP, Object Management Group Bill Mularie, Head, Science and Technology, NIMA Dr. Henry Kelly, Assoc. Director, Science and Policy, The White House Dr. Marvin Langston, CIO, Department of the Navy David Lehman, CTO, Mitre Corporation Dr. John Schill, Director of Advanced Technology, DARPA JPO Bill James, Director, Technology and Architecture, HQ USAF David Schell, President, Open GIS Consortium John Gilligan, PMO, HQ AF Dr. Frank Perry, Technical Director, J6/JIEO DISA Thomas Atwood, President, Cinebase Bob Epstein, Founder and Chairman, Sybase=20 Adelle Goldberg, Founder, ParcPlace Systems Eric Sargent, Director General, IRM, Canadian Dept. of National Defense Richard Green, GM, Solaris Product Group, SunSoft=20 Bob Zurek, VP, Powersoft Business Unit, Sybase Alfred Spector, GM, Transaction Processing Systems, IBM, CEO Transarc=20 John Slitz, VP Object Technology/Architecture and Design, IBM=20 Ivar Jacobson, VP Business Objects, Rational Software Ken Jacobs, EVP Server Products, Oracle=20 Rod Butters, Sr. Director of Network Computing Architectures, Oracle Dr. Jim Stikeleather, Executive Director, Perot Systems Dr. Michael Stonebraker, CTO, Informix, author, "Migrating Legacy Systems" Jon Hopkins, Director Object Technology, Rational Software=20 Luther Hampton, Sr. Consultant Lockheed Martin, ACC Jens Christensen, CTO, Visigenic Software Annrai O'Toole, Chief Technology Officer, IONA Technologies Don Deutch, SQL 3 Committee Chair, Sybase Tim McGowan, Sr. Systems Engineering Mgr. EDS Ely Eshel, CTO, Momentum Software=20 Sam Greenblatt, Sr. VP, Computer Associates Dr. Francois Bancilhon, President, O2 Technologies Dr. Andrew Wade, Founder, Objectivity Dr. Alen Brown, CTO, Cinebase Dr. Sridhar Iyengar, Director Advanced Technology, Unisys Maj. Richard Weisman, Director of C2 Planning, Canadian Dept. of National Defense (NATO) Bill Ravkin, CTO, Powersoft Corp. (Sybase) Amir Golshan, Manager, Distributed Computing Group, Ernst and Young Adrian Bowles, VP Research, GIGA Information Group Jonathan Chinitz, President, IntelliSoft Corp. Lyle Cox, Director Stategic Planning, ANSER David Harris, Applications Manager, SES, CIA=20 Ron Zahavi, Director of SI, Concept 5, co-author: "The Essential CORBA" Bob Scher, President, Messaging Oriented Middleware Assoc. Kevin Tyson, Enterprise Engineering Associates=20 Mary Jo McCauley, Sr. Object Technology Consultant, Digital Equipment Mark Ryland, Technical Evangelist Active X/DCOM, Microsoft=20 John Weiler, Founder/Chairman, The OBJECTive Technology Group >>>>>>>>> ABOUT THE OTG <<<<<<<<<<<< The OBJECTive TECHNOLOGY GROUP (The OTG), an active OMG and AFCEA member, represents a federation of open systems providers committed to transitioning industry into the converging Distributed Computing and Internet technologies. The OTG aids in the development of these architectural frameworks through architecture modeling, technology assessment, education, and mentoring. Though a cooperative network of software suppliers, user groups (government and commercial), integrators and testing labs, this web based =93Interoperability Clearinghouse=94 wil= l become a reference tool for assembling =93plug and play=94 suites of interworking componentry that both conform to standards and ensure smooth migration of legacy systems. How these industry specific Reference Models evolve will be detailed at upcoming vertical industry OOTS executive forums.=20 These efforts will benefit those industries most where consolidation and market changes necessitate the use of internet/object technology as a means of becoming more responsive to user needs, and ease the process of enterprise integration. The OBJECTive Technology Group provides information architecture migration mentoring for financial, telcom and media industry, and is available to federal agencies via a number of contracts: GSA, DEIS, Defense Medical Information Management D/SiDDOMS contract, CIO ISP, and the Defense Information Infrastructure/ Integration Contract (DII/IC).=20 John A. Weiler Chairman The OTG 703-768-0400 john_weiler@theotg.com http://www.theotg.com   Received: from cnri by ietf.org id aa15982; 14 Jul 97 15:28 EDT Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid PAA01475 for ; Mon, 14 Jul 1997 15:27:22 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id PAA05709; Mon, 14 Jul 1997 15:19:35 -0400 (EDT) Received: (from root@localhost) by maelstrom.nexen.com (8.8.5/8.7.3) id PAA26365 for disman-out; Mon, 14 Jul 1997 15:07:45 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id PAA26354 for ; Mon, 14 Jul 1997 15:07:35 -0400 (EDT) Received: from seymour16.snmp.com (seymour16.snmp.com [192.147.142.16]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id PAA23185 for ; Mon, 14 Jul 1997 15:07:35 -0400 (EDT) Received: from LOCALHOST.snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by seymour16.snmp.com with SMTP (cf v2.9s-SNMP) id PAA13215; Mon, 14 Jul 1997 15:02:28 -0400 (EDT) Message-Id: <199707141902.PAA13215@seymour16.snmp.com> To: Randy Presuhn Cc: disman@nexen.com Subject: Re: Disman drafts In-reply-to: Your message of Thu, 10 Jul 97 17:17:14 -0700. <199707110017.AA054890234@dorothy.peer.com> Date: Mon, 14 Jul 97 15:02:26 EDT From: David Levi Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com > Hi - > > There was a lot of enthusiasm and optimism in Memphis. > > Editors: how are those drafts coming? > > What shall I put on the agenda for Munich? > > The deadline for posting drafts is fast approaching... Randy, I have not had any time to work on this since Memphis, due to the snmpv3 work, and day job commitments. I doubt there will be a new script MIB draft before Munich. -Dave ------------------------------------------------------------------------- David Levi || SNMP Research || +1 423 573-1434 || levi@snmp.com -------------------------------------------------------------------------   Received: from cnri by ietf.org id aa16031; 14 Jul 97 15:30 EDT Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid PAA01484 for ; Mon, 14 Jul 1997 15:29:31 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id PAA05753; Mon, 14 Jul 1997 15:20:42 -0400 (EDT) Received: (from root@localhost) by maelstrom.nexen.com (8.8.5/8.7.3) id PAA26748 for disman-out; Mon, 14 Jul 1997 15:18:54 -0400 (EDT) Received: from nexen.nexen.com (nexen.nexen.com [204.249.96.18]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id PAA26738 for ; Mon, 14 Jul 1997 15:18:50 -0400 (EDT) Received: from smtp.abac.com (smtp.abac.com [208.137.248.30]) by nexen.nexen.com (8.8.5/8.7.3) with ESMTP id PAA23357 for ; Mon, 14 Jul 1997 15:18:58 -0400 (EDT) Received: from bmeandzija_nt ([168.84.65.19]) by smtp.abac.com (Netscape Mail Server v1.1) with SMTP id AAA142; Mon, 14 Jul 1997 12:20:04 +0100 Message-ID: <33CA7926.1EC9@metacomm.com> Date: Mon, 14 Jul 1997 12:08:22 -0700 From: Branislav Meandzija Reply-To: bran@metacomm.com Organization: Meta Communications, Inc. X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: Randy Presuhn CC: disman@nexen.com Subject: Re: notification filtering and dissemination References: <199707102336.AA297217779@dorothy.peer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com Randy Presuhn wrote: > > Hi - > > A few comments on the X.700-flavored event mib... > Randy, Thanks for the comments. They are good. How shall we poceed with this? Shall we go ahead and make this a draft? Do you want to do the same with an X-700 flavored logs MIB? Shall this be separate from Bob's events and notifications MIBs? What is the status of those anyway? Branislav   Received: from cnri by ietf.org id aa19656; 17 Jul 97 18:44 EDT Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid SAA13861 for ; Thu, 17 Jul 1997 18:42:49 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id SAA25356; Thu, 17 Jul 1997 18:33:42 -0400 (EDT) Received: (from root@localhost) by maelstrom.nexen.com (8.8.5/8.7.3) id SAA04646 for disman-out; Thu, 17 Jul 1997 18:29:27 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id SAA04630 for ; Thu, 17 Jul 1997 18:29:21 -0400 (EDT) Received: from charity.harvard.net (charity.harvard.net [206.137.222.16]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id SAA25312 for ; Thu, 17 Jul 1997 18:29:30 -0400 (EDT) Received: from xedia.com (madway.xedia.com [198.202.232.199]) by charity.harvard.net (8.8.5/8.7.3) with SMTP id SAA00686 for ; Thu, 17 Jul 1997 18:30:37 -0400 (EDT) Received: from (espanola) by xedia.com (4.1/SMI-4.1) id AA28775; Thu, 17 Jul 97 18:23:42 EDT Received: by (5.x/SMI-SVR4) id AA11586; Thu, 17 Jul 1997 18:28:57 -0400 Date: Thu, 17 Jul 1997 18:28:57 -0400 From: Maria Greene Message-Id: <9707172228.AA11586@> To: disman@nexen.com Subject: bounce test, do not read Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com testing, one two three...   Received: from cnri by ietf.org id aa17716; 18 Jul 97 20:02 EDT Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid UAA17538 for ; Fri, 18 Jul 1997 20:00:51 -0400 (EDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id TAA00702; Fri, 18 Jul 1997 19:51:31 -0400 (EDT) Received: (from root@localhost) by maelstrom.nexen.com (8.8.5/8.7.3) id TAA20725 for disman-out; Fri, 18 Jul 1997 19:36:22 -0400 (EDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by maelstrom.nexen.com (8.8.5/8.7.3) with ESMTP id TAA20715 for ; Fri, 18 Jul 1997 19:36:13 -0400 (EDT) Received: from smtp.abac.com (smtp.abac.com [208.137.248.30]) by guelah.nexen.com (8.8.5/8.7.3) with ESMTP id TAA00630 for ; Fri, 18 Jul 1997 19:36:21 -0400 (EDT) Received: from bmeandzija_nt ([168.84.65.19]) by smtp.abac.com (Netscape Mail Server v1.1) with SMTP id AAA150; Fri, 18 Jul 1997 16:37:44 +0100 Message-ID: <33CFFB7A.7FD9@metacomm.com> Date: Fri, 18 Jul 1997 16:25:46 -0700 From: Branislav Meandzija Reply-To: bran@metacomm.com Organization: Meta Communications, Inc. X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: Randy Presuhn CC: disman@nexen.com Subject: Re: notification filtering and dissemination References: <199707170254.AA084868086@dorothy.peer.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-disman@nexen.com Precedence: bulk X-Info: [Un]Subscribe to disman-request@nexen.com, submissions to disman@nexen.com Randy Presuhn wrote: > At this time, I'd suggest posting an internet draft containing a revised > proposal. Working group discussion will determine its fate. One internet draft comming up in about two weeks. Branislav