From daniele@zk3.dec.com Tue Dec 2 15:14:17 1997 Received: from cashew.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA239754456 for ; Tue, 2 Dec 1997 15:14:16 -0800 Return-Path: Received: (from uucp@localhost) by cashew.bmc.com (8.8.6/8.8.6) id RAA28724 for ; Tue, 2 Dec 1997 17:14:14 -0600 (CST) Received: from mail11.digital.com(192.208.46.10) by cashew.bmc.com via smap (V2.0) id xma028716; Tue, 2 Dec 97 17:14:00 -0600 Received: from quarry.zk3.dec.com (brbquarry.zk3.dec.com [16.141.24.3]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id SAA19843 for ; Tue, 2 Dec 1997 18:08:44 -0500 (EST) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA22143; Tue, 2 Dec 1997 18:07:12 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA03390; Tue, 2 Dec 1997 18:02:53 -0500 Message-Id: <9712022302.AA03390@bernie.zk3.dec.com> To: agentx@peer.com Subject: Re: representing ranges (was: Re: Comments on agentx mib from 22 october) In-Reply-To: Your message of "Fri, 14 Nov 97 13:48:16 PST." <199711142148.AA071884095@dorothy.peer.com> Date: Tue, 02 Dec 97 18:02:53 -0500 From: Mike Daniele X-Mts: smtp Hi folks, Sorry for my lack of participation. I keep deleting any mail that isn't the AgentX RFC announcement... :-) Randy wrote: >The difference in our viewpoints appears to hinge on one word. You write >"equal"; I would have written "equivalent". In the former case, it would >make sense for the MIB to show the results of the application of the >"splitting" algorithm, and to permit the individual deregistration of the >bits and pieces that result from the application of that algorithm; in >the latter case, it makes sense for the MIB to report the registration >requests that have been accepted and for which deregistration requests >have not yet been received. > Aside: > As a practical matter, I think the "equal" interpretation > effectively requires implementations to internally use the > "splitting" algorithm, where the "equivalent" interpretation > allows implementations use other algorithms internally, as long > as they meet protocol requirements for registration handling. I agree. And since we don't require an implementation to "split" to do registration/dispatching, it makes little since to require the implementation to (virtually) "split" to implement the MIB. If we agree with this, then I think we arrive at a MIB to, as Randy said, "report the registration requests that have been accepted and for which deregistration requests have not yet been received". This seems like the natural course to me. I'm still not sure how to represent registration of ranges though. Are you (Shawn and Randy) saying this? for a.b.c, agentxRegStart = a.b.c, agentRegEnd = 0.0 for a.b.c.[d-e], Start = a.b.c.d, End = a.b.c.e for a.b.c.[d-e].f, we have multiple entries, start = a.b.c.d.f, end = 0.0 start =a.b.c.d+1.f, end = 0.0 ... start = a.b.c.e.f, end = 0.0 So agentRegEnd really is used to indicate the end of a range (unless the range is not on the last subid)... So while not "splitting", it is "exploding" some range registrations. This is certainly required if we're going to use OBJECT IDENTIFIER syntax for the objects. We could alternatively use OCTET STRING with a convention that range subids are represented "[a-b]" or something. then we'd REALLY be displaying exactly what was registered. (only half a smiley) >makes all possible retrieval scenarios equally onerous. I'd suggest >removing the agentxRegSessionIndex column and adding agentxSessionIndex >as the first index of agentxRegistrationEntry. This would at least make >it reasonably efficient to determine a given subagent's registrations, >and would not make the query to identify which subagent would handle >a given object identifier any worse. Agreed, that's about all we can do from an indexing standpoint. If we really want to facilitate finding which subagent would handle a given requested oid, we could define a writeable object of syntax OBJECT IDENTIFER, and one or two INTEGERs whose value is an index into this registration table. A manager writes the value of the oid, then reads the other 2. They are updated to contain the values of agentRegIndex and agentxSessionIndex for the registration entry that would currently be (initially) dispatched to, for that oid. Regards, Mike From daniele@zk3.dec.com Tue Dec 2 15:33:37 1997 Received: from cashew.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA259305616 for ; Tue, 2 Dec 1997 15:33:36 -0800 Return-Path: Received: (from uucp@localhost) by cashew.bmc.com (8.8.6/8.8.6) id RAA01271 for ; Tue, 2 Dec 1997 17:33:34 -0600 (CST) Received: from mail13.digital.com(192.208.46.30) by cashew.bmc.com via smap (V2.0) id xma001259; Tue, 2 Dec 97 17:33:22 -0600 Received: from quarry.zk3.dec.com (brbquarry.zk3.dec.com [16.141.24.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id SAA13140 for ; Tue, 2 Dec 1997 18:29:47 -0500 (EST) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA23870; Tue, 2 Dec 1997 18:28:15 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA30366; Tue, 2 Dec 1997 18:24:01 -0500 Message-Id: <9712022324.AA30366@bernie.zk3.dec.com> To: agentx@peer.com Subject: general comments Date: Tue, 02 Dec 97 18:24:01 -0500 From: Mike Daniele X-Mts: smtp Hi, and thanks for the efforts so far. These are based on mib-01.txt, and don't include the registration table, since we already ahve a thread for that. 1) The abstract has some wording about specifying a MIB module w/ v2 SMI, but that is semantically identical to v1 defs. What v1 defs? I guess I don't understand what this is trying to say. Also, note that we use the BITS syntax, which isn't v1-able... 2) The description of agentxMasterAgentXVer is confusing. There is no earlier version, so how can we require supporting one? Also, I think that decision is up to implementations, or when we have a new AgentX protocol version, perhaps in the protocol spec. But it doesn't make sense to have it here. 3) I agree w/ Shawn and others that agentxConnTransportAddr needs work. TDomain/TAddr seems ok for this application. 4) Table counters. I've never been much of a fan of scalars that count table entries. Do we really need a count of connections, sessions per connection, and total sessions? 5) Is the value of agentxSessionId the same as the sessionID field within the protocol? 6) I think we should remove any description of agentxSessionObjectID and SessionDescr, except to say they are defined in the protocol spec. 7) agentxSessionAdminstatus: "status of the subagent" should be "status of the session". 8) agentRegContext says a 0-length string is the default context. We explicitly avoided doing this in the protocol spec. Is it OK to assume so here? Regards, Mike From rpresuhn@peer.com Tue Dec 2 15:54:56 1997 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA011486896 for ; Tue, 2 Dec 1997 15:54:56 -0800 Date: Tue, 2 Dec 1997 15:54:56 -0800 From: Randy Presuhn Return-Path: Message-Id: <199712022354.AA011486896@dorothy.peer.com> To: agentx@peer.com Subject: Re: representing ranges (was: Re: Comments on agentx mib from 22 october) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Message-Id: <9712022302.AA03390@bernie.zk3.dec.com> > To: agentx@peer.com > Subject: Re: representing ranges (was: Re: Comments on agentx mib from 22 october) > Date: Tue, 02 Dec 97 18:02:53 -0500 > From: Mike Daniele > > Hi folks, > > Sorry for my lack of participation. I keep deleting any mail > that isn't the AgentX RFC announcement... :-) Any word on when this might happen? ... (agreement deleted) > I'm still not sure how to represent registration of ranges though. > Are you (Shawn and Randy) saying this? > > for a.b.c, agentxRegStart = a.b.c, agentRegEnd = 0.0 ok > for a.b.c.[d-e], Start = a.b.c.d, End = a.b.c.e ok > for a.b.c.[d-e].f, we have multiple entries, > > start = a.b.c.d.f, end = 0.0 > start =a.b.c.d+1.f, end = 0.0 > ... > start = a.b.c.e.f, end = 0.0 I hope not. I'd prefer start = a.b.c.d.f, end = a.b.c.e.f > So agentRegEnd really is used to indicate the end of a range > (unless the range is not on the last subid)... > > So while not "splitting", it is "exploding" some range registrations. I was only interested in using 0.0 for the ends of simple registrations in order to reduce the bandwidth needed to walk the table. If it ended up increasing the number of table entries, it would be a false economy. > This is certainly required if we're going to use OBJECT IDENTIFIER syntax > for the objects. I don't see how one would be driven to this conclusion. > We could alternatively use OCTET STRING with a convention that range > subids are represented "[a-b]" or something. then we'd REALLY be > displaying exactly what was registered. (only half a smiley) This would be fine for manager role systems presenting a synthesis of what the MIB variables report. It would use less bandwidth for retrievals than two full varbinds with OBJECT IDENTIFIER values. ... > If we really want to facilitate finding which subagent would handle a > given requested oid, we could define a writeable object of syntax > OBJECT IDENTIFER, and one or two INTEGERs whose value is an index > into this registration table. > > A manager writes the value of the oid, then reads the other 2. > They are updated to contain the values of agentRegIndex and agentxSessionIndex > for the registration entry that would currently be (initially) dispatched > to, for that oid. ... An object like this would need to be coupled with a test-and-increment or other advisory mutex to work in multiple-manager configurations. The other point to consider is that where an operation is dispatched to depends on the operation type. (Example: GET-NEXT may initiallly go someplace other than where GET would go if the INSTANCE_REGISTRATION bit was sent at registration time.) In any case, I don't think we need to add this capability. (But I'm still willing to listen to reason. :-) --------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA --------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." --------------------------------------------------------------------- From rpresuhn@peer.com Tue Dec 2 16:04:21 1997 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA033357461 for ; Tue, 2 Dec 1997 16:04:21 -0800 Date: Tue, 2 Dec 1997 16:04:21 -0800 From: Randy Presuhn Return-Path: Message-Id: <199712030004.AA033357461@dorothy.peer.com> To: agentx@peer.com Subject: INSTANCE_REGISTRATION in agentx MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - Mike's message earlier today caused me to realize that the current agentx MIB does not allow a manager to determine whether the INSTANCE_REGISTRATION bit was set for a particular registration. I suggest we add something like this to AgentxRegistrationEntry: agentxRegInstance OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The value of agentxRegInstance is `true' for registrations for which the INSTANCE_REGISTRATION was set, and is `false' for all other registrations." DEFVAL { false } ::= { agentxRegistrationEntry xxx } --------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA --------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." --------------------------------------------------------------------- From rpresuhn@peer.com Tue Dec 2 16:45:33 1997 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA091489933 for ; Tue, 2 Dec 1997 16:45:33 -0800 Date: Tue, 2 Dec 1997 16:45:33 -0800 From: Randy Presuhn Return-Path: Message-Id: <199712030045.AA091489933@dorothy.peer.com> To: agentx@peer.com Subject: Re: general comments Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - (Smitha's on vacation; I'm sure she'll have more to say on this when she returns. Meanwhile, our sysadmin is watching in horror as her mailbox grows. :-) > Message-Id: <9712022324.AA30366@bernie.zk3.dec.com> > To: agentx@peer.com > Subject: general comments > Date: Tue, 02 Dec 97 18:24:01 -0500 > From: Mike Daniele ... > 1) The abstract has some wording about specifying a MIB module > w/ v2 SMI, but that is semantically identical to v1 defs. > > What v1 defs? I guess I don't understand what this is trying > to say. Also, note that we use the BITS syntax, which isn't > v1-able... I think the intent was to reflect words that appear in other MIBs to reassure folks that even though we use v2 SMI, the information is all accessible in v1 protocol. BITS works nicely in v1 protocol, and is just an OCTET STRING in v1 SMI. It wouldn't bother me if the paragraph were deleted. > 2) The description of agentxMasterAgentXVer is confusing. > > There is no earlier version, so how can we require supporting one? > > Also, I think that decision is up to implementations, or when we > have a new AgentX protocol version, perhaps in the protocol spec. > But it doesn't make sense to have it here. Agreed. It would be useful to be able to determine the set of supported protocols. If this object is retained, it might make more sense for it to be BITS, with the set positions corresponding to the supported values from h.version from the protocol specification. > 3) I agree w/ Shawn and others that agentxConnTransportAddr > needs work. TDomain/TAddr seems ok for this application. Agreed. > 4) Table counters. I've never been much of a fan of scalars > that count table entries. Do we really need a count of connections, > sessions per connection, and total sessions? Agreed. They're useful in cases where changes in the number of entries can be used to trigger more extensive polling. For the uses I've seen for MIBs like this, the decision to scan the tables are generally not made on the basis of a change to the number of table entries. They might be useful in fine-tuning a GET-BULK request. Does anyone really want these? > 5) Is the value of agentxSessionId the same as the sessionID field > within the protocol? The value of agentxSessionIndex should map to the value of h.sessionID used for a given session. The non-reuse requirements for the MIB index are stricter than those for the protocol field. (Aside: why does the protocol require that h.sessionID be given values unique across all of a master agent's transports? The logical requirement for uniqueness ends at the level of a transport connection.) > 6) I think we should remove any description of agentxSessionObjectID > and SessionDescr, except to say they are defined in the protocol spec. At a formal level I agree, but from the perspective of the person reading MIBs or using browsers, I think we should go the other direction, and make these DESCRIPTIONs more self-contained, though the pointers should be retained.. > 7) agentxSessionAdminstatus: "status of the subagent" should > be "status of the session". Yup. > 8) agentRegContext says a 0-length string is the default context. > > We explicitly avoided doing this in the protocol spec. Is it > OK to assume so here? ... I think this falls in line with what Bob Natale wrote about aligning things (like field lengths and UTF-8 usage) with the SNMPv3 way of doing things. We left much of the context stuff wide open in the protocol spec because we didn't what path SNMPv3 would take. In this particular case, the zero-length string convention seems safe to me; it has been with us since the latter days of SNMPv2 and has been non-contentious. I see the entity MIB working group is coming back to life. This would be a good time to harmonize these. --------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA --------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." --------------------------------------------------------------------- From daniele@zk3.dec.com Wed Dec 3 11:53:26 1997 Received: from cashew.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA037858805 for ; Wed, 3 Dec 1997 11:53:25 -0800 Return-Path: Received: (from uucp@localhost) by cashew.bmc.com (8.8.6/8.8.6) id NAA14173 for ; Wed, 3 Dec 1997 13:53:13 -0600 (CST) Received: from mail12.digital.com(192.208.46.20) by cashew.bmc.com via smap (V2.0) id xma014140; Wed, 3 Dec 97 13:52:52 -0600 Received: from quarry.zk3.dec.com (brbquarry.zk3.dec.com [16.141.24.3]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id OAA24715 for ; Wed, 3 Dec 1997 14:49:01 -0500 (EST) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA19410; Wed, 3 Dec 1997 14:48:58 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA12311; Wed, 3 Dec 1997 14:45:53 -0500 Message-Id: <9712031945.AA12311@bernie.zk3.dec.com> To: agentx@peer.com Subject: Re: INSTANCE_REGISTRATION in agentx MIB In-Reply-To: Your message of "Tue, 02 Dec 97 16:04:21 PST." <199712030004.AA033357461@dorothy.peer.com> Date: Wed, 03 Dec 97 14:45:53 -0500 From: Mike Daniele X-Mts: smtp >I suggest we add something like this to AgentxRegistrationEntry: > agentxRegInstance OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of agentxRegInstance is `true' for > registrations for which the INSTANCE_REGISTRATION > was set, and is `false' for all other registrations." > DEFVAL { false } > ::= { agentxRegistrationEntry xxx } Good catch! Can we name the object agentxRegIsInstance? "Instance" is a loaded term... Mike From rpresuhn@peer.com Wed Dec 3 13:29:49 1997 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA070174589 for ; Wed, 3 Dec 1997 13:29:49 -0800 Date: Wed, 3 Dec 1997 13:29:49 -0800 From: Randy Presuhn Return-Path: Message-Id: <199712032129.AA070174589@dorothy.peer.com> To: agentx@peer.com Subject: Re: INSTANCE_REGISTRATION in agentx MIB Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Message-Id: <9712031945.AA12311@bernie.zk3.dec.com> > To: agentx@peer.com > Subject: Re: INSTANCE_REGISTRATION in agentx MIB > Date: Wed, 03 Dec 97 14:45:53 -0500 > From: Mike Daniele ... > Good catch! Can we name the object agentxRegIsInstance? ... Sounds good to me. --------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA --------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." --------------------------------------------------------------------- From bnatale@acecomm.com Wed Dec 3 13:55:08 1997 Received: from cashew.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA095226107 for ; Wed, 3 Dec 1997 13:55:07 -0800 Return-Path: Received: (from uucp@localhost) by cashew.bmc.com (8.8.6/8.8.6) id PAA22347; Wed, 3 Dec 1997 15:54:57 -0600 (CST) Received: from relay1.smtp.psi.net(38.8.14.2) by cashew.bmc.com via smap (V2.0) id xma022336; Wed, 3 Dec 97 15:54:52 -0600 Received: from nips.acec.com by relay1.smtp.psi.net (8.8.5/SMI-5.4-PSI) id QAA04918; Wed, 3 Dec 1997 16:53:43 -0500 (EST) Received: from bnatale by nips.acec.com (5.65/3.2.083191-ACE*COMM) id AA27732; Wed, 3 Dec 1997 16:53:27 -0500 Message-Id: <3.0.5.32.19971203165537.00958940@nips.acecomm.com> X-Sender: natale@nips.acecomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 03 Dec 1997 16:55:37 -0500 To: Randy Presuhn From: Bob Natale Subject: AgentX status Cc: agentx@peer.com In-Reply-To: <199712022354.AA011486896@dorothy.peer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 03:54 PM 12/2/97 -0800, Randy Presuhn wrote: Hi Randy, everyone: <...> >> Sorry for my lack of participation. I keep deleting any mail >> that isn't the AgentX RFC announcement... :-) > >Any word on when this might happen? I wish I could give you all a solid answer on this, but I can't. Here's a synopsis of what has transpired to date, as far as I know it and as best I can represent it in this context: We did the Area Review (thanks Cheryl...thanks Deirdre) and issued the completed I-D on 6/10. We had the hand-off to the new AD, John Curran. Some time passed. Several e-mails requesting progres were send from me to John. John and I eventually had a telechat (on 8/29) about the spec and the results of the Area Review. The outcome of this telechat was positive. The spec than went to IESG Last Call (on 9/3, with a cut-off for comments of 9/12, if I recall correctly). Some time passed. Several e-mails requesting progress were sent from me (and others) to John (and others). The IESG Secretariat (Steve Coya) informed me, on 10/24, that AgentX was in the final stage of the IESG process, waiting for the AD to submit the Protocol Action text. I asked John about that (via e-mail) and he suggested we have another telechat...which we did on 11/7 (Friday). During that telechat, John said that the suggestion had been raised during the Last Call (which expired on 9/12, recall) that the WG was either mis-chartered and/or the scope/limitations of the protocol--clearly stated in Secs. 3.1 thru 4.4, I believe--did not actually reflect the WG's consensus. I stated that I found that claim extremely surprising. We discussed that and some other comparatively minor issues, during which I provided assurances and recollections to the contrary and promised to follow-up with some archival material (for back-up purposes). John said he saw no further problems at that time and hoped to have the Protocol Action Announcement out "by Tuesday" and "within 72 hours" (both comments made in fairly close temporal proximity during the concluding moments of the telechat). We both stated during the telechat and in prior e-mails that we would like to see the Protocol Action published before the Dec IETF meeting. Since then--despite several e-mail requests for progress--I have heard nothing. I would like to emphasize three things here: 1. For a variety of reasons, John has been *extremely* busy with his real life during this entire period, and when we actually have been able to work together on AgentX he has been *extremely* positive and impressively professional in all respects. 2. The authors and editor have done much additional work to help further the IESG process along. I am sure this long delay and lack of visible progress is highly demoralizing for them. 3. I at my wit's end on this thing. I care about the time/effort/talent the authors and editor have contributed; ditto for the people trying to move forward with the related MIB task; ditto for the people who have been working on their implementations and providing valuable feedback; and ditto for everyone who contributed positively to the WG's deliberation's via the list and at the f2f meetings over the years. I am doing my best to ensure that my many less desirable personality traits don't cause me to do anything at this stage to jeopardize the investments in AgentX that all those folks have made. But I am definitely in a foul mood over the current state of affairs. Peace, love, and understanding, 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 ---- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ---- ------ NetPlus (r) "FCAPS" Telemanagement Applications ------ From daniele@zk3.dec.com Wed Dec 3 13:54:30 1997 Received: from cashew.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA095176069 for ; Wed, 3 Dec 1997 13:54:29 -0800 Return-Path: Received: (from uucp@localhost) by cashew.bmc.com (8.8.6/8.8.6) id PAA22324 for ; Wed, 3 Dec 1997 15:54:27 -0600 (CST) Received: from mail11.digital.com(192.208.46.10) by cashew.bmc.com via smap (V2.0) id xma022312; Wed, 3 Dec 97 15:54:09 -0600 Received: from quarry.zk3.dec.com (brbquarry.zk3.dec.com [16.141.24.3]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id QAA29607 for ; Wed, 3 Dec 1997 16:27:13 -0500 (EST) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA14134; Wed, 3 Dec 1997 16:27:08 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA12398; Wed, 3 Dec 1997 16:24:09 -0500 Message-Id: <9712032124.AA12398@bernie.zk3.dec.com> To: agentx@peer.com Subject: Re: representing ranges (was: Re: Comments on agentx mib from 22 october) In-Reply-To: Your message of "Tue, 02 Dec 97 15:54:56 PST." <199712022354.AA011486896@dorothy.peer.com> Date: Wed, 03 Dec 97 16:24:09 -0500 From: Mike Daniele X-Mts: smtp Hi Randy, >> Sorry for my lack of participation. I keep deleting any mail >> that isn't the AgentX RFC announcement... :-) >Any word on when this might happen? No. John Curran had sent Bob N a few questions about the spec about a month ago, but my understanding was that everything was a go. The IESG is pretty backlogged. >> This is certainly required if we're going to use OBJECT IDENTIFIER syntax >> for the objects. >I don't see how one would be driven to this conclusion. I was driven there by my understanding of the proposed usage of agentxRegEnd. If it is used to denote the end of a range (as you suggest), then all is well. If it used instead to denote the implied end of a registered region (as I thought Shawn was suggesting), then we still have to deal with a range subid. Since the range subid can't be expressed in OBJECT IDENTIFIER, I concluded that we either have to explode the range (as I thought Shawn's mail was suggesting), or represent the registration as octet string. >> for a.b.c.[d-e].f, we have multiple entries, >> >> start = a.b.c.d.f, end = 0.0 >> start =a.b.c.d+1.f, end = 0.0 >> ... >> start = a.b.c.e.f, end = 0.0 >I hope not. I'd prefer > start = a.b.c.d.f, end = a.b.c.e.f That's fine with me. So perhaps agentxRegEnd should be renamed agentxRegRangeEnd, since we'll be using it explcitly to denote the end of a range (as opposed to the implied end of a region, as discussed in the protocol spec). >> A manager writes the value of the oid, then reads the other 2. >> They are updated to contain the values of agentRegIndex and agentxSessionIndex >> for the registration entry that would currently be (initially) dispatched >> to, for that oid. >The other point to consider is that where an operation is dispatched >to depends on the operation type. (Example: GET-NEXT may initiallly >go someplace other than where GET would go if the INSTANCE_REGISTRATION >bit was sent at registration time.) >In any case, I don't think we need to add this capability. (But I'm >still willing to listen to reason. :-) I think it would be very useful. In complicated configurations (with many overlapped registrations at many levels, etc) it could be quite difficult to determine how dispatching works, just by retrieving the registration table. You're right about get-next vs get. I think if we specified that the objects' values are the indexes for the registration that would be dispatched to on a GET, it would be clear, and still very helpful. It's no additional cost to the agent, it already has to have such a function. Mike From daniele@zk3.dec.com Wed Dec 3 14:31:14 1997 Received: from almond.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA119838273 for ; Wed, 3 Dec 1997 14:31:13 -0800 Return-Path: Received: (from uucp@localhost) by almond.bmc.com (8.8.6/8.8.6) id QAA18731 for ; Wed, 3 Dec 1997 16:31:11 -0600 (CST) Received: from mail11.digital.com(192.208.46.10) by almond.bmc.com via smap (V2.0) id xma018715; Wed, 3 Dec 97 16:31:07 -0600 Received: from quarry.zk3.dec.com (brbquarry.zk3.dec.com [16.141.24.3]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id RAA04217 for ; Wed, 3 Dec 1997 17:15:21 -0500 (EST) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA19200; Wed, 3 Dec 1997 17:15:20 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA12512; Wed, 3 Dec 1997 17:12:17 -0500 Message-Id: <9712032212.AA12512@bernie.zk3.dec.com> To: agentx@peer.com Subject: Re: general comments In-Reply-To: Your message of "Tue, 02 Dec 97 16:45:33 PST." <199712030045.AA091489933@dorothy.peer.com> Date: Wed, 03 Dec 97 17:12:16 -0500 From: Mike Daniele X-Mts: smtp Hi Randy, >> 5) Is the value of agentxSessionId the same as the sessionID field >> within the protocol? >The value of agentxSessionIndex should map to the value of h.sessionID >used for a given session. The non-reuse requirements for the MIB index >are stricter than those for the protocol field. OK. > (Aside: why does the >protocol require that h.sessionID be given values unique across all of >a master agent's transports? The logical requirement for uniqueness >ends at the level of a transport connection.) We had specific requests to make sessionID unique across all transports, so that implementations could do a much transport-independent work as possible. >> 8) agentRegContext says a 0-length string is the default context. >> >> We explicitly avoided doing this in the protocol spec. Is it >> OK to assume so here? >... >I think this falls in line with what Bob Natale wrote about aligning >things (like field lengths and UTF-8 usage) with the SNMPv3 way of doing >things. We left much of the context stuff wide open in the protocol >spec because we didn't what path SNMPv3 would take. In this particular >case, the zero-length string convention seems safe to me; it has been >with us since the latter days of SNMPv2 and has been non-contentious. Pardon my v3 ignorance, but zero-length == default in v3, right? OK then :-) Mike From rpresuhn@peer.com Wed Dec 3 15:04:28 1997 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA173030268 for ; Wed, 3 Dec 1997 15:04:28 -0800 Date: Wed, 3 Dec 1997 15:04:28 -0800 From: Randy Presuhn Return-Path: Message-Id: <199712032304.AA173030268@dorothy.peer.com> To: agentx@peer.com Subject: Re: representing ranges (was: Re: Comments on agentx mib from 22 october) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Message-Id: <9712032124.AA12398@bernie.zk3.dec.com> > To: agentx@peer.com > Subject: Re: representing ranges (was: Re: Comments on agentx mib from 22 october) > Date: Wed, 03 Dec 97 16:24:09 -0500 > From: Mike Daniele ... > I was driven there by my understanding of the proposed usage of agentxRegEnd. > If it is used to denote the end of a range (as you suggest), then > all is well. If it used instead to denote the implied end of a > registered region (as I thought Shawn was suggesting), then we still have > to deal with a range subid. Since the range subid can't > be expressed in OBJECT IDENTIFIER, I concluded that we either have to > explode the range (as I thought Shawn's mail was suggesting), or represent > the registration as octet string. The point is that we have a PAIR of object indentifiers in the MIB; for a well-formed registration request (the only kind that should result in a table entry :-) these two object identifiers would differ in at most one object identifier component. Both regions and ranges can be covered by this representation. I do agree that a string representation of the pattern would probably be more useful to humans. > >> for a.b.c.[d-e].f, we have multiple entries, > >> > >> start = a.b.c.d.f, end = 0.0 > >> start =a.b.c.d+1.f, end = 0.0 > >> ... > >> start = a.b.c.e.f, end = 0.0 > > >I hope not. I'd prefer > > start = a.b.c.d.f, end = a.b.c.e.f > > That's fine with me. So perhaps agentxRegEnd should be renamed > agentxRegRangeEnd, since we'll be using it explcitly to denote the > end of a range (as opposed to the implied end of a region, as discussed > in the protocol spec). I'm missing something here. By comparing a.b.c.d.f and a.b.c.e.f, a manager can determine that the region is a.b.c.[d-e].f This seems to me to be aligned with the terminology in the protocol spec clause 6.2.3 for registration of regions. ... > I think it would be very useful. In complicated configurations > (with many overlapped registrations at many levels, etc) it could be > quite difficult to determine how dispatching works, just by retrieving > the registration table. This begs the question of whether the MIB implementation can produce the same result as the actual dispatcher. In systems supporting multiple subagent protocols (with an internally unified registration/priority resolution mechanism) the "best" AgentX subagent for handling an SNMP varbind is not necessarily the best of all the known subagents for that varbind. I imagine we are not the only vendor with motivation to support multiple subagent protocols concurrently. This work doesn't need to model what folks like us are doing, but it shouldn't preclude it. > You're right about get-next vs get. I think if we specified that the > objects' values are the indexes for the registration that would be > dispatched to on a GET, it would be clear, and still very helpful. > > It's no additional cost to the agent, it already has to have > such a function. ... We'd also have to note that the result would identify the likely AgentX subagent, or else provide some way of indicating that the responsible subagent is not an AgentX subagent. I'm still skeptical about the value of this, but I'm still listening. --------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA --------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." --------------------------------------------------------------------- From rpresuhn@peer.com Wed Dec 3 15:18:38 1997 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA188371118 for ; Wed, 3 Dec 1997 15:18:38 -0800 Date: Wed, 3 Dec 1997 15:18:38 -0800 From: Randy Presuhn Return-Path: Message-Id: <199712032318.AA188371118@dorothy.peer.com> To: agentx@peer.com Subject: Re: general comments Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Message-Id: <9712032212.AA12512@bernie.zk3.dec.com> > To: agentx@peer.com > Subject: Re: general comments > Date: Wed, 03 Dec 97 17:12:16 -0500 > From: Mike Daniele ... > >> 8) agentRegContext says a 0-length string is the default context. ... > Pardon my v3 ignorance, but zero-length == default in v3, right? > > OK then :-) OK! See page 18 in the definition of vacmContextName. Although the architecture defines "contextName" as a piece of information relevant to the abstract service interfaces, the "zero-length == default" semantic is defined in VACM. This was probably an oversight. We'll see whether this is a problem when we get to the entity mib work. --------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA --------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." --------------------------------------------------------------------- From mdevlin@eltrax.com Thu Dec 4 06:17:41 1997 Received: from almond.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA121285060 for ; Thu, 4 Dec 1997 06:17:40 -0800 Return-Path: Received: (from uucp@localhost) by almond.bmc.com (8.8.6/8.8.6) id IAA22828; Thu, 4 Dec 1997 08:17:38 -0600 (CST) Received: from mail.htconn.com(38.245.21.2) by almond.bmc.com via smap (V2.0) id xma022803; Thu, 4 Dec 97 08:17:07 -0600 Received: from unknown by mail.htconn.com (SMI-8.6/SMI-SVR4) id JAA23240; Thu, 4 Dec 1997 09:12:21 -0500 From: mdevlin@eltrax.com (T. Max Devlin) To: Randy Presuhn Cc: agentx@peer.com Subject: Re: representing ranges (was: Re: Comments on agentx mib from 22 october) Date: Thu, 04 Dec 1997 14:09:59 GMT Organization: Eltrax Systems/Hi-TECH Connections Message-Id: <3486b87e.2929971@mail.htconn.com> References: <199712032304.AA173030268@dorothy.peer.com> In-Reply-To: <199712032304.AA173030268@dorothy.peer.com> X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, all. I hope this mssg hits the list; I'm in the midst of changing email identities, and some of the mailing lists are getting picky about who can send stuff. Let me know if you don't receive this... ;-) Randy Presuhn said: >Hi - > [...] >> >> for a.b.c.[d-e].f, we have multiple entries, >> >> >> >> start = a.b.c.d.f, end = 0.0 >> >> start =a.b.c.d+1.f, end = 0.0 >> >> ... >> >> start = a.b.c.e.f, end = 0.0 >> >> >I hope not. I'd prefer >> > start = a.b.c.d.f, end = a.b.c.e.f >> >> That's fine with me. So perhaps agentxRegEnd should be renamed >> agentxRegRangeEnd, since we'll be using it explcitly to denote the >> end of a range (as opposed to the implied end of a region, as discussed >> in the protocol spec). > >I'm missing something here. By comparing a.b.c.d.f and a.b.c.e.f, >a manager can determine that the region is a.b.c.[d-e].f This seems >to me to be aligned with the terminology in the protocol spec clause >6.2.3 for registration of regions. > >... I haven't been paying too much attention to details the last few months, so I'm confused. Please forgive, and show me where I got lost. Does agentx support instance registration (registering for a single row of a table)? If so, the start=a.b.c.d.f, end=a.b.c.e.f is not possible. Or is there something about the syntax of how you represent the OIDs that I'm missing? Wouldn't this entry also include a.b.c.d.[ j | k | l |{...}], as well as a.b.c.e.[ a | b | c | d | e]? What am I missing? -- T. Max Devlin Hi-TECH Connections/Eltrax Systems ***************************************************** - Opinions expressed are my own. Anyone else may use them only in accordance with licensing agreements. - From mdevlin@eltrax.com Thu Dec 4 06:18:40 1997 Received: from almond.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA121335119 for ; Thu, 4 Dec 1997 06:18:39 -0800 Return-Path: Received: (from uucp@localhost) by almond.bmc.com (8.8.6/8.8.6) id IAA22881; Thu, 4 Dec 1997 08:18:38 -0600 (CST) Received: from mail.htconn.com(38.245.21.2) by almond.bmc.com via smap (V2.0) id xma022872; Thu, 4 Dec 97 08:18:32 -0600 Received: from unknown by mail.htconn.com (SMI-8.6/SMI-SVR4) id JAA23243; Thu, 4 Dec 1997 09:13:54 -0500 From: mdevlin@eltrax.com (T. Max Devlin) To: Randy Presuhn Cc: agentx@peer.com Subject: Re: INSTANCE_REGISTRATION in agentx MIB Date: Thu, 04 Dec 1997 14:11:33 GMT Organization: Eltrax Systems/Hi-TECH Connections Message-Id: <3487b9f7.3307755@mail.htconn.com> References: <199712030004.AA033357461@dorothy.peer.com> In-Reply-To: <199712030004.AA033357461@dorothy.peer.com> X-Mailer: Forte Agent 1.5/32.451 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Well, you've answered my previous question before I even asked it! Sorry for the bother; I believe this clears it up. Randy Presuhn said: >Hi - > >Mike's message earlier today caused me to realize that the current >agentx MIB does not allow a manager to determine whether the >INSTANCE_REGISTRATION bit was set for a particular registration. > >I suggest we add something like this to AgentxRegistrationEntry: > > agentxRegInstance OBJECT-TYPE > SYNTAX TruthValue > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The value of agentxRegInstance is `true' for > registrations for which the INSTANCE_REGISTRATION > was set, and is `false' for all other registrations." > DEFVAL { false } > ::= { agentxRegistrationEntry xxx } > > --------------------------------------------------------------------- > Randy Presuhn BMC Software, Inc. (Silicon Valley Division) > Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com > Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 > Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA > --------------------------------------------------------------------- > In accordance with the BMC Communications Systems Use and Security > Policy memo dated December 10, 1996, page 2, item (g) (the first of > two), I explicitly state that although my affiliation with BMC may be > apparent, implied, or provided, my opinions are not necessarily those > of BMC Software and that all external representations on behalf of > BMC must first be cleared with a member of "the top management team." > --------------------------------------------------------------------- -- T. Max Devlin Hi-TECH Connections/Eltrax Systems ***************************************************** - Opinions expressed are my own. Anyone else may use them only in accordance with licensing agreements. - From bnatale@acecomm.com Thu Dec 4 07:26:42 1997 Received: from almond.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA123899201 for ; Thu, 4 Dec 1997 07:26:41 -0800 Return-Path: Received: (from uucp@localhost) by almond.bmc.com (8.8.6/8.8.6) id JAA29166 for ; Thu, 4 Dec 1997 09:26:39 -0600 (CST) Received: from relay1.smtp.psi.net(38.8.14.2) by almond.bmc.com via smap (V2.0) id xma029150; Thu, 4 Dec 97 09:26:27 -0600 Received: from nips.acec.com by relay1.smtp.psi.net (8.8.5/SMI-5.4-PSI) id KAA24140; Thu, 4 Dec 1997 10:25:56 -0500 (EST) Received: from bnatale by nips.acec.com (5.65/3.2.083191-ACE*COMM) id AA08628; Thu, 4 Dec 1997 10:25:10 -0500 Message-Id: <3.0.5.32.19971204102717.00948820@nips.acecomm.com> X-Sender: natale@nips.acecomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 04 Dec 1997 10:27:17 -0500 To: mdevlin@eltrax.com (T. Max Devlin) From: Bob Natale Subject: Re: representing ranges (was: Re: Comments on agentx mib from 22 october) Cc: agentx@peer.com In-Reply-To: <3486b87e.2929971@mail.htconn.com> References: <199712032304.AA173030268@dorothy.peer.com> <199712032304.AA173030268@dorothy.peer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 02:09 PM 12/4/97 GMT, you wrote: Hi Max, >Hi, all. I hope this mssg hits the list; I'm in the midst of >changing email identities, and some of the mailing lists are >getting picky about who can send stuff. Let me know if you don't >receive this... ;-) Yes, it reached me via the list. You might want to drop a note to agentx-request@peer.com (will be read by a human) if you think your subscription record should be changed to your new mailer domain. The easiest way is to send an "unsubscribe " msg and then a "subcribe " msg, if that can work. <...> >I haven't been paying too much attention to details the last few >months, so I'm confused. Please forgive, and show me where I got >lost. Does agentx support instance registration (registering >for a single row of a table)? Yes. >If so, the start=a.b.c.d.f, end=a.b.c.e.f is not possible. Or >is there something about the syntax of how you represent the >OIDs that I'm missing? <...> I didn't really understand your example very well, but I think that either the instance_registration bit and/or identical start/end entries would handle the case. 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 ---- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ---- ------ NetPlus (r) "FCAPS" Telemanagement Applications ------ From daniele@zk3.dec.com Thu Dec 4 14:56:28 1997 Received: from cashew.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA010026186 for ; Thu, 4 Dec 1997 14:56:26 -0800 Return-Path: Received: (from uucp@localhost) by cashew.bmc.com (8.8.6/8.8.6) id QAA01029 for ; Thu, 4 Dec 1997 16:56:23 -0600 (CST) Received: from mail13.digital.com(192.208.46.30) by cashew.bmc.com via smap (V2.0) id xma000999; Thu, 4 Dec 97 16:55:56 -0600 Received: from quarry.zk3.dec.com (brbquarry.zk3.dec.com [16.141.24.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id RAA06708 for ; Thu, 4 Dec 1997 17:41:51 -0500 (EST) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA30016; Thu, 4 Dec 1997 17:41:50 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA12912; Thu, 4 Dec 1997 17:38:51 -0500 Message-Id: <9712042238.AA12912@bernie.zk3.dec.com> To: agentx@peer.com Subject: Re: representing ranges (was: Re: Comments on agentx mib from 22 october) In-Reply-To: Your message of "Wed, 03 Dec 97 15:04:28 PST." <199712032304.AA173030268@dorothy.peer.com> Date: Thu, 04 Dec 97 17:38:50 -0500 From: Mike Daniele X-Mts: smtp Hi Randy, >> That's fine with me. So perhaps agentxRegEnd should be renamed >> agentxRegRangeEnd, since we'll be using it explcitly to denote the >> end of a range (as opposed to the implied end of a region, as discussed >> in the protocol spec). >I'm missing something here. By comparing a.b.c.d.f and a.b.c.e.f, >a manager can determine that the region is a.b.c.[d-e].f This seems >to me to be aligned with the terminology in the protocol spec clause >6.2.3 for registration of regions. I don't want to spend many more cycles on this, since I'm fairly sure I agree with you :-) By implied end of region, I am referring to some of the discussion in section 7.1.5. Wherein a.b.c implied a region from a.b.c, up to but not including a.b.c+1. I interpreted Shawn's early posting as suggesting that the value of agentxRegEnd would be this implied oid (a.b.c+1). If you use agentxRegEnd to hold this '+1' value, you've used up both oids in the MIB entry, and have no way to express the range subid. That's all, and it's not worth discussing any more. I think you and I (at hopefully others) agree on this: received r.region agentxRegStart agentxRegEnd ----------------- -------------- ------------ a.b.c a.b.c 0.0 a.b.c.[d-e] a.b.c.d a.b.c.e a.b.c.[d-e].f a.b.c.d.f a.b.c.e.f >This begs the question of whether the MIB implementation can produce the >same result as the actual dispatcher. In systems supporting multiple >subagent protocols (with an internally unified registration/priority >resolution mechanism) the "best" AgentX subagent for handling an SNMP >varbind is not necessarily the best of all the known subagents for >that varbind. I imagine we are not the only vendor with motivation to >support multiple subagent protocols concurrently. This work doesn't >need to model what folks like us are doing, but it shouldn't preclude it. That's a pretty good issue. >We'd also have to note that the result would identify the likely AgentX >subagent, or else provide some way of indicating that the responsible >subagent is not an AgentX subagent. The responsible subagent's registration information that caused it to be chosen, would not be reflected in agentxRegTable, right? Then I think we'd want some way of denoting this condition (different than denoting "no subagent will be dispatched to"). >I'm still skeptical about the value of this, but I'm still listening. In a AgentX-only master I think it's worthwhile, but it's starting to sound less useful for the more general case. I'm not pushing hard for it. Mike From 6b23d5ACt@1nashvill.com Sat Dec 6 14:10:30 1997 Received: from cashew.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA005106229 for ; Sat, 6 Dec 1997 14:10:29 -0800 Return-Path: <6b23d5ACt@1nashvill.com> Received: (from uucp@localhost) by cashew.bmc.com (8.8.6/8.8.6) id QAA17187 for ; Sat, 6 Dec 1997 16:10:27 -0600 (CST) From: 6b23d5ACt@1nashvill.com Received: from gauntlet.fv.com(207.67.199.118) by cashew.bmc.com via smap (V2.0) id xma017183; Sat, 6 Dec 97 16:10:21 -0600 Received: (from uucp@localhost) by gauntlet.fv.com (8.8.8/8.8.8) id OAA19609 for ; Sat, 6 Dec 1997 14:04:58 -0800 (PST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma019603; Sat, 6 Dec 97 14:04:30 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.8/8.8.8) with ESMTP id OAA16538 for ; Sat, 6 Dec 1997 14:09:48 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.8/8.8.8) id OAA19596 for ; Sat, 6 Dec 1997 14:04:29 -0800 (PST) Received: from gate4.gateway.com(208.215.59.158) by gauntlet.fv.com via smap (3.2) id xma019589; Sat, 6 Dec 97 14:04:13 -0800 Received: by lsf008.gateway.com; id QAA03132; Sat, 6 Dec 1997 16:02:04 -0600 (CST) Received: from sdn-ts-003gaatlap12.dialsprint.net(206.133.65.63) by lsf008.gateway.com via smap (V3.1) id xmac02553; Sat, 6 Dec 97 16:01:35 -0600 Date: 05 Dec 97 5:08:19 PM Message-Id: To: lasers@44optic.com Subject: Lasers/Optics/Optical Tables - Save! MWK INDUSTRIES SALE! JUST A QUICK LETTER TO SHOW YOU SOME LASERS- OPTICS AND OPTICAL TABLES SURPLUS THAT WE JUST RECEIVED. ITEM TRIMMU12 14 WATT ARGON LASER MADE FOR HEART SURGERY, TRIMEDYNE MODEL 900 TEMOO, POLORIZED,220VAC INPUT , WATER COOLED , FIBER LAUNCH, ALL ON ROLLAROUND CART EXCELENT FOR LAB USE, THE POWER WAS MEASURED AT 13 TO 14 WATTS. PRICE $9500 12 MONTH WARRANTEE. ITEM: COHERENT ARTICULATING ARM FROM A MODEL 451 CO2 MEDICAL LASER. ECCELLENT COND. $200 ITEM CO220A: CO2 LASER MADE BY PFIZER ,1990, FOR SURGERY, TATTOO REMOVAL ECT. 20 WATT OUTPUT , TESTED AND IN EXC. COND. 110 VAC INPUT, COST $40,000 NEW OUR PRICE 4,900. MODEL 20-C ITEM:PDA-1U1 SPECTRA PHYSICS QUANTRA RAY PULSED DYE LASER , GOOD FOR SPARE PARTS MODEL PDA-1 $500 ITEM NEWU1 NEWPORT OPTICAL TABLE 16" BY 36" 4" THICK, 1 " HOLE SPACING, COMES WITH A RUBBER ISOLATED TABLE STAND, NOT AIR SUPPORTED, $750 ITEM: HEPSN1 HELIUM NEON POWER SUPPLY KIT OPERATES UP TO A 15 mW LASER, INCLUDES ALL COMPONENTS AND PRINTED CIRCUIT BOARD, ALL YOU HAVE TO DO IS STUFF AND SOLDER THE CIRCUIT BOARD . 4" BY 3" BY 3", PRICE $75 ITEM HENEU12 1 TO 1.5 MW HE-NE LASER 632.8 nM INCLUDES 12VDC INPUT POWER SUPPLY ALL IN A PLASTIC HOUSING 6.25 IN. BY 1.375IN BY 2.25 IN. TEMOO,RANDOM POL. ,1.7 MR DIVERGENCE. 12 MONTH WARRANTEE , PRICE $45 ITEM MELU12 1 TO 2 mW HE-NE LASER 632.8 NM , PULLS FROM MEDICAL EQUIPMENT .EACH UNIT INCLUDES HE-NE HEAD AND POWER SUPPLY[110VAC INPUT]. ALL YOU NEED TO PROVIDE IS A POWER CORD AND A FUSE TO MAKE THE UNIT OPERATIONAL. THE BEAM IS TEM00, POLORIZED WE WILL COVER EACH UNIT WITH A 12 MONTH UNLIMITED HOUR WARRANTEE, EXCELLENT FOR FOR LAB OR HOME USE. NEW THESE COST APPROX. $350 OUR PRICE $85. DIMENSIONS 9.75 BY 1.25 INCHES, P.S. 4.25 BY 3.25BY 1.25 INCHES. ITEM RAMCNS1: RAMAN CELL OPTICS 308 nm AR/AR 4600 A 0=0 DEGREES 1000 MM FL. 2" DIA. NEW. ORIGINAL PRICE $520 OUR PRICE $175 ITEM TFPOLNS1: POLARIZERS , THIN FILM FOR 532 nm , NEW, ORIGINAL COST $590 EACH OUR PRICE $200 EACH 10 MM DIA. ITEM CO2OCNS1: CO2 HIGH REFECTOR AND OUTPUT COUPLER 10.5 MM DIA, OC =79%R NEW. $200 A SET. ITEM 25MNS1: DIELECTRIC BROADBAND MIRRORS 450 TO 700NM , NEW WITH PLASTIC PROTECTIVE COATINGS , 2 SIZES 25 MM SQ. AND 50 MM SQ. RECOMENDED FOR HIGHER POWER LASERS. 25MM SIZE ITEM 25MNS1 $20 50MM SIZE ITEM 50MNS1 $25 ITEM # BSDNS1: 50/50 DIELECTRIC COATED PLATE BEAM SPLITTER 630 TO 660 NM COMES IN A TRIANGLE SHAPE EACH SIDE APPROX. 1" PRICE $20 ITEM # 45NS1 45 DEGREE RED REFLECTOR , PASSES 488 TO 532NM , CAN BE USED TO COMBINE RED AND GREEN/BLUE LASERS TO CREATE A WHITE LIGHT LASER. 1" SQ. PRICE $15 ITEM# PCINS1 PLANO/CONVEX LENS COATED FOR YAG 1064NM , AR COATED, 10MM DIA. NEW, ORIG. COST $250 OUR PRICE $100 ITEM# INFILTER : INTERFERENCE FILTERS USED FOR PASSING A PARTICULAR SPECTRAL LINE , 11.8 MM DIA. CAREFULLY REMOVED FROM MEDICAL EQUIPMENT AND WRAPPED IN LENSE PAPER. THE FOLLOWING WAVE LENGTHS ARE AVAILABLE. 523.5, 547.4 , 572.1, 512.9, 550.6, 488, 505.7 nm price $20 each. FOR A COMPLETE LINE OF NEW AND USED LASERS - OPTICS -ELECTRO OPTICS- LASER SHOWS ORDER A COMPLETE CATALOG AT MWKINDUSTRIES.COM TO: ORDER GO TO OUR WEB SITE MWKINDUSTRIES.COM {SECURE ORDERING SITE} QUESTIONS OR REMOVAL FROM MAILING LIST EMAIL: MWK@WORLDNET.ATT.NET MWK INDUSTRIES 1269 POMONA RD CORONA CA 91720 PHONE 909-278-0563 FAX 909-278-4887 From kvv@isengard.sw.bcd.adc.com Mon Dec 8 13:57:27 1997 Received: from almond.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA158638236 for ; Mon, 8 Dec 1997 13:57:17 -0800 Return-Path: Received: (from uucp@localhost) by almond.bmc.com (8.8.6/8.8.6) id PAA08583 for ; Mon, 8 Dec 1997 15:57:10 -0600 (CST) Received: from gauntlet.fv.com(207.67.199.118) by almond.bmc.com via smap (V2.0) id xma008577; Mon, 8 Dec 97 15:57:02 -0600 Received: (from uucp@localhost) by gauntlet.fv.com (8.8.8/8.8.8) id NAA10412 for ; Mon, 8 Dec 1997 13:51:34 -0800 (PST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma010362; Mon, 8 Dec 97 13:51:07 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.8/8.8.8) with ESMTP id NAA16822 for ; Mon, 8 Dec 1997 13:56:29 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.8/8.8.8) id NAA10352 for ; Mon, 8 Dec 1997 13:51:05 -0800 (PST) Received: from isengard.sw.bcd.adc.com(155.226.17.1) by gauntlet.fv.com via smap (3.2) id xma010345; Mon, 8 Dec 97 13:50:58 -0800 Received: (from kvv@localhost) by isengard.sw.bcd.adc.com (8.7.6/8.7.3) id PAA04917 for agentx@fv.com; Mon, 8 Dec 1997 15:56:22 -0600 (CST) From: "Kanaiya V. Vasani" Message-Id: <199712082156.PAA04917@isengard.sw.bcd.adc.com> To: agentx@fv.com Date: Mon, 8 Dec 1997 15:56:22 -0600 (CST) X-Mailer: ELM [version 2.4ME+ PL22 (25)] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit unsubscribe From andrm@ryan.oilpatchnet.com Sun Dec 21 14:30:19 1997 Received: from cashew.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA228703299 for ; Sun, 21 Dec 1997 14:28:19 -0800 Return-Path: Received: (from uucp@localhost) by cashew.bmc.com (8.8.6/8.8.6) id QAA16931 for ; Sun, 21 Dec 1997 16:26:58 -0600 (CST) Received: from gauntlet.fv.com(207.67.199.118) by cashew.bmc.com via smap (V2.0) id xma016910; Sun, 21 Dec 97 16:26:29 -0600 Received: (from uucp@localhost) by gauntlet.fv.com (8.8.8/8.8.8) id OAA16260 for ; Sun, 21 Dec 1997 14:19:17 -0800 (PST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma016256; Sun, 21 Dec 97 14:18:49 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.8/8.8.8) with ESMTP id OAA07711 for ; Sun, 21 Dec 1997 14:23:25 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.8/8.8.8) id OAA16223 for ; Sun, 21 Dec 1997 14:16:18 -0800 (PST) Received: from mnet01-81.houston.texas.net(206.127.23.81) by gauntlet.fv.com via smap (3.2) id xma016207; Sun, 21 Dec 97 14:16:07 -0800 Received: by ryan.oilpatchnet.com (8.8.7/8.8.7) id QAA02703 Date: Sun, 21 Dec 1997 16:24:06 -0600 Message-Id: <199712212224.QAA02703@ryan.oilpatchnet.com> From: gpg@t-1net.com Subject: Turn-key Home Business Apparently-To: I own and operate a lucrative home business. It generates $2,000-$3,000 per week. My business is direct sales, and my profit is 90% on every sale. I do not make "cold" calls, nor do I need to contact my family and friends. Our unique method of marketing has customers coming to us for our products. Combining this system with your commitment and determination makes this business an absolute success. For information, e-mail: gpg@t-1net.com ///////////////////////////////////////////////////////// If you wish to be removed from my mailing, write to remove@t-1net.com, with remove as the subject heading or Visit our web site, www.t-1net.com/remove, and enter your request to be removed. Call 281-922-2731 anytime and be manually removed. ///////////////////////////////////////////////////////// From scoya@cnri.reston.va.us Mon Dec 29 08:08:44 1997 Received: from cashew.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA062481719 for ; Mon, 29 Dec 1997 08:08:39 -0800 Return-Path: Received: (from uucp@localhost) by cashew.bmc.com (8.8.6/8.8.6) id KAA15174 for ; Mon, 29 Dec 1997 10:08:38 -0600 (CST) Received: from gauntlet.fv.com(207.67.199.118) by cashew.bmc.com via smap (V2.0) id xma015165; Mon, 29 Dec 97 10:08:22 -0600 Received: (from uucp@localhost) by gauntlet.fv.com (8.8.8/8.8.8) id IAA13147 for ; Mon, 29 Dec 1997 08:02:07 -0800 (PST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma013128; Mon, 29 Dec 97 08:01:37 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.8/8.8.8) with ESMTP id IAA23429 for ; Mon, 29 Dec 1997 08:07:45 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.8/8.8.8) id IAA13125 for ; Mon, 29 Dec 1997 08:01:36 -0800 (PST) Received: from ietf.org(132.151.1.19) by gauntlet.fv.com via smap (3.2) id xma013019; Mon, 29 Dec 97 08:01:09 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id LAA16131; Mon, 29 Dec 1997 11:07:17 -0500 (EST) Message-Id: <199712291607.LAA16131@ns.ietf.org> To: IETF-Announce:;@cnri.reston.va.us Cc: RFC Editor Cc: Internet Architecture Board Cc: agentx@fv.com From: The IESG Subject: Protocol Action: Agent Extensibility (AgentX) Protocol Version 1 to Proposed Standard Date: Mon, 29 Dec 1997 11:07:17 -0500 Sender: scoya@cnri.reston.va.us The IESG has approved the Internet-Draft 'Agent Extensibility (AgentX) Protocol Version 1' as a Proposed Standard. This document is the product of the SNMP Agent Extensibility Working Group. The IESG contact persons are John Curran and Michael O'Dell. Technical Summary 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. Working Group Summary The Working Group spent significant time discussing the scope of the protocol and trying to balance the desire for a straightforward subagent communication model against the desire for a transparent subagent model which would work for any given MIB structure. This resulted in an approach which minimizes subagent communication messages while supporting the many common MIB object configurations. During Last Call, the issue was raised that the protocol was not suitable as a replacement for existing proprietary master/subagent protocols, as it could not address the full range of object types found in some MIBs. In review, it was determined that this tradeoff were made with the rough consensus of the working group, and that the resulting protocol is still sufficiently valuable for portable subagents development that it warrants standardization. Also raised during Last Call was an issue regarding inability of a master agent to administratively decline a subagent's registration request. While not a requirement, per se, it was felt that this concern was reasonable and would be best resolved by the creation of an additional return code or set of codes as determined by implementation experience. Protocol Quality This work has been reviewed by the Area Director responsible for the work as well as others knowledgable regarding master/subagent technology. There are at least two draft implementations at this time. From bnatale@acecomm.com Tue Dec 30 09:17:36 1997 Received: from almond.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA174022254 for ; Tue, 30 Dec 1997 09:17:34 -0800 Return-Path: Received: (from uucp@localhost) by almond.bmc.com (8.8.6/8.8.6) id LAA23811 for ; Tue, 30 Dec 1997 11:17:32 -0600 (CST) Received: from relay1.smtp.psi.net(38.8.14.2) by almond.bmc.com via smap (V2.0) id xma023798; Tue, 30 Dec 97 11:17:11 -0600 Received: from nips.acec.com by relay1.smtp.psi.net (8.8.5/SMI-5.4-PSI) id MAA17846; Tue, 30 Dec 1997 12:16:53 -0500 (EST) Received: from bnatale by nips.acec.com (5.65/3.2.083191-ACE*COMM) id AA27541; Tue, 30 Dec 1997 12:18:28 -0500 Message-Id: <3.0.5.32.19971230121843.009644a0@nips.acecomm.com> X-Sender: natale@nips.acecomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 30 Dec 1997 12:18:43 -0500 To: agentx@peer.com From: The IESG (by way of Bob Natale ) Subject: Protocol Action: Agent Extensibility (AgentX) Protocol Version 1 to Proposed Standard Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" The IESG has approved the Internet-Draft 'Agent Extensibility (AgentX) Protocol Version 1' as a Proposed Standard. This document is the product of the SNMP Agent Extensibility Working Group. The IESG contact persons are John Curran and Michael O'Dell. Technical Summary 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. Working Group Summary The Working Group spent significant time discussing the scope of the protocol and trying to balance the desire for a straightforward subagent communication model against the desire for a transparent subagent model which would work for any given MIB structure. This resulted in an approach which minimizes subagent communication messages while supporting the many common MIB object configurations. During Last Call, the issue was raised that the protocol was not suitable as a replacement for existing proprietary master/subagent protocols, as it could not address the full range of object types found in some MIBs. In review, it was determined that this tradeoff were made with the rough consensus of the working group, and that the resulting protocol is still sufficiently valuable for portable subagents development that it warrants standardization. Also raised during Last Call was an issue regarding inability of a master agent to administratively decline a subagent's registration request. While not a requirement, per se, it was felt that this concern was reasonable and would be best resolved by the creation of an additional return code or set of codes as determined by implementation experience. Protocol Quality This work has been reviewed by the Area Director responsible for the work as well as others knowledgable regarding master/subagent technology. There are at least two draft implementations at this time.