Delivery-Date: Mon, 01 Jan 1996 09:38:58 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id JAA05140 for X-agentx-local; Mon, 1 Jan 1996 09:38:58 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id JAA05133 for ; Mon, 1 Jan 1996 09:38:57 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA27749 for agentx@fv.com; Mon, 1 Jan 96 12:39:06 -0500 Date: Mon, 1 Jan 1996 12:37:14 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA11147; Mon, 1 Jan 1996 12:37:14 -0500 Message-Id: <9601011737.AA11147@nips.acec.com> To: agentx@fv.com Subject: Clarifications Hi Everyone, I had the following off-list exchange which might be of interest to others and/or might give others the oppotunity to correct and/or augment anything that I said: > I have few questions about extensible agent. Ok...I'll do my best to answer them. > After reading Harmen thesis, I am very glad you took the time to do and hope it was a useful investment for you. > I'm trying to clarify some concepts. I'll use: P for Proxy, > E for Extensible and (CLE,CLT) pair as sub-agent identifier. Ok...note that contextLocalEntity and contextLocalTime were part of the formal SNMPv2 proposals at the time that Harmen wrote his thesis...they aren't now. > 1) E manipulate variables while P manipulate packages. Right. > 2) E hide sub-components while P expose sub-components. Right. > 3) both E and P sub-agent are physical component (based on hardware). The term we are now using is "Component Agent"...a component can be anything that can be managed, directly or indirectly, via the "System Agent" interface on the SNMP side. It might be a hardware product, but it could also be a piece of software (e.g., an RDBMS). > 4) E/P sub-agents can be connected to the E/P master agent via > physical connection or network connection. Well, I think the term "physical" is a bit unclear here...but, yes, the current thinking is that component agents may reside either on the same physical element as the system agent or be reachable via a network connection. There are some who want to limit the scope to the former for the time being, but I don't think we've collectively adopted this limitation as necessary yet (and most don't seem to consider it a desirable limitation, even though it might eventually become necessary to achieve consensus on at least a subset solution). > If my concepts are true, than I have several questions. I think they are generally very accurate. > 1) If we have a unique component (of any type) connected to the > E agent, than I can understand that it`s physical location can > (or should) be hide from the administrator. Ok. > What will happened if two (or more) components from the same > type will be connected to the same E agent. Depends on the MIB that their component agent(s) implement. (And this is, in part, why we are trying to coordinate our work with the Entity MIB work.) > Example: In an hub. If we put one card of Ethernet concentrator, > one Ethernet switch, one Token Ring to Ethernet router,.... > We will be want the administrator to see the hub as one unit. > Of course when he want some data about the Ethernet switch specific > mib, the hub E agent will point the variables to the switch > card. What will happen if we put two Ethernet switch in the same hub, > the administrator will use the (CLE,CLT) to identify the appropriate > Ethernet switch. In this case we do not hide the sub-components from > the administrator. Again this is strictly (hmmm, that's far too strong a word for the real state of things at this moment, I know!) a MIB issue... and I think that both the on-going Hub MIB and the Entity MIB work are designed to correct this MIB-level flaw. Two other possible responses to your question would be: 1. You should think about the agentx protocol as a means of facilitating multi-vendor provision of component agents into a user's single system agent environment. In a scenario in which a single vendor is developing the component agent(s) for elements in that vendor's own box--where no outside vendor participation is foreseen--this might not be the most efficient protocol to use. 2. A component agent can be a "system agent" in its own right at a lower (or even lateral) level in the management hierarchy. I know this concept probably needs a lot more elaboration to form a solid basis for thinking about the problem, but I've got to leave it at that for the moment. I hope you can see some possibilities in it. However, the bottom-line answer for now is that it's a MIB-based problem. > If this scenario is relevant, than this scenario remove > concept #2 from my list. I don't think that is either desirable or necessary, based upon the options. > 2) SET several instances, Harmen's thesis describe two scenarios. > One - one sub-agent involved in the SET operation. Two - more then > one sub-agent involved in the SET operation. I failed to see when > case #2 happens. Can you , please, show me a scenario that SET > operation has to be done on more then one component. Well, it is true that some have suggested in the past that we limit SetRequests (coming into the system agent) to a single component (sub-agent)...based upon the fact that in practice this would be the most frequent case anyway...and then, as an improvement over that, provide exceptional behavior for the multi-component Set case. However, the current thinking about the matter seems to be that we should deal with multi-component Sets in a forthright manner. As far as a scenario goes, at the logical level it is quite obvious: The system agent contains settable variables for multiple components; the management application does not know that any two settable variables might be managed by different components (and per your concept #2 above, we don't want the mgmt apps to have to know or care about this); therefore, the mgmt app is likely to issue a SetRequest for varbinds managed by multiple component agents; and we are committed to maintaining both the "as if simultaneous" and the "two-phase commit" error codes of SNMPv2C in the transaction, as seen by the management application. > 3) While the connection between the master-agent to sub-agent > was clearly describe, at all the modules in Harmen's thesis, > the connection between administrator to master-agent remain > unclear to me. Does the administrator send with each variable > the (CLE,CLT) pair? or the (CLE,CLT) pair is added to each > variable group in a packet? or per packet? Are the (CLE,CLT) > pair part of the variable OID? or two instances that are added > to the variable/packet? In other postings, I have made reference to the concept of the "whole product" solution that will be required to use agentx in the field. Administration of the system agent--in fact of the overall agentx envrionment--is a major part of that whole product solution. More directly in answer to your question, however, at the present time CLE/CLT is not part of the SNMP protocol itself. As always, the agent configuration utility can allow for the stipulation of "community profiles" containing "MIB views" of arbitrarily fine granularity and accessibility, governed by the community name. At this level, the management application distinguishes among CLE/CLT-like subsets of MIB variables using an appropriate community name value when communicating with the system agent. > 4) Another scenario as in Q1 case #1. For each component we > open a new row that describe it's variables. When we want to > get to a common standard object, like ifOperStatus from MIB-II > Interface group, that implemented by several different components > (Ethernet switch and Token Ring to Ethernet router). Does the > administrator send an index to identify the component he want > to have knowledge about? Yes, I think so. Note that this "index" value--at least in the scenario I have proposed (which is far from likely to be the one we adopt in the end at this time)--*might* not be the same index value that is used between the system agent and the one or more component agents that might be involved in retrieving the actual management information. I hope the above helps to clarify things, at least as I see them...I will circulate a version of this to the group to solicit additional input (and any necessary corrections!). In the meantime, feel free to let me know directly if you have any follow-up or other questions...or, preferably, go ahead and raise your concerns/issues/suggestions directly on the list. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Mon, 01 Jan 1996 12:31:34 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id MAA11139 for X-agentx-local; Mon, 1 Jan 1996 12:31:34 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id MAA11133 for ; Mon, 1 Jan 1996 12:31:33 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA03655 for agentx@fv.com; Mon, 1 Jan 96 15:31:43 -0500 Date: Mon, 1 Jan 1996 15:29:51 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA13980; Mon, 1 Jan 1996 15:29:51 -0500 Message-Id: <9601012029.AA13980@nips.acec.com> To: agentx@fv.com Subject: Component agent non-interdependency Hi Everyone, In reviewing some of the protocols the solution space (particularly DPI and eSNMP at the moment), I notice that several of the mechanisms they employ seem, to me, to imply some degree of component agent interdependency ...and I think this must be avoided entirely. For example, the concept of a registration "priority" for an object (or range of objects) which is conveyed by a component agent to the system agent at "register" time implies that a set of component agents who can manage the same resources (or subset of resources) "cooperate" somehow (most likely with foreknowledge of each other) to determine who registers with the "highest" priority (lowest number in DPI, highest in eSNMP). Likewise, eSNMP allows a second component agent to register for a subtree within a subtree already registered by another component agent. Again, this feature cannot be employed in orderly fashion without some foreknowledge of the multiple component agent structure...as the example in eSNMP shows between two "system level" component agents (os_mibs and gated, if I recall correctly) provided by the system (OS) vendor. [Speaking as wg chair...] It is a fundamental design goal of agentx that multiple independently developed and procured component agents can be employed to extend a user's system agent in an orderly fashion without any such component agents having any built-in foreknowledge of each other. Does anyone disagree with that statement...or want to refine it? [Off...] Does anyone who agrees with that statement interpret either or both of the two examples I gave (above) in a manner which says those features (priorities and nested external subtree registration) do not violate it? Or does anyone feel that while such a "violation" may in fact exist in one or both of these cases, it is still a positive trade-off in practice? Or any other thoughts? Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Mon, 01 Jan 1996 13:20:59 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id NAA22353 for X-agentx-local; Mon, 1 Jan 1996 13:20:58 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id NAA22349 for ; Mon, 1 Jan 1996 13:20:57 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA05739 for agentx@fv.com; Mon, 1 Jan 96 16:21:06 -0500 Date: Mon, 1 Jan 1996 16:19:14 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA14778; Mon, 1 Jan 1996 16:19:14 -0500 Message-Id: <9601012119.AA14778@nips.acec.com> To: agentx@fv.com Subject: MIBs in agentx Hi everyone, [Speaking as a technical contributor...] It seems to me that it might be helpful to have a brief discussion about the role(s) of MIBs in the extensible agent context. The way that I see this issue, it reveals some strong drivers toward some refinements of the solution space...I'd like to know what different views others hold on this general topic or any of the specifics I will mention. 1. First of all, one of our goals is that properly authorized management applications see a self- consistent standard SNMP MIB space at the system agent interface encompassing all the management objects accessible via the system agent, with no particular knowledge of the existence of component agents *required* by those management applications. 2. The "extensible agent" is a virtual agent... consisting of the system agent and the collection of active component agents at any point in time. The extensible agent, per se, does not implement a MIB. 3. The system agent is a real agent...it will implement a standard system agent MIB. This MIB may serve multiple purposes...e.g., enabling the management applications to configure the extensible agent environment and monitoring information about the extensible agent environment. 4. Each component agent will implement a MIB, specific to its managed component. 5. The system agent and the component agents will share an "intra-agent MIB" space used for system agent <-> component agent (i.e., "intra-agent") interactions (communications and coordination). This intra-agent MIB space need not be visible to management applications (although on a read-only basis, there may be no harm in seeing it as an extension of the system agent MIB for this purpose). 6. Management applications have to "compile in" knowledge of the system agent MIB and the component agent MIBs. (How this is done is an implementation detail outside the scope of agentx.) 7. My view is that the system agent should also "compile in" knowledge of the component agents... note that this yields all the necessary object registration information, except for instances of tabular objects. It also allows for enormous runtime efficiency of the registration process after the first time a component agent registers its MIB (until the next time a new version of the component MIB is installed). (Note that whether a particular system agent implementation actually did "compile in" the component MIBs knowledge in this manner is totally an implementation detail... if it didn't, it would pay a performance penalty in the marketplace relative to others implementations that did, but would have no impact on the agentx protocol itself.) Comments/corrections/critiques/etc. welcomed. (Btw, I know this thread begs for a nice drawing... I can do that using some nifty Windows-based tools I have, but know that would present problems for some to view...and I am loathe (ok, maybe just too lazy) to fool around trying to get an ASCII drawing right...any recommendations?) Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Mon, 01 Jan 1996 17:51:03 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id RAA20559 for X-agentx-local; Mon, 1 Jan 1996 17:51:01 -0800 (PST) Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id RAA20538 for ; Mon, 1 Jan 1996 17:51:00 -0800 (PST) Message-Id: <199601020151.RAA20538@zloty.fv.com> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 2041; Mon, 01 Jan 96 20:50:50 EST Date: Mon, 1 Jan 96 20:50:49 EST From: "Geoff Carpenter" To: agentx@fv.com Subject: Component agent non-interdependency Ref: Your note of Mon, 1 Jan 1996 15:29:51 -0500 (attached) > In reviewing some of the protocols the solution space > (particularly DPI and eSNMP at the moment), I notice > that several of the mechanisms they employ seem, to me, > to imply some degree of component agent interdependency > ...and I think this must be avoided entirely. > > For example, the concept of a registration "priority" > for an object (or range of objects) which is conveyed > by a component agent to the system agent at "register" > time implies that a set of component agents who can > manage the same resources (or subset of resources) > "cooperate" somehow (most likely with foreknowledge > of each other) to determine who registers with the > "highest" priority (lowest number in DPI, highest in > eSNMP). I don't quite see it this way. When we were developing tools for the NSFNET backbone, one of our goals was to strive for non-stop operation. As a result, our tools supported dynamic loading/unloading/replacement of management applications. When the DPI V1 was done back in 1989 to support monitoring of ACSUs on the backbone and the implementation of SNMP agents for the VM TCP/IP product, that same spirit infected the DPI implementation. The behavior of a registration request was defined so that a later registration would "cover up" a previous one, thus permitting a broken component to be overridden by registering a new sub-agent. Perhaps one can blame creeping featurism, but this rule was made more general (with a corresponding loss of understanding of its utility) in DPI V2 with the addition of the notion of a registration priority. I don't know if the support for multiple levels of priority has ever been exploited by a sub-agent. In the absence of any examples, I'd favor dropping such a feature and going back to the original DPI V1 rule of the last registration having precedence. > Likewise, eSNMP allows a second component agent to > register for a subtree within a subtree already > registered by another component agent. Again, this > feature cannot be employed in orderly fashion without > some foreknowledge of the multiple component agent > structure...as the example in eSNMP shows between two > "system level" component agents (os_mibs and gated, if > I recall correctly) provided by the system (OS) vendor. But you might have exactly that knowledge if you are attempting to patch an almost correct sub-agent you obtained in object-code-only form (e.g., ifSpeed on your point-to-point link is not returning the desired value). > [Speaking as wg chair...] > It is a fundamental design goal of agentx that > multiple independently developed and procured > component agents can be employed to extend a > user's system agent in an orderly fashion without > any such component agents having any built-in > foreknowledge of each other. I'll accept the above as an axiom. Ignorance isn't useful for proving much, but I'm not aware of any sub-agent technology which *requires* component agents to be aware of each other. Seems to me the question at hand is whether or not you want to permit vs. prohibit a component agent to be aware of a second component agent. I can think of a reasonable justification for permitting this. I can't think of a compelling reason to prohibit it in any and all cases. Geoff Carpenter IBM Research -- Yorktown Heights, NY   Delivery-Date: Mon, 01 Jan 1996 22:06:10 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id WAA16999 for X-agentx-local; Mon, 1 Jan 1996 22:06:09 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id WAA16995 for ; Mon, 1 Jan 1996 22:06:08 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA04646 for agentx@fv.com; Tue, 2 Jan 96 01:06:18 -0500 Date: Tue, 2 Jan 1996 01:04:26 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA23167; Tue, 2 Jan 1996 01:04:26 -0500 Message-Id: <9601020604.AA23167@nips.acec.com> To: gcc@watson.ibm.com Subject: Re: Component agent non-interdependency Cc: agentx@fv.com > Date: Mon, 1 Jan 96 20:50:49 EST > From: "Geoff Carpenter" Hi Geoff, [Speaking as a technical contributor...] <...> > I don't quite see it this way. I think some of your wording is more precise than mine was...I think we see this very similarly. > When we were developing tools for the NSFNET backbone, one > of our goals was to strive for non-stop operation. As a result, > our tools supported dynamic loading/unloading/replacement > of management applications. When the DPI V1 was done back > in 1989 to support monitoring of ACSUs on the backbone and the > implementation of SNMP agents for the VM TCP/IP product, that > same spirit infected the DPI implementation. The behavior of a > registration request was defined so that a later registration > would "cover up" a previous one, thus permitting a broken > component to be overridden by registering a new sub-agent. Thanks for the historical background (very useful stuff)... I understand...but would just point out that a routine "close" of the "broken component" and "open" of the repaired one would appear to work just as well. > Perhaps one can blame creeping featurism, but this rule was > made more general (with a corresponding loss of understanding > of its utility) in DPI V2 with the addition of the notion of > a registration priority. I don't know if the support for multiple > levels of priority has ever been exploited by a sub-agent. > In the absence of any examples, I'd favor dropping such a feature > and going back to the original DPI V1 rule of the last registration > having precedence. Yes, I could accept either the last registration or the first registration as having precedence. The problem with the priority scheme, as it relates to component agent independence, is that there is absolutely no rationale which would prevent multiple component agents from registering at the same (and logically high) priority), with the sole result that the system agent would have to adopt some other method (e.g., last or first precedence) to resolve the conflict. <...> > But you might have exactly that knowledge if you are attempting > to patch an almost correct sub-agent you obtained in object-code-only > form (e.g., ifSpeed on your point-to-point link is not returning the > desired value). [Speaking as wg chair...] I'd suggest that--while it's an interesting use of the protocol and a possible by-product that would have value--being able to patch run-time object-code is a non-goal of the wg at this time. [Off...] > > [Speaking as wg chair...] > > It is a fundamental design goal of agentx that > > multiple independently developed and procured > > component agents can be employed to extend a > > user's system agent in an orderly fashion without > > any such component agents having any built-in > > foreknowledge of each other. > > I'll accept the above as an axiom. Ignorance isn't > useful for proving much, but I'm not aware of any sub-agent > technology which *requires* component agents to be aware of > each other. Seems to me the question at hand is whether or > not you want to permit vs. prohibit a component agent to be > aware of a second component agent. Well, it seems to me that orderly utilization of the priority schemes requires this awareness...otherwise, your riding on luck and/or some other means of resolving the possibility that multiple "competing" component agents all register at the highest possible priority. > I can think of a reasonable justification for permitting > this. I can't think of a compelling reason to prohibit it > in any and all cases. You are absolutely right...and this is where I can see that my choice of wording above leaves room for mis-interpretation. All I meant to say was that component agents must be able to be added to a system under "user" control in an orderly manner without *requiring* component agents to have foreknowledge of the others that the "user" may have loaded. Yes, component agents should be *permitted* to be aware of each other on a cooperative basis...in my view this would occur via the "intra-agent MIB" dimension that I mentioned in a separate posting. Naturally, as well, cooperating component agents could use any means available to them and external to the agentx protocol to further coordinate their operations. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Mon, 01 Jan 1996 22:18:37 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id WAA19771 for X-agentx-local; Mon, 1 Jan 1996 22:18:36 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id WAA19765 for ; Mon, 1 Jan 1996 22:18:35 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA05258 for agentx@fv.com; Tue, 2 Jan 96 01:18:32 -0500 Date: Tue, 2 Jan 1996 01:16:40 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA23359; Tue, 2 Jan 1996 01:16:40 -0500 Message-Id: <9601020616.AA23359@nips.acec.com> To: rwill1@freenet.scri.fsu.edu Subject: Re: MIBs in agentx Cc: agentx@fv.com > From: Russell Willis > Date: Mon, 1 Jan 96 19:55:01 EST Hi Russell, [Speaking as a technical contributor...] > Russell Willis to Bob and all: I'll assume from that "and all" that you meant your query --or at least my answer--to go the whole list...ergo the cc: on this reply. > I, for one, would benefit from additional details regarding > the virtual agent concept mentioned below. Thanks in advance > for any and all assistance. > > > 2. The "extensible agent" is a virtual agent... > > consisting of the system agent and the collection > > of active component agents at any point in time. > > The extensible agent, per se, does not implement > > a MIB. First, let me warn you that I sometimes throw words around too loosely! But, I think this is a fairly clear one. The "extensible agent" is sort of like "the whole that is greater than its parts". The extensible agent emerges only from the realization of a system agent (aka, master) and one or more (normally multiple) component agents (aka, sub-agents). In a sense, the system agent comes with "receptors" for independent component agents (although some of them may come with the system agent itself) and "control circuitry" for the resulting collective entity. Such a collective entity--built up from its constituent parts (system agent and component agents)--is what I am referring to as the "extensible agent" in the referenced posting and, as such, it is somewhat "virtual" relative to the system agent and the component agents, each of which have some concrete existence in their own right. I hope that's clearer and seems correct to you. If not, in either or both ways, please let me know. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Mon, 01 Jan 1996 22:46:39 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id WAA25703 for X-agentx-local; Mon, 1 Jan 1996 22:46:39 -0800 (PST) Received: from aristo.tau.ac.il (aristo.tau.ac.il [132.66.32.10]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id WAA25693 for ; Mon, 1 Jan 1996 22:46:35 -0800 (PST) Received: from gandalf (world.lannet.com) by aristo.tau.ac.il with SMTP id AA23389 (5.67b/IDA-1.5 for ); Tue, 2 Jan 1996 08:46:27 +0200 Received: from moon.lannet.com by gandalf (4.1/SMI-4.1) id AA14740; Tue, 2 Jan 96 08:47:34 IST Received: from smtplink.lannet.com by moon.lannet.com (4.1/SMI-4.1) id AA18586; Tue, 2 Jan 96 08:44:41 IST Received: from Connect2 Message Router by smtplink.lannet.com via Connect2-SMTP 4.00; Tue, 2 Jan 96 08:43:06 -0500 Message-Id: In-Reply-To: <912FE930010CB6AA> Date: Tue, 2 Jan 96 08:51:21 -0500 From: Dan Romascanu Sender: Dan Romascanu Organization: Lannet Ltd. To: agentx@fv.com, natale@acec.com (Bob Natale) Subject: Re: Component agent non-interde X-Mailer: Connect2-SMTP 4.00 MHS to SMTP Gateway Hi Bob, >It is a fundamental design goal of agentx that >multiple independently developed and procured >component agents can be employed to extend a >user's system agent in an orderly fashion without >any such component agents having any built-in >foreknowledge of each other. > >Does anyone disagree with that statement...or >want to refine it? >[Off...] > >Does anyone who agrees with that statement interpret >either or both of the two examples I gave (above) >in a manner which says those features (priorities >and nested external subtree registration) do not >violate it? Or does anyone feel that while such a >"violation" may in fact exist in one or both of >these cases, it is still a positive trade-off in >practice? Or any other thoughts? Let me see if I understand well your statement. You mean that 'One should be able to implement agentx component agents to extend a system agent without requireing any knowledge of each other. Any mechanism that implies some relationship between component agents is out of the scope of agentx.' If my interpretation is correct, I agree with what you are saying. I would however be careful into clarifying (explicitely or implicitely) that:: 1. The component agent has some knowledge about the system agent local context. 2. The component agent might have some view about other component agents local context 3. The agentx mechanisms may be used for communication between component agents for features like those described in your mail. In our experience we met the need of implementing a priority mechanism like the one described in your mail. I can also imagine situations in which nested subtree registration would be useful. We shouldn't preclude implementation of such features but we shouldn't make them a mandatory part of our architecture. Regards, Dan Romascanu, Madge Networks (Israel) Ltd., Voice: 972-3-645-8414, e-nail: dan@lannet.com   Delivery-Date: Tue, 02 Jan 1996 07:07:18 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id HAA24517 for X-agentx-local; Tue, 2 Jan 1996 07:07:17 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id HAA24513 for ; Tue, 2 Jan 1996 07:07:16 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA14962 for agentx@fv.com; Tue, 2 Jan 96 10:07:11 -0500 Date: Tue, 2 Jan 1996 10:05:18 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA01892; Tue, 2 Jan 1996 10:05:18 -0500 Message-Id: <9601021505.AA01892@nips.acec.com> To: dan@lannet.com Subject: Re: Component agent non-interde Cc: agentx@fv.com > Date: Tue, 2 Jan 96 08:51:21 -0500 > From: Dan Romascanu Hi Dan, [Speaking as a technical contributor...] <...> > Let me see if I understand well your statement. You > mean that 'One should be able to implement agentx > component agents to extend a system agent without > requireing any knowledge of each other. Yes, and (as Geoff elicited earlier) the emphasis in that statement is on *requiring*. I am saying that any mandatory part of the protocol which *relies* upon component agent foreknowledge would be counter to a fundamental purpose of the protocol (component agent independence) and therefore unacceptable. > Any mechanism that implies some relationship between > component agents is out of the scope of agentx.' Instead of "implies some relationship between component agents" make that something like "requires an inter- dependency relationship between component agents" and then, yes, I do think that would be unacceptable. > If my interpretation is correct, I agree with what you > are saying. I would however be careful into clarifying > (explicitely or implicitely) that:: Yes, thanks, for keeping me honest! > 1. The component agent has some knowledge > about the system agent local context. Yes. (And in my own scheme this would be essential.) > 2. The component agent might have some view > about other component agents local context Yes. (Emphasis on *might*...would be a cooperative thing between/among component agents, but could not adversely affect non-cooperating component agents that a "user" has elected to load.) > 3. The agentx mechanisms may be used for > communication between component agents for > features like those described in your mail. Yes. (Literally speaking, in my view, each such component agent communicates with the system agent to accomplish this.) > In our experience we met the need of implementing > a priority mechanism like the one described in your > mail. I can also imagine situations in which nested > subtree registration would be useful. We shouldn't > preclude implementation of such features but we > shouldn't make them a mandatory part of our > architecture. I agree entirely. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Tue, 02 Jan 1996 08:30:51 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id IAA12540 for X-agentx-local; Tue, 2 Jan 1996 08:30:51 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id IAA12537 for ; Tue, 2 Jan 1996 08:30:47 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA26188 for agentx@fv.com; Tue, 2 Jan 96 11:30:23 -0500 Date: Tue, 2 Jan 1996 11:28:30 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA03879; Tue, 2 Jan 1996 11:28:30 -0500 Message-Id: <9601021628.AA03879@nips.acec.com> To: schoenw@ibr.cs.tu-bs.de Subject: Re: PDUs, proto-ops, and principles Cc: agentx@fv.com > Date: Sat, 30 Dec 1995 13:33:10 +0100 > From: Juergen Schoenwaelder Hi Juergen, [Speaking as a technical contributor...] > Lou Fernandez said: > Lou> If instance-level registration is required, the subagent will > Lou> have to do an enormous amount of work to maintain in the > Lou> master agent the current list of active processes. The > Lou> majority of this work will be wasted because no manager will > Lou> ever make a query for those instances. > > I think this problem can be solved easily if the master agent (and > hence the agentx protocol) is able to signal the subagent that a > request to one of its instances is going to happen. This will allow > the subagent to update the instances known by the master agent on > demand before PDU processing starts. Well, the problem with your statement (whose objective I agree with) is that for the system agent to signal a component agent that "a request to one of its instances is going to happen", the system agent must know that instance(s) is, in fact, owned by the component agent that it is going to signal. And that seems to beg the question...? > The subagent may even use additional parameters like "only signal > the beginning of a request if the last instance update is at least > n seconds away". This can reduce instance registration overhead > even further. In general, I agree that if a scheme is adopted in which the system agent has close to perfect knowledge about the MIB variables/instances managed by its component agents (which, of course, I personally support), then a time-to-live type value may be useful. As I pointed out in an earlier message, this same general type of approach is already used in some component agent implementations using existing extensible agent protocols in the field. While it does have some drawbacks, it also (clearly) has its uses. > In the Host Resources MIB example, you could register the > hrRunningSoftware subtree with a minimum update interval of e.g. 2 > seconds. This will avoid all wasted updates and will also limit the > max. number of updates. I'm not sure we can justify the claim that it will avoid "all" wasted updates...but it can reduce them for sure. > There is still some overhead compared to approaches without > instance-level registration. However, getnext and getbulk > processing as well as access control can be completely moved > to the master agent, which will make the component agent very simple. Yes, I agree. Assuming we won't identify a *perfect* solution, then each candidate solution will have its pluses and its minuses...in the end (I hope!) we will choose the one with the best overall result. > In an ideal world, I would like to have an agentx solution that will > make the implementation of subagents as simple as e.g. database > interfaces for the WWW using CGI. Instance-level registration might be > a way to reach this goal. Yes, I agree. I believe that is much that happens in practice in most deployed "whole product" solutions to agent extensibility than can be mapped to instance-level registration as an optimization...and, given that, a lot of potential additional optimiizations fall out...avoidance of GetNext and GetBulk in components, more importantly avoidance of access control issues in components, and the possibility for (implementation specific) registration time performance optimization (via pre-compiling the component agent MIBs by the system agent) and (implementation specific) MIB access time performance optimization (by caching data returned from component agents (although this one assumes agentx protocol support for a TTL-type indicator... although the default, of course, would be "none", ergo "ask every time"). I guess a lot of how one views this depends upon a important you think simplifying component agent construction is...I personally think it's of the utmost importance. (Btw, I know I own some others responses on this thread... I suffered a self-inflicted e-mail injury trying to get out of here in time to attend a family holiday event on the Friday before Christmas...so some of my e-mail is semi-offline to me at the moment...I'll work it out as quickly as possible and respond asap (I'm thinking of Mary Quinn's excellent question at the moment).) Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Tue, 02 Jan 1996 09:15:22 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id JAA24708 for X-agentx-local; Tue, 2 Jan 1996 09:15:21 -0800 (PST) Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id JAA24702 for ; Tue, 2 Jan 1996 09:15:20 -0800 (PST) Message-Id: <199601021715.JAA24702@zloty.fv.com> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 8889; Tue, 02 Jan 96 12:15:11 EST Date: Tue, 2 Jan 96 12:15:11 EST From: "Geoff Carpenter (8-862-1970)" To: agentx@fv.com Subject: Component agent non-interdependency Ref: Your note of Tue, 2 Jan 1996 01:04:26 -0500 (attached) Hi, Bob... > Thanks for the historical background (very useful stuff)... > I understand...but would just point out that a routine "close" > of the "broken component" and "open" of the repaired one > would appear to work just as well. This presupposes that 1) you can unregister the component (i.e., you have the appropriate priviledges with the underlying operating system) and 2) the sub-agent which implements the broken component is not providing any other services. Again, from a historical perspective, the VM TCP/IP implementation was done such that the TCP/IP virtual machine (the kernel if you will) acted as a giant DPI sub-agent along with all of its other tasks. It was extremely rare that one would have the priviledge level to restart said virtual machine and the effect of doing so would be non-trivial indeed -- pretty close to the effect of rebooting. I'm not a proponent of mainframes, but I do appreciate that their culture places great importance on availability. I have also observed that some modern SNMP agent implementations have taken a similar approach of implementing a core SNMP agent with the bulk of the instrumentation provided by sub-agents. My summary of the issue is this: one way or another, the case of a duplicate registration must be addressed. There are 3 approaches that come to mind based on prior practice: 1) reject the duplicate registration. The effect is clearly well- understood and easy to implement. 2) accept the duplicate registration and allow it to have precedence over a prior registration. While slightly more difficult to implement than the first case, this would permit run-time patching of faulty components. 3) allow components to be registered with various priority levels and have the agent sort them out. This is a generalization of the last-one-in-has-precedence scheme of the second case. My personal opinion is that case 1 is too restrictive and I haven't seen a compelling case for such rigidity. Case 3 appears to me to be a case of generalization without justification and would, if it was ever exploited, create opportunities for confusing interdependencies. I think it was this generalization which caused your concern. For me, case 2 is the way to go. Geoff Carpenter IBM Research -- Yorktown Heights, NY   Delivery-Date: Tue, 02 Jan 1996 11:13:48 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id LAA22493 for X-agentx-local; Tue, 2 Jan 1996 11:13:48 -0800 (PST) Received: from ftp.com (ftp.com [128.127.2.122]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id LAA22486 for ; Tue, 2 Jan 1996 11:13:47 -0800 (PST) Received: from ftp.com by ftp.com ; Tue, 2 Jan 1996 14:13:57 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 2 Jan 1996 14:13:57 -0500 Received: from toeloop.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA05274; Tue, 2 Jan 96 14:10:34 EST Message-Id: In-Reply-To: <9601012119.AA14778@nips.acec.com> References: Conversation <9601012119.AA14778@nips.acec.com> with last message <9601012119.AA14778@nips.acec.com> Priority: Normal To: Bob Natale Cc: agentx@fv.com Mime-Version: 1.0 From: Mary Quinn Subject: Re: MIBs in agentx Date: Tue, 02 Jan 96 14:34:20 EST Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Hi Bob, >> 7. My view is that the system agent should also >> "compile in" knowledge of the component agents... >> note that this yields all the necessary object >> registration information, except for instances >> of tabular objects. It also allows for enormous >> runtime efficiency of the registration process >> after the first time a component agent registers >> its MIB (until the next time a new version of the >> component MIB is installed). (Note that whether >> a particular system agent implementation actually >> did "compile in" the component MIBs knowledge in >> this manner is totally an implementation detail... >> if it didn't, it would pay a performance penalty >> in the marketplace relative to others implementations >> that did, but would have no impact on the agentx >> protocol itself.) I'm not sure what you are getting at here. I had always envisioned the extensible agent to be very dynamic- the term "compile in" knowledge doesn't fit with my picture of this. Are you alluding to the ability to specify the subagent pieces to the master agent via some sort of configuration file ? You don't seem to be advocating that this "facility" be part of the protocol. I don't understand the relevance. Mary Mary Quinn FTP Software 2 High St. N. Andover, MA 01844 (508) 659-6294 mquinn@ftp.com FAX: (508) 659-6038   Delivery-Date: Tue, 02 Jan 1996 11:39:24 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id LAA28741 for X-agentx-local; Tue, 2 Jan 1996 11:39:23 -0800 (PST) Received: from hp.com (hp.com [15.255.152.4]) by zloty.fv.com (8.7.3/8.7.1) with ESMTP id LAA28728 for ; Tue, 2 Jan 1996 11:39:21 -0800 (PST) Received: from nsmdserv.cnd.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA193701569; Tue, 2 Jan 1996 11:39:29 -0800 Received: from localhost by nsmdserv.cnd.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA287141569; Tue, 2 Jan 1996 12:39:29 -0700 Message-Id: <199601021939.AA287141569@nsmdserv.cnd.hp.com> To: agentx@fv.com Subject: Re: "System Group Roles" In-Reply-To: Your message of Fri, 29 Dec 1995 14:11:16 -0500. <9512291911.AA05472@nips.acec.com> Date: Tue, 02 Jan 1996 12:39:29 -0700 From: "Brian O'Keefe" > Hi Brian, > > In reviewing your slides from the Dallas agentx meeting > I noticed the following two bullets: > > o Each Logical Entity should support the system group > o Each Subagent does not have its own system group > > I would appreciate it very much if you would post a brief > (or longer) narrative describing these points in more > detail. First, please review the description clauses of the system group objects in RFC1213. This will give us a common basis of discussion. In a nutshell, several of us (Maria Greene, Andy Bierman, Dave Perkins and I) that prepared the presentation I gave in Dallas agentx meeting have tried to distinguish between a "logical entity" (being defined w/in the EntityMIB WG) and an agent "implementation component" or "subagent" (being defined w/in the AgentX WG) with respect to the system group. System Group: . the system group consists of information about a "managed system" . the managed system has a "network management portion" associated with it (for example, to which sysUpTime pertains) Logical Entity: . in some cases, the "managed system" is a single physical system . in other cases, the "managed system" is one of many logical systems . a logical system is one that could exist on its own as a single physical system (i.e., a repeater in a single vs stackable hub) Agent Implementation Component (sub-agent): . a single agent can provide access to one or many "managed systems" . a single managed system (be it logical or physical) may be instrumented via one or many implementation components . the same implementation component may be used to instrument a like-portion of multiple logical systems within the overall system. Therefore, we believe that the system group is a property of the "logical entity" (aka, logical managed system), not a property of each implementation component that instruments that managed system. If a single logical entity is implemented via multiple sub-agents, then only one of those sub-agents provides the instrumentation of the system group for that logical entity. Example (from the presentation): The single physical system contains FOUR "logical entities": a router entity, two bridge entities, and an overall system entity. Conversely, there are SIX "implementation components" or "sub-agents" providing the instrumentation of the various entities. The overall system (networked box) is instrumented by a single subagent (quite possibly the "master" or "primary" agent). The router entity is instrumented by two sub-agents. Each bridge entity is instrumented by two sub-agents; one that is unique to the respective bridge entity and one shared by the two bridge entities. According to the distinctions made above, there would be FOUR instances of the system group in this example -- one for the router, one for each bridge, and one for the overall physical system. In the case of the Router entity, only one of the two sub-agents would instrument the system group. The other sub-agent might (presumably) instrument a particular routing MIB such as the OSPF-MIB. Hope this helps, bok   Delivery-Date: Tue, 02 Jan 1996 13:56:08 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id NAA04162 for X-agentx-local; Tue, 2 Jan 1996 13:56:08 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id NAA04156 for ; Tue, 2 Jan 1996 13:56:06 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA05762 for agentx@fv.com; Tue, 2 Jan 96 16:56:13 -0500 Date: Tue, 2 Jan 1996 16:54:20 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA11666; Tue, 2 Jan 1996 16:54:20 -0500 Message-Id: <9601022154.AA11666@nips.acec.com> To: mquinn@ftp.com Subject: Re: MIBs in agentx Cc: agentx@fv.com > From: Mary Quinn > Date: Tue, 02 Jan 96 14:34:20 EST Hi Mary, [Speaking as a technical contributor...] > >> 7. My view is that the system agent should also > >> "compile in" knowledge of the component agents... <...> > I'm not sure what you are getting at here. I had always envisioned > the extensible agent to be very dynamic- For sure! > the term "compile in" knowledge doesn't fit with my picture of this. As in "MIB compile"...i.e., translate ASN.1 object defintions from text into some more efficient (implementation-specific) format...can happen at runtime...(not like "build time" for program development, for example). > Are you alluding to the ability to specify the subagent pieces > to the master agent via some sort of configuration file? No. > You don't seem to be advocating that this "facility" be part > of the protocol. You are right about that...I do imagine that in any sufficiently usable "whole product" solution something like "configuration files" will be used as part of the "user" interface (probably for a system administrator or setup utility...but it is, IMHO, definitely not part of the protocol itself. > I don't understand the relevance. The point I was making works like this...let's use the eSNMP write-up as an example to set the stage: - a component agent OPENs a connection with the system agent...as part of that operation (in eSNMP) the component agent includes a textual varbind with a descriptive name for the component agent. - then the component agent has to issue a series of one or more REGISTERs, telling the system agent the OID of each sub-tree it will manage and a textual varbind with a descriptive name for the sub-tree. Now, the way I would like to improve upon this is: - a component agent opens a connection with the system agent by creating a new row in a system agent table via a SetRequest which includes the name of the component agent's MIB. (Maybe "an intra-agent table" would be more precise here.) - the system agent (via implementation-specific means) identifies the corresponding MIB file and loads (i.e., "compiles in" in my previous posting) all the MIB objects this component agent will manage. - (An optional implementation-specific performance enhancement here would be to check whether the MIB file had changed--e.g., timestamp--since the last "open" by this component agent and, if not, perhaps use the previously "compiled in" version of this MIB. As this will be the usual case by far (i.e., not a new MIB file), the possible performance gains here could be significant.) - for a scalar objects in the component agent's MIB, the only possible instance value is known, so that's the end of that. - for any tabular objects the component agent would later "register" and "unregister" instances via an appropriately composed SetRequest into a system agent table. (Again, maybe "an intra- agent table" would be more precise here). Looks to me like an easy and efficient way for the system agent to acquire lots of "MIB knowledge" about its component agents...with high on-the-fly performance for the normal case. Of course, this all goes back to my fundamental views on the advisability of instance-level registration, piggy-backing on the need for the component agent to provide a MIB file for use by the management applications anyway, and leveraging the SNMP protocol as the foundation for the agentx protocol. (A concluding note about the last point...a protocol consists of message structures, semantics, and operations (possibly among other things). In my view, the agentx protocol could build off of SNMP for the basics of all of the above, but will specific "profiles" for each of them...e.g., instead of a special-purpose OPEN pdu, agentx would (i.e., *could*...I am just expressing one novice's personal suggestions here) use a standard SNMP SetRequest with certain required varbinds and certain required operations on the receiving end. The collection of these special requirements in terms of structure, semantics, and operations over and above the underlying SNMP would be the "agentx protocol".) I hope the above helps to clarify my position, Mary (or anyone else)...please let me know if it doesn't or it reveals additional weaknesses (besides lack of clarity, that is! :-). I realize that I tend to dribble this out like a bouncing ball when I really should compose a game plan and expose that for review... and I can only claim that I'm doing my best to get there and ask for your (collective) continued forebearance. In the meantime, let's see some additional input wrt other ways of approaching this. I think that Geoff Carpenter's input on some of the background behind certain design decisions and his explanation of the evolution (my word, not his) of his own views on the registration precedence issue(s) were very helpful. Mike Daniele has promised us a synopsis of and some more rationale for the eSNMP adaptation (my word, not his) of DPI...and I think this will be extremely interesting and informative. I am sure there are more of you out there with substantial ideas/analyses/opinions to contribute...let's have 'em! Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Tue, 02 Jan 1996 15:27:40 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id PAA29439 for X-agentx-local; Tue, 2 Jan 1996 15:27:40 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id PAA29432 for ; Tue, 2 Jan 1996 15:27:38 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA15607 for agentx@fv.com; Tue, 2 Jan 96 18:27:47 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA13959; Tue, 2 Jan 1996 18:25:19 -0500 Date: Tue, 2 Jan 1996 18:28:49 EST From: Bob Natale Subject: Re: Component agent non-interdependency To: "Geoff Carpenter (8-862-1970)" Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Geoff Carpenter (8-862-1970) > Date: Tue, 2 Jan 96 12:15:11 EST Hi Geoff, > > Thanks for the historical background (very useful stuff)... > > I understand...but would just point out that a routine "close" > > of the "broken component" and "open" of the repaired one > > would appear to work just as well. > > This presupposes that 1) you can unregister the component (i.e., > you have the appropriate priviledges with the underlying operating > system) Ok...now I don't want to beat this to death either...since in the end it looks like we are mostly in agreement...but I do see it as unlikely that a user or process would not have the privileges needed to "close" a component agent connection and "open" a new one, but would have the privileges to over-write a registration. > and 2) the sub-agent which implements the broken component > is not providing any other services. Granted...I'm working from the view that component agents should be relatively limited in scope...i.e., providing an agentx management interface to a managed component. > Again, from a historical perspective, the VM TCP/IP implementation > was done such that the TCP/IP virtual machine (the kernel if you > will) acted as a giant DPI sub-agent along with all of its other tasks. > It was extremely rare that one would have the priviledge level > to restart said virtual machine and the effect of doing so would > be non-trivial indeed -- pretty close to the effect of rebooting. > I'm not a proponent of mainframes, but I do appreciate that their > culture places great importance on availability. Granted...clearly (or not so clearly, many would say! :-), I usually speak from the perspective of an architectural bias that would preclude a "giant DPI sub-agent" form gaining control of my computers or my networks. :-) Seriously though: [Speaking as wg chair...] I think we all (?) share the view that in the agentx environment, component agents should be able to "come and go"--via whatever "open" and "close" protocol operations we provide. I am not saying that we might not impose some protocol constraints on that...just that the basic idea is that this will be a fairly dynamic runtime environment (at least potentially...even though any given real system might become fairly static at the "user's" discretion). If anyone disagrees with this view, please speak up. [Over...] > I have also observed that some modern SNMP agent implementations > have taken a similar approach of implementing a core SNMP agent > with the bulk of the instrumentation provided by sub-agents. Yes, I think that's the model we're are trying to promote via agentx standardization. > My summary of the issue is this: one way or another, the case > of a duplicate registration must be addressed. For sure. > There are 3 approaches that come to mind based on prior practice: > > 1) reject the duplicate registration. The effect is clearly well- > understood and easy to implement. > 2) accept the duplicate registration and allow it to have precedence > over a prior registration. While slightly more difficult to implement > than the first case, this would permit run-time patching of faulty > components. > 3) allow components to be registered with various priority levels > and have the agent sort them out. This is a generalization of the > last-one-in-has-precedence scheme of the second case. > > My personal opinion is that case 1 is too restrictive and I haven't seen > a compelling case for such rigidity. Well, to borrow a comment from a posting by Dave Crocker on the ietf-pkix list earlier today: "This moves one back to the dictum of forceful simplicity to facilitate adoption by a diverse community." So, the very advantages you cite ("The effect is clearly well- understood and easy to implement.") become the "compelling case" for it. But, ok, maybe we can do better. > Case 3 appears to me to be a case of generalization without > justification and would, if it was ever exploited, create > opportunities for confusing interdependencies. > I think it was this generalization which caused your concern. Exactly. > For me, case 2 is the way to go. I can agree with that. Anyone else have an opinion or experience which suggests one of the other alternatives would be superior? Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Tue, 02 Jan 1996 16:21:46 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id QAA14085 for X-agentx-local; Tue, 2 Jan 1996 16:21:45 -0800 (PST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id QAA14076 for ; Tue, 2 Jan 1996 16:21:44 -0800 (PST) Received: from flume.zk3.dec.com by mail11.digital.com; (5.65v3.2/1.0/WV) id AA01289; Tue, 2 Jan 1996 19:10:12 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA14281; Tue, 2 Jan 1996 19:10:09 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA04591; Tue, 2 Jan 1996 19:10:31 -0500 Message-Id: <9601030010.AA04591@bernie.zk3.dec.com> To: natale@acec.com (Bob Natale) Cc: agentx@fv.com Subject: Re: MIBs in agentx In-Reply-To: Your message of "Tue, 02 Jan 96 16:54:20 EST." <9601022154.AA11666@nips.acec.com> Date: Tue, 02 Jan 96 19:10:31 -0500 From: Mike Daniele X-Mts: smtp Hi Bob, >Now, the way I would like to improve upon this is: > - a component agent opens a connection with the > system agent by creating a new row in a system > agent table via a SetRequest which includes the > name of the component agent's MIB. (Maybe "an > intra-agent table" would be more precise here.) > - the system agent (via implementation-specific > means) identifies the corresponding MIB file > and loads (i.e., "compiles in" in my previous > posting) all the MIB objects this component > agent will manage. What if there is no MIB file, nor even a (conceptual) MIB associated with the connection? [admittedly unlikely] What if the component agent wishes to register only a specific subtree within a MIB? [a real-world situation i think we need to address] At first glance, no problem. The component agent just returns errors for the parts of the MIB it doesn't implement. But what if a different component agent implements the rest of the MIB? This leads to some really fundamental questions that need to be answered for agentx: o Will the system agent contain knowledge of component MIBs? o Will the protocol permit truly dynamic inclusion of new component agents? o What is the unit of registration? o What rules (algorithms) are specified around registration? o Are "instance registrations" allowed, and if so, how are they handled? o How are MIB views handled? >Mike Daniele has promised us a synopsis >of and some more rationale for the eSNMP adaptation >(my word, not his) of DPI... And it's accurate. One of the things I wanted to mention up front is that from a protocol perspective, eSNMP is almost identical to, and was based heavily on DPI. If you are anticipating an entirely new extensible agent protocol, you'll be disappointed. Sorry if I've wasted anybody's time out there. >and I think this will be extremely interesting and informative. Well, I hope so :-) I'm having trouble getting a single all-encompassing synopsis together, maybe it will be best to approach this in pieces. So let me answer the questions I posed above wrt eSNMP. While the eSNMP spec uses the terms 'master' and 'sub' agent, I'll try to use system and component respectively from now on. (Note that to a large extent I'm answering for the other reference protocols, since (as I read them) they are quite similar in many aspects. I do NOT presume however to speak for the authors or implementors of those protocols.) o Will the system agent contain knowledge of component MIBs? The eSNMP system agent contains absolutely no (zero) knowledge ANY MIB. o Will the protocol permit truly dynamic inclusion of new component agents? The eSNMP system agent expects component agents to handshake and register via the protocol. No configuration information is known from other mechanisms. We needed an environment that was truly dynamic. In particular, we could not assume the system agent knows when to start and when to stop component agents. That is, a process that functions as a component agent is likely to have other non SNMP-related functions, and must be able to start and stop, and register and unregister as it wishes. o What is the unit of registration? The eSNMP system agent's is a single oid. Component agents register oids, not oid ranges, not conceptual rows by instance. Registering an oid IMPLIES a range, and the responsibility to implement objects whose oids are within the implied range. For example: system (1.3.6.1.2.1.1) implies a range from 1.3.6.1.2.1.1 up to but not including 1.3.6.1.2.1.2. o What rules (algorithms) are specified around registration? In eSNMP we permit what Dave Keeney phrases as "overlapping registrations" with associated priorities. We did this because we thought it was a general requirement that the protocol be flexible enough to handle one component agent wishing to implement a subtree within another component agents' registered subtrees. (This is an attempt to account for the eventuality that oids defined in 1 MIB are contained by those defined in other MIBs, e.g., ipForwardingTable.) The relative value of priorities would need to be worked out a priori. That is, it's really for cooperating component agents. All registrations are kept track of by the system agent. Ranges subsumed by higher priority registrations are inactive. If a component agent unregisters then another component agent's registration may become active. Only the active registration is dispatched to when processing SNMP requests. In eSNMP, there is no way for a component agent to know whether or not its registration is active (within the protocol explicitly, of course a method routine being executed indicates active registration.) This whole arrangement gives rise to specific algorithms in both the component and system agents protocol entities for processing GetNext/Bulk requests. (As Aleksey pointed out, the component agent needs to be made aware what range of oid it may respond to.) I don't think it's time to describe the particulars yet, given where we are in the process. these are some of the differences between eSNMP and DPI. While a system agent MIB could add clarity here, I think we still need to agree on what a registration is, what a 'duplicate registration' is, and how they will be processed. o Are "instance registrations" allowed, and if so, how are they handled? The eSNMP component agents may register oids that contain instance values, but the system agent doesn't notice any difference, it's just another oid. Note that a component agent therefore registers a conceptual row by registering each column in the row. o How are MIB views handled? We punted MIB views in eSNMP. I'll try to post other differences/assumptions/rationale soon. > - for a scalar objects in the component agent's > MIB, the only possible instance value is known, > so that's the end of that. > - for any tabular objects the component agent > would later "register" and "unregister" instances > via an appropriately composed SetRequest into > a system agent table. (Again, maybe "an intra- > agent table" would be more precise here). >Looks to me like an easy and efficient way for the system >agent to acquire lots of "MIB knowledge" about its component >agents...with high on-the-fly performance for the normal >case. Of course, this all goes back to my fundamental >views on the advisability of instance-level registration, >piggy-backing on the need for the component agent to provide >a MIB file for use by the management applications anyway, >and leveraging the SNMP protocol as the foundation for the >agentx protocol. I really agree with most everything you say. I disagree with your assumption of what "the normal case" is, and hence with the viability of making a scheme like this into the standard. I think a few contributors now have pointed out real flaws with the idea that the system agent knows about all instances of everything. It would render some very real, existing MIB implementations virtually impossible to build according to agentx. Conversely, you COULD build your idea using DPI for example as agentx, and impart the simplicity you wish to end users, by a suitable toolkit and API (as part of your value-added solition for building component agents). The protocol needs to permit both. (I seem to find myself beating the dead horse again :-) Regards, Mike   Delivery-Date: Tue, 02 Jan 1996 16:35:24 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id QAA18141 for X-agentx-local; Tue, 2 Jan 1996 16:35:23 -0800 (PST) Received: from lightning.synoptics.com (lightning.synoptics.com [134.177.3.18]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id QAA18135 for ; Tue, 2 Jan 1996 16:35:22 -0800 (PST) Received: from pobox ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA22996; Tue, 2 Jan 96 16:33:55 PST Received: from wolverine.engwest by pobox (4.1/SMI-4.1) id AA19371; Tue, 2 Jan 96 16:28:54 PST Received: by wolverine.engwest (4.1/SMI-4.1) id AA04669; Tue, 2 Jan 96 16:29:20 PST Date: Tue, 2 Jan 96 16:29:20 PST From: johns@BayNetworks.COM (John Seligson) Message-Id: <9601030029.AA04669@wolverine.engwest> To: gcc@watson.ibm.com, natale@acec.com Subject: Re: Component agent non-interdependency Cc: agentx@fv.com > > My summary of the issue is this: one way or another, the case > > of a duplicate registration must be addressed. > > For sure. > > > There are 3 approaches that come to mind based on prior practice: > > > > 1) reject the duplicate registration. The effect is clearly well- > > understood and easy to implement. > > 2) accept the duplicate registration and allow it to have precedence > > over a prior registration. While slightly more difficult to implement > > than the first case, this would permit run-time patching of faulty > > components. > > 3) allow components to be registered with various priority levels > > and have the agent sort them out. This is a generalization of the > > last-one-in-has-precedence scheme of the second case. > > > > My personal opinion is that case 1 is too restrictive and I haven't seen > > a compelling case for such rigidity. > > Well, to borrow a comment from a posting by Dave Crocker on the > ietf-pkix list earlier today: > > "This moves one back to the dictum of forceful simplicity > to facilitate adoption by a diverse community." > > So, the very advantages you cite ("The effect is clearly well- > understood and easy to implement.") become the "compelling case" > for it. But, ok, maybe we can do better. > > > Case 3 appears to me to be a case of generalization without > > justification and would, if it was ever exploited, create > > opportunities for confusing interdependencies. > > I think it was this generalization which caused your concern. > > Exactly. > > > For me, case 2 is the way to go. > > I can agree with that. > > Anyone else have an opinion or experience which suggests > one of the other alternatives would be superior? I feel a priority registration mechanism should not be precluded by the design. A simple trade-off would be to allow component agents that are aware of each other register with a priority. Component agents that don't know about anyone else could register with no priority value and be given the highest priority value by the system agent should other component agents register for the same object space. I assume that the "precedence" mentioned in item 2 above means that one component agent will be called before another, not that only one component agent is queried. When multiple component agents register for the same object space, each presumably handles different object instances. Each component agent will need to be queried during GetNext processing, allowing the system agent to compute and return the lexi-least return OID value. Just a clarification. John   Delivery-Date: Wed, 03 Jan 1996 03:51:46 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id DAA10126 for X-agentx-local; Wed, 3 Jan 1996 03:51:46 -0800 (PST) Received: from pokey.maxm.com (POKEY.MAXM.COM [192.147.28.65]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id DAA10121 for ; Wed, 3 Jan 1996 03:51:45 -0800 (PST) Received: from kirk.maxm.com by pokey.maxm.com (AIX 3.2/UCB 5.64/4.03) id AA22821; Wed, 3 Jan 1996 06:30:08 -0600 Received: by kirk.maxm.com (AIX 3.2/UCB 5.64/4.03) id AA54434; Wed, 3 Jan 1996 06:47:43 -0500 Date: Wed, 3 Jan 1996 06:47:43 -0500 From: jwest@maxm.com (Jim West) Message-Id: <9601031147.AA54434@kirk.maxm.com> To: agentx@fv.com, natale@acec.com Subject: Re: PDUs, proto-ops, and principles Hi Bob, Sorry about the timeliness of this response, but I've been on vacation for a week. >Date: Fri, 22 Dec 1995 13:53:05 EST >From: Bob Natale >Subject: PDUs, proto-ops, and principles In general I like this proposal. Using SNMP as the transfer protocol between system agents and component agents will satisfy several of my needs. However, >One way I can see to do this is to restrict the PDU handling >requirements in the component agent to just four standard >SNMP PDU types: > > - GetRequest > - SetRequest > - Response > - Trap I have to agree with others that the GetNext Request needs to be added to this list. From my experience, GetNext isn't that expensive to implement and would provide several benefits including: +Simpilar system agents. +Component Agents that I can either use as component agents or monolithic agents. Jim   Delivery-Date: Wed, 03 Jan 1996 04:06:45 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id EAA12296 for X-agentx-local; Wed, 3 Jan 1996 04:06:44 -0800 (PST) Received: from aristo.tau.ac.il (aristo.tau.ac.il [132.66.32.10]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id EAA12281 for ; Wed, 3 Jan 1996 04:06:38 -0800 (PST) Received: from gandalf (world.lannet.com) by aristo.tau.ac.il with SMTP id AA02815 (5.67b/IDA-1.5 for ); Wed, 3 Jan 1996 14:06:23 +0200 Received: from moon.lannet.com by gandalf (4.1/SMI-4.1) id AA25370; Wed, 3 Jan 96 14:07:29 IST Received: from smtplink.lannet.com by moon.lannet.com (4.1/SMI-4.1) id AA04636; Wed, 3 Jan 96 14:04:35 IST Received: from Connect2 Message Router by smtplink.lannet.com via Connect2-SMTP 4.00; Wed, 3 Jan 96 14:05:59 -0500 Message-Id: <5D86EA30010CB6AA@smtplink.lannet.com> In-Reply-To: <3D23EA30010CB6AA> Date: Wed, 3 Jan 96 14:12:26 -0500 From: Dan Romascanu Sender: Dan Romascanu Organization: Lannet Ltd. To: gcc@watson.ibm.com ("Geoff Carpenter (8-862-1970)"), natale@acec.com (Bob Natale) Cc: agentx@fv.com Subject: Re: Component agent non-interde X-Mailer: Connect2-SMTP 4.00 MHS to SMTP Gateway Hi Bob, >[Speaking as wg chair...] >I think we all (?) share the view that in the agentx environment, >component agents should be able to "come and go"--via whatever >"open" and "close" protocol operations we provide. I am not >saying that we might not impose some protocol constraints on >that...just that the basic idea is that this will be a fairly >dynamic runtime environment (at least potentially...even though >any given real system might become fairly static at the "user's" >discretion). >If anyone disagrees with this view, please speak up. >[Over...] I am not sure what would be the applicability of the 'close' protocol operation. In the cruel physical world where I need to implement my projects, cards are extracted from the slots or PSUs are down before the logical entitities that run on the physical devices have the time to properly 'close' the connection. That's why periodical 'are you there?' messages (like the ones you proposed in one of your earlier mails) are required, while I hardly can see the use of the 'close' messages. Dan Romascanu, Madge Networks (Israel) Ltd., Voice: 972-3-645-8414, e-mail: dan@lannet.com   Delivery-Date: Wed, 03 Jan 1996 07:10:33 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id HAA17086 for X-agentx-local; Wed, 3 Jan 1996 07:10:29 -0800 (PST) Received: from ftp.com (ftp.com [128.127.2.122]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id HAA17080 for ; Wed, 3 Jan 1996 07:10:23 -0800 (PST) Received: from ftp.com by ftp.com ; Wed, 3 Jan 1996 10:10:28 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 3 Jan 1996 10:10:28 -0500 Received: from toeloop.ftp.com by MAILSERV-D.FTP.COM (5.x/SMI-SVR4) id AA03616; Wed, 3 Jan 1996 10:10:56 -0500 Message-Id: In-Reply-To: <9601031147.AA54434@kirk.maxm.com> References: Conversation <9601031147.AA54434@kirk.maxm.com> with last message <9601031147.AA54434@kirk.maxm.com> Priority: Normal To: Jim West , agentx@fv.com, Bob Natale Mime-Version: 1.0 From: Mary Quinn Subject: Re: PDUs, proto-ops, and principles Date: Wed, 03 Jan 96 10:30:49 EST Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Jim and Bob, Jim West wrote: >> >> In general I like this proposal. Using SNMP as the transfer >> protocol between system agents and component agents will >> satisfy several of my needs. >> I assume this implies BER encoding /decoding to be done in the subagents? Many of the "solution space" implementations pass varbinds in an alternate form between master/sub agent. Has anyone done a comparision of the pros/cons of the different approaches? Mary Mary Quinn FTP Software 2 High St. N. Andover, MA 01844 (508) 659-6294 mquinn@ftp.com FAX: (508) 659-6038   Delivery-Date: Wed, 03 Jan 1996 08:19:48 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id IAA02018 for X-agentx-local; Wed, 3 Jan 1996 08:19:48 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id IAA02013 for ; Wed, 3 Jan 1996 08:19:47 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA06943 for agentx@fv.com; Wed, 3 Jan 96 11:19:55 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA03245; Wed, 3 Jan 1996 11:18:31 -0500 Date: Wed, 3 Jan 1996 11:21:00 EST From: Bob Natale Subject: "Close" operation To: Dan Romascanu Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Dan Romascanu > Date: Wed, 3 Jan 96 14:12:26 -0500 > Subject: Re: Component agent non-interde Hi Dan, [Speaking as a technical contributor...] > I am not sure what would be the applicability of the > 'close' protocol operation. Ok...let's start from the observation that all of the reference protocols in our current solution space include such an operation. Just a data point. > In the cruel physical world where I need to implement > my projects, cards are extracted from the slots or PSUs > are down before the logical entitities that run on the > physical devices have the time to properly 'close' the > connection. This can happen (obviously) and must be taken into account, both by the eventual agentx protocol and by each specific implementation. The default position wrt the agentx protocol's handling of this as of now (i.e., based on how the reference protocols do it) would seem to be that the system agent detects the loss of connectivity with the component agent based upon the timeout of a subsequent protocol operation request directed to that component agent. > That's why periodical 'are you there?' messages (like > the ones you proposed in one of your earlier mails) > are required, Yes, but as implemented in DPI (for example) the "Are_You_There" request is sent from the component agent to the system agent to verify that the system agent is still running. (In my scheme, this special- purpose packet would not be needed since a simple SNMP GetRequest for sysUpTime, for example, from component agent to system agent would accomplish the same purpose.) > while I hardly can see the use of the 'close' > messages. Well, there are a number of potentially good uses for it. (Again, remember that in my scheme, there would be no special-purpose "close" (or "open") operation types, but rather standard SNMP Sets into some intra-agent table to indicate status.) First, we can think of a common user environment (e.g., a PC) in which a user might want to be able to start and stop physical components (e.g., a printer)...done in an orderly fashion, the component agent should be able to signal the system agent that it is terminating since it will no longer have anything to manage, thus allowing the system agent to free up resources that might be dedicated to that component agent. Another example might be the emerging applications management domain...in which (possibly) each application will have a component agent and since applications can come and go it will be useful to permit the component agents to signal the fact that they are terminating...for the same reasons and with the same benefits as the preceding example. So, I think that a logical "close" operation--as well as a corresponding logical "open" operation-- has its valid uses...and I would probably categorize these logical operations as "necessary" for the agentx protocol. But, as your observation made clear, we do have to account for the case in which a component agent may "die" without having been able to do an orderly "close". Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Wed, 03 Jan 1996 08:38:42 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id IAA06907 for X-agentx-local; Wed, 3 Jan 1996 08:38:41 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id IAA06903 for ; Wed, 3 Jan 1996 08:38:40 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA09151 for agentx@fv.com; Wed, 3 Jan 96 11:38:42 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA03493; Wed, 3 Jan 1996 11:37:19 -0500 Date: Wed, 3 Jan 1996 11:39:49 EST From: Bob Natale Subject: Re: PDUs, proto-ops, and principles To: Mary Quinn Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Mary Quinn > Date: Wed, 03 Jan 96 10:30:49 EST > Subject: Re: PDUs, proto-ops, and principles Hi Mary, > Jim West wrote: > >> > >> In general I like this proposal. Using SNMP as the transfer > >> protocol between system agents and component agents will > >> satisfy several of my needs. > > I assume this implies BER encoding /decoding to be done in the > subagents? In my scheme, the answer is "Yes...but...", where the "but..." will be that the BER work will not really need to be done *in* the component agent code itself in most cases (see below). > Many of the "solution space" implementations pass > varbinds in an alternate form between master/sub agent. True. And that is a prima facie case against "my scheme" which (by my own self-imposed guidance as wg chair) argues strongly against adopting my scheme ["Isn't Life Ironic?", Alanis Morrissette*, from "Jagged Little Pill"]. I will have to make the case--as a technical contributor--that this deviation from the solution space represents a worthy trade-off. > Has anyone done a comparision of the pros/cons of the > different approaches? Well, this general issue is one that pops up regularly in a variety of working groups dealing with protocols. Right now, for instance, it is being discussed in the pkix (and/or ipsec) wg. (And if you think I'm confused about SNMP, you should see how confused I am about PKI, certificates, multi-tiered security encapsulations, and most of the other stuff they are debating! :-) And there have been various informal comparisons that I know of...I think that Karl Auerbach has posted some good ones from time to time on the various SNMP threads. For me, it boils down to "I favor the SNMP/ASN.1/BER approach because:" - The rules are fairly well-defined and well-known to all of us; - we're talking about an inter-process protocol with no end-user exposure (so a text-based protocol is not needed); - most of the "complexity" of these protocol elements will be hidden from component agent developers via SNMP libraries; - most implementations will be able to re-use *existing* SNMP library code for this purpose; - most implementations will be able to share this SNMP library code at runtime between system agent and component agents (and possibly even with management apps). I hope that helps explain the rationale behind my view. *Alanis Morrissette, "The Bob Dylan of Generation X!" (tm) :-) Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Wed, 03 Jan 1996 10:50:06 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id KAA11704 for X-agentx-local; Wed, 3 Jan 1996 10:50:05 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id KAA11697 for ; Wed, 3 Jan 1996 10:50:03 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA26774 for agentx@fv.com; Wed, 3 Jan 96 13:50:07 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA04841; Wed, 3 Jan 1996 13:48:44 -0500 Date: Wed, 3 Jan 1996 13:51:14 EST From: Bob Natale Subject: Agentx WG Status Report To: kostick@qsun.ho.att.com Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi Deirdre, [Speaking as wg chair...] Since the wg has been fairly active since its inception in early November (and since I'm going to be out-of-town and incommunicado for a long weekend starting tomorrow), I thought I'd provide you (and the wg readership) a brief (?) report on our progress and status to date. We had a very informative and productive pair of meetings at the Dallas IETF in early December, organized and moderated by Marshall Rose, who was the wg chair at the time. A number of very instructive presentations were made, largely based on the implementation experiences of the presenters...and a fair portion of that material has still under discussion/consideration and/or some from of action in the wg. Unfortunately, one non- technical outcome of the Dallas meeting was that Marshall elected to resign as wg chair. As the new wg chair, I outlined some proposed "ground rules" during a brief presentation I made at Dallas. These included: - A major focus on correct process operation in the wg - A working orientation toward the "solution space", as opposed to the "problem space" - Cooptation of the deployed and openly published implementations as the "reference protocols" of the solution space - A bottom-up approach...working from the operational specifics of the reference protocols outward toward architectural generalities - An bias toward leveraging SNMP to the maximum extent possible (subject to cost/benefit trade-offs). I think there has been reasonable acceptance of these guidelines to date and, impressively, a visible and substantive attempt on the part of every participant thus far to give them a fair shot, even in cases where one or more of those participants would personally have chosen some differing approach(es). This is very encouraging, particularly wrt the first guideline above--"focus on corret process operation of the wg"--given the recnet/current history of some IETF wg experiences. To further ensure a positive result in that regard--and especially since I am personally inclined to participate in the technical discussions (although I will throttle this tendency somewhat as soon as a solid line of consensus emerges), I have asked you to consider identifying and appointing a "Facilitator" for the wg, whose sole purpose whould be to monitor the activity of the wg for any signs of improper process actions and advise me as to how to correct them. I am still hopeful that you will be able to find such a person. In the meantime, I hope I am stating the common view when I claim that it seems that we have had no process problems thus far. Wrt the orientation toward the "solution space" vs the "problem space", my thinking was that most of the active participants in the agentx wg have been discussing many aspects of the problem space--e.g., requirements, design goals, interactions with other technologies, and so forth--for a number of years and--while we may not have agreement on them--we do have a relatively complete shared knowledge of them. During the last major non-IETF push at this, the major output was a substantial body of work defining numerous requirements/issues/paradoxes in the problem space. All signs are that consideration, refinement, and (egad!) expansion of the problem space could go on indefinitely. So, we are saying that there is clearly a sizable installed base of deployed extensible agent technology. Let's start from that and see what commonalities we can identify, what refinements must be made to merge the "best of the best" of them, what new features must then be added to cover enough of the knwon problem space to warrant standardization and deployment by an even larger provider and user base. The focus on the solution space does *not* mean that any discussion of the problem space is "out of order". And, in fact, I have (just recently) received one off-list message about requirements that I will forward to the list after removing any identification of the original sender. But all in all, I think it is fair to state that most active participants seem to agree that this new orientation might have value in its own right and, moreover, might help move us off of square zero this time. We have used several published documents to define a loose collection of "reference protocols" to work from. These documents include RFCs (e.g., 1227, 1228, 1592) and other papers (e.g., the eSNMP write-up and Harmen van der Linde's helpful comparative thesis, among others). We are actively soliciting similar inputs from other sources of deployed extensible agent solutions...and would particularly like to get it from SNMP Research (for EMANATE) and Epilogue (for ENVOY) and any others with similar products. As of this time, it is uncertain that we will receive additional inputs of this nature. But I think it is fair to state that the published information we do have about the "reference protocols" (now, SMUX, DPI 1 & 2, UT-SNMP, OAA, and eSNMP) provides a fair basis for evaluation of common elements and features. The "bottom-up" approach in this case is closely related to the "solution space" and "reference protocols" ideas... we are trying to work from specifics that are in use in the field as a basis for analysis and refinement, as opposed to starting from architectural concepts and design goals. Again, it is not the belief that these "top-down" elements are unimportant...quite the contrary...just that we do have a fair amount of shared knowledge about them already--and, yes, that includes a fair amount of disagreement over some of them too--and working from that direction has not proven fruitful to date. So, the bottom-up approach in this case says, for example, "let's look at the deployed functionality ...say, this "open" or this "close" operation...and assess how well it works or how it could be improved, in light of the other deployed solutions and in light of our shared knowledge of the solution space". Again, I think it is fair to claim that, thus far, most active participants have accepted this a strategy at least worth trying. And there are early signs that it is bearing fruit. The final guideline wrt a "bias toward leveraging SNMP" is intended to orient us toward the way to "harmonize" any merging/refining/extending that will need to be done based upon the comparative analysis of the reference protocols and the attempt to fit the resulting solution space to the known problem space. As with all these guidelines, the degree of application of it in the end will involve a cost/benefit assessment in relation to counter-approaches. At present, there seems to be some acceptance of this "bias" in the wg, but at least an equal amount of skepticism toward it too. The most signifiant "problem" that has emerged to date, I believe, is the fact that the wg chair (me) is also playing an active role as a technical contributor... perhaps the most active up to this time. At least one wg member asked that I take care to distinguish my postings as a technical contributor from those I post as "wg chair" to avoid confusion. And I am now trying to remember to do this on all postings. It is fair to say that some respondents to *seem* to accord more meaning to technical contributions from the wg chair than they should. (Such technical contributions are simply that and should be judged solely on their technical merit or lack thereof.) This potential problem is further exacerbated by the fact that my technical proposals, in general, *seem* to violate (or seem to tend to violate) some of the solution space ground-rules I myself stipulated! :-( I don't think this will escalate into a serious problem because: - if it does, I will refrain from pursuing my proposals; and - in the end, I am sure that I am being faithful to the full set of guidelines (although the piece-meal view I have been presenting may hide that fact at any given point in time); and - as soon as a solid line of consensus begins to emerge--even if 100% opposite from my technical proposals--I will devote all my energies to being wg chair and promoting this consensus exclusively. Also, I am hopeful that we have the "Facilitator" available to make sure nothing goes wrong in that respect. Finally, a word about the schedule. The wg was supposed to submit "initial drafts" by the end of December. While we cannot claim formal completion of that milestone as a wg, our positiion is that the assembled body of reference protocol documents (which we hope will be further extended in the very near future) is an acceptable surrogate for that goal at this point in time. I do not think we will be able to produce the "real thing" in this regard--i.e., an *initial* draft or set of drafts--until the end of January at the earliest. I have received several off-list postings from senior members of the community saying that they intend to participate actively, but simply cannot do it at this time...mostly due to the combined business/travel/ holiday schedules during the mid-November/early-January period. We will need the input from these people, both to ensure technical excellence and to form a solid consensus. One other interim "output" of the wg to date was reaching apparent consensus on separating "proxy" from "agentx" solutions; acknowledging that both play important roles in realizing flexible use of SNMP and will likely, in fact, co-exist in many management environments; and we have issued a (perhaps too vague) request to the "proxy community" to forumate a BCP-type document that could become an additional work product of the agentx wg (or not, at their discretion). Well, I think that's a fair assessment of where things stand. Others are invited to correct any misconceptions that they may perceive in any of the above. I'll plan on providing a similar report at the end of January... that one will likely be almost entirely focused on specific technical decisions and achievements, rather than explaining the process rationale as I have done in this one. Please let me know if you have any questions, comments, or guidance. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Wed, 03 Jan 1996 11:29:12 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id LAA21667 for X-agentx-local; Wed, 3 Jan 1996 11:29:12 -0800 (PST) Received: from pokey.maxm.com (POKEY.MAXM.COM [192.147.28.65]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id LAA21659 for ; Wed, 3 Jan 1996 11:29:11 -0800 (PST) Received: from kirk.maxm.com by pokey.maxm.com (AIX 3.2/UCB 5.64/4.03) id AA23352; Wed, 3 Jan 1996 14:07:41 -0600 Received: by kirk.maxm.com (AIX 3.2/UCB 5.64/4.03) id AA49826; Wed, 3 Jan 1996 14:25:16 -0500 Date: Wed, 3 Jan 1996 14:25:16 -0500 From: jwest@maxm.com (Jim West) Message-Id: <9601031925.AA49826@kirk.maxm.com> To: agentx@fv.com, mquinn@ftp.com Subject: Re: PDUs, proto-ops, and principles >From: Mary Quinn >Subject: Re: PDUs, proto-ops, and principles >Date: Wed, 03 Jan 96 10:30:49 EST Hi Mary, >I assume this implies BER encoding /decoding to be done in the >subagents? This is the assumption I have been making about the proposals Bob has presented. I have also assumed the following: 1. SNMP Sets would be used to perform registration between the component agent and the system agent. 2. My component agent will have access to the complete SNMP PDU, so I can get at things such as the community string associated with the request. 3. If a component agent want to retrieve information from another component agent, it would issue an SNMP Get (or GetNext) and send it to the system agent, which would make sure that it gets to the appropriate component agent. Am I off base with these assumptions? Jim West   Delivery-Date: Wed, 03 Jan 1996 13:20:30 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id NAA20422 for X-agentx-local; Wed, 3 Jan 1996 13:20:26 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id NAA20415 for ; Wed, 3 Jan 1996 13:20:21 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA16038 for agentx@fv.com; Wed, 3 Jan 96 16:20:28 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA06374; Wed, 3 Jan 1996 16:19:05 -0500 Date: Wed, 3 Jan 1996 16:21:36 EST From: Bob Natale Subject: Re: PDUs, proto-ops, and principles To: Jim West , mquinn@ftp.com Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Jim West > Date: Wed, 3 Jan 1996 14:25:16 -0500 Hi Jim, > >From: Mary Quinn > >Date: Wed, 03 Jan 96 10:30:49 EST > >I assume this implies BER encoding /decoding to be done in the > >subagents? > > This is the assumption I have been making about the proposals > Bob has presented. I have also assumed the following: > > 1. SNMP Sets would be used to perform registration between > the component agent and the system agent. Correct. Ditto wrt "unregistering" (primarily instances, in my view). And I would see the bulk of registration being done through the initial "open" SetRequest from component agent to system agent which would indicate the MIB name to use for this. > 2. My component agent will have access to the complete SNMP > PDU, so I can get at things such as the community string > associated with the request. Correct...although the RequestID could be (and most likely would be) a system agent determined value, rather than the originating application PDU's value. As a real important sidebar to this one, however, please note that a big motivator behind my scheme is to avoid access control issues in the component agents (ergo, the community string passed...like the RequestID above...*could* be a system agent specific value used for intra-agent control purposes). Additional motivation for seeing it this way is that, ideally (in my view), only the overall extensible agent gets configured by the "user", not each individual component agent directly...all community profile info is at the extensible agent level (which encompasses the system agent and the component agents). > 3. If a component agent want to retrieve information from > another component agent, it would issue an SNMP Get > (or GetNext) and send it to the system agent, which > would make sure that it gets to the appropriate > component agent. Exactly right. > Am I off base with these assumptions? As far as reflecting what I (personally) had in mind, you are right on target. Btw, let me take this opportunity to say two things that I might repeat in responses to one or more other earlier messages from others that elicited the need: 1. I am not going to push much harder for "my scheme". I will probably pursue it to the point of a brief (ha! ;-) draft-like overview, mostly for the intellectual satisfaction of it and to make myself pay those dues. I am more anxious--as wg chair--to see a consensus position emerge that is more directly rooted in the solution space and I will then devote my energies to advancing that. At the moment, based upon the inputs that we have all seen so far, I'd say that possible consensus position *might* be something more akin to a "DPI v3"...? 2. Even within my scheme--while I do hate to concede the point in terms of running code--I might be willing to drop the features which allow for all GetNext and GetBulk to be done in the system agent (via multi-varbind Gets to the component agents), due to the possible performance issues with instance registration for component agents that manage large *and* highly volatile datasets (i.e., where *many* instances come and go with very short lifetimes). I am still considering (rather, trying to find time to consider) whether dropping this feature--with its consequent introduction of the need to do "instance searching via exception returns"--detracts so much from my scheme as to render it not worth further cycles. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Wed, 03 Jan 1996 14:08:09 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id OAA02651 for X-agentx-local; Wed, 3 Jan 1996 14:08:09 -0800 (PST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id OAA02645 for ; Wed, 3 Jan 1996 14:08:08 -0800 (PST) Received: from flume.zk3.dec.com by mail11.digital.com; (5.65v3.2/1.0/WV) id AA04801; Wed, 3 Jan 1996 16:57:41 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA05476; Wed, 3 Jan 1996 16:57:38 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA04747; Wed, 3 Jan 1996 16:58:01 -0500 Message-Id: <9601032158.AA04747@bernie.zk3.dec.com> To: natale@acec.com (Bob Natale) Cc: agentx@fv.com Subject: Re: MIBs in agentx In-Reply-To: Your message of "Mon, 01 Jan 96 16:19:14 EST." <9601012119.AA14778@nips.acec.com> Date: Wed, 03 Jan 96 16:58:00 -0500 From: Mike Daniele X-Mts: smtp Hi Bob, I didn't get a chance to address the first 6 items, having gotten lost in the furor over #7 :-) >[Speaking as a technical contributor...] >It seems to me that it might be helpful to have a >brief discussion about the role(s) of MIBs in the >extensible agent context. The way that I see this >issue, it reveals some strong drivers toward some >refinements of the solution space...I'd like to >know what different views others hold on this >general topic or any of the specifics I will mention. >1. First of all, one of our goals is that properly >authorized management applications see a self- >consistent standard SNMP MIB space at the system >agent interface encompassing all the management >objects accessible via the system agent, with no >particular knowledge of the existence of component >agents *required* by those management applications. Absolutely. >2. The "extensible agent" is a virtual agent... >consisting of the system agent and the collection >of active component agents at any point in time. >The extensible agent, per se, does not implement >a MIB. Agreed. >3. The system agent is a real agent...it will >implement a standard system agent MIB. This MIB >may serve multiple purposes...e.g., enabling the >management applications to configure the extensible >agent environment and monitoring information about >the extensible agent environment. Is it correct for me to think of this MIB as similar to the subAgent MIB that Bert posted to the list? I agree that the system agent should itself implement a MIB, and that MIB should be defined as part of this work. >4. Each component agent will implement a MIB, >specific to its managed component. I may just be objecting to your choice of words, but I disagree. A component agent may implement a MIB, several MIBs, a smaller subtree of any particular MIB, or it may simply provide management access to a single oid, not necessarily defined in any MIB. What I'm trying to get at is, I don't believe it's a good idea to think of a component agent as implementing entire MIBs, and I certainly don't think it's a good idea make that distinction somehow part of agentx. (That is, I think the unit of registration needs to be much finer than "MIB"). I think it's more realistic to think of component agents as implementing management access to subtrees, or simply oids. As an example, consider gated, which needs to implement the egp and ipRouteTable portions of MIB II. Or perhaps simpler, the multitude of component agents which (as I understand it) each will implement a row of ifTable, but certainly not all of MIB II. >5. The system agent and the component agents will >share an "intra-agent MIB" space used for system >agent <-> component agent (i.e., "intra-agent") >interactions (communications and coordination). >This intra-agent MIB space need not be visible >to management applications (although on a read-only >basis, there may be no harm in seeing it as an >extension of the system agent MIB for this purpose). I don't understand what kind of information would be in this MIB, and exactly how it is different than the system agent MIB. (If we're talking about registration via SNMP sets in a MIB, I would have thought that to be part of the system agent MIB...) >6. Management applications have to "compile in" >knowledge of the system agent MIB and the component >agent MIBs. (How this is done is an implementation >detail outside the scope of agentx.) I don't understand how this is relevant to agentx, but I don't think management applications "have to" do anything :-) Regards, Mike   Delivery-Date: Wed, 03 Jan 1996 14:36:08 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id OAA10841 for X-agentx-local; Wed, 3 Jan 1996 14:36:08 -0800 (PST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id OAA10837 for ; Wed, 3 Jan 1996 14:36:07 -0800 (PST) Received: from flume.zk3.dec.com by mail11.digital.com; (5.65v3.2/1.0/WV) id AA03541; Wed, 3 Jan 1996 17:27:38 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA09711; Wed, 3 Jan 1996 17:27:35 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA04777; Wed, 3 Jan 1996 17:27:58 -0500 Message-Id: <9601032227.AA04777@bernie.zk3.dec.com> To: natale@acec.com (Bob Natale) Cc: agentx@fv.com Subject: Re: Component agent non-interdependency In-Reply-To: Your message of "Mon, 01 Jan 96 15:29:51 EST." <9601012029.AA13980@nips.acec.com> Date: Wed, 03 Jan 96 17:27:58 -0500 From: Mike Daniele X-Mts: smtp Hi Bob, >Likewise, eSNMP allows a second component agent to >register for a subtree within a subtree already >registered by another component agent. Again, this >feature cannot be employed in orderly fashion without >some foreknowledge of the multiple component agent >structure...as the example in eSNMP shows between two >"system level" component agents (os_mibs and gated, if >I recall correctly) provided by the system (OS) vendor. >[Speaking as wg chair...] >It is a fundamental design goal of agentx that >multiple independently developed and procured >component agents can be employed to extend a >user's system agent in an orderly fashion without >any such component agents having any built-in >foreknowledge of each other. >Does anyone disagree with that statement...or >want to refine it? >[Off...] I completely agree with that goal. >Does anyone who agrees with that statement interpret >either or both of the two examples I gave (above) >in a manner which says those features (priorities >and nested external subtree registration) do not >violate it? In the case of eSNMP, it was actually an attempt to achieve the same goal. It seems to me that precisely because component agents have no knowledge of other component agents, there is likely to be registration conflict (or overlap). There is also likely to be downright duplicate registration (I define duplicate to mean EXACTLY the same oid is registered.) How will agentx handle it? Regards, Mike   Delivery-Date: Wed, 03 Jan 1996 16:05:00 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id QAA04748 for X-agentx-local; Wed, 3 Jan 1996 16:04:59 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id QAA04741 for ; Wed, 3 Jan 1996 16:04:58 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA04535 for agentx@fv.com; Wed, 3 Jan 96 19:05:06 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA07992; Wed, 3 Jan 1996 19:03:43 -0500 Date: Wed, 3 Jan 1996 19:06:15 EST From: Bob Natale Subject: Re: MIBs in agentx To: Mike Daniele Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Mike Daniele > Date: Wed, 03 Jan 96 16:58:00 -0500 Hi Mike, > I didn't get a chance to address the first 6 items, > having gotten lost in the furor over #7 :-) Well, I'm glad you've finally gotten around to it! :-) Seriously, I'm running a bit behind in my e-mail trail on agentx (now who's fault could that be? :) (my own, I know!)...and I already owe you one (which I'll eventually do as 2 separate ones) in response to your posting of yesterday wrt #7. I'm getting ready to leave for a long weekend mini-vacation (12th wedding anniversary) and probably won't be in touch after tonight until late Sunday evening. But this posting of yours is a nice platform for some positive replies, so I wanted to be sure to get to it. Still [Speaking as a technical contributor...] > >It seems to me that it might be helpful to have a > >brief discussion about the role(s) of MIBs in the > >extensible agent context. The way that I see this > >issue, it reveals some strong drivers toward some > >refinements of the solution space...I'd like to > >know what different views others hold on this > >general topic or any of the specifics I will mention. > > >1. First of all, one of our goals is that properly > >authorized management applications see a self- > >consistent standard SNMP MIB space at the system > >agent interface encompassing all the management > >objects accessible via the system agent, with no > >particular knowledge of the existence of component > >agents *required* by those management applications. > > Absolutely. > > >2. The "extensible agent" is a virtual agent... > >consisting of the system agent and the collection > >of active component agents at any point in time. > >The extensible agent, per se, does not implement > >a MIB. > > Agreed. > > >3. The system agent is a real agent...it will > >implement a standard system agent MIB. This MIB > >may serve multiple purposes...e.g., enabling the > >management applications to configure the extensible > >agent environment and monitoring information about > >the extensible agent environment. > > Is it correct for me to think of this MIB as similar > to the subAgent MIB that Bert posted to the list? Yes, that is my view. > I agree that the system agent should itself implement a > MIB, and that MIB should be defined as part of this work. Great...we're in sync on that one then. > >4. Each component agent will implement a MIB, > >specific to its managed component. > > I may just be objecting to your choice of words, > but I disagree. Yes, I think we agree (see below). > A component agent may implement a MIB, several MIBs, > a smaller subtree of any particular MIB, or > it may simply provide management access to a single > oid, not necessarily defined in any MIB. Except for what follows the last comma above, I agree. > What I'm trying to get at is, I don't believe it's a > good idea to think of a component agent as implementing > entire MIBs, and I certainly don't think it's a good idea > make that distinction somehow part of agentx. (That is, > I think the unit of registration needs to be much finer > than "MIB"). I think you forcing a volume on to the meaning of "MIB" that, while normally found in practice, is not a necessary aspect of being a "MIB". > I think it's more realistic to think of component agents > as implementing management access to subtrees, or simply oids. I agree entirely (maybe even just "instances"). > As an example, consider gated, which needs to implement the egp > and ipRouteTable portions of MIB II. Or perhaps simpler, the > multitude of component agents which (as I understand it) each will > implement a row of ifTable, but certainly not all of MIB II. No problem. A component agent's MIB file should be no larger than necessary to describe only the objects that it manages in the format that SNMP specifies for MIBs. And and all of your examples above qualify. For argument's sake, take the example of a component agent that only needs to implement a row in ifTable...its MIB file would contain on the defintions required to define that "object"...maybe ifTable, ifEntry, IfEntry, and the elements of IfEntry...assisted by IMPORTS or whatever other standard MIB constructs it needs. > >5. The system agent and the component agents will > >share an "intra-agent MIB" space used for system > >agent <-> component agent (i.e., "intra-agent") > >interactions (communications and coordination). > >This intra-agent MIB space need not be visible > >to management applications (although on a read-only > >basis, there may be no harm in seeing it as an > >extension of the system agent MIB for this purpose). > > I don't understand what kind of information would be in this > MIB, and exactly how it is different than the system agent MIB. > (If we're talking about registration via SNMP sets in a MIB, I > would have thought that to be part of the system agent MIB...) Yes, you are right. And it might be that this "intra-agent MIB" is just a logical construct within the system agent MIB. There are two basic attributes which might differentiate if from the system agent MIB itself: 1. There is no real need for external management applications to see this info; and 2. Some of the objects (as I am construing this scheme) are used by the system agent solely to manage the component agents... e.g., ... well, I was going to give an e.g. about how a system agent might tell a component agent to undo a SetRequest, but I think that might be a bad choice at this time (just before leaving for a mini-vacation!) :-) The "intra-agnet MIB" concept can be dropped in favor of just thinking about it as a special part of the system agent MIB used only for intra-agent communication purposes. On the other hand, if you find that the concept becomes more concrete over time, then you might want a low-cost physical embodiment around it and that can be the "intra- agent MIB". > >6. Management applications have to "compile in" > >knowledge of the system agent MIB and the component > >agent MIBs. (How this is done is an implementation > >detail outside the scope of agentx.) > > I don't understand how this is relevant to agentx, but > I don't think management applications "have to" do anything :-) You're right, literally. This bullet was supposed to be a "no brainer" reflection of common practice in the real world and was, I thought, a logical stepping stone to #7. Thanks for all the helpful, constructive feedback. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Wed, 03 Jan 1996 17:48:17 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id RAA00722 for X-agentx-local; Wed, 3 Jan 1996 17:48:16 -0800 (PST) Received: from pokey.maxm.com (POKEY.MAXM.COM [192.147.28.65]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id RAA00716 for ; Wed, 3 Jan 1996 17:48:15 -0800 (PST) Received: from kirk.maxm.com by pokey.maxm.com (AIX 3.2/UCB 5.64/4.03) id AA17272; Wed, 3 Jan 1996 20:26:39 -0600 Received: by kirk.maxm.com (AIX 3.2/UCB 5.64/4.03) id AA43221; Wed, 3 Jan 1996 20:44:15 -0500 Date: Wed, 3 Jan 1996 20:44:15 -0500 From: jwest@maxm.com (Jim West) Message-Id: <9601040144.AA43221@kirk.maxm.com> To: natale@acec.com Subject: Re: PDUs, proto-ops, and principles Cc: agentx@fv.com Hi Bob, >Date: Wed, 3 Jan 1996 16:21:36 EST >From: Bob Natale >Subject: Re: PDUs, proto-ops, and principles >> 2. My component agent will have access to the complete SNMP >> PDU, so I can get at things such as the community string >> associated with the request. >Correct...although the RequestID could be (and most likely >would be) a system agent determined value, rather than the >originating application PDU's value. I don't see a problem with this. >As a real important sidebar to this one, however, please note >that a big motivator behind my scheme is to avoid access >control issues in the component agents (ergo, the community >string passed...like the RequestID above...*could* be a >system agent specific value used for intra-agent control >purposes). Additional motivation for seeing it this way >is that, ideally (in my view), only the overall extensible >agent gets configured by the "user", not each individual >component agent directly...all community profile info is at >the extensible agent level (which encompasses the system >agent and the component agents). I'm not sure I like this. I agree that we don't want to get into standardizing access control issues in the component agents, but I don't think we want to prohibit it either. If I can't depend on the community string being unmodified by the system agent, then how can I implement multiple logical components within a single component agent. (I think this is the issue of supporting multiple instances of the same MIB on the same machine. I'm not expecting agentx to do this for me, but I don't want agentx taking away functionality that I might use to implement this.) Jim   Delivery-Date: Wed, 03 Jan 1996 22:50:34 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id WAA12052 for X-agentx-local; Wed, 3 Jan 1996 22:50:30 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id WAA12049 for ; Wed, 3 Jan 1996 22:50:25 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA12982 for agentx@fv.com; Thu, 4 Jan 96 01:50:33 -0500 Date: Thu, 4 Jan 1996 01:49:46 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA00931; Thu, 4 Jan 1996 01:49:46 -0500 Message-Id: <9601040649.AA00931@nips.acec.com> To: agentx@fv.com Subject: A contribution wrt the "Problem Space" The following is a very slightly modified excerpt of an off-list exchange I had with a very knowledgeable SNMP activist who cannot, unfortunately, commit to devoting a lot of time and attention to agentx at this time. The opening "> " paragraph is a quote from me to him; all that follows that is his response (verbatim). While I [speaking as wg chair...] don't think that we can successfully follow the game plan that he outlines (given our time constraints and the history of the past attempts down that path) nor that we need to (given our shared knowledge of the problem space), I respect his advice and am not suggesting that we completely forget about such concerns...that would be dumb... just that we attach priority to working from the solution space perspective this time around. I apologize for interjecting this preface...which is probably an inappropriate thing to have done...but I am going to be off-line for a few days (and wanted to get my $.02 in! :-). Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications ------------- > I hope you will monitor our work as best you can and if > *at any point in the process* you feel that a correction > is in order, please let me or the list know. I hope to. While this is a private note, I will convey one concern I have based on what I've seen thus far. I understand the desire/need to bound the discussion so as to produce *something* in a timely manner. However, I'm very concerned about the lack of attention to the "problem space", which in my terminology is the "functional requirements". Without even taking a stab at capturing what the *known/perceived set* of requirements are, there is no way to have a common understanding nor a common agreement on the solution. For example, are the following features "critical", "important", "desirable" or "out-of-scope" with respect the the AgentX deliverables. Further, each feature should also be based upon some real-world, well-founded usage to justify its existance/priority. [note, I'd rate each of these examples with different priorities that span the full range] a) multiple sub-agents instantiating different "rows" of the same "mib table" (within the same naming-scope) e.g., workstation (unix or NT) has multiple 3rd party interface card suppliers, each provides their own sub-agent for their "rows" in the ifTable and what-ever interface specific mib that interface type corresponds to. b) multiple sub-agents instantiating different "columns" of the same "mib table" (w/in the same naming-scope); what about augmented tables? c) different sub-agents providing the instrumentation of the same mib objects instances, but for different name-scopes (and don't forget scalar objects) d) the same sub-agent providing the instrumentation for multiple naming-scopes (i.e., same sub-agent for multiple logical entities). e) independently developed sub-agents interoperate with master-agent on given HW/OS system type. f) establishment of some performance criteria g) inter-agent security measures In close, I'll observe that for each topic that has been discussed on the list, a fairly substantial portion of the bandwidth consumed is spent trying to understand the other person's intentions/needs/objectives... in a word "requirements". Maybe it would be more productive to develop a quick snapshot of requirements via a process such as: 1. brainstorm / braindump "known" requirements 2. assess / evaluate each w.r.t. real-world need 3. prioritize into categories as means to weigh trade-offs Of course, capture each step in a "living" document available via the wg ftp site. Then, most importantly, 4. use this requirements specification to guide discussion and assessment of solution alternatives. When your currently defined "solution space" offers an alternative fine; but if none do, then you might need to look outside the current "solution space"... especially if the requirement is a critical one. And BTW, there is one item in my list above that I believe fall under the latter case; it is (a).   Delivery-Date: Thu, 04 Jan 1996 16:30:25 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id QAA18429 for X-agentx-local; Thu, 4 Jan 1996 16:30:22 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id QAA18404 for ; Thu, 4 Jan 1996 16:30:18 -0800 (PST) Received: by dorothy.peer.com (4.1/SMI-4.1) id AA20291; Thu, 4 Jan 96 16:12:32 PST Date: Thu, 4 Jan 96 16:12:32 PST From: randy@dorothy.peer.com (Randy Presuhn) Message-Id: <9601050012.AA20291@dorothy.peer.com> To: agentx@fv.com Subject: Re: "System Group Roles" Hi - Brian's analysis of "Logical Entities" underscores several concerns to be addressed in the agentx registration and operation protocols: 1) the registration/deregistration protocol must permit the subagent to identify the logical entity owning the information This can currently be accomplished in SMUX and DPI by using multiple associations, implicitly binding a set of associations to a logical entity. This works, but is not at all optimal. 2) the operation (get / set / etc) protocol must permit the operation invoker to specify to the information which logical entity owns the information This can currently be accomplished in SMUX and DPI by using multiple associations, implicitly binding a set of associations to a logical entity. This works, but is not at all optimal. 3) since community strings have overloaded naming and authentication semantics, we need to formally distinguish community strings from logical entity identifiers. (Simple example: there may be two different community strings, "public" and "private", which are both used to access information from a single logical entity, "SanFrancisco-fileserver".) This relationship was more or less explicit in the old party MIB context table (contextLocalEntity). | To: agentx@fv.com | Subject: Re: "System Group Roles" | Date: Tue, 02 Jan 1996 12:39:29 -0700 | From: "Brian O'Keefe" ... | Logical Entity: | . in some cases, the "managed system" is a single physical system | . in other cases, the "managed system" is one of many logical systems | . a logical system is one that could exist on its own as a single | physical system (i.e., a repeater in a single vs stackable hub) | | Agent Implementation Component (sub-agent): | . a single agent can provide access to one or many "managed systems" | . a single managed system (be it logical or physical) may be | instrumented via one or many implementation components | . the same implementation component may be used to instrument a | like-portion of multiple logical systems within the overall system. ... -------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy@peer.com USA --------------------------------------------------------------------------   Delivery-Date: Thu, 04 Jan 1996 18:14:02 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id SAA13825 for X-agentx-local; Thu, 4 Jan 1996 18:14:01 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id SAA13787 for ; Thu, 4 Jan 1996 18:14:00 -0800 (PST) Received: by dorothy.peer.com (4.1/SMI-4.1) id AA22458; Thu, 4 Jan 96 18:13:57 PST Date: Thu, 4 Jan 96 18:13:57 PST From: randy@peer.com (Randy Presuhn) Message-Id: <9601050213.AA22458@dorothy.peer.com> To: agentx@fv.com Subject: Re: "Close" operation Hi - | Date: Wed, 3 Jan 1996 11:21:00 EST | From: Bob Natale | Subject: "Close" operation | To: Dan Romascanu | Cc: agentx@fv.com | | > From: Dan Romascanu | > Date: Wed, 3 Jan 96 14:12:26 -0500 | > Subject: Re: Component agent non-interde ... | > In the cruel physical world where I need to implement | > my projects, cards are extracted from the slots or PSUs | > are down before the logical entitities that run on the | > physical devices have the time to properly 'close' the | > connection. I think we're in agreement that this is a real case, and an important one that must be supported by the agentx solution. | This can happen (obviously) and must be taken into | account, both by the eventual agentx protocol and by | each specific implementation. The default position | wrt the agentx protocol's handling of this as of now | (i.e., based on how the reference protocols do it) | would seem to be that the system agent detects the | loss of connectivity with the component agent based | upon the timeout of a subsequent protocol operation | request directed to that component agent. I'm not sure what you mean by "default". The whole point of having explicit close PDUs as in SMUX is to permit a subagent to inform a master agent that the subagent is going to go away. This can can dramatically reduce the amount of time required to handle a subsequent request for a MIB region that was previously the responsibility of the (deceased) subagent. In hot-standby configurations with high-latency proxies this is a big win. Even (or especially) when the transport happens to be TCP, the use (or lack) of keep-alives at the TCP level may not provide sufficiently timely notification of the loss of an association. In some systems, notification of the loss of a localhost TCP connection is instantaneous. In others, it is painfully slow. This is where having an application-layer keep-alive and close, as is available in DPI and other protocols, can have significant benefits. Ugly? No question. I view both keepalives and close PDUs as ugly but necessary optimizations. If done right, they reduce our dependency on the peculiarities of specific transport mechanisms without significantly increasing overall protocol or implementation complexity. | > That's why periodical 'are you there?' messages (like | > the ones you proposed in one of your earlier mails) | > are required, | | Yes, but as implemented in DPI (for example) the | "Are_You_There" request is sent from the component | agent to the system agent to verify that the system | agent is still running. (In my scheme, this special- | purpose packet would not be needed since a simple | SNMP GetRequest for sysUpTime, for example, from | component agent to system agent would accomplish the | same purpose.) ... I think this is confusing the SERVICE with the PROTOCOL. The scheme BobN is presenting appears to in fact have a keepalive service; it is simply realized using the GET protocol. -------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy@peer.com USA --------------------------------------------------------------------------   Delivery-Date: Thu, 04 Jan 1996 19:05:14 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id TAA23499 for X-agentx-local; Thu, 4 Jan 1996 19:05:13 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id TAA23495 for ; Thu, 4 Jan 1996 19:05:12 -0800 (PST) Received: by dorothy.peer.com (4.1/SMI-4.1) id AA22650; Thu, 4 Jan 96 18:59:14 PST Date: Thu, 4 Jan 96 18:59:14 PST From: randy@dorothy.peer.com (Randy Presuhn) Message-Id: <9601050259.AA22650@dorothy.peer.com> To: agentx@fv.com Subject: Re: Component agent non-interdependency Hi - |Date: Tue, 2 Jan 1996 18:28:49 EST |From: Bob Natale |Subject: Re: Component agent non-interdependency ... |> From: Geoff Carpenter (8-862-1970) |> Date: Tue, 2 Jan 96 12:15:11 EST ... |> 1) reject the duplicate registration. The effect is clearly well- |> understood and easy to implement. |> 2) accept the duplicate registration and allow it to have precedence |> over a prior registration. While slightly more difficult to implement |> than the first case, this would permit run-time patching of faulty |> components. |> 3) allow components to be registered with various priority levels |> and have the agent sort them out. This is a generalization of the |> last-one-in-has-precedence scheme of the second case. ... |Anyone else have an opinion or experience which suggests |one of the other alternatives would be superior? ... (1) is a step backwards. (2) is the minimum needed to handle hot-insertion scenarios. (3) is needed to correctly handle hot-standby configurations. From an implementation perspective, alternative (3) is no more complex to implement than (2). In (2), every "duplicate" registration attempt is treated as a collision, with the collision resolution algorithm treating newcomers as automatic winners. Approach (3) simply admits the possibility that a subagent might be capable of suggesting a non-colliding priority. This does not affect the overall complexity, and allows support of a commercially significant case. -------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy@peer.com USA --------------------------------------------------------------------------   Delivery-Date: Fri, 05 Jan 1996 08:19:05 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id IAA23757 for X-agentx-local; Fri, 5 Jan 1996 08:19:05 -0800 (PST) Received: from gatekeeper.ctron.com (ctron.com [134.141.197.25]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id IAA23718 for ; Fri, 5 Jan 1996 08:19:02 -0800 (PST) Received: (from news@localhost) by gatekeeper.ctron.com (8.6.12/8.6.9) id LAA14918 for ; Fri, 5 Jan 1996 11:19:08 -0500 Received: from stealth.ctron.com(134.141.5.107) by gatekeeper via smap (V1.3mjr) id sma014906; Fri Jan 5 11:19:02 1996 Received: from express.ctron.com by stealth.ctron.com (4.1/SMI-4.1) id AA19936; Fri, 5 Jan 96 11:14:11 EST Received: from gimli.ctron (gimli.ctron.com [134.141.64.24]) by express.ctron.com (8.6.9/8.6.9) with SMTP id LAA11455 for ; Fri, 5 Jan 1996 11:19:00 -0500 From: David Harrington Message-Id: <199601051619.LAA11455@express.ctron.com> Subject: mib registration To: agentx@fv.com Date: Fri, 5 Jan 96 11:18:59 EST X-Mailer: ELM [version 2.3 PL11] Discussion of mib regristration seems to point out the need to support registering at the object level. However, this would be very expensive. Has any consideration been given to using the now-historic context and view mechanisms of snmpv2? If agent X registers subtree a.b.c.d.e and agent Y registers subtree a.b.c.d.e.f, then objects in the "f" branch are represented by agent Y, and objects in the a.b.c.d.e. branch are represented by agent X. The agent-capabilities facility could be used to determine what is, or is not, contained in a given sub-agent implementation. The a-c would need to be imported/read-in/compiled-in by the master agent to "know" what is supported by the sub-agent. If the subagent registers a view family into a intra-agent table, and the a-c capabilities are stored in an intra-agent table, then a subagent can look up what is being supported by another agent already registered. If agent Y does not support a specific subtree that agent X can support, and agent X checks the intra-agent table for this purpose, it can register additional entries into its view to support a.b.c.d.e.f.. Not pretty, but doable. The question of the NMS knowing which subagent supports a paticular object, with recognition of the dynamism of the intra-table, it can look up that data in the intra-agent table itself. If a manager wants to ensure that a given subtree is supported, and can determine that agent X can support it, via the a-c registration, but that agent Y's registration prevents that support from being actualized, the NMS (or for that matter, the master agent) could add the registration to the view table. Of course, it might be desirable to include sometging in the protocol allowing the NMS or master agent to request that the subagent make the registration itself, in case there is an implemntation reason why agent X should not support that subtree withut supporting sibling subtrees. The whole registration process could probably be handled by the master agent if agent-capabilities are adequately machine-readable and can be processed by the master to determine which subagents can support which subtrees, and either gnerates the intra-agent mib itself, or generates registration requetss to the sub-agents who then would register the requested view in the intr-agent table. the subagent starts the process by requesting that the master agent register the subagent's views by importing its agent-capabilties. It would proabbly be useful to include in the protocol a regstration notification - the master agent sends notifiaction to all registered subagents whenever a subagent registers a new view, so the already-regsitered subagents can determinew whether the new registartion affects their view, and they can respond accrodingly. There would need to be rules to prevent race conditions, I suppose. -- ----------------------------------------------------- #include David Harrington dbh@ctron.com Spectrum Network Management Platform Protocols Group Cabletron Systems Inc. -----------------------------------------------------   Delivery-Date: Fri, 05 Jan 1996 10:52:30 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id KAA01873 for X-agentx-local; Fri, 5 Jan 1996 10:52:30 -0800 (PST) Received: from seymour4 (seymour4.snmp.com [192.147.142.4]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id KAA01861 for ; Fri, 5 Jan 1996 10:52:28 -0800 (PST) From: case@snmp.com Received: by seymour4 (5.61++/2.8s-SNMP ) id AA00991; Fri, 5 Jan 96 13:47:38 -0500 Date: Fri, 5 Jan 96 13:47:38 -0500 Message-Id: <9601051847.AA00991@seymour4> To: agentx@fv.com Subject: on overlapping registrations and priorities any technology must have a transition scheme from the technology of the market it hopes to supplant which is to say that if the work output of the agentx effort is to be successful, it needs to be able to support transition from the existing extensible agent technologies since at least two of the existing extensible agent technologies (SMUX and EMANATE) support overlapping registration requests, a similar capability is required in the followon design if we are to be able to build "weird plumbing adapters" to support the installed base ... or ... we have to be willing to abandon the installed base EMANATE supports the priority feature primarily to allow the construction of interfaces to existing smux-based subagents while there are 128ish or 256ish levels of priority possible, in practice i have seen only a couple of levels used, i.e., some, and more, but once n is >= 2, the top limit is pretty irrrelevant, and n is >= 2 a more recent finding is that some users believe overlapping registrations should be "transparent" whereas other overlapping registrations should be "opaque" ... i have not yet found a case where the "opaque" requirement was real but there is always a counterexample ... perhaps this list will come up with one ... then we can decide if it is meaningful ... this, in part was what i perceived to be one of the points of seligson's posting of 2 jan i know there are other messages i need to respond to, but i'm having trouble catching up with the 60+ messages that accumulated while i was away on Christmas travel regards, jdc   Delivery-Date: Fri, 05 Jan 1996 10:54:26 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id KAA02375 for X-agentx-local; Fri, 5 Jan 1996 10:54:26 -0800 (PST) Received: from seymour4 (seymour4.snmp.com [192.147.142.4]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id KAA02367 for ; Fri, 5 Jan 1996 10:54:25 -0800 (PST) From: case@snmp.com Received: by seymour4 (5.61++/2.8s-SNMP ) id AA00996; Fri, 5 Jan 96 13:49:37 -0500 Date: Fri, 5 Jan 96 13:49:37 -0500 Message-Id: <9601051849.AA00996@seymour4> To: agentx@fv.com Subject: Re: PDUs, proto-ops, and principles >Jim West wrote: >> >> In general I like this proposal. Using SNMP as the transfer >> protocol between system agents and component agents will >> satisfy several of my needs. >> To which Mary Quinn followed up: >I assume this implies BER encoding /decoding to be done in the >subagents? Many of the "solution space" implementations pass >varbinds in an alternate form between master/sub agent. Has >anyone done a comparision of the pros/cons of the different >approaches? we studied this carefully when designing emanate and we decided NOT to use ASN.1 BER encoding in any messages between the master agent and the subagent and have been delighted with this design choice regards, jdc   Delivery-Date: Fri, 05 Jan 1996 13:22:03 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id NAA09080 for X-agentx-local; Fri, 5 Jan 1996 13:22:01 -0800 (PST) Received: from inetgw.fsc.ibm.com (inetgw.lfs.loral.com [204.177.125.1]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id NAA09076 for ; Fri, 5 Jan 1996 13:21:52 -0800 (PST) Received: by inetgw.fsc.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA28347; Fri, 5 Jan 1996 16:21:59 -0500 Received: from bldfln1.fs.boulder.ibm.com(9.99.33.11) by inetgw.fsc.ibm.com via smap (V1.3) id sma034228; Fri Jan 5 16:21:40 1996 Received: by bldfln1.fs.boulder.ibm.com (IBM OS/2 SENDMAIL VERSION 1.3.2)/1.0) id AA0533; Fri, 05 Jan 96 14:16:37 -0500 Message-Id: <9601051916.AA0533@bldfln1.fs.boulder.ibm.com> Received: from lfsbld with "Lotus Notes Mail Gateway for SMTP" id 5258A8C1B93B4D20872562A8007096CD; Fri, 5 Jan 96 14:16:36 To: "agentx%fv.com" From: Carl Kugler/lfsbld Date: 5 Jan 96 14:15:40 Subject: on overlapping registrations and priorities Mime-Version: 1.0 Content-Type: Text/Plain Let's get object-oriented here for a minute. Part of what we're discussing here is different ways of assembling an aggregate object (the extensible system agent) from a collection of objects (the core agent and multiple component agents). The two most common ways of going about this in the OO world are "inheritance" and "composition". The approach of allowing a second component agent to register for a subtree within a subtree already registered by another component agent could be considered a form of inheritance. The second component agent inherits all the operations of the previously registered component agent, and overrides and extends them to tailor its behavior. Requiring non-overlapping registrations, at well-defined points, of independent component agents could be called composition. If you're still with me, then at this point I think you can apply many of the standard arguments regarding the relative merits of inheritence vs. compostion. For example, inheritance makes it easier to modify an existing implementation for reuse. Typically designs based on inheritance require fewer objects than designs based on composition. However, "inheritance breaks encapsulation", and changes in the parent might force changes in the inheritor. Favoring composition over inheritence helps you keep each class encapsulated and focused on one task, and allows each component to be free of dependencies on other components. Carl Kugler carlk@lfs.loral.com   Delivery-Date: Fri, 05 Jan 1996 19:56:58 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id TAA16498 for X-agentx-local; Fri, 5 Jan 1996 19:56:57 -0800 (PST) Received: from europe.std.com (europe.std.com [192.74.137.10]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id TAA16486 for ; Fri, 5 Jan 1996 19:56:54 -0800 (PST) Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id WAA02169; Fri, 5 Jan 1996 22:57:02 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA17159; Fri, 5 Jan 1996 22:53:42 -0500 From: ralex@world.std.com (Aleksey Y Romanov) Message-Id: <199601060353.AA17159@world.std.com> Subject: OAA 0.5 To: agentx@fv.com Date: Fri, 5 Jan 1996 22:53:41 -0500 (EST) X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, Next revision of OAA is available as ftp://ftp.std.com/vendors/snmp/snmp95/oaa5.txt New things are 1. It is 30% smaller 2. (Hopefully) it is easier to both understand and implement 3. It does not have dependencies to particular admin model being used. Aleksey P.S. It is not prohibitvely big to be posted, so I am attaching to this mail =============================================================== The Open SNMP Agent The Interface for Programming the Extensible SNMP V1/V2 Agent Version 0.5 11 October 1995 Aleksey Y. Romanov Paul Freeman Associates, Inc. William H. White Westford Systems, Inc. Pete Wilson Paul Freeman Associates, Inc. Copyright (c) 1993-1996 by Paul Freeman Associates, Inc. 14 Pleasant Street P. O. Box 2067 Westford, Massachusetts 01886-5067 All Rights Reserved This document may be freely distributed in any form whatever, including the form of computer-readable electronic medium, provided that it is distributed intact and in its entirety and that the copyright and this notice are included. Authors' Contact Information Aleksey Romanov ralex@world.std.com William H. White bhwhite@wsi.ultranet.com Pete Wilson pwilson@world.std.com 1 INTRODUCTION 1.1 Identification 1.2 Trademarks 1.3 Background 1.4 Goals of This Paper 1.5 Non-Goals of This Paper 1.6 What is the Open Agent? 1.7 Naming Conventions 2 OVERVIEW OF THE CORE-AGENT-TO-MIB-SERVER INTERFACE 2.1 Major Components 2.2 Program Flow 3 ERROR CODES AND PSEUDO-TYPES 3.1 Intermediate Error Codes 3.2 Error Processing and Reporting 3.3 Set Primitive 3.4 SNMPv1 DO_COMMIT 3.5 SNMPv2 DO_COMMIT/UNDO_COMMIT 4 FUNCTION-CALL INTERFACES FOR LOADABLE MIB SERVERS 4.1 Basic Structures 4.2 Function Definitions 5 OTHER ISSUES 5.1 Common Services 5.2. Dynamic mounting 6 REFERENCES APPENDIX A Implementation 1 INTRODUCTION 1.1 Identification This paper is the Open Agent description, version 0.5. It describes the rules for the implementation of dynamically- extensible, interoperable, vendor-neutral SNMP agent software that observes the rules of the SNMP Version 1 and Version 2 and that operates under a variety of operating systems, including Unix and Unix variants; MS-DOS; and real-time systems. Because the Microsoft MS-Windows family of operating systems presents unique issues for the designer and implementor, the Open Agent for Windows (WinSNMP/Agent) is described in a separate, companion paper [Romanov et. al.]. 1.2 Trademarks Microsoft, MS, and MS-DOS are are registered trademarks; and Windows is a trademark of Microsoft Corporation. Open Agent Architecture and The Universal SNMP v1+v2 Agent are trademarks of Paul Freeman Associates, Inc. Univel is a trademark of Univel. UNIX is a registered trademark; and UnixWare is a trademark of UNIX Systems Laboratories, Inc., a wholly-owned subsidiary of Novell, Inc. 1.3 Background The architecture described in this paper is the Open Agent Architecture developed as part of the Universal SNMP v1+v2 Agent by Paul Freeman Associates, Inc., which makes the technology available to any agent standards effort. Paul Freeman Associates, Inc., is the developer of the Universal SNMP v1+v2 Agent (tm), a commercial implementation of the agent part of the SNMP. In order to advance the state of the network- management art, PFA is making available to any public agent standards effort the part of its Agent which realizes the interface between the core part of its Agent and any MIB implementation. It is this interface which enables independent third-party MIBs to operate correctly with the PFA core Agent. The PFA interface is referred to below as the "Interface." The impetus for the revelation of this trade-secret material is the ongoing call in the network-management for open, standard SNMP components for operation under many operating systems. Because the Interface has proven useful and complete in many environments, PFA offers it as an interface for any emergent SNMP agent standard. 1.4 Goals of This Paper 1.4.1 The paper describes a robust, powerful, and understandable framework for the implementation of dynamically-extensible, interoperable, vendor-neutral SNMP bilingual agents. 1.4.2 The paper defines a standard but flexible interface between a core agent and its MIB-server modules and thereby supports the independent development of core agents and MIB servers. 1.4.3 The paper encourages the development of interoperable agent components by different vendors so as to allow the dynamic selection of core-agent and MIB-server configurations by the end user from a set of fully interoperable core-agent and MIB-server components. 1.4.4 The paper describes standardized elements which are focused enough to permit the creation of a broad range of product- specific, value-added agents by conforming yet competing vendors, but proposes no further implementation policy. 1.5 Non-Goals of This Paper 1.5.1 The paper sets no implementation policy, but only presents an implementation framework. 1.5.2 The paper is silent on issues of correct and compliant SNMP-agent development. 1.5.3 The paper proposes no communications scheme or transport layer of any kind, except to say by implication that some (conceptual) transport layer is present. The choice of transport layer and its realization is entirely the province of each agent implementor. 1.6 What is the Open Agent? The Open Agent is an extensible SNMPv1- and SNMPv2-compliant agent that can run under any operating system. This paper describes a model for implementing the extensible agent. This model strictly partitions the agent into three parts: -- a protocol-specific part, called the "core agent"; -- one or more MIB-specific parts, called "MIB servers"; and -- the interface between the two, called the "core-agent-to-MIB- server interface" or, more often and more simply, the "interface" or the "API." 1.6.1 Core Agent A core agent is an application that binds to a transport service for receiving or sending SNMP packets and for processing the SNMP v1/v2 PDU header. The core agent never accesses any MIB variables directly, but relies completely upon one or more MIB servers to perform MIB-variable accesses. The core agent completely manages SNMP-packet processing: -- it receives the SNMP request packet from the communications stack. -- it verifies the packet's authenticity, privacy, and context. -- it locates the appropriate MIB server for each variable in the packet. -- it passes each variable binding and protocol operation, in turn, to the appropriate MIB server. -- it manages the synchronization of multiple-phase (SET) and multiple-MIB-server (GETNEXT, GETBULK and SET) processing. -- it receives the result of each protocol operation for each variable binding from the MIB server and, when appropriate, encodes the result in an SNMP response packet. -- it returns the complete response packet to the communications stack for delivery to the NMS. The core agent also provides a number of service primitives for general use including, among possibly many others: -- trap sending. -- BER parsing. -- oid comparison. -- common RowStatus service. -- view evaluation. -- event logging. 1.6.2 Open Agent MIB Server A MIB server is a linkable object module that provides access to MIB variables at the request of and on behalf of the core agent. A MIB server implements all of the functions necessary to carry out all of the variable-access operations requested in any SNMP packet for one or more variables. A MIB server may operate on part of a MIB; on a complete MIB; or on multiple MIBs. The MIB variables under the purview of a MIB server are said to comprise that MIB server's "namespace." A MIB server is bound to a core agent in either of two ways: The MIB server can be a dynamically-linkable (loadable) object module which can be loaded, linked with the core agent, and then unloaded at run time. A MIB server bound in this way is said to be "loadable." This paper deals exclusively with dynamically-linkable MIB servers. The MIB server can exist as a process separate from the core agent. Such a MIB server communicates with the core agent using IPC mechanisms like shared memory and messages and is said to be "external." This paper is silent on issues of external MIB servers. External MIB servers are treated elsewhere. For example: -- External MIB servers under the MS-Windows family of operating systems, and their interactions with the core agent, are described in the WinSNMP/Agent proposal [Romanov et. al.]. -- Sub-agents which communicate with the core agent via the Distributed Protocol Interface are treated in RFC 1592 [Wijnen et. al.]. 1.6.3 Core-Agent-to-MIB-Server Interface The core-agent-to-MIB-server interface consists of four primitive types: -- an initialization primitive that lets each MIB server initialize its namespaces; -- variable-access primitives, including primitives that support GET and SET operations; -- synchronization primitives that tells a MIB server when packet processing is starting or is complete; and -- general housekeeping primitive for timekeeping. This paper describes an arrangement of primitives which the core agent accesses through direct function calls, which is the scheme used for loadable MIB servers in the Open Agent. +----------+ +-------+ +-----+ +--------+ | Request | | | | +--Call->| MIB | +-->| Packet +->| | Requests | |<- Ret -+ Server | | | from NMS | | +-- with ->| | +--------+ | +----------+ | | Varbinds | | +--+-------------+ | | | | +--------+ | Communications | | Core | | I/F +- Call->| MIB | | Layer | | Agent | | |<- Ret -+ Server | +----------------+ | | | | +--------+ A +----------+ | |<-Results-+ | | | Response | | | | | +--------+ +---+ Packet |<-+ | | +- Call->| MIB | | for NMS | | | | |<- Ret -+ Server | +----------+ +-------+ +-----+ +--------+ Figure 1.1 Control and data flow through some communications layer, the Core Agent, the Interface, and the MIB Server(s). 1.7 Naming Conventions This section aims precisely to define terms which are local to this paper. 1.7.1 Mib Each namespace (see just below) is represented to the core agent by one structure, called "mib" in this paper. There is a linked list of such mib structures, and each structure holds the complete definitions of: -- the single namespace under the control of the corresponding MIB server; and -- all MIB-server-resident primitives which operate on that namespace. The core agent views all MIB servers mounted at any moment as a set of mib entries. The core agent has no interest in the ways in which namespace access might be implemented within any MIB server. 1.7.2 Namespace A namespace, equivalent to a range of MIB variables, is an ordered and contiguous set of variable instances accessible to one and only one MIB server. The set is characterized, defined, and bounded by a common OID prefix, time domain and an entity name. For the purpose of this paper we will call the combination of time domain with entity name a context. 1.7.3 Primitives Each MIB server implements six callable functions, termed "primitives," which operate on its namespaces. No primitive may operate on the namespace of any other MIB server. The MIB-server namespace primitives are: -- init() Initialize (one time) namespace. -- cycle_begin() Let the MIB server know packet processing is starting. -- cycle_end() Let the MIB server know packet processing is finished. -- look() Process GETs and phase one of SETs in the namespace. -- set() Process phase two of SETs in the namespace. -- tick() Keep track of elapsed time. There is no connection between the name of the primitive and the name of the function implementing the primitive operation. We use primitive names as function names in order to avoid another level of indirection. For a loadable MIB server, the core agent calls the primitives using the function pointers associated with the namespace. These function pointers are stored in the namespace's mib structure. 2 OVERVIEW OF THE CORE-AGENT-TO-MIB-SERVER INTERFACE This section is a brief, high-level overview of the "what" and "why" of the interface. A formal, detailed description of each interface component (the "how") appears later. 2.1 Major Components The main part of the interface is a set of five primitives: init(), cycle_begin(), cycle_end(), look(), set(), and tick(). Each MIB server must offer at least the look() primiteve. 2.1.1 Init Function The init function for each namespace is called only once, and before any other MIB-server functions are called, to allow the MIB server to initialize itself and the namespaces it supports. 2.1.2 Cycle_Begin and Cycle_End Functions The cycle_begin function is called before calling any other mib primitives involved in processing the current received packet; and cycle_end is called after all varbinds in the request packet have been dealt with and the core agent is ready to return a response packet to the communications layer. The purpose of these functions is to allow the MIB server to allocate and free resources synchronously with packet processing. For example, the MIB server might allocate temporary resources or locks at cycle_begin time and release them at cycle_end time. The call also conveys information which is not going to change during the current packet processing: the version of this current request (SNMPv1 or SNMPv2), the type of operation performed, the index of the current view, and temporal domain. 2.1.3 Look Function The MIB server's look function must perform the search and access validation for the requested name. The details of the operations performed depend upon the pdu type being processed For the get (GetRequest pdu), the core agent supplies the name of the variable instance to find. The MIB server needs to find this variable instance, check access rights, possibly copy this variable into some temporary area, pass back its type and length (both unencoded) and a pointer to the variable, and return success or the appropriate error code. The next (Get-Next or Get-Bulk pdu) transaction performs similarly, except that the name of the found variable is also returned. The write (Set pdu) transaction differs substantially from the two get transactions. In a write transaction, the core agent delivers the name of the variable to be set, its BER encoded value, and the type and length of the value. The MIB server then must find this variable instance, check access rights, check the value, the type, and and the length provided; and then must store this value into shadow memory, along with all the information needed for a successful later low-level set operation. If any error is found, the MIB server returns the appropriate error code. 2.1.4 Set Function The core agent marks each namespace that has successfully completed its look primitive. Once the look primitive has been successfully performed for all varbinds in the current packet, the core agent calls set(DO_PHASE1) for each marked MIB server. The MIB server now has the chance to verify the consistency of all variable instances and/or all other variables in the server's namespaces (new values for all variables being known at this point), and/or all other conditions, having made all arrangements necessary to insure a successful later commit. The MIB server returns an indication of success or the appropriate error code. In case of error, the core agent, remembering the error code and the index, calls set(UNDO_PHASE1) for each marked namespace which is already processed (including one which indicated error condition) in the reverse order. The MIB server must undo all reservations made during the previous set(DO_PHASE1,...) calls. If all calls to set(DO_PHASE1,...) are successfully performed, the core agent calls set(DO_COMMIT) for all marked namespaces. If a set(DO_COMMIT,...) fails, the core agent calls set(UNDO_COMMIT) for each already committed namespace, including one which indicated error in reverse order, then it calls set(UNDO_PHASE1) for all marked MIB servers in reverse order. If all calls to set(DO_COMMIT, ...) are successfully performed, the core agent calls set(DO_RELEASE, ...) for all marked MIB servers in reverse order. 2.1.5 Tick Function The tick function is called between packets every 10-15 seconds in order to allow MIB servers to perform any time related functions: clean up old notInService rows, initiate trap sending, etc. 2.2 Program Flow This section gives an overview of the program flows of a simple, straightforward conceptual core agent and a cooperating MIB server. For clarity and simplicity, this description omits error handling. 2.2.1 Initialization Core Agent MIB server -------------------------------------- ------------ for(all loadable MIB servers){ add MIB server to MIB-server list; for(all MIB-server name spaces){ for(all contexts supported){ add mib to the list; } } } for(all mibs known){ mib->mib_init(); -----> reset to known state, } according to init parameters; return local multiplexor value 2.2.2 GetRequest Processing ... for(all mibs for particular context){ mark mib as not referenced; } ... for(each requested varbind) check access rights to variable; find first and last mib entries to search; for( mib=first; mib!=last; mib=mib->mib_next ){ if(not referenced yet){ mib->mib_cycle_begin() -----> perform all operations mark as referenced required to start packet } processing } mib->mib_look() ----------> look for variable instance, pass value back add result to output packet; } for(all mibs for particular cotext){ if(not referenced){ continue; } mib->mib_cycle_end() -----------> perform all operations } required to end packet processing build response packet and return packet pointer to the communications layer return noError 2.2.3 SetRequest Processing ... for(all mibs for particular context){ mark mib as not referenced; make mib as no-set-look-perfomed; } ... for(each requested varbind) check access rights to variable; find first and last mib entries to search; for( mib=first; mib!=last; mib=mib->mib_next ){ if(not referenced yet){ mib->mib_cycle_begin() ---------> perform all operations mark as referenced; required to start packet } mib->mib_look() ----------> look for variable instance, mark mib as set-look-performed check value, store it in } shadow memory } for(all mibs with set-look perofrmed mark){ mib->mib_set(DO_PHASE1) --> check consistency, reserve } resources for(all mibs with set-look perofrmed mark){ mib->mib_set(DO_COMMIT) --> perform commit } for(all mibs with set-look perofrmed mark in rev order){ mib->mib_set(DO_RELEASE) --> release locks } for(all mibs for particular context){ if(not referenced){ continue; } mib->mib_cycle_end() -----------> perform all operations } required to end packet processing build response packet and return a packet pointer to the communications layer 3 ERROR CODES AND PSEUDO-TYPES The Open Agent architecture defines a consistent set of intermediate error codes used throughout the agent. Below is the description of the error-codes applicable to the core-agent-to- MIB-server interface. The Open Agent architecture uses an extended set of types internally. This set of types includes the base set of types defined by SMI and pseudo-types. The pseudo-type is a subtype of the base type which requires additional processing from the core agent. There is just a single pseudo-type defined currently: UINT32V1. There are some SNMPv1 mibs which use objects of type INTEGER (xxx...4294967295). The value of this type must be encoded in 5 bytes if it is greater than or equal to 0x80000000. UINT32V1, defined as (0x100 | INTEGER), gives the core agent the information required for appropriate encoding in this specific case. Extended-type encoding is straightforward: the SMI type is encoded in byte 0 (LSB) of the extended type, and byte 1 is used to provide the core agent with additional information. If byte 1 is 0 then this is a basic SMI type, otherwise it is a pseudo- type. See section 4.2.3 for precise descriptions of where and how extended types are used. If some undefined extended type is given to core agent it will generate genErr. The core agent does not perform any conversions of SNMPv2 SMI types to SNMPv1 SMI types. It is the responsibility of the MIB server to use types in accordance with the version of the request packet being processed. 3.1 Intermediate Error Codes: Core-Agent-to-MIB-Server Interface. These codes are used by the MIB-server to indicate the particular error condition associated with the primitive operation being executed. Generally, the set of intermediate error codes is wider than the base set of error codes defined by the SNMPv2 protocol operations document. Additional error codes are used by MIB server to specify internal errors in a version-independent manner; these codes are then converted to the appropriate base error codes by the core agent. SNMPv2 makes use of type exceptions to desginate 'noSuchObject' 'noSuchInstance' and 'endOfMibView' conditions. The MIB server must report these coditions as internal codes LOC_ERR_NOSUCHOBJECT or LOC_ERR_NOSUCHINSTANCE. LOC_ERR_INTL -- the core agent performs cycle_end() primitive for all namespaces already touched in the current packet processing and drops processing of the request without any other action. LOC_ERR_DATA -- The size of data area provided for result of parsing of integer value has to be 4, otherwise this error will be generated by set_variable(). LOC_ERR_NOERROR -- same as SNMPv2 noError LOC_ERR_GENERR -- same as SNMPv2 genErr LOC_ERR_WRONGTYPE -- same as SNMPv2 wrongType LOC_ERR_WRONGLENGTH -- same as SNMPv2 wrongLength LOC_ERR_WRONGENCODING -- same as SNMPv2 wrongEncoding LOC_ERR_WRONGVALUE -- same as SNMPv2 wrongValue LOC_ERR_NOCREATION -- same as SNMPv2 noCreation LOC_ERR_INCONSISTENTVALUE -- same as SNMPv2 inconsistentValue LOC_ERR_RESOURCEUNAVAILABLE -- same as SNMPv2 resourceUnvailable LOC_ERR_NOTWRITABLE -- same as SNMPv2 notWritable LOC_ERR_INCONSISTENTNAME -- same as SNMPv2 inconsistentName LOC_ERR_NOCREATION -- same as SNMPv2 noCreation LOC_ERR_NOSUCHOBJECT -- used to indecate 'noSuchObject' exception for Get processing, and 'endOfMIBView' exception for GetNext and GetBulk. In case of SET request processing this value can be used instead of LOC_ERR_NOTWRITABLE. This value HAS to be used instead of LOC_ERR_NOTWRITABLE when overalapped namespaces are supported and requested variable does not have matching object contained in the namespace. LOC_ERR_NOSUCHINSTANCE -- used to indicate 'noSuchInstance' exception for Get processing; and 'endOfMIBView' exception for GetNext and GetBulk. In the case of SET request processing this value is equivalent of LOC_ERR_NOCREATION There are some other intermediate error codes used by the core agent and listed here for information purposes only: LOC_ERR_PARSE, LOC_ERR_TOOBIG, LOC_ERR_NOACCESS, LOC_ERR_COMMITFAILED, LOC_ERR_UNDOFAILED, LOC_ERR_AUTHORIZATIONERROR. In addition, the core agent has further uses and reason for LOC_ERR_DATA. 3.2 Error Processing and Reporting Any error not listed below for particular case is unexpected. For example, the error value 1002345 is an unexpected one for any case, and the error LOC_ERR_BADVALUE is an unexpected one for SNMPv1 GetRequest. Unexpected error codes returned for a particular environment are translated into genErr by the core agent. The next subsections of this section will describe error translation performed by core agent for each environment. 3.2.1 Look Primitive 3.2.1.1 SNMPv2 GetRequest LOC_ERR_INTL see explanation in 3.1. LOC_ERR_NOERROR -> noError, core agent creates a varbind using returned type and value in the output packet LOC_ERR_GENERR -> genErr LOC_ERR_NOSUCHOBJECT -> noError, core agent will create a varbind with value noSuchObject in the output packet LOC_ERR_NOSUCHINSTANCE -> noError, core agent will create a varbind with value noSuchInstance in the output packet 3.2.1.2 SNMPv2 GetNextRequest and GetBulkRequest LOC_ERR_INTL see explanation in 3.1. LOC_ERR_NOERROR -> noError, core agent will create a varbind using returned type and value in the output packet LOC_ERR_GENERR -> genErr LOC_ERR_NOSUCHOBJECT -> (a) If there are namespaces left unprocessed, LOC_ERR_NOSUCHINSTANCE the core agent will continue search in the next namespaces, otherwise (b) noError, core agent will create a varbind with value endOfMibView in the output packet 3.2.1.3 SNMPv2 SetRequest LOC_ERR_INTL see explanation in 3.1. LOC_ERR_DATA -> genErr LOC_ERR_NOERROR -> noError LOC_ERR_GENERR -> genErr LOC_ERR_WRONGTYPE -> wrongType LOC_ERR_WRONGLENGTH -> wrongLength LOC_ERR_WRONGENCODING -> wrongEncoding LOC_ERR_WRONGVALUE -> wrongValue LOC_ERR_NOCREATION -> noCreation LOC_ERR_INCONSISTENTVALUE -> inconsistentValue LOC_ERR_RESOURCEUNAVAILABLE -> resourceUnvailable LOC_ERR_NOTWRITABLE -> notWritable LOC_ERR_INCONSISTENTNAME -> inconsistentName LOC_ERR_NOSUCHOBJECT -> notWritable LOC_ERR_NOSUCHINSTANCE -> noCreation LOC_ERR_NOCREATION 3.2.1.4 SNMPv1 GetRequest and GetNextRequest LOC_ERR_INTL see explanation in 3.1. LOC_ERR_NOERROR -> noError, core agent will create a varbind using returned type and value in the output packet LOC_ERR_GENERR -> genErr LOC_ERR_NOSUCHOBJECT -> noSuchName LOC_ERR_NOSUCHINSTANCE 3.2.1.5 SNMPv1 SetRequest LOC_ERR_INTL see explanation in 3.1. LOC_ERR_DATA -> genErr LOC_ERR_NOERROR -> noError LOC_ERR_GENERR -> genErr LOC_ERR_WRONGTYPE -> badValue LOC_ERR_WRONGLENGTH LOC_ERR_WRONGVALUE LOC_ERR_INCONSISTENTVALUE LOC_ERR_WRONGENCODING -> the core agent discards the packet, update snmpInASNParseErrors counter LOC_ERR_RESOURCEUNAVAILABLE -> genErr LOC_ERR_NOCREATION -> noSuchName LOC_ERR_NOTWRITABLE LOC_ERR_INCONSISTENTNAME LOC_ERR_NOSUCHOBJECT LOC_ERR_NOSUCHINSTANCE 3.3 Set Primitive 3.3.1 DO_PHASE1 The same set of rules is applicable here as in case of the look primitive in the same environment. 3.3.2 UNDO_PHASE1 The return value and index value are ignored. 3.3.3 SNMPv1 DO_COMMIT The same set of rules is applicable here as in case of the look primitive in the SNMPv1 SetRequest environment. 3.4 SNMPv1 UNDO_COMMIT The return value and index value are ignored. 3.5 SNMPv2 DO_COMMIT/UNDO_COMMIT The same set of rules is applicable here as in case of look primitive in the SNMPv2 SetRequest environment, if all DO_COMMIT calls return LOC_ERR_NOERROR. Otherwise the core agent stores the index passed back by failed set(DO_COMMIT). If all subsequent UNDO_COMMIT calls return LOC_ERR_NOERROR, then the core agent generates 'commitFailed' and error-index is set equal to the stored index value. Otherwise the core agent generates 'undoFailed' with error-index 0. 3.6. DO_RELEASE The return value and index value are ignored. 4 FUNCTION-CALL INTERFACES FOR LOADABLE MIB SERVERS This section describes the basic structures and primitives used in the core-agent-to-MIB-server interface when the MIB server is implemented as a loadable MIB server. 4.1 Basic Structures 4.1.1 The CYCLE_MIB The CYCLE_MIB structure contains information about the current cycle being performed. It is passed to all primitives as the first argument. Primary usage of this structure is to pass information about current packet/PDU being processed, its admin model, entity, time domain, security information, etc. This feature allso allows multithreaded SNMP agent implementations in the OAA framework. In this case CYCLE_MIB should be extended with current thread information. In a single-threaded environment, the MIB server should not change this information. struct cycle_mibsrv { UINT32 cm_admin_model; union adm_un { void *pt; UINT32 hand; } cm_admin_un; INT32 cm_tdomain; UINT8 *cm_entity; INT32 cm_entity_len; INT32 cm_pdutype; UINT32 cm_id; }; #define cm_admin_pt cm_admin_un.pt #define cm_admin_hand cm_admin_un.hand typedef struct cycle_mibsrv CYCLE_MIB; where - cm_admin_model -- ID of the current admin model being used, except that SNMPv1 admin model SNMPV1 uses SNMPv1 protocol operations; all others use SNMPv2 protocol operations. cm_admin_un -- information specific for admin model (e.g. view_index, pointer to community etc). Each admin model can use this area for whatever purpose seems suitable to admin model designer. cm_tdomain -- time domain: CURRENTTIME or RESTARTIME. cm_entity -- current local entity. cm_entitty_len -- its length. cm_pdutype -- the type of PDU being processed, set to 0 before the tick primitive is called. cm_id -- cycle-id, the non-zero 32-bit unsigned value associated with packet being processed (see below). 4.2 Function Definitions The formal definitions of all core-agent-to-MIB-server primitives are given below with reference to a fictitious example namespace called the "abc" namespace. The agent calls the functions by reference to a pointer in the MIB server's mib structure, so the "name" is that of the pointer, not the MIB server's actual function name. As we said above, the actual name of the function is a matter of choice for MIB server designer. We called tham abc_xxxx just to logically link the primitive and namespace. The first argument to each primitive function call (except init()) is a pointer to a CYCLE_MIB structure containing information about the current PDU being processed. The final argument to each primitive function (except init()) is the multiplexor: the value returned by init() primitive for the current namespace. 4.2.1 Init Primitive Function Called by the core agent at the time the MIB server is mounted and before any other primitives are called. Syntax: UINT32 abc_init( UINT32 time_domain, UINT8 *entity, INT32 entity_len, OID *sub_tree, INT32 sub_tree_len ); where - time_domain -- CURRENTTIME or RESTARTTIME entity -- local entity entity -- its length sub_tree -- sub tree namespace is mounted under sub_tree_len -- its length Returns: (UINT32) 0 on failure and some (UINT32) non-zero value on success. The core agent stores this returned value in for later reference and passes it as last parameter to all primtives except init(). If the MIB server returns zero, then this namespace is marked inactive and won't be referenced again. The return value is otherwise not interpreted in any way by the core agent. Description: The core agent issues init at the time the MIB server is mounted and before any other primitives are called. 4.2.2 Cycle_Begin and Cycle_End Functions Called by the core agent for each namespace to indicate the start and end of processing for each received request packet. Syntax: INT32 abc_cycle_begin(CYCLE_MIB *cm, UINT32 mx); INT32 abc_cycle_end(CYCLE_MIB *cm, UINT32 mx); cm -- pointer to current cycle_info mx -- multiplexor value Returns: cycle_xxx returns (INT32) 0 on failure and (INT32) 1 on success. If cycle_xxxx returns failure, then the core agent disables the MIB server, in all its instantiations in mib, and (if applicable) unloads the MIB server. If cycle_begin returns 0, then the core agent responds with error-status genError and error-index pointing to the first variable in a packet which has to be looked for in the mibs's name space. If cycle_end returns 0, it does not affect the result of current packet processing, however in both cases core agent disables the MIB server and releases its namespace. Description: The core agent invokes the MIB server's cycle_begin function for each namespace when a request packet is delivered from the communications layer, and before any other MIB-server functions are invoked for that namespace and packet; and it calls cycle_end when all the varbinds in that packet for each namespace have been processed and no further MIB-server functions will be called for that packet. The functions intend to let each MIB server synchronize on the arrival of packets and the end of packet processing. Recall that there may be several namespaces represented by a single MIB server and therefore several instantions of that MIB server in mib table. What happens in this case? Imagine a MIB server which represents two namespaces and which therefore has two entries in mib: "abc_A" and "abc_B." Suppose further that the order of variables in a GetRequest pdu is as: abc_A_1, abc_A_2, abc_B_1, abc_A_3, abc_B_2 Processing proceeds as: abc_A_cycle_begin() -- server is told of a new packet referencing the abc_A namespace. abc_A_look(abc_A_1) -- process GetRequest of abc_A_1; abc_A_cycle_begin is guaranteed to be invoked before abc_A_look(). abc_A_look(abc_A_2) -- process GetRequest of abc_A_2. abc_B_cycle_begin() -- core agent finds a reference to the abc_B namespace, again tells server of this packet. abc_B_look(abc_B_1) -- process GetRequest of abc_B_1; again, abc_B_cycle_begin is guaranteed to be invoked before abc_B_look(). abc_A_look(abc_A_3) abc_B_look(abc_B_2) abc_B_cycle_end() -- the order of invocations to abc_A_cycle_end() abc_X_cycle_end is unpredictable, but it is guaranteed that there will be no call to abc_X_look() after any call to abc_X_cycle_end() for any namespace. In order to distinguish the very first call (and the very beginning of the packet processing) cm->cm_id is used. This is a 32-bit unsigned value which is never 0. The value is incremented for every packet processed, and wraps and skips 0 in the process. So, the MIB-server can detect the very beginning of the packet. The same value used by core-agent to detect packets delivered after timeout. 4.2.3 Look Primitive Function Invoked for all MIB-access operations. Syntax: INT32 abc_look( CYCLE_MIB *cm OID *name, INT32 *namelen, INT32 index, UINT8 **pval, UINT32 *type, INT32 *len, UINT32 mx ); Get Transaction: cm -- current PDU information name -- requested name namelen -- pointer to its length index -- of current variable (ignored) pval -- *pval points to unencoded value upon return type -- *type contains extended type of variable found upon return len -- *len contains length of variable value upon return mx -- multiplexor - value returned by init() primitive for this namespace Next Transaction: cm -- current PDU information name -- requested name upon return contains the found name namelen -- pointer to its length index -- of current variable (ignored) pval -- *pval points to unencoded value on return type -- *type contain extended type of variable found len -- *len contains length of variable value mx -- multiplexor - value returned by init() primitive for this namespace Write Transaction: cm -- current PDU information name -- name of variable namelen -- pointer to its length index -- of current variable, can be stored for following use pval -- *pval points to BER encoded value type -- type points to the ASN type of value len -- len points to the asn_length of value mx -- multiplexor - value returned by init() primitive for this namespace Returns: The value returned by look() is either LOC_ERR_NOERROR for success or some error code from Section 3. If this return value is an error code, then the core agent discards the other values passed back by the MIB server. Description: The look function is invoked for all MIB-access operations: GetRequest, GetNextRequest, GetBulkRequest, and SetRequest. The MIB server must support instance-level granularity while calculating access rights for a particular name in all cases. Note for SET request processing: 1. At the time abc_look is called, the core agent has already checked for valid tag and length encodings and no message overflow. 2. The SMI type is used here, not an extended type. It is the responsibility of the MIB-server designer to provide appropriate handling for the case if pseudo-type is used by variables of this MIB-server. 4.2.4 Set Primitive Function Used to set variables. Syntax: INT32 abc_set( CYCLLE_MIB *cm, INT32 cmd, INT32 *index, UINT32 mx ); cm -- Information about PDU being processed cmd -- can have four values CMD_DO_PHASE1, CMD_UNDO_PHASE1, CMD_DO_COMMIT, CMD_UNDO_COMMIT, CMD_DO_RELEASE index -- in case of errors, *index has to contain error-index value to be used. mx -- multiplexor - value returned by init() primitive for this namespace Returns: Return values of this function are described in the section 3. Description: Described in the section 3. 4.2.5 Tick Primitive Function Informs the MIB server of the passage of time. Syntax: void abc_tick(CYCLE_MIB *cm, UINT32 mx); cm -- pointer to current tick information: cm_pdutype is 0, cm_id contains 32-bit unsigned id of the tick being performed, so if one tick function serves several namespaces inside MIB-server, necessary operations will be perfromed once. mx -- multiplexor - value returned by init() primitive for this namespace Returns: Nothing. Description: The core agent invokes the tick function once every few (nominally ten) seconds between packets to allow the MIB server to perform any needed time-related functions. The tick function is never called while any packet is being processed, but only between request packets. 5 OTHER ISSUES 5.1. Other framework functions 5.1.1. Access check function admin_name_access is used by MIB-server to check access to the name while processing GetNext and GetBulk requests. INT32 admin_name_access( CYCLE_MIB *cm, OID *name, INT32 known_len, INT32 total_len ); cm -- information about PDU being processed name -- name to be checked known_len -- how many oids in the name are known total_len -- total length of the name retruned values ANA_YES -- name is accessible ANA_NO -- name is not-accessible ANA_MAYBE -- cannot be resolved yet 5.1.2. Event related functions admin_event is used to send well-known/generic notifications. Call to this function will result in sending traps/informs to all destinations registered to receive them in way appropriate for particulare destination (SNMPv1 trap, SNMPv2 trap, Inform). void admin_event( UINT32 tdomain, UINT8 *entity, INT32 entity_len, INT32 event_id, UINT32 event_data ); tdomain -- time domain (CURRENTTIME or RESTARTTIME) associated with the event. entity -- local entity associated with the event. entity_len -- its length event_id -- event-id (uses generic trap values defined in RFC1157) event_data -- if event is linkXXXX it is ifIndex value, if event egpNeighborLoss it is address, otherwise it is ignored admin_event is used to send specific notifications. Call to this function will result in sending traps/informs to all destinations registered to receive them in way appropriate for particulare destination (SNMPv1 trap, SNMPv2 trap, Inform). void admin_event_specific( UINT32 tdomain, UINT8 *entity, INT32 entity_len, struct event_block *event_blk ); tdomain -- time domain (CURRENTTIME or RESTARTTIME) associated with the event. entity -- local entity associated with the event. entity_len -- its length event_blk -- pointer to event information defined as struct event_block { INT32 eb_format; INT32 eb_generic; INT32 eb_specific; INT32 eb_oid_len; UINT32 eb_oid[MAX_EVENT_BLK_OIDS]; INT32 eb_var_len; UINT8 eb_var[1]; }; where eb_format -- format used to describe event, possible values are EF_SNMPV1 and EF_SNMPV2. eb_var_len -- length of data block eb_var -- interesing variables (beyond ones required for each SNMPv2 notification) Rest of the structure depends upon eb_format value. if eb_format is EF_SNMPV1 then, eb_generic -- is trap-geneic value eb_specific -- is trap-specific value eb_oid_len -- lenght of enterprise value eb_oid -- enterprise value if eb_format is EF_SNMPV2 then, eb_generic -- is ignored eb_specific -- is ignored eb_oid_len -- lenght of trap oid eb_oid -- trap oid value Note: traps specified in EF_SNMPV1 format are distributed to both SNMPv1 and SNMPv2 destinations, traps specified in EF_SNMPV2 format are distributed only to SNMPv2 destinations. 5.1.2. Configuration functions Windows NT's Registry is a best thing since sliced bread for configuring modular systems. OAA mimics it in a following way. There is configuration area (directory) under which all information for all MIB-servers is stored. This area can be retrieved by calling function INT32 conf_area_get(char *name, INT32 name_len) where -- name -- buffer to retrieve name of configuration area name_len -- size of this buffer And after than each MIB-server is on its own wrt configuring itself. 5.2. Other functions There are number of other functions required to be defined for a properly functional SNMP agent. However, these functions are beyond the scope of the present document. 5.3. Implementations PFA's own implementeation is available from ftp://ftp.std.com/vendors/snmp/snmp95/snmp95.tar.Z   Delivery-Date: Wed, 10 Jan 1996 09:24:49 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id JAA21537 for X-agentx-local; Wed, 10 Jan 1996 09:24:48 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id JAA21531 for ; Wed, 10 Jan 1996 09:24:47 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA02794 for agentx@fv.com; Wed, 10 Jan 96 12:24:50 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA16838; Wed, 10 Jan 1996 12:23:27 -0500 Date: Wed, 10 Jan 1996 12:25:42 EST From: Bob Natale Subject: Re: "Close" operation To: Randy Presuhn Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Randy Presuhn > Date: Thu, 4 Jan 96 18:13:57 PST Hi Randy, [Speaking as a technical contributor...] > | > From: Dan Romascanu > | > Date: Wed, 3 Jan 96 14:12:26 -0500 > | > Subject: Re: Component agent non-interde > ... > | > In the cruel physical world where I need to implement > | > my projects, cards are extracted from the slots or PSUs > | > are down before the logical entitities that run on the > | > physical devices have the time to properly 'close' the > | > connection. > > I think we're in agreement that this is a real case, and an > important one that must be supported by the agentx solution. Right...please note that Dan is talking about the case where a component agent *cannot* close gracefully (see below). > | This can happen (obviously) and must be taken into > | account, both by the eventual agentx protocol and by > | each specific implementation. The default position > | wrt the agentx protocol's handling of this as of now > | (i.e., based on how the reference protocols do it) > | would seem to be that the system agent detects the > | loss of connectivity with the component agent based > | upon the timeout of a subsequent protocol operation > | request directed to that component agent. > > I'm not sure what you mean by "default". The whole point of > having explicit close PDUs as in SMUX is to permit a subagent > to inform a master agent that the subagent is going to go away. Right...but we're talking about the case in which a component agent (subagent) for some reason cannot or does not inform the system agent (master agent) that is going to go away. In this case, timeout detection is the fallback. And, of course, this case will happen in the real world. > This can can dramatically reduce the amount of time required to > handle a subsequent request for a MIB region that was previously > the responsibility of the (deceased) subagent. In hot-standby > configurations with high-latency proxies this is a big win. True (for the normal case). No one is suggesting that we drop this functionality. > Even (or especially) when the transport happens to be TCP, the use (or > lack) of keep-alives at the TCP level may not provide sufficiently > timely notification of the loss of an association. In some systems, > notification of the loss of a localhost TCP connection is > instantaneous. In others, it is painfully slow. This is where having > an application-layer keep-alive and close, as is available in DPI and > other protocols, can have significant benefits. Ugly? No question. Again, no disagreement. > I view both keepalives and close PDUs as ugly but necessary > optimizations. If done right, they reduce our dependency on the > peculiarities of specific transport mechanisms without significantly > increasing overall protocol or implementation complexity. I think you are confusing the SERVICE with the PROTOCOL here, Randy. No one is suggesting that these kinds of services should not be provided by agentx. I would like to avoid introducing a PDU type for every service to be offered. As has been said by someone earlier, agentx is basically an "intra-agent communications protocol". As such, the messages it conveys can also carry intra- agent operational information as data...rather than having a distinct message type for each piece of intra-agent operational information. I am not saying it *has* to be this way, just that multiple PDU types for these fairly obvious cases could be avoided. I personally see that as a worthy goal for an open systems standard, but I realize that others might have a more appropriate set of design priorities. > | > That's why periodical 'are you there?' messages (like > | > the ones you proposed in one of your earlier mails) > | > are required, > | > | Yes, but as implemented in DPI (for example) the > | "Are_You_There" request is sent from the component > | agent to the system agent to verify that the system > | agent is still running. (In my scheme, this special- > | purpose packet would not be needed since a simple > | SNMP GetRequest for sysUpTime, for example, from > | component agent to system agent would accomplish the > | same purpose.) > ... > > I think this is confusing the SERVICE with the PROTOCOL. The > scheme BobN is presenting appears to in fact have a keepalive > service; it is simply realized using the GET protocol. Yes. That is exactly right. I am suggesting that it might make a lot of sense to reuse our well-understood, fairly well-debugged, clearly field-proven IETF network management protocol as the basic intra-agent communications protocol for agentx, with the "added-value" being primarily in a set of rules about message content and protocol operations upon them. There are several potentially very serious objections to such an approach...two that come to mind quicly are: - All the reference protocols in the solution space chose to define a new set of PDUs to do this; and - using SNMP is not efficient for this purpose. Insofar as the first is concerned, I am focusing on solution space functionality as the goal...and much less on specific solution space *implementations*. The problem with focusing on the latter is that they *all* appear to involve significant chunks of the "whole product" solution, above and beyond the intra-agent protocol and dealing with all of those issues could preclude us from ever reaching consensus or even technial completion if we did reach consensus on the full range of issues. The second objection was high-lighted in the recent posting from Jeff Case (about the choice of formal definition language and encoding rules), which I will answer in a separate reply. Note that I am saying that both of those are potentially serious objections (with real merit) against my scheme. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Wed, 10 Jan 1996 13:06:05 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id NAA18605 for X-agentx-local; Wed, 10 Jan 1996 13:06:05 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id NAA18600 for ; Wed, 10 Jan 1996 13:06:04 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA01647 for agentx@fv.com; Wed, 10 Jan 96 16:06:10 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA19431; Wed, 10 Jan 1996 15:04:47 -0500 Date: Wed, 10 Jan 1996 15:07:03 EST From: Bob Natale Subject: Re: PDUs, proto-ops, and principles To: case@snmp.com Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: case@snmp.com > Date: Fri, 5 Jan 96 13:49:37 -0500 Hi Jeff, [Speaking as a technical contributor...] <...> > we studied this carefully when designing emanate and we decided > NOT to use ASN.1 BER encoding in any messages between the master > agent and the subagent and have been delighted with this design > choice Yes, certainly more appealing/efficient encoding schemes are available, relative to ASN.1/BER. The arguments *for* using ASN.1/BER include: 1. It already exists as a public, open standard; 2. it's (reasonably) well-defined (particularly the SNMP subset); 3. it's (reasonably!) efficient (based on existence proofs); 4. other parts of an extensible agent environment will use it anyway (e.g., MIBs and the system agent interface to the external management apps); 5. most (?) folks who will implement extensible agent products (i.e., system agent and "environment") already have this code in tools/libraries in fairly well-debugged form; 6. most (?) (maybe all ???) component agent builders will have access to these libraries. I, of course, stand ready to be corrected on any or all of the above. My personal feeling is the only assertion #6 is problematic. And, I agree that the choice of a different encodig format by multiple implementors in the solution space is a very strong argument. However, one can *imagine* that it is inviting to come up with a new encoding format (not to mention a bunch of PDU types!) when devising a new system on one's own and, particularly, in the context of an overall "whole product" solution in which many/most of the other parts will come from this same implementor. I am merely trying to call attention to whether it might not be preferable--in the context of an industry standard design process--to reuse/leverge as much as possble of an existing core protocol (SNMP) that will be an integral part of the operating environment for the new protocol (agentx) as well. A scan of the solution space suggests the answer to that is "No". But then we might need more detailed definitions of the encoding(s) to be used...can you provide some info (at whatever level of abstraction or detail that you consider appropriate) wrt what emanate uses in this regard or to what you (anyone) think agentx *should* use. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Wed, 10 Jan 1996 14:00:15 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id OAA02670 for X-agentx-local; Wed, 10 Jan 1996 14:00:14 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id OAA02664 for ; Wed, 10 Jan 1996 14:00:12 -0800 (PST) Received: by dorothy.peer.com (4.1/SMI-4.1) id AA22429; Wed, 10 Jan 96 14:00:07 PST Date: Wed, 10 Jan 96 14:00:07 PST From: randy@peer.com (Randy Presuhn) Message-Id: <9601102200.AA22429@dorothy.peer.com> To: agentx@fv.com Subject: Re: PDUs, proto-ops, and principles Hi - > From agentx-owner@fv.com Wed Jan 10 13:56:02 1996 > Date: Wed, 10 Jan 1996 15:07:03 EST > From: Bob Natale > Subject: Re: PDUs, proto-ops, and principles > To: case@snmp.com > Cc: agentx@fv.com ... > Yes, certainly more appealing/efficient encoding schemes are > available, relative to ASN.1/BER. ... Did you have anything specific in mind? -------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy@peer.com USA --------------------------------------------------------------------------   Delivery-Date: Wed, 10 Jan 1996 15:39:53 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id PAA29401 for X-agentx-local; Wed, 10 Jan 1996 15:39:52 -0800 (PST) Received: from seymour4 (seymour4.snmp.com [192.147.142.4]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id PAA29398 for ; Wed, 10 Jan 1996 15:39:50 -0800 (PST) From: case@snmp.com Received: by seymour4 (5.61++/2.8s-SNMP ) id AA07393; Wed, 10 Jan 96 18:34:54 -0500 Date: Wed, 10 Jan 96 18:34:54 -0500 Message-Id: <9601102334.AA07393@seymour4> To: natale@acec.com Subject: Re: PDUs, proto-ops, and principles Cc: agentx@fv.com >the above. My personal feeling is the only assertion #6 is >problematic. none of your assertions are problematic as such ... ASN.1/BER certainly CAN be used for a design ... and it would have some advantages and some disadvantages you cite multiple advantages i started to write some of the disadvantages here, but deleted them because i don't want to be labeled as the initiator of the rathole discussion which is certain to follow ... i'll merely respond directly to your queries, below there are far more important considerations than the encoding of the messages that we have barely even begun to discuss: registration options by objects by partial instances by complete instances by subtrees by ranges by contexts/naming scopes/etc single or multiple registrations and deregistrations during the life of a subagent overlapping or disjoint registrations "connection" types tightly coupled loosely coupled remotely coupled set semantics number of passes memory management aspects reservation features always the same instance monotonically increasing instances subagent-to-subagent communications error handling caching mechanisms etc >And, I agree that the choice of a different encodig format by >multiple implementors in the solution space is a very strong >argument. However, one can *imagine* that it is inviting to gee, i suspect there were solid reasons why they decided not to use asn.1 >come up with a new encoding format (not to mention a bunch of >PDU types!) when devising a new system on one's own and, we dont even use pdus between the master agent and subagents ... we call them "events" because the events between master agents and subagents tend to operate on varbinds, not varbindlists (but there is almost always an exception to every rule) >particularly, in the context of an overall "whole product" >solution in which many/most of the other parts will come from >this same implementor. ok >I am merely trying to call attention to whether it might not >be preferable--in the context of an industry standard design >process--to reuse/leverge as much as possble of an existing >core protocol (SNMP) that will be an integral part of the >operating environment for the new protocol (agentx) as well. you could reuse/leverage as much as possible of an existing protocol without reusing SNMP ... for example, you might use RPC, as specified in RFC 1050 >A scan of the solution space suggests the answer to that is >"No". But then we might need more detailed definitions of with the exception of SMUX/RFC 1227, i think you are correct >the encoding(s) to be used...can you provide some info (at >whatever level of abstraction or detail that you consider >appropriate) wrt what emanate uses in this regard or to >what you (anyone) think agentx *should* use. we use something that is an rpc note that i said an rpc, not to be confused with what i call THE rpc we think that aligned and padded values makes a good deal of sense there are at least 4 notable differences between what we do and what xdr/rpc/nfs uses xdr is always big endian whereas emanate is "receiver makes it right" which is a big performance win in homogeneous little endian environments, like the 100 gazillion or so intel-based dos/nt/os2/unix boxen (where homogeneous means the master agent and subagent are on the same type of processor, which they are in the normal case, even the SAME processor, which kindof implies the same type of processor) emanate is layered on a "connection-oriented" transport so we can tell when a subagent goes away and comes back again ... that connection-oriented transport might be DDE (windows), named pipes (NT) unix domain sockets (unix), ..., tcp connection (across lan/man/wan), etc. [nb: it can be layered on top of something not connection oriented (an exception to make a rule) if one adds a shim layer ] we don't do anything even close to portmapper we've transitioned to a self-describing data structure in some places ... the redefinition of a datastructure (contextInfo *) which among other things told about the party, party, context triple which caused the transaction caused us to make it self-describing since we don't know exactly what the future holds with regard to the replacement for party, party, context, hence the self-describing part to preserve future interoperability in the face of uncertainty [they may not interoperate, but they will at least be able to decide that they can't talk with one another without crashing each other] i think you will find that if you try to leverage too much, e.g., the PDU format, you don't have enough bits to do some of the transactions specifically, multipass sets with commit, rollback, locking, unlocking, etc will be a problem without additional syntactic richness it may be helpful for you to think of it this way: take a monolithic agent that is compliant with all of the features you want, then figure out a way to make the procedure calls between cooperating processes, possibly across a lan, i.e., change the procedure calls into remote procedure calls speaking of solution space ... rather than problem space: as i said in my brief talk in seattle at the 29th ietf ... it is easier to take a compliant implementation that has all the features you want ... and modify it to make it extensible ... than to take something that is extensible but isn't compliant or doesn't have all the features you want and add the compliance and other features you want so rather than looking at noncompliant and limited extensible agent schemes as the solution space, it make make some sense to look at the solution space of nonextensible agents that have the features and compliance you want and figure out how to make them extensible regards, jdc   Delivery-Date: Wed, 10 Jan 1996 20:23:17 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id UAA11417 for X-agentx-local; Wed, 10 Jan 1996 20:23:17 -0800 (PST) Received: from europe.std.com (europe.std.com [192.74.137.10]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id UAA11410 for ; Wed, 10 Jan 1996 20:23:16 -0800 (PST) Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id XAA10929; Wed, 10 Jan 1996 23:23:22 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA07803; Wed, 10 Jan 1996 23:17:35 -0500 From: ralex@world.std.com (Aleksey Y Romanov) Message-Id: <199601110417.AA07803@world.std.com> Subject: Re: PDUs, proto-ops, and principles To: case@snmp.com Date: Wed, 10 Jan 1996 23:17:35 -0500 (EST) Cc: agentx@fv.com In-Reply-To: <9601102334.AA07393@seymour4> from "case@snmp.com" at Jan 10, 96 06:34:54 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > messages that we have barely even begun to discuss: > registration options > by objects > by partial instances > by complete instances > by subtrees > by ranges > by contexts/naming scopes/etc IMHO, subtrees and ranges are more than enough while being simpliest things to implement. I favored ranges but had changed my mind recently in favor of sub-trees - it adds unsignificant overhead, however, substantially simplifies processing in case of overlapped sub-tress (e.g. when different rows in table have to be handled by different sub-agents). > single or multiple registrations and deregistrations during > the life of a subagent Yes. > overlapping or disjoint registrations Yes. I suppose under disjoint registration you mean case when same sub-agent handles sub-trees located in the different parts of the whole MIB-space. > "connection" types > tightly coupled I suppose it means connection through by DLL > loosely coupled I suppose it means connection by some sort of IPC within one computer > remotely coupled ????? Do we need to address this issue at this level ? So far there is a hope that something logically universal will arise from this work, isn't it ? I we have to make a decision I would prefer to see efforts concentrated in area of loosely coupled: I do not think that one can provide much of improvement vs OAA in the area of tightly coupled sub-agents, and I do think that remotely coupled case is more appropriate to be solved by proxies. (Actually, I think that losely coupled connection can be achieved by writing simple device driver and mapping OAA into this environment, but I would like to see whether more general solution will surface, before jumping.) > set semantics > number of passes > memory management aspects Can you elaborate on this issue ? > reservation features > always the same instance > monotonically increasing instances ???? > subagent-to-subagent communications There is very simple solution, which is not absolute but can satisfy 99.9% of requirements. Let us suppose that we have tightly coupled, loosely coupled and remotely coupled sub-agents. It is really trivial to allow for piece of software mounted as tightly coupled sub-agent to take over master-agent (on time-to-time basis) or thread in master-agent (on the permanent basis) and thus gain access to all other sub-agents. As I said this solution is not an absolute one, however, it seem to provide for all practical needs and very cheap. > error handling ???? > caching mechanisms IMHO, this has to be left to sub-agent designers. > etc What about access control policies ? > we dont even use pdus between the master agent and subagents ... we call > them "events" because the events between master agents and subagents tend > to operate on varbinds, not varbindlists (but there is almost always an > exception to every rule) we call it 'primitives' :). > so rather than looking at noncompliant and limited extensible agent schemes > as the solution space, it make make some sense to look at the solution space > of nonextensible agents that have the features and compliance you want > and figure out how to make them extensible Do you mean that BobN does not pay enough attention to OAA ? :) (While OAA can be considered only 'moderately extensible' (only tight coupling so far) it is definitely compliant (naturally limited by the extent I understand documents). > > regards, > jdc Aleksey   Delivery-Date: Wed, 10 Jan 1996 22:32:58 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id WAA12243 for X-agentx-local; Wed, 10 Jan 1996 22:32:58 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id WAA12239 for ; Wed, 10 Jan 1996 22:32:57 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA13048 for agentx@fv.com; Thu, 11 Jan 96 01:30:32 -0500 Date: Thu, 11 Jan 1996 01:29:45 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA27149; Thu, 11 Jan 1996 01:29:45 -0500 Message-Id: <9601110629.AA27149@nips.acec.com> To: randy@peer.com Subject: Re: PDUs, proto-ops, and principles Cc: agentx@fv.com > Date: Wed, 10 Jan 96 14:00:07 PST > From: randy@peer.com (Randy Presuhn) Hi Randy, [Speaking as a technical contributor...] <...> > > Yes, certainly more appealing/efficient encoding schemes are > > available, relative to ASN.1/BER. > > Did you have anything specific in mind? Nope...although I advocate re-using SNMP-ized ASN.1/BER, I was recognizing the apparent wide sentiment for using something else and trying to eke out contributions from others about the *specifics* of those alternatives. [Speaking (mostly) as wg chair...] In a slightly later message than yours, Jeff outlined some of the attributes of the alternative encoding scheme used by EMANATE. That was helpful. But, if agentx is not going to use ASN.1/BER, then we need a detailed and (eventually) complete description of the encoding scheme it will use. Also in his message (which I will reply to separately in the morning...probably working from Aleksey's follow-up), Jeff indicated (if I understood him correctly) that there are more important issues to be dealt with (first?). That is perhaps true. I am just trying to get a couple of threads going...and trying to get them fueled by inputs from other contributors. And as I said in an earlier posting, one strategy I am trying to follow is to have us work from the bottom up on some of these issues, rather than the top down (and I consider the encoding scheme to be fairly close to the bottom). That is just a strategy... if it does not fly, fine...we'll press on anyway. It is very encouraging to see input coming from you and Jeff and several other implementors (e.g., Mike and Aleksey). I hope that you (all) will be able to continue to oversee and contribute to this effort. I have been advised by several other notable implementors that they will soon be able to play active roles in the wg too. We have a lot of issues to resolve, for sure...but we have collectively shown a strong and abiding desire to provide a standard for this technology. There is both a lot of diversity and several significant gaps in the solution space...and some competitive pressures to overcome...but I think we are gaining some momentum and moving--albeit very slowly--in the right direction at this time. [Off...] Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Thu, 11 Jan 1996 07:57:15 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id HAA28972 for X-agentx-local; Thu, 11 Jan 1996 07:57:14 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id HAA28966 for ; Thu, 11 Jan 1996 07:57:13 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA17227 for agentx@fv.com; Thu, 11 Jan 96 10:57:17 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA02531; Thu, 11 Jan 1996 10:55:54 -0500 Date: Thu, 11 Jan 1996 10:58:15 EST From: Bob Natale Subject: Re: on overlapping registrations and priorities To: case@snmp.com Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: case@snmp.com > Date: Fri, 5 Jan 96 13:47:38 -0500 Hi Jeff, [Speaking with some probable confusion of roles here...] > any technology must have a transition scheme from the technology > of the market it hopes to supplant which is to say that if the > work output of the agentx effort is to be successful, it needs > to be able to support transition from the existing extensible > agent technologies Granted. > since at least two of the existing extensible agent technologies > (SMUX and EMANATE) support overlapping registration requests, a > similar capability is required in the followon design if we are > to be able to build "weird plumbing adapters" to support the > installed base ... or ... we have to be willing to abandon the > installed base I doubt that I (or many others) would be willing to abandon the installed base...the only basis I can see for assigning a lower priority (no pun intended) to that goal *might* be the "100 gazillion or so" Intel based boxes (most of which sorely need a standard extensible SNMP agent solution) that you mentioned in another posting...? > EMANATE supports the priority feature primarily to allow the > construction of interfaces to existing smux-based subagents So, it *might* not be unreasonable to ask: - How many of these are there that users will want to continue using? (Cost/benefit issue relative to deploying "better" (?) technology.) - How much do we want to commit to supporting code based on "Historic" status RFCs? I know those are tough questions to answer...actually, they're not all that easy to ask even! > while there are 128ish or 256ish levels of priority possible, > in practice i have seen only a couple of levels used, i.e., > some, and more, but once n is >= 2, the top limit is pretty > irrrelevant, and n is >= 2 Granted. The key issue wrt priorities is this: What relevance does this feature have to someone developing a component agent vis-a-vis others (independently) developing competing and/or complementary component agents? In other words, how does one decide to assign oneself a higher or lower priority relative to those others? I would really like to see an answer to that question from the proponents of a priority mechanism. Now, if the answer is that this is a non-issue because the user can configure the relative priorities of the component agents, then priority is not needed in the protocol because that could clearly all be accomplished by simply configuring the extensible agent environment itself (i.e., external to the component agents). That's it...I just don't see how "priority" can be used rationally in the independent development of component agents. While that certainly leaves room for its rational use when mutually dependent component agents are being developed (as the gated example that Mike Daniele offered clearly shows), it also leaves room for rampant irrational use of the feature among independently developed component agents (e.g., random priority, selfishly high priority, masochistically low priority, etc.). The argument that "Well, we have this now in the solution space and it does not seem to present any problems" is (possibly) refuted by the fact that only a low measure of competition exists for component agents to date. This will change dramatically --I believe--when agentx is available to equip the "100 gazillion or so" PCs out there with system agents, printer agents, modem agents, scanner agents, video agents, and (above all) application agents. > a more recent finding is that some users believe overlapping > registrations should be "transparent" whereas other overlapping > registrations should be "opaque" ... i have not yet found a case > where the "opaque" requirement was real but there is always a > counterexample ... perhaps this list will come up with one ... > then we can decide if it is meaningful ... this, in part was what > i perceived to be one of the points of seligson's posting of 2 jan Yes, I owe John (and some others) a reply (delayed due to a self- inflicted e-mail injury which I am recovering from). FWIW, I personally favor the "transparent" view (and note that transparent support for overlapping registrations does not depend on any explicit priority mechanism in the protocol). > i know there are other messages i need to respond to, but i'm > having trouble catching up with the 60+ messages that accumulated > while i was away on Christmas travel Yes, and I guess you're losing considerable time to the recent snow storm too... As wg chair, I greatly appreciate your taking the time to provide whatever info you can wrt how EMANATE helps to define the solution space and to offer your opinions and guidance on any other aspect of this work. I am optimistic that an open discussion among all interested parties, fueled by inputs and feedback control from the major implementors, will help us to identify the common ground and the improvements we will have to make to it. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Thu, 11 Jan 1996 08:28:01 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id IAA05946 for X-agentx-local; Thu, 11 Jan 1996 08:28:00 -0800 (PST) Received: from seymour4 (seymour4.snmp.com [192.147.142.4]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id IAA05933 for ; Thu, 11 Jan 1996 08:27:58 -0800 (PST) From: case@snmp.com Received: by seymour4 (5.61++/2.8s-SNMP ) id AA07861; Thu, 11 Jan 96 11:14:08 -0500 Date: Thu, 11 Jan 96 11:14:08 -0500 Message-Id: <9601111614.AA07861@seymour4> To: natale@acec.com Subject: Re: on overlapping registrations and priorities Cc: agentx@fv.com >> since at least two of the existing extensible agent technologies >> (SMUX and EMANATE) support overlapping registration requests, a >> similar capability is required in the followon design if we are >> to be able to build "weird plumbing adapters" to support the >> installed base ... or ... we have to be willing to abandon the >> installed base >I doubt that I (or many others) would be willing to abandon the >installed base...the only basis I can see for assigning a lower >priority (no pun intended) to that goal *might* be the "100 >gazillion or so" Intel based boxes (most of which sorely need a >standard extensible SNMP agent solution) that you mentioned in >another posting...? so you like my way of sidestepping market research to get the exact number of those boxes? in all seriousness, please note that the NT and now Windows '95 boxen will need weird plumbing adapters to work with the NT extensible agent which is now available on Windows '95 ... even though this piece of code is pretty lame, it is a pretty big installed base to intentionally ignore since it comes from the world's largest and most successful standards-setting organization i think any agentx spec should allow the construction of a shim layer, i.e., perhaps a subagent, to allow backward compatibility with subagents built using the microsoft sdk, even though such subagents accessed through such shims would not do sets correctly, i.e., in accord with rfc 1157; however, we should be able to design something that allows them to be no less correct than they already are >> EMANATE supports the priority feature primarily to allow the >> construction of interfaces to existing smux-based subagents >So, it *might* not be unreasonable to ask: > > - How many of these are there that users will want > to continue using? (Cost/benefit issue relative > to deploying "better" (?) technology.) > > - How much do we want to commit to supporting code > based on "Historic" status RFCs? > >I know those are tough questions to answer...actually, they're >not all that easy to ask even! i don't know the answers wrt smux ... perhaps randy has better data ... i merely know that it is a market expectation of EMANATE in some markets that it be able to handle existing subagents from other technologies ... if you hope for agentx to be able to replace EMANATE, then i think it follows that agentx faces similar requirements >The key issue wrt priorities is this: What relevance does this >feature have to someone developing a component agent vis-a-vis >others (independently) developing competing and/or complementary >component agents? In other words, how does one decide to assign >oneself a higher or lower priority relative to those others? i think use of a startup parameter is the obvious solution >Yes, and I guess you're losing considerable time to the recent >snow storm too... As wg chair, I greatly appreciate your taking we are currently between storm waves ... we are hunkering down to get plastered again ... besides, we didn't get it as badly as you and others did, plus, my commute isn't too bad ... the problem is when the power fails -- because you can live on a ups only so long :-) >the time to provide whatever info you can wrt how EMANATE helps >to define the solution space and to offer your opinions and >guidance on any other aspect of this work. I am optimistic >... thanks, i hope my contributions have been a least a little help regards, jdc   Delivery-Date: Thu, 11 Jan 1996 09:26:24 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id JAA18477 for X-agentx-local; Thu, 11 Jan 1996 09:26:23 -0800 (PST) Received: from lightning.synoptics.com (lightning.synoptics.com [134.177.3.18]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id JAA18474 for ; Thu, 11 Jan 1996 09:26:23 -0800 (PST) Received: from pobox ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA15680; Thu, 11 Jan 96 09:24:30 PST Received: from turing.engwest (turing-nf0) by pobox (4.1/SMI-4.1) id AA27936; Thu, 11 Jan 96 09:21:28 PST Received: from wolverine.engwest by turing.engwest (SMI-8.6/SMI-SVR4) id JAA04977; Thu, 11 Jan 1996 09:18:15 -0800 Date: Thu, 11 Jan 1996 09:18:15 -0800 From: johns@BayNetworks.COM (John Seligson) Message-Id: <199601111718.JAA04977@turing.engwest> To: case@snmp.com, natale@acec.com Subject: Re: on overlapping registrations and priorities Cc: agentx@fv.com Bob, > The key issue wrt priorities is this: What relevance does this > feature have to someone developing a component agent vis-a-vis > others (independently) developing competing and/or complementary > component agents? In other words, how does one decide to assign > oneself a higher or lower priority relative to those others? I'm not necessarily arguing for priorities (there are much bigger fish to fry here) but I would like to remind folks not to forget the use of this technology within embedded systems. Component agents are developed in a cooperative fashion in this environement and can use a priority scheme to their advantage. To date, embedded systems probably represent the largest installed base of extensible agent technology. > That's it...I just don't see how "priority" can be used rationally > in the independent development of component agents. While that > certainly leaves room for its rational use when mutually dependent > component agents are being developed (as the gated example that Mike > Daniele offered clearly shows), it also leaves room for rampant > irrational use of the feature among independently developed > component agents (e.g., random priority, selfishly high priority, > masochistically low priority, etc.). Including a switch in the system (i.e., master) agent to disregard priorities during registration solves the "irrational use" problem when independently developed component agents may be present while allowing the use of priorities when it is deemed appropriate. Having a switch which defaults to "no priority support" makes this a no-brainer. System agents can then support priority registration or not (i.e., the siwtch does not need to be setable). All it costs is a couple of bytes in the registration message and no existing functionality is lost. John   Delivery-Date: Thu, 11 Jan 1996 14:16:35 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id OAA26480 for X-agentx-local; Thu, 11 Jan 1996 14:16:34 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id OAA26462 for ; Thu, 11 Jan 1996 14:16:32 -0800 (PST) Received: by dorothy.peer.com (4.1/SMI-4.1) id AA08192; Thu, 11 Jan 96 14:15:11 PST Date: Thu, 11 Jan 96 14:15:11 PST From: randy@dorothy.peer.com (Randy Presuhn) Message-Id: <9601112215.AA08192@dorothy.peer.com> To: agentx@fv.com Subject: Re: on overlapping registrations and priorities Hi - I think supporting registration overlaps is a requirement. Specific case: tables allowing row creation where different rows may belong to different subagents. (For example, a table which allows new processes to be spawned.) I think prioritization is a requirement. It is needed for systems with hot insertion, for example. Master agent pre-configuration or re-configuration is NOT an option in this environment. Prioritization, with a reasonable conflict resolution policy and the ability for a subagent to choose whether to request a specific priority or a "I don't care", is NOT difficult or costly to implement. As a practical matter, you have to do it anyway to deal with accidental subagent conflicts. It makes it possible to support an important class of applications, without requiring any increase in the complexity of applications that don't need it. > Date: Thu, 11 Jan 1996 10:58:15 EST > From: Bob Natale > Subject: Re: on overlapping registrations and priorities ... > The key issue wrt priorities is this: What relevance does this > feature have to someone developing a component agent vis-a-vis > others (independently) developing competing and/or complementary > component agents? In other words, how does one decide to assign > oneself a higher or lower priority relative to those others? In the cases where priority is relevant, the mechanism for deciding which hot-swappable module (or whatever) is the primary one will be highly system system specific. How an application choses its own priority is far outside the scope of subagent communication standardization. What we do need to agree on is the default priority assignment and conflict resolution scheme for the (more typical) case where the managed application is not intelligently chosing its own priority. > Now, if the answer is that this is a non-issue because the user > can configure the relative priorities of the component agents, In the systems I have in mind (switches, routers, muxes, and fault- tolerant servers), there isn't really a "user". The provisioning of a particular component as a primary or backup unit should not be made any more complicated than it already is. Requiring additional out-of-band configuration of master agents does not make sense when the problem can be solved in a much simpler and cleaner way through the registration protocol. > then priority is not needed in the protocol because that could > clearly all be accomplished by simply configuring the extensible > agent environment itself (i.e., external to the component agents). Usually in these systems the components are very much aware of whether they are active or on hot/warm standby. With typical 1-for-N redundancy configurations, the set of information that the backup unit will register isn't known till changeover time. Master agent preconfiguration only makes matters more complicated. > That's it...I just don't see how "priority" can be used rationally > in the independent development of component agents. While that > certainly leaves room for its rational use when mutually dependent > component agents are being developed (as the gated example that Mike > Daniele offered clearly shows), it also leaves room for rampant > irrational use of the feature among independently developed > component agents (e.g., random priority, selfishly high priority, > masochistically low priority, etc.). What's the problem? All that priority does is determine which subagent services a request in the event of otherwise identical registrations. If the subagent can make a "I don't care what priority" registration request, the common case is nicely covered. In the case where the registration requests don't collide, priority assignment is boring. > The argument that "Well, we have this now in the solution space > and it does not seem to present any problems" is (possibly) > refuted by the fact that only a low measure of competition exists > for component agents to date. This will change dramatically > --I believe--when agentx is available to equip the "100 gazillion > or so" PCs out there with system agents, printer agents, modem > agents, scanner agents, video agents, and (above all) application > agents. ... I suspect that registration conflicts have a different significance in PC environments than they do for the multi-processor switches and servers where subagent technology is currently widely deployed. In the PC environment, a duplicate registration request is probably more likely to indicate an entity MIB kind of situation (multiple logical resources) rather than multiple sets of instrumentation for the same logical resource. Anyway, once you recognize the possibility of duplicate registration requests, you need to define not only a conflict resolution mechanism, but you also need to recognize priority at least as a aspect of the model in order to describe what happens if a contention winner dies. I don't understand what you mean by "measure of competition .. for component agents." Priority in the existing solutions is a property of the registration of a MIB region. A subagent may register different MIB regions at different priorities. Priority of registration request coupled with a conflict resolution mechanism determines which subagent gets to handle management requests for a particular MIB region. This is not difficult. I'd really hate to drop a feature that is usefull, is required to understand system behaviour, and is easy to implement, especially if the alternative increases configuration complexity, requires an additional, out-of-band channel, a more complicated model, and does not support hot standby configurations. -------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy@peer.com USA --------------------------------------------------------------------------   Delivery-Date: Thu, 11 Jan 1996 15:00:16 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id PAA08318 for X-agentx-local; Thu, 11 Jan 1996 15:00:15 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id PAA08311 for ; Thu, 11 Jan 1996 15:00:13 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA10715 for agentx@fv.com; Thu, 11 Jan 96 18:00:16 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA08844; Thu, 11 Jan 1996 17:58:52 -0500 Date: Thu, 11 Jan 1996 18:01:16 EST From: Bob Natale Subject: Re: on overlapping registrations and priorities (fwd) To: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi everyone, In response to my request for inputs from implementors wrt the use of priority among independently developed component agents, I received the following off-list response. It is from an implementor with direct experience wrt the topic. I have deleted some introductory text of a non-technical nature. And I have modified the remainder only wrt ensuring the anonymity of the original poster. -----Forwarded message ----- From: Date: Thu, 11 Jan 1996 14:09:35 -0500 (EST) > = BobN > The key issue wrt priorities is this: What relevance does this > feature have to someone developing a component agent vis-a-vis > others (independently) developing competing and/or complementary > component agents? In other words, how does one decide to assign > oneself a higher or lower priority relative to those others? > > I would really like to see an answer to that question from the > proponents of a priority mechanism. > > Now, if the answer is that this is a non-issue because the user > can configure the relative priorities of the component agents, > then priority is not needed in the protocol because that could > clearly all be accomplished by simply configuring the extensible > agent environment itself (i.e., external to the component agents). does have transparent overlapping registrations and it does support registration priorities. However we found that there was no really good way to resolve which agent gets the request in the case of a registration overlap. We considered using the most fully qualified subtree oid (most number of subids), first registered, most recently registered, and priorities. We ended up with priorities and using most recently registered when the priorities are the same. But we could always find cases where the result was not deterministic or it required some level of coordination between component agent implementations. For example, the order of startup of component agents (or when they register relative to each other) is not always controllable. Any component agent should be allowed to come and go at any time. On the otherhand, hard coding priorities in the component agents will require coordination between implementations that is not possible or desirable. I feel that perhaps the best thing to do is pick an approach that gives the best resolution most of the time and then allow the user to specify a priority (to the component agent) to overide the result if the default registration resolutions do not result in the desired affect. Unless the user (the system manager perhaps) controls the priorities, the use of priorities does not make since. For this reason we may still need to support priority in the protocol so that the priority can be passed through from the component agent to the system agent during registration. This way it is the runtime configuration of the component agent that determines the priority and the system agent does not need to know anything about the component agent until it registers. ----- End of forwarded message ----- My response to this very helpful summary is that I'd personally prefer to avoid having the user (which, as was noted above, would typically be a sysadmin type) configure individual component agents, in favor of having him configure the single system agent. The latter would most likely be done via SNMP mgmt apps by setting values in some SA_MIB table or by settings in an external config file which would be read a system agent startup...either and all of which would be totally transparent to the individual component agents. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Thu, 11 Jan 1996 15:19:45 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id PAA12949 for X-agentx-local; Thu, 11 Jan 1996 15:19:44 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id PAA12942 for ; Thu, 11 Jan 1996 15:19:43 -0800 (PST) Received: by dorothy.peer.com (4.1/SMI-4.1) id AA00973; Thu, 11 Jan 96 15:19:38 PST Date: Thu, 11 Jan 96 15:19:38 PST From: randy@peer.com (Randy Presuhn) Message-Id: <9601112319.AA00973@dorothy.peer.com> To: agentx@fv.com Subject: Re: on overlapping registrations and priorities Hi - > From: case@snmp.com > Date: Thu, 11 Jan 96 11:14:08 -0500 > To: natale@acec.com > Subject: Re: on overlapping registrations and priorities > Cc: agentx@fv.com ... > i think any agentx spec should allow the construction of a shim layer, i.e., > perhaps a subagent, to allow backward compatibility with subagents built > using the microsoft sdk, even though such subagents accessed through such > shims would not do sets correctly, i.e., in accord with rfc 1157; however, > we should be able to design something that allows them to be no less correct > than they already are Yes. There are numerous situations like this out there. Proxy would perhaps be a more proper approach, but these situations do not always play out in a way that permits it, either for business or technical reasons. > i don't know the answers wrt smux ... perhaps randy has better data ... i > merely know that it is a market expectation of EMANATE in some markets that > it be able to handle existing subagents from other technologies ... if > you hope for agentx to be able to replace EMANATE, then i think it follows > that agentx faces similar requirements ... I agree with Jeff's analysis. The same market situation applies for other subagent technologies. We've both seen both sides of this situation. It's a big win if we define things in such a way as to permit the necessary adapters. I don't see a need to introduce a priority mechanism richer than that provided by the SMUX/EMANATE solutions, since they appear to meet the known requirements. In order to preserve the existing investment in these technologies, agentx needs to support equivalent capability. -------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy@peer.com USA --------------------------------------------------------------------------   Delivery-Date: Thu, 11 Jan 1996 15:24:08 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id PAA14057 for X-agentx-local; Thu, 11 Jan 1996 15:24:08 -0800 (PST) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id PAA14051 for ; Thu, 11 Jan 1996 15:24:05 -0800 (PST) Received: from flume.zk3.dec.com by mail12.digital.com; (5.65v3.2/1.0/WV) id AA25733; Thu, 11 Jan 1996 18:19:03 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA13297; Thu, 11 Jan 1996 18:18:59 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA04517; Thu, 11 Jan 1996 18:19:25 -0500 Message-Id: <9601112319.AA04517@bernie.zk3.dec.com> To: natale@acec.com Cc: case@snmp.com, agentx@fv.com Subject: Re: PDUs, proto-ops, and principles In-Reply-To: Your message of "Wed, 10 Jan 96 18:34:54 EST." <9601102334.AA07393@seymour4> Date: Thu, 11 Jan 96 18:19:24 -0500 From: Mike Daniele X-Mts: smtp Hi Bob, I agree (with several others, it seems) that we've got the cart before the horse to some extent. I think it would be a good idea to focus on getting concensus for a general architecture and set of functions for agentx. Along the way hopefully current requirements will be fleshed out. (Please feel free to substitute 'picture', or 'system design' or 'division of labor' for the word 'architecture' above, if it makes you queasy :-) I haven't jumped in with more about eSNMP (as promised) because, as I alluded to previously, it's not important now. You're the chair, and I certainly agree that we have to do something other than argue about requirements. But... Since the notion of registration is so key to agentx, that's probably a good place to start. Specifically, wrt Jeff's posting: >there are far more important considerations than the encoding of the >messages that we have barely even begun to discuss: > registration options > by objects > by partial instances > by complete instances > by subtrees > by ranges Hi Jeff, I'm not sure what you mean by 'partial instance', is it the ability to register a row without registering all columnar objects in the row? Or is it simply an object plus some-but-not-all the instance portion? If the latter, would you agree that registering a single oid accomplishes all of these (given an oid carries an assumed range)? Is 'registration by single oid' viable for everyone? Anyone? > single or multiple registrations and deregistrations during > the life of a subagent This strikes me as a general requirement. > overlapping or disjoint registrations This too. Bob, wrt priority: >I would really like to see an answer to that question from the >proponents of a priority mechanism. I am not a proponent of a priority mechanism, even tho eSNMP has one. So I'm not going to defend it :-) I am of the opinion that overlapping registrations are a reality of life, and agentx needs to address it. (Note, 'addressing it' could be as simple as something like overlapping regs are accepted when evaluating how to distribute a management request, the system agent's algorithm is 'most fully qualified registration wins' the response to a registration request indicates whether or not the component agent is currently most fully qualified. but subsequent registrations could alter that (transparently) there are no priorities associated with registration I don't mean to rathole about overlapping registration. If it's the concensus of the group that agentx shouldn't allow it, so be it. But it seems like a real-world requirement to me. Off to buy more snow shovels... Mike   Delivery-Date: Thu, 11 Jan 1996 15:41:19 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id PAA18582 for X-agentx-local; Thu, 11 Jan 1996 15:41:16 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id PAA18571 for ; Thu, 11 Jan 1996 15:41:11 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA15016 for agentx@fv.com; Thu, 11 Jan 96 18:41:16 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA09608; Thu, 11 Jan 1996 18:39:54 -0500 Date: Thu, 11 Jan 1996 18:42:16 EST From: Bob Natale Subject: Re: Component agent non-interdependency To: John Seligson Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: John Seligson > Date: Tue, 2 Jan 96 16:29:20 PST Hi John, Please forgive my delay in answering...been swamped...and it seems that the "top of the pile" (most recent stuff) is always somehow easier to get to...! [Speaking as a technical contributor...] <...> > I feel a priority registration mechanism should not be precluded > by the design. I agree with that. It does not imply that a priority registration mechanism needs to be part of the protocol, however. > A simple trade-off would be to allow component agents > that are aware of each other register with a priority. Component > agents that don't know about anyone else could register with no priority > value and be given the highest priority value by the system agent > should other component agents register for the same object space. This can be accomplished just as effectively and more efficiently by configuration of/settings in the system agent. It's the only one that needs to know about the relative priorities of components anyway. >>> = from Geoff Carpenter, for reference below... >>> 2) accept the duplicate registration and allow it to have precedence >>> over a prior registration. While slightly more difficult to implement >>> than the first case, this would permit run-time patching of faulty >>> components. > I assume that the "precedence" mentioned in item 2 above means that > one component agent will be called before another, not that only one > component agent is queried. I'm not sure that's what Geoff meant. I interpreted it as meaning that the component agent with the highest precedence would get the call. If it goes away, then the one with the next highest precedence would get the next one. > When multiple component agents register for the same object space, > each presumably handles different object instances. Yes, unless we're talking about scalars...for which only one component agent will get the call. For "rows", there are several good candidate possible ways for the system agent to support duplicate/inter-mixed instance values. > Each component agent will need to be queried during GetNext > processing, allowing the system agent to compute and return > the lexi-least return OID value. Just a clarification. Some schemes require that...I would prefer one in which the system agent knows the lexi-order of all instances up front (or has a means to "refresh" its knowledge on an as-needed basis) to this "survey" method. As has been pointed out in earlier feedback to that idea, it is problematic in at least one respect wrt potential performance impact. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Thu, 11 Jan 1996 15:53:23 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id PAA21719 for X-agentx-local; Thu, 11 Jan 1996 15:53:23 -0800 (PST) Received: from seymour4 (seymour4.snmp.com [192.147.142.4]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id PAA21711 for ; Thu, 11 Jan 1996 15:53:21 -0800 (PST) From: case@snmp.com Received: by seymour4 (5.61++/2.8s-SNMP ) id AA08682; Thu, 11 Jan 96 18:48:18 -0500 Date: Thu, 11 Jan 96 18:48:18 -0500 Message-Id: <9601112348.AA08682@seymour4> To: daniele@zk3.dec.com Subject: Re: PDUs, proto-ops, and principles Cc: agentx@fv.com >Hi Jeff, hi mike >I'm not sure what you mean by 'partial instance', is it the ability >to register a row without registering all columnar objects in the >row? Or is it simply an object plus some-but-not-all the instance portion? the latter ... in an embedded system (hi john s.) you are doing an implementation of rfc1516 (repeater mib) where the index is variable.group.port and you want subagent 1 to register for variable.1.* and subagent 2 to register for variable.2.*, etc >If the latter, would you agree that registering a single oid accomplishes >all of these (given an oid carries an assumed range)? you note correctly that an object is a subtree as is a partial instance is a subtree and that a fully qualified instance is [sort of] a subtree i think there are some subtle differences about the meaning of "next" between fully qualified instance and the rest i'll also coattail on your observation that a range registration can always be translated into a group of subtree registrations but it may, in the worst case (but very atypical) require on the O(4B) of them to do so >Is 'registration by single oid' viable for everyone? Anyone? note also that if you register a subtree that contains multiple objects that it precludes keeping track of the variable type and access clause in the master agent ... these must be kept down in the subagents >> single or multiple registrations and deregistrations during >> the life of a subagent >This strikes me as a general requirement. i agree ... market pressures caused us to add it to EMANATE because we didn't have it ... the gross but not overly gross workaround if you don't have this capability is to do a disconnect and a reconnect of the subagent (distinction between the life of the connection and the life of the subagent) >> overlapping or disjoint registrations > >This too. we agree, but bob is wanting us to use existing specs ... can ANY of the ones that harmen reviewed do it? >I don't mean to rathole about overlapping registration. If it's >the concensus of the group that agentx shouldn't allow it, so be it. >But it seems like a real-world requirement to me. absolutely >Off to buy more snow shovels... i hope you weather the upcoming storm ok regards, jdc   Delivery-Date: Thu, 11 Jan 1996 17:21:43 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id RAA12782 for X-agentx-local; Thu, 11 Jan 1996 17:21:43 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id RAA12765 for ; Thu, 11 Jan 1996 17:21:39 -0800 (PST) Received: by dorothy.peer.com (4.1/SMI-4.1) id AA03722; Thu, 11 Jan 96 17:21:35 PST Date: Thu, 11 Jan 96 17:21:35 PST From: randy@peer.com (Randy Presuhn) Message-Id: <9601120121.AA03722@dorothy.peer.com> To: agentx@fv.com Subject: Re: PDUs, proto-ops, and principles Hi - > From: case@snmp.com > Date: Thu, 11 Jan 96 18:48:18 -0500 > To: daniele@zk3.dec.com > Subject: Re: PDUs, proto-ops, and principles > Cc: agentx@fv.com ... > you note correctly that an object is a subtree as is a partial instance is > a subtree and that a fully qualified instance is [sort of] a subtree > > i think there are some subtle differences about the meaning of "next" > between fully qualified instance and the rest > > i'll also coattail on your observation that a range registration can always > be translated into a group of subtree registrations but it may, in the > worst case (but very atypical) require on the O(4B) of them to do so A variant on this is "row" registration or even table "slice" registration. At the protocol level, this is pretty easy to represent using something roughly like: SubIdType ::= INTEGER (0 .. MAX) Range ::= SEQUENCE { lower-bound SubIdType, extent SubIdType } RegionSpecifier ::= SEQUENCE OF Range This representation allows very efficient registration of a tree or a family of trees, ranging from a set of groups to a scalar to a table to a row to a set of rows or a set of columns. The downside is that defining a MIB of the registration information is awkward due to SMI limitations. Translating an SMUX or DPI registration request to this form is simple. > note also that if you register a subtree that contains multiple objects > that it precludes keeping track of the variable type and access clause in > the master agent ... these must be kept down in the subagents True, but probably not a big loss, since this would represent a win only for processing invalid SET attempts. ... > >> overlapping or disjoint registrations > > > >This too. > > we agree, but bob is wanting us to use existing specs ... can ANY of the > ones that harmen reviewed do it? ... SMUX allows both. For overlapping registrations, the intended interaction of subtree priority with the "subtree mounting effect" described in RFC 1227 clause 3.1.1 is unclear. Practical experience suggests that the "subtree mounting effect" should NOT be given preference over registration priority. The deciding case is where a table is split across multiple subagents, with one of them taking resposibility for requests for the creation of new rows in that table. -------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy@peer.com USA --------------------------------------------------------------------------   Delivery-Date: Thu, 11 Jan 1996 17:34:56 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id RAA16151 for X-agentx-local; Thu, 11 Jan 1996 17:34:55 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id RAA16145 for ; Thu, 11 Jan 1996 17:34:54 -0800 (PST) Received: by dorothy.peer.com (4.1/SMI-4.1) id AA04075; Thu, 11 Jan 96 17:34:50 PST Date: Thu, 11 Jan 96 17:34:50 PST From: randy@peer.com (Randy Presuhn) Message-Id: <9601120134.AA04075@dorothy.peer.com> To: agentx@fv.com Subject: Re: PDUs, proto-ops, and principles Hi - | From: ralex@world.std.com (Aleksey Y Romanov) | Subject: Re: PDUs, proto-ops, and principles | To: case@snmp.com | Date: Wed, 10 Jan 1996 23:17:35 -0500 (EST) | Cc: agentx@fv.com | | > messages that we have barely even begun to discuss: | > registration options | > by objects | > by partial instances | > by complete instances | > by subtrees | > by ranges | > by contexts/naming scopes/etc | | IMHO, subtrees and ranges are more than enough while being simpliest | things to implement. I favored ranges but had changed my mind recently | in favor of sub-trees - it adds unsignificant overhead, however, substantially | simplifies processing in case of overlapped sub-tress (e.g. when different | rows in table have to be handled by different sub-agents). I think a hybrid approach (ammounting to regular expressions describing families of subtrees) would be optimal, but am willing to fall back to subtrees. It is essential that a subagent be able to specify at registration time which "entity" a tree (family) belongs to. It's possible to use SMUX to represent multiple logical entities in a single process, but the protocol forces the use of a separate association for each logical entity. This increases resource consumption and adds no value. An entity identifier of some kind should be present on both registration and operation traffic, with provision for a default (contextLocalEntity "") value for the many many subagents that won't care. I'd like to hear whether anyone thinks there is a requirement to be able to wildcard entity identification on registration requests. ... | > subagent-to-subagent communications | | There is very simple solution, which is not absolute but can satisfy | 99.9% of requirements. Let us suppose that we have tightly coupled, | loosely coupled and remotely coupled sub-agents. It is really trivial | to allow for piece of software mounted as tightly coupled | sub-agent to take over master-agent (on time-to-time basis) or | thread in master-agent (on the permanent basis) and thus gain access | to all other sub-agents. As I said this solution is not an absolute one, | however, it seem to provide for all practical needs and very cheap. ... | What about access control policies ? ... I'm concerned too that the access control work to date has not taken this into account. (The RMON-1 work uses one possible approach, though SNMPv1-centric in its formulation.) -------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy@peer.com USA --------------------------------------------------------------------------   Delivery-Date: Thu, 11 Jan 1996 20:32:02 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id UAA27428 for X-agentx-local; Thu, 11 Jan 1996 20:32:00 -0800 (PST) Received: from europe.std.com (europe.std.com [192.74.137.10]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id UAA27417 for ; Thu, 11 Jan 1996 20:31:59 -0800 (PST) Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id XAA10516; Thu, 11 Jan 1996 23:32:05 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA22361; Thu, 11 Jan 1996 23:28:16 -0500 From: ralex@world.std.com (Aleksey Y Romanov) Message-Id: <199601120428.AA22361@world.std.com> Subject: Re: PDUs, proto-ops, and principles To: randy@peer.com (Randy Presuhn) Date: Thu, 11 Jan 1996 23:28:15 -0500 (EST) Cc: agentx@fv.com In-Reply-To: <9601120134.AA04075@dorothy.peer.com> from "Randy Presuhn" at Jan 11, 96 05:34:50 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > | IMHO, subtrees and ranges are more than enough while being simpliest > | things to implement. I favored ranges but had changed my mind recently > | in favor of sub-trees - it adds unsignificant overhead, however, substantially > | simplifies processing in case of overlapped sub-tress (e.g. when different > | rows in table have to be handled by different sub-agents). > > I think a hybrid approach (ammounting to regular expressions describing > families of subtrees) would be optimal, but am willing to fall back to > subtrees. > > It is essential that a subagent be able to specify at registration time > which "entity" a tree (family) belongs to. It's possible to use SMUX > to represent multiple logical entities in a single process, but the > protocol forces the use of a separate association for each logical > entity. This increases resource consumption and adds no value. An > entity identifier of some kind should be present on both registration > and operation traffic, with provision for a default (contextLocalEntity > "") value for the many many subagents that won't care. > > I'd like to hear whether anyone thinks there is a requirement to be able > to wildcard entity identification on registration requests. I do think that when we are talking about registration we have to put clarity of the process ahead of effectiveness - it is not going to be executed too often. > Randy Presuhn PEER Networks, a division of BMC Software, Inc. Aleksey   Delivery-Date: Thu, 11 Jan 1996 23:14:05 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id XAA04942 for X-agentx-local; Thu, 11 Jan 1996 23:14:04 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id XAA04935 for ; Thu, 11 Jan 1996 23:14:03 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA08888 for agentx@fv.com; Fri, 12 Jan 96 02:11:33 -0500 Date: Fri, 12 Jan 1996 02:10:47 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA13598; Fri, 12 Jan 1996 02:10:47 -0500 Message-Id: <9601120710.AA13598@nips.acec.com> To: daniele@zk3.dec.com Subject: Re: PDUs, proto-ops, and principles Cc: agentx@fv.com > Date: Thu, 11 Jan 96 18:19:24 -0500 > From: Mike Daniele Hi Mike, [Speaking mostly as wg chair...] > I agree (with several others, it seems) that we've got the cart > before the horse to some extent. I think it would be a good > idea to focus on getting concensus for a general architecture and > set of functions for agentx. For the moment, I think we've got rough consensus on substantial portions of both based upon the solution space as defined by what we know of SMUX, DPI, eSNMP, and (to lesser extents) UT_SNMP, OAA, and EMANATE. The "general architecture" that emerges from that is moderately clear; the "set of functions" is very clear. (I--as a wanna-be technical contributor--was the most (only?) guilty party in digressing from the general architecture... by trying to build agentx on top of SNMP itself...while not intending at all to waver from the common set of functions... I am ending that digression herewith!) > Along the way hopefully current requirements will be fleshed out. Yes, they will be (although "fleshed out" is probably going to be too kind-and-gentle of a description in retrospect! :-). > (Please feel free to substitute 'picture', or 'system design' or > 'division of labor' for the word 'architecture' above, if it makes > you queasy :-) I do like "division of labor". > I haven't jumped in with more about eSNMP (as promised) because, > as I alluded to previously, it's not important now. Hmmm. I disagree, and will try to get you back on track (:-) in the near future! > You're the chair, and I certainly agree that we have to do > something other than argue about requirements. But... > > Since the notion of registration is so key to agentx, > that's probably a good place to start. Ok. But there is a lot to be said for tackling some lower priority (no pun intended) issues first...(there are some more or less non-technical purposes that are served too). And, above all, there is no reason not to root that discussion in the examples provided by the solution space protocols (despite my own bad example to the contrary!). > Specifically, wrt Jeff's posting: > > >there are far more important considerations than the encoding of the > >messages that we have barely even begun to discuss: > > registration options > > by objects > > by partial instances > > by complete instances > > by subtrees > > by ranges > > Hi Jeff, > > I'm not sure what you mean by 'partial instance', is it the ability > to register a row without registering all columnar objects in the > row? Or is it simply an object plus some-but-not-all the instance portion? > > If the latter, would you agree that registering a single oid accomplishes > all of these (given an oid carries an assumed range)? I note that Jeff has already answered this and I interpreted his answer to be generally affirmative, with some caveats. > Is 'registration by single oid' viable for everyone? Anyone? It certainly is for me...although I am of the opinion that the single OID registration operation is only necessary wrt instance- level registration...and a much simpler and more efficient mechanism exists (implicitly at least) in the reference protocols (i.e., MIB registration at "open" time). > > single or multiple registrations and deregistrations during > > the life of a subagent > > This strikes me as a general requirement. Sure...but, again, I only see the necessity for this applying to instance-level registration. > > overlapping or disjoint registrations > > This too. Agreed. > Bob, wrt priority: > > >I would really like to see an answer to that question from the > >proponents of a priority mechanism. > > I am not a proponent of a priority mechanism, even tho eSNMP has one. > So I'm not going to defend it :-) I will post a separate summary on this issue...the bottom line is that it appears that proponents of including a priority mechanism have made a more compelling case than its oponents have, IMHO. Ergo, unless and until further evidence arises against this mechanism, we should plan on agentx having a priority mechanism similar to that found in the reference protocols. Semantic details remain to be ironed out. > I am of the opinion that overlapping registrations are a reality > of life, and agentx needs to address it. As you note below, the issue of overlapping registrations is logically distinct from the issue of an explicit priority mechanism. I have never doubted the need for the former; and I have yielded on the latter. > (Note, 'addressing it' could be as simple as something like > > overlapping regs are accepted > > when evaluating how to distribute a management request, > the system agent's algorithm is 'most fully qualified > registration wins' > > the response to a registration request indicates > whether or not the component agent is currently most > fully qualified. but subsequent registrations could alter > that (transparently) > > there are no priorities associated with registration Right. > I don't mean to rathole about overlapping registration. If it's > the concensus of the group that agentx shouldn't allow it, so be it. > But it seems like a real-world requirement to me. >From what I've seen so far, I'd say that the consensus is clearly that overlapping registrations must be supported. > Off to buy more snow shovels... Good luck...don't bother visiting the hardware stores in my neck of the woods! I've been puttin in 3 to 4 hours a night shoveling, since Monday...saves me the 30-60 minutes I normally exercise and is actually more enjoyable...but I must admit that I'm kinda feeling it in the morning and am looking upon the imminent next snowload with a little less enthusiasm! Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Thu, 11 Jan 1996 23:30:14 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id XAA08302 for X-agentx-local; Thu, 11 Jan 1996 23:30:13 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id XAA08297 for ; Thu, 11 Jan 1996 23:30:12 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA11377 for agentx@fv.com; Fri, 12 Jan 96 02:29:01 -0500 Date: Fri, 12 Jan 1996 02:28:15 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA13741; Fri, 12 Jan 1996 02:28:15 -0500 Message-Id: <9601120728.AA13741@nips.acec.com> To: ralex@world.std.com Subject: Re: PDUs, proto-ops, and principles Cc: agentx@fv.com > From: ralex@world.std.com (Aleksey Y Romanov) > Date: Thu, 11 Jan 1996 23:28:15 -0500 (EST) Hi Aleksey, [Speaking as a technical contributor...] <...> > > = Randy Presuhn > > I'd like to hear whether anyone thinks there is a requirement > > to be able to wildcard entity identification on registration > > requests. Only implicitly (i.e., no explicit wildcard function). If you mean something special by "entity identification" in this context, you will need to clue me in. > I do think that when we are talking about registration we have to put > clarity of the process ahead of effectiveness - it is not going to be > executed too often. I agree 100%. The bulk of registration could/should (IMHO) happen at one time...via MIB file at "open" time...with only instance-level registration happening dynamically thereafter. Even if you don't buy into the particulars of that opinion, Aleksey's point is still valid in the most general case. And btw, I read a nice comment by Phil Karn on the ipsec list (I think it was) the other day...it went something like: "Always optimize for the most common case." Now maybe that's a well known aphorism...it's certainly something I've always tried to practice...even before I recognized it...I see it as applying to this and several other issues we do or will have on the agentx table. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Fri, 12 Jan 1996 07:19:45 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id HAA05376 for X-agentx-local; Fri, 12 Jan 1996 07:19:44 -0800 (PST) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id HAA05368 for ; Fri, 12 Jan 1996 07:19:43 -0800 (PST) Received: from flume.zk3.dec.com by mail12.digital.com; (5.65v3.2/1.0/WV) id AA17395; Fri, 12 Jan 1996 10:14:30 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA09618; Fri, 12 Jan 1996 10:14:29 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA10247; Fri, 12 Jan 1996 10:14:53 -0500 Message-Id: <9601121514.AA10247@bernie.zk3.dec.com> To: natale@acec.com (Bob Natale) Cc: agentx@fv.com Subject: Re: PDUs, proto-ops, and principles In-Reply-To: Your message of "Fri, 12 Jan 96 02:10:47 EST." <9601120710.AA13598@nips.acec.com> Date: Fri, 12 Jan 96 10:14:52 -0500 From: Mike Daniele X-Mts: smtp Hi Bob, >It certainly is for me...although I am of the opinion that the >single OID registration operation is only necessary wrt instance- >level registration...and a much simpler and more efficient mechanism >exists (implicitly at least) in the reference protocols (i.e., MIB >registration at "open" time). I'm guilty of using the term 'single oid registration' ambiguously. I'm not suggesting that a component agent needs to register every object explicitly. I'm suggesting that if a registration is expressed by a single oid, then the system agent does not need to make any distintion between 'object', 'partial instance', 'complete instance', 'subtree', or 'range'. I register Host MIB by registering the single oid "mib-2.25". I register instance 33 of ifDescr by registering the single oid "ifDescr.33". This is how eSNMP works, and it makes for an easy to understand registration/dispatching policy. The potential drawback would be that 'row registration' would require registering each columnar object+instance. (But this would be eliminated if agentx has special handling for row registration, including assignment/management of row indexes.) Again, the 'division of labor' we used is that the system agent does not attach any meaning to the registered oid. It is 'MIB-ignorant'. >> > single or multiple registrations and deregistrations during >> > the life of a subagent >> >> This strikes me as a general requirement. >Sure...but, again, I only see the necessity for this applying >to instance-level registration. I don't understand this. Multiple registrations have nothing to do with instances in particular, they have to do with what MIB spaces you're implementing in a particular component agent. A component agent may wish to perform both the registrations I mentioned above. (I have a feeling I'm missing your point.) >Good luck...don't bother visiting the hardware stores in my >neck of the woods! I've been puttin in 3 to 4 hours a night >shoveling, since Monday...saves me the 30-60 minutes I normally >exercise and is actually more enjoyable...but I must admit >that I'm kinda feeling it in the morning and am looking upon >the imminent next snowload with a little less enthusiasm! I also enjoy shoveling snow! It's good exercise, and peaceful. But I share your lack of enthusiasm at this point. :-) Regards, Mike   Delivery-Date: Fri, 12 Jan 1996 09:22:50 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id JAA06114 for X-agentx-local; Fri, 12 Jan 1996 09:22:46 -0800 (PST) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id JAA06109 for ; Fri, 12 Jan 1996 09:22:45 -0800 (PST) Received: from flume.zk3.dec.com by mail12.digital.com; (5.65v3.2/1.0/WV) id AA02605; Fri, 12 Jan 1996 12:13:23 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA28339; Fri, 12 Jan 1996 12:13:22 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA10314; Fri, 12 Jan 1996 12:13:48 -0500 Message-Id: <9601121713.AA10314@bernie.zk3.dec.com> To: case@snmp.com Cc: agentx@fv.com Subject: Re: PDUs, proto-ops, and principles In-Reply-To: Your message of "Thu, 11 Jan 96 18:48:18 EST." <9601112348.AA08682@seymour4> Date: Fri, 12 Jan 96 12:13:47 -0500 From: Mike Daniele X-Mts: smtp Hi Jeff, >note also that if you register a subtree that contains multiple objects >that it precludes keeping track of the variable type and access clause in >the master agent ... these must be kept down in the subagents Yup. I view that as the correct division of labor. >i think there are some subtle differences about the meaning of "next" >between fully qualified instance and the rest Nothing that can't be handled fairly simply by the master agent (I think :-) But our model is o the system agent finds the 'best' registration for each requested variable o an eSNMP request is sent to any component agent that registered one of these 'best' registrations o the request sent to a particular component agent contains all requested variables, and only those requested variables, for which the component agent was deemed 'best' o each requested oid is passed in the request along with the registered oid that the master agent used to decide the component agent was 'best' (i.e., the registered subtree) Given this situation, the only time fully qualified instances become problematical is if different component agents registered columns of the same conceptual row. I personally view this as an unrealistic configuration, but as you say, almost everything is 'required' by somebody. I'll also point out that in our implementation, component agent developers do NOT implement the protocol. There is a library of code we supply to do most of the sorting out required on the component agent side. [More to Bob N now...] I think it is a reasonable to assume this is the case in general, and that therefore agentx should be more concerned with efficiency [end to end response time for completing a request] than with simplicity *for end users*. >>> overlapping or disjoint registrations >> >>This too. >we agree, but bob is wanting us to use existing specs ... can ANY of the >ones that harmen reviewed do it? I think so, but only SMUX discusses the consequences (or what Randy termed the conflict resolution policy). I think eSNMP and EMANATE can be considered reference implementations too :-) >i hope you weather the upcoming storm ok Thanks, I hope we all do... (Oh, you were talking about snow? :-) Regards, Mike   Delivery-Date: Fri, 12 Jan 1996 09:38:59 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id JAA10585 for X-agentx-local; Fri, 12 Jan 1996 09:38:58 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id JAA10580 for ; Fri, 12 Jan 1996 09:38:57 -0800 (PST) Received: by dorothy.peer.com (4.1/SMI-4.1) id AA11723; Fri, 12 Jan 96 09:38:51 PST Date: Fri, 12 Jan 96 09:38:51 PST From: randy@peer.com (Randy Presuhn) Message-Id: <9601121738.AA11723@dorothy.peer.com> To: agentx@fv.com Subject: Re: PDUs, proto-ops, and principles Hi - |Date: Fri, 12 Jan 1996 02:28:15 -0500 |From: natale@acec.com (Bob Natale) |To: ralex@world.std.com |Subject: Re: PDUs, proto-ops, and principles |Cc: agentx@fv.com | |> From: ralex@world.std.com (Aleksey Y Romanov) |> Date: Thu, 11 Jan 1996 23:28:15 -0500 (EST) ... |> > = Randy Presuhn |> > I'd like to hear whether anyone thinks there is a requirement |> > to be able to wildcard entity identification on registration |> > requests. | |Only implicitly (i.e., no explicit wildcard function). | |If you mean something special by "entity identification" in this |context, you will need to clue me in. I was thinking about interactions between an entity mib and resource managers in things like stackable hubs and systems supporting hot insertion. In such an environment, a resource manager might want to take responsibility for all instances of a particular class (as some number of different entities, as required by the hub mib). If we allow operations on these entites only when the resource is actually in place, then it is sufficient to have the resource manager do individual, entity-by-entity registration of the relevant mib regions. If, on the other hand, we permit provisioning of these things, it is necessary to allow operation requests affecting a mib region of a particular entity before the resource manager has found out about it. I'm not convinced yet that this is a "must have" requirement. Perhaps Jon has some thoughts on this... |> I do think that when we are talking about registration we have to put |> clarity of the process ahead of effectiveness - it is not going to be |> executed too often. | |I agree 100%. The bulk of registration could/should (IMHO) |happen at one time...via MIB file at "open" time...with only |instance-level registration happening dynamically thereafter. I assume you're including row-level or table slice (not all index values specified) registration in this. To permit only leaf-node registration after initialization is extremely suboptimal for multiple index tables implemented through multiple subagents. I don't want to get into a diminishing returns situation; but these cases are important for products out in the field today. I don't want to take any technological steps backwards! |Even if you don't buy into the particulars of that opinion, |Aleksey's point is still valid in the most general case. Agreed. |And btw, I read a nice comment by Phil Karn on the ipsec |list (I think it was) the other day...it went something like: |"Always optimize for the most common case." Now maybe that's |a well known aphorism...it's certainly something I've always |tried to practice...even before I recognized it...I see it |as applying to this and several other issues we do or will |have on the agentx table. I'm all for ensuring that the common case is highly optimized and not going crazy over oddball situation. However, we must also be careful to not get into a situation where less common but still commercially significant cases are highly suboptimal, especially if improving the performance for these would not adversely impact the most common cases. |Cordially, | |BobN |------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ |Bob Natale | ACE*COMM | 301-258-9850 [v] |Director | 209 Perry Pkwy | 301-921-0434 [f] |Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com |----------------- NetPlus (r) "FCAPS" Applications ------------- -------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy@peer.com USA --------------------------------------------------------------------------   Delivery-Date: Fri, 12 Jan 1996 09:45:41 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id JAA12369 for X-agentx-local; Fri, 12 Jan 1996 09:45:41 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id JAA12363 for ; Fri, 12 Jan 1996 09:45:40 -0800 (PST) Received: by dorothy.peer.com (4.1/SMI-4.1) id AA11774; Fri, 12 Jan 96 09:45:33 PST Date: Fri, 12 Jan 96 09:45:33 PST From: randy@peer.com (Randy Presuhn) Message-Id: <9601121745.AA11774@dorothy.peer.com> To: agentx@fv.com Subject: Re: PDUs, proto-ops, and principles Hi - > To: natale@acec.com (Bob Natale) > Cc: agentx@fv.com > Subject: Re: PDUs, proto-ops, and principles > Date: Fri, 12 Jan 96 10:14:52 -0500 > From: Mike Daniele ... > I'm suggesting that if a registration is expressed by a single > oid, then the system agent does not need to make any distintion > between 'object', 'partial instance', 'complete instance', 'subtree', > or 'range'. YES! Agreed! This simplifies things greatly. ... > The potential drawback would be that 'row registration' would > require registering each columnar object+instance. (But this would > be eliminated if agentx has special handling for row registration, > including assignment/management of row indexes.) The "regular expresion" representation of registration requests covers this case as well, without requiring the master to know the semantics of the substructure. > Again, the 'division of labor' we used is that the system agent > does not attach any meaning to the registered oid. It is 'MIB-ignorant'. ... YES! Otherwise it is necessary to talk about representing MIB semantics on the agent/subagent registration dialog. Doable, but not pretty. -------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy@peer.com USA --------------------------------------------------------------------------   Delivery-Date: Fri, 12 Jan 1996 10:04:18 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id KAA17057 for X-agentx-local; Fri, 12 Jan 1996 10:04:18 -0800 (PST) Received: from seymour4 (seymour4.snmp.com [192.147.142.4]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id KAA17046 for ; Fri, 12 Jan 1996 10:04:15 -0800 (PST) From: case@snmp.com Received: by seymour4 (5.61++/2.8s-SNMP ) id AA09487; Fri, 12 Jan 96 12:51:07 -0500 Date: Fri, 12 Jan 96 12:51:07 -0500 Message-Id: <9601121751.AA09487@seymour4> To: daniele@zk3.dec.com Subject: Re: PDUs, proto-ops, and principles Cc: agentx@fv.com >>i think there are some subtle differences about the meaning of "next" >>between fully qualified instance and the rest >Nothing that can't be handled fairly simply by the master agent >(I think :-) > >But our model is > > o the system agent finds the 'best' registration for > each requested variable > > o an eSNMP request is sent to any component agent that > registered one of these 'best' registrations > > o the request sent to a particular component agent > contains all requested variables, and only those > requested variables, for which the component agent > was deemed 'best' > > o each requested oid is passed in the request along > with the registered oid that the master agent used > to decide the component agent was 'best' > (i.e., the registered subtree) > >Given this situation, the only time fully qualified instances >become problematical is if different component agents registered >columns of the same conceptual row. I personally view this >as an unrealistic configuration, but as you say, almost everything >is 'required' by somebody. we agree ... it all has to do with the definition of "best" ... and i didn't say it was a problem ... it just requires some care ... for example, one subtle difference is that when processing getnext, and are tripping down through dispatch table entries of subtrees, the definition of "best" changes depending upon whether the one you are looking at is a fully qualified instance or not ... if you fail to recognize this subtle difference, you will exhibit less than optimal behavior and routinely make subagent calls that are unproductive and unnecessary when processing sequences of management station queries that are often encountered in practice we agree that it is *REAL HARD* to have different subagent register for different columns of the same conceptual row ... i pointed this out in the meeting ... but at the meeting went on to say that it is survivable for readonly tables, but that read-create tables are really "impossible" under these implementation conditions >I'll also point out that in our implementation, component agent developers >do NOT implement the protocol. There is a library of code we supply >to do most of the sorting out required on the component agent side. ditto ... all of this is hidden from the developer in EMANATE (unless they are a real sicko and want to relentlessly stare at library source code with their brothers and cousins) regards, jdc   Delivery-Date: Fri, 12 Jan 1996 10:25:27 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id KAA22632 for X-agentx-local; Fri, 12 Jan 1996 10:25:27 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id KAA22627 for ; Fri, 12 Jan 1996 10:25:26 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA25001 for agentx@fv.com; Fri, 12 Jan 96 13:25:31 -0500 Date: Fri, 12 Jan 1996 13:24:43 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA20030; Fri, 12 Jan 1996 13:24:43 -0500 Message-Id: <9601121824.AA20030@nips.acec.com> To: agentx@fv.com Subject: A check on some consensus points Hi everyone, [Speaking as wg chair...] I'd like to take this opportunity to summarize some apparent points of consensus and solicit any feedback to the contrary: 1. Agentx should be built on the foundation of the major commonalities found among the reference protocols... this includes, for example: 2. A set of protocol-specific PDUs (i.e., not SNMP itself); 3. A protocol-specific (and perhaps PDU-specific) encoding scheme (i.e., not ASN.1/BER); 4. A priority registration mechanism...some more background on this one: - I think there have been several postings with strong logical evidence that the priority mechanism simply plays no rational role vis-a-vis independent component agent development; however... - while strong, they definitely are not conclusive; and - the evidence in favor of the use of priority among the reference protocols is clear; and - the cost of including it is (most likely) small; and - the strength of the sentiment for priority among its proponents is compelling; therefore - we should retain the feature. 5. There are probably others that could be included in the list at this time, but I've mentioned the above explicitly because they were all the subject of some extended discussion that can now (I hope) be closed. I read the net effect of the above list as validating the strategy of focusing on the solution space as defined by the reference protocols...and, yes, that includes all deployed implementations about which we can get sufficiently detailed info in a timely manner (and specifically includes SMUX, DPI, UT_SNMP, OAA, eSNMP, and EMANATE...with a continuing open invitation for similar input from other implementors...quickly, please!). The major threat I see on the horizon (or maybe at the doorstep by now) is a lurking expectation that we must support *every* deployed feature of every implementation. However, we must bear in mind that we probably cannot produce a successful agentx protocol if it is a de facto requirement that we must support every detail now found in the deployed products; I am hopeful we will produce the leanest possible protocol to accomplish the requisite functionality. I am sure we can count on each other to recognize and accept the necessary compromises, if and when they become evident. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Fri, 12 Jan 1996 10:34:12 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id KAA24881 for X-agentx-local; Fri, 12 Jan 1996 10:34:12 -0800 (PST) Received: from seymour4 (seymour4.snmp.com [192.147.142.4]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id KAA24866 for ; Fri, 12 Jan 1996 10:34:10 -0800 (PST) From: case@snmp.com Received: by seymour4 (5.61++/2.8s-SNMP ) id AA09559; Fri, 12 Jan 96 13:27:49 -0500 Date: Fri, 12 Jan 96 13:27:49 -0500 Message-Id: <9601121827.AA09559@seymour4> To: agentx@fv.com Subject: Re: PDUs, proto-ops, and principles >> Is 'registration by single oid' viable for everyone? Anyone? >It certainly is for me...although I am of the opinion that the >single OID registration operation is only necessary wrt instance- >level registration...and a much simpler and more efficient mechanism >exists (implicitly at least) in the reference protocols (i.e., MIB >registration at "open" time). i don't follow this, perhaps i don't understand > > > single or multiple registrations and deregistrations during > > > the life of a subagent > > > > This strikes me as a general requirement. > Sure...but, again, I only see the necessity for this applying > to instance-level registration. this either, i.e., the interaction with instance-level registration again, perhaps i am confused? regards, jdc   Delivery-Date: Fri, 12 Jan 1996 10:49:50 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id KAA28594 for X-agentx-local; Fri, 12 Jan 1996 10:49:50 -0800 (PST) Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by zloty.fv.com (8.7.3/8.7.3) with ESMTP id KAA28577 for ; Fri, 12 Jan 1996 10:49:47 -0800 (PST) Received: from world.std.com by relay1.UU.NET with SMTP id QQzyfr10183; Fri, 12 Jan 1996 13:47:50 -0500 (EST) Received: by world.std.com (5.65c/Spike-2.0) id AA11675; Fri, 12 Jan 1996 13:25:47 -0500 From: ralex@world.std.com (Aleksey Y Romanov) Message-Id: <199601121825.AA11675@world.std.com> Subject: Re: PDUs, proto-ops, and principles To: daniele@zk3.dec.com (Mike Daniele) Date: Fri, 12 Jan 1996 13:25:47 -0500 (EST) Cc: agentx@fv.com In-Reply-To: <9601121514.AA10247@bernie.zk3.dec.com> from "Mike Daniele" at Jan 12, 96 10:14:52 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > I register Host MIB by registering the single oid "mib-2.25". > I register instance 33 of ifDescr by registering the single > oid "ifDescr.33". > > This is how eSNMP works, and it makes for an easy to understand > registration/dispatching policy. > > The potential drawback would be that 'row registration' would > require registering each columnar object+instance. (But this would > be eliminated if agentx has special handling for row registration, > including assignment/management of row indexes.) Why any special handling would be required and why master agent should know about particulars of any tables ? Simple example: We have five sub-agents handling 5 different kinds of interfaces. There is nor ordering established between ifIndex values and sub-agents. E.g. ifIndex 1 can be handled by sub-agent 3 and ifIndex 2 by sub-agent 1. Each sub-agent registered ifTable with master agent. Let us look how request for something under ifTable sub-tree will be processed. Get: Call each sub-agent in turn: once one of them would return 'noError' or 'genErr' stop processing and returned data as a result of operation, if all of them would return 'noSuchObject' result of operation is 'noSuchObject', if some of them will return 'noSuchObject' and some 'noSuchInstance' result is 'noSuchInstance'. Get-Next/Bulk: Call each sub-agent in turn: data returned with lowest name will be used as result of operation, if any of them returns 'genErr' - 'genErr' is a result of operation, otherwise look for next sub-tree. Set: Two additional intermediate error-conditions to be defined: say 'noSuchObject' - means required object is not found in sub-agent and 'noSuchInstance' - means creation of required instance is not supported by particular sub-agent but may be supported by others ('noCreation' should be restricted to the cases when sub-agent supports required instance but could not create it, 'notWritable' should be also reserved to indicate hits into read-only instances and objects). Call each sub-agent in turn: once one of them would return anything else except 'noSuchObject'/'noSuchInstance' - it is a result of operation, if all of them returned 'noSuchObject' then result is 'notWritable', if all of them returned mix of 'noSuchObject' and 'noSuchInstance' result is 'noCreation'. And this is it, folks. > Mike Aleksey   Delivery-Date: Fri, 12 Jan 1996 11:27:43 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id LAA08683 for X-agentx-local; Fri, 12 Jan 1996 11:27:42 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id LAA08679 for ; Fri, 12 Jan 1996 11:27:41 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA02432 for agentx@fv.com; Fri, 12 Jan 96 14:27:40 -0500 Date: Fri, 12 Jan 1996 14:26:53 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA21007; Fri, 12 Jan 1996 14:26:53 -0500 Message-Id: <9601121926.AA21007@nips.acec.com> To: case@snmp.com Subject: A clarification on a non-goal of agentx Cc: agentx@fv.com > From: case@snmp.com > Date: Thu, 11 Jan 96 11:14:08 -0500 Hi Jeff and everyone else, [Speaking as wg chair...] <...> > if you hope for agentx to be able to replace EMANATE, I know that you are notorious for your wit (a major positive quality I wish I had) and I can be very humor-impaired at times (and am not accomplished enough to be notorious for anything...well, except maybe long-windedness!)...but assuming you meant the above as a serious statement, please let me make this very clear: I certainly hope we all share the view that agentx should contribute to the success of "whole product" solutions such as EMANATE, OAA, and similarly excellent offerings from Peer, Epilogue, IBM, DEC, and many others (no omissions intended). It is definitely a non-goal to "replace" them. The agentx role is to provide a standard protocol for the "intra-agent" portion only...where intra-agent refers to the system agent <-> component agent relationship. And the primary purpose of this goal is to enable component agents to be developed without (significant) regard to the particular system agent they will combine with to form the extensible agent environment on any given managed system. Is there any strong disagreement with or substantial refinement of that set of statements that anyone would care to make? Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Fri, 12 Jan 1996 12:45:50 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id MAA29312 for X-agentx-local; Fri, 12 Jan 1996 12:45:50 -0800 (PST) Received: from epilogue.com (quern.epilogue.com [128.224.1.136]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id MAA29275 for ; Fri, 12 Jan 1996 12:45:35 -0800 (PST) Received: from dab.gate.epilogue.com with DMSP Date: Fri, 12 Jan 96 13:38:35 -0700 From: David Bridgham To: agentx@fv.com In-reply-to: "natale@acec.com"'s message of Fri, 12 Jan 1996 13:24:43 -0500 Subject: Re: A check on some consensus points Sender: dab@epilogue.com Repository: quern.epilogue.com Originating-client: gate.epilogue.com Message-ID: <9601121544.aa10212@quern.epilogue.com> I'd like to take this opportunity to summarize some apparent points of consensus and solicit any feedback to the contrary: Concensus in that I wouldn't actually block any of these if everyone were against me, not that I agree with all your points. 3. A protocol-specific (and perhaps PDU-specific) encoding scheme (i.e., not ASN.1/BER); In Envoy we chose to just use BER (though it's a customer replacable module for any customer who religiously objects to BER). Not that we like BER or ASN.1, I'd prefer fixed size fields and receiver-makes-it-right as Jeff described (unless I were feeling really crochety that day and decided on ASCII encoded s-expressions) but we could see no significant advantage to designing, implementing, debugging, and burning code space on yet another data encoding. 4. A priority registration mechanism...some more background on this one: - the evidence in favor of the use of priority among the reference protocols is clear; and Most of what I've seen is people putting it in because the earlier protocols (SMUX) did. Not because they think it's such a good idea. - the cost of including it is (most likely) small; and True. The major threat I see on the horizon (or maybe at the doorstep by now) is a lurking expectation that we must support *every* deployed feature of every implementation. I wonder how necessary this really is for us. Hopefully we all believe we can design something where the method routines don't have to change. In other words, source code compatibility where the major work is. Do we actually need binary compatibilty too? I'd argue that if any SNMP vendor feels they need to supply that, they can provide master agents to run both their old protocol and the new, agentx protocol. Any existing user knows they're running a proprietary sub-agent protocol, and the set of master agent they'll work against won't shrink unless the vendor of that proprietary solution chooses to end support. In other words, a shim between the odl and the new isn't the only way to continue binary support for the old. Dave   Delivery-Date: Fri, 12 Jan 1996 13:58:36 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id NAA18475 for X-agentx-local; Fri, 12 Jan 1996 13:58:36 -0800 (PST) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id NAA18470 for ; Fri, 12 Jan 1996 13:58:35 -0800 (PST) Received: from flume.zk3.dec.com by mail12.digital.com; (5.65v3.2/1.0/WV) id AA10827; Fri, 12 Jan 1996 16:54:24 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA12489; Fri, 12 Jan 1996 16:54:23 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA10464; Fri, 12 Jan 1996 16:54:50 -0500 Message-Id: <9601122154.AA10464@bernie.zk3.dec.com> To: ralex@world.std.com (Aleksey Y Romanov) Cc: agentx@fv.com Subject: Re: PDUs, proto-ops, and principles In-Reply-To: Your message of "Fri, 12 Jan 96 13:25:47 EST." <199601121825.AA11675@world.std.com> Date: Fri, 12 Jan 96 16:54:49 -0500 From: Mike Daniele X-Mts: smtp Hi Aleksey, >> The potential drawback would be that 'row registration' would >> require registering each columnar object+instance. (But this would >> be eliminated if agentx has special handling for row registration, >> including assignment/management of row indexes.) >Why any special handling would be required and why master agent should >know about particulars of any tables ? I was just pointing out that there is no way in our registration scheme to specify "ifTable row 6". Instead you'd have to register for ifDescr.6, ifType.6, etc. >Simple example: Your example is an interesting idea! It suggests basically o component agents don't register specific row instances, they just indicate which conceptual table they implement o the system agent broadcasts requests for objects in the table to all such component agents simultaneously, and sorts out the responses. The questions I have immediately are o how do component agents know which row they have? how is contention avoided? o does this imply in general that the system agent must permit duplicate registrations (registration by different component agents of exactly the same oid)? I don't think the reference implementations permit this (at least not without some other indicator, like priority, to break the tie). It's very convenient to have a deterministic dispatching table. o Is the overhead of the potentially huge amount of wasted agentx communication offset by any huge win? o I'm having a hard time trying to imagine how sets could work in this scheme... Regards, Mike   Delivery-Date: Fri, 12 Jan 1996 14:18:19 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id OAA23800 for X-agentx-local; Fri, 12 Jan 1996 14:18:19 -0800 (PST) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id OAA23797 for ; Fri, 12 Jan 1996 14:18:18 -0800 (PST) Received: from flume.zk3.dec.com by mail12.digital.com; (5.65v3.2/1.0/WV) id AA30062; Fri, 12 Jan 1996 17:10:09 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA15838; Fri, 12 Jan 1996 17:10:06 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA10492; Fri, 12 Jan 1996 17:10:31 -0500 Message-Id: <9601122210.AA10492@bernie.zk3.dec.com> To: case@snmp.com Cc: agentx@fv.com Subject: Re: PDUs, proto-ops, and principles In-Reply-To: Your message of "Fri, 12 Jan 96 12:51:07 EST." <9601121751.AA09487@seymour4> Date: Fri, 12 Jan 96 17:10:30 -0500 From: Mike Daniele X-Mts: smtp Hi Jeff, >>But our model is >> >> o the system agent finds the 'best' registration for >> each requested variable >> >> o an eSNMP request is sent to any component agent that >> registered one of these 'best' registrations >> >> o the request sent to a particular component agent >> contains all requested variables, and only those >> requested variables, for which the component agent >> was deemed 'best' >> >> o each requested oid is passed in the request along >> with the registered oid that the master agent used >> to decide the component agent was 'best' >> (i.e., the registered subtree) >> >>Given this situation, the only time fully qualified instances >>become problematical is if different component agents registered >>columns of the same conceptual row. I personally view this >>as an unrealistic configuration, but as you say, almost everything >>is 'required' by somebody. >we agree ... it all has to do with the definition of "best" ... and i didn't >say it was a problem ... it just requires some care ... for example, >one subtle difference is that when processing getnext, and are tripping down >through dispatch table entries of subtrees, the definition of "best" changes >depending upon whether the one you are looking at is a fully qualified instance >or not ... if you fail to recognize this subtle difference, you will exhibit >less than optimal behavior and routinely make subagent calls that are >unproductive and unnecessary when processing sequences of management station >queries that are often encountered in practice The point I was trying to make (and doing badly) was that in our scheme there is no penalty for dispatching a 'next' when the "matching" oid is a fully qualified instance. I was wrong. Point taken. Also, the description above about what oids we pass in the request is not accurate. Time for me to go home. And it's snowing... :-) Regards, Mike   Delivery-Date: Fri, 12 Jan 1996 19:42:10 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id TAA17730 for X-agentx-local; Fri, 12 Jan 1996 19:42:09 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id TAA17718 for ; Fri, 12 Jan 1996 19:42:07 -0800 (PST) Received: by dorothy.peer.com (4.1/SMI-4.1) id AA25802; Fri, 12 Jan 96 19:37:40 PST Date: Fri, 12 Jan 96 19:37:40 PST From: randy@dorothy.peer.com (Randy Presuhn) Message-Id: <9601130337.AA25802@dorothy.peer.com> To: agentx@fv.com Subject: Index Sharing Hi - I apologize in advance for the length of this contribution. I'd like to share some notes on the index sharing problem. Others have touched on the topic and I think we're getting to the point where we can address it in earnest. I consider this problem tougher than others we've talked about, but I think we can bludgeon it into submission. Customers tell me there is a market requirement for this capability. I believe them, and would like to hear what others think. Enjoy. For general background, RFC 1573 is highly recommended reading. A specific proposal for the single integer, semantic-free index assignment case appeared in the "Open Agent Architecture (OAA) Multiple Component SNMP Agent (MCSA) SNMP/MCSA/Agent (Draft)" by Bill White, et al., discussed on the DPI mailing list in Autumn of 1994. The proposal did not address the issues involved where multiple subagents need to know about a specific index value assignment, nor did it address the case where index values themselves have semantics, such as port numbers or "Johnson Indexes", nor did it deal with any index data type other than INTEGER. To understand the problem better, it is important to recognize four distinct kinds of index sharing. 1) where different rows of a table may be realized by instrumentation in different (sub)agents. ifIndex is the classic example of this. 2) where distinct tables have common indexes a) identical INDEX lists {x, y, z} == {x, y, z}, {x, y, z} is shared b) shared INDEX components {x, y, z} != {x}, {x} is shared 3) AUGMENTS relationships. At first glance, this looks like (2) but is actually more complex, due to the existence semantics of the AUGMENTS clause. 4) attributes serving as pointers or references, as in the ifStackTable or proposed entity MIB. The following requirements must be met by an ideal index sharing scheme: 1) correct syntax. index assignments must be within any syntactic constraints for the index data type. Not all indexes are INTEGER. 2) generate unique values (e.g., for creating new rows) The solution must be capable of handling requests to hand out new index values with an extremely low (preferably zero) probability of collision with existing row assignments. This requirement is problematic in cases where co-existence with arbitrary pre-existing (sub)agents is needed. 3) obtain values already allocated (to allow references) The solution must be capable of handling requests for an index value that has already been allocated, based on some agreed semantic. This is needed to maintain referential integrity of "pointer" attributes. 4) MIB-specific value semantics. The syntax alone may not be enough to permit index value generation. For example, an index may be constructed as a "Johnson Index" or correspond to things like processID or physical location 5) value allocation notification (e.g., for AUGMENTS) When a value is allocated, subagents responsible for AUGMENTS portions need to be informed of the allocation in order to comply with the existance semantics of the AUGMENTS clause. We may decide that this capability is overkill. The following definitions appear to be useful for all the various models of how shared indexing might be handled: index users - entities which need to know about specific index values. For example, a subagent registering a specific row of a table needs to know what index value to use. Another example is the instrumentation for an attribute serving as a pointer to a related entity. specific index allocator - the entity responsible for handling the assignment of new values for a particular index to index users; the entity designated to service requests for a particular index generic index coordinator - an entity responsible for routing indexing requests to a responsible specific index manager Different implementation strategies assign these roles to subagents, a master agent, logic embedded in common code, or separate processes. Which of these makes the most sense will depend on the available communication mechanisms, the semantics of the indexes themselves, and the need to support legacy software. Disregarding the choice of underlying implementation mechanism, the generic services appear to be: - coordination responsibility - take responsibility for a particular index - identify entity responsible for an index - relinquish responsibility for a particular index - allocation notification subscription and dispatch - index allocation - allocate a unique index value (meeting semantic parameters) - determine index value (meeting semantic parameters) - deallocate an index value In a specific implementation, some of these services may in effect be hard-coded. For example, for an index realized as a direct mapping onto physical port numbers, the model and services are mapped as follows: - the index users are the various (sub)agents; - the specific index manager is the algorithm (index=port) realized in all code using this index (index allocation service is hard-coded); - the generic index manager is the decision to put this code in all these entities (coordination responsibility service is hard-coded). The following general approaches have been suggested: - put everything into proxies - solve for specific cases, e.g., ifIndex - solve for general case Putting everything into proxies is not a realistic solution. Doing so pushes the problem of determining the relationships among entries in various tables from the agent system to the manager-role system, which is even less likely to have the information needed to make such a determination. Solving for specific cases, such as ifIndex, works better, but does not provide any way to handle future MIBs, which might require sharing indexes which have not been defined at the time a master agent is built. Solving for the general case is hardest of all, especially if the details of index allocation are confused with other issues in the design of agent/subagent protocols. There are a number of implementation techniques available to address parts of the problem. - "proxy" fails to meet most interesting requirements - "hashing" (where index semantics allow distributed, collision-free allocation. physical port numbers are a classic example, "Johnson Indexes" a much more sophisticated application) - "plug-and-pray" (where the index semantic or allocation scheme permits distributed, but not collision-free, allocation. ifIndex is an example of this. A brute force MIB walk allows computation of the probable next available index, but does not guarantee uniqueness. - "extensible index generation" If the generic index coordinator mechanism can be dynamically extended with new, specific index allocators, all the requirements can be met, except for caveats regarding legacy subagents. The challenge is to do this without overly complicating agent/subagent communications. A key decision point is whether to handle index resolution as part of the agent-subagent dialogue or out-of-band. The tradeoffs: - this service is applicable to multiple subagent environments. - as a separate protocol, it would preserve the investment in existing master and subagent technologies, both open and proprietary. - built into an open protocol, perhaps as part of the agentx work, it could significantly accelerate convergence on a smaller number of open subagent mechanisms - legacy (sub)agents would need some rework to make use of this mechanism Different possible mechanisms can be evaluated using the requirements derived above. - correct syntax - can be handled by: - "hashing" subagent logic - master agent with protocol exchange that informs master of the index OID and SYNTAX; note that the MCSA proposal fails this test for all except the trivial integer case - a "designated index server" - uniqueness - can be handled by: - "hashing" subagent logic, as long as the hashing algorithm is up to the distribution realities of the implementation - master agent index generator - designated index server - fails in all cases with uncooperative legacy (sub)agents - obtaining values already allocated - can be handled by: - works for hashing if referencers can determine what the identity of the referenced thing would be, and thus compute index - master agent index generator would require query transactions, though ultimately same issue arises as for hashing case - designated index server, with same caveats - MIB-specific value semantics - trivial for hashing case - difficult for master agent index generator, since it requires communication of semantics in addition to syntax (unless using a DLL strategy, which is really a designated index server that just happens to run in the master agent's address space) - trivial for designated index server Problems with specific strategies: - all strategies run into potential problems with legacy code which may produce collisions. The addition of brute force can reduce collision probability but not eliminate it - hashing / Johnson index schemes are particularly attractive for card/slot/port/vc situations, since they eliminate the need for query/allocation transactions. this is a big win for dynamic things like vcs and for systems with large numbers of table entries. (note comments on vc in RFC 1573 clause 3.2.4) Proposal: Add the index services described above to subagent protocol. It is important that these services be done in such a way as to not add undue complexity to set processing or the protocol state space. It may make sense to treat it as having a state space of its own, allowing complete asynchronicity to other protocol operations other than session establishment and termination. (Index allocation interacts with row creation, since table rows may be created both by local means and by management request in some cases. A pathological example would be a table representing hot-insertion hardware, where the MIB definitions also allow provisioning, and empty, non-provision slots appear as holes in the table.) The services need to support the case where the index allocation and resource reservation is handled by some process other than the master agent, as well as allowing implementation of index assignment within the master agent or a DLL. The model must not preclude collision-free "hashing" schemes, since these are, in general, dramatically more efficient than the client-server model required to handle others. -------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy@peer.com USA --------------------------------------------------------------------------   Delivery-Date: Fri, 12 Jan 1996 20:32:00 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id UAA29872 for X-agentx-local; Fri, 12 Jan 1996 20:31:59 -0800 (PST) Received: from europe.std.com (europe.std.com [192.74.137.10]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id UAA29867 for ; Fri, 12 Jan 1996 20:31:58 -0800 (PST) Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id XAA09143; Fri, 12 Jan 1996 23:31:34 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA10573; Fri, 12 Jan 1996 23:29:29 -0500 From: ralex@world.std.com (Aleksey Y Romanov) Message-Id: <199601130429.AA10573@world.std.com> Subject: Re: PDUs, proto-ops, and principles To: daniele@zk3.dec.com (Mike Daniele) Date: Fri, 12 Jan 1996 23:29:28 -0500 (EST) Cc: agentx@fv.com In-Reply-To: <9601122154.AA10464@bernie.zk3.dec.com> from "Mike Daniele" at Jan 12, 96 04:54:49 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > >Simple example: > > Your example is an interesting idea! Thanks, however, I got to it while thinking about 'what is a most trivial way to allow overlapping'. > It suggests basically > > o component agents don't register specific row instances, > they just indicate which conceptual table they implement Basically they indicate list of sub-trees they implement. I limited my example to table just to make explanation a little bit shorter > o the system agent broadcasts requests for objects in > the table to all such component agents simultaneously, > and sorts out the responses. I did not think about broadcasting (while it is definetely an option). I see it as follows there is a list of of sub-trees ordered lexicographically master agent just going through this list. Fact that this list ordered is makes life a little bit easier (there is no deteminism in order of mounting same sub-tree by different sub-agents). > > The questions I have immediately are > > o how do component agents know which row they have? Who else would know it better than sub-agent itself ? > how is contention avoided? a. Either by design of sub-agent. E.g. sub-agent A handles interface of kind x and sub-agent B handles interface of kind y. b. Or by allowing contention: same instance can be handled by several sub-agents - first one in the list or one with higher priority will take over. > > o does this imply in general that the system agent must > permit duplicate registrations (registration by different > component agents of exactly the same oid)? Yes. > > I don't think the reference implementations permit > this (at least not without some other indicator, > like priority, to break the tie). It's very convenient > to have a deterministic dispatching table. If you are talking snmp95 as it is released to the net it does not include support for this feature. What problem do you see in several sub-agents of the same priority mounting same sub-tree ? If there are no instnaces common to any two or more of them then there is simply no problem there, if there are such instances - then one moutned first will take over (if it is not what system administrator would like to see, then he has to assign priorities in appropriate way). > o Is the overhead of the potentially huge amount > of wasted agentx communication offset by any huge win? I do not think that overhead is going to be huge. E.g. you guys who do not see problem in concentrating access checking in master agent hence allowing potentially 1000's of exchanges to take place while processing GetNexts with instance level ganularity. Comparing to this overhead to send extra request per overalpped sub-tree is very small. There is simply no alternative, IMHO. You example with registerineg each instance of ifTable is valid. However, ifTable does not allow rows to be created and I simply do not see a how your scheme will hanlde row creation in overlapped sub-trees. > o I'm having a hard time trying to imagine how sets > could work in this scheme... What was unclear in the exmple I had provided ? > Mike Aleksey   Delivery-Date: Sat, 13 Jan 1996 06:55:59 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id GAA07693 for X-agentx-local; Sat, 13 Jan 1996 06:55:59 -0800 (PST) Received: from europe.std.com (europe.std.com [192.74.137.10]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id GAA07688 for ; Sat, 13 Jan 1996 06:55:58 -0800 (PST) Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id JAA05558; Sat, 13 Jan 1996 09:56:04 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA08246; Sat, 13 Jan 1996 09:54:58 -0500 From: ralex@world.std.com (Aleksey Y Romanov) Message-Id: <199601131454.AA08246@world.std.com> Subject: Re: Index Sharing To: randy@dorothy.peer.com (Randy Presuhn) Date: Sat, 13 Jan 1996 09:54:58 -0500 (EST) Cc: agentx@fv.com In-Reply-To: <9601130337.AA25802@dorothy.peer.com> from "Randy Presuhn" at Jan 12, 96 07:37:40 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > Hi - > > I apologize in advance for the length of this contribution. > > I'd like to share some notes on the index sharing problem. Others have > touched on the topic and I think we're getting to the point where we > can address it in earnest. I consider this problem tougher than others > we've talked about, but I think we can bludgeon it into submission. > > Customers tell me there is a market requirement for this capability. > I believe them, and would like to hear what others think. Rnady and others, IMHO, SNMP agents are very simple pieces of software which does not require so big efforts, in order to be done. If we have request, varbind and list of sub-agents mounted we can always perform following set of simple oprations: A. Generate sub-list of of sub-agents to whom it makes sense to send this request/varbind combination. Note: In many cases this will be achieved by simply comparing sub-tree prefix with requested name and skipping dead end destinations. B. Order this sub-list in a reasonable way (lexicographically for GetNex/Bulk, by priorities in case of Get/Set). Note: Get/Set operation does not require ordering if either of following is true: (1) there is no instances represented by two or more sub-agents, (2) if there are such instances they are proprely represented by all sub-agents involved, in other words, if we do not care about priorities C. Send request/varbind combination to all sub-agents in the list and interpret results as follows: 1. GetNext/Bulk: smallest name returned is the result of request for this var-bind. 2. Get: first name returned is the result of request for this var-bind. 3. First sub-agent who indicated 'this is my instance' will be used to perform second pass of SET operation for this request/varbind. > > > For general background, RFC 1573 is highly recommended reading. It seems to me that the choice of small integer as index for ifTable instead of OCTET STRING is a problem, which will hunt us for years to come. BTW, can we fix it, while still working on SNMPv2 ? Aleksey   Delivery-Date: Sat, 13 Jan 1996 14:58:41 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id OAA03075 for X-agentx-local; Sat, 13 Jan 1996 14:58:40 -0800 (PST) Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id OAA03070 for ; Sat, 13 Jan 1996 14:58:39 -0800 (PST) Received: by dorothy.peer.com (4.1/SMI-4.1) id AA04414; Sat, 13 Jan 96 14:58:29 PST Date: Sat, 13 Jan 96 14:58:29 PST From: randy@peer.com (Randy Presuhn) Message-Id: <9601132258.AA04414@dorothy.peer.com> To: agentx@fv.com Subject: Re: Index Sharing Hi - I was not clear enough when I used the phrase "index sharing." I was NOT referring to operation dispatch. Operation dispatch for tables spread across multiple subagents is well understood, as Aleksey's implementation outline demonstrates. The problem I was referring to is the problem of ALLOCATING and DISSEMINATING index values among subagents requiring knowledge of specific index value assignments other than their own. This problem is logically distinct from the registration and the inter-agent mib variable access questions. I hope my concerns are clearer now. | From: ralex@world.std.com (Aleksey Y Romanov) | Subject: Re: Index Sharing | To: randy@peer.com (Randy Presuhn) | Date: Sat, 13 Jan 1996 09:54:58 -0500 (EST) | Cc: agentx@fv.com ... | If we have request, varbind and list of sub-agents mounted we can always | perform following set of simple oprations: ... | It seems to me that the choice of small integer as index for ifTable | instead of OCTET STRING is a problem, which will hunt us for years to | come. BTW, can we fix it, while still working on SNMPv2 ? ... The index sharing problem exists independently of the index syntax. Whether "small integer" for ifTable was the correct choice is an independent discussion. Careful selection of index semantics can make the problem trivial in some cases. Unfortunately, there are already mibs with references to index values requiring coordination of index allocation and communication of index usage among component agents. -------------------------------------------------------------------------- Randy Presuhn PEER Networks, a division of BMC Software, Inc. Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 Fax: +1 408 556-0735 San Jose, California 95129-3433 Email: randy@peer.com USA --------------------------------------------------------------------------   Delivery-Date: Sat, 13 Jan 1996 19:06:19 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id TAA02307 for X-agentx-local; Sat, 13 Jan 1996 19:06:19 -0800 (PST) Received: from europe.std.com (europe.std.com [192.74.137.10]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id TAA02302 for ; Sat, 13 Jan 1996 19:06:18 -0800 (PST) Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id WAA26985; Sat, 13 Jan 1996 22:06:23 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA11543; Sat, 13 Jan 1996 22:03:28 -0500 From: ralex@world.std.com (Aleksey Y Romanov) Message-Id: <199601140303.AA11543@world.std.com> Subject: Re: Index Sharing To: randy@peer.com (Randy Presuhn) Date: Sat, 13 Jan 1996 22:03:28 -0500 (EST) Cc: agentx@fv.com In-Reply-To: <9601132258.AA04414@dorothy.peer.com> from "Randy Presuhn" at Jan 13, 96 02:58:29 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > Hi - > > I was not clear enough when I used the phrase "index sharing." I was > NOT referring to operation dispatch. It was unclear for me indeed. > | It seems to me that the choice of small integer as index for ifTable > | instead of OCTET STRING is a problem, which will hunt us for years to > | come. BTW, can we fix it, while still working on SNMPv2 ? > ... > > The index sharing problem exists independently of the index syntax. > Whether "small integer" for ifTable was the correct choice is an > independent discussion. > > Careful selection of index semantics can make the problem trivial in > some cases. Unfortunately, there are already mibs with references to > index values requiring coordination of index allocation and > communication of index usage among component agents. IMHO, 'careful selection' of index semantics as OCTET STRING (which is how interfaces are identified in inside most OSes) would make problem trivial indeed, so it seems relevant to me. In other words whenever we have indexing set far away from the natural /inernal identification of instances inside managed object we are in the deep trouble if we have to share support for the MIB across several sub-agents. Hopefully, there are not many MIBs with similar flaw around and among flawed ones only ifTable seems like a probable candidate for multiple sub-agents support. Can ifIndex specific solution suffice practical requirements supposing MIB designers/reviewer will have it mind ? Otherwise we have to address this problem in expedient manner, somewhere along lines you are talking about. > Randy Presuhn PEER Networks, a division of BMC Software, Inc. Aleksey   Delivery-Date: Mon, 15 Jan 1996 07:40:30 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id HAA25782 for X-agentx-local; Mon, 15 Jan 1996 07:40:27 -0800 (PST) Received: from hp.com (hp.com [15.255.152.4]) by zloty.fv.com (8.7.3/8.7.3) with ESMTP id HAA25779 for ; Mon, 15 Jan 1996 07:40:24 -0800 (PST) Received: from nsmdserv.cnd.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA063220426; Mon, 15 Jan 1996 07:40:27 -0800 Received: from localhost by nsmdserv.cnd.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA122970425; Mon, 15 Jan 1996 08:40:25 -0700 Message-Id: <199601151540.AA122970425@nsmdserv.cnd.hp.com> To: ralex@world.std.com (Aleksey Y Romanov) Cc: agentx@fv.com Subject: Re: Index Sharing In-Reply-To: Your message of Sat, 13 Jan 1996 09:54:58 -0500. <199601131454.AA08246@world.std.com> Date: Mon, 15 Jan 1996 08:40:25 -0700 From: "Brian O'Keefe" > It seems to me that the choice of small integer as index for ifTable > instead of OCTET STRING is a problem, which will hunt us for years to > come. BTW, can we fix it, while still working on SNMPv2 ? > > Aleksey If this is such a problem, then a report to the broader MIB writing community ought to go out... it seems to me the recent trend for MIB writers has been to use small-valued integers so as to reduce the packet overhead attributed to instance-id information for each varbind in the message. Sounds to me like conflicting objectives... . on one hand, intuition and agentx promotes semantically meaningful index . on the other hand, MIB writers are trying to minimize/optimize packet overhead via an arbitrary integer index. Is the NM Area Directorate taking note of this emerging situation? bok   Delivery-Date: Mon, 15 Jan 1996 08:29:26 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id IAA07863 for X-agentx-local; Mon, 15 Jan 1996 08:29:25 -0800 (PST) Received: from lobster.wellfleet.com (lobster.corpeast.baynetworks.com [192.32.253.3]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id IAA07855 for ; Mon, 15 Jan 1996 08:29:24 -0800 (PST) Received: from pobox.BayNetworks.com (pobox.corpeast.baynetworks.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA25610; Mon, 15 Jan 96 11:28:36 EST Received: from tick.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA16233; Mon, 15 Jan 96 11:29:27 EST Date: Mon, 15 Jan 96 11:29:27 EST From: sonishi@BayNetworks.com (Steve Onishi) Message-Id: <9601151629.AA16233@pobox.BayNetworks.com> To: ralex@world.std.com, bok@nsmdserv.cnd.hp.com Subject: Re: Index Sharing Cc: agentx@fv.com I think another reason for using "generic" small valued integers is that they can be used on any system/platform. If you were to design an index that had some real semantics to it you might find it difficult to come up with one that applies across all vendor platforms. > >> It seems to me that the choice of small integer as index for ifTable >> instead of OCTET STRING is a problem, which will hunt us for years to >> come. BTW, can we fix it, while still working on SNMPv2 ? >> >> Aleksey > >If this is such a problem, then a report to the broader MIB writing >community ought to go out... it seems to me the recent trend for MIB >writers has been to use small-valued integers so as to reduce the >packet overhead attributed to instance-id information for each varbind >in the message. > >Sounds to me like conflicting objectives... > . on one hand, intuition and agentx promotes semantically meaningful index > . on the other hand, MIB writers are trying to minimize/optimize packet > overhead via an arbitrary integer index. > >Is the NM Area Directorate taking note of this emerging situation? > >bok > > > >---------------- >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 the this message to unsubscribe. You must send >your request to agentx-request@fv.com Thank you.) >   Delivery-Date: Mon, 15 Jan 1996 11:04:29 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id LAA16832 for X-agentx-local; Mon, 15 Jan 1996 11:04:28 -0800 (PST) Received: from seymour4 (seymour4.snmp.com [192.147.142.4]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id LAA16822 for ; Mon, 15 Jan 1996 11:04:26 -0800 (PST) From: case@snmp.com Received: by seymour4 (5.61++/2.8s-SNMP ) id AA10979; Mon, 15 Jan 96 13:58:01 -0500 Date: Mon, 15 Jan 96 13:58:01 -0500 Message-Id: <9601151858.AA10979@seymour4> To: agentx@fv.com Subject: Re: PDUs, proto-ops, and principles mike writes: > o does this imply in general that the system agent must > permit duplicate registrations (registration by different > component agents of exactly the same oid)? > I don't think the reference implementations permit > this (at least not without some other indicator, > like priority, to break the tie). It's very convenient > to have a deterministic dispatching table. EMANATE has done this (what aleksey said) for some time ... not including the broadcasting part ... we talk to each one, one by one ... but if i followed correctly, otherwise pretty much as you understood what he said EMANATE does allow priorities to resolve overlaps, but still is ok if the priorities are equal in more recent EMANATE program releases, we allow even greater flexibility in keeping with the philosophy that "one subagent writer need not know about the work of another subagent writer" by allowing different subagent to register at different "heights" for the same subtree for example, one subagent might register for ifSpeed while another registers for ifSpeed.3 while yet another registers for [being ridiculous] iso > o Is the overhead of the potentially huge amount > of wasted agentx communication offset by any huge win? if somebody registers for "iso" as in the above example, the get called *A LOT* and there is a lot of wasted communication ... it works, but it is inefficient, so DONT DO THAT! people who do stupid things get stupid results ... however, i would prefer that we not legislate morality within the master agent - subagent interface specification > o I'm having a hard time trying to imagine how sets > could work in this scheme... it works ... row creation can be a little quirky if you don't know in which subagent the row should be created ... rmon is the canonic example regards, jdc   Delivery-Date: Mon, 15 Jan 1996 11:09:01 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id LAA17815 for X-agentx-local; Mon, 15 Jan 1996 11:09:01 -0800 (PST) Received: from seymour4 (seymour4.snmp.com [192.147.142.4]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id LAA17797 for ; Mon, 15 Jan 1996 11:09:00 -0800 (PST) From: case@snmp.com Received: by seymour4 (5.61++/2.8s-SNMP ) id AA10994; Mon, 15 Jan 96 14:01:07 -0500 Date: Mon, 15 Jan 96 14:01:07 -0500 Message-Id: <9601151901.AA10994@seymour4> To: agentx@fv.com Subject: Re: Index Sharing i think randy is talking about index reservation as opposed to index registration i mentioned this earlier and generally got a "huh?" in response i believe index reservation and index registration are potentially quite independent both are market requirements because they are requirements for the implementation of some of today's standards-track mibs in open environments regards, jdc   Delivery-Date: Mon, 15 Jan 1996 11:17:37 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id LAA20191 for X-agentx-local; Mon, 15 Jan 1996 11:17:37 -0800 (PST) Received: from seymour4 (seymour4.snmp.com [192.147.142.4]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id LAA20181 for ; Mon, 15 Jan 1996 11:17:35 -0800 (PST) From: case@snmp.com Received: by seymour4 (5.61++/2.8s-SNMP ) id AA11005; Mon, 15 Jan 96 14:12:40 -0500 Date: Mon, 15 Jan 96 14:12:40 -0500 Message-Id: <9601151912.AA11005@seymour4> To: agentx@fv.com Subject: Re: Index Sharing >> It seems to me that the choice of small integer as index for ifTable >> instead of OCTET STRING is a problem, which will hunt us for years to >> come. BTW, can we fix it, while still working on SNMPv2 ? >> >> Aleksey >If this is such a problem, then a report to the broader MIB writing >community ought to go out... it seems to me the recent trend for MIB >writers has been to use small-valued integers so as to reduce the >packet overhead attributed to instance-id information for each varbind >in the message. > >Sounds to me like conflicting objectives... > . on one hand, intuition and agentx promotes semantically meaningful index > . on the other hand, MIB writers are trying to minimize/optimize packet > overhead via an arbitrary integer index. > >Is the NM Area Directorate taking note of this emerging situation? who? it seems that the right time to fix this is in the interfaces mib working group and RIGHT NOW the ifmib wg is working on the tables that replace the ifTable in MIB 2 i.e., son of rfc 1573 i have sent input to that working group (which met at the same time as the friday agentx wg meeting in dallas where i was expected to make a presentation and couldnt attend the ifmib wg simultaneously) which states that the stack table (which is required) can't be implemented on open systems [by multiple independent implementers] except as a postem-note mib configured by the system administrator this didn't slow 'em down any ... there are implementations in embedded systems this indexing and the sharing of index pointers within the stack table is a problem that should be addressed and now is the time, but i've been unsuccessful in bringing it forward as a problem worth solving regards, jdc   Delivery-Date: Mon, 15 Jan 1996 12:18:19 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id MAA05578 for X-agentx-local; Mon, 15 Jan 1996 12:18:19 -0800 (PST) Received: from POST (post.mis.tandem.com [130.252.223.47]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id MAA05573 for ; Mon, 15 Jan 1996 12:18:17 -0800 (PST) Received: by POST (4.13/4.5) id AA20281; 15 Jan 96 12:17:55 -0800 Date: 15 Jan 96 11:15:00 -0800 From: SOJOURNER_CLIFF@Tandem.COM Message-Id: <199601151217.AA20281@POST> To: agentx@fv.com Subject: more about INTEGER indexes one more reason for using arbitrary INTEGER indexes in tables: we recently implemented a table which had the following columns: serverName DisplayString(0..48) serverAddress DisplayString(0..28) serverType INTEGER serverHops INTEGER the first three (Name, Address, and Type) are the indexes for the table. There aren't many programs that can handle DisplayString indexes that large. Using an arbitrary INTEGER index, assigned by the subagent for each (Name, Address, and Type) tuple sure simplified the code! The locate() and next() function size was greatly reduced. Further, our chances of interoperability are greatly enhanced by not demanding that certain (common, but broken) applications be able to generate PDUs with *90* OIDs per varbind... (11 for enterprise OID & table ID + serverName [1 + 48] + serverAddress [1 + 28] + serverType 1). Cliff Sojourner   Delivery-Date: Mon, 15 Jan 1996 12:42:19 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id MAA11491 for X-agentx-local; Mon, 15 Jan 1996 12:42:19 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id MAA11486 for ; Mon, 15 Jan 1996 12:42:17 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA28955 for agentx@fv.com; Mon, 15 Jan 96 15:42:14 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA04840; Mon, 15 Jan 1996 15:40:51 -0500 Date: Mon, 15 Jan 1996 15:43:42 EST From: Bob Natale Subject: Meeting(s) at LA IETF...? To: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi everyone, Face-to-face sessions at the IETF meetings can be very helpful to a wg in making progress/reaching decisions on difficult technical issues. We had two sessions at the Dallas IETF that served very well, IMHO, to set the focus on technical matters that has been continued on the list in the subsequent e-mail discussions. A couple of trends seem clear: - the members of the wg are strongly committed to producing the agentx protocol; and - the number and nature of technical contributions continues to be invigorating; and - with appropriate tuning, we will likely have our key decision points identified (hopefully to the smallest possible number of them) by the March (4-8) IETF, - at which point, one or more face-to-face meetings might be critical in reaching working decisions and a tentative statement of consensus for further consideration on the list. However, some potential objections to holding such meetings at that time might include: - we had two sessions in Dallas and other groups need/deserve IETF time slots (which are limited); - the early March time frame might be too soon... we might not be far enough along to hope for such a concrete outcome at that time; and/or - multiple interested parties who would otherwise participate in such a meeting have schedule conflicts with the March IETF. So, I would like your feedback wrt this matter. If you have an opinion--one way or the other--please let me know (on-list (preferred) or off-list). I will need to ask Deirdre to consider our request for meeting slots at the earliest possible date.... Thanks. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Tue, 16 Jan 1996 11:30:05 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id LAA26953 for X-agentx-local; Tue, 16 Jan 1996 11:30:03 -0800 (PST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id LAA26910 for ; Tue, 16 Jan 1996 11:29:58 -0800 (PST) Received: from flume.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA30162; Tue, 16 Jan 1996 14:15:02 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA13584; Tue, 16 Jan 1996 14:14:49 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA11353; Tue, 16 Jan 1996 14:15:11 -0500 Message-Id: <9601161915.AA11353@bernie.zk3.dec.com> To: case@snmp.com, ralex@world.std.com Cc: agentx@fv.com Subject: dispatching for shared tables Date: Tue, 16 Jan 96 14:15:11 -0500 From: Mike Daniele X-Mts: smtp Hi Jeff, Aleksey >EMANATE has done this (what aleksey said) for some time ... not including >the broadcasting part ... we talk to each one, one by one ... but if i >followed correctly, otherwise pretty much as you understood what he said >in more recent EMANATE program releases, we allow even greater flexibility >in keeping with the philosophy that "one subagent writer need not know about >the work of another subagent writer" by allowing different subagent to >register at different "heights" for the same subtree >for example, one subagent might register for ifSpeed while another registers >for ifSpeed.3 while yet another registers for [being ridiculous] iso >> o Is the overhead of the potentially huge amount >> of wasted agentx communication offset by any huge win? >if somebody registers for "iso" as in the above example, the get called >*A LOT* and there is a lot of wasted communication ... it works, but it is >inefficient, so DONT DO THAT! Just want to make sure I understand. Your registration policy is o overlaps and duplicate subtrees are permitted o priorities are allowed but not required o all registered subtrees are 'remembered' Your dispatching policy when a requested variable falls within 2 or more registered subtrees (either duplicate or overlapping) is o if a higher priority containing subtree exists, dispatch to it only o otherwise dispatch to each candidate subtree in order the order is based on ? (order of registration? reverse order of registration?) is it the same order each time? for Get, the first successful component agent response is used for Next/Bulk, all component agent responses must be examined to determine the lowest name, and this data is used for Set, the first component agent that can perform the operation becomes active for the operation (i assume the first component agent that responds successfully to the first phase of a 2 phase commit scenario is the one considered active?) It's that Next/Bulk part that I was referring to as a "potentially huge amount of wasted agentx communication". >people who do stupid things get stupid results ... however, i would prefer >that we not legislate morality within the master agent - subagent interface >specification Agreed. And we've also chosen within eSNMP to let the chips fall where they may, by permitting overlaps at any 'height'. We have a similar registration policy as described above. Our dispatching policy however is that we dispatch to only one component agent for any particular variable. That component agent is the one with a containing subtree (duplicate or overlap) at highest priority or (in case of priority ties) was most recently registered. This saves the Get & Next/Bulk overhead, which I still think needs to be avoided. It makes registration 'mistakes' more costly, but ultimately you need to rely on component agent developers doing the right thing. It also means (as Aleksey pointed out) that row creation in shared tables doesn't work. >> I'm having a hard time trying to imagine how sets >> could work in this scheme... Aleksey your example was clear. I was really thinking out loud, and trying to think about a Set of variables in different subtrees, one or more of which is a duplicate and must be handled as you pointed out, with 2 phase commit etc. Sorry for the pointless statement in my response. What you've described is then a way for component agents to effectively share rows in a table (with row creation), without knowing anything other than what subtree to register, and what their own index values are. The issues I see are 1) it makes Get and Set performance worse, and Next/Bulk performance 'much' worse 2) it's possible for contention; 2 component agents think they have the same index values These may just be the price of doing business. I've no better suggestion based on the reference implementations. But at the risk of being accused of not realizing the logical distinction between allocating and disseminating index values among subagents, and registration/mib variable access, I would like to point out: o for shared tables, for which agentx does handle index allocation, both problems disappear. o for shared tables whose indexes can't be allocated by the system agent, if agentx permitted 'row instance' registration (ifTable index n) then problem 1 disappears and problem 2 could possibly be handled by the registration policy. If agentx is to manage indexes for component agents somehow, it would make sense to me to also provide registration semantics (for instance, 'row instance registation') so that the system agent can dispatch to a single component agent per variable. (Sets will still require involving multiple component agents initially.) Well, sorry for the length, and thanks both for the information. Regards, Mike   Delivery-Date: Tue, 16 Jan 1996 11:40:45 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id LAA29602 for X-agentx-local; Tue, 16 Jan 1996 11:40:40 -0800 (PST) Received: from inet1.tek.com (inet1.tek.com [134.62.48.21]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id LAA29476 for ; Tue, 16 Jan 1996 11:40:15 -0800 (PST) Received: by inet1.tek.com id ; Tue, 16 Jan 1996 11:40:12 -0800 Received: from tektronix.tek.com(134.62.48.24) by inet1 via smap (V1.3) id sma023841; Tue Jan 16 11:38:59 1996 Received: from dtl.labs.tek.com by tektronix.TEK.COM (4.1/8.2) id AA16521; Tue, 16 Jan 96 11:39:00 PST Received: from icebox.LABS.TEK.COM (icebox.TEK) by dtl.labs.tek.com (4.1/8.0) id AA10925; Tue, 16 Jan 96 11:38:44 PST Received: from icebox (localhost) by icebox.LABS.TEK.COM (5.x/SMI-SVR4) id AA26684; Tue, 16 Jan 1996 11:41:58 -0800 Message-Id: <9601161941.AA26684@icebox.LABS.TEK.COM> To: agentx@fv.COM Cc: tedb@icebox.LABS.TEK.COM, if-mib@dtl.LABS.TEK.COM, kostick@qsun.att.COM, case@snmp.COM Subject: Re: Index Sharing From: Ted Brunner Date: Tue, 16 Jan 1996 11:41:58 -0800 Sender: tedb@icebox.LABS.TEK.COM Although I haven't been following this discussion, I'd like to comment on the following posting on the agentx list. > From: case@snmp.com > Date: Mon, 15 Jan 96 14:12:40 -0500 > it seems that the right time to fix this is in the interfaces mib working > group and RIGHT NOW Yes it would be good to fix whatever has to be fixed, since the Interfaces MIB WG is hoping to go to draft soon. > i have sent input to that working group (which met at the same time as the > friday agentx wg meeting in dallas where i was expected to make a presentation > and couldnt attend the ifmib wg simultaneously) which states that the stack > table (which is required) can't be implemented on open systems [by multiple > independent implementers] except as a postem-note mib configured by the > system administrator Yes, it is unfortunate that you were not able to be there yourself. Not so pro-active IETF scheduling on my part is partially to blame for the scheduling conflict. I expressed your concerns to the WG in Dallas on your behalf (hopefully I did so accurately.) There was a discussion, and the result has been published in the minutes, which were sent to this list and available at cnri. Here is a copy: > -The ifStackTable is implementable if have > embedded system, single developer, source code knowlege/control. > No implementation experience from open systems > with 3rd party developers. Furthermore not all > proxy agent implementations/architectures have sufficient > visibility to support the ifStackTable. > > While the WG has sympathy for the implemention problems > of open platforms it feels that the ifStackTable has real utility. > While the WG acknowleges this utility is most needed on "WAN boxes" > it felt this utility overrides implementation problems on certain > platforms. There is precedent for this. > At other times the implementation difficulties of eg UNIX > were not deemed sufficient to quash an object of demonstrable utility. > > Action > The ifStackTable is manditory. > If an implementation cannot determine the ifStackTable internally, > it must not fake it, by returning a misleading table which indicates > no stacking or something else inaccurate. This was considered akin > to returning a count of zero when the counter is not implemented. > Text forbidding this usage shall be added to the draft. > > The wg also wants to send a request to the Agentx wg that the > capability to support the ifStackTable in a proxy agent environment > be a requirement of the extensible agent design. First observation: The friday morning dallas meeting only had about 15 people attend. Thus it would be best to reaffirm the above conclusion on the full interfaces mailing list. > this didn't slow 'em down any ... there are implementations in embedded > systems Well yes. Those implementations were cited as the reason why other implementation issues should not preclude needed functionality. > this indexing and the sharing of index pointers within the stack table is > a problem that should be addressed and now is the time, but i've been > unsuccessful in bringing it forward as a problem worth solving Unsuccessful so far; this is why. Within the interfaces WG the feeling is that the plumbing of some boxes (routers connected to WANs is the usual example) is sufficiently complex that the ability to express stacking is just too important to forgo. From that perspective the stackTable of rfc1573 was a raging success. Of course one might consider this view parochial. And it is true that the discussion about son of rfc1573 has been somewhat narrowly focused on expressing stacks and compatiblity with other mibs. But I would say that the interfaces MIB WG has demonstrated quite a strong constituency for the ability to express stacking. Whatever it is that folks feel needs to be fixed now, we MUST keep that ability. Second observation: I don't know if the following has come up yet on the agentx list; its probably my fault if it hasn't. (repeated from above) > The wg also wants to send a request to the Agentx wg that the > capability to support the ifStackTable in a proxy agent environment > be a requirement of the extensible agent design. The working group felt that this stack functionality is something that SNMP should move forward with, and that its a managable requirement from the extensible agent. Are we off base here? Do folks feel that it can't be supported as we move toward future agents? Ted Brunner Video and Networking Technology Tektronix MS 50-490 ted.brunner@tek.com 14150 SW Karl Braun 503.627.1317 Beaverton OR 97005   Delivery-Date: Tue, 16 Jan 1996 15:09:16 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id PAA22876 for X-agentx-local; Tue, 16 Jan 1996 15:09:15 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id PAA22872 for ; Tue, 16 Jan 1996 15:09:14 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA21190 for agentx@fv.COM; Tue, 16 Jan 96 18:09:13 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA26805; Tue, 16 Jan 1996 18:07:50 -0500 Date: Tue, 16 Jan 1996 18:10:48 EST From: Bob Natale Subject: Re: Index Sharing To: Ted Brunner Cc: agentx@fv.COM, if-mib@dtl.labs.tek.com, kostick@qsun.att.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Ted Brunner > Date: Tue, 16 Jan 1996 11:41:58 -0800 Hi Ted, > Although I haven't been following this discussion, I'd like to > comment on the following posting on the agentx list. Ok...since you haven't been following agentx, let me just state that I have been asked to indicate when I am speaking as the agentx chair...and I am going to do so now: <...> > Second observation: > I don't know if the following has come up yet on the > agentx list; its probably my fault if it hasn't. > (repeated from above) > > The wg also wants to send a request to the Agentx wg that the > > capability to support the ifStackTable in a proxy agent environment > > be a requirement of the extensible agent design. As of now, the agentx wg position is that a proxy agent environment is one thing and an extensible agent environment is another. The agentx wg is addressing the extensible agent environment only. The agentx wg feels that much good work has been done in the development of proxy-based solutions and we are hopeful that we will be able to assist with the composition and publication of a "BCP"-type document outlining proxy...but that will only be as either a non-wg effort or an optional output of the wg...and we are (currently) running far behind on our (perhaps overly optimistic) schedule wrt our mandatory deliverables. > The working group felt that this stack functionality is something > that SNMP should move forward with, and that its a managable > requirement from the extensible agent. Could be. To be honest, I'm probably not up to the speed that you and Jeff and some others are on this specific topic, so I may well be unqualified to pass judgment on this. Given that, naturally, I will monitor further replies from any interest parties. From a technical perspective, I will just hazard the comment that to the extent the ifStackTable problem might relate to "index sharing/index reservation/index assignment" then, yes, I do believe agentx will have to deal with this. I can give you a bit more insight into the current agentx modus operandi: - We are trying to focus on the deployed "solution space" of existing extensible agent protocols/products --e.g., SMUX, DPI, UT-SNMP, OAA, eSNMP, EMANATE, Envoy, Optima, and others--and assessing whether the "common ground" that they share covers enough of the "problem space" to warrant standardization and deployment, and - if not, then determining/defining what corrections, refinements, extensions are necessary to get to sufficient coverage; and - while this process is going fairly well so far-- certainly we have seen outstanding cooperation among the major technical contributors thus far-- there is a lurking feeling (at least in my mind) that we are really still trying to characterize the "problem space" as including this or that (well, "all" really) of our individual favorite requirements; and - that's not a winning approach; so - it's up to me (as wg chair) to re-energize the "solution space" approach...and I have some ideas for doing so in the immediate future... Now, given all of that, could you please re-phrase/re-assess the passage you quoted and let us know how you think agentx should proceed wrt ifStackTable, etc...? > Are we off base here? Do folks feel that it can't be > supported as we move toward future agents? As I said, I am not competent to decide this. I can say this: Trying to integrate/steer agentx discussions and monitor and incorprate the App MIB, Entity MIB, RMON2, and SNMPv2C into the agentx stream is already quite a stretch. Like the trend of the recent discussions on the AppMIB list has shown (where Bob Stewart summed all of this up with impressive succinctness which I wish I could emulate...congenital flaw), folks are just going to have to realize that not every requirementcan be met... at least not in the first (several) generation(s) of agentx... and some requirements will have to be shelved. The major criteria I am trying to foster for making those tough decisions are: - Is the requirement met by the deployed protocols/products in the "solution space"? - If "yes", then is that in the "common ground" demonstrated by several of them...or is it a feature of just one or a small minority of them? - If "no", is there a compelling explanation as to why those protocols/products have not seen the need to include it? I am hopeful that these criteria (or similar ones) will help us to reach a fair and productive concensus and avoid both deadlock and interminable enlargement of the "problem space". I think the positive attitudes shown by all participants to date will help us to avoid the former (deadlock), but there are factors that still point to the latter ("feature creep") as a serious threat. Now, what new requirement did you want us to handle? :-):-):-) Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Tue, 16 Jan 1996 21:27:04 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id VAA20129 for X-agentx-local; Tue, 16 Jan 1996 21:27:03 -0800 (PST) Received: from europe.std.com (europe.std.com [192.74.137.10]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id VAA20064 for ; Tue, 16 Jan 1996 21:26:59 -0800 (PST) Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id AAA05577; Wed, 17 Jan 1996 00:27:01 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA04903; Wed, 17 Jan 1996 00:24:54 -0500 From: ralex@world.std.com (Aleksey Y Romanov) Message-Id: <199601170524.AA04903@world.std.com> Subject: Re: dispatching for shared tables To: daniele@zk3.dec.com (Mike Daniele) Date: Wed, 17 Jan 1996 00:24:54 -0500 (EST) Cc: agentx@fv.com In-Reply-To: <9601161915.AA11353@bernie.zk3.dec.com> from "Mike Daniele" at Jan 16, 96 02:15:11 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > o overlaps and duplicate subtrees are permitted > > o priorities are allowed but not required The only use of provide a possibility for two or more sub-agent to represent same instance with different 'quality of service' :). Note: if two or more sub-agents represent same instance with the same quality then master agent does not care which one of them to call. So, I think we can conclude that practically we do not need priorities, while having them does not create any principal problem. (*) > o all registered subtrees are 'remembered' ????? Do you see any other options ? > Your dispatching policy when a requested variable falls within 2 or > more registered subtrees (either duplicate or overlapping) is > > o if a higher priority containing subtree exists, dispatch > to it only Not. > > o otherwise dispatch to each candidate subtree in order Yes. > > the order is based on ? (order of registration? reverse order of registration?) The only order which makes sense is lexicograpical one, if there several sub-agent mounted under same sub-tree they are ordered by priorities between themselves, however, let us not talk about priorities. (**) > is it the same order each time? It seems quite natural to satisfy requests for mounting new sub-agents between PDU processing and to satisfy request to umount any time they are received. So, within one PDU processing the only possible change in order is removing some sub-agents from the list. > > for Get, the first successful component agent response is used Yes. I would like to note that considering (**) condition above it is very easy to skip sub-agents which are mounted as a whole below requested name and stop processing once first sub-agent mounted as a whole above requested name is encountered (***). > > for Next/Bulk, all component agent responses must be examined > to determine the lowest name, and this data is used It does not seem so, considering (**) we can skip sub-agents mounted as a whole below requested name and and we can stop processing once first sub-agent moutned as whole above so far smallest found name will be encountered. > > for Set, the first component agent that can perform the operation > becomes active for the operation > > (i assume the first component agent that responds successfully to > the first phase of a 2 phase commit scenario is the one considered > active?) Yes. Note: (***) is also applicable here. > It's that Next/Bulk part that I was referring to as a "potentially huge amount > of wasted agentx communication". Frankly I do not see it. > Agreed. And we've also chosen within eSNMP to let the chips fall where they > may, by permitting overlaps at any 'height'. > > We have a similar registration policy as described above. > Our dispatching policy however is that we dispatch to only one > component agent for any particular variable. That component agent is the one > with a containing subtree (duplicate or overlap) at highest priority or > (in case of priority ties) was most recently registered. ???? How about variables handled by low priority sub-agent ? > > This saves the Get & Next/Bulk overhead, which I still think needs to be avoided. > It makes registration 'mistakes' more costly, but ultimately you need to rely > on component agent developers doing the right thing. ????? > > It also means (as Aleksey pointed out) that row creation in shared tables > doesn't work. ??????? It works in our case. > The issues I see are > > 1) it makes Get and Set performance worse, and Next/Bulk performance > 'much' worse ???? Overhed in any case is <= one additional call per overlapping sub-agent can it be less ? > > 2) it's possible for contention; 2 component agents think they > have the same index values Yes. Whichever one will be linked firts will be used. It is supposed that they both provide same 'quality of service' so it does not matter. > Mike Aleksey   Delivery-Date: Wed, 17 Jan 1996 08:34:21 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id IAA08145 for X-agentx-local; Wed, 17 Jan 1996 08:34:21 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id IAA08140 for ; Wed, 17 Jan 1996 08:34:19 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA02960 for agentx@fv.com; Wed, 17 Jan 96 11:34:23 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA02358; Wed, 17 Jan 1996 11:33:01 -0500 Date: Wed, 17 Jan 1996 11:35:14 EST From: Bob Natale Subject: Some comments on "priority" (fwd) To: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi everyone, I received the following off-list communication the other day which I am herewith forwarding to the list for consideration unchanged, except for deleting the originator's identity (as requested): - - - - - Forwarded Message - - - - - From: <...> Date: Fri, 12 Jan 1996 14:40:52 -0500 Subject: Re: Component agent non-interdependency Bob, I've been following the discussion about priorities in subagent registrations. It seems to me we are trying to develop a mandate for subagent priorities while in the real world, the actual priority value for any particular subagent is likely to be installation dependant. As you pointed out: > This can be accomplished just as effectively and more efficiently > by configuration of/settings in the system agent. It's the only > one that needs to know about the relative priorities of components > anyway. Can the whole discussion of priorities be moved from the subagent/master agent realm to the master agent/manager realm? I've seen discussion of a table in the master agent's mib that would contain agent registration information (which could be populated either thru set-requests or DPI-like registration messages). This seems the place to maintain priority information on subagents. As I see it, the table would keep the relevant information on subtrees and subagent identification, the current connection status, and a priority assigned to the registered subtree. This table would keep track of all subagents that had ever been connected to the master agent (maintaining a disk file for this purpose). The first time a subagent registers with the master agent, a new row is created in the table (and added to the corresponding disk file). If another subagent is registered for the same mib subtree, the master agent sends a trap to the manager and takes a defined default action. In response to the trap the manager may use a set-request to modify the assigned priority of as necessary. I may be totally off base in my analysis or maybe I've missed something critical on this issue since I don't have the benefit of years of experience in this area. Thanks for your time...<...> - - - - - End of forwarded message - - - - - [Speaking as wg chair...] While I (as a technical contributor) have formerly yielded on the priority issue, subsequent postings by others on the list continue to call it into question. Since it's common to multiple of the reference protocols in the solution space, it has an a priori positive status. However, I would ask the proponents to continue to monitor the discussion and consider whether this feature can/should be dropped in the name of simplyfing the eventual agentx protocol if possible. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Wed, 17 Jan 1996 11:07:32 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id LAA14110 for X-agentx-local; Wed, 17 Jan 1996 11:07:32 -0800 (PST) Received: from card.com (card.com [199.100.120.2]) by zloty.fv.com (8.7.3/8.7.3) with ESMTP id LAA14097 for ; Wed, 17 Jan 1996 11:07:30 -0800 (PST) From: cheryl@empiretech.com Received: from DRAGON.COM (dragon.com [155.229.20.1]) by card.com (8.7.3/8.7.3) with SMTP id MAA27074 for ; Wed, 17 Jan 1996 12:51:35 -0500 (EST) Received: by dragon.com (MX V4.1 VAX) with UUCP; Wed, 17 Jan 1996 12:50:52 EDT Received: (from cheryl@localhost) by emptech.empiretech.com (8.6.12/8.6.12) id MAA10116 for agentx@fv.com; Wed, 17 Jan 1996 12:35:11 -0500 Message-ID: <199601171735.MAA10116@emptech.empiretech.com> Subject: I'm here! To: agentx@fv.com Date: Wed, 17 Jan 1996 12:35:10 -0500 (EST) X-Mailer: ELM [version 2.4 PL22] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Gee... I subscribed to the list when it was first announced and received a confirmation email (my message is even at the top of the archive!) but it looks like I somehow got dropped. And here I was thinking there just wasnt any traffic (duh) Anyway, this is to let everyone know that I AM interested in this working group (and also to test if I get this message.) Cheers! Cheryl +--------------------------------------------------------------------+ + Check us out! http://www.empiretech.com/empiretech + +--------------------------------------------------------------------+ + Cheryl Krupczak Empire Technologies, Inc. + + cheryl@empiretech.com 541 Tenth Street NW + + PH : (770)384-0184 Suite 169 + + FAX: (770)384-0183 Atlanta, GA 30318 + +--------------------------------------------------------------------+   Delivery-Date: Wed, 17 Jan 1996 12:46:19 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id MAA09121 for X-agentx-local; Wed, 17 Jan 1996 12:46:19 -0800 (PST) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id MAA09116 for ; Wed, 17 Jan 1996 12:46:18 -0800 (PST) Received: from flume.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA00539; Wed, 17 Jan 1996 15:43:26 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA20191; Wed, 17 Jan 1996 15:43:23 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA12134; Wed, 17 Jan 1996 15:43:44 -0500 Message-Id: <9601172043.AA12134@bernie.zk3.dec.com> To: Bob Natale Cc: agentx@fv.com Subject: Re: Some comments on "priority" (fwd) In-Reply-To: Your message of "Wed, 17 Jan 96 11:35:14 EST." Date: Wed, 17 Jan 96 15:43:44 -0500 From: Mike Daniele X-Mts: smtp Hi Bob, >While I (as a technical contributor) have formerly yielded on the >priority issue, subsequent postings by others on the list continue >to call it into question. Since it's common to multiple of the >reference protocols in the solution space, it has an a priori >positive status. However, I would ask the proponents to continue >to monitor the discussion and consider whether this feature >can/should be dropped in the name of simplyfing the eventual >agentx protocol if possible. In my opinion what's important (and emerging) is a picture of how different reference implementations handle duplicate and overlapping registration. The discussion seems necessary to me because these details are typically not specified as part of the on-the-wire protocol. And it will be problematical if different compliant agentx system agents exhibit different behavior when presented with the same component agent configuration. Hence we need to specify registration and dispatching policy as part of agentx. I'd like to know how others feel about this. Let me know if you (as wg chair) feel I'm killing another horse :-) Regards, Mike   Delivery-Date: Wed, 17 Jan 1996 13:20:29 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id NAA17001 for X-agentx-local; Wed, 17 Jan 1996 13:20:28 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id NAA16996 for ; Wed, 17 Jan 1996 13:20:27 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA06966 for agentx@fv.com; Wed, 17 Jan 96 16:20:30 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA05139; Wed, 17 Jan 1996 16:19:02 -0500 Date: Wed, 17 Jan 1996 16:21:17 EST From: Bob Natale Subject: Re: Some comments on "priority" (fwd) To: Mike Daniele Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Mike Daniele > Date: Wed, 17 Jan 96 15:43:44 -0500 Hi Mike, [Speaking (on request) as wg chair...] > >While I (as a technical contributor) have formerly yielded on the > >priority issue, subsequent postings by others on the list continue > >to call it into question. Since it's common to multiple of the > >reference protocols in the solution space, it has an a priori > >positive status. However, I would ask the proponents to continue > >to monitor the discussion and consider whether this feature > >can/should be dropped in the name of simplyfing the eventual > >agentx protocol if possible. > > In my opinion what's important (and emerging) is a picture > of how different reference implementations handle duplicate > and overlapping registration. Yes. Additional contributions along those lines...or interim summaries/analyses of the comparative/contrasting methods will be GREATLY APPRECIATED. (This applies to any aspect of agentx for that matter.) > The discussion seems necessary to me because these details are > typically not specified as part of the on-the-wire protocol. Right. > And it will be problematical if different compliant agentx > system agents exhibit different behavior when presented with > the same component agent configuration. Agreed...while minor variations in some aspects might not be problematical, as a general rule we want different system agents to behave consistenly in every important respect. > Hence we need to specify registration and dispatching > policy as part of agentx. Yes, I don't see any alternative to doing this...nor any reason not to want to...it will be part of the "Intro", "Elements of Procedure", "Protocol Operations", and "Error Handling" sections (abstract term for now) of our eventual protocol document(s). > I'd like to know how others feel about this. I suspect everyone agrees here...of course, the floor is open for other views. > Let me know if you (as wg chair) feel I'm killing > another horse :-) Not at all. [Speaking as a technical contributor...] I'm not sure I understand the juxtaposition of your expression of concern over "registration and dispatching policy" with the off-list mini-critique of a (possibly unpredictable) "priority" as the mechansim...? The provision of duplicate/overlapping registration and associated dispatching algorithms can be accommodated through other means, some with a higher degree of predictability at a lower "cost" (in complexity and bandwidth). At this time, the mechanism we have is "priority"...we are early enough into this process (even though our schedule says otherwise!) to keep the issue on the table just in case some more effective idea emerges and wins favor. I personally favor registration "precedence"...whether first-in-wins or last-in-wins...over "priority" as being more predictable and less costly. I definitely oppose any scheme which is based upon the system agent having to poll all component agents to find out which one supports an object (or an instance for that matter, in my extreme view)...unless we get this kind of operation down to the barest minimum number of cases where there just isn't any alternative to using it. And I do understand that the issues of registration and dispatching are not coterminous with priority, precedence, or any other such mechansim...i.e., there's much more that's involved...and I was just starting to address some of them in a response to an earlier posting from you on "MIBS in agentx" that I'll get back to now. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Wed, 17 Jan 1996 15:15:17 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id PAA16719 for X-agentx-local; Wed, 17 Jan 1996 15:15:15 -0800 (PST) Received: from seymour4 (seymour4.snmp.com [192.147.142.4]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id PAA16715 for ; Wed, 17 Jan 1996 15:15:14 -0800 (PST) From: case@snmp.com Received: by seymour4 (5.61++/2.8s-SNMP ) id AA13782; Wed, 17 Jan 96 18:05:50 -0500 Date: Wed, 17 Jan 96 18:05:50 -0500 Message-Id: <9601172305.AA13782@seymour4> To: agentx@fv.com Subject: Re: Some comments on "priority" (fwd) Mike writes: >In my opinion what's important (and emerging) is a picture >of how different reference implementations handle duplicate >and overlapping registration. >The discussion seems necessary to me because these details are >typically not specified as part of the on-the-wire protocol. >And it will be problematical if different compliant agentx system agents >exhibit different behavior when presented with the same component >agent configuration. Hence we need to specify registration and dispatching >policy as part of agentx. >I'd like to know how others feel about this. i think you are correct ... in a sense, we are talking about the difference between syntax (the on-the-wire protocol) and semantics both must be specified and implemented or the standard won't be rs232 is an example of half a standard in this regard regards, jdc   Delivery-Date: Thu, 18 Jan 1996 08:22:10 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id IAA20934 for X-agentx-local; Thu, 18 Jan 1996 08:22:09 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id IAA20924 for ; Thu, 18 Jan 1996 08:22:07 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA15579 for agentx@fv.com; Thu, 18 Jan 96 11:21:31 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA12180; Thu, 18 Jan 1996 11:20:08 -0500 Date: Thu, 18 Jan 1996 11:22:21 EST From: Bob Natale Subject: agentx (and related) wg meetings at LA IETF To: agentx@fv.com Cc: applmib@emi-summit.com, entmib@cisco.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi everyone, Our charter calls for wg meetings at the LA IETF and I believe that the current level and nature of discussion suggests that we will have a finite list of concrete decision points that we will be able to work on productively in face-to-face meetings at that time. I have received the following confirmation from the IETF Secretariat: > This is to confirm 2 sessions for AGENTX as follows: > > Tuesday, March 5 - 7:30-10:00pm (opposite RECEIPT) > Wednesday, March 6 - 3:30-5:30pm (opposite pkix,ipatm/rsvp/intserv) I asked for the slots to be fairly close together chronologically and to not interfere with the applmib and entmib meetings if at possible, since there is a fair amount of potential/probable synergy among them. Both requests have been met. The current overall schedule for these wg meetings is: Tue Mar 5 13:00-15:00 applmib 19:30-22:00 agentx Wed Mar 6 15:30-17:00 agentx 19:30-22:00 entmib Thu Mar 7 09:00-11:30 applmib 13:00-15:00 entmib I look forward to working with as many of you as can possibly make it to these meetings. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Fri, 19 Jan 1996 10:03:22 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id KAA18133 for X-agentx-local; Fri, 19 Jan 1996 10:03:21 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id KAA18112 for ; Fri, 19 Jan 1996 10:03:16 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA21459 for agentx@fv.com; Fri, 19 Jan 96 13:02:48 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA24306; Fri, 19 Jan 1996 13:01:27 -0500 Date: Fri, 19 Jan 1996 13:03:41 EST From: Bob Natale Subject: Re: MIBs in agentx - Part 1 To: Mike Daniele Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Mike Daniele > Date: Tue, 02 Jan 96 19:10:31 -0500 Hi Mike, [Speaking as a technical contributor...] Sorry to be responding to this more than two weeks later, but I've been giving this issue some more study. Your message was in reply to an earlier one of mine...in the first part of your reply, you critiqued the ideas I had expressed in the previous one; in the second part, you outlined how eSNMP handles some of the issues involved. I am only responding to the first part here and will respond to the second part in a separate message later. In that study time, I have reviewed very closely how SMUX, DPI-2, and eSNMP handle registration operations. The result of that review, however, has been a strengthening of my belief that having the component agent indicate to the system agent the name of the MIB file it implements (see below before jumping to conclusions about what constitutes a "MIB file", please) as part of the "open" operation can yield a very big payoff. <...> > What if there is no MIB file, nor even a (conceptual) MIB > associated with the connection? [admittedly unlikely] More than unlikely...in my scheme, it is a requirement that a component agent have an associated "MIB file". This would seem to be a reasonable requirement, for an agent (even a component agent) should implement a MIB. And note that a MIB may have anywhere from 1 to n objects defined in it. > What if the component agent wishes to register only a > specific subtree within a MIB? [a real-world situation > i think we need to address] In that case, that subtree would constitute the entire contents (minus standard MIB identification and format stuf) of the MIB file identified in the open operation. > At first glance, no problem. The component agent just > returns errors for the parts of the MIB it doesn't implement. I've avoided that nastiness, per above. (In general, I strongly oppose schemes which depend upon error returns from the component agents for navigation/dispatching.) > But what if a different component agent implements the > rest of the MIB? Again, no problem. The respective MIB file named by each in the open operation contains just those objects that the component agent implements. (We'll get to instance issues later). > This leads to some really fundamental questions that need > to be answered for agentx: > > o Will the system agent contain knowledge of > component MIBs? In my scheme, at runtime, yes. My scheme also *allows* for optimization (persistance) of much of these knowledge across invocations of the system agent and/or individual component agents. (Since MIB files are relatively static.) And, obviously, my schme also *allows* for the use of all info in the associated MIB file, above and beyond simply the object identifier(s). > o Will the protocol permit truly dynamic inclusion > of new component agents? I think it must. (I am not aware of anyone suggesting that this is not a requirement.) > o What is the unit of registration? There are two. The first is the individual object IDs, which are contained in the component agent's MIB file. Obviously, a system agent implementation will have a number of implementation-specific opportunities to optimize for either information richness or resource efficiency (e.g., memory) in deciding how to deal with this data. The second unit of registration is the instance. For scalar variables in the MIB file, the system agent knows the instance values (.0). (Don't hit me here, yet, with "what about multiple component agents registering for the same scalar variables?"...there are a variety of solutions available on this one ranging from "drop 'em", "stack 'em", "virtualize 'em", "EntityMIB 'em", and so forth...I'm not ready at the moment to pick an approach.) For instances in tables where only one component agent has registered, again, I see no problem. Foreknowledge of instances on the part of the system agent is not required in this case. For instances in "shared tables", I think an "index assignment" technique can work, in which the system agent presents "virtual index values" (transparently) to the management applications and maps these back to the (possibly duplicated) real index values when communicating with each component agent. (And this is the only case in which the "instance registration" operation-- which, in my scheme, *is* the Register operation found in SMUX, DPI, and eSNMP--must be performed.) Before looking for the cases which might present problems for the above approach (an important exercise, I agree), just give some thought to how much it does for a user-scenario like a workstation with MIB-2, HR MIB, Printer MIB, and some (future) sysAppl MIB extensible agent requirements. (To the retort that "Yes, but I could do that pretty easily with SMUX's registration mechanisms" the follow-up is "Yes, but my scheme is more efficient (fewer protocol transactions) and has tremendously more *potential* value (in the form of the MIB knowledge available to the system agent)". ...?) > o What rules (algorithms) are specified around > registration? I've outlined some aspects of the associated "elements of procedure" above...or is this question asking for something else? > o Are "instance registrations" allowed, and if so, > how are they handled? Yes. See above. > o How are MIB views handled? In my scheme, MIB views are created/managed/implemented at the system agent level...this is the only place where management apps have access...and I'm assuming that we won't build an agentx with a dependency on out-of-band local configuration of component agents. <...> > >Looks to me like an easy and efficient way for the system > >agent to acquire lots of "MIB knowledge" about its component > >agents...with high on-the-fly performance for the normal > >case. Of course, this all goes back to my fundamental > >views on the advisability of instance-level registration, > >piggy-backing on the need for the component agent to provide > >a MIB file for use by the management applications anyway, > >and leveraging the SNMP protocol as the foundation for the > >agentx protocol. > > I really agree with most everything you say. I disagree with your > assumption of what "the normal case" is, and hence with the viability > of making a scheme like this into the standard. I think a few > contributors now have pointed out real flaws with the idea that > the system agent knows about all instances of everything. There was one that I acknowledged as a serious problem (and every solution deployed or proposed so far exhibits at least one serious problem!)...namely, large and highly volatile data sets (such as processes in the HR MIB). However, now that I have thought about it some more, I can limit this even further by saying "large and highly volatile data sets that represent *shared* tables implemented by more than one component agent concurrently". Perfect instance fore- knowledge is *not* required in the system agent for objects in tables that are not shared, irrespective of their size and/or volatility. This *may* severely reduce the candidate population of problematic data sets. And, if it gets small enough, the cost/benefit ratio *may* clearly favor the trade-off I am suggesting. > It would render some very real, existing MIB implementations > virtually impossible to build according to agentx. I am not sure it's a requirement to be able to replicate any and all "existing MIB implementations" as agentx component agents. *Some* existing implementations will likely have to be modified (i.e., re-engineered) to comply with agnetx, no matter what scheme we agree on in the end. If you can point to existing MIBs (or specific sections thereof) that you think would present a problem here, give me that info and I'll see if I can work through them. <...eSNMP-specific parts deferred to separate reply...> Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Fri, 19 Jan 1996 14:31:30 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id OAA23783 for X-agentx-local; Fri, 19 Jan 1996 14:31:29 -0800 (PST) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id OAA23779 for ; Fri, 19 Jan 1996 14:31:27 -0800 (PST) Received: from flume.zk3.dec.com by mail12.digital.com (5.65v3.2/1.0/WV) id AA22171; Fri, 19 Jan 1996 17:27:32 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA18892; Fri, 19 Jan 1996 17:27:31 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA13251; Fri, 19 Jan 1996 17:27:55 -0500 Message-Id: <9601192227.AA13251@bernie.zk3.dec.com> To: Bob Natale Cc: agentx@fv.com Subject: Re: MIBs in agentx - Part 1 In-Reply-To: Your message of "Fri, 19 Jan 96 13:03:41 EST." Date: Fri, 19 Jan 96 17:27:54 -0500 From: Mike Daniele X-Mts: smtp Hi Bob, >Sorry to be responding to this more than two weeks later, >but I've been giving this issue some more study. I quite understand :-) But I think the time lag has caused a bit of disconnect. For one thing, the series of questions I posed were of a very general nature intended to promote general discussion. They were not directly related to your proposal. In the interim, we've answered several of them. >> I really agree with most everything you say. I disagree with your >> assumption of what "the normal case" is, and hence with the viability >> of making a scheme like this into the standard. I think a few >> contributors now have pointed out real flaws with the idea that >> the system agent knows about all instances of everything. >There was one that I acknowledged as a serious problem (and >every solution deployed or proposed so far exhibits at least >one serious problem!)...namely, large and highly volatile >data sets (such as processes in the HR MIB). However, now >that I have thought about it some more, I can limit this >even further by saying "large and highly volatile data sets >that represent *shared* tables implemented by more than >one component agent concurrently". Perfect instance fore- >knowledge is *not* required in the system agent for objects >in tables that are not shared, irrespective of their size >and/or volatility. What I was referring to (and perhaps I was in error by not being up to date on your ideas) was the scheme in which o all instances of all variables are registered with the system agent o the system agent does not convey Next or Bulk semantics to component agents, since it knows all instances of all objects it handles the request semantics and simply sends Gets to component agents I still maintain that this idea is much more complicated and is immensely less efficient than letting component agents instantiate their own objects and handle Next/Bulk themselves. >> It would render some very real, existing MIB implementations >> virtually impossible to build according to agentx. >I am not sure it's a requirement to be able to replicate >any and all "existing MIB implementations" as agentx component >agents. *Some* existing implementations will likely have to >be modified (i.e., re-engineered) to comply with agnetx, no >matter what scheme we agree on in the end. I contend that it would be extremely difficult (if possible) to build a good implementation of RFC 1213 on a typical server, given the constraints listed above. In my mind, this fact alone is reason enough to reject the proposal unless there is some corresponding huge advantage, and I don't see the huge advantage. That said, I don't *think* you're promoting both those ideas any more. As I understand it, you're proposing registration by the on-disk location of a file containing a (possibly partial) MIB spec, instead of registration by (subtree) oid. The system agent parses the spec and registers the object(s) it defines. This would still result in possible duplicate and overlapping registered subtrees, right? >Before looking for the cases which might present >problems for the above approach (an important >exercise, I agree), just give some thought to how >much it does for a user-scenario like a workstation >with MIB-2, HR MIB, Printer MIB, and some (future) >sysAppl MIB extensible agent requirements. (To >the retort that "Yes, but I could do that pretty >easily with SMUX's registration mechanisms" the >follow-up is "Yes, but my scheme is more efficient >(fewer protocol transactions) and has tremendously >more *potential* value (in the form of the MIB >knowledge available to the system agent)". ...?) I don't see exactly how this particular example has fewer protocol transactions than DPI-like registration of the same 4 MIBs. But I don't think registration is where we need to worry about performance. (I also add for the record that your scheme now requires the system agent to parse MIB files during registration instead of simply parsing an agentx message, isn't this a performance loss?) > My scheme also *allows* for optimization (persistance) of >much of these knowledge across invocations of the system >agent and/or individual component agents. (Since MIB >files are relatively static.) >And, obviously, my schme also *allows* for the use of >all info in the associated MIB file, above and beyond >simply the object identifier(s). One advantage I can see is the system agent would then understand the substructure of the shared tables, and could use this knowledge (probably combined with a priori knowledge of instances per component agent) when dispatching. But I believe Randy's suggestion of registering 'regular expression oids' does the same thing. I think Randy also pointed out the ACCESS clause is only useful for a small part of processing Sets. Could you summarize what you think the benefits are? >The second unit of registration is the instance. >For scalar variables in the MIB file, the system >agent knows the instance values (.0). (Don't hit me >here, yet, with "what about multiple component agents >registering for the same scalar variables?"...there >are a variety of solutions available on this one >ranging from "drop 'em", "stack 'em", "virtualize 'em", >"EntityMIB 'em", and so forth...I'm not ready at the >moment to pick an approach.) >For instances in tables where only one component >agent has registered, again, I see no problem. >Foreknowledge of instances on the part of the >system agent is not required in this case. >For instances in "shared tables", I think an >"index assignment" technique can work, in which >the system agent presents "virtual index values" >(transparently) to the management applications >and maps these back to the (possibly duplicated) >real index values when communicating with each >component agent. (And this is the only case in I don't understand. Do you think you could reword this in terms of the registration and dispatching policy you propose? (As an example, I posted my understanding of the policies Jeff and Aleksey were defining.) I certainly agree with you that in cases of table sharing, if the system agent knows a priori what instances are 'in' what component agents, life would be good. Regards, Mike   Delivery-Date: Fri, 19 Jan 1996 23:34:02 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id XAA22435 for X-agentx-local; Fri, 19 Jan 1996 23:34:01 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id XAA22420 for ; Fri, 19 Jan 1996 23:33:57 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA17788 for agentx@fv.com; Sat, 20 Jan 96 02:31:23 -0500 Date: Sat, 20 Jan 1996 02:30:37 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA29548; Sat, 20 Jan 1996 02:30:37 -0500 Message-Id: <9601200730.AA29548@nips.acec.com> To: daniele@zk3.dec.com Subject: Re: MIBs in agentx - Part 1 Cc: agentx@fv.com > Date: Fri, 19 Jan 96 17:27:54 -0500 > From: Mike Daniele Hi Mike, > >Sorry to be responding to this more than two weeks later, > >but I've been giving this issue some more study. > > I quite understand :-) But I think the time lag has caused > a bit of disconnect. I hope not...(appearances can be deceiving!). > For one thing, the series of questions I posed were of a > very general nature intended to promote general discussion. That's my main intent at this time too. We need to get some of this issues moving toward resolution...sometimes setting up a stark alternative to critique can lead to openings in other positions. > They were not directly related to your proposal. Sorry. I misunderstood the context of your message, then. I did not take your questions as anything other than a set of valid, serious questions and meant to respond accordingly. I hope I did not convey some other tone or excessive "defensiveness"...? > In the interim, we've answered several of them. The postings have been informative...but I have not seen a clear trend toward coalesence (sp?) on specific choices... if you have discerned such a trend (or, better yet, several!), please summarize them for the list. <..> > What I was referring to (and perhaps I was in error by not > being up to date on your ideas) Well, that's not your fault!...I don't always make it possible to stay up to date on my ideas! :-) > was the scheme in which > > o all instances of all variables are registered with the > system agent I've reduced this to the case of shared tables only. > o the system agent does not convey Next or Bulk semantics > to component agents, since it knows all instances of all > objects it handles the request semantics and simply sends > Gets to component agents While that's music to my ears, in no longer requiring registration of instances for non-shared tables, I have to pass Next and Bulk onto the component agent(s) involved. > I still maintain that this idea is much more complicated I think I can empirically substantiate the contrary...but I'd rather not have to do that if the idea is going to fail at some lower level of analysis anyway. > and is immensely less efficient than letting component agents > instantiate their own objects In my schme: 1. Scalar objects do not require instance registration 2. Columnar objects in non-shared tables do not require instance registration 3. Columnar objects in shared tables do require instance registration... #1 and #2 are, I assume, unproblematic. #3 is, IMHO, immensely more efficient wrt "index sharing" than any of the forms of "test the component agents until you find the right one" or "make the component agents keep registering with a different index value until they hit an unused one". > and handle Next/Bulk themselves. Ok. Since I no longer seek instance registration for non-shared tables, I have to ass Next and Bulk onto the component agents for resolution. <...> > I contend that it would be extremely difficult (if possible) to > build a good implementation of RFC 1213 on a typical server, > given the constraints listed above. Given the additional explanation provided herein, do you still feel these "constraints" obtain? Maybe I'm being dense, but I just can't see the problem(s). > In my mind, this fact alone is reason enough to reject the > proposal unless there is some corresponding huge advantage, > and I don't see the huge advantage. The advantages include: - Using an "available resource" (i.e., the MIB file) - which contains all the information the system agent needs for selecting/dispatching among component agents (except instance values for shared tables) - which contains additional syntactical and semantic information which can be used for other purposes - which also defines what object identifiers are *not* implemented by a component agent - all of which can be conveyed in one transaction between the component agent and the system agent - and all of which, in the overwelmingly usual case, will be cached in an efficient format by the system agent after the first such transaction with any given component agent(s). > That said, I don't *think* you're promoting both those ideas > any more. Correct: Instance registration is now (just referring to my idea, of course) required *only* for objects in shared tables and Next and Bulk will be processed by the component agents. > As I understand it, you're proposing registration by the on-disk > location of a file containing a (possibly partial) MIB spec, > instead of registration by (subtree) oid. Yes. (Although I would not use such an implementation-specific term as "on-disk location"...but that will often be the case.) > The system agent parses the spec and registers the object(s) > it defines. Yes. Note that I would *expect* (although it would be an implementation decision) that they system agent would only have to parse a MIB file once, unless some form of implementation- specific inspection (e.g., file timestamp) showed it to have changed since the last invocation. > This would still result in possible duplicate and overlapping > registered subtrees, right? Yes. "Duplicates" present one set of problems/alternatives that are different from "overlapping" (in both the general case and in my scheme). Duplicate handling will essentially boil down to either an agentx policy (elements of procedure) or an Entity MIB like solution. Overlapping registrations do not present a problem when scalars or non-shared tables are involved...each component's MIB file contains just the objects it implements and there is no ambiguity. For the shared table form of overlap, instance registration is required. <...> > I don't see exactly how this particular example has fewer > protocol transactions than DPI-like registration of the same > 4 MIBs. But I don't think registration is where we need to > worry about performance. Literally speaking, I agree with that. However, it's the possible by-prodoct efficiencies in downstream operations that count. Knowing what objects are and *are not* implemented by a component agent can have significant benefits over knowing just which ones *might be*. Furthermore, the availability of the other syntactical and semantic info in the MIB files can lead to additional processing efficiencies wrt minimizing "will fail" transactions between the system agent and the component agents. > (I also add for the record that your scheme now requires the > system agent to parse MIB files during registration instead > of simply parsing an agentx message, isn't this a performance > loss?) For the first such transaction between the system agent and a component agent, yes. But, as explained above, in the overwelmingly usual case, this is a one-time event. As I said in the earlier message (>>): >> My scheme also *allows* for optimization (persistance) of >>much of these knowledge across invocations of the system >>agent and/or individual component agents. (Since MIB >>files are relatively static.) > >>And, obviously, my schme also *allows* for the use of >>all info in the associated MIB file, above and beyond >>simply the object identifier(s). > > One advantage I can see is the system agent would then > understand the substructure of the shared tables, and could > use this knowledge (probably combined with a priori knowledge > of instances per component agent) when dispatching. Correct. > But I believe Randy's suggestion of registering 'regular > expression oids' does the same thing. Perhaps. I believe the overall benefits of the approach I am proposing tilt the scales in its favor however. > I think Randy also pointed out the ACCESS clause is only > useful for a small part of processing Sets. It is its most obvious usefulness. There are other signifcant *potential* uses (possibly implementation-specific) for any/all of the syntactical and semantic info in the MIB files. > Could you summarize what you think the benefits are? Due to my irritating long-windedness, let me just point to the answers I've given above in the message...and suggest one more tie-in benefit: I would contend that they system agent needs knowledge of the component agent MIBs anyway to enable overall in-band view/access configuration. <...> > >For instances in "shared tables", I think an > >"index assignment" technique can work, in which > >the system agent presents "virtual index values" > >(transparently) to the management applications > >and maps these back to the (possibly duplicated) > >real index values when communicating with each > >component agent. (And this is the only case in > > I don't understand. Do you think you could reword this in > terms of the registration and dispatching policy you propose? > (As an example, I posted my understanding of the policies Jeff > and Aleksey were defining.) Again, in the interest of short-windedness, I will defer an answer to this one for now. Oh well, maybe just a short one... I'm saying that for shared tables, the system agent--based on its MIB knowledge--can assign index values for presentation to the management apps and can map these assigned values to the real values used by any component agentts which have registered instances in this shared table. (Instance registration is performed via the Register operation from component to system agent.) In this way, component agents don't have to worry at all about index value conflicts with other component agents using the same shared table. This looks, to me, to be easy and efficient...all around. > I certainly agree with you that in cases of table sharing, > if the system agent knows a priori what instances are 'in' what > component agents, life would be good. For efficiency's sake, there is no alternative. Having MIB syntax/semantic knowledge up front makes it farily easy for the system agent to handle. Using "virtual index values" in the system agent which map to the real index values registered by the component agents makes it painless for the component agents to share tables and maintains the transparency principle vis-a-vis the management applications. Hey, it's 2:30 am! I gotta get to bed! Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Mon, 22 Jan 1996 15:44:46 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id PAA24481 for X-agentx-local; Mon, 22 Jan 1996 15:44:45 -0800 (PST) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id PAA24471 for ; Mon, 22 Jan 1996 15:44:43 -0800 (PST) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id SAA16283; Mon, 22 Jan 1996 18:39:42 -0500 Received: from avalon.nexen.com (avalon.nexen.com [204.249.99.77]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id SAA05432; Mon, 22 Jan 1996 18:34:30 -0500 Received: (from greene@localhost) by avalon.nexen.com (8.6.12/8.6.12) id SAA00163; Mon, 22 Jan 1996 18:45:34 -0500 Date: Mon, 22 Jan 1996 18:45:34 -0500 From: Maria Greene Message-Id: <199601222345.SAA00163@avalon.nexen.com> To: randy@dorothy.peer.com (Randy Presuhn) cc: agentx@fv.com Subject: Index Sharing In-Reply-To: <9601130337.AA25802@dorothy.peer.com> References: <9601130337.AA25802@dorothy.peer.com> Randy Presuhn writes: > Hi - > > I apologize in advance for the length of this contribution. OK, it *is* a little long, which is my excuse for taking a while to respond to it. Excuse me if I chop out some parts that I'm not commenting on. > > I'd like to share some notes on the index sharing problem. Others have > touched on the topic and I think we're getting to the point where we > can address it in earnest. I consider this problem tougher than others > we've talked about, but I think we can bludgeon it into submission. > > Customers tell me there is a market requirement for this capability. > I believe them, and would like to hear what others think. Yes. I am implementing a large, complicated agent using distributed agent technology. This capability is a must have. > > Enjoy. > > > > For general background, RFC 1573 is highly recommended reading. I second this! > The following general approaches have been suggested: > - put everything into proxies > - solve for specific cases, e.g., ifIndex > - solve for general case > > Putting everything into proxies is not a realistic solution. Doing > so pushes the problem of determining the relationships among entries > in various tables from the agent system to the manager-role system, > which is even less likely to have the information needed to make such > a determination. I agree with this most whole-heartedly! > > Solving for specific cases, such as ifIndex, works better, but does > not provide any way to handle future MIBs, which might require sharing > indexes which have not been defined at the time a master agent is built. > > Solving for the general case is hardest of all, especially if the details > of index allocation are confused with other issues in the design of > agent/subagent protocols. Yes, and there've been several examples of this confusion. Based on my experience I would say that providing a solution for the ifIndex case covers 80% of the problem. It would also provide a model that could be used for the other cases. In our implementation, one of our subagents (the one that supports the ifNumber attribute) is the "keeper" of the ifIndex name-space. This subagent doesn't actually provide instrumentation for any interface instances, it just acts as central arbiter when subagents need "blocks" of ifIndexes. The benefit of having this service be part of the agentx protocol would be that it would make it easier to implement RFC1595 correctly (including the ifStackTable) in open systems. We have found it very useful to have the "master agent -> subagent protocol" also work "subagent -> subagent", at least for GET and GETNEXT/BULK. Our subagents use GET-NEXT to find out about potential lower-layer interfaces that they can be "stacked above" and maintain their own entries in the ifStackTable, for example. > > Proposal: > Add the index services described above to subagent protocol. > It is important that these services be done in such a way as to > not add undue complexity to set processing or the protocol > state space. It may make sense to treat it as having a state > space of its own, allowing complete asynchronicity to other > protocol operations other than session establishment and > termination. I agree. I think solving the problem for distributing support for the ifTable amongst subagents is a good place to start. Our implementation has proven that it's really not that difficult. I don't want Randy's comprehensive analysis to lead people to believe it's very complicated and through the baby out with the bathwater. (Randy, I think your contribution was excellent, but I don't want to repeat that too much lest people think this is really from BobN. :-) > -------------------------------------------------------------------------- > Randy Presuhn PEER Networks, a division of BMC Software, Inc. > Voice: +1 408 556-0720 1190 Saratoga Avenue, Suite 130 > Fax: +1 408 556-0735 San Jose, California 95129-3433 > Email: randy@peer.com USA > -------------------------------------------------------------------------- Maria ________________________________________________________________________ Maria N. Greene greene@nexen.com Ascom Nexion 289 Great Rd., Acton MA 01720 USA +1 508 266-4570   Delivery-Date: Mon, 22 Jan 1996 23:34:40 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id XAA07398 for X-agentx-local; Mon, 22 Jan 1996 23:34:39 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id XAA07392 for ; Mon, 22 Jan 1996 23:34:36 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA23883 for agentx@fv.com; Tue, 23 Jan 96 02:31:51 -0500 Date: Tue, 23 Jan 1996 02:31:06 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA19497; Tue, 23 Jan 1996 02:31:06 -0500 Message-Id: <9601230731.AA19497@nips.acec.com> To: greene@nexen.com Subject: Re: Index Sharing Cc: agentx@fv.com > Date: Mon, 22 Jan 1996 18:45:34 -0500> > From: Maria Greene > Hi Maria, [Speaking as a technical contributor...] <...much agreeable stuff deleted...> > > = Randy > > Solving for the general case is hardest of all, especially if > > the details of index allocation are confused with other issues > > in the design of agent/subagent protocols. > > > Yes, and there've been several examples of this confusion. It might help (us to avoid them henceforth) if you pointed these out in specific detail. > Based on my experience I would say that providing a solution for > the ifIndex case covers 80% of the problem. It would also provide > a model that could be used for the other cases. I believe that a general solution that works for all cases is available...and has been proposed...albeit perhaps not in sufficient detail (! :-)...namely: - system agent knowledge of component agent MIBs (for index structure and semantics; - via component agent "MIB files" (where such files consist of at least one object def); - index "assignment" by the system agent for rows in shared tables (i.e., any table "registered" for in more than one component agent MIB file); - such "assignment" is only visible to the management applications (where it is transparent); - and is mapped back to real index values (instances) when the system agent communicates with the component agent (which knows nothing about the mapping); - this implies that, in addition to registration "en masse" via the MIB file, component agents need to register instances *for shared tables only*. > In our implementation, one of our subagents (the one that supports > the ifNumber attribute) is the "keeper" of the ifIndex name-space. > This subagent doesn't actually provide instrumentation for any > interface instances, it just acts as central arbiter when subagents > need "blocks" of ifIndexes. Substitute the system agent for your "keeper" sub-agent, add some of the bullets above for generality beyond ifIndex, and you've described my scheme, it seems. > The benefit of having this service be part of the agentx protocol > would be that it would make it easier to implement RFC1595 correctly > (including the ifStackTable) in open systems. I think it's necessary for efficient "table sharing" (i.e., where different rows are instantiated by different component agents who do not (necessarily) have any knowledge of each other), across the board. > We have found it very useful to have the "master agent -> subagent > protocol" also work "subagent -> subagent", at least for GET and > GETNEXT/BULK. Our subagents use GET-NEXT to find out about potential > lower-layer interfaces that they can be "stacked above" and maintain > their own entries in the ifStackTable, for example. Right...but I think this should be conceptualized (at least) as "component agent <-> sytem agent <-> component agent"...and, in many cases of shared tables in my scheme it would more simply be resolved at the "component agent <-> system agent" interface. > > > > > Proposal: > > Add the index services described above to subagent protocol. > > It is important that these services be done in such a way as to > > not add undue complexity to set processing or the protocol > > state space. It may make sense to treat it as having a state > > space of its own, allowing complete asynchronicity to other > > protocol operations other than session establishment and > > termination. > > > I agree. I think solving the problem for distributing support for the > ifTable amongst subagents is a good place to start. Our implementation > has proven that it's really not that difficult. I don't want Randy's > comprehensive analysis to lead people to believe it's very complicated > and through the baby out with the bathwater. Ok. It seems we all agree on the need for this in agentx. I believe that I have proposed a method of providing these "index services". I don't *think* I've seen another method proposed for doing it. (Acknowledging, per above, that the approach you implemented, Maria, seems to me to be the "moral equivalent".) If mine is deficient, then let's see some others. If it is eventually determined that my proposed approach is at least workable, then I would point to the other derivative benefits that can come from fuller MIB awareness on the part of the system agent to further bolster the proposal. > (Randy, I think your contribution was excellent, Me too! > but I don't want to repeat that too much lest people think this is > really from BobN. :-) Me neither! Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Director | 209 Perry Pkwy | 301-921-0434 [f] Network Mgmt Products | Gaithersburg MD 20877 | natale@acec.com ----------------- NetPlus (r) "FCAPS" Applications -------------   Delivery-Date: Tue, 23 Jan 1996 05:04:18 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id FAA03926 for X-agentx-local; Tue, 23 Jan 1996 05:04:18 -0800 (PST) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id FAA03921 for ; Tue, 23 Jan 1996 05:04:17 -0800 (PST) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.6.12/8.6.12) with ESMTP id HAA18027 for ; Tue, 23 Jan 1996 07:59:12 -0500 Received: from avalon.nexen.com (avalon.nexen.com [204.249.99.77]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id HAA10233 for ; Tue, 23 Jan 1996 07:54:00 -0500 Received: (from greene@localhost) by avalon.nexen.com (8.6.12/8.6.12) id IAA00609; Tue, 23 Jan 1996 08:05:13 -0500 Date: Tue, 23 Jan 1996 08:05:13 -0500 From: Maria Greene Message-Id: <199601231305.IAA00609@avalon.nexen.com> To: agentx@fv.com Subject: Index Sharing In-Reply-To: <199601222345.SAA00163@avalon.nexen.com> References: <9601130337.AA25802@dorothy.peer.com> <199601222345.SAA00163@avalon.nexen.com> In my recent mail, in support of having index allocation be part of the agentx "solution space", I made the following statement: "The benefit of having this service be part of the agentx protocol would be that it would make it easier to implement RFC1595 correctly (including the ifStackTable) in open systems." Of course I meant "it would make it easier to implement RFC1573 correctly..." although it wouldn't hurt RFC1595 either! Maria   Delivery-Date: Tue, 23 Jan 1996 09:18:20 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id JAA25317 for X-agentx-local; Tue, 23 Jan 1996 09:18:19 -0800 (PST) Received: from europe.std.com (europe.std.com [192.74.137.10]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id JAA25311 for ; Tue, 23 Jan 1996 09:18:17 -0800 (PST) Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id MAA03607; Tue, 23 Jan 1996 12:18:20 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA03824; Tue, 23 Jan 1996 12:09:14 -0500 From: ralex@world.std.com (Aleksey Y Romanov) Message-Id: <199601231709.AA03824@world.std.com> Subject: Re: Index Sharing To: greene@nexen.com (Maria Greene) Date: Tue, 23 Jan 1996 12:09:14 -0500 (EST) Cc: agentx@fv.com In-Reply-To: <199601231305.IAA00609@avalon.nexen.com> from "Maria Greene" at Jan 23, 96 08:05:13 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > > In my recent mail, in support of having index allocation be part of > the agentx "solution space", I made the following statement: ??????? I am really puzzled here. It seems to me that in order for anything to become part of the 'solution space' it has to be: 1. Engineered 2. Implmented 3. Spec published IMHO, none of the above depends upon support expressed on the mailing list. > Maria Aleksey   Delivery-Date: Tue, 30 Jan 1996 13:19:42 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id NAA14575 for X-agentx-local; Tue, 30 Jan 1996 13:19:40 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id NAA14571 for ; Tue, 30 Jan 1996 13:19:38 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA19003 for ; Tue, 30 Jan 96 15:53:32 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA22346; Tue, 30 Jan 1996 15:52:11 -0500 Date: Tue, 30 Jan 1996 15:54:24 EST From: Bob Natale Subject: agentx/entmib relationship? To: Maria Greene Cc: James Watt , if-mib@dtl.labs.tek.com, entmib@cisco.com, agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Maria Greene > Date: Mon, 29 Jan 1996 09:53:14 -0500 (EST) > Subject: Re: ifmib dallas minutes Hi Maria, <...> >jw> I would assert that mapping from ifIndex -> physical entity >jw> is a fundamental requirement and _will_ get fixed. > > Yup, me too! I'm working on it. :-) There's a bit of confusion in the > Entity MIB WG about the scope of the ifTable/ifStackTable. If you have > an agent that supports multiple "logical entities" (e.g. two bridge > entities and a router entity), then you need multiple community > strings to be able to "name" a particular instance of a particular MIB > object. (E.g., "bridge1", "bridge2", "iprouter1" and "system", or you > could get away with "bridge2" and "system" if you only want to > configure the minimum number of community strings.) So, what entries > would you expect to see in the ifTable (and, by extension, in the > entIfMappingTable) if you sweep the table in the "system" scope? My > opinion is that you should see all of them -- that the ifTable and the > ifStackTable need to be "global" tables or they are not all that > useful. I agree with your opinion. And I'd suggest that what you want from such "global" tables is more likely to be achieved via the concept of "shared" tables as being discussed/debated on the agentx list. > What this breaks is agents that follow rules like a bridge's "bridge > port 1" is always associated with ifIndex.1. A "table sharing" solution which I have proposed (in conceptual terms) for agentx can avoid breaking those agents in that manner. Since this set of comments (originating on the if-mib list) and several others on this general thread on the entmib mailing list seem to touch upon some of the more recent threads on the agentx list (although it's been quiet for about a week now), I thought I'd offer an observation or two to either generate some synergy or some distinctions in the feedback. On one of the entmib exchanges, Keith made a comment that drew a distinction between agents implementing the entmib (as more or less stand-alone entities) and (component) agents developed for agentx (as "related" entities). (Heavily paraphrased from fleeting memory...apologies to Keith if I've got it all wrong!) After watching these discussions and doing my best to under- stand them...I'm not so sure there can be or should be such a distinction. It's really starting to seem like these two efforts should be more closely aligned. In particular, I'm beginning to suspect that any "system" implementing the entity mib should do so in the context of an agentx architecture ...with the "physical entity" realized by the "system agent" and the "logical entities" realized by the "component agents". And, likewise, any "intra-agent" MIB for agentx might draw heavily upon the entity MIB. *IF* that works, then I think that some of the discussion on the agentx list wrt "index sharing"...which is actually "table sharing with index assignment"...might apply to the ifIndex problem you are concerned with above. Namely, each bridge could use ifIndex.1 for its "bridge port 1"...but this would get mapped by the system agent to some other value for presentation to the management applications; and re-mapped back to the "real" value (i.e., "ifIndex.1") by the system agent when communicating with the logical entity's component agent. Note that--wrt shared tables, at least--this solution does not *require* the managemnet applications to be aware of different naming-scopes. And, as you pointed out in another posting on the entmib list, yes, this does require the systen agent to resemble a "mid-level-manager" in some (limited) respects. Anyway--in the interest of brevity! :-)--, I'll forego going into that aspect...and just put this general issue of the nature of the relationship between the entmib and agentx out there for comment.... Are the two efforts so distinct that they merit two separate WGs? Are they so similar that they should be merged? Are they close enough to warrant special efforts at alignment as we progress on the individual paths? <...> [Sincere apologies to all for the cross-post to if-mib, entmib, and agentx...I really have no idea of how many on each are subscribed to the others...I suspect it's a lot, but this will give those who might not be on one or two of them a chance to join in...I think alll follow up could be limited to either agentx or entmib (or both of those at the most).] Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Tue, 30 Jan 1996 13:48:48 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id NAA22581 for X-agentx-local; Tue, 30 Jan 1996 13:48:47 -0800 (PST) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id NAA22578 for ; Tue, 30 Jan 1996 13:48:47 -0800 (PST) Received: from [171.69.128.42] (gryphon.cisco.com [171.69.128.42]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id NAA29414; Tue, 30 Jan 1996 13:43:46 -0800 X-Sender: bstewart@puli.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Jan 1996 16:43:50 -0500 To: Bob Natale , Maria Greene From: bstewart@cisco.com (Bob Stewart) Subject: Re: agentx/entmib relationship? Cc: James Watt , if-mib@dtl.labs.TEK.COM, entmib@cisco.com, agentx@fv.COM At 3:54 PM 1/30/96, Bob Natale wrote: >and just put this general issue >of the nature of the relationship between the entmib and >agentx out there for comment.... Are the two efforts >so distinct that they merit two separate WGs? Are they >so similar that they should be merged? Are they close >enough to warrant special efforts at alignment as we >progress on the individual paths? To mix Entity MIB and agentx would be to mix architecture and implementation. The Entity MIB needs to supply certain types of information with some confidence that it can be implemented in various environments, from the simplest embedded system to a more complex host environment with parts from different vendors. This level of confidence is little different from that needed for other MIBs. Agentx is a standard way to deal with implementation problems in certain environments. It must be capable of supporting the existing SNMP architecture for protocol and MIBs. The Entity MIB is one it must consider. The Interface MIB is another that presents certain difficulties. In both cases this is because the present a seamless view of a system. Agentx is in the business of covering those seams in systems that have them. Bob   Delivery-Date: Tue, 30 Jan 1996 15:22:16 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id PAA17602 for X-agentx-local; Tue, 30 Jan 1996 15:22:15 -0800 (PST) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by zloty.fv.com (8.7.3/8.7.3) with ESMTP id PAA17584 for ; Tue, 30 Jan 1996 15:22:10 -0800 (PST) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.6.12) with ESMTP id SAA02538; Tue, 30 Jan 1996 18:14:50 -0500 (EST) Received: from avalon.nexen.com (avalon.nexen.com [204.249.99.77]) by maelstrom.nexen.com (8.6.12/8.6.12) with ESMTP id SAA07529; Tue, 30 Jan 1996 18:09:35 -0500 Received: (from greene@localhost) by avalon.nexen.com (8.7.3/8.6.12) id SAA03122; Tue, 30 Jan 1996 18:22:52 -0500 (EST) Date: Tue, 30 Jan 1996 18:22:52 -0500 (EST) From: Maria Greene Message-Id: <199601302322.SAA03122@avalon.nexen.com> To: bstewart@cisco.com (Bob Stewart) Cc: if-mib@dtl.labs.TEK.COM, entmib@cisco.com, agentx@fv.COM Subject: Re: agentx/entmib relationship? In-Reply-To: References: Bob Stewart writes: > At 3:54 PM 1/30/96, Bob Natale wrote: > >and just put this general issue > >of the nature of the relationship between the entmib and > >agentx out there for comment.... Are the two efforts > >so distinct that they merit two separate WGs? Are they > >so similar that they should be merged? Are they close > >enough to warrant special efforts at alignment as we > >progress on the individual paths? > > To mix Entity MIB and agentx would be to mix architecture and implementation. Yes, I agree with BobS completely. > > The Entity MIB needs to supply certain types of information with some > confidence that it can be implemented in various environments, from the > simplest embedded system to a more complex host environment with parts from > different vendors. This level of confidence is little different from that > needed for other MIBs. Yes, in particular, the Entity MIB allows you (the manager) to learn what hardware (physical entities) and network services (logical entities) are supported by the agent (which may be monolithic or may be a "system agent" and a set of "component agents"). > > Agentx is a standard way to deal with implementation problems in certain > environments. It must be capable of supporting the existing SNMP > architecture for protocol and MIBs. The Entity MIB is one it must > consider. The Interface MIB is another that presents certain difficulties. > In both cases this is because the present a seamless view of a system. > Agentx is in the business of covering those seams in systems that have > them. At the Dallas IETF, Brian O'Keefe made a presentation which tried to show how the implementation of a particular logical entity might actually be realized by several component agents. The seams between component agents are not necessarily the seams between MIBs or logical entities. > > Bob > > So, BobN, I think it's good that the agentx, entmib, and ifmib working groups are all active at the same time because there are certainly considerations that go across the groups, but I hope people don't confuse a logical entity with a component agent because they're really very different things. Maria   Delivery-Date: Wed, 31 Jan 1996 18:25:14 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id SAA27447 for X-agentx-local; Wed, 31 Jan 1996 18:25:13 -0800 (PST) Received: from hansons.demon.co.uk (hansons.demon.co.uk [158.152.246.152]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id SAA26939 for ; Wed, 31 Jan 1996 18:23:29 -0800 (PST) Date: Thu, 01 Feb 1996 01:27:05 GMT From: Iain@hansons.demon.co.uk (Iain K. Hanson) Reply-To: Iain@hansons.demon.co.uk Message-Id: <983@hansons.demon.co.uk> To: natale@acec.com, Maria Greene Cc: if-mib@dtl.labs.tek.com, entmib@cisco.com, agentx@fv.com Subject: Re: agentx/entmib relationship? X-Mailer: PCElm 1.10 Lines: 112 Hi Folks, I've only just got back onto these lists and not yet had time to do all my homework, but I beleive I have something relevant gere. In message Bob Natale writes: > > From: Maria Greene > > Date: Mon, 29 Jan 1996 09:53:14 -0500 (EST) > > Subject: Re: ifmib dallas minutes > > Hi Maria, > > <...> > >jw> I would assert that mapping from ifIndex -> physical entity > >jw> is a fundamental requirement and _will_ get fixed. > > > > Yup, me too! I'm working on it. :-) There's a bit of confusion in the > > Entity MIB WG about the scope of the ifTable/ifStackTable. If you have > > an agent that supports multiple "logical entities" (e.g. two bridge > > entities and a router entity), then you need multiple community > > strings to be able to "name" a particular instance of a particular MIB > > object. (E.g., "bridge1", "bridge2", "iprouter1" and "system", or you > > could get away with "bridge2" and "system" if you only want to > > configure the minimum number of community strings.) So, what entries > > would you expect to see in the ifTable (and, by extension, in the > > entIfMappingTable) if you sweep the table in the "system" scope? My > > opinion is that you should see all of them -- that the ifTable and the > > ifStackTable need to be "global" tables or they are not all that > > useful. BobN: > I agree with your opinion. And I'd suggest that what you want > from such "global" tables is more likely to be achieved via the > concept of "shared" tables as being discussed/debated on the > agentx list. > > > What this breaks is agents that follow rules like a bridge's "bridge > > port 1" is always associated with ifIndex.1. This does not need to be broken. BobN's explantion above seems a little light and I think I can expand on it a little ( for both agentx and entmib with an impact of the ifmib.[ all feed back welcome]) At the 'system' level, given two bridges and an iprouter with 2 interfaces each, I would expect to see six interfaces numbered 1 to 6. if bridge1 ( community/context/entity ) had two interfaces labeled 1 & 2 and bridge2 has 2 interfaces ( also ) labeled 1 & 2 and they shared if1 this would still all be consistent within their given contexts. ( i.e. you have multiple instances of the IF table ( not snmp instances but OO style ). This gives you a system if table, bridge1 if table and bridge2 table. I don't see any problem here from the agentx or entmib side of things but it may alter the semantics for the if side. In particular, for underlying IF rows, they would need to report the value of their counters relative to the context. So if bridge1 and bridge2 share if1 then MAC level packets for each would need to be relative to bridge1 or bridge2 and total mac packets would only be visable from the 'system' context. Perhaps a greater problem is that given a shared serial interface, ( for bridge1 & 2 ) one may want to use xon/xoff and the other hardware handshaking. To allow both to set this would seem to be asking for trouble. Whilst I can see other potential solutions, it would seem reasonable, in this senario for the control to be at the 'system' level. I'll save the agentx specifics for a seperate mail that is not cross-posted. > After watching these discussions and doing my best to under- > stand them...I'm not so sure there can be or should be such > a distinction. It's really starting to seem like these two > efforts should be more closely aligned. In particular, I'm > beginning to suspect that any "system" implementing the > entity mib should do so in the context of an agentx architecture > ...with the "physical entity" realized by the "system agent" > and the "logical entities" realized by the "component agents". > And, likewise, any "intra-agent" MIB for agentx might draw > heavily upon the entity MIB. In addition to BobS's comments ( which I entirely agree with ) I would suggest that there is a much greater likelyhood of agentx being reliant on the entity MIB than vice versa! Particularly give the poor mapping between entities/contexts and communities within the community model. > *IF* that works, then I think that some of the discussion > on the agentx list wrt "index sharing"...which is actually > "table sharing with index assignment"... [ much elided ] I don't see this as index sharring but as having seperate tables, where different indexes refer to the same interface/instance which could only ever be implemented by a single sub-agent or by passing logical pointers. This means that for agentx, the master agent does indeed know of all instances ( at least implicitly ) and that a pointer must be passed from one sub-agent so that for instance , a sub-agent implementing an IfEntry can update the interface counter. /ikh -- Iain K. Hanson