From owner-agentx@dorothy.bmc.com Thu Jul 12 18:32:38 2001 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05557 for ; Thu, 12 Jul 2001 18:32:38 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id f6CMXXs18037; Thu, 12 Jul 2001 17:33:33 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA13045 for agentx-list; Thu, 12 Jul 2001 15:26:06 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA13040 for ; Thu, 12 Jul 2001 15:26:03 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id f6CMQPr22894 for ; Thu, 12 Jul 2001 17:26:25 -0500 (CDT) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id CED1E1FF010 for ; Thu, 12 Jul 2001 22:22:15 -0500 (CDT) Received: from auemail1.firewall.lucent.com (localhost [127.0.0.1]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6CMQx004324 for ; Thu, 12 Jul 2001 18:26:59 -0400 (EDT) Received: from md6370exch001p.wins.lucent.com (h135-114-206-50.lucent.com [135.114.206.50]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6CMQwF04320 for ; Thu, 12 Jul 2001 18:26:58 -0400 (EDT) Received: by md6370exch001p.nse.lucent.com with Internet Mail Service (5.5.2650.21) id <3XWZN1W5>; Thu, 12 Jul 2001 18:26:58 -0400 Message-ID: From: "Natale, Robert C (Bob)" To: AgentX@dorothy.bmc.com Subject: AgentX issue resolution request Date: Thu, 12 Jul 2001 18:26:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Hi everyone, Note that the non-anonymous implementation reports and the open issues list mentioned below can be accessed at: http://www.scguild.com/agentx/ [Thanks as always to Dave Keeney for doing an out-standing job on the AgentX web site, despite the fact that the WG Chair has not done enough to encourage the WG to make full use of the resource.] 1. The comments contained in the implementation reports (including the three anonymous ones) did not indicate any required changes in the documents (to the best of my interpretation and recollection now...submitters are free (and encouraged) to indicate otherwise if I've got that wrong on the e-mail list or to me privately asap). 2. There are some open issues noted on the web site (toward the bottom of the page)...please take a look at them and post any thoughts you might have about them asap. We'll try to reach closure on them by the middle of next week. 3. Anyone who cares to post an interoperability report concerning experience with AgentX components (Master Agent, Sub-Agent, and/or Toolkit) from two or more implementations and/or any deployment experience with any one or more is invited and encouraged to do so asap. While I think we have enough material in the implementation reports for the purpose of recommending the advancement of the AgentX protocol and MIB RFCs to Draft Standard status, more input is welcomed. As I am sure it has been for most of you, work has really been a bear in recent months -- exacerbated beyond the normal high level by the turmoil in the telecom industry -- and "spare time" has been scarcer than ever. My plan is to try to wrap up the formal WG recommendation to the IESG by the middle of next week and hand it off to our ADs for review and processing. Again, your input is invited and encouraged on any of the above, or anything else relevant to the WG...post away! Cordially, BobN AgentX WG Chair From owner-agentx@dorothy.bmc.com Wed Jul 18 03:18:57 2001 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20737 for ; Wed, 18 Jul 2001 03:18:56 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id f6I7JoB24787; Wed, 18 Jul 2001 02:19:50 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id AAA24836 for agentx-list; Wed, 18 Jul 2001 00:17:21 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id AAA24816 for agentx@dorothy.bmc.com; Wed, 18 Jul 2001 00:17:16 -0700 (PDT) Date: Wed, 18 Jul 2001 00:17:16 -0700 (PDT) From: Randy Presuhn Message-Id: <200107180717.AAA24816@dorothy.bmc.com> To: agentx@dorothy.bmc.com Subject: Fwd: message from Randy Bush Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list X-MIME-Autoconverted: from 8bit to quoted-printable by babbler.bmc.com id f6I7JoB24787 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA20737 Hi - I'm forwarding a message from Randy Bush. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ > Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA12929; > Tue, 17 Jul 2001 10:25:02 -0700 (PDT) > Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) > by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id f6HHPNg20201; > Tue, 17 Jul 2001 12:25:23 -0500 (CDT) > Received: from roam.psg.com (unknown [135.207.10.122]) > by mx-us-hou-1-int.bmc.com (Postfix) with SMTP > id 1FA2D20EFEE; Tue, 17 Jul 2001 17:19:55 -0500 (CDT) > Received: from randy by roam.psg.com with local (Exim 3.30 #1) > id 15MYb7-0000LK-00; Tue, 17 Jul 2001 13:25:25 -0400 > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > Rsent-To: eos@ops.ietf.org > Approved: snmp > From: The IESG > To: AAA Working Group , > ACAP Working Group , > ADSLMIB Working Group , > AFT Working Group , > AGENTX Working Group , > APEX Working Group , > ATOMMIB Working Group , > AVT Working Group , > BEEP Working Group , > BGMP Working Group , > BMWG Working Group , > BRIDGE Working Group , > CALSCH Working Group , > CAT Working Group , > CCAMP Working Group , > CNRP Working Group , > DELTAV Working Group , > DHC Working Group , > DIFFSERV Working Group , > DISMAN Working Group , > DNSEXT Working Group , > DNSOP Working Group , > ECM Working Group , > EDIINT Working Group , > ENTMIB Working Group , > ENUM Working Group , > EOS Working Group , > FAX Working Group , > FRNETMIB Working Group , > FTPEXT Working Group , > GEOPRIV Working Group , > GRIP Working Group , > GSMP Working Group , > HUBMIB Working Group , > IDMR Working Group , > IDN Working Group , > IDR Working Group , > IDWG Working Group , > IFMIB Working Group , > IMAPEXT Working Group , > IMPP Working Group , > IPCDN Working Group , > IPFC Working Group , > IPNGWG Working Group , > IPO Working Group , > IPORPR Working Group , > IPP Working Group , > IPPM Working Group , > IPS Working Group , > IPSEC Working Group , > IPSP Working Group , > IPSRA Working Group , > IPTEL Working Group , > ISIS Working Group , > ISSLL Working Group , > ITRACE Working Group , > KINK Working Group , > KRB-WG Working Group , > L2TPEXT Working Group , > LDAPBIS Working Group , > LDAPEXT Working Group , > LDUP Working Group , > MALLOC Working Group , > MANET Working Group , > MBONED Working Group , > MEGACO Working Group , > MIDCOM Working Group , > MMUSIC Working Group , > MOBILEIP Working Group , > MPLS Working Group , > MSDP Working Group , > MSEC Working Group , > MSGTRK Working Group , > MULTI6 Working Group , > NASREQ Working Group , > NAT Working Group , > NFSV4 Working Group , > NGTRANS Working Group , > NNTPEXT Working Group , > OPENPGP Working Group , > OSPF Working Group , > OTP Working Group , > PILC Working Group , > PIM Working Group , > PKIX Working Group , > POISSON Working Group , > POLICY Working Group , > PPPEXT Working Group , > PPVPN Working Group , > PROVREG Working Group , > PWE3 Working Group , > RAP Working Group , > RESCAP Working Group , > RIP Working Group , > RMONMIB Working Group , > RMT Working Group , ROHC Working Group , > RSERPOOL Working Group , > RUN Working Group , > SACRED Working Group , > SEAMOBY Working Group , > SECSH Working Group , > SIGTRAN Working Group , > SIMPLE Working Group , > SIP Working Group , > SMIME Working Group , > SMING Working Group , > SNMPCONF Working Group , > SNMPV3 Working Group , > SPIRITS Working Group , > SSM Working Group , > STIME Working Group , > SYSLOG Working Group , > TEWG Working Group , > TLS Working Group , > TN3270E Working Group , > TRADE Working Group , > TSVWG Working Group , > UDLR Working Group , > URN Working Group , > USEFOR Working Group , > USWG Working Group , > VPIM Working Group , > VRRP Working Group , > WEBDAV Working Group , > WEBI Working Group , > WTS Working Group , > XMLDSIG Working Group , > ZEROCONF Working Group > Cc: iesg@ietf.org > Subject: Note Well > Message-Id: > Sender: Randy Bush > Date: Tue, 17 Jul 2001 13:25:25 -0400 > > > Greetings, > > This is the revised text of the NOTE WELL statement. > > ------------------------------------------------------ > > NOTE WELL > > All statements related to the activities of the IETF and addressed to > the IETF are subject to all provisions of Section 10 of RFC 2026, which > grants to the IETF and its participants certain licenses and rights in > such statements. > > Such statements include verbal statements in IETF meetings, as well as > written and electronic communications made at any time or place, which > are addressed to: > > - the IETF plenary session, > - any IETF working group or portion thereof, > - the IESG, or any member thereof on behalf of the IESG, > - the IAB or any member thereof on behalf of the IAB, > - any IETF mailing list, including the IETF list itself, > any working group or design team list, or any other list > functioning under IETF auspices, > - the RFC Editor or the Internet-Drafts function > > Statements made outside of an IETF meeting, mailing list or other > function, that are clearly not intended to be input to an IETF > activity, group or function, are not subject to these provisions. > > From owner-agentx@dorothy.bmc.com Wed Jul 18 03:19:10 2001 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA20767 for ; Wed, 18 Jul 2001 03:19:09 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id f6I7Jn424784; Wed, 18 Jul 2001 02:19:50 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id AAA24777 for agentx-list; Wed, 18 Jul 2001 00:14:32 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id AAA24771 for agentx@dorothy.bmc.com; Wed, 18 Jul 2001 00:14:27 -0700 (PDT) Date: Wed, 18 Jul 2001 00:14:27 -0700 (PDT) From: Randy Presuhn Message-Id: <200107180714.AAA24771@dorothy.bmc.com> To: agentx@dorothy.bmc.com Subject: Fwd: message from Steve Coya Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list X-MIME-Autoconverted: from 8bit to quoted-printable by babbler.bmc.com id f6I7Jn424784 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA20767 Hi - I'm forwarding an important message from Steve Coya. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. 1-3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ > Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) > by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA12849; > Tue, 17 Jul 2001 10:17:17 -0700 (PDT) > Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) > by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id f6HHHdf18168; > Tue, 17 Jul 2001 12:17:39 -0500 (CDT) > Received: from ietf.org (odin.ietf.org [132.151.1.176]) > by mx-us-hou-1-int.bmc.com (Postfix) with SMTP > id AFFA21FF05A; Tue, 17 Jul 2001 17:13:05 -0500 (CDT) > Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) > by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23758; > Tue, 17 Jul 2001 13:16:53 -0400 (EDT) > Message-Id: <200107171716.NAA23758@ietf.org> > From: The IESG > To: AAA Working Group , > ACAP Working Group , > ADSLMIB Working Group , > AFT Working Group , > AGENTX Working Group , > APEX Working Group , > ATOMMIB Working Group , > AVT Working Group , > BEEP Working Group , > BGMP Working Group , > BMWG Working Group , > BRIDGE Working Group , > CALSCH Working Group , > CAT Working Group , > CCAMP Working Group , > CNRP Working Group , > DELTAV Working Group , > DHC Working Group , > DIFFSERV Working Group , > DISMAN Working Group , > DNSEXT Working Group , > DNSOP Working Group , > ECM Working Group , > EDIINT Working Group , > ENTMIB Working Group , > ENUM Working Group , > EOS Working Group , > FAX Working Group , > FRNETMIB Working Group , > FTPEXT Working Group , > GEOPRIV Working Group , > GRIP Working Group , > GSMP Working Group , > HUBMIB Working Group , > IDMR Working Group , > IDN Working Group , > IDR Working Group , > IDWG Working Group , > IFMIB Working Group , > IMAPEXT Working Group , > IMPP Working Group , > IPCDN Working Group , > IPFC Working Group , > IPNGWG Working Group , > IPO Working Group , > IPORPR Working Group , > IPP Working Group , > IPPM Working Group , > IPS Working Group , > IPSEC Working Group , > IPSP Working Group , > IPSRA Working Group , > IPTEL Working Group , > ISIS Working Group , > ISSLL Working Group , > ITRACE Working Group , > KINK Working Group , > KRB-WG Working Group , > L2TPEXT Working Group , > LDAPBIS Working Group , > LDAPEXT Working Group , > LDUP Working Group , > MALLOC Working Group , > MANET Working Group , > MBONED Working Group , > MEGACO Working Group , > MIDCOM Working Group , > MMUSIC Working Group , > MOBILEIP Working Group , > MPLS Working Group , > MSDP Working Group , > MSEC Working Group , > MSGTRK Working Group , > MULTI6 Working Group , > NASREQ Working Group , > NAT Working Group , > NFSV4 Working Group , > NGTRANS Working Group , > NNTPEXT Working Group , > OPENPGP Working Group , > OSPF Working Group , > OTP Working Group , > PILC Working Group , > PIM Working Group , > PKIX Working Group , > POISSON Working Group , > POLICY Working Group , > PPPEXT Working Group , > PPVPN Working Group , > PROVREG Working Group , > PWE3 Working Group , > RAP Working Group , > RESCAP Working Group , > RIP Working Group , > RMONMIB Working Group , > RMT Working Group , ROHC Working Group , > RSERPOOL Working Group , > RUN Working Group , > SACRED Working Group , > SEAMOBY Working Group , > SECSH Working Group , > SIGTRAN Working Group , > SIMPLE Working Group , > SIP Working Group , > SMIME Working Group , > SMING Working Group , > SNMPCONF Working Group , > SNMPV3 Working Group , > SPIRITS Working Group , > SSM Working Group , > STIME Working Group , > SYSLOG Working Group , > TEWG Working Group , > TLS Working Group , > TN3270E Working Group , > TRADE Working Group , > TSVWG Working Group , > UDLR Working Group , > URN Working Group , > USEFOR Working Group , > USWG Working Group , > VPIM Working Group , > VRRP Working Group , > WEBDAV Working Group , > WEBI Working Group , > WTS Working Group , > XMLDSIG Working Group , > ZEROCONF Working Group > Cc: iesg@ietf.org > Subject: Note Well > Date: Tue, 17 Jul 2001 13:16:53 -0400 > Sender: scoya@cnri.reston.va.us > > > Greetings, > > This is the revised text of the NOTE WELL statement. > > ------------------------------------------------------ > > NOTE WELL > > All statements related to the activities of the IETF and addressed to > the IETF are subject to all provisions of Section 10 of RFC 2026, which > grants to the IETF and its participants certain licenses and rights in > such statements. > > Such statements include verbal statements in IETF meetings, as well as > written and electronic communications made at any time or place, which > are addressed to: > > - the IETF plenary session, > - any IETF working group or portion thereof, > - the IESG, or any member thereof on behalf of the IESG, > - the IAB or any member thereof on behalf of the IAB, > - any IETF mailing list, including the IETF list itself, > any working group or design team list, or any other list > functioning under IETF auspices, > - the RFC Editor or the Internet-Drafts function > > Statements made outside of an IETF meeting, mailing list or other > function, that are clearly not intended to be input to an IETF > activity, group or function, are not subject to these provisions. > From owner-agentx@dorothy.bmc.com Wed Jul 18 13:49:09 2001 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21281 for ; Wed, 18 Jul 2001 13:49:09 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id f6IHnTC10192; Wed, 18 Jul 2001 12:49:29 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA08678 for agentx-list; Wed, 18 Jul 2001 10:45:30 -0700 (PDT) Received: from creeper.bmc.com (creeper.bmc.com [172.17.1.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA08673 for ; Wed, 18 Jul 2001 10:45:27 -0700 (PDT) Received: from ec02-hou.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f6IHkd410749 for ; Wed, 18 Jul 2001 12:46:39 -0500 (CDT) Received: by EC02-HOU.bmc.com with Internet Mail Service (5.5.2653.19) id <3ZBHL6CX>; Wed, 18 Jul 2001 12:46:44 -0500 Message-ID: From: "Ayers, Mike" To: "'agentx@dorothy.bmc.com'" Subject: r.upper_bound Date: Wed, 18 Jul 2001 12:46:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="utf-8" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list There is no clause in RFC2741 requiring r.upper_bound to have a value greater than that of the r.range_subid'th subid of r.subtree. Yet the name is r.upper_bound, not, say, r.range_bound, which implies that it must be the greater value. Which is the correct interpretation? Thanks, /|/|ike /+yers Test Engineer BMC Software Beware of geeks bearing gifts. From owner-agentx@dorothy.bmc.com Thu Jul 19 03:02:43 2001 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA19968 for ; Thu, 19 Jul 2001 03:02:43 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id f6J73jK09558; Thu, 19 Jul 2001 02:03:45 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id XAA05375 for agentx-list; Wed, 18 Jul 2001 23:59:57 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id XAA05370 for ; Wed, 18 Jul 2001 23:59:53 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id f6J70EI09776 for ; Thu, 19 Jul 2001 02:00:14 -0500 (CDT) Received: from mailout01.sul.t-online.de (unknown [194.25.134.80]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 4D71220EFC3 for ; Thu, 19 Jul 2001 06:54:34 -0500 (CDT) Received: from fwd00.sul.t-online.de by mailout01.sul.t-online.de with smtp id 15N7nu-0003Nu-09; Thu, 19 Jul 2001 09:00:58 +0200 Received: from fock.de (320061250925-0001@[217.81.130.235]) by fwd00.sul.t-online.com with esmtp id 15N7nk-0RFlXEC; Thu, 19 Jul 2001 09:00:48 +0200 Message-ID: <3B5688F1.A522697D@fock.de> Date: Thu, 19 Jul 2001 09:14:57 +0200 From: Frank.Fock@t-online.de (Frank Fock) Organization: AGENT++ X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "'agentx@dorothy.bmc.com'" Subject: Timeout during COMMIT SET phase? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: 320061250925-0001@t-dialin.net Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 7bit Hi, As far as I know, the AgentX protocol does not define behavior of the master/subagent when a timeout occurs during the COMMIT phase of a SET request. It is my understanding that the master answers the SNMP SET request with a "general error" when it detects that the subagent does not respond within the corresponding session/region timeout. But then the subagent will never enter the CLEANUP phase for that request. That is a problem because the subagent may have locked the MIB object for concurrent access and may also have allocated some resources. Should the master send a CLEANUP PDU even if the subagent timed out? Or should the subagent detect that the master agent timed out the SET request and start its CLEANUP phase independently? Thanks for any clarification, Frank Fock From owner-agentx@dorothy.bmc.com Thu Jul 19 05:28:52 2001 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07330 for ; Thu, 19 Jul 2001 05:28:51 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id f6J9Tig23003; Thu, 19 Jul 2001 04:29:45 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id CAA17305 for agentx-list; Thu, 19 Jul 2001 02:26:08 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id CAA17300 for ; Thu, 19 Jul 2001 02:26:03 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id f6J9QNL06909 for ; Thu, 19 Jul 2001 04:26:24 -0500 (CDT) Received: from ns.hitt.nl (unknown [212.206.243.122]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 11A9520F071 for ; Thu, 19 Jul 2001 09:20:44 -0500 (CDT) Received: (from fwmaster@localhost) by ns.hitt.nl (8.9.1a/8.6.12) id LAA13951; Thu, 19 Jul 2001 11:27:13 +0200 (MET DST) Received: by ns.hitt.nl via smap (V1.3) id sma013600; Thu, 19 Jul 01 11:25:52 +0200 Received: by CHOPIN with Internet Mail Service (5.5.2448.0) id ; Thu, 19 Jul 2001 11:25:52 +0200 Message-ID: <11655D647028D311A3A20008C7BB878A1EAE32@CHOPIN> From: "Holstein, Bert" To: "'agentx@dorothy.bmc.com'" Cc: "'Frank.Fock@t-online.de'" Subject: RE: Timeout during COMMIT SET phase? Date: Thu, 19 Jul 2001 11:25:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Hi, If the master should send anything at all (I think it should), then it seems to me that the RFC wants it to be an agentx-UndoSet-PDU (instead of the mentioned agentx-CleanupSet-PDU). Reading rfc 2741, especially section 7.2.5.5., having the master send an SNMP response PDU's error set to genErr would also be my choice. However... some clarification is welcomed indeed. Bert Holstein > -----Original Message----- > From: Frank.Fock@t-online.de [SMTP:Frank.Fock@t-online.de] > Sent: Thursday, July 19, 2001 9:15 AM > To: 'agentx@dorothy.bmc.com' > Subject: Timeout during COMMIT SET phase? > > Hi, > > As far as I know, the AgentX protocol does not define > behavior of the master/subagent when a timeout occurs > during the COMMIT phase of a SET request. > > It is my understanding that the master answers the SNMP > SET request with a "general error" when it detects that > the subagent does not respond within the corresponding > session/region timeout. But then the subagent will never > enter the CLEANUP phase for that request. That is a > problem because the subagent may have locked the MIB > object for concurrent access and may also have allocated > some resources. > > Should the master send a CLEANUP PDU even if > the subagent timed out? > > Or should the subagent detect that the master agent > timed out the SET request and start its CLEANUP phase > independently? > > Thanks for any clarification, > Frank Fock From owner-agentx@dorothy.bmc.com Thu Jul 19 08:20:31 2001 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10945 for ; Thu, 19 Jul 2001 08:20:30 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id f6JCLPg14546; Thu, 19 Jul 2001 07:21:25 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA17717 for agentx-list; Thu, 19 Jul 2001 05:17:59 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA17712 for ; Thu, 19 Jul 2001 05:17:54 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id f6JCIEA08433 for ; Thu, 19 Jul 2001 07:18:14 -0500 (CDT) Received: from mercury.mv.net (unknown [199.125.85.40]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id EEB5620F022; Thu, 19 Jul 2001 12:12:33 -0500 (CDT) Received: from world.std.com (bnh-aa1-176.mv.com [199.125.109.176]) by mercury.mv.net (8.8.8/mem-971025) with ESMTP id IAA00968; Thu, 19 Jul 2001 08:19:01 -0400 (EDT) Message-ID: <3B56D0A7.D0B45AC9@world.std.com> Date: Thu, 19 Jul 2001 08:20:55 -0400 From: Mark Ellison Organization: Ellison Software Consulting, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Ayers, Mike" , "'agentx@dorothy.bmc.com'" Subject: Re: r.upper_bound References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 7bit Hi Mike, I've always believed: (r.range_subid == 0) /\ (sub_id[r.range_subid - 1] <= r_upper_bound) where: (sub_id[r.range_subid - 1] == r.upper_bound) is a degenerate condition, so is considered optional, imho The u.upper_bound text on p29 indicates its the upper bound of the range sub-identifier. Possibly this text isn't where you need it? What text would you suggest to clarify? Hope this helps... \\Mark The "Ayers, Mike" wrote: > There is no clause in RFC2741 requiring r.upper_bound to have a > value greater than that of the r.range_subid'th subid of r.subtree. Yet the > name is r.upper_bound, not, say, r.range_bound, which implies that it must > be the greater value. Which is the correct interpretation? > > Thanks, > > /|/|ike /+yers > Test Engineer > BMC Software > Beware of geeks bearing gifts. From owner-agentx@dorothy.bmc.com Thu Jul 19 12:40:36 2001 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08419 for ; Thu, 19 Jul 2001 12:40:35 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id f6JGfLb29184; Thu, 19 Jul 2001 11:41:21 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA18653 for agentx-list; Thu, 19 Jul 2001 09:38:15 -0700 (PDT) Received: from creeper.bmc.com (creeper.bmc.com [172.17.1.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA18648 for ; Thu, 19 Jul 2001 09:38:11 -0700 (PDT) Received: from ec03-hou.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f6JGdKW26423; Thu, 19 Jul 2001 11:39:21 -0500 (CDT) Received: by ec03-hou.bmc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Jul 2001 11:39:25 -0500 Message-ID: From: "Ayers, Mike" To: "'Holstein, Bert'" , "'agentx@dorothy.bmc.com'" Cc: "'Frank.Fock@t-online.de'" Subject: RE: Timeout during COMMIT SET phase? Date: Thu, 19 Jul 2001 11:39:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list > > From: Frank.Fock@t-online.de [SMTP:Frank.Fock@t-online.de] > > As far as I know, the AgentX protocol does not define > > behavior of the master/subagent when a timeout occurs > > during the COMMIT phase of a SET request. Thought I'd snip the relevant sections. It gets clearer when I stick 'em together (at least it does for me). From RFC2741: 7.2.5.1. Common Processing of All AgentX Response PDUs 1) If a response is not received on a session within the timeout interval for this dispatch, it is treated as if the subagent had returned `genErr' and processed as described below. 7.2.5.5. Processing of Responses to agentx-CommitSet-PDUs After common processing of the subagent's response to an agentx- CommitSet-PDU (see section 7.2.5.1, "Common Processing of All AgentX Response PDUs", above), processing continues with the following steps: 1) If any response is not `noError', the SNMP response PDU's error code is set to this value. If res.error contains an AgentX specific value (e.g. `parseError'), the SNMP response PDU's error code is set to a value of genErr instead. Also, the SNMP response PDU's error index is set to the index of the VarBind corresponding to the failed VarBind in the agentx-TestSet-PDU. An agentx-UndoSet-PDU is sent to each target session that has been sent an agentx-CommitSet-PDU. An agentx-CleanupSet-PDU is sent to the remainder of the involved sessions. 7.2.5.6. Processing of Responses to agentx-UndoSet-PDUs After common processing of the subagent's response to an agentx- UndoSet-PDU (see section 7.2.5.1, "Common Processing of All AgentX Response PDUs", above), processing continues with the following steps: 1) If any response is `undoFailed' the SNMP response PDU's error code is set to this value. Also, the SNMP response PDU's error index is set to 0. 2) Otherwise, if any response is not `noError' the SNMP response PDU's error code is set to this value. Also, the SNMP response PDU's error index is set to the index of the VarBind corresponding to the failed VarBind in the agentx-TestSet-PDU. If res.error is an AgentX specific value (e.g. `parseError'), the SNMP response PDU's error code is set to a value of genErr instead. 3) Otherwise the SNMP response PDU's error code and error index were set in section 7.2.5.5 step 1) Return value: undoFailed - if returned, else (return code to undoSet that was not noError) - if returned, else genErr Cleanupo PDUs: UndoSet - if a CommitSet had been sent, else CleanupSet HTH, /|/|ike From owner-agentx@dorothy.bmc.com Thu Jul 19 13:28:24 2001 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16471 for ; Thu, 19 Jul 2001 13:28:23 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id f6JHTLC08141; Thu, 19 Jul 2001 12:29:21 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA19045 for agentx-list; Thu, 19 Jul 2001 10:26:21 -0700 (PDT) Received: from creeper.bmc.com (creeper.bmc.com [172.17.1.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA19017 for ; Thu, 19 Jul 2001 10:26:13 -0700 (PDT) Received: from ec03-hou.bmc.com (localhost [127.0.0.1]) by creeper.bmc.com (8.10.2/8.10.2) with ESMTP id f6JHROT00695 for ; Thu, 19 Jul 2001 12:27:24 -0500 (CDT) Received: by ec03-hou.bmc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 19 Jul 2001 12:27:29 -0500 Message-ID: From: "Ayers, Mike" To: "'agentx@dorothy.bmc.com'" Subject: RE: r.upper_bound Date: Thu, 19 Jul 2001 12:27:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list > From: Mark Ellison [mailto:ellison@world.std.com] > I've always believed: > > (r.range_subid == 0) /\ (sub_id[r.range_subid - 1] > <= r_upper_bound) I take it you're using 0 offset indexing here, as opposed to the 1 offset indexing of r.range_subid, therefore the "- 1", yes? If so, then this behavior is exactly what I expected. > (sub_id[r.range_subid - 1] == r.upper_bound) is a > degenerate condition, so > is considered optional, imho Agreed. There are some specifications better left undeclared. > The u.upper_bound text on p29 indicates its the upper bound > of the range > sub-identifier. Possibly this text isn't where you need it? > What text would > you suggest to clarify? How about (from page 25): r.upper_bound The upper bound of a sub-identifier's range. This field is present only if r.range_subid is not 0, and must be greater in value than the subid indicated by r.range_subid. Why am I picking this nit, you ask? I tripped over an oddity while debugging, and made a cursory check that r.upper_bound could not be 0 (at least for a registration with no 0s in its OID) and found the text too weak to be certain (could wraparound registration be permitted?). Therefore I came here. Figure we can save someone else the trip. /|/|ike From owner-agentx@dorothy.bmc.com Thu Jul 19 17:18:09 2001 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15306 for ; Thu, 19 Jul 2001 17:18:08 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id f6JLGS709650; Thu, 19 Jul 2001 16:16:28 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA22584 for agentx-list; Thu, 19 Jul 2001 14:12:14 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA22579 for ; Thu, 19 Jul 2001 14:12:11 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id f6JLCVE09087 for ; Thu, 19 Jul 2001 16:12:31 -0500 (CDT) Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id B30D91FF057; Thu, 19 Jul 2001 21:07:47 -0500 (CDT) Received: from world.std.com (bnh-aa1-140.mv.com [199.125.109.140]) by mercury.mv.net (8.8.8/mem-971025) with ESMTP id RAA26818; Thu, 19 Jul 2001 17:13:06 -0400 (EDT) Message-ID: <3B574DD2.F1ABA086@world.std.com> Date: Thu, 19 Jul 2001 17:14:58 -0400 From: Mark Ellison Organization: Ellison Software Consulting, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Ayers, Mike" Cc: "'agentx@dorothy.bmc.com'" Subject: Re: r.upper_bound References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 7bit Mike, I salute your excellency in nits :-) ...and yes, I'm using 0 offset indexing in the p.notation below. Now, I'd like to solicit comments from the list on the suggested text with respect to existing text on p.26 for the first paragraph.as follows: r.upper_bound The upper bound of a sub-identifier's range. This field is present only if r.range_subid is not 0, and must be greater in value than the subid indicated by r.range_subid. Do others see a need to amend the suggested text? Or is it best left as is? Regards, Mark "Ayers, Mike" wrote: > > From: Mark Ellison [mailto:ellison@world.std.com] > > > I've always believed: > > > > (r.range_subid == 0) /\ (sub_id[r.range_subid - 1] > > <= r_upper_bound) > > I take it you're using 0 offset indexing here, as opposed to the 1 > offset indexing of r.range_subid, therefore the "- 1", yes? If so, then > this behavior is exactly what I expected. > > > (sub_id[r.range_subid - 1] == r.upper_bound) is a > > degenerate condition, so > > is considered optional, imho > > Agreed. There are some specifications better left undeclared. > > > The u.upper_bound text on p29 indicates its the upper bound > > of the range > > sub-identifier. Possibly this text isn't where you need it? > > What text would > > you suggest to clarify? > > How about (from page 25): > > > > r.upper_bound > > The upper bound of a sub-identifier's range. This field is > present only if r.range_subid is not 0, and must be greater > in value than the subid indicated by r.range_subid. > > > > Why am I picking this nit, you ask? I tripped over an oddity while > debugging, and made a cursory check that r.upper_bound could not be 0 (at > least for a registration with no 0s in its OID) and found the text too weak > to be certain (could wraparound registration be permitted?). Therefore I > came here. Figure we can save someone else the trip. > > /|/|ike From owner-agentx@dorothy.bmc.com Fri Jul 20 03:16:54 2001 Received: from babbler.bmc.com (fw-us-hou-9.bmc.com [198.207.223.229]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01977 for ; Fri, 20 Jul 2001 03:16:53 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id f6K7Hmc08626; Fri, 20 Jul 2001 02:17:49 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id AAA06327 for agentx-list; Fri, 20 Jul 2001 00:14:41 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id AAA06322 for ; Fri, 20 Jul 2001 00:14:37 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id f6K7Ev522534 for ; Fri, 20 Jul 2001 02:14:57 -0500 (CDT) Received: from mailout00.sul.t-online.de (mailout00.sul.t-online.com [194.25.134.16]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id A83171FF03E; Fri, 20 Jul 2001 07:10:12 -0500 (CDT) Received: from fwd03.sul.t-online.de by mailout00.sul.t-online.de with smtp id 15NUVZ-0002FQ-0D; Fri, 20 Jul 2001 09:15:33 +0200 Received: from fock.de (320061250925-0001@[217.81.135.131]) by fwd03.sul.t-online.com with esmtp id 15NUVS-0EjUTAC; Fri, 20 Jul 2001 09:15:26 +0200 Message-ID: <3B57DDE9.7EFC1ABF@fock.de> Date: Fri, 20 Jul 2001 09:29:45 +0200 From: Frank.Fock@t-online.de (Frank Fock) Organization: AGENT++ X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Ayers, Mike" Cc: "'Holstein, Bert'" , "'agentx@dorothy.bmc.com'" Subject: Re: Timeout during COMMIT SET phase? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: 320061250925-0001@t-dialin.net Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 7bit Mike and Bert, Thanks for your clarifications. It aligns with my first approach to this problem. What made me uncertain about it was that the subagent that timed out will receive the UNDO while the COMMIT is currently in progress. Thus, a multithreaded agent must serialize the AgentX requests related to a SNMP SET request. Best regards, Frank "Ayers, Mike" wrote: > >From RFC2741: > > > 7.2.5.1. Common Processing of All AgentX Response PDUs > > 1) If a response is not received on a session within the timeout > interval for this dispatch, it is treated as if the subagent had > returned `genErr' and processed as described below. > > > > 7.2.5.5. Processing of Responses to agentx-CommitSet-PDUs > > After common processing of the subagent's response to an agentx- > CommitSet-PDU (see section 7.2.5.1, "Common Processing of All AgentX > Response PDUs", above), processing continues with the following > steps: > > 1) If any response is not `noError', the SNMP response PDU's error > code is set to this value. If res.error contains an AgentX > specific value (e.g. `parseError'), the SNMP response PDU's error > code is set to a value of genErr instead. Also, the SNMP response > PDU's error index is set to the index of the VarBind corresponding > to the failed VarBind in the agentx-TestSet-PDU. > > An agentx-UndoSet-PDU is sent to each target session that has been > sent an agentx-CommitSet-PDU. An agentx-CleanupSet-PDU is sent to > the remainder of the involved sessions. > > > > 7.2.5.6. Processing of Responses to agentx-UndoSet-PDUs > > After common processing of the subagent's response to an agentx- > UndoSet-PDU (see section 7.2.5.1, "Common Processing of All AgentX > Response PDUs", above), processing continues with the following > steps: > > 1) If any response is `undoFailed' the SNMP response PDU's error code > is set to this value. Also, the SNMP response PDU's error index > is set to 0. > > 2) Otherwise, if any response is not `noError' the SNMP response > PDU's error code is set to this value. Also, the SNMP response > PDU's error index is set to the index of the VarBind corresponding > to the failed VarBind in the agentx-TestSet-PDU. If res.error is > an AgentX specific value (e.g. `parseError'), the SNMP response > PDU's error code is set to a value of genErr instead. > > 3) Otherwise the SNMP response PDU's error code and error index were > set in section 7.2.5.5 step 1) > > > Return value: > undoFailed - if returned, else > (return code to undoSet that was not noError) - if returned, else > genErr > > Cleanupo PDUs: > UndoSet - if a CommitSet had been sent, else > CleanupSet > > HTH, > > /|/|ike