From mailman-bounces@ietf.org Thu Jul 1 07:27:55 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 HAA15782 for ; Thu, 1 Jul 2004 07:27:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BfxjV-0004oG-2e for disman-archive@lists.ietf.org; Thu, 01 Jul 2004 05:19:53 -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: Thu, 01 Jul 2004 05:04:57 -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. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* 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 disman-bounces@ietf.org Thu Jul 1 12:34:04 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 MAA15425 for ; Thu, 1 Jul 2004 12:34:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg41b-0007HD-SY; Thu, 01 Jul 2004 12:02:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg3j3-0004xc-3C for disman@megatron.ietf.org; Thu, 01 Jul 2004 11:43: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 LAA12162 for ; Thu, 1 Jul 2004 11:43:47 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bg3j2-0006U0-88 for disman@ietf.org; Thu, 01 Jul 2004 11:43:48 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg3iJ-00064S-00 for disman@ietf.org; Thu, 01 Jul 2004 11:43:03 -0400 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1Bg3hN-0005e9-00; Thu, 01 Jul 2004 11:42:05 -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 i61FeftH025948; Thu, 1 Jul 2004 11:40:41 -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 i61FectH025839; Thu, 1 Jul 2004 11:40:39 -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, 1 Jul 2004 18:41:59 +0300 Message-ID: Thread-Topic: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt Thread-Index: AcRUoQrzrk2YeJA3Ri+90L5skCPcRgK3+QSg 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 I have some concerns with respect to the Security Considerations = section. It is not aligned with the latest guidelines = (http://www.ops.ietf.org/mib-security.html), probably reflecting the = style or the guidelines that were in place by the time RFC 2925 was = published. However, I miss the clarity of the current text, and = especially the enumeration of the security sensitive objects in the MIB = modules, the explicit description of the risks associated with their = mis-configuration or disclosure, and the explicit recommendation to = deploy SNMPv3 and to enable cryptographic security. 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 Jul 1 15:27:57 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 PAA27997 for ; Thu, 1 Jul 2004 15:27: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 1Bg77N-0005d0-Kh; Thu, 01 Jul 2004 15:21:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg6nR-0005M3-Tt for disman@megatron.ietf.org; Thu, 01 Jul 2004 15:00: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 PAA25272 for ; Thu, 1 Jul 2004 15:00:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bg6nQ-0000Sh-O4 for disman@ietf.org; Thu, 01 Jul 2004 15:00:32 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg6mS-000041-00 for disman@ietf.org; Thu, 01 Jul 2004 14:59:32 -0400 Received: from falcon.mail.pas.earthlink.net ([207.217.120.74]) by ietf-mx with esmtp (Exim 4.12) id 1Bg6lW-0007U6-00 for disman@ietf.org; Thu, 01 Jul 2004 14:58:35 -0400 Received: from h-68-164-155-224.snvacaid.dynamic.covad.net ([68.164.155.224] helo=oemcomputer) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1Bg6lW-0005Mi-00 for disman@ietf.org; Thu, 01 Jul 2004 11:58:34 -0700 Message-ID: <004801c45f9d$9843c960$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt Date: Thu, 1 Jul 2004 11:59:53 -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, July 01, 2004 8:41 AM > Subject: RE: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt > > I have some concerns with respect to the Security Considerations section. > It is not aligned with the latest guidelines (http://www.ops.ietf.org/mib-security.html), > probably reflecting the style or the guidelines that were in place by the time > RFC 2925 was published. (As WG chair) Clearly, this must be fixed before we ask our AD to take it to the IESG. Juergen Q.: could you re-spin this before the i-d cutoff? > However, I miss the clarity of the current text, and > especially the enumeration of the security sensitive objects in the MIB modules, > the explicit description of the risks associated with their mis-configuration or > disclosure, and the explicit recommendation to deploy SNMPv3 and to enable > cryptographic security. ... (As technical contributor) I rather like the current text. I'd like to see it retained (except perhaps the first paragraph, which would become redundant) and merged with the additional text required by the boilerplate. Randy From disman-bounces@ietf.org Thu Jul 1 16:05:30 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 QAA29415 for ; Thu, 1 Jul 2004 16:05:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg7WX-0000yb-GA; Thu, 01 Jul 2004 15:47:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bg7OC-0005hZ-WF for disman@megatron.ietf.org; Thu, 01 Jul 2004 15:38: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 PAA28436 for ; Thu, 1 Jul 2004 15:38:30 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bg7OB-0007Ui-80 for disman@ietf.org; Thu, 01 Jul 2004 15:38:31 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bg7NE-00078X-00 for disman@ietf.org; Thu, 01 Jul 2004 15:37:32 -0400 Received: from falcon.mail.pas.earthlink.net ([207.217.120.74]) by ietf-mx with esmtp (Exim 4.12) id 1Bg7Mh-0006mW-00 for disman@ietf.org; Thu, 01 Jul 2004 15:36:59 -0400 Received: from h-68-164-155-224.snvacaid.dynamic.covad.net ([68.164.155.224] helo=oemcomputer) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1Bg7Mh-0007DZ-00 for disman@ietf.org; Thu, 01 Jul 2004 12:36:59 -0700 Message-ID: <00c101c45fa2$f62e8100$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" Date: Thu, 1 Jul 2004 12:38: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 Subject: [Disman] annoying vacation messages 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 must use an annoying "vacation" message, PLEASE have the common sense to configure it to not respond to traffic from IETF mailing lists. YOU KNOW WHO YOU ARE. On the WG chairs list, we've been discussing whether offenders should be automatically dropped from WG mailing lists... Randy disman WG chair disman mailing list admin From disman-bounces@ietf.org Fri Jul 2 04:29: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 EAA14722 for ; Fri, 2 Jul 2004 04:29: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 1BgJIl-0003nP-KJ; Fri, 02 Jul 2004 04:21:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgJ2j-0007nT-E9 for disman@megatron.ietf.org; Fri, 02 Jul 2004 04:05:09 -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 EAA13888 for ; Fri, 2 Jul 2004 04:05:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BgJ2h-0003QU-1Q for disman@ietf.org; Fri, 02 Jul 2004 04:05:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgJ1h-00034o-00 for disman@ietf.org; Fri, 02 Jul 2004 04:04:06 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 1BgJ12-0002Ox-00 for disman@ietf.org; Fri, 02 Jul 2004 04:03:25 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.netlab.nec.de (Postfix) with ESMTP id A7A332C90C; Fri, 2 Jul 2004 10:02:50 +0200 (CEST) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 2656A148DE5; Fri, 2 Jul 2004 10:02:48 +0200 (CEST) Date: Fri, 02 Jul 2004 10:03:06 +0200 From: Juergen Quittek To: Randy Presuhn , disman@ietf.org Subject: Re: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt Message-ID: <2147483647.1088762586@[10.1.1.171]> In-Reply-To: <004801c45f9d$9843c960$7f1afea9@oemcomputer> References: <004801c45f9d$9843c960$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 Rand --On 01.07.2004 11:59 Uhr -0700 Randy Presuhn wrote: > Hi - > >> From: "Romascanu, Dan (Dan)" >> To: "Randy Presuhn" ; >> Cc: >> Sent: Thursday, July 01, 2004 8:41 AM >> Subject: RE: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt >> > >> I have some concerns with respect to the Security Considerations section. >> It is not aligned with the latest guidelines (http://www.ops.ietf.org/mib-security.html), >> probably reflecting the style or the guidelines that were in place by the time >> RFC 2925 was published. > > (As WG chair) Clearly, this must be fixed before we ask our AD to take > it to the IESG. > > Juergen Q.: could you re-spin this before the i-d cutoff? > >> However, I miss the clarity of the current text, and >> especially the enumeration of the security sensitive objects in the MIB modules, >> the explicit description of the risks associated with their mis-configuration or >> disclosure, and the explicit recommendation to deploy SNMPv3 and to enable >> cryptographic security. > ... > > (As technical contributor) I rather like the current text. I'd like to see it retained > (except perhaps the first paragraph, which would become redundant) and > merged with the additional text required by the boilerplate. I will try to satisfy both sides: including the new boilerplate text and listing vulnerable objects as well as keeping all but the first paragraphs of the current version. Juergen > Randy > > > From disman-bounces@ietf.org Fri Jul 2 08:19:31 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 IAA01528 for ; Fri, 2 Jul 2004 08:19:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgMuR-0003Bp-IL; Fri, 02 Jul 2004 08:12:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BgMjF-00076u-Du for disman@megatron.ietf.org; Fri, 02 Jul 2004 08:01:17 -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 IAA00340 for ; Fri, 2 Jul 2004 08:01: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 1BgMjE-00020v-Tt for disman@ietf.org; Fri, 02 Jul 2004 08:01:17 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BgMiD-0001eb-00 for disman@ietf.org; Fri, 02 Jul 2004 08:00:13 -0400 Received: from tokyo.netlab.nec.de ([195.37.70.2]) by ietf-mx with esmtp (Exim 4.12) id 1BgMhE-00010T-00 for disman@ietf.org; Fri, 02 Jul 2004 07:59:12 -0400 Received: from venus.office (venus.office [10.1.1.11]) by tokyo.netlab.nec.de (Postfix) with ESMTP id A49C42C90C; Fri, 2 Jul 2004 13:58:41 +0200 (CEST) Received: from [10.1.1.171] (n-quittek.office [10.1.1.171]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 6807A139D42; Fri, 2 Jul 2004 13:58:36 +0200 (CEST) Date: Fri, 02 Jul 2004 13:58:55 +0200 From: Juergen Quittek To: Randy Presuhn , disman@ietf.org Subject: Re: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt Message-ID: <2147483647.1088776734@[10.1.1.171]> In-Reply-To: <004801c45f9d$9843c960$7f1afea9@oemcomputer> References: <004801c45f9d$9843c960$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 Randy, Sorry, my last email slipped out of my mail editor while I was typing with a wrong keyboard driver. --On 01.07.2004 11:59 h -0700 Randy Presuhn wrote: > Hi - > >> From: "Romascanu, Dan (Dan)" >> To: "Randy Presuhn" ; >> Cc: >> Sent: Thursday, July 01, 2004 8:41 AM >> Subject: RE: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt >> > >> I have some concerns with respect to the Security Considerations section. >> It is not aligned with the latest guidelines (http://www.ops.ietf.org/mib-security.html), >> probably reflecting the style or the guidelines that were in place by the time >> RFC 2925 was published. > > (As WG chair) Clearly, this must be fixed before we ask our AD to take > it to the IESG. > > Juergen Q.: could you re-spin this before the i-d cutoff? Yes. I am currently working on the issues raised by Eduardo. Fixing the security consideration should not be a big problem. >> However, I miss the clarity of the current text, and >> especially the enumeration of the security sensitive objects in the MIB modules, >> the explicit description of the risks associated with their mis-configuration or >> disclosure, and the explicit recommendation to deploy SNMPv3 and to enable >> cryptographic security. > ... > > (As technical contributor) I rather like the current text. I'd like to see it retained > (except perhaps the first paragraph, which would become redundant) and > merged with the additional text required by the boilerplate. I will try to satisfy both sides: including the new boilerplate text and listing vulnerable objects as well as keeping all but the first paragraphs of the current version. Thanks, Juergen > Randy > > > From disman-bounces@ietf.org Mon Jul 5 06:21:43 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 GAA18669 for ; Mon, 5 Jul 2004 06:21:43 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhQMO-0003DY-GS; Mon, 05 Jul 2004 06:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhQAB-0002CT-D8 for disman@megatron.ietf.org; Mon, 05 Jul 2004 05:53: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 FAA17331 for ; Mon, 5 Jul 2004 05:53: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 1BhQA3-0000q1-An for disman@ietf.org; Mon, 05 Jul 2004 05:53:19 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhQ96-0000Xx-00 for disman@ietf.org; Mon, 05 Jul 2004 05:52:22 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx with esmtp (Exim 4.12) id 1BhQ8G-0007ll-00; Mon, 05 Jul 2004 05:51:28 -0400 Received: from [10.1.1.171] (marseille.netlab.nec.de [195.37.70.15]) by kyoto.netlab.nec.de (Postfix) with ESMTP id A77271BAC4D; Mon, 5 Jul 2004 11:50:55 +0200 (CEST) Date: Mon, 05 Jul 2004 11:51:18 +0200 From: Juergen Quittek To: Eduardo Cardona , Randy Presuhn , disman@ietf.org Subject: RE: [ipcdn] Re: [Disman] WG last call ondraft-ietf-disman-remops-mib-v2-01.txt Part1 Message-ID: <2147483647.1089028278@[10.1.1.171]> 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 Eduardo, Many thanks for your comments. Please find some replies inline. --On 22.06.2004 11:42 Uhr -0600 Eduardo Cardona wrote: > Thanks Jurgen for adding the Minimal compliance in the new draft > > Few comments: > > Draft is not indicating in upper header that is obsoleting RFC 2925 I think the RFC editor will take care of this issue. I did not dare yet using an "Obsoletes:" entry in the header while having an "Expires:" entry in the line below :-) > 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 > > Please pay special attention to the new minimum compliance modules > comments (under ****) > > > pingCtlTrapGeneration > 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 Exactly this is the case, see pingCtlTrapTestFailureFilter. Or did I get something wrong? > ( 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. I don't really get this. We have a counter for probe failures and a counter for test failures. Both can be switched on and off independently by setting the corresponding bits in pingCtlTrapGeneration. > - also does "sucessive" means consecutive? Let's replace "sucessive" by "consecutive". Any objection from native English speakers? > If Filter is set to 3 > 1)timeout, 2)timeout, 3)reply, 4) timeout, 5) timeout, 6) timeout, 7) > reply > Means ProbeFailure happen between 4) and 6) As far as I understand the current DESCRIPTION clause, the notification is triggered by 6). > 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. The bit testFailure(1) does not indicate that any failure happened, it indicates that generation of notification in such a case is enabled. As far as I understood the descriptions so far, a test is failed only if all probes failed. I must admit that this is not explicitly specified. Any comment from an implementer? > A possible wording to illustrate the comment could be: > "... > For > 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. > testFailure(1) - Generate a pingTestFailed > notification. A Test Failure condition is defined > if within a test the number of probe failures > 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 > 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. > pingCtlTrapProbeFailureFilter = 5 > pingCtlProbeCount = 15 > Supposed all ping probes timed out, > Will it send notification after attempts 5, 10 and 15 > or > After attempts 5,6,7,....15 > A possible wording could be ( only sending notifications after attempts > 5, 10 and 15: You are right. This case is not well specified. > pingCtlTrapProbeFailureFilter > "The value of this object is used to determine when > to generate a pingProbeFailed NOTIFICATION. > > Setting pingCtlTrapGeneration BIT probeFailure(0) > to '1' implies that a pingProbeFailed I think we can omit "to '1'". > NOTIFICATION is generated only when a number of > successive ping probes equal to the value of > pingCtlTrapPrbefailureFilter fail within > a given ping test. Then a Test failure condition is > reached and the probe failure count is > reset for the following attempts within the > given ping test." I disagree with the first part of the last sentence "Then a Test failure condition is reached", but I agree to the rest. > 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 > within a test exceed the value of > pingCtlTrapTestFailureFilter." He also need to add a statement on reseeting the test failure counter when the notification is sent. > Above is also included a small wording for the BIT sets > > pingCtlSourceAddressType I believe should have DEFVAL 'unknown' to > conform with RFC3291 bis draft 03 Fine with me. Any objections from the "Who needs IPv6?" community? > > MinimumCompliance > ***************** > > PingCtlRowStatus has a compliance SYNTAX read-only; some clarifications > in how the minimum compliance default entry > All time with value 'active' ? > 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 In read-only mode it has three possible values: - 'notReady' as long as pingCtlTargetAddress is not specified. - 'notInService' starting when pingCtlTargetAddress specified until pingCtlAdminStatus is set to enabled(1). - 'active' after pingCtlAdminStatus has been set to enabled(1) in state 'notInService'. - again 'notInService' after pingCtlAdminStatus has been set to disabled(1) in stat 'active'. > a) Will the compliance statement should say that a 'notReady' is > automatically set to 'active' when all fields (specially when > pingCtlTargetAddress is set?) No, it will automatically be set to 'notInService'. > would that be valid request? -not included > in the state diagram of RowStatus TC- >From 'notInService', transitions to 'active' can only be reached by setting pingCtlAdminStatus. (as specified in the DESCRIPTION clause of pingCtlRowStatus). Note, that setting pingCtlTargetAddress and pingCtlAdminStatus should still be possible with just a single SNMP PDU. > Or > 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 Yes, this is missing. > SYNTAX RowStatus { notReady(3), active(1)} It should look like SYNTAX RowStatus { active(1), notInService(2), notReady(3)} Probably it would be a good idea to explain the state transitions (as described above) in the corresponding DESCRIPTION clause. > 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 I agree that the sentence is redundant. I thought it would help understanding the compliancy more quickly, but I have no strong feeling about keeping or removing the sentence. Any further opinions? > 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 > SYNTAX StorageType { volatile(2)} I think this is more strict. I did not intend to exclude. for example, 'permanent' entries. >> 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) What about just renaming the new pingGroup to pingMinimumGroup? > - 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 > 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. OK, however we decide on the PING MIB, I will change the TRACEROUTE MIB analogously. Thanks, Juergen > > DISMAN-NSLOOKUP-MIB > No issues. > > > Thanks > > Eduardo > > > -----Original Message----- > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > 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 > -- > 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-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 >>> > 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 basicPingGroupOBJECT-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 >>> > >>> > >>> > >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> > > > > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > > From disman-bounces@ietf.org Tue Jul 6 01:59: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 BAA09350 for ; Tue, 6 Jul 2004 01:59: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 1BhifZ-0006EA-MA; Tue, 06 Jul 2004 01:39:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhiNi-0004pC-Tq for disman@megatron.ietf.org; Tue, 06 Jul 2004 01:20:38 -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 BAA07906 for ; Tue, 6 Jul 2004 01:20:02 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BhiN7-0006y1-SV for disman@ietf.org; Tue, 06 Jul 2004 01:20:01 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhiM5-0006eE-00 for disman@ietf.org; Tue, 06 Jul 2004 01:18:58 -0400 Received: from avocet.mail.pas.earthlink.net ([207.217.120.50]) by ietf-mx with esmtp (Exim 4.12) id 1BhiL4-00064X-00 for disman@ietf.org; Tue, 06 Jul 2004 01:17:54 -0400 Received: from h-68-164-82-130.snvacaid.dynamic.covad.net ([68.164.82.130] helo=oemcomputer) by avocet.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BhiKz-0000fS-00 for disman@ietf.org; Mon, 05 Jul 2004 22:17:49 -0700 Message-ID: <008201c46318$cace5020$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <2147483647.1089028278@[10.1.1.171]> Subject: Re: [ipcdn] Re: [Disman] WG last callondraft-ietf-disman-remops-mib-v2-01.txt Part1 Date: Mon, 5 Jul 2004 22:19: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 - Technical constributor comments... Please note that I'm NOT cc-ing the ipcdn list. Folks that care about this level of detail should be subscribed to the disman list anyway. > From: "Juergen Quittek" ... > Sent: Monday, July 05, 2004 2:51 AM > Subject: RE: [ipcdn] Re: [Disman] WG last callondraft-ietf-disman-remops-mib-v2-01.txt Part1 ... > > Draft is not indicating in upper header that is obsoleting RFC 2925 > > I think the RFC editor will take care of this issue. I did not dare > yet using an "Obsoletes:" entry in the header while having an "Expires:" > entry in the line below :-) What I have done with documents I've edited has been to use "Will Obsolete" in place of "Obsoletes" in the internet drafts. In any case, this is something to double check for in the AUTH48 period. ... > > - also does "sucessive" means consecutive? > > Let's replace "sucessive" by "consecutive". > Any objection from native English speakers? I'd prefer "consecutive," even though dictionaries may list "successive" and "consecutive" as potential synonyms. ... > > pingCtlTrapProbeFailureFilter > > "The value of this object is used to determine when > > to generate a pingProbeFailed NOTIFICATION. > > > > Setting pingCtlTrapGeneration BIT probeFailure(0) > > to '1' implies that a pingProbeFailed > > I think we can omit "to '1'". I think it would be better to keep the "1". Not everyone assumes that "setting" and attribute implies that the resulting value will be non-zero. Since the document doesn't use the verb "clear", there's no context to alert the reader to a "set/clear" paradigm rather than the "set to value" one. ... > > 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 > > SYNTAX StorageType { volatile(2)} > > I think this is more strict. I did not intend to exclude. for example, > 'permanent' entries. ... It sounds like WRITE-SYNTAX would be more appropriate here. Randy From disman-bounces@ietf.org Tue Jul 6 14:10:08 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 OAA08195 for ; Tue, 6 Jul 2004 14:10:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bhtjr-0001gI-Fy; Tue, 06 Jul 2004 13:28:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BhriV-00081H-DP for disman@megatron.ietf.org; Tue, 06 Jul 2004 11:18: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 LAA22545 for ; Tue, 6 Jul 2004 11:18:35 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BhriP-0006zC-IM for disman@ietf.org; Tue, 06 Jul 2004 11:18:37 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BhrhT-0006gD-00 for disman@ietf.org; Tue, 06 Jul 2004 11:17:40 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx with esmtp (Exim 4.12) id 1Bhrh2-0006Lz-00 for disman@ietf.org; Tue, 06 Jul 2004 11:17:12 -0400 Received: from [10.1.1.171] (marseille.netlab.nec.de [195.37.70.15]) by kyoto.netlab.nec.de (Postfix) with ESMTP id C794E1BAC4D; Tue, 6 Jul 2004 17:16:37 +0200 (CEST) Date: Tue, 06 Jul 2004 17:17:03 +0200 From: Juergen Quittek To: Randy Presuhn , disman@ietf.org Subject: Re: [ipcdn] Re: [Disman] WG last callondraft-ietf-disman-remops-mib-v2-01.txt Part1 Message-ID: <2147483647.1089134223@[10.1.1.171]> In-Reply-To: <008201c46318$cace5020$7f1afea9@oemcomputer> References: <2147483647.1089028278@[10.1.1.171]> <008201c46318$cace5020$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-Mailman-Approved-At: Tue, 06 Jul 2004 13:28:13 -0400 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 Randy, Thanks for the comments. --On 05.07.2004 22:19 h -0700 Randy Presuhn wrote: > Hi - > > Technical constributor comments... > Please note that I'm NOT cc-ing the ipcdn list. > Folks that care about this level of detail should be subscribed > to the disman list anyway. > >> From: "Juergen Quittek" > ... >> Sent: Monday, July 05, 2004 2:51 AM >> Subject: RE: [ipcdn] Re: [Disman] WG last callondraft-ietf-disman-remops-mib-v2-01.txt Part1 > ... >> > Draft is not indicating in upper header that is obsoleting RFC 2925 >> >> I think the RFC editor will take care of this issue. I did not dare >> yet using an "Obsoletes:" entry in the header while having an "Expires:" >> entry in the line below :-) > > What I have done with documents I've edited has been to use > "Will Obsolete" in place of "Obsoletes" in the internet drafts. In any > case, this is something to double check for in the AUTH48 period. Sounds good. I will add a 'Will Obsolete:' header > ... >> > - also does "sucessive" means consecutive? >> >> Let's replace "sucessive" by "consecutive". >> Any objection from native English speakers? > > I'd prefer "consecutive," even though dictionaries may list > "successive" and "consecutive" as potential synonyms. > > ... >> > pingCtlTrapProbeFailureFilter >> > "The value of this object is used to determine when >> > to generate a pingProbeFailed NOTIFICATION. >> > >> > Setting pingCtlTrapGeneration BIT probeFailure(0) >> > to '1' implies that a pingProbeFailed >> >> I think we can omit "to '1'". > > I think it would be better to keep the "1". Not everyone assumes > that "setting" and attribute implies that the resulting value will be > non-zero. Since the document doesn't use the verb "clear", there's > no context to alert the reader to a "set/clear" paradigm rather than > the "set to value" one. Fine. > ... >> > 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 >> > SYNTAX StorageType { volatile(2)} >> >> I think this is more strict. I did not intend to exclude. for example, >> 'permanent' entries. > ... > > It sounds like WRITE-SYNTAX would be more appropriate here. The conformance statement has MIN-ACCESS read-only: OBJECT pingCtlStorageType MIN-ACCESS read-only DESCRIPTION "Write access is not required. It is also allowed for implementations to support only the volatile(2) StorageType enumeration." Thanks, Juergen > Randy > > > From disman-bounces@ietf.org Wed Jul 7 23:58: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 XAA10194 for ; Wed, 7 Jul 2004 23:58: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 1BiOU9-0008I9-W0; Wed, 07 Jul 2004 22:18:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiMqg-0002L5-DC for disman@megatron.ietf.org; Wed, 07 Jul 2004 20:33: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 UAA00411 for ; Wed, 7 Jul 2004 20:33:07 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiMqZ-0003Qu-Nc for disman@ietf.org; Wed, 07 Jul 2004 20:33:07 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiMpZ-000377-00 for disman@ietf.org; Wed, 07 Jul 2004 20:32:06 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx with esmtp (Exim 4.12) id 1BiMoy-0002k1-00 for disman@ietf.org; Wed, 07 Jul 2004 20:31:28 -0400 Received: from dialin-145-254-219-237.arcor-ip.net (dialin-145-254-219-237.arcor-ip.net [145.254.219.237]) by kyoto.netlab.nec.de (Postfix) with ESMTP id CBB2A1BAC4D; Thu, 8 Jul 2004 02:30:46 +0200 (CEST) Date: Thu, 08 Jul 2004 02:31:12 +0200 From: Juergen Quittek To: Juergen Quittek , Randy Presuhn , disman@ietf.org, dromasca@avaya.com Subject: Re: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt Message-ID: <2147483647.1089253871@dialin-145-254-219-237.arcor-ip.net> In-Reply-To: <2147483647.1088776734@[10.1.1.171]> References: <004801c45f9d$9843c960$7f1afea9@oemcomputer> <2147483647.1088776734@[10.1.1.171]> 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=none 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 Dan and Randy, Below please find a new version of the Security Considerations. Please have a look at it and tell me if it covers your concerns. 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 02.07.2004 13:58 h +0200 Juergen Quittek wrote: > Randy, > > Sorry, my last email slipped out of my mail editor > while I was typing with a wrong keyboard driver. > > > --On 01.07.2004 11:59 h -0700 Randy Presuhn wrote: > >> Hi - >> >>> From: "Romascanu, Dan (Dan)" >>> To: "Randy Presuhn" ; >>> Cc: >>> Sent: Thursday, July 01, 2004 8:41 AM >>> Subject: RE: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt >>> >> >>> I have some concerns with respect to the Security Considerations section. >>> It is not aligned with the latest guidelines (http://www.ops.ietf.org/mib-security.html), >>> probably reflecting the style or the guidelines that were in place by the time >>> RFC 2925 was published. >> >> (As WG chair) Clearly, this must be fixed before we ask our AD to take >> it to the IESG. >> >> Juergen Q.: could you re-spin this before the i-d cutoff? > > Yes. I am currently working on the issues raised by Eduardo. > Fixing the security consideration should not be a big problem. > >>> However, I miss the clarity of the current text, and >>> especially the enumeration of the security sensitive objects in the MIB modules, >>> the explicit description of the risks associated with their mis-configuration or >>> disclosure, and the explicit recommendation to deploy SNMPv3 and to enable >>> cryptographic security. >> ... >> >> (As technical contributor) I rather like the current text. I'd like to see it retained >> (except perhaps the first paragraph, which would become redundant) and >> merged with the additional text required by the boilerplate. > > I will try to satisfy both sides: including the new boilerplate text and listing > vulnerable objects as well as keeping all but the first paragraphs of the current > version. > > Thanks, > > Juergen > >> Randy >> 5. Security Considerations There are a number of management objects defined in the three MIB modules with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o pingMaxConcurrentRequests o traceRouteMaxConcurrentRequests o lookupMaxConcurrentRequests The MIB modules limit their maximum numbers of concurrent requests by the values of these objects. Unauthorized access to them may lead to an overload of the managed node and to a disruption of other functions of the managed node. o pingCtlTable o traceRouteCtlTable o lookupCtlTable All objects in entries of these tables (except index objects) have a MAX-ACCESS clause of read-create. Unauthorized access to these objects can disturb the measurements controlled by the tables. Also, the functions offered by the MIB modules can be misused for illegal data retrieval and for attacking other systems by floods of ping probes, traceorute probes or lookup requests, respectively. In general, both the ping and traceroute functions when used excessively are considered a form of system attack. In the case of ping sending a system requests too often can negatively effect its performance or attempting to connect to what is supposed to be an unused port can be very unpredictable. Excessive use of the traceroute capability can like ping negatively affect system performance. In insecure environments it is RECOMMENDED that the MIBs defined within this memo not be supported. o lookupPurgeTime Unauthorized access to this object can lead to results of lookup operations being deleted before they are read by a management system, if the object is set to 0 or small values close to 0. If otherwise, the object is set to very high values, unauthorized access can lead to a high consumption of resources for storing lookup results. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. However, the only information that might be disclosed is the configuration and results of measurements that are performed by implementations of the MIB modules. This information can only be mis-used in conjunction with the mis-use of further information. To facilitate the provisioning of access control by a security administrator using the View-Based Access Control Model (VACM) defined in RFC 3415 [RFC3415] for tables in which multiple users may need to independently create or modify entries, the initial index is used as an "owner index". Such an initial index has a syntax of SnmpAdminString, and can thus be trivially mapped to a securityName or groupName as defined in VACM, in accordance with a security policy. All entries in related tables belonging to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same subidentifiers (except for the "column" subidentifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask "wildcarding" the column subidentifier. More elaborate configurations are possible. The VACM access control mechanism described above provides control. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. From disman-bounces@ietf.org Thu Jul 8 11:05: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 LAA28948 for ; Thu, 8 Jul 2004 11:05: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 1Bia0a-0003Yq-5F; Thu, 08 Jul 2004 10:36:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiZDq-0008Du-LC for disman@megatron.ietf.org; Thu, 08 Jul 2004 09:45: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 JAA21367 for ; Thu, 8 Jul 2004 09:45:51 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiZDl-0006RN-2O for disman@ietf.org; Thu, 08 Jul 2004 09:45:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BiZCf-000661-00 for disman@ietf.org; Thu, 08 Jul 2004 09:44:46 -0400 Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx with esmtp (Exim 4.12) id 1BiZC8-0005l1-00 for disman@ietf.org; Thu, 08 Jul 2004 09:44:12 -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 i68DgktH026994 for ; Thu, 8 Jul 2004 09:42:47 -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 i68DgftH026849 for ; Thu, 8 Jul 2004 09:42:42 -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 WGlast call ondraft-ietf-disman-remops-mib-v2-02.txt Date: Thu, 8 Jul 2004 16:44:04 +0300 Message-ID: Thread-Topic: [Disman] Disman WGlast call ondraft-ietf-disman-remops-mib-v2-02.txt Thread-Index: AcRkocvmxPDYLW9BRwSC8CeyA1YmkgATz85A From: "Romascanu, Dan (Dan)" To: "Juergen Quittek" , "Juergen Quittek" , "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 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 It looks fine with one observation. The phrase: In insecure environments it is RECOMMENDED that the MIBs defined within this memo not be supported. seems intended to apply only for the ping and traceroute MIB, not for = the lookup MIB.=20 In any case, this seems redundant with the generic recommendations that = are part of the security boilerplate which say: It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security.=20 Regards, Dan > -----Original Message----- > From: disman-bounces@ietf.org=20 > [mailto:disman-bounces@ietf.org]On Behalf Of Juergen Quittek > Sent: 08 July, 2004 3:31 AM > To: Juergen Quittek; Randy Presuhn; disman@ietf.org;=20 > Romascanu, Dan (Dan) > Subject: Re: [Disman] Disman WGlast call=20 > ondraft-ietf-disman-remops-mib-v2-02.txt >=20 >=20 > Dan and Randy, >=20 > Below please find a new version of the Security Considerations. > Please have a look at it and tell me if it covers your concerns. >=20 > Thanks, >=20 > Juergen > --=20 > Juergen Quittek quittek@ccrle.nec.de Tel: +49=20 > 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49=20 > 6221 90511-55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany =20 > http://www.ccrle.nec.de >=20 >=20 > --On 02.07.2004 13:58 h +0200 Juergen Quittek wrote: >=20 > > Randy, > > > > Sorry, my last email slipped out of my mail editor > > while I was typing with a wrong keyboard driver. > > > > > > --On 01.07.2004 11:59 h -0700 Randy Presuhn wrote: > > > >> Hi - > >> > >>> From: "Romascanu, Dan (Dan)" > >>> To: "Randy Presuhn" ;=20 > > >>> Cc: > >>> Sent: Thursday, July 01, 2004 8:41 AM > >>> Subject: RE: [Disman] Disman WG last call=20 > ondraft-ietf-disman-remops-mib-v2-02.txt > >>> > >> > >>> I have some concerns with respect to the Security=20 > Considerations section. > >>> It is not aligned with the latest guidelines=20 > (http://www.ops.ietf.org/mib-security.html), > >>> probably reflecting the style or the guidelines that were=20 > in place by the time > >>> RFC 2925 was published. > >> > >> (As WG chair) Clearly, this must be fixed before we ask=20 > our AD to take > >> it to the IESG. > >> > >> Juergen Q.: could you re-spin this before the i-d cutoff? > > > > Yes. I am currently working on the issues raised by Eduardo. > > Fixing the security consideration should not be a big problem. > > > >>> However, I miss the clarity of the current text, and > >>> especially the enumeration of the security sensitive=20 > objects in the MIB modules, > >>> the explicit description of the risks associated with=20 > their mis-configuration or > >>> disclosure, and the explicit recommendation to deploy=20 > SNMPv3 and to enable > >>> cryptographic security. > >> ... > >> > >> (As technical contributor) I rather like the current text.=20 > I'd like to see it retained > >> (except perhaps the first paragraph, which would become=20 > redundant) and > >> merged with the additional text required by the boilerplate. > > > > I will try to satisfy both sides: including the new=20 > boilerplate text and listing > > vulnerable objects as well as keeping all but the first=20 > paragraphs of the current > > version. > > > > Thanks, > > > > Juergen > > > >> Randy > >> >=20 >=20 > 5. Security Considerations >=20 > There are a number of management objects defined in the three MIB > modules with a MAX-ACCESS clause of read-write and/or read-create. > Such objects may be considered sensitive or vulnerable in some > network environments. The support for SET operations in a=20 > non-secure > environment without proper protection can have a negative effect on > network operations. These are the tables and objects and their > sensitivity/vulnerability: >=20 > o pingMaxConcurrentRequests > o traceRouteMaxConcurrentRequests > o lookupMaxConcurrentRequests > The MIB modules limit their maximum numbers of=20 > concurrent requests > by the values of these objects. Unauthorized access to them may > lead to an overload of the managed node and to a disruption of > other functions of the managed node. >=20 > o pingCtlTable > o traceRouteCtlTable > o lookupCtlTable > All objects in entries of these tables (except index=20 > objects) have > a MAX-ACCESS clause of read-create. Unauthorized=20 > access to these > objects can disturb the measurements controlled by the tables. > Also, the functions offered by the MIB modules can be=20 > misused for > illegal data retrieval and for attacking other systems by floods > of ping probes, traceorute probes or lookup requests, > respectively. >=20 > In general, both the ping and traceroute functions when used > excessively are considered a form of system attack. In the case of > ping sending a system requests too often can negatively effect its > performance or attempting to connect to what is supposed to be an > unused port can be very unpredictable. Excessive use of the > traceroute capability can like ping negatively affect system > performance. In insecure environments it is RECOMMENDED that the > MIBs defined within this memo not be supported. >=20 > o lookupPurgeTime > Unauthorized access to this object can lead to results of lookup > operations being deleted before they are read by a management > system, if the object is set to 0 or small values close=20 > to 0. If > otherwise, the object is set to very high values, unauthorized > access can lead to a high consumption of resources for storing > lookup results. >=20 > Some of the readable objects in this MIB module (i.e.,=20 > objects with a > MAX-ACCESS other than not-accessible) may be considered=20 > sensitive or > vulnerable in some network environments. It is thus important to > control even GET and/or NOTIFY access to these objects and possibly >=20 > to even encrypt the values of these objects when sending them over > the network via SNMP. However, the only information that might be > disclosed is the configuration and results of measurements that are > performed by implementations of the MIB modules. This information > can only be mis-used in conjunction with the mis-use of further > information. >=20 > To facilitate the provisioning of access control by a security > administrator using the View-Based Access Control Model (VACM) > defined in RFC 3415 [RFC3415] for tables in which multiple=20 > users may > need to independently create or modify entries, the=20 > initial index is > used as an "owner index". Such an initial index has a syntax of > SnmpAdminString, and can thus be trivially mapped to a securityName > or groupName as defined in VACM, in accordance with a security > policy. >=20 > All entries in related tables belonging to a particular user will > have the same value for this initial index. For a given user's > entries in a particular table, the object identifiers for the > information in these entries will have the same subidentifiers > (except for the "column" subidentifier) up to the end of=20 > the encoded > owner index. To configure VACM to permit access to this portion of > the table, one would create vacmViewTreeFamilyTable=20 > entries with the > value of vacmViewTreeFamilySubtree including the owner=20 > index portion, > and vacmViewTreeFamilyMask "wildcarding" the column subidentifier. > More elaborate configurations are possible. The VACM=20 > access control > mechanism described above provides control. >=20 > SNMP versions prior to SNMPv3 did not include adequate security. > Even if the network itself is secure (for example by using IPSec), > even then, there is no control as to who on the secure network is > allowed to access and GET/SET (read/change/create/delete)=20 > the objects > in this MIB module. >=20 > It is RECOMMENDED that implementers consider the security=20 > features as > provided by the SNMPv3 framework (see [RFC3410], section 8), > including full support for the SNMPv3 cryptographic mechanisms (for > authentication and privacy). >=20 > Further, deployment of SNMP versions prior to SNMPv3 is NOT > RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to > enable cryptographic security. It is then a customer/operator > responsibility to ensure that the SNMP entity giving access to an > instance of this MIB module is properly configured to give=20 > access to > the objects only to those principals (users) that have legitimate > rights to indeed GET or SET (change/create/delete) them. >=20 >=20 >=20 >=20 From disman-bounces@ietf.org Thu Jul 8 17:58:45 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 RAA05077 for ; Thu, 8 Jul 2004 17:58:45 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BifrK-0000SJ-Rb; Thu, 08 Jul 2004 16:51:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bic79-00089w-Po for disman@megatron.ietf.org; Thu, 08 Jul 2004 12:51: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 MAA08753 for ; Thu, 8 Jul 2004 12:50:37 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bic6Z-0002x6-Dd for disman@ietf.org; Thu, 08 Jul 2004 12:50:39 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bic5d-0002YO-00 for disman@ietf.org; Thu, 08 Jul 2004 12:49:42 -0400 Received: from conure.mail.pas.earthlink.net ([207.217.120.54]) by ietf-mx with esmtp (Exim 4.12) id 1Bic4e-000296-00 for disman@ietf.org; Thu, 08 Jul 2004 12:48:40 -0400 Received: from h-68-164-77-145.snvacaid.dynamic.covad.net ([68.164.77.145] helo=oemcomputer) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1Bic4d-0003HW-00 for disman@ietf.org; Thu, 08 Jul 2004 09:48:39 -0700 Message-ID: <009001c4650b$a4d848e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <004801c45f9d$9843c960$7f1afea9@oemcomputer><2147483647.1088776734@[10.1.1.171]> <2147483647.1089253871@dialin-145-254-219-237.arcor-ip.net> Subject: Re: [Disman] Disman WG last call on draft-ietf-disman-remops-mib-v2-02.txt Date: Thu, 8 Jul 2004 09:50:15 -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: "Juergen Quittek" ; "Randy Presuhn" ; ; > Sent: Wednesday, July 07, 2004 5:31 PM > Subject: Re: [Disman] Disman WGlast call ondraft-ietf-disman-remops-mib-v2-02.txt > > Dan and Randy, > > Below please find a new version of the Security Considerations. > Please have a look at it and tell me if it covers your concerns. ... As technical contributor: This looks very good to me. I'm happy. I'll reply to Dan's observations separately. As WG chair: I'll have limited email access until Sunday. I'd like you to proceed as follows in my virtual absence. Since no other issues have surfaced, please submit the updated i-d at your earliest opportunity after coming to agreement on Dan's concerns about whether the lookup MIB should be included in the list of MIBs NOT RECOMMENDED for implementation in insecure environments. In light of the stability and lack of problems reported on this document, there will be a ONE WEEK WG last call, starting when the updated i-d appears. If anyone *committed* to reviewing the document needs additional time, please contact me and we'll work something out. Randy From disman-bounces@ietf.org Thu Jul 8 18:00:27 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 SAA05261 for ; Thu, 8 Jul 2004 18:00:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bifru-0000dJ-GK; Thu, 08 Jul 2004 16:51:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BicEG-0000Go-Bq for disman@megatron.ietf.org; Thu, 08 Jul 2004 12:58:36 -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 MAA09241 for ; Thu, 8 Jul 2004 12:57:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BicDg-0005iQ-50 for disman@ietf.org; Thu, 08 Jul 2004 12:58:00 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BicCc-0005KP-00 for disman@ietf.org; Thu, 08 Jul 2004 12:56:54 -0400 Received: from conure.mail.pas.earthlink.net ([207.217.120.54]) by ietf-mx with esmtp (Exim 4.12) id 1BicC5-0004wL-00 for disman@ietf.org; Thu, 08 Jul 2004 12:56:21 -0400 Received: from h-68-164-77-145.snvacaid.dynamic.covad.net ([68.164.77.145] helo=oemcomputer) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BicC5-0004hf-00 for disman@ietf.org; Thu, 08 Jul 2004 09:56:21 -0700 Message-ID: <009301c4650c$b7e88b60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Disman] Disman WG last call on draft-ietf-disman-remops-mib-v2-02.txt Date: Thu, 8 Jul 2004 09:57: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.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: "Juergen Quittek" ; "Juergen Quittek" ; "Randy Presuhn" ; > Sent: Thursday, July 08, 2004 6:44 AM > Subject: RE: [Disman] DismanWGlast call ondraft-ietf-disman-remops-mib-v2-02.txt > > It looks fine with one observation. The phrase: > > In insecure environments it is RECOMMENDED that the > MIBs defined within this memo not be supported. > > seems intended to apply only for the ping and traceroute MIB, not for the lookup MIB. (As technical contributor) I disagree. One could use excessive DNS lookups as a form of DoS attack. Consequently, I think the lookup MIB merits the same level of protection as the traceroute MIB. > In any case, this seems redundant with the generic recommendations > that are part of the security boilerplate which say: ... I understand the redundancy in the abstract. However, given these tools' potential for abuse, I think the redundancy is a good thing, and would like to see the recommendation retained. I think it's important that the lookup MIB be given the same level of protection as ping and traceroute. I feel much less strongly about whether the redundacy should be removed. Randy From disman-bounces@ietf.org Fri Jul 9 16:22:33 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 QAA27525 for ; Fri, 9 Jul 2004 16:22:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj1Ua-0006G6-89; Fri, 09 Jul 2004 15:57:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BiyhS-00057j-AN for disman@megatron.ietf.org; Fri, 09 Jul 2004 12:58: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 MAA10799 for ; Fri, 9 Jul 2004 12:58:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BiyhM-0002D9-Cq for disman@ietf.org; Fri, 09 Jul 2004 12:58:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Biygb-0001r1-00 for disman@ietf.org; Fri, 09 Jul 2004 12:57:22 -0400 Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx with esmtp (Exim 4.12) id 1Biyfb-0001QM-00 for disman@ietf.org; Fri, 09 Jul 2004 12:56:19 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i69Go9Dq003530 for ; Fri, 9 Jul 2004 11:50:09 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i69Go7Dq003485 for ; Fri, 9 Jul 2004 11:50:08 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt Date: Fri, 9 Jul 2004 19:56:15 +0300 Message-ID: Thread-Topic: [Disman] Disman WG last call ondraft-ietf-disman-remops-mib-v2-02.txt Thread-Index: AcRlODTMAQwQCdhiQainbJwGEt8PmgAnQ2Zg 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 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, I buy your argument. However, in this case, the text preceding this = recommendation in the paragraph should also detail the threats of the = DNS lookups. Right now it refers only to pings and traceroutes hazards. > In general, both the ping and traceroute functions when used > excessively are considered a form of system attack. In the case of > ping sending a system requests too often can negatively effect its > performance or attempting to connect to what is supposed to be an > unused port can be very unpredictable. Excessive use of the > traceroute capability can like ping negatively affect system > performance. In insecure environments it is RECOMMENDED that the > MIBs defined within this memo not be supported. >=20 Regards, Dan > > >=20 > > It looks fine with one observation. The phrase: > > > > In insecure environments it is RECOMMENDED that the > > MIBs defined within this memo not be supported. > > > > seems intended to apply only for the ping and traceroute=20 > MIB, not for the lookup MIB. >=20 > (As technical contributor) > I disagree. One could use excessive DNS lookups as a form of=20 > DoS attack. > Consequently, I think the lookup MIB merits the same level of=20 > protection as > the traceroute MIB. >=20 > > In any case, this seems redundant with the generic recommendations > > that are part of the security boilerplate which say: > ... >=20 From disman-bounces@ietf.org Fri Jul 9 23:43:14 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 XAA01506 for ; Fri, 9 Jul 2004 23:43:14 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj7c5-0007nS-RQ; Fri, 09 Jul 2004 22:29:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj34Q-0001QE-Ls for disman@megatron.ietf.org; Fri, 09 Jul 2004 17:38: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 RAA02842 for ; Fri, 9 Jul 2004 17:38:06 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bj34K-0000hM-9y for disman@ietf.org; Fri, 09 Jul 2004 17:38:08 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bj33O-0000HT-00 for disman@ietf.org; Fri, 09 Jul 2004 17:37:10 -0400 Received: from adsl-64-165-72-146.dsl.scrm01.pacbell.net ([64.165.72.146] helo=wes.hardakers.net) by ietf-mx with esmtp (Exim 4.12) id 1Bj32N-0007fF-00 for disman@ietf.org; Fri, 09 Jul 2004 17:36:07 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 30F4411EC03; Fri, 9 Jul 2004 14:36:05 -0700 (PDT) To: "Randy Presuhn" Subject: Re: [Disman] Event MIB Implementation Survey References: <00b601c41b44$1c123d60$7f1afea9@oemcomputer> From: Wes Hardaker Organization: Sparta Date: Fri, 09 Jul 2004 14:36:05 -0700 In-Reply-To: <00b601c41b44$1c123d60$7f1afea9@oemcomputer> (Randy Presuhn's message of "Mon, 5 Apr 2004 12:28:01 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.5 (chayote, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 >>>>> On Mon, 5 Apr 2004 12:28:01 -0700, "Randy Presuhn" said: Randy> Here is the Implementation Survey for RFC 2981, the Event MIB. And here is a really really late response: Randy> Module: DISMAN-EVENT-MIB Randy> Implemtation Source: Net-SNMP Randy> Management Application / Agent: Agent, plus configuration file tokens to make management easier. It's likely we'll be implementing a gui management interface "sometime". GROUPs: dismanEventResourceGroup (y/n): n dismanEventTriggerGroup (y/n): y dismanEventObjectsGroup (y/n): y dismanEventEventGroup (y/n): y [SET events not yet implemented] dismanEventNotificationObjectGroup (y/n): y dismanEventNotificationGroup (y/n): y OBJECTs: mteTriggerTargetTag (ro/rw): rw [err... but it won't do any good, we only look at self-management. The tag is actually writable, but later on things will break if you set it. Future goals are to make monitoring of other hosts available too, but it's not there now] mteEventSetTargetTag (ro/rw): no mteTriggerValueIDWildcard (ro/rw): rw mteTriggerContextNameWildcard (ro/rw): rw mteObjectsIDWildcard (ro/rw): rw mteEventSetContextNameWildcard (ro/rw): no Randy> Deployment / Operational Experience: I implemented the majority of this on a plane ride a number of years ago (to and from the last DC conference if I recall). There are a number of things that are incomplete in the implementation, such as set events, monitoring of other hosts, etc. We do support writable tables everywhere (though in one case, the tables aren't yet persistent which is sort of problematic ;-). I can't even promise that I remember everything that was and wasn't implemented properly I'm afraid, because the code is rather old (old enough that I'd probably rewrite it at this point if I had to touch it heavily again in order to make use of better APIs that now exist). We also implemented a simple configuration file token wrapper around the MIB tables that is a bit easier to use if you don't want to understand the MIB. EG, monitor -t 60 -u me -o sysUpTime.0 -o hrSWRunName "high process memory" hrSWRunPerfMem > 10000 for example monitors the hrSWRuntable for processes with too much memory every 60 seconds using the security name "me" and adds in the sysUpTime.0 and hrSWRunName objects into the notification that is sent. Similarly, notification events are easily added using a "notificationevent" configuration token (see below for an example). Over all, I think the management structure of the tables works fairly well. Most users don't make use of the actual mib infrastructure (currently), and rely on the above configuration tokens. However, we follow the guidelines of the MIB for actually doing the monitoring and that seems to work quite well. We get a large number of requests asking for how to send traps based on random MIB object monitoring, and we point them to this support and they go away and don't come back. That either means it never works or it always works I guess ;-) On a side note, our agent doesn't have hooks into all the operating systems everywhere for determining when an interface goes up or down, so for a very long time we didn't support the standard ifLinkUp/Down notifications. I recently thought, "you know I could simply configure the event mib to do this for me and it word work on every system". Thus, we now support the notifications in an extremely hacky way: monitor -r 60 -e linkUpTrap "send linkup From disman-bounces@ietf.org Fri Jul 9 23:43:31 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 XAA01528 for ; Fri, 9 Jul 2004 23:43:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj7cp-0008DA-KB; Fri, 09 Jul 2004 22:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj3Ec-0003EY-Um for disman@megatron.ietf.org; Fri, 09 Jul 2004 17:48: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 RAA03946 for ; Fri, 9 Jul 2004 17:48:38 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bj3EW-0003pM-J8 for disman@ietf.org; Fri, 09 Jul 2004 17:48:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bj3Cg-0003Gz-00 for disman@ietf.org; Fri, 09 Jul 2004 17:46:46 -0400 Received: from adsl-64-165-72-146.dsl.scrm01.pacbell.net ([64.165.72.146] helo=wes.hardakers.net) by ietf-mx with esmtp (Exim 4.12) id 1Bj39d-0002Ho-00 for disman@ietf.org; Fri, 09 Jul 2004 17:43:38 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 44BBC11EC03; Fri, 9 Jul 2004 14:43:36 -0700 (PDT) To: "Randy Presuhn" Subject: Re: [Disman] Log MIB Implementation Survey References: <00c101c41b44$40bd7260$7f1afea9@oemcomputer> From: Wes Hardaker Organization: Sparta Date: Fri, 09 Jul 2004 14:43:36 -0700 In-Reply-To: <00c101c41b44$40bd7260$7f1afea9@oemcomputer> (Randy Presuhn's message of "Mon, 5 Apr 2004 12:29:02 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.5 (chayote, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 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 >>>>> On Mon, 5 Apr 2004 12:29:02 -0700, "Randy Presuhn" said: Randy> Here is the Implementation Survey for RFC 3014, the Log MIB. Here is an extremely late... oh you get the point: sorry. Module: NOTIFICATION-LOG-MIB Implementation Source: Net-SNMP Management Application / Agent: subagent in the management station notificationLogConfigGroup (y/n): n notificationLogStatsGroup (y/n): y notificationLogLogGroup (y/n): y notificationLogDateGroup (y/n): y OBJECTs: nlmConfigGlobalEntryLimit (rw/ro): rw lower bound: 0 upper bound: by memory nlmConfigLogEntryLimit (rw/ro): no lower bound: ________ upper bound: ________ nlmConfigLogEntryStatus: (rw/ro): no Randy> Deployment / Operational Experience: I actually implemented this on our receiver side a while ago (to test a new automatic-storage API mechanism actually, but thats besides the point). Thus, the log reports only things that were actually received by the demon and are reported to the agent running on the management station through a agentx connection between the notification receiver and the agent. We don't support anything but the default log group and no configuration. I don't know if anyone is actually using the results of the days work I did in throwing it together. That being said, it is highly likely that we'll be implementing it in the agent in the near future since a fairly large number of clients are suddenly going to need support for it on the agent side. -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett From disman-bounces@ietf.org Fri Jul 9 23:47: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 XAA01904 for ; Fri, 9 Jul 2004 23:47:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj7gk-000513-M1; Fri, 09 Jul 2004 22:34:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bj554-0006UO-Oy for disman@megatron.ietf.org; Fri, 09 Jul 2004 19:47: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 TAA13884 for ; Fri, 9 Jul 2004 19:46: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 1Bj54y-0000yG-88 for disman@ietf.org; Fri, 09 Jul 2004 19:46:56 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bj54B-0000ef-00 for disman@ietf.org; Fri, 09 Jul 2004 19:46:10 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1Bj53T-0000H7-00; Fri, 09 Jul 2004 19:45:23 -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 i69Nimbw014400; Fri, 9 Jul 2004 17:44:49 -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 callondraft-ietf-disman-remops-mib-v2-01.txt Part1 Date: Fri, 9 Jul 2004 17:44:48 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F03E592@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] Re: [Disman] WG last callondraft-ietf-disman-remops-mib-v2-01.txt Part1 Thread-Index: AcRirwV22L3ge7KCR5athhHXaMl7ygCSd3Yw 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.0 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 Juergen,=20 Thanks for the detail responses, Please find some extra comments inline Thanks Eduardo -----Original Message----- From: Juergen Quittek [mailto:quittek@ccrle.nec.de]=20 Sent: Monday, July 05, 2004 3:51 AM To: Eduardo Cardona; Randy Presuhn; disman@ietf.org Cc: ipcdn@ietf.org Subject: RE: [ipcdn] Re: [Disman] WG last callondraft-ietf-disman-remops-mib-v2-01.txt Part1 Eduardo, Many thanks for your comments. Please find some replies inline. --On 22.06.2004 11:42 Uhr -0600 Eduardo Cardona wrote: > Thanks Jurgen for adding the Minimal compliance in the new draft > > Few comments: > > Draft is not indicating in upper header that is obsoleting RFC 2925 I think the RFC editor will take care of this issue. I did not dare yet using an "Obsoletes:" entry in the header while having an "Expires:" entry in the line below :-) - OK=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=20 > misunderstood them > > Please pay special attention to the new minimum compliance modules > comments (under ****) > > > pingCtlTrapGeneration > I see a lot of overlapping in between probeFailures and TestFailures > because both are within a ping Test. Making that very punctual for=20 > notification stand point > > One approach (two layers) could be that TestFailure notification is > only sent after multiple Test Failures Exactly this is the case, see pingCtlTrapTestFailureFilter. Or did I get something wrong? - See next comment > ( 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=20 > Test failures, then collect notifications only for Test failures=20 > 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. I don't really get this. We have a counter for probe failures and a counter for test failures. Both can be switched on and off independently by setting the corresponding bits in pingCtlTrapGeneration. - I agree that this should be the intention; probably some terms are not used exactly pingCtlTrapTestFailureFilter says=20 "...a pingTestFailed NOTIFICATION is generated only when the number of ping failures within a test exceed the value of pingCtlTrapTestFailureFilter." pingCtlFrequency says: "... A value of 0 for this object implies that the test as defined by the corresponding entry will not be repeated." "within a test" above seems to be associated to a "test" (a set of ping probes) not a consecutive number of tests as per CtlFrequency > 0 will imply Another variant will be that instead of saying ProbeFailures =3D 3 TestFailures =3D 4=20 Japanesse notation: O ok X fail ( with your assumption below that all probes in test means failure ? ) Test 1: probe1: O, probe2: X, probe3: X Test 2: probe1: X, -> TestFailure NOTIFICATION Test1: O Test2: X Test3: X Test4: X Test5: X -> TestFailure NOTIFICATION I think will be more interested if consecutive N Test Failed: It also remove the otherwise required constrain that TestFailure > probeFailure "...a pingTestFailed NOTIFICATION is generated only when a number of consecutive=20 test failures exceed the value of pingCtlTrapTestFailureFilter. After a NOTIFICATION is generated the test failure counter is reinitialized." - it is an internal implicit counter with no MIB representation, which I think is ok The third alternative is=20 # probes per test is very long and all TestFailure and ping Probes are within a particular test. Which I think Does not scale well for time intervals flexibility (test vs test frequency). / different sort of SLA needs. But if that is the case the definitions are ok but with the hiden constrain that TestFailure > Ping Probe (within a test) =20 =20 > - also does "sucessive" means consecutive? Let's replace "sucessive" by "consecutive". Any objection from native English speakers? > If Filter is set to 3 > 1)timeout, 2)timeout, 3)reply, 4) timeout, 5) timeout, 6) timeout, 7) > reply Means ProbeFailure happen between 4) and 6) As far as I understand the current DESCRIPTION clause, the notification is triggered by 6). > I think the testFailure(1) BIT should indicate that a Test Failure is > reached by the threshold of pingCtlTrapProbeFailure rather than=20 > pingCtlTrapTestFailure. Moreover the definitions of=20 > pingCtlTrapGeneration and=20 > pingCtlTrapProbeFailureFilter/pingCtlTrapTestFailureFilter are=20 > overlapping and probably redundant. The bit testFailure(1) does not indicate that any failure happened, it indicates that generation of notification in such a case is enabled. As far as I understood the descriptions so far, a test is failed only if all probes failed. I must admit that this is not explicitly specified. Any comment from an implementer? > A possible wording to illustrate the comment could be: > "... > For > 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. > testFailure(1) - Generate a pingTestFailed > notification. A Test Failure condition is defined > if within a test the number of probe failures > 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 > the description of pingCtlTrapProbeFailureFilter is not Clear to me > if after the # of probe failures of the ProbeFailureFilter object are=20 > reached a notification is sent and if the counter is cleared > > e.g. > pingCtlTrapProbeFailureFilter =3D 5 > pingCtlProbeCount =3D 15 > Supposed all ping probes timed out, > Will it send notification after attempts 5, 10 and 15 > or > After attempts 5,6,7,....15 > A possible wording could be ( only sending notifications after > attempts 5, 10 and 15: You are right. This case is not well specified. > pingCtlTrapProbeFailureFilter > "The value of this object is used to determine when > to generate a pingProbeFailed NOTIFICATION. > > Setting pingCtlTrapGeneration BIT probeFailure(0) > to '1' implies that a pingProbeFailed I think we can omit "to '1'". - but what it mean setting BIT probeFailure(0) setting to '1' or setting to '0'? Both values are valid so I do not see that setting BITs means to UP, ON or '1' eventually I missed that from SMI but I have been see other MIB MODULES defining setting=20 BIT X to '1' or '0' =20 > NOTIFICATION is generated only when a number of > successive ping probes equal to the value of > pingCtlTrapPrbefailureFilter fail within > a given ping test. Then a Test failure condition is > reached and the probe failure count is > reset for the following attempts within the > given ping test." I disagree with the first part of the last sentence "Then a Test failure condition is reached", but I agree to the rest. - Ok, aligned with my other clarifications proposed above > 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 > within a test exceed the value of > pingCtlTrapTestFailureFilter." He also need to add a statement on reseeting the test failure counter when the notification is sent. - as proposed above .... But still unsure if the intention is to keep this "within a test" as commented above (alternative 3) "...a pingTestFailed NOTIFICATION is generated only when a number of consecutive=20 test failures exceed the value of pingCtlTrapTestFailureFilter. After a NOTIFICATION is generated the test failure counter is reinitialized." - See the proposed=20 > Above is also included a small wording for the BIT sets > > pingCtlSourceAddressType I believe should have DEFVAL 'unknown' to > conform with RFC3291 bis draft 03 Fine with me. Any objections from the "Who needs IPv6?" community? > > MinimumCompliance > ***************** > > PingCtlRowStatus has a compliance SYNTAX read-only; some > clarifications in how the minimum compliance default entry All time=20 > with value 'active' ? Regularly a 'notReady' entry when filled all the > minimum object sets becomes 'notInService' and need to be set to=20 > 'active' via SNMP to complete the operation In read-only mode it has three possible values: - 'notReady' as long as pingCtlTargetAddress is not specified. - 'notInService' starting when pingCtlTargetAddress specified until pingCtlAdminStatus is set to enabled(1). - 'active' after pingCtlAdminStatus has been set to enabled(1) in state 'notInService'. - again 'notInService' after pingCtlAdminStatus has been set to disabled(1) in stat 'active'. - About=20 "'active' after pingCtlAdminStatus has been set to enabled(1) in state 'notInService'" -I do not think that RowStatus TC can transition automatically from 'notInService' to 'active' >From RowStatus State Diagram=20 >From State C "setting other column to some value" -> C - My view was that because the pre-created entry with zero indexes was already there No need to have to set RowStatus to active afterwards,=20 I see any way the value of RowStatus as an indicator the the test configuration is not ready, Just quite expensive to always have to turn active,=20 > a) Will the compliance statement should say that a 'notReady' is > automatically set to 'active' when all fields (specially when=20 > pingCtlTargetAddress is set?) No, it will automatically be set to 'notInService'. Yes, see above=20 > would that be valid request? -not included > in the state diagram of RowStatus TC- >From 'notInService', transitions to 'active' can only be reached by setting pingCtlAdminStatus. (as specified in the DESCRIPTION clause of pingCtlRowStatus). Note, that setting pingCtlTargetAddress and pingCtlAdminStatus should still be possible with just a single SNMP PDU. > Or > b) more general the pingCtlAdminStatus should indicate an error when > attempting to start (enabled(1) the test and the entry is notReady(2)=20 > / > notInService(1) ? > > And probably the MinumimCompliance may need a SYNTAX clause like Yes, this is missing. > SYNTAX RowStatus { notReady(3), active(1)} It should look like SYNTAX RowStatus { active(1), notInService(2), notReady(3)} Probably it would be a good idea to explain the state transitions (as described above) in the corresponding DESCRIPTION clause. Yes, I agree just verify the RFC 2579 transition from notInService' to active ( I may miss something) > 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=20 > defined In the object description I agree that the sentence is redundant. I thought it would help understanding the compliancy more quickly, but I have no strong feeling about keeping or removing the sentence. Any further opinions? - OK, >From the comment in the security section redundancy is less expensive than ambiguity=20 > Normalization of SYNTAX sub-typing as in other objects. -- Just a > comment Up to MIB doctor for style normalization in the compliances..=20 > pingCtlStorateType can have a SYNTAX clause SYNTAX StorageType {=20 > volatile(2)} I think this is more strict. I did not intend to exclude. for example, 'permanent' entries. - OK, no need for that >> 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=20 > Results Objects. So the original group is left intact (unless specific > compliances are needed as pingComplianceV2 (if there are important=20 > differences with the original Compliance) What about just renaming the new pingGroup to pingMinimumGroup? - OK with me > - 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 > 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. OK, however we decide on the PING MIB, I will change the TRACEROUTE MIB analogously. Thanks, Juergen > > DISMAN-NSLOOKUP-MIB > No issues. > > > Thanks > > Eduardo > > > -----Original Message----- > From: Juergen Quittek [mailto:quittek@ccrle.nec.de] > 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=20 > in addition to the existing full compliancy statements to each of the=20 > three MIB modules. > > I also had to (syntactically) modify the existing compliancy > statements. Please have a close look at all six MODULE-COMPLIANCE=20 > macros. Until the document becomes available at the I-D repository,=20 > 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=20 > in place to creating non-consecutive numbering of objects in table=20 > 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=20 >> 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=20 >>> 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=20 >>> small devices. >>> >>> Your suggestions aim at introducing additional MODULE-COMPLIANCE >>> 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 >>> willing to make suggestions for minimalCompliance clauses for the=20 >>> 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=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 >>> 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 >>> > 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=20 >>> > PING/TRACEROUTE operations, only remote operation per operator=20 >>> > request. >>> > >>> > >>> > We are looking at your comments about the clear overlap in >>> > draft-ietf-disman-remops-mib-v2-01.txt >>> > With IPCDN draft=20 >>> > http://www.ipcdn.org/drafts/draft-ietf-ipcdn-cable-gateway-tools-m >>> > i >>> > 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/msg0081 > 8. >>> > 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=20 >>> 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=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,=20 >>> > NSLOOKUP, mostly for small foot-print devices with no network=20 >>> > monitoring role at the connectivity level as pretended with this=20 >>> > updated RFC. >>> >>> I 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=3DpingCtl,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=20 >>> > 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 basicPingGroupOBJECT-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=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 >>> > 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=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 >>> > the remote operations MIB cycling at proposed rather than=20 >>> > advancing > >>> > to draft standard. As working group chair, I want to ensure that >>> > whatever course we take reflects WG consensus. So, balancing the=20 >>> > need for bringing this to a conclusion with the need to ensure=20 >>> > that > >>> > the technical issues are properly considered, I'll entertain >>> > discussion of this issue ("ad hoc procedure call") until Friday=20 >>> > noon (Korean Time). Shortly thereafter I'll make a call on=20 >>> > whether > >>> > there is consensus to modify the draft regarding this specific >>> > proposal. >>> > >>> > Randy >>> > >>> > >>> > >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >> >> > > > > > > _______________________________________________ > IPCDN mailing list > IPCDN@ietf.org > https://www1.ietf.org/mailman/listinfo/ipcdn > > _______________________________________________ IPCDN mailing list IPCDN@ietf.org https://www1.ietf.org/mailman/listinfo/ipcdn From disman-bounces@ietf.org Mon Jul 12 13:44:25 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 NAA26848 for ; Mon, 12 Jul 2004 13:44:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bk4Y1-0000Zn-AH; Mon, 12 Jul 2004 13:25:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bk4H8-0006NG-Va for disman@megatron.ietf.org; Mon, 12 Jul 2004 13:07:35 -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 NAA24452 for ; Mon, 12 Jul 2004 13:07:31 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Bk4H7-0000oo-Pz for disman@ietf.org; Mon, 12 Jul 2004 13:07:33 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Bk4GF-0000bS-00 for disman@ietf.org; Mon, 12 Jul 2004 13:06:39 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx with esmtp (Exim 4.12) id 1Bk4Fd-0000CK-00 for disman@ietf.org; Mon, 12 Jul 2004 13:06:01 -0400 Received: from dialin-145-254-223-112.arcor-ip.net (dialin-145-254-223-112.arcor-ip.net [145.254.223.112]) by kyoto.netlab.nec.de (Postfix) with ESMTP id B56E01BAC4D; Mon, 12 Jul 2004 19:05:17 +0200 (CEST) Date: Mon, 12 Jul 2004 19:05:46 +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.1089659146@dialin-145-254-223-112.arcor-ip.net> 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=none 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 Dan, Thanks for the comment. I will fix this. Juergen -- Juergen Quittek quittek@netlab.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.netlab.nec.de --On 09.07.2004 19:56 h +0300 Romascanu, Dan (Dan) wrote: > Randy, > > I buy your argument. However, in this case, the text preceding this recommendation in the paragraph should also detail the threats of the DNS lookups. Right now it refers only to pings and traceroutes hazards. > >> In general, both the ping and traceroute functions when used >> excessively are considered a form of system attack. In the case of >> ping sending a system requests too often can negatively effect its >> performance or attempting to connect to what is supposed to be an >> unused port can be very unpredictable. Excessive use of the >> traceroute capability can like ping negatively affect system >> performance. In insecure environments it is RECOMMENDED that the >> MIBs defined within this memo not be supported. >> > > Regards, > > Dan > > > >> > >> >> > It looks fine with one observation. The phrase: >> > >> > In insecure environments it is RECOMMENDED that the >> > MIBs defined within this memo not be supported. >> > >> > seems intended to apply only for the ping and traceroute >> MIB, not for the lookup MIB. >> >> (As technical contributor) >> I disagree. One could use excessive DNS lookups as a form of >> DoS attack. >> Consequently, I think the lookup MIB merits the same level of >> protection as >> the traceroute MIB. >> >> > In any case, this seems redundant with the generic recommendations >> > that are part of the security boilerplate which say: >> ... >> > From disman-bounces@ietf.org Mon Jul 12 22:16:12 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 WAA15446 for ; Mon, 12 Jul 2004 22:16:12 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkCR7-000281-7W; Mon, 12 Jul 2004 21:50:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkBNr-0005dU-Ih for disman@megatron.ietf.org; Mon, 12 Jul 2004 20:42:59 -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 UAA06822 for ; Mon, 12 Jul 2004 20:42: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 1BkBNl-0006I6-5u for disman@ietf.org; Mon, 12 Jul 2004 20:42:53 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkBMs-00063I-00 for disman@ietf.org; Mon, 12 Jul 2004 20:41:58 -0400 Received: from snipe.mail.pas.earthlink.net ([207.217.120.62]) by ietf-mx with esmtp (Exim 4.12) id 1BkBM7-0005nF-00 for disman@ietf.org; Mon, 12 Jul 2004 20:41:11 -0400 Received: from h-68-164-77-87.snvacaid.dynamic.covad.net ([68.164.77.87] helo=oemcomputer) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BkBM1-0003Ih-00 for disman@ietf.org; Mon, 12 Jul 2004 17:41:05 -0700 Message-ID: <033501c46872$5469d940$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <00b601c41b44$1c123d60$7f1afea9@oemcomputer> Subject: Re: [Disman] Event MIB Implementation Survey Date: Mon, 12 Jul 2004 17:42:52 -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: "Wes Hardaker" > To: "Randy Presuhn" > Cc: "Disman (E-mail)" > Sent: Friday, July 09, 2004 2:36 PM > Subject: Re: [Disman] Event MIB Implementation Survey ... > And here is a really really late response: ... Thanks for the detailed response. It was worth the wait! Are there any more out there? Randy From disman-bounces@ietf.org Mon Jul 12 22:16:26 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 WAA15463 for ; Mon, 12 Jul 2004 22:16:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkCRH-00029j-GB; Mon, 12 Jul 2004 21:50:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkBPo-0005q0-BL for disman@megatron.ietf.org; Mon, 12 Jul 2004 20:45:00 -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 UAA06889 for ; Mon, 12 Jul 2004 20:44:58 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkBPm-0006m5-Q0 for disman@ietf.org; Mon, 12 Jul 2004 20:44:58 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkBOl-0006X2-00 for disman@ietf.org; Mon, 12 Jul 2004 20:43:56 -0400 Received: from snipe.mail.pas.earthlink.net ([207.217.120.62]) by ietf-mx with esmtp (Exim 4.12) id 1BkBOK-0006Im-00 for disman@ietf.org; Mon, 12 Jul 2004 20:43:28 -0400 Received: from h-68-164-77-87.snvacaid.dynamic.covad.net ([68.164.77.87] helo=oemcomputer) by snipe.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BkBOK-0003mp-00 for disman@ietf.org; Mon, 12 Jul 2004 17:43:28 -0700 Message-ID: <034801c46872$a97fc520$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <00c101c41b44$40bd7260$7f1afea9@oemcomputer> Subject: Re: [Disman] Log MIB Implementation Survey Date: Mon, 12 Jul 2004 17:45:14 -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: "Wes Hardaker" > To: "Randy Presuhn" > Cc: "Disman (E-mail)" > Sent: Friday, July 09, 2004 2:43 PM > Subject: Re: [Disman] Log MIB Implementation Survey ... > Here is an extremely late... oh you get the point: sorry. ... Thanks! Are there any others out there? Randy From disman-bounces@ietf.org Tue Jul 13 01:12:19 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 BAA27553 for ; Tue, 13 Jul 2004 01:12:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkFOH-00010B-D5; Tue, 13 Jul 2004 00:59:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkFE3-0006wB-MN for disman@megatron.ietf.org; Tue, 13 Jul 2004 00:49:07 -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 AAA26149 for ; Tue, 13 Jul 2004 00:49:03 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkFE0-000360-Ry for disman@ietf.org; Tue, 13 Jul 2004 00:49:04 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkFD1-0002oz-00 for disman@ietf.org; Tue, 13 Jul 2004 00:48:04 -0400 Received: from shell4.bayarea.net ([209.128.82.1]) by ietf-mx with esmtp (Exim 4.12) id 1BkFC6-0002Y9-00 for disman@ietf.org; Tue, 13 Jul 2004 00:47:06 -0400 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) (authenticated bits=0) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id i6D4l1bN026540; Mon, 12 Jul 2004 21:47:01 -0700 Message-Id: <5.2.0.9.2.20040712213950.0240aec0@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 12 Jul 2004 21:46:58 -0700 To: "Randy Presuhn" , "Disman \(E-mail\)" From: "David T. Perkins" Subject: Re: [Disman] Log MIB Implementation Survey In-Reply-To: <034801c46872$a97fc520$7f1afea9@oemcomputer> References: <00c101c41b44$40bd7260$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 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, The most important issue is how the results areto be interpreted. From my experience at Riverstone and with talking with Ram about the cisco implementation, my interpretation is that the current log MIB is not a good solution for the need that it addresses. It's sort of hard to get excited about developing a replacement, given the low deployment of SNMPv3, and the almost universal model of locating the filtering and access control in element managers instead of in managed devices. At 05:45 PM 7/12/2004 -0700, Randy Presuhn wrote: >Hi - > >> From: "Wes Hardaker" >> To: "Randy Presuhn" >> Cc: "Disman (E-mail)" >> Sent: Friday, July 09, 2004 2:43 PM >> Subject: Re: [Disman] Log MIB Implementation Survey >... >> Here is an extremely late... oh you get the point: sorry. >... > >Thanks! Are there any others out there? > >Randy Regards, /david t. perkins From disman-bounces@ietf.org Tue Jul 13 14:21: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 OAA00754 for ; Tue, 13 Jul 2004 14:21: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 1BkRf4-0001df-OC; Tue, 13 Jul 2004 14:05:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkRY9-0008Do-VA for disman@megatron.ietf.org; Tue, 13 Jul 2004 13:58:41 -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 NAA29195 for ; Tue, 13 Jul 2004 13:58:40 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkRY8-0001gV-Ng for disman@ietf.org; Tue, 13 Jul 2004 13:58:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkRXA-0001M0-00 for disman@ietf.org; Tue, 13 Jul 2004 13:57:41 -0400 Received: from turkey.mail.pas.earthlink.net ([207.217.120.126]) by ietf-mx with esmtp (Exim 4.12) id 1BkRWL-00011h-00 for disman@ietf.org; Tue, 13 Jul 2004 13:56:49 -0400 Received: from h-68-164-78-169.snvacaid.dynamic.covad.net ([68.164.78.169] helo=oemcomputer) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BkRWK-0000ag-00 for disman@ietf.org; Tue, 13 Jul 2004 10:56:48 -0700 Message-ID: <001401c46903$048d3d40$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" References: <00c101c41b44$40bd7260$7f1afea9@oemcomputer> <5.2.0.9.2.20040712213950.0240aec0@127.0.0.1> Subject: Re: [Disman] Log MIB Implementation Survey Date: Tue, 13 Jul 2004 10:58:35 -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: "David T. Perkins" > To: "Randy Presuhn" ; "Disman (E-mail)" > Sent: Monday, July 12, 2004 9:46 PM > Subject: Re: [Disman] Log MIB Implementation Survey ... > The most important issue is how the results areto be interpreted. > From my experience at Riverstone and with talking with > Ram about the cisco implementation, my interpretation is > that the current log MIB is not a good solution for the > need that it addresses. It's sort of hard to get excited > about developing a replacement, given the low deployment > of SNMPv3, and the almost universal model of locating the > filtering and access control in element managers instead > of in managed devices. ... Several IETF meetings you and Ram said that you'd write up the issues that concern you and possible solutions. Any progress? An off-list discussion (especially one that I haven't seen) is of little help to me as WG chair, or to the rest of the WG. Randy From disman-bounces@ietf.org Tue Jul 13 14:23:25 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 OAA01109 for ; Tue, 13 Jul 2004 14:23: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 1BkRhO-0002DL-Er; Tue, 13 Jul 2004 14:08:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BkRd2-0000uL-7n for disman@megatron.ietf.org; Tue, 13 Jul 2004 14:03:44 -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 OAA29566 for ; Tue, 13 Jul 2004 14:03:39 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BkRcy-0003TZ-9I for disman@ietf.org; Tue, 13 Jul 2004 14:03:40 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BkRbw-00038U-00 for disman@ietf.org; Tue, 13 Jul 2004 14:02:36 -0400 Received: from turkey.mail.pas.earthlink.net ([207.217.120.126]) by ietf-mx with esmtp (Exim 4.12) id 1BkRau-0002eb-00 for disman@ietf.org; Tue, 13 Jul 2004 14:01:32 -0400 Received: from h-68-164-78-169.snvacaid.dynamic.covad.net ([68.164.78.169] helo=oemcomputer) by turkey.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BkRau-0001jW-00 for disman@ietf.org; Tue, 13 Jul 2004 11:01:32 -0700 Message-ID: <002701c46903$add74080$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" Date: Tue, 13 Jul 2004 11:03:19 -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] Draft Submissions - Important note about boilerplate 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 can't put it any better than Jean-Francois Mule (ipcdn chair) did: > If you are submitting new or revised Internet Drafts now, please > ensure that the drafts have the correct boilerplate, "status of this > memo" and "copyright notice" sections. > > See details in > the ID guidelines: > http://www.ietf.org/ietf/1id-guidelines.txt > > and the ID checklist: > http://www.ietf.org/ID-Checklist.html > > Otherwise the risk is high that the IETF secretary will reject your > submission. This practice has recently begun being enforced. Randy From disman-bounces@ietf.org Thu Jul 15 18:29:57 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 SAA12311 for ; Thu, 15 Jul 2004 18:29: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 1BlESv-0007OL-2n; Thu, 15 Jul 2004 18:12:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlDFB-0003dB-IW for disman@megatron.ietf.org; Thu, 15 Jul 2004 16:54:17 -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 QAA26717 for ; Thu, 15 Jul 2004 16:54: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 1BlDF9-0006ap-RC for disman@ietf.org; Thu, 15 Jul 2004 16:54:15 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlD4P-0004DP-00 for disman@ietf.org; Thu, 15 Jul 2004 16:43:11 -0400 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx with esmtp (Exim 4.12) id 1BlCtW-0001ku-00 for disman@ietf.org; Thu, 15 Jul 2004 16:31:55 -0400 Received: from [10.1.1.171] (dialin-145-254-216-204.arcor-ip.net [145.254.216.204]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 02B511BAC4D; Thu, 15 Jul 2004 22:31:12 +0200 (CEST) Date: Thu, 15 Jul 2004 22:31:49 +0200 From: Juergen Quittek To: Eduardo Cardona , Randy Presuhn , disman@ietf.org Subject: RE: [ipcdn] Re: [Disman] WG last callondraft-ietf-disman-remops-mib-v2-01.txt Part1 Message-ID: <2147483647.1089930709@dialin-145-254-216-204.arcor-ip.net> In-Reply-To: <5259D0D7419C6149B347837A2E64F46F03E592@srvxchg.cablelabs.com> References: <5259D0D7419C6149B347837A2E64F46F03E592@srvxchg.cablelabs.com> 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=none 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 Eduardo, Please find comments inline. --On 09.07.2004 17:44 h -0600 Eduardo Cardona wrote: >> [...] >> >> pingCtlTrapGeneration >> 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 > > Exactly this is the case, see pingCtlTrapTestFailureFilter. > Or did I get something wrong? > > - See next comment > >> ( 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. > > I don't really get this. We have a counter for probe failures and a > counter for test failures. Both can be switched on and off > independently by setting the corresponding bits in > pingCtlTrapGeneration. > > - I agree that this should be the intention; probably some terms are not > used exactly > pingCtlTrapTestFailureFilter says > "...a pingTestFailed NOTIFICATION is > generated only when the number of ping failures > within a test exceed the value of > pingCtlTrapTestFailureFilter." > > pingCtlFrequency says: > "... > A value of 0 for this object implies that the test > as defined by the corresponding entry will not be > repeated." > > "within a test" above seems to be associated to a "test" (a set of ping > probes) not a consecutive number of tests as per CtlFrequency > 0 will > imply > > Another variant will be that instead of saying > ProbeFailures = 3 > TestFailures = 4 > Japanesse notation: O ok X fail ( with your assumption below that all > probes in test means failure ? ) > Test 1: probe1: O, probe2: X, probe3: X > Test 2: probe1: X, -> TestFailure NOTIFICATION > > Test1: O > Test2: X > Test3: X > Test4: X > Test5: X -> TestFailure NOTIFICATION > > I think will be more interested if consecutive N Test Failed: > It also remove the otherwise required constrain that TestFailure > > probeFailure > > "...a pingTestFailed NOTIFICATION is > generated only when a number of consecutive > test failures exceed the value of > pingCtlTrapTestFailureFilter. After a NOTIFICATION > is generated the test failure counter is reinitialized." > > - it is an internal implicit counter with no MIB representation, which > I think is ok This is the way I understand the current MIB specification. Following your proposal, I suggest to change the text in the DESCRIPTION clause of pingCtlTrapProbeFailureFilter to "... a pingTestFailed NOTIFICATION is generated only when a number of consecutive ping tests equal to the value of pingCtlTrapProbeFailureFilter fail. After triggering the notification the test failure, counter is reset to zero." > The third alternative is ># probes per test is very long and all TestFailure and ping Probes are > within a particular test. Which I think > Does not scale well for time intervals flexibility (test vs test > frequency). / different sort of SLA needs. > But if that is the case the definitions are ok but with the hiden > constrain that TestFailure > Ping Probe (within a test) [...] >> pingCtlTrapProbeFailureFilter >> "The value of this object is used to determine when >> to generate a pingProbeFailed NOTIFICATION. >> >> Setting pingCtlTrapGeneration BIT probeFailure(0) >> to '1' implies that a pingProbeFailed > > I think we can omit "to '1'". > > - but what it mean setting BIT probeFailure(0) setting to '1' or setting > to '0'? > Both values are valid so I do not see that setting BITs means to UP, > ON or '1' > eventually I missed that from SMI but I have been see other MIB > MODULES defining setting > BIT X to '1' or '0' A common terminology when talking about bits is 'set' means assigning the value '1' to the bit, while 'reset' means assigning the value '0' to the bit. But your version avoids misunderstandings, so let's take it. >> NOTIFICATION is generated only when a number of >> successive ping probes equal to the value of >> pingCtlTrapPrbefailureFilter fail within >> a given ping test. Then a Test failure condition is >> reached and the probe failure count is >> reset for the following attempts within the >> given ping test." > > I disagree with the first part of the last sentence "Then a Test failure > condition is reached", but I agree to the rest. > > - Ok, aligned with my other clarifications proposed above Please see my new text suggestion above. >> 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 >> within a test exceed the value of >> pingCtlTrapTestFailureFilter." > > He also need to add a statement on reseeting the test failure counter > when the notification is sent. > > - as proposed above .... But still unsure if the intention is to keep > this "within a test" as commented above (alternative 3) > > "...a pingTestFailed NOTIFICATION is > generated only when a number of consecutive > test failures exceed the value of > pingCtlTrapTestFailureFilter. After a NOTIFICATION > is generated the test failure counter is reinitialized." > > - See the proposed >> Above is also included a small wording for the BIT sets >> >> pingCtlSourceAddressType I believe should have DEFVAL 'unknown' to >> conform with RFC3291 bis draft 03 > > Fine with me. > Any objections from the "Who needs IPv6?" community? > >> >> MinimumCompliance >> ***************** >> >> PingCtlRowStatus has a compliance SYNTAX read-only; some >> clarifications in how the minimum compliance default entry All time >> with value 'active' ? 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 > > In read-only mode it has three possible values: > - 'notReady' as long as pingCtlTargetAddress is not specified. > - 'notInService' starting when pingCtlTargetAddress specified until > pingCtlAdminStatus is set to enabled(1). > - 'active' after pingCtlAdminStatus has been set to enabled(1) > in state 'notInService'. > - again 'notInService' after pingCtlAdminStatus has been set to > disabled(1) > in stat 'active'. > > - About > "'active' after pingCtlAdminStatus has been set to enabled(1) > in state 'notInService'" > > -I do not think that RowStatus TC can transition automatically from > 'notInService' to 'active' You are right. The TC does not allow to do so. Now I do not see anymore a clean way of keeping object pingCtlRowStatus in the minimumCompliance. So, let's go back to your initial suggestion and remove the object from the minimumCompliance. Since this is the last column of the pingCtlTable, removing this object does not create a 'hole' in the consecutive list of columnar objects. The same applies to traceRouteCtlRowStatus. Thanks, Juergen -- Juergen Quittek quittek@netlab.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.netlab.nec.de From disman-bounces@ietf.org Thu Jul 15 22:33:31 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 WAA10845 for ; Thu, 15 Jul 2004 22:33:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlIS6-0002jk-D8; Thu, 15 Jul 2004 22:27:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlIKz-0001C6-Pk for disman@megatron.ietf.org; Thu, 15 Jul 2004 22:20:37 -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 WAA06595 for ; Thu, 15 Jul 2004 22:20:34 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlIKx-00051n-BG for disman@ietf.org; Thu, 15 Jul 2004 22:20:35 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlIK0-0004gk-00 for disman@ietf.org; Thu, 15 Jul 2004 22:19:37 -0400 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx with esmtp (Exim 4.12) id 1BlIJ1-00041o-00 for disman@ietf.org; Thu, 15 Jul 2004 22:18:35 -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 i6G2I3bw004924; Thu, 15 Jul 2004 20:18:03 -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 callondraft-ietf-disman-remops-mib-v2-01.txt Part1 Date: Thu, 15 Jul 2004 20:18:03 -0600 Message-ID: <5259D0D7419C6149B347837A2E64F46F03E5CB@srvxchg.cablelabs.com> Thread-Topic: [ipcdn] Re: [Disman] WG last callondraft-ietf-disman-remops-mib-v2-01.txt Part1 Thread-Index: AcRqqrk0L2B7aoJhQP6ahNW4gIbCPAAL1uDg 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.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable 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 Juergen,=20 I concur with all your comments and proposed actions Thanks Eduardo -----Original Message----- From: Juergen Quittek [mailto:quittek@netlab.nec.de]=20 Sent: Thursday, July 15, 2004 2:32 PM To: Eduardo Cardona; Randy Presuhn; disman@ietf.org Subject: RE: [ipcdn] Re: [Disman] WG last callondraft-ietf-disman-remops-mib-v2-01.txt Part1 Eduardo, Please find comments inline. --On 09.07.2004 17:44 h -0600 Eduardo Cardona wrote: >> [...] >> >> pingCtlTrapGeneration >> I see a lot of overlapping in between probeFailures and TestFailures=20 >> because both are within a ping Test. Making that very punctual for=20 >> notification stand point >> >> One approach (two layers) could be that TestFailure notification is=20 >> only sent after multiple Test Failures > > Exactly this is the case, see pingCtlTrapTestFailureFilter. Or did I=20 > get something wrong? > > - See next comment > >> ( based on the Frequency object may >> indicate reasonable periods of hosts disconnection) so you can avoid=20 >> getting ProbeFailure notification but use this counter for accumulate >> Test failures, then collect notifications only for Test failures=20 >> periods >> -probeFailure(0) set to '0'. In the other hand setting=20 >> probeFailure(0) to '1' will get the time details of the probe=20 >> failures that constitute > a >> Test failure. > > I don't really get this. We have a counter for probe failures and a=20 > counter for test failures. Both can be switched on and off=20 > independently by setting the corresponding bits in=20 > pingCtlTrapGeneration. > > - I agree that this should be the intention; probably some terms are=20 > not used exactly pingCtlTrapTestFailureFilter says > "...a pingTestFailed NOTIFICATION is > generated only when the number of ping failures > within a test exceed the value of > pingCtlTrapTestFailureFilter." > > pingCtlFrequency says: > "... > A value of 0 for this object implies that the test > as defined by the corresponding entry will not be > repeated." > > "within a test" above seems to be associated to a "test" (a set of=20 > ping > probes) not a consecutive number of tests as per CtlFrequency > 0 will > imply > > Another variant will be that instead of saying > ProbeFailures =3D 3 > TestFailures =3D 4 > Japanesse notation: O ok X fail ( with your assumption below that all > probes in test means failure ? ) Test 1: probe1: O, probe2: X, probe3: > X Test 2: probe1: X, -> TestFailure NOTIFICATION > > Test1: O > Test2: X > Test3: X > Test4: X > Test5: X -> TestFailure NOTIFICATION > > I think will be more interested if consecutive N Test Failed: It also > remove the otherwise required constrain that TestFailure >=20 > probeFailure > > "...a pingTestFailed NOTIFICATION is > generated only when a number of consecutive > test failures exceed the value of > pingCtlTrapTestFailureFilter. After a NOTIFICATION > is generated the test failure counter is reinitialized." > > - it is an internal implicit counter with no MIB representation,=20 > which I think is ok This is the way I understand the current MIB specification. Following your proposal, I suggest to change the text in the DESCRIPTION clause of pingCtlTrapProbeFailureFilter to "... a pingTestFailed NOTIFICATION is generated only when a number of consecutive ping tests equal to the value of pingCtlTrapProbeFailureFilter fail. After triggering the notification the test failure, counter is reset to zero." > The third alternative is ># probes per test is very long and all TestFailure and ping Probes are >within a particular test. Which I think Does not scale well for time=20 >intervals flexibility (test vs test frequency). / different sort of=20 >SLA needs. But if that is the case the definitions are ok but with the >hiden constrain that TestFailure > Ping Probe (within a test) [...] >> pingCtlTrapProbeFailureFilter >> "The value of this object is used to determine when >> to generate a pingProbeFailed NOTIFICATION. >> >> Setting pingCtlTrapGeneration BIT probeFailure(0) >> to '1' implies that a pingProbeFailed > > I think we can omit "to '1'". > > - but what it mean setting BIT probeFailure(0) setting to '1' or=20 > setting to '0'? > Both values are valid so I do not see that setting BITs means to UP, > ON or '1' > eventually I missed that from SMI but I have been see other MIB=20 > MODULES defining setting > BIT X to '1' or '0' A common terminology when talking about bits is 'set' means assigning the value '1' to the bit, while 'reset' means assigning the value '0' to the bit. But your version avoids misunderstandings, so let's take it. >> NOTIFICATION is generated only when a number of >> successive ping probes equal to the value of >> pingCtlTrapPrbefailureFilter fail within >> a given ping test. Then a Test failure condition is >> reached and the probe failure count is >> reset for the following attempts within the >> given ping test." > > I disagree with the first part of the last sentence "Then a Test=20 > failure condition is reached", but I agree to the rest. > > - Ok, aligned with my other clarifications proposed above Please see my new text suggestion above. >> 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 >> within a test exceed the value of >> pingCtlTrapTestFailureFilter." > > He also need to add a statement on reseeting the test failure counter=20 > when the notification is sent. > > - as proposed above .... But still unsure if the intention is to keep=20 > this "within a test" as commented above (alternative 3) > > "...a pingTestFailed NOTIFICATION is > generated only when a number of consecutive > test failures exceed the value of > pingCtlTrapTestFailureFilter. After a NOTIFICATION > is generated the test failure counter is reinitialized." > > - See the proposed >> Above is also included a small wording for the BIT sets >> >> pingCtlSourceAddressType I believe should have DEFVAL 'unknown' to=20 >> conform with RFC3291 bis draft 03 > > Fine with me. > Any objections from the "Who needs IPv6?" community? > >> >> MinimumCompliance >> ***************** >> >> PingCtlRowStatus has a compliance SYNTAX read-only; some=20 >> clarifications in how the minimum compliance default entry All time=20 >> with value 'active' ? Regularly a 'notReady' entry when filled all=20 >> the > >> minimum object sets becomes 'notInService' and need to be set to=20 >> 'active' via SNMP to complete the operation > > In read-only mode it has three possible values: > - 'notReady' as long as pingCtlTargetAddress is not specified. > - 'notInService' starting when pingCtlTargetAddress specified until > pingCtlAdminStatus is set to enabled(1). > - 'active' after pingCtlAdminStatus has been set to enabled(1) > in state 'notInService'. > - again 'notInService' after pingCtlAdminStatus has been set to > disabled(1) > in stat 'active'. > > - About > "'active' after pingCtlAdminStatus has been set to enabled(1) > in state 'notInService'" > > -I do not think that RowStatus TC can transition automatically from=20 > 'notInService' to 'active' You are right. The TC does not allow to do so. Now I do not see anymore a clean way of keeping object pingCtlRowStatus in the minimumCompliance. So, let's go back to your initial suggestion and remove the object from the minimumCompliance. Since this is the last column of the pingCtlTable, removing this object does not create a 'hole' in the consecutive list of columnar objects. The same applies to traceRouteCtlRowStatus. Thanks, Juergen --=20 Juergen Quittek quittek@netlab.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.netlab.nec.de From disman-bounces@ietf.org Fri Jul 16 03:18:04 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 DAA10619 for ; Fri, 16 Jul 2004 03:18:04 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlMw2-0007Go-Vh; Fri, 16 Jul 2004 03:15:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BlMts-0006uC-Ou for disman@megatron.ietf.org; Fri, 16 Jul 2004 03:12:56 -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 DAA10443 for ; Fri, 16 Jul 2004 03:12:55 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BlMtq-0001Qu-Ds for disman@ietf.org; Fri, 16 Jul 2004 03:12:54 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BlMsm-000173-00 for disman@ietf.org; Fri, 16 Jul 2004 03:11:49 -0400 Received: from swan.mail.pas.earthlink.net ([207.217.120.123]) by ietf-mx with esmtp (Exim 4.12) id 1BlMsC-0000nM-00 for disman@ietf.org; Fri, 16 Jul 2004 03:11:12 -0400 Received: from h-69-3-91-24.snvacaid.dynamic.covad.net ([69.3.91.24] helo=oemcomputer) by swan.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BlMsC-0000hX-00; Fri, 16 Jul 2004 00:11:12 -0700 Message-ID: <001101c46b04$57669b80$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" Date: Fri, 16 Jul 2004 00:13: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=none autolearn=no version=2.60 Cc: Daniel Chuang Subject: [Disman] Fw: DISMAN REMOPS MIB implementation/deployment report 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 am please to be able to forward Juniper's implementation report for RFC 2925, courtesy of Daniel Chuang. Randy > From: "Daniel Chuang" > To: "Randy Presuhn" > Cc: "Steve Moulton" ; > Sent: Thursday, July 15, 2004 5:18 PM > Subject: Re: DISMAN REMOPS MIB implementation/deployment report > > Go ahead. It is OK to make it public. Please cc me since > I am not in the mailing list. > > thanks, > Daniel > Randy Presuhn wrote: > > >Hi Daniel - > > > >Thanks! May I forward the report to the disman WG mailing > >list, or would you prefer this report to remain anonymous? > > > >Randy > > > >----- Original Message ----- > > > >>From: "Daniel Chuang" > >>To: > >>Cc: "Daniel Chuang" ; "Steve Moulton" ; > >>Sent: Thursday, July 15, 2004 4:14 PM > >>Subject: Re: DISMAN REMOPS MIB implementation/deployment report > >> > > > >>Hi, Randy, > >> > >> I attach the implementation report for rfc 2925 in Juniper. > >>Hopefully it is not too late. > >> > >>thanks, > >>Daniel > >> > >... > > > >> Juniper Implementation report for RFC 2925 > >> > >>================================================= > >> > >>Implementation Survey for RFC 2925, > >>Definitions of Managed Objects for Remote Ping, > >>Traceroute, and Lookup Operations > >> > >> Module: DISMAN-PING-MIB > >> Implementation Source: Internal Implementation > >> Management Application / Agent: > >> It is based on Wind River WindManage v9.3 > >> > >> > >>GROUPs: > >>pingGroup (y/n): y > >>pingNotificationsGroup (y/n): y > >>pingTimeStampGroup (y/n): y > >> > >>OBJECTs: > >>pingMaxConcurrentRequests (rw/ro): rw > >>pingCtlStorageType (rw/ro): rw (volatile only) > >>pingCtlType (rw/ro): rw (pingIcmpEcho, pingUdpEcho, pingTcpConnectionAttempt) > >>pingCtlByPassRouteTable (rw/ro): rw > >>pingCtlSourceAddressType (rw/ro): rw > >> unknown (y/n): y > >> ipv4 (y/n): y > >> ipv6 (y/n): n > >> > >>pingCtlSourceAddress (rw/ro): rw > >>pingCtlIfIndex (rw/ro): rw > >>pingCtlDSField (rw/ro): rw > >>pingResultsIpTargetAddressType: > >> unknown (y/n): y > >> ipv4 (y/n): y > >> ipv6: n > >>pingResultsIpTargetAddress: > >> 0 (y/n): y > >> 4 (y/n): y > >> 16 (y/n): n > >> > >> > >>Module: DISMAN-TRACEROUTE-MIB > >>Implementation Source: Internal Implementation. > >>Management Application / Agent: > >> It is based on Wind River WindManage v9.3 > >> > >>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): rw > >>traceRouteCtlStorageType (rw/ro): rw (volatile only) > >>traceRouteCtlDSField (rw/ro): rw > >>traceRouteCtlType (rw/ro): rw > >>traceRouteResultsIpTgtAddrType > >> unknown (y/n): y > >> ipv4 (y/n): y > >> ipv6 (y/n): n > >>traceRouteResultsIpTgtAddr > >> 0 (y/n): y > >> 4 (y/n): y > >> 16 (y/n): n > >>traceRouteProbeHistoryHAddrType > >> unknown (y/n): y > >> ipv4 (y/n): y > >> ipv6 (y/n): n > >>traceRouteProbeHistoryHAddr > >> 0 (y/n): y > >> 4 (y/n): y > >> 16 (y/n): n > >>traceRouteHopsIpTgtAddressType > >> unknown (y/n): y > >> ipv4 (y/n): y > >> ipv6 (y/n): n > >>traceRouteHopsIpTgtAddress > >> 0 (y/n): y > >> 4 (y/n): y > >> 16 (y/n): n > >> > >> > >>Module: DISMAN-NSLOOKUP-MIB > >>Implementation Source: Not supported. > >>Management Application / Agent: > >> > >>GROUPs > >>lookupGroup (y/n): n > >> > >>OBJECTs: > >>lookupMaxConcurrentRequests (rw/ro): NA > >>lookupPurgeTime (rw/ro): NA > >> > >> > >>Deployment / Operational Experience: > >> > >>Comments: > >> > >> From disman-bounces@ietf.org Mon Jul 19 19:15: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 TAA02554 for ; Mon, 19 Jul 2004 19:15: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 1BmetJ-0006uy-CR; Mon, 19 Jul 2004 16:37:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmdgU-00014u-7x; Mon, 19 Jul 2004 15:20:22 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18002; Mon, 19 Jul 2004 15:20:20 -0400 (EDT) Message-Id: <200407191920.PAA18002@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 19 Jul 2004 15:20:19 -0400 X-Mailman-Approved-At: Mon, 19 Jul 2004 16:37:40 -0400 Cc: disman@ietf.org Subject: [Disman] I-D ACTION:draft-ietf-disman-remops-mib-v2-03.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-03.txt Pages : 89 Date : 2004-7-19 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-03.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-03.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-03.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-7-19152151.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-disman-remops-mib-v2-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-disman-remops-mib-v2-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-7-19152151.I-D@ietf.org> --OtherAccess-- --NextPart-- From disman-bounces@ietf.org Tue Jul 20 06:34: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 GAA06895 for ; Tue, 20 Jul 2004 06:34: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 1BmrsT-0004LE-5D; Tue, 20 Jul 2004 06:29:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmrrR-0003z4-FD for disman@megatron.ietf.org; Tue, 20 Jul 2004 06:28:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06479 for ; Tue, 20 Jul 2004 06:28:34 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmrrY-0005jW-9e for disman@ietf.org; Tue, 20 Jul 2004 06:28:45 -0400 Received: from [10.1.1.171] (marseille.netlab.nec.de [195.37.70.15]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 5BD161BAC4D for ; Tue, 20 Jul 2004 12:27:56 +0200 (CEST) Date: Tue, 20 Jul 2004 12:28:37 +0200 From: Juergen Quittek To: disman@ietf.org Message-ID: <2147483647.1090326517@[10.1.1.171]> In-Reply-To: <200407191920.PAA18002@ietf.org> References: <200407191920.PAA18002@ietf.org> 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-Score: 0.0 (/) X-Scan-Signature: 07e9b4af03a165a413ec6e4d37ae537b Content-Transfer-Encoding: 7bit Subject: [Disman] Re: I-D ACTION:draft-ietf-disman-remops-mib-v2-03.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 Content-Transfer-Encoding: 7bit Dear all, Below please find the list of changes from version -02 to version -03. Thanks, Juergen -- Juergen Quittek quittek@netlab.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.netlab.nec.de --On 19.07.2004 15:20 h -0400 Internet-Drafts@ietf.org wrote: > 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-03.txt > Pages : 89 > Date : 2004-7-19 ======================================= changes from version -02 to version -03 ======================================= ======================================================================== 23. new Internet draft boilerplates ======================================================================== Problem Description: ------------------------------------------------------------------------ The boilerplates for Internet drafts have changed. the ones used so far are outdated. ======================================================================== Suggested solution: ------------------------------------------------------------------------ Update boilerplate sections. ======================================================================== Status: solution committed ======================================================================== ======================================================================== 24. DESCRIPTIONs of pingCtlTrapProbe/TestFailureFilter unclear ======================================================================== Problem Description: ------------------------------------------------------------------------ The DESCRIPTION clauses of objects pingCtlTrapProbeFailureFilter and pingCtlTrapTestFailureFilter have some ambiguity ======================================================================== Suggested solution: ------------------------------------------------------------------------ in DESCRITION clause of pingCtlTrapProbeFailureFilter replace OLD Setting pingCtlTrapGeneration to probeFailure(0) implies that a pingProbeFailed NOTIFICATION is generated only when the number of successive probe failures as indicated by the value of pingCtlTrapPrbefailureFilter fail within a given ping test." with NEW Setting BIT probeFailure(0) of object pingCtlTrapGeneration to '1' implies that a pingProbeFailed NOTIFICATION is generated only when a number of consecutive ping probes equal to the value of pingCtlTrapProbeFailureFilter fail within a given ping test. After triggering the notification, the probe failure counter is reset to zero." in DESCRITION clause of pingCtlTrapTestFailureFilter replace OLD Setting pingCtlTrapGeneration to testFailure(1) implies that a pingTestFailed NOTIFICATION is generated only when the number of ping failures within a test exceed the value of pingCtlTrapTestFailureFilter." with new Setting BIT testFailure(1) of object pingCtlTrapGeneration to '1' implies that a pingTestFailed NOTIFICATION is generated only when a number of consecutive ping tests equal to the value of pingCtlTrapProbeFailureFilter fail. After triggering the notification the test failure, counter is reset to zero." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 25. wrong DEFVAL for pingCtlSourceAddressType, traceRouteCtlTargetAddressType, and lookupCtlTargetAddressType ======================================================================== Problem Description: ------------------------------------------------------------------------ Object pingCtlSourceAddressType with a SYNTAX clause of InetAddressType has a DEFVAL of { ipv4 }. this does not comply with RFC 3291. The same applies to objects traceRouteCtlTargetAddressType and lookupCtlTargetAddressType. ======================================================================== Suggested solution: ------------------------------------------------------------------------ for pingCtlSourceAddressType, traceRouteCtlTargetAddressType and lookupCtlTargetAddressType: replace OLD DEFVAL { ipv4 } with NEW DEFVAL { unknown } ======================================================================== Status: solution committed ======================================================================== ======================================================================== 26. Name and number conflicts in compliancy sections ======================================================================== Problem Description: ------------------------------------------------------------------------ Some object groups and the compliancy statements have changed compared to RFC 2925, but still use the same names and OIDs. ======================================================================== Suggested solution: ------------------------------------------------------------------------ rename OLD pingGroup to NEW pingMinimumGroup rename OLD pingCompliance to NEW pingFullCompliance rename OLD traceRouteGroup to NEW traceRouteMinimumGroup rename OLD traceRouteCompliance to NEW traceRouteFullCompliance remove all OID conflicts with RFC 2925 ======================================================================== Status: solution committed ======================================================================== ======================================================================== 27. read-only RowStatus conflicts with RowStatus TC ======================================================================== Problem Description: ------------------------------------------------------------------------ pingCtlRowStatus and traceRouteCtlRowStatus have MIN-ACCES of read-only in pingMinimumCompliancy and traceRouteMinimumCompliancy, respectively. According to the RowStatus TC this implies that the row status can never have a transition to 'active'. ======================================================================== Suggested solution: ------------------------------------------------------------------------ Make the implementation of pingCtlRowStatus and traceRouteCtlRowStatus optional in pingMinimumCompliancy and traceRouteMinimumCompliancy: add NEW pingCtlRowStatusGroup OBJECT-GROUP OBJECTS { pingCtlRowStatus } STATUS current DESCRIPTION "The RowStatus object of the pingCtlTable." ::= { pingGroups 5 } in pingMinimumCompliancy replace OLD OBJECT pingCtlRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required. If write access is not supported then at least one entry in the pingCtlTable MUST be established already when the SNMP agent starts offering access to the PING-MIB module. If in such a case only a single entry is offered, then it is RECOMMENDED that this entry uses strings with a length of 0 for both of its two index objects." with NEW GROUP pingCtlRowStatusGroup DESCRIPTION "A compliant implementation does not have to implement the pingCtlRowStatusGroup." add NEW traceRouteCtlRowStatusGroup OBJECT-GROUP OBJECTS { traceRouteCtlRowStatus } STATUS current DESCRIPTION "The RowStatus object of the traceRouteCtlTable." ::= { traceRouteGroups 6 } in traceRouteMinimumCompliancy remove OLD OBJECT traceRouteCtlRowStatus MIN-ACCESS read-only DESCRIPTION "Write access is not required. If write access is not supported then at least one entry in the pingCtlTable MUST be established already when the SNMP agent starts offering access to the TRACEROUTE-MIB module. If in such a case only a single entry is offered, then it is RECOMMENDED that this entry uses strings with a length of 0 for both of its two index objects." ======================================================================== Status: solution committed ======================================================================== ======================================================================== 28. Security consideration do not match boilerplate ======================================================================== Problem Description: ------------------------------------------------------------------------ The section on security considerations does not match the boilerplate for MIB security considerations. ======================================================================== Suggested solution: ------------------------------------------------------------------------ replace OLD 5. Security Considerations Certain management information in the MIBs defined by this document may be considered sensitive in some network environments. Therefore, authentication of received SNMP requests and controlled access to management information SHOULD be employed in such environments. The method for this authentication is a function of the SNMP Administrative Framework, and has not been expanded by this MIB. To facilitate the provisioning of access control by a security administrator using the View-Based Access Control Model (VACM) defined in RFC 3415 [RFC3415] for tables in which multiple users may need to independently create or modify entries, the initial index is used as an "owner index". Such an initial index has a syntax of SnmpAdminString, and can thus be trivially mapped to a securityName or groupName as defined in VACM, in accordance with a security policy. All entries in related tables belonging to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same subidentifiers (except for the "column" subidentifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask "wildcarding" the column subidentifier. More elaborate configurations are possible. The VACM access control mechanism described above provides control. In general, both the ping and traceroute functions when used excessively are considered a form of system attack. In the case of ping sending a system requests too often can negatively effect its performance or attempting to connect to what is supposed to be an unused port can be very unpredictable. Excessive use of the traceroute capability can like ping negatively affect system performance. In insecure environments it is RECOMMENDED that the MIBs defined within this memo not be supported. with NEW 5. Security Considerations There are a number of management objects defined in the three MIB modules with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. These are the tables and objects and their sensitivity/vulnerability: o pingMaxConcurrentRequests o traceRouteMaxConcurrentRequests o lookupMaxConcurrentRequests The MIB modules limit their maximum numbers of concurrent requests by the values of these objects. Unauthorized access to them may lead to an overload of the managed node and to a disruption of other functions of the managed node. o pingCtlTable o traceRouteCtlTable o lookupCtlTable All objects in entries of these tables (except index objects) have a MAX-ACCESS clause of read-create. Unauthorized access to these objects can disturb the measurements controlled by the tables. Also, the functions offered by the MIB modules can be misused for illegal data retrieval and for attacking other systems by floods of ping probes, traceorute probes or lookup requests, respectively. In general, both the ping and traceroute functions when used excessively are considered a form of system attack. In the case of ping sending a system requests too often can negatively effect its performance or attempting to connect to what is supposed to be an unused port can be very unpredictable. Excessive use of the traceroute capability can like ping negatively affect system performance. In insecure environments it is RECOMMENDED that the MIBs defined within this memo not be supported. o lookupPurgeTime Unauthorized access to this object can lead to results of lookup operations being deleted before they are read by a management system, if the object is set to 0 or small values close to 0. If otherwise, the object is set to very high values, unauthorized access can lead to a high consumption of resources for storing lookup results. Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. However, the only information that might be disclosed is the configuration and results of measurements that are performed by implementations of the MIB modules. This information can only be mis-used in conjunction with the mis-use of further information. To facilitate the provisioning of access control by a security administrator using the View-Based Access Control Model (VACM) defined in RFC 3415 [RFC3415] for tables in which multiple users may need to independently create or modify entries, the initial index is used as an "owner index". Such an initial index has a syntax of SnmpAdminString, and can thus be trivially mapped to a securityName or groupName as defined in VACM, in accordance with a security policy. All entries in related tables belonging to a particular user will have the same value for this initial index. For a given user's entries in a particular table, the object identifiers for the information in these entries will have the same subidentifiers (except for the "column" subidentifier) up to the end of the encoded owner index. To configure VACM to permit access to this portion of the table, one would create vacmViewTreeFamilyTable entries with the value of vacmViewTreeFamilySubtree including the owner index portion, and vacmViewTreeFamilyMask "wildcarding" the column subidentifier. More elaborate configurations are possible. The VACM access control mechanism described above provides control. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy). Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. ======================================================================== Status: solution committed ======================================================================== From disman-bounces@ietf.org Tue Jul 20 06:43: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 GAA07456 for ; Tue, 20 Jul 2004 06:43: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 1Bms0v-0006M1-59; Tue, 20 Jul 2004 06:38:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmrxZ-0005Xw-Cw for disman@megatron.ietf.org; Tue, 20 Jul 2004 06:34:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06933 for ; Tue, 20 Jul 2004 06:34:54 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bmrxg-0005nF-G7 for disman@ietf.org; Tue, 20 Jul 2004 06:35:05 -0400 Received: from [10.1.1.171] (marseille.netlab.nec.de [195.37.70.15]) by kyoto.netlab.nec.de (Postfix) with ESMTP id E6FFE1BAC4D for ; Tue, 20 Jul 2004 12:34:22 +0200 (CEST) Date: Tue, 20 Jul 2004 12:35:04 +0200 From: Juergen Quittek To: disman@ietf.org Message-ID: <2147483647.1090326904@[10.1.1.171]> In-Reply-To: <2147483647.1090326517@[10.1.1.171]> References: <200407191920.PAA18002@ietf.org> <2147483647.1090326517@[10.1.1.171]> 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-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit Subject: [Disman] Re: I-D ACTION:draft-ietf-disman-remops-mib-v2-03.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 Content-Transfer-Encoding: 7bit Dear all, When editing the last version, I made a few mistakes and failed to apply three changes, that you will find listed at the end of this message. Since we are entering a short WG last call on this document soon, please include three suggested changes below in your review. Thanks, Juergen --On 20.07.2004 12:28 Uhr +0200 Juergen Quittek wrote: > Dear all, > > Below please find the list of changes from version -02 to version -03. > > Thanks, > > Juergen [...] > ================================ suggested changes to version -03 ================================ ======================================================================== 29. Bad numbering of objects in DISMAN-TRACEROUTE-MIB ======================================================================== Problem Description: ------------------------------------------------------------------------ OID { traceRouteGroups 6 } is assigned twice, to traceRouteCtlRowStatusGroup and to traceRouteHistoryGroup ======================================================================== Suggested solution: ------------------------------------------------------------------------ replcace for traceRouteHistoryGroup OLD ::= { traceRouteGroups 6 } with NEW ::= { traceRouteGroups 7 } ======================================================================== Status: solution suggested ======================================================================== ======================================================================== 30. traceRouteMinimumCompliancy does not cover traceRouteCtlRowStatusGroup ======================================================================== Problem Description: ------------------------------------------------------------------------ The traceRouteMinimumCompliancy statement does not cover the new traceRouteCtlRowStatusGroup. ======================================================================== Suggested solution: ------------------------------------------------------------------------ add to traceRouteMinimumCompliancy: GROUP traceRouteCtlRowStatusGroup DESCRIPTION "A compliant implementation does not have to implement the traceRouteCtlRowStatusGroup." ======================================================================== Status: solution suggested ======================================================================== ======================================================================== 31. Coverage of excessive lookup in security considerations ======================================================================== Problem Description: ------------------------------------------------------------------------ The Security considerations do not describe the threat of excessively using the lookup service. raised by Dan Romascanu ======================================================================== Suggested solution: ------------------------------------------------------------------------ In Secton 5. Security Considerations replace OLD In general, both the ping and traceroute functions when used excessively are considered a form of system attack. In the case of ping sending a system requests too often can negatively effect its performance or attempting to connect to what is supposed to be an unused port can be very unpredictable. Excessive use of the traceroute capability can like ping negatively affect system performance. In insecure environments it is RECOMMENDED that the MIBs defined within this memo not be supported. with NEW In general, all three, the ping, traceroute and lookup functions, when used excessively are considered a form of system attack. In the case of ping sending a system requests too often can negatively effect its performance or attempting to connect to what is supposed to be an unused port can be very unpredictable. Excessive use of the traceroute capability can like ping negatively affect system performance. The same applies to excessive use of the lookup service, particularly, if the lookup cannot be resolved locally. In insecure environments it is RECOMMENDED that the MIBs defined within this memo not be supported. ======================================================================== Status: solution suggested ======================================================================== From disman-bounces@ietf.org Tue Jul 20 08:11:50 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 IAA13406 for ; Tue, 20 Jul 2004 08:11: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 1BmtLd-0003h2-Rm; Tue, 20 Jul 2004 08:03:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmtF3-000260-Ve for disman@megatron.ietf.org; Tue, 20 Jul 2004 07:57:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11992 for ; Tue, 20 Jul 2004 07:57:04 -0400 (EDT) Received: from weird-brew.cisco.com ([144.254.15.118] helo=strange-brew.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmtFB-0006oI-6v for disman@ietf.org; Tue, 20 Jul 2004 07:57:14 -0400 Received: from [144.254.7.44] (dhcp-peg3-vl30-144-254-7-44.cisco.com [144.254.7.44]) by strange-brew.cisco.com (8.11.7+Sun/8.8.8) with ESMTP id i6KBuXg13853; Tue, 20 Jul 2004 13:56:33 +0200 (CEST) Message-ID: <40FD086E.4080304@cisco.com> Date: Tue, 20 Jul 2004 13:56:30 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: disman@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: me , Ramanathan Kavasseri Subject: [Disman] Editor for the EVENT-MIB 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 Hi, Looking at the Seoul meeting minutes and discussing with Ram Kavasseri (the current editor), I see that you are still looking for an editor for the EVENT-MIB. If this is still the case, I would like to propose myself. I have to admit that I haven't given much feedback on the list. However, I've been recently testing the cisco implementation of that MIB. If accepted, Ram would remain the editor till the San Diego meeting, and the co-editor for some time. Feedback? Regards, Benoit From disman-bounces@ietf.org Tue Jul 20 13:57: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 NAA10207 for ; Tue, 20 Jul 2004 13:57: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 1Bmylz-00030J-H6; Tue, 20 Jul 2004 13:51:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BmyfB-0000jt-H1 for disman@megatron.ietf.org; Tue, 20 Jul 2004 13:44:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08810 for ; Tue, 20 Jul 2004 13:44:24 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BmyfK-0003tG-Um for disman@ietf.org; Tue, 20 Jul 2004 13:44:37 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 20 Jul 2004 10:46:49 +0000 X-BrightmailFiltered: true Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i6KHhnIV014448; Tue, 20 Jul 2004 10:43:50 -0700 (PDT) Received: from cisco.com (dhcp-128-107-133-87.cisco.com [128.107.133.87]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id ADH41721; Tue, 20 Jul 2004 10:43:49 -0700 (PDT) Message-ID: <40FD5A20.6000203@cisco.com> Date: Tue, 20 Jul 2004 10:45:04 -0700 From: Ramanathan Kavasseri User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Benoit Claise Subject: Re: [Disman] Editor for the EVENT-MIB References: <40FD086E.4080304@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: disman@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 Benoit Claise wrote: > Hi, > > Looking at the Seoul meeting minutes and discussing with Ram Kavasseri > (the current editor), I see that you are still looking for an editor for > the EVENT-MIB. > If this is still the case, I would like to propose myself. > I have to admit that I haven't given much feedback on the list. However, > I've been recently testing the cisco implementation of that MIB. > If accepted, Ram would remain the editor till the San Diego meeting, and > the co-editor for some time. > Benoit, if the wg is ok with this, it works well with me. Ram > Feedback? > > Regards, Benoit > From disman-bounces@ietf.org Tue Jul 20 23:21:52 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 XAA11226 for ; Tue, 20 Jul 2004 23:21:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn7Cw-00041Y-On; Tue, 20 Jul 2004 22:51:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bn6mJ-0006Ky-F4 for disman@megatron.ietf.org; Tue, 20 Jul 2004 22:24:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01460 for ; Tue, 20 Jul 2004 22:24:17 -0400 (EDT) Received: from falcon.mail.pas.earthlink.net ([207.217.120.74]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bn6mY-0000Fe-Hg for disman@ietf.org; Tue, 20 Jul 2004 22:24:35 -0400 Received: from h-69-3-92-43.snvacaid.dynamic.covad.net ([69.3.92.43] helo=oemcomputer) by falcon.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1Bn6mB-0000Bg-00 for disman@ietf.org; Tue, 20 Jul 2004 19:24:11 -0700 Message-ID: <023201c46eca$18c613a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200407191920.PAA18002@ietf.org><2147483647.1090326517@[10.1.1.171]> <2147483647.1090326904@[10.1.1.171]> Subject: Re: [Disman] Re: I-D ACTION:draft-ietf-disman-remops-mib-v2-03.txt Date: Tue, 20 Jul 2004 19:26:14 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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: > Sent: Tuesday, July 20, 2004 3:35 AM > Subject: [Disman] Re: I-D ACTION:draft-ietf-disman-remops-mib-v2-03.txt ... > When editing the last version, I made a few mistakes and failed > to apply three changes, that you will find listed at the end of > this message. > > Since we are entering a short WG last call on this document > soon, please include three suggested changes below in your > review. ... Thanks, Juergen. Since the IESG doesn't like documents with errata sheets (I wonder why? :-) we'll need to spin a new draft before we hand it off to our AD. However, unless some other issue surfaces in the meantime, I will *NOT* issue a WG last call on that revision, and instead hand it off directly to our AD. If anyone objects to proceeding in this manner, please speak up now. Randy Presuhn disman WG chair From disman-bounces@ietf.org Wed Jul 21 03:39: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 DAA24717 for ; Wed, 21 Jul 2004 03:39: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 1BnBd1-00006h-R7; Wed, 21 Jul 2004 03:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnBYO-0006EF-Bv for disman@megatron.ietf.org; Wed, 21 Jul 2004 03:30:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24186 for ; Wed, 21 Jul 2004 03:30:14 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnBYe-00066F-4y for disman@ietf.org; Wed, 21 Jul 2004 03:30:35 -0400 Received: from [10.1.1.171] (marseille.netlab.nec.de [195.37.70.15]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 6B5D21BAC4D; Wed, 21 Jul 2004 09:29:34 +0200 (CEST) Date: Wed, 21 Jul 2004 09:30:15 +0200 From: Juergen Quittek To: Randy Presuhn , disman@ietf.org Subject: Re: [Disman] Re: I-D ACTION:draft-ietf-disman-remops-mib-v2-03.txt Message-ID: <2147483647.1090402215@[10.1.1.171]> In-Reply-To: <023201c46eca$18c613a0$7f1afea9@oemcomputer> References: <200407191920.PAA18002@ietf.org><2147483647.1090326517@[10.1.1.171]> <2147483647.1090326904@[10.1.1.171]> <023201c46eca$18c613a0$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-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 Randy, --On 20.07.2004 19:26 Uhr -0700 Randy Presuhn wrote: > Hi - > >> From: "Juergen Quittek" >> To: >> Sent: Tuesday, July 20, 2004 3:35 AM >> Subject: [Disman] Re: I-D ACTION:draft-ietf-disman-remops-mib-v2-03.txt > ... >> When editing the last version, I made a few mistakes and failed >> to apply three changes, that you will find listed at the end of >> this message. >> >> Since we are entering a short WG last call on this document >> soon, please include three suggested changes below in your >> review. > ... > > Thanks, Juergen. Since the IESG doesn't like documents with > errata sheets (I wonder why? :-) we'll need to spin a new draft > before we hand it off to our AD. Yes, of course. I just handed in the errata in order to simplify the last call procedure. > However, unless some other > issue surfaces in the meantime, I will *NOT* issue a WG last > call on that revision, and instead hand it off directly to our AD. > If anyone objects to proceeding in this manner, please speak > up now. If anybody wants to preview the fixed version (to be submitted after the IETF meeting), please have a look at ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-disman-remops-mib-v2-04.txt Thanks, Juergen -- Juergen Quittek quittek@netlab.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.netlab.nec.de > Randy Presuhn > disman WG chair > > > From disman-bounces@ietf.org Wed Jul 21 12:24: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 MAA01187 for ; Wed, 21 Jul 2004 12:24: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 1BnJYB-000617-G1; Wed, 21 Jul 2004 12:02:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnJUA-0004bH-Iy for disman@megatron.ietf.org; Wed, 21 Jul 2004 11:58:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29160 for ; Wed, 21 Jul 2004 11:58:23 -0400 (EDT) Received: from gull.mail.pas.earthlink.net ([207.217.120.84]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnJUX-0004tD-0w for disman@ietf.org; Wed, 21 Jul 2004 11:58:50 -0400 Received: from h-68-165-170-16.snvacaid.dynamic.covad.net ([68.165.170.16] helo=oemcomputer) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1BnJU7-00039x-00 for disman@ietf.org; Wed, 21 Jul 2004 08:58:23 -0700 Message-ID: <000c01c46f3b$d78e5740$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200407191920.PAA18002@ietf.org><2147483647.1090326517@[10.1.1.171]> <2147483647.1090326904@[10.1.1.171]><023201c46eca$18c613a0$7f1afea9@oemcomputer> <2147483647.1090402215@[10.1.1.171]> Subject: Re: [Disman] Re: I-D ACTION:draft-ietf-disman-remops-mib-v2-03.txt Date: Wed, 21 Jul 2004 09:00:27 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: "Randy Presuhn" ; > Sent: Wednesday, July 21, 2004 12:30 AM > Subject: Re: [Disman] Re: I-D ACTION:draft-ietf-disman-remops-mib-v2-03.txt ... > If anybody wants to preview the fixed version (to be submitted > after the IETF meeting), please have a look at > > ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-disman-remops-mib-v2-04.txt ... Thanks! As always, I'd like to hear from anyone who has read the draft, even if it's only to say "no objection". Randy From disman-bounces@ietf.org Wed Jul 21 14:14:08 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 OAA09298 for ; Wed, 21 Jul 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 1BnLTZ-0000xB-1U; Wed, 21 Jul 2004 14:05:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnLQX-0008JL-NL for disman@megatron.ietf.org; Wed, 21 Jul 2004 14:02:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08467 for ; Wed, 21 Jul 2004 14:02:48 -0400 (EDT) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnLQr-0006T0-9f for disman@ietf.org; Wed, 21 Jul 2004 14:03:14 -0400 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i6LHuMKa003832 for ; Wed, 21 Jul 2004 12:56:22 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i6LHuJKa003773 for ; Wed, 21 Jul 2004 12:56:20 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Disman] Re: I-D ACTION:draft-ietf-disman-remops-mib-v2-03.txt Date: Wed, 21 Jul 2004 21:02:39 +0300 Message-ID: Thread-Topic: [Disman] Re: I-D ACTION:draft-ietf-disman-remops-mib-v2-03.txt Thread-Index: AcRvP0Jn3QL0UQNXTw29Vs13PO8stwADX+cQ From: "Romascanu, Dan (Dan)" To: "Randy Presuhn" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable 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 looked at it, and I am fairly happy with new version. The issues that = I raised was addressed in an appropriate manner. Regards, Dan > -----Original Message----- > From: disman-bounces@ietf.org=20 > [mailto:disman-bounces@ietf.org]On Behalf Of Randy Presuhn > Sent: 21 July, 2004 7:00 PM > To: disman@ietf.org > Subject: Re: [Disman] Re: I-D=20 > ACTION:draft-ietf-disman-remops-mib-v2-03.txt >=20 >=20 > Hi - >=20 > > From: "Juergen Quittek" > > To: "Randy Presuhn" ;=20 > > > Sent: Wednesday, July 21, 2004 12:30 AM > > Subject: Re: [Disman] Re: I-D=20 > ACTION:draft-ietf-disman-remops-mib-v2-03.txt > ... > > If anybody wants to preview the fixed version (to be submitted > > after the IETF meeting), please have a look at > > > > =20 > ftp://ftp.ccrle.nec.de/pub/internet-drafts/draft-ietf-disman-r > emops-mib-v2-04.txt > ... >=20 > Thanks! >=20 > As always, I'd like to hear from anyone who has read the draft, > even if it's only to say "no objection". >=20 > Randy >=20 >=20 >=20 >=20 From disman-bounces@ietf.org Thu Jul 22 18:53:36 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 SAA24211 for ; Thu, 22 Jul 2004 18:53:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BnkGO-00079x-I5; Thu, 22 Jul 2004 16:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bnjfe-0004n0-Uj for disman@megatron.ietf.org; Thu, 22 Jul 2004 15:56:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22223 for ; Thu, 22 Jul 2004 15:56:00 -0400 (EDT) Received: from mallard.mail.pas.earthlink.net ([207.217.120.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BnjgF-0008Jk-ES for disman@ietf.org; Thu, 22 Jul 2004 15:56:41 -0400 Received: from h-68-166-38-176.snvacaid.dynamic.covad.net ([68.166.38.176] helo=oemcomputer) by mallard.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1Bnjfa-0003GR-00 for disman@ietf.org; Thu, 22 Jul 2004 12:55:58 -0700 Message-ID: <005a01c47026$342ab9e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: "Disman \(E-mail\)" Date: Thu, 22 Jul 2004 12:58:05 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: [Disman] disman document editors 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 are an editor of a disman WG document, or are interested in becoming one, I expect to see you at the Editor's Training session in San Diego. If you won't be at the session, I want a really good excuse. Randy disman WG chair > From: "Margaret Wasserman" > To: ; ; > Sent: Thursday, July 22, 2004 8:05 AM > Subject: General Training in San Diego > > > Hi All, > > We have our usual complement of training sessions scheduled for > Sunday afternoon at the San Diego IETF meeting (see below for > details). These sessions include training for IETF Newcomer's, > Introductory Training for New or Aspiring WG Chairs, Training for > IETF Document Editors and a technical Security Tutorial. > > All of these sessions are open to any IETF participant. So, if you > will be in San Diego on Sunday afternoon, I hope you will attend! > > Thanks, > Margaret > > --- > > Sunday, August 1, 2004 > =================== > > 1300-1400 Newcomer's Training -- Grande Ballroom A (Margaret Wasserman) > > An introduction to the IETF for new or recent IETF > attendees. Covers the IETF document processes, the > structure of the IETF, and tips for new attendees to > be successful in the IETF environment. > > 1300-1500 Editor's Training -- Marina 5 (Avri Doria) > > Training for current or aspiring IETF document > editors. Covers the roles and responsibilities > of a document editor, and includes advice on > producing a high-quality IETF specification. > > 1500-1700 Intro WG Chairs Training -- Location TBD (Spencer Dawkins) > > Introductory training for new or aspiring WG > chairs. Covers the role and responsibilities of > a WG chair, and includes advice on how to run a > WG that is fair, open and productive. This class > is open to all IETF attendees. > > 1500-1700 Security Tutorial -- Grande Ballroom A (Radia Perlman) > > All IETF attendees need to be aware of the security > implications of our design choices. This session > offers a basic primer in protocol security, as well > as advice on how to write the Security Considerations > sections required for all IETF documents. > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf From disman-bounces@ietf.org Mon Jul 26 11:44: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 LAA18044 for ; Mon, 26 Jul 2004 11:44: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 1Bp7Vd-00018g-NV; Mon, 26 Jul 2004 11:35:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Bp6yR-0000Hp-Ni for disman@megatron.ietf.org; Mon, 26 Jul 2004 11:01:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08688 for ; Mon, 26 Jul 2004 11:01:04 -0400 (EDT) Received: from merkur.iu-bremen.de ([212.201.44.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Bp6zo-0004ML-R1 for disman@ietf.org; Mon, 26 Jul 2004 11:02:33 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by merkur.iu-bremen.de (Postfix) with ESMTP id 5545485DD9 for ; Mon, 26 Jul 2004 17:00:30 +0200 (CEST) Received: from merkur.iu-bremen.de ([212.201.44.27]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 10635-03; Mon, 26 Jul 2004 17:00:29 +0200 (CEST) Received: from james.eecs.iu-bremen.de (unknown [212.201.47.2]) by merkur.iu-bremen.de (Postfix) with ESMTP id 4C00D48936; Mon, 26 Jul 2004 17:00:29 +0200 (CEST) Received: by james.eecs.iu-bremen.de (Postfix, from userid 1000) id 4322782DA; Mon, 26 Jul 2004 17:00:29 +0200 (CEST) Date: Mon, 26 Jul 2004 17:00:29 +0200 From: Juergen Schoenwaelder To: disman@ietf.org Message-ID: <20040726150029.GA5185@iu-bremen.de> Mail-Followup-To: disman@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-Mailman-Approved-At: Mon, 26 Jul 2004 11:35:24 -0400 Subject: [Disman] RFC 3165 and RFC 3231 implementation reports X-BeenThere: disman@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de 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 --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline A long time has passed since Randy posted his request for implementation reports. I am sorry for being so late to followup on this. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="RFC3165-report.txt" Implementation Survey for RFC 3165, Definitions of Managed Objects for the Delegation of Management Scripts Module: DISMAN-SCRIPT-MIB Implementation Source: TU Braunschweig, Germany NEC Research Heidelberg, Germany Management Application / Agent: NET-SNMP agent GROUPs: smLanguageGroup (y/n): y smScriptGroup2 (y/n): y smLaunchGroup2 (y/n): y smRunGroup2 (y/n): y smNotificationsGroup2 (y,n): n smCodeGroup (y,n): n OBJECTs: smScriptSource (ro/rw): rw smCodeText (ro/rw): __ smLaunchArgument maximum size: SNMP_MAX_LEN smRunArgument maximum size: SNMP_MAX_LEN smRunResult maximum size: SNMP_MAX_LEN smRunState suspension permitted? (y,n): y (depends on the runtime system) Deployement / Operational Experience: SNMP_MAX_LEN defaults to 1500 in NET-SNMP 5.1.1. The source code has been downloaded a number of times. It is unclear what people really did with it in production networks. The software package includes a manager-side graphical user interface written in Java called smurf. In addition, some commands have been added to the scli SNMP command line interface in order to interact with the agent. The agent has been used in a research project to distribute, start, control and terminate policy scripts. Comments: The SNMP engine used for this application does not provide an easy way to record the credentials during the processing of a set request. Hence, the implementation cheats to some extend by guessing credentials, which of course is not a good thing to do. It is unclear whether newer versions of NET-SNMP would allow to handle this correctly. --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="RFC3231-report.txt" Implementation Survey for RFC 3231, Definitions of Managed Objects for Scheduling Management Operations Module: DISMAN-SCHEDULE-MIB Implementation Source: TU Braunschweig, Germany Management Application / Agent: NET-SNMP agent GROUPs schedGroup2 (y/n): y schedNotificationsGroup (y/n): n schedCalendarGroup (y,n): y Deployment / Operational Experience: Some commands have been implemented as part of the scli SNMP command line interface to interact with the agent. Interoperability tests with other implementations have not been performed. Comments: The SNMP engine used for this application does not provide an easy way to record the credentials during the processing of a set request. Hence, the implementation cheats to some extend by guessing credentials, which of course is not a good thing to do. It is unclear whether newer versions of NET-SNMP would allow to handle this correctly. --ReaqsoxgOBHFXBhH-- From disman-bounces@ietf.org Mon Jul 26 19:53:49 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 TAA21362 for ; Mon, 26 Jul 2004 19:53: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 1BpFC2-0001wk-6c; Mon, 26 Jul 2004 19:47:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BpF8W-00011u-1Q for disman@megatron.ietf.org; Mon, 26 Jul 2004 19:44:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20863 for ; Mon, 26 Jul 2004 19:44:02 -0400 (EDT) Received: from dcn236-44.dcn.davis.ca.us ([168.150.236.44] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1BpF9z-0002zA-I5 for disman@ietf.org; Mon, 26 Jul 2004 19:45:36 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 57BC511D904; Mon, 26 Jul 2004 16:43:53 -0700 (PDT) To: disman@ietf.org Subject: Re: [Disman] RFC 3165 and RFC 3231 implementation reports References: <20040726150029.GA5185@iu-bremen.de> From: Wes Hardaker Organization: Sparta Date: Mon, 26 Jul 2004 16:43:52 -0700 In-Reply-To: <20040726150029.GA5185@iu-bremen.de> (Juergen Schoenwaelder's message of "Mon, 26 Jul 2004 17:00:29 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.5 (chayote, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 >>>>> On Mon, 26 Jul 2004 17:00:29 +0200, Juergen Schoenwaelder said: Juergen> The SNMP engine used for this application does not provide an Juergen> easy way to record the credentials during the processing of a Juergen> set request. Hence, the implementation cheats to some extend Juergen> by guessing credentials, which of course is not a good thing Juergen> to do. It is unclear whether newer versions of NET-SNMP would Juergen> allow to handle this correctly. FYI, the version you mentioned (5.1.1) does provide APIs for accessing the security credentials. You're likely using the older (CMU style) API set, which has no nice interface to the packet credentials. However, even given that there is a work around (not-advertised because it's better for people to use the better MIB APIs if possible). Let me know if you want further information. EG, the event mib implementation properly records authentication information (and is written using the older APIs as well). -- "In the bathtub of history the truth is harder to hold than the soap, and much more difficult to find." -- Terry Pratchett