Delivery-Date: Tue, 05 Mar 1996 08:04:25 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id IAA24521 for X-agentx-local; Tue, 5 Mar 1996 08:04:24 -0800 (PST) Received: from bootes.cus.cam.ac.uk (bootes.cus.cam.ac.uk [131.111.8.1]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id IAA24511 for ; Tue, 5 Mar 1996 08:04:23 -0800 (PST) Received: by bootes.cus.cam.ac.uk (Smail-3.1.29.0 #36) id m0ttzDl-000C0UC; Tue, 5 Mar 96 16:04 GMT Message-Id: Date: Tue, 5 Mar 96 16:04 GMT From: mjtg@cus.cam.ac.uk (M.J.T. Guy) To: agentx@fv.com subscribe mjtg@cam.ac.uk   Delivery-Date: Thu, 07 Mar 1996 18:03:25 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id SAA26387 for X-agentx-local; Thu, 7 Mar 1996 18:03:25 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id SAA26283 for ; Thu, 7 Mar 1996 18:03:03 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA02411 for ; Thu, 7 Mar 96 19:58:02 -0500 Date: Thu, 7 Mar 1996 19:57:08 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA05236; Thu, 7 Mar 1996 19:57:08 -0500 Message-Id: <9603080057.AA05236@nips.acec.com> To: kostick@qsun.ho.att.com Subject: Summary of AgentX IETF Meetings Cc: agentx@fv.com Hi Deirdre, The IETF requires that a WG chair submit a brief summary of WG meetings to the AD prior to the last day of the IETF. This report is appended below. This is not the minutes of the meetings...they were taken by Dale Francisco (AgentX editor) and will be submitted to the Secretariat, posted on the agentx list, and copied to you in the near future. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications -------- The AgentX working group held two meetings at the Los Angeles IETF. Over 50 people attended each session. Significant overall progress was made. The first session covered some administrative and background material. The major output of this session was an agreement to use the existing DPI specifications--especially RFC1592--as the document base for AgentX development. The second session was dedicated to a review of all the major known "issues" with the concept of a generic extensible SNMP agent technology. While this list was, for the most part, discussed in detail during the pre-IETF extensible agent efforts, there was a major qualitative difference in this discussion this time as evidenced by the following: - There was general agreement on specific solutions to some of the issues; - there was general agreement on general solutions (direction) to most of the others; - there was general agreement that some of the issues were no longer problems at all; - and there was general agreement that the solutions to the open issues could be framed in the context of an evolution of the DPI specifications into the AgentX standards. We also acknowledged that we cannot meet the original schedule in the WG charter and must petition the Area Director for a new schedule. This schedule can be based on production of a complete and well-discussed I-D for the AgentX Protocol Specification by the Montreal IETF (end of June). Three task groups were formed: - Bert Wijnen and Mike Daniele will lead the core protocol specification effort; - Maria Greene will lead the (optional) MIB specification effort; - Bob Natale will lead the (optional) API specification effort. Dale Francisco (AgentX editor) took minutes at both meetings and these will be published on the AgentX e-mail list asap. Bob Natale (AgentX chair) will publish a list and synopsis of the "issues and solutions" discussion and will number each topic for subsequent resolution via the e-mail list. Bert and Mike will make initial decision wrt protocol modifications in response to the course of the the recent meetings and the ensuing e-mail list discussions. Bob Natale March 7, 1996   Delivery-Date: Tue, 12 Mar 1996 04:16:40 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id EAA05658 for X-agentx-local; Tue, 12 Mar 1996 04:16:39 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id EAA05654 for ; Tue, 12 Mar 1996 04:16:38 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA02340 for ; Tue, 12 Mar 96 07:14:51 -0500 Date: Tue, 12 Mar 1996 07:14:29 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA15994; Tue, 12 Mar 1996 07:14:29 -0500 Message-Id: <9603121214.AA15994@nips.acec.com> To: dward@hns.com Subject: Re: logistics Cc: agentx@fv.com, snmpv2@tis.com > From: David Ward > Date: Tue, 12 Mar 1996 06:20:14 -0500 Hi David, > I think that Bert alludes to a good point here. SNMPv2 would probably be > best off dealing only with the issues of the protocol necessary for getting > information between SNMPv2 managers and SNMPv2 agents. This would include any > necessary PDUs and security issues. This would give this group a much more > concise focus, and would allow it to complete its efforts much more quickly. Agreed. And at one--not insignificant--level (SNMPv2c) this effort has been completed. > If this tact is taken, then proxies (including those used for security > firewalls) can be eliminated from SNMPv2 altogether. Yes. Brian and Randy, among others, submitted instructive postings on behalf of keeping them in the protocol, but I personally agree that they can be handled quite adequately outside it. > That said, there is still an obvious need for proxies - foreign (V2<->legacy), > native (V2<->V2), firewall (V2-secure <-> V2-non-secure) and maybe even > (V2<->V1 - although this is probably just another type of foreign proxy). It > seems that this work (as Bert said) comes under the confines of the agentx > working group. After all, they are working on extensible agents. All > of these proxies are just that. Well, yes...and no. The AgentX WG is chartered to come up with a protocol for use in realizing an "extensible agent" environment via communications between a "system agent" (aka "master agent") and multiple "component agents" (aka "sub-agents"). One of the basic working assumptions is that this will be a "per varbind" type protocol and not a "per packet" type protocol and for that reason--among others--it is not a proxy agent protocol. On the other hand, the WG fully recognizes that proxy is a well-established method of realizing certain forms of agent extensibility that is well represented in the current and future installed base and we are hopeful that we can convince a group of experienced proxy implementors to submit a "Proxy BCP" as an optional output of the WG. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Tue, 12 Mar 1996 04:48:42 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id EAA13016 for X-agentx-local; Tue, 12 Mar 1996 04:48:41 -0800 (PST) Received: from hnssysa.hns.com (hnssysa.hns.com [139.85.76.210]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id EAA13013 for ; Tue, 12 Mar 1996 04:48:41 -0800 (PST) Received: from pessys5.hns.com (pessys5.hns.com [139.85.124.96]) by hnssysa.hns.com (8.7.1/) with ESMTP id HAA28379; Tue, 12 Mar 1996 07:48:34 -0500 (EST) Received: (dward@localhost) by pessys5.hns.com (8.7.1/8.6.12) id HAA25488; Tue, 12 Mar 1996 07:48:33 -0500 (EST) From: "David Ward" Message-Id: <9603120748.ZM25486@pessys5.hns.com> Date: Tue, 12 Mar 1996 07:48:32 -0500 In-Reply-To: natale@acec.com (Bob Natale) "Re: logistics" (Mar 12, 7:14am) References: <9603121214.AA15994@nips.acec.com> X-Mailer: Z-Mail (3.2.1 10apr95) To: natale@acec.com (Bob Natale) Subject: Re: logistics Cc: agentx@fv.com, snmpv2@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Mar 12, 7:14am, Bob Natale wrote: > Subject: Re: logistics > > From: David Ward > > Date: Tue, 12 Mar 1996 06:20:14 -0500 > > Hi David, > > > I think that Bert alludes to a good point here. SNMPv2 would probably be > > best off dealing only with the issues of the protocol necessary for getting > > information between SNMPv2 managers and SNMPv2 agents. This would include any > > necessary PDUs and security issues. This would give this group a much more > > concise focus, and would allow it to complete its efforts much more quickly. > > Agreed. And at one--not insignificant--level (SNMPv2c) this effort > has been completed. > > > If this tact is taken, then proxies (including those used for security > > firewalls) can be eliminated from SNMPv2 altogether. > > Yes. Brian and Randy, among others, submitted instructive postings > on behalf of keeping them in the protocol, but I personally agree > that they can be handled quite adequately outside it. > > > That said, there is still an obvious need for proxies - foreign (V2<->legacy), > > native (V2<->V2), firewall (V2-secure <-> V2-non-secure) and maybe even > > (V2<->V1 - although this is probably just another type of foreign proxy). It > > seems that this work (as Bert said) comes under the confines of the agentx > > working group. After all, they are working on extensible agents. All > > of these proxies are just that. > > Well, yes...and no. The AgentX WG is chartered to come up with > a protocol for use in realizing an "extensible agent" environment > via communications between a "system agent" (aka "master agent") > and multiple "component agents" (aka "sub-agents"). One of the > basic working assumptions is that this will be a "per varbind" > type protocol and not a "per packet" type protocol and for that > reason--among others--it is not a proxy agent protocol. On the > other hand, the WG fully recognizes that proxy is a well-established > method of realizing certain forms of agent extensibility that is > well represented in the current and future installed base and > we are hopeful that we can convince a group of experienced > proxy implementors to submit a "Proxy BCP" as an optional output > of the WG. Bob: I don't agree with you here. It doesn't seem far-fetched that the master/sub agent paradigm could be extended to handle sub-agents that wish to work on a per packet basis as you allude to is necessary for proxy agents (which is true in our case anyway). It seems that this is just some kind of transaction processing where a transaction can be 1, 2, up to N (where N is the number of varbinds in the PDU) varbinds. All you would need to do is to cache the transaction's varbinds, and pass this "cache" to the sub-agent when the transaction is "ended". If this is done, you've put in all of the hooks for the proxy agents to just be complicated sub-agents. I then agree with you that some other group would then be responsible for creating certain types of proxy agents - V2<->V2, V2(secure)<->V2(insecure), V2<->V1 and so on. It is the per-varbind approach that precludes us from using any current master agent technology. This then requires us to sit on other ports which the manager needs to know, etc. which makes a messy arrangement. Even in a local sub-agent, it still might be useful (i.e. better performance) to process all varbinds at once. More complicated, but certainly not unobtainable. David > > Cordially, > > BobN > ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ > Bob Natale | ACE*COMM | 301-258-9850 [v] > Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] > natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com > ------- NetPlus (r) "FCAPS" Telemanagement Applications -------- >-- End of excerpt from Bob Natale -- David Ward dward@hns.com Hughes Network Systems, Inc. 11717 Exploration Lane Germantown, MD 20876 (301) 212-1022 (voice) (301) 212-2089 (fax) -------------------------------------------------------------------------------- Please help me - I'm stuck in a barrel and can't get out! --------------------------------------------------------------------------------   Delivery-Date: Tue, 12 Mar 1996 08:09:40 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id IAA07879 for X-agentx-local; Tue, 12 Mar 1996 08:09:40 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id IAA07865 for ; Tue, 12 Mar 1996 08:09:38 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA17139 for ; Tue, 12 Mar 96 10:42:03 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA17895; Tue, 12 Mar 1996 10:07:55 -0500 Date: Tue, 12 Mar 1996 10:09:47 EST From: Bob Natale Subject: Re: logistics To: David Ward Cc: agentx@fv.com, snmpv2@tis.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: David Ward > Date: Tue, 12 Mar 1996 07:48:32 -0500 Hi David, <...> > I don't agree with you here. It doesn't seem far-fetched that the > master/sub agent paradigm could be extended to handle sub-agents > that wish to work on a per packet basis as you allude to is necessary > for proxy agents (which is true in our case anyway). It seems that > this is just some kind of transaction processing where a transaction > can be 1, 2, up to N (where N is the number of varbinds in the PDU) > varbinds. All you would need to do is to cache the transaction's varbinds, > and pass this "cache" to the sub-agent when the transaction is "ended". This is exactly right, David. You can build a "per packet" implementation from the "per varbind" model, but not vice versa. The key distinction between the two models is the amount of fore-knowledge of the overall agent structure by the management applications. The "per packet" model (proxy) requires some degree of non-transparency, since managers must know how to limit a packet to varbinds handled by a single proxy agent. The "per varbind" model does not have this requirement... managers can use any combination of varbinds in a single request to the system agent, which then demuxes them, repackages them, and dispatches them to the component agents, unbeknownst to the management applications. "Per varbind" does not mean that a component agent *necessarily* receives only one varbind per packet from the system agent. This may end up being an implementation choice...or, for performance and integrity reasons (i.e., SetRequest processing) the AgentX protocol *might* specify that all varbinds (for a given component agent) from a single SetRequest must be passed in a single packet (by the system agent to the component agent... the management app--which would not necessarily know about the component agents at all--could still mix varbinds from any number of compoennt agents). This issue will be discussed more fully on the AgentX e-mail list in the coming weeks. It will (soon) be a numbered issue under the general "Set Processing" category. I suggest that we drop snmpv2@tis.com from any follow-up to this posting and just continue it on agentx@fv.com. (Anyone who wants to participate can join in by sending a e-mail to agentx-request@fv.com with a Subject: of "Subscribe".) > If this is done, you've put in all of the hooks for the proxy agents to > just be complicated sub-agents. I then agree with you that some other > group would then be responsible for creating certain types of proxy > agents - V2<->V2, V2(secure)<->V2(insecure), V2<->V1 and so on. Proxy solutions will still be viable outside the context of an AgentX extensible agent system, at the discretion of proxy implementors/users. > It is the per-varbind approach that precludes us from using any current > master agent technology. This then requires us to sit on other ports which > the manager needs to know, etc. which makes a messy arrangement. That's not clear to me. > Even in a local sub-agent, it still might be useful (i.e. better > performance) to process all varbinds at once. The "per varbind" model does not preclude this. Per above, it will either be an implementation choice or will be mandated by the AgentX "elements of procedure" (perhaps just for Sets). > More complicated, but certainly not unobtainable. I don't really see any complexity here. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Tue, 12 Mar 1996 14:54:26 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id OAA25601 for X-agentx-local; Tue, 12 Mar 1996 14:54:26 -0800 (PST) Received: from audrey.enst-bretagne.fr (audrey.enst-bretagne.fr [192.108.115.9]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id OAA25593 for ; Tue, 12 Mar 1996 14:54:24 -0800 (PST) From: djoneidi@rsm.rennes.enst-bretagne.fr Received: from rsm.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr) by audrey.enst-bretagne.fr (5.67b8/090294); Tue, 12 Mar 1996 23:51:35 +0100 Received: from morlaix by rsm.enst-bretagne.fr (4.1/SMI-4.1) id AA10964; Tue, 12 Mar 96 23:54:17 +0100 Message-Id: <9603122254.AA10964@rsm.enst-bretagne.fr> Received: by morlaix (1.37.109.16/16.2) id AA166231240; Tue, 12 Mar 1996 23:54:00 +0100 Date: Tue, 12 Mar 1996 23:54:00 +0100 To: agentx@fv.com help ! ________________________________________________________________________ Djoneidi Kamyar djoneidi@rennes.enst-bretagne.fr BP 78 35 512 Cesson sevigne cedex Tel : 99 87 57 37 Mastere "Reseaux et systemes d'information multimedia" _________________________________________________________________________   Delivery-Date: Thu, 14 Mar 1996 15:29:05 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id PAA20253 for X-agentx-local; Thu, 14 Mar 1996 15:28:54 -0800 (PST) Received: from olddorothy.peer.com ([192.146.153.91]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id PAA20238 for ; Thu, 14 Mar 1996 15:28:51 -0800 (PST) Received: by olddorothy.peer.com (4.1/SMI-4.1) id AA03663; Thu, 14 Mar 96 15:27:57 PST Date: Thu, 14 Mar 96 15:27:57 PST From: randy@peer.com (Randy Presuhn) Message-Id: <9603142327.AA03663@olddorothy.peer.com> To: agentx@fv.com Subject: Permission to quote Cc: bryant@sce.carleton.ca, faye@synoptics.com, johns@synoptics.com, karl@cavebear.com, pwilson@world.std.com, ralex@world.std.com, rds@world.std.com, sojourner_cliff@tandem.com, timon@timonware.com, truong_huy@tandem.com, uri@watson.ibm.com Hi - I apologize to folks receiving multiple copies of this message. Many of you were involved in agent extensibility discussions last few years. Some of you sent private message to me as part of those discussions. I'd like to forward portions to the agentx IETF working group. Of course, I'll do my best to ensure that product planning and other confidential information is not included. Before I do so, I'd like to ensure that you have no objections to this. PLEASE let me know by the end of this week if you have any objections or specific restrictions on re-distribution of these messages. -------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy@peer.com USA --------------------------------------------------------------------------   Delivery-Date: Thu, 14 Mar 1996 22:18:45 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id WAA09350 for X-agentx-local; Thu, 14 Mar 1996 22:18:45 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id WAA09345 for ; Thu, 14 Mar 1996 22:18:44 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA24435 for ; Fri, 15 Mar 96 01:11:35 -0500 Date: Fri, 15 Mar 1996 01:11:04 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA04435; Fri, 15 Mar 1996 01:11:04 -0500 Message-Id: <9603150611.AA04435@nips.acec.com> To: zhang@mdd.comm.mot.com Subject: Re: Two agents; one port 161--what to do?, a newby wonders Cc: agentx@fv.com, snmp@psi.com > Date: Thu, 14 Mar 1996 12:39:19 -0800 (PST) > From: Qing Zhang Hi Qing, > Two years ago, I came across the same problem, basically one snmpd > from SNM, and one application specific snmp agent need to co-exist > on the same machine. > > I solved the problem by developing a multiplex agent, the core of that > multiplex agent is a Split-and-Merge algorithm. It works in such a way: Did you start from one of the existing public extensible agent specs--e.g., RFC1227 (SMUX) or RFC1228/1592 (DPI 1/2)? If so, can you explain in detail...preferably on the AgentX list... what changes you made and why...and what you might do differently today. > The mux agent is listening on port 161, snmpd from SNM is listening to > port, say 2001, and my own snmp agent is listening to port 2002. How do the mux agent, these SNMP agents, and (especially) any new ones you might add, learn the correct port number(s) to use. In other words, how are connections established between the mux agent ("system agent" in AgentX parlance) and the SNMP agents ("component agents")? > Upon receiving SNMP message, the mux agent first looks into > the message, if the variables in the message is under one sub-agent's MIB, > then it directly forward the message to that sub-agent. When received > response from the sub-agent, it forward the response back to the manager. > > If the variables in the message belongs to two separate sub-agents, then > the mux agent split the message into two SNMP messages, one forwarded > to sub-agent1, and the other forwarded to sub-agent2. When received > responses from both sub-agents, it merges them into one response and > send it back to manager. > > The MIB trees managed by each sub-agent is defined in a configuration > file, so the mux agent know which variable should be forwarded to which > sub-agent. Do you allow overlapping registrations? What about instance registration in "shared tables"? > From manager's point of view, it is totally transperant, the manager could > walk through the MIB trees managed by two separate sub-agent as if they > are managed by a single SNMP agent. Yes, that is one of the advantages of the extensible agent approach over the proxy agent approach (although the latter approach has many valid applications too). > The limitation to the Split-and-Merge algorithm is very little, and could be > removed if needed. The advantage is that you can extend the SNMP agent > without having to modify it. Can you elaborate a bit more on "the limitation"...? >From the foregoing, it does not sound like you have done a lot "extending" so far...true? > The mux agent I developed has been working for two years without problem. Excellent. We'd really like to know more about your implementation on the AgentX list. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Mon, 18 Mar 1996 09:48:31 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA08291 for X-agentx-local; Mon, 18 Mar 1996 09:48:31 -0800 (PST) Received: from hcla.hcla.com (hcla.hcla.com [204.160.248.11]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id JAA08267 for ; Mon, 18 Mar 1996 09:48:28 -0800 (PST) Received: (from rvenkat@localhost) by hcla.hcla.com (8.6.12/8.6.6) id JAA04427 for agentx@fv.com; Mon, 18 Mar 1996 09:51:36 -0800 From: Venkatasubramaniam R Message-Id: <199603181751.JAA04427@hcla.hcla.com> Subject: HELP To: agentx@fv.com Date: Mon, 18 Mar 1996 09:51:33 -0800 (PST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello, I would like to know more about this mailing list. ------------------------------------------------------------------------------- VENKATASUBRAMANIAM RAMAKRISHNAN Residence : Office : Apt # P1, 260, North Mathilda Avenue, Cisco Systems, Inc. Sunnyvale, Corporate Headquarters, California - 94086. 170 W. Tasman Drive, United States of America. San Jose, CA-95134-1706. United States of America. rvenkat@hcla.com ENJOYING LIFE : HAVING THE RIGHT PEOPLE AROUND -------------------------------------------------------------------------------   Delivery-Date: Mon, 18 Mar 1996 13:57:10 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id NAA13738 for X-agentx-local; Mon, 18 Mar 1996 13:57:09 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id NAA13735 for ; Mon, 18 Mar 1996 13:57:08 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA15531 for ; Mon, 18 Mar 96 16:32:07 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA15146; Mon, 18 Mar 1996 16:30:59 -0500 Date: Mon, 18 Mar 1996 16:33:15 EST From: Bob Natale Subject: Re: HELP (agentx) To: Venkatasubramaniam R Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Venkatasubramaniam R > Date: Mon, 18 Mar 1996 09:51:33 -0800 (PST) Hi, > I would like to know more about this mailing list. The AgentX WG is working on a standard SNMP extensible agent protocol and our charter can be reviewed at: http://www.ietf.cnri.reston.va.us/html.charters/agentx-charter.html> The schedule shown there will be revised in the near future. If you have not yet subscribed to the list, you can by sending the following e-mail: To: agentx-request@fv.com Subject: subscribe Please let me know if you have any additional questions. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Tue, 19 Mar 1996 12:49:19 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id MAA11719 for X-agentx-local; Tue, 19 Mar 1996 12:49:18 -0800 (PST) Received: from mail.sharplabs.com ([204.75.175.200]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id MAA11689 for ; Tue, 19 Mar 1996 12:49:04 -0800 (PST) Received: from sla5c by mail.sharplabs.com (SMI-8.6/SMI-SVR4) id MAA19519; Tue, 19 Mar 1996 12:46:34 -0800 From: rturner@mail.sharplabs.com (Randy Turner) Received: by sla5c (SMI-8.6) id MAA02694; Tue, 19 Mar 1996 12:46:30 -0800 Date: Tue, 19 Mar 1996 12:46:30 -0800 Message-Id: <199603192046.MAA02694@sla5c> To: agentx@fv.com Subject: Re: Overlapping registrations Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: WT9UjRjRD5g4qjvZZILE0w== I was just wondering if anyone is working on a proposal for overlapping registrations, and what policy is used to select the destination for a request that can be satisfied by multiple sub-agents? Thanks Randy   Delivery-Date: Tue, 19 Mar 1996 13:10:21 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id NAA17338 for X-agentx-local; Tue, 19 Mar 1996 13:10:20 -0800 (PST) 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 NAA17316 for ; Tue, 19 Mar 1996 13:10:13 -0800 (PST) Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA21177; Tue, 19 Mar 96 13:07:30 PST Received: from santa.strata.com by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA27041; Tue, 19 Mar 96 13:07:29 PST Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA24288; Tue, 19 Mar 96 13:07:28 PST Date: Tue, 19 Mar 96 13:07:28 PST From: dfrancisco@santa.stratacom.com (Dale Francisco) Message-Id: <9603192107.AA24288@santa.strata.com> To: agentx@fv.com Subject: Draft of L.A. IETF minutes Here's a draft of minutes of the agentx meetings at the recent L.A. IETF. Please send me any corrections or suggestions. I need revisions in time to submit the final minutes to the IETF Secretariat on Friday, March 22. I actually have more complete notes than this brief summary may suggest, and I've thought about putting a more detailed record in the archives (at a later date) if there's sufficient interest. Cordially, Dale Francisco Software Engineering StrataCom 93 South La Patera Lane Santa Barbara CA 93117 voice: (805) 961-3642 fax: (805) 961-3600 Agentx WG at 35th IETF, March 4-8, 1996 --------------------------------------- At the 35th IETF in Los Angeles, March 4-8, 1996, the SNMP Agent Extensibility Working Group (agentx) had two meetings, one on Tuesday, March 5, 19:30-22:00, and the other on Wednesday, March 6, 15:30-17:30. The most active participants in the discussions (a few names were missed due to inattentiveness on the part of the note-taker) were: Uri Blumenthal, David Bridgham, Jeff Case, Mike Daniele, Maria Greene, Bob Natale, Dave Perkins, Randy Presuhn, Bob Stewart, Glenn Waters, and Bert Wijnen. About 40 people were present at the meetings. Meeting notes were taken by Dale Francisco, wg editor. Meeting 1 (Tue, March 5, 19:30-22:00) ------------------------------------- WG chair Bob Natale opened the meeting with a brief allusion to the long history of discussions on SNMP agent extensibility, a summary of the formation of the agentx wg, and a review of its charter. He called for presentations from anyone with a prepared topic. He introduced meeting participants who have been active in the discussion and implementation of extensible agents. The chair expressed the hope that the agentx wg could benefit from the long experience of extensible agent products such as SMUX, DPI, eSNMP, EMANATE, Envoy, and others. He stressed that the goal of agentx was come up with a simple, widely applicable protocol that would solve interoperability problems and that vendors of existing commercial extensible agents would see as a complement, not a threat, to their products. He asked that we focus on these deployed solutions ("the solution space") as a starting point, and try to avoid endless, circular discussions of the many "interesting" problems associated with agentx. He mentioned that there was general consensus that the original wg schedule, which called for a final internet draft by May, 1996, was unrealistically tight, and that one of the goals of this meeting would be to agree on a new, more rational schedule that could be presented to the Area Director for consideration. There was a discussion of why DPI and some other extensible agent products had chosen not to use SNMP for communication between master and subagents, the main argument being that writing subagents should be as simple as possible. Some questioned whether the alternatives to SNMP (such as DPI bit-specified messages) were really simpler. There was also a question as to whether using a non-SNMP encoding meant that the agentx protocol would be limited, for security reasons, to communication among agents on the same box. It was suggested that this was really a transport mapping issue, and that security should not be considered explicitly in the first version of agentx. Maria Greene gave a presentation on "Coordinating Index Value Assignments". The problem: In order to allow different component agents to be responsible for different rows in the same table, a method must be agreed upon for handing out indices to the rows of that shared table. Maria's solution involves three MIB objects implemented in a single component agent. There would be three such objects for each shared table. The objects are: (1) nextIndex, the value of the next available index; (2) Lock, a TestAndIncr or `spin lock' object used to coordinate the assignment of indices; and (3) numIndices, the number of indices that the component agent wants. A component agent that wants one or more indices temporarily takes on a manager role to manipulate these objects, or uses some other implementation-dependent method. Jeff Case noted that EMANATE does something similar, but instead of having a separate set of objects for each shared table, it has a single "reservation table" in a single "reservation subagent". In addition to the index coordination provided by Maria's solution, Jeff's solution also encompasses pre-configured, "dedicated" indices for special purposes, and the ability of the reservation subagent to go out and find which indices are already in use when it comes up. Jeff said that he would consider publishing his "reservation MIB". This led to a brief discussion of communication between subagents, subagent-to-subagent Get requests, and the necessity (or not) of multithreading to support this. There was also a discussion of whether reservation functionality ought to be in the master agent, or whether it should be left to the implementor to decide on placing it either in the master agent or a component agent. A question about the agentx protocol formulation led to Bob Natale's proposal that agentx use DPI version 2.0 as a base document. He also suggested that three small working groups take on the tasks of (1) specifying requirements, (2) initial protocol specification, and (3) agentx MIB. He asked that participants be prepared by the next day's meeting to commit to a realistic (TBD) schedule for fulfilling the agentx charter. Meeting 2 (Wednesday, March 6, 15:30-17:30) ------------------------------------------- The chair opened the meeting with the announcement that Bert Wijnen and Mike Daniele had volunteered to work on the initial protocol specification, and Maria Greene would be working on an agentx MIB. He then began a discussion of a list of issues which he hoped could be refined into a firm set of requirements for the agentx protocol. The following issues were briefly discussed: GetNext across subagents. A requirement. Tables shared across subagents. A requirement. Subagent MIB. Probably a requirement-Maria Greene to investigate. Multiphase Set for "as if simultaneous" Sets. Disposition unclear. Randy Presuhn volunteered to post a summary of an off-list discussion of multiphase Set. Problems with sysUpTime across subagents, possibly on different physical systems; detecting counter discontinuities; and timestamps for event logs. Disposition unclear. How much (if any) of the header information in the SNMP PDU received by the master agent should be visible to subagents. Disagreement on this. Access control. Should be concentrated in the master agent. Effect of subagents dying and restarting on sysUpTime, subagent-specific timestamps, and registration. Disposition unclear. Cross-subagent communication. Disagreement over whether this is a requirement. Some felt that it was a prerequisite for index reservation. There was disagreement over whether it necessitated support for multithreading in subagents. SNMPv2 compatibility. A requirement. Per varbind vs. per packet. Previously decided in favor of per varbind. Use of ASN.1 and BER in agentx protocol specification. Disagreement on this. Some argued that ASN.1 should be used as description language, but not mandate use of BER for actual encoding. What is subject to registration? Subtrees, ranges, partial indexes, objects, instances? Are overlapping registrations required? Disposition unclear. Dispatch policy, priorities. Disposition unclear. Reservation protocol. Are some pre-reserved indices a requirement? With a half hour remaining, the chair asked that the discussion of requirements be continued on the mailing list, and that Bert Wijnen use the remaining time to give an overview of DPI and registration issues. Bert briefly discussed DPI subagent registration. He pointed out that DPI 2.0 did not support overlapping registration, instance registration, multiple naming scopes, multiple varbinds per subagent packet, shared tables, registration priorities, and other things that had been discussed as possible agentx requirements. The chair asked for suggestions on a reasonable schedule for completing agentx work. Bert Wijnen volunteered to write a first draft of an agentx protocol specification, but noted that, as a result of all the new requirements he had just learned of, it might take longer than he had originally planned. He had originally hoped to have something by June 1996. The chair asked that we drive towards rough draft documents by June, and that discussion and resolution of requirements be continued on the mailing list. [LA IETF minutes, revision 1.0: Tue Mar 19 00:11:50 PST 1996]   Delivery-Date: Tue, 19 Mar 1996 13:12:44 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id NAA18015 for X-agentx-local; Tue, 19 Mar 1996 13:12:44 -0800 (PST) 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 NAA18000 for ; Tue, 19 Mar 1996 13:12:41 -0800 (PST) Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA21261; Tue, 19 Mar 96 13:12:34 PST Received: from santa.strata.com by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA27319; Tue, 19 Mar 96 13:12:33 PST Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA24408; Tue, 19 Mar 96 13:12:32 PST Date: Tue, 19 Mar 96 13:12:32 PST From: dfrancisco@santa.stratacom.com (Dale Francisco) Message-Id: <9603192112.AA24408@santa.strata.com> To: agentx@fv.com Subject: A little question of terminology I have a little question regarding agentx terminology. I'd like to hear what people think about the terms "master agent"/"subagent" vs. "system agent"/"component agent" This may seem like a minor nit, but I'd like to pick one set of terms and stick to it. I have my opinions on this, but I'm willing to yield to the force of reason and the judgement of agentx veterans (which I definitely am not). I would argue that, for simplicity and clarity, we use the terms "master agent" and "subagent". Here's why: 1) Most of the existing papers use such terms or something close: rfc1227 SNMP agent, SMUX peer (OK, not very close!) rfc1592 SNMP agent, sub-agent Daniele and Keeney. eSNMP Version 1.0 master-agent, sub-agent van der Linde. Evaluation and New Specification of the Extensible Agent Protocol. Harmen uses "master agent" and "sub-agent" when speaking generically, and the 'native' terminology when discussing a single product (e.g., OAA's "core agent" and "MIB server"). 2) The two commercial extensible agent products I'm familiar with (Envoy and EMANATE) use "master agent" and "subagent". 3) "System agent" has two problematic connotations: First, our one mandatory deliverable is a "protocol which supports intra-agent communication within a device or _a local area network_". If the agents were all on one device, "system agent" might be a good name, but if co-operating agents are on more than one device, "system agent" becomes a little confusing. Second, and similarly, there's a bit of a prejudicial connotation in the very word "system" that may lead people to think that the system group or other system- or device-level instrumentation is _necessarily_ part of the "system agent". The term "master agent" avoids these connotations. It also expresses the idea that there is a single agent controlling the multiplexing of requests to subagents, and that there is a single point of contact for managers. 4) It seemed to me that most people at the L.A. IETF used the terms "master agent"/"subagent". Bob Natale told me in an off-list post that he preferred the terms "system agent"/"component agent" because (1) The break with previous terminology would further reinforce the difference between agentx and previous efforts, and help us think about it in new ways, and (2) That it was consistent with DMTF terminology. Bob I'm sure can state these and perhaps other arguments more forcefully. Personally, I can see the merit in argument (1), though I still feel the simplicity of "master agent"/"subagent" outweighs it. As to argument (2), I admit to being DMTF-ignorant, and not capable of judging how similar our efforts may be to work in that area. I'll try to find out more about it. Eagerly awaiting your opinions on this burning issue, Dale Francisco Software Engineering StrataCom 93 South La Patera Lane Santa Barbara CA 93117 voice: (805) 961-3642 fax: (805) 961-3600   Delivery-Date: Tue, 19 Mar 1996 13:57:19 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id NAA29736 for X-agentx-local; Tue, 19 Mar 1996 13:57:18 -0800 (PST) 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 NAA29613 for ; Tue, 19 Mar 1996 13:56:47 -0800 (PST) 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 NAA14412; Tue, 19 Mar 1996 13:56:21 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 19 Mar 1996 16:56:24 -0500 To: dfrancisco@santa.stratacom.com (Dale Francisco), agentx@fv.com From: bstewart@cisco.com (Bob Stewart) Subject: Re: A little question of terminology Circa 1:12 PM 3/19/96, Dale Francisco bitwhacked: > The term "master agent" avoids these connotations. It also > expresses the idea that there is a single agent controlling > the multiplexing of requests to subagents, and that there > is a single point of contact for managers. > >4) It seemed to me that most people at the L.A. IETF used the > terms "master agent"/"subagent". How about a compromise: master agent and component agent? I'm more than half serious. It's accurate and carries the right implications. It's different enough to underscore a difference. Bob   Delivery-Date: Tue, 19 Mar 1996 14:27:37 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id OAA08134 for X-agentx-local; Tue, 19 Mar 1996 14:27:36 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id OAA08125 for ; Tue, 19 Mar 1996 14:27:35 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA14638 for ; Tue, 19 Mar 96 16:59:40 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA04820; Tue, 19 Mar 1996 16:58:32 -0500 Date: Tue, 19 Mar 1996 17:00:56 EST From: Bob Natale Subject: Re: Overlapping registrations To: Randy Turner Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Randy Turner > Date: Tue, 19 Mar 1996 12:46:30 -0800 Hi Randy, [Speaking as wg chair...] > I was just wondering if anyone is working on a proposal for overlapping > registrations, Yes, we (as a working group) are working on a comprehensive agent extensibility proposal, that will include overlapping registsrations. This will (imminently...now that I see the draft minutes have been posted) be one of a numbered list of "issues" to be resolved. (Actually, overlapping registrations might be a subset of a larger registration issue.) You are invited to post your comments on the matter to the list at any time (but preferably after I post the numbered list, so that you can refer to the number in your subject header!). At the LA IETF AgentX meetings, we agreed to frame our proposals--where possible--as modifications to the existing DPI-2 specification (RFC 1592). Mike Daniele and Bert Wijnen will take first cuts (by default) at proposing the formal mods; and Dale Francisco will edit those into the evolving AgentX specification(s). All of that is modulo on-going open input from on the list. > and what policy is used to select the destination for a > request that can be satisfied by multiple sub-agents? The actual policy to be used--and that is not to say there might not be acceptable implementation alternatives in the end--will be part of the above wg process. One additional thing we did identify substantial consensus on in LA is that--to the extent possible--the protocol and policy should be such that the system agent is able to know deterministically or algorithmically which component agents to contact to satisfy a given request from a manager entity without having to poll the compoenent agents to discover which one(s) can respond. Stay tuned to this channel...things should buzz up here pretty soon! Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Tue, 19 Mar 1996 14:45:59 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id OAA12868 for X-agentx-local; Tue, 19 Mar 1996 14:45:58 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id OAA12862 for ; Tue, 19 Mar 1996 14:45:57 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA15875 for ; Tue, 19 Mar 96 17:20:19 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA05125; Tue, 19 Mar 1996 17:19:11 -0500 Date: Tue, 19 Mar 1996 17:21:35 EST From: Bob Natale Subject: Nice job on the minutes! To: dfrancisco@santa.stratacom.com Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi Dale, [Speaking as wg chair...] Nice job on the minutes of the LA meetings as they made it to the list. I don't think many mods will be needed at all before getting them to the IETF Secretariat on Friday...the only area I noted where there might have been some misunderstanding was in the recap of Bert's comments on "limitations" in DPI v2 vs AgentX reguirements... some of them actually refer to limitations in his *implementation* of DPI v2 rather than the protocol itself. All in all, an OUTSTANDING job! Many, many thanks! Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Tue, 19 Mar 1996 15:05:29 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id PAA17419 for X-agentx-local; Tue, 19 Mar 1996 15:05:28 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id PAA17411 for ; Tue, 19 Mar 1996 15:05:27 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA16833 for ; Tue, 19 Mar 96 17:39:18 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA05427; Tue, 19 Mar 1996 17:38:10 -0500 Date: Tue, 19 Mar 1996 17:40:33 EST From: Bob Natale Subject: 01: Terminology To: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi everyone, [In the interest of minimizing formality, I will forego the "Speaking as wg chair...] henceforth, since (hopefully) that is mostly how I will be speaking. I will try to remember to point out that I am "Speaking as a technical contributor..." whenever I do that, however.] This will serve to inaugurate the numbered list of issues for resolution by the wg via discussion on this list. More will follow quickly, but this one issue of "terminology" has gotten started on its own. Anyway, that's fine...I had some off-list requests to include it as an "issue", so here it is. Please include at least the "01:" in your Subject: header when following up on this thread. Issue 01: Terminology... The wg chair has recommended for some time that the traditional terms "master agent" and "sub-agent" be replaced in the AgentX context with "system agent" and "component agent", respectively. (Furthermore, the wg chair has tried to "institutionalize" this usage via the "Repetition is the key to learning..." method for almost two years. :-) Initial arguments for and against this recommendation have already been posted to the list by Dale Francisco and wg members are urged to read that message for background info. As a side note, starting with this relatively non-technical issue is not a bad thing...first, the lack of clarity in the use of terms is often a major barrier to an otherwise possible convergence of views and, secondly, it points to the need for us to remember to include a "Glossary" or "Definitions" section in our eventual AgentX specification. All yours! Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Tue, 19 Mar 1996 15:34:39 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id PAA25201 for X-agentx-local; Tue, 19 Mar 1996 15:34:39 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id PAA25193 for ; Tue, 19 Mar 1996 15:34:38 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA17847 for ; Tue, 19 Mar 96 17:58:40 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA05690; Tue, 19 Mar 1996 17:57:31 -0500 Date: Tue, 19 Mar 1996 17:59:55 EST From: Bob Natale Subject: 01: Re: A little question of terminology To: Bob Stewart Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Bob Stewart > Date: Tue, 19 Mar 1996 16:56:24 -0500 Hi BobS, > How about a compromise: master agent and component agent? > > I'm more than half serious. It's accurate and carries the right > implications. It's different enough to underscore a difference. I could live with that. I agree that it has the qualities you attribute to it. I am mildly opposed to the term "master agent" on a completely non-tech basis and I feel that Dale's definition of "system" (in his objection to that part of it) is a bit too constrained. But, even though I am strongly in favor of the system/component pair, I don't think this issue is critical to the success of the AgentX protocol and I think your proposed compromise is a good one. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Tue, 19 Mar 1996 16:03:04 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id QAA02128 for X-agentx-local; Tue, 19 Mar 1996 16:03:04 -0800 (PST) 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 QAA02044 for ; Tue, 19 Mar 1996 16:02:58 -0800 (PST) Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA23325; Tue, 19 Mar 96 16:02:51 PST Received: from santa.strata.com by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA05139; Tue, 19 Mar 96 16:02:50 PST Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA25846; Tue, 19 Mar 96 16:02:49 PST Date: Tue, 19 Mar 96 16:02:49 PST From: dfrancisco@santa.stratacom.com (Dale Francisco) Message-Id: <9603200002.AA25846@santa.strata.com> To: agentx@fv.com, bstewart@cisco.com Subject: Re: A little question of terminology > To: dfrancisco@santa.strata.com (Dale Francisco), agentx@fv.com > From: bstewart@cisco.com (Bob Stewart) > Subject: Re: A little question of terminology > > How about a compromise: master agent and component agent? > > I'm more than half serious. It's accurate and carries the right > implications. It's different enough to underscore a difference. > > Bob > That sounds pretty good. It's really the term "system agent" that doesn't seem quite right to me; my only objection to "component agent" is that it's harder to say than "subagent", and that is a minor complaint indeed. So, if most other people like it, I'd go along with "master agent"/"component agent" as the official agentx terminology. By the way Bob, speaking of the art of compromise, have you considered going into politics? Dole is reportedly looking for a running mate who could bring in the nerd vote--and who better than another Bob? Thanks, Dale Francisco Software Engineering StrataCom 93 South La Patera Lane Santa Barbara CA 93117 voice: (805) 961-3642 fax: (805) 961-3600   Delivery-Date: Tue, 19 Mar 1996 16:11:29 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id QAA04414 for X-agentx-local; Tue, 19 Mar 1996 16:11:29 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id QAA04405 for ; Tue, 19 Mar 1996 16:11:28 -0800 (PST) Message-Id: <199603200012.AA226270725@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA226270725; Tue, 19 Mar 1996 16:12:05 -0800 Date: Tue, 19 Mar 1996 16:12:05 -0800 From: Randy Presuhn To: agentx@fv.com Subject: Re: Overlapping registrations Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > From: rturner@mail.sharplabs.com (Randy Turner) > Date: Tue, 19 Mar 1996 12:46:30 -0800 > Message-Id: <199603192046.MAA02694@sla5c> > To: agentx@fv.com > Subject: Re: Overlapping registrations > > > I was just wondering if anyone is working on a proposal for overlapping > registrations, and what policy is used to select the destination for a > request that can be satisfied by multiple sub-agents? ... Most the proposals use a policy based on some combination of subtree length, order of registration, and explicit priority. If shorter subtrees get priority over longer ones, it becomes difficult to handle creation of rows in tables split across subagents and to handle extensions to groups implemented in different subagents. In many environments, it usually makes sense for the most recent registration to get the better priority if there is no other basis for deciding between them. Explicit priority is needed in fault-tolerant environments and in systems in which the order in which components are activated is not deterministic. In terms of processing, handling of registration ordering and explicit priority can usually be collapsed within an implementation, so there's really not much extra work at all. One approach: at registration time: if (specific priority requested) { if ((new subtree IN registered subtrees) AND (duplicate priority)) { collision - reject registration } else use requested priority } else { select priority better than that of elements of UNION(all previous registrations of unspecified priority, all previous registrations of that subtree) } at dispatch time: Use longest matching registration as starting point for operation evaluation (this gets fairly elaborate with get-next and bulk) When you consider the interactions with access control, there are cases where it may be necessary to make multiple agent-subagent queries to come up with a suitable response. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Tue, 19 Mar 1996 16:36:29 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id QAA11576 for X-agentx-local; Tue, 19 Mar 1996 16:36:28 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id QAA11555 for ; Tue, 19 Mar 1996 16:36:23 -0800 (PST) Message-Id: <199603200037.AA229702221@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA229702221; Tue, 19 Mar 1996 16:37:01 -0800 Date: Tue, 19 Mar 1996 16:37:01 -0800 From: Randy Presuhn To: agentx@fv.com Subject: Re: A little question of terminology Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - I prefer master agent (or just agent) and subagent. More below if you care. :-) > Date: Tue, 19 Mar 96 13:12:32 PST > From: dfrancisco@santa.stratacom.com (Dale Francisco) > Message-Id: <9603192112.AA24408@santa.strata.com> > To: agentx@fv.com > Subject: A little question of terminology ... > I would argue that, for simplicity and clarity, we use > the terms "master agent" and "subagent". Here's why: ... Many strong arguments omitted... ... > Bob Natale told me in an off-list post that he preferred the > terms "system agent"/"component agent" because (1) The break > with previous terminology would further reinforce the difference > between agentx and previous efforts, and help us think about it > in new ways, Honestly, I don't see enough technical differences to warrant a change. The models certainly aren't changing. The biggest change I see is in the wider understanding of the issues of technology options. > and (2) That it was consistent with DMTF terminology. ... Although there is some overlap, I feel the use of the DMTF terminology would lead to confusion with DMTF interfaces. We have enough difficulty with maintaining the API/service/protocol destinction. The MI and CI interfaces do not NECESSARILY correspond to the management protocol and subagent interfaces of a master agent. Consider the case where a subagent makes use of the MI interface; employing the DMTF terminology would make describing the configuration unnecessarily convoluted. A second factor is that the provider of the DMTF service layer in a given system will most likely be different from the source of the SNMP infrastructure. There may be a "MIF-MIB" in there somewhere, but it might be implemented by either or even by a third party. The fact is that we have two technologies that provide overlapping, not identical, capabilities. The folks in DMTF land I've talked to seem to be interested in increasing the synergy between these technologies. We should appreciate this. By appropriating the terminology inappropriately, (and thus implying functional equivalence) I fear we'd open a pointless DMTF vs SNMP debate, a debate I neither need nor want. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Tue, 19 Mar 1996 16:53:08 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id QAA15717 for X-agentx-local; Tue, 19 Mar 1996 16:53:07 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id QAA15707 for ; Tue, 19 Mar 1996 16:53:05 -0800 (PST) Message-Id: <199603200053.AA233333223@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA233333223; Tue, 19 Mar 1996 16:53:43 -0800 Date: Tue, 19 Mar 1996 16:53:43 -0800 From: Randy Presuhn To: agentx@fv.com Subject: Re: 01: Terminology Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > Date: Tue, 19 Mar 1996 17:40:33 EST > From: Bob Natale > Subject: 01: Terminology > To: agentx@fv.com > Message-Id: > > Issue 01: Terminology... > > The wg chair has recommended for some time that the traditional > terms "master agent" and "sub-agent" be replaced in the AgentX > context with "system agent" and "component agent", respectively. I think we should stick with the terms "master agent" and "sub-agent". Dale made most of the necessary points. In a separate posting, I outlined why I believe that appropriating the DMTF terminology would only serve to confuse rather than to enlighten. > (Furthermore, the wg chair has tried to "institutionalize" this > usage via the "Repetition is the key to learning..." method for > almost two years. :-) ... Despite the best efforts of the wg chair, I do not get the impression that the new terminology has been widely adopted. The few cases where I have seen it have been in very implementation- specific contexts where the subagent interface was realized using DLLs, with instrumentation executing in the context of the system agent process. Such an approach more closely resembles the DMTF CI interface than our current discussions, which much greater freedom to the developer of the instrumentation. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Tue, 19 Mar 1996 17:22:32 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id RAA22858 for X-agentx-local; Tue, 19 Mar 1996 17:22:32 -0800 (PST) Received: from hansons.demon.co.uk (hansons.demon.co.uk [158.152.246.152]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id RAA22050 for ; Tue, 19 Mar 1996 17:19:59 -0800 (PST) Date: Wed, 20 Mar 1996 00:29:20 GMT From: Iain@hansons.demon.co.uk (Iain K. Hanson) Reply-To: Iain@hansons.demon.co.uk Message-Id: <1467@hansons.demon.co.uk> To: bstewart@cisco.com, dfrancisco@santa.stratacom.com, agentx@fv.com Cc: iain Subject: Re: A little question of terminology X-Mailer: PCElm 1.10 Lines: 26 In message bstewart@cisco.com (Bob Stewart) writes: > Circa 1:12 PM 3/19/96, Dale Francisco bitwhacked: > > The term "master agent" avoids these connotations. It also > > expresses the idea that there is a single agent controlling > > the multiplexing of requests to subagents, and that there > > is a single point of contact for managers. > > > >4) It seemed to me that most people at the L.A. IETF used the > > terms "master agent"/"subagent". > > How about a compromise: master agent and component agent? > > I'm more than half serious. It's accurate and carries the right > implications. It's different enough to underscore a difference. Sounds good to me. System agent always sounded a little overloaded so this looks like a good compromise. It may be useful to glossary the other alternatives, but thats just crossing the i's and dotting the t's. /ikh -- Iain K. Hanson   Delivery-Date: Tue, 19 Mar 1996 19:51:50 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id TAA29734 for X-agentx-local; Tue, 19 Mar 1996 19:51:49 -0800 (PST) Received: from lightning.synoptics.com (lightning.synoptics.com [134.177.3.18]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id TAA29729 for ; Tue, 19 Mar 1996 19:51:48 -0800 (PST) Received: from pobox ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA07932; Tue, 19 Mar 96 19:49:58 PST Received: from turing.engwest by pobox (4.1/SMI-4.1) id AA29489; Tue, 19 Mar 96 19:50:13 PST Received: from coachese.engwest by turing.engwest (SMI-8.6/SMI-SVR4) id TAA24492; Tue, 19 Mar 1996 19:46:52 -0800 Date: Tue, 19 Mar 1996 19:46:52 -0800 From: johns2@BayNetworks.COM (John Seligson) Message-Id: <199603200346.TAA24492@turing.engwest> To: agentx@fv.com Subject: Re: A little question of terminology I vote for master agent and subagent. The history is ok with me. Seems like we have some harder problems to deal with ... John   Delivery-Date: Tue, 19 Mar 1996 20:21:53 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id UAA07095 for X-agentx-local; Tue, 19 Mar 1996 20:21:52 -0800 (PST) Received: from DRAGON.COM (dragon.com [155.229.20.1]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id UAA07089 for ; Tue, 19 Mar 1996 20:21:50 -0800 (PST) From: cheryl@empiretech.com Received: by dragon.com (MX V4.1 VAX) with UUCP; Tue, 19 Mar 1996 23:20:58 EST Received: (from cheryl@localhost) by emptech.empiretech.com (8.6.12/8.6.12) id XAA23325; Tue, 19 Mar 1996 23:04:58 -0500 Message-ID: <199603200404.XAA23325@emptech.empiretech.com> Subject: Re: A little question of terminology To: Date: Tue, 19 Mar 1996 23:04:58 -0500 (EST) CC: dfrancisco@santa.stratacom.com, agentx@fv.com In-Reply-To: from "Bob Stewart" at Mar 19, 96 04:56:24 pm X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > >How about a compromise: master agent and component agent? > >I'm more than half serious. It's accurate and carries the right >implications. It's different enough to underscore a difference. > > Bob Hey! I like it! (being that my company's main focus is on SNMP agents for managing host _systems_, I don't like the opportunity for confusion that the term 'systems agent' presents.) - Cheryl +--------------------------------------------------------------------+ + Check us out! http://www.empiretech.com/empiretech + +--------------------------------------------------------------------+ + Cheryl Krupczak Empire Technologies, Inc. + + cheryl@empiretech.com 541 Tenth Street NW + + PH : (770)384-0184 Suite 169 + + FAX: (770)384-0183 Atlanta, GA 30318 + +--------------------------------------------------------------------+   Delivery-Date: Wed, 20 Mar 1996 02:54:28 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id CAA01519 for X-agentx-local; Wed, 20 Mar 1996 02:54:27 -0800 (PST) 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 CAA01510 for ; Wed, 20 Mar 1996 02:54:26 -0800 (PST) Message-Id: <199603201054.CAA01510@zloty.fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 4085; Wed, 20 Mar 96 05:54:00 EST Date: Wed, 20 Mar 96 11:53:41 CET From: "Bert Wijnen" To: agentx@fv.com Subject: comments on minutes version 01. Please fix this in the minutes (of still possible): > Bert briefly discussed DPI subagent registration. He pointed > out that DPI 2.0 did not support overlapping registration, > instance registration, multiple naming scopes, multiple > varbinds per subagent packet, shared tables, registration > priorities, and other things that had been discussed as > possible agentx requirements. > I may not have been clear enough. But from the bove, DPI 2.0 does support multiple varBinds per subagent-packet, but it does NOT mandate it. The result is that a sub-agent cannot assume that all varBinds belonging to the same SNMP packet always come in one and the same subagent-packet. DPI 2.0 also supports registration priorities, but I did question if this was a required feature. Also... my not supporting overlapping registrations and (to some extend) instance registrations, is an implementation restriction on my part and not a limitation of the DPI 2.0 spec. I did state that the shared tables and instance registrations are problematic in the current DPI 2.0 spec. Thanks, Bert.   Delivery-Date: Wed, 20 Mar 1996 03:15:40 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id DAA05418 for X-agentx-local; Wed, 20 Mar 1996 03:15:40 -0800 (PST) Received: from tom.perform.fr (tom.perform.fr [194.3.57.1]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id DAA05393 for ; Wed, 20 Mar 1996 03:15:30 -0800 (PST) Received: from pcjhr.perform.fr by tom.perform.fr with SMTP (1.38.193.4/16.2) id AA02817; Wed, 20 Mar 1996 12:18:45 +0100 Message-Id: <314FE5B7.2694@perform.fr> Date: Wed, 20 Mar 1996 12:02:15 +0100 From: Jean-Hugues Robert Organization: perform.fr X-Mailer: Mozilla 2.0GoldB1 (WinNT; I) Mime-Version: 1.0 To: agentx@fv.com Subject: Re: A little question of terminology Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "master agent" and "component agent" don't mix perfectly. "master" qualifies the agent, whereas "component" is a noun. Other combinations : "master agent" vs "sub-agent" "system agent" vs "component agent" "core agent" vs "added agent" What about : "extensible agent" and "agent extension" ? That would degrade into : "the agent and its extensions" in spoken language. Vendors would sell "extended snmp agents" with "extensions" to manage this and that. If the "sub-agent" isn't expected to behave as a regular SNMP agent, if it isn't expected to be directly addressed by a manager, then calling it an "agent" may be misleading. In french sub-xxx translates into "sous-xxx" and "sous"'s meaning is similar to "less valuable"... "master agent" leads to "slave agent", is this politically correct ? :-) The protocol between the extensible agent and the agent extension could be called "esnmp", "e" for extension : "Our agent extension supports the esnmp protocol, you won't have any trouble to use it with your extensible agent". Jean-Hugues Robert http://www.perform.fr/   Delivery-Date: Wed, 20 Mar 1996 05:41:01 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id FAA04243 for X-agentx-local; Wed, 20 Mar 1996 05:41:00 -0800 (PST) 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 FAA04226 for ; Wed, 20 Mar 1996 05:41:00 -0800 (PST) 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 FAA07464 for ; Wed, 20 Mar 1996 05:40:47 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Mar 1996 08:40:49 -0500 To: agentx@fv.com From: bstewart@cisco.com (Bob Stewart) Subject: Re: A little question of terminology Circa 4:02 PM 3/19/96, Dale Francisco bitwhacked: >By the way Bob, speaking of the art of compromise, >have you considered going into politics? Dole is reportedly >looking for a running mate who could bring in the nerd >vote--and who better than another Bob? I find Dole a bit too liberal for my tastes, as well as the other Republican candidates for the most part. A bunch of statists. I'll accept the nomination for President if Dole steps down and if I don't have to do any campaigning and Clinton resigns and I get to decide things instead of waiting for Congress to vote on them. I'll listen to Congress's opinion if they can get it to me in time and don't annoy me too much. Other than that, I'm not interested. Bob   Delivery-Date: Wed, 20 Mar 1996 05:41:10 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id FAA04317 for X-agentx-local; Wed, 20 Mar 1996 05:41:10 -0800 (PST) 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 FAA04288 for ; Wed, 20 Mar 1996 05:41:02 -0800 (PST) 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 FAA07473 for ; Wed, 20 Mar 1996 05:40:53 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Mar 1996 08:40:55 -0500 To: agentx@fv.com From: bstewart@cisco.com (Bob Stewart) Subject: Re: comments on minutes version 01. Circa 6:53 AM 3/20/96, Bert Wijnen bitwhacked: >The result is that a sub-agent cannot assume that >all varBinds belonging to the same SNMP packet always come in >one and the same subagent-packet. Hmmm. This particular policy needs to be made real clear. Some MIBs specify that certain objects must come in the same Set request. The multistage process could satisfy that need as long as the sub-agent keeps the right state along the way and doesn't get order sensitive. It seems like it would be easiest on the sub-agent if we required that all varbinds from the same Set came in the same request. Enforce the restriction once, in the master, rather than having to handle a possible mess in every sub-agent. Bob   Delivery-Date: Wed, 20 Mar 1996 06:23:26 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id GAA13862 for X-agentx-local; Wed, 20 Mar 1996 06:23:26 -0800 (PST) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id GAA13856 for ; Wed, 20 Mar 1996 06:23:25 -0800 (PST) Received: from flume.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA17189; Wed, 20 Mar 1996 09:16:39 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA07691; Wed, 20 Mar 1996 09:16:37 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA02352; Wed, 20 Mar 1996 09:17:06 -0500 Message-Id: <9603201417.AA02352@bernie.zk3.dec.com> To: bstewart@cisco.com (Bob Stewart) Cc: agentx@fv.com Subject: Re: comments on minutes version 01. In-Reply-To: Your message of "Wed, 20 Mar 96 08:40:55 EST." Date: Wed, 20 Mar 96 09:17:05 -0500 From: Mike Daniele X-Mts: smtp Hi, >Circa 6:53 AM 3/20/96, Bert Wijnen bitwhacked: >>The result is that a sub-agent cannot assume that >>all varBinds belonging to the same SNMP packet always come in >>one and the same subagent-packet. >Hmmm. This particular policy needs to be made real clear. Some MIBs >specify that certain objects must come in the same Set request. The >multistage process could satisfy that need as long as the sub-agent keeps >the right state along the way and doesn't get order sensitive. It seems >like it would be easiest on the sub-agent if we required that all varbinds >from the same Set came in the same request. Enforce the restriction once, >in the master, rather than having to handle a possible mess in every >sub-agent. > Bob Bob, I agree, and in fact would extend the requirement to all requests, not just sets. But I'm waiting to discuss this (and other) points until there is an enumerated list of topics. For instance, the minutes also mention DPI and instance registration. I would argue that the DPI spec as written cannot support instance level registration (or more specifically the GetNext Pdu will miss them). But since we're talking about meeting minutes, and not technical issues, I haven't brought it up :-) Regards, Mike   Delivery-Date: Wed, 20 Mar 1996 06:45:26 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id GAA19187 for X-agentx-local; Wed, 20 Mar 1996 06:45:25 -0800 (PST) Received: from louie.udel.edu (louie.udel.edu [128.175.1.3]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id GAA19179 for ; Wed, 20 Mar 1996 06:45:24 -0800 (PST) Received: from ra.cis.udel.edu by louie.udel.edu id ab20771; 20 Mar 96 9:45 EST Received: from louie.udel.edu by sol.cis.udel.edu id aa09423; 20 Mar 96 14:44 GMT Received: from localhost by pokey.cis.udel.edu id aa02614; 20 Mar 96 9:40 EST To: agentx@fv.com Subject: Re: 01: Re: A little question of terminology In-reply-to: Your message of "Tue, 19 Mar 1996 17:59:55 EST." Date: Wed, 20 Mar 1996 09:40:23 -0500 From: Adarsh Sethi Message-ID: <9603200940.aa02614@pokey.cis.udel.edu> >> > From: Bob Stewart >> > Date: Tue, 19 Mar 1996 16:56:24 -0500 >> >> Hi BobS, >> >> > How about a compromise: master agent and component agent? >> > >> > I'm more than half serious. It's accurate and carries the right >> > implications. It's different enough to underscore a difference. >> >> I could live with that. I agree that it has the qualities >> you attribute to it. I am mildly opposed to the term "master >> agent" on a completely non-tech basis and I feel that Dale's >> definition of "system" (in his objection to that part of it) >> is a bit too constrained. >> >> But, even though I am strongly in favor of the system/component >> pair, I don't think this issue is critical to the success of the >> AgentX protocol and I think your proposed compromise is a good one. >> >> Cordially, >> >> BobN Is it possible for a component agent to be itself further sub-divided into component agents? In that case, does it have two roles, one as a master agent and another as a component agent? Any terminology and definitions agreed upon should not preclude such an arrangement. Adarsh Sethi University of Delaware sethi@cis.udel.edu   Delivery-Date: Wed, 20 Mar 1996 08:28:00 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id IAA15977 for X-agentx-local; Wed, 20 Mar 1996 08:28:00 -0800 (PST) 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 IAA15960 for ; Wed, 20 Mar 1996 08:27:56 -0800 (PST) From: sheehan@VNET.IBM.COM Message-Id: <199603201627.IAA15960@zloty.fv.com> Received: from RALVM12 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 5198; Wed, 20 Mar 96 11:27:21 EST Date: Wed, 20 Mar 96 11:24:20 EST To: agentx@fv.com Subject: Issue 1: Terminology Hi Everyone, >> >>How about a compromise: master agent and component agent? >> >>I'm more than half serious. It's accurate and carries the right >>implications. It's different enough to underscore a difference. >> >> Bob > > Hey! I like it! > > (being that my company's main focus is on SNMP agents for > managing host _systems_, I don't like the opportunity for > confusion that the term 'systems agent' presents.) I would tend to agree. Don't want confusion with Systems Monitoring processes/agent. master agent and component agent or master agent and sub-agent would be fine by me :-) Barry ---------------------------------------------------------------------- Barry Sheehan | Internet: Netview for AIX Development Dept E72A | sheehan@vnet.ibm.com A SystemView Product | IBM Corporation | ----------------------------------------------------------------------   Delivery-Date: Wed, 20 Mar 1996 09:16:01 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA28788 for X-agentx-local; Wed, 20 Mar 1996 09:16:00 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id JAA28772 for ; Wed, 20 Mar 1996 09:15:58 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA26795 for ; Wed, 20 Mar 96 11:39:14 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA17726; Wed, 20 Mar 1996 11:37:15 -0500 Date: Wed, 20 Mar 1996 11:39:44 EST From: Bob Natale Subject: Numbered List of Issue Topics To: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi everyone, Ok...here's the list. It can be amended/revised as needed as we progress. The "-" items under some of the numbered items are there just to indicate some of the known sub-topics that should (initially) be included under the numbered topic. They are in no way exclusive of other sub-topics being discussed and one or more of them can be elevated to a numbered topic level of their own if volume/content eventually warrants. Please do you best to include the "nn:" portion on your related postings...it will be fine with me if you want to use the rest of the Subject: header to indicate what particular aspect of the topic you are addressing. 01: Terminology 02: Architecture - Per varbind - Modularity 03: Specification Language - e.g., ASN.1 04: Encoding Protocol - e.g., BER 05: SNMPv1/SNMPv2c Support 06: Master/Component "Binding" - Transport/IPC - Open/Close/KeepAlive 07: Get Processing 08: GetNext Processing 09: GetBulk Processing 10: Set Processing - "As if simultaneous" - Multi-phase commit - Row creation 11: Trap Processing 12: Response Processing 13: Request/Response Dispatching 14: sysUpTime - Timestamping - Counter discontinuities 15: Registration - Individual objects - Object ranges - Subtrees - Overlapping - Instances (incl. partial) - Unregistration - Priority 16: Reservation - Index sharing - MIB(s) 17: Shared Tables - Volume/Volatile Data 18: PDU Header Data Access 19: Component/Component Data Access 20: Access Control - Location - Configuration - "Naming Scopes" - Spatial/Temporal Domains 21: "Fate Sharing" 22: AgentX MIB(s) 23: AgentX API(s) 24: Special Environments - Embedded agents 25: Manager App Interface - Transparency - Disclosure Funny, how '25' feels like a nice round number...but if you feel there are any omissions at this point, let me know asap, and I'll add them to the list unless I can reasonably fit them into one of the above (which I would try to do). You are also invited to suggest which ones might be rolled into other ones...I really want to keep this list as short as possible. I do not personally have the means to set up the kind of Web site that Steve Waldbusser and the folks at CMU did (probably with a lot of help from Bob Stewart) that showed the current status of each issue. Frankly, I don't think most of these are of the yes/no variety (yet). I will do my best to keep the discussions on track on publish interim summaries/status reports on a fairly frequent basis (bi-weekly seems reasonable at this time). Please watch for a later posting from me on our new target schedule...yet to be approved by Deirdre/IESG...and feel free to comment, etc. Thanks. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Wed, 20 Mar 1996 09:16:21 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA28940 for X-agentx-local; Wed, 20 Mar 1996 09:16:20 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id JAA28931 for ; Wed, 20 Mar 1996 09:16:19 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA27733 for ; Wed, 20 Mar 96 11:54:56 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA18293; Wed, 20 Mar 1996 11:53:48 -0500 Date: Wed, 20 Mar 1996 11:56:17 EST From: Bob Natale Subject: 02: "Dual-role" agents To: Adarsh Sethi Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Adarsh Sethi > Date: Wed, 20 Mar 1996 09:40:23 -0500 Hi Ardash, [I've moved this response to the "02: Architecture" thread, because that's really the heart of your very interesting questions.] [Speaking as a technical contributor...] > Is it possible for a component agent to be itself further > sub-divided into component agents? Yes...I'd say so. > In that case, does it have two roles, one as a master agent > and another as a component agent? Yes, *but*...it would not a "master" in the same sense as *the* master agent on the "system" (;-), since manager apps would (normally) go through the latter to get to it and its constituent component agents. Of course, this second "master" agent could use a different port number for direct access by any port-aware manager apps. So, in that model, I'd say that, yes, there can be multiple "master" agents in a single system and that they may have both a master/component relationship among them as well as multiple external manager/master interfaces. > Any terminology and definitions agreed upon should not preclude > such an arrangement. True. But at some point we may have to rely upon our common understanding of the terms--and document that--as opposed to trying forever to find the literally perfect terms...which I doubt exist. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Wed, 20 Mar 1996 10:04:23 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id KAA12061 for X-agentx-local; Wed, 20 Mar 1996 10:04:22 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id KAA12046 for ; Wed, 20 Mar 1996 10:04:21 -0800 (PST) Message-Id: <199603201804.AA245655098@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA245655098; Wed, 20 Mar 1996 10:04:59 -0800 Date: Wed, 20 Mar 1996 10:04:59 -0800 From: Randy Presuhn To: agentx@fv.com Subject: Re: 01: Re: A little question of terminology Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > To: agentx@fv.com > Subject: Re: 01: Re: A little question of terminology > Date: Wed, 20 Mar 1996 09:40:23 -0500 > From: Adarsh Sethi ... > Is it possible for a component agent to be itself further sub-divided > into component agents? In that case, does it have two roles, one as > a master agent and another as a component agent? Any terminology and > definitions agreed upon should not preclude such an arrangement. ... It helps to think of the terms "manager", "agent", "master agent", and "sub-agent" as describing interfaces or roles, rather than defining the programs themselves. It is certainly reasonable for one program to play multiple roles or to have multiple interfaces. It's unfortunate that the term "component agent" leads one to use terms like "sub-divided". "Sub-divided" has connotations at odds with the autonomy subagents must have with respect to each other. It's ironic that "sub" agent doesn't seem to have this connotation. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Wed, 20 Mar 1996 10:14:05 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id KAA14752 for X-agentx-local; Wed, 20 Mar 1996 10:14:05 -0800 (PST) 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 KAA14747 for ; Wed, 20 Mar 1996 10:14:03 -0800 (PST) Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA00901; Wed, 20 Mar 96 10:13:13 PST Received: from santa.strata.com by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA04849; Wed, 20 Mar 96 10:13:12 PST Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA28710; Wed, 20 Mar 96 10:13:11 PST Date: Wed, 20 Mar 96 10:13:11 PST From: dfrancisco@santa.stratacom.com (Dale Francisco) Message-Id: <9603201813.AA28710@santa.strata.com> To: wijnen@vnet.ibm.com Subject: Re: comments on minutes version 01. Cc: agentx@fv.com Bert, Thanks for the clarification. I've amended the paragraph you questioned to read as follows; please let me know if I've missed anything. 170,181c170,175 < Bert briefly discussed DPI subagent registration and outlined < differences between the current DPI implementation and some of < the registration strategies mentioned earlier in the meeting. < DPI supports, but does not mandate, multiple varbinds per < subagent packet. Thus a subagent cannot assume that all of the < varbinds from one SNMP request will be delivered to it in a < single subagent packet. DPI supports registration priority, but < Bert questioned whether this was an agentx requirement. His < current implementation of DPI does not support overlapping < registration, but it is not precluded by the DPI spec. Shared < tables and instance registration would be problematic under the < DPI 2.0 spec. --- > Bert briefly discussed DPI subagent registration. He pointed > out that DPI 2.0 did not support overlapping registration, > instance registration, multiple naming scopes, multiple > varbinds per subagent packet, shared tables, registration > priorities, and other things that had been discussed as > possible agentx requirements. 196d189 < [LA IETF minutes, revision 1.2: Wed Mar 20 10:07:17 PST 1996] Cordially, Dale Francisco Software Engineering StrataCom 93 South La Patera Lane Santa Barbara CA 93117 voice: (805) 961-3642 fax: (805) 961-3600   Delivery-Date: Wed, 20 Mar 1996 10:32:06 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id KAA19275 for X-agentx-local; Wed, 20 Mar 1996 10:32:05 -0800 (PST) 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 KAA19271 for ; Wed, 20 Mar 1996 10:32:04 -0800 (PST) Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA01223; Wed, 20 Mar 96 10:31:57 PST Received: from santa.strata.com by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA05917; Wed, 20 Mar 96 10:31:57 PST Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA28871; Wed, 20 Mar 96 10:31:56 PST Date: Wed, 20 Mar 96 10:31:56 PST From: dfrancisco@santa.stratacom.com (Dale Francisco) Message-Id: <9603201831.AA28871@santa.strata.com> To: agentx@fv.com Subject: Re: 01: Terminology Cc: rpresuhn@peer.com After reading Randy's post on DMTF, I've regained the courage of my convictions. I think "master agent" and "subagent" is simple and clear. "master agent" and "component agent" would be a second choice. "subagent" is better than "component agent" for the same reason that "GetNext" is better than "GetSubsequent". Cordially, Dale Francisco Software Engineering StrataCom 93 South La Patera Lane Santa Barbara CA 93117 voice: (805) 961-3642 fax: (805) 961-3600   Delivery-Date: Wed, 20 Mar 1996 10:50:22 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id KAA23753 for X-agentx-local; Wed, 20 Mar 1996 10:50:22 -0800 (PST) Received: from card.com (card.com [199.100.120.2]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id KAA23750 for ; Wed, 20 Mar 1996 10:50:21 -0800 (PST) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by card.com (8.7.4/8.7.3) with SMTP id NAA00400 for ; Wed, 20 Mar 1996 13:49:21 -0500 (EST) 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 KAA04811 for ; Wed, 20 Mar 1996 10:44:54 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Mar 1996 13:44:56 -0500 To: agentx@fv.com From: bstewart@cisco.com (Bob Stewart) Subject: Re: 01: Re: A little question of terminology Circa 9:40 AM 3/20/96, Adarsh Sethi bitwhacked: >Is it possible for a component agent to be itself further sub-divided >into component agents? In that case, does it have two roles, one as >a master agent and another as a component agent? Any terminology and >definitions agreed upon should not preclude such an arrangement. The component agent would have to take on some part of the master agent role, but that could get real tricky. For some of that it would probably have to go to the master agent. The key to making it work is that the overall system should work as if one master agent were coordinating everything. A second-level component agent shouldn't be able to tell the difference. That is, of course if it's using the standard procedures. How people do their implementation doesn't matter as long as the visible characteristics meet the architectural requirements. Bob   Delivery-Date: Wed, 20 Mar 1996 11:44:10 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id LAA07234 for X-agentx-local; Wed, 20 Mar 1996 11:44:09 -0800 (PST) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id LAA07228 for ; Wed, 20 Mar 1996 11:44:08 -0800 (PST) Received: from flume.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA07019; Wed, 20 Mar 1996 14:37:12 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA10797; Wed, 20 Mar 1996 14:37:11 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA03126; Wed, 20 Mar 1996 14:37:42 -0500 Message-Id: <9603201937.AA03126@bernie.zk3.dec.com> To: dfrancisco@santa.stratacom.com (Dale Francisco) Cc: agentx@fv.com Subject: Re: 01: Terminology In-Reply-To: Your message of "Wed, 20 Mar 96 10:31:56 PST." <9603201831.AA28871@santa.strata.com> Date: Wed, 20 Mar 96 14:37:41 -0500 From: Mike Daniele X-Mts: smtp Of what I've heard so far, I vote for master/sub. The only other idea I've come up with also involves 02: Architecture. If we agree on a division of labor in which the master agent only knows about oids, and the subagents know about their object-types, instantiation, etc. we could use the terms "master agent" and "mib agent". Regards, Mike   Delivery-Date: Wed, 20 Mar 1996 13:41:53 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id NAA07935 for X-agentx-local; Wed, 20 Mar 1996 13:41:52 -0800 (PST) Received: from louie.udel.edu (louie.udel.edu [128.175.1.3]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id NAA07923 for ; Wed, 20 Mar 1996 13:41:50 -0800 (PST) Received: from ra.cis.udel.edu by louie.udel.edu id ab03042; 20 Mar 96 16:40 EST Received: from louie.udel.edu by sol.cis.udel.edu id aa20117; 20 Mar 96 21:40 GMT Received: from localhost by pokey.cis.udel.edu id aa03078; 20 Mar 96 16:35 EST To: Bob Stewart cc: agentx@fv.com Subject: Re: 01: Re: A little question of terminology In-reply-to: Your message of "Wed, 20 Mar 1996 13:44:56 EST." Date: Wed, 20 Mar 1996 16:35:42 -0500 From: Adarsh Sethi Message-ID: <9603201635.aa03078@pokey.cis.udel.edu> >> >> The component agent would have to take on some part of the master agent >> role, but that could get real tricky. For some of that it would probab ly >> have to go to the master agent. The key to making it work is that the >> overall system should work as if one master agent were coordinating >> everything. A second-level component agent shouldn't be able to tell t he >> difference. That is, of course if it's using the standard procedures. How >> people do their implementation doesn't matter as long as the visible >> characteristics meet the architectural requirements. >> >> Bob Just as a manager doesn't/shouldn't have to care whether or not a given agent is monolithic or split into component agents, the master agent shouldn't have to care whether a component agent is monolithic or split further into sub-component agents. Or is transparency not an objective? I haven't been following this list carefully since its inception, so please excuse me if this issue has been resolved previously. Adarsh Sethi University of Delaware sethi@cis.udel.edu   Delivery-Date: Wed, 20 Mar 1996 13:48:13 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id NAA09624 for X-agentx-local; Wed, 20 Mar 1996 13:48:12 -0800 (PST) Received: from louie.udel.edu (louie.udel.edu [128.175.1.3]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id NAA09610 for ; Wed, 20 Mar 1996 13:48:07 -0800 (PST) Received: from ra.cis.udel.edu by louie.udel.edu id aa03106; 20 Mar 96 16:45 EST Received: from louie.udel.edu by sol.cis.udel.edu id aa20271; 20 Mar 96 21:45 GMT Received: from localhost by pokey.cis.udel.edu id aa03089; 20 Mar 96 16:44 EST To: Bob Natale cc: agentx@fv.com Subject: Re: 02: "Dual-role" agents In-reply-to: Your message of "Wed, 20 Mar 1996 11:56:17 EST." Date: Wed, 20 Mar 1996 16:44:55 -0500 From: Adarsh Sethi Message-ID: <9603201644.aa03089@pokey.cis.udel.edu> >> Yes, *but*...it would not a "master" in the same sense as >> *the* master agent on the "system" (;-), since manager apps >> would (normally) go through the latter to get to it and its >> constituent component agents. Of course, this second "master" >> agent could use a different port number for direct access by >> any port-aware manager apps. So, in that model, I'd say that, >> yes, there can be multiple "master" agents in a single system >> and that they may have both a master/component relationship >> among them as well as multiple external manager/master >> interfaces. >> >> BobN I agree that manager apps would always go through the so-called "system" agent, so you are right that it wouldn't be a "master" in quite the same sense. But the "system" agent could forward a request to a "component" agent which wasn't really monolithic, and so it might split the request up and send it further down to "sub-component" agents. Your view that there may actually be multiple external manager/master interfaces is very interesting. Would the behavior of the agent depend on which external interface the request came in on? In that case, would the MIB views presented to the manager and the agent structure (in terms of master-component relationships) also vary with where the request was received? Adarsh Sethi University of Delaware sethi@cis.udel.edu   Delivery-Date: Wed, 20 Mar 1996 14:16:41 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id OAA17016 for X-agentx-local; Wed, 20 Mar 1996 14:16:40 -0800 (PST) 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 OAA17009 for ; Wed, 20 Mar 1996 14:16:39 -0800 (PST) Message-Id: <199603202216.OAA17009@zloty.fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0191; Wed, 20 Mar 96 17:16:11 EST Date: Wed, 20 Mar 96 23:15:46 CET From: "Bert Wijnen" To: dfrancisco@santa.stratacom.com cc: agentx@fv.com Subject: comments on minutes version 01. Ref: Your note of Wed, 20 Mar 96 10:13:11 PST Subject: comments on minutes version 01. Dale, new text is fine with me, thanks Bert   Delivery-Date: Wed, 20 Mar 1996 15:02:57 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id PAA28862 for X-agentx-local; Wed, 20 Mar 1996 15:02:57 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id PAA28854 for ; Wed, 20 Mar 1996 15:02:54 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA18473 for ; Wed, 20 Mar 96 17:43:46 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA24131; Wed, 20 Mar 1996 17:42:38 -0500 Date: Wed, 20 Mar 1996 17:45:08 EST From: Bob Natale Subject: Schedule guidance needed To: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi everyone, I need your help. I have to submit revisions to our charter by this Friday, 3/22. This will include listing Dale as editor and a proposed revised schedule. I would like you to review and think about the new schedule I will include below, and let me know what changes to it you think are necessary. It might be a bit overly detailed for a wg charter, in part due to my congenital wordiness but, more importantly, because I tried to take a project management view of the tasks...while being some aggressive and optimistic in the fine IETF tradition. First, for comparative purposes, here is the current schedule: ----- Goals and Milestones Dec 95 First meeting at Dallas IETF. Dec 95 Post first Internet-Draft(s) for SNMP Agent Extensibility. Jan 96 Post revised Internet-Draft(s) on SNMP Agent Extensibility. Mar 96 Meet at LA IETF. Apr 96 Post final Internet-Drafts. May 96 Submit final set of Internet-Drafts on SNMP Agent Extensibility to IESG for consideration as a Proposed Standard. ----- As soon as you stop laughing, take a look at this revised schedule: Goals and Milestones Dec 95 First meeting at Dallas IETF. Jan-Feb 96 Identify/review existing SNMP Agent Extensibility protocol specifications and technologies Mar 96 Meet at LA IETF to identify requirements and form task groups Apr 96 Post initial AgentX protocol I-D May 96 Post revised AgentX protocol I-D Jun 96 Post final AgentX protocol I-D Meet at Montreal IETF to: 1. Review final AgentX protocol I-D 2. Outline implementation reporting requirements and mechanisms 3. Assess need to pursue either the optional MIB deliverable and/or the optional API deliverable (assumed to be affirmative herein) Jul 96 Post initial AgentX MIB I-D Post initial AgentX API I-D Initiate formal implementation progress monitoring Sep 96 Post revised AgentX MIB I-D Post revised AgentX API I-D Continue formal implementation progress monitoring Oct 96 Collect and evaluate implementation reports Nov 96 Conduct interoperability testing Dec 96 (early) Post final AgentX MIB I-D Post final AgentX API I-D Meet at San Jose IETF to: 1. Review implementation/interoperability results 2. Review final AgentX Protocol I-D 3. Review final AgentX MIB I-D 4. Review final AgentX API I-D 5. Identify/resolve any "loose ends" Dec 96 (end of month) Submit all AgentX I-Ds to IESG for consideration as Proposed Standards ----- All dates imply "end of month", unless otherwise stated. Please give me your feedback asap. And whatever we submit will still be subject to review/revision by Deirdre and/or the IESG as a whole. Thanks. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Wed, 20 Mar 1996 17:02:06 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id RAA27730 for X-agentx-local; Wed, 20 Mar 1996 17:02:05 -0800 (PST) Received: from paloalto.access.hp.com (paloalto.access.hp.com [15.254.56.2]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id RAA27623 for ; Wed, 20 Mar 1996 17:02:04 -0800 (PST) Received: from nsmdserv.cnd.hp.com by paloalto.access.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA050440092; Wed, 20 Mar 1996 17:01:32 -0800 Received: from localhost by nsmdserv.cnd.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA008280094; Wed, 20 Mar 1996 18:01:34 -0700 Message-Id: <199603210101.AA008280094@nsmdserv.cnd.hp.com> To: Adarsh Sethi Cc: Bob Natale , agentx@fv.com Subject: Re: 02: "Dual-role" agents In-Reply-To: Your message of Wed, 20 Mar 1996 16:44:55 -0500. <9603201644.aa03089@pokey.cis.udel.edu> Date: Wed, 20 Mar 1996 18:01:34 -0700 From: "Brian O'Keefe" This topic apears to center around the notion of "agent-adaptors", like those that currently exist in todays non-standard extensible agent technologies... and that includes *ALL* existing snmp agent technologies since this effort is the first to formally standardize agent extensibilty. I see the notion of "adaptor-agents" (or "dual-role agents" if you prefer) to be a vendor specific thing that is beyond the scope of this group. This group is chartered to define a standard interface for sub-agents to be developed and attach to an snmp protocol entity that listens to the standard snmp port (e.g., udp 161). If there are intermediate layers in between the port 161 listening and the standard sub-agent interface, who cares! The only important thing is that a sub-agent implemented to this standard is capable of working with the thing that is actually listening to the snmp port. bok - std disclaimer   Delivery-Date: Wed, 20 Mar 1996 21:43:06 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id VAA12391 for X-agentx-local; Wed, 20 Mar 1996 21:43:05 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id VAA12370 for ; Wed, 20 Mar 1996 21:43:04 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA03999 for ; Thu, 21 Mar 96 00:35:07 -0500 Date: Thu, 21 Mar 1996 00:34:35 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA28243; Thu, 21 Mar 1996 00:34:35 -0500 Message-Id: <9603210534.AA28243@nips.acec.com> To: bok@nsmdserv.cnd.hp.com Subject: Re: 02: "Dual-role" agents Cc: agentx@fv.com > Date: Wed, 20 Mar 1996 18:01:34 -0700 > From: Brian O'Keefe Hi Brian, <...> > I see the notion of "adaptor-agents" (or "dual-role agents" if you > prefer) to be a vendor specific thing that is beyond the scope of > this group. Correct. <...> Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Thu, 21 Mar 1996 04:54:00 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id EAA08019 for X-agentx-local; Thu, 21 Mar 1996 04:54:00 -0800 (PST) Received: from ta.antec.com ([205.187.171.11]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id EAA08005 for ; Thu, 21 Mar 1996 04:53:58 -0800 (PST) Received: from pc_georgeb by ta.antec.com via SMTP (8.6.12/8.6.4) for id HAA13966; Thu, 21 Mar 1996 07:48:41 -0500 Date: Thu, 21 Mar 1996 07:48:41 -0500 Message-Id: <199603211248.HAA13966@ta.antec.com> X-Sender: georgeb@bopper.ta.antec.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: agentx@fv.com From: george.best@antec.com (George Best) Subject: Re: A little question of terminology At 08:40 AM 3/20/96 -0500, Bob Stewart wrote: >I'll accept the nomination for President if Dole steps down and if I don't >have to do any campaigning and Clinton resigns and I get to decide things >instead of waiting for Congress to vote on them. I'll listen to Congress's >opinion if they can get it to me in time and don't annoy me too much. > Sounds like Bob is Dogbert's soul-mate... Gb   Delivery-Date: Thu, 21 Mar 1996 08:54:43 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id IAA04639 for X-agentx-local; Thu, 21 Mar 1996 08:54:43 -0800 (PST) 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 IAA04632 for ; Thu, 21 Mar 1996 08:54:42 -0800 (PST) Message-Id: <199603211654.IAA04632@zloty.fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 5974; Thu, 21 Mar 96 11:54:14 EST Date: Thu, 21 Mar 96 17:53:55 CET From: "Bert Wijnen" To: agentx@fv.com Subject: 01: terminology My vote is for (master) agent and subagent. Bert   Delivery-Date: Thu, 21 Mar 1996 08:57:26 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id IAA05307 for X-agentx-local; Thu, 21 Mar 1996 08:57:25 -0800 (PST) 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 IAA05295 for ; Thu, 21 Mar 1996 08:57:23 -0800 (PST) Message-Id: <199603211657.IAA05295@zloty.fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 6054; Thu, 21 Mar 96 11:56:49 EST Date: Thu, 21 Mar 96 17:56:24 CET From: "Bert Wijnen" To: agentx@fv.com Subject: revised schedule I can find myself in the new schedule. Except, I guess that posting of the final draft in June96 should be early June (default being end of month). We do want to discuss that final draft at the IETF, so we need to give people some time to review and read and study. Bert   Delivery-Date: Thu, 21 Mar 1996 09:04:15 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA06964 for X-agentx-local; Thu, 21 Mar 1996 09:04:15 -0800 (PST) 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 JAA06957 for ; Thu, 21 Mar 1996 09:04:13 -0800 (PST) Message-Id: <199603211704.JAA06957@zloty.fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 6254; Thu, 21 Mar 96 12:03:45 EST Date: Thu, 21 Mar 96 18:03:24 CET From: "Bert Wijnen" To: agentx@fv.com Subject: 05: sysUpTime I propose we do this: a.in the reponse to DPI-OPEN we pass the current sysUpTime (in units of TimeTicks, e.g. 100ths of a second). This allows subagents to sync up any timers they may need to support. b.whenever a sub-agent disconnects or unregisters anything we reset sysUpTime with a warmStart trap (No, I don't like this, but this is the only way I think to live up to the semantics of sysUpTime and to ensure that we implicitly reset sysUpTime if counter discontinuities (may) occur... but we need more, see next c.we include a DPI-RESET-SYSUPTIME packet (Again, I don't like it, but we need it to allow a subagent to reset sysUpTime when a counter discontinuity occurs) When the (master) agent receives this, it resets sysUpTime and sends a warmStart trap. I think this would solve all issues with sysUpTime, albeit that the solution is a bit rough. Bert   Delivery-Date: Thu, 21 Mar 1996 09:16:47 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA10084 for X-agentx-local; Thu, 21 Mar 1996 09:16:47 -0800 (PST) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.139.6]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id JAA10079 for ; Thu, 21 Mar 1996 09:16:46 -0800 (PST) Received: from hawpub.watson.ibm.com ([9.2.90.19]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id MAA23295; Thu, 21 Mar 1996 12:16:41 -0500 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/2/16/96) id AA35091; Thu, 21 Mar 1996 12:16:31 -0500 Message-Id: <9603211716.AA35091@hawpub.watson.ibm.com> Subject: Re: 02: "Dual-role" agents To: bok@nsmdserv.cnd.hp.com (Brian O'Keefe) Date: Thu, 21 Mar 1996 12:16:31 -0500 (EST) From: "Uri Blumenthal" Cc: agentx@fv.com In-Reply-To: <199603210101.AA008280094@nsmdserv.cnd.hp.com> from "Brian O'Keefe" at Mar 20, 96 06:01:34 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Brian O'Keefe says: > I see the notion of "adaptor-agents" (or "dual-role agents" if you > prefer) to be a vendor specific thing that is beyond the scope of > this group.......... > This group is chartered to define a standard interface for sub-agents > to be developed and attach to an snmp protocol entity.............. 1. I agree - "dual-role" entities aren't within the scope of "agentx" WG. 2. I am sure that there will be a benefit in defining the functionality and standardizing the interfaces to the "dual-role" agents, as it will allow interoperation between NMS of one vendor and "dual-role" of another. Thus, in my view it's clearly a subject to be discussed [even though not in this WG] and *not* a vendor-specific thing. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Thu, 21 Mar 1996 09:43:17 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA16783 for X-agentx-local; Thu, 21 Mar 1996 09:43:17 -0800 (PST) Received: from hnssysa.hns.com ([139.85.76.210]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id JAA16768; Thu, 21 Mar 1996 09:43:15 -0800 (PST) Received: from pessys5.hns.com (pessys5.hns.com [139.85.124.96]) by hnssysa.hns.com (8.7.1/) with ESMTP id MAA04371; Thu, 21 Mar 1996 12:43:06 -0500 (EST) Received: (dward@localhost) by pessys5.hns.com (8.7.1/8.6.12) id MAA13806; Thu, 21 Mar 1996 12:43:06 -0500 (EST) From: "David Ward" Message-Id: <9603211243.ZM13804@pessys5.hns.com> Date: Thu, 21 Mar 1996 12:43:05 -0500 In-Reply-To: dfrancisco@santa.stratacom.com (Dale Francisco) "Draft of L.A. IETF minutes" (Mar 19, 1:07pm) References: <9603192107.AA24288@santa.strata.com> X-Mailer: Z-Mail (3.2.1 10apr95) To: , agentx@fv.com Subject: Re: Draft of L.A. IETF minutes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii I have a comment on the following from the meeting minutes: Per varbind vs. per packet. Previously decided in favor of per varbind. We build satellite networks, and the per varbind style is woefully inefficient because of the amount of satellite bandwidth that it uses. Is it possible to have the master agent broadcast a "Start varbind processing" message before processing the first varbind, and an "End varbind processing" message after the last varbind has been passed to a subagent? If this is done (and the master agent is asynchronous in nature), then we could "cache" the varbinds in our subagent, send them over the satellite when we receive the "End" message, and then send the response(s) to the master agent. We could have the subagents register in these "Start/End" messages using whatever scheme is devised for them to register for the varbinds themselves. This could possibly be done by having the "Start/End" actually be MIB variables themselves? Thanks, David -- David Ward dward@hns.com Hughes Network Systems, Inc. 11717 Exploration Lane Germantown, MD 20876 (301) 212-1022 (voice) (301) 212-2089 (fax) -------------------------------------------------------------------------------- Please help me - I'm stuck in a barrel and can't get out! --------------------------------------------------------------------------------   Delivery-Date: Thu, 21 Mar 1996 09:46:24 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA17580 for X-agentx-local; Thu, 21 Mar 1996 09:46:24 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id JAA17574 for ; Thu, 21 Mar 1996 09:46:22 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA28258 for ; Thu, 21 Mar 96 12:17:12 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA05019; Thu, 21 Mar 1996 12:15:13 -0500 Date: Thu, 21 Mar 1996 12:17:50 EST From: Bob Natale Subject: Re: 02: "Dual-role" agents To: Adarsh Sethi Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Adarsh Sethi > Date: Wed, 20 Mar 1996 16:44:55 -0500 Hi Adarsh, I just wanted to answer your questions, although Bob Stewart's point about this general theme being outside the scope of the AgentX effort is true. <...> > I agree that manager apps would always go through the so-called > "system" agent, so you are right that it wouldn't be a "master" > in quite the same sense. Right. > But the "system" agent could forward a > request to a "component" agent which wasn't really monolithic, > and so it might split the request up and send it further down > to "sub-component" agents. Right...but as BobS said, none of that would be visible from the AgentX perspective. > Your view that there may actually be > multiple external manager/master interfaces is very interesting. > Would the behavior of the agent depend on which external interface > the request came in on? It could. It would be an implementation decision. > In that case, would the MIB views presented > to the manager and the agent structure (in terms of master-component > relationships) also vary with where the request was received? They could. It would be an implementation decision. It is extremely unlikely that AgentX will address any of these issues directly. And all of them can be implemented without intefering with the AgentX protocol paths in such a system.... If you'd like to pursue these issues in more detail, I'll be happy to do so off-list or perhaps you can raise them on the general snmp list. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Thu, 21 Mar 1996 10:02:51 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id KAA21563 for X-agentx-local; Thu, 21 Mar 1996 10:02:51 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id KAA21558 for ; Thu, 21 Mar 1996 10:02:50 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA29145 for ; Thu, 21 Mar 96 12:28:35 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA05197; Thu, 21 Mar 1996 12:27:27 -0500 Date: Thu, 21 Mar 1996 12:30:03 EST From: Bob Natale Subject: 02: Transparency To: Adarsh Sethi Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Adarsh Sethi > Date: Wed, 20 Mar 1996 16:35:42 -0500 > Subject: 01: Re: A little question of terminology Hi Adarsh, <...> >> How people do their implementation doesn't matter as long as >> the visible characteristics meet the architectural requirements. >> BobS > > Just as a manager doesn't/shouldn't have to care whether or not a > given agent is monolithic or split into component agents, the > master agent shouldn't have to care whether a component agent > is monolithic or split further into sub-component agents. I think that is exactly what BobS is saying above. > Or is transparency not an objective? I haven't been following > this list carefully since its inception, so please excuse me if > this issue has been resolved previously. Yes, it is a major objective. We are generally agreed, it seems, that transparency from the perspective of the management applications is a requirement, that it can be met, and (broadly) we know how to achieve it. Transparency from the perspective of an independently developed subagent not knowing or caring which independently developed master agent it will bind to at run time via AgentX is, I am sorry to report, not quite as firmly established. But it will have to be, in the end. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Thu, 21 Mar 1996 09:58:16 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA20466 for X-agentx-local; Thu, 21 Mar 1996 09:58:15 -0800 (PST) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id JAA20463 for ; Thu, 21 Mar 1996 09:58:14 -0800 (PST) Received: from flume.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA04047; Thu, 21 Mar 1996 12:53:33 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA31038; Thu, 21 Mar 1996 12:53:30 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA03436; Thu, 21 Mar 1996 12:54:01 -0500 Message-Id: <9603211754.AA03436@bernie.zk3.dec.com> To: "Bert Wijnen" Cc: agentx@fv.com Subject: Re: 05: sysUpTime In-Reply-To: Your message of "Thu, 21 Mar 96 18:03:24 +0700." <199603211704.JAA06957@zloty.fv.com> Date: Thu, 21 Mar 96 12:54:00 -0500 From: Mike Daniele X-Mts: smtp Hi Bert, >I propose we do this: > a.in the reponse to DPI-OPEN we pass the current sysUpTime (in > units of TimeTicks, e.g. 100ths of a second). > This allows subagents to sync up any timers they may > need to support. Agreed. Subagents that need clocks may be assumed to have access to them, and be able to convert this value to whatever they need. > b.whenever a sub-agent disconnects or unregisters anything we > reset sysUpTime with a warmStart trap > (No, I don't like this, but this is the only way I think to > live up to the semantics of sysUpTime and to ensure that > we implicitly reset sysUpTime if counter discontinuities > (may) occur... but we need more, see next But disconnecting or unregistering doesn't necessarily mean a counter discontinuity is pending, right? this may be a subagent that reports counters kept in hardware that's still running, for example. > c.we include a DPI-RESET-SYSUPTIME packet > (Again, I don't like it, but we need it to allow a subagent to > reset sysUpTime when a counter discontinuity occurs) > When the (master) agent receives this, it resets sysUpTime and > sends a warmStart trap. But this leaves all other subagents synching against the old value of sysUpTime? In general, I thought we'd more or less concluded in L.A. that sysUpTime can never achieve the semantics implied by (broken) applications, and that this shouldn't really be an agent issue. Maybe I was dreaming... :-) Regards, Mike   Delivery-Date: Thu, 21 Mar 1996 10:43:15 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id KAA01385 for X-agentx-local; Thu, 21 Mar 1996 10:43:14 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id KAA01362 for ; Thu, 21 Mar 1996 10:43:12 -0800 (PST) Message-Id: <199603211843.AA295533824@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA295533824; Thu, 21 Mar 1996 10:43:44 -0800 Date: Thu, 21 Mar 1996 10:43:44 -0800 From: Randy Presuhn To: agentx@fv.com Subject: Re: Draft of L.A. IETF minutes Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > From: "David Ward" > Message-Id: <9603211243.ZM13804@pessys5.hns.com> > Date: Thu, 21 Mar 1996 12:43:05 -0500 > In-Reply-To: dfrancisco@santa.stratacom.com (Dale Francisco) "Draft of L.A. IETF minutes" (Mar 19, 1:07pm) > References: <9603192107.AA24288@santa.strata.com> > To: , agentx@fv.com > Subject: Re: Draft of L.A. IETF minutes > > I have a comment on the following from the meeting minutes: > > Per varbind vs. per packet. Previously decided in favor of > per varbind. > > We build satellite networks, and the per varbind style is woefully > inefficient because of the amount of satellite bandwidth that it > uses. Is it possible to have the master agent broadcast a "Start > varbind processing" message before processing the first varbind, > and an "End varbind processing" message after the last varbind has > been passed to a subagent? If this is done (and the master agent > is asynchronous in nature), then we could "cache" the varbinds in our > subagent, send them over the satellite when we receive the "End" > message, and then send the response(s) to the master agent. We could > have the subagents register in these "Start/End" messages using > whatever scheme is devised for them to register for the varbinds > themselves. This could possibly be done by having the "Start/End" actually be > MIB variables themselves? ... This is a nomenclature problem. "Per varbind" simply means that we've accepted as a requirement that different varbinds in a single SNMP operation may involve different subagents. "Per packet" multiplexing, equivalent to simple proxy, only supports SNMP operations where all varbinds belong to the same subagent. The decision between "per varbind" and "per packet" multiplexing is independent of the number of varbinds per pdu in the subagent protocol. There was a fairly strong concensus at the Dallas meeting that we'd rather NOT split varbinds belonging to a single SNMP operation into multiple PDUs between a subagent and its master. The only argument in favor of the (one-at-a-time) approach was for backwards compatibility with some DPI subagent implementations. As far as I can tell, that argument does not outweigh the many disadvantages (time, complexity, etc.) that result from "one-at-a-time" handling of the varbinds. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Thu, 21 Mar 1996 10:51:28 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id KAA03487 for X-agentx-local; Thu, 21 Mar 1996 10:51:27 -0800 (PST) Received: from fn3.freenet.tlh.fl.us (fn3.freenet.tlh.fl.us [144.174.128.57]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id KAA03480 for ; Thu, 21 Mar 1996 10:51:26 -0800 (PST) Received: (from rwill1@localhost) by fn3.freenet.tlh.fl.us (8.6.10/8.6.9) id NAA27105 for agentx@fv.com; Thu, 21 Mar 1996 13:51:07 -0500 From: Russell Willis Message-Id: <199603211851.NAA27105@fn3.freenet.tlh.fl.us> Subject: Re: 02: "Dual-role" agents (fwd) To: agentx@fv.com Date: Thu, 21 Mar 96 13:50:57 18000 X-Mailer: ELM [version 2.3.1 PL11] To all: In response to Brian O'keefe's request, I am posting my diagram below for further consideration. See below: Forwarded message: > From bok@nsmdserv.cnd.hp.com Thu Mar 21 09:03:10 1996 > Message-Id: <199603211400.AA024826817@nsmdserv.cnd.hp.com> > To: Russell Willis > Subject: Re: 02: "Dual-role" agents > In-Reply-To: Your message of Wed, 20 Mar 1800 22:57:15. > <199603210357.WAA20943@fn3.freenet.tlh.fl.us> > Date: Thu, 21 Mar 1996 07:00:16 -0700 > From: "Brian O'Keefe" > > > Russell, > > Thanks. You diagram illustrating my prose is an excellent > addendum to my message. Could you please post it to the > entire agentx list for all to benefit from? > > Regards, > bok > > > > This group is chartered to define a standard interface for sub-agents > > > to be developed and attach to an snmp protocol entity that listens to > > > the standard snmp port (e.g., udp 161). If there are intermediate layers > > > in between the port 161 listening and the standard sub-agent interface, > > > who cares! The only important thing is that a sub-agent implemented > > > to this standard is capable of working with the thing that is actually > > > listening to the snmp port. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > I couldn't agree more with your statement immediately above. > > How about a picture to enhance the discussion: > > > > > > ------------------/\ ___________ > > --------- | SNMP |--| | > > | Port |__________| Protocol | | Sub- | > > | 161 | | Entity | | Agent | > > --------- | ( listening ) |--|___________| > > ------------------\/ > > ^<---- Interface > > > > > > > > bok > > > > > > - std disclaimer > > > > > > > ---Russell--- > > bok > > ---Russell---   Delivery-Date: Thu, 21 Mar 1996 11:06:40 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id LAA07972 for X-agentx-local; Thu, 21 Mar 1996 11:06:40 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id LAA07967 for ; Thu, 21 Mar 1996 11:06:39 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA03642 for ; Thu, 21 Mar 96 13:44:07 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA06401; Thu, 21 Mar 1996 13:42:58 -0500 Date: Thu, 21 Mar 1996 13:45:35 EST From: Bob Natale Subject: 02: Per-Varbind Processing To: David Ward Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: David Ward > Date: Thu, 21 Mar 1996 12:43:05 -0500 > Subject: Re: Draft of L.A. IETF minutes > To: agentx-owner@fv.com, agentx@fv.com ^^^^^^^^^^^^ Hi Dave, [Please drop the agentx-owner@fv.com from your To:/Cc: headers if you are sending general messages to agentx@fv.com.] > I have a comment on the following from the meeting minutes: > > Per varbind vs. per packet. Previously decided in favor of > per varbind. > > We build satellite networks, and the per varbind style is woefully > inefficient because of the amount of satellite bandwidth that it > uses. We are using the term "per varbind", in contrast to "per packet" to distinguish a high-level architectual difference between the generic extensible agent model and the generic proxy model, respectively. In this context, "per varbind" does *not* mean "one varbind at a time". It means that: 1. The manager application can package multiple varbinds in one request to the master agent that may be destined (unbeknownst to the manager application) form multiple subagents; and 2. The master agent will demux these varbinds and dispatch them to their respective subagents, then remux the multiple responses back into a single SNMP response packet and transmit that back to the management applications. Some specific *implementations* of extensible agent technology have elected to limit the exchanges between the master and the subagent to a single varbind at a time. That is not going to be a design feature of AgentX. > Is it possible to have the master agent broadcast a "Start > varbind processing" message before processing the first varbind, > and an "End varbind processing" message after the last varbind has > been passed to a subagent? If this is done (and the master agent > is asynchronous in nature), then we could "cache" the varbinds in our > subagent, send them over the satellite when we receive the "End" > message, and then send the response(s) to the master agent. We could > have the subagents register in these "Start/End" messages using > whatever scheme is devised for them to register for the varbinds > themselves. This could possibly be done by having the "Start/End" > actually be MIB variables themselves? That is a possibility. I am personally hopeful, however, that our ultimate consensus will be for something more efficient... such as a policy that all varbinds for a SetRequest must be given to the subagent in a single packet. [Dale, please note that we will need to include these defintions of "per varbind" and "per packet" in our Glossary...Thanks.] Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Thu, 21 Mar 1996 11:32:30 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id LAA14031 for X-agentx-local; Thu, 21 Mar 1996 11:32:30 -0800 (PST) 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 LAA14023 for ; Thu, 21 Mar 1996 11:32:28 -0800 (PST) Message-Id: <199603211932.LAA14023@zloty.fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0028; Thu, 21 Mar 96 14:32:00 EST Date: Thu, 21 Mar 96 20:31:42 CET From: "Bert Wijnen" To: agentx@fv.com Subject: 05: sysUpTime Mike writes: > > b.whenever a sub-agent disconnects or unregisters anything we > > reset sysUpTime with a warmStart trap > > (No, I don't like this, but this is the only way I think to > > live up to the semantics of sysUpTime and to ensure that > > we implicitly reset sysUpTime if counter discontinuities > > (may) occur... but we need more, see next > > But disconnecting or unregistering doesn't necessarily mean > a counter discontinuity is pending, right? this may be a subagent > that reports counters kept in hardware that's still running, for example. > I agree that we do not know. But to be on the safe side we would need to do this, unless we require the agent to have more knowledge about internals of a subagent and I think we do not want that. > > c.we include a DPI-RESET-SYSUPTIME packet > > (Again, I don't like it, but we need it to allow a subagent to > > reset sysUpTime when a counter discontinuity occurs) > > When the (master) agent receives this, it resets sysUpTime and > > sends a warmStart trap. > > But this leaves all other subagents synching against the old value > of sysUpTime? > You got me here (actually I was checking if the readers are alert ;-)). So we would need a DPI_UPDATED_SYSUPTIME packet that flows from (master) agent to subagent when b. or c. happen. The alternative (possibly much better) would be to include in the header of each DPI packet the current sysUpTime. It is just 4 bytes (assuming network byte order encoding) and each subagent is always in sync for sysUpTime. > In general, I thought we'd more or less concluded in L.A. that > sysUpTime can never achieve the semantics implied by (broken) > applications, and that this shouldn't really be an agent issue. > > Maybe I was dreaming... :-) > I know that this was mentioned, but I don't think we had consensus on that. If we did, the better. Then we would only do a. of my previous e-mail, namely pass sysuptime in the response to a DPI_OPEN. (BobN, can you call for consensus on any of these ideas? or is that too early?). Bert   Delivery-Date: Thu, 21 Mar 1996 11:47:34 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id LAA17611 for X-agentx-local; Thu, 21 Mar 1996 11:47:34 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id LAA17608 for ; Thu, 21 Mar 1996 11:47:33 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA06101 for ; Thu, 21 Mar 96 14:26:14 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA07078; Thu, 21 Mar 1996 14:25:04 -0500 Date: Thu, 21 Mar 1996 14:27:41 EST From: Bob Natale Subject: Re: revised schedule To: Bert Wijnen Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Bert Wijnen > Date: Thu, 21 Mar 96 17:56:24 CET Hi Bert, > I can find myself in the new schedule. Great! > Except, I guess that posting of the final draft in June96 should > be early June (default being end of month). We do want to discuss > that final draft at the IETF, so we need to give people some time > to review and read and study. Good point. I'll amend that one to indicate that the final draft will be posted on or before the official cut-off date prior to the Montreal IETF. Since the Montreal meeting is late in June (24-28, I believe), that should give us a week or so extra into the month. (...Unless there are any objections and assuming that the NMAD/IESG will approve the schedule changes at all!) Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Thu, 21 Mar 1996 12:01:09 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id MAA20572 for X-agentx-local; Thu, 21 Mar 1996 12:01:08 -0800 (PST) Received: from seymour16.snmp.com (seymour16.snmp.com [192.147.142.16]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id MAA20566 for ; Thu, 21 Mar 1996 12:01:05 -0800 (PST) Received: by seymour16.snmp.com (5.61++/2.8s-SNMP) id AA28185; Thu, 21 Mar 96 15:00:53 -0500 Date: Thu, 21 Mar 96 15:00:53 -0500 From: David Battle Message-Id: <9603212000.AA28185@seymour16.snmp.com> To: agentx@fv.com Subject: 05: sysUpTime Bert Wijnen say: > > I propose we do this: > > a.in the reponse to DPI-OPEN we pass the current sysUpTime (in > > b.whenever a sub-agent disconnects or unregisters anything we > > reset sysUpTime with a warmStart trap > > c.we include a DPI-RESET-SYSUPTIME packet To which Mike Daniele responds: > But disconnecting or unregistering doesn't necessarily mean > a counter discontinuity is pending, right? this may be a subagent > that reports counters kept in hardware that's still running, for example. How about a and c but not b. That way the subagent can decide if something it's doing really needs to reset sysUpTime. Um, except maybe if a subagent disconnects without "CLOSEing" you might want to reset sysUpTime and warm start "automagically". -David battle@snmp.com Senior Software Engineer SNMP Research, Inc.   Delivery-Date: Thu, 21 Mar 1996 12:10:57 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id MAA22899 for X-agentx-local; Thu, 21 Mar 1996 12:10:56 -0800 (PST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id MAA22893 for ; Thu, 21 Mar 1996 12:10:55 -0800 (PST) Received: from flume.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA09492; Thu, 21 Mar 1996 14:52:54 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA22693; Thu, 21 Mar 1996 14:52:47 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA03465; Thu, 21 Mar 1996 14:53:18 -0500 Message-Id: <9603211953.AA03465@bernie.zk3.dec.com> To: Bob Natale Cc: agentx@fv.com Subject: Re: Schedule guidance needed In-Reply-To: Your message of "Wed, 20 Mar 96 17:45:08 EST." Date: Thu, 21 Mar 96 14:53:17 -0500 From: Mike Daniele X-Mts: smtp Hi Bob, >Apr 96 > Post initial AgentX protocol I-D Anything posted in April will have many sections marked "To Be Determined", unless the 25 items are resolved much more quickly than I think they will be. But there was general agreement to get "something" out relatively soon to make discussion easier. So this seems ok. >May 96 > Post revised AgentX protocol I-D I think we should produce an initial draft of the Agentx MIB by this point. Regards, Mike   Delivery-Date: Thu, 21 Mar 1996 12:18:16 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id MAA24634 for X-agentx-local; Thu, 21 Mar 1996 12:18:16 -0800 (PST) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.139.6]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id MAA24628 for ; Thu, 21 Mar 1996 12:18:15 -0800 (PST) Received: from hawpub.watson.ibm.com ([9.2.90.19]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id PAA10876 for ; Thu, 21 Mar 1996 15:18:16 -0500 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/2/16/96) id AA27350; Thu, 21 Mar 1996 15:18:01 -0500 Message-Id: <9603212018.AA27350@hawpub.watson.ibm.com> Subject: Re: 05: sysUpTime To: wijnen@vnet.ibm.com (Bert Wijnen) Date: Thu, 21 Mar 1996 15:18:01 -0500 (EST) From: "Uri Blumenthal" Cc: agentx@fv.com In-Reply-To: <199603211704.JAA06957@zloty.fv.com> from "Bert Wijnen" at Mar 21, 96 06:03:24 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Bert Wijnen says: > a.in the reponse to DPI-OPEN we pass the current sysUpTime (in > units of TimeTicks, e.g. 100ths of a second). > This allows subagents to sync up any timers they may > need to support. Sure. Or alternatively there should be whateverUpTime related to every subagent? > b.whenever a sub-agent disconnects or unregisters anything we > reset sysUpTime with a warmStart trap > (No, I don't like this, but this is the only way I think to > live up to the semantics of sysUpTime and to ensure that > we implicitly reset sysUpTime if counter discontinuities > (may) occur... but we need more, see next > c.we include a DPI-RESET-SYSUPTIME packet I strongly dislike this solution, as it clearly disrupts all the counters: some are related to restarted agent and were zeroed, but some have been accumulating for a while. Now, sysUpTime will claim everything's restarted [from zero?], but some counters will be zeroed and some will keep incrementing! Is this a problem? I'm afraid it is. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Thu, 21 Mar 1996 12:18:59 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id MAA24756 for X-agentx-local; Thu, 21 Mar 1996 12:18:58 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id MAA24752 for ; Thu, 21 Mar 1996 12:18:57 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA07917 for ; Thu, 21 Mar 96 14:59:11 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA07614; Thu, 21 Mar 1996 14:58:02 -0500 Date: Thu, 21 Mar 1996 15:00:39 EST From: Bob Natale Subject: 13: Request/Response Dispatching To: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Bob Stewart > Date: Wed, 20 Mar 1996 08:40:55 -0500 > Subject: Re: comments on minutes version 01. Hi everyone, I'd like to kick off this numbered topic with a follow-up to the following exchange between Bert and BobS: > Circa 6:53 AM 3/20/96, Bert Wijnen bitwhacked: >> The result is that a sub-agent cannot assume that all varBinds >> belonging to the same SNMP packet always come in one and the >> same subagent-packet. > > Hmmm. This particular policy needs to be made real clear. > Some MIBs specify that certain objects must come in the same > Set request. The multistage process could satisfy that need > as long as the sub-agent keeps the right state along the way > and doesn't get order sensitive. It seems like it would be > easiest on the sub-agent if we required that all varbinds > from the same Set came in the same request. I agree. > Enforce the restriction once, in the master, rather than > having to handle a possible mess in every sub-agent. Yes. I would propose the following policy (strawman wording): 1. The subagent can assume that all varbinds for a SetRequest will arrive in a single SetRequest packet from the master agent. 2. The master agent will include all varbinds for a SetRequest in a single packet to the subagent. 3. *If* the AgentX protocol includes a mechanism by which a subagent can limit the number of varbinds it will accept in a single packet from the master agent, then when a SetRequest arrives from the management application with more than that number of varbinds for that subagent, then: a. Either, an error Response of ??? is returned to the management application; b. or, the assumption in #1 will be invalid (e.g., the master puts maxvarbinds at a time, in the order they appeared in the original SetRequest) into sequential SetRequests directed to the subagent); c. or, What? 4. Nothing needs to be stipulated in the respect for GetRequests since there should be no negative impact on the subagent from either approach (one-, some-, or all-at-a-time) and the marketplace will choose in favor of those master agents which do all-at-a-time, modulo possible considerations in #3. OTOH, I would support at a requirement or at least a strong recommendation that all GetRequest varbinds (again, modulo #3) be transmitted in a single AgentX packet to the subagent. Corrections/improvements? Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Thu, 21 Mar 1996 12:23:51 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id MAA25874 for X-agentx-local; Thu, 21 Mar 1996 12:23:50 -0800 (PST) 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 MAA25866 for ; Thu, 21 Mar 1996 12:23:49 -0800 (PST) Message-Id: <199603212023.MAA25866@zloty.fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1293; Thu, 21 Mar 96 15:23:22 EST Date: Thu, 21 Mar 96 21:23:04 CET From: "Bert Wijnen" To: agentx@fv.com Subject: 05: sysUpTime Gee... I thought let us get that sysUpTime agreed upon quickly. Uri writes: > > c.we include a DPI-RESET-SYSUPTIME packet > > I strongly dislike this solution, as it clearly disrupts all the > counters: some are related to restarted agent and were zeroed, > but some have been accumulating for a while. Now, sysUpTime > will claim everything's restarted [from zero?], but some > counters will be zeroed and some will keep incrementing! > > Is this a problem? I'm afraid it is. > It is NOT a problem. I agree that it disrupts all the management applications who are (regularly) polling to gather statistics. That is exactly why I claimed in the past that we should not worry about sysUpTime... alas, too many people thought we need to do this sysUpTime thing, so I am giving in. But a reset of sysUpTime does not require all counters to go to zero. A counter has no meaning by itself. It is only the difference between to GETs that has a meaning. Bert   Delivery-Date: Thu, 21 Mar 1996 12:33:52 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id MAA28309 for X-agentx-local; Thu, 21 Mar 1996 12:33:51 -0800 (PST) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id MAA28302 for ; Thu, 21 Mar 1996 12:33:50 -0800 (PST) Received: from flume.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA30684; Thu, 21 Mar 1996 15:23:28 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA10186; Thu, 21 Mar 1996 15:23:26 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA03473; Thu, 21 Mar 1996 15:23:58 -0500 Message-Id: <9603212023.AA03473@bernie.zk3.dec.com> To: agentx@fv.com Subject: 02: Architecture - Division of Labor Date: Thu, 21 Mar 96 15:23:57 -0500 From: Mike Daniele X-Mts: smtp Hi, Perhaps this kind of thing was intended for the "Modularity" bucket... I propose that all association of registered "subtrees" with actual MIB variables, reside in the subagents. A variable's OBJECT-TYPE and instantiation are solely the responsibility of the subagent, and are invisible to the master. I'm using "subtree" here to mean whatever we permit with the agentx registration syntax. It might be single oids, or ranges, etc. All the master agent will know how to do with these "subtrees" is handle overlaps etc. by a TBD policy, and lexi order them. (A subagent may indeed choose to register a fully qualified instance, but this "subtree" is no different to the master agent than any other.) My rationale is that this makes registration simple, makes the master agent simpler (and simpler to document in a standard), is a natural division of labor, and is implemented by at least 2 of the reference implementations. Regards, Mike   Delivery-Date: Thu, 21 Mar 1996 13:03:49 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id NAA05725 for X-agentx-local; Thu, 21 Mar 1996 13:03:48 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id NAA05722 for ; Thu, 21 Mar 1996 13:03:47 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA09837 for ; Thu, 21 Mar 96 15:30:16 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA08216; Thu, 21 Mar 1996 15:29:08 -0500 Date: Thu, 21 Mar 1996 15:31:45 EST From: Bob Natale Subject: Re: 05: sysUpTime To: Bert Wijnen Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Bert Wijnen > Date: Thu, 21 Mar 96 20:31:42 CET Hi Bert and Mike, <...very productive exchange of comments!...> >> In general, I thought we'd more or less concluded in L.A. that >> sysUpTime can never achieve the semantics implied by (broken) >> applications, and that this shouldn't really be an agent issue. >> >> Maybe I was dreaming... :-) >> MikeD > > I know that this was mentioned, but I don't think we had consensus > on that. If we did, the better. Then we would only do a. of my > previous e-mail, namely pass sysuptime in the response to a > DPI_OPEN. (BobN, can you call for consensus on any of these > ideas? or is that too early?). First, although I recall the outcome of this particular issue more or less as Mike reports it above, we cannot declare wg consensus on the basis of the f2f meetings. However, we had almost all the active participants at the LA meetings and the minutes have been posted for review. And this particular round of excellent technical interaction between you two on this issue is exposing everyone to some good options. So, I think we are headed toward a positive resolution of it, but it might be just a bit too soon to call for consensus. As I see it now, the major alternatives before us are: 1. Simple/Efficient/Limited: master passes sysUpTime in response to subagent's "open" operation...all (external) subagent time variables are sync'd with this value... counter discontinuities and the like are an app-level problem (no different from existing SNMPv1 and SNMPv2c). 2. Complex/Effective/Robust: master passes sysUpTime in response to subagent's "open" operation...all (external) subagent time variables are sync'd with this value... warmStart traps and/or additional (new) AgentX packet-types are used to signal counter discontinuities and other events which potentially impact sysUpTime integrity ...this approach may or may not be made more efficient via the inclusion of sysUpTime in each packet from the master. The foregoing summaries might not be literally perfect, but I think they reasonably characterize the major options. I know that many, many permutations of each could be devised...and everyone is free to propose his or her favorite. So, if you have an opinion, please express it asap. In the absence of further compelling arguments, I would maintain that something like #1 would hold, since that seemed to be the general expression at the LA meetings. Speaking as a technical contributor: It is my view that the behavior of a master agent as seen by an external management application has to be 100% as good as a totally conformant SNMPv2c (or bilingual) native agent. It need not be "better" than that and any such "better-ness" should not introduce transparency problems for management apps vis-a-vis those 100% good native agents. Between master and subagent, we can make the rules as tight as we want...but this is primarily an issue that concerns the view of the managed environment (notice how I'm avoiding the word "system" ;-) from the perspective of the management applications. So, in this role, I am in favor of a simple/efficient/limited solution. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Thu, 21 Mar 1996 13:04:25 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id NAA05902 for X-agentx-local; Thu, 21 Mar 1996 13:04:24 -0800 (PST) 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 NAA05895 for ; Thu, 21 Mar 1996 13:04:23 -0800 (PST) Message-Id: <199603212104.NAA05895@zloty.fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2247; Thu, 21 Mar 96 16:03:56 EST Date: Thu, 21 Mar 96 22:03:38 CET From: "Bert Wijnen" To: agentx@fv.com Subject: 13: Request/Response Dispatching BobN writes > I would propose the following policy (strawman wording): > > 1. The subagent can assume that all varbinds for > a SetRequest will arrive in a single SetRequest > packet from the master agent. > > 2. The master agent will include all varbinds for > a SetRequest in a single packet to the subagent. > > 3. *If* the AgentX protocol includes a mechanism by > which a subagent can limit the number of varbinds > it will accept in a single packet from the master > agent, then when a SetRequest arrives from the > management application with more than that number > of varbinds for that subagent, then: > > a. Either, an error Response of ??? is > returned to the management application; > > b. or, the assumption in #1 will be invalid > (e.g., the master puts maxvarbinds at a > time, in the order they appeared in the > original SetRequest) into sequential > SetRequests directed to the subagent); > > c. or, What? > I would say b. And I think we need to allow a sub-agent to specify that it wants only a limited (possibly only 1) varBind at a time. I would need it for compatibility for 90% of the current DPI implementations, but that of course can not be a mandatory reason for it. But I would love the possibility. > 4. Nothing needs to be stipulated in the respect > for GetRequests since there should be no > negative impact on the subagent from either > approach (one-, some-, or all-at-a-time) and > the marketplace will choose in favor of those > master agents which do all-at-a-time, modulo > possible considerations in #3. OTOH, I would > support at a requirement or at least a strong > recommendation that all GetRequest varbinds > (again, modulo #3) be transmitted in a single > AgentX packet to the subagent. > Well, maybe nothing is NEEDED for GetRequests, but if we do it for SET requests, then I'd say let us do it for GetRequests also. Just use on euniform way of doing the grouping of varBinds. Bert   Delivery-Date: Thu, 21 Mar 1996 13:13:52 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id NAA08549 for X-agentx-local; Thu, 21 Mar 1996 13:13:51 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id NAA08544 for ; Thu, 21 Mar 1996 13:13:50 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA10728 for ; Thu, 21 Mar 96 15:45:26 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA08496; Thu, 21 Mar 1996 15:44:18 -0500 Date: Thu, 21 Mar 1996 15:46:55 EST From: Bob Natale Subject: Re: Schedule guidance needed To: Mike Daniele Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Mike Daniele > Date: Thu, 21 Mar 96 14:53:17 -0500 Hi Mike, > >Apr 96 > > Post initial AgentX protocol I-D > > Anything posted in April will have many sections marked > "To Be Determined", That will be ok. > unless the 25 items are resolved much more quickly than > I think they will be. Not all 25 are necessarily problems that we have to resolve. Some are just "bookmarks" for general reference and some are "placeholders" for future items on the agenda. The pace of discussion so far has been as good as we could have expected and the technical caliber has been even better. Let's continue with an optimistic view. Also, it is acceptable for the initial draft to include "proposed" or "recommended" solutions to any outstanding problems...preferably acknowledged as such by the authors (you and Bert, with Dale's help as editor) or even left as an exercise for the workig group. > But there was general agreement to get "something" out > relatively soon to make discussion easier. Right...and I am sure it will be very good "something"! > So this seems ok. Great! > >May 96 > > Post revised AgentX protocol I-D > > I think we should produce an initial draft of the Agentx MIB > by this point. I'll accept your "seems ok" above, instead. :-) It is mildly unfortunate that the Montreal IETF occurs in June...when the next (San Jose) will be in December...(but not as unfortunate as the LA IETF occurring in early March exactly three months after the December (Dallas) meeting!). But, if the new schedule is approved, that will give us a good chunk of time to implement, interoperate, and refine the specs between the "final" versions in Montreal and the "released" versions after San Jose. You graciously accepted a working role in a working group that was, through no fault of yours, already somewhat behind the eight ball on schedule. Your continued effort and cooperation will be GREATLY appreciated. Ditto for Bert, Dale, Maria, and others. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Thu, 21 Mar 1996 13:17:44 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id NAA09990 for X-agentx-local; Thu, 21 Mar 1996 13:17:44 -0800 (PST) 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 NAA09974 for ; Thu, 21 Mar 1996 13:17:43 -0800 (PST) Message-Id: <199603212117.NAA09974@zloty.fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2551; Thu, 21 Mar 96 16:17:13 EST Date: Thu, 21 Mar 96 22:16:55 CET From: "Bert Wijnen" To: agentx@fv.com Subject: 05: SNMPv1/SNMPv2c support What is the issue here? The DPI 2.0 (on which we were going to base our work) allows a subagent to return data in SNMPv1 or SNMPv2 form. I did that because I still support subagents that were written back in the late 80s early 90s and we only had SNMPv1 back then. We now have RFC1902-1907 and so we can assume SNMPv2 (that is SMI, protocol, TC, conformance, etc)... Certainly by the time that we get agentX on the standards track (ultimo 96, right?). Of course, a master agent assures that a SNMPv1 manager can communicate with the v2-based subagents. I basically do that already in my DPI 2.0 implementations.... however we do need to solve how we will return convert a counter64... and maybe a few other items like what to do with context/naming scope and such. Is that what this item (05) is supposed to discuss? Anyway, I suggest we define the interface between (master)agent and subagent in terms of SNMPv2 (RFC1902-1907). That will make them SNMPv2 ready from the start too. Bert   Delivery-Date: Thu, 21 Mar 1996 13:14:10 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id NAA08660 for X-agentx-local; Thu, 21 Mar 1996 13:14:09 -0800 (PST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id NAA08655 for ; Thu, 21 Mar 1996 13:14:08 -0800 (PST) Received: from flume.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA14087; Thu, 21 Mar 1996 16:01:44 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA28967; Thu, 21 Mar 1996 16:01:57 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA03527; Thu, 21 Mar 1996 16:02:28 -0500 Message-Id: <9603212102.AA03527@bernie.zk3.dec.com> To: Bob Natale Cc: agentx@fv.com Subject: Re: 13: Request/Response Dispatching In-Reply-To: Your message of "Thu, 21 Mar 96 15:00:39 EST." Date: Thu, 21 Mar 96 16:02:27 -0500 From: Mike Daniele X-Mts: smtp Hi Bob, >Corrections/improvements? As Randy pointed out, there was no reason brought forth in L.A. why agentx should support a notion of "max number of varbinds per packet". As we discussed, the reason this might be useful is if the pipe between master and subagent is smaller than the pipe between manager and agent. This seems unlikely to me... I'd like to counter propose this: "All VarBinds associated with a subagent, and only those VarBinds, are passed in a single request Pdu to that subagent." Thoughts? Regards, Mike   Delivery-Date: Thu, 21 Mar 1996 13:22:32 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id NAA11942 for X-agentx-local; Thu, 21 Mar 1996 13:22:31 -0800 (PST) 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 NAA11935 for ; Thu, 21 Mar 1996 13:22:28 -0800 (PST) Message-Id: <199603212122.NAA11935@zloty.fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2655; Thu, 21 Mar 96 16:22:00 EST Date: Thu, 21 Mar 96 22:21:40 CET From: "Bert Wijnen" To: agentx@fv.com Subject: 22: agentX MIB(s) Just for those who have never seen it. In the IBM DPI 2.0 implementations I have included a so called subagent MIB named saMIB. Looking back at it and the experience we have with it, I must say that I think it has too many items in it. I must also say that most of it we have only used (sofar) to check the status of subagents and registerd subtrees/objects when we were debugging an agent/subagent pair. But here is that MIB as a starting point. -- the SUBAGENT MIB -- The MIB objects are implemented by the master SNMP agent -- This MIB is based on some experience with both DPI and SMUX -- subagents. As you can see, some of the ideas come from the -- original SMUX MIB (RFC1227) by Marshall Rose. -- We try to define a subagent MIB that represents subagents -- using different protocols. SUBAGENT-MIB DEFINITIONS ::= BEGIN IMPORTS enterprises, TimeTicks, Counter FROM RFC1155-SMI OBJECT-TYPE FROM RFC-1212 DisplayString FROM RFC1213-MIB; ibm OBJECT IDENTIFIER ::= { enterprises 2 } ibmResearch OBJECT IDENTIFIER ::= { ibm 4 } saMIB OBJECT IDENTIFIER ::= { ibmResearch 12 } -- -- Following can be used once we fit into SNMPv2 -- -- MODULE-IDENTITY, OBJECT-TYPE, snmpModules -- FROM SNMPv2-SMI -- -- saMIB MODULE-IDENTITY -- LAST-UPDATED "9403200000Z" -- ORGANIZATION "IBM Research - T.J. Watson Research Center" -- CONTACT-INFO -- " Bert Wijnen -- -- Postal: IBM International Operations -- Watsonweg 2 -- 1423 ND Uithoorn -- The Netherlands -- -- Tel: +31 348-412-498 -- Fax: none -- -- E-mail: wijnen@vnet.ibm.com -- (IBM internal: wijnen at uitvm1)" -- DESCRIPTION -- "The MIB module describing SNMP subagents." -- ::= { snmpModules x } saDefaultTimeout OBJECT-TYPE SYNTAX INTEGER -- (1..saMaxTimeout) -- UNITS "seconds" ACCESS read-write STATUS mandatory DESCRIPTION "The default timeout (in seconds) that this agent waits for a response from a SubAgent. This value is used if a timeout value is not specified for the subtree nor for the subagent that exports the subtree." -- DEFVAL { 5 } ::= { saMIB 1 } saMaxTimeout OBJECT-TYPE SYNTAX INTEGER (1..3600) -- 3600 is 60 minutes, -- so quite big already -- UNITS "seconds" ACCESS read-write STATUS mandatory DESCRIPTION "The maximum timeout (in seconds) that this agent allows for timeout values for SubAgents. When you try to set any other timeout value it must be between 1 and this maximum value." -- DEFVAL { 60 } ::= { saMIB 2 } saAllowDuplicateIDs OBJECT-TYPE SYNTAX INTEGER { yes(1), no(2) } ACCESS read-write STATUS mandatory DESCRIPTION "Controls if multiple instances of a sub-agent (as identified by the sub-agent Identifier) are allowed. Setting this object to the value no(2) will prevent (new) duplicate sub-agentIDs. However, if any duplicates exist at that point in time, the agent will not remove them. That is considered a manager responsibility." -- DEFVAL { yes } ::= { saMIB 3 } saNumber OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "The number of entries in the saTable" ::= { saMIB 4 } saAllPacketsIn OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count of packets received from all subagents." ::= { saMIB 5 } saAllPacketsOut OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count of packets send to all subagents." ::= { saMIB 6 } saTable OBJECT-TYPE SYNTAX SEQUENCE OF SaEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The SubAgent table, listing all subagents." ::= { saMIB 7 } saEntry OBJECT-TYPE SYNTAX SaEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An entry in the SubAgent table." INDEX { saIndex } ::= { saTable 1 } SaEntry ::= SEQUENCE { saIndex INTEGER, saIdentifier OBJECT IDENTIFIER, saDescription DisplayString, saStatus INTEGER, saStatusChangeTime TimeTicks, saProtocol INTEGER, saProtocolVersion INTEGER, saProtocolRelease INTEGER, saTransport INTEGER, saTransportAddress OCTET STRING, saTimeout INTEGER, saMaxVarBinds INTEGER, saPacketsIn Counter, saPacketsOut Counter } saIndex OBJECT-TYPE SYNTAX INTEGER (1..4294967295) ACCESS read-only STATUS mandatory DESCRIPTION "An index which uniquely identifies a SubAgent. The number is in the range from 1 up to and including the value of saNumber." ::= { saEntry 1 } saIdentifier OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "The authoritative identification for a SubAgent." ::= { saEntry 2 } saDescription OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "A descriptive name for a SubAgent." ::= { saEntry 3 } saStatus OBJECT-TYPE SYNTAX INTEGER { valid(1), invalid(2), connecting(3), disconnecting(4), closedByManager(5), closedByAgent(6), closedBySubAgent(7), closedBySubAgentTimeout(8), closedBySubAgentError(9) } ACCESS read-write STATUS mandatory DESCRIPTION "The status of the SubAgent. The only value that can be set is invalid(2). This can only be done if the status is not already in a ClosedSomething status. Setting this object to the value invalid(2) has the effect of invalidating the entry upon which the agent will close the connection and turn it to status closedByManager(7). It is an implementation specific matter if an entry that is not valid(1) is removed from the table. However, if such an entry is kept and the subagent re-connects, then the same entry must be re-used." ::= { saEntry 4 } saStatusChangeTime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION "The timestamp of the last status change of the SubAgent. Timestamp is taken from the sysUpTime." ::= { saEntry 5 } saProtocol OBJECT-TYPE SYNTAX INTEGER { dpi(1), -- SNMP DPI, RFC 1228 & 1592 moh(2), -- SNMP MIB Object Handler smux(3) -- SNMP MUX, RFC 1227 } ACCESS read-only STATUS mandatory DESCRIPTION "The SubAgent protocol being used." ::= { saEntry 6 } saProtocolVersion OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The version of the SubAgent Protocol used." ::= { saEntry 7 } saProtocolRelease OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The release of the SubAgent Protocol used." ::= { saEntry 8 } saTransport OBJECT-TYPE SYNTAX INTEGER { udp(1), -- User Datagram tcp(2), -- Transmission Control nmq(3), -- Named Queue sna(4) -- IBM SNA } ACCESS read-only STATUS mandatory DESCRIPTION "The transport protocol used by the SubAgent." ::= { saEntry 9 } saTransportAddress OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "The address of the subagent (transport specific address information)." -- IPaddress, Portnumber for UDP and TCP -- DisplayString for Named Queue -- DisplayString for SNA (LU-name) ::= { saEntry 10 } saTimeout OBJECT-TYPE SYNTAX INTEGER -- (1..saMaxTimeout) -- UNITS "seconds" ACCESS read-write STATUS mandatory DESCRIPTION "The default timeout (seconds) for a SubAgent response. This value will be used if there is no timeout value specified for a particular subtree." -- DEFVAL { 0 } ::= { saEntry 11 } saMaxVarBinds OBJECT-TYPE SYNTAX INTEGER (0..4294967295) ACCESS read-only STATUS mandatory DESCRIPTION "Max varBinds this subagent accepts per request." ::= { saEntry 12 } saPacketsIn OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count of packets received from this subagent." ::= { saEntry 13 } saPacketsOut OBJECT-TYPE SYNTAX Counter ACCESS read-only STATUS mandatory DESCRIPTION "A count of packets send to this subagent." ::= { saEntry 14 } saTreeTable OBJECT-TYPE SYNTAX SEQUENCE OF SaTreeEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "The SubAgent tree table." ::= { saMIB 8 } saTreeEntry OBJECT-TYPE SYNTAX SaTreeEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An entry in the SubAgent tree table." INDEX { saTsubtree, saTpriority } ::= { saTreeTable 1 } SaTreeEntry ::= SEQUENCE { saTsubtree OBJECT IDENTIFIER, saTpriority INTEGER, saTindex INTEGER, saTstatus INTEGER, saTtimeout INTEGER } saTsubtree OBJECT-TYPE SYNTAX OBJECT IDENTIFIER ACCESS read-only STATUS mandatory DESCRIPTION "The MIB subtree being exported by the SubAgent." ::= { saTreeEntry 1 } saTpriority OBJECT-TYPE SYNTAX INTEGER (0..'7fffffff'h) ACCESS read-only STATUS mandatory DESCRIPTION "The SubAgents Priority when exporting the MIB subtree. The lower the value the better the priority." ::= { saTreeEntry 2 } saTindex OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The SubAgent's identity (index into the saTable)." ::= { saTreeEntry 3 } saTstatus OBJECT-TYPE SYNTAX INTEGER { valid(1), -- registered, active entry invalid(2), -- invalid, unregistered waiting(3) -- registered, waiting cause -- higher priority entry is -- valid/active now } ACCESS read-write STATUS mandatory DESCRIPTION "The status of subtree exported by the SubAgent. The only value that can be set is invalid(2). Setting this object to the value invalid(2) has the effect of invalidating the entry. It is an implementation specific matter if an entry that is not valid(1) or waiting(3) is removed from the table." ::= { saTreeEntry 4 } saTtimeout OBJECT-TYPE SYNTAX INTEGER -- (1..saMaxTimeout) -- UNITS "seconds" ACCESS read-write STATUS mandatory DESCRIPTION "The timeout (in seconds) for objects in this subtree. A value of zero (0) means that the overall timeout value (as specified in the saTableEntry for the SubAgent) will be used." -- DEFVAL { 0 } ::= { saTreeEntry 5 } END   Delivery-Date: Thu, 21 Mar 1996 13:26:46 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id NAA13110 for X-agentx-local; Thu, 21 Mar 1996 13:26:46 -0800 (PST) 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 NAA13104 for ; Thu, 21 Mar 1996 13:26:45 -0800 (PST) Message-Id: <199603212126.NAA13104@zloty.fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2774; Thu, 21 Mar 96 16:26:16 EST Date: Thu, 21 Mar 96 22:25:58 CET From: "Bert Wijnen" To: agentx@fv.com Subject: 25: Manager App Interface Two subitems were listed here. - Transparency I think this comes automatic with the reuirement that we need to be as compliant as if we were a monolithic agent. - Disclosure Not sure what you mean here. Do you mean that we (optionally) want to disclose info about subagents to the manager application? Then that falls under the agentX MIB(s) I would say? So I think both points are addressed under other headings. Is there anything else in this area? Bert   Delivery-Date: Thu, 21 Mar 1996 14:01:14 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id OAA21619 for X-agentx-local; Thu, 21 Mar 1996 14:01:14 -0800 (PST) Received: from seymour16.snmp.com (seymour16.snmp.com [192.147.142.16]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id OAA21611 for ; Thu, 21 Mar 1996 14:01:12 -0800 (PST) Received: by seymour16.snmp.com (5.61++/2.8s-SNMP) id AA18319; Thu, 21 Mar 96 17:01:02 -0500 Date: Thu, 21 Mar 96 17:01:02 -0500 From: David Battle Message-Id: <9603212201.AA18319@seymour16.snmp.com> To: agentx@fv.com Subject: 05: sysUpTime > I strongly dislike this solution, as it clearly disrupts all the > counters: some are related to restarted agent and were zeroed, > but some have been accumulating for a while. Now, sysUpTime > will claim everything's restarted [from zero?], but some > counters will be zeroed and some will keep incrementing! > > Is this a problem? I'm afraid it is. No, it's not a problem. Counters aren't guaranteed to start at 0. If a manager sees a negative offset in sysUpTime it merely retrieves new base-line values for all the counters it's interested in. -David   Delivery-Date: Thu, 21 Mar 1996 14:03:09 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id OAA22110 for X-agentx-local; Thu, 21 Mar 1996 14:03:09 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id OAA22102 for ; Thu, 21 Mar 1996 14:03:08 -0800 (PST) Message-Id: <199603212203.AA002135826@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA002135826; Thu, 21 Mar 1996 14:03:46 -0800 Date: Thu, 21 Mar 1996 14:03:46 -0800 From: Randy Presuhn To: agentx@fv.com Subject: Re: 05: sysUpTime Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > Date: Thu, 21 Mar 96 18:03:24 CET > From: "Bert Wijnen" > To: agentx@fv.com > Subject: 05: sysUpTime > > I propose we do this: > a.in the reponse to DPI-OPEN we pass the current sysUpTime (in > units of TimeTicks, e.g. 100ths of a second). > This allows subagents to sync up any timers they may > need to support. There may be a different sysUpTime for each naming scope supported by a master agent. There are two ways of modifying Bert's proposal to handle this: 1) explicitly limit a single subagent association to a single naming scope 2) return the time base for a naming scope with the response to a registration request for that scope (assuming registration and operation pdus are extended to include naming scope selection) I prefer alternative (2). Alternative (1) tends to burn resources unnecessarily, but does not reduce the complexity of the master agent or of the subagent. > b.whenever a sub-agent disconnects or unregisters anything we > reset sysUpTime with a warmStart trap > (No, I don't like this, but this is the only way I think to > live up to the semantics of sysUpTime and to ensure that > we implicitly reset sysUpTime if counter discontinuities > (may) occur... but we need more, see next I fear this would do more harm than good. > c.we include a DPI-RESET-SYSUPTIME packet > (Again, I don't like it, but we need it to allow a subagent to > reset sysUpTime when a counter discontinuity occurs) > When the (master) agent receives this, it resets sysUpTime and > sends a warmStart trap. ... This is more attractive than (b), but should be modified to identify the naming scopy to which the reset applies. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Thu, 21 Mar 1996 14:09:52 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id OAA23639 for X-agentx-local; Thu, 21 Mar 1996 14:09:51 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id OAA23622 for ; Thu, 21 Mar 1996 14:09:48 -0800 (PST) Message-Id: <199603212210.AA002296223@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA002296223; Thu, 21 Mar 1996 14:10:23 -0800 Date: Thu, 21 Mar 1996 14:10:23 -0800 From: Randy Presuhn To: agentx@fv.com Subject: Re: 05: sysUpTime Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > Message-Id: <9603211754.AA03436@bernie.zk3.dec.com> > To: "Bert Wijnen" > Cc: agentx@fv.com > Subject: Re: 05: sysUpTime > In-Reply-To: Your message of "Thu, 21 Mar 96 18:03:24 +0700." <199603211704.JAA06957@zloty.fv.com> > Date: Thu, 21 Mar 96 12:54:00 -0500 > From: Mike Daniele ... > > c.we include a DPI-RESET-SYSUPTIME packet > > (Again, I don't like it, but we need it to allow a subagent to > > reset sysUpTime when a counter discontinuity occurs) > > When the (master) agent receives this, it resets sysUpTime and > > sends a warmStart trap. > > But this leaves all other subagents synching against the old value > of sysUpTime? Doing things like this does require a mechanism to notify subagents of discontinuitues for all affected naming scopes. > In general, I thought we'd more or less concluded in L.A. that > sysUpTime can never achieve the semantics implied by (broken) > applications, and that this shouldn't really be an agent issue. > > Maybe I was dreaming... :-) That was my recollection as well. Attached is an old message on this topic from Joey de Wiele that bears re-reading: |From uunet!lists.psi.com!snmp-forw Fri Aug 12 15:21:40 1994 |Return-Path: |Date: Wed, 10 Aug 1994 17:40:00 -0400 |From: "joey (j.h.) de wiele" |To: uunet!attmail.com!dherington |Cc: uunet!psi.com!snmp |Subject: Re: SNMP DPI (RFC1592) and sysUpTime requirements. | |In message "Re: SNMP DPI (RFC1592) and sysUpTime requirements.", |'dherington@attmail.com' writes: | |>I have another question. Are there many tools out there that actually |>use sysUpTime in calculations? I though it was more common to take the |>delta between two consecutive queries and do calculations on that delta. | |The above is a good point. | |I subscribe to the heretical view that resetting sysUptime every single |time that there is a discontinuity in any Counter is absurd. | |Doing this means that any application monitoring ANY Counter and using |sysUpTime will experience a discontinuity in its processing, mostly needlessly, |anytime any other Counter gets foobarred. This is true whether |the application uses deltas, which has been suggested by some in this group, |and represents the only way to get any sort of real figures if your Counters |do not reset when sysUptime is reset (noone says this is a requirement), or |if it divides by the current value of sysUptime. | |Let's look at all the bad things that can happen if we do not reset |sysUptime. If a Counter is reset due to a card being reset, the |Counter will have a lower value than its previous reading. I hope that |Managers should be able to figure this one out. Isn't the Manager supposed |to be the smart one? | |What happens if the value remains the same following the reset. Oh my God, |we will get an incorrect value for one polling period! Anyone using Counters |for billing? But wait, if we set sysUptime to 0, then all values for that |polling period need to be trashed! | |I am also extremely skeptical that most agents send cold starts and reset |sysUptime every time any card or Counter gets reset, I just don't believe |it. | |If you have a multi-processor or distributed environment then it is |extremely difficult to coordinate sysUptime amongst all of the individual |processes. Why should an Agent do this to make life easier for dumb |Managers? What happened to the SNMP philosophy? | |What about MIBs that use sysUptime as a timestamp? What about ifLastChange? |Why bother if sysUptime is being reset regularly as dynamic applications |come and go? | |And it does not say anywhere in the rfc's that "sysUptime must be reset |whenever any Counter experiences a discontinuity". Period. (I've noticed |that if you say "Period" then the preceding clause is mandatorily true). |Some people *interpret* the standard to mean this, but I don't see it and I |don't believe it. | |I am amazed at these "If your Agent does not reset sysUptime when |a Counter experiences a discontinuity, your Agent is not SNMP compliant" |statements. | |I could go on about the obvious semantics of a variable "system uptime" |having nothing to do with the reset of individual Counters, but rather |meaning the time that the "system/agent" has been up, but why bother? | |After all, this discussion has degenerated into talk of crucibles full of |molten lead pouring all over hordes of factory workers. I am now waiting for |the nuclear war to start because SNMP is in control and some Counters have |unknowingly been reset. | |In summary: | 1. Resetting sysUptime anytime that a Counter experiences a discontinuity | is absurd. It is difficult to implement on the Agent side, screws up all | other ongoing calculations, and is easy for a Manager to work around. | 2. Managers should be able to "work around" problems with Counters some | other way, and by this I mean not crap out. In this I believe that | some small number of invalid interval counts are not a big problem. I | don't believe that they are ANY problem. | 3. Do not bombard me with pathological conditions where a Manager must | know that some count is screwed. If you have crucibles full of molten lead | or nuclear warheads on hold or some such thing, get your MIB right. | sysUptime isn't the answer. | |By the way, I do believe that Master Agent/Sub Agents are here and the |number of implementations using this sort of approach will grow. I believe |the time is here to rethink the whole system group to deal with this |reality, Maniacally clinging to interpretations appropriate only for |so-called monolithic agents running on simple single processor systems is |doing a horrible disservice to those of us that have vastly more complex |systems to deal with. | |Joey ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Thu, 21 Mar 1996 14:36:57 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id OAA00471 for X-agentx-local; Thu, 21 Mar 1996 14:36:56 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id OAA00466 for ; Thu, 21 Mar 1996 14:36:55 -0800 (PST) Message-Id: <199603212237.AA004007852@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA004007852; Thu, 21 Mar 1996 14:37:32 -0800 Date: Thu, 21 Mar 1996 14:37:32 -0800 From: Randy Presuhn To: agentx@fv.com Subject: Re: 13: Request/Response Dispatching Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > Date: Thu, 21 Mar 1996 15:00:39 EST > From: Bob Natale > Subject: 13: Request/Response Dispatching > To: agentx@fv.com > Message-Id: ... > 1. The subagent can assume that all varbinds for > a SetRequest will arrive in a single SetRequest > packet from the master agent. good. this simplifies things. > 2. The master agent will include all varbinds for > a SetRequest in a single packet to the subagent. this is ambiguously worded. (the ambiguities are latent in (1), more serious here.) I hope the intent was: for all subagents: from an SNMP set request, the non-empty subset of those varbinds for which that subagent is responsible is dispatched to that subagent in a single subagent PDU I hope we can agree: in processing a set (or simple get) operation, a master agent will not send varbinds to a subagent for which that subagent has not claimed responsibility. > 3. *If* the AgentX protocol includes a mechanism by > which a subagent can limit the number of varbinds > it will accept in a single packet from the master I do not see this as a requirement. It increases both master agent and subagent complexity, with no real benefits. > agent, then when a SetRequest arrives from the > management application with more than that number > of varbinds for that subagent, then: > > a. Either, an error Response of ??? is > returned to the management application; The decision can be made at the subagent level, handling it like any other "tooBig" case. > b. or, the assumption in #1 will be invalid > (e.g., the master puts maxvarbinds at a > time, in the order they appeared in the > original SetRequest) into sequential > SetRequests directed to the subagent); This item (b) seems to combine the worst of all worlds. > c. or, What? Let's drop this non-requirement. > 4. Nothing needs to be stipulated in the respect > for GetRequests since there should be no > negative impact on the subagent from either > approach (one-, some-, or all-at-a-time) and > the marketplace will choose in favor of those > master agents which do all-at-a-time, modulo > possible considerations in #3. OTOH, I would > support at a requirement or at least a strong > recommendation that all GetRequest varbinds > (again, modulo #3) be transmitted in a single > AgentX packet to the subagent. By removing the need for varbind count negotiation from the protocol, we get a substantial improvement in simplicity. Once the infrastructure to handle multiple varbinds is in place for SET processing, there's even less of a need for supporting one-at-a-time imoplementations for GET and GET-NEXT. Let's keep it simple: for GET processing, for all subagents: from an SNMP get request, the non-empty subset of those varbinds for which that subagent is responsible is dispatched to that subagent in a single subagent PDU Unfortunately, we can make no such promises with GET-NEXT and GET-BULK, especially if fine-grained access control mechanisms are in place. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Thu, 21 Mar 1996 14:40:06 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id OAA01295 for X-agentx-local; Thu, 21 Mar 1996 14:40:04 -0800 (PST) Received: from mail.sharplabs.com ([204.75.175.200]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id OAA01243 for ; Thu, 21 Mar 1996 14:40:01 -0800 (PST) Received: from sla5c by mail.sharplabs.com (SMI-8.6/SMI-SVR4) id OAA04646; Thu, 21 Mar 1996 14:37:05 -0800 From: rturner@mail.sharplabs.com (Randy Turner) Received: by sla5c (SMI-8.6) id OAA04044; Thu, 21 Mar 1996 14:36:59 -0800 Date: Thu, 21 Mar 1996 14:36:59 -0800 Message-Id: <199603212236.OAA04044@sla5c> To: agentx@fv.com Subject: Re: 13: Request/Response Dispatching Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: Ay3NNP/axYu7gV5AuhpvVg== > From daniele@zk3.dec.com Thu Mar 21 13:37:27 1996 > Resent-From: agentx-owner@fv.com > Comment: Posted to the agentx Mailing List To unsubscribe, send mail to agentx-request@fv.com with "unsubscribe" in the Subject > Resent-Date: Thu, 21 Mar 1996 13:20:56 -0800 > Resent-Message-ID: <8669.827443256.1@fv.com> > To: Bob Natale > Cc: agentx@fv.com > Subject: Re: 13: Request/Response Dispatching > Date: Thu, 21 Mar 96 16:02:27 -0500 > From: Mike Daniele > X-Suppressed-X-Mts: smtp > > Hi Bob, > > >Corrections/improvements? > > As Randy pointed out, there was no reason brought forth > in L.A. why agentx should support a notion of > "max number of varbinds per packet". > > As we discussed, the reason this might be useful > is if the pipe between master and subagent is smaller than the > pipe between manager and agent. This seems unlikely to me... I think it would be very presumptious to equate the transport capabilities between NMS and master to be the same as master<-->subagent. Can we not include some type of subagent capabilities negotiation during the "open" process? > > I'd like to counter propose this: > > "All VarBinds associated with a subagent, and only those VarBinds, > are passed in a single request Pdu to that subagent." > > Thoughts? > > Regards, > Mike > > ================ > 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: Thu, 21 Mar 1996 14:45:39 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id OAA02760 for X-agentx-local; Thu, 21 Mar 1996 14:45:39 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id OAA02733 for ; Thu, 21 Mar 1996 14:45:36 -0800 (PST) Message-Id: <199603212246.AA004398371@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA004398371; Thu, 21 Mar 1996 14:46:11 -0800 Date: Thu, 21 Mar 1996 14:46:11 -0800 From: Randy Presuhn To: agentx@fv.com Subject: Re: 13: Request/Response Dispatching Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > Message-Id: <9603212102.AA03527@bernie.zk3.dec.com> > To: Bob Natale > Cc: agentx@fv.com > Subject: Re: 13: Request/Response Dispatching > In-Reply-To: Your message of "Thu, 21 Mar 96 15:00:39 EST." > Date: Thu, 21 Mar 96 16:02:27 -0500 > From: Mike Daniele ... > I'd like to counter propose this: > > "All VarBinds associated with a subagent, and only those VarBinds, > are passed in a single request Pdu to that subagent." > > Thoughts? Well put. I agree with this for the GET and SET cases. It's too strong for GET-NEXT or GET-BULK. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Thu, 21 Mar 1996 14:50:13 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id OAA04060 for X-agentx-local; Thu, 21 Mar 1996 14:50:12 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id OAA04011 for ; Thu, 21 Mar 1996 14:50:10 -0800 (PST) Message-Id: <199603212250.AA004698644@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA004698644; Thu, 21 Mar 1996 14:50:44 -0800 Date: Thu, 21 Mar 1996 14:50:44 -0800 From: Randy Presuhn To: agentx@fv.com, wijnen@vnet.ibm.com Subject: Re: 05: SNMPv1/SNMPv2c support Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > Message-Id: <199603212117.NAA09974@zloty.fv.com> > Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2551; Thu, 21 Mar 96 16:17:13 EST > Date: Thu, 21 Mar 96 22:16:55 CET > From: "Bert Wijnen" > To: agentx@fv.com > Subject: 05: SNMPv1/SNMPv2c support do we have two issue 05s? ... > Anyway, I suggest we define the interface between (master)agent and > subagent in terms of SNMPv2 (RFC1902-1907). That will make them > SNMPv2 ready from the start too. ... Sounds good to me. It still needs to be able to carry the "obsolete" error codes and data types, but I agree the focus should be on v2. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Thu, 21 Mar 1996 14:53:21 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id OAA04853 for X-agentx-local; Thu, 21 Mar 1996 14:53:21 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id OAA04847 for ; Thu, 21 Mar 1996 14:53:19 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA17047 for ; Thu, 21 Mar 96 17:32:25 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA10095; Thu, 21 Mar 1996 17:31:16 -0500 Date: Thu, 21 Mar 1996 17:33:54 EST From: Bob Natale Subject: Re: 25: Manager App Interface To: Bert Wijnen Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Bert Wijnen > Date: Thu, 21 Mar 96 22:25:58 CET Hi Bert, Darn, this one's so good I kinda wish it were Friday and I'd just answer and head for home with a happy heart! > Two subitems were listed here. Btw, all the "subitems" on the list are just "ticklers"... not meant to be exclusive of others, can be moved to other categories, can be dropped/ignored, etc. > - Transparency > I think this comes automatic with the reuirement that > we need to be as compliant as if we were a monolithic > agent. Right. This is just the informal issue-list recognition of the requirement. I don't think we have any doubts/problems as a wg on this one. > - Disclosure > Not sure what you mean here. Do you mean that we > (optionally) want to disclose info about subagents > to the manager application? Exactly. > Then that falls under the agentX MIB(s) I would say? That is perfectly fine with me. > So I think both points are addressed under other headings. Ok. (Transparency under "Architecture" and Disclosure under AgentX MIB(s).) > Is there anything else in this area? Maybe not. (Check another one off, Mike! :-) We'll see. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Thu, 21 Mar 1996 14:57:34 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id OAA05895 for X-agentx-local; Thu, 21 Mar 1996 14:57:34 -0800 (PST) Received: from mail.sharplabs.com ([204.75.175.200]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id OAA05884 for ; Thu, 21 Mar 1996 14:57:31 -0800 (PST) Received: from sla5c by mail.sharplabs.com (SMI-8.6/SMI-SVR4) id OAA04662; Thu, 21 Mar 1996 14:54:35 -0800 From: rturner@mail.sharplabs.com (Randy Turner) Received: by sla5c (SMI-8.6) id OAA04058; Thu, 21 Mar 1996 14:54:30 -0800 Date: Thu, 21 Mar 1996 14:54:30 -0800 Message-Id: <199603212254.OAA04058@sla5c> To: agentx@fv.com Subject: Re: 22: agentX MIB(s) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: vfwlaz2e17+aDNhU07DtlA== It seems to me that the "debugging and verification" of subagent functionality is really the primary rationale for the development and support of a subagent MIB. That in the real world, we are striving for transparency and that creating a subagent MIB and publishing it would mean that we are now exposing the existence of the subagent(s) to the network administrator, and that he/she would have to understand the agent<-->subagent model in order to properly "manage" the agentx functionality. Using the MIB for debugging and verification of subagent status would be very helpful, but only for developers. But as a fundamental idea, the MIB seems to fly in the face of the requirment for transparency. Just a thought.... Randy   Delivery-Date: Thu, 21 Mar 1996 14:59:51 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id OAA06340 for X-agentx-local; Thu, 21 Mar 1996 14:59:50 -0800 (PST) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.139.6]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id OAA06335 for ; Thu, 21 Mar 1996 14:59:49 -0800 (PST) Received: from hawpub.watson.ibm.com ([9.2.90.19]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id RAA12066 for ; Thu, 21 Mar 1996 17:59:50 -0500 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/2/16/96) id AA36091; Thu, 21 Mar 1996 17:59:40 -0500 Message-Id: <9603212259.AA36091@hawpub.watson.ibm.com> Subject: Re: 05: sysUpTime To: wijnen@vnet.ibm.com (Bert Wijnen) Date: Thu, 21 Mar 1996 17:59:40 -0500 (EST) From: "Uri Blumenthal" Cc: agentx@fv.com In-Reply-To: <199603212023.MAA25866@zloty.fv.com> from "Bert Wijnen" at Mar 21, 96 09:23:04 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Bert Wijnen says: > Gee... I thought let us get that sysUpTime agreed upon quickly. Keep wishing (:-). > > .......Now, sysUpTime will claim everything's restarted > > [from zero?], but some counters will be zeroed and some > > will keep incrementing! ......... Is this a problem? > > It is NOT a problem. I agree that it disrupts all the management > applications who are (regularly) polling to gather statistics. Well, why then reset sysUpTime at all? All that gets screwed up is statistics gathered? > That is exactly why I claimed in the past that we should not > worry about sysUpTime... alas, too many people thought we need > to do this sysUpTime thing, so I am giving in. I'd prefer [as I said in the past :-] that every subagent-related object or group should have it's own UpTime, because it's clear that one "central" sysUpTime is not enough to deal with several asynchronous entities (subagents) that come and go... > But a reset of sysUpTime does not require all counters to go to zero. > A counter has no meaning by itself. It is only the difference between > to GETs that has a meaning. I'm missing something. Some counters got "zeroed" and you want to recognize it by resetting sysUptime. Some other counters will get messed up by that resetting, but you don't care? Why bother then resetting sysUpTime at all? What is it going to tell you? What is it telling you now? -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Thu, 21 Mar 1996 15:06:09 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id PAA08133 for X-agentx-local; Thu, 21 Mar 1996 15:06:09 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id PAA08128 for ; Thu, 21 Mar 1996 15:06:07 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA17672 for ; Thu, 21 Mar 96 17:44:18 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA10261; Thu, 21 Mar 1996 17:43:09 -0500 Date: Thu, 21 Mar 1996 17:45:48 EST From: Bob Natale Subject: Re: 05: SNMPv1/SNMPv2c support To: Bert Wijnen Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Bert Wijnen > Date: Thu, 21 Mar 96 22:16:55 CET Hi Bert, > What is the issue here? None, I hope. But see below. > The DPI 2.0 (on which we were going to base our work) allows a > subagent to return data in SNMPv1 or SNMPv2 form. I did that because > I still support subagents that were written back in the late 80s early > 90s and we only had SNMPv1 back then. Ok...AgentX subagents will be completely new animals. > We now have RFC1902-1907 and so we can assume SNMPv2 (that is SMI, > protocol, TC, conformance, etc)... Certainly by the time that we > get agentX on the standards track (ultimo 96, right?). I hope so (on both counts). > Of course, a master agent assures that a SNMPv1 manager can communicate > with the v2-based subagents. I basically do that already in my DPI 2.0 > implementations.... however we do need to solve how we will > return convert a counter64... and maybe a few other items like > what to do with context/naming scope and such. > Is that what this item (05) is supposed to discuss? It can be. On the other hand, we could say that whether and how a master agent is bilingual wrt mangement applications is left as an implementation choice...since it will (should) have no impact on the master<->subagent AgentX protocol exchanges. > Anyway, I suggest we define the interface between (master)agent and > subagent in terms of SNMPv2 (RFC1902-1907). That will make them > SNMPv2 ready from the start too. Speaking as a technical contributor: Yes, I agree with this completely, unequivocally, and whole-heartedly. I think this is/should be an architectural requirement of the same caliber as "transparency". Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Thu, 21 Mar 1996 15:08:00 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id PAA08570 for X-agentx-local; Thu, 21 Mar 1996 15:07:59 -0800 (PST) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.139.6]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id PAA08564 for ; Thu, 21 Mar 1996 15:07:58 -0800 (PST) Received: from hawpub.watson.ibm.com ([9.2.90.19]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id SAA10778; Thu, 21 Mar 1996 18:07:59 -0500 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/2/16/96) id AA29816; Thu, 21 Mar 1996 18:07:49 -0500 Message-Id: <9603212307.AA29816@hawpub.watson.ibm.com> Subject: Re: 13: Request/Response Dispatching To: natale@acec.com (Bob Natale) Date: Thu, 21 Mar 1996 18:07:48 -0500 (EST) From: "Uri Blumenthal" Cc: agentx@fv.com In-Reply-To: from "Bob Natale" at Mar 21, 96 03:00:39 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Bob Natale says: > Yes. I would propose the following policy (strawman wording): > > 1. The subagent can assume that all varbinds for > a SetRequest will arrive in a single SetRequest > packet from the master agent. > 2. The master agent will include all varbinds for > a SetRequest in a single packet to the subagent. This is bad, as: - you're forcing a subagent to deal with multiple varBinds, which not all the sub's are willing to. - as you point yourself, if the number of varBinds in a request is greater than what a sub' can handle, you got a problem. I prefer thus an extra phase in Set. > 3. *If* the AgentX protocol includes a mechanism by > which a subagent can limit the number of varbinds A subagent might not have room available to deal with "unlimited" number of varBinds! Think small, like sub-on-a-card (or a chip! :-). > a. Either, an error Response of ??? is > returned to the management application; An agent with unpredictable behavior, as "general" number of varbinds in the request will have little to do with whether the request bounces, but whether a specific subagent was hit... > b. or, the assumption in #1 will be invalid > (e.g., the master puts maxvarbinds at a > time, in the order they appeared in the > original SetRequest) into sequential > SetRequests directed to the subagent); This seems the reasonable thing to do! > 4. Nothing needs to be stipulated in the respect > for GetRequests since there should be no > negative impact on the subagent from either > approach (one-, some-, or all-at-a-time) and > the marketplace will choose in favor of those > master agents which do all-at-a-time, modulo > possible considerations in #3. Unacceptable, as interoperability is likely to suffer. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Thu, 21 Mar 1996 15:35:43 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id PAA15887 for X-agentx-local; Thu, 21 Mar 1996 15:35:42 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id PAA15875 for ; Thu, 21 Mar 1996 15:35:41 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA19750 for ; Thu, 21 Mar 96 18:25:29 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA10853; Thu, 21 Mar 1996 18:23:31 -0500 Date: Thu, 21 Mar 1996 18:26:09 EST From: Bob Natale Subject: Re: 05: sysUpTime (fwd) To: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi, I received these comments to an earlier posting of mine off-list ...since they make some very good points that need to be considered in reaching consensus on the sysUpTime issue(s), I'm posting them to the list with only the elisions customary in such a case: > Date: Thu, 21 Mar 1996 15:31:45 EST > From: Bob Natale ... > So, I think we are headed toward a positive resolution of > it, but it might be just a bit too soon to call for consensus. > As I see it now, the major alternatives before us are: > > 1. Simple/Efficient/Limited: master passes > sysUpTime in response to subagent's "open" > operation...all (external) subagent time > variables are sync'd with this value... > counter discontinuities and the like are > an app-level problem (no different from > existing SNMPv1 and SNMPv2c). This is not enough to support multiple naming scopes. At the very least, it needs to be moved to registration responses. > 2. Complex/Effective/Robust: master > passes sysUpTime in response to subagent's > "open" operation...all (external) subagent > time variables are sync'd with this value... > warmStart traps and/or additional (new) Same problem with respect to multiple naming scopes as (1). > AgentX packet-types are used to signal > counter discontinuities and other events > which potentially impact sysUpTime integrity > ...this approach may or may not be made more > efficient via the inclusion of sysUpTime in > each packet from the master. ... Including sysuptime value in packets from master does not help the case of sysUpTime-based time stamps in logs and the like. If there are no asynchronous notifications of time base change, a sub agent won't find out the time base has changed until the next management operation occurs. By then it may be too late. If it is informed through some asynchronous mechanism, there's no need for the overhead of putting timestamps in every packet. ... Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Thu, 21 Mar 1996 15:50:13 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id PAA19773 for X-agentx-local; Thu, 21 Mar 1996 15:50:13 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id PAA19759 for ; Thu, 21 Mar 1996 15:50:12 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA20446 for ; Thu, 21 Mar 96 18:40:49 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA11104; Thu, 21 Mar 1996 18:38:51 -0500 Date: Thu, 21 Mar 1996 18:41:29 EST From: Bob Natale Subject: Re: 05: SNMPv1/SNMPv2c support To: Randy Presuhn Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Randy Presuhn > Date: Thu, 21 Mar 1996 14:50:44 -0800 Hi Randy, > do we have two issue 05s? No...05 is v1/v2 stuff...sysUpTime is 14. > > Anyway, I suggest we define the interface between (master)agent and > > subagent in terms of SNMPv2 (RFC1902-1907). That will make them > > SNMPv2 ready from the start too. > > Sounds good to me. Great. > It still needs to be able to carry the "obsolete" error codes and > data types, Right...'cause that's what the RFCs say...but those error codes should never get generated by AgentX subagents and those data types would only be used if the AgentX subagent implemented a v1 MIB...right? If so, can the latter possibility be ruled out? > but I agree the focus should be on v2. Excellent. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Thu, 21 Mar 1996 16:03:24 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id QAA23286 for X-agentx-local; Thu, 21 Mar 1996 16:03:23 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id QAA23278 for ; Thu, 21 Mar 1996 16:03:21 -0800 (PST) Message-Id: <199603220003.AA010773039@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA010773039; Thu, 21 Mar 1996 16:03:59 -0800 Date: Thu, 21 Mar 1996 16:03:59 -0800 From: Randy Presuhn To: agentx@fv.com Subject: Re: 05: SNMPv1/SNMPv2c support Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - |From natale@acec.com Thu Mar 21 15:50:54 PST 1996 |Date: Thu, 21 Mar 1996 18:41:29 EST |From: Bob Natale |Subject: Re: 05: SNMPv1/SNMPv2c support |To: Randy Presuhn |Cc: agentx@fv.com |Message-Id: ... |Right...'cause that's what the RFCs say...but those error codes |should never get generated by AgentX subagents and those data |types would only be used if the AgentX subagent implemented a |v1 MIB...right? No and yes, in that order. |If so, can the latter possibility be ruled out? No. If a subagent implements a mapping to some existing protocol or instrumentation built for v1, it may not have enough information to map to the v2-only codes. I don't see any reason to increase subagent protocol complexity by adding payload constraints not present in the underlying SNMP specifications. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Thu, 21 Mar 1996 16:03:56 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id QAA23419 for X-agentx-local; Thu, 21 Mar 1996 16:03:55 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id QAA23412 for ; Thu, 21 Mar 1996 16:03:54 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA20987 for ; Thu, 21 Mar 96 18:55:32 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA11307; Thu, 21 Mar 1996 18:54:24 -0500 Date: Thu, 21 Mar 1996 18:57:02 EST From: Bob Natale Subject: Re: 14: sysUpTime To: uri@watson.ibm.com Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Uri Blumenthal > Date: Thu, 21 Mar 1996 17:59:40 -0500 (EST) > Subject: Re: 05: sysUpTime ^^^ >>>>> 14: Hi Uri, > Bert Wijnen says: > > Gee... I thought let us get that sysUpTime agreed upon quickly. > > Keep wishing (:-). I don't know...it's moving along here. <...> > Well, why then reset sysUpTime at all? All that gets screwed up > is statistics gathered? Right...I think we are leaning toward not resetting sysUpTime on counter discontinuities...Randy had a good posting on this (and thanks for re-posting Joey's convincing analysis!). > > That is exactly why I claimed in the past that we should not > > worry about sysUpTime... alas, too many people thought we need > > to do this sysUpTime thing, so I am giving in. I really haven't seen that tidal shift, Bert...hang in there! > I'd prefer [as I said in the past :-] that every subagent-related > object or group should have it's own UpTime, because it's clear > that one "central" sysUpTime is not enough to deal with several > asynchronous entities (subagents) that come and go... Fine (as a proposal)...start a new subtopic under this (14) or whatever other topic number you consider more appropriate. <...> Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Thu, 21 Mar 1996 16:16:02 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id QAA26794 for X-agentx-local; Thu, 21 Mar 1996 16:16:02 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id QAA26770 for ; Thu, 21 Mar 1996 16:16:01 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA21487 for ; Thu, 21 Mar 96 19:06:55 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA11439; Thu, 21 Mar 1996 19:05:46 -0500 Date: Thu, 21 Mar 1996 19:08:25 EST From: Bob Natale Subject: Re: 13: Request/Response Dispatching To: Mike Daniele Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Mike Daniele > Date: Thu, 21 Mar 96 16:02:27 -0500 Hi Mike, > "All VarBinds associated with a subagent, > and only those VarBinds, > are passed in a single request Pdu to that subagent." > > Thoughts? This sounds like the position to beat at the moment. Bert/Uri, can you please start a subtopic on the maxvarbinds issue (13: Maxvarbinds), if you want to pursue it further. (One possible compromise thought here is that the "normal case" would be 0, which would mean "all", thus the complexity would be incurred by the master agent (in all cases) and only those subagents who wanted to set a limit.) [Speaking as a technical contributor, I prefer Mike's maxim with no maxvarbind option.] Randy, can you follow up with some more explanation on your point about GetNext/GetBulk and fine grained access control (maybe you can think of a meaningful subtopic title for that...and you can decide whether it belongs here or under (20: Access Control) or someplace else. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Thu, 21 Mar 1996 16:18:50 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id QAA27561 for X-agentx-local; Thu, 21 Mar 1996 16:18:49 -0800 (PST) Received: from lightning.synoptics.com (lightning.synoptics.com [134.177.3.18]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id QAA27556 for ; Thu, 21 Mar 1996 16:18:48 -0800 (PST) Received: from pobox ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA14560; Thu, 21 Mar 96 16:18:39 PST Received: from turing.engwest by pobox (4.1/SMI-4.1) id AA15404; Thu, 21 Mar 96 16:17:10 PST Received: from coachese.engwest by turing.engwest (SMI-8.6/SMI-SVR4) id QAA00427; Thu, 21 Mar 1996 16:13:46 -0800 Date: Thu, 21 Mar 1996 16:13:46 -0800 From: johns@BayNetworks.COM (John Seligson) Message-Id: <199603220013.QAA00427@turing.engwest> To: agentx@fv.com Subject: Re: 13: Request/Response Dispatching > > > > As Randy pointed out, there was no reason brought forth > > in L.A. why agentx should support a notion of > > "max number of varbinds per packet". > > > > As we discussed, the reason this might be useful > > is if the pipe between master and subagent is smaller than the > > pipe between manager and agent. This seems unlikely to me... > > > I think it would be very presumptious to equate the transport capabilities > between NMS and master to be the same as master<-->subagent. Can we not > include some type of subagent capabilities negotiation during the "open" > process? > I agree. There are a number of products using subagent technology today where the master <---> subagent channel has less bandwidth (potentially far less) than the manager <---> agent pipe. Requiring varBind aggregation for GETs and SETs without upfront negotiation would make this technology unusable in a number of situations where it is used today. > > > > I'd like to counter propose this: > > > > "All VarBinds associated with a subagent, and only those VarBinds, > > are passed in a single request Pdu to that subagent." > > > > Thoughts? > > > > Regards, > > Mike > >   Delivery-Date: Thu, 21 Mar 1996 16:22:36 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id QAA28540 for X-agentx-local; Thu, 21 Mar 1996 16:22:36 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id QAA28537 for ; Thu, 21 Mar 1996 16:22:35 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA21740 for ; Thu, 21 Mar 96 19:13:35 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA11502; Thu, 21 Mar 1996 19:12:27 -0500 Date: Thu, 21 Mar 1996 19:15:05 EST From: Bob Natale Subject: Re: 13: Request/Response Dispatching To: Randy Turner Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Randy Turner > Date: Thu, 21 Mar 1996 14:36:59 -0800 Hi Randy, > I think it would be very presumptious to equate the transport > capabilities between NMS and master to be the same as > master<-->subagent. Can we not include some type of subagent > capabilities negotiation during the "open" process? Perhaps. Do you want to make any specific proposals? If so, can you peg them off of what DPI v2 does now? Also, maybe you will want to address that under (06: Master/Subagent Binding)? Perhaps this *could* involve something in any eventual AgentX MIB by which a manager application could determine the MMS of the AgentX "environment" (still avoiding "system" here!)...which would be the smallest MMS of all the subagent bindings...? Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Thu, 21 Mar 1996 16:23:37 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id QAA28825 for X-agentx-local; Thu, 21 Mar 1996 16:23:36 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id QAA28812 for ; Thu, 21 Mar 1996 16:23:35 -0800 (PST) Message-Id: <199603220024.AA011634253@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA011634253; Thu, 21 Mar 1996 16:24:13 -0800 Date: Thu, 21 Mar 1996 16:24:13 -0800 From: Randy Presuhn To: agentx@fv.com Subject: Re: 13: Request/Response Dispatching Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > From: rturner@mail.sharplabs.com (Randy Turner) > Received: by sla5c (SMI-8.6) id OAA04044; Thu, 21 Mar 1996 14:36:59 -0800 > Date: Thu, 21 Mar 1996 14:36:59 -0800 > Message-Id: <199603212236.OAA04044@sla5c> > To: agentx@fv.com > Subject: Re: 13: Request/Response Dispatching ... > I think it would be very presumptious to equate the transport capabilities > between NMS and master to be the same as master<-->subagent. Can we not > include some type of subagent capabilities negotiation during the "open" > process? The master agent to subagent pipe is likely to be more robust than the pipe between NMS and agent. This has been true for (or at least an assumption of) all the subagent proposals I've seen. Let's resist the temptation to add capabilities negotiation. 1) it adds size and complexity to the protocol description 2) it adds size and complexity to the protocol implementation 3) vendors, in order to stay competitive, end up implementing the full capability set anyway. Compare the CMIP PICS with the AOM-12 (11183-2) profile to see what happens to options like these. It's much simpler to get rid of the optionality from the start. If no one's going to use it, get rid of it. If everyone has to implement it anyway, make it mandatory. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Thu, 21 Mar 1996 16:37:29 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id QAA02519 for X-agentx-local; Thu, 21 Mar 1996 16:37:29 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id QAA02494 for ; Thu, 21 Mar 1996 16:37:25 -0800 (PST) Message-Id: <199603220038.AA012025083@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA012025083; Thu, 21 Mar 1996 16:38:03 -0800 Date: Thu, 21 Mar 1996 16:38:03 -0800 From: Randy Presuhn To: agentx@fv.com Subject: Re: 13: Request/Response Dispatching Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > Date: Thu, 21 Mar 1996 19:08:25 EST > From: Bob Natale > Subject: Re: 13: Request/Response Dispatching > To: Mike Daniele > Cc: agentx@fv.com > Message-Id: ... > Randy, can you follow up with some more explanation on > your point about GetNext/GetBulk and fine grained access > control (maybe you can think of a meaningful subtopic > title for that...and you can decide whether it belongs > here or under (20: Access Control) or someplace else. ... In processing a get-next or get-bulk operation, it may be determined that some subagent may be able to provide a better response than the one given by the subagent to which the request was originally directed. For example, a table may be exhausted, or the instance returned by a subagent may be excluded by access control. (In general, with subtree registration, it is not always possible to determine in advance whether a subagent's response to get-next/bulk will be permitted by access control.) When this occurs, the master agent will need to send a request to some other subagent in order to figure out what's really next. As Jeff Case has pointed out, flagging instance registrations (special case of subtree registration) allows significant optimization. However, it does not eliminate the possibility that evaluation of a single get-next/bulk operation may require multiple master/subagent interactions. None of this is new. The issues are outlined in RFC 1227. Something like this is needed to get get-next/bulk to work with any mechanism that does not limit itself exlusively to instance-level registration. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Thu, 21 Mar 1996 16:54:08 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id QAA06986 for X-agentx-local; Thu, 21 Mar 1996 16:54:08 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id QAA06980 for ; Thu, 21 Mar 1996 16:54:07 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA23087 for ; Thu, 21 Mar 96 19:46:25 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA11944; Thu, 21 Mar 1996 19:44:27 -0500 Date: Thu, 21 Mar 1996 19:47:05 EST From: Bob Natale Subject: Re: 22: agentX MIB(s) To: Randy Turner Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Randy Turner > Date: Thu, 21 Mar 1996 14:54:30 -0800 Hi Randy, > It seems to me that the "debugging and verification" of subagent > functionality is really the primary rationale for the development > and support of a subagent MIB. I would like to see us handle master agent configuration items in such a MIB. This would include such things as MIB views, community profiles, trap dispatching, etc. In other words, all the things we'd like to see configurable in a well-equipped native agent. None of that needs to (or should) include any explicit exposure of the underlying subagent structure. > That in the real world, we are striving for transparency and > that creating a subagent MIB and publishing it would mean that > we are now exposing the existence of the subagent(s) to the > network administrator, and that he/she would have to understand > the agent<-->subagent model in order to properly "manage" the > agentx functionality. The premise does not mandate the conclusion. Disclosure *can* be an adjunct to transparency. That is, the requirement is that management applications *must* be able to perform all standard SNMP operations against the collective AgentX managed environment without *having* to be aware of the AgentX structure. This requirement does not preclude the possibility of exposing internal information to them for whatever worthwhile purpose it might serve. I'm not arguing for that, necessarily...in fact, I find Bert's empirical report that most of the data in the DPI SA MIB do not appear to be very widely used in practice to be quite persuasive. But I was just pointing out the logical difference. > Using the MIB for debugging and verification of subagent > status would be very helpful, but only for developers. > But as a fundamental idea, the MIB seems to fly in the > face of the requirment for transparency. Again, if you believe the first sentence in that paragraph, you should take comfort in the fact that the second sentence is not necessarily true. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Thu, 21 Mar 1996 17:04:55 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id RAA09752 for X-agentx-local; Thu, 21 Mar 1996 17:04:55 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id RAA09739 for ; Thu, 21 Mar 1996 17:04:53 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA23333 for ; Thu, 21 Mar 96 19:53:24 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA12018; Thu, 21 Mar 1996 19:52:16 -0500 Date: Thu, 21 Mar 1996 19:54:54 EST From: Bob Natale Subject: 02: Architecture (payload constraints) To: Randy Presuhn Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Randy Presuhn > Date: Thu, 21 Mar 1996 16:03:59 -0800 > Subject: Re: 05: SNMPv1/SNMPv2c support Hi Randy, [Redirecting this to 02: for future reference.] <...your correct answers to my erroneous questions! :-> > I don't see any reason to increase subagent protocol complexity > by adding payload constraints not present in the underlying SNMP > specifications. Excellent. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Fri, 22 Mar 1996 01:20:28 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id BAA11826 for X-agentx-local; Fri, 22 Mar 1996 01:20:27 -0800 (PST) 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 BAA11791 for ; Fri, 22 Mar 1996 01:20:24 -0800 (PST) Message-Id: <199603220920.BAA11791@zloty.fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 9720; Fri, 22 Mar 96 04:19:56 EST Date: Fri, 22 Mar 96 10:19:36 CET From: "Bert Wijnen" To: agentx@fv.com Subject: 05: sysUpTime It seems there is some mis-understanding about sysUpTime and Counters. 1.The way it has (always as far as I know) been defined is that if there is a counter discontinuity (no matter if the counter got reset to zero or if it got screwed some other way), then sysUpTime needs to be reset. The reset of sysUpTime is then supposedly a signal to the management applications that one or more (which ones and how many is unknown) counters have experienced a discontinuity. The zero value is nothing special in counters, see RFC1902 section 7.1.6 which clearly states that counters do NOT have any "initial value" 2.In the past I have also suggested/proposed many times that it is kind of crazy to have only one indicator (namely sysUpTime) to indicate that one of (possibly very) many counters has had some trouble. Because then for the ONE counter discontinuity, a management application (or applications) must all of a sudden assume that something happened to all counters.... and so unneccessary discuntinuties in statistics or unneccessary extra polling is the result. In fact RFC1902, sections 7.1.6 and 7.1.10 which discuss Counter32 and Counter64 repectively, state explicitly that if "discontinuities of counters can occur at other times than at system initialization time, that then a corresponding object of SYNTAX TimeSTamp should be defined that indicates the time of the last discontinuity of the counter in question" (this quote is not literal, but is accurate I think). So the questions now are: a.is it a re-initialization of the management system if a subagent disconnects/reconnects? - if yes, then sysUpTime must be reset - if no, then an object of SYNTAX TimeStamp must be defined for counter implemented within the MIB supported by the subagent. But since you never know if this counter in a MIB is part of a monolithic agent or a subagent, you cannot require the MIB designers that they define an object of SYNTAX TimeStamp. So I then come to the conclusion that in order to do this properly (and transparent), that a disconnect/connect sequence of a subagent should reset sysUpTime b.Is the unregister/register sequence a re-initialization of the management system or not. - if yes, then sysUpTime must be reset - if no... see above under a. I come to the same conclusion as under a. So from the above... I concluded that we'd reset sysUpTime, no matter how much I dislike that. Then Mike came with the remark that we may have possible consensus that we'd leave sysUpTime untouched, because this whole thing seems already broken in monolithic SNMPv1/v2c agents right now, and we do not need to fix that as paart of agentX WG. Now another way to solve it might be via the saMIB where we can define at which time subagents come and go and at what time registrations take place. So then when a subagent encounters a discontinuity in a counter, it could unregister/reregister the subtree under which this counter is registered. The problem with this is the following: - I think we want to make that saMIB optional (if we create it at all) So it would not always work for a manager. - Some manager want to treat a master/subagent environment transparent as if it were just one monolithic agent, and so it would not work either. Unless we give up the transparency principle for this particular item. Personally I am in favor of keeping the transparency principle. Yet another way to try and solve this might be via the sysORTable in RFC1907. When a subagent reggisters subtrees or objects, then for all I can tell we will have to add entries in the sysORTable. And this is also true if such kind of registrations happen within a monolithic agent, so no difference for the subagent scenario. The sysORTable has a sysORUpTime field. And so if we could make sure that this time is updated when a counter in a subagent gets a discontiinuity (we could do that by telling subagent implementers that a discunituity in a counter that does not have an object of SYNTAX TimeStamp associated with it, that for such cases the subagent must unregister/reregister in order to get th sysORUpTime reset. Of course (existing) management applications will have to be changed to recognize this, but many of them may need to change because of sysORTable already. To me, that is acceptable. Bert   Delivery-Date: Fri, 22 Mar 1996 02:14:47 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id CAA22483 for X-agentx-local; Fri, 22 Mar 1996 02:14:46 -0800 (PST) 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 CAA22479 for ; Fri, 22 Mar 1996 02:14:45 -0800 (PST) Message-Id: <199603221014.CAA22479@zloty.fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0104; Fri, 22 Mar 96 05:14:17 EST Date: Fri, 22 Mar 96 11:13:59 CET From: "Bert Wijnen" To: agentx@fv.com Subject: 05: SNMPv1/SNMPv2c support Randy writes > > Anyway, I suggest we define the interface between (master)agent and > > subagent in terms of SNMPv2 (RFC1902-1907). That will make them > > SNMPv2 ready from the start too. > ... > > Sounds good to me. It still needs to be able to carry the "obsolete" > error codes and data types, but I agree the focus should be on v2. > Pls explain why we need thes eold error-codes and data types. We're defining a complete new interface. I'd think that people leave there current instrumentation in whichever way it exists. By the time that a MIB gets re-issued to conform to the v2 (RFC1902-04), by that time the instrumentation code may have to change, and so that would be the time that one would considere writing to agentX interface. Now... if we can see quite a big number of "component" vendors to tell us here that they plan to move old SNMPv1 based instrumentation to the outcome of the agentX WG, then I'd give in, but I am afraid not many (if any) are willing to commit that. So... then why bother with these extra (obsolet) things? Bert   Delivery-Date: Fri, 22 Mar 1996 02:35:56 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id CAA26225 for X-agentx-local; Fri, 22 Mar 1996 02:35:55 -0800 (PST) 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 CAA26218 for ; Fri, 22 Mar 1996 02:35:54 -0800 (PST) Message-Id: <199603221035.CAA26218@zloty.fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0210; Fri, 22 Mar 96 05:35:26 EST Date: Fri, 22 Mar 96 11:35:08 CET From: "Bert Wijnen" To: agentx@fv.com Subject: Re: 13: Request/Response Dispatching Randy Presuhn writes: > more serious here.) I hope the intent was: > for all subagents: > from an SNMP set request, the non-empty subset of > those varbinds for which that subagent is responsible > is dispatched to that subagent in a single subagent > PDU > This is indeed a more precise statement. > I hope we can agree: > in processing a set (or simple get) operation, a master agent > will not send varbinds to a subagent for which that subagent > has not claimed responsibility. > Yes certainly so. > > 3. *If* the AgentX protocol includes a mechanism by > > which a subagent can limit the number of varbinds > > it will accept in a single packet from the master > > I do not see this as a requirement. It increases both master > agent and subagent complexity, with no real benefits. > Mmmm. I can agree that it adds complexity to the master agent, but not to a sub-agent. That is you do not mean that "having to specify something if it does not want the default" is "complex" for a subagent, is it? Bert   Delivery-Date: Fri, 22 Mar 1996 02:44:27 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id CAA27886 for X-agentx-local; Fri, 22 Mar 1996 02:44:26 -0800 (PST) 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 CAA27880 for ; Fri, 22 Mar 1996 02:44:25 -0800 (PST) Message-Id: <199603221044.CAA27880@zloty.fv.com> Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0242; Fri, 22 Mar 96 05:43:57 EST Date: Fri, 22 Mar 96 11:43:40 CET From: "Bert Wijnen" To: agentx@fv.com Subject: compatibility I don't see an "item-number" for this yet. 1.It has come up a few times already that "such and such is required in order to allow the creation of adapters for existing subagent implementations" 2.One of the reason why I (as one of the DPI authors) want to allow a subagent to specify that it only wants to handle n varBinds per subagent packet, is that that makes it much easier for me to write a DPI 1.0 or DPI 2.0 adapter on top of agentX. But the question comes up.... do we really want to take such compatility issues as serious requirements for our design. I have seen in the past, that if we do that, then we end up with lots of options or features that we do not really need, but that we only need for compatibility. And the net result is a much more complex design that warranted. I agree that if a new version of some STANDARD protocol is designed, that it is then important to think about compatibility with the earlier version. But is it also so important when we design the FIRST version of a standard, that we try to accomodate (at high cost) all sorts of proprietary and experimental protocols??? Personally I would say NO. Maybe IBM (heavily using DPI) would say yes. But we are here to try and design the best technical and the best usable agentX protocol... that of course needs to be accepted by the market-place, otherwise it is also useless. Opinions? Bert   Delivery-Date: Fri, 22 Mar 1996 03:02:12 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id DAA01012 for X-agentx-local; Fri, 22 Mar 1996 03:02:11 -0800 (PST) Received: from hnssysa.hns.com ([139.85.76.210]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id DAA01007 for ; Fri, 22 Mar 1996 03:02:10 -0800 (PST) Received: from pessys5.hns.com (pessys5.hns.com [139.85.124.96]) by hnssysa.hns.com (8.7.1/) with ESMTP id GAA25498; Fri, 22 Mar 1996 06:02:03 -0500 (EST) Received: (dward@localhost) by pessys5.hns.com (8.7.1/8.6.12) id GAA24319; Fri, 22 Mar 1996 06:02:02 -0500 (EST) From: "David Ward" Message-Id: <9603220602.ZM24317@pessys5.hns.com> Date: Fri, 22 Mar 1996 06:02:02 -0500 In-Reply-To: Bob Natale "02: Per-Varbind Processing" (Mar 21, 1:45pm) References: X-Mailer: Z-Mail (3.2.1 10apr95) To: Bob Natale Subject: Re: 02: Per-Varbind Processing Cc: agentx@fv.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Mar 21, 1:45pm, Bob Natale wrote: > Subject: 02: Per-Varbind Processing > > From: David Ward > > Date: Thu, 21 Mar 1996 12:43:05 -0500 > > Subject: Re: Draft of L.A. IETF minutes > > To: agentx-owner@fv.com, agentx@fv.com > ^^^^^^^^^^^^ > > > Is it possible to have the master agent broadcast a "Start > > varbind processing" message before processing the first varbind, > > and an "End varbind processing" message after the last varbind has > > been passed to a subagent? If this is done (and the master agent > > is asynchronous in nature), then we could "cache" the varbinds in our > > subagent, send them over the satellite when we receive the "End" > > message, and then send the response(s) to the master agent. We could > > have the subagents register in these "Start/End" messages using > > whatever scheme is devised for them to register for the varbinds > > themselves. This could possibly be done by having the "Start/End" > > actually be MIB variables themselves? > > That is a possibility. I am personally hopeful, however, that > our ultimate consensus will be for something more efficient... > such as a policy that all varbinds for a SetRequest must be > given to the subagent in a single packet. The single packet to the subagent would work great for us. It would have to apply to Getxxx requests as well. If it is not a general solution for all, perhaps it could be a configuration parameter of the subagent itself (i.e., in his MIB). > > [Dale, please note that we will need to include these > defintions of "per varbind" and "per packet" in our > Glossary...Thanks.] > > Cordially, > > BobN > ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ > Bob Natale | ACE*COMM | 301-258-9850 [v] > Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] > natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com > ------- NetPlus (r) "FCAPS" Telemanagement Applications -------- > > > >-- End of excerpt from Bob Natale -- David Ward dward@hns.com Hughes Network Systems, Inc. 11717 Exploration Lane Germantown, MD 20876 (301) 212-1022 (voice) (301) 212-2089 (fax) -------------------------------------------------------------------------------- Please help me - I'm stuck in a barrel and can't get out! --------------------------------------------------------------------------------   Delivery-Date: Fri, 22 Mar 1996 03:29:46 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id DAA07290 for X-agentx-local; Fri, 22 Mar 1996 03:29:45 -0800 (PST) Received: from hnssysa.hns.com ([139.85.76.210]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id DAA07287 for ; Fri, 22 Mar 1996 03:29:44 -0800 (PST) Received: from pessys5.hns.com (pessys5.hns.com [139.85.124.96]) by hnssysa.hns.com (8.7.1/) with ESMTP id GAA25744; Fri, 22 Mar 1996 06:29:37 -0500 (EST) Received: (dward@localhost) by pessys5.hns.com (8.7.1/8.6.12) id GAA27611; Fri, 22 Mar 1996 06:29:36 -0500 (EST) From: "David Ward" Message-Id: <9603220629.ZM27609@pessys5.hns.com> Date: Fri, 22 Mar 1996 06:29:36 -0500 In-Reply-To: Randy Presuhn "Re: 13: Request/Response Dispatching" (Mar 21, 2:46pm) References: <199603212246.AA004398371@dorothy.peer.com> X-Mailer: Z-Mail (3.2.1 10apr95) To: Randy Presuhn , agentx@fv.com Subject: Re: 13: Request/Response Dispatching Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Mar 21, 2:46pm, Randy Presuhn wrote: > Subject: Re: 13: Request/Response Dispatching > Hi - > > > Message-Id: <9603212102.AA03527@bernie.zk3.dec.com> > > To: Bob Natale > > Cc: agentx@fv.com > > Subject: Re: 13: Request/Response Dispatching > > In-Reply-To: Your message of "Thu, 21 Mar 96 15:00:39 EST." > > Date: Thu, 21 Mar 96 16:02:27 -0500 > > From: Mike Daniele > ... > > I'd like to counter propose this: > > > > "All VarBinds associated with a subagent, and only those VarBinds, > > are passed in a single request Pdu to that subagent." > > > > Thoughts? > > Well put. I agree with this for the GET and SET cases. It's > too strong for GET-NEXT or GET-BULK. As I stated in a previous message, in a satellite network, the varbinds would always need to be passed to the subagent in a single pdu regardless of the original pdu type passed between the manager and agent. This is necessary because the master agent will not know the performance requirements of actually satisfying the get xxx request (only the subagent can discern that). I can see the dilemma here in regards to getNext and getBulk since the master agent really doesn't know which varbinds will be accessed. In our small world, we do the following: 1. getRequest, getNext, and getBulk are transformed into a single getVarbinds message before being passed onto the subagent. In the getVarbinds message is a list of varbinds to be satisfied. For each varbind is listed the following: - Originally requested varbind OID. - Type of value requested (N/A for getNext and getBulk). - Whether or not lexicographic successors are requested (N/A for getRequest). - Number of repetitions to perform (set to 1 for both getRequest and getNext as well as for the non-repeaters in getBulk). 2. This getVarbinds message is then passed to the subagent. 3. The subagent creates an associated response message (looks similar to the getVarbinds message with the addition of the real value type, a status, value length and the value. 4. The master agent collects all of the response messages from the subagents, creates a Response PDU, and ships the Response PDU back to the manager. Thus, with one message, we've encompassed all of the getxxx PDUs. Unfortunately, for you, this negates the ability to talk SNMP between the master agent and the subagents (not a requirement for us, obviously). In addition, it doesn't allow any fine grained control over the variables requested of a subagent when getNext and getBulk are used (all control is based on the varbind specified in the original request, and not those actually retrieved). The fine grained control in this case is very tricky, and I can see why it poses so much trouble for this working group. Perhaps satisfying getNext and getBulk is an iterative process where you pass it to a subagent based on the originally requested varbinds. That subagent satisfies as many varbinds as it can. Upon receiving the subagent's response, the master agent must then see if other subagents are present that can give more information, and passes it to them. This continues until there is no more information to retrieve from any subagents. David > > ----------------------------------------------------------------------------- > Randy Presuhn PEER Networks, a division of BMC Software, Inc. > Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 > Fax: +1 408 556-0735 San Jose, California 95129-3433 > Email: randy_presuhn@bmc.com USA > ----------------------------------------------------------------------------- > > ================ > 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.) >-- End of excerpt from Randy Presuhn -- David Ward dward@hns.com Hughes Network Systems, Inc. 11717 Exploration Lane Germantown, MD 20876 (301) 212-1022 (voice) (301) 212-2089 (fax) -------------------------------------------------------------------------------- Please help me - I'm stuck in a barrel and can't get out! --------------------------------------------------------------------------------   Delivery-Date: Fri, 22 Mar 1996 03:58:51 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id DAA12507 for X-agentx-local; Fri, 22 Mar 1996 03:58:50 -0800 (PST) Received: from europe.std.com (europe.std.com [192.74.137.10]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id DAA12504 for ; Fri, 22 Mar 1996 03:58:49 -0800 (PST) Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id GAA16179; Fri, 22 Mar 1996 06:58:28 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA10404; Fri, 22 Mar 1996 06:57:57 -0500 From: ralex@world.std.com (Aleksey Y Romanov) Message-Id: <199603221157.AA10404@world.std.com> Subject: Re: compatibility To: wijnen@vnet.ibm.com (Bert Wijnen) Date: Fri, 22 Mar 1996 06:57:57 -0500 (EST) Cc: agentx@fv.com In-Reply-To: <199603221044.CAA27880@zloty.fv.com> from "Bert Wijnen" at Mar 22, 96 11:43:40 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > I agree that if a new version of some STANDARD protocol is designed, > that it is then important to think about compatibility with the earlier > version. But is it also so important when we design the FIRST version ^^^^^ > of a standard, that we try to accomodate (at high cost) all sorts of > proprietary and experimental protocols??? > Personally I would say NO. I agree with you. Our goal is to develop cheap/lean attachment protocol for new development - not a univerasal adapter for old stuff. BTW, accepting this policy still allows vendors to have more than one atachment mechanisms implemented - one for new stuff and one for old one. > Bert Aleksey   Delivery-Date: Fri, 22 Mar 1996 04:15:54 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id EAA15887 for X-agentx-local; Fri, 22 Mar 1996 04:15:53 -0800 (PST) Received: from europe.std.com (europe.std.com [192.74.137.10]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id EAA15881 for ; Fri, 22 Mar 1996 04:15:52 -0800 (PST) Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id HAA17290; Fri, 22 Mar 1996 07:15:44 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA16945; Fri, 22 Mar 1996 07:13:47 -0500 From: ralex@world.std.com (Aleksey Y Romanov) Message-Id: <199603221213.AA16945@world.std.com> Subject: Re: 13: Request/Response Dispatching To: wijnen@vnet.ibm.com (Bert Wijnen) Date: Fri, 22 Mar 1996 07:13:47 -0500 (EST) Cc: agentx@fv.com In-Reply-To: <199603221035.CAA26218@zloty.fv.com> from "Bert Wijnen" at Mar 22, 96 11:35:08 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > Randy Presuhn writes: > > more serious here.) I hope the intent was: > > for all subagents: > > from an SNMP set request, the non-empty subset of > > those varbinds for which that subagent is responsible > > is dispatched to that subagent in a single subagent > > PDU > > > This is indeed a more precise statement. > > > I hope we can agree: > > in processing a set (or simple get) operation, a master agent > > will not send varbinds to a subagent for which that subagent > > has not claimed responsibility. > > > Yes certainly so. I have a problem here - it means among other things that master-agent knows and verifies details of (a) indexing, (b) holes in registration tree - I am not against this, however I would like for everybody to understand that there is substantial overhead involved here both during registration and operation phase. I would like to note also that despite 1000's of lines of postings about registering overlapping rows I did not see anything yet which will provide simple/robust/generic mechanism for row creation in this environment (*). BTW, if we are going to go ther way of 'master-agent knows all details about sub-agent variable space' indeed than let us use ALL positive sides of this approach - there are many of them still untapped. E.g. when master-agent registers variable, master assigns number to this variable and returns it back to sub-agent and uses this number instead of OID string since and because master would do initial verification of index part anyway - it can convert them from oid strings into sets of integers and strings. But I still think it is undoable due to (*). > > > > 3. *If* the AgentX protocol includes a mechanism by > > > which a subagent can limit the number of varbinds > > > it will accept in a single packet from the master > > > > I do not see this as a requirement. It increases both master > > agent and subagent complexity, with no real benefits. > > > Mmmm. I can agree that it adds complexity to the master agent, > but not to a sub-agent. That is you do not mean that "having to > specify something if it does not want the default" is "complex" > for a subagent, is it? What if NMS <->master-agent MTU is much bigger than master<->sub-agent MTU ? > Bert Aleksey   Delivery-Date: Fri, 22 Mar 1996 05:13:09 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id FAA27639 for X-agentx-local; Fri, 22 Mar 1996 05:13:04 -0800 (PST) Received: from ta.antec.com ([205.187.171.11]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id FAA27560 for ; Fri, 22 Mar 1996 05:12:57 -0800 (PST) Received: from pc_georgeb by ta.antec.com via SMTP (8.6.12/8.6.4) for id IAA21118; Fri, 22 Mar 1996 08:07:37 -0500 Date: Fri, 22 Mar 1996 08:07:37 -0500 Message-Id: <199603221307.IAA21118@ta.antec.com> X-Sender: georgeb@bopper.ta.antec.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: agentx@fv.com From: george.best@antec.com (George Best) Subject: Re: 13: Request/Response Dispatching At 03:00 PM 3/21/96 EST, Bob Natale wrote: [snip] >Yes. I would propose the following policy (strawman wording): > [snip] > 3. *If* the AgentX protocol includes a mechanism by > which a subagent can limit the number of varbinds > it will accept in a single packet from the master > agent,... [snip] >Corrections/improvements? Shouldn't the varbind limit be no less than the current varbind limit (defacto or otherwise) for set-requests? If not, then the managers will have two sets of rules to follow (e.g., "I can put up to X varbinds in the PDU if it's a simple agent, but I can only put Y varbinds in the PDU if I'm talking to a subagent"). Gb - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - George Best email: georgeb@antec.com Digital Video, Norcross GA, USA voice: (770)734-0400 ext. 8534   Delivery-Date: Fri, 22 Mar 1996 05:25:25 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id FAA00109 for X-agentx-local; Fri, 22 Mar 1996 05:25:24 -0800 (PST) Received: from ta.antec.com ([205.187.171.11]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id FAA00105 for ; Fri, 22 Mar 1996 05:25:23 -0800 (PST) Received: from pc_georgeb by ta.antec.com via SMTP (8.6.12/8.6.4) for id IAA21181; Fri, 22 Mar 1996 08:20:03 -0500 Date: Fri, 22 Mar 1996 08:20:03 -0500 Message-Id: <199603221320.IAA21181@ta.antec.com> X-Sender: georgeb@bopper.ta.antec.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: agentx@fv.com From: george.best@antec.com (George Best) Subject: Re: 02: Architecture - Division of Labor At 03:23 PM 3/21/96 -0500, Mike Daniele wrote: >I propose that all association of registered "subtrees" >with actual MIB variables, reside in the subagents. >A variable's OBJECT-TYPE and instantiation are solely the >responsibility of the subagent, and are invisible to the master. > >I'm using "subtree" here to mean whatever we permit with the >agentx registration syntax. It might be single oids, or ranges, >etc. So you would mandate that every table is wholly instrumented by one and only one agent? I don't mean to be niave, but is this a reasonable expectation? Would this work for the MADMAN MIB set, for example, if you had an MTA from vendor X and a DSA from vendor Y? Gb - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - George Best email: georgeb@antec.com Digital Video, Norcross GA, USA voice: (770)734-0400 ext. 8534   Delivery-Date: Fri, 22 Mar 1996 05:43:45 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id FAA04138 for X-agentx-local; Fri, 22 Mar 1996 05:43:45 -0800 (PST) Received: from ta.antec.com ([205.187.171.11]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id FAA04135 for ; Fri, 22 Mar 1996 05:43:44 -0800 (PST) Received: from pc_georgeb by ta.antec.com via SMTP (8.6.12/8.6.4) id IAA21256; Fri, 22 Mar 1996 08:38:14 -0500 Date: Fri, 22 Mar 1996 08:38:14 -0500 Message-Id: <199603221338.IAA21256@ta.antec.com> X-Sender: georgeb@bopper.ta.antec.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: rturner@mail.sharplabs.com (Randy Turner), agentx@fv.com From: george.best@antec.com (George Best) Subject: Re: 22: agentX MIB(s) At 02:54 PM 3/21/96 -0800, Randy Turner wrote: > >Using the MIB for debugging and verification of subagent status would be very >helpful, but only for developers. But as a fundamental idea, the MIB seems >to fly in the face of the requirment for transparency. > Or would the agent and subagent be represented (and monitored) via the sysAppl MIB and the related Appl MIBs? Gb - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - George Best email: georgeb@antec.com Digital Video, Norcross GA, USA voice: (770)734-0400 ext. 8534   Delivery-Date: Fri, 22 Mar 1996 05:55:32 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id FAA07025 for X-agentx-local; Fri, 22 Mar 1996 05:55:31 -0800 (PST) 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 FAA07020 for ; Fri, 22 Mar 1996 05:55:30 -0800 (PST) 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 FAA21652 for ; Fri, 22 Mar 1996 05:55:21 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Mar 1996 08:55:22 -0500 To: agentx@fv.com From: bstewart@cisco.com (Bob Stewart) Subject: Re: 13: Request/Response Dispatching Circa 4:24 PM 3/21/96, Randy Presuhn bitwhacked: >Compare the CMIP PICS with the AOM-12 (11183-2) profile to see what >happens to options like these. It's much simpler to get rid of the >optionality from the start. If no one's going to use it, get rid >of it. If everyone has to implement it anyway, make it mandatory. There was a time when this was a guiding principle for the Internet Network Management Framework. It's still a good one. Bob   Delivery-Date: Fri, 22 Mar 1996 05:55:52 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id FAA07098 for X-agentx-local; Fri, 22 Mar 1996 05:55:51 -0800 (PST) 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 FAA07093 for ; Fri, 22 Mar 1996 05:55:51 -0800 (PST) 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 FAA21666 for ; Fri, 22 Mar 1996 05:55:42 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Mar 1996 08:55:43 -0500 To: agentx@fv.com From: bstewart@cisco.com (Bob Stewart) Subject: Re: 22: agentX MIB(s) Circa 2:54 PM 3/21/96, Randy Turner bitwhacked: >Using the MIB for debugging and verification of subagent status would be very >helpful, but only for developers. But as a fundamental idea, the MIB seems >to fly in the face of the requirment for transparency. We have a fine line to walk. Transparency can be a big problem when you have to fix something that's broken and you can't see the pieces. On the other hand, we have to be careful that we don't let all the cows out when we open the barn door. If we have a MIB we'll be tempted to overuse it. The guiding principle should be that an AgentX MIB is of interest only to applications focussed on managing the multi-part agent itself. It supports tools needed by the responsible system manager. Furthermore, we shouldn't load up the poor system manager with tools intended for subagent developers. Standard MIBs are for managers, not code developers. We must resist the temptation to try to solve general application problems with the subagent MIB. That would violate the real transparency requirement. Bob   Delivery-Date: Fri, 22 Mar 1996 06:01:40 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id GAA08498 for X-agentx-local; Fri, 22 Mar 1996 06:01:39 -0800 (PST) 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 GAA08495 for ; Fri, 22 Mar 1996 06:01:38 -0800 (PST) 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 GAA21799; Fri, 22 Mar 1996 06:01:18 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Mar 1996 09:01:19 -0500 To: Bob Natale , Randy Turner From: bstewart@cisco.com (Bob Stewart) Subject: Re: 22: agentX MIB(s) Cc: agentx@fv.com Circa 7:47 PM 3/21/96, Bob Natale bitwhacked: >I would like to see us handle master agent configuration items >in such a MIB. This would include such things as MIB views, >community profiles, trap dispatching, etc. In other words, >all the things we'd like to see configurable in a well-equipped >native agent. None of that needs to (or should) include any >explicit exposure of the underlying subagent structure. Aaarrrrggghh. I completely disagree. I believe that would be thoroughly exceeding our charter. We're not doing this to solve general problems, such as MIB views, community profiles, and trap dispatching. If the things in the AgentX MIB aren't absolutely focussed on AgentX-specific concerns, they're out of place. >The premise does not mandate the conclusion. Disclosure *can* >be an adjunct to transparency. That is, the requirement is >that management applications *must* be able to perform all >standard SNMP operations against the collective AgentX managed >environment without *having* to be aware of the AgentX structure. >This requirement does not preclude the possibility of exposing >internal information to them for whatever worthwhile purpose >it might serve. I agree up to the "whatever worthwhile purposes" part. That's to inclusive. Solving world hunger is a worthwhile (if perhaps futile) purpose, but doesn't belong in the AgentX MIB. Having good jobs available for software developers and network management gurus is another worthwhile purpose, but we shouldn't do it by complicating the MIB. >I'm not arguing for that, necessarily...in fact, I find >Bert's empirical report that most of the data in the DPI >SA MIB do not appear to be very widely used in practice >to be quite persuasive. But I was just pointing out the >logical difference. Bert's experience is extremely instructive. In actual practise (novel concept) he found he had a debugging aid and little else. Debugging aids are fine for developers, but shouldn't be confused with tools for end users. Doing that has been one of the banes of system/network management since the first day I poked my nose into the field 27 years ago. Bob   Delivery-Date: Fri, 22 Mar 1996 06:10:28 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id GAA10558 for X-agentx-local; Fri, 22 Mar 1996 06:10:27 -0800 (PST) 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 GAA10555 for ; Fri, 22 Mar 1996 06:10:26 -0800 (PST) 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 GAA21953 for ; Fri, 22 Mar 1996 06:10:18 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Mar 1996 09:10:19 -0500 To: agentx@fv.com From: bstewart@cisco.com (Bob Stewart) Subject: Re: compatibility Circa 6:43 AM 3/22/96, Bert Wijnen bitwhacked: >I agree that if a new version of some STANDARD protocol is designed, >that it is then important to think about compatibility with the earlier >version. But is it also so important when we design the FIRST version >of a standard, that we try to accomodate (at high cost) all sorts of >proprietary and experimental protocols??? Although we shouldn't be unnecessarily hostile to the proprietary base, we shouldn't consider it as pre-existing chains of compatibility. Anything we do to ease conversion of existing code should be inexpensive and clean with regard to a new design and new code. Bob   Delivery-Date: Fri, 22 Mar 1996 06:22:51 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id GAA13537 for X-agentx-local; Fri, 22 Mar 1996 06:22:50 -0800 (PST) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id GAA13533 for ; Fri, 22 Mar 1996 06:22:49 -0800 (PST) Received: from flume.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA12090; Fri, 22 Mar 1996 09:12:59 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA29425; Fri, 22 Mar 1996 09:12:59 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA03716; Fri, 22 Mar 1996 09:13:30 -0500 Message-Id: <9603221413.AA03716@bernie.zk3.dec.com> To: "David Ward" Cc: agentx@fv.com Subject: Re: 13: Request/Response Dispatching In-Reply-To: Your message of "Fri, 22 Mar 96 06:29:36 EST." <9603220629.ZM27609@pessys5.hns.com> Date: Fri, 22 Mar 96 09:13:29 -0500 From: Mike Daniele X-Mts: smtp Dave, >it poses so much trouble for this working group. Perhaps satisfying getNext >and getBulk is an iterative process where you pass it to a subagent based >on the originally requested varbinds. That subagent satisfies as many >varbinds as it can. Upon receiving the subagent's response, the master >agent must then see if other subagents are present that can give more >information, and passes it to them. This continues until there is no more >information to retrieve from any subagents. Precisely. Randy P, >For example, a table may be exhausted, or the instance returned by a >subagent may be excluded by access control. (In general, with subtree > ... Sorry for the confusion. I didn't mean to imply by "All VarBinds associated with a subagent, and only those VarBinds, are passed in a single request Pdu to that subagent." that this is the ONLY packet that will ever be sent for those VarBinds. The master agent actually loops on o associate all unserviced VarBinds with a subagent o encode 1 packet for each involved subagent, containing all of the VarBinds currently associated with it, and only those VarBinds o send all packets, marshall responses o mark VarBinds returned w/ endofMibView (and any determined to be out of view in an implementation-specific manner) as unserviced probably with some provision for timing out subs that don't respond. For Get/Set you only loop once (ignoring multi-phase Sets). Note that the 'association' phase may well result in a different subagent being asked to service a VarBind than on the last pass, especially given overlapping registrations. I'm writing up detailed verbage for this stuff now. Regards, Mike   Delivery-Date: Fri, 22 Mar 1996 06:36:48 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id GAA16778 for X-agentx-local; Fri, 22 Mar 1996 06:36:47 -0800 (PST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id GAA16773 for ; Fri, 22 Mar 1996 06:36:46 -0800 (PST) Received: from flume.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA10837; Fri, 22 Mar 1996 09:29:42 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA26113; Fri, 22 Mar 1996 09:30:58 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA03734; Fri, 22 Mar 1996 09:31:25 -0500 Message-Id: <9603221431.AA03734@bernie.zk3.dec.com> To: johns@baynetworks.com (John Seligson) Cc: agentx@fv.com Subject: Re: 13: Request/Response Dispatching In-Reply-To: Your message of "Thu, 21 Mar 96 16:13:46 PST." <199603220013.QAA00427@turing.engwest> Date: Fri, 22 Mar 96 09:31:24 -0500 From: Mike Daniele X-Mts: smtp Hi John, >I agree. There are a number of products using subagent technology today >where the master <---> subagent channel has less bandwidth (potentially far >less) than the manager <---> agent pipe. Requiring varBind aggregation >for GETs and SETs without upfront negotiation would make this technology >unusable in a number of situations where it is used today. The subagents I know about (admittedly less than you) are connected via TCP, or by a local (same box) high-bandwidth transport (unix-domain sockets, shared memory, etc). Can you help shed some light here? I'm having trouble imagining a situation where it would be preferable to feed a remote subagent 10 30-byte packets, instead of 1 150-byte packet. Thanks, Mike   Delivery-Date: Fri, 22 Mar 1996 06:44:17 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id GAA18852 for X-agentx-local; Fri, 22 Mar 1996 06:44:17 -0800 (PST) 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 GAA18848 for ; Fri, 22 Mar 1996 06:44:16 -0800 (PST) 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 GAA22371 for ; Fri, 22 Mar 1996 06:44:08 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Mar 1996 09:44:09 -0500 To: agentx@fv.com From: bstewart@cisco.com (Bob Stewart) Subject: Re: 22: agentX MIB(s) Circa 8:38 AM 3/22/96, George Best bitwhacked: >Or would the agent and subagent be represented (and monitored) via the >sysAppl MIB and the related Appl MIBs? Good point. Bob   Delivery-Date: Fri, 22 Mar 1996 06:52:10 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id GAA20714 for X-agentx-local; Fri, 22 Mar 1996 06:52:10 -0800 (PST) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id GAA20709 for ; Fri, 22 Mar 1996 06:52:08 -0800 (PST) Received: from flume.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA11835; Fri, 22 Mar 1996 09:40:10 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA15732; Fri, 22 Mar 1996 09:40:09 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA03552; Fri, 22 Mar 1996 09:40:40 -0500 Message-Id: <9603221440.AA03552@bernie.zk3.dec.com> To: Bob Natale Cc: agentx@fv.com Subject: Re: 22: agentX MIB(s) In-Reply-To: Your message of "Thu, 21 Mar 96 19:47:05 EST." Date: Fri, 22 Mar 96 09:40:40 -0500 From: Mike Daniele X-Mts: smtp Bob, >I would like to see us handle master agent configuration items >in such a MIB. This would include such things as MIB views, >community profiles, trap dispatching, etc. In other words, >all the things we'd like to see configurable in a well-equipped >native agent. Ouch. >None of that needs to (or should) include any >explicit exposure of the underlying subagent structure. I would reword this to say, "None of the above has anything to do with Agentx." I don't think any of this is proper for inclusion in an Agentx MIB. As your reply and others state, we must maintain transparency. All agree that an NMS need never look at the Agentx MIB. But we should allow trained technicians to peek under the Agentx hood if they wish to tinker with the engine. It might be VERY helpful to be able to browse the current registry. You know, to find out that the "Hacker" subagent has registered 'iso'... Regards, Mike   Delivery-Date: Fri, 22 Mar 1996 06:53:36 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id GAA21031 for X-agentx-local; Fri, 22 Mar 1996 06:53:36 -0800 (PST) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id GAA21024 for ; Fri, 22 Mar 1996 06:53:35 -0800 (PST) Received: from flume.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA10193; Fri, 22 Mar 1996 09:48:08 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA30989; Fri, 22 Mar 1996 09:48:07 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA03745; Fri, 22 Mar 1996 09:48:39 -0500 Message-Id: <9603221448.AA03745@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: compatibility In-Reply-To: Your message of "Fri, 22 Mar 96 11:43:40 +0700." <199603221044.CAA27880@zloty.fv.com> Date: Fri, 22 Mar 96 09:48:38 -0500 From: Mike Daniele X-Mts: smtp Bert, >I agree that if a new version of some STANDARD protocol is designed, >that it is then important to think about compatibility with the earlier >version. But is it also so important when we design the FIRST version >of a standard, that we try to accomodate (at high cost) all sorts of >proprietary and experimental protocols??? >Personally I would say NO. Maybe IBM (heavily using DPI) would say yes. >But we are here to try and design the best technical and the best >usable agentX protocol... that of course needs to be accepted by the >market-place, otherwise it is also useless. I applaud your stance, given the installed base of DPI usage. And I agree with you. We shouldn't strive necessarily for compatibility, but we SHOULD strive for roughly equivalent functionality. If Agentx isn't strong enough to be used in existing subagent environments, it's useless. Regards, Mike   Delivery-Date: Fri, 22 Mar 1996 07:09:31 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id HAA25144 for X-agentx-local; Fri, 22 Mar 1996 07:09:31 -0800 (PST) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id HAA25141 for ; Fri, 22 Mar 1996 07:09:29 -0800 (PST) Received: from flume.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA05467; Fri, 22 Mar 1996 10:02:25 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA31384; Fri, 22 Mar 1996 10:02:23 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA03555; Fri, 22 Mar 1996 10:02:55 -0500 Message-Id: <9603221502.AA03555@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: 05: SNMPv1/SNMPv2c support In-Reply-To: Your message of "Fri, 22 Mar 96 11:13:59 +0700." <199603221014.CAA22479@zloty.fv.com> Date: Fri, 22 Mar 96 10:02:54 -0500 From: Mike Daniele X-Mts: smtp Bert, Randy, >Now... if we can see quite a big number of "component" vendors to >tell us here that they plan to move old SNMPv1 based instrumentation >to the outcome of the agentX WG, then I'd give in, but I am afraid >not many (if any) are willing to commit that. I agree. We have to assume the existance of SNMPv1 MIBs being implemented in subagents that communicate via agentx. Some standards are even mandating this (Video Consortium, and I believe ATM). >So... then why bother with these extra (obsolet) things? I believe Randy's point is that if you map v1-ness to v2-ness in the subagent and only pass v2-ness to the master, it can't in every case put the correct v1-ness back into the ultimate v1 response. So agentx needs to carry some amount of v1 SMI. Randy just says it better than me :-) (I think it's a data type issue and not so much error codes.) Regards, Mike   Delivery-Date: Fri, 22 Mar 1996 07:42:41 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id HAA03981 for X-agentx-local; Fri, 22 Mar 1996 07:42:38 -0800 (PST) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id HAA03977 for ; Fri, 22 Mar 1996 07:42:37 -0800 (PST) Received: from flume.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA16315; Fri, 22 Mar 1996 10:32:13 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA30849; Fri, 22 Mar 1996 10:32:11 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA03785; Fri, 22 Mar 1996 10:32:42 -0500 Message-Id: <9603221532.AA03785@bernie.zk3.dec.com> To: george.best@antec.com (George Best) Cc: agentx@fv.com Subject: Re: 02: Architecture - Division of Labor In-Reply-To: Your message of "Fri, 22 Mar 96 08:20:03 EST." <199603221320.IAA21181@ta.antec.com> Date: Fri, 22 Mar 96 10:32:40 -0500 From: Mike Daniele X-Mts: smtp >>I propose that all association of registered "subtrees" >>with actual MIB variables, reside in the subagents. >>A variable's OBJECT-TYPE and instantiation are solely the >>responsibility of the subagent, and are invisible to the master. >> >>I'm using "subtree" here to mean whatever we permit with the >>agentx registration syntax. It might be single oids, or ranges, >>etc. George, >So you would mandate that every table is wholly instrumented by one and only >one agent? I don't mean to be niave, but is this a reasonable expectation? >Would this work for the MADMAN MIB set, for example, if you had an MTA from >vendor X and a DSA from vendor Y? Not at all. Table sharing was deemed an absolute must-have for agentx. To help enable that we'll probably provide registration syntax so that for instance subagent A can register 1.3.6.1.2.1.2.2.1.[1-22].1 (interface 1) and subagent B can register 1.3.6.1.2.1.2.2.1.[1-22].2, etc. All I'm suggesting is that this is ALL the registration consists of (at least with respect to MIB speficiations). I'd prefer to see these registered oids (that I loosely call "subtrees") associated with actual MIB variables out in the respective subagents, not within the master agent. The subagent should figure out which of its instantiated MIB variables it should return, if the syntax was right, if it implements the required access, etc. Do we really want the master agent to try and do all that? Regards, Mike   Delivery-Date: Fri, 22 Mar 1996 08:28:07 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id IAA14858 for X-agentx-local; Fri, 22 Mar 1996 08:28:06 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id IAA14815 for ; Fri, 22 Mar 1996 08:28:03 -0800 (PST) Message-Id: <199603221628.AA023752120@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA023752120; Fri, 22 Mar 1996 08:28:41 -0800 Date: Fri, 22 Mar 1996 08:28:41 -0800 From: Randy Presuhn To: agentx@fv.com Subject: Re: compatibility Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > Message-Id: <9603221448.AA03745@bernie.zk3.dec.com> > To: agentx@fv.com > Subject: Re: compatibility > In-Reply-To: Your message of "Fri, 22 Mar 96 11:43:40 +0700." <199603221044.CAA27880@zloty.fv.com> > Date: Fri, 22 Mar 96 09:48:38 -0500 > From: Mike Daniele ... > We shouldn't strive necessarily for compatibility, but we > SHOULD strive for roughly equivalent functionality. Yes. That means not adding constraints that would preclude information flow (e.g. old error codes and data types) supported by the existing technologies, especially when adding such constraints increases the complexity of both specification and of implementation. > If Agentx isn't strong enough to be used in existing subagent > environments, it's useless. ... Amen. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Fri, 22 Mar 1996 08:30:39 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id IAA15586 for X-agentx-local; Fri, 22 Mar 1996 08:30:38 -0800 (PST) Received: from ta.antec.com ([205.187.171.11]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id IAA15583 for ; Fri, 22 Mar 1996 08:30:37 -0800 (PST) Received: from pc_georgeb by ta.antec.com via SMTP (8.6.12/8.6.4) id LAA22177; Fri, 22 Mar 1996 11:18:31 -0500 Date: Fri, 22 Mar 1996 11:18:31 -0500 Message-Id: <199603221618.LAA22177@ta.antec.com> X-Sender: georgeb@bopper.ta.antec.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Mike Daniele From: george.best@antec.com (George Best) Subject: Re: 02: Architecture - Division of Labor Cc: agentx@fv.com At 10:32 AM 3/22/96 -0500, Mike Daniele wrote: >>>I propose that all association of registered "subtrees" >>>with actual MIB variables, reside in the subagents. >>>A variable's OBJECT-TYPE and instantiation are solely the >>>responsibility of the subagent, and are invisible to the master. >>> >>>I'm using "subtree" here to mean whatever we permit with the >>>agentx registration syntax. It might be single oids, or ranges, >>>etc. > >George, > >>So you would mandate that every table is wholly instrumented by one and only >>one agent? I don't mean to be niave, but is this a reasonable expectation? >>Would this work for the MADMAN MIB set, for example, if you had an MTA from >>vendor X and a DSA from vendor Y? > >Not at all. Table sharing was deemed an absolute must-have for agentx. >To help enable that we'll probably provide registration syntax so that >for instance subagent A can register 1.3.6.1.2.1.2.2.1.[1-22].1 (interface 1) >and subagent B can register 1.3.6.1.2.1.2.2.1.[1-22].2, etc. > >All I'm suggesting is that this is ALL the registration consists >of (at least with respect to MIB speficiations). I'd prefer to see >these registered oids (that I loosely call "subtrees") associated >with actual MIB variables out in the respective subagents, not within >the master agent. > >The subagent should figure out which of its instantiated MIB variables >it should return, if the syntax was right, if it implements the required >access, etc. > >Do we really want the master agent to try and do all that? > >Regards, >Mike > It sounds like registering by OID for scalars and registering by "rows" for tables. Is that what you're proposing? (yes, if there are no tables in the MIB and it's all supported by one sub-agent, you could treat the whole MIB as a "subtree") Gb - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - George Best email: georgeb@antec.com Digital Video, Norcross GA, USA voice: (770)734-0400 ext. 8534   Delivery-Date: Fri, 22 Mar 1996 08:39:53 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id IAA18123 for X-agentx-local; Fri, 22 Mar 1996 08:39:53 -0800 (PST) Received: from DRAGON.COM (dragon.com [155.229.20.1]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id IAA18108 for ; Fri, 22 Mar 1996 08:39:50 -0800 (PST) From: cheryl@empiretech.com Received: by dragon.com (MX V4.1 VAX) with UUCP; Fri, 22 Mar 1996 11:38:44 EST Received: (from cheryl@localhost) by emptech.empiretech.com (8.6.12/8.6.12) id LAA27433; Fri, 22 Mar 1996 11:32:43 -0500 Message-ID: <199603221632.LAA27433@emptech.empiretech.com> Subject: Re: 22: agentX MIB(s) To: Date: Fri, 22 Mar 1996 11:32:43 -0500 (EST) CC: rturner@mail.sharplabs.com, agentx@fv.com In-Reply-To: <199603221338.IAA21256@ta.antec.com> from "George Best" at Mar 22, 96 08:38:14 am X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > >At 02:54 PM 3/21/96 -0800, Randy Turner wrote: >> >>Using the MIB for debugging and verification of subagent status would be very >>helpful, but only for developers. But as a fundamental idea, the MIB seems >>to fly in the face of the requirment for transparency. >> >Or would the agent and subagent be represented (and monitored) via the >sysAppl MIB and the related Appl MIBs? No. Take a look at the subagent mib that bert posted. The infor reflected in that MIB is far more specific to the case of mstr-component agent than anything that we would have in the sysAppl or even a generic applications mib. You would need a specific MIB for this type of info -- i.e. Bert's sa mib. > >Gb >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >George Best email: georgeb@antec.com >Digital Video, Norcross GA, USA voice: (770)734-0400 ext. 8534 +--------------------------------------------------------------------+ + Check us out! http://www.empiretech.com/empiretech + +--------------------------------------------------------------------+ + Cheryl Krupczak Empire Technologies, Inc. + + cheryl@empiretech.com 541 Tenth Street NW + + PH : (770)384-0184 Suite 169 + + FAX: (770)384-0183 Atlanta, GA 30318 + +--------------------------------------------------------------------+   Delivery-Date: Fri, 22 Mar 1996 08:46:33 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id IAA20026 for X-agentx-local; Fri, 22 Mar 1996 08:46:32 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id IAA19987 for ; Fri, 22 Mar 1996 08:46:30 -0800 (PST) Message-Id: <199603221647.AA024173222@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA024173222; Fri, 22 Mar 1996 08:47:02 -0800 Date: Fri, 22 Mar 1996 08:47:02 -0800 From: Randy Presuhn To: agentx@fv.com Subject: Re: 05: SNMPv1/SNMPv2c support Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit hi - > Message-Id: <9603221502.AA03555@bernie.zk3.dec.com> > To: agentx@fv.com > Subject: Re: 05: SNMPv1/SNMPv2c support > In-Reply-To: Your message of "Fri, 22 Mar 96 11:13:59 +0700." <199603221014.CAA22479@zloty.fv.com> > Date: Fri, 22 Mar 96 10:02:54 -0500 > From: Mike Daniele ... > I believe Randy's point is that if you map v1-ness to v2-ness > in the subagent and only pass v2-ness to the master, it can't > in every case put the correct v1-ness back into the ultimate > v1 response. So agentx needs to carry some amount of v1 SMI. ... The mapping of v2-ness to v1-ness is actually pretty easy. What doesn't work is to map v1-ness to v2-ness if the "obsolete" error codes and data types are precluded. For example, if the existing instrumentation only knows how to say "badValue", a run-time library may not be able to determine which of several v2 erorr codes is the correct one to use. It is precisely for this reason that these old codes are still included in the v2 syntax. Prohibiting their use will only clutter the specification and result in "fabricated" error codes returned on behalf of legacy instrumentation. The definitions in the v2 specifications are fine. Let's not gild the lily any more than is absolutely necessary. > (I think it's a data type issue and not so much error codes.) We have to be able to shovel around Network address and Opaque things, even if we feel we should wash our hands afterwards. I'm only asking that we not constrain the subagent protocol to be less capable than SNMPv2. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Fri, 22 Mar 1996 08:55:01 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id IAA22166 for X-agentx-local; Fri, 22 Mar 1996 08:55:00 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id IAA22150 for ; Fri, 22 Mar 1996 08:54:59 -0800 (PST) Message-Id: <199603221655.AA024423737@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA024423737; Fri, 22 Mar 1996 08:55:37 -0800 Date: Fri, 22 Mar 1996 08:55:37 -0800 From: Randy Presuhn To: agentx@fv.com Subject: Re: 02: Architecture - Division of Labor Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - |Date: Fri, 22 Mar 1996 08:20:03 -0500 |Message-Id: <199603221320.IAA21181@ta.antec.com> |To: agentx@fv.com |From: george.best@antec.com (George Best) |Subject: Re: 02: Architecture - Division of Labor | |At 03:23 PM 3/21/96 -0500, Mike Daniele wrote: | |>I propose that all association of registered "subtrees" xxxxxxxxxxx (I prefer the term "binding") |>with actual MIB variables, reside in the subagents. |>A variable's OBJECT-TYPE and instantiation are solely the |>responsibility of the subagent, and are invisible to the master. |> |>I'm using "subtree" here to mean whatever we permit with the |>agentx registration syntax. It might be single oids, or ranges, |>etc. | |So you would mandate that every table is wholly instrumented by one and only |one agent? I don't see how this conclusion follows from Mike's proposal. There are already products that have the property he describes that do allow a table to be implemented by multiple subagents. There's no conflict in these requirements. | I don't mean to be niave, but is this a reasonable expectation? Support for having different portions of a table implemented by different subagents seems to be a generally agreed requirement. |Would this work for the MADMAN MIB set, for example, if you had an MTA from |vendor X and a DSA from vendor Y? We're in agreement that we need to support configurations like this. Mike's proposal is not in conflict with this requirement. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Fri, 22 Mar 1996 09:01:01 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA23983 for X-agentx-local; Fri, 22 Mar 1996 09:01:00 -0800 (PST) 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 JAA23957 for ; Fri, 22 Mar 1996 09:00:54 -0800 (PST) Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA22206; Fri, 22 Mar 96 09:00:46 PST Received: from santa.strata.com by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-931007-1) id AA07673; Fri, 22 Mar 96 09:00:45 PST Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA09791; Fri, 22 Mar 96 09:00:44 PST Date: Fri, 22 Mar 96 09:00:44 PST From: dfrancisco@santa.stratacom.com (Dale Francisco) Message-Id: <9603221700.AA09791@santa.strata.com> To: agentx@fv.com Subject: Final version of L.A. IETF minutes Cc: natale@acec.com Here's the final version of the minutes of the recent agentx meetings at the L.A. IETF. A few typos have been corrected. Also, the description of DPI's handling of registration has been modified in response to comments by Bob Natale and Bert Wijnen. Cordially, Dale Francisco Software Engineering StrataCom 93 South La Patera Lane Santa Barbara CA 93117 voice: (805) 961-3642 fax: (805) 961-3600 Agentx WG at 35th IETF, March 4-8, 1996 --------------------------------------- At the 35th IETF in Los Angeles, March 4-8, 1996, the SNMP Agent Extensibility Working Group (agentx) had two meetings, one on Tuesday, March 5, 19:30-22:00, and the other on Wednesday, March 6, 15:30-17:30. The most active participants in the discussions (a few names were missed due to inattentiveness on the part of the note-taker) were: Uri Blumenthal, David Bridgham, Jeff Case, Mike Daniele, Maria Greene, Bob Natale, Dave Perkins, Randy Presuhn, Bob Stewart, Glenn Waters, and Bert Wijnen. About 40 people were present at the meetings. Meeting notes were taken by Dale Francisco, wg editor. Meeting 1 (Tue, March 5, 19:30-22:00) ------------------------------------- WG chair Bob Natale opened the meeting with a brief allusion to the long history of discussions on SNMP agent extensibility, a summary of the formation of the agentx wg, and a review of its charter. He called for presentations from anyone with a prepared topic. He introduced meeting participants who have been active in the discussion and implementation of extensible agents. The chair expressed the hope that the agentx wg could benefit from the long experience of extensible agent products such as SMUX, DPI, eSNMP, EMANATE, Envoy, and others. He stressed that the goal of agentx was to come up with a simple, widely applicable protocol that would solve interoperability problems and that vendors of existing commercial extensible agents would see as a complement, not a threat, to their products. He asked that we focus on these deployed solutions ("the solution space") as a starting point, and try to avoid endless, circular discussions of the many "interesting" problems associated with agentx. He mentioned that there was general consensus that the original wg schedule, which called for a final internet draft by May, 1996, was unrealistically tight, and that one of the goals of this meeting would be to agree on a new, more rational schedule that could be presented to the Area Director for consideration. There was a discussion of why DPI and some other extensible agent products had chosen not to use SNMP for communication between master and subagents, the main argument being that writing subagents should be as simple as possible. Some questioned whether the alternatives to SNMP (such as DPI bit-specified messages) were really simpler. There was also a question as to whether using a non-SNMP encoding meant that the agentx protocol would be limited, for security reasons, to communication among agents on the same box. It was suggested that this was really a transport mapping issue, and that security should not be considered explicitly in the first version of agentx. Maria Greene gave a presentation on "Coordinating Index Value Assignments". The problem: In order to allow different component agents to be responsible for different rows in the same table, a method must be agreed upon for handing out indices to the rows of that shared table. Maria's solution involves three MIB objects implemented in a single component agent. There would be three such objects for each shared table. The objects are: (1) nextIndex, the value of the next available index; (2) Lock, a TestAndIncr or `spin lock' object used to coordinate the assignment of indices; and (3) numIndices, the number of indices that the component agent wants. A component agent that wants one or more indices temporarily takes on a manager role to manipulate these objects, or uses some other implementation-dependent method. Jeff Case noted that EMANATE does something similar, but instead of having a separate set of objects for each shared table, it has a single "reservation table" in a single "reservation subagent". In addition to the index coordination provided by Maria's solution, Jeff's solution also encompasses pre-configured, "dedicated" indices for special purposes, and the ability of the reservation subagent to go out and find which indices are already in use when it comes up. Jeff said that he would consider publishing his "reservation MIB". This led to a brief discussion of communication between subagents, subagent-to-subagent Get requests, and the necessity (or not) of multithreading to support this. There was also a discussion of whether reservation functionality ought to be in the master agent, or whether it should be left to the implementor to decide on placing it either in the master agent or a component agent. A question about the agentx protocol formulation led to Bob Natale's proposal that agentx use DPI version 2.0 as a base document. He also suggested that three small working groups take on the tasks of (1) specifying requirements, (2) initial protocol specification, and (3) agentx MIB. He asked that participants be prepared by the next day's meeting to commit to a realistic (TBD) schedule for fulfilling the agentx charter. Meeting 2 (Wednesday, March 6, 15:30-17:30) ------------------------------------------- The chair opened the meeting with the announcement that Bert Wijnen and Mike Daniele had volunteered to work on the initial protocol specification, and Maria Greene would be working on an agentx MIB. He then began a discussion of a list of issues which he hoped could be refined into a firm set of requirements for the agentx protocol. The following issues were briefly discussed: GetNext across subagents. A requirement. Tables shared across subagents. A requirement. Subagent MIB. Probably a requirement--Maria Greene to investigate. Multiphase Set for "as if simultaneous" Sets. Disposition unclear. Randy Presuhn volunteered to post a summary of an off-list discussion of multiphase Set. Problems with sysUpTime across subagents, possibly on different physical systems; detecting counter discontinuities; and timestamps for event logs. Disposition unclear. How much (if any) of the header information in the SNMP PDU received by the master agent should be visible to subagents. Disagreement on this. Access control. Should be concentrated in the master agent. Effect of subagents dying and restarting on sysUpTime, subagent-specific timestamps, and registration. Disposition unclear. Cross-subagent communication. Disagreement over whether this is a requirement. Some felt that it was a prerequisite for index reservation. There was disagreement over whether it necessitated support for multithreading in subagents. SNMPv2 compatibility. A requirement. Per varbind vs. per packet. Previously decided in favor of per varbind. Use of ASN.1 and BER in agentx protocol specification. Disagreement on this. Some argued that ASN.1 should be used as a description language, but not mandate use of BER for actual encoding. What is subject to registration? Subtrees, ranges, partial indexes, objects, instances? Are overlapping registrations required? Disposition unclear. Dispatch policy, priorities. Disposition unclear. Reservation protocol. Are some pre-reserved indices a requirement? With a half hour remaining, the chair asked that the discussion of requirements be continued on the mailing list, and that Bert Wijnen use the remaining time to give an overview of DPI and registration issues. Bert briefly discussed DPI subagent registration and outlined differences between the current DPI implementation and some of the registration strategies mentioned earlier in the meeting. DPI supports, but does not mandate, multiple varbinds per subagent packet. Thus a subagent cannot assume that all of the varbinds from one SNMP request will be delivered to it in a single subagent packet. DPI supports registration priority, but Bert questioned whether this was an agentx requirement. His current implementation of DPI does not support overlapping registration, but it is not precluded by the DPI spec. Shared tables and instance registration would be problematic under the DPI 2.0 spec. The chair asked for suggestions on a reasonable schedule for completing agentx work. Bert Wijnen volunteered to write a first draft of an agentx protocol specification, but noted that, as a result of all the new requirements he had just learned of, it might take longer than he had originally planned. He had originally hoped to have something by June 1996. The chair asked that we drive towards rough draft documents by June, and that discussion and resolution of requirements be continued on the mailing list. [LA IETF minutes, final revision: Wed Mar 20 10:07:17 PST 1996]   Delivery-Date: Fri, 22 Mar 1996 09:08:36 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA26114 for X-agentx-local; Fri, 22 Mar 1996 09:08:35 -0800 (PST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id JAA26109 for ; Fri, 22 Mar 1996 09:08:34 -0800 (PST) Received: from flume.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA27809; Fri, 22 Mar 1996 11:55:16 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA10334; Fri, 22 Mar 1996 11:56:42 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA03834; Fri, 22 Mar 1996 11:57:14 -0500 Message-Id: <9603221657.AA03834@bernie.zk3.dec.com> To: george.best@antec.com (George Best) Cc: agentx@fv.com Subject: Re: 02: Architecture - Division of Labor In-Reply-To: Your message of "Fri, 22 Mar 96 11:18:31 EST." <199603221618.LAA22177@ta.antec.com> Date: Fri, 22 Mar 96 11:57:13 -0500 From: Mike Daniele X-Mts: smtp >It sounds like registering by OID for scalars and registering by "rows" for >tables. Is that what you're proposing? No. We should support registration of (essentially) oids. The oids could represent anything a subagent wishes. mib-2, hrDeviceDescr.3, ifTable, etc. What these oids actually name within the MIB should be completely transparent to the master agent. >(yes, if there are no tables in the MIB and it's all supported by >one sub-agent, you could treat the whole MIB >as a "subtree") Perhaps its my use of the term "subtree" that's confusing. If you register 1.2.3.4.5, and a request arrives for 1.2.3.4.5.6.7.8, the master agent must send that request to you (ignoring any other registrations that might impact dispatching). In this sense, 1.2.3.4.5 is a "subtree". Now in fact, 1.2.3.4.5 might be an instance of an object defined in an enterprise-specific MIB you support, in which case you'd return an appropriate error (nosuchObject) for 1.2.3.4.5.6.7.8. Or 1.2.3.4 might be the name of that MIB, that is, you chose to register the entire MIB. And further, you currently have an instance 8 of column 7 of entry 6 in table 5 of your mib 1.2.3.4, in which case you'd return a successful data response. But wait! It was a Set request and you don't implement write access to it. You should return an error. I suggest that the master agent shouldn't care what 1.2.3.4.5 is, or what 1.2.3.4.5.6.7.8 is, it should only care that 1.2.3.4.5.6.7.8 falls within the subtree that must be assumed to exist below 1.2.3.4.5. Regards, Mike   Delivery-Date: Fri, 22 Mar 1996 09:23:47 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA00425 for X-agentx-local; Fri, 22 Mar 1996 09:23:46 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id JAA00411 for ; Fri, 22 Mar 1996 09:23:42 -0800 (PST) Message-Id: <199603221724.AA025105460@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA025105460; Fri, 22 Mar 1996 09:24:20 -0800 Date: Fri, 22 Mar 1996 09:24:20 -0800 From: Randy Presuhn To: agentx@fv.com Subject: Re: 13: Request/Response Dispatching Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > From: "David Ward" > Message-Id: <9603220629.ZM27609@pessys5.hns.com> > Date: Fri, 22 Mar 1996 06:29:36 -0500 > In-Reply-To: Randy Presuhn > "Re: 13: Request/Response Dispatching" (Mar 21, 2:46pm) > References: <199603212246.AA004398371@dorothy.peer.com> > To: Randy Presuhn , agentx@fv.com > Subject: Re: 13: Request/Response Dispatching ... > As I stated in a previous message, in a satellite network, the varbinds > would always need to be passed to the subagent in a single pdu regardless > of the original pdu type passed between the manager and agent. This is > necessary because the master agent will not know the performance > requirements of actually satisfying the get xxx request (only the > subagent can discern that). We're actually in agreement. > I can see the dilemma here in regards to > getNext and getBulk since the master agent really doesn't know which varbinds > will be accessed. In our small world, we do the following: > > 1. getRequest, getNext, and getBulk are transformed into a single > getVarbinds message before being passed onto the subagent. In > the getVarbinds message is a list of varbinds to be satisfied. > For each varbind is listed the following: > > - Originally requested varbind OID. This is an overspecification. In some cases, it is possible to compute a probe value based on the original varbind OID and the access controls in effect that will significantly reduce the amount of iteration required to produce a correct result. > - Type of value requested (N/A for getNext and getBulk). Also not applicable for get. > - Whether or not lexicographic successors are requested > (N/A for getRequest). > - Number of repetitions to perform (set to 1 for both getRequest > and getNext as well as for the non-repeaters in getBulk). > > 2. This getVarbinds message is then passed to the subagent. > > 3. The subagent creates an associated response message (looks similar to > the getVarbinds message with the addition of the real value type, a > status, value length and the value. > > 4. The master agent collects all of the response messages from the subagents, > creates a Response PDU, and ships the Response PDU back to the manager. This will fail for boundary conditions, such as when a get-next or get-bulk iterates past the end of a subagent's area of responsibility. The process is necessarily iterative. There are some opportunities for parallelism in the initial probe, and I fully agree that these should be exploited. > Thus, with one message, we've encompassed all of the getxxx PDUs. > Unfortunately, > for you, this negates the ability to talk SNMP between the master agent > and the subagents (not a requirement for us, obviously). This is not a requirement for anyone, as far as I can tell. If SNMP were itself sufficient as a subagent protocol, none of this discussion would be needed. > In addition, it > doesn't allow any fine grained control over the variables requested of a > subagent when getNext and getBulk are used (all control is based on the > varbind specified in the original request, and not those actually retrieved). Agreed. This won't meet the requirements of most access control proposals. > The fine grained control in this case is very tricky, and I can see why > it poses so much trouble for this working group. Perhaps satisfying getNext > and getBulk is an iterative process where you pass it to a subagent based > on the originally requested varbinds. It is indeed iterative, but the probe OID sent to a subagent is not necessarily the same as what appeared in the original request from the management station. (If a response has been excluded by access control, it won't help matters to ask the same subagent the same question again.) > That subagent satisfies as many > varbinds as it can. Upon receiving the subagent's response, the master > agent must then see if other subagents are present that can give more > information, and passes it to them. This continues until there is no more > information to retrieve from any subagents. ... Yes. Wildcarding in access control can result in the master agent needing to send a re-formulated request back to that same subagent as well. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Fri, 22 Mar 1996 09:30:09 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA02168 for X-agentx-local; Fri, 22 Mar 1996 09:30:07 -0800 (PST) Received: from epilogue.com (quern.epilogue.com [128.224.1.136]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id JAA02145 for ; Fri, 22 Mar 1996 09:30:04 -0800 (PST) From: dab@epilogue.com Received: from dab.gate with DMSP Date: 22 Mar 1996 10:27:19 -0700 To: agentx@fv.com In-reply-to: Uri Blumenthal's message of Thu, 21 Mar 1996 17:59:40 -0500 (EST) <9603212259.AA36091@hawpub.watson.ibm.com> Subject: Re: 05: sysUpTime Sender: dab@epilogue.com Repository: quern.epilogue.com Originating-client: gate Message-ID: <9603221229.aa24673@quern.epilogue.com> Well, why then reset sysUpTime at all? All that gets screwed up is statistics gathered? Are you saying that it's okay to screw up the statistics gathering capability of SNMP? I'd say it's the most used feature at the moment. I'd prefer [as I said in the past :-] that every subagent-related object or group should have it's own UpTime, because it's clear that one "central" sysUpTime is not enough to deal with several asynchronous entities (subagents) that come and go... If it were possible to determine when a MIB is designed how the variables and groups would be divided amonst the sub-agents, this might work. I'm missing something. Some counters got "zeroed" and you want to recognize it by resetting sysUptime. That is the current SNMP (MIB?) standard. Some other counters will get messed up by that resetting, but you don't care? No, no other counters get messed up. But for all counters that reference off sysUptime, the mangement station can't tell which ones did and which didn't. Why bother then resetting sysUpTime at all? What is it going to tell you? What is it telling you now? By not resetting sysUptime, you're proposing that when a counter does get scrambled we don't let the management station know about it at all. Not a choice I'd make. Dave   Delivery-Date: Fri, 22 Mar 1996 09:37:13 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA04012 for X-agentx-local; Fri, 22 Mar 1996 09:37:12 -0800 (PST) Received: from epilogue.com (quern.epilogue.com [128.224.1.136]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id JAA04006 for ; Fri, 22 Mar 1996 09:37:11 -0800 (PST) From: dab@epilogue.com Received: from dab.gate with DMSP Date: 22 Mar 1996 10:35:08 -0700 To: agentx@fv.com In-reply-to: Bob Natale's message of Thu, 21 Mar 1996 18:57:02 EST Subject: Re: 14: sysUpTime Sender: dab@epilogue.com Repository: quern.epilogue.com Originating-client: gate Message-ID: <9603221236.aa24722@quern.epilogue.com> > Well, why then reset sysUpTime at all? All that gets screwed up > is statistics gathered? Right...I think we are leaning toward not resetting sysUpTime on counter discontinuities...Randy had a good posting on this (and thanks for re-posting Joey's convincing analysis!). So you're ready to throw out SNMP as a statistics gathering tool too? I MUST be missing something here. There's transparency and there's loss of information. It's bad enough that you want to hide information from the manager, but I think it's a REALLY bad idea to pass bad information. Is this sort of change to SNMP really in the scope of this group? I suppose management stations could examine the second derivative of the polled counter data to try and guess if the counter has reset. But a short lived spike in whatever event the counter is counting would then be indistinguishable from a counter reset. Those one time spikes could be very interesting. Dave   Delivery-Date: Fri, 22 Mar 1996 10:00:09 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id KAA09843 for X-agentx-local; Fri, 22 Mar 1996 10:00:08 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id KAA09813 for ; Fri, 22 Mar 1996 10:00:05 -0800 (PST) Message-Id: <199603221800.AA026897641@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA026897641; Fri, 22 Mar 1996 10:00:42 -0800 Date: Fri, 22 Mar 1996 10:00:42 -0800 From: Randy Presuhn To: agentx@fv.com Subject: Re: 13: Request/Response Dispatching Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > From: ralex@world.std.com (Aleksey Y Romanov) > Message-Id: <199603221213.AA16945@world.std.com> > Subject: Re: 13: Request/Response Dispatching > To: wijnen@vnet.ibm.com (Bert Wijnen) > Date: Fri, 22 Mar 1996 07:13:47 -0500 (EST) > Cc: agentx@fv.com > In-Reply-To: <199603221035.CAA26218@zloty.fv.com> from "Bert Wijnen" at Mar 22, 96 11:35:08 am ... > > > I hope we can agree: > > > in processing a set (or simple get) operation, a master agent > > > will not send varbinds to a subagent for which that subagent > > > has not claimed responsibility. ... > I have a problem here - it means among other things that master-agent > knows and verifies details of (a) indexing, (b) holes in registration ... The master agent only needs to know that a particular subagent has claimed responsibility for some portion of the OID space. That claim might be communicated as a subtree, regular expression, or whatever. > tree - I am not against this, however I would like for everybody to > understand that there is substantial overhead involved here both during > registration and operation phase. I would like to note also that > despite 1000's of lines of postings about registering overlapping rows > I did not see anything yet which will provide simple/robust/generic > mechanism for row creation in this environment (*). You're right that more detail is needed in describing reservation. At the Los Angeles meeting we discussed a proposal by Jeff Case for reservation tracking in terms of a table. Maria and others went into some detail about how it could be used to meet reservation requirements. > BTW, if we are going to go ther way of 'master-agent knows all details > about sub-agent variable space' indeed than let us use ALL positive > sides of this approach - there are many of them still untapped. ... I'd rather go the other direction, that of minimizing the amount of knowledge that has to be maintained at the master agent. > What if NMS <->master-agent MTU is much bigger than master<->sub-agent > MTU ? ... I haven't seen an environment like this yet. Did you have something specific in mind? I'd like to be sure we're not cutting off any significant opportunities here. We also need to make sure that we don't confuse lower-layer MTU with the QOS provided by the transport used by the agentx protocol. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Fri, 22 Mar 1996 10:24:38 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id KAA16114 for X-agentx-local; Fri, 22 Mar 1996 10:24:38 -0800 (PST) Received: from lightning.synoptics.com (lightning.synoptics.com [134.177.3.18]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id KAA16104 for ; Fri, 22 Mar 1996 10:24:35 -0800 (PST) Received: from pobox ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA28044; Fri, 22 Mar 96 10:24:01 PST Received: from turing.engwest by pobox (4.1/SMI-4.1) id AA00166; Fri, 22 Mar 96 10:19:30 PST Received: from coachese.engwest by turing.engwest (SMI-8.6/SMI-SVR4) id KAA01979; Fri, 22 Mar 1996 10:15:56 -0800 Date: Fri, 22 Mar 1996 10:15:56 -0800 From: johns@BayNetworks.COM (John Seligson) Message-Id: <199603221815.KAA01979@turing.engwest> To: daniele@zk3.dec.com Subject: Re: 13: Request/Response Dispatching Cc: agentx@fv.com Hi Mike, > >I agree. There are a number of products using subagent technology today > >where the master <---> subagent channel has less bandwidth (potentially far > >less) than the manager <---> agent pipe. Requiring varBind aggregation > >for GETs and SETs without upfront negotiation would make this technology > >unusable in a number of situations where it is used today. > The subagents I know about (admittedly less than you) are connected > via TCP, or by a local (same box) high-bandwidth transport (unix-domain > sockets, shared memory, etc). > Can you help shed some light here? I'm having trouble imagining > a situation where it would be preferable to feed a remote subagent > 10 30-byte packets, instead of 1 150-byte packet. I'm not suggesting messages on the order of 30 bytes or even 150 bytes. Many of the MIBs today define objects with potentially quite large instance components (e.g., tables instanced by multiple ATM addresses are common). Now for OCTET STRING OBJECT-TYPE objects, single varBinds could easily exceed 150 bytes. Now consider conceptual rows containing 10 or 20 columns where, say, half are required to successfully create a new row. A one-shot create-and-go now requires a fairly sizable message be passed between the master agent and the subagent. Personally, I have run into bandwidth limitations in shared memory IPC environments. These limitations have come in two forms, the first being message size limitations imposed by the IPC mechanism. The second being the memory management component in high performance environments. In this case, available memory is often preallocated into buffer pools of various sizes. The same pool is always used for certain types of communication (e.g., master agent <---> subagent IPC). Since memory is an extremely scarce resource, buffer size and quantity in a given pool must be tuned to the usage. You don't want to drop packets being routed due to buffer exhaustion because you have allocated SNMP message buffers large enough to handle any request. This leaves us with having to come up with a reasonable maximum message size and I would argue that this realistically can't be done. New MIBs can always be defined with larger conceptual rows requiring any number of mandatory objects to allow row creation. A realistic max message size estimate can be attained if one allows single varBinds to be passed between the various components. This is simply a case a trade-offs. You can say that all varBinds destined for a subagent as part of a SET will be packaged in a single message (Q: will this be all of the varBinds associated with a single row or all varBinds for all rows supported by an SA?). This forces one to support varying, possibly quite large message sizes or this forces additional overhead into each message to support fragmentation and reassembly. As an alternative, you can support a negotiation process which allows a subagent to say whether it would like one or N varBinds per message. Or you can just always pass one varBinds at a time and forget negotiation in the name of simplicity. Please let me know if I'm missing something with regard to the current proposals. John   Delivery-Date: Fri, 22 Mar 1996 11:28:10 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id LAA02373 for X-agentx-local; Fri, 22 Mar 1996 11:28:08 -0800 (PST) Received: from mail.sharplabs.com ([204.75.175.200]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id LAA02262 for ; Fri, 22 Mar 1996 11:28:00 -0800 (PST) Received: from sla5c by mail.sharplabs.com (SMI-8.6/SMI-SVR4) id LAA07220; Fri, 22 Mar 1996 11:25:47 -0800 From: rturner@mail.sharplabs.com (Randy Turner) Received: by sla5c (SMI-8.6) id LAA05637; Fri, 22 Mar 1996 11:25:38 -0800 Date: Fri, 22 Mar 1996 11:25:38 -0800 Message-Id: <199603221925.LAA05637@sla5c> To: daniele@zk3.dec.com, johns@BayNetworks.com Subject: Re: 13: Request/Response Dispatching Cc: agentx@fv.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: CBKInhlj56yfF/uwhcnJsw== I basically agree with John's argument below, its nice to have a small lightweight agentx protocol and I'm all for that, however, the particular issue with master<-->subagent transports involves architectural and cost decisions for certain manufacturers and we don't want to ram something through and play hard ball. After all, what good is a standard if no one implements it. Allowing negotiatable subagent capabilities would require more work, no debate here, but I think it is very easy to rationalize why we need it, and it would allow further extensions to the protocol in the future without a complete re-do, and possible break, of the original agentx installed base. Randy > From johns@BayNetworks.com Fri Mar 22 10:55:01 1996 > Resent-From: agentx-owner@fv.com > Comment: Posted to the agentx Mailing List To unsubscribe, send mail to agentx-request@fv.com with "unsubscribe" in the Subject > Resent-Date: Fri, 22 Mar 1996 10:24:40 -0800 > Resent-Message-ID: <16122.827519080.1@fv.com> > Date: Fri, 22 Mar 1996 10:15:56 -0800 > From: johns@BayNetworks.com (John Seligson) > To: daniele@zk3.dec.com > Subject: Re: 13: Request/Response Dispatching > Cc: agentx@fv.com > > > Hi Mike, > > > >I agree. There are a number of products using subagent technology today > > >where the master <---> subagent channel has less bandwidth (potentially far > > >less) than the manager <---> agent pipe. Requiring varBind aggregation > > >for GETs and SETs without upfront negotiation would make this technology > > >unusable in a number of situations where it is used today. > > > The subagents I know about (admittedly less than you) are connected > > via TCP, or by a local (same box) high-bandwidth transport (unix-domain > > sockets, shared memory, etc). > > > Can you help shed some light here? I'm having trouble imagining > > a situation where it would be preferable to feed a remote subagent > > 10 30-byte packets, instead of 1 150-byte packet. > > I'm not suggesting messages on the order of 30 bytes or even 150 bytes. > Many of the MIBs today define objects with potentially quite large instance > components (e.g., tables instanced by multiple ATM addresses are common). > Now for OCTET STRING OBJECT-TYPE objects, single varBinds could easily > exceed 150 bytes. Now consider conceptual rows containing 10 or 20 columns > where, say, half are required to successfully create a new row. A one-shot > create-and-go now requires a fairly sizable message be passed between the > master agent and the subagent. > > Personally, I have run into bandwidth limitations in shared memory IPC > environments. These limitations have come in two forms, the first being > message size limitations imposed by the IPC mechanism. The second being > the memory management component in high performance environments. In this > case, available memory is often preallocated into buffer pools of various > sizes. The same pool is always used for certain types of communication (e.g., > master agent <---> subagent IPC). Since memory is an extremely scarce > resource, buffer size and quantity in a given pool must be tuned to the > usage. You don't want to drop packets being routed due to buffer exhaustion > because you have allocated SNMP message buffers large enough to handle > any request. > > This leaves us with having to come up with a reasonable maximum message > size and I would argue that this realistically can't be done. New MIBs can > always be defined with larger conceptual rows requiring any number of > mandatory objects to allow row creation. A realistic max message size > estimate can be attained if one allows single varBinds to be passed between > the various components. > > This is simply a case a trade-offs. You can say that all varBinds destined > for a subagent as part of a SET will be packaged in a single message (Q: > will this be all of the varBinds associated with a single row or all varBinds > for all rows supported by an SA?). This forces one to support varying, > possibly quite large message sizes or this forces additional overhead into > each message to support fragmentation and reassembly. As an alternative, > you can support a negotiation process which allows a subagent to say whether > it would like one or N varBinds per message. Or you can just always pass one > varBinds at a time and forget negotiation in the name of simplicity. > > Please let me know if I'm missing something with regard to the current > proposals. > > John > > ================ > 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: Fri, 22 Mar 1996 12:34:06 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id MAA19943 for X-agentx-local; Fri, 22 Mar 1996 12:34:05 -0800 (PST) Received: from europe.std.com (europe.std.com [192.74.137.10]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id MAA19906 for ; Fri, 22 Mar 1996 12:34:01 -0800 (PST) Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id PAA06252; Fri, 22 Mar 1996 15:33:45 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA26510; Fri, 22 Mar 1996 15:30:57 -0500 From: ralex@world.std.com (Aleksey Y Romanov) Message-Id: <199603222030.AA26510@world.std.com> Subject: Re: 13: Request/Response Dispatching To: rpresuhn@peer.com (Randy Presuhn) Date: Fri, 22 Mar 1996 15:30:57 -0500 (EST) Cc: agentx@fv.com In-Reply-To: <199603221800.AA026897641@dorothy.peer.com> from "Randy Presuhn" at Mar 22, 96 10:00:42 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > > > I hope we can agree: > > > > in processing a set (or simple get) operation, a master agent > > > > will not send varbinds to a subagent for which that subagent > > > > has not claimed responsibility. > ... > > I have a problem here - it means among other things that master-agent > > knows and verifies details of (a) indexing, (b) holes in registration > ... > > The master agent only needs to know that a particular subagent has > claimed responsibility for some portion of the OID space. That claim > might be communicated as a subtree, regular expression, or whatever. ???? Without instance information master-agent has no chance to satisfy your requirement, isn't it ? > > tree - I am not against this, however I would like for everybody to > > understand that there is substantial overhead involved here both during > > registration and operation phase. I would like to note also that > > despite 1000's of lines of postings about registering overlapping rows > > I did not see anything yet which will provide simple/robust/generic > > mechanism for row creation in this environment (*). > > You're right that more detail is needed in describing reservation. > At the Los Angeles meeting we discussed a proposal by Jeff Case for > reservation tracking in terms of a table. Maria and others went into > some detail about how it could be used to meet reservation requirements. So, you agree with me that we did not see generic/robust solution of this problem yet. At the same time we are going to have final spec in just about one month - it seems to me that it is a time to drop the requirement you had specified as unrealistic in a given time frame. > > BTW, if we are going to go ther way of 'master-agent knows all details > > about sub-agent variable space' indeed than let us use ALL positive > > sides of this approach - there are many of them still untapped. > ... > > I'd rather go the other direction, that of minimizing the amount > of knowledge that has to be maintained at the master agent. I would rather (I am actually moving) move in this direction myself, however, requirement you had specified that each sub-agent should expect to receives only instances it is responsible for clearly contradicts with this reasonable intention. > > What if NMS <->master-agent MTU is much bigger than master<->sub-agent > > MTU ? > ... > > I haven't seen an environment like this yet. Did you have something > specific in mind? I'd like to be sure we're not cutting off any > significant opportunities here. We also need to make sure that we don't > confuse lower-layer MTU with the QOS provided by the transport used by > the agentx protocol. ????? Is it already established fact that components of agentx should use stream based protocol to talk to each other ? If not then there are two MTUs and I would not like to beteverything that second one will always be larger than first. > Randy Presuhn PEER Networks, a division of BMC Software, Inc. Aleksey   Delivery-Date: Fri, 22 Mar 1996 12:34:03 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id MAA19922 for X-agentx-local; Fri, 22 Mar 1996 12:34:02 -0800 (PST) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id MAA19866 for ; Fri, 22 Mar 1996 12:34:00 -0800 (PST) Received: from flume.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA30761; Fri, 22 Mar 1996 15:27:13 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA18184; Fri, 22 Mar 1996 15:27:08 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA03952; Fri, 22 Mar 1996 15:27:39 -0500 Message-Id: <9603222027.AA03952@bernie.zk3.dec.com> To: johns@baynetworks.com (John Seligson) Cc: agentx@fv.com Subject: Re: 13: Request/Response Dispatching In-Reply-To: Your message of "Fri, 22 Mar 96 10:15:56 PST." <199603221815.KAA01979@turing.engwest> Date: Fri, 22 Mar 96 15:27:38 -0500 From: Mike Daniele X-Mts: smtp Hi John, Thanks for following up. >I'm not suggesting messages on the order of 30 bytes or even 150 bytes. >Many of the MIBs today define objects with potentially quite large instance >components (e.g., tables instanced by multiple ATM addresses are common). >Now for OCTET STRING OBJECT-TYPE objects, single varBinds could easily >exceed 150 bytes. Now consider conceptual rows containing 10 or 20 columns >where, say, half are required to successfully create a new row. A one-shot >create-and-go now requires a fairly sizable message be passed between the >master agent and the subagent. But first it had to be passed from the NMS to the agent, so the message was smaller than the max msg size of each. >You don't want to drop packets being routed due to buffer exhaustion >because you have allocated SNMP message buffers large enough to handle >any request. A freudian slip? :-) I think you meant "agentx" buffers not "SNMP" buffers? Dave Keeney just dropped in and suggested that in constrained environments where you worry about the size of agentx packets, perhaps what really needs adjustment is the overall agent's max msg size. >Please let me know if I'm missing something with regard to the current >proposals. I doubt it. I guess what I'm missing is an understanding that there are environments where the agent can send and receive "big" packets to/from the NMS, but is constrained to send "small" ones to subagents, especially when they are co-located. (Aside: I don't think network MTU is an issue, I don't care if IP fragments my agentx packets.) Would it work for your environment to simply adjust the overall agent's max msg size? Then agentx could worry simply about 'tooBig', not about 'max_vbs_per_packet'. Thanks, Mike   Delivery-Date: Fri, 22 Mar 1996 12:53:44 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id MAA24907 for X-agentx-local; Fri, 22 Mar 1996 12:53:43 -0800 (PST) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.139.6]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id MAA24900 for ; Fri, 22 Mar 1996 12:53:42 -0800 (PST) Received: from hawpub.watson.ibm.com ([9.2.90.19]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id PAA18262; Fri, 22 Mar 1996 15:53:44 -0500 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/2/16/96) id AA25425; Fri, 22 Mar 1996 15:53:33 -0500 Message-Id: <9603222053.AA25425@hawpub.watson.ibm.com> Subject: 13: MaxVarBinds To: natale@acec.com (Bob Natale) Date: Fri, 22 Mar 1996 15:53:33 -0500 (EST) From: "Uri Blumenthal" Cc: agentx@fv.com In-Reply-To: from "Bob Natale" at Mar 21, 96 07:08:25 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Bob Natale says: > Bert/Uri, can you please start a subtopic on the maxvarbinds > issue (13: Maxvarbinds), if you want to pursue it further. There's no choice but to pursue it, for a decision must be made. The choices are: - master-agent collects all the "relevant" varbinds for the sub' in question and passes them in one chunk; - master-agent always passes as many varbinds as the sub' in question said [at registration] is can deal with. First choice makes life easier for some subagents, while making other impossible if for some reasons (I's assume space be the biggest) they cannot handle more than a certain number of varbinds at a time. Second choice seems to be good and efficient for most subagents. Naturally, I'm for it. > (One possible compromise thought here is that the "normal > case" would be 0, which would mean "all", thus the complexity > would be incurred by the master agent (in all cases) and > only those subagents who wanted to set a limit.) I'm not sure - for in this case you have to have both extra phase on Set *and* extra complexity on the master-agent side [to deal with putting all the relevant varbinds together and then figuring out what error code from which subagent should the "main" response" contain]. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Fri, 22 Mar 1996 13:06:00 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id NAA28041 for X-agentx-local; Fri, 22 Mar 1996 13:05:59 -0800 (PST) Received: from ta.antec.com ([205.187.171.11]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id NAA28034 for ; Fri, 22 Mar 1996 13:05:58 -0800 (PST) Received: from pc_georgeb by ta.antec.com via SMTP (8.6.12/8.6.4) id PAA23992; Fri, 22 Mar 1996 15:53:43 -0500 Date: Fri, 22 Mar 1996 15:53:43 -0500 Message-Id: <199603222053.PAA23992@ta.antec.com> X-Sender: georgeb@bopper.ta.antec.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: johns@BayNetworks.com (John Seligson), daniele@zk3.dec.com From: george.best@antec.com (George Best) Subject: Re: 13: Request/Response Dispatching Cc: agentx@fv.com At 10:15 AM 3/22/96 -0800, John Seligson wrote: >...A one-shot >create-and-go now requires a fairly sizable message be passed between the >master agent and the subagent. > >Personally, I have run into bandwidth limitations in shared memory IPC >environments. These limitations have come in two forms, the first being >message size limitations imposed by the IPC mechanism. The second being >the memory management component in high performance environments. In this >case, available memory is often preallocated into buffer pools of various >sizes... It sounds like the agent/sub-agent protocol has to be able to support the equivalent of transactions (a la TCP) when passing set request varbinds to sub-agents. This would allow the sub-agents collect all the varbinds and set the OIDs "simultaneously". This transaction size could then be one of those items for the MIB. Gb - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - George Best email: georgeb@antec.com Digital Video, Norcross GA, USA voice: (770)734-0400 ext. 8534   Delivery-Date: Fri, 22 Mar 1996 13:11:28 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id NAA29426 for X-agentx-local; Fri, 22 Mar 1996 13:11:27 -0800 (PST) Received: from mail.sharplabs.com ([204.75.175.200]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id NAA29419 for ; Fri, 22 Mar 1996 13:11:23 -0800 (PST) Received: from sla5c by mail.sharplabs.com (SMI-8.6/SMI-SVR4) id NAA08276; Fri, 22 Mar 1996 13:08:32 -0800 From: rturner@mail.sharplabs.com (Randy Turner) Received: by sla5c (SMI-8.6) id NAA05708; Fri, 22 Mar 1996 13:08:27 -0800 Date: Fri, 22 Mar 1996 13:08:27 -0800 Message-Id: <199603222108.NAA05708@sla5c> To: johns@BayNetworks.com, daniele@zk3.dec.com Subject: Re: 13: Request/Response Dispatching Cc: agentx@fv.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: W7dFyTCQl0BTXw672M9tNw== > From daniele@zk3.dec.com Fri Mar 22 13:02:24 1996 > Resent-From: agentx-owner@fv.com > Comment: Posted to the agentx Mailing List To unsubscribe, send mail to agentx-request@fv.com with "unsubscribe" in the Subject > Resent-Date: Fri, 22 Mar 1996 12:40:49 -0800 > Resent-Message-ID: <19933.827527249.1@fv.com> > To: johns@BayNetworks.com (John Seligson) > Cc: agentx@fv.com > Subject: Re: 13: Request/Response Dispatching > Date: Fri, 22 Mar 96 15:27:38 -0500 > From: Mike Daniele > X-Suppressed-X-Mts: smtp > > Hi John, > > Thanks for following up. > > >I'm not suggesting messages on the order of 30 bytes or even 150 bytes. > >Many of the MIBs today define objects with potentially quite large instance > >components (e.g., tables instanced by multiple ATM addresses are common). > >Now for OCTET STRING OBJECT-TYPE objects, single varBinds could easily > >exceed 150 bytes. Now consider conceptual rows containing 10 or 20 columns > >where, say, half are required to successfully create a new row. A one-shot > >create-and-go now requires a fairly sizable message be passed between the > >master agent and the subagent. > > But first it had to be passed from the NMS to the agent, so the message > was smaller than the max msg size of each. > > >You don't want to drop packets being routed due to buffer exhaustion > >because you have allocated SNMP message buffers large enough to handle > >any request. > > A freudian slip? :-) I think you meant "agentx" buffers not "SNMP" > buffers? > > Dave Keeney just dropped in and suggested that in constrained environments > where you worry about the size of agentx packets, perhaps what really > needs adjustment is the overall agent's max msg size. > > >Please let me know if I'm missing something with regard to the current > >proposals. > > I doubt it. I guess what I'm missing is an understanding that > there are environments where the agent can send and receive > "big" packets to/from the NMS, but is constrained to send "small" > ones to subagents, especially when they are co-located. (Aside: I don't > think network MTU is an issue, I don't care if IP fragments my agentx > packets.) > > Would it work for your environment to simply adjust > the overall agent's max msg size? > > Then agentx could worry simply about 'tooBig', not about > 'max_vbs_per_packet'. > > Thanks, > Mike > > Mike, This is closer to being something I could use. Fundamentally, I can't handle the case where the master agent sends the subagent a request and returns 'tooBig', because there is really no way to clearly recover from this. The master agent needs to know how to adjust the request to fit what the subagent expects. So I guess an overall max-subagent-packet-size would be sufficient. Randy   Delivery-Date: Fri, 22 Mar 1996 14:58:29 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id OAA28173 for X-agentx-local; Fri, 22 Mar 1996 14:58:29 -0800 (PST) Received: from ny.frontiercomm.net (ny.frontiercomm.net [206.28.158.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id OAA28162 for ; Fri, 22 Mar 1996 14:58:27 -0800 (PST) Received: from monroe-85.dialup.frontiercomm.net by ny.frontiercomm.net (NX5.67e/NX3.0M) id AA26640; Fri, 22 Mar 96 17:57:56 -0500 Received: (from uri@localhost) by angmar.hopewell.ny.us (8.7.3/8.6.11) id RAA14518; Fri, 22 Mar 1996 17:57:39 -0500 Date: Fri, 22 Mar 1996 17:57:39 -0500 From: Uri Blumenthal Message-Id: <199603222257.RAA14518@angmar.hopewell.ny.us> To: agentx@fv.com Subject: 05: sysUpTime In-Reply-To: <199603220920.BAA11791@zloty.fv.com> References: <199603220920.BAA11791@zloty.fv.com> Reply-To: uri@cornwall.ny.frontiercomm.net Mime-Version: 1.0 (generated by tm-edit 7.38) Content-Type: text/plain; charset=US-ASCII >>>>> "Bert" == Bert Wijnen writes: Bert> 2.In the past I have also suggested/proposed many times that Bert> it is kind of crazy to have only one indicator (namely Bert> sysUpTime) to indicate that one of (possibly very) many Bert> counters has had some trouble........................ Your [skipped] quote is perfect, and I agree with the reasoning. Bert> So the questions now are: is it a re-initialization of Bert> the management system if a subagent disconnects/reconnects? Bert> - if yes, then sysUpTime must be reset - if no, then an Bert> object of SYNTAX TimeStamp must be defined for counter Bert> implemented within the MIB supported by the subagent. Perfectly correct and we're in agreement here. Bert> ...since you never know if this counter in a MIB is part of Bert> a monolithic agent or a subagent, you cannot require the MIB Bert> designers that they define an object of SYNTAX TimeStamp. I don't see why not... A row in a table seems to merit its own TimeStamp... A MIB group merits one... There are some logical splits, which practically everybody would use, and catering to those seems a safe bet. Such an extra object doesn't hurt anything, and can come as a show-saver. Bert> So I then come to the conclusion that in order to do this Bert> properly (and transparent), that a disconnect/connect Bert> sequence of a subagent should reset sysUpTime...... I'd rather track down the registrations of the just-connected subagent and either enforced re-registration, or canceled all of them (registered subtrees by the given subagent).See below. Bert> Now another way to solve it might be via the saMIB where we Bert> can define at which time subagents come and go and at what Bert> time registrations take place..... Right, but we don't care as much about when a _subagent_ came online, as when the _objects_ did! Thus, it looks more like a sysORTable than saMIB... This allows saMIB to be optional, and everybody is happy (:-). Bert> Yet another way to try and solve this might be via the Bert> sysORTable in RFC1907. When a subagent reggisters subtrees Bert> or objects, then for all I can tell we will have to add Bert> entries in the sysORTable. And this is also true if such Bert> kind of registrations happen within a monolithic agent, so Bert> no difference for the subagent scenario. This solution cannot be bested. I propose we stick with it. Bert> ...And so if we could make sure that this Bert> time is updated when a counter in a subagent gets a Bert> discontinuity (we could do that by telling subagent Bert> implementers that a discunituity in a counter that does not Bert> have an object of SYNTAX TimeStamp associated with it, that Bert> for such cases the subagent must unregister/reregister in Bert> order to get the sysORUpTime reset. Cannot we mandate this? "Legislating" re-registration sounds quite reasonable to me. More difficult technically, but still workable would be to enforce unregistering everything a given subagent registered at his disconnect. Smart implementations might be doing this already. Comments? Regards, Uri. -=-=-==-=-=- uri@watson.ibm.com I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.   Delivery-Date: Fri, 22 Mar 1996 14:59:23 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id OAA28420 for X-agentx-local; Fri, 22 Mar 1996 14:59:23 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id OAA28415 for ; Fri, 22 Mar 1996 14:59:22 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA28471 for ; Fri, 22 Mar 96 12:44:51 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA22571; Fri, 22 Mar 1996 12:44:22 -0500 Date: Fri, 22 Mar 1996 12:47:06 EST From: Bob Natale Subject: Re: 02: Architecture - Division of Labor To: Mike Daniele Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Mike Daniele > Date: Fri, 22 Mar 96 10:32:40 -0500 Hi Mike, <...object/instance/syntax discussion...> > All I'm suggesting is that this is ALL the registration consists > of (at least with respect to MIB speficiations). I'd prefer to see > these registered oids (that I loosely call "subtrees") associated > with actual MIB variables out in the respective subagents, not within > the master agent. > > The subagent should figure out which of its instantiated MIB variables > it should return, if the syntax was right, if it implements the required > access, etc. > > Do we really want the master agent to try and do all that? I really did (thinking that the cost/benefit outcome was positive). Once upon I time. I believe that the bulk of opinion expressed then was clearly against that approach. I believe that we are now firmly oriented toward the "division of labor" you have outlined on this thread--i.e., master agent holds only registration/dispatching info; subagent holds actual object syntax info--and that our design and specification work should proceed accordingly. We can always revisit the issue if we hit an insurmountable obstacle with that approach, which I consider highly unlikely at this point. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Fri, 22 Mar 1996 15:49:20 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id PAA12098 for X-agentx-local; Fri, 22 Mar 1996 15:49:19 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id PAA12090 for ; Fri, 22 Mar 1996 15:49:18 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA29482 for ; Fri, 22 Mar 96 13:05:01 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA22887; Fri, 22 Mar 1996 13:04:32 -0500 Date: Fri, 22 Mar 1996 13:07:17 EST From: Bob Natale Subject: Re: 05: SNMPv1/SNMPv2c support To: rpresuhn@peer.com Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Randy Presuhn > Date: Fri, 22 Mar 1996 08:47:02 -0800 Hi Randy, > I'm only asking that we not constrain the subagent protocol to > be less capable than SNMPv2. Yes. I believe we have accepted this as a requirement at the AgentX protcol level. If I were writing an SNMPv2-only *subagent* implementing an SNMPv2-only MIB, I would have no need to deal with the obsolete data types nor the error codes which exist solely for backwards compatibility. Do you find that statement to be incorrect or otherwise inconsistent with the requirement as you phrased it? Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Fri, 22 Mar 1996 15:49:31 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id PAA12149 for X-agentx-local; Fri, 22 Mar 1996 15:49:30 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id PAA12080 for ; Fri, 22 Mar 1996 15:49:28 -0800 (PST) Message-Id: <199603222349.AA042508588@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA042508588; Fri, 22 Mar 1996 15:49:48 -0800 Date: Fri, 22 Mar 1996 15:49:48 -0800 From: Randy Presuhn To: agentx@fv.com Subject: Re: 13: Request/Response Dispatching Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > Date: Fri, 22 Mar 1996 15:53:43 -0500 > Message-Id: <199603222053.PAA23992@ta.antec.com> > To: johns@BayNetworks.com (John Seligson), daniele@zk3.dec.com > From: george.best@antec.com (George Best) > Subject: Re: 13: Request/Response Dispatching > Cc: agentx@fv.com > > At 10:15 AM 3/22/96 -0800, John Seligson wrote: > > >...A one-shot > >create-and-go now requires a fairly sizable message be passed between the > >master agent and the subagent. > > > >Personally, I have run into bandwidth limitations in shared memory IPC > >environments. These limitations have come in two forms, the first being > >message size limitations imposed by the IPC mechanism. The second being > >the memory management component in high performance environments. In this > >case, available memory is often preallocated into buffer pools of various > >sizes... > > It sounds like the agent/sub-agent protocol has to be able to support the > equivalent of transactions (a la TCP) when passing set request varbinds to > sub-agents. This would allow the sub-agents collect all the varbinds and > set the OIDs "simultaneously". This transaction size could then be one of > those items for the MIB. It would be much simpler to employ a layered design than to clutter the subagent protocol with features propoerly belonging to session and transport layers. If an underlying system-specific transport mechanism doesn't meet the minimal QOS requirements (e.g., clean byte stream), then a convergence layer should be defined between the application layer subagent protocol and whatever this limited transport is. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Fri, 22 Mar 1996 18:21:31 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id SAA26063 for X-agentx-local; Fri, 22 Mar 1996 18:21:30 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id SAA25611 for ; Fri, 22 Mar 1996 18:21:24 -0800 (PST) Message-Id: <199603230220.AA049977633@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA049977633; Fri, 22 Mar 1996 18:20:33 -0800 Date: Fri, 22 Mar 1996 18:20:33 -0800 From: Randy Presuhn To: natale@acec.com Subject: Re: 05: SNMPv1/SNMPv2c support Cc: agentx@fv.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > Date: Fri, 22 Mar 1996 13:07:17 EST > From: Bob Natale > Subject: Re: 05: SNMPv1/SNMPv2c support > To: rpresuhn@dorothy.peer.com > Cc: agentx@fv.com > Message-Id: > > > From: Randy Presuhn > > Date: Fri, 22 Mar 1996 08:47:02 -0800 > > Hi Randy, > > > I'm only asking that we not constrain the subagent protocol to > > be less capable than SNMPv2. > > Yes. I believe we have accepted this as a requirement at the > AgentX protcol level. > > If I were writing an SNMPv2-only *subagent* implementing an > SNMPv2-only MIB, I would have no need to deal with the > obsolete data types nor the error codes which exist solely > for backwards compatibility. > > Do you find that statement to be incorrect or otherwise > inconsistent with the requirement as you phrased it? ... It's pretty close. There is still the possibility that an obsolete data type would appear in a management operation request, but these would either be ignored (for the get/next/bulk case) or handled by well-defined error procedures (for set.) Subagent code for handling sets needs to be able to handle incorrect data types anyway, so no special logic is required in an implementation. That's why I don't see what all the fuss is about on this point. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Fri, 22 Mar 1996 18:28:17 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id SAA27860 for X-agentx-local; Fri, 22 Mar 1996 18:28:17 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id SAA27854 for ; Fri, 22 Mar 1996 18:28:16 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA10008 for ; Fri, 22 Mar 96 16:14:58 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA26083; Fri, 22 Mar 1996 16:14:29 -0500 Date: Fri, 22 Mar 1996 16:17:14 EST From: Bob Natale Subject: Re: 13: MaxVarBinds To: uri@watson.ibm.com Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Uri Blumenthal > Date: Fri, 22 Mar 1996 15:53:33 -0500 (EST) Hi Uri, > > Bert/Uri, can you please start a subtopic on the maxvarbinds > > issue (13: Maxvarbinds), if you want to pursue it further. > > There's no choice but to pursue it, for a decision must be > made. Yes, it does look like the wg has some differences of opinion on this one that we will need to resolve. > The choices are: > > - master-agent collects all the "relevant" varbinds > for the sub' in question and passes them in one > chunk; > > - master-agent always passes as many varbinds as the > sub' in question said [at registration] is can > deal with. Ok. [Speaking as a technical contributor: I'm not in favor of "maxvarbinds", per se. In addition to being committed to some of the principles of simplicity and "just-enough-and- no-more-ness" that have been well-stated by RandyP, I am uncovinced that "maxvarbinds" is a meaningful measure. I think that if the issue were MMS, it would make more sense. "maxvarbinds"--espeically with a value of "1"-- *suggests* that *possibly* other implementation charac- teristics might be at the crux of it all.] Also, we should not forget that the problem of a tooBig message exists for native agents too and the management applications have to deal with this. I'm not sure I see why there has to be a difference with respect to the extensible agent environment. (Yes, I saw the argument that it is possible that the pipe between the master and the subagent(s) could be narrower than that between the management app(s) and the master...but from my experience and the other postings on that issue, I'd have to say that case is relatively exceptional.) > First choice makes life easier for some subagents, while making > other impossible if for some reasons (I's assume space be the > biggest) they cannot handle more than a certain number of > varbinds at a time. "Space" and "number of varbinds" are not consistently related. > Second choice seems to be good and efficient for most subagents. > Naturally, I'm for it. > > > (One possible compromise thought here is that the "normal > > case" would be 0, which would mean "all", thus the complexity > > would be incurred by the master agent (in all cases) and > > only those subagents who wanted to set a limit.) > > I'm not sure - for in this case you have to have both extra > phase on Set *and* extra complexity on the master-agent > side [to deal with putting all the relevant varbinds > together True. > and then figuring out what error code from which subagent > should the "main" response" contain]. I'm sorry...I do not understand that point (in this context). Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Fri, 22 Mar 1996 19:17:52 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id TAA11113 for X-agentx-local; Fri, 22 Mar 1996 19:17:52 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id TAA11099 for ; Fri, 22 Mar 1996 19:17:49 -0800 (PST) Message-Id: <199603230318.AA052361100@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA052361100; Fri, 22 Mar 1996 19:18:21 -0800 Date: Fri, 22 Mar 1996 19:18:21 -0800 From: Randy Presuhn To: agentx@fv.com Subject: Re: 13: Request/Response Dispatching Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - | From: ralex@world.std.com (Aleksey Y Romanov) | Message-Id: <199603222030.AA26510@world.std.com> | Subject: Re: 13: Request/Response Dispatching | To: rpresuhn@dorothy.peer.com (Randy Presuhn) | Date: Fri, 22 Mar 1996 15:30:57 -0500 (EST) | Cc: agentx@fv.com | In-Reply-To: <199603221800.AA026897641@dorothy.peer.com> from "Randy Presuhn" at Mar 22, 96 10:00:42 am ... | > > > > I hope we can agree: | > > > > in processing a set (or simple get) operation, a master agent | > > > > will not send varbinds to a subagent for which that subagent | > > > > has not claimed responsibility. | > ... | > > I have a problem here - it means among other things that master-agent | > > knows and verifies details of (a) indexing, (b) holes in registration | > ... | > | > The master agent only needs to know that a particular subagent has | > claimed responsibility for some portion of the OID space. That claim | > might be communicated as a subtree, regular expression, or whatever. | | ???? Without instance information master-agent has no chance to satisfy | your requirement, isn't it ? I think the phrase "claimed responsibility" is causing difficulty here. I'll try to explain what I meant. A registration request defines a set S, which is a subset of the set of all object identifiers. For a given subagent, the Union over all the sets S defined by its registration requests provides the set of variables for which that subagent has claimed responsibility, which we will call R. The set V of variable instances actually in existance at the subagent may be any subset of R, and may change over time. A claim of responsibility merely indicates a willingness to process requests from some region of the OID space. This region may be the same as or a superset of the region of variables that actually exist in a subagent at any moment. This is a SMUX-ish view of registration. In the DPI-ish view, since it does not aggregate a given subagents registrations, the claim is per registration (rather than the union of a subagent's registrations). For agentx, we need to note that this occurs independently for each supported naming scope. These notions are not new. ... | > You're right that more detail is needed in describing reservation. | > At the Los Angeles meeting we discussed a proposal by Jeff Case for | > reservation tracking in terms of a table. Maria and others went into | > some detail about how it could be used to meet reservation requirements. | | So, you agree with me that we did not see generic/robust solution of this | problem yet. At the same time we are going to have final spec in | just about one month - it seems to me that it is a time to drop the | requirement you had specified as unrealistic in a given time frame. On the contrary, several solutions are known. Our challenge as a group is to make the tradeoffs to get a good cost/benefit ratio and to ensure that the resulting specification is clear and implementable. ... | ????? Is it already established fact that components of agentx should | use stream based protocol to talk to each other ? If not then there are | two MTUs and I would not like to beteverything that second one will | always be larger than first. ... It'd be simpler to layer the design and handle this in a sublayer in environments that have severe limitations on their transport mechanisms. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Sat, 23 Mar 1996 10:32:30 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id KAA05985 for X-agentx-local; Sat, 23 Mar 1996 10:32:29 -0800 (PST) Received: from hansons.demon.co.uk (hansons.demon.co.uk [158.152.246.152]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id KAA05972 for ; Sat, 23 Mar 1996 10:32:23 -0800 (PST) Date: Sat, 23 Mar 1996 13:07:01 GMT From: Iain@hansons.demon.co.uk (Iain K. Hanson) Reply-To: Iain@hansons.demon.co.uk Message-Id: <1704@hansons.demon.co.uk> To: rpresuhn@peer.com, agentx@fv.com Cc: iain@hansons.demon.co.uk Subject: Re: 05: sysUpTime X-Mailer: PCElm 1.10 Lines: 55 Hi, In message <199603212210.AA002296223@dorothy.peer.com> Randy Presuhn writes: > > > Message-Id: <9603211754.AA03436@bernie.zk3.dec.com> > > To: "Bert Wijnen" > > Cc: agentx@fv.com > > Subject: Re: 05: sysUpTime > > In-Reply-To: Your message of "Thu, 21 Mar 96 18:03:24 +0700." <199603211704.JAA06957@zloty.fv.com> > > Date: Thu, 21 Mar 96 12:54:00 -0500 > > From: Mike Daniele > ... > > > c.we include a DPI-RESET-SYSUPTIME packet > > > (Again, I don't like it, but we need it to allow a subagent to > > > reset sysUpTime when a counter discontinuity occurs) > > > When the (master) agent receives this, it resets sysUpTime and > > > sends a warmStart trap. > > > > But this leaves all other subagents synching against the old value > > of sysUpTime? > > Doing things like this does require a mechanism to notify subagents of > discontinuitues for all affected naming scopes. Thanks Randy, I'd forgotten about naming scopes in this context ( no pun intended ). > > > In general, I thought we'd more or less concluded in L.A. that > > sysUpTime can never achieve the semantics implied by (broken) > > applications, and that this shouldn't really be an agent issue. > > > > Maybe I was dreaming... :-) > > That was my recollection as well. Attached is an old message on this > topic from Joey de Wiele that bears re-reading: > I read it and find it a good analysis but... I would still like to see a solution of the problem. But not a solution that is worse than the problem. So I agree that sysUpTime should only be re-set when the master agent re-sets. I also don't like the idea of an upTime for each counter or agent being sent with every get response, although if there is an agentx MIB then it would seem sensible to have an upTime for each sub-agent. However, I like Bert's idea of a warm start trap ( which implicitly carries a naming scope) and could carry other naming scopes from the entity MIB if required plus information regarding sucessfull registration. /ikh -- Iain K. Hanson   Delivery-Date: Sat, 23 Mar 1996 12:50:25 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id MAA11238 for X-agentx-local; Sat, 23 Mar 1996 12:50:24 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id MAA11224 for ; Sat, 23 Mar 1996 12:50:23 -0800 (PST) Message-Id: <199603232050.AA057764255@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA057764255; Sat, 23 Mar 1996 12:50:55 -0800 Date: Sat, 23 Mar 1996 12:50:55 -0800 From: Randy Presuhn To: agentx@fv.com Subject: Re: 05: sysUpTime Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > From: Uri Blumenthal > Message-Id: <199603222257.RAA14518@angmar.hopewell.ny.us> > To: agentx@fv.com > Subject: 05: sysUpTime > In-Reply-To: <199603220920.BAA11791@zloty.fv.com> ... > Bert> Yet another way to try and solve this might be via the > Bert> sysORTable in RFC1907. When a subagent reggisters subtrees > Bert> or objects, then for all I can tell we will have to add > Bert> entries in the sysORTable. And this is also true if such > Bert> kind of registrations happen within a monolithic agent, so > Bert> no difference for the subagent scenario. > > This solution cannot be bested. I propose we stick with it. I agree - the sysORTable is probably the best place to handle these matters. > Bert> ...And so if we could make sure that this > Bert> time is updated when a counter in a subagent gets a > Bert> discontinuity (we could do that by telling subagent > Bert> implementers that a discunituity in a counter that does not > Bert> have an object of SYNTAX TimeStamp associated with it, that > Bert> for such cases the subagent must unregister/reregister in > Bert> order to get the sysORUpTime reset. > > Cannot we mandate this? > > "Legislating" re-registration sounds quite reasonable to me. The counter discontinuity problem is not typically one of a subagent discovering a discontinuity. The important problem case occurs when a subagent that does not guarantee counter continuity from invocation to invocation goes away and comes back too quickly for a manager to find out that it was gone. > More difficult technically, but still workable would be to > enforce unregistering everything a given subagent registered > at his disconnect. Smart implementations might be doing this > already. ... This behaviour is already specified in RFC 1227. It is part of building a robust master agent. An implementation that did not do this would allow registrations from dead subagents to accumulate without bound. This would probably be indistinguishable from a memory leak. Not the sort of thing one would want to ship! ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Mon, 25 Mar 1996 04:53:44 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id EAA14366 for X-agentx-local; Mon, 25 Mar 1996 04:53:43 -0800 (PST) Received: from europe.std.com (europe.std.com [192.74.137.10]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id EAA14359 for ; Mon, 25 Mar 1996 04:53:42 -0800 (PST) Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id HAA22057; Mon, 25 Mar 1996 07:53:29 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA17973; Mon, 25 Mar 1996 07:51:25 -0500 From: ralex@world.std.com (Aleksey Y Romanov) Message-Id: <199603251251.AA17973@world.std.com> Subject: 20: Access control To: agentx@fv.com Date: Mon, 25 Mar 1996 07:51:25 -0500 (EST) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, There is a real need for access control functions to be performed in component-/sub- agent. 1. Bulks and GetNexts are most popular operations utilized by NMSs 2. NMS folks are strongly for instance level granularity (and we can consider it as customer requirement). 3. So extensible agents with access control located in the central agent will be unadequate performance-wise in this conditions. As everybody knows current idea about access control is rotating around SNMPv2-Classic views. However, there are things which has to be addressed before it will be usable in agentX environment. 1. Propagation mechanism - master can perform set operation on sub-agents view table as part of it performing set-operation on its own view table. I feel that peferred policy should be that sub-agent who cannot SET view (which was already verified by master as a correct one) has to be unmounted - so, one faulty view implementation will not bog down the whole big thing. The same thing should also happen upon mounting, master-agent has to initiate sub-agent's views. 2. Size. It is reasonable for sub-agent to provide information about max length of names it is supporting (worst case is 128), so master will have less stuff to propagate. 3. Access mechanism - master- to sub-agent PDU has to include view index. Aleksey   Delivery-Date: Mon, 25 Mar 1996 08:26:22 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id IAA02148 for X-agentx-local; Mon, 25 Mar 1996 08:26:22 -0800 (PST) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id IAA02140 for ; Mon, 25 Mar 1996 08:26:20 -0800 (PST) Received: from flume.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA12824; Mon, 25 Mar 1996 11:18:11 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA00651; Mon, 25 Mar 1996 11:18:10 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA04427; Mon, 25 Mar 1996 11:18:44 -0500 Message-Id: <9603251618.AA04427@bernie.zk3.dec.com> To: agentx@fv.com Subject: 20: Access Control - Naming Scopes Date: Mon, 25 Mar 96 11:18:43 -0500 From: Mike Daniele X-Mts: smtp Hi, We seem to agree that agentx needs to support naming scopes. Could we pin this down a bit more? From the discussions it sounds like a subagent should be able to specify 'naming scope' as part of either its OPEN (connection establishment) or as part of REGISTER Pdus. Doing this as part of the OPEN seems too coarse, so I assume it must happen during REGISTRATION. The master agent must then maintain a separate logical registry for each registered naming scope, and dispatch to subagents based only on the logical registry for the naming scope specified in the request. That naming scope must be passed as part of the operational Pdus to support subagents that register in multiple scopes. A default naming scope of "all" is applied to registrations and operational pdus in which no naming scope info is specified. A REGISTER Pdu will contain a single naming scope? a list of naming scopes? How do we represent naming scopes, variable length ascii strings? I'd like to get this established before we get much further into sysUpTime, ORTable, traps when you (de)register, etc. Thanks, Mike   Delivery-Date: Mon, 25 Mar 1996 10:44:03 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id KAA08631 for X-agentx-local; Mon, 25 Mar 1996 10:44:02 -0800 (PST) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.139.6]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id KAA08605 for ; Mon, 25 Mar 1996 10:44:01 -0800 (PST) Received: from hawpub.watson.ibm.com ([9.2.90.19]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id NAA10715 for ; Mon, 25 Mar 1996 13:44:02 -0500 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/2/16/96) id AA19096; Mon, 25 Mar 1996 13:43:52 -0500 Message-Id: <9603251843.AA19096@hawpub.watson.ibm.com> Subject: Re: 13: MaxVarBinds To: agentx@fv.com Date: Mon, 25 Mar 1996 13:43:52 -0500 (EST) From: "Uri Blumenthal" In-Reply-To: from "Bob Natale" at Mar 22, 96 04:17:14 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Bob Natale says: > I think that if the issue were MMS, it would make more > sense. "maxvarbinds"--espeically with a value of "1"-- > *suggests* that *possibly* other implementation charac- > teristics might be at the crux of it all.] There are more issues than just MMS. Like - in many cases the implementation can be a lot simpler/stupider/more-slim if you accept only one varBind at a time... > Also, we should not forget that the problem of a tooBig > message exists for native agents too and the management > applications have to deal with this. Of course. However I wouldn't like the whole "brigade" of agent+subagents return tooBig just in those few cases when you happen to ask for two objects in the subtree handled by the subagent "stupidSmallPack"... > why there has to be a difference with respect to the > extensible agent environment. (Yes, I saw the argument > that it is possible that the pipe between the master > and the subagent(s) could be narrower than that between > the management app(s) and the master...but from my > experience and the other postings on that issue, I'd > have to say that case is relatively exceptional.) It is not just the pipe. It's how much space and supporting code a subagent is allowed to have. Think small, think embedded (:-). > > and then figuring out what error code from which subagent > > should the "main" response" contain]. > > I'm sorry...I do not understand that point (in this context). If you pack together all the varbinds handled by sub' A, and do the same for sub' B and so on, and then some of the sub's return errors, you have to figure out which of those errors relates to the lowest global varbind index... I'm not saying it's impossible to implement, or that it's rocket science... I simply point that this is extra complexity which can and probably should be avoided. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Mon, 25 Mar 1996 11:57:52 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id LAA25816 for X-agentx-local; Mon, 25 Mar 1996 11:57:51 -0800 (PST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id LAA25811 for ; Mon, 25 Mar 1996 11:57:50 -0800 (PST) Received: from flume.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA00847; Mon, 25 Mar 1996 14:48:05 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA20384; Mon, 25 Mar 1996 14:48:03 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA04519; Mon, 25 Mar 1996 14:48:37 -0500 Message-Id: <9603251948.AA04519@bernie.zk3.dec.com> To: uri@watson.ibm.com Cc: agentx@fv.com Subject: Re: 13: MaxVarBinds In-Reply-To: Your message of "Mon, 25 Mar 96 13:43:52 EST." <9603251843.AA19096@hawpub.watson.ibm.com> Date: Mon, 25 Mar 96 14:48:36 -0500 From: Mike Daniele X-Mts: smtp Hi Uri, >There are more issues than just MMS. Like - in many cases >the implementation can be a lot simpler/stupider/more-slim >if you accept only one varBind at a time... In my opinion the work of dealing with an uknown number of VarBinds in a request, compared to dealing with 1, is trivial. Plus now you have to save the individual VarBinds you get one at a time for a Set, then wait for the ENDOFSET Pdu... Doesn't sound like a win for the subagent to me. >It is not just the pipe. It's how much space and supporting >code a subagent is allowed to have. Think small, think >embedded (:-). The embedded system permits allocation of say n SNMP buffers. Why can't n/2 be used for SNMP requests off the wire, n/2 be used for subagent communication, and the embedded system discards requests as it needs to. And if the size of the buffers is too small to handle some particular NMS request, that's tough, return tooBig. I just don't see why this is an agentx issue. Probably because I don't work on embedded systems? :-) >> > and then figuring out what error code from which subagent >> > should the "main" response" contain]. >> >> I'm sorry...I do not understand that point (in this context). >If you pack together all the varbinds handled by sub' A, and >do the same for sub' B and so on, and then some of the sub's >return errors, you have to figure out which of those errors >relates to the lowest global varbind index... I'm not saying >it's impossible to implement, or that it's rocket science... >I simply point that this is extra complexity which can and >probably should be avoided. But you have to map individaul subagent responses (error indexes) back to the original request anyway, regardless of how many VarBinds you send in one packet. In my opinion, having implemented the algorithm you describe, I much prefer that, than the concept of having to be aware of each subagent's maxvarbinds, fragmenting each of their requests, keeping track of where you are for each subagent... max_vbs_per_packet is definitely a loss for the master agent. To sum up: It's seems more complex for the subagent. It's definitely more complex for the master agent It MAY have use in memory-constrained environments, but I'm not convinced of that. Regards, Mike   Delivery-Date: Mon, 25 Mar 1996 12:20:44 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id MAA01121 for X-agentx-local; Mon, 25 Mar 1996 12:20:44 -0800 (PST) Received: from acme.sb.west.net (acme.sb.west.net [205.254.224.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id MAA01116 for ; Mon, 25 Mar 1996 12:20:42 -0800 (PST) Received: from abierman.west.net (term1-29.vta.west.net [205.254.241.29]) by acme.sb.west.net (8.6.12/8.6.12) with SMTP id MAA15313; Mon, 25 Mar 1996 12:13:37 -0800 Message-ID: <3156FE09.5F94@west.net> Date: Mon, 25 Mar 1996 12:11:53 -0800 From: Andy Bierman X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: Mike Daniele CC: agentx@fv.com Subject: Re: 20: Access Control - Naming Scopes References: <9603251618.AA04427@bernie.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike Daniele wrote: > > Hi, > > We seem to agree that agentx needs to support naming scopes. > Could we pin this down a bit more? These details cannot be determined in the absence of an administrative framework. But one fact is clear: the 'naming scope <--> sub-agent' mapping is many-to-many. The $64 questions (unresolved by entmib, maybe agentx has the answers): 1) given an arbitrary community string, how is the associated naming scope identified by the agent (master or sub)? 2) how will this 'naming-scope-mapping' function be realized for emerging versions of SNMP? 3) how will naming-scopes be managed by the (non-existent) administrative model? I agree that the per-PDU naming-scope information must be accessible by sub-agents. In the first release, I suggest that the naming-scope-identifier string be equated with the entire community string, since there is no common mapping function available. Andy   Delivery-Date: Mon, 25 Mar 1996 12:42:38 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id MAA06332 for X-agentx-local; Mon, 25 Mar 1996 12:42:38 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id MAA06327 for ; Mon, 25 Mar 1996 12:42:35 -0800 (PST) Message-Id: <199603252043.AA090316587@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA090316587; Mon, 25 Mar 1996 12:43:07 -0800 Date: Mon, 25 Mar 1996 12:43:07 -0800 From: Randy Presuhn To: agentx@fv.com Subject: Re: 13: MaxVarBinds Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > Message-Id: <9603251843.AA19096@hawpub.watson.ibm.com> > Subject: Re: 13: MaxVarBinds > To: agentx@fv.com > Date: Mon, 25 Mar 1996 13:43:52 -0500 (EST) > From: "Uri Blumenthal" > In-Reply-To: from "Bob Natale" at Mar 22, 96 04:17:14 pm ... > There are more issues than just MMS. Like - in many cases > the implementation can be a lot simpler/stupider/more-slim > if you accept only one varBind at a time... Doing one variable binding at a time reduces neither the complexity nor the storage requirements at the subagent. Data Storage: the subagent needs to have enough space to remember all the individual pieces of a proposed SET operation until the operation is committed. This is true regardless of whether the operation comes in piecemeal or not. The list of varbinds will take the same space whether you build it one at a time or all at once. Code Size: piecemeal operations require MORE code in both the master agent and the subagent, due to the increased number of protocol states, as well as the need in product-quality libraries to be able to handle both agents that send things piecemeal as well as ones that are more efficient. Complexity: both the protocol description and implementation are more complex if piecemeal operations are supported. This kind of unnecessary complexity is a result of pushing functionality that should be handled at the transport layer into the application layer. ... > It is not just the pipe. It's how much space and supporting > code a subagent is allowed to have. Think small, think > embedded (:-). These are good reasons to avoid adding unneeded complexity and size. ... > If you pack together all the varbinds handled by sub' A, and > do the same for sub' B and so on, and then some of the sub's > return errors, you have to figure out which of those errors > relates to the lowest global varbind index... I'm not saying > it's impossible to implement, or that it's rocket science... > I simply point that this is extra complexity which can and > probably should be avoided. This is not extra complexity. It is required to implement SNMP. Whether the variable bindings are processed one-at-a-time or in groups, the master agent needs to correlate subagent responses with the varbind positions in the original request. There is NO additional complexity or processing cost in the multiple varbind scenario. If anything, piecemeal processing is more complex and expensive. Here are some differences between the approaches for GET processing: Intelligent Piecemeal: for all N varbinds (in paralle) { identify subagent send to subagent receive response if error is lowest so far, remember it } success cost: N identifications N sends and receives, N assesments of error position failure cost: N identifications N sends and receives, N assesments of error position ------------------------------------------------------------ Stupid Piecemeal: for all N varbinds (serially) { identify subagent send to subagent receive response if error, bail } success cost: N identifications N sends and receives, N assesments of error position failure cost: E (E <= N) identifications E (E <= N) sends and receives, E (E <= N) assesments of error position ------------------------------------------------------------ Grouped: for all N varbinds (serially) { identify subagent } for all S affected subagents (in parallel) { send to subagent receive response for all varbinds in response if error is lowest so far, remember it } success cost: N identifications S (S <= N, S typically 1) sends & receives N assesments of error position failure cost: N identifications S (S <= N, S typically 1) sends and receives N assesments of error position Note the differences between the cost of the algorithms: the piecemeal approach never performs fewer expensive operations for the typical case of the successful operation, and achieves a savings in the failure case only if we constrain sub-operations to be performed serially. For the common case of multiple columns being retrieved from a table row, it is easy to see that the piecemeal approach is significantly more costly. I don't think it's a good tradeoff to get a processing savings limited to the failure case by constraining the master agent to wait for a response from a subagent before dispatching the next variable binding. I find it hard to believe that the marketplace could swallow a limitation like this. Without this constraint, there are no processing cost benefits at all to the piecemeal appriach. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Mon, 25 Mar 1996 12:52:39 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id MAA08721 for X-agentx-local; Mon, 25 Mar 1996 12:52:39 -0800 (PST) Received: from acme.sb.west.net (acme.sb.west.net [205.254.224.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id MAA08716 for ; Mon, 25 Mar 1996 12:52:37 -0800 (PST) Received: from abierman.west.net (term1-29.vta.west.net [205.254.241.29]) by acme.sb.west.net (8.6.12/8.6.12) with SMTP id MAA20267; Mon, 25 Mar 1996 12:45:06 -0800 Message-ID: <3157056A.50D6@west.net> Date: Mon, 25 Mar 1996 12:43:22 -0800 From: Andy Bierman X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: Mike Daniele CC: uri@watson.ibm.com, agentx@fv.com Subject: Re: 13: MaxVarBinds References: <9603251948.AA04519@bernie.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, > >There are more issues than just MMS. Like - in many cases > >the implementation can be a lot simpler/stupider/more-slim > >if you accept only one varBind at a time... > > In my opinion the work of dealing with an uknown number > of VarBinds in a request, compared to dealing with 1, is trivial. > > Plus now you have to save the individual VarBinds you get one at > a time for a Set, then wait for the ENDOFSET Pdu... > > Doesn't sound like a win for the subagent to me. I agree with Mike. There are some agent implementations which only support the 'createAndGo' style of row creation. It is common for such agents to check the entire PDU to determine if all the required columns for a given row are present. This algorithm breaks if the sub-agent is only given 1 varbind at a time. Andy   Delivery-Date: Mon, 25 Mar 1996 13:07:21 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id NAA12157 for X-agentx-local; Mon, 25 Mar 1996 13:07:21 -0800 (PST) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.139.6]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id NAA12152 for ; Mon, 25 Mar 1996 13:07:19 -0800 (PST) Received: from hawpub.watson.ibm.com ([9.2.90.19]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id QAA12137 for ; Mon, 25 Mar 1996 16:07:21 -0500 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/2/16/96) id AA32496; Mon, 25 Mar 1996 16:07:11 -0500 Message-Id: <9603252107.AA32496@hawpub.watson.ibm.com> Subject: Re: 13: MaxVarBinds To: agentx@fv.com Date: Mon, 25 Mar 1996 16:07:11 -0500 (EST) From: "Uri Blumenthal" In-Reply-To: <9603251948.AA04519@bernie.zk3.dec.com> from "Mike Daniele" at Mar 25, 96 02:48:36 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Mike Daniele says: > In my opinion the work of dealing with an uknown number > of VarBinds in a request, compared to dealing with 1, is trivial. I never said it's rocket science. It's space and code and you don't always have those resources. > To sum up: [....having maxVarBinds........] > It's seems more complex for the subagent. No it isn't. [Having implemented those both, plus other things I'd rather not brag here about :-] > It's definitely more complex for the master agent No it isn't. > It MAY have use in memory-constrained environments, but > I'm not convinced of that. That's OK. When you're in a tight corner memory-wise and code-wise, the life itself will convince you - so why should I? (:-) -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Mon, 25 Mar 1996 13:24:09 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id NAA16300 for X-agentx-local; Mon, 25 Mar 1996 13:24:09 -0800 (PST) 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 NAA16297 for ; Mon, 25 Mar 1996 13:24:08 -0800 (PST) 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 NAA08795 for ; Mon, 25 Mar 1996 13:23:54 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 25 Mar 1996 16:23:58 -0500 To: agentx@fv.com From: bstewart@cisco.com (Bob Stewart) Subject: Re: 13: MaxVarBinds Circa 1:43 PM 3/25/96, Uri Blumenthal bitwhacked: >It is not just the pipe. It's how much space and supporting >code a subagent is allowed to have. Think small, think >embedded (:-). One of the things we have to balance here is where to draw the lines. In some systems the severely constrained, imbedded component may need to have some software on top of it to make it a proper subagent, that is, it may not implement AgentX. We're defining a functional interface, and that doesn't always match hardware boundries. The interface we define could come on either side of a hardware boundry, with appropriate, implementation-specific software to fill the gap. In other words, you may install a semi-intelligent board that has in it a data base of information that wants to make it to the outside world as a MIB. You may not be able to fit proper AgentX functions inside the board. In that case you need a driver in the main machine that speaks AgentX upward and whatever is neccessary and appropriate downward. Bob   Delivery-Date: Tue, 26 Mar 1996 09:56:21 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id JAA16863 for X-agentx-local; Tue, 26 Mar 1996 09:56:21 -0800 (PST) Received: from ta.antec.com ([205.187.171.11]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id JAA16855 for ; Tue, 26 Mar 1996 09:56:20 -0800 (PST) Received: from pc_georgeb by ta.antec.com via SMTP (8.6.12/8.6.4) for id MAA14070; Tue, 26 Mar 1996 12:50:55 -0500 Date: Tue, 26 Mar 1996 12:50:55 -0500 Message-Id: <199603261750.MAA14070@ta.antec.com> X-Sender: georgeb@bopper.ta.antec.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: agentx@fv.com From: george.best@antec.com (George Best) Subject: Re: 13: MaxVarBinds General Comment: In the recent past, on a mail list not too far away, it was made very clear that streamlining and simplifying the initial version of a given solution (be it MIB or protocol) was the most prudent path to approval by the IETF and acceptance by the user community. It sounds like the same paradigm applies to agentx, and in particular, to the issue of restricted bandwidth between the master and sub-agents. Specific Comment: Uri has a very basic and valid point. The limitations of the transport mechanisms between the master and sub-agent do need to be accounted for somewhere. I get the impression that the requirements analysis has been done already so... 1. Are there mandatory/recommended/assumed protocol layers below agentx that are expected to handle these limitations? 2. Assuming this is really out of scope for agentx, is it because: a. it is assumed that lower layers will break up the PDU, ship it through the small pipe, and then reassemble the PDU and present it to the sub-agent, or b. it was decided not to address this issue at this time? Gb - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - George Best email: georgeb@antec.com Digital Video, Norcross GA, USA voice: (770)734-0400 ext. 8534   Delivery-Date: Tue, 26 Mar 1996 10:06:23 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id KAA19622 for X-agentx-local; Tue, 26 Mar 1996 10:06:22 -0800 (PST) Received: from nastg.gsfc.nasa.gov (nastg.gsfc.nasa.gov [192.86.21.220]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id KAA19617 for ; Tue, 26 Mar 1996 10:06:21 -0800 (PST) Received: from katsura by nastg.gsfc.nasa.gov (8.6.11/1.35) id NAA08883; Tue, 26 Mar 1996 13:07:04 -0500 Message-Id: <199603261807.NAA08883@nastg.gsfc.nasa.gov> X-Sender: kkoran@nastg X-Mailer: Windows Eudora Version 1.4.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Mar 1996 13:04:01 -0500 To: agentx@fv.com From: kkoran@nastg.gsfc.nasa.gov (Kim Koran) Hi all; I'm new to SNMP and to this list; and I have a question for you all. Does anyone know of a quality SNMP agent source (drevelopment) package that can be installed on Linux and that also supports MIB II? I've looked at a number of companies already; some don't support Linux, some don't support MIB II. One said that MIB II is not SNMP compliant... This last puzzles me in particular. I have the Stallings book and there is no indication that MIB II is anything but SNMP (RFC 1213) compliant... Thanks in advance for any info! ************************************************************************* * Kim Koran Phone: 301-794-2854 * * Computer Sciences Corp. Fax: 301-794-9530 * * 7700 Hubble Drive Email: kkoran@nastg.gsfc.nasa.gov * * Lanham-Seabrook Md. 20706 * ************************************************************************* Diplomacy is the art of saying 'Nice doggie!'... until you can find a rock.   Delivery-Date: Tue, 26 Mar 1996 11:35:32 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id LAA13246 for X-agentx-local; Tue, 26 Mar 1996 11:35:31 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id LAA13221 for ; Tue, 26 Mar 1996 11:35:28 -0800 (PST) Message-Id: <199603261936.AA115738966@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA115738966; Tue, 26 Mar 1996 11:36:06 -0800 Date: Tue, 26 Mar 1996 11:36:06 -0800 From: Randy Presuhn To: agentx@fv.com Subject: Re: 13: MaxVarBinds Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > Date: Tue, 26 Mar 1996 12:50:55 -0500 > Message-Id: <199603261750.MAA14070@ta.antec.com> > To: agentx@fv.com > From: george.best@antec.com (George Best) > Subject: Re: 13: MaxVarBinds > > General Comment: > > In the recent past, on a mail list not too far away, it was made very clear > that streamlining and simplifying the initial version of a given solution > (be it MIB or protocol) was the most prudent path to approval by the IETF > and acceptance by the user community. It sounds like the same paradigm > applies to agentx, and in particular, to the issue of restricted bandwidth > between the master and sub-agents. Agreed. The problem is getting agreement on what constitutes streamlining, and what the simplicity metric should be. > Specific Comment: > > Uri has a very basic and valid point. The limitations of the transport > mechanisms between the master and sub-agent do need to be accounted for > somewhere. I get the impression that the requirements analysis has been > done already so... There have been fairly lengthy discussions in the past. Among the approaches that have been proposed: a) define a standard transport mapping, e.g., tcp/ip, and allow vendors to define others as needed for special environments. b) define a suite of standard transport mappings, each suited to a particular set of environments c) define no standard transport mapping; the transport mapping would in all cases be system specific I favor approach (a). Having a single standard transport mapping maximizes interoperability. As long as the QOS requirements ( e.g., 8-bit clean byte stream) are well-defined, it's not difficult to define additional, higher-performance or target-specific transports meeting this QOS. If a vendor is constrained to using a limited IPC mechanism that can't even provide byte-stream service, then they should build a convergence layer on top of it that can. Approach (b) is awkward, both from a specification management perspective and from the perspective of vendors who would have to support all of these. We'll evetually arrive at point (b), I believe, but I'd prefer to go there by way of (a). Approach (c) is good news for contractors, since every piece of software would have to be customized for every possible target. It's bad news for everyone else. Adding packet sequencing, CRCs, ARQ strategies, FEC techniques, and so on into an application layer protocol is not clean, efficient, or simple. These belong in a lower layer. If there is any requirement for the communication of RPC or other modern protocols between system components, this convergence layer will be necessary anyway. > 1. Are there mandatory/recommended/assumed protocol layers below agentx > that are expected to handle these limitations? I'd suggest TCP/IP as the basic one. A trivial convergence layer on top of UDP or other datagram service would solve some additional problems, but by layering our design we can avoid having to do it at this time. > 2. Assuming this is really out of scope for agentx, is it because: > a. it is assumed that lower layers will break up the PDU, ship it > through the small pipe, and then reassemble the PDU and present it to the > sub-agent, or This is really caught up in the issue of the choice of transfer syntax. If the transfer syntax is self-delimiting (TLV or otherwise), there's no need for the underlying layers to preserve PDU boundaries, or do packet assembly, as long as the byte stream is preserved. > b. it was decided not to address this issue at this time? ... This needs to be resolved. Here's what I'd like to see: 1. protocol requires connection-oriented, 8-bit clean, byte stream service. connection termination may lose data. 2. document should define mapping of agentx protocol onto TCP/IP as a transport providing this service. this should be the "interoperability" mapping. 3. definition of additional mappings to other protocols should be explicitly permitted, to avoid confusing the folks who confuse omission with prohibition. these additional mappings may be motivated by performance requirements or target environment constraints. The publication of these mappings should be encouraged. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Tue, 26 Mar 1996 11:54:02 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id LAA18044 for X-agentx-local; Tue, 26 Mar 1996 11:54:02 -0800 (PST) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id LAA17993 for ; Tue, 26 Mar 1996 11:53:56 -0800 (PST) Received: from flume.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA31384; Tue, 26 Mar 1996 14:47:00 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA19194; Tue, 26 Mar 1996 14:46:57 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA04892; Tue, 26 Mar 1996 14:47:29 -0500 Message-Id: <9603261947.AA04892@bernie.zk3.dec.com> To: george.best@antec.com (George Best) Cc: agentx@fv.com Subject: Re: 13: MaxVarBinds In-Reply-To: Your message of "Tue, 26 Mar 96 12:50:55 EST." <199603261750.MAA14070@ta.antec.com> Date: Tue, 26 Mar 96 14:47:29 -0500 From: Mike Daniele X-Mts: smtp Hi George, >1. Are there mandatory/recommended/assumed protocol layers below agentx >that are expected to handle these limitations? I don't think it would be wise for agentx to *require* underlying protocols. There will be transport discussions, but I would expect them to be in the context of defining the master agent's well-known transport addresses (or defining agentx MIB objects to permit discovering the transport addresses, etc), not dealing with possible bandwidth problems. >2. Assuming this is really out of scope for agentx, is it because: > a. it is assumed that lower layers will break up the PDU, ship it >through the small pipe, and then reassemble the PDU and present it to the >sub-agent, or > b. it was decided not to address this issue at this time? In my opinion, it's out of scope for agentx because agentx is an application protocol, and this is a transport (or below) issue. I think it would be reasonable in agent to specify transport *requirements*: o what the agentx packet sizes are for typical operations. o what typical agentx get/next/bulk/set packet sizes are as a function of SNMP request size, and various subagent configurations. How big are the agentx packets if a GetNext for 10 VarBinds when all 10 are dispatched to a single subagent? what if all 10 are dispatched to different subagents? o that it is a requirement of the local environment that agentx have access to buffers of sufficient size and number. This is implementation specific, and depends on number of subagents, is the master agent single-threaded, etc. o this may require tailoring the SNMP buffers, adjusting buffer policy, or implementing a service layer that provides the "buffer semantics" required by agentx. Agentx should handle "tooBig". But it shouldn't have to do fragmentation and reassembly. That's my 2 cents. Regards, Mike   Delivery-Date: Tue, 26 Mar 1996 12:28:31 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id MAA27433 for X-agentx-local; Tue, 26 Mar 1996 12:28:30 -0800 (PST) Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.139.6]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id MAA27430 for ; Tue, 26 Mar 1996 12:28:29 -0800 (PST) Received: from hawpub.watson.ibm.com ([9.2.90.19]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id PAA08522 for ; Tue, 26 Mar 1996 15:28:31 -0500 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/2/16/96) id AA36371; Tue, 26 Mar 1996 15:28:17 -0500 Message-Id: <9603262028.AA36371@hawpub.watson.ibm.com> Subject: Re: 13: MaxVarBinds To: agentx@fv.com Date: Tue, 26 Mar 1996 15:28:16 -0500 (EST) From: "Uri Blumenthal" In-Reply-To: <199603261936.AA115738966@dorothy.peer.com> from "Randy Presuhn" at Mar 26, 96 11:36:06 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Just one point I didn't mention (I think): it looks like you envision the subagent to most likely be dealing with lots of settable inderdependent objects. There are other, much simpler subagents, that are REALLY small and that deal with ONE variable at a time. I firmly believe we shouldn't make those impossible. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Tue, 26 Mar 1996 16:45:55 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id QAA04680 for X-agentx-local; Tue, 26 Mar 1996 16:45:55 -0800 (PST) Received: from acme.sb.west.net (acme.sb.west.net [205.254.224.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id QAA04675 for ; Tue, 26 Mar 1996 16:45:53 -0800 (PST) Received: from abierman.west.net (term1-9.vta.west.net [205.254.241.9]) by acme.sb.west.net (8.6.12/8.6.12) with SMTP id QAA02837; Tue, 26 Mar 1996 16:45:18 -0800 Message-ID: <31588F35.7C7@west.net> Date: Tue, 26 Mar 1996 16:43:33 -0800 From: Andy Bierman X-Mailer: Mozilla 2.0 (Win95; I) MIME-Version: 1.0 To: uri@watson.ibm.com CC: agentx@fv.com Subject: Re: 13: MaxVarBinds References: <9603262028.AA36371@hawpub.watson.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Uri Blumenthal wrote: > > Just one point I didn't mention (I think): it looks like you > envision the subagent to most likely be dealing with lots > of settable inderdependent objects. There are other, much > simpler subagents, that are REALLY small and that deal > with ONE variable at a time. I firmly believe we > shouldn't make those impossible. I must be missing something really basic here... Why can't the sub-agent just pass its 'maxMsgSize' when it registers with the master-agent? Why are you suggesting that max-message-size is measured in units of varbinds instead of octets? What kind of agent is designed to accept at most one varbind at a time (besides a nonconformant one)? I think a 'maxMsgSize' registration parameter is sufficient to handle the transport problem. A master-agent should dispatch sub-agent messages based on message size, NOT the number of varbinds in the PDU. Andy > -- > Regards, > Uri uri@watson.ibm.com > -=-=-=-=-=-=- > > > ================ > 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: Tue, 26 Mar 1996 17:16:53 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id RAA12690 for X-agentx-local; Tue, 26 Mar 1996 17:16:49 -0800 (PST) Received: from mail.sharplabs.com ([204.75.175.200]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id RAA12681 for ; Tue, 26 Mar 1996 17:16:46 -0800 (PST) Received: by mail.sharplabs.com (SMI-8.6/SMI-SVR4) id RAA05723; Tue, 26 Mar 1996 17:14:25 -0800 From: "Randy Turner" Message-Id: <9603261714.ZM5721@sla20a.sharplabs.com> Date: Tue, 26 Mar 1996 17:14:25 -0800 In-Reply-To: Andy Bierman "Re: 13: MaxVarBinds" (Mar 26, 4:43pm) References: <9603262028.AA36371@hawpub.watson.ibm.com> <31588F35.7C7@west.net> X-Mailer: Z-Mail (3.2.1 10apr95) To: agentx@fv.com Subject: Re: 13: MaxVarBinds Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Mar 26, 4:43pm, Andy Bierman wrote: > Subject: Re: 13: MaxVarBinds > Uri Blumenthal wrote: > > > > Just one point I didn't mention (I think): it looks like you > > envision the subagent to most likely be dealing with lots > > of settable inderdependent objects. There are other, much > > simpler subagents, that are REALLY small and that deal > > with ONE variable at a time. I firmly believe we > > shouldn't make those impossible. > > I must be missing something really basic here... > Why can't the sub-agent just pass its 'maxMsgSize' when it > registers with the master-agent? > Why are you suggesting that max-message-size is measured in units > of varbinds instead of octets? > What kind of agent is designed to accept at most one varbind at > a time (besides a nonconformant one)? > > I think a 'maxMsgSize' registration parameter is sufficient to handle > the transport problem. A master-agent should dispatch sub-agent messages > based on message size, NOT the number of varbinds in the PDU. I agree, a byte-quantity message size would be more useful. A varbind is too ambiguous as to how many bytes is required to contain a particular varbind. Randy > > Andy > > - End of excerpt from Andy Bierman   Delivery-Date: Tue, 26 Mar 1996 23:47:21 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id XAA16387 for X-agentx-local; Tue, 26 Mar 1996 23:47:21 -0800 (PST) Received: from garam.kreonet.re.kr (garam.kreonet.re.kr [134.75.30.11]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id XAA16367 for ; Tue, 26 Mar 1996 23:47:16 -0800 (PST) Received: from super5.hyundai.co.kr (super5.hyundai.co.kr [134.75.165.2]) by garam.kreonet.re.kr (8.6.9H1/8.6.12) with SMTP id QAA25194 for ; Wed, 27 Mar 1996 16:47:36 +0900 Received: by super5.hyundai.co.kr (4.1/SMI-4.1) id AA11768; Wed, 27 Mar 96 16:36:07 KST Date: Wed, 27 Mar 96 16:36:07 KST From: wind@super5.hyundai.co.kr (Im SangHyeon) Message-Id: <9603270736.AA11768@super5.hyundai.co.kr> To: agentx@fv.com subscribe wind@super5.hyundai.co.kr   Delivery-Date: Wed, 27 Mar 1996 05:37:25 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id FAA23360 for X-agentx-local; Wed, 27 Mar 1996 05:37:24 -0800 (PST) Received: from ta.antec.com ([205.187.171.11]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id FAA23352 for ; Wed, 27 Mar 1996 05:37:23 -0800 (PST) Received: from pc_georgeb by ta.antec.com via SMTP (8.6.12/8.6.4) for id IAA19639; Wed, 27 Mar 1996 08:31:57 -0500 Date: Wed, 27 Mar 1996 08:31:57 -0500 Message-Id: <199603271331.IAA19639@ta.antec.com> X-Sender: georgeb@bopper.ta.antec.com X-Mailer: Windows Eudora Version 2.0.3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: agentx@fv.com From: george.best@antec.com (George Best) Subject: Re: 13: MaxVarBinds At 05:14 PM 3/26/96 -0800, Randy Turner wrote: >I agree, a byte-quantity message size would be more useful. A varbind is >too ambiguous as to how many bytes is required to contain a particular varbind. > It sounds like there's a couple of places where limitations can be found: a. the communications between the master and sub-agent - Here, the limitation could be handled at layers below UDP meaning that this issue is not within the scope of the agentx protocol definition. (This assumes that everyone agrees that communications between master and sub-agents should be SNMP PDUs and that the agentx protocol stops at the point that the SNMP message is put into a UDP packet.) b. the memory space of the sub-agent - Would the proper response be to pass a tooBig from the sub through the master to the manager? If so, we'd be passing a tooBig back to the manager that could be based on a subset of a set-request (i.e., the set-request could be multiplexed to multiple sub-agents and only some would respond with a tooBig). This issue does sound like it should be within the scope of the agentx protocol because it involves SNMP message-level communications. Has the requirements analysis been done in this area yet? If not, this would seem to be the place where additional work is needed. Gb - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - George Best email: georgeb@antec.com Digital Video, Norcross GA, USA voice: (770)734-0400 ext. 8534   Delivery-Date: Wed, 27 Mar 1996 10:21:25 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id KAA03630 for X-agentx-local; Wed, 27 Mar 1996 10:21:25 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id KAA03598 for ; Wed, 27 Mar 1996 10:21:23 -0800 (PST) Message-Id: <199603271821.AA201040909@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA201040909; Wed, 27 Mar 1996 10:21:49 -0800 Date: Wed, 27 Mar 1996 10:21:49 -0800 From: Randy Presuhn To: agentx@fv.com Subject: Re: 13: MaxVarBinds Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - I am surpised that we are spending this much time and energy on this point. There are other more interesting and important matters to consider. > Date: Wed, 27 Mar 1996 08:31:57 -0500 > Message-Id: <199603271331.IAA19639@ta.antec.com> > To: agentx@fv.com > From: george.best@antec.com (George Best) > Subject: Re: 13: MaxVarBinds ... > It sounds like there's a couple of places where limitations can be found: > > a. the communications between the master and sub-agent - > > Here, the limitation could be handled at layers below UDP meaning that > this issue is not within the scope of the agentx protocol definition. (This > assumes that everyone agrees that communications between master and > sub-agents should be SNMP PDUs and that the agentx protocol stops at the > point that the SNMP message is put into a UDP packet.) In Los Angeles we agreed use DPIv2, which does not use encapsulated SNMP PDUs, as the starting point for the protocol work. The clear preference for the standardized transport mechanism seemed to be TCP, with the possibility of other transports defined elsewhere left open. In any case, we're asking for trouble if we don't learn from experience and keep this design layered. > b. the memory space of the sub-agent - > > Would the proper response be to pass a tooBig from the sub through the > master to the manager? If so, we'd be passing a tooBig back to the manager > that could be based on a subset of a set-request (i.e., the set-request > could be multiplexed to multiple sub-agents and only some would respond with > a tooBig). This issue does sound like it should be within the scope of the > agentx protocol because it involves SNMP message-level communications. Has > the requirements analysis been done in this area yet? If not, this would > seem to be the place where additional work is needed. ... Depending on the choice of transfer syntax, there may be no need for a subagent to marshall its entire reponse in memory. The issue then becomes one of the maximum request size a single subagent can handle. If the target environment is so constrained as to preclude even marhsalling a request, there are going to be so many other constraints (it has to fit on a single PDP-8 memory page and be reentrant :-) that a general solution may not be practical. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------   Delivery-Date: Wed, 27 Mar 1996 11:23:49 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id LAA19231 for X-agentx-local; Wed, 27 Mar 1996 11:23:49 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id LAA19220 for ; Wed, 27 Mar 1996 11:23:48 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA22646 for ; Wed, 27 Mar 96 14:03:25 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA16752; Wed, 27 Mar 1996 14:04:02 -0500 Date: Wed, 27 Mar 1996 14:04:57 EST From: Bob Natale Subject: Jeff's EMANATE slides for AgentX To: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi, At the Dallas IETF AgentX meetings (Dec 95), Jeff Case gave a detailed overview of EMANATE and how it addresses many of the issues confronting AgentX. This presentation can now be retrieved via anonymous ftp from: ftp.fv.com/pub/agentx/95-12/jcase.ps. the ~/95-12 subdirectory contains other presentations from the Dallas meetings. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Wed, 27 Mar 1996 11:46:18 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id LAA24336 for X-agentx-local; Wed, 27 Mar 1996 11:46:11 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id LAA24332 for ; Wed, 27 Mar 1996 11:46:09 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA23551 for ; Wed, 27 Mar 96 14:14:46 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA16915; Wed, 27 Mar 1996 14:15:26 -0500 Date: Wed, 27 Mar 1996 14:16:21 EST From: Bob Natale Subject: 13: MaxVarBinds - Interim decision To: Randy Presuhn Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Randy Presuhn > Date: Wed, 27 Mar 1996 10:21:49 -0800 Hi Randy, > I am surpised that we are spending this much time and energy on > this point. True. I think it's safe to say that we have reached a fair degree of consensus (IETF WG sense of the term) on this specific point: - MaxVarBinds is tabled...current resolution is that there will be no specific MaxVarBinds limit in AgentX. - MaxMessageSize (MMS) seems potentially relevant and suggestions may be proposed and discussed. Just to help keep the different issues organized, please note: - How MMS affects request/response processing belongs under "13: Request/Response Processing". - How MMS gets specified/negotiated or whatever between master and subagent and related transport type issues belong under "06: Master/Component 'Binding'". <...> Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Thu, 28 Mar 1996 10:38:11 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id KAA21140 for X-agentx-local; Thu, 28 Mar 1996 10:38:11 -0800 (PST) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id KAA21136 for ; Thu, 28 Mar 1996 10:38:09 -0800 (PST) Received: from flume.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA05670; Thu, 28 Mar 1996 13:33:27 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA23887; Thu, 28 Mar 1996 13:33:25 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA05665; Thu, 28 Mar 1996 13:34:00 -0500 Message-Id: <9603281834.AA05665@bernie.zk3.dec.com> To: agentx@fv.com Subject: 06: Master/Component "Binding" - Transport/IPC Date: Thu, 28 Mar 96 13:33:59 -0500 From: Mike Daniele X-Mts: smtp > - How MMS gets specified/negotiated or whatever > between master and subagent and related > transport type issues belong under "06: > Master/Component 'Binding'". I propose the master agent return a value of MMS in the response to the OPEN message. Both sides already know any size limit inherent to the transport in use. The master also knows any MMS restrictions on inbound SNMP requests. Based on those things it determines a reasonable AgentX MMS. AgentX messages are sent in a single transport 'packet'. On systems with severely constrained IPC, etc, the AgentX MMS will be small. (Perhaps an implementation-specific service layer may be provided in these cases as Randy has suggested, that provides a larger virtual pipe.) We might want to suggest reasonable upper and lower bounds. Thoughts? Mike   Delivery-Date: Thu, 28 Mar 1996 15:02:06 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id PAA03062 for X-agentx-local; Thu, 28 Mar 1996 15:02:05 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.4/8.7.3) with ESMTP id PAA02961 for ; Thu, 28 Mar 1996 15:02:04 -0800 (PST) Message-Id: <199603282302.AA033614143@dorothy.peer.com> Received: by dorothy.peer.com (1.39.111.2/16.2) id AA033614143; Thu, 28 Mar 1996 15:02:23 -0800 Date: Thu, 28 Mar 1996 15:02:23 -0800 From: Randy Presuhn To: agentx@fv.com Subject: Re: 06: Master/Component "Binding" - Transport/IPC Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - > Message-Id: <9603281834.AA05665@bernie.zk3.dec.com> > To: agentx@fv.com > Subject: 06: Master/Component "Binding" - Transport/IPC > Date: Thu, 28 Mar 96 13:33:59 -0500 > From: Mike Daniele > > > - How MMS gets specified/negotiated or whatever > > between master and subagent and related > > transport type issues belong under "06: > > Master/Component 'Binding'". > > I propose the master agent return a value of MMS in the response > to the OPEN message. > > Both sides already know any size limit inherent to the transport > in use. The master also knows any MMS restrictions on inbound SNMP > requests. Based on those things it determines a reasonable AgentX MMS. Depending on which version of SNMPv2 is in use, MMS is a property of - the party to which the operation's response should be sent - the transport over which the operation's repsonse should be sent - a proposed MMS carried directly in the request In all of these cases, the MMS consequently may vary from request to request. For this reason, a MMS as part of the OPEN exchange would be of questionable value. > AgentX messages are sent in a single transport 'packet'. On systems There are well-known transports that really don't have any concept of packet at their service boundary. A popular one is TCP. There's no promise (even over a localhost connection) that the number of reads and writes at opposite ends of a connection will be equal to transfer a given number of bytes. There's no indication of packet boundaries, and no way to tell it where to put one. If we say we use a datagram QOS, then it'd be necessary to add ARQ strategies to the protocol. We don't need this complexity; there's already a solution waiting for us to use it. > with severely constrained IPC, etc, the AgentX MMS will be small. > (Perhaps an implementation-specific service layer may be provided in these > cases as Randy has suggested, that provides a larger virtual pipe.) I'm not sure why there is all this concern about packet sizes. Do we want to run this raw over ATM cells, without even the benefit of something so basic as IP fragmentation, much less a real transport like TCP, Unix sockets, named pipes, or IPC? Why? Every multitasking environment I've worked in, including PDP-8, 8048, 8051, 6802, and Z80 assembler ones, had at least a clean byte-stream IPC mechanism. Granted, the PDP-8 "bytes" were 6-bit characters packed into 12 bit words... Is there a name for this environment that's the cause of all this concern? > We might want to suggest reasonable upper and lower bounds. ... If we select our encoding rules intelligently, so as to be usable with a simple byte stream QOS as is provided by TCP, there is no reason to set a lower bound (other than 1 byte). Determination of tooBig must occur on a request-by-request basis, and must occur in the master agent. Consider get-next/bulk in the presence of access control. Something that the subagent might think would be too big might be excluded by access control. For the subagent to make the decision to abort the operation would be inappropriate. ----------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy_presuhn@bmc.com USA -----------------------------------------------------------------------------