From rpresuhn@peer.com Thu Oct 30 12:11:02 1997 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA151712262 for ; Thu, 30 Oct 1997 12:11:02 -0800 Date: Thu, 30 Oct 1997 12:11:02 -0800 From: Randy Presuhn Return-Path: Message-Id: <199710302011.AA151712262@dorothy.peer.com> To: dfrancis@santa.cisco.com, sgudur@peer.com Subject: Re: New version of agentx Mib draft (02) Cc: agentx@peer.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - (trying out the new exploder....) > Date: Wed, 29 Oct 1997 22:26:18 -0800 > From: dfrancis@santa.cisco.com (Dale Francisco) > Message-Id: <199710300626.WAA22532@marvell.cisco.com> > To: sgudur@peer.com > Subject: Re: New version of agentx Mib draft (02) > Cc: agentx@fv.com ... > (2) Error output from SMIC > -------------------------- > % smicng -CC -CW -CB -M 0 AGENTX-MIB.inc > > E: f(AGENTX-MIB.my), (1,4) SMI item "BITS" used in AGENTX-MIB, but not defined or imported This is a peculiarity of SMIC. There is no BITS production to import. BITS is part of the macro notation defined in RFC 1902 and 1903. Importing it would be rather like importing "DESCRIPTION". > E: f(AGENTX-MIB.my), (157,16) Index item "agentxConnIndex" must be defined with syntax that includes a range ... > E: f(AGENTX-MIB.my), (264,21) Index item "agentxSessionIndex" must be defined with syntax that includes a range ... > E: f(AGENTX-MIB.my), (428,21) Index item "agentxRegIndex" must be defined with syntax that includes a range ... Why on earth would ranges required for these indexes? The type definition of Unsigned32 (the type of these indexes) already is defined with both lower and upper bounds. Further constraints seem pointless. --------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA --------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." --------------------------------------------------------------------- >From agentx-owner@fv.com Wed Oct 29 22:48:49 PST 1997 Received: from cashew.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA181134128 for ; Wed, 29 Oct 1997 22:48:48 -0800 Return-Path: Received: (from uucp@localhost) by cashew.bmc.com (8.8.6/8.8.6) id AAA19540; Thu, 30 Oct 1997 00:48:46 -0600 (CST) Resent-From: agentx-owner@fv.com Received: from proto.fv.com(207.67.199.11) by cashew.bmc.com via smap (V2.0) id xma019537; Thu, 30 Oct 97 00:48:42 -0600 Received: from localhost (proto.fv.com [207.67.199.11]) by proto.fv.com (8.8.8/8.8.8) with ESMTP id WAA13680 for ; Wed, 29 Oct 1997 22:26:39 -0800 (PST) Comment: Posted to the agentx Mailing List To unsubscribe, send mail to agentx-request@proto.fv.com with "unsubscribe" in the Subject Resent-Date: Wed, 29 Oct 1997 22:26:39 -0800 Resent-Message-Id: <13678.878192799.1@proto.fv.com> Received: (from smusr@localhost) by proto.fv.com (8.8.8/8.8.8) id WAA13674 for X-agentx-local; Wed, 29 Oct 1997 22:26:39 -0800 (PST) X-Suppressed-X-Authentication-Warning: proto.fv.com: smusr set sender to agentx-owner using -f Received: from shekel.fv.com (shekel.fv.com [207.67.199.130]) by proto.fv.com (8.8.8/8.8.8) with ESMTP id WAA13671 for ; Wed, 29 Oct 1997 22:26:38 -0800 (PST) Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.8/8.8.8) with ESMTP id WAA13292 for ; Wed, 29 Oct 1997 22:26:37 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.7/8.8.7) id WAA07170 for ; Wed, 29 Oct 1997 22:22:12 -0800 (PST) Received: from farley.cisco.com(204.179.2.54) by gauntlet.fv.com via smap (3.2) id xma007163; Wed, 29 Oct 97 22:21:54 -0800 Received: from santa.cisco.com (santa [171.69.187.12]) by farley.cisco.com (8.8.5-Cisco.1/8.6.5) with SMTP id WAA10122; Wed, 29 Oct 1997 22:25:55 -0800 (PST) Received: from marvell.cisco.com by santa.cisco.com (4.1/SMI-4.1) id AA27151; Wed, 29 Oct 97 22:26:19 PST Received: by marvell.cisco.com (SMI-8.6/SMI-SVR4) id WAA22532; Wed, 29 Oct 1997 22:26:18 -0800 Date: Wed, 29 Oct 1997 22:26:18 -0800 >From: dfrancis@santa.cisco.com (Dale Francisco) Message-Id: <199710300626.WAA22532@marvell.cisco.com> To: sgudur@peer.com Subject: Re: New version of agentx Mib draft (02) Cc: agentx@fv.com X-Suppressed-X-Sun-Charset: US-ASCII Status: RO Hi Smitha, I did a quick review of the latest AgentX MIB draft for style and spelling, and have some small suggestions for improvements. Also, I extracted the MIB and ran it through SMIC, and found some issues you may want to address. (Thanks to David Perkins for creating an incredibly useful tool.) I list below (1) the diff of the draft and my suggested style edits and (2) the error output from SMIC. If it would prove useful to you to have the edited text or the MIB I used (for line number info), I'd be happy to forward them to you. Thanks, Dale --- /// Dale Francisco Editor, AgentX WG \\\ Cisco Systems dfrancis@cisco.com /// 210 W Tasman Dr Bldg F voice: (408) 527-9787 \\\ San Jose CA 95134-1714 fax: (408) 527-2477 (1) Diff of draft and edited draft ---------------------------------- *** agentxmib.txt.orig Wed Oct 29 20:18:17 1997 --- agentxmib.txt Wed Oct 29 21:49:05 1997 *************** *** 98,99 **** ! - Identify the subagent's type, vendor, transport address, AgentX ! protocol version and other characteristics. --- 98,99 ---- ! - Identify each subagent's type, vendor, transport address, AgentX ! protocol version, and other characteristics. *************** *** 102 **** ! context in which the objects are registered and the priority of --- 102 ---- ! context in which the objects are registered, and the priority of *************** *** 124 **** ! provides information describing the master agent's agentx support, ! --- 124 ---- ! provides information describing the master agent's AgentX support, ! *************** *** 127 **** ! describing the current set of connections capable of carrying agentx ! --- 127 ---- ! describing the current set of connections capable of carrying AgentX ! *************** *** 154 **** ! which aagentxSessionConnIndex matches the value of the ! --- 154 ---- ! which agentxSessionConnIndex matches the value of the ! *************** *** 320,322 **** ! "The agentxConnectionTable tracks all current agentx transport ! ! connections. There may be zero, one, or more agentx sessions ! ! on a given agentx connection." ! --- 320,322 ---- ! "The agentxConnectionTable tracks all current AgentX transport ! ! connections. There may be zero, one, or more AgentX sessions ! ! on a given AgentX connection." ! *************** *** 346,347 **** ! single agentx transport connection. A conenction may be ! ! used to support zero or more agentx sessions. Entries come ! --- 346,347 ---- ! single AgentX transport connection. A connection may be ! ! used to support zero or more AgentX sessions. Entries come ! *************** *** 372 **** ! and, therefore, this entry was added to the table." ! --- 372,373 ---- ! and, therefore, its value when this entry was added to the ! table." *************** *** 563 **** ! therefore, this entry was added to the table." --- 564 ---- ! therefore, its value when this entry was added to the table." *************** *** 572 **** ! subagent. This will be equal to or less than the value of --- 573 ---- ! subagent. This will be less than or equal to the value of *************** *** 711 **** ! instance identifier." --- 712 ---- ! instance." *************** *** 731 **** ! or a partial object instance identifier." --- 732 ---- ! or a partial object instance." *************** *** 765 **** ! that default value (indicated by agentxSessionTimeout or --- 766 ---- ! that the default value (indicated by agentxSessionTimeout or *************** *** 972 **** ! or assist in its implmentation may be prepared, copied, published and | --- 973 ---- ! or assist in its implementation may be prepared, copied, published and | (2) Error output from SMIC -------------------------- % smicng -CC -CW -CB -M 0 AGENTX-MIB.inc E: f(AGENTX-MIB.my), (1,4) SMI item "BITS" used in AGENTX-MIB, but not defined or imported E: f(AGENTX-MIB.my), (157,16) Index item "agentxConnIndex" must be defined with syntax that includes a range W: f(AGENTX-MIB.my), (198,21) Item "agentxConnTransportAddr" should have SIZE specified W: f(AGENTX-MIB.my), (257,4) Sequence "AgentxSubagentEntry" and Row "agentxSessionEntry" should have related names E: f(AGENTX-MIB.my), (264,21) Index item "agentxSessionIndex" must be defined with syntax that includes a range E: f(AGENTX-MIB.my), (428,21) Index item "agentxRegIndex" must be defined with syntax that includes a range W: f(AGENTX-MIB.my), (452,19) Item "agentxRegContext" should have SIZE specified E: f(AGENTX-MIB.my), (558,10) Item "agentxConnIndex" in object-group "agentxMIBGroup" has access of "not-accessible" W: f(AGENTX-MIB.my), (9,27) "DisplayString" imported but not used *** 5 errors and 4 warnings in parsing ---------------- This e-mail message was sent to all subscribers to the agentx mailing list. To unsubscribe from this mailing list, please send mail to: agentx-request@proto.fv.com with Subject: unsubscribe your.address@your.domain (NOTE: Please do not reply to this message to unsubscribe. You must send your request to agentx-request@proto.fv.com Thank you.) From rpresuhn@peer.com Thu Oct 30 12:16:24 1997 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA152722584 for ; Thu, 30 Oct 1997 12:16:24 -0800 Date: Thu, 30 Oct 1997 12:16:24 -0800 From: Randy Presuhn Return-Path: Message-Id: <199710302016.AA152722584@dorothy.peer.com> To: agentx@peer.com Subject: test - please ignore Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Test #1 of agentx@peer.com list - please ignore --------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA --------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." --------------------------------------------------------------------- From sgudur@peer.com Thu Oct 30 12:36:03 1997 Received: from cashew.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA154843762 for ; Thu, 30 Oct 1997 12:36:02 -0800 Return-Path: Received: (from uucp@localhost) by cashew.bmc.com (8.8.6/8.8.6) id OAA21901 for ; Thu, 30 Oct 1997 14:36:00 -0600 (CST) Received: from gauntlet.fv.com(207.67.199.118) by cashew.bmc.com via smap (V2.0) id xma021879; Thu, 30 Oct 97 14:35:31 -0600 Received: (from uucp@localhost) by gauntlet.fv.com (8.8.7/8.8.7) id MAA11773 for ; Thu, 30 Oct 1997 12:31:00 -0800 (PST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma011746; Thu, 30 Oct 97 12:30:30 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.8/8.8.8) with ESMTP id MAA26417 for ; Thu, 30 Oct 1997 12:34:58 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.7/8.8.7) id MAA11741 for ; Thu, 30 Oct 1997 12:30:29 -0800 (PST) Received: from mail-gw1.bmc.com(198.64.253.22) by gauntlet.fv.com via smap (3.2) id xma011721; Thu, 30 Oct 97 12:30:13 -0800 Received: (from uucp@localhost) by almond.bmc.com (8.8.6/8.8.6) id OAA08046 for ; Thu, 30 Oct 1997 14:34:38 -0600 (CST) Received: from firewall.bmc.com(192.245.162.250) by almond.bmc.com via smap (V2.0) id xma008037; Thu, 30 Oct 97 14:34:27 -0600 Received: (from uucp@localhost) by dresden.bmc.com (8.8.5/8.8.6) id OAA08702 for ; Thu, 30 Oct 1997 14:34:35 -0600 (CST) Received: from cherry.bmc.com(172.17.1.25) by dresden.bmc.com via smap (3.2) id xma008227; Thu, 30 Oct 97 14:34:06 -0600 Received: from dorothy.peer.com (dorothy.peer.com [192.146.153.65]) by cherry.bmc.com with ESMTP (8.7.5/8.7.3) id OAA21771; Thu, 30 Oct 1997 14:33:56 -0600 (CST) Received: by dorothy.peer.com (1.39.111.2/16.2) id AA154663635 for ; Thu, 30 Oct 1997 12:33:55 -0800 From: Smitha Gudur Message-Id: <199710302033.AA154663635@dorothy.peer.com> Subject: Re: New version of agentx Mib draft (02) To: dfrancis@santa.cisco.com Date: Thu, 30 Oct 1997 12:33:55 PST Cc: agentx@fv.com, sgudur@peer.com In-Reply-To: <199710300626.WAA22532@marvell.cisco.com>; from "Dale Francisco" at Oct 29, 97 10:26 pm X-Mailer: Elm [revision: 111.1] Hi, > > Hi Smitha, > > I did a quick review of the latest AgentX MIB draft > for style and spelling, and have some small suggestions > for improvements. Also, I extracted the MIB and ran it > through SMIC, and found some issues you may want to address. > (Thanks to David Perkins for creating an incredibly useful > tool.) > > I list below (1) the diff of the draft and my suggested style > edits and (2) the error output from SMIC. If it would prove > useful to you to have the edited text or the MIB I used (for > line number info), I'd be happy to forward them to you. > > Thanks, > Dale > > --- > /// Dale Francisco Editor, AgentX WG > \\\ Cisco Systems dfrancis@cisco.com > /// 210 W Tasman Dr Bldg F voice: (408) 527-9787 > \\\ San Jose CA 95134-1714 fax: (408) 527-2477 > > (1) Diff of draft and edited draft > ---------------------------------- > *** agentxmib.txt.orig Wed Oct 29 20:18:17 1997 > --- agentxmib.txt Wed Oct 29 21:49:05 1997 > *************** > *** 98,99 **** > ! - Identify the subagent's type, vendor, transport address, AgentX > ! protocol version and other characteristics. > --- 98,99 ---- > ! - Identify each subagent's type, vendor, transport address, AgentX > ! protocol version, and other characteristics. > *************** > *** 102 **** > ! context in which the objects are registered and the priority of > --- 102 ---- > ! context in which the objects are registered, and the priority of > *************** > *** 124 **** > ! provides information describing the master agent's agentx support, ! > --- 124 ---- > ! provides information describing the master agent's AgentX support, ! > *************** > *** 127 **** > ! describing the current set of connections capable of carrying agentx ! > --- 127 ---- > ! describing the current set of connections capable of carrying AgentX ! > *************** > *** 154 **** > ! which aagentxSessionConnIndex matches the value of the ! > --- 154 ---- > ! which agentxSessionConnIndex matches the value of the ! > *************** > *** 320,322 **** > ! "The agentxConnectionTable tracks all current agentx transport ! > ! connections. There may be zero, one, or more agentx sessions ! > ! on a given agentx connection." ! > --- 320,322 ---- > ! "The agentxConnectionTable tracks all current AgentX transport ! > ! connections. There may be zero, one, or more AgentX sessions ! > ! on a given AgentX connection." ! > *************** > *** 346,347 **** > ! single agentx transport connection. A conenction may be ! > ! used to support zero or more agentx sessions. Entries come ! > --- 346,347 ---- > ! single AgentX transport connection. A connection may be ! > ! used to support zero or more AgentX sessions. Entries come ! > *************** > *** 372 **** > ! and, therefore, this entry was added to the table." ! > --- 372,373 ---- > ! and, therefore, its value when this entry was added to the > ! table." > *************** > *** 563 **** > ! therefore, this entry was added to the table." > --- 564 ---- > ! therefore, its value when this entry was added to the table." > *************** > *** 572 **** > ! subagent. This will be equal to or less than the value of > --- 573 ---- > ! subagent. This will be less than or equal to the value of > *************** > *** 711 **** > ! instance identifier." > --- 712 ---- > ! instance." > *************** > *** 731 **** > ! or a partial object instance identifier." > --- 732 ---- > ! or a partial object instance." > *************** > *** 765 **** > ! that default value (indicated by agentxSessionTimeout or > --- 766 ---- > ! that the default value (indicated by agentxSessionTimeout or > *************** > *** 972 **** > ! or assist in its implmentation may be prepared, copied, published and | > --- 973 ---- > ! or assist in its implementation may be prepared, copied, published and | > > > > (2) Error output from SMIC > -------------------------- > % smicng -CC -CW -CB -M 0 AGENTX-MIB.inc > > E: f(AGENTX-MIB.my), (1,4) SMI item "BITS" used in AGENTX-MIB, but not defined or imported BITS needs to be imported. > E: f(AGENTX-MIB.my), (157,16) Index item "agentxConnIndex" must be defined with syntax that includes a range > W: f(AGENTX-MIB.my), (198,21) Item "agentxConnTransportAddr" should have SIZE specified > W: f(AGENTX-MIB.my), (257,4) Sequence "AgentxSubagentEntry" and Row "agentxSessionEntry" should have related names > E: f(AGENTX-MIB.my), (264,21) Index item "agentxSessionIndex" must be defined with syntax that includes a range > E: f(AGENTX-MIB.my), (428,21) Index item "agentxRegIndex" must be defined with syntax that includes a range > W: f(AGENTX-MIB.my), (452,19) Item "agentxRegContext" should have SIZE specified As agentxRegContext is an OCTET-STRING and OCTET-STRING has an implied range of OCTET STRING (SIZE (0..65535)). This is is specified in rfc1902. > E: f(AGENTX-MIB.my), (558,10) Item "agentxConnIndex" in object-group "agentxMIBGroup" has access of "not-accessible" agentxConnIndex "not-accessible" needs to be "read-only". > W: f(AGENTX-MIB.my), (9,27) "DisplayString" imported but not used DisplayString needs to be removed. agentxConnIndex, agentxSessionIndex, agentxRegIndex have SYNTAX of Unsigned32. Unsigned32 as per rfc1902 and the range is specified as 0..4294967295. Any comments or suggestions on limiting ranges or sizes of of the above objects?. smitha > > *** 5 errors and 4 warnings in parsing > > ---------------- > This e-mail message was sent to all subscribers to the > agentx mailing list. > > To unsubscribe from this mailing list, please send mail to: > agentx-request@proto.fv.com > with > Subject: unsubscribe your.address@your.domain > > (NOTE: Please do not reply to this message to unsubscribe. You must send > your request to agentx-request@proto.fv.com Thank you.) > From dfrancis@santa.cisco.com Thu Oct 30 12:49:11 1997 Received: from cashew.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA158714550 for ; Thu, 30 Oct 1997 12:49:10 -0800 Return-Path: Received: (from uucp@localhost) by cashew.bmc.com (8.8.6/8.8.6) id OAA22665; Thu, 30 Oct 1997 14:49:08 -0600 (CST) Received: from farley.cisco.com(204.179.2.54) by cashew.bmc.com via smap (V2.0) id xma022650; Thu, 30 Oct 97 14:48:43 -0600 Received: from santa.cisco.com (santa [171.69.187.12]) by farley.cisco.com (8.8.5-Cisco.1/8.6.5) with SMTP id MAA23335; Thu, 30 Oct 1997 12:48:16 -0800 (PST) Received: from marvell.cisco.com by santa.cisco.com (4.1/SMI-4.1) id AA09063; Thu, 30 Oct 97 12:48:41 PST Received: by marvell.cisco.com (SMI-8.6/SMI-SVR4) id MAA22895; Thu, 30 Oct 1997 12:48:41 -0800 Date: Thu, 30 Oct 1997 12:48:41 -0800 From: dfrancis@santa.cisco.com (Dale Francisco) Message-Id: <199710302048.MAA22895@marvell.cisco.com> To: rpresuhn@peer.com, sgudur@peer.com Subject: Re: New version of agentx Mib draft (02) Cc: agentx@peer.com X-Sun-Charset: US-ASCII Randy, I reproduced the command line arguments and the entire error output from SMIC for the sake of completeness. Sometimes a compiler message that's mystifying to me will be plain as day to someone else, or, in the case of spurious error messages, it will lead indirectly to a real error. I agree there's nothing to be done about BITS, and as to the "must be defined with a syntax that includes a range" error, I assume (but do not know) that this stems from the v2 SMI's injunction to avoid 0-valued index objects. So, I bet a range of 1..maxUint32 would make SMIC contented and happy. Regards, Dale --- /// Dale Francisco Editor, AgentX WG \\\ Cisco Systems dfrancis@cisco.com /// 210 W Tasman Dr Bldg F voice: (408) 527-9787 \\\ San Jose CA 95134-1714 fax: (408) 527-2477 > From rpresuhn@peer.com Thu Oct 30 12:17:40 1997 > > Hi - > > (trying out the new exploder....) > > > Date: Wed, 29 Oct 1997 22:26:18 -0800 > > From: dfrancis@santa.cisco.com (Dale Francisco) > > Message-Id: <199710300626.WAA22532@marvell.cisco.com> > > To: sgudur@peer.com > > Subject: Re: New version of agentx Mib draft (02) > > Cc: agentx@fv.com > ... > > (2) Error output from SMIC > > -------------------------- > > % smicng -CC -CW -CB -M 0 AGENTX-MIB.inc > > > > E: f(AGENTX-MIB.my), (1,4) SMI item "BITS" used in AGENTX-MIB, but not defined or imported > > This is a peculiarity of SMIC. There is no BITS production to import. > BITS is part of the macro notation defined in RFC 1902 and 1903. > Importing it would be rather like importing "DESCRIPTION". > > > E: f(AGENTX-MIB.my), (157,16) Index item "agentxConnIndex" must be defined with syntax that includes a range > ... > > E: f(AGENTX-MIB.my), (264,21) Index item "agentxSessionIndex" must be defined with syntax that includes a range > ... > > E: f(AGENTX-MIB.my), (428,21) Index item "agentxRegIndex" must be defined with syntax that includes a range > ... > > Why on earth would ranges required for these indexes? The type definition > of Unsigned32 (the type of these indexes) already is defined with both > lower and upper bounds. Further constraints seem pointless. > > --------------------------------------------------------------------- > Randy Presuhn BMC Software, Inc. (Silicon Valley Division) > Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com > Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 > Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA > --------------------------------------------------------------------- > In accordance with the BMC Communications Systems Use and Security > Policy memo dated December 10, 1996, page 2, item (g) (the first of > two), I explicitly state that although my affiliation with BMC may be > apparent, implied, or provided, my opinions are not necessarily those > of BMC Software and that all external representations on behalf of > BMC must first be cleared with a member of "the top management team." > --------------------------------------------------------------------- From dfrancis@santa.cisco.com Thu Oct 30 13:15:53 1997 Received: from almond.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA165216152 for ; Thu, 30 Oct 1997 13:15:52 -0800 Return-Path: Received: (from uucp@localhost) by almond.bmc.com (8.8.6/8.8.6) id PAA12757 for ; Thu, 30 Oct 1997 15:15:51 -0600 (CST) Received: from gauntlet.fv.com(207.67.199.118) by almond.bmc.com via smap (V2.0) id xma012743; Thu, 30 Oct 97 15:15:38 -0600 Received: (from uucp@localhost) by gauntlet.fv.com (8.8.7/8.8.7) id NAA15354 for ; Thu, 30 Oct 1997 13:11:06 -0800 (PST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma015306; Thu, 30 Oct 97 13:10:36 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.8/8.8.8) with ESMTP id NAA00521 for ; Thu, 30 Oct 1997 13:15:04 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.7/8.8.7) id NAA15280 for ; Thu, 30 Oct 1997 13:10:35 -0800 (PST) Received: from farley.cisco.com(204.179.2.54) by gauntlet.fv.com via smap (3.2) id xma015246; Thu, 30 Oct 97 13:10:13 -0800 Received: from santa.cisco.com (santa [171.69.187.12]) by farley.cisco.com (8.8.5-Cisco.1/8.6.5) with SMTP id NAA26819; Thu, 30 Oct 1997 13:14:11 -0800 (PST) Received: from marvell.cisco.com by santa.cisco.com (4.1/SMI-4.1) id AA09551; Thu, 30 Oct 97 13:14:35 PST Received: by marvell.cisco.com (SMI-8.6/SMI-SVR4) id NAA22923; Thu, 30 Oct 1997 13:14:35 -0800 Date: Thu, 30 Oct 1997 13:14:35 -0800 From: dfrancis@santa.cisco.com (Dale Francisco) Message-Id: <199710302114.NAA22923@marvell.cisco.com> To: sgudur@peer.com Subject: Re: New version of agentx Mib draft (02) Cc: agentx@fv.com X-Sun-Charset: US-ASCII Smitha, I mentioned in an earlier post what I think the warning is about with regards the Unsigned32 indices. The warning about no SIZE for OCTET STRING is just that: a warning. There are very few applications that could handle an allocation of the max-size OCTET STRING, so I think the idea behind the warning is simply this: If you _can_ assign a reasonable upper bound, please do--it then becomes a plausible "contract" between MIB designer and agent implementor. If it's just "OCTET STRING", each implementor will pick what he or she thinks is a reasonable upper bound, almost certainly something less than 65,535 bytes. Thanks, Dale --- /// Dale Francisco Editor, AgentX WG \\\ Cisco Systems dfrancis@cisco.com /// 210 W Tasman Dr Bldg F voice: (408) 527-9787 \\\ San Jose CA 95134-1714 fax: (408) 527-2477 > From sgudur@peer.com Thu Oct 30 12:48:08 1997 > From: Smitha Gudur > Subject: Re: New version of agentx Mib draft (02) > To: dfrancis@santa.cisco.com > Date: Thu, 30 Oct 1997 12:33:55 PST > Cc: agentx@fv.com, sgudur@peer.com > > > > > (2) Error output from SMIC > > -------------------------- > > % smicng -CC -CW -CB -M 0 AGENTX-MIB.inc > > > > E: f(AGENTX-MIB.my), (1,4) SMI item "BITS" used in AGENTX-MIB, but not defined or imported > BITS needs to be imported. > > E: f(AGENTX-MIB.my), (157,16) Index item "agentxConnIndex" must be defined with syntax that includes a range > > W: f(AGENTX-MIB.my), (198,21) Item "agentxConnTransportAddr" should have SIZE specified > > W: f(AGENTX-MIB.my), (257,4) Sequence "AgentxSubagentEntry" and Row "agentxSessionEntry" should have related names > > E: f(AGENTX-MIB.my), (264,21) Index item "agentxSessionIndex" must be defined with syntax that includes a range > > E: f(AGENTX-MIB.my), (428,21) Index item "agentxRegIndex" must be defined with syntax that includes a range > > W: f(AGENTX-MIB.my), (452,19) Item "agentxRegContext" should have SIZE specified > > As agentxRegContext is an OCTET-STRING and OCTET-STRING has an implied > range of OCTET STRING (SIZE (0..65535)). > This is is specified in rfc1902. > > > E: f(AGENTX-MIB.my), (558,10) Item "agentxConnIndex" in object-group "agentxMIBGroup" has access of "not-accessible" > > agentxConnIndex "not-accessible" needs to be "read-only". > > > W: f(AGENTX-MIB.my), (9,27) "DisplayString" imported but not used > DisplayString needs to be removed. > > agentxConnIndex, agentxSessionIndex, agentxRegIndex have SYNTAX of Unsigned32. > Unsigned32 as per rfc1902 and the range is specified as 0..4294967295. > > Any comments or suggestions on limiting ranges or sizes > of of the above objects?. > > smitha > > > > > > > > *** 5 errors and 4 warnings in parsing > > > > ---------------- > > This e-mail message was sent to all subscribers to the > > agentx mailing list. > > > > To unsubscribe from this mailing list, please send mail to: > > agentx-request@proto.fv.com > > with > > Subject: unsubscribe your.address@your.domain > > > > (NOTE: Please do not reply to this message to unsubscribe. You must send > > your request to agentx-request@proto.fv.com Thank you.) > > > From rpresuhn@peer.com Thu Oct 30 13:46:10 1997 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA168867970 for ; Thu, 30 Oct 1997 13:46:10 -0800 Date: Thu, 30 Oct 1997 13:46:10 -0800 From: Randy Presuhn Return-Path: Message-Id: <199710302146.AA168867970@dorothy.peer.com> To: agentx@peer.com Subject: Re: New version of agentx Mib draft (02) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > From: Smitha Gudur > Message-Id: <199710302033.AA154663635@dorothy.peer.com> > Subject: Re: New version of agentx Mib draft (02) > To: dfrancis@santa.cisco.com > Date: Thu, 30 Oct 1997 12:33:55 PST > Cc: agentx@fv.com, sgudur@peer.com .... > > W: f(AGENTX-MIB.my), (452,19) Item "agentxRegContext" should have SIZE specified > > As agentxRegContext is an OCTET-STRING and OCTET-STRING has an implied > range of OCTET STRING (SIZE (0..65535)). > This is is specified in rfc1902. ... The agentx protocol leaves the length of agentxRegContext unconstrained. Would it make sense to tighten up the MIB representation to align with VACM's notion of context? PRO: would probably be more consistent CON: the protocol would permit contest names that the MIB could not represent --------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA --------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." --------------------------------------------------------------------- From rpresuhn@peer.com Thu Oct 30 14:06:27 1997 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA173459187 for ; Thu, 30 Oct 1997 14:06:27 -0800 Date: Thu, 30 Oct 1997 14:06:27 -0800 From: Randy Presuhn Return-Path: Message-Id: <199710302206.AA173459187@dorothy.peer.com> To: agentx@peer.com Subject: Re: New version of agentx Mib draft (02) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > Date: Thu, 30 Oct 1997 12:48:41 -0800 > From: dfrancis@santa.cisco.com (Dale Francisco) > Message-Id: <199710302048.MAA22895@marvell.cisco.com> > To: rpresuhn@peer.com, sgudur@peer.com > Subject: Re: New version of agentx Mib draft (02) > Cc: agentx@peer.com ... > I agree there's nothing to be done about BITS, and as > to the "must be defined with a syntax that includes a > range" error, I assume (but do not know) that this > stems from the v2 SMI's injunction to avoid 0-valued > index objects. So, I bet a range of 1..maxUint32 would > make SMIC contented and happy. ... You're probably right. Although RFC 1902 clause 7.7 is advisory rather than normative, using "should" rather than "must", who knows what the MIB checker has in mind. :-) | Instances identified by use of integer-valued objects should be | numbered starting from one (i.e., not from zero). The use of zero as | a value for an integer-valued index object should be avoided, except | in special cases. Sounds like something thrown in to make FORTRAN IV programmers happy. :-) I don't see any particular value to prohibiting or distinguishing zero as an index value in this case, since there appears to be a strong logical dependency between connections, sessions, and registrations. (In other MIBs, zero proved useful as a sentinel value for unsatisfied relationships.) Your suggstion to subtype to (1 .. 4294967295) sounds like an easy way forward. --------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA --------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." --------------------------------------------------------------------- From acec.com!natale@aceccomm.com Thu Oct 30 14:42:26 1997 Received: from cashew.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA186971345 for ; Thu, 30 Oct 1997 14:42:25 -0800 Return-Path: Received: (from uucp@localhost) by cashew.bmc.com (8.8.6/8.8.6) id QAA28167; Thu, 30 Oct 1997 16:42:23 -0600 (CST) Received: from relay1.smtp.psi.net(38.8.14.2) by cashew.bmc.com via smap (V2.0) id xma028157; Thu, 30 Oct 97 16:42:04 -0600 Received: from nips.acec.com by relay1.smtp.psi.net (8.8.5/SMI-5.4-PSI) id RAA10848; Thu, 30 Oct 1997 17:41:54 -0500 (EST) Received: from bnatale by nips.acec.com (5.65/3.2.083191-ACE*COMM) id AA17015; Thu, 30 Oct 1997 17:43:16 -0500 Message-Id: <3.0.1.32.19971030174357.009713e0@nips.acecomm.com> X-Sender: natale@nips.acecomm.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 30 Oct 1997 17:43:57 -0500 To: Randy Presuhn From: Bob Natale Subject: Re: New version of agentx Mib draft (02) Cc: agentx@peer.com In-Reply-To: <199710302146.AA168867970@dorothy.peer.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" >At 01:46 PM 10/30/97 -0800, Randy Presuhn wrote: Hi Randy, <...> >The agentx protocol leaves the length of agentxRegContext unconstrained. >Would it make sense to tighten up the MIB representation to align with >VACM's notion of context? > > PRO: would probably be more consistent > > CON: the protocol would permit contest names > that the MIB could not represent I'd vote the PRO option here...for consistency, for synergy with an eventual SNMPv3, and for enhanced guidance to implementors. The CON (if I understand your point correctly) is something we encounter in general anyway...the MIB, in this case, should take precedence. Cordially, BobN ----- ISO 9001 Registered Hardware and Software Divsions ---- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ---- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ---- ------ NetPlus (r) "FCAPS" Telemanagement Applications ------ From acec.com!natale@aceccomm.com Thu Oct 30 15:28:38 1997 Received: from almond.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA217114116 for ; Thu, 30 Oct 1997 15:28:36 -0800 Return-Path: Received: (from uucp@localhost) by almond.bmc.com (8.8.6/8.8.6) id RAA23376 for ; Thu, 30 Oct 1997 17:28:34 -0600 (CST) Received: from relay1.smtp.psi.net(38.8.14.2) by almond.bmc.com via smap (V2.0) id xma023359; Thu, 30 Oct 97 17:28:09 -0600 Received: from nips.acec.com by relay1.smtp.psi.net (8.8.5/SMI-5.4-PSI) id SAA28715; Thu, 30 Oct 1997 18:28:05 -0500 (EST) Received: from bnatale by nips.acec.com (5.65/3.2.083191-ACE*COMM) id AA17671; Thu, 30 Oct 1997 18:29:26 -0500 Message-Id: <3.0.1.32.19971030183007.00955c10@nips.acecomm.com> X-Sender: natale@nips.acecomm.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Thu, 30 Oct 1997 18:30:07 -0500 To: agentx@peer.com From: Bob Natale Subject: New e-mail and archive instructions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi, The AgentX e-mail list is now officially: agentx@peer.com Admin requests (subscribe/unsubscribe) must be addressed to: agentx-request@peer.com I recommend putting the requested action in both the "Subject:" header and the body text. An AgentX FTP repository has been established: ftp://ftp.peer.com/pub/agentx And the archives are in: ftp://ftp.peer.com/pub/agentx/archives The files in this directory are archives of the traffic that has flowed over the agentx mailing list. They are named by year and month, in the format YYYY-MM. The current month's traffic is accumulated in the file "current", which may actually lag behind the list's traffic by a few days. (this is a temporary situation) The files from 1995-11 to 1997-10 are from the distribution list. More recent files are from the distribution list. Peer/BMC personnel may issue additional instructions and/or information about use of these resources from time to time. I will get the IETF AgentX WG web page info updated asap. Thanks again to Peer/BMC for providing these resources, to First Virtual for having done so hitherto, and to the University at Buffalo, Cisco, and Center Technology for volunteering to do so. Cordially, BobN ----- ISO 9001 Registered Hardware and Software Divsions ---- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ---- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ---- ------ NetPlus (r) "FCAPS" Telemanagement Applications ------ From 7i9l04ok1z1@aol.com Sun Nov 9 15:13:00 1997 Received: from cashew.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA261347180 for ; Sun, 9 Nov 1997 15:13:00 -0800 Return-Path: <7i9l04ok1z1@aol.com> Received: (from uucp@localhost) by cashew.bmc.com (8.8.6/8.8.6) id RAA18197 for ; Sun, 9 Nov 1997 17:12:58 -0600 (CST) From: 7i9l04ok1z1@aol.com Received: from gauntlet.fv.com(207.67.199.118) by cashew.bmc.com via smap (V2.0) id xma018189; Sun, 9 Nov 97 17:12:42 -0600 Received: (from uucp@localhost) by gauntlet.fv.com (8.8.8/8.8.8) id PAA07466 for ; Sun, 9 Nov 1997 15:07:49 -0800 (PST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma007427; Sun, 9 Nov 97 15:07:27 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.8/8.8.8) with ESMTP id PAA04188 for ; Sun, 9 Nov 1997 15:12:07 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.8/8.8.8) id PAA07410 for ; Sun, 9 Nov 1997 15:07:18 -0800 (PST) Date: Sun, 9 Nov 1997 15:07:18 -0800 (PST) Received: from mtigwc04.worldnet.att.net(204.127.131.33) by gauntlet.fv.com via smap (3.2) id xma007398; Sun, 9 Nov 97 15:06:52 -0800 Received: from [12.64.117.34] by mtigwc04.worldnet.att.net (post.office MTA v2.0 0613 ) with SMTP id AAA7416 for ; Sun, 9 Nov 1997 23:11:40 +0000 To: 7i9l04ok1z1@aol.com Comments: Authenticated sender is <7i9l04ok1z1@aol.com> Subject: Wet Bathroom Floors Message-Id: <199711092041WAA22505@post.worldnet.att.net> PREVENT WET BATHROOM FLOORS use SHOWER EASE Shower Ease is a super absorbent, self drying foam bath mat that prevents wet bathroom floors and extra wet towels. To use, place the bath mat close to the base of the shower or bathtub. After showering or bathing just step onto the non-skid self drying bath mat and dry off as usual. After drying yourself thoroughly, place the Shower Ease in an up-right position in the shower or bathtub area. The Shower Ease never needs to be washed or squeezed. The Shower Ease is injected with a germicide to prevent fungi including athletes foot. Guaranteed not to mildew, smell or dry rot, the Shower Ease requires almost no maintenance. Use Shower Ease and you will be pleased. End wet bathroom floors forever. Safe non-skid base - mildew / mold resistant Shower Ease has been featured on television shopping services. Price: Shower Ease normally sells for $19.95 but with this special E-mail promotion we can offer the Shower Ease for $9.95 + $5.00 shipping and handling. You save $10.00 while supplies last. It makes a great gift for the holidays or any special gift giving occasion. Order: To place your order call 1-800-291-8957 day or night. Visa / Master Card, or Discover Cards accepted. Shower Ease is a product of Sandyco Inc From gpg@t-1net.com Mon Nov 10 21:52:29 1997 Received: from cashew.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA295597549 for ; Mon, 10 Nov 1997 21:52:29 -0800 Return-Path: Received: (from uucp@localhost) by cashew.bmc.com (8.8.6/8.8.6) id XAA26707 for ; Mon, 10 Nov 1997 23:52:27 -0600 (CST) From: gpg@t-1net.com Received: from gauntlet.fv.com(207.67.199.118) by cashew.bmc.com via smap (V2.0) id xma026699; Mon, 10 Nov 97 23:52:12 -0600 Received: (from uucp@localhost) by gauntlet.fv.com (8.8.8/8.8.8) id VAA09081 for ; Mon, 10 Nov 1997 21:45:57 -0800 (PST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma009070; Mon, 10 Nov 97 21:45:32 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.8/8.8.8) with ESMTP id VAA12008; Mon, 10 Nov 1997 21:49:03 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.8/8.8.8) id VAA08982; Mon, 10 Nov 1997 21:42:57 -0800 (PST) Received: from ryan.t-1net.com(208.21.213.20) by gauntlet.fv.com via smap (3.2) id xma008975; Mon, 10 Nov 97 21:42:52 -0800 Received: by ryan.t-1net.com (8.8.7/8.8.7) with SMTP id AAA13065 Date: Tue, 11 Nov 1997 00:28:24 -0600 Message-Id: <199711110628.AAA13065@ryan.t-1net.com> To: gpg@t-1net.com Subject: A complete turn-key home biz I own and operate a lucrative home business. It generates $2,000-$3,000 per week. It does not involve selling in the traditional sense and it is not MLM. Cold calling is not necessary, nor is shipping or an inventory required. Our unique method of marketing, combined with your commitment and determination is what makes this business a success. For information e-mail: gpg@t-1net.com /////////////////////////////////////////////////////////////////////////////// If you wish to be removed from my future mailings, please reply with the word "Remove" in the subject heading and this software will automatically block you from further mailings. //////////////////////////////////////////////////////////////////////////////// From andreab@ntsrv02.group.nl Thu Nov 13 00:39:31 1997 Received: from cashew.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA010280370 for ; Thu, 13 Nov 1997 00:39:30 -0800 Return-Path: Received: (from uucp@localhost) by cashew.bmc.com (8.8.6/8.8.6) id CAA28265 for ; Thu, 13 Nov 1997 02:39:29 -0600 (CST) Received: from ns.nl.net(193.78.240.1) by cashew.bmc.com via smap (V2.0) id xma028259; Thu, 13 Nov 97 02:39:18 -0600 Received: from guide by ns.NL.net (5.65b/NLnet1.3) id AA07167; Thu, 13 Nov 1997 09:11:31 +0100 Received: from ntsrv02 by guide.group.nl id aa12630; 13 Nov 97 9:00 CET Received: by NTSRV02 with Internet Mail Service (5.0.1457.3) id ; Thu, 13 Nov 1997 09:01:46 +0100 Message-Id: From: Andrea Bonetta To: agentx@peer.com Subject: subscribe SNMP andreab@group.nl Date: Thu, 13 Nov 1997 09:01:16 +0100 X-Priority: 3 Mime-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain subscribe SNMP andreab@group.nl From Sudheendra.Harwalker@COMPAQ.com Thu Nov 13 06:32:34 1997 Received: from cashew.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA124481553 for ; Thu, 13 Nov 1997 06:32:33 -0800 Return-Path: Received: (from uucp@localhost) by cashew.bmc.com (8.8.6/8.8.6) id IAA09639 for ; Thu, 13 Nov 1997 08:32:30 -0600 (CST) Received: from mailext02.compaq.com(207.18.199.33) by cashew.bmc.com via smap (V2.0) id xma009624; Thu, 13 Nov 97 08:32:02 -0600 Received: from mail.compaq.com(really [207.18.199.36]) by mailext02.compaq.com via sendmail with smtp id for ; Thu, 13 Nov 1997 08:28:42 -0600 (CST) (Smail-3.2.0.92 1997-Feb-9 #2 built 1997-Sep-10) Received: from exchou-conn01.im.hou.compaq.com(really [172.18.22.253]) by mail.compaq.com via sendmail with smtp id for ; Thu, 13 Nov 97 08:31:15 -0600 (CST) (/\##/\ Smail3.1.30.16 #30.2 built 25-may-96) Received: by exchou-conn01.im.hou.compaq.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BCF00E.367A14B0@exchou-conn01.im.hou.compaq.com>; Thu, 13 Nov 1997 08:29:09 -0600 Message-Id: From: "Harwalker, Sudheendra" To: "'agentx@peer.com'" Subject: subscribe SNMP Sudheendra.Harwalker@Compaq.com Date: Thu, 13 Nov 1997 08:29:07 -0600 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit subscribe SNMP Sudheendra.Harwalker@Compaq.com > From bnatale@acecomm.com Thu Nov 13 08:54:00 1997 Received: from cashew.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA127240039 for ; Thu, 13 Nov 1997 08:53:59 -0800 Return-Path: Received: (from uucp@localhost) by cashew.bmc.com (8.8.6/8.8.6) id KAA17801 for ; Thu, 13 Nov 1997 10:53:57 -0600 (CST) Received: from relay1.smtp.psi.net(38.8.14.2) by cashew.bmc.com via smap (V2.0) id xma017768; Thu, 13 Nov 97 10:53:26 -0600 Received: from nips.acec.com by relay1.smtp.psi.net (8.8.5/SMI-5.4-PSI) id LAA20076; Thu, 13 Nov 1997 11:52:25 -0500 (EST) Received: from bnatale by nips.acec.com (5.65/3.2.083191-ACE*COMM) id AA07150; Thu, 13 Nov 1997 11:53:49 -0500 Message-Id: <3.0.5.32.19971113115414.0092ca20@nips.acecomm.com> X-Sender: natale@nips.acecomm.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 13 Nov 1997 11:54:14 -0500 To: Andrea Bonetta , "Harwalker, Sudheendra" From: Bob Natale Subject: Admin requests to AgentX e-mail list Cc: agentx@peer.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi Andrea and Sudheendra, We are all glad to have you join the AgentX list. However, please note that the correct address for admin requests (such as subscribe and unsubscribe) is agentx-request@peer.com I cannot say for sure whether the good people at Peer/BMC who provide the list server and administrative services will pick up your original requests so, unless you have received notification from them that you are now subscribed, please re-send your request to agentx-request@peer.com. Three more points: 1. I am cc'ing the whole list on this since the switch to Peer is fairly recent and others might not have noted the new admin address (tell your friends! :-), and 2. Did either of you (Andrea or Sudheendra) see instructions somewhere else that caused you to send your request to the list address itself? If so, I'd like to go to that source and get it fixed. 3. For some content: We are still progressing through the IESG process. We are still hopeful of having an announcement prior to the December IETF meeting. Thanks. Cordially, BobN ----- ISO 9001 Registered Hardware and Software Divsions ---- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ---- WinSNMP DLL, SDK, Apps & Agents for Win16/32 & UNIX ---- ------ NetPlus (r) "FCAPS" Telemanagement Applications ------ From sgudur@peer.com Thu Nov 13 17:49:59 1997 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA161462199 for ; Thu, 13 Nov 1997 17:49:59 -0800 From: Smitha Gudur Return-Path: Message-Id: <199711140149.AA161462199@dorothy.peer.com> Subject: draft-ietf-agentx-mib-01.txt To: agentx@peer.com Date: Thu, 13 Nov 1997 17:49:59 PST Cc: sgudur@peer.com X-Mailer: Elm [revision: 111.1] Hi, This is the revised draft based on the discussion on the mailing list. This is has been submitted to IETF. Please direct questions, comments to agentx@peer.com Thanks Smitha INTERNET-DRAFT M. Greene Ascom Nexion, Inc. S. Gudur BMC Software, Inc. 13 November 1997 Definitions of Managed Objects for Extensible SNMP Agents | Status of this Memo This document is an Internet-Draft. Internet-Drafts are working doc- uments of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute work- ing 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 mate- rial or to cite them other than as a "work in progress". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Copyright Notice | Copyright (C) The Internet Society (1997). 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 April 1998 [Page 1] Internet Draft AgentX MIB 13 November 1997 1. The SNMP Network Management Framework The SNMP Network Management Framework presently consists of three major components. They are: - the SMI, described in RFC 1902 [1] - the mechanisms used for describing and naming objects for the purpose of management. - the MIB-II, STD 17, RFC 1213 [2] - the core set of managed objects for the Internet suite of protocols. - the protocol, RFC 1157 [3] and/or RFC 1905 [4], - the protocol for accessing managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. 1.1. Object Definitions Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the subset of Abstract Syntax Notation One (ASN.1) defined in the SMI. In particular, each object type is named by an OBJECT IDENTIFIER, an administratively assigned name. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the descriptor, to also refer to the object type. 2. Introduction The SNMP Agent Extensibility Protocol (AgentX) is a protocol used to distribute the implementation of an SNMP agent amongst a single "master agent" and multiple "subagents". See [5] 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. Provide statistics about the protocol operation such as the number of packets to and from each subagent. AgentX Working Group Expires April 1998 [Page 2] Internet Draft AgentX MIB 13 November 1997 - 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. 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 and the supported transport ! mechanisms. 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 represented through the agentxRegSessionIndex object in a registration entry. To determine which session is responsible for a given registration entry, a manager can retrieve the value of agentxRegSessionIndex for that entry, and then use that value to retrieve the corresponding row of the session table. To determine which registration(s), if any, a given subagent session is responsible for, a manager can scan the registration table for entries in which agentxRegSessionIndex matches the value of the agentxSessionIndex of the session in question. Entries in the session table exist in a many-to-one relationship with entries in the connection table. This relationship is represented through the agentxSessionConnIndex object in a session entry. To determine which connection is carrying a given session, a manager can retrieve the value of agentxSessionConnIndex for that entry, and then use that value to retrieve the corresponding row of the connection table. To determine which session(s), if any, a given connection is carrying, a manager can scan the connection table for entries in which agentxSessionConnIndex matches the value of the agentxConnIndex ! of the connection in question. AgentX Working Group Expires April 1998 [Page 3] Internet Draft AgentX MIB 13 November 1997 4. Definitions AGENTX-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, experimental, Counter32, Gauge32, Unsigned32 ! FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF TEXTUAL-CONVENTION, TimeStamp FROM SNMPv2-TC; agentxMIB MODULE-IDENTITY LAST-UPDATED "9710221200Z" -- October 22, 1997 | ORGANIZATION "IETF AgentX Working Group" CONTACT-INFO "WG-email: agentx@fv.com | Subscribe: agentx-request@fv.com | http://www.ietf.org/html.charters/agentx-charter.html | Chair: Bob Natale | ACE*COMM Corporation | Email: bnatale@acec.com | Editor: Smitha Gudur | BMC Software, Inc. | 1190 Saratoga Avenue | San Jose, CA 95129 | Phone: +1 408-556-0720 | Email: sgudur@bmc.com | " DESCRIPTION "This is the MIB module for the SNMP Agent Extensibility Protocol (AgentX). This MIB module will be implemented by the master agent." -- For testing purposes only. Need to get an experimental id ::= { experimental 2001 } agentxObjects OBJECT IDENTIFIER ::= { agentxMIB 1 } -- -- Define the four groups that serve to organize the -- objects in this MIB -- agentxGeneral OBJECT IDENTIFIER ::= { agentxObjects 1 } agentxConnection OBJECT IDENTIFIER ::= { agentxObjects 2 } AgentX Working Group Expires April 1998 [Page 4] Internet Draft AgentX MIB 13 November 1997 agentxSession OBJECT IDENTIFIER ::= { agentxObjects 3 } agentxRegistration OBJECT IDENTIFIER ::= { agentxObjects 4 } -- -- Textual Conventions -- Utf8String ::= TEXTUAL-CONVENTION DISPLAY-HINT "255a" STATUS current DESCRIPTION "To facilitate internationalization, this TC represents information taken from the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 character encoding scheme described in RFC 2044 [8]. For strings in 7-bit US-ASCII, there is no impact since the UTF-8 representation is identical to the US-ASCII encoding." SYNTAX OCTET STRING (SIZE (0..255)) 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..256) MAX-ACCESS read-only STATUS current DESCRIPTION "The AgentX protocol version supported by this master agent. Current version is 1. Note that the master agent must allow registration of earlier version subagents." DEFVAL { 1 } ::= { agentxGeneral 2 } agentxMasterTransports OBJECT-TYPE SYNTAX BITS { unixDomainSockets(0), tcp(1), AgentX Working Group Expires April 1998 [Page 5] Internet Draft AgentX MIB 13 November 1997 udp(2), sharedMem(3), other(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The transports that the master agent supports." DEFVAL { { tcp } } ! ::= { agentxGeneral 3 } -- ! -- 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 } ! agentxConnNumber OBJECT-TYPE ! SYNTAX Gauge32 ! MAX-ACCESS read-only ! STATUS current ! DESCRIPTION ! "The current number of entries in the agentxConnectionTable. Note! that this may be smaller than the largest value of agentxConnIndex! since index values are not reused when entries come and go from ! the agentxConnectionTable." ! ::= { agentxConnection 2 } ! 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 ! on a given Agentx connection." ! ::= { agentxConnection 3 } ! AgentxConnectionEntry ::= SEQUENCE { ! agentxConnIndex Unsigned32, ! agentxConnOpenTime TimeStamp, ! agentxConnTransportType INTEGER, ! AgentX Working Group Expires April 1998 [Page 6] Internet Draft AgentX MIB 13 November 1997 agentxConnTransportAddr OCTET STRING, ! agentxConnSessions Gauge32 } ! 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. Entries come ! into being when the transport connection is established, ! and are not deleted unless the transport connection has ! been terminated." ! INDEX { agentxConnIndex } ! ::= { agentxConnectionTable 1 } ! agentxConnIndex OBJECT-TYPE ! SYNTAX Unsigned32 ! MAX-ACCESS not-accessible ! STATUS current ! DESCRIPTION ! "The value of agentxConnIndex uniquely identifies each ! 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 } agentxConnTransportType OBJECT-TYPE SYNTAX INTEGER { unixDomainSockets(1), tcp(2), udp(3), sharedMem(4), other(5) } MAX-ACCESS read-only STATUS current DESCRIPTION AgentX Working Group Expires April 1998 [Page 7] Internet Draft AgentX MIB 13 November 1997 "The transport protocol in use for this connection to the master agent. This information can be used by a management application to determine how agentxConnTransportAddr should be displayed." ::= { agentxConnectionEntry 3 } agentxConnTransportAddr OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The transport address of the remote (subagent) end of this connection to the master agent, in network byte order. Management applications can use agentxConnTransportType to determine how this information is to be formatted for display." ::= { agentxConnectionEntry 4 } agentxConnSessions OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of AgentX sessions being carried by this transport connection. For purposes of this MIB, an AgentX session begins when a valid agentx-Open-PDU is received, and ends when a corresponding agentx-Close-PDU has been sent or received by the master agent." ::= { agentxConnectionEntry 5 } -- -- 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 } agentxSessionNumber OBJECT-TYPE SYNTAX Gauge32 ! MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of entries in the AgentX Working Group Expires April 1998 [Page 8] Internet Draft AgentX MIB 13 November 1997 agentxSessionTable. Note that this may be smaller than the largest value of agentxSessionIndex since index values are not reused when entries come and go from the agentxSessionTable." ::= { agentxSession 2 } -- -- The AgentX Subagent Session Table -- agentxSessionTable OBJECT-TYPE SYNTAX SEQUENCE OF AgentxSubagentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of AgentX subagents that have open sessions with the AgentX master agent." ::= { agentxSession 3 } agentxSessionEntry OBJECT-TYPE SYNTAX AgentxSubagentEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about a single open session between the AgentX master agent and a subagent." INDEX { agentxSessionIndex } ::= { agentxSessionTable 1 } AgentxSubagentEntry ::= SEQUENCE { agentxSessionIndex Unsigned32, agentxSessionObjectID OBJECT IDENTIFIER, agentxSessionDescr Utf8String, agentxSessionAdminStatus INTEGER, agentxSessionOpenTime TimeStamp, agentxSessionAgentXVer INTEGER, agentxSessionTimeout INTEGER, agentxSessionConnIndex Unsigned32 ! } agentxSessionIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique index for the subagent session. 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 not be contiguous and AgentX Working Group Expires April 1998 [Page 9] Internet Draft AgentX MIB 13 November 1997 will generally not be the same for the same subagent across multiple sessions. Index values assigned for a given registration are constant for the lifetime of this table" ::= { agentxSessionEntry 1 } agentxSessionObjectID OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "This is analogous to sysObjectID defined in MIB-2 [2] and is taken from the o.id field of the agentx-Open-PDU." ::= { agentxSessionEntry 2 } -- -- Issue: should we describe this more in terms of AGENT-CAPABILITIES -- or sysORTable? -- agentxSessionDescr OBJECT-TYPE SYNTAX Utf8String 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'). When read, the value returned is always 'up(1)'." DEFVAL { up } ::= { agentxSessionEntry 4 } agentxSessionOpenTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current AgentX Working Group Expires April 1998 [Page 10] Internet Draft AgentX MIB 13 November 1997 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..256) 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." DEFVAL { 1 } ::= { 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 '0' indicates that the master agent's default timeout value should be used (see agentxDefaultTimeout)." DEFVAL { 0 } ::= { agentxSessionEntry 7 } agentxSessionConnIndex OBJECT-TYPE ! SYNTAX Unsigned32 ! MAX-ACCESS read-only ! STATUS current ! DESCRIPTION ! "The agentxSessionConnIndex attribute identifies the entry ! in the agentxConnectionTable for the connection on which ! this session is carried. This attribute's value is ! constant for the lifetime of a given session. Multiple ! sessions, if carried by the same transport connection, will ! have the same value for this attribute." ! ::= { agentxSessionEntry 8 } ! AgentX Working Group Expires April 1998 [Page 11] Internet Draft AgentX MIB 13 November 1997 -- -- The AgentX Registration Information group -- -- The statistics in this group are maintained by the Master Agent. -- -- Other stats have been removed. Support trap generation based -- on certain situations for duplicate registration. -- 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 } -- -- The AgentX Registration Table -- agentxRegistrationTable OBJECT-TYPE SYNTAX SEQUENCE OF AgentxRegistrationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table of registered OBJECT IDENTIFIER regions. This is the table used to identify a registered region of a subagent. Note that a subagent registration may be broken up into multiple entries in this table, as described in the AgentX Protocol specification [5]." ::= { agentxRegistration 2 } agentxRegistrationEntry OBJECT-TYPE SYNTAX AgentxRegistrationEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A single registered region. Regions are added by the master agent when subagents register and are removed from the table when the subagents unregister the region or their sessions are closed. Note that the combination of agentxRegContext, agentxRegStart and agentxRegDispatchOrder will be unique and could have been used for indexing purposes, but would have potentially resulted in excessively long OBJECT IDENTIFIERs." INDEX { agentxRegIndex } ::= { agentxRegistrationTable 1 } AgentX Working Group Expires April 1998 [Page 12] Internet Draft AgentX MIB 13 November 1997 AgentxRegistrationEntry ::= SEQUENCE { agentxRegIndex Unsigned32, agentxRegContext OCTET STRING, agentxRegStart OBJECT IDENTIFIER, agentxRegEnd OBJECT IDENTIFIER, agentxRegPriority Unsigned32, agentxRegSessionIndex Unsigned32, agentxRegTimeout INTEGER } agentxRegIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "AgentxRegIndex is an integer that uniquely identifies a registration entry. Its 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 agentxRegSessionIndex 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 } agentxRegEnd OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "The ending OBJECT IDENTIFIER of this registration entry. The subagent identified by agentxRegSessionIndex implements AgentX Working Group Expires April 1998 [Page 13] Internet Draft AgentX MIB 13 November 1997 objects up to but not including this value. Note that this value could identify an object type, an object instance, or a partial object instance." ! ::= { agentxRegistrationEntry 4 } -- -- To support other subagent types that can be visible -- to the manager. -- 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." DEFVAL { 255 } ::= { agentxRegistrationEntry 5 } agentxRegSessionIndex OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of agentxSessionIndex for the subagent that registered this OID range." ::= { agentxRegistrationEntry 6 } agentxRegTimeout OBJECT-TYPE SYNTAX INTEGER (0..255) UNITS "seconds" ! MAX-ACCESS read-only STATUS current DESCRIPTION "The timeout value, in seconds, for subagent responses to requests associated with this OID range. The value '0' indicates that 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." DEFVAL { 0 } ::= { agentxRegistrationEntry 7 } -- -- Conformance Statements for the AgentX MIB -- agentxConformance OBJECT IDENTIFIER ::= { agentxMIB 2 } agentxMIBGroups OBJECT IDENTIFIER ::= { agentxConformance 1 } AgentX Working Group Expires April 1998 [Page 14] Internet Draft AgentX MIB 13 November 1997 agentxMIBCompliances OBJECT IDENTIFIER ::= { agentxConformance 2 } 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." OBJECT agentxSessionAdminStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required." ::= { agentxMIBCompliances 1 } agentxMIBGroup OBJECT-GROUP OBJECTS { agentxDefaultTimeout, agentxMasterAgentXVer, agentxMasterTransports, agentxConnTableLastChange, ! agentxConnNumber, ! agentxConnOpenTime, ! agentxConnTransportType, ! agentxConnTransportAddr, ! agentxConnSessions, ! agentxSessionTableLastChange, agentxSessionNumber, agentxSessionTimeout, agentxSessionObjectID, agentxSessionDescr, agentxSessionAdminStatus, agentxSessionOpenTime, agentxSessionAgentXVer, agentxSessionConnIndex, agentxRegisterDuplicate, agentxRegContext, agentxRegStart, agentxRegEnd, AgentX Working Group Expires April 1998 [Page 15] Internet Draft AgentX MIB 13 November 1997 agentxRegPriority, agentxRegSessionIndex, agentxRegTimeout } STATUS current DESCRIPTION "All accessible objects in the AgentX MIB." ::= { agentxMIBGroups 1 } END 5. Acknowledgments This document is a product of the IETF's AgentX Working Group. Special acknowledgement is made to: Maria Greene Ascom Nexion 289 Great Road Acton, MA 01720 USA Phone: +1 508-266-4570 EMail: greene@nexen.com 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 [6]. 6. References [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance Systems International, March 1991. [3] 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. AgentX Working Group Expires April 1998 [Page 16] Internet Draft AgentX MIB 13 November 1997 [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., International Network Services, January 1996. [5] Daniele, M., Wijnen, B., and D. Francisco, "Agent Extensibility (AgentX) Protocol, Version 1", draft-ietf-agentx-ext-pro-01.txt, Digital Equipment Corporation, T.J. Watson Research Center, IBM Corp., Cisco Systems, November, 1996. [6] Rose, M., "SNMP MUX Protocol and MIB", RFC1227, Performance Systems International, Inc., May 1991. [7] Wijnen, B., Carpenter, G., Curran, K., Sehgal, A., and G. Waters, "Simple Network Management Protocol: Distributed Protocol Interface, Version 2.0", RFC 1592, T.J. Watson Research Center, IBM Corp., Bell Northern Research, Ltd., March 1994. [8] F. Yergeau, "UTF-8, a transformation format of Unicode and ISO 10646,", RFC 2044, October 1996. 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 | agentxSAAdminStatus. Setting agentxDefaultTimeout to an | inappropriately small value can prevent new subagent sessions from | being usable. Setting agentxSAAdminStatus 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 | AgentX Working Group Expires April 1998 [Page 17] Internet Draft AgentX MIB 13 November 1997 access. | 8. Editor's Address Smitha Gudur BMC Software, Inc. 1190 Saratoga Avenue, Suite 130 San Jose, CA 95129-3433 USA Phone: +1 408-556-0720 EMail: sgudur@bmc.com 9. Full Copyright Statement | Copyright (C) The Internet Society (1997). 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 implmentation 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 April 1998 [Page 18] From sar@epilogue.com Thu Nov 13 19:35:01 1997 Received: from almond.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA242378500 for ; Thu, 13 Nov 1997 19:35:00 -0800 Return-Path: Received: (from uucp@localhost) by almond.bmc.com (8.8.6/8.8.6) id VAA26047 for ; Thu, 13 Nov 1997 21:34:58 -0600 (CST) Received: from khitomer.epilogue.com(128.224.1.172) by almond.bmc.com via smap (V2.0) id xma026045; Thu, 13 Nov 97 21:34:53 -0600 From: "Shawn A. Routhier" Sender: sar@khitomer.epilogue.com To: agentx@peer.com Cc: sar@epilogue.com Subject: Comments on agentx mib from 22 october Date: Thu, 13 Nov 97 22:34:52 -0500 Message-Id: <9711132234.aa28297@khitomer.epilogue.com> 1) When Randy originally mentioned having a connection table I had thought it was an acceptable idea. After thinking about it more I concluded that it really seems to be outside of the scope of agentx to understand what the layers underneath it are doing. This table would require an agentx engine to understand if it were running on top of tcp or udp or something else and to be able to determine information from that layer before any agentx messages have been exchanged. For example the agentx entity would need to be able to determine from the tcp layer that a connection has been established even if an open message hasn't been received. As I fail to see a major use for this table (as opposed to the address of the sub agent) and this sort of information may be difficult to determine for some types of layers and in some implementations I really don't think it is necessary. I think it would be more useful to return to having the address information in the session table. 2) I think that the description of the transport address needs to be better no matter what table it ends up in. The current description basically says "network byte order". Does that include port numbers for tcp & udp? do the port numbers come before or after the ip address? is the address in binary form? (the answer to the last seems to be yes given the network byte order comment). What about a unix socket, how is that represented? 3) I'm not sure I understand the use of agentxRegEnd. It seems that it should be the end of the registered entry as of the time of registration. I think in most cases that will be the immediate sibling of agenxRegStart. That is if agentxRegStart = a.b.c.d then most of the time agentxRegEnd = a.b.c.(d+1). There are three cases I can think of a) register a single object a.b.c.d b) register a set of objects a.b.c.[d ... e] c) register a set of objects with instance a.b.c.[d ... e].f a) is straightforward, because there are gaps between the instance for c) it becomes a series of entries, the first one starts at a.b.c.d.f and ends at a.b.c.d.f+1 the last is a.b.c.d.e.f to a.b.c.d.e.f+1 this leaves b). which in many sub agents should really be registering a.b.c (according to the suggestion to register as high in the tree as possible) in this case we end up with a). In some cases we would have a contiguous series of objects which would benefit from the start and end objects, but I think that most of the time we wouldn't and it would be cheaper to turn those cases into a series of entries rather than trying to have a single entry for them. Alternatively I would propose that the null object id (0.0) be used for the ending object to indicate that the start object is a root of a tree rather than the start of a range. 4) In conjunction with 3), what happens to regIndex if a sub agent de registers an object in the middle of a range? That is a sub agent registers a.b.c.1-10.d and then de registers a.b.c.5.d. 5) I'd also like to point out that the choice of an index for the registration table means that a manager will need to retrieve the entire table to determine what sub agent is actually handling a given object id. This seems somewhat inefficient. regards, sar From rpresuhn@peer.com Fri Nov 14 09:41:55 1997 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA195759315 for ; Fri, 14 Nov 1997 09:41:55 -0800 Date: Fri, 14 Nov 1997 09:41:55 -0800 From: Randy Presuhn Return-Path: Message-Id: <199711141741.AA195759315@dorothy.peer.com> To: agentx@peer.com Subject: transport representation (Was: Re: Comments on agentx mib from 22 october) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > From: "Shawn A. Routhier" > To: agentx@peer.com > Cc: sar@epilogue.com > Subject: Comments on agentx mib from 22 october > Date: Thu, 13 Nov 97 22:34:52 -0500 > Message-Id: <9711132234.aa28297@khitomer.epilogue.com> ... > 2) I think that the description of the transport address needs to > be better no matter what table it ends up in. The current > description basically says "network byte order". Does that > include port numbers for tcp & udp? do the port numbers come > before or after the ip address? is the address in binary form? > (the answer to the last seems to be yes given the network byte > order comment). What about a unix socket, how is that represented? I think it would help to align this with the style used in . Unfortunately, TDomain and TAddress in RFC 1903 seem to be tied to SNMP as an application layer protocol. I'm willing to be persuaded otherwise. --------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA --------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." --------------------------------------------------------------------- From rpresuhn@peer.com Fri Nov 14 09:35:55 1997 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA194888955 for ; Fri, 14 Nov 1997 09:35:55 -0800 Date: Fri, 14 Nov 1997 09:35:55 -0800 From: Randy Presuhn Return-Path: Message-Id: <199711141735.AA194888955@dorothy.peer.com> To: agentx@peer.com Subject: agentx connection table (Was: Re: Comments on agentx mib from 22 october) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > From: "Shawn A. Routhier" > To: agentx@peer.com > Cc: sar@epilogue.com > Subject: Comments on agentx mib from 22 october > Date: Thu, 13 Nov 97 22:34:52 -0500 > Message-Id: <9711132234.aa28297@khitomer.epilogue.com> ... > 1) When Randy originally mentioned having a connection table I had > thought it was an acceptable idea. After thinking about it more > I concluded that it really seems to be outside of the scope of > agentx to understand what the layers underneath it are doing. I agree that the agentx MIB should not delve unnecessarily into the underlying transport(s). However, it should permit reliable identification of those sessions being multiplexed over a particular transport connection, and provide enough information to identify it in the relevant transport protocol-specific MIB. > This table would require an agentx engine to understand if it > were running on top of tcp or udp or something else and to be > able to determine information from that layer before any > agentx messages have been exchanged. In order to set up the listen() (or equivalent) call to the underlying transport services, a master agent needs to be able to sufficiently identify what protocol(s) it's willing to accept connections on. Whether the master agent gets this information from command line, configuration file, non-volatile memory, getservbyname(), registry, or whatever, it needs to know the address family, address:port to listen to, and the protocol. > For example the agentx > entity would need to be able to determine from the tcp layer > that a connection has been established even if an open message > hasn't been received. With the transport APIs I'm familiar with, one has to do this anyway. For example, with BSD-style sockets, the master agent has to do a listen() before anything can connect to it, and an accept() before there's any data transfer. > As I fail to see a major use for this table (as opposed to > the address of the sub agent) and this sort of information > may be difficult to determine for some types of layers and > in some implementations I really don't think it is necessary. > I think it would be more useful to return to having the > address information in the session table. ... The connection table has these items: agentxConnIndex Unsigned32 agentxConnOpenTime TimeStamp agentxConnTransportType INTEGER agentxConnTransportAddr OCTET STRING agentxConnSessions Gauge32 There are two issues: utility and difficulty. Which present any difficulty? agentxConnIndex is assigned by the master agent; agentxConnOpenTime is known (looks the time of the listen() or accept() to me, though Smitha may have something else in mind); agentxConnTransportType and agentxConnTransportAddr we seem to agree would be useful. That leaves agentxConnSessions, which I would hope the master agent knows. Which of these are useful? We've gotten a lot of mileage out of the SMUX MIB, which only contains subagent identity and registration information, and has no transport information at all. Frankly, about the only times we use these MIBs is in regression tests (where they're VERY useful) and in trouble-shooting scenarios. --------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA --------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." --------------------------------------------------------------------- From rpresuhn@peer.com Fri Nov 14 10:06:43 1997 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA199190803 for ; Fri, 14 Nov 1997 10:06:43 -0800 Date: Fri, 14 Nov 1997 10:06:43 -0800 From: Randy Presuhn Return-Path: Message-Id: <199711141806.AA199190803@dorothy.peer.com> To: agentx@peer.com Subject: representing ranges (was: Re: Comments on agentx mib from 22 october) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > From: "Shawn A. Routhier" > To: agentx@peer.com > Cc: sar@epilogue.com > Subject: Comments on agentx mib from 22 october > Date: Thu, 13 Nov 97 22:34:52 -0500 > Message-Id: <9711132234.aa28297@khitomer.epilogue.com> ... > 3) I'm not sure I understand the use of agentxRegEnd. > It seems that it should be the end of the registered entry > as of the time of registration. I think in most cases that > will be the immediate sibling of agenxRegStart. That is > if agentxRegStart = a.b.c.d then most of the time > agentxRegEnd = a.b.c.(d+1). Hmmm. I think we have a problem when d is 4294967295. > There are three cases I can think of > > a) register a single object a.b.c.d > b) register a set of objects a.b.c.[d ... e] > c) register a set of objects with instance a.b.c.[d ... e].f > > a) is straightforward, because there are gaps between the > instance for c) it becomes a series of entries, the first > one starts at a.b.c.d.f and ends at a.b.c.d.f+1 the last > is a.b.c.d.e.f to a.b.c.d.e.f+1 > > this leaves b). which in many sub agents should really be > registering a.b.c (according to the suggestion to register > as high in the tree as possible) in this case we end up with a). Except in cases like the RDBMS MIB, application MIB, WWW MIB, and so on where different rows of a given table may be implemented by different subagents. > In some cases we would have a contiguous series of objects > which would benefit from the start and end objects, > but I think that most of the time we wouldn't and it would > be cheaper to turn those cases into a series of entries > rather than trying to have a single entry for them. Implementations certainly should have the flexibility to do their registrations that way, though I think the MIB should reflect what has been going on in the protocol. (This goes back to my comment about the use of this MIB in trouble-shooting scenarios.) > Alternatively I would propose that the null object id (0.0) > be used for the ending object to indicate that the start object > is a root of a tree rather than the start of a range. I like this idea. It would also circumvent the 4294967295 problem and reduce the bandwidth needed to walk this table for common configurations. > 4) In conjunction with 3), what happens to regIndex if a sub agent > de registers an object in the middle of a range? That is > a sub agent registers a.b.c.1-10.d and then de registers a.b.c.5.d. I think clause 7.1.6 (4) of the agentx protocol draft answers this question. The deregistration request should be rejected. > 5) I'd also like to point out that the choice of an index for the > registration table means that a manager will need to retrieve the > entire table to determine what sub agent is actually handling a > given object id. This seems somewhat inefficient. ... An indexing structure to optimize a query to identify which subagent would actually handle a given object ID would be pretty hairy, given the lexicographical ordering of object identifiers and the limitation on their length. In the SMUX MIB, the equivalent table is indexed by the registered tree and priority. Due to the lexicographical "ordering" of object identifiers, a similar problem exists there. The current index order makes all possible retrieval scenarios equally onerous. I'd suggest removing the agentxRegSessionIndex column and adding agentxSessionIndex as the first index of agentxRegistrationEntry. This would at least make it reasonably efficient to determine a given subagent's registrations, and would not make the query to identify which subagent would handle a given object identifier any worse. --------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA --------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." --------------------------------------------------------------------- From kzm@cisco.com Fri Nov 14 10:37:21 1997 Received: from almond.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA205882640 for ; Fri, 14 Nov 1997 10:37:20 -0800 Return-Path: Received: (from uucp@localhost) by almond.bmc.com (8.8.6/8.8.6) id MAA04165; Fri, 14 Nov 1997 12:37:18 -0600 (CST) Received: from foxhound.cisco.com(171.69.192.161) by almond.bmc.com via smap (V2.0) id xma004126; Fri, 14 Nov 97 12:37:06 -0600 Received: (kzm@localhost) by foxhound.cisco.com (8.8.4-Cisco.1/8.6.5) id KAA01143; Fri, 14 Nov 1997 10:36:41 -0800 (PST) From: Keith McCloghrie Message-Id: <199711141836.KAA01143@foxhound.cisco.com> Subject: Re: transport representation (Was: Re: Comments on agentx mib from 22 october) To: rpresuhn@peer.com (Randy Presuhn) Date: Fri, 14 Nov 1997 10:36:41 -0800 (PST) Cc: agentx@peer.com In-Reply-To: <199711141741.AA195759315@dorothy.peer.com> from "Randy Presuhn" at Nov 14, 97 09:41:55 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > > 2) I think that the description of the transport address needs to > > be better no matter what table it ends up in. The current > > description basically says "network byte order". Does that > > include port numbers for tcp & udp? do the port numbers come > > before or after the ip address? is the address in binary form? > > (the answer to the last seems to be yes given the network byte > > order comment). What about a unix socket, how is that represented? > > I think it would help to align this with the style used in > . Unfortunately, TDomain and > TAddress in RFC 1903 seem to be tied to SNMP as an application > layer protocol. I'm willing to be persuaded otherwise. The 1903 definitions use SNMP as examples, but are generic otherwise. Keith. From rpresuhn@peer.com Fri Nov 14 10:47:29 1997 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA218383249 for ; Fri, 14 Nov 1997 10:47:29 -0800 Date: Fri, 14 Nov 1997 10:47:29 -0800 From: Randy Presuhn Return-Path: Message-Id: <199711141847.AA218383249@dorothy.peer.com> To: agentx@peer.com Subject: Re: transport representation (Was: Re: Comments on agentx mib from 22 october) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > From: Keith McCloghrie > Message-Id: <199711141836.KAA01143@foxhound.cisco.com> > Subject: Re: transport representation (Was: Re: Comments on agentx mib from 22 october) > To: rpresuhn@peer.com (Randy Presuhn) > Date: Fri, 14 Nov 1997 10:36:41 -0800 (PST) > Cc: agentx@peer.com ... > > I think it would help to align this with the style used in > > . Unfortunately, TDomain and > > TAddress in RFC 1903 seem to be tied to SNMP as an application > > layer protocol. I'm willing to be persuaded otherwise. > > The 1903 definitions use SNMP as examples, but are generic otherwise. I'm persuaded. :-) --------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA --------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." --------------------------------------------------------------------- From sar@epilogue.com Fri Nov 14 10:50:12 1997 Received: from almond.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA219843411 for ; Fri, 14 Nov 1997 10:50:11 -0800 Return-Path: Received: (from uucp@localhost) by almond.bmc.com (8.8.6/8.8.6) id MAA06011 for ; Fri, 14 Nov 1997 12:50:09 -0600 (CST) Received: from khitomer.epilogue.com(128.224.1.172) by almond.bmc.com via smap (V2.0) id xma005802; Fri, 14 Nov 97 12:49:07 -0600 From: "Shawn A. Routhier" Sender: sar@khitomer.epilogue.com To: agentx@peer.com Cc: sar@epilogue.com In-Reply-To: <199711141806.AA199190803@dorothy.peer.com> (message from Randy Presuhn on Fri, 14 Nov 1997 10:06:43 -0800) Subject: Re: representing ranges (was: Re: Comments on agentx mib from 22 october) Date: Fri, 14 Nov 97 13:49:05 -0500 Message-Id: <9711141349.aa07071@khitomer.epilogue.com> Date: Fri, 14 Nov 1997 10:06:43 -0800 From: Randy Presuhn Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > From: "Shawn A. Routhier" > To: agentx@peer.com > Cc: sar@epilogue.com > Subject: Comments on agentx mib from 22 october > Date: Thu, 13 Nov 97 22:34:52 -0500 > Message-Id: <9711132234.aa28297@khitomer.epilogue.com> ... > There are three cases I can think of > > a) register a single object a.b.c.d > b) register a set of objects a.b.c.[d ... e] > c) register a set of objects with instance a.b.c.[d ... e].f > > a) is straightforward, because there are gaps between the > instance for c) it becomes a series of entries, the first > one starts at a.b.c.d.f and ends at a.b.c.d.f+1 the last > is a.b.c.d.e.f to a.b.c.d.e.f+1 > > this leaves b). which in many sub agents should really be > registering a.b.c (according to the suggestion to register > as high in the tree as possible) in this case we end up with a). Except in cases like the RDBMS MIB, application MIB, WWW MIB, and so on where different rows of a given table may be implemented by different subagents. I think this is a description of (c), you want to register a row of objects each of which will have a given instance. What is registered has gaps between the instances what the registration table describes doesn't. Am I missing something? > In some cases we would have a contiguous series of objects > which would benefit from the start and end objects, > but I think that most of the time we wouldn't and it would > be cheaper to turn those cases into a series of entries > rather than trying to have a single entry for them. Implementations certainly should have the flexibility to do their registrations that way, though I think the MIB should reflect what has been going on in the protocol. (This goes back to my comment about the use of this MIB in trouble-shooting scenarios.) > Alternatively I would propose that the null object id (0.0) > be used for the ending object to indicate that the start object > is a root of a tree rather than the start of a range. I like this idea. It would also circumvent the 4294967295 problem and reduce the bandwidth needed to walk this table for common configurations. > 4) In conjunction with 3), what happens to regIndex if a sub agent > de registers an object in the middle of a range? That is > a sub agent registers a.b.c.1-10.d and then de registers a.b.c.5.d. I think clause 7.1.6 (4) of the agentx protocol draft answers this question. The deregistration request should be rejected. I haven't been interpreting that section as requiring that u.region exactly match a previously registered region. In other sections of the document (such as 7.1.5 (6)) describes "splitting" regions. I would suggest that if there is a requirement to keep regions together the document needs to be a lot clearer about it and needs to avoid discussions about "splitting" regions. Further I don't see a reason to restrict the de-registration step to an exact match for a previously registered region. > 5) I'd also like to point out that the choice of an index for the > registration table means that a manager will need to retrieve the > entire table to determine what sub agent is actually handling a > given object id. This seems somewhat inefficient. ... An indexing structure to optimize a query to identify which subagent would actually handle a given object ID would be pretty hairy, given the lexicographical ordering of object identifiers and the limitation on their length. Ah, yes. I was thinking of an index with an object id, followed by a single integer. The object id would be as much of the region's oid as we could fit in (up to 127 sub ids) and the integer would be used for uniqueness if necessary (or desired). This would work but it is disallowed by the index mapping rules, specifically the that implied index must be the last index, which rule I had forgotten. In the SMUX MIB, the equivalent table is indexed by the registered tree and priority. Due to the lexicographical "ordering" of object identifiers, a similar problem exists there. The current index order makes all possible retrieval scenarios equally onerous. I'd suggest removing the agentxRegSessionIndex column and adding agentxSessionIndex as the first index of agentxRegistrationEntry. This would at least make it reasonably efficient to determine a given subagent's registrations, and would not make the query to identify which subagent would handle a given object identifier any worse. This seems ok. (Well it seems ugly, but I don't see I better option currently). --------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA --------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." --------------------------------------------------------------------- sar From rpresuhn@peer.com Fri Nov 14 11:37:30 1997 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA291746250 for ; Fri, 14 Nov 1997 11:37:30 -0800 Date: Fri, 14 Nov 1997 11:37:30 -0800 From: Randy Presuhn Return-Path: Message-Id: <199711141937.AA291746250@dorothy.peer.com> To: agentx@peer.com Subject: Re: representing ranges (was: Re: Comments on agentx mib from 22 october) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - |From: "Shawn A. Routhier" |To: agentx@peer.com |Cc: sar@epilogue.com |Subject: Re: representing ranges (was: Re: Comments on agentx mib from 22 october) |Date: Fri, 14 Nov 97 13:49:05 -0500 |Message-Id: <9711141349.aa07071@khitomer.epilogue.com> | | Date: Fri, 14 Nov 1997 10:06:43 -0800 | From: Randy Presuhn ... | > From: "Shawn A. Routhier" | > To: agentx@peer.com | > Cc: sar@epilogue.com | > Subject: Comments on agentx mib from 22 october | > Date: Thu, 13 Nov 97 22:34:52 -0500 | > Message-Id: <9711132234.aa28297@khitomer.epilogue.com> | ... | | | | > There are three cases I can think of | > | > a) register a single object a.b.c.d | > b) register a set of objects a.b.c.[d ... e] | > c) register a set of objects with instance a.b.c.[d ... e].f | > | > a) is straightforward, because there are gaps between the | > instance for c) it becomes a series of entries, the first | > one starts at a.b.c.d.f and ends at a.b.c.d.f+1 the last | > is a.b.c.d.e.f to a.b.c.d.e.f+1 | > | > this leaves b). which in many sub agents should really be | > registering a.b.c (according to the suggestion to register | > as high in the tree as possible) in this case we end up with a). | | Except in cases like the RDBMS MIB, application MIB, WWW MIB, and | so on where different rows of a given table may be implemented | by different subagents. | |I think this is a description of (c), you want to register a row |of objects each of which will have a given instance. What is |registered has gaps between the instances what the registration |table describes doesn't. You're right. This is what makes it possible to support these configurations using SMUX and some other pre-agentx protocols. |Am I missing something? Nope. I was. Range registration is simply an optimization of what could be accomplished with simple subtree registration. In some cases, however, the reduction in the number of entries required in the registration MIB could be pretty substantial. ... | > 4) In conjunction with 3), what happens to regIndex if a sub agent | > de registers an object in the middle of a range? That is | > a sub agent registers a.b.c.1-10.d and then de registers a.b.c.5.d. | | I think clause 7.1.6 (4) of the agentx protocol draft answers this | question. The deregistration request should be rejected. | |I haven't been interpreting that section as requiring that u.region |exactly match a previously registered region. In other sections of |the document (such as 7.1.5 (6)) describes "splitting" regions. This is why I was so concerned about the "splitting" stuff getting into the document in the first place. It was supposed to just be a description of how a master agent implementation MIGHT maintain its internal structures to get the desired effect. That's this note was added to (6): + Note: The following algorithm describes maintaining a set of + OID ranges derived from "splitting" registered regions. The + algorithm for operational dispatching is also stated in terms of + these OID ranges. |I would suggest that if there is a requirement to keep regions together |the document needs to be a lot clearer about it and needs to avoid |discussions about "splitting" regions. I don't think there is any requirement to keep regions "together" or not. I agree strongly that it would be good to remove the splitting text, but was very much in the minority the last time this came up. | Further I don't see a reason |to restrict the de-registration step to an exact match for a previously |registered region. ... If the deregistrations do not exactly match the registrations, it could become difficult to tell when the registration is really "gone". For example: register 1.3.4.5.6 deregister 1.3.4.5.6.1 deregister 1.3.4.5.6.2 deregister 1.3.4.5.6.3 ... deregister 1.3.4.5.6.n When is 1.3.4.5.6 "gone"? Would the registration MIB look like (a) the set of active registrations received, or (b) the result of applying the "splitting" algorithm? What configuration would need to do this? I think it's simpler to have the MIB reflect the registrations received that have not been deregistered, and for deregistration to require an exact match. --------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA --------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." --------------------------------------------------------------------- From sar@epilogue.com Fri Nov 14 12:04:28 1997 Received: from almond.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA008127867 for ; Fri, 14 Nov 1997 12:04:27 -0800 Return-Path: Received: (from uucp@localhost) by almond.bmc.com (8.8.6/8.8.6) id OAA12895; Fri, 14 Nov 1997 14:04:26 -0600 (CST) Received: from khitomer.epilogue.com(128.224.1.172) by almond.bmc.com via smap (V2.0) id xma012889; Fri, 14 Nov 97 14:04:10 -0600 From: "Shawn A. Routhier" Sender: sar@khitomer.epilogue.com To: rpresuhn@peer.com Cc: agentx@peer.com In-Reply-To: <199711141937.AA291746250@dorothy.peer.com> (message from Randy Presuhn on Fri, 14 Nov 1997 11:37:30 -0800) Subject: Re: representing ranges (was: Re: Comments on agentx mib from 22 october) Date: Fri, 14 Nov 97 15:04:09 -0500 Message-Id: <9711141504.aa07980@khitomer.epilogue.com> Date: Fri, 14 Nov 1997 11:37:30 -0800 From: Randy Presuhn Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - | > 4) In conjunction with 3), what happens to regIndex if a sub agent | > de registers an object in the middle of a range? That is | > a sub agent registers a.b.c.1-10.d and then de registers a.b.c.5.d. | | I think clause 7.1.6 (4) of the agentx protocol draft answers this | question. The deregistration request should be rejected. | |I haven't been interpreting that section as requiring that u.region |exactly match a previously registered region. In other sections of |the document (such as 7.1.5 (6)) describes "splitting" regions. This is why I was so concerned about the "splitting" stuff getting into the document in the first place. It was supposed to just be a description of how a master agent implementation MIGHT maintain its internal structures to get the desired effect. That's this note was added to (6): + Note: The following algorithm describes maintaining a set of + OID ranges derived from "splitting" registered regions. The + algorithm for operational dispatching is also stated in terms of + these OID ranges. |I would suggest that if there is a requirement to keep regions together |the document needs to be a lot clearer about it and needs to avoid |discussions about "splitting" regions. I don't think there is any requirement to keep regions "together" or not. I agree strongly that it would be good to remove the splitting text, but was very much in the minority the last time this came up. | Further I don't see a reason |to restrict the de-registration step to an exact match for a previously |registered region. ... If the deregistrations do not exactly match the registrations, it could become difficult to tell when the registration is really "gone". For example: register 1.3.4.5.6 deregister 1.3.4.5.6.1 deregister 1.3.4.5.6.2 deregister 1.3.4.5.6.3 ... deregister 1.3.4.5.6.n When is 1.3.4.5.6 "gone"? Would the registration MIB look like (a) the set of active registrations received, or (b) the result of applying the "splitting" algorithm? What configuration would need to do this? I think it's simpler to have the MIB reflect the registrations received that have not been deregistered, and for deregistration to require an exact match. Perhaps we are not describing the same concept. I'm thinking of the case of a sub agent registering 1.3.4.5.[6-11] and then de-registering 1.3.4.5.6 or 1.3.4.5.7 rather than de-registering 1.3.4.5.[6-11] as oppossed to the case of de-registering 1.3.4.5.6.1. I would allow the former, I would disallow the latter. I view registering a range of nodes as equal to registering each node individually, therefore you should be able to remove each node individually. However this doesn't allow you to remove some part of a node, which is what you were describing. Is that better? sar From rpresuhn@peer.com Fri Nov 14 13:48:16 1997 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA071884095 for ; Fri, 14 Nov 1997 13:48:16 -0800 Date: Fri, 14 Nov 1997 13:48:16 -0800 From: Randy Presuhn Return-Path: Message-Id: <199711142148.AA071884095@dorothy.peer.com> To: agentx@peer.com Subject: Re: representing ranges (was: Re: Comments on agentx mib from 22 october) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > From: "Shawn A. Routhier" > To: rpresuhn@peer.com > Cc: agentx@peer.com > Subject: Re: representing ranges (was: Re: Comments on agentx mib from 22 october) > Date: Fri, 14 Nov 97 15:04:09 -0500 > Message-Id: <9711141504.aa07980@khitomer.epilogue.com> ... > Perhaps we are not describing the same concept. > I'm thinking of the case of a sub agent registering 1.3.4.5.[6-11] > and then de-registering 1.3.4.5.6 or 1.3.4.5.7 rather than > de-registering 1.3.4.5.[6-11] as oppossed to the case of > de-registering 1.3.4.5.6.1. I would allow the former, I would > disallow the latter. I hadn't picked up that distinction from your earlier message. > I view registering a range of nodes as equal to registering each > node individually, therefore you should be able to remove each > node individually. However this doesn't allow you to remove some > part of a node, which is what you were describing. > > Is that better? ... The difference in our viewpoints appears to hinge on one word. You write "equal"; I would have written "equivalent". In the former case, it would make sense for the MIB to show the results of the application of the "splitting" algorithm, and to permit the individual deregistration of the bits and pieces that result from the application of that algorithm; in the latter case, it makes sense for the MIB to report the registration requests that have been accepted and for which deregistration requests have not yet been received. Aside: As a practical matter, I think the "equal" interpretation effectively requires implementations to internally use the "splitting" algorithm, where the "equivalent" interpretation allows implementations use other algorithms internally, as long as they meet protocol requirements for registration handling. Although the "splitting" algorithm may be pedagogically useful, I wouldn't want to make it a requirement of implementations. --------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA --------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." --------------------------------------------------------------------- From cclark@cnri.reston.va.us Mon Nov 17 07:47:00 1997 Received: from almond.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA105971619 for ; Mon, 17 Nov 1997 07:46:59 -0800 Return-Path: Received: (from uucp@localhost) by almond.bmc.com (8.8.6/8.8.6) id JAA29480 for ; Mon, 17 Nov 1997 09:46:58 -0600 (CST) Received: from gauntlet.fv.com(207.67.199.118) by almond.bmc.com via smap (V2.0) id xma029473; Mon, 17 Nov 97 09:46:38 -0600 Received: (from uucp@localhost) by gauntlet.fv.com (8.8.8/8.8.8) id HAA01310 for ; Mon, 17 Nov 1997 07:41:26 -0800 (PST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma001299; Mon, 17 Nov 97 07:40:56 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.8/8.8.8) with ESMTP id HAA29256 for ; Mon, 17 Nov 1997 07:46:00 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.8/8.8.8) id HAA01296 for ; Mon, 17 Nov 1997 07:40:55 -0800 (PST) Received: from ietf.org(132.151.1.19) by gauntlet.fv.com via smap (3.2) id xma001293; Mon, 17 Nov 97 07:40:48 -0800 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.7/8.8.7a) with ESMTP id KAA15465; Mon, 17 Nov 1997 10:45:46 -0500 (EST) Message-Id: <199711171545.KAA15465@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ietf.org Cc: agentx@fv.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-agentx-mib-01.txt Date: Mon, 17 Nov 1997 10:45:46 -0500 Sender: cclark@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SNMP Agent Extensibility Working Group of the IETF. Title : Definitions of Managed Objects for Extensible SNMP Agents Author(s) : M. Greene, S. Gudur Filename : draft-ietf-agentx-mib-01.txt Pages : 18 Date : 14-Nov-97 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. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-agentx-mib-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-agentx-mib-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ds.internic.net US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-agentx-mib-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19971114180355.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-agentx-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-agentx-mib-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19971114180355.I-D@ietf.org> --OtherAccess-- --NextPart-- From welcome@letslink.net Tue Nov 18 14:45:44 1997 Received: from almond.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA035563143 for ; Tue, 18 Nov 1997 14:45:43 -0800 Return-Path: Received: (from uucp@localhost) by almond.bmc.com (8.8.6/8.8.6) id QAA16482 for ; Tue, 18 Nov 1997 16:45:41 -0600 (CST) From: welcome@letslink.net Received: from gauntlet.fv.com(207.67.199.118) by almond.bmc.com via smap (V2.0) id xma016433; Tue, 18 Nov 97 16:45:16 -0600 Received: (from uucp@localhost) by gauntlet.fv.com (8.8.8/8.8.8) id OAA06900 for ; Tue, 18 Nov 1997 14:39:35 -0800 (PST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma006883; Tue, 18 Nov 97 14:39:09 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.8/8.8.8) with ESMTP id OAA02091 for ; Tue, 18 Nov 1997 14:44:16 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.8/8.8.8) id OAA06875 for ; Tue, 18 Nov 1997 14:39:04 -0800 (PST) Message-Id: <199711182239.OAA06875@gauntlet.fv.com> Received: from tatiyana.savoynet.com(204.157.255.6) by gauntlet.fv.com via smap (3.2) id xma006835; Tue, 18 Nov 97 14:38:41 -0800 Date: Tue, 18 Nov 1997 06:41:48 -0500 X-Sender: welcome@letslink.net X-Advertisement: Click here to be removed. To: agentx@fv.com Subject: Let's Link I like your site content .... let's consider linking .... it's FREE! I invite you to visit Let's Link and add your site along with a brief description of your site content to our Internet Resource Center Search Engine ... perhaps our Let's Link & Links section. Although, our "Add Your Link" service is FREE, we do ask you to reciprocate with a LINK at your site .... not required but highly appreciated. .... please review our instructions for linking before adding your site. Let's Link is a family friendly site. Let's Link is a highly interactive Information Resource Center and a Global Gateway to thousands of The Best Sites on the "Net". Primary links include: Global Travel Guide; Education Network; Career Services; SharewareNET; Product Showcase; Worldwide Marketplace, Art; Catalogs; Real Estate Corner; Shoppers Paradise and much more. Our site visitation now exceeds 4,300 per/day! 25% Europe.... 70% North America... 5% Asia I hope you find our Information Resource Center beneficial. Regards, Terry http://www.letslink.net/ From sar@epilogue.com Wed Nov 19 15:21:39 1997 Received: from almond.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA169871697 for ; Wed, 19 Nov 1997 15:21:38 -0800 Return-Path: Received: (from uucp@localhost) by almond.bmc.com (8.8.6/8.8.6) id RAA26797 for ; Wed, 19 Nov 1997 17:21:35 -0600 (CST) Received: from khitomer.epilogue.com(128.224.1.172) by almond.bmc.com via smap (V2.0) id xma026794; Wed, 19 Nov 97 17:21:23 -0600 From: "Shawn A. Routhier" Sender: sar@khitomer.epilogue.com To: agentx@peer.com Cc: sar@epilogue.com In-Reply-To: <199711141735.AA194888955@dorothy.peer.com> (message from Randy Presuhn on Fri, 14 Nov 1997 09:35:55 -0800) Subject: Re: agentx connection table (Was: Re: Comments on agentx mib from 22 october) Date: Wed, 19 Nov 97 18:21:22 -0500 Message-Id: <9711191821.aa12992@khitomer.epilogue.com> Date: Fri, 14 Nov 1997 09:35:55 -0800 From: Randy Presuhn Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > From: "Shawn A. Routhier" > To: agentx@peer.com > Cc: sar@epilogue.com > Subject: Comments on agentx mib from 22 october > Date: Thu, 13 Nov 97 22:34:52 -0500 > Message-Id: <9711132234.aa28297@khitomer.epilogue.com> ... > 1) When Randy originally mentioned having a connection table I had > thought it was an acceptable idea. After thinking about it more > I concluded that it really seems to be outside of the scope of > agentx to understand what the layers underneath it are doing. I agree that the agentx MIB should not delve unnecessarily into the underlying transport(s). However, it should permit reliable identification of those sessions being multiplexed over a particular transport connection, and provide enough information to identify it in the relevant transport protocol-specific MIB. I think we agree. > This table would require an agentx engine to understand if it > were running on top of tcp or udp or something else and to be > able to determine information from that layer before any > agentx messages have been exchanged. In order to set up the listen() (or equivalent) call to the underlying transport services, a master agent needs to be able to sufficiently identify what protocol(s) it's willing to accept connections on. Whether the master agent gets this information from command line, configuration file, non-volatile memory, getservbyname(), registry, or whatever, it needs to know the address family, address:port to listen to, and the protocol. This depends on just where you draw various boundaries. The entire process that supports an agentX master agent does need to do what you are describing. However depending on how you write things the core agentx engine doesn't need to know much about the underlying transport layers. > For example the agentx > entity would need to be able to determine from the tcp layer > that a connection has been established even if an open message > hasn't been received. With the transport APIs I'm familiar with, one has to do this anyway. For example, with BSD-style sockets, the master agent has to do a listen() before anything can connect to it, and an accept() before there's any data transfer. > As I fail to see a major use for this table (as opposed to > the address of the sub agent) and this sort of information > may be difficult to determine for some types of layers and > in some implementations I really don't think it is necessary. > I think it would be more useful to return to having the > address information in the session table. ... The connection table has these items: agentxConnIndex Unsigned32 agentxConnOpenTime TimeStamp agentxConnTransportType INTEGER agentxConnTransportAddr OCTET STRING agentxConnSessions Gauge32 There are two issues: utility and difficulty. Which present any difficulty? agentxConnIndex is assigned by the master agent; agentxConnOpenTime is known (looks the time of the listen() or accept() to me, though Smitha may have something else in mind); agentxConnTransportType and agentxConnTransportAddr we seem to agree would be useful. That leaves agentxConnSessions, which I would hope the master agent knows. Which of these are useful? We've gotten a lot of mileage out of the SMUX MIB, which only contains subagent identity and registration information, and has no transport information at all. Frankly, about the only times we use these MIBs is in regression tests (where they're VERY useful) and in trouble-shooting scenarios. Basically I don't think they are useful enough to outweight the extra effort needed for them. I'd be interested in hearing how they could be used. I would point out that previously the requirement was that a particular mib object needed to be useful in general operation - not just for debugging purposes. sar From rpresuhn@peer.com Wed Nov 19 18:11:30 1997 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA085131890 for ; Wed, 19 Nov 1997 18:11:30 -0800 Date: Wed, 19 Nov 1997 18:11:30 -0800 From: Randy Presuhn Return-Path: Message-Id: <199711200211.AA085131890@dorothy.peer.com> To: agentx@peer.com Subject: Re: agentx connection table (Was: Re: Comments on agentx mib from 22 october) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > From: "Shawn A. Routhier" > To: agentx@peer.com > Cc: sar@epilogue.com > Subject: Re: agentx connection table (Was: Re: Comments on agentx mib from 22 october) > Date: Wed, 19 Nov 97 18:21:22 -0500 > Message-Id: <9711191821.aa12992@khitomer.epilogue.com> ... (lots of violent agreement :-) > The connection table has these items: > agentxConnIndex Unsigned32 > agentxConnOpenTime TimeStamp > agentxConnTransportType INTEGER > agentxConnTransportAddr OCTET STRING > agentxConnSessions Gauge32 ... > Basically I don't think they are useful enough to outweight the extra > effort needed for them. I'd be interested in hearing how they could > be used. I would point out that previously the requirement was that > a particular mib object needed to be useful in general operation - not > just for debugging purposes. ... To me this reasoning suggests that we get rid of the connection table altogether, and the only appearance of connection-level information in the MIB would be the arbitrary integer used to identify sessions as sharing a common transport connection. Even the address information could go away. Though this might seem a bit draconian to some, it wouldn't bother me much. We've gotten along nicely without it in other subagent protocol MIBs. The debugging scenarios where this stuff would be useful are primarily ones where a system administrator has incorrectly configured something, and can usually be handled with the Unix netstat command. (Come to think of it, NONE of the information in this MIB is interesting when a system is functioning correctly; it's really only useful when a system's agent or subagents have been misconfigured or are malfunctioning.) --------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA --------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." --------------------------------------------------------------------- From sar@epilogue.com Thu Nov 20 19:46:26 1997 Received: from cashew.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA227093984 for ; Thu, 20 Nov 1997 19:46:24 -0800 Return-Path: Received: (from uucp@localhost) by cashew.bmc.com (8.8.6/8.8.6) id VAA12448 for ; Thu, 20 Nov 1997 21:46:22 -0600 (CST) Received: from khitomer.epilogue.com(128.224.1.172) by cashew.bmc.com via smap (V2.0) id xma012443; Thu, 20 Nov 97 21:46:13 -0600 From: "Shawn A. Routhier" Sender: sar@khitomer.epilogue.com To: agentx@peer.com Cc: sar@epilogue.com In-Reply-To: <199711200211.AA085131890@dorothy.peer.com> (message from Randy Presuhn on Wed, 19 Nov 1997 18:11:30 -0800) Subject: Re: agentx connection table (Was: Re: Comments on agentx mib from 22 october) Date: Thu, 20 Nov 97 22:46:10 -0500 Message-Id: <9711202246.aa25365@khitomer.epilogue.com> Date: Wed, 19 Nov 1997 18:11:30 -0800 From: Randy Presuhn Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > From: "Shawn A. Routhier" > To: agentx@peer.com > Cc: sar@epilogue.com > Subject: Re: agentx connection table (Was: Re: Comments on agentx mib from 22 october) > Date: Wed, 19 Nov 97 18:21:22 -0500 > Message-Id: <9711191821.aa12992@khitomer.epilogue.com> ... (lots of violent agreement :-) > The connection table has these items: > agentxConnIndex Unsigned32 > agentxConnOpenTime TimeStamp > agentxConnTransportType INTEGER > agentxConnTransportAddr OCTET STRING > agentxConnSessions Gauge32 ... > Basically I don't think they are useful enough to outweight the extra > effort needed for them. I'd be interested in hearing how they could > be used. I would point out that previously the requirement was that > a particular mib object needed to be useful in general operation - not > just for debugging purposes. ... To me this reasoning suggests that we get rid of the connection table altogether, and the only appearance of connection-level information in the MIB would be the arbitrary integer used to identify sessions as sharing a common transport connection. Even the address information could go away. I don't have many problems with that, but see below. Though this might seem a bit draconian to some, it wouldn't bother me much. We've gotten along nicely without it in other subagent protocol MIBs. The debugging scenarios where this stuff would be useful are primarily ones where a system administrator has incorrectly configured something, and can usually be handled with the Unix netstat command. (Come to think of it, NONE of the information in this MIB is interesting when a system is functioning correctly; it's really only useful when a system's agent or subagents have been misconfigured or are malfunctioning.) The only general use for this information I can see is for the manager to be able to tell what is "under the covers" of the the sub agent protocol. That is to be able to tell what object it is really manipulating. If we want that capability we need the registration table, though given the possibility that the identity of the object (read which sub-agent a specific object id will mean) may change between snmp packets from a manager I'm not sure how useful it will truly be. And to finish the "see below tag" above, if we want to be able to identify which sub agent an object is on then we need some way of identifying the sub agents - the description strings from the open pdu would work if they are used, the address fields tend to be an easy way to get uniqueness. sar From battle@snmp.com Mon Nov 24 08:11:44 1997 Received: from almond.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA243007903 for ; Mon, 24 Nov 1997 08:11:43 -0800 Return-Path: Received: (from uucp@localhost) by almond.bmc.com (8.8.6/8.8.6) id KAA06646; Mon, 24 Nov 1997 10:11:41 -0600 (CST) Received: from seymour16.snmp.com(192.147.142.16) by almond.bmc.com via smap (V2.0) id xma006630; Mon, 24 Nov 97 10:11:16 -0600 Received: by seymour16.snmp.com (cf v2.9s-SNMP) id LAA10191; Mon, 24 Nov 1997 11:11:14 -0500 (EST) Date: Mon, 24 Nov 1997 11:11:14 -0500 (EST) From: David Battle Message-Id: <199711241611.LAA10191@seymour16.snmp.com> To: rpresuhn@peer.com Subject: Re: representing ranges (was: Re: Comments on agentx mib from 22 october) Cc: agentx@peer.com > Although the "splitting" algorithm may be pedagogically useful, > I wouldn't want to make it a requirement of implementations. Amen. -David From info@tonex.com Tue Nov 25 14:45:08 1997 Received: from cashew.bmc.com by dorothy.peer.com with ESMTP (1.39.111.2/16.2) id AA070537905 for ; Tue, 25 Nov 1997 14:45:05 -0800 Return-Path: Received: (from uucp@localhost) by cashew.bmc.com (8.8.6/8.8.6) id QAA26094 for ; Tue, 25 Nov 1997 16:45:03 -0600 (CST) Received: from gauntlet.fv.com(207.67.199.118) by cashew.bmc.com via smap (V2.0) id xma026062; Tue, 25 Nov 97 16:44:38 -0600 Received: (from uucp@localhost) by gauntlet.fv.com (8.8.8/8.8.8) id OAA00232 for ; Tue, 25 Nov 1997 14:39:36 -0800 (PST) Received: from shekel.fv.com(207.67.199.130) by gauntlet.fv.com via smap (3.2) id xma000195; Tue, 25 Nov 97 14:39:08 -0800 Received: from gauntlet.fv.com (gauntlet-in.fv.com [10.0.0.2]) by shekel.fv.com (8.8.8/8.8.8) with ESMTP id OAA12739 for ; Tue, 25 Nov 1997 14:44:00 -0800 (PST) Received: (from uucp@localhost) by gauntlet.fv.com (8.8.8/8.8.8) id OAA00153 for ; Tue, 25 Nov 1997 14:39:04 -0800 (PST) Received: from dfw-ix5.ix.netcom.com(206.214.98.5) by gauntlet.fv.com via smap (3.2) id xma029987; Tue, 25 Nov 97 14:38:39 -0800 Received: (from smap@localhost) by dfw-ix5.ix.netcom.com (8.8.4/8.8.4) id QAA28178 for ; Tue, 25 Nov 1997 16:43:33 -0600 (CST) Received: from whx-ca9-03.ix.netcom.com(205.187.202.99) by dfw-ix5.ix.netcom.com via smap (V1.3) id rma028126; Tue Nov 25 16:43:09 1997 Message-Id: <347B53F3.6232@tonex.com> Date: Tue, 25 Nov 1997 14:40:51 -0800 From: Kathy Franklin Reply-To: info@tonex.com Organization: TONEX Texhnologies, Inc. X-Mailer: Mozilla 3.0C-NC320 (Win95; U) Mime-Version: 1.0 To: agentx@fv.com Subject: TMN/OSI/GDMO/ASN.1/CMIP Training Class, Dallas/TX, Dec. 8-12 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from 8bit to quoted-printable by dfw-ix5.ix.netcom.com id QAA28178 TONEX Technologies, Inc. Presents a 5 Day Course In: The Telecommunications Management Network: (TMN): Techniques, Standards, Applications, Implementations and Migration Telecommunications and Information Systems Professionals,=20 =20 This 5 day TMN course is designed to provide the latest information of TMN standards, TMN architecture, TMN solutions, TMN marketplace, TMN implementations and TMN deployment The following list details the highlights of the course: =B7 A detailed introduction to TMN and related concepts and buzzwords =B7 An overview of Integrated TMN Service and Network Management=20 =B7 NMF SMART, SPIRIT and Network Management Activities and Solutions Set= s Overview =B7 This course thoroughly describes the challenges, opportunities, and compatibility issues faced in migrating to TMN =B7 This comprehensive course covers the principles, architectures, design, applications, and technologies driving state-of-the-art and future TMN development. =B7 Grasp the fundamental concepts and key trade-off required in TMN planning, design, and implementation =B7 Cost-justifying TMN implementation for service and network management =B7 Begin with the basic principles and vocabulary, then combine them and see how easy it really is to understand sophisticated TMN concepts and implementation =B7 Develop an in-depth understanding of the TMN tools currently used in the market =B7 Understand TMN and CORBA integration issues =B7 Understand protocol independent information models =B7 An overview og the global TMN Convergence =20 Workshops: =B7 OSI Workshop =B7 Information Modeling Workshop =B7 GDMO and ASN.1 Workshop =B7 CMISE/CMIP Workshop =B7 CORBA/IDL for Telecommunications Management Workshop =B7 JIDM CORBA/OSI Workshop =B7 NMF TMN++ API Workshop =B7 Java for Management Workshop =20 WHEN: December 8-12, 1997 WHERE: Dallas, Texas (Dallas Parkway Hilton on LBJ, for Reservation call 972-661-3600, FAX: 972-385-3156)=20 =20 TMN Course Description: Provides an overview of TMN standards including principles, architectures, information modeling techniques, protocols, management services, and functions. Describes OSI systems management concepts, and the relationship between the two, since OSI System Management is a foundation for TMN implementation. This course is an overview of the current network and service management paradigms, standard, and technologies. Identifies the relationships (and differences) between network management concepts, conceived by telecommunications and computing industries, and how they can coexists in an enterprise environment. Gives special emphasis to the opportunities enabled by new technologies from the telecommunications and computing industries, and the role of emerging standards such as TMN in evolving the network and services. Includes a brief to standards activities employing TMN concepts for technology-specific applications such as B-ISDN, SDH/SONET, Wireless, ATM, IDLC/GR-303, ADSL, LNP, and AIN/IN, and their relationship to TMN generic capability. Provides a summary of TMN implementation issues including TMN/NMF/OMNIPoint/ANSI/T1M1/ECIC/OBF/Bellcore, applicability of network management platforms and productivity tools, and outlook to the future of TMN including influences from other emerging concepts such as ODP, COBRA, JMAPI, and TINA (Telecommunications Information Networking Architecture)-C. =20 =20 =20 Topic this course will cover: =B7 Introduction to Service and Network Management principles, and=20 techniques =B7 Introduction to TMN principles, layers, interfaces, techniques, and benefits =B7 Introduction to OSI principles, techniques, benefits =B7 Introduction to OSI System Management Communications: CMIS/CMIP =B7 Introduction to Network Operations and OAM&P =B7 Introduction to Q3 Interface =B7 Introduction to TMN Physical Architecture =B7 Introduction to TMN Functional Architecture =B7 Introduction to TMN Information Architecture =B7 Understanding of the more common terms and concepts associated with communications protocols =B7 Introduction to CMIS/CMIP =B7 Understanding of the more common terms and concepts associated with OSI MIB =B7 Introduction to GDMO =B7 Introduction to ASN.1 =B7 Introduction to SONET/ATM/GR-303 Information Models (GDMO/ASN.1) =B7 An overview of the international standard bodies involved in the TMN effort =B7 An overview of the technique, tools, products associated with TMN network and service management development effort =B7 An overview of TMN Migration Issues =B7 GDMO vs. CORBA Managed Objects =B7 TMN++ API =B7 JIDM TMN/OSI Gateway =B7 TMN and CORBA Integration =20 =20 Course Outline: =20 Introduction Network and Service Management: What and Why Foundation of Network Management and Service Management Today=92s Telecommunications Industry OSS and Management Systems Key Issues Current Needs Integration Issues Interconnection Issues Next Generation Operational Support Systems (OSS) TMN overview The Concepts of TMN Integrated Network Management - TMN Vision TMN Objectives TMN Standards TMN Layers TMN/OSI System Management Functional Areas (SMFA) Description TMN Migration Strategies =20 Concepts of TMN TMN Models, functions, and Interfaces TMN- Management Objectives TMN Functional Architecture Model TMN Physical Architecture and Interfaces TMN Management Information Architecture =20 =20 TMN Management Layers Business Management Layer OSF - BML=20 Service Management Layer OSF - SML Network Management Layer OSF - NML Element Management Layer OSF - EML Network Element Layer (NEL) =20 TMN Management Layers Dependencies TMN Management Layers related to System Management Functional Areas (CM, FM, PM, SM, AM) TMN Management Services related to TMN Management Layers TMN Management Services related to System Management Functional Areas =20 =20 Management Standards in the TMN/OSI Context OSI Key Concepts and Terms OSI Management Framework OSI System Management Services =20 OSI System Management Functional Areas (SMFA) Fault Management (FM) FM Process Network Control and Recovery Alarm Surveillance (analyze, filter, correlate) Fault Localization Fault Detection Root Cause Analysis Fault Correction Testing Acceptance Trouble Administration=20 =20 Configuration Management (CM) Provisioning NE (network element) Status and Control Installation Initialization Data Base Management Inventory Control Backup Restoration Topology NE Administration=20 NE Configuration =20 =20 Performance Management (PM) Data Collection Data Filtering Trend Analysis Performance Monitoring Performance Control Performance Analysis =20 Accounting Management (AM) Collecting Accounting Records (Billing) Process Accounting Records Set Billing Parameters for the usage of Services =20 Security Management (SM) Secure access to NE functions Security Alarms Audit Trails =20 OSI Information Architecture Basic Concepts New and planned OSI standards OSI Information Architecture Methodology Management Information Model Starters =20 OSI System Management Functions (SMF) General Principles object Management Functions=09 State Management Functions Alarm Reporting Functions=09 Log Control Functions Security Alarm Reporting Function Security Audit Trail Function Workload Monitoring Function Test Management Function Summarization Function Confidence and Diagnostic Test Functions Scheduling Function =20 OSI System Management Communications (CMISE/CMIP) OSI Management Structure The Common Management Information Service Element: CMISE=20 The Common Management Information Protocol : CMIP=20 CMISE Services CMIP Services ROSE Services =20 A quick comparison between CMIP, SNMP, and CMIP CORBA Architecture Information Structure Management Functions Underlying Communications =20 =20 OSI Management Information Base (MIB) Management Information Model Defining Managed-Object Classes OSI Management and Agent Processes Management Information Tree Relative Distinguished Names (RDN) Distinguished Names (DN) Absolutes Names Inheritance =20 =20 GDMO Workshop: Working with GDMO Templates=20 ASN.1 Workshop: Working with ASN.1 Syntax =20 =20 TMN Agent - Manager Relationships Filtering Scoping Synchronization Event Forwarding Discriminator (EFD) =20 =20 TMN Information Architecture TMN System Information Architecture TMN System Information Methodology TMN Candidate Managed Objects TMN Information Architecture Methodology Management application models, management services models, Managed resources=20 TMN Applicability of network management platforms and productivity tools TMN Information Modeling with SONET/SDH TMN Information Modeling with ATM TMN Information Modeling with ADSL TMN Information Modeling with IDLC/GR-303 =20 TMN Implementation and Migration TMN Implementation Strategies and Development Process TMN Design Strategies and Interfaces TMN Layers and Distribution of TMN Functions TMN Techniques and Standards TMN Applications TMN Architecture Integration of Legacy Systems into the TMN (including Q-adapters and Mediators) TMN and Directory Services International Standardized Profiles for TMN=20 TMN Commercial Platforms, tools, and other applicable COTS=20 TMN Mediation Strategies Q-Adaptions vs.Mediation =20 =20 TMN and CORBA Integration CORBA-Based Telecommunication Network Management System CORBA vs. GDMO Object Models Applied COBA Architecture: Managing Systems vs. Managed Systems CORBA 2.0 Services=20 CORBA Services vs. OSI SMF JIDM-Based CORBA/OSI Gateway =20 TMN Future Directions=20 TMN Concepts for SDH/SONET, ATM, B-ISDN, IN, GSM, WLL, Broadband Wireless, GR-303, xDSL Applicability of Network Management Platforms and Productivity Tools Outlook to the future of TMN including influences from other emerging technology : ODP (Open Distributed Processing) , CORBA, and TINA-C TMN Architecture and Modeling Principles GDMO vs. CORBA Managed Objects - TMN/CORBA Interworking OSI Systems Management vs. CORBA/IDL and Java/RMI Embedded CORBA and/or Java Based TMN Solutions: Vision vs. Reality Intelligent Mobile Agents for Telecom Management =20 More TMN Standards Information Model Methodology Information Model Development Strategy Element Layer Requirements Network Layer Requirements Service Layer Requirements Business Layer Requirements ITU-T Solutions ISO Solutions ISO/ IEC JTC1 NMF SMART and OMNIPoint Solutions Sets NMF TMN++ (C++ API) CORBA and Java based Network Management Solutions Bellcore Standards ( Generic, SONET, ATM , IDLC) ATM Forum Solutions SIF (SONET Interoperability Forum) Solutions Local Number Portability (LNP) Solutions: NPAC/LSMS Agent/Manager Relationship TIA Solutions T1M1 and ANSI Solutions=20 ECIC, OBF and other North American Solutions ETSI Solutions EURESCOM Solutions TINA-C =20 List of Available Network Management Standard Documents and Managed Objects (MO) Description; General List A Quick Comparison Between Standards ITU-T: X, G, Q, M Series NMF ETSI TINA-C T1M1 Bellcore ATM Forum SONET Interoperability Forum (SIF) DAVIC MPEG Wireless WLL Wireless ATM OMG /CORBA Based Telecommunications Network Management LNP/NPAC TMN Industry Catalog of Forums, Standards, Bodies, Associations, Activities, and Vendors =20 Audience: This course will benefit all executives, managers, and developers involved with managing or developing TMN compliant Operational Support Systems. It will be particularly beneficial for senior managers, engineers, analysts and consultants concerned with the following areas: =B7 TMN Business Development =B7 TMN Strategic Development =B7 Network design, development & planning =B7 Network and service management & support =B7 Network engineering & maintenance =B7 TMN Research & Development =B7 Software & systems engineers =B7 Technical Managers and Executives interested in TMN concepts and buzzwords =B7 Systems engineers and software developers who are involved in providing various portions of the functionality for the new TMN capabilities =B7 Systems engineers and software developers of existing systems intending to integrate their systems into this TMN compliant architecture =B7 Software component vendors involved in providing various portions of the functionality for the new TMN capabilities =B7 Platform vendors interested in providing the computing environment fo= r development and support of this TMN architectures =B7 Network equipment vendors interested in providing SDH/SONET/ATM, IDLC= , Wireless capable equipment with Q3 information model TONEX Register by December 6, 1997: By Phone: Call TONEX Technologies, Inc, Attn: Kathy +1-818-222-0392 or 1-888-TO-TONEX or 1-800-352-4046 By Fax: Fill out the registration form and fax it to: +1-818-222-0394, Attn: Kathy By Mail: Fill out this registration form and mail it to: TONEX Technologies, Inc., Attn: Kathy, 23067 Ventura Blvd., Suite 204, Woodland Hills, CA 91364 USA, info@tonex.com, http://www.tonex.com By E-mail: info@tonex.com=20 http://www.tonex.com TMN Dallas Registration Form:=20 Name: (Mr./Mrs./Miss/Dr): Title Company: Approving Manager: Address: City: Zip Code: State: Country: E-mail: URL: http:// Nature of Your Company=92s Business: P.O.# Total: $ Contact Person: Registration Fee: $1,695 per person By Check- Please make the check payable to TONEX Technologies, Inc. Company P.O. Please make P.O. to TONEX Technologies, Inc, $1,695, Please include P.O. Number and Account Payables Contact Information Thank You! TONEX Technologies, Inc. , Attn: Kathy, 23067 Ventura Blvd., Suite 204,=20 Woodland Hills, California 91364, USA From rpresuhn@peer.com Tue Nov 25 14:49:41 1997 Received: by dorothy.peer.com (1.39.111.2/16.2) id AA074338181 for ; Tue, 25 Nov 1997 14:49:41 -0800 Date: Tue, 25 Nov 1997 14:49:41 -0800 From: Randy Presuhn Return-Path: Message-Id: <199711252249.AA074338181@dorothy.peer.com> To: agentx@peer.com Subject: Re: agentx connection table (Was: Re: Comments on agentx mib from 22 october) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - > From: "Shawn A. Routhier" > Sender: sar@khitomer.epilogue.com > To: agentx@peer.com > Cc: sar@epilogue.com > Subject: Re: agentx connection table (Was: Re: Comments on agentx mib from 22 october) > Date: Thu, 20 Nov 97 22:46:10 -0500 > Message-Id: <9711202246.aa25365@khitomer.epilogue.com> ... (discussion of eliminating the connection table deleted) ... > The only general use for this information I can see is for the > manager to be able to tell what is "under the covers" of the > the sub agent protocol. That is to be able to tell what object > it is really manipulating. If we want that capability we need > the registration table, though given the possibility that the identity > of the object (read which sub-agent a specific object id will mean) > may change between snmp packets from a manager I'm not sure how > useful it will truly be. > > And to finish the "see below tag" above, if we want to be able to > identify which sub agent an object is on then we need some way of > identifying the sub agents - the description strings from the open > pdu would work if they are used, the address fields tend to be > an easy way to get uniqueness. ... In my experience with other subagent protocols, I have not found the subagent address to be useful in IDENTIFYING subagents. The IP portion will generally (though not always) be on the same host as the master agent, and the port number will typically have been assigned by the protocol stack. The subagent OID and description string (agentxSessionObjectID and agentxSessionDescr in the draft MIB) have been much more useful in trouble-shooting system configurations. With other subagent protocols, what I have found useful in trouble- shooting system configurations is: - the ability to determine which subagents have set up sessions with the master agent - the ability to determine what subtreess they had registered, and at what priority. (And whether this matched the system administrator's expectations :-) The session multiplexing is (relatively) new stuff, and I'm not yet sure what it will take to trouble-shoot systems that make heavy use of this capability. I guess it comes down to whether we start out with some objects that we end up deprecating because they turn out to not be useful, or we start out without the objects and end up hacking them back in because we find out we need them. I think the answer to this will emerge as we all start deploying this technology in diverse environments. --------------------------------------------------------------------- Randy Presuhn BMC Software, Inc. (Silicon Valley Division) Voice: +1 408 556-0720 (Formerly PEER Networks) http://www.bmc.com Fax: +1 408 556-0735 1190 Saratoga Avenue, Suite 130 Email: rpresuhn@bmc.com San Jose, California 95129-3433 USA --------------------------------------------------------------------- In accordance with the BMC Communications Systems Use and Security Policy memo dated December 10, 1996, page 2, item (g) (the first of two), I explicitly state that although my affiliation with BMC may be apparent, implied, or provided, my opinions are not necessarily those of BMC Software and that all external representations on behalf of BMC must first be cleared with a member of "the top management team." ---------------------------------------------------------------------