Delivery-Date: Wed, 07 Feb 1996 09:14:12 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id JAA04666 for X-agentx-local; Wed, 7 Feb 1996 09:14:03 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id JAA04608 for ; Wed, 7 Feb 1996 09:14:00 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA23911 for ; Wed, 7 Feb 96 11:47:20 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA23220; Wed, 7 Feb 1996 11:45:57 -0500 Date: Wed, 7 Feb 1996 11:48:15 EST From: Bob Natale Subject: Re: Index Sharing To: Aleksey Y Romanov Cc: Maria Greene , agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Aleksey Y Romanov > Date: Tue, 23 Jan 1996 12:09:14 -0500 (EST) Hi Aleksey, Maria, and everyone else! [Speaking as wg chair...] Well, things have been very quiet on the agentx list for almost two weeks now...I assume that implies we've all been very busy on other pressing matters and not that we have lost interest in this community effort! I am going to resume the thread on "Index Sharing", beginning with this semi-procedural item, followed (soon) by a technical follow-up to Randy's earlier (excellent) overview of the this problem wrt allocating/disseminating index values. >mg> In my recent mail, in support of having index allocation be >mg> part of the agentx "solution space", I made the following >mg> statement: > > ??????? I am really puzzled here. It seems to me that in order > for anything to become part of the 'solution space' it has to be: > > 1. Engineered > 2. Implmented > 3. Spec published That's a good set of criteria, Aleksey (assuming a somewhat liberal interpretation of #3)... However, > IMHO, none of the above depends upon support expressed on the > mailing list. The "solution space" as delimited by your criteria is just our starting point. Clearly, it is not singularly sufficient... several implementations have some "extremities" not supported by the others and the area of overlap does not *appear* to cover enough of the generally perceived "problem space" to just leave it at that. So, we have to bring in enough new functionality/featuers to reach that point. (And one of my goals has been to try to restrain us from going beyond that point if any significant costs are involved in doing so.) It seems clear that resolving the "index sharing" problem is an addition that most contributors feel must be included. There will likely be some others...a very small set, I hope. So, building support on the mailing list for such inclusions and, moreso, specific approaches to them is appropriate. I hope to see a resumption of activity on this list. At the very least, let's work toward an agenda of specific issues to hammer out at the LA meetings for subsequent review on the list. Thanks for your continued participation. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Wed, 07 Feb 1996 20:05:47 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id UAA20631 for X-agentx-local; Wed, 7 Feb 1996 20:05:46 -0800 (PST) Received: from netra.soft.net (netra.soft.net [164.164.128.17]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id UAA20616 for ; Wed, 7 Feb 1996 20:05:42 -0800 (PST) Received: from plutonium.bflsl.soft.net. by netra.soft.net (5.x/SMI-SVR4) id AA22626; Thu, 8 Feb 1996 09:30:28 +0500 Received: by plutonium.bflsl.soft.net. (SMI-8.6/SMI-SVR4) id JAA02415; Thu, 8 Feb 1996 09:40:10 -0600 From: bflram@plutonium.bflsl.soft.net (Ramaprasad K.R.) Message-Id: <199602081540.JAA02415@plutonium.bflsl.soft.net.> Subject: Hello all To: agentx@fv.com Date: Thu, 8 Feb 96 9:40:09 GMT X-Mailer: ELM [version 2.3 PL11] Hi everybody, I am new on this list. If it is possible could somebody tell me what's been happening. Or if you can tell me where the information would be available, I'll look there. Thanks for your time and help -rampi   Delivery-Date: Fri, 09 Feb 1996 14:09:44 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id OAA28944 for X-agentx-local; Fri, 9 Feb 1996 14:09:44 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id OAA28935 for ; Fri, 9 Feb 1996 14:09:43 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA01088 for ; Fri, 9 Feb 96 16:50:50 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA06248; Fri, 9 Feb 1996 16:49:29 -0500 Date: Fri, 9 Feb 1996 16:52:02 EST From: Bob Natale Subject: WG Editor On-Board! To: agentx@fv.com Cc: dfrancisco@santa.stratacom.com, kostick@qsun.ho.att.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Hi everyone, I am very pleased to announce that Dale Francisco of StrataCom has agreed to serve as Editor for the agentx wg. Dale has significant hands-on knowledge wrt both the design and implementation of agents and managers, gained over the past five years...first at Network Equipment Technologies and now at StrataCom. Prior to this period, he worked professionally as a writer and editor. In addition to his technical qualifications, he is strongly motivated by some quality objectives he has for technical SNMP documentation. I am certain his efforts in this role will play a major role in both the development of and the eventual successful deployment of the agentx protocol. Dale will be at the LA IETF agentx meetings, which will surely give him some "raw material" to work with. In the interim, I will suggest some general approaches on the list for his consideration and general comment. Here is Dale's contact info: Dale Francisco dfrancisco@santa.stratacom.com Software Engineering StrataCom 93 South La Patera Lane Santa Barbara CA 93117 voice: (805) 961-3642 fax: (805) 961-3600 Have a good weekend! Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Fri, 09 Feb 1996 14:45:41 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id OAA10157 for X-agentx-local; Fri, 9 Feb 1996 14:45:40 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id OAA10152 for ; Fri, 9 Feb 1996 14:45:39 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA02813 for ; Fri, 9 Feb 96 17:03:30 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA06455; Fri, 9 Feb 1996 17:02:11 -0500 Date: Fri, 9 Feb 1996 17:04:43 EST From: Bob Natale Subject: Re: Hello all [agentx status] To: "Ramaprasad K.R." Cc: agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Ramaprasad K.R. > Date: Thu, 8 Feb 96 9:40:09 GMT Hi Rampi, > I am new on this list. If it is possible could somebody > tell me what's been happening. I did a summary of our progress earlier this month...I'll forward you a copy privately. Since then, we got into some serious technical discussion of the "index sharing" issues, and we may have it a (temporary) impasse, since activity has been very low (close to nil) over the past ten days or so. (I'll try to resuscitate it very soon!). We do have two meetings scheduled during the LA IETF. We are seriously behind on our chartered schedule.... (And if you have not reviewed the charter yet, you can access it from the IETF home page...or I'll be happy to send you a text copy.) > Or if you can tell me where the information would be > available, I'll look there. The wg's archives are at: ftp://ftp.fv.com/pub/agentx/ > Thanks for your time and help Glad to have you in the group! I will look forward to your input once you feel you are sufficiently up to speed (or before! :-). Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Tue, 13 Feb 1996 09:30:09 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id JAA04946 for X-agentx-local; Tue, 13 Feb 1996 09:30:07 -0800 (PST) Received: from motgate2.mot.com ([129.188.136.20]) by zloty.fv.com (8.7.3/8.7.3) with ESMTP id JAA04933 for ; Tue, 13 Feb 1996 09:30:06 -0800 (PST) Received: from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (8.7.3/8.6.10/MOT-3.8) with ESMTP id RAA12729 for ; Tue, 13 Feb 1996 17:19:40 GMT Received: from il02dns1.comm.mot.com (il02dns1.comm.mot.com [145.1.3.2]) by pobox.mot.com (8.7.3/8.6.10/MOT-3.8) with ESMTP id LAA11449 for ; Tue, 13 Feb 1996 11:30:03 -0600 (CST) Received: from eis.comm.mot.com (eis.comm.mot.com [145.1.171.1]) by il02dns1.comm.mot.com (8.7.2/8.7.2) with SMTP id LAA18055 for ; Tue, 13 Feb 1996 11:30:02 -0600 (CST) Received: from rastov48.comm.mot.com by eis.comm.mot.com (4.1/SMI-4.1) id AA06088; Tue, 13 Feb 96 11:29:59 CST Received: by rastov48.comm.mot.com (5.x/SMI-SVR4) id AA21225; Tue, 13 Feb 1996 11:29:56 -0600 Date: Tue, 13 Feb 1996 11:29:56 -0600 From: cong@eis-e2.comm.mot.com (David Cong) Message-Id: <9602131729.AA21225@rastov48.comm.mot.com> To: agentx@fv.com Subject: Set Operation for Action X-Sun-Charset: US-ASCII I have one question maybe relate to agent extensibility. If SNMP manager performs set on a variable to trigger an action, should I wait action done to send GETRESPONSE or as soon as I parse the PDU? I know action is not part of SNMP, but is there a general approach to trigger the action? I will appreaciate that if anyone can help me to clearify. Cheers, David   Delivery-Date: Wed, 14 Feb 1996 11:39:28 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id LAA14941 for X-agentx-local; Wed, 14 Feb 1996 11:39:28 -0800 (PST) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by zloty.fv.com (8.7.3/8.7.3) with ESMTP id LAA14935 for ; Wed, 14 Feb 1996 11:39:26 -0800 (PST) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.97.5]) by guelah.nexen.com (8.7.3/8.6.12) with ESMTP id OAA04780; Wed, 14 Feb 1996 14:39:17 -0500 (EST) Received: from avalon.nexen.com (avalon.nexen.com [204.249.99.77]) by maelstrom.nexen.com (8.7.3/8.6.12) with ESMTP id OAA20315; Wed, 14 Feb 1996 14:37:17 -0500 (EST) Received: (from greene@localhost) by avalon.nexen.com (8.7.3/8.6.12) id OAA18775; Wed, 14 Feb 1996 14:40:22 -0500 (EST) Date: Wed, 14 Feb 1996 14:40:22 -0500 (EST) From: Maria Greene Message-Id: <199602141940.OAA18775@avalon.nexen.com> To: Bob Natale cc: agentx@fv.com, mkc@nexen.com Subject: Re: Index Sharing References: >>>>> On Wed, 7 Feb 1996 11:48:15 EST, Bob Natale said: Bob> Hi Aleksey, Maria, and everyone else! Bob> [Speaking as wg chair...] Bob> Well, things have been very quiet on the agentx list for almost Bob> two weeks now...I assume that implies we've all been very busy Bob> on other pressing matters and not that we have lost interest in Bob> this community effort! Of course not. Most of us have "Real Jobs" in addition to our IETF activities which sometime cause us to drop in and out of ongoing discussions. I know this can make life frustrating, especially for motivated WG chairs. C'est la IETF! Bob> I am going to resume the thread on "Index Sharing", beginning Bob> with this semi-procedural item, followed (soon) by a technical Bob> follow-up to Randy's earlier (excellent) overview of the this Bob> problem wrt allocating/disseminating index values. I am not in favor of "index sharing" if that means that several component agents "own" instances with the same identifier value. The reason I have a problem with this is that many MIBs keep "pointers" to instances by keeping the value of the index. Interfaces are the best example. Take the Bridge MIB: it has bridge ports that have the value of ifIndex that they are associated with, which is probably an Ethernet interface maintained by an Ethernet component agent. As another example, a Frame Relay agent uses ifStackLowerPointer to indicate what lower layer interface (such as a ds1 interface or ds0 bundle) that it is stacked on top of. Most likely, it is a separate T1 component agent that implements the T1 MIB. In an earlier main, BobN proposed that the System Agent keep mappings between a global index value and each component's corresponding index value so that many component agents could use the same values. When the manager asks for something with index N, the system agent would have to translate that to the component agent's value. (Bob, correct me if I got that wrong.) But what about these values that are being used as instance pointers? I see no way that the system agent could know that the value of dot1dBasePortIfIndex needs to be translated. This is even worse of the instance pointer is being kept as an OID. Bob> It seems clear that resolving the "index sharing" problem is Bob> an addition that most contributors feel must be included. Bob> There will likely be some others...a very small set, I hope. Bob> So, building support on the mailing list for such inclusions Bob> and, moreso, specific approaches to them is appropriate. Yes, I see a lot of value in resolving the problem, however, I would prefer to solve it by coordinating index assignment. If component agents cooperate just enough to make sure their index values don't conflict, we're ok. And, if it's easy enough to achieve this coordination, we're ok. For each index that needs to be distributed, I propose a little "MIBlette" like this one for ifIndex. I'd like to draw attention to the Note in the ifMgrNextIndex description: Note that the component agent may take on a manager role and use SNMP requests to access these MIB variables, or it may use a local interface to the MIB data. This is completely implementation dependent. If the mechanism was an extension to the agentx system -> component agent protocol, this would be ideal. ifMgrNextIndex OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the next available ifIndex. This variable, in conjunction with the ifMgrLock and ifMgrNumIndices, is used to support centralized ifIndex assignment amongst several cooperating 'component agents' in a system. When a component agent needs to add rows to the ifTable, for example, when a user plugs a new board into a chassis or when the user configures a new 'logical interface', it uses these variables to reserve values for ifIndex that will not conflict with other component agents. The algorithm for doing this is summarized in the following pseudocode: while not done get (ifMgrLock, ifMgrNextIndex) lock_value = ifMgrLock if ( set (ifMgrLock = lock_value, ifMgrNumIndices = N ) != FAILURE) /* * I have the lock and have reserved my indices */ break; As an example, if the value of ifMgrNextIndex is 100, after the component agent successfully sets the ifMgrNumIndices to 10 (setting the ifMgrLock in the same PDU), the value of ifMgrNextIndex will be 110. Note that the component agent may take on a manager role and use SNMP requests to access these MIB variables, or it may use a local interface to the MIB data. This is completely implementation dependent. Note that this MIB group is essentially an implementation detail of the agent and will not generally be visible in a MIB view that is accessible by an SNMP entity acting in a manager role that is not a component agent." ::= { ifMgr 1 } ifMgrLock OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "A 'spin lock' which is used to coordinate access to the ifMgrNextIndex variable. A TestAndIncr variable can only successfully be set to its current value, after which it auto-increments to the next value. See the description of ifMgrNextIndex for an example of how this feature is used to coordinate access to a shared resource for ifIndex value reservation." REFERENCE "RFC 1903, Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2)." ::= { ifMgr 2 } ifMgrNumIndices OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-write STATUS current DESCRIPTION "The number of ifIndex values the entity setting this variable would like to reserve." ::= { ifMgr 3 } Bob> I hope to see a resumption of activity on this list. At Bob> the very least, let's work toward an agenda of specific Bob> issues to hammer out at the LA meetings for subsequent Bob> review on the list. I'd be glad to make a presentation out of this for LA. I know it is sometimes very difficult to "digest" long email messages. Bob> Thanks for your continued participation. You're welcome. Bob> Cordially, Bob> BobN Bob> ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob> Bob Natale | ACE*COMM | 301-258-9850 [v] Bob> Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] Bob> natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com Bob> ------- NetPlus (r) "FCAPS" Telemanagement Applications -------- Maria ________________________________________________________________________ Maria N. Greene greene@nexen.com Ascom Nexion 289 Great Rd., Acton MA 01720 USA +1 508 266-4570   Delivery-Date: Tue, 20 Feb 1996 12:17:09 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id MAA21092 for X-agentx-local; Tue, 20 Feb 1996 12:17:08 -0800 (PST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id MAA21087 for ; Tue, 20 Feb 1996 12:17:05 -0800 (PST) Received: from flume.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA01458; Tue, 20 Feb 1996 15:03:52 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA09599; Tue, 20 Feb 1996 15:03:45 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA11162; Tue, 20 Feb 1996 15:04:27 -0500 Message-Id: <9602202004.AA11162@bernie.zk3.dec.com> To: Maria Greene Cc: agentx@fv.com Subject: Re: Index Sharing In-Reply-To: Your message of "Wed, 14 Feb 96 14:40:22 EST." <199602141940.OAA18775@avalon.nexen.com> Date: Tue, 20 Feb 96 15:04:26 -0500 From: Mike Daniele X-Mts: smtp Hi Maria, > Bob> Well, things have been very quiet on the agentx list for almost > Bob> two weeks now...I assume that implies we've all been very busy > Bob> on other pressing matters and not that we have lost interest in > Bob> this community effort! >Of course not. Most of us have "Real Jobs" in addition to our IETF >activities which sometime cause us to drop in and out of ongoing >discussions. I know this can make life frustrating, especially for >motivated WG chairs. C'est la IETF! Yes indeed. I personally am thinking of starting a 12-step support group for those who have implemented RFC 1514 ... :-) > Yes, I see a lot of value in resolving the problem, however, I would >prefer to solve it by coordinating index assignment. If component >agents cooperate just enough to make sure their index values don't >conflict, we're ok. And, if it's easy enough to achieve this >coordination, we're ok. I agree. >If the mechanism was an extension to the agentx system -> component >agent protocol, this would be ideal. I agree. It seems reasonable to me to make this part of agentx registration. > As an example, if the value of ifMgrNextIndex is 100, > after the component agent successfully sets the > ifMgrNumIndices to 10 (setting the ifMgrLock in > the same PDU), the value of ifMgrNextIndex will be > 110. And this implies that the system agent should assume the existance of conceptual rows 100-109, and that they 'belong to' this component agent? Thanks Mike   Delivery-Date: Tue, 20 Feb 1996 13:40:40 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id NAA13260 for X-agentx-local; Tue, 20 Feb 1996 13:40:39 -0800 (PST) Received: from guelah.nexen.com (guelah.nexen.com [204.249.96.19]) by zloty.fv.com (8.7.3/8.7.3) with ESMTP id NAA13236 for ; Tue, 20 Feb 1996 13:40:30 -0800 (PST) Received: from maelstrom.nexen.com (maelstrom.nexen.com [204.249.99.5]) by guelah.nexen.com (8.7.3/8.7.3) with ESMTP id QAA26264; Tue, 20 Feb 1996 16:37:50 -0500 (EST) Received: from avalon.nexen.com (avalon.nexen.com [204.249.99.77]) by maelstrom.nexen.com (8.7.3/8.7.3) with ESMTP id QAA11890; Tue, 20 Feb 1996 16:37:29 -0500 (EST) Received: (from greene@localhost) by avalon.nexen.com (8.7.3/8.7.3) id QAA14492; Tue, 20 Feb 1996 16:38:59 -0500 (EST) Date: Tue, 20 Feb 1996 16:38:59 -0500 (EST) From: Maria Greene Message-Id: <199602202138.QAA14492@avalon.nexen.com> To: Mike Daniele cc: agentx@fv.com Subject: Re: Index Sharing References: <199602141940.OAA18775@avalon.nexen.com> <9602202004.AA11162@bernie.zk3.dec.com> >>>>> On Tue, 20 Feb 96 15:04:26 -0500, Mike Daniele said: Mike> Hi Maria, Howdy, Mike. >If the mechanism was an extension to the agentx system -> component >agent protocol, this would be ideal. Mike> I agree. It seems reasonable to me to make this part of agentx Mike> registration. Not just registration -- interfaces may be created dynamically. New cards may be inserted into a chassis (that supports hot insertion) and new "logical interfaces" can be configured (such as frame relay "logical ports" or "ds0 bundles" or "LAN Emulation client interfaces"...) > As an example, if the value of ifMgrNextIndex is 100, > after the component agent successfully sets the > ifMgrNumIndices to 10 (setting the ifMgrLock in > the same PDU), the value of ifMgrNextIndex will be > 110. Mike> And this implies that the system agent should assume the existance Mike> of conceptual rows 100-109, and that they 'belong to' this component Mike> agent? No, actually. The system agent doesn't have to 'know' or assume anything. It most definitely doesn't have to keep track of what component agents were allocated what index values. It just has to provide GET access to the ifMgrNextIndex and bump that value by ifMgrNumIndices when ifMgrNumIndices is set. (In fact, in our implementation, it isn't the system agent that supports these three MIB variables since our "system agent" is the EMANATE Master Agent which we didn't implement). Mike> Thanks Mike> Mike Hope this helps clear things up, Maria   Delivery-Date: Wed, 21 Feb 1996 06:40:51 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id GAA11794 for X-agentx-local; Wed, 21 Feb 1996 06:40:51 -0800 (PST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id GAA11784 for ; Wed, 21 Feb 1996 06:40:50 -0800 (PST) Received: from flume.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA17363; Wed, 21 Feb 1996 09:28:26 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA29547; Wed, 21 Feb 1996 09:28:23 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA11505; Wed, 21 Feb 1996 09:28:56 -0500 Message-Id: <9602211428.AA11505@bernie.zk3.dec.com> To: greene@nexen.com Cc: agentx@fv.com Subject: Index Sharing via registration Date: Wed, 21 Feb 96 09:28:55 -0500 From: Mike Daniele X-Mts: smtp Hi Maria, >>If the mechanism was an extension to the agentx system -> component >>agent protocol, this would be ideal. >No, actually. The system agent doesn't have to 'know' or assume >anything. It most definitely doesn't have to keep track of what >component agents were allocated what index values. Do you agree though that if index assignment was done via agentx, the system agent would already know this information? > It just has to >provide GET access to the ifMgrNextIndex and bump that value by >ifMgrNumIndices when ifMgrNumIndices is set. (In fact, in our >implementation, it isn't the system agent that supports these three >MIB variables since our "system agent" is the EMANATE Master Agent >which we didn't implement). So what do you actually register with the master agent? ifTable? Mike> I agree. It seems reasonable to me to make this part of agentx Mike> registration. >Not just registration -- interfaces may be created dynamically. New >cards may be inserted into a chassis (that supports hot insertion) and >new "logical interfaces" can be configured (such as frame relay >"logical ports" or "ds0 bundles" or "LAN Emulation client >interfaces"...) So when your component agents determine new interfaces exist, they manipulate the ifMgrxxx variables to allocate new values of ifIndex for themselves. What if instead, they performed agentx registration of new rows in the ifTable? This 'special' registration of rows in shared tables would have to provide the same capability you described (grant to the component agent an index or block of indexes). If (un)registration were completely dynamic, it seems like your requirements would be met. (Or am I missing something?) Another possibly large win in doing this by agentx registration is the subsequent system agent dispatching. In the environment you describe (please correct me if I'm wrong) the system agent is unaware of individual index assignments. It is only aware that multiple component agents have registered subtrees that overlap on ifTable. So when any SNMP request arrives that requires operation on ifTable, ALL component agents must be notified and respond. The system agent then selects one of the responses. What I'm suggesting is that if shared table index assignment could be done via agentx registrations, the system agent COULD correctly dispatch to only a single component agent. It seems to me this would be a large win in the efficiency (and perhaps data integrity) of agentx. Especially when servicing say, GetBulk. Of course, it might be more trouble than it's worth... Thoughts welcome. Regards, Mike   Delivery-Date: Wed, 21 Feb 1996 12:16:37 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id MAA08196 for X-agentx-local; Wed, 21 Feb 1996 12:16:36 -0800 (PST) Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id MAA08177 for ; Wed, 21 Feb 1996 12:16:34 -0800 (PST) Received: from acec.com by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via SMTP; id AA07406 for ; Wed, 21 Feb 96 14:29:21 -0500 Received: from natale by nips.acec.com (5.65/3.2.083191-American Computer and Electronics Corp. ) id AA29271; Wed, 21 Feb 1996 14:28:02 -0500 Date: Wed, 21 Feb 1996 14:30:13 EST From: Bob Natale Subject: Re: Index Sharing via registration To: Mike Daniele Cc: greene@nexen.com, agentx@fv.com Message-Id: Priority: Normal Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII > From: Mike Daniele > Date: Wed, 21 Feb 96 09:28:55 -0500 Hi Mike, Maria, Everyone, [Speaking as wg chair...] Well, I'm back from vacation, getting caught up on all the new assignments I've was given while away :-(, and hopefully ready to get back to work on the agentx effort. For one thing, Maria's offer to give a presentation on this topic at the LA IETF agentx meeting(s) is hereby accepted... Thanks, Maria!...we'll work up and agree on an overall agenda during the coming week. [Speaking as a technical contributor...] <...Mike replying to some of Maria's comments...> > So when your component agents determine new interfaces exist, they > manipulate the ifMgrxxx variables to allocate new values of ifIndex > for themselves. That's the way I read it. > What if instead, they performed agentx registration of new rows > in the ifTable? This 'special' registration of rows in shared > tables would have to provide the same capability you described > (grant to the component agent an index or block of indexes). I like that. > If (un)registration were completely dynamic, it seems like > your requirements would be met. (Or am I missing something?) Registration can be "selectively dynamic" (i.e., only when a table is actually being shared by multiple component agents); and it is possible that unregistration can even be "passively dynamic" (i.e., simply detected by the system agent during the normal course of exchanges with component agents) and not entail any special protocol operations. > Another possibly large win in doing this by agentx registration > is the subsequent system agent dispatching. Right. > In the environment you describe (please correct me if I'm wrong) > the system agent is unaware of individual index assignments. > It is only aware that multiple component agents have registered > subtrees that overlap on ifTable. That's the way I read it. > So when any SNMP request arrives that requires operation on > ifTable, ALL component agents must be notified and respond. The > system agent then selects one of the responses. I think that's the implication...I consider it a major negative... I'd like to avoid anything that *depends* upon polling component agents to determine which of them implements/controls a given object/instance at a given point in time. > What I'm suggesting is that if shared table index assignment > could be done via agentx registrations, the system agent COULD > correctly dispatch to only a single component agent. Yes. I personally consider this to be a technical requirement for agentx. > It seems to me this would be a large win in the efficiency > (and perhaps data integrity) of agentx. Especially when > servicing say, GetBulk. Right. > Of course, it might be more trouble than it's worth... Nope. The immediate benefits in run-time efficiency and design "quality" are, IMHO, worth a lot more. Furthermore, once this approach is approach is adopted in general, many derivative/associated benefits become possible. > Thoughts welcome. I still think the "index mapping" algorithm I have suggested in earlier posts is the right way to go: - Mass (one-time) registration of all supported objects via components agent's MIB file at "open" time. (Note that this gives the system agent access to the full syntax/semantics of the index object(s).) - System agent detects shared tables via subsequent registrations for same table by other component agents. - As long as only one component agent has so registered a table, nothing special has to happen (i.e., the system agent knows to pass requests for all instances in the table to that one component agent). - When a second registration for a (now) shared table occurs, the system agent: - notifies both component agents that row-instance registration for this table is in effect; and - does a GetNext scan of the table in the first component agent to identify all existing row-instances; and - initializes a table of row-instance values used by each component agent and a corresponding assigned index value for presentation to the external management applications. - When any subsequent registration for the shared table occurs, the system agent merely notifies the registering component agent that row-instance registration is in effect for that table. - When a management request arrives for an object in a shared table, the system agent maps the assigned index value (used by the management application) back to the original index value (used by the component agent) and forwards the mapped request to the appropriate component agent. Other than knowing that they have to register their row- instances for shared tables, component agents are not otherwise affected by this algorithm. Cordially, BobN ------- WinSNMP DLL, SDK, and Applets for Win16 and Win32 ------ Bob Natale | ACE*COMM | 301-258-9850 [v] Dir, Net Mgmt Prod | 209 Perry Pkwy | 301-921-0434 [f] natale@acec.com | Gaithersburg MD 20877 | http://www.acec.com ------- NetPlus (r) "FCAPS" Telemanagement Applications --------   Delivery-Date: Thu, 22 Feb 1996 00:26:11 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.3/8.7.3) id AAA27346 for X-agentx-local; Thu, 22 Feb 1996 00:26:11 -0800 (PST) Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.1.17]) by zloty.fv.com (8.7.3/8.7.3) with SMTP id AAA27339 for ; Thu, 22 Feb 1996 00:26:08 -0800 (PST) Received: from speedy.frcl.bull.fr (rap.frcl.bull.fr) by clbull.frcl.bull.fr; Thu, 22 Feb 1996 09:24:29 +0100 (MET) Received: by speedy.frcl.bull.fr (AIX 3.2/UCB 5.64/4.03) id AA22597; Thu, 22 Feb 1996 09:26:56 +0100 From: L.Frerebeau@frcl.bull.fr (Laurent FREREBEAU) Message-Id: <9602220826.AA22597@speedy.frcl.bull.fr> To: agentx@fv.com Subject: subscribe Date: Thu, 22 Feb 96 09:26:56 +0100   Delivery-Date: Fri, 23 Feb 1996 08:44:00 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id IAA00231 for X-agentx-local; Fri, 23 Feb 1996 08:43:55 -0800 (PST) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id IAA00196 for ; Fri, 23 Feb 1996 08:43:47 -0800 (PST) Received: from flume.zk3.dec.com by mail11.digital.com (5.65v3.2/1.0/WV) id AA24848; Fri, 23 Feb 1996 11:25:57 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA13801; Fri, 23 Feb 1996 11:25:53 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA12217; Fri, 23 Feb 1996 11:26:38 -0500 Message-Id: <9602231626.AA12217@bernie.zk3.dec.com> To: Bob Natale Cc: agentx@fv.com Subject: Re: Index Sharing via registration In-Reply-To: Your message of "Wed, 21 Feb 96 14:30:13 EST." Date: Fri, 23 Feb 96 11:26:37 -0500 From: Mike Daniele X-Mts: smtp Hi Bob, (Maria, this message sort of answers your questions to me, and also makes some of the same arguments about Bob's index mapping that you've already made. -mike) >I think that's the implication...I consider it a major negative... >I'd like to avoid anything that *depends* upon polling component >agents to determine which of them implements/controls a given >object/instance at a given point in time. >> What I'm suggesting is that if shared table index assignment >> could be done via agentx registrations, the system agent COULD >> correctly dispatch to only a single component agent. >Yes. I personally consider this to be a technical requirement >for agentx. I think this is do-able (system agent knowledge of instances implemented by component agents) for simple tables. A simple table is one that o is indexed by an arbirtary integer o does not imply or require the existance of, logically related objects in other tables For instance, the registration request could be something like REGISTER[ subtree = fooEntry num_rows = nr readOnly = T/F row_create = T/F ] and the response RESPONSE[ subtree = fooEntry start_index = si ] by which the component agent asks for nr rows of a conceptual table whose entries are named fooEntry (passed as an oid), and the system agent assigns nr rows starting w/ index si. (The component agent could also indicate general SetRequest related information as shown. Are Sets allowed, and if so, does this component agent wish to participate in row creation? [which as Jeff and Aleskey pointed out, would still need to 'poll' all component agents].) >I still think the "index mapping" algorithm I have suggested >in earlier posts is the right way to go: > - Mass (one-time) registration of all supported > objects via components agent's MIB file at > "open" time. (Note that this gives the system > agent access to the full syntax/semantics of > the index object(s).) I've tried not to discuss details at the protocol level, and concentrate on general mechanics of registration and dispatching. But... I think all agentx registration has to be dynamic, especially for shared tables. Also, where did the componenet agent indicate how many rows of each table in the MIB it has? > - When a management request arrives for an > object in a shared table, the system agent > maps the assigned index value (used by the > management application) back to the original > index value (used by the component agent) > and forwards the mapped request to the > appropriate component agent. Bob, what do you see is the advantage to having the system agent maintain its own set of indexes, as opposed to simply telling the component agents which ones they have? I think there are several problems with that idea: 1) It's extra work and overhead for the system agent to substitute index values in its agentx requests and responses 2) Suppose the component agent needs to register some other subtree based on the value of a row instance in a shared table? (a NetToMedia entry, for instance) 3) Suppose the component agent uses a row instance value as data for some other object (hrNetworkIfIndex, for example) 4) Suppose 2 cooperating component agents share data in a private manner, and happen to share values of row instances in a shared table? 5) How will row creation work? Imagine that the management application sees indexes 1,2, and 3 exist so tries to create row 4. But the componentt agents each think row 4 exists, so all fail the request. In short, it just seems to me we'd be aking for a world of complication in order to save 2 bytes in the registration response. IfTable: Of course all this is moot if we can't handle ifTable and all its relatives. I suppose it's feasible for a componenet agent that registers a row R in ifTable to also register ipNetToMediaEntry.R (if applicable). But what about the others? I suppose agentx could special case registration of interfaces, so that a single registration for index R means that component agent will be dispatched to for both ifTables.R ifXTable.R ifTestTable.R ifRcvAddress.R ifStackTable.R?? and the system agent knows to respond to ifNumber. Or componenet agents could register each row of each related table explicitly... Regards, Mike   Delivery-Date: Mon, 26 Feb 1996 15:04:47 -0800 Return-Path: Received: (from daemon@localhost) by zloty.fv.com (8.7.4/8.7.3) id PAA15915 for X-agentx-local; Mon, 26 Feb 1996 15:04:46 -0800 (PST) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by zloty.fv.com (8.7.4/8.7.3) with SMTP id PAA15888 for ; Mon, 26 Feb 1996 15:04:43 -0800 (PST) Received: from flume.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA30482; Mon, 26 Feb 1996 17:54:25 -0500 Received: from bernie.zk3.dec.com by flume.zk3.dec.com; (5.65v3.2/1.1.8.2/16Jan95-0946AM) id AA26020; Mon, 26 Feb 1996 17:54:14 -0500 Received: from localhost by bernie.zk3.dec.com; (5.65v3.2/1.1.8.2/20Nov95-1250PM) id AA06605; Mon, 26 Feb 1996 17:55:01 -0500 Message-Id: <9602262255.AA06605@bernie.zk3.dec.com> To: agentx@fv.com Cc: daniele@zk3.dec.com Subject: Registration & Dispatching: A proposal Date: Mon, 26 Feb 96 17:55:01 -0500 From: Mike Daniele X-Mts: smtp Hi, This is an attempt to define the behavior of a distributed agent in which the system agent maintains knowledge of which component agents instantiate which rows of shared tables. This is in keeping with the overall design goal of dispatching to a single component agent per requested variable (as opposed to polling all component agents when there are any overlapping registrations). It's certainly not intended to specify a complete protocol, only those pieces that are needed to discuss registration and dispatching algorithms. (And plenty is missing still, see section 6 :-) I've borrowed ideas from Maria, Jeff, Aleksey, Randy, and (I think :-) Bob. The general registration mechanism, splitting overlaps, and occlusion, are how Dave Keeney & I built eSNMP. Thanks to Dave for initial review. Sorry for the length, but I think we're gonna end up with something at least this big regardless of how agentx works. Looking forward to meeting some of you next week. Regards, Mike Proposal for Agentx Registration and Dispatching Policy ------------------------------------------------------- 1 Definition of Terms: Registration is the act of a component agent informing the system agent that the component agent will provide management of a MIB subtree. A subtree is indicated by a single oid. The system agent has no innate understanding of what this subtree is wrt any MIB specifi- cation. The subtree may actually be an entire MIB (e.g., 'host'), a full instance (e.g., hrDeviceDescr.42), or may not even be a subtree named in any MIB specification. An oid range is the range of oids implied by a subtree. For in- stance, the subtree 1.2.3 carries an implied range of 1.2.3 up to but not including 1.2.4 A duplicate registration is an attempt by one component agent to register a subtree that exactly matches a subtree already re- gistered by another component agent. An overlapping registration is an attempt by one component agent to register a subtree that is contained within, or contains, a subtree already registered by another component agent. Dispatching is the communication (via the agentx protocol) of a management request from the system agent to one or more component agents. Dispatching is performed according to the system agent's current 'view' of registered subtrees, and an explicitly stated algorithm. Table sharing is the instantation in different component agents of different rows of the same conceptual table. Occlusion is the logical 'covering' of an oid range. An active oid range is one that is being dispatched to. 2 Registration Registration is dynamic. A component agent may register or unre- gister a subtree at any time during its lifetime (that is, at any time that a logical connection exists between the component agent and the system agent). 2.1 Registration Types There are 3 types of registration, 'general', 'shared-table', and 'augments'. A 'general' registration carries the following information: g.subtree - The oid to register. May be any oid value. g.priority - An optional, arbitrary integer. A 'shared-table' registration carries the following information: s.subtree - The oid to register. It must be the name of the object that defines the entry of the shared table. That is, it is the object whose syntax is a SEQUENCE containing the columnar objects of the shared table (for instance, ifEntry). s.num_rows - The number of rows of this shared table the component agent wishes to register and subse- quently manage. s.read_only - An indication of whether or not this component agent can perform SetRequest operations on ob- jects in its registered rows (not necessarily the same as possible MIB-specified syntax). s.row_create - An indication of whether or not this component agent can perform SetRequests that would cause the creation of a row in this table not currently registered by any component agent. A 'augments' registration carries the following information: a.subtree - The oid to register. It must be the name of the object that defines the entry of the shared table. That is, it is the object whose syntax is a SEQUENCE containing the columnar objects of the shared table (for instance, ifXEntry). In addition, the definition of this object con- tains an AUGMENTS clause. a.augments - The oid of the object augmented by the first subtree. a.read_only - An indication of whether or not this component agent can perform SetRequest operations on ob- jects in its registered rows (not necessarily the same as possible MIB-specified syntax). a.index_list - An optional list of (row instance) index values. The purpose of this registration type is to provide the semantics of AUGMENTS. New indexes for these tables are not allocated. Existing indexes of other (augmented) tables are reassigned. It also provides a convenient mechanism for a component agent to aquire all of its augmenting rows in a single operation. 2.2 Overlaps and OID Ranges The system agent maintains a logical view of registered subtrees and their 'owner' component agents. Both duplicate and overlapping registrations are permitted. The system agent handles overlapping registration by splitting affected subtrees into smaller ranges that are either exact du- plicates, or no longer overlapping. For instance, suppose component agent A registers ip (1.3.6.1.2.1.4) and subsequently component agent B registers ip- NetToMediaTable (1.3.6.1.2.1.4.22). The system agent splits the registry into 3 oid ranges: (1.3.6.1.2.1.4 -> 1.3.6.1.2.1.4.22) ------> A (1.3.6.1.2.1.4.22 -> 1.3.6.1.2.1.4.23) ------> A & B (1.3.6.1.2.1.4.23 -> 1.3.6.1.2.1.5) ------> A Here the symbol '->' means 'up to but not including'. If component agent C now registers mib-2 (1.3.6.1.2.1) this is split into the oid ranges: (1.3.6.1.2.1 -> 1.3.6.1.2.1.4) (1.3.6.1.2.1.4 -> 1.3.6.1.2.1.4.22) (1.3.6.1.2.1.4.22 -> 1.3.6.1.2.1.4.23) (1.3.6.1.2.1.4.23 -> 1.3.6.1.2.1.5) (1.3.6.1.2.5 -> 1.3.6.1.2.2) And each of these in turn is registered, resulting in (1.3.6.1.2.1 -> 1.3.6.1.2.1.4) ------> C (1.3.6.1.2.1.4 -> 1.3.6.1.2.1.4.22) ------> A & C (1.3.6.1.2.1.4.22 -> 1.3.6.1.2.1.4.23) ------> A & B & C (1.3.6.1.2.1.4.23 -> 1.3.6.1.2.1.5) ------> A & C (1.3.6.1.2.5 -> 1.3.6.1.2.2) ------> C 2.3 'General' Registrations: All subtrees registered via 'general' registration are accepted by the system agent. That is, no policy is enforced that would limit which subtrees may be registered, or at which priority they may be registered (within architected bounds). A component agent may register 'iso'. g.subtree is processed according to section 2.2. All oid ranges generated by this processing are marked as active unless an ex- isting oid range exists in the registry with priority more signi- ficant that g.priority. (Registrations occlude less recent ones of equal or lesser prior- ity.) Note also that since registration is completely dynamic, a later registration may occlude a currently active registration. 2.4 'Shared Table' Registration Shared table registrations are intended to be duplicates of other shared table registrations, so that dispatching may be done ac- cording to the value of assigned indexes. Other than this, if s.subtree would contain, or would be con- tained in, a current shared table registration, the registration fails. (No shared tables within shared tables.) s.subtree may overlap (containing) subtrees that have already been registered via general registration, causing the containing subtree to be split as described above. The system agent manages indexes for each subtree (s.subtree) re- gistered in this manner. s.num_rows contiguous index values are alloted to the registering component agent. These values are guaranteed to be unique among all indexes allocated for s.subtree. (Don't re-use indexes when unregistered.) The starting index of the contiguous block allocated to the com- ponent agent is returned in the registration response. All allocated indexes for s.subtree indicate active rows. NOTE that the system agent represents a conceptual row by a sin- gle integer. The s.subtree table may be indexed by oids of length greater than 1 (see the section on dispatching). 2.5 'Augments' Registration If a.augments is not a current shared table registration, the re- quest fails. a.subtree is processed as in 2.4 If a.index_list is not provided: if this component agent has already registered a.augments via shared table registration, a.index_list is construct- ed which contains all indexes allocated to this component agent for a.augments. if this component agent has NOT already registered a.augments via shared table registration, the request is failed. If any of the indexes in a.index_list has already been allocated for a.subtree, the request is failed. Otherwise all indexes in a.index_list are allocated to the com- ponent agent for a.subtree, and the request succeeds. All allocated indexes for a.subtree indicate active rows. 3 Dispatching This section describes the algorithm used by the system agent for its INITIAL dispatching. (When servicing GetNext and GetBulk re- quests the system agent may have to dispatch to several different registered subtrees before one returns success.) The output of the initial dispatching algorithm is to associate a single component agent with each requested variable. * * Only this component agent is dispatched to in order to perform * the management operation requested. * * (Row creation being the sole exception.) * When the system agent receives an SNMP request, each VarBind in the request is processed in turn: a) Search the list of active subtrees and find the lexicographi- cally first candidate. If none exists ERROR_RESPONSE. If this subtree is NOT a shared or augmented table b) The component agent who registered the subtree is the asso- ciated component agent for this variable. If this subtree IS a shared or augmented table c) determine which conceptual row of the table contains the requested variable This is done assuming a component agent that was allocated index i of subtree s implements variables named s.*.i [.*] ... That is, the component agent implements all columns of the row. The instance portion of the oids for variables in this table may be of length greater than 1. If so, the first arc of the instance portion is compared to the allocated value i for lexicographical comparisons. If a candidate row exists c1) for Get, GetNext, or GetBulk, the component agent to whom was allocated this row is the associated component agent for this variable. for Set, if the component agent to whom was allocated this row specified read_only, ERROR_RESPONSE. Otherwise the component agent is the associated com- ponent agent for this variable. If no conceptual rows could contain the requested variable: c2) for Get, ERROR_RESPONSE. for GetNext or Get- Bulk, continue the search in a) for Set requests, c3) if this subtree augments another, ERROR_RESPONSE. Otherwise all component agents who registered this shared table and indicated (via s.row_create) that they participate in row creation are multiply asso- ciated component agents for this variable. If none exist, ERROR_RESPONSE. Now all VarBinds are dispatched (via agentx) to their associated component agents. For the case of multiply associated component agents in row crea- tion operations, the VarBind is dispatched to each component agent in an implementation-specific manner. The system agent identifies a single associated component agent in an implementa- tion -specific manner, or generates ERROR_RESPONSE, based on their responses. If this single associated component agent does in fact success- fully create a row, the system agent implicitly allocates the new row number to that component agent. 4 ifTable Given the central nature of ifTable and its associated tables, this section describes a technique for registering them, using the general purpose mechanisms described above. In this example a component agent implements management of 3 interfaces (which are allocated indexes of 7,8, and 9). Interface 8 carries IP, interface 9 implements the ifTestTable. Interface 8 runs over interface 9, nothing is 'over' 8. a) REGISTER [ shared table, s.subtree = ifEntry s.num_rows = 3 ] RESPONSE: starting index = 7 (component agent has rows 7,8,9) b) REGISTER [ augments, a.subtree = ifXEntry a.augments = ifEntry a.index_list = NULL ] RESPONSE: ok (component agent has same rows in ifXEntry) c) REGISTER [ augments, a.subtree = ifTestEntry a.augments = ifEntry a.index_list = 9 ] RESPONSE: ok (component agent now has row 9 only of ifTestEntry) d) REGISTER [ augments, a.subtree = ifRecvAddressEntry a.augments = ifEntry a.index_list = NULL ] RESPONSE: ok (component agent instantiates rows 7.x, 8.x, and 9.x in ifRecvAd- dressTable) e) REGISTER [ augments, a.subtree = ipNetToMediaEntry, a.augments = ifEntry a.index_list = 8 ] RESPONSE: ok (component agent instantiates rows 8.x in ifNetToMediaTable) f) REGISTER [ augments, a.subtree = ifStackEntry, a.augments = ifEntry a.index_list = 8, 9 ] RESPONSE: ok (component agent instantiates rows 8.* and 9.* in ifStackTable) (Assumes missionary convention) 5 Agentx MIB Should have a component agent table similar to Bert's sub-agent table, except it does not contain a subtree table. A separate subtree table is instrumented to make visible the sys- tem agent's subtree registry, including active and occluded ranges when there is overlap. AgentxRegTable OBJECT-TYPE SYNTAX SEQUENCE OF AgentxRegEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table describing the agentx system agent's current registry. This is maintained in an order that makes it convenient for management applications to view the registry and so understand the agentx dispatching characteristics for this system." ::= { agentx n } AgentxRegEntry OBJECT-TYPE SYNTAX AgentxRegEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the table represents a single registered subtree." INDEX { AgentxRegSubTree, AgentxRegActive, AgentxRegIndex } ::= { AgentxRegTable 1 } AgentxRegEntry ::= SEQUENCE { AgentxRegSubTree OBJECT IDENTIFIER, AgentxRegAugments OBJECT IDENTIFIER, AgentxRegType Integer, AgentxRegActive Integer, AgentxRegIndex Integer } AgentxRegSubTree OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the registered subtree." ::= { AgentxRegEntry 1 } AgentxRegType OBJECT-TYPE SYNTAX Integer { general (1), shared-table (2), augments (3) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of registration that was used to register this subtree." ::= { AgentxRegEntry 2 } AgentxRegActive OBJECT-TYPE SYNTAX TruthValue, MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of whether or not this registered subtree is active (being dispatched to). For entries that are of type shared-table (2) or augments (3), a value of true (1) should always be returned." ::= { AgentxRegEntry 3 } AgentxRegIndex OBJECT-TYPE SYNTAX Integer MAX-ACCESS read-only STATUS current DESCRIPTION "The value of an index that was allocated for this registered subtree. For entries of type general (1), a value of 0 should always be returned." ::= { AgentxRegEntry 4 } AgentxRegAugments OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The value of the registered subtree that is augmented by this registered subtree. For entries of type general (1) or shared-table(2), a value of 0.0 should be returned." ::= { AgentxRegEntry 5 } 6 Deficiencies and Omissions No explanation of unregistration and its effects. Probably need to permit component agent to request specific indexes in shared-table registration. How would a component agent maintain shared table indexes across a lost connection? (I think that's beyond agentx and is up to the component agent.) How will row-count type variables be handled for shared/augmented tables? (for instance, ifNumber) Probably need to add another field to these registration pdus containing the oid of a scalar that the system agent should implement and return the number of rows. I think ifStackTable needs work.