From mailman-bounces@ietf.org Tue Jun 1 07:41:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19593 for ; Tue, 1 Jun 2004 07:41:51 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BV5Yr-0004zY-7L for disman-archive@lists.ietf.org; Tue, 01 Jun 2004 05:27:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: disman-archive@ietf.org X-No-Archive: yes Message-ID: Date: Tue, 01 Jun 2004 05:04:58 -0400 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit 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, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@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 mailman-admin@ietf.org Tue Jun 1 11:47:46 2004 Received: from optimus.ietf.org ([132.151.1.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17714 for ; Tue, 1 Jun 2004 11:47:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1BV956-00088q-A7 for disman-archive@lists.ietf.org; Tue, 01 Jun 2004 09:13:28 -0400 Date: Tue, 01 Jun 2004 09:13:28 -0400 Message-ID: <20040601131328.26555.55818.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 disman-bounces@ietf.org Thu Jun 3 14:58:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02980 for ; Thu, 3 Jun 2004 14:58:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVwWp-0002Wp-Aa; Thu, 03 Jun 2004 14:01:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVw4v-0003r0-8b for disman@megatron.ietf.org; Thu, 03 Jun 2004 13:32:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26736 for ; Thu, 3 Jun 2004 13:32:32 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVw4u-0004Wt-Dg for disman@ietf.org; Thu, 03 Jun 2004 13:32:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVw3u-00045S-00 for disman@ietf.org; Thu, 03 Jun 2004 13:31:31 -0400 Received: from cardinal.mail.pas.earthlink.net ([207.217.121.226]) by ietf-mx with esmtp (Exim 4.12) id 1BVw2t-0003e4-00 for disman@ietf.org; Thu, 03 Jun 2004 13:30:27 -0400 Received: from h-68-164-78-243.snvacaid.dynamic.covad.net ([68.164.78.243] helo=oemcomputer) by cardinal.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BVw2t-0003Ef-00 for disman@ietf.org; Thu, 03 Jun 2004 10:30:27 -0700 Message-ID: <004b01c448c7$5cb0d100$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" Date: Wed, 2 Jun 2004 10:30:56 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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,DATE_IN_PAST_12_24 autolearn=no version=2.60 Subject: [Disman] Fw: Heads-up: we intend to tell people "new boilerplate please" X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - If you're planning to submit internet drafts, please read. Randy ----- Original Message ----- > From: "Harald Tveit Alvestrand" > To: > Sent: Wednesday, June 02, 2004 4:26 PM > Subject: Heads-up: we intend to tell people "new boilerplate please" > > We're currently in the process of (at last!) upgrading to support the new > boilerplate (RFC 3667) only. > > We're going to set a cutoff date for I-D submissions, saying that "after > this date, ONLY I-Ds with new boilerplate will be accepted". > > June 15 is our target date - but we're not firmly wedded to a date until we > have all the guideline documents updated - and things are taking (too much) > time! > > Harald > > From disman-bounces@ietf.org Sat Jun 5 17:09:56 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06658 for ; Sat, 5 Jun 2004 17:09:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWiJ3-0003C3-GA; Sat, 05 Jun 2004 17:02:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BWiBR-0001y5-OY for disman@megatron.ietf.org; Sat, 05 Jun 2004 16:54:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05904 for ; Sat, 5 Jun 2004 16:54:27 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BWiBQ-0004Na-Cj for disman@ietf.org; Sat, 05 Jun 2004 16:54:28 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BWiAc-00046Y-00 for disman@ietf.org; Sat, 05 Jun 2004 16:53:39 -0400 Received: from turkey.mail.pas.earthlink.net ([207.217.120.126]) by ietf-mx with esmtp (Exim 4.12) id 1BWi9x-0003oV-00 for disman@ietf.org; Sat, 05 Jun 2004 16:52:58 -0400 Received: from h-68-164-83-88.snvacaid.dynamic.covad.net ([68.164.83.88] helo=oemcomputer) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BWi9n-0005h1-00; Sat, 05 Jun 2004 13:52:47 -0700 Message-ID: <005401c44a75$f87a2500$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Jean-Francois Mule" , "Juergen Quittek" References: Date: Fri, 4 Jun 2004 13:53:20 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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,DATE_IN_PAST_12_24 autolearn=no version=2.60 Cc: Eduardo Cardona , "Disman \(E-mail\)" Subject: [Disman] Re: Status of comments resolution re: draft-ietf-disman-remops-mib-v2-01.txt X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - There have been no objections raised to the proposed edits modulo what little discussion has taken place on the list, so I'm just waiting for the new ID. Randy Disman WG chair > From: "Jean-Francois Mule" > To: "Randy Presuhn" ; "Juergen Quittek" > Cc: "Eduardo Cardona" > Sent: Friday, June 04, 2004 1:40 PM > Subject: Status of comments resolution re: draft-ietf-disman-remops-mib-v2-01.txt > > Hi Randy & Juergen, > > I was off when you exchange this thread. I am curious to know what the resolution was. > Should we expect a new ID soon adding the minimal compliance module? > > Let me know, thanks, > Jean-François > IPCDN co-chair ... From disman-bounces@ietf.org Tue Jun 15 14:29:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06986 for ; Tue, 15 Jun 2004 14:29:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaIb9-0000pW-SZ; Tue, 15 Jun 2004 14:23:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaITq-0008Db-Rg for disman@megatron.ietf.org; Tue, 15 Jun 2004 14:16:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06181 for ; Tue, 15 Jun 2004 14:16:14 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaITm-0004eY-AJ for disman@ietf.org; Tue, 15 Jun 2004 14:16:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaISu-0004KL-00 for disman@ietf.org; Tue, 15 Jun 2004 14:15:21 -0400 Received: from swan.mail.pas.earthlink.net ([207.217.120.123]) by ietf-mx with esmtp (Exim 4.12) id 1BaISN-0003zN-00 for disman@ietf.org; Tue, 15 Jun 2004 14:14:47 -0400 Received: from h-68-164-78-145.snvacaid.dynamic.covad.net ([68.164.78.145] helo=oemcomputer) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BaISN-0001Hi-00 for disman@ietf.org; Tue, 15 Jun 2004 11:14:47 -0700 Message-ID: <003f01c45304$c58c5720$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" Date: Tue, 15 Jun 2004 11:15:42 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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: DISMAN Milestones past due X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - Well? Randy > From: "WG Milestone Tracker" > To: "DISMAN Chair" > Cc: "OPS ADs" ; "OPS ADs" > Sent: Monday, June 14, 2004 11:30 PM > Subject: DISMAN Milestones past due > > > Dear DISMAN Working Group Chair(s): > > Below is a list of the DISMAN Working Group milestones that are past due. Please be reminded that changes to existing milestones or due dates require Area Director approval. Therefore, please send comments, requests, or status reports regarding these milestones directly to your Area Directors. > > To report that a milestone has been achieved, please send a message to iesg-secretary@ietf.org with the name of the milestone and the completion date. If you do not provide a completion date, then the completion date recorded will be the date that your message is received. > > The IESG Secretariat > -------------------------------------------------------------------------------------- > > Past Due Milestones: > > Feb 04 WG last call on updates to Remote Operations MIB > Mar 04 Implementation Report on Remote Operations MIB > Mar 04 Remote Operations MIB submitted to IESG for consideration as Draft > Standard > -------------------------------------------------------------------------------------- > From disman-bounces@ietf.org Wed Jun 16 01:00:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20980 for ; Wed, 16 Jun 2004 01:00:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaSK5-0007kG-4q; Wed, 16 Jun 2004 00:46:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaS8t-0004Cv-SH for disman@megatron.ietf.org; Wed, 16 Jun 2004 00:35:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14618 for ; Wed, 16 Jun 2004 00:35:17 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaS8r-0005zK-MH for disman@ietf.org; Wed, 16 Jun 2004 00:35:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaNOh-0007HH-00 for disman@ietf.org; Tue, 15 Jun 2004 19:31:20 -0400 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx with esmtp (Exim 4.12) id 1BaKxp-0003d0-00 for disman@ietf.org; Tue, 15 Jun 2004 16:55:25 -0400 Received: from h-68-164-78-145.snvacaid.dynamic.covad.net ([68.164.78.145] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BaKxl-0000K6-00 for disman@ietf.org; Tue, 15 Jun 2004 13:55:21 -0700 Message-ID: <007801c4531b$346875a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <00b601c41b44$1c123d60$7f1afea9@oemcomputer> Subject: Re: [Disman] Event MIB Implementation Survey Date: Tue, 15 Jun 2004 13:56:17 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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 X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - Over two months have passed, and I have received NO implementation reports for the Event MIB. Randy > From: "Randy Presuhn" > To: "Disman (E-mail)" > Sent: Monday, April 05, 2004 12:28 PM > Subject: [Disman] Event MIB Implementation Survey > > Hi - > > Here is the Implementation Survey for RFC 2981, the Event MIB. > Please send responses to disman@ietf.org , or, if you would like your implementation > to remain anonymous for the implementation report, to the WG chair at > randy_presuhn@mindspring.com. > > ================================================= > > Implementation Survey for RFC 2981, Event MIB > > Module: DISMAN-EVENT-MIB > Implemtation Source: > Management Application / Agent: > > GROUPs: > dismanEventResourceGroup (y/n): _ > dismanEventTriggerGroup (y/n): _ > dismanEventObjectsGroup (y/n): _ > dismanEventEventGroup (y/n): _ > dismanEventNotificationObjectGroup (y/n): _ > dismanEventNotificationGroup (y/n): _ > > OBJECTs: > mteTriggerTargetTag (ro/rw): __ > mteEventSetTargetTag (ro/rw): __ > mteTriggerValueIDWildcard (ro/rw): __ > mteTriggerContextNameWildcard (ro/rw): __ > mteObjectsIDWildcard (ro/rw): __ > mteEventSetContextNameWildcard (ro/rw): __ > > > Deployment / Operational Experience: > > > Comments: > > > From disman-bounces@ietf.org Wed Jun 16 01:01:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21132 for ; Wed, 16 Jun 2004 01:01:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaSK8-0007kV-Sn; Wed, 16 Jun 2004 00:46:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaS9J-0004II-LH for disman@megatron.ietf.org; Wed, 16 Jun 2004 00:35:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14732 for ; Wed, 16 Jun 2004 00:35:42 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaS9H-00063M-GV for disman@ietf.org; Wed, 16 Jun 2004 00:35:43 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaNPW-0007Pk-00 for disman@ietf.org; Tue, 15 Jun 2004 19:32:12 -0400 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by ietf-mx with esmtp (Exim 4.12) id 1BaKym-0003js-00 for disman@ietf.org; Tue, 15 Jun 2004 16:56:24 -0400 Received: from h-68-164-78-145.snvacaid.dynamic.covad.net ([68.164.78.145] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BaKym-0000XQ-00 for disman@ietf.org; Tue, 15 Jun 2004 13:56:25 -0700 Message-ID: <007d01c4531b$5a4043c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <00c201c41b44$6d116880$7f1afea9@oemcomputer> Subject: Re: [Disman] Expression MIB Implementation Survey Date: Tue, 15 Jun 2004 13:57:20 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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 X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - Two months have passed, and I haven't seen a single response. Suggestions? Randy > From: "Randy Presuhn" > To: "Disman (E-mail)" > Sent: Monday, April 05, 2004 12:30 PM > Subject: [Disman] Expression MIB Implementation Survey > > Hi - > > Here is the Implementation Survey for RFC 2982, the Expression MIB. > Please send responses to disman@ietf.org , or, if you would like your implementation > to remain anonymous for the implementation report, to the WG chair at > randy_presuhn@mindspring.com. > > ================================================= > > Implementat Survey for RFC 2982, > Distributed Management Expression MIB > > > Implementation Source: > Management Application / Agent: > Module: DISMAN-EXPRESSION-MIB > > GROUPs: > dismanExpressionResourceGroup (y/n): _ > dismanExpressionDefinitionGroup (y/n): _ > dismanExpressionValueGroup (y,n): _ > > OBJECTs: > expResourceDeltaMinimum full range supported (y/n): _ > expObjectSampleType deltas supported (y/n): _ > expObjectIDWildcard wildcard supported (y/n): _ > expObjectDiscontinuityIDWildcard wildcard supported (y/n): _ > expObjectConditionalWildcard deltas/wildcards supported (y/n): _ > > > Deployment / Operational Experience: > > > Comments: > > > From disman-bounces@ietf.org Wed Jun 16 01:40:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29933 for ; Wed, 16 Jun 2004 01:40:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaT7I-00060H-Dr; Wed, 16 Jun 2004 01:37:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaSUZ-0001tg-Sh for disman@megatron.ietf.org; Wed, 16 Jun 2004 00:57:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20111 for ; Wed, 16 Jun 2004 00:57:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaSUX-0001su-Rd for disman@ietf.org; Wed, 16 Jun 2004 00:57:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaODF-0004XY-00 for disman@ietf.org; Tue, 15 Jun 2004 20:23:34 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BaLEb-0005U1-00 for disman@ietf.org; Tue, 15 Jun 2004 17:12:45 -0400 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BaL6J-0006Sc-JV for disman@ietf.org; Tue, 15 Jun 2004 17:04:11 -0400 Received: from h-68-164-78-145.snvacaid.dynamic.covad.net ([68.164.78.145] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BaL6H-00025S-00 for disman@ietf.org; Tue, 15 Jun 2004 14:04:09 -0700 Message-ID: <009501c4531c$6f481080$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <00aa01c41b43$b9900a00$7f1afea9@oemcomputer> Subject: Re: [Disman] Remops Implementation Survey Date: Tue, 15 Jun 2004 14:05:06 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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 X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - Two months have gone by, and I've seen no response, nor have I seen any response to Juergen Quittek's call for implementation results last November. Should we abandon our attempt to update the document? Randy > From: "Randy Presuhn" > To: "Disman (E-mail)" > Sent: Monday, April 05, 2004 12:25 PM > Subject: [Disman] Remops Implementation Survey > > Hi - > > Here is the Implementation Survey for RFC 2925, the Remote Operations MIBs. > Please send responses to disman@ietf.org , or, if you would like your implementation > to remain anonymous for the implementation report, to the WG chair at > randy_presuhn@mindspring.com. > > ================================================= > > Implementation Survey for RFC 2925, > Definitions of Managed Objects for Remote Ping, > Traceroute, and Lookup Operations > > > Module: DISMAN-PING-MIB > Implementation Source: > Management Application / Agent: > > > GROUPs: > pingGroup (y/n): _ > pingNotificationsGroup (y/n): _ > pingTimeStampGroup (y/n): _ > > OBJECTs: > pingMaxConcurrentRequests (rw/ro): __ > pingCtlStorageType (rw/ro): __ > pingCtlType (rw/ro): __ > pingCtlByPassRouteTable (rw/ro): __ > pingCtlSourceAddressType (rw/ro): __ > unknown (y/n): _ > ipv4 (y/n): _ > ipv6 (y/n): _ > > pingCtlSourceAddress (rw/ro): __ > pingCtlIfIndex (rw/ro): __ > pingCtlDSField (rw/ro): __ > pingResultsIpTargetAddressType: > unknown (y/n): _ > ipv4 (y/n): _ > ipv6: _ > pingResultsIpTargetAddress: > 0 (y/n): _ > 4 (y/n): _ > 16 (y/n): _ > > > Module: DISMAN-TRACEROUTE-MIB > Implementation Source: > Management Application / Agent: > > GROUPs: > traceRouteGroup (y/n): _ > traceRouteTimeStampGroup (y/n): _ > traceRouteNotificationsGroup (y/n): _ > traceRouteHopsTableGroup (y/n): > > OBJECTs: > traceRouteMaxConcurrentRequests (rw/ro): __ > traceRouteCtlByPassRouteTable (rw/ro): __ > traceRouteCtlSourceAddressType rw/ro): __ > traceRouteCtlSourceAddress (rw/ro): __ > traceRouteCtlIfIndex (rw/ro): __ > traceRouteCtlMiscOptions (rw/ro): __ > traceRouteCtlStorageType (rw/ro): __ > traceRouteCtlDSField (rw/ro): __ > traceRouteCtlType (rw/ro): __ > traceRouteResultsIpTgtAddrType > unknown (y/n): _ > ipv4 (y/n): _ > ipv6 (y/n): _ > traceRouteResultsIpTgtAddr > 0 (y/n): _ > 4 (y/n): _ > 16 (y/n): _ > traceRouteProbeHistoryHAddrType > unknown (y/n): _ > ipv4 (y/n): _ > ipv6 (y/n): _ > traceRouteProbeHistoryHAddr > 0 (y/n): _ > 4 (y/n): _ > 16 (y/n): _ > traceRouteHopsIpTgtAddressType > unknown (y/n): _ > ipv4 (y/n): _ > ipv6 (y/n): _ > traceRouteHopsIpTgtAddress > 0 (y/n): _ > 4 (y/n): _ > 16 (y/n): _ > > > Module: DISMAN-NSLOOKUP-MIB > Implementation Source: > Management Application / Agent: > > GROUPs > lookupGroup (y/n): _ > > OBJECTs: > lookupMaxConcurrentRequests (rw/ro): __ > lookupPurgeTime (rw/ro): __ > > > Deployment / Operational Experience: > > > Comments: > > > From disman-bounces@ietf.org Wed Jun 16 01:46:47 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01516 for ; Wed, 16 Jun 2004 01:46:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaTED-0000Q4-DY; Wed, 16 Jun 2004 01:44:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaSWY-0002o0-Va for disman@megatron.ietf.org; Wed, 16 Jun 2004 00:59:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20689 for ; Wed, 16 Jun 2004 00:59:43 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaSWW-0002Du-BJ for disman@ietf.org; Wed, 16 Jun 2004 00:59:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaOIO-0004z8-00 for disman@ietf.org; Tue, 15 Jun 2004 20:28:53 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BaLFA-0005TJ-00 for disman@ietf.org; Tue, 15 Jun 2004 17:13:21 -0400 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BaL3z-0005m6-5t for disman@ietf.org; Tue, 15 Jun 2004 17:01:47 -0400 Received: from h-68-164-78-145.snvacaid.dynamic.covad.net ([68.164.78.145] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BaL3x-0001Z8-00 for disman@ietf.org; Tue, 15 Jun 2004 14:01:45 -0700 Message-ID: <008e01c4531c$1914cdc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <00b001c41b43$ec031400$7f1afea9@oemcomputer> Subject: Re: [Disman] Script MIB Implementation Survey Date: Tue, 15 Jun 2004 14:02:41 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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 X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - I've seen no responses to this survey, and the only implementation report of any kind I've received is from Juergen Quittek. Surely there are more out there! Randy > From: "Randy Presuhn" > To: "Disman (E-mail)" > Sent: Monday, April 05, 2004 12:26 PM > Subject: [Disman] Script MIB Implementation Survey > > Hi - > > Here is the Implementation Survey for RFC 3165, the Script MIB. > Please send responses to disman@ietf.org , or, if you would like your implementation > to remain anonymous for the implementation report, to the WG chair at > randy_presuhn@mindspring.com. > > ================================================= > > > Implementation Survey for RFC 3165, > Definitions of Managed Objects for the Delegation of Management Scripts > > Module: DISMAN-SCRIPT-MIB > Implementation Source: ____________ > Management Application / Agent: > > GROUPs: > smLanguageGroup (y/n): _ > smScriptGroup2 (y/n): _ > smLaunchGroup2 (y/n): _ > smRunGroup2 (y/n): _ > smNotificationsGroup2 (y,n): _ > smCodeGroup (y,n): _ > > OBJECTs: > smScriptSource (ro/rw): __ > smCodeText (ro/rw): __ > smLaunchArgument maximum size: __ > smRunArgument maximum size: ___ > smRunResult maximum size: ___ > smRunState suspension permitted? (y,n): _ > > Deployement / P[erational Experience: > > Comments: > > > From disman-bounces@ietf.org Wed Jun 16 01:53:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03027 for ; Wed, 16 Jun 2004 01:53:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaTIs-0001Gq-7m; Wed, 16 Jun 2004 01:49:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaSXq-0003BG-5m for disman@megatron.ietf.org; Wed, 16 Jun 2004 01:01:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21083 for ; Wed, 16 Jun 2004 01:01:05 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaSXo-0002UG-4d for disman@ietf.org; Wed, 16 Jun 2004 01:01:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaOM7-0005Ih-00 for disman@ietf.org; Tue, 15 Jun 2004 20:32:46 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BaLFW-0005cA-00 for disman@ietf.org; Tue, 15 Jun 2004 17:13:42 -0400 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BaL1U-00058z-Ra for disman@ietf.org; Tue, 15 Jun 2004 16:59:12 -0400 Received: from h-68-164-78-145.snvacaid.dynamic.covad.net ([68.164.78.145] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BaL1S-00014A-00 for disman@ietf.org; Tue, 15 Jun 2004 13:59:10 -0700 Message-ID: <008701c4531b$bd305420$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <00ca01c41b44$bb04da40$7f1afea9@oemcomputer> Subject: Re: [Disman] Schedule MIB Implementation Survey Date: Tue, 15 Jun 2004 14:00:07 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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 X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - I've seen no response to this call for implementation information. This is disappointing, given the number of implementations that are allegedly out there. Randy > From: "Randy Presuhn" > To: "Disman (E-mail)" > Sent: Monday, April 05, 2004 12:32 PM > Subject: [Disman] Schedule MIB Implementation Survey > > Hi - > > > Here is the Implementation Survey for RFC 3231, the Schedule MIB. > Please send responses to disman@ietf.org , or, if you would like your implementation > to remain anonymous for the implementation report, to the WG chair at > randy_presuhn@mindspring.com. > > ================================= > > Implementation Survey for RFC 3231, > Definitions of Managed Objects for Scheduling Management Operations > > > Module: DISMAN-SCHEDULE-MIB > Implementation Source: > Management Application / Agent: > > > GROUPs > schedGroup2 (y/n): _ > schedNotificationsGroup (y/n): _ > schedCalendarGroup (y,n): _ > > > Deployment / Operational Experience: > > > Comments: > > > From disman-bounces@ietf.org Wed Jun 16 01:57:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03943 for ; Wed, 16 Jun 2004 01:57:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaTLj-0002HL-Dw; Wed, 16 Jun 2004 01:52:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaSZS-0003P3-9F for disman@megatron.ietf.org; Wed, 16 Jun 2004 01:02:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21474 for ; Wed, 16 Jun 2004 01:02:45 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaSZQ-0002jH-4j for disman@ietf.org; Wed, 16 Jun 2004 01:02:44 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaOOu-0005at-00 for disman@ietf.org; Tue, 15 Jun 2004 20:35:37 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BaLFo-0005XQ-00 for disman@ietf.org; Tue, 15 Jun 2004 17:14:00 -0400 Received: from flamingo.mail.pas.earthlink.net ([207.217.120.232]) by mx2.foretec.com with esmtp (Exim 4.24) id 1BaL0K-0004pB-Bz for disman@ietf.org; Tue, 15 Jun 2004 16:58:00 -0400 Received: from h-68-164-78-145.snvacaid.dynamic.covad.net ([68.164.78.145] helo=oemcomputer) by flamingo.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BaL0I-0000sZ-00 for disman@ietf.org; Tue, 15 Jun 2004 13:57:58 -0700 Message-ID: <008201c4531b$92121ee0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <00c101c41b44$40bd7260$7f1afea9@oemcomputer> Subject: Re: [Disman] Log MIB Implementation Survey Date: Tue, 15 Jun 2004 13:58:55 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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 X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - Two months have passed, and I've seen NO response. I know there are implementations out there, but if I don't see any response, I think there's no point in attempting to update / progress this work. Comments welcomed. Randy > From: "Randy Presuhn" > To: "Disman (E-mail)" > Sent: Monday, April 05, 2004 12:29 PM > Subject: [Disman] Log MIB Implementation Survey > > Hi - > > Here is the Implementation Survey for RFC 3014, the Log MIB. > Please send responses to disman@ietf.org , or, if you would like your implementation > to remain anonymous for the implementation report, to the WG chair at > randy_presuhn@mindspring.com. > > ================================================= > > Implementation Survey for RFC 3014, > Notification Log MIB > > Module: NOTIFICATION-LOG-MIB > Implementation Source: > Management Application / Agent: > > > GROUPs: > notificationLogConfigGroup (y/n): _ > notificationLogStatsGroup (y/n): _ > notificationLogLogGroup (y/n): > notificationLogDateGroup (y/n): _ > > > OBJECTs: > nlmConfigGlobalEntryLimit (rw/ro): _ > lower bound: _______ > upper bound: _______ > nlmConfigLogEntryLimit (rw/ro): _ > lower bound: ________ > upper bound: ________ > nlmConfigLogEntryStatus: (rw/ro): _ > > > Deployment / Operational Experience: > > > Comments: > > > From disman-bounces@ietf.org Wed Jun 16 18:47:51 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27303 for ; Wed, 16 Jun 2004 18:47:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Baiz8-0001Xz-Aq; Wed, 16 Jun 2004 18:34:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BaiNp-0007Ym-9A for disman@megatron.ietf.org; Wed, 16 Jun 2004 17:55:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20164 for ; Wed, 16 Jun 2004 17:55:46 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BaiNl-00043e-52 for disman@ietf.org; Wed, 16 Jun 2004 17:55:45 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BaiJp-000349-00 for disman@ietf.org; Wed, 16 Jun 2004 17:51:43 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 1BaiFr-0001mF-00; Wed, 16 Jun 2004 17:47:35 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.netlab.nec.de (Postfix) with ESMTP id 05D102C911; Wed, 16 Jun 2004 23:47:08 +0200 (CEST) Received: from [192.168.1.10] (unknown [192.168.1.3]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 9ED8C3B530; Wed, 16 Jun 2004 23:47:02 +0200 (CEST) Date: Wed, 16 Jun 2004 23:46:59 +0200 From: Juergen Quittek To: Randy Presuhn , disman@ietf.org Subject: Re: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt Message-ID: <2147483647.1087429619@localhost> 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-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 Cc: ipcdn@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear all, I just posted a new version of the remote operation MIB modules. Following Eduardo's suggestion I added Minimum Compliancy statements in addition to the existing full compliancy statements to each of the three MIB modules. I also had to (syntactically) modify the existing compliancy statements. Please have a close look at all six MODULE-COMPLIANCE macros. Until the document becomes available at the I-D repository, you can preview it at ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-disman-remops-mib-v2-02.txt There was not much response on my questions on how to define the minimum compliance statements. I preferred leaving read-only objects in place to creating non-consecutive numbering of objects in table entries. I am not dogmatic about this and suggestions for changes are very welcome. For simplifying the review here is a list of objects and groups for which the full and minimum compliance statements differ: pingHistoryGroup, pingNotificationsGroup pingCtlDataFill pingCtlFrequency pingCtlMaxRows pingCtlTrapGeneration pingCtlProbeFailureFilter pingCtlTestFailureFilter pingCtlDescr pingCtlByPassRouteTable pingProbeHistoryTime traceRouteHistoryGroup traceRouteCtlByPassRouteTable traceRouteCtlDontFragment traceRouteCtlInitialTtl traceRouteCtlFrequency traceRouteCtlDescr traceRouteCtlMaxRows traceRouteCtlTrapGeneration traceRouteCtlCreateHopsEntries traceRouteCtlRowStatus traceRouteHopsLastGoodProbe lookupCtlRowStatus Beyond the compliance statement I just made two changes to the document: 1. Added new section 3.4 introducing the compliance statement 2. Extended DESCRIPTION clause of object lookupPurgeTime by one sentence: "A value of 0 indicates that automatic deletion of entries is disabled." Thanks, 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 --On 29.04.2004 14:29 h -0700 Randy Presuhn wrote: > Hi - > > Are there any objections to proceding as Juergen and Eduardo suggest? > I'd like to see comment (pro or contra) on the specific questions > Juergen raised below. > > Randy, disman WG chair > >> From: "Juergen Quittek" >> To: "Eduardo Cardona" ; "Randy Presuhn" ; >> Cc: "Ipcdn List (E-mail)" >> Sent: Monday, April 26, 2004 1:11 AM >> Subject: RE: [Disman] WG last call on draft-ietf-disman-remops-mib-v2-01.txt >> > >> Eduardo, >> >> Thank you for raising this issue and my apologies for this >> very late reply. >> >> I ran into similar problems several times where a well designed >> technology was too mighty or too general for being implemented >> at small devices. >> >> Your suggestions aim at introducing additional MODULE-COMPLIANCE >> clauses to the PING-MIB, the TRACEROUTE-MIB and LOOKUP-MIB modules >> for allowing simpler implementations with smaller footprints. >> >> I support your proposal, but have a few comments, see below. >> I am willing to make suggestions for minimalCompliance clauses >> for the MIB modules, but first the WG should agree on two issues: >> >> - Is it agreed to add such clauses, that definitely require >> less funtionality to be implemented? >> >> - what is the preferred procedure for columnar objects that >> are not required for minimal compliancy? We can either >> allow them to be missing completely. But this would result >> in non-consecutive numbering of the remaining objects in >> the minimal tables. Or we require them to be implemented >> as read-only indicating that the feature that they would >> serve in full compliancy is not supported. >> >> Please find further comments inline. >> >> 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 >> >> >> --On 02.03.2004 10:04 h -0700 Eduardo Cardona wrote: >> > Randy, >> > >> > Few comments, >> > >> > I review the MIB and appears compelling respect to previous RFC >> > >> > Just one comment >> > >> > >> > (*) 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. >> >> Currently, the MODULE-COMPLIANCE clause traceRouteCompliance requests >> implementation of this object, but it may be implemented as read-only >> and returning always a value of zero, if there is not further semantics >> defined for it. Do you suggest to completely remove the object or to >> state in the MODULE-COMPLIANCE clause that it does not need to be >> implemented? >> >> > 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 >> > 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? >> >> I doubt that it is a good idea to replicate large portions of the PING-MIB >> in the IPCDN cable gateway Tools MIB module, as it is done right now. >> >> > 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 don't think the remops MIB modules forbid null-named entries in the >> respective tables. But currently the support of a read-write >> pingCtlRowStatus is mandatory. >> >> Is your concrete suggestion to add something like >> >> OBJECT XXRowStatus >> MIN-ACCESS read-only >> DESCRIPTION >> "Implementations may disallow the creation of named entries." >> >> with XX=pingCtl,traceRouteCtl,lookupCtl? >> >> > In summary A new Compliance Statement for small devices with no >> > monitoring capabilities to : >> > 1) remove the constant pulling and login information >> > 2) remove the test row creation >> > - 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 >> > system. >> > - Create an additional set of Compliance statements to require the >> > new Groups and other objects Compliance >> > requirements MIN-ACCESS clauses mainly >> > >> > Schema of the content of the new Compliance statement: >> > >> > List of objects not to include in basicPingGroup OBJECT-GROUP clause >> > qnd/or hints for OBJECT Compliances: >> > pingMaxConcurrentRequests -- remove >> >> Could also be read-only returning 1. >> >> > pingCtlDataFill -- remove or MIN-ACCESS read-only default >> > value is OK >> > pingCtlFrequency -- remove Only one test >> >> Could also be read-only returning 0. >> >> > pingCtlType -- remove or MIN-ACCESS read-only >> > pingCtlByPassRouteTable -- remove or MIN-ACCESS read-only >> > pingCtlDSField -- MIN-ACCESS read-only >> > pingCtlStorageType -- remove >> > pingCtlRowStatus -- SYNTAX RowStatus (notReady(2) >> > WRITE-SYNTAX RowStatus (active(1), notInService(3) >> >> Why don't you consider removing this object? >> >> > 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) >> > 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) >> > >> > >> > Best Regards >> > >> > Eduardo >> > >> > -----Original Message----- >> > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] >> > 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 >> >> 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-bounces@ietf.org Thu Jun 17 14:14:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00581 for ; Thu, 17 Jun 2004 14:14:07 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb14p-0003bl-Qk; Thu, 17 Jun 2004 13:53:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BayYh-00019t-VE; Thu, 17 Jun 2004 11:12:07 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08804; Thu, 17 Jun 2004 11:12:05 -0400 (EDT) Message-Id: <200406171512.LAA08804@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 17 Jun 2004 11:12:05 -0400 X-Mailman-Approved-At: Thu, 17 Jun 2004 13:53:26 -0400 Cc: disman@ietf.org Subject: [Disman] I-D ACTION:draft-ietf-disman-remops-mib-v2-02.txt X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Management Working Group of the IETF. Title : Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations Author(s) : J. Quittek, K. White Filename : draft-ietf-disman-remops-mib-v2-02.txt Pages : 88 Date : 2004-6-17 This memo defines Management Information Bases (MIBs) for performing remote ping, traceroute and lookup operations at a remote host. When managing a network it is useful to be able to initiate and retrieve the results of ping or traceroute operations when performed at a remote host. A Lookup capability is defined in order to enable resolving of either an IP address to an DNS name or an DNS name to an IP address at a remote host. Currently, there are several enterprise-specific MIBs for performing remote ping or traceroute operations. The purpose of this memo is to define a standards-based solution to enable interoperability. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-disman-remops-mib-v2-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-disman-remops-mib-v2-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-17113452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-remops-mib-v2-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-remops-mib-v2-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-17113452.I-D@ietf.org> --OtherAccess-- --NextPart-- From disman-bounces@ietf.org Thu Jun 17 15:27:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07692 for ; Thu, 17 Jun 2004 15:27:11 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb2Fx-0000FI-Mg; Thu, 17 Jun 2004 15:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb24M-0005eN-0q for disman@megatron.ietf.org; Thu, 17 Jun 2004 14:57:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04620 for ; Thu, 17 Jun 2004 14:56:59 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb24J-0000pQ-V9 for disman@ietf.org; Thu, 17 Jun 2004 14:57:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb23Q-0000Th-00 for disman@ietf.org; Thu, 17 Jun 2004 14:56:05 -0400 Received: from falcon.mail.pas.earthlink.net ([207.217.120.74]) by ietf-mx with esmtp (Exim 4.12) id 1Bb21h-0007gi-00; Thu, 17 Jun 2004 14:54:17 -0400 Received: from h-68-164-159-66.snvacaid.dynamic.covad.net ([68.164.159.66] helo=oemcomputer) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1Bb21g-0004wC-00; Thu, 17 Jun 2004 11:54:16 -0700 Message-ID: <02c501c4549c$9d9d9c80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <2147483647.1087429619@localhost> Date: Thu, 17 Jun 2004 11:55:10 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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 Cc: ipcdn@ietf.org Subject: [Disman] Disman WG last call on draft-ietf-disman-remops-mib-v2-02.txt X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - As disman WG chair, I'm announcing the start of a two-week working group last call on the Remote Operations MIBs. The latest version is available at http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-mib-v2-02.txt Our objective is to advance to Draft Standard. Off-line I've received word that that we will have at least two implementation reports. I'm fairly sure there are more out there, so please speak up if you know of an implementation. I'm CC:ing the ipcdn WG mailing list, since we've incorporated some additional conformance material to meet (I hope) their needs. Please send any comments, including "I've read it and don't object" comments, to the disman WG mailing list at disman@ietf.org. The last call will end on Friday, July second, 2004. If anyone is committed to reviewing it but would need additional time, let me know and I'll see what we can work out. Randy From disman-bounces@ietf.org Thu Jun 17 16:07:40 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10005 for ; Thu, 17 Jun 2004 16:07:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb2yw-0001Z3-GM; Thu, 17 Jun 2004 15:55:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb2ml-0006fr-L0 for disman@megatron.ietf.org; Thu, 17 Jun 2004 15:42:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08470 for ; Thu, 17 Jun 2004 15:42:53 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb2mk-0007nc-FA for disman@ietf.org; Thu, 17 Jun 2004 15:42:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb2mF-0007TT-00 for disman@ietf.org; Thu, 17 Jun 2004 15:42:24 -0400 Received: from seymour39.snmp.com ([192.147.142.39]) by ietf-mx with esmtp (Exim 4.12) id 1Bb2kk-0006s9-00 for disman@ietf.org; Thu, 17 Jun 2004 15:40:50 -0400 Received: from snowball.snmp.com (snowball.snmp.com [192.147.142.193]) by seymour39.snmp.com (8.9.3p2-20030922/m.030206) with ESMTP id PAA22607 for ; Thu, 17 Jun 2004 15:40:20 -0400 (EDT) Received: from snowball (moulton@localhost) by snowball.snmp.com (8.11.2/8.11.2/snmpclient.mc-011018) with ESMTP id i5HJeKt14630 for ; Thu, 17 Jun 2004 15:40:20 -0400 Message-Id: <200406171940.i5HJeKt14630@snowball.snmp.com> X-Mailer: exmh version 2.6.1 02/18/2003 with nmh-1.0.4 To: disman@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Thu, 17 Jun 2004 15:40:19 -0400 From: Steve Moulton 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: 8bit Subject: [Disman] DISMAN MIB implementation summaries X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Content-Transfer-Encoding: 8bit The following are implementation summaries for the DISMAN MIBs implemented in SNMP Research products. We do not implement the Notification Log or Expression MIBs. See the end of this message for more deployment information. The summaries were prepared by Alan Luchuk and Brian Beach of the SNMP Research Staff. ---------------------------------------------------------------------- Implementation Survey for RFC 3165 Definition of Managed Objects for the Delegation of Management Scripts Module: DISMAN-SCRIPT-MIB GROUPS: smLanguageGroup: Implemented smScriptGroup2: Implemented smLaunchGroup2: Implemented smRunGroup2: Implemented smNotificationsGroup2: smScriptAbort implemented smScriptResult implemented smScriptException not implemented smCodeGroup: Implemented OBJECTS: smScriptSource: read-only smCodeText: read-write smLaunchArgument: maximum size 2048 smRunArgument: maximum size 2048 smRunResult: maximum size 2048 smRunState suspension permitted: yes Deployment/Operational experience: The DISMAN-SCRIPT-MIB is implementable, does work, and can be used for network management, although it is, shall we say, "MIB Object rich". The lengthy description clauses that describe the interlocking states bet- ween tables makes it difficult to insure the implementation conforms to the specification. In some cases, the documented behavior is counter-intuitive. For example, an intuitive behavior for 'destroying' a row in the smScriptTable would be to delete the row and all subordinate references to it (from the smCodeTable, the smLaunchTable, and smRunTable). But the MIB appears to not allow this. To 'destroy' a row in the smScriptTable, the following procedure must be followed: - terminate all subordinate running instances from the smRunTable; - disable (or expire) all subordinate smLaunchEntries; - 'destroy' all subordinate smLaunchEntries; - disable the 'smScriptAdminStatus'; - 'destroy' the smScriptEntry; The MIB allows instrumenting, launching, suspending, and restarting programs in a multi-process operating system. This capability adds much more complex- ity and agent code size than is necessary to support distributed network management, which seems more likely to need to run fairly modest scripts that start and run perpetually. The added complexity and code size is likely to reduce the the number of implementations and actual field deployment. ---------------------------------------------------------------------- Implementation Survey for RFC 3231 Definition of Managed Objects for Scheduling Management Operations Module: DISMAN-SCHED-MIB GROUPS: schedGroup2: implemented schedNotificationsGroup: implemented schedCalendarGroup: implemented, on systems that support time of day Deployment/Operational experience: The DISMAN-SCHED-MIB is implementable, does work, and can be used for network management. ---------------------------------------------------------------------- Implementation Survey for RFC 2981 Event MIB Module: DISMAN-EVENT-MIB Implementation Survey for RFC 2981, Event MIB Module: DISMAN-EVENT-MIB Implementation Source: SNMP Research Management Application / Agent: CIAgent GROUPs: dismanEventResourceGroup (y/n): y dismanEventTriggerGroup (y/n): y dismanEventObjectsGroup (y/n): y dismanEventEventGroup (y/n): y dismanEventNotificationObjectGroup (y/n): y dismanEventNotificationGroup (y/n): y OBJECTs: mteTriggerTargetTag (ro/rw): ro mteEventSetTargetTag (ro/rw): ro mteTriggerValueIDWildcard (ro/rw): rw mteTriggerContextNameWildcard (ro/rw): ro mteObjectsIDWildcard (ro/rw): ro mteEventSetContextNameWildcard (ro/rw): ro Deployment / Operational Experience: Comments: ---------------------------------------------------------------------- Implementation Survey for RFC 2925 DISMAN Remote Operation MIBs Module: DISMAN-NSLOOKUP-MIB, DISMAN-PING-MIB, and DISMAN-TRACEROUTE-MIB Implemented DISMAN-NSLOOKUP-MIB, DISMAN-PING-MIB, DISMAN-TRACEROUTE-MIB as part of SNMP Research's Service Monitor product to provide remote management of nslookup, ping, and traceroute services. Capabilities - We support all objects of these three MIB Modules with the following exceptions: DISMAN-PING-MIB: pingCtlTargetAddressType - Does not support IPv6 pingCtlDataFill - Not implemented pingCtlType - Only value allowed is pingIcmpEcho pingCtlSourceAddress - Not implemented pingCtlIfIndex - Not implemented pingCtlByPassRouteTable - Not implemented pingCtlDSField - Not implemented DISMAN-TRACEROUTE-MIB traceRouteCtlTargetAddressType - Does not support IPv6 traceRouteCtlByPassRouteTable - Not implemented traceRouteCtlDSField - Not implemented traceRouteCtlSourceAddress - Not implemented traceRouteCtlIfIndex - Not implemented traceRouteCtlDontFragment - Not implemented traceRouteCtlTrapGeneration - pathChange not implemented traceRouteCtlType - Default is using UDP Probes. Only implemented to use ICMP ECHO DISMAN-NSLOOKUP-MIB lookupCtlTargetAddressType - Does not support IPv6 SNMP Research has no immediate plans to add support to the above MIB objects on our roadmap. We support the Service Monitor product including the REMOPS MIBs on Windows (NT, XP, 2000), Solaris 2.x (32, 64-bit), and Red Hat Linux. ---------------------------------------------------------------------- General Summary --------------- The DISMAN-SCHEDULE-MIB, DISMAN-SCRIPT-MIB, and DISMAN-EVENT-MIB have been implemented by SNMP Research, Inc. and included as parts of the CIAgent product. CIAgent may be freely downloaded from the SNMP Research web site for evaluation and interoperability test. The remops-related MIBs are an optional, extra-cost feature of CIAgent, and are not available for download. Since the CIAgent product was first introduced several years ago, SNMP Research, International, Inc., sales reports hundreds of customers have licensed and deployed thousands of copies of CIAgent. Because the remops- related MIBs are an extra-cost feature of CIAgent, their actual licensing and deployment are lower than that of the standard CIAgent components. SNMP Research has internal deployment experience typical for a software development company, that is deployment for internal testing, trade show demos, etc. However, the SNMP Research, Inc., Technical Support group does provide support to customers about the DISMAN MIBs implemented in CIAgent, and does receive feedback from customer deployments. SNMP Research, Inc., Technical Support has received no questions about the DISMAN-SCHEDULE-MIB. SNMP Research, Inc., Technical Support has received questions about the DISMAN-EVENT-MIB from a few customers. SNMP Research, Inc., Technical Support has received questions about the DISMAN-SCRIPT-MIB from a few customers. Many of these questions concern the SNMP Research proprietary SNMP scripting language. SNMP Research, Inc., Technical Support has received no questions about the remops-related MIBs, but again, their deployment numbers are much lower because it is a extra-cost feature. Feedback from our customers is that they typically find the DISMAN MIBs too complex and difficult-to-understand because of the multiple tables and relationships defined between the tables. Maintaining the configurations proves difficult because of the complexity of the configurations and the learning curve required to understand these MIBs. --- SNMP Research, Inc voice: +1 865 573 1434 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 Knoxville, TN 37920-9716 USA http://www.snmp.com From disman-bounces@ietf.org Thu Jun 17 16:09:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10093 for ; Thu, 17 Jun 2004 16:09:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb2yw-0001ZA-Q6; Thu, 17 Jun 2004 15:55:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb2mo-0006gM-1U for disman@megatron.ietf.org; Thu, 17 Jun 2004 15:42:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08482 for ; Thu, 17 Jun 2004 15:42:56 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb2mm-000004-OA for disman@ietf.org; Thu, 17 Jun 2004 15:42:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb2mI-0007Tr-00 for disman@ietf.org; Thu, 17 Jun 2004 15:42:27 -0400 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1Bb2ky-0007Ao-00; Thu, 17 Jun 2004 15:41:04 -0400 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 i5HJditH002885; Thu, 17 Jun 2004 15:39:44 -0400 (EDT) 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 i5HJdgtH002838; Thu, 17 Jun 2004 15:39:43 -0400 (EDT) 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] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt Date: Thu, 17 Jun 2004 22:41:00 +0300 Message-ID: Thread-Topic: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt Thread-Index: AcRUoQrzrk2YeJA3Ri+90L5skCPcRgAAceMw From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , 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 Cc: ipcdn@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Randy, Would it be possible for the authors to provide a log of changes = relative to RFC 2925? Regards, Dan > -----Original Message----- > From: disman-bounces@ietf.org=20 > [mailto:disman-bounces@ietf.org]On Behalf Of Randy Presuhn > Sent: 17 June, 2004 9:55 PM > To: disman@ietf.org > Cc: ipcdn@ietf.org > Subject: [Disman] Disman WG last call=20 > ondraft-ietf-disman-remops-mib-v2-02.txt >=20 >=20 > Hi - >=20 > As disman WG chair, I'm announcing the start of a two-week=20 > working group > last call on the Remote Operations MIBs. The latest version=20 > is available at > http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-m > ib-v2-02.txt > Our objective is to advance to Draft Standard. Off-line I've received > word that that we will have at least two implementation reports. I'm > fairly sure there are more out there, so please speak up if=20 > you know of > an implementation. >=20 > I'm CC:ing the ipcdn WG mailing list, since we've incorporated some > additional conformance material to meet (I hope) their needs. Please > send any comments, including "I've read it and don't object" comments, > to the disman WG mailing list at disman@ietf.org. >=20 > The last call will end on Friday, July second, 2004. If=20 > anyone is committed > to reviewing it but would need additional time, let me know=20 > and I'll see what > we can work out. >=20 > Randy >=20 >=20 >=20 >=20 From disman-bounces@ietf.org Thu Jun 17 16:19:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10891 for ; Thu, 17 Jun 2004 16:19:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb3F2-0007Yo-0i; Thu, 17 Jun 2004 16:12:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb2vx-0000qb-NR for disman@megatron.ietf.org; Thu, 17 Jun 2004 15:52:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09047 for ; Thu, 17 Jun 2004 15:52:23 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb2vv-00037W-SN for disman@ietf.org; Thu, 17 Jun 2004 15:52:23 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb2v8-0002ow-00 for disman@ietf.org; Thu, 17 Jun 2004 15:51:34 -0400 Received: from mail4.riverstonenet.com ([63.113.148.11] helo=rs-sc-exc4.rs.riverstonenet.com) by ietf-mx with esmtp (Exim 4.12) id 1Bb2uf-0002Vq-00 for disman@ietf.org; Thu, 17 Jun 2004 15:51:05 -0400 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: FW: [Disman] REMOPS: any implementations? Date: Thu, 17 Jun 2004 12:50:34 -0700 Message-ID: Thread-Topic: FW: [Disman] REMOPS: any implementations? Thread-Index: AcRT5IfE0WzRS1A/She6QagfiAncvQAIUv9gACarH2A= From: "Haridass, Govind" To: 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: quoted-printable X-Mailman-Approved-At: Thu, 17 Jun 2004 16:12:07 -0400 Cc: "Hongal, Thippanna" , "Rao, Sethu" , quittek@ccrle.nec.de X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I have replied in the form below about our implementation. Thanks. - Govind. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Here is the Implementation Survey for RFC 2925, the Remote Operations MIBs. Please send responses to disman@ietf.org , or, if you would like your implementation to remain anonymous for the implementation report, to the WG chair at randy_presuhn@mindspring.com. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Implementation Survey for RFC 2925, Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations Module: DISMAN-PING-MIB Implementation Source: Management Application / Agent: SNMP Research GROUPs: pingGroup (y/n): _y pingNotificationsGroup (y/n): _y pingTimeStampGroup (y/n): _y OBJECTs: pingMaxConcurrentRequests (rw/ro): __rw pingCtlStorageType (rw/ro): __rw pingCtlType (rw/ro): __rw pingCtlByPassRouteTable (rw/ro): __rw pingCtlSourceAddressType (rw/ro): __rw unknown (y/n): _n ipv4 (y/n): _y ipv6 (y/n): _n pingCtlSourceAddress (rw/ro): __rw pingCtlIfIndex (rw/ro): __rw pingCtlDSField (rw/ro): __rw pingResultsIpTargetAddressType: unknown (y/n): _n ipv4 (y/n): _y ipv6: _n pingResultsIpTargetAddress: 0 (y/n): _ 4 (y/n): _ 16 (y/n): _ Module: DISMAN-TRACEROUTE-MIB Implementation Source: Management Application / Agent: GROUPs: traceRouteGroup (y/n): _y traceRouteTimeStampGroup (y/n): _y traceRouteNotificationsGroup (y/n): _y traceRouteHopsTableGroup (y/n):y OBJECTs: traceRouteMaxConcurrentRequests (rw/ro): __rw traceRouteCtlByPassRouteTable (rw/ro): __rw traceRouteCtlSourceAddressType rw/ro): __rw traceRouteCtlSourceAddress (rw/ro): __rw traceRouteCtlIfIndex (rw/ro): __rw traceRouteCtlMiscOptions (rw/ro): __ro traceRouteCtlStorageType (rw/ro): __rw traceRouteCtlDSField (rw/ro): __rw traceRouteCtlType (rw/ro): __rw traceRouteResultsIpTgtAddrType unknown (y/n): _n ipv4 (y/n): _y ipv6 (y/n): _n traceRouteResultsIpTgtAddr 0 (y/n): _ 4 (y/n): _ 16 (y/n): _ traceRouteProbeHistoryHAddrType unknown (y/n): _n ipv4 (y/n): _y ipv6 (y/n): _n traceRouteProbeHistoryHAddr 0 (y/n): _ 4 (y/n): _ 16 (y/n): _ traceRouteHopsIpTgtAddressType unknown (y/n): _n ipv4 (y/n): _n ipv6 (y/n): _n traceRouteHopsIpTgtAddress 0 (y/n): _ 4 (y/n): _ 16 (y/n): _ Module: DISMAN-NSLOOKUP-MIB Implementation Source: Management Application / Agent: GROUPs lookupGroup (y/n): _ OBJECTs: lookupMaxConcurrentRequests (rw/ro): __ lookupPurgeTime (rw/ro): __ Deployment / Operational Experience: Comments: From disman-bounces@ietf.org Thu Jun 17 16:34:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11868 for ; Thu, 17 Jun 2004 16:34:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb3N3-0002My-15; Thu, 17 Jun 2004 16:20:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb3JD-00015U-Gp for disman@megatron.ietf.org; Thu, 17 Jun 2004 16:16:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10627 for ; Thu, 17 Jun 2004 16:16:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb3JB-0003Pu-Ac for disman@ietf.org; Thu, 17 Jun 2004 16:16:25 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb3I6-00035d-00 for disman@ietf.org; Thu, 17 Jun 2004 16:15:19 -0400 Received: from gull.mail.pas.earthlink.net ([207.217.120.84]) by ietf-mx with esmtp (Exim 4.12) id 1Bb3HF-0002lw-00 for disman@ietf.org; Thu, 17 Jun 2004 16:14:26 -0400 Received: from h-68-164-159-66.snvacaid.dynamic.covad.net ([68.164.159.66] helo=oemcomputer) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1Bb3HE-0002hv-00 for disman@ietf.org; Thu, 17 Jun 2004 13:14:24 -0700 Message-ID: <001101c454a7$cf9c11c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt Date: Thu, 17 Jun 2004 13:15:18 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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 X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" ; > Cc: > Sent: Thursday, June 17, 2004 12:41 PM > Subject: RE: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt > > Would it be possible for the authors to provide a log of changes relative to RFC 2925? ... Juergen Quittek sent out a summary earlier. Do you need something more detailed? Randy From disman-bounces@ietf.org Thu Jun 17 16:44:28 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13002 for ; Thu, 17 Jun 2004 16:44:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb3as-0006Qu-N9; Thu, 17 Jun 2004 16:34:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb3OV-0002ZW-53 for disman@megatron.ietf.org; Thu, 17 Jun 2004 16:21:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11124 for ; Thu, 17 Jun 2004 16:21:52 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb3OT-0005G6-FT for disman@ietf.org; Thu, 17 Jun 2004 16:21:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb3Nc-0004uJ-00 for disman@ietf.org; Thu, 17 Jun 2004 16:21:01 -0400 Received: from gull.mail.pas.earthlink.net ([207.217.120.84]) by ietf-mx with esmtp (Exim 4.12) id 1Bb3MU-0004GQ-00 for disman@ietf.org; Thu, 17 Jun 2004 16:19:50 -0400 Received: from h-68-164-159-66.snvacaid.dynamic.covad.net ([68.164.159.66] helo=oemcomputer) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1Bb3MU-00040f-00 for disman@ietf.org; Thu, 17 Jun 2004 13:19:50 -0700 Message-ID: <001a01c454a8$917c5520$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200406171940.i5HJeKt14630@snowball.snmp.com> Subject: Re: [Disman] DISMAN MIB implementation summaries Date: Thu, 17 Jun 2004 13:20:44 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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 X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - Thanks! I especially appreciate the detailed comments provided, and would like to initiate some (separate) follow-up threads on them. This is the kind of useful feedback we need. Randy > From: "Steve Moulton" > To: > Sent: Thursday, June 17, 2004 12:40 PM > Subject: [Disman] DISMAN MIB implementation summaries > > The following are implementation summaries for the DISMAN MIBs > implemented in SNMP Research products. We do not implement the > Notification Log or Expression MIBs. See the end of this message for > more deployment information. > > The summaries were prepared by Alan Luchuk and Brian Beach of the > SNMP Research Staff. > > ---------------------------------------------------------------------- > > Implementation Survey for RFC 3165 > Definition of Managed Objects for the Delegation of Management Scripts > Module: DISMAN-SCRIPT-MIB > > > GROUPS: > smLanguageGroup: Implemented > smScriptGroup2: Implemented > smLaunchGroup2: Implemented > smRunGroup2: Implemented > smNotificationsGroup2: smScriptAbort implemented > smScriptResult implemented > smScriptException not implemented > smCodeGroup: Implemented > > > OBJECTS: > smScriptSource: read-only > smCodeText: read-write > smLaunchArgument: maximum size 2048 > smRunArgument: maximum size 2048 > smRunResult: maximum size 2048 > smRunState suspension permitted: yes > > > Deployment/Operational experience: > > The DISMAN-SCRIPT-MIB is implementable, does work, and can be used > for network management, although it is, shall we say, "MIB Object rich". > > The lengthy description clauses that describe the interlocking states bet- > ween tables makes it difficult to insure the implementation conforms to the > specification. > > In some cases, the documented behavior is counter-intuitive. For example, > an intuitive behavior for 'destroying' a row in the smScriptTable would be > to delete the row and all subordinate references to it (from the smCodeTable, > the smLaunchTable, and smRunTable). But the MIB appears to not allow this. > To 'destroy' a row in the smScriptTable, the following procedure must be > followed: > > - terminate all subordinate running instances from the smRunTable; > - disable (or expire) all subordinate smLaunchEntries; > - 'destroy' all subordinate smLaunchEntries; > - disable the 'smScriptAdminStatus'; > - 'destroy' the smScriptEntry; > > The MIB allows instrumenting, launching, suspending, and restarting programs > in a multi-process operating system. This capability adds much more complex- > ity and agent code size than is necessary to support distributed network > management, which seems more likely to need to run fairly modest scripts > that start and run perpetually. The added complexity and code size is likely > to reduce the the number of implementations and actual field deployment. > > ---------------------------------------------------------------------- > > Implementation Survey for RFC 3231 > Definition of Managed Objects for Scheduling Management Operations > Module: DISMAN-SCHED-MIB > > GROUPS: > schedGroup2: implemented > schedNotificationsGroup: implemented > schedCalendarGroup: implemented, on systems that support time of day > > > Deployment/Operational experience: > > The DISMAN-SCHED-MIB is implementable, does work, and can be used > for network management. > > ---------------------------------------------------------------------- > > Implementation Survey for RFC 2981 > Event MIB > Module: DISMAN-EVENT-MIB > > > Implementation Survey for RFC 2981, Event MIB > > Module: DISMAN-EVENT-MIB > Implementation Source: SNMP Research > Management Application / Agent: CIAgent > > GROUPs: > dismanEventResourceGroup (y/n): y > dismanEventTriggerGroup (y/n): y > dismanEventObjectsGroup (y/n): y > dismanEventEventGroup (y/n): y > dismanEventNotificationObjectGroup (y/n): y > dismanEventNotificationGroup (y/n): y > > OBJECTs: > mteTriggerTargetTag (ro/rw): ro > mteEventSetTargetTag (ro/rw): ro > mteTriggerValueIDWildcard (ro/rw): rw > mteTriggerContextNameWildcard (ro/rw): ro > mteObjectsIDWildcard (ro/rw): ro > mteEventSetContextNameWildcard (ro/rw): ro > > > Deployment / Operational Experience: > > > Comments: > > > ---------------------------------------------------------------------- > > > Implementation Survey for RFC 2925 > DISMAN Remote Operation MIBs > Module: DISMAN-NSLOOKUP-MIB, DISMAN-PING-MIB, and DISMAN-TRACEROUTE-MIB > > > Implemented DISMAN-NSLOOKUP-MIB, DISMAN-PING-MIB, > DISMAN-TRACEROUTE-MIB as part of SNMP Research's > Service Monitor product to provide remote management of nslookup, ping, > and traceroute services. > > Capabilities - We support all objects of these three MIB Modules with > the following exceptions: > > DISMAN-PING-MIB: > > pingCtlTargetAddressType - Does not support IPv6 > pingCtlDataFill - Not implemented > pingCtlType - Only value allowed is pingIcmpEcho > pingCtlSourceAddress - Not implemented > pingCtlIfIndex - Not implemented > pingCtlByPassRouteTable - Not implemented > pingCtlDSField - Not implemented > > DISMAN-TRACEROUTE-MIB > > traceRouteCtlTargetAddressType - Does not support IPv6 > traceRouteCtlByPassRouteTable - Not implemented > traceRouteCtlDSField - Not implemented > traceRouteCtlSourceAddress - Not implemented > traceRouteCtlIfIndex - Not implemented > traceRouteCtlDontFragment - Not implemented > traceRouteCtlTrapGeneration - pathChange not implemented > traceRouteCtlType - Default is using UDP Probes. Only implemented > to use ICMP ECHO > > DISMAN-NSLOOKUP-MIB > > lookupCtlTargetAddressType - Does not support IPv6 > > > SNMP Research has no immediate plans to add support to the above MIB > objects on our roadmap. > > We support the Service Monitor product including the REMOPS MIBs on > Windows (NT, XP, 2000), Solaris 2.x (32, 64-bit), and Red Hat Linux. > > ---------------------------------------------------------------------- > > General Summary > --------------- > > The DISMAN-SCHEDULE-MIB, DISMAN-SCRIPT-MIB, and DISMAN-EVENT-MIB have > been implemented by SNMP Research, Inc. and included as parts of the > CIAgent product. CIAgent may be freely downloaded from the SNMP Research > web site for evaluation and interoperability test. The remops-related > MIBs are an optional, extra-cost feature of CIAgent, and are not available > for download. > > Since the CIAgent product was first introduced several years ago, SNMP > Research, International, Inc., sales reports hundreds of customers have > licensed and deployed thousands of copies of CIAgent. Because the remops- > related MIBs are an extra-cost feature of CIAgent, their actual licensing > and deployment are lower than that of the standard CIAgent components. > > SNMP Research has internal deployment experience typical for a software > development company, that is deployment for internal testing, trade show > demos, etc. However, the SNMP Research, Inc., Technical Support group > does provide support to customers about the DISMAN MIBs implemented in > CIAgent, and does receive feedback from customer deployments. > > SNMP Research, Inc., Technical Support has received no questions about the > DISMAN-SCHEDULE-MIB. SNMP Research, Inc., Technical Support has received > questions about the DISMAN-EVENT-MIB from a few customers. SNMP Research, > Inc., Technical Support has received questions about the DISMAN-SCRIPT-MIB > from a few customers. Many of these questions concern the SNMP Research > proprietary SNMP scripting language. SNMP Research, Inc., Technical Support > has received no questions about the remops-related MIBs, but again, their > deployment numbers are much lower because it is a extra-cost feature. > > Feedback from our customers is that they typically find the DISMAN MIBs too > complex and difficult-to-understand because of the multiple tables and > relationships defined between the tables. Maintaining the configurations > proves difficult because of the complexity of the configurations and the > learning curve required to understand these MIBs. > > > --- > SNMP Research, Inc voice: +1 865 573 1434 > 3001 Kimberlin Heights Rd. fax: +1 865 573 9197 > Knoxville, TN 37920-9716 USA http://www.snmp.com > > > > > > From disman-bounces@ietf.org Thu Jun 17 16:45:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13096 for ; Thu, 17 Jun 2004 16:45:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb3at-0006RH-VO; Thu, 17 Jun 2004 16:34:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb3Sk-0003ev-8h for disman@megatron.ietf.org; Thu, 17 Jun 2004 16:26:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11253 for ; Thu, 17 Jun 2004 16:26:15 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb3Si-0006nj-Vq for disman@ietf.org; Thu, 17 Jun 2004 16:26:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb3Rl-0006SF-00 for disman@ietf.org; Thu, 17 Jun 2004 16:25:18 -0400 Received: from gull.mail.pas.earthlink.net ([207.217.120.84]) by ietf-mx with esmtp (Exim 4.12) id 1Bb3Qp-00069W-00 for disman@ietf.org; Thu, 17 Jun 2004 16:24:19 -0400 Received: from h-68-164-159-66.snvacaid.dynamic.covad.net ([68.164.159.66] helo=oemcomputer) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1Bb3Qp-000516-00; Thu, 17 Jun 2004 13:24:19 -0700 Message-ID: <002501c454a9$31d70d80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: FW: [Disman] REMOPS: any implementations? Date: Thu, 17 Jun 2004 13:25:13 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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 Cc: "Hongal, Thippanna" , "Rao, Sethu" , "Haridass, Govind" X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - Thanks! Please let me verify: you DIDN'T implement DISMAN-NSLOOKUP-MIB? Randy ---------------------------------------------------------------------------------------------------------------- From: "Haridass, Govind" To: Cc: "Hongal, Thippanna" ; "Rao,Sethu" ; Sent: Thursday, June 17, 2004 12:50 PM Subject: RE: FW: [Disman] REMOPS: any implementations? I have replied in the form below about our implementation. Thanks. - Govind. ================================================= Here is the Implementation Survey for RFC 2925, the Remote Operations MIBs. Please send responses to disman@ietf.org , or, if you would like your implementation to remain anonymous for the implementation report, to the WG chair at randy_presuhn@mindspring.com. ================================================= Implementation Survey for RFC 2925, Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations Module: DISMAN-PING-MIB Implementation Source: Management Application / Agent: SNMP Research GROUPs: pingGroup (y/n): _y pingNotificationsGroup (y/n): _y pingTimeStampGroup (y/n): _y OBJECTs: pingMaxConcurrentRequests (rw/ro): __rw pingCtlStorageType (rw/ro): __rw pingCtlType (rw/ro): __rw pingCtlByPassRouteTable (rw/ro): __rw pingCtlSourceAddressType (rw/ro): __rw unknown (y/n): _n ipv4 (y/n): _y ipv6 (y/n): _n pingCtlSourceAddress (rw/ro): __rw pingCtlIfIndex (rw/ro): __rw pingCtlDSField (rw/ro): __rw pingResultsIpTargetAddressType: unknown (y/n): _n ipv4 (y/n): _y ipv6: _n pingResultsIpTargetAddress: 0 (y/n): _ 4 (y/n): _ 16 (y/n): _ Module: DISMAN-TRACEROUTE-MIB Implementation Source: Management Application / Agent: GROUPs: traceRouteGroup (y/n): _y traceRouteTimeStampGroup (y/n): _y traceRouteNotificationsGroup (y/n): _y traceRouteHopsTableGroup (y/n):y OBJECTs: traceRouteMaxConcurrentRequests (rw/ro): __rw traceRouteCtlByPassRouteTable (rw/ro): __rw traceRouteCtlSourceAddressType rw/ro): __rw traceRouteCtlSourceAddress (rw/ro): __rw traceRouteCtlIfIndex (rw/ro): __rw traceRouteCtlMiscOptions (rw/ro): __ro traceRouteCtlStorageType (rw/ro): __rw traceRouteCtlDSField (rw/ro): __rw traceRouteCtlType (rw/ro): __rw traceRouteResultsIpTgtAddrType unknown (y/n): _n ipv4 (y/n): _y ipv6 (y/n): _n traceRouteResultsIpTgtAddr 0 (y/n): _ 4 (y/n): _ 16 (y/n): _ traceRouteProbeHistoryHAddrType unknown (y/n): _n ipv4 (y/n): _y ipv6 (y/n): _n traceRouteProbeHistoryHAddr 0 (y/n): _ 4 (y/n): _ 16 (y/n): _ traceRouteHopsIpTgtAddressType unknown (y/n): _n ipv4 (y/n): _n ipv6 (y/n): _n traceRouteHopsIpTgtAddress 0 (y/n): _ 4 (y/n): _ 16 (y/n): _ Module: DISMAN-NSLOOKUP-MIB Implementation Source: Management Application / Agent: GROUPs lookupGroup (y/n): _ OBJECTs: lookupMaxConcurrentRequests (rw/ro): __ lookupPurgeTime (rw/ro): __ Deployment / Operational Experience: Comments: From disman-bounces@ietf.org Thu Jun 17 20:58:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01683 for ; Thu, 17 Jun 2004 20:58:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb7XN-00044H-AR; Thu, 17 Jun 2004 20:47:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb7SX-0002bE-Ni for disman@megatron.ietf.org; Thu, 17 Jun 2004 20:42:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00076 for ; Thu, 17 Jun 2004 20:42:20 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb7SW-0005UZ-4f for disman@ietf.org; Thu, 17 Jun 2004 20:42:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb7Re-0005AT-00 for disman@ietf.org; Thu, 17 Jun 2004 20:41:27 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 1Bb7Qj-0004Xa-00 for disman@ietf.org; Thu, 17 Jun 2004 20:40:29 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.netlab.nec.de (Postfix) with ESMTP id B7FE02C913 for ; Fri, 18 Jun 2004 02:39:58 +0200 (CEST) Received: from [192.168.1.8] (unknown [192.168.1.3]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id AFBD1141362 for ; Fri, 18 Jun 2004 02:39:56 +0200 (CEST) Date: Fri, 18 Jun 2004 02:39:55 +0200 From: Juergen Quittek To: "Disman (E-mail)" Subject: Re: [Disman] Remops Implementation Survey Message-ID: <2147483647.1087526395@[192.168.1.8]> In-Reply-To: <00aa01c41b43$b9900a00$7f1afea9@oemcomputer> References: <00aa01c41b43$b9900a00$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-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 X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Content-Transfer-Encoding: 7bit Many thanks to all who submitted Remote Operations MIBs implementation reports. I know that also Juniper has an implementation. Does anyone on the list have contacts to Juniper and can ask there for an implementation report? Below please find the form for the report. Thanks, 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 --On 05.04.2004 12:25 Uhr -0700 Randy Presuhn wrote: > Hi - > > Here is the Implementation Survey for RFC 2925, the Remote Operations MIBs. > Please send responses to disman@ietf.org , or, if you would like your implementation > to remain anonymous for the implementation report, to the WG chair at > randy_presuhn@mindspring.com. > ================================================= Implementation Survey for RFC 2925, Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations Module: DISMAN-PING-MIB Implementation Source: Management Application / Agent: GROUPs: pingGroup (y/n): _ pingNotificationsGroup (y/n): _ pingTimeStampGroup (y/n): _ OBJECTs: pingMaxConcurrentRequests (rw/ro): __ pingCtlStorageType (rw/ro): __ pingCtlType (rw/ro): __ pingCtlByPassRouteTable (rw/ro): __ pingCtlSourceAddressType (rw/ro): __ unknown (y/n): _ ipv4 (y/n): _ ipv6 (y/n): _ pingCtlSourceAddress (rw/ro): __ pingCtlIfIndex (rw/ro): __ pingCtlDSField (rw/ro): __ pingResultsIpTargetAddressType: unknown (y/n): _ ipv4 (y/n): _ ipv6: _ pingResultsIpTargetAddress: 0 (y/n): _ 4 (y/n): _ 16 (y/n): _ Module: DISMAN-TRACEROUTE-MIB Implementation Source: Management Application / Agent: GROUPs: traceRouteGroup (y/n): _ traceRouteTimeStampGroup (y/n): _ traceRouteNotificationsGroup (y/n): _ traceRouteHopsTableGroup (y/n): OBJECTs: traceRouteMaxConcurrentRequests (rw/ro): __ traceRouteCtlByPassRouteTable (rw/ro): __ traceRouteCtlSourceAddressType rw/ro): __ traceRouteCtlSourceAddress (rw/ro): __ traceRouteCtlIfIndex (rw/ro): __ traceRouteCtlMiscOptions (rw/ro): __ traceRouteCtlStorageType (rw/ro): __ traceRouteCtlDSField (rw/ro): __ traceRouteCtlType (rw/ro): __ traceRouteResultsIpTgtAddrType unknown (y/n): _ ipv4 (y/n): _ ipv6 (y/n): _ traceRouteResultsIpTgtAddr 0 (y/n): _ 4 (y/n): _ 16 (y/n): _ traceRouteProbeHistoryHAddrType unknown (y/n): _ ipv4 (y/n): _ ipv6 (y/n): _ traceRouteProbeHistoryHAddr 0 (y/n): _ 4 (y/n): _ 16 (y/n): _ traceRouteHopsIpTgtAddressType unknown (y/n): _ ipv4 (y/n): _ ipv6 (y/n): _ traceRouteHopsIpTgtAddress 0 (y/n): _ 4 (y/n): _ 16 (y/n): _ Module: DISMAN-NSLOOKUP-MIB Implementation Source: Management Application / Agent: GROUPs lookupGroup (y/n): _ OBJECTs: lookupMaxConcurrentRequests (rw/ro): __ lookupPurgeTime (rw/ro): __ Deployment / Operational Experience: Comments: From disman-bounces@ietf.org Thu Jun 17 23:39:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09046 for ; Thu, 17 Jun 2004 23:39:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbA41-0007Na-HU; Thu, 17 Jun 2004 23:29:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bb3f8-0007Ce-FN for disman@megatron.ietf.org; Thu, 17 Jun 2004 16:39:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12233 for ; Thu, 17 Jun 2004 16:39:04 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bb3f7-00035I-62 for disman@ietf.org; Thu, 17 Jun 2004 16:39:05 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bb3e7-0002hO-00 for disman@ietf.org; Thu, 17 Jun 2004 16:38:04 -0400 Received: from mail4.riverstonenet.com ([63.113.148.11] helo=rs-sc-exc4.rs.riverstonenet.com) by ietf-mx with esmtp (Exim 4.12) id 1Bb3d1-00023p-00 for disman@ietf.org; Thu, 17 Jun 2004 16:36:55 -0400 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: [Disman] REMOPS: any implementations? Date: Thu, 17 Jun 2004 13:36:25 -0700 Message-ID: Thread-Topic: FW: [Disman] REMOPS: any implementations? Thread-Index: AcRUqRO82097jxlYTfeDBtmDVGN3ngAAaIDg From: "Haridass, Govind" To: "Randy Presuhn" , 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: quoted-printable X-Mailman-Approved-At: Thu, 17 Jun 2004 23:29:12 -0400 Cc: "Hongal, Thippanna" , "Rao, Sethu" X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Yes. We didnot implement the DISMAN-NSLOOKUP_MIB. Thanks. - Govind. -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Thursday, June 17, 2004 1:25 PM To: disman@ietf.org Cc: Hongal, Thippanna; Rao, Sethu; Haridass, Govind Subject: Re: FW: [Disman] REMOPS: any implementations? Hi - Thanks! Please let me verify: you DIDN'T implement DISMAN-NSLOOKUP-MIB? Randy -------------------------------------------------------------------------= --------------------------------------- From: "Haridass, Govind" To: Cc: "Hongal, Thippanna" ; "Rao,Sethu" = ; Sent: Thursday, June 17, 2004 12:50 PM Subject: RE: FW: [Disman] REMOPS: any implementations? I have replied in the form below about our implementation. Thanks. - Govind. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Here is the Implementation Survey for RFC 2925, the Remote Operations MIBs. Please send responses to disman@ietf.org , or, if you would like your implementation to remain anonymous for the implementation report, to the WG chair at randy_presuhn@mindspring.com. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Implementation Survey for RFC 2925, Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations Module: DISMAN-PING-MIB Implementation Source: Management Application / Agent: SNMP Research GROUPs: pingGroup (y/n): _y pingNotificationsGroup (y/n): _y pingTimeStampGroup (y/n): _y OBJECTs: pingMaxConcurrentRequests (rw/ro): __rw pingCtlStorageType (rw/ro): __rw pingCtlType (rw/ro): __rw pingCtlByPassRouteTable (rw/ro): __rw pingCtlSourceAddressType (rw/ro): __rw unknown (y/n): _n ipv4 (y/n): _y ipv6 (y/n): _n pingCtlSourceAddress (rw/ro): __rw pingCtlIfIndex (rw/ro): __rw pingCtlDSField (rw/ro): __rw pingResultsIpTargetAddressType: unknown (y/n): _n ipv4 (y/n): _y ipv6: _n pingResultsIpTargetAddress: 0 (y/n): _ 4 (y/n): _ 16 (y/n): _ Module: DISMAN-TRACEROUTE-MIB Implementation Source: Management Application / Agent: GROUPs: traceRouteGroup (y/n): _y traceRouteTimeStampGroup (y/n): _y traceRouteNotificationsGroup (y/n): _y traceRouteHopsTableGroup (y/n):y OBJECTs: traceRouteMaxConcurrentRequests (rw/ro): __rw traceRouteCtlByPassRouteTable (rw/ro): __rw traceRouteCtlSourceAddressType rw/ro): __rw traceRouteCtlSourceAddress (rw/ro): __rw traceRouteCtlIfIndex (rw/ro): __rw traceRouteCtlMiscOptions (rw/ro): __ro traceRouteCtlStorageType (rw/ro): __rw traceRouteCtlDSField (rw/ro): __rw traceRouteCtlType (rw/ro): __rw traceRouteResultsIpTgtAddrType unknown (y/n): _n ipv4 (y/n): _y ipv6 (y/n): _n traceRouteResultsIpTgtAddr 0 (y/n): _ 4 (y/n): _ 16 (y/n): _ traceRouteProbeHistoryHAddrType unknown (y/n): _n ipv4 (y/n): _y ipv6 (y/n): _n traceRouteProbeHistoryHAddr 0 (y/n): _ 4 (y/n): _ 16 (y/n): _ traceRouteHopsIpTgtAddressType unknown (y/n): _n ipv4 (y/n): _n ipv6 (y/n): _n traceRouteHopsIpTgtAddress 0 (y/n): _ 4 (y/n): _ 16 (y/n): _ Module: DISMAN-NSLOOKUP-MIB Implementation Source: Management Application / Agent: GROUPs lookupGroup (y/n): _ OBJECTs: lookupMaxConcurrentRequests (rw/ro): __ lookupPurgeTime (rw/ro): __ Deployment / Operational Experience: Comments: From disman-bounces@ietf.org Thu Jun 17 23:50:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09743 for ; Thu, 17 Jun 2004 23:50:10 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbAFk-0001ox-7H; Thu, 17 Jun 2004 23:41:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbACv-0000ID-Lf for disman@megatron.ietf.org; Thu, 17 Jun 2004 23:38:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09028 for ; Thu, 17 Jun 2004 23:38:19 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbACq-0002zG-O6 for disman@ietf.org; Thu, 17 Jun 2004 23:38:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbABr-0002ey-00 for disman@ietf.org; Thu, 17 Jun 2004 23:37:19 -0400 Received: from swan.mail.pas.earthlink.net ([207.217.120.123]) by ietf-mx with esmtp (Exim 4.12) id 1BbAAr-0002E2-00 for disman@ietf.org; Thu, 17 Jun 2004 23:36:17 -0400 Received: from h-68-165-64-21.snvacaid.dynamic.covad.net ([68.165.64.21] helo=oemcomputer) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BbAAq-0005Tk-00 for disman@ietf.org; Thu, 17 Jun 2004 20:36:17 -0700 Message-ID: <001201c454e5$8acdbec0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" Date: Thu, 17 Jun 2004 20:37:12 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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 Subject: [Disman] Fw: New versions of guidelines for Internet-Drafts X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - If you to submit any documents for consideration by this WG, or if you are currently a document editor, or if you would like to become a document editor, PLEAESE read the following. Randy, disman WG chair > From: "Harald Alvestrand" > To: "IETF Announcement list" > Sent: Thursday, June 17, 2004 3:29 PM > Subject: New versions of guidelines for Internet-Drafts > > The IESG has emitted new versions of the following guideline documents: > > "Guidelines to authors of Internet-Drafts" > http://www.ietf.org/ietf/1id-guidelines.txt > > which has been updated to reflect the new IPR policy RFCs (3667 and 3668): > Note that in this process, we discovered a bug in one of the RFCs; the document > ontains a temporary fix, but the details of a permanent fix are still being > worked out on the IPR WG list. > > "Checklist for Internet-Drafts submitted for RFC publication" > http://www.ietf.org/ID-Checklist.html > > This has had a more thorough review/revision, and should be re-read by all > participants. Note in particular the new language about IANA considerations. > > (This was actually posted a month ago, but has not been announced to this list > et, so I am including it in this announcement.) > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce From disman-bounces@ietf.org Fri Jun 18 18:19:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27475 for ; Fri, 18 Jun 2004 18:19:21 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbRWQ-0003ug-Lj; Fri, 18 Jun 2004 18:07:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbRSJ-00020E-DW for disman@megatron.ietf.org; Fri, 18 Jun 2004 18:03:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25657 for ; Fri, 18 Jun 2004 18:03:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbRSI-00063Y-0j for disman@ietf.org; Fri, 18 Jun 2004 18:03:26 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbRRJ-0005gl-00 for disman@ietf.org; Fri, 18 Jun 2004 18:02:25 -0400 Received: from swan.mail.pas.earthlink.net ([207.217.120.123]) by ietf-mx with esmtp (Exim 4.12) id 1BbRQL-0005Jf-00; Fri, 18 Jun 2004 18:01:25 -0400 Received: from h-68-164-158-226.snvacaid.dynamic.covad.net ([68.164.158.226] helo=oemcomputer) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BbRQK-0003Ud-00; Fri, 18 Jun 2004 15:01:24 -0700 Message-ID: <009c01c4557f$ee431dc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [ipcdn] RE: [Disman] Disman WG last callondraft-ietf-disman-remops-mib-v2-02.txt Date: Fri, 18 Jun 2004 15:02:21 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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 Cc: "Disman \(E-mail\)" X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - > From: "Romascanu, Dan (Dan)" > To: "Randy Presuhn" ; > Cc: > Sent: Thursday, June 17, 2004 12:41 PM > Subject: [ipcdn] RE: [Disman] Disman WG last callondraft-ietf-disman-remops-mib-v2-02.txt > > Randy, > > Would it be possible for the authors to provide a log of changes relative to RFC 2925? ... Juergen Quittek's summary of June 16 appears below. Do you need more detail? Please send any followup discussion to the disman WG mailing list. Randy --------------------------------------------------- Dear all, I just posted a new version of the remote operation MIB modules. Following Eduardo's suggestion I added Minimum Compliancy statements in addition to the existing full compliancy statements to each of the three MIB modules. I also had to (syntactically) modify the existing compliancy statements. Please have a close look at all six MODULE-COMPLIANCE macros. Until the document becomes available at the I-D repository, you can preview it at ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-disman-remops-mib-v2-02.txt There was not much response on my questions on how to define the minimum compliance statements. I preferred leaving read-only objects in place to creating non-consecutive numbering of objects in table entries. I am not dogmatic about this and suggestions for changes are very welcome. For simplifying the review here is a list of objects and groups for which the full and minimum compliance statements differ: pingHistoryGroup, pingNotificationsGroup pingCtlDataFill pingCtlFrequency pingCtlMaxRows pingCtlTrapGeneration pingCtlProbeFailureFilter pingCtlTestFailureFilter pingCtlDescr pingCtlByPassRouteTable pingProbeHistoryTime traceRouteHistoryGroup traceRouteCtlByPassRouteTable traceRouteCtlDontFragment traceRouteCtlInitialTtl traceRouteCtlFrequency traceRouteCtlDescr traceRouteCtlMaxRows traceRouteCtlTrapGeneration traceRouteCtlCreateHopsEntries traceRouteCtlRowStatus traceRouteHopsLastGoodProbe lookupCtlRowStatus Beyond the compliance statement I just made two changes to the document: 1. Added new section 3.4 introducing the compliance statement 2. Extended DESCRIPTION clause of object lookupPurgeTime by one sentence: "A value of 0 indicates that automatic deletion of entries is disabled." From disman-bounces@ietf.org Fri Jun 18 18:20:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27602 for ; Fri, 18 Jun 2004 18:20:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbRX2-0004E6-Vd; Fri, 18 Jun 2004 18:08:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbRT4-0002M8-G6 for disman@megatron.ietf.org; Fri, 18 Jun 2004 18:04:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25756 for ; Fri, 18 Jun 2004 18:04:11 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbRT2-0006P3-UX for disman@ietf.org; Fri, 18 Jun 2004 18:04:13 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbRS9-000634-00 for disman@ietf.org; Fri, 18 Jun 2004 18:03:20 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 1BbRRF-0005Jp-00; Fri, 18 Jun 2004 18:02:21 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.netlab.nec.de (Postfix) with ESMTP id 972912C916; Sat, 19 Jun 2004 00:01:46 +0200 (CEST) Received: from [192.168.1.6] (unknown [192.168.1.6]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id D1713FECD7; Sat, 19 Jun 2004 00:01:39 +0200 (CEST) Date: Sat, 19 Jun 2004 00:01:40 +0200 From: Juergen Quittek To: "Romascanu, Dan (Dan)" , Randy Presuhn , disman@ietf.org Subject: RE: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt Message-ID: <2147483647.1087603299@[192.168.1.6]> In-Reply-To: References: 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-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 Cc: ipcdn@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Content-Transfer-Encoding: 7bit Dan, Please find the list of changes at the end of this message. Thanks, 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 --On 17.06.2004 22:41 Uhr +0300 Romascanu, Dan (Dan) wrote: > Randy, > > Would it be possible for the authors to provide a log of changes relative to RFC 2925? > > Regards, > > Dan > > > >> -----Original Message----- >> From: disman-bounces@ietf.org >> [mailto:disman-bounces@ietf.org]On Behalf Of Randy Presuhn >> Sent: 17 June, 2004 9:55 PM >> To: disman@ietf.org >> Cc: ipcdn@ietf.org >> Subject: [Disman] Disman WG last call >> ondraft-ietf-disman-remops-mib-v2-02.txt >> >> >> Hi - >> >> As disman WG chair, I'm announcing the start of a two-week >> working group >> last call on the Remote Operations MIBs. The latest version >> is available at >> http://www.ietf.org/internet-drafts/draft-ietf-disman-remops-m >> ib-v2-02.txt >> Our objective is to advance to Draft Standard. Off-line I've received >> word that that we will have at least two implementation reports. I'm >> fairly sure there are more out there, so please speak up if >> you know of >> an implementation. >> >> I'm CC:ing the ipcdn WG mailing list, since we've incorporated some >> additional conformance material to meet (I hope) their needs. Please >> send any comments, including "I've read it and don't object" comments, >> to the disman WG mailing list at disman@ietf.org. >> >> The last call will end on Friday, July second, 2004. If >> anyone is committed >> to reviewing it but would need additional time, let me know >> and I'll see what >> we can work out. >> >> Randy >> >> ====================================================================== Changes in draft-ietf-disman-remops-mib-v2-00.txt compared to RFC 2925 ====================================================================== ======================================================================== 1. typo in description of pingTestCompleted ======================================================================== Problem Description: ------------------------------------------------------------------------ >From RFC Errata web page Reported by: Randy Presuhn; rpresuhn@dorothy.bmc.com Date: Tue, 26 Mar 2002 15:16:54 -0800 In Section 4.1: "Generated at the completion of a ping test when the corresponding pingCtlTrapGeneration object is set to testCompletion(4)." Should be: "Generated at the completion of a ping test when the corresponding pingCtlTrapGeneration object is set to testCompletion(2)." ======================================================================== Suggested solution: ------------------------------------------------------------------------ obvious ======================================================================== Status: solution committed ======================================================================== ======================================================================== 2. description of pingCtlDataSize ignores IPv6 ======================================================================== Problem Description: ------------------------------------------------------------------------ Currently, RFC 2925 says: pingCtlDataSize OBJECT-TYPE SYNTAX Unsigned32 (0..65507) UNITS "octets" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the size of the data portion to be transmitted in a ping operation in octets. A ping request is usually an ICMP message encoded into an IP packet. An IP packet has a maximum size of 65535 octets. Subtracting the size of the ICMP or UDP header (both 8 octets) and the size of the IP header (20 octets) yields a maximum size of 65507 octets." DEFVAL { 0 } ::= { pingCtlEntry 5 } This has caused some concern that the MIB isn't right for IPv6. ======================================================================== Suggested solution: ------------------------------------------------------------------------ Replace description by "Specifies the size of the data portion to be transmitted in a ping operation in octets. Whether or not this value can be applied depends on the selected implementation method for performing a ping operation indicated by pingCtlType in the same conceptual row. If the method used allows applying the value contained in this object, then it MUST be applied. If the specified size is not appropriate for the chosen ping method, the implementation SHOULD use whatever size (appropriate to the method) is closest to the specified size. The maximum value for this object was computed by substracting the smallest possible IP header size of 20 octets (IPv4 header with no options) and the UDP header size of 8 octets from the maximum IP packet size. An IP packet has a maximum size of 65535 octets (excluding IPv6 Jumbograms)." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 3. description of traceRouteCtlDataSize ignores IPv6 ======================================================================== Problem Description: ------------------------------------------------------------------------ Currently, RFC 2925 says: traceRouteCtlDataSize OBJECT-TYPE SYNTAX Unsigned32 (0..65507) UNITS "octets" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the size of the data portion of a traceroute request in octets. A traceroute request is essentially transmitted by encoding a UDP datagram into a IP packet. So subtracting the size of a UDP header (8 octets) and the size of a IP header (20 octets) yields a maximum of 65507 octets." DEFVAL { 0 } ::= { traceRouteCtlEntry 6 } This has caused some concern that the MIB isn't right for IPv6. ======================================================================== Suggested solution: ------------------------------------------------------------------------ Replace description by "Specifies the size of the data portion of a traceroute request in octets. If the RECOMMENDED traceroute method (UDP datagrams as probes) is used, then the value contained in this object MUST be applied. If another traceroute method is used for which the specified size is not appropriate, then the implementation SHOULD use whatever size (appropriate to the method) is closest to the specified size. The maximum value for this object was computed by substracting the smallest possible IP header size of 20 octets (IPv4 header with no options) and the UDP header size of 8 octets from the maximum IP packet size. An IP packet has a maximum size of 65535 octets (excluding IPv6 Jumbograms)." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 4. SNMP boilerplate outdated ======================================================================== Problem Description: ------------------------------------------------------------------------ Section 2 on "The Internet-Standard Management Framework" is outdated. ======================================================================== Suggested solution: ------------------------------------------------------------------------ Replace with new one. This implies an update of the reference section. ======================================================================== Status: solution committed ======================================================================== ======================================================================== 5. References need to be split in normative and informational ones. ======================================================================== Problem Description: ------------------------------------------------------------------------ clear ======================================================================== Suggested solution: ------------------------------------------------------------------------ 7. Normative References [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. 8. Informative References [RFC2119] S. Bradner "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC862] J. Postel "Echo Protocol", STD 20, RFC 862, May 1983. [RFC792] J. Postel "Internet Control Message Protocol", RFC 792, September 1981. [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet- Standard Management Framework", RFC 3410, December 2002. [RFC3415] B. Wijnen, R. Presuhn, K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. ======================================================================== Status: solution committed ======================================================================== ======================================================================== 6. clarify structure of Section 1 "Introduction" ======================================================================== Problem Description: ------------------------------------------------------------------------ The structure of the introduction would be clearer if subsections were used. ======================================================================== Suggested solution: ------------------------------------------------------------------------ insert subsection headers 1.1. Ping 1.2. Traceroute 1.3. Lookup 1.4. Remote Operations ======================================================================== Status: solution committed ======================================================================== ======================================================================== 7. context of remote operations explanation not clear ======================================================================== Problem Description: ------------------------------------------------------------------------ At the end of Section 1 "Introduction" the remote operations scenario is described. The description starts without explaining the context. ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace "Consider the following diagram:" by "The MIB modules defined in this document allow a management station to initiate ping, traceroute and lookup operations remotely. The basic scenario is illustrated by the following diagram." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 8. diagram explaining remote operations scenario ======================================================================== Problem Description: ------------------------------------------------------------------------ The diagram at the end of Section 1 "Introduction" +--------------------------------------------------------------------+ | | | Remote ping, traceroute, Actual ping, traceroute, | | +-----+or Lookup op. +------+or Lookup op. +------+ | | |Local|---------------->|Remote|---------------->|Target| | | | Host| | Host | | Host | | | +-----+ +------+ +------+ | | | | | +--------------------------------------------------------------------+ uses "local host" and "remote host". In order to align it with the SNMP management framework, these terms should be replaced by "management station" or "managed node", respectively. also it would increase clarity if the remote initiation of operations was separated from reciving results. ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace diagram by +-------+ +-------+ +-------+ | |---------->| | | | | | initiate | |---------->| | | Mgmt. | operation |Managed| perform |Target | |Station| remotely | Node | operation | Host | | | | | | | | |<----------| | | | +-------+ receive +-------+ +-------+ result of operation and update text in following paragraph accordingly. ======================================================================== Status: solution committed ======================================================================== ======================================================================== 9. RFC 2575 (VACM) obsoleted ======================================================================== Problem Description: ------------------------------------------------------------------------ RFC 2575 (VACM) is referenced several times in the document. RFC 2575 has been obsoleted by RFC 3415. ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace RFC 2575 by RFC 3415 in text, MIBs and reference sections. ======================================================================== Status: solution committed ======================================================================== ======================================================================== 10. obsoleted RFCs metioned in IPORT sections ======================================================================== Problem Description: ------------------------------------------------------------------------ RFC 2571 imported by DISMAN-PING-MIB is obsoleted by RFC 3411. RFC 2571 imported by DISMAN-TRACEROUTE-MIB is obsoleted by RFC 3411. RFC 2571 imported by DISMAN-NSLOOKUP-MIB is obsoleted by RFC 3411. RFC 2851 imported by DISMAN-PING-MIB is obsoleted by RFC 3291. RFC 2851 imported by DISMAN-TRACEROUTE-MIB is obsoleted by RFC 3291. RFC 2851 imported by DISMAN-NSLOOKUP-MIB is obsoleted by RFC 3291. ======================================================================== Suggested solution: ------------------------------------------------------------------------ The comment in DISMAN-PING-MIB IMPORT section needs to be updated. The comment in DISMAN-TRACEROUTE-MIB IMPORT section needs to be updated. The comment in DISMAN-NSLOOKUP-MIB IMPORT section needs to be updated. The comment in DISMAN-PING-MIB IMPORT section needs to be updated. The comment in DISMAN-TRACEROUTE-MIB IMPORT section needs to be updated. The comment in DISMAN-NSLOOKUP-MIB IMPORT section needs to be updated. ======================================================================== Status: solution committed ======================================================================== ======================================================================== 11. Update contact info in MIB modules ======================================================================== Problem Description: ------------------------------------------------------------------------ So far Kenneth served as contact. Now Juergen edits the docuemnt and takes over. ======================================================================== Suggested solution: ------------------------------------------------------------------------ Replace Kenneth by Juergen in all three MIB modules. ======================================================================== Status: solution committed ======================================================================== ======================================= changes from version -00 to version -01 ======================================= ======================================================================== 12. clarification required for pingMaxConcurrentRequests and lookupMaxConcurrentRequests ======================================================================== Problem Description: ------------------------------------------------------------------------ The DESCRIPTION clause of object pingMaxConcurrentRequests does not explain how to deal with the case that its value is reduced to a number smaller than the number of active requests. The same applies to the DESCRIPTION clause of object lookupMaxConcurrentRequests. ======================================================================== Suggested solution: ------------------------------------------------------------------------ append "The limit applies only to new requests being activated. When a new value is set, the agent will continue processing all the requests already active, even if their number exceed the limit just imposed." to DESCRIPTION clause of object pingMaxConcurrentRequests and to DESCRIPTION clause of object lookupMaxConcurrentRequests ======================================================================== Status: solution committed ======================================================================== ======================================================================== 13. No default value for pingCtlTrapGeneration ======================================================================== Problem Description: ------------------------------------------------------------------------ The DESCRIPTION clause of object pingCtlTrapGeneration suggests that the object "defaults to zero", but there is no DEFVAL clause. ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace in DESCRIPTION clause "The value of this object defaults to zero, indicating that none of the above options have been selected." with "By default, no bits are set, indicating that none of the above options are selected." and add "DEFVAL { {} } -- no bits set." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 14. Re-initialization of entries in ping/tracerouteResultsTable unclear ======================================================================== Problem Description: ------------------------------------------------------------------------ The DESCRIPTION clause of objects pingResultsTable and traceRouteResultsTable do not describe the semantics of re-initialization. ======================================================================== Suggested solution: ------------------------------------------------------------------------ add to DESCRIPTION clause of object pingResultsTable "If object pingCtlAdminStatus already has value enabled(1) and if the corresponding pingResultsOperStatus object has value completed(3), then successfully writing enabled(1) to object pingCtlAdminStatus re-initializes the already existing entry in the pingResultsTable. The values of objects in the re-initialized entry are the same than the values of objects in a new entry would be." add to DESCRIPTION clause of object traceRouteResultsTable "If object traceRouteCtlAdminStatus already has value enabled(1) and if the corresponding traceRouteResultsOperStatus object has value completed(3), then successfully writing enabled(1) to object traceRouteCtlAdminStatus re-initializes the already existing entry in the traceRouteResultsTable. The values of objects in the re-initialized entry are the same than the values of objects in a new entry would be." add value completed(3) to SYNTAX clause of pingResultsOperStatus add value completed(3) to SYNTAX clause of traceRouteResultsOperStatus ======================================================================== Status: solution committed ======================================================================== ======================================================================== 15. Some objects have syntax Unsigned32 but should be Gauge32 ======================================================================== Problem Description: ------------------------------------------------------------------------ Some counters have syntax Unsigned32. Gauge32 fits better. ======================================================================== Suggested solution: ------------------------------------------------------------------------ Change SYNTAX clause from Unsigned32 to Gauge32 for objects pingResultsProbeResponses, pingResultsSentProbes, traceRouteResultsTestAttempts, traceRouteResultsTestSuccesses ======================================================================== Status: solution committed ======================================================================== ======================================================================== 16. Typo in DESCRIPTION clause of pingTestCompleted ======================================================================== Problem Description: ------------------------------------------------------------------------ The DESCRIPTION clause of pingTestCompleted refers to value testCompletion(4) of object pingCtlTrapGeneration. Correct is testCompletion(2). ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace "corresponding pingCtlTrapGeneration object is set to testCompletion(4)." with "corresponding pingCtlTrapGeneration object has the testCompletion(2) bit set." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 17. Value of 0 does not make sense for traceRouteCtlInitialTtl ======================================================================== Problem Description: ------------------------------------------------------------------------ The SYNTAX clause of object traceRouteCtlInitialTtl includes 0. This is not a useful value. ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace "SYNTAX Unsigned32 (0..255)" with "SYNTAX Unsigned32 (1..255)" ======================================================================== Status: solution committed ======================================================================== ======================================================================== 18. Irritating description of traceRouteCtlFrequency ======================================================================== Problem Description: ------------------------------------------------------------------------ The DESCRIPTION clause of object traceRouteCtlFrequency contains an irritating sentence referring to the number of hops per single traceroute test. ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace "The number of hops in a single traceroute test is determined by the value of the corresponding traceRouteCtlProbesPerHop object. After a single test completes the number of seconds as defined by the value of traceRouteCtlFrequency MUST elapse before the next traceroute test is started." with "After a single test completes the number of seconds as defined by the value of traceRouteCtlFrequency MUST elapse before the next traceroute test is started." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 19. What is a good path? ======================================================================== Problem Description: ------------------------------------------------------------------------ The DESCRIPTION clause of object traceRouteResultsLastGoodPath does not clearly describe the term 'good' or 'complete' path. ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace DESCRIPTION clause "The date and time when the last complete path was determined." with "The date and time when the last complete path was determined. A path is complete if responses were received or timeout occurred for each hop on the path, i.e. for each TTL value from the value of the corresponding traceRouteCtlInitialTtl object up to the end of the path or - if no reply from the target IP address was received - up to the value of the corresponding traceRouteCtlMaxTtl object." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 20. Fixing bug in SYNTAX clause of lookupCtlOperStatus ======================================================================== Problem Description: ------------------------------------------------------------------------ The DESCRIPTION clause of object lookupCtlOperStatus defines values notStarted(2) and completed(3), but enabled(1) is missing, although enabled(1) is defined in the DESCRIPTION clause. ======================================================================== Suggested solution: ------------------------------------------------------------------------ add to SYNTAX clause "enabled(1), -- operation is active" ======================================================================== Status: solution committed ======================================================================== ======================================================================== 21. Missing references ======================================================================== Problem Description: ------------------------------------------------------------------------ Some RFCs are mentioned in DESCRIPTION clauses of the MIB definition, but not referenced in the Reference section. ======================================================================== Suggested solution: ------------------------------------------------------------------------ add to Normative References [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. [RFC3291] Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder "Textual Conventions for Internet Network Addresses", RFC 3291, May 2002. add to Normative References [RFC2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [RFC1812] F. Baker, "Requirements for IP Version 4 Routers", RFC 1812, June 1995. ======================================================================== Status: solution committed ======================================================================== ======================================= changes from version -01 to version -02 ======================================= ======================================================================== 22. The compliance ststements are not well suited for small devices ======================================================================== Problem Description: ------------------------------------------------------------------------ For small devices it might be desirable to support just a single test per MIB module. Then creating and deleting table entries is not required anymore. ======================================================================== Suggested solution: ------------------------------------------------------------------------ Add new MODULE-COMPLIANCY statements pingMinimumCompliance, traceRouteMinimumCompliance, lookupMinimumCompliance. The already existing MODULE-COMPLIANCY statements pingCompliance and traceRouteCompliance are syntactically modified, but semantically unchanged. For the following objects pingCompliance and pingMinimumCompliance differ: pingCtlDataFill pingCtlFrequency pingCtlMaxRows pingCtlTrapGeneration pingCtlProbeFailureFilter pingCtlTestFailureFilter pingCtlDescr pingCtlByPassRouteTable pingProbeHistoryTime For the following objects traceRouteCompliance and traceRouteMinimumCompliance differ: traceRouteCtlByPassRouteTable traceRouteCtlDontFragment traceRouteCtlInitialTtl traceRouteCtlFrequency traceRouteCtlDescr traceRouteCtlMaxRows traceRouteCtlTrapGeneration traceRouteCtlCreateHopsEntries traceRouteCtlRowStatus traceRouteHopsLastGoodProbe For the following objects lookupCompliance and lookupMinimumCompliance differ: lookupCtlRowStatus Add new section "3.4. Conformance Each of the three MIB modules defined in this document has two compliancy statements, one for full compliancy and one for minimum compliancy. The minimum compliancy statements are intended to be applied to implementation for devices with very limited resources. The main difference between full and minimum compliancy is that for minimum compliancy dynamic creation and deletion of table entries is not required while it is required for full compliancy." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 23. disabling of lookupPurgeTime ======================================================================== Problem Description: ------------------------------------------------------------------------ There is no value defined for object lookupPurgeTime that disables the function of automatich entry deletion. Also, the use of value 0 is questionable. ======================================================================== Suggested solution: ------------------------------------------------------------------------ Add to DESCRIPTION clause "A value of 0 indicates that automatic deletion of entries is disabled." ======================================================================== Status: solution committed ======================================================================== From disman-bounces@ietf.org Fri Jun 18 18:25:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27907 for ; Fri, 18 Jun 2004 18:25:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbRkI-0002Jj-KR; Fri, 18 Jun 2004 18:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BbRap-0006GF-HC for disman@megatron.ietf.org; Fri, 18 Jun 2004 18:12:15 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26741 for ; Fri, 18 Jun 2004 18:12:12 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BbRao-0001bd-4a for disman@ietf.org; Fri, 18 Jun 2004 18:12:14 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BbRZv-0001FY-00 for disman@ietf.org; Fri, 18 Jun 2004 18:11:20 -0400 Received: from swan.mail.pas.earthlink.net ([207.217.120.123]) by ietf-mx with esmtp (Exim 4.12) id 1BbRZ6-0000tG-00 for disman@ietf.org; Fri, 18 Jun 2004 18:10:28 -0400 Received: from h-68-164-158-226.snvacaid.dynamic.covad.net ([68.164.158.226] helo=oemcomputer) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BbRZ6-0005DK-00 for disman@ietf.org; Fri, 18 Jun 2004 15:10:28 -0700 Message-ID: <011f01c45581$3276b8c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <2147483647.1087603299@[192.168.1.6]> Subject: Re: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt Date: Fri, 18 Jun 2004 15:11:25 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 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 X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Hi - > From: "Juergen Quittek" > To: "Romascanu, Dan (Dan)" ; "Randy Presuhn" ; > Cc: > Sent: Friday, June 18, 2004 3:01 PM > Subject: RE: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt ... > Please find the list of changes at the end of this message. ... Thanks! Randy From disman-bounces@ietf.org Tue Jun 22 19:11:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08126 for ; Tue, 22 Jun 2004 19:11:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BctnC-0007xu-3T; Tue, 22 Jun 2004 18:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BcqDH-0001MP-2P for disman@megatron.ietf.org; Tue, 22 Jun 2004 14:41:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15305 for ; Tue, 22 Jun 2004 14:41:41 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BcqDF-0003zW-N2 for disman@ietf.org; Tue, 22 Jun 2004 14:41:41 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bcprb-00009M-00 for disman@ietf.org; Tue, 22 Jun 2004 14:19:23 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BcpIE-0001fl-00; Tue, 22 Jun 2004 13:42:46 -0400 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 i5MHg7ZA014805; Tue, 22 Jun 2004 11:42:08 -0600 (MDT) 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: [ipcdn] Re: [Disman] WG last call ondraft-ietf-disman-remops-mib-v2-01.txt Part1 Date: Tue, 22 Jun 2004 11:42:07 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F03E4A8@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] Re: [Disman] WG last call ondraft-ietf-disman-remops-mib-v2-01.txt Part1 Thread-Index: AcRUbbPfcr9wigL1T2eEqq3ygupFVAAU+bHg From: "Eduardo Cardona" To: "Juergen Quittek" , "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.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Cc: ipcdn@ietf.org X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Distributed Management List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: disman-bounces@ietf.org Errors-To: disman-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Thanks Jurgen for adding the Minimal compliance in the new draft Few comments:=20 Draft is not indicating in upper header that is obsoleting RFC 2925=20 DISMAN-PING-MIB Since the objects are carried from a previous RFC, The extra comments I got for objects are not critical, although I went to the exercise of understanding and may worth for direct clarifications to me if I misunderstood them=20 Please pay special attention to the new minimum compliance modules comments (under ****) pingCtlTrapGeneration=20 I see a lot of overlapping in between probeFailures and TestFailures because both are within a ping Test. Making that very punctual for notification stand point One approach (two layers) could be that TestFailure notification is only sent after multiple Test Failures ( based on the Frequency object may indicate reasonable periods of hosts disconnection) so you can avoid getting ProbeFailure notification but use this counter for accumulate Test failures, then collect notifications only for Test failures periods -probeFailure(0) set to '0'. In the other hand setting probeFailure(0) to '1' will get the time details of the probe failures that constitute a Test failure. - also does "sucessive" means consecutive?=20 If Filter is set to 3=20 1)timeout, 2)timeout, 3)reply, 4) timeout, 5) timeout, 6) timeout, 7) reply=20 Means ProbeFailure happen between 4) and 6)=20 I think the testFailure(1) BIT should indicate that a Test Failure is reached by the threshold of pingCtlTrapProbeFailure rather than pingCtlTrapTestFailure. Moreover the definitions of pingCtlTrapGeneration and pingCtlTrapProbeFailureFilter/pingCtlTrapTestFailureFilter are overlapping and probably redundant. A possible wording to illustrate the comment could be: "... For=20 pingCtlTrapGeneration DESCRIPTION "The value of this object determines when and if to generate a notification for this entry: probeFailure(0) - Generate a pingProbeFailed notification subject to the value of pingCtlTrapProbeFailureFilter.=20 testFailure(1) - Generate a pingTestFailed notification. A Test Failure condition is defined if within a test the number of probe failures=20 reaches the value of pingCtlTrapProbeFailureFilter testCompletion(2) - Generate a pingTestCompleted notification. By default, no bits are set, indicating that none of the above options are selected." pingCtlTrapProbeFailureFilter/TestFailureFilter=20 the description of pingCtlTrapProbeFailureFilter is not Clear to me if after the # of probe failures of the ProbeFailureFilter object are reached a notification is sent and if the counter is cleared e.g.=20 pingCtlTrapProbeFailureFilter =3D 5 pingCtlProbeCount =3D 15 Supposed all ping probes timed out, Will it send notification after attempts 5, 10 and 15=20 or=20 After attempts 5,6,7,....15 A possible wording could be ( only sending notifications after attempts 5, 10 and 15:=20 pingCtlTrapProbeFailureFilter "The value of this object is used to determine when to generate a pingProbeFailed NOTIFICATION. Setting pingCtlTrapGeneration BIT probeFailure(0)=20 to '1' implies that a pingProbeFailed NOTIFICATION is generated only when a number of successive ping probes equal to the value of=20 pingCtlTrapPrbefailureFilter fail within a given ping test. Then a Test failure condition is=20 reached and the probe failure count is=20 reset for the following attempts within the=20 given ping test." Similar for pingCtlTrapTestFailureFilter "The value of this object is used to determine when to generate a pingTestFailed NOTIFICATION. Setting pingCtlTrapGeneration BIT testFailure(1) to '1' implies that a pingTestFailed NOTIFICATION is generated only when the number of test failures=20 within a test exceed the value of pingCtlTrapTestFailureFilter." Above is also included a small wording for the BIT sets=20 pingCtlSourceAddressType I believe should have DEFVAL 'unknown' to conform with RFC3291 bis draft 03=20 =20 MinimumCompliance ***************** PingCtlRowStatus has a compliance SYNTAX read-only; some clarifications in how the minimum compliance default entry=20 All time with value 'active' ?=20 Regularly a 'notReady' entry when filled all the minimum object sets becomes 'notInService' and need to be set to 'active' via SNMP to complete the operation a) Will the compliance statement should say that a 'notReady' is automatically set to 'active' when all fields (specially when pingCtlTargetAddress is set?) would that be valid request? -not included in the state diagram of RowStatus TC-=20 Or=20 b) more general the pingCtlAdminStatus should indicate an error when attempting to start (enabled(1) the test and the entry is notReady(2) / notInService(1) ? And probably the MinumimCompliance may need a SYNTAX clause like SYNTAX RowStatus { notReady(3), active(1)} Object Compliances pingCtlFrequency r-o; last sentence "A value zero means... " may not be needed any case, the test is not repeated and 0 value already defined In the object description Normalization of SYNTAX sub-typing as in other objects. -- Just a comment Up to MIB doctor for style normalization in the compliances.. pingCtlStorateType can have a SYNTAX clause=20 SYNTAX StorageType { volatile(2)} >From RFC 2925 the Compliance statement has under pingGroup the objects of Ctl, Results, History and the Notification Group Since the minimal compliance has only Ctl, Results objects I think is better to define a MANDATORY-GROUP pingMinGroup including Ctl and Results Objects. So the original group is left intact (unless specific compliances are needed as pingComplianceV2 (if there are important differences with the original Compliance) - Will be ok with MIB doctor perception of this compliances ramifications DISMAN-TRACEROUTE-MIB MinumumCompliance ***************** Same as ping Compliances From RFC 2925 and new draft the=20 traceRouteGroup has originally Ctl, Results and Probehistory Objects. The minimal compliance will just have a traceReouteMinimumGroup with Ctl and Results objects and leave the original group (fully compliant) intact. Same comments for traceRouteCtlFrequency and traceRouteCtlStorageType as for the PING minimum compliance. DISMAN-NSLOOKUP-MIB No issues. Thanks Eduardo -----Original Message----- From: Juergen Quittek [mailto:quittek@ccrle.nec.de]=20 Sent: Wednesday, June 16, 2004 3:47 PM To: Randy Presuhn; disman@ietf.org Cc: ipcdn@ietf.org Subject: [ipcdn] Re: [Disman] WG last call ondraft-ietf-disman-remops-mib-v2-01.txt Dear all, I just posted a new version of the remote operation MIB modules. Following Eduardo's suggestion I added Minimum Compliancy statements in addition to the existing full compliancy statements to each of the three MIB modules. I also had to (syntactically) modify the existing compliancy statements. Please have a close look at all six MODULE-COMPLIANCE macros. Until the document becomes available at the I-D repository, you can preview it at ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-disman-remops-mib- v2-02.txt There was not much response on my questions on how to define the minimum compliance statements. I preferred leaving read-only objects in place to creating non-consecutive numbering of objects in table entries. I am not dogmatic about this and suggestions for changes are very welcome. For simplifying the review here is a list of objects and groups for which the full and minimum compliance statements differ: pingHistoryGroup, pingNotificationsGroup pingCtlDataFill pingCtlFrequency pingCtlMaxRows pingCtlTrapGeneration pingCtlProbeFailureFilter pingCtlTestFailureFilter pingCtlDescr pingCtlByPassRouteTable pingProbeHistoryTime traceRouteHistoryGroup traceRouteCtlByPassRouteTable traceRouteCtlDontFragment traceRouteCtlInitialTtl traceRouteCtlFrequency traceRouteCtlDescr traceRouteCtlMaxRows traceRouteCtlTrapGeneration traceRouteCtlCreateHopsEntries traceRouteCtlRowStatus traceRouteHopsLastGoodProbe lookupCtlRowStatus Beyond the compliance statement I just made two changes to the document: 1. Added new section 3.4 introducing the compliance statement 2. Extended DESCRIPTION clause of object lookupPurgeTime by one sentence: "A value of 0 indicates that automatic deletion of entries is disabled." Thanks, Juergen --=20 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 --On 29.04.2004 14:29 h -0700 Randy Presuhn wrote: > Hi - > > Are there any objections to proceding as Juergen and Eduardo suggest?=20 > I'd like to see comment (pro or contra) on the specific questions=20 > Juergen raised below. > > Randy, disman WG chair > >> From: "Juergen Quittek" >> To: "Eduardo Cardona" ; "Randy Presuhn"=20 >> ; >> Cc: "Ipcdn List (E-mail)" >> Sent: Monday, April 26, 2004 1:11 AM >> Subject: RE: [Disman] WG last call on=20 >> draft-ietf-disman-remops-mib-v2-01.txt >> > >> Eduardo, >> >> Thank you for raising this issue and my apologies for this very late=20 >> reply. >> >> I ran into similar problems several times where a well designed=20 >> technology was too mighty or too general for being implemented at=20 >> small devices. >> >> Your suggestions aim at introducing additional MODULE-COMPLIANCE=20 >> clauses to the PING-MIB, the TRACEROUTE-MIB and LOOKUP-MIB modules=20 >> for allowing simpler implementations with smaller footprints. >> >> I support your proposal, but have a few comments, see below. I am=20 >> willing to make suggestions for minimalCompliance clauses for the MIB >> modules, but first the WG should agree on two issues: >> >> - Is it agreed to add such clauses, that definitely require >> less funtionality to be implemented? >> >> - what is the preferred procedure for columnar objects that >> are not required for minimal compliancy? We can either >> allow them to be missing completely. But this would result >> in non-consecutive numbering of the remaining objects in >> the minimal tables. Or we require them to be implemented >> as read-only indicating that the feature that they would >> serve in full compliancy is not supported. >> >> Please find further comments inline. >> >> 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 >> >> >> --On 02.03.2004 10:04 h -0700 Eduardo Cardona wrote: >> > Randy, >> > >> > Few comments, >> > >> > I review the MIB and appears compelling respect to previous RFC >> > >> > Just one comment >> > >> > >> > (*) traceRouteCtlMiscOptions >> > It appears to me an uncanny object and rather implementations may=20 >> > opt to extend the capabilities in the private branch, could leave=20 >> > with that to avoid deprecation, of if there are field=20 >> > implementations. >> >> Currently, the MODULE-COMPLIANCE clause traceRouteCompliance requests >> implementation of this object, but it may be implemented as read-only >> and returning always a value of zero, if there is not further=20 >> semantics defined for it. Do you suggest to completely remove the=20 >> object or to state in the MODULE-COMPLIANCE clause that it does not=20 >> need to be implemented? >> >> > Regardless of the additions to the MIB I apologize for the late=20 >> > notice, >> > >> > Before sending a complete proposal and get your concept of the best >> > approach, below is the proposal to add a simplified Compliance=20 >> > statement for devices not requiring to keep constant status of=20 >> > PING/TRACEROUTE operations, only remote operation per operator=20 >> > request. >> > >> > >> > We are looking at your comments about the clear overlap in=20 >> > draft-ietf-disman-remops-mib-v2-01.txt >> > With IPCDN draft >> > http://www.ipcdn.org/drafts/draft-ietf-ipcdn-cable-gateway-tools-mi >> > b-00. >> > txt ( currently out of date in IETF drafts site) which is clearly a >> > subset of the DISMAN-PING-MIB >> > 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=20 >> > compliance statement outlined below? >> >> I doubt that it is a good idea to replicate large portions of the=20 >> PING-MIB in the IPCDN cable gateway Tools MIB module, as it is done=20 >> right now. >> >> > 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 >> > TestName) for a manager requested operation of PING/ TRACEROUTE, >> > 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 don't think the remops MIB modules forbid null-named entries in the >> respective tables. But currently the support of a read-write=20 >> pingCtlRowStatus is mandatory. >> >> Is your concrete suggestion to add something like >> >> OBJECT XXRowStatus >> MIN-ACCESS read-only >> DESCRIPTION >> "Implementations may disallow the creation of named=20 >> entries." >> >> with XX=3DpingCtl,traceRouteCtl,lookupCtl? >> >> > In summary A new Compliance Statement for small devices with no=20 >> > monitoring capabilities to : >> > 1) remove the constant pulling and login information >> > 2) remove the test row creation >> > - 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 >> > system. >> > - Create an additional set of Compliance statements to=20 >> > require the new Groups and other objects Compliance >> > requirements MIN-ACCESS clauses mainly >> > >> > Schema of the content of the new Compliance statement: >> > >> > List of objects not to include in basicPingGroup OBJECT-GROUP=20 >> > clause qnd/or hints for OBJECT Compliances: >> > pingMaxConcurrentRequests -- remove >> >> Could also be read-only returning 1. >> >> > pingCtlDataFill -- remove or MIN-ACCESS read-only default >> > value is OK >> > pingCtlFrequency -- remove Only one test >> >> Could also be read-only returning 0. >> >> > pingCtlType -- remove or MIN-ACCESS read-only >> > pingCtlByPassRouteTable -- remove or MIN-ACCESS read-only >> > pingCtlDSField -- MIN-ACCESS read-only >> > pingCtlStorageType -- remove >> > pingCtlRowStatus -- SYNTAX RowStatus (notReady(2) >> > WRITE-SYNTAX RowStatus (active(1), notInService(3) >> >> Why don't you consider removing this object? >> >> > pingCtlIfIndex -- not to include >> > pingProbeHistory* -- not to include. >> > >> > List of objects not to include in basicTraceRouteGroup=20 >> > 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) >> > traceRouteCtlStorageType -- remove >> > traceRouteProbeHistory* -- not to include. >> > >> > List of objects not to include in basicLookupGroup OBJECT-GROUP=20 >> > clause and/or hints for OBJECT Compliances: >> > lookupMaxConcurrentRequests -- remove >> > lookupPurgeTime -- remove >> > lookupCtlRowStatus -- SYNTAX RowStatus (notReady(2) >> > WRITE-SYNTAX RowStatus (active(1), notInService(3) >> > >> > >> > Best Regards >> > >> > Eduardo >> > >> > -----Original Message----- >> > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] >> > Sent: Monday, March 01, 2004 6:44 PM >> > To: disman@ietf.org >> > Subject: RE: [Disman] WG last call on=20 >> > 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=20 >> > adequate review. >> > >> >> We at Cablelabs are interested in adding a simplified compliance=20 >> >> statement for ad-hoc procedure call instead of a user entry=20 >> >> 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=20 >> > 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=20 >> > please make your specific proposal as quickly as you can. My=20 >> > opinion as a technical contributor is that the case for these=20 >> > changes would need to be fairly compelling if they would result in=20 >> > the remote operations MIB cycling at proposed rather than advancing >> > to draft standard. As working group chair, I want to ensure that=20 >> > whatever course we take reflects WG consensus. So, balancing the=20 >> > need for bringing this to a conclusion with the need to ensure that >> > the technical issues are properly considered, I'll entertain=20 >> > discussion of this issue ("ad hoc procedure call") until Friday=20 >> > noon (Korean Time). Shortly thereafter I'll make a call on whether >> > there is consensus to modify the draft regarding this specific=20 >> > proposal. >> > >> > Randy >> > >> > >> > >> >> >> >> >> >> >> >> >> > > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn