Delivery-Date: Tue, 01 Jul 1997 12:19:04 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id MAA22155 for X-agentx; Tue, 1 Jul 1997 12:19:04 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id MAA22152 for ; Tue, 1 Jul 1997 12:19:03 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id MAA07072 for ; Tue, 1 Jul 1997 12:19:00 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id MAA14788 for ; Tue, 1 Jul 1997 12:11:56 -0700 (PDT) Received: from khitomer.epilogue.com(128.224.1.172) by gauntlet.fv.com via smap (3.2) id xma014751; Tue, 1 Jul 97 12:11:49 -0700 From: "Shawn A. Routhier" Sender: sar@khitomer.epilogue.com To: agentx@fv.com cc: sar@epilogue.com Subject: Comments and questions on the agentx mib Date: Tue, 1 Jul 97 15:18:53 -0400 Message-ID: <9707011518.aa02157@khitomer.epilogue.com> I've been thinking about how I would implement the agentX procotocol and mibs and had some questions and comments about the mib as defined in the May 14 version of draft-ietf-agentx-mib-00.txt. 1) The object agentxSATimeout claims that "if the agent supports writing of this object the new value will be used for the next agentx-Open-PDU the subagent sends" If I understand the mib correctly this object is on the master side, how is this information suppossed to be conveyed to the subagent for subsequent use? Two other objects, agentxRegPriority and agentxRegTimeout have similar definitions. 2) agentxRegIndex is defined simple as "An integer that uniquely identifies a registration entry" From my reading of the document I would think it can be changed whenever the master wanted to, is that what was intended? I would also point out that using such an index rather than incorporating agentxRegStart into the index means that managers may have to get the entire table in order to determine if any particular object id is included in a registered region. This seems potentially costly to me. 3) agentxRegistrationTable I would think that the registration and dispatch tables would be of similar value to a manager. Given that the registration table will be either the same size or smaller than the dispatch table and, for some types of agents, much easier to compute I don't see why the mib chooses to use the dispatch table over the registraion table. sar   Delivery-Date: Tue, 01 Jul 1997 12:49:34 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id MAA24466 for X-agentx; Tue, 1 Jul 1997 12:49:33 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id MAA24463 for ; Tue, 1 Jul 1997 12:49:33 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id MAA09510 for ; Tue, 1 Jul 1997 12:49:29 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id MAA17508 for ; Tue, 1 Jul 1997 12:42:26 -0700 (PDT) Received: from khitomer.epilogue.com(128.224.1.172) by gauntlet.fv.com via smap (3.2) id xma017475; Tue, 1 Jul 97 12:42:04 -0700 From: "Shawn A. Routhier" Sender: sar@khitomer.epilogue.com To: agentx@fv.com Subject: Questions about the AgentX protocol Date: Tue, 1 Jul 97 15:49:08 -0400 Message-ID: <9707011549.aa06721@khitomer.epilogue.com> These questions refer to draft-ietf-agentx-ext-pro-04.txt. 1) What should a master agent do if, while processing a snmp request it receives an agentx administrative request? For example: a master agent has received a set request, has sent out the test requests to the sub agents and is waiting for their replies. It now receives a request from a sub agent to register some region. Should it: discard the request in some fashion, defer the request until after the set is finished or process the registration while the set is in process? 2) If a subagent detects an error during either the test or commit phases of a set request after it is sent a response to the master should it expect a cleanup or undo request from the master or should it clean up or undo the request state on it's own? sar   Delivery-Date: Wed, 02 Jul 1997 18:53:43 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id SAA20068 for X-agentx; Wed, 2 Jul 1997 18:53:43 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id SAA20065 for ; Wed, 2 Jul 1997 18:53:42 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id SAA26624 for ; Wed, 2 Jul 1997 18:53:37 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id SAA02739 for ; Wed, 2 Jul 1997 18:46:30 -0700 (PDT) Received: from dresden.bmc.com(198.64.253.250) by gauntlet.fv.com via smap (3.2) id xma002736; Wed, 2 Jul 97 18:46:27 -0700 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.5) id UAA03361 for ; Wed, 2 Jul 1997 20:53:41 -0500 (CDT) Received: from cherry.bmc.com(172.17.1.25) by dresden.bmc.com via smap (3.2) id xma003342; Wed, 2 Jul 97 20:53:29 -0500 Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by cherry.bmc.com with ESMTP (8.7.5/8.7.3) id UAA02134; Wed, 2 Jul 1997 20:53:20 -0500 (CDT) Received: by dorothy.peer.com (1.39.111.2/16.2) id AA087764799 for ; Wed, 2 Jul 1997 18:53:19 -0700 From: Smitha Gudur Message-Id: <199707030153.AA087764799@dorothy.peer.com> Subject: Re: Comments and questions on the agentx mib To: sar@epilogue.com Date: Wed, 02 Jul 1997 18:53:19 PDT Cc: agentx@fv.com In-Reply-To: <9707011518.aa02157@khitomer.epilogue.com>; from "Shawn A. Routhier" at Jul 1, 97 3:18 pm X-Mailer: Elm [revision: 111.1] > > > I've been thinking about how I would implement the agentX > procotocol and mibs and had some questions and comments about > the mib as defined in the May 14 version of draft-ietf-agentx-mib-00.txt. > > 1) The object agentxSATimeout claims that > "if the agent supports writing of this object the new value > will be used for the next agentx-Open-PDU the subagent sends" > > If I understand the mib correctly this object is on the master side, > how is this information suppossed to be conveyed to the subagent for > subsequent use? > > Two other objects, agentxRegPriority and agentxRegTimeout have similar > definitions. I agree that the information cannot be conveyed to subagent. so these objects have to be changed to "read-only" in the mib. > 2) agentxRegIndex is defined simple as > "An integer that uniquely identifies a registration entry" > >From my reading of the document I would think it can be changed > whenever the master wanted to, is that what was intended? I would > also point out that using such an index rather than incorporating > agentxRegStart into the index means that managers may have to get > the entire table in order to determine if any particular object id > is included in a registered region. This seems potentially costly > to me. > The description should be made clearer for this and changed in the draft to "Index values assigned for a given registration is constant for the lifetime of this Table" > 3) agentxRegistrationTable > I would think that the registration and dispatch tables would > be of similar value to a manager. Given that the registration > table will be either the same size or smaller than the dispatch > table and, for some types of agents, much easier to compute I don't > see why the mib chooses to use the dispatch table over the registraion table. > Description should be changed to say: "This is the table used to identify a registered region of a subagent". "A table of registered OBJECT IDENTIFIER regions. This is the table used to identify a registered region of a subagent. Note that a subagent registration may be broken up into multiple entries in this table, as described in the AgentX Protocol specification [5]. Thanks smitha > sar > > > > > > > ---------------- > 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: Wed, 02 Jul 1997 23:11:19 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id XAA09740 for X-agentx; Wed, 2 Jul 1997 23:11:18 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id XAA09737 for ; Wed, 2 Jul 1997 23:11:18 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id XAA09164 for ; Wed, 2 Jul 1997 23:11:14 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id XAA07984 for ; Wed, 2 Jul 1997 23:04:07 -0700 (PDT) Message-Id: <199707030604.XAA07984@gauntlet.fv.com> Received: from vnet.ibm.com(204.146.168.194) by gauntlet.fv.com via smap (3.2) id xma007981; Wed, 2 Jul 97 23:04:05 -0700 Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 6651; Thu, 03 Jul 97 02:11:11 EDT Date: Thu, 3 Jul 97 07:53:38 DST From: "Bert Wijnen" To: sgudur@peer.com, sar@epilogue.com cc: agentx@fv.com Subject: Comments and questions on the agentx mib Ref: Your note of Wed, 02 Jul 1997 18:53:19 PDT Subject: Re: Comments and questions on the agentx mib Shawn and Smitha discuss: > > 1) The object agentxSATimeout claims that > > "if the agent supports writing of this object the new value > > will be used for the next agentx-Open-PDU the subagent sends" > > > > If I understand the mib correctly this object is on the master side, > > how is this information suppossed to be conveyed to the subagent for > > subsequent use? > > > > Two other objects, agentxRegPriority and agentxRegTimeout have similar > > definitions. > > I agree that the information cannot be conveyed to subagent. > so these objects have to be changed to "read-only" in the mib. > Oooopssss.... not so hasty please. The idea here was (in my original very old saMIB where I had similar objects) that a manager would be able to change the timout and pritority so that a "mis-behaving" subagent could be controlled. I an agree that it kind of would be nice if the info could be passed to the subagent in question, but that is not absolutly necessary to make these object useful in read-write mode. And so I do not (yet) agree with making them read-only More important.... it is good to hear that Shawn (or anyone) is trying to implement and thus evaluat ethis MIB. But we should realize that we did not spend much time on the MIB... and so I would expect that if we pick up this work (after the agentX protocol itself gets out as a Proposed-level RFC) that then we may/will come up with quite a few changes. Bert   Delivery-Date: Thu, 03 Jul 1997 06:16:12 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id GAA11557 for X-agentx; Thu, 3 Jul 1997 06:16:11 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id GAA11553 for ; Thu, 3 Jul 1997 06:16:11 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id GAA02063 for ; Thu, 3 Jul 1997 06:16:08 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id GAA15997 for ; Thu, 3 Jul 1997 06:08:58 -0700 (PDT) Received: from ibere.tecgraf.puc-rio.br(139.82.85.1) by gauntlet.fv.com via smap (3.2) id xma015979; Thu, 3 Jul 97 06:08:56 -0700 Received: from planck.netdreams.com.br by ibere.tecgraf.puc-rio.br (SMI-8.6/SMI-SVR4) id KAA27192; Thu, 3 Jul 1997 10:14:21 -0300 Message-Id: <199707031314.KAA27192@ibere.tecgraf.puc-rio.br> Comments: Authenticated sender is From: "Paulo Henrique Mascarenhas Sant'Anna" To: agentx@fv.com Date: Wed, 2 Jul 1997 22:15:14 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Off Topic: Subagent Identifiers Reply-to: paulo@inf.puc-rio.br X-Confirm-Reading-To: paulo@inf.puc-rio.br X-pmrqc: 1 Priority: normal X-mailer: Pegasus Mail for Win32 (v2.52) Dear Sirs, Sorry for this off topic question but I want to clarifie a point that seems, at least in the version of the draft that I have, not clear to me. In the draft Object Identifiers are also used to identify Subagents. What is the range to be used? BTW I'm working in an AgentX implementation using CMU agent code and an extension language called Lua. Thanks a lot, -- Paulo Henrique   Delivery-Date: Mon, 07 Jul 1997 09:12:08 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id JAA11889 for X-agentx; Mon, 7 Jul 1997 09:12:08 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id JAA11817 for ; Mon, 7 Jul 1997 09:11:58 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id JAA00722 for ; Mon, 7 Jul 1997 09:11:57 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id JAA16896 for ; Mon, 7 Jul 1997 09:04:37 -0700 (PDT) Received: from mail13.digital.com(192.208.46.30) by gauntlet.fv.com via smap (3.2) id xma016861; Mon, 7 Jul 97 09:04:30 -0700 Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id LAA29247; Mon, 7 Jul 1997 11:52:25 -0400 (EDT) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA16092; Mon, 7 Jul 1997 11:52:22 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA10820; Mon, 7 Jul 1997 11:48:31 -0400 Message-Id: <9707071548.AA10820@bernie.zk3.dec.com> To: paulo@inf.puc-rio.br Cc: agentx@fv.com Subject: Re: Off Topic: Subagent Identifiers In-Reply-To: Your message of "Wed, 02 Jul 97 22:15:14 -0000." <199707031314.KAA27192@ibere.tecgraf.puc-rio.br> Date: Mon, 07 Jul 97 11:48:31 -0400 From: Mike Daniele X-Mts: smtp >In the draft Object Identifiers are also used to identify Subagents. >What is the range to be used? Hi Paulo, The AgentX protocol draft includes object identifiers that "identify" a subagent in the Open and AddagentCaps pdus. In the Open pdu it would be a value like that of sysObjectID (if the subagent has such a value). In the AddAgentCaps pdu it would be a value of sysORID. But the draft doesn't define any particular object identifier values. (I'm not sure if I understand your question.) Regards, Mike   Delivery-Date: Wed, 16 Jul 1997 07:54:07 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id HAA14594 for X-agentx; Wed, 16 Jul 1997 07:54:07 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id HAA14591 for ; Wed, 16 Jul 1997 07:54:06 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id HAA25688 for ; Wed, 16 Jul 1997 07:54:03 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id HAA29257 for ; Wed, 16 Jul 1997 07:53:27 -0700 (PDT) Received: from seymour16.snmp.com(192.147.142.16) by gauntlet.fv.com via smap (3.2) id xma029216; Wed, 16 Jul 97 07:53:12 -0700 Received: by seymour16.snmp.com (cf v2.9s-SNMP) id KAA28799; Wed, 16 Jul 1997 10:53:01 -0400 (EDT) Date: Wed, 16 Jul 1997 10:53:01 -0400 (EDT) From: David Battle Message-Id: <199707161453.KAA28799@seymour16.snmp.com> To: agentx@fv.com Subject: o.timeout > An agentx-Open-PDU contains the following fields: > > o.timeout > The length of time, in seconds, that a master agent should > allow to elapse after dispatching a message to a subagent > before it regards the subagent as not responding. This is a > subagent-wide default value that may be overridden by values Since subagents can have multiple sessions open at once, shouldn't this say something like "session-wide" instead of "subagent-wide"? Thanks, -David   Delivery-Date: Wed, 16 Jul 1997 08:11:03 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id IAA15990 for X-agentx; Wed, 16 Jul 1997 08:11:03 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id IAA15987 for ; Wed, 16 Jul 1997 08:11:02 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id IAA27057 for ; Wed, 16 Jul 1997 08:10:59 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id IAA00390 for ; Wed, 16 Jul 1997 08:10:31 -0700 (PDT) Received: from seymour16.snmp.com(192.147.142.16) by gauntlet.fv.com via smap (3.2) id xma000373; Wed, 16 Jul 97 08:10:23 -0700 Received: by seymour16.snmp.com (cf v2.9s-SNMP) id LAA08478; Wed, 16 Jul 1997 11:10:37 -0400 (EDT) Date: Wed, 16 Jul 1997 11:10:37 -0400 (EDT) From: David Battle Message-Id: <199707161510.LAA08478@seymour16.snmp.com> To: agentx@fv.com Subject: NETWORK_BYTE_ORDER > - The NETWORK_BYTE_ORDER value in h.flags is retained. > All subsequent AgentX protocol operations initiated by > the master agent for this session must use this byte > ordering and set this bit accordingly. > > The subagent typically sets this bit to correspond to > its native byte ordering, and typically does not vary > byte ordering for an initiated session. The master > agent must be able to decode each PDU according to the > h.flag NETWORK_BYTE_ORDER bit in the PDU, but does not > need to toggle its retained value for the session if > the subagent varies its byte ordering. If the master agent must be able to decode each PDU according to the h.flag NETWORK_BYTE_ORDER bit in the PDU, then why does the master agent need to retain the one from the session open PDU? When would the master agent ever refer to such a retained bit? I think we should eliminate the language which refers to retaining the bit and simply say that the master agent checks the bit in each PDU. -David   Delivery-Date: Wed, 16 Jul 1997 08:54:49 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id IAA19364 for X-agentx; Wed, 16 Jul 1997 08:54:49 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id IAA19361 for ; Wed, 16 Jul 1997 08:54:48 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id IAA00694 for ; Wed, 16 Jul 1997 08:54:47 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id IAA03899 for ; Wed, 16 Jul 1997 08:54:17 -0700 (PDT) Received: from mail13.digital.com(192.208.46.30) by gauntlet.fv.com via smap (3.2) id xma003859; Wed, 16 Jul 97 08:53:50 -0700 Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id LAA09224; Wed, 16 Jul 1997 11:32:47 -0400 (EDT) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA28330; Wed, 16 Jul 1997 11:32:49 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA20037; Wed, 16 Jul 1997 11:28:54 -0400 Message-Id: <9707161528.AA20037@bernie.zk3.dec.com> To: David Battle Cc: agentx@fv.com Subject: Re: NETWORK_BYTE_ORDER In-Reply-To: Your message of "Wed, 16 Jul 97 11:10:37 EDT." <199707161510.LAA08478@seymour16.snmp.com> Date: Wed, 16 Jul 97 11:28:53 -0400 From: Mike Daniele X-Mts: smtp Hi David, Glad to hear you're back to work :-) >If the master agent must be able to decode each PDU according to the >h.flag NETWORK_BYTE_ORDER bit in the PDU, then why does the master agent >need to retain the one from the session open PDU? When would the master >agent ever refer to such a retained bit? Whenever it initiates communication as opposed to responding (like sending get/next/bulk/set pdus). Mike   Delivery-Date: Wed, 16 Jul 1997 09:15:54 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id JAA21105 for X-agentx; Wed, 16 Jul 1997 09:15:53 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id JAA21102 for ; Wed, 16 Jul 1997 09:15:53 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id JAA02944 for ; Wed, 16 Jul 1997 09:15:50 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id JAA05957 for ; Wed, 16 Jul 1997 09:15:20 -0700 (PDT) Received: from relay1.smtp.psi.net(38.8.14.2) by gauntlet.fv.com via smap (3.2) id xma005933; Wed, 16 Jul 97 09:14:54 -0700 Received: from nips.acec.com by relay1.smtp.psi.net (8.8.3/SMI-5.4-PSI) id MAA10009; Wed, 16 Jul 1997 12:15:06 -0400 (EDT) Received: from bnatale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA17861; Wed, 16 Jul 1997 12:15:50 -0400 Message-Id: <3.0.1.32.19970716121709.009556a0@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 16 Jul 1997 12:17:09 -0400 To: David Battle From: Bob Natale Subject: Re: NETWORK_BYTE_ORDER Cc: agentx@fv.com In-Reply-To: <199707161510.LAA08478@seymour16.snmp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 11:10 AM 7/16/97 -0400, David Battle wrote: Hi David, <...> >If the master agent must be able to decode each PDU according >to the h.flag NETWORK_BYTE_ORDER bit in the PDU, then why does >the master agent need to retain the one from the session open PDU? >When would the master agent ever refer to such a retained bit? When initiating an exchange with the sub-agent (e.g., sending it a request packet). >I think we should eliminate the language which refers to retaining >the bit and simply say that the master agent checks the bit in each >PDU. The language might be less than perfect as is, but is probably ok. The intent is that the byte order established by the sub- agent at session open will normally be used for all communications between the two. However, since the flag bit is there, if the sub does change it on a packet to the master, the master must be able to deal with that transparently. This does not put any additional burden on the master, since it must be able to deal with either byte order flag value at session open anyway. Cordially, BobN ----- ISO 9001 Registered Hardware and Software Divsions ---- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ---- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ---- ------ NetPlus (r) "FCAPS" Telemanagement Applications ------   Delivery-Date: Wed, 16 Jul 1997 12:17:15 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id MAA06020 for X-agentx; Wed, 16 Jul 1997 12:17:15 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id MAA06017 for ; Wed, 16 Jul 1997 12:17:14 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id MAA24705 for ; Wed, 16 Jul 1997 12:17:03 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id MAA25826 for ; Wed, 16 Jul 1997 12:16:34 -0700 (PDT) Received: from mail13.digital.com(192.208.46.30) by gauntlet.fv.com via smap (3.2) id xma025818; Wed, 16 Jul 97 12:16:20 -0700 Received: from flume.zk3.dec.com (flume.zk3.dec.com [16.140.112.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id OAA00098; Wed, 16 Jul 1997 14:21:14 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA31083; Wed, 16 Jul 1997 14:20:28 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA20224; Wed, 16 Jul 1997 14:16:51 -0400 Message-Id: <9707161816.AA20224@bernie.zk3.dec.com> To: David Battle Cc: agentx@fv.com Subject: Re: o.timeout In-Reply-To: Your message of "Wed, 16 Jul 97 10:53:01 EDT." <199707161453.KAA28799@seymour16.snmp.com> Date: Wed, 16 Jul 97 14:16:50 -0400 From: Mike Daniele X-Mts: smtp >> An agentx-Open-PDU contains the following fields: >> >> o.timeout >> The length of time, in seconds, that a master agent should >> allow to elapse after dispatching a message to a subagent >> before it regards the subagent as not responding. This is a >> subagent-wide default value that may be overridden by values >Since subagents can have multiple sessions open at once, shouldn't this >say something like "session-wide" instead of "subagent-wide"? Yes it should. Also, in 7.1.1 4) - The o.timeout value is used in calculating response timeout conditions for this subagent. we should say "for this session". Oddly enough, 7.2.1 4) is correct... :-) Thanks, Mike   Delivery-Date: Wed, 16 Jul 1997 12:56:29 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id MAA09227 for X-agentx; Wed, 16 Jul 1997 12:56:29 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id MAA09224 for ; Wed, 16 Jul 1997 12:56:28 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id MAA28608 for ; Wed, 16 Jul 1997 12:56:22 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id MAA29017 for ; Wed, 16 Jul 1997 12:55:54 -0700 (PDT) Received: from mail13.digital.com(192.208.46.30) by gauntlet.fv.com via smap (3.2) id xma029009; Wed, 16 Jul 97 12:55:47 -0700 Received: from flume.zk3.dec.com (flume.zk3.dec.com [16.140.112.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id PAA24759; Wed, 16 Jul 1997 15:47:11 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA19921; Wed, 16 Jul 1997 15:44:20 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA20704; Wed, 16 Jul 1997 15:39:22 -0400 Message-Id: <9707161939.AA20704@bernie.zk3.dec.com> To: "Shawn A. Routhier" Cc: agentx@fv.com Subject: Re: Questions about the AgentX protocol In-Reply-To: Your message of "Tue, 01 Jul 97 15:49:08 EDT." <9707011549.aa06721@khitomer.epilogue.com> Date: Wed, 16 Jul 97 15:39:22 -0400 From: Mike Daniele X-Mts: smtp Hi Shawn, Sorry for the delay in answering. >1) What should a master agent do if, while processing a snmp >request it receives an agentx administrative request? I think that's best left up to the implementation, and probably differs as well depending on which PDU is received. > 2) If a subagent detects an error during either the test or commit >phases of a set request after it is sent a response to the master >should it expect a cleanup or undo request from the master or should >it clean up or undo the request state on it's own? In either case, regardless of how it responded, the subagent should expect at least 1 more PDU (see 7.3.1). The last PDU a subagent receives is either UndoSet or CleanupSet. Regards, Mike   Delivery-Date: Thu, 17 Jul 1997 12:14:05 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id MAA07654 for X-agentx; Thu, 17 Jul 1997 12:14:04 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id MAA07651 for ; Thu, 17 Jul 1997 12:14:03 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id MAA25894 for ; Thu, 17 Jul 1997 12:14:01 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id MAA14295 for ; Thu, 17 Jul 1997 12:13:29 -0700 (PDT) Received: from seymour16.snmp.com(192.147.142.16) by gauntlet.fv.com via smap (3.2) id xma014287; Thu, 17 Jul 97 12:13:24 -0700 Received: by seymour16.snmp.com (cf v2.9s-SNMP) id PAA01372; Thu, 17 Jul 1997 15:13:54 -0400 (EDT) Date: Thu, 17 Jul 1997 15:13:54 -0400 (EDT) From: David Battle Message-Id: <199707171913.PAA01372@seymour16.snmp.com> To: agentx@fv.com Subject: elements of procedure It seems to me that the elements of procedure muddle the idea of subagent and session in many places. For example, in 7.2.4.5 > An agentx-UndoSet-PDU is sent to each target subagent that has > been sent a agentx-CommitSet-PDU. All other subagents are sent a > agentx-CleanupSet-PDU. There are two things I don't like about this paragraph. One is it talks about sending things to a subagent rather than a particular session within a subagent. The other thing is that it says "all other subagents" when I think it means something like "all other sessions involved in the processing of the set request in question". In particular you wouldn't send a CleanupSet to sessions who had never received a TestSet (ie because they aren't even registered for the mib region/context involved). -David   Delivery-Date: Thu, 17 Jul 1997 12:26:41 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id MAA08654 for X-agentx; Thu, 17 Jul 1997 12:26:40 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id MAA08651 for ; Thu, 17 Jul 1997 12:26:40 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id MAA27400 for ; Thu, 17 Jul 1997 12:26:36 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id MAA15458 for ; Thu, 17 Jul 1997 12:26:04 -0700 (PDT) Received: from seymour16.snmp.com(192.147.142.16) by gauntlet.fv.com via smap (3.2) id xma015389; Thu, 17 Jul 97 12:25:39 -0700 Received: by seymour16.snmp.com (cf v2.9s-SNMP) id PAA01738; Thu, 17 Jul 1997 15:26:07 -0400 (EDT) Date: Thu, 17 Jul 1997 15:26:07 -0400 (EDT) From: David Battle Message-Id: <199707171926.PAA01738@seymour16.snmp.com> To: agentx@fv.com Subject: TestSet PDU's > Note that all VarBinds applicable to a given session must be > sent in a single agentx-TestSet-PDU. I don't like this restriction. I would like to be able to send separate TestSets for different VarBinds and have the subagent maintain state for all the TestSets with the same session and transaction ID. Forcing the master agent to attempt accumulate them all into one PDU makes it's job quite hairy. On the converse, it's pretty easy to have the subagent save them as it receives them and then free them all when it gets a CleanupSet or UndoSet. I agree that only one CommitSet, CleanupSet or UndoSet per transaction is the right thing. Plus, if we allow one or more TestSets per SNMP Set transaction, master agent implementers can implement it either way (either put them all in one TestSet or send separate TestSets). This would more closely match the relaxed rules for Get/GetNext/GetBulk processing which allow multiple AgentX Get pdu's per SNMP Get PDU. Comments? -David   Delivery-Date: Thu, 17 Jul 1997 18:18:13 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id SAA06393 for X-agentx; Thu, 17 Jul 1997 18:18:13 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id SAA06390 for ; Thu, 17 Jul 1997 18:18:12 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id SAA02383 for ; Thu, 17 Jul 1997 18:18:08 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id SAA19110 for ; Thu, 17 Jul 1997 18:17:36 -0700 (PDT) Received: from khitomer.epilogue.com(128.224.1.172) by gauntlet.fv.com via smap (3.2) id xma019006; Thu, 17 Jul 97 18:17:09 -0700 From: "Shawn A. Routhier" Sender: sar@khitomer.epilogue.com To: battle@snmp.com CC: agentx@fv.com, sar@epilogue.com In-reply-to: <199707171926.PAA01738@seymour16.snmp.com> (message from David Battle on Thu, 17 Jul 1997 15:26:07 -0400 (EDT)) Subject: Re: TestSet PDU's Date: Thu, 17 Jul 97 21:17:35 -0400 Message-ID: <9707172117.aa03380@khitomer.epilogue.com> 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, 17 Jul 1997 12:26:41 -0700 Date: Thu, 17 Jul 1997 15:26:07 -0400 (EDT) From: David Battle > Note that all VarBinds applicable to a given session must be > sent in a single agentx-TestSet-PDU. I don't like this restriction. I would like to be able to send separate TestSets for different VarBinds and have the subagent maintain state for all the TestSets with the same session and transaction ID. Forcing the master agent to attempt accumulate them all into one PDU makes it's job quite hairy. On the converse, it's pretty easy to have the subagent save them as it receives them and then free them all when it gets a CleanupSet or UndoSet. I find the opposite to be true. I also believe this was discussed at one of the IETF's and the consensus was that there should be a single test message. In your scheme how would the sub agent know that it has received all of the varbinds for a snmp request? Does it send a response to each testset? What does it test - each individual varbind by itself? when does it do group consistency checking? I agree that only one CommitSet, CleanupSet or UndoSet per transaction is the right thing. Plus, if we allow one or more TestSets per SNMP Set transaction, master agent implementers can implement it either way (either put them all in one TestSet or send separate TestSets). Sub agents would then need to be more complex to handle the dribble case and there was a distinct desire to keep the sub agents simple. This would more closely match the relaxed rules for Get/GetNext/GetBulk processing which allow multiple AgentX Get pdu's per SNMP Get PDU. Comments? -David Get/Next/Bulk processing doesn't have multiple phases and there aren't (possible) dependencies between the different varbinds. I think most sub agents will find it easier to get one packet for a test and do the checks on both individual varbinds and groups of varbinds rather than to wait for (possibly) multiple packets to arrive before being able to do group consistency checking. sar   Delivery-Date: Fri, 18 Jul 1997 11:09:06 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id LAA24495 for X-agentx; Fri, 18 Jul 1997 11:09:06 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id LAA24492 for ; Fri, 18 Jul 1997 11:09:05 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id LAA05793 for ; Fri, 18 Jul 1997 11:09:04 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id LAA00945 for ; Fri, 18 Jul 1997 11:08:28 -0700 (PDT) Received: from seymour16.snmp.com(192.147.142.16) by gauntlet.fv.com via smap (3.2) id xma000920; Fri, 18 Jul 97 11:08:06 -0700 Received: by seymour16.snmp.com (cf v2.9s-SNMP) id JAA27179; Fri, 18 Jul 1997 09:46:43 -0400 (EDT) Date: Fri, 18 Jul 1997 09:46:43 -0400 (EDT) From: David Battle Message-Id: <199707181346.JAA27179@seymour16.snmp.com> To: agentx@fv.com Subject: Re: TestSet PDU's > In your scheme how would the sub agent know that it > has received all of the varbinds for a snmp request? > a response to each testset? > What does it test - each individual varbind > by itself? when does it do group consistency checking? All I'm really asking for is that when a subagent gets a TestSet for a session and transaction that it already has saved, it: 1) appends the varbinds from the new TestSet to its saved copy of the old one. 2) Calls its testing and consistency checking again (just as if it had received all the varbinds in one pdu to begin with) and sends another reply. I don't think that asking too much, it is? Note that a master agent may choose to be efficient and put them all in one TestSet. In this case my "scheme" reduces to the current scheme and the only "wasted" complication in the subagent is the append operation (in my implementation that is about three line of code). Here is some pseudo code for how the two might differ in a typical subagent: Receive(buf); /* wait for a message from the master agent */ switch (buf.type) { /* ... */ case TestSet_type: TestSet = buf; if(!SavedTestSet) { SavedTestSet = TestSet; } + else if (SavedTestSet.transactionId == TestSet.transactionId && + SavedTestSet.sessionIdd == TestSet.sessionId)) { + Append TestSet to SavedTestSet; + } else { Error(); /* this error condition could happen anyway */ } if(TestAndConsistency(SavedTestSet) == GOOD) { SendGoodReply(); } else { SendBadReply(); } /* ... */ } The lines I marked with a + would have be added in my scheme. All other processing would be unchanged. In a good subagent implementation these lines would be in a library. -David   Delivery-Date: Fri, 18 Jul 1997 12:05:13 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id MAA29198 for X-agentx; Fri, 18 Jul 1997 12:05:13 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id MAA29193 for ; Fri, 18 Jul 1997 12:05:12 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id MAA10951 for ; Fri, 18 Jul 1997 12:05:09 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id MAA05714 for ; Fri, 18 Jul 1997 12:04:32 -0700 (PDT) Received: from mail12.digital.com(192.208.46.20) by gauntlet.fv.com via smap (3.2) id xma005682; Fri, 18 Jul 97 12:04:12 -0700 Received: from flume.zk3.dec.com (flume.zk3.dec.com [16.140.112.3]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id OAA17197; Fri, 18 Jul 1997 14:55:40 -0400 (EDT) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA09514; Fri, 18 Jul 1997 14:55:31 -0400 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA22926; Fri, 18 Jul 1997 14:51:27 -0400 Message-Id: <9707181851.AA22926@bernie.zk3.dec.com> To: David Battle Cc: agentx@fv.com Subject: Re: TestSet PDU's In-Reply-To: Your message of "Fri, 18 Jul 97 09:46:43 EDT." <199707181346.JAA27179@seymour16.snmp.com> Date: Fri, 18 Jul 97 14:51:27 -0400 From: Mike Daniele X-Mts: smtp Hi David, There was general agreement that the simplest and most efficient mechanism is sending all vb-s in a single pdu. Both sides know in a single request-response iteration what to do, if it passes the test phase, and how to advance state. Regards, Mike   Delivery-Date: Fri, 18 Jul 1997 12:21:27 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id MAA00561 for X-agentx; Fri, 18 Jul 1997 12:21:27 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id MAA00555 for ; Fri, 18 Jul 1997 12:21:12 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id MAA12845 for ; Fri, 18 Jul 1997 12:21:09 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id MAA07113 for ; Fri, 18 Jul 1997 12:20:33 -0700 (PDT) Received: from mail-gw.bmc.com(198.64.253.22) by gauntlet.fv.com via smap (3.2) id xma007079; Fri, 18 Jul 97 12:20:18 -0700 Received: (from uucp@localhost) by almond.bmc.com (8.8.6/8.8.6) id OAA24154 for ; Fri, 18 Jul 1997 14:20:45 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma024146; Fri, 18 Jul 97 14:20:19 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA07638 for ; Fri, 18 Jul 1997 14:20:27 -0500 (CDT) Received: from cherry.bmc.com(172.17.1.25) by dresden.bmc.com via smap (3.2) id xma007362; Fri, 18 Jul 97 14:20:10 -0500 Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by cherry.bmc.com with ESMTP (8.7.5/8.7.3) id OAA02827; Fri, 18 Jul 1997 14:20:00 -0500 (CDT) Received: by dorothy.peer.com (1.39.111.2/16.2) id AA096533600 for ; Fri, 18 Jul 1997 12:20:00 -0700 From: Smitha Gudur Message-Id: <199707181920.AA096533600@dorothy.peer.com> Subject: Re: TestSet PDU's To: agentx@fv.com Date: Fri, 18 Jul 1997 12:19:59 PDT Cc: battle@snmp.com, sgudur@peer.com In-Reply-To: <199707181346.JAA27179@seymour16.snmp.com>; from "David Battle" at Jul 18, 97 9:46 am X-Mailer: Elm [revision: 111.1] Doing one varbind at a time increases complexity and the number of transactions between MA and SA. The current draft has an efficient approach on this and avoids the above. Smitha > > > > In your scheme how would the sub agent know that it > > has received all of the varbinds for a snmp request? > > a response to each testset? > > What does it test - each individual varbind > > by itself? when does it do group consistency checking? > > All I'm really asking for is that when a subagent gets > a TestSet for a session and transaction that it already has saved, it: > > 1) appends the varbinds from the new TestSet to its saved copy of the old one. > 2) Calls its testing and consistency checking again (just as if it > had received all the varbinds in one pdu to begin with) and > sends another reply. > > I don't think that asking too much, it is? > > Note that a master agent may choose to be efficient and put them all in > one TestSet. In this case my "scheme" reduces to the current scheme > and the only "wasted" complication in the subagent is the append operation > (in my implementation that is about three line of code). > > > Here is some pseudo code for how the two might differ in a typical subagent: > > Receive(buf); /* wait for a message from the master agent */ > > switch (buf.type) { > /* ... */ > case TestSet_type: > TestSet = buf; > if(!SavedTestSet) { > SavedTestSet = TestSet; > } > + else if (SavedTestSet.transactionId == TestSet.transactionId && > + SavedTestSet.sessionIdd == TestSet.sessionId)) { > + Append TestSet to SavedTestSet; > + } > else { > Error(); /* this error condition could happen anyway */ > } > if(TestAndConsistency(SavedTestSet) == GOOD) { > SendGoodReply(); > } > else { > SendBadReply(); > } > /* ... */ > } > > > The lines I marked with a + would have be added in my scheme. All other > processing would be unchanged. In a good subagent implementation these > lines would be in a library. > > -David > > ---------------- > 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, 18 Jul 1997 13:29:26 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id NAA05932 for X-agentx; Fri, 18 Jul 1997 13:29:25 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id NAA05929 for ; Fri, 18 Jul 1997 13:29:25 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id NAA20068 for ; Fri, 18 Jul 1997 13:29:24 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id NAA12249 for ; Fri, 18 Jul 1997 13:28:47 -0700 (PDT) Received: from relay1.smtp.psi.net(38.8.14.2) by gauntlet.fv.com via smap (3.2) id xma012228; Fri, 18 Jul 97 13:28:25 -0700 Received: from nips.acec.com by relay1.smtp.psi.net (8.8.3/SMI-5.4-PSI) id QAA13984; Fri, 18 Jul 1997 16:28:33 -0400 (EDT) Received: from bnatale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA04312; Fri, 18 Jul 1997 16:29:27 -0400 Message-Id: <3.0.1.32.19970718163046.0093d250@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 18 Jul 1997 16:30:46 -0400 To: David Battle From: Bob Natale Subject: Re: TestSet PDU's Cc: agentx@fv.com In-Reply-To: <199707171926.PAA01738@seymour16.snmp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 03:26 PM 7/17/97 -0400, David Battle wrote: Hi David, >> Note that all VarBinds applicable to a given session must be >> sent in a single agentx-TestSet-PDU. > >I don't like this restriction. I would like to be able to send >separate TestSets for different VarBinds and have the subagent >maintain state for all the TestSets with the same session and >transaction ID. The motivation for this approach in AgentX is to simplify life for the sub-agent. >Forcing the master agent to attempt accumulate them all into >one PDU makes it's job quite hairy. The master already has to deal with the full varbindlist in the SNMP request and response anyway, so the adopted approach adds no complexity to its task. >On the converse, it's pretty easy to have the subagent save >them as it receives them and then free them all when it gets >a CleanupSet or UndoSet. I guess that's a debatable point. In any case, we took the approach of proactively trying to simplify things for sub- agent development, sometimes (and I don't think this is one of them) at the cost of putting complexity in the master agent. This is somewhat analogous to the traditional SNMP allocation of tasks. For the master agent, it's simply a matter of passing all (in the case of only a single target sub-agent for the request) or some sub-set of the varbinds in the varbindlist it received intact via the SNMP SetRequest-PDU... so it's hard (for me) to see any added complexity for the master agent here. >I agree that only one CommitSet, CleanupSet or UndoSet per >transaction is the right thing. Good. >Plus, if we allow one or more TestSets per SNMP Set >transaction, master agent implementers can implement it either way (either put them all in one TestSet or send >separate TestSets). True...but the design objective was to simplify for the sub-agent where possible...and giving him a look at the full dependancy-set for Sets was such a possibility. >This would more closely match the relaxed rules for >Get/GetNext/GetBulk processing which allow multiple >AgentX Get pdu's per SNMP Get PDU. The cases are very different due to the (possible) inter-depedencies among varbinds for Sets. >Comments? I sincerely believe this specific issue was fully discussed on the list during various phases of AgentX specification. We should now implement this as spec'd and report back any significant implementation or interoperability problems it presents. Cordially, BobN ----- ISO 9001 Registered Hardware and Software Divsions ---- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ---- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ---- ------ NetPlus (r) "FCAPS" Telemanagement Applications ------   Delivery-Date: Fri, 18 Jul 1997 14:19:39 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id OAA09858 for X-agentx; Fri, 18 Jul 1997 14:19:34 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id OAA09855 for ; Fri, 18 Jul 1997 14:19:34 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id OAA26747 for ; Fri, 18 Jul 1997 14:19:32 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id OAA17627 for ; Fri, 18 Jul 1997 14:18:55 -0700 (PDT) Received: from seymour16.snmp.com(192.147.142.16) by gauntlet.fv.com via smap (3.2) id xma017608; Fri, 18 Jul 97 14:18:26 -0700 Received: by seymour16.snmp.com (cf v2.9s-SNMP) id RAA09175; Fri, 18 Jul 1997 17:18:49 -0400 (EDT) Date: Fri, 18 Jul 1997 17:18:49 -0400 (EDT) From: David Battle Message-Id: <199707182118.RAA09175@seymour16.snmp.com> To: sgudur@peer.com Subject: Re: TestSet PDU's Cc: agentx@fv.com > Doing one varbind at a time increases complexity and the number of transactions I'm not saying require one varbind at a time. I'm just saying why not give the master agent the option of doing it either way? My point is it only adds at worst a few lines of code to the subagent to append the subsequent TestSet requests and then behave just as it normally would when receiving a TestSet. -David   Delivery-Date: Fri, 18 Jul 1997 14:23:04 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id OAA10239 for X-agentx; Fri, 18 Jul 1997 14:23:03 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id OAA10236 for ; Fri, 18 Jul 1997 14:23:03 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id OAA27127 for ; Fri, 18 Jul 1997 14:23:01 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id OAA17836 for ; Fri, 18 Jul 1997 14:22:25 -0700 (PDT) Received: from seymour16.snmp.com(192.147.142.16) by gauntlet.fv.com via smap (3.2) id xma017825; Fri, 18 Jul 97 14:22:12 -0700 Received: by seymour16.snmp.com (cf v2.9s-SNMP) id RAA10871; Fri, 18 Jul 1997 17:22:44 -0400 (EDT) Date: Fri, 18 Jul 1997 17:22:44 -0400 (EDT) From: David Battle Message-Id: <199707182122.RAA10871@seymour16.snmp.com> To: daniele@zk3.dec.com Subject: Re: TestSet PDU's Cc: agentx@fv.com > There was general agreement that the simplest and most efficient Perhaps it is the simplest if one is starting over from scratch with a master agent, but why not give us poor blokes with an installed base a break and let us do it either way :-)? -David   Delivery-Date: Fri, 18 Jul 1997 14:54:01 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id OAA12566 for X-agentx; Fri, 18 Jul 1997 14:54:00 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id OAA12563 for ; Fri, 18 Jul 1997 14:54:00 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id OAA01032 for ; Fri, 18 Jul 1997 14:53:59 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id OAA20209 for ; Fri, 18 Jul 1997 14:53:22 -0700 (PDT) Received: from relay1.smtp.psi.net(38.8.14.2) by gauntlet.fv.com via smap (3.2) id xma020190; Fri, 18 Jul 97 14:53:10 -0700 Received: from nips.acec.com by relay1.smtp.psi.net (8.8.3/SMI-5.4-PSI) id RAA03785; Fri, 18 Jul 1997 17:53:43 -0400 (EDT) Received: from bnatale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA05727; Fri, 18 Jul 1997 17:54:38 -0400 Message-Id: <3.0.1.32.19970718175558.0093d100@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 18 Jul 1997 17:55:58 -0400 To: David Battle From: Bob Natale Subject: Re: TestSet PDU's Cc: agentx@fv.com In-Reply-To: <199707182122.RAA10871@seymour16.snmp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 05:22 PM 7/18/97 -0400, David Battle wrote: Hi David, >> There was general agreement that the simplest and most efficient > >Perhaps it is the simplest if one is starting over from scratch >with a master agent, but why not give us poor blokes with an >installed base a break and let us do it either way :-)? Overall, AgentX does try to accommodate this important sentiment...after all, we definitely do want existing extensible agent developers to bring AgentX-based products to market. There were a number of discussions about this on this list and in the various f2f meetings and a number of AgentX features derived from this perspective. However, one over-riding goal is to simplify life for the sub-agent developers, since the proliferation of those is the both the raison d'etre and the sine qua non (huh?) of a successful IETF standard in this area. A good weekend to all! Cordially, BobN ----- ISO 9001 Registered Hardware and Software Divsions ---- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ---- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ---- ------ NetPlus (r) "FCAPS" Telemanagement Applications ------   Delivery-Date: Sat, 19 Jul 1997 09:41:23 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id JAA09237 for X-agentx; Sat, 19 Jul 1997 09:41:22 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id JAA09234 for ; Sat, 19 Jul 1997 09:41:22 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id JAA15253 for ; Sat, 19 Jul 1997 09:41:20 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id JAA28775 for ; Sat, 19 Jul 1997 09:40:45 -0700 (PDT) Received: from khitomer.epilogue.com(128.224.1.172) by gauntlet.fv.com via smap (3.2) id xma028771; Sat, 19 Jul 97 09:40:22 -0700 From: "Shawn A. Routhier" Sender: sar@khitomer.epilogue.com To: battle@snmp.com CC: sgudur@peer.com, agentx@fv.com In-reply-to: <199707182118.RAA09175@seymour16.snmp.com> (message from David Battle on Fri, 18 Jul 1997 17:18:49 -0400 (EDT)) Subject: Re: TestSet PDU's Date: Sat, 19 Jul 97 12:40:57 -0400 Message-ID: <9707191240.aa10019@khitomer.epilogue.com> 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, 18 Jul 1997 14:19:39 -0700 Date: Fri, 18 Jul 1997 17:18:49 -0400 (EDT) From: David Battle Cc: agentx@fv.com > Doing one varbind at a time increases complexity and the number of > transactions I'm not saying require one varbind at a time. I'm just saying why not give the master agent the option of doing it either way? My point is it only adds at worst a few lines of code to the subagent to append the subsequent TestSet requests and then behave just as it normally would when receiving a TestSet. -David I don't agree that it would only add "at worst a few lines of code in the subagent". Depending on the model the sub agent uses it may be much more pervasive. For example if, as part of the test phase, the method routines acquire the memory and actually build a new row. Then when the second test request arrives the sub agent must either throw that row away (via the cleanup routines) which sounds pretty inefficient or the method routines must understand that they may be called multiple times before a cleanup or set request occurs and behave accordingly. You are also dictating more of the internal implementation. I believe that a currently externally compliant sub agent could discard the test request after determining that it had failed and then process the cleanup as if it hadn't. In your scheme the sub agent can't discard the test request early because other tests may arrive that will change the failure into success. sar   Delivery-Date: Sat, 19 Jul 1997 09:56:22 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id JAA10279 for X-agentx; Sat, 19 Jul 1997 09:56:22 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id JAA10276 for ; Sat, 19 Jul 1997 09:56:21 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id JAA15981 for ; Sat, 19 Jul 1997 09:56:20 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id JAA29189 for ; Sat, 19 Jul 1997 09:55:45 -0700 (PDT) Received: from khitomer.epilogue.com(128.224.1.172) by gauntlet.fv.com via smap (3.2) id xma029169; Sat, 19 Jul 97 09:55:29 -0700 From: "Shawn A. Routhier" Sender: sar@khitomer.epilogue.com To: daniele@zk3.dec.com CC: agentx@fv.com In-reply-to: <9707161939.AA20704@bernie.zk3.dec.com> (message from Mike Daniele on Wed, 16 Jul 97 15:39:22 -0400) Subject: Re: Questions about the AgentX protocol Date: Sat, 19 Jul 97 12:55:58 -0400 Message-ID: <9707191255.aa10049@khitomer.epilogue.com> 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: Wed, 16 Jul 1997 12:56:29 -0700 Cc: agentx@fv.com Date: Wed, 16 Jul 97 15:39:22 -0400 From: Mike Daniele X-Suppressed-X-Mts: smtp Hi Shawn, Sorry for the delay in answering. >1) What should a master agent do if, while processing a snmp >request it receives an agentx administrative request? I think that's best left up to the implementation, and probably differs as well depending on which PDU is received. I think that leaving this up to the implementation is the least attractive option. Generic master agents will need to implement code to handle this case but generic sub agents will not be able to take advantage of that code because they can't be sure that their master agent handles this case. sar   Delivery-Date: Sat, 19 Jul 1997 10:14:23 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id KAA11734 for X-agentx; Sat, 19 Jul 1997 10:14:22 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id KAA11731 for ; Sat, 19 Jul 1997 10:14:22 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id KAA16941 for ; Sat, 19 Jul 1997 10:14:21 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id KAA29557 for ; Sat, 19 Jul 1997 10:13:46 -0700 (PDT) Received: from khitomer.epilogue.com(128.224.1.172) by gauntlet.fv.com via smap (3.2) id xma029550; Sat, 19 Jul 97 10:13:41 -0700 From: "Shawn A. Routhier" Sender: sar@khitomer.epilogue.com To: agentx@fv.com cc: sar@epilogue.com Subject: Elements of Procedure: Open PDU Date: Sat, 19 Jul 97 13:14:11 -0400 Message-ID: <9707191314.aa10111@khitomer.epilogue.com> In section 7.1.1 step 1 has the master agent setting the sysuptime to the value of sysuptime for the indicated context. a) As the open request doesn't require any specific context wouldn't it make more sense to have it ignore the context info and return the sysuptime value for the default context? b) If we do want it to return the sysuptime for the indicated context what should happen if the indicated context doesn't exist? This case isn't handled in the current procedures. One option would be to add a clause rejecting the request with an unsupported context error, another would be to specify that the open failed error means that the sysuptime isn't valid. sar   Delivery-Date: Sat, 19 Jul 1997 10:28:22 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id KAA12832 for X-agentx; Sat, 19 Jul 1997 10:28:22 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id KAA12829 for ; Sat, 19 Jul 1997 10:28:21 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id KAA17710 for ; Sat, 19 Jul 1997 10:28:20 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id KAA29799 for ; Sat, 19 Jul 1997 10:27:45 -0700 (PDT) Received: from khitomer.epilogue.com(128.224.1.172) by gauntlet.fv.com via smap (3.2) id xma029795; Sat, 19 Jul 97 10:27:32 -0700 From: "Shawn A. Routhier" Sender: sar@khitomer.epilogue.com To: agentx@fv.com cc: sar@epilogue.com Subject: Elements of procedure: Registration Date: Sat, 19 Jul 97 13:28:08 -0400 Message-ID: <9707191328.aa10156@khitomer.epilogue.com> In section 7.1.5 there does not seem to be any way to reject registrations that the master agent either can't or doesn't want to perform. The master agent might not be able to register an object due to some resource constraints (such as out of memory). It might not want to register an object because it is handling that object itself (for example the system group, or the snmp group). The master agent would seem to have the options of claiming that a duplicate registration had occurred or (from section 7) that a protocol error had occurred. Neither of these seem either appropriate or useful. One solution would be to add more error codes (or use some, such as resource unavailable, from snmpv2) and to update the elements of procedure accordingly. The procedures for other admin requests (add agent caps, index allocate) would probably need to be updated as well. sar   Delivery-Date: Sat, 19 Jul 1997 10:34:51 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id KAA13386 for X-agentx; Sat, 19 Jul 1997 10:34:51 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id KAA13383 for ; Sat, 19 Jul 1997 10:34:50 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id KAA18095 for ; Sat, 19 Jul 1997 10:34:49 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id KAA29935 for ; Sat, 19 Jul 1997 10:34:15 -0700 (PDT) Received: from khitomer.epilogue.com(128.224.1.172) by gauntlet.fv.com via smap (3.2) id xma029921; Sat, 19 Jul 97 10:33:48 -0700 From: "Shawn A. Routhier" Sender: sar@khitomer.epilogue.com To: agentx@fv.com cc: sar@epilogue.com Subject: Elements of Procedure: Close Date: Sat, 19 Jul 97 13:34:24 -0400 Message-ID: <9707191334.aa10194@khitomer.epilogue.com> In section 7.1.9 step 2 a response is sent if there wasn't a session to be closed, otherwise no response is sent. I don't see any real utility to the error response, can somebody point out a use for it? Absent some major use for the reponse I suggest that it be removed so that the expectations for a close are consistent. In this way neither the sub or master agents need to have special case code to handle the error response. sar   Delivery-Date: Sat, 19 Jul 1997 10:43:52 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id KAA14130 for X-agentx; Sat, 19 Jul 1997 10:43:52 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id KAA14127 for ; Sat, 19 Jul 1997 10:43:52 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id KAA18631 for ; Sat, 19 Jul 1997 10:43:50 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id KAA00311 for ; Sat, 19 Jul 1997 10:43:15 -0700 (PDT) Received: from khitomer.epilogue.com(128.224.1.172) by gauntlet.fv.com via smap (3.2) id xma000303; Sat, 19 Jul 97 10:42:58 -0700 From: "Shawn A. Routhier" Sender: sar@khitomer.epilogue.com To: agentx@fv.com cc: sar@epilogue.com Subject: Elements of Procedure: Notify Date: Sat, 19 Jul 97 13:43:33 -0400 Message-ID: <9707191343.aa10207@khitomer.epilogue.com> In section 7.1.11 there is no discussion of context information. This makes the notify operation different from most of the admin messages, the exceptions are the open and close messages which are of a different type then the other admin messages. I think that the notify should have the same context checking as the other admin messages. I would also prefer that a reponse message be sent on success as well as failure. This would make processing of most of the admin messages more consistent both on the master and the sub. Note that a success message would only indicate that the master agent had received the notify request and found it acceptable from an agentx perspective, NOT that the master agent had done anything with the message. sar   Delivery-Date: Sat, 19 Jul 1997 22:52:17 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id WAA10022 for X-agentx; Sat, 19 Jul 1997 22:52:17 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id WAA10019 for ; Sat, 19 Jul 1997 22:52:16 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id WAA26493 for ; Sat, 19 Jul 1997 22:52:13 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id WAA16167 for ; Sat, 19 Jul 1997 22:51:38 -0700 (PDT) Received: from seymour16.snmp.com(192.147.142.16) by gauntlet.fv.com via smap (3.2) id xma016148; Sat, 19 Jul 97 22:51:20 -0700 Received: by seymour16.snmp.com (cf v2.9s-SNMP) id BAA17712; Sun, 20 Jul 1997 01:51:56 -0400 (EDT) Date: Sun, 20 Jul 1997 01:51:56 -0400 (EDT) From: David Battle Message-Id: <199707200551.BAA17712@seymour16.snmp.com> To: agentx@fv.com Subject: res.error In a response to a get-pdu, should res.error echo the error code in a failed varbind? Should the error index be set to point to the first such varbind? Or should error and index be 0 and rely on the master agent finding the failed varbind? Is this specified in the draft somewhere and I'm just missing it (it is quite late). -David   Delivery-Date: Mon, 21 Jul 1997 11:31:51 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id LAA00326 for X-agentx; Mon, 21 Jul 1997 11:31:51 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id LAA00323 for ; Mon, 21 Jul 1997 11:31:46 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id LAA10676 for ; Mon, 21 Jul 1997 11:31:42 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id LAA11836 for ; Mon, 21 Jul 1997 11:30:59 -0700 (PDT) Received: from seymour16.snmp.com(192.147.142.16) by gauntlet.fv.com via smap (3.2) id xma011749; Mon, 21 Jul 97 11:30:27 -0700 Received: by seymour16.snmp.com (cf v2.9s-SNMP) id OAA28608; Mon, 21 Jul 1997 14:31:02 -0400 (EDT) Date: Mon, 21 Jul 1997 14:31:02 -0400 (EDT) From: David Battle Message-Id: <199707211831.OAA28608@seymour16.snmp.com> To: thatcher@rahul.net Subject: Re: TestSet PDU's Cc: agentx@fv.com > an error on the "first" varbind and then MA would return that error as the > response to the set. Yes, a master agent that did this sort of thing would have to be smart enough to ignore "early failures", but that burden would be on the master agent which chose this path, not on master agents which did it the "normal" way and not on subagents. I'm still not convinced that allowing multiple TestSets for the same transaction adds any burden to the subagent. One person pointed out that it made things more complex because the subagent author would have to make sure that their test methods could be called "multiple times". But they have to be able to anyway, because you might get a TestSet, a cleanup, and then another TestSet with an amazingly similar varbindlist. So, my suggested procedure for handling the case where a subagent receives multpile TestSets with the same transactionID becomes: 1) Append the new varbind(s) to the saved TestSet and save a copy 2) behave as if a cleanup had been received for the transaction 3) Behave as if you had just received the saved copy from 1). -David   Delivery-Date: Wed, 23 Jul 1997 09:12:52 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id JAA05197 for X-agentx; Wed, 23 Jul 1997 09:12:51 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id JAA05193 for ; Wed, 23 Jul 1997 09:12:50 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id JAA04318 for ; Wed, 23 Jul 1997 09:12:48 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id JAA27988 for ; Wed, 23 Jul 1997 09:12:02 -0700 (PDT) Received: from seymour16.snmp.com(192.147.142.16) by gauntlet.fv.com via smap (3.2) id xma027916; Wed, 23 Jul 97 09:11:38 -0700 Received: by seymour16.snmp.com (cf v2.9s-SNMP) id MAA22748; Wed, 23 Jul 1997 12:12:16 -0400 (EDT) Date: Wed, 23 Jul 1997 12:12:16 -0400 (EDT) From: David Battle Message-Id: <199707231612.MAA22748@seymour16.snmp.com> To: agentx@fv.com Subject: transaction > b) When processing an SNMP Set request, the master agent > must send all of the VarBinds applicable to a particular > subagent session in a single Test/Set transaction. ^^^^^^^^^^^ Shouldn't it be "packet" instead of "transaction" since we use the term transaction to refer to the duration of a single SNMP management request? -David   Delivery-Date: Wed, 23 Jul 1997 09:21:53 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id JAA05964 for X-agentx; Wed, 23 Jul 1997 09:21:52 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id JAA05961 for ; Wed, 23 Jul 1997 09:21:52 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id JAA05370 for ; Wed, 23 Jul 1997 09:21:48 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id JAA29145 for ; Wed, 23 Jul 1997 09:21:03 -0700 (PDT) Received: from seymour16.snmp.com(192.147.142.16) by gauntlet.fv.com via smap (3.2) id xma029098; Wed, 23 Jul 97 09:20:43 -0700 Received: by seymour16.snmp.com (cf v2.9s-SNMP) id MAA23583; Wed, 23 Jul 1997 12:21:28 -0400 (EDT) Date: Wed, 23 Jul 1997 12:21:28 -0400 (EDT) From: David Battle Message-Id: <199707231621.MAA23583@seymour16.snmp.com> To: agentx@fv.com Subject: reply to testset Am I correct in assuming that there is no varbind list in the response to a TestSet pdu? Thanks, -David   Delivery-Date: Wed, 23 Jul 1997 10:12:39 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id KAA10014 for X-agentx; Wed, 23 Jul 1997 10:12:38 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id KAA10011 for ; Wed, 23 Jul 1997 10:12:38 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id KAA11493 for ; Wed, 23 Jul 1997 10:12:35 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id KAA04533 for ; Wed, 23 Jul 1997 10:11:50 -0700 (PDT) Received: from seymour16.snmp.com(192.147.142.16) by gauntlet.fv.com via smap (3.2) id xma004511; Wed, 23 Jul 97 10:11:32 -0700 Received: by seymour16.snmp.com (cf v2.9s-SNMP) id NAA02986; Wed, 23 Jul 1997 13:12:16 -0400 (EDT) Date: Wed, 23 Jul 1997 13:12:16 -0400 (EDT) From: David Battle Message-Id: <199707231712.NAA02986@seymour16.snmp.com> To: agentx@fv.com Subject: TestSets Should subagents be able to handle multiple outstanding TestSet's at once? I suppose they could distinguish them by transactionID. Is that was is intended? The draft refers to "previous TestSet-PDU". If multiple outstanding sets are supposed to be handled, perhaps it should say "most recent TestSet-PDU with the same sessionID and transactionID" somewhere. -David   Delivery-Date: Wed, 23 Jul 1997 11:45:56 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id LAA17525 for X-agentx; Wed, 23 Jul 1997 11:45:56 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id LAA17522 for ; Wed, 23 Jul 1997 11:45:54 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id LAA22810 for ; Wed, 23 Jul 1997 11:45:51 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id LAA11360 for ; Wed, 23 Jul 1997 11:45:07 -0700 (PDT) Received: from khitomer.epilogue.com(128.224.1.172) by gauntlet.fv.com via smap (3.2) id xma011328; Wed, 23 Jul 97 11:44:57 -0700 From: "Shawn A. Routhier" Sender: sar@khitomer.epilogue.com To: battle@snmp.com CC: agentx@fv.com In-reply-to: <199707231712.NAA02986@seymour16.snmp.com> (message from David Battle on Wed, 23 Jul 1997 13:12:16 -0400 (EDT)) Subject: Re: TestSets Date: Wed, 23 Jul 97 14:45:37 -0400 Message-ID: <9707231445.aa27678@khitomer.epilogue.com> 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: Wed, 23 Jul 1997 10:12:39 -0700 Date: Wed, 23 Jul 1997 13:12:16 -0400 (EDT) From: David Battle Should subagents be able to handle multiple outstanding TestSet's at once? I don't think the protocol should either prohibit or require handling multiple outstanding TestSet's in parallel. I suppose they could distinguish them by transactionID. Is that was is intended? The draft refers to "previous TestSet-PDU". If multiple outstanding sets are supposed to be handled, perhaps it should say "most recent TestSet-PDU with the same sessionID and transactionID" somewhere. -David   Delivery-Date: Wed, 23 Jul 1997 12:50:02 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id MAA22541 for X-agentx; Wed, 23 Jul 1997 12:50:01 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id MAA22519 for ; Wed, 23 Jul 1997 12:50:00 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id MAA29062 for ; Wed, 23 Jul 1997 12:49:57 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id MAA16097 for ; Wed, 23 Jul 1997 12:49:13 -0700 (PDT) Received: from seymour16.snmp.com(192.147.142.16) by gauntlet.fv.com via smap (3.2) id xma016084; Wed, 23 Jul 97 12:48:50 -0700 Received: by seymour16.snmp.com (cf v2.9s-SNMP) id PAA17094; Wed, 23 Jul 1997 15:49:21 -0400 (EDT) Date: Wed, 23 Jul 1997 15:49:21 -0400 (EDT) From: David Battle Message-Id: <199707231949.PAA17094@seymour16.snmp.com> To: sar@epilogue.com Subject: Re: TestSets Cc: agentx@fv.com > I don't think the protocol should either prohibit or require handling > multiple outstanding TestSet's in parallel. Hmmm. Well, how do you envision interoperability happening if, for example, I write a master agent which expects subagents to handle multiple outstanding TestSets and you write a subagent which doesn't? How will the master agent know that he may need to "try again later" when he gets GenError from the second TestSet? It seems like we at least need a new error code for this which the subagent may use if it decides not to handle a second TestSet with a different transactionID. I suppose we could use resourceUnavailable for this, but that's not exactly right either. -David   Delivery-Date: Wed, 23 Jul 1997 13:25:40 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id NAA25463 for X-agentx; Wed, 23 Jul 1997 13:25:39 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id NAA25460 for ; Wed, 23 Jul 1997 13:25:39 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id NAA02540 for ; Wed, 23 Jul 1997 13:25:35 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id NAA18198 for ; Wed, 23 Jul 1997 13:24:50 -0700 (PDT) Received: from khitomer.epilogue.com(128.224.1.172) by gauntlet.fv.com via smap (3.2) id xma018177; Wed, 23 Jul 97 13:24:20 -0700 From: "Shawn A. Routhier" Sender: sar@khitomer.epilogue.com To: battle@snmp.com CC: agentx@fv.com In-reply-to: <199707231949.PAA17094@seymour16.snmp.com> (message from David Battle on Wed, 23 Jul 1997 15:49:21 -0400 (EDT)) Subject: Re: TestSets Date: Wed, 23 Jul 97 16:25:04 -0400 Message-ID: <9707231625.aa12697@khitomer.epilogue.com> Date: Wed, 23 Jul 1997 15:49:21 -0400 (EDT) From: David Battle Cc: agentx@fv.com > I don't think the protocol should either prohibit or require handling > multiple outstanding TestSet's in parallel. Hmmm. Well, how do you envision interoperability happening if, for example, I write a master agent which expects subagents to handle multiple outstanding TestSets and you write a subagent which doesn't? How will the master agent know that he may need to "try again later" when he gets GenError from the second TestSet? It seems like we at least need a new error code for this which the subagent may use if it decides not to handle a second TestSet with a different transactionID. I suppose we could use resourceUnavailable for this, but that's not exactly right either. -David As I see it the sub agent has three options 1) process TestSets in parallel. That is work on multiple TestSets at the same time, perhaps on multiple processors. 2) handle multiple TestSets at a time but process them in a serial fashion. That is queue up the second and later TestSets and process them after the first TestSet and other phases of the Set have finished. 3) only handle one TestSet at a time. the second TestSet would be rejected with some sort of error. I was thinking of options 1 & 2 in my message. I don't think the master agent can distinguish between those two. I think option 3 is analagous to a monolithic agent sending back an error to the manager for the same case. We can specify another error which would allow the optimization of the master agent trying again, or we can decide on a current error (resoruceUnavailable would probably be the closest) and let the manager sort it out. I don't see an overriding reason to specify another error but adding one wouldn't bother me. sar   Delivery-Date: Fri, 25 Jul 1997 17:12:04 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id RAA26516 for X-agentx; Fri, 25 Jul 1997 17:12:03 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id RAA26479 for ; Fri, 25 Jul 1997 17:12:02 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id RAA18878 for ; Fri, 25 Jul 1997 17:11:58 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id RAA08774 for ; Fri, 25 Jul 1997 17:11:06 -0700 (PDT) Received: from card.com(208.145.163.11) by gauntlet.fv.com via smap (3.2) id xmag08577; Fri, 25 Jul 97 17:10:37 -0700 Received: from seymour16.snmp.com (seymour16.snmp.com [192.147.142.16]) by card.com (8.8.5/8.8.5) with ESMTP id GAA18005 for ; Fri, 25 Jul 1997 06:07:55 -0700 (PDT) Received: by seymour16.snmp.com (cf v2.9s-SNMP) id JAA09343; Fri, 25 Jul 1997 09:05:26 -0400 (EDT) Date: Fri, 25 Jul 1997 09:05:26 -0400 (EDT) From: David Battle Message-Id: <199707251305.JAA09343@seymour16.snmp.com> To: agentx@fv.com Subject: 7.3.1 Set Transaction States I would like to make a minor modification to the set transaction states. I notice that subagents have no specified action when they receive a cleanup while in state E Commit Fail. At first I was confused by this, but after reading section 7.2.4.5 Processing of Responses to agentx-CommitSet-PDUs I see that the subagent is able to "reason" that it can't possibly be sent a cleanup. I think that subagents should accept a cleanup at any time to terminate a set transaction so that the master agent doesn't necessarily have to track the state machine of each subagent to know whether it will accept a cleanup to end the transaction. Thoughts? -David   Delivery-Date: Fri, 25 Jul 1997 17:12:04 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id RAA26517 for X-agentx; Fri, 25 Jul 1997 17:12:04 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id RAA26493 for ; Fri, 25 Jul 1997 17:12:02 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id RAA18884 for ; Fri, 25 Jul 1997 17:11:58 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id RAA08775 for ; Fri, 25 Jul 1997 17:11:06 -0700 (PDT) Received: from card.com(208.145.163.11) by gauntlet.fv.com via smap (3.2) id xmah08577; Fri, 25 Jul 97 17:10:37 -0700 Received: from seymour16.snmp.com (seymour16.snmp.com [192.147.142.16]) by card.com (8.8.5/8.8.5) with ESMTP id FAA15313 for ; Fri, 25 Jul 1997 05:50:32 -0700 (PDT) Received: by seymour16.snmp.com (cf v2.9s-SNMP) id IAA08405; Fri, 25 Jul 1997 08:47:51 -0400 (EDT) Date: Fri, 25 Jul 1997 08:47:51 -0400 (EDT) From: David Battle Message-Id: <199707251247.IAA08405@seymour16.snmp.com> To: agentx@fv.com Subject: cleanup, response or no I think we have a minor inconsistency here: A conformant AgentX subagent must support the agentx-TestSet, -CommitSet, -UndoSet, and -CleanupSet PDUs, and must support multiple ^^^^^^^^^ variables being supplied in each PDU. These four PDUs are used to collectively perform the indicated ^^^^ management operation. An agentx-Response-PDU is sent in reply to ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ each of the PDUs, to inform the master agent of the state of the ^^^^^^^^^^^^^^^^ operation. ... 2 pages later when talking about cleanup: No response is sent by the subagent.   Delivery-Date: Mon, 28 Jul 1997 09:32:59 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id JAA26948 for X-agentx; Mon, 28 Jul 1997 09:32:58 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id JAA26945 for ; Mon, 28 Jul 1997 09:32:56 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id JAA05777 for ; Mon, 28 Jul 1997 09:32:55 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id JAA06992 for ; Mon, 28 Jul 1997 09:31:56 -0700 (PDT) Received: from seymour16.snmp.com(192.147.142.16) by gauntlet.fv.com via smap (3.2) id xma006960; Mon, 28 Jul 97 09:31:39 -0700 Received: by seymour16.snmp.com (cf v2.9s-SNMP) id MAA12021; Mon, 28 Jul 1997 12:32:13 -0400 (EDT) Date: Mon, 28 Jul 1997 12:32:13 -0400 (EDT) From: David Battle Message-Id: <199707281632.MAA12021@seymour16.snmp.com> To: agentx@fv.com Subject: interoperability testing If anyone is interested in doing some preliminary interoperability testing, please email me. Thanks, -David   Delivery-Date: Tue, 29 Jul 1997 14:49:58 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id OAA15733 for X-agentx; Tue, 29 Jul 1997 14:49:58 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id OAA15730 for ; Tue, 29 Jul 1997 14:49:57 -0700 (PDT) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id OAA20944 for ; Tue, 29 Jul 1997 14:49:50 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id OAA17494 for ; Tue, 29 Jul 1997 14:48:51 -0700 (PDT) Received: from mail-gw.bmc.com(198.64.253.22) by gauntlet.fv.com via smap (3.2) id xma017471; Tue, 29 Jul 97 14:48:29 -0700 Received: (from uucp@localhost) by almond.bmc.com (8.8.6/8.8.6) id QAA27367 for ; Tue, 29 Jul 1997 16:49:27 -0500 (CDT) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma027363; Tue, 29 Jul 97 16:49:24 -0500 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id QAA10011 for ; Tue, 29 Jul 1997 16:49:31 -0500 (CDT) Received: from cherry.bmc.com(172.17.1.25) by dresden.bmc.com via smap (3.2) id xma010000; Tue, 29 Jul 97 16:49:28 -0500 Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by cherry.bmc.com with ESMTP (8.7.5/8.7.3) id QAA26888; Tue, 29 Jul 1997 16:49:15 -0500 (CDT) Received: by dorothy.peer.com (1.39.111.2/16.2) id AA256972954 for ; Tue, 29 Jul 1997 14:49:14 -0700 From: Smitha Gudur Message-Id: <199707292149.AA256972954@dorothy.peer.com> Subject: Re: 7.3.1 Set Transaction States To: battle@snmp.com Date: Tue, 29 Jul 1997 14:49:13 PDT Cc: agentx@fv.com, sgudur@peer.com In-Reply-To: <199707251305.JAA09343@seymour16.snmp.com>; from "David Battle" at Jul 25, 97 9:05 am X-Mailer: Elm [revision: 111.1] David, We share similar experience in this matter. We find it more useful to keep track of state of the transaction, instead of using subagent states. subagents should be in position to accept cleanup at any time. Smitha > > > I would like to make a minor modification to the set transaction states. > > I notice that subagents have no specified action when they receive a cleanup > while in state E Commit Fail. At first I was confused by this, but after > reading section 7.2.4.5 Processing of Responses to agentx-CommitSet-PDUs I > see that the subagent is able to "reason" that it can't possibly be sent a > cleanup. > > I think that subagents should accept a cleanup at any time to terminate > a set transaction so that the master agent doesn't necessarily have to track > the state machine of each subagent to know whether it will accept a cleanup to > end the transaction. > > Thoughts? > > -David > > ---------------- > 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, 31 Jul 1997 22:02:28 -0700 Return-Path: Received: (from daemon@localhost) by fv.com (8.8.5/8.8.5) id WAA06122 for X-agentx; Thu, 31 Jul 1997 22:02:27 -0700 (PDT) Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by fv.com (8.8.5/8.8.5) with ESMTP id WAA06119 for ; Thu, 31 Jul 1997 22:02:26 -0700 (PDT) From: invite@onlinenow.net Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id WAA19459 for ; Thu, 31 Jul 1997 22:02:23 -0700 (PDT) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id WAA19550 for ; Thu, 31 Jul 1997 22:01:18 -0700 (PDT) Received: from unknown(206.96.72.164) by gauntlet.fv.com via smap (3.2) id xma019545; Thu, 31 Jul 97 22:01:08 -0700 Received: from onlinenow.net (brain2.now.net [206.96.72.165]) by brain.now.net (8.8.6/8.7.3) with SMTP id XAA31358 for ; Thu, 31 Jul 1997 23:04:27 -0700 Date: Thu, 31 Jul 1997 23:04:27 -0700 Message-Id: <199708010604.XAA31358@brain.now.net> To: agentx@fv.com Subject: Free Link for your Web Site ! OnLineNow recently visited your site and in recognition of it's quality and uniqueness, we wanted to personally invite you to "Add Your Link, Free" to OnLineNow World Wide Directories. Just go to: http://onlinenow.net/intro/html/add_your_link.htm Fill out the form, selecting the category and city or country you would like your link in, and then submit it. Your link will be added right then and there. If you do not have a web page or you feel you recieved this invitation by mistake, then your address was probably given to us as a referral on our Guest Registration Page. You can however create yourself a Free Web Page with OnlineNow. In appreciation of a free Net! OnLineNow World Wide http://onlinenow.net