From mailman-admin@ietf.org Mon Mar 1 09:13:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20775 for ; Mon, 1 Mar 2004 09:13:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxoAE-0003n9-58 for disman-archive@lists.ietf.org; Mon, 01 Mar 2004 09:12:58 -0500 Date: Mon, 01 Mar 2004 09:12:58 -0500 Message-ID: <20040301141258.27462.4112.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: disman-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, disman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for disman-archive@lists.ietf.org: List Password // URL ---- -------- disman@ietf.org hixour https://www1.ietf.org/mailman/options/disman/disman-archive%40lists.ietf.org From exim@www1.ietf.org Mon Mar 1 09:22:48 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22478 for ; Mon, 1 Mar 2004 09:22:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxoJH-0005db-Jm for disman-archive@odin.ietf.org; Mon, 01 Mar 2004 09:22:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21EMJHf021660 for disman-archive@odin.ietf.org; Mon, 1 Mar 2004 09:22:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxoJH-0005dB-Bq for disman-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 09:22:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22311 for ; Mon, 1 Mar 2004 09:22:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxoJF-0007mq-00 for disman-web-archive@ietf.org; Mon, 01 Mar 2004 09:22:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axo6P-0004Wr-00 for disman-web-archive@ietf.org; Mon, 01 Mar 2004 09:09:03 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Axo1y-0003L0-02 for disman-web-archive@ietf.org; Mon, 01 Mar 2004 09:04:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Axo0q-0007Rp-3S for disman-web-archive@ietf.org; Mon, 01 Mar 2004 09:03:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axo0o-0002L3-M7 for disman-web-archive@ietf.org; Mon, 01 Mar 2004 09:03:14 -0500 Date: Mon, 01 Mar 2004 09:03:14 -0500 Message-ID: <20040301140314.27462.31196.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: disman-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, disman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for disman-web-archive@ietf.org: List Password // URL ---- -------- disman@ietf.org carehu https://www1.ietf.org/mailman/options/disman/disman-web-archive%40ietf.org From disman-admin@ietf.org Mon Mar 1 19:06:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14156 for ; Mon, 1 Mar 2004 19:06:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxQA-00038J-It; Mon, 01 Mar 2004 19:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxPK-00035n-Ta for disman@optimus.ietf.org; Mon, 01 Mar 2004 19:05:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14083 for ; Mon, 1 Mar 2004 19:05:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxPH-0004OE-00 for disman@ietf.org; Mon, 01 Mar 2004 19:05:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxOW-0004Hv-00 for disman@ietf.org; Mon, 01 Mar 2004 19:04:20 -0500 Received: from barry.mail.mindspring.net ([207.69.200.25]) by ietf-mx with esmtp (Exim 4.12) id 1AxxNu-0004BA-00 for disman@ietf.org; Mon, 01 Mar 2004 19:03:42 -0500 Received: from [192.168.167.40] (helo=wamui02.slb.atl.earthlink.net) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AxxNu-0006Ev-00 for disman@ietf.org; Mon, 01 Mar 2004 19:03:42 -0500 Message-ID: <31338358.1078185822904.JavaMail.root@wamui02.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: disman@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 09:03:42 +0900 (GMT+09:00) Content-Transfer-Encoding: 7bit Hi - WG las call was supposed to conclude today. I haven't seen any comment on draft-ietf-disman-remops-mib-v2-01.txt I haven't even received any indication that anyone has even read it. I will not hand this over to our AD until I have some reasonable assurance that someone has actually read it and found it acceptable. Randy disman WG chair From exim@www1.ietf.org Mon Mar 1 19:08:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14257 for ; Mon, 1 Mar 2004 19:08:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxS8-0003Pp-K5 for disman-archive@odin.ietf.org; Mon, 01 Mar 2004 19:08:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22084UW013115 for disman-archive@odin.ietf.org; Mon, 1 Mar 2004 19:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxS8-0003PK-17 for disman-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 19:08:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14203 for ; Mon, 1 Mar 2004 19:07:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxS4-0004i5-00 for disman-web-archive@ietf.org; Mon, 01 Mar 2004 19:08:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxR7-0004bP-00 for disman-web-archive@ietf.org; Mon, 01 Mar 2004 19:07:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxxQA-0004UP-00 for disman-web-archive@ietf.org; Mon, 01 Mar 2004 19:06:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxQA-00038J-It; Mon, 01 Mar 2004 19:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxPK-00035n-Ta for disman@optimus.ietf.org; Mon, 01 Mar 2004 19:05:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14083 for ; Mon, 1 Mar 2004 19:05:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxPH-0004OE-00 for disman@ietf.org; Mon, 01 Mar 2004 19:05:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxOW-0004Hv-00 for disman@ietf.org; Mon, 01 Mar 2004 19:04:20 -0500 Received: from barry.mail.mindspring.net ([207.69.200.25]) by ietf-mx with esmtp (Exim 4.12) id 1AxxNu-0004BA-00 for disman@ietf.org; Mon, 01 Mar 2004 19:03:42 -0500 Received: from [192.168.167.40] (helo=wamui02.slb.atl.earthlink.net) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AxxNu-0006Ev-00 for disman@ietf.org; Mon, 01 Mar 2004 19:03:42 -0500 Message-ID: <31338358.1078185822904.JavaMail.root@wamui02.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: disman@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 Content-Transfer-Encoding: 7bit Subject: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 09:03:42 +0900 (GMT+09:00) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi - WG las call was supposed to conclude today. I haven't seen any comment on draft-ietf-disman-remops-mib-v2-01.txt I haven't even received any indication that anyone has even read it. I will not hand this over to our AD until I have some reasonable assurance that someone has actually read it and found it acceptable. Randy disman WG chair From disman-admin@ietf.org Mon Mar 1 19:29:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15313 for ; Mon, 1 Mar 2004 19:29:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxmO-0005eJ-Ol; Mon, 01 Mar 2004 19:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxlR-0005VZ-If for disman@optimus.ietf.org; Mon, 01 Mar 2004 19:28:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15234 for ; Mon, 1 Mar 2004 19:27:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxlP-00073c-00 for disman@ietf.org; Mon, 01 Mar 2004 19:28:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxkU-0006xY-00 for disman@ietf.org; Mon, 01 Mar 2004 19:27:02 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1Axxja-0006l3-00 for disman@ietf.org; Mon, 01 Mar 2004 19:26:06 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i220PXut017957; Mon, 1 Mar 2004 17:25:34 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Message-ID: Thread-Topic: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Thread-Index: AcP/7BBgvkQUyvRiQiypkOFFqAniEwAAGwXw From: "Eduardo Cardona" To: "Randy Presuhn" , X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 17:25:33 -0700 Content-Transfer-Encoding: quoted-printable Hi Randy,=20 One simple note, I tough last call was March 5th=20 We at Cablelabs are interested in adding a simplified compliance statement for ad-hoc procedure call instead of a user entry schecule entry, so an user can do a one time execution e.g PING The draft we had is almost complete,=20 Would be that an opportunity to add that? I can post that tomorrow in the list if compeling=20 Thanks Eduardo -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Monday, March 01, 2004 5:04 PM To: disman@ietf.org Subject: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Hi - WG las call was supposed to conclude today. I haven't seen any comment on draft-ietf-disman-remops-mib-v2-01.txt I haven't even received any indication that anyone has even read it. I will not hand this over to our AD until I have some reasonable assurance that someone has actually read it and found it acceptable. Randy disman WG chair From exim@www1.ietf.org Mon Mar 1 19:31:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15474 for ; Mon, 1 Mar 2004 19:31:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxoM-0005mz-Sq for disman-archive@odin.ietf.org; Mon, 01 Mar 2004 19:31:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i220V1Q4022155 for disman-archive@odin.ietf.org; Mon, 1 Mar 2004 19:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxoL-0005lB-3K for disman-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 19:31:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15411 for ; Mon, 1 Mar 2004 19:30:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxoJ-0007OG-00 for disman-web-archive@ietf.org; Mon, 01 Mar 2004 19:30:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxnK-0007GY-00 for disman-web-archive@ietf.org; Mon, 01 Mar 2004 19:29:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxxmN-0007A1-00 for disman-web-archive@ietf.org; Mon, 01 Mar 2004 19:28:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxmO-0005eJ-Ol; Mon, 01 Mar 2004 19:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxlR-0005VZ-If for disman@optimus.ietf.org; Mon, 01 Mar 2004 19:28:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15234 for ; Mon, 1 Mar 2004 19:27:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxlP-00073c-00 for disman@ietf.org; Mon, 01 Mar 2004 19:28:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxkU-0006xY-00 for disman@ietf.org; Mon, 01 Mar 2004 19:27:02 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1Axxja-0006l3-00 for disman@ietf.org; Mon, 01 Mar 2004 19:26:06 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i220PXut017957; Mon, 1 Mar 2004 17:25:34 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Message-ID: Thread-Topic: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Thread-Index: AcP/7BBgvkQUyvRiQiypkOFFqAniEwAAGwXw From: "Eduardo Cardona" To: "Randy Presuhn" , X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 1 Mar 2004 17:25:33 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Randy,=20 One simple note, I tough last call was March 5th=20 We at Cablelabs are interested in adding a simplified compliance statement for ad-hoc procedure call instead of a user entry schecule entry, so an user can do a one time execution e.g PING The draft we had is almost complete,=20 Would be that an opportunity to add that? I can post that tomorrow in the list if compeling=20 Thanks Eduardo -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Monday, March 01, 2004 5:04 PM To: disman@ietf.org Subject: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Hi - WG las call was supposed to conclude today. I haven't seen any comment on draft-ietf-disman-remops-mib-v2-01.txt I haven't even received any indication that anyone has even read it. I will not hand this over to our AD until I have some reasonable assurance that someone has actually read it and found it acceptable. Randy disman WG chair From disman-admin@ietf.org Mon Mar 1 20:47:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21223 for ; Mon, 1 Mar 2004 20:47:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axyzs-0001qw-1W; Mon, 01 Mar 2004 20:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axyyy-0001pF-QM for disman@optimus.ietf.org; Mon, 01 Mar 2004 20:46:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21116 for ; Mon, 1 Mar 2004 20:46:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axyyw-00024e-00 for disman@ietf.org; Mon, 01 Mar 2004 20:46:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axyxy-0001xL-00 for disman@ietf.org; Mon, 01 Mar 2004 20:45:03 -0500 Received: from mclean.mail.mindspring.net ([207.69.200.57]) by ietf-mx with esmtp (Exim 4.12) id 1Axyx2-0001oY-00 for disman@ietf.org; Mon, 01 Mar 2004 20:44:04 -0500 Received: from wamui09.slb.atl.earthlink.net ([192.168.167.47]) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1Axyx3-0004jp-00 for disman@ietf.org; Mon, 01 Mar 2004 20:44:05 -0500 Message-ID: <9800656.1078191845185.JavaMail.root@wamui09.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: disman@ietf.org Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 10:44:03 +0900 (GMT+09:00) Content-Transfer-Encoding: 7bit Hi - > From: Eduardo Cardona > Sent: Mar 2, 2004 9:25 AM > To: Randy Presuhn , disman@ietf.org > Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt ... > One simple note, I tough last call was March 5th No, it was supposed to end March 2. However, I'm not going to hand it to our AD until I can be reasonably sure that it has received adequate review. > We at Cablelabs are interested in adding a simplified compliance > statement for ad-hoc procedure call instead of a user entry schecule > entry, so an user can do a one time execution e.g PING It would have been nice to have learned of this earlier, rather than during WG last call. > The draft we had is almost complete, > Would be that an opportunity to add that? I can post that tomorrow in > the list if compeling ... I'd like to have this discussion sooner rather than later, so please make your specific proposal as quickly as you can. My opinion as a technical contributor is that the case for these changes would need to be fairly compelling if they would result in the remote operations MIB cycling at proposed rather than advancing to draft standard. As working group chair, I want to ensure that whatever course we take reflects WG consensus. So, balancing the need for bringing this to a conclusion with the need to ensure that the technical issues are properly considered, I'll entertain discussion of this issue ("ad hoc procedure call") until Friday noon (Korean Time). Shortly thereafter I'll make a call on whether there is consensus to modify the draft regarding this specific proposal. Randy From exim@www1.ietf.org Mon Mar 1 20:49:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21468 for ; Mon, 1 Mar 2004 20:49:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axz1w-0002MA-Ve for disman-archive@odin.ietf.org; Mon, 01 Mar 2004 20:49:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i221n8aZ009051 for disman-archive@odin.ietf.org; Mon, 1 Mar 2004 20:49:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axz1w-0002LF-1f for disman-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 20:49:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21365 for ; Mon, 1 Mar 2004 20:49:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axz1r-0002Uq-00 for disman-web-archive@ietf.org; Mon, 01 Mar 2004 20:49:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axz0r-0002Le-00 for disman-web-archive@ietf.org; Mon, 01 Mar 2004 20:48:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axyzr-00029U-00 for disman-web-archive@ietf.org; Mon, 01 Mar 2004 20:46:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axyzs-0001qw-1W; Mon, 01 Mar 2004 20:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axyyy-0001pF-QM for disman@optimus.ietf.org; Mon, 01 Mar 2004 20:46:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21116 for ; Mon, 1 Mar 2004 20:46:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axyyw-00024e-00 for disman@ietf.org; Mon, 01 Mar 2004 20:46:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axyxy-0001xL-00 for disman@ietf.org; Mon, 01 Mar 2004 20:45:03 -0500 Received: from mclean.mail.mindspring.net ([207.69.200.57]) by ietf-mx with esmtp (Exim 4.12) id 1Axyx2-0001oY-00 for disman@ietf.org; Mon, 01 Mar 2004 20:44:04 -0500 Received: from wamui09.slb.atl.earthlink.net ([192.168.167.47]) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1Axyx3-0004jp-00 for disman@ietf.org; Mon, 01 Mar 2004 20:44:05 -0500 Message-ID: <9800656.1078191845185.JavaMail.root@wamui09.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: disman@ietf.org Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 10:44:03 +0900 (GMT+09:00) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi - > From: Eduardo Cardona > Sent: Mar 2, 2004 9:25 AM > To: Randy Presuhn , disman@ietf.org > Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt ... > One simple note, I tough last call was March 5th No, it was supposed to end March 2. However, I'm not going to hand it to our AD until I can be reasonably sure that it has received adequate review. > We at Cablelabs are interested in adding a simplified compliance > statement for ad-hoc procedure call instead of a user entry schecule > entry, so an user can do a one time execution e.g PING It would have been nice to have learned of this earlier, rather than during WG last call. > The draft we had is almost complete, > Would be that an opportunity to add that? I can post that tomorrow in > the list if compeling ... I'd like to have this discussion sooner rather than later, so please make your specific proposal as quickly as you can. My opinion as a technical contributor is that the case for these changes would need to be fairly compelling if they would result in the remote operations MIB cycling at proposed rather than advancing to draft standard. As working group chair, I want to ensure that whatever course we take reflects WG consensus. So, balancing the need for bringing this to a conclusion with the need to ensure that the technical issues are properly considered, I'll entertain discussion of this issue ("ad hoc procedure call") until Friday noon (Korean Time). Shortly thereafter I'll make a call on whether there is consensus to modify the draft regarding this specific proposal. Randy From disman-admin@ietf.org Tue Mar 2 12:07:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19541 for ; Tue, 2 Mar 2004 12:07:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyDME-0000I0-5D; Tue, 02 Mar 2004 12:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyDLr-0000CZ-Cw for disman@optimus.ietf.org; Tue, 02 Mar 2004 12:06:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19498 for ; Tue, 2 Mar 2004 12:06:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyDLp-00040g-00 for disman@ietf.org; Tue, 02 Mar 2004 12:06:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyDKr-0003ql-00 for disman@ietf.org; Tue, 02 Mar 2004 12:05:38 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AyDJu-0003bq-00; Tue, 02 Mar 2004 12:04:39 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i22H45ut003679; Tue, 2 Mar 2004 10:04:05 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Message-ID: Thread-Topic: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Thread-Index: AcP/+FAa0cy3TLYoQ9G5WHj5Y4XgEQAc9PKQ From: "Eduardo Cardona" To: "Randy Presuhn" , Cc: "Ipcdn List (E-mail)" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 10:04:05 -0700 Content-Transfer-Encoding: quoted-printable Randy,=20 Few comments,=20 I review the MIB and appears compelling respect to previous RFC=20 Just one comment (*) traceRouteCtlMiscOptions=20 It appears to me an uncanny object and rather implementations may opt to extend the capabilities in the private branch, could leave with that to avoid deprecation, of if there are field implementations.=20 Regardless of the additions to the MIB I apologize for the late notice, Before sending a complete proposal and get your concept of the best approach, below is the proposal to add a simplified Compliance statement for devices not requiring to keep constant status of PING/TRACEROUTE operations, only remote operation per operator request. We are looking at your comments about the clear overlap in draft-ietf-disman-remops-mib-v2-01.txt With IPCDN draft http://www.ipcdn.org/drafts/draft-ietf-ipcdn-cable-gateway-tools-mib-00. txt ( currently out of date in IETF drafts site) which is clearly a subset of the DISMAN-PING-MIB=20 Lectors refer to http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/msg00818. html Should the proposal below being include in the remops MIB or should we update IPCDN cable gateway Tools MIB module to be just the compliance statement outlined below?=20 RFC 3014 (LOG-MIB) introduces the concept of "named log" and "null named log" default entry for devices not supporting the named log=20 Named log is analog to disman remops draft for "OwnerIndex" and "TestName" where default entries are created (null owner, null TestName) for a manager requested operation of PING/ TRACEROUTE, NSLOOKUP, mostly for small foot-print devices with no network monitoring role at the connectivity level as pretended with this updated RFC. In summary A new Compliance Statement for small devices with no monitoring capabilities to : 1) remove the constant pulling and login information=20 2) remove the test row creation=20 - CTL* Results* tables only default entries (null owner, null TestName) 3) History* tables not required. - New basicGroups to exclude History* objects and other objects which are not relevant to the simplified=20 system.=20 - Create an additional set of Compliance statements to require the new Groups and other objects Compliance=20 requirements MIN-ACCESS clauses mainly Schema of the content of the new Compliance statement:=20 List of objects not to include in basicPingGroup OBJECT-GROUP clause qnd/or hints for OBJECT Compliances: pingMaxConcurrentRequests -- remove pingCtlDataFill -- remove or MIN-ACCESS read-only default value is OK pingCtlFrequency -- remove Only one test pingCtlType -- remove or MIN-ACCESS read-only pingCtlByPassRouteTable -- remove or MIN-ACCESS read-only pingCtlDSField -- MIN-ACCESS read-only pingCtlStorageType -- remove=20 pingCtlRowStatus -- SYNTAX RowStatus (notReady(2) WRITE-SYNTAX RowStatus (active(1), notInService(3) =20 pingCtlIfIndex -- not to include pingProbeHistory* -- not to include. List of objects not to include in basicTraceRouteGroup OBJECT-GROUP clause and/or hints for OBJECT Compliances: traceRouteMaxConcurrentRequests -- remove traceRouteCtlType -- remove or MIN-ACCESS read-only traceRouteCtlDSField -- MIN-ACCESS read-only traceRouteCtlByPassRouteTable -- remove or MIN-ACCESS read-only traceRouteCtlIfIndex -- not to include traceRouteCtlMiscOptions -- not to include traceRouteCtlDontFragment -- remove or MIN-ACCESS read-only traceRouteCtlInitialTtl -- remove or MIN-ACCESS traceRouteCtlFrequency -- remove only one test traceRouteCtlDescr -- remove traceRouteCtlCreateHopsEntries -- remove HopsEntries not required. traceRouteCtlRowStatus -- SYNTAX RowStatus (notReady(2) WRITE-SYNTAX RowStatus (active(1), notInService(3) =20 traceRouteCtlStorageType -- remove traceRouteProbeHistory* -- not to include. List of objects not to include in basicLookupGroup OBJECT-GROUP clause and/or hints for OBJECT Compliances: lookupMaxConcurrentRequests -- remove lookupPurgeTime -- remove lookupCtlRowStatus -- SYNTAX RowStatus (notReady(2) WRITE-SYNTAX RowStatus (active(1), notInService(3) =20 Best Regards Eduardo -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Monday, March 01, 2004 6:44 PM To: disman@ietf.org Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Hi - > From: Eduardo Cardona > Sent: Mar 2, 2004 9:25 AM > To: Randy Presuhn , disman@ietf.org > Subject: RE: [Disman] WG last call on=20 > draft-ietf-disman-remops-mib-v2-01.txt ... > One simple note, I tough last call was March 5th No, it was supposed to end March 2. However, I'm not going to hand it to our AD until I can be reasonably sure that it has received adequate review. > We at Cablelabs are interested in adding a simplified compliance=20 > statement for ad-hoc procedure call instead of a user entry schecule=20 > entry, so an user can do a one time execution e.g PING It would have been nice to have learned of this earlier, rather than during WG last call. > The draft we had is almost complete, > Would be that an opportunity to add that? I can post that tomorrow in > the list if compeling=20 ... I'd like to have this discussion sooner rather than later, so please make your specific proposal as quickly as you can. My opinion as a technical contributor is that the case for these changes would need to be fairly compelling if they would result in the remote operations MIB cycling at proposed rather than advancing to draft standard. As working group chair, I want to ensure that whatever course we take reflects WG consensus. So, balancing the need for bringing this to a conclusion with the need to ensure that the technical issues are properly considered, I'll entertain discussion of this issue ("ad hoc procedure call") until Friday noon (Korean Time). Shortly thereafter I'll make a call on whether there is consensus to modify the draft regarding this specific proposal. Randy From exim@www1.ietf.org Tue Mar 2 12:09:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19646 for ; Tue, 2 Mar 2004 12:09:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyDOA-0001KV-OJ for disman-archive@odin.ietf.org; Tue, 02 Mar 2004 12:09:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22H92rv005074 for disman-archive@odin.ietf.org; Tue, 2 Mar 2004 12:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyDOA-0001Ia-Bt for disman-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 12:09:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19632 for ; Tue, 2 Mar 2004 12:08:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyDO8-0004LK-00 for disman-web-archive@ietf.org; Tue, 02 Mar 2004 12:09:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyDN1-0004Bf-00 for disman-web-archive@ietf.org; Tue, 02 Mar 2004 12:07:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyDMG-00043h-00 for disman-web-archive@ietf.org; Tue, 02 Mar 2004 12:07:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyDME-0000I0-5D; Tue, 02 Mar 2004 12:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyDLr-0000CZ-Cw for disman@optimus.ietf.org; Tue, 02 Mar 2004 12:06:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19498 for ; Tue, 2 Mar 2004 12:06:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyDLp-00040g-00 for disman@ietf.org; Tue, 02 Mar 2004 12:06:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyDKr-0003ql-00 for disman@ietf.org; Tue, 02 Mar 2004 12:05:38 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AyDJu-0003bq-00; Tue, 02 Mar 2004 12:04:39 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i22H45ut003679; Tue, 2 Mar 2004 10:04:05 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Message-ID: Thread-Topic: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Thread-Index: AcP/+FAa0cy3TLYoQ9G5WHj5Y4XgEQAc9PKQ From: "Eduardo Cardona" To: "Randy Presuhn" , Cc: "Ipcdn List (E-mail)" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 10:04:05 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Randy,=20 Few comments,=20 I review the MIB and appears compelling respect to previous RFC=20 Just one comment (*) traceRouteCtlMiscOptions=20 It appears to me an uncanny object and rather implementations may opt to extend the capabilities in the private branch, could leave with that to avoid deprecation, of if there are field implementations.=20 Regardless of the additions to the MIB I apologize for the late notice, Before sending a complete proposal and get your concept of the best approach, below is the proposal to add a simplified Compliance statement for devices not requiring to keep constant status of PING/TRACEROUTE operations, only remote operation per operator request. We are looking at your comments about the clear overlap in draft-ietf-disman-remops-mib-v2-01.txt With IPCDN draft http://www.ipcdn.org/drafts/draft-ietf-ipcdn-cable-gateway-tools-mib-00. txt ( currently out of date in IETF drafts site) which is clearly a subset of the DISMAN-PING-MIB=20 Lectors refer to http://www1.ietf.org/mail-archive/working-groups/ipcdn/current/msg00818. html Should the proposal below being include in the remops MIB or should we update IPCDN cable gateway Tools MIB module to be just the compliance statement outlined below?=20 RFC 3014 (LOG-MIB) introduces the concept of "named log" and "null named log" default entry for devices not supporting the named log=20 Named log is analog to disman remops draft for "OwnerIndex" and "TestName" where default entries are created (null owner, null TestName) for a manager requested operation of PING/ TRACEROUTE, NSLOOKUP, mostly for small foot-print devices with no network monitoring role at the connectivity level as pretended with this updated RFC. In summary A new Compliance Statement for small devices with no monitoring capabilities to : 1) remove the constant pulling and login information=20 2) remove the test row creation=20 - CTL* Results* tables only default entries (null owner, null TestName) 3) History* tables not required. - New basicGroups to exclude History* objects and other objects which are not relevant to the simplified=20 system.=20 - Create an additional set of Compliance statements to require the new Groups and other objects Compliance=20 requirements MIN-ACCESS clauses mainly Schema of the content of the new Compliance statement:=20 List of objects not to include in basicPingGroup OBJECT-GROUP clause qnd/or hints for OBJECT Compliances: pingMaxConcurrentRequests -- remove pingCtlDataFill -- remove or MIN-ACCESS read-only default value is OK pingCtlFrequency -- remove Only one test pingCtlType -- remove or MIN-ACCESS read-only pingCtlByPassRouteTable -- remove or MIN-ACCESS read-only pingCtlDSField -- MIN-ACCESS read-only pingCtlStorageType -- remove=20 pingCtlRowStatus -- SYNTAX RowStatus (notReady(2) WRITE-SYNTAX RowStatus (active(1), notInService(3) =20 pingCtlIfIndex -- not to include pingProbeHistory* -- not to include. List of objects not to include in basicTraceRouteGroup OBJECT-GROUP clause and/or hints for OBJECT Compliances: traceRouteMaxConcurrentRequests -- remove traceRouteCtlType -- remove or MIN-ACCESS read-only traceRouteCtlDSField -- MIN-ACCESS read-only traceRouteCtlByPassRouteTable -- remove or MIN-ACCESS read-only traceRouteCtlIfIndex -- not to include traceRouteCtlMiscOptions -- not to include traceRouteCtlDontFragment -- remove or MIN-ACCESS read-only traceRouteCtlInitialTtl -- remove or MIN-ACCESS traceRouteCtlFrequency -- remove only one test traceRouteCtlDescr -- remove traceRouteCtlCreateHopsEntries -- remove HopsEntries not required. traceRouteCtlRowStatus -- SYNTAX RowStatus (notReady(2) WRITE-SYNTAX RowStatus (active(1), notInService(3) =20 traceRouteCtlStorageType -- remove traceRouteProbeHistory* -- not to include. List of objects not to include in basicLookupGroup OBJECT-GROUP clause and/or hints for OBJECT Compliances: lookupMaxConcurrentRequests -- remove lookupPurgeTime -- remove lookupCtlRowStatus -- SYNTAX RowStatus (notReady(2) WRITE-SYNTAX RowStatus (active(1), notInService(3) =20 Best Regards Eduardo -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Monday, March 01, 2004 6:44 PM To: disman@ietf.org Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Hi - > From: Eduardo Cardona > Sent: Mar 2, 2004 9:25 AM > To: Randy Presuhn , disman@ietf.org > Subject: RE: [Disman] WG last call on=20 > draft-ietf-disman-remops-mib-v2-01.txt ... > One simple note, I tough last call was March 5th No, it was supposed to end March 2. However, I'm not going to hand it to our AD until I can be reasonably sure that it has received adequate review. > We at Cablelabs are interested in adding a simplified compliance=20 > statement for ad-hoc procedure call instead of a user entry schecule=20 > entry, so an user can do a one time execution e.g PING It would have been nice to have learned of this earlier, rather than during WG last call. > The draft we had is almost complete, > Would be that an opportunity to add that? I can post that tomorrow in > the list if compeling=20 ... I'd like to have this discussion sooner rather than later, so please make your specific proposal as quickly as you can. My opinion as a technical contributor is that the case for these changes would need to be fairly compelling if they would result in the remote operations MIB cycling at proposed rather than advancing to draft standard. As working group chair, I want to ensure that whatever course we take reflects WG consensus. So, balancing the need for bringing this to a conclusion with the need to ensure that the technical issues are properly considered, I'll entertain discussion of this issue ("ad hoc procedure call") until Friday noon (Korean Time). Shortly thereafter I'll make a call on whether there is consensus to modify the draft regarding this specific proposal. Randy From disman-admin@ietf.org Tue Mar 2 19:14:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11833 for ; Tue, 2 Mar 2004 19:14:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyK1Q-0005Mt-6I; Tue, 02 Mar 2004 19:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyK1H-0005M2-6l for disman@optimus.ietf.org; Tue, 02 Mar 2004 19:13:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11763 for ; Tue, 2 Mar 2004 19:13:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyK1F-00024z-00 for disman@ietf.org; Tue, 02 Mar 2004 19:13:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyK0H-0001vf-00 for disman@ietf.org; Tue, 02 Mar 2004 19:12:49 -0500 Received: from tisch.mail.mindspring.net ([207.69.200.157]) by ietf-mx with esmtp (Exim 4.12) id 1AyJzJ-0001nA-00; Tue, 02 Mar 2004 19:11:49 -0500 Received: from [192.168.167.41] (helo=wamui03.slb.atl.earthlink.net) by tisch.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AyJzJ-0000Fc-00; Tue, 02 Mar 2004 19:11:49 -0500 Message-ID: <29620639.1078272709925.JavaMail.root@wamui03.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: disman@ietf.org Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Cc: "Ipcdn List (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,REMOVE_IN_QUOTES autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Mar 2004 09:11:49 +0900 (GMT+09:00) Content-Transfer-Encoding: 7bit Hi - > From: Eduardo Cardona > Sent: Mar 3, 2004 2:04 AM > To: Randy Presuhn , disman@ietf.org > Cc: "Ipcdn List (E-mail)" > Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt ... Thanks for the comments! ... > (*) traceRouteCtlMiscOptions > It appears to me an uncanny object and rather implementations may opt to > extend the capabilities in the private branch, could leave with that to > avoid deprecation, of if there are field implementations. any suggested changes? ... > Should the proposal below being include in the remops MIB or should we > update IPCDN cable gateway Tools MIB module to be just the compliance > statement outlined below? Both seem reasonable. If we can include a "basic" compliance statement to suit your needs without jeopardizing progression, that seems like an option that I would prefer as a technical contributor, though I admit that it is not a strong preference and would like to hear other opinions. > RFC 3014 (LOG-MIB) introduces the concept of "named log" and "null named > log" default entry for devices not supporting the named log > Named log is analog to disman remops draft for "OwnerIndex" and > "TestName" where default entries are created > (null owner, null TestName) for a manager requested operation of PING/ > TRACEROUTE, NSLOOKUP, mostly for small foot-print devices with no > network monitoring role at the connectivity level as pretended with this > updated RFC. I have no problem with this in principle, and think it would be really nice if we can verify that the MIB definitions do not preclude operating this way. > In summary A new Compliance Statement for small devices with no > monitoring capabilities to : ... I'd phrase it a bit differently. Rather than "remove" information, I think the proposal is to ensure that it can function meaningfully using a small subset of the objects. I'd like to hear from Juergen (and others) regarding the details of the proposed compliance material, especially with regard to whether there are any details in the current object definitions that would prevent this usage. Randy From exim@www1.ietf.org Tue Mar 2 19:16:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11914 for ; Tue, 2 Mar 2004 19:16:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyK3C-0005d4-Qy for disman-archive@odin.ietf.org; Tue, 02 Mar 2004 19:15:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i230FoGQ021632 for disman-archive@odin.ietf.org; Tue, 2 Mar 2004 19:15:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyK3C-0005cp-Mi for disman-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 19:15:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11901 for ; Tue, 2 Mar 2004 19:15:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyK3B-0002Kg-00 for disman-web-archive@ietf.org; Tue, 02 Mar 2004 19:15:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyK2E-0002Do-00 for disman-web-archive@ietf.org; Tue, 02 Mar 2004 19:14:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyK1V-00026t-00 for disman-web-archive@ietf.org; Tue, 02 Mar 2004 19:14:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyK1Q-0005Mt-6I; Tue, 02 Mar 2004 19:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyK1H-0005M2-6l for disman@optimus.ietf.org; Tue, 02 Mar 2004 19:13:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11763 for ; Tue, 2 Mar 2004 19:13:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyK1F-00024z-00 for disman@ietf.org; Tue, 02 Mar 2004 19:13:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyK0H-0001vf-00 for disman@ietf.org; Tue, 02 Mar 2004 19:12:49 -0500 Received: from tisch.mail.mindspring.net ([207.69.200.157]) by ietf-mx with esmtp (Exim 4.12) id 1AyJzJ-0001nA-00; Tue, 02 Mar 2004 19:11:49 -0500 Received: from [192.168.167.41] (helo=wamui03.slb.atl.earthlink.net) by tisch.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1AyJzJ-0000Fc-00; Tue, 02 Mar 2004 19:11:49 -0500 Message-ID: <29620639.1078272709925.JavaMail.root@wamui03.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: disman@ietf.org Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Cc: "Ipcdn List (E-mail)" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Mar 2004 09:11:49 +0900 (GMT+09:00) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,REMOVE_IN_QUOTES autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi - > From: Eduardo Cardona > Sent: Mar 3, 2004 2:04 AM > To: Randy Presuhn , disman@ietf.org > Cc: "Ipcdn List (E-mail)" > Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt ... Thanks for the comments! ... > (*) traceRouteCtlMiscOptions > It appears to me an uncanny object and rather implementations may opt to > extend the capabilities in the private branch, could leave with that to > avoid deprecation, of if there are field implementations. any suggested changes? ... > Should the proposal below being include in the remops MIB or should we > update IPCDN cable gateway Tools MIB module to be just the compliance > statement outlined below? Both seem reasonable. If we can include a "basic" compliance statement to suit your needs without jeopardizing progression, that seems like an option that I would prefer as a technical contributor, though I admit that it is not a strong preference and would like to hear other opinions. > RFC 3014 (LOG-MIB) introduces the concept of "named log" and "null named > log" default entry for devices not supporting the named log > Named log is analog to disman remops draft for "OwnerIndex" and > "TestName" where default entries are created > (null owner, null TestName) for a manager requested operation of PING/ > TRACEROUTE, NSLOOKUP, mostly for small foot-print devices with no > network monitoring role at the connectivity level as pretended with this > updated RFC. I have no problem with this in principle, and think it would be really nice if we can verify that the MIB definitions do not preclude operating this way. > In summary A new Compliance Statement for small devices with no > monitoring capabilities to : ... I'd phrase it a bit differently. Rather than "remove" information, I think the proposal is to ensure that it can function meaningfully using a small subset of the objects. I'd like to hear from Juergen (and others) regarding the details of the proposed compliance material, especially with regard to whether there are any details in the current object definitions that would prevent this usage. Randy From disman-admin@ietf.org Tue Mar 2 20:53:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19713 for ; Tue, 2 Mar 2004 20:53:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLZF-0004Hh-1J; Tue, 02 Mar 2004 20:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLYU-0004Cd-Ed for disman@optimus.ietf.org; Tue, 02 Mar 2004 20:52:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19630 for ; Tue, 2 Mar 2004 20:52:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLYR-0002iW-00 for disman@ietf.org; Tue, 02 Mar 2004 20:52:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLXa-0002Y8-00 for disman@ietf.org; Tue, 02 Mar 2004 20:51:19 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AyLWg-0002Jk-00 for disman@ietf.org; Tue, 02 Mar 2004 20:50:22 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i231nq905147 for ; Tue, 2 Mar 2004 20:49:52 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Mar 2004 20:49:52 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A5AECE1@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Disman] My Action Item: Probable Cause Liaison Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 20:49:51 -0500 hi I took an action during the disman meeting to send information to the mailing list about how people can find the liaison that was sent from ITU-T SG 4 on the topic of structured probable causes. This work would be of interest if in 5 years time, or whenever, we were looking at an Alarm MIB v2. http://www.ietf.org/IESG/LIAISON/itut-sg4-ls-structured-cause.html Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada From exim@www1.ietf.org Tue Mar 2 20:55:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19847 for ; Tue, 2 Mar 2004 20:55:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLbM-0004Sb-Jm for disman-archive@odin.ietf.org; Tue, 02 Mar 2004 20:55:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i231tC6j017140 for disman-archive@odin.ietf.org; Tue, 2 Mar 2004 20:55:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLbM-0004SN-B2 for disman-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 20:55:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19783 for ; Tue, 2 Mar 2004 20:55:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLbJ-0003Cf-00 for disman-web-archive@ietf.org; Tue, 02 Mar 2004 20:55:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLaD-0002zz-00 for disman-web-archive@ietf.org; Tue, 02 Mar 2004 20:54:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyLZE-0002qs-00 for disman-web-archive@ietf.org; Tue, 02 Mar 2004 20:53:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLZF-0004Hh-1J; Tue, 02 Mar 2004 20:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLYU-0004Cd-Ed for disman@optimus.ietf.org; Tue, 02 Mar 2004 20:52:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19630 for ; Tue, 2 Mar 2004 20:52:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLYR-0002iW-00 for disman@ietf.org; Tue, 02 Mar 2004 20:52:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLXa-0002Y8-00 for disman@ietf.org; Tue, 02 Mar 2004 20:51:19 -0500 Received: from zcars0m9.nortelnetworks.com ([47.129.242.157]) by ietf-mx with esmtp (Exim 4.12) id 1AyLWg-0002Jk-00 for disman@ietf.org; Tue, 02 Mar 2004 20:50:22 -0500 Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i231nq905147 for ; Tue, 2 Mar 2004 20:49:52 -0500 (EST) Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Mar 2004 20:49:52 -0500 Message-ID: <3549C09B853DD5119B540002A52CDD340A5AECE1@zcard0ka.ca.nortel.com> From: "Sharon Chisholm" To: disman@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Disman] My Action Item: Probable Cause Liaison Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 2 Mar 2004 20:49:51 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 hi I took an action during the disman meeting to send information to the mailing list about how people can find the liaison that was sent from ITU-T SG 4 on the topic of structured probable causes. This work would be of interest if in 5 years time, or whenever, we were looking at an Alarm MIB v2. http://www.ietf.org/IESG/LIAISON/itut-sg4-ls-structured-cause.html Sharon Chisholm Portfolio Integration Nortel Networks Ottawa, Canada From disman-admin@ietf.org Wed Mar 3 00:45:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03509 for ; Wed, 3 Mar 2004 00:45:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyPBl-0000bL-43; Wed, 03 Mar 2004 00:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyPAr-0000YO-N4 for disman@optimus.ietf.org; Wed, 03 Mar 2004 00:44:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03478 for ; Wed, 3 Mar 2004 00:44:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyPAo-0000By-00 for disman@ietf.org; Wed, 03 Mar 2004 00:44:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyP9r-00004O-00 for disman@ietf.org; Wed, 03 Mar 2004 00:43:04 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AyP8y-0007jA-00 for disman@ietf.org; Wed, 03 Mar 2004 00:42:08 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i235c7pc021954 for ; Wed, 3 Mar 2004 00:38:07 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i235c4pc021923 for ; Wed, 3 Mar 2004 00:38:05 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C400E2.4338DAA9" Message-ID: Thread-Topic: My notes from the yesterday wg meeting Thread-Index: AcQA4kEf4a+VvZ/RRtGBrjLWf1U8xQ== From: "Romascanu, Dan (Dan)" To: "Disman (E-mail)" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_40_50, HTML_FONT_FACE_BAD,HTML_MESSAGE autolearn=no version=2.60 Subject: [Disman] My notes from the yesterday wg meeting Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Mar 2004 07:42:06 +0200 This is a multi-part message in MIME format. ------_=_NextPart_001_01C400E2.4338DAA9 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Below please find my notes from the disman wg meeting yesterday, = including the original missions, typos and mis-spelling errors.=20 Regards, Dan ---------------------------------------- . Agenda bashing . status of current work . ARC - in RFC Editor Q . Alarm MIB - in IESG, not yet in RFC Editor Q. AI - Sharon will ping = the AD. If there is any problem will report back to Randy . remops update - in WLC, one comment only. Need feedback before = being forwarded to the IESG . script mib - advance to draft? Deployed, used, needs editorial = resources. Juergen S. is not at the meeting. Any feeling of urgency? No. = AI -chair to ask if the wg agrees to advance the document as is . schedule mib - identical situation . if anybody has cycles, let randy know . AI -chair to ask if the wg agrees to advance the document as is . events mib, notification / log MIB - implemented, not largely used. = Cisco is doing it, Elliott would take it as editor if there is another = vendor that does it. . Expression mib - one implementation, is this the wrong direction = because of the limitations of smi? . ITU liaison - thank you for the probable cause work. AI - Sharon to = forward the URL of the original liaison to the list.=20 . Clarification from the AD about liaisons - WG chair to send e-mail = responses, copy Bert and Scott brander . Juergen Q. - proposal for a light expression MIB . why not do it using existing MIB? . Shailadja - Advanced History Collection=20 . How is the configuration simplified? Automatic configuration . When I-D submitted, discuss on the WG list . Charter updates - Chair will submit proposal to the list, and then if = agreed to Bert=20 ------_=_NextPart_001_01C400E2.4338DAA9 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable My notes from the yesterday wg meeting

Below please find my notes = from the disman wg meeting yesterday, including the original missions, = typos and mis-spelling errors.

Regards,

Dan

----------------------------------------

=

    .       Agenda = bashing

    .       status of current = work

        .       = ‎ARC - in RFC Editor = Q

        .       = ‎Alarm MIB - in IESG, = not yet in RFC Editor Q. AI - Sharon will ping the AD. If there is any = problem will report back to Randy

        .       = ‎remops update - in = WLC, one comment only. Need feedback before being forwarded to the = IESG

        .       = ‎script mib - advance = to draft? Deployed, used, needs editorial resources. Juergen S. is not = at the meeting. Any feeling of urgency? No.  AI -chair to ask if = the wg agrees to advance the document as is

        .       = ‎schedule mib - = identical situation

            .       = ‎if anybody has = cycles, let randy know

            .       = ‎AI -chair to ask if = the wg agrees to advance the document as is

        .       = ‎events mib, = notification / log MIB - implemented, not largely used. Cisco is doing = it, Elliott would take it as editor if there is another vendor that does = it.

        .       = ‎Expression mib - one = implementation, is this the wrong direction because of the limitations = of smi?

    .       ITU liaison - thank you for = the probable cause work. AI - Sharon to forward the URL of the original = liaison to the list.

        .       = ‎Clarification from = the AD about liaisons - WG chair to send e-mail responses, copy Bert and = Scott brander

    .        Juergen Q. - proposal = for a light expression MIB

        .       = ‎why not do it using = existing MIB?

    .       Shailadja - Advanced = History Collection

        .       = ‎How is the = configuration simplified? Automatic configuration

        .       = ‎When I-D submitted, = discuss on the WG list

    .       Charter updates - Chair = will submit proposal to the list, and then if agreed to Bert =

------_=_NextPart_001_01C400E2.4338DAA9-- From exim@www1.ietf.org Wed Mar 3 00:58:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04260 for ; Wed, 3 Mar 2004 00:58:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyPOX-0002vl-Fx for disman-archive@odin.ietf.org; Wed, 03 Mar 2004 00:58:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i235wDgc011265 for disman-archive@odin.ietf.org; Wed, 3 Mar 2004 00:58:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyPOX-0002vZ-9b for disman-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 00:58:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04095 for ; Wed, 3 Mar 2004 00:58:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyPOU-0002PV-00 for disman-web-archive@ietf.org; Wed, 03 Mar 2004 00:58:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyPMD-0001o6-00 for disman-web-archive@ietf.org; Wed, 03 Mar 2004 00:55:50 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyPKd-0001RE-02 for disman-web-archive@ietf.org; Wed, 03 Mar 2004 00:54:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyPBn-00037i-Nr for disman-web-archive@ietf.org; Wed, 03 Mar 2004 00:45:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyPBl-0000bL-43; Wed, 03 Mar 2004 00:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyPAr-0000YO-N4 for disman@optimus.ietf.org; Wed, 03 Mar 2004 00:44:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03478 for ; Wed, 3 Mar 2004 00:44:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyPAo-0000By-00 for disman@ietf.org; Wed, 03 Mar 2004 00:44:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyP9r-00004O-00 for disman@ietf.org; Wed, 03 Mar 2004 00:43:04 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1AyP8y-0007jA-00 for disman@ietf.org; Wed, 03 Mar 2004 00:42:08 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i235c7pc021954 for ; Wed, 3 Mar 2004 00:38:07 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i235c4pc021923 for ; Wed, 3 Mar 2004 00:38:05 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C400E2.4338DAA9" Message-ID: Thread-Topic: My notes from the yesterday wg meeting Thread-Index: AcQA4kEf4a+VvZ/RRtGBrjLWf1U8xQ== From: "Romascanu, Dan (Dan)" To: "Disman (E-mail)" Subject: [Disman] My notes from the yesterday wg meeting Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 3 Mar 2004 07:42:06 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,HTML_40_50, HTML_FONT_FACE_BAD,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C400E2.4338DAA9 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Below please find my notes from the disman wg meeting yesterday, = including the original missions, typos and mis-spelling errors.=20 Regards, Dan ---------------------------------------- . Agenda bashing . status of current work . ARC - in RFC Editor Q . Alarm MIB - in IESG, not yet in RFC Editor Q. AI - Sharon will ping = the AD. If there is any problem will report back to Randy . remops update - in WLC, one comment only. Need feedback before = being forwarded to the IESG . script mib - advance to draft? Deployed, used, needs editorial = resources. Juergen S. is not at the meeting. Any feeling of urgency? No. = AI -chair to ask if the wg agrees to advance the document as is . schedule mib - identical situation . if anybody has cycles, let randy know . AI -chair to ask if the wg agrees to advance the document as is . events mib, notification / log MIB - implemented, not largely used. = Cisco is doing it, Elliott would take it as editor if there is another = vendor that does it. . Expression mib - one implementation, is this the wrong direction = because of the limitations of smi? . ITU liaison - thank you for the probable cause work. AI - Sharon to = forward the URL of the original liaison to the list.=20 . Clarification from the AD about liaisons - WG chair to send e-mail = responses, copy Bert and Scott brander . Juergen Q. - proposal for a light expression MIB . why not do it using existing MIB? . Shailadja - Advanced History Collection=20 . How is the configuration simplified? Automatic configuration . When I-D submitted, discuss on the WG list . Charter updates - Chair will submit proposal to the list, and then if = agreed to Bert=20 ------_=_NextPart_001_01C400E2.4338DAA9 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable My notes from the yesterday wg meeting

Below please find my notes = from the disman wg meeting yesterday, including the original missions, = typos and mis-spelling errors.

Regards,

Dan

----------------------------------------

=

    .       Agenda = bashing

    .       status of current = work

        .       = ‎ARC - in RFC Editor = Q

        .       = ‎Alarm MIB - in IESG, = not yet in RFC Editor Q. AI - Sharon will ping the AD. If there is any = problem will report back to Randy

        .       = ‎remops update - in = WLC, one comment only. Need feedback before being forwarded to the = IESG

        .       = ‎script mib - advance = to draft? Deployed, used, needs editorial resources. Juergen S. is not = at the meeting. Any feeling of urgency? No.  AI -chair to ask if = the wg agrees to advance the document as is

        .       = ‎schedule mib - = identical situation

            .       = ‎if anybody has = cycles, let randy know

            .       = ‎AI -chair to ask if = the wg agrees to advance the document as is

        .       = ‎events mib, = notification / log MIB - implemented, not largely used. Cisco is doing = it, Elliott would take it as editor if there is another vendor that does = it.

        .       = ‎Expression mib - one = implementation, is this the wrong direction because of the limitations = of smi?

    .       ITU liaison - thank you for = the probable cause work. AI - Sharon to forward the URL of the original = liaison to the list.

        .       = ‎Clarification from = the AD about liaisons - WG chair to send e-mail responses, copy Bert and = Scott brander

    .        Juergen Q. - proposal = for a light expression MIB

        .       = ‎why not do it using = existing MIB?

    .       Shailadja - Advanced = History Collection

        .       = ‎How is the = configuration simplified? Automatic configuration

        .       = ‎When I-D submitted, = discuss on the WG list

    .       Charter updates - Chair = will submit proposal to the list, and then if agreed to Bert =

------_=_NextPart_001_01C400E2.4338DAA9-- From disman-admin@ietf.org Wed Mar 3 19:28:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09684 for ; Wed, 3 Mar 2004 19:28:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygiX-0000xR-85; Wed, 03 Mar 2004 19:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygiR-0000x6-6h for disman@optimus.ietf.org; Wed, 03 Mar 2004 19:27:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09669 for ; Wed, 3 Mar 2004 19:27:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AygiP-0003U3-00 for disman@ietf.org; Wed, 03 Mar 2004 19:27:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyghU-0003Kp-00 for disman@ietf.org; Wed, 03 Mar 2004 19:26:56 -0500 Received: from hall.mail.mindspring.net ([207.69.200.60]) by ietf-mx with esmtp (Exim 4.12) id 1Ayggh-0003Bo-00 for disman@ietf.org; Wed, 03 Mar 2004 19:26:07 -0500 Received: from [192.168.167.42] (helo=wamui04.slb.atl.earthlink.net) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1Ayggc-0006WT-00; Wed, 03 Mar 2004 19:26:02 -0500 Message-ID: <6954740.1078359961850.JavaMail.root@wamui04.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: bwijnen@lucent.com Cc: disman@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Disman] Summary of disman WG session in Seoul Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 4 Mar 2004 09:26:01 +0900 (GMT+09:00) Content-Transfer-Encoding: 7bit Hi - The disman working group met Tuesday afternoon for one one-hour session at the IETF meeting in Seoul. Discussion focused on advancement of the script and schedule MIB RFCs from Proposed Standard to Draft Standard, and on experience with (as well as alternatives to) the expression and event MIB RFCs. Randy Presuhn disman WG chair From exim@www1.ietf.org Wed Mar 3 19:30:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09809 for ; Wed, 3 Mar 2004 19:30:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygkQ-00016B-3Z for disman-archive@odin.ietf.org; Wed, 03 Mar 2004 19:29:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i240TwbA004217 for disman-archive@odin.ietf.org; Wed, 3 Mar 2004 19:29:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygkP-00015w-Vu for disman-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 19:29:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09800 for ; Wed, 3 Mar 2004 19:29:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AygkO-0003ok-00 for disman-web-archive@ietf.org; Wed, 03 Mar 2004 19:29:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AygjT-0003ep-00 for disman-web-archive@ietf.org; Wed, 03 Mar 2004 19:29:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aygia-0003Va-00 for disman-web-archive@ietf.org; Wed, 03 Mar 2004 19:28:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygiX-0000xR-85; Wed, 03 Mar 2004 19:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygiR-0000x6-6h for disman@optimus.ietf.org; Wed, 03 Mar 2004 19:27:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09669 for ; Wed, 3 Mar 2004 19:27:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AygiP-0003U3-00 for disman@ietf.org; Wed, 03 Mar 2004 19:27:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyghU-0003Kp-00 for disman@ietf.org; Wed, 03 Mar 2004 19:26:56 -0500 Received: from hall.mail.mindspring.net ([207.69.200.60]) by ietf-mx with esmtp (Exim 4.12) id 1Ayggh-0003Bo-00 for disman@ietf.org; Wed, 03 Mar 2004 19:26:07 -0500 Received: from [192.168.167.42] (helo=wamui04.slb.atl.earthlink.net) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1Ayggc-0006WT-00; Wed, 03 Mar 2004 19:26:02 -0500 Message-ID: <6954740.1078359961850.JavaMail.root@wamui04.slb.atl.earthlink.net> From: Randy Presuhn Reply-To: Randy Presuhn To: bwijnen@lucent.com Cc: disman@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 Content-Transfer-Encoding: 7bit Subject: [Disman] Summary of disman WG session in Seoul Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 4 Mar 2004 09:26:01 +0900 (GMT+09:00) X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi - The disman working group met Tuesday afternoon for one one-hour session at the IETF meeting in Seoul. Discussion focused on advancement of the script and schedule MIB RFCs from Proposed Standard to Draft Standard, and on experience with (as well as alternatives to) the expression and event MIB RFCs. Randy Presuhn disman WG chair From disman-admin@ietf.org Wed Mar 3 20:43:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13691 for ; Wed, 3 Mar 2004 20:43:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayht9-00005R-1F; Wed, 03 Mar 2004 20:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyhsO-0008O4-B2 for disman@optimus.ietf.org; Wed, 03 Mar 2004 20:42:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13400 for ; Wed, 3 Mar 2004 20:42:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyhsL-0000rI-00 for disman@ietf.org; Wed, 03 Mar 2004 20:42:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyhqC-0000E4-00 for disman@ietf.org; Wed, 03 Mar 2004 20:40:01 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1Ayhof-0007ht-00 for disman@ietf.org; Wed, 03 Mar 2004 20:38:25 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Wed, 03 Mar 2004 18:37:55 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Subject: [Disman] Disman WG Meeting Minutes Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 03 Mar 2004 18:37:34 -0700 Content-Transfer-Encoding: 7bit Hello, I and Dan captured the meeting minutes of disman meeting. Following is data is what I have captured. Regards, Shailaja. Tuesday, March 2 at 1700-1800 CHAIR: Randy Presuhn List of attendees: Venue :Lotte Hotel, Seoul, South Korea. Reported By: Shailaja Yadawad. Minutes: Alarm MIB: Should be in the RFC editor queue and Sharon will ping the AD for the status. Remote Operations MIB: RFC 2925 It was felt that many in the meeting had not read the RFC2925 and hence action item on the WG members to read the RFC. Script MIB: A volunteer is required for moving the Script MIB to standard and the work is mostly admin kind. Schedule MIB: RFC 3231 A volunteer is required for moving the Schedule MIB to standard and the work is mostly admin kind. Expression MIB Mixed feedback was expressed about the MIB, some people expressed that MIB is complicated to implement and some members shared how customers are using this MIB. WG members to share implementation reports. Event MIB: RFC 2981 WG members to share implementation reports. 2.8 Notification/Log MIB: RFC 3014 A volunteer is required for moving the Notification/Log MIB to standard and the work is mostly admin kind. Randy to send interoperability report for the MIBs. Randy to send a consensus mail to the mailing list requesting for "specific item attempt to move from proposed to draft std without any changes". 3. Other relevant work (25 minutes) 3.1 ITU-T liaison statements Sharon to forward the Liason related communication mail to the WG as only "Thank you" mail has been copied to Randy. WG members to keep Bert and Scot(ITU-T) in CC list for any ITU-T communications. 3.2 Juergen to see if the proposed solution for the problem could be solved using RMON group definition. 3.3 Shailaja Yadawad's proposals for possible new work. Shailaja to submit the draft. From disman-admin@ietf.org Wed Mar 3 20:59:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14885 for ; Wed, 3 Mar 2004 20:59:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayi8b-0002Bb-QK; Wed, 03 Mar 2004 20:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayi7i-00024p-Gk for disman@optimus.ietf.org; Wed, 03 Mar 2004 20:58:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14832 for ; Wed, 3 Mar 2004 20:58:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayi7g-0004DU-00 for disman@ietf.org; Wed, 03 Mar 2004 20:58:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayi6k-00044D-00 for disman@ietf.org; Wed, 03 Mar 2004 20:57:06 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayi66-0003sn-00 for disman@ietf.org; Wed, 03 Mar 2004 20:56:27 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i241tri16445 for ; Wed, 3 Mar 2004 19:55:54 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <1699L45D>; Thu, 4 Mar 2004 02:55:52 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503B6464F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Randy Presuhn , bwijnen@lucent.com Cc: disman@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Disman] RE: Summary of disman WG session in Seoul Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 4 Mar 2004 02:55:51 +0100 Thanks Randy Bert From exim@www1.ietf.org Wed Mar 3 21:02:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15377 for ; Wed, 3 Mar 2004 21:02:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiBO-0002TE-Kk for disman-archive@odin.ietf.org; Wed, 03 Mar 2004 21:01:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2421swE009490 for disman-archive@odin.ietf.org; Wed, 3 Mar 2004 21:01:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiBO-0002Sz-Fn for disman-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 21:01:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15277 for ; Wed, 3 Mar 2004 21:01:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyiBL-00054f-00 for disman-web-archive@ietf.org; Wed, 03 Mar 2004 21:01:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayi9v-0004gW-00 for disman-web-archive@ietf.org; Wed, 03 Mar 2004 21:00:24 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayi83-0004DV-00 for disman-web-archive@ietf.org; Wed, 03 Mar 2004 20:58:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyhtJ-0003Ur-6j for disman-web-archive@ietf.org; Wed, 03 Mar 2004 20:43:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayht9-00005R-1F; Wed, 03 Mar 2004 20:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyhsO-0008O4-B2 for disman@optimus.ietf.org; Wed, 03 Mar 2004 20:42:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13400 for ; Wed, 3 Mar 2004 20:42:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyhsL-0000rI-00 for disman@ietf.org; Wed, 03 Mar 2004 20:42:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyhqC-0000E4-00 for disman@ietf.org; Wed, 03 Mar 2004 20:40:01 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1Ayhof-0007ht-00 for disman@ietf.org; Wed, 03 Mar 2004 20:38:25 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Wed, 03 Mar 2004 18:37:55 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Subject: [Disman] Disman WG Meeting Minutes Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 03 Mar 2004 18:37:34 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello, I and Dan captured the meeting minutes of disman meeting. Following is data is what I have captured. Regards, Shailaja. Tuesday, March 2 at 1700-1800 CHAIR: Randy Presuhn List of attendees: Venue :Lotte Hotel, Seoul, South Korea. Reported By: Shailaja Yadawad. Minutes: Alarm MIB: Should be in the RFC editor queue and Sharon will ping the AD for the status. Remote Operations MIB: RFC 2925 It was felt that many in the meeting had not read the RFC2925 and hence action item on the WG members to read the RFC. Script MIB: A volunteer is required for moving the Script MIB to standard and the work is mostly admin kind. Schedule MIB: RFC 3231 A volunteer is required for moving the Schedule MIB to standard and the work is mostly admin kind. Expression MIB Mixed feedback was expressed about the MIB, some people expressed that MIB is complicated to implement and some members shared how customers are using this MIB. WG members to share implementation reports. Event MIB: RFC 2981 WG members to share implementation reports. 2.8 Notification/Log MIB: RFC 3014 A volunteer is required for moving the Notification/Log MIB to standard and the work is mostly admin kind. Randy to send interoperability report for the MIBs. Randy to send a consensus mail to the mailing list requesting for "specific item attempt to move from proposed to draft std without any changes". 3. Other relevant work (25 minutes) 3.1 ITU-T liaison statements Sharon to forward the Liason related communication mail to the WG as only "Thank you" mail has been copied to Randy. WG members to keep Bert and Scot(ITU-T) in CC list for any ITU-T communications. 3.2 Juergen to see if the proposed solution for the problem could be solved using RMON group definition. 3.3 Shailaja Yadawad's proposals for possible new work. Shailaja to submit the draft. From exim@www1.ietf.org Wed Mar 3 21:02:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15409 for ; Wed, 3 Mar 2004 21:02:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiBe-0002X1-97 for disman-archive@odin.ietf.org; Wed, 03 Mar 2004 21:02:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2422ADk009724 for disman-archive@odin.ietf.org; Wed, 3 Mar 2004 21:02:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiBe-0002Wl-3w for disman-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 21:02:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15346 for ; Wed, 3 Mar 2004 21:02:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyiBb-0005Ee-00 for disman-web-archive@ietf.org; Wed, 03 Mar 2004 21:02:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyiAH-0004m8-00 for disman-web-archive@ietf.org; Wed, 03 Mar 2004 21:00:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayi8Z-0004NQ-00 for disman-web-archive@ietf.org; Wed, 03 Mar 2004 20:58:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayi8b-0002Bb-QK; Wed, 03 Mar 2004 20:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayi7i-00024p-Gk for disman@optimus.ietf.org; Wed, 03 Mar 2004 20:58:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14832 for ; Wed, 3 Mar 2004 20:58:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayi7g-0004DU-00 for disman@ietf.org; Wed, 03 Mar 2004 20:58:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayi6k-00044D-00 for disman@ietf.org; Wed, 03 Mar 2004 20:57:06 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayi66-0003sn-00 for disman@ietf.org; Wed, 03 Mar 2004 20:56:27 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i241tri16445 for ; Wed, 3 Mar 2004 19:55:54 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <1699L45D>; Thu, 4 Mar 2004 02:55:52 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503B6464F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Randy Presuhn , bwijnen@lucent.com Cc: disman@ietf.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Subject: [Disman] RE: Summary of disman WG session in Seoul Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 4 Mar 2004 02:55:51 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Thanks Randy Bert From disman-admin@ietf.org Thu Mar 4 00:47:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01646 for ; Thu, 4 Mar 2004 00:47:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AylhF-00077N-8V; Thu, 04 Mar 2004 00:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aylgz-00074Y-VJ for disman@optimus.ietf.org; Thu, 04 Mar 2004 00:46:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01445 for ; Thu, 4 Mar 2004 00:46:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aylgx-0003ah-00 for disman@ietf.org; Thu, 04 Mar 2004 00:46:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AylfK-00035o-00 for disman@ietf.org; Thu, 04 Mar 2004 00:45:03 -0500 Received: from adsl-66-127-127-227.dsl.scrm01.pacbell.net ([66.127.127.227] helo=wes.hardakers.net) by ietf-mx with esmtp (Exim 4.12) id 1Ayldu-0002k7-00 for disman@ietf.org; Thu, 04 Mar 2004 00:43:34 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id DD5CA11D573; Wed, 3 Mar 2004 21:43:29 -0800 (PST) To: "Romascanu, Dan (Dan)" Cc: "Disman (E-mail)" Subject: Re: [Disman] My notes from the yesterday wg meeting References: From: Wes Hardaker Organization: Sparta In-Reply-To: (Dan Romascanu's message of "Wed, 3 Mar 2004 07:42:06 +0200") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) XEmacs/21.5 (celeriac, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 03 Mar 2004 21:43:29 -0800 >>>>> On Wed, 3 Mar 2004 07:42:06 +0200, "Romascanu, Dan (Dan)" said: Dan> . events mib, notification / log MIB - implemented, not largely Dan> used. Cisco is doing it, Elliott would take it as editor if there Dan> is another vendor that does it. The event mib is fairly heavily used by Net-SNMP users. All of our internal monitoring -> sending traps is actually implemented on top of the event MIB. I don't think anyone is using the MIB, actually, and most of them are using configuration tokens that look something like this: monitor -r 15 -o hrSWRunName -u secname "high process memory" hrSWRunPerfMem > 10000 to actually load the data into the MIB. But the process of "doing stuff" underneath the hood all came from an older copy of the Event MIB ID. (note that we only support local agent queries though at this time) -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett From exim@www1.ietf.org Thu Mar 4 01:05:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02714 for ; Thu, 4 Mar 2004 01:05:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aylyr-0008HL-Fl for disman-archive@odin.ietf.org; Thu, 04 Mar 2004 01:05:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2465DRD031821 for disman-archive@odin.ietf.org; Thu, 4 Mar 2004 01:05:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aylyr-0008HA-Bp for disman-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 01:05:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02603 for ; Thu, 4 Mar 2004 01:05:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aylyo-0007AJ-00 for disman-web-archive@ietf.org; Thu, 04 Mar 2004 01:05:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aylwr-0006Wn-00 for disman-web-archive@ietf.org; Thu, 04 Mar 2004 01:03:09 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AylvO-0006Am-00 for disman-web-archive@ietf.org; Thu, 04 Mar 2004 01:01:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AylhS-0006wr-TW for disman-web-archive@ietf.org; Thu, 04 Mar 2004 00:47:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AylhF-00077N-8V; Thu, 04 Mar 2004 00:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aylgz-00074Y-VJ for disman@optimus.ietf.org; Thu, 04 Mar 2004 00:46:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01445 for ; Thu, 4 Mar 2004 00:46:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aylgx-0003ah-00 for disman@ietf.org; Thu, 04 Mar 2004 00:46:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AylfK-00035o-00 for disman@ietf.org; Thu, 04 Mar 2004 00:45:03 -0500 Received: from adsl-66-127-127-227.dsl.scrm01.pacbell.net ([66.127.127.227] helo=wes.hardakers.net) by ietf-mx with esmtp (Exim 4.12) id 1Ayldu-0002k7-00 for disman@ietf.org; Thu, 04 Mar 2004 00:43:34 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id DD5CA11D573; Wed, 3 Mar 2004 21:43:29 -0800 (PST) To: "Romascanu, Dan (Dan)" Cc: "Disman (E-mail)" Subject: Re: [Disman] My notes from the yesterday wg meeting References: From: Wes Hardaker Organization: Sparta In-Reply-To: (Dan Romascanu's message of "Wed, 3 Mar 2004 07:42:06 +0200") Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) XEmacs/21.5 (celeriac, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 03 Mar 2004 21:43:29 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 >>>>> On Wed, 3 Mar 2004 07:42:06 +0200, "Romascanu, Dan (Dan)" said: Dan> . events mib, notification / log MIB - implemented, not largely Dan> used. Cisco is doing it, Elliott would take it as editor if there Dan> is another vendor that does it. The event mib is fairly heavily used by Net-SNMP users. All of our internal monitoring -> sending traps is actually implemented on top of the event MIB. I don't think anyone is using the MIB, actually, and most of them are using configuration tokens that look something like this: monitor -r 15 -o hrSWRunName -u secname "high process memory" hrSWRunPerfMem > 10000 to actually load the data into the MIB. But the process of "doing stuff" underneath the hood all came from an older copy of the Event MIB ID. (note that we only support local agent queries though at this time) -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett From disman-admin@ietf.org Thu Mar 4 05:53:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07966 for ; Thu, 4 Mar 2004 05:53:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyqTM-0000nA-BQ; Thu, 04 Mar 2004 05:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayq8T-0007Ie-Dq for disman@optimus.ietf.org; Thu, 04 Mar 2004 05:31:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06575 for ; Thu, 4 Mar 2004 05:31:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayq8P-0003RQ-00 for disman@ietf.org; Thu, 04 Mar 2004 05:31:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayq7c-0003DT-00 for disman@ietf.org; Thu, 04 Mar 2004 05:30:32 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1Ayq6n-0002nB-00 for disman@ietf.org; Thu, 04 Mar 2004 05:29:42 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id A69A5866CF; Thu, 4 Mar 2004 11:29:09 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.37]) by merkur.iu-bremen.de (Postfix) with ESMTP id 8D90186643; Thu, 4 Mar 2004 11:29:06 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id DF3DE8F60; Thu, 4 Mar 2004 11:29:05 +0100 (CET) From: Juergen Schoenwaelder To: disman@ietf.org Subject: Re: [Disman] Disman WG Meeting Minutes Message-ID: <20040304102905.GA1730@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by AMaViS 0.3.12pre8 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 4 Mar 2004 11:29:05 +0100 On Wed, Mar 03, 2004 at 06:37:34PM -0700, Shailaja Yadawad wrote: > Script MIB: > > A volunteer is required for moving the Script MIB to standard and the > work is mostly admin kind. > > Schedule MIB: RFC 3231 > > A volunteer is required for moving the Schedule MIB to standard and the > work is mostly admin kind. Since I edited these documents up to now (which are still Proposed Standards), I am volunteering myself to play the editor for these documents. I am not aware of many technical issues with these documents since most of them got fixed in the revision. The only thing I have on my TODO list is a broken range of the smLaunchRunIndexNext - I think there is also an errata for this out there on the RFC Editor pages. So I think the documents are in a reasonable good shape content wise and the hard part will be to collect implementation reports. Are there people out there on this list who can provide implementation reports for RFC 3231 and RFC 3165? Were people at the meeting who have implemented these MIBs and who are interested in advancing them? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From exim@www1.ietf.org Thu Mar 4 06:13:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09451 for ; Thu, 4 Mar 2004 06:13:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyqnA-0003rH-Qg for disman-archive@odin.ietf.org; Thu, 04 Mar 2004 06:13:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24BDSdY014825 for disman-archive@odin.ietf.org; Thu, 4 Mar 2004 06:13:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyqnA-0003r2-Ld for disman-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 06:13:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09373 for ; Thu, 4 Mar 2004 06:13:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayqn6-0004cD-00 for disman-web-archive@ietf.org; Thu, 04 Mar 2004 06:13:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyqlC-0003r7-00 for disman-web-archive@ietf.org; Thu, 04 Mar 2004 06:11:26 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayqii-0003ET-00 for disman-web-archive@ietf.org; Thu, 04 Mar 2004 06:08:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyqTO-0003t2-Rl for disman-web-archive@ietf.org; Thu, 04 Mar 2004 05:53:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyqTM-0000nA-BQ; Thu, 04 Mar 2004 05:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayq8T-0007Ie-Dq for disman@optimus.ietf.org; Thu, 04 Mar 2004 05:31:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06575 for ; Thu, 4 Mar 2004 05:31:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayq8P-0003RQ-00 for disman@ietf.org; Thu, 04 Mar 2004 05:31:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayq7c-0003DT-00 for disman@ietf.org; Thu, 04 Mar 2004 05:30:32 -0500 Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx with esmtp (Exim 4.12) id 1Ayq6n-0002nB-00 for disman@ietf.org; Thu, 04 Mar 2004 05:29:42 -0500 Received: from localhost (localhost [127.0.0.1]) by merkur.iu-bremen.de (Postfix) with ESMTP id A69A5866CF; Thu, 4 Mar 2004 11:29:09 +0100 (CET) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.37]) by merkur.iu-bremen.de (Postfix) with ESMTP id 8D90186643; Thu, 4 Mar 2004 11:29:06 +0100 (CET) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id DF3DE8F60; Thu, 4 Mar 2004 11:29:05 +0100 (CET) From: Juergen Schoenwaelder To: disman@ietf.org Subject: Re: [Disman] Disman WG Meeting Minutes Message-ID: <20040304102905.GA1730@iu-bremen.de> Reply-To: j.schoenwaelder@iu-bremen.de References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.5.1+cvs20040105i X-Virus-Scanned: by AMaViS 0.3.12pre8 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 4 Mar 2004 11:29:05 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 On Wed, Mar 03, 2004 at 06:37:34PM -0700, Shailaja Yadawad wrote: > Script MIB: > > A volunteer is required for moving the Script MIB to standard and the > work is mostly admin kind. > > Schedule MIB: RFC 3231 > > A volunteer is required for moving the Schedule MIB to standard and the > work is mostly admin kind. Since I edited these documents up to now (which are still Proposed Standards), I am volunteering myself to play the editor for these documents. I am not aware of many technical issues with these documents since most of them got fixed in the revision. The only thing I have on my TODO list is a broken range of the smLaunchRunIndexNext - I think there is also an errata for this out there on the RFC Editor pages. So I think the documents are in a reasonable good shape content wise and the hard part will be to collect implementation reports. Are there people out there on this list who can provide implementation reports for RFC 3231 and RFC 3165? Were people at the meeting who have implemented these MIBs and who are interested in advancing them? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany From disman-admin@ietf.org Fri Mar 5 11:44:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15589 for ; Fri, 5 Mar 2004 11:44:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzIQb-0001rC-GS; Fri, 05 Mar 2004 11:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzIQK-0001qc-8M for disman@optimus.ietf.org; Fri, 05 Mar 2004 11:43:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15577 for ; Fri, 5 Mar 2004 11:43:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzIQH-0007VT-00 for disman@ietf.org; Fri, 05 Mar 2004 11:43:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzIPK-0007LH-00 for disman@ietf.org; Fri, 05 Mar 2004 11:42:43 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AzIOP-00071S-00; Fri, 05 Mar 2004 11:41:45 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i25GfCut003527; Fri, 5 Mar 2004 09:41:13 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Message-ID: Thread-Topic: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Thread-Index: AcQAtHyjl1N9qd0FT+WG1twTQHhagQCGD5nQ From: "Eduardo Cardona" To: "Randy Presuhn" , Cc: "Ipcdn List (E-mail)" X-Approved: ondar X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,REMOVE_IN_QUOTES autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 5 Mar 2004 09:41:03 -0700 Content-Transfer-Encoding: quoted-printable Thanks for the comments,=20 I will wait as you for hearing from authors One note below ... > (*) traceRouteCtlMiscOptions > It appears to me an uncanny object and rather implementations may opt to > extend the capabilities in the private branch, could leave with that to > avoid deprecation, of if there are field implementations.=20 any suggested changes? In the revision history : ( if option is deprecation), something like=20 The MIB object traceRouteCtlMiscOptions is being deprecated, implementations willing to extend the traceRoute functionality with proprietary parameters can follow standard procedures of extending entry tables (e.g. AUGMENTS [RFC2578]) If willing to have a direct parameters reference in the CTL entry, similar to the existing traceRouteCtlMiscOptions, uses a new object with RowPointer syntax or an ID pointing to a private table entry, ( in some cases it may simplify the configuration model if the vendor feature is just a flag or a common parameter set for all owners/testNames, pointing the test to the same parameter definition, policy, etc. =20 As I said, it seems to me to be quite unusual object definition, Due the already RFC status could be left as is, or change it for one of the above options or any other alternative.=20 Eduardo -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Tuesday, March 02, 2004 5:12 PM To: disman@ietf.org Cc: Ipcdn List (E-mail) Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Hi - > From: Eduardo Cardona > Sent: Mar 3, 2004 2:04 AM > To: Randy Presuhn , disman@ietf.org > Cc: "Ipcdn List (E-mail)" > Subject: RE: [Disman] WG last call on=20 > draft-ietf-disman-remops-mib-v2-01.txt ... Thanks for the comments! ... > (*) traceRouteCtlMiscOptions > It appears to me an uncanny object and rather implementations may opt to > extend the capabilities in the private branch, could leave with that to > avoid deprecation, of if there are field implementations.=20 any suggested changes? ... > Should the proposal below being include in the remops MIB or should we > update IPCDN cable gateway Tools MIB module to be just the compliance=20 > statement outlined below? Both seem reasonable. If we can include a "basic" compliance statement to suit your needs without jeopardizing progression, that seems like an option that I would prefer as a technical contributor, though I admit that it is not a strong preference and would like to hear other opinions. > RFC 3014 (LOG-MIB) introduces the concept of "named log" and "null=20 > named log" default entry for devices not supporting the named log=20 > Named log is analog to disman remops draft for "OwnerIndex" and=20 > "TestName" where default entries are created (null owner, null=20 > TestName) for a manager requested operation of PING/ TRACEROUTE,=20 > NSLOOKUP, mostly for small foot-print devices with no network=20 > monitoring role at the connectivity level as pretended with this=20 > updated RFC. I have no problem with this in principle, and think it would be really nice if we can verify that the MIB definitions do not preclude operating this way. > In summary A new Compliance Statement for small devices with no=20 > monitoring capabilities to : ... I'd phrase it a bit differently. Rather than "remove" information, I think the proposal is to ensure that it can function meaningfully using a small subset of the objects. I'd like to hear from Juergen (and others) regarding the details of the proposed compliance material, especially with regard to whether there are any details in the current object definitions that would prevent this usage. Randy From exim@www1.ietf.org Fri Mar 5 11:48:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15829 for ; Fri, 5 Mar 2004 11:48:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzIUy-0002MC-Bu for disman-archive@odin.ietf.org; Fri, 05 Mar 2004 11:48:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25GmWHb009054 for disman-archive@odin.ietf.org; Fri, 5 Mar 2004 11:48:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzIUy-0002Lx-7J for disman-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 11:48:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15740 for ; Fri, 5 Mar 2004 11:48:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzIUv-0000da-00 for disman-web-archive@ietf.org; Fri, 05 Mar 2004 11:48:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzITJ-0000Gy-00 for disman-web-archive@ietf.org; Fri, 05 Mar 2004 11:46:50 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AzIST-000062-01 for disman-web-archive@ietf.org; Fri, 05 Mar 2004 11:45:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AzIQe-0002Sp-3W for disman-web-archive@ietf.org; Fri, 05 Mar 2004 11:44:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzIQb-0001rC-GS; Fri, 05 Mar 2004 11:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzIQK-0001qc-8M for disman@optimus.ietf.org; Fri, 05 Mar 2004 11:43:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15577 for ; Fri, 5 Mar 2004 11:43:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzIQH-0007VT-00 for disman@ietf.org; Fri, 05 Mar 2004 11:43:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzIPK-0007LH-00 for disman@ietf.org; Fri, 05 Mar 2004 11:42:43 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1AzIOP-00071S-00; Fri, 05 Mar 2004 11:41:45 -0500 Received: from srvxchg.cablelabs.com (srvxchg.cablelabs.com [10.5.0.20]) by ondar.cablelabs.com (8.12.10/8.12.10) with ESMTP id i25GfCut003527; Fri, 5 Mar 2004 09:41:13 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Message-ID: Thread-Topic: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Thread-Index: AcQAtHyjl1N9qd0FT+WG1twTQHhagQCGD5nQ From: "Eduardo Cardona" To: "Randy Presuhn" , Cc: "Ipcdn List (E-mail)" X-Approved: ondar Content-Transfer-Encoding: quoted-printable Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 5 Mar 2004 09:41:03 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,REMOVE_IN_QUOTES autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Thanks for the comments,=20 I will wait as you for hearing from authors One note below ... > (*) traceRouteCtlMiscOptions > It appears to me an uncanny object and rather implementations may opt to > extend the capabilities in the private branch, could leave with that to > avoid deprecation, of if there are field implementations.=20 any suggested changes? In the revision history : ( if option is deprecation), something like=20 The MIB object traceRouteCtlMiscOptions is being deprecated, implementations willing to extend the traceRoute functionality with proprietary parameters can follow standard procedures of extending entry tables (e.g. AUGMENTS [RFC2578]) If willing to have a direct parameters reference in the CTL entry, similar to the existing traceRouteCtlMiscOptions, uses a new object with RowPointer syntax or an ID pointing to a private table entry, ( in some cases it may simplify the configuration model if the vendor feature is just a flag or a common parameter set for all owners/testNames, pointing the test to the same parameter definition, policy, etc. =20 As I said, it seems to me to be quite unusual object definition, Due the already RFC status could be left as is, or change it for one of the above options or any other alternative.=20 Eduardo -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Tuesday, March 02, 2004 5:12 PM To: disman@ietf.org Cc: Ipcdn List (E-mail) Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Hi - > From: Eduardo Cardona > Sent: Mar 3, 2004 2:04 AM > To: Randy Presuhn , disman@ietf.org > Cc: "Ipcdn List (E-mail)" > Subject: RE: [Disman] WG last call on=20 > draft-ietf-disman-remops-mib-v2-01.txt ... Thanks for the comments! ... > (*) traceRouteCtlMiscOptions > It appears to me an uncanny object and rather implementations may opt to > extend the capabilities in the private branch, could leave with that to > avoid deprecation, of if there are field implementations.=20 any suggested changes? ... > Should the proposal below being include in the remops MIB or should we > update IPCDN cable gateway Tools MIB module to be just the compliance=20 > statement outlined below? Both seem reasonable. If we can include a "basic" compliance statement to suit your needs without jeopardizing progression, that seems like an option that I would prefer as a technical contributor, though I admit that it is not a strong preference and would like to hear other opinions. > RFC 3014 (LOG-MIB) introduces the concept of "named log" and "null=20 > named log" default entry for devices not supporting the named log=20 > Named log is analog to disman remops draft for "OwnerIndex" and=20 > "TestName" where default entries are created (null owner, null=20 > TestName) for a manager requested operation of PING/ TRACEROUTE,=20 > NSLOOKUP, mostly for small foot-print devices with no network=20 > monitoring role at the connectivity level as pretended with this=20 > updated RFC. I have no problem with this in principle, and think it would be really nice if we can verify that the MIB definitions do not preclude operating this way. > In summary A new Compliance Statement for small devices with no=20 > monitoring capabilities to : ... I'd phrase it a bit differently. Rather than "remove" information, I think the proposal is to ensure that it can function meaningfully using a small subset of the objects. I'd like to hear from Juergen (and others) regarding the details of the proposed compliance material, especially with regard to whether there are any details in the current object definitions that would prevent this usage. Randy From disman-admin@ietf.org Fri Mar 12 12:36:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05642 for ; Fri, 12 Mar 2004 12:36:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qZm-0000N5-Bq; Fri, 12 Mar 2004 12:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qZi-0000MS-Ea for disman@optimus.ietf.org; Fri, 12 Mar 2004 12:35:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05602 for ; Fri, 12 Mar 2004 12:35:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1qZg-0007hD-00 for disman@ietf.org; Fri, 12 Mar 2004 12:35:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1qYj-0007XU-00 for disman@ietf.org; Fri, 12 Mar 2004 12:34:58 -0500 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1B1qYB-0007Oc-00 for disman@ietf.org; Fri, 12 Mar 2004 12:34:23 -0500 Received: from h-68-164-89-72.snvacaid.dynamic.covad.net ([68.164.89.72] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1B1qY7-0005Fw-00 for disman@ietf.org; Fri, 12 Mar 2004 09:34:19 -0800 Message-ID: <002001c40858$8d393f60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Disman] Fw: ID Nits Reminder Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 09:36:28 -0800 Hi - fwd fyi Randy > From: "IETF Secretariat" > To: > Cc: > Sent: Friday, March 12, 2004 8:52 AM > Subject: ID Nits Reminder > > Dear Working Group Chairs: > > In the course of your efforts, you will be submitting Internet-Drafts to the IESG > for consideration as RFCs. Please note that all Internet-Drafts offered for publication > as RFCs must conform to the requirements specified in ID Nits > (http://www.ietf.org/ID-nits.html), or they will be returned to the author(s) for > revision. Therefore, the IETF Secretariat strongly recommends that you address all of the > issues raised in this document before submitting a request to publish an Internet-Draft > to the IESG. The content issues should be addressed early on in the work since they are > integral to the technical makeup of the Internet-Draft. > > Thank you in advance for your cooperation. > > The IETF Secretariat. > > > From exim@www1.ietf.org Fri Mar 12 12:55:13 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07556 for ; Fri, 12 Mar 2004 12:55:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qru-000284-Ey for disman-archive@odin.ietf.org; Fri, 12 Mar 2004 12:54:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CHskjp008183 for disman-archive@odin.ietf.org; Fri, 12 Mar 2004 12:54:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qru-00027u-Ba for disman-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 12:54:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07506 for ; Fri, 12 Mar 2004 12:54:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1qrs-0003KA-00 for disman-web-archive@ietf.org; Fri, 12 Mar 2004 12:54:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1qqu-000334-00 for disman-web-archive@ietf.org; Fri, 12 Mar 2004 12:53:45 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1qpE-0002fc-00 for disman-web-archive@ietf.org; Fri, 12 Mar 2004 12:52:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1qZr-0004SK-HT for disman-web-archive@ietf.org; Fri, 12 Mar 2004 12:36:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qZm-0000N5-Bq; Fri, 12 Mar 2004 12:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1qZi-0000MS-Ea for disman@optimus.ietf.org; Fri, 12 Mar 2004 12:35:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05602 for ; Fri, 12 Mar 2004 12:35:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1qZg-0007hD-00 for disman@ietf.org; Fri, 12 Mar 2004 12:35:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1qYj-0007XU-00 for disman@ietf.org; Fri, 12 Mar 2004 12:34:58 -0500 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1B1qYB-0007Oc-00 for disman@ietf.org; Fri, 12 Mar 2004 12:34:23 -0500 Received: from h-68-164-89-72.snvacaid.dynamic.covad.net ([68.164.89.72] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1B1qY7-0005Fw-00 for disman@ietf.org; Fri, 12 Mar 2004 09:34:19 -0800 Message-ID: <002001c40858$8d393f60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Fw: ID Nits Reminder Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 09:36:28 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi - fwd fyi Randy > From: "IETF Secretariat" > To: > Cc: > Sent: Friday, March 12, 2004 8:52 AM > Subject: ID Nits Reminder > > Dear Working Group Chairs: > > In the course of your efforts, you will be submitting Internet-Drafts to the IESG > for consideration as RFCs. Please note that all Internet-Drafts offered for publication > as RFCs must conform to the requirements specified in ID Nits > (http://www.ietf.org/ID-nits.html), or they will be returned to the author(s) for > revision. Therefore, the IETF Secretariat strongly recommends that you address all of the > issues raised in this document before submitting a request to publish an Internet-Draft > to the IESG. The content issues should be addressed early on in the work since they are > integral to the technical makeup of the Internet-Draft. > > Thank you in advance for your cooperation. > > The IETF Secretariat. > > > From disman-admin@ietf.org Fri Mar 12 14:26:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12806 for ; Fri, 12 Mar 2004 14:26:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1sID-0001g3-Nh; Fri, 12 Mar 2004 14:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1sHw-0001fM-D9 for disman@optimus.ietf.org; Fri, 12 Mar 2004 14:25:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12784 for ; Fri, 12 Mar 2004 14:25:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1sHt-00009U-00 for disman@ietf.org; Fri, 12 Mar 2004 14:25:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1sH0-00002a-00 for disman@ietf.org; Fri, 12 Mar 2004 14:24:46 -0500 Received: from falcon.mail.pas.earthlink.net ([207.217.120.74]) by ietf-mx with esmtp (Exim 4.12) id 1B1sGF-0007je-00 for disman@ietf.org; Fri, 12 Mar 2004 14:23:59 -0500 Received: from h-68-164-89-72.snvacaid.dynamic.covad.net ([68.164.89.72] helo=oemcomputer) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1B1sGC-0005C4-00 for disman@ietf.org; Fri, 12 Mar 2004 11:23:56 -0800 Message-ID: <001601c40867$dd9500c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Disman] Fw: Core Services Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 11:26:06 -0800 Hi - Some implicit criticism of the Event MIB.... Randy > From: "Andy Bierman" > To: "Netconf Data Model Discussion" > Sent: Friday, March 12, 2004 10:44 AM > Subject: Core Services > > Hi, > > Since we are starting fresh with standard XSDs for NM in the IETF, > we have a chance to reflect on past experience and try to get > it better the 2nd time around. One of the things to get right > is the design of core services. (E.g., many MIBs have their > own ad-hoc threshold, or other event, monitoring feature > because there is no simple to use core Event Management service > to use.) > > We need to select and design the core services for a > NETCONF-manageable network device. > > > Andy ... From exim@www1.ietf.org Fri Mar 12 14:37:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13588 for ; Fri, 12 Mar 2004 14:37:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1sTE-0002Zq-CL for disman-archive@odin.ietf.org; Fri, 12 Mar 2004 14:37:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CJbOcE009898 for disman-archive@odin.ietf.org; Fri, 12 Mar 2004 14:37:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1sTD-0002ZZ-Ul for disman-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 14:37:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13469 for ; Fri, 12 Mar 2004 14:37:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1sTB-0001qT-00 for disman-web-archive@ietf.org; Fri, 12 Mar 2004 14:37:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1sRR-0001NY-00 for disman-web-archive@ietf.org; Fri, 12 Mar 2004 14:35:34 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1sQS-00018X-00 for disman-web-archive@ietf.org; Fri, 12 Mar 2004 14:34:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1sIE-0006Ev-Ee for disman-web-archive@ietf.org; Fri, 12 Mar 2004 14:26:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1sID-0001g3-Nh; Fri, 12 Mar 2004 14:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1sHw-0001fM-D9 for disman@optimus.ietf.org; Fri, 12 Mar 2004 14:25:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12784 for ; Fri, 12 Mar 2004 14:25:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1sHt-00009U-00 for disman@ietf.org; Fri, 12 Mar 2004 14:25:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1sH0-00002a-00 for disman@ietf.org; Fri, 12 Mar 2004 14:24:46 -0500 Received: from falcon.mail.pas.earthlink.net ([207.217.120.74]) by ietf-mx with esmtp (Exim 4.12) id 1B1sGF-0007je-00 for disman@ietf.org; Fri, 12 Mar 2004 14:23:59 -0500 Received: from h-68-164-89-72.snvacaid.dynamic.covad.net ([68.164.89.72] helo=oemcomputer) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1B1sGC-0005C4-00 for disman@ietf.org; Fri, 12 Mar 2004 11:23:56 -0800 Message-ID: <001601c40867$dd9500c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Fw: Core Services Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 12 Mar 2004 11:26:06 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi - Some implicit criticism of the Event MIB.... Randy > From: "Andy Bierman" > To: "Netconf Data Model Discussion" > Sent: Friday, March 12, 2004 10:44 AM > Subject: Core Services > > Hi, > > Since we are starting fresh with standard XSDs for NM in the IETF, > we have a chance to reflect on past experience and try to get > it better the 2nd time around. One of the things to get right > is the design of core services. (E.g., many MIBs have their > own ad-hoc threshold, or other event, monitoring feature > because there is no simple to use core Event Management service > to use.) > > We need to select and design the core services for a > NETCONF-manageable network device. > > > Andy ... From disman-admin@ietf.org Tue Mar 16 10:33:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06621 for ; Tue, 16 Mar 2004 10:33:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3GYu-0000Cy-O2; Tue, 16 Mar 2004 10:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3GYG-00007d-Oa for disman@optimus.ietf.org; Tue, 16 Mar 2004 10:32:20 -0500 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06570 for ; Tue, 16 Mar 2004 10:32:16 -0500 (EST) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1B3GXm-0008V1-B0; Tue, 16 Mar 2004 10:31:50 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Subject: [Disman] Protocol Action: 'Alarm MIB' to Proposed Standard Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 10:31:50 -0500 The IESG has approved the following document: - 'Alarm MIB ' as a Proposed Standard This document is the product of the Distributed Management Working Group. The IESG contact persons are Bert Wijnen and David Kessens. Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes management objects used for modelling and storing alarms. Working Group Summary The Working Group has (rough) consensus to publish this document as a Proposed Standard. There was some discussion on the consistentcy of terminology as used in IETF and other organizations. The current result is acceptable and usable. The ITU-T SG 4 was also alerted (via a Liaison statement) about this work and they have no objection to this document being published. Protocol Quality Bert Wijnen has reviewed this document for the IESG. RFC-Editor note: RFC Editor instructions - Please change MODULE names to conform to MIB guidelines on page 37 pls fix: OLD: IANA-ITU-ALARM-TC DEFINITIONS ::= BEGIN NEW: IANA-ITU-ALARM-TC-MIB DEFINITIONS ::= BEGIN on page 44 pls fix: OLD: ITU-ALARM-TC DEFINITIONS ::= BEGIN NEW: ITU-ALARM-TC-MIB DEFINITIONS ::= BEGIN on page 46 pls fix: OLD: ItuTrendIndication FROM ITU-ALARM-TC NEW: ItuTrendIndication FROM ITU-ALARM-TC-MIB on page 46 pls fix: OLD: IANAItuEventType FROM IANA-ITU-ALARM-TC NEW: IANAItuEventType FROM IANA-ITU-ALARM-TC-MIB From exim@www1.ietf.org Tue Mar 16 10:35:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06824 for ; Tue, 16 Mar 2004 10:35:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Gam-0000Kg-Uz for disman-archive@odin.ietf.org; Tue, 16 Mar 2004 10:34:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GFYutk001277 for disman-archive@odin.ietf.org; Tue, 16 Mar 2004 10:34:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Gam-0000KW-BV for disman-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 10:34:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06743 for ; Tue, 16 Mar 2004 10:34:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Gaj-0005sD-00 for disman-web-archive@ietf.org; Tue, 16 Mar 2004 10:34:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3GZq-0005lk-00 for disman-web-archive@ietf.org; Tue, 16 Mar 2004 10:33:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3GYu-0005fZ-00 for disman-web-archive@ietf.org; Tue, 16 Mar 2004 10:33:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3GYu-0000Cy-O2; Tue, 16 Mar 2004 10:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3GYG-00007d-Oa for disman@optimus.ietf.org; Tue, 16 Mar 2004 10:32:20 -0500 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06570 for ; Tue, 16 Mar 2004 10:32:16 -0500 (EST) Received: from nobody by optimus.ietf.org with local (Exim 4.20) id 1B3GXm-0008V1-B0; Tue, 16 Mar 2004 10:31:50 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Subject: [Disman] Protocol Action: 'Alarm MIB' to Proposed Standard Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 10:31:50 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,UPPERCASE_25_50 autolearn=no version=2.60 The IESG has approved the following document: - 'Alarm MIB ' as a Proposed Standard This document is the product of the Distributed Management Working Group. The IESG contact persons are Bert Wijnen and David Kessens. Technical Summary This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes management objects used for modelling and storing alarms. Working Group Summary The Working Group has (rough) consensus to publish this document as a Proposed Standard. There was some discussion on the consistentcy of terminology as used in IETF and other organizations. The current result is acceptable and usable. The ITU-T SG 4 was also alerted (via a Liaison statement) about this work and they have no objection to this document being published. Protocol Quality Bert Wijnen has reviewed this document for the IESG. RFC-Editor note: RFC Editor instructions - Please change MODULE names to conform to MIB guidelines on page 37 pls fix: OLD: IANA-ITU-ALARM-TC DEFINITIONS ::= BEGIN NEW: IANA-ITU-ALARM-TC-MIB DEFINITIONS ::= BEGIN on page 44 pls fix: OLD: ITU-ALARM-TC DEFINITIONS ::= BEGIN NEW: ITU-ALARM-TC-MIB DEFINITIONS ::= BEGIN on page 46 pls fix: OLD: ItuTrendIndication FROM ITU-ALARM-TC NEW: ItuTrendIndication FROM ITU-ALARM-TC-MIB on page 46 pls fix: OLD: IANAItuEventType FROM IANA-ITU-ALARM-TC NEW: IANAItuEventType FROM IANA-ITU-ALARM-TC-MIB From disman-admin@ietf.org Tue Mar 16 12:52:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13767 for ; Tue, 16 Mar 2004 12:52:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3IjS-0004yx-4c; Tue, 16 Mar 2004 12:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Iif-0004vw-Cm for disman@optimus.ietf.org; Tue, 16 Mar 2004 12:51:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13604 for ; Tue, 16 Mar 2004 12:51:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Iid-0004QP-00 for disman@ietf.org; Tue, 16 Mar 2004 12:51:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3IhY-0004Ew-00 for disman@ietf.org; Tue, 16 Mar 2004 12:50:04 -0500 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1B3Igj-00043H-00 for disman@ietf.org; Tue, 16 Mar 2004 12:49:13 -0500 Received: from h-68-164-91-145.snvacaid.dynamic.covad.net ([68.164.91.145] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1B3Igi-0004tK-00 for disman@ietf.org; Tue, 16 Mar 2004 09:49:12 -0800 Message-ID: <002b01c40b7f$50fe1f00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Disman] Protocol Action: 'Alarm MIB' to Proposed Standard X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 09:51:31 -0800 Hi - Congratulations and a big THANK YOU to everyone who put in the blood, sweat, and tears to finish this work! Special thanks go to Sharon and Dan for championing this work and taking on the editing. Randy disman WG chair > From: "The IESG" > To: > Cc: "Internet Architecture Board" ; "RFC Editor" ; > Sent: Tuesday, March 16, 2004 7:31 AM > Subject: [Disman] Protocol Action: 'Alarm MIB' to Proposed Standard > > The IESG has approved the following document: > > - 'Alarm MIB ' > as a Proposed Standard > > This document is the product of the Distributed Management Working Group. > > The IESG contact persons are Bert Wijnen and David Kessens. > > > Technical Summary > > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes management objects used for modelling > and storing alarms. > > Working Group Summary > > The Working Group has (rough) consensus to publish this document as > a Proposed Standard. There was some discussion on the consistentcy of > terminology as used in IETF and other organizations. The current > result is acceptable and usable. The ITU-T SG 4 was also alerted > (via a Liaison statement) about this work and they have no objection > to this document being published. > > Protocol Quality > > Bert Wijnen has reviewed this document for the IESG. > > RFC-Editor note: > > RFC Editor instructions > > - Please change MODULE names to conform to MIB guidelines > > on page 37 pls fix: > OLD: > IANA-ITU-ALARM-TC DEFINITIONS ::= BEGIN > NEW: > IANA-ITU-ALARM-TC-MIB DEFINITIONS ::= BEGIN > > on page 44 pls fix: > OLD: > ITU-ALARM-TC DEFINITIONS ::= BEGIN > NEW: > ITU-ALARM-TC-MIB DEFINITIONS ::= BEGIN > > on page 46 pls fix: > OLD: > ItuTrendIndication FROM ITU-ALARM-TC > NEW: > ItuTrendIndication FROM ITU-ALARM-TC-MIB > > on page 46 pls fix: > OLD: > IANAItuEventType FROM IANA-ITU-ALARM-TC > NEW: > IANAItuEventType FROM IANA-ITU-ALARM-TC-MIB > > From exim@www1.ietf.org Tue Mar 16 12:54:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13858 for ; Tue, 16 Mar 2004 12:54:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3IlE-0005AV-Np for disman-archive@odin.ietf.org; Tue, 16 Mar 2004 12:53:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GHrqdF019861 for disman-archive@odin.ietf.org; Tue, 16 Mar 2004 12:53:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3IlE-0005AG-G1 for disman-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 12:53:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13849 for ; Tue, 16 Mar 2004 12:53:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3IlC-0004mp-00 for disman-web-archive@ietf.org; Tue, 16 Mar 2004 12:53:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3IkN-0004id-00 for disman-web-archive@ietf.org; Tue, 16 Mar 2004 12:53:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3IjX-0004b0-00 for disman-web-archive@ietf.org; Tue, 16 Mar 2004 12:52:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3IjS-0004yx-4c; Tue, 16 Mar 2004 12:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Iif-0004vw-Cm for disman@optimus.ietf.org; Tue, 16 Mar 2004 12:51:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13604 for ; Tue, 16 Mar 2004 12:51:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Iid-0004QP-00 for disman@ietf.org; Tue, 16 Mar 2004 12:51:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3IhY-0004Ew-00 for disman@ietf.org; Tue, 16 Mar 2004 12:50:04 -0500 Received: from scaup.mail.pas.earthlink.net ([207.217.120.49]) by ietf-mx with esmtp (Exim 4.12) id 1B3Igj-00043H-00 for disman@ietf.org; Tue, 16 Mar 2004 12:49:13 -0500 Received: from h-68-164-91-145.snvacaid.dynamic.covad.net ([68.164.91.145] helo=oemcomputer) by scaup.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1B3Igi-0004tK-00 for disman@ietf.org; Tue, 16 Mar 2004 09:49:12 -0800 Message-ID: <002b01c40b7f$50fe1f00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Disman] Protocol Action: 'Alarm MIB' to Proposed Standard X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 09:51:31 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi - Congratulations and a big THANK YOU to everyone who put in the blood, sweat, and tears to finish this work! Special thanks go to Sharon and Dan for championing this work and taking on the editing. Randy disman WG chair > From: "The IESG" > To: > Cc: "Internet Architecture Board" ; "RFC Editor" ; > Sent: Tuesday, March 16, 2004 7:31 AM > Subject: [Disman] Protocol Action: 'Alarm MIB' to Proposed Standard > > The IESG has approved the following document: > > - 'Alarm MIB ' > as a Proposed Standard > > This document is the product of the Distributed Management Working Group. > > The IESG contact persons are Bert Wijnen and David Kessens. > > > Technical Summary > > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes management objects used for modelling > and storing alarms. > > Working Group Summary > > The Working Group has (rough) consensus to publish this document as > a Proposed Standard. There was some discussion on the consistentcy of > terminology as used in IETF and other organizations. The current > result is acceptable and usable. The ITU-T SG 4 was also alerted > (via a Liaison statement) about this work and they have no objection > to this document being published. > > Protocol Quality > > Bert Wijnen has reviewed this document for the IESG. > > RFC-Editor note: > > RFC Editor instructions > > - Please change MODULE names to conform to MIB guidelines > > on page 37 pls fix: > OLD: > IANA-ITU-ALARM-TC DEFINITIONS ::= BEGIN > NEW: > IANA-ITU-ALARM-TC-MIB DEFINITIONS ::= BEGIN > > on page 44 pls fix: > OLD: > ITU-ALARM-TC DEFINITIONS ::= BEGIN > NEW: > ITU-ALARM-TC-MIB DEFINITIONS ::= BEGIN > > on page 46 pls fix: > OLD: > ItuTrendIndication FROM ITU-ALARM-TC > NEW: > ItuTrendIndication FROM ITU-ALARM-TC-MIB > > on page 46 pls fix: > OLD: > IANAItuEventType FROM IANA-ITU-ALARM-TC > NEW: > IANAItuEventType FROM IANA-ITU-ALARM-TC-MIB > > From disman-admin@ietf.org Tue Mar 16 13:16:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14757 for ; Tue, 16 Mar 2004 13:16:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3J6g-0006UT-5G; Tue, 16 Mar 2004 13:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3J6a-0006TU-Uf for disman@optimus.ietf.org; Tue, 16 Mar 2004 13:15:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14697 for ; Tue, 16 Mar 2004 13:15:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3J6Z-0006eC-00 for disman@ietf.org; Tue, 16 Mar 2004 13:15:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3J5j-0006Yj-00 for disman@ietf.org; Tue, 16 Mar 2004 13:15:04 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1B3J4p-0006Ly-00 for disman@ietf.org; Tue, 16 Mar 2004 13:14:07 -0500 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2GIDYc26838 for ; Tue, 16 Mar 2004 12:13:35 -0600 (CST) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2657.72) id <15RZF4VB>; Tue, 16 Mar 2004 13:13:34 -0500 Message-ID: From: "Lam, Hing-Kam (Kam)" To: "'Randy Presuhn'" , disman@ietf.org Subject: RE: [Disman] Protocol Action: 'Alarm MIB' to Proposed Standard MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 13:13:33 -0500 Randy, I assume the 'ARC MIB' now can move forward, as it is pending on the approval of the 'Alarm MIB'. Regards, Kam > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Tuesday, March 16, 2004 12:52 PM > To: disman@ietf.org > Subject: Re: [Disman] Protocol Action: 'Alarm MIB' to > Proposed Standard > > > Hi - > > Congratulations and a big THANK YOU to everyone who put in the > blood, sweat, and tears to finish this work! Special thanks go to > Sharon and Dan for championing this work and taking on the editing. > > Randy > disman WG chair > > > From: "The IESG" > > To: > > Cc: "Internet Architecture Board" ; "RFC > Editor" ; > > Sent: Tuesday, March 16, 2004 7:31 AM > > Subject: [Disman] Protocol Action: 'Alarm MIB' to Proposed Standard > > > > > The IESG has approved the following document: > > > > - 'Alarm MIB ' > > as a Proposed Standard > > > > This document is the product of the Distributed Management > Working Group. > > > > The IESG contact persons are Bert Wijnen and David Kessens. > > > > > > Technical Summary > > > > This memo defines a portion of the Management Information > Base (MIB) > > for use with network management protocols in the Internet > community. > > In particular, it describes management objects used for modelling > > and storing alarms. > > > > Working Group Summary > > > > The Working Group has (rough) consensus to publish this > document as > > a Proposed Standard. There was some discussion on the > consistentcy of > > terminology as used in IETF and other organizations. The current > > result is acceptable and usable. The ITU-T SG 4 was also alerted > > (via a Liaison statement) about this work and they have > no objection > > to this document being published. > > > > Protocol Quality > > > > Bert Wijnen has reviewed this document for the IESG. > > > > RFC-Editor note: > > > > RFC Editor instructions > > > > - Please change MODULE names to conform to MIB guidelines > > > > on page 37 pls fix: > > OLD: > > IANA-ITU-ALARM-TC DEFINITIONS ::= BEGIN > > NEW: > > IANA-ITU-ALARM-TC-MIB DEFINITIONS ::= BEGIN > > > > on page 44 pls fix: > > OLD: > > ITU-ALARM-TC DEFINITIONS ::= BEGIN > > NEW: > > ITU-ALARM-TC-MIB DEFINITIONS ::= BEGIN > > > > on page 46 pls fix: > > OLD: > > ItuTrendIndication FROM ITU-ALARM-TC > > NEW: > > ItuTrendIndication FROM ITU-ALARM-TC-MIB > > > > on page 46 pls fix: > > OLD: > > IANAItuEventType FROM IANA-ITU-ALARM-TC > > NEW: > > IANAItuEventType FROM IANA-ITU-ALARM-TC-MIB > > > > > > > From exim@www1.ietf.org Tue Mar 16 13:18:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14942 for ; Tue, 16 Mar 2004 13:18:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3J8O-0006eb-Gm for disman-archive@odin.ietf.org; Tue, 16 Mar 2004 13:17:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GIHmgB025573 for disman-archive@odin.ietf.org; Tue, 16 Mar 2004 13:17:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3J8O-0006eO-Ce for disman-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 13:17:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14921 for ; Tue, 16 Mar 2004 13:17:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3J8M-0006of-00 for disman-web-archive@ietf.org; Tue, 16 Mar 2004 13:17:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3J7T-0006kD-00 for disman-web-archive@ietf.org; Tue, 16 Mar 2004 13:16:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3J6f-0006f9-00 for disman-web-archive@ietf.org; Tue, 16 Mar 2004 13:16:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3J6g-0006UT-5G; Tue, 16 Mar 2004 13:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3J6a-0006TU-Uf for disman@optimus.ietf.org; Tue, 16 Mar 2004 13:15:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14697 for ; Tue, 16 Mar 2004 13:15:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3J6Z-0006eC-00 for disman@ietf.org; Tue, 16 Mar 2004 13:15:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3J5j-0006Yj-00 for disman@ietf.org; Tue, 16 Mar 2004 13:15:04 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1B3J4p-0006Ly-00 for disman@ietf.org; Tue, 16 Mar 2004 13:14:07 -0500 Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com [135.17.42.36]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2GIDYc26838 for ; Tue, 16 Mar 2004 12:13:35 -0600 (CST) Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service (5.5.2657.72) id <15RZF4VB>; Tue, 16 Mar 2004 13:13:34 -0500 Message-ID: From: "Lam, Hing-Kam (Kam)" To: "'Randy Presuhn'" , disman@ietf.org Subject: RE: [Disman] Protocol Action: 'Alarm MIB' to Proposed Standard MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 13:13:33 -0500 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Randy, I assume the 'ARC MIB' now can move forward, as it is pending on the approval of the 'Alarm MIB'. Regards, Kam > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Tuesday, March 16, 2004 12:52 PM > To: disman@ietf.org > Subject: Re: [Disman] Protocol Action: 'Alarm MIB' to > Proposed Standard > > > Hi - > > Congratulations and a big THANK YOU to everyone who put in the > blood, sweat, and tears to finish this work! Special thanks go to > Sharon and Dan for championing this work and taking on the editing. > > Randy > disman WG chair > > > From: "The IESG" > > To: > > Cc: "Internet Architecture Board" ; "RFC > Editor" ; > > Sent: Tuesday, March 16, 2004 7:31 AM > > Subject: [Disman] Protocol Action: 'Alarm MIB' to Proposed Standard > > > > > The IESG has approved the following document: > > > > - 'Alarm MIB ' > > as a Proposed Standard > > > > This document is the product of the Distributed Management > Working Group. > > > > The IESG contact persons are Bert Wijnen and David Kessens. > > > > > > Technical Summary > > > > This memo defines a portion of the Management Information > Base (MIB) > > for use with network management protocols in the Internet > community. > > In particular, it describes management objects used for modelling > > and storing alarms. > > > > Working Group Summary > > > > The Working Group has (rough) consensus to publish this > document as > > a Proposed Standard. There was some discussion on the > consistentcy of > > terminology as used in IETF and other organizations. The current > > result is acceptable and usable. The ITU-T SG 4 was also alerted > > (via a Liaison statement) about this work and they have > no objection > > to this document being published. > > > > Protocol Quality > > > > Bert Wijnen has reviewed this document for the IESG. > > > > RFC-Editor note: > > > > RFC Editor instructions > > > > - Please change MODULE names to conform to MIB guidelines > > > > on page 37 pls fix: > > OLD: > > IANA-ITU-ALARM-TC DEFINITIONS ::= BEGIN > > NEW: > > IANA-ITU-ALARM-TC-MIB DEFINITIONS ::= BEGIN > > > > on page 44 pls fix: > > OLD: > > ITU-ALARM-TC DEFINITIONS ::= BEGIN > > NEW: > > ITU-ALARM-TC-MIB DEFINITIONS ::= BEGIN > > > > on page 46 pls fix: > > OLD: > > ItuTrendIndication FROM ITU-ALARM-TC > > NEW: > > ItuTrendIndication FROM ITU-ALARM-TC-MIB > > > > on page 46 pls fix: > > OLD: > > IANAItuEventType FROM IANA-ITU-ALARM-TC > > NEW: > > IANAItuEventType FROM IANA-ITU-ALARM-TC-MIB > > > > > > > From disman-admin@ietf.org Tue Mar 16 14:22:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19412 for ; Tue, 16 Mar 2004 14:22:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3K8W-0003J3-Mr; Tue, 16 Mar 2004 14:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3K7v-0003IO-Vp for disman@optimus.ietf.org; Tue, 16 Mar 2004 14:21:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19390 for ; Tue, 16 Mar 2004 14:21:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3K7t-0006rB-00 for disman@ietf.org; Tue, 16 Mar 2004 14:21:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3K7B-0006jc-00 for disman@ietf.org; Tue, 16 Mar 2004 14:20:37 -0500 Received: from cardinal.mail.pas.earthlink.net ([207.217.121.226]) by ietf-mx with esmtp (Exim 4.12) id 1B3K6F-0006Yu-00 for disman@ietf.org; Tue, 16 Mar 2004 14:19:40 -0500 Received: from h-68-164-153-158.snvacaid.dynamic.covad.net ([68.164.153.158] helo=oemcomputer) by cardinal.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1B3K62-0003Pe-00 for disman@ietf.org; Tue, 16 Mar 2004 11:19:26 -0800 Message-ID: <000601c40b8b$f3a73dc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Disman] Protocol Action: 'Alarm MIB' to Proposed Standard X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 11:21:58 -0800 Hi - > From: "Lam, Hing-Kam (Kam)" > To: "'Randy Presuhn'" ; > Sent: Tuesday, March 16, 2004 10:13 AM > Subject: RE: [Disman] Protocol Action: 'Alarm MIB' to Proposed Standard ... > I assume the 'ARC MIB' now can move forward, as it is pending on the approval of the 'Alarm MIB'. ... The ARC MIB was already in the RFC editor queue, and this was the only pending reference, so it's just a matter of time now before you get to AUTH48. Randy From exim@www1.ietf.org Tue Mar 16 14:24:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19515 for ; Tue, 16 Mar 2004 14:24:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3KAK-0003Q0-RT for disman-archive@odin.ietf.org; Tue, 16 Mar 2004 14:23:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2GJNqvH013134 for disman-archive@odin.ietf.org; Tue, 16 Mar 2004 14:23:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3KAK-0003Pl-KN for disman-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 14:23:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19492 for ; Tue, 16 Mar 2004 14:23:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3KAH-00078j-00 for disman-web-archive@ietf.org; Tue, 16 Mar 2004 14:23:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3K9N-000736-00 for disman-web-archive@ietf.org; Tue, 16 Mar 2004 14:22:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3K8X-0006wM-00 for disman-web-archive@ietf.org; Tue, 16 Mar 2004 14:22:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3K8W-0003J3-Mr; Tue, 16 Mar 2004 14:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3K7v-0003IO-Vp for disman@optimus.ietf.org; Tue, 16 Mar 2004 14:21:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19390 for ; Tue, 16 Mar 2004 14:21:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3K7t-0006rB-00 for disman@ietf.org; Tue, 16 Mar 2004 14:21:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3K7B-0006jc-00 for disman@ietf.org; Tue, 16 Mar 2004 14:20:37 -0500 Received: from cardinal.mail.pas.earthlink.net ([207.217.121.226]) by ietf-mx with esmtp (Exim 4.12) id 1B3K6F-0006Yu-00 for disman@ietf.org; Tue, 16 Mar 2004 14:19:40 -0500 Received: from h-68-164-153-158.snvacaid.dynamic.covad.net ([68.164.153.158] helo=oemcomputer) by cardinal.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1B3K62-0003Pe-00 for disman@ietf.org; Tue, 16 Mar 2004 11:19:26 -0800 Message-ID: <000601c40b8b$f3a73dc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Disman] Protocol Action: 'Alarm MIB' to Proposed Standard X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 16 Mar 2004 11:21:58 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi - > From: "Lam, Hing-Kam (Kam)" > To: "'Randy Presuhn'" ; > Sent: Tuesday, March 16, 2004 10:13 AM > Subject: RE: [Disman] Protocol Action: 'Alarm MIB' to Proposed Standard ... > I assume the 'ARC MIB' now can move forward, as it is pending on the approval of the 'Alarm MIB'. ... The ARC MIB was already in the RFC editor queue, and this was the only pending reference, so it's just a matter of time now before you get to AUTH48. Randy From disman-admin@ietf.org Wed Mar 17 13:55:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29247 for ; Wed, 17 Mar 2004 13:55:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3gBy-00083t-5Q; Wed, 17 Mar 2004 13:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3gBf-000837-5A for disman@optimus.ietf.org; Wed, 17 Mar 2004 13:54:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29169 for ; Wed, 17 Mar 2004 13:54:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3gBc-0006VC-00 for disman@ietf.org; Wed, 17 Mar 2004 13:54:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3gAh-0006LQ-00 for disman@ietf.org; Wed, 17 Mar 2004 13:53:44 -0500 Received: from turkey.mail.pas.earthlink.net ([207.217.120.126]) by ietf-mx with esmtp (Exim 4.12) id 1B3g9m-0006A4-00 for disman@ietf.org; Wed, 17 Mar 2004 13:52:46 -0500 Received: from h-68-164-156-169.snvacaid.dynamic.covad.net ([68.164.156.169] helo=oemcomputer) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1B3g9d-0005pm-00 for disman@ietf.org; Wed, 17 Mar 2004 10:52:37 -0800 Message-ID: <001a01c40c51$58b72b60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Subject: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Mar 2004 10:54:58 -0800 Hi - I'd welcome discussion of this on the disman mailing list. I think it's relevant to the question of what to do about the expression and event MIBs. Randy > From: > To: > Sent: Wednesday, March 17, 2004 8:10 AM > Subject: I-D ACTION:draft-yadawad-disman-ahcf-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Advanced History Collection Framework > Author(s) : S. Yadawad, H. Kumar, H. Yamijala, R. Shekar > Filename : draft-yadawad-disman-ahcf-00.txt > Pages : 47 > Date : 2004-3-17 > > This draft defines a portion of the Management Information Base for > use with network management protocols in TCP/IP based Internets. In > particular, it defines objects for configuring and controlling the > history collection of user specified Data, which is an ASN.1 > INTEGER based object. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-yadawad-disman-ahcf-00.txt > ... From exim@www1.ietf.org Wed Mar 17 13:57:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29343 for ; Wed, 17 Mar 2004 13:57:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3gDp-0008Jb-1M for disman-archive@odin.ietf.org; Wed, 17 Mar 2004 13:56:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HIuv5C031962 for disman-archive@odin.ietf.org; Wed, 17 Mar 2004 13:56:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3gDo-0008JR-U7 for disman-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 13:56:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29339 for ; Wed, 17 Mar 2004 13:56:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3gDm-0006rg-00 for disman-web-archive@ietf.org; Wed, 17 Mar 2004 13:56:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3gCz-0006jI-00 for disman-web-archive@ietf.org; Wed, 17 Mar 2004 13:56:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3gCA-0006aQ-00 for disman-web-archive@ietf.org; Wed, 17 Mar 2004 13:55:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3gBy-00083t-5Q; Wed, 17 Mar 2004 13:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3gBf-000837-5A for disman@optimus.ietf.org; Wed, 17 Mar 2004 13:54:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29169 for ; Wed, 17 Mar 2004 13:54:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3gBc-0006VC-00 for disman@ietf.org; Wed, 17 Mar 2004 13:54:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3gAh-0006LQ-00 for disman@ietf.org; Wed, 17 Mar 2004 13:53:44 -0500 Received: from turkey.mail.pas.earthlink.net ([207.217.120.126]) by ietf-mx with esmtp (Exim 4.12) id 1B3g9m-0006A4-00 for disman@ietf.org; Wed, 17 Mar 2004 13:52:46 -0500 Received: from h-68-164-156-169.snvacaid.dynamic.covad.net ([68.164.156.169] helo=oemcomputer) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1B3g9d-0005pm-00 for disman@ietf.org; Wed, 17 Mar 2004 10:52:37 -0800 Message-ID: <001a01c40c51$58b72b60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Mar 2004 10:54:58 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi - I'd welcome discussion of this on the disman mailing list. I think it's relevant to the question of what to do about the expression and event MIBs. Randy > From: > To: > Sent: Wednesday, March 17, 2004 8:10 AM > Subject: I-D ACTION:draft-yadawad-disman-ahcf-00.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Advanced History Collection Framework > Author(s) : S. Yadawad, H. Kumar, H. Yamijala, R. Shekar > Filename : draft-yadawad-disman-ahcf-00.txt > Pages : 47 > Date : 2004-3-17 > > This draft defines a portion of the Management Information Base for > use with network management protocols in TCP/IP based Internets. In > particular, it defines objects for configuring and controlling the > history collection of user specified Data, which is an ASN.1 > INTEGER based object. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-yadawad-disman-ahcf-00.txt > ... From disman-admin@ietf.org Wed Mar 17 14:21:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00691 for ; Wed, 17 Mar 2004 14:21:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3gb7-0001Sq-7L; Wed, 17 Mar 2004 14:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3gat-0001QJ-TF for disman@optimus.ietf.org; Wed, 17 Mar 2004 14:20:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00667 for ; Wed, 17 Mar 2004 14:20:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3gar-0002Q1-00 for disman@ietf.org; Wed, 17 Mar 2004 14:20:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3gZu-0002J6-00 for disman@ietf.org; Wed, 17 Mar 2004 14:19:46 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1B3gZD-0002CB-00 for disman@ietf.org; Wed, 17 Mar 2004 14:19:03 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2HJI1gL009989 for ; Wed, 17 Mar 2004 14:18:01 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2HJHxgL009936 for ; Wed, 17 Mar 2004 14:17:59 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Message-ID: Thread-Topic: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Thread-Index: AcQMUZT/FmmzFaS6ROus766PkxI54wAAljwQ From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , "Disman (E-mail)" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Mar 2004 21:18:59 +0200 Content-Transfer-Encoding: quoted-printable I will repeat a comment that I made during the meeting in Seoul. I think = that all, or almost all that is being defined in this MIB module can = already be performed - some features even in multiple ways - by agents = that implement existing MIB modules like RMON, Events MIB, and Alarm = MIB. I think that it would help the discussion if the authors could = shortly describe what is the added value that this MIB module would = bring, and what operations/management functions this MIB module provides = that are not covered by existing MIB modules. =20 Thanks and Regards, Dan > -----Original Message----- > From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On=20 > Behalf Of Randy Presuhn > Sent: 17 March, 2004 8:55 PM > To: Disman (E-mail) > Subject: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt >=20 >=20 > Hi - >=20 > I'd welcome discussion of this on the disman mailing list. > I think it's relevant to the question of what to do about the > expression and event MIBs. >=20 > Randy >=20 > > From: > > To: > > Sent: Wednesday, March 17, 2004 8:10 AM > > Subject: I-D ACTION:draft-yadawad-disman-ahcf-00.txt > > >=20 > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > > > > > > Title : Advanced History Collection Framework > > Author(s) : S. Yadawad, H. Kumar, H. Yamijala, R. Shekar > > Filename : draft-yadawad-disman-ahcf-00.txt > > Pages : 47 > > Date : 2004-3-17 > > > > This draft defines a portion of the Management Information Base for > > use with network management protocols in TCP/IP based=20 > Internets. In > > particular, it defines objects for configuring and=20 > controlling the > > history collection of user specified Data, which is an ASN.1 > > INTEGER based object. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-yadawad-disman-ahcf-00.txt > > > ... >=20 >=20 >=20 >=20 From exim@www1.ietf.org Wed Mar 17 14:23:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00797 for ; Wed, 17 Mar 2004 14:23:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3gct-0001Y9-V1 for disman-archive@odin.ietf.org; Wed, 17 Mar 2004 14:22:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HJMpu6005951 for disman-archive@odin.ietf.org; Wed, 17 Mar 2004 14:22:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3gct-0001Xu-PL for disman-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 14:22:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00773 for ; Wed, 17 Mar 2004 14:22:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3gcq-0002fO-00 for disman-web-archive@ietf.org; Wed, 17 Mar 2004 14:22:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3gbt-0002YK-00 for disman-web-archive@ietf.org; Wed, 17 Mar 2004 14:21:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3gb6-0002RE-00 for disman-web-archive@ietf.org; Wed, 17 Mar 2004 14:21:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3gb7-0001Sq-7L; Wed, 17 Mar 2004 14:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3gat-0001QJ-TF for disman@optimus.ietf.org; Wed, 17 Mar 2004 14:20:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00667 for ; Wed, 17 Mar 2004 14:20:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3gar-0002Q1-00 for disman@ietf.org; Wed, 17 Mar 2004 14:20:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3gZu-0002J6-00 for disman@ietf.org; Wed, 17 Mar 2004 14:19:46 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1B3gZD-0002CB-00 for disman@ietf.org; Wed, 17 Mar 2004 14:19:03 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2HJI1gL009989 for ; Wed, 17 Mar 2004 14:18:01 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2HJHxgL009936 for ; Wed, 17 Mar 2004 14:17:59 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Message-ID: Thread-Topic: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Thread-Index: AcQMUZT/FmmzFaS6ROus766PkxI54wAAljwQ From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , "Disman (E-mail)" Content-Transfer-Encoding: quoted-printable Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Mar 2004 21:18:59 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I will repeat a comment that I made during the meeting in Seoul. I think = that all, or almost all that is being defined in this MIB module can = already be performed - some features even in multiple ways - by agents = that implement existing MIB modules like RMON, Events MIB, and Alarm = MIB. I think that it would help the discussion if the authors could = shortly describe what is the added value that this MIB module would = bring, and what operations/management functions this MIB module provides = that are not covered by existing MIB modules. =20 Thanks and Regards, Dan > -----Original Message----- > From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On=20 > Behalf Of Randy Presuhn > Sent: 17 March, 2004 8:55 PM > To: Disman (E-mail) > Subject: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt >=20 >=20 > Hi - >=20 > I'd welcome discussion of this on the disman mailing list. > I think it's relevant to the question of what to do about the > expression and event MIBs. >=20 > Randy >=20 > > From: > > To: > > Sent: Wednesday, March 17, 2004 8:10 AM > > Subject: I-D ACTION:draft-yadawad-disman-ahcf-00.txt > > >=20 > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > > > > > > Title : Advanced History Collection Framework > > Author(s) : S. Yadawad, H. Kumar, H. Yamijala, R. Shekar > > Filename : draft-yadawad-disman-ahcf-00.txt > > Pages : 47 > > Date : 2004-3-17 > > > > This draft defines a portion of the Management Information Base for > > use with network management protocols in TCP/IP based=20 > Internets. In > > particular, it defines objects for configuring and=20 > controlling the > > history collection of user specified Data, which is an ASN.1 > > INTEGER based object. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-yadawad-disman-ahcf-00.txt > > > ... >=20 >=20 >=20 >=20 From disman-admin@ietf.org Wed Mar 17 15:14:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03793 for ; Wed, 17 Mar 2004 15:14:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hQP-0003V3-B8; Wed, 17 Mar 2004 15:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hQG-0003QD-LX for disman@optimus.ietf.org; Wed, 17 Mar 2004 15:13:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03684 for ; Wed, 17 Mar 2004 15:13:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3hQF-0001hu-00 for disman@ietf.org; Wed, 17 Mar 2004 15:13:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3hPD-0001WF-00 for disman@ietf.org; Wed, 17 Mar 2004 15:12:48 -0500 Received: from snipe.mail.pas.earthlink.net ([207.217.120.62]) by ietf-mx with esmtp (Exim 4.12) id 1B3hOE-0001NZ-00 for disman@ietf.org; Wed, 17 Mar 2004 15:11:46 -0500 Received: from h-68-164-156-169.snvacaid.dynamic.covad.net ([68.164.156.169] helo=oemcomputer) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1B3hOD-0001go-00 for disman@ietf.org; Wed, 17 Mar 2004 12:11:45 -0800 Message-ID: <000e01c40c5c$66edc6c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: Subject: Re: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Mar 2004 12:14:07 -0800 Hi - (as technical contributor) > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" ; "Disman (E-mail)" > Sent: Wednesday, March 17, 2004 11:18 AM > Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt > > I will repeat a comment that I made during the meeting in Seoul. I think that all, > or almost all that is being defined in this MIB module can already be performed > - some features even in multiple ways - by agents that implement existing MIB > modules like RMON, Events MIB, and Alarm MIB. This seems to be the case. I think the question raised is one of usability, that is, how difficult is it to configure these existing MIBs to these things. This is another facet of the old scripting vs. expression vs. special-purpose MIB debate, but also ties in with the questions Juergen raised in his overview of http://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt at the session in Seoul. > I think that it would help the discussion if the authors could shortly describe > what is the added value that this MIB module would bring, and what Agreed. > operations/management functions this MIB module provides that are > not covered by existing MIB modules. ... To the extent that the script MIB supports languages that are Turing complete, one could reasonably argue that all other MIBs are superfluous. Of course, a problem with such a line of argument would be the amount of pain required to use such a system. That is why the expression MIB and the script MIB were both put out as Proposed Standards. The motivation for the expression MIB was that it was supposed to be simpler to implement and use. Whether it adequately met those criteria is being questioned. From my perspective it looks like draft-yadawad-disman-ahcf-00.txt presents another factoring of the problem. I am far from convinced that it is *the* solution, but (as WG chair) I think it's appropriate to include it in the discussion of whether the expression MIB requires some re-thinking. Randy From exim@www1.ietf.org Wed Mar 17 15:16:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04059 for ; Wed, 17 Mar 2004 15:16:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hSX-0004IM-Ed for disman-archive@odin.ietf.org; Wed, 17 Mar 2004 15:16:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HKG31o016368 for disman-archive@odin.ietf.org; Wed, 17 Mar 2004 15:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hSN-0004C0-7b for disman-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 15:16:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03955 for ; Wed, 17 Mar 2004 15:15:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3hS6-00021g-00 for disman-web-archive@ietf.org; Wed, 17 Mar 2004 15:15:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3hRF-0001ti-00 for disman-web-archive@ietf.org; Wed, 17 Mar 2004 15:14:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3hQS-0001jv-00 for disman-web-archive@ietf.org; Wed, 17 Mar 2004 15:14:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hQP-0003V3-B8; Wed, 17 Mar 2004 15:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hQG-0003QD-LX for disman@optimus.ietf.org; Wed, 17 Mar 2004 15:13:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03684 for ; Wed, 17 Mar 2004 15:13:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3hQF-0001hu-00 for disman@ietf.org; Wed, 17 Mar 2004 15:13:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3hPD-0001WF-00 for disman@ietf.org; Wed, 17 Mar 2004 15:12:48 -0500 Received: from snipe.mail.pas.earthlink.net ([207.217.120.62]) by ietf-mx with esmtp (Exim 4.12) id 1B3hOE-0001NZ-00 for disman@ietf.org; Wed, 17 Mar 2004 15:11:46 -0500 Received: from h-68-164-156-169.snvacaid.dynamic.covad.net ([68.164.156.169] helo=oemcomputer) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1B3hOD-0001go-00 for disman@ietf.org; Wed, 17 Mar 2004 12:11:45 -0800 Message-ID: <000e01c40c5c$66edc6c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: Subject: Re: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Mar 2004 12:14:07 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi - (as technical contributor) > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" ; "Disman (E-mail)" > Sent: Wednesday, March 17, 2004 11:18 AM > Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt > > I will repeat a comment that I made during the meeting in Seoul. I think that all, > or almost all that is being defined in this MIB module can already be performed > - some features even in multiple ways - by agents that implement existing MIB > modules like RMON, Events MIB, and Alarm MIB. This seems to be the case. I think the question raised is one of usability, that is, how difficult is it to configure these existing MIBs to these things. This is another facet of the old scripting vs. expression vs. special-purpose MIB debate, but also ties in with the questions Juergen raised in his overview of http://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt at the session in Seoul. > I think that it would help the discussion if the authors could shortly describe > what is the added value that this MIB module would bring, and what Agreed. > operations/management functions this MIB module provides that are > not covered by existing MIB modules. ... To the extent that the script MIB supports languages that are Turing complete, one could reasonably argue that all other MIBs are superfluous. Of course, a problem with such a line of argument would be the amount of pain required to use such a system. That is why the expression MIB and the script MIB were both put out as Proposed Standards. The motivation for the expression MIB was that it was supposed to be simpler to implement and use. Whether it adequately met those criteria is being questioned. From my perspective it looks like draft-yadawad-disman-ahcf-00.txt presents another factoring of the problem. I am far from convinced that it is *the* solution, but (as WG chair) I think it's appropriate to include it in the discussion of whether the expression MIB requires some re-thinking. Randy From disman-admin@ietf.org Wed Mar 17 15:25:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05066 for ; Wed, 17 Mar 2004 15:25:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hb2-0006sA-Ta; Wed, 17 Mar 2004 15:25:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hZx-0006Rx-Ds for disman@optimus.ietf.org; Wed, 17 Mar 2004 15:23:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04869 for ; Wed, 17 Mar 2004 15:23:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3hZr-0003Dh-00 for disman@ietf.org; Wed, 17 Mar 2004 15:23:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3hYu-00035r-00 for disman@ietf.org; Wed, 17 Mar 2004 15:22:49 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1B3hY6-0002ym-00 for disman@ietf.org; Wed, 17 Mar 2004 15:21:58 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2HKHiE0017814 for ; Wed, 17 Mar 2004 15:17:44 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2HKHfE0017762 for ; Wed, 17 Mar 2004 15:17:42 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Message-ID: Thread-Topic: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Thread-Index: AcQMXIJdPtT2qeBqQV6MYG5S0xaF3wAAGYgA From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , "Disman (E-mail)" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Mar 2004 22:21:55 +0200 Content-Transfer-Encoding: quoted-printable >=20 > > operations/management functions this MIB module provides that are > > not covered by existing MIB modules. > ... >=20 > To the extent that the script MIB supports languages that are Turing > complete, one could reasonably argue that all other MIBs are=20 > superfluous. > Of course, a problem with such a line of argument would be the > amount of pain required to use such a system. That is why=20 > the expression > MIB and the script MIB were both put out as Proposed Standards. >=20 > The motivation for the expression MIB was that it was supposed to be > simpler to implement and use. Whether it adequately met those > criteria is being questioned. From my perspective it looks like > draft-yadawad-disman-ahcf-00.txt presents another factoring of > the problem. I am far from convinced that it is *the* solution, but > (as WG chair) I think it's appropriate to include it in the discussion > of whether the expression MIB requires some re-thinking. >=20 I was not going that far, and actually I did not have the expression MIB = in mind.=20 What I am seeing are mechanisms like RMON alarm and usrHistory being = reinvented, and objects like ituSeverity from the Alarm MIB being = duplicated. Dan > Randy >=20 >=20 >=20 >=20 From exim@www1.ietf.org Wed Mar 17 15:27:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05210 for ; Wed, 17 Mar 2004 15:27:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hcq-0007cx-Pk for disman-archive@odin.ietf.org; Wed, 17 Mar 2004 15:26:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HKQqRG029280 for disman-archive@odin.ietf.org; Wed, 17 Mar 2004 15:26:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hcp-0007c3-JA for disman-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 15:26:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05182 for ; Wed, 17 Mar 2004 15:26:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3hco-0003bs-00 for disman-web-archive@ietf.org; Wed, 17 Mar 2004 15:26:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3hbo-0003U2-00 for disman-web-archive@ietf.org; Wed, 17 Mar 2004 15:25:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3hb3-0003Mp-00 for disman-web-archive@ietf.org; Wed, 17 Mar 2004 15:25:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hb2-0006sA-Ta; Wed, 17 Mar 2004 15:25:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hZx-0006Rx-Ds for disman@optimus.ietf.org; Wed, 17 Mar 2004 15:23:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04869 for ; Wed, 17 Mar 2004 15:23:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3hZr-0003Dh-00 for disman@ietf.org; Wed, 17 Mar 2004 15:23:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3hYu-00035r-00 for disman@ietf.org; Wed, 17 Mar 2004 15:22:49 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1B3hY6-0002ym-00 for disman@ietf.org; Wed, 17 Mar 2004 15:21:58 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2HKHiE0017814 for ; Wed, 17 Mar 2004 15:17:44 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2HKHfE0017762 for ; Wed, 17 Mar 2004 15:17:42 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Message-ID: Thread-Topic: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Thread-Index: AcQMXIJdPtT2qeBqQV6MYG5S0xaF3wAAGYgA From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , "Disman (E-mail)" Content-Transfer-Encoding: quoted-printable Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Mar 2004 22:21:55 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >=20 > > operations/management functions this MIB module provides that are > > not covered by existing MIB modules. > ... >=20 > To the extent that the script MIB supports languages that are Turing > complete, one could reasonably argue that all other MIBs are=20 > superfluous. > Of course, a problem with such a line of argument would be the > amount of pain required to use such a system. That is why=20 > the expression > MIB and the script MIB were both put out as Proposed Standards. >=20 > The motivation for the expression MIB was that it was supposed to be > simpler to implement and use. Whether it adequately met those > criteria is being questioned. From my perspective it looks like > draft-yadawad-disman-ahcf-00.txt presents another factoring of > the problem. I am far from convinced that it is *the* solution, but > (as WG chair) I think it's appropriate to include it in the discussion > of whether the expression MIB requires some re-thinking. >=20 I was not going that far, and actually I did not have the expression MIB = in mind.=20 What I am seeing are mechanisms like RMON alarm and usrHistory being = reinvented, and objects like ituSeverity from the Alarm MIB being = duplicated. Dan > Randy >=20 >=20 >=20 >=20 From disman-admin@ietf.org Wed Mar 17 15:46:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06290 for ; Wed, 17 Mar 2004 15:46:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hvR-0001In-81; Wed, 17 Mar 2004 15:46:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3huP-0001Gn-1K for disman@optimus.ietf.org; Wed, 17 Mar 2004 15:45:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06259 for ; Wed, 17 Mar 2004 15:44:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3huN-0006FC-00 for disman@ietf.org; Wed, 17 Mar 2004 15:44:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3htS-00066R-00 for disman@ietf.org; Wed, 17 Mar 2004 15:44:02 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3hsy-0005y3-00 for disman@ietf.org; Wed, 17 Mar 2004 15:43:32 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i2HKhKO28359 for ; Wed, 17 Mar 2004 12:43:20 -0800 Message-Id: <5.2.0.9.2.20040317123446.02285f78@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: disman@ietf.org From: "David T. Perkins" Subject: Re: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt In-Reply-To: <000e01c40c5c$66edc6c0$7f1afea9@oemcomputer> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Mar 2004 12:43:11 -0800 HI, I just quickly scanned the document. It does provide in creative ways features not found in other MIB modules. These include: 1) automatic inclusion of values of new instances that come into existence after control entry creation 2) filtering based on instance 3) identification of instances via "alternative indices" The definitions do have problems, maybe all are fixable. And it might be easy to extend it to provide additional benefits at a low cost. To support it might be pretty expensive in memory and CPU processing, and it appears to be best matched for monitoring "hosts" or "big routers". At 12:14 PM 3/17/2004 -0800, Randy Presuhn wrote: >Hi - > >(as technical contributor) > >> From: "Romascanu, Dan (Dan)" >> To: "Randy Presuhn" ; "Disman (E-mail)" >> Sent: Wednesday, March 17, 2004 11:18 AM >> Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt >> > >> I will repeat a comment that I made during the meeting in Seoul. I think that all, >> or almost all that is being defined in this MIB module can already be performed >> - some features even in multiple ways - by agents that implement existing MIB >> modules like RMON, Events MIB, and Alarm MIB. > >This seems to be the case. I think the question raised is one of usability, >that is, how difficult is it to configure these existing MIBs to these things. >This is another facet of the old scripting vs. expression vs. special-purpose >MIB debate, but also ties in with the questions Juergen raised in his >overview of http://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt >at the session in Seoul. > >> I think that it would help the discussion if the authors could shortly describe >> what is the added value that this MIB module would bring, and what > >Agreed. > >> operations/management functions this MIB module provides that are >> not covered by existing MIB modules. >... > >To the extent that the script MIB supports languages that are Turing >complete, one could reasonably argue that all other MIBs are superfluous. >Of course, a problem with such a line of argument would be the >amount of pain required to use such a system. That is why the expression >MIB and the script MIB were both put out as Proposed Standards. > >The motivation for the expression MIB was that it was supposed to be >simpler to implement and use. Whether it adequately met those >criteria is being questioned. From my perspective it looks like >draft-yadawad-disman-ahcf-00.txt presents another factoring of >the problem. I am far from convinced that it is *the* solution, but >(as WG chair) I think it's appropriate to include it in the discussion >of whether the expression MIB requires some re-thinking. > >Randy Regards, /david t. perkins From exim@www1.ietf.org Wed Mar 17 16:15:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07968 for ; Wed, 17 Mar 2004 16:15:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3iNo-0004p3-RH for disman-archive@odin.ietf.org; Wed, 17 Mar 2004 16:15:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HLFOka018533 for disman-archive@odin.ietf.org; Wed, 17 Mar 2004 16:15:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hxZ-0001PK-SF for disman-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 15:48:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06418 for ; Wed, 17 Mar 2004 15:48:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3hxJ-0006ii-00 for disman-web-archive@ietf.org; Wed, 17 Mar 2004 15:48:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3hwP-0006ZV-00 for disman-web-archive@ietf.org; Wed, 17 Mar 2004 15:47:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3hvR-0006Pl-00 for disman-web-archive@ietf.org; Wed, 17 Mar 2004 15:46:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3hvR-0001In-81; Wed, 17 Mar 2004 15:46:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3huP-0001Gn-1K for disman@optimus.ietf.org; Wed, 17 Mar 2004 15:45:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06259 for ; Wed, 17 Mar 2004 15:44:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3huN-0006FC-00 for disman@ietf.org; Wed, 17 Mar 2004 15:44:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3htS-00066R-00 for disman@ietf.org; Wed, 17 Mar 2004 15:44:02 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3hsy-0005y3-00 for disman@ietf.org; Wed, 17 Mar 2004 15:43:32 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i2HKhKO28359 for ; Wed, 17 Mar 2004 12:43:20 -0800 Message-Id: <5.2.0.9.2.20040317123446.02285f78@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: disman@ietf.org From: "David T. Perkins" Subject: Re: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt In-Reply-To: <000e01c40c5c$66edc6c0$7f1afea9@oemcomputer> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Mar 2004 12:43:11 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 HI, I just quickly scanned the document. It does provide in creative ways features not found in other MIB modules. These include: 1) automatic inclusion of values of new instances that come into existence after control entry creation 2) filtering based on instance 3) identification of instances via "alternative indices" The definitions do have problems, maybe all are fixable. And it might be easy to extend it to provide additional benefits at a low cost. To support it might be pretty expensive in memory and CPU processing, and it appears to be best matched for monitoring "hosts" or "big routers". At 12:14 PM 3/17/2004 -0800, Randy Presuhn wrote: >Hi - > >(as technical contributor) > >> From: "Romascanu, Dan (Dan)" >> To: "Randy Presuhn" ; "Disman (E-mail)" >> Sent: Wednesday, March 17, 2004 11:18 AM >> Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt >> > >> I will repeat a comment that I made during the meeting in Seoul. I think that all, >> or almost all that is being defined in this MIB module can already be performed >> - some features even in multiple ways - by agents that implement existing MIB >> modules like RMON, Events MIB, and Alarm MIB. > >This seems to be the case. I think the question raised is one of usability, >that is, how difficult is it to configure these existing MIBs to these things. >This is another facet of the old scripting vs. expression vs. special-purpose >MIB debate, but also ties in with the questions Juergen raised in his >overview of http://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt >at the session in Seoul. > >> I think that it would help the discussion if the authors could shortly describe >> what is the added value that this MIB module would bring, and what > >Agreed. > >> operations/management functions this MIB module provides that are >> not covered by existing MIB modules. >... > >To the extent that the script MIB supports languages that are Turing >complete, one could reasonably argue that all other MIBs are superfluous. >Of course, a problem with such a line of argument would be the >amount of pain required to use such a system. That is why the expression >MIB and the script MIB were both put out as Proposed Standards. > >The motivation for the expression MIB was that it was supposed to be >simpler to implement and use. Whether it adequately met those >criteria is being questioned. From my perspective it looks like >draft-yadawad-disman-ahcf-00.txt presents another factoring of >the problem. I am far from convinced that it is *the* solution, but >(as WG chair) I think it's appropriate to include it in the discussion >of whether the expression MIB requires some re-thinking. > >Randy Regards, /david t. perkins From disman-admin@ietf.org Wed Mar 17 18:04:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14417 for ; Wed, 17 Mar 2004 18:04:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3k3m-0005Dr-Vz; Wed, 17 Mar 2004 18:02:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3k2l-0004m2-FJ for disman@optimus.ietf.org; Wed, 17 Mar 2004 18:01:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14362 for ; Wed, 17 Mar 2004 18:01:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3k2i-0003Lf-00 for disman@ietf.org; Wed, 17 Mar 2004 18:01:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3k1o-0003Ej-00 for disman@ietf.org; Wed, 17 Mar 2004 18:00:49 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1B3k0w-00038k-00 for disman@ietf.org; Wed, 17 Mar 2004 17:59:54 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2HMteE0002815 for ; Wed, 17 Mar 2004 17:55:40 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2HMtcE0002785 for ; Wed, 17 Mar 2004 17:55:39 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Message-ID: Thread-Topic: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Thread-Index: AcQMYP3pgck46UvIRR2hPWAXgSTPzAAEceaQ From: "Romascanu, Dan (Dan)" To: "David T. Perkins" , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 00:59:51 +0200 Content-Transfer-Encoding: quoted-printable David, There are a lot of creative ideas indeed. However, I do not understand = yet why the design approach that was taken is better than extending the = existing RMON usrHistory and Alarm mechanisms with the columns and = instance filtering mechanisms. Id I am not mistaken such mechanisms were = discussed, and rejected, or delayed by the time RMON2 was developed.=20 Let us not forget that RMON agent implementations are widely deployed = and understood and some vendors may have implemented such mechanisms = already. The argumentation in the I-D is quite extensive, but I am not = convinced that this solution is more efficient or saves agent resources. Regards, Dan > -----Original Message----- > From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On=20 > Behalf Of David T. Perkins > Sent: 17 March, 2004 10:43 PM > To: disman@ietf.org > Subject: Re: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt >=20 >=20 > HI, >=20 > I just quickly scanned the document. It does provide in creative ways > features not found in other MIB modules. These include: > 1) automatic inclusion of values of new instances that come > into existence after control entry creation > 2) filtering based on instance > 3) identification of instances via "alternative indices"=20 >=20 > The definitions do have problems, maybe all are fixable. And it > might be easy to extend it to provide additional benefits at a > low cost. >=20 > To support it might be pretty expensive in memory and CPU processing, > and it appears to be best matched for monitoring "hosts" or > "big routers". >=20 > At 12:14 PM 3/17/2004 -0800, Randy Presuhn wrote: > >Hi - > > > >(as technical contributor) > > > >> From: "Romascanu, Dan (Dan)" > >> To: "Randy Presuhn" ;=20 > "Disman (E-mail)" > >> Sent: Wednesday, March 17, 2004 11:18 AM > >> Subject: RE: [Disman] Fw: I-D=20 > ACTION:draft-yadawad-disman-ahcf-00.txt > >> > > > >> I will repeat a comment that I made during the meeting in=20 > Seoul. I think that all, > >> or almost all that is being defined in this MIB module can=20 > already be performed > >> - some features even in multiple ways - by agents that=20 > implement existing MIB > >> modules like RMON, Events MIB, and Alarm MIB. > > > >This seems to be the case. I think the question raised is=20 > one of usability, > >that is, how difficult is it to configure these existing=20 > MIBs to these things. > >This is another facet of the old scripting vs. expression=20 > vs. special-purpose > >MIB debate, but also ties in with the questions Juergen raised in his > >overview of =20 > http://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt > >at the session in Seoul. > > > >> I think that it would help the discussion if the authors=20 > could shortly describe > >> what is the added value that this MIB module would bring, and what > > > >Agreed. > > > >> operations/management functions this MIB module provides that are > >> not covered by existing MIB modules. > >... > > > >To the extent that the script MIB supports languages that are Turing > >complete, one could reasonably argue that all other MIBs are=20 > superfluous. > >Of course, a problem with such a line of argument would be the > >amount of pain required to use such a system. That is why=20 > the expression > >MIB and the script MIB were both put out as Proposed Standards. > > > >The motivation for the expression MIB was that it was supposed to be > >simpler to implement and use. Whether it adequately met those > >criteria is being questioned. From my perspective it looks like > >draft-yadawad-disman-ahcf-00.txt presents another factoring of > >the problem. I am far from convinced that it is *the* solution, but > >(as WG chair) I think it's appropriate to include it in the=20 > discussion > >of whether the expression MIB requires some re-thinking. > > > >Randy > Regards, > /david t. perkins=20 >=20 >=20 >=20 From exim@www1.ietf.org Wed Mar 17 18:06:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14608 for ; Wed, 17 Mar 2004 18:06:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3k6k-0007Ot-O8 for disman-archive@odin.ietf.org; Wed, 17 Mar 2004 18:05:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HN5sct028446 for disman-archive@odin.ietf.org; Wed, 17 Mar 2004 18:05:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3k6j-0007Oj-Up for disman-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 18:05:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14562 for ; Wed, 17 Mar 2004 18:05:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3k6h-0003pp-00 for disman-web-archive@ietf.org; Wed, 17 Mar 2004 18:05:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3k5m-0003ib-00 for disman-web-archive@ietf.org; Wed, 17 Mar 2004 18:04:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3k56-0003bU-00 for disman-web-archive@ietf.org; Wed, 17 Mar 2004 18:04:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3k3m-0005Dr-Vz; Wed, 17 Mar 2004 18:02:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3k2l-0004m2-FJ for disman@optimus.ietf.org; Wed, 17 Mar 2004 18:01:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14362 for ; Wed, 17 Mar 2004 18:01:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3k2i-0003Lf-00 for disman@ietf.org; Wed, 17 Mar 2004 18:01:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3k1o-0003Ej-00 for disman@ietf.org; Wed, 17 Mar 2004 18:00:49 -0500 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1B3k0w-00038k-00 for disman@ietf.org; Wed, 17 Mar 2004 17:59:54 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2HMteE0002815 for ; Wed, 17 Mar 2004 17:55:40 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2HMtcE0002785 for ; Wed, 17 Mar 2004 17:55:39 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Message-ID: Thread-Topic: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Thread-Index: AcQMYP3pgck46UvIRR2hPWAXgSTPzAAEceaQ From: "Romascanu, Dan (Dan)" To: "David T. Perkins" , Content-Transfer-Encoding: quoted-printable Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 00:59:51 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable David, There are a lot of creative ideas indeed. However, I do not understand = yet why the design approach that was taken is better than extending the = existing RMON usrHistory and Alarm mechanisms with the columns and = instance filtering mechanisms. Id I am not mistaken such mechanisms were = discussed, and rejected, or delayed by the time RMON2 was developed.=20 Let us not forget that RMON agent implementations are widely deployed = and understood and some vendors may have implemented such mechanisms = already. The argumentation in the I-D is quite extensive, but I am not = convinced that this solution is more efficient or saves agent resources. Regards, Dan > -----Original Message----- > From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On=20 > Behalf Of David T. Perkins > Sent: 17 March, 2004 10:43 PM > To: disman@ietf.org > Subject: Re: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt >=20 >=20 > HI, >=20 > I just quickly scanned the document. It does provide in creative ways > features not found in other MIB modules. These include: > 1) automatic inclusion of values of new instances that come > into existence after control entry creation > 2) filtering based on instance > 3) identification of instances via "alternative indices"=20 >=20 > The definitions do have problems, maybe all are fixable. And it > might be easy to extend it to provide additional benefits at a > low cost. >=20 > To support it might be pretty expensive in memory and CPU processing, > and it appears to be best matched for monitoring "hosts" or > "big routers". >=20 > At 12:14 PM 3/17/2004 -0800, Randy Presuhn wrote: > >Hi - > > > >(as technical contributor) > > > >> From: "Romascanu, Dan (Dan)" > >> To: "Randy Presuhn" ;=20 > "Disman (E-mail)" > >> Sent: Wednesday, March 17, 2004 11:18 AM > >> Subject: RE: [Disman] Fw: I-D=20 > ACTION:draft-yadawad-disman-ahcf-00.txt > >> > > > >> I will repeat a comment that I made during the meeting in=20 > Seoul. I think that all, > >> or almost all that is being defined in this MIB module can=20 > already be performed > >> - some features even in multiple ways - by agents that=20 > implement existing MIB > >> modules like RMON, Events MIB, and Alarm MIB. > > > >This seems to be the case. I think the question raised is=20 > one of usability, > >that is, how difficult is it to configure these existing=20 > MIBs to these things. > >This is another facet of the old scripting vs. expression=20 > vs. special-purpose > >MIB debate, but also ties in with the questions Juergen raised in his > >overview of =20 > http://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt > >at the session in Seoul. > > > >> I think that it would help the discussion if the authors=20 > could shortly describe > >> what is the added value that this MIB module would bring, and what > > > >Agreed. > > > >> operations/management functions this MIB module provides that are > >> not covered by existing MIB modules. > >... > > > >To the extent that the script MIB supports languages that are Turing > >complete, one could reasonably argue that all other MIBs are=20 > superfluous. > >Of course, a problem with such a line of argument would be the > >amount of pain required to use such a system. That is why=20 > the expression > >MIB and the script MIB were both put out as Proposed Standards. > > > >The motivation for the expression MIB was that it was supposed to be > >simpler to implement and use. Whether it adequately met those > >criteria is being questioned. From my perspective it looks like > >draft-yadawad-disman-ahcf-00.txt presents another factoring of > >the problem. I am far from convinced that it is *the* solution, but > >(as WG chair) I think it's appropriate to include it in the=20 > discussion > >of whether the expression MIB requires some re-thinking. > > > >Randy > Regards, > /david t. perkins=20 >=20 >=20 >=20 From disman-admin@ietf.org Wed Mar 17 19:09:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18810 for ; Wed, 17 Mar 2004 19:09:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3l5p-0006yp-74; Wed, 17 Mar 2004 19:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3l4w-0006kJ-S2 for disman@optimus.ietf.org; Wed, 17 Mar 2004 19:08:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18781 for ; Wed, 17 Mar 2004 19:08:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3l4t-0004dG-00 for disman@ietf.org; Wed, 17 Mar 2004 19:08:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3l45-0004VL-00 for disman@ietf.org; Wed, 17 Mar 2004 19:07:14 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3l3a-0004N1-00 for disman@ietf.org; Wed, 17 Mar 2004 19:06:42 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i2I06fO21300 for ; Wed, 17 Mar 2004 16:06:41 -0800 Message-Id: <5.2.0.9.2.20040317155957.0227da60@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: disman@ietf.org From: "David T. Perkins" Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Mar 2004 16:06:33 -0800 HI, On the issue of whether or not to extend existing RMOM definitions or to create new ones is something that I can see both sides. It appears to me that the new proposal is something that would be found in a host or big infrastructure box (such as a big router). In neither of these is a place one would find RMON, and, thus to me it boils down to a "packaging" issue. At 12:59 AM 3/18/2004 +0200, Romascanu, Dan (Dan) wrote: >David, > >There are a lot of creative ideas indeed. However, I do not understand yet why the design approach that was taken is better than extending the existing RMON usrHistory and Alarm mechanisms with the columns and instance filtering mechanisms. Id I am not mistaken such mechanisms were discussed, and rejected, or delayed by the time RMON2 was developed. > >Let us not forget that RMON agent implementations are widely deployed and understood and some vendors may have implemented such mechanisms already. The argumentation in the I-D is quite extensive, but I am not convinced that this solution is more efficient or saves agent resources. > >Regards, > >Dan > > > >> -----Original Message----- >> From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On >> Behalf Of David T. Perkins >> Sent: 17 March, 2004 10:43 PM >> To: disman@ietf.org >> Subject: Re: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt >> >> >> HI, >> >> I just quickly scanned the document. It does provide in creative ways >> features not found in other MIB modules. These include: >> 1) automatic inclusion of values of new instances that come >> into existence after control entry creation >> 2) filtering based on instance >> 3) identification of instances via "alternative indices" >> >> The definitions do have problems, maybe all are fixable. And it >> might be easy to extend it to provide additional benefits at a >> low cost. >> >> To support it might be pretty expensive in memory and CPU processing, >> and it appears to be best matched for monitoring "hosts" or >> "big routers". >> >> At 12:14 PM 3/17/2004 -0800, Randy Presuhn wrote: >> >Hi - >> > >> >(as technical contributor) >> > >> >> From: "Romascanu, Dan (Dan)" >> >> To: "Randy Presuhn" ; >> "Disman (E-mail)" >> >> Sent: Wednesday, March 17, 2004 11:18 AM >> >> Subject: RE: [Disman] Fw: I-D >> ACTION:draft-yadawad-disman-ahcf-00.txt >> >> >> > >> >> I will repeat a comment that I made during the meeting in >> Seoul. I think that all, >> >> or almost all that is being defined in this MIB module can >> already be performed >> >> - some features even in multiple ways - by agents that >> implement existing MIB >> >> modules like RMON, Events MIB, and Alarm MIB. >> > >> >This seems to be the case. I think the question raised is >> one of usability, >> >that is, how difficult is it to configure these existing >> MIBs to these things. >> >This is another facet of the old scripting vs. expression >> vs. special-purpose >> >MIB debate, but also ties in with the questions Juergen raised in his >> >overview of >> http://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt >> >at the session in Seoul. >> > >> >> I think that it would help the discussion if the authors >> could shortly describe >> >> what is the added value that this MIB module would bring, and what >> > >> >Agreed. >> > >> >> operations/management functions this MIB module provides that are >> >> not covered by existing MIB modules. >> >... >> > >> >To the extent that the script MIB supports languages that are Turing >> >complete, one could reasonably argue that all other MIBs are >> superfluous. >> >Of course, a problem with such a line of argument would be the >> >amount of pain required to use such a system. That is why >> the expression >> >MIB and the script MIB were both put out as Proposed Standards. >> > >> >The motivation for the expression MIB was that it was supposed to be >> >simpler to implement and use. Whether it adequately met those >> >criteria is being questioned. From my perspective it looks like >> >draft-yadawad-disman-ahcf-00.txt presents another factoring of >> >the problem. I am far from convinced that it is *the* solution, but >> >(as WG chair) I think it's appropriate to include it in the >> discussion >> >of whether the expression MIB requires some re-thinking. >> > >> >Randy >> Regards, >> /david t. perkins >> >> >> From exim@www1.ietf.org Wed Mar 17 19:11:18 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18889 for ; Wed, 17 Mar 2004 19:11:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3l7d-00075s-2D for disman-archive@odin.ietf.org; Wed, 17 Mar 2004 19:10:53 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2I0AqRC027259 for disman-archive@odin.ietf.org; Wed, 17 Mar 2004 19:10:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3l7c-00075a-JM for disman-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 19:10:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18866 for ; Wed, 17 Mar 2004 19:10:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3l7Y-0004yB-00 for disman-web-archive@ietf.org; Wed, 17 Mar 2004 19:10:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3l6g-0004rs-00 for disman-web-archive@ietf.org; Wed, 17 Mar 2004 19:09:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3l5o-0004l5-00 for disman-web-archive@ietf.org; Wed, 17 Mar 2004 19:09:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3l5p-0006yp-74; Wed, 17 Mar 2004 19:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3l4w-0006kJ-S2 for disman@optimus.ietf.org; Wed, 17 Mar 2004 19:08:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18781 for ; Wed, 17 Mar 2004 19:08:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3l4t-0004dG-00 for disman@ietf.org; Wed, 17 Mar 2004 19:08:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3l45-0004VL-00 for disman@ietf.org; Wed, 17 Mar 2004 19:07:14 -0500 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3l3a-0004N1-00 for disman@ietf.org; Wed, 17 Mar 2004 19:06:42 -0500 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) by shell4.bayarea.net (8.11.6/8.11.6) with ESMTP id i2I06fO21300 for ; Wed, 17 Mar 2004 16:06:41 -0800 Message-Id: <5.2.0.9.2.20040317155957.0227da60@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 To: disman@ietf.org From: "David T. Perkins" Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 17 Mar 2004 16:06:33 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 HI, On the issue of whether or not to extend existing RMOM definitions or to create new ones is something that I can see both sides. It appears to me that the new proposal is something that would be found in a host or big infrastructure box (such as a big router). In neither of these is a place one would find RMON, and, thus to me it boils down to a "packaging" issue. At 12:59 AM 3/18/2004 +0200, Romascanu, Dan (Dan) wrote: >David, > >There are a lot of creative ideas indeed. However, I do not understand yet why the design approach that was taken is better than extending the existing RMON usrHistory and Alarm mechanisms with the columns and instance filtering mechanisms. Id I am not mistaken such mechanisms were discussed, and rejected, or delayed by the time RMON2 was developed. > >Let us not forget that RMON agent implementations are widely deployed and understood and some vendors may have implemented such mechanisms already. The argumentation in the I-D is quite extensive, but I am not convinced that this solution is more efficient or saves agent resources. > >Regards, > >Dan > > > >> -----Original Message----- >> From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On >> Behalf Of David T. Perkins >> Sent: 17 March, 2004 10:43 PM >> To: disman@ietf.org >> Subject: Re: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt >> >> >> HI, >> >> I just quickly scanned the document. It does provide in creative ways >> features not found in other MIB modules. These include: >> 1) automatic inclusion of values of new instances that come >> into existence after control entry creation >> 2) filtering based on instance >> 3) identification of instances via "alternative indices" >> >> The definitions do have problems, maybe all are fixable. And it >> might be easy to extend it to provide additional benefits at a >> low cost. >> >> To support it might be pretty expensive in memory and CPU processing, >> and it appears to be best matched for monitoring "hosts" or >> "big routers". >> >> At 12:14 PM 3/17/2004 -0800, Randy Presuhn wrote: >> >Hi - >> > >> >(as technical contributor) >> > >> >> From: "Romascanu, Dan (Dan)" >> >> To: "Randy Presuhn" ; >> "Disman (E-mail)" >> >> Sent: Wednesday, March 17, 2004 11:18 AM >> >> Subject: RE: [Disman] Fw: I-D >> ACTION:draft-yadawad-disman-ahcf-00.txt >> >> >> > >> >> I will repeat a comment that I made during the meeting in >> Seoul. I think that all, >> >> or almost all that is being defined in this MIB module can >> already be performed >> >> - some features even in multiple ways - by agents that >> implement existing MIB >> >> modules like RMON, Events MIB, and Alarm MIB. >> > >> >This seems to be the case. I think the question raised is >> one of usability, >> >that is, how difficult is it to configure these existing >> MIBs to these things. >> >This is another facet of the old scripting vs. expression >> vs. special-purpose >> >MIB debate, but also ties in with the questions Juergen raised in his >> >overview of >> http://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt >> >at the session in Seoul. >> > >> >> I think that it would help the discussion if the authors >> could shortly describe >> >> what is the added value that this MIB module would bring, and what >> > >> >Agreed. >> > >> >> operations/management functions this MIB module provides that are >> >> not covered by existing MIB modules. >> >... >> > >> >To the extent that the script MIB supports languages that are Turing >> >complete, one could reasonably argue that all other MIBs are >> superfluous. >> >Of course, a problem with such a line of argument would be the >> >amount of pain required to use such a system. That is why >> the expression >> >MIB and the script MIB were both put out as Proposed Standards. >> > >> >The motivation for the expression MIB was that it was supposed to be >> >simpler to implement and use. Whether it adequately met those >> >criteria is being questioned. From my perspective it looks like >> >draft-yadawad-disman-ahcf-00.txt presents another factoring of >> >the problem. I am far from convinced that it is *the* solution, but >> >(as WG chair) I think it's appropriate to include it in the >> discussion >> >of whether the expression MIB requires some re-thinking. >> > >> >Randy >> Regards, >> /david t. perkins >> >> >> From disman-admin@ietf.org Thu Mar 18 05:43:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01909 for ; Thu, 18 Mar 2004 05:43:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uzP-0001zO-EC; Thu, 18 Mar 2004 05:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uyl-0001yD-Il for disman@optimus.ietf.org; Thu, 18 Mar 2004 05:42:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01846 for ; Thu, 18 Mar 2004 05:42:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3uyh-0006cQ-00 for disman@ietf.org; Thu, 18 Mar 2004 05:42:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3uxu-0006VB-00 for disman@ietf.org; Thu, 18 Mar 2004 05:41:31 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1B3uxL-0006Me-00 for disman@ietf.org; Thu, 18 Mar 2004 05:40:55 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Thu, 18 Mar 2004 03:40:21 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: , Subject: Re: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part6243766F.0__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 03:39:59 -0700 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part6243766F.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Randy, >This seems to be the case. I think the question raised is one of usability, >that is, how difficult is it to configure these existing MIBs to these things. >This is another facet of the old scripting vs. expression vs. special-purpose >MIB debate, but also ties in with the questions Juergen raised in his >overview of http://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt >at the session in Seoul. Yes, usability is one of the motivation for our draft. >To the extent that the script MIB supports languages that are Turing >complete, one could reasonably argue that all other MIBs are superfluous. >Of course, a problem with such a line of argument would be the >amount of pain required to use such a system. That is why the expression >MIB and the script MIB were both put out as Proposed Standards. How true. It is not possible restrict the user to find solution for the problem with the existing MIB definitions. >The motivation for the expression MIB was that it was supposed to be >simpler to implement and use. Whether it adequately met those >criteria is being questioned. From my perspective it looks like >draft-yadawad-disman-ahcf-00.txt presents another factoring of >the problem. Thanks. Regards, Shailaja. --=__Part6243766F.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Randy,

 
>This seems to be the case.  I think = the question raised is one of usability,
>that is, how difficult is = it to configure these existing MIBs to these things.
>This is = another facet of the old scripting vs. expression vs. special-purpose
&g= t;MIB debate, but also ties in with the questions Juergen raised in = his
>overview of  http://www.ietf.org/internet-drafts/draft-nu= nzi-check-mib-00.txt
>at the session in Seoul.
Yes, usability is one of the motivation for = our draft.
 
>To the extent that the script MIB = supports languages that are Turing
>complete, one could reasonably = argue that all other MIBs are superfluous.
>Of course, a problem = with such a line of argument would be the
>amount of pain required = to use such a system.  That is why the expression
>MIB and the = script MIB were both put out as Proposed Standards.
How true. It is not possible restrict the = user to find solution for the problem with the
existing MIB definitions.
 
>The motivation for the expression MIB = was that it was supposed to be
>simpler to implement and use.  = Whether it adequately met those
>criteria is being questioned.  = From disman-admin@ietf.org Thu Mar 18 05:44:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01984 for ; Thu, 18 Mar 2004 05:44:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3v0L-000230-38; Thu, 18 Mar 2004 05:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uze-00022Y-Rv for disman@optimus.ietf.org; Thu, 18 Mar 2004 05:43:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01873 for ; Thu, 18 Mar 2004 05:43:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3uzb-0006jf-00 for disman@ietf.org; Thu, 18 Mar 2004 05:43:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3uyc-0006bl-00 for disman@ietf.org; Thu, 18 Mar 2004 05:42:15 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1B3uxo-0006OJ-00 for disman@ietf.org; Thu, 18 Mar 2004 05:41:24 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Thu, 18 Mar 2004 03:40:56 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: , Subject: Re: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartBE9FAAB3.1__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 03:40:35 -0700 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartBE9FAAB3.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit David, You have correctly captured the proposed features in our draft. It will be great to fix all the definitions problems that you foresee. Regards, Shailaja. >>> "David T. Perkins" 3/18/2004 2:13:11 AM >>> HI, I just quickly scanned the document. It does provide in creative ways features not found in other MIB modules. These include: 1) automatic inclusion of values of new instances that come into existence after control entry creation 2) filtering based on instance 3) identification of instances via "alternative indices" The definitions do have problems, maybe all are fixable. And it might be easy to extend it to provide additional benefits at a low cost. To support it might be pretty expensive in memory and CPU processing, and it appears to be best matched for monitoring "hosts" or "big routers". At 12:14 PM 3/17/2004 -0800, Randy Presuhn wrote: >Hi - > >(as technical contributor) > >> From: "Romascanu, Dan (Dan)" >> To: "Randy Presuhn" ; "Disman (E-mail)" >> Sent: Wednesday, March 17, 2004 11:18 AM >> Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt >> > >> I will repeat a comment that I made during the meeting in Seoul. I think that all, >> or almost all that is being defined in this MIB module can already be performed >> - some features even in multiple ways - by agents that implement existing MIB >> modules like RMON, Events MIB, and Alarm MIB. > >This seems to be the case. I think the question raised is one of usability, >that is, how difficult is it to configure these existing MIBs to these things. >This is another facet of the old scripting vs. expression vs. special-purpose >MIB debate, but also ties in with the questions Juergen raised in his >overview of http://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt >at the session in Seoul. > >> I think that it would help the discussion if the authors could shortly describe >> what is the added value that this MIB module would bring, and what > >Agreed. > >> operations/management functions this MIB module provides that are >> not covered by existing MIB modules. >... > >To the extent that the script MIB supports languages that are Turing >complete, one could reasonably argue that all other MIBs are superfluous. >Of course, a problem with such a line of argument would be the >amount of pain required to use such a system. That is why the expression >MIB and the script MIB were both put out as Proposed Standards. > >The motivation for the expression MIB was that it was supposed to be >simpler to implement and use. Whether it adequately met those >criteria is being questioned. From my perspective it looks like >draft-yadawad-disman-ahcf-00.txt presents another factoring of >the problem. I am far from convinced that it is *the* solution, but >(as WG chair) I think it's appropriate to include it in the discussion >of whether the expression MIB requires some re-thinking. > >Randy Regards, /david t. perkins --=__PartBE9FAAB3.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
David,
 
You have correctly captured the proposed features in our draft.
 
It will be great to fix all the definitions problems that you = foresee.
 
Regards,
Shailaja.

>>> "David T. Perkins" <dperkins@dsperkins.com> = 3/18/2004 2:13:11 AM >>>
HI,

I just quickly scanned the = document. It does provide in creative ways
features not found in other = MIB modules. These include:
  1) automatic inclusion of values of = new instances that come
     into existence after = control entry creation
  2) filtering based on instance
  = 3) identification of instances via "alternative indices"

The = definitions do have problems, maybe all are fixable. And it
might be = easy to extend it to provide additional benefits at a
low cost.

T= o support it might be pretty expensive in memory and CPU processing,
and= it appears to be best matched for monitoring "hosts" or
"big routers".<= BR>
At 12:14 PM 3/17/2004 -0800, Randy Presuhn wrote:
>Hi = -
>
>(as technical contributor)
>
>> From: = "Romascanu, Dan (Dan)" <dromasca@avaya.com>
>> To: "Randy = Presuhn" <randy_presuhn@mindspring.com>; "Disman (E-mail)" <disman= @ietf.org>
>> Sent: Wednesday, March 17, 2004 11:18 AM
>&= gt; Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt>>
>
>> I will repeat a comment that I made during = the meeting in Seoul. I think that all,
>> or almost all that is = being defined in this MIB module can already be performed
>> - = some features even in multiple ways - by agents that implement existing = MIB
>> modules like RMON, Events MIB, and Alarm MIB.
>
&g= t;This seems to be the case.  I think the question raised is one of = usability,
>that is, how difficult is it to configure these existing = MIBs to these things.
>This is another facet of the old scripting = vs. expression vs. special-purpose
>MIB debate, but also ties in = with the questions Juergen raised in his
>overview of  h= ttp://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt
>= at the session in Seoul.
>
>> I think that it would help = the discussion if the authors could shortly describe
>> what is = the added value that this MIB module would bring, and what
>
>A= greed.
>
>> operations/management functions this MIB module = provides that are
>> not covered by existing MIB modules.
>.= ..
>
>To the extent that the script MIB supports languages = that are Turing
>complete, one could reasonably argue that all other = MIBs are superfluous.
>Of course, a problem with such a line of = argument would be the
>amount of pain required to use such a = system.  That is why the expression
>MIB and the script MIB = were both put out as Proposed Standards.
>
>The motivation for = the expression MIB was that it was supposed to be
>simpler to = implement and use.  Whether it adequately met those
>criteria = is being questioned.  From my perspective it looks like
>draft-y= adawad-disman-ahcf-00.txt presents another factoring of
>the = problem.  I am far from convinced that it is *the* solution, = but
>(as WG chair) I think it's appropriate to include it in the = discussion
>of whether the expression MIB requires some re-thinking.<= BR>>
>Randy
Regards,
/david t. perkins


--=__PartBE9FAAB3.1__=-- From exim@www1.ietf.org Thu Mar 18 05:44:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02002 for ; Thu, 18 Mar 2004 05:44:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3v0i-00029a-C2 for disman-archive@odin.ietf.org; Thu, 18 Mar 2004 05:44:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IAiOw1008264 for disman-archive@odin.ietf.org; Thu, 18 Mar 2004 05:44:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3v0g-00029B-KA for disman-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 05:44:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01977 for ; Thu, 18 Mar 2004 05:44:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3v0d-0006sD-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 05:44:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3uzq-0006la-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 05:43:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3uzP-0006du-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 05:43:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uzP-0001zW-UU; Thu, 18 Mar 2004 05:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uym-0001yI-1n for disman@optimus.ietf.org; Thu, 18 Mar 2004 05:42:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01849 for ; Thu, 18 Mar 2004 05:42:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3uyi-0006cW-00 for disman@ietf.org; Thu, 18 Mar 2004 05:42:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3uxv-0006VJ-00 for disman@ietf.org; Thu, 18 Mar 2004 05:41:32 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1B3uxL-0006Mk-00 for disman@ietf.org; Thu, 18 Mar 2004 05:40:55 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Thu, 18 Mar 2004 03:40:21 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: , , Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part95B48198.1__=" Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 03:40:08 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part95B48198.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Dan, >I was not going that far, and actually I did not have the expression MIB in mind. Expression MIB can be modified based on some of our features. >What I am seeing are mechanisms like RMON alarm and usrHistory being reinvented, and >objects like ituSeverity from the Alarm MIB being duplicated. you are correct that our draft contains object definition similar to that of RMON alarm and usrHistory but with additional features and changes. Regards, Shailaja. --=__Part95B48198.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dan,
 
>I was not going = that far, and actually I did not have the expression MIB in mind. =
Expression MIB can be modified based on some of our features.

>What I am seeing are mechanisms like RMON alarm and usrHistory= being reinvented, and >objects like ituSeverity from the Alarm MIB = being duplicated.

you are correct that our draft contains object = definition similar to that of  RMON alarm and usrHistory but = with additional features and changes.
 
Regards,
Shailaja.
--=__Part95B48198.1__=-- From disman-admin@ietf.org Thu Mar 18 05:45:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02064 for ; Thu, 18 Mar 2004 05:45:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3v1J-0002C8-Lw; Thu, 18 Mar 2004 05:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3v0Z-00027l-Af for disman@optimus.ietf.org; Thu, 18 Mar 2004 05:44:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01943 for ; Thu, 18 Mar 2004 05:44:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3v0V-0006rA-00 for disman@ietf.org; Thu, 18 Mar 2004 05:44:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3uzW-0006j9-00 for disman@ietf.org; Thu, 18 Mar 2004 05:43:11 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1B3uyX-0006Vs-00 for disman@ietf.org; Thu, 18 Mar 2004 05:42:09 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Thu, 18 Mar 2004 03:41:41 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: , , Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartCDECD9C0.2__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 03:41:20 -0700 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartCDECD9C0.2__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Dan, Our main objective was easy and automatic configuration. In case of usr history group, history collection can be configured for any number of oids of any table for a given control entry, this will break our design as configuration settings become specific to particular tables. This was one main reason as why we did not propose extending the usr history group. Dan, the main thing is easy configuration and also let user configure only for the desired number of instances which in turn saves the resource. Regards, Shailaja. >>> "Romascanu, Dan (Dan)" 3/18/2004 4:29:51 AM >>> David, There are a lot of creative ideas indeed. However, I do not understand yet why the design approach that was taken is better than extending the existing RMON usrHistory and Alarm mechanisms with the columns and instance filtering mechanisms. Id I am not mistaken such mechanisms were discussed, and rejected, or delayed by the time RMON2 was developed. Let us not forget that RMON agent implementations are widely deployed and understood and some vendors may have implemented such mechanisms already. The argumentation in the I-D is quite extensive, but I am not convinced that this solution is more efficient or saves agent resources. Regards, Dan > -----Original Message----- > From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On > Behalf Of David T. Perkins > Sent: 17 March, 2004 10:43 PM > To: disman@ietf.org > Subject: Re: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt > > > HI, > > I just quickly scanned the document. It does provide in creative ways > features not found in other MIB modules. These include: > 1) automatic inclusion of values of new instances that come > into existence after control entry creation > 2) filtering based on instance > 3) identification of instances via "alternative indices" > > The definitions do have problems, maybe all are fixable. And it > might be easy to extend it to provide additional benefits at a > low cost. > > To support it might be pretty expensive in memory and CPU processing, > and it appears to be best matched for monitoring "hosts" or > "big routers". > > At 12:14 PM 3/17/2004 -0800, Randy Presuhn wrote: > >Hi - > > > >(as technical contributor) > > > >> From: "Romascanu, Dan (Dan)" > >> To: "Randy Presuhn" ; > "Disman (E-mail)" > >> Sent: Wednesday, March 17, 2004 11:18 AM > >> Subject: RE: [Disman] Fw: I-D > ACTION:draft-yadawad-disman-ahcf-00.txt > >> > > > >> I will repeat a comment that I made during the meeting in > Seoul. I think that all, > >> or almost all that is being defined in this MIB module can > already be performed > >> - some features even in multiple ways - by agents that > implement existing MIB > >> modules like RMON, Events MIB, and Alarm MIB. > > > >This seems to be the case. I think the question raised is > one of usability, > >that is, how difficult is it to configure these existing > MIBs to these things. > >This is another facet of the old scripting vs. expression > vs. special-purpose > >MIB debate, but also ties in with the questions Juergen raised in his > >overview of > http://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt > >at the session in Seoul. > > > >> I think that it would help the discussion if the authors > could shortly describe > >> what is the added value that this MIB module would bring, and what > > > >Agreed. > > > >> operations/management functions this MIB module provides that are > >> not covered by existing MIB modules. > >... > > > >To the extent that the script MIB supports languages that are Turing > >complete, one could reasonably argue that all other MIBs are > superfluous. > >Of course, a problem with such a line of argument would be the > >amount of pain required to use such a system. That is why > the expression > >MIB and the script MIB were both put out as Proposed Standards. > > > >The motivation for the expression MIB was that it was supposed to be > >simpler to implement and use. Whether it adequately met those > >criteria is being questioned. From my perspective it looks like > >draft-yadawad-disman-ahcf-00.txt presents another factoring of > >the problem. I am far from convinced that it is *the* solution, but > >(as WG chair) I think it's appropriate to include it in the > discussion > >of whether the expression MIB requires some re-thinking. > > > >Randy > Regards, > /david t. perkins > > > --=__PartCDECD9C0.2__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dan,
 
Our main objective was easy and automatic configuration. In case of = usr history group, history collection can be configured for any number of = oids of any table for a given control entry, this will break our design as = configuration settings become specific to particular tables. This was one = main reason as why we did not propose extending the usr history group.
 
Dan, the main thing is easy configuration and also let user = configure only for the desired number of instances which in turn saves the = resource.
 
Regards,
Shailaja.
 

>>> "Romascanu, Dan (Dan)" <dromasca@avaya.com> = 3/18/2004 4:29:51 AM >>>
David,

There are a lot of creative = ideas indeed. However, I do not understand yet why the design approach = that was taken is better than extending the existing RMON usrHistory and = Alarm mechanisms with the columns and instance filtering mechanisms. Id I = am not mistaken such mechanisms were discussed, and rejected, or delayed = by the time RMON2 was developed.

Let us not forget that RMON agent = implementations are widely deployed and understood and some vendors may = have implemented such mechanisms already. The argumentation in the I-D is = quite extensive, but I am not convinced that this solution is more = efficient or saves agent resources.

Regards,

Dan


<= BR>> -----Original Message-----
> From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On
> Behalf Of David T. Perkins
> Sent: 17 March, 2004 10:43 = PM
> To: disman@ietf.org
> Subject: Re: [Disman] Fw: I-D = ACTION:draft-yadawad-disman-ahcf-00.txt
>
>
> = HI,
>
> I just quickly scanned the document. It does provide = in creative ways
> features not found in other MIB modules. These = include:
>   1) automatic inclusion of values of new = instances that come
>      into existence = after control entry creation
>   2) filtering based on = instance
>   3) identification of instances via "alternativ= e indices"
>
> The definitions do have problems, maybe all = are fixable. And it
> might be easy to extend it to provide = additional benefits at a
> low cost.
>
> To support it = might be pretty expensive in memory and CPU processing,
> and it = appears to be best matched for monitoring "hosts" or
> "big = routers".
>
> At 12:14 PM 3/17/2004 -0800, Randy Presuhn = wrote:
> >Hi -
> >
> >(as technical contributor)=
> >
> >> From: "Romascanu, Dan (Dan)" <dromasca@av= aya.com>
> >> To: "Randy Presuhn" <randy_presuhn@mindspri= ng.com>;
> "Disman (E-mail)" <disman@ietf.org>
> = >> Sent: Wednesday, March 17, 2004 11:18 AM
> >> = Subject: RE: [Disman] Fw: I-D
> ACTION:draft-yadawad-disman-ahcf-00.= txt
> >>
> >
> >> I will repeat a comment = that I made during the meeting in
> Seoul. I think that all,
>= >> or almost all that is being defined in this MIB module can =
> already be performed
> >> - some features even in = multiple ways - by agents that
> implement existing MIB
> = >> modules like RMON, Events MIB, and Alarm MIB.
> >
>= >This seems to be the case.  I think the question raised is =
> one of usability,
> >that is, how difficult is it to = configure these existing
> MIBs to these things.
> >This = is another facet of the old scripting vs. expression
> vs. = special-purpose
> >MIB debate, but also ties in with the = questions Juergen raised in his
> >overview of 
> h= ttp://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt
>= >at the session in Seoul.
> >
> >> I think that = it would help the discussion if the authors
> could shortly = describe
> >> what is the added value that this MIB module = would bring, and what
> >
> >Agreed.
> >
>= >> operations/management functions this MIB module provides that = are
> >> not covered by existing MIB modules.
> = >...
> >
> >To the extent that the script MIB = supports languages that are Turing
> >complete, one could = reasonably argue that all other MIBs are
> superfluous.
> = >Of course, a problem with such a line of argument would be the
> = >amount of pain required to use such a system.  That is why =
> the expression
> >MIB and the script MIB were both put = out as Proposed Standards.
> >
> >The motivation for the = expression MIB was that it was supposed to be
> >simpler to = implement and use.  Whether it adequately met those
> >criter= ia is being questioned.  From my perspective it looks like
> = >draft-yadawad-disman-ahcf-00.txt presents another factoring of
> = >the problem.  I am far from convinced that it is *the* solution, = but
> >(as WG chair) I think it's appropriate to include it in = the
> discussion
> >of whether the expression MIB requires = some re-thinking.
> >
> >Randy
> Regards,
> = /david t. perkins
>
>
>

--=__PartCDECD9C0.2__=-- From disman-admin@ietf.org Thu Mar 18 05:45:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02066 for ; Thu, 18 Mar 2004 05:45:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3v1L-0002CR-3k; Thu, 18 Mar 2004 05:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3v0c-00028k-GD for disman@optimus.ietf.org; Thu, 18 Mar 2004 05:44:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01952 for ; Thu, 18 Mar 2004 05:44:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3v0Z-0006rd-00 for disman@ietf.org; Thu, 18 Mar 2004 05:44:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3uzj-0006ks-00 for disman@ietf.org; Thu, 18 Mar 2004 05:43:25 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1B3uyx-0006W3-00 for disman@ietf.org; Thu, 18 Mar 2004 05:42:35 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Thu, 18 Mar 2004 03:42:06 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: , , Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartEECFFAE3.1__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 03:41:55 -0700 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartEECFFAE3.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Dan, As mentioned in the draft following are the features Simple configuration and Instance Management : suppose if the user wants to configure history collection for all the instances of the columnar oid, using RMON object definition the user has to configure for each instance individually where as using our object definition, it is just one configuration setting. It has to be noted here that the user has the option of applying same configuration settings to all the instances or can fine tune the configuration setting for desired instances. RMON2 user history object definition does not take care of newly added and deleted instances and hence if the new instances are added the user has to configure for the new instances manually. Consistent reference to the resource: History collection activity can be for a long duration and hence it is important to provide consistent reference of collected history to the underlying physical media. This kind of feature is seen only interface group however if user needs this kind of ability for any oid that is being trended. Instance Filtering Istance filtering is not available in RMON user history mib. Threshold Monitoring Yes, threshold monitoring is available in the alarm table but if user wants a complete solution of history collection and threshold monitoring in a single object definition, our mib definition provides the solution. Dan, see it this way, the above mentioned features are seen in many mibs but user needs one mib which has all required features as otherwise it is difficult for the user to implement multiple mibs for one problem. Regards, Shailaja. >>> "Romascanu, Dan (Dan)" 3/18/2004 12:48:59 AM >>> I will repeat a comment that I made during the meeting in Seoul. I think that all, or almost all that is being defined in this MIB module can already be performed - some features even in multiple ways - by agents that implement existing MIB modules like RMON, Events MIB, and Alarm MIB. I think that it would help the discussion if the authors could shortly describe what is the added value that this MIB module would bring, and what operations/management functions this MIB module provides that are not covered by existing MIB modules. Thanks and Regards, Dan > -----Original Message----- > From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On > Behalf Of Randy Presuhn > Sent: 17 March, 2004 8:55 PM > To: Disman (E-mail) > Subject: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt > > > Hi - > > I'd welcome discussion of this on the disman mailing list. > I think it's relevant to the question of what to do about the > expression and event MIBs. > > Randy > > > From: > > To: > > Sent: Wednesday, March 17, 2004 8:10 AM > > Subject: I-D ACTION:draft-yadawad-disman-ahcf-00.txt > > > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > > > > Title : Advanced History Collection Framework > > Author(s) : S. Yadawad, H. Kumar, H. Yamijala, R. Shekar > > Filename : draft-yadawad-disman-ahcf-00.txt > > Pages : 47 > > Date : 2004-3-17 > > > > This draft defines a portion of the Management Information Base for > > use with network management protocols in TCP/IP based > Internets. In > > particular, it defines objects for configuring and > controlling the > > history collection of user specified Data, which is an ASN.1 > > INTEGER based object. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-yadawad-disman-ahcf-00.txt > > > ... > > > > --=__PartEECFFAE3.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dan,
 
As mentioned in the draft following are the features
 
Simple configuration and Instance Management : suppose if the user = wants to configure history collection for all the instances of the = columnar oid, using RMON object definition the  user has to configure = for each instance individually where as using our object definition, it is = just one configuration setting.
 
It has to be noted here that the user has the option of applying same = configuration settings to all the instances or can fine tune the configurat= ion setting for desired instances.
 
RMON2 user history object definition does not take care of newly = added and deleted instances and hence if the new instances are added the = user has to configure for the new instances manually.
 
Consistent reference to the resource:
History collection activity can be for a long duration and hence it = is important to provide consistent reference of collected history to the = underlying physical media. This kind of feature is seen only interface = group however if user needs this kind of ability for any oid that is = being trended.
 
 
Instance Filtering
 
Istance filtering is not available in RMON user history mib.
 
Threshold Monitoring
Yes, threshold monitoring is available in the alarm table but if user = wants a complete solution of history collection and threshold = monitoring in a single object definition, our mib definition provides the = solution.
 
Dan, see it this way, the above mentioned  features are = seen in many mibs but user needs one mib which has all required features = as otherwise it is difficult for the user to implement multiple mibs for = one problem.
 
Regards,
Shailaja.
 
 
>>> "Romascanu, Dan (Dan)" <dromasca@avaya.com> = 3/18/2004 12:48:59 AM >>>
I will repeat a comment that I made during = the meeting in Seoul. I think that all, or almost all that is being = defined in this MIB module can already be performed - some features even = in multiple ways - by agents that implement existing MIB modules like = RMON, Events MIB, and Alarm MIB. I think that it would help the discussion = if the authors could shortly describe what is the added value that this = MIB module would bring, and what operations/management functions this MIB = module provides that are not covered by existing MIB modules.  =

Thanks and Regards,

Dan



> -----Original = Message-----
> From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On
> Behalf Of = Randy Presuhn
> Sent: 17 March, 2004 8:55 PM
> To: Disman = (E-mail)
> Subject: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf= -00.txt
>
>
> Hi -
>
> I'd welcome = discussion of this on the disman mailing list.
> I think it's = relevant to the question of what to do about the
> expression and = event MIBs.
>
> Randy
>
> > From: <Internet= -Drafts@ietf.org>
> > To: <IETF-Announce:>
> > = Sent: Wednesday, March 17, 2004 8:10 AM
> > Subject: I-D = ACTION:draft-yadawad-disman-ahcf-00.txt
> >
>
> > = A New Internet-Draft is available from the on-line
> Internet-Drafts= directories.
> >
> >
> > Title : Advanced = History Collection Framework
> > Author(s) : S. Yadawad, H. = Kumar, H. Yamijala, R. Shekar
> > Filename : draft-yadawad-disman-= ahcf-00.txt
> > Pages : 47
> > Date : 2004-3-17
> = >
> > This draft defines a portion of the Management Informatio= n Base for
> >     use with network management= protocols in TCP/IP based
> Internets. In
> >  &= nbsp;  particular, it defines objects for configuring and
> = controlling the
> >     history collection of = user specified Data, which is an ASN.1
> >    = INTEGER based object.
> >
> > A URL for this Internet-Dr= aft is:
> > http://www.ietf.org/internet-drafts/draft-yadawa= d-disman-ahcf-00.txt
> >
> ...
>
> =
>
>

--=__PartEECFFAE3.1__=-- From exim@www1.ietf.org Thu Mar 18 05:45:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02099 for ; Thu, 18 Mar 2004 05:45:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3v1Y-0002Fd-JF for disman-archive@odin.ietf.org; Thu, 18 Mar 2004 05:45:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IAjGGT008647 for disman-archive@odin.ietf.org; Thu, 18 Mar 2004 05:45:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3v1Y-0002FO-5t for disman-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 05:45:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02052 for ; Thu, 18 Mar 2004 05:45:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3v1U-0006yc-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 05:45:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3v0d-0006sO-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 05:44:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3v0I-0006lr-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 05:43:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3v0L-000230-38; Thu, 18 Mar 2004 05:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uze-00022Y-Rv for disman@optimus.ietf.org; Thu, 18 Mar 2004 05:43:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01873 for ; Thu, 18 Mar 2004 05:43:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3uzb-0006jf-00 for disman@ietf.org; Thu, 18 Mar 2004 05:43:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3uyc-0006bl-00 for disman@ietf.org; Thu, 18 Mar 2004 05:42:15 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1B3uxo-0006OJ-00 for disman@ietf.org; Thu, 18 Mar 2004 05:41:24 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Thu, 18 Mar 2004 03:40:56 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: , Subject: Re: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartBE9FAAB3.1__=" Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 03:40:35 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartBE9FAAB3.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit David, You have correctly captured the proposed features in our draft. It will be great to fix all the definitions problems that you foresee. Regards, Shailaja. >>> "David T. Perkins" 3/18/2004 2:13:11 AM >>> HI, I just quickly scanned the document. It does provide in creative ways features not found in other MIB modules. These include: 1) automatic inclusion of values of new instances that come into existence after control entry creation 2) filtering based on instance 3) identification of instances via "alternative indices" The definitions do have problems, maybe all are fixable. And it might be easy to extend it to provide additional benefits at a low cost. To support it might be pretty expensive in memory and CPU processing, and it appears to be best matched for monitoring "hosts" or "big routers". At 12:14 PM 3/17/2004 -0800, Randy Presuhn wrote: >Hi - > >(as technical contributor) > >> From: "Romascanu, Dan (Dan)" >> To: "Randy Presuhn" ; "Disman (E-mail)" >> Sent: Wednesday, March 17, 2004 11:18 AM >> Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt >> > >> I will repeat a comment that I made during the meeting in Seoul. I think that all, >> or almost all that is being defined in this MIB module can already be performed >> - some features even in multiple ways - by agents that implement existing MIB >> modules like RMON, Events MIB, and Alarm MIB. > >This seems to be the case. I think the question raised is one of usability, >that is, how difficult is it to configure these existing MIBs to these things. >This is another facet of the old scripting vs. expression vs. special-purpose >MIB debate, but also ties in with the questions Juergen raised in his >overview of http://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt >at the session in Seoul. > >> I think that it would help the discussion if the authors could shortly describe >> what is the added value that this MIB module would bring, and what > >Agreed. > >> operations/management functions this MIB module provides that are >> not covered by existing MIB modules. >... > >To the extent that the script MIB supports languages that are Turing >complete, one could reasonably argue that all other MIBs are superfluous. >Of course, a problem with such a line of argument would be the >amount of pain required to use such a system. That is why the expression >MIB and the script MIB were both put out as Proposed Standards. > >The motivation for the expression MIB was that it was supposed to be >simpler to implement and use. Whether it adequately met those >criteria is being questioned. From my perspective it looks like >draft-yadawad-disman-ahcf-00.txt presents another factoring of >the problem. I am far from convinced that it is *the* solution, but >(as WG chair) I think it's appropriate to include it in the discussion >of whether the expression MIB requires some re-thinking. > >Randy Regards, /david t. perkins --=__PartBE9FAAB3.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
David,
 
You have correctly captured the proposed features in our draft.
 
It will be great to fix all the definitions problems that you = foresee.
 
Regards,
Shailaja.

>>> "David T. Perkins" <dperkins@dsperkins.com> = 3/18/2004 2:13:11 AM >>>
HI,

I just quickly scanned the = document. It does provide in creative ways
features not found in other = MIB modules. These include:
  1) automatic inclusion of values of = new instances that come
     into existence after = control entry creation
  2) filtering based on instance
  = 3) identification of instances via "alternative indices"

The = definitions do have problems, maybe all are fixable. And it
might be = easy to extend it to provide additional benefits at a
low cost.

T= o support it might be pretty expensive in memory and CPU processing,
and= it appears to be best matched for monitoring "hosts" or
"big routers".<= BR>
At 12:14 PM 3/17/2004 -0800, Randy Presuhn wrote:
>Hi = -
>
>(as technical contributor)
>
>> From: = "Romascanu, Dan (Dan)" <dromasca@avaya.com>
>> To: "Randy = Presuhn" <randy_presuhn@mindspring.com>; "Disman (E-mail)" <disman= @ietf.org>
>> Sent: Wednesday, March 17, 2004 11:18 AM
>&= gt; Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt>>
>
>> I will repeat a comment that I made during = the meeting in Seoul. I think that all,
>> or almost all that is = being defined in this MIB module can already be performed
>> - = some features even in multiple ways - by agents that implement existing = MIB
>> modules like RMON, Events MIB, and Alarm MIB.
>
&g= t;This seems to be the case.  I think the question raised is one of = usability,
>that is, how difficult is it to configure these existing = MIBs to these things.
>This is another facet of the old scripting = vs. expression vs. special-purpose
>MIB debate, but also ties in = with the questions Juergen raised in his
>overview of  h= ttp://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt
>= at the session in Seoul.
>
>> I think that it would help = the discussion if the authors could shortly describe
>> what is = the added value that this MIB module would bring, and what
>
>A= greed.
>
>> operations/management functions this MIB module = provides that are
>> not covered by existing MIB modules.
>.= ..
>
>To the extent that the script MIB supports languages = that are Turing
>complete, one could reasonably argue that all other = MIBs are superfluous.
>Of course, a problem with such a line of = argument would be the
>amount of pain required to use such a = system.  That is why the expression
>MIB and the script MIB = were both put out as Proposed Standards.
>
>The motivation for = the expression MIB was that it was supposed to be
>simpler to = implement and use.  Whether it adequately met those
>criteria = is being questioned.  From my perspective it looks like
>draft-y= adawad-disman-ahcf-00.txt presents another factoring of
>the = problem.  I am far from convinced that it is *the* solution, = but
>(as WG chair) I think it's appropriate to include it in the = discussion
>of whether the expression MIB requires some re-thinking.<= BR>>
>Randy
Regards,
/david t. perkins


--=__PartBE9FAAB3.1__=-- From exim@www1.ietf.org Thu Mar 18 05:46:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02155 for ; Thu, 18 Mar 2004 05:46:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3v2Y-0002JW-IE for disman-archive@odin.ietf.org; Thu, 18 Mar 2004 05:46:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IAkIBs008893 for disman-archive@odin.ietf.org; Thu, 18 Mar 2004 05:46:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3v2X-0002JM-13 for disman-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 05:46:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02128 for ; Thu, 18 Mar 2004 05:46:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3v2T-000750-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 05:46:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3v1a-0006zF-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 05:45:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3v1I-0006tE-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 05:45:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3v1L-0002CR-3k; Thu, 18 Mar 2004 05:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3v0c-00028k-GD for disman@optimus.ietf.org; Thu, 18 Mar 2004 05:44:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01952 for ; Thu, 18 Mar 2004 05:44:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3v0Z-0006rd-00 for disman@ietf.org; Thu, 18 Mar 2004 05:44:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3uzj-0006ks-00 for disman@ietf.org; Thu, 18 Mar 2004 05:43:25 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1B3uyx-0006W3-00 for disman@ietf.org; Thu, 18 Mar 2004 05:42:35 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Thu, 18 Mar 2004 03:42:06 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: , , Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartEECFFAE3.1__=" Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 03:41:55 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartEECFFAE3.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Dan, As mentioned in the draft following are the features Simple configuration and Instance Management : suppose if the user wants to configure history collection for all the instances of the columnar oid, using RMON object definition the user has to configure for each instance individually where as using our object definition, it is just one configuration setting. It has to be noted here that the user has the option of applying same configuration settings to all the instances or can fine tune the configuration setting for desired instances. RMON2 user history object definition does not take care of newly added and deleted instances and hence if the new instances are added the user has to configure for the new instances manually. Consistent reference to the resource: History collection activity can be for a long duration and hence it is important to provide consistent reference of collected history to the underlying physical media. This kind of feature is seen only interface group however if user needs this kind of ability for any oid that is being trended. Instance Filtering Istance filtering is not available in RMON user history mib. Threshold Monitoring Yes, threshold monitoring is available in the alarm table but if user wants a complete solution of history collection and threshold monitoring in a single object definition, our mib definition provides the solution. Dan, see it this way, the above mentioned features are seen in many mibs but user needs one mib which has all required features as otherwise it is difficult for the user to implement multiple mibs for one problem. Regards, Shailaja. >>> "Romascanu, Dan (Dan)" 3/18/2004 12:48:59 AM >>> I will repeat a comment that I made during the meeting in Seoul. I think that all, or almost all that is being defined in this MIB module can already be performed - some features even in multiple ways - by agents that implement existing MIB modules like RMON, Events MIB, and Alarm MIB. I think that it would help the discussion if the authors could shortly describe what is the added value that this MIB module would bring, and what operations/management functions this MIB module provides that are not covered by existing MIB modules. Thanks and Regards, Dan > -----Original Message----- > From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On > Behalf Of Randy Presuhn > Sent: 17 March, 2004 8:55 PM > To: Disman (E-mail) > Subject: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt > > > Hi - > > I'd welcome discussion of this on the disman mailing list. > I think it's relevant to the question of what to do about the > expression and event MIBs. > > Randy > > > From: > > To: > > Sent: Wednesday, March 17, 2004 8:10 AM > > Subject: I-D ACTION:draft-yadawad-disman-ahcf-00.txt > > > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > > > > > Title : Advanced History Collection Framework > > Author(s) : S. Yadawad, H. Kumar, H. Yamijala, R. Shekar > > Filename : draft-yadawad-disman-ahcf-00.txt > > Pages : 47 > > Date : 2004-3-17 > > > > This draft defines a portion of the Management Information Base for > > use with network management protocols in TCP/IP based > Internets. In > > particular, it defines objects for configuring and > controlling the > > history collection of user specified Data, which is an ASN.1 > > INTEGER based object. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-yadawad-disman-ahcf-00.txt > > > ... > > > > --=__PartEECFFAE3.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dan,
 
As mentioned in the draft following are the features
 
Simple configuration and Instance Management : suppose if the user = wants to configure history collection for all the instances of the = columnar oid, using RMON object definition the  user has to configure = for each instance individually where as using our object definition, it is = just one configuration setting.
 
It has to be noted here that the user has the option of applying same = configuration settings to all the instances or can fine tune the configurat= ion setting for desired instances.
 
RMON2 user history object definition does not take care of newly = added and deleted instances and hence if the new instances are added the = user has to configure for the new instances manually.
 
Consistent reference to the resource:
History collection activity can be for a long duration and hence it = is important to provide consistent reference of collected history to the = underlying physical media. This kind of feature is seen only interface = group however if user needs this kind of ability for any oid that is = being trended.
 
 
Instance Filtering
 
Istance filtering is not available in RMON user history mib.
 
Threshold Monitoring
Yes, threshold monitoring is available in the alarm table but if user = wants a complete solution of history collection and threshold = monitoring in a single object definition, our mib definition provides the = solution.
 
Dan, see it this way, the above mentioned  features are = seen in many mibs but user needs one mib which has all required features = as otherwise it is difficult for the user to implement multiple mibs for = one problem.
 
Regards,
Shailaja.
 
 
>>> "Romascanu, Dan (Dan)" <dromasca@avaya.com> = 3/18/2004 12:48:59 AM >>>
I will repeat a comment that I made during = the meeting in Seoul. I think that all, or almost all that is being = defined in this MIB module can already be performed - some features even = in multiple ways - by agents that implement existing MIB modules like = RMON, Events MIB, and Alarm MIB. I think that it would help the discussion = if the authors could shortly describe what is the added value that this = MIB module would bring, and what operations/management functions this MIB = module provides that are not covered by existing MIB modules.  =

Thanks and Regards,

Dan



> -----Original = Message-----
> From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On
> Behalf Of = Randy Presuhn
> Sent: 17 March, 2004 8:55 PM
> To: Disman = (E-mail)
> Subject: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf= -00.txt
>
>
> Hi -
>
> I'd welcome = discussion of this on the disman mailing list.
> I think it's = relevant to the question of what to do about the
> expression and = event MIBs.
>
> Randy
>
> > From: <Internet= -Drafts@ietf.org>
> > To: <IETF-Announce:>
> > = Sent: Wednesday, March 17, 2004 8:10 AM
> > Subject: I-D = ACTION:draft-yadawad-disman-ahcf-00.txt
> >
>
> > = A New Internet-Draft is available from the on-line
> Internet-Drafts= directories.
> >
> >
> > Title : Advanced = History Collection Framework
> > Author(s) : S. Yadawad, H. = Kumar, H. Yamijala, R. Shekar
> > Filename : draft-yadawad-disman-= ahcf-00.txt
> > Pages : 47
> > Date : 2004-3-17
> = >
> > This draft defines a portion of the Management Informatio= n Base for
> >     use with network management= protocols in TCP/IP based
> Internets. In
> >  &= nbsp;  particular, it defines objects for configuring and
> = controlling the
> >     history collection of = user specified Data, which is an ASN.1
> >    = INTEGER based object.
> >
> > A URL for this Internet-Dr= aft is:
> > http://www.ietf.org/internet-drafts/draft-yadawa= d-disman-ahcf-00.txt
> >
> ...
>
> =
>
>

--=__PartEECFFAE3.1__=-- From disman-admin@ietf.org Thu Mar 18 06:30:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01907 for ; Thu, 18 Mar 2004 05:43:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uzP-0001zW-UU; Thu, 18 Mar 2004 05:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uym-0001yI-1n for disman@optimus.ietf.org; Thu, 18 Mar 2004 05:42:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01849 for ; Thu, 18 Mar 2004 05:42:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3uyi-0006cW-00 for disman@ietf.org; Thu, 18 Mar 2004 05:42:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3uxv-0006VJ-00 for disman@ietf.org; Thu, 18 Mar 2004 05:41:32 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1B3uxL-0006Mk-00 for disman@ietf.org; Thu, 18 Mar 2004 05:40:55 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Thu, 18 Mar 2004 03:40:21 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: , , Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part95B48198.1__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 03:40:08 -0700 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part95B48198.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Dan, >I was not going that far, and actually I did not have the expression MIB in mind. Expression MIB can be modified based on some of our features. >What I am seeing are mechanisms like RMON alarm and usrHistory being reinvented, and >objects like ituSeverity from the Alarm MIB being duplicated. you are correct that our draft contains object definition similar to that of RMON alarm and usrHistory but with additional features and changes. Regards, Shailaja. --=__Part95B48198.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dan,
 
>I was not going = that far, and actually I did not have the expression MIB in mind. =
Expression MIB can be modified based on some of our features.

>What I am seeing are mechanisms like RMON alarm and usrHistory= being reinvented, and >objects like ituSeverity from the Alarm MIB = being duplicated.

you are correct that our draft contains object = definition similar to that of  RMON alarm and usrHistory but = with additional features and changes.
 
Regards,
Shailaja.
--=__Part95B48198.1__=-- From exim@www1.ietf.org Thu Mar 18 06:30:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02001 for ; Thu, 18 Mar 2004 05:44:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3v0i-00029Z-Bb for disman-archive@odin.ietf.org; Thu, 18 Mar 2004 05:44:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IAiOCm008270 for disman-archive@odin.ietf.org; Thu, 18 Mar 2004 05:44:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3v0h-00029J-9x for disman-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 05:44:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01980 for ; Thu, 18 Mar 2004 05:44:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3v0d-0006sI-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 05:44:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3uzr-0006li-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 05:43:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3uzP-0006dv-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 05:43:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uzP-0001zO-EC; Thu, 18 Mar 2004 05:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3uyl-0001yD-Il for disman@optimus.ietf.org; Thu, 18 Mar 2004 05:42:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01846 for ; Thu, 18 Mar 2004 05:42:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3uyh-0006cQ-00 for disman@ietf.org; Thu, 18 Mar 2004 05:42:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3uxu-0006VB-00 for disman@ietf.org; Thu, 18 Mar 2004 05:41:31 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1B3uxL-0006Me-00 for disman@ietf.org; Thu, 18 Mar 2004 05:40:55 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Thu, 18 Mar 2004 03:40:21 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: , Subject: Re: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part6243766F.0__=" Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 03:39:59 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part6243766F.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Randy, >This seems to be the case. I think the question raised is one of usability, >that is, how difficult is it to configure these existing MIBs to these things. >This is another facet of the old scripting vs. expression vs. special-purpose >MIB debate, but also ties in with the questions Juergen raised in his >overview of http://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt >at the session in Seoul. Yes, usability is one of the motivation for our draft. >To the extent that the script MIB supports languages that are Turing >complete, one could reasonably argue that all other MIBs are superfluous. >Of course, a problem with such a line of argument would be the >amount of pain required to use such a system. That is why the expression >MIB and the script MIB were both put out as Proposed Standards. How true. It is not possible restrict the user to find solution for the problem with the existing MIB definitions. >The motivation for the expression MIB was that it was supposed to be >simpler to implement and use. Whether it adequately met those >criteria is being questioned. From my perspective it looks like >draft-yadawad-disman-ahcf-00.txt presents another factoring of >the problem. Thanks. Regards, Shailaja. --=__Part6243766F.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Randy,

 
>This seems to be the case.  I think = the question raised is one of usability,
>that is, how difficult is = it to configure these existing MIBs to these things.
>This is = another facet of the old scripting vs. expression vs. special-purpose
&g= t;MIB debate, but also ties in with the questions Juergen raised in = his
>overview of  http://www.ietf.org/internet-drafts/draft-nu= nzi-check-mib-00.txt
>at the session in Seoul.
Yes, usability is one of the motivation for = our draft.
 
>To the extent that the script MIB = supports languages that are Turing
>complete, one could reasonably = argue that all other MIBs are superfluous.
>Of course, a problem = with such a line of argument would be the
>amount of pain required = to use such a system.  That is why the expression
>MIB and the = script MIB were both put out as Proposed Standards.
How true. It is not possible restrict the = user to find solution for the problem with the
existing MIB definitions.
 
>The motivation for the expression MIB = was that it was supposed to be
>simpler to implement and use.  = Whether it adequately met those
>criteria is being questioned.  = From exim@www1.ietf.org Thu Mar 18 06:32:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02154 for ; Thu, 18 Mar 2004 05:46:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3v2Y-0002JX-Ib for disman-archive@odin.ietf.org; Thu, 18 Mar 2004 05:46:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IAkIS0008886 for disman-archive@odin.ietf.org; Thu, 18 Mar 2004 05:46:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3v2W-0002JF-80 for disman-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 05:46:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02124 for ; Thu, 18 Mar 2004 05:46:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3v2S-00074v-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 05:46:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3v1Z-0006z7-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 05:45:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3v1I-0006tC-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 05:45:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3v1J-0002C8-Lw; Thu, 18 Mar 2004 05:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3v0Z-00027l-Af for disman@optimus.ietf.org; Thu, 18 Mar 2004 05:44:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01943 for ; Thu, 18 Mar 2004 05:44:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3v0V-0006rA-00 for disman@ietf.org; Thu, 18 Mar 2004 05:44:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3uzW-0006j9-00 for disman@ietf.org; Thu, 18 Mar 2004 05:43:11 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1B3uyX-0006Vs-00 for disman@ietf.org; Thu, 18 Mar 2004 05:42:09 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Thu, 18 Mar 2004 03:41:41 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: , , Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartCDECD9C0.2__=" Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 03:41:20 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartCDECD9C0.2__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Dan, Our main objective was easy and automatic configuration. In case of usr history group, history collection can be configured for any number of oids of any table for a given control entry, this will break our design as configuration settings become specific to particular tables. This was one main reason as why we did not propose extending the usr history group. Dan, the main thing is easy configuration and also let user configure only for the desired number of instances which in turn saves the resource. Regards, Shailaja. >>> "Romascanu, Dan (Dan)" 3/18/2004 4:29:51 AM >>> David, There are a lot of creative ideas indeed. However, I do not understand yet why the design approach that was taken is better than extending the existing RMON usrHistory and Alarm mechanisms with the columns and instance filtering mechanisms. Id I am not mistaken such mechanisms were discussed, and rejected, or delayed by the time RMON2 was developed. Let us not forget that RMON agent implementations are widely deployed and understood and some vendors may have implemented such mechanisms already. The argumentation in the I-D is quite extensive, but I am not convinced that this solution is more efficient or saves agent resources. Regards, Dan > -----Original Message----- > From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On > Behalf Of David T. Perkins > Sent: 17 March, 2004 10:43 PM > To: disman@ietf.org > Subject: Re: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt > > > HI, > > I just quickly scanned the document. It does provide in creative ways > features not found in other MIB modules. These include: > 1) automatic inclusion of values of new instances that come > into existence after control entry creation > 2) filtering based on instance > 3) identification of instances via "alternative indices" > > The definitions do have problems, maybe all are fixable. And it > might be easy to extend it to provide additional benefits at a > low cost. > > To support it might be pretty expensive in memory and CPU processing, > and it appears to be best matched for monitoring "hosts" or > "big routers". > > At 12:14 PM 3/17/2004 -0800, Randy Presuhn wrote: > >Hi - > > > >(as technical contributor) > > > >> From: "Romascanu, Dan (Dan)" > >> To: "Randy Presuhn" ; > "Disman (E-mail)" > >> Sent: Wednesday, March 17, 2004 11:18 AM > >> Subject: RE: [Disman] Fw: I-D > ACTION:draft-yadawad-disman-ahcf-00.txt > >> > > > >> I will repeat a comment that I made during the meeting in > Seoul. I think that all, > >> or almost all that is being defined in this MIB module can > already be performed > >> - some features even in multiple ways - by agents that > implement existing MIB > >> modules like RMON, Events MIB, and Alarm MIB. > > > >This seems to be the case. I think the question raised is > one of usability, > >that is, how difficult is it to configure these existing > MIBs to these things. > >This is another facet of the old scripting vs. expression > vs. special-purpose > >MIB debate, but also ties in with the questions Juergen raised in his > >overview of > http://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt > >at the session in Seoul. > > > >> I think that it would help the discussion if the authors > could shortly describe > >> what is the added value that this MIB module would bring, and what > > > >Agreed. > > > >> operations/management functions this MIB module provides that are > >> not covered by existing MIB modules. > >... > > > >To the extent that the script MIB supports languages that are Turing > >complete, one could reasonably argue that all other MIBs are > superfluous. > >Of course, a problem with such a line of argument would be the > >amount of pain required to use such a system. That is why > the expression > >MIB and the script MIB were both put out as Proposed Standards. > > > >The motivation for the expression MIB was that it was supposed to be > >simpler to implement and use. Whether it adequately met those > >criteria is being questioned. From my perspective it looks like > >draft-yadawad-disman-ahcf-00.txt presents another factoring of > >the problem. I am far from convinced that it is *the* solution, but > >(as WG chair) I think it's appropriate to include it in the > discussion > >of whether the expression MIB requires some re-thinking. > > > >Randy > Regards, > /david t. perkins > > > --=__PartCDECD9C0.2__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dan,
 
Our main objective was easy and automatic configuration. In case of = usr history group, history collection can be configured for any number of = oids of any table for a given control entry, this will break our design as = configuration settings become specific to particular tables. This was one = main reason as why we did not propose extending the usr history group.
 
Dan, the main thing is easy configuration and also let user = configure only for the desired number of instances which in turn saves the = resource.
 
Regards,
Shailaja.
 

>>> "Romascanu, Dan (Dan)" <dromasca@avaya.com> = 3/18/2004 4:29:51 AM >>>
David,

There are a lot of creative = ideas indeed. However, I do not understand yet why the design approach = that was taken is better than extending the existing RMON usrHistory and = Alarm mechanisms with the columns and instance filtering mechanisms. Id I = am not mistaken such mechanisms were discussed, and rejected, or delayed = by the time RMON2 was developed.

Let us not forget that RMON agent = implementations are widely deployed and understood and some vendors may = have implemented such mechanisms already. The argumentation in the I-D is = quite extensive, but I am not convinced that this solution is more = efficient or saves agent resources.

Regards,

Dan


<= BR>> -----Original Message-----
> From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On
> Behalf Of David T. Perkins
> Sent: 17 March, 2004 10:43 = PM
> To: disman@ietf.org
> Subject: Re: [Disman] Fw: I-D = ACTION:draft-yadawad-disman-ahcf-00.txt
>
>
> = HI,
>
> I just quickly scanned the document. It does provide = in creative ways
> features not found in other MIB modules. These = include:
>   1) automatic inclusion of values of new = instances that come
>      into existence = after control entry creation
>   2) filtering based on = instance
>   3) identification of instances via "alternativ= e indices"
>
> The definitions do have problems, maybe all = are fixable. And it
> might be easy to extend it to provide = additional benefits at a
> low cost.
>
> To support it = might be pretty expensive in memory and CPU processing,
> and it = appears to be best matched for monitoring "hosts" or
> "big = routers".
>
> At 12:14 PM 3/17/2004 -0800, Randy Presuhn = wrote:
> >Hi -
> >
> >(as technical contributor)=
> >
> >> From: "Romascanu, Dan (Dan)" <dromasca@av= aya.com>
> >> To: "Randy Presuhn" <randy_presuhn@mindspri= ng.com>;
> "Disman (E-mail)" <disman@ietf.org>
> = >> Sent: Wednesday, March 17, 2004 11:18 AM
> >> = Subject: RE: [Disman] Fw: I-D
> ACTION:draft-yadawad-disman-ahcf-00.= txt
> >>
> >
> >> I will repeat a comment = that I made during the meeting in
> Seoul. I think that all,
>= >> or almost all that is being defined in this MIB module can =
> already be performed
> >> - some features even in = multiple ways - by agents that
> implement existing MIB
> = >> modules like RMON, Events MIB, and Alarm MIB.
> >
>= >This seems to be the case.  I think the question raised is =
> one of usability,
> >that is, how difficult is it to = configure these existing
> MIBs to these things.
> >This = is another facet of the old scripting vs. expression
> vs. = special-purpose
> >MIB debate, but also ties in with the = questions Juergen raised in his
> >overview of 
> h= ttp://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt
>= >at the session in Seoul.
> >
> >> I think that = it would help the discussion if the authors
> could shortly = describe
> >> what is the added value that this MIB module = would bring, and what
> >
> >Agreed.
> >
>= >> operations/management functions this MIB module provides that = are
> >> not covered by existing MIB modules.
> = >...
> >
> >To the extent that the script MIB = supports languages that are Turing
> >complete, one could = reasonably argue that all other MIBs are
> superfluous.
> = >Of course, a problem with such a line of argument would be the
> = >amount of pain required to use such a system.  That is why =
> the expression
> >MIB and the script MIB were both put = out as Proposed Standards.
> >
> >The motivation for the = expression MIB was that it was supposed to be
> >simpler to = implement and use.  Whether it adequately met those
> >criter= ia is being questioned.  From my perspective it looks like
> = >draft-yadawad-disman-ahcf-00.txt presents another factoring of
> = >the problem.  I am far from convinced that it is *the* solution, = but
> >(as WG chair) I think it's appropriate to include it in = the
> discussion
> >of whether the expression MIB requires = some re-thinking.
> >
> >Randy
> Regards,
> = /david t. perkins
>
>
>

--=__PartCDECD9C0.2__=-- From disman-admin@ietf.org Thu Mar 18 09:14:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11994 for ; Thu, 18 Mar 2004 09:14:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yHZ-0000jM-0P; Thu, 18 Mar 2004 09:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yHD-0000hm-FB for disman@optimus.ietf.org; Thu, 18 Mar 2004 09:13:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11961 for ; Thu, 18 Mar 2004 09:13:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3yHB-0002wq-00 for disman@ietf.org; Thu, 18 Mar 2004 09:13:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3yGF-0002of-00 for disman@ietf.org; Thu, 18 Mar 2004 09:12:40 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1B3yFj-0002g3-00; Thu, 18 Mar 2004 09:12:07 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2IEB5gL020156; Thu, 18 Mar 2004 09:11:05 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2IEB1gL020026; Thu, 18 Mar 2004 09:11:02 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40CF2.FC28E677" Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Message-ID: Thread-Topic: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Thread-Index: AcQM1izBngl1OE8fRBK6xxd6vjGfiAAGHpXw From: "Romascanu, Dan (Dan)" To: "Shailaja Yadawad" , , Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 16:12:02 +0200 This is a multi-part message in MIME format. ------_=_NextPart_001_01C40CF2.FC28E677 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (sorry for the cross-posting, but I think that this conversation is = relevant for rmonmib) =20 Shailadja, =20 I have read the draft carefully, I think that I understand it better = now, and I appreciate what you are trying to achieve. I should point = however, that the problems that you are dealing with have solutions in = other MIB modules, sometimes even multiple solutions as you are yourself = pointing. An optimization may be a good thing for a certain class of = applications and devices, but a sound discussion is needed to prove that = this is an important enough problem to deserve a new piece of = standardization in the IETF. =20 What do you suggest that we do with this? Are you suggesting that we = deprecate the relevant MIB groups in RMON and RMON-2 and replace them by = new optimized MIB groups on the lines of your proposal? Or should we = standardize a new method for user history with instance filtering, and = applying alarms to history with lesser MIB objects in addition to = existing RMON standards? =20 =20 Regards, Dan -----Original Message----- From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On Behalf Of = Shailaja Yadawad Sent: 18 March, 2004 12:42 PM To: Romascanu, Dan (Dan); disman@ietf.org; randy_presuhn@mindspring.com Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Dan, =20 As mentioned in the draft following are the features=20 =20 Simple configuration and Instance Management : suppose if the user wants = to configure history collection for all the instances of the columnar = oid, using RMON object definition the user has to configure for each = instance individually where as using our object definition, it is just = one configuration setting. =20 It has to be noted here that the user has the option of applying same = configuration settings to all the instances or can fine tune the = configuration setting for desired instances. =20 RMON2 user history object definition does not take care of newly added = and deleted instances and hence if the new instances are added the user = has to configure for the new instances manually. =20 Consistent reference to the resource: History collection activity can be for a long duration and hence it is = important to provide consistent reference of collected history to the = underlying physical media. This kind of feature is seen only interface = group however if user needs this kind of ability for any oid that is = being trended. =20 =20 Instance Filtering =20 Istance filtering is not available in RMON user history mib. =20 Threshold Monitoring Yes, threshold monitoring is available in the alarm table but if user = wants a complete solution of history collection and threshold monitoring = in a single object definition, our mib definition provides the solution. =20 Dan, see it this way, the above mentioned features are seen in many = mibs but user needs one mib which has all required features as otherwise = it is difficult for the user to implement multiple mibs for one problem. =20 Regards, Shailaja. =20 =20 >>> "Romascanu, Dan (Dan)" 3/18/2004 12:48:59 AM = >>> I will repeat a comment that I made during the meeting in Seoul. I think = that all, or almost all that is being defined in this MIB module can = already be performed - some features even in multiple ways - by agents = that implement existing MIB modules like RMON, Events MIB, and Alarm = MIB. I think that it would help the discussion if the authors could = shortly describe what is the added value that this MIB module would = bring, and what operations/management functions this MIB module provides = that are not covered by existing MIB modules. =20 Thanks and Regards, Dan > -----Original Message----- > From: disman-admin@ietf.org [ mailto:disman-admin@ietf.org]On=20 > Behalf Of Randy Presuhn > Sent: 17 March, 2004 8:55 PM > To: Disman (E-mail) > Subject: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt >=20 >=20 > Hi - >=20 > I'd welcome discussion of this on the disman mailing list. > I think it's relevant to the question of what to do about the > expression and event MIBs. >=20 > Randy >=20 > > From: > > To: > > Sent: Wednesday, March 17, 2004 8:10 AM > > Subject: I-D ACTION:draft-yadawad-disman-ahcf-00.txt > > >=20 > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > > > > > > Title : Advanced History Collection Framework > > Author(s) : S. Yadawad, H. Kumar, H. Yamijala, R. Shekar > > Filename : draft-yadawad-disman-ahcf-00.txt > > Pages : 47 > > Date : 2004-3-17 > > > > This draft defines a portion of the Management Information Base for > > use with network management protocols in TCP/IP based=20 > Internets. In > > particular, it defines objects for configuring and=20 > controlling the > > history collection of user specified Data, which is an ASN.1 > > INTEGER based object. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-yadawad-disman-ahcf-00.txt > > > ... >=20 >=20 >=20 >=20 ------_=_NextPart_001_01C40CF2.FC28E677 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
(sorry for the cross-posting, but = I think=20 that this conversation is relevant for rmonmib)
 
Shailadja,
 
I have read the draft carefully, I = think=20 that I understand it better now, and I appreciate what you are trying to = achieve. I should point however, that the problems that you are dealing = with=20 have solutions in other MIB modules, sometimes even multiple = solutions as=20 you are yourself pointing. An optimization may be a good thing for = a=20 certain class of applications and devices, but a sound discussion = is needed=20 to prove that this is an important enough problem to deserve a new piece = of=20 standardization in the IETF.
 
What do you suggest that we do = with this?=20 Are you suggesting that we deprecate the relevant MIB groups in = RMON and=20 RMON-2 and replace them by new optimized MIB groups on the lines of = your=20 proposal? Or should we standardize a new method for user history = with=20 instance filtering, and applying alarms to history with lesser MIB = objects in=20 addition to existing RMON standards?  
 
Regards,

Dan

-----Original Message-----
From: = disman-admin@ietf.org=20 [mailto:disman-admin@ietf.org]On Behalf Of Shailaja=20 Yadawad
Sent: 18 March, 2004 12:42 PM
To: = Romascanu, Dan=20 (Dan); disman@ietf.org; = randy_presuhn@mindspring.com
Subject: RE:=20 [Disman] Fw: I-D = ACTION:draft-yadawad-disman-ahcf-00.txt

Dan,
 
As mentioned in the draft following are the features
 
Simple configuration and Instance Management : suppose if the = user wants=20 to configure history collection for all the instances of the columnar = oid,=20 using RMON object definition the  user has to configure for each = instance=20 individually where as using our object definition, it is just one=20 configuration setting.
 
It has to be noted here that the user has the option of applying = same=20 configuration settings to all the instances or can fine tune the = configuration=20 setting for desired instances.
 
RMON2 user history object definition does not take care of newly = added=20 and deleted instances and hence if the new instances are added the = user has to=20 configure for the new instances manually.
 
Consistent reference to the resource:
History collection activity can be for a long duration and hence = it is=20 important to provide consistent reference of collected history to the=20 underlying physical media. This kind of feature is seen only interface = group=20 however if user needs this kind of ability for any oid that is = being=20 trended.
 
 
Instance Filtering
 
Istance filtering is not available in RMON user history = mib.
 
Threshold Monitoring
Yes, threshold monitoring is available in the alarm table but if = user=20 wants a complete solution of history collection and threshold = monitoring=20 in a single object definition, our mib definition provides the = solution.
 
Dan, see it this way, the above mentioned  features are = seen in=20 many mibs but user needs one mib which has all required features as = otherwise=20 it is difficult for the user to implement multiple mibs for one = problem.
 
Regards,
Shailaja.
 
 
>>> "Romascanu, Dan (Dan)" <dromasca@avaya.com> = 3/18/2004=20 12:48:59 AM >>>
I will repeat a comment that I made = during the=20 meeting in Seoul. I think that all, or almost all that is being = defined in=20 this MIB module can already be performed - some features even in = multiple ways=20 - by agents that implement existing MIB modules like RMON, Events MIB, = and=20 Alarm MIB. I think that it would help the discussion if the authors = could=20 shortly describe what is the added value that this MIB module would = bring, and=20 what operations/management functions this MIB module provides that are = not=20 covered by existing MIB modules. 

Thanks and=20 Regards,

Dan



> -----Original = Message-----
>=20 From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On<= /A>=20
> Behalf Of Randy Presuhn
> Sent: 17 March, 2004 8:55 = PM
>=20 To: Disman (E-mail)
> Subject: [Disman] Fw: I-D=20 ACTION:draft-yadawad-disman-ahcf-00.txt
>
>
> Hi = -
>=20
> I'd welcome discussion of this on the disman mailing = list.
> I=20 think it's relevant to the question of what to do about the
> = expression=20 and event MIBs.
>
> Randy
>
> > From:=20 <Internet-Drafts@ietf.org>
> > To:=20 <IETF-Announce:>
> > Sent: Wednesday, March 17, 2004 = 8:10=20 AM
> > Subject: I-D = ACTION:draft-yadawad-disman-ahcf-00.txt
>=20 >
>
> > A New Internet-Draft is available from the = on-line=20
> Internet-Drafts directories.
> >
> = >
> >=20 Title : Advanced History Collection Framework
> > Author(s) : = S.=20 Yadawad, H. Kumar, H. Yamijala, R. Shekar
> > Filename :=20 draft-yadawad-disman-ahcf-00.txt
> > Pages : 47
> > = Date :=20 2004-3-17
> >
> > This draft defines a portion of = the=20 Management Information Base for
> >     = use with=20 network management protocols in TCP/IP based
> Internets. = In
>=20 >     particular, it defines objects for = configuring=20 and
> controlling the
> >     = history=20 collection of user specified Data, which is an ASN.1
>=20 >     INTEGER based object.
> = >
> > A=20 URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-yadawad-disman-ahcf-00.txt=
>=20 >
> ...
>
>
>
>=20

------_=_NextPart_001_01C40CF2.FC28E677-- From exim@www1.ietf.org Thu Mar 18 09:16:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12179 for ; Thu, 18 Mar 2004 09:16:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yJE-0000zb-2B for disman-archive@odin.ietf.org; Thu, 18 Mar 2004 09:15:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IEFil2003811 for disman-archive@odin.ietf.org; Thu, 18 Mar 2004 09:15:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yJD-0000zO-OC for disman-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 09:15:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12143 for ; Thu, 18 Mar 2004 09:15:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3yJC-0003HI-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 09:15:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3yIH-00038G-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 09:14:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3yHZ-0002yO-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 09:14:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yHZ-0000jM-0P; Thu, 18 Mar 2004 09:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yHD-0000hm-FB for disman@optimus.ietf.org; Thu, 18 Mar 2004 09:13:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11961 for ; Thu, 18 Mar 2004 09:13:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3yHB-0002wq-00 for disman@ietf.org; Thu, 18 Mar 2004 09:13:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3yGF-0002of-00 for disman@ietf.org; Thu, 18 Mar 2004 09:12:40 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1B3yFj-0002g3-00; Thu, 18 Mar 2004 09:12:07 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2IEB5gL020156; Thu, 18 Mar 2004 09:11:05 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2IEB1gL020026; Thu, 18 Mar 2004 09:11:02 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40CF2.FC28E677" Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Message-ID: Thread-Topic: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Thread-Index: AcQM1izBngl1OE8fRBK6xxd6vjGfiAAGHpXw From: "Romascanu, Dan (Dan)" To: "Shailaja Yadawad" , , Cc: Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 16:12:02 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C40CF2.FC28E677 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (sorry for the cross-posting, but I think that this conversation is = relevant for rmonmib) =20 Shailadja, =20 I have read the draft carefully, I think that I understand it better = now, and I appreciate what you are trying to achieve. I should point = however, that the problems that you are dealing with have solutions in = other MIB modules, sometimes even multiple solutions as you are yourself = pointing. An optimization may be a good thing for a certain class of = applications and devices, but a sound discussion is needed to prove that = this is an important enough problem to deserve a new piece of = standardization in the IETF. =20 What do you suggest that we do with this? Are you suggesting that we = deprecate the relevant MIB groups in RMON and RMON-2 and replace them by = new optimized MIB groups on the lines of your proposal? Or should we = standardize a new method for user history with instance filtering, and = applying alarms to history with lesser MIB objects in addition to = existing RMON standards? =20 =20 Regards, Dan -----Original Message----- From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On Behalf Of = Shailaja Yadawad Sent: 18 March, 2004 12:42 PM To: Romascanu, Dan (Dan); disman@ietf.org; randy_presuhn@mindspring.com Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Dan, =20 As mentioned in the draft following are the features=20 =20 Simple configuration and Instance Management : suppose if the user wants = to configure history collection for all the instances of the columnar = oid, using RMON object definition the user has to configure for each = instance individually where as using our object definition, it is just = one configuration setting. =20 It has to be noted here that the user has the option of applying same = configuration settings to all the instances or can fine tune the = configuration setting for desired instances. =20 RMON2 user history object definition does not take care of newly added = and deleted instances and hence if the new instances are added the user = has to configure for the new instances manually. =20 Consistent reference to the resource: History collection activity can be for a long duration and hence it is = important to provide consistent reference of collected history to the = underlying physical media. This kind of feature is seen only interface = group however if user needs this kind of ability for any oid that is = being trended. =20 =20 Instance Filtering =20 Istance filtering is not available in RMON user history mib. =20 Threshold Monitoring Yes, threshold monitoring is available in the alarm table but if user = wants a complete solution of history collection and threshold monitoring = in a single object definition, our mib definition provides the solution. =20 Dan, see it this way, the above mentioned features are seen in many = mibs but user needs one mib which has all required features as otherwise = it is difficult for the user to implement multiple mibs for one problem. =20 Regards, Shailaja. =20 =20 >>> "Romascanu, Dan (Dan)" 3/18/2004 12:48:59 AM = >>> I will repeat a comment that I made during the meeting in Seoul. I think = that all, or almost all that is being defined in this MIB module can = already be performed - some features even in multiple ways - by agents = that implement existing MIB modules like RMON, Events MIB, and Alarm = MIB. I think that it would help the discussion if the authors could = shortly describe what is the added value that this MIB module would = bring, and what operations/management functions this MIB module provides = that are not covered by existing MIB modules. =20 Thanks and Regards, Dan > -----Original Message----- > From: disman-admin@ietf.org [ mailto:disman-admin@ietf.org]On=20 > Behalf Of Randy Presuhn > Sent: 17 March, 2004 8:55 PM > To: Disman (E-mail) > Subject: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt >=20 >=20 > Hi - >=20 > I'd welcome discussion of this on the disman mailing list. > I think it's relevant to the question of what to do about the > expression and event MIBs. >=20 > Randy >=20 > > From: > > To: > > Sent: Wednesday, March 17, 2004 8:10 AM > > Subject: I-D ACTION:draft-yadawad-disman-ahcf-00.txt > > >=20 > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > > > > > > Title : Advanced History Collection Framework > > Author(s) : S. Yadawad, H. Kumar, H. Yamijala, R. Shekar > > Filename : draft-yadawad-disman-ahcf-00.txt > > Pages : 47 > > Date : 2004-3-17 > > > > This draft defines a portion of the Management Information Base for > > use with network management protocols in TCP/IP based=20 > Internets. In > > particular, it defines objects for configuring and=20 > controlling the > > history collection of user specified Data, which is an ASN.1 > > INTEGER based object. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-yadawad-disman-ahcf-00.txt > > > ... >=20 >=20 >=20 >=20 ------_=_NextPart_001_01C40CF2.FC28E677 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
(sorry for the cross-posting, but = I think=20 that this conversation is relevant for rmonmib)
 
Shailadja,
 
I have read the draft carefully, I = think=20 that I understand it better now, and I appreciate what you are trying to = achieve. I should point however, that the problems that you are dealing = with=20 have solutions in other MIB modules, sometimes even multiple = solutions as=20 you are yourself pointing. An optimization may be a good thing for = a=20 certain class of applications and devices, but a sound discussion = is needed=20 to prove that this is an important enough problem to deserve a new piece = of=20 standardization in the IETF.
 
What do you suggest that we do = with this?=20 Are you suggesting that we deprecate the relevant MIB groups in = RMON and=20 RMON-2 and replace them by new optimized MIB groups on the lines of = your=20 proposal? Or should we standardize a new method for user history = with=20 instance filtering, and applying alarms to history with lesser MIB = objects in=20 addition to existing RMON standards?  
 
Regards,

Dan

-----Original Message-----
From: = disman-admin@ietf.org=20 [mailto:disman-admin@ietf.org]On Behalf Of Shailaja=20 Yadawad
Sent: 18 March, 2004 12:42 PM
To: = Romascanu, Dan=20 (Dan); disman@ietf.org; = randy_presuhn@mindspring.com
Subject: RE:=20 [Disman] Fw: I-D = ACTION:draft-yadawad-disman-ahcf-00.txt

Dan,
 
As mentioned in the draft following are the features
 
Simple configuration and Instance Management : suppose if the = user wants=20 to configure history collection for all the instances of the columnar = oid,=20 using RMON object definition the  user has to configure for each = instance=20 individually where as using our object definition, it is just one=20 configuration setting.
 
It has to be noted here that the user has the option of applying = same=20 configuration settings to all the instances or can fine tune the = configuration=20 setting for desired instances.
 
RMON2 user history object definition does not take care of newly = added=20 and deleted instances and hence if the new instances are added the = user has to=20 configure for the new instances manually.
 
Consistent reference to the resource:
History collection activity can be for a long duration and hence = it is=20 important to provide consistent reference of collected history to the=20 underlying physical media. This kind of feature is seen only interface = group=20 however if user needs this kind of ability for any oid that is = being=20 trended.
 
 
Instance Filtering
 
Istance filtering is not available in RMON user history = mib.
 
Threshold Monitoring
Yes, threshold monitoring is available in the alarm table but if = user=20 wants a complete solution of history collection and threshold = monitoring=20 in a single object definition, our mib definition provides the = solution.
 
Dan, see it this way, the above mentioned  features are = seen in=20 many mibs but user needs one mib which has all required features as = otherwise=20 it is difficult for the user to implement multiple mibs for one = problem.
 
Regards,
Shailaja.
 
 
>>> "Romascanu, Dan (Dan)" <dromasca@avaya.com> = 3/18/2004=20 12:48:59 AM >>>
I will repeat a comment that I made = during the=20 meeting in Seoul. I think that all, or almost all that is being = defined in=20 this MIB module can already be performed - some features even in = multiple ways=20 - by agents that implement existing MIB modules like RMON, Events MIB, = and=20 Alarm MIB. I think that it would help the discussion if the authors = could=20 shortly describe what is the added value that this MIB module would = bring, and=20 what operations/management functions this MIB module provides that are = not=20 covered by existing MIB modules. 

Thanks and=20 Regards,

Dan



> -----Original = Message-----
>=20 From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On<= /A>=20
> Behalf Of Randy Presuhn
> Sent: 17 March, 2004 8:55 = PM
>=20 To: Disman (E-mail)
> Subject: [Disman] Fw: I-D=20 ACTION:draft-yadawad-disman-ahcf-00.txt
>
>
> Hi = -
>=20
> I'd welcome discussion of this on the disman mailing = list.
> I=20 think it's relevant to the question of what to do about the
> = expression=20 and event MIBs.
>
> Randy
>
> > From:=20 <Internet-Drafts@ietf.org>
> > To:=20 <IETF-Announce:>
> > Sent: Wednesday, March 17, 2004 = 8:10=20 AM
> > Subject: I-D = ACTION:draft-yadawad-disman-ahcf-00.txt
>=20 >
>
> > A New Internet-Draft is available from the = on-line=20
> Internet-Drafts directories.
> >
> = >
> >=20 Title : Advanced History Collection Framework
> > Author(s) : = S.=20 Yadawad, H. Kumar, H. Yamijala, R. Shekar
> > Filename :=20 draft-yadawad-disman-ahcf-00.txt
> > Pages : 47
> > = Date :=20 2004-3-17
> >
> > This draft defines a portion of = the=20 Management Information Base for
> >     = use with=20 network management protocols in TCP/IP based
> Internets. = In
>=20 >     particular, it defines objects for = configuring=20 and
> controlling the
> >     = history=20 collection of user specified Data, which is an ASN.1
>=20 >     INTEGER based object.
> = >
> > A=20 URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-yadawad-disman-ahcf-00.txt=
>=20 >
> ...
>
>
>
>=20

------_=_NextPart_001_01C40CF2.FC28E677-- From disman-admin@ietf.org Thu Mar 18 09:21:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12405 for ; Thu, 18 Mar 2004 09:21:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yON-00019f-0J; Thu, 18 Mar 2004 09:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yNv-00017U-OY for disman@optimus.ietf.org; Thu, 18 Mar 2004 09:20:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12374 for ; Thu, 18 Mar 2004 09:20:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3yNt-0003pF-00 for disman@ietf.org; Thu, 18 Mar 2004 09:20:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3yMw-0003iF-00 for disman@ietf.org; Thu, 18 Mar 2004 09:19:35 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1B3yMR-0003bP-00; Thu, 18 Mar 2004 09:19:03 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2IEI1gL028567; Thu, 18 Mar 2004 09:18:01 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2IEHxgL028525; Thu, 18 Mar 2004 09:18:00 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40CF3.F52DAAFD" Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Message-ID: Thread-Topic: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Thread-Index: AcQM1fHbzUUf8DZRRLSASW/JGqiM2wAHTSfA From: "Romascanu, Dan (Dan)" To: "Shailaja Yadawad" , , Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 16:19:00 +0200 This is a multi-part message in MIME format. ------_=_NextPart_001_01C40CF3.F52DAAFD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ... and this brings exactly the two issues that I am trying to point to: * as at least a partial solution exists to the problems that your I-D = tries to solve, do the additional functionality and optimizations = justify new standards work? * assuming the answer is yes to the above, should we not consider rather = extending the existing RMON design, and try to ensure to the possible = extend backwards compatibility to existing RMON MIBs? =20 Regards, Dan -----Original Message----- From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On Behalf Of = Shailaja Yadawad Sent: 18 March, 2004 12:40 PM To: Romascanu, Dan (Dan); disman@ietf.org; randy_presuhn@mindspring.com Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Dan, =20 >I was not going that far, and actually I did not have the expression = MIB in mind.=20 Expression MIB can be modified based on some of our features. >What I am seeing are mechanisms like RMON alarm and usrHistory being = reinvented, and >objects like ituSeverity from the Alarm MIB being = duplicated. you are correct that our draft contains object definition similar to = that of RMON alarm and usrHistory but with additional features and = changes. =20 Regards, Shailaja. ------_=_NextPart_001_01C40CF3.F52DAAFD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
... and this brings exactly the = two issues=20 that I am trying to point to:
  • as at least a partial solution = exists to=20 the problems that your I-D tries to solve, do the additional = functionality and=20 optimizations justify new standards work?
  • assuming the answer is yes to the = above,=20 should we not consider rather extending the existing RMON design, and = try to=20 ensure to the possible extend backwards compatibility to existing RMON = MIBs?
 

Regards,

Dan

-----Original Message-----
From: = disman-admin@ietf.org=20 [mailto:disman-admin@ietf.org]On Behalf Of Shailaja=20 Yadawad
Sent: 18 March, 2004 12:40 PM
To: = Romascanu, Dan=20 (Dan); disman@ietf.org; = randy_presuhn@mindspring.com
Subject: RE:=20 [Disman] Fw: I-D = ACTION:draft-yadawad-disman-ahcf-00.txt

Dan,
 
>I was not = going that=20 far, and actually I did not have the expression MIB in mind. =
Expression MIB can be modified based on some of our = features.

>What I am seeing are mechanisms like RMON alarm and = usrHistory=20 being reinvented, and >objects like ituSeverity from the Alarm MIB = being=20 duplicated.

you are correct that our draft contains object = definition=20 similar to that of  RMON alarm and usrHistory but = with additional=20 features and changes.
 
Regards,
Shailaja.
------_=_NextPart_001_01C40CF3.F52DAAFD-- From exim@www1.ietf.org Thu Mar 18 09:22:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12509 for ; Thu, 18 Mar 2004 09:22:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yPl-0001HE-EB for disman-archive@odin.ietf.org; Thu, 18 Mar 2004 09:22:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IEMTaa004902 for disman-archive@odin.ietf.org; Thu, 18 Mar 2004 09:22:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yPl-0001Gz-AW for disman-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 09:22:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12497 for ; Thu, 18 Mar 2004 09:22:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3yPj-00043Y-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 09:22:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3yOp-0003x7-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 09:21:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3yOM-0003qH-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 09:21:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yON-00019f-0J; Thu, 18 Mar 2004 09:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3yNv-00017U-OY for disman@optimus.ietf.org; Thu, 18 Mar 2004 09:20:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12374 for ; Thu, 18 Mar 2004 09:20:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3yNt-0003pF-00 for disman@ietf.org; Thu, 18 Mar 2004 09:20:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3yMw-0003iF-00 for disman@ietf.org; Thu, 18 Mar 2004 09:19:35 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1B3yMR-0003bP-00; Thu, 18 Mar 2004 09:19:03 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2IEI1gL028567; Thu, 18 Mar 2004 09:18:01 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2IEHxgL028525; Thu, 18 Mar 2004 09:18:00 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C40CF3.F52DAAFD" Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Message-ID: Thread-Topic: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Thread-Index: AcQM1fHbzUUf8DZRRLSASW/JGqiM2wAHTSfA From: "Romascanu, Dan (Dan)" To: "Shailaja Yadawad" , , Cc: Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 16:19:00 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C40CF3.F52DAAFD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ... and this brings exactly the two issues that I am trying to point to: * as at least a partial solution exists to the problems that your I-D = tries to solve, do the additional functionality and optimizations = justify new standards work? * assuming the answer is yes to the above, should we not consider rather = extending the existing RMON design, and try to ensure to the possible = extend backwards compatibility to existing RMON MIBs? =20 Regards, Dan -----Original Message----- From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On Behalf Of = Shailaja Yadawad Sent: 18 March, 2004 12:40 PM To: Romascanu, Dan (Dan); disman@ietf.org; randy_presuhn@mindspring.com Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Dan, =20 >I was not going that far, and actually I did not have the expression = MIB in mind.=20 Expression MIB can be modified based on some of our features. >What I am seeing are mechanisms like RMON alarm and usrHistory being = reinvented, and >objects like ituSeverity from the Alarm MIB being = duplicated. you are correct that our draft contains object definition similar to = that of RMON alarm and usrHistory but with additional features and = changes. =20 Regards, Shailaja. ------_=_NextPart_001_01C40CF3.F52DAAFD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
... and this brings exactly the = two issues=20 that I am trying to point to:
  • as at least a partial solution = exists to=20 the problems that your I-D tries to solve, do the additional = functionality and=20 optimizations justify new standards work?
  • assuming the answer is yes to the = above,=20 should we not consider rather extending the existing RMON design, and = try to=20 ensure to the possible extend backwards compatibility to existing RMON = MIBs?
 

Regards,

Dan

-----Original Message-----
From: = disman-admin@ietf.org=20 [mailto:disman-admin@ietf.org]On Behalf Of Shailaja=20 Yadawad
Sent: 18 March, 2004 12:40 PM
To: = Romascanu, Dan=20 (Dan); disman@ietf.org; = randy_presuhn@mindspring.com
Subject: RE:=20 [Disman] Fw: I-D = ACTION:draft-yadawad-disman-ahcf-00.txt

Dan,
 
>I was not = going that=20 far, and actually I did not have the expression MIB in mind. =
Expression MIB can be modified based on some of our = features.

>What I am seeing are mechanisms like RMON alarm and = usrHistory=20 being reinvented, and >objects like ituSeverity from the Alarm MIB = being=20 duplicated.

you are correct that our draft contains object = definition=20 similar to that of  RMON alarm and usrHistory but = with additional=20 features and changes.
 
Regards,
Shailaja.
------_=_NextPart_001_01C40CF3.F52DAAFD-- From disman-admin@ietf.org Thu Mar 18 11:20:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22641 for ; Thu, 18 Mar 2004 11:20:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B40FW-00011z-E5; Thu, 18 Mar 2004 11:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B40F0-00010b-U6 for disman@optimus.ietf.org; Thu, 18 Mar 2004 11:19:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22593 for ; Thu, 18 Mar 2004 11:19:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B40Ez-00012w-00 for disman@ietf.org; Thu, 18 Mar 2004 11:19:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B40E1-00010N-00 for disman@ietf.org; Thu, 18 Mar 2004 11:18:30 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B40DM-0000wV-00; Thu, 18 Mar 2004 11:17:49 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 18 Mar 2004 08:21:12 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2IGHFaD021461; Thu, 18 Mar 2004 08:17:15 -0800 (PST) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn4-143.cisco.com [10.21.80.143]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ASA76748; Thu, 18 Mar 2004 08:17:14 -0800 (PST) Message-Id: <6.0.3.0.2.20040318075144.046af2b8@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 To: "Romascanu, Dan (Dan)" From: Andy Bierman Subject: Re: [RMONMIB] RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Cc: "Shailaja Yadawad" , , , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 08:12:56 -0800 At 06:19 AM 3/18/2004, Romascanu, Dan (Dan) wrote: >... and this brings exactly the two issues that I am trying to point to: > * as at least a partial solution exists to the problems that your I-D tries to solve, do the additional functionality and optimizations justify new standards work? For the alarm features: Hopefully the DISMAN WG will someday finish the Alarm MIB and other WGs can use it for alarm management instead of creating yet another ad-hoc alarm feature thrown in with a domain-specific monitoring MIB. For the threshold wildcard features: Although this MIB appears to overlap the Expression MIB, it's much easier to use and it's focused on the persistent index problem, not the on-the-box data reduction problem. This MIB is a well-designed band-aid for the (lack of) persistent index problem. Unfortunately, the persistent index problem impacts application polling even worse than embedded polling. Customers are demanding that we get rid or our arbitrarily renumbered integer index objects (like ifIndex and entPhysicalIndex) by making the index assignments persist across reboots. So that's what we're doing -- addressing the core problem. > * assuming the answer is yes to the above, should we not consider rather extending the existing RMON design, and try to ensure to the possible extend backwards compatibility to existing RMON MIBs? You are thinking of perhaps adding the threshold wildcard feature to the usrHistoryControlTable and usrHistoryObjectTable, and leaving the data (usrHistoryTable) untouched? Unless there is massive interest from the RMONMIB WG to re-open the RMON-2 usrHistory group for this feature, I don't think this approach is viable. > > >Regards, > >Dan Andy >-----Original Message----- >From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On Behalf Of Shailaja Yadawad >Sent: 18 March, 2004 12:40 PM >To: Romascanu, Dan (Dan); disman@ietf.org; randy_presuhn@mindspring.com >Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt > >Dan, > >>I was not going that far, and actually I did not have the expression MIB in mind. >Expression MIB can be modified based on some of our features. > >>What I am seeing are mechanisms like RMON alarm and usrHistory being reinvented, and >objects like ituSeverity from the Alarm MIB being duplicated. > >you are correct that our draft contains object definition similar to that of RMON alarm and usrHistory but with additional features and changes. > >Regards, >Shailaja. From exim@www1.ietf.org Thu Mar 18 11:22:04 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22750 for ; Thu, 18 Mar 2004 11:22:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B40H2-0001L4-7b for disman-archive@odin.ietf.org; Thu, 18 Mar 2004 11:21:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IGLaPj005146 for disman-archive@odin.ietf.org; Thu, 18 Mar 2004 11:21:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B40H2-0001Kv-3b for disman-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 11:21:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22736 for ; Thu, 18 Mar 2004 11:21:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B40H0-0001AF-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 11:21:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B40G5-00017n-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 11:20:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B40FY-000156-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 11:20:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B40FW-00011z-E5; Thu, 18 Mar 2004 11:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B40F0-00010b-U6 for disman@optimus.ietf.org; Thu, 18 Mar 2004 11:19:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22593 for ; Thu, 18 Mar 2004 11:19:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B40Ez-00012w-00 for disman@ietf.org; Thu, 18 Mar 2004 11:19:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B40E1-00010N-00 for disman@ietf.org; Thu, 18 Mar 2004 11:18:30 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B40DM-0000wV-00; Thu, 18 Mar 2004 11:17:49 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 18 Mar 2004 08:21:12 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2IGHFaD021461; Thu, 18 Mar 2004 08:17:15 -0800 (PST) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn4-143.cisco.com [10.21.80.143]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ASA76748; Thu, 18 Mar 2004 08:17:14 -0800 (PST) Message-Id: <6.0.3.0.2.20040318075144.046af2b8@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 To: "Romascanu, Dan (Dan)" From: Andy Bierman Subject: Re: [RMONMIB] RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Cc: "Shailaja Yadawad" , , , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 08:12:56 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 06:19 AM 3/18/2004, Romascanu, Dan (Dan) wrote: >... and this brings exactly the two issues that I am trying to point to: > * as at least a partial solution exists to the problems that your I-D tries to solve, do the additional functionality and optimizations justify new standards work? For the alarm features: Hopefully the DISMAN WG will someday finish the Alarm MIB and other WGs can use it for alarm management instead of creating yet another ad-hoc alarm feature thrown in with a domain-specific monitoring MIB. For the threshold wildcard features: Although this MIB appears to overlap the Expression MIB, it's much easier to use and it's focused on the persistent index problem, not the on-the-box data reduction problem. This MIB is a well-designed band-aid for the (lack of) persistent index problem. Unfortunately, the persistent index problem impacts application polling even worse than embedded polling. Customers are demanding that we get rid or our arbitrarily renumbered integer index objects (like ifIndex and entPhysicalIndex) by making the index assignments persist across reboots. So that's what we're doing -- addressing the core problem. > * assuming the answer is yes to the above, should we not consider rather extending the existing RMON design, and try to ensure to the possible extend backwards compatibility to existing RMON MIBs? You are thinking of perhaps adding the threshold wildcard feature to the usrHistoryControlTable and usrHistoryObjectTable, and leaving the data (usrHistoryTable) untouched? Unless there is massive interest from the RMONMIB WG to re-open the RMON-2 usrHistory group for this feature, I don't think this approach is viable. > > >Regards, > >Dan Andy >-----Original Message----- >From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On Behalf Of Shailaja Yadawad >Sent: 18 March, 2004 12:40 PM >To: Romascanu, Dan (Dan); disman@ietf.org; randy_presuhn@mindspring.com >Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt > >Dan, > >>I was not going that far, and actually I did not have the expression MIB in mind. >Expression MIB can be modified based on some of our features. > >>What I am seeing are mechanisms like RMON alarm and usrHistory being reinvented, and >objects like ituSeverity from the Alarm MIB being duplicated. > >you are correct that our draft contains object definition similar to that of RMON alarm and usrHistory but with additional features and changes. > >Regards, >Shailaja. From disman-admin@ietf.org Thu Mar 18 12:51:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26984 for ; Thu, 18 Mar 2004 12:51:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B41fY-0001nZ-To; Thu, 18 Mar 2004 12:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B41f2-0001eF-CB for disman@optimus.ietf.org; Thu, 18 Mar 2004 12:50:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26890 for ; Thu, 18 Mar 2004 12:50:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B41f0-0006mS-00 for disman@ietf.org; Thu, 18 Mar 2004 12:50:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B41eA-0006hv-00 for disman@ietf.org; Thu, 18 Mar 2004 12:49:35 -0500 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1B41dM-0006dr-00; Thu, 18 Mar 2004 12:48:44 -0500 Received: from h-68-164-88-226.snvacaid.dynamic.covad.net ([68.164.88.226] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1B41dK-0006aP-00; Thu, 18 Mar 2004 09:48:42 -0800 Message-ID: <010501c40d11$96449a60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Cc: References: <6.0.3.0.2.20040318075144.046af2b8@fedex.cisco.com> Subject: Re: [RMONMIB] RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 09:51:05 -0800 Hi - (disman WG chair hat on) > From: "Andy Bierman" > To: "Romascanu, Dan (Dan)" > Cc: "Shailaja Yadawad" ; ; ; > Sent: Thursday, March 18, 2004 8:12 AM >Subject: Re: [RMONMIB] RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt ... > Hopefully the DISMAN WG will someday finish the Alarm MIB > and other WGs can use it for alarm management instead of > creating yet another ad-hoc alarm feature thrown in with > a domain-specific monitoring MIB. It's already done; it's in the RFC editor queue. ... > > * assuming the answer is yes to the above, should we not consider rather extending >> the existing RMON design, and try to ensure to the possible extend backwards >> compatibility to existing RMON MIBs? > You are thinking of perhaps adding the threshold wildcard > feature to the usrHistoryControlTable and usrHistoryObjectTable, > and leaving the data (usrHistoryTable) untouched? > Unless there is massive interest from the RMONMIB WG to > re-open the RMON-2 usrHistory group for this feature, > I don't think this approach is viable. ... Since there is substantial overlap in the membership of the two working groups, can we confine this discussion to just one of the WG lists? I suggest that we continue discussion on the disman list. If consensus develops that there is a problem to be solved along with a general sense what technical approach we'd like to use, then Andy and I could consult with Bert (our Area Director) to figure out whether the work would make sense for either working group, a new working group, or whatever. Much of disman's work is a generalization of work pioneered in the RMON work. The question of "genericness" (I need a better word) is the one I personally use in trying to figure out whether a proposal might make more sense in one WG or the other. However, let's first decide whether there's a problem to solve and a general technical direction to use as a starting point for a solution before jumping to the question putting it on a specific WG's charter. Randy From exim@www1.ietf.org Thu Mar 18 12:53:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27173 for ; Thu, 18 Mar 2004 12:53:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B41hC-00022U-B9 for disman-archive@odin.ietf.org; Thu, 18 Mar 2004 12:52:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IHqgip007837 for disman-archive@odin.ietf.org; Thu, 18 Mar 2004 12:52:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B41hC-00022K-7d for disman-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 12:52:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27142 for ; Thu, 18 Mar 2004 12:52:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B41hA-0006z2-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 12:52:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B41gM-0006vD-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 12:51:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B41fZ-0006qu-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 12:51:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B41fY-0001nZ-To; Thu, 18 Mar 2004 12:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B41f2-0001eF-CB for disman@optimus.ietf.org; Thu, 18 Mar 2004 12:50:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26890 for ; Thu, 18 Mar 2004 12:50:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B41f0-0006mS-00 for disman@ietf.org; Thu, 18 Mar 2004 12:50:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B41eA-0006hv-00 for disman@ietf.org; Thu, 18 Mar 2004 12:49:35 -0500 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1B41dM-0006dr-00; Thu, 18 Mar 2004 12:48:44 -0500 Received: from h-68-164-88-226.snvacaid.dynamic.covad.net ([68.164.88.226] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1B41dK-0006aP-00; Thu, 18 Mar 2004 09:48:42 -0800 Message-ID: <010501c40d11$96449a60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: Cc: References: <6.0.3.0.2.20040318075144.046af2b8@fedex.cisco.com> Subject: Re: [RMONMIB] RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 09:51:05 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Hi - (disman WG chair hat on) > From: "Andy Bierman" > To: "Romascanu, Dan (Dan)" > Cc: "Shailaja Yadawad" ; ; ; > Sent: Thursday, March 18, 2004 8:12 AM >Subject: Re: [RMONMIB] RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt ... > Hopefully the DISMAN WG will someday finish the Alarm MIB > and other WGs can use it for alarm management instead of > creating yet another ad-hoc alarm feature thrown in with > a domain-specific monitoring MIB. It's already done; it's in the RFC editor queue. ... > > * assuming the answer is yes to the above, should we not consider rather extending >> the existing RMON design, and try to ensure to the possible extend backwards >> compatibility to existing RMON MIBs? > You are thinking of perhaps adding the threshold wildcard > feature to the usrHistoryControlTable and usrHistoryObjectTable, > and leaving the data (usrHistoryTable) untouched? > Unless there is massive interest from the RMONMIB WG to > re-open the RMON-2 usrHistory group for this feature, > I don't think this approach is viable. ... Since there is substantial overlap in the membership of the two working groups, can we confine this discussion to just one of the WG lists? I suggest that we continue discussion on the disman list. If consensus develops that there is a problem to be solved along with a general sense what technical approach we'd like to use, then Andy and I could consult with Bert (our Area Director) to figure out whether the work would make sense for either working group, a new working group, or whatever. Much of disman's work is a generalization of work pioneered in the RMON work. The question of "genericness" (I need a better word) is the one I personally use in trying to figure out whether a proposal might make more sense in one WG or the other. However, let's first decide whether there's a problem to solve and a general technical direction to use as a starting point for a solution before jumping to the question putting it on a specific WG's charter. Randy From disman-admin@ietf.org Thu Mar 18 13:14:20 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28536 for ; Thu, 18 Mar 2004 13:14:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B421G-0004OM-L1; Thu, 18 Mar 2004 13:13:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B41xq-0004Hf-B8 for disman@optimus.ietf.org; Thu, 18 Mar 2004 13:09:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28195 for ; Thu, 18 Mar 2004 13:09:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B41xh-0000AX-00 for disman@ietf.org; Thu, 18 Mar 2004 13:09:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B41wk-00005x-00 for disman@ietf.org; Thu, 18 Mar 2004 13:08:46 -0500 Received: from pintail.mail.pas.earthlink.net ([207.217.120.122]) by ietf-mx with esmtp (Exim 4.12) id 1B41wF-00001f-00 for disman@ietf.org; Thu, 18 Mar 2004 13:08:15 -0500 Received: from h-68-164-88-226.snvacaid.dynamic.covad.net ([68.164.88.226] helo=oemcomputer) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1B41wD-0007iJ-00 for disman@ietf.org; Thu, 18 Mar 2004 10:08:13 -0800 Message-ID: <000801c40d14$4fe2ff00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,DOMAIN_4U2 autolearn=no version=2.60 Subject: [Disman] OT: useless reply Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 10:10:35 -0800 Hi - This is the sort of thing that drives mailing list administrators crazy. Does anyone know what the old subscriber address would have been? The message is particularly questionable since the "From:" address is forged, so I'm inclined to ignore it. Randy =============================================== Status: U Return-Path: <> Received: from mail9.atl.registeredsite.com ([64.224.219.83]) by wanamaker.mail.atl.earthlink.net (EarthLink SMTP Server) with ESMTP id 1b41Gl7qd3Nl3oJ0 for ; Thu, 18 Mar 2004 12:51:49 -0500 (EST) Received: from saturn.hosting4u.net (saturn.hosting4u.net [209.35.191.120]) by mail9.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i2IIpmCE019242 for ; Thu, 18 Mar 2004 13:51:48 -0500 Date: Thu, 18 Mar 2004 13:51:48 -0500 Received: from saturn ([209.35.191.120]) by saturn.hosting4u.net ; Thu, 18 Mar 2004 11:51:48 -0600 Subject: Email address has changed From: X-Rcpt-To: Message-ID: <107963230801@saturn.hosting4u.net> To: X-ELNK-AV: 0 This address has moved - the new address is firstname.lastname@opennet.com for the recipient. This address has been removed due to spam, and those of you who know me will know my firstname.lastname address. Thank You Carmody From exim@www1.ietf.org Thu Mar 18 13:15:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28626 for ; Thu, 18 Mar 2004 13:15:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B423J-0004gz-IH for disman-archive@odin.ietf.org; Thu, 18 Mar 2004 13:15:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2IIFXF8018037 for disman-archive@odin.ietf.org; Thu, 18 Mar 2004 13:15:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B423J-0004gq-C6 for disman-web-archive@optimus.ietf.org; Thu, 18 Mar 2004 13:15:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28588 for ; Thu, 18 Mar 2004 13:15:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B423H-0000b3-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 13:15:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B422L-0000W6-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 13:14:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B421h-0000U0-00 for disman-web-archive@ietf.org; Thu, 18 Mar 2004 13:13:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B421G-0004OM-L1; Thu, 18 Mar 2004 13:13:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B41xq-0004Hf-B8 for disman@optimus.ietf.org; Thu, 18 Mar 2004 13:09:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28195 for ; Thu, 18 Mar 2004 13:09:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B41xh-0000AX-00 for disman@ietf.org; Thu, 18 Mar 2004 13:09:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B41wk-00005x-00 for disman@ietf.org; Thu, 18 Mar 2004 13:08:46 -0500 Received: from pintail.mail.pas.earthlink.net ([207.217.120.122]) by ietf-mx with esmtp (Exim 4.12) id 1B41wF-00001f-00 for disman@ietf.org; Thu, 18 Mar 2004 13:08:15 -0500 Received: from h-68-164-88-226.snvacaid.dynamic.covad.net ([68.164.88.226] helo=oemcomputer) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1B41wD-0007iJ-00 for disman@ietf.org; Thu, 18 Mar 2004 10:08:13 -0800 Message-ID: <000801c40d14$4fe2ff00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Disman] OT: useless reply Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Thu, 18 Mar 2004 10:10:35 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,DOMAIN_4U2 autolearn=no version=2.60 Hi - This is the sort of thing that drives mailing list administrators crazy. Does anyone know what the old subscriber address would have been? The message is particularly questionable since the "From:" address is forged, so I'm inclined to ignore it. Randy =============================================== Status: U Return-Path: <> Received: from mail9.atl.registeredsite.com ([64.224.219.83]) by wanamaker.mail.atl.earthlink.net (EarthLink SMTP Server) with ESMTP id 1b41Gl7qd3Nl3oJ0 for ; Thu, 18 Mar 2004 12:51:49 -0500 (EST) Received: from saturn.hosting4u.net (saturn.hosting4u.net [209.35.191.120]) by mail9.atl.registeredsite.com (8.12.8/8.12.8) with ESMTP id i2IIpmCE019242 for ; Thu, 18 Mar 2004 13:51:48 -0500 Date: Thu, 18 Mar 2004 13:51:48 -0500 Received: from saturn ([209.35.191.120]) by saturn.hosting4u.net ; Thu, 18 Mar 2004 11:51:48 -0600 Subject: Email address has changed From: X-Rcpt-To: Message-ID: <107963230801@saturn.hosting4u.net> To: X-ELNK-AV: 0 This address has moved - the new address is firstname.lastname@opennet.com for the recipient. This address has been removed due to spam, and those of you who know me will know my firstname.lastname address. Thank You Carmody From disman-admin@ietf.org Mon Mar 22 07:55:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21109 for ; Mon, 22 Mar 2004 07:55:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5OxL-0004FN-NB; Mon, 22 Mar 2004 07:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Owr-0004DN-A7 for disman@optimus.ietf.org; Mon, 22 Mar 2004 07:54:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20913 for ; Mon, 22 Mar 2004 07:54:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Owq-0004LO-00 for disman@ietf.org; Mon, 22 Mar 2004 07:54:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Ov7-000411-00 for disman@ietf.org; Mon, 22 Mar 2004 07:52:45 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1B5Oue-0003t0-00; Mon, 22 Mar 2004 07:52:16 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Mon, 22 Mar 2004 05:51:45 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: , , Cc: Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartD2F3C145.1__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Mar 2004 05:51:33 -0700 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartD2F3C145.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Dan >I have read the draft carefully, I think that I understand it better now, and I appreciate what >you are trying to achieve. I should point however, that the problems that you are dealing with >have solutions in other MIB modules, sometimes even multiple solutions as you are yourself >pointing. An optimization may be a good thing for a certain class of applications and devices, >but a sound discussion is needed to prove that this is an important enough problem to deserve >a new piece of standardization in the IETF. The draft proposal is trying to solve a important problems associated with the history collection. The user will in most probability will face these problems like persistent index ( as Andy mentioned) and need for automatic instance management and easy configurations during history collection activity. It is my belief that standardization of such features will help users. >What do you suggest that we do with this? Are you suggesting that we deprecate the relevant >MIB groups in RMON and RMON-2 and replace them by new optimized MIB groups on the lines >of your proposal? Or should we standardize a new method for user history with instance >filtering, and applying alarms to history with lesser MIB objects in addition to existing RMON >standards? I feel that proposed features needs a standardization. As mentioned in our draft, deprecating the relevant RMON-2 MIB groups will pose a backward compatibility issue of previously collected history data to the user and so creating a new standard is a good idea. Regards, Shailaja. --=__PartD2F3C145.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dan
 
>I have read the draft carefully, = I think that I understand it better now, and I appreciate what >you are = trying to achieve. I should point however, that the problems that you are = dealing with >have solutions in other MIB modules, sometimes even = multiple solutions as you are yourself >pointing. An optimization m= ay be a good thing for a certain class of applications and devices, = >but a sound discussion is needed to prove that this is an = important enough problem to deserve >a new piece of standardization in = the IETF.
 
The draft proposal is  trying = to solve a important problems associated with the history collection. =
The user will in most probability = will face these problems like persistent index ( as Andy mentioned) = and need for automatic instance management and easy configuration= s during history collection activity. It is my belief that standardization = of such features will help users.
 
 
>What do you suggest that we do = with this? Are you suggesting that we deprecate the relevant >MIB = groups in RMON and RMON-2 and replace them by new optimized MIB = groups on the lines >of your proposal? Or should we standardize a = new method for user history with instance >filtering, and applying = alarms to history with lesser MIB objects in addition to existing RMON = >standards?  
 
I feel that proposed features needs = a standardization. As mentioned in our draft, deprecating the relevant = RMON-2 MIB groups will pose a backward compatibility issue  of = previously collected history data to the user and so creating a new = standard is a good idea.
 
 
Regards,
Shailaja.
 
--=__PartD2F3C145.1__=-- From exim@www1.ietf.org Mon Mar 22 07:57:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21274 for ; Mon, 22 Mar 2004 07:57:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Oz0-0004Wp-Hr for disman-archive@odin.ietf.org; Mon, 22 Mar 2004 07:56:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MCukiB017406 for disman-archive@odin.ietf.org; Mon, 22 Mar 2004 07:56:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Oz0-0004Wf-DA for disman-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 07:56:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21254 for ; Mon, 22 Mar 2004 07:56:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Oyy-0004kr-00 for disman-web-archive@ietf.org; Mon, 22 Mar 2004 07:56:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5OyJ-0004bv-00 for disman-web-archive@ietf.org; Mon, 22 Mar 2004 07:56:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5OxN-0004Qv-00 for disman-web-archive@ietf.org; Mon, 22 Mar 2004 07:55:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5OxL-0004FN-NB; Mon, 22 Mar 2004 07:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Owr-0004DN-A7 for disman@optimus.ietf.org; Mon, 22 Mar 2004 07:54:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20913 for ; Mon, 22 Mar 2004 07:54:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Owq-0004LO-00 for disman@ietf.org; Mon, 22 Mar 2004 07:54:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Ov7-000411-00 for disman@ietf.org; Mon, 22 Mar 2004 07:52:45 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1B5Oue-0003t0-00; Mon, 22 Mar 2004 07:52:16 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Mon, 22 Mar 2004 05:51:45 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: , , Cc: Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartD2F3C145.1__=" Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Mar 2004 05:51:33 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartD2F3C145.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Dan >I have read the draft carefully, I think that I understand it better now, and I appreciate what >you are trying to achieve. I should point however, that the problems that you are dealing with >have solutions in other MIB modules, sometimes even multiple solutions as you are yourself >pointing. An optimization may be a good thing for a certain class of applications and devices, >but a sound discussion is needed to prove that this is an important enough problem to deserve >a new piece of standardization in the IETF. The draft proposal is trying to solve a important problems associated with the history collection. The user will in most probability will face these problems like persistent index ( as Andy mentioned) and need for automatic instance management and easy configurations during history collection activity. It is my belief that standardization of such features will help users. >What do you suggest that we do with this? Are you suggesting that we deprecate the relevant >MIB groups in RMON and RMON-2 and replace them by new optimized MIB groups on the lines >of your proposal? Or should we standardize a new method for user history with instance >filtering, and applying alarms to history with lesser MIB objects in addition to existing RMON >standards? I feel that proposed features needs a standardization. As mentioned in our draft, deprecating the relevant RMON-2 MIB groups will pose a backward compatibility issue of previously collected history data to the user and so creating a new standard is a good idea. Regards, Shailaja. --=__PartD2F3C145.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dan
 
>I have read the draft carefully, = I think that I understand it better now, and I appreciate what >you are = trying to achieve. I should point however, that the problems that you are = dealing with >have solutions in other MIB modules, sometimes even = multiple solutions as you are yourself >pointing. An optimization m= ay be a good thing for a certain class of applications and devices, = >but a sound discussion is needed to prove that this is an = important enough problem to deserve >a new piece of standardization in = the IETF.
 
The draft proposal is  trying = to solve a important problems associated with the history collection. =
The user will in most probability = will face these problems like persistent index ( as Andy mentioned) = and need for automatic instance management and easy configuration= s during history collection activity. It is my belief that standardization = of such features will help users.
 
 
>What do you suggest that we do = with this? Are you suggesting that we deprecate the relevant >MIB = groups in RMON and RMON-2 and replace them by new optimized MIB = groups on the lines >of your proposal? Or should we standardize a = new method for user history with instance >filtering, and applying = alarms to history with lesser MIB objects in addition to existing RMON = >standards?  
 
I feel that proposed features needs = a standardization. As mentioned in our draft, deprecating the relevant = RMON-2 MIB groups will pose a backward compatibility issue  of = previously collected history data to the user and so creating a new = standard is a good idea.
 
 
Regards,
Shailaja.
 
--=__PartD2F3C145.1__=-- From disman-admin@ietf.org Mon Mar 22 08:01:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21524 for ; Mon, 22 Mar 2004 08:01:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5P37-0004pr-Qa; Mon, 22 Mar 2004 08:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5P2j-0004oP-Ki for disman@optimus.ietf.org; Mon, 22 Mar 2004 08:00:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21483 for ; Mon, 22 Mar 2004 08:00:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5P2i-0005Ee-00 for disman@ietf.org; Mon, 22 Mar 2004 08:00:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5P1o-000585-00 for disman@ietf.org; Mon, 22 Mar 2004 07:59:41 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1B5P12-0004yZ-00; Mon, 22 Mar 2004 07:58:52 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Mon, 22 Mar 2004 05:58:21 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: , , Cc: Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part5E7F4DCA.1__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Mar 2004 05:58:02 -0700 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part5E7F4DCA.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Dan, For a moment I want to focus on getting the WG to understand the need for standardization of the proposed features. I want to seek WG help in deciding either for the new standard or extending the existing standard. Regards, Shailaja. >>> "Romascanu, Dan (Dan)" 3/18/2004 7:49:00 PM >>> ... and this brings exactly the two issues that I am trying to point to: as at least a partial solution exists to the problems that your I-D tries to solve, do the additional functionality and optimizations justify new standards work? assuming the answer is yes to the above, should we not consider rather extending the existing RMON design, and try to ensure to the possible extend backwards compatibility to existing RMON MIBs? Regards,Dan-----Original Message----- From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On Behalf Of Shailaja Yadawad Sent: 18 March, 2004 12:40 PM To: Romascanu, Dan (Dan); disman@ietf.org; randy_presuhn@mindspring.com Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Dan, >I was not going that far, and actually I did not have the expression MIB in mind. Expression MIB can be modified based on some of our features. >What I am seeing are mechanisms like RMON alarm and usrHistory being reinvented, and >objects like ituSeverity from the Alarm MIB being duplicated. you are correct that our draft contains object definition similar to that of RMON alarm and usrHistory but with additional features and changes. Regards, Shailaja. --=__Part5E7F4DCA.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dan,
 
For a moment I want to focus on getting the WG to understand the need = for standardization of the proposed features.
 
I want to seek WG help in deciding either for the new = standard or extending the existing standard. 
 
Regards,
Shailaja.  

>>> "Romascanu, Dan (Dan)" <dromasca@avaya.com> = 3/18/2004 7:49:00 PM >>>
... and this brings exactly the two = issues that I am trying to point to:
  • as at least a partial solution exists = to the problems that your I-D tries to solve, do the additional functionali= ty and optimizations justify new standards work?=20
  • assuming the answer is yes to the = above, should we not consider rather extending the existing RMON design, = and try to ensure to the possible extend backwards compatibility to = existing RMON MIBs?
 

Regards,

Dan

-----Original Message-----
From: disman-admin@ietf.org = [mailto:disman-admin@ietf.org]On Behalf Of Shailaja Yadawad
Se= nt: 18 March, 2004 12:40 PM
To: Romascanu, Dan (Dan); = disman@ietf.org; randy_presuhn@mindspring.com
Subject: RE: = [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt
Dan,
 
>I was not going = that far, and actually I did not have the expression MIB in mind. =
Expression MIB can be modified based on some of our features.

>What I am seeing are mechanisms like RMON alarm and usrHistory= being reinvented, and >objects like ituSeverity from the Alarm MIB = being duplicated.

you are correct that our draft contains object = definition similar to that of  RMON alarm and usrHistory but = with additional features and changes.
 
Regards,
Shailaja.
--=__Part5E7F4DCA.1__=-- From exim@www1.ietf.org Mon Mar 22 08:02:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21636 for ; Mon, 22 Mar 2004 08:02:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5P4Y-00052R-EL for disman-archive@odin.ietf.org; Mon, 22 Mar 2004 08:02:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MD2UUR019361 for disman-archive@odin.ietf.org; Mon, 22 Mar 2004 08:02:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5P4Y-00052C-Ad for disman-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 08:02:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21621 for ; Mon, 22 Mar 2004 08:02:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5P4X-0005RW-00 for disman-web-archive@ietf.org; Mon, 22 Mar 2004 08:02:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5P3f-0005Ll-00 for disman-web-archive@ietf.org; Mon, 22 Mar 2004 08:01:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5P38-0005Fv-00 for disman-web-archive@ietf.org; Mon, 22 Mar 2004 08:01:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5P37-0004pr-Qa; Mon, 22 Mar 2004 08:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5P2j-0004oP-Ki for disman@optimus.ietf.org; Mon, 22 Mar 2004 08:00:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21483 for ; Mon, 22 Mar 2004 08:00:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5P2i-0005Ee-00 for disman@ietf.org; Mon, 22 Mar 2004 08:00:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5P1o-000585-00 for disman@ietf.org; Mon, 22 Mar 2004 07:59:41 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1B5P12-0004yZ-00; Mon, 22 Mar 2004 07:58:52 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Mon, 22 Mar 2004 05:58:21 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: , , Cc: Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part5E7F4DCA.1__=" Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Mar 2004 05:58:02 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part5E7F4DCA.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Dan, For a moment I want to focus on getting the WG to understand the need for standardization of the proposed features. I want to seek WG help in deciding either for the new standard or extending the existing standard. Regards, Shailaja. >>> "Romascanu, Dan (Dan)" 3/18/2004 7:49:00 PM >>> ... and this brings exactly the two issues that I am trying to point to: as at least a partial solution exists to the problems that your I-D tries to solve, do the additional functionality and optimizations justify new standards work? assuming the answer is yes to the above, should we not consider rather extending the existing RMON design, and try to ensure to the possible extend backwards compatibility to existing RMON MIBs? Regards,Dan-----Original Message----- From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On Behalf Of Shailaja Yadawad Sent: 18 March, 2004 12:40 PM To: Romascanu, Dan (Dan); disman@ietf.org; randy_presuhn@mindspring.com Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Dan, >I was not going that far, and actually I did not have the expression MIB in mind. Expression MIB can be modified based on some of our features. >What I am seeing are mechanisms like RMON alarm and usrHistory being reinvented, and >objects like ituSeverity from the Alarm MIB being duplicated. you are correct that our draft contains object definition similar to that of RMON alarm and usrHistory but with additional features and changes. Regards, Shailaja. --=__Part5E7F4DCA.1__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dan,
 
For a moment I want to focus on getting the WG to understand the need = for standardization of the proposed features.
 
I want to seek WG help in deciding either for the new = standard or extending the existing standard. 
 
Regards,
Shailaja.  

>>> "Romascanu, Dan (Dan)" <dromasca@avaya.com> = 3/18/2004 7:49:00 PM >>>
... and this brings exactly the two = issues that I am trying to point to:
  • as at least a partial solution exists = to the problems that your I-D tries to solve, do the additional functionali= ty and optimizations justify new standards work?=20
  • assuming the answer is yes to the = above, should we not consider rather extending the existing RMON design, = and try to ensure to the possible extend backwards compatibility to = existing RMON MIBs?
 

Regards,

Dan

-----Original Message-----
From: disman-admin@ietf.org = [mailto:disman-admin@ietf.org]On Behalf Of Shailaja Yadawad
Se= nt: 18 March, 2004 12:40 PM
To: Romascanu, Dan (Dan); = disman@ietf.org; randy_presuhn@mindspring.com
Subject: RE: = [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt
Dan,
 
>I was not going = that far, and actually I did not have the expression MIB in mind. =
Expression MIB can be modified based on some of our features.

>What I am seeing are mechanisms like RMON alarm and usrHistory= being reinvented, and >objects like ituSeverity from the Alarm MIB = being duplicated.

you are correct that our draft contains object = definition similar to that of  RMON alarm and usrHistory but = with additional features and changes.
 
Regards,
Shailaja.
--=__Part5E7F4DCA.1__=-- From disman-admin@ietf.org Mon Mar 22 08:14:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22240 for ; Mon, 22 Mar 2004 08:14:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PG9-000614-BP; Mon, 22 Mar 2004 08:14:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PFI-0005zK-DQ for disman@optimus.ietf.org; Mon, 22 Mar 2004 08:13:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22133 for ; Mon, 22 Mar 2004 08:13:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5PFH-0006hx-00 for disman@ietf.org; Mon, 22 Mar 2004 08:13:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5PEJ-0006a2-00 for disman@ietf.org; Mon, 22 Mar 2004 08:12:36 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1B5PDT-0006TV-00; Mon, 22 Mar 2004 08:11:43 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2MDAdgL011080; Mon, 22 Mar 2004 08:10:39 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2MDAbgL011053; Mon, 22 Mar 2004 08:10:38 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4100F.364EEF56" Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Thread-Index: AcQQDdwMOcZvDsbOS+i8dMmIA0omrwAAVVWw From: "Romascanu, Dan (Dan)" To: "Shailaja Yadawad" , , Cc: X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Mar 2004 15:11:39 +0200 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4100F.364EEF56 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ... and that's fine with me. At this point the right questions are - I = think - on the table, and Andy's answer helped by clarifying the issue = of the relationship with the existing RMON MIB modules from the = perspective of the RMON WG. =20 Let us see what other people have to say, if they have an opinion. =20 Regards, Dan -----Original Message----- From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On Behalf Of = Shailaja Yadawad Sent: 22 March, 2004 2:58 PM To: Romascanu, Dan (Dan); disman@ietf.org; randy_presuhn@mindspring.com Cc: rmonmib@ietf.org Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Dan, =20 For a moment I want to focus on getting the WG to understand the need = for standardization of the proposed features. =20 I want to seek WG help in deciding either for the new standard or = extending the existing standard.=20 =20 Regards, Shailaja. =20 >>> "Romascanu, Dan (Dan)" 3/18/2004 7:49:00 PM >>> ... and this brings exactly the two issues that I am trying to point to: * as at least a partial solution exists to the problems that your I-D = tries to solve, do the additional functionality and optimizations = justify new standards work?=20 * assuming the answer is yes to the above, should we not consider rather = extending the existing RMON design, and try to ensure to the possible = extend backwards compatibility to existing RMON MIBs? =20 Regards, Dan -----Original Message----- From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On Behalf Of = Shailaja Yadawad Sent: 18 March, 2004 12:40 PM To: Romascanu, Dan (Dan); disman@ietf.org; randy_presuhn@mindspring.com Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Dan, =20 >I was not going that far, and actually I did not have the expression = MIB in mind.=20 Expression MIB can be modified based on some of our features. >What I am seeing are mechanisms like RMON alarm and usrHistory being = reinvented, and >objects like ituSeverity from the Alarm MIB being = duplicated. you are correct that our draft contains object definition similar to = that of RMON alarm and usrHistory but with additional features and = changes. =20 Regards, Shailaja. ------_=_NextPart_001_01C4100F.364EEF56 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
... and that's fine with me. At = this point=20 the right questions are - I think - on the table, and Andy's answer = helped by=20 clarifying the issue of the relationship with the existing RMON MIB = modules from=20 the perspective of the RMON WG.
 
Let us see=20 what other people have to say, if they have an = opinion.
 

Regards,

Dan

-----Original Message-----
From: = disman-admin@ietf.org=20 [mailto:disman-admin@ietf.org]On Behalf Of Shailaja=20 Yadawad
Sent: 22 March, 2004 2:58 PM
To: = Romascanu, Dan=20 (Dan); disman@ietf.org; randy_presuhn@mindspring.com
Cc:=20 rmonmib@ietf.org
Subject: RE: [Disman] Fw: I-D=20 ACTION:draft-yadawad-disman-ahcf-00.txt

Dan,
 
For a moment I want to focus on getting the WG to understand the = need for=20 standardization of the proposed features.
 
I want to seek WG help in deciding either for the = new=20 standard or extending the existing standard. 
 
Regards,
Shailaja.  

>>> "Romascanu, Dan (Dan)" = <dromasca@avaya.com>=20 3/18/2004 7:49:00 PM >>>
... and this brings exactly the = two issues=20 that I am trying to point to:
  • as at least a partial solution = exists to=20 the problems that your I-D tries to solve, do the additional = functionality=20 and optimizations justify new standards work?=20
  • assuming the answer is yes to = the above,=20 should we not consider rather extending the existing RMON design, = and try to=20 ensure to the possible extend backwards compatibility to existing = RMON=20 MIBs?
 

Regards,

Dan

-----Original Message-----
From: = disman-admin@ietf.org=20 [mailto:disman-admin@ietf.org]On Behalf Of Shailaja=20 Yadawad
Sent: 18 March, 2004 12:40 PM
To: = Romascanu, Dan=20 (Dan); disman@ietf.org; = randy_presuhn@mindspring.com
Subject: RE:=20 [Disman] Fw: I-D=20 ACTION:draft-yadawad-disman-ahcf-00.txt

Dan,
 
>I was not = going that=20 far, and actually I did not have the expression MIB in mind. =
Expression MIB can be modified based on some of our = features.

>What I am seeing are mechanisms like RMON alarm and = usrHistory=20 being reinvented, and >objects like ituSeverity from the Alarm = MIB being=20 duplicated.

you are correct that our draft contains object = definition=20 similar to that of  RMON alarm and usrHistory but = with additional=20 features and changes.
 
Regards,
Shailaja.
------_=_NextPart_001_01C4100F.364EEF56-- From disman-admin@ietf.org Mon Mar 22 08:15:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22338 for ; Mon, 22 Mar 2004 08:15:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PGf-00068X-Ng; Mon, 22 Mar 2004 08:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PGD-00063Z-TJ for disman@optimus.ietf.org; Mon, 22 Mar 2004 08:14:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22218 for ; Mon, 22 Mar 2004 08:14:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5PGC-0006pU-00 for disman@ietf.org; Mon, 22 Mar 2004 08:14:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5PFU-0006jh-00 for disman@ietf.org; Mon, 22 Mar 2004 08:13:49 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1B5PEk-0006ZR-00; Mon, 22 Mar 2004 08:13:02 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Mon, 22 Mar 2004 06:12:32 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: , Cc: , , Subject: Re: [RMONMIB] RE: [Disman] Fw: I-DACTION:draft-yadawad-disman-ahcf-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartB697A526.2__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Mar 2004 06:12:22 -0700 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartB697A526.2__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, >For the threshold wildcard features: >Although this MIB appears to overlap the Expression MIB, >it's much easier to use and it's focused on the persistent >index problem, not the on-the-box data reduction problem. >This MIB is a well-designed band-aid for the (lack of) >persistent index problem. Andy, you are very correct in pointing out the features of the draft. Our main motivation was to provide easy and simple configuration ability to the user and solving the persistent index problem. >Unfortunately, the persistent index problem impacts application >polling even worse than embedded polling. Customers are >demanding that we get rid or our arbitrarily renumbered integer >index objects (like ifIndex and entPhysicalIndex) by making the >index assignments persist across reboots. So that's what >we're doing -- addressing the core problem. I am bit new to IETF and hence could you please point me to some drafts/standards in this regard. > * assuming the answer is yes to the above, should we not consider rather extending the >existing RMON design, and try to ensure to the possible extend backwards compatibility to >existing RMON MIBs? >You are thinking of perhaps adding the threshold wildcard >feature to the usrHistoryControlTable and usrHistoryObjectTable, >and leaving the data (usrHistoryTable) untouched? >Unless there is massive interest from the RMONMIB WG to >re-open the RMON-2 usrHistory group for this feature, >I don't think this approach is viable. I request both(disman and rmon) WG members to share their thoughts on our draft. http://www.ietf.org/internet-drafts/draft-yadawad-disman-ahcf-00.txt Regards, Shailaja. --=__PartB697A526.2__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

>For the threshold wildcard features:
>Although this MIB = appears to overlap the Expression MIB,
>it's much easier to use and = it's focused on the persistent
>index problem, not the on-the-box = data reduction problem.
>This MIB is a well-designed band-aid for = the (lack of)
>persistent index problem.
Andy, you are very correct in pointing out the features of the draft. = Our main motivation
was to provide easy and simple configuration ability to the user and = solving the persistent index
problem.
 
>Unfortunately, the persistent index problem impacts application>polling even worse than embedded polling.  Customers are
>d= emanding that we get rid or our arbitrarily renumbered integer
>inde= x objects (like ifIndex and entPhysicalIndex) by making the
>index = assignments persist across reboots.  So that's what
>we're = doing -- addressing the core problem.
I am bit new to IETF and hence could you please point me to some = drafts/standards in this regard.

>    * assuming the answer is yes to the above, = should we not consider rather extending the >existing RMON design, and = try to ensure to the possible extend backwards compatibility to >existin= g RMON MIBs?
>You are thinking of perhaps adding the threshold = wildcard
>feature to the usrHistoryControlTable and usrHistoryObjectT= able,
>and leaving the data (usrHistoryTable) untouched?
>Unles= s there is massive interest from the RMONMIB WG to
>re-open the = RMON-2 usrHistory group for this feature,
>I don't think this = approach is viable.

I request both(disman and rmon) WG = members to share their thoughts on our draft.
 
Regards,
Shailaja.
--=__PartB697A526.2__=-- From exim@www1.ietf.org Mon Mar 22 08:16:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22484 for ; Mon, 22 Mar 2004 08:16:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PHz-0006Od-PC for disman-archive@odin.ietf.org; Mon, 22 Mar 2004 08:16:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MDGNMn024581 for disman-archive@odin.ietf.org; Mon, 22 Mar 2004 08:16:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PHz-0006OO-Li for disman-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 08:16:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22402 for ; Mon, 22 Mar 2004 08:16:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5PHy-00072G-00 for disman-web-archive@ietf.org; Mon, 22 Mar 2004 08:16:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5PH3-0006vI-00 for disman-web-archive@ietf.org; Mon, 22 Mar 2004 08:15:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5PG9-0006p3-00 for disman-web-archive@ietf.org; Mon, 22 Mar 2004 08:14:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PG9-000614-BP; Mon, 22 Mar 2004 08:14:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PFI-0005zK-DQ for disman@optimus.ietf.org; Mon, 22 Mar 2004 08:13:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22133 for ; Mon, 22 Mar 2004 08:13:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5PFH-0006hx-00 for disman@ietf.org; Mon, 22 Mar 2004 08:13:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5PEJ-0006a2-00 for disman@ietf.org; Mon, 22 Mar 2004 08:12:36 -0500 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1B5PDT-0006TV-00; Mon, 22 Mar 2004 08:11:43 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2MDAdgL011080; Mon, 22 Mar 2004 08:10:39 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i2MDAbgL011053; Mon, 22 Mar 2004 08:10:38 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4100F.364EEF56" Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt X-MIMEOLE: Produced By Microsoft Exchange V6.0.6487.1 Message-ID: Thread-Topic: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Thread-Index: AcQQDdwMOcZvDsbOS+i8dMmIA0omrwAAVVWw From: "Romascanu, Dan (Dan)" To: "Shailaja Yadawad" , , Cc: Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Mar 2004 15:11:39 +0200 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,HTML_20_30,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C4100F.364EEF56 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ... and that's fine with me. At this point the right questions are - I = think - on the table, and Andy's answer helped by clarifying the issue = of the relationship with the existing RMON MIB modules from the = perspective of the RMON WG. =20 Let us see what other people have to say, if they have an opinion. =20 Regards, Dan -----Original Message----- From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On Behalf Of = Shailaja Yadawad Sent: 22 March, 2004 2:58 PM To: Romascanu, Dan (Dan); disman@ietf.org; randy_presuhn@mindspring.com Cc: rmonmib@ietf.org Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Dan, =20 For a moment I want to focus on getting the WG to understand the need = for standardization of the proposed features. =20 I want to seek WG help in deciding either for the new standard or = extending the existing standard.=20 =20 Regards, Shailaja. =20 >>> "Romascanu, Dan (Dan)" 3/18/2004 7:49:00 PM >>> ... and this brings exactly the two issues that I am trying to point to: * as at least a partial solution exists to the problems that your I-D = tries to solve, do the additional functionality and optimizations = justify new standards work?=20 * assuming the answer is yes to the above, should we not consider rather = extending the existing RMON design, and try to ensure to the possible = extend backwards compatibility to existing RMON MIBs? =20 Regards, Dan -----Original Message----- From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On Behalf Of = Shailaja Yadawad Sent: 18 March, 2004 12:40 PM To: Romascanu, Dan (Dan); disman@ietf.org; randy_presuhn@mindspring.com Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Dan, =20 >I was not going that far, and actually I did not have the expression = MIB in mind.=20 Expression MIB can be modified based on some of our features. >What I am seeing are mechanisms like RMON alarm and usrHistory being = reinvented, and >objects like ituSeverity from the Alarm MIB being = duplicated. you are correct that our draft contains object definition similar to = that of RMON alarm and usrHistory but with additional features and = changes. =20 Regards, Shailaja. ------_=_NextPart_001_01C4100F.364EEF56 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
... and that's fine with me. At = this point=20 the right questions are - I think - on the table, and Andy's answer = helped by=20 clarifying the issue of the relationship with the existing RMON MIB = modules from=20 the perspective of the RMON WG.
 
Let us see=20 what other people have to say, if they have an = opinion.
 

Regards,

Dan

-----Original Message-----
From: = disman-admin@ietf.org=20 [mailto:disman-admin@ietf.org]On Behalf Of Shailaja=20 Yadawad
Sent: 22 March, 2004 2:58 PM
To: = Romascanu, Dan=20 (Dan); disman@ietf.org; randy_presuhn@mindspring.com
Cc:=20 rmonmib@ietf.org
Subject: RE: [Disman] Fw: I-D=20 ACTION:draft-yadawad-disman-ahcf-00.txt

Dan,
 
For a moment I want to focus on getting the WG to understand the = need for=20 standardization of the proposed features.
 
I want to seek WG help in deciding either for the = new=20 standard or extending the existing standard. 
 
Regards,
Shailaja.  

>>> "Romascanu, Dan (Dan)" = <dromasca@avaya.com>=20 3/18/2004 7:49:00 PM >>>
... and this brings exactly the = two issues=20 that I am trying to point to:
  • as at least a partial solution = exists to=20 the problems that your I-D tries to solve, do the additional = functionality=20 and optimizations justify new standards work?=20
  • assuming the answer is yes to = the above,=20 should we not consider rather extending the existing RMON design, = and try to=20 ensure to the possible extend backwards compatibility to existing = RMON=20 MIBs?
 

Regards,

Dan

-----Original Message-----
From: = disman-admin@ietf.org=20 [mailto:disman-admin@ietf.org]On Behalf Of Shailaja=20 Yadawad
Sent: 18 March, 2004 12:40 PM
To: = Romascanu, Dan=20 (Dan); disman@ietf.org; = randy_presuhn@mindspring.com
Subject: RE:=20 [Disman] Fw: I-D=20 ACTION:draft-yadawad-disman-ahcf-00.txt

Dan,
 
>I was not = going that=20 far, and actually I did not have the expression MIB in mind. =
Expression MIB can be modified based on some of our = features.

>What I am seeing are mechanisms like RMON alarm and = usrHistory=20 being reinvented, and >objects like ituSeverity from the Alarm = MIB being=20 duplicated.

you are correct that our draft contains object = definition=20 similar to that of  RMON alarm and usrHistory but = with additional=20 features and changes.
 
Regards,
Shailaja.
------_=_NextPart_001_01C4100F.364EEF56-- From exim@www1.ietf.org Mon Mar 22 08:16:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22503 for ; Mon, 22 Mar 2004 08:16:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PI6-0006Rm-FN for disman-archive@odin.ietf.org; Mon, 22 Mar 2004 08:16:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MDGU0P024776 for disman-archive@odin.ietf.org; Mon, 22 Mar 2004 08:16:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PI6-0006RX-BP for disman-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 08:16:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22428 for ; Mon, 22 Mar 2004 08:16:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5PI4-00073A-00 for disman-web-archive@ietf.org; Mon, 22 Mar 2004 08:16:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5PHF-0006xC-00 for disman-web-archive@ietf.org; Mon, 22 Mar 2004 08:15:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5PGf-0006qs-00 for disman-web-archive@ietf.org; Mon, 22 Mar 2004 08:15:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PGf-00068X-Ng; Mon, 22 Mar 2004 08:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PGD-00063Z-TJ for disman@optimus.ietf.org; Mon, 22 Mar 2004 08:14:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22218 for ; Mon, 22 Mar 2004 08:14:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5PGC-0006pU-00 for disman@ietf.org; Mon, 22 Mar 2004 08:14:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5PFU-0006jh-00 for disman@ietf.org; Mon, 22 Mar 2004 08:13:49 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1B5PEk-0006ZR-00; Mon, 22 Mar 2004 08:13:02 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Mon, 22 Mar 2004 06:12:32 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: , Cc: , , Subject: Re: [RMONMIB] RE: [Disman] Fw: I-DACTION:draft-yadawad-disman-ahcf-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartB697A526.2__=" Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Mar 2004 06:12:22 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartB697A526.2__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, >For the threshold wildcard features: >Although this MIB appears to overlap the Expression MIB, >it's much easier to use and it's focused on the persistent >index problem, not the on-the-box data reduction problem. >This MIB is a well-designed band-aid for the (lack of) >persistent index problem. Andy, you are very correct in pointing out the features of the draft. Our main motivation was to provide easy and simple configuration ability to the user and solving the persistent index problem. >Unfortunately, the persistent index problem impacts application >polling even worse than embedded polling. Customers are >demanding that we get rid or our arbitrarily renumbered integer >index objects (like ifIndex and entPhysicalIndex) by making the >index assignments persist across reboots. So that's what >we're doing -- addressing the core problem. I am bit new to IETF and hence could you please point me to some drafts/standards in this regard. > * assuming the answer is yes to the above, should we not consider rather extending the >existing RMON design, and try to ensure to the possible extend backwards compatibility to >existing RMON MIBs? >You are thinking of perhaps adding the threshold wildcard >feature to the usrHistoryControlTable and usrHistoryObjectTable, >and leaving the data (usrHistoryTable) untouched? >Unless there is massive interest from the RMONMIB WG to >re-open the RMON-2 usrHistory group for this feature, >I don't think this approach is viable. I request both(disman and rmon) WG members to share their thoughts on our draft. http://www.ietf.org/internet-drafts/draft-yadawad-disman-ahcf-00.txt Regards, Shailaja. --=__PartB697A526.2__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

>For the threshold wildcard features:
>Although this MIB = appears to overlap the Expression MIB,
>it's much easier to use and = it's focused on the persistent
>index problem, not the on-the-box = data reduction problem.
>This MIB is a well-designed band-aid for = the (lack of)
>persistent index problem.
Andy, you are very correct in pointing out the features of the draft. = Our main motivation
was to provide easy and simple configuration ability to the user and = solving the persistent index
problem.
 
>Unfortunately, the persistent index problem impacts application>polling even worse than embedded polling.  Customers are
>d= emanding that we get rid or our arbitrarily renumbered integer
>inde= x objects (like ifIndex and entPhysicalIndex) by making the
>index = assignments persist across reboots.  So that's what
>we're = doing -- addressing the core problem.
I am bit new to IETF and hence could you please point me to some = drafts/standards in this regard.

>    * assuming the answer is yes to the above, = should we not consider rather extending the >existing RMON design, and = try to ensure to the possible extend backwards compatibility to >existin= g RMON MIBs?
>You are thinking of perhaps adding the threshold = wildcard
>feature to the usrHistoryControlTable and usrHistoryObjectT= able,
>and leaving the data (usrHistoryTable) untouched?
>Unles= s there is massive interest from the RMONMIB WG to
>re-open the = RMON-2 usrHistory group for this feature,
>I don't think this = approach is viable.

I request both(disman and rmon) WG = members to share their thoughts on our draft.
 
Regards,
Shailaja.
--=__PartB697A526.2__=-- From disman-admin@ietf.org Mon Mar 22 08:28:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22931 for ; Mon, 22 Mar 2004 08:28:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PTQ-0007bh-8N; Mon, 22 Mar 2004 08:28:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PSf-0007Oe-6h for disman@optimus.ietf.org; Mon, 22 Mar 2004 08:27:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22842 for ; Mon, 22 Mar 2004 08:27:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5PSe-0000P7-00 for disman@ietf.org; Mon, 22 Mar 2004 08:27:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5PRi-0000IT-00 for disman@ietf.org; Mon, 22 Mar 2004 08:26:26 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1B5PQp-00007h-00; Mon, 22 Mar 2004 08:25:31 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Mon, 22 Mar 2004 06:25:00 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: , Cc: Subject: Re: [RMONMIB] RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part96B78509.0__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Mar 2004 06:24:41 -0700 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part96B78509.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi >Since there is substantial overlap in the membership of the two >working groups, can we confine this discussion to just one of the >WG lists? I suggest that we continue discussion on the disman >list. If consensus develops that there is a problem to be solved >along with a general sense what technical approach we'd like >to use, then Andy and I could consult with Bert (our Area Director) >to figure out whether the work would make sense for either working >group, a new working group, or whatever. I am fine with this approach. Sorry, I saw this mail now after I posted my previous mail. Here onwards will confine my mail discussion to disman WG. Regards, Shailaja. --=__Part96B78509.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi
 
>Since there is substantial overlap in the membership of the = two
>working groups, can we confine this discussion to just one of = the
>WG lists?  I suggest that we continue discussion on the = disman
>list.  If consensus develops that there is a problem to = be solved
>along with a general sense  what technical approach = we'd like
>to use, then Andy and I could consult with Bert (our Area = Director)
>to figure out whether the work would make sense for = either working
>group, a new working group, or whatever.
I am fine with this approach. Sorry, I saw this mail now after I = posted my previous mail. Here onwards will confine my mail discussion to = disman WG.

Regards,
Shailaja.
 
--=__Part96B78509.0__=-- From disman-admin@ietf.org Mon Mar 22 09:34:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27369 for ; Mon, 22 Mar 2004 09:34:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5QV7-0007r4-C9; Mon, 22 Mar 2004 09:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5QUf-0007qL-Ae for disman@optimus.ietf.org; Mon, 22 Mar 2004 09:33:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27355 for ; Mon, 22 Mar 2004 09:33:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5QUd-0001dE-00 for disman@ietf.org; Mon, 22 Mar 2004 09:33:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5QTt-0001Wz-00 for disman@ietf.org; Mon, 22 Mar 2004 09:32:45 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5QTC-0001Kv-00 for disman@ietf.org; Mon, 22 Mar 2004 09:32:02 -0500 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2MEVTK2020327; Mon, 22 Mar 2004 06:31:29 -0800 (PST) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn4-474.cisco.com [10.21.81.218]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ASD65720; Mon, 22 Mar 2004 06:31:29 -0800 (PST) Message-Id: <6.0.3.0.2.20040322061418.028e38b0@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 To: "Shailaja Yadawad" From: Andy Bierman Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Cc: , , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Mar 2004 06:27:53 -0800 At 02:41 AM 3/18/2004, Shailaja Yadawad wrote: IMO, the problem worth addressing in the IETF is the detrimental effect of arbitrary renumbering of object instance identifiers after a reboot. This is a general problem, not related to DISMAN or RMONMIB. Perhaps some ideas in this draft could be used to solve the general problem. We have a proprietary solution -- save enough info in NV-storage (e.g., the ifName or ifAlias) to reassign the same index values after a reboot and avoid renumbering "returning" instances altogether. Optimizations to the usrHistory group should be done in a new MIB module without impacting the existing RMON-2 conformance. Andy >Dan, > >As mentioned in the draft following are the features > >Simple configuration and Instance Management : suppose if the user wants to configure history collection for all the instances of the columnar oid, using RMON object definition the user has to configure for each instance individually where as using our object definition, it is just one configuration setting. > >It has to be noted here that the user has the option of applying same configuration settings to all the instances or can fine tune the configuration setting for desired instances. > >RMON2 user history object definition does not take care of newly added and deleted instances and hence if the new instances are added the user has to configure for the new instances manually. > >Consistent reference to the resource: >History collection activity can be for a long duration and hence it is important to provide consistent reference of collected history to the underlying physical media. This kind of feature is seen only interface group however if user needs this kind of ability for any oid that is being trended. > > >Instance Filtering > >Istance filtering is not available in RMON user history mib. > >Threshold Monitoring >Yes, threshold monitoring is available in the alarm table but if user wants a complete solution of history collection and threshold monitoring in a single object definition, our mib definition provides the solution. > >Dan, see it this way, the above mentioned features are seen in many mibs but user needs one mib which has all required features as otherwise it is difficult for the user to implement multiple mibs for one problem. > >Regards, >Shailaja. > > >>>> "Romascanu, Dan (Dan)" 3/18/2004 12:48:59 AM >>> >I will repeat a comment that I made during the meeting in Seoul. I think that all, or almost all that is being defined in this MIB module can already be performed - some features even in multiple ways - by agents that implement existing MIB modules like RMON, Events MIB, and Alarm MIB. I think that it would help the discussion if the authors could shortly describe what is the added value that this MIB module would bring, and what operations/management functions this MIB module provides that are not covered by existing MIB modules. > >Thanks and Regards, > >Dan > > > >> -----Original Message----- >> From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On >> Behalf Of Randy Presuhn >> Sent: 17 March, 2004 8:55 PM >> To: Disman (E-mail) >> Subject: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt >> >> >> Hi - >> >> I'd welcome discussion of this on the disman mailing list. >> I think it's relevant to the question of what to do about the >> expression and event MIBs. >> >> Randy >> >> > From: >> > To: >> > Sent: Wednesday, March 17, 2004 8:10 AM >> > Subject: I-D ACTION:draft-yadawad-disman-ahcf-00.txt >> > >> >> > A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> > >> > >> > Title : Advanced History Collection Framework >> > Author(s) : S. Yadawad, H. Kumar, H. Yamijala, R. Shekar >> > Filename : draft-yadawad-disman-ahcf-00.txt >> > Pages : 47 >> > Date : 2004-3-17 >> > >> > This draft defines a portion of the Management Information Base for >> > use with network management protocols in TCP/IP based >> Internets. In >> > particular, it defines objects for configuring and >> controlling the >> > history collection of user specified Data, which is an ASN.1 >> > INTEGER based object. >> > >> > A URL for this Internet-Draft is: >> > http://www.ietf.org/internet-drafts/draft-yadawad-disman-ahcf-00.txt >> > >> ... >> >> >> >> From exim@www1.ietf.org Mon Mar 22 09:36:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27415 for ; Mon, 22 Mar 2004 09:36:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5QWj-00085H-14 for disman-archive@odin.ietf.org; Mon, 22 Mar 2004 09:35:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MEZfNf031074 for disman-archive@odin.ietf.org; Mon, 22 Mar 2004 09:35:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5QWi-000857-TN for disman-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 09:35:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27408 for ; Mon, 22 Mar 2004 09:35:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5QWg-0001wy-00 for disman-web-archive@ietf.org; Mon, 22 Mar 2004 09:35:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5QVt-0001pe-00 for disman-web-archive@ietf.org; Mon, 22 Mar 2004 09:34:50 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5QVG-0001iN-00 for disman-web-archive@ietf.org; Mon, 22 Mar 2004 09:34:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B5QVH-0007q2-B0 for disman-web-archive@ietf.org; Mon, 22 Mar 2004 09:34:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5QV7-0007r4-C9; Mon, 22 Mar 2004 09:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5QUf-0007qL-Ae for disman@optimus.ietf.org; Mon, 22 Mar 2004 09:33:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27355 for ; Mon, 22 Mar 2004 09:33:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5QUd-0001dE-00 for disman@ietf.org; Mon, 22 Mar 2004 09:33:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5QTt-0001Wz-00 for disman@ietf.org; Mon, 22 Mar 2004 09:32:45 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B5QTC-0001Kv-00 for disman@ietf.org; Mon, 22 Mar 2004 09:32:02 -0500 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2MEVTK2020327; Mon, 22 Mar 2004 06:31:29 -0800 (PST) Received: from ABIERMAN-W2K.cisco.com (sjc-vpn4-474.cisco.com [10.21.81.218]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ASD65720; Mon, 22 Mar 2004 06:31:29 -0800 (PST) Message-Id: <6.0.3.0.2.20040322061418.028e38b0@fedex.cisco.com> X-Sender: abierman@fedex.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0 To: "Shailaja Yadawad" From: Andy Bierman Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Cc: , , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Mar 2004 06:27:53 -0800 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 At 02:41 AM 3/18/2004, Shailaja Yadawad wrote: IMO, the problem worth addressing in the IETF is the detrimental effect of arbitrary renumbering of object instance identifiers after a reboot. This is a general problem, not related to DISMAN or RMONMIB. Perhaps some ideas in this draft could be used to solve the general problem. We have a proprietary solution -- save enough info in NV-storage (e.g., the ifName or ifAlias) to reassign the same index values after a reboot and avoid renumbering "returning" instances altogether. Optimizations to the usrHistory group should be done in a new MIB module without impacting the existing RMON-2 conformance. Andy >Dan, > >As mentioned in the draft following are the features > >Simple configuration and Instance Management : suppose if the user wants to configure history collection for all the instances of the columnar oid, using RMON object definition the user has to configure for each instance individually where as using our object definition, it is just one configuration setting. > >It has to be noted here that the user has the option of applying same configuration settings to all the instances or can fine tune the configuration setting for desired instances. > >RMON2 user history object definition does not take care of newly added and deleted instances and hence if the new instances are added the user has to configure for the new instances manually. > >Consistent reference to the resource: >History collection activity can be for a long duration and hence it is important to provide consistent reference of collected history to the underlying physical media. This kind of feature is seen only interface group however if user needs this kind of ability for any oid that is being trended. > > >Instance Filtering > >Istance filtering is not available in RMON user history mib. > >Threshold Monitoring >Yes, threshold monitoring is available in the alarm table but if user wants a complete solution of history collection and threshold monitoring in a single object definition, our mib definition provides the solution. > >Dan, see it this way, the above mentioned features are seen in many mibs but user needs one mib which has all required features as otherwise it is difficult for the user to implement multiple mibs for one problem. > >Regards, >Shailaja. > > >>>> "Romascanu, Dan (Dan)" 3/18/2004 12:48:59 AM >>> >I will repeat a comment that I made during the meeting in Seoul. I think that all, or almost all that is being defined in this MIB module can already be performed - some features even in multiple ways - by agents that implement existing MIB modules like RMON, Events MIB, and Alarm MIB. I think that it would help the discussion if the authors could shortly describe what is the added value that this MIB module would bring, and what operations/management functions this MIB module provides that are not covered by existing MIB modules. > >Thanks and Regards, > >Dan > > > >> -----Original Message----- >> From: disman-admin@ietf.org [mailto:disman-admin@ietf.org]On >> Behalf Of Randy Presuhn >> Sent: 17 March, 2004 8:55 PM >> To: Disman (E-mail) >> Subject: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt >> >> >> Hi - >> >> I'd welcome discussion of this on the disman mailing list. >> I think it's relevant to the question of what to do about the >> expression and event MIBs. >> >> Randy >> >> > From: >> > To: >> > Sent: Wednesday, March 17, 2004 8:10 AM >> > Subject: I-D ACTION:draft-yadawad-disman-ahcf-00.txt >> > >> >> > A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> > >> > >> > Title : Advanced History Collection Framework >> > Author(s) : S. Yadawad, H. Kumar, H. Yamijala, R. Shekar >> > Filename : draft-yadawad-disman-ahcf-00.txt >> > Pages : 47 >> > Date : 2004-3-17 >> > >> > This draft defines a portion of the Management Information Base for >> > use with network management protocols in TCP/IP based >> Internets. In >> > particular, it defines objects for configuring and >> controlling the >> > history collection of user specified Data, which is an ASN.1 >> > INTEGER based object. >> > >> > A URL for this Internet-Draft is: >> > http://www.ietf.org/internet-drafts/draft-yadawad-disman-ahcf-00.txt >> > >> ... >> >> >> >> From disman-admin@ietf.org Tue Mar 23 08:31:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25238 for ; Tue, 23 Mar 2004 08:31:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5lzi-0004dI-GY; Tue, 23 Mar 2004 08:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5lyx-0004VK-50 for disman@optimus.ietf.org; Tue, 23 Mar 2004 08:30:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25164 for ; Tue, 23 Mar 2004 08:30:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5lyv-0000m1-00 for disman@ietf.org; Tue, 23 Mar 2004 08:30:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5ly4-0000ev-00 for disman@ietf.org; Tue, 23 Mar 2004 08:29:21 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1B5lxA-0000Qx-00 for disman@ietf.org; Tue, 23 Mar 2004 08:28:24 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Tue, 23 Mar 2004 06:27:53 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: Cc: , , Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part26070B55.2__=" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 06:27:33 -0700 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part26070B55.2__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Andy, Thanks for your reponse. >IMO, the problem worth addressing in the IETF is the >detrimental effect of arbitrary renumbering of object >instance identifiers after a reboot. This is a general >problem, not related to DISMAN or RMONMIB. Perhaps >some ideas in this draft could be used to solve the >general problem. I totally agree with you in that, the persistent indexing is a requirement of many application and not just history collection. >Optimizations to the usrHistory group should be done in >a new MIB module without impacting the existing RMON-2 >conformance. I am of the opinion that proposed features of our draft certainly are required in the history collection framework and hence we(WG) need to work in optimizing the the usrHistory group. Regards, Shailaja. --=__Part26070B55.2__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Andy,
 
Thanks for your reponse.

>IMO, the problem worth addressing in the IETF is the
>de= trimental effect of arbitrary renumbering of object
>instance = identifiers after a reboot.  This is a general
>problem, not = related to DISMAN or RMONMIB.  Perhaps
>some ideas in this = draft could be used to solve the
>general problem.
 
 
I totally agree with you in that, the persistent indexing is a = requirement of many application and not just history collection.


>Optimizations to the usrHistory group should be done = in
>a new MIB module without impacting the existing RMON-2
>con= formance.
I am of the opinion that proposed features of our draft certainly are = required in the history collection framework and hence we(WG) need to work = in optimizing the the usrHistory group.
 
 
Regards,
Shailaja.
 
--=__Part26070B55.2__=-- From exim@www1.ietf.org Tue Mar 23 08:33:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25422 for ; Tue, 23 Mar 2004 08:33:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5m1p-0004pl-IN for disman-archive@odin.ietf.org; Tue, 23 Mar 2004 08:33:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NDXDGX018580 for disman-archive@odin.ietf.org; Tue, 23 Mar 2004 08:33:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5m1p-0004pb-Du for disman-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 08:33:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25390 for ; Tue, 23 Mar 2004 08:33:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5m1o-0001Bp-00 for disman-web-archive@ietf.org; Tue, 23 Mar 2004 08:33:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5m0q-00012C-00 for disman-web-archive@ietf.org; Tue, 23 Mar 2004 08:32:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5lzu-0000tJ-00 for disman-web-archive@ietf.org; Tue, 23 Mar 2004 08:31:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5lzi-0004dI-GY; Tue, 23 Mar 2004 08:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5lyx-0004VK-50 for disman@optimus.ietf.org; Tue, 23 Mar 2004 08:30:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25164 for ; Tue, 23 Mar 2004 08:30:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5lyv-0000m1-00 for disman@ietf.org; Tue, 23 Mar 2004 08:30:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5ly4-0000ev-00 for disman@ietf.org; Tue, 23 Mar 2004 08:29:21 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1B5lxA-0000Qx-00 for disman@ietf.org; Tue, 23 Mar 2004 08:28:24 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Tue, 23 Mar 2004 06:27:53 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: Cc: , , Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part26070B55.2__=" Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 06:27:33 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part26070B55.2__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Andy, Thanks for your reponse. >IMO, the problem worth addressing in the IETF is the >detrimental effect of arbitrary renumbering of object >instance identifiers after a reboot. This is a general >problem, not related to DISMAN or RMONMIB. Perhaps >some ideas in this draft could be used to solve the >general problem. I totally agree with you in that, the persistent indexing is a requirement of many application and not just history collection. >Optimizations to the usrHistory group should be done in >a new MIB module without impacting the existing RMON-2 >conformance. I am of the opinion that proposed features of our draft certainly are required in the history collection framework and hence we(WG) need to work in optimizing the the usrHistory group. Regards, Shailaja. --=__Part26070B55.2__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Andy,
 
Thanks for your reponse.

>IMO, the problem worth addressing in the IETF is the
>de= trimental effect of arbitrary renumbering of object
>instance = identifiers after a reboot.  This is a general
>problem, not = related to DISMAN or RMONMIB.  Perhaps
>some ideas in this = draft could be used to solve the
>general problem.
 
 
I totally agree with you in that, the persistent indexing is a = requirement of many application and not just history collection.


>Optimizations to the usrHistory group should be done = in
>a new MIB module without impacting the existing RMON-2
>con= formance.
I am of the opinion that proposed features of our draft certainly are = required in the history collection framework and hence we(WG) need to work = in optimizing the the usrHistory group.
 
 
Regards,
Shailaja.
 
--=__Part26070B55.2__=-- From disman-admin@ietf.org Tue Mar 23 09:30:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28988 for ; Tue, 23 Mar 2004 09:30:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5mun-0002Zb-F1; Tue, 23 Mar 2004 09:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5mud-0002Yd-K3 for disman@optimus.ietf.org; Tue, 23 Mar 2004 09:29:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28923 for ; Tue, 23 Mar 2004 09:29:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5mub-0001ad-00 for disman@ietf.org; Tue, 23 Mar 2004 09:29:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5mtT-0001Qb-00 for disman@ietf.org; Tue, 23 Mar 2004 09:28:40 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1B5msw-0001GE-00 for disman@ietf.org; Tue, 23 Mar 2004 09:28:06 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i2NERRYK072543 for ; Tue, 23 Mar 2004 15:27:32 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i2NEMbc2071871 for ; Tue, 23 Mar 2004 15:22:37 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i2NEMbYC071869; Tue, 23 Mar 2004 15:22:37 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 09AC011A316; Tue, 23 Mar 2004 15:22:36 +0100 (CET) From: Juergen Quittek To: Randy Presuhn , "Disman (E-mail)" Subject: Usability of Expression MIB (was: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt) Message-ID: <2147483647.1080055426@[10.1.1.171]> In-Reply-To: <000e01c40c5c$66edc6c0$7f1afea9@oemcomputer> References: <000e01c40c5c$66edc6c0$7f1afea9@oemcomputer> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 15:23:46 +0100 Content-Transfer-Encoding: 7bit Randy and all, --On 17.03.2004 12:14 Uhr -0800 Randy Presuhn wrote: > Hi - > > (as technical contributor) > >> From: "Romascanu, Dan (Dan)" >> To: "Randy Presuhn" ; "Disman (E-mail)" >> Sent: Wednesday, March 17, 2004 11:18 AM >> Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt >> > >> I will repeat a comment that I made during the meeting in Seoul. I think that all, >> or almost all that is being defined in this MIB module can already be performed >> - some features even in multiple ways - by agents that implement existing MIB >> modules like RMON, Events MIB, and Alarm MIB. > > This seems to be the case. I think the question raised is one of usability, > that is, how difficult is it to configure these existing MIBs to these things. > This is another facet of the old scripting vs. expression vs. special-purpose > MIB debate, but also ties in with the questions Juergen raised in his > overview of http://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt > at the session in Seoul. Usability of the Expression MIB was exactly our starting point for the development of the Check MIB. As I explained (at least I tried to) in Seoul, we wanted to implement local health checks on small devices. In particular, we wanted to (1) compare a (configurable) set of managed objects to thresholds or desired status values, (2) summarize the results and (3) send notifications on the summary in case of failed checks. (See more details in This is well possible using Expression MIB and Event MIB. However, when we started implementing it, we discovered big overheads on the side of the agent (number of tables and objects) as well as on the side of the manager (number of get and set requests required for configuring a health check). This is a usability problem. When discussing the Event/Expression MIB solution with product management people in my company, they said no because the cost/benefit relation was not acceptable for them, particularly not on the small devices which are our target for local health checks. As an alternative, we developed the small Check MIB which just has 5 scalar and 16 columnar objects (see MIB tree at the end of this email) but still is general enough for supporting a wide range of different health checks on a wide range of devices. Also configuring checks on the manager side became many times less complex than for Expression/Event MIB. My conclusion concerning the Expression MIB: Usability is poor although (or because) functionality is very good and general. It is designed multi-purpose, but for our purpose (and potentially also for other purposes) it is not well usable. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de ============== Check MIB tree ============== --checkMIB(1.3.6.1.2.1.7777) | +--checkObjects(1) | | | +--checkCapabilities(1) | | | | | +-- r-n TimeTicks checkCapabMinCheckInterval(1) | | +-- r-n Unsigned32 checkCapabMaxResults(2) | | +-- r-n Unsigned32 checkCapabMaxRules(3) | | | +--checkControl(2) | | | | | +-- rwn Enumeration checkCtrlAdminStatus(1) | | +-- r-n Enumeration checkCtrlOperStatus(2) | | | +--checkResultTable(3) | | | | | +--checkResultEntry(1) [checkResultName] | | | | | +-- --- SnmpAdminString checkResultName(1) | | +-- r-n SeverityReturned checkResultSeverity(2) | | +-- r-n Unsigned32 checkResultSize(3) | | +-- r-n TimeStamp checkResultTime(4) | | +-- rwn TimeInterval checkResultInterval(5) | | +-- r-n SeverityConfigured checkResultSeverityThreshold(6) | | +-- rwn StorageType checkResultStorageType(7) | | +-- rwn RowStatus checkResultRowStatus(8) | | | +--checkRuleTable(4) | | | | | +--checkRuleEntry(1) [checkResultName,checkRuleName] | | | | | +-- --- SnmpAdminString checkRuleName(2) | | +-- rwn ObjectIdentifier checkRuleOid(3) | | +-- rwn RuleValue checkRuleValue(4) | | +-- rwn Enumeration checkRuleOperation(5) | | +-- rwn SeverityConfigured checkRuleSeverity(6) | | +-- rwn RowStatus checkRuleRowStatus(7) | | | +--checkFailureTable(5) | | | +--checkFailureEntry(1) [checkResultName,checkFailureSeverity,checkRuleName] | | | +-- --- SeverityReturned checkFailureSeverity(1) | +-- r-n ObjectIdentifier checkFailureOid(2) | +--checkNotifications(2) | +--checkEvent(0) | +--checkFailed(1) [checkResultSeverity] From exim@www1.ietf.org Tue Mar 23 09:32:06 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29153 for ; Tue, 23 Mar 2004 09:32:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5mwL-0002j5-Jp for disman-archive@odin.ietf.org; Tue, 23 Mar 2004 09:31:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2NEVbmR010479 for disman-archive@odin.ietf.org; Tue, 23 Mar 2004 09:31:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5mwL-0002iw-G8 for disman-web-archive@optimus.ietf.org; Tue, 23 Mar 2004 09:31:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29131 for ; Tue, 23 Mar 2004 09:31:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5mwJ-0001td-00 for disman-web-archive@ietf.org; Tue, 23 Mar 2004 09:31:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5mvY-0001lD-00 for disman-web-archive@ietf.org; Tue, 23 Mar 2004 09:30:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5muo-0001bx-00 for disman-web-archive@ietf.org; Tue, 23 Mar 2004 09:30:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5mun-0002Zb-F1; Tue, 23 Mar 2004 09:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5mud-0002Yd-K3 for disman@optimus.ietf.org; Tue, 23 Mar 2004 09:29:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28923 for ; Tue, 23 Mar 2004 09:29:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5mub-0001ad-00 for disman@ietf.org; Tue, 23 Mar 2004 09:29:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5mtT-0001Qb-00 for disman@ietf.org; Tue, 23 Mar 2004 09:28:40 -0500 Received: from tokyo.netlab.nec.de ([195.37.70.2] helo=tokyo.ccrle.nec.de) by ietf-mx with esmtp (Exim 4.12) id 1B5msw-0001GE-00 for disman@ietf.org; Tue, 23 Mar 2004 09:28:06 -0500 Received: from tokyo.ccrle.nec.de (localhost [127.0.0.1]) by tokyo.ccrle.nec.de (8.12.10/8.12.9) with ESMTP id i2NERRYK072543 for ; Tue, 23 Mar 2004 15:27:32 +0100 (CET) Received: (from defang@localhost) by tokyo.ccrle.nec.de (8.12.10/8.12.8/Submit) id i2NEMbc2071871 for ; Tue, 23 Mar 2004 15:22:37 +0100 (CET) X-Authentication-Warning: tokyo.ccrle.nec.de: defang set sender to using -f Received: from venus.office (venus.office [10.1.1.11]) by pluto.office (8.12.9/8.12.9+MIMEDefang) with ESMTP id i2NEMbYC071869; Tue, 23 Mar 2004 15:22:37 +0100 (CET) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 09AC011A316; Tue, 23 Mar 2004 15:22:36 +0100 (CET) From: Juergen Quittek To: Randy Presuhn , "Disman (E-mail)" Subject: Usability of Expression MIB (was: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt) Message-ID: <2147483647.1080055426@[10.1.1.171]> In-Reply-To: <000e01c40c5c$66edc6c0$7f1afea9@oemcomputer> References: <000e01c40c5c$66edc6c0$7f1afea9@oemcomputer> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Tue, 23 Mar 2004 15:23:46 +0100 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Randy and all, --On 17.03.2004 12:14 Uhr -0800 Randy Presuhn wrote: > Hi - > > (as technical contributor) > >> From: "Romascanu, Dan (Dan)" >> To: "Randy Presuhn" ; "Disman (E-mail)" >> Sent: Wednesday, March 17, 2004 11:18 AM >> Subject: RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt >> > >> I will repeat a comment that I made during the meeting in Seoul. I think that all, >> or almost all that is being defined in this MIB module can already be performed >> - some features even in multiple ways - by agents that implement existing MIB >> modules like RMON, Events MIB, and Alarm MIB. > > This seems to be the case. I think the question raised is one of usability, > that is, how difficult is it to configure these existing MIBs to these things. > This is another facet of the old scripting vs. expression vs. special-purpose > MIB debate, but also ties in with the questions Juergen raised in his > overview of http://www.ietf.org/internet-drafts/draft-nunzi-check-mib-00.txt > at the session in Seoul. Usability of the Expression MIB was exactly our starting point for the development of the Check MIB. As I explained (at least I tried to) in Seoul, we wanted to implement local health checks on small devices. In particular, we wanted to (1) compare a (configurable) set of managed objects to thresholds or desired status values, (2) summarize the results and (3) send notifications on the summary in case of failed checks. (See more details in This is well possible using Expression MIB and Event MIB. However, when we started implementing it, we discovered big overheads on the side of the agent (number of tables and objects) as well as on the side of the manager (number of get and set requests required for configuring a health check). This is a usability problem. When discussing the Event/Expression MIB solution with product management people in my company, they said no because the cost/benefit relation was not acceptable for them, particularly not on the small devices which are our target for local health checks. As an alternative, we developed the small Check MIB which just has 5 scalar and 16 columnar objects (see MIB tree at the end of this email) but still is general enough for supporting a wide range of different health checks on a wide range of devices. Also configuring checks on the manager side became many times less complex than for Expression/Event MIB. My conclusion concerning the Expression MIB: Usability is poor although (or because) functionality is very good and general. It is designed multi-purpose, but for our purpose (and potentially also for other purposes) it is not well usable. Juergen -- Juergen Quittek quittek@ccrle.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.ccrle.nec.de ============== Check MIB tree ============== --checkMIB(1.3.6.1.2.1.7777) | +--checkObjects(1) | | | +--checkCapabilities(1) | | | | | +-- r-n TimeTicks checkCapabMinCheckInterval(1) | | +-- r-n Unsigned32 checkCapabMaxResults(2) | | +-- r-n Unsigned32 checkCapabMaxRules(3) | | | +--checkControl(2) | | | | | +-- rwn Enumeration checkCtrlAdminStatus(1) | | +-- r-n Enumeration checkCtrlOperStatus(2) | | | +--checkResultTable(3) | | | | | +--checkResultEntry(1) [checkResultName] | | | | | +-- --- SnmpAdminString checkResultName(1) | | +-- r-n SeverityReturned checkResultSeverity(2) | | +-- r-n Unsigned32 checkResultSize(3) | | +-- r-n TimeStamp checkResultTime(4) | | +-- rwn TimeInterval checkResultInterval(5) | | +-- r-n SeverityConfigured checkResultSeverityThreshold(6) | | +-- rwn StorageType checkResultStorageType(7) | | +-- rwn RowStatus checkResultRowStatus(8) | | | +--checkRuleTable(4) | | | | | +--checkRuleEntry(1) [checkResultName,checkRuleName] | | | | | +-- --- SnmpAdminString checkRuleName(2) | | +-- rwn ObjectIdentifier checkRuleOid(3) | | +-- rwn RuleValue checkRuleValue(4) | | +-- rwn Enumeration checkRuleOperation(5) | | +-- rwn SeverityConfigured checkRuleSeverity(6) | | +-- rwn RowStatus checkRuleRowStatus(7) | | | +--checkFailureTable(5) | | | +--checkFailureEntry(1) [checkResultName,checkFailureSeverity,checkRuleName] | | | +-- --- SeverityReturned checkFailureSeverity(1) | +-- r-n ObjectIdentifier checkFailureOid(2) | +--checkNotifications(2) | +--checkEvent(0) | +--checkFailed(1) [checkResultSeverity] From exim@www1.ietf.org Tue Mar 30 18:22:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29407 for ; Tue, 30 Mar 2004 18:22:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjQ-0006YH-2z for disman-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DGD6am001617 for disman-archive@odin.ietf.org; Fri, 13 Feb 2004 11:13:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfwA-0000Q0-FU for disman-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 11:13:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17228 for ; Fri, 13 Feb 2004 11:13:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arfw9-0006K7-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 11:13:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arfv9-0006E4-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 11:12:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArfuF-00067S-00 for disman-web-archive@ietf.org; Fri, 13 Feb 2004 11:11:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arfu9-0008Ss-Ar; Fri, 13 Feb 2004 11:11:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArftE-0008DV-Ri for disman@optimus.ietf.org; Fri, 13 Feb 2004 11:10:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16972 for ; Fri, 13 Feb 2004 11:10:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArftC-00062D-00 for disman@ietf.org; Fri, 13 Feb 2004 11:10:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArfsE-0005yB-00 for disman@ietf.org; Fri, 13 Feb 2004 11:09:04 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1ArfrK-0005qj-00 for disman@ietf.org; Fri, 13 Feb 2004 11:08:06 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Fri, 13 Feb 2004 09:07:35 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: Cc: "Hemanth Kumar" , "Raja Shekar" , "Hemanth Yamijala" Subject: [Disman] Statistical Sampling of Data- Discussion on requirement and proposal on advanced features Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__PartDEFFBF2C.0__=" Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Fri, 13 Feb 2004 09:07:24 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__PartDEFFBF2C.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi All At the moment a group of us are working on a draft-00-. The work is about object definition for configuring and controlling the periodic statistical sampling of user specified Data (ASN.1 INTEGER). As you might be aware that usr history group of RMON2 (RFC2021) does address this kind of requirement. Our proposed framework apart from containing the mechanisms seen in the alarm and usr history groups of RMON2 contains also the additional features and functionality. In order to get the ideas and inputs from congenial minds on the proposed features (to be), a brief description of proposed features (to be) is given below. Discussion: Suppose if the user needs to collect history for all the instances of a columnar object say e.g., on the interface related statistics (ifTable of MIB-II) like packets sent for all the interfaces by using the usrHistory group object definition, the user is required to carry out configuration for each instance separately. The usr History group does not provide a single point of configuration for all the instances of the columnar objects. It has to be noted that there are some special requirements that arise because of the above such condition. Following features address some such special requirements. Features: (a) Goal: Simple configuration and Instance Management: Objective: It must be possible to configure and control the history collection for all the instances of the columnar object in a simple way. The OID of a columnar object variable consists of two parts: a columnar OID and an index. Usually, the index part of the OID is defined by implementers of the MIB or is dependent on the specific type of the parameter that is being monitored. Hence it can have arbitrary values. Also, these indices can vary from machine to machine. For example, the index of the ifTable is a column called ifIndex. The value of this ifIndex is not pre-determined and can be any arbitrary integer value. It is difficult for a user to determine the complete OID for such parameter. There is another problem that arises vis-a-vis the history collection of columnar variables. The numbers of instances for these parameters are not fixed. This means that there could be new instances that are added or existing ones removed, as per the dynamic behavior of the system being monitored. For example, new interfaces added to the system could result in new rows in the ifTable. Interfaces removed would result in the deletion of existing rows. It becomes difficult if an user needs to keep track of these additions and deletions and make sure that the history collection configuration reflects these changes. A simple resolution to these kind of requirement being providing the capability to the user to define only the columnar part of the OID and allow the implementing application to find all the instances of the table automatically. At the same time, this would also allow the agent to keep track of additions and deletions that occur as stated above. (b) Consistent reference to the resource: It must be possible to track changing instances and automatically adjust the history collection. Normally, the index part of columnar variables maps to an instance of the system resource being monitored. However, if the resource being monitored changes, it could result in a change to the index part of the columnar variables also. As it is again left to implementation what the index part is, there is no guarantee that an index is mapped to the same instance of the system resource always. For example, consider the hrSWRunTable table in the Host resources MIB. The index of this table is again an integer valued variable called hrSWRunIndex. The HTTP server process might initially be associated with index 7219. However, if it is restarted, it could get the index 9029. Also, it is likely that a row with index 7219 might actually represent a new process like notepad.exe. If some columnar variable related to the above table need statistical sampling, it cannot rely just on the OID of that variable. It may result in the data not being collected for the instance even if it is actually available. Or worse, it may collect incorrect data assuming that the OID still represents the same instance. It is also very difficult for an user to keep these synchronized. Strictly speaking, this problem should not arise if the indices of tables are defined and implemented in such a way that their mapping to the underlying resource is ensured to be always unique. However, it is observed in practice that indices of tables are usually just integer valued numbers. It is also observed that there would be other columns in the table which identify the resources in a more permanent manner. For example, in the case of the hrSWRunTable, the name of the software could serve as a good identifier. This problem is addressed by introducing a concept of 'Identifier Object'. The Identifier Objects are one or more Columnar Objects that will serve to uniquely identify one instance among several ones of selected columnar objects. The MIB definition allows the user to associate Identifier Objects to the columnar Object being sampled. By doing so, it is now left to the monitoring application to make sure that data is being collected for the right resource even if it changes with time. (c) Instance Filtering: It must be possible to selectively collect history on certain instances of a columnar object. Sometimes, the user may not be interested in all the instances of a given table. In such a case, usr can specify the OIDs of the specific instances of interest. However, as described in the above points, specifying the complete OID will again have a problem if there is a change to the index part of such instances. For example, consider again the hrSWRunTable in the Host resources MIB. This would include all processes running on the system. However the user might be interested in monitoring only certain important processes like a HTTP server or other major services. The current draft allows the user to define filter criteria specifying the instances to be monitored. The monitoring application can now ensure that instances satisfying these criteria can be monitored. Combined with the other points mentioned above, this would handle cases where instances satisfying the criteria get added, removed or modified. (d) Threshold Monitoring: Combining the aspect of threshold monitoring with history collection: In addition to the above considerations, the current object definition also tries to combine the functionality of threshold-based monitoring with the history collection functionality. It allows the user to define thresholds on the data being monitored. Any violation of the threshold would result in a trap being generated. --=__PartDEFFBF2C.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit
Hi All
 
At the moment a group of us are working on a draft-00-.
The work is about object definition for configuring and controlling the periodic statistical sampling of user specified Data (ASN.1 INTEGER). As you might be aware that usr history group of RMON2 (RFC2021) does address this kind of requirement. Our proposed framework apart from containing the mechanisms seen in the alarm and usr history groups of RMON2 contains also the additional features and functionality. In order to get the ideas and inputs from congenial minds on the proposed features (to be), a brief description of proposed features (to be) is given below.
 
Discussion:
 
Suppose if the user needs to collect history for all the instances of a columnar object say e.g., on the interface related statistics (ifTable of MIB-II) like packets sent for all the interfaces by using the usrHistory group object definition, the user is required to carry out configuration for each instance separately. The usr History group does not provide a single point of configuration for all the instances of the columnar objects.
  
It has to be noted that there are some special requirements that arise because of the above such condition. Following features address some such special requirements.
 
Features:
 
(a) Goal: Simple configuration and Instance Management:
 
Objective: It must be possible to configure and control the history collection for all the instances of the columnar object in a simple way.
 
  The OID of a columnar object variable consists of two parts: a columnar OID and an index.
 
Usually, the index part of the OID is defined by implementers of the MIB or is dependent on the specific type of the parameter that is being monitored. Hence it can have arbitrary values. Also, these indices can vary from machine to machine. For example, the index of the ifTable is a column called ifIndex. The value of this ifIndex is not pre-determined and can be any arbitrary integer value. It is difficult for a user to determine the complete OID for such parameter.
 
There is another problem that arises vis-a-vis the history collection of columnar variables. The numbers of instances for these parameters are not fixed. This means that there could be new instances that are added or existing ones removed, as per the dynamic behavior of the system being monitored. For example, new interfaces added to the system could result in new rows in the ifTable. Interfaces removed would result in the deletion of existing rows. It becomes difficult if an user needs to keep track of these additions and deletions and make sure that the history collection configuration reflects these changes.
 
 A simple resolution to these kind of requirement being providing the capability to the user to define only the columnar part of the OID and allow the implementing application to find all the instances of the table automatically. At the same time, this would also allow the agent to keep track of additions and deletions that occur as stated above.
 
(b) Consistent reference to the resource: It must be possible to track changing instances and automatically adjust the history collection.
 
Normally, the index part of columnar variables maps to an instance of the system resource being monitored. However, if the resource being monitored changes, it could result in a change to the index part of the columnar variables also. As it is again left to implementation what the index part is, there is no guarantee that an index is mapped to the same instance of the system resource always.
 
For example, consider the hrSWRunTable table in the Host resources
MIB. The index of this table is again an integer valued variable called hrSWRunIndex. The HTTP server process might initially be associated with index 7219. However, if it is restarted, it could get the index 9029. Also, it is likely that a row with index 7219 might actually represent a new process
like notepad.exe.
 
If some columnar variable related to the above table need statistical sampling, it cannot rely just on the OID of that variable. It may result in the data not being collected for the instance even if it is actually available. Or worse, it may collect incorrect data assuming that the OID still represents the same instance. It is also very difficult for an user to keep these synchronized.
 
Strictly speaking, this problem should not arise if the indices of
tables are defined and implemented in such a way that their mapping to the underlying resource is ensured to be always unique. However, it is observed in practice that indices of tables are usually just integer valued numbers. It is also observed that there would be other columns in the table which identify the resources in a more permanent manner. For example, in the
case of the hrSWRunTable, the name of the software could serve as a good identifier.
 
This problem is addressed by introducing a concept of
'Identifier Object'. The Identifier Objects are one or more Columnar Objects that will serve to uniquely identify one instance among several ones of selected columnar objects. The MIB definition allows the user to associate Identifier Objects to the columnar Object being sampled. By doing so, it is now left to the monitoring application to make sure that data is being collected for the right resource even if it changes with time.
 
(c) Instance Filtering: It must be possible to selectively collect history on certain instances of a columnar object.
 
Sometimes, the user may not be interested in all the instances of a given table. In such a case, usr can specify the OIDs of the specific instances of interest. However, as described in the above points, specifying the complete OID will again have a problem if there is a change to the index part of such instances.
 
For example, consider again the hrSWRunTable in the Host resources MIB. This would include all processes running on the system. However the user might be interested in monitoring only certain important processes like a HTTP server or other major services.
 
The current draft allows the user to define filter criteria specifying the instances to be monitored. The monitoring application can now ensure that instances satisfying these criteria can be monitored. Combined with the other points mentioned above, this would handle cases where instances satisfying the criteria get added, removed or modified.
 
(d) Threshold Monitoring: Combining the aspect of threshold monitoring with history collection:
 
In addition to the above considerations, the current object definition also tries to combine the functionality of threshold-based monitoring with the history collection functionality. It allows the user to define thresholds on the data being monitored. Any violation of the threshold would result in a trap being generated.
 

 
--=__PartDEFFBF2C.0__=-- From exim@www1.ietf.org Tue Mar 30 18:29:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01158 for ; Tue, 30 Mar 2004 18:29:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjL-0006a4-5M for disman-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MDTbm8029835 for disman-archive@odin.ietf.org; Mon, 22 Mar 2004 08:29:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PUj-0007l2-QE for disman-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 08:29:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23004 for ; Mon, 22 Mar 2004 08:29:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5PUi-0000cR-00 for disman-web-archive@ietf.org; Mon, 22 Mar 2004 08:29:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5PTm-0000Ws-00 for disman-web-archive@ietf.org; Mon, 22 Mar 2004 08:28:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5PTR-0000Rg-00 for disman-web-archive@ietf.org; Mon, 22 Mar 2004 08:28:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PTQ-0007bh-8N; Mon, 22 Mar 2004 08:28:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5PSf-0007Oe-6h for disman@optimus.ietf.org; Mon, 22 Mar 2004 08:27:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22842 for ; Mon, 22 Mar 2004 08:27:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5PSe-0000P7-00 for disman@ietf.org; Mon, 22 Mar 2004 08:27:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5PRi-0000IT-00 for disman@ietf.org; Mon, 22 Mar 2004 08:26:26 -0500 Received: from prv-mail25.provo.novell.com ([137.65.81.121]) by ietf-mx with esmtp (Exim 4.12) id 1B5PQp-00007h-00; Mon, 22 Mar 2004 08:25:31 -0500 Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Mon, 22 Mar 2004 06:25:00 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.5.2 Beta From: "Shailaja Yadawad" To: , Cc: Subject: Re: [RMONMIB] RE: [Disman] Fw: I-D ACTION:draft-yadawad-disman-ahcf-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=__Part96B78509.0__=" Sender: disman-admin@ietf.org Errors-To: disman-admin@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Distributed Management List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 22 Mar 2004 06:24:41 -0700 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,HTML_MESSAGE autolearn=no version=2.60 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part96B78509.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi >Since there is substantial overlap in the membership of the two >working groups, can we confine this discussion to just one of the >WG lists? I suggest that we continue discussion on the disman >list. If consensus develops that there is a problem to be solved >along with a general sense what technical approach we'd like >to use, then Andy and I could consult with Bert (our Area Director) >to figure out whether the work would make sense for either working >group, a new working group, or whatever. I am fine with this approach. Sorry, I saw this mail now after I posted my previous mail. Here onwards will confine my mail discussion to disman WG. Regards, Shailaja. --=__Part96B78509.0__= Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi
 
>Since there is substantial overlap in the membership of the = two
>working groups, can we confine this discussion to just one of = the
>WG lists?  I suggest that we continue discussion on the = disman
>list.  If consensus develops that there is a problem to = be solved
>along with a general sense  what technical approach = we'd like
>to use, then Andy and I could consult with Bert (our Area = Director)
>to figure out whether the work would make sense for = either working
>group, a new working group, or whatever.
I am fine with this approach. Sorry, I saw this mail now after I = posted my previous mail. Here onwards will confine my mail discussion to = disman WG.

Regards,
Shailaja.
 
--=__Part96B78509.0__=--