Delivery-Date: Fri, 07 Feb 1997 13:56:40 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id NAA07942 for X-agentx; Fri, 7 Feb 1997 13:56:40 -0800 (PST) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.7.5/8.7.3) with ESMTP id NAA07939 for ; Fri, 7 Feb 1997 13:56:39 -0800 (PST) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id NAA03203 for ; Fri, 7 Feb 1997 13:56:36 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id QAA23357 for ; Fri, 7 Feb 1997 16:54:55 -0500 (EST) X-Authentication-Warning: gauntlet.fv.com: uucp set sender to using -f Received: from phoenix.sce.carleton.ca(134.117.4.1) by gauntlet.fv.com via smap (3.2) id xma023352; Fri, 7 Feb 97 13:54:46 -0800 Received: from kosmos.sce.carleton.ca by phoenix.sce.carleton.ca id AA11907; Fri, 7 Feb 97 16:56:14 EST From: pierre@sce.carleton.ca (Pierre Ernst) Received: by kosmos.sce.carleton.ca (SMI-8.6/Sun-Client) id VAA29783; Fri, 7 Feb 1997 21:56:11 GMT Message-Id: <199702072156.VAA29783@kosmos.sce.carleton.ca> Subject: looking for a SNMP DPI agent To: agentx@fv.com Date: Fri, 7 Feb 1997 16:56:11 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I'm looking for a DPI-enabled SNMP agent to be run on Solaris. could someone help me ? thanks, ,,, (o -) --------------------------------oOOo--(_)--oOOo------------------------------ Pierre F. Ernst, Research Assistant http://www.scs.carleton.ca/~pierre Carleton University, Ottawa, Canada eMail: pierre@sce.carleton.ca   Delivery-Date: Fri, 07 Feb 1997 15:19:45 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id PAA16400 for X-agentx; Fri, 7 Feb 1997 15:19:44 -0800 (PST) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.7.5/8.7.3) with ESMTP id PAA16397 for ; Fri, 7 Feb 1997 15:19:44 -0800 (PST) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id PAA09747 for ; Fri, 7 Feb 1997 15:19:40 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id SAA28930 for ; Fri, 7 Feb 1997 18:17:56 -0500 (EST) X-Authentication-Warning: gauntlet.fv.com: uucp set sender to using -f Received: from dresden.bmc.com(198.64.253.250) by gauntlet.fv.com via smap (3.2) id xma028902; Fri, 7 Feb 97 15:17:42 -0800 Received: by dresden.bmc.com (1.40.112.4/16.2) id AA208938045; Fri, 7 Feb 1997 17:27:25 -0600 Received: from crow.bmc.com(198.147.191.100) by dresden.bmc.com via smap (3.2) id xma020869; Fri, 7 Feb 97 17:27:22 -0600 Received: from dorothy.peer.com by crow.bmc.com (AIX 3.2/UCB 5.64/4.03) id AA56763; Fri, 7 Feb 1997 17:18:57 -0600 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA298817537; Fri, 7 Feb 1997 15:18:57 -0800 From: Smitha Gudur Message-Id: <199702072318.AA298817537@dorothy.peer.com> Subject: Re: looking for a SNMP DPI agent To: pierre@sce.carleton.ca Date: Fri, 07 Feb 1997 15:18:56 PST Cc: agentx@fv.com In-Reply-To: <199702072156.VAA29783@kosmos.sce.carleton.ca>; from "Pierre Ernst" at Feb 7, 97 4:56 pm X-Mailer: Elm [revision: 111.1] > > I'm looking for a DPI-enabled SNMP agent There is developers toolkit for DPI sub-agent DPI 2.0 protocol at: software.watson.ibm.com - /pub/dpi ftp file: dip20api.tar.Z from the above site. This is freely available. > to be run on Solaris. I am not sure whether the above has been compiled on Solaris. Smitha Email: sgudur@bmc.com > could someone help me ? > thanks, > ,,, > (o -) > --------------------------------oOOo--(_)--oOOo------------------------------ > Pierre F. Ernst, Research Assistant http://www.scs.carleton.ca/~pierre > Carleton University, Ottawa, Canada eMail: pierre@sce.carleton.ca > > ---------------- > This e-mail message was sent to all subscribers to the > agentx mailing list. > > To unsubscribe from this mailing list, please send mail to: > agentx-request@fv.com > with > Subject: unsubscribe your.address@your.domain > > (NOTE: Please do not reply to this message to unsubscribe. You must send > your request to agentx-request@fv.com Thank you.)   Delivery-Date: Mon, 10 Feb 1997 12:21:48 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id MAA12412 for X-agentx; Mon, 10 Feb 1997 12:21:48 -0800 (PST) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.7.5/8.7.3) with ESMTP id MAA12409 for ; Mon, 10 Feb 1997 12:21:47 -0800 (PST) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id MAA20909 for ; Mon, 10 Feb 1997 12:21:43 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id PAA02122 for ; Mon, 10 Feb 1997 15:19:57 -0500 (EST) X-Authentication-Warning: gauntlet.fv.com: uucp set sender to using -f Received: from dns.linmor.com(206.130.52.2) by gauntlet.fv.com via smap (3.2) id xma002052; Mon, 10 Feb 97 12:19:27 -0800 Received: from lcrcssa0.mer.linmor.com (lcrcssa0.linmor.com [205.207.66.50]) by gateway.linmor.com (8.6.9/8.6.9) with SMTP id NAA23191; Mon, 10 Feb 1997 13:42:14 -0500 Received: from lmeridc9.mer.linmor.com (lmeridc9.linmor.com) by lcrcssa0.mer.linmor.com (4.1) id AA27460; Mon, 10 Feb 97 15:22:56 EST Message-Id: <32FF839F.214F@linmor.com> Date: Mon, 10 Feb 1997 15:22:55 -0500 From: Thomas Winkler Reply-To: thomas.winkler@linmor.com Organization: LINMOR Technologies, Inc. X-Mailer: Mozilla 3.0Gold (Win95; I) Mime-Version: 1.0 To: Pierre Ernst Cc: agentx@fv.com, sales@linmor.com Subject: Re: looking for a SNMP DPI agent References: <199702072156.VAA29783@kosmos.sce.carleton.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Pierre Ernst wrote: > > I'm looking for a DPI-enabled SNMP agent > to be run on Solaris. > could someone help me ? LINMOR is selling such an agent. Check our web site http://www.linmor.com and feel free to call 1-800-LINMOR-3 or (613) 727-2757. Cheers, Thomas   Delivery-Date: Mon, 24 Feb 1997 09:20:50 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id JAA14962 for X-agentx; Mon, 24 Feb 1997 09:20:50 -0800 (PST) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.7.5/8.7.3) with ESMTP id JAA14957 for ; Mon, 24 Feb 1997 09:20:49 -0800 (PST) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id JAA02571 for ; Mon, 24 Feb 1997 09:20:48 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id MAA20459 for ; Mon, 24 Feb 1997 12:18:31 -0500 (EST) X-Authentication-Warning: gauntlet.fv.com: uucp set sender to using -f Received: from relay1.smtp.psi.net(38.8.14.2) by gauntlet.fv.com via smap (3.2) id xma020402; Mon, 24 Feb 97 09:18:02 -0800 Received: from nips.acec.com by relay1.smtp.psi.net (8.8.3/SMI-5.4-PSI) id MAA17244; Mon, 24 Feb 1997 12:19:38 -0500 (EST) Received: from bnatale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA08949; Mon, 24 Feb 1997 12:21:54 -0500 Message-Id: <3.0.32.19970224121901.00948100@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 24 Feb 1997 12:19:01 -0500 To: agentx@fv.com From: Bob Natale Subject: Final AgentX issues list and next draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi everyone, The purpose of this posting is to identify the final "issues list" for v1 of AgentX and the corresponding "strawman" consensus position for each as agreed to by the core design team (Mike Daniele, Bert Wijnen, Dale Francisco, and myself). In reaching these consensus positions, we have done our best to assimilate all input from the Dec '96 IETF meeting (San Jose) and the subsequent on-list discussions with our best collective judgment wrt "technical excellence", workability, and prospects of achieving our chartered goals. We are proceeding apace with a revision of the draft (v6) for transmission to the NM AD (Deirdre Kostick) in time for her possible referral of it to the IESG for consideration as a Proposed Standard RFC prior to the forthcoming Apr '9y IETF meeting (Memphis). Please note that--while some very good post-San Jose technical discussion did occur on the list--we did not get any proposals acompanied by "proposed text", as requested as a modus operandi for that stage. So, we did our best to digest the minutes and the on-list discussion and trie to come up with the best approach reflecting that input and our own best technical judgment. As WG chair, I am posting these "strawman positions" as a poll for consensus among the WG at-large. Only objections that relate to serious flaws will be accepted at this point in time. Clearly, objections based upon a scope or set of objectives for AgentX other than those outlined in item #1 below are conceivable. It is unlikely, however, that they will be very fruitful...so I ask that you do your best to work within this bounded AgentX "problem space". Refinements based upon relatively minor adjustments to the scope or objectives may still be considered. In saying all of that, I am attempting neither to foreclose further discussion of these "issues" and current consensus positions nor to suggest that the WG won't get a reasonable (but brief) period to review and suggest revisions to the v6 draft. I am just asking that all WG members try to recognize that we have assimilated a lot of input and the reality of our schedule requires that we move forward at this time. Here's the list: 1. Scope/Objectives of AgentX (v1) - The primary purpose of AgentX is to provide an extensible agent environment so that multiple independent MIBs managed by multiple independent sub-agents can be accessed in a standard fashion by multiple independent management applications... typically via a single standard transport address (including port). This means that an AgentX master agent might represent sub-agents implementing MIB x, MIB y, and MIB z. All tables and all scalars in such MIBs are fair game. All such scalar variables are "discrete scalars", as opposed to "aggregate scalars". - A sencondary purpose of AgentX is to permit multiple independent sub-agents to manage correspondingly independent rows in tables in shared MIBs. Such "shared tables" do not include any dependencies upon or interactions with "aggregate scalars". - A by-product of these two perspectives is to allow "shared tables" which are dependent upon some "collective scalar". A "collective scalar" is a "discrete scalar" in a shared MIB which can be viewed as an "aggregate scalar" for a shared table in that MIB, but which is managed by the single sub-agent most qualified by the registration rules of precedence. The case typified by the primary purpose by itself covers a lot of useful territory. It also allows for the case where one of the sub-agents implements MIB-2...including ifNumber...but only one sub-agent does so. Not an uncommon case. The case characterized by the secondary purpose brings in a lot of additional territory...there are many MIBs with sharable tables that do not include dependencies upon or interactions with "aggergate scalars". And we expect the population of such MIBs to increase substantially henceforth. It is possible to combine those two scenarios in a meaningful way...e.g., the first sub-agent to register a scalar can be the only sub-agent to register it (all other attempts fail) and must, therefore, assume responsibility for it in some implementation-specific way. Corresponding tables *may* still be shared...however, this case will be rare in practice. This scenario is something like the "provide a vendor-specific super-sub-agent and an inter-sub-agent protocol to handle this requirment" strategy. The AgentX registration rules of precendence will support such strategies via exclusion of duplicate ("unionized") registrations and inclusion of registration priority values. And, yes, row creation in shared tables is supported (this is covered in #12, below). 2. Multi-VB PDUs: - SA *must* support multi-VB PDUs. - MA *must* send all SA-specific VBs of an SNMP SetRequest-PDU in a single SetTest-PDU "transaction". - MA *may* elect to send multiple single-VB PDUs for any GetRequest-PDUs. - SA *must* support GetBulk-PDUs. - MA *may* elect to send GetNext-PDUs in lieu of GetBulk-PDUs. 3. Unionized registration: - *Duplicate* registrations (i.e., identical OID, context, and priority) are disallowed in AgentX. - *Overlapping* registrations (e.g., shared tables) are allowed in AgentX. 4. Contexts: - Default, if none specified. - Specific context allowed. - No "All". 5. sysUpTime: - Returned as part of all AgentX *Response* packets from MA -> SA. - The default context sysUpTime will be passed in the agentx-reponse to the agentx-open, -close and -ping PDUs. - Context-specific sysUpTime, if needed, can be derived from the sysUpTime value returned from the agentx-response to the associated agentx-register, -unregister, -addAgentCaps, and -removeAgentCaps PDUs. 6. Options: - There are no optional features in the AgentX protocol specification. - MA support for non-default contexts was an option in the previous draft; it is now mandatory feature of the *protocol*. [However, note that actual *confiugration* of "contexts" (e.g., "community profiles") is an implementation-specific feature.] - MA support for non-integer index allocation was an option in the previous draft; it is now mandatory. 7. Index [Re-]Allocation: - No guaranteed reallocation upon SA restart. 8. States: - Set Test/Commit/Undo/Cleanup: - SA is guaranteed of a certain (small) set of sequence patterns here, per EOP in spec. 9. TransactionID: - Added for caching and general SA efficiency. - May be used by SA to correlate different AgentX PDUs (i.e., different PacketIDs in the headers) with a single logical AgentX transaction. - A transaction represents all interactions between an MA and the SA(s) relating to a single SNMP PDU. - Note the name of this feature (i.e., not the "SNMP Request ID"). - From #2 above: MA *must* send all SA-specific VBs of an SNMP SetRequest-PDU in a single AgentX SetTest-PDU "transaction". 10. SessionID: - Added. - Enables support for multiple "logical sessions/ connections" over a single "transport connection". - Possible future use wrt connection-oriented protocols. 11. Traps (should they be generated upon SA Open/Close or sysORTable mods): - Not included at this time (AgentX v1). - Will appear, when appropriate, in the AgentX MIB document. - Waiting on SNMP-NG "remote config MIB" standard. We understand that some SAs may have a valid need to pass trap-destinations when sending a trap to the MA. However we think it is best to wait for the SNMP-NG remote config MIB standard to see what they do, so as to not define a method that might conflict with the outcome of SNMP-NG. 12. Row creation request (in absence of unionized registration): - Goes to SA registered at the lowest (most fully qualified) level, with higher priority used to break any ties. - In an "equally shared table" (all SAs register at the "row level") no SA will get dispatched to for the row creation. That is, it will fail. - An SA must register above the row level to "catch" the row creation request. - In summary, SAs can: o Register a range of rows which have not yet been instantiated. If we then get a row creation Set within such a range, that request gets dispatched to the SA which registerd that range. In this way, multiple SAs can share the work of row creation in a table. o Register only instantiated rows and rely on a cooperating "super-subagent" to register at the table or tableEntry level. A row creation Set then gets dispatched to that "super-subagent". o Register only instantiated rows and, additionally, register at the table or tableEntry level, with multiple registration attempts at decreasing priorities until successful. In this case, if the one with the highest priority goes away (because a row gets deleted for instance), then the next one in the priority order automatically takes over. 13. Multiply indexed tables: - No change from Draft 5. - The design team invested considerable effort on this topic. At first it seemed we could add some rules to support this feature. However, as of now, it looks as if this will add more complexity to the MA than is currently justified by the additional functionality achieved. Cordially, BobN ------ ISO 9000 Registered, Hardware and Software Divsions ----- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] natale@acec.com | Gaithersburg MD 20878 | http://www.acec.com ----- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ------ ------- NetPlus (r) "FCAPS" Telemanagement Applications --------