Delivery-Date: Fri, 03 May 1996 01:49:07 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id BAA11917 for X-agentx-local; Fri, 3 May 1996 01:49:07 -0700 (PDT) Received: from venere.unial.it ([130.192.116.1]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id BAA11842 for ; Fri, 3 May 1996 01:48:56 -0700 (PDT) Received: by venere.unial.it (5.65/DEC-Ultrix/4.3) id AA26387; Fri, 3 May 1996 10:50:05 +0200 Received: from pulcinella.it. by cicladi (5.0/SMI-SVR4) id AA01477; Fri, 3 May 1996 10:45:53 --100 Received: by pulcinella.it. (5.0/SMI-SVR4) id AA02738; Fri, 3 May 1996 10:47:17 +0200 Date: Fri, 3 May 1996 10:47:17 +0200 From: inf2@cicladi.unial.it (Degiorgi Marco) Message-Id: <9605030847.AA02738@pulcinella.it.> To: agentx@fv.com subscribe inf2@cicladi.unial.it   Delivery-Date: Fri, 03 May 1996 12:25:50 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id MAA07476 for X-agentx-local; Fri, 3 May 1996 12:25:50 -0700 (PDT) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id MAA07467 for ; Fri, 3 May 1996 12:25:47 -0700 (PDT) Message-Id: <199605031925.MAA07467@zloty.fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 4564; Fri, 03 May 96 15:24:43 EDT Date: Fri, 3 May 96 21:25:17 DST From: "Bert Wijnen" To: agentx@fv.com Subject: 02: Architecture - SubAgent OID and sysORTable I have chosen a new subheading under 02: Architecture I did not know where to fit this otherwise. Hope that is OK. At the L.A. agentX meetings I suggested that I was thinking about mapping the subAgent OID (as passed with the DPI_OPEN request) into the sysORTable. The idea here is that the OID by which you identify you subagent is the OID that represents the AGENT-CAPABILITIES statement for that subagent. Some of the people present did not agree to that. Can they pls explain (again) why they do not agree and how they see that we will dynamically update the sysORTable when a new sub-agent registers any subtrees? Thanks, Bert   Delivery-Date: Tue, 14 May 1996 04:44:31 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id EAA10558 for X-agentx-local; Tue, 14 May 1996 04:44:31 -0700 (PDT) Received: from lepus.celepar.br (lepus.celepar.br [200.6.40.33]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id EAA10545 for ; Tue, 14 May 1996 04:44:28 -0700 (PDT) From: armando@lepus.celepar.br Received: from [200.17.110.173] by lepus.celepar.br (AIX 3.2/UCB 5.64/AIX-22-06-95) id AA92725; Tue, 14 May 1996 08:45:44 -0200 Date: Tue, 14 May 1996 08:45:44 -0200 Message-Id: <9605141045.AA92725@lepus.celepar.br> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Subject: subscribe To: agentx@fv.com X-Mailer: SPRY Mail Version: 04.00.06.17   Delivery-Date: Tue, 14 May 1996 09:02:03 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA04955 for X-agentx-local; Tue, 14 May 1996 09:02:02 -0700 (PDT) Received: from stratacom.strata.com (stratacom.strata.com [204.179.0.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id JAA04933 for ; Tue, 14 May 1996 09:02:01 -0700 (PDT) Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA19882; Tue, 14 May 96 09:01:58 PDT Received: from santa.strata.com (santa-le1) by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA09144; Tue, 14 May 96 09:01:57 PDT Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA02561; Tue, 14 May 96 09:01:57 PDT Date: Tue, 14 May 96 09:01:57 PDT From: dfrancisco@stratacom.com (Dale Francisco) Message-Id: <9605141601.AA02561@santa.strata.com> To: wijnen@vnet.ibm.com Subject: Re: 02: Architecture - SubAgent OID and sysORTable Cc: agentx@fv.com Bert, According to my notes (LA IETF, March 6th agentx meeting), the person who stated disagreement with your approach was Maria Greene; she said that it was "inconsistent with the Entity MIB use of sysORTable". Dale > Date: Fri, 3 May 96 21:25:17 DST > From: "Bert Wijnen" > To: agentx@fv.com > Subject: 02: Architecture - SubAgent OID and sysORTable > > At the L.A. agentX meetings I suggested that I was thinking about > mapping the subAgent OID (as passed with the DPI_OPEN request) into > the sysORTable. The idea here is that the OID by which you identify > you subagent is the OID that represents the AGENT-CAPABILITIES > statement for that subagent. > > Some of the people present did not agree to that. Can they pls explain > (again) why they do not agree and how they see that we will dynamically > update the sysORTable when a new sub-agent registers any subtrees? > > Thanks, Bert   Delivery-Date: Wed, 15 May 1996 07:58:05 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id HAA24610 for X-agentx-local; Wed, 15 May 1996 07:58:04 -0700 (PDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id HAA24585 for ; Wed, 15 May 1996 07:58:02 -0700 (PDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id KAA17968 for ; Wed, 15 May 1996 10:58:00 -0400 (EDT) Received: from avalon.nexen.com (avalon.nexen.com [204.249.99.77]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id KAA25468 for ; Wed, 15 May 1996 10:58:00 -0400 (EDT) Received: (from greene@localhost) by avalon.nexen.com (8.7.3/8.7.3) id KAA09387; Wed, 15 May 1996 10:57:59 -0400 (EDT) Date: Wed, 15 May 1996 10:57:59 -0400 (EDT) From: Maria Greene Message-Id: <199605151457.KAA09387@avalon.nexen.com> To: agentx@fv.com Subject: MIB requirements At the LA IETF meeting I volunteered to coordinate work on the agentx MIB(s). Before I go very far, I want to solicit other's opinions on the requirements for the MIB. Back in November, Andy Bierman drew this diagram to illustrate the spectrum of ideas about how much visibility and control people thought a management station should have into the internal distribution of an agent: total visibility some visibility sub-agents are and control no control invisible +----------------+-------------------+ SNMPv2 proxy saMIB SNMPv1 Personally, I lean toward the right side of this spectrum. However, I can see the desire, as expressed by Dave Harrington in the past, to not hide information from the manager. If we have the capability of providing information on the registered subagents this may be useful diagnostic information for the agent developer and for a manager who is seeing problems with a system. By embedding a management subsystem in the device, we have added another thing that can be managed! On the other hand, I resist the temptation to "instrument everything that moves". Just because we can make a MIB for it, should we? Will we make the user confused over the distinction between a Logical Entity (as enumerated in the Entity MIB) and a subagent? The former is important because it is related to context/community strings and therefore to access control and security administration. The latter is normally not interesting. So, I am floating a proposal that we define a subagent MIB based on Bert's that will support the following management functions: o Enumerate the set of subagents currently registered or previously registered (within a limited time). o Identify the subagent (including vendor), the registration/deregistration time, transport address, agentx protocol version, etc. o Identify the set of MIB trees the subagent implements. Possibly priority? Possibly instances? o Gather statistics about the protocol operation such as the number of requests handled by each subagent. o Control protocol operation parameters such as the timeout interval for messages between the master agent and subagents. (Necessary?) In addition, we may add a MIB or MIB group to support subagent reservation of index values in order to support more efficient protocol operations and allow multiple subagents to implement rows in the same table without conflict. Jeff Case's company may have a starting point for this. Do we need to add information that relates a subagent to one or more logical entities and therefore to associated community/context/view? Do we need to add information that relates subagents to entries in the Application MIB? My proposal is that we define this MIB but that we make support for it be optional (ack, I can't believe using the evil "o" word! :) ) While I personally think the MIB may have limited value, it would be unfortunate if there were different versions of it defined by different agentx vendors. Opinions, please. Maria ________________________________________________________________________ Maria N. Greene greene@nexen.com Ascom Nexion 289 Great Rd., Acton MA 01720 USA +1 508 266-4570   Delivery-Date: Wed, 15 May 1996 08:46:33 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id IAA08174 for X-agentx-local; Wed, 15 May 1996 08:46:32 -0700 (PDT) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id IAA08166 for ; Wed, 15 May 1996 08:46:31 -0700 (PDT) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id LAA18414; Wed, 15 May 1996 11:46:22 -0400 (EDT) Received: from avalon.nexen.com (avalon.nexen.com [204.249.99.77]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id LAA26084; Wed, 15 May 1996 11:46:21 -0400 (EDT) Received: (from greene@localhost) by avalon.nexen.com (8.7.3/8.7.3) id LAA09446; Wed, 15 May 1996 11:46:05 -0400 (EDT) Date: Wed, 15 May 1996 11:46:05 -0400 (EDT) From: Maria Greene Message-Id: <199605151546.LAA09446@avalon.nexen.com> To: dfrancisco@stratacom.com (Dale Francisco) cc: wijnen@vnet.ibm.com, agentx@fv.com Subject: Re: 02: Architecture - SubAgent OID and sysORTable References: <9605141601.AA02561@santa.strata.com> Hi, Bert, Dale. It certainly would make life easier if each entry in the sysORTable was the OID of a subagent. In the Entity MIB working group we concluded that each Logical Entity should implement the system group (and therefore the sysORTable) in its naming scope. By sweeping the entLogicalTable with the "default" context/community, you can determine what the Logical Entities are and their corresponding context/community. Then, by sweeping the sysORTable with the appropriate context/community string, you can (indirectly through AGENT-CAPABILITIES) determine the set of managed objects each entity supports. More than one subagent can register the same OIDs and the same instances, in which case the context/community string is needed in order to dispatch the request to the correct subagent. So, my real question is how does a subagent get associated with a Logical Entity (naming scope, context, community string...)? Maybe that's part of the open request, too? Maria >>>>> On Tue, 14 May 96 09:01:57 PDT, dfrancisco@stratacom.com (Dale Francisco) said: Dale> Bert, According to my notes (LA IETF, March 6th Dale> agentx meeting), the person who stated disagreement with Dale> your approach was Maria Greene; she said that it was Dale> "inconsistent with the Entity MIB use of sysORTable". Dale> Dale > Date: Fri, 3 May 96 21:25:17 DST > From: "Bert Wijnen" > To: agentx@fv.com > Subject: 02: Architecture - SubAgent OID and sysORTable > > At the L.A. agentX meetings I suggested that I was thinking about > mapping the subAgent OID (as passed with the DPI_OPEN request) into > the sysORTable. The idea here is that the OID by which you identify > you subagent is the OID that represents the AGENT-CAPABILITIES > statement for that subagent. > > Some of the people present did not agree to that. Can they pls explain > (again) why they do not agree and how they see that we will dynamically > update the sysORTable when a new sub-agent registers any subtrees? > > Thanks, Bert Dale> Dale> ================ Dale> This e-mail message was sent to all subscribers to the Dale> agentx mailing list. Dale> To unsubscribe from this mailing list, please send mail to: Dale> agentx-request@fv.com Dale> with Dale> Subject: unsubscribe your.address@your.domain Dale> (NOTE: Please do not reply to this message to unsubscribe. You must send Dale> your request to agentx-request@fv.com Thank you.)   Delivery-Date: Wed, 15 May 1996 11:50:58 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id LAA22725 for X-agentx-local; Wed, 15 May 1996 11:50:58 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id LAA22719 for ; Wed, 15 May 1996 11:50:56 -0700 (PDT) Received: from flume.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id OAA12660; Wed, 15 May 1996 14:41:36 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA08833; Wed, 15 May 1996 14:40:54 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA00314; Wed, 15 May 1996 14:41:50 -0400 Message-Id: <9605151841.AA00314@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: 02: Architecture - SubAgent OID and sysORTable In-Reply-To: Your message of "Wed, 15 May 96 11:46:05 EDT." <199605151546.LAA09446@avalon.nexen.com> Date: Wed, 15 May 96 14:41:49 -0400 From: Mike Daniele X-Mts: smtp Hi Maria, Clearly we'd like AgentX to support subagents [that know nothing of contexts] being able to add their agent caps oid(s) into the sysORTable. But you've pointed out some inconsistencies of this wrt both AgentX supporting contexts, and the Entity MIB. >More than one subagent can register the same OIDs and the same >instances, in which case the context/community string is needed in >order to dispatch the request to the correct subagent. So, my real >question is how does a subagent get associated with a Logical Entity >(naming scope, context, community string...)? Maybe that's part of the >open request, too? Currently (and its had minimal discussion) a subagent may specify a "context" when it registers a "region". A region is sort of an extended subtree. >In the Entity MIB working group we concluded that each Logical Entity >should implement the system group (and therefore the sysORTable) in >its naming scope. This would happen as a natural part of AgentX processing if the subagent registered the system group within that context. [showing his Entity MIB ignorance, Mike then asked] Is there a one-to-one relationship between Logical Entities and naming scopes? >By sweeping the entLogicalTable with the "default" >context/community, you can determine what the Logical Entities are and >their corresponding context/community. Then, by sweeping the >sysORTable with the appropriate context/community string, you can >(indirectly through AGENT-CAPABILITIES) determine the set of managed >objects each entity supports. If I understand you, it seems like if AgentX supports subagents registering within contexts, it should also support entLogicalTable. Here's a floater: ~~ A subagent may specify a list of "entry data" in the OPEN PDU (which establishes the logical connection with the master agent). Each item in the list becomes either an entLogicalEntry, or a sysOREntry. The AgentX "service" implements entLogicalTable, the system group and the snmp group within the default context. By "service" I mean within a compliant AgentX master agent implementation. (The vendor ships a subagent that handles these objects, for instance). The entries sent in OPEN PDUs are included in these tables, within the default context. Subsequently, a subagent may register MIB regions within the default context, or within any context it specified in its OPEN. Subagents that register regions in non-default contexts are responsible for registering (and thereby implementing) the system group for those contexts. ~~ Regards, Mike   Delivery-Date: Thu, 16 May 1996 08:01:47 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id IAA11165 for X-agentx-local; Thu, 16 May 1996 08:01:46 -0700 (PDT) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id IAA11159 for ; Thu, 16 May 1996 08:01:46 -0700 (PDT) Received: from [171.69.128.42] (gryphon.cisco.com [171.69.128.42]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id IAA28402 for ; Thu, 16 May 1996 08:01:39 -0700 X-Sender: bstewart@puli.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 16 May 1996 11:01:41 -0400 To: agentx@fv.com From: bstewart@cisco.com (Bob Stewart) Subject: Re: MIB requirements Circa 10:57 AM 5/15/96, Maria Greene bitwhacked: >My proposal is that we define this MIB but that we make support for it >be optional (ack, I can't believe using the evil "o" word! :) ) While >I personally think the MIB may have limited value, it would be >unfortunate if there were different versions of it defined by >different agentx vendors. Opinions, please. "Optional" bothers me some, too, but I see your point. We could make a distinction between a manageable distributed agent and one that's not. If you do a remotely manageable distributed agent, you must implement this MIB. We could even go so far as fully and minimally manageable if the MIB has clear divisions of effort. The biggest question comes in on how much time will be spent designing the MIB. If the demand and benefit are so marginal that we make it optional, we have to seriously question whether we should spend time designing it. Forward progress on agentx has been fairly slow. The more work we take on, the slower the progress. That said, the information you suggested sounds interesting, if you like to look inside things and see how they work. Bob   Delivery-Date: Fri, 17 May 1996 12:27:32 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id MAA02622 for X-agentx-local; Fri, 17 May 1996 12:27:32 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id MAA02616 for ; Fri, 17 May 1996 12:27:31 -0700 (PDT) Received: from flume.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id PAA18730; Fri, 17 May 1996 15:04:17 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA26286; Fri, 17 May 1996 15:03:46 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA01221; Fri, 17 May 1996 15:04:48 -0400 Message-Id: <9605171904.AA01221@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: MIB requirements Date: Fri, 17 May 96 15:04:47 -0400 From: Mike Daniele X-Mts: smtp >So, I am floating a proposal that we define a subagent MIB based on >Bert's that will support the following management functions: > o Enumerate the set of subagents currently registered or > previously registered (within a limited time). I'd rather not keep history of attached subagents. > o Identify the subagent (including vendor), the > registration/deregistration time, transport address, agentx > protocol version, etc. ** nit alert ** We've been using the term "registration" to mean letting the master agent know what "subtrees" you implement. I think here we want the time of the subagent's logical connection. > o Identify the set of MIB trees the subagent implements. Possibly > priority? Possibly instances? If this data is intended to help subagent developers debug, and admins to learn what's happening within the distributed agent, it might be more useful to reflect the master agent's "dispatch table". If several subagents have registered overlapping subtrees, simply listing each subagent's registrations won't provide enough information to know what's happening (why subagent X never sees any requests for fooEntries). If we had a table indexed by { registered "subtree" oid, dispatch_factor } where dispatch_factor is a small integer indicating this "subtree"'s relative order, then you could really see who gets dispatched to for what. (This would fall out naturally if the master did region splitting as described in the latest rough draft, those of you who've seen it) The table entries would contain an index into the subagent table, priority, etc. If registrations are done within a context, then this table ought to reflect that. And perhaps this would provide sufficient distinction between suagents and Logical Entities. > o Control protocol operation parameters such as the timeout > interval for messages between the master agent and > subagents. (Necessary?) I vote no. Seems to me a timeout value is something a subagent developer knows about, and codes into the subagent. >Do we need to add information that relates a subagent to one or more >logical entities and therefore to associated community/context/view? Hopefully partially answered above? >Do we need to add information that relates subagents to entries in the >Application MIB? I'm punting this one. >My proposal is that we define this MIB but that we make support for it >be optional (ack, I can't believe using the evil "o" word! :) ) While >I personally think the MIB may have limited value, it would be >unfortunate if there were different versions of it defined by >different agentx vendors. Opinions, please. I agree we should define a MIB. Not sure about how much should be optional. >In addition, we may add a MIB or MIB group to support subagent >reservation of index values in order to support more efficient >protocol operations and allow multiple subagents to implement rows in >the same table without conflict. Jeff Case's company may have a >starting point for this. ***** IMPORTANCE ALERT ***** While we may use a MIB for index reservation, we may not. (It may just be more AgentX PDUs.) But in my view, working out index reservation is much more important than working out the saMib-like things listed above. Anything you, Jeff, or anyone else can do to start things rolling on reservation would be great. (By now I'm sure several of you are tired of my "index reservation != mib" crusade, so I'll stop :-) Thanks, Mike   Delivery-Date: Tue, 21 May 1996 09:53:59 -0700 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA09580 for X-agentx-local; Tue, 21 May 1996 09:53:51 -0700 (PDT) Received: from zafu.bbn.com (ZAFU.BBN.COM [128.89.0.25]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id JAA09577 for ; Tue, 21 May 1996 09:53:49 -0700 (PDT) Received: from [128.89.3.200] (CBENNETT.BBN.COM [128.89.3.200]) by zafu.bbn.com (8.7.5/8.6.5) with SMTP id MAA24946; Tue, 21 May 1996 12:55:21 -0400 (EDT) X-Sender: cbennett@po1.bbn.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 21 May 1996 13:02:51 -0500 To: atm@tango.cos.com, rwnmcc@external.iihe.rtt.be, snmsigl@nemo.nmf.com, agentx@zloty.fv.com From: isinm97@bbn.com (ISINM '97) Subject: ISINM '97 Call for Papers -- July 1 deadline! IFIP/IEEE INTERNATIONAL SYMPOSIUM ON INTEGRATED NETWORK MANAGEMENT C A L L F O R P A R T I C I P A T I O N Hotel Del Coronado, San Diego, CA, USA May 12-16, 1997 "INTEGRATED MANAGEMENT IN A VIRTUAL WORLD" IFIP and the IEEE Communications Society remind authors that the paper submission deadline of July 1, 1996 is fast approaching for ISINM '97, the Fifth International Symposium on Integrated Network Management. The symposium will be held from May 12-16, 1997 in San Diego, CA, USA, at the beautiful Hotel Del Coronado. The event is sponsored by the International Federation for Information Processing (IFIP) Working Group 6.6 on Network Management for Communication Networks, and by the IEEE Communications Society Technical Committee on Network Operations and Management (CNOM). For more complete information, check the web site URL given at the end of this message. Our theme, "Integrated Management in a Virtual World," challenges participants to contribute real and virtual management solutions in a world filled with virtual corporations, virtual LANs, inter-enterprise internetworking, real and virtual service management, outsourcing and electronic commerce. ISINM '97 is seeking authors who can bring the buzz words down to earth and present world-class solutions to the integrated management puzzles. Authors are invited to submit unpublished papers, as well as proposals for tutorials, panel discussions, poster demonstrations, or birds-of-a-feather sessions (informal discussion groups), in the following topic areas: - Customer Requirements - Distributed Systems Management - Integration of Network Control and Management - Intelligent Agent Technology - Interoperability and Cooperative Control - Internet Management - Management Applications - Management of Mobile Networks - Modeling and Interpretation of Management Information - Multimedia Services Management - New Enabling Management Platforms (Corba, etc.) - Open Network Control - Outsourcing Network Management - Personal Communications Services Management - Policy-Driven Management - Process Reenginering - Quality of Service Management - Service Creation, Deployment and Management - Standards Frameworks and Issues: OSI, SNMP, TMN, etc. - Trials, Case Studies and Experiences Submit cover pages for your paper in plain text format (ASCII) to or via fax to +1 212 316 9068. Complete instructions for electronic submissions are available at: Submit proposals for Tutorials and Birds-of-a-Feather Sessions to: Varoozh Harikan, varoozh@vnet.ibm.com; Fax:+1 919 301 4579 Submit proposals for Expert and Regular Panel Sessions to: Jim Herman, herman@ncri.com, Fax: +1 617 654 0654 For general information about ISINM '97, or to indicate your interest in participating, send email inquiries to isinm97@bbn.com, or consult the ISINM'97 web site at: