Delivery-Date: Sun, 10 Dec 1995 21:30:13 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.1/8.7.1) id UAA16868 for X-agentx-local; Sun, 10 Dec 1995 20:36:30 -0800 (PST) Received: from tsunami.dbc.mtview.ca.us (tsunami.fv.com [204.250.90.8]) by zloty.fv.com (8.7.1/8.7.1) with ESMTP id UAA16865 for ; Sun, 10 Dec 1995 20:36:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tsunami.dbc.mtview.ca.us (8.6.10/8.6.10) with ESMTP id UAA23417 for ; Sun, 10 Dec 1995 20:34:56 -0800 From: Marshall Rose To: agentx@fv.com Subject: agentx minutes MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <23374.818656324.0@dbc.mtview.ca.us> Date: Sun, 10 Dec 1995 20:34:55 -0800 Message-ID: <23416.818656495@dbc.mtview.ca.us> Sender: mrose@dbc.mtview.ca.us ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23374.818656324.1@dbc.mtview.ca.us> i'm trying an experiment. here are the minutes in HTML format. enjoy. please give me corrections by month's end. /mtr ps: i'm still poking around with the HTML->ASCII converter... ------- =_aaaaaaaaaa0 Content-Type: text/html; charset="us-ascii" Content-ID: <23374.818656324.2@dbc.mtview.ca.us> Minutes of the AgentX WG at the 34th IETF

minutes of the agentx wg

the agentx working group met for two sessions at the 34th IETF.

session 1

the first session was held on wednesday, december 6th at 1300.

there were no changes to the agenda published on november 27th.

the chair began with a presentation (also available in postscript) which:

  • reviewed the working group's charter;
  • described, in high-level terms, the multiple component problem; and,
  • reviewed previous IETF publications in this area.
there was considerable discussion with respect to the high-level description of the multiple component problem, and the resulting comments were incorporated into the presentation.

the chair called for presentations by interested parties.

jim west made a presentation describing his experiences with packet-based multiplexing:

  • use of port 161 is driving the need for sub-agents
  • independent functional entities are best implemented using packet-based multiplexing:
    • the "real" snmp agent is started on a non-standard port;
    • the proxy-agent listens on port 161, and forwards requests to proxy-targets based on community name; and,
    • if the community is unknown, the request is forwarded to the original agent.
  • limitations to this approach are:
    • there is no "standard" API for component developers
    • moving the "real" snmp agent to another port is problematic in some environments, e.g.,
      • if the agent reads a configuration file to determine its port number, then other processes on that system (e.g. management applications) will malfunction if the configuration file is altered; but,
      • if the agent has the port number hard-coded, then its object code must be patched directly.

bert wijnen made a presentation describing his experiences with variable-based multiplexing:

  • too many interfaces for component developers is the driving force
  • in developing his approach, DPI, he sought to:
    • hide complexity from the component developer;
    • split the core of the agent code from the instrumentation;
    • require no modifications of management applications; and,
    • provide a "drop-in" solution for component developers
  • his approach is targeted for developers of non-network related components
  • his approach is documented as RFC 1592

with only a few minutes left, the chair asked for other presentations to be made in the second session. in the interim, there was some general discussion on whether management applications could support multiple community strings when communicating with the same agent.

session 2

the second session was held on friday, december 8th at 0900.

the chair indicated that he was stepping down at the end of this meeting, and that bob natale is the new chair. bob natale indicated that, due to an unfortunate, scheduling conflict, would leave an hour early. regardless, the meeting would run until its scheduled completion.

jeff case made a presentation describing his experiences with variable-based multiplexing:

  • the need for implementation standard MIB modules is the driving force
  • in developing his approach, EMANATE, he sought to:
    • achieve source code portability and binary interoperability;
    • achieve compliance with both the SMI and the protocol (e.g., support multi-phase operators); and,
    • achieve flexibility by utilizing the most efficient communications facilities available on the target platform.
  • his approach supports environments in which there is interaction between multiple MIB modules which may be cooperatively realized by multiple implementation units
  • his approach takes a programmatic, rather than a protocol approach, and hence is not openly published

randy presuhn made a presentation describing ongoing work in the area of variable-based multiplexing:

  • the work focused on issues of both correctness ("as if simultaneous") and performance (optimizing multi-phase operations)
  • he suggested that the key issues were developing:
    • a set of service requirements;
    • a service definition (i.e., an abstract api); and,
    • a specification for the protocol used for intra-agent communication.

brian o'keefe made a presentation in which he suggested that the working group distinguish between

  • logical entities, which implement functional components, and contain a system group; and,
  • implementation units, which are realized by sub-agents.
for example, a managed system might contain four logical entities: itself, a router, and two bridges; further, the two bridge entities might be realized by three implementational units, one of which is shared between the two logical entities. although there needn't be any logical structure imposed on how implementation units comprise functional components, an important question is whether there a one-to-one or a one-to-many relationship between an operational scope and a logical entity. it was noted that this dichotomy helps to explain the difficulties in implementing interMIB relationships.

prior to leaving, the new chair presented a few thoughts on the agentx working group:

  • he would ask the area director to appoint a facilitator for the working group, to oversee both content discussion and process;
  • the working group should focus on the solution space;
  • any working group-approved solution should be based on a developed and published specification;
  • he preferred a "bottom-up" approach towards a solution; and,
  • he felt the working group should leverage SNMP whenever possible.

dan romanscieu made a presentation describing his experiences with variable-based multiplexing:

  • his approach sought to:
    • minimize the number of managed elements visible to management applications;
    • provide an alternate multiplexing agent in case of failure; and,
    • require only minimal configuration.
  • he expressed concern over the difficulty of mapping MIB modules onto implementational units
  • in view of his experiences, he felt that the working group's goals were ambitious

finally, there was group discussion on the issues presented:

  • one thread dealt with the issue as to the merits of the information hiding approach implicit with variable-based multiplexing, versus the information publication approach implicit with packet-based multiplexing.
    in particular, dave bridgham and randy presuhn presented conflicting arguments as to these merits. (a voluntary action has been assigned asking each participant to post concise summaries of their positions.)
  • a second thread dealt with the issues as to the difference between the information selection inherent with packet-based multiplexing, versus the information integration inherent with variable-based multiplexing.
    for example, a service provider might provision a customer-specific subset of the available management information based on community string.
  • a third thread dealt the goal of the working group, viz. to allow multiple, independent contributors to implement a single system.
    further, three functional requirements were identified:
    • applicable system types (outside the scope of the working group);
    • consistency with overall framework; and,
    • end-to-end performance.

action items

the chair assigned the following voluntary actions:
aleksey romanov
please provide the working group with a URL for the proposal on agent extensibility that you posted some time ago.
all presenters (actually just bert wijnen, jeff case, dan romanscieu, and brian o'keefe)
please send ascii, postscript, or html versions of your presentation to the chair, so that your presentation may be included in the ftp archive
dave bridgham and randy presuhn
please post concise summaries of your position with respect to the efficacy of the proxy approach to the mailing list
andy bierman, editor for the entity mib working group
please consider the relationship between packet-based multiplexing and the logical entity table, especially how proxy relates to chaining or referal of requests to logical entities

marshall t. rose
Last modified: Sun Dec 10 20:29:19 PST 1995 ------- =_aaaaaaaaaa0--   Delivery-Date: Mon, 11 Dec 1995 15:32:24 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.1/8.7.1) id OAA09309 for X-agentx-local; Mon, 11 Dec 1995 14:34:44 -0800 (PST) Received: from hp.com (hp.com [15.255.152.4]) by zloty.fv.com (8.7.1/8.7.1) with ESMTP id OAA09299 for ; Mon, 11 Dec 1995 14:34:43 -0800 (PST) Received: from nsmdserv.cnd.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA170231297; Mon, 11 Dec 1995 14:34:58 -0800 Received: from localhost by nsmdserv.cnd.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA295731297; Mon, 11 Dec 1995 15:34:57 -0700 Message-Id: <199512112234.AA295731297@nsmdserv.cnd.hp.com> To: Marshall Rose Cc: agentx@fv.com Subject: Re: agentx minutes In-Reply-To: Your message of Sun, 10 Dec 1995 20:34:55 -0800. <23416.818656495@dbc.mtview.ca.us> Date: Mon, 11 Dec 1995 15:34:57 -0700 From: "Brian O'Keefe" The presentation I gave on Friday morning that is referenced in the meeting minutes was on behalf of Andy Bierman, Maria Greene, Dave Perkins as well as myself. Thanks to Maria for producing the slides. Regards, bok   Delivery-Date: Mon, 11 Dec 1995 18:32:58 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.1/8.7.1) id RAA13888 for X-agentx-local; Mon, 11 Dec 1995 17:36:54 -0800 (PST) Received: from tsunami.dbc.mtview.ca.us (tsunami.fv.com [204.250.90.8]) by zloty.fv.com (8.7.1/8.7.1) with ESMTP id RAA13882 for ; Mon, 11 Dec 1995 17:36:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tsunami.dbc.mtview.ca.us (8.6.10/8.6.10) with ESMTP id RAA05191; Mon, 11 Dec 1995 17:28:04 -0800 To: "Brian O'Keefe" cc: agentx@fv.com reply-to: agentx@fv.com Subject: Re: agentx minutes In-reply-to: Your message of "Mon, 11 Dec 1995 15:34:57 MST." <199512112234.AA295731297@nsmdserv.cnd.hp.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <5187.818731683.0@dbc.mtview.ca.us> Date: Mon, 11 Dec 1995 17:28:03 -0800 Message-ID: <5189.818731683@dbc.mtview.ca.us> From: Marshall Rose ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5187.818731683.1@dbc.mtview.ca.us> thanks, i've updated the minutes... /mtr ------- =_aaaaaaaaaa0 Content-Type: message/rfc822 Content-Description: original message Newsgroups: dbc Return-Path: Received: from hp.com (hp.com [15.255.152.4]) by tsunami.dbc.mtview.ca.us (8.6.10/8.6.10) with ESMTP id OAA03349 for ; Mon, 11 Dec 1995 14:34:21 -0800 Received: from nsmdserv.cnd.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA170231297; Mon, 11 Dec 1995 14:34:58 -0800 Received: from localhost by nsmdserv.cnd.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA295731297; Mon, 11 Dec 1995 15:34:57 -0700 Message-Id: <199512112234.AA295731297@nsmdserv.cnd.hp.com> To: Marshall Rose Cc: agentx@fv.com Subject: Re: agentx minutes In-Reply-To: Your message of Sun, 10 Dec 1995 20:34:55 -0800. <23416.818656495@dbc.mtview.ca.us> Date: Mon, 11 Dec 1995 15:34:57 -0700 From: "Brian O'Keefe" The presentation I gave on Friday morning that is referenced in the meeting minutes was on behalf of Andy Bierman, Maria Greene, Dave Perkins as well as myself. Thanks to Maria for producing the slides. Regards, bok ------- =_aaaaaaaaaa0--   Delivery-Date: Mon, 11 Dec 1995 18:53:00 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.1/8.7.1) id SAA25541 for X-agentx-local; Mon, 11 Dec 1995 18:39:11 -0800 (PST) Received: from europe.std.com (europe.std.com [192.74.137.10]) by zloty.fv.com (8.7.1/8.7.1) with SMTP id SAA25531 for ; Mon, 11 Dec 1995 18:39:10 -0800 (PST) Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id VAA26242; Mon, 11 Dec 1995 21:39:20 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA13073; Mon, 11 Dec 1995 21:31:29 -0500 From: ralex@world.std.com (Aleksey Y Romanov) Message-Id: <199512120231.AA13073@world.std.com> Subject: Re: agentx minutes To: agentx@fv.com Date: Mon, 11 Dec 1995 21:31:28 -0500 (EST) Cc: natale@acec.com X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, Latest published OAA specs are available at ftp://ftp.std.com/vendors/snmp/open-agent/oaa04.txt There is 0.5 draft which at ts final stages now. It does not contain prinicpal changes. Three most significant changes: 1. It is not SNMPv2-Classic specific admin-wise. 2. Sub-agents are mounted by sub-trees (as in alther schemes), instead of name ranges. 3. SET processing was stream-lined at the price of maginally more complicated sub agents. Aleksey P.S. On the subject of the discussion being held, IMHO, hiding complexity is not a worthy goal, because: (a) Developing SNMP specific code takes 5% while variable access takes 95% of efforts. (b) Complexity hiding is the most adequate task for code generators and thus is not related to the problem of agent extensibility.   Delivery-Date: Wed, 13 Dec 1995 10:34:04 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.1/8.7.1) id KAA20199 for X-agentx-local; Wed, 13 Dec 1995 10:22:38 -0800 (PST) Received: from seymour4 (seymour4.snmp.com [192.147.142.4]) by zloty.fv.com (8.7.1/8.7.1) with SMTP id KAA20193 for ; Wed, 13 Dec 1995 10:22:37 -0800 (PST) From: case@snmp.com Received: by seymour4 (5.61++/2.8s-SNMP ) id AA13562; Wed, 13 Dec 95 13:16:36 -0500 Date: Wed, 13 Dec 95 13:16:36 -0500 Message-Id: <9512131816.AA13562@seymour4> To: agentx@fv.com Subject: any progress on human readable minutes for review and comment? subject line says it all regards, jdc   Delivery-Date: Fri, 15 Dec 1995 12:30:57 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.1/8.7.1) id MAA21838 for X-agentx-local; Fri, 15 Dec 1995 12:18:15 -0800 (PST) Received: from inetgw.fsc.ibm.com (inetgw.lfs.loral.com [204.177.125.1]) by zloty.fv.com (8.7.1/8.7.1) with SMTP id MAA21833 for ; Fri, 15 Dec 1995 12:18:14 -0800 (PST) Received: by inetgw.fsc.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA50403; Fri, 15 Dec 1995 15:18:32 -0500 Received: from be02.fs.boulder.ibm.com(9.99.33.52) by inetgw.fsc.ibm.com via smap (V1.3) id sma037080; Fri Dec 15 15:17:53 1995 Received: by be02.fs.boulder.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA21550; Fri, 15 Dec 1995 13:16:53 -0700 From: "Carl Kugler" Message-Id: <9512151316.ZM13868@be02.fs.boulder.ibm.com> Date: Fri, 15 Dec 1995 13:16:52 -0700 X-Mailer: Z-Mail (3.2.0 06sep94) To: agentx@fv.com Subject: Use case analysis Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii I'm just jumping in here, having only reviewed the archives. I'm just thinking that in requirements analysis or definition, it's often helpful to look at use cases, or common applications. I can think of a few common applications of agent extensibility: 1) Managing external, non-SNMP hardware. For example, many networks contain communications links like microwave or satellite links. These typically involve racks of communications hardware like amplifiers, modems, up-converters, down-converters, cryptos, antennas, etc. Typically these devices present only RS-232 interfaces with unique status and control protocols. In order to be able to manage this gear remotely, you drop a workstation into the communication station and write a subagent to provide an SNMP interface to the serial devices. In these cases, it would be nice for the NMS to be able to discover these devices as separate, distinct entities that can be independently managed. 2) Critical applications. For example, a database server that you want to be able to monitor and control. In this case, you want the NMS to recognize that the server is contained in a computer and is dependent on the computer's resources. 3) Interfaces to other management systems. For example, BlueVision gateways, or various gateways to, say, mainframe SNA-type network managers. Here you have a proxy relaying information from another world of network management. Are these the kinds of applications you envision? Are there other applications? Is agentx adequately addressing the requirements these types of applications present? Carl Kugler carlk@lfs.loral.com   Delivery-Date: Fri, 15 Dec 1995 13:58:23 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id NAA14153 for X-agentx-local; Fri, 15 Dec 1995 13:53: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 NAA14148 for ; Fri, 15 Dec 1995 13:53:25 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA20444 for agentx@fv.com; Fri, 15 Dec 95 16:53:32 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA21959; Fri, 15 Dec 1995 16:52:07 -0500 Date: Fri, 15 Dec 1995 16:54:27 EST From: Bob Natale Subject: Addressing the Solution Space To: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi Everyone, Hopefully, eveyrone has had a chance to review the minutes that Marshall posted. If not, please do. On the whole, the Dallas meetings contained a very high signal-to-noise ratio. Our charter does not give us a lot of leisurely ramp up time--which is fair considering how long we've been pursuing the objective of a standard for extensible SNMP agent technology. Our first set of I-Ds is to be posted by the end of this month. Per the charter, we have one mandatory goal: "o (mandatory) a platform-independent protocol which supports intra-agent communication within a device or local area network;" Our job now is to get that done. One of the strategies I outlined--very briefly--just before having to leave Friday's meeting early was that we should focus on the "solution space" rather than the "problem space". To keep the explanation of that short, I recommend that everyone read Herman van der Linde's thesis, "Evaluation and specification of the extensible agent protocol", which is available at: file://ftp.cs.utwente.nl:/pub/src/snmp/thesis/Linde.ps Or follow the links from http://wwwsnmp.cs.utwente.nl/UT-SNMP into "The Documents" into "Third Generation". The main purpose of reviewing this thesis is to examine the tables which show the protocol operations and parameters supported by the set of protocols covered in the thesis; namely: SMUX, DPI, UT-SNMP, and OAA. I invite anyone else with a protocol proposal (or updated versions of any of those four) to provide similarly structured data. The objective is to build as large as possible empirical base as quickly as possible. I will concurrently work on normalizing that data into a common format (as a set of tables similar to Herman's). I hope to publish a normalized view of Herman's tables on Monday. I will do my best to incorporate any others that are submitted in a timely fashion. It will be most beneficial to have inputs--structured per above--from persons knowledgeable about deployed protocols...but that is really not meant to discourage the submission of new protocol proposals. The point is that the installed base represented by the deployed protocols is fairly large and constitutes a *potentially* viable "solution space". Perhaps we can utilize this empirical, comparative approach to identify and remove the weaker aspects of each, to identify and leverage the common aspects of them all, and to identify and optimize for the stronger aspects of each. My hope (belief, expectation) is that we will thereby identify a solution space that covers a large enough portion of the problem space to win consensus as the first concrete strep toward meeting our mandatory goal. None of the above is meant to rule out discussion of the "problem space"--requirements, architecture, cross- effects, implementation concerns, etc.--or any of the "optional" goals (which tend to concern the so-called "whole product" solution which must ultimately be delivered to the user community in some fashion). All of that is welcome, but will (have to) take a back seat relative to focusing on the "solution space" as a means of ensuring that we will meet our mandatory goal. Have a good weekend! 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: Sun, 17 Dec 1995 05:17:02 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id FAA02366 for X-agentx-local; Sun, 17 Dec 1995 05:04:29 -0800 (PST) Received: from dw3f.ess.harris.com (dw3f.ess.harris.com [130.41.9.242]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id FAA02363 for ; Sun, 17 Dec 1995 05:04:28 -0800 (PST) Received: from sur3g4 (sur3g4 [130.41.34.18]) by dw3f.ess.harris.com (8.6.9/mdb(941103)) with SMTP id IAA03950 for ; Sun, 17 Dec 1995 08:04:18 -0500 From: James White Received: by sur3g4 (5.x) id AA22624; Sun, 17 Dec 1995 08:04:41 -0500 Date: Sun, 17 Dec 1995 08:04:41 -0500 Message-Id: <9512171304.AA22624@sur3g4> To: agentx@fv.com Subject: subscribe X-Sun-Charset: US-ASCII   Delivery-Date: Mon, 18 Dec 1995 16:17:19 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id PAA09373 for X-agentx-local; Mon, 18 Dec 1995 15:49:38 -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 PAA09367 for ; Mon, 18 Dec 1995 15:49:36 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA19356 for agentx@fv.com; Mon, 18 Dec 95 18:49:46 -0500 Date: Mon, 18 Dec 1995 18:47:53 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA07573; Mon, 18 Dec 1995 18:47:53 -0500 Message-Id: <9512182347.AA07573@nips.acec.com> To: agentx@fv.com Subject: ASCII format IETF meeting minutes As requested by members of the wg, I've converted Marshall's notes from HTML to ASCII. I've made no content changes and only minor punctuation/formatting changes. If my HTML to ASCII converter messed anything up, please accept my apologies. BobN - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Minutes of the AgentX WG at the 34th IETF the agentx working group met for two sessions at the 34th IETF. session 1 the first session was held on wednesday, december 6th at 1300. there were no changes to the agenda published on november 27th. the chair began with a presentation (also available in postscript) which: reviewed the working group's charter; described, in high-level terms, the multiple component problem; and, reviewed previous IETF publications in this area. there was considerable discussion with respect to the high-level description of the multiple component problem, and the resulting comments were incorporated into the presentation. the chair called for presentations by interested parties. jim west made a presentation describing his experiences with packet-based multiplexing: use of port 161 is driving the need for sub-agents independent functional entities are best implemented using packet-based multiplexing: the real snmp agent is started on a non-standard port; the proxy-agent listens on port 161, and forwards requests to proxy-targets based on community name; and, if the community is unknown, the request is forwarded to the original agent. limitations to this approach are: there is no standard API for component developers moving the real snmp agent to another port is problematic in some environments, e.g., if the agent reads a configuration file to determine its port number, then other processes on that system (e.g. management applications) will malfunction if the configuration file is altered; but, if the agent has the port number hard-coded, then its object code must be patched directly. bert wijnen made a presentation describing his experiences with variable-based multiplexing: too many interfaces for component developers is the driving force in developing his approach, DPI, he sought to: hide complexity from the component developer; split the core of the agent code from the instrumentation; require no modifications of management applications; and, provide a drop-in solution for component developers his approach is targeted for developers of non-network related components his approach is documented as RFC 1592 with only a few minutes left, the chair asked for other presentations to be made in the second session. in the interim, there was some general discussion on whether management applications could support multiple community strings when communicating with the same agent. session 2 the second session was held on friday, december 8th at 0900. the chair indicated that he was stepping down at the end of this meeting, and that bob natale is the new chair. bob natale indicated that, due to an unfortunate, scheduling conflict, would leave an hour early. regardless, the meeting would run until its scheduled completion. jeff case made a presentation describing his experiences with variable-based multiplexing: the need for implementation standard MIB modules is the driving force in developing his approach, EMANATE, he sought to: achieve source code portability and binary interoperability; achieve compliance with both the SMI and the protocol (e.g., support multi-phase operators); and, achieve flexibility by utilizing the most efficient communications facilities available on the target platform. his approach supports environments in which there is interaction between multiple MIB modules which may be cooperatively realized by multiple implementation units his approach takes a programmatic, rather than a protocol approach, and hence is not openly published randy presuhn made a presentation describing ongoing work in the area of variable-based multiplexing: the work focused on issues of both correctness (as if simultaneous) and performance (optimizing multi-phase operations) he suggested that the key issues were developing: a set of service requirements; a service definition (i.e., an abstract api); and, a specification for the protocol used for intra-agent communication. brian o'keefe made a presentation in which he suggested that the working group distinguish between logical entities, which implement functional components, and contain a system group; and, implementation units, which are realized by sub-agents. for example, a managed system might contain four logical entities: itself, a router, and two bridges; further, the two bridge entities might be realized by three implementational units, one of which is shared between the two logical entities. although there needn't be any logical structure imposed on how implementation units comprise functional components, an important question is whether there a one-to-one or a one-to-many relationship between an operational scope and a logical entity. it was noted that this dichotomy helps to explain the difficulties in implementing interMIB relationships. prior to leaving, the new chair presented a few thoughts on the agentx working group: he would ask the area director to appoint a facilitator for the working group, to oversee both content discussion and process; the working group should focus on the solution space; any working group-approved solution should be based on a developed and published specification; he preferred a bottom-up approach towards a solution; and, he felt the working group should leverage SNMP whenever possible. dan romanscieu made a presentation describing his experiences with variable-based multiplexing: his approach sought to: minimize the number of managed elements visible to management applications; provide an alternate multiplexing agent in case of failure; and, require only minimal configuration. he expressed concern over the difficulty of mapping MIB modules onto implementational units in view of his experiences, he felt that the working group's goals were ambitious finally, there was group discussion on the issues presented: one thread dealt with the issue as to the merits of the information hiding approach implicit with variable-based multiplexing, versus the information publication approach implicit with packet-based multiplexing. in particular, dave bridgham and randy presuhn presented conflicting arguments as to these merits. (a voluntary action has been assigned asking each participant to post concise summaries of their positions.) a second thread dealt with the issues as to the difference between the information selection inherent with packet-based multiplexing, versus the information integration inherent with variable-based multiplexing. for example, a service provider might provision a customer-specific subset of the available management information based on community string. a third thread dealt the goal of the working group, viz. to allow multiple, independent contributors to implement a single system. further, three functional requirements were identified: applicable system types (outside the scope of the working group); consistency with overall framework; and, end-to-end performance. action items the chair assigned the following voluntary actions: aleksey romanov please provide the working group with a URL for the proposal on agent extensibility that you posted some time ago. all presenters (actually just bert wijnen, jeff case, dan romanscieu, and brian o'keefe) please send ascii, postscript, or html versions of your presentation to the chair, so that your presentation may be included in the ftp archive dave bridgham and randy presuhn please post concise summaries of your position with respect to the efficacy of the proxy approach to the mailing list andy bierman, editor for the entity mib working group please consider the relationship between packet-based multiplexing and the logical entity table, especially how proxy relates to chaining or referal of requests to logical entities marshall t. rose Last modified: Sun Dec 10 20:29:19 PST 1995 HTML -> ASCII, with minor editing, by Bob Natale on 12/18/95 18:30 EST   Delivery-Date: Tue, 19 Dec 1995 18:17:16 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id RAA24407 for X-agentx-local; Tue, 19 Dec 1995 17:49:09 -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 RAA24399 for ; Tue, 19 Dec 1995 17:49:08 -0800 (PST) Received: by dorothy.peer.com (4.1/SMI-4.1) id AA17571; Tue, 19 Dec 95 17:48:45 PST Date: Tue, 19 Dec 95 17:48:45 PST From: randy@peer.com (Randy Presuhn) Message-Id: <9512200148.AA17571@dorothy.peer.com> To: agentx@fv.com Subject: When proxy? Hi - As requested, here are some paragraphs giving a view of when subagent and proxy technologies are appropriate. This is far more verbose than I would like. This builds heavily on Brian's presentation. However, I've mangled his terminology. Comments and clarifications would be helpful! I'm sending an alternative presentation which some find easier to parse separately. =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Proxy can work when the three conditions outlined below are met. When these three conditions aren't met, per-varbind subagent functionality is needed. Some seemingly "monolithic" agents employ implementation strategies that are effectively (ad hoc or proprietary) subagent mechanisms for handling inter-process information transfer. The question then becomes one of choosing between ad hoc, proprietary, and open solutions to coordinating the information needed to provide coherent logical entities and to meet the protocol requirements for an operational (naming) scope. 1) Proxy requires that the structure of the instrumentation implementation directly reflects the logical structure assumed by the relevant definitions of management information. E.g., different rows, columns, or AUGMENTs of a table are not implemented in different processes. 2) Proxy requires that the structure of the instrumentation implementation directly reflects that of the set of operational scopes assumed by management. (An "operational scope" {or "naming scope"} is the set of information that may be potentially accessed through a single SNMP operation. {Actually, it's a union of non-disjoint subsets, since it's rare for a single PDU to be able to hold all the information accessible within an operational scope.} Think of a walk of an SNMPv2 context, without access control semantics.) For proxy to work, a single operational scope cannot provide access to instrumentation from multiple processes, and, logically related information from a single process cannot be visible in distinct operational scopes. (Think about the "as if simultaneous" requirement for operations with side-effects to see why.) The ifStackTable, ifTable, and related MIBs have rather strong implications about what might show up in a single operational scope. 3) To be usable, proxy requires that manager-role systems are able to synthesize an image of the managed systems as a whole from the various pieces visible through the various operational scopes. Issues here, falling into the entity MIB work, include: - discovering the set of DISTINCT operational scopes (naming versus (authentication => access control) semantics of community strings) - discovering logical relationships between operational scopes =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Note also that an ideal subagent protocol allows a given operational scope to gain the appearance of meeting these conditions. As a result, I believe it is perfectly reasonable for both proxy and subagent technologies to be used in a single system. I'm leaving the access control administration issues out; I believe the subagent approaches result in better access control scalability. That's a separate can of red herring, however. :-) -------------------------------------------------------------------------- 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: Tue, 19 Dec 1995 18:17:17 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id RAA24628 for X-agentx-local; Tue, 19 Dec 1995 17:50:09 -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 RAA24622 for ; Tue, 19 Dec 1995 17:50:07 -0800 (PST) Received: by dorothy.peer.com (4.1/SMI-4.1) id AA17654; Tue, 19 Dec 95 17:49:44 PST Date: Tue, 19 Dec 95 17:49:44 PST From: randy@peer.com (Randy Presuhn) Message-Id: <9512200149.AA17654@dorothy.peer.com> To: agentx@fv.com Subject: When Proxy? (in pictures) Hi - Here's an alternative way of looking at the question of when proxy is a viable solution. This uses an E-R-like approach. The main reason to distinguish between "operational scope" (naming scope imposed by the protocol) and "logical entity" (management information abstraction) here is to emphasize the point that we have plenty of MIB definitions, such as ifTable, ifStackTable, and so on, that effectively require there to be multiple logical entities within a single operational scope. There are other mibs, such as the hub mib, that effectively require multiple operational scopes in order to access what, from at least some perspectives, is a single logical entity. The general form of the relationship is: provides instrumented +-------------+ access +---------+ by +----------------+ | Operational |____________| Logical |______________| Implementation | | Scope | ?:? | Entity | ?:? | Component | +-------------+ +---------+ +----------------+ The deciding factor is the cardinality of relationship between the operational scope and the underlying instrumentation implementation components. There are various ways of looking at this relationship; which one is more convenient depends on the specific case. +----------------------------------------+ | provides |instrumented | +-------------+ access +---------+| by +----------------+ | | Operational |____________| Logical ||_____________| Implementation | | | Scope | ?:? | Entity || ?:? | Component | | +-------------+ +---------+| +----------------+ +----------------------------------------+ +--------------------------------------------+ provides | instrumented | +-------------+ access |+---------+ by +----------------+ | | Operational |___________|| Logical |______________| Implementation | | | Scope | ?:? || Entity | ?:? | Component | | +-------------+ |+---------+ +----------------+ | +--------------------------------------------+ Each of these relations may be 1:1, 1:many, many:1, or many:many. This leads to lots of combinations, but, fortunately, we can collapse some of them. For example, all cases of the following form are unsuitable for proxy: +--------------------------------------------+ provides | instrumented | +-------------+ access |+---------+ by +----------------+ | | Operational |___________|| Logical |______________| Implementation | | | Scope | ?:? || Entity | ?:many | Component | | +-------------+ |+---------+ +----------------+ | +--------------------------------------------+ All cases of the following form are potentially candidates for proxy: +----------------------------------------+ | provides |instrumented | +-------------+ access +---------+| by +----------------+ | | Operational |____________| Logical ||_____________| Implementation | | | Scope | ?:? | Entity || ?:1 | Component | | +-------------+ +---------+| +----------------+ +----------------------------------------+ A few specific ILLUSTRATIONS follow: ============================================================================ Proxy can work: +-------------+ +---------+ +----------------+ | Operational |____________| Logical |______________| Implementation | | Scope | 1:1 | Entity | 1:1 | Component | +-------------+ +---------+ +----------------+ An operational scope allows access to a single logical entity realized by a single underlying implementation. ============================================================================ Proxy can work: +-------------+ +---------+ +----------------+ | Operational |__________/| Logical |\_________| Implementation | | Scope | 1:many \| Entity |/ many:1 | Component | +-------------+ +---------+ +----------------+ An operational scope allows access to multiple logical entities, all of which are realized by a single underlying imeplementation. ============================================================================ Proxy can work: +-------------+ +-------------+| +---------+ +----------------+ | Operational ||\___________| Logical |______________| Implementation | | Scope ||/ many:1 | Entity | 1:1 | Component | +-------------+ +---------+ +----------------+ Multiple operational scopes are used to access what from a management perspective is a single logical entity. The current hub mib is an example of this. ============================================================================ Proxy can work: +------------------------------------------+ | | | +-------------+ +---------+ | +----------------+ | | Operational |___________/| Logical | |___________| Implementation | | | Scope | 1:many \| Entity | | 1:1 | Component | | +-------------+ +---------+ | +----------------+ | | +------------------------------------------+ Multiple logical entities are accessible within an operational scope, all supported by a single underlying implementation. ============================================================================ Proxy Does not Work: +----------------+ +-------------+ +---------+ +----------------+| | Operational |____________| Logical |_____________/| Implementation || | Scope | 1:1 | Entity | 1:many \| Component |+ +-------------+ +---------+ +----------------+ The underlying implementation for a single logical entity requires multiple processes / vendor supplied components. ============================================================================ Proxy does not work: +------------------------------------------+ | | | +-------------+ +---------+ | +----------------+ | | Operational |___________/| Logical | |__________/| Implementation | | | Scope | 1:many \| Entity | | 1:many \| Component | | +-------------+ +---------+ | +----------------+ | | +------------------------------------------+ The underlying implementation for a set of logical entities accessible within a single operational scope requires multiple processes or vendor-supplied components. -------------------------------------------------------------------------- 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, 20 Dec 1995 01:17:08 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id AAA09852 for X-agentx-local; Wed, 20 Dec 1995 00:20:50 -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 AAA09849 for ; Wed, 20 Dec 1995 00:20:44 -0800 (PST) Received: from gandalf (world.lannet.com) by aristo.tau.ac.il with SMTP id AA29156 (5.67b/IDA-1.5 for ); Wed, 20 Dec 1995 10:20:39 +0200 Received: from moon.lannet.com by gandalf (4.1/SMI-4.1) id AA11947; Wed, 20 Dec 95 10:22:00 IST Received: from smtplink.lannet.com by moon.lannet.com (4.1/SMI-4.1) id AA23190; Wed, 20 Dec 95 10:18:52 IST Received: from Connect2 Message Router by smtplink.lannet.com via Connect2-SMTP 4.00; Wed, 20 Dec 95 10:21:39 -0500 Message-Id: In-Reply-To: <7115D830010CB6AA> Date: Wed, 20 Dec 95 10:21:07 -0500 From: Dan Romascanu Sender: Dan Romascanu Organization: Lannet Ltd. To: agentx@fv.com, randy@peer.com (Randy Presuhn) Subject: Re: When Proxy? (in pictures) X-Mailer: Connect2-SMTP 4.00 MHS to SMTP Gateway Randy, > There are other mibs, such as the hub mib, >that effectively require multiple operational scopes in order to access >what, from at least some perspectives, is a single logical entity. Using multiple community strings (well, operational scopes...) in order to multiplex repeaters in the same hub, was just one of the methods implementors were forced to use in order to correct a major bug in the Hub MIB. The new version of the Hub MIB, under discussion in the Hub MIB will correct this bug. As a general rule, there is no reason to manage repeaters with multiple operational scopes, if this bug is corrected. Dan   Delivery-Date: Wed, 20 Dec 1995 08:17:07 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id HAA13931 for X-agentx-local; Wed, 20 Dec 1995 07:37:34 -0800 (PST) Received: from dime.fv.com (dime.fv.com [204.250.90.7]) by zloty.fv.com (8.7.3/8.7.1) with ESMTP id HAA13928 for ; Wed, 20 Dec 1995 07:37:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by dime.fv.com (8.7.3/8.6.10) with ESMTP id HAA11177 for ; Wed, 20 Dec 1995 07:36:58 -0800 (PST) Message-Id: <199512201536.HAA11177@dime.fv.com> X-Mailer: exmh version 1.6.5 12/8/95 To: agentx@fv.com Reply-To: "Mike D. Kail" Subject: (fwd) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Dec 1995 07:36:58 -0800 From: "Mike D. Kail" ------- Forwarded Message Date: Wed, 20 Dec 1995 12:25:47 +0000 From: David_Beattie@tertio.demon.co.uk To: agentx-owner@zloty.fv.com Subject: cc:Mail SMTPLINK Undeliverable Message To: agentx@fv.com Subject: When proxy? Hi - As requested, here are some paragraphs giving a view of when subagent and proxy technologies are appropriate. This is far more verbose than I would like. This builds heavily on Brian's presentation. However, I've mangled his terminology. Comments and clarifications would be helpful! I'm sending an alternative presentation which some find easier to parse separately. =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Proxy can work when the three conditions outlined below are met. When these three conditions aren't met, per-varbind subagent functionality is needed. Some seemingly "monolithic" agents employ implementation strategies that are effectively (ad hoc or proprietary) subagent mechanisms for handling inter-process information transfer. The question then becomes one of choosing between ad hoc, proprietary, and open solutions to coordinating the information needed to provide coherent logical entities and to meet the protocol requirements for an operational (naming) scope. 1) Proxy requires that the structure of the instrumentation implementation directly reflects the logical structure assumed by the relevant definitions of management information. E.g., different rows, columns, or AUGMENTs of a table are not implemented in different processes. 2) Proxy requires that the structure of the instrumentation implementation directly reflects that of the set of operational scopes assumed by management. (An "operational scope" {or "naming scope"} is the set of information that may be potentially accessed through a single SNMP operation. {Actually, it's a union of non-disjoint subsets, since it's rare for a single PDU to be able to hold all the information accessible within an operational scope.} Think of a walk of an SNMPv2 context, without access control semantics.) For proxy to work, a single operational scope cannot provide access to instrumentation from multiple processes, and, logically related information from a single process cannot be visible in distinct operational scopes. (Think about the "as if simultaneous" requirement for operations with side-effects to see why.) The ifStackTable, ifTable, and related MIBs have rather strong implications about what might show up in a single operational scope. 3) To be usable, proxy requires that manager-role systems are able to synthesize an image of the managed systems as a whole from the various pieces visible through the various operational scopes. Issues here, falling into the entity MIB work, include: - discovering the set of DISTINCT operational scopes (naming versus (authentication => access control) semantics of community strings) - discovering logical relationships between operational scopes =-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Note also that an ideal subagent protocol allows a given operational scope to gain the appearance of meeting these conditions. As a result, I believe it is perfectly reasonable for both proxy and subagent technologies to be used in a single system. I'm leaving the access control administration issues out; I believe the subagent approaches result in better access control scalability. That's a separate can of red herring, however. :-) -------------------------------------------------------------------------- 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 -------------------------------------------------------------------------- - ---------------- 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@zloty.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@zloty.fv.com Thank you.) ------- End of Forwarded Message -- /*----------------------------------------------------------*/ /* Mike D. Kail | voice: (619) 793-3359 */ /* System Administrator | fax: (619) 793-2950 */ /* FIRST VIRTUAL Holdings Inc. | e-mail: mdkail@fv.com */ /*----------------------------------------------------------*/   Delivery-Date: Wed, 20 Dec 1995 08:17:08 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id HAA14038 for X-agentx-local; Wed, 20 Dec 1995 07:38:06 -0800 (PST) Received: from dime.fv.com (dime.fv.com [204.250.90.7]) by zloty.fv.com (8.7.3/8.7.1) with ESMTP id HAA14034 for ; Wed, 20 Dec 1995 07:38:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by dime.fv.com (8.7.3/8.6.10) with ESMTP id HAA11188 for ; Wed, 20 Dec 1995 07:37:30 -0800 (PST) Message-Id: <199512201537.HAA11188@dime.fv.com> X-Mailer: exmh version 1.6.5 12/8/95 To: agentx@fv.com Reply-To: "Mike D. Kail" Subject: (fwd #2) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Dec 1995 07:37:30 -0800 From: "Mike D. Kail" ------- Forwarded Message Date: Wed, 20 Dec 1995 12:25:57 +0000 From: David_Beattie@tertio.demon.co.uk To: agentx-owner@zloty.fv.com Subject: cc:Mail SMTPLINK Undeliverable Message Date: Tue, 19 Dec 95 17:49:44 PST From: randy@peer.com (Randy Presuhn) Message-Id: <9512200149.AA17654@dorothy.peer.com> To: agentx@fv.com Subject: When Proxy? (in pictures) Hi - Here's an alternative way of looking at the question of when proxy is a viable solution. This uses an E-R-like approach. The main reason to distinguish between "operational scope" (naming scope imposed by the protocol) and "logical entity" (management information abstraction) here is to emphasize the point that we have plenty of MIB definitions, such as ifTable, ifStackTable, and so on, that effectively require there to be multiple logical entities within a single operational scope. There are other mibs, such as the hub mib, that effectively require multiple operational scopes in order to access what, from at least some perspectives, is a single logical entity. The general form of the relationship is: provides instrumented +-------------+ access +---------+ by +----------------+ | Operational |____________| Logical |______________| Implementation | | Scope | ?:? | Entity | ?:? | Component | +-------------+ +---------+ +----------------+ The deciding factor is the cardinality of relationship between the operational scope and the underlying instrumentation implementation components. There are various ways of looking at this relationship; which one is more convenient depends on the specific case. +----------------------------------------+ | provides |instrumented | +-------------+ access +---------+| by +----------------+ | | Operational |____________| Logical ||_____________| Implementation | | | Scope | ?:? | Entity || ?:? | Component | | +-------------+ +---------+| +----------------+ +----------------------------------------+ +--------------------------------------------+ provides | instrumented | +-------------+ access |+---------+ by +----------------+ | | Operational |___________|| Logical |______________| Implementation | | | Scope | ?:? || Entity | ?:? | Component | | +-------------+ |+---------+ +----------------+ | +--------------------------------------------+ Each of these relations may be 1:1, 1:many, many:1, or many:many. This leads to lots of combinations, but, fortunately, we can collapse some of them. For example, all cases of the following form are unsuitable for proxy: +--------------------------------------------+ provides | instrumented | +-------------+ access |+---------+ by +----------------+ | | Operational |___________|| Logical |______________| Implementation | | | Scope | ?:? || Entity | ?:many | Component | | +-------------+ |+---------+ +----------------+ | +--------------------------------------------+ All cases of the following form are potentially candidates for proxy: +----------------------------------------+ | provides |instrumented | +-------------+ access +---------+| by +----------------+ | | Operational |____________| Logical ||_____________| Implementation | | | Scope | ?:? | Entity || ?:1 | Component | | +-------------+ +---------+| +----------------+ +----------------------------------------+ A few specific ILLUSTRATIONS follow: =========================================================================== = Proxy can work: +-------------+ +---------+ +----------------+ | Operational |____________| Logical |______________| Implementation | | Scope | 1:1 | Entity | 1:1 | Component | +-------------+ +---------+ +----------------+ An operational scope allows access to a single logical entity realized by a single underlying implementation. =========================================================================== = Proxy can work: +-------------+ +---------+ +----------------+ | Operational |__________/| Logical |\_________| Implementation | | Scope | 1:many \| Entity |/ many:1 | Component | +-------------+ +---------+ +----------------+ An operational scope allows access to multiple logical entities, all of which are realized by a single underlying imeplementation. =========================================================================== = Proxy can work: +-------------+ +-------------+| +---------+ +----------------+ | Operational ||\___________| Logical |______________| Implementation | | Scope ||/ many:1 | Entity | 1:1 | Component | +-------------+ +---------+ +----------------+ Multiple operational scopes are used to access what from a management perspective is a single logical entity. The current hub mib is an example of this. =========================================================================== = Proxy can work: +------------------------------------------+ | | | +-------------+ +---------+ | +----------------+ | | Operational |___________/| Logical | |___________| Implementation | | | Scope | 1:many \| Entity | | 1:1 | Component | | +-------------+ +---------+ | +----------------+ | | +------------------------------------------+ Multiple logical entities are accessible within an operational scope, all supported by a single underlying implementation. =========================================================================== = Proxy Does not Work: +----------------+ +-------------+ +---------+ +----------------+| | Operational |____________| Logical |_____________/| Implementation || | Scope | 1:1 | Entity | 1:many \| Component |+ +-------------+ +---------+ +----------------+ The underlying implementation for a single logical entity requires multiple processes / vendor supplied components. =========================================================================== = Proxy does not work: +------------------------------------------+ | | | +-------------+ +---------+ | +----------------+ | | Operational |___________/| Logical | |__________/| Implementation | | | Scope | 1:many \| Entity | | 1:many \| Component | | +-------------+ +---------+ | +----------------+ | | +------------------------------------------+ The underlying implementation for a set of logical entities accessible within a single operational scope requires multiple processes or vendor-supplied components. -------------------------------------------------------------------------- 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 -------------------------------------------------------------------------- - ---------------- 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@zloty.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@zloty.fv.com Thank you.) ------- End of Forwarded Message -- /*----------------------------------------------------------*/ /* Mike D. Kail | voice: (619) 793-3359 */ /* System Administrator | fax: (619) 793-2950 */ /* FIRST VIRTUAL Holdings Inc. | e-mail: mdkail@fv.com */ /*----------------------------------------------------------*/   Delivery-Date: Wed, 20 Dec 1995 11:17:03 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id KAA15929 for X-agentx-local; Wed, 20 Dec 1995 10:29:56 -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 KAA15925 for ; Wed, 20 Dec 1995 10:29:56 -0800 (PST) Received: by dorothy.peer.com (4.1/SMI-4.1) id AA25790; Wed, 20 Dec 95 10:29:30 PST Date: Wed, 20 Dec 95 10:29:30 PST From: randy@peer.com (Randy Presuhn) Message-Id: <9512201829.AA25790@dorothy.peer.com> To: agentx@fv.com Subject: Re: When Proxy? (in pictures) Hi Dan - > From agentx-owner@zloty.fv.com Wed Dec 20 02:22:04 1995 > Date: Wed, 20 Dec 95 10:21:07 -0500 > From: Dan Romascanu > To: agentx@fv.com, randy@peer.com (Randy Presuhn) > Subject: Re: When Proxy? (in pictures) ... > Using multiple community strings (well, operational scopes...) in > order to multiplex repeaters in the same hub, was just one of the > methods implementors were forced to use in order to correct a > major bug in the Hub MIB. The new version of the Hub MIB, under > discussion in the Hub MIB will correct this bug. As a general rule, > there is no reason to manage repeaters with multiple operational > scopes, if this bug is corrected. ... True, as long as all the existing deployed units are upgraded and there aren't any other MIBs that have followed the same approach. I'm not too willing to bet on either one happening any time soon. :-) -------------------------------------------------------------------------- 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, 20 Dec 1995 13:17:04 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id MAA11765 for X-agentx-local; Wed, 20 Dec 1995 12:32:36 -0800 (PST) Received: from dub-img-6.compuserve.com (dub-img-6.compuserve.com [198.4.9.6]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id MAA11753 for ; Wed, 20 Dec 1995 12:32:34 -0800 (PST) Received: by dub-img-6.compuserve.com (8.6.10/5.950515) id PAA28453; Wed, 20 Dec 1995 15:32:51 -0500 Date: 20 Dec 95 15:29:37 EST From: Deepak Goel <75107.1302@compuserve.com> To: a Subject: Status of agentx! Message-ID: <951220202936_75107.1302_FHI59-1@CompuServe.COM> Hi All, I just came to know about this working group. Could someone please tell me what is the current status and when can we expect the first draft of the standard for agentx. Thanks, Deepak   Delivery-Date: Wed, 20 Dec 1995 14:17:48 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id NAA00314 for X-agentx-local; Wed, 20 Dec 1995 13:58:37 -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 NAA00307 for ; Wed, 20 Dec 1995 13:58:35 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA28682 for agentx@fv.com; Wed, 20 Dec 95 16:58:49 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA04680; Wed, 20 Dec 1995 16:56:19 -0500 Date: Wed, 20 Dec 1995 16:59:43 EST From: Bob Natale Subject: Re: Status of agentx! To: Deepak Goel <75107.1302@compuserve.com> Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Deepak Goel <75107.1302@compuserve.com> > Date: 20 Dec 95 15:29:37 EST Hi Deepak, > I just came to know about this working group. Welcome! > Could someone please tell me what is the current > status The wg is fairly newly chartered, but the subject matter has been under consideration by many of the participants for some time. Due to a change in personal plans, Marshall Rose resigned as chair as of Dec 8, and I now have that role. I anticipate having a Facilitator to oversee the process of the wg, and will likely ask for an Editor once the consensus-track draft(s) start(s) to take shape. > and when can we expect the first draft of the > standard for agentx. I have asked that we focus on the "solution space" defined (primarily) by the deployed extensible agent solutions. I have suggested that some initial comparative mapping of their messages, parameters, and operations might be a good starting point (and have referred people to Herman van der Linde's paper for initial background reading of this approach). I have asked for comparable/compatible inputs from vendors/designers of extensible agents not included in Herman's paper (he covers SMUX, DPI, OAA, UT-SNMP). I have committed to putting out a normalized summary of this information in the near future (actually, the recent past...but had an extremely busy last weekend!). Our charter includes only one *madatory* goal and that is the specification of the protocol to be used between the extensible agent (aka, master agent) and the component agents (aka, sub-agents). The initial draft of this protocol is to be posted by the end of December, and I am responsible for seeing that that happens...I will. (I may limit the initial posting to the wg mailing list rather than the official IETF repository, since time constraints might not allow for adequate wg quality control by then.) In the meantime, of course, all input is welcome... particularly that which focuses on the "solution space"...i.e., how currently deployed (or at least designed) extensible agent protocols work. I have received several off-list technical inputs from good people...but I would prefer that to the maximum extent possible everyone post their comments/contributions/ critiques to 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: Wed, 20 Dec 1995 20:17:42 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id TAA09746 for X-agentx-local; Wed, 20 Dec 1995 19:43:28 -0800 (PST) Received: from epilogue.com (quern.epilogue.com [128.224.1.136]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id TAA09738 for ; Wed, 20 Dec 1995 19:43:26 -0800 (PST) Received: from dab.gate.epilogue.com with DMSP Date: Wed, 20 Dec 95 20:40:58 -0700 From: David Bridgham To: agentx@fv.com Subject: management with a per-varbind multiplexing protocol Sender: dab@epilogue.com Repository: quern.epilogue.com Originating-client: gate.epilogue.com Message-ID: <9512202242.aa23275@quern.epilogue.com> Despite arguing furiously against using per-varbind multiplexing as a way to access multiple SNMP entities on a single device, I've helped design a shipping sub-agent protocol, evolve it, and have thought through many of the changes I'd make if I were to do it again. From all this effort on this thing that I think is such a bad idea, I've come to a few conclusions regarding what such a protocol would look like. In short, it's a superset of SNMP. In order to properly support SNMP it must support everything that SNMP does and use a very similar naming system. In addition, it needs locking and multiphase commit across multiple entities for proper execution of sets. It's either built on a reliable transport or reliability becomes a part of the spec rather than being left to the implementors, as in SNMP. Sub-agents are a bit more proactive in notifying the layer above them what MIBs they support, what instances they have, and what changes happen to them. In a world with this more powerful protocol, why would management stations speak SNMP? Why not just use the more capable protocol directly? Once all the effort has gone into figuring out the hard parts of the sub-agent protocol, adding the ability for multiple masters is likely straightforward. We also would have the opportunity to beef up the naming to better deal with name collisions of the multiple underlying entities (see previous message). Then a management station would take the role of a master and we would move SNMP to historic. Dave   Delivery-Date: Wed, 20 Dec 1995 20:17:43 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id TAA09736 for X-agentx-local; Wed, 20 Dec 1995 19:43:26 -0800 (PST) Received: from epilogue.com (quern.epilogue.com [128.224.1.136]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id TAA09709 for ; Wed, 20 Dec 1995 19:43:20 -0800 (PST) Received: from dab.gate.epilogue.com with DMSP Date: Wed, 20 Dec 95 20:05:17 -0700 From: David Bridgham To: agentx@fv.com Subject: position paragraphs Sender: dab@epilogue.com Repository: quern.epilogue.com Originating-client: gate.epilogue.com Message-ID: <9512202242.aa23273@quern.epilogue.com> Because of comments I made at the working group meeting in Dallas, I was asked to write up a couple of paragraphs stating my position. I've divided this message into two parts, different ways of looking at the issue. First a direct response to Marshall's request, then a philisophical look at SNMP's place in the world. ----------- Direct response My comments were made in reaction to statements of the form, "for case N, per-varbind multiplexing is required". Yet, in every case, per-packet multiplexing would also work. The only situation I've discovered so far that per-packet multiplexing can't easily handle, is different columns of a table being handled by different SNMP entities. In short, my position is that I have yet to hear a case that can't also be done with per-packet multiplexing, per-packet multiplexing neatly sidesteps problems inherent in per-varbind multiplexing, therefore the decision between the two, from a technical standpoint, is clear. ----------- Philosophy SNMP is a fairly low level, transaction protocol. It has limited sized packets, everything for a transaction must fit in a single packet, and its naming systems are suitable only for a single entity at a time. If I draw a chart of information flow in a management system, I get a tree with information sources at the leaves and a management station at the root. From the leaves up, there are various aggregation nodes with a selection node just before the root. Yes, a sophisticated management system would have a more complex picture than this but this will do for my purposes here. The arcs between nodes in the tree represent various mechanisms for information flow. In some cases network protocols, in others just internal function calls. Someone (I think Butler Lampson) once said that everything in computer science comes down to naming. The protocol or api between each node must be able to name everything below in the tree. SNMP's naming lets you specify an SNMP entity (through the transport naming and the community string) and a variable within that entity. Multiple SNMP entities will often implement the same variables causing naming ambiguities if they're aggregated and presented through SNMP. SNMP's design is best for transporting management information between the information sources and the lowest level aggregators. Not all of the information sources are reached via SNMP of course; dns, traceroute, icmp, and other protocols provide useful information too. David Bridgham   Delivery-Date: Thu, 21 Dec 1995 05:12:36 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id FAA09856 for X-agentx-local; Thu, 21 Dec 1995 05:12:36 -0800 (PST) Received: from saturn.landmark.com (landmark.com [192.246.113.2]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id FAA09848 for ; Thu, 21 Dec 1995 05:12:35 -0800 (PST) Received: from proda.landmark.com by saturn.landmark.com with SMTP id AA17257 (5.67b8/IDA-1.5 for ); Thu, 21 Dec 1995 08:12:49 -0500 Received: by proda.landmark.com with SMTP id AA21409 (5.67b8/IDA-1.5); Thu, 21 Dec 1995 08:12:48 -0500 Message-Id: <199512211312.AA21409@proda.landmark.com> X-Mailer: exmh version 1.5.3 12/28/94 To: Bob Natale Cc: agentx@fv.com, bobk@landmark.com Subject: Re: Status of agentx! In-Reply-To: Your message of "Wed, 20 Dec 1995 16:59:43 EST." Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Dec 1995 08:12:44 -0500 From: Bob Kuhfahl Forgive me for not knowing, but where can one obtain the recommended reading (Herman van der Linde's paper)? Thanks, Bob > > I have asked that we focus on the "solution space" > defined (primarily) by the deployed extensible > agent solutions. I have suggested that some initial > comparative mapping of their messages, parameters, > and operations might be a good starting point (and > have referred people to Herman van der Linde's > paper for initial background reading of this approach).   Delivery-Date: Thu, 21 Dec 1995 06:26:29 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id GAA21164 for X-agentx-local; Thu, 21 Dec 1995 06:26:29 -0800 (PST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id GAA21158 for ; Thu, 21 Dec 1995 06:26:27 -0800 (PST) Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelayMX-SVR4_1.2/RBINF) id PAA08302; Thu, 21 Dec 1995 15:26:02 +0100 Received: from dijkstra.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id PAA24766; Thu, 21 Dec 1995 15:25:58 +0100 Received: from localhost by dijkstra.cs.utwente.nl (SMI-8.6/SMI-SVR4) id PAA15935; Thu, 21 Dec 1995 15:25:58 +0100 Message-Id: <199512211425.PAA15935@dijkstra.cs.utwente.nl> To: Bob Kuhfahl cc: agentx@fv.com Subject: Re: Status of agentx! In-reply-to: Your message of Thu, 21 Dec 1995 08:12:44 EST From: f.p.h.vanHengstum@cs.utwente.nl Organisation: "Frederic P. H. van Hengstum" "Dept. of Computer Science" "P.O. Box 217, 7500 AE Enschede, The Netherlands" "+31 53 4892537, fax +31 53 4333815" "http://wwwtios.cs.utwente.nl/tios/dg/mgt/" "" Date: Thu, 21 Dec 1995 15:25:57 +0100 Sender: hengstum@cs.utwente.nl ---------------------------------CUT-HERE------------------------------------ Forgive me for not knowing, but where can one obtain the recommended reading (Herman van der Linde's paper)? Thanks, Bob > > I have asked that we focus on the "solution space" > defined (primarily) by the deployed extensible > agent solutions. I have suggested that some initial > comparative mapping of their messages, parameters, > and operations might be a good starting point (and > have referred people to Herman van der Linde's > paper for initial background reading of this approach). Hi, At url http://wwwsnmp.cs.utwente.nl/ section "UT-SNMP" project in then iun subsection "Documentation". Regards, Eric van Hengstum ---------------- 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@zloty.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@zloty.fv.com Thank you.) ---------------------------------CUT-HERE------------------------------------ If a train station is where a train stops, then what's a workstation ? Anonymous.   Delivery-Date: Thu, 21 Dec 1995 10:43:52 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id KAA06800 for X-agentx-local; Thu, 21 Dec 1995 10:43:52 -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 KAA06794 for ; Thu, 21 Dec 1995 10:43:51 -0800 (PST) Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id NAA13470; Thu, 21 Dec 1995 13:44:03 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA18539; Thu, 21 Dec 1995 13:35:20 -0500 From: ralex@world.std.com (Aleksey Y Romanov) Message-Id: <199512211835.AA18539@world.std.com> Subject: Re: management with a per-varbind multiplexing protocol To: dab@epilogue.com (David Bridgham) Date: Thu, 21 Dec 1995 13:35:19 -0500 (EST) Cc: agentx@fv.com In-Reply-To: <9512202242.aa23275@quern.epilogue.com> from "David Bridgham" at Dec 20, 95 08:40:58 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > In short, it's a superset of SNMP. In order to properly support SNMP > it must support everything that SNMP does and use a very similar > naming system. yes. > In addition, it needs locking and multiphase commit > across multiple entities for proper execution of sets. yes. > It's either > built on a reliable transport or reliability becomes a part of the > spec rather than being left to the implementors, as in SNMP. yes. > Sub-agents are a bit more proactive in notifying the layer above them > what MIBs they support, what instances they have, and what changes > happen to them. No. It is not necessary. Once realiability is there these are not a problem. > Then a > management station would take the role of a master and we would move > SNMP to historic. Then I see more sense n the idea to limit agentx scope by sub-agents executed on the same network entity as master agent. > > Dave Aleksey   Delivery-Date: Thu, 21 Dec 1995 11:31:55 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id LAA15126 for X-agentx-local; Thu, 21 Dec 1995 11:31:51 -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 LAA15123 for ; Thu, 21 Dec 1995 11:31:47 -0800 (PST) Received: by dorothy.peer.com (4.1/SMI-4.1) id AA13546; Thu, 21 Dec 95 11:32:06 PST Date: Thu, 21 Dec 95 11:32:06 PST From: randy@peer.com (Randy Presuhn) Message-Id: <9512211932.AA13546@dorothy.peer.com> To: agentx@fv.com Subject: Re: Status of agentx! Hi - > From: f.p.h.vanHengstum@cs.utwente.nl > Date: Thu, 21 Dec 1995 15:25:57 +0100 ... > At url http://wwwsnmp.cs.utwente.nl/ > section "UT-SNMP" project in then iun subsection "Documentation". At least in the case of an HP LaserJet 4, the document refuses to allow itself to be printed on North American paper. Rather than scaling itself to the available paper, the document insists on A4 dimensions. By editing the PostScript I've gotten it to print, but have lost most of the page numbers. Short of flying to Japan to buy paper and cartridges, does anyone have a better solution? I'd love to have a sed/awk/perl script to remove the paper-size dependencies from Frame-generated PostScript. -------------------------------------------------------------------------- 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, 21 Dec 1995 12:52:47 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id MAA28401 for X-agentx-local; Thu, 21 Dec 1995 12:52:46 -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 MAA28375 for ; Thu, 21 Dec 1995 12:52:45 -0800 (PST) Received: from nsmdserv.cnd.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA129439166; Thu, 21 Dec 1995 12:52:48 -0800 Received: from localhost by nsmdserv.cnd.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA169579168; Thu, 21 Dec 1995 13:52:48 -0700 Message-Id: <199512212052.AA169579168@nsmdserv.cnd.hp.com> To: randy@peer.com (Randy Presuhn) Cc: agentx@fv.com Subject: Re: Status of agentx! In-Reply-To: Your message of Thu, 21 Dec 1995 11:32:06 -0800. <9512211932.AA13546@dorothy.peer.com> Date: Thu, 21 Dec 1995 13:52:48 -0700 From: "Brian O'Keefe" Is it possible to make a copy local to the agentx ftp site. I'm having problems with my Web browser timing out so I can't even retrieve the document, let alone print it on NA paper. bok   Delivery-Date: Thu, 21 Dec 1995 13:12:58 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id NAA02228 for X-agentx-local; Thu, 21 Dec 1995 13:12:57 -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 NAA02222 for ; Thu, 21 Dec 1995 13:12:56 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA19055 for agentx@fv.com; Thu, 21 Dec 95 16:13:12 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA22088; Thu, 21 Dec 1995 15:11:52 -0500 Date: Thu, 21 Dec 1995 15:15:16 EST From: Bob Natale Subject: Printing Herman's papaer... 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, 21 Dec 95 11:32:06 PST > Subject: Re: Status of agentx! Hi Randy, > > At url http://wwwsnmp.cs.utwente.nl/ > > section "UT-SNMP" project in then iun subsection "Documentation". I can't say when I pulled mine down...it might have been a while ago and it's possible something has changed at the site...but > At least in the case of an HP LaserJet 4, the document refuses to allow > itself to be printed on North American paper. Rather than scaling > itself to the available paper, the document insists on A4 dimensions. > By editing the PostScript I've gotten it to print, but have lost most > of the page numbers. My copy printed fine on an HP LaserJet 3si...standard US letter size paper...page numbers and all... > Short of flying to Japan to buy paper and cartridges, does anyone > have a better solution? I'd love to have a sed/awk/perl script to > remove the paper-size dependencies from Frame-generated PostScript. I don't have time to analyze the PostScript itself or to figure out if the 3si is able to somehow "adjust" (e.g., font size reduction) for it (not likely, I know)...but if anyone wants me to e-mail them a copy of the .ps file I used, I'll be happy to do so. 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, 21 Dec 1995 16:41:43 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id QAA12526 for X-agentx-local; Thu, 21 Dec 1995 16:41:39 -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 QAA12522 for ; Thu, 21 Dec 1995 16:41:37 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA09866 for agentx@fv.com; Thu, 21 Dec 95 19:41:52 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA28149; Thu, 21 Dec 1995 19:39:22 -0500 Date: Thu, 21 Dec 1995 19:42:46 EST From: Bob Natale Subject: Focus on "per-varbind" model To: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII We have recently had several articulate postings wrt proxy solutions. On behalf of the wg, let me say "thank you" to those contributors...likewise to those who have promoted the proxy solution(s) at the various extensible agent meetings over the years. It is clear that reasonable people can disagree, with substantial validity on all sides, as to whether proxy is "superior" to sub-agent (or vice versa) or whether one of the approaches can handle situations that aren't (nicely) handled by the other. We're not here to debate either of those points (and I'm not saying that anyone is doing so). Clearly, successful proxy solutions exist and successful extensible agent solutions exist. As Randy (I believe it was) pointed out, there is no reason to doubt that proxy and extensible agent solutions may even exist side by side on the same operational system. I think what Marshall had in mind at the Dallas meeting-- and what I would like to request now--is that a self- forming group of proxy proponents get together and write a BCP-like document describing the features and benefits of proxy solutions. I think this could become an optional output of the wg (or of the proxy group if they'd prefer independence). The formal work of the agentx effort will focus on the "per-varbind" extensible agent model in which the extensible agent consists of a core, organizing part commonly referred to as the "master agent" and multiple mutually independent component parts commonly referred to as "sub-agents". I hope we can all accept that and focus on the mission at hand...our single mandatory deliverable: "(mandatory) a platform-independent protocol which supports intra-agent communication within a device or local area network;" 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, 21 Dec 1995 18:15:51 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id SAA00991 for X-agentx-local; Thu, 21 Dec 1995 18:15:50 -0800 (PST) Received: from tsunami.dbc.mtview.ca.us (tsunami.dbc.mtview.ca.us [204.250.93.202]) by zloty.fv.com (8.7.3/8.7.1) with ESMTP id SAA00985 for ; Thu, 21 Dec 1995 18:15:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tsunami.dbc.mtview.ca.us (8.6.10/8.6.10) with ESMTP id RAA28658; Thu, 21 Dec 1995 17:59:03 -0800 To: "Brian O'Keefe" cc: randy@peer.com (Randy Presuhn), agentx@fv.com reply-to: agentx@fv.com Subject: Re: Status of agentx! In-reply-to: Your message of "Thu, 21 Dec 1995 13:52:48 MST." <199512212052.AA169579168@nsmdserv.cnd.hp.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <28655.819597542.0@dbc.mtview.ca.us> Date: Thu, 21 Dec 1995 17:59:03 -0800 Message-ID: <28657.819597543@dbc.mtview.ca.us> From: Marshall Rose ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <28655.819597542.1@dbc.mtview.ca.us> try ftp://ftp.fv.com/pub/mrose/agentx/Linde.ps /mtr ------- =_aaaaaaaaaa0 Content-Type: message/rfc822 Content-Description: original message Newsgroups: internet.ietf.agentx Received: from yukinojo.fv.com (yukinojo.fv.com [204.250.90.3]) by tsunami.dbc.mtview.ca.us (8.6.10/8.6.10) with ESMTP id NAA25663 for ; Thu, 21 Dec 1995 13:05:18 -0800 Received: from zloty.fv.com (zloty.fv.com [204.250.90.12]) by yukinojo.fv.com (8.7.1/8.7.1) with ESMTP id MAA11382 for ; Thu, 21 Dec 1995 12:58:52 -0800 (PST) Received: from localhost (zloty.fv.com [204.250.90.12]) by zloty.fv.com (8.7.3/8.7.1) with ESMTP id MAA28405 for ; Thu, 21 Dec 1995 12:52:47 -0800 (PST) Resent-From: agentx-owner@fv.com Comment: Posted to the agentx Mailing List To unsubscribe, send mail to agentx-request@zloty.fv.com with "unsubscribe" in the Subject Resent-Date: Thu, 21 Dec 1995 12:52:47 -0800 Resent-Message-ID: <28404.819579167.1@zloty.fv.com> Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id MAA28401 for X-agentx-local; Thu, 21 Dec 1995 12:52:46 -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 MAA28375 for ; Thu, 21 Dec 1995 12:52:45 -0800 (PST) Received: from nsmdserv.cnd.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA129439166; Thu, 21 Dec 1995 12:52:48 -0800 Received: from localhost by nsmdserv.cnd.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA169579168; Thu, 21 Dec 1995 13:52:48 -0700 Message-Id: <199512212052.AA169579168@nsmdserv.cnd.hp.com> To: randy@peer.com (Randy Presuhn) Cc: agentx@fv.com Subject: Re: Status of agentx! In-Reply-To: Your message of Thu, 21 Dec 1995 11:32:06 -0800. <9512211932.AA13546@dorothy.peer.com> Date: Thu, 21 Dec 1995 13:52:48 -0700 From: "Brian O'Keefe" Is it possible to make a copy local to the agentx ftp site. I'm having problems with my Web browser timing out so I can't even retrieve the document, let alone print it on NA paper. 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@zloty.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@zloty.fv.com Thank you.) ------- =_aaaaaaaaaa0--   Delivery-Date: Fri, 22 Dec 1995 00:32:23 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id AAA07968 for X-agentx-local; Fri, 22 Dec 1995 00:32:22 -0800 (PST) Received: from utrhcs.cs.utwente.nl (utrhcs.cs.utwente.nl [130.89.10.247]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id AAA07938 for ; Fri, 22 Dec 1995 00:32:20 -0800 (PST) Received: from myrtilos.cs.utwente.nl by utrhcs.cs.utwente.nl (SMI-8.6/csrelayMX-SVR4_1.2/RBINF) id JAA09621; Fri, 22 Dec 1995 09:32:25 +0100 Received: from dijkstra.cs.utwente.nl by myrtilos.cs.utwente.nl (SMI-8.6/csrelay-Sol1.4/RB) id JAA27392; Fri, 22 Dec 1995 09:32:18 +0100 Received: from localhost by dijkstra.cs.utwente.nl (SMI-8.6/SMI-SVR4) id JAA19755; Fri, 22 Dec 1995 09:32:17 +0100 Message-Id: <199512220832.JAA19755@dijkstra.cs.utwente.nl> To: agentx@fv.com Subject: Re: Status of agentx! In-reply-to: Your message of Thu, 21 Dec 1995 17:59:03 PST From: f.p.h.vanHengstum@cs.utwente.nl Organisation: "Frederic P. H. van Hengstum" "Dept. of Computer Science" "P.O. Box 217, 7500 AE Enschede, The Netherlands" "+31 53 4892537, fax +31 53 4333815" "http://wwwtios.cs.utwente.nl/tios/dg/mgt/" "" Date: Fri, 22 Dec 1995 09:32:16 +0100 Sender: hengstum@cs.utwente.nl ---------------------------------CUT-HERE------------------------------------ or try ftp://ftp.cs.utwente.nl/pub/src/snmp/thesis/Linde.ps Eric ---------------------------------CUT-HERE------------------------------------ If a train station is where a train stops, then what's a workstation ? Anonymous.   Delivery-Date: Fri, 22 Dec 1995 10:52:06 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id KAA16088 for X-agentx-local; Fri, 22 Dec 1995 10:52:02 -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 KAA16078 for ; Fri, 22 Dec 1995 10:51:57 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA23436 for agentx@fv.com; Fri, 22 Dec 95 13:52:10 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA18814; Fri, 22 Dec 1995 13:49:40 -0500 Date: Fri, 22 Dec 1995 13:53:05 EST From: Bob Natale Subject: PDUs, proto-ops, and principles To: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi, If you've reviewed Herman's thesis, you noticed the taxonomy of intra-agent protocol operations presented on p. 18. The following is a modified version of it: o Communication between the protocol entities - Connection establishment - Connection termination o Registration of management information - Registration request - Unregistration request o Information retrieval operations - Get o Information modification operations - Set - Reset o Notifications - Traps The major modifications I have made to Herman's taxonomy are: 1. I've removed the "Connection maintenance" item from the "Communication between protocol entities" category. First of all, not all of the implementations include it (this is the DPI "Are_You_There" and the OAA "Tick" PDUs). Secondly, the functionality can be provided as part of the normal operation of the extensible agent system, without an explicit special- purpose operation. (I will substantiate that later.) 2. I've added the "Reset" item to the "Information modification operations" category. This is a short-hand reference to the various "Commit", "Undo", "Rollback", "Cleanup", PDUs found in the various implementations. These operations can be simplified, IMHO, and the "Reset" moniker is intended to advertize that notion. (Which I will also substantiate later.) Looking at the resulting taxonomy, does any see any large-scale functionality that is not covered? Before answering that, remember our one mandatory deliverable: "(mandatory) a platform-independent protocol which supports intra-agent communication within a device or local area network" The two key words in that statement, wrt the present discussion, are "protocol" and "intra-agent": That is, we are talking about messages exchanged between (logically) internal elements of an extensible SNMP agent; namely, between the core agent and its constituent component agents (or, master agent and sub-agents, respectively). I have suggested that we should try to "leverage SNMP" as much as possible in this effort...probably sounds like a truism... in a big way, I hope it is. Anyway, doing so can lead us to see the extensible agent as a microcosm of SNMP itself. In this microcosm, the core agent is analogous to an SNMP manager entity and the component agents are analogoous to standard SNMP device agents. A consequence of this is that a basic SNMP principle can be reaffirmed here: Component agents must have minimal demands placed upon them by the protocol; core agents off-load higher-order management functions from the component agents. In meeting our mandatory deliverable, we must strive to do so in a way which optimizes for simplicity of component agent construction (insofar as its extensible agent interface is concerned, at least). 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 As an example of how this can be applied to the protocol operations taxonomy above, let me go back to the issue of the "connection maintenance" PDU types found in DPI and OAA. Clearly, this could be replaced with a simple GetRequest for sysUpTime from the component agent to the core agent. Right? If you can agree with that, you can also see two other consequences worth noting at this point: - It's a bi-directional SNMP channel; and - the component agents have access to the core agent's MIB (or at least certain parts of it). If you are still on board at this point, I'll leave you to think about the implications and extrapolations of that over the (for many of us, at least) long holiday weekend. I'll work on abstracting some more detail out of Herman's study (down at the actual PDU "parameter" level this time) and some more channeling of that into the model alluded to above. The direction I am taking at the moment is to take the bounded functionality of the several deployed implementations covered in Herman's study, try to reduce that even further (scope), and then try to provide that in an even simpler package (form) than any of those. Any and all input, feedback, commentary, etc. will be welcomed. Happy Holidays! 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: Sat, 23 Dec 1995 09:06:33 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id JAA26618 for X-agentx-local; Sat, 23 Dec 1995 09:06:33 -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 JAA26594 for ; Sat, 23 Dec 1995 09:06:16 -0800 (PST) Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id MAA20150; Sat, 23 Dec 1995 12:06:30 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA28897; Sat, 23 Dec 1995 12:05:03 -0500 From: ralex@world.std.com (Aleksey Y Romanov) Message-Id: <199512231705.AA28897@world.std.com> Subject: Re: PDUs, proto-ops, and principles To: natale@acec.com (Bob Natale) Date: Sat, 23 Dec 1995 12:05:03 -0500 (EST) Cc: agentx@fv.com In-Reply-To: from "Bob Natale" at Dec 22, 95 01:53:05 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > The major modifications I have made to Herman's taxonomy are: > > 1. I've removed the "Connection maintenance" item > from the "Communication between protocol entities" > category. First of all, not all of the implementations > include it (this is the DPI "Are_You_There" and the > OAA "Tick" PDUs). It is ever more so, because OAA's ticks are not related to connection maintenance - it just a way to allow sub-agents to perform asynchronous tasks (monitoring, traps generations, RMONing, RowStatus cleanup etc) in strictly synchronous environment. BTW, there are simply no connections to maintain in OAA. > Secondly, the functionality can > be provided as part of the normal operation of the > extensible agent system, without an explicit special- > purpose operation. (I will substantiate that later.) ????? > > 2. I've added the "Reset" item to the "Information > modification operations" category. This is a > short-hand reference to the various "Commit", > "Undo", "Rollback", "Cleanup", PDUs found in the > various implementations. These operations can > be simplified, IMHO, and the "Reset" moniker is > intended to advertize that notion. (Which I will > also substantiate later.) If two different sub-agents would never lock same resource you are right. However, it is not the case if sub-agents are running on the same computer - and this is going to be one the most popular applications for the thing under development here. So, it is simply unavoidable to go some lengths to insure orderly release of the resources. In other words, if we are working on general solution we have no luxury to ignore real complexity of the reasonably general case. > 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 There are three things I would like to note in this respect: No GetNext has to be a typo here - while master agent can figure out next object there is no way master agent can figure out next instance. Access control issue - GetNext/Bulk will be painfully ineffective if sub-agents would have no access control information available locally so, some operations/way to distibute access control information is required also. I would prefer to have this interface (a) RPC-based , (b) transparent wrt reliabilty/retiries/security. Rationale for (a): (1) RPC is the protocol of choice for the most popular OSes on the market - WinNT, Win95, (2) all other OSes do support PRC too, (3) At least WinNT has very effective RPC mechanism for calls going withing same machine - RPC over LPC. I was ever considering OLE for this purpose, but I am not brave enough to actually start doing it (. > The direction I am taking > at the moment is to take the bounded functionality of > the several deployed implementations covered in Herman's > study, try to reduce that even further (scope), and then ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Frankly, I do not think it is possible. E.g. I saw a couple of mails here from people implementing DPS that they had to change it in order to add support for multiple sub-trees mounted by the same sub-agent and to allow splitting rows of the table between several subagents, and provide information about beginning of the new packet. So, question is not removing some functionality from say DPS but rather addign it. BTW, our previous attempt to formulate public standard in this area failed just by the reason of this exact task being undoable and by no other reason. > try to provide that in an even simpler package (form) > than any of those. I think this is the area where we have to concentrate our attention. > BobN Aleksey   Delivery-Date: Tue, 26 Dec 1995 10:31:45 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id KAA25872 for X-agentx-local; Tue, 26 Dec 1995 10:31:44 -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 KAA25865 for ; Tue, 26 Dec 1995 10:31:41 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA07231 for agentx@fv.com; Tue, 26 Dec 95 13:31:52 -0500 Date: Tue, 26 Dec 1995 13:29:58 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA15356; Tue, 26 Dec 1995 13:29:58 -0500 Message-Id: <9512261829.AA15356@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: Sat, 23 Dec 1995 12:05:03 -0500 (EST) Hi Aleksey, > > The major modifications I have made to Herman's taxonomy are: > > > > 1. I've removed the "Connection maintenance" item > > from the "Communication between protocol entities" > > category. First of all, not all of the implementations > > include it (this is the DPI "Are_You_There" and the > > OAA "Tick" PDUs). > > It is ever more so, because OAA's ticks are not related to connection > maintenance - it just a way to allow sub-agents to perform asynchronous > tasks (monitoring, traps generations, RMONing, RowStatus cleanup etc) > in strictly synchronous environment. BTW, there are simply no connections > to maintain in OAA. Good. This further supports my claim that a special-purpose "Are_You_There" PDU is not required. Furthermore, sub-agent timer services (e.g., for internal asynchronous operations like the ones you list) are not part of the intra-agent protocol we are working on either. (How such services are provided will be an internal issue for the component agent builder and will most likely depend heavily on services provided by the runtime environment.) > > Secondly, the functionality can > > be provided as part of the normal operation of the > > extensible agent system, without an explicit special- > > purpose operation. (I will substantiate that later.) > > ????? A simple GetRequest for sysUpTime from the component agent to the system agent (aka, master agent, core agent). > > 2. I've added the "Reset" item to the "Information > > modification operations" category. This is a > > short-hand reference to the various "Commit", > > "Undo", "Rollback", "Cleanup", PDUs found in the > > various implementations. These operations can > > be simplified, IMHO, and the "Reset" moniker is > > intended to advertize that notion. (Which I will > > also substantiate later.) > > If two different sub-agents would never lock same resource you are > right. However, it is not the case if sub-agents are running on the same > computer - and this is going to be one the most popular applications > for the thing under development here. So, it is simply unavoidable > to go some lengths to insure orderly release of the resources. > In other words, if we are working on general solution we have no luxury > to ignore real complexity of the reasonably general case. Ensuring orderly resource of the resources is a requirement. My claim is that it can be accomplished more simply than it has been in existing proposals/implementations. (I plan to substantiate that claim in a posting dedicated to the topic later.) > > 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 > > There are three things I would like to note in this respect: > > No GetNext has to be a typo here - while master agent can figure out next > object there is no way master agent can figure out next instance. No typo. The system agent (aka master agent) will know what instances are available in the collection of active component agents at any given point in time. (And the "noSuchInstance" varbind exception can further refine this knowledge for the case in which an instance goes out of scope between the time it was registered and the subject Get operation, without an intervening "unregister" operation.) My assertion assumes instance-level registration operations (via simple SetRequests between component agents and the system agent...not special-purpose PDUs). I hope to get off a message about the multiple MIB dimensions that come into play in the extensible agent scenario later today. > Access control issue - GetNext/Bulk will be painfully ineffective if > sub-agents would have no access control information available locally This is an unsubstantiated claim. I do not believe it is true in the general case. In fact, localizing all access control information in the system agent will, in my judgment, prove to be both highly effective and totally painless for the component agent implementors. (And remember, optimizing for that latter quality will be a major determinant of the success of our eventual agentx protocol solution.) > so, some operations/way to distibute access control information is required > also. I disagree (strongly). IMHO, this information must be centralized in the system agent...when a component agent gets a request from the system agent, it can assume it's had a certain (high) degree of access control applied to it already. > I would prefer to have this interface (a) RPC-based , (b) transparent > wrt reliabilty/retiries/security. Rationale for (a): (1) RPC is the protocol > of choice for the most popular OSes on the market - WinNT, Win95, (2) all > other OSes do support PRC too, (3) At least WinNT has very effective RPC > mechanism for calls going withing same machine - RPC over LPC. There will be many ways of transporting the agentx protocol. They are--at this point, at least--external to that protocol itself. > I was ever considering OLE for this purpose, but I am not brave enough to > actually start doing it (. Yep, there's yet another way. As was clear, for example, from the presentation by Jeff Case at the Dallas IETF meeting, it takes a "whole product" solution to bring extensible agent technology to fruition in a real, production environment. This means that there will be ample room for product and service providers to add-value to the agentx protocol...indeed, it will be asolutely necessary for them to do so before the protocol will be of any *use* to our end-users. > > The direction I am taking > > at the moment is to take the bounded functionality of > > the several deployed implementations covered in Herman's > > study, try to reduce that even further (scope), and then > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Frankly, I do not think it is possible. E.g. I saw a couple of mails > here from people implementing DPS that they had to change it in order > to add support for multiple sub-trees mounted by the same sub-agent and > to allow splitting rows of the table between several subagents, > and provide information about beginning of the new packet. So, question > is not removing some functionality from say DPS but rather addign it. This is a (valid) "problem space" observation. There are many permutations of extensible agent technology. In reviewing the RFCs and meeting notes from 1991 on, one sees that the community has made many attempts at this before...with none resulting in substantial success. Yet we continue the effort. This time we have to try a different approach. One aspect of the approach I recommend is to say "there might be chunks of the problem space that might have to be deferred for now...some may be deferred indefinitely". Let's try to carve out a "solution space" that covers a large enough portion of the "problem space" to be worthwhile on its own merits, and then come back for more of the "problem space" later (or maybe not). A quick check of the some of the changes made to the DPI spec between RFC1228 and RFC1592 suggests two things (among others): 1. We do not want to deal with API issues at this time...let's focus on the core agentx protocol messages. 2. We do want to maximize for re-use of SNMP protocol constructs. (The preceding paragraph and bullets may seem a bit "free-floating" there...yep...anyway, they have something to do with refining the "solution space".) > BTW, our previous attempt to formulate public standard in this area > failed just by the reason of this exact task being undoable and by no > other reason. Please clarify/elaborate on what you mean by "this exact task". > > try to provide that in an even simpler package (form) > > than any of those. > > I think this is the area where we have to concentrate our attention. Please offer any specific ideas/suggestions/caveats you have in mind. 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, 26 Dec 1995 21:06:59 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id VAA29507 for X-agentx-local; Tue, 26 Dec 1995 21:06:59 -0800 (PST) Received: from card.com (card.com [199.100.120.2]) by zloty.fv.com (8.7.3/8.7.1) with ESMTP id VAA29495 for ; Tue, 26 Dec 1995 21:06:57 -0800 (PST) Received: from europe.std.com (europe.std.com [192.74.137.10]) by card.com (8.7.3/8.7.1) with SMTP id VAA04534 for ; Tue, 26 Dec 1995 21:02:31 -0500 (EST) Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id VAA10736; Tue, 26 Dec 1995 21:01:33 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA01585; Tue, 26 Dec 1995 20:58:53 -0500 From: ralex@world.std.com (Aleksey Y Romanov) Message-Id: <199512270158.AA01585@world.std.com> Subject: Re: PDUs, proto-ops, and principles To: natale@acec.com (Bob Natale) Date: Tue, 26 Dec 1995 20:58:53 -0500 (EST) Cc: agentx@fv.com In-Reply-To: <9512261829.AA15356@nips.acec.com> from "Bob Natale" at Dec 26, 95 01:29:58 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Hi Aleksey, Hi, Bob, Below is IMHO. > Ensuring orderly resource of the resources is a requirement. Great. > My claim is that it can be accomplished more simply than it > has been in existing proposals/implementations. (I plan to > substantiate that claim in a posting dedicated to the topic > later.) Let us see. > > > 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 > > > > There are three things I would like to note in this respect: > > > > No GetNext has to be a typo here - while master agent can figure out next > > object there is no way master agent can figure out next instance. > > No typo. The system agent (aka master agent) will know what > instances are available in the collection of active component > agents at any given point in time. (And the "noSuchInstance" > varbind exception can further refine this knowledge for the > case in which an instance goes out of scope between the time > it was registered and the subject Get operation, without an > intervening "unregister" operation.) Bob, may be this approach to the SNMP agent extensibility may be worth a try, however, it is absolutely outside 'solution space'. It can be fun indeed but I would definitely prefer to start from something already implemented. So, if this is a way to go let us wait until your ideas will materialize into first cut implementation at least, as far as I understand your are working in this direction for about two years now, so it is not going to be long. BTW, I omitted all other questions I had - they all have their natural answers in this environment. > > > The direction I am taking > > > at the moment is to take the bounded functionality of > > > the several deployed implementations covered in Herman's > > > study, try to reduce that even further (scope), and then > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Frankly, I do not think it is possible. E.g. I saw a couple of mails > > here from people implementing DPS that they had to change it in order > > to add support for multiple sub-trees mounted by the same sub-agent and > > to allow splitting rows of the table between several subagents, > > and provide information about beginning of the new packet. So, question > > is not removing some functionality from say DPS but rather addign it. > > This is a (valid) "problem space" observation. There are many > permutations of extensible agent technology. In reviewing the > RFCs and meeting notes from 1991 on, one sees that the community > has made many attempts at this before...with none resulting in > substantial success. Yet we continue the effort. This time we > have to try a different approach. One aspect of the approach I > recommend is to say "there might be chunks of the problem space > that might have to be deferred for now...some may be deferred > indefinitely". Let's try to carve out a "solution space" that > covers a large enough portion of the "problem space" to be > worthwhile on its own merits, and then come back for more of > the "problem space" later (or maybe not). Bob, I am sorry but I am failing to see a relationship between what you are writing here (solution space etc) and instance level registration you were talking above. > > BTW, our previous attempt to formulate public standard in this area > > failed just by the reason of this exact task being undoable and by no > > other reason. > > Please clarify/elaborate on what you mean by "this exact task". 'This exact task' - to make agent extensibility protocol which will be easier than DPI. I posted list of primitive tasks which has to be part of any traditional (means a la DPI) extensibility scheme. I can repost it again and you can try take pieces out and see how it will affect functional capabilities. > > > try to provide that in an even simpler package (form) > > > than any of those. > > > > I think this is the area where we have to concentrate our attention. > > Please offer any specific ideas/suggestions/caveats you have > in mind. IMHO, we have first have to settle down on what we are doing: (a) trying to improve some existing scheme, DPI looks fine with me as a starting point, or (b) trying to invent something completely unseen. If (a) is in question I have some ideas in this area, and if (b) is the path we are taking I think have a couple of radical ideas too :). Howeve, I feel that going (b)-way will be just a waste of time. > BobN Aleksey   Delivery-Date: Tue, 26 Dec 1995 22:12:23 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id WAA11870 for X-agentx-local; Tue, 26 Dec 1995 22:12:21 -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 WAA11863 for ; Tue, 26 Dec 1995 22:12:15 -0800 (PST) Received: from gandalf (world.lannet.com) by aristo.tau.ac.il with SMTP id AA01470 (5.67b/IDA-1.5 for ); Wed, 27 Dec 1995 08:12:02 +0200 Received: from moon.lannet.com by gandalf (4.1/SMI-4.1) id AA01933; Wed, 27 Dec 95 08:13:17 IST Received: from smtplink.lannet.com by moon.lannet.com (4.1/SMI-4.1) id AA15505; Wed, 27 Dec 95 08:10:16 IST Received: from Connect2 Message Router by smtplink.lannet.com via Connect2-SMTP 4.00; Wed, 27 Dec 95 08:11:37 -0500 Message-Id: In-Reply-To: <1268DD30010CB6AA> Date: Wed, 27 Dec 95 08:17:46 -0500 From: Dan Romascanu Sender: Dan Romascanu Organization: Lannet Ltd. To: agentx@fv.com, natale@acec.com (Bob Natale) Subject: Re: PDUs, proto-ops, and princi X-Mailer: Connect2-SMTP 4.00 MHS to SMTP Gateway Bob & Group, >If you are still on board at this point, I'll leave you >to think about the implications and extrapolations of >that over the (for many of us, at least) long holiday >weekend. I'll work on abstracting some more detail out >of Herman's study (down at the actual PDU "parameter" >level this time) and some more channeling of that into >the model alluded to above. The direction I am taking >at the moment is to take the bounded functionality of >the several deployed implementations covered in Herman's >study, try to reduce that even further (scope), and then >try to provide that in an even simpler package (form) >than any of those. I do agree with your approach at this point. It's probably the best time to see what we have from the previous iterations of standards tentative and proprietary implementations. However, I would like us not to miss one of the aspects that proved to be insuficient in all existing proposals. The problem we encountered in trying to implement any of those, was the lack of flexibility in registration of variables by component agents (sub-agents) to the core agent (master, multiplexer). In real life applications, common to all multiplexing agents schemas in multiple entities hubs you MUST allow registration by subtree OID, OID range, indeces range, table rows, variables and instances of variables, including variables from the same row supported by different component agents, and all combinations of the above. As I pointed in my short presentation in Dallas, without supporting this flexibility, this effort is all but useless for complex hubs implementations, in which agent implementors need to map the imposed structures of standard MIBs to the imposed structures of the modular hardware they run on. Regards, Dan Romascanu, Madge Networks Ltd., Tel Aviv, ISRAEL Voice: 972-3-645-8414, e-mail: dan@lannet.com   Delivery-Date: Tue, 26 Dec 1995 22:33:12 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id WAA15780 for X-agentx-local; Tue, 26 Dec 1995 22:33:12 -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 WAA15764 for ; Tue, 26 Dec 1995 22:33:11 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA14288 for agentx@fv.com; Wed, 27 Dec 95 01:33:23 -0500 Date: Wed, 27 Dec 1995 01:31:30 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA29090; Wed, 27 Dec 1995 01:31:30 -0500 Message-Id: <9512270631.AA29090@nips.acec.com> To: carlk@lfs.loral.com Subject: Re: Use case analysis Cc: agentx@fv.com > From: "Carl Kugler" > Date: Fri, 15 Dec 1995 13:16:52 -0700 Hi Carl, > I'm just jumping in here, having only reviewed the archives. Welcome! > I'm just thinking that in requirements analysis or definition, > it's often helpful to look at use cases, or common applications. By way of background... You are defintely right...but this is part of what I have been referring to as the "problem space". We (collectively) have spent much time and effort focusing on the problem space in past attempts to reach consensus an a standard approach to extensible agent technology. IMHO, Randy Presuhn (of Peer) did a superlative job of cataloging the problem space in last year's edition of this effort. The point is that we have (again, collectively) a lot of information about the problem space and I believe we have agreement that it is probably too broad and densely populated to succomb to any reasonably simple standard solution that will encompass all of its elements. So, this time I am trying to articulate an approach which works from the existing "solution space" (i.e., deployed protocols and products such as SMUX, DPI, OAA, EMANATE, ENVOY, etc.)... trying to find the common ground among them and the possible simplifications and the necessary changes (refinements, deletions, and extensions) that must be made to define a solution space of adequate scope to satisfy a large enough portion of the problem space to win consensus among the implementors (us) and to warrant deployment from the perspective of the user community. I know that some of that will come across as "word-smithing"...true... but history seems to indicate that a different approach may be required in this particular effort. > I can think of a few common applications of agent extensibility: All good ones for illustrating various aspects of the problem space. > 1) Managing external, non-SNMP hardware. For example, many networks contain > communications links like microwave or satellite links. These typically > involve racks of communications hardware like amplifiers, modems, > up-converters, down-converters, cryptos, antennas, etc. Typically these > devices present only RS-232 interfaces with unique status and control > protocols. In order to be able to manage this gear remotely, you drop a > workstation into the communication station and write a subagent to provide an > SNMP interface to the serial devices. In these cases, it would be nice for the > NMS to be able to discover these devices as separate, distinct entities that > can be independently managed. See, there's an awful lot of problem space in there! Potential solutions might involve proxy, the Entity MIB, transport specifics, and/or extensible agent technology. We seem to have implicit agreement that proxy and "agentx" solutions will (continue) to co-exist, to the benefit of all. We are not yet clear about the interactions between the fruits of the Entity MIB work and the agentx work...but early indications point again to a positive synergy overall. I believe that the eventual agentx solution will consist of several elements...the overall "thing" will be the extensible agent...it will consist of a "system agent" (aka "master" or "core" agent) and a (potentially dynamic) collection of "component agents" (aka "sub-agents" or "peer agents"). One key aspect that might relate to your example is that a "component agent" may actually be an interface between the "system agent" and some fairly complex system in its own right. For example, one component agent might support just one attached printer on a PC by instrumenting the Printer MIB while another component agent might support an "LPD Service" on a PC with multiple attached local and/or network printers attached to it by implementing a special-purpose enterprise MIB. Both use the same, simple agentx protocol to interact with the system agent to form the extensible agent. > 2) Critical applications. For example, a database server that you want to be > able to monitor and control. In this case, you want the NMS to recognize that > the server is contained in a computer and is dependent on the computer's > resources. Yes, and of course this is done today with specially adapted versions of some of the deployed extensible agent solutions. A key driver behind the need for a standard extensible agent solution is the imminent proliferation of application management via SNMP. Component agent construction needs to be *relatively* simple (relative to a native SNMP agent, relative to the system agent part of the extensible agent, and relative to non-SNMP alternatives) in large part to ensure that applications management can be plugged into SNMP quickly, econmically, and pervasively. > 3) Interfaces to other management systems. For example, BlueVision gateways, > or various gateways to, say, mainframe SNA-type network managers. Here you > have a proxy relaying information from another world of network management. While hoping to avoid starting a debate on this point, I'd would like to say that this example seem less like one that the agentx effort should be concerned with than your other examples. Proxy and/or management application level solutions seem more appropriate for this one. However, nothing will prevent a component agent from begin constructed to perform this function. > Are these the kinds of applications you envision? Are there other > applications? Is agentx adequately addressing the requirements these types of > applications present? Let me answer the first part of that in two ways: First, the kinds of "applications" being supported by the collection of deployed protocols I listed above (not meant to be an exclusive list, btw) comprise one answer to the question of what kinds of applications will/should/must the agentx protocol support? Second, I personally use the system agent for a server or desktop workstation/PC as my favorite example...this would implement MIB-II, the host resources MIB, and maybe the printer, modem, RAID, and special-purpose enterprise MIBs, for example. Wrt the second part, otoh there's an existence proof of sorts implicit in the "first" above that this solution space "adequately" addresses the requirements those applications present. (I am not suggesting that "adequately" is good enough here.) More importantly, however, we will have to assess whether the problem space covered by any emerging solution space is adequate as we continue to elaborate the solution space(s). I hope we can count on you to offer your assessment from time to time. 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, 26 Dec 1995 23:08:05 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id XAA21504 for X-agentx-local; Tue, 26 Dec 1995 23:08: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 XAA21499 for ; Tue, 26 Dec 1995 23:08:03 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA15739 for agentx@fv.com; Wed, 27 Dec 95 02:08:02 -0500 Date: Wed, 27 Dec 1995 02:06:09 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA29661; Wed, 27 Dec 1995 02:06:09 -0500 Message-Id: <9512270706.AA29661@nips.acec.com> To: dan@lannet.com Subject: Re: PDUs, proto-ops, and princi Cc: agentx@fv.com > Date: Wed, 27 Dec 95 08:17:46 -0500 > From: Dan Romascanu Hi Dan, <...> > I do agree with your approach at this point. It's probably > the best time to see what we have from the previous > iterations of standards tentative and proprietary > implementations. Thanks. For those who (not without cause) hate my writing style, this "solution space" theme probably seems like a figment of my imagination...but I do think it's necessary for us to take a different approach this time...and we do have a lot of collective knowledge about the possible "problem space" already. We all understand that having a handle on requirements is essential. > However, I would like us not to miss one of the aspects > that proved to be insuficient in all existing proposals. > The problem we encountered in trying to implement any > of those, was the lack of flexibility in registration of variables > by component agents (sub-agents) to the core agent > (master, multiplexer). Yes, as I have said in earlier posts, this is one of the key "extensions" to the reference protocols that pops out of a systematic review of them in the context of the agentx history. At the moment, I am inclined to sum this up by saying that instance level registration is the quintessential capability here. (I am not saying it is the only registration capability that must be provided.) > In real life applications, common to > all multiplexing agents schemas in multiple entities hubs > you MUST allow registration by subtree OID, OID range, > indeces range, table rows, variables and instances of > variables, including variables from the same row supported > by different component agents, and all combinations of > the above. I am hopeful that we can meet the core requirements without having to provide a large number of specialized registration messages. I am hopeful that we will find a synergistic relationship with the Entity MIB that might help us here. As I will try to show in a more detailed message on MIBs in the agentx environment in the next day or two, I believe that reliance upon the existence of the component MIB (corresponding to each component agent) for bulk registration plus instance level registration can be made to suffice. (And both accomplished via standard SNMP SetRequests from the component agent into the system agent's MIB space.) > As I pointed in my short presentation in Dallas, Which you graciously deferred so that I could make a few comments before having to leave for my flight...(so I missed your presentation, but have read Marshall's notes of it in the minutes).... > without supporting this flexibility, this effort is all but useless > for complex hubs implementations, in which agent implementors > need to map the imposed structures of standard MIBs to the > imposed structures of the modular hardware they run on. Without passing judgment on the appropriateness of this particular application for agentx (which I am neither qualified nor empowered to do, one way or the other), let me just repeat the possibilities that: 1. *Maybe* such complex applications will be outside the initial solution space (deferred); or 2. *maybe* the component agent for such a complex application will hide much of the complexity from the system agent...behind the agentx protocol...? I look forward to your further inputs on this and other matters of relevance to the agentx effort (knowing that you are also very busy with the RMON2 stuff). 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, 27 Dec 1995 09:00:32 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id JAA19841 for X-agentx-local; Wed, 27 Dec 1995 09:00:31 -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 JAA19830 for ; Wed, 27 Dec 1995 09:00:29 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA18511 for agentx@fv.com; Wed, 27 Dec 95 12:00:11 -0500 Date: Wed, 27 Dec 1995 11:58:17 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA09646; Wed, 27 Dec 1995 11:58:17 -0500 Message-Id: <9512271658.AA09646@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: Tue, 26 Dec 1995 20:58:53 -0500 (EST) Hi Aleksey, >>> No GetNext has to be a typo here - while master agent can figure out next >>> object there is no way master agent can figure out next instance. >> >> No typo. The system agent (aka master agent) will know what >> instances are available in the collection of active component >> agents at any given point in time. (And the "noSuchInstance" >> varbind exception can further refine this knowledge for the >> case in which an instance goes out of scope between the time >> it was registered and the subject Get operation, without an >> intervening "unregister" operation.) > > Bob, may be this approach to the SNMP agent extensibility may be worth > a try, however, it is absolutely outside 'solution space'. It can be fun > indeed but I would definitely prefer to start from something already > implemented. Valid point...but I don't agree that this (i.e., instance-level registration) is outside the existing solution space. First of all, the reference protocols all support several forms of object registration, so instance-level registration is just an extension of that idea...not entirely a new functional category. Secondly, some of the proprietary implementations that have been reported on (e.g., most recently Dan's report at the Dallas IETF meeting) have pointed to the need for instance-level registration. Thirdly, when we look at some of the reported deficiencies of weaknesses in the reference protocols we can trace their root cause to a lack of instance-level registration. So, for those reasons, I don't think this is either a novel or a radical proposal. > So, if this is a way to go let us wait until your ideas > will materialize into first cut implementation at least, Again, fair comment...but I believe there are implementations (some deployed, some just R&D) that incorporate this concept already. > as far as I understand your are working in this direction for > about two years now, so it is not going to be long. Touche! Fair point...but I have mostly been trying to surface a consensus solution from the body politic for most of that time...and that's still my main task as wg chair... I am only pushing my own ideas to try to generate some new momentum towards such a solution this time. By any reasonable measure, there are many people more qualified than me in the community to identify the skeleton of the agentx protocol among the reference protocols and deployed solutions and to add the needed muscle, ligaments, and flesh to make the thing work. > BTW, I omitted all other questions I had - they all have their natural > answers in this environment. Thanks...the last part of that statement is actually a very important observation that can help propel us toward a consensus if things progress...it is an attribute we should look for in a proposed solution..."Do a lot of things seem to fall in place naturally given a small set of basic principles?" <...> > Bob, I am sorry but I am failing to see a relationship between what > you are writing here (solution space etc) and instance level > registration you were talking above. Ok...I hope I have clarified that a bit above...? >>> BTW, our previous attempt to formulate public standard in this area >>> failed just by the reason of this exact task being undoable and by no >>> other reason. >> >> Please clarify/elaborate on what you mean by "this exact task". > > 'This exact task' - to make agent extensibility protocol which will be > easier than DPI. I posted list of primitive tasks which has to be > part of any traditional (means a la DPI) extensibility scheme. > I can repost it again and you can try take pieces out and see > how it will affect functional capabilities. Yes, please do re-post your list. >>> > try to provide that in an even simpler package (form) >>> > than any of those. >>> >>> I think this is the area where we have to concentrate our attention. >> >> Please offer any specific ideas/suggestions/caveats you have >> in mind. > > IMHO, we have first have to settle down on what we are doing: > (a) trying to improve some existing scheme, DPI looks fine with me > as a starting point, or (b) trying to invent something completely > unseen. Not (b)...because that seems unnecessary...since the existing solution space defined by the reference protocols and the various deployed solutions seems to offer an existence proof of sufficient force. Close to (a)...but not quite...I do not think that DPI--as a stand-alone solution--should be the only thing we reference in this exercise. We should look at as much of the deployed solution space as possible...SMUX, DPI (1 and 2), OAA, the UT_SNMP solution...and I'd really like to get some input wrt EMANATE and ENVOY (and any others) structured like the tables in Harmen's paper for further comparative data at the protocol level. The resulting solution will, I believe, represent a distilled amalgam of the most workable aspects of all of the above, with some possible extensions identified primarily by the collective deployed experience. > If (a) is in question I have some ideas in this area, Please post them. > and if (b) is the path we are taking I think have a couple of > radical ideas too :). If you think they can have a positive bearing on the outcome, please post them too (maybe separately from the ideas you have in context (a)). In other words, just because we are starting from the "solution space" rather than the "problem space" does not mean that any and all "new" ideas or constructs are off-limits...it just means that the rationale and justification for introducing them has to be a bit more well-defined than it would otherwise have to be. > Howeve, I feel that going (b)-way will be just a waste of time. I agree (with emphasis on your use of the "completely unseen" qualifier). 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, 27 Dec 1995 09:07:06 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id JAA21009 for X-agentx-local; Wed, 27 Dec 1995 09:07:06 -0800 (PST) Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id JAA21004 for ; Wed, 27 Dec 1995 09:07:05 -0800 (PST) Received: from flume.zk3.dec.com by mail12.digital.com; (5.65v3.2/1.0/WV) id AA08066; Wed, 27 Dec 1995 12:02:08 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA16799; Wed, 27 Dec 1995 12:02:06 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA01670; Wed, 27 Dec 1995 12:02:24 -0500 Message-Id: <9512271702.AA01670@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 "Tue, 26 Dec 95 13:29:58 EST." <9512261829.AA15356@nips.acec.com> Date: Wed, 27 Dec 95 12:02:24 -0500 From: Mike Daniele X-Mts: smtp Hello Bob, We implemented an extensible agent from scratch (sort of :-) for Digital UNIX. The protocol (eSNMP) was based on DPI, and we modified it in a few areas (along similar lines to what was done in the research paper.) I'll post a protocol spec later this week, and call out particular areas of differentiation. But the recent mailings have brought up some ideas that need squelching immediately :-) * > > 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 * > * > There are three things I would like to note in this respect: * > * > No GetNext has to be a typo here - while master agent can figure out next * > object there is no way master agent can figure out next instance. * No typo. The system agent (aka master agent) will know what * instances are available in the collection of active component * agents at any given point in time. (And the "noSuchInstance" * varbind exception can further refine this knowledge for the * case in which an instance goes out of scope between the time * it was registered and the subject Get operation, without an * intervening "unregister" operation.) If I understand you correctly, then with all due respect, this idea is completely broken. One of the design tenets of the existing solutions is that detailed knowledge of the MIB variables (how to get and set them, how many there are, what are their instance values) is contained in the subagent, not the master agent. The shortcomings of your proposed mechanisms are: o Places a huge burden on the master agent. You're effectively saying the master agent becomes a database containing all variable bindings for the system. o Attempts to replace method routine SNMP semantics with a complex mechanism of instance-level registration. If you're going to limit subagents to only answering GetRequests, why not have them register the values as well, and the master agent never needs to communicate with them at all :-) o Destroys any chance of optimal (or even reasonable) processing of GetBulk requests. The subagent method routine will have no chance to optimize it's access to MIB data (that is, fetch everything now that it will need to service the request). The master and subagent will be forced to exchange many data packets instead of only 1. o Seems to impose huge runtime overhead when processing dynamic tables. Consider as an example a Host Resources MIB subagent on a unix timesharing system system. Specifically, think about the hrSWRunTable and hrSWRunPerfTable, an entry in both of them being required for EACH process on the system. yuck.... * My assertion assumes instance-level registration operations * (via simple SetRequests between component agents and the * system agent...not special-purpose PDUs). I hope to get off * a message about the multiple MIB dimensions that come into * play in the extensible agent scenario later today. I'm not opposing instance-level registration. But I think it's important to differentiate between permitting registration at this level of granularity, and FORCING it in an attempt to manage SNMP semantics. > A simple GetRequest for sysUpTime from the component agent to > the system agent (aka, master agent, core agent). I think it's broken to assume the master agent contains any particular MIB implementation. Clearly the master agent and whatever part of the system implements MIB II must somehow share information for correct implementation of the snmp group (at least). But that's an implementation/product detail, it shouldn't be part of the extensible agent protocol. It seems much simpler to me to have a ping-type PDU (it takes about 10 lines of code) than to impose an architectural constraint around which entity implements MIB II. Regards, Mike   Delivery-Date: Wed, 27 Dec 1995 10:05:23 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id KAA01632 for X-agentx-local; Wed, 27 Dec 1995 10:05:23 -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 KAA01627 for ; Wed, 27 Dec 1995 10:05:21 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA24216 for agentx@fv.com; Wed, 27 Dec 95 13:03:02 -0500 Date: Wed, 27 Dec 1995 13:01:09 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA10972; Wed, 27 Dec 1995 13:01:09 -0500 Message-Id: <9512271801.AA10972@nips.acec.com> To: daniele@zk3.dec.com Subject: Re: PDUs, proto-ops, and principles Cc: agentx@fv.com > Date: Wed, 27 Dec 95 12:02:24 -0500 > From: Mike Daniele Hi Mike, > We implemented an extensible agent from scratch (sort of :-) > for Digital UNIX. The protocol (eSNMP) was based on DPI, > and we modified it in a few areas (along similar lines to > what was done in the research paper.) Interesting. > I'll post a protocol spec later this week, and call out > particular areas of differentiation. Excellent! > But the recent mailings > have brought up some ideas that need squelching immediately :-) Ok...let's see if I can defend any of them: <...> > * No typo. The system agent (aka master agent) will know what > * instances are available in the collection of active component > * agents at any given point in time. (And the "noSuchInstance" > * varbind exception can further refine this knowledge for the > * case in which an instance goes out of scope between the time > * it was registered and the subject Get operation, without an > * intervening "unregister" operation.) > > If I understand you correctly, then with all due respect, > this idea is completely broken. "Completely"? I think there are some deployed solutions that use it or some variation of it. Of course, that does not mean that it's "completely" unbroken either! > One of the design tenets of the existing solutions is that > detailed knowledge of the MIB variables (how to get and set them, > how many there are, what are their instance values) is contained > in the subagent, not the master agent. All of that knowledge remains in the component agents in my scheme...especially the "how to get and set them" part...some of that knowledge however...especially the "how many there are, what are their instance values" part...*has* to be in the system agent, IMHO, to overcome certain deficiencies/limitations in the reference solutions. > The shortcomings of your proposed mechanisms are: > > o Places a huge burden on the master agent. > You're effectively saying the master agent becomes > a database containing all variable bindings for the > system. This true to some extent. The trade-off I am seeking is a correspondingly huge reduction in the burden placed on component agent construction. I do not think that future component agents will look like the sub-agents of today. I think they will be much simpler. On the other hand, it is true that future system agents will probably be more complex than today's master agents. As I said in one of the initial postings outlining this approach, I think that this model (correctly) maps to the larger SNMP model itself. > o Attempts to replace method routine SNMP semantics > with a complex mechanism of instance-level registration. No attempt to replace method routines is implied. No *complex* mechanism of instance-level registration is called for...it can be as simple as a simple SetRequest from component agent to system agent. > If you're going to limit subagents to only answering > GetRequests, why not have them register the values as > well, and the master agent never needs to communicate > with them at all :-) Well, this is not an *entirely* crazy idea. SMUX had the concept of "cache-ahead" operations (was not embodied in the published protocol). And it would definitely be feasible to allow for a "time-to-live" value on a returned value such that, for examples: - Once, say, some permanent value was retrieved from the component agent the system agent would not need to ask it again during the lifetime of a connection with that component agent; whereas - a volatile value knowable only to the component agent at each retrieval time would be flagged as transient and, therefore, discarded by the system agent after each transmittal up to the originating management entity. - And, of course, the system agent implementation could, at its option, treat all values as transient--avoiding the need to cache them for performance and making the request to the component agent each time...so this could be a totally added-value marketplace differentiator among system agent implementations. Note that I am *not* proposing such functionality...just responding to your (rhetorical?) point. > o Destroys any chance of optimal (or even reasonable) > processing of GetBulk requests. I am not sure why. Are you thinking that a GetRequest from the system agent to the component agent is limited to a single varbind for some reason...? (It's not.) > The subagent method routine will have no chance to optimize > it's access to MIB data (that is, fetch everything now that > it will need to service the request). I don't think this is true. It will have whatever chance is built into it by its implementors...it may choose an optimization scheme totally asynchronous to the system agent (e.g., read all permanent read-only values at init time and hold them in memory in case the system agent ever asks for them). Some implementations of the RDBMS MIB, for example, choose such an asynchronous scheme...i.e., some variables are loaded into the sub-agent at some longer interval and some are loaded at some shorter interval and requests from the master agent are filled from these two caches at request time. > The master and subagent will be forced to exchange many > data packets instead of only 1. Not necessarily...not intended...see above. > o Seems to impose huge runtime overhead when processing > dynamic tables. Please elaborate...my intention is just the opposite. > Consider as an example a Host Resources MIB subagent > on a unix timesharing system system. Specifically, think about > the hrSWRunTable and hrSWRunPerfTable, an entry in both of them > being required for EACH process on the system. Please elaborate...yes, entries *must* be maintained in both of those tables for each process running on the system...presumably in the component agent directly instrumenting the HR MIB...what's that got to do with the system agent and instance-level registration? Well, for each process that the component agent loads into its tables it would let the system agent know the instance (index) value. > yuck.... Your mileage may vary! :-) > * My assertion assumes instance-level registration operations > * (via simple SetRequests between component agents and the > * system agent...not special-purpose PDUs). I hope to get off > * a message about the multiple MIB dimensions that come into > * play in the extensible agent scenario later today. > > I'm not opposing instance-level registration. Whew! Had me fooled there for a moment! :-) > But I think > it's important to differentiate between permitting registration > at this level of granularity, and FORCING it in an attempt to > manage SNMP semantics. I am not trying to force it in an attempt to manage SNMP semantics. I am suggesting that it is required to meet certain field-proven requirements efficiently (e.g., different rows in a single table being managed by different component agents) and that *once you satisfy that requirement* other implications fall out it that might be useful (esp. in being able to simplify the construction of component agents). You may or may not recall that one of the purported major complaints about the people who reviewed SNMP as a possible management choice for desktop systems balked at GetNext as being too complex (mostly due to the lexicographic ordering requirements) and voila! DMTF-ology arose. So a key principle here should be (must be, IMHO): Simplify component agent construction to the maximum extent possible...moving additional complexity into the system agent is a positive trade-off for this purpose. > > A simple GetRequest for sysUpTime from the component agent to > > the system agent (aka, master agent, core agent). > > I think it's broken to assume the master agent contains any > particular MIB implementation. Ok...let me rephrase that...the component agent (just like some remote management entity) makes a request of the *extensible agent* (which it sees as the system agent)... the system agent might field the request for sysUpTime to some other component agent that happens to be instrumenting that part of MIB-II, but this is transparent to the requesting component agent. > Clearly the master agent and whatever part of the system implements > MIB II must somehow share information for correct implementation > of the snmp group (at least). Yes. > But that's an implementation/product detail, it shouldn't be part of > the extensible agent protocol. You're right...but I am not suggesting anything special in the agentx protocol that even implies how it's implemented...a component agent which needs to know the value of sysUptTime makes a standard GetRequest of the system agent (just like a management app would) and the system agent satisfies that request...either directly or via a component agent which, in that implementation, might happen to instrument sysUpTime. > It seems much simpler to me to have a ping-type PDU (it takes about > 10 lines of code) than to impose an architectural constraint around > which entity implements MIB II. I am not suggesting that we impose such an architectural constraint. I am trying to avoid the design of any new PDU types...I believe that existing SNMP PDUs can be made to suffice quite nicely. It goes without saying, of course, that I could be very wrong. 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, 27 Dec 1995 10:13:12 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id KAA03126 for X-agentx-local; Wed, 27 Dec 1995 10:13:08 -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 KAA03118 for ; Wed, 27 Dec 1995 10:13:04 -0800 (PST) Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id NAA01655; Wed, 27 Dec 1995 13:13:14 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA23912; Wed, 27 Dec 1995 13:09:38 -0500 From: ralex@world.std.com (Aleksey Y Romanov) Message-Id: <199512271809.AA23912@world.std.com> Subject: Re: PDUs, proto-ops, and principles To: natale@acec.com (Bob Natale) Date: Wed, 27 Dec 1995 13:09:37 -0500 (EST) Cc: agentx@fv.com In-Reply-To: <9512271658.AA09646@nips.acec.com> from "Bob Natale" at Dec 27, 95 11:58:17 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > Bob, may be this approach to the SNMP agent extensibility may be worth > > a try, however, it is absolutely outside 'solution space'. It can be fun > > indeed but I would definitely prefer to start from something already > > implemented. > > Valid point...but I don't agree that this (i.e., instance-level > registration) is outside the existing solution space. First of > all, the reference protocols all support several forms of object > registration, so instance-level registration is just an extension > of that idea...not entirely a new functional category. :):):):) For me it is too far away from exisiting solution space. > Secondly, > some of the proprietary implementations that have been reported > on (e.g., most recently Dan's report at the Dallas IETF meeting) > have pointed to the need for instance-level registration. I do not see the real need for per instance registration in order to support per instance multiplexing. There is a trivial algorithm to be used to in order to combine per sub-tree registration with per instance multiplexing. I can spell it out if it is not self-evident. > Thirdly, > when we look at some of the reported deficiencies of weaknesses > in the reference protocols we can trace their root cause to a > lack of instance-level registration. Bob, IMHO, this is both novel and radical proposal wrt existing solution space and we all would be much better off if we either (a) will wait untill there will be at least one implementation done, or (b) choose other path. > look for in a proposed solution..."Do a lot of things seem > to fall in place naturally given a small set of basic principles?" Bob, IMHO, lots of things are really fall in place, however, basic principle itself does not seem that much implementable and definetely does not promise any solution which will be easier than say DPI. I would not like to dicurage you from persuing your ideas, but it is definetely not a time to rush into conclusions in any case: if your ideas are way to go we have to have at least one implementation in order to weight all pros and contras. > > Bob, I am sorry but I am failing to see a relationship between what > > you are writing here (solution space etc) and instance level > > registration you were talking above. > > Ok...I hope I have clarified that a bit above...? It is definitely not in the solution space in my view. > Yes, please do re-post your list. It is attached to this mail, warning it is not applicable to the set of ideas you are talking about. > Close to (a)...but not quite...I do not think that DPI--as > a stand-alone solution--should be the only thing we reference > in this exercise. I think that if we would take DPI and fix it in the areas which require fixing, we will have what we are looking for and in very short time if we will base our work on experience gained both in DPI area and elsewhere. > > If (a) is in question I have some ideas in this area, > > Please post them. 1. Do not waste time on discussing instance-level registration if (a) is a way to go. > BobN Aleksey =================================================================== Hi, Basic primitives. Whatever mechanism is used to pass data, whatever design trade-offs are made in any area it seems like basic set of primitive operations required to successfully adapt third party MIB-module (sub-agent) is basically the same. In one environment it is reasonable sometimes to combine two or more primitives in one complex one, but the overall set is constant. As it was properly noted by BobN, all these primitives have to be optional to be implemented by particular sub-agent, however, all of them are required to be part of the master-sub-agent framework. So, it seems reasonable to spell them out. I am sorry, I am planning very skim description and rationale of each primitive. I hope it will be enough for the people already involved into agent design and implementations and I will be more than glad to answer questions, however, I would like to have this thing slim enough. This set of primitives I am describing is associated with no changes in both protocol and NMSs. A. General A.1 Initialization It is quite reasonable for master-agent to have a possibility to reset sub-agent into known state. E.g. if sub-agent initialization takes some time and can cause unwanted delays if implemented as part of PDU processing. Again, all primitives has to be optional, but this possibility has to be part of the framework. In particular if sub-agent is implemented as separate process it does not need this primitive to be used. A.2. Time ticking There are number of time related activities to be performed by sub-agent. Most important of them is cleanup of 'notReady', 'notInService' rows. Second use is to provide monitoring capabilities in single-threaded environments. Third use cacheing agents can keep their cache up to date. So, we have entry to be touched called once upon a time to allow sub-agent to perform this kind of work. Again, all primitives has to be optional, but this possibility has to be part of the framework. In particular if sub-agent is implemented as separate process it does not need this primitive to be used. B. Get/GetNext/Bulk B.1. Beginning of the new PDU If sub-agent using some sort of cacheing scheme one would not like to have cache updated in a middle of the PDU processing and thus have inconsistent data. This is major necessity of this primitive. Again, all primitives has to be optional, but this possibility has to be part of the framework. In particular this primitive expected to have very light job associated with it, so it is primary candidate to be piggy-backed on top of search/retrieval primitive. B.2. Variable search/retrieval This is the most agreeable upon primitive :). There is only one issue to be discussed. In order to provide for effective GetNext/GetBulk implementations, access checking has to be performed within this primitive. Hence we have a requirement to admin model developments: access rules database has to be small enough to be distributable to sub-agents at low price (in other words be of small size) from master to sub-agent. Again, all primitives has to be optional, but this possibility has to be part of the framework. E.g. I can imagine sub-agent which has only time ticking primitive implemented. B.3. End of PDU processing We can expect that some sub-agents will temporarily allocate some local resources in order to process requests, so we have to give them a possibility to release these resources ASAP. At least we as standard body are in no position to punish implementors who chose this approach in their wares. C. Set C.1. Beginning of the new PDU It is not hard thing to imagine that sub-agent designer would appreciate being notified about new PDU being processed. At least we as standard body are in no position to punish implementors who chose this approach in their wares. Again, all primitives has to be optional, but this possibility has to be part of the framework. In particular this primitive expected to have very light job associated with it, so it is primary candidate to be piggy-backed on top of search/verification primitive. C.2. Variable search/verification This is the second most agreeable upon primitive. C.3. Resource locking If we are talking about sub-agents developed by independent parties we have to go some additional lengths insuring that whatever resource is locked it will be properly unlocked (e.g. setting splnet/splx in two different program modules). The most common way to insure this feature is to unlock resources in reverse order it is unlocked. This primitive can be piggy-backed on search/verification primitive. However, if master agent calls search/verification primitive several times per PDU being processed, then it is desirable (from implementation point of view) to not piggy-back it. Side effect of having this primitive separate is that cross variable checking can be implemented within this primitive instead of search/verification which makes it a little bit easier. Again, all primitives has to be optional, but this possibility has to be part of the framework. C.4. Resource unlocking This is the third most agreeable primitive. Important thing is that it has to be called in reverse order vs resource locking primitive. Again, all primitives has to be optional, but this possibility has to be part of the framework. C.5. Commit This is the fourth most agreeable primitive. Again, all primitives has to be optional, but this possibility has to be part of the framework. C.6. Commit undo This is the fourth most agreeable primitive. Important thing is that it has to be called in reverse order vs commit primitive. It seems like to have resource unlocking called after commit undoing will allow to unwind most complicated web of cross dependent resource locks, however, this idea is far from being generally accepted. Again, all primitives has to be optional, but this possibility has to be part of the framework. C.7. Release If all sub-agents performed commit successfully, the only thing left is to unlock resources and inform sub-agents about this remarkable achievement. Important thing is that it has to be called in reverse order vs resource locking primitive. Again, all primitives has to be optional, but this possibility has to be part of the framework. C.8. End of PDU processing We can expect that some sub-agents will temporarily allocate some local resources within search/verification primitive, these resources cannot not be freed as part of resource unlocking, because if one sub-agent had error-encountered in search/verification primitive, resource locking/unlocking stage will never be reached. So we have to give them a possibility to release these resources ASAP. At least we as standard body are in no position to punish implementors who chose this approach to there wares. Aleksey P.S. ftp://ftp.std.com/vendors/snmp/snmp95/snmp95.tar.Z can be used as an example implementation.   Delivery-Date: Wed, 27 Dec 1995 10:27:51 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id KAA06242 for X-agentx-local; Wed, 27 Dec 1995 10:27:50 -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 KAA06235 for ; Wed, 27 Dec 1995 10:27:49 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA26924 for agentx@fv.com; Wed, 27 Dec 95 13:27:58 -0500 Date: Wed, 27 Dec 1995 13:26:05 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA11521; Wed, 27 Dec 1995 13:26:05 -0500 Message-Id: <9512271826.AA11521@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: Wed, 27 Dec 1995 13:09:37 -0500 (EST) Hi Aleksey, > I do not see the real need for per instance registration in order > to support per instance multiplexing. There is a trivial algorithm > to be used to in order to combine per sub-tree registration with > per instance multiplexing. I can spell it out if it is not self-evident. Yes, please spell it out for me. (Which is not to say it is not self-evident to many...but it will be educational for me and will provide a tangible basis for me to either yield on the instance-level registration point or to identify flaws in the algorithm.) <...> > > Yes, please do re-post your list. > > It is attached to this mail, warning it is not applicable to the set > of ideas you are talking about. Yes, I remember this list now. I will review it again closely and post a follow-up to it if anything new comes to mind this time. (It's a good list...summarizes some of the key things in Harmen's paper.) > > Close to (a)...but not quite...I do not think that DPI--as > > a stand-alone solution--should be the only thing we reference > > in this exercise. > > I think that if we would take DPI and fix it in the areas which > require fixing, we will have what we are looking for and in very > short time if we will base our work on experience gained both in > DPI area and elsewhere. That is a valid proposition...let's see if support builds for that approach...we have to bear in mind the "vendor neutral" part of our mandate too. <...> 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, 27 Dec 1995 10:58:22 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id KAA17933 for X-agentx-local; Wed, 27 Dec 1995 10:58:22 -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 KAA17898 for ; Wed, 27 Dec 1995 10:58:20 -0800 (PST) Received: from nsmdserv.cnd.hp.com by hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA013170698; Wed, 27 Dec 1995 10:58:20 -0800 Received: from localhost by nsmdserv.cnd.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA214090700; Wed, 27 Dec 1995 11:58:20 -0700 Message-Id: <199512271858.AA214090700@nsmdserv.cnd.hp.com> To: natale@acec.com (Bob Natale) Cc: agentx@fv.com Subject: Roles and Responsibilities In-Reply-To: Your message of Wed, 27 Dec 1995 13:01:09 -0500. <9512271801.AA10972@nips.acec.com> Date: Wed, 27 Dec 1995 11:58:19 -0700 From: "Brian O'Keefe" AgentX WG Chair, Bob, I'm finding it increasingly difficult to distinguish between your messages posted as "WG Chair" versus "Technical Contributor". You obviously have an interest in the latter, but that can get difficult to balance against your duties as WG Chair -- maintain impartial order and process. Therefore, I would like to request that you compose your messages wearing only one hat or the other per message; and further, please indicate at top of the message which hat you're wearing. Regards, bok   Delivery-Date: Wed, 27 Dec 1995 11:21:35 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id LAA22086 for X-agentx-local; Wed, 27 Dec 1995 11:21:32 -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 LAA22083 for ; Wed, 27 Dec 1995 11:21:30 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA01913 for agentx@fv.com; Wed, 27 Dec 95 14:19:09 -0500 Date: Wed, 27 Dec 1995 14:17:15 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA12695; Wed, 27 Dec 1995 14:17:15 -0500 Message-Id: <9512271917.AA12695@nips.acec.com> To: bok@nsmdserv.cnd.hp.com Subject: Re: Roles and Responsibilities Cc: agentx@fv.com > Date: Wed, 27 Dec 1995 11:58:19 -0700 > From: Brian O'Keefe Hi Brian, > Bob, I'm finding it increasingly difficult to distinguish > between your messages posted as "WG Chair" versus "Technical > Contributor". You obviously have an interest in the latter, > but that can get difficult to balance against your duties as > WG Chair -- maintain impartial order and process. Ok. I've just been trying to get some discussion threads started and moving...I really haven't seen much need to wear a "WG Chair" hat yet. But you are definitely right about the need to maintain impartial order and process. And I do just want to let everyone know that I am still hoping for someone to fill the "Facilitator" role for this wg, to serve just that sole purpose. I have made the request, it is being considered and acted upon by the NMAD, and I think we will have one in the not too distant future. > Therefore, I would like to request that you compose your > messages wearing only one hat or the other per message; and > further, please indicate at top of the message which hat > you're wearing. Will do. 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, 27 Dec 1995 14:01:26 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id OAA23202 for X-agentx-local; Wed, 27 Dec 1995 14:01:24 -0800 (PST) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id OAA23199 for ; Wed, 27 Dec 1995 14:01:22 -0800 (PST) Received: from flume.zk3.dec.com by mail13.digital.com; (5.65v3.2/1.0/WV) id AA01529; Wed, 27 Dec 1995 16:51:56 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA21745; Wed, 27 Dec 1995 16:51:55 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA01801; Wed, 27 Dec 1995 16:52:14 -0500 Message-Id: <9512272152.AA01801@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 "Wed, 27 Dec 95 13:01:09 EST." <9512271801.AA10972@nips.acec.com> Date: Wed, 27 Dec 95 16:52:13 -0500 From: Mike Daniele X-Mts: smtp >> If I understand you correctly, then with all due respect, >> this idea is completely broken. >"Completely"? I think there are some deployed solutions >that use it or some variation of it. Of course, that >does not mean that it's "completely" unbroken either! Of course what I meant to say was "I feel strongly that this approach is frought with peril." Sorry :-) >> One of the design tenets of the existing solutions is that >> detailed knowledge of the MIB variables (how to get and set them, >> how many there are, what are their instance values) is contained >> in the subagent, not the master agent. >All of that knowledge remains in the component agents in my >scheme...especially the "how to get and set them" part...some >of that knowledge however...especially the "how many there are, >what are their instance values" part...*has* to be in the >system agent, IMHO, to overcome certain deficiencies/limitations >in the reference solutions. This is the crux of my concern. I feel that making the master agent maintain knowledge of all instances of every variable is both 'way outside of the solution space', and a poor design choice. (The 2 are probably not unrelated.) I'll try to be specific below. >> * My assertion assumes instance-level registration operations >> * (via simple SetRequests between component agents and the >> * system agent...not special-purpose PDUs). I hope to get off >> * a message about the multiple MIB dimensions that come into >> * play in the extensible agent scenario later today. >> >> I'm not opposing instance-level registration. >Whew! Had me fooled there for a moment! :-) >> But I think >> it's important to differentiate between permitting registration >> at this level of granularity, and FORCING it in an attempt to >> manage SNMP semantics. >I am not trying to force it in an attempt to manage SNMP semantics. >I am suggesting that it is required to meet certain field-proven >requirements efficiently (e.g., different rows in a single >table being managed by different component agents) and that >*once you satisfy that requirement* other implications fall >out it that might be useful (esp. in being able to simplify >the construction of component agents). OK, I see your point. But I think the component agents that result from this scheme are no less complicated than they would be otherwise. I agree that instance-level registration may be necessary, and as such should be permitted by the protocol. But registering instances of a particular row in a table seems to me something that only works for relatively static tables (for instance, ifTable). I don't think it's appropriate as a general purpose mechanism to be applied to all MIB tables/variables. In fact, I call upon the transparency principle :-) The master agent should not know anything about instances. It should accept registration of oids, and pass Get, GetNext, GetBulk, and Set* requests on to the best candidate component agent, in a manner specified by the standard protocol specification. > You may or may not >recall that one of the purported major complaints about the >people who reviewed SNMP as a possible management choice >for desktop systems balked at GetNext as being too complex >(mostly due to the lexicographic ordering requirements) and >voila! DMTF-ology arose. So a key principle here should be >(must be, IMHO): Simplify component agent construction to >the maximum extent possible...moving additional complexity >into the system agent is a positive trade-off for this purpose. I disagree. Not to the sentiment, but its application. In fact, most of the details of this protocol will be hidden from end users/developers anyway behind some API. If someone wishes to create an API that does not have GetNext, they may certainly do so. We're trying to specify a protocol. The protocol must be efficient and complete. IMHO, trying to hide GetNext from the protocol is a mistake, and contrary to the goals of the WG (as I understand them, I could be dead wrong here.) Well, on to some specifics... >> The subagent method routine will have no chance to optimize >> it's access to MIB data (that is, fetch everything now that >> it will need to service the request). >I don't think this is true. It will have whatever chance is >built into it by its implementors...it may choose an optimization >scheme totally asynchronous to the system agent (e.g., read all >permanent read-only values at init time and hold them in >memory in case the system agent ever asks for them). Some >implementations of the RDBMS MIB, for example, choose such an >asynchronous scheme...i.e., some variables are loaded into >the sub-agent at some longer interval and some are loaded at >some shorter interval and requests from the master agent are >filled from these two caches at request time. But what you've described isn't "fetch everything now that I will need to service this request", it's "fetch EVERYTHING, every n seconds, regardless of whether anyone wants it or not." If n is not sufficiently small, you lose the realtime nature of SNMP. If n is sufficiently small, you waste a lot of resources doing this when no requests are outstanding. Certainly some component agents with huge latency will have to do this anyway. But they shouldn't ALL have to due to the protocol definition. (I think this is an argument against the master knowing about instances in general, and not specifically lack of GetBulk.) >> The master and subagent will be forced to exchange many >> data packets instead of only 1. >Not necessarily...not intended...see above. >> o Seems to impose huge runtime overhead when processing >> dynamic tables. >Please elaborate...my intention is just the opposite. >> Consider as an example a Host Resources MIB subagent >> on a unix timesharing system system. Specifically, think about >> the hrSWRunTable and hrSWRunPerfTable, an entry in both of them >> being required for EACH process on the system. >Please elaborate...yes, entries *must* be maintained in both of >those tables for each process running on the system...presumably >in the component agent directly instrumenting the HR MIB...what's >that got to do with the system agent and instance-level registration? >Well, for each process that the component agent loads into its tables >it would let the system agent know the instance (index) value. How does it do that? Let's say system agent receives GetNextRequest{ hrSWRunTable }. Currently the first registered row has index = 2. so it sends GetRequest{ hrSWRunIndex.2 } to the component agent. But that process no longer exists. the component agent now must send back an error response. The system agent now must o remove the registered entry for index = 2 ? o send a GetRequest for the next registered entry? What if that one doesn't exist either? o wait for the component agent to register somehow? At the very least, it requires sending twice as many packets as it would via DPI/eSNMP: == GetNextRequest{hrSWrunTable} ==>> <<== Response{hrSWRunIndex.3 = 3} == In a nutshell, what I'm trying to say is this: A component agent has to understand how to implement its MIB objects. That means it has to understand how to assign instance values. That means it has to understand SNMP's lexicographical nature. Given that, the work of actually processing a GetNext vs GetRequest is trivial. Using the same example, here is the routine in my Host MIB implementation that handles GetNext semantics: static hrm_proc_t *find_proc_entry( int index, int search ) { hrm_proc_t *p; for (p = proclist; p; p = p->next) { if (((search == ESNMP_ACT_GET) && (p->pid == index)) || ((search != ESNMP_ACT_GET) && (p->pid > index))) break; } return(p); } The entire module is 800 lines of code... The hard part was loading proclist, not handling GetNext/Bulk. So we wouldn't be achieving any meaningful savings in component agents by hiding GetNext, IMO. And we'd be ADDING the work of registering each of these instances, and the runtime hit of fixing up stale entries in the system agent. > > A simple GetRequest for sysUpTime from the component agent to > > the system agent (aka, master agent, core agent). > > I think it's broken to assume the master agent contains any > particular MIB implementation. >Ok...let me rephrase that...the component agent (just like >some remote management entity) makes a request of the >*extensible agent* (which it sees as the system agent)... >the system agent might field the request for sysUpTime to >some other component agent that happens to be instrumenting >that part of MIB-II, but this is transparent to the requesting >component agent. I thought that accessing MIB variable values by component agents was outside the scope of (or at least not an explicit goal of) the WG? At the very least, it injects new complexity. Neither eSNMP, nor any of the other reference implementations provide data requests from a component agent to the system agent. It makes life much simpler this way. I still think the 'ping' PDU is more to the point, and a lot simpler, than defining a 2-way data path. >I am not suggesting that we impose such an architectural constraint. >I am trying to avoid the design of any new PDU types...I believe >that existing SNMP PDUs can be made to suffice quite nicely. I disagree. The functions of system <-> component agent communication are different than the functions of SNMP application <-> SNMP agent communication. >It goes without saying, of course, that I could be very wrong. You and me both! But the reference implementations are quite similar. My feeling is that we should stick with that basic design and work on the specific areas that need it. Regards, Mike   Delivery-Date: Wed, 27 Dec 1995 15:05:33 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id PAA07267 for X-agentx-local; Wed, 27 Dec 1995 15:05:33 -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 PAA07261 for ; Wed, 27 Dec 1995 15:05:32 -0800 (PST) Received: from pobox ([134.177.1.95]) by lightning.synoptics.com (4.1/SMI-4.1) id AA26024; Wed, 27 Dec 95 15:01:37 PST Received: from wolverine.engwest by pobox (4.1/SMI-4.1) id AA09704; Wed, 27 Dec 95 14:56:30 PST Received: by wolverine.engwest (4.1/SMI-4.1) id AA03533; Wed, 27 Dec 95 14:57:04 PST Date: Wed, 27 Dec 95 14:57:04 PST From: johns@BayNetworks.COM (John Seligson) Message-Id: <9512272257.AA03533@wolverine.engwest> To: natale@acec.com, daniele@zk3.dec.com Subject: Re: PDUs, proto-ops, and principles Cc: agentx@fv.com > I thought that accessing MIB variable values by component agents > was outside the scope of (or at least not an explicit goal of) > the WG? > At the very least, it injects new complexity. Neither eSNMP, > nor any of the other reference implementations provide data requests > from a component agent to the system agent. It makes life much > simpler this way. Supporting object access requests from a subagent to other subagents or to the master agent is required in a general purpose solution. As an example, take an RMON subagent. Allowing any managed MIB object to be monitored (which is typical nowadays) means that the RMON subagent must be allowed to issues Get requests for objects possibly implemented in other subagents or in the master agent. I believe EMANATE includes this functionality. Set support between subagents is a big rat hole... John   Delivery-Date: Wed, 27 Dec 1995 15:09:30 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id PAA08235 for X-agentx-local; Wed, 27 Dec 1995 15:09: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 PAA08225 for ; Wed, 27 Dec 1995 15:09:29 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA21395 for agentx@fv.com; Wed, 27 Dec 95 18:07:07 -0500 Date: Wed, 27 Dec 1995 18:05:14 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA17324; Wed, 27 Dec 1995 18:05:14 -0500 Message-Id: <9512272305.AA17324@nips.acec.com> To: daniele@zk3.dec.com Subject: Re: PDUs, proto-ops, and principles Cc: agentx@fv.com > Date: Wed, 27 Dec 95 16:52:13 -0500 > From: Mike Daniele Hi Mike, [Speaking as a technical contributor...] You gave a very impressive explanation of your position wrt instance-level registration. I will forego a point-by-point response since none is needed. I would like to make just a couple of technical observations here and then there were a couple of "process-like" comments you made that I will reply to below when [speaking as wg chair...]. <...> > I agree that instance-level registration may be necessary, > and as such should be permitted by the protocol. But registering > instances of a particular row in a table seems to me something > that only works for relatively static tables (for instance, > ifTable). I don't think it's appropriate as a general > purpose mechanism to be applied to all MIB tables/variables. I understand...sounds like there's grounds for an eventual compromise position in that. <...> > We're trying to specify a protocol. The protocol must be efficient > and complete. IMHO, trying to hide GetNext from the protocol > is a mistake, Ok...we agree on the first two points; disagree on the last. [speaking as wg chair...] > and contrary to the goals of the WG (as I understand them, > I could be dead wrong here.) As far as our charter is concerned we have only one mandatory goal and I don't think it excludes or mandates anything wrt instance-level registration or GetNext or anything like that. [off...] <...> > But what you've described isn't "fetch everything now that I > will need to service this request", it's "fetch EVERYTHING, every > n seconds, regardless of whether anyone wants it or not." I was only describing how some *existing* sub-agents do it in practice now. It's not an approach that I am particularly fond of and probably would not have designed. On the other hand, it does seem to work adequately in practice for the target user community. I was merely using it as an example of how component agents could still use the some "cache-ahead" technique even without waiting for a GetNext/Bulk request to trigger it. <...> > >Well, for each process that the component agent loads into its tables > >it would let the system agent know the instance (index) value. > > How does it do that? Via a simple SetRequest into the system agent...in fact, it is worth pointing out (admiitting?) that it might be the case that the system agent *assigns* an index value that is visible to the external management applications (and not even necessarily known to the component agent). > Let's say system agent receives GetNextRequest{ hrSWRunTable }. > Currently the first registered row has index = 2. > so it sends GetRequest{ hrSWRunIndex.2 } to the component agent. > > But that process no longer exists. > the component agent now must send back an error response. Not necessarily. My scheme uses a symmetrical SetRequest into the system agent to unregister instances too. The component agent returns an SNMP error (noSuchInstance) only in the case when the GetRequest for the instance arrives after the instance has gone out of existence and the before the component agent had a chance to send off the unregister SetRequest. This should be rare in practice. Furthermore, upon receipt of a noSuchInstance error, the system agent knows to purge the instance from its table. Btw, let me take this opportunity to note that--completely outside the context of this exchange--I have reviewed an algorithm that shows how to find instances without instance level registration...it seems to rely upon the processing of noSuch<> error responses as the primary driver and, therefore, not optimal, IMHO. <...> > In a nutshell, what I'm trying to say is this: > > A component agent has to understand how to implement its MIB objects. Agreed. > That means it has to understand how to assign instance values. Maybe...well, ok, at least insofar as its own MIB space is concerned. > That means it has to understand SNMP's lexicographical nature. To at least a limited extent, yes. <...> [speaking as wg chair...] > I thought that accessing MIB variable values by component agents > was outside the scope of (or at least not an explicit goal of) > the WG? No, if this can help us meet the mandatory goal, then its not outside the scope. It is not an explicit goal...its a (potential) means to the required end. [off...] > > At the very least, it injects new complexity. Neither eSNMP, > nor any of the other reference implementations provide data requests > from a component agent to the system agent. It makes life much > simpler this way. You could be right about that. It really will come down to is the cost of the "much simpler" a too-small solution space. Of course, you could be wrong about that too, when you look at the overall protocol capabilities and complexity points. As one individual technical contributor, I don't think that I have enough evidence for a convincing conclusion either way. But I'm definitely interested in hearing more from you and other viewpoints too. > I still think the 'ping' PDU is more to the point, and a lot > simpler, than defining a 2-way data path. Again, if the need for a special PDU type were limited to just one function, you would probably be right. But at some point the need for special purpose PDUs to accomplish overall extensible agent effectiveness and efficiency will tend to argue for a bi-directional use of standard PDUs, IMHO. > >I am not suggesting that we impose such an architectural constraint. > >I am trying to avoid the design of any new PDU types...I believe > >that existing SNMP PDUs can be made to suffice quite nicely. > > I disagree. The functions of system <-> component agent communication > are different than the functions of SNMP application <-> SNMP agent > communication. Now that's a claim that merits further discussion. But you are reading me right...I do believe that it will be fruitful to see the system agent<->component agent relationship as analogous to the standard SNMP app<->SNMP agent relationship. > >It goes without saying, of course, that I could be very wrong. > > You and me both! But the reference implementations are quite similar. > My feeling is that we should stick with that basic design and work > on the specific areas that need it. Sounds good to me...my initial stabs at the last part of that ("work on the specific areas that need it") have led me to: - quasi-complete MIB (registration) knowledge on the part of the system agent; and - bi-directional SNMP exchanges between the the system agent and the component agents for intra-agentx operations. It would be most helpful to hear what you and others see as the specific areas that need work based upon your reviews and analyses of the reference implementations. It would also be most helpful to receive some structured information about some of the other major or interesting extensible agent implementations (e.g., EMANATE, ENVOY, etc.). It would be nice if this info were to come from the primary sources, but it will be helpful nonetheless if it comes from knowledgeable secondary sources. 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, 27 Dec 1995 15:29:02 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id PAA12254 for X-agentx-local; Wed, 27 Dec 1995 15:29:01 -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 PAA12236 for ; Wed, 27 Dec 1995 15:29:00 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA23047 for agentx@fv.com; Wed, 27 Dec 95 18:29:10 -0500 Date: Wed, 27 Dec 1995 18:27:17 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA17806; Wed, 27 Dec 1995 18:27:17 -0500 Message-Id: <9512272327.AA17806@nips.acec.com> To: johns@baynetworks.com Subject: Re: PDUs, proto-ops, and principles Cc: agentx@fv.com > Date: Wed, 27 Dec 95 14:57:04 PST > From: johns@BayNetworks.COM (John Seligson) Hi John, [Speaking as a technical contributor...] <...> > Supporting object access requests from a subagent to other subagents > or to the master agent is required in a general purpose solution. > As an example, take an RMON subagent. Allowing any managed MIB > object to be monitored (which is typical nowadays) means that the > RMON subagent must be allowed to issues Get requests for objects > possibly implemented in other subagents or in the master agent. I am hopeful that it can be limited to component agent to system agent (which might in turn access a component agent to satisfy the request). > I believe EMANATE includes this functionality. I wish we had more info of this nature about EMANATE, ENVOY, and other implementations not covered in Harmen's paper.... > Set support between subagents is a big rat hole... Yes...I don't think anyone has proposed this as of yet. 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, 28 Dec 1995 07:27:13 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id HAA19814 for X-agentx-local; Thu, 28 Dec 1995 07:27:12 -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 HAA19809 for ; Thu, 28 Dec 1995 07:27:11 -0800 (PST) Received: from flume.zk3.dec.com by mail11.digital.com; (5.65v3.2/1.0/WV) id AA18131; Thu, 28 Dec 1995 10:16:15 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA16312; Thu, 28 Dec 1995 10:16:14 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA01909; Thu, 28 Dec 1995 10:16:33 -0500 Message-Id: <9512281516.AA01909@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 "Wed, 27 Dec 95 18:05:14 EST." <9512272305.AA17324@nips.acec.com> Date: Thu, 28 Dec 95 10:16:33 -0500 From: Mike Daniele X-Mts: smtp Hi Bob, I'm trying not to beat a dead horse here, but I would like to address your general idea of the system agent assigning/ being made 'instantly' aware of index values. >> But what you've described isn't "fetch everything now that I >> will need to service this request", it's "fetch EVERYTHING, every >> n seconds, regardless of whether anyone wants it or not." >I was only describing how some *existing* sub-agents do it >in practice now. It's not an approach that I am particularly >fond of and probably would not have designed. On the other >hand, it does seem to work adequately in practice for the >target user community. I was merely using it as an example >of how component agents could still use the some "cache-ahead" >technique even without waiting for a GetNext/Bulk request >to trigger it. But it seems to me that this "cache everything every so often" approach would be mandated in order to work with the registration scenario you describe below. <...> >> >Well, for each process that the component agent loads into its tables >> >it would let the system agent know the instance (index) value. >> >> How does it do that? >Via a simple SetRequest into the system agent...in fact, it is >worth pointing out (admiitting?) that it might be the case >that the system agent *assigns* an index value that is visible >to the external management applications (and not even necessarily >known to the component agent). I don't understand how an index value could ever be hidden from the component agent, when eventually you have to ask the component agent to perform operations on specific instances of MIB variables. In general, I don't believe it is feasible for the system agent to assign index values. Once again, consider the Host MIB hrSWRunTable, where the entries are to be indexed by the process identifier native to the host system. Or consider the MIB II udpTable or tcpConnTable or ipRouteTable. These tables contain entries whose index values reflect the current state of the TCP/IP stack (speaking loosely). If there is a process whose pid is 1234, and a tcp connection from ip address 1.2.3.4 port 5 to our ip address (6.7.8.9) port 10, then there has to be a hrSWRunTable entry whose index is 1234, and a tcpConnTable entry whose index is 1.2.3.4.5.6.7.8.9.10. Do you really suggest the system agent can know how to "assign" such indexes? On this point I agree with you ONLY in 1 specific case, ifTable. Given the fundamental importance of the ifTable, and the use of ifIndex in several other MIBs, it would make sense to me, eventually, to make assignment of ifIndexes part of the extensible agent protocol. But ONLY ifIndexes. Well, that's my 2 cents anyway. >> Let's say system agent receives GetNextRequest{ hrSWRunTable }. >> Currently the first registered row has index = 2. >> so it sends GetRequest{ hrSWRunIndex.2 } to the component agent. >> >> But that process no longer exists. >> the component agent now must send back an error response. >Not necessarily. My scheme uses a symmetrical SetRequest >into the system agent to unregister instances too. >The component agent returns an SNMP error (noSuchInstance) >only in the case when the GetRequest for the instance >arrives after the instance has gone out of existence and the >before the component agent had a chance to send off the >unregister SetRequest. This should be rare in practice. As stated above, the only way to make this actually occur rarely is for the component agents to spend most of their life checking the current state of affairs and issuing lots of register/unregister messages (whatever form they take). Consider the huge amount of background activity (and resultant performance loss) for a Web server whose SNMP agent is implemented along your lines, and has to keep the udp and tcp tables up to date. All for nothing! Because nothing has made a request for any of this information. One of the rules we need to live by is that a system has other work to do besides providing SNMP management access. We need to keep the original SNMP principle in mind of keeping the agent simple. In my opinion, a design where the system agent is kept aware of all instances of all MIB variables implemented in all component agents all the time is never going to work well. And for MIBs whose tables are large and very dynamic, it would be disastrous. >> >I am not suggesting that we impose such an architectural constraint. >> >I am trying to avoid the design of any new PDU types...I believe >> >that existing SNMP PDUs can be made to suffice quite nicely. >> >> I disagree. The functions of system <-> component agent communication >> are different than the functions of SNMP application <-> SNMP agent >> communication. >Now that's a claim that merits further discussion. But you >are reading me right...I do believe that it will be fruitful >to see the system agent<->component agent relationship as >analogous to the standard SNMP app<->SNMP agent relationship. >> >It goes without saying, of course, that I could be very wrong. >> >> You and me both! But the reference implementations are quite similar. >> My feeling is that we should stick with that basic design and work >> on the specific areas that need it. >Sounds good to me...my initial stabs at the last part of that >("work on the specific areas that need it") have led me to: > - quasi-complete MIB (registration) knowledge > on the part of the system agent; and > - bi-directional SNMP exchanges between the > the system agent and the component agents > for intra-agentx operations. >It would be most helpful to hear what you and others see as >the specific areas that need work based upon your reviews >and analyses of the reference implementations. I think we have different frameworks for discussion. I am assuming the relative merit of the reference implementations, and therefore that o system <-> component agent data is NOT carried by SNMP, but by agentx o agentx component agents do NOT necessarily contain an SNMP protocol engine. they DO contain an agentx protocol engine. o agentx will look substantially like DPI, UT-SNMP, etc (OAA is really a different thing, since there is not really a protocol, both sides are linked into a single executable image) o therefore there will agentx Pdus which are not the same as SNMP Pdus o agentx will not use ASN.1 encoding o the primary purpose of agentx can really be viewed as inter-process communication The kinds of changes I imagine are things like small changes in the packet structure, more rigourous definitions of oid registration and how they are interpreted by the system agent, etc. Will there be 'row instance' registration or simply oid registration? Will agentx handle assigning ifIndexes? To me this is what 'focus on the solution space' means. (Admittedly there is room for interpretation.) >It would also be most helpful to receive some structured >information about some of the other major or interesting >extensible agent implementations (e.g., EMANATE, ENVOY, etc.). >It would be nice if this info were to come from the primary >sources, but it will be helpful nonetheless if it comes >from knowledgeable secondary sources. I'll post the basics of eSNMP (which is based on DPI) separately. As part of that I'll try and specify design goals and assumptions that I think are really part of all the reference implementations, as well as specific changes to DPI. Regarding Emanate, my understanding is that Emanate is proprietary, so knowledgable folk (end user/developers) are not at liberty to discuss it. Only SNMP Research can legally do that. Regards, Mike   Delivery-Date: Thu, 28 Dec 1995 10:30:19 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id KAA23042 for X-agentx-local; Thu, 28 Dec 1995 10:30:18 -0800 (PST) Received: from gateway.sequent.com (gateway.sequent.com [138.95.18.1]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id KAA23036 for ; Thu, 28 Dec 1995 10:30:16 -0800 (PST) Received: from eng3.sequent.com (eng3.sequent.com [138.95.7.14]) by gateway.sequent.com (8.6.12/8.6.9) with ESMTP id KAA24712 for ; Thu, 28 Dec 1995 10:29:45 -0800 Received: (from lff@localhost) by eng3.sequent.com (8.6.12/8.6.9) id KAA18180; Thu, 28 Dec 1995 10:30:24 -0800 Date: Thu, 28 Dec 1995 10:30:24 -0800 From: Lou Fernandez Message-Id: <199512281830.KAA18180@eng3.sequent.com> To: agentx@fv.com In-reply-to: <9512261829.AA15356@nips.acec.com> (natale@acec.com) Subject: Re: PDUs, proto-ops, and principles > From: natale@acec.com (Bob Natale) > > From: ralex@world.std.com (Aleksey Y Romanov) > > Date: Sat, 23 Dec 1995 12:05:03 -0500 (EST) > > > (from Bob Natale) > > > 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 > > > > There are three things I would like to note in this respect: > > > > No GetNext has to be a typo here - while master agent can figure out next > > object there is no way master agent can figure out next instance. > > No typo. The system agent (aka master agent) will know what > instances are available in the collection of active component > agents at any given point in time. (And the "noSuchInstance" > varbind exception can further refine this knowledge for the > case in which an instance goes out of scope between the time > it was registered and the subject Get operation, without an > intervening "unregister" operation.) > > My assertion assumes instance-level registration operations > (via simple SetRequests between component agents and the > system agent...not special-purpose PDUs). I hope to get off > a message about the multiple MIB dimensions that come into > play in the extensible agent scenario later today. Instance-level registration may be a reasonable technical solution for some classes of MIB variables. If the instances which exist don't change very often and if different instances are implemented by different subagents, instance-level registration can allow a master agent to efficiently choose an appropriate subagent to provide the variable values. However, there are classes of MIB variables which are a bad match for instance-level registration. Take, for example, the hrSWRunTable from hostmib. I'm writing this mail on an internal Sequent server. It's a nice quiet holiday period so the machine is fairly idle. It's running about 1300 processes now and starting 180 new processes per minute. The vast majority of these are the short-lived intermediates of processing UNIX commands and no one will ever care about them once they terminate. Today, my hostmib subagent doesn't even try to keep track of all the processes which are launched. Instead, it's demand-driven. When a query comes in, it decides what information needs to be acquired about the processes that are running right then. No effort need be spent on processes that started and terminated without any SNMP manager asking about them. If instance-level registration is required, the subagent will have to do an enormous amount of work to maintain in the master agent the current list of active processes. The majority of this work will be wasted because no manager will ever make a query for those instances. I think that if instance-level registration is going to be part of agentx, it must be optional. ...Lou -- Louis F. Fernandez Sequent Computer Systems lfernandez@sequent.com Beaverton, OR 97006-6063   Delivery-Date: Thu, 28 Dec 1995 11:08:26 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id LAA01114 for X-agentx-local; Thu, 28 Dec 1995 11:08:26 -0800 (PST) Received: from relay.hp.com (relay.hp.com [15.255.152.2]) by zloty.fv.com (8.7.3/8.7.1) with ESMTP id LAA01095 for ; Thu, 28 Dec 1995 11:08:23 -0800 (PST) Received: from nsmdserv.cnd.hp.com by relay.hp.com with ESMTP (1.37.109.16/15.5+ECS 3.3) id AA240727714; Thu, 28 Dec 1995 11:08:34 -0800 Received: from localhost by nsmdserv.cnd.hp.com with SMTP (1.37.109.16/15.5+ECS 3.3) id AA141607716; Thu, 28 Dec 1995 12:08:36 -0700 Message-Id: <199512281908.AA141607716@nsmdserv.cnd.hp.com> To: agentx@fv.com Subject: Re: PDUs, proto-ops, and principles In-Reply-To: Your message of Wed, 27 Dec 1995 16:52:13 -0500. <9512272152.AA01801@bernie.zk3.dec.com> Date: Thu, 28 Dec 1995 12:08:36 -0700 From: "Brian O'Keefe" There's one thing that I hope is not getting lost in this discussion over instance level registration. That is the fact that two *different* instances of the same mib object may exist w/in the same agent (or sub-agent) with the *same* instance oid in cases where the naming scope (i.e., community or context) differs. Regards, bok   Delivery-Date: Thu, 28 Dec 1995 14:44:13 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id OAA16274 for X-agentx-local; Thu, 28 Dec 1995 14:44: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 OAA16268 for ; Thu, 28 Dec 1995 14:44:08 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA02995 for agentx@fv.com; Thu, 28 Dec 95 17:44:19 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA12568; Thu, 28 Dec 1995 17:41:49 -0500 Date: Thu, 28 Dec 1995 17:45:11 EST From: Bob Natale Subject: Re: PDUs, proto-ops, and principles To: Lou Fernandez , Mike Daniele Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi Lou (and Mike), [Speaking as a technical contributor...] Well, you and Mike Daniele have convinced me to revise my position...I'm not 100% happy about doing so, but I think you've made one argument that I cannot overcome. <...> > Instance-level registration may be a reasonable technical solution for > some classes of MIB variables. If the instances which exist don't > change very often and if different instances are implemented by > different subagents, instance-level registration can allow a master > agent to efficiently choose an appropriate subagent to provide the > variable values. Right. And it's that "if different instances are implemented by different subagents" part that I was focused on...I see many emerging scenarios where different component agents will account for different rows in tables. The solutions I have seen so far which do not entail instance-level knowledge in the system agent appear to be highly inefficient and somewhat inelegant, IMHO. > However, there are classes of MIB variables which are a bad match for > instance-level registration. Take, for example, the hrSWRunTable from > hostmib. I'm writing this mail on an internal Sequent server. It's a > nice quiet holiday period so the machine is fairly idle. It's running > about 1300 processes now and starting 180 new processes per minute. The > vast majority of these are the short-lived intermediates of processing > UNIX commands and no one will ever care about them once they terminate. Ok. I could respond by saying that maybe components which exhibit extremely volatile data characteristics are not good candidates for participation in an extensible agent, but ought to be handled in some other way (e.g., proxy). Or, I could say that maybe components of this type should be bound more tightly into the system agent portion of the extensible agent. But, for various good reasons, I am not really saying either of those. Mainly, I think we ought to be trying to make the solution space as inclusive as possible at this stage so I don't want to start characterizing components as bad choices...furthermore, I am sure that most of us would expect the HRMIB to be a good candidate for a component agent. > Today, my hostmib subagent doesn't even try to keep track of all the > processes which are launched. Instead, it's demand-driven. When a > query comes in, it decides what information needs to be acquired about > the processes that are running right then. No effort need be spent on > processes that started and terminated without any SNMP manager asking > about them. This is the part I cannot refute. When I thought about doing so, my refutation was based on some assumptions I was making about the likely "transport" interface between the system agent and its component agents which, in my world, would be a highly efficient one...one in which an update to internal component agent memory space might *also* be an update to internal system agent memory space. I realize that this is an implementation feature that (1) might not be realizable in all environments and (2) should not come into consideration at this stage anyway. > If instance-level registration is required, the subagent will have to do > an enormous amount of work to maintain in the master agent the current > list of active processes. The majority of this work will be wasted > because no manager will ever make a query for those instances. Acknowledged. I yield. (Mike, I chose to use Lou's message to post this response since it was singularly focused on this point...I realize that you also made this point in your earlier posts, amidst several others that I felt I could refute.) > I think that if instance-level registration is going to be part of > agentx, it must be optional. I guess I have to agree with that view now too. The consequence of this for me is that component agents will have to deal with GetNext and GetBulk requests. 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, 28 Dec 1995 17:30:32 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id RAA19263 for X-agentx-local; Thu, 28 Dec 1995 17:30:31 -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 RAA19248 for ; Thu, 28 Dec 1995 17:30:29 -0800 (PST) Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id UAA14530; Thu, 28 Dec 1995 20:30:41 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA22349; Thu, 28 Dec 1995 20:27:13 -0500 From: ralex@world.std.com (Aleksey Y Romanov) Message-Id: <199512290127.AA22349@world.std.com> Subject: Re: PDUs, proto-ops, and principles To: natale@acec.com (Bob Natale) Date: Thu, 28 Dec 1995 20:27:13 -0500 (EST) Cc: agentx@fv.com In-Reply-To: from "Bob Natale" at Dec 28, 95 05:45:11 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > I guess I have to agree with that view now too. The consequence > of this for me is that component agents will have to deal with > GetNext and GetBulk requests. And hence with access control too. > BobN Aleksey   Delivery-Date: Thu, 28 Dec 1995 21:08:15 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id VAA28396 for X-agentx-local; Thu, 28 Dec 1995 21:08: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 VAA28391 for ; Thu, 28 Dec 1995 21:08:13 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA28676 for agentx@fv.com; Fri, 29 Dec 95 00:05:27 -0500 Date: Fri, 29 Dec 1995 00:03:34 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA19670; Fri, 29 Dec 1995 00:03:34 -0500 Message-Id: <9512290503.AA19670@nips.acec.com> To: bok@nsmdserv.cnd.hp.com, ralex@world.std.com Subject: Division of work between system and component agents Cc: agentx@fv.com Hi Brian and Aleksey, [Speaking as a technical contributor...] > Date: Thu, 28 Dec 1995 12:08:36 -0700 > From: "Brian O'Keefe" > > There's one thing that I hope is not getting lost in > this discussion over instance level registration. That > is the fact that two *different* instances of the same mib > object may exist w/in the same agent (or sub-agent) with > the *same* instance oid in cases where the naming scope > (i.e., community or context) differs. (As a technical aside, in my scheme of instance-level registration with system agent omniscience wrt MIB varible status (which now seems unlikely), your point would be covered...only one registraton of the instance would be required in the system agent because that info is used only to let the system agent know unambiguously and immediately which component agent will serve requests for it.) > From: ralex@world.std.com (Aleksey Y Romanov) > Date: Thu, 28 Dec 1995 20:27:13 -0500 (EST) > > > I guess I have to agree with that view now too. The consequence > > of this for me is that component agents will have to deal with > > GetNext and GetBulk requests. > > And hence with access control too. It is very important to consider the implications of these two points--which are indisputably correct, given certain assumptions about what a component agent is/should be/can be. One way of characterizing the problem space is "we need to support component agents of any conceivable (legitimate) nature". One way of characterizing the solution space is to say "we are going to limit the kinds of things which can qualify as agentx component agents". (I realize that the first characterization is somewhat more extreme than the second...in part that's accidental...in part it's for dramatic effect.) I would like to gather a (public) sense of how people feel about this issue. My (personal, technical) view is that we should confine component agents to a certain range of functionality that would be something less than a full-blown native SNMP agent. (Note that this would not prohibit a component agent from serving as something like (the little I know about) EMANATE's "native agent adapter".) How you see this issue has implications for the nature of the system agent too. At the "liberal" extreme, the system agent is not much more than a port multiplexor or packet dispatcher, and all component agents have to be full-blown SNMP agents in their own right. At the "conservative" extreme, the system agent is more of a "super agent"...fairly complex, but with possible system-wide efficiency gains and component agents can be restricted primarily to component instrumentation. Again, I'm just curious as to what others think about this...I look forward to hearing your views. 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, 28 Dec 1995 21:55:56 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id VAA07185 for X-agentx-local; Thu, 28 Dec 1995 21:55:56 -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 VAA07179 for ; Thu, 28 Dec 1995 21:55:54 -0800 (PST) Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id AAA02971; Fri, 29 Dec 1995 00:56:07 -0500 Received: by world.std.com (5.65c/Spike-2.0) id AA08567; Fri, 29 Dec 1995 00:54:15 -0500 From: ralex@world.std.com (Aleksey Y Romanov) Message-Id: <199512290554.AA08567@world.std.com> Subject: Re: Division of work between system and component agents To: natale@acec.com (Bob Natale) Date: Fri, 29 Dec 1995 00:54:15 -0500 (EST) Cc: agentx@fv.com In-Reply-To: <9512290503.AA19670@nips.acec.com> from "Bob Natale" at Dec 29, 95 00:03:34 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > Hi Brian and Aleksey, > > [Speaking as a technical contributor...] > > > Date: Thu, 28 Dec 1995 12:08:36 -0700 > > From: "Brian O'Keefe" > > > > There's one thing that I hope is not getting lost in > > this discussion over instance level registration. That > > is the fact that two *different* instances of the same mib > > object may exist w/in the same agent (or sub-agent) with > > the *same* instance oid in cases where the naming scope > > (i.e., community or context) differs. > > (As a technical aside, in my scheme of instance-level > registration with system agent omniscience wrt MIB > varible status (which now seems unlikely), your point > would be covered...only one registraton of the instance > would be required in the system agent because that info > is used only to let the system agent know unambiguously > and immediately which component agent will serve requests > for it.) Bob, it seems to me that you are missing Brian's point. He is saying nothing else than, 'registration process has to allow different sub-agents to handle same instance(s) of different contexts'. This requirement is trivial to meet (it is just important not to forget about it): during registration time sub-agent informs master-agent which context/sub-tree combination(s) it is going to handle and then it is (not-complicated) task of master-agent to distribute requests to appropriate sub-agents. There is another issue closely related to this one. It is quite possible that one sub-agent (considered as network/program entity) can handle several sub-trees (e.g. main table and its enterprise specific augmentation). So, there should be piece in the protocol exchange format what one of these sub-trees master-agent has in mind while sending this packet. > > From: ralex@world.std.com (Aleksey Y Romanov) > > Date: Thu, 28 Dec 1995 20:27:13 -0500 (EST) > > > > > I guess I have to agree with that view now too. The consequence > > > of this for me is that component agents will have to deal with > > > GetNext and GetBulk requests. > > > > And hence with access control too. > > It is very important to consider the implications of these > two points--which are indisputably correct, given certain > assumptions about what a component agent is/should be/can be. > One way of characterizing the problem space is "we need to > support component agents of any conceivable (legitimate) > nature". One way of characterizing the solution space is to > say "we are going to limit the kinds of things which can > qualify as agentx component agents". (I realize that the > first characterization is somewhat more extreme than the > second...in part that's accidental...in part it's for > dramatic effect.) Bob, as I said first characterization is not complex at all. Second one is simply unavoidable, while unpleasant to handle in distributed environment. > BobN Aleksey   Delivery-Date: Fri, 29 Dec 1995 06:17:46 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id GAA21394 for X-agentx-local; Fri, 29 Dec 1995 06:17:45 -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 GAA21391 for ; Fri, 29 Dec 1995 06:17:44 -0800 (PST) Received: from ftp.com by ftp.com ; Fri, 29 Dec 1995 09:17:57 -0500 Received: from mailserv-D.ftp.com by ftp.com ; Fri, 29 Dec 1995 09:17:57 -0500 Received: from toeloop.ftp.com (mquinn-slippp.ftp.com) by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA19350; Fri, 29 Dec 95 09:14:27 EST Message-Id: In-Reply-To: <9512290503.AA19670@nips.acec.com> References: Conversation <9512290503.AA19670@nips.acec.com> with last message <9512290503.AA19670@nips.acec.com> Priority: Normal To: Bob Natale Cc: agentx@fv.com Mime-Version: 1.0 From: Mary Quinn Subject: Re: Division of work between system and component agents Date: Fri, 29 Dec 95 09:18:57 EST Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Hi Bob, >> How you see this issue has implications for the nature >> of the system agent too. At the "liberal" extreme, the >> system agent is not much more than a port multiplexor >> or packet dispatcher, and all component agents have to >> be full-blown SNMP agents in their own right. At the >> "conservative" extreme, the system agent is more of a >> "super agent"...fairly complex, but with possible >> system-wide efficiency gains and component agents can >> be restricted primarily to component instrumentation. >> >> Again, I'm just curious as to what others think about >> this...I look forward to hearing your views. I can appreciate your desire to concentrate as much of the intelligence into the one master agent versus duplicating functionality into the many subagents. However, the technical limitations that people have raised in doing this seem to be overwhelming. While my personal application for this technology is pretty basic and probably could be fulfilled with subagents of restricted capabilities, I feel that the product of this working group should serve the needs of the general public. Vendors can always optimize the implementation of the "agentx protocol engine" based upon OS and/or provide client functions which encapsulate lower-level primitives. Do you have more information regarding the characterization of subagents whose restriction from this technology would simplify the protocol? Mary Mary Quinn FTP Software 2 High St. N. Andover, MA 01844 (508) 659-6294 mquinn@ftp.com FAX: (508) 659-6038   Delivery-Date: Fri, 29 Dec 1995 10:55:44 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id KAA07340 for X-agentx-local; Fri, 29 Dec 1995 10:55:44 -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 KAA07336 for ; Fri, 29 Dec 1995 10:55:43 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA22155 for agentx@fv.com; Fri, 29 Dec 95 13:55:51 -0500 Date: Fri, 29 Dec 1995 13:53:57 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA05052; Fri, 29 Dec 1995 13:53:57 -0500 Message-Id: <9512291853.AA05052@nips.acec.com> To: randy@peer.com Subject: "Richer registration semantics" Cc: agentx@fv.com Hi Randy, I was just going over your slides from the Dallas agentx meeting and noticed the following bullets: o richer registration semantics - enabling optimization - index sharing issues - cascading And there have been other postings on the list to a similar general effect. I would appreciate it very much if you would post a brief (as long as you think necessary!) narrative wrt these bullets to the list and, in particular, offer suggestions as to how the deployed reference protocols might need to be modified to achieve these enrichments (or some alternative strategy if you think that one is impossible). TIA for your continued contributions. 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, 29 Dec 1995 10:59:15 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id KAA08317 for X-agentx-local; Fri, 29 Dec 1995 10:59:15 -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 KAA08296 for ; Fri, 29 Dec 1995 10:59:13 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA22341 for agentx@fv.com; Fri, 29 Dec 95 13:59:23 -0500 Date: Fri, 29 Dec 1995 13:57:29 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA05133; Fri, 29 Dec 1995 13:57:29 -0500 Message-Id: <9512291857.AA05133@nips.acec.com> To: randy@peer.com Subject: "Set/Commit Optimizations" Cc: agentx@fv.com Hi Randy, In reviewing your slides form the Dallas agentx meeting, I also noticed the following two bullets: o SET optimization o commit protocol enhancement I would appreciate it very much if you would post a brief (or longer) narrative describing what you have in mind in this regard. In particular, if you can, please show how the deployed reference protocols might need to be changed to provide the improvements you envision. TIA for your continued contributions. 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, 29 Dec 1995 11:15:35 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id LAA10801 for X-agentx-local; Fri, 29 Dec 1995 11:15: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 LAA10793 for ; Fri, 29 Dec 1995 11:15:33 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA23488 for agentx@fv.com; Fri, 29 Dec 95 14:13:09 -0500 Date: Fri, 29 Dec 1995 14:11:16 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA05472; Fri, 29 Dec 1995 14:11:16 -0500 Message-Id: <9512291911.AA05472@nips.acec.com> To: bok@nsmdserv.cnd.hp.com Subject: "System Group Roles" Cc: agentx@fv.com 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. In particular, how the policy they embody would work in a couple of sample/hypthetical implementations and what, if any, specific changes to the deployed reference protocols would be necessary as a result. TIA for your continued contributions. Have a Happy New Year! 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, 29 Dec 1995 12:41:23 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id MAA29435 for X-agentx-local; Fri, 29 Dec 1995 12:41:20 -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 MAA29429 for ; Fri, 29 Dec 1995 12:41:18 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA01012 for agentx@fv.com; Fri, 29 Dec 95 15:38:56 -0500 Date: Fri, 29 Dec 1995 15:37:02 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA07389; Fri, 29 Dec 1995 15:37:02 -0500 Message-Id: <9512292037.AA07389@nips.acec.com> To: daniele@zk3.dec.com Subject: Re: PDUs, proto-ops, and principles Cc: agentx@fv.com > Date: Thu, 28 Dec 95 10:16:33 -0500 > From: Mike Daniele Hi Mike, [Speaking as a technical contributor...] > I'm trying not to beat a dead horse here, but I would like > to address your general idea of the system agent assigning/ > being made 'instantly' aware of index values. Well, I don't think you are (or were) beating a dead horse... even though I'll note again that I admit that the need to inform the system agent of index value (instance) changes in the absnece of a request from a higher-level management entity is a (potentially fatal) negative in my scheme (for component agents who manage large amounts of highly volatile data). I will also note, however, that all known solutions to date have some downsides to them from one or more perspectives and, in the end, we'll have to weigh the pros and cons of each viable solution to see which yields the biggest payoff...and all of them will have some cons, even the one we end up with. (Darn, that sounds so pessimistic... but I guess it's realistic nonetheless.) <...> > But it seems to me that this "cache everything every so often" > approach would be mandated in order to work with the registration > scenario you describe below. Definitely not. <...> > I don't understand how an index value could ever be hidden from the > component agent, when eventually you have to ask the component agent > to perform operations on specific instances of MIB variables. The system agent maps from index values it has "assigned" to the ones used by the component agents. Note that it would only do this assignment in the case where multiple component agents had the same index value for the same object. I think this approach is preferable to sending some sort of error packet back to the second component agent saying something like "Sorry, you cannot register this instance due to an index value conflict... please pick another index and try again". > In general, I don't believe it is feasible for the system agent to > assign index values. Hmmm. Don't see why not. It can be necessary to resolve index value conflicts among component agents (hopefully they will be relatively rare), since obviously the higher order management entities need to see uniqueness here. And there really is no need to bother the component agents with this. All the (infrequent) mapping can be done in the system agent, transparently to both the management entities and the component agents. > Once again, consider the Host MIB hrSWRunTable, where the entries are > to be indexed by the process identifier native to the host system. > > Or consider the MIB II udpTable or tcpConnTable or ipRouteTable. > These tables contain entries whose index values reflect the current > state of the TCP/IP stack (speaking loosely). > > If there is a process whose pid is 1234, and a tcp connection from > ip address 1.2.3.4 port 5 to our ip address (6.7.8.9) port 10, then > there has to be a hrSWRunTable entry whose index is 1234, and a > tcpConnTable entry whose index is 1.2.3.4.5.6.7.8.9.10. > > Do you really suggest the system agent can know how to "assign" such > indexes? Neither of these examples reflects a *need* for the system agent to assign an index. And, if it did, the assigned index would be transparent to the component agent, which would know about and get requests against its own assigned index in any case. > On this point I agree with you ONLY in 1 specific case, ifTable. > Given the fundamental importance of the ifTable, and the use of > ifIndex in several other MIBs, it would make sense to me, eventually, > to make assignment of ifIndexes part of the extensible agent protocol. > But ONLY ifIndexes. You're right that this is a potentially good example of when the index assignment (as seen by the management entities only) would be useful. I think there will be other tables in the future in which individual rows will be managed by different component agents and, ergo, with the possibility of index value collisions. In those cases, the system agent can assign a unique index value for exposure to the management entities and map this to the "real" index value for requests to each of the component agents when necessary. > Well, that's my 2 cents anyway. Ok...you get a lot for your money! (compliment) <...> > >Not necessarily. My scheme uses a symmetrical SetRequest > >into the system agent to unregister instances too. > > >The component agent returns an SNMP error (noSuchInstance) > >only in the case when the GetRequest for the instance > >arrives after the instance has gone out of existence and the > >before the component agent had a chance to send off the > >unregister SetRequest. This should be rare in practice. > > As stated above, the only way to make this actually occur > rarely is for the component agents to spend most of their > life checking the current state of affairs and issuing lots > of register/unregister messages (whatever form they take). You could be right, and that could be the flaw that kills this idea. However, let me just reiterate that I envision the bulk of component agents being of a nature that does not ential massive, continuous row creation/deletion operations. I could be wrong about that (especially since I've done no empirical analysis....) > Consider the huge amount of background activity (and resultant performance > loss) for a Web server whose SNMP agent is implemented along your lines, > and has to keep the udp and tcp tables up to date. I might suggest that a high-impact, mission-critical system-- particularly one with a quasi-dedicated purpose--might not be a good candidate for an extensible SNMP agent, but rather ought to have a dedicated monolithic SNMP agent that is tuned for performance and/or special management purposes. I know that this statement can be too easy of an escape hatch...but I do want to keep exposing the idea that not every SNMP manageable component ought to be plugged into an extensible agent in every case. Also, performance of the system agent<->component agent interface will be both platform- and implementation-specific. At the protocol level, I think we should address performance only insofar as ensuring that in providing the necessary scope of functionality in the protocol messages and protocol oerations, we do so with zero excess (unneeded, superfluous) overhead. > All for nothing! Because nothing has made a request for any of this > information. You're right. That, by itself, is a big negative. However, it has to be assessed, in the end, relative to costs in other solutions...e.g., forcing components to pick another index value due to collisions or, worse, simply not allowing a duplicate index registration or, worse.... > One of the rules we need to live by is that a system has other work > to do besides providing SNMP management access. We need to keep > the original SNMP principle in mind of keeping the agent simple. Yes, and that is my objective...but I read that, in this context, as: Keep the component agents simple relative to the system agent. > In my opinion, a design where the system agent is kept aware of > all instances of all MIB variables implemented in all component > agents all the time is never going to work well. You could be right. A lot depends upon the overall costs/benefits of other approaches in the context of an overall solution. This is a very difficult thing for us to deal with... We know that the eventual agentx protocol will only be of value in a "whole product" solution context for the end-users. But we are specifically dealing with only one of many important parts of that whole product solution in this forum...I am fairly convinced that almost everyone who contributes openly to this discussion always has a "whole product" solution in the back of his/her mind when arguing for protocol features. Perhaps this is inevitable. I notice in reviewing the reference protocols and other sources that much of that material either incorporates quasi-API features or explicitly refers to external API definitions for further understanding of the protocol choices. Somehow, I think, we have to overcome this temptation here (as much as I would personally like to engage in it! :-). I am sure that there are some among us (perhaps including you, Mike...but definitely excluding me) who are skilled protocol designers...who can identify the necessary characteristics of an efficient protocol and the optimal characteristics of an effective protocol, irrespective of higher layer concerns. Perhaps we could benefit by applying those criteria to the reference protocols and seeing what strengths and weaknesses emerge...? > And for MIBs whose tables are large and very dynamic, > it would be disastrous. Granted...this is the point I yielded on...reamins to be seen, however: - relative overall costs/benefits of other solutions - whether MIBs with those two characteristics are good candidates for component agents and/or whether some means of alleviating the negative effects can be identified. <...> > >It would be most helpful to hear what you and others see as > >the specific areas that need work based upon your reviews > >and analyses of the reference implementations. > > I think we have different frameworks for discussion. Perhaps you are right...if so, I suspect it goes back to the point I made about the "whole product" solution perspective. > I am assuming the relative merit of the reference implementations, Right...that is the right way to start. > and therefore that > > o system <-> component agent data is NOT carried by SNMP, but > by agentx Agentx *could* be an adaptation of SNMP...in fact, I do tend to favor this form of "re-use", if possible. > o agentx component agents do NOT necessarily contain an SNMP > protocol engine. they DO contain an agentx protocol engine. My view is that SNMP protocol engines exist aplenty...if they can be put to work for the component agents (since they will already be at work for the system agent), so much the better. > o agentx will look substantially like DPI, UT-SNMP, etc Maybe. If that is the technical conclusion of this effort, I think it will be a viable one. > (OAA is really a different thing, since there is not really > a protocol, both sides are linked into a single executable image) In general, I agree with your point. > o therefore there will agentx Pdus which are not the same as SNMP Pdus While viable (obviously, from the deployed solutions), I think this will be an inferior outcome *considered as a stand-alone item*. I think we should leverage SNMP as much as possible in the agentx protocol. Not only because it is equally (at least) technically viable, but I suspect that it will result in fewer non-technical concerns. > o agentx will not use ASN.1 encoding To me, this is a non-issue...since my view presupposes the availability of an SNMP protocol engine (to serve the system agent if nothing else) and, therefore, the component agents themselves won't really have to do the ASN.1/BER stuff. > o the primary purpose of agentx can really be viewed as inter-process > communication Interesting perspective. (Not meant to imply anything beyond that.) Maybe your statement is true of any protocol and, therefore, not significant...? (Emphasis on "maybe"...not meant to be a value judgment at all.) > The kinds of changes I imagine are things like small changes in the > packet structure, more rigourous definitions of oid registration and how > they are interpreted by the system agent, etc. Will there be 'row instance' > registration or simply oid registration? Will agentx handle assigning ifIndexes? > > To me this is what 'focus on the solution space' means. Great! I sincerely hope you will be able to post your specific changes as they impact the reference protocols in the very near future. That is EXACTLY the kind of contribution we need! > (Admittedly there is room for interpretation.) Well, you've got a good one...and we really do need to ensure that there is only one meaning of that over time...I think that for this early stage (although we don't have a luxury of time available to us), the concept is serving its purpose fairly well. <...> > I'll post the basics of eSNMP (which is based on DPI) separately. Ok. For the record, Mike has sent me a copy of the eSNMP spec. I have asked Marshall to put it on the agentx ftp server. I expect this to happen in the near future (not knowing Marshall's holiday plans), and either he or I will notify the list when it's available for downloading. > As part of that I'll try and specify design goals and assumptions > that I think are really part of all the reference implementations, > as well as specific changes to DPI. Terrific! [Speaking as wg chair...] > Regarding Emanate, my understanding is that Emanate is proprietary, > so knowledgable folk (end user/developers) are not at liberty to discuss it. > Only SNMP Research can legally do that. Well, then, I hope Jeff or someone will do so. Given EMANATE's status in the marketplace, it would be a shame not to include it among the reference protocols (ditto wrt Epilogue's ENVOY product). Jeff's presentation at the Dallas agentx meeting was very informative...but we need data structured for comparison more or less iaw Harmen's paper. Please note that even in the absence of that data and to the extent allowed by any license agreements or other legal documents, we should do our best to make sure that relevant details that can be made public about those products are made known if they can improve the eventual agentx protocol that we will publish. [off...] Happy New Year! 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, 29 Dec 1995 21:58:28 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id VAA25495 for X-agentx-local; Fri, 29 Dec 1995 21:58:28 -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 VAA25491 for ; Fri, 29 Dec 1995 21:58:27 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA03908 for agentx@fv.com; Sat, 30 Dec 95 00:58:39 -0500 Date: Sat, 30 Dec 1995 00:56:45 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA17434; Sat, 30 Dec 1995 00:56:45 -0500 Message-Id: <9512300556.AA17434@nips.acec.com> To: agentx@fv.com Subject: eSNMP spec available Hi everyone, The copy of the eSNMP that Mike Daniele has contributed is now available at: ftp://ftp.fv.com/pub/mrose/agentx/esnmp.txt Please take the time to review it and consider it in the context of the other reference protocols in the solution space. I am confident that Mike will soon post a synopsis of it on the list, along with some pointers to specific changes it makes vis-a-vis those other protocols and changes that must yet be made--in his view--to merit standardization. Happy New Year! 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: Sat, 30 Dec 1995 04:33:11 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id EAA04774 for X-agentx-local; Sat, 30 Dec 1995 04:33:11 -0800 (PST) Received: from ra.ibr.cs.tu-bs.de (ra.ibr.cs.tu-bs.de [134.169.246.34]) by zloty.fv.com (8.7.3/8.7.1) with SMTP id EAA04764 for ; Sat, 30 Dec 1995 04:33:09 -0800 (PST) Received: from data [134.169.34.7] by ra.ibr.cs.tu-bs.de (8.6.10/tubsibr) with ESMTP id NAA28552; Sat, 30 Dec 1995 13:33:18 +0100 Received: from schoenw@localhost by data.ibr.cs.tu-bs.de (8.6.10/tubsibr) id NAA19193; Sat, 30 Dec 1995 13:33:10 +0100 Date: Sat, 30 Dec 1995 13:33:10 +0100 Message-Id: <199512301233.NAA19193@data.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: lff@sequent.com CC: agentx@fv.com In-reply-to: <199512281830.KAA18180@eng3.sequent.com> (message from Lou Fernandez on Thu, 28 Dec 1995 10:30:24 -0800) Subject: Re: PDUs, proto-ops, and principles Reply-to: schoenw@ibr.cs.tu-bs.de Hi! On Thu, 28 Dec 1995 10:30:24 -0800, 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. 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 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. 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. 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. Happy New Year, Juergen --- Juergen Schoenwaelder schoenw@ibr.cs.tu-bs.de http://www.cs.tu-bs.de/~schoenw Technical University Braunschweig, Dept. Operating Systems & Computer Networks Bueltenweg 74/75, D-38106 Braunschweig, Germany. (Tel. +49 531 / 391-3249)   Delivery-Date: Sun, 31 Dec 1995 10:28:40 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.1) id KAA19243 for X-agentx-local; Sun, 31 Dec 1995 10:28:39 -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 KAA19237 for ; Sun, 31 Dec 1995 10:28:38 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA02868 for agentx@fv.com; Sun, 31 Dec 95 13:28:49 -0500 Date: Sun, 31 Dec 1995 13:26:56 -0500 From: natale@acec.com (Bob Natale) Received: by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA20774; Sun, 31 Dec 1995 13:26:56 -0500 Message-Id: <9512311826.AA20774@nips.acec.com> To: agentx@fv.com Subject: Change in agentx archives address Hi everyone, There has been a slight change in the ftp address of the agentx archives...the used to live at: ftp://ftp.fv.com/pub/mrose/agentx/ they now live at ftp://ftp.fv.com/pub/agentx/ both locations still work, but eventually the old one (mrose/agentx/) will go away. Continued thanks to FirstVirtual for hosting the archives and the e-mail listserver! Happy New Year! 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 -------------