From owner-agentx@dorothy.bmc.com Thu Sep 12 18:38:49 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10147 for ; Thu, 12 Sep 2002 18:38:49 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g8CMgx021406; Thu, 12 Sep 2002 17:42:59 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA29472 for agentx-list; Thu, 12 Sep 2002 15:34:03 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA29466; Thu, 12 Sep 2002 15:33:59 -0700 (PDT) Date: Thu, 12 Sep 2002 15:33:59 -0700 (PDT) From: Randy Presuhn Message-Id: <200209122233.PAA29466@dorothy.bmc.com> To: agentx@dorothy.bmc.com, disman@dorothy.bmc.com Subject: brief list outages for disman and agentx Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 8bit Hi - Friday morning (pacific time) the agentx and disman working group mailing lists will be off-line for about thirty minutes while we install operating system patches and upgrade antiviral software. The FTP site will continue to be operational, and incoming mail should be queued. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. SJC-1.3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San Jos, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-agentx@dorothy.bmc.com Thu Sep 26 10:48:01 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10111 for ; Thu, 26 Sep 2002 10:48:00 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g8QEqjg28000; Thu, 26 Sep 2002 09:52:46 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA01785 for agentx-list; Thu, 26 Sep 2002 07:43:44 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA01778 for agentx@dorothy.bmc.com; Thu, 26 Sep 2002 07:43:40 -0700 (PDT) Date: Thu, 26 Sep 2002 07:43:40 -0700 (PDT) From: Randy Presuhn Message-Id: <200209261443.HAA01778@dorothy.bmc.com> To: agentx@dorothy.bmc.com Subject: non-subscriber posting Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 7bit Dear ***, I have two questions about agentX protocol. Question 1: Why agentX use sessions? I think that subagent register a connection with masterAgent ,then register the vews to masterAgent. It is enogh Question 2: Can many subagents owned the same OID? when SNMP set is requested, will master Agent send agentX_test_set for each subagent? I am waiting for your reply, Thanks Red . From owner-agentx@dorothy.bmc.com Thu Sep 26 10:59:37 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10569 for ; Thu, 26 Sep 2002 10:59:37 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g8QF4Z002579; Thu, 26 Sep 2002 10:04:35 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA01891 for agentx-list; Thu, 26 Sep 2002 07:56:51 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id HAA01885; Thu, 26 Sep 2002 07:56:47 -0700 (PDT) Date: Thu, 26 Sep 2002 07:56:47 -0700 (PDT) From: Randy Presuhn Message-Id: <200209261456.HAA01885@dorothy.bmc.com> To: agentx@dorothy.bmc.com Subject: Re: non-subscriber posting Cc: red.wang@utstar.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 7bit Hi - > Dear ***, > I have two questions about agentX protocol. > Question 1: > Why agentX use sessions? > I think that subagent register a connection with masterAgent ,then register the vews to masterAgent. It is enogh There are several uses for sessions. See the working group archives for January, 1997 in the thread "IETF 37, agentx meeting transcript" for a discussion of this point. > Question 2: > Can many subagents owned the same OID? when SNMP set is requested, will master Agent send agentX_test_set for each subagent? ... No limit, but which one sees the query is determined by RFC 2741 section 7.1.4.1 and its subsections. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. SJC-1.3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San Jos, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-agentx@dorothy.bmc.com Thu Sep 26 14:51:32 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18040 for ; Thu, 26 Sep 2002 14:51:31 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g8QGDsL01084; Thu, 26 Sep 2002 11:13:54 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA02068 for agentx-list; Thu, 26 Sep 2002 08:18:58 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA02062; Thu, 26 Sep 2002 08:18:54 -0700 (PDT) Date: Thu, 26 Sep 2002 08:18:54 -0700 (PDT) From: Randy Presuhn Message-Id: <200209261518.IAA02062@dorothy.bmc.com> To: agentx@dorothy.bmc.com Subject: Re: non-subscriber posting Cc: red.wang@utstar.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 8bit Hi - > Date: Thu, 26 Sep 2002 07:56:47 -0700 (PDT) > From: Randy Presuhn > Message-Id: <200209261456.HAA01885@dorothy.bmc.com> > To: agentx@dorothy.bmc.com > Subject: Re: non-subscriber posting > Cc: red.wang@utstar.com ... > There are several uses for sessions. See the working group > archives for January, 1997 in the thread "IETF 37, agentx > meeting transcript" for a discussion of this point. ... That's what I get for answering email before I've had some caffeine. The "transcript" was mailed by Dale Francisco to some of the most active participants in the meeting, but not the mailing list. The San Jose meeting minutes have a brief summary of the issue of sessions. In short, they make it easier to support subagent multiplexors and adaptors proxying other management protocols. It wasn't that long ago that the number of open sockets per process was rather constrained on some platforms, so multiplexing on a single connection was important to scalability. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. SJC-1.3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San Jos, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-agentx@dorothy.bmc.com Thu Sep 26 14:51:33 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18047 for ; Thu, 26 Sep 2002 14:51:32 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g8QGDLL00866; Thu, 26 Sep 2002 11:13:21 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA02150 for agentx-list; Thu, 26 Sep 2002 08:33:20 -0700 (PDT) Received: from flicker.bmc.com (flicker.bmc.com [172.20.8.40]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA02137; Thu, 26 Sep 2002 08:32:45 -0700 (PDT) Received: from mx-us-sjc-2-int.bmc.com (IDENT:postfix@[198.175.229.198]) by flicker.bmc.com (8.10.2/8.10.2) with ESMTP id g8QFZ6c00619; Thu, 26 Sep 2002 08:35:06 -0700 (PDT) Received: from mercury.mv.net (unknown [199.125.85.40]) by mx-us-sjc-2-int.bmc.com (Postfix) with ESMTP id 97EF9222EF2; Thu, 26 Sep 2002 16:05:58 -0500 (CDT) Received: from ieee.org (bnh-2-43.mv.com [199.125.99.107]) by mercury.mv.net (8.9.3/8.9.3/mem-20020217) with ESMTP id LAA00521; Thu, 26 Sep 2002 11:30:34 -0400 (EDT) Message-ID: <3D9328D8.5FB3A8FF@ieee.org> Date: Thu, 26 Sep 2002 11:33:44 -0400 From: Mark Ellison Organization: Ellison Software Consulting, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: disman@dorothy.bmc.com Cc: agentx@dorothy.bmc.com Subject: Re: non-subscriber posting (Agentx) References: <200209261443.HAA01778@dorothy.bmc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 7bit Hi Red, [Please follow-up on the agentx list] (1) Agentx uses sessions so that the master agent and sub-agents can readily detect a breakdown in connectivity with the other. For example, if a -test-set is sent to a sub-agent that crashes, the master-agent can recover more quickly than by waiting for the dispatch to the sub-agent to timeout. (2) It is possible for many subagents to know about the same object-type. Typically, subagents will register a subtree rather than a leaf object. There are many details involved when registering a subtree (see RFC 2741 sxn 6.2.3, "The agentx-Register-PDU"). When the master receives a request for a particular object name, it searches its list of registrations to determine the "authorative region", and dispatches the request to a single subagent (see sxn. 7.1.4.1, "Handling Duplicate and Overlapping Subtrees") The above should get you headed in the right direction, and additional followup questions are welcome- please post to agentx@dorothy.bmc.com. Regards, Mark Ellison Ellison Software Consulting, Inc. Randy Presuhn wrote: > Dear ***, > I have two questions about agentX protocol. > Question 1: > Why agentX use sessions? > I think that subagent register a connection with masterAgent ,then register the vews to masterAgent. It is enogh > Question 2: > Can many subagents owned the same OID? when SNMP set is requested, will master Agent send agentX_test_set for each subagent? > > I am waiting for your reply, Thanks > > Red > > . > > From owner-agentx@dorothy.bmc.com Thu Sep 26 17:40:35 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23045 for ; Thu, 26 Sep 2002 17:40:35 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g8QLjLi15578; Thu, 26 Sep 2002 16:45:21 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA03522 for agentx-list; Thu, 26 Sep 2002 14:37:29 -0700 (PDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA03516; Thu, 26 Sep 2002 14:37:25 -0700 (PDT) Date: Thu, 26 Sep 2002 14:37:25 -0700 (PDT) From: Randy Presuhn Message-Id: <200209262137.OAA03516@dorothy.bmc.com> To: disman@dorothy.bmc.com Subject: Re: non-subscriber posting (Agentx) Cc: agentx@dorothy.bmc.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 7bit Hi - > Message-ID: <3D9328D8.5FB3A8FF@ieee.org> > Date: Thu, 26 Sep 2002 11:33:44 -0400 > From: Mark Ellison > To: disman@dorothy.bmc.com > Cc: agentx@dorothy.bmc.com > Subject: Re: non-subscriber posting (Agentx) > References: <200209261443.HAA01778@dorothy.bmc.com> ... > [Please follow-up on the agentx list] ... The mis-forward to the disman list was my error. I was in the midst of an early-morning conference call, and hadn't had any caffeine yet. (Without caffeine, I make mistakes in slow motion. :-) ------------------------------------------------------ Randy Presuhn BMC Software, Inc. SJC-1.3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San Jos, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-agentx@dorothy.bmc.com Sat Sep 28 22:25:42 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16133 for ; Sat, 28 Sep 2002 22:25:41 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g8T2RsV07445; Sat, 28 Sep 2002 21:27:54 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id TAA09036 for agentx-list; Sat, 28 Sep 2002 19:17:56 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id TAA09030; Sat, 28 Sep 2002 19:17:48 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g8T2JPq29155; Sat, 28 Sep 2002 21:19:25 -0500 (CDT) Received: from mail.szutstar.com (unknown [210.21.224.30]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 9B4D51FF007; Sat, 28 Sep 2002 21:19:22 -0500 (CDT) Received: from sznssredw (pc161_47 [172.16.161.47]) by mail.szutstar.com (8.11.1/8.11.1) with SMTP id g8T2GW721841; Sun, 29 Sep 2002 10:16:36 +0800 From: "red" To: "Randy Presuhn" , Subject: =?utf-8?B?4oCyZT/igLI6IG5vbi1zdWJzY3JpYmVyIHBvc3RpbmcoYW5vdGhlciBxdWVzdA==?= =?utf-8?B?aW9uKQ==?= Date: Sun, 29 Sep 2002 10:19:16 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <200209261518.IAA02062@dorothy.bmc.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by dorothy.bmc.com id TAA09031 Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 8bit Dear Randy: I am very appreciate for your answers. I have another question, Will master Agent handle the next snmp request , when it has not send response for the last snmp request yet? Thank&Regards Red -----原始邮件----- 发件人: Randy Presuhn [mailto:rpresuhn@dorothy.bmc.com] 发送时间: 2002年9月26日 23:19 收件人: agentx@dorothy.bmc.com 抄送: red.wang@utstar.com 主题: Re: non-subscriber posting Hi - > Date: Thu, 26 Sep 2002 07:56:47 -0700 (PDT) > From: Randy Presuhn > Message-Id: <200209261456.HAA01885@dorothy.bmc.com> > To: agentx@dorothy.bmc.com > Subject: Re: non-subscriber posting > Cc: red.wang@utstar.com ... > There are several uses for sessions. See the working group > archives for January, 1997 in the thread "IETF 37, agentx > meeting transcript" for a discussion of this point. ... That's what I get for answering email before I've had some caffeine. The "transcript" was mailed by Dale Francisco to some of the most active participants in the meeting, but not the mailing list. The San Jose meeting minutes have a brief summary of the issue of sessions. In short, they make it easier to support subagent multiplexors and adaptors proxying other management protocols. It wasn't that long ago that the number of open sockets per process was rather constrained on some platforms, so multiplexing on a single connection was important to scalability. ------------------------------------------------------ Randy Presuhn BMC Software, Inc. SJC-1.3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San Josi, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ From owner-agentx@dorothy.bmc.com Sun Sep 29 15:53:28 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08290 for ; Sun, 29 Sep 2002 15:53:28 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g8TJrVq08550; Sun, 29 Sep 2002 14:53:31 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id MAA10560 for agentx-list; Sun, 29 Sep 2002 12:45:17 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id MAA10555 for ; Sun, 29 Sep 2002 12:45:12 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g8TJkn209094 for ; Sun, 29 Sep 2002 14:46:49 -0500 (CDT) Received: from hoemail2.firewall.lucent.com (unknown [192.11.226.163]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id D000E20EF96 for ; Sun, 29 Sep 2002 14:46:50 -0500 (CDT) Received: from md6370exch004u.wins.lucent.com (h135-114-172-12.lucent.com [135.114.172.12]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g8TJkpZ18117 for ; Sun, 29 Sep 2002 15:46:51 -0400 (EDT) Received: by md6370exch004u.nse.lucent.com with Internet Mail Service (5.5.2653.19) id ; Sun, 29 Sep 2002 15:46:50 -0400 Message-ID: <305D2EAC01C45448A7F3ECC487666F6C0286F7C3@md6370exch004u.nse.lucent.com> From: "Natale, Robert C (Bob)" To: Jed Lau Cc: mibs@ops.ietf.org, agentx@dorothy.bmc.com Subject: Re: Help/guidance on L2TPv3 MIB draft Date: Sun, 29 Sep 2002 15:46:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list At 8/19/2002:08:26 PM, Jed Lau wrote: Hi Jed, Please review this MIB for compatibility with the IETF standard SNMP agent extensibility protocol, AgentX (RFC2741...and RFC2742 can also give you some additional insight into AgentX operations). The fundamental issue is that scalar objects are potentially problematic for AgentX. They should be avoided by putting them into a table indexed by some form of "AgentEntityID" object (an exercise left to the implementer for now :-(). Note that the issue of AgentX compatibility for MIB writers will be addressed in a forthcoming Internet Draft that I will submit...perhaps with an extended applicability statement for AgentX (Sections 4.2, 4.3, and 4.4 of RFC2741 do a good job of the basics already)...for consideration by the relevant IETF WGs. My hope is that consideration of this Draft will lead to adding a statement or two to the standard "SNMP Framework" boilerplate to document these requirements for MIB writers. Guidance from Bert re where to discuss this issue -- AgentX compatibility guidelines for SNMP MIBs -- will be appreciated. (The AgentX e-mail list is still operative, but the WG is closed pending further work when its time to move to Full Standard status.) Cheers, BobN - - - - - >Hi, > >I am one of three co-authors of the L2TPv3 MIB draft. I attended the IETF in >Yokohama in July, and I got this e-mail address during one of the plenaries. I >understand that somebody behind this e-mail address might be able to provide us >with some guidance in developing our MIB. > >The first draft of the MIB is . We'd >like to get some feedback regarding our organization of the MIB tables. The >L2TPv3 (Layer Two Tunneling Protocol, Version 3) MIB borrows a lot from its >predecessor, . However, it introduces a >new framework that, we hope, allows us to better modularize the various >components of the tunneling protocol (e.g. pseudowire, payload, transport, >etc.). The intention is to allow future enhancements to the protocol (e.g. >additions to the list of supported payloads or transport types) to occur in >scalable and modular manner. > >I intend to go into further details and ask some specific questions in a >subsequent e-mail. Should I send follow-up e-mails to this address, or should >I interface with a specific individual? > >Thanks in advance. > >Jed Lau From owner-agentx@dorothy.bmc.com Sun Sep 29 16:20:55 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08580 for ; Sun, 29 Sep 2002 16:20:55 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g8TKPuu18160; Sun, 29 Sep 2002 15:25:57 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA10621 for agentx-list; Sun, 29 Sep 2002 13:18:22 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA10616 for ; Sun, 29 Sep 2002 13:18:17 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g8TKJs820243 for ; Sun, 29 Sep 2002 15:19:54 -0500 (CDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 8E7521FF015 for ; Sun, 29 Sep 2002 15:19:53 -0500 (CDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8TKJeaW001927; Sun, 29 Sep 2002 13:19:40 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8TKJkx9012329; Sun, 29 Sep 2002 13:19:46 -0700 (PDT) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn1-481.cisco.com [10.21.97.225]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA21204; Sun, 29 Sep 2002 13:19:44 -0700 (PDT) Message-Id: <4.3.2.7.2.20020929130901.06c0ab60@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 29 Sep 2002 13:17:59 -0700 To: "Natale, Robert C (Bob)" From: Andy Bierman Subject: Re: Help/guidance on L2TPv3 MIB draft Cc: Jed Lau , mibs@ops.ietf.org, agentx@dorothy.bmc.com In-Reply-To: <305D2EAC01C45448A7F3ECC487666F6C0286F7C3@md6370exch004u.ns e.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list At 03:46 PM 9/29/2002 -0400, Natale, Robert C (Bob) wrote: >At 8/19/2002:08:26 PM, Jed Lau wrote: I have a strong objection to this suggestion to change a MIB design solely to make AgentX implementations easier. When AgentX was chartered, there was an understanding that sub-agents would be transparent to NMS applications (command generators). Asking MIB writers to use a more complicated design is a hack. It makes the MIB more complicated for everybody, for the sake of a corner case. That's not good engineering. Andy >Hi Jed, > >Please review this MIB for compatibility with the >IETF standard SNMP agent extensibility protocol, >AgentX (RFC2741...and RFC2742 can also give you >some additional insight into AgentX operations). > >The fundamental issue is that scalar objects are >potentially problematic for AgentX. They should be >avoided by putting them into a table indexed by >some form of "AgentEntityID" object (an exercise >left to the implementer for now :-(). > >Note that the issue of AgentX compatibility for >MIB writers will be addressed in a forthcoming >Internet Draft that I will submit...perhaps with >an extended applicability statement for AgentX >(Sections 4.2, 4.3, and 4.4 of RFC2741 do a good >job of the basics already)...for consideration by >the relevant IETF WGs. My hope is that consideration >of this Draft will lead to adding a statement or two >to the standard "SNMP Framework" boilerplate to >document these requirements for MIB writers. > >Guidance from Bert re where to discuss this >issue -- AgentX compatibility guidelines for >SNMP MIBs -- will be appreciated. (The AgentX >e-mail list is still operative, but the WG is >closed pending further work when its time to >move to Full Standard status.) > >Cheers, > >BobN >- - - - - >>Hi, >> >>I am one of three co-authors of the L2TPv3 MIB draft. I attended the IETF >in >>Yokohama in July, and I got this e-mail address during one of the >plenaries. I >>understand that somebody behind this e-mail address might be able to >provide us >>with some guidance in developing our MIB. >> >>The first draft of the MIB is . >We'd >>like to get some feedback regarding our organization of the MIB tables. The >>L2TPv3 (Layer Two Tunneling Protocol, Version 3) MIB borrows a lot from its >>predecessor, . However, it introduces a >>new framework that, we hope, allows us to better modularize the various >>components of the tunneling protocol (e.g. pseudowire, payload, transport, >>etc.). The intention is to allow future enhancements to the protocol (e.g. >>additions to the list of supported payloads or transport types) to occur in >>scalable and modular manner. >> >>I intend to go into further details and ask some specific questions in a >>subsequent e-mail. Should I send follow-up e-mails to this address, or >should >>I interface with a specific individual? >> >>Thanks in advance. >> >>Jed Lau From owner-agentx@dorothy.bmc.com Sun Sep 29 17:35:48 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09525 for ; Sun, 29 Sep 2002 17:35:48 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g8TLevv10648; Sun, 29 Sep 2002 16:40:57 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id OAA10729 for agentx-list; Sun, 29 Sep 2002 14:33:09 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id OAA10724 for ; Sun, 29 Sep 2002 14:33:03 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g8TLYeA14909 for ; Sun, 29 Sep 2002 16:34:40 -0500 (CDT) Received: from hoemail2.firewall.lucent.com (unknown [192.11.226.163]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id E60C420EF94 for ; Sun, 29 Sep 2002 16:34:01 -0500 (CDT) Received: from md6370exch004u.wins.lucent.com (h135-114-172-12.lucent.com [135.114.172.12]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g8TLY2Z02385 for ; Sun, 29 Sep 2002 17:34:02 -0400 (EDT) Received: by md6370exch004u.nse.lucent.com with Internet Mail Service (5.5.2653.19) id ; Sun, 29 Sep 2002 17:34:01 -0400 Message-ID: <305D2EAC01C45448A7F3ECC487666F6C0286F7D1@md6370exch004u.nse.lucent.com> From: "Natale, Robert C (Bob)" To: Andy Bierman , "Natale, Robert C (Bob)" Cc: Jed Lau , mibs@ops.ietf.org, agentx@dorothy.bmc.com Subject: RE: Help/guidance on L2TPv3 MIB draft Date: Sun, 29 Sep 2002 17:33:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Hi Andy, I think you have missed the point of the discussion around AgentX at the time it was developed concerning MIB design. There are some MIB design approaches that are preferable for (open standard) extensible agent implementation in general. Enabling multi-sub-agent support of sub-agent-specific configuration (or similar) attributes -- normally represented as scalar objects in monolithic agent designs -- via the tabular approach that you seem to consider "more complicated" (?) is one of those straight- forward (my assertion) approaches. Our hope was to promote such MIB design choices going forward. Improving MIB designs along these lines *might* become more important if the SNMP community decides to extend the scope of MIB functionality as part of an attempt to rejuvenate SNMP[v3] as the management protocol of choice in ever-wider arenas. As per its original design intent -- and the Applicability statements in section 4.2 of RFC2741 -- AgentX can certainly support MIB designs that implement a monolithic agent approach to scalar objects...in which case a single-sub-agent handles such objects (which might or might not be a limitation for any given application...and wouldn't be for any MIB that is expected to be implemented only by a single sub-agent with a given master agent scope). Cheers, BobN - - - - - > -----Original Message----- > From: Andy Bierman [mailto:abierman@cisco.com] > Sent: Sunday, September 29, 2002 4:18 PM > To: Natale, Robert C (Bob) > Cc: Jed Lau; mibs@ops.ietf.org; agentx@dorothy.bmc.com > Subject: Re: Help/guidance on L2TPv3 MIB draft > > > At 03:46 PM 9/29/2002 -0400, Natale, Robert C (Bob) wrote: > >At 8/19/2002:08:26 PM, Jed Lau wrote: > > I have a strong objection to this suggestion to change > a MIB design solely to make AgentX implementations easier. > When AgentX was chartered, there was an understanding that > sub-agents would be transparent to NMS applications (command > generators). Asking MIB writers to use a more complicated > design is a hack. It makes the MIB more complicated > for everybody, for the sake of a corner case. That's not > good engineering. > > Andy > > > > >Hi Jed, > > > >Please review this MIB for compatibility with the > >IETF standard SNMP agent extensibility protocol, > >AgentX (RFC2741...and RFC2742 can also give you > >some additional insight into AgentX operations). > > > >The fundamental issue is that scalar objects are > >potentially problematic for AgentX. They should be > >avoided by putting them into a table indexed by > >some form of "AgentEntityID" object (an exercise > >left to the implementer for now :-(). > > > >Note that the issue of AgentX compatibility for > >MIB writers will be addressed in a forthcoming > >Internet Draft that I will submit...perhaps with > >an extended applicability statement for AgentX > >(Sections 4.2, 4.3, and 4.4 of RFC2741 do a good > >job of the basics already)...for consideration by > >the relevant IETF WGs. My hope is that consideration > >of this Draft will lead to adding a statement or two > >to the standard "SNMP Framework" boilerplate to > >document these requirements for MIB writers. > > > >Guidance from Bert re where to discuss this > >issue -- AgentX compatibility guidelines for > >SNMP MIBs -- will be appreciated. (The AgentX > >e-mail list is still operative, but the WG is > >closed pending further work when its time to > >move to Full Standard status.) > > > >Cheers, > > > >BobN > >- - - - - > >>Hi, > >> > >>I am one of three co-authors of the L2TPv3 MIB draft. I > attended the IETF > >in > >>Yokohama in July, and I got this e-mail address during one of the > >plenaries. I > >>understand that somebody behind this e-mail address might be able to > >provide us > >>with some guidance in developing our MIB. > >> > >>The first draft of the MIB is > . > >We'd > >>like to get some feedback regarding our organization of the > MIB tables. The > >>L2TPv3 (Layer Two Tunneling Protocol, Version 3) MIB > borrows a lot from its > >>predecessor, . However, > it introduces a > >>new framework that, we hope, allows us to better modularize > the various > >>components of the tunneling protocol (e.g. pseudowire, > payload, transport, > >>etc.). The intention is to allow future enhancements to the > protocol (e.g. > >>additions to the list of supported payloads or transport > types) to occur in > >>scalable and modular manner. > >> > >>I intend to go into further details and ask some specific > questions in a > >>subsequent e-mail. Should I send follow-up e-mails to this > address, or > >should > >>I interface with a specific individual? > >> > >>Thanks in advance. > >> > >>Jed Lau > From owner-agentx@dorothy.bmc.com Sun Sep 29 18:27:58 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10092 for ; Sun, 29 Sep 2002 18:27:58 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g8TMX8729682; Sun, 29 Sep 2002 17:33:08 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA10825 for agentx-list; Sun, 29 Sep 2002 15:25:33 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA10820 for ; Sun, 29 Sep 2002 15:25:27 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g8TMR3l02361 for ; Sun, 29 Sep 2002 17:27:03 -0500 (CDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 8E1181FF01C for ; Sun, 29 Sep 2002 17:27:02 -0500 (CDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8TMQuIm002078; Sun, 29 Sep 2002 15:26:56 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8TMQt43012846; Sun, 29 Sep 2002 15:26:55 -0700 (PDT) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn1-481.cisco.com [10.21.97.225]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA06172; Sun, 29 Sep 2002 15:26:53 -0700 (PDT) Message-Id: <4.3.2.7.2.20020929152124.06c00f00@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 29 Sep 2002 15:25:05 -0700 To: "Natale, Robert C (Bob)" From: Andy Bierman Subject: RE: Help/guidance on L2TPv3 MIB draft Cc: "Natale, Robert C (Bob)" , Jed Lau , mibs@ops.ietf.org, agentx@dorothy.bmc.com In-Reply-To: <305D2EAC01C45448A7F3ECC487666F6C0286F7D1@md6370exch004u.ns e.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list At 05:33 PM 9/29/2002 -0400, Natale, Robert C (Bob) wrote: >Hi Andy, > >I think you have missed the point of the >discussion around AgentX at the time it >was developed concerning MIB design. There I don't think it's a good idea to force a MIB designer to use a table when a scalar is needed, just for the sake of AgentX. Why would multiple sub-agents need to register for a scalar anyway? Monolithic vs. sub-agent design has nothing to do with whether or not a MIB object is designed to have one instance or many instances. Andy >are some MIB design approaches that are >preferable for (open standard) extensible >agent implementation in general. Enabling >multi-sub-agent support of sub-agent-specific >configuration (or similar) attributes -- >normally represented as scalar objects in >monolithic agent designs -- via the tabular >approach that you seem to consider "more >complicated" (?) is one of those straight- >forward (my assertion) approaches. Our hope >was to promote such MIB design choices going >forward. Improving MIB designs along these >lines *might* become more important if the >SNMP community decides to extend the scope >of MIB functionality as part of an attempt >to rejuvenate SNMP[v3] as the management >protocol of choice in ever-wider arenas. > >As per its original design intent -- and >the Applicability statements in section 4.2 >of RFC2741 -- AgentX can certainly support >MIB designs that implement a monolithic >agent approach to scalar objects...in which >case a single-sub-agent handles such objects >(which might or might not be a limitation >for any given application...and wouldn't be >for any MIB that is expected to be implemented >only by a single sub-agent with a given >master agent scope). > >Cheers, > >BobN >- - - - - >> -----Original Message----- >> From: Andy Bierman [mailto:abierman@cisco.com] >> Sent: Sunday, September 29, 2002 4:18 PM >> To: Natale, Robert C (Bob) >> Cc: Jed Lau; mibs@ops.ietf.org; agentx@dorothy.bmc.com >> Subject: Re: Help/guidance on L2TPv3 MIB draft >> >> >> At 03:46 PM 9/29/2002 -0400, Natale, Robert C (Bob) wrote: >> >At 8/19/2002:08:26 PM, Jed Lau wrote: >> >> I have a strong objection to this suggestion to change >> a MIB design solely to make AgentX implementations easier. >> When AgentX was chartered, there was an understanding that >> sub-agents would be transparent to NMS applications (command >> generators). Asking MIB writers to use a more complicated >> design is a hack. It makes the MIB more complicated >> for everybody, for the sake of a corner case. That's not >> good engineering. >> >> Andy >> >> >> >> >Hi Jed, >> > >> >Please review this MIB for compatibility with the >> >IETF standard SNMP agent extensibility protocol, >> >AgentX (RFC2741...and RFC2742 can also give you >> >some additional insight into AgentX operations). >> > >> >The fundamental issue is that scalar objects are >> >potentially problematic for AgentX. They should be >> >avoided by putting them into a table indexed by >> >some form of "AgentEntityID" object (an exercise >> >left to the implementer for now :-(). >> > >> >Note that the issue of AgentX compatibility for >> >MIB writers will be addressed in a forthcoming >> >Internet Draft that I will submit...perhaps with >> >an extended applicability statement for AgentX >> >(Sections 4.2, 4.3, and 4.4 of RFC2741 do a good >> >job of the basics already)...for consideration by >> >the relevant IETF WGs. My hope is that consideration >> >of this Draft will lead to adding a statement or two >> >to the standard "SNMP Framework" boilerplate to >> >document these requirements for MIB writers. >> > >> >Guidance from Bert re where to discuss this >> >issue -- AgentX compatibility guidelines for >> >SNMP MIBs -- will be appreciated. (The AgentX >> >e-mail list is still operative, but the WG is >> >closed pending further work when its time to >> >move to Full Standard status.) >> > >> >Cheers, >> > >> >BobN >> >- - - - - >> >>Hi, >> >> >> >>I am one of three co-authors of the L2TPv3 MIB draft. I >> attended the IETF >> >in >> >>Yokohama in July, and I got this e-mail address during one of the >> >plenaries. I >> >>understand that somebody behind this e-mail address might be able to >> >provide us >> >>with some guidance in developing our MIB. >> >> >> >>The first draft of the MIB is >> . >> >We'd >> >>like to get some feedback regarding our organization of the >> MIB tables. The >> >>L2TPv3 (Layer Two Tunneling Protocol, Version 3) MIB >> borrows a lot from its >> >>predecessor, . However, >> it introduces a >> >>new framework that, we hope, allows us to better modularize >> the various >> >>components of the tunneling protocol (e.g. pseudowire, >> payload, transport, >> >>etc.). The intention is to allow future enhancements to the >> protocol (e.g. >> >>additions to the list of supported payloads or transport >> types) to occur in >> >>scalable and modular manner. >> >> >> >>I intend to go into further details and ask some specific >> questions in a >> >>subsequent e-mail. Should I send follow-up e-mails to this >> address, or >> >should >> >>I interface with a specific individual? >> >> >> >>Thanks in advance. >> >> >> >>Jed Lau >> From owner-agentx@dorothy.bmc.com Mon Sep 30 08:07:55 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29932 for ; Mon, 30 Sep 2002 08:07:54 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g8UCCNG29460; Mon, 30 Sep 2002 07:12:24 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id FAA12232 for agentx-list; Mon, 30 Sep 2002 05:04:08 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id FAA12227 for ; Mon, 30 Sep 2002 05:04:05 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g8UC5fC05963 for ; Mon, 30 Sep 2002 07:05:41 -0500 (CDT) Received: from agitator.ibr.cs.tu-bs.de (unknown [134.169.34.18]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 8505920EFAC for ; Mon, 30 Sep 2002 07:05:38 -0500 (CDT) Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id g8UC5ewT007385 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Mon, 30 Sep 2002 14:05:40 +0200 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id g8UC5bCQ015899 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Mon, 30 Sep 2002 14:05:37 +0200 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id g8UC5b0h015896; Mon, 30 Sep 2002 14:05:37 +0200 Date: Mon, 30 Sep 2002 14:05:37 +0200 Message-Id: <200209301205.g8UC5b0h015896@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: bnatale@lucent.com Cc: mibs@ops.ietf.org, agentx@dorothy.bmc.com In-reply-to: <305D2EAC01C45448A7F3ECC487666F6C0286F7D1@md6370exch004u.nse.lucent.com> (bnatale@lucent.com) Subject: Re: Help/guidance on L2TPv3 MIB draft References: <305D2EAC01C45448A7F3ECC487666F6C0286F7D1@md6370exch004u.nse.lucent.com> Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list >>>>> Natale, Robert C (Bob) writes: Bob> I think you have missed the point of the discussion around AgentX Bob> at the time it was developed concerning MIB design. There are Bob> some MIB design approaches that are preferable for (open Bob> standard) extensible agent implementation in general. [...] I guess you two are not well communcating. My understanding is that Bob talks about objects such as ifNumber which are problematic when the counted ifEntry rows exist in different sub-agents. I do not think Bob is talking about scalars in general, which is what Andy seem to have in mind. /js -- Juergen Schoenwaelder From owner-agentx@dorothy.bmc.com Mon Sep 30 11:54:37 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09365 for ; Mon, 30 Sep 2002 11:54:37 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g8UFxEP04482; Mon, 30 Sep 2002 10:59:14 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id IAA12688 for agentx-list; Mon, 30 Sep 2002 08:51:14 -0700 (PDT) Received: from flicker.bmc.com (flicker.bmc.com [172.20.8.40]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id IAA12683 for ; Mon, 30 Sep 2002 08:51:11 -0700 (PDT) Received: from mx-us-sjc-2-int.bmc.com (IDENT:postfix@[198.175.229.198]) by flicker.bmc.com (8.10.2/8.10.2) with ESMTP id g8UFrVc19819 for ; Mon, 30 Sep 2002 08:53:31 -0700 (PDT) Received: from agitator.ibr.cs.tu-bs.de (agitator.ibr.cs.tu-bs.de [134.169.34.18]) by mx-us-sjc-2-int.bmc.com (Postfix) with ESMTP id 185EC222F2A for ; Mon, 30 Sep 2002 16:26:46 -0500 (CDT) Received: from hansa.ibr.cs.tu-bs.de (hansa.ibr.cs.tu-bs.de [134.169.34.81]) by agitator.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id g8UFr1wT023358 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Mon, 30 Sep 2002 17:53:02 +0200 Received: from hansa.ibr.cs.tu-bs.de (schoenw@localhost [127.0.0.1]) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) with ESMTP id g8UFqxCQ025260 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=FAIL); Mon, 30 Sep 2002 17:52:59 +0200 Received: (from schoenw@localhost) by hansa.ibr.cs.tu-bs.de (8.12.3/8.12.3/Debian -4) id g8UFqwVf025257; Mon, 30 Sep 2002 17:52:58 +0200 Date: Mon, 30 Sep 2002 17:52:58 +0200 Message-Id: <200209301552.g8UFqwVf025257@hansa.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: mrw@windriver.com Cc: mibs@ops.ietf.org, agentx@dorothy.bmc.com In-reply-to: <5.1.0.14.2.20020930104133.02a4bae0@mail.windriver.com> (message from Margaret Wasserman on Mon, 30 Sep 2002 10:48:10 -0400) Subject: Re: Help/guidance on L2TPv3 MIB draft References: < <305D2EAC01C45448A7F3ECC487666F6C0286F7D1@md6370exch004u.nse.lucent.com> <305D2EAC01C45448A7F3ECC487666F6C0286F7D1@md6370exch004u.nse.lucent.com> <5.1.0.14.2.20020930104133.02a4bae0@mail.windriver.com> Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list >>>>> Margaret Wasserman writes: Margaret> I never understood the value of the "fooNumber" variables to Margaret> begin with... [...] This is just an example. There are other variables that might have similar implications from an AgentX perspective which are not so obviously questionable or problematic. Margaret> Why would it be more useful to present them as a table? Margaret> And, how would you index such a table? I guess Bob wants to have them indexed by something which relates to the sub-agent relationship, which means that the sub-agent structure would not be transparent for management applications. I am not arguing for Bob's or Andy's position. I am just trying to make the discussion more useful to us. And we really should agree on a single mailing list if this thread continues. Margaret> Not just idle speculation -- I'm working on a MIB right now Margaret> that (for historical reasons) will probably continue to have Margaret> one of these irritating little buggers... Historical reasons translates to STATUS deprecated or obsolete as far as I am concerned... /js -- Juergen Schoenwaelder From owner-agentx@dorothy.bmc.com Mon Sep 30 13:53:52 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14840 for ; Mon, 30 Sep 2002 13:53:52 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g8UHws100400; Mon, 30 Sep 2002 12:58:54 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id KAA12941 for agentx-list; Mon, 30 Sep 2002 10:51:06 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id KAA12936 for ; Mon, 30 Sep 2002 10:51:01 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g8UHqbZ24098 for ; Mon, 30 Sep 2002 12:52:37 -0500 (CDT) Received: from mercury.mv.net (mercury.mv.net [199.125.85.40]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 9B1701FF016 for ; Mon, 30 Sep 2002 12:52:36 -0500 (CDT) Received: from ieee.org (bnh-1-10.mv.com [199.125.99.10]) by mercury.mv.net (8.9.3/8.9.3/mem-20020217) with ESMTP id NAA15206; Mon, 30 Sep 2002 13:52:15 -0400 (EDT) Message-ID: <3D98900D.305FAD60@ieee.org> Date: Mon, 30 Sep 2002 13:55:25 -0400 From: Mark Ellison Organization: Ellison Software Consulting, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Margaret Wasserman Cc: Juergen Schoenwaelder , bnatale@lucent.com, mibs@ops.ietf.org, agentx@dorothy.bmc.com, Andy Bierman Subject: Re: Help/guidance on L2TPv3 MIB draft References: < <305D2EAC01C45448A7F3ECC487666F6C0286F7D1@md6370exch004u.nse.lucent.com> <305D2EAC01C45448A7F3ECC487666F6C0286F7D1@md6370exch004u.nse.lucent.com> <5.1.0.14.2.20020930104133.02a4bae0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 7bit Hi Margaret, There is a trade off, with respect to subagents, when implementing AgentX subagents. Most of the problematic issues revolve around tables for which there are "companion scalar attributes". The most referenced example is ifNumber and ifTable. One of the goals for AgentX is to provide a means for horizontal slices (rows) of tables to owned by different subagents. So the problem becomes which subagent knows the (accurate) value of ifNumber when several subagents each own rows presented during a walk on the ifTable. As an implemtor, the following are solutions I can think of. (1) don't design MIB modules with "companion scalar attributes" like ifNumber. ifNumber is kind of an extreme example, as you have pointed out. (2) use an "orchestrator subagent" that registers for the companion scalar attributes that can return a correct value. (Note that an orchestrator subagent that registers the OID just above the table attributes (e.g. ifEntry or ifTable) is necessary whenever a row can be created within the table.) (3) implement the "companion scalar attributes" in a non-default context (This is essentially what happened with RFC 1493, the bridge MIB, which was designed for a bridge, when a device implemented a single bridge). In my opinion, a non-starter. Since this thread concerns review of a MIB module, it makes sense to mention solution (1) above. For monolithic agents, those that are not designed to be runtime extensible, accommodating AgentX during MIB design looks like an unnecessary change. Regards, Mark Ellison Ellison Software Consulting, Inc. Margaret Wasserman wrote: > > > >I guess you two are not well communcating. My understanding is that > >Bob talks about objects such as ifNumber which are problematic when > >the counted ifEntry rows exist in different sub-agents. I do not think > >Bob is talking about scalars in general, which is what Andy seem to > >have in mind. > > I never understood the value of the "fooNumber" variables to begin > with... > > They are complex to maintain for a large, dynamic table (like a > routing table). > > They don't reflect the number of entries that are actually > visible to the manager, so a manager can't expect to see that > number of entries in the table. > > And, for a large, dynamic table, the number of entries is likely to > change in the time it takes to do enough get-nexts and/or get-bulks > to download it. > > But, assuming that you believe that they have any use at all... > > Why would it be more useful to present them as a table? And, > how would you index such a table? > > Not just idle speculation -- I'm working on a MIB right now that (for > historical reasons) will probably continue to have one of these > irritating little buggers... > > Margaret From owner-agentx@dorothy.bmc.com Mon Sep 30 14:40:53 2002 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16862 for ; Mon, 30 Sep 2002 14:40:53 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g8UIjlv18435; Mon, 30 Sep 2002 13:45:48 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA13024 for agentx-list; Mon, 30 Sep 2002 11:38:08 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id LAA13019 for ; Mon, 30 Sep 2002 11:38:03 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g8UIddG18963 for ; Mon, 30 Sep 2002 13:39:39 -0500 (CDT) Received: from sj-msg-core-4.cisco.com (unknown [171.71.163.54]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id B922F20EFD6 for ; Mon, 30 Sep 2002 13:39:41 -0500 (CDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8UIddot009359; Mon, 30 Sep 2002 11:39:39 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8UIdcQa029512; Mon, 30 Sep 2002 11:39:38 -0700 (PDT) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn1-481.cisco.com [10.21.97.225]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA10932; Mon, 30 Sep 2002 11:39:36 -0700 (PDT) Message-Id: <4.3.2.7.2.20020930112646.06c380f8@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 30 Sep 2002 11:37:47 -0700 To: Mark Ellison From: Andy Bierman Subject: Re: Help/guidance on L2TPv3 MIB draft Cc: Margaret Wasserman , Juergen Schoenwaelder , bnatale@lucent.com, mibs@ops.ietf.org, agentx@dorothy.bmc.com In-Reply-To: <3D98900D.305FAD60@ieee.org> References: < <305D2EAC01C45448A7F3ECC487666F6C0286F7D1@md6370exch004u.nse.lucent.com> <305D2EAC01C45448A7F3ECC487666F6C0286F7D1@md6370exch004u.nse.lucent.com> <5.1.0.14.2.20020930104133.02a4bae0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list At 01:55 PM 9/30/2002 -0400, Mark Ellison wrote: >Hi Margaret, > >There is a trade off, with respect to subagents, when implementing AgentX >subagents. > >Most of the problematic issues revolve around tables for which there are >"companion scalar attributes". The most referenced example is ifNumber and >ifTable. > >One of the goals for AgentX is to provide a means for horizontal slices >(rows) of tables to owned by different subagents. So the problem becomes >which subagent knows the (accurate) value of ifNumber when several >subagents each own rows presented during a walk on the ifTable. > >As an implemtor, the following are solutions I can think of. Here is one more design approach: (4) Allow for sub-agent to sub-agent queries. E.g., the sub-agent that registers for ifNumber sends a request to every other sub-agent for the number of rows in ifEntry owned by that sub-agent. Either this or (2) below are acceptable because they don't force MIB design changes. Andy >(1) don't design MIB modules with "companion scalar attributes" like >ifNumber. ifNumber is kind of an extreme example, as you have pointed out. > >(2) use an "orchestrator subagent" that registers for the companion scalar >attributes that can return a correct value. (Note that an orchestrator >subagent that registers the OID just above the table attributes (e.g. >ifEntry or ifTable) is necessary whenever a row can be created within the >table.) > >(3) implement the "companion scalar attributes" in a non-default context >(This is essentially what happened with RFC 1493, the bridge MIB, which was >designed for a bridge, when a device implemented a single bridge). In my >opinion, a non-starter. > >Since this thread concerns review of a MIB module, it makes sense to >mention solution (1) above. > >For monolithic agents, those that are not designed to be runtime >extensible, accommodating AgentX during MIB design looks like an >unnecessary change. > >Regards, > >Mark Ellison >Ellison Software Consulting, Inc. > >Margaret Wasserman wrote: > >> > >> >I guess you two are not well communcating. My understanding is that >> >Bob talks about objects such as ifNumber which are problematic when >> >the counted ifEntry rows exist in different sub-agents. I do not think >> >Bob is talking about scalars in general, which is what Andy seem to >> >have in mind. >> >> I never understood the value of the "fooNumber" variables to begin >> with... >> >> They are complex to maintain for a large, dynamic table (like a >> routing table). >> >> They don't reflect the number of entries that are actually >> visible to the manager, so a manager can't expect to see that >> number of entries in the table. >> >> And, for a large, dynamic table, the number of entries is likely to >> change in the time it takes to do enough get-nexts and/or get-bulks >> to download it. >> >> But, assuming that you believe that they have any use at all... >> >> Why would it be more useful to present them as a table? And, >> how would you index such a table? >> >> Not just idle speculation -- I'm working on a MIB right now that (for >> historical reasons) will probably continue to have one of these >> irritating little buggers... >> >> Margaret From owner-agentx@dorothy.bmc.com Mon Sep 30 16:23:19 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20003 for ; Mon, 30 Sep 2002 16:23:19 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g8UKSD501376; Mon, 30 Sep 2002 15:28:13 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id NAA13209 for agentx-list; Mon, 30 Sep 2002 13:20:22 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id NAA13204 for ; Mon, 30 Sep 2002 13:20:17 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g8UKLr213379 for ; Mon, 30 Sep 2002 15:21:53 -0500 (CDT) Received: from mercury.mv.net (unknown [199.125.85.40]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id 57E1A20EF9E for ; Mon, 30 Sep 2002 15:21:55 -0500 (CDT) Received: from ieee.org (bnh-4-26.mv.com [199.125.99.218]) by mercury.mv.net (8.9.3/8.9.3/mem-20020217) with ESMTP id QAA28165; Mon, 30 Sep 2002 16:21:45 -0400 (EDT) Message-ID: <3D98B31A.D6596CAC@ieee.org> Date: Mon, 30 Sep 2002 16:24:58 -0400 From: Mark Ellison Organization: Ellison Software Consulting, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Andy Bierman Cc: Margaret Wasserman , Juergen Schoenwaelder , bnatale@lucent.com, mibs@ops.ietf.org, agentx@dorothy.bmc.com Subject: Re: Help/guidance on L2TPv3 MIB draft References: < <305D2EAC01C45448A7F3ECC487666F6C0286F7D1@md6370exch004u.nse.lucent.com> <305D2EAC01C45448A7F3ECC487666F6C0286F7D1@md6370exch004u.nse.lucent.com> <5.1.0.14.2.20020930104133.02a4bae0@mail.windriver.com> <4.3.2.7.2.20020930112646.06c380f8@fedex.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Content-Transfer-Encoding: 7bit Hi Andy, Allowing for subagent to subagent queries would be predicated upon having sufficient security in place. Support for the SNMPv3 security has been proposed as work items (see the "security credentials" and "isAccessAllowed()" threads on the agentx-email list). Until there is an update to the AgentX protocol, this sort of orchestration must occur "out of scope" or "out of band" to a standards compliant snmp agent. I would suspect the subagent knowing about certain scalars would likely be part of the same daemon or process as that responsible for spawning instance daemons, so would probably already contain the instrumentation, or access to it the local instrumentation's of the scalar without additional demands on the snmp agent. I think this true for both monolithic and run time extensible agents. If the eos and sming working groups create changes to the operations and the underlying PDU structure, then there is a definite need to make changes to AgentX to support these new features (One option would be to convert everything per `on the wire' for compatibility with the current set of AgentX PDUs, but this would be extremely inefficient). So I think there'll be ample time to discuss subagent to subagent requests as well. In the meantime, pointing out issues to MIB designers is still a very good tool. Regards, Mark Andy Bierman wrote: > [deletions] > > Here is one more design approach: > > (4) Allow for sub-agent to sub-agent queries. E.g., the sub-agent that > registers for ifNumber sends a request to every other sub-agent for > the number of rows in ifEntry owned by that sub-agent. > > Either this or (2) below are acceptable because they don't force > MIB design changes. > > Andy > [deletions] From owner-agentx@dorothy.bmc.com Mon Sep 30 18:11:48 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22926 for ; Mon, 30 Sep 2002 18:11:48 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g8UMGjT17846; Mon, 30 Sep 2002 17:16:46 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA13456 for agentx-list; Mon, 30 Sep 2002 15:08:56 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id PAA13451 for ; Mon, 30 Sep 2002 15:08:51 -0700 (PDT) Received: from mx-us-hou-2-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g8UMARM10617 for ; Mon, 30 Sep 2002 17:10:27 -0500 (CDT) Received: from postman.bayarea.net (postman.bayarea.net [205.219.84.13]) by mx-us-hou-2-int.bmc.com (Postfix) with SMTP id 6766B1FF006 for ; Mon, 30 Sep 2002 17:10:26 -0500 (CDT) Received: from host.dsperkins.com (shell4.BAYAREA.NET [209.128.82.1]) by postman.bayarea.net (8.9.3/8.9.3) with ESMTP id PAA28425; Mon, 30 Sep 2002 15:06:13 -0700 (PDT) (envelope-from dperkins@dsperkins.com) Message-Id: <5.1.1.6.2.20020930145433.0343c1f0@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Mon, 30 Sep 2002 15:04:42 -0700 To: Mark Ellison , Andy Bierman From: "David T. Perkins" Subject: Re: Help/guidance on L2TPv3 MIB draft Cc: Margaret Wasserman , Juergen Schoenwaelder , bnatale@lucent.com, mibs@ops.ietf.org, agentx@dorothy.bmc.com In-Reply-To: <3D98B31A.D6596CAC@ieee.org> References: < <305D2EAC01C45448A7F3ECC487666F6C0286F7D1@md6370exch004u.nse.lucent.com> <305D2EAC01C45448A7F3ECC487666F6C0286F7D1@md6370exch004u.nse.lucent.com> <5.1.0.14.2.20020930104133.02a4bae0@mail.windriver.com> <4.3.2.7.2.20020930112646.06c380f8@fedex.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list HI, I suggest that this is really a system problem, and not an agentX or SNMP problem. Its a system problem because a well designed system that supports management should not require an agentX hack to add support for another interface. So if I was the first developer to add support for a new interface and there was not an system interface to add in the support for management, I would add one to an open source OS, and for closed source OSs, then I would work with the vendor. Only after ALL other available options were exhausted would I add an agentX hack. Why do I call it a hack? It is because ideally all management information should be available via all management interfaces to a system. That is, there should be system calls to present info on a CLI, present via a WEB server, and SNMP agent. As soon as you do a "quick and dirty" job to circumvent the OS, then you find you need to provide it for other management interfaces. The result being extra cost and lower integrity than if the wholistic approach is taken. Note that there are some vendors (such as MicroSoft) that make things difficult. But for all others it is criminal to go the hack approach. At 04:24 PM 9/30/2002 -0400, Mark Ellison wrote: >Hi Andy, > >Allowing for subagent to subagent queries would be predicated upon having >sufficient security in place. Support for the SNMPv3 security has been proposed >as work items (see the "security credentials" and "isAccessAllowed()" threads >on the agentx-email list). > >Until there is an update to the AgentX protocol, this sort of orchestration must >occur "out of scope" or "out of band" to a standards compliant snmp agent. > >I would suspect the subagent knowing about certain scalars would likely be part >of the same daemon or process as that responsible for spawning instance daemons, >so would probably already contain the instrumentation, or access to it the local >instrumentation's of the scalar without additional demands on the snmp agent. I >think this true for both monolithic and run time extensible agents. > >If the eos and sming working groups create changes to the operations and the >underlying PDU structure, then there is a definite need to make changes to >AgentX to support these new features (One option would be to convert everything >per `on the wire' for compatibility with the current set of AgentX PDUs, but >this would be extremely inefficient). So I think there'll be ample time to >discuss subagent to subagent requests as well. > >In the meantime, pointing out issues to MIB designers is still a very good tool. > >Regards, > >Mark > > >Andy Bierman wrote: > >> [deletions] >> >> Here is one more design approach: >> >> (4) Allow for sub-agent to sub-agent queries. E.g., the sub-agent that >> registers for ifNumber sends a request to every other sub-agent for >> the number of rows in ifEntry owned by that sub-agent. >> >> Either this or (2) below are acceptable because they don't force >> MIB design changes. >> >> Andy >> > >[deletions] Regards, /david t. perkins From owner-agentx@dorothy.bmc.com Mon Sep 30 21:24:46 2002 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01144 for ; Mon, 30 Sep 2002 21:24:45 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g911TlH19751; Mon, 30 Sep 2002 20:29:47 -0500 (CDT) Received: (from root@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id SAA13800 for agentx-list; Mon, 30 Sep 2002 18:21:56 -0700 (PDT) Received: from tattler.bmc.com (tattler.bmc.com [172.17.0.117]) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) with ESMTP id SAA13795 for ; Mon, 30 Sep 2002 18:21:50 -0700 (PDT) Received: from mx-us-hou-1-int.bmc.com (localhost [127.0.0.1]) by tattler.bmc.com (8.10.2/8.10.2) with ESMTP id g911NQx02882 for ; Mon, 30 Sep 2002 20:23:26 -0500 (CDT) Received: from auemail2.firewall.lucent.com (unknown [192.11.223.163]) by mx-us-hou-1-int.bmc.com (Postfix) with SMTP id A5CBD20F002 for ; Mon, 30 Sep 2002 20:23:27 -0500 (CDT) Received: from md6370exch004u.wins.lucent.com (h135-114-172-12.lucent.com [135.114.172.12]) by auemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g911NOV05507 for ; Mon, 30 Sep 2002 21:23:28 -0400 (EDT) Received: by md6370exch004u.nse.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 30 Sep 2002 21:23:24 -0400 Message-ID: <305D2EAC01C45448A7F3ECC487666F6C028E4179@md6370exch004u.nse.lucent.com> From: "Natale, Robert C (Bob)" To: mibs@ops.ietf.org Subject: RE: Help/guidance on L2TPv3 MIB draft Date: Mon, 30 Sep 2002 21:23:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-agentx@dorothy.bmc.com Precedence: bulk List-Id: IETF Agentx Working Group mailing list Ha! That's what I love/hate about getting into discussions of fundamental concepts on SNMP lists: Before you know it, you're into "criminal hacks". Amazing. Let me drop back to "thinking about MIBs 101": The cases in which a MIB *should* be designed from the perspective of being instantiated by only a single agent entity on a managed system (host:port) are a few special cases. In the general case, a MIB should *always* be designed from the perspective of multiple instances being supported concurrently, by multiple independent agent entities, on a managed system. When you think this through, you will come to the realization that it is nearly axiomatic wrt design principles. Extrapolating from that axiom leads you to the realization that scalar objects are as out-of-place in MIBs as non-normalized constructs are in a relational database schema. Avoiding the problem is trivial, both in terms of identifying a logical approach and in terms of implementation effort and runtime overhead. The one thing Dave said below that I can agree with is that this is not an AgentX issue (and hence I suggest that any further follow up should go only to the mibs@ops.ietf.org list ...I've bcc'd the AgentX list to give everyone a chance to join the mibs list). AgentX provides the standardized extensible SNMP agent framework that makes best use of multiply instantiable MIBs, but readily supports the (degenerate) case of a MIB designed for single instance use only (RFC2741, Sec. 4.2.1), as well as a range of applications that span both models. To sum it up, my basic assertion is: MIBs designed to be multiply instantiable are better designed MIBs in the general case than MIBs that are designed to be singly instantiable. That they also enable maximum benefit from AgentX is a freebie by-product of their design. However, there may be some special cases where singly instantiable MIBs are not inappropriate. Nonetheless, it is also axiomatic that a multiply instantiable MIB can inherently support single instance configurations, while the converse, in the general case, does not hold. I can't wait to see what the level after "criminal hack" is! :-) Cheers (sincerely...this is not a matter of life and death for me), BobN - - - - - > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Monday, September 30, 2002 6:05 PM > To: Mark Ellison; Andy Bierman > Cc: Margaret Wasserman; Juergen Schoenwaelder; bnatale@lucent.com; > mibs@ops.ietf.org; agentx@dorothy.bmc.com > Subject: Re: Help/guidance on L2TPv3 MIB draft > > > HI, > > I suggest that this is really a system problem, and not an agentX > or SNMP problem. Its a system problem because a well designed system > that supports management should not require an agentX hack to add > support for another interface. So if I was the first developer to > add support for a new interface and there was not an system interface > to add in the support for management, I would add one to an open > source OS, and for closed source OSs, then I would work with the > vendor. Only after ALL other available options were exhausted would > I add an agentX hack. > > Why do I call it a hack? It is because ideally all management > information > should be available via all management interfaces to a > system. That is, > there should be system calls to present info on a CLI, present via > a WEB server, and SNMP agent. As soon as you do a "quick and dirty" > job to circumvent the OS, then you find you need to provide it for > other management interfaces. The result being extra cost and lower > integrity than if the wholistic approach is taken. Note that there > are some vendors (such as MicroSoft) that make things difficult. But > for all others it is criminal to go the hack approach. > > > At 04:24 PM 9/30/2002 -0400, Mark Ellison wrote: > >Hi Andy, > > > >Allowing for subagent to subagent queries would be > predicated upon having > >sufficient security in place. Support for the SNMPv3 > security has been proposed > >as work items (see the "security credentials" and > "isAccessAllowed()" threads > >on the agentx-email list). > > > >Until there is an update to the AgentX protocol, this sort > of orchestration must > >occur "out of scope" or "out of band" to a standards > compliant snmp agent. > > > >I would suspect the subagent knowing about certain scalars > would likely be part > >of the same daemon or process as that responsible for > spawning instance daemons, > >so would probably already contain the instrumentation, or > access to it the local > >instrumentation's of the scalar without additional demands > on the snmp agent. I > >think this true for both monolithic and run time extensible agents. > > > >If the eos and sming working groups create changes to the > operations and the > >underlying PDU structure, then there is a definite need to > make changes to > >AgentX to support these new features (One option would be > to convert everything > >per `on the wire' for compatibility with the current set of > AgentX PDUs, but > >this would be extremely inefficient). So I think there'll > be ample time to > >discuss subagent to subagent requests as well. > > > >In the meantime, pointing out issues to MIB designers is > still a very good tool. > > > >Regards, > > > >Mark > > > > > >Andy Bierman wrote: > > > >> [deletions] > >> > >> Here is one more design approach: > >> > >> (4) Allow for sub-agent to sub-agent queries. E.g., the > sub-agent that > >> registers for ifNumber sends a request to every other > sub-agent for > >> the number of rows in ifEntry owned by that sub-agent. > >> > >> Either this or (2) below are acceptable because they don't force > >> MIB design changes. > >> > >> Andy > >> > > > >[deletions] > Regards, > /david t. perkins >