Delivery-Date: Mon, 06 Jan 1997 14:57:36 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id OAA24808 for X-agentx; Mon, 6 Jan 1997 14:57:36 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id OAA24805 for ; Mon, 6 Jan 1997 14:57:35 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id RAA14089 for ; Mon, 6 Jan 1997 17:57:07 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma014048; Mon, 6 Jan 97 14:56:39 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id OAA27801 for ; Mon, 6 Jan 1997 14:57:37 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id RAA14028 for ; Mon, 6 Jan 1997 17:56:38 -0500 (EST) Received: from igw3.watson.ibm.com(129.34.139.18) by gauntlet.fv.com via smap (3.2) id xma013999; Mon, 6 Jan 97 14:56:19 -0800 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id RAA08684 for ; Mon, 6 Jan 1997 17:57:17 -0500 Received: from alisan.hopewell.ny.us (uri@[32.224.169.96]) by mailhub1.watson.ibm.com (8.8.2/11-26-96) with ESMTP id RAA75581 for ; Mon, 6 Jan 1997 17:56:02 -0500 Received: (from uri@localhost) by alisan.hopewell.ny.us (8.7.6/8.7.3) id RAA01707; Mon, 6 Jan 1997 17:55:20 -0500 Date: Mon, 6 Jan 1997 17:55:20 -0500 Message-Id: <199701062255.RAA01707@alisan.hopewell.ny.us> From: To: agentx@fv.com Subject: Security Considerations Reply-to: uri@watson.ibm.com Hello there! First, due to the recent wind change in IESG, namely the fact that dummy SecCon in RFCs won't be accepted any more, here's the proposed text to "Security Considerations" section. Below are my concerns and questions wrt. current state of affairs wrt. security issues. Security considerations require two questions to be answered: 1. Is this Subagent allowed to connect to that Master Agent? 2. If the first question was answered "Yes - what part of MIB tree is this Subagent allowed to "cover"? Via Agentx protocol, a Subagent can connect to a Master Agent (or an Agent) using either network transport mechanism (e.g. TCP), or local one (i.e. shared memory, named pipes). In case local transport mechanism is used and both Subagent and Master Agent are running on the same box, security can be delegated to the operating system features. The answer to the security question 1 then is trivial (iff the Subagent has sufficient privileges - operating system will allow the connection). The answer to the question 2 is: "As long as the Subagent is authorised to connect we allow it to access any part of the MIB". If network transport is used, and/or Subagent and Master Agent are running on different hosts, it is required, that the transport mechanism utilized provides its own security. Transport Layer Security or SSL is suggested as offering adequate protection, identifying the Subagents by their OIDs, and the Master Agent by its AgentID (this is necessary for the purpose of security key ownership). When Subagent and Master Agent are running on the same host, authorization issues can be ignored: if the box owner (root privileges) wishes to start a subagent that wants to handle some MIB groups, the decision is his and no security issues arise. Thus it is recommended that subagents run always on the same box as the Master Agent. If network layer insecure transport is used - it is a potential exposure. Now - the problematic point: However, when the owners of the "Subagent" and the "Agent" entities are different - we need to be able to provide both authentication (i.e. whether this Subagent is allowed to talk to us at all) and authorization (i.e. what part of the MIB tree we parcel out to this Subagent). When the connection is being established, mutual authentication between Master Agent and Subagent is required. TLS allows that. Even though actual cryptographic services (message integrity, source authentication, confidentiality and such) can be handled by TLS (or SSL) layer, authorization has to be done here in Agentx, in order for independent implementations of Agentx agents and subagents to interoperate and be secure at the same time. I say it's problematic because I haven't quite figured out how to accommodate for all the fancy registration features of the Agentx in this authorization table, that should tell: "Subagent 1.3.x.y.... is allowed to talk to us and we permit it to handle the following MIBs....." Any comments? -- Regards, Uri -=-=-==-=-=- uri@watson.ibm.com   Delivery-Date: Thu, 09 Jan 1997 09:12:03 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id JAA07440 for X-agentx; Thu, 9 Jan 1997 09:12:02 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id JAA07425 for ; Thu, 9 Jan 1997 09:12:01 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id MAA25994 for ; Thu, 9 Jan 1997 12:11:26 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma025977; Thu, 9 Jan 97 09:10:56 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id JAA18441 for ; Thu, 9 Jan 1997 09:11:58 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id MAA25968 for ; Thu, 9 Jan 1997 12:10:54 -0500 (EST) Received: from stratacom.strata.com(204.179.0.2) by gauntlet.fv.com via smap (3.2) id xma025929; Thu, 9 Jan 97 09:10:23 -0800 Received: from Strata.COM (kiwi.strata.com) by stratacom.strata.com (4.1/SMI-4.1/Gatekeeper.Strata.Com-950201) id AA25122; Thu, 9 Jan 97 09:10:57 PST Received: from farley.strata.com by Strata.COM (4.1/SMI-4.1/StrataCom-GCA-Kiwi-961130-1) id AA29125; Thu, 9 Jan 97 09:10:56 PST Received: from santa.strata.com by farley.strata.com (SMI-8.6/SMI-SVR4) id JAA00730; Thu, 9 Jan 1997 09:10:11 -0800 Received: from marvell.strata.com by santa.strata.com (4.1/SMI-4.1/StrataCom-GCA-SunClient-LOCAL-931101) id AA14028; Thu, 9 Jan 97 09:10:55 PST Date: Thu, 9 Jan 97 09:10:55 PST From: dfrancis@stratacom.com (Dale Francisco) Message-Id: <9701091710.AA14028@santa.strata.com> To: agentx@fv.com Subject: AgentX WG at 37th IETF, reported by Dale Francisco [Here's the minutes I sent to the IETF yesterday; I'm in the final phase of completing a more complete record, which I hope will be available to the working group by Monday. Thanks, Dale Francisco, wg editor] Agentx WG at 37th IETF, December 9-13, 1996 ------------------------------------------- At the 37th IETF in San Jose, December 9-13, 1996, the SNMP Agent Extensibility Working Group (agentx) met on Wednesday, December 11, 9:00-11:30. The most active participants in the discussion (a few names may have been missed due to confusion on the part of the note-taker) were: Uri Blumenthal, Linda Cabeca, Jeff Case, Dale Francisco, Maria Greene, Jeff Johnson, Deirdre Kostick, Bobby Krupczak, Bob Natale, Dave Perkins, Randy Presuhn, and Don Ryan. About 80 people were present at the meeting. Meeting notes were taken by Dale Francisco, wg editor. AgentX WG Meeting (Wed, December 11, 09:00-11:30) ------------------------------------------------- Working group chair Bob Natale opened the meeting with a statement that he wanted to concentrate first on a review of section 11 ("Questions and Issues") of the most recent protocol draft, and then move on to discussion of implementations and interoperability testing. There was some discussion of 11.1, the decision to proceed with multiple varbinds per AgentX PDU. Jeff Case proposed that we require subagents to be able to accept multiple-varbind PDUs, but not require master agents to emit them. Others felt that only in the case of AgentX GetNext and GetBulk PDUs should the master be allowed to emit fewer than all the relevant varbinds in a single AgentX PDU. The issue was not resolved. The next item to be discussed (11.3) was the decision to remove the value "all contexts" for the context field in the AgentX header. Some felt that by not allowing the possibility of subagents registering for "all contexts", a significant percentage of the market for extensible agents would be unable to use AgentX. It was agreed that there needed to be more discussion on the list of whether registration for "all contexts" is necessary. Several people voiced concerns about how changes in the protocol draft were tracked from version to version. There was a request, agreed to by the chair and the editor, that either a longer rationale section or a separate rationale document be added to explain the motivation behind various design decisions. There was also a request, agreed to by the editor, that instead of posting interim versions of the protocol draft to the mailing list, each new iteration would be submitted as a new internet draft. The question was raised as to whether AgentX was meant to be able to run over a connectionless transport, and if so, how. The consensus was that AgentX is only specified over connection-oriented transports. Several people felt that, though by itself it would not solve the problem of running on a connectionless transport, the idea of a connection or session ID in the AgentX header was a good one. There was a great deal of discussion about index allocation and instance reservation. Many felt that there was insufficient support for multiply-indexed tables in the current protocol draft, and that, in fact, the current index allocation scheme only worked for singly-indexed, arbitrary integer tables. The example was given of a table with two index objects, the first of which is shared. Since indices must be allocated one at a time, it would be impossible for subagent A to get an allocation for, say, "1.2", and subagent B to allocate "1.3". Many people felt that any model that relied on the master agent alone for index allocation was inherently unworkable, since, by design, only the subagent has detailed MIB knowledge. Various solutions were proposed, including a new entity, the "index allocation server"; ad hoc, outside-the-protocol subagent-to-subagent communication; and new AgentX protocol operations that would allow subagents to discover existing indexes and to request arbitrary length (not just single integer valued) index objects. There was also discussion of the unionized registration concept that had been deleted, for lack of a compelling defense, from the most recent protocol draft. It was asked how, without unionized registration, it would be possible to do row creation in tables supported by multiple subagents, where only one of the subagents would be capable of creating a particular row. It became clear, given the intensity of the discussion and the cogency of some of the counterexamples that had been brought forward, that further discussion of the protocol was necessary before general implementation could go forward (though in fact, many of the questions that were raised were the result of initial implementations of the current protocol draft). Deirdre Kostick, NM Area Director, asked that everyone with proposals for changes to the protocol draft post them to the mailing list by a specified time, and that we agree on a date sometime after that for achieving consensus on the protocol. It was agreed that proposed changes to the protocol be posted to the list by January 10, 1977; that we determine final consensus on those issues by February 14; and that a new version of the protocol draft would be submitted to the IETF by February 28.   Delivery-Date: Thu, 09 Jan 1997 10:20:05 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id KAA13853 for X-agentx; Thu, 9 Jan 1997 10:20:04 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id KAA13844 for ; Thu, 9 Jan 1997 10:20:03 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id NAA00492 for ; Thu, 9 Jan 1997 13:19:29 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma000468; Thu, 9 Jan 97 10:19:00 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id KAA25803 for ; Thu, 9 Jan 1997 10:20:02 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id NAA00463 for ; Thu, 9 Jan 1997 13:18:59 -0500 (EST) Received: from relay1.smtp.psi.net(38.8.14.2) by gauntlet.fv.com via smap (3.2) id xma000443; Thu, 9 Jan 97 10:18:50 -0800 Received: from nips.acec.com by relay1.smtp.psi.net (8.6.12/SMI-5.4-PSI) id NAA08556; Thu, 9 Jan 1997 13:19:16 -0500 Received: from bnatale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA22592; Thu, 9 Jan 1997 13:21:08 -0500 Message-Id: <3.0.32.19970109131848.009343b0@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 09 Jan 1997 13:18:50 -0500 To: agentx@fv.com From: Bob Natale Subject: AgentX schedule Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi everyone, Quoting from Dale's recently posted minutes of the San Jose meeting: "It was agreed that proposed changes to the protocol be posted to the list by January 10, 1977; that we determine final consensus on those issues by February 14; and that a new version of the protocol draft would be submitted to the IETF by February 28." To give you more time to review the minutes--and possibly the more detailed version Dale will try to post by Monday-- and to permit more precise formulation of any contemplated change proposals, we will extend the deadline for posting such proposals to January 17, 1997 (perhaps the longest extension on record...1041 weeks! :-) The other two dates will remain as stated in the minutes. While they should be concise, change proposals should be clear wrt what sections/text of the current draft they are changing, complete wrt the proposed new text, and provide a candidate rationale that can be used in the new section which will explain our major design decisions. So, the dates are (COB): Jan 17, 1997 - Cut-off for posting of change proposals relative to Draft 5. Feb 14, 1997 - Statement of consensus position on all requirements and design issues. Feb 28, 1997 - Submission of new version of the AgentX Protocol I-D to the IETF. Note that, as of now, we plan to complete the AgentX before the next IETF meeting (April 7-11 in Nashville TN) and no AgentX meeting is planned for Nashville. Cordially, BobN ------ ISO 9000 Registered, Hardware and Software Divsions ----- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] natale@acec.com | Gaithersburg MD 20878 | http://www.acec.com ----- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ------ ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Fri, 10 Jan 1997 02:19:33 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id CAA06914 for X-agentx; Fri, 10 Jan 1997 02:19:32 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id CAA06911 for ; Fri, 10 Jan 1997 02:19:32 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id FAA21372 for ; Fri, 10 Jan 1997 05:18:54 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma021369; Fri, 10 Jan 97 02:18:40 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id CAA22361 for ; Fri, 10 Jan 1997 02:19:32 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id FAA21366 for ; Fri, 10 Jan 1997 05:18:24 -0500 (EST) Message-Id: <199701101018.FAA21366@gauntlet.fv.com> Received: from vnet.ibm.com(199.171.26.4) by gauntlet.fv.com via smap (3.2) id xma021364; Fri, 10 Jan 97 02:18:23 -0800 Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1194; Fri, 10 Jan 97 05:18:44 EST Date: Fri, 10 Jan 97 11:20:09 CET From: "Bert Wijnen" To: agentx@fv.com Subject: draft-ietf-agentx-ext-pro-01.txt problems I'll be posting some (belated) comments on postings of December. JeffJohnson writes (15 Dec 1996) > ............................. In particular, I was interested in two > classes of products: > 1) software applications running on the workstation > 2) hardware products with on-board subagents being plugged into the > workstation > AgentX is of course not limited to these environments, but I do feel > that this is where it is most applicable. > I very much agree on this. We try to solve 80% of the problem space and these workstation indeed represent a big part of that. > In evaluating the document from this perspective, it is useful to see > how currently existing, applicable MIBs would be implemented in an > AgentX environment. In particular, I considered it mandatory that an > AgentX master agent with multiple subagents be able to completely > implement the following MIBs which should reasonably be expected to be > implemented in an AgentX environment. > 1) The MIBs Formerly Known as MIB-II > 1.1) SNMPv2 MIB > Yes, but this one (as we state in the doc) is SNMP admin based and so it is normally implemented within the master agent itself. > 1.2) Interfaces MIB > 1.3) IP MIB > 1.4) UDP MIB > 1.5) TCP MIB > 2) Media-specific MIBs > 3) Remote Monitoring MIB > I do not agree with the requirement to be able to implement the RMON MIB as an agentX based subagent. To me the RMON MIB is more of a MLM MIB than an "agent"-MIB. What I do want to enable is that an RMON implementation can be done such that it can function also in the role of master agent. I made this statement to the mailing list in mid-December also and asked if anybody would implement an RMON-mib using agentX if agentX could handl it. I basically got only one answer that stated that they might consider it in the future, but that right now they use another product. So... we could worry about RMON being inplementable as a sub, but the RMON vendors are not interested it seems. > 4) Host Resources MIB > 5) Application MIB > > Note that I wanted to add Entity MIB to the list, but I don't see how > it can be implemented in a distributed environment (particularly the > object entPhysicalContainedIn). > Correct. I would se the EntityMIB as an SNMP admin MIB also, and thus I think it should be impemented within the master-agent itself. > Now that you know where I'm coming from, here is my list of issues. I'm > going to address each in separate messages so that the individual > threads can be followed. > 1) unionized registration requirement > 2) handling scalar objects > 3) directed traps > 4) get-bulk elements of procedure > 5) support for persistency > Bert   Delivery-Date: Fri, 10 Jan 1997 02:23:32 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id CAA07279 for X-agentx; Fri, 10 Jan 1997 02:23:32 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id CAA07276 for ; Fri, 10 Jan 1997 02:23:31 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id FAA21397 for ; Fri, 10 Jan 1997 05:22:54 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma021395; Fri, 10 Jan 97 02:22:25 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id CAA22497 for ; Fri, 10 Jan 1997 02:23:28 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id FAA21389 for ; Fri, 10 Jan 1997 05:22:25 -0500 (EST) Message-Id: <199701101022.FAA21389@gauntlet.fv.com> Received: from vnet.ibm.com(199.171.26.4) by gauntlet.fv.com via smap (3.2) id xma021384; Fri, 10 Jan 97 02:21:55 -0800 Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1244; Fri, 10 Jan 97 05:22:17 EST Date: Fri, 10 Jan 97 11:23:42 CET From: "Bert Wijnen" To: agentx@fv.com Subject: Handling Scalar Objects JeffJohnson writes (15 Dec 1996): > Unlike table objects where a given instance of an object typically > resides on a single subagent, scalar objects typically represent global > data which may be shared among multiple (or all) subagents. The current > agentx draft has no support for scalar objects. Consider the scalar > ifNumber. The agentx draft uses the ifTable in many of its examples to > demonstrate how agentx works, and yet inexplicably ignores ifNumber. In > reality the value for the global ifNumber is the sum of the individual > ifNumber values maintained by each subagent supporting the ifTable. But > there is no mechanism in agentx to support this summation. > Aggregated scalars (like ifNumber) are really bad in my view. These were designed in a time that we only knew about monolithic agents. If you take a master/sub-agent as a good way to implement instrumentation on managd devices/systems (and many people believe that this is the better approach these days)... then I think one would never design such an aggregate scalar. Besides, the ifNumber is really conflicting with the SNMP philosophy already where we state that we would never implement an object that can be calculated by a manager (and a manager could count the entries in the ifTable and so it then has the value for ifNumber). Nevertheless, I understand that we may have to give ifNumber special consideration.... not sure yet how to do that. I am certainly not in favor of providing a generic AGGREGATE solution that would encourage new MIB designs to do similar things as MIB II did with ifNumber. Bert   Delivery-Date: Fri, 10 Jan 1997 02:30:32 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id CAA07843 for X-agentx; Fri, 10 Jan 1997 02:30:32 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id CAA07840 for ; Fri, 10 Jan 1997 02:30:31 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id FAA21470 for ; Fri, 10 Jan 1997 05:29:54 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma021462; Fri, 10 Jan 97 02:29:25 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id CAA22716 for ; Fri, 10 Jan 1997 02:30:28 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id FAA21459 for ; Fri, 10 Jan 1997 05:29:25 -0500 (EST) Message-Id: <199701101029.FAA21459@gauntlet.fv.com> Received: from vnet.ibm.com(199.171.26.4) by gauntlet.fv.com via smap (3.2) id xma021457; Fri, 10 Jan 97 02:29:18 -0800 Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1340; Fri, 10 Jan 97 05:29:40 EST Date: Fri, 10 Jan 97 11:31:04 CET From: "Bert Wijnen" To: agentx@fv.com Subject: Unionized Registration Requirement JeffJohnson writes: > ................... So here is the show stopper. Without unionized > registrations, there is no way to support row creation in arbitrarily > indexed tables. > Yep, that sounds like a serious problem. And I agree that the suggested work-around with a sort of a "arbitrating subagent" that handles the SET and then spawns another child does sem ugly... We need to work on this more Bert   Delivery-Date: Fri, 10 Jan 1997 02:34:02 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id CAA08078 for X-agentx; Fri, 10 Jan 1997 02:34:02 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id CAA08071 for ; Fri, 10 Jan 1997 02:34:01 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id FAA21495 for ; Fri, 10 Jan 1997 05:33:24 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma021489; Fri, 10 Jan 97 02:32:55 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id CAA22753 for ; Fri, 10 Jan 1997 02:33:58 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id FAA21486 for ; Fri, 10 Jan 1997 05:32:54 -0500 (EST) Message-Id: <199701101032.FAA21486@gauntlet.fv.com> Received: from vnet.ibm.com(199.171.26.4) by gauntlet.fv.com via smap (3.2) id xma021483; Fri, 10 Jan 97 02:32:37 -0800 Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1391; Fri, 10 Jan 97 05:32:59 EST Date: Fri, 10 Jan 97 11:34:24 CET From: "Bert Wijnen" To: agentx@fv.com Subject: Support for Persistency JeffJohnson writes (15 Dec 1996): > Although I don't know of any arbitrarily-indexed MIB tables which > require that the arbitrary indexing be persistent from reboot to reboot > there are customers who require this, specifically in the ifTable. Many > of us have experienced the distinct displeasure of trying to explain to > a customer that it is perfectly legal for a given interface to have a > different ifIndex value following a reboot. Many applications don't > handle this, and customers are more likely to blame the agent than the > application. So it would be nice if there were some support for > persistency. I have though of two possible mechanisms. > Since subagents can register with different priorities, an administartor has control (if the subagent allows to specify the priority at startup) as to which subagent would win.... so I think that this is workable. Bert   Delivery-Date: Fri, 10 Jan 1997 02:37:03 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id CAA08314 for X-agentx; Fri, 10 Jan 1997 02:37:03 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id CAA08304 for ; Fri, 10 Jan 1997 02:37:02 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id FAA21552 for ; Fri, 10 Jan 1997 05:36:25 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma021541; Fri, 10 Jan 97 02:35:55 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id CAA22797 for ; Fri, 10 Jan 1997 02:36:57 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id FAA21535 for ; Fri, 10 Jan 1997 05:35:54 -0500 (EST) Message-Id: <199701101035.FAA21535@gauntlet.fv.com> Received: from vnet.ibm.com(199.171.26.4) by gauntlet.fv.com via smap (3.2) id xma021531; Fri, 10 Jan 97 02:35:39 -0800 Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1427; Fri, 10 Jan 97 05:36:01 EST Date: Fri, 10 Jan 97 11:37:26 CET From: "Bert Wijnen" To: agentx@fv.com Subject: Get-Bulk Elements of Procedure JeffJohnson writes (15 Dec 1996): > This brings us to 7.2.1.3 of the agentx draft which starts by specifyin > that a response PDU containing N + (M * R) variable bindings. For large > values of M this is stupid since the response will be too big. Further, > even though step 2 specifies that the g.max_repetitions field in the > agentx-GetBulk-PDU can be set to a value smaller than the max- > repetitions field in the incoming SNMP PDU, there are no real guideline > for supplying a value. Well, how about: 7.2.1.3. agentx-GetBulk-PDU states: - g.max_repetitions is generally set to the max_repetitions value in the Request-PDU. However, the master agent may elect a smaller value based on the maximum possible size of a potential Response-PDU, known constraints of the AgentX transport, or any other implementation-specific constraint. So in your example, I would let my master agent set max repetitions to 1 I think, because I know that there are other rows in the table that are handled by other subs. > I personally don't see that an agentx-GetBulk-PDU is necessary (or that > one would even work). It seems to me that an agentx-GetNext-PDU should > be used for the non-repeaters. Then a loop is entered that iterates at > most max-repetitions times. This loop would seed a requested varbinds > list with the remaining varbinds from the GetNext PDU. Each iteration > of the loop would use the agentx-GetNext-Pdu to retrieve the values for > each of the requested varbinds. The returned OID would then be used as > the requested varbind on the next iteration. This scheme has the > advantage that it removes complexity from the subagents, and that it > handles the cutover from one subagent to another. > I can very much agree with this. And in fact my experience with DPI has shown that this works pretty well. In my implementation of DPI I do not (yet) support the sending of a GETBULK to a sub, and I indeed always translate it in a loop into multiple GETNEXTs. That works great and is FAR LESS complex as supporting the GETBULK to a sub. However, people have told me that there are reasons why you would want a GETBULK to be passed to the sub, and I kind of agree with those too: - if a big table within one sub needs to be retrieved, a GETBULK works much faster than multiple GETNEXTs. - in such cases, using a GETBULK also allows the sub to more easily try to provide a consistent view of such a table. Maybe we could specify that, no matter what the value of max-repetitions is, that the sub could (or maybe better SHOULD/MUST) stop when it passes on to another column in a table or outside the table or to another registration point. Now... given our spec, the master agent can do that by setting the searchRange properly, no? In any event, I (personally) could support a statement that says: the agentx-GETBULK-PDU need not be passed by a master agent. The implementation may decide to translate a GETBULK into multiple GETNEXT requests if it so wants for simplicity. Bert   Delivery-Date: Fri, 10 Jan 1997 02:40:34 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id CAA08644 for X-agentx; Fri, 10 Jan 1997 02:40:34 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id CAA08641 for ; Fri, 10 Jan 1997 02:40:33 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id FAA21620 for ; Fri, 10 Jan 1997 05:39:56 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma021609; Fri, 10 Jan 97 02:39:27 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id CAA22953 for ; Fri, 10 Jan 1997 02:40:29 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id FAA21604 for ; Fri, 10 Jan 1997 05:39:26 -0500 (EST) Message-Id: <199701101039.FAA21604@gauntlet.fv.com> Received: from vnet.ibm.com(199.171.26.4) by gauntlet.fv.com via smap (3.2) id xma021591; Fri, 10 Jan 97 02:39:22 -0800 Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1472; Fri, 10 Jan 97 05:39:45 EST Date: Fri, 10 Jan 97 11:41:09 CET From: "Bert Wijnen" To: agentx@fv.com Subject: Directed Traps JeffJohnson writes (15 Dec 1996): > The agentx-Notify-PDU allows a subagent to specify a context and a > variable binding list that is to be used for trap generation. > Unfortunately, for some forms of directed traps, this is not enough > information. For the purpose of this discussion, there are two kinds > of directed traps I'd like to address. > > The first type of directed trap is found in the RMON MIB. The > eventTable is used to determine if an RMON event will generate an SNMP > trap, and if so, the associated instance of eventCommunity specifies > the communities which are to receive the trap. In other words, the trap > should only be directed to those hosts associated with the given > community. Unfortunately, the agentx-Notify-PDU does not provide a > mechanism for an RMON subagent to tell the master agent the communities > to which the trap is to be directed, and hence agentx is unable to > correctly support RMON traps. > As I have stated before, I do not consider the RMON MIB as an agent MIB but as an MLM MIB and so I consider it outside the scope of agentX for now. > The second type of directed trap is not found in any standard MIB that > I am aware of. However, I have seen this type of trap in several vendor > MIBs. This type of trap is sent to a single recipient when a service > that was requested has completed. Consider a generic "service" MIB. > > Such a MIB would allow a management application to specify the > parameters for a service to be performed, and then activate the > service. > > The management application can monitor a status object to check when the > requested service has completed, or alternately can wait for a directed > trap that is sent from the agent to the management application when the > service has completed. Since this mechanism is not found in any > standard MIBs, there is not a requirement to support it, but it would > be nice to have this capability. Of course, I recognize that adding this > support would require adding a mechanism for the subagent to specify the > destination of the trap, and further would require adding a mechanism > for the subagent to determine from the master agent where the initial > service request came from. > I must admit that recently I have been exposed to few situations where this same requirement was mentioned. Now... I would hope that the "filtering" mechanisms as we were discussing in the SNMPv2 advisory team (that is the access control appliation onto the varBinds of a TRAP) could address this problem, could they not? Since we do not yet have a STD MIB that needs this (except the RMON MIB, but see comments above) can we pls pospone a solution for this to a second version of agentX, that is if it turns out that there is a real need by that time. Bert   Delivery-Date: Fri, 10 Jan 1997 05:50:58 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id FAA23266 for X-agentx; Fri, 10 Jan 1997 05:50:57 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id FAA23263 for ; Fri, 10 Jan 1997 05:50:57 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id IAA25087 for ; Fri, 10 Jan 1997 08:50:21 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma025085; Fri, 10 Jan 97 05:50:03 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id FAA00496 for ; Fri, 10 Jan 1997 05:50:58 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id IAA25080 for ; Fri, 10 Jan 1997 08:49:50 -0500 (EST) Received: from puli.cisco.com(171.69.1.174) by gauntlet.fv.com via smap (3.2) id xma025076; Fri, 10 Jan 97 05:49:45 -0800 Received: from [171.69.128.42] (gryphon.cisco.com [171.69.128.42]) by puli.cisco.com (8.6.12/8.6.5) with ESMTP id FAA27452 for ; Fri, 10 Jan 1997 05:50:20 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: In-Reply-To: <199701101039.FAA21604@gauntlet.fv.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-pression: awestruck amazement Date: Fri, 10 Jan 1997 08:48:35 -0500 To: agentx@fv.com From: Bob Stewart Subject: Re: Directed Traps Circa 11:41 AM +0000 1/10/97, Bert Wijnen bitwhacked: >As I have stated before, I do not consider the RMON MIB as an agent >MIB but as an MLM MIB and so I consider it outside the scope of >agentX for now. Although I agree with the idea that RMON is a mid-level manager application, putting it out of scope for that reason sounds wrong. The idea of AgentX is to support modular agents with components from multiple vendors for open systems. A mid-level or even higher level manager is exactly the sort that would want such modularity. To support solid, distributed management, many (perhaps most) management applications should include a MIB so they can be remotely controlled. Support for this from AgentX would be absolutely necessary. >Since we do not yet have a STD MIB that needs this (except the RMON MIB, >but see comments above) can we pls pospone a solution for this to a >second version of agentX, that is if it turns out that there is a real >need by that time. Postponing such a solution is fine as long as there are no obvious barriers to it in the present design. Bob   Delivery-Date: Fri, 10 Jan 1997 06:26:02 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id GAA26022 for X-agentx; Fri, 10 Jan 1997 06:26:02 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id GAA26017 for ; Fri, 10 Jan 1997 06:26:01 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id JAA25554 for ; Fri, 10 Jan 1997 09:25:25 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma025548; Fri, 10 Jan 97 06:25:12 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id GAA01982 for ; Fri, 10 Jan 1997 06:26:03 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id JAA25541 for ; Fri, 10 Jan 1997 09:24:56 -0500 (EST) Message-Id: <199701101424.JAA25541@gauntlet.fv.com> Received: from vnet.ibm.com(199.171.26.4) by gauntlet.fv.com via smap (3.2) id xma025525; Fri, 10 Jan 97 06:24:27 -0800 Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 6385; Fri, 10 Jan 97 09:24:47 EST Date: Fri, 10 Jan 97 15:26:07 CET From: "Bert Wijnen" To: bstewart@cisco.com, agentx@fv.com Subject: Directed Traps Ref: Your note of Fri, 10 Jan 1997 08:48:35 -0500 Subject: Directed Traps Bob writes: > >As I have stated before, I do not consider the RMON MIB as an agent > >MIB but as an MLM MIB and so I consider it outside the scope of > >agentX for now. > > Although I agree with the idea that RMON is a mid-level manager > application, putting it out of scope for that reason sounds wrong. The > idea of AgentX is to support modular agents with components from multiple > vendors for open systems. A mid-level or even higher level manager is > exactly the sort that would want such modularity. To support solid, > distributed management, many (perhaps most) management applications should > include a MIB so they can be remotely controlled. Support for this from > AgentX would be absolutely necessary. > I agree that such MLM-based applications need the possibility to be MIB-controlled/monitored. However, they also need the normal SNMP manager-side API. I think if you look at something like the WinSNMP API, then that API can probably serve both purposes for such MLM-based applications. Bert   Delivery-Date: Fri, 10 Jan 1997 09:03:08 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id JAA09899 for X-agentx; Fri, 10 Jan 1997 09:03:07 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id JAA09895 for ; Fri, 10 Jan 1997 09:03:07 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id MAA01228 for ; Fri, 10 Jan 1997 12:02:30 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma001217; Fri, 10 Jan 97 09:02:01 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id JAA10311 for ; Fri, 10 Jan 1997 09:03:03 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id MAA01204 for ; Fri, 10 Jan 1997 12:01:59 -0500 (EST) Received: from mail12.digital.com(192.208.46.20) by gauntlet.fv.com via smap (3.2) id xma001195; Fri, 10 Jan 97 09:01:43 -0800 Received: from flume.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id LAA19751; Fri, 10 Jan 1997 11:54:09 -0500 (EST) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA20592; Fri, 10 Jan 1997 11:54:04 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA05933; Fri, 10 Jan 1997 11:49:33 -0500 Message-Id: <9701101649.AA05933@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: Get-Bulk Elements of Procedure Date: Fri, 10 Jan 97 11:49:33 -0500 From: Mike Daniele X-Mts: smtp Bert wrote: >JeffJohnson writes (15 Dec 1996): >> I personally don't see that an agentx-GetBulk-PDU is necessary (or that >> one would even work). It seems to me that an agentx-GetNext-PDU should >> be used for the non-repeaters. Then a loop is entered that iterates at >> most max-repetitions times. This loop would seed a requested varbinds >> list with the remaining varbinds from the GetNext PDU. Each iteration >> of the loop would use the agentx-GetNext-Pdu to retrieve the values for >> each of the requested varbinds. The returned OID would then be used as >> the requested varbind on the next iteration. This scheme has the >> advantage that it removes complexity from the subagents, and that it >> handles the cutover from one subagent to another. >> >I can very much agree with this. And in fact my experience with DPI has >shown that this works pretty well. In my implementation of DPI I do >not (yet) support the sending of a GETBULK to a sub, and I indeed >always translate it in a loop into multiple GETNEXTs. That works great >and is FAR LESS complex as supporting the GETBULK to a sub. >However, people have told me that there are reasons why you would want >a GETBULK to be passed to the sub, and I kind of agree with those too: > - if a big table within one sub needs to be retrieved, a GETBULK > works much faster than multiple GETNEXTs. > - in such cases, using a GETBULK also allows the sub to more easily > try to provide a consistent view of such a table. I think GetBulk is necessary. Jeff correctly pointed out though that the draft is confusing and in error when describing how to use it. >Maybe we could specify that, no matter what the value of max-repetitions >is, that the sub could (or maybe better SHOULD/MUST) stop when it >passes on to another column in a table or outside the table or to >another registration point. Now... given our spec, the master agent >can do that by setting the searchRange properly, no? I think the spec is correct here, simply specifying the subagent must stop where it is told to stop (the end of the searchrange). The problem is that procedure described for the master agent is too constraining, probably too implementation-specific, and not optimal in all cases. What we need is to strongly define the subagent's procedures, but be more general in the master agent's. For example, the subagent MUST accept request pdus containing multiple variables, but the master doesn't HAVE to send multiple variables. The subagent MUST adhere to the searchranges, and MUST support GetBulk, but the master agent doesn't HAVE to send GetBulk. The master agent HAS to ensure that the registry is honored. That is, that ONLY the subagent responsible for a region gets to get/set the values of variables within that region. But if the master chooses to notice that a particular SNMP getbulk would be optimally handled by AgentX getnexts (because of instance level registrations, for example) it should be free to do so. I went overboard on this part. >In any event, I (personally) could support a statement that says: > the agentx-GETBULK-PDU need not be passed by a master agent. The > implementation may decide to translate a GETBULK into multiple > GETNEXT requests if it so wants for simplicity. >Bert I think the master agent's dispatching procedures need to be rewritten to specify much less detail, and permitting this type of behavior. The risk in doing so is that it opens up a "marketing" opportunity. "Our master agent doesn't force you to implement getbulk, so don't." Mike   Delivery-Date: Fri, 10 Jan 1997 10:54:25 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id KAA19509 for X-agentx; Fri, 10 Jan 1997 10:54:24 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id KAA19505 for ; Fri, 10 Jan 1997 10:54:21 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id NAA08293 for ; Fri, 10 Jan 1997 13:53:45 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma008283; Fri, 10 Jan 97 10:53:20 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id KAA19982 for ; Fri, 10 Jan 1997 10:54:24 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id NAA08263 for ; Fri, 10 Jan 1997 13:53:13 -0500 (EST) Received: from falcon.sps.com(192.82.122.36) by gauntlet.fv.com via smap (3.2) id xma008121; Fri, 10 Jan 97 10:51:37 -0800 Received: from [192.82.122.129] by Falcon.SPS.COM (post.office MTA v1.9.3b ID# 0-12586) with ESMTP id AAA48 for ; Fri, 10 Jan 1997 13:51:04 -0500 X-Sender: mwallace@falcon.sps.com Message-Id: In-Reply-To: <199701101022.FAA21389@gauntlet.fv.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 10 Jan 1997 13:53:25 -0500 To: agentx@fv.com From: mwallace@sps.com (Mark Wallace) Subject: Re: Handling Scalar Objects At 11:23 AM +0000 1/10/97, Bert Wijnen wrote: >JeffJohnson writes (15 Dec 1996): >Aggregated scalars (like ifNumber) are really bad in my view. >These were designed in a time that we only knew about monolithic >agents. If you take a master/sub-agent as a good way to implement >instrumentation on managd devices/systems (and many people believe >that this is the better approach these days)... then I think one >would never design such an aggregate scalar. Besides, the ifNumber >is really conflicting with the SNMP philosophy already where we >state that we would never implement an object that can be calculated >by a manager (and a manager could count the entries in the ifTable >and so it then has the value for ifNumber). >Nevertheless, I understand that we may have to give ifNumber special >consideration.... not sure yet how to do that. I am certainly >not in favor of providing a generic AGGREGATE solution that would >encourage new MIB designs to do similar things as MIB II did with >ifNumber. Gee, I kind of like ifNumber. :-) When I initially contact an SNMPv1 agent, I can ask for its ifNumber.0 (and maybe some other initial stuff) in one get-request, and then (since I know ifIndexes will be numbered 1 thru N, where N = ifNumber.0) I can generate a varbind list for getting, say, ifOperStatus for each interface, and poll for the status of each interface with one get-request. If I didn't have ifNumber, I indeed could calculate it, but I'd have to walk the ifTable with get-nexts to determine it. If the device as 29 interfaces, that's 29+1 requests to find out how many interfaces it has. Having ifNumber seems a lot more efficient. Of course, this doesn't help with the aggregation issue in Agent-X, but I did want to speak up for poor ol' ifNumber in terms of protocol efficiency. :-) -- Mark Wallace email: mwallace@sps.com Systems Engineer, SPS Inc. voice: 407-984-3370 Indialantic, Florida, USA   Delivery-Date: Fri, 10 Jan 1997 11:36:44 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id LAA22690 for X-agentx; Fri, 10 Jan 1997 11:36:44 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id LAA22687 for ; Fri, 10 Jan 1997 11:36:44 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id OAA11096 for ; Fri, 10 Jan 1997 14:36:05 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma011062; Fri, 10 Jan 97 11:35:35 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id LAA23610 for ; Fri, 10 Jan 1997 11:36:38 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id OAA11055 for ; Fri, 10 Jan 1997 14:35:34 -0500 (EST) Received: from unknown(134.177.110.46) by gauntlet.fv.com via smap (3.2) id xma011044; Fri, 10 Jan 97 11:35:23 -0800 Received: from bern.engwest (bern.engwest.baynetworks.com) by fedex.engwest.baynetworks.com.engwest.baynetworks.com (4.1/SMI-4.1) id AA25896; Fri, 10 Jan 97 11:36:00 PST Received: from localhost by bern.engwest (4.1/SMI-4.1) id AA14883; Fri, 10 Jan 97 11:35:58 PST Date: Fri, 10 Jan 1997 11:35:58 -0800 (PST) From: "Patrick D. Wildi" X-Sender: pwildi@bern To: agentx@fv.com Subject: Re: draft-ietf-agentx-ext-pro-01.txt problems In-Reply-To: <199701101018.FAA21366@gauntlet.fv.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 10 Jan 1997, Bert Wijnen wrote: > I'll be posting some (belated) comments on postings of December. > I do not agree with the requirement to be able to implement the RMON MIB > as an agentX based subagent. To me the RMON MIB is more of a MLM MIB than > an "agent"-MIB. What I do want to enable is that an RMON implementation > can be done such that it can function also in the role of master agent. > I made this statement to the mailing list in mid-December also and asked > if anybody would implement an RMON-mib using agentX if agentX could handl > it. I basically got only one answer that stated that they might consider > it in the future, but that right now they use another product. So... we > could worry about RMON being inplementable as a sub, but the RMON vendors > are not interested it seems. I have to admit I hardly followed the AgentX development. But here at Bay we do implement RMON subagents in our hub products. We use SNMP Research's Emanate. So if we would ever want to migrate to AgentX all the problems Jeff Johnson addressed would have to be solved. But then maybe AgentX was never intended for embedded system and we stick with what we have. Patrick Wildi ------------------------------------------------------------------- Patrick D. Wildi pwildi@baynetworks.com   Delivery-Date: Fri, 10 Jan 1997 11:42:49 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id LAA23176 for X-agentx; Fri, 10 Jan 1997 11:42:48 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id LAA23173 for ; Fri, 10 Jan 1997 11:42:48 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id OAA11556 for ; Fri, 10 Jan 1997 14:42:09 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma011539; Fri, 10 Jan 97 11:41:40 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id LAA24029 for ; Fri, 10 Jan 1997 11:42:43 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id OAA11528 for ; Fri, 10 Jan 1997 14:41:39 -0500 (EST) Message-Id: <199701101941.OAA11528@gauntlet.fv.com> Received: from vnet.ibm.com(199.171.26.4) by gauntlet.fv.com via smap (3.2) id xma011504; Fri, 10 Jan 97 11:41:21 -0800 Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 2804; Fri, 10 Jan 97 14:41:42 EST Date: Fri, 10 Jan 97 20:43:07 CET From: "Bert Wijnen" To: mwallace@sps.com, agentx@fv.com Subject: Handling Scalar Objects Ref: Your note of Fri, 10 Jan 1997 13:53:25 -0500 Subject: Handling Scalar Objects Mark wallace writes: > Gee, I kind of like ifNumber. :-) When I initially contact an SNMPv1 > agent, I can ask for its ifNumber.0 (and maybe some other initial stuff) in > one get-request, and then (since I know ifIndexes will be numbered 1 thru > N, where N = ifNumber.0) I can generate a varbind list for getting, say, > ifOperStatus for each interface, and poll for the status of each interface > with one get-request. If I didn't have ifNumber, I indeed could calculate > it, but I'd have to walk the ifTable with get-nexts to determine it. If > the device as 29 interfaces, that's 29+1 requests to find out how many > interfaces it has. Having ifNumber seems a lot more efficient. > > Of course, this doesn't help with the aggregation issue in Agent-X, but I > did want to speak up for poor ol' ifNumber in terms of protocol efficiency. > :-) > Yep I understand that you like that. And I am sure you (and me included when I am given the job of coding SNMP management apps) would love to see more intelligence in the agents. But the SNMP philosophy says we should keep agents SIMPLE. Besides, I must warn you that the new definition of ifIndex in the interfaces MIB (RFC1573) allows for ifIndex to be outside the range of 1-ifNumber. So your technique is no longer guearanteed to work. For preformance reasons, I am sure you are aware that we have GETBULK in SNMPv2 and so you can do your thing with ONE SINGLE GETBULK request. Mark, thanks for your comment anyway. I just wanted to make sure people understand where I am coming from and that I also understand why some of you like ifNumber so well. Bert   Delivery-Date: Fri, 10 Jan 1997 11:44:23 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id LAA23558 for X-agentx; Fri, 10 Jan 1997 11:44:22 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id LAA23548 for ; Fri, 10 Jan 1997 11:44:21 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id OAA11709 for ; Fri, 10 Jan 1997 14:43:41 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma011672; Fri, 10 Jan 97 11:43:11 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id LAA24179 for ; Fri, 10 Jan 1997 11:44:14 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id OAA11661 for ; Fri, 10 Jan 1997 14:43:10 -0500 (EST) Received: from mail12.digital.com(192.208.46.20) by gauntlet.fv.com via smap (3.2) id xma011621; Fri, 10 Jan 97 11:42:55 -0800 Received: from flume.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id OAA07876; Fri, 10 Jan 1997 14:34:39 -0500 (EST) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA07358; Fri, 10 Jan 1997 14:34:33 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA06014; Fri, 10 Jan 1997 14:30:05 -0500 Message-Id: <9701101930.AA06014@bernie.zk3.dec.com> To: agentx@fv.com Subject: Re: Handling Scalar Objects Date: Fri, 10 Jan 97 14:30:05 -0500 From: Mike Daniele X-Mts: smtp mwallace@sps.com wrote >Gee, I kind of like ifNumber. :-) When I initially contact an SNMPv1 >agent, I can ask for its ifNumber.0 (and maybe some other initial stuff) in >one get-request, and then (since I know ifIndexes will be numbered 1 thru >N, where N = ifNumber.0) I can generate a varbind list for getting, say, >ifOperStatus for each interface, and poll for the status of each interface >with one get-request. Not any more. From draft-ietf-ifmib-mib-05.txt: This constancy requirement on the value of ifIndex for a particular interface is vital for efficient management. However, an increasing number of devices allow for the dynamic addition/removal of network interfaces. One example of this is a dynamic ability to configure the use of SLIP/PPP over a character-oriented port. For such dynamic additions/removals, the combination of the constancy requirement and the restriction that the value of ifIndex is less than ifNumber is problematic. ... The solution adopted in this memo is just to delete the requirement that the value of ifIndex must be less than the value of ifNumber, and to retain ifNumber with its current definition. So, given that ifNumber will tell you ONLY how many interfaces there are, not what their ifIndex values are, do you still think it's valuable? Regards, Mike   Delivery-Date: Fri, 10 Jan 1997 12:48:05 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id MAA29505 for X-agentx; Fri, 10 Jan 1997 12:48:05 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id MAA29502 for ; Fri, 10 Jan 1997 12:48:05 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id PAA16122 for ; Fri, 10 Jan 1997 15:47:26 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma016110; Fri, 10 Jan 97 12:46:57 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id MAA29758 for ; Fri, 10 Jan 1997 12:48:00 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id PAA16102 for ; Fri, 10 Jan 1997 15:46:56 -0500 (EST) Received: from puli.cisco.com(171.69.1.174) by gauntlet.fv.com via smap (3.2) id xma016091; Fri, 10 Jan 97 12:46:43 -0800 Received: from [171.69.128.42] (gryphon.cisco.com [171.69.128.42]) by puli.cisco.com (8.6.12/8.6.5) with ESMTP id MAA04393 for ; Fri, 10 Jan 1997 12:47:19 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: In-Reply-To: References: <199701101022.FAA21389@gauntlet.fv.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-pression: awestruck amazement Date: Fri, 10 Jan 1997 15:45:53 -0500 To: agentx@fv.com From: Bob Stewart Subject: Re: Handling Scalar Objects Circa 1:53 PM -0500 1/10/97, Mark Wallace bitwhacked: >Gee, I kind of like ifNumber. :-) When I initially contact an SNMPv1 >agent, I can ask for its ifNumber.0 (and maybe some other initial stuff) in >one get-request, and then (since I know ifIndexes will be numbered 1 thru >N, where N = ifNumber.0) I can generate a varbind list for getting, say, >ifOperStatus for each interface, and poll for the status of each interface >with one get-request. As of RFC 1573 that won't work. The ifIndex space can be sparse. Bob   Delivery-Date: Fri, 10 Jan 1997 14:57:02 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id OAA11119 for X-agentx; Fri, 10 Jan 1997 14:57:01 -0800 (PST) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [129.34.139.18]) by fv.com (8.7.5/8.7.3) with ESMTP id OAA11099 for ; Fri, 10 Jan 1997 14:56:57 -0800 (PST) Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id RAA09458; Fri, 10 Jan 1997 17:52:48 -0500 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by mailhub1.watson.ibm.com (8.8.2/11-26-96) with SMTP id RAA60532; Fri, 10 Jan 1997 17:52:07 -0500 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA26929; Fri, 10 Jan 1997 17:52:07 -0500 From: Uri Blumenthal Message-Id: <9701102252.AA26929@hawpub.watson.ibm.com> Subject: Re: Get-Bulk Elements of Procedure To: daniele@zk3.dec.com (Mike Daniele) Date: Fri, 10 Jan 1997 17:52:07 -0500 (EST) Cc: agentx@fv.com In-Reply-To: <9701101649.AA05933@bernie.zk3.dec.com> from "Mike Daniele" at Jan 10, 97 11:49:33 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text > I think GetBulk is necessary. But not for the subagent. > The subagent MUST adhere to the searchranges, Yes. > and MUST support GetBulk, No. The subagent MAY support GetBULK and MUST indicate at registration (or "login" :-) time whether it is capable of supporting GetBULK. In case it cannot, master agent will translate GetBULK into a sequence of GetNEXT's for that subagent. > but the master agent doesn't HAVE to send GetBulk. Of course. > I went overboard on this part. Yeah!! [sorry, couldn't resist :-] > The risk in doing so is that it opens up a "marketing" opportunity. > "Our master agent doesn't force you to implement getbulk, so don't." Quit guessing about who might say what and start thinking: what's good, simple and straightforward for the subagent? AFTER this is satisfied - think what's good, simple and straightforward for the master agent. The rest can wait. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Fri, 10 Jan 1997 16:18:43 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id QAA18303 for X-agentx; Fri, 10 Jan 1997 16:18:43 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id QAA18300 for ; Fri, 10 Jan 1997 16:18:42 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id TAA00726 for ; Fri, 10 Jan 1997 19:18:03 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma000712; Fri, 10 Jan 97 16:17:34 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id QAA17229 for ; Fri, 10 Jan 1997 16:18:37 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id TAA00692 for ; Fri, 10 Jan 1997 19:17:32 -0500 (EST) Received: from mickey.nad.telco.com(204.30.216.2) by gauntlet.fv.com via smap (3.2) id xma000635; Fri, 10 Jan 97 16:16:52 -0800 Received: from ren.telco-nac.com ([199.164.221.112]) by mickey.nad.telco.com (8.6.4/8.6.4) with SMTP id QAA00641; Fri, 10 Jan 1997 16:16:46 -0800 Received: from phi.nad.telco.com by ren.telco-nac.com (5.0/SMI-SVR4) id AA08080; Fri, 10 Jan 1997 16:16:08 -0800 Date: Fri, 10 Jan 1997 16:16:08 -0800 From: sunil@nad.telco.com (Sunil Vallamkonda) Message-Id: <9701110016.AA08080@ren.telco-nac.com> To: natale@acec.com, agentx@fv.com Subject: Agent Extensibility ----- Begin Included Message ----- From sunil Thu Jan 9 17:20 PST 1997 >Return-Path: Date: Thu, 9 Jan 1997 17:20:30 -0800 From: sunil (Sunil Vallamkonda) To: snmp@lists.psi.com Subject: Agent Extensibility Content-Type: text Content-Length: 901 Hello SNMP Gurus, Re: Agent / Sub-Agent - Extensibility Architecture info I have spent time going through various issues of Simple Times Mag. I am looking for information or atleast pointers relating to architectural perspectives of ProxyAgent implementation (community string based - request-reponse method as in RFC1227) versus Sub-Agent implementation (cache-ahead method as in RFC 1227) I am trying to find/get information on architectural details, pros and cons, efficiency, maintenance-on-site (considering NMS as a whole), industry standard issues, proposals etc. I am looking for any white papers, articles, or detailed documents or even references such and other issues of concern in both the methods and in comparison. I have obtained Simple Times April 1996 issue. Though this gives some brief overview, however it does not cover much information such as recommended method, perspectives. I am looking for information, its specifics, differences and vendor implementations, pros and cons, and supportive arguments, etc. I would appreciate if you could email me any info/pointers on Agent-Proxy Agent versus SubAgent methods. Thank you. Sunil Vallamkonda   Delivery-Date: Fri, 10 Jan 1997 21:13:33 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id VAA12188 for X-agentx; Fri, 10 Jan 1997 21:13:32 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id VAA12185 for ; Fri, 10 Jan 1997 21:13:31 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id AAA10047 for ; Sat, 11 Jan 1997 00:12:52 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma010024; Fri, 10 Jan 97 21:12:22 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id VAA29578 for ; Fri, 10 Jan 1997 21:13:26 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id AAA10021 for ; Sat, 11 Jan 1997 00:12:21 -0500 (EST) Received: from seymour16.snmp.com(192.147.142.16) by gauntlet.fv.com via smap (3.2) id xma010009; Fri, 10 Jan 97 21:11:50 -0800 Received: from seymour4.snmp.com by seymour16.snmp.com with SMTP (5.61++/2.8s-SNMP) id AA13746; Sat, 11 Jan 97 00:12:23 -0500 Date: Sat, 11 Jan 97 00:12:23 -0500 From: Jeff Case Message-Id: <9701110512.AA13746@seymour16.snmp.com> To: agentx@fv.com Subject: Re: Get-Bulk Elements of Procedure i agree with jeff (johnson) and bert that the interation of getbulk in the subagent is of questionable complexity in comparison to the value delivered jj> I personally don't see that an agentx-GetBulk-PDU is necessary (or that jj> one would even work). It seems to me that an agentx-GetNext-PDU should jj> be used for the non-repeaters. Then a loop is entered that iterates at jj> most max-repetitions times. This loop would seed a requested varbinds jj> list with the remaining varbinds from the GetNext PDU. Each iteration jj> of the loop would use the agentx-GetNext-Pdu to retrieve the values for jj> each of the requested varbinds. The returned OID would then be used as jj> the requested varbind on the next iteration. This scheme has the jj> advantage that it removes complexity from the subagents, and that it jj> handles the cutover from one subagent to another. bert>I can very much agree with this. And in fact my experience with DPI has bert>shown that this works pretty well. In my implementation of DPI I do bert>not (yet) support the sending of a GETBULK to a sub, and I indeed bert>always translate it in a loop into multiple GETNEXTs. That works great bert>and is FAR LESS complex as supporting the GETBULK to a sub. bert's experience with dpi matches our experience with EMANATE bert>However, people have told me that there are reasons why you would want bert>a GETBULK to be passed to the sub, and I kind of agree with those too: bert> - if a big table within one sub needs to be retrieved, a GETBULK bert> works much faster than multiple GETNEXTs. bert> - in such cases, using a GETBULK also allows the sub to more easily bert> try to provide a consistent view of such a table. when we care about performance, we usually connect the subagent to the master agent using dynamically linked libraries and shared memory -- and when you do so, the speed advantages disappear i don't understand the continuing discussion of atomic gets (i understand you (bert) are only the messenger here) bert>Maybe we could specify that, no matter what the value of max-repetitions bert>is, that the sub could (or maybe better SHOULD/MUST) stop when it bert>passes on to another column in a table or outside the table or to bert>another registration point. gack bert>Now... given our spec, the master agent bert>can do that by setting the searchRange properly, no? if you don't know, we are all in trouble, given that you wrote it bert>In any event, I (personally) could support a statement that says: bert> the agentx-GETBULK-PDU need not be passed by a master agent. The bert> implementation may decide to translate a GETBULK into multiple bert> GETNEXT requests if it so wants for simplicity. gosh, i wish you could have been in san jose ... i argued for this but was unable to get consensus on it ... however, i hope and suspect that your time was better spent ... and congratulations are due both you and your wife on achieving such an anniversary milestone but, maybe we can get consensus now on this list regards, jdc   Delivery-Date: Fri, 10 Jan 1997 21:27:32 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id VAA13467 for X-agentx; Fri, 10 Jan 1997 21:27:32 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id VAA13464 for ; Fri, 10 Jan 1997 21:27:32 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id AAA10313 for ; Sat, 11 Jan 1997 00:26:52 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma010297; Fri, 10 Jan 97 21:26:22 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id VAA29903 for ; Fri, 10 Jan 1997 21:27:26 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id AAA10294 for ; Sat, 11 Jan 1997 00:26:22 -0500 (EST) Received: from seymour16.snmp.com(192.147.142.16) by gauntlet.fv.com via smap (3.2) id xma010290; Fri, 10 Jan 97 21:25:55 -0800 Received: from seymour4.snmp.com by seymour16.snmp.com with SMTP (5.61++/2.8s-SNMP) id AA14188; Sat, 11 Jan 97 00:26:29 -0500 Date: Sat, 11 Jan 97 00:26:29 -0500 From: Jeff Case Message-Id: <9701110526.AA14188@seymour16.snmp.com> To: agentx@fv.com Subject: Re: Directed Traps jj> = JeffJohnson bert> bert wijnen jj> The agentx-Notify-PDU allows a subagent to specify a context and a jj> variable binding list that is to be used for trap generation. jj> Unfortunately, for some forms of directed traps, this is not enough jj> information. For the purpose of this discussion, there are two kinds jj> of directed traps I'd like to address. jj> jj> The first type of directed trap is found in the RMON MIB. The jj> eventTable is used to determine if an RMON event will generate an SNMP jj> trap, and if so, the associated instance of eventCommunity specifies jj> the communities which are to receive the trap. In other words, the trap jj> should only be directed to those hosts associated with the given jj> community. Unfortunately, the agentx-Notify-PDU does not provide a jj> mechanism for an RMON subagent to tell the master agent the communities jj> to which the trap is to be directed, and hence agentx is unable to jj> correctly support RMON traps. bert>As I have stated before, I do not consider the RMON MIB as an agent bert>MIB but as an MLM MIB and so I consider it outside the scope of bert>agentX for now. i don't understand this rationale, but it is secondary to the main point, below jj> The second type of directed trap is not found in any standard MIB that jj> I am aware of. However, I have seen this type of trap in several vendor jj> MIBs. This type of trap is sent to a single recipient when a service jj> that was requested has completed. Consider a generic "service" MIB. jj> jj> Such a MIB would allow a management application to specify the jj> parameters for a service to be performed, and then activate the jj> service. jj> jj> The management application can monitor a status object to check when the jj> requested service has completed, or alternately can wait for a directed jj> trap that is sent from the agent to the management application when the jj> service has completed. Since this mechanism is not found in any jj> standard MIBs, there is not a requirement to support it, but it would jj> be nice to have this capability. Of course, I recognize that adding this jj> support would require adding a mechanism for the subagent to specify the jj> destination of the trap, and further would require adding a mechanism jj> for the subagent to determine from the master agent where the initial jj> service request came from. bert>I must admit that recently I have been exposed to few situations where bert>this same requirement was mentioned. i agree with jeff (johnson) and bert here ... i too have been exposed to situations where this same requirement was mentioned we had sufficient demand from EMANATE customers that we had to put in code after release 12 to address this requirement (not that i recall jeff johnson being one of those demanding it at the time) they didn't want to have trap destinations solely controlled by the configuration data in the (lpd/lcd or whatever name is in vogue) configuration store held by the master agent we couldn't resist the demands of paying customers ... one important customer had previously had their own extensible agent protocol that had such a feature in order to get them to switch to our technology, we had to add this feature because the could not abandon their installed base and move to a less powerful design ... the new had to have backward compatibility options that allowed them to transition gracefully without loss of function hence, if we wanted to become the new master agent/subagent technology, we had to be able to do what their old master agent/subagent technology did since we wanted that important piece of the market, and because we wanted them to converge toward EMANATE, then we chose to address their requirements anyway, that's what we had to do to move from N extensible agent technologies to N-1 extensible agent technologies ... which is what i think this group wants to do many times over ... rather than create another N+1th incompatible one regards, jdc   Delivery-Date: Fri, 10 Jan 1997 21:39:48 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id VAA14796 for X-agentx; Fri, 10 Jan 1997 21:39:48 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id VAA14793 for ; Fri, 10 Jan 1997 21:39:48 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id AAA10856 for ; Sat, 11 Jan 1997 00:39:08 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma010851; Fri, 10 Jan 97 21:38:39 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id VAA00546 for ; Fri, 10 Jan 1997 21:39:43 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id AAA10848 for ; Sat, 11 Jan 1997 00:38:39 -0500 (EST) Received: from seymour16.snmp.com(192.147.142.16) by gauntlet.fv.com via smap (3.2) id xma010846; Fri, 10 Jan 97 21:38:29 -0800 Received: from seymour4.snmp.com by seymour16.snmp.com with SMTP (5.61++/2.8s-SNMP) id AA16718; Sat, 11 Jan 97 00:39:02 -0500 Date: Sat, 11 Jan 97 00:39:02 -0500 From: Jeff Case Message-Id: <9701110539.AA16718@seymour16.snmp.com> To: agentx@fv.com Subject: Re: Get-Bulk Elements of Procedure i think we are making more progress toward a consensus on this issue Mike Daniele writes: >The problem is that procedure described for the master agent is >too constraining, probably too implementation-specific, and not >optimal in all cases. > >What we need is to strongly define the subagent's procedures, >but be more general in the master agent's. > >For example, the subagent MUST accept request pdus containing >multiple variables, but the master doesn't HAVE to send multiple >variables. > >The subagent MUST adhere to the searchranges, and MUST support >GetBulk, but the master agent doesn't HAVE to send GetBulk. > >The master agent HAS to ensure that the registry is honored. >That is, that ONLY the subagent responsible for a region gets >to get/set the values of variables within that region. > >But if the master chooses to notice that a particular SNMP getbulk >would be optimally handled by AgentX getnexts (because of instance >level registrations, for example) it should be free to do so. and >I think the master agent's dispatching procedures need to be rewritten >to specify much less detail, and permitting this type of behavior. while i think (and have previously indicated) that i think that iterating getbulk in the subagent is inappropriate engineering (optimizing the wrong thing), i think i could live with this compromise position ... i'd like to see the final text, though in some applications, especially when the master is on a different cpu than the subagent, this might be of value ... some customers have asked us for this kind of capability, which we have successfully "talked them out of" so far, but this would be something that agentx could do that EMANATE can't do and would be a motivation for us to move in that direction i still think it is a *really* dumb idea but can live with it in the interest of compromise since mike has been relentless about this "improvement" that he added to dpi when he designed eSNMP -- i preferred dpi on this feature, but i doubt we'll ever convince mike this is essentially what i argued for as a compromise position in san jose but mike wasn't able to be there to support it i don't like it, but it is probably the best we can do if we are ever going to come to agreement regards, jdc   Delivery-Date: Fri, 10 Jan 1997 21:43:48 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id VAA15163 for X-agentx; Fri, 10 Jan 1997 21:43:48 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id VAA15160 for ; Fri, 10 Jan 1997 21:43:48 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id AAA10924 for ; Sat, 11 Jan 1997 00:43:08 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma010922; Fri, 10 Jan 97 21:42:39 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id VAA00727 for ; Fri, 10 Jan 1997 21:43:43 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id AAA10919 for ; Sat, 11 Jan 1997 00:42:38 -0500 (EST) Received: from seymour16.snmp.com(192.147.142.16) by gauntlet.fv.com via smap (3.2) id xma010917; Fri, 10 Jan 97 21:42:28 -0800 Received: from seymour4.snmp.com by seymour16.snmp.com with SMTP (5.61++/2.8s-SNMP) id AA19713; Sat, 11 Jan 97 00:43:01 -0500 Date: Sat, 11 Jan 97 00:43:01 -0500 From: Jeff Case Message-Id: <9701110543.AA19713@seymour16.snmp.com> To: agentx@fv.com Subject: Re: Handling Scalar Objects you know, i think that we are getting off track if we debate whether ifNumber is a good mib object or a bad mib object fact is, it is a mib object, and most of the civilized world is going to expect an agent to be able to implement it if we expect agents to be built from agentx technology, then agentx technology had better be able to implement it, no matter whether we think that the folks who designed it back in '88 had a clue or not people expect the interfaces group ... we'd better be able to implement it or we might as well fold our tents like/dislike has nothing to do with it i suggest we not debate the quality of standards track mibs further here regards, jdc   Delivery-Date: Fri, 10 Jan 1997 21:45:19 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id VAA15314 for X-agentx; Fri, 10 Jan 1997 21:45:18 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id VAA15308 for ; Fri, 10 Jan 1997 21:45:17 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id AAA10962 for ; Sat, 11 Jan 1997 00:44:38 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma010951; Fri, 10 Jan 97 21:44:09 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.7.5/8.7.3) with ESMTP id VAA00750 for ; Fri, 10 Jan 1997 21:45:13 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id AAA10938 for ; Sat, 11 Jan 1997 00:44:08 -0500 (EST) Received: from seymour16.snmp.com(192.147.142.16) by gauntlet.fv.com via smap (3.2) id xma010928; Fri, 10 Jan 97 21:43:46 -0800 Received: from seymour4.snmp.com by seymour16.snmp.com with SMTP (5.61++/2.8s-SNMP) id AA20640; Sat, 11 Jan 97 00:44:17 -0500 Date: Sat, 11 Jan 97 00:44:17 -0500 From: Jeff Case Message-Id: <9701110544.AA20640@seymour16.snmp.com> To: agentx@fv.com Subject: Re: draft-ietf-agentx-ext-pro-01.txt problems Bert writes: >I'll be posting some (belated) comments on postings of December. i, too, will follow your lead JeffJohnson writes (15 Dec 1996) jj> ............................. In particular, I was interested in two jj> classes of products: jj> 1) software applications running on the workstation jj> 2) hardware products with on-board subagents being plugged into the jj> workstation jj> AgentX is of course not limited to these environments, but I do feel jj> that this is where it is most applicable. bert>I very much agree on this. We try to solve 80% of the problem space and bert>these workstation indeed represent a big part of that. so, are you saying that the agent-x design is oriented toward open systems and is not particularly suited toward implementation in embedded systems? is there a consensus about that? i can agree with that if that is your point jj> In evaluating the document from this perspective, it is useful to see jj> how currently existing, applicable MIBs would be implemented in an jj> AgentX environment. In particular, I considered it mandatory that an jj> AgentX master agent with multiple subagents be able to completely jj> implement the following MIBs which should reasonably be expected to be jj> implemented in an AgentX environment. jj> 1) The MIBs Formerly Known as MIB-II jj> 1.1) SNMPv2 MIB bert>Yes, but this one (as we state in the doc) is SNMP admin based and so bert>it is normally implemented within the master agent itself. i agree with bert here jj> 1.2) Interfaces MIB jj> 1.3) IP MIB jj> 1.4) UDP MIB jj> 1.5) TCP MIB jj> 2) Media-specific MIBs jj> 3) Remote Monitoring MIB bert>I do not agree with the requirement to be able to implement the RMON MIB bert>as an agentX based subagent. To me the RMON MIB is more of a MLM MIB than bert>an "agent"-MIB. What I do want to enable is that an RMON implementation bert>can be done such that it can function also in the role of master agent. bert>I made this statement to the mailing list in mid-December also and asked bert>if anybody would implement an RMON-mib using agentX if agentX could handl bert>it. I basically got only one answer that stated that they might consider bert>it in the future, but that right now they use another product. So... we bert>could worry about RMON being inplementable as a sub, but the RMON vendors bert>are not interested it seems. bert, i do not want to be accused of spamming the list again, but snmp research has been shipping an emanate-based rmon subagent for both embedded systems and for open systems for several years now ... the open systems supported include multiple dialects of unix (we have been asked for nt but have not shipped nt-based rmon products yet -- although we have quoted them) in addition to embedded operating systems such as vxworks etc folks who use this software often house it on a node on a segment, often within the satelite equipment room, which serves multiple purposes ... terminal server access to glop in the room, an rmon probe, sometimes an nnstat probe, sometimes a remote data collector, ... they often like to have the rmon probe as a subagent so that it can be started (and stopped) at will, so as to consume resources if and only if desired these users, of course, want their subagent technology for their rmon subagents to be compatible with the subagent technology used by their other subagents and master agents however, this market segment is not growing rapidly what *is* a growing market segment is atm to the open workstation, and many of these implementations include rmon implementations in their atm products rmon on open desktop operating systems isn't freakshow technology and is growing at approximately the same rate as atm i think that there are a number of folks who are interested in using open workstations for atm circuit allocation computations, i.e., to set up virtual circuits and that rmon products are a part of their plans the bottom line is that there are at least two reasons why the rmon mib cannot be implemented by agent-x as currently designed: 1) the registration issues previously articulated by jeff.1 (johnson) 2) no way to implement the alarm/event functions as previously articulated by T. Max Devlin ... but for perhaps a different reason -- how does subagent #1 (an rmon subagent) do a rising edge or falling edge threshold on a mib object found in subagent #2 (any other subagent running on the system) the rmon design did not anticipate implementation in a subagent and many things could have been done to make it easier to implement in a subagent or otherwise but the consensus of the rmon group was to make no changes between proposed and draft that would change any bits on the wire or any (correct) implementations ... only clarifications in any case, i think you need these capabilities to be conformant with rmon, and i do not see how this can done in the current design it seems we have multiple options: 1) change rmon and the other "hard to implement mibs" to fit the agent-x design 2) declare that we simply are not going to be able to implement some mibs via agent-x in a conformant manner, and abandon the ideas that brian o'keefe argued for so effectively in the dallas meeting bob n wrote in one of his messages: bobn>Granted, in my scheme, there are some existing agent bobn>implementations and some MIBs that would have to be bobn>re-designed to fit AgentX. This seems to be counter bobn>to the current consensus of the group...which is bobn>closer to "AgentX must be designed to accommodate bobn>any and all existing agents and MIBs, even though bobn>they were not designed with standardized extensibility bobn>in mind". [And it is truly a tribute to the intelligence, bobn>creativity, effort, and open-mindedness of Mike, Bert, bobn>and Dale that the spec continues to evolve in this bobn>direction.] since rewriting standard mibs (and vendor-specific mibs) is probably not in the charter of the agent-x group, nor is it likely to be, we either need to continue the evolution of the specification to support the implementation of real (not theoretical) smi-compliant mibs or we need to declare that implementation of standard mibs and other mibs is a non-goal and document the reasons for that decision that is essentially what the dmtf did with the dmi -- snmp compliant, but not smi nor standard mib compliant seems like a pretty fundamental watershed decision to me -- and i thought we resolved it in dallas, but i guess i was wrong about that regards, jdc   Delivery-Date: Tue, 14 Jan 1997 14:44:04 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id OAA03021 for X-agentx; Tue, 14 Jan 1997 14:44:04 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id OAA03000 for ; Tue, 14 Jan 1997 14:44:02 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id RAA28873 for ; Tue, 14 Jan 1997 17:43:15 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma028852; Tue, 14 Jan 97 14:42:46 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.4/8.8.4) with ESMTP id OAA28310 for ; Tue, 14 Jan 1997 14:43:54 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id RAA28844 for ; Tue, 14 Jan 1997 17:42:44 -0500 (EST) Message-Id: <199701142242.RAA28844@gauntlet.fv.com> Received: from vnet.ibm.com(199.171.26.4) by gauntlet.fv.com via smap (3.2) id xma028802; Tue, 14 Jan 97 14:42:13 -0800 Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7737; Tue, 14 Jan 97 17:42:34 EST Date: Tue, 14 Jan 97 23:28:14 CET From: "Bert Wijnen" To: agentx@fv.com Subject: registering for ALL contexts from the minutes: >The next item to be discussed (11.3) was the decision to >remove the value "all contexts" for the context field in >the AgentX header. Some felt that by not allowing the >possibility of subagents registering for "all contexts", a >significant percentage of the market for extensible agents >would be unable to use AgentX. It was agreed that there >needed to be more discussion on the list of whether >registration for "all contexts" is necessary. > Is there any substance here? If I read comments that a "significant percentage of the market" would be unable to use agentX, then I assume that those who claim that can at least list a few samples. So any samples? See if it is that a sub-agent is just lazy and does not want to figure out which context(s) it supports, then that is no argument. To me... if you talk about a sub-agent that wants to handle ALL contexts, then to me that sounds like you want to implement ONE BIG MONOLITHIC subagent ... while we try to allow for nice moularity. Bert   Delivery-Date: Tue, 14 Jan 1997 14:44:33 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id OAA03054 for X-agentx; Tue, 14 Jan 1997 14:44:32 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id OAA03051 for ; Tue, 14 Jan 1997 14:44:32 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id RAA28895 for ; Tue, 14 Jan 1997 17:43:44 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma028889; Tue, 14 Jan 97 14:43:18 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.4/8.8.4) with ESMTP id OAA28335 for ; Tue, 14 Jan 1997 14:44:25 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id RAA28875 for ; Tue, 14 Jan 1997 17:43:15 -0500 (EST) Message-Id: <199701142243.RAA28875@gauntlet.fv.com> Received: from vnet.ibm.com(199.171.26.4) by gauntlet.fv.com via smap (3.2) id xma028855; Tue, 14 Jan 97 14:42:51 -0800 Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7795; Tue, 14 Jan 97 17:43:20 EST Date: Tue, 14 Jan 97 23:29:42 CET From: "Bert Wijnen" To: agentx@fv.com Subject: multiple indices and shared indices from the minutes: >There was a great deal of discussion about index allocation >and instance reservation. Many felt that there was >insufficient support for multiply-indexed tables in the >current protocol draft, and that, in fact, the current >index allocation scheme only worked for singly-indexed, >arbitrary integer tables. The example was given of a table >with two index objects, the first of which is shared. Since >indices must be allocated one at a time, it would be >impossible for subagent A to get an allocation for, say, >"1.2", and subagent B to allocate "1.3". > I do not understand. I can (in one PDU) ask for 2 indices can I not. You can have multiple varBinds, so multiple indices is no problem. I do see the problem with a "shared" index. Now.. if you "share" such an index, then I think subs should know which one to share, no? And if they know, then they do not have to allocate, or only one of them needs to allocate, and the next one knows it shares it with another sub, and so the fact that it cannot allocate the one that it wants means that someone already has it. We could add a SHARE_INDEX flag to let people specify this... but I am not sure that it will really help. Another solution might be that if you send an ReserveIndex request that you list all indices, and that as long as the complete instance has not been reserved that you will succeed. This does make processing at the master more complex though. Bert   Delivery-Date: Tue, 14 Jan 1997 14:47:34 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id OAA03262 for X-agentx; Tue, 14 Jan 1997 14:47:33 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id OAA03258 for ; Tue, 14 Jan 1997 14:47:33 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id RAA29248 for ; Tue, 14 Jan 1997 17:46:45 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma029196; Tue, 14 Jan 97 14:46:16 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.4/8.8.4) with ESMTP id OAA28529 for ; Tue, 14 Jan 1997 14:47:24 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id RAA29181 for ; Tue, 14 Jan 1997 17:46:15 -0500 (EST) Message-Id: <199701142246.RAA29181@gauntlet.fv.com> Received: from vnet.ibm.com(199.171.26.4) by gauntlet.fv.com via smap (3.2) id xma029170; Tue, 14 Jan 97 14:46:13 -0800 Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 7923; Tue, 14 Jan 97 17:46:41 EST Date: Tue, 14 Jan 97 23:32:37 CET From: "Bert Wijnen" To: agentx@fv.com Subject: agentX goals/non-goals JeffJohnson writes (15 Dec 1996) jj> ............................. In particular, I was interested in two jj> classes of products: jj> 1) software applications running on the workstation jj> 2) hardware products with on-board subagents being plugged into the jj> workstation jj> AgentX is of course not limited to these environments, but I do feel jj> that this is where it is most applicable. bert>I very much agree on this. We try to solve 80% of the problem space bert>and these workstation indeed represent a big part of that. jdc> so, are you saying that the agent-x design is oriented toward open jdc> system and is not particularly suited toward implementation in jdc> embedded systems is there a consensus about that? i can agree with jdc> that if that is your point > The above would not be my wording. Support for embedded systems is fine. There are however many types of embedded systems, and some of those are so complex that we do not particularly tailor for them. I think that THERE IS CONSENSUS that the forst version of agentX does not need to cover 100% of the problem space. Virtually no standards have ever been able to get everything right and covered the first time. Look at the SNMP protocol, MIB II, the ifMIB, the RMON MIB etc etc. So I am trying to say that we should shoot for 80% coverage of problem space... and that we do not need to cover all the special and fancy systems that exist today. They have a working solution (possibly Emanate). We need to find a standard and simple solution for the vast majority of "instrumentation-code-still-to-be-done" out there. We are not necessarily after the market of selling complete SNMP source code. We want all those systems that now ship (for free) SNMP agents with their Operating System (like all unix-es, OS/2, W95, NT, VMS, etc ect). We want those systems to ship an agent into which 3rd party vendors can plus their application related MIBs and such. Bert   Delivery-Date: Tue, 14 Jan 1997 14:49:33 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id OAA03415 for X-agentx; Tue, 14 Jan 1997 14:49:33 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id OAA03412 for ; Tue, 14 Jan 1997 14:49:32 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id RAA29308 for ; Tue, 14 Jan 1997 17:48:45 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma029300; Tue, 14 Jan 97 14:48:16 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.4/8.8.4) with ESMTP id OAA28664 for ; Tue, 14 Jan 1997 14:49:25 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id RAA29297 for ; Tue, 14 Jan 1997 17:48:15 -0500 (EST) Message-Id: <199701142248.RAA29297@gauntlet.fv.com> Received: from vnet.ibm.com(199.171.26.4) by gauntlet.fv.com via smap (3.2) id xma029292; Tue, 14 Jan 97 14:48:14 -0800 Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 8028; Tue, 14 Jan 97 17:48:40 EST Date: Tue, 14 Jan 97 23:35:30 CET From: "Bert Wijnen" To: agentx@fv.com Subject: no need to support RMON (MLM) jdc writes: >bert, i do not want to be accused of spamming the list again, but snmp >research has been shipping an emanate-based rmon subagent for both embed >ded systems and for open systems for several years now..the open systems >supported include multiple dialects of unix (we have been asked for nt >but have not shipped nt-based rmon products yet -- although we have >quoted them in addition to embedded operating systems such as vxworks >etc. >folks who use this software often house it on a node on a segment, often >within the satelite equipment room, which serves multiple purposes ... >terminal server access to glop in the room, an rmon probe, sometimes an >nnstat probe, sometimes a remote data collector, ... > >they often like to have the rmon probe as a subagent so that it can be >started (and stopped) at will, so as to consume resources if and only if >desired > >these users, of course, want their subagent technology for their rmon >subagents to be compatible with the subagent technology used by their >other subagents and master agents > Jeff, again, RMON is a mid-level manager. We're looking for extensible AGENTs, not extensible MLMs. See my earlier posting also. I can understand that your customers want an AGENT that supports their existing RMON "sub-agent" and that they ALSO want that agent to allow other subagents that adhere to a standard (agentX if we can get there). So what that means for you is that you should try to support agentX in addition to Emanate. So your customers will be happy. You provide something extra that a lot of other vendors probably do not provide, so they stick to you as a provider. Isn't this team nice to you ;-). So all these customers need is a new (payed for guess) level of Emanate that also supports agentX. They would not have to change their existing code and new agentX based subagents will work with your package, no? In fact the one vendor who reacted to my question as to who would be willing to considere agentX for an RMON implementation is Bay (they have posted that to this list in the meanwhile). However, they already are using your Emanate, and so they can continue to do so. Bert   Delivery-Date: Tue, 14 Jan 1997 14:51:04 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id OAA03632 for X-agentx; Tue, 14 Jan 1997 14:51:04 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id OAA03622 for ; Tue, 14 Jan 1997 14:51:03 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id RAA29374 for ; Tue, 14 Jan 1997 17:50:16 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma029347; Tue, 14 Jan 97 14:49:46 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.4/8.8.4) with ESMTP id OAA28816 for ; Tue, 14 Jan 1997 14:50:55 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id RAA29343 for ; Tue, 14 Jan 1997 17:49:46 -0500 (EST) Message-Id: <199701142249.RAA29343@gauntlet.fv.com> Received: from vnet.ibm.com(199.171.26.4) by gauntlet.fv.com via smap (3.2) id xma029316; Tue, 14 Jan 97 14:49:23 -0800 Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 8065; Tue, 14 Jan 97 17:49:26 EST Date: Tue, 14 Jan 97 23:36:32 CET From: "Bert Wijnen" To: agentx@fv.com Subject: which mibs do we or can we support Jeff Case writes: >it seems we have multiple options: > 1) change rmon and the other "hard to implement mibs" to fit the > agent-x design > No, we do not want to do this. > 2) declare that we simply are not going to be able to implement > some mibs via agent-x in a conformant manner, and abandon the > ideas that brian o'keefe argued for so effectively in the dallas > meeting > We may have to state that some MIBs (RMON is an example) will not be implementable as a subagent using the 1st version of agentX. I am not sure why that abandons the ideas of BOK, I tried to look them up, the ideas I could find back in the mailing list are still in tact. Can you explain which one we would have to abandon? Bert   Delivery-Date: Tue, 14 Jan 1997 16:40:46 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id QAA13261 for X-agentx; Tue, 14 Jan 1997 16:40:45 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id QAA13258 for ; Tue, 14 Jan 1997 16:40:45 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id TAA08255 for ; Tue, 14 Jan 1997 19:39:55 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma008248; Tue, 14 Jan 97 16:39:36 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.4/8.8.4) with ESMTP id QAA08626 for ; Tue, 14 Jan 1997 16:40:34 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id TAA08232 for ; Tue, 14 Jan 1997 19:39:25 -0500 (EST) Received: from mail4.microsoft.com(131.107.3.29) by gauntlet.fv.com via smap (3.2) id xma008208; Tue, 14 Jan 97 16:39:00 -0800 Received: by INET-04-IMC.itg.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC0239.CDA0CC30@INET-04-IMC.itg.microsoft.com>; Tue, 14 Jan 1997 16:41:34 -0800 Message-ID: From: Don Ryan To: "'Bert Wijnen'" Cc: "'agentx@fv.com'" Subject: RE: Unionized Registration Requirement Date: Tue, 14 Jan 1997 16:39:16 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 75 TEXT Hi Bert, Why can't arbitration be solved via the priority attribute? I thought that what it was for. I suggest we let the AgentX master agent accept any number of registrations for the same MIB region but specify that each registration must be done at a different priority or the registration will fail. Furthermore, instead of having overlapping MIB regions hide one another as is specified in the current draft, I suggest that each subagent in the union be considered for reads as well as writes on the basis of priority. For SETs, n AgentX master agent sends out N agentx-Test-PDUs n AgentX master agent waits for each response to arrive n If more than one positive response is received, the highest priority subagent gets the agentx-Commit-PDU n All other subagents get an agentx-Cleanup-PDU For GETNEXTs, n AgentX master agent sends out N agentx-GetNext-PDUs n AgentX master agent waits for each response to arrive n Each returned OID is examined to determine which lexographically follows the original n If more the one lexographically correct response is received with the same instance identifier, the highest priority subagent's VB is returned For GETs, n AgentX master agent sends out N agentX-Get-PDUs n AgentX master agent DOES NOT wait for each response to arrive n AgentX master agent processes reponses in order of priority (may also serialize sends based on priority) n The VB of the highest priority subagent with a positive response is returned As Randy Presuhn has pointed out in his detailed analysis of duplicate registration, this does incur additional processing overhead but since this overhead is a function of the number of duplicate registrations the overhead should not be a showstopper. Comments? Cheers, Don -----Original Message----- From: Bert Wijnen [SMTP:wijnen@vnet.ibm.com] Sent: Friday, January 10, 1997 3:31 AM To: agentx@fv.com Subject: Unionized Registration Requirement JeffJohnson writes: > ................... So here is the show stopper. Without unionized > registrations, there is no way to support row creation in arbitrarily > indexed tables. > Yep, that sounds like a serious problem. And I agree that the suggested work-around with a sort of a "arbitrating subagent" that handles the SET and then spawns another child does sem ugly... We need to work on this more Bert ---------------- This e-mail message was sent to all subscribers to the agentx mailing list. To unsubscribe from this mailing list, please send mail to: agentx-request@fv.com with Subject: unsubscribe your.address@your.domain (NOTE: Please do not reply to this message to unsubscribe. You must send your request to agentx-request@fv.com Thank you.)   Delivery-Date: Tue, 14 Jan 1997 17:26:47 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id RAA16944 for X-agentx; Tue, 14 Jan 1997 17:26:46 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id RAA16941 for ; Tue, 14 Jan 1997 17:26:46 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id UAA10417 for ; Tue, 14 Jan 1997 20:25:57 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma010408; Tue, 14 Jan 97 17:25:29 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.4/8.8.4) with ESMTP id RAA11164 for ; Tue, 14 Jan 1997 17:26:38 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id UAA10403 for ; Tue, 14 Jan 1997 20:25:28 -0500 (EST) Received: from igw3.watson.ibm.com(129.34.139.18) by gauntlet.fv.com via smap (3.2) id xma010394; Tue, 14 Jan 97 17:25:04 -0800 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id UAA10492; Tue, 14 Jan 1997 20:26:22 -0500 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by mailhub1.watson.ibm.com (8.8.2/11-26-96) with SMTP id UAA75333; Tue, 14 Jan 1997 20:25:40 -0500 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA57012; Tue, 14 Jan 1997 20:25:39 -0500 From: Uri Blumenthal Message-Id: <9701150125.AA57012@hawpub.watson.ibm.com> Subject: Re: Unionized Registration Requirement To: donryan@microsoft.com (Don Ryan) Date: Tue, 14 Jan 1997 20:25:39 -0500 (EST) Cc: wijnen@vnet.ibm.com, agentx@fv.com In-Reply-To: from "Don Ryan" at Jan 14, 97 04:39:16 pm Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text Don Ryan says: > Why can't arbitration be solved via the priority attribute? In my opinion, this violates the simplicity requirement. In short - yes, it's doable, but it's (a) ugly; (b) too complicated to deal with comfortably; (c) it does not really solve the issue who "should" be responsible for the objects - the fact that sub' 1 succeeds performing the operation and sub' 2 fails, does not necessarily means that we can return the success of sub'1 as a result (or a failure of sub'2). In my opinion, cost far outweights the benefits. Please, please, let's behave as if we really had to implement it and then maintain the code ourselves (:-). -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Wed, 15 Jan 1997 03:47:21 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id DAA07734 for X-agentx; Wed, 15 Jan 1997 03:47:21 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id DAA07731 for ; Wed, 15 Jan 1997 03:47:20 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id GAA01412 for ; Wed, 15 Jan 1997 06:46:31 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma001408; Wed, 15 Jan 97 03:46:01 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.4/8.8.4) with ESMTP id DAA01901 for ; Wed, 15 Jan 1997 03:47:11 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id GAA01405 for ; Wed, 15 Jan 1997 06:46:00 -0500 (EST) Message-Id: <199701151146.GAA01405@gauntlet.fv.com> Received: from vnet.ibm.com(199.171.26.4) by gauntlet.fv.com via smap (3.2) id xma001403; Wed, 15 Jan 97 03:45:45 -0800 Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1198; Wed, 15 Jan 97 06:46:17 EST Date: Wed, 15 Jan 97 12:47:43 CET From: "Bert Wijnen" To: donryan@MICROSOFT.com, agentx@fv.com Subject: Unionized Registration Requirement Ref: Your note of Tue, 14 Jan 1997 16:39:16 -0800 Subject: Unionized registration Don writes: >Hi Bert, > Hi Don, >Why can't arbitration be solved via the priority attribute? I thought that > First there is of course the fact that unionized registrations make the process much more complex at the master agent. And if we want people to actally implement fully compliant master agents, we cannot make it more difficult than absolutely required (certainly for the first version... I fimrly believe that the big success of SNMP is the result of the fact that version 1 was so SIMPLE). But see below for more reasons. >what it was for. I suggest we let the AgentX master agent accept any >number of registrations for the same MIB region but specify that each >registration must be done at a different priority or the registration will >fail. Furthermore, instead of having overlapping MIB regions hide one >another as is specified in the current draft, I suggest that each subagent >in the union be considered for reads as well as writes on the basis of >priority. > >For SETs, > >n AgentX master agent sends out N agentx-Test-PDUs >n AgentX master agent waits for each response to arrive >n If more than one positive response is received, the highest > priotity subagent gets the agentx-Commit-PDU > Here is where I do not feel comfortable. It would mean that responses would be inconsistent and unpredictable. If subA has the best priority and fails to repond to the SET for some reason, then subB would get it, while I think we should return an error. Consider that we have a SET for multiple varBinds say 3. They are all in the same registration tree (for which we have multiple registrations). Now we send 3 agentx-TestAndSet-PDUs to the 3 subagents. The first one The 1st sub tells me vb1=noError, vb2=noCreation, vb3=inconsistentName The 2nd sub tells me vb1=noCreation, vb2=noError, vb3=noError The 3rd sub tells me vb1=noCreation, vb2=noError, vb3=inconsistentName So now as a master agent, what do I do?? Can you see how complex it becomes and how different implementations may return different results? Are there other opinions on the INCONSISTENCY RISK that we would create if we did this? I personally would vote against it... but I am just one player, right? >n All other subagents get an agentx-Cleanup-PDU > >For GETNEXTs, > >n AgentX master agent sends out N agentx-GetNext-PDUs >n AgentX master agent waits for each response to arrive >n Each returned OID is examined to determine which lexographically > follows the original >n If more the one lexographically correct response is received > with the same instance identifier, the highest priority > subagent's VB is returned > >For GETs, > >n AgentX master agent sends out N agentX-Get-PDUs >n AgentX master agent DOES NOT wait for each response to arrive >n AgentX master agent processes reponses in order of priority > (may also serialize sends based on priority) >n The VB of the highest priority subagent with a positive > response is returned > >As Randy Presuhn has pointed out in his detailed analysis of duplicate >registration, this does incur additional processing overhead but since >this overhead is a function of the number of duplicate registrations the >overhead should not be a showstopper. Comments? > Mmmmm... in my set of target environments for agentX there would be virtually no duplicate registrations, so overhead would be minimal if any.... (yet these people had to pay for the complexity of the code). In the situation where JeffJonson refers to (ipRouteTable), there will be a lot of overhead I guess. Also... for GETBULK this process even becomes more complex. Bert   Delivery-Date: Wed, 15 Jan 1997 06:20:22 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id GAA19170 for X-agentx; Wed, 15 Jan 1997 06:20:22 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id GAA19167 for ; Wed, 15 Jan 1997 06:20:21 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id JAA03036 for ; Wed, 15 Jan 1997 09:19:30 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma003028; Wed, 15 Jan 97 06:19:02 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.4/8.8.4) with ESMTP id GAA05771 for ; Wed, 15 Jan 1997 06:20:11 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id JAA03017 for ; Wed, 15 Jan 1997 09:19:00 -0500 (EST) Received: from mail2.microsoft.com(131.107.3.42) by gauntlet.fv.com via smap (3.2) id xma003011; Wed, 15 Jan 97 06:18:47 -0800 Received: by INET-02-IMC.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC02AC.0FDB6C00@INET-02-IMC.microsoft.com>; Wed, 15 Jan 1997 06:19:28 -0800 Message-ID: From: Don Ryan To: "'Bert Wijnen'" Cc: "'agentx@fv.com'" Subject: RE: Unionized Registration Requirement Date: Wed, 15 Jan 1997 06:20:45 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 148 TEXT Hi Bert, I fully understand the fact that unionized registration makes life difficult for the master agent but it was my impression from the meeting in San Jose that a consensus existed among the active members of the audience (perhaps Uri excluded) that the idea of unionized registration needed to be revisited because table sharing via index allocation and instance level registration may not be practical in all cases (e.g., the ipRouteTable). Furthermore, there was at least one other person at the IETF meeting who agreed with my opinion that it may NOT be such a good idea to have a subagent's table entries completely hidden by other subagents registering more specific OIDs. If I register ip and you later register ipRouteTable then any ipRouteTable entries I may support will never be returned because of the current dispatch mechanism. I am still struggling to understand why this is a good thing as I thought the point of the exercise was to enable table sharing. I think the only way to move forward quickly on this protocol (and this is certainly something I would like to do) is to put the issue of unionized registration to rest one way or another. I think the only way to do this properly is to sketch out a q&d design based on unionized registration and see it we can make a.) make it work properly and b.) make it reasonable as possible to implement. My previous post was only meant to be a starting point in this direction. I definitely agree that great care needs to be taken in defining the elements of procedure in order to eliminate any risk of inconsistency but I think if these procedures are spelled out correctly we can trust developers to implement them properly. As far as your example below, this would be my take: Assume SA1 is higher in priority than SA2 who is higher in priority than SA3. - master agent receives VBL containing VB1, VB2, and VB3 which are in a region supported by all three. - master agent sends agentx-TestSet-PDU containing VB1, VB2, and VB3 to all three - master agent waits for the response from each subagent - SA1 returns errorStatus=noCreation, errorIndex=2 - SA2 returns errorStatus=noCreation, errorIndex=1 - SA3 returns errorStatus=noCreation, errorIndex=1 - master agent assumes at this point that SA1 will handle VB1 - master agent sends agentx-TestSet-PDU containing VB1 and VB3 to SA1 - master agent sends agentx-TestSet-PDU containing VB2 and VB3 to SA2 and SA3 - SA1 returns errorStatus=inconsistentName, errorIndex=3 - SA2 returns errorStatus=noError, errorIndex=0 - SA3 returns errorStatus=inconsistentName, errorIndex=3 - since SA1 is the highest priority subagent then master returns errorStatus=inconsistentName, errorIndex=3 If SA1 returned errorStatus=noError then the write should continue regardless of the results returned by SA3 since each varbind has been validated by higher priority subagents. - master agent sends agentx-TestSet-PDU containing VB1 and VB3 to SA1 - master agent sends agentx-TestSet-PDU containing VB2 and VB3 to SA2 and SA3 - SA1 returns errorStatus=noError, errorIndex=0 - SA2 returns errorStatus=noError, errorIndex=0 - SA3 returns errorStatus=inconsistentName, errorIndex=3 - master agent assumes at this point that SA1 will handle VB1 & VB3 - master agent sends agentx-Cleanup-PDU to SA2 // we could eliminate this step with a PDU serial number - master agent sends agentx-TestSet-PDU containing VB2 to SA2 - if SA2 returns errorStatus=noError, the write operation proceeds to the commit phase - if SA2 returns errorStatus=noCreation, then master agent sends agentx-TestSet-PDU containing VB2 to SA3 - if SA2 returns errorStatus!=noError && errorStatus!=noCreation then master agent returns errorStatus If you think the procedure above would cause a lot of overhead think about N subagents trying to constantly keep the master agent up to date by continually registering instances of ipRouteTable. I am of the opinion that we should eliminate GETBULK from AgentX version 1 and instead implement PDU serial numbers to optimize caching. As a subagent, if I get a agentx-GetNext-PDU with the same serial number as the previous one then I know the VBL included is being returned in the same SNMP PDU as the previously requested VBL and I can safely choose not need to refresh my cache. Cheers, Don -----Original Message----- From: Bert Wijnen [SMTP:wijnen@VNET.IBM.COM] Sent: Wednesday, January 15, 1997 4:48 AM To: Don Ryan; agentx@fv.com Subject: Unionized Registration Requirement Ref: Your note of Tue, 14 Jan 1997 16:39:16 -0800 Subject: Unionized registration >Why can't arbitration be solved via the priority attribute? I thought that > First there is of course the fact that unionized registrations make the process much more complex at the master agent. And if we want people to actally implement fully compliant master agents, we cannot make it more difficult than absolutely required (certainly for the first version... I fimrly believe that the big success of SNMP is the result of the fact that version 1 was so SIMPLE). But see below for more reasons. >For SETs, > >n AgentX master agent sends out N agentx-Test-PDUs >n AgentX master agent waits for each response to arrive >n If more than one positive response is received, the highest > priotity subagent gets the agentx-Commit-PDU > Here is where I do not feel comfortable. It would mean that responses would be inconsistent and unpredictable. If subA has the best priority and fails to repond to the SET for some reason, then subB would get it, while I think we should return an error. Consider that we have a SET for multiple varBinds say 3. They are all in the same registration tree (for which we have multiple registrations). Now we send 3 agentx-TestAndSet-PDUs to the 3 subagents. The first one The 1st sub tells me vb1=noError, vb2=noCreation, vb3=inconsistentName The 2nd sub tells me vb1=noCreation, vb2=noError, vb3=noError The 3rd sub tells me vb1=noCreation, vb2=noError, vb3=inconsistentName So now as a master agent, what do I do?? Can you see how complex it becomes and how different implementations may return different results? Are there other opinions on the INCONSISTENCY RISK that we would create if we did this? I personally would vote against it... but I am just one player, right? > >As Randy Presuhn has pointed out in his detailed analysis of duplicate >registration, this does incur additional processing overhead but since >this overhead is a function of the number of duplicate registrations the >overhead should not be a showstopper. Comments? > Mmmmm... in my set of target environments for agentX there would be virtually no duplicate registrations, so overhead would be minimal if any.... (yet these people had to pay for the complexity of the code). In the situation where JeffJonson refers to (ipRouteTable), there will be a lot of overhead I guess. Also... for GETBULK this process even becomes more complex. Bert   Delivery-Date: Wed, 15 Jan 1997 06:35:53 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id GAA20287 for X-agentx; Wed, 15 Jan 1997 06:35:53 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id GAA20284 for ; Wed, 15 Jan 1997 06:35:52 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id JAA03275 for ; Wed, 15 Jan 1997 09:35:02 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma003269; Wed, 15 Jan 97 06:34:32 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.4/8.8.4) with ESMTP id GAA06263 for ; Wed, 15 Jan 1997 06:35:41 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id JAA03264 for ; Wed, 15 Jan 1997 09:34:31 -0500 (EST) Received: from puli.cisco.com(171.69.1.174) by gauntlet.fv.com via smap (3.2) id xma003260; Wed, 15 Jan 97 06:34:31 -0800 Received: from [171.69.128.42] (gryphon.cisco.com [171.69.128.42]) by puli.cisco.com (8.6.12/8.6.5) with ESMTP id GAA02447 for ; Wed, 15 Jan 1997 06:35:18 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: In-Reply-To: <199701142248.RAA29297@gauntlet.fv.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-pression: awestruck amazement Date: Wed, 15 Jan 1997 09:29:20 -0500 To: agentx@fv.com From: Bob Stewart Subject: Re: no need to support RMON (MLM) Circa 11:35 PM +0000 1/14/97, Bert Wijnen bitwhacked: >Jeff, again, RMON is a mid-level manager. We're looking for extensible >AGENTs, not extensible MLMs. See my earlier posting also. Mid-level managers and top level managers have agents, too. We have a really bad habit of using "agent" to mean a managed system, and assuming that system doesn't do management functions. An agent is a low-level management process that speaks SNMP and moves data in and out of a MIB. A MIB might be the remote control for a high-level, mid-level or low-level management application as well as for a driver or a protocol. We shouldn't aim our work only at systems that have no manager functions in them. The amount of management function in a given system can fit anywhere in the full range from 0% to 100%. Any of them can be part of a distributed system, subject to remote management via an agent. Bob   Delivery-Date: Wed, 15 Jan 1997 11:05:06 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id LAA16563 for X-agentx; Wed, 15 Jan 1997 11:05:05 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id LAA16560 for ; Wed, 15 Jan 1997 11:05:05 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id OAA18496 for ; Wed, 15 Jan 1997 14:04:14 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma018484; Wed, 15 Jan 97 11:03:47 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.4/8.8.4) with ESMTP id LAA01011 for ; Wed, 15 Jan 1997 11:04:57 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id OAA18474 for ; Wed, 15 Jan 1997 14:03:45 -0500 (EST) Received: from mail13.digital.com(192.208.46.30) by gauntlet.fv.com via smap (3.2) id xma018430; Wed, 15 Jan 97 11:03:16 -0800 Received: from quarry.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id LAA04879; Wed, 15 Jan 1997 11:31:37 -0500 (EST) Received: from bernie.zk3.dec.com by quarry.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA05210; Wed, 15 Jan 1997 11:33:01 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA08304; Wed, 15 Jan 1997 11:26:57 -0500 Message-Id: <9701151626.AA08304@bernie.zk3.dec.com> To: agentx@fv.com Subject: Unionized Registration vis a vis MIB partitioning Date: Wed, 15 Jan 97 11:26:56 -0500 From: Mike Daniele X-Mts: smtp The discussions about "unionized" registration touch on 3 distinct subjects: - MIB partitioning between subagents - Row creation in shared tables - Distributed scalars (ifNumber) Rergarding the first one only: Don Ryan said: >Hi Bert, >I fully understand the fact that unionized registration makes life >difficult for the master agent but it was my impression from the meeting in >San Jose that a consensus existed among the active members of the audience >(perhaps Uri excluded) that the idea of unionized registration needed to be >revisited because table sharing via index allocation and instance level >registration may not be practical in all cases (e.g., the ipRouteTable). A nit: The current draft does not *require* fully qualified instances for registering in shared tables. It requires enough of the instance to make a unique region oid (which will frequently be a fqi). I think we all agree that this mechanism is not practical in all cases. I think there is disagreement in what this means to AgentX. The benefits of the current draft's registration and dispatching scheme are that it is simple, and it is deterministic. For any given set of registrations, the same subagent is always responsible for any particular region/tree/oid. The weakness is that some MIBs can only be partitioned by registering fqi-s, and that may not be practical (due to highly dynamic rows for example). With unionized registrations, things become somewhat more complex, and they become non-deterministic. Different subagents can become responsible for a particular region/tree/oid when servicing different requests. Also, there is no way to specify in the elements of procedure exactly what the master agent should do (at least I haven't seen anything, other than "choose the 'best' response"). But the partitioning issue goes away. My opinion is that the number of MIBs that can't be partitioned reasonably between subagents usng the current draft, AND whose implementation is likely to be shared between subagents produced by different vendors (and hence that require an internet standard protocol) is very small. Therefore the conclusion I come to is that the current registration mechanism is more suitable to an internet draft than unionized registrations, WITH RESPECT TO MIB PARTITIONING. Your thoughts welcome. The MIBs I have seen/heard referenced as examples of why we need unionized registrations are tcpConnTable, ifTable, ipRouteTable, and RMON. The first 2 can be partitioned reasonably, the last 2 probably cannot. RMON has already had some discussion, and I am personally comfortable with a v1 AgentX that can't handle it. I'm finding it hard to imagine a system where ip routing is implemented by different vendors plug-ins on the same system. Do you have such a requirement Don? >Furthermore, there was at least one other person at the IETF meeting who >agreed with my opinion that it may NOT be such a good idea to have a >subagent's table entries completely hidden by other subagents registering >more specific OIDs. If I register ip and you later register ipRouteTable >then any ipRouteTable entries I may support will never be returned because >of the current dispatch mechanism. I am still struggling to understand why >this is a good thing as I thought the point of the exercise was to enable >table sharing. I believe there was wide-spread consensus for the "most-qualified wins" approach. It's the glue that holds everything together. I differentiate between planned-for table sharing (ifTable) and accidental table sharing (like the example you described above). The latter is a configuration "error". You have 2 subagents each claiming they support the entire table. They are not intending to share it. This is just another example of arbitrary overlapping registrations, and should be handled like any other. At least, that's how I view it. > I think the only way to move forward quickly on this >protocol (and this is certainly something I would like to do) is to put the >issue of unionized registration to rest one way or another. I think the >only way to do this properly is to sketch out a q&d design based on >unionized registration and see it we can make a.) make it work properly and >b.) make it reasonable as possible to implement. My previous post was only >meant to be a starting point in this direction. I agree with you, and will be posting wrt the other 2 areas of unionized registrations to at least provide explicit threads for discussion. >I am of the opinion that we should eliminate GETBULK from AgentX version 1 >and instead implement PDU serial numbers to optimize caching. As a >subagent, if I get a agentx-GetNext-PDU with the same serial number as the >previous one then I know the VBL included is being returned in the same >SNMP PDU as the previously requested VBL and I can safely choose not need >to refresh my cache. But without seeing max_repetitions, you don't know how far ahead to fetch/cache. You also lose the performance gain of exchanging a single PDU as opposed to max_repetitions pdus. A somewhat separate issue (#10 in the draft) is that if multiple PDUs for Next/Bulk are sent to a subagent, it cannot correlate them to the same SNMP request PDU. Do you feel that's an important issue? Thanks for your input, Mike   Delivery-Date: Thu, 16 Jan 1997 05:53:00 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id FAA22675 for X-agentx; Thu, 16 Jan 1997 05:53:00 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id FAA22672 for ; Thu, 16 Jan 1997 05:52:59 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id IAA02614 for ; Thu, 16 Jan 1997 08:52:06 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma002607; Thu, 16 Jan 97 05:51:38 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.4/8.8.4) with ESMTP id FAA29216 for ; Thu, 16 Jan 1997 05:52:49 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id IAA02600 for ; Thu, 16 Jan 1997 08:51:36 -0500 (EST) Received: from unknown(38.234.93.2) by gauntlet.fv.com via smap (3.2) id xma002588; Thu, 16 Jan 97 05:51:31 -0800 Received: by server1.cadia.com with Microsoft Exchange (IMC 4.0.837.3) id <01BC038A.66457750@server1.cadia.com>; Thu, 16 Jan 1997 08:51:01 -0500 Message-ID: From: Steve Sherry To: "'agentx@fv.com'" Subject: unsubscribe Date: Thu, 16 Jan 1997 08:50:53 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.837.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit   Delivery-Date: Thu, 16 Jan 1997 14:17:07 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id OAA08073 for X-agentx; Thu, 16 Jan 1997 14:16:56 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id OAA08070 for ; Thu, 16 Jan 1997 14:16:55 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id RAA02424 for ; Thu, 16 Jan 1997 17:16:01 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma002418; Thu, 16 Jan 97 14:15:36 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.4/8.8.4) with ESMTP id OAA12269 for ; Thu, 16 Jan 1997 14:16:42 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id RAA02399 for ; Thu, 16 Jan 1997 17:15:30 -0500 (EST) Received: from mail5.microsoft.com(131.107.3.31) by gauntlet.fv.com via smap (3.2) id xma002386; Thu, 16 Jan 97 14:15:05 -0800 Received: by INET-05-IMC.itg.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC03B8.0BAE2840@INET-05-IMC.itg.microsoft.com>; Thu, 16 Jan 1997 14:17:46 -0800 Message-ID: From: Don Ryan To: "'Mike Daniele'" , "'agentx@fv.com'" Subject: RE: Unionized Registration vis a vis MIB partitioning Date: Thu, 16 Jan 1997 14:16:17 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 216 TEXT Hi Mike, I absolutely agree that - MIB partitioning between subagents - Row creation in shared tables - Distributed scalars (ifNumber) all need to addressed in the AgentX specification as well as in any q&d design involving unionized registration. I think the row creation problem goes away in the procedure that I have sketched out because the highest priority subagent who can create the row does so. I am still struggling with distributed scalars but I can tell you that any solution involving forking off child subagents is unacceptable. Now back to MIB partitioning between subagents... The question is whether we are willing to live with a warning label on AgentX products saying "Please do not use this product to implement MIB tables with highly dynamic rows as this could lead to system meltdown". I do not think we should dismiss support for highly dynamic rows (let's call them HDRs) simply because "RMON should really be implemented in a MLM" or "it is hard to imagine vendors sharing the ipRouteTable." I think we need to make the decision based on the following: - Is HDR support necessary to implement MIBs today? - Will HDR support be necessary to implement MIBs tomorrow? The answer to both of these questions is clearly yes. Your assertion has been that the MIBs that need HDR support will never amount to more than 20% of the total and therefore can be safely ignored. This assertion was challenged in San Jose by more than one individual (perhaps more for the "safely ignored" portion than anything else) and it was agreed to investigate unionized registration further. The Windows NT 4.0 Server includes a software sniffer today that used in conjunction with the Microsoft Systems Management Server works like a probe to remotely analyze network traffic (the agent transfers statistics until the sniff has ended and then transfers the network packets). It is not outside the realm of possibility that someday this will be converted to RMON and implemented as an extensible agent though I have certainly not investigated this possibility very thoroughly nor is it on anybody's development schedule. I think including a serial number in the agentx-PDUs which binds them to the snmp-PDU is important regardless of whether or not GETBULK is eliminated. The point is to supply a context in those cases where subagents receive more than one agentx-PDU during the processing of a single snmp-PDU. I think eliminating GETBULK and using a serial number with GETNEXT would (in order of importance): - simplify writing a subagent (something not discussed a lot as of yet) - simplify the PDU encodings (as this would eliminate the need for SearchRange) - simplify writing the master agent GETBULK dispatching/merging code - simplify designs involving unionized registration The price is forcing the subagent to transfer one varbind at a time instead of many. Bert & Jeff claim this is minimal so if it is minimal I am willing to incur it. Cheers, Don -----Original Message----- From: Mike Daniele [SMTP:daniele@zk3.dec.com] Sent: Wednesday, January 15, 1997 8:27 AM To: agentx@fv.com Subject: Unionized Registration vis a vis MIB partitioning The discussions about "unionized" registration touch on 3 distinct subjects: - MIB partitioning between subagents - Row creation in shared tables - Distributed scalars (ifNumber) Rergarding the first one only: Don Ryan said: >Hi Bert, >I fully understand the fact that unionized registration makes life >difficult for the master agent but it was my impression from the meeting in >San Jose that a consensus existed among the active members of the audience >(perhaps Uri excluded) that the idea of unionized registration needed to be >revisited because table sharing via index allocation and instance level >registration may not be practical in all cases (e.g., the ipRouteTable). A nit: The current draft does not *require* fully qualified instances for registering in shared tables. It requires enough of the instance to make a unique region oid (which will frequently be a fqi). I think we all agree that this mechanism is not practical in all cases. I think there is disagreement in what this means to AgentX. The benefits of the current draft's registration and dispatching scheme are that it is simple, and it is deterministic. For any given set of registrations, the same subagent is always responsible for any particular region/tree/oid. The weakness is that some MIBs can only be partitioned by registering fqi-s, and that may not be practical (due to highly dynamic rows for example). With unionized registrations, things become somewhat more complex, and they become non-deterministic. Different subagents can become responsible for a particular region/tree/oid when servicing different requests. Also, there is no way to specify in the elements of procedure exactly what the master agent should do (at least I haven't seen anything, other than "choose the 'best' response"). But the partitioning issue goes away. My opinion is that the number of MIBs that can't be partitioned reasonably between subagents usng the current draft, AND whose implementation is likely to be shared between subagents produced by different vendors (and hence that require an internet standard protocol) is very small. Therefore the conclusion I come to is that the current registration mechanism is more suitable to an internet draft than unionized registrations, WITH RESPECT TO MIB PARTITIONING. Your thoughts welcome. The MIBs I have seen/heard referenced as examples of why we need unionized registrations are tcpConnTable, ifTable, ipRouteTable, and RMON. The first 2 can be partitioned reasonably, the last 2 probably cannot. RMON has already had some discussion, and I am personally comfortable with a v1 AgentX that can't handle it. I'm finding it hard to imagine a system where ip routing is implemented by different vendors plug-ins on the same system. Do you have such a requirement Don? >Furthermore, there was at least one other person at the IETF meeting who >agreed with my opinion that it may NOT be such a good idea to have a >subagent's table entries completely hidden by other subagents registering >more specific OIDs. If I register ip and you later register ipRouteTable >then any ipRouteTable entries I may support will never be returned because >of the current dispatch mechanism. I am still struggling to understand why >this is a good thing as I thought the point of the exercise was to enable >table sharing. I believe there was wide-spread consensus for the "most-qualified wins" approach. It's the glue that holds everything together. I differentiate between planned-for table sharing (ifTable) and accidental table sharing (like the example you described above). The latter is a configuration "error". You have 2 subagents each claiming they support the entire table. They are not intending to share it. This is just another example of arbitrary overlapping registrations, and should be handled like any other. At least, that's how I view it. > I think the only way to move forward quickly on this >protocol (and this is certainly something I would like to do) is to put the >issue of unionized registration to rest one way or another. I think the >only way to do this properly is to sketch out a q&d design based on >unionized registration and see it we can make a.) make it work properly and >b.) make it reasonable as possible to implement. My previous post was only >meant to be a starting point in this direction. I agree with you, and will be posting wrt the other 2 areas of unionized registrations to at least provide explicit threads for discussion. >I am of the opinion that we should eliminate GETBULK from AgentX version 1 >and instead implement PDU serial numbers to optimize caching. As a >subagent, if I get a agentx-GetNext-PDU with the same serial number as the >previous one then I know the VBL included is being returned in the same >SNMP PDU as the previously requested VBL and I can safely choose not need >to refresh my cache. But without seeing max_repetitions, you don't know how far ahead to fetch/cache. You also lose the performance gain of exchanging a single PDU as opposed to max_repetitions pdus. A somewhat separate issue (#10 in the draft) is that if multiple PDUs for Next/Bulk are sent to a subagent, it cannot correlate them to the same SNMP request PDU. Do you feel that's an important issue? Thanks for your input, Mike ---------------- This e-mail message was sent to all subscribers to the agentx mailing list. To unsubscribe from this mailing list, please send mail to: agentx-request@fv.com with Subject: unsubscribe your.address@your.domain (NOTE: Please do not reply to this message to unsubscribe. You must send your request to agentx-request@fv.com Thank you.)   Delivery-Date: Fri, 17 Jan 1997 17:56:42 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id RAA01295 for X-agentx; Fri, 17 Jan 1997 17:56:42 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id RAA01292 for ; Fri, 17 Jan 1997 17:56:41 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id UAA02654 for ; Fri, 17 Jan 1997 20:55:43 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma002649; Fri, 17 Jan 97 17:55:18 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.4/8.8.4) with ESMTP id RAA00595 for ; Fri, 17 Jan 1997 17:56:31 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.7.5/8.7.3) id UAA02642 for ; Fri, 17 Jan 1997 20:55:13 -0500 (EST) Received: from unknown(198.64.253.250) by gauntlet.fv.com via smap (3.2) id xma002497; Fri, 17 Jan 97 17:55:03 -0800 Received: by dresden.bmc.com (1.40.112.4/16.2) id AA025472961; Fri, 17 Jan 1997 20:02:41 -0600 Received: from crow.bmc.com(198.147.191.100) by dresden.bmc.com via smap (3.2) id xma002526; Fri, 17 Jan 97 20:02:18 -0600 Received: from dorothy.peer.com by crow.bmc.com (AIX 3.2/UCB 5.64/4.03) id AA58365; Fri, 17 Jan 1997 19:48:07 -0600 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA039772461; Fri, 17 Jan 1997 17:54:21 -0800 Date: Fri, 17 Jan 1997 17:54:21 -0800 From: Randy Presuhn Message-Id: <199701180154.AA039772461@dorothy.peer.com> To: agentx@fv.com Subject: Agentx MIB Comments Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Hi - Here are a few comments on as posted to the list by Maria. agentxMasterSnmpVer doesn't really belong here. In any case, the list of protocols would need to be more open-ended. Suggest removing this definition. agentxSANumber - there is no motivation provided for the range constraints. Suggest changing the type to Unsigned32 and removing the constraints. agentxSubagentEntry - this is actually information about a subagent session, rather than a subagent, unless we are very careful to identify "subagent" as an instance of an interface supporting this capability, rather than the process which is also usually called a subagent. (A single process may, for various reasons, have multiple sessions with the same or different master agents.) Suggest changing the description to read: "Information about a single open session between the AgentX master agent and a subagent." agentxSAIndex - there is no motivation provided for the range constraints. Suggest changing the type to Unsigned32 and removing the constraints. agentxSATimeout - the last sentence of the last paragraph of the description mandates behaviour from subagents that is not required by the protocol. Suggest: delete the sentence. agentxSAObjectID - something is missing in the description. It is unclear what "type identification" is supposed to mean, even though the second sentence is quite clear. agentxSADescr - in view of the discussion, it might make sense for this to be a UTF-8 octet string rather than NVT DisplayString. agentxSAAdminStatus - the description mandates subagent behaviour not required by the protocol specification. Suggest: delete last sentence. agentxSAMsgsIn, agentxSAMsgsOut - the utility of these counters is questionable. Unless we can find a clear need to include these, suggest deleting them. agentxSATransportType - should SSL be added to the list? (More generally, do we need to consider the possible encapsulations over a given transport as part of the transport specification, since we seem to have relegated privacy and authentication to something below the application layer?) agentxSATransportAddr - the description needs to be revisted if we view this table as having one entry per session. agentxRegistrationEntry - the recommendation in the last sentence does not belong in the MIB specification. Suggest deleting last sentence of description. agentxRegIndex - there is no motivation provided for the range constraints. Suggest changing the type to Unsigned32 and removing the constraints. agentxRegContext - the agentx protocol does not impose corresponding limits on the length of context names. The MIB doesn't need to try to prevent people from doing really silly things. Suggest: remove constraint on context length. agentxRegDispatchOrder - the current description means that the value observed for a particular row could start out zero, become non-zero, and potentially be adjusted back to zero again. What value is provided by this? agentxRegPriority - the interactions between this and unionized registration needs to be worked out, particularly if wildcarding is supported. agentRegSAIndex - there is no motivation provided for the range constraints. Suggest changing the type to Unsigned32 and removing the constraints. agentxRegTimeout - the description mandates specific subagent behaviour that is not required by the protocol specification and which may be inappropriate in some configurations. Suggest delete the last sentence. agentxStats - the entire group is of questionable value. In our experience, statistics like these were not terribly useful. However, there may be value in counting (and possibly generating traps) for certain situations which are almost certain indications of serious configuration error, such as true "duplicate" registrations. ----------------------------------------------------------------------- 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." -----------------------------------------------------------------------   Delivery-Date: Tue, 28 Jan 1997 09:51:16 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id JAA02355 for X-agentx; Tue, 28 Jan 1997 09:51:12 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id JAA02352 for ; Tue, 28 Jan 1997 09:51:11 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id MAA10702 for ; Tue, 28 Jan 1997 12:49:53 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma010690; Tue, 28 Jan 97 09:49:25 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id JAA06232 for ; Tue, 28 Jan 1997 09:50:51 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id MAA10684 for ; Tue, 28 Jan 1997 12:49:23 -0500 (EST) X-Authentication-Warning: gauntlet.fv.com: uucp set sender to using -f Received: from unknown(134.177.110.46) by gauntlet.fv.com via smap (3.2) id xma010665; Tue, 28 Jan 97 09:49:02 -0800 Received: from turing.engwest ([134.177.118.22]) by fedex.engwest.baynetworks.com (4.1/SMI-4.1) id AA03285; Tue, 28 Jan 97 09:50:15 PST Received: from cheesewhiz.engwest by turing.engwest (SMI-8.6/SMI-SVR4) id JAA06555; Tue, 28 Jan 1997 09:47:05 -0800 Date: Tue, 28 Jan 1997 09:47:05 -0800 From: johns@baynetworks.com (John Seligson) Message-Id: <199701281747.JAA06555@turing.engwest> To: if-mib@tek.com, wijnen@vnet.IBM.COM Subject: Re: if-mib draft 05.txt Cc: agentx@fv.com Bert, A couple of comments: > 3. The ifTableLastChange is yet another scalar that get agentX into > trouble if ifEntries are spread over multiple subagents. > So I wonder if this object is really needed. > Management stations will probably GET(BULK) the whole ifTable > with every poll, so they can figure out if something changed, no? With the size of the boxes today and the abundance of interface layers, virtual and otherwise, it is quite unlikely that the entire ifTable can be retrieved in a single PDU in many situations. This is particularly true given the stated minimum supported SNMP PDU size of 484. More importantly, I don't agree with the idea, being advocated by several AgentX working group members on various mailing lists, that MIB definition should be constrained by the capabilities of AgentX. This just seems odd to me. It has been pointed out that several standard MIBs don't easily fit the current AgentX model. There are undoubtedly many many more proprietary MIBs, implemented using standard MIBs as examples, that don't fit the AgentX model as well. In situations such as this, I view the protocol (i.e., AgentX) as deficient if it can't support the full richness of various MIB definitions and the protocol should be the item that is updated. Now I know that AgentX is trying to follow the 80/20 rule and that is ok. However, I feel that the AgentX proposal should include a section stating that it does not support certain types of MIB definitions. Or the AgentX protocol should be updated to handle these constructs if the working group thinks they are important (my feeling here is that the working group does not). But I am against limiting MIB content to fit the AgentX ideal. If I was to tell my manager that I had a great new app but that existing apps would need to change to use it, he would ask me to redesign it for backwards compatibility in most cases. Just an opinion. John   Delivery-Date: Tue, 28 Jan 1997 12:51:13 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id MAA19807 for X-agentx; Tue, 28 Jan 1997 12:51:12 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id MAA19804 for ; Tue, 28 Jan 1997 12:51:12 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id PAA23301 for ; Tue, 28 Jan 1997 15:49:54 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma023246; Tue, 28 Jan 97 12:49:24 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id MAA19383 for ; Tue, 28 Jan 1997 12:50:50 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id PAA23227 for ; Tue, 28 Jan 1997 15:49:23 -0500 (EST) X-Authentication-Warning: gauntlet.fv.com: uucp set sender to using -f Received: from relay1.smtp.psi.net(38.8.14.2) by gauntlet.fv.com via smap (3.2) id xma023161; Tue, 28 Jan 97 12:48:58 -0800 Received: from nips.acec.com by relay1.smtp.psi.net (8.8.3/SMI-5.4-PSI) id PAA16179; Tue, 28 Jan 1997 15:49:56 -0500 (EST) Received: from bnatale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA20008; Tue, 28 Jan 1997 15:52:13 -0500 Message-Id: <3.0.32.19970128154921.0093b100@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 28 Jan 1997 15:49:25 -0500 To: johns@BayNetworks.com (John Seligson) From: Bob Natale Subject: Re: if-mib draft 05.txt Cc: wijnen@vnet.ibm.com, agentx@fv.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 09:47 AM 1/28/97 -0800, John Seligson wrote: Hi John, [I've dropped the if-mib cross-post, since my comments are limited to the AgentX aspects of this.] <...> >With the size of the boxes today and the abundance of >interface layers, virtual and otherwise, it is quite >unlikely that the entire ifTable can be retrieved in >a single PDU in many situations. This is particularly >true given the stated minimum supported SNMP PDU size >of 484. I think a GetNext sweep would work just as well, i.e., in the sense of Bert's example. However, as you note, that is a fairly minor point relative to the larger issues here. >More importantly, I don't agree with the idea, being >advocated by several AgentX working group members on >various mailing lists, that MIB definition should be >constrained by the capabilities of AgentX. This just >seems odd to me. That is not the view being advocated. "Constrained" is not the right term at all. Relative to "hierarchical" and "network", did "normalization" "constrain" data definitions in the "relational" DBMS model? I don't think so. Will "encapsulation" further "constrain" or "empower" the meaning of "data definition" in the (future) OODBMS world? The latter, I think. It is the use of autonomous scalars in (some) existing MIBs that is "constraining" now...it "constrains" the types of distributed/partitioned applications that can be built with those MIBs to a higher order of complexity/inefficiency than is currently desirable or, possibly, acceptable. >It has been pointed out that several standard > MIBs don't easily fit the current AgentX model. Just as many legacy databases have had to be re-modeled for the RDBMS and OODBMS worlds-- does that reflect flaws in relational theory or the object paradigm? >There are undoubtedly many many more proprietary >MIBs, implemented using standard MIBs as examples, >that don't fit the AgentX model as well. Maybe. But I observe a lot of enterprise MIB evolution over time anyway (from my own very limited set of vendors/partners, etc.). Usually to incorporate new device features added as a result of technology evolution and/or competitive pressures. >In situations such as this, I view the protocol > (i.e., AgentX) as deficient if it can't support > the full richness of various MIB definitions We might not be talking about "full richness" as opposed to simply "out-dated" or "inflexible" designs. Do you really see it as a mandate to live with such "richness" forever? (And I don't mean that question to sound sarcastic at all-- I am (pretty) sure you adjust to model evolution in other technologies, I am just curious as to why you think this one should be permanently exempt...or, if not permanently, for how long?) >and the protocol should be the item that is > updated. Here I think you should use the word "constrained" instead of "updated". You are saying, literally, that you think that AgentX--or any new standard extensible agent protocol--should be "constrained" by the characteristics of existing MIBs, even those characteristics that impede extensibility. >Now I know that AgentX is trying to follow the > 80/20 rule and that is ok. Thanks...we have been trying...but that basic perspective has not been universally adopted. There is still some strong sentiment for a 100/0 outcome. (And 100 sounds like a good outcome until you realize that such a solution would probably be equivalent to a 0 outcome in terms of workability and deployment.) >However, I feel that the AgentX proposal should > include a section stating that it does not support >certain types of MIB definitions. Yes, incorporating this kind of statement, along with the explanatory rationale for related decisions, has been recognized as a requirement and will appear in the next version of the protocol draft. > Or the AgentX protocol should be updated to handle > these constructs if the working group thinks they > are important Yes, you are right about that (with the *if*). And, in fact, some form of accommodation might have to be made even if the general consensus is that "constraining" AgentX to handle such anti-extensible constructs has a negative technical cost/benefit outcome, simply due to the reality of the situation. >(my feeling here is that the working group > does not). As AgentX chair, I cannot say that there is a clear consensus on this issue among the WG. Among the core technical team, there appears to be a fairly high degree of quasi-consensus on this issue (and some related ones). However, we are collectively aware of dissenting opinion and we are still doing our best to find a viable solution. Unfortunately, there are simply some desirable aspects of a simple, open standard extensible agent design that appear to be at odds with some (a very small number) aspects of deployed MIBs. Time--in several senses--is definitely a real "constraint" for all concerned. > But I am against limiting MIB content to fit the > AgentX ideal. Referring to "MIB" as a "conceptual" or "logical" data store, nothing in AgentX is designed to "limit" MIB content...rather it is designed to "extend" the range of possibilities. OTOH, there appear to be certain constructs in deployed MIBs that may indeed serve to limit extensibility. >If I was to tell my manager that I had a great new >app but that existing apps would need to change to >use it, he would ask me to redesign it for backwards >compatibility in most cases. Perhaps this is not one of those cases? On a personal level, I can strongly identify with the sentiment you express...however, on a working level today I have to say that we find ourselves adapting our processes, our products, our services, and our people to new technical and marketplace realities on a more or less constant basis. >Just an opinion. Likewise...nothing more. Cordially, BobN ------ ISO 9000 Registered, Hardware and Software Divsions ----- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] natale@acec.com | Gaithersburg MD 20878 | http://www.acec.com ----- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ------ ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Tue, 28 Jan 1997 15:03:29 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id PAA01523 for X-agentx; Tue, 28 Jan 1997 15:03:29 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id PAA01520 for ; Tue, 28 Jan 1997 15:03:28 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id SAA02969 for ; Tue, 28 Jan 1997 18:02:09 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma002961; Tue, 28 Jan 97 15:01:40 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id PAA28664 for ; Tue, 28 Jan 1997 15:03:07 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id SAA02950 for ; Tue, 28 Jan 1997 18:01:39 -0500 (EST) X-Authentication-Warning: gauntlet.fv.com: uucp set sender to using -f Received: from unknown(134.177.110.46) by gauntlet.fv.com via smap (3.2) id xma002939; Tue, 28 Jan 97 15:01:35 -0800 Received: from turing.engwest ([134.177.118.22]) by fedex.engwest.baynetworks.com (4.1/SMI-4.1) id AA06724; Tue, 28 Jan 97 15:02:44 PST Received: from cheesewhiz.engwest by turing.engwest (SMI-8.6/SMI-SVR4) id PAA07971; Tue, 28 Jan 1997 15:00:37 -0800 Date: Tue, 28 Jan 1997 15:00:37 -0800 From: johns@baynetworks.com (John Seligson) Message-Id: <199701282300.PAA07971@turing.engwest> To: natale@acec.com Subject: Re: if-mib draft 05.txt Cc: agentx@fv.com Bob, > It is the use of autonomous scalars in (some) > existing MIBs that is "constraining" now...it > "constrains" the types of distributed/partitioned > applications that can be built with those MIBs > to a higher order of complexity/inefficiency than > is currently desirable or, possibly, acceptable. This is not true. There are extensible agent technologies in wide-spread use that handle these types of objects while providing the benefits you suggest. > Here I think you should use the word "constrained" > instead of "updated". You are saying, literally, > that you think that AgentX--or any new standard > extensible agent protocol--should be "constrained" > by the characteristics of existing MIBs, even > those characteristics that impede extensibility. Not even close. What I am suggesting is that AgentX, as currently specified, does not provide support for defining certain types of management objects. These types of objects have been, and will continue to be, useful for certain applications. New technology can choose to support or not support these uses. It is a design tradeoff - make the choice, document it and proceed. Do not suggest, however, that providing support for these types of objects "constrains" or "impedes" extensibility. Existing technology (i.e., EMANATE) shows this assertion to be false. MIBs should be designed to be effectively used by management applications. My concerns are related to having developers possibly make non-optimal MIB design choices to conform to a technology that consciously doesn't support certain MIB design choices. Other technology options are available if needed. Optimal MIB design for effective network management is the target. John   Delivery-Date: Tue, 28 Jan 1997 20:44:39 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id UAA00121 for X-agentx; Tue, 28 Jan 1997 20:44:39 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id UAA00118 for ; Tue, 28 Jan 1997 20:44:39 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id XAA17758 for ; Tue, 28 Jan 1997 23:43:19 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma017748; Tue, 28 Jan 97 20:42:50 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id UAA17291 for ; Tue, 28 Jan 1997 20:44:17 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id XAA17742 for ; Tue, 28 Jan 1997 23:42:49 -0500 (EST) X-Authentication-Warning: gauntlet.fv.com: uucp set sender to using -f Received: from igw3.watson.ibm.com(129.34.139.18) by gauntlet.fv.com via smap (3.2) id xma017732; Tue, 28 Jan 97 20:42:33 -0800 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw3.watson.ibm.com (8.7.6/8.7.1) with ESMTP id XAA03456; Tue, 28 Jan 1997 23:44:28 -0500 Received: from hawpub.watson.ibm.com (hawpub.watson.ibm.com [9.2.90.19]) by mailhub1.watson.ibm.com (8.8.2/01-15-97) with SMTP id XAA31296; Tue, 28 Jan 1997 23:43:40 -0500 Received: by hawpub.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA31399; Tue, 28 Jan 1997 23:43:40 -0500 From: Uri Blumenthal Message-Id: <9701290443.AA31399@hawpub.watson.ibm.com> Subject: Re: if-mib draft 05.txt To: johns@BayNetworks.com (John Seligson) Date: Tue, 28 Jan 1997 23:43:39 -0500 (EST) Cc: if-mib@tek.com, agentx@fv.com In-Reply-To: <199701281747.JAA06555@turing.engwest> from "John Seligson" at Jan 28, 97 09:47:05 am Reply-To: uri@watson.ibm.com X-Mailer: ELM [version 2.4 PL25] Content-Type: text John Seligson says: > More importantly, I don't agree with the idea, being advocated by several > AgentX working group members on various mailing lists, that MIB definition > should be constrained by the capabilities of AgentX. This just seems odd > to me. Excuse me - it's not the Agentx perse, that requests the MIB's to be constrained. It's common sense and the architecture of today's SNMP agents (and very likely - tomorrow SNMP agents as well). Face the reality: modern agents must be composite. This adds restrictions on what various components can do. And MIBs shouldn't be a proving ground of how clever or twisted your imagination is. I can think of a few restrictions of Java that I don't like. I can also think of a few restrictions of C that I'd rather do away with. I can also think of a few restrictions of English language. Guess what - I learned to live with those, and hopefully so shall you. (:-) > It has been pointed out that several standard MIBs don't easily fit > the current AgentX model. There are undoubtedly many many more proprietary > MIBs, implemented using standard MIBs as examples, that don't fit the AgentX > model as well. It is no secret that there are MIB's designed in extremely nauseatic way, possibly by people who didn't know any better. Those MIBs are more kludgy than an agent can afford, especially if it has to support OTHER MIBs as well. It turns out to be too expensive to drag along that cannonball of the old kludges to support, and at some point one simply has to say: enough, that's it. Agentx made (or is trying to make) such a decision. > In situations such as this, I view the protocol (i.e., AgentX) as deficient > if it can't support the full richness of various MIB definitions and the > protocol should be the item that is updated. Many of those "rich" MIBs are severely broken - you know that. They were designed when their authors didn't know any better. Too bad. Today's technology holds MIBs to higher standard - and just like a car that used to run fine at 30 mph but falls apart when you drive it at 89 mph and thus has no place on today's highways, these older screwed-up MIBs have no place in today's agents. > But I am against limiting MIB content to fit the AgentX ideal. No - your MIB content is "ideal" because it requires a non-existent "ideal" multiplexing protocol to implement it. So stop dreaming and accept the fact, that Agentx expressive abilities are limited, and it is not possible to accomodate every stupid MIB, whose designers messed up (because of lack of vision, or lack in available tools,or lack in available technology). Today's agents cannot afford to be monolitic, and the multiplexing protocol cannot afford to support every perversion, that every MIB designer succeeded to put in one or another RFC. It would be nice to accomodate all the possible requirements and be everything for everybody (like Java :-), but it just isn't possible. > If I was to tell my manager > that I had a great new app but that existing apps would need to change to > use it, he would ask me to redesign it for backwards compatibility in most > cases. Some apps are broken and really have to be redesigned. have you never seen programs that used to compile fine with the old compiler but fail on the newer better but stricter one? Consider this new development as newer, better but stricter. -- Regards, Uri uri@watson.ibm.com -=-=-=-=-=-=-   Delivery-Date: Tue, 28 Jan 1997 23:05:55 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id XAA11318 for X-agentx; Tue, 28 Jan 1997 23:05:54 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id XAA11315 for ; Tue, 28 Jan 1997 23:05:54 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id CAA22398 for ; Wed, 29 Jan 1997 02:04:35 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma022389; Tue, 28 Jan 97 23:04:07 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id XAA22137 for ; Tue, 28 Jan 1997 23:05:33 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id CAA22383 for ; Wed, 29 Jan 1997 02:04:06 -0500 (EST) X-Authentication-Warning: gauntlet.fv.com: uucp set sender to using -f Received: from relay1.smtp.psi.net(38.8.14.2) by gauntlet.fv.com via smap (3.2) id xma022379; Tue, 28 Jan 97 23:03:41 -0800 Received: from nips.acec.com by relay1.smtp.psi.net (8.8.3/SMI-5.4-PSI) id CAA00310; Wed, 29 Jan 1997 02:04:55 -0500 (EST) Date: Wed, 29 Jan 1997 02:07:21 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA25346; Wed, 29 Jan 1997 02:07:21 -0500 Message-Id: <9701290707.AA25346@nips.acec.com> To: johns@baynetworks.com Subject: Re: if-mib draft 05.txt Cc: agentx@fv.com > Date: Tue, 28 Jan 1997 15:00:37 -0800 > From: johns@baynetworks.com (John Seligson) Hi John, > > It is the use of autonomous scalars in (some) > > existing MIBs that is "constraining" now...it > > "constrains" the types of distributed/partitioned > > applications that can be built with those MIBs > > to a higher order of complexity/inefficiency than > > is currently desirable or, possibly, acceptable. > > This is not true. There are extensible agent technologies > in wide-spread use that handle these types of objects > while providing the benefits you suggest. That may be true. None of them is a simple, open industry standard. AgentX is not out to eliminate those solutions, but rather to addess a large body of as yet unaddressed extensible agent needs with a simple, open standard approach. > > Here I think you should use the word "constrained" > > instead of "updated". You are saying, literally, > > that you think that AgentX--or any new standard > > extensible agent protocol--should be "constrained" > > by the characteristics of existing MIBs, even > > those characteristics that impede extensibility. > > Not even close. What I am suggesting is that AgentX, > as currently specified, does not provide support for > defining certain types of management objects. These > types of objects have been, and will continue to be, > useful for certain applications. New technology can > choose to support or not support these uses. It is a > design tradeoff - make the choice, document it and > proceed. Do not suggest, however, that providing support > for these types of objects "constrains" or "impedes" > extensibility. It is clear that the semantic battle here is a lose/lose situation. > Existing technology (i.e., EMANATE) > shows this assertion to be false. No, EMANATE is not an existance proof of what AgentX aims to be. AgentX would, in effect, most likely constitute a smallish appendage to EMANATE. Furthermore, AgentX is not out to eliminate any of the existing excellent products that work well for some classes of users--products from SNMP Research, BMC/Peer, IBM, Epilogue, Digital, Paul Freeman Associates, and others. In my view, AgentX targets the kind of unmet need that the DMTF aimed for...among others. > MIBs should be designed to be effectively used by > management applications. My concerns are related to > having developers possibly make non-optimal MIB design > choices to conform to a technology that consciously > doesn't support certain MIB design choices. Other > technology options are available if needed. Optimal > MIB design for effective network management is the > target. Well, I agree almost 100% with that set of statements. Unfortunately for this dialogue, I interpret them as supportive of the idea that a new simple, open standard extensible agent protocol and new "optimal MIB design for effective network management" might well need to go hand in hand. Btw, to all, we should have a summary list of the open AgentX issues and a draft consensus position on each posted to the list in the next several days...followed by 2-3 weeks of on-list discussion ...then the next "final" draft a couple of weeks after that. The current delay is (again, alas) entirely my fault (but at least I am making *some* visible on-list progress on WinSNMP v2! :-). Cordially, BobN ------ ISO 9000 Registered, Hardware and Software Divsions ----- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] natale@acec.com | Gaithersburg MD 20878 | http://www.acec.com ----- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ------ ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Wed, 29 Jan 1997 09:36:13 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id JAA00550 for X-agentx; Wed, 29 Jan 1997 09:36:13 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id JAA00547 for ; Wed, 29 Jan 1997 09:36:13 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id MAA07619 for ; Wed, 29 Jan 1997 12:34:51 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma007579; Wed, 29 Jan 97 09:34:21 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id JAA16413 for ; Wed, 29 Jan 1997 09:35:47 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id MAA07565 for ; Wed, 29 Jan 1997 12:34:20 -0500 (EST) X-Authentication-Warning: gauntlet.fv.com: uucp set sender to using -f Received: from unknown(134.177.110.46) by gauntlet.fv.com via smap (3.2) id xma007522; Wed, 29 Jan 97 09:33:54 -0800 Received: from turing.engwest ([134.177.118.22]) by fedex.engwest.baynetworks.com (4.1/SMI-4.1) id AA13377; Wed, 29 Jan 97 09:35:11 PST Received: from cheesewhiz.engwest by turing.engwest (SMI-8.6/SMI-SVR4) id JAA13465; Wed, 29 Jan 1997 09:33:01 -0800 Date: Wed, 29 Jan 1997 09:33:01 -0800 From: johns@baynetworks.com (John Seligson) Message-Id: <199701291733.JAA13465@turing.engwest> To: uri@watson.ibm.com Subject: Re: if-mib draft 05.txt Cc: agentx@fv.com Uri, An interesting diatribe, not quite addressing the real issues, but enjoyable nonetheless. Let me try one last time to be more clear. On several occasions over the past two months, several AgentX folks have spoken up on other IETF mailing lists regarding MIBs being developed for the standards process. Now, informing other developers that proposed MIB designs do not fit nicely within the confines of AgentX is fine. Telling them that their MIB design is wrong for this reason is not. This was certainly not the tone of Bert's note yesterday that initiated my comments. But it has been the tone of others in the past. This is not related to the limitations, goals, etc. of the current AgentX effort. Enought said. Have a nice day. John   Delivery-Date: Thu, 30 Jan 1997 07:26:46 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id HAA15058 for X-agentx; Thu, 30 Jan 1997 07:26:46 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id HAA15055 for ; Thu, 30 Jan 1997 07:26:45 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id KAA27248 for ; Thu, 30 Jan 1997 10:25:23 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma027231; Thu, 30 Jan 97 07:24:55 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id HAA17399 for ; Thu, 30 Jan 1997 07:26:24 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id KAA27226 for ; Thu, 30 Jan 1997 10:24:53 -0500 (EST) X-Authentication-Warning: gauntlet.fv.com: uucp set sender to using -f Received: from mail12.digital.com(192.208.46.20) by gauntlet.fv.com via smap (3.2) id xma027211; Thu, 30 Jan 97 07:24:35 -0800 Received: from flume.zk3.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) id KAA12005; Thu, 30 Jan 1997 10:14:17 -0500 (EST) Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA10010; Thu, 30 Jan 1997 10:14:12 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65/1.1.8.2/22Aug96-1117AM) id AA16126; Thu, 30 Jan 1997 10:09:48 -0500 Message-Id: <9701301509.AA16126@bernie.zk3.dec.com> To: johns@baynetworks.com (John Seligson) Cc: agentx@fv.com Subject: Re: if-mib draft 05.txt In-Reply-To: Your message of "Wed, 29 Jan 97 09:33:01 PST." <199701291733.JAA13465@turing.engwest> Date: Thu, 30 Jan 97 10:09:48 -0500 From: Mike Daniele X-Mts: smtp John, >Let me try one last time to be more clear. On several >occasions over the past two months, several AgentX folks >have spoken up on other IETF mailing lists regarding >MIBs being developed for the standards process. I hadn't noticed this. Which MIBs? Mike   Delivery-Date: Thu, 30 Jan 1997 09:07:10 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id JAA23535 for X-agentx; Thu, 30 Jan 1997 09:07:09 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id JAA23532 for ; Thu, 30 Jan 1997 09:07:09 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id MAA01671 for ; Thu, 30 Jan 1997 12:05:45 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma001658; Thu, 30 Jan 97 09:05:16 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id JAA23281 for ; Thu, 30 Jan 1997 09:06:45 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id MAA01653 for ; Thu, 30 Jan 1997 12:05:15 -0500 (EST) Message-Id: <199701301705.MAA01653@gauntlet.fv.com> X-Authentication-Warning: gauntlet.fv.com: uucp set sender to using -f Received: from vnet.ibm.com(199.171.26.4) by gauntlet.fv.com via smap (3.2) id xma001625; Thu, 30 Jan 97 09:05:00 -0800 Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 1495; Thu, 30 Jan 97 12:05:55 EST Date: Thu, 30 Jan 97 18:06:42 CET From: "Bert Wijnen" To: agentx@fv.com cc: if-mib@vndad.tek.com, snmpv2@tis.com Subject: scalars like ifNumber and ifTableLastChange Sorry for the cross posting, but it is an issue that touches all 3 areas. To prevent further duplication of postings, I suggest that we take this discussion further on the agentX mailing list and so anyone who wants to follow it should subscribe to that list too. We've seen quite a few comments about the agentX protocol not being able to cope with "aggregate scalars" like ifMIB. Also the new ifTableLastChange is problematic for the current agentX design. Now... a collegue of mine (Robert Moore from IBM RTP) brought up a good point that shows that these kind of scalars are already problematic in the world of SNMPv2 with view definitions specified in RFC144x and in SNMPv2* and in USEC-draft-config-document. What do we see: - one can specify a MIB-view in which ifNumber and ifTableLastChange are included, some rows in the ifTable are included and other rows in the ifTable are excluded. - If a manager now gets ifNumber and then walks the table, then it turns out that the ifNumber is in many cases not equal to the number of rows that thus manager can get. - If a manager now gets ifTableLastChange, then he may see that this object tells him that a change took place, but in the table that he retrieves he sees no changes at all. I understand that this is not a real serious problem.... but as I have stated before, it makes one wonder what the heck these 2 objects contribute in terms of usefull information. Comments? Bert   Delivery-Date: Thu, 30 Jan 1997 09:37:00 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id JAA26587 for X-agentx; Thu, 30 Jan 1997 09:36:59 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id JAA26584 for ; Thu, 30 Jan 1997 09:36:59 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id MAA03469 for ; Thu, 30 Jan 1997 12:35:35 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma003456; Thu, 30 Jan 97 09:35:05 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id JAA26749 for ; Thu, 30 Jan 1997 09:36:34 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id MAA03453 for ; Thu, 30 Jan 1997 12:35:05 -0500 (EST) X-Authentication-Warning: gauntlet.fv.com: uucp set sender to using -f Received: from puli.cisco.com(171.69.1.174) by gauntlet.fv.com via smap (3.2) id xma003425; Thu, 30 Jan 97 09:34:42 -0800 Received: from [171.69.128.42] (gryphon.cisco.com [171.69.128.42]) by puli.cisco.com (8.6.12/8.6.5) with ESMTP id JAA24242; Thu, 30 Jan 1997 09:36:00 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: In-Reply-To: <199701301706.JAA24078@inet1.tek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-pression: awestruck amazement Date: Thu, 30 Jan 1997 12:35:49 -0500 To: "Bert Wijnen" From: Bob Stewart Subject: Re: scalars like ifNumber and ifTableLastChange Cc: agentx@fv.com, if-mib@vndad.tek.com, snmpv2@tis.com Circa 6:06 PM +0000 1/30/97, Bert Wijnen bitwhacked: >Sorry for the cross posting, but it is an issue that touches all 3 >areas. To prevent further duplication of postings, I suggest that >we take this discussion further on the agentX mailing list and so >anyone who wants to follow it should subscribe to that list too. ... >I understand that this is not a real serious problem.... but as I >have stated before, it makes one wonder what the heck these 2 >objects contribute in terms of usefull information. People who limit their SNMP views in silly ways get silly results. The AgentX tail can't wag the SNMP dog. If there is to be a new restriction on the type of objects put in MIBs that should be the business of an SNMP-wide working group, with visibility to the individual MIBs affected. Some proponents of AgentX have said it should only try to cover 80% of present MIB behavior, to keep it simple. Now they're trying to come back and impose its simplifications on the rest of SNMP. If that's to be discussed it shouldn't be in the context of "it's hard for AgentX." It should be in the context of management needs, SNMP limitations, and impact on existing MIBs. Furthermore, as I understand it, there are existing, fielded, proprietary products that can handle the objects AgentX can't. If AgentX is going to have such a pervasive influence on SNMP, we ought to know exactly what we'd be saving by accepting its limitations. We're not working in a speculative vacuum. Real-world experience and information already exist. Bob   Delivery-Date: Thu, 30 Jan 1997 10:38:14 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id KAA01435 for X-agentx; Thu, 30 Jan 1997 10:38:14 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id KAA01432 for ; Thu, 30 Jan 1997 10:38:13 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id NAA07891 for ; Thu, 30 Jan 1997 13:36:50 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma007861; Thu, 30 Jan 97 10:36:21 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id KAA03429 for ; Thu, 30 Jan 1997 10:37:50 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id NAA07856 for ; Thu, 30 Jan 1997 13:36:21 -0500 (EST) Message-Id: <199701301836.NAA07856@gauntlet.fv.com> X-Authentication-Warning: gauntlet.fv.com: uucp set sender to using -f Received: from vnet.ibm.com(199.171.26.4) by gauntlet.fv.com via smap (3.2) id xma007849; Thu, 30 Jan 97 10:36:05 -0800 Received: from UITVM1 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 6086; Thu, 30 Jan 97 13:36:59 EST Date: Thu, 30 Jan 97 19:37:27 CET From: "Bert Wijnen" To: bstewart@cisco.com cc: agentx@fv.com, if-mib@vndad.tek.com, snmpv2@tis.com Subject: scalars like ifNumber and ifTableLastChange Ref: Your note of Thu, 30 Jan 1997 12:35:49 -0500 Subject: scalars like ifNumber and ifTableLastChange I am crossposting again because Bob answer with copy to 3 mailing lists I prefer to move this to one mailing list. So let us decide this: - if it is about agentX, then lets use agentX list - if it is general SNMP then use snmpv2 mailing list. I find Bob's "attack" on agentX a litle bit harsh... I know he means well though. I was not trying to justify agentX topics so much as I was trying to raise the issue w.r.t. to SNMP MIB-Views. So let me answer that piece here. Bert writes: > - one can specify a MIB-view in which ifNumber and ifTableLastChange > are included, some rows in the ifTable are included and other rows > in the ifTable are excluded. > - If a manager now gets ifNumber and then walks the table, then > it turns out that the ifNumber is in many cases not equal > to the number of rows that thus manager can get. > - If a manager now gets ifTableLastChange, then he may see that > this object tells him that a change took place, but in the > table that he retrieves he sees no changes at all. >I understand that this is not a real serious problem.... but as I >have stated before, it makes one wonder what the heck these 2 >objects contribute in terms of usefull information. > To which Bob answers: >People who limit their SNMP views in silly ways get silly results. > So... you think that that is silly. Mmmm... I see that specifically the ifTable is used as an example. So that then is a bad example I guess. Mmmm... If such a definition is silly... then certainly we should not use the ifTable as an example. And... if we cannot find any better (real and smart samples), then maybe we should do away with some of that complex MASKing stuff for MIBviews. Mmmm... I have also heard so often the ISPs and Telcoes need such fine granularity for MIBviews because they want each of their customers to see only their own stuff and not that of other customer.s Mmmm... So if they do that silly thing, then at least I can see that this ISP or Telco has at least ifNumber of customers. Oh... well, mybe Bob can explain his statement a bit better I seemed unable to understand it as it was written. Bert   Delivery-Date: Thu, 30 Jan 1997 11:05:21 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id LAA03738 for X-agentx; Thu, 30 Jan 1997 11:05:21 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id LAA03735 for ; Thu, 30 Jan 1997 11:05:20 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id OAA09207 for ; Thu, 30 Jan 1997 14:03:57 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma009177; Thu, 30 Jan 97 11:03:28 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id LAA05489 for ; Thu, 30 Jan 1997 11:04:57 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id OAA09170 for ; Thu, 30 Jan 1997 14:03:28 -0500 (EST) X-Authentication-Warning: gauntlet.fv.com: uucp set sender to using -f Received: from beasley.cisco.com(171.69.2.135) by gauntlet.fv.com via smap (3.2) id xma009150; Thu, 30 Jan 97 11:02:57 -0800 Received: from feta.cisco.com (feta.cisco.com [171.69.1.158]) by beasley.cisco.com (8.8.4-Cisco.1/CISCO.GATE.1.1) with SMTP id LAA23303; Thu, 30 Jan 1997 11:04:14 -0800 (PST) Message-Id: <199701301904.LAA23303@beasley.cisco.com> To: "Bert Wijnen" cc: bstewart@cisco.com, agentx@fv.com, if-mib@vndad.tek.com, snmpv2@tis.com Subject: Re: scalars like ifNumber and ifTableLastChange In-reply-to: Your message of "Thu, 30 Jan 97 19:37:27 +0700." <199701301837.KAA02933@inet1.tek.com> Date: Thu, 30 Jan 97 11:04:14 PST From: Robert Snyder Bert, Mayber I can help. ifNumber ifNumber is a poorly thought out object, it should have never been. That said, I have run into more that one management station that can not deal without its presence or misimplementation. This is would break a lot of fielded implementations, it remains ifTableLastChange As I recall the discussions around this certered around a need for a hint as to whether the ifTable changed, since downloading the entire table frequently is impractical for devices with say a 1000 interfaces That said, if you object to these specific objects and get them nuked that does not mean that a new wiz bang object that does have a legitimate value wont come along and present the same issues for agentX. Does that help? Robert > Date: Thu, 30 Jan 97 19:37:27 +0700 > To: bstewart@cisco.com > cc: agentx@fv.com, if-mib@vndad.tek.com, snmpv2@tis.com > > From: "Bert Wijnen" > Subject: scalars like ifNumber and ifTableLastChange > > Ref: Your note of Thu, 30 Jan 1997 12:35:49 -0500 > > Subject: scalars like ifNumber and ifTableLastChange > > I am crossposting again because Bob answer with copy to 3 mailing lists > I prefer to move this to one mailing list. > So let us decide this: > - if it is about agentX, then lets use agentX list > - if it is general SNMP then use snmpv2 mailing list. > > I find Bob's "attack" on agentX a litle bit harsh... I know he means > well though. I was not trying to justify agentX topics so much as > I was trying to raise the issue w.r.t. to SNMP MIB-Views. > > So let me answer that piece here. > > Bert writes: > > - one can specify a MIB-view in which ifNumber and ifTableLastChange > > are included, some rows in the ifTable are included and other rows > > in the ifTable are excluded. > > - If a manager now gets ifNumber and then walks the table, then > > it turns out that the ifNumber is in many cases not equal > > to the number of rows that thus manager can get. > > - If a manager now gets ifTableLastChange, then he may see that > > this object tells him that a change took place, but in the > > table that he retrieves he sees no changes at all. > >I understand that this is not a real serious problem.... but as I > >have stated before, it makes one wonder what the heck these 2 > >objects contribute in terms of usefull information. > > > > To which Bob answers: > >People who limit their SNMP views in silly ways get silly results. > > > > So... you think that that is silly. > Mmmm... I see that specifically the ifTable is used as an example. > So that then is a bad example I guess. > Mmmm... If such a definition is silly... then certainly we should > not use the ifTable as an example. And... if we cannot > find any better (real and smart samples), then maybe > we should do away with some of that complex MASKing stuff > for MIBviews. > Mmmm... I have also heard so often the ISPs and Telcoes need such > fine granularity for MIBviews because they want each of > their customers to see only their own stuff and not that > of other customer.s > Mmmm... So if they do that silly thing, then at least I can see > that this ISP or Telco has at least ifNumber of customers. > > Oh... well, mybe Bob can explain his statement a bit better > I seemed unable to understand it as it was written. > > Bert   Delivery-Date: Thu, 30 Jan 1997 12:00:20 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id MAA08187 for X-agentx; Thu, 30 Jan 1997 12:00:20 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id MAA08184 for ; Thu, 30 Jan 1997 12:00:19 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id OAA12063 for ; Thu, 30 Jan 1997 14:58:56 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma012056; Thu, 30 Jan 97 11:58:27 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id LAA10998 for ; Thu, 30 Jan 1997 11:59:55 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id OAA12050 for ; Thu, 30 Jan 1997 14:58:26 -0500 (EST) X-Authentication-Warning: gauntlet.fv.com: uucp set sender to using -f Received: from puli.cisco.com(171.69.1.174) by gauntlet.fv.com via smap (3.2) id xma012045; Thu, 30 Jan 97 11:58:09 -0800 Received: from [171.69.128.42] (gryphon.cisco.com [171.69.128.42]) by puli.cisco.com (8.6.12/8.6.5) with ESMTP id LAA02705; Thu, 30 Jan 1997 11:59:26 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: In-Reply-To: <199701301837.KAA10500@hubbub.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-pression: awestruck amazement Date: Thu, 30 Jan 1997 14:58:05 -0500 To: "Bert Wijnen" From: Bob Stewart Subject: Re: scalars like ifNumber and ifTableLastChange Cc: agentx@fv.com, if-mib@vndad.tek.com, snmpv2@tis.com Circa 7:37 PM +0000 1/30/97, Bert Wijnen bitwhacked: >I am crossposting again because Bob answer with copy to 3 mailing lists >I prefer to move this to one mailing list. I agree about the cross posting. The problem is which list to pick: If the issue is items in the Interfaces MIB, pick the if-mib mailing list. If the issue is proposed global restrictions on SNMP, pick the SNMPv2 list. If the issue is whether AgentX is adequate or whether the AgentX troops would like to develop some global restrictions for SNMP, pick the AgentX list. It's your issue. You get to pick which of those it belongs in. >I find Bob's "attack" on agentX a litle bit harsh... I know he means >well though. I was not trying to justify agentX topics so much as >I was trying to raise the issue w.r.t. to SNMP MIB-Views. My intention was not to attack AgentX but to say clearly that I believe limiting MIBs based on AgentX's 80% goal is short sighted. Arguments that start with AgentX's limitations don't ring well. >Oh... well, mybe Bob can explain his statement a bit better >I seemed unable to understand it as it was written. ifNumber is indeed a silly object. A similar object that said how many active users were on a system even though you couldn't look at all of their individual entries might be less silly. It's an anonymous measure of overall load, but you may not be allowed to know who the load is coming from, other than perhaps your own designated view's entries. An application that used ifTableLastChange as its event indicator and got upset when it couldn't find a change would be silly. As you said, it might not have a full view of all entries and missed the changed ones. But then again it might find one it really cared about and would have been saved having to poll the whole table regularly to check for a change. And in the typical case where their is no view limitation the object is fully useful. Bob   Delivery-Date: Thu, 30 Jan 1997 12:15:23 -0800 Return-Path: Received: (from daemon@localhost) by fv.com (8.7.5/8.7.3) id MAA09372 for X-agentx; Thu, 30 Jan 1997 12:15:23 -0800 (PST) Received: from gauntlet.fv.com (gauntlet.fv.com [207.67.199.118]) by fv.com (8.7.5/8.7.3) with ESMTP id MAA09369 for ; Thu, 30 Jan 1997 12:15:22 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id PAA12560 for ; Thu, 30 Jan 1997 15:13:59 -0500 (EST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma012557; Thu, 30 Jan 97 12:13:29 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.5/8.8.5) with ESMTP id MAA12001 for ; Thu, 30 Jan 1997 12:14:59 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.5/8.8.5) id PAA12544 for ; Thu, 30 Jan 1997 15:13:29 -0500 (EST) X-Authentication-Warning: gauntlet.fv.com: uucp set sender to using -f Received: from mail.htconn.com(38.245.21.2) by gauntlet.fv.com via smap (3.2) id xma012525; Thu, 30 Jan 97 12:12:54 -0800 Received: from tmax.htconn.com by mail.htconn.com (SMI-8.6/SMI-SVR4) id PAA21404; Thu, 30 Jan 1997 15:12:48 -0500 Date: Thu, 30 Jan 1997 15:12:48 -0500 From: devlinm@mail.htconn.com (T. Max Devlin) Message-Id: <199701302012.PAA21404@mail.htconn.com> To: agentx@fv.com Subject: Re: scalars like ifNumber and ifTableLastChange X-Mailer: ProntoIP [version 2.0] MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit > What do we see: > - one can specify a MIB-view in which ifNumber and ifTableLastChange > are included, some rows in the ifTable are included and other rows > in the ifTable are excluded. > - If a manager now gets ifNumber and then walks the table, then > it turns out that the ifNumber is in many cases not equal > to the number of rows that thus manager can get. > - If a manager now gets ifTableLastChange, then he may see that > this object tells him that a change took place, but in the > table that he retrieves he sees no changes at all. > I understand that this is not a real serious problem.... but as I > have stated before, it makes one wonder what the heck these 2 > objects contribute in terms of usefull information. > > Comments? > Bert > It seems your example ideally illustrates the need for ifNumber. Without aggregate scalars, a manager can't know if its technical view is being limited by organizational limits (there are more rows, but you don't know that) or by technical limits (there are no more rows, and ifNumber can be determined indirectly). There are three ways which you can find out how many interfaces a device has (that I know of; I'm not necessarily the most creative person around ;0) 1) Walk (GetNext or GetBulk; I can't see that it matters) the ifTable and count the number of rows you get 2) Walk the ifTable and find the highest value (or last value) of ifIndex 3) Get ifNumber Method 1 is problematic as you described: without also using method 2, you can't know if you are getting all the rows; just the ones in your view Method 2 is supposed to be going away: ifIndex values may longer be required to be contiguous low-value integers, but simply arbitrary designations Method 3 is not possible without redefining "MIB views" unless we can figure out how to support aggregate scalars, and the solution avoids this problem to begin with What's left are these questions: A) Is it possible to know that there are things outside your MIB view? Is your (appropriate context identifier here, I guess) view considered a subset of something, or the entire universe so far as you (a manager) are concerned? B) Is it feasible to know that there are things outside your view? How does it work if I had a table indexed by an attribute defined in a seperate table which is outside my view? Is it possible to know that things are outside your view, but not know what they are? Who manages the views/contexts/users/whatever and ensures that all required information is available for a specific view? C) Is it practical to know what things are outside your view? Something tells me this is a couple of questions, some of which are more centered on security and authentication (restrictive) and some on technical grounds such as the feasibility of aggregate scalars. I haven't really worked with context stuff yet (my customer base barely uses community strings: you would be surprised who uses "public" for their router community!), so this is all theoretical musings, as well as a request for answers and (hopefully) an aid in the discussion. Thanks for your time. -- T. Max Devlin Hi-TECH Connections Voice:(610)372-1401x233 Fax:(610)372-1805 tmax@htconn.com -[Opinions expressed are my own; everyone else, including my employer, has to pay for them, subject to applicable licensing agreement]-