From owner-agentx@dorothy.bmc.com Thu Jul 1 16:25:51 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18419 for ; Thu, 1 Jul 1999 16:25:50 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id PAA16663; Thu, 1 Jul 1999 15:22:59 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA13605 for agentx-list; Thu, 1 Jul 1999 13:18:26 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA13600 for ; Thu, 1 Jul 1999 13:18:20 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id PAA15706 for ; Thu, 1 Jul 1999 15:18:19 -0500 (CDT) Received: from [38.249.211.2] (helo=relay1.acecomm.com) by relay6.smtp.psi.net with smtp (Exim 1.90 #1) for agentx@dorothy.bmc.com id 10znHl-0003u5-00; Thu, 1 Jul 1999 16:18:17 -0400 Received: from bnatale by relay1.acecomm.com (SMI-8.6/SMI-SVR4) id QAA21520; Thu, 1 Jul 1999 16:27:00 -0400 Message-Id: <4.1.19990701160559.00a4c590@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 01 Jul 1999 16:22:19 -0400 To: agentx@dorothy.bmc.com From: Bob Natale Subject: AgentX "WG Last Call", etc. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Hi, The primary purpose of this message is to announce a one-month "Working Group Last Call" on the following two documents: Title : Agent Extensibility (AgentX) Protocol Author(s) : M. Daniele, B. Wijnen, M. Ellison Filename : draft-ietf-agentx-rfc-update-00.txt Pages : 83 Date : 24-Jun-99 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-agentx-rfc-update-00.txt Title : Definitions of Managed Objects for Extensible SNMP Agents Author(s) : L. Heintz, S. Gudur, M. Ellison Filename : draft-ietf-agentx-mib-03.txt Pages : 24 Date : 24-Jun-99 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-agentx-mib-03.txt This WG Last Call will expire on Aug 1, 1999...that is, comments will be accepted for discussion through July 31, 1999. Cordially, This is a one-month last call in recognition of the impact of the 45th IETF meeting in Oslo (July 11-16) on some WG participants and of the higher incidence of vacations taken during this time of the year. In addition to the technical details of each document, we need to reach decisions wrt: - Should the MIB document be put on the standards track (Proposed Standard) or published as Informational RFC, or something else? Strawman: Standards track. - Should we seek to advance the protocol RFC to Draft Standard on the basis of this revision, the existig bake-off experience, published implementation and interoperability reports, and any new supporting facts in these areas that might materialize between now and the 46th IETF (Washington, DC; Nov 1999)... or should we recycle it at Proposed Standard due to the number and nature of the changes and (mostly) clarifications made to this revision and rely on the next bake-off (possibly in late September) and new/renwed implementation and interoperability reports to bolster the case for Draft Standard status around the start of 2000? Strawman: Recycle at Proposed Standard. - Items (goals and milestones) pertaining to revising our Charter for going forward. - Anything else of relevance to AgentX that any Working Group member wishes to propose...? BobN ------------ ISO 9001 Registered Quality Supplier ----------- 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 ------------- Free downloads at www.winsnmp.com ------------- From owner-agentx@dorothy.bmc.com Fri Jul 2 12:02:21 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17243 for ; Fri, 2 Jul 1999 12:02:20 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id KAA26266; Fri, 2 Jul 1999 10:59:45 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA22739 for agentx-list; Fri, 2 Jul 1999 08:58:01 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA22732 for ; Fri, 2 Jul 1999 08:57:51 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id KAA25829 for ; Fri, 2 Jul 1999 10:57:50 -0500 (CDT) Received: from southrelay03.raleigh.ibm.com (southrelay03.raleigh.ibm.com [9.37.3.210]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA119802 for ; Fri, 2 Jul 1999 11:57:36 -0400 Received: from BLDVMA.boulder.ibm.com (bldvma.boulder.ibm.com [9.99.64.30]) by southrelay03.raleigh.ibm.com (8.8.8m2/NCO v2.03) with SMTP id LAA96816 for ; Fri, 2 Jul 1999 11:57:42 -0400 Message-Id: <199907021557.LAA96816@southrelay03.raleigh.ibm.com> Received: by BLDVMA.boulder.ibm.com (IBM VM SMTP Level 310) via spool with SMTP id 3478 ; Fri, 02 Jul 1999 09:57:06 MDT Date: Fri, 2 Jul 99 17:55:25 DST From: "Bert Wijnen" To: agentx@dorothy.bmc.com Subject: AgentX "WG Last Call", etc. Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Ref: Your note of Thu, 01 Jul 1999 16:22:19 -0400 Subject: Re: AgentX "WG Last Call" for draft-ietf-agentx-mib-03.txt In general, I think the doc looks quoite good. Here are some comments I have (as a WG member): - I agree that we should put it on the Standards Track - That means we need to remove "experimental" from the abstract. - Pls change "SNMPv2 SMI" into "SMIv2" (multiple places) and I think that SNMPv1 in the abstract should read SMIv1. - I would suggest to add a revision clause to the MODULE-IDENTITY. So just before : ::= { mib-2 ? } -- To be assigned by IANA pls insert: -- revision history REVISION "yymmdd000000Z" -- use same date as LAST-UPDATED -- RFC-Editor assigns RFC xxxx DESCRIPTION " Initial version, published as RFC xxxx." thatway, an extracted MIB will get a ptr to the RFC. - I would suggest to add a range to the Unsigned32 indices so that a value of zero is excluded as a valid value. We do not want an index to be zero. - Maybe the references to MIB II (sysDescr) should be replaced with refenreces to RFC1907. - I am surprised about agentxSessionAdminStatus. Can the value "up" be SET via SNMP? I doubt it. And after a set to "down", is the row then gone? If so, then maybe a RowStatus is the better TC to use?? - I would suggest that the various xxxTimeOut objects should have MAX-ACCESS of read-write. You would want a manager to be able to reset an excessive value requested by a subagent, no? Of course it is OK to put a MIN-ACCESS of read-only in the compliance section. - Sect 7, talks about the existence of read-create objects, but I do not see any. So... we need to fix that. I guess that is what you get when template text gets used. Bert From owner-agentx@dorothy.bmc.com Fri Jul 2 12:08:23 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17602 for ; Fri, 2 Jul 1999 12:08:22 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id LAA27578; Fri, 2 Jul 1999 11:05:53 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA22849 for agentx-list; Fri, 2 Jul 1999 09:05:42 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA22844 for ; Fri, 2 Jul 1999 09:05:38 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id LAA27512 for ; Fri, 2 Jul 1999 11:05:36 -0500 (CDT) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.117.200.23]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id MAA56658 for ; Fri, 2 Jul 1999 12:05:20 -0400 Received: from BLDVMA.boulder.ibm.com (bldvma.boulder.ibm.com [9.99.64.30]) by northrelay03.pok.ibm.com (8.8.8m2/NCO v2.03) with SMTP id MAA20462 for ; Fri, 2 Jul 1999 12:05:28 -0400 Message-Id: <199907021605.MAA20462@northrelay03.pok.ibm.com> Received: by BLDVMA.boulder.ibm.com (IBM VM SMTP Level 310) via spool with SMTP id 3583 ; Fri, 02 Jul 1999 10:04:50 MDT Date: Fri, 2 Jul 99 18:03:10 DST From: "Bert Wijnen" To: agentx@dorothy.bmc.com Subject: AgentX "WG Last Call", etc. Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Ref: Your note of Thu, 01 Jul 1999 16:22:19 -0400 Subject: Re: AgentX "WG Last Call" for draft-ietf-agentx-rfc-update-00 I think the document looks pretty good. Given the notes about "Changes on the wire" in the appendix, and given that another round of interoperability testing is tentaively schedule for later this year... I agree that recycling at Proposed would be a wise thing to do Here are my comments (as WG member): - I think we need an abstract. The abstract also needs to state that it will obsolete RFC 2257 - Pls change my info in section 11 to: Bert Wijnen IBM T.J.Watson Research Schagen 33 3461 GL Linschoten Netherlands Phone: +31-348-432-794 EMail: wijnen@vnet.ibm.com Speaking as AD: - I am missing Dale from the title page. Did he request or agree to be removed? In any event, I think even if he wants to be removed, we should say special thanks to him in the acknowledgement section. But I suggest we keep him on title page. That would be consistent what IESG has decided in other cases. Bert From owner-agentx@dorothy.bmc.com Fri Jul 2 12:55:10 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19220 for ; Fri, 2 Jul 1999 12:55:09 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id LAA05940; Fri, 2 Jul 1999 11:52:41 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA23184 for agentx-list; Fri, 2 Jul 1999 09:52:16 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA23179 for ; Fri, 2 Jul 1999 09:52:12 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id LAA05838 for ; Fri, 2 Jul 1999 11:52:11 -0500 (CDT) Received: from [38.249.211.2] (helo=relay1.acecomm.com) by relay6.smtp.psi.net with smtp (Exim 1.90 #1) id 1106Xh-0000wD-00; Fri, 2 Jul 1999 12:52:01 -0400 Received: from bnatale by relay1.acecomm.com (SMI-8.6/SMI-SVR4) id MAA25561; Fri, 2 Jul 1999 12:53:02 -0400 Message-Id: <4.1.19990702123245.00a5b800@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 02 Jul 1999 12:48:21 -0400 To: "Bert Wijnen" From: Bob Natale Subject: Re: [RFC doc] AgentX "WG Last Call", etc. Cc: daniele@zk3.dec.com, ellison@world.std.com, dfrancis@cisco.com, agentx@dorothy.bmc.com In-Reply-To: <199907021605.MAA20462@northrelay03.pok.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk >At 7/2/99:02:03 PM, Bert Wijnen wrote: Hi Bert, >Re: AgentX "WG Last Call" for draft-ietf-agentx-rfc-update-00 >I think the document looks pretty good. Great!...thanks for the prompt feedback. >Given the notes about "Changes on the wire" in the appendix, and >given that another round of interoperability testing is tentaively >schedule for later this year... I agree that recycling at Proposed >would be a wise thing to do Ok...good (and that pretty much settles that issue). >Here are my comments (as WG member): > >- I think we need an abstract. > The abstract also needs to state that it will obsolete RFC 2257 Mike will you take the lead on that please...work with Mark as necessary...and then post it to the list with a target date of no later than July 15...allowing for WG review and comment (which hopefully will be minimal to none) during this established last call period. >- Pls change my info in section 11 to: > > Bert Wijnen > IBM T.J.Watson Research > Schagen 33 > 3461 GL Linschoten > Netherlands > > Phone: +31-348-432-794 > EMail: wijnen@vnet.ibm.com Mark, that ones for you directly. >Speaking as AD: > >- I am missing Dale from the title page. Dale resigned as WG editor, having completed the task (very competently) up to and including issuance of RFC2257. Mark assumed the role and, working from a highly evolved text developed by Mike, produced the current I-D as the lone editor. > Did he request or agree to be removed? No, the issue was not raised. It was probably my assumption that only the actual editor(s) of a given document should be listed on the title page. If that is incorrect, we can surely fix it. > In any event, I think even if he wants to be > removed, we should say special thanks to him > in the acknowledgement section. I do prefer that approach...actually I *thought* I had made a suggestion to that effect during the process of creating this rev, but perhaps not. It is surely true that Dale did an excellent job on the original document and also contributed to the WG in other ways prior to his workload in his day job becoming overwelming. > But I suggest we keep him on title page. > That would be consistent what IESG has decided > in other cases. It that's the case, then it's probably the best approach, regardless of my preferences (which emanate solely from a desire to have the title page reflect only those who functioned as author or editor on the given document). Let's see if Dale or anyone else has any follow-up comments on this point between now and July 15...if not, we'll take Bert's advice here. In either case, Mark be prepared to change the title page and/or add a special tribute in the Acknowledgments section. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- 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 ------------- Free downloads at www.winsnmp.com ------------- From owner-agentx@dorothy.bmc.com Fri Jul 2 13:16:44 1999 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19786 for ; Fri, 2 Jul 1999 13:16:43 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id MAA10105; Fri, 2 Jul 1999 12:14:19 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA23304 for agentx-list; Fri, 2 Jul 1999 10:13:47 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA23299 for ; Fri, 2 Jul 1999 10:13:41 -0700 (PDT) Received: from fw-us-hou2.bmc.com (fw-us-hou2.bmc.com [172.17.1.236]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id MAA09951 for ; Fri, 2 Jul 1999 12:13:38 -0500 (CDT) Received: from pet1-104208 ([192.168.104.208] helo=cerent.com) by mailhost with esmtp (Exim 2.05 #2) id 1106n6-0004lD-00; Fri, 2 Jul 1999 10:07:56 -0700 Message-ID: <377CF207.77DC42F5@cerent.com> Date: Fri, 02 Jul 1999 10:08:23 -0700 From: Lauren Heintz Organization: Cerent Corporation X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Bert Wijnen CC: agentx@dorothy.bmc.com Subject: Re: AgentX "WG Last Call", etc. References: <199907021557.LAA96816@southrelay03.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi Bert, Bert Wijnen wrote: > > Ref: Your note of Thu, 01 Jul 1999 16:22:19 -0400 > > Subject: Re: AgentX "WG Last Call" for draft-ietf-agentx-mib-03.txt > > - I am surprised about agentxSessionAdminStatus. > Can the value "up" be SET via SNMP? I doubt it. > And after a set to "down", is the row then gone? > If so, then maybe a RowStatus is the better TC to use?? Mike Thatcher and I suggested this, I think at Chicago AgentX session, and I recall I mentioned this on the list even earlier than that. However, no one seemed thrilled about using RowStatus (didn't even get any head-nodding or your famous, mmmms) so I dropped the issue. And yes, "down" is equivalent to "destroy", and "up" can't be set via SNMP. > - I would suggest that the various xxxTimeOut objects should > have MAX-ACCESS of read-write. You would want a manager to > be able to reset an excessive value requested by a subagent, no? > Of course it is OK to put a MIN-ACCESS of read-only in the > compliance section. agentxSessionTimeout and agentxRegTimeout (MAX-ACCESS, read-only) descriptions indicate these values are reflective of the subagent protocol element. So, do we want to be able to both report the protocol elements AND be able to override them as you suggest? Might we instead redefine the agentxDefaultTimeout so that it also defines a timeout ceiling, or perhaps add a agentxMaxTimeout variable? Of course, if reporting the protocol elements isn't essential, we could just change as you suggested and rewrite the descriptions, etc.. > - Sect 7, talks about the existence of read-create objects, > but I do not see any. So... we need to fix that. I guess that > is what you get when template text gets used. > > Bert Since the text reads "read-write and/or read-create", it seems technically correct, although maybe a little too generic. So, are you suggesting that we change the boilerplate, or just edit this one reference, or both? Tks, Lauren From owner-agentx@dorothy.bmc.com Fri Jul 2 14:06:43 1999 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21158 for ; Fri, 2 Jul 1999 14:06:43 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id NAA21298; Fri, 2 Jul 1999 13:03:36 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA23692 for agentx-list; Fri, 2 Jul 1999 11:02:36 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA23687 for ; Fri, 2 Jul 1999 11:02:33 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id NAA21065 for ; Fri, 2 Jul 1999 13:02:31 -0500 (CDT) Received: from sigma.zk3.dec.com (brysigma.zk3.dec.com [16.141.40.6]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id OAA09085; Fri, 2 Jul 1999 14:06:11 -0400 (EDT) Received: from zk3.dec.com by sigma.zk3.dec.com (8.8.8/1.1.20.3/24Apr98-0811AM) id OAA0000032345; Fri, 2 Jul 1999 14:01:57 -0400 (EDT) Message-ID: <377CFD22.216CFAF@zk3.dec.com> Date: Fri, 02 Jul 1999 13:55:46 -0400 From: Mike Daniele Organization: Compaq 64-bit UNIX networking X-Mailer: Mozilla 4.61 [en] (X11; I; OSF1 X5.0 alpha) X-Accept-Language: en MIME-Version: 1.0 To: Bob Natale CC: Bert Wijnen , ellison@world.std.com, dfrancis@cisco.com, agentx@dorothy.bmc.com Subject: Re: [RFC doc] AgentX "WG Last Call", etc. References: <4.1.19990702123245.00a5b800@nips.acec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Content-Transfer-Encoding: 7bit >Mike will you take the lead on that please...work with Mark >as necessary...and then post it to the list with a target >date of no later than July 15...allowing for WG review and >comment (which hopefully will be minimal to none) during >this established last call period. Will do. Post just a suggested abstract or a whole new draft? Mike From owner-agentx@dorothy.bmc.com Fri Jul 2 14:31:00 1999 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21704 for ; Fri, 2 Jul 1999 14:30:54 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id NAA27169; Fri, 2 Jul 1999 13:27:38 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA23939 for agentx-list; Fri, 2 Jul 1999 11:27:14 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA23931 for ; Fri, 2 Jul 1999 11:27:10 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id NAA27077 for ; Fri, 2 Jul 1999 13:27:08 -0500 (CDT) Received: from [38.249.211.2] (helo=relay1.acecomm.com) by relay2.smtp.psi.net with smtp (Exim 1.90 #1) id 11081h-0006Dr-00; Fri, 2 Jul 1999 14:27:05 -0400 Received: from bnatale by relay1.acecomm.com (SMI-8.6/SMI-SVR4) id OAA25945; Fri, 2 Jul 1999 14:35:49 -0400 Message-Id: <4.1.19990702141539.00a4ca40@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 02 Jul 1999 14:31:07 -0400 To: Mike Daniele From: Bob Natale Subject: Re: [RFC doc] AgentX "WG Last Call", etc. Cc: agentx@dorothy.bmc.com In-Reply-To: <377CFD22.216CFAF@zk3.dec.com> References: <4.1.19990702123245.00a5b800@nips.acec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk >At 7/2/99:01:55 PM, Mike Daniele wrote: Hi Mike, >>Mike will you take the lead on that please...work with Mark >>as necessary...and then post it to the list with a target >>date of no later than July 15...allowing for WG review and >>comment (which hopefully will be minimal to none) during >>this established last call period. > >Will do. Thanks. >Post just a suggested abstract or a whole new draft? Just the proposed abstract. I think that interested parties should be able to track the few anticipated changes as mods to the already posted I-Ds. Then, at the close of this WG last call period (Aug 1), Mark will finalize corresponding updates to both I-Ds and resubmit them with our request for IESG review/action. Let me know if anyone sees any problems with that approach. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- 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 ------------- Free downloads at www.winsnmp.com ------------- From owner-agentx@dorothy.bmc.com Mon Jul 5 10:34:51 1999 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02074 for ; Mon, 5 Jul 1999 10:34:50 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id JAA28089; Mon, 5 Jul 1999 09:24:44 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA21823 for agentx-list; Mon, 5 Jul 1999 07:17:37 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA21818 for ; Mon, 5 Jul 1999 07:17:33 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id JAA27539 for ; Mon, 5 Jul 1999 09:17:32 -0500 (CDT) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.117.200.23]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA09662; Mon, 5 Jul 1999 10:17:17 -0400 Received: from BLDVMA.boulder.ibm.com (bldvma.boulder.ibm.com [9.99.64.30]) by northrelay03.pok.ibm.com (8.8.8m2/NCO v2.03) with SMTP id KAA33950; Mon, 5 Jul 1999 10:17:22 -0400 Message-Id: <199907051417.KAA33950@northrelay03.pok.ibm.com> Received: by BLDVMA.boulder.ibm.com (IBM VM SMTP Level 310) via spool with SMTP id 6526 ; Mon, 05 Jul 1999 08:16:31 MDT Date: Mon, 5 Jul 99 16:14:45 DST From: "Bert Wijnen" To: lauren.heintz@cerent.com cc: agentx@dorothy.bmc.com Subject: AgentX "WG Last Call", etc. Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Ref: Your note of Fri, 02 Jul 1999 10:08:23 -0700 Subject: Re: AgentX "WG Last Call", etc. Lauren writes: > > > > Ref: Your note of Thu, 01 Jul 1999 16:22:19 -0400 > > > > Subject: Re: AgentX "WG Last Call" for draft-ietf-agentx-mib-03.txt > > > > - I am surprised about agentxSessionAdminStatus. > > Can the value "up" be SET via SNMP? I doubt it. > > And after a set to "down", is the row then gone? > > If so, then maybe a RowStatus is the better TC to use?? > > Mike Thatcher and I suggested this, I think at Chicago AgentX session, > and I recall I mentioned this on the list even earlier than that. > However, no one seemed thrilled about using RowStatus (didn't even get > any head-nodding or your famous, mmmms) so I dropped the issue. And > yes, "down" is equivalent to "destroy", and "up" can't be set via SNMP. > So... I would say RowStatus is probably best. But in nay event, you should explain that 'up' cannot be SET. And in the Compliance you should specify that too as a WRITE-SYNTAX and then only list the 'down' value. > > > - I would suggest that the various xxxTimeOut objects should > > have MAX-ACCESS of read-write. You would want a manager to > > be able to reset an excessive value requested by a subagent, no? > > Of course it is OK to put a MIN-ACCESS of read-only in the > > compliance section. > > agentxSessionTimeout and agentxRegTimeout (MAX-ACCESS, read-only) > descriptions indicate these values are reflective of the subagent > protocol element. So, do we want to be able to both report the protocol > elements AND be able to override them as you suggest? Might we instead > redefine the agentxDefaultTimeout so that it also defines a timeout > ceiling, or perhaps add a agentxMaxTimeout variable? Of course, if > reporting the protocol elements isn't essential, we could just change as > you suggested and rewrite the descriptions, etc.. > In my original (saMIB) I did have a ..MaxTimeOut, so that the NMS could limit the max timeout a subagent can use. Also.. I did allow a NMS to overwrite any value that a subagent had requested... just so a NMS can excercise control. See if MaxTimeOut is say 255 tpo begin with and a sub request 255 and then a NMS sets MaxTimeOut to say 10... do you then go automatically to reset all subagent values to max 10 too? or do you leave them in tact and only apply the max value for the new connections. Guess you could do so, because an NMS could always destroy (down) the connection and cause the sub to reconnect in whcih case the new MaxTimeout value would apply. Anyway... it is not that I feel VERY STRONG about these things, I just brought it up, because I know I had this capability in my original saMIB (IBM enterprise specific MIB used with DPI). > > - Sect 7, talks about the existence of read-create objects, > > but I do not see any. So... we need to fix that. I guess that > > is what you get when template text gets used. > > > > Bert > > Since the text reads "read-write and/or read-create", it seems > technically correct, although maybe a little too generic. So, are you > suggesting that > we change the boilerplate, or just edit this one reference, or both? > Our security guildelines are GUIDELINES. So in this case I would remove the "and/or read-create" although I do agree that it is not incorrect according to the letter of the words. Up to you. Bert From owner-agentx@dorothy.bmc.com Mon Jul 5 12:55:51 1999 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03377 for ; Mon, 5 Jul 1999 12:55:51 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id LAA09773; Mon, 5 Jul 1999 11:51:57 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA22616 for agentx-list; Mon, 5 Jul 1999 09:49:57 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA22611 for ; Mon, 5 Jul 1999 09:49:52 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id LAA09659 for ; Mon, 5 Jul 1999 11:49:51 -0500 (CDT) Received: from [38.249.211.2] (helo=relay1.acecomm.com) by relay1.smtp.psi.net with smtp (Exim 1.90 #1) id 111BwE-0007hI-00; Mon, 5 Jul 1999 12:49:50 -0400 Received: from natale by relay1.acecomm.com (SMI-8.6/SMI-SVR4) id MAA03547; Mon, 5 Jul 1999 12:58:23 -0400 Message-Id: <4.1.19990705123306.0096b100@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 05 Jul 1999 12:50:58 -0400 To: "Bert Wijnen" , lauren.heintz@cerent.com From: Bob Natale Subject: AbentX MIB: maxTimeOut issue Cc: agentx@dorothy.bmc.com In-Reply-To: <199907051417.KAA33950@northrelay03.pok.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk >At 7/5/99:12:14 PM, Bert Wijnen wrote: Hi Bert and Lauren, >Subject: Re: AgentX "WG Last Call", etc. I've changed the subject header to more clearly identify this single issue: >> > - I would suggest that the various xxxTimeOut objects should >> > have MAX-ACCESS of read-write. You would want a manager to >> > be able to reset an excessive value requested by a subagent, no? >> > Of course it is OK to put a MIN-ACCESS of read-only in the >> > compliance section. >> >> agentxSessionTimeout and agentxRegTimeout (MAX-ACCESS, read-only) >> descriptions indicate these values are reflective of the subagent >> protocol element. So, do we want to be able to both report the protocol >> elements AND be able to override them as you suggest? Might we instead >> redefine the agentxDefaultTimeout so that it also defines a timeout >> ceiling, or perhaps add a agentxMaxTimeout variable? Of course, if >> reporting the protocol elements isn't essential, we could just change as >> you suggested and rewrite the descriptions, etc.. >> >In my original (saMIB) I did have a ..MaxTimeOut, so that the >NMS could limit the max timeout a subagent can use. Also.. I did >allow a NMS to overwrite any value that a subagent had >requested... just so a NMS can excercise control. Yes, I think [an interpretation of the agentxDefaultTimeout value as] a maxTimeOut value is very useful. I do not think we should hold either the NMS or the master agent hostage to a given sub-agent timeout value. Of course, the sub-agent may still take as long as it needs to perform its processing and this may well result in a timeout condition followed by an "out-dated" response from the sub-agent that will just have to be discarded...thus if either the sub-agent's requested timeout value and/or its inability to respond within a user-specified amount of time (via the NMS) is unacceptable in a given user scenario, we can expect market forces to play their legitimate role. >See if MaxTimeOut is say 255 tpo begin with and a sub request 255 >and then a NMS sets MaxTimeOut to say 10... do you then go automatically >to reset all subagent values to max 10 too? That's what I would do...their really is no need to "reset" higher sub-agent values to a lower master agent maxTimeOut value...the lower value applies automatically in any case. In fact, you (i.e., the master agent implementation) should not change the value requested by the sub-agent...in setting the timer on any request to a sub- agent, the master simply checks its notion of maxTimeOut versus the sub's notion and applies the shorter. If the master's maxTimeOut value is later changed to something higher than a given sub-agent's requested timeout value, then that sub-agent's value applies on requests to it. >or do you leave them in tact and only apply the max value for the >new connections. Guess you could do so, because an NMS could always >destroy (down) the connection and cause the sub to reconnect in whcih >case the new MaxTimeout value would apply. I would not recommend that...it is unnecessary (see above) and would be highly costly in terms of operational overhead and performance. >Anyway... it is not that I feel VERY STRONG about these things, >I just brought it up, because I know I had this capability >in my original saMIB (IBM enterprise specific MIB used with DPI). Right...I think we can just re-state the semantics of the agentxDefaultTimeout object as applying a maxTimeOut value as well. In other words, if a sub-agent does not specify a specific timeout value, the agentxDefaultTimeout value will be applied to requests to that sub-agent. If a sub-agent does supply a specific timeout value and it is *less than* the agentxDefaultTimeout value, then it will be used for such requests. Otherwise, if it is higher than agentxDefaultTimeout, then it will simply be retained for use should the value of agentxDefaultTimeout be administratively increased to a value higher than the sub-agent's specific timeout value. Assuming that basic interpretation is acceptable, I am certain the Laren and Mark can put that into a much nicer (clearer and more concise) wording! :-) Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- 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 ------------- Free downloads at www.winsnmp.com ------------- From owner-agentx@dorothy.bmc.com Tue Jul 6 11:32:41 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01650 for ; Tue, 6 Jul 1999 11:32:40 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id KAA03263; Tue, 6 Jul 1999 10:29:42 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA29599 for agentx-list; Tue, 6 Jul 1999 08:23:57 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA29594 for ; Tue, 6 Jul 1999 08:23:53 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id KAA01721 for ; Tue, 6 Jul 1999 10:23:52 -0500 (CDT) Received: from sigma.zk3.dec.com (sigma.zk3.dec.com [16.140.128.160]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id LAA07827 for ; Tue, 6 Jul 1999 11:23:50 -0400 (EDT) Received: from zk3.dec.com by sigma.zk3.dec.com (8.8.8/1.1.20.3/24Apr98-0811AM) id LAA0000010245; Tue, 6 Jul 1999 11:23:49 -0400 (EDT) Message-ID: <37821E0F.3CD4F032@zk3.dec.com> Date: Tue, 06 Jul 1999 11:17:35 -0400 From: Mike Daniele Organization: Compaq 64-bit UNIX networking X-Mailer: Mozilla 4.61 [en] (X11; I; OSF1 X5.0 alpha) X-Accept-Language: en MIME-Version: 1.0 To: AgentX WG Subject: Proposed Abstract Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Content-Transfer-Encoding: 7bit Abstract This memo defines a standardized framework for extensible SNMP agents. It defines processing entities called master agents and subagents, a protocol (AgentX) used to communicate between them, and the elements of procedure by which the extensible agent processes SNMP protocol messages. This memo replaces RFC 2257. From owner-agentx@dorothy.bmc.com Tue Jul 6 11:50:49 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02412 for ; Tue, 6 Jul 1999 11:50:48 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id KAA07602; Tue, 6 Jul 1999 10:47:39 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA29772 for agentx-list; Tue, 6 Jul 1999 08:47:29 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA29765 for ; Tue, 6 Jul 1999 08:47:23 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id KAA07542 for ; Tue, 6 Jul 1999 10:47:22 -0500 (CDT) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.117.200.23]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA584488; Tue, 6 Jul 1999 11:45:43 -0400 Received: from BLDVMA.boulder.ibm.com (bldvma.boulder.ibm.com [9.99.64.30]) by northrelay03.pok.ibm.com (8.8.8m2/NCO v2.03) with SMTP id LAA70354; Tue, 6 Jul 1999 11:45:52 -0400 Message-Id: <199907061545.LAA70354@northrelay03.pok.ibm.com> Received: by BLDVMA.boulder.ibm.com (IBM VM SMTP Level 310) via spool with SMTP id 6433 ; Tue, 06 Jul 1999 09:45:15 MDT Date: Tue, 6 Jul 99 17:43:33 DST From: "Bert Wijnen" To: daniele@zk3.dec.com, agentx@dorothy.bmc.com Subject: Proposed Abstract Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Ref: Your note of Tue, 06 Jul 1999 11:17:35 -0400 Subject: Re: Proposed Abstract Thanks, looks good, except... I would say that it "obsoletes" RFC2257 instead of replace. The term "obsoletes" is what the stds process uses in cases like this. Bert From owner-agentx@dorothy.bmc.com Tue Jul 6 11:51:10 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02439 for ; Tue, 6 Jul 1999 11:51:09 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id KAA07584; Tue, 6 Jul 1999 10:47:33 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA29763 for agentx-list; Tue, 6 Jul 1999 08:47:03 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA29758 for ; Tue, 6 Jul 1999 08:46:59 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id KAA07487 for ; Tue, 6 Jul 1999 10:46:58 -0500 (CDT) Received: from sigma.zk3.dec.com (sigma.zk3.dec.com [16.140.128.160]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id LAA09468; Tue, 6 Jul 1999 11:51:14 -0400 (EDT) Received: from zk3.dec.com by sigma.zk3.dec.com (8.8.8/1.1.20.3/24Apr98-0811AM) id LAA0000014729; Tue, 6 Jul 1999 11:46:53 -0400 (EDT) Message-ID: <37822377.C992B381@zk3.dec.com> Date: Tue, 06 Jul 1999 11:40:39 -0400 From: Mike Daniele Organization: Compaq 64-bit UNIX networking X-Mailer: Mozilla 4.61 [en] (X11; I; OSF1 X5.0 alpha) X-Accept-Language: en MIME-Version: 1.0 To: Bert Wijnen CC: lauren.heintz@cerent.com, agentx@dorothy.bmc.com Subject: Re: admin status (was Re: AgentX "WG Last Call", etc.) References: <199907051417.KAA33950@northrelay03.pok.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Content-Transfer-Encoding: 7bit >> > Subject: Re: AgentX "WG Last Call" for draft-ietf-agentx-mib-03.txt >> > >> > - I am surprised about agentxSessionAdminStatus. >> > Can the value "up" be SET via SNMP? I doubt it. >> > And after a set to "down", is the row then gone? >> > If so, then maybe a RowStatus is the better TC to use?? >> >> Mike Thatcher and I suggested this, I think at Chicago AgentX session, >> and I recall I mentioned this on the list even earlier than that. >> However, no one seemed thrilled about using RowStatus (didn't even get >> any head-nodding or your famous, mmmms) so I dropped the issue. And >> yes, "down" is equivalent to "destroy", and "up" can't be set via SNMP. >> >So... I would say RowStatus is probably best. >But in nay event, you should explain that 'up' cannot be SET. >And in the Compliance you should specify that too as a WRITE-SYNTAX >and then only list the 'down' value. RowStatus seems inappropriate to me for rows that can only be de-activated (as opposed to created and/or activated) by a SetRequest. I agree the description should state the only possible value to Set is 'down'. Mike From owner-agentx@dorothy.bmc.com Tue Jul 6 12:00:43 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02723 for ; Tue, 6 Jul 1999 12:00:42 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id KAA10151; Tue, 6 Jul 1999 10:58:04 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA29847 for agentx-list; Tue, 6 Jul 1999 08:57:43 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA29842 for ; Tue, 6 Jul 1999 08:57:39 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id KAA10026 for ; Tue, 6 Jul 1999 10:57:38 -0500 (CDT) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.117.200.23]) by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA148430 for ; Tue, 6 Jul 1999 11:55:56 -0400 Received: from BLDVMA.boulder.ibm.com (bldvma.boulder.ibm.com [9.99.64.30]) by northrelay03.pok.ibm.com (8.8.8m2/NCO v2.03) with SMTP id LAA47856 for ; Tue, 6 Jul 1999 11:56:04 -0400 Message-Id: <199907061556.LAA47856@northrelay03.pok.ibm.com> Received: by BLDVMA.boulder.ibm.com (IBM VM SMTP Level 310) via spool with SMTP id 6540 ; Tue, 06 Jul 1999 09:55:27 MDT Date: Tue, 6 Jul 99 17:53:46 DST From: "Bert Wijnen" To: daniele@zk3.dec.com cc: lauren.heintz@cerent.com, agentx@dorothy.bmc.com Subject: admin status (was Re: AgentX "WG Last Call", etc.) Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Ref: Your note of Tue, 06 Jul 1999 11:40:39 -0400 Subject: Re: admin status (was Re: AgentX "WG Last Call", etc.) RowStatus is even used for read-only tables in some cases. So I do not see why we cannot use it for destroying entries. And the nice thing is that with a WRITE-SYNTAX in the compliance section we can even explicitly state that we only support 'destroy' Bert From owner-agentx@dorothy.bmc.com Tue Jul 6 12:04:11 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02875 for ; Tue, 6 Jul 1999 12:04:10 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id KAA10154; Tue, 6 Jul 1999 10:58:04 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA29854 for agentx-list; Tue, 6 Jul 1999 08:57:51 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA29849 for ; Tue, 6 Jul 1999 08:57:45 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id KAA10049 for ; Tue, 6 Jul 1999 10:57:44 -0500 (CDT) Received: from sigma.zk3.dec.com (sigma.zk3.dec.com [16.140.128.160]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id LAA14664; Tue, 6 Jul 1999 11:57:42 -0400 (EDT) Received: from zk3.dec.com by sigma.zk3.dec.com (8.8.8/1.1.20.3/24Apr98-0811AM) id LAA0000016066; Tue, 6 Jul 1999 11:57:42 -0400 (EDT) Message-ID: <378225FF.BC1EB473@zk3.dec.com> Date: Tue, 06 Jul 1999 11:51:27 -0400 From: Mike Daniele Organization: Compaq 64-bit UNIX networking X-Mailer: Mozilla 4.61 [en] (X11; I; OSF1 X5.0 alpha) X-Accept-Language: en MIME-Version: 1.0 To: Bob Natale CC: Bert Wijnen , lauren.heintz@cerent.com, agentx@dorothy.bmc.com Subject: Re: AbentX MIB: maxTimeOut issue References: <4.1.19990705123306.0096b100@nips.acec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Content-Transfer-Encoding: 7bit Bob Natale wrote: > >At 7/5/99:12:14 PM, Bert Wijnen wrote: > > Hi Bert and Lauren, > > >Subject: Re: AgentX "WG Last Call", etc. > > I've changed the subject header to more clearly identify > this single issue: > > >> > - I would suggest that the various xxxTimeOut objects should > >> > have MAX-ACCESS of read-write. You would want a manager to > >> > be able to reset an excessive value requested by a subagent, no? I don't see the value in this. There is no way (via AgentX) for the subagent to know its requested timeout value was replaced by a new value. > > >> > Of course it is OK to put a MIN-ACCESS of read-only in the > >> > compliance section. > >> > >> agentxSessionTimeout and agentxRegTimeout (MAX-ACCESS, read-only) > >> descriptions indicate these values are reflective of the subagent > >> protocol element. So, do we want to be able to both report the protocol > >> elements AND be able to override them as you suggest? Might we instead > >> redefine the agentxDefaultTimeout so that it also defines a timeout > >> ceiling, or perhaps add a agentxMaxTimeout variable? Of course, if > >> reporting the protocol elements isn't essential, we could just change as > >> you suggested and rewrite the descriptions, etc.. > >> > >In my original (saMIB) I did have a ..MaxTimeOut, so that the > >NMS could limit the max timeout a subagent can use. Also.. I did > >allow a NMS to overwrite any value that a subagent had > >requested... just so a NMS can excercise control. > > Yes, I think [an interpretation of the agentxDefaultTimeout value as] > a maxTimeOut value is very useful. I do not think we should hold either > the NMS or the master agent hostage to a given sub-agent timeout value. That's a reasonable implementation, but it's unfortunately not reflected in the spec: From 7.2.1: 4) Timeout Values The master agent chooses a timeout value for each MIB region being queried, which is a) the value specified during registration of the MIB region, if it was non-zero b) otherwise, the value specified during establishment of the session in which this region was subsequently registered, if that value was non-zero c) otherwise, the master agent's implementaton-specific default value When an AgentX PDU that references multiple MIB regions is dispatched, the timeout value used for the PDU is the maximum value of the timeouts so determined for each of the referenced MIB regions. I think it would be reasonable to state that the above is SHOULD processing, but the master agent MAY select a different value (one choice being the master's default). Mike > > Of course, the sub-agent may still take as long as it needs to perform > its processing and this may well result in a timeout condition followed > by an "out-dated" response from the sub-agent that will just have to be > discarded...thus if either the sub-agent's requested timeout value and/or > its inability to respond within a user-specified amount of time (via the > NMS) is unacceptable in a given user scenario, we can expect market forces > to play their legitimate role. > > >See if MaxTimeOut is say 255 tpo begin with and a sub request 255 > >and then a NMS sets MaxTimeOut to say 10... do you then go automatically > >to reset all subagent values to max 10 too? > > That's what I would do...their really is no need to "reset" higher > sub-agent values to a lower master agent maxTimeOut value...the lower > value applies automatically in any case. In fact, you (i.e., the > master agent implementation) should not change the value requested > by the sub-agent...in setting the timer on any request to a sub- > agent, the master simply checks its notion of maxTimeOut versus > the sub's notion and applies the shorter. If the master's maxTimeOut > value is later changed to something higher than a given sub-agent's > requested timeout value, then that sub-agent's value applies on > requests to it. > > >or do you leave them in tact and only apply the max value for the > >new connections. Guess you could do so, because an NMS could always > >destroy (down) the connection and cause the sub to reconnect in whcih > >case the new MaxTimeout value would apply. > > I would not recommend that...it is unnecessary (see above) and would > be highly costly in terms of operational overhead and performance. > > >Anyway... it is not that I feel VERY STRONG about these things, > >I just brought it up, because I know I had this capability > >in my original saMIB (IBM enterprise specific MIB used with DPI). > > Right...I think we can just re-state the semantics of the > agentxDefaultTimeout object as applying a maxTimeOut value > as well. In other words, if a sub-agent does not specify > a specific timeout value, the agentxDefaultTimeout value will > be applied to requests to that sub-agent. If a sub-agent does > supply a specific timeout value and it is *less than* the > agentxDefaultTimeout value, then it will be used for such > requests. Otherwise, if it is higher than agentxDefaultTimeout, > then it will simply be retained for use should the value of > agentxDefaultTimeout be administratively increased to a value > higher than the sub-agent's specific timeout value. > > Assuming that basic interpretation is acceptable, I am > certain the Laren and Mark can put that into a much nicer > (clearer and more concise) wording! :-) > > Cordially, > > BobN > ------------ ISO 9001 Registered Quality Supplier ----------- > 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 > ------------- Free downloads at www.winsnmp.com ------------- From owner-agentx@dorothy.bmc.com Tue Jul 6 12:32:08 1999 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03661 for ; Tue, 6 Jul 1999 12:32:07 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id LAA16728; Tue, 6 Jul 1999 11:29:20 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA00211 for agentx-list; Tue, 6 Jul 1999 09:27:45 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA00206 for ; Tue, 6 Jul 1999 09:27:41 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id LAA16467 for ; Tue, 6 Jul 1999 11:27:39 -0500 (CDT) Received: from [38.249.211.2] (helo=relay1.acecomm.com) by relay1.smtp.psi.net with smtp (Exim 1.90 #1) id 111Y3Y-0004gL-00; Tue, 6 Jul 1999 12:26:52 -0400 Received: from bnatale by relay1.acecomm.com (SMI-8.6/SMI-SVR4) id MAA07243; Tue, 6 Jul 1999 12:35:40 -0400 Message-Id: <4.1.19990706122933.00a5e820@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 06 Jul 1999 12:30:56 -0400 To: Mike Daniele From: Bob Natale Subject: Re: AbentX MIB: maxTimeOut issue Cc: agentx@dorothy.bmc.com In-Reply-To: <378225FF.BC1EB473@zk3.dec.com> References: <4.1.19990705123306.0096b100@nips.acec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk >At 7/6/99:11:51 AM, Mike Daniele wrote: Hi Mike, <...> >> Yes, I think [an interpretation of the agentxDefaultTimeout value as] >> a maxTimeOut value is very useful. I do not think we should hold either >> the NMS or the master agent hostage to a given sub-agent timeout value. > >That's a reasonable implementation, but it's unfortunately not reflected in >the spec: >From 7.2.1: <...> >I think it would be reasonable to state that the above is SHOULD processing, >but the master agent MAY select a different value (one choice being the >master's default). I can certainly live with that. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- 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 ------------- Free downloads at www.winsnmp.com ------------- From owner-agentx@dorothy.bmc.com Tue Jul 6 12:51:35 1999 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04353 for ; Tue, 6 Jul 1999 12:51:34 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id LAA20624; Tue, 6 Jul 1999 11:47:42 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA00418 for agentx-list; Tue, 6 Jul 1999 09:47:23 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA00413 for ; Tue, 6 Jul 1999 09:47:18 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id LAA20543 for ; Tue, 6 Jul 1999 11:47:16 -0500 (CDT) Received: from pet1-104208 ([192.168.104.208] helo=cerent.com) by mailhost with esmtp (Exim 2.05 #2) id 111YG7-0003En-00; Tue, 6 Jul 1999 09:39:51 -0700 Message-ID: <3782315D.D4875A48@cerent.com> Date: Tue, 06 Jul 1999 09:39:57 -0700 From: Lauren Heintz Organization: Cerent Corporation X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Mike Daniele CC: Bert Wijnen , agentx@dorothy.bmc.com Subject: Re: admin status (was Re: AgentX "WG Last Call", etc.) References: <199907051417.KAA33950@northrelay03.pok.ibm.com> <37822377.C992B381@zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Content-Transfer-Encoding: 7bit Comments follow... Mike Daniele wrote: > > >> > Subject: Re: AgentX "WG Last Call" for draft-ietf-agentx-mib-03.txt > >> > > >> > - I am surprised about agentxSessionAdminStatus. > >> > Can the value "up" be SET via SNMP? I doubt it. > >> > And after a set to "down", is the row then gone? > >> > If so, then maybe a RowStatus is the better TC to use?? > >> > >> Mike Thatcher and I suggested this, I think at Chicago AgentX session, > >> and I recall I mentioned this on the list even earlier than that. > >> However, no one seemed thrilled about using RowStatus (didn't even get > >> any head-nodding or your famous, mmmms) so I dropped the issue. And > >> yes, "down" is equivalent to "destroy", and "up" can't be set via SNMP. > >> > >So... I would say RowStatus is probably best. > >But in nay event, you should explain that 'up' cannot be SET. > >And in the Compliance you should specify that too as a WRITE-SYNTAX > >and then only list the 'down' value. > > RowStatus seems inappropriate to me for rows that can only be de-activated > (as opposed to created and/or activated) by a SetRequest. But to quote from the RowStatus description clause in rfc1903: "The RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.7.1 of [2].)... " Seems that agentxSessionAdminStatus is just a constrained subset of the RowStatus capability, so RowStatus does apply. If not, then this description needs more clarification on when RowStatus is intended -- and not intended -- to be used. > > I agree the description should state the only possible value to Set is 'down'. > > Mike So, if a row has status of "up" (or "active"), does a SET request fail if it is setting the row status to the same value (whether that makes sense or not)? If we use RowStatus, then the SET should (according to the RowStatus state table in rfc1903) succeed. I think what we want to make sure we constrain is the notion that the new rows can be created via SNMP. Lauren From owner-agentx@dorothy.bmc.com Tue Jul 6 20:27:00 1999 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14205 for ; Tue, 6 Jul 1999 20:26:59 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id TAA21718; Tue, 6 Jul 1999 19:24:32 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA06812 for agentx-list; Tue, 6 Jul 1999 17:23:39 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA06803 for agentx@dorothy.bmc.com; Tue, 6 Jul 1999 17:23:35 -0700 (PDT) Date: Tue, 6 Jul 1999 17:23:35 -0700 (PDT) From: Randy Presuhn Message-Id: <199907070023.RAA06803@dorothy.bmc.com> To: agentx@dorothy.bmc.com Subject: Re: AbentX MIB: maxTimeOut issue Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi - > Date: Mon, 05 Jul 1999 12:50:58 -0400 > To: "Bert Wijnen" , lauren.heintz@cerent.com > From: Bob Natale > Subject: AbentX MIB: maxTimeOut issue > Cc: agentx@dorothy.bmc.com ... > Right...I think we can just re-state the semantics of the > agentxDefaultTimeout object as applying a maxTimeOut value > as well. In other words, if a sub-agent does not specify > a specific timeout value, the agentxDefaultTimeout value will > be applied to requests to that sub-agent. If a sub-agent does > supply a specific timeout value and it is *less than* the > agentxDefaultTimeout value, then it will be used for such > requests. Otherwise, if it is higher than agentxDefaultTimeout, > then it will simply be retained for use should the value of > agentxDefaultTimeout be administratively increased to a value > higher than the sub-agent's specific timeout value. ... PLEASE don't change the default to behave as a maximum. If you're convinced of the value of an agent-wide upper bound that can be controlled through SNMP, then add a new object dedicated to that function. ------------------------------------------------------------------------ Randy Presuhn rpresuhn@dorothy.bmc.com http://www.bmc.com/ Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ------------------------------------------------------------------------ Any relationship between my opinions and BMC's is probably coincidental. ------------------------------------------------------------------------ From owner-agentx@dorothy.bmc.com Wed Jul 7 11:16:09 1999 Received: from tangelo.bmc.com (fw-us-hou-2.bmc.com [198.207.223.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11282 for ; Wed, 7 Jul 1999 11:16:08 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id KAA25463; Wed, 7 Jul 1999 10:13:07 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA11292 for agentx-list; Wed, 7 Jul 1999 08:11:43 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA11286; Wed, 7 Jul 1999 08:11:38 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id KAA25095; Wed, 7 Jul 1999 10:11:37 -0500 (CDT) Received: from sigma.zk3.dec.com (sigma.zk3.dec.com [16.140.128.160]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id LAA30819; Wed, 7 Jul 1999 11:15:55 -0400 (EDT) Received: from zk3.dec.com by sigma.zk3.dec.com (8.8.8/1.1.20.3/24Apr98-0811AM) id LAA0000024254; Wed, 7 Jul 1999 11:11:33 -0400 (EDT) Message-ID: <37836CAE.A5E3BDCA@zk3.dec.com> Date: Wed, 07 Jul 1999 11:05:18 -0400 From: Mike Daniele Organization: Compaq 64-bit UNIX networking X-Mailer: Mozilla 4.61 [en] (X11; I; OSF1 X5.0 alpha) X-Accept-Language: en MIME-Version: 1.0 To: Randy Presuhn CC: agentx@dorothy.bmc.com Subject: Re: AbentX MIB: maxTimeOut issue References: <199907070023.RAA06803@dorothy.bmc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Content-Transfer-Encoding: 7bit Randy Presuhn wrote: > Hi - > > > Date: Mon, 05 Jul 1999 12:50:58 -0400 > > To: "Bert Wijnen" , lauren.heintz@cerent.com > > From: Bob Natale > > Subject: AbentX MIB: maxTimeOut issue > > Cc: agentx@dorothy.bmc.com > ... > > Right...I think we can just re-state the semantics of the > > agentxDefaultTimeout object as applying a maxTimeOut value > > as well. In other words, if a sub-agent does not specify > > a specific timeout value, the agentxDefaultTimeout value will > > be applied to requests to that sub-agent. If a sub-agent does > > supply a specific timeout value and it is *less than* the > > agentxDefaultTimeout value, then it will be used for such > > requests. Otherwise, if it is higher than agentxDefaultTimeout, > > then it will simply be retained for use should the value of > > agentxDefaultTimeout be administratively increased to a value > > higher than the sub-agent's specific timeout value. > ... > > PLEASE don't change the default to behave as a maximum. > If you're convinced of the value of an agent-wide upper > bound that can be controlled through SNMP, then add a > new object dedicated to that function. > I think the 3 timeout objects defined in the -03 MIB draft are correctly defined. I also think, as stated in previous mail, that we need to loosen the wording in the protocol spec around how timeouts are handled. But that wording should not state that the master's default must be an upper bound. (I just think that some master agent implementations will always honor the subagent's timeout values, and some won't, due to implementation considerations or other unforeseen external circumstances [like SNMP over TCP, or SNMPv4 messages that include a timeout value ...]). Mike From owner-agentx@dorothy.bmc.com Fri Jul 16 17:42:13 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09691 for ; Fri, 16 Jul 1999 17:42:13 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id QAA28812; Fri, 16 Jul 1999 16:36:03 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA14736 for agentx-list; Fri, 16 Jul 1999 14:31:40 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA14731 for ; Fri, 16 Jul 1999 14:31:34 -0700 (PDT) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id QAA28008 for ; Fri, 16 Jul 1999 16:31:33 -0500 (CDT) Received: from world.std.com (pm2b-46.dialup.jlc.net [199.201.159.46]) by verdi.jlc.net (8.9.1/8.9.0) with ESMTP id RAA13252; Fri, 16 Jul 1999 17:31:38 -0400 (EDT) Message-ID: <378FA4DB.D3B2D378@world.std.com> Date: Fri, 16 Jul 1999 17:32:11 -0400 From: Mark Ellison Organization: Ellison Software Consulting, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: agentx-email CC: Mark Ellison Subject: --- AgentX "WG Last Call" -- summary of issues --- Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Content-Transfer-Encoding: 7bit Hello folks- This email enumerates what I think the current issues are for the two AgentX WG I-Ds that are currently in last call. It appears that there are only three open issues, so I'll list those first. Comments and discussion (and resolution :-) are encouraged. Once we've converged on resolutions, I can edit these documents. Regards, Mark AgentX WG Editor ------------------ 1. (MIB) agentxSessionAdminStatus - leave as is, or - introduce a RowStatus and limit (in description) the possible state transitions (active->destroy)? 2. (MIB) xxxTimeOut objects - what should we use for MAX-ACCESS? - do we want a MIN-ACCESS in the compliance section? - (RFC) probably want to loosen text related to sub-agent timeout values in registrations- they are "suggestions"? - Do we need another MIB object (agentxMaxTimeout ?), or, is a change in the RFC sufficient without another MIB object? 3. add a range to the Unsigned32 indices so that a value of zero is excluded as a valid value. We do not want an index to be zero. - I think we've already run through this at the bake-off, and it seems that zero(0) is OK as a sessionID. Since sessionID is used as an Index, I don't think we want limit the index values further. ---- the rest of these are editorial things I've accounted for ---------- ---- but am listing here as a sanity check ------------------------------ 4. (MIB) we need to remove "experimental" from the abstract. - will do. 5. (MIB) change "SNMPv2 SMI" into "SMIv2" (multiple places) - will do. 6. (MIB) SNMPv1 in the abstract should read SMIv1. - will do. 7. (MIB) add a revision clause to the MODULE-IDENTITY. - will do. 8. (MIB) Maybe the references to MIB II (sysDescr) should be replaced with refenreces to RFC1907. - will do. 9. (MIB) Sect 7, ...read-create objects, - will adjust boilerplate. 10. (Proto) change Bert's info in section 11 - will do. 11. (Proto) missing Dale... - he's listed in sxn. 10, Acknowledgements...do we like the way this is currently, or, do we want to break Dale "out of the pack" for an extra-special-thanks? 12. (Proto) need an abstract, and it should say this I-D obsoletes 2257 - done. From owner-agentx@dorothy.bmc.com Thu Jul 29 14:42:21 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29958 for ; Thu, 29 Jul 1999 14:42:19 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id NAA04564; Thu, 29 Jul 1999 13:27:12 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA24361 for agentx-list; Thu, 29 Jul 1999 11:09:12 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA24356 for ; Thu, 29 Jul 1999 11:09:06 -0700 (PDT) From: ravinderv@future.futsoft.com Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id NAA00644 for ; Thu, 29 Jul 1999 13:09:05 -0500 (CDT) Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Thu, 29 Jul 1999 23:36:20 +0530 Received: from kamban.FsoftMadras.NDF.COM (kamban.fsoftmadras.ndf.com [192.168.254.10]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id XAA07575 for <@kailash:agentx@dorothy.bmc.com>; Thu, 29 Jul 1999 23:46:34 +0530 Received: from future.futsoft.com by kamban.FsoftMadras.NDF.COM; Thu, 29 Jul 99 18:46 EDT Received: by srinagar.FsoftMadras.ADF.COM with Microsoft Mail id <01BEDA1A.30779220@srinagar.FsoftMadras.ADF.COM>; Thu, 29 Jul 1999 23:29:23 +0530 Message-Id: <01BEDA1A.30779220@srinagar.FsoftMadras.ADF.COM> >From: future.futsoft.com!ravinderv (Ravinder Verma) To: agentx@dorothy.bmc.com ("'agentx@dorothy.bmc.com'") Subject: Hi !! Date: Thu, 29 Jul 1999 23:29:21 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, I have recently subscribed to this list. This is just a greeting mail to know that i have become active member of this list. Looking forward to hear from all on the list. Thanks, Ravinder. From owner-agentx@dorothy.bmc.com Thu Jul 29 14:47:52 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00242 for ; Thu, 29 Jul 1999 14:47:51 -0400 (EDT) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id NAA08132; Thu, 29 Jul 1999 13:43:02 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA25022 for agentx-list; Thu, 29 Jul 1999 11:42:13 -0700 (PDT) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA25017 for ; Thu, 29 Jul 1999 11:42:08 -0700 (PDT) From: ravinderv@future.futsoft.com Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id NAA07833 for ; Thu, 29 Jul 1999 13:42:06 -0500 (CDT) Received: from kailash.future.futsoft.com (unverified [203.197.140.36]) by fsnt.future.futsoft.com (Integralis SMTPRS 2.04) with ESMTP id ; Fri, 30 Jul 1999 00:01:39 +0530 Received: from kamban.FsoftMadras.NDF.COM (kamban.fsoftmadras.ndf.com [192.168.254.10]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id AAA07772 for <@kailash:agentx@dorothy.bmc.com>; Fri, 30 Jul 1999 00:11:54 +0530 Received: from future.futsoft.com by kamban.FsoftMadras.NDF.COM; Thu, 29 Jul 99 19:12 EDT Received: by srinagar.FsoftMadras.ADF.COM with Microsoft Mail id <01BEDA1D.B9B4E760@srinagar.FsoftMadras.ADF.COM>; Thu, 29 Jul 1999 23:54:41 +0530 Message-Id: <01BEDA1D.B9B4E760@srinagar.FsoftMadras.ADF.COM> >From: future.futsoft.com!ravinderv (Ravinder Verma) To: dorothy.bmc.com!agentx@kailash.future.futsoft.com ('agentx') Subject: Instance !!!! Date: Thu, 29 Jul 1999 23:54:40 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Could anyone elaborate the meaning "Fully Qualified instance and Partial instance while registration ". Thanks in advance ... Ravi.