From mdavidson@a1results.net Mon Feb 1 21:58:47 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA06684 for ; Mon, 1 Feb 1999 21:58:46 -0500 (EST) From: mdavidson@a1results.net Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id UAA18766; Mon, 1 Feb 1999 20:55:24 -0600 (CST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id SAA03715 for ; Mon, 1 Feb 1999 18:48:31 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id UAA17638 for ; Mon, 1 Feb 1999 20:48:30 -0600 (CST) Received: by khlab.kyunghee.ac.kr id AB10212; Tue, 2 Feb 1999 11:47:59 +0900 Date: Tue, 2 Feb 1999 11:47:59 +0900 Message-Id: <199902020247.AB10212@khlab.kyunghee.ac.kr> To: Subject: Search Engine Registration adv I saw your listing on the internet. I work for a company that submits websites to search engines. We can submit your website to over 350 of the worlds best search engines and directories for a one time charge of only $39.95. If you would like to put your website in the fast lane and receive more traffic call me on our toll-free number listed below. All work is verified! Sincerely, Mike Davidson (800) 484-2621 X5568 From Lauren_Heintz@ec01-hou.bmc.com Wed Feb 3 15:19:25 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA07164 for ; Wed, 3 Feb 1999 15:19:20 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA09796; Wed, 3 Feb 1999 14:15:32 -0600 (CST) Received: from ec01-hou.bmc.com (ec01-hou.bmc.com [172.17.0.150]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA13413 for ; Wed, 3 Feb 1999 10:24:31 -0800 (PST) Received: by ec01-hou.bmc.com with Internet Mail Service (5.5.2232.9) id ; Wed, 3 Feb 1999 12:24:30 -0600 Message-ID: From: "Heintz, Lauren" To: "'disman@nexen.com'" , "'agentx@peer.com'" Subject: AgentX Log Table Date: Wed, 3 Feb 1999 12:24:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" I am x-posting this to disman and AgentX. As co-editor of the AgentX MIB draft, one of the issues I am dealing with is to come up with a specific recommendation to instrument appropriate AgentX errors or events. Ideally, I think a generic (non-AgentX) log mechanism would solve the problem, but I know of no such mechanisms except perhaps the disman LOG MIB. The disman LOG MIB allows applications to define notifications that map to interesting events and which can then be logged once the notification is transmitted, but this seems too complex for the indended purpose (simple debugging of AgentX situations). Instead, what I would like to propose is that in addition to the existing LOG MIB, the disman WG create a more simplified remote logging mechanism, implemented as a table and a single scalar variable, something like: logSize - scalar could be set by a manager to control the maximum number of log entries. logTable would have the following two columns: logIndex (incrementing int type) logEntry (SnmpAdminString, application generated LOG entry) logEntry would have max len of, say, 255. Applications could then generate human-readable log entries for any event it chooses. Richness of reporting could be implementation-specific or, in some cases, specified in RFCs. The AgentX MIB RFC, for example, could specify which kinds of AgentX events SHOULD be reportable and could even recommend the format of the each logEntry so that it could be parsed by manager applications. AgentX MIB could even provide one or two additional variables that enabel/disable AgentX log reporting or set a log severity level (kinds of AgentX events to be reported). Manager-side parsing of logEntry is not necesarrily intended, although not precluded on a case-by-case basis. Rather, the disman log MIB should instead be considered for most events that REQUIRE parsing. Lastly, this simpler logging mechanism is intended for applications that require an easy-to-implement-and-use remote debug capability, and it would preclude the need for AgentX to define its own specialized table. Thoughts? Agreements? Objections? Suggestions? Thanks, Lauren ------------------------------------------------------------------------- Lauren Heintz BMC Software, Inc. (Formerly PEER Networks) Voice: +1 408 616-3169 Silicon Valley Division Fax: +1 408 616-3339 965 Stewart Drive Email: Lauren_Heintz@bmc.com Sunnyvale, California 94086 USA ------------------------------------------------------------------------- From rpresuhn@dorothy.bmc.com Wed Feb 3 15:31:14 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA07630 for ; Wed, 3 Feb 1999 15:31:13 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA11920; Wed, 3 Feb 1999 14:26:54 -0600 (CST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA14748; Wed, 3 Feb 1999 11:37:54 -0800 (PST) Date: Wed, 3 Feb 1999 11:37:54 -0800 (PST) From: Randy Presuhn Message-Id: <199902031937.LAA14748@dorothy.bmc.com> To: agentx@dorothy.bmc.com, disman@nexen.com Subject: Applmib logging capability revisited? Cc: applmib@ietf.verio.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - I'm forwarding this to the application mib list, since this was a past topic here. Begging Bob Natale's, Jon Saperia's, and Cheryl Krupczak's pardon, can we for the time being limit the follow-ups to the list? (See http://www.ietf.org/html.charters/disman-charter.html for subscription instructions.) PLEASE note that we're on the verge of working group last call for the disman log MIB work, and as WG chair I'm reluctant to entertain proposals that would further delay its completion. However, I think the issue Lauren raises does merit prompt discussion and decision. ----------------------------------------------------------------------- Randy Presuhn Email: rpresuhn@peer.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy, I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ----------------------------------------------------------------------- > From maria@xedia.com Wed Feb 3 10:30:03 PST 1999 > From: "Heintz, Lauren" > To: "'disman@nexen.com'" , > "'agentx@peer.com'" > > Subject: AgentX Log Table > Date: Wed, 3 Feb 1999 12:24:35 -0600 > > I am x-posting this to disman and AgentX. > > As co-editor of the AgentX MIB draft, one of the > issues I am dealing with is to come up with a specific > recommendation to instrument appropriate AgentX errors or > events. > > Ideally, I think a generic (non-AgentX) log mechanism > would solve the problem, but I know of no such mechanisms > except perhaps the disman LOG MIB. > > The disman LOG MIB allows applications to define notifications > that map to interesting events and which can then be logged once > the notification is transmitted, but this seems too complex for > the indended purpose (simple debugging of AgentX situations). > > Instead, what I would like to propose is that in addition to > the existing LOG MIB, the disman WG create a more simplified > remote logging mechanism, implemented as a table and a single scalar > variable, something like: > > logSize - scalar could be set by a manager to control the > maximum number of log entries. > > logTable would have the following two columns: > > logIndex (incrementing int type) > logEntry (SnmpAdminString, application generated LOG entry) > > logEntry would have max len of, say, 255. Applications could then > generate human-readable log entries for any event it chooses. Richness > of reporting could be implementation-specific or, in some cases, specified > in RFCs. The AgentX MIB RFC, for example, could specify which kinds of > AgentX events SHOULD be reportable and could even recommend the format of > the > each logEntry so that it could be parsed by manager applications. AgentX > MIB > could even provide one or two additional variables that enabel/disable > AgentX log > reporting or set a log severity level (kinds of AgentX events to be > reported). > > Manager-side parsing of logEntry is not necesarrily intended, although > not precluded on a case-by-case basis. Rather, the disman log MIB > should instead be considered for most events that REQUIRE parsing. > > Lastly, this simpler logging mechanism is intended for applications > that require an easy-to-implement-and-use remote debug capability, and > it would preclude the need for AgentX to define its own specialized > table. > > Thoughts? Agreements? Objections? Suggestions? > > Thanks, > Lauren > > ------------------------------------------------------------------------- > Lauren Heintz BMC Software, Inc. (Formerly PEER Networks) > Voice: +1 408 616-3169 Silicon Valley Division > Fax: +1 408 616-3339 965 Stewart Drive > Email: Lauren_Heintz@bmc.com Sunnyvale, California 94086 USA > ------------------------------------------------------------------------- > From daniele@zk3.dec.com Wed Feb 3 16:24:30 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA08670 for ; Wed, 3 Feb 1999 16:24:26 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA21509; Wed, 3 Feb 1999 15:21:04 -0600 (CST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA15703 for ; Wed, 3 Feb 1999 12:30:44 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id OAA12626; Wed, 3 Feb 1999 14:30:41 -0600 (CST) Received: from iota.zk3.dec.com (iota.zk3.dec.com [16.140.32.65]) by mail13.digital.com (8.9.1a/8.9.1/WV2.0d) with ESMTP id PAA21677; Wed, 3 Feb 1999 15:30:33 -0500 (EST) Received: from zk3.dec.com by iota.zk3.dec.com (8.8.8/1.1.20.3/24Apr98-0811AM) id PAA0000028450; Wed, 3 Feb 1999 15:30:32 -0500 (EST) Sender: daniele@zk3.dec.com Message-ID: <36B8B108.3F0EE8AD@zk3.dec.com> Date: Wed, 03 Feb 1999 15:26:48 -0500 From: Mike Daniele Organization: Compaq 64-bit UNIX networking X-Mailer: Mozilla 4.5 [en] (X11; I; OSF1 X5.0 alpha) X-Accept-Language: en MIME-Version: 1.0 To: "Heintz, Lauren" CC: "'disman@nexen.com'" , "'agentx@peer.com'" Subject: Re: AgentX Log Table References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Heintz, Lauren" wrote: > I am x-posting this to disman and AgentX. > > As co-editor of the AgentX MIB draft, one of the > issues I am dealing with is to come up with a specific > recommendation to instrument appropriate AgentX errors or > events. > > Ideally, I think a generic (non-AgentX) log mechanism > would solve the problem, but I know of no such mechanisms > except perhaps the disman LOG MIB. Hi Lauren, Maybe I don't understand the requirement. But what is wrong with just defining appropriate counters/notifications in the AgentX MIB? Mike From bstewart@cisco.com Wed Feb 3 16:59:34 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA09415 for ; Wed, 3 Feb 1999 16:59:32 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA27261; Wed, 3 Feb 1999 15:54:38 -0600 (CST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA15980 for ; Wed, 3 Feb 1999 13:06:16 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id PAA18710; Wed, 3 Feb 1999 15:06:14 -0600 (CST) Received: from tootsie.cisco.com (tootsie.cisco.com [171.69.128.44]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id NAA02859; Wed, 3 Feb 1999 13:05:58 -0800 (PST) Message-Id: <4.1.19990203155050.00b735d0@zipper.cisco.com> X-Sender: bstewart@zipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 03 Feb 1999 16:05:45 -0500 To: "Heintz, Lauren" , "'disman@nexen.com'" , "'agentx@peer.com'" From: Bob Stewart Subject: Re: AgentX Log Table In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 12:24 PM 2/3/99 -0600, Heintz, Lauren wrote: >Ideally, I think a generic (non-AgentX) log mechanism >would solve the problem, but I know of no such mechanisms >except perhaps the disman LOG MIB. The Notification Log MIB is intended to be a generic mechanism for logging notifications. (Sounds repetitive doesn't it?) >The disman LOG MIB allows applications to define notifications >that map to interesting events and which can then be logged once >the notification is transmitted, but this seems too complex for >the indended purpose (simple debugging of AgentX situations). The Notification Log MIB simply logs any standard SNMP notification. Independent of that anything can have its own MIB that defines its own notifications. >Instead, what I would like to propose is that in addition to >the existing LOG MIB, the disman WG create a more simplified >remote logging mechanism, implemented as a table and a single scalar >variable, something like: This is very different from the idea of the MIB. It's for logging SNMP notifications, not for general message logs. >Applications could then >generate human-readable log entries for any event it chooses. I have a major problem with this. I've recently been fighting off internal company attempts to define notifications designed around DisplayStrings. In the past we've gone out of our way to fight off DisplayStrings in MIBs in general. DisplayStrings are useful only for people to read. They are not the friend of interoperability or automation, both of which are primary SNMP goals. Undocumented strings of allegedly useful text are a scourge and an abomination when you're trying to sort out a problem. We should not implement general mechanisms that allow programmers the freedom to be so lazy. > and could even recommend the format of the >each logEntry so that it could be parsed by manager applications. Eeeeek. Picture Von Helsing holding off Dracula with cross, holy water, and garlic. A basic principle of SNMP design is that we put information in binary form that's easy for software, not in ASCII text that must then have a specified, locked-down format so you can parse it. >Lastly, this simpler logging mechanism is intended for applications >that require an easy-to-implement-and-use remote debug capability, and >it would preclude the need for AgentX to define its own specialized >table. If AgentX finds it acceptable to grand implementors a standard SNMP Notification that carries a text-based debugging comment, that's up to the AgentX designers. You might guess that I personally wouldn't be particularly supportive of such a notification. Given a standard SNMP notification, the Notification Log MIB would be perfectly willing to store it and supply a copy to whomever has access. At the last IETF I talked about the error reporting mechanism in the DisMan Event MIB. I used notifications and didn't include a history table. I explained that the idea was to provide debug information that you'd enable through generic notification control mechanisms only when you needed it. In most cases you'd have it sent where you wanted it and most of it would most likely arrive. If you wanted it more reliable, you could have an implementation of the Notification Log MIB to store it locally for perusal at your leisure. I think this is a solid mechanism, using existing or nearly completed components in a way that doesn't seriously violate SNMP conventions. Bob From Lauren_Heintz@ec01-hou.bmc.com Wed Feb 3 18:02:15 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA10844 for ; Wed, 3 Feb 1999 18:02:10 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA09027; Wed, 3 Feb 1999 16:58:49 -0600 (CST) Received: from ec01-hou.bmc.com (ec01-hou.bmc.com [172.17.0.150]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA16701 for ; Wed, 3 Feb 1999 14:07:29 -0800 (PST) Received: by ec01-hou.bmc.com with Internet Mail Service (5.5.2232.9) id ; Wed, 3 Feb 1999 16:07:28 -0600 Message-ID: From: "Heintz, Lauren" To: "'Mike Daniele'" Cc: "'disman@nexen.com'" , "'agentx@peer.com'" Subject: RE: AgentX Log Table Date: Wed, 3 Feb 1999 16:07:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Hi Mike, > -----Original Message----- > From: Mike Daniele [mailto:daniele@zk3.dec.com] > Maybe I don't understand the requirement. I believe the general requirement is to define some mechanism for AgentX to allow debugging of mis-behaving AgentX implementations (probably at implementation or installation time). The AgentX list consensus (to my recollection) seemed to indicate (with one or two exceptions) that most AgentX implementors did not feel this was important, but I believe more discussion is warranted. So the purpose of my proposal is to, a) begin the process of reaching final consensus on what statistics/errors are needed and, b) to suggest a starting point. > But what is wrong > with just defining appropriate counters/notifications in the > AgentX MIB? Regarding notifications: Seems overkill to me to define notifications (even one) in the AgentX MIB just to provide a debugging capability that most people (judging by the opinions expressed on the AgentX list) don't even need/want. Then to have to implement and configure the disman LOG MIB and the notification tables to even be able to log AgentX errors/statistics makes it even more complex and way too undesirable (IMHO). Regarding counters: If counters are designed to effectively augment given entries in the connection, session or registration tables, then those same counters and their values will dissappear the moment the associated connection, session or registration is/are closed. As you recall, AgentX master agents are supposed to close misbehaving connections, thus, it doesn't seem very useful to tightly couple these counters with the current tables. Something more persistent is needed. To instead have a group of general-purpose scalar counters would not likely help anyone figure out exactly which subagent is misbehaving. This is the reason for the log proposal. Each entry would indicate all the info needed to identify the specific nature of the problem and which subagent caused it. I personally suggest we remove the requirement to have the AgentX MIB contain error/statistics counters of any kind and to instead rely on a simple (to use and implement) and generic log mechanism (such as in my proposal) to report errors/statistics. Tks, Lauren From Lauren_Heintz@ec01-hou.bmc.com Wed Feb 3 18:56:01 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA11933 for ; Wed, 3 Feb 1999 18:56:00 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id RAA17632; Wed, 3 Feb 1999 17:52:20 -0600 (CST) Received: from ec01-hou.bmc.com (ec01-hou.bmc.com [172.17.0.150]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA16971 for ; Wed, 3 Feb 1999 15:02:57 -0800 (PST) Received: by ec01-hou.bmc.com with Internet Mail Service (5.5.2232.9) id ; Wed, 3 Feb 1999 17:02:56 -0600 Message-ID: From: "Heintz, Lauren" To: "'Bob Stewart'" Cc: "'disman@nexen.com'" , "'agentx@peer.com'" Subject: RE: AgentX Log Table Date: Wed, 3 Feb 1999 17:03:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Hi Bob, > -----Original Message----- > From: Bob Stewart [mailto:bstewart@cisco.com] > I have a major problem with this. I've recently been > fighting off internal > company attempts to define notifications designed around > DisplayStrings. > In the past we've gone out of our way to fight off > DisplayStrings in MIBs > in general. DisplayStrings are useful only for people to > read. They are > not the friend of interoperability or automation, both of > which are primary > SNMP goals. The intention for my proposal for a simpler log mechanism (using human-readable strings) was for interoperability between a real person and a machine. In the case of AgentX error reporting, I think automation is overkill. > Undocumented strings of allegedly useful text are a scourge and an > abomination when you're trying to sort out a problem. We should not > implement general mechanisms that allow programmers the > freedom to be so lazy. My intention is really to make it easier for lazy debuggers to debug AgentX. Why should I have to configure several MIBs just to figure out which AgentX subagent is mis-behaving if there's an easier way? Easier implementation is just icing on the cake. > > and could even recommend the format of the > >each logEntry so that it could be parsed by manager applications. > > Eeeeek. Picture Von Helsing holding off Dracula with cross, > holy water, > and garlic. You must have me confused with someone else. I do like garlic, after all! :) > A basic principle of SNMP design is that we put information > in binary form > that's easy for software, not in ASCII text that must then have a > specified, locked-down format so you can parse it. It also seems to be an SNMP (stress the letter, 'S") design principle to make things more complex than they always have to be. Sometimes simpler can be better. Everything (stress the word "everything") shouldn't HAVE to be in binary, locked-down format. Too constricting. Instead, allow implementations to choose which style of logging they want to use (binary or readable) for a given purpose, and let customers decide which product is better suited for their purposes. BTW, I'm not suggesting we change or replace the current disman LOG MIB -- rather, just add a new tool to the disman toolbox. In any case, the issue I am trying to solve is whether or not the AgentX MIB must include an integral means of error logging, or whether it will rely on a more generic mechanism. Thanks, Lauren ------------------------------------------------------------------------- Lauren Heintz BMC Software, Inc. (Formerly PEER Networks) Voice: +1 408 616-3169 Silicon Valley Division Fax: +1 408 616-3339 965 Stewart Drive Email: Lauren_Heintz@bmc.com Sunnyvale, California 94086 USA ------------------------------------------------------------------------- From bnatale@acecomm.com Thu Feb 4 10:28:08 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA27323 for ; Thu, 4 Feb 1999 10:28:07 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id JAA29222; Thu, 4 Feb 1999 09:24:14 -0600 (CST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA21600 for ; Thu, 4 Feb 1999 06:36:34 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id IAA20116 for ; Thu, 4 Feb 1999 08:36:29 -0600 (CST) Received: from [192.152.208.5] (helo=acecomm.com) by relay3.smtp.psi.net with smtp (Exim 1.90 #1) id 108PtD-0004Bk-00; Thu, 4 Feb 1999 09:36:19 -0500 Received: from ppp12 by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA08573; Thu, 4 Feb 1999 09:39:18 -0500 Message-Id: <4.1.19990204093036.009b8a40@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 04 Feb 1999 09:34:10 -0500 To: Bob Stewart From: Bob Natale Subject: RE: AgentX Log Table Cc: disman@nexen.com, agentx@dorothy.bmc.com In-Reply-To: <4.1.19990204085844.0094e2e0@zipper.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 2/4/99:09:08 AM, Bob Stewart wrote: Hi BobS, <...> >Recall that there was originally considerable debate as to whether >AgentX was appropriate work for the SNMP community in the IETF at all. True...but this "debate" was certainly not due to any question of the importance and relevance of an agent extensibility protocol to SNMP! (As you well know, I'm sure.) > It's an API for software development. Dead wrong. >That's really stretching the coverage of SNMP. AgentX is one of the *core* aspects of SNMP evolution, as defined by the ADs. Are you thinking of something else entirely here, or what? Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From daniele@zk3.dec.com Thu Feb 4 10:28:31 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA27340 for ; Thu, 4 Feb 1999 10:28:29 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id JAA29181; Thu, 4 Feb 1999 09:24:07 -0600 (CST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA21632 for ; Thu, 4 Feb 1999 06:44:11 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id IAA21608 for ; Thu, 4 Feb 1999 08:44:04 -0600 (CST) Received: from iota.zk3.dec.com (iota.zk3.dec.com [16.140.32.65]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0d) with ESMTP id JAA15383; Thu, 4 Feb 1999 09:44:05 -0500 (EST) Received: from zk3.dec.com by iota.zk3.dec.com (8.8.8/1.1.20.3/24Apr98-0811AM) id JAA0000021782; Thu, 4 Feb 1999 09:43:53 -0500 (EST) Sender: daniele@zk3.dec.com Message-ID: <36B9B149.F1B8C03A@zk3.dec.com> Date: Thu, 04 Feb 1999 09:40:09 -0500 From: Mike Daniele Organization: Compaq 64-bit UNIX networking X-Mailer: Mozilla 4.5 [en] (X11; I; OSF1 X5.0 alpha) X-Accept-Language: en MIME-Version: 1.0 To: Bob Stewart CC: "'disman@nexen.com'" , "'agentx@peer.com'" Subject: Re: AgentX Log Table References: <4.1.19990204085844.0094e2e0@zipper.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob Stewart wrote: > At 05:03 PM 2/3/99 -0600, Heintz, Lauren wrote: > >The intention for my proposal for a simpler log mechanism > >(using human-readable strings) was for interoperability > >between a real person and a machine. In the case of AgentX > >error reporting, I think automation is overkill. > > If this is purely for debug messages for people to read it seems > inappropriate to standardized that in relationship to SNMP. The purpose of > SNMP is management via the network, not debugging code. SNMP wasn't > designed for the sort of high-volume, deeply-specific, human-targetted > information that goes with debugging. That's typically a function of the > operating system and debuggers for the particular environment. > > >My intention is really to make it easier for lazy debuggers to debug AgentX. > > That's not a good reason to open Pandora's box in SNMP. Such a tool > wouldn't be limited to appropriate uses. It would become another short cut > that people would use to avoid doing the real work but still keep the SNMP > stamp of approval. > I agree. It seems to me it's up to implementations to make analyzing their errors "easy", using whatever mechanisms are appropriate to the platform in question. > > >Why should I have to configure several MIBs just to figure out which AgentX > >subagent is mis-behaving if there's an easier way? Easier implementation is > >just icing on the cake. > > Recall that there was originally considerable debate as to whether AgentX > was appropriate work for the SNMP community in the IETF at all. It's an > API for software development. That's really stretching the coverage of SNMP. > Bob, I realize you're speaking in generalities in order to make a point, but of course the whole point of AgentX is that it's a protocol that can be implemented underneath existing or new sw development APIs. The bakeoff saw interoperability at the protocol level between 4 or 5 different APIs. > > >It also seems to be an SNMP (stress the letter, 'S") design principle to > >make things more complex than they always have to be. Sometimes simpler can > >be better. > > Gee, why didn't I think of that. Guess I just like things too complicated. > > >In any case, the issue I am trying to solve is whether or not the AgentX MIB > >must include an integral means of error logging, or whether it will rely on > >a more generic mechanism. > > And my question is whether solving that problem is appropriate for SNMP at all. > > Bob I don't think the AgentX MIB should define error logging at all. The MIB's registration table tells you essentially everything you need to know : which session is authoratative for each region. Just about anything else can be relegated to syslog (or whatever the admins for the platform are used to looking at.) At any rate, I think it would be helpful to write down everything you are concerned about that could "go wrong", post it to AgentX (only :-), and let's discuss it. I'm pretty sure that the last time we did this, the consensus was to leave things as described in the paragraph above ... Mike From bstewart@cisco.com Thu Feb 4 10:32:24 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA27514 for ; Thu, 4 Feb 1999 10:32:22 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id JAA29223; Thu, 4 Feb 1999 09:24:14 -0600 (CST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA21521 for ; Thu, 4 Feb 1999 06:12:53 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id IAA16053 for ; Thu, 4 Feb 1999 08:12:51 -0600 (CST) Received: from tootsie.cisco.com (tootsie.cisco.com [171.69.128.44]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id GAA08454; Thu, 4 Feb 1999 06:12:34 -0800 (PST) Message-Id: <4.1.19990204085844.0094e2e0@zipper.cisco.com> X-Sender: bstewart@zipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 04 Feb 1999 09:08:48 -0500 To: "'disman@nexen.com'" , "'agentx@peer.com'" From: Bob Stewart Subject: RE: AgentX Log Table In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 05:03 PM 2/3/99 -0600, Heintz, Lauren wrote: >The intention for my proposal for a simpler log mechanism >(using human-readable strings) was for interoperability >between a real person and a machine. In the case of AgentX >error reporting, I think automation is overkill. If this is purely for debug messages for people to read it seems inappropriate to standardized that in relationship to SNMP. The purpose of SNMP is management via the network, not debugging code. SNMP wasn't designed for the sort of high-volume, deeply-specific, human-targetted information that goes with debugging. That's typically a function of the operating system and debuggers for the particular environment. >My intention is really to make it easier for lazy debuggers to debug AgentX. That's not a good reason to open Pandora's box in SNMP. Such a tool wouldn't be limited to appropriate uses. It would become another short cut that people would use to avoid doing the real work but still keep the SNMP stamp of approval. >Why should I have to configure several MIBs just to figure out which AgentX >subagent is mis-behaving if there's an easier way? Easier implementation is >just icing on the cake. Recall that there was originally considerable debate as to whether AgentX was appropriate work for the SNMP community in the IETF at all. It's an API for software development. That's really stretching the coverage of SNMP. >It also seems to be an SNMP (stress the letter, 'S") design principle to >make things more complex than they always have to be. Sometimes simpler can >be better. Gee, why didn't I think of that. Guess I just like things too complicated. >In any case, the issue I am trying to solve is whether or not the AgentX MIB >must include an integral means of error logging, or whether it will rely on >a more generic mechanism. And my question is whether solving that problem is appropriate for SNMP at all. Bob From bstewart@cisco.com Thu Feb 4 11:54:12 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA00782 for ; Thu, 4 Feb 1999 11:54:11 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA17199; Thu, 4 Feb 1999 10:50:36 -0600 (CST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id HAA21902 for ; Thu, 4 Feb 1999 07:58:01 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id JAA06070 for ; Thu, 4 Feb 1999 09:57:59 -0600 (CST) Received: from tootsie.cisco.com (tootsie.cisco.com [171.69.128.44]) by zipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with SMTP id HAA13103; Thu, 4 Feb 1999 07:57:36 -0800 (PST) Message-Id: <4.1.19990204104558.00956e40@zipper.cisco.com> X-Sender: bstewart@zipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 04 Feb 1999 10:57:28 -0500 To: Bob Natale From: Bob Stewart Subject: RE: AgentX Log Table Cc: disman@nexen.com, agentx@dorothy.bmc.com In-Reply-To: <4.1.19990204093036.009b8a40@nips.acec.com> References: <4.1.19990204085844.0094e2e0@zipper.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" At 09:34 AM 2/4/99 -0500, Bob Natale wrote: >AgentX is one of the *core* aspects of SNMP evolution, as >defined by the ADs. > >Are you thinking of something else entirely here, or what? AgentX defines one way to implement agents, specifically those made up of multiple pieces from different sources. Since in some environments that's a major concern, it is a valuable standard. But we have to be careful about letting AgentX, or the implementation of any other SNMP-related gadgetry, intrude too far or too specially on the primary business of SNMP, which is managing the network and its components. The question is how far should SNMP go in taking over the world. Think of emacs. For some people emacs is the center of everything they do with their computer, from developing code to managing files to reading and writing email. I question whether SNMP and the IETF working groups related to it are appropriate as the place to define, for example, remote debugging aids, whether that's for code in general or an agent implementation. The problem is that "distributed management" can take on an extremely broad definition, so broad that it risks becoming all of distributed systems, one chunk at a time. A cheap, local (or even remote) logging mechanism for debugging purposes sounds like a handy gadget that might well be worthy of a standard. I don't believe it's SNMP's job to provide that in any way other than through existing or already-planned mechanisms. We're having enough trouble finishing work that is clearly our own. Bob From bnatale@acecomm.com Thu Feb 4 12:39:13 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA03820 for ; Thu, 4 Feb 1999 12:39:12 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA26350; Thu, 4 Feb 1999 11:35:33 -0600 (CST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA22232 for ; Thu, 4 Feb 1999 08:49:28 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id KAA16869 for ; Thu, 4 Feb 1999 10:49:26 -0600 (CST) Received: from [192.152.208.5] (helo=acecomm.com) by relay3.smtp.psi.net with smtp (Exim 1.90 #1) id 108Rxq-0004Ge-00; Thu, 4 Feb 1999 11:49:14 -0500 Received: from ppp12 by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA10474; Thu, 4 Feb 1999 11:52:11 -0500 Message-Id: <4.1.19990204114322.009a1c10@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 04 Feb 1999 11:44:06 -0500 To: Bob Stewart From: Bob Natale Subject: RE: AgentX Log Table Cc: disman@nexen.com, agentx@dorothy.bmc.com In-Reply-To: <4.1.19990204104558.00956e40@zipper.cisco.com> References: <4.1.19990204093036.009b8a40@nips.acec.com> <4.1.19990204085844.0094e2e0@zipper.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 2/4/99:10:57 AM, Bob Stewart wrote: Hi Bob, >AgentX defines one way to implement agents, specifically those made up of >multiple pieces from different sources. Since in some environments that's >a major concern, it is a valuable standard. > >But we have to be careful about letting AgentX, or the implementation of >any other SNMP-related gadgetry, intrude too far or too specially on the >primary business of SNMP, which is managing the network and its components. Yep. We're in violent agreement on both point. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From cwk@verio.net Thu Feb 4 12:55:42 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA04732 for ; Thu, 4 Feb 1999 12:55:37 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA29504; Thu, 4 Feb 1999 11:52:17 -0600 (CST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA22316 for ; Thu, 4 Feb 1999 09:07:07 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id LAA20555; Thu, 4 Feb 1999 11:07:05 -0600 (CST) Received: from nocgate.noc.verio.net (nocgate.noc.verio.net [205.238.61.245]) by mx0.verio.net (8.9.1a/8.9.1) with SMTP id LAA18641; Thu, 4 Feb 1999 11:05:33 -0600 (CST) Message-ID: <36B9D3DE.F0739FDF@verio.net> Received: from dhcp24.noc.verio.net by nocgate.noc.verio.net via smtpd (for mx0.verio.net [205.238.61.251]) with SMTP; 4 Feb 1999 15:53:55 UT Date: Thu, 04 Feb 1999 11:07:42 -0600 From: "Carl W. Kalbfleisch" Organization: Verio X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Heintz, Lauren" CC: "'Mike Daniele'" , "'disman@nexen.com'" , "'agentx@peer.com'" Subject: Re: AgentX Log Table References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit If it is just for debugging, how about if the agent X code just sends some syslogs (or other log information) out to a host to be processed during the code development then turned off when the product ships. Carl "Heintz, Lauren" wrote: > > Hi Mike, > > > -----Original Message----- > > From: Mike Daniele [mailto:daniele@zk3.dec.com] > > Maybe I don't understand the requirement. > > I believe the general requirement is to define some mechanism for AgentX to > allow debugging of mis-behaving AgentX implementations (probably at > implementation or installation time). The AgentX list consensus (to my > recollection) seemed to indicate (with one or two exceptions) that most > AgentX implementors did not feel this was important, but I believe more > discussion is warranted. > > So the purpose of my proposal is to, a) begin the process of reaching final > consensus on what statistics/errors are needed and, b) to suggest a starting > point. > > > But what is wrong > > with just defining appropriate counters/notifications in the > > AgentX MIB? > > Regarding notifications: > > Seems overkill to me to define notifications (even one) in the AgentX MIB > just to provide a debugging capability that most people (judging by the > opinions expressed on the AgentX list) don't even need/want. Then to have > to implement and configure the disman LOG MIB and the notification tables to > even be able to log AgentX errors/statistics makes it even more complex and > way too undesirable (IMHO). > > Regarding counters: > > If counters are designed to effectively augment given entries in the > connection, session or registration tables, then those same counters and > their values will dissappear the moment the associated connection, session > or registration is/are closed. As you recall, AgentX master agents are > supposed to close misbehaving connections, thus, it doesn't seem very useful > to tightly couple these counters with the current tables. Something more > persistent is needed. > > To instead have a group of general-purpose scalar counters would not likely > help anyone figure out exactly which subagent is misbehaving. This is the > reason for the log proposal. Each entry would indicate all the info needed > to identify the specific nature of the problem and which subagent caused it. > > I personally suggest we remove the requirement to have the AgentX MIB > contain error/statistics counters of any kind and to instead rely on a > simple (to use and implement) and generic log mechanism (such as in my > proposal) to report errors/statistics. > > Tks, > Lauren -- Carl W. Kalbfleisch Manager NMS Development Verio Inc., http://www.verio.net From Lauren_Heintz@ec01-hou.bmc.com Thu Feb 4 12:55:49 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA04752 for ; Thu, 4 Feb 1999 12:55:49 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA29503; Thu, 4 Feb 1999 11:52:17 -0600 (CST) Received: from ec01-hou.bmc.com (ec01-hou.bmc.com [172.17.0.150]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA22296 for ; Thu, 4 Feb 1999 09:02:34 -0800 (PST) Received: by ec01-hou.bmc.com with Internet Mail Service (5.5.2232.9) id ; Thu, 4 Feb 1999 11:02:31 -0600 Message-ID: From: "Heintz, Lauren" To: "'Mike Daniele'" Cc: "'agentx@peer.com'" Subject: RE: AgentX Log Table Date: Thu, 4 Feb 1999 11:02:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Mike Daniele [mailto:daniele@zk3.dec.com] > > I don't think the AgentX MIB should define error logging at all. I personally agree with this. And at this point I think I am hearing consensus that a specialized log, error or statistics table should NOT be added to the AgentX MIB. At least no one has objected otherwise. Thanks, Lauren ------------------------------------------------------------------------- Lauren Heintz BMC Software, Inc. (Formerly PEER Networks) Voice: +1 408 616-3169 Silicon Valley Division Fax: +1 408 616-3339 965 Stewart Drive Email: Lauren_Heintz@bmc.com Sunnyvale, California 94086 USA ------------------------------------------------------------------------- From rpresuhn@dorothy.bmc.com Thu Feb 4 20:01:22 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA25650 for ; Thu, 4 Feb 1999 20:01:22 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id SAA17075; Thu, 4 Feb 1999 18:58:11 -0600 (CST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA27970 for agentx@peer.com; Thu, 4 Feb 1999 15:26:01 -0800 (PST) Date: Thu, 4 Feb 1999 15:26:01 -0800 (PST) From: Randy Presuhn Message-Id: <199902042326.PAA27970@dorothy.bmc.com> To: agentx@dorothy.bmc.com Subject: Re: AgentX Log Table Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Thu, 04 Feb 1999 09:40:09 -0500 > From: Mike Daniele > To: Bob Stewart > CC: "'disman@nexen.com'" , > "'agentx@peer.com'" > Subject: Re: AgentX Log Table > References: <4.1.19990204085844.0094e2e0@zipper.cisco.com> ... > I don't think the AgentX MIB should define error logging at all. I agree whole-heartedly with this statement. The fact that interoperable impementations have been successfully developed without such a capability is a good indication of how unnecessary a definition of agentx error logging is. ----------------------------------------------------------------------- Randy Presuhn rpresuhn@dorothy.bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- Any relationship between my opinions and BMC's is coincidental. ----------------------------------------------------------------------- From udel@crow.bmc.com Mon Feb 8 01:41:51 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA08658 for ; Mon, 8 Feb 1999 01:41:50 -0500 (EST) From: udel@crow.bmc.com Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id AAA11895; Mon, 8 Feb 1999 00:39:04 -0600 (CST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id WAA22286 for ; Sun, 7 Feb 1999 22:34:05 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id AAA11073 for ; Mon, 8 Feb 1999 00:34:03 -0600 (CST) Received: from localhost (127.0.0.1) by localhost (8.8.5/8.8.5) with SMTP id TAA18912; Thu, 4 Feb 1999 19:03:27 -0500 (EST) Received: from (courier.samp.12.com) by (120.325.69.112) (8.8.5/8.6.5) with SMTP id GAA01078 for ; Sun, 07 Feb 1999 18:50:14 -0600 (EST) Date: Sun, 07 Feb 99 18:50:14 EST To: Announcement@tangelo.bmc.com Subject: Book & Software reviewers needed. You review it & you keep it! Message-ID: <> Lisa posted your email address on our web site on Feb 5, 1999 stating that you might be interested in becoming a reviewer for our service. We are the largest independent consumer review service on the Internet. We need book, PC & Macintosh software, consumer product and upscale restaurant and resort reviewers. Our reviewers can request virtually any book, software program and consumer product to review. You may keep the review titles after you post your review to our web site. We supply you with the review request forms and envelopes and complete instructions how you are to send theses requests to the publishers and manufacturers. Our review service has been on the internet for two years and we have shipped out over $3,772,532 in products to over 4,200 reviewers in the past 18 months. To learn how to become a reviewer for our company send us an email with the words STARTER PACKAGE in the message subject line. Email to: ims@sprnt-lnk.com OR DOUBLE-CLICK: Sincerely, Kristen Matthews, Senior Editor PS: We have a contract with two major book publishers to sign authors for new eBooks. These are short pamphlets and books up to 1,000 pages which they will publish on their Internet web site. You will write or convert your book to HTML format. We will supply you with free WYSIWYG HTML software programs. REMOVAL FROM LIST? This information is only mailed to individuals who are reviewers or requested information about our review service. You may have had your email address placed on our mailing list by a friend or associate who visited our web site. This is an opt-out newsletter. We honor all REMOVE request. Reply to: ims@sprnt-lnk.com with the word REMOVE in the messsage subject line. From Lauren_Heintz@ec01-hou.bmc.com Mon Feb 8 15:30:48 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA29534 for ; Mon, 8 Feb 1999 15:30:39 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA12966; Mon, 8 Feb 1999 14:25:42 -0600 (CST) Received: from ec01-hou.bmc.com (ec01-hou.bmc.com [172.17.0.150]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA27881 for ; Mon, 8 Feb 1999 12:21:17 -0800 (PST) Received: by ec01-hou.bmc.com with Internet Mail Service (5.5.2232.9) id <1M9F8D0V>; Mon, 8 Feb 1999 14:21:16 -0600 Message-ID: From: "Heintz, Lauren" To: "'agentx@peer.com'" Subject: with change bars Date: Mon, 8 Feb 1999 14:21:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Hi, I am posting this revised agentx mib. Please review it and send the comments to the mailing list(agentx@peer.com). Since there are substantial editing changes, I have only included change bars for those areas that involve the greatest technical change. Lauren Heintz ------------------------------------------------------------------------ INTERNET-DRAFT S. Gudur Independent Consultant L. Heintz BMC Software, Inc. 8 February 1999 Definitions of Managed Objects for Extensible SNMP Agents | Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects managing SNMP agents that use the Agent Extensibility (AgentX) Protocol. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. This memo does not specify a standard for the Internet community. AgentX Working Group Expires August 1999 [Page 1] Internet Draft AgentX MIB 8 February 1999 Table of Contents 1. The SNMP Management Framework ............................... 3 2. Introduction ................................................ 3 3. AgentX MIB Overview ......................................... 4 4. Managed Object Definitions for AgentX ....................... 6 5. Intellectual Property ....................................... 18 6. Acknowledgements ............................................ 18 7. Security Considerations ..................................... 19 8. References .................................................. 20 9. Editors' Addresses .......................................... 22 10. Full Copyright Statement ................................... 22 AgentX Working Group Expires August 1999 [Page 2] Internet Draft AgentX MIB 8 February 1999 1. The SNMP Management Framework The SNMP Network Management Framework presently consists of five major components: - An overall architecture, described in RFC 2271 [1] - Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. - Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. - Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. - A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. AgentX Working Group Expires August 1999 [Page 3] Internet Draft AgentX MIB 8 February 1999 2. Introduction The SNMP Agent Extensibility Protocol (AgentX) is a protocol used to distribute the implementation of an SNMP agent amongst a single "mas- ter agent" and multiple "subagents". See [16] for details about the AgentX protocol. The goals of the AgentX MIB are: - List the set of subagents that currently have logical sessions open with the master agent. - Identify each subagent's type, vendor, transport address, AgentX protocol version, and other characteristics. - Identify the set of MIB objects each subagent implements, the context in which the objects are registered, and the priority of the registration. - Determine protocol operational parameters such as the timeout interval for responses from a subagent and the priority at which a subagent registers a particular MIB region. - Allow (but do not require) managers to be able to modify AgentX protocol operational parameters and to explicitly close subagent sessions with the master agent. 3. AgentX MIB Overview This MIB is organized into four groups. The agentxGeneral group provides information describing the master agent's Agentx support, including the protocol version supported. The agentxConnection group provides information describing the current set of connections capable of carrying Agentx sessions. The agentxSession group provides information describing the current set of AgentX sessions. The agentxRegistration group provides information describing the current set of registrations. Three tables form the heart of this mib. These are the connection, session, and registration tables. Entries in the registration table exist in a many-to-one relationship with entries in the session table. This relationship is expressed through the two common indices, agentxSessionIndex and agentxConnIndex. Entries in the registration table also exist in a many-to-one relationship with entries in the connection table. This relationship is expressed through the common index, agentxConnIndex. AgentX Working Group Expires August 1999 [Page 4] Internet Draft AgentX MIB 8 February 1999 Entries in the session table exist in a many-to-one relationship with entries in the connection table. This relationship is expressed through the common index, agentxConnIndex. AgentX Working Group Expires August 1999 [Page 5] Internet Draft AgentX MIB 8 February 1999 4. Managed Object Definitions for AgentX AGENTX-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Unsigned32, mib-2 ! FROM SNMPv2-SMI SnmpAdminString FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION, TimeStamp, TruthValue, TDomain ! FROM SNMPv2-TC; agentxMIB MODULE-IDENTITY LAST-UPDATED "9902081200Z" -- February 8, 1999 ! ORGANIZATION "AgentX Working Group" CONTACT-INFO "WG-email: agentx@peer.com Subscribe: agentx-request@peer.com http://www.ietf.org/html.charters/agentx-charter.html Chair: Bob Natale ACE*COMM Corporation Email: bnatale@acecomm.com Co-editor: Smitha Gudur ! Independent Consultant ! Email: sgudur@hotmail.com ! Co-editor: Lauren Heintz ! postal: BMC Software, Inc. ! 965 Stewart Drive ! Sunnyvale, CA 94086 ! USA ! EMail: Lauren_Heintz@bmc.com ! Phone: +1 408-616-3169 ! " DESCRIPTION "This is the MIB module for the SNMP Agent Extensibility Protocol (AgentX). This MIB module will be implemented by the master agent. " ::= { mib-2 ? } -- To be assigned by IANA. ! AgentX Working Group Expires August 1999 [Page 6] Internet Draft AgentX MIB 8 February 1999 -- Textual Conventions AgentxTAddress ::= TEXTUAL-CONVENTION ! STATUS current ! DESCRIPTION ! "Denotes a transport service address. This is identical to ! the TAddress textual convention (SNMPv2-SMI) except that ! zero-length values are permitted. ! " ! SYNTAX OCTET STRING (SIZE (0..255)) -- Administrative assignments agentxObjects OBJECT IDENTIFIER ::= { agentxMIB 1 } agentxGeneral OBJECT IDENTIFIER ::= { agentxObjects 1 } agentxConnection OBJECT IDENTIFIER ::= { agentxObjects 2 } agentxSession OBJECT IDENTIFIER ::= { agentxObjects 3 } agentxRegistration OBJECT IDENTIFIER ::= { agentxObjects 4 } agentxDefaultTimeout OBJECT-TYPE SYNTAX INTEGER (0..255) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The default length of time, in seconds, that the master agent should allow to elapse after dispatching a message to a subagent before it regards the subagent as not responding. This is a system-wide value that may be overridden by the values associated with a particular subagent (agentxSessionTimeout) or a particular registered MIB region (agentxRegTimeout). " DEFVAL { 5 } ::= { agentxGeneral 1 } agentxMasterAgentXVer OBJECT-TYPE SYNTAX INTEGER (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The AgentX protocol version supported by this master agent. The current protocol version is 1. Note that the master agent must also allow registration of earlier version subagents. " ::= { agentxGeneral 2 } AgentX Working Group Expires August 1999 [Page 7] Internet Draft AgentX MIB 8 February 1999 -- The Agentx Subagent Connection Group agentxConnTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last row creation or deletion occurred in the agentxConnectionTable. " ::= { agentxConnection 1 } agentxConnectionTable OBJECT-TYPE SYNTAX SEQUENCE OF AgentxConnectionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The agentxConnectionTable tracks all current Agentx transport connections. There may be zero, one, or more agentx sessions carried on a given Agentx connection. " ::= { agentxConnection 2 } agentxConnectionEntry OBJECT-TYPE SYNTAX AgentxConnectionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An agentxConnectionEntry contains information describing a single Agentx transport connection. A connection may be used to support zero or more Agentx sessions. An entry is ! created when a new transport connection is established, ! and is destroyed when the transport connection is terminated. ! " INDEX { agentxConnIndex } ::= { agentxConnectionTable 1 } AgentxConnectionEntry ::= SEQUENCE { agentxConnIndex Unsigned32, agentxConnOpenTime TimeStamp, agentxConnTransportDomain TDomain, agentxConnTransportAddress AgentxTAddress } AgentX Working Group Expires August 1999 [Page 8] Internet Draft AgentX MIB 8 February 1999 agentxConnIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "agentxConnIndex contains the value that uniquely identifies an open transport connection used by this master agent to provide AgentX service. Values of this index should not be re-used. The value assigned to a given transport connection is constant for the lifetime of that connection. " ::= { agentxConnectionEntry 1 } agentxConnOpenTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this connection was established and, therefore, its value when this entry was added to the table. " ::= { agentxConnectionEntry 2 } agentxConnTransportDomain OBJECT-TYPE SYNTAX TDomain MAX-ACCESS read-only STATUS current DESCRIPTION "The transport protocol in use for this connection to the subagent. " ::= { agentxConnectionEntry 3 } agentxConnTransportAddress OBJECT-TYPE SYNTAX AgentxTAddress ! MAX-ACCESS read-only STATUS current DESCRIPTION "The transport address of the remote (subagent) end of this connection to the master agent. This object may be zero-length! for unix-domain sockets (and possibly other types of transport ! addresses) since the subagent need not bind a filename to its ! local socket. ! " ::= { agentxConnectionEntry 4 } AgentX Working Group Expires August 1999 [Page 9] Internet Draft AgentX MIB 8 February 1999 -- The AgentX Subagent Session Group agentxSessionTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last row creation or deletion occurred in the agentxSessionTable. " ::= { agentxSession 1 } agentxSessionTable OBJECT-TYPE SYNTAX SEQUENCE OF AgentxSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of AgentX subagent sessions currently in effect. " ::= { agentxSession 2 } ! agentxSessionEntry OBJECT-TYPE SYNTAX AgentxSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single open session between the AgentX master agent and a subagent is contained in this entry. An entry is created when a new session is successfully established! and is destroyed either when the parent transport connection ! has terminated or when the session is closed. ! " INDEX { agentxConnIndex, agentxSessionIndex } ::= { agentxSessionTable 1 } AgentxSessionEntry ::= SEQUENCE { agentxSessionIndex Unsigned32, agentxSessionObjectID OBJECT IDENTIFIER, agentxSessionDescr SnmpAdminString, agentxSessionAdminStatus INTEGER, agentxSessionOpenTime TimeStamp, agentxSessionAgentXVer INTEGER, agentxSessionTimeout INTEGER } AgentX Working Group Expires August 1999 [Page 10] Internet Draft AgentX MIB 8 February 1999 agentxSessionIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index for the subagent session. It is the same as h.sessionID defined in the agentx header. Note that if a subagent's session with the master agent is closed for any reason its index should not be re-used, therefore, the values of agentxSessionIndex may be discontiguous and will generally not be the same for the same subagent across multiple sessions. " ::= { agentxSessionEntry 1 } agentxSessionObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "This is taken from the o.id field of the agentx-Open-PDU. " ::= { agentxSessionEntry 2 } agentxSessionDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the subagent. This is analogous to sysDescr defined in MIB-2 [2] and is taken from the o.descr field of the agentx-Open-PDU. " ::= { agentxSessionEntry 3 } agentxSessionAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The administrative (desired) status of the subagent. Setting the value to 'down(2)' closes the subagent session (with c.reason set to 'reasonByManager'). " ::= { agentxSessionEntry 4 } AgentX Working Group Expires August 1999 [Page 11] Internet Draft AgentX MIB 8 February 1999 agentxSessionOpenTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this session was opened and, therefore, its value when this entry was added to the table. " ::= { agentxSessionEntry 5 } agentxSessionAgentXVer OBJECT-TYPE SYNTAX INTEGER (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The version of the AgentX protocol supported by the subagent. This will be less than or equal to the value of agentxMasterAgentXVer. " ::= { agentxSessionEntry 6 } agentxSessionTimeout OBJECT-TYPE SYNTAX INTEGER (0..255) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The length of time, in seconds, that a master agent should allow to elapse after dispatching a message to this subagent before it regards the subagent as not responding. This value is taken from the o.timeout field of the agentx-Open-PDU. This is a subagent-specific value that may be overridden by values associated with specific registered MIB regions (see agentxRegTimeout). The default value of zero indicates that the master agent's default timeout value should be used (see agentxDefaultTimeout). " ::= { agentxSessionEntry 7 } AgentX Working Group Expires August 1999 [Page 12] Internet Draft AgentX MIB 8 February 1999 -- The AgentX Registration Group agentxRegisterDuplicate OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages sent by this master agent where the res.error field was set to 'duplicateRegistration'. " ::= { agentxRegistration 1 } agentxRegistrationTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last row creation or deletion occurred in the agentxRegistrationTable. " ::= { agentxRegistration 2 } agentxRegistrationTable OBJECT-TYPE SYNTAX SEQUENCE OF AgentxRegistrationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of registered regions. ! " ! ::= { agentxRegistration 3 } agentxRegistrationEntry OBJECT-TYPE SYNTAX AgentxRegistrationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains information for a single registered region. An ! entry is created when a subagent successfully registers a ! region and is destroyed for any of three reasons: this region ! is unregistered by the subagent, the parent session is closed, ! or the parent connection is closed. ! " ! INDEX { agentxConnIndex, agentxSessionIndex, agentxRegIndex } ::= { agentxRegistrationTable 1 } AgentX Working Group Expires August 1999 [Page 13] Internet Draft AgentX MIB 8 February 1999 AgentxRegistrationEntry ::= SEQUENCE { agentxRegIndex Unsigned32, agentxRegContext OCTET STRING, agentxRegStart OBJECT IDENTIFIER, agentxRegRangeSubId Unsigned32, ! agentxRegUpperBound Unsigned32, ! agentxRegPriority Unsigned32, agentxRegTimeout INTEGER, agentxRegInstance TruthValue } agentxRegIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "agentxRegIndex uniquely identifies a registration entry. This value is constant for the lifetime of an entry. " ::= { agentxRegistrationEntry 1 } agentxRegContext OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The context in which the subagent supports the objects in this region. A zero-length context indicates the default context. " ::= { agentxRegistrationEntry 2 } agentxRegStart OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The starting OBJECT IDENTIFIER of this registration entry. The subagent identified by agentxSessionIndex implements objects starting at this value (inclusive). Note that this value could identify an object type, an object instance, or a partial object instance. " ::= { agentxRegistrationEntry 3 } AgentX Working Group Expires August 1999 [Page 14] Internet Draft AgentX MIB 8 February 1999 agentxRegRangeSubId OBJECT-TYPE SYNTAX Unsigned32 ! MAX-ACCESS read-only STATUS current DESCRIPTION "agentxRegRangeSubId is used to specify the range. This is taken from r.region_subid in the registration PDU. If the value of this object is zero, no range is specified. If it is non-zero, it identifies the "nth" sub-identifier in r.region for which this entry's agentxRegUpperBound value is substituted in the OID for purposes of defining the region's upper bound. " ::= { agentxRegistrationEntry 4 } agentxRegUpperBound OBJECT-TYPE ! SYNTAX Unsigned32 ! MAX-ACCESS read-only ! STATUS current ! DESCRIPTION ! "agentxRegUpperBound represents the upper-bound sub-identifier in! a registration. This is taken from the r.upper_bound in the ! registration PDU. If agentxRegRangeSubid (r.region_subid) is ! zero, this value is also zero and is not used to define an upper! bound for this registration. ! " ! ::= { agentxRegistrationEntry 5 } ! agentxRegPriority OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The subagent's priority when exporting this OID range. Lower values have higher priority. " ::= { agentxRegistrationEntry 6 } agentxRegTimeout OBJECT-TYPE SYNTAX INTEGER (0..255) UNITS "seconds" MAX-ACCESS read-only STATUS current AgentX Working Group Expires August 1999 [Page 15] Internet Draft AgentX MIB 8 February 1999 DESCRIPTION "The timeout value, in seconds, for subagent responses to requests associated with this OID range. A value of zero indicates the default value (indicated by agentxSessionTimeout or agentxDefaultTimeout) is to be used. This value is taken from the r.timeout field of the agentx-Register-PDU. " ::= { agentxRegistrationEntry 7 } agentxRegInstance OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The value of agentxRegInstance is `true' for registrations for which the INSTANCE_REGISTRATION was set, and is `false' for all other registrations. " ::= { agentxRegistrationEntry 8 } -- Conformance Statements for AgentX agentxConformance OBJECT IDENTIFIER ::= { agentxMIB 2 } agentxMIBGroups OBJECT IDENTIFIER ::= { agentxConformance 1 } agentxMIBCompliances OBJECT IDENTIFIER ::= { agentxConformance 2 } -- Compliance Statements for AgentX agentxMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the AgentX protocol. Note that a compliant agent can implement all objects in this MIB module as read-only. " MODULE -- this module MANDATORY-GROUPS { agentxMIBGroup } OBJECT agentxDefaultTimeout MIN-ACCESS read-only DESCRIPTION "Write access is not required. " AgentX Working Group Expires August 1999 [Page 16] Internet Draft AgentX MIB 8 February 1999 OBJECT agentxSessionAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required. " ::= { agentxMIBCompliances 1 } agentxMIBGroup OBJECT-GROUP OBJECTS { agentxDefaultTimeout, agentxMasterAgentXVer, agentxConnTableLastChange, ! agentxConnOpenTime, agentxConnTransportDomain, agentxConnTransportAddress, agentxSessionTableLastChange, agentxSessionTimeout, agentxSessionObjectID, agentxSessionDescr, agentxSessionAdminStatus, agentxSessionOpenTime, agentxSessionAgentXVer, agentxRegisterDuplicate, agentxRegistrationTableLastChange, agentxRegContext, agentxRegStart, agentxRegRangeSubId, agentxRegUpperBound, agentxRegPriority, agentxRegTimeout, agentxRegInstance } STATUS current DESCRIPTION "All accessible objects in the AgentX MIB. " ::= { agentxMIBGroups 1 } END AgentX Working Group Expires August 1999 [Page 17] Internet Draft AgentX MIB 8 February 1999 5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 6. Acknowledgements This document is the result of the efforts of the IETF AgentX Working Group (WG). This MIB is an evolution of the Subagent MIB by Bert Wijnen (wijnen@vnet.ibm.com) which in turn was derived from the SMUX-MIB by Marshall Rose [17]. Thanks are in order to the following AgentX WG members: Mike Daniele (Compaq Computer Corporation) Dale Francisco (Cisco Systems) Bob Natale (ACE*COMM Corporation) Randy Presuhn (BMC Software, Inc.) Shawn Routhier (Epilogue) Mike Thatcher (Independent Consultant) Special acknowledgement is made to: Maria Greene (Xedia) AgentX Working Group Expires August 1999 [Page 18] Internet Draft AgentX MIB 8 February 1999 Special acknowledgement is also made to the following individuals for participating in the 1998 Agentx testing summit (bakeoff) held in Sunnyvale, California: Mike Daniele (Compaq Computer Corporation) Jeff Case (SNMP Research, Inc.) Mark Ellison (Independent Consultant) Lauren Heintz (BMC Software, Inc.) Verne Hyde (Independent Consultant) Bob Natale (ACE*COMM Corporation) Shawn Routhier (Epilogue) Mike Thatcher (Independent Consultant) Bert Wijnen (IBM T. J. Watson Research Center) 7. Security Considerations In most cases, MIBs are not themselves security risks; if SNMP security is operating as intended, the use of a MIB to view information about a system, or to change some parameter at the system, is a tool, not a threat. None of the read-only objects in this MIB reports a password, user data, or anything else that is particularly sensitive. If access to these objects is not limited by an appropriate access control policy, these objects can provide an attacker with information about a system's configuration and the services that that system is providing. Some enterprises view their network and system configurations themselves, as well as information about usage and performance, as corporate assets; such enterprises may wish to restrict SNMP access to most of the objects in the MIB. This MIB contains two read-write objects: agentxDefaultTimeout and agentxSessionAdminStatus. Setting agentxDefaultTimeout to an inappropriately small value can prevent new subagent sessions from being usable. Setting agentxSessionAdminStatus to an inappropriate value can effectively prevent access to management information, or provide access to inappropriate information. Since changes to either of these objects can adversely impact the manageability of a system, write access to these objects should be subject to an appropriate access control policy. Such a policy may be realized in an implementation by limiting support for these objects to read-only access. AgentX Working Group Expires August 1999 [Page 19] Internet Draft AgentX MIB 8 February 1999 8. References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998 [2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991 [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991 [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Proto- col (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, Jan- uary 1996. [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. AgentX Working Group Expires August 1999 [Page 20] Internet Draft AgentX MIB 8 February 1999 [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Trans- port Mappings for Version 2 of the Simple Network Management Pro- tocol (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Ser- vices, January 1996. [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, IBM T. J. Watson Research, January 1998. [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco Systems, January 1998 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., Cisco Systems, Inc., January 1998 [16] Daniele, M., Wijnen, B., and D. Francisco, "Agent Extensibility (AgentX) Protocol, Version 1", draft-ietf-agentx-ext-pro-02.txt, Digital Equipment Corporation, T.J. Watson Research Center, IBM Corp., Cisco Systems, November, 1996. [17] Rose, M., "SNMP MUX Protocol and MIB", RFC1227, Performance Systems International, May 1991. AgentX Working Group Expires August 1999 [Page 21] Internet Draft AgentX MIB 8 February 1999 9. Editors' Addresses Smitha Gudur Independent Consultant EMail: sgudur@hotmail.com Lauren Heintz BMC Software, Inc 965 Stewart Drive Sunnyvale, CA 94086 USA Phone: +1 408-616-3169 Fax: +1 408-616-3101 EMail: Lauren_Heintz@bmc.com 10. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. AgentX Working Group Expires August 1999 [Page 22] From Lauren_Heintz@ec01-hou.bmc.com Mon Feb 8 15:33:24 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA29707 for ; Mon, 8 Feb 1999 15:33:22 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA13661; Mon, 8 Feb 1999 14:29:05 -0600 (CST) Received: from ec01-hou.bmc.com (ec01-hou.bmc.com [172.17.0.150]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA27989 for ; Mon, 8 Feb 1999 12:28:42 -0800 (PST) Received: by ec01-hou.bmc.com with Internet Mail Service (5.5.2232.9) id <1M9F81HC>; Mon, 8 Feb 1999 14:28:41 -0600 Message-ID: From: "Heintz, Lauren" To: internet-drafts@ietf.org Cc: "'agentx@peer.com'" Subject: Date: Mon, 8 Feb 1999 14:28:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Please post the following as an internet-draft for the AgentX WG. Thanks, Lauren Heintz ------------------------------------------------------------------------ INTERNET-DRAFT S. Gudur Independent Consultant L. Heintz BMC Software, Inc. 8 February 1999 Definitions of Managed Objects for Extensible SNMP Agents Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects managing SNMP agents that use the Agent Extensibility (AgentX) Protocol. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. This memo does not specify a standard for the Internet community. AgentX Working Group Expires August 1999 [Page 1] Internet Draft AgentX MIB 8 February 1999 Table of Contents 1. The SNMP Management Framework ............................... 3 2. Introduction ................................................ 3 3. AgentX MIB Overview ......................................... 4 4. Managed Object Definitions for AgentX ....................... 6 5. Intellectual Property ....................................... 18 6. Acknowledgements ............................................ 18 7. Security Considerations ..................................... 19 8. References .................................................. 20 9. Editors' Addresses .......................................... 22 10. Full Copyright Statement ................................... 22 AgentX Working Group Expires August 1999 [Page 2] Internet Draft AgentX MIB 8 February 1999 1. The SNMP Management Framework The SNMP Network Management Framework presently consists of five major components: - An overall architecture, described in RFC 2271 [1] - Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. - Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. - Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. - A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. AgentX Working Group Expires August 1999 [Page 3] Internet Draft AgentX MIB 8 February 1999 2. Introduction The SNMP Agent Extensibility Protocol (AgentX) is a protocol used to distribute the implementation of an SNMP agent amongst a single "mas- ter agent" and multiple "subagents". See [16] for details about the AgentX protocol. The goals of the AgentX MIB are: - List the set of subagents that currently have logical sessions open with the master agent. - Identify each subagent's type, vendor, transport address, AgentX protocol version, and other characteristics. - Identify the set of MIB objects each subagent implements, the context in which the objects are registered, and the priority of the registration. - Determine protocol operational parameters such as the timeout interval for responses from a subagent and the priority at which a subagent registers a particular MIB region. - Allow (but do not require) managers to be able to modify AgentX protocol operational parameters and to explicitly close subagent sessions with the master agent. 3. AgentX MIB Overview This MIB is organized into four groups. The agentxGeneral group provides information describing the master agent's Agentx support, including the protocol version supported. The agentxConnection group provides information describing the current set of connections capable of carrying Agentx sessions. The agentxSession group provides information describing the current set of AgentX sessions. The agentxRegistration group provides information describing the current set of registrations. Three tables form the heart of this mib. These are the connection, session, and registration tables. Entries in the registration table exist in a many-to-one relationship with entries in the session table. This relationship is expressed through the two common indices, agentxSessionIndex and agentxConnIndex. Entries in the registration table also exist in a many-to-one relationship with entries in the connection table. This relationship is expressed through the common index, agentxConnIndex. AgentX Working Group Expires August 1999 [Page 4] Internet Draft AgentX MIB 8 February 1999 Entries in the session table exist in a many-to-one relationship with entries in the connection table. This relationship is expressed through the common index, agentxConnIndex. AgentX Working Group Expires August 1999 [Page 5] Internet Draft AgentX MIB 8 February 1999 4. Managed Object Definitions for AgentX AGENTX-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Unsigned32, mib-2 FROM SNMPv2-SMI SnmpAdminString FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION, TimeStamp, TruthValue, TDomain FROM SNMPv2-TC; agentxMIB MODULE-IDENTITY LAST-UPDATED "9902081200Z" -- February 8, 1999 ORGANIZATION "AgentX Working Group" CONTACT-INFO "WG-email: agentx@peer.com Subscribe: agentx-request@peer.com http://www.ietf.org/html.charters/agentx-charter.html Chair: Bob Natale ACE*COMM Corporation Email: bnatale@acecomm.com Co-editor: Smitha Gudur Independent Consultant Email: sgudur@hotmail.com Co-editor: Lauren Heintz postal: BMC Software, Inc. 965 Stewart Drive Sunnyvale, CA 94086 USA EMail: Lauren_Heintz@bmc.com Phone: +1 408-616-3169 " DESCRIPTION "This is the MIB module for the SNMP Agent Extensibility Protocol (AgentX). This MIB module will be implemented by the master agent. " ::= { mib-2 ? } -- To be assigned by IANA. AgentX Working Group Expires August 1999 [Page 6] Internet Draft AgentX MIB 8 February 1999 -- Textual Conventions AgentxTAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Denotes a transport service address. This is identical to the TAddress textual convention (SNMPv2-SMI) except that zero-length values are permitted. " SYNTAX OCTET STRING (SIZE (0..255)) -- Administrative assignments agentxObjects OBJECT IDENTIFIER ::= { agentxMIB 1 } agentxGeneral OBJECT IDENTIFIER ::= { agentxObjects 1 } agentxConnection OBJECT IDENTIFIER ::= { agentxObjects 2 } agentxSession OBJECT IDENTIFIER ::= { agentxObjects 3 } agentxRegistration OBJECT IDENTIFIER ::= { agentxObjects 4 } agentxDefaultTimeout OBJECT-TYPE SYNTAX INTEGER (0..255) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The default length of time, in seconds, that the master agent should allow to elapse after dispatching a message to a subagent before it regards the subagent as not responding. This is a system-wide value that may be overridden by the values associated with a particular subagent (agentxSessionTimeout) or a particular registered MIB region (agentxRegTimeout). " DEFVAL { 5 } ::= { agentxGeneral 1 } agentxMasterAgentXVer OBJECT-TYPE SYNTAX INTEGER (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The AgentX protocol version supported by this master agent. The current protocol version is 1. Note that the master agent must also allow registration of earlier version subagents. " ::= { agentxGeneral 2 } AgentX Working Group Expires August 1999 [Page 7] Internet Draft AgentX MIB 8 February 1999 -- The Agentx Subagent Connection Group agentxConnTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last row creation or deletion occurred in the agentxConnectionTable. " ::= { agentxConnection 1 } agentxConnectionTable OBJECT-TYPE SYNTAX SEQUENCE OF AgentxConnectionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The agentxConnectionTable tracks all current Agentx transport connections. There may be zero, one, or more agentx sessions carried on a given Agentx connection. " ::= { agentxConnection 2 } agentxConnectionEntry OBJECT-TYPE SYNTAX AgentxConnectionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An agentxConnectionEntry contains information describing a single Agentx transport connection. A connection may be used to support zero or more Agentx sessions. An entry is created when a new transport connection is established, and is destroyed when the transport connection is terminated. " INDEX { agentxConnIndex } ::= { agentxConnectionTable 1 } AgentxConnectionEntry ::= SEQUENCE { agentxConnIndex Unsigned32, agentxConnOpenTime TimeStamp, agentxConnTransportDomain TDomain, agentxConnTransportAddress AgentxTAddress } AgentX Working Group Expires August 1999 [Page 8] Internet Draft AgentX MIB 8 February 1999 agentxConnIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "agentxConnIndex contains the value that uniquely identifies an open transport connection used by this master agent to provide AgentX service. Values of this index should not be re-used. The value assigned to a given transport connection is constant for the lifetime of that connection. " ::= { agentxConnectionEntry 1 } agentxConnOpenTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this connection was established and, therefore, its value when this entry was added to the table. " ::= { agentxConnectionEntry 2 } agentxConnTransportDomain OBJECT-TYPE SYNTAX TDomain MAX-ACCESS read-only STATUS current DESCRIPTION "The transport protocol in use for this connection to the subagent. " ::= { agentxConnectionEntry 3 } agentxConnTransportAddress OBJECT-TYPE SYNTAX AgentxTAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The transport address of the remote (subagent) end of this connection to the master agent. This object may be zero-length for unix-domain sockets (and possibly other types of transport addresses) since the subagent need not bind a filename to its local socket. " ::= { agentxConnectionEntry 4 } AgentX Working Group Expires August 1999 [Page 9] Internet Draft AgentX MIB 8 February 1999 -- The AgentX Subagent Session Group agentxSessionTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last row creation or deletion occurred in the agentxSessionTable. " ::= { agentxSession 1 } agentxSessionTable OBJECT-TYPE SYNTAX SEQUENCE OF AgentxSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of AgentX subagent sessions currently in effect. " ::= { agentxSession 2 } agentxSessionEntry OBJECT-TYPE SYNTAX AgentxSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single open session between the AgentX master agent and a subagent is contained in this entry. An entry is created when a new session is successfully established and is destroyed either when the parent transport connection has terminated or when the session is closed. " INDEX { agentxConnIndex, agentxSessionIndex } ::= { agentxSessionTable 1 } AgentxSessionEntry ::= SEQUENCE { agentxSessionIndex Unsigned32, agentxSessionObjectID OBJECT IDENTIFIER, agentxSessionDescr SnmpAdminString, agentxSessionAdminStatus INTEGER, agentxSessionOpenTime TimeStamp, agentxSessionAgentXVer INTEGER, agentxSessionTimeout INTEGER } AgentX Working Group Expires August 1999 [Page 10] Internet Draft AgentX MIB 8 February 1999 agentxSessionIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index for the subagent session. It is the same as h.sessionID defined in the agentx header. Note that if a subagent's session with the master agent is closed for any reason its index should not be re-used, therefore, the values of agentxSessionIndex may be discontiguous and will generally not be the same for the same subagent across multiple sessions. " ::= { agentxSessionEntry 1 } agentxSessionObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "This is taken from the o.id field of the agentx-Open-PDU. " ::= { agentxSessionEntry 2 } agentxSessionDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the subagent. This is analogous to sysDescr defined in MIB-2 [2] and is taken from the o.descr field of the agentx-Open-PDU. " ::= { agentxSessionEntry 3 } agentxSessionAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The administrative (desired) status of the subagent. Setting the value to 'down(2)' closes the subagent session (with c.reason set to 'reasonByManager'). " ::= { agentxSessionEntry 4 } AgentX Working Group Expires August 1999 [Page 11] Internet Draft AgentX MIB 8 February 1999 agentxSessionOpenTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this session was opened and, therefore, its value when this entry was added to the table. " ::= { agentxSessionEntry 5 } agentxSessionAgentXVer OBJECT-TYPE SYNTAX INTEGER (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The version of the AgentX protocol supported by the subagent. This will be less than or equal to the value of agentxMasterAgentXVer. " ::= { agentxSessionEntry 6 } agentxSessionTimeout OBJECT-TYPE SYNTAX INTEGER (0..255) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The length of time, in seconds, that a master agent should allow to elapse after dispatching a message to this subagent before it regards the subagent as not responding. This value is taken from the o.timeout field of the agentx-Open-PDU. This is a subagent-specific value that may be overridden by values associated with specific registered MIB regions (see agentxRegTimeout). The default value of zero indicates that the master agent's default timeout value should be used (see agentxDefaultTimeout). " ::= { agentxSessionEntry 7 } AgentX Working Group Expires August 1999 [Page 12] Internet Draft AgentX MIB 8 February 1999 -- The AgentX Registration Group agentxRegisterDuplicate OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages sent by this master agent where the res.error field was set to 'duplicateRegistration'. " ::= { agentxRegistration 1 } agentxRegistrationTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last row creation or deletion occurred in the agentxRegistrationTable. " ::= { agentxRegistration 2 } agentxRegistrationTable OBJECT-TYPE SYNTAX SEQUENCE OF AgentxRegistrationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of registered regions. " ::= { agentxRegistration 3 } agentxRegistrationEntry OBJECT-TYPE SYNTAX AgentxRegistrationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains information for a single registered region. An entry is created when a subagent successfully registers a region and is destroyed for any of three reasons: this region is unregistered by the subagent, the parent session is closed, or the parent connection is closed. " INDEX { agentxConnIndex, agentxSessionIndex, agentxRegIndex } ::= { agentxRegistrationTable 1 } AgentX Working Group Expires August 1999 [Page 13] Internet Draft AgentX MIB 8 February 1999 AgentxRegistrationEntry ::= SEQUENCE { agentxRegIndex Unsigned32, agentxRegContext OCTET STRING, agentxRegStart OBJECT IDENTIFIER, agentxRegRangeSubId Unsigned32, agentxRegUpperBound Unsigned32, agentxRegPriority Unsigned32, agentxRegTimeout INTEGER, agentxRegInstance TruthValue } agentxRegIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "agentxRegIndex uniquely identifies a registration entry. This value is constant for the lifetime of an entry. " ::= { agentxRegistrationEntry 1 } agentxRegContext OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The context in which the subagent supports the objects in this region. A zero-length context indicates the default context. " ::= { agentxRegistrationEntry 2 } agentxRegStart OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The starting OBJECT IDENTIFIER of this registration entry. The subagent identified by agentxSessionIndex implements objects starting at this value (inclusive). Note that this value could identify an object type, an object instance, or a partial object instance. " ::= { agentxRegistrationEntry 3 } AgentX Working Group Expires August 1999 [Page 14] Internet Draft AgentX MIB 8 February 1999 agentxRegRangeSubId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "agentxRegRangeSubId is used to specify the range. This is taken from r.region_subid in the registration PDU. If the value of this object is zero, no range is specified. If it is non-zero, it identifies the "nth" sub-identifier in r.region for which this entry's agentxRegUpperBound value is substituted in the OID for purposes of defining the region's upper bound. " ::= { agentxRegistrationEntry 4 } agentxRegUpperBound OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "agentxRegUpperBound represents the upper-bound sub-identifier in a registration. This is taken from the r.upper_bound in the registration PDU. If agentxRegRangeSubid (r.region_subid) is zero, this value is also zero and is not used to define an upper bound for this registration. " ::= { agentxRegistrationEntry 5 } agentxRegPriority OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The subagent's priority when exporting this OID range. Lower values have higher priority. " ::= { agentxRegistrationEntry 6 } agentxRegTimeout OBJECT-TYPE SYNTAX INTEGER (0..255) UNITS "seconds" MAX-ACCESS read-only STATUS current AgentX Working Group Expires August 1999 [Page 15] Internet Draft AgentX MIB 8 February 1999 DESCRIPTION "The timeout value, in seconds, for subagent responses to requests associated with this OID range. A value of zero indicates the default value (indicated by agentxSessionTimeout or agentxDefaultTimeout) is to be used. This value is taken from the r.timeout field of the agentx-Register-PDU. " ::= { agentxRegistrationEntry 7 } agentxRegInstance OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The value of agentxRegInstance is `true' for registrations for which the INSTANCE_REGISTRATION was set, and is `false' for all other registrations. " ::= { agentxRegistrationEntry 8 } -- Conformance Statements for AgentX agentxConformance OBJECT IDENTIFIER ::= { agentxMIB 2 } agentxMIBGroups OBJECT IDENTIFIER ::= { agentxConformance 1 } agentxMIBCompliances OBJECT IDENTIFIER ::= { agentxConformance 2 } -- Compliance Statements for AgentX agentxMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the AgentX protocol. Note that a compliant agent can implement all objects in this MIB module as read-only. " MODULE -- this module MANDATORY-GROUPS { agentxMIBGroup } OBJECT agentxDefaultTimeout MIN-ACCESS read-only DESCRIPTION "Write access is not required. " AgentX Working Group Expires August 1999 [Page 16] Internet Draft AgentX MIB 8 February 1999 OBJECT agentxSessionAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required. " ::= { agentxMIBCompliances 1 } agentxMIBGroup OBJECT-GROUP OBJECTS { agentxDefaultTimeout, agentxMasterAgentXVer, agentxConnTableLastChange, agentxConnOpenTime, agentxConnTransportDomain, agentxConnTransportAddress, agentxSessionTableLastChange, agentxSessionTimeout, agentxSessionObjectID, agentxSessionDescr, agentxSessionAdminStatus, agentxSessionOpenTime, agentxSessionAgentXVer, agentxRegisterDuplicate, agentxRegistrationTableLastChange, agentxRegContext, agentxRegStart, agentxRegRangeSubId, agentxRegUpperBound, agentxRegPriority, agentxRegTimeout, agentxRegInstance } STATUS current DESCRIPTION "All accessible objects in the AgentX MIB. " ::= { agentxMIBGroups 1 } END AgentX Working Group Expires August 1999 [Page 17] Internet Draft AgentX MIB 8 February 1999 5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 6. Acknowledgements This document is the result of the efforts of the IETF AgentX Working Group (WG). This MIB is an evolution of the Subagent MIB by Bert Wijnen (wijnen@vnet.ibm.com) which in turn was derived from the SMUX-MIB by Marshall Rose [17]. Thanks are in order to the following AgentX WG members: Mike Daniele (Compaq Computer Corporation) Dale Francisco (Cisco Systems) Bob Natale (ACE*COMM Corporation) Randy Presuhn (BMC Software, Inc.) Shawn Routhier (Epilogue) Mike Thatcher (Independent Consultant) Special acknowledgement is made to: Maria Greene (Xedia) AgentX Working Group Expires August 1999 [Page 18] Internet Draft AgentX MIB 8 February 1999 Special acknowledgement is also made to the following individuals for participating in the 1998 Agentx testing summit (bakeoff) held in Sunnyvale, California: Mike Daniele (Compaq Computer Corporation) Jeff Case (SNMP Research, Inc.) Mark Ellison (Independent Consultant) Lauren Heintz (BMC Software, Inc.) Verne Hyde (Independent Consultant) Bob Natale (ACE*COMM Corporation) Shawn Routhier (Epilogue) Mike Thatcher (Independent Consultant) Bert Wijnen (IBM T. J. Watson Research Center) 7. Security Considerations In most cases, MIBs are not themselves security risks; if SNMP security is operating as intended, the use of a MIB to view information about a system, or to change some parameter at the system, is a tool, not a threat. None of the read-only objects in this MIB reports a password, user data, or anything else that is particularly sensitive. If access to these objects is not limited by an appropriate access control policy, these objects can provide an attacker with information about a system's configuration and the services that that system is providing. Some enterprises view their network and system configurations themselves, as well as information about usage and performance, as corporate assets; such enterprises may wish to restrict SNMP access to most of the objects in the MIB. This MIB contains two read-write objects: agentxDefaultTimeout and agentxSessionAdminStatus. Setting agentxDefaultTimeout to an inappropriately small value can prevent new subagent sessions from being usable. Setting agentxSessionAdminStatus to an inappropriate value can effectively prevent access to management information, or provide access to inappropriate information. Since changes to either of these objects can adversely impact the manageability of a system, write access to these objects should be subject to an appropriate access control policy. Such a policy may be realized in an implementation by limiting support for these objects to read-only access. AgentX Working Group Expires August 1999 [Page 19] Internet Draft AgentX MIB 8 February 1999 8. References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998 [2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991 [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991 [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Proto- col (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, Jan- uary 1996. [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. AgentX Working Group Expires August 1999 [Page 20] Internet Draft AgentX MIB 8 February 1999 [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Trans- port Mappings for Version 2 of the Simple Network Management Pro- tocol (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Ser- vices, January 1996. [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, IBM T. J. Watson Research, January 1998. [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco Systems, January 1998 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., Cisco Systems, Inc., January 1998 [16] Daniele, M., Wijnen, B., and D. Francisco, "Agent Extensibility (AgentX) Protocol, Version 1", draft-ietf-agentx-ext-pro-02.txt, Digital Equipment Corporation, T.J. Watson Research Center, IBM Corp., Cisco Systems, November, 1996. [17] Rose, M., "SNMP MUX Protocol and MIB", RFC1227, Performance Systems International, May 1991. AgentX Working Group Expires August 1999 [Page 21] Internet Draft AgentX MIB 8 February 1999 9. Editors' Addresses Smitha Gudur Independent Consultant EMail: sgudur@hotmail.com Lauren Heintz BMC Software, Inc 965 Stewart Drive Sunnyvale, CA 94086 USA Phone: +1 408-616-3169 Fax: +1 408-616-3101 EMail: Lauren_Heintz@bmc.com 10. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. AgentX Working Group Expires August 1999 [Page 22] From Lauren_Heintz@ec01-hou.bmc.com Mon Feb 8 17:41:54 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA04830 for ; Mon, 8 Feb 1999 17:41:48 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA13281; Mon, 8 Feb 1999 16:37:11 -0600 (CST) Received: from ec01-hou.bmc.com (ec01-hou.bmc.com [172.17.0.150]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA29822 for ; Mon, 8 Feb 1999 14:33:20 -0800 (PST) Received: by ec01-hou.bmc.com with Internet Mail Service (5.5.2232.9) id <1M9F823T>; Mon, 8 Feb 1999 16:33:17 -0600 Message-ID: From: "Heintz, Lauren" To: "'agentx@peer.com'" Subject: with change bars (RE-POST) Date: Mon, 8 Feb 1999 16:33:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Please disregard my previous postings regarding . ^^ The correct name is: ^^ I also had to update the first section boilerplate (hey, I'm new to this). Once I receive some comments as to the general worthiness of the below document, I shall re-post as an internet draft (no sense being rejected twice in same day!). Lauren ------------------------------------------------------------------------ INTERNET-DRAFT S. Gudur Independent Consultant L. Heintz BMC Software, Inc. 8 February 1999 Definitions of Managed Objects for Extensible SNMP Agents | Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects managing SNMP agents that use the Agent Extensibility (AgentX) Protocol. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. This memo does not specify a standard for the Internet community. AgentX Working Group Expires August 1999 [Page 1] Internet Draft AgentX MIB 8 February 1999 Table of Contents 1. The SNMP Management Framework ............................... 3 2. Introduction ................................................ 3 3. AgentX MIB Overview ......................................... 4 4. Managed Object Definitions for AgentX ....................... 6 5. Intellectual Property ....................................... 18 6. Acknowledgements ............................................ 18 7. Security Considerations ..................................... 19 8. References .................................................. 20 9. Editors' Addresses .......................................... 22 10. Full Copyright Statement ................................... 22 AgentX Working Group Expires August 1999 [Page 2] Internet Draft AgentX MIB 8 February 1999 1. The SNMP Management Framework The SNMP Network Management Framework presently consists of five major components: - An overall architecture, described in RFC 2271 [1] - Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. - Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. - Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. - A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. AgentX Working Group Expires August 1999 [Page 3] Internet Draft AgentX MIB 8 February 1999 2. Introduction The SNMP Agent Extensibility Protocol (AgentX) is a protocol used to distribute the implementation of an SNMP agent amongst a single "mas- ter agent" and multiple "subagents". See [16] for details about the AgentX protocol. The goals of the AgentX MIB are: - List the set of subagents that currently have logical sessions open with the master agent. - Identify each subagent's type, vendor, transport address, AgentX protocol version, and other characteristics. - Identify the set of MIB objects each subagent implements, the context in which the objects are registered, and the priority of the registration. - Determine protocol operational parameters such as the timeout interval for responses from a subagent and the priority at which a subagent registers a particular MIB region. - Allow (but do not require) managers to be able to modify AgentX protocol operational parameters and to explicitly close subagent sessions with the master agent. 3. AgentX MIB Overview This MIB is organized into four groups. The agentxGeneral group provides information describing the master agent's Agentx support, including the protocol version supported. The agentxConnection group provides information describing the current set of connections capable of carrying Agentx sessions. The agentxSession group provides information describing the current set of AgentX sessions. The agentxRegistration group provides information describing the current set of registrations. Three tables form the heart of this mib. These are the connection, session, and registration tables. Entries in the registration table exist in a many-to-one relationship with entries in the session table. This relationship is expressed through the two common indices, agentxSessionIndex and agentxConnIndex. Entries in the registration table also exist in a many-to-one relationship with entries in the connection table. This relationship is expressed through the common index, agentxConnIndex. AgentX Working Group Expires August 1999 [Page 4] Internet Draft AgentX MIB 8 February 1999 Entries in the session table exist in a many-to-one relationship with entries in the connection table. This relationship is expressed through the common index, agentxConnIndex. AgentX Working Group Expires August 1999 [Page 5] Internet Draft AgentX MIB 8 February 1999 4. Managed Object Definitions for AgentX AGENTX-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Unsigned32, mib-2 ! FROM SNMPv2-SMI SnmpAdminString FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION, TimeStamp, TruthValue, TDomain ! FROM SNMPv2-TC; agentxMIB MODULE-IDENTITY LAST-UPDATED "9902081200Z" -- February 8, 1999 ! ORGANIZATION "AgentX Working Group" CONTACT-INFO "WG-email: agentx@peer.com Subscribe: agentx-request@peer.com http://www.ietf.org/html.charters/agentx-charter.html Chair: Bob Natale ACE*COMM Corporation Email: bnatale@acecomm.com Co-editor: Smitha Gudur ! Independent Consultant ! Email: sgudur@hotmail.com ! Co-editor: Lauren Heintz ! postal: BMC Software, Inc. ! 965 Stewart Drive ! Sunnyvale, CA 94086 ! USA ! EMail: Lauren_Heintz@bmc.com ! Phone: +1 408-616-3169 ! " DESCRIPTION "This is the MIB module for the SNMP Agent Extensibility Protocol (AgentX). This MIB module will be implemented by the master agent. " ::= { mib-2 ? } -- To be assigned by IANA. ! AgentX Working Group Expires August 1999 [Page 6] Internet Draft AgentX MIB 8 February 1999 -- Textual Conventions AgentxTAddress ::= TEXTUAL-CONVENTION ! STATUS current ! DESCRIPTION ! "Denotes a transport service address. This is identical to ! the TAddress textual convention (SNMPv2-SMI) except that ! zero-length values are permitted. ! " ! SYNTAX OCTET STRING (SIZE (0..255)) -- Administrative assignments agentxObjects OBJECT IDENTIFIER ::= { agentxMIB 1 } agentxGeneral OBJECT IDENTIFIER ::= { agentxObjects 1 } agentxConnection OBJECT IDENTIFIER ::= { agentxObjects 2 } agentxSession OBJECT IDENTIFIER ::= { agentxObjects 3 } agentxRegistration OBJECT IDENTIFIER ::= { agentxObjects 4 } agentxDefaultTimeout OBJECT-TYPE SYNTAX INTEGER (0..255) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The default length of time, in seconds, that the master agent should allow to elapse after dispatching a message to a subagent before it regards the subagent as not responding. This is a system-wide value that may be overridden by the values associated with a particular subagent (agentxSessionTimeout) or a particular registered MIB region (agentxRegTimeout). " DEFVAL { 5 } ::= { agentxGeneral 1 } agentxMasterAgentXVer OBJECT-TYPE SYNTAX INTEGER (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The AgentX protocol version supported by this master agent. The current protocol version is 1. Note that the master agent must also allow registration of earlier version subagents. " ::= { agentxGeneral 2 } AgentX Working Group Expires August 1999 [Page 7] Internet Draft AgentX MIB 8 February 1999 -- The Agentx Subagent Connection Group agentxConnTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last row creation or deletion occurred in the agentxConnectionTable. " ::= { agentxConnection 1 } agentxConnectionTable OBJECT-TYPE SYNTAX SEQUENCE OF AgentxConnectionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The agentxConnectionTable tracks all current Agentx transport connections. There may be zero, one, or more agentx sessions carried on a given Agentx connection. " ::= { agentxConnection 2 } agentxConnectionEntry OBJECT-TYPE SYNTAX AgentxConnectionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An agentxConnectionEntry contains information describing a single Agentx transport connection. A connection may be used to support zero or more Agentx sessions. An entry is ! created when a new transport connection is established, ! and is destroyed when the transport connection is terminated. ! " INDEX { agentxConnIndex } ::= { agentxConnectionTable 1 } AgentxConnectionEntry ::= SEQUENCE { agentxConnIndex Unsigned32, agentxConnOpenTime TimeStamp, agentxConnTransportDomain TDomain, agentxConnTransportAddress AgentxTAddress } AgentX Working Group Expires August 1999 [Page 8] Internet Draft AgentX MIB 8 February 1999 agentxConnIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "agentxConnIndex contains the value that uniquely identifies an open transport connection used by this master agent to provide AgentX service. Values of this index should not be re-used. The value assigned to a given transport connection is constant for the lifetime of that connection. " ::= { agentxConnectionEntry 1 } agentxConnOpenTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this connection was established and, therefore, its value when this entry was added to the table. " ::= { agentxConnectionEntry 2 } agentxConnTransportDomain OBJECT-TYPE SYNTAX TDomain MAX-ACCESS read-only STATUS current DESCRIPTION "The transport protocol in use for this connection to the subagent. " ::= { agentxConnectionEntry 3 } agentxConnTransportAddress OBJECT-TYPE SYNTAX AgentxTAddress ! MAX-ACCESS read-only STATUS current DESCRIPTION "The transport address of the remote (subagent) end of this connection to the master agent. This object may be zero-length! for unix-domain sockets (and possibly other types of transport ! addresses) since the subagent need not bind a filename to its ! local socket. ! " ::= { agentxConnectionEntry 4 } AgentX Working Group Expires August 1999 [Page 9] Internet Draft AgentX MIB 8 February 1999 -- The AgentX Subagent Session Group agentxSessionTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last row creation or deletion occurred in the agentxSessionTable. " ::= { agentxSession 1 } agentxSessionTable OBJECT-TYPE SYNTAX SEQUENCE OF AgentxSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of AgentX subagent sessions currently in effect. " ::= { agentxSession 2 } ! agentxSessionEntry OBJECT-TYPE SYNTAX AgentxSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single open session between the AgentX master agent and a subagent is contained in this entry. An entry is created when a new session is successfully established! and is destroyed either when the parent transport connection ! has terminated or when the session is closed. ! " INDEX { agentxConnIndex, agentxSessionIndex } ::= { agentxSessionTable 1 } AgentxSessionEntry ::= SEQUENCE { agentxSessionIndex Unsigned32, agentxSessionObjectID OBJECT IDENTIFIER, agentxSessionDescr SnmpAdminString, agentxSessionAdminStatus INTEGER, agentxSessionOpenTime TimeStamp, agentxSessionAgentXVer INTEGER, agentxSessionTimeout INTEGER } AgentX Working Group Expires August 1999 [Page 10] Internet Draft AgentX MIB 8 February 1999 agentxSessionIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index for the subagent session. It is the same as h.sessionID defined in the agentx header. Note that if a subagent's session with the master agent is closed for any reason its index should not be re-used, therefore, the values of agentxSessionIndex may be discontiguous and will generally not be the same for the same subagent across multiple sessions. " ::= { agentxSessionEntry 1 } agentxSessionObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "This is taken from the o.id field of the agentx-Open-PDU. " ::= { agentxSessionEntry 2 } agentxSessionDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the subagent. This is analogous to sysDescr defined in MIB-2 [2] and is taken from the o.descr field of the agentx-Open-PDU. " ::= { agentxSessionEntry 3 } agentxSessionAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The administrative (desired) status of the subagent. Setting the value to 'down(2)' closes the subagent session (with c.reason set to 'reasonByManager'). " ::= { agentxSessionEntry 4 } AgentX Working Group Expires August 1999 [Page 11] Internet Draft AgentX MIB 8 February 1999 agentxSessionOpenTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this session was opened and, therefore, its value when this entry was added to the table. " ::= { agentxSessionEntry 5 } agentxSessionAgentXVer OBJECT-TYPE SYNTAX INTEGER (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The version of the AgentX protocol supported by the subagent. This will be less than or equal to the value of agentxMasterAgentXVer. " ::= { agentxSessionEntry 6 } agentxSessionTimeout OBJECT-TYPE SYNTAX INTEGER (0..255) UNITS "seconds" MAX-ACCESS read-only STATUS current DESCRIPTION "The length of time, in seconds, that a master agent should allow to elapse after dispatching a message to this subagent before it regards the subagent as not responding. This value is taken from the o.timeout field of the agentx-Open-PDU. This is a subagent-specific value that may be overridden by values associated with specific registered MIB regions (see agentxRegTimeout). The default value of zero indicates that the master agent's default timeout value should be used (see agentxDefaultTimeout). " ::= { agentxSessionEntry 7 } AgentX Working Group Expires August 1999 [Page 12] Internet Draft AgentX MIB 8 February 1999 -- The AgentX Registration Group agentxRegisterDuplicate OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages sent by this master agent where the res.error field was set to 'duplicateRegistration'. " ::= { agentxRegistration 1 } agentxRegistrationTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last row creation or deletion occurred in the agentxRegistrationTable. " ::= { agentxRegistration 2 } agentxRegistrationTable OBJECT-TYPE SYNTAX SEQUENCE OF AgentxRegistrationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of registered regions. ! " ! ::= { agentxRegistration 3 } agentxRegistrationEntry OBJECT-TYPE SYNTAX AgentxRegistrationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains information for a single registered region. An ! entry is created when a subagent successfully registers a ! region and is destroyed for any of three reasons: this region ! is unregistered by the subagent, the parent session is closed, ! or the parent connection is closed. ! " ! INDEX { agentxConnIndex, agentxSessionIndex, agentxRegIndex } ::= { agentxRegistrationTable 1 } AgentX Working Group Expires August 1999 [Page 13] Internet Draft AgentX MIB 8 February 1999 AgentxRegistrationEntry ::= SEQUENCE { agentxRegIndex Unsigned32, agentxRegContext OCTET STRING, agentxRegStart OBJECT IDENTIFIER, agentxRegRangeSubId Unsigned32, ! agentxRegUpperBound Unsigned32, ! agentxRegPriority Unsigned32, agentxRegTimeout INTEGER, agentxRegInstance TruthValue } agentxRegIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "agentxRegIndex uniquely identifies a registration entry. This value is constant for the lifetime of an entry. " ::= { agentxRegistrationEntry 1 } agentxRegContext OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The context in which the subagent supports the objects in this region. A zero-length context indicates the default context. " ::= { agentxRegistrationEntry 2 } agentxRegStart OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The starting OBJECT IDENTIFIER of this registration entry. The subagent identified by agentxSessionIndex implements objects starting at this value (inclusive). Note that this value could identify an object type, an object instance, or a partial object instance. " ::= { agentxRegistrationEntry 3 } AgentX Working Group Expires August 1999 [Page 14] Internet Draft AgentX MIB 8 February 1999 agentxRegRangeSubId OBJECT-TYPE SYNTAX Unsigned32 ! MAX-ACCESS read-only STATUS current DESCRIPTION "agentxRegRangeSubId is used to specify the range. This is taken from r.region_subid in the registration PDU. If the value of this object is zero, no range is specified. If it is non-zero, it identifies the "nth" sub-identifier in r.region for which this entry's agentxRegUpperBound value is substituted in the OID for purposes of defining the region's upper bound. " ::= { agentxRegistrationEntry 4 } agentxRegUpperBound OBJECT-TYPE ! SYNTAX Unsigned32 ! MAX-ACCESS read-only ! STATUS current ! DESCRIPTION ! "agentxRegUpperBound represents the upper-bound sub-identifier in! a registration. This is taken from the r.upper_bound in the ! registration PDU. If agentxRegRangeSubid (r.region_subid) is ! zero, this value is also zero and is not used to define an upper! bound for this registration. ! " ! ::= { agentxRegistrationEntry 5 } ! agentxRegPriority OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The subagent's priority when exporting this OID range. Lower values have higher priority. " ::= { agentxRegistrationEntry 6 } agentxRegTimeout OBJECT-TYPE SYNTAX INTEGER (0..255) UNITS "seconds" MAX-ACCESS read-only STATUS current AgentX Working Group Expires August 1999 [Page 15] Internet Draft AgentX MIB 8 February 1999 DESCRIPTION "The timeout value, in seconds, for subagent responses to requests associated with this OID range. A value of zero indicates the default value (indicated by agentxSessionTimeout or agentxDefaultTimeout) is to be used. This value is taken from the r.timeout field of the agentx-Register-PDU. " ::= { agentxRegistrationEntry 7 } agentxRegInstance OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The value of agentxRegInstance is `true' for registrations for which the INSTANCE_REGISTRATION was set, and is `false' for all other registrations. " ::= { agentxRegistrationEntry 8 } -- Conformance Statements for AgentX agentxConformance OBJECT IDENTIFIER ::= { agentxMIB 2 } agentxMIBGroups OBJECT IDENTIFIER ::= { agentxConformance 1 } agentxMIBCompliances OBJECT IDENTIFIER ::= { agentxConformance 2 } -- Compliance Statements for AgentX agentxMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the AgentX protocol. Note that a compliant agent can implement all objects in this MIB module as read-only. " MODULE -- this module MANDATORY-GROUPS { agentxMIBGroup } OBJECT agentxDefaultTimeout MIN-ACCESS read-only DESCRIPTION "Write access is not required. " AgentX Working Group Expires August 1999 [Page 16] Internet Draft AgentX MIB 8 February 1999 OBJECT agentxSessionAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required. " ::= { agentxMIBCompliances 1 } agentxMIBGroup OBJECT-GROUP OBJECTS { agentxDefaultTimeout, agentxMasterAgentXVer, agentxConnTableLastChange, ! agentxConnOpenTime, agentxConnTransportDomain, agentxConnTransportAddress, agentxSessionTableLastChange, agentxSessionTimeout, agentxSessionObjectID, agentxSessionDescr, agentxSessionAdminStatus, agentxSessionOpenTime, agentxSessionAgentXVer, agentxRegisterDuplicate, agentxRegistrationTableLastChange, agentxRegContext, agentxRegStart, agentxRegRangeSubId, agentxRegUpperBound, agentxRegPriority, agentxRegTimeout, agentxRegInstance } STATUS current DESCRIPTION "All accessible objects in the AgentX MIB. " ::= { agentxMIBGroups 1 } END AgentX Working Group Expires August 1999 [Page 17] Internet Draft AgentX MIB 8 February 1999 5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 6. Acknowledgements This document is the result of the efforts of the IETF AgentX Working Group (WG). This MIB is an evolution of the Subagent MIB by Bert Wijnen (wijnen@vnet.ibm.com) which in turn was derived from the SMUX-MIB by Marshall Rose [17]. Thanks are in order to the following AgentX WG members: Mike Daniele (Compaq Computer Corporation) Dale Francisco (Cisco Systems) Bob Natale (ACE*COMM Corporation) Randy Presuhn (BMC Software, Inc.) Shawn Routhier (Epilogue) Mike Thatcher (Independent Consultant) Special acknowledgement is made to: Maria Greene (Xedia) AgentX Working Group Expires August 1999 [Page 18] Internet Draft AgentX MIB 8 February 1999 Special acknowledgement is also made to the following individuals for participating in the 1998 Agentx testing summit (bakeoff) held in Sunnyvale, California: Mike Daniele (Compaq Computer Corporation) Jeff Case (SNMP Research, Inc.) Mark Ellison (Independent Consultant) Lauren Heintz (BMC Software, Inc.) Verne Hyde (Independent Consultant) Bob Natale (ACE*COMM Corporation) Shawn Routhier (Epilogue) Mike Thatcher (Independent Consultant) Bert Wijnen (IBM T. J. Watson Research Center) 7. Security Considerations In most cases, MIBs are not themselves security risks; if SNMP security is operating as intended, the use of a MIB to view information about a system, or to change some parameter at the system, is a tool, not a threat. None of the read-only objects in this MIB reports a password, user data, or anything else that is particularly sensitive. If access to these objects is not limited by an appropriate access control policy, these objects can provide an attacker with information about a system's configuration and the services that that system is providing. Some enterprises view their network and system configurations themselves, as well as information about usage and performance, as corporate assets; such enterprises may wish to restrict SNMP access to most of the objects in the MIB. This MIB contains two read-write objects: agentxDefaultTimeout and agentxSessionAdminStatus. Setting agentxDefaultTimeout to an inappropriately small value can prevent new subagent sessions from being usable. Setting agentxSessionAdminStatus to an inappropriate value can effectively prevent access to management information, or provide access to inappropriate information. Since changes to either of these objects can adversely impact the manageability of a system, write access to these objects should be subject to an appropriate access control policy. Such a policy may be realized in an implementation by limiting support for these objects to read-only access. AgentX Working Group Expires August 1999 [Page 19] Internet Draft AgentX MIB 8 February 1999 8. References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998 [2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991 [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991 [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Proto- col (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, Jan- uary 1996. [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. AgentX Working Group Expires August 1999 [Page 20] Internet Draft AgentX MIB 8 February 1999 [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Trans- port Mappings for Version 2 of the Simple Network Management Pro- tocol (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Ser- vices, January 1996. [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, IBM T. J. Watson Research, January 1998. [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco Systems, January 1998 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., Cisco Systems, Inc., January 1998 [16] Daniele, M., Wijnen, B., and D. Francisco, "Agent Extensibility (AgentX) Protocol, Version 1", draft-ietf-agentx-ext-pro-02.txt, Digital Equipment Corporation, T.J. Watson Research Center, IBM Corp., Cisco Systems, November, 1996. [17] Rose, M., "SNMP MUX Protocol and MIB", RFC1227, Performance Systems International, May 1991. AgentX Working Group Expires August 1999 [Page 21] Internet Draft AgentX MIB 8 February 1999 9. Editors' Addresses Smitha Gudur Independent Consultant EMail: sgudur@hotmail.com Lauren Heintz BMC Software, Inc 965 Stewart Drive Sunnyvale, CA 94086 USA Phone: +1 408-616-3169 Fax: +1 408-616-3101 EMail: Lauren_Heintz@bmc.com 10. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. AgentX Working Group Expires August 1999 [Page 22] From daniele@zk3.dec.com Mon Feb 15 15:31:25 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA07862 for ; Mon, 15 Feb 1999 15:31:24 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA05611; Mon, 15 Feb 1999 14:28:44 -0600 (CST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA13422 for ; Mon, 15 Feb 1999 12:22:31 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id OAA04674 for ; Mon, 15 Feb 1999 14:22:29 -0600 (CST) Received: from iota.zk3.dec.com (riota.zk3.dec.com [16.140.64.227]) by mail13.digital.com (8.9.1a/8.9.1/WV2.0d) with ESMTP id PAA29462 for ; Mon, 15 Feb 1999 15:22:26 -0500 (EST) Received: from zk3.dec.com by iota.zk3.dec.com (8.8.8/1.1.20.3/24Apr98-0811AM) id PAA0000017183; Mon, 15 Feb 1999 15:22:18 -0500 (EST) Sender: daniele@zk3.dec.com Message-ID: <36C8810D.89B0D5@zk3.dec.com> Date: Mon, 15 Feb 1999 15:18:21 -0500 From: Mike Daniele Organization: Compaq 64-bit UNIX networking X-Mailer: Mozilla 4.5 [en] (X11; I; OSF1 X5.0 alpha) X-Accept-Language: en MIME-Version: 1.0 To: AgentX WG Subject: Testing, and Bakeoff II? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello AgentX-ers, At Compaq we'd like to do more testing with other vendors' implementations. In the past we've done this via the internet, or by downloading code that can be built and run on our unix platform. Both have been very beneficial and are relatively easy to accomplish. Please send me mail if you'd be interested in either of these. Also, we'd be happy to host a bakeoff here in Nashua, NH. Regards, Mike From owner-agentx@dorothy.bmc.com Sun Feb 21 14:14:09 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03423 for ; Sun, 21 Feb 1999 14:14:08 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA09835; Sun, 21 Feb 1999 13:11:32 -0600 (CST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA16135 for ; Sun, 21 Feb 1999 11:01:58 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id NAA04401; Sun, 21 Feb 1999 13:01:56 -0600 (CST) Received: from ieee.org (pm2b-42.dialup.jlc.net [199.201.159.42]) by verdi.jlc.net (8.8.8/8.8.8) with ESMTP id JAA09857; Sun, 21 Feb 1999 09:26:42 -0500 (EST) (envelope-from ellison@ieee.org) Message-ID: <36D017AF.B49EC91A@ieee.org> Date: Sun, 21 Feb 1999 09:26:55 -0500 From: Mark Ellison Reply-To: ellison@ieee.org Organization: Ellison Software Consulting, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Heintz, Lauren" CC: "'agentx@peer.com'" , Mark Ellison , Mike Daniele Subject: Re: with change bars (RE-POST) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Lauren Here is some feedback draft-ietf-agentx-mib-03.txt. These notes reflect a contribution from both myself and from Mike Daniele. Regards, Mark ================================================================= general conmments: - check capitalization on "AgentX". The draft contains "Agentx", "AgentX", and "agentx". p.7 agentxDefaultTimeout What are the semantics associated with a value of zero? Would it be "don't timeout"? Or would this attribute be better defined with a range of 1..255? p.9 agentxConnTransportDomain Where are possible values listed? A reference to an RFC or Internet Draft might be good. p.11 agentxSessionIndex I'd suggest "...its index should not be re-used..." be replaced with "...its index shall not be re-used...". Also, I have some difficulty understanding the last part of the last sentence, "...the values of agentxSessionIndex my be discontiguous and will not be the same for the same subagenet across multiple sessions." Possibly the use of the word `session' is not the AgentX sense of session (something which is assigned an h.sessionID). If that is what is going on here, probably change the last word in the sentence, from `sessions' to `invocations' or `process invocations' or something similar. p.11 agentxSessionObjectID Please add: "This attribute will report a value "0.0" for subagents not supporting the notion of an objectID. p.11 agentxSessionDescr Please add: "This attribute will report a value a value of the zero-length string for subagents not supporting the notion of a session description. p.12 agentxSessionAgentXVer Consider change from: "This will be less..." to: "This must be less..." p.13 agentxRegisterDuplicate This attribute belongs in the AgentXRegistrationEntry, and should be incremented whenever a received registration is determined to be a `duplicate' of this region. Putting this attribute in the registration table would provide better information about registration "hot spots". p.15 agentxRegPriority I think the WG had agreed upon using a default value for this attribute- but forget if the actual value was 127 or 128...please state the default value for this attribute. p.16 Conformance statements These look good. p.18 Security Considerations This section might have to be revamped to the SNMPv3 template, as this is what IESG seems to want these days. From owner-agentx@dorothy.bmc.com Tue Mar 2 14:50:14 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09803 for ; Tue, 2 Mar 1999 14:50:14 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA02768; Tue, 2 Mar 1999 13:33:11 -0600 (CST) Received: from ec01-hou.bmc.com (ec01-hou.bmc.com [172.17.0.150]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA05304 for ; Tue, 2 Mar 1999 11:25:25 -0800 (PST) Received: by ec01-hou.bmc.com with Internet Mail Service (5.5.2448.0) id ; Tue, 2 Mar 1999 13:25:24 -0600 Message-ID: From: "Heintz, Lauren" To: "'ellison@ieee.org'" Cc: "'agentx@peer.com'" Subject: RE: with change bars (RE-POST) Date: Tue, 2 Mar 1999 13:25:38 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Comments follow.... Lauren > -----Original Message----- > From: Mark Ellison [mailto:ellison@ieee.org] > general conmments: > > - check capitalization on "AgentX". > The draft contains "Agentx", "AgentX", and "agentx". Done. Changed all non-object refs to "AgentX". > p.7 agentxDefaultTimeout > > What are the semantics associated with a value of zero? > Would it be "don't timeout"? Or would this attribute > be better defined with a range of 1..255? Done. 0 now means "don't timeout". > p.9 agentxConnTransportDomain > > Where are possible values listed? A reference to an > RFC or Internet Draft might be good. I've checked other SNMPv3 docs containing similar constructs and have not found explicit references to any docs that contain possible TDomain values. Indeed, the purpose of TDomain is to allow new (unanticipated) TDomain values to be defined any time new standards are created without obsoleting older ones. It is thus very difficult to reference documents that haven't been written yet. :-) Also, I think it was determined at the Chicago AgentX WG that these new TDomain values would be defined within a separate draft, proposed I think, by Mike D. I'm not sure any possible values have even been defined yet anyway. However, if someone provides suggested text regarding this issue, I will be happy to add it. > p.11 agentxSessionIndex > > I'd suggest "...its index should not be re-used..." be > replaced with "...its index shall not be re-used...". > Also, I have some difficulty understanding the last > part of the last sentence, "...the values of > agentxSessionIndex my be discontiguous and will not > be the same for the same subagenet across multiple > sessions." Possibly the use of the word `session' > is not the AgentX sense of session (something which > is assigned an h.sessionID). If that is what is > going on here, probably change the last word in the > sentence, from `sessions' to `invocations' or > `process invocations' or something similar. I'm not even sure of the intended value of the last phrase of that sentence, so I propose to delete that confusing phrase so the sentence simply reads: "Note that if a subagent's session with the master agent is closed for any reason, its index shall not be re-used." Done (pending objections to the above proposal). > p.11 agentxSessionObjectID > > Please add: "This attribute will report a > value "0.0" for subagents not supporting the > notion of an objectID. Done. > p.11 agentxSessionDescr > > Please add: "This attribute will report a value > a value of the zero-length string for subagents > not supporting the notion of a session description. Done. > p.12 agentxSessionAgentXVer > > Consider change from: "This will be less..." > to: "This must be less..." Done. > p.13 agentxRegisterDuplicate > > This attribute belongs in the AgentXRegistrationEntry, > and should be incremented whenever a received registration > is determined to be a `duplicate' of this region. > Putting this attribute in the registration table would > provide better information about registration "hot spots". I don't have a problem with this if no strong objections are heard. Any objections? However, considering that a given entry "belongs" to a given subagent, how likely is it that the given subagent may choose to disconnect (with the AgentxRegistrationEntry containing the incremented duplicate variable thus being deleted) rather than adjust to the failed registration. If likely or common, moving the duplicate variable to the entry may be undesirable. > p.15 agentxRegPriority > > I think the WG had agreed upon using a default value for > this attribute- but forget if the actual value was 127 > or 128...please state the default value for this attribute. Done (127). > p.18 Security Considerations > > This section might have to be revamped to the SNMPv3 template, > as this is what IESG seems to want these days. I'll work on this and everyone will have a chance to review the security modifications when I finish and re-post the draft to the list. ------------------------------------------------------------------------- Lauren Heintz BMC Software, Inc. (Formerly PEER Networks) Voice: +1 408 616-3169 Silicon Valley Division Fax: +1 408 616-3339 965 Stewart Drive Email: Lauren_Heintz@bmc.com Sunnyvale, California 94086 USA ------------------------------------------------------------------------- From owner-agentx@dorothy.bmc.com Tue Mar 2 15:14:24 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10450 for ; Tue, 2 Mar 1999 15:14:23 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA09913; Tue, 2 Mar 1999 14:11:23 -0600 (CST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA05451 for ; Tue, 2 Mar 1999 12:08:30 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id OAA09381; Tue, 2 Mar 1999 14:08:28 -0600 (CST) Received: from sigma.zk3.dec.com (rsigma.zk3.dec.com [16.140.64.171]) by mail13.digital.com (8.9.2/8.9.2/WV2.0e) with ESMTP id PAA01337; Tue, 2 Mar 1999 15:08:26 -0500 (EST) Received: from zk3.dec.com by sigma.zk3.dec.com (8.8.8/1.1.20.3/24Apr98-0811AM) id PAA0000014640; Tue, 2 Mar 1999 15:08:25 -0500 (EST) Sender: daniele@zk3.dec.com Message-ID: <36DC443D.AA69DEF6@zk3.dec.com> Date: Tue, 02 Mar 1999 15:04:13 -0500 From: Mike Daniele Organization: Compaq 64-bit UNIX networking X-Mailer: Mozilla 4.5 [en] (X11; I; OSF1 X5.0 alpha) X-Accept-Language: en MIME-Version: 1.0 To: "Heintz, Lauren" CC: "'ellison@ieee.org'" , "'agentx@peer.com'" Subject: Re: with change bars (RE-POST) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Lauren, Thanks for the updates. > > > p.9 agentxConnTransportDomain > > > > Where are possible values listed? A reference to an > > RFC or Internet Draft might be good. > > I've checked other SNMPv3 docs containing similar constructs and have not > found explicit references to any docs that contain possible TDomain values. > Indeed, the purpose of TDomain is to allow new (unanticipated) TDomain > values to be defined any time new standards are created without obsoleting > older ones. It is thus very difficult to reference documents that haven't > been written yet. :-) Also, I think it was determined at the Chicago > AgentX WG that these new TDomain values would be defined within a separate > draft, proposed I think, by Mike D. I'm not sure any possible values have > even been defined yet anyway. However, if someone provides suggested text > regarding this issue, I will be happy to add it. > I agree there aren't RFCs to quote. The values we need for AgentX do have to be defined somewhere, and as you note we had talked about doing that not in the AgentX MIB but in a different document. The issue of what to use to represent general addresses has come up to IESG and I think Bert is going to put it on the new list of things for the SNMPv3 WG to do that aren't really SNMPv3. Not sure if anything will happen soon enough to help us here. > > > p.13 agentxRegisterDuplicate > > > > This attribute belongs in the AgentXRegistrationEntry, > > and should be incremented whenever a received registration > > is determined to be a `duplicate' of this region. > > Putting this attribute in the registration table would > > provide better information about registration "hot spots". > > I don't have a problem with this if no strong objections are heard. Any > objections? However, considering that a given entry "belongs" to a given > subagent, how likely is it that the given subagent may choose to disconnect > (with the AgentxRegistrationEntry containing the incremented duplicate > variable thus being deleted) rather than adjust to the failed registration. > If likely or common, moving the duplicate variable to the entry may be > undesirable. > If session A registers foo then later session B also registers foo and receives the duplicateRegistration error, then the MIB counter in the AgentXRegistrationEntry corresponding to A's registration of foo would be the one that gets bumped. A doesn't need to adjust to anything. That is, the object counts the number of times other registration requests were refused as duplicates of this registration. At least that's what I think would be useful. Regards, Mike From owner-agentx@dorothy.bmc.com Tue Mar 2 15:37:19 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10963 for ; Tue, 2 Mar 1999 15:37:18 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA14376; Tue, 2 Mar 1999 14:34:32 -0600 (CST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA05505 for ; Tue, 2 Mar 1999 12:31:12 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id OAA13671; Tue, 2 Mar 1999 14:31:10 -0600 (CST) Received: from [192.152.208.5] (helo=acecomm.com) by relay2.smtp.psi.net with smtp (Exim 1.90 #1) id 10Hvoq-00047D-00; Tue, 2 Mar 1999 15:31:08 -0500 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA24788; Tue, 2 Mar 1999 15:34:07 -0500 Message-Id: <4.1.19990302152902.00ad4190@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 02 Mar 1999 15:33:29 -0500 To: Mike Daniele From: Bob Natale Subject: Re: duplicateRegistrations Cc: Lauren_Heintz@ec01-hou.bmc.com, ellison@ieee.org, agentx@dorothy.bmc.com In-Reply-To: <36DC443D.AA69DEF6@zk3.dec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 3/2/99:03:04 PM, Mike Daniele wrote: Hi Mike, >Hi Lauren, > >Thanks for the updates. Yes, thanks Lauren, we'll try to build some momentum off of this now. >> > p.13 agentxRegisterDuplicate <...> >If session A registers foo then later session B also registers foo >and receives the duplicateRegistration error, then the MIB counter >in the AgentXRegistrationEntry corresponding to A's registration of >foo would be the one that gets bumped. A doesn't need to adjust to >anything. > >That is, the object counts the number of times other registration >requests were refused as duplicates of this registration. > >At least that's what I think would be useful. Yep...that's my understanding too. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From owner-agentx@dorothy.bmc.com Thu Mar 4 20:08:15 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19896 for ; Thu, 4 Mar 1999 20:08:14 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id TAA05545; Thu, 4 Mar 1999 19:05:37 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA09573 for agentx-list; Thu, 4 Mar 1999 16:58:07 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA09567 for agentx@peer.com; Thu, 4 Mar 1999 16:58:03 -0800 (PST) Date: Thu, 4 Mar 1999 16:58:03 -0800 (PST) From: Randy Presuhn Message-Id: <199903050058.QAA09567@dorothy.bmc.com> To: agentx@dorothy.bmc.com Subject: AgentX list changes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi - The agentx mailing list has been cut over to a Majordomo list server. Subscription requests are still manually approved. Spam filters are enabled, and only list members and known subscribers to sub-lists are allowed to post. Other postings may be delayed until the poster can be added to the list of permitted posters. If you have problems, please contact me or Lauren Heintz, lheintz@bmc.com. Summary: to post: agentx@peer.com (unchanged) to subscribe: agentx-request@peer.com (unchanged) to unsubscribe: agentx-request@peer.com (unchanged) ----------------------------------------------------------------------- Randy Presuhn rpresuhn@dorothy.bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- Any relationship between my opinions and BMC's is coincidental. ----------------------------------------------------------------------- From owner-agentx@dorothy.bmc.com Fri Mar 5 21:19:27 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11597 for ; Fri, 5 Mar 1999 21:19:27 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id UAA20371; Fri, 5 Mar 1999 20:16:35 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA20422 for agentx-list; Fri, 5 Mar 1999 18:13:06 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA20408 for agentx@dorothy.bmc.com; Fri, 5 Mar 1999 18:12:58 -0800 (PST) Date: Fri, 5 Mar 1999 18:12:58 -0800 (PST) From: Randy Presuhn Message-Id: <199903060212.SAA20408@dorothy.bmc.com> To: agentx@dorothy.bmc.com Subject: RE: with change bars (RE-POST) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi - > From: "Heintz, Lauren" > To: "'ellison@ieee.org'" > Cc: "'agentx@peer.com'" > Subject: RE: with change bars (RE-POST) > Date: Tue, 2 Mar 1999 13:25:38 -0600 ... > > p.11 agentxSessionIndex > > > > I'd suggest "...its index should not be re-used..." be > > replaced with "...its index shall not be re-used...". > > Also, I have some difficulty understanding the last > > part of the last sentence, "...the values of > > agentxSessionIndex my be discontiguous and will not > > be the same for the same subagenet across multiple > > sessions." Possibly the use of the word `session' > > is not the AgentX sense of session (something which > > is assigned an h.sessionID). If that is what is > > going on here, probably change the last word in the > > sentence, from `sessions' to `invocations' or > > `process invocations' or something similar. > > > I'm not even sure of the intended value of the last phrase of that sentence, > so I propose to delete that confusing phrase so the sentence simply reads: > "Note that if a subagent's session with the master agent is closed for any > reason, its index shall not be re-used." > > Done (pending objections to the above proposal). I object. "Shall" is the wrong word to use. See RFC 2119 section 6. Non-reuse of indexes is not required for the protocol to work. However, non-reuse is a good idea, but cannot be avoided if an agent stays up long enough. "Should" is the correct word. ... > > p.13 agentxRegisterDuplicate > > > > This attribute belongs in the AgentXRegistrationEntry, > > and should be incremented whenever a received registration "should be" -> "is" > > is determined to be a `duplicate' of this region. > > Putting this attribute in the registration table would > > provide better information about registration "hot spots". > > > I don't have a problem with this if no strong objections are heard. Any > objections? However, considering that a given entry "belongs" to a given > subagent, how likely is it that the given subagent may choose to disconnect > (with the AgentxRegistrationEntry containing the incremented duplicate > variable thus being deleted) rather than adjust to the failed registration. > If likely or common, moving the duplicate variable to the entry may be > undesirable. ... It sounds like this behaviour would only be useful with extremely robust (recovering from duplicate registration) or extremely sloppy (not checking duplicate registration) subagents. Those that just mutter "configuration error" and quit would derive no benefit here. ----------------------------------------------------------------------- Randy Presuhn rpresuhn@dorothy.bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- Any relationship between my opinions and BMC's is coincidental. ----------------------------------------------------------------------- From owner-agentx@dorothy.bmc.com Tue Mar 9 13:01:13 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16789 for ; Tue, 9 Mar 1999 13:01:12 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA11077; Tue, 9 Mar 1999 11:53:29 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id JAA13902 for agentx-list; Tue, 9 Mar 1999 09:37:02 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id JAA13896 for ; Tue, 9 Mar 1999 09:36:47 -0800 (PST) Received: from ec01-hou.bmc.com (ec01-hou.bmc.com [172.17.0.150]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id LAA08231 for ; Tue, 9 Mar 1999 11:36:45 -0600 (CST) Received: by ec01-hou.bmc.com with Internet Mail Service (5.5.2448.0) id ; Tue, 9 Mar 1999 11:36:45 -0600 Message-ID: From: "Heintz, Lauren" To: "'agentx@peer.com'" Subject: AgentX MIB Draft with change bars Date: Tue, 9 Mar 1999 11:37:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Here is the latest attempt at the AgentX MIB. It includes change bars for the most important changes made since the last posting a few weeks ago. As of now, I know of no open issues regarding this document. Lauren ------------------------------------------------------------------------- Lauren Heintz BMC Software, Inc. (Formerly PEER Networks) Voice: +1 408 616-3169 Silicon Valley Division Fax: +1 408 616-3339 965 Stewart Drive Email: Lauren_Heintz@bmc.com Sunnyvale, California 94086 USA ------------------------------------------------------------------------- INTERNET-DRAFT S. Gudur Independent Consultant L. Heintz BMC Software, Inc. 9 March 1999 Definitions of Managed Objects for Extensible SNMP Agents Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects managing SNMP agents that use the Agent Extensibility (AgentX) Protocol. This memo specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. This memo does not specify a standard for the Internet community. AgentX Working Group Expires September 1999 [Page 1] Internet Draft AgentX MIB 9 March 1999 Table of Contents 1. The SNMP Management Framework ............................... 3 2. Introduction ................................................ 3 3. AgentX MIB Overview ......................................... 4 4. Managed Object Definitions for AgentX ....................... 6 5. Intellectual Property ....................................... 18 6. Acknowledgements ............................................ 18 7. Security Considerations ..................................... 19 8. References .................................................. 21 9. Editors' Addresses .......................................... 23 10. Full Copyright Statement ................................... 23 AgentX Working Group Expires September 1999 [Page 2] Internet Draft AgentX MIB 9 March 1999 1. The SNMP Management Framework The SNMP Network Management Framework presently consists of five major components: - An overall architecture, described in RFC 2271 [1] - Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC 1904 [7]. - Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12]. - Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13]. - A set of fundamental applications described in RFC 2273 [14] and the view-based access control mechanism described in RFC 2275 [15]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB. AgentX Working Group Expires September 1999 [Page 3] Internet Draft AgentX MIB 9 March 1999 2. Introduction The SNMP Agent Extensibility Protocol (AgentX) is a protocol used to distribute the implementation of an SNMP agent amongst a single "mas- ter agent" and multiple "subagents". See [16] for details about the AgentX protocol. The goals of the AgentX MIB are: - List the set of subagents that currently have logical sessions open with the master agent. - Identify each subagent's type, vendor, transport address, AgentX protocol version, and other characteristics. - Identify the set of MIB objects each subagent implements, the context in which the objects are registered, and the priority of the registration. - Determine protocol operational parameters such as the timeout interval for responses from a subagent and the priority at which a subagent registers a particular MIB region. - Allow (but do not require) managers to be able to modify AgentX protocol operational parameters and to explicitly close subagent sessions with the master agent. 3. AgentX MIB Overview This MIB is organized into four groups. The agentxGeneral group provides information describing the master agent's AgentX support, including the protocol version supported. The agentxConnection group provides information describing the current set of connections capable of carrying AgentX sessions. The agentxSession group provides information describing the current set of AgentX sessions. The agentxRegistration group provides information describing the current set of registrations. Three tables form the heart of this mib. These are the connection, session, and registration tables. Entries in the registration table exist in a many-to-one relationship with entries in the session table. This relationship is expressed through the two common indices, agentxSessionIndex and agentxConnIndex. Entries in the registration table also exist in a many-to-one relationship with entries in the connection table. This relationship is expressed through the common index, agentxConnIndex. AgentX Working Group Expires September 1999 [Page 4] Internet Draft AgentX MIB 9 March 1999 Entries in the session table exist in a many-to-one relationship with entries in the connection table. This relationship is expressed through the common index, agentxConnIndex. AgentX Working Group Expires September 1999 [Page 5] Internet Draft AgentX MIB 9 March 1999 4. Managed Object Definitions for AgentX AGENTX-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Counter32, Unsigned32, mib-2 FROM SNMPv2-SMI SnmpAdminString FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION, TimeStamp, TruthValue, TDomain FROM SNMPv2-TC; agentxMIB MODULE-IDENTITY LAST-UPDATED "9902081200Z" -- February 8, 1999 ORGANIZATION "AgentX Working Group" CONTACT-INFO "WG-email: agentx@peer.com Subscribe: agentx-request@peer.com http://www.ietf.org/html.charters/agentx-charter.html Chair: Bob Natale ACE*COMM Corporation Email: bnatale@acecomm.com Co-editor: Smitha Gudur Independent Consultant Email: sgudur@hotmail.com Co-editor: Lauren Heintz postal: BMC Software, Inc. 965 Stewart Drive Sunnyvale, CA 94086 USA EMail: Lauren_Heintz@bmc.com Phone: +1 408-616-3169 " DESCRIPTION "This is the MIB module for the SNMP Agent Extensibility Protocol (AgentX). This MIB module will be implemented by the master agent. " ::= { mib-2 ? } -- To be assigned by IANA. AgentX Working Group Expires September 1999 [Page 6] Internet Draft AgentX MIB 9 March 1999 -- Textual Conventions AgentxTAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Denotes a transport service address. This is identical to the TAddress textual convention (SNMPv2-SMI) except that zero-length values are permitted. " SYNTAX OCTET STRING (SIZE (0..255)) -- Administrative assignments agentxObjects OBJECT IDENTIFIER ::= { agentxMIB 1 } agentxGeneral OBJECT IDENTIFIER ::= { agentxObjects 1 } agentxConnection OBJECT IDENTIFIER ::= { agentxObjects 2 } agentxSession OBJECT IDENTIFIER ::= { agentxObjects 3 } agentxRegistration OBJECT IDENTIFIER ::= { agentxObjects 4 } agentxDefaultTimeout OBJECT-TYPE SYNTAX INTEGER (0..255) UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The default length of time, in seconds, that the master agent should allow to elapse after dispatching a message to a subagent before it regards the subagent as not responding. This is a system-wide value that may be overridden by the values associated with a particular subagent (agentxSessionTimeout) or a particular registered MIB region (agentxRegTimeout). If the associated values of ! agentxSessionTimeout, agentxRegTimeout and agentxDefaultTimeout! all are zero, the master agent will not timeout while awaiting ! a response from the subagent. ! " DEFVAL { 5 } ::= { agentxGeneral 1 } AgentX Working Group Expires September 1999 [Page 7] Internet Draft AgentX MIB 9 March 1999 agentxMasterAgentXVer OBJECT-TYPE SYNTAX INTEGER (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The AgentX protocol version supported by this master agent. The current protocol version is 1. Note that the master agent must also allow registration of earlier version subagents. " ::= { agentxGeneral 2 } -- The AgentX Subagent Connection Group agentxConnTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last row creation or deletion occurred in the agentxConnectionTable. " ::= { agentxConnection 1 } agentxConnectionTable OBJECT-TYPE SYNTAX SEQUENCE OF AgentxConnectionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The agentxConnectionTable tracks all current AgentX transport connections. There may be zero, one, or more AgentX sessions carried on a given AgentX connection. " ::= { agentxConnection 2 } agentxConnectionEntry OBJECT-TYPE SYNTAX AgentxConnectionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An agentxConnectionEntry contains information describing a single AgentX transport connection. A connection may be used to support zero or more AgentX sessions. An entry is created when a new transport connection is established, and is destroyed when the transport connection is terminated. " INDEX { agentxConnIndex } ::= { agentxConnectionTable 1 } AgentX Working Group Expires September 1999 [Page 8] Internet Draft AgentX MIB 9 March 1999 AgentxConnectionEntry ::= SEQUENCE { agentxConnIndex Unsigned32, agentxConnOpenTime TimeStamp, agentxConnTransportDomain TDomain, agentxConnTransportAddress AgentxTAddress } agentxConnIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "agentxConnIndex contains the value that uniquely identifies an open transport connection used by this master agent to provide AgentX service. Values of this index should not be re-used. The value assigned to a given transport connection is constant for the lifetime of that connection. " ::= { agentxConnectionEntry 1 } agentxConnOpenTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this connection was established and, therefore, its value when this entry was added to the table. " ::= { agentxConnectionEntry 2 } agentxConnTransportDomain OBJECT-TYPE SYNTAX TDomain MAX-ACCESS read-only STATUS current DESCRIPTION "The transport protocol in use for this connection to the subagent. " ::= { agentxConnectionEntry 3 } AgentX Working Group Expires September 1999 [Page 9] Internet Draft AgentX MIB 9 March 1999 agentxConnTransportAddress OBJECT-TYPE SYNTAX AgentxTAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The transport address of the remote (subagent) end of this connection to the master agent. This object may be zero-length for unix-domain sockets (and possibly other types of transport addresses) since the subagent need not bind a filename to its local socket. " ::= { agentxConnectionEntry 4 } -- The AgentX Subagent Session Group agentxSessionTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last row creation or deletion occurred in the agentxSessionTable. " ::= { agentxSession 1 } agentxSessionTable OBJECT-TYPE SYNTAX SEQUENCE OF AgentxSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of AgentX subagent sessions currently in effect. " ::= { agentxSession 2 } agentxSessionEntry OBJECT-TYPE SYNTAX AgentxSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single open session between the AgentX master agent and a subagent is contained in this entry. An entry is created when a new session is successfully established and is destroyed either when the parent transport connection has terminated or when the session is closed. " INDEX { agentxConnIndex, agentxSessionIndex } ::= { agentxSessionTable 1 } AgentX Working Group Expires September 1999 [Page 10] Internet Draft AgentX MIB 9 March 1999 AgentxSessionEntry ::= SEQUENCE { agentxSessionIndex Unsigned32, agentxSessionObjectID OBJECT IDENTIFIER, agentxSessionDescr SnmpAdminString, agentxSessionAdminStatus INTEGER, agentxSessionOpenTime TimeStamp, agentxSessionAgentXVer INTEGER, agentxSessionTimeout INTEGER } agentxSessionIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index for the subagent session. It is the same as h.sessionID defined in the agentx header. Note that if a subagent's session with the master agent is closed for ! any reason its index should not be re-used. ! " ::= { agentxSessionEntry 1 } agentxSessionObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "This is taken from the o.id field of the agentx-Open-PDU. This attribute will report a value of '0.0' for subagents ! not supporting the notion of an AgentX session object ! identifier. ! " ::= { agentxSessionEntry 2 } agentxSessionDescr OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual description of the subagent. This is analogous to sysDescr defined in MIB-2 [2] and is taken from the o.descr field of the agentx-Open-PDU. This attribute will report a ! zero-length string value for subagents not supporting the ! notion of a session description. ! " ::= { agentxSessionEntry 3 } AgentX Working Group Expires September 1999 [Page 11] Internet Draft AgentX MIB 9 March 1999 agentxSessionAdminStatus OBJECT-TYPE SYNTAX INTEGER { up(1), down(2) } MAX-ACCESS read-write STATUS current DESCRIPTION "The administrative (desired) status of the subagent. Setting the value to 'down(2)' closes the subagent session (with c.reason set to 'reasonByManager'). " ::= { agentxSessionEntry 4 } agentxSessionOpenTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when this session was opened and, therefore, its value when this entry was added to the table. " ::= { agentxSessionEntry 5 } agentxSessionAgentXVer OBJECT-TYPE SYNTAX INTEGER (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The version of the AgentX protocol supported by the subagent. This must be less than or equal to the value of ! agentxMasterAgentXVer. " ::= { agentxSessionEntry 6 } agentxSessionTimeout OBJECT-TYPE SYNTAX INTEGER (0..255) UNITS "seconds" MAX-ACCESS read-only STATUS current AgentX Working Group Expires September 1999 [Page 12] Internet Draft AgentX MIB 9 March 1999 DESCRIPTION "The length of time, in seconds, that a master agent should allow to elapse after dispatching a message to this subagent before it regards the subagent as not responding. This value is taken from the o.timeout field of the agentx-Open-PDU. This is a subagent-specific value that may be overridden by values associated with specific registered MIB regions (see agentxRegTimeout). The default value of zero indicates that the master agent's default timeout value should be used (see agentxDefaultTimeout). " ::= { agentxSessionEntry 7 } -- The AgentX Registration Group agentxRegistrationTableLastChange OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when the last row creation or deletion occurred in the agentxRegistrationTable. " ::= { agentxRegistration 1 } ! agentxRegistrationTable OBJECT-TYPE SYNTAX SEQUENCE OF AgentxRegistrationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of registered regions. " ::= { agentxRegistration 2 } ! agentxRegistrationEntry OBJECT-TYPE SYNTAX AgentxRegistrationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Contains information for a single registered region. An entry is created when a subagent successfully registers a region and is destroyed for any of three reasons: this region is unregistered by the subagent, the parent session is closed, or the parent connection is closed. " INDEX { agentxConnIndex, agentxSessionIndex, agentxRegIndex } ::= { agentxRegistrationTable 1 } AgentX Working Group Expires September 1999 [Page 13] Internet Draft AgentX MIB 9 March 1999 AgentxRegistrationEntry ::= SEQUENCE { agentxRegIndex Unsigned32, agentxRegContext OCTET STRING, agentxRegStart OBJECT IDENTIFIER, agentxRegRangeSubId Unsigned32, agentxRegUpperBound Unsigned32, agentxRegPriority Unsigned32, agentxRegTimeout INTEGER, agentxRegInstance TruthValue, agentxRegDuplicate Counter32 ! } agentxRegIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "agentxRegIndex uniquely identifies a registration entry. This value is constant for the lifetime of an entry. " ::= { agentxRegistrationEntry 1 } agentxRegContext OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The context in which the subagent supports the objects in this region. A zero-length context indicates the default context. " ::= { agentxRegistrationEntry 2 } agentxRegStart OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The starting OBJECT IDENTIFIER of this registration entry. The subagent identified by agentxSessionIndex implements objects starting at this value (inclusive). Note that this value could identify an object type, an object instance, or a partial object instance. " ::= { agentxRegistrationEntry 3 } AgentX Working Group Expires September 1999 [Page 14] Internet Draft AgentX MIB 9 March 1999 agentxRegRangeSubId OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "agentxRegRangeSubId is used to specify the range. This is taken from r.region_subid in the registration PDU. If the value of this object is zero, no range is specified. If it is non-zero, it identifies the "nth" sub-identifier in r.region for which this entry's agentxRegUpperBound value is substituted in the OID for purposes of defining the region's upper bound. " ::= { agentxRegistrationEntry 4 } agentxRegUpperBound OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "agentxRegUpperBound represents the upper-bound sub-identifier in a registration. This is taken from the r.upper_bound in the registration PDU. If agentxRegRangeSubid (r.region_subid) is zero, this value is also zero and is not used to define an upper bound for this registration. " ::= { agentxRegistrationEntry 5 } agentxRegPriority OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The subagent's priority when exporting this OID range. Lower values have higher priority. This value is taken ! from r.priority in the register PDU. Subagents should ! use the value of 127 for r.priority if a default value ! is desired. ! " ::= { agentxRegistrationEntry 6 } agentxRegTimeout OBJECT-TYPE SYNTAX INTEGER (0..255) UNITS "seconds" MAX-ACCESS read-only STATUS current AgentX Working Group Expires September 1999 [Page 15] Internet Draft AgentX MIB 9 March 1999 DESCRIPTION "The timeout value, in seconds, for subagent responses to requests associated with this OID range. A value of zero indicates the default value (indicated by agentxSessionTimeout or agentxDefaultTimeout) is to be used. This value is taken from the r.timeout field of the agentx-Register-PDU. " ::= { agentxRegistrationEntry 7 } agentxRegInstance OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The value of agentxRegInstance is `true' for registrations for which the INSTANCE_REGISTRATION was set, and is `false' for all other registrations. " ::= { agentxRegistrationEntry 8 } agentxRegDuplicate OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of agentx-Response-PDU messages sent by this master agent where the res.error field was set to 'duplicateRegistration' and for which the attempted region ! registration would have duplicated the registration in this ! entry. ! " ::= { agentxRegistrationEntry 9 } -- Conformance Statements for AgentX agentxConformance OBJECT IDENTIFIER ::= { agentxMIB 2 } agentxMIBGroups OBJECT IDENTIFIER ::= { agentxConformance 1 } agentxMIBCompliances OBJECT IDENTIFIER ::= { agentxConformance 2 } -- Compliance Statements for AgentX agentxMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP entities that implement the AgentX protocol. Note that a compliant agent can implement all objects in this MIB module as read-only. " AgentX Working Group Expires September 1999 [Page 16] Internet Draft AgentX MIB 9 March 1999 MODULE -- this module MANDATORY-GROUPS { agentxMIBGroup } OBJECT agentxDefaultTimeout MIN-ACCESS read-only DESCRIPTION "Write access is not required. " OBJECT agentxSessionAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required. " ::= { agentxMIBCompliances 1 } agentxMIBGroup OBJECT-GROUP OBJECTS { agentxDefaultTimeout, agentxMasterAgentXVer, agentxConnTableLastChange, agentxConnOpenTime, agentxConnTransportDomain, agentxConnTransportAddress, agentxSessionTableLastChange, agentxSessionTimeout, agentxSessionObjectID, agentxSessionDescr, agentxSessionAdminStatus, agentxSessionOpenTime, agentxSessionAgentXVer, agentxRegistrationTableLastChange, agentxRegContext, agentxRegStart, agentxRegRangeSubId, agentxRegUpperBound, agentxRegPriority, agentxRegTimeout, agentxRegInstance, agentxRegDuplicate ! } STATUS current DESCRIPTION "All accessible objects in the AgentX MIB. " ::= { agentxMIBGroups 1 } END AgentX Working Group Expires September 1999 [Page 17] Internet Draft AgentX MIB 9 March 1999 5. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 6. Acknowledgements This document is the result of the efforts of the IETF AgentX Working Group (WG). This MIB is an evolution of the Subagent MIB by Bert Wijnen (wijnen@vnet.ibm.com) which in turn was derived from the SMUX-MIB by Marshall Rose [17]. Thanks are in order to the following AgentX WG members: Mike Daniele (Compaq Computer Corporation) Dale Francisco (Cisco Systems) Bob Natale (ACE*COMM Corporation) Randy Presuhn (BMC Software, Inc.) Shawn Routhier (Epilogue) Mike Thatcher (Independent Consultant) Special acknowledgement is made to: Maria Greene (Xedia) AgentX Working Group Expires September 1999 [Page 18] Internet Draft AgentX MIB 9 March 1999 Special acknowledgement is also made to the following individuals for participating in the 1998 AgentX testing summit (bakeoff) held in Sunnyvale, California: Jeff Case (SNMP Research, Inc.) Mike Daniele (Compaq Computer Corporation) Mark Ellison (Independent Consultant) Lauren Heintz (BMC Software, Inc.) Verne Hyde (Independent Consultant) Bob Natale (ACE*COMM Corporation) Shawn Routhier (Epilogue) Mike Thatcher (Independent Consultant) Bert Wijnen (IBM T. J. Watson Research Center) 7. Security Considerations There are a number of management objects defined in this MIB that ! have a MAX-ACCESS clause of read-write and/or read-create. Such ! objects may be considered sensitive or vulnerable in some network ! environments. The support for SET operations in a non-secure ! environment without proper protection can have a negative effect on ! network operations. ! There are a number of managed objects in this MIB that may contain ! sensitive information. These are: agentxDefaultTimeout and ! agentxSessionAdminStatus. Setting agentxDefaultTimeout to an ! inappropriately small value can prevent new subagent sessions from ! being usable. Setting agentxSessionAdminStatus to an inappropriate ! value can effectively prevent access to management information, or ! provide access to inappropriate information. ! It is thus important to control even GET access to these objects and ! possibly to even encrypt the values of these objects when sending ! them over the network via SNMP. Not all versions of SNMP provide ! features for such a secure environment. ! SNMPv1 by itself is not a secure environment. Even if the network ! itself is secure (for example by using IPSec), even then, there is no ! control as to who on the secure network is allowed to access and ! GET/SET (read/change/create/delete) the objects in this MIB. ! It is recommended that the implementers consider the security ! features as provided by the SNMPv3 framework. Specifically, the use ! of the User-based Security Model RFC 2274 [12] and the View-based ! Access Control Model RFC 2275 [15] is recommended. AgentX Working Group Expires September 1999 [Page 19] Internet Draft AgentX MIB 9 March 1999 It is then a customer/user responsibility to ensure that the SNMP en- ! tity giving access to an instance of this MIB, is properly configured ! to give access to the objects only to those principals (users) that ! have legitimate rights to indeed GET or SET (change/create/delete) ! them. AgentX Working Group Expires September 1999 [Page 20] Internet Draft AgentX MIB 9 March 1999 8. References [1] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998 [2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International, Hughes LAN Systems, May 1990 [3] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, Performance Systems International, Hughes LAN Systems, March 1991 [4] M. Rose, "A Convention for Defining Traps for use with the SNMP", RFC 1215, Performance Systems International, March 1991 [5] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual Conventions for Version 2 of the Simple Network Management Proto- col (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, Jan- uary 1996. [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [8] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network Management Protocol", RFC 1157, SNMP Research, Performance Systems International, Performance Systems International, MIT Laboratory for Computer Science, May 1990. [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. AgentX Working Group Expires September 1999 [Page 21] Internet Draft AgentX MIB 9 March 1999 [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Trans- port Mappings for Version 2 of the Simple Network Management Pro- tocol (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Ser- vices, January 1996. [11] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. [12] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2274, IBM T. J. Watson Research, January 1998. [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [14] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco Systems, January 1998 [15] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., Cisco Systems, Inc., January 1998 [16] Daniele, M., Wijnen, B., and D. Francisco, "Agent Extensibility (AgentX) Protocol, Version 1", draft-ietf-agentx-ext-pro-02.txt, Digital Equipment Corporation, T.J. Watson Research Center, IBM Corp., Cisco Systems, November, 1996. [17] Rose, M., "SNMP MUX Protocol and MIB", RFC1227, Performance Systems International, May 1991. AgentX Working Group Expires September 1999 [Page 22] Internet Draft AgentX MIB 9 March 1999 9. Editors' Addresses Smitha Gudur Independent Consultant EMail: sgudur@hotmail.com Lauren Heintz BMC Software, Inc 965 Stewart Drive Sunnyvale, CA 94086 USA Phone: +1 408-616-3169 Fax: +1 408-616-3101 EMail: Lauren_Heintz@bmc.com 10. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. AgentX Working Group Expires September 1999 [Page 23] From owner-agentx@dorothy.bmc.com Tue Mar 9 13:45:47 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17408 for ; Tue, 9 Mar 1999 13:45:46 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA18116; Tue, 9 Mar 1999 12:40:29 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA15096 for agentx-list; Tue, 9 Mar 1999 10:33:03 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA15089 for ; Tue, 9 Mar 1999 10:32:56 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id MAA16831 for ; Tue, 9 Mar 1999 12:32:53 -0600 (CST) From: "Shawn A. Routhier" To: Lauren_Heintz@ec01-hou.bmc.com CC: agentx@dorothy.bmc.com In-reply-to: (Lauren_Heintz@ec01-hou.bmc.com) Subject: Comments on latest AgentX MIB (march 9 1999) Date: Tue, 9 Mar 99 13:32:50 -0500 Message-ID: <9903091332.aa18775@khitomer.epilogue.com> Sender: owner-agentx@dorothy.bmc.com Precedence: bulk 1) agentxRegDuplicate: I think adding this to the table is not a good idea. By keeping it in a registration entry any information it contains will be lost if the sub agent de-registers that region or if the sub agent goes away. If we are going to have it as part of a table then it needs to be described more tightly. What does "duplicated the registration in this entry" mean? For example what should happen if there are two registrations foo.1 and foo.2 and a sub agent tries to register foo.[1-2]? Do the counters for both entries get updated? If so the registration code must check all objects in the range and not stop at the first duplicate detected, this seems wasteful. Note: I would just as soon get rid of the counter completely but think having a single counter rather than one per region is better. 2) agentxRegIndex: Is this unique per connection, session or globally? sar From owner-agentx@dorothy.bmc.com Tue Mar 9 14:57:00 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18087 for ; Tue, 9 Mar 1999 14:56:59 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA00330; Tue, 9 Mar 1999 13:51:05 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA15891 for agentx-list; Tue, 9 Mar 1999 11:33:17 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA15886 for ; Tue, 9 Mar 1999 11:33:11 -0800 (PST) Received: from ec01-hou.bmc.com (ec01-hou.bmc.com [172.17.0.150]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA27070; Tue, 9 Mar 1999 13:33:05 -0600 (CST) Received: by ec01-hou.bmc.com with Internet Mail Service (5.5.2448.0) id ; Tue, 9 Mar 1999 13:33:05 -0600 Message-ID: From: "Heintz, Lauren" To: "'Shawn A. Routhier'" Cc: agentx@dorothy.bmc.com Subject: RE: Comments on latest AgentX MIB (march 9 1999) Date: Tue, 9 Mar 1999 13:33:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Hi Shawn, Thanks for your comments. > -----Original Message----- > From: Shawn A. Routhier [mailto:sar@epilogue.com] > Sent: Tuesday, March 09, 1999 10:33 AM > To: Lauren_Heintz@ec01-hou.bmc.com > Cc: agentx@dorothy.bmc.com > Subject: Comments on latest AgentX MIB (march 9 1999) > > > > 1) agentxRegDuplicate: > I think adding this to the table is not a good idea. > By keeping it in a registration entry any information it contains > will be lost if the sub agent de-registers that region or > if the sub agent goes away. If we are going to have it as part > of a table then it needs to be described more tightly. What does > "duplicated the registration in this entry" mean? For example what > should happen if there are two registrations foo.1 and foo.2 and a > sub agent tries to register foo.[1-2]? Do the counters for both > entries get updated? If so the registration code must check all > objects in the range and not stop at the first duplicate detected, > this seems wasteful. > > Note: I would just as soon get rid of the counter completely but > think having a single counter rather than one per region is better. I personally agree with the above note, but I know some others -- they know who they are :-) -- who asked for this object to be included in the table. What do you others think? Is it worth keeping this in the table and making its use more clear (even though it is expensive to implement), and if not, keeping it at all? I say let's axe it all together. > 2) agentxRegIndex: > Is this unique per connection, session or globally? I think the first sentence of the description... "agentxRegIndex uniquely identifies a registration entry." ...implies this is global despite the fact there are two other indices. ------------------------------------------------------------------------- Lauren Heintz BMC Software, Inc. (Formerly PEER Networks) Voice: +1 408 616-3169 Silicon Valley Division Fax: +1 408 616-3339 965 Stewart Drive Email: Lauren_Heintz@bmc.com Sunnyvale, California 94086 USA ------------------------------------------------------------------------- From owner-agentx@dorothy.bmc.com Tue Mar 9 15:16:51 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18404 for ; Tue, 9 Mar 1999 15:16:50 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA04417; Tue, 9 Mar 1999 14:13:41 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA18423 for agentx-list; Tue, 9 Mar 1999 12:10:19 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA18418 for ; Tue, 9 Mar 1999 12:10:14 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id OAA03778; Tue, 9 Mar 1999 14:10:12 -0600 (CST) Received: from [192.152.208.5] (helo=acecomm.com) by relay6.smtp.psi.net with smtp (Exim 1.90 #1) id 10KSpO-0005yu-00; Tue, 9 Mar 1999 15:10:10 -0500 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA16676; Tue, 9 Mar 1999 15:13:05 -0500 Message-Id: <4.1.19990309150623.00a162f0@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 09 Mar 1999 15:12:33 -0500 To: "Heintz, Lauren" From: Bob Natale Subject: RE: Comments on latest AgentX MIB (march 9 1999) Cc: agentx@dorothy.bmc.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk >At 3/9/99:02:33 PM, Heintz, Lauren wrote: Hi Lauren, >> 1) agentxRegDuplicate: >> >> Note: I would just as soon get rid of the counter completely but >> think having a single counter rather than one per region is better. > >I personally agree with the above note, but I know some others -- they know >who they are :-) -- who asked for this object to be included in the table. >What do you others think? Is it worth keeping this in the table and making >its use more clear (even though it is expensive to implement), and if not, >keeping it at all? I say let's axe it all together. I think that now that we have the duplicateRegistration error code which the master agent returns to a sub-agent in this eventuality we no longer need it in the AgentX MIB. A sub-agent might utilize the information in some manner deemed useful in its context...or it might simply accept the fact that some other entity is managing that range and attempt to register others or exist if it has no others. So, we can drop this object from the AgentX MIB, IMHO. >> 2) agentxRegIndex: >> Is this unique per connection, session or globally? > >I think the first sentence of the description... > > "agentxRegIndex uniquely identifies a registration entry." > >...implies this is global despite the fact there are two other indices. Yes, I agree with that interpretation...if I recall correctly, the feeling was that the additional indices would facilitate certain queries that would otherwise require the manage app to do some work to associate registrations with sessions and/or connections. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From owner-agentx@dorothy.bmc.com Tue Mar 9 15:34:59 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18724 for ; Tue, 9 Mar 1999 15:34:59 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA07541; Tue, 9 Mar 1999 14:32:39 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA18544 for agentx-list; Tue, 9 Mar 1999 12:29:33 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA18539 for ; Tue, 9 Mar 1999 12:29:28 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id OAA07020; Tue, 9 Mar 1999 14:29:26 -0600 (CST) Received: from sigma.zk3.dec.com (sigma.zk3.dec.com [16.140.128.160]) by mail13.digital.com (8.9.2/8.9.2/WV2.0e) with ESMTP id PAA00345; Tue, 9 Mar 1999 15:29:23 -0500 (EST) Received: from zk3.dec.com by sigma.zk3.dec.com (8.8.8/1.1.20.3/24Apr98-0811AM) id PAA0000000680; Tue, 9 Mar 1999 15:29:23 -0500 (EST) Message-ID: <36E5839F.D62725D8@zk3.dec.com> Date: Tue, 09 Mar 1999 15:25:03 -0500 From: Mike Daniele Organization: Compaq 64-bit UNIX networking X-Mailer: Mozilla 4.5 [en] (X11; I; OSF1 X5.0 alpha) X-Accept-Language: en MIME-Version: 1.0 To: Bob Natale CC: "Heintz, Lauren" , agentx@dorothy.bmc.com Subject: Re: Comments on latest AgentX MIB (march 9 1999) References: <4.1.19990309150623.00a162f0@nips.acec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Content-Transfer-Encoding: 7bit Bob Natale wrote: > >At 3/9/99:02:33 PM, Heintz, Lauren wrote: > > Hi Lauren, > > >> 1) agentxRegDuplicate: > >> > >> Note: I would just as soon get rid of the counter completely but > >> think having a single counter rather than one per region is better. > > > >I personally agree with the above note, but I know some others -- they know > >who they are :-) -- who asked for this object to be included in the table. > >What do you others think? Is it worth keeping this in the table and making > >its use more clear (even though it is expensive to implement), and if not, > >keeping it at all? I say let's axe it all together. > > I think that now that we have the duplicateRegistration error code which > the master agent returns to a sub-agent in this eventuality we no longer > need it in the AgentX MIB. A sub-agent might utilize the information in > some manner deemed useful in its context...or it might simply accept the > fact that some other entity is managing that range and attempt to register > others or exist if it has no others. So, we can drop this object from > the AgentX MIB, IMHO. > Well, I'm not arguing hard to keep it. but I think we're missing its purpose. This counter isn't there to help any subagents. Subagents don't ever need to read its value or anything, they know if their registration was rejected and can do whatever they like. The counter would be there to illuminate to a human what is happening or has happened on that system. "Gee, 1.3.6.1.4.1.232.18.2 has had 5000 duplicate registrations. I wonder what's going on?" To me, that seems useful. Much more useful than "Gee, the master agent has had 5000 duplicate registrations. I wonder what they were, and what's going on?" So I don't agree that a single global counter would be better. I also don't see why it's expensive to implement. A master agent has to detect that a registration is a duplicate, and so presumably is then holding a reference of some sort to the existing (duplicated) registration. Seems pretty simple to bump that guy's counter... And if the registration being processed is a duplicate of more than one existing registration, pick one! Still seems useful to me. Regards, Mike From owner-agentx@dorothy.bmc.com Tue Mar 9 16:14:12 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19371 for ; Tue, 9 Mar 1999 16:14:11 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA13054; Tue, 9 Mar 1999 15:07:33 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA18668 for agentx-list; Tue, 9 Mar 1999 12:59:34 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA18663 for ; Tue, 9 Mar 1999 12:59:29 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id OAA11834 for ; Tue, 9 Mar 1999 14:59:26 -0600 (CST) Received: from [192.152.208.5] (helo=acecomm.com) by relay6.smtp.psi.net with smtp (Exim 1.90 #1) id 10KTb2-0000cO-00; Tue, 9 Mar 1999 15:59:24 -0500 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA17189; Tue, 9 Mar 1999 16:02:23 -0500 Message-Id: <4.1.19990309154613.00a66e40@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 09 Mar 1999 16:01:51 -0500 To: Mike Daniele From: Bob Natale Subject: Re: Comments on latest AgentX MIB (march 9 1999) Cc: agentx@dorothy.bmc.com In-Reply-To: <36E5839F.D62725D8@zk3.dec.com> References: <4.1.19990309150623.00a162f0@nips.acec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk >At 3/9/99:03:25 PM, Mike Daniele wrote: Hi Mike, <...> >> I think that now that we have the duplicateRegistration error code which >> the master agent returns to a sub-agent in this eventuality we no longer >> need it in the AgentX MIB. A sub-agent might utilize the information in >> some manner deemed useful in its context...or it might simply accept the >> fact that some other entity is managing that range and attempt to register >> others or exist if it has no others. So, we can drop this object from >> the AgentX MIB, IMHO. > >Well, I'm not arguing hard to keep it. Ok...but this is still a useful technical discussion, it seems. >but I think we're missing its purpose. Ok...let's analyze that a bit further. >This counter isn't there to help any subagents. Subagents don't ever need >to read its value or anything, they know if their registration was rejected >and can do whatever they like. Right...including informing the cognizant humans (actively (say, via an e-mail message), or passively (say, via a log file entry), or indirectly (say, via a alert to some other piece of software). The added value here is that the particular sub-agent encountering the "problem" (if it is one) can report it in its own context (not used in the technical sense here). >The counter would be there to illuminate to a human what is happening >or has happened on that system. Perhaps the sub-agent response mechanism is a better one for this purpose. >"Gee, 1.3.6.1.4.1.232.18.2 has had 5000 duplicate registrations. >I wonder what's going on?" > >To me, that seems useful. Much more useful than > >"Gee, the master agent has had 5000 duplicate registrations. >I wonder what they were, and what's going on?" Agreed...and (ignoring the 5K case for now :-) the sub-agent response mechanism can provide the precise kind of feedback of your useful case. >So I don't agree that a single global counter would be better. Agreed...I did not mean to imply that we should have a single global counter for this event. The MIB should not deal with it all. >I also don't see why it's expensive to implement. A master agent >has to detect that a registration is a duplicate, and so presumably >is then holding a reference of some sort to the existing (duplicated) >registration. Seems pretty simple to bump that guy's counter... Agreed [and, remember, I'm actually personally in favor of even more extensive error monitoring/reporting via the AgentX MIB...but I'm now supporting what I've come to see as a strong consensus for a very lean AgentX MIB]...however, the sub-agent response mechanism provides an equally unproblematic implementation task, with the possibility of added-value extensions. >And if the registration being processed is a duplicate of more than >one existing registration, pick one! Still seems useful to me. That could work, although it's a bit frayed at the edges it seems. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From owner-agentx@dorothy.bmc.com Tue Mar 9 16:44:29 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19810 for ; Tue, 9 Mar 1999 16:44:28 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA18777; Tue, 9 Mar 1999 15:42:05 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA18806 for agentx-list; Tue, 9 Mar 1999 13:37:13 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA18799 for ; Tue, 9 Mar 1999 13:37:06 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id PAA18108 for ; Tue, 9 Mar 1999 15:37:04 -0600 (CST) Received: from sigma.zk3.dec.com (sigma.zk3.dec.com [16.140.128.160]) by mail13.digital.com (8.9.2/8.9.2/WV2.0e) with ESMTP id QAA02760; Tue, 9 Mar 1999 16:37:01 -0500 (EST) Received: from zk3.dec.com by sigma.zk3.dec.com (8.8.8/1.1.20.3/24Apr98-0811AM) id QAA0000007789; Tue, 9 Mar 1999 16:37:01 -0500 (EST) Message-ID: <36E59379.BC2C88BA@zk3.dec.com> Date: Tue, 09 Mar 1999 16:32:41 -0500 From: Mike Daniele Organization: Compaq 64-bit UNIX networking X-Mailer: Mozilla 4.5 [en] (X11; I; OSF1 X5.0 alpha) X-Accept-Language: en MIME-Version: 1.0 To: Bob Natale CC: agentx@dorothy.bmc.com Subject: Re: Comments on latest AgentX MIB (march 9 1999) References: <4.1.19990309150623.00a162f0@nips.acec.com> <4.1.19990309154613.00a66e40@nips.acec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Content-Transfer-Encoding: 7bit Bob Natale wrote: Hi Bob, > Right...including informing the cognizant humans (actively (say, via > an e-mail message), or passively (say, via a log file entry), or > indirectly (say, via a alert to some other piece of software). The > added value here is that the particular sub-agent encountering the > "problem" (if it is one) can report it in its own context (not used > in the technical sense here). > > >The counter would be there to illuminate to a human what is happening > >or has happened on that system. > > Perhaps the sub-agent response mechanism is a better one for this > purpose. > But I thought we wanted to provide a MIB? You know, an SNMP MIB? :-) > > >"Gee, 1.3.6.1.4.1.232.18.2 has had 5000 duplicate registrations. > >I wonder what's going on?" > > > >To me, that seems useful. Much more useful than > > > >"Gee, the master agent has had 5000 duplicate registrations. > >I wonder what they were, and what's going on?" > > Agreed...and (ignoring the 5K case for now :-) the sub-agent > response mechanism can provide the precise kind of feedback > of your useful case. > > >So I don't agree that a single global counter would be better. > > Agreed...I did not mean to imply that we should have a single > global counter for this event. The MIB should not deal with > it all. > > >I also don't see why it's expensive to implement. A master agent > >has to detect that a registration is a duplicate, and so presumably > >is then holding a reference of some sort to the existing (duplicated) > >registration. Seems pretty simple to bump that guy's counter... > > Agreed [and, remember, I'm actually personally in favor of even more > extensive error monitoring/reporting via the AgentX MIB...but I'm now > supporting what I've come to see as a strong consensus for a very lean > AgentX MIB]...however, the sub-agent response mechanism provides an > equally unproblematic implementation task, with the possibility > of added-value extensions. > But it - requires subagents to do something - requires a human to be logged on to each machine with AgentX installed and manually do something. - requires a human to understand each implementation's logging mechanism (maybe not a big deal) - is not available via SNMP However, if you see emerging consensus to remove this object, no argument here. > > >And if the registration being processed is a duplicate of more than > >one existing registration, pick one! Still seems useful to me. > > That could work, although it's a bit frayed at the edges it seems. > Oh I don't know. Think about how this would work in practice. To be a duplicate of > 1 existing registration you have to be registering a range, where at least 2 individual subtrees from that range exactly match different existing registrations. (I think.) Example, A registers the first 3 columns of row n in some table (foo.[1-3].n) B registers the last 4 columns for the same row n (foo.[4-7].n). And now C registers all columns for row n, and is a duplicate of both. Or perhaps C registered foo.[3-4].n... Is it really a problem that this might be logged as a duplicate of either A's or B's registration? Mike From owner-agentx@dorothy.bmc.com Tue Mar 9 17:22:23 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20522 for ; Tue, 9 Mar 1999 17:22:22 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA24790; Tue, 9 Mar 1999 16:20:05 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA19256 for agentx-list; Tue, 9 Mar 1999 14:15:11 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA19251 for ; Tue, 9 Mar 1999 14:15:03 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id QAA23978 for ; Tue, 9 Mar 1999 16:15:00 -0600 (CST) Received: from [192.152.208.5] (helo=acecomm.com) by relay6.smtp.psi.net with smtp (Exim 1.90 #1) id 10KUmA-0004lb-00; Tue, 9 Mar 1999 17:14:59 -0500 Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM) id AA17874; Tue, 9 Mar 1999 17:17:58 -0500 Message-Id: <4.1.19990309170306.00a5d240@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 09 Mar 1999 17:17:25 -0500 To: Mike Daniele From: Bob Natale Subject: Re: duplicateRegistration error handling Cc: agentx@dorothy.bmc.com In-Reply-To: <36E59379.BC2C88BA@zk3.dec.com> References: <4.1.19990309150623.00a162f0@nips.acec.com> <4.1.19990309154613.00a66e40@nips.acec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk >At 3/9/99:04:32 PM, Mike Daniele wrote: Hi Mike, I've changed the Subject: header (way belatedly, I'm sure!) to better reflect the content of this thread. <...> >> Perhaps the sub-agent response mechanism is a better one for this >> purpose. >> > >But I thought we wanted to provide a MIB? You know, an SNMP MIB? :-) You're preaching to the choir...my personal view is that every AgentX error state should be represented in the MIB...that's clearly a minority view (perhaps a minority of one) and is not even on the table...it looks like we're aiming for a truly minimalist AgentX MIB. So, continuing in that spirit: >> ...however, the sub-agent response mechanism provides an >> equally unproblematic implementation task, with the possibility >> of added-value extensions. >> > >But it > > - requires subagents to do something Not in all cases. In some cases, ignoring a duplicateRegistration message might be perfectly acceptable to a sub-agent which is willing to make the assumption as long as something is handling the object(s), that's good enough. In other cases, yes, the sub-agent would do something to record and/or report the error...this may be a good thing from the perspective of the goal you stated to assist the human operators. > - requires a human to be logged on to each machine with AgentX > installed and manually do something. Not necessarily...I gave a brief outline of active, passive, and indirect responses a sub-agent might take. It may be rare, indeed, that a human will need to react to a duplicateRegistration report. [Whereas that other new error code one we added in this category for "registrationFailure"...I forget the exact name at the moment... may be much more important to the human operator and, presumably, will *require* some sort of sub-agent notification response up the food chain...however, that's strictly an implementation matter.] > - requires a human to understand each implementation's logging >mechanism (maybe not a big deal) True...(on both counts)...although one should expect the sub-agent response mechanisms to be generally familiar ones...however, again, I guess that's strictly an implementation matter. > - is not available via SNMP True...unless the sub-agent is configured to issue an SNMP notification for it...or pumps data into some direct method of generating an SNMP notification (e.g., a log file monitored by some external notification originator app). >However, if you see emerging consensus to remove this object, >no argument here. I think we are seeing such consensus...the rest of you can monitor and comment on that as well as I can too...so please feel free to do so. <...> >> That could work, although it's a bit frayed at the edges it seems. <...> >Is it really a problem that this might be logged as a duplicate of >either A's or B's registration? No, it's not a major problem...just not as "tidy" as one might wish ...just a nit on my part. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From owner-agentx@dorothy.bmc.com Tue Mar 9 17:32:10 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20767 for ; Tue, 9 Mar 1999 17:32:09 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA25419; Tue, 9 Mar 1999 16:24:10 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA19306 for agentx-list; Tue, 9 Mar 1999 14:23:56 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA19301 for ; Tue, 9 Mar 1999 14:23:50 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with SMTP id QAA25370 for ; Tue, 9 Mar 1999 16:23:48 -0600 (CST) Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id RAA18907; Tue, 9 Mar 1999 17:18:19 -0500 (EST) Received: from roc-mail2.ctron.com(134.141.72.230) by ctron-dnm.ctron.com via smap (4.1) id xma018871; Tue, 9 Mar 99 17:18:02 -0500 Received: from ctron-exc1.ctron.com (ctron-exc1 [134.141.34.126]) by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id RAA10661; Tue, 9 Mar 1999 17:19:11 -0500 (EST) Received: by ctron-exc1.ctron.com with Internet Mail Service (5.5.2232.9) id ; Tue, 9 Mar 1999 17:16:50 -0500 Message-ID: From: "Harrington, David" To: "'Mike Daniele'" , Bob Natale Cc: agentx@dorothy.bmc.com Subject: RE: Comments on latest AgentX MIB (march 9 1999) Date: Tue, 9 Mar 1999 17:16:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BE6A7A.85D20E40" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BE6A7A.85D20E40 Content-Type: text/plain; charset="ISO-8859-1" Hi all, Would it make sense to send a trap (duplicate-registration-trap) with the OIDs or the oid range or whatever? from the standpoint of a manager (er.. entity with command generator application) it might be useful to know that someone is trying to register to support an access control MIB or some such OID range, that could somehow be used to violate configured privileges. A trap would certainly be more useful than knowing that somebody tried to register some mib that was a duplication. An alternative would be to store a row into a table with the duplicate registration information. just my $.02 dbh ---------------- #include David Harrington, Spectrum ATM Services Manager Development dbh@cabletron.com Cabletron Systems Inc. > -----Original Message----- > From: Mike Daniele [mailto:daniele@zk3.dec.com] > Sent: Tuesday, March 09, 1999 4:33 PM > To: Bob Natale > Cc: agentx@dorothy.bmc.com > Subject: Re: Comments on latest AgentX MIB (march 9 1999) > > > Bob Natale wrote: > > Hi Bob, > > > > Right...including informing the cognizant humans (actively (say, via > > an e-mail message), or passively (say, via a log file entry), or > > indirectly (say, via a alert to some other piece of software). The > > added value here is that the particular sub-agent encountering the > > "problem" (if it is one) can report it in its own context (not used > > in the technical sense here). > > > > >The counter would be there to illuminate to a human what > is happening > > >or has happened on that system. > > > > Perhaps the sub-agent response mechanism is a better one for this > > purpose. > > > > But I thought we wanted to provide a MIB? You know, an SNMP MIB? :-) > > > > > >"Gee, 1.3.6.1.4.1.232.18.2 has had 5000 duplicate registrations. > > >I wonder what's going on?" > > > > > >To me, that seems useful. Much more useful than > > > > > >"Gee, the master agent has had 5000 duplicate registrations. > > >I wonder what they were, and what's going on?" > > > > Agreed...and (ignoring the 5K case for now :-) the sub-agent > > response mechanism can provide the precise kind of feedback > > of your useful case. > > > > >So I don't agree that a single global counter would be better. > > > > Agreed...I did not mean to imply that we should have a single > > global counter for this event. The MIB should not deal with > > it all. > > > > >I also don't see why it's expensive to implement. A master agent > > >has to detect that a registration is a duplicate, and so presumably > > >is then holding a reference of some sort to the existing > (duplicated) > > >registration. Seems pretty simple to bump that guy's counter... > > > > Agreed [and, remember, I'm actually personally in favor of even more > > extensive error monitoring/reporting via the AgentX > MIB...but I'm now > > supporting what I've come to see as a strong consensus for > a very lean > > AgentX MIB]...however, the sub-agent response mechanism provides an > > equally unproblematic implementation task, with the possibility > > of added-value extensions. > > > > But it > > - requires subagents to do something > - requires a human to be logged on to each machine with > AgentX installed and > manually do something. > - requires a human to understand each implementation's > logging mechanism > (maybe not a big deal) > - is not available via SNMP > > However, if you see emerging consensus to remove this object, > no argument here. > > > > > >And if the registration being processed is a duplicate of more than > > >one existing registration, pick one! Still seems useful to me. > > > > That could work, although it's a bit frayed at the edges it seems. > > > > Oh I don't know. Think about how this would work in practice. > To be a duplicate of > 1 existing registration you have to be > registering > a range, where at least 2 individual subtrees from that range exactly > match different existing registrations. (I think.) > > Example, A registers the first 3 columns of row n in some table > (foo.[1-3].n) > > B registers the last 4 columns for the same row n > (foo.[4-7].n). And now C > registers all columns for row n, and is a duplicate of both. > Or perhaps > C registered foo.[3-4].n... > > Is it really a problem that this might be logged as a duplicate of > either A's or B's registration? > > Mike > > ------_=_NextPart_000_01BE6A7A.85D20E40 Content-Type: application/octet-stream; name="Harrington, David.vcf" Content-Disposition: attachment; filename="Harrington, David.vcf" Content-Location: ATT-0-336A11376AD6D2119DFE0000C0BFD3F3-H ARRIN%7E1.VCF BEGIN:VCARD VERSION:2.1 N:Harrington;David FN:Harrington, David ORG:Cabletron Systems, Inc.;5140 -- SPECTRUM CORE TEL;WORK;VOICE:77357 ADR;WORK:;Durham;121 Technology Drive;Durham;NH;03824;US LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Durham=0D=0A121 Technology Drive=0D=0ADurham, NH 03824=0D=0AUS EMAIL;PREF;INTERNET:dbh@cabletron.com REV:19981214T180642Z END:VCARD ------_=_NextPart_000_01BE6A7A.85D20E40-- From owner-agentx@dorothy.bmc.com Tue Mar 9 17:58:22 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21193 for ; Tue, 9 Mar 1999 17:58:22 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA29755; Tue, 9 Mar 1999 16:55:09 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA19408 for agentx-list; Tue, 9 Mar 1999 14:50:25 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA19403 for ; Tue, 9 Mar 1999 14:50:21 -0800 (PST) Received: from ec01-hou.bmc.com (ec01-hou.bmc.com [172.17.0.150]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id QAA29127 for ; Tue, 9 Mar 1999 16:50:19 -0600 (CST) Received: by ec01-hou.bmc.com with Internet Mail Service (5.5.2448.0) id ; Tue, 9 Mar 1999 16:50:19 -0600 Message-ID: From: "Heintz, Lauren" To: agentx@dorothy.bmc.com Subject: Re: duplicateRegistration error handling Date: Tue, 9 Mar 1999 16:50:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Hi all, I'd suggest that unless we can reasonably show that error counters are useful in helping to detect spontaneous AgentX-related network problems, that the counters are not justified being in the MIB. Seems to me that the only thing we've been talking about so far (as justification for adding the duplicate counter) is the single, non-spontaneous issue of easing subagent installation. Is it really wise to complicate the MIB (even if ever so slightly) just to ease subagent installation? Lauren ------------------------------------------------------------------------- Lauren Heintz BMC Software, Inc. (Formerly PEER Networks) Voice: +1 408 616-3169 Silicon Valley Division Fax: +1 408 616-3339 965 Stewart Drive Email: Lauren_Heintz@bmc.com Sunnyvale, California 94086 USA ------------------------------------------------------------------------- From owner-agentx@dorothy.bmc.com Mon Mar 15 16:55:00 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24815 for ; Mon, 15 Mar 1999 16:54:59 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA19731; Mon, 15 Mar 1999 15:52:20 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA25908 for agentx-list; Mon, 15 Mar 1999 13:45:05 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA25903 for ; Mon, 15 Mar 1999 13:45:00 -0800 (PST) Received: from ec01-hou.bmc.com (ec01-hou.bmc.com [172.17.0.150]) by tangelo.bmc.com (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA18461; Mon, 15 Mar 1999 15:44:57 -0600 (CST) Received: by ec01-hou.bmc.com with Internet Mail Service (5.5.2448.0) id ; Mon, 15 Mar 1999 15:44:57 -0600 Message-ID: From: "Heintz, Lauren" To: "'agentx@peer.com'" Cc: "'ellison@ieee.org'" Subject: FW: duplicateRegistration error handling Date: Mon, 15 Mar 1999 15:45:17 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk This relevant message (below) didn't make it on the AgentX list since it originated from a non-subscriber. Lauren ------------------------------------------------------------------------- Lauren Heintz BMC Software, Inc. (Formerly PEER Networks) Voice: +1 408 616-3169 Silicon Valley Division Fax: +1 408 616-3339 965 Stewart Drive Email: Lauren_Heintz@bmc.com Sunnyvale, California 94086 USA ------------------------------------------------------------------------- -----Original Message----- From: Mark Ellison [mailto:ellison@ieee.org] Sent: Saturday, March 13, 1999 6:40 AM To: Heintz, Lauren Cc: agentx@dorothy.bmc.com; Mark Ellison Subject: Re: duplicateRegistration error handling ...sorry if I kicked up some dust on the agentXRegisterDuplicate attribute- My original thought was that a global counter of duplicate registrations in the AgentX MIB is not very useful in helping figure out a root cause. I thought a duplicate registration counter within the AgentXRegistrationEntry would go alot farther in helping to determine a root cause. I don't think it matters which AgentXRegistrationEntry gets the register-duplicate counter incremented when a registration request is a duplicate of more than one registration. Also, I don't think it matters if an AgentXRegistrationEntry with a non-zero duplicate registration counter goes away when a subagent unregisters the region, or terminates processing. When the only subagents loaded on a system are provided by the system vendor (e.g. an embedded device, like a Cisco or Cabletron box; or, a general computing platform, like Compaq Tru64 UNIX, or IBM AIX), I don't think a counter of duplicate registrations is necessary at all- those sort of installation/configuration problems would presumably be caught and resolved prior to product release. With general computing platforms, application and layered software can be added to the platform's process mix. Along with this software often comes managability via SNMP- i.e. an AgentX subagent. Should this software be misconfigured, or installed improperly, one of the symptoms might likely show up as a duplicate registration when its subagent starts up. For example, an Oracle database server might kick off several processes, each responsible for a portion of some table, organized by indices. If these processes are mis-configured, a support desk might receive calls due to user perceived problems of database performance...but this same issue might also be seen as a duplicate registration...and, if the registration duplicates are counted within the AgentXRegistrationEntry, then diagnosis of such a problem would be simplified. While it is clear this is an installation/configuration problem, it is a problem of an essentially different nature than an installation/configuration problem when all subagents come as part of a base product from a single vendor. In summary, I feel the agentxRegisterDuplicate attribute, to be of any real use should be in the AgentXRegistrationEntry. However, I'm not going to lose any sleep if it doesn't show up there in the final version of the AgentX MIB- that's up to the WG at large. Also, I won't worry if the agentxRegisterDuplicate attribute remains as a global either, or, is removed entirely from the MIB. I can implement this in either manner, or not. Anyway, that's what my current thoughts are on this topic. Hope this helps. Regards, Mark "Heintz, Lauren" wrote: > Hi all, > > I'd suggest that unless we can reasonably show that error counters are > useful in helping to detect spontaneous AgentX-related network problems, > that the counters are not justified being in the MIB. > > Seems to me that the only thing we've been talking about so far (as > justification for adding the duplicate counter) is the single, > non-spontaneous issue of easing subagent installation. > > Is it really wise to complicate the MIB (even if ever so slightly) just to > ease subagent installation? > > Lauren > > ------------------------------------------------------------------------- > Lauren Heintz BMC Software, Inc. (Formerly PEER Networks) > Voice: +1 408 616-3169 Silicon Valley Division > Fax: +1 408 616-3339 965 Stewart Drive > Email: Lauren_Heintz@bmc.com Sunnyvale, California 94086 USA > ------------------------------------------------------------------------- From owner-agentx@dorothy.bmc.com Wed Mar 24 19:37:21 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08083 for ; Wed, 24 Mar 1999 19:37:20 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id SAA09280; Wed, 24 Mar 1999 18:33:58 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA28764 for agentx-list; Wed, 24 Mar 1999 16:29:10 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id QAA28758 for agentx@dorothy.bmc.com; Wed, 24 Mar 1999 16:29:06 -0800 (PST) Date: Wed, 24 Mar 1999 16:29:06 -0800 (PST) From: Randy Presuhn Message-Id: <199903250029.QAA28758@dorothy.bmc.com> To: agentx@dorothy.bmc.com Subject: Agentx timetable Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi - What's the current timetable for the updates to RFC 2257 and the AgentX MIB document? It's been quite a while since the working group has met. Are there any plans to meet in Oslo? ----------------------------------------------------------------------- Randy Presuhn rpresuhn@dorothy.bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- Any relationship between my opinions and BMC's is coincidental. ----------------------------------------------------------------------- From owner-agentx@dorothy.bmc.com Thu Mar 25 09:10:37 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26221 for ; Thu, 25 Mar 1999 09:10:36 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id IAA18606; Thu, 25 Mar 1999 08:07:49 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id GAA11407 for agentx-list; Thu, 25 Mar 1999 06:03:28 -0800 (PST) Received: from tangelo.bmc.com (root@tangelo.bmc.com [172.17.7.166]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id GAA11401; Thu, 25 Mar 1999 06:03:23 -0800 (PST) Received: from fw-us-hou1.bmc.com (fw-us-hou1.bmc.com [172.17.0.250]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with SMTP id IAA17951; Thu, 25 Mar 1999 08:03:20 -0600 (CST) Received: from [38.249.211.2] (helo=relay1.acecomm.com) by relay1.smtp.psi.net with smtp (Exim 1.90 #1) id 10QAj8-0005Go-00; Thu, 25 Mar 1999 09:03:18 -0500 Received: from natale by relay1.acecomm.com (SMI-8.6/SMI-SVR4) id JAA10586; Thu, 25 Mar 1999 09:09:52 -0500 Message-Id: <4.1.19990325083155.009a4df0@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 25 Mar 1999 09:04:31 -0500 To: Randy Presuhn From: Bob Natale Subject: Re: Agentx timetable Cc: agentx@dorothy.bmc.com In-Reply-To: <199903250029.QAA28758@dorothy.bmc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk >At 3/24/99:07:29 PM, Randy Presuhn wrote: Hi Randy, >What's the current timetable for the updates to RFC 2257 >and the AgentX MIB document? I am happy to report that our editor for the protocol spec (Dale Francisco) recently came back on-line, so to speak, after a series of international assignments for his employer which had precluded his active participation for some time. The primary author of the protocol spec (Mike Daniele) has made all technical revisions to RFC2257 indicated by previous IETF WG meetings and on-list issue discussion. Similarly, the primary MIB author (Lauren Heintz) has completed all technical revisions to the MIB document. Both of those documents are currently in Dale's possession and he is in the process of: - Ensuring technical consistency/completeness within the RFC2257 revision; - Ensuring technical consistency between the revised RFC2257 and MIB documents; - Performing an editorial pass on the RFC2257 document (and optionally also on the MIB document); - Formatting the documents for RFC and/or I-D submission as the case may be; - Anything else he deems appropriate and feasible. Following the completion of that process, both documents will be re-posted to the AgentX list for a brief period of review and comments (say, 2 weeks). During that time, I will be working with our ADs to assess the appropriate next step for these documents...esp. whether RFC2257 can/should be advanced to Draft Standard status or must/should recycle at Proposed Standard status and our next set of Charter revisions, if any. Of couse, all WG members will have open input into that decision as well. I do not have a definitive date for completion of Dale's current part (which is the gating factor here), but is in "crunch mode" on it for the current period so I am anticipating a near-term delivery (i.e., one to two weeks). >It's been quite a while since the working group has met. >Are there any plans to meet in Oslo? Not presently. It seems that the current consensus opinion--at least among the core design team--is that we (the AgentX community at-large) will be better served by focusing on an additional "bake-off" event as a means of promoting further imlementation work and of gathering additional interoperability reports. Given the number (several!) of known new implementations underway that were not represented in the last bake-off, this seems to be a good idea. Mike has offered Compaq/Digital facilities in New England for this event and current possible timing is mid- to late-Summer of this year. All of the above is, of course, open for further discussion by any and all interested parties. For people who have not been following the WG status all that closely due to the delay in publishing the document revisions, things should start to pick up very soon now and you might want to check both the WG web page (managed by Dave Keeney...needs some updates on the admin info re AD and list e-mail) at: http://www.scguild.com/agentx/ and the WG's IETF charter page at: http://www.ietf.org/html.charters/agentx-charter.html (Fortuitously, you will see that we are not that far off our current charter milestones at this point! :-) Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- From owner-agentx@dorothy.bmc.com Fri Mar 26 21:02:17 1999 Received: from tangelo.bmc.com (fw-us-hou-1.bmc.com [198.207.223.250]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10958 for ; Fri, 26 Mar 1999 21:02:16 -0500 (EST) Received: from dorothy.bmc.com (dorothy.bmc.com [192.146.153.65]) by tangelo.bmc.com (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id UAA27573; Fri, 26 Mar 1999 20:00:04 -0600 (CST) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA05494 for agentx-list; Fri, 26 Mar 1999 17:56:27 -0800 (PST) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id RAA05488 for agentx@dorothy.bmc.com; Fri, 26 Mar 1999 17:56:24 -0800 (PST) Date: Fri, 26 Mar 1999 17:56:24 -0800 (PST) From: Randy Presuhn Message-Id: <199903270156.RAA05488@dorothy.bmc.com> To: agentx@dorothy.bmc.com Subject: Re: Agentx timetable Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi - > Date: Thu, 25 Mar 1999 09:04:31 -0500 > To: Randy Presuhn > From: Bob Natale > Subject: Re: Agentx timetable > Cc: agentx@dorothy.bmc.com ... > During that time, I will be working with our ADs to assess > the appropriate next step for these documents...esp. whether > RFC2257 can/should be advanced to Draft Standard status or > must/should recycle at Proposed Standard status and our next > set of Charter revisions, if any. ... Taking the optimistic view that we might be able to progress from Proposed to Draft, is the required interoperability statement ready to go? I'm a bit concerned about the implementation interoperability status of the index reservation stuff. ----------------------------------------------------------------------- Randy Presuhn rpresuhn@dorothy.bmc.com http://www.bmc.com Voice: +1 408 616-3100 BMC Software, Inc. 965 Stewart Drive Fax: +1 408 616-3101 Sunnyvale, California 94086 USA ----------------------------------------------------------------------- Any relationship between my opinions and BMC's is coincidental. -----------------------------------------------------------------------